This month, VMWare is releasing some significant changes to their embattled VMWare Boxer application (version 5.8). With that in mind, I wanted to take everyone through the Email Notification Service v2 along with the problem that it solves. I think we all know the challenges that are faced with using any mail client that isn’t the native mail application.

What’s the actual problem?

Apps have never run particularly well in the background on iOS. The CPU monitor will move apps to the background and eventually suspend/shutdown applications. They tend to do this for power consumption, performance, and privacy concerns. This tends to be a problem because users and their email are constantly needing instant gratification.

How does Microsoft Help?

I know Microsoft are help are not always synonymous. Microsoft has something called mailbox notifications, which you can read about here.

The best-in-class example of this are streaming notifications, which are very similar to the concept of “Direct Push” which is how email is delivered to an ActiveSync device today. Simply, as you can see below a server will subscribe for changes and receive notifications from the Exchange Server.

Vendors leverage this technology to build a service that will notify a client device that new mail has arrived. The first company to solve this problem was BlackBerry’s UDS way back when and then followed by others in the not too distant future.

The notifications leverage Microsoft’s API that many products used today called Exchange Web Services or EWS, which is hosted on the same servers as your OWA or Exchange ActiveSync backend. Typically, vendors can use this to deliver a push notification with the sender, sender and subject, or perhaps sender, subject, and a small preview.

ENS v1

VMWare started things off a few years back with the Email Notification Service, which was a valiant first effort to deliver real-time notifications to the Boxer email client. The main highlights are:

• Really only works with Push Notifications (ick!) for On-Premise.
• May occasionally crap out with issues like Insufficient service users in domain which is lovely and fine and useless (I know you shouldnt use and twice in a sentence but thats how frustrating it is!)
• Overall just inconsistent in an on-premise implementation which lets be honest if it is inconsistent then your power users will hammer you. The biggest problem is that if it doesnt work people think Boxer sucks even though they are actually two disparate systems.
• Disabling notifications in the application doesnt 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 dont care much for preview so I wont focus on that.

If you want to learn more about ENSv1, I suggest reading my article on Boxer from a few years ago which really goes deep. The biggest problem with ENSv1 was that very few people were able to make it work properly. You had to be a borderline savant to make the most out of their first stab at notifications.

ENSv2

ENSv2 is much more pliable and does a great job bringing things together. We will discuss a few aspects of it:

• Architecture
• Client Configuration

ENSv2 Architecture

ENSv2’s architectural model has advanced nicely over the last few years. You can now leverage a cloud-hosted endpoint with VMWare or continue to host it yourself. I strongly urge everyone to leverage the cloud-hosted endpoint as everyone should be motivated to reduce your tech debt unless you are using Exchange On-Premise in a regulated environment.

Simply this is how it works as you can see above:

1. Device negotiates encryption keys with the ENS server
2. Device wraps credentials and required info in an encrypted packet and sends it to the ENS server
3. ENS registers for push subscription with your Exchange Server or O365 via webhook URLs.
4. Exchange tells ENS about new emails, which causes ENS to decrypt notification and leverage the user credentials to prepare the fetch
5. ENS fetches the email based on configuration (subject, sender, preview, etc)
6. ENS sends the message details to their notification service (AWS SNS), which will leverage the Apple Push Notification Service (APNS) for iOS or Firebase Cloud Messaging (FCM) for Android.

Deployment Options

The biggest debate with ENSv2 is whether you do On-Premise or Cloud. The main reason I’m not a big proponent of On-Premise is that it requires a Database Server and an Application Server. Let’s start with cloud, which I strongly recommend and is much easier to deploy. The main divide on ENSv2 is whether you are willing to expose your EWS endpoints to the internet or not. Luckily. most people are using O365 for email now, which makes things easier, but not everything is one size fits all.

ENSv2 for Cloud

The main divide between using cloud or on-premise is your security posture. Let’s break down the requirements so it makes sense. When you’re in the cloud, we focus on the network requirements:

Your decision points:

• Can you let Cloud ENS access your EWS endpoint over HTTPs/443?
• Are you okay with Cloud ENS receiving and decrypting your subscription packets we mentioned earlier to subscribe and deliver notifications?

If you can say yes to these two decisions, then Cloud ENS is an easy decision. This will likely work well for most companies especially those in Office 365. Let’s talk about the rest…

ENSv2 For On-Premise with SEGv2 Proxy

ENSv2 On-Premise has become much easier than it was initially. Now, you can use the Secure Email Gateway v2 (SEGv2) as a proxy for communication between the device and ENS. Originally, you had to host the ENSv2 in your DMZ or proxy requests internally, which are both very bad options. Today’s new design can be seen below leveraging SEGv2.

The biggest challenge with hosting this yourself is it requires one server per 100,000 users and a SQL database, which is substantial tech debt. If you are a WorkspaceONE UEM On-Premise customer, its not as big of a deal. Ideally, you won’t need to go this route, but some of you using Exchange 2016 may want to consider it. I won’t dig deep into the setup or configuration, but I want to highlight how to setup your SEG for the proxy method.

You just need to modify the config file called application.properties. You set enable.boxer.ens.ews.proxy=true and restart the SEG services. That’s the nice thing about SEGv2 and moving away from IIS is that changes are much simpler and transparent vs. navigating the IIS nonsense.

Client Configuration

Once you setup the ENSv2 environment, you will configure some application properties via managed app configuration.

The properties and values are below, which you will configure to extend ENSv2 to Boxer below. You can access the Cloud ENS Addresses here if necessary.

In Closing

I know that the information can be a bit daunting. ENSv2 has done a nice job of eliminating the risk of using service accounts, notifications being separate from the mail client itself, and the overall performance issues ENSv1 had. ENSv2 is going to be a game changer as Boxer 5.8 releases and a HUGE deal hits that will change the way we think about mobile email. We no longer have to settle for native mail ineffectiveness or the existing gaps in other clients.