Help with Win10 Driver injection
-
@MotD Hey there Motd. So I took a break off of this for a while due to being busy with work projects.
So when you added your drivers onto the fog server for Lenovo, the product name worked compared to for example Lenovo ThinkPad T570? -
@Jamaal If your Lenovo was inventoried by FOG, look at the fog web gui
host management -> Host (in question) -> Inventory (tab) and then what does the System Product field say? For the Dells it says ‘OptiPlex 7050’ or what ever model it is. If I remember correctly the lenovo systems put the actual system model/name in a different smbios field than Dells. That name needs to be the parent directory where the drivers are stored. -
@george1421 ok, I get it now. I’ll play around with it this weekend. And thanks to you, I have a better grasp with MDT 2013 update 2. Do you do what most do like have 2 WIMS? Example, one will be a reference image with like antivirus, office 2013, VNC with up to date windows updates and the other WIM will be a little fatter with other company in house apps that are a little harder to auto install?
-
@Jamaal I don’t have WIMs per se. We use MDT to build the reference image each time. So far we have found almost all applications install using the application’s unattended install method. So our MDT reference image build is all automatic (lite touch). We do have 2 reference image, but one is bios based and the other is uefi based. Other than the firmware version they builds are exactly the same.
-
@george1421 Ok, my bad, I meant reference WIMs. But for example, how do you handle in house apps to install and configure automatically? We have a few apps that’s in house and we need to configure the settings after install, 1 app we need to configure to point to the G drive to a server for example and our old way we used the USB and bring down the image with Acronis, which I don’t want to do anymore, know what I mean?
-
@Jamaal The in house applications are a bit more problem since they are probably not built for unattended install. If you have the ability to create the installer for unattended mode then its possible.
1 app we need to configure to point to the G drive to a server for example
I would have to ask you where is that information stored? In the registry or an ini file? If its registry then its pretty easy, just export the registry tree where the settings have already been set, then as part of your MDT application install then just reimport the registry on the target computer.
I can tell you with MDT, once the task sequence has finished on the target computer and displays the end of sequence status panel. At that point the target computer IS still in audit mode. You may continue adding applications and adjusting settings. Just don’t reboot or sysprep until you have finished making tweaks to your reference image.
-
I think they’re mostly coming from the ini files. I would need to check.
If worse comes to worse, I can boot the vm, add in the third party apps and when I’m done with everything, just run light touch to sysprep it, correct? Also if I go that route, where should I configure the unattended file? From the unattended tab in MDT? Or directly on the vm like c:\windows\panther for example? I think the unattended file I got confused with last year on where to edit and think that’s another reason why my drivers didn’t transfer over. -
- If your configurations are coming from ini file, why not just copy the “fixed” ini files to the proper location during MDT sequence steps?
- Lite touch is a build methodology. i.e. you launch the task sequence and then don’t touch the target computer until you sysprep. Everything is installed and configured as part of a task sequence. Its not possible to do this 100%, but you can get pretty close.
- I have a standard unattend.xml file for our builds, I started with an online unattend xml generator [http://www.windowsafg.com/] to create a generic unattend file. Then we updated it (by hand and via WAIK) to have the features we needed in the target system. I have a task sequence in MDT that copies files to the target system that we will need later. Three of the important files are the unattend.xml, setupcomplete.cmd, and a batch file called sysprepper.cmd. We use that sysprepper.cmd batch file to copy the unattend.xml and setupcomplete.cmd files to their proper locations as well as several other config files, then call sysprep with the /shutdown option. Then we pxe boot and capture with FOG. Understand this is not the unattend.xml that is used to build the MDT image (what you would edit in MDT/WAIK), but this is the unattend.xml file that is used during sysprep and OOBE after the image has been cloned by FOG.
-
@george1421 Ok, I’ll work on getting them automated. One more question. So the file you’re referring to called sysprepper.cmd is what you built to copy the files? Or can I look it up online to create that file? Where in the task sequence do I put it in to copy those files? Can you send a screen shot for example? I’m assuming copying the custom unattended.xml file replaces the one MDT uses during deployment?
-
@Jamaal Hey wait, that was more than just one more question.
sysprepper.cmd is a batch file I created to do last minute clean up just before sysprepping the system. That way all of the clean up steps are done every time the same way for automation. The batch file is manually run. The last command in sysprepper is to call sysprep and power off the computer.
To copy all of the specific files (scripts, logos, pictures, config files) from MDT to the target computer during reference image build I used the instructions from here: https://mdtguy.wordpress.com/2014/07/30/how-to-copy-folders-in-mdt-like-a-boss-the-easy-way/ That way all of our required scripts are placed on the target computer during reference image build.
There are actually 2 unattend.xml files being used here, but they are used at different times. The first unattend.xml file is created by MDT for the specific reason to build the reference image. MDT manages this unattend.xml file. The second unattend.xml file is used during sysprep and oobe of the target computer after FOG places the image on the target computer. This unattend.xml file may have instructions about creating local accounts, connecting to AD, target system naming all things you need to avoid OOBE asking questions during the imaging process. This is the unattend.xml file you create to customize the target computer to your company’s needs.
-
@george1421 lol, yea sometimes I slip a few more questions last minute
ok, I heard of them and I’ll start working on things. I’ll reply back in a few days or so letting you know how I made out. Thanks again for your help. -
George,
Not sure if you’ve done this with MDT, but I’m having issues using WSUS Offline updates for Windows 10 Ver 1709. I got a reference from IT Bros, but still errors out when updating with updates. https://theitbros.com/integrate-wsus-updater-with-mdt-2013-to-deploy-windows-10/
I even tried looking at the YouTube link, but still fails, won’t run Windows Offline install, but will mount the drive with no issues. Do you know another way?
-
@Jamaal I don’t use the offline wsus package during MDT deployment. I just have MDT connect to my local WSUS server and get the updates from there.
So it maps the Y: drive no problem?
at the end of the MDT run, can you manually map the Y drive as the deployment user then run the following command via a command prompt? “Y:\DeploymentShare\Scripts\client\update.bat”? Where does it error out in the process?
but looking at the code how does it get from this
cscript.exe "%SCRIPTROOT%\ZTIConnect.wsf" /uncpath:\\10.24.0.70\DeploymentShare\Scripts\clientto knowing what the Y: drive is and that the files are in
“Y:\DeploymentShare\Scripts\client\update.bat”Also if the mapping command was magically picking the Y: drive then the path root isn’t consistent
/uncpath:\\10.24.0.70\DeploymentShare\Scripts\clientSo \10.24.0.70\DeploymentShare\Scripts\client would equal Y:
Then the execution path is
Y:\DeploymentShare\Scripts\client\update.batSo the real path on the server would be
.\DeploymentShare\Scripts\client\DeploymentShare\Scripts\client\update.batNot logical
-
@george1421 said in Help with Win10 Driver injection:
.\DeploymentShare\Scripts\client\DeploymentShare\Scripts\client\update.bat
yea it’s driving me nuts here, lol. The reason I was gonna go this route was because for some reason, the WSUS is taking forever to download the updates. I let it run for a few hours and I also noticed some errors in WSUS it was trying to download Office 2013 Service pack 1. Would you know on how to speed that process? I have Server 2012 R2 and tried things like increasing the Application Pool that I saw online on IIS. I’ll play around with the offline again shortly as well.
-
@Jamaal For windows 10, WSUS works just fine, updates in less that 20 minutes. For Windows 7 it would take hours to run. I think my vm for win10 has 4 vCPU and 6GB of ram.
For packages like office 2013, I do use wsus offline to download the office updates, but then I place them in the application’s update folder so that when office is installed it also installs all of the updates automatically. That won’t address your slow update issue, but it is a way to speed up the wsus online update process.
-
@george1421 ok, I’m gonna try that route for the updates. Just curious, what classifications do you use in WSUS for Windows 10? I selected Windows 10 and windows 10 updates and latest build I think, don’t remember.
-
@george1421 and when I get to this process on copying files, where should I tell Fog to copy the unattend.xml? Into c:\windows\system32\sysprep? Or the panther folder?
-
@Jamaal The c:\windows\panther folder is the first place OOBE looks for the unattend.xml file. You really can place it anywhere if you call out the specific directory when you run sysprep. But I’ve never been one to push luck. I place the file in the Panther directory and call out the specific path when sysprep is run.
As for how wsus is setup for win10, I’d have to look at the wsus server for that.
-
@george1421 hey George, so I see what the problem was with WSUS. I thought the content folder can be put anywhere since it said remote path. I tried my NAS both network path and iscsi, but still locks up the downloads. I did research and said it’s not supported in a network share, so I put it back on the local.
Now for the Office 2013 updates, I found this online to extract the service pack 1 and I was able to get the updates faster compared to WSUS.
https://www.howto-outlook.com/howto/slipstreamoffice2013sp.htm
I’m working on the unattend file and will work on copying files this weekend. The offline script I was following sucked and didn’t work no matter what I tried. I’ll keep you posted. Thanks for leading me in the right direction.
-
@george1421 George, I started playing around with the copy script and worked good copying to the Windows 10 client, but I didn’t do fog as yet. I just booted the VM after MDT to test it out and got through setupcomplete.cmd to copy over, but looks like the unattend.xml didn’t make the changes. Any ideas? I didn’t see the c:\drivers folder create even though I used WSIM to add the line? Do I need to call the command to create the folder drivers as well?
