Wednesday, January 16, 2013 5:21 PM
I'm using MDT 2012 Update 1 to build, sysprep, and capture a reference image. For some reason the sysprep is not removing all the drivers. Specifically it is not removing the AMD 3GIO Filter driver (among others). When the 3GIO filter driver is included in the reference image, and the image is used on another system, the Intel HD Graphics Family driver reports that it cannont find enough resources (Code 12).
I've manually removed the 3GIO Filter driver from the reference image wim using the DISM /Remove-Driver command, and the reference image will now properly deploy.
I have double checked the Unattend.XML file and the PersistAllDeviceInstalls is set to False, so my understanding is that sysprep should remove all the drivers in the generalize phase. Is this correct?
My question is "Is there a way to have the sysprep program remove all the drivers from the image that are not "Inbox" drivers". I use the DriverGroup property based on Make and Model to include all the drivers needed to deploy each particular type of computer, so I really don't want any "left over" drivers causing problems, and I don't want to have to manually remove drivers using the DISM /Remove-Drivers command each time I build a reference image.
Wednesday, January 16, 2013 8:23 PMSysprep does not remove drivers and therefore you should never create an image of an physical computer.
Thursday, January 17, 2013 12:52 AM
Actually, that's not really correct (from http://technet.microsoft.com/en-us/library/cc766514(v=ws.10).aspx):
"You can persist device drivers when you run the sysprep /generalize command by specifying the PersistentAllDeviceInstalls setting in the Microsoft-Windows-PnPSysprep component. During the specialize pass, Plug and Play scans the computer for devices and installs device drivers for the detected devices. By default, these device drivers are removed from the system when you generalize the system. If you set PersistAllDeviceInstalls to True in an answer file, Sysprep will not remove the detected device drivers. For more information, see the Unattended Windows Setup Reference."
The above is from the Vista version of the WAIK (1.0) but to my knowledge, nothing has changed in any other version of sysprep.
Note that the exact definition of "remove" is not specified but the implication is that they are removed from being installed and removed from the driver repository.
I do whole heartedly agree that you should always use a VM to build images though because I have seen weird things happen with drivers like control panel applets persisting or other remnants being left behind that aren't strictly part of the driver but are supporting utilities that sysprep has no knowledge of.
Jason | http://blog.configmgrftw.com
- Proposed As Answer by Stefan Sonneveld Thursday, January 17, 2013 11:06 AM
Friday, January 18, 2013 4:22 PM
I agree I should be using a virtual machine to build my reference images, just not there yet. Hopefully any non "inbox" virtual machine drivers will be removed.
I will be rebuilding the reference image and examining the logs to try to determine why certain drivers are not being removed. Thanks for the link, now I know to look in the %WINDIR%\System32\Sysprep\Panther for the log files.
If you have any idea why the generalize phase of sysprep does not remove some of the drivers, I would appreciate the information.
Monday, January 21, 2013 3:30 AM
Jason, from what I understand if you set PersistAllDeviceInstalls to False (or not included in the unattend.xml) all drivers are removed from being installed but are kept in the driver repository. If you set PersistAllDeviceInstalls to True all drivers are left alone meaning both being installed and in the driver repository.
Tuesday, January 22, 2013 2:53 AMThe documentation is definitely not precise on this point, but after looking over some other documentation, I believe that is correct. It doesn't change the problem at hand though which is a driver getting falsely installed when the image is deployed even though it is not present on the system. This seems to me like it is an issue with some virtual device or something else left over in the image that is causing Windows to falsely detect and install the device. The best answer in this case is to avoid the scenario causing it which is using a very generic reference system.
Jason | http://blog.configmgrftw.com