- 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!
“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.”
I respectfully disagree with this statement. If you configure this setting to ‘not configured’, the configuration manager agent will appropriately configure local policy. If that’s not the case, please let me know.
You are correct that it will work by setting not configured – the client will write the configuration to the local group policy for that machine.
In the past, I’ve had to troubleshoot problems where this setting was set it multiple places or local group policy was disabled. I’ve found it a lot easier to configure the setting so that everything is seen in the GPMC.
Great write up on getting SCCM configured in an organized way. Thank you for sharing. I have one question though…how are you creating your Device Collections? I really can only choose All Systems from the Limiting collection section. Did I miss a step somewhere else?
You will want to right click on Device Collections and create the Software Updates folder structure that you see in the last screenshot. I then use the OS queries that are mentioned in the last of the articles to dynamically create collections.
I’m just having some issues at the moment and firstly I want to tell which service is providing updates. Am I right in thinking that if I see the shield/blue install icon in the task bar then it’s the old wsus but if the software centre talks of new updates then sccm is handling them?
Currently I’ve also got an annoying problem where my machine is trying to install the same update again and again (an endpoint definition update). First it succeeds and them a moment later tells me I have a new update to install (invariably the same one).
Any ideas on this welcome…
Thanks,
Richard
Hi Richard – If software center is showing the updates, SCCM is handling them.
Did you get the endpoint update fixed? Clearing the cache on a client has fixed this issue for me in the past.
Hi – thanks for the WSUS clarification. I’m still getting the same endpoint trouble. When you say clear the cache – where do I need to go for that?
Thanks.
Open up the Configuration Manager Properties on the client computer. This is in control panel. Select the cache tab – configure – clear.
Reboot and see if the update installs as deployed.
hello, thanks for the article !
I have a question about WSUS issue .
Today I am using local wsus on server 2008 r2 64 bit and would like to migrate the activity to new SCCM 2012 I had already installed , do you know where I can find any article are explain how to do that ?
Thanks.
David – This series will teach you that.
Hi, thanks for the article, but I can’t seem to understand where exactly we specify the SCCM to use the existing WSUS server. From what I see so far, SCCM does not even know the name of the WSUS server. Do we have to install an SCCM client to the WSUS server before doing this?
You will want to use WSUS on SCCM – this article shows how you can move from an standalone WSUS to a WSUS managed by SCCM.
Hi
Can you explain the test group query or, how to create ? Thank you!
Create a collection and choose direct as the method. Then add individual computer names to that group. This group allows you to deploy to a smaller collection first to test updates.
Does that mean I need to create software update group for each MS product like MS office, visual studio, exchange server, SCCM itself and so on and also create collections contain the computers that have these products installed>
I am a bit confused about software update points. If I have an office in City1 and another in City2 do I need a SUP in each locations for my clients to be able to get updates? and if I need a sup in each location does that mean I will need WSUS at each location or will one WSUS suffice?
Baybars – install WSUS service on primary SCCM server