I've noticed my DCU isn't pulling down BIOS updates, only driver updates. My xml settings include drivers, firmware, and BIOS. The Dell reference guide for DCU states if no options are used with scan and apply updates, the existing application settings will be used. The existing settings should be those applied by the imported xml. I verified once in Windows that the settings are imported. Why are the BIOS updates not pulling down?

In my TS I have the following steps: Install DCU Import settings (xml) Scan Apply updates

Any advise on this ?

I’m trying to get Dell Command Update to install and download all available driver updates as part of the task sequence. The log file reports that the installation of the app fails but in reality, the install completes successfully. The next step where the BAT file is supposed to run and install the updates never seems to run.

I’m using the latest version Dell Command Update 4.8.0

I’m installing Dell Command Update using a command line task in TS:

cmd.exe /c %DEPLOYROOT%\Packages\DellCommand.exe /s

With Success codes: 0 1 500 3010

**INSTALL TASK:**This somewhat seems to work as it does successfully install the application but the log file reports that this step fails.

To get Dell Command Update to scan the system and install the updates I create a BAT file with this script:

@echo off
TITLE Running DELL Command Update...
REM Checks for updated DELL Drivers using DELL Command Update CLI

"C:\Program Files\Dell\CommandUpdate\dcu-cli.exe" /configure -silent -autoSuspendBitLocker=enable -userConsent=disable
"C:\Program Files\Dell\CommandUpdate\dcu-cli.exe" /scan -outputLog=C:\dell\logs\scan.log
"C:\Program Files\Dell\CommandUpdate\dcu-cli.exe" /applyUpdates -outputLog=C:\dell\logs\applyUpdates.log        

• This script works when run manually but does not seem to run at all in the TS; I'm guessing since MDT thinks the installation of the application failed it does not continue.

RUN BATCH SCRIPT TASK

The error log at the end of deployment is this:

It says "The system cannot file the specified file" But have the DellCommand.exe in the DeploymentShare\Packages\DellCommand.exe location

Any ideas?

Thank you!

The latest update to the Dell's Update application has converted it into some sort of a windowsapp rather than a normal application. With this change, the command line version has disappeared.

Anyone know if theres a downloadable version of the command line tools? I had some nice scripts set up to pull in the lists of pending patches for machines. This has now broken and I can't see any other way of achieving the same result.

Looking to have two different tasks, one that's scan only and one that's scan and install.

The commands themselves work fine, however there's a whammy where depending on the version, Command Update will either be in Program Files or Program Files (x86), thus there is no "one task to rule them all", and having to parse which is which would be a pain.

So, with some Googling, I make a little CMD script that should fit the bill, however it doesn't seem to be detecting the x86 directory when running it and defaults over the 64 bit path instead.

Any thoughts? Or a better way to go about it?

SET ProgFiles86Root=%ProgramFiles(x86)%\Dell\CommandUpdate

IF NOT "%ProgFiles86Root%"=="" GOTO win64

:win64

SET ProgFiles86Root=%ProgramFiles%\Dell\CommandUpdate

"%ProgFiles86Root%\dcu-cli.exe" /scan -silent

I have seen the earlier posts regarding DCU but they stop short of some detailed info that would be helpful.

What I am thinking is:

1. Use TDM (Tech Direct Dell) to create driver packages, BIOS, tools, etc. That allows me to download a Zip file

2. Put the unzipped BIOS files (for example) on the source directory of the SCCM MP.

3. Replicate these folders/files to the DP's (using Package\Program)

4. Run a command which copies these folders to the local machine (say, C:\Source)

5. run the DCU-CLI with appropriate switches to install the updates from the Source folder

6. Setup the ADMX Template to turn off Dell.com as a source

When thinking a bit further, these drivers, etc are many Gigs of data and will fill things up if I do this repetitively without deleting them periodically.

This model may not make the best sense, and alternatively I could have the computers run the DCU-CLI and point it to the DP's to get the updates.

Ideas? Suggestions?

I've been playing with the switches to try this using just a \\server\share and have not been able to use the UNC path appropriately (not certain which switch specifies the \\server\share), but more problematic is how to have computers in a remote site point to the local DP to scan and apply.

Has anyone done it this way? thanks!

I use Dell Command Update in our environment to scan for available updates and apply driver/BIOS/firmware updates as needed. It's very handy for keeping tabs on urgent update releases and generating reports on what devices are missing patches.

I just noticed that the most recent version of the software (5.7.0) seems to be installing AMD bloatware automatically when checking for updates which is annoying. All our devices are Dells with Intel processors and despite that it seems Dell Command Update is now installing something called "AMD Software" for an unknown reason. Attempting to run this software even gives an error message stating that our system isn't running AMD hardware to support it and it immediately closes. I looked through Task Manager as well and can confirm that something called "AMD Crash Defender Service" has also been installed by default and is running in the background. If I have a fully Intel system, why are these things being installed?

