Windows 10 Driver and Deployment Question
-
Hey everybody, been lurking in the forum for quite awhile now and I’m finally ready to ask for some help. I’m setting up FOG to image machines with Windows 10. I’ve been all over the forums and will use @george1421’s guide, but I have a couple other questions that I’m not clear on before I set this up.
I work for an ITAD company so we refurbish a lot of different computers. I created an image in a VM and have that ready to deploy in FOG already. The tech would image the machine, put it in audit mode, activate Windows, then shut it down to boot to OOBE for the customer. Right now they’re doing that and also having to install a bunch of drivers as well, we deal with a lot of different models.
My first question with this setup is do I need an unattended file? I think I do but I am not positive, and if I do do I then need the fog.updateunattend? I’m just getting going on this so it’s baby noob steps for now. I think I have drivers figured out for now. I am going to image a couple of Dells first, I think I understand to get the cab file, extract it in Windows to get the folder structure, than zip it and copy it to FOG server. I’ll deal with the hard to find drivers later.
I’m sure I’ll have more questions, I’m at the point where I’ve read too much on the forums and it all blends together.
Thanks!
-
@mwilcox said in Windows 10 Driver and Deployment Question:
My first question with this setup is do I need an unattended file?
The short answer is NO you don’t need an unattend.xml file. If you do not use the file, then oobe will ask questions of the installer during OOBE. The reason why you use an unattend.xml file in a business environment is to pre-answer the questions so the IT Tech doesn’t need to answer them each time they deploy an image. This creates the lite touch concept of image deployment.
do I then need the fog.updateunattend?
No you don’t. The fog.updateunattend script is intended to “patch” the generic unattend.xml file with build time settings. In my case I dynamically calculate the host name and target OU based on the build site’s IP address as well as the image name. I use the fog.updateunattend script to replace the paramters in the unattend.xml so the system is named correctly and destined to the right AD OU.
For MSP or system re-manufacturers I can give you a few hints.
- You don’t need or install the fog client on your golden image. The fog client is used to manage the target computer after the image has been deployed. In your case once the image is deployed you will never see the computer again (hopefully).
- At the end of image deployment you can have FOG power off the target computer. This is what you want because the next time its powered on (at the client site) you want OOBE to run in front of the client.
- There is no value in activating windows on your golden image, because it will need to activate it on the final hardware during OOBE. You should look into the commands necessary to activate the image using the setupcomplete.cmd or the in the unattend.xml file using the first login stanza. (yes there are reasons for using an unattend.xml file). You will need to use the setupcomplete.cmd file anyways to use the pnputil.exe program to load the drivers during OOBE.
- For System rebuilders there is a process I call “Load and Go”. Normally people register their target computers with FOG then deploy images to the target computer, and then finally manage the target computer post image deployment with the FOG client. In your case you will just want to load the OS and power off the target computer. So the load and go method you pxe boot into the FOG iPXE menu and then select the Deploy Image from the iPXE menu. This will immediately deploy the image to the target computer, FOG will forget this computer existed once the deployment is done. There is nothing to inventory, nothing to register, everything can be done from the iPXE FOG boot menu.
- One you get under production with your system, you can set a global kernel parameter that will tell the target computer to power off once FOG is done, that way once its image FOG will shutdown the target computer. Once your Imaging tech starts the process he/she can walk away and come back when the system is shutdown.
-
Thank you so much for the quick response George, it’s an honor to get your advice. I’ve read countless threads with you being so helpful.
My golden image doesn’t have the FOG client installed, it also doesn’t have an unattend so that’s good for me. We do have a FOG server running on our network. I built one a couple years ago and then had to abandon it when I ended up going offsite most of the time. So when we upgraded to new systems the boss had me resurrect it and we’ve used that for our in house machines. They have the FOG client installed and are managed that way, so with doing that they created a generic Windows 10 image to push out to sales prep to image the machines.
This created a couple problems, sales prep isn’t “tech savvy” so I need this to work as seamlessly as possible. So having them find drivers and install software isn’t the best solution. So what they are doing now is pxe booting into FOG and selecting Deploy Image, after that they go into audit mode from the OOBE screen and then activate Windows on the client machine (this is where they would install drivers or software if needed also). Then they shut it back down to boot to OOBE. My golden image has no activation set, sorry for the confusion.
So having FOG power off the machine doesn’t actually help here, but I understand the value. I’m sure this isn’t the most efficient way, and I’m not a deployment expert by any means, so if there’s a better way I’d love to hear it. I know FOG has the ability to add the activation key in, could that be a pop up before the image starts and then it could be set to power off the target? Would that require registration, or at least a quick registration?
Thanks again!
-
@george1421 So I just finished copying the scripts and creating the driver directories. Regarding this:
“Update: With the later releases of Win10 post 1703, the offline servicing section doesn’t seem to load the drivers. As a fix, add the following lines to your setupcomplete.cmd batch file to load the drivers at the end of the OSD process.
pnputil.exe /add-driver “C:\Drivers*.inf” /subdirs /install
pnputil.exe /add-driver “C:\Drivers*.inf” /subdirs /install
pnputil.exe /add-driver “C:\Drivers*.inf” /subdirs /install”I do not have a setupcomplete.cmd in my image. I’m presuming that this is something I need to add to my golden image before capture? If so, do I just create that file with this contents, and then where does it go?
Thanks again.
-
@mwilcox The setupcomplete.cmd file is a windows thing that is used to do any final presetup before the user interface starts after oobe. ref: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/add-a-custom-script-to-windows-setup
How I see some system rebuilders use fog is that some use the unattend.xml file to hold the activation key for when winsetup/oobe runs. Also the drives are left on the target machine so that the pnputil command will pick them up at the end of oobe. In their setup once FOG is done running and the machine is powered off the rebuilder take the computer and puts it in the box to ship. There is no post deployment activity. When the computer is booted winsetup/oobe runs, drivers are installed and the machine is activated. It take a bit of time, and scripting (in both FOG and the golden image) to get to this level of automation. But with it setup you can crank out quite a few systems per shift.
-
@george1421 Sorry for not getting back to you earlier, thanks for the response again. This sounds like exactly what I would want to do. Although it leaves me a bit worried about the drivers installing and Windows activating after it’s left our shop. But I guess if I can test it and it works it wouldn’t be any worse than what we’re doing now.
I did get your driver scripts, and drivers for a Dell E6430, loaded last night and after the deployment it did find the drivers on the server. It didn’t load them because I did’t have the setupcomplete.cmd set up yet. I did make that file on the imaged 6430 and ran it and it did install the drivers (minus one fingerprint reader), so they were there in the C:\drivers. There was one unsigned driver that I had to give permission to install.
This is the same as Windows 10 hangs at “Just a moment…” on Dell Latitude 5500 because I then put the setupcomplete in C:\Windows\Setup\Scripts (which I created; right or wrong) on my golden image. I deployed that today and it still found the drivers, but after finding the drivers it eventually just hung at the “just a moment” screen. This was after about a half hour and I had to leave work, with this machine, so I just unplugged it. After seeing the previously mentioned thread I booted it up and it went to the OOBE, I went into audit mode and indeed all the drivers were installed, but now missing 2 fingerprint reader drivers instead of one previously. So maybe that was the other unsigned driver which caused the hang. I can do more testing tomorrow.
With that setup does it install drivers after the deployment while it’s booting up Windows?
But back on task, it sounds like I’ll need to use the unattend file for the activation code and the setupcomplete.cmd will take care of putting the driver on the target machine. Would there be a prompt or something somewhere in the FOG GUI that would ask for a activation key before image deploy?
Then it is shipped and drivers and activation is done when the end user turns it on. I can see how this would be a huge time saver on my end. I would just be worried about something going wrong with driver installs and activation on the customers end. Drivers not working would be my fault but I also worry about someone entering the activation code wrong. I’m sure there’s ways to safeguard that, someone has to be doing this already.
I’ll get the home lab set up again tomorrow and see what I can get working.
Sorry for the ramble, thanks for the help!
-
@mwilcox said in Windows 10 Driver and Deployment Question:
So maybe that was the other unsigned driver which caused the hang. I can do more testing tomorrow
If there are any unsigned drivers or any reason why the driver install pops up with a question it will fail the install (probably not something you want to happen at a client’s place). There is a bcd edit command you can turn on in your golden image and then turn off in the setupcomplete file that will accept all drivers signed or not. Usually Dell only ships signed drivers. So I’m a bit surprised at the condition.
With that setup does it install drivers after the deployment while it’s booting up Windows?
Yes, but in the golden image we will typically deploy the Dell WinPE driver pack so the golden image has at least the basis drivers. If you are shipping the hardware with Win10 then most of the basic drivers are already built in.
Would there be a prompt or something somewhere in the FOG GUI that would ask for a activation key before image deploy?
If you are using the load and go approach, you are not registering the computers with FOG. Normally when you do a full registration you could enter the key there. But if you are using the load and go approach then you are not registering the machine with FOG so you have to be a bit more creative. In this case you would create in your post install script a prompt to enter the key value, then take that key and update the unattend.xml file using the fog.updateunattemd. Probably that script is where you would want to stop and ask the FOG installer for the key.
Testing is the key even if you eventually end up with a hybrid of FOG doing everything, except you turn the system on at your facility do a QC check (drivers: yes, activation: yes, etc) then ship it to the customer like you do today. The idea is to eliminate as much hands on stuff you do so you can build more systems faster.
