Great post, thanks for this information.
Made my day! Now, our E5420 don't crash coming out of standby. We have to redeploy some machines now..
At first try I got an error:
2014-04-10 10:48:57, Error DISM DISM Driver Manager: PID=396 Failed to install the driver package 'C:\Drivers\win7\x64\security\R308120\Drivers\tcwbfadv.inf'. - CDmiDriverStore::Import(hr:0x80070002)
I found out that this is some kind of fingerprint reader driver, which is not built into our devices. I zipped these drivers so dism won't try to install it. How do you handle this kind of errors? Simply add it to the successful return code list in the template? Or is there a dism switch to prevent the installtion of devices that are not present?
EDIT: One more question: What about devices, for which there are no Windows 7 drivers available (on the Dell Driver CAB download page)? Do you create a dummy folder which contains one hardware independent driver, so that the action won't fail?
I inject all drivers that came from DELL for the specific model, also the one that are not needed (as Example the Fingerprintreader)
I didn't check the dism log all the time. Maybe we get this errors too.
Where is the point that these errors are a problem for you?
Is the provisioning template stopping?
To your additional question.
Are non Windows 7 drivers not compatibel with dism? I did not tried it. We are working in a Windows7/8 Environment.
-> In this case I would only try to find a Windows 7 Network driver for the Model an the other drivers I would install via Softwarepackage and a HII Action in the System Configuration Section
I extract the drivers from the *.cabs (e.g. http://en.community.dell.com/techcenter/enterprise-client/w/wiki/2180.latitude-e6320-windows-7-driver-cab.aspx). In there are all possible drivers, even if there is a component missing in our specific configuration. The templates stops, because a expect return code 0. I could ignore errors, but I thought it would be better to know when something's going wrong.
Second question: I don't know. The point is, that there ARE no drivers for a specific model (e.g. D630), the standard Win7 drivers coming with the image are sufficiant. But if the folder C:\Drivers is empty, dism fails. The "workaround" would be not to expect 0 as return code. But maybe it's a good idea to simply create a DUMMY folder which contains a generic NIC driver that gets deployed during the custom HII.
Okay...now I understand it a bit better.
I'am Sorry that your first try has this problems. I never had errors like this and I also do not ignore errors in the dism action.
If I have a bit time I will try to reproduce it with the driver R308120
For D630 we have a few Windows 7x64-drivers here if you need:
PS: Warum brech ich mir hier einen auf englisch ab, wenn du deutsch kannst .
I've done a little research. When I create a Dummy.inf, Dism gives me Error 2, which I wanted to add to expected return code in the prov. Template. The problem is, that you can only set ONE expected return code. But I would need two in may case (0 and 2)..So I set the exp. RC back to "Any" and my colleagues have to check the prov. history afterwards...Not that nice, but better than the standard HII action offered by LD..
habe gerade das Problem, dass er bei den Modellen E5440 und E7240 immer die SCSI-Treiber benutzt anstatt die für SATA (AHCI). Das führt im Nachgang zu Problemen. Hast du eine Idee, wie ich die Nutzung des SATA-Treibers erzwingen kann oder auch die Nutzung des SCSI-Treibers verhindern kann?
Currently, I have an issue with Dell models E5440 and E7240. They are always using the SCSI drivers instead of using the ones for SATA (AHCI). This causes problems later in the usage of the clients. Do you have an idea how to force using the SATA driver or to prevent using the SCSI driver?
bei uns klappt das 7240 ohne Probleme.
Wo kommt denn der SCSI Treiber her?
Bei mir gibt es gar keinen SCSI Treiber für das Modell (den 5440 haben wir nicht).
Würde was dagegen sprechen den SCSI Treiber einfach aus dem Ordner für das 7240 rauszulöschen?
Dann müsste das Setup ja den richtigen ziehen.
der entscheidende Unterschied war wahrscheinlich, dass wir nicht die Standardplatten benutzen, sondern Self-Enrypting drives..Die "ziehen" sich scheinbar den "falschen" Treiber..
Genau, hab die dann einfach entfernt.
Danke für den Hinweis.
I have not tested this with x64 UEFI. I'm not aware of the changes needed on the PXE server (Could you explain this, cause I would like to test x64 UEFI network boots).
What version of LANDesk do you use? I suspect this to be a typical "bitness issue", where you call 32 bit programs in a 64 bit environment.
Googling this also directs us in this direction:
Could you please cross check the bitness of the environment and tools? Also, could you perform this step manually on the WinPE command line? This way you should be able to troubleshoot this issue better.
Maybe C:\Windows\Logs\DISM\dism.log contains some useful info.
1 of 1 people found this helpful
The newest version of WinPE 64-bit does not work with 32 bit applications.
We just had to take the AutoIT script and recompile for 64 bit and it worked.
Based on my study of the device, thus far, I would have to say the culprit appears to be Secure Boot. It seems to be VERY touchy about devices and protocols it'll utilize. Unfortunately, the system also only seems to network boot when Secure Boot is enabled (you can have legacy support or UEFI device support, but not both). Using LDMS 9.6, and WinPE runs a script to load the network boot drivers then waits for the network to load before connecting to the core. I also noticed it attempting to connect to PXE, but I have yet to set up vboot.
Very likely this bitness situation. I seem to get the same error with my custom ImageX setup (just pulled the first ImageX.exe I could find, as the built in ImageX doesn't support direct wim application from a net use mounted repository) and the AutoIT script posted in this thread.
I just used the .au3 to compile a 64-bit executable if anybody needs it; thanks for making it available!.
CopyDrivers.zip 543.5 K
There's actually more to this.
It seems that WINPE loads 32-bit or WOW when not using UEFI, and 64-bit in UEFI. The laptop won't PXE without UEFI support, because there's no built in NIC.
I had been testing basing my deployment off of a net use mounted M: drive, which allows me to apply the image directly to the drive using ImageX, skipping the time consuming pre-application WIM file transfer.
I've now created CMD scripts for both ImageX and CopyDrivers that uses this code:
if %processor_architecture%==AMD64 (M:\Drivers\Tools\imagex64.exe /apply M:\DEPLOY\MicroSoft\Windows\7SP1\install.wim 1 C:) else (M:\Drivers\Tools\imagex32.exe /apply M:\DEPLOY\MicroSoft\Windows\7SP1\install.wim 1 C:)
This verifies if WINPE is running 32 or 64-bit (I should use X86 but we don't deploy Itanium). This ensures that I'm executing the correct version, avoiding errors that would be associated to running the 32 or 64-bit version in the wrong arch.
On a side note, you could also have the 32-bit and then the 64-bit steps one after the other, since one or the other always produces an arch related error. Both steps would need to be prevented from halting template processing, however. I used that to test the functionality, but something scares me about the idea of letting ImageX or CopyDrivers possibly run twice, should I find some strange situation that allows 32 AND 64-bit executables to run.