Category: ConfigMgr

Took a while to resolve this one, with the help of Microsoft PSS.

The Problem

The refresh involves using the User State Migration Tool version 5 to capture user settings/preferences and data from old devices and restore to new machines once the Operating System and applications such as Office are deployed.

Source/old machines are running Windows Vista or Windows 7, Office 2007 and have the Enterprise Vault Add-In for Outlook version 9.0.2.1136. Target/new machines have Windows 7 SP1, Office 2013 and Enterprise Vault Add-In for Outlook version 10.0.3.1090. All operating systems are 32-bit. On machines where the User State Migration Tool is used every time Outlook is opened the following error is presented:

Either there is no default mail client or the current mail client cannot fulfill the messaging request.

If Outlook is started using outlook.exe /safe it opens without issue. If I disable the Enterprise Vault Add-In within Outlook, it opens without issue.

The Fix

Modification of the following reg key will resolve the issue without an Office repair:

HKLM\SOFTWARE\Clients\Mail\Microsoft Outlook\MSIComponentID

Set this to the following value to resolve the issue: {6DB1921F-8B40-4406-A18B-E906DBEEF0C9}

Initial tests excluding this from capture/restore via a custom XML but this doesn’t seem to workw so we’re now using the following Run Command Line step in the USMT Task Sequence to resolve the issue:

reg add “HKLM\SOFTWARE\Clients\Mail\Microsoft Outlook” /v MSIComponentID /t REG_SZ /d {6DB1921F-8B40-4406-A18B-E906DBEEF0C9} /f

It is possible to deploy and enable the VMware WDDM graphics driver during an OSD Task Sequence using the command listed below. This should be run after installation of the VMWare tools and a subsequent reboot. Use the ‘Run Command Line’ task to execute the comman, note that no additional package/configuration is required:

cmd.exe /c pnputil -i -a “%PROGRAMFILES%\Common Files\vmware\drivers\wddm_video\vm3d.inf”

I follow this stage witha reboot to ensure successful installation.

Ever since rolling out SCCM 2012 we have been ‘unhappy’ with the Console performance, its not been unusable, but its not been as snappy as many of us have come to expect from our applications these days. Last night I was determined to resolve this; bring on Process Monitor! I noticed that browsing the various views in the console appears to increase CPU utilisation of the MsMpEng.exe process – System Center 2012 Endpoint Protection. I focused Process Monitor at the antimalware process to see if I could discover what it was scanning.

It’s worth pointing out at this stage we have been using the supplied SCEP policy for ConfigMgr servers since day one… I know what you were thinking.

Process Monitor revealed that the %PROGRAMFILES%\Microsoft Configuration Manager\Logs\SMSProv.log (note your path may vary depending upon you installation configuration) was being absolutely hammered when using the console. I’ve now whitelisted this single log file and the console is significantly faster – the change is quite remarkable.

My stance on SCCM updates, following ConigMgr 2012 SP1’s initial release, is a cautious one to say the least.

Today we completed the updgrade of our ConfigMgr 2012 SP1 envronment to CU3, facilitating the following capabilities for Windows 8.1 and Server 2012 R2:

• Endpoint Protection
• Software Deployment
• OSD (http://blogs.technet.com/b/configmgrteam/archive/2013/10/21/how-to-enable-windows-8.1-deployment-in-sc-2012-configmgr-sp1-cu3.aspx)

Fully appreciate ConfigMgr 2012 R2 is now out, give it 6 weeks and we’ll no doubt deploy – however CU3 at least gets the Surface Pro 2 trial moving forwards, and gives bretahing space for authenticode issues and the like!

In our multi-site (Primary/Secondary) environment the update installed without anyhickups – backups/offline-snapshot people, just to be sure!

In testing Surface Pro 2 deployment via ConfigMgr I ran into an issue where no matter what I tried the device would not PXE boot. I was using the official Ethernet USB adapter and all of our existing device portfolio were able to PXE boot without issue.

I then discovered the following article: http://support.microsoft.com/kb/2602043/EN-US

To summarise, in a mixed environment, which is likely to represent most, you’ll find that trying to PXE boot a UEFI client with DHCP options 66/67 set will fail.

This is because the boot programs differ:

• Legacy BIOS: wdsnbp.com
• UEFI: wdsmgfw.efi

The *only* way you can achieve this cross-subnet/VLAN is to define IP-Helper addresses on your network infrastructure, adding entries for the PXE boot servers. Once this is completed remove the DHCP scope/server options and you’ll find that both legacy BIOS and UEFI machines can PXE boot.

Had an issue with some builds today where the mahcines appeared to Domain Join during T/S but the bombed-out on the Enable Bitlocker stage as they wer eunable to store the Recovery Key data in the Directory service… because they were not Domain Joined! To cut a long story short, SCCM and the Domain Join functionality cannot function in the event that the computer account already exists, in another Organizational Unit. This is a limitation in Windows Setup, not the SCCM Task Sequence.

We use a custom HTA to collect OU locations, machine names etc so I extended it with the function below to perform a comparision of the TS MachineObjectOU variable value, and the existing account distinguishedName value – using the MDT Web Service produced by Maik Koster.

It’s never easy with ConfigMgr… in fact it’s normally self inflicted! In this scenario the smsts.log showed the following “useful” information:

Initializing HTTP transport. OSDSMPClient 19/09/2013 16:21:52 2952 (0x0B88)
cannot create a certificate context from the given encoded string OSDSMPClient 19/09/2013 16:21:52 2952 (0x0B88)
Set authenticator in transport OSDSMPClient 19/09/2013 16:21:52 2952 (0x0B88)
Sending request to MP https://SRV.domain.local. OSDSMPClient 19/09/2013 16:21:52 2952 (0x0B88)
In SSL, but with no client cert OSDSMPClient 19/09/2013 16:21:52 2952 (0x0B88)
In SSL, but with no media cert OSDSMPClient 19/09/2013 16:21:52 2952 (0x0B88)
Received 12566 byte response. OSDSMPClient 19/09/2013 16:21:53 2952 (0x0B88)
Failed to decrypt state encryption key (0x80070057) OSDSMPClient 19/09/2013 16:21:53 2952 (0x0B88)
Failed to parse response from Management Point (0x80070057). OSDSMPClient 19/09/2013 16:21:53 2952 (0x0B88)
ExecuteCaptureRequestMP failed (0x80070057). OSDSMPClient 19/09/2013 16:21:53 2952 (0x0B88)
ExecuteCaptureRequest failed (0x80070057). OSDSMPClient 19/09/2013 16:21:53 2952 (0x0B88)
OSDSMPClient finished: 0x00000057 OSDSMPClient 19/09/2013 16:21:53 2952 (0x0B88)
Process completed with exit code 87 TSManager 19/09/2013 16:21:53 5556 (0x15B4)
!--------------------------------------------------------------------------------------------! TSManager 19/09/2013 16:21:53 5556 (0x15B4)
Failed to run the action: Request State Store. 
The parameter is incorrect. (Error: 00000057; Source: Windows) TSManager 19/09/2013 16:21:53 5556 (0x15B4)

In this case there was actually an old Computer Association defined in the ConfigMgr database which was stopping the capture from running. This could be viewed via SQL Management Studio, using the following query against the Primary/Central site database:

SELECT *
FROM [<SITE DB>].[dbo].[StateMigration]
WHERE SourceClientItemKey = <RESOURCE ID>

To rectify this, I adjusted the built-in Site Maint. Task “Delete Aged Computer Association Data” to run immediately, with a lower number of days configured to retain data.

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 🙂