One of our clients is a national consumer packaged goods (CPG) distributor with a large fleet of Zebra MC9200 handhelds, most several years old, all running a variety of Windows CE versions. Handhelds with older versions of the WiFi driver were having issues dropping the network connection, and the client generally wanted to standardize on a single, current OS version.

These handhelds were all enrolled in AirWatch/WorkspaceONE, and the client had previously attempted to deploy OS upgrades via MDM, but they weren't able to get the setup to work at all. The size of the fleet meant that manual upgrades were out of the question. Now that we were managing their handhelds, we wanted to design a configuration that would allow all devices on older versions (and only those devices) to be upgraded automatically with little to no user intervention. This proved harder than we thought.

What follows is our testing process and the configuration that eventually worked. Note that these steps were conducted on console version 19.03.0.6 (1903). Other versions may have different behavior.

INITIAL TESTING

The first step taken was to construct an OS upgrade configuration with the new OS files to confirm that AirWatch could successfully upgrade the OS on test devices. The OS package is a series of files with an updater EXE, and the process is to load the files onto the device then execute that updater. To accomplish that, we built a Files/Actions entry in WorkspaceONE that uploaded the files and included an install manifest run command to start the upgrade.

Next, we created a Product entry that installed that Files/Actions we created, assigned it to a test assignment group that targeted our test device, and waited. After a few minutes downloading the files, the device went into the upgrade process, rebooted, and came up with a screen calibration page. Success!

Maybe not. Looking at that device in the WorkspaceONE console, while the OS version had updated to the new one, the Product we created did not show Complete. A few minutes later, the device again went into the upgrade process and rebooted again. This reboot cycle continued overnight, with AirWatch never able to see that the upgrade was completed successfully.

We opened a ticket with VMware, but they were unable to replicate the issue. Come to find out, they were testing on a newer version of the Console that had not yet been deployed to our client's cloud environment. We went back and forth with VMware, exchanging logs and trying various settings changes in the Product, but we couldn’t get it to work.

Ultimately our engineers came up with a workaround. When the upgrade executes, the install files are deleted upon completion. We thought we could take advantage of that. Instead of having the file load and upgrade execution occur in the same Files/Actions and Product, we split them into two separate components with a dependency set up.

WorkspaceONE would first deliver the upgrade files via the first Product, then when that Product showed complete, the command to run the installer would be executed. Because the installer deleted the files at the end of the upgrade process, we didn’t care if that second product showed as completed or not – if WorkspaceONE tried to make it execute again (repeating that loop we experienced before), there would be no file to run and it would simply show Failed with no ill effects.

AUTOMATING DEPLOYMENT

Our next task was to determine how to deliver these two products automatically only to devices with older OS versions. WorkspaceONE Products support Assignment Rules, which allow you to specify conditions that must be met for the product to be sent to a device. One of those conditions is OS version, so we first attempted to establish an assignment rule that would target any device with OS less than our upgrade version.

Unfortunately, when setting that rule, we kept running into a save error. We worked with VMware to figure out what was going on and realized that the OS version property returned by the agent app is a string. WorkspaceONE only knows how to do less-than and greater-than comparisons on numbers.

While we couldn’t set a rule for less than our target version, we could set a rule and use the not-equal or “NOT IN” comparison operators. This workaround isn’t ideal, as we don’t want new devices with newer OS versions to get our product, but for now it would work.

We now had a working config:

• Two separate, dependent products to execute the upgrade
• Assignment rules that would target only older versions

This config was deployed over a weekend, giving plenty of time for devices to check in, download the files, and execute the install. While we had a few stragglers that weren’t checking in or had network issues, the project was completed by midday the following Monday.

CONFIGURATION DETAILS

Below are instructions on how to implement the final configuration we landed on after all our testing. We always recommend testing any configuration on an Assignment Group with specific test devices selected.

1. Navigate to Devices -> Provisioning -> Components -> Files/Actions
   
2. Click "Add Files/Actions" then choose Windows Rugged to start the process of creating a new entry.
3. Give the package a name, then upload all the files in the OS upgrade package. For Windows CE devices, we typically specify that files be downloaded into the \InstallerFiles directory, but you could also use \temp or a subdirectory under \temp. In our testing we had consistently better results using the \temp directory as a target. AirWatch will create the directory if the one you specify doesn't exist.
   
4. Save and close that Files/Actions, then click to create another.
5. Give the package a name, then in the manifest tab create an Install entry that will run the StartUpdLdr.exe file that's in the upgrade package. The command line value must exactly match the destination location you specified in the Files tab of the first Files/Actions entry. This is very important. It's an easy mistake to make, so triple-check it! Also note that other OS upgrade packages may have different installer EXE's. If that's the case, you may need to change the command. We set the critical setting to "Continue" and timeout to 0.
   
6. Save and close, then navigate to the Product List View.
   
7. Click “Add Product” to start the process of creating a new entry.
8. Give it a name, select your assignment group, and click “Add Rules.” In the next screen, select “OS Version @ AW_Agent” – “<>” – then the version you’re upgrading to. Finally, click “Add Rule” and make sure it shows up in the Rule Logic box below. Note that you won’t see the new version in the list unless you have at least one device enrolled with that version. This means you may either need to manually upgrade a device or save this step for after testing.
   
   
9. Click save to return to the Product creation screen, then click on the Manifest tab.
10. Click “Add” then select “Install Files/Actions” and select the Files/Actions you created to deliver the upgrade files. Click Save, then click Save on the Product entry screen.
11. Repeat the process for the other Files/Actions entry you created, but this time, before saving the Product, click on the Dependencies tab, and add a dependency on the first Product you created. This setting will ensure that this second Product won’t execute until the first one completes.
    

 

We hope this article has been helpful and will serve as a technical resource to assist you with OS deployments and upgrades on Zebra Handheld Devices. Acuity can help your business support existing MDM software, or we can design and implement a program that works best for you. Contact us for a free consultation.