Designing and implementing a successful Enterprise Mobility Management (EMM) solution that keeps both end users and security teams happy involves making some crucial decisions before commencing the implementation phase.

This article aims to organize and simplify some of the various data points that are common contributing factors in XenMobile Enterprise design decisions. The information here can be leveraged as a reference during relevant design discussions as it relates to designing an environment that balances user experience and security.

The topics discussed in this article are:

  1. Requiring MDM vs. Not Requiring MDM
  2. Session and Application Time-outs
  3. Mobile Email

It should be noted that the data in each decision tree represents only common talking points. Unique use cases and other environmental factors may involve more extensive information.

Alright … let’s get down to it!

1) Requiring MDM vs. Not Requiring MDM

In a XenMobile Enterprise environment, there is often a mixture of use cases that may or may not require a device to be managed by Mobile Device Management (MDM) polices in order to access your Mobile Application Management (MAM) resources. When configuring WorxHome on their device for the first time, a user will typically either enter their email address or enrollment URL as the first step. After authenticating (assuming they didn’t enter the NetScaler Gateway URL), the user will then be prompted to enrollĀ their device if they wish to do so. Assuming MDM is optional in the environment, this is where it breaks down into two different flows:

A) If the user selectsĀ YES:

  • The device will be enrolled into XenMobile and become a managed device by MDM. If configured, users will also have access to their MAM resources (and/or HDX resources if StoreFront is integrated). This combination of MDM and MAM can be referred to as hybridĀ mode.
B) If the user selects NO:
  • The device will bypass MDM enrollment and receive access to their MAM resources (and/or HDX resources if StoreFront is integrated). This can be referred to as MAM-onlyĀ mode.

Since the ability to require MDM enrollment is set at a global level on the XenMobile Server (XMS) with version 10 (Configure –> Settings –>Ā  Server Properties –> Enrollment Required –> true/false), this setting affects all users/devices within that XMS instance. After a deep dive into MDX application containerization and encryption with security teams, you may find that “MDM Required” is not a true requirement. On the other hand,Ā MAM-only control without MDM policies may not satisfy all needs. Regardless, it is vital to weigh this decision out in the beginning to avoid deviceĀ re-enrollmentĀ as described in part b of this section’s key takeaways.

The following decision tree outlines some of the contributing factors around this topic:

Requiring MDM vs Not Requiring MDM
Requiring MDM vs Not Requiring MDM

Key takeaways:

a) “MDM Required” is a global setting.

b) Changing “MDM Required” to “true” after the fact will require MAM-only users to re-enroll their devices so it’s best to make this decision before too many users are on-boarded to the environment.

c) Talk through every single use case and how this setting will affect them to help weigh out the environment’s need on the whole

  • Consider alternatives to mitigate security concerns for specific use cases before making the final decision (like how timers come into play with decision 2 in this article entitled Session and Application Time-outs).
d) If there are two unique use cases significant enough on both sides of the argument, there is always the option to have two dedicated environments (one for MDM requiredĀ and one for MDM not required). It’s best to avoid this since you will now be managing two environments and require additional resources, but it is an option and customers have implemented this with success.

2) Session and Application Time-outs

Session and application time-outs are EVERYTHING! Not only do they define the user experience, but the security of user data as well. This does not mean, however, that just because the data needs to be secure, the time-outs need to be as short as possible.

It is important to remember that there are many mechanisms at play here outside of authentication frequency keeping your data secure, not to mention the ability to have multiple layers of authentication/authorization.

I highly recommend first checking out “XenMobile 8.x – Understanding Authentication Timeout Values” for more information on how these come into play. While some of the values mentioned in the article are deprecated with recent versions of XenMobile, it gives a solid explanation of how these timers work together. Additionally, in XenMobile versions 9 and above, the application “inactivity timer” was released, further enhancing security and user experience. Albert Alvarez does a great job explaining this feature here. For a deeper dive into this topic, be sure to also read “XenMobile Timeouts: How do they work?”

The decision tree belowĀ outlines some of the different settings available with regard to session and application time-outs along with the pros and cons to changing their values:

XenMobile Session and Application Time-outs
Session and Application Time-outs

Key takeaways:

a) The decision is not necessarily to use one baseline or the other in this tree but rather to find your “sweet spot” which may very well be somewhere in the middle.

b) As you decrease time-out values, you may sacrifice user experience, but increase security.

c) As you increase time-out values, you improve user experience, but may sacrifice security.

  • Note: I emphasize the may in this one because many of the security concerns can often be mitigated in other ways so be sure to find out why if there is a push to decrease specific time-out values.

d) Lead with user experience and tweak for security if possible. The effect of these time-out values is often tough to realize. It may help to start with a lenient baseline and see how accepting pilot users are as security begins to tighten these down rather than the other way around.

e) This decision tree should come into play when discussing decision 1 in this article, entitledĀ Requiring MDM vs Not Requiring MDM for Access to MAM Resources.

3) Mobile Email

WorxMail vs native mail? “Tunneled to the internal network” vs “unrestricted” network access? There are many flavors to choose from when it comes to delivering email to mobile devices. If the security team doesn’t have concerns here and the only thing that matters is getting email to a mobile device, then it’s likely an environment where EAS/CAS is already externally accessible and anyone can configure their native mail client to receive e-mail. In this scenario, it may be a perfect fit for XenMobile Mail Manager (XMM) or XenMobile NetScaler Connector (XNC) for additional filtering and compliance checking. However, this only solves a fraction of the problem.

If the goal is to lock down external Internet access to EAS/CAS and provide full control over the device’s email application, WorxMail is likely the appropriate solution. Also, what happens when a user wants to view/edit attachments on iOS, Android and Windows mobile devices? The answer is every user is on their own to download or use a 3rd-party viewer/editor for each file type (p.s. those attachments are now free to be saved/edited/distributed however users please šŸ˜‰ ). Don’t forget the importance of calenders, tasks, notes, and all that comes along with going mobile. By leveraging WorxMail and our MDX technology, you can take advantage of the full Worx Mobile app suite including seamless integration with ShareFile. Aside from the security concerns that are addressed, you now have a standard platform and user experience across all devices with added feature sets which far exceed that of a native email client. Remember, this is something that can change over time. There may be some scenarios where a phased approach fits but be sure to account for user adoption.

All of the above being said, there are still decisions to be made on mobile email security and user experience. It really boils down to 4 options (in no particular order):

The following decision tree outlines some of the pros and cons for each option:

Mobile Email
Mobile Email

Key takeaways:

a) Mobility = productivity. Be sure to choose the solution that best fits each user community in terms of workflow, not just e-mail. Consider how attachments will be viewed/edited and how internal URLs sent in an email will be accessed (you may require WorxWeb or other MDX applications like ShareFile).

b) This is really about performance and user experience vs. security. It’s important to find the right fit for each business requirement. If the need is to keep a fair balance between both sides, then you may want to lead with WorxMail.

  • If choosing WorxMail, consider how timers come into play here. You may want to referenceĀ decision 2Ā again entitledĀ Session and Application Time-outsĀ to find the right mix.

Final Note:

Don’t underestimate user adoption! Whichever solutions are chosen, ensure that on-boarding resources are plentiful. This may come in the form of documentation, verbal or written communications, webinars/presentations, flyers, kiosks for employee assistance, and/or any combination of these and more. Create a “hype” around it if you are making a significant change!

Happy mobilizing,
Craig Tylek

Huge thanks to the following people who have contributed to obtaining and reviewing this content: Adam Savoy, Nicholas Rintalan, Roberto Moreno, Ryan McClure, Jing Song Huang, and James Armstrong.