If you have setup your driver drivers like I have in which they are separated by OS-->Make-->Model, you will see duplicate drivers in each Model folder. This is caused by the fact that some drivers exist in more than one category. Although you have setup the driver folders in the GUI portion of MDT, MDT sorts them differently in the windows folders. It sorts them by driver type, such as display, bluetooth, modem, and such. They are sorted in the GUI interface through the XML file that sorts the GUIDs into the groups you specified.
Within each group folder, you will see duplicates with (1), (2) and such appearing after the name. This is because a driver may exist under both System and Net for instance. The NIC driver is commonly put in with the system drivers besides the network drivers folder, thereby causing it to appear twice.
To trim the driver list down, sort the Name field. When you find your first duplicated driver, look at the dates on the original and the dupe. If they do not match, then select the oldest ones to delete, leaving just one. Under the actions list, click Delete under the driver name, NOT under the folder name. If you click delete under the folder, the entire folder will be deleted. I have done that and could have kicked myself afterwards, so pay close attention. Once you click delete, do NOT select the Completely delete these items, even if there are copies in other folders. (Force)! If you select this, it will delete that driver across all models and types. I did this and then found out when building other model machines, they were missing those drivers. I had to go back and re-import the drivers for every model. When you leave it unchecked, it only deletes the pointer to the driver and not the actual driver.
Next, you will see duplicate drivers, except with different versions. You will most definitely want to clean up this list so that only the latest driver is there. For instance, I had one model that had 6 versions of NVIDIA Display NVDW.INF in the list. I deleted all, except for the latest one. I also made sure I only deleted it from the list and not completely from the folder.
This not only cleans up the number of drivers copied down during the build, but it also ensures the latest driver gets installed too, as I do see on occasion that the older driver got installed.
NOTE: Before you do any of this, make sure you have the original drivers that you imported into MDT in a windows folder, as if you make a mistake and need to re-import them.
Within each group folder, you will see duplicates with (1), (2) and such appearing after the name. This is because a driver may exist under both System and Net for instance. The NIC driver is commonly put in with the system drivers besides the network drivers folder, thereby causing it to appear twice.
To trim the driver list down, sort the Name field. When you find your first duplicated driver, look at the dates on the original and the dupe. If they do not match, then select the oldest ones to delete, leaving just one. Under the actions list, click Delete under the driver name, NOT under the folder name. If you click delete under the folder, the entire folder will be deleted. I have done that and could have kicked myself afterwards, so pay close attention. Once you click delete, do NOT select the Completely delete these items, even if there are copies in other folders. (Force)! If you select this, it will delete that driver across all models and types. I did this and then found out when building other model machines, they were missing those drivers. I had to go back and re-import the drivers for every model. When you leave it unchecked, it only deletes the pointer to the driver and not the actual driver.
Next, you will see duplicate drivers, except with different versions. You will most definitely want to clean up this list so that only the latest driver is there. For instance, I had one model that had 6 versions of NVIDIA Display NVDW.INF in the list. I deleted all, except for the latest one. I also made sure I only deleted it from the list and not completely from the folder.
This not only cleans up the number of drivers copied down during the build, but it also ensures the latest driver gets installed too, as I do see on occasion that the older driver got installed.
NOTE: Before you do any of this, make sure you have the original drivers that you imported into MDT in a windows folder, as if you make a mistake and need to re-import them.
Mick, i love this and have been looking for something like this for a very long time. However, how does one go forward and keep the duplicates out after cleaning them up using your process? I add new PC models all the time and even before reading your post I organize my Out-of-box-Drivers in the OS-Make-Model structure but in my task sequences in MDT i have a driverGroup detection that does a wmi query for the make & model so it gets the right drivers. If I have cleaned out drivers under a particular folder model but it exists elsewhere in the server, how is my PC deployment going to receive the proper drivers after all?
ReplyDeleteThat is the difficult part. I hate to say that I have never found another way to keep those duplicate drivers out, other than going back through this process. I know, it is a real pain.
DeleteThe problem I have now is that the duplicate drivers has grown so much that the MDT process won't boot be uses it says there is not enough memory to create a ramdisk device and it led me to this. I just don't know what I should do going forward. One post I found me ruined creating individual task sequences for each model and setting the driver group in that way but it still doesn't seem ton address the duplicate driver issue. The only way I see that working is if you dump all the drivers in one folder and the system detection process will grab the drivers as needed but it makes driver management virtually non-existent.
ReplyDeleteI had the same problem. What I ended up doing was to import only network drivers into the WIM files. We use Dell systems, so I left the driver updates to depend on the dcu-cli.exe to download the updates in real time from Dell's site. That way I never have to update them again, except for new models and they are always pushing new updates to the systems when it is being built.
DeleteThat sounds interesting but I am not familiar with the dcu-cli.exe. We have many Dell models we have to manage as well but are you saying you are only adding NIC drivers to the WIM file. We use a USB boot drive to connect the PC to my deployment share. I would be very interested in trying this if you can explain to me how you are using the dcu-cli to get the updates in real time from Dell's site. That sounds almost foolproof.
DeleteDoes using the dcu-cli make your image deployments faster or slower?
DeleteI am hoping what you respond with would allow me to continue using my WMI query to select make and model to get the right drivers. In my experience it has made it so simple because I can keep with 1 or 2 task sequences, 1 for 32-bit and 1 for 64-bit. And all of the driver selection for the models happens in the background. If I could somehow use this dcu-cli in that same process to pull down the right drivers, that would be so cool. Please share what you can on that, how I can implement it.
DeleteI wonder if I can download the Dell Command Utility and have it install during the image deployment process and then run afterward to pull down drivers. I am going for something as close to automated as possible here as I am sure you have guessed.
DeleteThe dcu-cli is the executable from Dell's Command | Update application. All you have to do is setup the dcu-cli.exe as a task sequence with no switches. It will automatically go to Dell's website and install any drivers and/or Dell Applications that need to be installed or updated. It does slow the build process down, but it also frees you up from having to constantly update the drivers.
DeleteOne thing I forgot was that it will also update the BIOS
DeleteThat is excellent thank you. I was handling the BIOS updates separately using an element in the task sequence and it works pretty well. I simply setup a folder structure repository for the %model% and then the bios updates are renamed to BIOSUpdate.exe and then a text or blank file of the current version like "A15". But I am thinking I like the idea of it always pulling the most current one using the DCU utility. How much difference in time would you said it slows down the build? I am on a slower link that we are normally on so that will hurt us initially but we are normally on fiber which is no issue.
DeleteIt depends on the model system, but typically it slows the build down by about 10 minutes.
DeleteI will post the PowerShell script I use to execute the DCU. I actually use a powershell script so that it disables the BIOS password first in the event it needs to update the BIOS.
ReplyDeleteI might continue to do the BIOS updates the way I have been doing them since I can easily manage those versions and use your way of getting drivers.
ReplyDeleteWhere will I be able to see the PowerShell script you use to execute the DCU. We don't use BIOS passwords at all but that is nice too. Does your PowerShell script install the DCU or would I have to address the DCU install in a different way?
ReplyDeleteI have rewritten my script that executes the Dell Client Update application to be able to be published here. I will publish it tomorrow.
DeleteGive me one more day. I just published another script today. I will definitely publish this tomorrow.
DeleteThis comment has been removed by the author.
ReplyDeleteOddly enough now I have a new problem. We just received the new OptiPlex 7040 with the Skylake chipset. It keeps saying that it can't find the deployment share and I have every NIC driver known to man added for that model it seems. So I guess I can't load this with MDT 2013 Update 2 after all. The PCI ID is VEN_8086&DEV_15B7&SUBSYS_06B91028&REV_31 which comes back as an Intel(R) Ethernet Connection (2) I219-LM but still nothing allows that thing to see my deployment share. I think I am dead in the water so to speak. I have seen many posts about this same problem but no fixes really.
ReplyDeleteAre you using the driver sets from the Dell enterprise driver site?
DeleteHere is the link to the blog posting as of this morning. http://mickitblog.blogspot.com/2016/04/using-powershell-to-control-dell.html
ReplyDeleteYes I was but I figured it out... I had to use DISM to inject 2 hotfixes for this very issue and it is imaging fine now. Now I am ready to do the Dell Control Update program. While I was waiting to hear from you, I modified by task sequence to install it silently which it did successfully. Then I tried just running the dcu-cli.exe and it seems to automatically run and download and install which is great. I guess I could add an execute program in the task sequence later on that will run this but the problem is I use a standard task sequence for all systems so i would want only the Dell Command Update and the running of it to execute on only Dell Systems which I could accomplish with WMI query I suppose. I will look at your script, maybe it is much easier.
ReplyDeleteHey Mick, is there any chance we could just resort to email back and forth only long enough to get me going with your script? I tried running it without any params and it seems to just update everything which I think is what i want. We don't use BIOS passwords so there should be nothing to disable there. Do I just create a new run powershell script in my task sequence and reference %scriptroot%\Update.ps1 and just let it run with no switches?
ReplyDeleteI am finding that on some of our Dell Models that Dell Command Update doesn't get some of the updates. In multiple cases I have had to go back and manually install the USB 3 drivers and the Intel Management Engine driver that the utility missed. How do you typically handle the drivers with your script? Do you end up loading more drivers in the out-of-box drivers section for your systems other than network? I am trying to not have my driver cache grow too large and then not boot my WMI.
ReplyDeleteOne technique I use to trim down the size of the PE is to only include network drivers and mass storage drivers in the selection profile for the WinPE, and also ensuring that the drivers in that profile correspond to the PE version. I created a selection profile just for WinPE and because my MDT uses WinPE 5.0, I need to only include Windows 8.1 drivers in that selection profile. It makes no sense to include Win 7 or Win 10 drivers there. Also, if you use Dell systems, Dell packages "family" cab files (or combo cabs) that will provide support among several models. I would recommend importing these family cabs into the Selection Profile for WinPE rather than one cab file for every model. Dell also provides cabs specifically for WinPE and using those will significantly trim down your PE size and cut down on the time required to update your deployment share and generate the WIM or ISO to boot WinPE.
ReplyDeleteI like that approach but I have already spent a lot of work creating a single task sequence for our standard load for x86 and one ofr x64 and within that sequence I have a "SetDriverGroup" that performs a wmi query to select the proper model and push out the appropriate drivers. However I have wiped my driver library and started again because it grew too large. Now I am only importing chipset and NIC drivers per model to keep things small and then the Dell Command Update is installing the remaining drivers and so far that has been working rather well with the exception of the occasional missed driver.
DeleteOne new thing I am getting now too since implementing this script is at the end of my deploymen I am seeing the following text:
ReplyDeleteException calling "SetBufferContents" with "2" argument(s): "The method or operation is not implemented."
At line:9 char:33
+ $Host.UI.RawUI.SetBufferContents <<<< {$rect, $space)
NotSpecified: (:) [], MethodInvocationException
I have no clue what any of this means or what file it is referencing but it was not doing it until I added the Dell Command Update in my task sequence? What could be going wrong?