Now, depending on how you have your network, you may want to apply the other GPOs to OUs or create Security Groups and make computers members of them instead. Either way works, or a combination of both. I will explain a combination of both.
Link the “WSUS – Location” GPO at the domain level. This will ensure that all devices attached to the domain will look at this WSUS Server for updates. As you build out your network, you can create multiple WSUS – Location GPOs for all of your different sites that have downstream WSUS Servers and apply them at the Site Level (hidden by default). This way when a user travels to another site temporarily or permanently, they will receive updates locally from the downstream server rather than traversing your site links. If you have a large site, consider splitting up your WSUS Deployment to include multiple downstream servers within the same site. This way you can combine a GPO that is scoped to a domain local group that will contain systems that will use this server over the upstream server within the same site. With GPO ordering, linking to sites, and scoping to domain local security groups, you can develop a WSUS Deployment to scale the largest environments. In addition, you can use load balancing and high availability options for WSUS by utilizing a shared remote SQL database (although there’s a better alternative using downstream servers vs a high availability node. Do you really think a Windows Update store has a reason to be high availability?).
If you have your computers in a single OU or single OU Structure, apply the ‘WSUS – Workstations’ GPO to this OU.
If you have your servers in a single OU or single OU Structure, apply the “WSUS – Servers” GPO to this OU. (Don’t forget the Domain Controllers OU)
Configuration GPOs for Test Systems
First you’ll want to create at least these 4 groups (and yes, you want to create a deny – it is always good for troubleshooting if you need it and much harder to figure out where to remove the computer or GPO from if you don’t have the deny group. Don’t forget, deny takes precedence over everything so if you add a group to deny for troubleshooting, you’re 100% guaranteed that it will not be applied.)
ACL_GPO.WSUS – Workstations & Test_Apply
ACL_GPO.WSUS – Workstations & Test_Deny
ACL_GPO.WSUS – Servers & Test_Apply
ACL_GPO.WSUS – Servers & Test_Deny
In either case, you may have a group of test computers and test servers to initially test updates on. This is where these groups will come into play.
On the GPO – “WSUS – Workstations, Test – Workstations” in the Scope tab, remove Authenticated users and add “ACL_GPO.WSUS – Workstations & Test_Apply”. Go to the Delegation tab and add Authenticated Users with Read permission. Click on the Advanced button and add “ACL_GPO.WSUS – Workstations & Test_Deny” with deny permissions on “Apply group policy”
On the GPO – “WSUS – Servers, Test – Servers” in the Scope tab, remove Authenticated users and add “ACL_GPO.WSUS – Servers & Test_Apply”. Go to the Delegation tab and add Authenticated Users with Read permission. Click on the Advanced button and add “ACL_GPO.WSUS – Servers & Test_Deny” with deny permissions on “Apply group policy”
If you are going to be testing ‘in production’ Apply the 2 “WSUS – Workstations, Test – Workstations” and “WSUS – Servers, Test – Servers” to the same OU that applied the ‘WSUS – Workstations’ and ‘WSUS – Servers’ to respectively.