itwatchhelp
asked on
WSUS Approval Groups
When configuring Approval Groups inside of WSUS, the former administrator did it by Operating system, there was one Approval group for each OS:
Windows Server 2008 R2
Windows Server 2008 x86
Windows Server 2008 x64
Windows XP x86
Windows XP x64
...
The test groups were the same way, except prefixed by the word test. This results in a lot of working sorting all of the updates down by the OS they are intended for. Further, multiple approvals are needed when a single update (.NET Framework) is intended for multiple OS (XP, Server 2003).
What is the best practice? From my research I believe (and want) to set it up in the following:
Servers
User Machines (Desktops Laptops)
Server Test Group
User Machines (Desktop Laptops) Test Group
And then just mass approve everything to the Test groups, if nothing breaks, then approve all to the regular groups.
I am looking to see what is best practice in how to set this up. Do I do it by OS, and if so why? It seems like a lot more work to set it up by OS.
Windows Server 2008 R2
Windows Server 2008 x86
Windows Server 2008 x64
Windows XP x86
Windows XP x64
...
The test groups were the same way, except prefixed by the word test. This results in a lot of working sorting all of the updates down by the OS they are intended for. Further, multiple approvals are needed when a single update (.NET Framework) is intended for multiple OS (XP, Server 2003).
What is the best practice? From my research I believe (and want) to set it up in the following:
Servers
User Machines (Desktops Laptops)
Server Test Group
User Machines (Desktop Laptops) Test Group
And then just mass approve everything to the Test groups, if nothing breaks, then approve all to the regular groups.
I am looking to see what is best practice in how to set this up. Do I do it by OS, and if so why? It seems like a lot more work to set it up by OS.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The system will only be offered updates that are relavent to it. I.e. if your Production desktop group consists of both X86 and x64 you would need to look at each type (x86/x64) in this group and approve the updates for this type. The common updates for office and the like need only be approved once.
Similarly, by group the test, you would need to approve updates when looking through the workstations in the group and the updates it needs.
A deny is not advisable, if a patch presents as a conflict, simply do not approve it. If you decline it will never be offered and may cause issues down the line while the vendor of your customer with which this patch conflicted may release an update to correct this issue.
I usually deny updates for systems that I do not have. i.e. there is no reason to keep an update list of itanium if you do not have such equipment., etc.
Similarly, by group the test, you would need to approve updates when looking through the workstations in the group and the updates it needs.
A deny is not advisable, if a patch presents as a conflict, simply do not approve it. If you decline it will never be offered and may cause issues down the line while the vendor of your customer with which this patch conflicted may release an update to correct this issue.
I usually deny updates for systems that I do not have. i.e. there is no reason to keep an update list of itanium if you do not have such equipment., etc.
ASKER
I apologize for the late addition
Do I need to split my approval groups based upon architecture:
Do I need
Test Workstations x86
Test Workstations x64
and ONLY approve x64 for the x64 group?
Or can I just have
Test Workstations
And drop and approve patches and workstations that are both x86 and x64 in there?
Do I need to split my approval groups based upon architecture:
Do I need
Test Workstations x86
Test Workstations x64
and ONLY approve x64 for the x64 group?
Or can I just have
Test Workstations
And drop and approve patches and workstations that are both x86 and x64 in there?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
ASKER
WSUS Configured to email when update changes occur: No, we are currnelty not getting notices from the WSUS server.
You mention having a test and a normal split along architecture lines (x86 and x64). Why is that?
Ideally I would like to simplify our whole setup to just:
Test Servers
Test Desktops
Production Servers
Production Desktops
And just be able to mass approve to the test groups, let them patch, watch for problems, and if there are any I would then deny that patch for the production push.
I guess I am also wondering if there is any harm in approving, lets say an itanium, or a x64 patch for a nonitanium, x86 server. I dont think so, since as the Neilsr indicated, the server wont request that. THe previous administrator swore up and down that doing this could cause the x86 server to go and install x64 patches or itanium patches and thus cause a lot of problems.