We’ve been deploying Microsoft updates with System Center Configuration Manager for a few months now. Each month we get a little better at the process and trust the system more. After approving each month’s patches, I kept finding myself logging into my servers to see if they had pending updates ready to be deployed at the next maintenance window. Logging into each server doesn’t scale, so I needed to find a way to automate the process using PowerShell.
After using a search engine I was able to find the correct WMI class that I could use to query for SCCM client software updates.
Description:Install thisupdate toresolve issues inWindows.Foracomplete listing of the issues that are included inthisupdate,see the associated Microsoft Knowledge Base article formore information.After you
install thisitem,you may have torestart your computer.
If you work with System Center Configuration Manager (SCCM) you will be familiar with the number client actions that you can execute. Some of these actions are used more often than others, and learning what each of them do is for another blog post.
In our quest to roll out automated patching with SCCM we found that we often needed to run these various actions to get the SCCM client to check back in for new policy and check for pending updates. After logging into a handful of computers to open the Configuration Manger client applet from Control Panel to perform a Machine Policy Retrieval and Evaluation Cycle, I had to stop myself and find a faster way.
“What if I could use PowerShell to do this for me?”
I started like I normally do trying to find a SCCM client module with built-in cmdlets, but that path led to futility. Thankfully I found @adbertram wrote a PowerShell module that could execute the proper WMI method for the client actions. I immediately downloaded the code and started to try it out. I found one problem: the functions only accepted a single computer name at a time. I asked Adam about it. He told me to go ahead and update the code, and do a pull request on Git. I said I’d be glad to, pretending I knew how to do any of that Git stuff. After updating the code and performing my first Git pull request, we now have a SCCM client module for invoking client actions on multiple computers.
I’ve been working on a project to roll out automated patching to the servers in our environment. We have been using a combination of group policy and WSUS, which is a great solution, but it doesn’t allow for multiple maintenance windows. Since we are primarily a Windows shop we chose to use System Center Configuration Manger (SCCM) as our solution. If you’ve worked with SCCM you know that “it’s a full time job.” So over the last few months we’ve been carving off some servers from our WSUS and moving them to SCCM for patching. During the changeover we needed to verify if the server was actually talking to SCCM instead of our existing WSUS infrastructure. For the first few servers I logged on and launched regedit.exe to look at the policy key HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate. After doing this two (too many) times I realized this wasn’t going to scale. I put together a PowerShell script to read the registry keys we needed from one or more remote servers.