Patch your ConfigMgr Boot Image for Advanced Format / 512e DrivesWritten by Andy
Advanced Format (AF or 512e) drives are out there, often fitted randomly from one model to the next. I won’t go into the technicalities of what they are all about as Google will tell you this, but what I will tell you is that their presence can slow down the deployment rate on an affected system.
Firstly, if you are not sure whether your system is equipped with an AF drive (DELL include bright orange note with the system, HP just seem to sneak them in) then you can download and run the following tool in the OS or in WindowsPE;
The tool will tell you if an AF drive is fitted and also if the partitions are ‘aligned’.
When we use ConfigMgr and WindowsPE boot images to deploy systems with AF drives you may notice quite a slow down, especially in the “Apply Operating System Image” Task Sequence step. There is a patch to be downloaded from Microsoft that should be installed within a fully patched Windows 7 SP1 OS image AND we must also incorporate this patch into our ConfigMgr boot images;
Once you have obtained the x86 and amd64 versions you can follow my guide below on how to update BOTH of your ConfigMgr boot images. We will do the x86 boot image first and you just need to repeat the process for the amd64 image.
You should have installed the Windows Automated Deployment Toolkit (WAIK). You can undertake this task on the ConfigMgr server as it will have the WAIK installed. From your Start Menu, find the Microsoft Windows AIK\Deployment Tools Command Prompt and run as Administrator.
Create the following structure on a drive of your choice with a good few GB free (where X = YourDriveLetter)
X:\WinPE X:\WinPE\mount X:\WinPE\patches
Copy both of the downloaded Windows6.1-KB982018-v3-x64.msu and Windows6.1-KB982018-v3-x86.msu to X:\WinPE\patches. It does not matter that they are together as the patch injection process is clever enough to pick the right one.
Copy the boot.wim file (ignore the boot.xxx12345.wim) from <ConfigMgrInstallDir>\OSD\boot\i386 to X:\WinPE
From the Deployment Tools Command Prompt, run the following commands (replacing X:\ as appropriate);
DISM /Mount-Wim /WimFile:X:\WinPE\boot.wim /MountDir:X:\WinPE\mount /Index:1 DISM /Image:X:\WinPE\mount /Add-Package:X:\WinPE\patches DISM /Unmount-Wim /MountDir:X:\WinPE\mount /Commit
Rename the existing <ConfigMgrInstallDir>\OSD\boot\i386 .wim file to .old and copy up your replacement boot.wim from X:\WinPE.
From the ConfigMgr Console, Right click the x86 Boot Image and choose to Update Distribution Points. This will take our new boot.wim and re-integrate the ConfigMgr components, your modifications and drivers and re-send out to the DP’s.
The size increases on the boot.wim files you should be looking for, if all went successfully, should be;
i386 boot.wim should increase by approx 10MB
x64 boot.wim should increase by approx 12MB
With a patched WindowsPE boot image, the “Apply Operating System Image” Task Sequence step when ran on an AF drive should speed up considerably. The speed increases I have observed on an HP Touchsmart system were as follows;
BEFORE: AF Drive non-patched took 28 minutes for the “Apply Operating System Image” step to complete (inc. download)
AFTER: AF Drive patched took 13 minutes for the “Apply Operating System Image” step to complete (inc. download)
So you can see, there are significant time savings to be made with a properly patched WindowsPE boot image on an AF drive equipped system.
Oddly, when an AF equipped drive is partitioned and formatted using the boot images generated by ConfigMgr 2012 the Dell Alignment Tool states that the partitions are aligned correctly – however without the patch the disk performance is still poor.
Latest from Andy
- ConfigMgr 2012 SP1 with MDT 2012 Update 1, UDI Task Sequence and Bitlocker Error 6767
- ConfigMgr 101: Patience dear boy… SMS_SERVER_BOOTSTRAP
- ConfigMGr MPControl.log: Call to HttpSendRequestSync failed for port 443 with status code 403, text: Forbidden
- ATI Catalyst Drivers Installation
- ConfigMgr 2012: 64bit file system redirection bites again…