Last April, I took Dell Tech World by storm unveiling the next generation of PC deployment and imaging. Sure, Dell presented this whole Dell Provisioning concept, but I took it and decided that I would push the limits of what it can do. You can read more about that here

Dell Provisioning at my current company has been very good for us. I’ve seen almost 500 PCs go out the door during a PC refresh where we can churn stuff out with my “plug it in, press power, and get a cup of coffee” method. The art of engineering is based on taking something and pushing the limits, which we don’t see much of these days as people have gotten lazy and just rely on the vendor. Then you also have companies who are decided to hire two junior engineers instead of skill positions, but I digress.

One of the major gaps that Dell Provisioning has had is around the Dell Apps themselves. I’ve uncovered several bugs and challenges around Dell Command Update, Dell Support Assist, Dell Command Monitor etc. Sometimes we can work through them, but other times we just can’t get to a comfortable jumping off point.

Dell Command Update 3.1

I’ve been patiently awaiting Dell Command Update (DCU) 3.1, which if you aren’t familiar is a product that handles firmware, drivers, BIOS updates for Dell PCs conceptually similar to Windows Update. The main problem with the current releases of DCU are: (1) the scheduling component is broken, (2) silent updates were bombing out with gateway errors, (3) it didn’t play well with WorkspaceONE. It’s a major frustration for me because as anyone who knows me will tell you that I live and breathe automation.

The only way that imaging/provisioning/delivery of PCs/Macs, etc are successful is if its seamless. I was definitely happy to see DCU 3.1 release and finally get me “closer” to where I need to be, but it isn’t currently a clean process. I will walk you through how to get there with a little help from our friend “Product Provisioning”

What’s New in DCU 3.1

As you will find on the Dell Website, there are a few new features available in DCU 3.1:

• Automatic suspension of BitLocker when BIOS updates are applied
• Enhanced return codes for command-line interface
• Options to schedule updates on a weekly or monthly basis
• Bug fixes and enhancement

We should demystify this stuff a little bit. Let’s start by talking about the suspension of Bitlocker to apply BIOS updates.

How the BitLocker Suspension/BIOS Update Stuff Works

So it’s straight forward enough. You use a configuration to suspend BitLocker, but it doesn’t stop there. By using the DCU-CLI (its the command line interface for DCU), you set DCU 3.1 to automatically suspend BitLocker when needed and provide the BIOS password so that it can apply the BIOS password.

I’ve been able to get this work pretty effectively, but I think the major thing to focus on is cleanup and risk. I use a cleanup batch file that runs after my configuration, which we will discuss a bit later to make sure that we cleanup the script and don’t give an attacker easy access to the BIOS. A few things to be aware of before moving on:

• After any BIOS update, a PC reboot will automatically happen
• BitLocker will be resumed once completed
• You cannot apply any BIOS updates without using the suspend BitLocker/BIOS password configuration.

Status of Workspace ONE Integration

As of today, we still do not have any functional integration for DCU 3.1 and Workspace ONE. Their configuration still only supports DCU 2.4 which does not work for silent updates (I beat my head into a wall for a few months trying to get it to work).

That’s okay though. As an architect and engineer, if they can’t do it, I will do it myself! I’ve been able to build a recipe for success on this, which we will now go over!

How to Build DCU 3.1 Scheduling/Automation via Product Provisioning

The Scripts

I’m not going to cover deploying the application itself, but I’ll tell you this is the silent command to install: DellCommandUpdateApp_Setup.exe /S /v/qn

I use 3 files to make the magic happen..

Settings.XML

This is the settings file that configures everything except BitLocker and the BIOS password. We will use the CLI to point at this file later on..

WordPress isn’t all that happy about pasting XML so you can access it here. You will find its pretty straight forward.

Configuredcu.bat

This batch file fires off several DCU-CLI commands to configure the the application itself. You will see it points at the settings.xml we deployed, configures the BitLocker and specifies the BIOS password, and tells DCU to do the initial scan and apply updates:

"C:\Program Files\Dell\CommandUpdate\dcu-cli.exe" /configure -importSettings=C:\Temp\settings.xml
"C:\Program Files\Dell\CommandUpdate\dcu-cli.exe" /configure -autoSuspendBitLocker=enable -biosPassword="Password1"
"C:\Program Files\Dell\CommandUpdate\dcu-cli.exe" /scan
"C:\Program Files\Dell\CommandUpdate\dcu-cli.exe" /applyUpdates -silent -reboot=enable

DCU Cleanup File

This one is pretty straight forward. You just create a batch file with this below, which will remove the batch file with the BIOS password:

del C:\temp\configuredcu.bat

Deploying Via Workspace ONE

The deployment is pretty basic. We will first add the files:

Now we build out the commands:

The design is relatively straight forward. You can really do this in a few different ways depending on how you want to roll things out. You could deploy DCU 3.1 within Product Provisioning in one cohesive design, which I would strongly recommend (that just requires adding in the DellCommandUpdateApp_Setup.exe file and then adding the run command for DellCommandUpdateApp_Setup.exe /S /v/qn OR you can deploy the application via the Intelligent Hub and set the product to elective/optional. At a minimum, I will show you how to prepare the DCU 3.1 installer so you can deploy, but if you want help with actually deploying it reach out to me.

Building a Deployment Package for DCU 3.1

Building the package is pretty simple, but not a ton of info on it out there. First, you will go here and download the universal package for DCU 3.1 and then run a single command in CMD to extract the installer for deployments:

Installing the DCU 3.1 Configuration Manually (If you choose this method)

Personally, I decided to separate them because we have some people who are “high touch” and don’t want automatic updates believe it or not. You might also need to deploy several different configurations when you have different patch cycles/etc. This will entirely depend on how you build your environment.

Ideally, you want to consider use cases and what is best for your users. Most times its best to build the entire package completely with Product Provisioning so its seamless and doesn’t require people to put on their thinking caps. The main challenge you have when things are separated is that you need to manually install the product when necessary like this: (Just click SEND!)

In Summary…

So in reflection, it’s a great thing that DCU 3.1 is finally out and is accounting for the REAL use case. For me, It’s not a huge deal that it requires a bit of DIY at the moment.

What matters is, your techs don’t need to spend stupid amounts of time after hours applying firmware updates or remediating some zero day on patch Tuesday. There are several nice apps in the Dell arsenal when used properly automate and streamline some of the largest pain points that Desktop Engineering has today, such as Dell Support Assist optimizing and monitoring defective hardware along with automating the ordering of replacement parts. You also have stuff like Dell Command | Monitor which gives you additional insight into the PC itself.

I always focus on what I’m trying to solve and not just throwing technology at shit to see what sticks. I’ve spent several months evaluating every piece of Dell desktop software to see what is good for me and my organization. You should do the same especially with the introduction of Dell BIOS verification and several other great tools that give you the intelligence to be awesome.