One of the last major steps to restore Windows Deployment Services to production was to create a custom boot image. I was determined to bypass issues we experienced with the default boot.wim image where users reported show-stopping "Network Path Not Found" errors toward the end of the capture procedure, which resulted from a lack of supported NIC drivers in the WinPE image. I made a policy decision to include all custom drivers in one set of setup and capture images so that users exclusively see those two options at the boot menu.
Missing Tool FAIL
The world has changed since I first deployed WDS... First of all, I'm running the official RTM version of Windows 7 on my desktop, and secondly Windows 2008 R2 was released. Collectively, this is known as "the new efficiency." So, to get started I installed the Windows 7 version of the Windows Automated Installation Kit on my desktop. Next, I brought down the boot.wim file from the Sources folder on the Windows 2008 R2 install media. I went through and carefully documented the prep steps for adding custom drivers, and things were going smoothly until:
peimg /inf=c:\temp\drivers\*inf /image=C:\temp\mount
...after which I received the puzzling error:
'peimg' is not recognized as an internal or external command,
operable program or batch file.
I scoured the file system for peimg.exe only to find that it was no longer there. Some research yielded the fact that, as of WinPE 3 and the Windows 7 WAIK, image-servicing functions are the now the domain of DISM: Deployment Image Servicing and Management.
Supported Architecture FAIL
That is OK with me because I'm all for doing things the new way, especially if it is newly efficient in some nebulous indeterminate fashion. So, I studied the new syntax and eccentricities of DISM, and carefully documented it for my users. The procedure is fairly similar to that of ImageX:
Backward Compatibility FAIL
I persisted in my mission and obtained the boot.wim file from the Windows 2008 SP2 x86 install media. This time, when adding the drivers with DISM, I was greeted with a different error message:
Error: 50
DISM does not support servicing a Windows Vista RTM or earlier operating system
If the operating system is supported check that SSShim.DLL is present.
The DISM log file can be found at C:\Windows\Logs\DISM\dism.log
Windows 2008, along with Vista SP1 and above, are documented as supported by DISM. The SSShim.dll file was definitely present, and was actively being referenced in the dism.log file. The relevant error in dism.log seemed to be the line:
DISM.EXE: Failed to get target image version. HRESULT=0x80070002
I tried using the boot.wim from the Windows 2008 non-SP2 x86 install disk and received the same error. I researched extensively on the web and only turned up one post which had one "me too" response. After a lot of work spinning my wheels, it was time to haul in the big guns and put in a case with MS Premier Support.
After confirming that I was using the correct syntax, the tech received some information from the engineers regarding limitations of DISM on Windows Vista SP1 and Windows Server 2008 pre-R2 images:
• Only offline scenarios are supported. (OK)
• The Windows image that you are updating must be Vista SP1 or Server 2008. (OK)
• DISM must be run from a full operating system or from Windows PE. (OK)
• Only Package Manager features are available – the new functionality in DISM, such as adding and removing drivers without an answer file, or enumerating packages and drivers, will not translate to package manager syntax. (FAIL)
Answer File FAIL
The phrase "adding and removing drivers without an answer file" in the tech's response was intriguing to me because it implied that the operation may be possible using an answer file. I dug in and researched what this would entail.
Like the Sysprep unattend xml answer file, it is created using Windows System Image Manager from the WAIK. After you have pointed the file to the locations of your drivers and generated the file, you mount the image and run the command:
dism /Image:C:\temp\mount /Apply-Unattend:C:\temp\unattend.xml
Sadly, after another significant time investment, this operation resulted in the same error 50.
Conclusion
In summary, I discovered that unless the Windows 7 WAIK is changed in a future update, it will be necessary to continue to run the Vista SP1 WAIK in parallel in order to add custom NIC drivers to x86 boot images using peimg. I was told by Microsoft that other customers have noticed this problem, and that my feedback would be forwarded to the product team for consideration in a future release.
That being said, this situation has made me consider the need to create and maintain separate x64 platform boot images and client OS system images in Windows Deployment Services. For three years, since Core2Duo hit the market and became standard, x64 has been available to the desktop user and it is really no longer in an "experimental" stage. Most of the common software packages and drivers which were slow to support x64 are now compliant (though, you should do a reality check of your specific users' software needs before deploying.) If the direction of Windows 2008 R2 can be interpreted as an early indicator of the future of the desktop OS market, we as IT professionals should be prepared -- and prepare our users -- for the inevitable.
Missing Tool FAIL
The world has changed since I first deployed WDS... First of all, I'm running the official RTM version of Windows 7 on my desktop, and secondly Windows 2008 R2 was released. Collectively, this is known as "the new efficiency." So, to get started I installed the Windows 7 version of the Windows Automated Installation Kit on my desktop. Next, I brought down the boot.wim file from the Sources folder on the Windows 2008 R2 install media. I went through and carefully documented the prep steps for adding custom drivers, and things were going smoothly until:
peimg /inf=c:\temp\drivers\*inf /image=C:\temp\mount
...after which I received the puzzling error:
'peimg' is not recognized as an internal or external command,
operable program or batch file.
I scoured the file system for peimg.exe only to find that it was no longer there. Some research yielded the fact that, as of WinPE 3 and the Windows 7 WAIK, image-servicing functions are the now the domain of DISM: Deployment Image Servicing and Management.
Supported Architecture FAIL
That is OK with me because I'm all for doing things the new way, especially if it is newly efficient in some nebulous indeterminate fashion. So, I studied the new syntax and eccentricities of DISM, and carefully documented it for my users. The procedure is fairly similar to that of ImageX:
- dism /Get-WimInfo /WimFile:C:\temp\customboot.wim - Retrieve the index number or name of the image that you wish to modify.
- dism /Mount-Wim /WimFile:C:\temp\customboot.wim /index:2 /MountDir:C:\temp\mount - Mount the image in a directory called C:\temp\mount.
- dism /image:c:\temp\mount /add-driver /driver:c:\temp\drivers /recurse - Add all .inf driver files contained in subfolders of c:\temp\drivers.
- dism /Unmount-Wim /MountDir:C:\temp\mount /Commit - Unmount the image, committing changes.
Backward Compatibility FAIL
I persisted in my mission and obtained the boot.wim file from the Windows 2008 SP2 x86 install media. This time, when adding the drivers with DISM, I was greeted with a different error message:
Error: 50
DISM does not support servicing a Windows Vista RTM or earlier operating system
If the operating system is supported check that SSShim.DLL is present.
The DISM log file can be found at C:\Windows\Logs\DISM\dism.log
Windows 2008, along with Vista SP1 and above, are documented as supported by DISM. The SSShim.dll file was definitely present, and was actively being referenced in the dism.log file. The relevant error in dism.log seemed to be the line:
DISM.EXE: Failed to get target image version. HRESULT=0x80070002
I tried using the boot.wim from the Windows 2008 non-SP2 x86 install disk and received the same error. I researched extensively on the web and only turned up one post which had one "me too" response. After a lot of work spinning my wheels, it was time to haul in the big guns and put in a case with MS Premier Support.
After confirming that I was using the correct syntax, the tech received some information from the engineers regarding limitations of DISM on Windows Vista SP1 and Windows Server 2008 pre-R2 images:
• Only offline scenarios are supported. (OK)
• The Windows image that you are updating must be Vista SP1 or Server 2008. (OK)
• DISM must be run from a full operating system or from Windows PE. (OK)
• Only Package Manager features are available – the new functionality in DISM, such as adding and removing drivers without an answer file, or enumerating packages and drivers, will not translate to package manager syntax. (FAIL)
Answer File FAIL
The phrase "adding and removing drivers without an answer file" in the tech's response was intriguing to me because it implied that the operation may be possible using an answer file. I dug in and researched what this would entail.
Like the Sysprep unattend xml answer file, it is created using Windows System Image Manager from the WAIK. After you have pointed the file to the locations of your drivers and generated the file, you mount the image and run the command:
dism /Image:C:\temp\mount /Apply-Unattend:C:\temp\unattend.xml
Sadly, after another significant time investment, this operation resulted in the same error 50.
Conclusion
In summary, I discovered that unless the Windows 7 WAIK is changed in a future update, it will be necessary to continue to run the Vista SP1 WAIK in parallel in order to add custom NIC drivers to x86 boot images using peimg. I was told by Microsoft that other customers have noticed this problem, and that my feedback would be forwarded to the product team for consideration in a future release.
That being said, this situation has made me consider the need to create and maintain separate x64 platform boot images and client OS system images in Windows Deployment Services. For three years, since Core2Duo hit the market and became standard, x64 has been available to the desktop user and it is really no longer in an "experimental" stage. Most of the common software packages and drivers which were slow to support x64 are now compliant (though, you should do a reality check of your specific users' software needs before deploying.) If the direction of Windows 2008 R2 can be interpreted as an early indicator of the future of the desktop OS market, we as IT professionals should be prepared -- and prepare our users -- for the inevitable.
Leave a comment