Post Sysprep Driver Install
-
do you have a method?
-
@TrinityAcademy sorry it took me a bit longer than it should have to locate the document. I was updating my previous post when you replied.
-
@george1421 The process works for win10, but you need to update the unattend.xml file to tell windows OOBE where to find the drivers you install via the post install script. Lee also has an alternate method, let me get that link to. But either way we use postinstall scripts to place the drivers in a specific location on the target computer, and the instruct the windows computer to look in a certain location for these drivers.
Here is another article: https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection
This post specifically mentions the Win10 unattend.xml file settings: https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection/4
-
I’m also in an educational environment deploying one image to 20+ models. I’m not using the FOG postinstall script.
I use the SetupComplete.cmd file to launch my SetupComplete.ps1 file, stored in the same location. From here I mount a network drive a launch another script that uses WMI to determine the model. Once I have the model determined I use that to copy another powershell script to the local hdd and run it. This script copies and installs all the drivers.
The important thing, if you go this way, is to add all your NIC drivers for every model into the image using PnPUtil. They don’t need to be installed, just added to the DriverStore.
So far I’ve found doing it this way to be very flexible as I can modify or add things as needed without having to edit the image or answer file.
-
I sill say that with Windows 10 currently, I’ve yet to have it not find a driver for something out of the box through Windows Update. It’s been very lucky, I’m sure, but it’s been huge.
We only have 4 models to support, due to forcing bulk purchases, but use 1 image for it with drivers added to the DriverStore using PNPUtil. Since we’re a Dell and Lenovo shop, they offer SCCM cab’s of the files which makes it very easy to throw them all in.
-
I use AutoPkgr (mac program, https://github.com/lindegroup/autopkgr/releases ) to automatically check for updates, download, and generate packages out of Driver Packs and Bios updates ( https://github.com/jeremylarose/autopkg-recipes ) daily. … Then I use Salt ( https://docs.saltstack.com/en/latest/ ) to deploy them, with this simple state…
{% set model = grains[‘productname’] %}
‘c:\salt\drivers{{ model }}.exe’:
file.managed:- source: ‘salt://win/drivers/win10/{{ model }}.exe’
- makedirs: True
install_drivers:
cmd.run:- name: ‘“c:\salt\drivers{{ model }}.exe”’
- onchanges:
- file: ‘c:\salt\drivers{{ model }}.exe’
-
@larosejm now that i think about it, if you use the snap-in feature of fog, you could just use the generated silent installer packages as snap-ins as well
-
@larosejm said in Post Sysprep Driver Install:
@larosejm now that i think about it, if you use the snap-in feature of fog, you could just use the generated silent installer packages as snap-ins as well
You could, as long as the NIC driver is working. However, if the driver isn’t a single file .msi or .exe you’d need to package it with something like 7-zip SFX.
Really depends on how many models you are deploying to. I’m doing over 20 with one image, so making all drivers snapins just isn’t practical.
-
@Avaryan yes, that’s why I provided a tool to automatically generate those 7zip packages for you… add some recipes for your models.
-
@larosejm said in Post Sysprep Driver Install:
I use AutoPkgr (mac program, https://github.com/lindegroup/autopkgr/releases ) to automatically check for updates, download, and generate packages out of Driver Packs and Bios updates ( https://github.com/jeremylarose/autopkg-recipes ) daily. … Then I use Salt ( https://docs.saltstack.com/en/latest/ ) to deploy them, with this simple state…
{% set model = grains[‘productname’] %}
‘c:\salt\drivers{{ model }}.exe’:
file.managed:- source: ‘salt://win/drivers/win10/{{ model }}.exe’
- makedirs: True
install_drivers:
cmd.run:- name: ‘“c:\salt\drivers{{ model }}.exe”’
- onchanges:
- file: ‘c:\salt\drivers{{ model }}.exe’
That stuff sounds pretty neat, and you sound knowledgeable on the topic. You could do a solid for the community by writing a tutorial here.
-
- Be on a Mac, version 10.8 or higher
- download AutoPkgr… https://github.com/lindegroup/autopkgr/releases
- Open AutoPkgr and install Git and AutoPkg with the provided buttons
- In the “Add a repo URL manually” box, add the following to get many Dell drivers and software … https://github.com/jeremylarose/autopkg-recipes.git
- right click on any pkg you want and click “Create Override”… this is to protect you from any malicious changes ( https://github.com/lindegroup/autopkgr/wiki/Overrides-and-Trust-Info )
- now you can right click on the created local recipe (Recipe identifier changes to local.pkg…) and click run this “Run this Recipe Only” to create that package at ~/Library/AutoPkg/Cache
that’s it, although…
- you’ll likely want to checkmark all the packages you want and setup a schedule to run automatically
- you’ll likely want to create your own recipes for different models, which you can essentially duplicate the ones I already have created and modify, or just ask and I can probably do it real quick
bonus…
- I created a PkgOrganizer PostProcessor that will organize them in a PkgOrganizer folder, to add that…
- in AutoPkgr, click “Folders and Integration” then click “Configure AutoPkg” button and paste this into the postprocesser… com.github.jeremylarose.SharedProcessors/PkgOrganizer
Now you have silent installers to do whatever your want with. I find this tool extremely handy, saves alot of work. Its also amazing for macs with munki.
-
@TrinityAcademy
Hello,
You can install specifics drivers during sysprep.
In the regitry at “HKLM\HARDWARE\DESCRIPTION\System\BIOS\SystemProductName” you have the machine model or at “HKLM\HARDWARE\DESCRIPTION\System\BIOS\BaseBoardProduct” you got motherboard model. If you place your drivers at “C:\Windows\Drivers\MyModel1”, “C:\Windows\Drivers\MyModel2”… you can edit “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DevicePath” to add the path driver of your model.To do so I’ve developed a vbs script , you can edit it with Notepad++ to adapt it to your system.
Here is the steps:
1-place your script to “C:\Windows\Setup\Scripts\EditDriverPack.vbs”
2-execute your xml sysprep (ex: sysprep /generalize /oobe /quit /unattend:unattend.xml)
3-enter this in a cmd line:reg add HKLM\System\Setup /v CmdLine /t REG_SZ /d "cmd /c cscript //nologo C:\Windows\Setup\Scripts\EditDriverPack.vbs" /fReboot your computer to upload it to fog.
There is also a debug mode in this script, it allow you to use cmd line in sysprep just before drivers installation.
-
@Lenain You can also do this on the FOG linux side with a post install script. You would use the dmidecod linux function to access the machine properties. I have a few tutorials on how to do this too.
-
@TrinityAcademy said in Post Sysprep Driver Install:
HI
I am running FOG 1.3.4 on Ubuntu 16.04 and creating a Windows 10 Education 1607 image. I want this image to go on different machines and was wondering if there was a way to install the drivers automatically after sysprep. Any help will be greatly received.
Thanks
It really depends on how many models you plan to support with this image. If it’s only a couple, you could just pre-add the drivers to the DriverStore and Windows will usually pick the correct ones during the final stages of sysprep.
If you have more, you could utilize a network driverstore and again have Windows try to do it automatically. Or, if you want more control, you can use post installation scripts. FOG has a post installation script feature, but I’ve never used it.
I have this brief tutorial about doing multiple model post deployment scripts using PowerShell. I support 20+ models with this setup.
https://forums.fogproject.org/topic/9859/post-deployment-driver-installation-using-powershell-scripts -
#wiki worthy
-
These are all great automated methods for when you know in advance which models you’ll have and will support.
But say you work repair service where every possible model under the sun gets dumped for you to fix, then you need a broader solution.
To that end, we find Snappy Driver Installer to be very useful, not perfect, but it works very well.
-
@Quazz said in Post Sysprep Driver Install:
But say you work repair service where every possible model under the sun gets dumped for you to fix, then you need a broader solution.
warning with snappy driver installer… the project was hijacked and now includes malware… therefore a fork was generated called snappy driver installer origin…
https://sourceforge.net/projects/snappy-driver-installer-origin/
