During the recent issues with iOS 6.1 causing excessive transaction logging on Exchange servers many administrators took steps to block iOS 6.1 devices from their servers using ActiveSync device access rules.
But when Apple released iOS 6.1.2 (which may or may not actually fix the problem) they noticed that upgraded devices weren’t being automatically allowed to connect to Exchange again.
To demonstrate this I put an iOS 6.1 block rule on my test server, connected at least once to confirm my device was being blocked, and then updated the device to iOS 6.1.2.
After running the update the device still can’t connect to Exchange. A look at the device state still shows that it is blocked by the rule put in place for iOS 6.1, even though I upgraded to 6.1.2.
[PS] C:\>Get-ActiveSyncDeviceStatistics -Mailbox alan.reid | select device* DeviceType : iPhone DeviceID : ApplC39GQ8NNDTDL DeviceUserAgent : Apple-iPhone4C1/1002.142 DeviceModel : iPhone4C1 DeviceFriendlyName : Black iPhone 4S DeviceOS : iOS 6.1 10B142 DeviceAccessState : Blocked DeviceAccessStateReason : DeviceRule DeviceAccessControlRule : iOS 6.1 10B142 (DeviceOS) DevicePolicyApplied : Default DevicePolicyApplicationStatus : AppliedInFull DeviceActiveSyncVersion : 14.1
I don’t want to remove the device access rule because the bug still exists in iOS 6.1 and other devices might still be running that version and try to connect to the server again.
So what can I do to let the updated device gain access to the server again?
One option is to remove the device from Exchange entirely. This causes it to be assessed as a new device the next time it connects, and in this scenario would be allowed to connect.
However at a large scale this may be impractical and cause a lot of administrative effort.
Another option is to use a device access rule that quarantines devices instead of blocking them. For example, here is a device access rule that quarantines the iPad 3 running iOS 6.1.
New-ActiveSyncDeviceAccessRule -QueryString "iOS 6.1 10B141" -Characteristic DeviceOS -AccessLevel Quarantine
When the device attempts to connect it is put in the quarantine state instead of being blocked.
[PS] C:\>Get-ActiveSyncDeviceStatistics -Mailbox mary.hayes | select device* DeviceType : iPad DeviceID : ApplDLXH8DELDVGJ DeviceUserAgent : Apple-iPad3C3/1002.141 DeviceModel : iPad3C3 DeviceFriendlyName : Black iPad DeviceOS : iOS 6.1 10B141 DeviceOSLanguage : en-GB DeviceAccessState : Quarantined DeviceAccessStateReason : DeviceRule DeviceAccessControlRule : iOS 6.1 10B141 (DeviceOS) DevicePolicyApplied : Default DevicePolicyApplicationStatus : AppliedInFull DeviceActiveSyncVersion : 14.1
After updating the device to iOS 6.1.2 it is allowed to connect again with no administrative action required.
[PS] C:\>Get-ActiveSyncDeviceStatistics -Mailbox mary.hayes | select device* DeviceType : iPad DeviceID : ApplDLXH8DELDVGJ DeviceUserAgent : Apple-iPad3C3/1002.146 DeviceModel : iPad3C3 DeviceFriendlyName : Black iPad DeviceOS : iOS 6.1.2 10B146 DeviceOSLanguage : en-GB DeviceAccessState : Allowed DeviceAccessStateReason : Global DeviceAccessControlRule : DevicePolicyApplied : Default DevicePolicyApplicationStatus : AppliedInFull DeviceActiveSyncVersion : 14.1
So which is the smarter approach?
- Blocking devices gives the administrator the most control over when the devices are allowed to connect to the server again. In the case of iOS 6.1 multiple updates have since been released that do not solve the very serious problem of excessive transaction logging, therefore the continued blocking of the device is a good thing. However when the bug is fixed the administrators will have to spend more time unblocking devices, which is possibly a costly exercise in very large scale environments.
- Quarantining devices is the least administrative effort, because an updated device will automatically be allowed to reconnect when it updates to a version that has no block/quarantine rule configured on the server. However the risk exists that an administrator will process a quarantine request and allow a device running one of the bad iOS versions to begin connecting to the server again.
As you can see neither approach is entirely perfect but fortunately administrators have some choice and flexibility in how they deal with this issue.