Auto Populate Patch Testing Group

Issue

This month is a big month for Microsoft patches. With that said, have you ever had a patch blow up in your face or cause your pet to implode? No, never, they always work you say. For me unfortunatly I need new pets regularly... So I have a Patch Testing Group (PTG) that does that, test patches. In other words they get the patches before the rest of the fleet. Managing membership in PTG is cumbersome. Someone leaves the company, they are out, so we have to replace them. Computer is acting up and gets refreshed, they are out, so we replace or readd them. You get the idea. In an organization of many tens of thousands of systems it takes time to manage membership. If not managed, the PTG can go down to zero.

Background

MS releases patches on the second Tuesday of the month generally (excluding zero day) as we all hopefully know. Most organizations wait a week or more before applying to the fleet so they can test and mine is not all that different. To address it via a PTG, we created two AD Groups. One for the user of the machine and one for the machine itself. The user AD group is used for communications and the machine group is for the ConfigMgr collection and subsequent advertisements.

I always believe a PTG should NOT include IT staff and instead have a good representation of the user base. IT cares about what we care about and the users care about what they care about. IT isn't able to test some random accounting app that unknowingly takes advantage of a bug in the OS, which MS happened to patch this month. Multiply that by the thousands of apps floating around my organization and IT is unable to test every iteration based on the phase of the moon.  So we turn to the experts of all that other software, the users themselves. Thats PTG.

Resolution

Managing PTG has always been a pain. For our size, our InfoSec team and I feel a thousand systems is a good representation of our fleet. I had Cory Becht, (who WAS our ConfigMgr admin, he was stolen by MS, grumble grumble... :) Now hiring! ) write another wonderful script based on my quirky ideas before he left.

What it does is looks in ConfigMgr for workstation machines that were deployed in the last 30 days, and if the primary user is identified (you are using UDA right?), it will randomly decide to put that person and machine into PTG. I refer to this process as winning the lottery. It then sends an email to the user telling them they won and what that means and make getting out slightly annoying process. It also sends a summary email to the IT contact of who was added.

There are additional controls in place as well. For example, each run can be limited to how many are added as well as the max to allow (1000 in this case). This way the helpdesk is not overloaded with removal requests or questions over what they just won. We can comfortably bring PTG up to where we want it. I have the script running on a weekly basis.

There are a few things its lacking that will go into a new version:

• Ability to blacklist people, VIPs for example, who should not be in here. 
• Not re-add anyone who requested out
• If a machine is removed from AD for whatever reason, the person should be removed. 
• Support HTML for the user email for logo etc so its prettier.

Configuration

I wont cover setting up a PTG here, only the ongoing management of membership in it. As mentioned earlier, we have two AD groups for PTG use so the script revolves around that.

• Patch Testing Group Users
• Patch Testing Group Computers

One holds users and the other machines. The users is a DL that gets notification emails and the Computers group is tied to a Collection in ConfigMgr to get the patches early.

There is an EmailToUser.txt text file that is sent to the user when they "win". Customize as your environment needs. The script itself has several variables at the top needing to be customized to your environment. Should be mostly self explanatory but still allows some granular control. Items worth expanding:

• blnTestRun - Test mode to make sure its running correctly before you let it loose. 
• blnEmailUser - Allows you to tell the users they won or not.
• blnEmailTestUser - Lets you BCC the helpdesk to the user emails or not. 
• strEmailsFromTech and strEmailsFromUser - Lets you use an established "from IT" mailbox but the techs see its coming from the script.

 blnTestRun = True 'If True, the computer account and user accounts will not be added to the group. Emails will not be sent to the user either.  
 blnEmailUser = False 'do you want to email the end user that their computer has been added to the patch testing group? Test Run variable has to be set to False otherwise this is skipped.  
 blnEmailTestUser = False 'If set to True then the test email account will receive the indivdual emails as well  
 strPTGNameUser = "PTGTestGroupUsers" 'Name of group to contain user accounts  
 strPTGNameComputer = "PTGTestGroupComputers" 'Name of group to contain user accounts  
 intQuantity = 1000 'maximum number of computer accounts in the group  
 intMaxAddLimit = 50 'maximum number of computer accounts to add each time the script is run  
 intMinBuildDays = 30 'number of days past build date to look at for adding to the group. Make sure that User Device Affinity has had enough time to generate this  
 strEmailFile = ScriptPath()&"\EmailToUser.txt" 'path to the standard email template  
 strSMTPServer = "smarthost.mycompany.com" 'SMTP server to use  
 strEmailsTech = "[email protected]" ' separate with semi-colon and space.  Ex: "[email protected]; [email protected]"  
 strEmailFromTech = "[email protected]" 'From address that goes to email addresses that receive test and summary messages  
 strEmailFromUser = "[email protected]" 'From address that users will see  
 strEmailTest = "[email protected]" 'Test email account that will receive the individual emails  
 strEmailSubjectUser = "Your computer has been added to the patch testing group" 'Subject in email that goes out to users  
 strSQLServer = "SCCMDBserver.mycompany.com" 'FQDN of SQL server hosting ConfigMgr database  
 strDB = "CM_DB" 'DB name of ConfigMgr  

When you first run it, create two test groups in AD and configure the script and test. It will send summary with what it wanted to do. Then set blnTestRun to False but leave the blnEmailUser false, maybe set blnEmailTestUser to true. It will add users and computers to the test group but notify the techs only. Once its all validated to be working in your environment, change to your prod groups and enable blnEmailUser if you want. Then setup Collections and adverts and you have automatic PTG population.

Update 11.13.2014

Found a couple minor spelling errors that impacted the user email so corrected version below.

Download

This script is provided as-is, no warranty is provided or implied.The author is NOT responsible for any damages or data loss that may occur through the use of this script.  Always test, test, test before rolling anything into a production environment.

You can find the script referenced in this post as well as a sample enduser email here. You will need to tweak them for your environment as shown above.

-Kevin