My client uses Configuration Manager for software updates and has been for a long time. It works well and they’re used to the workflow. As you may know, Configuration Manager uses WSUS to manage a lot of the heavy lifting regarding software updates and works just fine (well..most of the time). You shouldn’t try to implement another solution just because of the extra management that it brings unless your hand is forced. Let me tell you a story unless you don’t want to hear my ramblings and just want to download it now.
There once was a product called Cisco ISE that tested and remediated clients that didn’t meet a certain update baseline. This product, although, very functional and expensive was created by a team that didn’t believe that any other update delivery mechanism existed other than plain ol’ WSUS; not SCCM, not Altiris, notta; only WSUS.
Frank comments to Cisco like “we have SCCM and we can’t use it’s WSUS server directly because SCCM controls it” yielded ye but a confused look and instructions to “build the SCCM integration yourself” were given. Needless to say, I was not happy but what was I to do? So I conceded.
Next comes along MDT. Although I’m not real familiar with the process it seems that this product cannot use SCCM’s software updates natively either and must have it’s own WSUS server as well.
With two products needing a separate WSUS server yet one system (SCCM) with all the tested and approved software updates already what is a guy to do? We have two options.
- Check each update in SCCM, look at the WSUS console and manually approve each and every one.
- Spend a few days and create a Powershell script that approves all WSUS updates in SCCM on a recurring basis.
Which am I to choose? Hmm.. Automation wins every time!
Out of this circumstance was born the bouncing baby Sync-CmToWsusSoftwareUpdates.ps1 script. Although I found multiple people (Technet Blogs, Configmgrblog.com) already having their hand at solving this problem every one didn’t go far enough for me. Some were not matching updates 1:1 and all were only approving WSUS updates in SCCM so I decided (with permission from my client) to build a more robust and reliable script (IMO) with far more features.
This script has the following features.
- Approves all WSUS updates that are deployed (in any deployment) in SCCM
- Declines all WSUS updates that are not in SCCM (optional)
- Lists all updates in SCCM that weren’t in WSUS
- Logs all activity to a log file in CSV-format for easy parsing later
- Performs a WSUS sync from Microsoft Update if any SCCM updates could not be match (Optional)
These functions allowed me to get 90% of where I wanted to go. �You’ll see in the code that I also wanted to synchronize all approved classifications and products from SCCM to WSUS but being a practicing pragmatist I decided to let those go for now in respect for my client’s time. �These only need be set once in WSUS anyway.
This script has a single requirement and a few suggestions before you run it.
The WSUS 3.0 SP2 (the version I used) administration console needs to be installed on the machine you’re executing this script on. If you’ll be running this script on Windows Server 2012 you can simply run a one liner:
Install-WindowsFeature -Name UpdateServices-Ui.
If you’re on any other operating system you’ll probably need to download and install it. This will install all the .NET assemblies you need to query the WSUS server remotely.
- Remove permission from anyone to manually approve, decline or even breathe on the WSUS server. It’s not going to be a big deal if someone changes a few updates between syncs but it will take longer for the script to run.
- Set the WSUS server’s update source to Microsoft (or an upstream WSUS server that you’re sure has all the updates that SCCM has). You need as many updates as possible in WSUS so that you can match on as many SCCM updates as possible.
- Perform at least one synchronization from Microsoft Update on the WSUS server before you run this. We need all the updates possible on the WSUS server to match from SCCM.
- Synchronization set to Automatic in WSUS. Again, because we need all the update metadata in WSUS as possible, you need to sync from Microsoft often.
- Remove all automatic approvals. This may seem obvious but you don’t want any other outside process jacking with the WSUS updates that you only want to be synced from SCCM.
- Run this script as a scheduled task. If you really want to, you can put a sticky note on your monitor with a reminder to execute this script every day at 2 AM if you want but I’d use a scheduled task instead.
I’ve heavily commented the script and have added all the common PowerShell advanced function ninja stuff but there are a few things I want to mention before you go off breaking your…I mean TESTING!..this script first before you roll it into production.
Since I intended this script to run as a scheduled task it outputs nothing to the console and writes all activity to a CSV-formatted log file to allow you to do things like this. Don’t comment on this post and tell me I don’t know what I’m doing since I didn’t include any verbose logging. Instead, look at the log file, by default, in the same directory as the script.
If you’ve got thousands of updates like my client did, this log file will be enormous if you include all of the
Write-Log lines I have in here. �So, I’ve commented out a lot of the really verbose stuff to only give you the meat and potatoes. �However, feel free to uncomment out this stuff if you’re troubleshooting and are just curious which updates it’s actually syncing.
As always, if you use this and something’s not working please let me know. I spent a lot of time on this but nothing is ever perfect and I’d love the opportunity to improve upon it.