ConfigMgr : Building a DaRT 8.1 WinRE Image via PowerShell inc. RemoteRecovery on Startup

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.

Continue reading “ConfigMgr : Building a DaRT 8.1 WinRE Image via PowerShell inc. RemoteRecovery on Startup”

ConfigMgr : Adding DaRT 8.1 Remote Viewer to Existing Windows PE4/5 Images

There are a few articles out there that detail DaRT Remote Viewer integration, I was unable to find one single article that covered MDOP 2013 R2 DaRT 8.1 integration with SCCM 2012 Task Sequences – specifically addressing the requirement for RemoteRecovery.exe to launch on WinPE load, not after clicking ‘Next’ on the initial start-up screen.

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

My requirements were ‘simple:’

  1. Launch DaRT RemoteRecovery on a static port during PXE-boot WinPE startup, allowing Operator selection of Task Sequence, including a WINRE/DaRT environment.
  2. Creation of shortcuts based upon Asset Tag if a Dell Platform, or IP address if not, on a remote File Share. Shortcuts should be created for both Dart 7 and DaRT 8.1 Remote Connections.
  3. I’m currently not using MDT-integration, so I also wanted to avoid using MDT components if possible – especiaslly for something as simple as this.
  4. The process should be automated for future/existing boot images – ideally using PowerShell.

Initially I reviewed using the Boot Image Prestart Files/Command however this meant that someone had to click ‘Next’ before RemoteRecovery was launched, unless the Task Sequence was mandatory.

Credits, the following sources were (bastardised!) used to compile the scripts/process outlined in this article:

 

Continue reading “ConfigMgr : Adding DaRT 8.1 Remote Viewer to Existing Windows PE4/5 Images”

ConfigMgr : Kernel-Mode Driver Framework 1.11 KB2685811

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

WP 20131213 08 18 14 Pro

"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

ConfigMgr : Processor/Core Reporting on Legacy Platforms

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

ConfigMgr : Surface Pro OSD “DRIVER_POWER_STATE_FAILURE”

I’ve seen this error across Windows 8 and Windows 8.1 builds to an original Surface Pro device – I had originally thought this was resolved in the latest Driver Pack, but alas the error continues to plague deployments to this platform:

Surface Err

I’ll attach DMP file analysis when this finally finishes the generation process… stuck at 0% at the moment.

Update 15/12/13: I was unable to get the device to produce a DMP file, despite leaving it all night the progress was 0%. After many attempts the device eventually built, however I’m not convinced it is 100%.

Update 08/02/14: Device replaced under warranty – no issues rebuilding, over and over.

ConfigMgr : Create a “Legacy” Windows PE Boot Image

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}

 

ConfigMgr : Surface Pro 2 Oct 2013 Driver Pack Missing Genuine Ethernet Adapter Driver

In testing Windows 8.1 deployment to Surface Pro 2 devices, via PXE and the genuine Microsoft Surface Ethernet Adapter, I came up against long delays during OSD, with the device stuck “Getting Ready” for 30 minutes plus.

win81_stuck

Eventually the Task Sequence progress UI appeared and I was able to get access to the Command Line, sure enough there was no ethernet adapter.

For some reason this is completely missing from the October 2013 Driver Pack. For now I have copied the driver from the original Surface Pro driver pack, which resolves the OSD issues.

ConfigMgr : Post PXE/Media Boot, 0x80004005

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:

{code lang:text showtitle:false lines:false hidden:false}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){/code}

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

ConfigMgr : Erratic Task Sequence Application Deployment Failure

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/

ConfigMgr : WinPE5 / Windows 8.1 “CRITICAL_STRUCTURE_CORRUPTION”

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.