Month: December 2013

A variation on a theme from yesterday where I enabled existing Windows PE images to support DaRT RemoteRecovery.exe on startup.

I also want to have a PXE-delivered DaRT WinRE Task Sequence deployed via ConfigMgr 2012 SP1. In order to automate the build of DaRT 8.1 images that include execution of the RemoteRecovery.exe via Unattend.xml I have modified the DaRT Wizard created PowerShell script. This script, along with pre-requisite file can be downloaded from here. The image will create shortcuts on a chosen file share for DaRT Remote Viewer connections – this means you don’t need the Ticket ID from the console to connect.

When executing the script, you will be prompted for a number of inputs  including specifying the target architecture – the script can be used to create x86 or amd64 DaRT WinRE images.

This article is focused on modification of a “true” DaRT image to facilitate RemoteRecovery.exe launch at boot. For existing WindowsPE 4/5 images, refer to this article.

So, in trying to get a Dell Precision M4800 to build recently we were presented with the following error during OSD:

"Windows could not configure one or more system components. To install Windows restart the computer and then restart the installation."

Below I have detailed how to inject the KMDF driver into your image,  for information on how to inject this into your “Build and Capture” task sequences click here.

We were using the Dell-supplied Driver CAB for the model, however even without this the build failed with the same error message. Eventually, after looking through various forums it became clear we were missing the KMDF 1.11 driver; http://support.microsoft.com/kb/2685811

Download the x64 and x86 update and extract using 7-zip and then use the following script to inject the driver to the x86 image, modify highlighted sections for x64 injection.

mkdir F:\Temp\Mount

dism.exe /mount-wim /wimfile:"<WIM file location>" /index:1 /mountdir:F:\Temp\Mount

dism /Image:F:\Temp\Mount /Add-Package /PackagePath:F:\Temp\kmdf-1.11-Win-6.1-x86\Windows6.1-KB2685811-x86.cab

dism.exe /unmount-wim /mountdir:F:\Temp\Mount /commit

In producing accurate reports for an MS SPLA I came across a bug on legacy Windows 2003 platforms where the total number of cores was not being reported (now critical for SQL server licensing). The following hotfix resolves this issue – note that installation requires a restart:

http://support.microsoft.com/kb/932370/en-us

If you’re still running ESX/ESXi 4.x anywhere in your environment then the SCCM 2012 Service Pack 1 upgrade will have been painful – the deployment I’ve been working on has until now been specifically client focused, however we’re now looking at server deployment via SCCM. Whilst we have ESXi 5.x across the estate there is still a spattering of ESX 4.x that we will have to support new Server 2008 R2 deployments to in the short term.

You can use the following batch file to create a WAIK-based Windows PE 3 boot image that will work on ESX/ESXi 4.x – download the WAIK from here: http://www.microsoft.com/en-us/download/details.aspx?id=5753

{code lang:css showtitle:false lines:false hidden:false}:: Install ‘legacy’ WAIK from http://www.microsoft.com/en-us/download/details.aspx?id=5753

:: Create Directories
mkdir C:\Temp\WinPEMount
mkdir C:\Temp\WinPEx64

:: Copy PE Image
copy “C:\Program Files\Windows AIK\Tools\PETools\amd64\winpe.wim” C:\Temp\WinPEx64\

:: CD to correct DISM verion (WAIK)
cd “C:\Program Files\Windows AIK\Tools\Servicing”

:: Mount Image
dism.exe /mount-wim /wimfile:C:\Temp\WinPEx64\winpe.wim /index:1 /mountdir:C:\Temp\WinPEMount

:: Add required components
dism.exe /image:C:\Temp\WinPEMount /add-package /packagepath:”C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\winpe-wmi.cab”
dism.exe /image:C:\Temp\WinPEMount /add-package /packagepath:”C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\winpe-scripting.cab”
dism.exe /image:C:\Temp\WinPEMount /add-package /packagepath:”C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\winpe-hta.cab”
dism.exe /image:C:\Temp\WinPEMount /add-package /packagepath:”C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\winpe-wds-tools.cab”
dism.exe /image:C:\Temp\WinPEMount /add-package /packagepath:”C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\en-us\winpe-wmi_en-us.cab”
dism.exe /image:C:\Temp\WinPEMount /add-package /packagepath:”C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\en-us\winpe-wds-tools_en-us.cab”
dism.exe /image:C:\Temp\WinPEMount /add-package /packagepath:”C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\en-us\winpe-hta_en-us.cab”
dism.exe /image:C:\Temp\WinPEMount /add-package /packagepath:”C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\en-us\winpe-scripting_en-us.cab”

