- What's new
- System requirements
- Onboarding and resource setup
- About XenMobile Service
Certificates and authentication
- NetScaler Gateway and XenMobile
- Domain or domain plus security token authentication
- Client certificate or certificate plus domain authentication
- PKI entities
- Credential providers
- APNs certificates
- SAML for single sign-on with ShareFile
- Single sign in with Azure Active Directory
- Derived credentials for iOS
- User accounts, roles, and enrollment
- ActiveSync Gateway
- Android for Work
- Bulk enrollment of Apple devices
- Bulk enrollment of Windows devices
- Client properties
- Deploy devices through Apple DEP
- Device enrollment limit
- Enroll devices
- Firebase Cloud Messaging
- Google Play credentials
- Integrate with Apple Education features
- Network Access Control
- Samsung KNOX
- Security actions
- Shared devices
- Workspace hub device management
- XenMobile Autodiscovery Service
- AirPlay mirroring device policy
- AirPrint device policy
- Android for Work app restriction policy
- Android for Work app permissions
- APN device policy
- App access device policy
- App attributes device policy
- App configuration device policy
- App inventory device policy
- Application Guard device policy
- App lock device policy
- App network usage device policy
- Apps notifications device policy
- App restrictions device policy
- App tunneling device policy
- App uninstall device policy
- App uninstall restrictions device policy
- BitLocker device policy
- Browser device policy
- Calendar (CalDav) device policy
- Cellular device policy
- Connection scheduling device policy
- Contacts (CardDAV) device policy
- Control OS Updates device policy
- Copy Apps to Samsung Container device policy
- Credentials device policy
- Custom XML device policy
- Defender device policy
- Device Guard device policy
- Device Health Attestation device policy
- Device name device policy
- Education Configuration device policy
- Enterprise Hub device policy
- Exchange device policy
- Files device policy
- FileVault device policy
- Firewall device policy
- Font device policy
- Home screen layout device policy
- Import Device Configuration device policy
- Import iOS & macOS Profile device policy
- Kiosk device policy
- Launcher configuration device policy for Android
- LDAP device policy
- Location device policy
- Lock screen message device policy
- Mail device policy
- Managed bookmarks device policy
- Managed domains device policy
- Maps device policy
- Maximum resident users device policy
- MDM options device policy
- Office device policy
- Organization information device policy
- Passcode device policy
- Passcode lock grace period device policy
- Personal hotspot device policy
- Power management device policy
- Profile Removal device policy
- Provisioning profile device policy
- Provisioning profile removal device policy
- Proxy device policy
- Restrictions device policy
- Roaming device policy
- Samsung MDM license key device policy
- SCEP device policy
- Siri and dictation policies
- SSO account device policy
- Storage encryption device policy
- Store device policy
- Subscribed calendars device policy
- Terms and conditions device policy
- VPN device policy
- Wallpaper device policy
- Web content filter device policy
- Webclip device policy
- WiFi device policy
- Windows Agent device policy
- Windows Hello for Business device policy
- Windows Information Protection device policy
- XenMobile options device policy
- XenMobile uninstall device policy
- Deprecated device policies
- Add apps
- Add media
- Deploy resources
- Automated actions
- Monitor and support
- REST APIs
- XenMobile Mail Manager 10.x
- XenMobile NetScaler Connector
- Management modes
- Device requirements
- Security and user experience
- User communities
- Email strategy
- XenMobile integration
- Integrating with NetScaler Gateway and NetScaler
- SSO and proxy considerations for MDX Apps
- Server properties
- Device and app policies
- User enrollment options
- Tuning XenMobile operations
- App provisioning and deprovisioning
- Dashboard-based operations
- Role-Based Access Control and XenMobile support model
- Systems monitoring
- Citrix support process
- Sending group enrollment invitations in XenMobile
- Configuring certificate-based authentication with EWS for Secure Mail push notifications
- Configuring an on-premises Device Health Attestation server
- XenMobile deployment
XenMobile lets you configure devices that multiple users can share. The shared devices feature lets, for example, clinicians in hospitals use any nearby device to access apps and data rather than having to carry around a specific device. You may also want shift workers in fields like law enforcement, retail, and manufacturing to share devices to reduce equipment costs.
- Available on both iOS and Android tablets and phones. Basic device enrollment program (DEP) enrollment is not supported for a XenMobile Enterprise shared device. You must use an authorized DEP to enroll a shared device in this mode.
- Client certificate authentication, Citrix PIN, Touch ID, User Entropy, and two-factor authentication are not supported.
- Available only on iOS and Android tablets.
- Supported on XenMobile 10.3.x and later.
- Only Active Directory username and password authentication is supported.
- Client certificate authentication, Worx PIN, Touch ID, User Entropy, and two-factor authentication are not supported.
- MAM-only mode is not supported. The devices must enroll in MDM.
- Only Secure Mail, Secure Web, and the ShareFile mobile app are supported. HDX apps are not supported.
- Active Directory users are the only supported users; local users and groups are not supported
- Re-enrollment is required for existing MDM-only shared devices to update to MDM+MAM mode.
- Users can share XenMobile Apps and MDX-wrapped apps only; they cannot share native apps on the devices.
- Once downloaded during first-time enrollment, XenMobile Apps are not downloaded again each time a new user signs on to the device. The new user can pick up the device, sign on, and get going.
- On Android, to isolate each user’s data for security purposes, the Disallow rooted devices policy in the XenMobile console should be On.
Before you can enroll shared devices, you must do the following:
- Create a shared device enrollment user role. See Configure roles with RBAC.
- Create a shared device user. See To add, edit, or delete local user accounts.
- Create a delivery group that contains the base policies, apps, and actions that you want to be applied to the shared device enrollment user. See Deploy resources.
- Create an Active Directory group named something like Shared Device Enrollers.
- Add to this group Active Directory users who will enroll shared devices. If you want a new account for this purpose, create a new Active Directory user (for example, sdenroll) and add that user to the Active Directory group.
Shared device requirements
For the best user experience, including silent installation and removal of apps, Citrix recommends configuring shared devices on the following platforms:
- iOS 9 (MDM only) and iOS 10
- Android M
- Android 5.x
- Android 4.4.x (MDM only)
- Android 4.0.x (MDM only)
Follow these steps to configure a shared device.
- From the XenMobile console, click the gear in the upper-right corner. The Settings page appears.
- Click Role-Based Access Control, then click Add. The Add Role screen appears.
Create a shared-device enrollment user role named Shared Device Enrollment User with Shared devices enroller permissions under Authorized Access. Be sure to expand Devices in Console features and then select Selective Wipe device. This setting ensures that the apps and policies provisioned through the shared devices enroller account are deleted through Secure Hub, when the device is un-enrolled.
For Apply Permissions, keep the default setting, To all user groups, or assign permissions to specific Active Directory user groups with the To specific user groups.
Click Next to move to the Assignment screen. Assign the shared-device enrollment role you just created to the Active Directory group you created for shared device enrollment users in Step 1 under Pre-requisites. In the image below, citrix.lab is the Active Directory domain and Shared Device Enrollers is the Active Directory group.
Create a delivery group that contains the base policies, apps, and actions that you want to apply to the device when a user is not signed on, then associate that delivery group with the shared device enrollment user Active Directory group.
Install Secure Hub on the shared device and enroll it in XenMobile using the shared device enrollment user account. You can now view and manage the device through the XenMobile console. For more information, see Enrolling Devices.
To apply different policies or to provide additional apps for authenticated users, you must create a delivery group associated with those users and deployed to shared devices only. When creating the groups, configure deployment rules to ensure that the packages are deployed to shared devices. For more information, see Deploy Resources.
- To stop sharing the device, perform a selective wipe to remove the shared device enrollment user account from the device, along with any apps and policies deployed to it.
Users see only the resources available to them, and they have the same experience on every shared device. The shared device enrollment policies and apps always remain on the device. When a user who isn’t enrolled in shared devices signs on to Secure Hub, that person’s policies and apps are deployed to the device. When that user signs off, the policies and apps that differ from those of the shared device enrollment are removed, while the shared-device enrollment resources remain intact.
Secure Mail and Secure Web are deployed to the device when enrolled by the shared device enrollment user. User data is maintained securely on the device. The data is not exposed to other users when they sign on to Secure Mail or Secure Web.
Only one user at a time can sign on to Secure Hub. The previous user must sign off before the next user can sign on. For security reasons, Secure Hub does not store user credentials on shared devices, so users must enter their credentials each time they sign on. To ensure that a new user cannot access resources intended for the previous user, Secure Hub does not allow new users to sign on while the policies, apps, and data associated with the previous user are being removed.
Shared device enrollment doesn’t change the process for upgrading apps. You can push upgrades to shared-device users as always, and shared-device users can upgrade apps right on their devices.
- For the best Secure Mail performance, set Max sync period based on the number of users that will share the device. Allowing unlimited sync is not recommended.
|Number of users sharing device||Recommended max sync period|
|21 to 25||1 week or less|
|6 to 20||2 weeks or less|
|5 or fewer||1 month or less|
Block Enable contact export to avoid exposing a user’s contacts to other users who share the device.
On iOS, only the following settings can be set per user. All other settings will be common across users who share the device:
- Out of Office
- Sync Mail Period
- Check Spelling