vEffort

Physical efforts in virtualization and mobility

VMware Access Point 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 Access Point 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. Access Point 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.

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 Access Point 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 Access Point, 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 11.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 http://mesu.apple.com (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 applednld.apple.com via a proxy server (although I think it should be appldnld.apple.com – 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.

Preparation

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 https://deploy.apple.com – 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:

Authentication

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 awagent.com.
  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.

Licencing

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

 

 

Load Balancing Exchange 2010 with NetScaler: No SSL Offload

Now true to form this isn’t a how to on “Load Balancing Exchange 2010 with NetScaler”; there are plenty of blogs on that, some of the best ones I’ve come across are below:

For the process end to end, these are very good:

http://www.cb-net.co.uk/citrix-articles/2013-netscaler-load-balancing-exchange-2010

http://benddiscount.com/2015/01/15/exchange-2010-load-balancing-with-netscaler-10-1

Two from Dave Stork:

For handling rewrite which basically means appending ‘/owa’ to the end of a blank URL:

https://dirteam.com/dave/2012/12/24/simplifying-the-owa-url-with-citrix-netscaler

and another detailing content switching:

https://dirteam.com/dave/2012/12/21/loadbalancing-exchange-2010-with-citrix-netscaler-using-content-switching

Actually the best one I have found, particularity for content switching is this one, which has a smart single expression covering OWA, RPC and OAB. It also has a summary of some useful tips at the end:

http://blog.decepticlone.com/2013/10/load-balancing-exchange-2010-on.html

I do a fair amount of NetScaler work normally due to XenApp or XenDesktop and a requirement to include remote access within the solution. On the odd occasion I am called upon to do pure load balancing assignments however. Most of them are pretty straightforward including Exchange if you have a lot of IP addresses at your disposal. When you don’t you will need to get your head around content switching. One of the above blogs will help you there.

SSL Offload – Quick how to

Now to the point, Content Switching to one side, most blogs and guides you will come across will blindly advise the same course of action to achieve load balancing of Exchange. In summary:

  1. Create the targets to be load balanced
  2. Assign them to either an HTTP based Service Group or Service (which, is a personal preference but I always prefer flexibility from Service Groups).
  3. Assign the Service Groups to an SSL based vServer with a commercial public SSL certificate assigned
  4. Modify the IIS virtual directories on the Exchange Servers to Not Require SSL and set Client Certificates to ‘Accept’
  5. Ensure authentication is set correctly in the IIS virtual directories or the Exchange console.
  6. In HKLM\system\CurrentControlSet\Services\MSExchange OWA Create a DWORD SSLOffloaded = 1

Collectively these steps enable SSL offload on the NetScaler; that is the CPU intensive decryption process is moved away from the Exchange servers onto the NetScaler appliances. This is a particularly good thing if you have physical MPX NetScalers as they have dedicated SSL offload cards built into them, ultimately the Exchange servers will have improved efficiency. For a VPX it’s probably marginally better than having your Exchange servers carrying out this task but it will increase CPU utilisation on the associated hypervisor host(s).

So although I’m quite comfortable with NetScalers, Exchange is not my thing, so I’m not really happy about blindly making these changes to a production Exchange servers which have thousands of internal users on-board. After-all in many cases you may only have a maybe fifty or a few hundred concurrent external users to cater for, but with thousands of internal users using these CAS servers, there could be adverse affects.

The needs of the many outweigh the needs of the few

Consider the following:

  • Remote access for Exchange services is only likely to be used for ~100 concurrent users, meaning SSL transaction load will be low
  • These SSL transactions are going to be spread across a number of CAS servers
  • Modification of the IIS settings could adversely affect internal users of OWA (I’ve seen this happen)
  • Removing the requirement for SSL would mean some internal Exchange related traffic will be sent in plain text

Going against the grain

I decided I didn’t like the smell of the above scenario so I thought what’s wrong with using an SSL only Service Group assigned to my SSL vServer? To me it sounded like SSL bridge was the ticket, this will just proxy the connection through carrying out no decryption. There are two issues with this:

  1. The Exchange CAS servers will require the public SSL certificate (more changes to the Exchange infrastructure that I don’t want to make)
  2. SSL Bridge is a very limited option, it removes the possibility of carrying out move ‘advanced’ features such as Content Switching and Rewrites on the NetScaler.

So the only remaining course of action is to use standard SSL service groups and vServers with no SSL offload, and do you know what? It works. OWA, ActiveSync, RPC over HTTP etc, all work just fine; there is no need to to make any changes to your Exchange servers that you may not fully understand (like me) at all. Sure you have no SSL offload but consider how many users you will be presenting this solution to, and the capability of your CAS servers.

What actually occurs in the scenario is:

  1. The vServer accepts SSL traffic
  2. Traffic is then decrypted within the NetScaler
  3. As traffic leaves the Netscaler on it’s way to the Exchange servers, it is re-encrypted
  4. The public SSL certificate is only required on the NetScaler, specifically the Load Balancing vServer and Service Group and the Content Switching vServer

Backing Up and Restoring User Profiles

Hot on the heels of my previous post, I was in a situation where I wanted a safety-net for backing up user profiles. “To the web! >>”  I found this which got me on the right path:

http://community.spiceworks.com/scripts/show/1575-user-profile-backup-and-restore

I didn’t want to use PowerShell (well I did but we had XP to deal with) so was pretty limited to batch. In the end I took the contents of the script in this article and spiced it up a bit:

  • Took the backup part and used it as a logon script which pushed the necessary content to a folder on the users home drive
  • Copied the restore batch file to the same users home drive folder
  • Updated the hard paths to use built in system variables
  • Updated locations to account for different Office versions from 2003 to 2013
  • Commented each section to describe what each line is doing
  • Used a check to see if Robocopy is present locally as it is not by default on XP.
    • If it is, assume the machine is Windows 7 or Vista and skip to that section that uses the %localappdata% variable
    • If it isn’t, assume the machine is XP which will temporarily map a drive to use robocopy on a remote location. Also uses the %userprofile%\Local Settings\Application Data path in the absence of %localappdata%
  • Added a logging option which gives a date and time of user logins and what machines they are logging onto.

The backup script is below:

:: For XP Machines that will not have Robocopy available locally and also no %localappdata% variable
if not exist %systemroot%\system32\robocopy.exe (
 net use v: \\domain.local\NETLOGON
 ::Backup Outlook signature files
 v:\robocopy.exe %appdata%\Microsoft\Signatures %homeshare%\ProfileBackup\Signatures *.* /e
 ::Backup NK2 cache for Outlook 2003/2007
 v:\robocopy.exe %appdata%\Microsoft\Outlook %homeshare%\ProfileBackup\NK2 *.nk2
 ::Backup NK2 cache for Outlook 2010/2013
 v:\robocopy.exe &quot;%userprofile%\Local Settings\Application Data\Microsoft\Outlook\RoamCache&quot; %homeshare%\ProfileBackup\Local *.dat
 ::Backup Internet Explorer Favorites
 v:\robocopy.exe %userprofile%\Favorites %homeshare%\ProfileBackup\Favorites *.* /e
 ::Backup all template files in AppData including normal.dot
 v:\robocopy.exe %appdata%\Microsoft\Templates %homeshare%\ProfileBackup\Templates\*.dot
 ::Backup customised Quick Access Toolbars in Office
 v:\robocopy.exe &quot;%userprofile%\Local Settings\Application Data\Microsoft\Office&quot; %homeshare%\ProfileBackup\Local *.Officeui
 ::Backup Office auto correct files
 v:\robocopy.exe %appdata%\Microsoft\Office %homeshare%\ProfileBackup\Roaming *.acl
 ::Backup custom dictionaries for Office
 v:\robocopy.exe %appdata%\Microsoft\Uproof %homeshare%\ProfileBackup\Roaming *.dic
 net use v: /delete
)

:: carrying on it Vista or Win7 backup the profile data to the users home drive
if exist %systemroot%\system32\robocopy.exe (
 ::Backup Outlook signature files
 Robocopy %appdata%\Microsoft\Signatures %homeshare%\ProfileBackup\Signatures *.* /e
 ::Backup NK2 cache for Outlook 2003/2007
 Robocopy %appdata%\Microsoft\Outlook %homeshare%\ProfileBackup\NK2 *.nk2
 ::Backup NK2 cache for Outlook 2010/2013
 Robocopy %localappdata%\Microsoft\Outlook\RoamCache %homeshare%\ProfileBackup\Local *.dat
 ::Backup Internet Explorer favorites
 Robocopy %userprofile%\Favorites %homeshare%\ProfileBackup\Favorites *.* /e
 ::Backup all template files in AppData including normal.dot
 Robocopy %appdata%\Microsoft\Templates %homeshare%\ProfileBackup\Templates\ *.dot
 ::Backup customised Quick Access Toolbars in Office
 Robocopy %localappdata%\Microsoft\Office %homeshare%\ProfileBackup\Local *.Officeui
 ::Backup Office autocorrect files
 Robocopy %appdata%\Microsoft\Office %homeshare%\ProfileBackup\Roaming *.acl
 ::Backup custom dictionaries for Office
 Robocopy %appdata%\Microsoft\Uproof %homeshare%\ProfileBackup\Roaming *.dic
)

:: copy the restore script to the users home drive so they can run a restore if required
copy &quot;\\domain.local\NETLOGON\RestoreProf.bat&quot; %homeshare%\ProfileBackup\ /y

:: output the logging on users to text file for reference to see what desktops they are logging on
echo %username%,%computername%,%date%,%time% &gt;&gt; \\domain.local\dfs\profiles\LiveLogonInfo.txt
Next create a RestoreProf.bat like this
@Echo off

:: Set log files variable, each line appends to the respective log file
SET LOGW7VISTA=%homeshare%\ProfileBackup\ProfileRestoreW7Vista.log
SET LOGXP=%homeshare%\ProfileBackup\ProfileRestoreXP.log

:: For XP Machines that will not have Robocopy available locally and also no %localappdata% variable
if not exist %systemroot%\system32\robocopy.exe (
 net use v: \\domain.local\NETLOGON &gt;NUL
 ::Restore Outlook signature files
 v:\robocopy.exe %homeshare%\ProfileBackup\signatures %appdata%\Microsoft\Signatures *.* /e /NC /NS /NP &gt;&gt; %LOGXP%
 ::Restore NK2 cache for Outlook 2003/2007
 v:\robocopy.exe %homeshare%\ProfileBackup\NK2 %appdata%\Microsoft\Outlook *.* /e /NC /NS /NP &gt;&gt; %LOGXP%
 ::Restore NK2 cache for Outlook 2010/2013
 v:\robocopy.exe %homeshare%\ProfileBackup\Local &quot;%userprofile%\Local Settings\Application Data\Microsoft\Outlook\RoamCache&quot; *.*
 ::Restore Internet Explorer Favorites
 v:\robocopy.exe %homeshare%\ProfileBackup\Favorites %userprofile%\Favorites *.* /e
 ::Restore all Template files in AppData including normal.dot
 v:\robocopy.exe %homeshare%\ProfileBackup\Templates %appdata%\Microsoft\Templates *.* /e /NC /NS /NP &gt;&gt; %LOGXP%
 ::Restore customised Quick Access Toolbars in Office
 v:\robocopy.exe %homeshare%\ProfileBackup\Local &quot;%userprofile%\Local Settings\Application Data\Microsoft\Office&quot; *.Officeui /e /NC /NS /NP &gt;&gt; %LOGXP%
 ::Restore Office autocorrect files
 v:\robocopy.exe %homeshare%\ProfileBackup\Roaming %appdata%\Microsoft\Office *.acl /e /NC /NS /NP &gt;&gt; %LOGXP%
 ::Restore custom dictionaries for Office
 v:\robocopy.exe %homeshare%\ProfileBackup\Roaming %appdata%\Microsoft\Uproof *.dic /e /NC /NS /NP &gt;&gt; %LOGXP%
 net use v: /delete &gt;NUL
)

:: carrying on if Vista or Win7 restore the profile data to the users local profile for upload at logoff
if exist %systemroot%\system32\robocopy.exe (
 ::Restore Outlook signature files
 Robocopy %homeshare%\ProfileBackup\Signatures %appdata%\Microsoft\Signatures *.* /e /NC /NS /NP &gt;&gt; %LOGW7VISTA%
 ::Restore NK2 cache for Outlook 2003/2007
 Robocopy %homeshare%\ProfileBackup\NK2 %appdata%\Microsoft\Outlook *.* /e /NC /NS /NP &gt;&gt; %LOGW7VISTA%
 ::Restore NK2 cache for Outlook 2010/2013
 Robocopy %homeshare%\ProfileBackup\Local %localappdata%\Microsoft\Outlook\RoamCache *.* /e /NC /NS /NP &gt;&gt; %LOGW7VISTA%
 ::Restore Internet Explorer Favorites
 Robocopy %homeshare%\ProfileBackup\Favorites %userprofile%\Favorites *.* /e
 ::Restore all Template files in AppData including normal.dot
 Robocopy %homeshare%\ProfileBackup\Templates %appdata%\Microsoft\Templates *.* /e /NC /NS /NP &gt;&gt; %LOGW7VISTA%
 ::Restore customised Quick Access Toolbars in Office
 Robocopy %homeshare%\ProfileBackup\Local %localappdata%\Microsoft\Office *.Officeui /e /NC /NS /NP &gt;&gt; %LOGW7VISTA%
 ::Restore Office autocorrect files
 Robocopy %homeshare%\ProfileBackup\Roaming %appdata%\Microsoft\Office *.acl /e /NC /NS /NP &gt;&gt; %LOGW7VISTA%
 ::Restore custom dictionaries for Office
 Robocopy %homeshare%\ProfileBackup\Roaming %appdata%\Microsoft\Uproof *.dic /e /NC /NS /NP &gt;&gt; %LOGW7VISTA%
)

@Echo profile settings restored
Pause

This will be copied to the users home drives from the logon script (so long as you put it in the right place) and will create a folder structure like this

Folderlook

Restoring files

So the idea here is that if there is an issue, the user can manually run the batch file, which may be a problem if you restrict the running of these file types. I see this as a useful tool though to be used as a matter of course. If everyone’s profiles are backup in such a way and you have a service desk with a penchant for flushing user profiles this will make the process easier because if the login script runs at every logon, the folder will always be up-to-date. After a profile flush the service desk can either insruct the user to run the file or they can run it as admin to drop all of the files in the correct place.

I have only found one slight issue with the restore method so far in that the signature file is somewhat orphaned. It’s there in Outlook, it just needs assigning as per screenshot below:

Sig

%d bloggers like this: