Author: Chris Bradford

In testing Winodws 8.1 deployment I’ve encountered numerous BSOD’s with “CRITICAL_STRUCTURE_CORRUPTION” errors in both Windows PE 5 and he full Windows 8.1 Operating System.

Solution is pretty simple if you’re running VMware ESX 5: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2060019

In sumary, this is resolved in ESXi 5.0 Update 3, but as a workaround:

Manually create a CPUID mask for the affected virtual machines:

1. Power down the virtual machine. 
2. Right-click the virtual machine.
3. Click Edit Settings. 
4. Click the Options tab. 
5. Select CPUID Mask under Advanced. 
6. Click Advanced. 
7. Under the Register column, locate the edx register under Level 80000001. 
8. Paste this into the Value field:
   —-:0—:—-:—-:—-:—-:—-:—-
9. Click OK. 
10. Click OK to close the virtual machine properties.

Want to deploy Windows 8.1, without upgrading your SCCM environemnt to 2012 R2? This is supported with SCCM 2012 SP1 CU3 – the steps below outline how you can do this.

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.