Windows Patching Assistant for SCCM Environment. An Alternative to traditional login and fix action.
Security Patching is a major part of an IT Admin’s Life. While Microsoft has provided a good bunch of tools to achieve automation, some degree of Non-Compliance always exist and would force manual intervention.
I have rarely seen 100% compliance with Microsoft’s System Center Configuration Manager (SCCM). So when I am asked to login to 30 something servers and get them patched within a given window, my day gets ruined. I had such plans to grab a cup of coffee, put my feet up and relax. Now, I have to login to each machine and open the Software Center and Install these patches manually and/or Reboot as required just to get the compliance up.
With my roughly 2 years of PowerShell experience, I came up with 3 separate scripts to achieve the most involved of tasks:
1. A script to monitor the SCCM patching progress (As visible in Software Center) and gather a bunch of other useful data to base decisions upon.
2. Another script to Install/Retry any straggling patches
3. Reboot Servers that need it [Eventvwr registers reboot to SCCM Client] with the option to Reboot by force[Eventvwr would register the User’s ID].
Eventually, with time, the need became more and more imperative. My team mates started using it too. So I decided it was time to go Pro. After about a week’s work learning GUI, I came up with this baby. I call it ‘Windows Patching Assistant”.
Windows Patching Assistant .exe version is currently available from the Download link above. I will update the .ps1 version in a short while.
a. Version 3.0 : No Credential Support.
b. Version 3.1 : Credential Support Added. [Can be used to manage machines on untrusted domains] [Recommended]
A screenshot is shown below. I haven’t had the time or the opportunity to test all the permutations and combinations of features (Some are still under development). So I make no promises about how well it would work on your environment. In fact, I am going to slip in a disclaimer.
Disclaimer: This is an application developed by me for personal use. If you want to use this, Do so at your own Risk. I will not be liable or responsible in any way.
Features that Work:
1. Monitoring SCCM Patching of Multiple Servers.
2. Individual Server Control [Install Available patches, View Update History, Force Reboot (Event will be Registered under UserID in Eventlogs)]
3. Automatic Installation of available Patches
4. Automatic Reboot of Servers ready for a reboot if patches are currently not waiting or installing.
5. Export results to csv file
6. Search on the Main Datagrid
6. View Update History and Installed Updates. The output is a standard PowerShell Out-GridView. This comes with a search field which is handy if you are looking for a specific KB.
7. Added the use of Credentials to Monitor and Manage servers on untrusted domains on version 3.1
I will constantly be updating the code when I get better ideas and the same will be updated in the Git Repository. For now, i will be working on developing the following features.
1. Software Center View.[A view that offers an experience similar to as directly viewing the software center of a machine.]
2. Viewing the SCCM Client Version #
3. One-Click RDP [For machines that has their login info populated on the input file]
4. Option to Restart SCCM Services on target machines
Trying to keep the overhead to a minimum without the use of a database. Involving a database could improve performance while deploying it could be a hassle. Using a file saved on disk with constant I/O could prove bad for performance.
HOW TO USE:
Input File: An input file can be generated from the tools menu>Export Template File. The FQDN column is mandatory.
The Domain user and Password column is optional. If you are running this app using an account that do not have admin permissions on target machines, you will run into access denied errors and will be shown in the monitoring screen. In that case populate this field with credentials of an account with admin permissions on the target machines.
Begin button will start the monitoring. Will prompt for the input file if not already selected using the browse button.
Once the monitoring is started, the data will start getting populated. the refresh time of the screen can be controlled by the up-down counter on the right side panel.
Double clicking a record on the monitoring screen will select it and activate the individual server control panel on the bottom. The gives you the ability to do micro management on that machine.
The “Enable Options” check box on the right side panel will grant you the ability to Push patches (if available to be pushed) and Reboot servers (if reboot is pending and no patches are installing/waiting) automatically on all the machines on the main monitoring screen. [Use with caution as this setting applies to all machines].
In case this is not running on your machine, you may have to set the PowerShell Execution policy correctly. Usually, setting it to ‘unrestricted’ would work.
For the Advanced User:
The Application’s GUI was developed using Sapien’s PowerShell Studio. I will update the Code in GitHub shortly along with the .ps1 version.
For Version 3.0: The Script should be run using an account that has admin permissions on the target set of machines. I usually login to a machine in the same domain as the target servers with a privileged account and run from there. Runs seamlessly.
For Version 3.1: Can be run from anywhere as long as credentials are properly populated in the input file.
Regardless of where this is run from, the performance will be affected by factors like proximity to the target servers, the current load on the network, current load on the target servers, the efficacy of the machine you are running this on… etc. On a standard corporate environment, this shouldn’t be noticeable.
The Script connects directly to the target machines through PowerShell CmdLets and WMI Queries. It does not use the SCCM Server at all. This is only an alternative to managing the servers over RDP or Direct Console.
The script keeps the main Datagridview updated every ‘x’ seconds (a value that the user can control) using an Infinite Loop. Because it was impossible to know how long a user would have to leave this thing running, Infinite loop was the best option. It can be terminated with the ‘Stop’ button.
Using an Infinite Loop comes with its own Caveats. Using a short refresh Interval on large number of systems could cause the script to gradually increase the amount of memory it consumes. Like I said, I am not a very good programmer. But I have tried to implement some sort of garbage collection. However, using a higher refresh interval lets the OS do its own memory management and keeps the App’s memory usage in check. Unless you are impatient, I don’t see the need to keep a refresh interval lower than 60 seconds. The default is 10 seconds.
Not all of the code is mine. I apologize, I do not remember where they came from. I never kept track of it, was so long ago. For beginners like me has to scour the world wide web to find their way. I will take solace in the idea that at least I am resourceful. I thank all of my uncredited indirect contributors. I will also thank StackOverflow and Microsoft Technet for the unwavering support they provide to the community. I hope this script serves some purpose for the community.
If I am to get better, I must be willing to listen to what others have to say. I would be happy to hear from you about:
1. Does the Application Serve the Intended purpose?
2. Any bugs?
3. Need any new features or modifications to existing ones?
4. All constructive criticism
5. Any other App requests