Plugging the hole
I was recently tasked with resolving an image build for the Desktop Services group at a large enterprise client I’d been assigned to. In between some major projects, their manager had requested that I fix some type of driver conflict with a Lenovo t430 laptop. He had told me that Desktop Services were recently attempting to insert new drivers for a model new to the environment and it somehow fugazed all legacy laptop and workstation deployments. Desktop Services were backed up and are unable to deploy any machines for anyone across the country, short of manually referring to ghost images, manually building etc.
After a few hours of acclimating myself to SCCM 2007 (something I have not ever touched), I had removed the autoapply driver option to the specific task sequence they were testing and directed to it to the custom repository of drivers I added. Success! The image is working. ……aaaaand now I have been requested to resolve all images, create custom task sequences, and add driver repositories like I had done before for the t430. So, off I go from the comfortable engineering area to the Desktop Services workbench to resolve this mess.
General technical design:
First and foremost, for scalability, one must ensure that variations in laptop/workstation models will use the same base/boot image and same OS image. This helps streamline processes and remove any room for error down the road, should another engineer or technician need to make adjustments. Second, you really want to have a specific task sequence and specific driver category/repository for each model. This will ease deployment tasks when importing new computer objects into a collection (one collection for each model associated to one task sequence for that model pointing to custom drivers for that model…very straight forward).
Business driven design:
I then spoke with the Desktop Services Supervisor and obtained priority for laptop/workstations across the country. How many of X model computers do they need at each location right now? Are there any expected rollouts/upgrades/repairs anticipated for the next two weeks? I really enjoy delivering results faster than expected. Clients are happy, I get more downtime to read, study, and keep in touch with my social network to share information.
Always the straggler
After all legacy makes/models were working properly, I was left tinkering with the new t440p that originally brought about all this mess. After checking sms logs, it was determined that incompatible USB3/chipset drivers were causing the initial hardware initialization on the boot WIM to fail. That is easy enough; Remove the legacy drivers, find the new drivers, slip it into the boot image, add it back to SCCM, and test against all models. (I used a copy, rather than the original, and inserted into SCCM as another image so no disruption was caused to working/production deployments just resolved)
# get image info Dism /Get-ImageInfo /ImageFile:C:\test\images\install.wim # mount the image Dism /Mount-Image /ImageFile:C:\test\images\install.wim /Name:"Windows_Drivers" /MountDir:C:\test\offline # list drivers Dism /image:C:\test\offline /Get-Drivers # remove drivers Dism /image:C:\test\offline /Remove-Driver /driver:oem1.inf # add the drivers (I dumped the files into a directory, used the /recurse for all drivers in the folder and forced unsigned drivers) Dism /Image:C:\test\offline /Add-Driver /Driver:c:\drivers /Recurse /ForceUnsigned # commit changes and unmount the image Dism /Image:C:\test\offline /Get-Drivers Dism /Unmount-Image /MountDir:C:\test\offline /Commit
For some reason the OS deployment would get all the way to the final stages of customization and fail with a bluescreen. After rebooting, an error would appear and then go into a looped reboot cycle.
After much research, it was determined that the windows image needed to have the latest Kernel-mode Framework Module and latest User-mode Framework Module in order for the drivers to be applied correctly. You can either make this a step in the task sequence or you can update your OS image. I chose to inject this into the image so we can keep our task sequences consistent and lean.
1. download the packages/modules from Microsoft
2. unpack/unzip (I used 7Zip)
3. make a copy of your image and create a temp/test directory to mount to
4. get image info, mount the image, add the package(s), commit/dismount, and add back to SCCM.
# get image info Dism /Get-ImageInfo /ImageFile:C:\test\images\install.wim # mount the image Dism /Mount-Image /ImageFile:C:\test\images\install.wim /Name:"Image_Name" /MountDir:C:\test\offline # add the packages Dism /Image:C:\test\offline /Add-Package /PackagePath:C:\packages\package1.cab /PackagePath:C:\packages\package2.cab # commit changes and unmount the image Dism /Unmount-Image /MountDir:C:\test\offline /Commit
I tested the whole process using the new boot image, OS image, driver repository, and specific task sequence with success. I then duplicated/modified task sequences for all other models and tested. Once all the computers were being deployed using the same boot/OS image, I removed unneeded sequences, updated production sequences to point to the new boot/OS images, removed the images from SCCM, moved the legacy images into a different folder, added a README.TXT with some notes, updated existing client documentation, and notified the client.Follow thecloudphd