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’
-
@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/
