Selecting Your Test Systems

Selecting your test systems is a question of what you have in your environment at your disposal.

In the past, people have always criticized those who have done ‘testing in production’, going even as far to make it a meme.

If you are one of the lucky few who have a true test environment, one that you have the same hardware, same drivers, same applications installed, etc., that would be where you would want to test the updates.

If you are like most small to medium sized businesses, we recommend that you ‘test in production’. It has a negative connotation because of the history of implementation and why the memes were created. When implemented in a ring deployment, you have a controlled release cycle that you can release updates, watch what happens, deal with any issues that crop up, and then choose to move forward or halt until the issues are resolved.

Microsoft has adopted this ring-based deployment in their Windows Update releases for feature upgrades of Windows 10 & 11. They release the feature upgrade to a small set of tested hardware and if they start receiving diagnostic data indicating that there are issues, they can pause deployment and figure out what has caused the issues and how to resolve them. Then they resume deployment to the next ring.

Selecting your Test Workstations – Ring 1

For selecting which workstations are part of the test group, try and get at least one system from every business process (department). Try to have a good mix of applications and hardware, and if you are running multiple operating systems, try to include a mix of operating systems to create a well-rounded test group. These users do not need to know that they are part of the test group, but as being transparent and open is a good thing, it would be best to let them know so that if they have any issues, they can let you know. Also, if you can, try to pick the NON-technical users more often than the technical ones. Why? The non-technical users are the best ones to test with as they break lots of things lots of times by not knowing what to do and playing around with it. Of course, have a couple of the more technical users for the advanced testing, but don’t exclude the non-technical ones. Add these computers as members of the “ACL_GPO.WSUS – Workstations – Ring 1 – Test-Workstations_Apply” group.

Default to Automatic for Broad Deployment

With workstations, it is best to default to broad deployment. This way you select your test systems specifically and only those get updates first. Broad deployment will only receive updates when they have gone through your testing procedures.

Selecting your Test Servers – Ring 1

For selecting your test servers, pick a few servers that are not critical business processes (maybe like a CA/Subordinate CA, a print server, a KMS server, etc) and that can restart automatically after the installation of the updates. Add these server computer objects as members of the “ACL_GPO.WSUS – Servers – Ring 1 – Test-Servers_Apply” group.

Selecting your Ring 2 Servers

For selecting your ring 2 systems, choose systems that have a little bit more importance in your network and can restart automatically after the installation of updates. These servers should also include one of your Domain Controllers (DCs) as they can be restarted automatically. Make sure that you do not put all your DCs into Ring 2 but split them up to include them in ring 3 so that they restart at different times. Add these server computer objects as members of the “ACL_GPO.WSUS – Servers – Ring 2 – Test-Servers_Apply” group.

Selecting your Ring 3 Servers

Rings 2 and 3 are released during the same phase but are applied at different times so that they restart at different times. For selecting your ring 3 systems, choose systems that need to restart at a different time so that high availability is maintained. Add these server computer objects as members of the “ACL_GPO.WSUS – Servers – Ring 3 – Test-Servers_Apply” group.

Default To Safe – For Servers Ring 4 is Manual

If we add new servers, or just forget to add them to a ring, we want to make sure we cause the least amount of trouble which is why we default to the manual installation of updates and the manual restarting. These servers that absolutely need to be in this ring are the systems that are of the most importance or have a requirement that a software must be opened manually after the restart (unfortunately some software still does not run as a Windows Service and must have an interactive session opened to work). These can include virtual machine (VM) host systems, application servers, or systems that you must hand-hold to ensure they come back up properly.

The Approvals Process

Without Drivers

