This post is a follow-up update to my previous article “Does Mobile Device Management Work?” and provides some additional insights as part of my VMWare AirWatch MDM review.
It has been a good chunk of time now that we have been using VMWare’s AirWatch which is currently better known as VMware Workspace ONE®. Much has been learned, tested and discovered during the last couple years of using this MDM (Mobile Device Management) solution, which is what prompted me to share it here for anyone else considering using this product.
Promising Beginnings
As explained in the previous post (see link above) about deploying and configuring this MDM, once the user devices such as Windows and MacOS laptops were enrolled and profiles created, it was mostly a matter of fine tuning the new system to effectively manage all of these computers. This is where things began to get interesting…
Issues Encountered
As I briefly alluded in my previous post about AirWatch, there was quite a bit of cleanup that had to be done since AirWatch did not want to play nice with Windows 8 machines. This process required quite a bit of time and effort to get these systems enrolled properly. Otherwise, they would show up with incorrect machine names or missing some pertinent system information. Another symptom of problematic enrollment for these devices would be manifested in the machines appearing in a state of limbo trying to complete the enrollment process and never getting there. The only solution at that point would be to completely unenroll any problematic devices (Enterprise Wipe or Delete Device from the More Actions menu). Quite frustrating and time consuming, to say the least!
On a related note, even enrolling Windows 10 machines was frequently a “hit and miss” proposition. Why would that be the case, you ask? Well, this primarily had to with which enrollment method was being used to get a device into AirWatch. There are multiple methods of getting devices enrolled, but we are going to be primarily concerned with two of them here.
Native MDM Enrollment for Windows Desktop
This enrollment method relies on the native MDM functionality built into both Windows 8 and Windows 10 (Settings > Accounts > Access work or school). Again, this seems to work much more reliably in Windows 10 than Windows 8. If you are not using Windows Auto Discovery, an AirWatch enrollment URL will need to be supplied during this enrollment process. This URL would be specific to your particular AirWatch hosted environment. One nice thing about this process is that as an admin in AirWatch I am able to enroll devices on behalf of any user without needing to know their password.
What has frequently become an issue for us with this enrollment method is the fact that devices would fail to register properly unless the next user to login to the machine is the person on whose behalf it had been enrolled. For example, I (Alex) would be enrolling a PC on behalf of User A, which would mean that User A would have to be next to login to this computer after completing enrollment into AirWatch. I am not sure what exactly causes this behavior, but the problem I have with this is that at the time we were troubleshooting these enrollment failures, there was no documentation from VMWare that had anything to shed light on this matter. I was only able to learn this from AirWatch support due to how many times we were seeing inconsistencies with this enrollment method. Again, much wasted time and effort spent on troubleshooting what should have been a straightforward process using built-in Windows MDM functionality.
VMware AirWatch Agent
One of the other methods advertised by AirWatch for enrolling Windows desktops is by installing the VMware AirWatch Agent from the Windows Store. Unfortunately, there are two problems with this enrollment method.
First, is that for Windows 8 devices, an installation of the AirWatch Protection Agent has to be performed manually in addition to the install from the Windows Store. Otherwise, the enrollment process for these devices never completes and results in unmanageable systems in AirWatch. To make things even more confusing, sometimes the order of installing these agents would determine the success or failure of device enrollment.
Second, the existence of two different agents (VMWare Agent and AirWatch Protection Agent) makes the whole process very confusing and VMWare’s documentation was not providing very clear guidance on deploying these agents. Also, VMWare introduced another, albeit more streamlined, agent enrollment option – “Workspace ONE Intelligent Hub for Windows Enrollment”. Unfortunately, it is only available for Windows 10 devices, so if you are trying to enroll a Windows 8 PC, you are out of luck.
No longer an issue for us as we have transitioned 99.99% of our machines to Windows 10, but prior to this change it certainly affected our enrollment process of any device running Windows 8. Also, in searching VMWare’s documentation, this deployment option was not easily discoverable and we had only learned about it from AirWatch support when troubleshooting.
Device Management
Getting beyond the challenges described above, next issues encountered had to do with managing newly enrolled devices when it came to such things as pushing applications and device profiles.
Applications
One of the main goals of employing an MDM such as AirWatch in the enterprise is the ability to deploy applications to remote systems without having to physically touch each device. Since there are several applications being deployed over and over to multiple devices, it makes sense to configure their deployment for automatic installation from the MDM.
Once again accomplishing this task in AirWatch can take different paths depending on the installation package being used. I want to clarify that I am focusing here on Windows applications for the purposes of this discussion since deploying MacOS apps is more straightforward and appears to function much more reliably than their Windows counterparts.
After adding multiple applications to AirWatch for deployment, it became quickly apparent that .msi packages are clearly preferred and are easier to configure than plain old executables (.exe). This is because AirWatch supports .msi packages natively and is able to extract such bits as version, install and uninstall command strings.
So if the application developer only provides a regular executable installation package, you will need to configure additional installation and uninstallation parameters manually. This is prone to error and ends up being mostly a trial and error process. Also, AirWatch would not reliably deploy apps for us with this approach as it had trouble passing command line parameters during execution. So at this point you would have to create what AirWatch refers to as a “Product” which requires multiple steps starting with uploading the installs bits and creating a custom manifest that would typically include a custom script in the form of a batch file.
Support
If you have read thus far, you’ve undoubtedly noticed me referring to AirWatch support. We’ve had to contact them on numerous occasions to either resolve issues or help us figure things out to make this MDM solution usable.
Well, to say the least, while I generally believe that all the various techs we have interacted with over this period of time tried to be genuinely helpful, I simply cannot overlook the fact that support quality has been poor from the start and has degraded over time. Some key points for giving thumbs down to AirWatch when it came to support:
- Very difficult (if not impossible) to initiate a support case by phone. While AirWatch seems to be based out of Atlanta, Georgia, the support center appears to be somewhere in India. Not that uncommon nowadays, but not really a valid excuse for not providing a phone number to call into that is well publicized instead of needing to search for it.
- Response times spanning anywhere from a day to several days or more. I have personally had a support case that dragged on for over two months. Ultimately, we just gave up and switched to another solution for reliable application deployment to our Windows systems.
- Most support techs have no concept of time zones outside their own. My colleague got multiple calls at 6 AM local time after clearly specifying his time zone and availability.
- While it has been technically possible to locate information in the online knowledge base provided by AirWatch, it was certainly not easy. The KB frequently contained outdated information applicable to earlier versions with a different interface or in our experience being what I would call “undocumented features”.
Needless to say, all of the above issues, experiences and terrible support have prompted a search for another MDM solution. I will be describing what we eventually settled on in a future review post, so keep checking back for that. It’s not that I am hating on VMWare in general or AirWatch specifically, but I cannot in good conscience recommend this solution any longer and hope this helps some of you out there considering this option.
Other MDM and/or systems management solutions we have looked at included IBM MaaS360 and Microsoft InTune. I would really appreciate your feedback to this post as well as any experience you can share regarding your usage of these other MDM products.