:: Inject Drivers for vmxnet3
dism.exe /image:C:\Temp\WinPEMount /add-driver /driver:”C:\Temp\Drivers\vmxnet3-8.3.12 build-493255\vmxnet3ndis6.inf”

:: Commit changes and unmount
dism.exe /unmount-wim /mountdir:C:\Temp\WinPEMount /commit

:: Now import to SCCM and assign to VMWare Windows 2008 R2 Task Sequence{/code}

Had a strange issue reported via our support team today, a couple of builds failing once the PXE boot password had been entered with a 0x80004005 error. The SMSts.log showed the following:

pNext != NULL, HRESULT=80004005 (e:\qfe\nts\sms\framework\osdmessaging\libsmsmessaging.cpp,1972)    TSPxe    10/06/2013 11:07:00    1364 (0x0554)
 reply has no message header marker    TSPxe    10/06/2013 11:07:00    1364 (0x0554)
 DoRequest (sReply, true), HRESULT=80004005 (e:\qfe\nts\sms\framework\osdmessaging\libsmsmessaging.cpp,5868)    TSPxe    10/06/2013 11:07:00    1364 (0x0554)
 Failed to get client identity (80004005)    TSPxe    10/06/2013 11:07:00    1364 (0x0554)
 ClientIdentity.RequestClientIdentity (), HRESULT=80004005 (e:\nts_sccm_release\sms\client\tasksequence\tsmbootstrap\tsmediawizardcontrol.cpp,1072)    TSPxe    10/06/2013 11:07:00    1364 (0x0554)
 failed to request for client    TSPxe    10/06/2013 11:07:00    1364 (0x0554)
 Exiting TSMediaWizardControl::GetPolicy.    TSPxe    10/06/2013 11:07:00    1364 (0x0554)
 pWelcomePage->m_pTSMediaWizardControl->GetPolicy(), HRESULT=80004005 (e:\nts_sccm_release\sms\client\tasksequence\tsmbootstrap\tsmediawelcomepage.cpp,303)    TSPxe    10/06/2013 11:07:00    1364 (0x0554)
 Setting wizard error: An error occurred while retrieving policy for this computer (0x80004005). For more information, contact your system administrator or helpdesk operator.    TSPxe    10/06/2013 11:07:00    1272 (0x04F8)

Changing the time/date in the computers BIOS resolved this error – the date and time were both incorrect.

I’ve seen this issue with Windows 7, Windows 8 and Windows 8.1 deployments via SCCM 2012 SP1 and SP1 CU3 – almost at random an OSD Task Sequence will fail with a “0x80004005” error, deploying an application that I know:

• Works outside of a Task Sequence
• Exists on the required Distribution Point used during OSD
• Worked on the last X builds, using the exact same Task Sequence

Interestingly, in my case at least, it was always the same application that caused the problem.

Tracing the error reveals an interesting “feature” in SCCM 2012 SP1 and SP1 CU3; the AppDiscovery.log shows the client is missing the application in question, and that the installation is launched:

{code lang:text showtitle:false lines:false hidden:false}ActionType – Install will use Content Id: Content_2956d9e2-e279-4868-a70c-4ea95cb55004 + Content Version: 1 for AppDT “Microsoft Office ProfessionalPlus 2013 X86 EN – SCRIPT” [ScopeId_43347163-BC72-4CCA-A9E9-DBCC13F55603/DeploymentType_9ebdc693-4a51-46c2-afe3-1fb24eab15ea], Revision – 10{/code}

What is interesting here is that the Revision Number is not the “current” revision, i.e. the the T/S is looking for revision 10, whereas revision 11 is the current revision.

As a workaround, until there is a real fix for this issue, perform the following tasks:

1. Remove the application from the Task Sequence
2. Disable the Install Applictaion step
3. Save the Task Sequence
4. Close and Open TS editor
5. Re-add the application and re-enable the Install Application step
6. Save the Task Sequence

Alternatively, as described from the link below, you can put the offending application into is own Install Application step (instead of having multiple applications in one step).

The same errors is reported here (in much more detail) with more details on this workaround: http://www.vansurksum.com/configmgr-2012-caveat-with-application-revisions-when-used-in-a-task-sequence/

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.