Hi,

I am working to use Dell Command Update to update the Dell Docking Station Firmware. How creating a local repository for that software for the dock?

I got a look to techdirect but it is only computers model and not dock. So how may I create a local repository easily including the dock firmwares?

Thanks,

We recently received updates for our dock firmware via DCU January 4th at my company we use Sennheiser headsets for audio through teams. Since the update we have noticed and an abundance of ticking and loud audio distortion when in a call. Just today I updated my dock firmware as I usually wait before updating and now I have the issue. We tested in multiple calling platforms, different headsets and different versions of teams and docks, the only time we had the issue was with the latest dock version and an Epos Sennheiser headset specifically the Impact D10. Has anyone else had this issue with different headset or different audio devices.

This journey started while trouble-shooting some performance issues with dell 7389s and 7390s, which also happen to use the WD15 docking station. In this trouble-shooting process, I updated the WD15 firmware and saw things get better. The next question was, “How do we update all docking station firmware across the company?”

When I updated the firmware manually on the machines I was trouble-shooting, the message listed a quite lengthy and hands-on process to complete the Firmware update:

1. Remove the USB Type-C Connector of the dock from the computer.

2. Remove the AC Adapter of the dock station from the dock.

3. Connect the AC Adapter with dock first then connect USB Type-C cable to the computer.

