Product Documentation

XenMobile NetScaler Connector

XenMobile NetScaler Connector provides a device-level authorization service of ActiveSync clients to NetScaler acting as a reverse proxy for the Exchange ActiveSync protocol. Authorization is controlled by a combination of policies that you define within XenMobile and by rules defined locally by XenMobile NetScaler Connector.

For more information, see ActiveSync Gateway.

For a detailed reference architecture diagram, see Architecture.

The current release of XenMobile NetScaler Connector is version 8.5.1.11.

What’s new in the current release

  • System requirement change: The current version of NetScaler Connector requires Microsoft .NET Framework 4.5.

  • Google Analytics support: We want to know how you use XenMobile NetScaler Connector so we can focus on where we can make the product better.

  • Support for TLS 1.1 and 1.2: Due to its weakening security, TLS 1.0 is being deprecated by the PCI Council. Support for TLS 1.1 and 1.2 is added to XenMobile NetScaler Connector.

Monitoring XenMobile NetScaler Connector

The XenMobile NetScaler Connector configuration utility provides detailed logging that you can use to view all traffic passing through your Exchange Server that is either allowed or blocked by Secure Mobile Gateway.

Use the Log tab to view the history of the ActiveSync requests forwarded to XenMobile NetScaler Connector by NetScaler for authorization.

Also, to ensure that the XenMobile NetScaler Connector web service is running, load the following URL into a browser on the XenMobile NetScaler Connector server http://<host:port>/services/ActiveSync/Version. If the URL returns the product version as a string, the web service is responsive.

To simulate ActiveSync traffic with XenMobile NetScaler Connector

You can use the XenMobile NetScaler Connector to simulate what ActiveSync traffic will look like in conjunction with your policies. In the XenMobile NetScaler Connector configuration utility, select the Simulator tab. The results show you how your policies will apply according to the rules you have configured.

Choosing filters for XenMobile NetScaler Connector

The XenMobile NetScaler Connector filters work by analyzing a device for a given policy violation or property setting. If the device meets the criteria, the device is placed in a Device List. This Device List is neither an allow list or a block list. It is a list of devices that meet the criteria defined. The following filters are available for XenMobile NetScaler Connector within XenMobile. The two options for each filter are Allow or Deny.

  • Anonymous Devices: Allows or denies devices that are enrolled in XenMobile but the user’s identity is unknown. For example, this could be a user who was enrolled, but the user’s Active Directory password is expired, or a user who enrolled with unknown credentials.
  • Failed Samsung KNOX attestation: Samsung devices have functionality for security and diagnostics. This filter provides confirmation that the device is setup for KNOX. For details, see the XenMobile Service article on Samsung KNOX.
  • Forbidden Apps: Allows or denies devices based on the Device List defined by blacklist policies and the presence of blacklisted apps.
  • Implicit Allow/Deny: Creates a Device List of all devices that do not meet any of the other filter rule criteria and allows or denies based on that list. The Implicit Allow/Deny option ensures that the XenMobile NetScaler Connector status in the Devices tab is enabled and shows the XenMobile NetScaler Connector status for your devices. The Implicit Allow/Deny option also controls all of the other XenMobile NetScaler Connector filters that have not been selected. For example, Blacklists Apps will be denied (blocked) by XenMobile NetScaler Connector, whereas all other filters will be allowed because the Implicit Allow/Deny option is set to Allow.
  • Inactive devices: Creates a Device List of devices that have not communicated with XenMobile within a specified period of time. These devices are considered inactive. The filter allows or denies the devices accordingly.
  • Missing required apps: When a user enrolls, the user receives a list of required apps that must be installed. The missing required apps filter indicates that one or more of the apps is no longer present; for example, the user deleted one or more apps.
  • Non-Suggested Apps: When a user enrolls, the user receives a list of the apps they should install. The non-suggested apps filter checks the device for apps that are not in that list.
  • Noncompliant password: Creates a Device List of all devices that do not have a passcode on the device.
  • Out of Compliance Devices: Allows you to deny or allow devices that meet your own internal IT compliance criteria. Compliance is an arbitrary setting defined by the device property named Out of Compliance, which is a Boolean flag that can be either True or False. (You can create this property manually and set the value, or you can use Automated Actions to create this property on a device if the device does or does not meet specific criteria.)
    • Out of Compliance = True. If a device does not meet the compliance standards and policy definitions set by your IT department, the device is out of compliance.
    • Out of Compliance = False. If a device does meet the compliance standards and policy definitions set by your IT department, the device is compliant.
  • Revoked Status: Creates a Device List of all revoked devices and allows or denies based on revoked status.
  • Rooted Android/Jailbroken iOS Devices. Creates a Device List of all devices flagged as rooted and allows or denies based on rooted status.
  • Unmanaged Devices. Creates a Device List of all devices in the XenMobile database. The Mobile Application Gateway needs to be deployed in a Block Mode.

