Not sure if this is the right place for this post, debated between this and r/sysadmin.

Ive been working on a script that our client requested that uses the Dell Command Update (DCU) CLI to run a script that updates the user's drivers/bios/firmware via proactive remediation. Ive managed to get that built out and tested and it works flawless. Since then they added a stipulation in the project, the CLI gives exit codes and for certain codes that basically says "reboot required". If this code were to appear they want a notification sent to the user letting them know to reboot.

Not that hard I thought, setup switch statements that looks for the various exit codes, but im getting stumped on the actual notification. I managed to get a Windows Toast notification setup but it does not work via Proactive Remediation since its running in SYSTEM context instead of USER. I did some digging and found that the DCU CLI tool has a command to push a notification to the user.

Thats where im currently at, ill post my code and conundrum below.

Here is a one line command using the CLI tool that sends a notification to the user at a specific time:

&"C:\Program Files\Dell\CommandUpdate\dcu-cli.exe" /customnotification -heading="Which one is this" -body="Update FOund" -timestamp="4/26/2024,13:55" 

This confirm works, but obviously I cant hard code a time because not all computers will run the script at the same time.

So i thought i found the solution below:

$notiDate = (get-date).ToString("MM/dd/yyyy,HH:mm")
&"C:\Program Files\Dell\CommandUpdate\dcu-cli.exe" /customnotification -heading="I am heading" -body="I am body" -timestamp="$notidate"

I thought this would work, it puts today's date/time in the exact format that the CLI tool requires but i get an error saying that the parameter is invalid everytime. It makes no sense to me, is that not the same format as the previous line of code???

Can anyone help a poor helpdesk worker out? Im sure its something simple im missing, but im up for any suggestion even ones that dont involve the CLI tool and use some other form of Windows Notification that runs in SYSTEM context without fail. I just need a way of alerting users to reboot their dang computer lol

ps. Heres a link to the CLI reference guide: https://www.dell.com/support/manuals/en-us/command-update/dellcommandupdate_rg/dell-command-update-cli-commands?guid=guid-92619086-5f7c-4a05-bce2-0d560c15e8ed&lang=en-us

Good evening everyone.

So, I created a powershell script to update a number of pc's (same model-dell). The issue is that when the script runs dell command update, a black cmd screen pops up on the user's display. Is there a way to prevent this popup from appearing?

This is the code I'm using atm:

# Dell Command Update

# Define paths and options for Dell Command Update

$dellCommandUpdatePath = "C:\Program Files\Dell\CommandUpdate\dcu-cli.exe"

$logFolderPathDCU = "C:\Logs\DellCommandUpdate"

Hi all,

Very much a Powershell n00b, but I'm hoping someone can guide me in the right direction.

I'm wanting to utilize "Dell Command Utility" - or more importantly - its CLI part in an interactive script. (It allows you to automatically download and update a Dell PC's drivers and BIOS). I believe the issue I have is that the utility doesn't like to run 'headless' through a remote PS-Session. But I want to see the progress (as it includes download information, what's out of date, etc.).

It works locally on the machine in a tell-tale way:

• If you run it in an elevated Command Prompt - it runs in-situ without any issue.

• If you run in in an elevated, but local, Powershell window (directly calling the .exe or a Start-Process), it will open it's own "command-prompt-esque black and grey" CLI window.

• If you call it in Powershell via cmd /c - it will open and run in-situ in that Powershell window - but again, only locally.

As soon as you run it in a remote session, you're greeted with:

.\dcu-cli.exe :
    + CategoryInfo          : NotSpecified: (:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

Unhandled Exception:
System.IO.IOException: The handle is invalid.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.Console.GetBufferInfo(Boolean throwOnNoConsole, Boolean& succeeded)
   at Dell.CommandUpdate.CLI.Program.ShowWorking()
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback,
Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state,
Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

no matter what I've tried (so far).

So my question is - can I enforce the program to stay within the Powershell shell and stop trying to break out into another? I think this is probably the issue (please correct me if I'm wrong!) but that's way out of my depth of PS understanding.

Than you in advance for any guidance given.

I'm trying to make a script to make my deployments at work easier.

My idea is to get the model number using (CimInstance -ClassName Win32_ComputerSystem).Model and then downloading Dell Command Update or Dell Update depending on the model. We have thousands of devices mostly consisting of Dell of various makes and models.

Does anyone know if there's a static link for either program or would I have to build a webscraping script with Selena to accomplish this?

Does anyone know of a better way to accomplish this? I've found driver packs but we use so many different models that making a script to link to each driver pack seems insane.

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

I've tested this script on my desktop, and it's been running smoothly. I'm reaching out for help, not criticism, and I would really appreciate it if someone could help me find out the problems I'm having when deploying the Dell Command Update and update using SCCM. Specifically, I'm running into error messages, namely, 0x1(1) and 0x2(2).

It's worth noting that when these error messages appear, I've noticed that the Dell Command Update seems to have been installed when I check the "Add or Remove Programs" section. However, beyond this observation, it appears that nothing else is progressing. Clicking "retry" seems to restart the installation process but then stops. Any help with this matter would be highly appreciated.

# Execute the script
Start-Process -FilePath "\\server\apps\Dell-Command-Update-Windows-Universal-Application_1WR6C_WIN_5.0.0_A00.exe" -ArgumentList '/s' -Wait

# Disable the initial setup popup in the Windows Registry for Dell Command Update
New-ItemProperty -Path "HKLM:\SOFTWARE\Dell\UpdateService\Clients\CommandUpdate\Preferences\CFG" -Name "ShowSetupPopup" -PropertyType DWORD -Value 0 -Force

# Define the paths for the Dell Command Update executable and the settings XML
$DellCommandPath = "C:\Program Files\Dell\CommandUpdate"
$SettingsXmlPath = "\\server\apps\SML\5.0.0\DCUMySettings.xml"

# Run the Dell Command Update tool to import settings
Start-Process -FilePath "$DellCommandPath\dcu-cli.exe" -ArgumentList "/configure -importSettings=$SettingsXmlPath" -NoNewWindow -Wait

# Lock the Dell Command Update settings
Start-Process -FilePath "$DellCommandPath\dcu-cli.exe" -ArgumentList "/configure -lockSettings=enable" -NoNewWindow -Wait

# Scan for updates (BIOS and firmware)
Start-Process -FilePath "$DellCommandPath\dcu-cli.exe" -ArgumentList "/scan -updateType=bios,firmware" -NoNewWindow -Wait

# Disable updates notification
Start-Process -FilePath "$DellCommandPath\dcu-cli.exe" -ArgumentList "/configure -updatesNotification=disable" -NoNewWindow -Wait

# Apply updates silently, enable reboot, and log the output
$LogPath = "C:\Dell-CU-apply.log"
Start-Process -FilePath "$DellCommandPath\dcu-cli.exe" -ArgumentList "/applyUpdates -silent -reboot=disable -outputLog=$LogPath" -NoNewWindow -Wait

# Run the Dell Command Update tool to import settings
Start-Process -FilePath "$DellCommandPath\dcu-cli.exe" -ArgumentList "/configure -importSettings=$SettingsXmlPath" -NoNewWindow -Wait

# Define the paths for the Dell Command Update executable and the settings XML using registery
$process = Start-Process reg -ArgumentList "import \\server\apps\reg\5.0.0\DCU_Preferences_Value.reg" -PassThru -Wait 
$process.ExitCode

# Define the paths for the Dell Command Update executable and the settings XML using registery #2

if((Test-Path -LiteralPath "HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences") -ne $true) {  New-Item "HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences" -force -ea SilentlyContinue };
if((Test-Path -LiteralPath "HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\CFG") -ne $true) {  New-Item "HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\CFG" -force -ea SilentlyContinue };
if((Test-Path -LiteralPath "HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings") -ne $true) {  New-Item "HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings" -force -ea SilentlyContinue };
if((Test-Path -LiteralPath "HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings\AdvancedDriverRestore") -ne $true) {  New-Item "HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings\AdvancedDriverRestore" -force -ea SilentlyContinue };
if((Test-Path -LiteralPath "HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings\General") -ne $true) {  New-Item "HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings\General" -force -ea SilentlyContinue };
if((Test-Path -LiteralPath "HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings\Schedule") -ne $true) {  New-Item "HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings\Schedule" -force -ea SilentlyContinue };
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\CFG' -Name '(default)' -Value '' -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\CFG' -Name 'ShowSetupPopup' -Value 0 -PropertyType DWord -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\CFG' -Name 'LockSettings' -Value 1 -PropertyType DWord -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings' -Name 'InstallPath' -Value 'C:\Program Files\Dell\CommandUpdate\' -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings' -Name 'ProductVersion' -Value '5.0.0' -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings' -Name 'AppCode' -Value 'Universal' -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings\AdvancedDriverRestore' -Name 'IsAdvancedDriverRestoreEnabled' -Value 0 -PropertyType DWord -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings\General' -Name 'UserConsentDefault' -Value 0 -PropertyType DWord -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings\General' -Name 'SuspendBitLocker' -Value 1 -PropertyType DWord -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings\General' -Name 'SettingsModifiedTime' -Value '10/16/2023 9:19:49 PM' -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings\Schedule' -Name 'DisableNotification' -Value 1 -PropertyType DWord -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings\Schedule' -Name 'ScheduleMode' -Value 'Monthly' -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings\Schedule' -Name 'MonthlyScheduleMode' -Value 'WeekDayOfMonth' -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings\Schedule' -Name 'WeekOfMonth' -Value 'last' -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings\Schedule' -Name 'Time' -Value '2023-10-11T23:45:00' -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings\Schedule' -Name 'DayOfWeek' -Value 'Sunday' -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\DELL\UpdateService\Clients\CommandUpdate\Preferences\Settings\Schedule' -Name 'DayOfMonth' -Value '28' -PropertyType String -Force -ea SilentlyContinue;

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.

I am attempting to create a set of PowerShell scripts/automations, intended to be used in the NinjaRRM console. I am trying to achieve the following:

• a script to download and install DCU if it is not already installed

• a script that scans for and logs any pending/needed updates/installs to custom fields

• a final script to install all the updates and reboot

However I have yet to find a way to download and install Dell Command | Update as part of an automation, and ninja flags both the .exe file and the download URL as suspicious. I am relatively new to automation and ninja as this is my first position at an msp. Any suggestions or advice welcome

EDIT: I have no successfully gotten this to work. In addition I have created a GitHub repository that contains a few useful scripts for DCU, I have also numbered them in the order they were intended to be run in. https://github.com/nolannash/dcu-scipting

Any advise on this ?

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?

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!

Hi All,

So I'm automating dell command update via a powershell script that installs it, and then pushes dcu-cli.exe commands to set things up how we want them. I can currently get it to use the bios password, but there doesnt seem to be any way of doing it without providing the bios password in clear text in the script.

DCU has an option to generate an encrypted password via your bios password + an encryption key password that you make up, but in order for it to use the encrypted password on the users end it also needs the encryption key. So my script would have an encrypted bios password. Cool. But it will also have the clear text key to decrypt it making the encryption useless? am i missing something here?

The bios password would be stored in a script, thats in an .intunewin package, on our intune instance, but still.