WSUS v2 managing updates with the manual group option John 5/30/2007 4:42:02 AM All, I have one particular Computer Goup in WSUS v2 that I need to break up into additional Computer Groups. Currently using the GPO Option and will soon go to the Manual Option for Computer group membership. How can I ensure that my previously approved updates from the original Computer Group (with the GPO Option that I will break up into additional Computer Groups) will be installed on a new image in one of my new Computer Groups when I change to the Manual Options? Thanks, John

Re: WSUS v2 managing updates with the manual group option "Lawrence Garvin \(MVP\)" <onsitech[ at ]community.nospam> 5/30/2007 1:12:58 PM "John" <John[ at ]discussions.microsoft.com> wrote in message news:0560511E-8A49-42FF-8BE6-AD409493AD09[ at ]microsoft.com... [Quoted Text] > I have one particular Computer Goup in WSUS v2 that I need to break up > into > additional Computer Groups. Currently using the GPO Option and will soon > go > to the Manual Option for Computer group membership. > > How can I ensure that my previously approved updates from the original > Computer Group (with the GPO Option that I will break up into additional > Computer Groups) will be installed on a new image in one of my new > Computer > Groups when I change to the Manual Options? The decision as to whether an update is detected for installation is a dynamic decision made at the moment of detection each and every time based on the status of approvals on that particular update at that particular time. The historical status of approvals, or the future status of approvals, is irrelevant to the client-side agent. Therefore, the simple answer to your question is: Make sure the update is approved for the correct groups. If a machine is added to a group with an update that is approved, but not installed, it will download and install that update at the next scheduled detection event. If a machine is added to a group with an update that is Not Approved, but actually installed, it will ignore the approval status, and report the update as Installed. -- Lawrence Garvin, M.S., MCTS, MCP Independent WSUS Evangelist MVP-Software Distribution (2005-2007) https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E Everything you need for WSUS is at http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx And, almost everything else is at http://wsusinfo.onsitechsolutions.com ..... > Thanks, > John >

Re: WSUS v2 managing updates with the manual group option John 5/30/2007 1:41:00 PM Lawrence, I changed from the GPO Option to Manual, then broke up the original group to a few new groups. Within a short time, I hade one particular update previously approved for a different group I did not break up begin to show ready for installation in the new groups. Fearfull that many more updates would begin to show up in the new groups for installation, and not scheduling a change, reverted back to the GPO option and moved the machines from the new groups back into the original group. Hopefully when they check in, the update that showed for installation will clear itself. Now my concern is that I'll have to re-approve many hundreds of updates for ther new groups when I attempt the Manual Option again. Is there a less troublesome approach? Thanks, John I'm concerned now that I'll have to cycle through many hundreds of previously approved updates to "re-approve" them in the new groups. Is there a less troublesome approach? Thanks, John "Lawrence Garvin (MVP)" wrote: [Quoted Text] > "John" <John[ at ]discussions.microsoft.com> wrote in message > news:0560511E-8A49-42FF-8BE6-AD409493AD09[ at ]microsoft.com... > > > I have one particular Computer Goup in WSUS v2 that I need to break up > > into > > additional Computer Groups. Currently using the GPO Option and will soon > > go > > to the Manual Option for Computer group membership. > > > > How can I ensure that my previously approved updates from the original > > Computer Group (with the GPO Option that I will break up into additional > > Computer Groups) will be installed on a new image in one of my new > > Computer > > Groups when I change to the Manual Options? > > The decision as to whether an update is detected for installation is a > dynamic decision made at the moment of detection each and every time based > on the status of approvals on that particular update at that particular > time. > > The historical status of approvals, or the future status of approvals, is > irrelevant to the client-side agent. > > Therefore, the simple answer to your question is: Make sure the update is > approved for the correct groups. > > If a machine is added to a group with an update that is approved, but not > installed, it will download and install that update at the next scheduled > detection event. > > If a machine is added to a group with an update that is Not Approved, but > actually installed, it will ignore the approval status, and report the > update as Installed. > > -- > Lawrence Garvin, M.S., MCTS, MCP > Independent WSUS Evangelist > MVP-Software Distribution (2005-2007) > https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E > > Everything you need for WSUS is at > http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx > > And, almost everything else is at > http://wsusinfo.onsitechsolutions.com > ..... > > > > > Thanks, > > John > > > > >