To configure a connection to XenMobile NetScaler Connector

XenMobile NetScaler Connector communicates with XenMobile and other remote configuration providers through secure web services.

  1. In the XenMobile NetScaler Connector configuration utility, click the Config Providers tab and then click Add.
  2. In the Config Providers dialog box, in Name, enter a user name that has administrative privileges and are used for basic HTTP authorization with the XenMobile server.
  3. In Url, enter the web address of the XenMobile GCS, typically in the format https://<FQDN>/<instanceName>/services/<MagConfigService>. The MagConfigService name is case-sensitive.
  4. In Password, enter the password that will be used for basic HTTP authorization with the XenMobile server.
  5. In Managing Host, enter the XenMobile NetScaler Connector server name.
  6. In Baseline Interval, specify a time period for when a new refreshed dynamic ruleset is pulled from Device Manager.
  7. In Delta interval, specify a time period for when an update of dynamic rules is pulled.
  8. In Request Timeout, specify the server request timeout interval.
  9. In Config Provider, select if the configuration provider server instance is providing the policy configuration.
  10. In Events Enabled, enable this option if you want XenMobile NetScaler Connector to notify XenMobile when a device is blocked. This option is required if you are using the XenMobile NetScaler Connector rules in any of your XenMobile Automated Actions.
  11. Click Save and then click Test Connectivity to test gateway-to-configuration provider connectivity. If the connection fails, check that the local firewall settings allow the connection or contact your administrator.
  12. When the connection succeeds, clear the Disabled check box and then click Save.

When you add a new configuration provider, XenMobile NetScaler Connector automatically creates one or more policies associated with the provider. These policies are defined by a template definition contained in config\policyTemplates.xml in the NewPolicyTemplate section. For each Policy element defined within this section, a new policy is created.

The operator may add, remove, or modify policy elements if the following is true: The policy element conforms to the schema definition and the standard substitution strings (enclosed in braces) are not modified. Next, add new groups for the provider and update the policy to include the new groups.

To import a policy from XenMobile

  1. In the XenMobile NetScaler Configuration configuration utility, click the Config Providers tab and then click Add.
  2. In the Config Providers dialog box, in Name, enter a user name that will be used for basic HTTP authorization with the XenMobile server and that has administrative privileges.
  3. In Url, enter the web address of the XenMobile Gateway Configuration Service (GCS), typically in the format https://<xdmHost>/xdm/services/<MagConfigService>. The MagConfigService name is case-sensitive.
  4. In Password, enter the password that is used for basic HTTP authorization with the XenMobile server.
  5. Click Test Connectivity to test gateway-to-configuration provider connectivity. If the connection fails, check that your local firewall settings allow the connection or check with your administrator.
  6. When a connection is successfully made, clear the Disabled check box and then click Save.
  7. In Managing Host, leave the default DNS name of the local host computer. This setting used to coordinate communication with XenMobile when multiple Forefront Threat Management Gateway (TMG) servers are configured in an array.

    After you save the settings, open the GCS.

Configuring XenMobile NetScaler Connector policy mode

XenMobile NetScaler Connector can run in the following six modes:

  • Allow All. This policy mode grants access for all traffic passing through XenMobile NetScaler Connector. No other filtering rules are used.
  • Deny All. This policy mode blocks access for all traffic passing through XenMobile NetScaler Connector. No other filtering rules are used.
  • Static Rules: Block Mode. This policy mode executes static rules with an implicit deny or block statement at the end. XenMobile NetScaler Connector blocks devices that are not allowed or permitted via other filter rules.
  • Static Rules: Permit Mode. This policy mode executes static rules with an implicit permit or allow statement at the end. Devices that are not blocked or denied via other filter rules are allowed through XenMobile NetScaler Connector.
  • Static + ZDM Rules: Block Mode. This policy mode executes static rules first, followed by dynamic rules from XenMobile with an implicit deny or block statement at the end. Devices are permitted or denied based on defined filters and Device Manager rules. Any devices that do not match on defined filters and rules are blocked.
  • Static + ZDM Rules: Permit Mode. This policy mode executes static rules first, followed by dynamic rules from XenMobile with an implicit permit or allow statement at the end. Devices are permitted or denied based on defined filters and XenMobile rules. Any devices that do not match on defined filters and rules are allowed.

