- SmartDeploy: Rethinking software deployment to remote workers in times of a pandemic - Thu, Jul 30 2020
- Outlook attachments now blocked in Office 365 - Tue, Nov 19 2019
- PolicyPak MDM Edition: Group Policy and more for BYOD - Tue, Oct 29 2019
System Center Configuration Manager (SCCM) can bring Windows Update management to a whole new level. It includes dozens of reports, fine-scheduled installation schedules, and easier troubleshooting methods. In this series, we will be working with an existing SCCM setup running SCCM 2012 R2. Like many organizations, our WSUS infrastructure existed before our SCCM implementation, and we are now looking at unifying the two.
Configuring the SCCM software update role
To get started, ensure that the WSUS role is installed on your primary server. If it isn’t, add the Windows Server Update Services role through Server Manager and accept the defaults for the role installation.
The WSUS role installed on our SCCM primary server
If you change any option on the Web Site Selection window (such as the port), be sure to note the changes. They will be needed when you reconfigure your Windows Update Group Policy settings. You don’t need to go through the additional WSUS configuration wizard.
Update configuration won’t be done in the WSUS management console. Instead, launch the Configuration Manager console and navigate to Administration – Site Configuration – Servers and Site System Roles. Right-click your primary server and select Add Site System Roles.
Adding a new role to our primary server
In the Add Roles Wizard, proceed past the first two pages. Under Role Selection, select Software Update Point. Continue through the wizard until your reach the Classifications page. Most organizations will choose all classifications or all classifications minus tools. With your classifications selected, head to the Products page.
To prevent update bloat, be careful to select only the Microsoft products that you currently support. If you are unsure if older versions of Office or operating systems exist, you can create collections in SCCM later to query for this information. Go ahead and finish the Role Wizard.
You will need to deploy updates for new products added to your environment (for example, a new operating system). To change the products or classifications that are deployed, navigate to Site Configuration – Sites - Configure Site Components. Select Software Update Point in the dropdown menu to edit these settings.
Adding additional product updates for the SCCM software update point
Before we leave the SCCM console, select Client Installation Settings (on the current Sites window). Under Software Update-Based Client Installation, select Enable software update-based client installation.
Group Policy changes needed for SCCM update management
Any environment currently using WSUS also uses Group Policy to configure update installation settings. These administrative templates are found under Computer Configuration/Administrative Templates/Windows Components/Windows Updates.
You will need to edit your existing Windows Update GPO to point to your SCCM primary server. Launch the Group Policy Management Console and navigate to the location above. Select Specify intranet Microsoft update service location.
From here, you have two choices: you can add your primary server and port name, or you can change the Group Policy setting back to Not Configured and allow the SCCM client to configure the correct server and port. Most organizations go with the first option because Group Policy overwrites the SCCM setting. Once you make your switch over to SCCM, you can set any other Windows Update Group Policy settings to Not Configured.
Syncing and deploying an update from the software update point
Head back to the SCCM console and navigate to Software Library – Software Updates – All Software Updates. On the Home tab, select Synchronize Software Updates.
A successful update synchronization on our primary server
This initial synchronization can be a bit slow if you are syncing across many categories or products. While we wait, head to Assets and Compliance – Device Collections. To keep update groups manageable, create a new folder named Software Updates. From here, I prefer to create a subfolder for each operating system or product (as seen in the picture below).
Software Update folders for each OS that we support
Within each folder, create two collections. The first collection should be a direct rule collection and should include the words “Test Group” in the name. To this collection, add specific machines that you have easy access to. Virtual machines make good candidates.
The second collection should populate on a query that includes certain operating systems. Two common OS queries are below. The first query will include all Windows 8.1 machines. The second query will grab any Windows 7 machines.
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_OPERATING_SYSTEM.Version like "%6.3%" and SMS_G_System_OPERATING_SYSTEM.Caption like "%Windows 8.1%" select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_OPERATING_SYSTEM.Caption like "%Windows 7%"
The end result should look like the screenshot above. In this guide, we configured WSUS and SCCM for update synchronization. We changed the required Group Policy settings and created a granular update collection hierarchy.
In our next post, we will look at automatic deployment rules, how updates actually install, and how to configure update schedules. If you have any questions or issues, leave a comment below!