As a system administrator of a small organization, I was extremely skeptical towards the BYOD (Bring Your Own Device) revolution when it first gained steam a couple of years ago. We had tried allowing employees to access company email on their personal Blackberries and wrestled with issues involving data plans, carrier support and individual settings which made it a tangled mess. Wrestling data off an employee-owned device when they left the company (or were terminated) was especially unpleasant.

In order to address the problem we started ordering company-owned Blackberries via a single carrier and then supported those corporate devices for our staff. The phones were predictable, standardized, and contained very few surprises. Sure, the plans were expensive, the devices contained some features people didn’t need, we had to maintain the Blackberry server environment, and people always wanted to port phone numbers on and off the company phones, but it seemed like the devil we knew then was better than the devil we had known before.

Perfect storm

Three factors converged into a perfect storm that pushed BYOD ahead of it: Blackberry went into decline, cost savings became a priority, and the blend between home and work life (or consumer and corporate life if you prefer) became even more pronounced. Once people started appearing with Androids and iPhones, asking if they might get their company email/calendars/contacts on these devices, we knew we had to evolve or become extinct.

One thing we had going for us: the devices and carriers had evolved to become more reliable and innovative, as well as administrator-friendly. We decide to leverage our new Exchange 2010 environment, which permits ActiveSync access on ports 80/443 (http/https) to our Client Access Server via a public URL (e.g. in order to permit BYOD.

And so we implemented a simple BYOD program:

  1. The ActiveSync protocol was enabled in our Exchange 2010 system for all users, so that we could skip having to turn it on/off on an individual basis (you may have heard that ActiveSync will no longer be available to synchronize email, calendars and contacts for Google Mail users; this does not apply to Exchange servers).
  2. We implemented a security policy for all devices which requires a password (this has proven its value dozens of times with lost and misplaced phones). Nothing too onerous as you can see in Figure A.

Figure A

3) We implemented a quarantine policy whereby the IT department would have to authorize any and all new devices. This involved using an Exchange PowerShell script to configure the access level and notify the user/appropriate personnel that the device was in quarantine state awaiting authorization in order to work.

4) The “device quarantined” notification email which users received would contain terms they had to agree with for their devices to be authorized (this is done using the Exchange Control Panel as outlined here). These terms stated they had to accept our security controls and that we can erase the device/terminate the device’s connection to our systems at any time.

The terms are meant to protect the organization as well as the user; lost phones are immediately erased – once the user has reported it – in order to ensure any confidential data on these devices does not fall into the wrong hands (this safeguard also ensures the employee remains employed). Most of our users were happy to comply with the terms, though a few declined, grumbling words to the effect that they didn’t intend to lose their kids pictures if the guys in IT wiped their phones (apparently out of sheer boredom). I’ve learned after years in IT – and as a parent – that not even Santa Claus can please all of the people all of the time.

So, in summary, a user adds the company email account to their phone, they receive an email which they must reply to from their desktop client signifying they agree with the terms, then we log into the Exchange Control Panel and find their device waiting there to be authorized. (Figure B)

Figure B

We click “Allow’ and then the phone starts processing mail (and calendar/contacts/tasks/notes if configured).

Since we’ve gone BYOD the company has saved money, the users have enjoyed greater convenience and flexibility with their choice of phones, and we’ve also managed to protect our second-greatest asset: data (the first being the people of course).

But – (there’s always a “but” somewhere, right? After all, this article wouldn’t exist if not for the “but”) – BYOD has led to some difficult support scenarios due to the range of phones which can now connect to our email environment. It was decidedly easier with a mix of three to four Blackberry models, all of which had the same menus, the same functions and the same operating system levels.

Exchange 2010

As I mentioned in a prior article on iPhone vs. Android, “it’s been my experience as an Exchange 2010 administrator that the phones which have had connectivity troubles have invariably been Android – usually models with a new OS. Conversely, I’ve seen numerous occasions whereby an iPhone user’s Active Directory password has changed but the iPhone won’t recognize the new password until it is powered off/back on.”

Android’s strength is the number of different models and operating systems it offers. This also adds to the complexity of supporting these phones. At present we have over 90 Androids running successfully in our Exchange email environment, with varying models from Samsung, Motorola, HTC and others. Our BYOD environment is definitely easier to handle than when we permitted employee-owned Blackberries. Problems nevertheless can and do erupt with Android and ActiveSync.