The XenMobile NetScaler Connector process permits or blocks for dynamic rules based on unique ActiveSync IDs for iOS and Windows-based mobile devices received from XenMobile. Android devices differ in their behavior based on the manufacturer and some do not readily expose a unique ActiveSync ID. To compensate, XenMobile sends user ID information for Android devices to make a permit or block decision. As a result, if a user has only one Android device, permits and blocks function normally. If the user has multiple Android devices, all the devices are allowed because Android devices cannot be differentiated. You can configure the gateway to statically block these devices by ActiveSyncID, if they are known. You can also configure the gateway to block based on device type or user agent.

To specify the policy mode, in the SMG Controller Configuration utility, do the following:

  1. Click the Path Filters tab and then click Add.
  2. In the Path Properties dialog box, select a policy mode from the Policy list and then click Save.

You can review rules on the Policies tab of the configuration utility. The rules are processed on XenMobile NetScaler Connector from top to bottom. The Allow policies are displayed with green check mark. The Deny policies are shown as a red circle with a line through it. To refresh the screen and see the most updated rules, click Refresh. You can also modify the ordering of rules in the config.xml file.

To test rules, click the Simulator tab. Specify values in the fields. These can also be obtained from the logs. A result message will appear specifying Allow or Block.

To configure static rules

Enter static rules with values that the ISAPI filtering of the ActiveSync connection HTTP requests reads. Static rules enable XenMobile NetScaler Connector to permit or block traffic by the following criteria:

  • User. XenMobile NetScaler Connector uses the authorized user value and name structure that was captured during device enrollment. This is commonly found as domain\username as referenced by the server running XenMobile connected to Active Directory via LDAP. The Log tab within the XenMobile NetScaler Connector configuration utility shows the values that are passed through XenMobile NetScaler Connector. The values are passed if the value structure needs to be determined or is different.
  • Deviceid (ActiveSyncID). Also known as the ActiveSyncID of the connected device. This value is commonly found within the specific device properties page in the XenMobile console. This value can also be screened from the Log tab in the XenMobile NetScaler Connector configuration utility.
  • DeviceType. XenMobile NetScaler Connector can determine if a device is an iPhone, iPad, or other device type and can permit or block based on that criteria. As with other values, the XenMobile NetScaler Connector configuration utility can reveal all connected device types being processed for the ActiveSync connection.
  • UserAgent. Contains information on the ActiveSync client that is used. In most cases, the value specified corresponds to a specific operating system build and version for the mobile device platform.

The XenMobile NetScaler Connector configuration utility running on the server always manages the static rules.

  1. In the SMG Controller Configuration utility, click the Static Rules tab and then click Add.
  2. In the Static Rule Properties dialog box, specify the values that you want to use as criteria. For example, you can enter a user to allow access by entering the user name (for example, AllowedUser) and then clearing the Disabled check box.
  3. Click Save.

    The static rule is now in effect. Additionally, you can use regular expressions to define values, but you must enable the rule processing mode in the config.xml file.

To configure dynamic rules

Device policies and properties in Device Manager define dynamic rules and can trigger a dynamic XenMobile NetScaler Connector filter. The triggers are based on the presence of a policy violation or property setting. The XenMobile NetScaler Connector filters work by analyzing a device for a given policy violation or property setting. If the device meets the criteria, the device is placed in a Device List. This Device List is not an allow list or a block list. It is a list of devices that meets the criteria defined. The following configuration options enable you to define whether you want to allow or deny the devices in the Device List by using XenMobile NetScaler Connector.

Note:

You must use the XenMobile console to configure dynamic rules.

  1. In the XenMobile console, click the gear icon in the upper-right corner. The Settings page appears.

  2. Under Server, click ActiveSync Gateway. The ActiveSync Gateway page appears.

  3. In Activate the following rules, select one or more rules you want to activate.

  4. In Android-only, in Send Android domain users to ActiveSync Gateway, click YES to ensure that XenMobile sends Android device information to the Secure Mobile Gateway.

    When this option is enabled, XenMobile sends Android device information to the XenMobile NetScaler Connector when XenMobile does not have the ActiveSync identifier for the Android device user.

To configure custom policies by editing the XenMobile NetScaler Connector XML file

You can view the basic policies in the default configuration on the Policies tab of the XenMobile NetScaler Connector configuration utility. If you want to create custom policies, you can edit the XenMobile NetScaler Connector XML configuration file (config\config.xml).

  1. Find the PolicyList section in the file and then add a new Policy element.
  2. If a new group is also required, such as another static group or a group to support another GCP, add the new Group element to the GroupList section.
  3. Optionally, you can change the ordering of groups within an existing policy by rearranging the GroupRef elements.

Configuring the XenMobile NetScaler Connector XML File

The XenMobile NetScaler Connector uses an XML configuration file to dictate the actions of XenMobile NetScaler Connector. Among other entries, the file specifies the group files and associated actions the filter take when evaluating HTTP requests. By default, the file is named config.xml and can be found at the following location: ..\Program Files\Citrix\XenMobile NetScaler Connector\config.

GroupRef Nodes

The GroupRef nodes define the logical group names. The defaults are AllowGroup and DenyGroup.

Note:

The order of the GroupRef nodes as they appear in the GroupRefList node is significant.

The ID value of a GroupRef node identifies a logical container or collection of members that are used for matching specific user accounts or devices. The action attributes specifies how the filter treats a member that matches a rule in the collection. For example, a user account or device that matches a rule in the AllowGroup set will “pass.” To pass means to be allowed to access the Exchange CAS. A user account or device that matches a rule in the DenyGroup set is “rejected.” Rejected means not to be allowed to access the Exchange CAS.

When a particular user account/device or combination meets rules in both groups, a precedence convention is used to direct the request’s outcome. Precedence is embodied in the order of the GroupRef nodes in the config.xml file from top to bottom. The GroupRef nodes are ranked in priority order. Rules for a given condition in the Allow group will always take precedence over rules for the same condition in the Deny group.

Group Nodes

Additionally, the config.xml defines Group nodes. These nodes link the logical containers AllowGroup and DenyGroup to external XML files. Entries stored in the external files form the basis of the filter rules.

Note:

In this release, only external XML files are supported.

The default installation implements two XML file in the configuration: allow.xml and deny.xml.

Configuring XenMobile NetScaler Connector

You can configure XenMobile NetScaler Connector to selectively block or allow ActiveSync requests based on the following properties: Active Sync Service ID, Device type, User Agent (device operating system), Authorized user, and ActiveSync Command.

The default configuration supports a combination of static and dynamic groups. You maintain static groups by using the SMG Controller Configuration utility. The static groups may consist of known categories of devices, such as all devices using a given user agent.

An external source called a Gateway Configuration Provider maintains dynamic groups. XenMobile NetScaler Connector connects the groups on a periodic basis. XenMobile can export groups of allowed and blocked devices and users to XenMobile NetScaler Connector.

Dynamic groups are maintained by an external source called a Gateway Configuration Provider and collected by XenMobile NetScaler Connector on a periodic basis. XenMobile can export groups of allowed and blocked devices and users to XenMobile NetScaler Connector.

A policy is an ordered list of groups in which each group has an associated action (allow or block) and a list of group members. A policy may have any number of groups. Group ordering within a policy is important because when a match is found the action of the group is taken, and subsequent groups are not evaluated.

A member defines a way to match the properties of a request. It can match a single property, such as device ID, or multiple properties, such as device type and user agent.

Choosing a Security Model for XenMobile NetScaler Connector

Establishing a security model is essential to a successful mobile device deployment for organizations of any size. It is common to use protected or quarantined network control to allow access to a user, computer, or device by default. This practice is not always ideal. Every organization that manages IT security may have a slightly different or tailored approach to security for mobile devices.

The same logic applies to mobile device security. Using a permissive model is a weak choice due to the multitude of mobile devices and types, mobile devices per user, and available operating system platforms and apps. In most organizations, the restrictive model will be the most logical choice.

The configuration scenarios that Citrix allows for integrating XenMobile NetScaler Connector with XenMobile are as follows:

Permissive Model (Permit Mode)

The permissive security model operates on the premise that everything is either allowed or granted access by default. Only through rules and filtering is something blocked and a restriction applied. The permissive security model is good for organizations that have a relatively loose security concern about mobile devices. The model only applies restrictive controls to deny access where appropriate (when a policy rule is failed).

Restrictive Model (Block Mode)

The restrictive security model is based on the premise that nothing is allowed or granted access by default. Everything passing through the security check point is filtered and inspected, and is denied access unless the rules allowing access are passed. The restrictive security model is good for organizations that have a relatively tight security criterion about mobile devices. The mode only grants access for use and functionality with the network services when all rules to allow access have passed.

Managing XenMobile NetScaler Connector

You can use XenMobile NetScaler Connector to build access control rules. The rules either allow or block access to ActiveSync connection requests from managed devices. Access is based on device status, app blacklists or whitelists, and other compliance conditions.

By using the XenMobile NetScaler Connector configuration utility, you can build dynamic and static rules that enforce corporate email policies, allowing you to block users who are in violation of compliance standards. You can also set up email attachment encryption, so that all attachments that pass through your Exchange Server to managed devices are encrypted and only viewable on managed devices by authorized users.

To uninstall the XNC

  1. Run XncInstaller.exe with an administrator account.
  2. Follow the onscreen instructions to complete the uninstallation.

To install, upgrade, or uninstall XenMobile NetScaler Connector

  1. Run XncInstaller.exe with an administrator account to install XenMobile NetScaler Connector or allow for upgrade or removal of an existing XenMobile NetScaler Connector.
  2. Follow the onscreen instructions to complete the installation, upgrade, or uninstallation.

After you install XenMobile NetScaler Connector, you must manually restart the XenMobile configuration service and the notification service.

Installing XenMobile NetScaler Connector

You can install XenMobile NetScaler Connector on its own server or on the same server where you installed XenMobile.

You can consider installing XenMobile NetScaler Connector on its own server (separate from XenMobile) for the following reasons:

  • If your XenMobile server is hosted remotely in the cloud (physical location).
  • If you do not want XenMobile NetScaler Connector to be affected by restarts of the XenMobile server (availability).
  • If you want a server’s system resources to be devoted entirely to XenMobile NetScaler Connector (performance).

The CPU load that XenMobile NetScaler Connector puts on a server depends on how many devices are managed. A general rule of thumb is to provision for one more CPU core if XenMobile NetScaler Connector is deployed on the same server as XenMobile. For large numbers of devices (more than 50,000), you may need to provision more cores if you do not have a clustered environment. The memory footprint of XenMobile NetScaler Connector is not significant enough to warrant more memory.

XenMobile NetScaler Connector system requirements

XenMobile NetScaler Connector communicates with NetScaler over an SSL bridge configured on the NetScaler appliance. The bridge enables the appliance to bridge all secure traffic directly to XenMobile. XenMobile NetScaler Connector requires the following minimum system configuration:

Component Requirement
Computer and processor 733 MHz Pentium III 733 MHz or higher processor. 2.0 GHz Pentium III or higher processor (recommended)
NetScaler NetScaler appliance with software version 10
Memory 1 GB
Hard disk NTFS-formatted local partition with 150 MB of available hard-disk space
Operating system Microsoft Windows Server 2008 R2, Microsoft Windows Server 2008 SP2, Microsoft Windows Server 2012 R2
Other devices Network adapter compatible with the host operating system for communication with the internal network
Microsoft .NET Framework Version 8.5.1.11 requires Microsoft .NET Framework 4.5.
Display VGA or higher-resolution monitor

The host computer for XenMobile NetScaler Connector requires the following minimum available hard disk space:

  • Application: 10 - 15 MB (100 MB recommended)
  • Logging: 1 GB (20 GB recommended)

For information about platform support for XenMobile NetScaler Connector, see Supported device operating systems.

Device email clients

Not all email clients consistently return the same ActiveSync ID for a device. Because XenMobile NetScaler Connect expects a unique ActiveSync ID for each device, the following is true: Only email clients that consistently generate the same, unique ActiveSync ID for each device are supported. Citrix has tested these email clients and the clients have performed without errors:

  • HTC native email client
  • Samsung native email client
  • iOS native email client
  • TouchDown

Deploying XenMobile NetScaler Connector

XenMobile NetScaler Connector enables you to use NetScaler to proxy and load balance XenMobile server communication with XenMobile managed devices. XenMobile NetScaler Connector communicates periodically with XenMobile to synchronize policies. XenMobile NetScaler Connector and XenMobile can be clustered, together or independently, and can be load-balanced by NetScaler.

