If you’re using Dell machines, you might be able to forget how to import drivers moving forward. I’ve tested this new method with several Dell Models, and so far, It’s been working well.
My Basic Solution:
- Using DISM, import the Dell Driver WinPE pack into the Base WIM
- Now our Windows 7 or 10 WIM Image has all of the Storage & Network Drivers needed
- During OSD, run the Dell Command Update utility to install rest of the drivers needed
- Pros
- No more large driver pack imports
- Works Great in Windows 10
- No more updating driver packs
- As long as Command Update supports the model, you’re already set
- Always uses the latest available drivers from dell
- Cons
- Installs the “Extra Bloat” software along with the driver (sometimes handy, sometimes not) – I’ve submit feedback requesting they add a switch to install drivers only, skipping the add-on software.
- Works So/So in Windows 7
- Requires Internet Connection during OSD if using Dell’s Internet Repo
- You can setup your own Repo, but then you’re managing a Repo
- Downloads can be Quite Large! (I’ve seen 755MB download between several driver updates), could take awhile over slow connection.
Lets Start by downloading the latest WinPE CAB from Dell’s Site
If you’re going to do this in MDT during your Build and Capture, place the files in a folder in the “Application” folder and then reference it during the TS. (I named the folder Drivers Win10x64 – WinPE)
Command: cmd /c dism.exe /image:C:\ /Add-Driver /driver:”z:\Applications\Drivers Win10x64 – WinPE” /recurse
Place the Step after the TS reboots back into PE, but before it’s captured:
Here is my folder of the drivers it injects:
I’ve added an additional driver (Security Folder) that Dell Command Update didn’t get, it was for the fingerprint sensor on the E5470. I grabbed the security folder out of the CAB for the E5470. (Probably fixed the issue on some other models before I tested them)
If you don’t want to add it to your Build & Capture, you can create a normal Package with the contents of the folder, then reference that during your ConfigMgr OSD TS:
Command: cmd /c dism.exe /image:C:\ /Add-Driver /driver:.\ /recurse
Either way will work, I’ve just chosen to add it to my Build & Capture since I’m 99% Dell Shop, and then it saves even more time when deploying a Dell. (However I’m testing on HP, and it seems to be working… I’ll Post later if I can get the HP Updater Software to work right)
Then towards the end of my TS, I have 4 Steps that Installs the Command Update Software, Applies Settings, and Runs it, then reboots. – Will get into more details later.
You’ll need to Create your Settings XML Settings File, install the software on a Dell machine, launch it, configure the settings, then export it. VERY IMPORTANT. YOU MUST CHANGE THE PATH otherwise it will FAIL during OSD.
Preparing the Dell Command Update software:
- Download the Dell Command Update utility from Dell
- Install on Dell Unit and launch software, go to Settings and set them how you’d like:
- General: Make sure you set the location to c:\ProgramData\Dell\CommandUpdate (Otherwise it WILL fail during OSD) – You might have to manually edit the XML document after the fact, I had trouble manually setting this since it’s a hidden folder.
- Schedule: I’ve set this to Manual, as I don’t want it to auto run
- Update Filter: I’ve left defaults but unchecked Bios (since I have a password, this will not work, I used the Application Model to update my BIOS via Script). I also uncheck Input, as it had installed a few things I didn’t really want. I’d recommend installing this on a machine and running it to see what updates come through, then you can change your settings accordingly.
- Export the xml file. – You can DOWNLOAD MINE HERE
- Create your Package Source (Dell Updater & xml file)
- Create the ConfigMgr Package (No Programs)
Now that you have your Package w/ your Dell XML File, you can add the steps to OSD.
- Command Line: Install Dell Command Update Package – cmd /c Systems-Management_Application_4DP6N_WN32_2.1.1_A00.EXE /s /f
- Command Line: Modify Dell Command Update – “C:\Program Files (x86)\Dell\CommandUpdate\dcu-cli.exe” /import /policy OSDSettings.xml
Make sure you set this step to “Continue on Error”. I’ve reported the Bug to Dell, while the import is successful, the program throws an error and will kill your TS if you don’t check that box. - Command Line: Run Dell Command Update – “C:\Program Files (x86)\Dell\CommandUpdate\dcu-cli.exe” /log c:\cabs\installlogs /silent
- Restart Computer.
Now when you image your computer, it will only have the bare driver installed until it runs the Dell Command Update, where it will check for the latest Dell supported drivers and apply them to your system.
Systems Tested:
- Windows 10 1511 x64
- Latitude E6540
- Latitude E5470 – missing fingerprint scanner driver (As noted earlier)
- Latitude E7275
- Latitude E7250
- Latitude E7270
- Latitude E7240
- Windows 7 x64 (kind of works – but I wouldn’t use this to replace Driver Packages, just supplement it)
- Latitude E6540 – Missing Drivers after OSD:
- Resolved by running Command Update Manually after OSD and changing Setting -> Update Filter to “All updates for system model” and choosing the drivers to install.
- STMicroelectonics 3-Axis Digital Accelerometer
- Realtek HD Audio (Used Default HD Audio drivers, it did work
- BayHubTech /O2Micro Integrated SD Controller (used default driver, did work)
- Intel Smart Connect Technology
- Resolved by running MS Updates (wuapp) pointed to the Internet
- After running both:
- Latitude E7250 – Missing Drivers after OSD:
- Resolved by running Command Update Manually after OSD and changing Setting -> Update Filter to “All updates for system model” and choosing the drivers to install.
- Intel Wireless
- Intel Dynamic Platform & Thermal Framework
- Realtek HD Audio (Used Default HD Audio drivers, it did work)
- O2Micro Integrated SD Controller (used default driver, did work)
- Broadcom USH (Dell ControlVault w/o Fingerprint Sensor
- Missing after running Dell Command Update – NONE !
- Latitude E5550 – Same Results as the E7250, just missing a few more drivers, but found them all when running manual update from Command Update:
Takeaways. For New Windows 10 Machines, we’ve switched to this model. No more downloading Dell Driver Packs and applying drivers. Just Injecting the Core Drivers into the WIM, then running Dell Command Update to get the rest and Update to the latest Dell Supported Drivers. On Windows 7, we still use the Dell Supplied Driver Packs, but run Dell Command Update at the end of OSD to update NIC / Video and whatever else it can find.
This is great for testing new Models, instead of taking time to import the drivers, just image it and Dell Command Update will do it’s part to get you far enough along.
There are still quite a few bugs in Dell Command Update 2.1.1 that I’ve been reporting, and I expect with each new version, it will be better and better.
Nice article.
I am trying to do this in WinPe. The article here is very good: http://mickitblog.blogspot.com/2016/05/install-dell-command-update-and-flash.html
Thing is, I cannot get the xml working so it will pull only from a share i have onsite, i never want it to go to FTP site. THought I had the right config, but it still pulled from FTP site.
Any ideas?
Hey Dave, I haven’t tried using it with an onsite FTP / FileShare yet, I’ll Email you to continue the conversation.
Awesome stuff! Thank you for putting this blog together.
This worked for me on my first attempt with a Dell Optiplex 7040 (mff) using version 2.2 of the Dell Command Update.
that’s gold, thanks a lot. After a few month do you still use this? (I’m concerned about all the “crap” that come with the standard drivers package.)
Do you have your own repo or take the drivers directly from dell each time? Does it take much longer than using driver package or family cab from Dell?
Also do you leave the dell command update installed after OSD, and use it during the life cycle of the computer? I’m thinking about just launching the dcu-clie.exe from the package source without installing, any thought on that?
Still using this, it’s been working well. We actually download directly from dell, we have a huge internet pipe, and only image 10-20 computers a day, so it’s not an issue. It does take a little while to run, and probably longer than a normal apply driver step. The “bloat” has been a concern, I run a step later to uninstall the intel wireless proset software if it got installed.
I do leave it installed after OSD, our service desk will run it from time to time if they think an issue my be driver related. I do lock it down so it can only install certain drivers though.
I think the idea of running the command line from a package source is a good idea, I might give that a try in the future.
I want to do the BIOS but I’m concerned if MDT will resume the task sequence, because task sequences tend to break when an application automatically reboots the computer.
For Dell, HP, and Lenovo, there is a no reboot option you use in the command line. In the TS, you trigger the reboot after upgrade by using the built in reboot step.
We’re still imaging with Windows 7 where I currently work, but going to Windows 10 soon. However, I’ve got all steps right, but on the “Run Dell Command Update” step, it will run, but after a while it gives the error 0x00000001. I can close that and it goes in to Windows once I put my credentials in, but then I am prompted to do a restart. I restart and unit comes back up. What am I missing to get this error message?
What Model are you testing on? How long is “awhile”, perhaps it’s timing out connecting to the internet? I’d start troubleshooting by importing a filter with a very few driver options, like just chipset and video, or something, and try again to see if that goes. Does Command Update work normal after OSD finishes on that Machine? You could disable Command Update in OSD, then run it after to see if it gives any errors if you run it manually through the GUI in Windows.
So doing some troubleshooting it was giving error on the docking station firmware. The only thing we will need are bios and drivers, and nothing else. I made the changes, but still getting the same error message. Found out it is failing on installing the wifi driver and deleting the Intel Graphics shortcut. Yet everything installs. This is on a Dell Latitude E5470 which is now EOL. I haven’t tried on a Latitude E6440, but will test Windows 10 for that one. We are using the MDT integration in to SCCM 2012 R2 SP1 CU5. Where should I be placing the Dell Command Update tasks? It could be having the issue that it’s not installing all this in the resident OS, that I have selected. It looks to be installing everything in the PE environment after the SCCM Client is installed. Also, I noticed from the activity.xml log that it considers 3010 an error code vs a success code and that could be causing the issue. The other 2 error codes are 0x2 and 0x3. My only option I can see in the Task Sequence would be to check “continue on error”, but that may stop any drivers from giving an error before it completes everything from Dell Command. Also, we are not the Dell Command Update software to stay installed after it runs. What is the command to uninstall it after all drivers are installed?
Are you having issues with the E5470 on Windows 10? I have not tested Windows 7 on that. I have the Command Update Steps near the end of the TS, but basically anytime after it reboots into the OS should be fine. The Installer is an MSI, so you should just be able to use the MSI Code to remove it 2.3.0 = {EC542D5D-B608-4145-A8F7-749C02BE6D94}. Msiexec -x {EC542D5D-B608-4145-A8F7-749C02BE6D94} /qn or similar.
I’ve got my step set to continue on error. Sorry, no better advice for you there. Consider opening a support Case with Dell, especially about the docking station firmware issue. They are good about getting back to you on these things. If not, hit up Warren on Twitter.
Thank you for the tip on checking “continue on error”. That corrected the issue and worked flawlessly. I was even able to uninstall the Dell Command tool too. I also verified that everything installed correctly. I’ve been fighting for a way to get the drivers updated for the team and this is by far the best that I’ve seen. I also moved the placement of the Dell Command in my Task Sequence. Thank you for the guide you have created on here.
I’ve followed this guide at every step. I’m running the Dell Command at the end of the MDT/SCCM Task Sequence, but it’s not updating the drivers. You can see if you open up Dell Command Update in Windows it show’s it has never check or even updated. What ports does it use when reaching out to the Dell Support site? It could be that our Security Team is blocking it from communicating out to the site. However, I can run it and it shows that it had driver updates. What am I missing in the TS. This is during an install for Windows 10. Thanks.
That’s accurate, it will not display the Last Check time in the Command Update when you run it from OSD due to different profiles… However, if you set a place for the Logs during OSD, you can check there. After OSD, in my “InstallLogs” folder, i have the ActivityLog & inventory log. when you run it in OSD, as long as you set the /LOG c:\…. then you will have the logs, that should help you troubleshoot.
Hi Gary,
This post is great and thank you so much…one QQ, The schedule update , will it run or prompt for updates after a Month ? or just during the OSD
I thought it was set to just run, but I didn’t get around to testing that functionality before I left my last job. I had always disabled the auto update feature, planning to circle back and test… but that wont’ be happening now. Hopefully I’ll get a few Latitudes at home eventually and can continue to test.
Thanks for posting Gary. I’m working with version 2.3.1. When I run the installation of DCU manually from an administrative command prompt, it installs fine. That was my initial test. Upon adding it into MDT(not sccm), using this install command with the raw update package:
Dell-Command-Update_X79N4_WIN_2.3.1_A00.EXE /s /f
spit out a reboot code and failed. Nothing ever installed. I didn’t quite understand what was going on. I then extracted by running the exe manually and choosing the “Extract” option. Then I tried running the setup within and found it was extracting an MSI into a C:\Windows\ location. I grabbed the MSI, used the /qn /norestart swtiches and was able to get around this 2 hours later. I hope this saves some time for anyone with MDT running into the same issue. It was puzzling. I hate wrappers!
-LvilleSystemsJockey
I have tried this with the old 2.1.1 and the new 2.3.1 version and I get the same result.
When I follow the steps above and run from a task sequence, the application gets installed fine and the “dcu-cli.exe” /log c:\temp /silent” cmd runs and creates the log file but fails in the ActivityLog with CLI: Error: Check for updates ended. (System Scan failed).
If I run this manually in a cmd prompt with my account or the local system account (the one that sccm uses) all works fine and drivers start to download. Any ideas?
ditto – i also have this problem. no idea what causes it or how to fix it
Regarding the “modify” step in which the XML is imported, this causes a “Dell Command | Update (CLI Version) has stopped working” dialog box during the task sequence. Interestingly, the file is clearly imported by the new settings. Anyone else ran into this issue? I don’t get the error when running the command manually afterwards, just during the task sequence.
interesting, I think I’ve seen it throw errors, even though it imports, but it’s never caused the process to completely crash. Do you have “Continue on Error” set for the import step? I would suggest doing that if you haven’t already, and since you can confirm that it is actually importing your xml file, then see if the CLI works to update your drivers.
Did anyone find the cause and resolution to the below ?
ActivityLog with CLI: Error: Check for updates ended. (System Scan failed).
I too had the “(System Scan failed)” during OSD TS. Was driving me crazy. Worked manually, worked after OSD. Spent many hours troubleshooting, and after 12 iterations I finally figured out what’s causing it: “8dot3name” While in WinPE, the 8dot3name name creation is NOT enabled, so c:\_SMSTaskSequence is created WITHOUT an “_SMSTA~1” alias. When dcu-cli runs, it would run from there, and work, but when it invokes “c:\Program Files (x86)\Dell\CommandUpdate\InvColPC.exe”, THAT would fail with a syntax error complaining about the “-enc” switch.
Fix is to configure your TS Step to “Start in: C:\Program Files (x86)\Dell\CommandUpdate”, or technically any other folder but C:\_SMSTaskSequence. :-)))
You could potentially also enable 8dot3name creation in WinPE, but I didn’t test / try that.
Hope this helps others who has this issue.
A virtual beer for you Superhenko! I had the exact same issue and was desperate for a solution. Now it´s working perfectly during OSD TS too. Thank you very much for posting your solution 🙂
Anyone done any of this on the new v3.0 UWA version?
Can’t find details for importing the xml in any documentation or triggering a update check. I know there is the 2.4 win32 version but this doesn’t support BIOS passwords so only good for the build then not after that.
You still need to use the 2.4 version. You can use it to update BIOS if you remove your BIOS password first, then re-add it. I did successfully test that process. Use CCTK to remove password, run DCU to upgrade drivers & BIOS, then use CCTK to enable password again. I believe they are working on a future release that will work with BIOS password that you can still use in a TS, that will not be completely UWA based.
Hi Gary,
I have been using 2.4 version of Dell Command Update to supply latest drivers and BIOS during OSD. Now Dell has released 3.1 version with new switches and parameters. Did you get a chance to test 3.1 version of Dell Command Update?
No, not yet. 3.1 was just released, and it’s been overly busy… but I plan to dig in to 3.1 in the Jan – April time frame…. hoping to be knowledgeable again about the product before MMS.
Hi,
great article, here in the dell command update software can not go to the internet deposit of dell, how to make a local deposit.
seen in dell command update to add a deposit but I don’t understand the catalog.xml, as I have the sccm 2012r2 solution, is it possible to use it.
Thank you for your help.
It is possible to create a local repository for Dell Update to use, and it will all work with CM 2012 R2 and newer, but it’s not something I’ve done. Contact your Dell Rep, they should be able to connect you with Dell Support who would have info.
warning with version 3.1.0, impossible to synchronize with the local repo, an internet connection is launched !!
I am still unable to get 3.1.0 to install drivers via the task sequence. Any suggestions?
I haven’t tried 3.1.0. Probably won’t for awhile as we don’t use this tool / method at my work place, so it’s just trying things out at home on my own time. Reach out to your Dell Support team, they should be able to assist… if they can’t, I know some other vendors with awesome tools. 🙂
Hi Gary,
I realise this is an old post, but was hoping to get some insight. I’m currently piloting DCU 3.1.3 for driver maintenance of my estate and then I was going to add it to the TS. My question is around monitoring and reporting on what DCU does. I can’t seem to find any meaningful log files to monitor or any other data points to scrape. Any ideas?
Thanks!
That’s a good question, and something I’d too be interested in knowing. I’ve barely touched DCU in the past few years, so I’m pretty rusty. I’d recommend hitting up your Dell Rep, or Dell Enterprise Support. If this isn’t a feature they have built in (running DCU in audit mode with logging), then it is something that should be added.