What sort of problems? They can vary. Maybe a new email account can’t be added to the phone due to credential errors, email fails to synchronize once the account is added, or someone has received the dreaded “Your mobile phone has been denied access to the server via Exchange ActiveSync because of server policies.” Here are some procedures to help surmount these frustrations. Note the Active Directory/Exchange 2010 steps assume a working administrative knowledge of these environments.

Plan Ahead

If you’re in IT, I can bet users thinking about buying Android phones will probably ask for your input on the choice(s) they have in mind. It pays to be prepared: research the phone for any known ActiveSync issues. Here is a great list of known issues with ActiveSync on Android devices (PDF).

The counterpart to this concept is finding out which Android devices and operating systems are known to work successfully via ActiveSync, and to publish this list to your users to help keep them informed.

Stick with the basics

Shakespeare’s “Hamlet” states that “When sorrows come, they come not single spies, but in battalions.”

The first report of any problem involving email should lead you to verify that email is in fact working for other devices/clients. Nothing is worse than diving into a problem under the assumption that it only impacts a single user only to find it’s really an organizational-wide outage a half hour later (once you finally check your voicemail to find seventeen messages asking “Is there a problem with email?”).

Once you’ve determined it’s just an individual problem, try the following:

  • Ensure the device has the appropriate network connectivity, their Active Directory account is not locked, the password is correct, the password has not expired.
  • Check the health of the AD account. On one recent issue, a user couldn’t sync mail on his Android phone, and it seemed to be caused by a weird problem with his AD account/mailbox. The Exchange Management Console told me his mailbox didn’t exist; I went into his AD properties to make a minor changed and saved it, and then somehow the account operated normally a few minutes later – and so did the Android. This may have been a replication issue.
  • Use to rule out any issues with the ID or the environment in case the issue isn’t with the mobile.
  • Remove the account on the phone and re-create it to see if it will synchronize mail. Be on the lookout for any security messages or prompts that might be hidden which you need to accept.
  • Try using your domain\username rather than just your username when setting up the ID on the account. For instance\username. Try NOT using this format if it still fails.
  • Make sure to select any option to use SSL in the account settings if your Exchange 2010 server requires it.
  • If connecting to the Exchange server internally, use the server name rather than the web URL in the account settings.
  • See if a recent update to the phone OS has provoked the problem. You might need to have the user remove the update, or – if all else fails – downgrade the OS. It’s not a pretty solution but it may just do the job if getting company email is more important.

Know how it’s supposed to work

You can’t troubleshoot something if you don’t know how it’s supposed to work. Make sure you understand the Exchange 2010 Client Access and Mailbox server environment, the firewall rules involved, any ActiveSync policies you have in place, and how to confirm that a user/device has been authorized for ActiveSync access.

Understanding Mobile Device Management in Exchange 2010 is a useful Microsoft TechNet article which provides a checklist you can run through to ensure everything is set up properly and find areas on which to pinpoint your Android troubleshooting. (Figure C)

Figure C

Ensure your environment is up to date

Keep your servers fully patched; for instance a synchronization failed error can be fixed by Update Rollup 3 for Exchange 2010 Service Pack 1. Now, I wouldn’t go so far as to install the latest network and video drivers on your Exchange servers (unless you’re really bored) but it’s definitely a priority to ensure the Exchange components are as recent as possible.

Troubleshoot any policies applied to the device

Your ActiveSync policy may be the source of the issue. Try setting up a separate policy for the user and turn off the password requirement (if applicable). There is a checkbox on the “General” tab of the policy to “Allow non-provisionable devices.” (Figure D)

Figure D

Try turning this option on to troubleshoot. Of course, you don’t want to create exceptions for users (especially not when it comes to avoiding password requirements) but this can help you pinpoint what’s happening.

Another policy consideration involves options on how far back to synchronize calendar and email data. (Figure E)

Figure E

On one occasion I came across an Android which couldn’t sync ANY calendar items because we had the “Include past calendar items” option set to 30 days. We changed this to “All” and it resolved the problem.

Use Exchange tools

The Exchange Control Panel will let you manage user phone settings (obviously you have to have the appropriate access rights in Exchange). Log in and click “Manage My Organization,” then select “Another User” as shown in Figure F.

Figure F

This will open a “Select Mailbox” window. Let’s say I want to check the phone settings and status for Kyle, one of my users. I’ll enter his full name then double-click the resulting entry to open the Options window for his account. (Figure G)

Figure G

I can click Phone to show the phone details. (Figure H)

Figure H

Kyle has three phones associated with his account, and all of them are showing “OK” for the status. If the problem Android you are troubleshooting is not listed, there may be a problem with network access on the device or it can’t communicate with the server/URL.