Re: WSUS v2 managing updates with the manual group option "Lawrence Garvin \(MVP\)" <onsitech[ at ]community.nospam> 5/30/2007 2:36:08 PM "John" <John[ at ]discussions.microsoft.com> wrote in message news:F4EA4E8D-FD6F-4153-8B48-36A1145647C3[ at ]microsoft.com... [Quoted Text] > Lawrence, > > I changed from the GPO Option to Manual, then broke up the original group > to > a few new groups. Within a short time, I hade one particular update > previously approved for a different group I did not break up begin to show > ready for installation in the new groups. Fearfull that many more updates > would begin to show up in the new groups for installation, and not > scheduling > a change, reverted back to the GPO option and moved the machines from the > new > groups back into the original group. Hopefully when they check in, the > update > that showed for installation will clear itself. You also need to keep in mind that the client caches the target group information in a client-side "cookie". Until that cached information expires (supposedly one hour), the client will attempt to query the same target group. However, the GPO change from client-side targeting to server-side targeting should trigger the purging of that cached targeting cookie. The activities related to this change will be logged in the WindowsUpdate.log of the client systems. You might want to check there and see if the client did expire the cookie, and obtain the updated group membership from the WSUS server. If the client is reporting in the new group, this is a reasonable indication that this conversion did take place. Another consideration is the time delay between detection, download, and installation. It's conceivable that a client might detect an update in one target group, initiate the download from the server, be changed to a different target group, and then complete the download of the update, thus reporting that update ready for installation. However, if that client performs a subsequent detection to the new target group (which the policy change should trigger), then the client will see the update is no longer approved, and it will unschedule it from the installation queue. If a detection does not occur before the installation, the update will be installed. > Now my concern is that I'll have to re-approve many hundreds of updates > for > ther new groups when I attempt the Manual Option again. Is there a less > troublesome approach? Best way all the way around to make sure this is working correctly is to run the command 'wuauclt /resetauthorization /detectnow' at each of the clients who have changed group membership. This will force a cookie purge and a detection against the newly assigned target group. -- Lawrence Garvin, M.S., MCTS, MCP Independent WSUS Evangelist MVP-Software Distribution (2005-2007) https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E Everything you need for WSUS is at http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx And, almost everything else is at http://wsusinfo.onsitechsolutions.com .....

Re: WSUS v2 managing updates with the manual group option John 5/30/2007 3:50:00 PM Lawrence, After moving the machines back to the original group with client-side targeting, the update cleared itself on most machines as you mentioned it would. I see some users installed it, but no issues. One final concern I have is when I switch to server-side targeting again permanently, & break up my original group into the others i've created for this, how can I be sure when I push a new image (we use RIS), that the new image will download & be ready to install all the updates previously approved for the original traget group? This group will no longer have machines because the machines will now be broken up between all the new groups. All the new groups will receive the same updates as they did in the one original group and I need to keep it that way and be sure all new images receive the same. (The reason we are going to break up our original group into the new groups with server-side targeting, is to install updates with date and time through the week each month for now on to stagger them.) Thanks again, John "Lawrence Garvin (MVP)" wrote: [Quoted Text] > "John" <John[ at ]discussions.microsoft.com> wrote in message > news:F4EA4E8D-FD6F-4153-8B48-36A1145647C3[ at ]microsoft.com... > > Lawrence, > > > > I changed from the GPO Option to Manual, then broke up the original group > > to > > a few new groups. Within a short time, I hade one particular update > > previously approved for a different group I did not break up begin to show > > ready for installation in the new groups. Fearfull that many more updates > > would begin to show up in the new groups for installation, and not > > scheduling > > a change, reverted back to the GPO option and moved the machines from the > > new > > groups back into the original group. Hopefully when they check in, the > > update > > that showed for installation will clear itself. > > You also need to keep in mind that the client caches the target group > information in a client-side "cookie". Until that cached information expires > (supposedly one hour), the client will attempt to query the same target > group. > > However, the GPO change from client-side targeting to server-side targeting > should trigger the purging of that cached targeting cookie. > > The activities related to this change will be logged in the > WindowsUpdate.log of the client systems. You might want to check there and > see if the client did expire the cookie, and obtain the updated group > membership from the WSUS server. If the client is reporting in the new > group, this is a reasonable indication that this conversion did take place. > > Another consideration is the time delay between detection, download, and > installation. It's conceivable that a client might detect an update in one > target group, initiate the download from the server, be changed to a > different target group, and then complete the download of the update, thus > reporting that update ready for installation. > > However, if that client performs a subsequent detection to the new target > group (which the policy change should trigger), then the client will see the > update is no longer approved, and it will unschedule it from the > installation queue. If a detection does not occur before the installation, > the update will be installed. > > > Now my concern is that I'll have to re-approve many hundreds of updates > > for > > ther new groups when I attempt the Manual Option again. Is there a less > > troublesome approach? > > Best way all the way around to make sure this is working correctly is to run > the command 'wuauclt /resetauthorization /detectnow' at each of the clients > who have changed group membership. This will force a cookie purge and a > detection against the newly assigned target group. > > > > -- > Lawrence Garvin, M.S., MCTS, MCP > Independent WSUS Evangelist > MVP-Software Distribution (2005-2007) > https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E > > Everything you need for WSUS is at > http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx > > And, almost everything else is at > http://wsusinfo.onsitechsolutions.com > ..... > > > >

