Physical efforts in virtualization and mobility
I’ve been working on a couple of AirWatch engagements recently and as a result, my product knowledge has had to move to a lower level. Being more of a ‘Citrix Guy’; from an MDM perspective I’ve had more involvement in XenMobile up until now, but seeing as Citrix is deemed a 2nd tier vendor by the likes of research firm IDC, it’s surprising the lack of resources there is out there for top tier AirWatch compared to XenMobile. Maybe it’s because AirWatch really push the SaaS model where the on-prem is the poor relation (~70/30 market split) so there is less community interest out there.
What I wanted to cover here was how the headline products fit into the AirWatch architecture as at first glance it’s not obvious, to this end I have created a flow chart as a kind of decision matrix. The components will change depending upon requirements and if SaaS is chosen over on-prem.
Below I will briefly cover each of the key components
Device Services Server – This is the Server that actively communicates with the devices and handles enrollments. Seeing as devices will normally be anywhere and everywhere, this server needs to be available on the internet. For SaaS deployments, clearly this will be handled but for On-Prem, this will normally located within a DMZ with SSL punched through to the internet secured with a public certificate.
Console Server – Sometimes called the API server, the server communicates with the Device Services Server and contains a Web App (IIS Site) for administrative control of the environment. This will normally be placed on the internal LAN, but would be possible to combine with the Device Services Server.
Database Server – As with most enterprise products a database is required; clearly AirWatch holds a lot of device data and this needs to be stored somewhere. Note that SQL is the only supported database type and it needs to be full SQL, not express. Again, this could be combined but in larger deployments would be separated to aid with high availability plans.
In a SaaS deployment, all of the above will be hosted and managed by AirWatch, but required for all deployments be they SaaS or on-prem. The following components however, are optional depending upon requirements.
AirWatch Cloud Connector (ACC) – This is nearly always used in SaaS only deployments for bringing the above three components to local customer based back-end resources. Typical integration components would be Directory Services (LDAP), Microsoft Certificate Services, and Exchange to name a few. If you have a SaaS deployment, your AD is locally hosted and you want to configure Auto enrollment for end users to use their email addresses for example, you’ll be needing ACC. This is normally placed on the internal LAN with a direct outbound connection to the internet so it can communicate with the AirWatch SaaS. This can be either direct (preferable) or via internal proxy.
Just a quick note on connecting components via proxy – At the time of writing (v126.96.36.199) proxy PAC files are not supported in the ACC but they are for the MAG!
AirWatch Content Gateway, formerly Mobile Access Gateway (MAG) – The MAG (also known as MAG Endpoint) is a relay for accessing internal content. It differs from the ACC which is more about authentication where the MAG is proxy and content. This component is secured in terms of Airwatch (‘Containerised’) so if you plan to use it you will need to be using one of the AirWatch client based products to access the content, that being Secure Content Locker, the AirWatch Browser and Enterprise Apps that have been subject to AirWatch App Wrapping.
In terms of placement there are a number of options. Really, being a reverse proxy, this is a DMZ type of component but could be a pain to manage as and when you want to open it up to more back end resources, this is because you would need to add rules for each server (unless you cheat and open up a subnet or whatever). If you have no DMZ, it’s simple as there is only one option which will be LAN placement. If you do have a DMZ the best approach would again be internal LAN but also to use the additional sub-component….
AirWatch Content Gateway Relay, formerly Mobile Access Gateway (MAG) Relay – This is part of the same installer as the above but you just choose the relay option. This is designed to be placed in a DMZ and is what your external devices will be pointing at along with the AirWatch Cloud Messaging Service. This simplifies ongoing management in a DMZ scenario as the internal ‘MAG Endpoint’ server can be left fully open to chat to all internal resources whilst the communication remains secure with the relay handling connectivity between the devices, AWCM and the internal MAG. In the MAG configuration on the AirWatch management console it just needs to be told that’s it’s using the relay model rather than basic endpoint.
AirWatch Tunnel – This is a Linux based product that I suspect at some point this will replace the Windows based Content Gateway. For the time being though, both are required if you want to externally publish Content for use with the Content Locker Client App, Wrapped applications and Per-App VPN. In a nutshell, AirWatch Tunnel doesn’t yet work with Content Locker and the Content Gateway doesn’t work with Per-App VPN (and probably never will). Like the Content Gateway, this is also available as a Relay configuration. Something to bear in mind is that as mentioned this is Linux based installation. This does not mean as I expected a virtual appliance, it’s purely a Linux installation which requires CentOS or Red Hat Enterprise, so you’ll need a level of Linux capability to implement this.
Secure Email Gateway (SEG) – Let’s be clear, the SEG isn’t a requirement for end users to be receiving emails on their devices but it is certainly beneficial. The SEG sits between your Exchange ActiveSync server(s) and enables greater control and monitoring of email to and from enrolled devices. ActiveSync is globally enabled on Exchange and while it can be switched off on a mailbox basis and (since Exchange 2010 SP2) be subject to device quarantine rules, it is not very easy to control. The SEG will proxy the ActiveSync communications and block/allow depending upon configured policy.
Cloud Messaging Service – This is mentioned for information, it’s a different sort of component to the above as it is a facilitator rather than something that performs it’s own specific front end function but it is important. It handles messages from the Administrative Console, and is a pre-requisite for both the MAG and ACC. For SaaS deployments this isn’t a consideration as it is preconfigured by AirWatch but for on-prem this needs to be installed and configured, typically on the Device Service Server. Seeing as the ACC is generally only used in SaaS implementations though, this is normally only a concern for MAG installations. Part of the MAG configuration requires the Cloud Messaging Service details to be entered.
Something else to bear in mind is licencing as these components don’t directly fit into their licencing models – well they do, but you have to base the components on the requirements and subsequent licencing model, which will spit out the required components. The licencing models and pricing is available publicly here. You could actually integrate any of the below components and no licensing would be breached but take for example the MAG; yes this could be fully integrated into AirWatch but unless you are doing App Wrapping, using the AirWatch Browser and/or Content Locker (which would require a ‘Blue’ license) it’s inclusion would have no benefit.
So what I’ve done on the flow diagram is to colour the text in accordance with the required licencing banding assuming you are requiring features that require the component in question.
Component Flow Chart
So without further ado, here is the flowchart I have created help with all of this. Note the decision questions are very high level, other questions could be asked of the capabilities particularly around the ACC which has many integration points.