Dell Command Update 3.1 UpdateType Bug

I experienced this issue as well.

A couple of other things that I ran across.

1) When running /scan -report=somefilename.log, the specified file name would get created as a folder and the file DCUApplicableUpdates.xml would be generated in the folder.

2) -scheduleReboot option did not appear to work. Ended up using -scheduledReboot when running /configure

Thanks for the info.  The -UpdateType field doesn't accept the "apps" parameter either.  It will fail and give an error if used.  Thanks for the tip regarding the /configure I will use that to achieve what I need.

The value provided for option '-updateType' is not valid.
Program exited with return code: 107

I just finished working on a script to update the BIOS using DCU 3.1 and here are my findings.

Would install ALL updates

• dcu-cli.exe /applyUpdates -updateType=bios -AutoSuspendBitLocker=enable

Would install ONLY BIOS update

• dcu-cli.exe /applyUpdates -autoSuspendBitLocker=enable -updateType=bios

I was only able to get DCU 3.1 to filter by update type if it was the last argument given. Can you try that and see if that works for you? Also, don't use -silent as the first time I used it, everything installed when I was just trying to install the BIOS update. The -silent switch only silents the CLI text output. When using the CLI, there is never a GUI that pops up. I'd rather not use -silent so I can capture the return codes.

DCU 3.1 /scan test

DCU 3.1 /applyUpdates test

DCU 3.1 /applyUpdates installed all

I confirmed that it works for me when putting "-updateType" at the end of the command.

I see what you mean about the -silent option. In my use case, a script initiates the dcu-cli and then outputs the return codes to the installation log using "-outputLog".

This thread is just what I was looking for.  I have a task sequence for imaging new machines, and although I apply the latest Dell driver CAB during imaging, I wanted to run dcu-cli to get up-to-date drivers at the very end.

We also have a very finely tuned, and separate, task sequence used to update the BIOS which is the last thing called.

Unfortunately, even though I was specifying "-reboot=disable -updateType=drivers,application,others" (note, it's "application" and not "apps" like some online documentation says), it was still trying, and failing to update the BIOS. We have a BIOS password set, and it's not being supplied to dcu-cli, so I don't know what it's thinking there.  And on top of it, it ignores the reboot=disable and just does that anyway which throws the task sequence out of whack thanks to an unexpected reboot.  Even if it's not trying the BIOS update, one of the drivers may require a reboot too which would still mess things up.

For now I just added a separate /configure command before doing the /applyUpdates so hopefully that does the trick.  But just in case, I'll keep the updateType in there as well, and move it to the end of the options right after the outputLog  Pretty weird Dell... pretty weird.

I'm still having issues, even after moving the -updateType parameter to the end of the command.  I have the command like this in my task sequence:

"%ProgramFiles(x86)%\Dell\CommandUpdate\dcu-cli.exe" /applyUpdates -outputLog=C:\Logs\dcu.log -reboot=disable -updateType=driver,application,others

It still tries installing the BIOS and rebooting. Stupid thing.

And before that I run a /configure command like this, so I really don't get why it's ignoring the settings:

"%ProgramFiles(x86)%\Dell\CommandUpdate\dcu-cli.exe" /configure -updateType=driver,application,others -scheduleManual -userConsent=disable -outputLog=C:\Logs\dcu.log

I can see from the log file that the configure command works:

'-updateType' setting updated with value 'driver,application,others'.
'-scheduleManual' setting updated.
'-userConsent' setting updated with value 'disable'.

Pretty frustrating since the end result is that the BIOS update fails in dcu-cli because we have a password set (and I *really* don't want it to try), and when it reboots, it messes up the task sequence. Since it's nearly the final step, the image actually works okay and the task sequence does in fact finish successfully. But since we have our separate BIOS update task sequence chained to run right after dcu-cli runs, that never happens and we end up with an imaged machine that doesn't have the approved BIOS update on it.

I wish Dell would fix this, or at least pay attention to the forum here and give us some kind of update or workaround.

@MisterABDell  i figured out through testing that it will always detect the bios update and try to update it UNLESS you explicitly  run -autoSuspendBitLocker=disable. It will still detect it, but it will skip it.
you can do that switch with the /configure (permanent) or the /applyupdates (one time only) switches

"C:\program files\dell\CommandUpdate\dcu-cli.exe" /applyupdates -updateSeverity=critical -updatetype=driver,application -autoSuspendBitLocker=disable 

Thanks, I'll give that a shot. I wondered about that option.  We do have Bitlocker enabled during imaging so hopefully this does the trick.  We also set a BIOS password so I'm a little surprised it didn't complain about that. But if setting that option gets it to skip the BIOS updates, then that's fine by me.