Physical efforts in virtualization and mobility

NetScaler VPN SMB Share Access and Group Policy Retrieval

It has been a VERY long time since I’ve posted anything but I just had to get this quick one out.


Standard NetScaler Gateway for Citrix Virtual Apps and Desktops, with StoreFront, with Universal Gateway feature of SSL VPN. Laptops have the Citrix NetScaler Gateway Plug-In, Split tunnelling is set to OFF, so all traffic is forced down the VPN connection.

Connect to the URL with either the browser of the Gateway Plug-in works fine, intranet site and proxying to the Internet works fine. User home drives, and general departmental shares do not work however, even though SMB port 445 is open from the NetScaler (SNIP) to the file servers.

What we found is that mapping the file shares using IP address instead of the host name the file shares worked fine. What we also found is that using a non-domain joined laptop, the file shares worked fine with both host name AND IP address.

  • Add the laptop to the domain – Fails
  • Remove it from the domain – It works again



Please bear in mind this article is not to scale and this took a very long time to bottom out, this article was a clue.  So we got the firewall guy on the phone and did a trace from the NetScaler SNIP to ANYWHERE to see if there were any drops. The key one we found was port 88 Kerberos, to the domain controllers. This was denied, and to be fair we hadn’t requested it.

Next day this was added and SMB shares were now working fine.

Note that port 88 is UDP with a TCP failback so ensure that both are requested.

It’s also worth pointing out that this port is not listed on either the Citrix Ports or Industry saviour Carl Stalhood’s firewall rules guide , if it was it would have been requested already. Personally I feel that mapping drives via VPN is a standard requirement, even in this day and age of using OneDrive etc.

Update…Group Policies over VPN

Another issue we’ve found was that when connected over VPN, group policy updates would not apply, and running GPUpdate /force would fail  eventually timing out and producing a DNS error. What we discovered was that TCP port 135 from the SNIPs (or VPN pool, if configured) to the domain controllers,  was also lacking from the previously mentioned documentation.

Until next time….maybe!

VMware Horizon Internal Traffic Ports

Following on from my last post which focussed on traffic flows to enable remote connectivity, I thought I would look at the internal side of things. I am coming across more and more on premises environments where there are lots of VLANs with firewalls inbetween them so this is becoming more of a requirement.

For this post I have just produced a diagram which you may find useful, when I get time, maybe I’ll produce another firewall spreadsheet. This diagram assumes that there is a common server VLAN hosting the likes of the Connection Servers and App Volumes Managers so I have not added the ports required between those sorts of components.

Horizon Ports - Internal

You may have noticed that I favour flat diagrams over the 3D ones that VMware produce. I have created a basic Visio stencil set for these which you can download if you wish.



VMware Unified Access Gateway Firewall Rule Generator

Hello Folks,

When deploying Virtual Desktop/Application remote access solutions you often need to engage with ‘The Firewall Guy’. This can often be a difficult conversation involving lots of questions such as “what?”, “from where?”, “to where?” and “why?”

To this end I have created a Unified Access Gateway Firewall Rules Generator which you can download. You just need to plug in the parameters on the lookup tab and it will pre-populate the firewall rules for you. Other than the standard back end stuff which you (as the Virtual Desktop Consultant) should already know, the only things you need to ask the firewall guy for are:

  1. Unified Access owned IP addresses in the DMZ
  2. Internet facing IP Address for the NAT rule  – You don’t actually need to know this yourself but it helps in order to provide a fully completed rule set
  3. Certificates – May be from someone else entirely

Hopefully you won’t even need to talk to the firewall guy at all after that! You can fill in the sheet and email it off to him/her. Here’s a diagram I put together with the ports:

UAG Ports

A Few points to note:

  • This is based upon the information from this VMware article which I found to be missing items such as DNS and RADIUS so I have added these in
  • The deployment mode is based upon the two IP addresses per Access Point; Single IP will work fine, just enter the same IP in both the Front-End and Back-End Management sections
  • When Deploying the Unified Access Gateway either via PoSH or OVF, the first IP entered becomes the external one, not the Management/Backend Communication one, which is the second one entered
  • If you want to read a blog on actually deploying UAG, this by Carl Stalhood is probably the best one out there

I’ve used the PowerShell deployment method before but since 2.8 the OVF deployment actually works properly so it’s just as easy to deploy it that way then import your predefined settings from a JSON file.

Automating Creation of Desktop Pools in VMware Horizon

I don’t know about you guys but I really hate the add new pool wizard in VMware Horizon. Generally speaking, I only work with non-persistent pools and during the life of a project will create and tear down a number of pools for dev, test, UAT and then create a bunch or production pools later on. These pools will have pretty much the same settings except for a few things like pool name, naming pattern, target storage etc. I get fed up with having to click around on the same stuff when all I want is effectively a duplicate with a few bits changing. What got me onto this was the desire to fix production pools to specific vSphere network labels detailed here.

First of all you will need some information about your environment, best thing is if you’ve been through the wizard once and have a pool setup like you’d want it to end up, run:

Get-Pool > C:\Temp\Get-Pool1.txt

From the resulting text file you can copy and paste all of the information you’ll need to automate the creation for all future pools. In particular you will want:

vc_id #Virtual Center ID so static setting
vmFolderPath #The parent folder where the desktops will land so static setting
ResourcePoolPath #Path to the vSphere Resource pool, static
ParentVmPath #Path to the Master VM so static setting
ParentSnapshotPath #Path to the particular snapshot of the above VM, more likely dynamic setting
DatastoreSpecs #Path and configuration of storage could be either static or dynamic
Composer_ad_id #Composer ID, static setting
organizationalUnit #Where the Computer accounts in AD will land, dynamic setting
NetworkLabelConfigFile #Path to text file containing the Network labels to use, built in the article mentioned earlier

I’ve noted above which of the settings are static (ones unlikely to change between pools) and which are likely to be dynamic.

Next you can use this example PowerCLI just changing the bits from your Get-Pool. The red text is stuff that is unlikely to change within an environment and the greens are ones that you will probably want to overwrite with the specifics of a new pool. You’ll need to run this on a connection server in an administrative PowerCLI window (you can remotely connect too if you want).

Add-AutomaticLinkedClonePool -Pool_id UAT1 -NamePrefix “UAT1-{n:fixed=2}” -Vc_id 40263e00-123e-43481-9a05-99afg09732c3 -Persistence NonPersistent -VmFolderPath  /Datacenter1/vm/Desktop Pools” -ResourcePoolPath “/Datacenter1/host/Cluster1/Resources” -ParentVmPath “/Datacenter1/vm/Reference Desktops/GOLD01” -ParentSnapshotPath “Snapshot1/Snapshot2/Snapshot3“-DatastoreSpecs “[Aggressive,OS,data]/Datacenter1/Custer1/Storage1” -Composer_ad_id 474cdee0-60dd-447f-bdfr-692rg3f83dbe -UseUserDataDisk $false -organizationalUnit “OU=UAT,OU=Virtual,OU=Clients” -NetworkLabelConfigFile “C:/Temp/label1.txt” -UseTempDisk $false -MinimumCount 10 -MaximumCount 10 – HeadroomCount 1 -PowerPolicy RemainOn -deletePolicy RefreshOnUse -SuspendProvisioningOnError $false -defaultProtocol PCOIP -allowProtocolOverride $false

So this powerCLI string will create a NonPersistent pool called UAT1 with 10 machines using a naming pattern starting at UAT1-01. It will not use a disposable disk, will refresh desktops at logoff, use PCOIP as the protocol and not permit the users to change to RDP. Just changing a few parts of this string means you can quickly create new pools in seconds by just pasting over the pertinent parts, and no more using that annoying wizard that seems to take days to get through…..

VMware Horizon 6.2 NetScaler TLS Support

So it turns out that TLS 1.1 and 1.2 is not supported on the NetScaler VPX platform to communicate with the backend servers.

Update: At the time of writing this was the case but support has now been provided with version 10.5 Build 65. MPX and SDX appliances would also be affected if they are running firmware older than 10.5 Build 58. I have since load balanced these services successfully using MPX 10.5 Build 60.7004.e with no need to carry out the procedure below.

The check boxes are there on an SSL Service Group but they won’t allow you to tick them. The trouble with this is that Horizon View 6.2 forces use of 1.2 on Server 2012/R2 so if you have created an SSL service group and point to 6.2 Connection servers (or recently carried out an upgrade), the members will show as Red (Down). Given the lack of support on the NetScaler end, the only workaround at the present time is to add TLS 1.0 support to the connection servers, which is achieved by editing the View LDAP instance on the Connection Servers using ADSI Edit. Below is a procedure I have adopted from the VMware documentation center but is specific to this issue:

1. Start the ADSI Edit utility on your View Connection Server computer.
2. In the console tree, select Connect to.
3. In the Select or type a Distinguished Name or Naming Context text box, type the distinguished name DC=vdi, DC=vmware, DC=int (exactly this DN, not your own domain)
4. In the Select or type a domain or server text box, select or type localhost:389
5. Expand the ADSI Edit tree, expand OU=Properties, select OU=Global, and select CN=Common in the right pane.
6. On the object CN=Common, OU=Global, OU=Properties, select pae-ServerSSLSecureProtocols, this will be configured as <not set>
7. Enter the following string in this field \LIST:TLSv1.2,TLSv1.1,TLSv1
8. Restart the View Connection Server Service

You do not need to do this on the other connection servers as this change will replicate to all other servers in the cluster. Restarting the Connection Server service on all of the all of them will suffice. As a side note, this also seemed to affect Imprivata OneSign appliances connecting to the Connection Servers so it looks like they don’t support TLS 1.2 either.

Suppressing iOS updates

So you’ve got a whole bunch of iPads out in the field hosting various applications and iOS9 comes out; one of the application vendors tells you his application isn’t quite ready for the latest OS and that you should hold off on updating your fleet. Problem – If you look for an option to disable iOS updates in your MDM suite you won’t find it, this is not a limitation of your MDM provider but more a control that Apple hasn’t provided to them. So if you ask your MDM vendor they will probably say it’s not possible, and as far as I can tell this is indeed the case. I’m going to keep looking but for now the best we can do is suppress the notifications that pop up advertising to all and sundry that a new version is available, but even this is not an out-of-the-box setting so I’m going to explain how it’s handled in AirWatch.

  1. Create a new iOS profile and in the General section endure that the Assignment Type is Auto using your All Corporate Devices (or similar) Smart group.
  2. Select the Content Filter payload
  3. Select Built-in: Deny Websites
  4. In Blacklisted URLs enter (Don’t be tempted to use any * here as is common with proxy exceptions as AirWatch doesn’t seem to recognise them and it breaks the string)
    1. Note that the requirement is iOS 7+Supervised for this to work, so have a read about DEP if your aren’t sure if you are able to meet this requirement.
  5. Click Save & Publish

Now there’s nothing to stop users navigating through the menus to check to see if there is an iOS update, finding one and proceeding to download and update it themselves, so this is about as good as it gets for now. According to the comments this short article it is possible to use via a proxy server (although I think it should be – note no ‘e’ on apple) to disable access to the download location but I didn’t have any joy with this. If I ever get any further with this issue I’ll post an update with the final solution.

Device enrolment options and DEP (Device Enrolment Program) Pt.2

DEP was discussed at a high level in the previous post; it is a facilitator for corporate owned iOS devices to be quickly enrolled into MDM solutions, all of the major MDM vendors support this.


First off, an account is required to manage the DEP portal and the devices within it. This is essentially another Apple ID which is created at – I think it is worth pointing out here that I tried using the same account that was used for management of the APNS certificate to start with and this wasn’t allowed so be prepared to manage two accounts going forward, one for DEP and one for APNS.

AirWatch Console

Now this process will be pretty much the same for any MDM provider but true to form I’m using AirWatch here. What we are doing is linking the MDM solution with the DEP account which contains the devices, once complete all of these devices should appear in the Device Lifecycle section of AirWatch (it may not actually contain any devices at this stage so this may happen later). So head over to the AirWatch console and navigate to:

System > Devices and Users > Apple > Device Enrollment Program > Configure

AW shot1

In order to link the two systems a token needs to be uploaded from AirWatch to DEP so from within this section, select to download the MDM public key file and then click the link to be taken straight to the DEP page and log in with the account created previously.

DEP Portal

Once within the DEP portal you may be startled by how sparse it is, there really isn’t very much one can achieve in there over and above the initial setup.

DEP Landing screen

Considering DEP holds your organisations inventory of iOS devices you may think you could run reports and so on from here but this is not the case. DEP will provide a very high level overview of what is in inventory and some rudimentary details of the MDM server(s) (yes you can add more than one) that is linked to the DEP account, other than that all other management and reporting is handled within the MDM tool.

  1. Going back to the implementation, click the ‘Get Started’ link and you will be prompted to setup two-factor verification link via SMS to a mobile phone. Multiple numbers can be used in case of different admins logging in (but note using the same Apple DEP account) but this needs to be used on every single login to the portal.
  2. Select ‘Add MDM Server’, give it a friendly name and tick the box to automatically assign devices and select next
  3. At the following screen upload the pem token generated on the AirWatch server a previously, click next and in return you can download the Apple Server token file which is to be uploaded to the AirWatch server – As you can see this linking process results in a bi-directional trust between Apple and in this case, AirWatch.

Finally there is the opportunity to assign devices if they are actually ready at this point, which can be assigned via either order number of by serial number. At this point it should be explained that DEP only ties into affiliated Apple resellers, if you do not purchase them from such a supplier DEP will not be an option for you so ensure you ask this question of the supplier before committing to an order. Personally I would always use the Order option as you will get the whole lot dumped in there with no messing about, in fact once up and running the supplier can simply drop devices into the portal (you will receive an email notification) and so long as the ‘assign automatically’ box was ticked on the server setup in the previous section, no further administrative action is required on your part. If you like though, you can not do this and paste in the serial numbers to DEP and have them enabled that way.


(Back to the) AirWatch Console

So here we are back at the AirWatch Console and we are now in a position to create the first DEP profile via completion of the DEP wizard. First of all you’ll be prompted to upload the Apple Server token file that was downloaded from the DEP portal previously to complete the linking process.

The wizard will then guide you through the creation of the first DEP profile; after which, additional ones can be created manually. As I have been through the wizard previously on my deployment I can’t re-invoke it without a lot of phaffing about so below I have will go through the settings as part of the manual profile setup which is the same but just displayed differently on screen. The profiles are split into three sections, Authentication, Features and the Setup Assistant:


DEP Auth

Authentication can be simply enabled of disabled, the default is ‘On’ which will result in an authentication prompt for the user as part of the enrolment process. Below is how this section will change if Authentication is set to ‘Off’. The device can be ‘Staged’ in this mode, so enrolled and ready to go but not tied to any particular user. The options here are for:

  • Single user device
  • Multi-user device
  • None

Note, if Single or user device is set an AirWatch basic account would be selected and used to enrol the device which can help place the device into a specific Organisation Group.

Going back to the first screen shot above, the next option is the Device Ownership Type. Now I’m struggling to think of a scenario where anything other than Corporate Dedicated would be used here with the other two options being:

  • Employee Owned
  • Corporate Shared

Employee Owned (BYOD) devices just don’t fit in into the DEP model at all, not least because end users wouldn’t be able to purchase and link them into DEP (happy to be corrected on this)

Corporate Shared would be better using no authentication and staged as the below screenshot shows but instead selecting the ‘Multi-User device’ staging mode. Users can then authenticate as and when each time the ‘check out’ a device so it can be returned to the pool for the next user.

DEP Auth off

Lastly in this section, the device ownership is selected for the profile along with the organisation group where you want the device to land once enrolled. These options will change again based upon previous selections, for example if Multi-User Device is selected, ‘Corporate Shared’ will be enforced and greyed out.

MDM Features

DEP Feat

Here we set the Profile Name, Department and Support number which are compulsory free text fields followed by some DEP specific MDM settings.

Require MDM enrolment – Yes there is an option disable enrolment as part of this process, I really don’t know why you would disable this but the option to skip is here folks if you chose to. This is pretty smart because if there are ever any issues with the iPad or there is a change of ownership, you can send the device a full device wipe instead of an enterprise wipe; it will then be back to an out of the box configuration maintaining the enrolment settings and enforcement into the MDM server.

Supervision – As mentioned in the previous post which covered supervision, for the Corporate Owned model, which DEP is aimed at I would always enable this to expose the enhanced management and security features to the MDM profiles

Lock MDM Profile – Again mentioned in the previous post, for Corporate owned, this would normally be enabled so that the secure profile cannot be removed by the end user.

Device Pairing – This is whether you want the end users in question to be able to connect the mobile device via ISB to a workstation to use things like iTunes. This is probably the only option here that’s worth giving any real amount of thought to disabling.

Setup Assistant

The ‘Hola’ welcome wizard that most iOS users see out of the box can be tailored in this section to streamline the start-up process. I’m not convinced these require much explanation as they are fairly self explanatory but most of these would be set to ‘skip’ to make the process fast for the end users. It is worth not skipping the Apple ID though as a valid ID will be required to download the MDM agent on enrolment from the Apple Store. Most of the other items can be managed via MDM profiles anyway.

DEP setup

Assigning profiles

Something very important not to miss in order to close this process off, is to actually assign the DEP profile to the devices. Going to the Device > Lifecycle > Enrollment Status page you can select one multiple or all devices. Then select to assign DEP profile as shown below.

DEP assign profile


This can be a bit of a pain if you have multiple DEP profiles to assign to different devices.

Device enrolment options and DEP (Device Enrolment Program) Pt.1

Quite a bit to get through in this post, ultimately what I want to discuss here is the Apple Device Enrollment Program (DEP) but this subject cannot be reached without first detailing the basic enrollment options in AirWatch, therefore I have made this a two part post which you could skip to if the lead up content is already understood.

End user agent based enrollment

This would be a scenario where the end user is either given an out of the box corporate device or chooses to use a BYOD. The steps a user would take would be something along the lines of:

  1. Download the AirWatch Agent by either going to their device’s public app store or navigating to
  2. Within the agent configuration they are prompted for their Server address (the public URL of the MDM Device Services Server) and the Group ID of where the device should be enrolled into with AirWatch.
  3. User then authenticates with either a predefined AirWatch basic account or a corporate domain account if configured.
  4. There’s then bunch of next, next finish prompts to accept various controls and the process is completed. Your device is enrolled.

AW Agent

Now the process detailed above is about the most manually intensive method possible and as you can see the user is required to tap and type several times and to also know or be told a few things about what they are doing. This process can though, be partially or pretty much fully automated as we will see.

The next step up from this handled in the user account setup process, where it is possible to send the user an email on account completion. This email can contain a QR code which has the server address and group ID embedded in it.

  1. The user selects QR code as the authentication method within the agent setup
  2. Holds the camera up to the screen.
  3. Next they will be promoted to authenticate with their credentials and have the next, next, finish to progress through again until it’s enrolled.

Pretty swish, but this method is relatively uncommon because of:

The final agent based enrollment method which is to use; email address.

  1. The user selects email address as the authentication method within the agent setup
  2. Types in email address and password
  3. Next, next, finish…..

This is probably the most common method as users will always know this info, it just requires a little more work on the back end to enable.

Pitfalls of agent based enrollment

Whichever way you look at it there is one common dependency on these three methods above and that is that they all require end user interaction. This means that things can go wrong as users may not know the information, understand what they are doing or just not bother enrolling at all because they can get away with not doing so. Another thing that can be done is to offload these tasks to an IT admin who can enrol as administrator then hand the device to a user. The biggest issue with agent based enrollment though is from a security aspect as devices can be simply un-enrolled and left in an unmanaged state.

For BYOD, agent based is the only way to go as users have every right to un-enrol their devices but for corporate devices, particularly on a medium or large scale two things are required; automation and security.

Corporate owned enrollment options

Apple Configurator

Apple Configurator is a kind of ‘offline’ MDM solution in its own right, as it can stage and apply configuration profiles to iOS devices. The trouble is, it is limited in that cannot work over the air (OTA) or as it must be physically plugged into the Mac OSX device running the configurator software. A USB hub can be used which can bank up to 30 iOS devices which can all be configured simultaneously making mass configuration and enrollment possible with Configurator. This works with AirWatch by having an (AirWatch) MDM profile imported into Configurator and into the banks of devices enrolling them en masse.

Supervision of Devices

Configurator enables ‘Supervision’ of Apple iOS devices which is a feature that enables greater security controls and configuration options. Although this is switched on via Configurator which is a tethered mechanism (in this instance at least), once enabled these additional features can be controlled OTA via the MDM solution of choice if it happens to support them. There are quite a few options that work with Supervised mode, but a few for reference would be to Allow App Removal, use of iMessage and erasing of content, but a more killer features would be things like Single App Mode which can be a very useful option for shared devices as it can lock the device to a single app. For corporate owned devices Supervision should be enabled wherever it’s practical to do so; if MDM is being applied to an existing fleet these will all need to be recalled so they can be physically plugged in to Apple Configurator, in the case of new devices being purchased however, the decision is more straightforward as these can have a supervised DEP profile assigned even before they come out of the box.

Device Enrollment Program (DEP)

First of all I want to point out that I am not comfortable with the use of the word ‘Program’ here which is what refers to a computer program. What we are talking about here is a ‘Programme’ which is more like a project or a system. Anyway, now I’ve proven my Britishness let’s talk about DEP at a high level.

Until last year there was the only option for mass enrollment and device supervision, and that was the Configurator and even that only arrived in 2013 with iOS 6. Then early last year a select few countries had access to DEP and towards the end of the year many more including the UK and may others too. DEP is a system provided by Apple which has been put in place purely to streamline corporate owned device enrolment into MDM solutions. The inner workings will be discussed in a follow up post but ultimately what it leaves the end user with is iOS version 7 or 8 device that can be taken fresh out of the box from a supplier and enrolled using a tailored version of the standard iOS start-up wizard, requiring no administrative involvement or use knowledge of the environment, other than their username and password (can be a basic account or domain).

One of the key benefits of DEP is a non-removable MDM profile can be deployed to the devices; even though both Configurator and DEP support supervision, only DEP supports this. Configuration profiles are not configured within the DEP portal this is all set within the MDM vendor console. We’ll take a look at this in part two of this post.

Samsung Knox and Android

Just for information its worth mentioning Samsung Knox which even though I am an Android Fan boy (FanDroid) it isn’t something that I have any experience of, but it is the only Android platform that supports mass enrollment in a similar way to that of DEP. This also includes Android for Work, the new Android MDM service provided by Google which aims to reduce fragmentation within the Android platform. So it is worth bearing in mind that features such as this are vendor specific on the Android Platform so we will need to wait for either Android for Work to develop or for other manufacturers to catch up.

That’s enough for part one which has been just an over of deployment options in the lead up to a more in depth discussion on DEP.

AirWatch EIS to ACC Migration

Just a short one this.

I recently came across a customer who required integration with an on-prem Certificate Authority so it could be integrated into a particular profile (maybe more on this another time). I noticed they were already using Directory integration for enrollment and assigning resources so I assumed an ACC would already be in place. I was wrong about this however as they were using the now legacy EIS component for this (I did find this out before I got there!).

A bit about EIS (Enterprise Integration Service)

According to the AirWatch EIS Guide:

The AirWatch Enterprise Integration Service (EIS) provides organizations the ability to securely integrate with back-end enterprise systems from either the AirWatch SaaS environment or a remote network zone (for example, a DMZ). This integration allows organizations to leverage the benefits of SaaS and their existing LDAP, CA, email, and other back-end systems.

Sounds just like the ACC (AirWatch Cloud Connector) huh? Well it does the same thing but the ACC is current, whereas  EIS is now considered legacy. EIS is a bit more of a painful to configure than ACC though as it really requires secure DMZ placement due to it needing inbound communication from the AirWatch Console Server. ACC on the other hand only requires an outbound web connection to the AirWatch Cloud Messaging Service so can quite happily sit on the internal LAN somewhere and go out directly or via a proxy if needed. Despite this, EIS is still in support however and oddly AirWatch are still (on version 8 for example) producing 33 page integration guides fot it which have no mention of the ACC.

EIS doesn’t support quite as many integration points as the ACC does, and for Certificate Services an additional and purchasable add-on pack is required.

Move to ACC

I didn’t want to get involved in any of this nonsense so I just replaced EIS with an ACC. If one was to navigate to the ACC node in the AirWatch console whilst EIS is enabled, this message would be seen:

12-05-2015 15-58-15

It’s not as daunting as it may first look, I had a new virtual server ready to run as an ACC so I went ahead and pressed the button, you then go through the ACC installation as normal.

The integration points (directory services in this case) that were previously using EIS remain just as before. These are independently configured nodes so will just carry on and the old EIS server will just be ignored and can be switched off. I then went ahead and implemented the Certificate Authority integration through the ACC so I could use it in my target device profile.

AirWatch Components

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.

The Components

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 (v8.0.1.0) 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.


AirWatch Component Guide



%d bloggers like this: