Sometimes upgrades have a different outcome than expected. Sometimes a system is more important that others and the impact of a negative outcome is more severe. Mobile device management is that kind of system. When a mobile device management system has issues all devices enrolled have issues. Last week I upgraded an on-premises VMware AirWatch environment from 9.0 to 9.2. The upgrade went smoothly but the aftermath was harsh. Several users reported that they lost they applications after the upgrade. This short article is about what went wrong as of course something went wrong and how to fix it.
The symptoms are simple, the applications are lost on the end user device. That’s what the user will report to you. If you look any further you see that the device is effectively un-enrolled. The profile is not installed any more.
Before you start the upgrade you need to backup the database and disable the services, the AirWatch services and the IIS service. You also need to install .Net 4.6.2 or let the installer handle that. After .Net is installed it requests a reboot and if the IIS service is not disabled at that time it will start again at reboot. When the IIS service on the Device service server starts up with no database connection (AirWatch services are down) it will create a empty page (200).
Devices checking in at that time will connect to this blank page and think they need to un-enroll. Due to security measures all applications (the MDM agent is also an application) are configured to deinstall with un-enroll. So that is what happened here also, all applications deinstalled, the device un-enrolled.
A little deeper
When this happens you will see strange things. Due to the fact that the database and the services where not online, the console will show the devices with their apps even though they are un-enrolled. Communication seems to be working, they report in and if you deploy an agent on them they seem to work. You can’t however deploy apps to them or request a check-in. They are like orphans running in the wild with the backend unaware of their real status.
The fix is simple, do a delete device from the console and re-enroll them again.
Once the device is deleted you can add it again. There is no dataloss for the end user except that you might have to reconfigure some of the applications again. For instance the token application they use might need to be re-enrolled again as well. So add the device to the user. Go to Accounts, find the user and click on Add Device. Click on message preview to get the QR code and enrol the device. Use the QR code which is easier as the user needs to be enrolled first before they got access to E-mail which is the default option.
And with that you can fix the upgrade issues that occurred with the IIS service. It’s simple but even better is to make sure and double check if the service is disabled. That is something I will never forget to do. Just wanted to share this so you are saved from a few days troubleshooting.