Pages

Monday, August 31, 2015

Deploying Carrier-Specific APN Settings using MobileIron

The first step is go into the policies and settings page in MobileIron. You'll need to login as an administrator and then go to the "Policies and Configs" tab and then into "Configurations";


Choose "Add New", then "iOS and OS X" and finally "APN". This will bring up the APN properties dialog to allow you to enter the APN details from the carrier;



We've added two APN's; one for Three and the other for Orange (both in the UK).

We primarily use AD groups to control who gets what but during a migration from one carrier to another this has not worked well. In the UK the switchover can happen anytime and the last thing you want is users to suddenly find themselves unable to access the network.

In order to fix this we've added some additional criteria to the label in MobileIron to ensure that users will only pickup the APN settings if they are on the right network.

The existing label criteria was;
"user.ldap.groups.name" =  "MobileIron_UK_APN"
We would simply put the user in the AD group they would pickup the APN information from our active provider.

This was changed to;
"user.ldap.groups.name" =  "MobileIron_UK_APN"  AND
"common.home_operator_name" =  "Three" AND "common.home_country_name" =  "United Kingdom"
In this way when users swap their sims and are migrated from the label should trigger the removal of the old APN even if the user is in the AD group which should be deploying it.

Similarly we create a another group to work in the other direction - to only apply the new APN for Orange if the user is in the right group AND on the Orange network (in the UK).

This actually had the happy side effect that users who were on Vodafone, O2, or any of the other virtual operators didn't pick up the APN if they'd be left in the group accidentally (or had two devices, one company the other private).

In this way we ensure disruption to the users (not to mention calls to ServiceDesk!) are minimised.

Thursday, August 27, 2015

Outlook 2016 (for Mac) Email Formatting/ Image Display Issue

I've been working today on an interesting issue with email formatting when you send HTML emails between the Mac and PC versions of Outlook. The issue only seems to occur one way - from Outlook 2016 on a Mac to Outlook 2013 on a Windows machine. In addition to font issues it also seems to be doing something "weird" with a PNG image I've embedded as a test.

So here's the problem. On the left is the test signature in Outlook 2016 (Mac) and on the right is the signature as it appears when it arrives in Outlook 2013 (PC);


As you can see the image shows that when the email arrives in Outlook 2013 the colour of the image changes (although if you save the file and open it in preview it is actually still the same colour - it's the way it's rendered that's different, not the image itself).

Clicking "reply" (which lets you see the font information being used) shows that while the email signature was build using the font Calibri (which is installed on both devices) it's being rendered in Outlook using "Times New Roman".

From what I can see (i.e. "thank you google") it looks like Outlook 2016 isn't including font information in the email so Outlook 2013 is reverting to it's standard font. The problem seems to persist if rather than using Outlook 2013 on a PC you use the mail client on an iPhone - this suggests Outlook 2016 is doing some odd rather than 2013 just not displaying it correctly.

What's going on with the image is a mystery! Which slightly deepens if you copy/ paste your email signature into Mail on the Mac. You still get the image problem, but not the font problem. However if you save the image to disk from the Outlook signature, open in preview, and then copy/paste into the email signature in Mail from there you don't get the same issue. Again the light image is also visible on an iPhone which suggests it's the information in the email message being rendered that is causing the issue.


Neither issue occurs if you use Apple Mail on a Mac, it's something specifically done by the latest version of Outlook.

Should I work out how to address this I'll make another post, just thought this was odd enough to justify a specific post ...