Monthly Archives: May 2017

Config Migration Tip – Use PowerShell to export and import Security Roles

I have been doing a lot of migration prep work and wanted to share a big time saver for moving security roles. You can use PowerShell to export and import security roles. If you have lots of custom roles this is a huge time saver.

To export all of the custom roles

After you collect all the xml files for the roles and are ready to import them use this


Restoring SMS Registry from the SCCM Site Backup

Well I had an interesting morning. For the past couple of weeks I have had to repair several site servers where key ccm and sms registry key had been deleted. At 1st it appeared that a client repair had gone bad and killed the keys. But this morning it was track down to someone running a client repair script incorrectly. They were targeting a remote client but the script was removing local registry keys. However today it happened on a primary server and we were looking at a site recovery to fix it. What follows may not be supported but it worked for me; if you are looking at site recovery worst case is this does not work and you will need to do the recovery anyway.

On this system the script attempted to deleted the HKLM\Software\Microsoft\SMS key and all sub keys. Most were still present because the SCCM services and components had them open and the delete failed. But a lot were missing! So we when looking for possible backups. I attempted to load the backup copy of the Software hive from windows\system32\config\regback but that was unsuccessful. Next I turned to the System Backups but the recovery plan for this server was to rebuild and then restore the application drives so the OS drive was not backed up. Well the site recovery was looking more and more like the solution. As I checked that backup from the site maintenance process the file \SiteServer\SMSbkSiteRegSMS.dat file reminded me that the back up includes the HKLM\Software\Microsoft\SMS key. So I took a peek at the DAT file in notepad and sure enough it had the registry info. After loading the DAT file as a custom hive in regedit I exported the custom hive and the sms key. (Always remember to back up the registry you are about to change. Got to remember to explain this to the script author 🙂 ) In the reg file for the custom hive I updated the path so that all of the key were for HKLM\Software\Microsoft\SMS. After ensuring that all of the SMS services where stopped, the custom hive reg file was imported into the registry. Some checking to ensure thing like server names and site codes where correct and the sms services were restarted. After celebrating the lack of red in the server logs, the site was declared functional and I snuck off for a nap.

Quickly get system stats for Software Update Point\Management Point

Like most of us out here is SCCM land Patch Tuesday generally means that you will see a performance for the WSUS app pool that you will need to ensure does not lead to issues. Here is a quick PowerShell command  to get the CPU utilization and the current connections the websites. I use it for monitoring both management points and software update points. Because it is using performance counters it is easy to add other counters that are relevant to your own environment.

get-counter supports remote systems with the -ComputerName parameter so to check Multiple systems use


Software Updates not applying after a Site Reset

There is a long story about why that I have not had time to post about, one of the SCCM environments had to be recovered with a Site Reset. The reset was successful and everything appeared to be functioning normally. The next day the patching team started to report a few clients not applying patches. Now this is not unusual, there are always some clients that have issues, but by the end of the day it they were reporting that it was all clients.  The bulk of the clients were reporting  ‘Assignment ({xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx}) already in progress state (AssignmentStateDetecting). No need to evaluate UpdatesDeploymentAgent’ in the UpdateDeployment.log. Gabriel Alicea has a great post that solved the issue –

The moral of the story is that the Site Reset changed the version of the wsus catalog to 1 on the primary server but the software update point and the database had a different number. Stopping the services on the primary,updating the registry values, restarting the services and then running a sync allowed the clients to correctly evaluate the scans and apply patches.