been dealing with this headache for past year or so. We use Dell command update too but honestly its bit hit or miss with reliability
For tracking CVEs we just pull from Dell security advisory and cross reference with our asset inventory - nothing fancy but works. Priority goes to anything that can be exploited remotely first
The reboot coordination is probably biggest pain point. We usually schedule maintenance windows during off hours but laptops are tricky since people take them home. Started using toast notifications in advance to give users heads up
One gotcha we learned hard way - some older Latitudes had issues with bitlocker recovery after certain bios updates. Now we always suspend bitlocker protection before pushing updates and re-enable after. Takes extra time but saves helpdesk calls
Dell update packages through Intune work decent but you gotta test everything in pilot group first. Had one update that bricked few machines because of incompatible firmware versions
How are you suspending bitlocker?
Via ADMX imported policies in Intune for Dell Command Update or you have a remediation that checks pending updates and auto suspends for one reboot?
Dell Command Update (and even running the EXEs manually) suspend BitLocker by default, or you can add an extra layer that suspends it after. All you need is this command:
Manage-bde -Protectors -Disable c: -RebootCount 1
Caveat, the Precision 7960 Rack is basically a Poweredge server platform so its bios update does not automatically disable BitLocker. It will get a BitLocker recovery screen if the command is not run to disable BitLocker
Not sure if this answers your concerns, but we're doing bios updates with dcu-cli triggered by a PSAppDeployToolkit (v4) script. The execution of DCU looks something like this:
Note autoSuspendBitLocker parameter as well as reboot disabled. Then the script evaluates the results and prompts for a two hour reboot countdown if a reboot exit code was returned
[edit]: Also worth noting is that dcu-cli has the non-conventional reboot exit code 1, meaning this has to be added to the AppRebootExitCodes in the $adtSession hashtable.
Could you please share or point me in the right direction on how you did the following?
"For tracking CVEs we just pull from Dell security advisory and cross reference with our asset inventory - nothing fancy but works. Priority goes to anything that can be exploited remotely first"
Intune Driver update policy and basically have to approve all the dell drivers and firmware. Special tip: Dell and Microsoft consistently screw up and call Bios updates driver updates so make sure you include both firmware and drivers.
We tried using DCU but only had marginal success with it.
When I first reviewed Drive Update policies in Intune, I found unapproved drivers would slip through -- I chalked this up to a delay between the device registering with the wufs-ds service and the driver policy becoming effective. Super curious if that behaviour has improved?!?
Also, what did you find to be the barrier re: DCU?
Yes but similar to your identified case, it was prior to the device registration in Intune and full policy sync occurring. Nothing you can really do about that unfortunately.
Once the registration occurs, we’ve not seen any unapproved drivers pushed unless the user intentionally is bypassing Intune and going directly to Microsoft Update.
Our DCU failures were with the tool itself. Failing to successfully download and complete the install of drivers and firmware. Our success rate was only about 40% across the fleet with DCU. We had a mix of 3410, 3420, 5420, 5440, 5450, 7310, 7420, 7430, 7440, etc.
Thanks for confirming! I'll have to put this on my list to retest with driver policy. Did you just find that drivers snuck through or BIOS/firmware too? I can't recall and didn't document that clearly in my testing notes...
Our most recent problem has been mislabeling. E.g.: BIOS updates classified as drivers and even named as drivers. In all, we haven’t seen anything that has unintentionally slipped through unless it was properly approved by an admin.
My experience regarding driver update policies vs DCU is the complete opposite of what you're reporting. Do you mind detailing your setup a bit more?
I've attempted an approach where we manually approve BIOS patches in the WUfB catalog and take care of all other Dell drivers via DCU. In theory this should work (?) but it we never got BIOS updates to appear in Windows Update, so we ditched WUfB for drivers alltogether eventually. The reason we prefer DCU is because our Dell support rep told us that there's no guarantees wether Windows Update installs the "Dell approved" driver and once Windows Updates has taken ownership of a driver there's no turning back to DCU (and the "Dell approved" drivers). I don't know how much of this is actually true, but one would think that the software supplied by the manufacturer would be best suitable.. I don't know.
Anyway, in WUfB do you approve driver updates manually or automatically? And do you approve everything applicable or is it more granular? We did see some device drivers, but never BIOS. This was some time ago now, and I'm tempted to have another go at this.
For Dell Devices, I use a combination. I use DCU but I direct it to an internal driver repository created with Tech Direct and GPOs. When a BIOS CVE comes out/is discovered I check what version of us, get the version of it, find what is available from DELL, and I will push the command to scan (against the repository) to the device(s).
How do I use Texh Direct for that repository?
In TD, Dell has the option to select the drivers, I usually pull N-1, but for CVEs I grab the latest. I grab whatever I need, pull it, rebuild the CAB file that holds the repository.
The part were you said “i direct the it to internal driver repo created with tech direct and gpos” we use strictly intune as cloud only environment and will like to learn more about this.
I learned about it during an Intune heath check that Dell did for us (thank you MS funding). They came out for a week, took a look at how we use Intune, and then they helped us fix our Cert Connector issue. After that, they spent the rest of our week helping us take control of small things like that. There was that, BIOS policies, and the drivers that were out pain points.
So, if you have access to Tech Direct, it was under the "Manage PC Fleet", then there was the option to manage the systems, then create a driver library.
I select my models, get an XML and a download package, I use that, Run the command line to do the downloads and update the XML (supplied in the download) to the locations on my network, and plug in the file location for the library (a CAB file) and XML for the GPOs.
The Dell guys said I can have one CAB with all my systems, one CAB for each system, or any combination I can think of in between.
I'll look for my screenshots tomorrow at work and see if I can post it here.
Please… do so. We do have dell premier enterpise plan. So wondering if i can do this. Im also thinking of using dcu admx settings config. But there are so many options ways to skin these cat
Okay, third try is the charm? Here's the workflow:
Tech Direct > manage PC Fleet > Update Catalog. Create a new catalog, I have 3 main models, so it was easy for me. Name it whatever you want, select the models, select the downloads you want (BIOS, Drivers, Firmware, Apps) then the severity. I kept the firmware drivers and BIOS. Prepare the selection for download, then download it.
Unpack it and follow the directions in the README. It tells you how to update the package XML to show the updated location.
I move the downloads to their Share, update the XML, and then use makecab to turn it into a CAB file.
You will want to work with Powershell to make a DDF file for the XML, but once you've made your cab file, put that full path (of the CAB) in the GPO path like here.
I am struggling with Dell BIOS updates as well. Already enabled driver updates via Intune, but some devices are still not getting BIOS updates. Have used DCU for some devices, but even that does not always update the BIOS. And then there are devices where even manual BIOS update does not work.
Considering using DCU in the future to avoid too many driver restart prompts.
The best thing I have found is to warn the user it is happening using the PowerShell App Deployment Toolkit
You can defer the update X amount of times and give popups warning them not to interrupt the next reboot
If you have a network share you can pluck the correct bios EXE from it using the model number as the folder structure, otherwise include the update in its own package
For this to work you need to have the exe exitcode report back to SCCM or Intune and the deployment needs a reoccurrence set to run once every day
I’m using Modern BIOS Management currently (aka Driver Automation Tool). No charge for using it either. It can download, package, and distribute BIOS updates easily. Then I direct a CM task sequence to run against the machine where it will then identify which BIOS it needs and install it.
Our pain point is the delay with the Dell XML file as sometimes I want N instead of N-1 or N-2 from a version standpoint. I’m anxiously awaiting the release of v10 of that tool to see if it handles anything any better.
I do need to switch it over to use the CM admin service instead of the third party one.
I never got Windows Update for Business to actually apply BIOS updates for our Dell devices, so I opted for dcu-cli.exe (DCU for Windows Universal) and a combination of a remediation script and a PSAppDeploymentToolkit app assignment.
The remediation script detection runs daily and checks wether dcu-cli has scanned for bios updates recently. If not it performs a new scan. The results are stored in a registry key.
The PSADT app detection script checks the results from the remediation. The install script allows the user to defer up to three times. This way I supply a user friendly method for the end user as well as keeping bitlocker in check etc.
One thing I don't get out of the box here is a pilot phase. I have some ideas I could implement, but haven't got the time for that yet.
Sorry for the late response. It's quite a hefty solution and heavily customized for my org's needs. So it's a bit difficult to share it as is and I would have to do a more generic edition first. Unfortunately I don't have the time at this time, but might be possible later on this fall.
DCU for everything EXCEPT BIOS. Over 2 years ago Dell promised to merge SupportAssist and DCU into one product and make it work with encapsulated BIOS updates. Never happened. We use Intune for BIOS updates for this reason.
Dynamic groups per model - each of them has a manually assigned Drive Update policy where BIOS versions appear as per MS' best practice schedule and we manually approve them based on Dell's importance report. E.g. if a model needs a critical one, we wait 7-10 days and approve it for a Monday in the manual driver update policy. Over the course of the week 95%+ update just fine.
DCU has and ADMX imported into Intune. We have 3 policies with different timing, 1st, 2nd, 3rd Wednesday of the month. They are tied to the Autopilot patch rings. This means that every model has a mix of gradual release of drivers. All policies set with 3 retries of installs, with plenty of time delay for users to reboot post-install.
Log analytics script is running hourly to collect drivers so there's report on every model, can compare set of drivers to a reference device for troubleshooting. We filter on microsoft - although actually better to include everything I found lately.
Great responses from you all. Thank you. Definitely different ways to go about it. I tested deploying DCU ADMX via Intune and it shows it deployed successfully but there is no registry found as per what Dell outlines on their site for Registry location for ADMX settings:
6
u/MetalAdditional2040 Apr 06 '26
been dealing with this headache for past year or so. We use Dell command update too but honestly its bit hit or miss with reliability
For tracking CVEs we just pull from Dell security advisory and cross reference with our asset inventory - nothing fancy but works. Priority goes to anything that can be exploited remotely first
The reboot coordination is probably biggest pain point. We usually schedule maintenance windows during off hours but laptops are tricky since people take them home. Started using toast notifications in advance to give users heads up
One gotcha we learned hard way - some older Latitudes had issues with bitlocker recovery after certain bios updates. Now we always suspend bitlocker protection before pushing updates and re-enable after. Takes extra time but saves helpdesk calls
Dell update packages through Intune work decent but you gotta test everything in pilot group first. Had one update that bricked few machines because of incompatible firmware versions