For reference, the command I use when applying updates is "waithidden "C:\Program Files (x86)\Dell\CommandUpdate\dcu-cli.exe" /applyupdates -silent" but I guess I might have to be more specific and tell it to just scan for drivers or BIOS updates to avoid other programs being installed when they aren't wanted or needed.

Happy Friday fellow Sysadmins!

Has anyone gotten Dell Command Update 3.1 running remotely yet?

https://www.dell.com/support/article/us/en/04/sln311129/dell-command-update?lang=en

I want to be able to run dcu-cli.exe on a remote workstation. If I am logged into a machine, I can run the application via CLI no problem. When I attempt to run it via script / PowerShell, nothing happens. No error code, don't see a process start on the remote machine, nothing.

Methods I have tried:

1.) Remotely running a batch script remotely that contains:

start wait "C:\Program Files\Dell\CommandUpdate\dcu-cli.exe" /ApplyUpdates -Silent -Reboot

2.) PowerShell Invoke-Command:

Invoke-Command Computer {start-process 'C:\Program Files\Dell\CommandUpdate\DCU-Cli.exe' -Argumentlist '/ApplyUpdates' -Reboot' -Wait}

3.) I have also tried using Invoke-Command to call the batch script above in #1.

Regardless of what I do, the command will work if I am running it while logged into the machine, but not remotely. I know I am missing something obvious. I suspect this would probably work if I ran it as a scheduled task as a specific user, but I want to run it on demand.

Has anyone had any success with this? Thank you!

_______________________________________________________

Edit: I was able to get it working after juskom95 sent me down the right path by using PSExec:

First i tried running PSexec \\ComputerName "C:\Program Files\Dell\CommandUpdate\dcu-cli.exe" /ApplyUpdates -OutputLog=C:\Temp\Test.Log. When running this, the application was failing with error code 2 which is "Unknown fatal error".

Ultimately I was able to get it working by running the application as the SYSTEM account. Full command:

PSexec \\computername -s "C:\Program Files\Dell\CommandUpdate\dcu-cli.exe" /ApplyUpdates -OutputLog=C:\Temp\DellCommandUpdate\Test.log

There is a PowerShell Module called Invoke-CommandAS that I would imagine would probably work as well. PSExec is suitable for my needs so I didn't explore it.

Hello to all,

probably mine is a problem related to different mothertongue,but I'm trying to do the most simple and plain operation, I have to execute the bios update on a bunch of Dell devices that ALREADY have an admin password on the BIOS, from GUI you just type the psw, when using DCU-CLI.EXE how the h*ll I have to pass the password??

righ now I'm using this:

$Password = Invoke-RestMethod -Uri $apiUrl -Method Get

Start-Process -Wait -FilePath dcu-cli.exe -ArgumentList "/configure -scheduleManual -autoSuspendBitLocker=enable -biosPassword=$Password -downloadLocation=$UpdatesFolderPath"

$Updates = Start-Process -FilePath dcu-cli.exe -ArgumentList "/applyUpdates -reboot=disable -outputLog=$UpdatesLog" -PassThru -Wait

I'm collecting the password from an Azure Key Vault thru an Azure Function, the variable $Password will contains the plain text psw.

but seems it doesn't work, the -biosPassword is the right attribute? there is something I miss? I just want to pass the already configured password value without changing it, anyone could clarify the code syntax error?

I'm running a step in my TS to apply updates from Dell's DCU CLI. The scan step finds 12 updates, the apply step downloads and successfully installs the 12 updates, then exits with error code 1. The reboot switch is set to disable for the syntax below.

I notice DCU doesn't download all applicable drivers, so it looks like I'll continue using MDM to download driver packages, and DCU to supplement MDM. But I'd still like DCU to run properly.

Edit: mentioning the output log file from DCU cli, no errors, the log ends showing the 12 updates were installed successfully. Completed with return code: 1.

Failure at the end of the log

Struggling to get DCU to run during the TS. Below is what my setup looks like (took these from someone elses post). Using DCU 5.1.0. I can briefly see the cmd window open during the TS but it quickly closes. What am I doing wrong?

Step name: Dell Driver Install (x64)

Run Command Line:

cmd.exe /c "C:\Program Files (x86)\Dell\CommandUpdate\dcu-cli.exe" /driverInstall -reboot=disable -outputLog=C:\DellDriversDuringImaging.log

Step name: Restart Computer to OS

Step name: Dell Update Install (x64)

Run Command Line:

cmd.exe /c "C:\Program Files (x86)\Dell\CommandUpdate\dcu-cli.exe" /ApplyUpdates -updatetype=BIOS,firmware,driver -reboot=disable -outputLog=C:\DellUpdatesDuringTS.log

Hi Everyone,

We’re using Dell Command Update to push our Drivers and BIOS updates.

Instead of waiting for the updating to automatically trigger, When I used the /ApplyUpdates option it only really installed a handful of what is available in my catalogue. Skipping among many things the BIOS update.

I was wondering if there is an option to just install everything available in the catalogue?

Thanks everyone!

trying to put together a batch file or powershell i can deploy to remotely set up dell command update settings to download drivers automatically and prompt for install any suggestions?

