by Thorsten Rood, CTP
For a long time now, running around with WorxMail on iOS devices left behind a bad taste depending on the actual usage: being the information junky that made frequent use of the app, an apple-specific algorithm kicked in to wake up the app very often when running in the background, resulting in nearby real-time notifications on incoming new items. Approaching periods of lowered interactivity, such as weekends, this experience quickly went away. The complaints by users were obvious, but also not avoidable. Reason for this is the underlying background services scheduling that iOS takes care of based on user telemetry. The more time you spend with an app, the more it qualifies for CPU cycles when not being in the foreground. Ugly, isn’t it? So the whole ActiveSync technology concept of long lived http calls to instantly “wake” an app simply doesn’t work on iOS. While you would like to blame Citrix for that, it wasn’t their fault at all. Other vendors struggled the same way.
This inefficiency is now taken care of with APNS push. In a nutshell, WorxMail instructs Exchange server to wake up each registered device per affected user to receive a true real time CPU allocation, and the only way to achieve this today is through Apple push notification services (APNS). What Citrix provides you is a free-of-charge cloud-hosted service (running in AWS) that all your enabled WorxMail devices subscribe to with their specific device ID, plus they also instruct your Exchange server to wake Citrix’s AWS instance whenever an inbox event (new items, and other changes to the “unread” counter) occurs. So Exchange notifies Citrix forwarder in cloud per each item once, and the cloud service then multiplexes this event to all devices per user. This surprisingly works better than what the core ActiveSync implementation with outstanding http calls can do, as we’ve seen APNS being a little faster than EAS (and the reason is simple as the new badge count comes in with APNS directly and WorxMail doesn’t even have to fetch this data over the wire, what would be required for native EAS).
Some “minimal” changes have to be implemented to make all this now happen technically. First, you need to wrap with explicit AppIDs instead of wildcards (but this applies to all new Apple developer accounts, anyway) and in case you run multiple independent Exchange environments such as dev and prod, you have to differentiate them all and wrap each of them and make sure you’ll never mix up the resulting .mdx container in your XenMobile setup. For each AppID, you also need a client certificate flagged for APNS usage as this is the mandatory security layer for an external party to authenticate to APNS when sending messages out to its subscribers. Associate the certificate with the AppID and the corresponding provisioning profile. With that done, hand over the certificate (including private key) to Citrix forwarding service and configure your WorxMail metadata configuration with the obtained customer ID to match those entities together. Lastly, make sure both your WorxMail clients and your Exchange CAS servers can talk to AWS. While the client side should be easy to accomplish (similar requirements as for WorxWeb being able to access public web sites), the Exchange part could become tricky. The easiest approach will be a direct NAT outbound authorization to the internet but this really may conflict with your security zone design and access policies. Luckily you can reconfigure Exchange to make use of your enterprise forward proxy for outbound access. Should be good for many customers, as long as the proxy supports anonymous connections, for example based on CAS source IP. While functional issues will get tracked through event logging, the “good case” tracker is harder to obtain from logging, in both cases.
An unofficial, but also fully working alternate approach is redirecting Exchange notifications though the NetScaler unit residing in DMZ anyway for XenMobile purposes (allowing a generic hopping mechanism through security zones with full layer 7 inspection). While it sounds like rocket science, all you have to do is temporarily “lying” to Exchange CAS when the subscription request comes in and later forwarding it to the respective AWS zone once it has been caught again through NetScaler. For security-oriented customers with a more complex communication restrictions, this may really help. On top, you’ll receive a nice hit counter on your Exchange noise.
In the end, this new feature obviously can’t be ignored if you want to keep your users happy.
Enjoy!
Recommended further reading:
APNS Push for Users
APNS Push for Admins
iOS background services