Re: WSUS v2 managing updates with the manual group option "Lawrence Garvin \(MVP\)" <onsitech[ at ]community.nospam> 5/30/2007 4:55:21 PM "John" <John[ at ]discussions.microsoft.com> wrote in message news:13E8E93B-2B66-4893-8F15-D3F4754CD62B[ at ]microsoft.com... [Quoted Text] > One final concern I have is when I switch to server-side targeting again > permanently, & break up my original group into the others i've created for > this, how can I be sure when I push a new image (we use RIS), that the new > image will download & be ready to install all the updates previously > approved > for the original traget group? John, this is directly, and exclusively a function of only two things: [a] Is the update approved for the correct target group. [b] Does the client know which target group to query. If both of those issues have been addressed, you should have no problems with the machines getting the desired updates. > This group will no longer have machines > because the machines will now be broken up between all the new groups. If the group will be empty -- just delete the group. That'll certainly prevent any rogue clients from getting updates through that group's approvals. > All > the new groups will receive the same updates as they did in the one > original > group and I need to keep it that way and be sure all new images receive > the > same. If the approvals list is identical between the old group and the new group, you shouldn't have any issues whatsoever. Though, as noted earlier, there may be some lag between the client detecting against the old group, and detecting against the new group. You can expedite that by using the /resetauthorization parameter and/or deleting the old (empty) group from the WSUS server. -- Lawrence Garvin, M.S., MCTS, MCP Independent WSUS Evangelist MVP-Software Distribution (2005-2007) https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E Everything you need for WSUS is at http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx And, almost everything else is at http://wsusinfo.onsitechsolutions.com .....

Re: WSUS v2 managing updates with the manual group option John 5/30/2007 5:26:01 PM Lawrence, As usual, you've helped me a great deal. I appreciate all your assistance, and Thank You, John "Lawrence Garvin (MVP)" wrote: [Quoted Text] > "John" <John[ at ]discussions.microsoft.com> wrote in message > news:13E8E93B-2B66-4893-8F15-D3F4754CD62B[ at ]microsoft.com... > > > One final concern I have is when I switch to server-side targeting again > > permanently, & break up my original group into the others i've created for > > this, how can I be sure when I push a new image (we use RIS), that the new > > image will download & be ready to install all the updates previously > > approved > > for the original traget group? > > John, this is directly, and exclusively a function of only two things: > [a] Is the update approved for the correct target group. > [b] Does the client know which target group to query. > > If both of those issues have been addressed, you should have no problems > with the machines getting the desired updates. > > > This group will no longer have machines > > because the machines will now be broken up between all the new groups. > > If the group will be empty -- just delete the group. That'll certainly > prevent any rogue clients from getting updates through that group's > approvals. > > > All > > the new groups will receive the same updates as they did in the one > > original > > group and I need to keep it that way and be sure all new images receive > > the > > same. > > If the approvals list is identical between the old group and the new group, > you shouldn't have any issues whatsoever. Though, as noted earlier, there > may be some lag between the client detecting against the old group, and > detecting against the new group. You can expedite that by using the > /resetauthorization parameter and/or deleting the old (empty) group from the > WSUS server. > > -- > Lawrence Garvin, M.S., MCTS, MCP > Independent WSUS Evangelist > MVP-Software Distribution (2005-2007) > https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E > > Everything you need for WSUS is at > http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx > > And, almost everything else is at > http://wsusinfo.onsitechsolutions.com > ..... > > >