Windows Server TechCenter >
Windows Server Forums
>
WSUS
>
WSUS Clients in Unassigned group taking updates
WSUS Clients in Unassigned group taking updates
- I have installed WSUS 3.0 on a Windows 2008 Server. I started testing by creating an OU in AD called "WSUS Test". I created a Group Policy linked to that OU that pointed computers in that group to the WSUS server. As an added measure I added the computers that I moved to that OU to the "Scope" in the GPO so that it would apply only to those computers. In WSUS I have the default groups of "All Computers" and "Unassigned" and I created a "WSUS Test" group and a "Full Deploy" group. My theory was to add computers to the test group in WSUS and set automatic updates for security and critical updates. Then after a day or so I would approve updates for the "Full Deploy" group which was to have all our computers other than the test group.
The first problem I encountered was that about 50 computers showed up in the "Unassigned" group even though I had not invited them through my AD and GPO setup. So I created a group called "Rogue" and moved them there to investigate why they showed up. I never did figure it out, but admittedly I did not spend a long time trying.
My bigger problem was that I decided to move the GPO to our "Computers" OU in AD that houses all of our computers (@550). And I took the test PC's out of the scope in the GPO and put "Authenticated Users". My theory here was to get all our PC's showing up in the WSUS "Unassigned" group and then move them 50 at a time into the "Full Deploy" group. What happened next caused a bit of a stir. The computers in th "Unassigned" group started taking updates and I had a dozen or so unsuspecting users stuck at the "Applying Personal Settings" screen at login (XP Pro SP2 and 3) for upwards of 45 minutes.
So my question is why would PC's in the "Unassigned" group take updates? I only approved updates for the "WSUS Test" and "Full Deploy" groups. Any help would be greatly appreciated.
Thanks,
Bob Gentry
All Replies
- Look for previous revisions on those updates that are approved for install on All Computers or on the parent group of your WSUS Test group. Since SP2, WSUS appears to be ignoring the configuration where you tell it to not automatically approve where there is a previous revision approval.
Just in case you're new to WSUS, to get to the revisions, right-click the update and choose Revision History.
The setting that is supposed to prevent this problem is under Options (in the left panel) then in the middle panel, Automatic Approvals. Go to the advanced tab and clear the check box for automatically approving where there was a previous revision approval - not that this appears to matter any longer since WSUS SP2.
Regards,
Dale As an added measure I added the computers that I moved to that OU to the "Scope" in the GPO so that it would apply only to those computers.
This "added measure" is probably a contributing factor; it's certainly an unnecessary complication of your Group Policy configuration. Adding unnecessary (and insignificant) complications to configurations can only result one one thing: Confusion down the road when you're trying to troubleshoot something and forgot that "complication" was implemented.My theory was to add computers to the test group in WSUS and set automatic updates for security and critical updates. Then after a day or so I would approve updates for the "Full Deploy" group which was to have all our computers other than the test group.
This is pretty much how it's designed to work.The first problem I encountered was that about 50 computers showed up in the "Unassigned" group even though I had not invited them through my AD and GPO setup. So I created a group called "Rogue" and moved them there to investigate why they showed up.
A reasonable response. Note: The most likely reason is that your Group Policy Object impacted more computers than you intended/expected. Remember your "added measure" above? Let's keep that in the back of your mind.I took the test PC's out of the scope in the GPO and put "Authenticated Users".
Another unnecessary complication. :)The computers in th "Unassigned" group started taking updates and I had a dozen or so unsuspecting users stuck at the "Applying Personal Settings" screen at login (XP Pro SP2 and 3) for upwards of 45 minutes. So my question is why would PC's in the "Unassigned" group take updates? I only approved updates for the "WSUS Test" and "Full Deploy" groups.
So, you applied a GPO at the "Computers" OU, you made it applicable to "Authenticated Users", and a bunch of computers in the "Unassigned Computers" group began installing updates. The answer to your question is found in the entries of the WindowsUpdate.log of one of those "unsuspecting" computers in the Unassigned Computers group.
The possibilities are this:
1. An automatic-approval rule was enabled and auto-approved updates for the All Computers or Unassigned Computers group.
2. "WSUS Required" updates were not taken into consideration, and your XP SP2 systems are missing (the most likely) the latest update (about 16 months old now) to the Package Installer.
3. The computers reporting in "Unassigned Computers" really aren't in that group and think they're in the Test or Production group.
The best approach is to review the WindowsUpdate.log for the period of time in which these installations were triggered. Post it here if you'd like some assistance interpreting the log entries. The log will tell us why the agent detected the update and where it got the update from.
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
My Blog: http://onsitechsolutions.spaces.live.comLook for previous revisions on those updates that are approved for install on All Computers or on the parent group of your WSUS Test group.
Just to expand on this point... previous revisions are only a risk factor *IF* you've disabled the option "Automatically decline updates when a new revision causes them to expire.", which, of course, also requires "Automatically approve new revisions of updates that are already approved" to be enabled.
Yes, I do know that some people got burned EONS ago because a Windows Desktop Search update was packaged incorrectly. That's one update out of thousands. If you choose to disable these options, then you also assume the responsibility for manually inspecting and configuring every update/revision released to your system to prevent being bit by approved revisions that should be declined because they've been expired.
MOST WSUS environments are not risk for this situation.
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
My Blog: http://onsitechsolutions.spaces.live.com
As I posted in another thread, since WSUS SP2, this is happening now for all updates on my server. Updates that do not have explicit approvals are getting approved if there is any revision it the history that has approval.Look for previous revisions on those updates that are approved for install on All Computers or on the parent group of your WSUS Test group.
Just to expand on this point... previous revisions are only a risk factor *IF* you've disabled the option "Automatically decline updates when a new revision causes them to expire.", which, of course, also requires "Automatically approve new revisions of updates that are already approved" to be enabled.
Yes, I do know that some people got burned EONS ago because a Windows Desktop Search update was packaged incorrectly. That's one update out of thousands. If you choose to disable these options, then you also assume the responsibility for manually inspecting and configuring every update/revision released to your system to prevent being bit by approved revisions that should be declined because they've been expired.
