Dell Command Update – pulling back the curtains

TLDR: You need to learn SKU’s (SystemSKUNumber) for Dell systems if you want to be successful in automation for Dell. – Script on GitHub for GARYTOWN’s Dell PS Functions early beta

Alright, so I write a lot of PowerShell functions around Dell Command Update, (DCU) and Dell updates, basically leveraging the feed that DCU uses and bending it towards my own purposes. The feed Dell provides could be used to create an entire powershell module.

So, this is when the community steps in and creates solutions to fill the gaps. Sometimes I think they [OEMs] do this on purpose, but not out of spite, typically resource allocation issues, and management tools “Free” from the OEMs don’t directly line the wallets of the company, so they don’t devote a ton of money for it. If not for a FEW amazing people in these OEMs pushing and fighting for development of the management tools, I think we’d be in a much worse position.

Perhaps someday I’ll give a breakdown of the big OEMs tools, Pros / Cons and ratings. Each OEM has some strengths and weaknesses.

Ok, enough with my rants, you didn’t come here for that, I was going to start going into how DCU worked, and how you too can leverage the intelligence in DCU without actually installing it.

This is the Magic URL for Dell, that provide the building blocks to all things Dell that I’ve build: https://downloads.dell.com/catalog/CatalogIndexPC.cab

Let’s crack that thing open and take a look:

When we open it, you can see it lists all the models of devices they support with DCU, in my example, I’m looking up the OptiPlex 3090, since that is what I have for a test machine, the problem is, it shows up 4 times, and when I do unique, I can get it down to 2 instances, this is why you need to know the SKU. (Sorry how small it looks, feel free to open the image in a new tab so you can zoom in more if needed)

Ok, so what, you have a list of all of the Models and SKUs, loddie freaking da Gary. If you look closely, each Model (SKU) has a URL associated with it, that’s the nugget that provides the DCU catalog for the device.

Basically, the flow is… Parent Catalog -> SKU Catalogs -> Update List -> automation…

So, lets continue with the OptiPlex 3090, we have this large XML file, lets suck it into PowerShell and make it useful.

So I took the XML, I cleaned it up a bit and placed it into its own Object with cleaner names, then I searched for my OptiPlex 3090, and you can see 2 are returned. I just happened to know which SKU is for my test machine, since I label my test machines with the methods the vendors use:

You can grab the SKU using this simple command:

(Get-CimInstance -ClassName Win32_ComputerSystem).SystemSKUNumber

Ok, now that I know the SKU for my test machine, I can pull back the DCU catalog for it.

We’re going to grab the URL for my SKU, then download the cab from that URL, expand and import into PS

Things to note in the XML file, the manifest baselocation, this is the information DCU uses to know if it should pull from Dell’s online servers, or from a local repo. And the version is when the catalog file was last updated. Then there are several sub items, like Component Type, which will have several options, which I’ll get into in a bit, but if you’re familiar with DCU, you’ll already be able to guess them.

Let’s use PS to make life easier here and pull out the different items. As you can see from the image below, you have to drill in a bit to get useful data, so in my automation, I rebuilt it into it’s own object. You can also see that my OptiPlex 3090 has 145 Dell updates available in the catalog, of which I bet only a few are applicable to my device.

So now you have the basics of how DCU first grabs a generic catalog, then based on the SKU follows that information to the specific catalog for the machine.

GARYTOWN’s Dell PS Functions beta

So, basically to make this easier, I’ve created several functions based on this data:

• Get-DellSupportedModels
• Get-DCUUpdateList
• Get-DellDeviceDetails
• Install-DCU
• etc… future posts

I have them available on my GitHub, and you can import them with a simple command. I have several more functions, but I’m not going to cover them in this post. I’m focused on the few things I really need to manage Dell Drivers & BIOS. To take them for a test drive, run this command in an elevated command prompt (after you check out the link for yourself of course)

iex (irm dell.garytown.com)

Get-DellSupportedModels

We’ll start with the Get-DellSupportedModels, which will load that first catalog, then supply a list of SystemIDs, Model Names (as they appear in the XML), the URL to the sub cab file, and the date of the last sub cabfile update. If you end up doing some automation to build offline repos, the date will be handy. This is building block function, that gets called in many of my other functions.

Get-DCUUpdateList

Next I’ll show the Get-DCUUpdateList, by default, if I was running on a Dell, it would look up the Dell SKU it is running from, and feed that into function, however since I’m running this on an HP, I’ll supply the SKU. This ability allows you to look up updates for any Dell model from any device.

It is now pulling back all updates available for the SKU 0B8A, lets pick this apart and look a bit more closely at the data.

$Updates = Get-DCUUpdateList -SystemSKUNumber 0B8A
$Updates.count

So there are 145 updates available, several types: Driver, Application, Firmware, BIOS, and in many categories.

This function accepts several parameters, so you can quickly find what you want. Example, let’s say you want to find the Audio drivers available.

Get-DCUUpdateList -SystemSKUNumber 0B8A -updateType driver -updateDeviceCategory audio

Ok, so now you get two results, for the same driver, just different versions, so let’s try adding -latest. You see that it now returns only the latest version of that driver.

I’ve added a TLDR switch, to format the results to allow you to see more info:

let’s do that again but remove the -latest and limit it to audio

So now it returns the 2 drivers we saw earlier, plus since we didn’t limit it to drivers, it also pulls back an audio application.

And just to show you can feed it a couple of types or categories, lets look for both BIOS & Audio related updates:

So you can see, with this function, you have lots of ways to slice and dice the update data, making it easy to see it in the console, or feed into variables and use in your own automation.

Current Parameters:

Get-DellDeviceDetails

This function is not overly impressive today, it’s a function I created to help myself track down Models / SKUs based on limited information. My goal was to model it after HP’s Get-HPDeviceDetails, so in time, hopefully I’ll figure out a way to add more info to provide better parity, perhaps someone at Dell will help.

In these examples, I show that if you don’t provide any input, it will work if you’re on a Dell machine, otherwise, provide info into the parameters, either a SKU or part of a Model Name

Install-DCU

It does what it says… it uses the feeds to pull down the catalog for the machine it is running on, looks up the DCU installer info, downloads and installs.

In my next post, I’ll demo this and show the other Functions for controlling DCU using PowerShell