Continued from part 2d:
In the previously explored client-side SCCM script, we saw some CSV files referenced by the client. These CSV files are not a natural part of the UDI environment, but must be generated by server-side script. What is in these files? Information about the driver packages and OS images that are defined in the SCCM database. Why not just have the client query SCCM for this information? Because to do so, we would need to inject privileged credentials into the WinPE environment, and I don’t want to do that. Creating the CSV files is a safe way to expose SCCM database info.
In authoring these posts, I see that at present the ‘zUVM-DriverCategories.csv’ gets generated twice… once when I run the ImportDrivers.ps1, and then again when running this script. Clearly this redundancy is not required. As I think about it, I probably should retire this script and merge the creation of the zUVM-OSImages.csv file into the script that updates our UDI Wizard display. I guess that will have to wait for version 2.0 of this guide.
This approach comes with the requirement that we update the CSV files any time a new OS or driver package is added to SCCM. We will get to the automation of the update process in a bit. But first, here is the UDI client CSV info file generation script, in PowerShell, of course:
You may note that this code uses the Get-CMOperatingSystem PowerShell module. Earlier I said that you should not use these PS modules. I did mean it, but I wrote this code before I discovered that the module is evil, and I don’t feel like re-writing the snippet. Call me lazy.
Observant readers may have noticed in the comments the text that reads: “YOU MUST ALSO RUN ‘build-UDIImageList.ps1’ to ensure that the images in the UDI Wizard are identical to the images used by the zUVMSetDriverCategories script.” The build-UDIImageList.ps1 script is a direct component of this driver handling routine. Instead, this script is used to populate SCCM OS Images into the UDI dialogs. However, since our driver handling logic is sensitive to the OS that was selected for installation, we now have a dependency on the our UDI dialog building process. I will present this script in part 3 of this blog series, where I will discuss OS Image selection in UDI.
But first we need to wrap up our discussion of driver handling, which I will do in part 2f, next…
Next: Drivers – File Structure and Dependencies
- Drivers – Package Import:
- Drivers – Task Sequence Management:
- Drivers – Powershell Support Module:
- Drivers – Client-side driver package selection:
- Drivers – Providing SCCM database info to clients:
- Drivers – File Structure and Dependencies:
- Operating Systems – Update the OS Image List in the UDI Wizard:
- Operating Systems – Update the Task Sequence with new OS Image data:
- Applications – Update the Applications and App Groups in the UDI Wizard:
- UDI Quirks:
- UDI Operations – Updating Drivers:
- UDI Operations – Updating Operating Systems:
- UDI Operations – Updating Applications: