/build/static/layout/Breadcrumb_cap_w.png

Windows 10 Image Deployment - Drivers not copying

Good morning,

I am attempting to deploy a Win10 image using a K2000, I've copied the image to the server and it deploys using a PE5 KBE. However, when it gets to the driver section, it does not seem to copy anything. I've checked the scripts in the peinst directory, and there doesnt seem to be any reason why they wouldnt---the script seems to grab the product from the registry ("windows 10 enterprise", wheras in the past it would have been "windows 7 enterprise") and then compares it to the strings in drvstr.cfg, which does indeed contain a line for Windows 10:windows_10. I have a windows_10_x64 directory with the same product names (but proper Win10 drivers from Dell) in my postinstall directory. 

Any idea why this does not work? 

2 Comments   [ + ] Show comments
  • Robcav, I added the windows 10 OS section to the drvstr.cfg thinking that would be all that is needed for this to work (same line as your thinking). Unfortunately, I don't have any hardware to test that has Windows 10 drivers. Did you run the driver_feed_discovery_tool.vbs? What does the output look like? During the midlevel task when copy_drivers runs, what happens in the commandline window?

    -Corey - cserrins 8 years ago
    • To be honest I can't tell... The window closes almost as soon as it opens. I was going to modify the script to output some debugging info but it seems like the folder is read only even when logged in as Admin. How did you modify the drivers config file? I was unable to login with sufficient credentials to modify it; the windows 10 entry was already there when I opened it. - robcav 8 years ago
      • robcav, I work for Dell and am currently in charge of modification of this file ;) - cserrins 8 years ago
    • What I tried doing is manually adding a mid level task that calls dism and points to the directory I created. Unfortunately it doesn't have the intelligence to determine the model, but i only have two classrooms using win 10 for this year. I can afford to write two manual scripts. I'll let you know if that works. - robcav 8 years ago
      • As a midlevel, manually run the copydriversdbg.vbs, that is the same as the copy_drivers. You can also move that to petemp, make modifications for testing. Let us know.
        -Corey - cserrins 8 years ago
    • it seems that the version of dism I was using was outdated and that might have been causing the issues with both the automated and manual driver addition. I rebuilt a pe10 KBE and I'm trying that now - robcav 8 years ago
    • It also seems it was truncating at 9030, while I had followed the pattern I found in the win 7/8 folders of including AIO in the naming. Trying again ONE more time before the day is over - robcav 8 years ago
    • OK So I think I solved it. I had to build a new KBE with Windows 10 PE. Also, for some reason the copy drivers script was removing "AIO" from the model, thus looking for a "9030" directory, which I did not have. Once I renamed the directory to 9030 (I made a duplicate, actually) and ran it in a PE10 KBE it worked as it should. I am concerned, however, because the script did not retain the "AIO" name... are the AIO models identical to the mini-tower models? (I dont really know if there is a 9030 tower, but there is a 9010 tower, and I happen to need to put Win10 on 20 9010 AIOs). I've looked at the Windows 7 and 8 folders and it seems like they keep AIO in the name, or do something like 9030-aio. What is the preferred naming for folders in this directory? The KACE script seems to disregard AIO, but the driver feed pulls down folders with AIO in the name. Its not a huge deal, because like I said we only have two models getting Win10, but it may affect us in the future. - robcav 8 years ago
  • I have the same issue back with windows 8 came out. the problem was that I was using the old KBE which had the old dism. i rebuild the KBE with the new OS and upload it to Kace. I was able to get the search for drivers working again. - roozbeh 8 years ago

Answers (1)

Posted by: bflood2000 8 years ago
Senior White Belt
1
I had the same issue.  The issue was I had a old Driver feed Discovery tool. The old one read win 10 with the enterprise name in it.  The newer one did not.  Once I ran new discovery and changed to drIvers_postinstall\dell\windows_10_x64
the drivers did install.  

Comments:
  • I had two issues, first I was using an old KBE: it needs to be built from Windows PE 10. Second, the script calculated the model to be a "9030," while I had put the drivers in "9030 AIO," following what I thought was the convention (because thats how it looks in the Win7/8 folders----but that could be other admins messing around). Once I renamed the folder 9030 everything worked fine----I just don't know why its clipping the "AIO" part, unless the hardware is the same regardless of form factor. - robcav 8 years ago
    • I'd be really interested in knowing if now that the folder is just 9030, if deployment would work with PE5. I truly don't feel that PE10 is needed. If you look at the 9030 detail page, you can see the install location "windows_7_x64/feed/dell/9030" this is in indicator of how what folder name should be. Now the wmi call to the machine includes the AIO, but if we look at the drvstr.cfg file we see the following, "MDL:9030 AIO:9030" showing that if the script sees 9030 AIO, make the model just 9030, this is so it matches that download extraction location.

      -Corey - cserrins 8 years ago
      • When I manually ran DISM from CMD it failed with an error similar to "This image cannot be serviced with this version of DISM" when running in PE5. - robcav 8 years ago

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