- What's new in XenMobile Server 10.8
- Fixed issues
- Known issues
- System requirements and compatibility
- Install and configure
- Certificates and authentication
- User accounts, roles, and enrollment
- ActiveSync Gateway
- Android for Work
- Bulk enrollment of iOS and macOS devices
- Client properties
- Deploy iOS and macOS 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
- XenMobile Autodiscovery Service
- Device policies by platform
- AirPlay mirroring device policy
- AirPrint device policy
- Android for Work app restriction policy
- Android for Work permissions
- APN device policy
- App access device policy
- App attributes device policy
- App configuration device policy
- App inventory 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 manager 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
- Delete files and folders device policy
- Delete registry keys and values 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
- Font device policy
- Home screen layout device policy
- Import iOS & macOS Profile device policy
- Kiosk device policy for Samsung SAFE
- Launcher configuration device policy for Android
- LDAP device policy
- Location device policy
- Mail device policy
- Managed domains device policy
- MDM options device policy
- Organization information device policy
- Passcode device policy
- Personal hotspot device policy
- Profile Removal device policy
- Provisioning profile device policy
- Provisioning profile removal device policy
- Proxy device policy
- Registry device policy
- Remote support device policy
- Restrictions device policy
- Roaming device policy
- Samsung MDM license key device policy
- Samsung SAFE firewall 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 CE certificate device policy
- Windows Information Protection device policy
- XenMobile options device policy
- XenMobile uninstall device policy
- Add apps
- Add media
- Deploy resources
- Automated actions
- Monitor and support
- REST APIs
- XenMobile Mail Manager 10.x
- XenMobile NetScaler Connector
- On-premises XenMobile interaction with Active Directory
- Management Modes
- Device Requirements
- Security and User Experience
- User Communities
- Email Strategy
- XenMobile Integration
- Multi-Site Requirements
- Integrating with NetScaler Gateway and NetScaler
- SSO and Proxy Considerations for MDX Apps
- Reference Architecture for On-Premises Deployments
- 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
- Systems Monitoring
- Disaster Recovery
- Citrix Support Process
- Sending group enrollment invitations in XenMobile
- Configuring an on-premises Device Health Attestation server
- Configuring certificate-based authentication with EWS for Secure Mail push notifications
You can architect and configure XenMobile deployments that include multiple sites for disaster recovery using an active-passive failover strategy.
The recommended disaster recovery strategy discuss in this article consists of:
- A single XenMobile active site in the datacenter of one geographical location serving all the enterprises users globally, known as the primary site.
- A second XenMobile site in the datacenter of a second geographical location, known as the disaster recovery site. This disaster recovery site provides active-passive site failover in if a site-wide datacenter failure occurs in the primary site. The primary site includes XenMobile, SQL database, NetScaler infrastructure in order to facilitate failover and provide users with access to XenMobile via the event of connectivity failure to the primary site.
The XenMobile servers at the disaster recovery site remains offline during normal operations and is brought online during only disaster recovery scenarios, where complete site failover from the primary site to the disaster recovery site is required. The SQL Servers at the disaster recovery site must be active and ready to service connections before you start the XenMobile servers at the disaster recovery site.
This disaster recovery strategy relies on manual failover of the NetScaler access tier by means of DNS changes for routing MDM and MAM connections to the disaster recovery site in the event of an outage.
To use this architecture, you must have a process in place for asynchronous backups of the databases and some way of ensuring high availability for the SQL infrastructure.
- If you are testing your disaster recovery failover process, shut down XenMobile servers in the primary site to simulate site failure.
- Change public DNS records for the XenMobile servers to point to the disaster recovery site’s external IP addresses.
- Change internal DNS record for the SQL Server to point to the disaster recovery site’s SQL Server IP address.
- Bring XenMobile SQL databases online at the disaster recovery site. Ensure that the SQL Server and database is active and ready to service connections from the XenMobile servers local to the site.
- Turn on the XenMobile servers on the disaster recovery site.
Follow these steps any time you update XenMobile with patches and releases, in order to keep the code of the primary and disaster recovery servers uniform.
- Ensure that XenMobile servers in primary site have been patched or upgraded.
- Ensure that DNS record for the SQL Server is resolving to the active SQL Server database in the primary site.
- Bring the disaster recovery site’s XenMobile servers online. The servers connect to the primary site’s database across the WAN during the upgrade process only.
- Apply required patches and updates to all disaster recovery site’s XenMobile servers.
- Restart the XenMobile servers and confirm that the patch or upgrade is successful.
The following diagram shows the high-level architecture for a disaster recovery deployment of XenMobile.
A key element of this architecture is the use of Global Server Load Balancing (GSLB) to direct traffic to the correct data center.
By default, the NetScaler for XenMobile wizard configures NetScaler Gateway in a way that does not enable the use of GSLB for disaster recovery. Therefore, you must take additional steps.
How GSLB Works
GSLB is at its core a form of DNS. Participating NetScaler appliances act as authoritative DNS servers and resolve DNS records to the correct IP address (typically the VIP that is supposed to receive traffic). The NetScaler appliance checks the system health before responding to a DNS query directing traffic to that system.
When a record is resolved, GSLB’s role in resolving the traffic is complete. The client communicates directly with the target virtual IP (VIP) address. DNS client behavior plays an important part on controlling how and when a record expires. This is largely outside the boundaries of the NetScaler system. As such, GSLB is subject to the same limitations as DNS name resolution. Clients cache responses; thus, load balancing in this way isn’t as real-time as is traditional load balancing.
The GSLB configuration on NetScaler, including sites, services, and monitors, exist in order to provide the correct DNS name resolution.
The actual configuration for publishing servers (in this scenario, the configuration that the NetScaler for XenMobile wizard creates) is not affected by the GSLB. GSLB is a separate service on the NetScaler.
Challenges with Domain Delegation When Using GSLB with XenMobile
The NetScaler for XenMobile wizard configures NetScaler Gateway for XenMobile. This wizard generates three load balancing virtual servers and a NetScaler Gateway virtual server.
Two of the load balancing virtual servers handle MDM traffic, on port 443 and 8443. NetScaler Gateway receives MAM traffic and forwards it to the third server, the MAM load balancing virtual server, on port 8443. All traffic to the MAM load balancing virtual server is passed through NetScaler Gateway.
The MAM load balancing virtual server requires the same SSL certificate as the XenMobile servers and uses the same FQDN as used to enroll devices. The MAM load balancing server also uses the same port (8443) as one of the MDM load balancing servers. To enable traffic to be resolved, the NetScaler for XenMobile wizard creates a local DNS record on NetScaler Gateway. The DNS record matches the FQDN used to enroll devices.
This configuration is effective when the XenMobile server URL is not a GSLB domain URL. If a GSLB domain URL is used as the XenMobile server URL, as is required for disaster recovery, the local DNS record prevents NetScaler Gateway from resolving traffic to the MDM load balancing servers.
Using the CNAME Method for GSLB Disaster Recovery
To address the challenges presented by the default configuration created by the NetScaler for XenMobile wizard, you can create a CNAME record for the XenMobile server FQDN in the parent domain (
company.com) and point a record in the delegated subzone (
gslb.company.com) for which NetScaler is authoritative. Doing so allows for the creation of the static DNS A record for the MAM load balancing VIP address required to resolve traffic.
On the external DNS, create a CNAME for the XenMobile server FQDN that points to the GSLB domain FQDN on NetScaler GSLB. You need two GSLB domains: One for MDM traffic and another for MAM (NetScaler Gateway) traffic.
CNAME = xms.company.com IN CNAME xms.gslb.comany.com
On the NetScaler Gateway instance of each site, create a GSLB virtual server with a FQDN that is what the CNAME record is pointing to.
bind gslb vserver xms-gslb -domainName xms.gslb.company.com
When using the NetScaler for XenMobile wizard to deploy NetScaler Gateway, use the XenMobile server URL when configuring the MAM load balancing server. This creates a static DNS A record for the XenMobile server URL.
Test with clients enrolling on Secure Hub using the XenMobile server URL (
This example uses the following FQDNs:
xms.company.comis the URL that is used by the MDM traffic and is used by devices enrolling, which is configured in this example by using the NetScaler for XenMobile wizard.
xms.gslb.company.comis the GSLB domain FQDN for the XenMobile server.