Author: Chris Bradford

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 🙂

Strange one this… I recently released a new version of a product in ConfigMgr, configured supersedence and waited for the defined uninstall/update to occur – only it didn’t. The software appeared to download on the client as expected (both old and new version) and then without any update in AppEnforce.log the deployment failed with an 80091007 error code.

On further investigation CAS.log contained the following:

{code lang:ini showtitle:false lines:false hidden:false}Download completed for content Content_1a0a6203-e945-4228-911c-3e3f7b6082aa.1 under context System ContentAccess 21/07/2013 16:48:36 9600 (0x2580)
Computed hash: 5AEBBE1E909AF384387E804ABCE3C8C71BBA007B433731766C0734EE44A28938 ContentAccess 21/07/2013 16:48:36 9600 (0x2580)
Failed to do hash verification with preference : 4. Try to verify at next hash algorithm ContentAccess 21/07/2013 16:48:36 9600 (0x2580)
Download failed for content Content_1a0a6203-e945-4228-911c-3e3f7b6082aa.1 under context System, error 0x80091007 ContentAccess 21/07/2013 16:48:36 9600 (0x2580){/code}

Content hash verification had failed.. strange as the MSI had been tested and was working. I simply updated the deployment content , waited for this to distribute and tested again without issue…!

I’ve had this crop up randomly on a number of machines now – software/update deployment stops working.  On investigation the SMS Host Agent service is not running. When restarted the service wont stay started – the system event log on the client is populated with the following errors:

{code lang:xml showtitle:false lines:false hidden:false}Log Name: Application
Source: Application Error
Date: 14/02/2013 09:14:34
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: <Client FQDN>
Description:
Faulting application name: CcmExec.exe, version: 5.0.7804.1000, time stamp: 0x50add095
Faulting module name: KERNELBASE.dll, version: 6.1.7600.16850, time stamp: 0x4e21132b
Exception code: 0xeeeefffe
Fault offset: 0x00009673
Faulting process id: 0xd74
Faulting application start time: 0x01ce0a939470cbdb
Faulting application path: C:\Windows\CCM\CcmExec.exe
Faulting module path: C:\Windows\system32\KERNELBASE.dll
Report Id: f1e3ad5b-7686-11e2-abf7-5c260a383293{/code}

Thanks to linkess from the TechNet forums I revised all of my Boundary Groups, creating a set of Boundary Groups that assign servers for content only, and a set of Boundary Groups for Site Code assignment (no servers listed in these).

I also ensured that only servers from the correct site were listed under each content group.

During deployment/configuration I ran into an issue where the Automatic Deployment Rule started failing. Tracing traffic via WireShark showed that a proxy server had been picked up (probably from a WPAD DNS entry) and as a result the ADR was failing to download.

Ruleengine.log showed: ‘Failed to download the update from the internet. Error = 12029’

Patchdownloader.log (careful as this changes location if the client is installed): ERROR: DownloadContentFiles() failed with hr=0x80072efd

To resolve I executed the following commands on the Primary Site Server (if you have a CAS then ensure you execute the command on the CAS server):

• bitsadmin /Util /SetIEProxy LOCALSYSTEM NO_PROXY
• bitsadmin /Util /SetIEProxy NETWORKSERVICE NO_PROXY       

By default these will be set to AUTODETECT – I can only guess that the server was picking up a proxy server from another domain in the environment.