(For reference: https://www.dell.com/support/article/us/en/04/sln301970/dell-wd-15-dock-bios-drivers-installation-guide?lang=en )

This update also required a reboot to complete.

Not sure about your user base, but I certainly wouldn’t want to force our users to follow this process…. I’ve seen users straight up hold down the power button when the computer reads “Do not shut down… Please wait”. You think they’re going to follow the directions Dell listed above?

We currently have 45 (and counting) 7389s/7390s spread across 3 different locations. I don’t believe sending a tech out to each dock and updating the dock firmware manually is a viable solution, so I took this problem to our local Dell Technical rep.

I was given the answer of, “Use Dell Command Update! It’s really easy, and worked for me.”

Yep… I bet it did work for you. But did you deploy the firmware silently to 50 other laptops that are in use by real people?

We were then escalated to someone who (we’ll call him “Tyler”) deals more with deployment and management for enterprise, with specific emphasis on SCCM. Tyler said that we could simply run the firmware WITHOUT all the manual interaction, and we could run it silently…. I confirmed this, but then asked about the following realistic situations:

1. If the firmware update is ran silently, is the updated firmware cached in the dock somehow and applies the update sometime (days or weeks?) when the laptop is rebooted when physically attached to the dock?

2. Is the update stored in the laptop’s memory, and will only apply the full firmware once it’s rebooted while ON the dock?

3. If the firmware is installed silently and stored in the laptop’s memory/RAM, removed from the dock, and later rebooted, will the firmware update need to be re-pushed?

Tyler confirmed that I was at a critical part of the process, and that the dock firmware will only apply AFTER the reboot happens WHILE connected to the dock… so yes, the reboot IS in fact required.. and yes, while the laptop is attached to the dock. However, Tyler couldn’t confirm all of my scenarios; all of which are likely.

Given the fact that the dock firmware can only be upgraded while connected to the dock and with a reboot…. How do you handle this? I got escalated within Dell again, and I posed these questions:

- At what point do you apply the reboot for the firmware to take affect?

- Do you apply After hours? Not if the user takes home the laptop.

-During business hours while the computer is docked?

-Is that considered acceptable to users in most environments?

-Most users will reboot a computer during windows updates when there’s a clear message that reads, “Please Wait”. Are users more patient with dock Firmware updates?

-Higher likelihood of failure (possibly brick’ing a device?) with more user involvement.

-What if user receives silent update, undocks to go to a meeting, shuts down, then re-docks? Update clearly isn’t applied and has to be re-pushed. Vicious cycle.

We have a mobile device, physically controlled by an end user, that is updating a (critical?) piece of firmware on an external device. hhmmmm… The only worse way of doing this would be through wireless.

We later had a conference call with Dell, which basically confirmed we’re out of luck if we want to do any sort of management of WD15 firmware reliably, consistently, and with no user interaction. While on the call, I asked, “Is this acceptable to companies that have 500 WD15s?” We received about 30 seconds of dead silence…. Followed by “I understand where you’re coming from, but…”

Recognizing that Dell has no strategy on updating WD15 firmware, I came up with my own strategy, and this relies heavily on SCCM.

1. Create SCCM Package for Firmware. (I wanted to create application, but there’s virtually no way to validate if the “application” (firmware) was installed, so that doesn’t work.)

- Command line I used:

DellDockingStationFwUp_1.0.4_IE_03222018.exe /s /l="\\Fileshare\%ComputerName%.log" /p=YourBiosPassword

2. I then had to figure out a way to validate if the computer was actually attached to the dock. There’s no use in even starting the task sequence if the dock isn’t attached. Through some trouble-shooting and testing, I created this query, which seems very consistent:

SELECT * FROM Win32_NetworkAdapter WHERE ServiceName = 'rtux64w10'

3. I made the above query a requirement before even kicking off the SCCM Package. If the above condition is “True”, the package will run.

4. Once the package runs, you’ll notice that it writes a log to a fileshare.

5. I then include a reboot step. However, before rebooting, I forced another check to ensure the laptop is still connected to the dock, which is just the same query as above:

SELECT * FROM Win32_NetworkAdapter WHERE ServiceName = 'rtux64w10'

After-all, why would you reboot if the machine isn’t connected to the dock still?

Oh yeah… ensure you’re at the latest version of the Bios before taking this on. But I’m sure everyone here keeps their end user machines up to date with the latest bios.

The next major hurdle you’re probably wondering is, “How the heck do you know if the dock firmware actually installed, and what version is the Dell dock currently at? How can I feasibly report on this?”

There’s simply not a great way to do this, but there are a couple of ways.

1. Export the installation log to a fileshare while the firmware is installing. Certainly not great, but it will give you some insight.

2. Push out the Dell Inventory Agent to laptops. This also involves importing a new MOF file for SCCM Inventory. More information can be found here:

r/http://en.community.dell.com/techcenter/enterprise-client/w/wiki/7536.dell-command-update-catalog

Note: This (Dell Inventory Agent) is NOT the same as Dell Command | Monitor, and Dell Command | Monitor does not report on the WD15 Firmware version.

The strange thing with each reporting mechanism is that nothing really jives. The last two bios updates I’ve downloaded have had names of:

-DellDockingStationFwUp_1.0.4_IE_03222018.exe

-DellDockingStationFwUp_1.0.0.8_20161220_WD15.exe

However, the Dell Inventory Agent reports to SCCM that the updated WD15 version is

0001.0000.0000.0010

The log shows a bunch of different version for each device:

Wired Dock EC : Current Version:BCD:01000010: New Version:BCD:01000010

Wired Dock USB PD : Current Version:BCD:00010108: New Version:BCD:00010108

Cable USB PD : Current Version:BCD:00000312: New Version:BCD:00000312

Cur Pkg Ver:00000000 , New Pkg Ver : 00010004

New Dock EC is found. Using components firmware versions.

Testing Device and Payload versions for RBU update requirement.

0: description:Wired Dock EC Current Version:01000010 : New Version:01000010

4: description:Wired Dock USB PD Current Version:00010108 : New Version:00010108

5: description:Cable USB PD Current Version:00000312 : New Version:00000312

Firmware version is not newer. So, no RBU

Some significant caveats on the Dell Inventory Agent. The service only runs upon first boot… so if the end user is one who always powers on the laptop while OFF the docking station, docking station firmware is never reported. However, the Dell Inventory Agent (actually named “DSM CM Inventory Agent” and executable is DsiaSrv32.exe) service can be started manually… so you could probably figure out some sort of way to kick that off every day at 10AM for machines.

TL:DR

The firmware update process on Dell WD15 docking stations suck.

If a device needs firmware, it should be able to be managed through the network as a stand-alone device without user interaction.

Reporting WD15 Firmware versions is just as much of a goat rope as it is to deploy.