When we deploy a profile to a laptop, we can see in the logs that the drivers appear to be getting downloaded but when the system is complete, the device manager shows that the drivers were not installed.
Here is an example of what we see
[2015/03/30 12:53:01] W OS drivers [local://root/D$/Deploy_work/050F3D68E15C5517BB7812BE0EF55A1487B1D590pkg.BFOSD] missing. Try remote copy.
[2015/03/30 12:53:01] W Remote copy. Name [050F3D68E15C5517BB7812BE0EF55A1487B1D590pkg.BFOSD], size [2271677], remote [tem://servername:52311/Uploads/050F3D68E15C5517BB7812BE0EF55A1487B1D590/050F3D68E15C5517BB7812BE0EF55A1487B1D590pkg.BFOSD/050F3D68E15C5517BB7812BE0EF55A1487B1D590|2271677|247E435FA505DF01FF7A88238F5823C6743151B540DAEA74998372CE3E0AAC46/050F3D68E15C5517BB7812BE0EF55A1487B1D590pkg.BFOSD], local [local://root/D$/Deploy_work/050F3D68E15C5517BB7812BE0EF55A1487B1D590pkg.BFOSD]
[2015/03/30 12:53:02] W Remote file copy completed.
Also, did you confirm that file actually corresponds to the driver that you are expecting to be injected into the image? Is the driver actually bound and compatible with the hardware that you are deploying to?
According to the logs, it is mapping the PCI devices to the correct drivers and the install is recognizing that it needs to download them. When I look at the bindings it appears that we have everything.
Noticed that the driver import wizard changed with the latest site update, so looking into that. There is also a new OSD server version to deploy and MDT bundle, so going to see if that makes a difference.
The messages are just tracing the fact that a certain driver is needed and we are about to copy it form the remote.
.
here is the code snippet causing the above traces. It does like this because it is in a loop, and there may be more PCI devices in the system requesting the same driver, hence we need to check if the driver was copied already in a previous iteration.
As you get the “Remote file copy completed” message it means the driver was copied OK.
// Download the driver if the file is not found.
if (!FileExists(dfile)) {
DefLogEx(3,Strf(“OS drivers [%s] missing. Try remote copy.”, dfile));
str fromURL= StrChDir(“link://src/.TPMfOSd/global/tem/drivers”, cr->drvfile);
DefLogEx(3,Strf(“Remote copy. Name [%s], size [%s], remote [%s], local [%s]”, cr->drvfile, cr->drvsize, fromURL, dfile));
CopyFile(fromURL,dfile);
if (!FileExists(dfile)) {
DefLogEx(3,Strf(“Remote file copy failure. File [%s] not found after remote copy. Keep going…”,dfile));
} else {
DefLogEx(3,Strf(“Remote file copy completed.”));
}
ManMany thanks
Antonio
In other words…
The system is dowloading the needed driver from the server to the target that you are installing hence you see this traces that are normal.
The Bindings provides a preview of what drivers are going to be selected at runtime, and more important if there are missing drivers for certain devices.
Wizard import changed, main difference is that you now have the possibility to view what you are about to import, and you also have the possibility to bind the group of driver to a model.
The trace is telling us that the diriver with SHA1: 050F3D68E15C5517BB7812BE0EF55A1487B1D590 was used, and it is not working properly.
You need to find and use a different driver.
Go back to the Bindings Tab and see if for that device there are others Drivers available. (click on the pencil). Try to manual bind a different driver (if available) for that device. Another option is to use the Model Bind Feature that we added in 3.7 to overcome this type of problems. This will allow the system better tailor the driver to use among the available ones.
I feel your pain… I have problems with the drivers just as you do… its frustrating…
For instance… I will bind the drivers to the system, verify the device ID on all drivers bound, re-image… and be missing bluetooth (ACPI), USB3, Card Reader drivers… even though they are all properly bound… they do not get installed on the system properly.
I will then take that EXACT same drivers that are bound, copy them to the PC, and manually update the drivers… and VOILA… they work perfectly…
It’s the most frustrating aspect of OSD from bigfix. SCCM doesn’t have this issue.