Help with Win10 Driver injection
-
@MotD I’m going to fork this discussion into a new thread since your issue is new and I don’t want to fill up this thread with a new issue.
We really need you to setup a debug deploy to this lenovo. The numbers you have look correct for what I remember of the Lenovo systems. So you may be spot on.
So schedule a image deploy to this computer but before you press OK, select the Debug check box. Then pxe boot the target computer. After a few enter key presses you should be dropped to the FOS engine command prompt. From there I want you to key in this command.
dmidecode -s baseboard-product-name -
@george1421 Ok, i made it this way you say.
The result is: 20F10026GEThe same result from the Way with dmidecode212 under Windows:
dmidecode212 -s baseboard-product-name
result: 20F10026GE -
@MotD OK good to know. Lets switch over to chat it will be faster to get an answer.
-
@george1421 After a lengthy chat session then switching to team viewer we found the issue.
Basically the fog.driver script was throwing this error:
/images/postdownloadscripts/fog.drivers: line 2: $’\r’: command not found /images/postdownloadscripts/fog.drivers: line 3: $’\r’: command not found /images/postdownloadscripts/fog.drivers: line 4: syntax error near unexpected token $'in\r'' 'images/postdownloadscripts/fog.drivers: line 4:case $manu inThe key to me was seeing the \r that was being complained about.
In a nutshell the issue was how the file was copied from the web, pasted into notepad++ on windows and then copied to the FOG server using winscp. Somewhere along the way carriage returns where added to the end of each line in the script. I installed dos2unix and ran that utility on the fog.drivers script. That cleaned up all of the errors. We again single stepped through the install process. I confirmed that the source path existed as well as the files on the target computer after the fog.drivers script completed.
When I left MotD he started to reboot the target computer to start the Win10 OOBE process.
Summary: The issue was related to the Windows->Unix file migration only. The script worked as outline in the thread.
-
@george1421 all drivers was installed correct, so my unattended File works. And the FOG with the great Help from you. Many Thanks.
Next Week i test it with the HP Machines i have, some HP ProDesk 600 G1 and G2, HP ProBooks G2 and G3. The Information from DMI i got todays afternun.
-
@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.