1. Click on the view “All Updates Except Drivers” (or “All Updates” if you do not have the Drivers classification selected) and make sure the selected Approval is set to Unapproved with a status of Failed or Needed. This list will show you what updates you need to take care of.
2. Select the ones you wish to approve for testing, and right click on the selection and choose Approve. On both the “Test – Servers” and “Test – Workstations”, select the down arrows and choose “Approved for Install”. Leave everything else as “Keep existing approvals” and click OK.
3. This will now download the physical update files to the WSUS Server and present them to the clients the next round that they check for updates. You can monitor the download process by clicking the server’s name in the left navigation list. It has a section on the right column of the display called “Download Status”
4. Only those machines in the test groups will see these updates you have approved. Do your testing; whether it be opening applications, or just installing, restarting and waiting to hear of any issues. You may choose to wait a few days, or a week. It is suggested to seriously consider shortening your testing to a week or less – preferably less, especially on those critical already exploited or high CVSS score security updates.
5. After testing is completed, go into the “Test – Workstations” update view and select the Approval of “Approved” and the status of “Any” and click Refresh. You will now see all approved updates to your “Test – Workstations” group. You can then select the updates that have passed your testing stages, and right click them and click Approve.
6. We recommend that you approve these tested updates to the “All Computers” group at the top of the tree and select “Apply to Children” or press CTRL-C. — Why? — You may have some ‘Servers’ that are running Windows 10, and/or other client-based systems that you are using as servers. Subsequently, if you decide to create more computer groups later for whatever reason, the updates will apply to those groups automatically by way of the inheritance tree. The same goes for Servers – approving to “All Computers” group and selecting “Apply to Children” or pressing CTRL-C.

Only updates that are relevant to each individual system and ONLY those that are deemed ‘needed’ updates will be installed. You don’t have to worry about a Windows 10 update applying to a Server 2012 system because WSUS takes care of knowing what is needed and what is not.

With Drivers

Drivers are usually for workstations, however there can be drivers for servers too. The Drivers unfortunately do not supersede each other and because of this, it is a VERY MANUAL process. Many driver updates will come in DAILY. It is not unusual to have anywhere between 40 and 1500+ driver updates that will synchronize to WSUS. It is a lot!

1. Click on the view “Drivers” and make sure the selected Approval is set to Unapproved with a status of Failed or Needed. This list will show you what driver updates you need to take care of. This list may confuse you as there may be MULTIPLE drivers that look exactly alike, but only apply to a select few systems and then another one that looks the same applies to more. There are also many drivers that have the date in the past (1970).
2. Select the ones you wish to approve for testing, and right click on the selection and choose Approve. On both the “Test – Servers” and “Test – Workstations”, select the down arrows and choose “Approved for Install”. Leave everything else as “Keep existing approvals” and click OK.
3. This will now download the physical update files to the WSUS Server and present them to the clients the next round that they check for updates. You can monitor the download process by clicking the server’s name in the left navigation list. It has a section on the right column of the display called “Download Status”
4. Only those machines in the test groups will see these drivers that you have approved. Do your testing of the drivers. Usually this is just installing, restarting, and waiting to hear of any issues. You may choose to wait a few days, or a week.
5. After testing is completed, go into the “Test – Workstations” update view and select the Approval of “Approved” and the status of “Any” and click Refresh. You will now see all approved updates to your “Test – Workstations” group. You can then select the drivers that have passed your testing stages, and right click them and click Approve.
6. We recommend that you approve these tested driver updates to the “All Computers” group at the top of the tree and select “Apply to Children” or press CTRL-C. — Why? — You may have some ‘Servers’ that are running Windows 10/11, and/or other client-based systems that you’re using as servers. Subsequently, if you decide to create more computer groups later for whatever reason, the updates will apply to those groups automatically by way of the inheritance tree. The same goes for Servers – approving to “All Computers” group and selecting “Apply to Children” or pressing CTRL-C.

Decline Installed Drivers with Newer Versions

7. Click the Drivers update view and make sure the selected Approval is set to Approved with a status of Installed/Not Applicable.
8. Sort the list of drivers by Title by clicking on the column heading ‘Title’
9. Review the Title column for multiples of the same name. Look at the version numbers and look at the NEEDED column. This will tell you if the driver is still needed by any clients.
10. If there are multiples of the same version, Decline the OLDER of the versions.

Be aware that it is possible that different versions are sometimes completely different drivers. An example would be if an Intel Driver is version 29.35.22.105 and another Intel Driver with the same title has version 30.21.56.301. These are 2 different drivers for 2 different types of hardware. These specific ones do not actually update each other (meaning v30 will not install over v29). In these cases, you will have to look at the Major, Minor, Build and Revision numbers to see if there are any that are any newer versions so that you can decline the older ones. Unfortunately, there is no easy way to know what you need to decline and what you should keep; you will have to learn what your set of driver updates will look like.

Only updates that are relevant to each individual system and ONLY those that are deemed ‘needed’ updates by each client will be installed. You do not have to worry about a Windows 10 update applying to a Server 2012 system because the client’s Windows Update Agent takes care of knowing what is needed and what is not.