XenMobile Apps administration and delivery
May 10, 2018
This article provides an overview of app administration and delivery in XenMobile.
Prerequisites for feature flag management
If an issue occurs with Secure Hub or Secure Mail in production, we can disable an affected feature within the app code. To do so, we use feature flags and a third-party service called Launch Darkly. You do not need to make any configurations to enable traffic to Launch Darkly, except when you have a firewall or proxy blocking outbound traffic. In that case, you enable traffic to Launch Darkly via specific URLs or IP addresses, depending on your policy requirements. For details about support in MDX since XenMobile Apps 10.6.15 for the exclusion of domains from tunneling, see the MDX Toolkit documentation. For a FAQ about feature flags and Launch Darkly, see this Support Knowledge Center article.
End of Life for enterprise XenMobile Apps was December 31, 2017.
Public app store apps require a fresh installation the first time you deploy them. It is not possible to upgrade from the current enterprise wrapped version of the app to the public store version.
With public app store distribution, you do not sign and wrap Citrix-developed apps with the MDX Toolkit. This significantly streamlines the process of deploying apps. You can use the MDX Toolkit to wrap third-party or enterprise apps.
- XenMobile 10.5 or later.
- Ensure that the apps can communicate with the following services if you have split tunneling on NetScaler set to OFF:
- Launch Darkly service. For details, see this Support Knowledge Center article.
- APNs listener service
Supported app stores
XenMobile Apps are available on the Apple App Store and Google Play. For securing and deploying the native productivity apps on Windows devices, see the Windows Information Protection device policy.
In China, where Google Play is unavailable, Secure Hub for Android is available on the following app stores:
Enabling public app store distribution
- Download public-store .mdx files for both iOS and Android from the XenMobile downloads page.
- Upload the .mdx files to the XenMobile console. The public store versions of XenMobile Apps are still uploaded as MDX applications. Do not upload the apps as public store apps on the server. For steps, see Add apps.
- Change policies from their defaults based on your security policies (optional).
- Push the apps as required apps (optional). This step requires your environment to be enabled for mobile device management.
- Install apps on the device from the App Store, Google Play, or the XenMobile Store.
- On Android, the user is directed to the Play Store to install the app. On iOS, in deployments with MDM, the app installs without the user being taken to the app store.
- When the app is installed from the App Store or Play Store, the app transitions to a managed app as long the corresponding .mdx file has been uploaded to the server. When transitioning to a managed app, the app prompts for a Citrix PIN. When users enter the Citrix PIN, Secure Mail displays the account configuration screen.
- Apps are accessible only if you’re enrolled in Secure Hub and the corresponding .mdx file is on the server. If either condition is not met, users can install the app, but usage of the app is blocked.
If you currently use apps from the Citrix Ready Marketplace that are on public app stores, you’re already familiar with the deployment process. XenMobile Apps adopt the same approach that many ISVs currently use. Embed the MDX SDK within the app to make the app public-store ready.
The public store versions of the ShareFile app for both iOS and Android are now universal. The ShareFile app is the same for phones and tablet.
Apple Push Notifications
For more information on configuring push notifications, see Configuring Secure Mail for Push Notifications.
Public App Store FAQs
1. Can I deploy multiple copies of the public store app to different user groups? For example, I may want to deploy different policies to different user groups.
You’ll have to upload a different .mdx file for each user group. However, in this case, a single user cannot belong to multiple groups. If users did belong to multiple groups, multiple copies of the same app are assigned to that user. Multiple copies of a public store app cannot be deployed to the same device, because the app ID can’t be changed.
2. Can I push public store apps as required apps?
Yes. Pushing apps to devices requires MDM; it’s not supported for MAM-only deployments.
3. Do I need to update any traffic policies or Exchange Server rules that are based on user agent?
Strings for any user agent-based policies and rules by platform are as follows.
|Citrix Secure Mail||Exchange||WorxMail|
|Lotus Notes Traveler||Apple - iPhone WorxMail|
|Citrix Secure Web||WorxMail|
|Citrix Secure Tasks||Exchange||WorxMail|
|Citrix Secure Notes||Exchange||WorxMail|
|Citrix Secure Mail||Exchange||WorxMail|
|Lotus Notes Traveler||Apple - iPhone WorxMail|
|Citrix Secure Web||com.citrix.browser|
|Citrix Secure Tasks||Exchange||WorxTasks|
|Citrix Secure Notes||Exchange||WorxNotes|
4. Can I prevent app upgrades?
No. When an update is posted on the public app store, any users who have auto updates enabled receive the update.
5. Can I enforce app upgrades?
Yes, upgrades are enforced via the Upgrade grace period policy. This policy is set when the new .mdx file corresponding to the updated version of the app is uploaded to the XenMobile Server.
6. How do I test the apps before the update reaches users if I can’t control the update timelines?
Similar to the process for Secure Hub, the apps are available for testing on Test Flight for iOS during the EAR period. For Android, the apps are available via the Google Play beta program during the EAR period. You can test app updates during this time.
7. What happens if I don’t update the new .mdx file before the automatic update reaches user devices?
The updated app continues to work with the older .mdx file. Any new features that depend on a new policy are not enabled.
8. Will the app transition to managed if Secure Hub is installed or does the app need to be enrolled?
Users must be enrolled in Secure Hub for the public store app to activate as a managed app (secured by MDX) and to be usable. If Secure Hub is installed, but not enrolled, the user cannot use the public store app.
9. Do I need an Apple Enterprise developer account for the public store apps?
No. Because Citrix is now maintaining the certificates and provisioning profiles for XenMobile Apps, an Apple Enterprise developer account is not required to deploy the apps to users.
10. Does the end of enterprise distribution apply to any wrapped application I have deployed?
No, it applies only to the XenMobile productivity apps: Secure Mail, Secure Web, Secure Notes, Secure Tasks, Sharefile for XenMobile, ScanDirect for XenMobile, QuickEdit for XenMobile, and ShareConnect for XenMobile. Any other enterprise wrapped apps you have deployed that are either developed in-house or by third parties can continue to use enterprise wrapping. The MDX Toolkit will continue to support enterprise wrapping for app developers.
11. When I install an app from Google Play, I get an Android error with error code 505.
This is a known issue with Google Play and Android 5.x versions. If this error occurrs, you can follow these steps to clear stale data on the device that prevents installation of the app:
Restart the device.
Clear the cache and data for Google Play through device settings.
As a last resort, remove and then add back the Google account on your device.
For more information, see this blog.
12. Although the app on Google Play has been released to production and there isn’t a new beta release, why do I still see Beta after the app title on the Google Play?
If you are part of our Early Access Release (EAR) program, you always see Beta next to the app title. This name simply notifies users of their access level for a particular app. The Beta name indicates that users receive the most recent version of the app available. The most recent version may be the latest version is published to a production track or to a beta track.
13. After installing and opening the app, users see the message App Not Authorized, even though the .mdx file is on the XenMobile Server.
This issue can happen if users install the app directly from the App Store or Google Play and Secure Hub is not refreshed. Secure Hub needs to be refreshed when the inactivity timer is expired. Policies refresh when users opens Secure Hub and reauthenticate. The app is authorized the next time users open the app.
14. Do I need an access code to use the app? I see a screen prompting me to enter an access code when I install the app from the App Store or Play Store.
If you see a screen requesting an access code, you are not enrolled in XenMobile through Secure Hub. Enroll with Secure Hub and ensure that the .mdx file for the app is deployed on the server. Also ensure that the app can be used. The access code is limited to Citrix internal use only. Apps require a XenMobile deployment to be activated.
15. Can I deploy iOS public store apps via VPP or DEP?
XenMobile Server is optimized for VPP distribution of public store apps that are not MDX-enabled. Although you can distribute the XenMobile public store apps with VPP, the deployment is not optimal, until we make further enhancements to the XenMobile Server and the Secure Hub store to address the limitations. For a list of known issues with deploying the XenMobile public store apps via VPP and potential workarounds, see this article in the Citrix knowledge center.
MDX policies for XenMobile Apps
MDX policies enable you to configure settings that the XenMobile Server enforces. The policies cover authentication, device security, network requirements and access, encryption, app interaction, app restrictions, and more. Many MDX policies apply to all XenMobile Apps; some policies are app-specific.
Policy files are provided as .mdx files for the public store versions of the XenMobile Apps. You can also configure policies in the XenMobile console when you add an app.
The following sections describe the MDX policies related to user connections.
User connections to the internal network
Connections that tunnel to the internal network can use a full VPN tunnel or a variation of a clientless VPN, referred to as secure browse. The Preferred VPN mode policy controls that behavior. By default, connections use secure browse, which is recommended for connections that require SSO. The full VPN tunnel setting is recommended for connections that use client certificates or end-to-end SSL to a resource in the internal network; the setting handles any protocol over TCP and can be used with Windows and Mac computers as well as iOS and Android devices.
Secure Web for iOS and Android supports use of a Proxy Automatic Configuration (PAC) file with a full VPN tunnel deployment, if you use NetScaler for proxy authentication. For details, see User connections to the internal network.
The Permit VPN mode switching policy allows automatic switching between the full VPN tunnel and secure browse modes as needed. By default, this policy is off. When this policy is on, a network request that fails due to an authentication request that cannot be handled in the preferred VPN mode is retried in the alternate mode. For example, server challenges for client certificates can be accommodated by the full VPN tunnel mode, but not secure browse mode. Similarly, HTTP authentication challenges are more likely to be serviced with SSO when using secure browse mode.
Network Access Restrictions
The Network access policy specifies whether restrictions are placed on network access. By default, Secure Mail and Secure Notes access is unrestricted, which means no restrictions are placed on network access; apps have unrestricted access to networks to which the device is connected. By default, Secure Web access is tunneled to the internal network, which means a per-application VPN tunnel back to the internal network is used for all network access and NetScaler split tunnel settings are used. You can also specify blocked access so that the app operates as if the device has no network connection.
Do not block the Network access policy if you want to allow features such as AirPrint, iCloud, and Facebook and Twitter APIs.
The Network access policy also interacts with the Background network services policy. For details, see Integrating Exchange Server or IBM Notes Traveler Server.
XenMobile client properties
Client properties contain information that is provided directly to Secure Hub on user devices. Client properties are located in the XenMobile console in Settings > Client > Client Properties.
Client properties are used to configure settings such as the following:
User password caching
User password caching allows the users’ Active Directory password to be cached locally on the mobile device. If you enable user password caching, users are prompted to set a Citrix PIN or passcode.
The inactivity timer defines the time in minutes that users can leave their device inactive and then can access an app without being prompted for a Citrix PIN or passcode. To enable this setting for an MDX app, you must set the App passcode policy to On. If the App passcode policy is Off, users are redirected to Secure Hub to perform a full authentication. When you change this setting, the value takes effect the next time users are prompted to authenticate.
Citrix PIN authentication
Citrix PIN simplifies the user authentication experience. The PIN is used to secure a client certificate or save Active Directory credentials locally on the device. If you configure PIN settings, the user sign on experience is as follows:
When users start Secure Hub for the first time, they receive a prompt to enter a PIN, which caches the Active Directory credentials.
When users subsequently start a XenMobile app, they enter the PIN and sign on.
You use client properties to enable PIN authentication, specify the PIN type, and specify PIN strength, length, and change requirements.
Fingerprint authentication is an alternative to Citrix PIN when wrapped apps, except for Secure Hub, need offline authentication, such as when the inactivity timer expires. You can enable this feature in the following authentication scenarios:
- Citrix PIN + Client certificate configuration
- Citrix PIN + Cached AD password configuration
- Citrix PIN + Client certificate configuration and Cached AD password configuration
- Citrix PIN is off
If fingerprint authentication fails or if a user cancels the fingerprint authentication prompt, wrapped apps fall back to Citrix PIN or AD password authentication.
Fingerprint authentication requirements:
iOS devices (minimum version 8.1) that support fingerprint authentication and have at least one fingerprint configured.
User entropy must be off.
To configure fingerprint authentication
If user entropy is on, the Enable Touch ID Authentication property is ignored. User entropy is enabled through the Encrypt secrets using Passcode key.
In the XenMobile console, go to Settings > Client > Client Properties.
Add the key ENABLE_TOUCH_ID_AUTH, set its Value to True and then set the policy Name to Enable Fingerprint Authentication.