Windows Server TechCenter > Windows Server Forums > WSUS > Deploying updates to test systems
Ask a questionAsk a question
 

AnswerDeploying updates to test systems

  • Thursday, October 29, 2009 2:31 PMspoe Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    We're testing WSUS 3.0 SP2. We've created groups by location (HQ, Remote, and Servers, and Systems). We have developers who have to replicate client testing environments, so we have to be careful about patches sent out. Does it make sense to have a test group where you may only have one or two systems in it then move the system back into a regular group after testing has been done?

     

    Thanks.

     

    Steve

Answers

  • Friday, October 30, 2009 5:22 AMLawrence GarvinMVP, ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    > Lawrence, do you have any guidelines/recommendations for creating groups?

    Nope. This is something that should be done appropriate to meeting the needs of the specific deployment and the organization in which the deployment is made.

    As for my personal server, I have a Servers group, a Workstations group, and a collection of subgroups under Servers and Workstations for each of the OS platforms and Core Server and groups for common server applications that get updates (Exchange, SQL Server, ISA, Web Server, WSUS Servers). When I approve an update I do so for the group that best represents the primary target of the update -- for example, security updates for Windows Server 2003 get approved for the Win2003 group; a SQL Server update gets approved for the SQLServers group. Then I simply make sure that machines which contain that functionaly (or subsequently obtain/remove that functionaliy) are added (or removed) from the appropriate WSUS group. But I'd hardly recommend that methodology to any organization as a general suggestion. Deciding what WSUS groups to configure is almost as significant as deciding how to setup SITES and OUs in Active Directory.

    The general guidelines in the product documentation suggest a minimum of two groups, as you've suggested: A Testing group and a Production group.

    You'll also find it appropriate, from time to time, to create temporary groups for short-term goals. For example, a technique I've suggested from time to time to deal with computers that should be excluded from receiving a specific update that all other computers should receive, is to create a separate group for the update and approve the update only for that group, or create a subgroup and explicitly remove the approval for that subgroup and move the computers into the subgroup until the update issue can be remediated, then move them back to the primary group where the update will automatically deploy to that computer.
    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

All Replies

  • Thursday, October 29, 2009 9:03 PMLawrence GarvinMVP, ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    We're testing WSUS 3.0 SP2. We've created groups by location (HQ, Remote, and Servers, and Systems). We have developers who have to replicate client testing environments, so we have to be careful about patches sent out. Does it make sense to have a test group where you may only have one or two systems in it then move the system back into a regular group after testing has been done?
    Certainly!

    If that's the nature of your testing scenarios, there's no issue at all with moving systems back and forth in order to meet your needs.

    I would, however, suggest that you also identify a couple of testing-only clients, as you'll want to have some sort of controlled testing scenarios above and beyond the needs of the development group.
    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
  • Friday, October 30, 2009 1:47 AMBryan Dam Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Lawrence, do you have any guidelines/recommendations for creating groups?  When I first setup my WSUS server I'll admit I never gave it much thought.  We have two physical locations so I just made two groups.  However, it occurs to me that a testing group and groups for servers might be a good idea.
  • Friday, October 30, 2009 5:22 AMLawrence GarvinMVP, ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    > Lawrence, do you have any guidelines/recommendations for creating groups?

    Nope. This is something that should be done appropriate to meeting the needs of the specific deployment and the organization in which the deployment is made.

    As for my personal server, I have a Servers group, a Workstations group, and a collection of subgroups under Servers and Workstations for each of the OS platforms and Core Server and groups for common server applications that get updates (Exchange, SQL Server, ISA, Web Server, WSUS Servers). When I approve an update I do so for the group that best represents the primary target of the update -- for example, security updates for Windows Server 2003 get approved for the Win2003 group; a SQL Server update gets approved for the SQLServers group. Then I simply make sure that machines which contain that functionaly (or subsequently obtain/remove that functionaliy) are added (or removed) from the appropriate WSUS group. But I'd hardly recommend that methodology to any organization as a general suggestion. Deciding what WSUS groups to configure is almost as significant as deciding how to setup SITES and OUs in Active Directory.

    The general guidelines in the product documentation suggest a minimum of two groups, as you've suggested: A Testing group and a Production group.

    You'll also find it appropriate, from time to time, to create temporary groups for short-term goals. For example, a technique I've suggested from time to time to deal with computers that should be excluded from receiving a specific update that all other computers should receive, is to create a separate group for the update and approve the update only for that group, or create a subgroup and explicitly remove the approval for that subgroup and move the computers into the subgroup until the update issue can be remediated, then move them back to the primary group where the update will automatically deploy to that computer.
    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
  • Tuesday, November 03, 2009 9:21 AMEric Zhang - MSFTMSFT, ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Hi,

    I want to see if the information Lawrence provided was helpful. Please keep us posted on your progress and let us know if you have any additional questions or concerns.

    We are looking forward to your response.

    Thanks