my OSD configuration is in a pretty early stage. I’ve PXE imaged a couple of models for testing, but we’re about at the point where we’d like to be able to image any of the hardware in our environment. it’s going to be the same windows 10 image deploying pretty much every time.
from what I understand, in order for a different computer model to be able to pxe boot and image successfully, there needs to be at least a network driver bound for that image and model.
1: are there other drivers that are critical for successful imaging, anything related to the chipset or storage controller etc? or is the network driver enough?
2: if my environment has a few dozen computer models in it, what would be the best way to prepare the OSD configuration to be able to pxe boot and image them? I am concerned that I will constantly be interrupted to solve issues with each model if I don’t preemptively situate the driver configuration. my thought: generate a list of all the computer make/models, download all of the network drivers for windows 10 on them from the MFG websites, and import them all in and generate the binding grid. is there a better way? this sounds tedious to me 
1 Like
Hi Entaille,
-
Also disk drivers are considered critical. In the early stages of a pxe imaging flow WinPE is stated on the target machine, and if network and disk are not accessible the imaging can not continue. Later on in the process, disk drivers for the Operating system are critical (if missing the operating system will not start). Other missing drivers at that stage may result in a non
functioning device when in the OS, but the imaging will complete (for example, if the network driver is missing from the OS, the network will not work but the imaging process completes).
-
At runtime, the product will try to find the best match between the driver loaded in the driver library and the device present on the target machine. This is the Automatic Binding.
It is then possible to override the Automatic Binding done by the product by performing a Manual Bind. In this way you indicate what driver to use for given device on the given model.
In cases like yours where you have to deal with several hardware model, the best approach will be to leverage the Model Bind feature of the product. This is something in the middle between Automatic Binding and Manual Binding. In this way, at drivers import time, you indicate for what hardware models those drivers should be used for.
Sample of model bind usage at this page:
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint%20Manager/page/Using%20the%20Model%20Binding%20Feature
In order to use model binding the model must be known to the environment. (see Discover the machine model section)
Please note that the Generate Binding Grids button in the Binding performs a simulation of what binding operation will be performed at runtine. This gives you the opportunity to verify any potential driver issue.
So, in conlusion, you thought is correct. Just consider that the “generate binding grid” part is not necessary (unless you want to check for drivers issues) and binding the imported drivers packages to the models should prevent several potential drivers issues at deployment time.
Hope this helps.
Antonio
1 Like