Hello!

I'm trying to install Dell Command Update client on my fleet of laptops and apply configuration where it locks the GUI and changes the check updates setting schedule to 'manual' (instead of being automatic) with the following powershell script:

Start-Process -filepath Dell-Command-Update-Application_6VFWW_WIN_5.4.0_A00.EXE -ArgumentList '/s /l=C:\Windows\Logs\install.log' -wait

Start-Process -filepath dcu-cli.exe -ArgumentList '/configure -userConsent=disable -scheduleManual' -wait

This script generally works across the majority of our laptops for the most part.

However, there is a small number of laptops that do not execute the second command to apply the dcu-cli.exe /configure step. The DCU-cli.exe errors out on code 3005 which translates to "The Dell Client Management Service is installing pending updates."

This error only happens on these machines when you string the two commands together. If you immediately launch another shell and run the second script manually, it applies the config no problem. I don't know what it is about having the two commands being strung together on some particular laptops that it returns this error code. I've tried inserting a step in between to restart the dellclientmanagement service, but it has no affect. Only launching another separate shell afterwards to apply it seems to work.

Has anyone encountered this before?

Much appreciated if anyone has any advice

Thanks!

I'm tearing my hair out on this one.

Windows 10 - 21H2 x64 (Enterprise, if it matters), installing DCU with PSADT, and this works fine:

Execute-Process -Path 'DCU_Setup_4_6_0.exe' -Parameters "/S /v/qn"

I've even rebooted after this install just to be sure. However in any case, having SCCM try and either import our config XML, or run any "/configure" command fails with return code 2. I've run it with cmd, with start, by calling dcu-cli directly, and any combination you can think of and it doesn't work.

It does log:

Execute-Process -Path "C:\Program Files (x86)\Dell\CommandUpdate\dcu-cli.exe" -Parameters '/configure -importSettings=C:\Temp\xxxx-DCU-v2.xml -silent -outputLog=C:\Temp\DCU.log'

But no matter what (log here https://pastebin.com/0HQuzYyJ ) we're always seeing:

[2022-09-15 23:19:07] : An error occurred while executing the provided CLI command. 
[2022-09-15 23:19:07] : The program exited with return code: 2 

Even though it claims it changes the settings it doesn't.

Anyone have any clue what's up? This is too simple to fail and I've been banging on this for a few days.

Edit: 4.5.0 works, but it's missing the restart deferral options and also allows a user to disable automatic updates on first launch of the GUI even after locking settings. Ugh. Dell.....

Edit2: We gave up, are doing 4.6.0 and just rawdogging the settings in the registry with PSADT:

https://pastebin.com/YNCWf8eg

I'm curious if anyone else is having issues with Dell Command Update not pulling in some driver updates (mostly BIOS) lately, currently not picking up the 2 latest versions. We use DCU 5.5 classic (not UWP), I am attempting to work with Dell but it seems their support even ProSupportPlus only continues to degrade by the day. They currently refuse to escalate unless I provide logs from an OEM imaged Windows 11 pro factory imaged machine (seems to be getting more common lately) which is entirely unacceptable and clearly a BS script item designed to be a hurdle.

Recently I noticed they stealth released another version of DCU 5.5 A00_01 but its not clear why which makes me suspicious. We have had nothing but issues with BIOS on these Latitude 5550s since day one. Every time we update its a crap shoot of what is going to go wrong.

I identified the repository location that DCU is pointing to on my machines and when manually navigating to that repo you get a cab file with an XML manifest, and low and behold, it doesn't have the BIOS updates I need, but does have some others from the last month or so. 100+ Lat 5550s all doing the same thing.

Uninstalling DCU and reinstalling has no effect, clearing the reg key that references the repo also had no effect so I believe it has to be something on Dell's end in terms of not updating the repo with the BIOS updates or needing to simply repoint something on the backend, etc.

So I'm curious:
Anyone else experiencing something similar with DCU?

Any tips or insight on the inner workings of DCU and how the repository location is set and why my machines might be pointed at an incorrect or outdated/incomplete repo?

Yet another post seeking community insight since paid vendor support can't be bothered and every company on the planet seems to be stuck in this enshittification death spiral.

Thanks.

Edit: imaged a laptop back to factory OEM image per Dell's request and unsurprisingly the URL DCU points to is still the same.

For some reason when I install this via TS, it's only installing the command line dcu-cli with no gui. Also, when I run

cmd.exe /c start /wait C:\"Program Files"\Dell\CommandUpdate\dcu-cli.exe /ApplyUpdates

via TS I can watch it download and apply some updates, but it was failing to install the latest firmware and bios.

I'm having to install the bios and schedule a reboot before pushing out any software..I then have it install DCU, run, restart into the OS and STILL our touchscreen and touchpad aren't working until we log in and run another windows update. At that point it installs the latest Dell Firmware as well as the drivers needed for touchscreen and touchpad.

This is with the latest latitude 5520 driver cab injected into the image.