I can double-click any of the devices shown here to get more information. For example, double-clicking the “Android” entry shows me Figure I.

Figure I

In this case, the “Access state” shows the problem – Access has been denied, probably due to our quarantine policy (see the next section for instructions on how to allow a phone). Frankly, that contradicts that “Status OK” field shown two screenshots above.

Let’s say the issue is with the “htcace” phone. Viewing the details for the phone shows me Figure J.

Figure J

As you can see, our “Test Policy” is applied in full to the user. Access has been granted. This device was working, but has not synchronized in a while. It may be that it does not have the appropriate connectivity or user credentials. You can check the device OS, the mobile network (if applicable), and other relevant details to gain more insight into what’s going on if it isn’t immediately obvious.

Back at the Phone Details screen, I can click “Start Logging” after highlighting the desired device (notify the user before you do this so they’ll know to expect an email as a result). This will bring up a box like Figure K.

Figure K

Click Yes, then get the user to try to connect. Once the attempt has failed, return to the Mobile Phones screen as shown in Figure L.

Figure L

Click “Retrieve Log.” The text-based log file will be emailed to the user; have them forward it to you for review. (Figure M)

Figure M

The above shows a snippet from a log file showing successful operation. You can look for and research any issues found as needed.

Unfortunately, in the case of Microsoft administration, there are multiple avenues to go down to administer or configure users/options/settings. Just as Yoda said “There is another Skywalker,” there is another way to get information about a user’s phone which can help you. Return to the main Exchange Control Panel as shown in Figure N.

Figure N

Click “Users & Groups” then find and double-click the user in question. Details about their account will appear, similar to Figure O.

Figure O

Expand “Phone & Voice Features.” (Figure P)

Figure P

You can confirm here that Exchange ActiveSync is enabled. Click Edit. (Figure Q)

Figure Q

Aha! The Android on the top line is showing “Access Denied”. To resolve the connectivity problem I can click “Allow.” I could also delete it using the black “X” if it is no longer needed.

You can run a cool Exchange PowerShell script which will generate an ActiveSync report showing the status of all devices in your organization to get more information:

$devices = @()
$mailboxes = Get-CASMailbox -ResultSize:Unlimited | Where-Object {$_.HasActiveSyncDevicePartnership -eq $true -and $_.ExchangeVersion.ExchangeBuild -ilike "14*"}
 foreach ($m in $mailboxes)
 $devices += Get-ActiveSyncDeviceStatistics -Mailbox $m.Identity
 $devices | Export-Csv DeviceStats.csv

(Copy and paste the above into a .ps1 script and run it in the Exchange Management Shell on your Exchange 2010 server (or a system with the Exchange Management Tools installed). The script will product a .CSV report similar to Figure R.

Figure R

This screenshot only shows the tip of the iceberg; the report displays many other useful columns such as Status (should read “DeviceOK”), DeviceAccessState (should read “Allowed”), Device Policy (should be the one you set up for mobile devices, if applicable), and DeviceActiveSync version. You could use this information to find another device in the organization matching the problem one and then look at that to see why it’s working so you can triangulate the issue.

If you’re still having problems getting the device to connect check the IIS logs on the CAS server for authentication errors. The log files may be large so ensure you check a period of time matching when the device tried to connect.

Check the Web

Obviously, any tinkerer worth his or her paycheck knows to do a Google search on the issue. Say you have a Google Nexus 7 which won’t connect; you can search for “Google Nexus 7 ActiveSync problem” (it’s even better to enter the exact error or description). You will get relevant articles from tech sites that might help. That’s elementary, but I recommend you first check the Google Product Forum, which offers discussion groups you can review and consult. There is a Google Mobile Help Forum there which is devoted to all mobile issues, and you can narrow the scope to Android Devices. Here’s a good example of a page devoted to issues with The Android Jelly Bean OS and the suggestions offered.

If all else fails

If the default mail client on the Android won’t work with ActiveSync no matter what you’ve tried, I suggest an alternate mail client. For example, there is one called Touchdown which seems to work well for devices that can’t connect natively (here is a review by Jack Wallen of TechRepublic).

In Summary

One of the many ironies of working in IT is that technology is supposed to make our lives easier – and it does, until something breaks and it’s up to you to fix it. In these situations, we can either view the technology as the “enemy” and try to figure out how to thwart it, or we can recognize technology as our ally and use it to solve the problem. Hopefully this article will help you to achieve the latter!

Also read:

TechRepublic and ZDNet delve deeper into this topic in a special report page: BYOD and the Consumerization of IT.