Humble Beginnings
When I first started as a systems administrator at my current workplace, things were much, much different from the way they are today. Just to provide a little perspective – there was no domain or Active Directory or any of the related infrastructure in place. Users were just working ad hoc accessing the Internet and using their preferred apps or tools to get their jobs done. There was no inventory to speak of, so if a new hire were to start the next day, they would have to wait for up to two weeks before their hardware arrived and was ready for use. Aah, the good old days… (not really!)
The Cost Of Progress
So over time, I had set up the domain and the necessary servers to centralize core functionality like printing, shared file access, and user administration among others. Back then the organization was still a startup and staff count fluctuated somewhere between twenty to thirty users. The environment was also pretty homogeneous, consisting mainly of Dell laptops with a single Mac thrown in for one of the directors.
Fast forward about five or so years, and we are now having to manage over a hundred users working on Windows, MacOS, Android, iOS and several hundred Chromebooks thrown in for good measure (more on this later). So how to keep track of all these devices, not all of which are on site or connected to the local network, a myriad of apps being installed and an increasing number of remote users?
So Many Devices, So Little Time!
Something had to give if all these devices, their configurations and applications were to be brought under control while maintaining scalability and accommodating the continuing growth of the organization. And this was just scratching the surface since on overage there were at least two or three devices per user counting their personal mobile hardware.
Another challenge of this growth and increasing environment complexity and hardware diversity was how to keep tabs and control access to sensitive and proprietary data which started to play an increasingly larger role as compliance with regulatory standards became a necessity.
There were also very practical considerations to deal with as a result of all this growth. Even though IT staff has increased from a single systems admin (yours truly), and we eventually got a dedicated help desk tech, our resources became spread quite thin having to touch each device during deployment, maintenance and support. This simply would not work for us long term as this could not be scaled to manage and keep track of hundreds of devices running multiple operating systems and their associated applications. So this prompted a search for a centralized management solution to meet mobile device management objectives.
Management Out Of Chaos
So what were some of the mobile device management key features we were looking for? Here’s an abbreviated list of some of the objectives:
- Keep track of and actively manage already deployed devices (including remote systems)
- Create and apply centrally managed and standardized device profiles across operating systems
- Provision and deploy approved applications from a central repository
- Streamline security settings such as disk encryption and system lock-down
So we looked and trialed a couple of solutions with the above objectives in mind before settling on what we are currently using. The road to getting there was sometimes bumpy and often circuitous, but we finally decided on going with AirWatch from VMWare (or as it is currently known – Workspace ONE).
Trials And Tribulations
As we started out our trial of AirWatch, discovering its ability to manage devices from multiple platforms such as Windows, MacOS, and Android, proved to be a mixture of both a blessing and a curse. Why do I say that? Because each type of device had to be enrolled into the MDM (AirWatch in this case) before it could be actively managed, this meant having to learn the various ways of accomplishing this task. So, naturally, with such an encompassing system, there was quite a learning curve which wasn’t totally unexpected but certainly frustrating at times.
Once we had some devices enrolled, it was time to start figuring out how they could be effectively managed at scale. So in practical terms this would come down to applying a common set of configuration settings (in terms of security or features) across each platform as opposed to manually accomplishing this on a device by device basis like firing up a Windows PC out of the box, going through system prep, installing updates, applications, etc.
AirWatch accomplishes this by use of “profiles” which can contain such settings as Wi-Fi presets, security parameters, and applications being assigned to a device among others. So if it’s not becoming painfully obvious yet, there was a lot of upfront work involved with the initial setup and configuration of the MDM itself before it could be used to deliver all these payloads to managed devices. This was definitely a long-term learning process since we would discover something that maybe worked well for one OS but not the other, for example.
One such discovery early on was the fact that Google had not released its APIs for managing Android or Chromebook devices, so we had to settle for managing some Android tablets and all of the Chromebooks via Google’s admin console. Its feature set and the number of settings that could be centrally managed either does not exist in AirWatch or cannot be easily attained.
That was a big revelation to me as I was still holding on to the pipe dream of that one single solution that we could use to manage all of our devices regardless of their operating system. Over time this fact would be driven home even more as we delved ever deeper into the capabilities and features of AirWatch. This is not to say that this MDM is inferior or not useful, but to dispel any ideas of that killer app that can do it all when it comes to mobile device management. The experience with managing Chromebooks is a perfect example of having to use separate solutions because one of them is just better suited to the task than the other.
AirWatch In Action
So what does AirWatch bring to the table when it comes to mobile device management and how did it help us with accomplishing our objectives listed above? So let’s tackle the first one on that list.
Keep track of and actively manage already deployed devices (including remote systems)
This was probably the second largest upfront investment we had to make after the initial setup of the MDM because each device already in production had to be physically accessed to get it enrolled into the MDM. After some previous trials and errors, the enrollment process was fairly straight forward which involved installing the AirWatch agent and supplying our MDM environment credentials. This was more of a challenge with remote users since we had to coordinate remote support to get the agent onto their devices.
One interesting tidbit we found out as part of this enrollment effort was the fact that AirWatch played a lot better with Windows 10 machines than Windows 8. We had trouble enrolling the latter and getting them to properly show up in AirWatch early on. This was because, as we later found out, you could not use either the domain administrator or the local administrator account to enroll Windows 8 PCs. It had to be an admin user who was part of the local administrators group other than those two. According to AirWatch support, this was due to Microsoft’s implementation of device management in Windows 8. Be that as it may, it seriously impacted our ability to effectively enroll these machines and manage them in AirWatch. This is something that we are still having to clean up even to this day after having the MDM in production for almost two years.
Create and apply centrally managed and standardized device profiles across operating systems
While using some test devices while exploring the new MDM, we had created specific profiles for our two primary operating systems – MacOS and Windows, closely followed by iOS for the iPads we were also using. This allowed us to push out preconfigured profiles that controlled such parameters as Wi-Fi settings, hard drive encryption (both BitLocker and FileVault) and other payloads. This was further enhanced by creating assignment groups in AirWatch based on either a specific user group or another predefined characteristic shared by a group of devices.
Provision and deploy approved applications from a central repository
This objective was one of the primary reasons we wanted to get an MDM since it would allow us to deploy and manage applications at scale without having to physically touch each device. Similar to device groups created for shared profiles, logical groupings could also be created for pushing applications. So if a new application got added or an existing one updated, it would get pushed out to its assigned group.
This sounded really good in theory, but proved somewhat of a mixed bag in practice. AirWatch classifies applications as either Internal, Public or Purchased. Internal apps were primarily free apps for which we had the installer which got uploaded into AirWatch for deployment. Early on we found out that AirWatch prefers .msi files as opposed to .exe for pushing app installs since it supports the first one natively while the latter typically would require some scripting via a batch file. Another key discovery was that Internal apps required Windows 10 as the minimum OS, so this would not work with our Windows 8 PCs.
Public apps were by far the easiest to deploy since those would come from a web-based application store like the Microsoft Store, Apple’s app store or Google Play. Another benefit to these apps was that the link to each store always provided the latest version of the application and in the case of MacOS, updates would normally happen automatically. Purchased applications were mostly used with either iOS or MacOS since they had a number of licenses allocated to them from Apple’s app store.
So we had to devise another way to deploy applications to our pool of Windows 8 machines as they were not supported by the standard deployment process described above. Fortunately, AirWatch does allow for some customization when it comes to application packaging. What that allows you to do is create custom products by uploading the required installation bits and accompanying them by a manifest which would tell AirWatch how to deploy them. For example, I would upload the setup file for Google Chrome and the manifest would tell AirWatch to execute the install command using that file. Other apps would usually require the manifest to use a batch file (or script for MacOS) as it would contain multiple steps for the installation process.
This worked out fairly well in practice, although it sometimes took awhile for the installs to show up. But, of course, there were some applications that required either additional handling by custom scripts or just would not install for whatever reason. Again, a similar pattern emerged where this was most noticeable with Windows 8 devices, which only encouraged us to upgrade them sooner. Another trend we saw when it came to seeing consistent installs and updates was with Apple devices running either iOS or MacOS. In that sense AirWatch resembled Apple’s MDM.
Streamline security settings such as disk encryption and system lock-down
One of the first things getting automatically kicked off upon enrollment was disk encryption via 
either BitLocker (Windows) or FileVault (MacOS). This would later allow for auditing any devices that for whatever reason had not been encrypted or whose encryption status was uncertain. We had also created compliance profiles to flag any devices whose encryption status was in question that would query each device periodically and label them accordingly in case they didn’t pass the security checks. Beyond that, other security settings being pushed out allowed us to lock down such devices as iPads and Android tablets, preventing users from making unwanted changes to either system or application settings.
Going Forward
So while we are getting AirWatch to accomplish most of what we want out of an MDM, it is certainly not the all encompassing solution we would hope it would be. Frankly, I don’t believe one exists. AirWatch is quite good at accomplishing some tasks as described above, but we still needed other solutions as in the case of Google Admin Console in order to effectively manage any Chromebooks.
Another shortcoming, in my view, is that any time a device needs to be reassigned to a different user, it has to be unenrolled and re-enrolled under the new user’s name. This effectively erases any previous history a device had in the MDM. So this made us realize that if we wanted to also manage a device’s lifecycle from deployment to disposal, we would need to start looking into an asset management or inventory management solution.
Overall, I would say that AirWatch as an MDM is a useful addition to our arsenal of administration tools, just not a complete one. Again, I don’t believe such a system exists. Of course, your mileage will vary depending on what you are looking to get out of a mobile device management solution. So please share in the comments below what your own experience has been with an MDM, so we can learn from each other.