XenMobile NetScaler Connector components

  • XenMobile NetScaler Connector service: This service provides a REST web service interface that can be invoked by NetScaler to determine if an ActiveSync request from a device is authorized.
  • XenMobile configuration service: This service communicates with Device Manager to synchronize Device Manager policy changes with XenMobile NetScaler Connector.
  • XenMobile notification service: This service sends notifications of unauthorized device access to Device Manager. In this way, Device Manager can take appropriate measures, such as notifying the user why the device was blocked.
  • XenMobile NetScaler configuration utility: This application allows the administrator to configure and monitor XenMobile NetScaler Connector.

To set up listening addresses for XenMobile NetScaler Connector

For XenMobile NetScaler Connector to receive requests from NetScaler to authorize ActiveSync traffic, do the following. Specify the port on which XenMobile NetScaler Connector listens to NetScaler web service calls.

  1. From the Start menu, select the XenMobile NetScaler configuration utility.
  2. Click the Web Service tab and then type the listening addresses for the XenMobile NetScaler Connector web service. You can select HTTP or HTTPS or both. If XenMobile NetScaler Connector is co-resident with XenMobile (installed on the same server), select port values that do not conflict with XenMobile.
  3. After the values are configured, click Save and then click Start Service to start the web service.

To configure device access control policies in XenMobile NetScaler Connector

To configure the access control policy you want to apply to your managed devices, do the following:

  1. In the XenMobile NetScaler configuration utility, click the Path Filters tab.
  2. Select the first row, Microsoft-Server-ActiveSync is for ActiveSync and then click Edit.
  3. From the Policy list, select the desired policy. For a policy that is inclusive of XenMobile policies, select Static + ZDM: Permit Mode or Static + ZDM: Block Mode. These policies combine local (or, static) rules with the rules from XenMobile. Permit Mode means that all devices not explicitly identified by the rules are permitted access to ActiveSync. Block Mode means that such devices are blocked.
  4. After setting the policies, click Save.

To configure communication with XenMobile

Specify the name and properties of the XenMobile server (also known as a Config Provider) that you want to use with XenMobile NetScaler Connector and NetScaler.

Note: This task assumes that you have already installed and configured XenMobile.

  1. In the XenMobile NetScaler Connector configuration utility, click the Config Providers tab and then click Add.
  2. Enter the name and URL of the XenMobile server you are using in this deployment. If youhave multiple XenMobile servers deployed in a multi-tenant deployment, this name must be unique for each server instance. For example, for Name, you could type XMS.
  3. In Url, enter the Web address of the XenMobile GlobalConfig Provider (GCP), typically in the format https://<FQDN>/<instanceName>/services/<MagConfigService>. The MagConfigService name is case-sensitive.
  4. In Password, enter the password that will be used for basic HTTP authorization with the XenMobile web server.
  5. In Managing Host, enter the server name where you installed XenMobile NetScaler Connector.
  6. In Baseline Interval, specify a time period for when a new refreshed dynamic ruleset is pulled from XenMobile.
  7. In Request Timeout, specify the server request timeout interval.
  8. In Config Provider, select if the config provider server instance is providing the policy configuration.
  9. In Events Enabled, enable this option if you want Secure Mobile Gateway to notify XenMobile when a device is blocked. This option is required if you are using Secure Mobile Gateway rules in any of your Device Manager Automated Actions.
  10. After configuring the server, click Test Connectivity to test the connection to XenMobile.
  11. When connectivity has been established, click Save.

Deploying XenMobile NetScaler Connector for redundancy and scalability

If you want to scale your XenMobile NetScaler Connector and XenMobile deployment, you can install instances of XenMobile NetScaler Connector on multiple Windows Servers, all pointing to the same XenMobile instance, and then you can use NetScaler to load balance the servers.

There are two modes for the XenMobile NetScaler Connector configuration:.

  • In non-shared mode, each XenMobile NetScaler Connector instance communicates with a XenMobile server and keeps its own private copy of the resulting policy. For example, if you had a cluster of XenMobile servers, you could run a XenMobile NetScaler Connector instance on each XenMobile server and XenMobile NetScaler Connector would get policies from the local XenMobile instance.
  • In shared mode, one XenMobile NetScaler Connector node is designated the primary node and it communicates with XenMobile. The resulting configuration is shared among the other nodes either by a Windows network share or by Windows (or third-party) replication.

The entire XenMobile NetScaler Connector configuration is in a single folder (consisting of a few XML files). The XenMobile NetScaler Connector process detects changes to any file in this folder and automatically reloads the configuration. There is no failover for the primary node in shared mode. But the system can tolerate the primary server being down for a few minutes (for example, to restart) because the last known good configuration is cached in the XenMobile NetScaler Connector process.