Month: August 2013

Had an ‘interesting’ day at the office yesterday – one of our SCCM administrators had pushed the SCCM client to a long list of clients by mistake.

Actions we took to halt any further depoloyments this were as follows:

1. Blocked SCCM site server to client subnet traffic using Windows Firewall.
2. Deleted files from the ccrretry.box invbox

The following reports allowed me to identify whom had performed this and to what machines:

• Reports | Client Push | Client Push Installation Status Details
• Reports | Status Messages | Audit | All audit messages for a specifric user

The latter report was run against all users, looking for MessgeID 30108 – as outlined here, this releates to client push.

The ccm.log will help you understand whether further deployments have stopped – meaning you can re-open the Windows Firewall.

I recently had a requirement to facilitate email notifications of Task Sequence Successes and Failures using Site Status Filters. This process is fairly straight forwards however there is one caveat with all of the guides I found online – if you’re using Unknown Computer support all of the email notifications will use the _SMSTSMachineName Task Sequence variable, which will be set to MININT-<XXXXXX> – this rendered this reporting method effectively useless within the environment I was looking to implement this solution within. However I found a solution/workaround for this issue…

Solution Summary

During the Task Sequence:

1. Map a network folder on the Site Server; I created a Mapping$ share and dedicated service account to write data to this share.
2. Create a “name mapping” comma-separated text file that contains the _SMSTSMachineName and desired name which is populated in the OSDComputerName Task Sequence variable. This file is always named <_SMSTSMachineName>.txt
3. Using the Status Filter execute a PowerShell Script that checks for the name mapping file and, if found, emails the success or failure message based upon the desired name. If not found then the email will contain the value of _SMSTSMachineName.

Detailed implementation steps are below.

If you want to leverage USMT and ensure you can support Office 2013 in the migration process you’ll need to update the MigApp.xml file using the following hotfix: http://support.microsoft.com/kb/2846838

Be sure to update the distribution points in your enviroment following replacement of the file 🙂