So many people have now been backed into a corner with their unmanaged platform. We just need to look at the options people have been using for years:

• Good for Enteprise (Out of Support officially now)
• Touchdown (Acquired by Symantec a few years ago and will be out of support next year)
• Outlook for iOS/Android (I’ll be doing a write-up on this application and its questionable security posture in a separate post) but suffice it to say there are concerns. For now, feel free to read more here and made your own conclusions

So basically the video below sort of shows what enterprises think of containerizing PIM data (that’s your Outlook/Exchange stuff for those who aren’t BlackBerry nerds from back in the day)

So amusing anecdotes aside, every MDM basically has their own “thing” now regardless of who you use. My focus currently is on AirWatch’s product known as Boxer. I have to give AirWatch credit as the biggest problem that exists in technology is a lack of self awareness. We’ve seen that with BlackBerry not being truly self aware and handling their inadequacies only to suffer later on. They saw an opportunity to purchase a great product which many of the OnePlus fan boys and girls can attest to in Boxer.

Anyone who knows me is very aware that there are fewer bigger supporters than me when it comes to AirWatch. My fate and AirWatch’s fate no matter what they will be called by 2018 are inextricably linked. People have often enjoyed poking fun at my supposed blind loyalty for them, but just as it was with BlackBerry I am truly agnostic. I don’t care what the product is and nothing is one size fits all. Boxer has shown tremendous potential and you will learn quickly with my blogs that I put away the pom-pom’s and only deal in fact. I have seen a number of AirWatch administrators/support people have these blogs that are almost laughable with their unwavering rose-colored glasses. That is not me.

AirWatch Boxer for iOS

I should point out why I decided to focus on the iOS client since the Android client is probably a larger concern. The iOS client introduces tons of complexity for many reasons:

• ActiveSync mail notifications cannot natively be delivered in the background
• When the app locks, the database locks also making it impossible to write to the database (aka deliver new mail) until it is unlocked again
• Well it’s Apple so yeah…

So let’s get into it and cover the application itself, the email notification service, and some of the quirks.

The Client

So just to provide an overview of Boxer before I highlight a few things you should probably know. Since most people know what Boxer is before reading this post, I’ll just provide a nice video below on Boxer. Most of us know the basics (looks pretty, swipe actions, cool availability stuff, used to be the native mail app for OnePlus etc)

Managed App Keys and Why?

Most people don’t really understand what managed app keys are, how to use them, and what the value is. I’ll explain a few of the key ones that are valuable in my opinion. The real key is that you are limited in working with DLP on an unmanaged application especially on iOS. Managed App Keys by design are for DLP and pushing down app settings to simplify onboarding.

PolicyAllowLocalCalendars: Set it to the boolean value of false to block local device calendar access. A really important thing to be aware of is it is not just read only access. If you allow access to local calendars you could theoretically have people copying/pasting emails into calendar invites and synchronizing them up to native calendars which is obviously an issue.

PolicyAllowLocalContacts: Set it to the boolean value of false to block local device contact access. The same applies to contacts as does calendars above.

AppForceActivateSSO: This key enables SSO for the Boxer application, which forces it to use the agent if its MDM enrolled, but the hidden gem with this feature is that it will ensure that proper device information is reported up to the AirWatch admin console and not just a disgusting value with Device ID etc. One caveat is that using this key will ensure the app uses the default application password policy, which can create issues for people in certain situations. One good example is imagine if devices that don’t have Touch ID have to put in their NT Password every 15m (ick!)

PolicyAllowPrint: Set it to the boolean value of false to block someone from printing emails or attachments, which is another DLP issue.

There’s plenty more here if you have a myAirWatch account, but the only ones that I find useful are the ones that I reference above, but some of you may want to do email classifications for example and don’t use a SEG.

Email Notification Service wtf?

So yeah..Mail Apps and new mail notifications are absolutely horrendous no matter what way you slice it. I don’t care what anyone tells you even if it’s Steve Jobs’ zombie. Once the application has locked you are not getting new mail notifications period!

Every company has been trying to solve this quandry for a REALLY long time. Eventually the EMM vendors figured out that there is one real way to fix this:

