As a person who uses mobile phones strictly as a phone and always prefers to perform other tasks on an actual PC, I do not pay much attention to all the ‘revolutionary’ applications, devices or even news on the subject. Still, we live in the BYOD era and lots of people appreciate the mobility they get with their smartphones, tablets, etc.
Exchange ActiveSync offers some security features, but its main function is to make email/calendar available to the users on the go. If you are looking for a complete MDM solution, Windows Intune or System Center Configuration Manager are your best bets. What this post will cover are some aspects of ActiveSync, so if you are interested in MDM as a whole, you can stop reading now 🙂
For the basics of ActiveSync, I recommend this very detailed two-part blog post by Nuno Mota at MSExchange.org.
If you need help with configuring a particular mobile device with Exchange Online, you can refer to the Mobile Phone Setup Wizard. Troubleshooting issues with ActiveSync is covered by the Exchange ActiveSync Guided Walkthrough and tons of TechNet and KB articles (this or this for example). Due to the fact that most device manufacturers decide to put their own touch on the ActiveSync specifications, the list of Current issues with Microsoft Exchange ActiveSync and third-party devices is ever-growing. It’s a good thing that we now have native OWA for iPhone and OWA for iPad applications, which save us (the admins) from having to deal with the device vendor.
And of course I wouldn’t be true to myself if I didn’t describe some business case and it’s solution, so here we go. Let’s say you are planning on rolling out an upgrade for the mobile devices for some of your users. As a result, you have several hundred devices that need to be activated in a short period of time. In a perfect world, you would’ve been provided with a list of all the users that need new device provisioned, along with the actual device IDs.
This of course is rarely the case, so instead you are left with just the user list and you need to make sure the process goes as smooth as possible. Changing the default organizational policy to allow all devices is never a good idea, so it’s out of the question. What might come in handy instead is creating a device access rule for that particular device model. This again comes with a certain amount of risk – every user having the said device model will be able to connect, so keeping the rule active for a long period of time is a bad idea. And there is also a catch – the moment you switch the device access rule off, all devices that are not handled by personal/rule exceptions will be affected by the default policy. In most cases this means blocked/quarantined devices.
If you have read Nuno’s blog post above, you would have no problem understanding this. Here’s the relevant passage:
Each time Exchange receives an EAS request from a mobile device, it has to determine which level of access the device should be given. To determine this, Exchange follows a pre-determined sequence of challenges:
-
Is the mobile device authenticated? If not, prompt the user for credentials. If yes, go to step 2;
-
Is EAS enabled for the current user? If not, return an “access restricted” error. If yes, go to step 3;
-
Is the EAS mailbox policy criteria met by the mobile device? If not, block access. If yes, go to step 4;
-
Is the mobile device blocked by a personal exemption for the user? If yes, block access. If not, go to step 5;
-
Is this mobile device allowed by a personal exemption for the user? If yes, grant access. If not, go to step 6;
-
Is this mobile device blocked by a device access rule? If yes, block access. If not, go to step 7;
-
Is this mobile device quarantined by a device access rule? If yes, quarantine the device. If not, go to step 8;
-
Is this mobile device allowed by a device access rule? If yes, grant access. If not, go to step 9;
-
Apply the default access state according to the EAS organizational settings, which will allow, block or quarantine the device.
So, to make sure that devices remain activated after removing the device access rule, simple add the corresponding deviceID to the list of allowed devices for that user. You can do this by pressing the corresponding button in EAC, either in the Quarantined devices section of the Mobile tab, or in the Mailbox Features section of the user mailbox settings dialog. Or, of course, use PowerShell to perform this in bulk.
Start by getting the list of all devices of this particular model. If the device access rule is in place, all of them should be in “Allowed” state, unless criteria 1, 2 or 3 above are not met (in which case you will have to perform manual steps regardless). Here’s the relevant PowerShell cmdlet:
$iphone5s = Get-MobileDevice -ResultSize Unlimited -Filter {DeviceAccessState -eq "allowed" -and DeviceModel -eq "iPhone6C2"}
As a side note, the DeviceAccessStateReason parameter is not reliable in this case, as it returns either “Policy” or “DeviceRule”. You can also use the DeviceAccessControlRule parameter as a base for the filter, but it corresponds to the actual DeviceModel, so it’s basically the same.
Anyway, once you have the list of devices, you can easily get the corresponding deviceIDs and the only thing left to do is getting the corresponding mailbox. This information is contained in the Identity parameter and depending on your naming policy, it might be as easy as truncating the Identity string till the first slash character. For reporting purposes, I prefer to use the primarySmtpAddress instead, and here is how to get it:
$list = $iphone5s | select FriendlyName,DeviceId,devicea*,@{n="email";e={(Get-Mailbox -Identity $_.identity.Split("")[0]).primarysmtpaddress}}
Once you have both the DeviceId and the Identity/primarySMTPaddress, adding the corresponding device to the list of allowed ones is easy:
$list | % { Set-CASMailbox -Identity $_.email -ActiveSyncAllowedDeviceIDs @{Add=$_.deviceid}}
If you need to repeat the process again, it’s a good idea to skip all the already added devices, you can achieve this by using the following filter instead:
$iphone5s = Get-MobileDevice -ResultSize Unlimited -Filter {DeviceAccessState -eq "allowed" -and DeviceModel -eq "iPhone6C2" -and DeviceAccessStateReason -ne "Individual" }
Hope this helps 🙂