Dell Command Update Tips for Enterprise Automation

I’ve been playing with Dell Command Update a bit again, and found some quirks that I had to overcome to get it working how I want in my lab.  I’ll show the registry keys associated with Dell Command Update, along with behavior exhibited by importing and exporting policy. Future post coming soon to see how I’ve set it up in a TS to update BIOS & Drivers… here is the leg work behind that post to a better understanding of DCU.

Few points before we get much deeper

• At time of post, This is for Version 2.4 of DCU, 3.0 removes CLI support.
  
• Product Page: https://www.dell.com/support/article/us/en/19/sln311129/dell-command-update?lang=en
• Documenation: https://topics-cdn.dell.com/pdf/dell-command-update-v2.3_users-guide_en-us.pdf
• Check out pages 27-29, which helps some, but still leaves you scratching your head over the behavior of your XML exports and imports.
• I use this in my Lab, and previous company, I do not use it currently in Prod due to bandwidth limitations and super tight version controls.
• This is ideal for companies who want to set and forget, have lots of bandwidth and have to constantly do more with less.

Now onto it… When you import a DCU settings policy, you’re unable to modify specified settings in the GUI. Basically how it works, if you modify a setting from the defaults in your imported policy, it will grey it out.  Options I’ve chosen to leave default, it will allow a user to modify.  If you’re going to leave DCU installed for your support staff, take this into account, perhaps you’ll create a template that disables certain items, but leaves most boxes available for the admin to change.   Clicking the “Restore Defaults” also does nothing if you’ve import settings, other than revert back to your imported settings. This is very important, because the Dell Defaults will actually schedule it to run automatically, and you might not want that, and you might not want your admin to make that decision either, this is when the power of an imported policy is great.. however if they are an admin, they can get around it by deleting a key, more on that later…

Here is the GUI after I’ve imported my “Drivers-All” Policy during OSD.  Many options are greyed out. (But not all)

Your imported policy is tied to a registry key:

HKLM\SOFTWARE\Dell\CommandUpdate\Preferences Value: Policy
This is what it looks like if you import policy BEFORE launching DCU

This is what it looks like if you import policy AFTER launching DCU the first time.

If you delete the value Policy, then Admins can change ANYTHING they like from the GUI.  Which could include automatically running weekly, installing updates and rebooting the machine. Not something I’d like to leave up to the local admin / support staff.
If you wanted to, you could also dump the entire “Preferences” Key, and it will run the “First Run” Wizard, this is VERY handy for when you’re creating your templates.

After deleting everything in Preferences:

As soon as you click OK, the registry populates with the Defaults:

Now you can go in and modify the Settings you want, for my example, I only want Drivers, here is what that looks like: *Note, before you launch the DCU GUI to make your exports, delete the Preference Key so you get the “First time dialog” & start from a clean slate.

Once I click OK… registry looks like:

I then Export this to create my Drivers-All.xml template to be used in my TS to install updated Dell Drivers.

My XML File:

This XML file corresponds to the first settings image on this post.

NOW… lets say you want to lock it down, so an admin can’t change any of the settings in the GUI at all, when you’re making your Settings Export, you need to modify each setting, basically, if you want to make a box greyed out, but remain checked, you uncheck it in the settings, then check it again. (so it’s still the default of checked, but modified because you unchecked & checked it again)  After you do this, it will create the Setting Name = True value, which will be exported.

Here is the registry after the SAME settings are enabled, but “Locked down”

XML: Export Drivers-All-LockDown.xml

DCU GUI with Drivers-All-LockDown imported

As you can see, the admin using the GUI has NO options to change anything, they are stuck with MY settings (Just the way I like it. )

How am I using it?
I have several templates, but mainly just use three, BIOS template,  Driver Template, & PostOSD Defaults Template.

I use DCU to update my BIOS during a Task Sequence (IPU or OSD), and use it to update drivers, both OSD & IPU.

I’ll blog the process later, as BIOS is a bit more complicated if you have Bitlocker & a BIOS password. (WHICH YOU SHOULD!!!!!!)

Hopefully this helps explain the quirks of DCU.  I used to be super confused as to why some items were greyed out, and some where not, all because of accidental clicks of settings before exporting, and not resetting DCU to defaults by deleting the preference key before creating new exports.

Quick Notes if you skimmed to bottom..

• If you do exports, ALWAYS delete the HKLM\SOFTWARE\Dell\CommandUpdate\Preferences key before you launch DCU to create your settings export
• Plan your exports, you’ll probably have a few, and then have a “Default” settings that you set that gives some liberty to the admin (technicians) but still locks down settings you don’t want changed.

Published at GARYTOWN.COM