• Build a web service built off EWS and a service account that has impersonation rights to all the pretty little mailboxes of your company (yes basically what BESAdmin did so many years ago)
• Use that web service to subscribe for either EWS Streaming or Push Notifications (PLEASE PLEASE use EWS Streaming notifications because Push sucks! (Microsoft says that themselves in prettier words)
• When new mail comes, the Exchange server says “Hey you got something!” and it sends a push notification to the device regardless of its state.

AirWatch’s valiant attempt at this is the Email Notification Service, which is a fairly lightweight Windows Server running the AirWatch application, using a service account, etc. So there’s a number of issues with its current implementation. Keep in mind that I only do on-premise and certainly Office 365 is a bit different. It’ll always be easier cloud to cloud:

• Really only works with Push Notifications (ick!) for On-Premise.
• Will just “stop” doing anything eventually with all kinds of stupid random errors like Insufficient service users in domain which is lovely and fine and useless (I know you shouldn’t use and twice in a sentence but that’s how frustrating it is!)
• Overall just inconsistent in an on-premise implementation which let’s be honest if it is inconsistent then your power users will hammer you. The biggest problem is that if it doesn’t work people think Boxer sucks even though they are actually two disparate systems.
• Disabling notifications in the application doesn’t stop the ENS subscription so it makes people lose confidence in the product (Boxer)
• The biggest frustration is that when it works it works REALLY well. You get the option to just do Sender or Sender/Subject which I think is really useful. I don’t care much for preview so I won’t focus on that.

One thing that I learned recently is that you want to make sure you tweak the throttling of your service account and then tweak the ENS configuration.

I largely recommend setting EWS Max Concurrency and EWS Max Subscriptions like this:

Set-ThrottlingPolicy -Identity ENSPolicy -EwsMaxConcurrency:unlimited -EWSMaxSubscriptions:unlimited

I’ve found that the ENS service does a very poor job of cleaning up subscriptions and will suffer from some inconsistencies otherwise. Additionally you want to set the ENS configuration file to some large numbers since I don’t really think it supports unlimited, such as:

maxSubscriptionsPerConnection=”20000″ maxConnectionPerUser=”100″

So, I largely consider myself as a master of putting lipstick on a pig. So I figured out how to “semi” improve things. I’m using Windows Scheduler to restart the service nightly and reboot the server once a week, which is pretty easy via my friend and yours powershell

Restart-Service AirWatchEmailNotificationService for the service restart, but sometimes I’ve seen where it needed a reboot. It takes a bit of patience but overall if you figure out when things go bad you can determine what you should do to improve it.

The last thing that I strongly suggest to ensure it works very well is to run ENS v1 with 16 GB of RAM. They tell you that you only need 4 GB, but that is completely false. What I have found is that ENS will scale up its resources based on what is available to it. Eventually if you run only 4 GB of RAM, it will crap out and you may need to reboot to restore service.

The Quirks

When you marry someone, you often call things you don’t like about them “quirks” so let’s go with that mentality.

The first thing that I always tell people is after you set it up, go stare at the Inbox. The experience that I have had is if you don’t let the mailbox initial sync finish in its entirety then you run into all sorts of “shenanigans.” Once that thing finishes then do whatever you want!

There’s a current bug in Boxer 4.7 where tasks queue up, the app locks, and then those tasks get canceled automatically upon unlock. Something most people don’t realize is when a folder sync is ongoing that it will queue up the remainder of the tasks, which can create some issues. If someone has a really large mailbox, they might think the app doesn’t work because it’s still syncing the initial email. So new emails don’t come in until that initial sync completes. I’ll cover synchronization and how it works more in my ActiveSync article. So to sum it up, the 4.7 bug is a epic fail 🙂

Something that most people don’t realize is when a folder sync is going on a few things happen:

• Headers are being downloaded
• Bodies are being downloaded
• Folder by Folder is synchronized (Inbox, Calendar, Contacts etc)
• All other tasks are queued up and are awaiting completion of the other tasks. Welcome to the world of asynchronous processing.

Typically, what I’ve found to be most useful is being very dynamic in how you manage Boxer. I have a special “Large Mailbox” Smart Group that I use for people with large mailboxes and I deliver them 1 week of email. By reducing the surface size, you can really improve performance.

The thing to really understand about iOS and the ActiveSync protocol is that Apple pushed the limits on the protocol and every vendor will implement the protocol a little bit differently. I have found that the Boxer client for iOS and MORESO Android is very sensitive to environments that have a few kinks in their Exchange armor.

You will learn a lot by reading your Boxer logs. Some stuff is invalid whereas other items give you some really good hints that your Exchange team might have missed some stuff, or your Security team. Here are a few good examples I’ve found over the years that something is off

System.Net.WebException: The request was aborted: The request was canceled: This is a fun one. It’s a current F5 issue that I am aware of and have worked on. You can read the F5 article here that tells you about it. Basically, F5 never issues a connection close so at the end of the PING cycle (15m later) you will get an abort instead of a standard connection close.

Error Error Domain=NSURLErrorDomain Code=-1001 “The request timed out.: I won’t go too crazy on this one, but simply this means your TCP Keep Alive is not set properly. I’m going to cover this more in depth in another article but simply make sure your Exchange Server has the lowest timeout. If ANYTHING from Exchange to Client Device kills your connection that isn’t the Exchange Server then it will create these situations Some mobile clients can actually get your device blacklisted or force email to reload from these sorts of issues. They create resource exhaustion and really mess with things.

I will leave you with one final sentiment that probably won’t be overly popular in some circles but I think self awareness is crucial.I love the Boxer product and dev teams, but let’s just be honest with ourselves. When people start asking for Good for Enterprise back, that’s a problem! I think it’s really close, but it’s not there yet. They definitely need to improve the QC prior to releasing new versions as there have been multiple instances of something missed during the BETA phase. My hope is that by the beginning of 2018 it will be a disruptor. I think that about covers it. I have plans to post a few more blogs over the next few weeks on the SEG, ActiveSync Protocols, and ActiveSync troubleshooting which I have worked on for a long time now. I hope everyone enjoys the content as I think it can be helpful for some of you.

2018 Updated Stance

Boxer is VERY close to finally being enterprise ready. Once they implement the OneDrive APIs it can finally be a viable solution. The key with this is you will NEED to whitelist the Boxer App ID in your MAM Policy for OneDrive. If you need help with that reach out! My honest feelings on Boxer have steadily improved. Without saying too many names, I have to give a ton of credit to Evan, Max, Kris, and Rod all at VMWare for taking my abuse over the last few years about Boxer and using it for the betterment of the enterprise. I gave Evan a hard time at VMWorld last year calling “Boxer an Enterprise product” but I will give them this: “this product is easily as good as Outlook is and is probably better if you have talented people supporting and architecting it.” With that plug for mobility engineers, PLEASE spend the money and hire smart people who know what they are doing. People who use unmanaged devices are TYPICALLY the loudest criticizers of bad products. Maybe its because they’re those silly Android users or maybe its because they are just silly in general. Eliminate your problems before they become problems. That’s how you become a sound architect.

Frequent Issues

This is my first edit for this article. People have been very supportive on my wiki so far and I was thinking that a list of frequent issues might be useful. Here’s a few issues and resolutions I’ve run into.

Issue 1: On enrollment, they see something like “Invalid Credentials “This is the AirWatch Enrollment Username and Password.”

Solution: You typically see this with consultants. Many consultant companies use AirWatch for their main company. Boxer does not allow you to enroll with a different company than the company you are enrolled with via the agent. Most people don’t know that the AirWatch Agent is much more than the thing that tells AirWatch what apps your users have installed. The AirWatch Agent is a SSO broker for all AirWatch Applications. When you try to enroll in Boxer, it checks for the presence in the Agent and tries to auth with the wrong credentials. Currently this is not supported.

Issue 2: Boxer for iOS 4.7 is not synchronizing. Deleting the application and reinstalling it will resume syncing for awhile.

This is an issue that will be resolved in Boxer 4.8. If you check the Boxer log, you will see”2017-07-13T04:12:36Z Associate email failed with database error: UNIQUE constraint failed: EmailToFolder.FolderId, EmailToFolder.Uid” which is basically an old SQL error. You may not be aware that essentially you have a SQL database in each application. The error basically means there’s data issues in the table aka corrupt data. Verbatim it means “The UNIQUE constraint ensures that all values in a column are different.” So in other words, you have a primary key for data like an ID and something is eff’d.

Issue 3: You cannot access your email when the device is offline

This one is very amusing. You need to make sure that you use the SDK for Boxer for a few key reasons. #1 is for jailbreak detection and #2 to achieve offline access. You just need to modify your SDK profile for Boxer. Product Management will “say” that you should use the default SDK profile for all AirWatch apps where Mobile Jon takes a page out of his four year old: “I’ll do what I want!” So, I use individual SDK profiles for each application and apply them for things like App Logs, Crash Logs, etc.