Known Issues

Known Issues

The following are known issues for the XenMobile 10 MDM Upgrade Tool:

• The XenMobile lockout limit value is not migrated. After migration, reset the value. [#545770]
• Options in role-based access control (RBAC) roles do not migrate cleanly. After migration, review RBAC roles and make any necessary adjustments. [#543183]
• Log settings do not migrate. After migration, re-configure log settings in the XenMobile console. [#541869]
• When a configuration with multiple LDAP configurations in which only one LDAP configuration to support nested groups is migrated, after migration, nested groups support is enabled on all LDAPs you configured. In addition, groups synchronization happens on all LDAP servers during server start-up. [#540713]
• When a Web Content Filter device policy contains URLs without HTTP/HTTPS, the URL is deleted when users edit the URL and then cancel the operation. After migration, make sure all URLs contain HTTP or HTTPS to prevent deletion when canceling an edit operation. [#540025]
• When policies, apps, or actions are included in multiple packages with different rules, deployment rules do not migrate. This behavior is as designed. [#539517]
• The XenMobile 9.0 administrator cannot log on to the XenMobile 10 console after successful migration when the administrator user name contains an uppercase character. Before migration, create an administrator user account with all lowercase letters and with all permissions enabled so that after migration you can use that account to log on to the XenMobile 10 console. [#547422]
• If Multi-Tenant Console (MTC) is enabled on XenMobile 9, MTC cannot be migrated to XenMobile 10. [#549969]
• The Super Admin role created in XenMobile 9.0 does not migrate several setting and assignment permissions in XenMobile 10. After migration, in the XenMobile 10 console, go to Configure > Settings > Role Based Access Control and recreate the XenMobile 9.0 Super Admin role with permissions from the XenMobile 10 Admin role. [#553079]
• Deployment package names created in XenMobile 9.0 with special characters (:, !, $, (), #, % , +, *, ~, ?, |, {}, and []) cannot be edited after migration. In addition, local users and local groups created in XenMobile 9.0 that contain an open square bracket ([) cause problems in XenMobile 10 when creating enrollment invitations. Before migration, remove all special characters from Deployment Package names as well as open square brackets from local user and local group names. [#538639]

Enabling and Running the XenMobile 10 MDM Upgrade Tool

These are the basic steps you follow to upgrade from XenMobile 9.0 to XenMobile 10:

1. Configure the XenMobile 10 instance using the command-line console.
2. Meet all Upgrade Tool prerequisites. For details, see .
3. Update the Upgrade Tool to the latest version. Important: Clear your browser cache after the system restarts.
4. Start the Upgrade Tool in Firefox or Chrome.
5. Upload the copied XenMobile 9.0 files to the Upgrade Tool.
6. Enter the XenMobile 9.0 certificate password.
7. Allow the Upgrade Tool to run.
8. Restart the XenMobile 10 server.
9. Log on to the XenMobile 10 console.
10. Configure licenses on XenMobile 10 to allow users to connect.
11. For a production upgrade, change the external DNS for XenMobile to point to the new XenMobile 10 server.
12. For a production upgrade if you are using a load balancing NetScaler, remove the XenMobile 9.0 server IP and add the XenMobile 10 server IP.

Internet Connection

Internet Connection

• Intranet – Alternatively, the HDX session over which their virtual desktop will be delivered may be transported across the Enterprise WAN and proxied by the same NetScaler Gateway where they authenticated. The advantage of this approach is that a significant portion of the HDX traffic would traverse the Enterprise network where quality of service may be used to provide an optimal user experience. Therefore, this is the recommended dynamic method provided the network assessment identifies that sufficient bandwidth is available or that the project allows for it to be provisioned and that an appropriate QoS infrastructure is in place or may be configured.

Resource Layer

The resource layer is the third layer of the design methodology and the final layer focused specifically on the user groups. The overall user acceptance of the solution is defined by the decisions made within the resource layer. Personalization, applications and overall desktop image design play a pivotal role in how well the desktop is aligned with the user group’s requirements, which were identified within the user data capture and application data capture sections of the assess phase.

Personalization

User Profiles

A user’s profile plays a critical role in determining how successful the user experience is within a virtual desktop or virtual application scenario. Even a well-designed virtual desktop solution can fail if users are frustrated due to lengthy logon times or lost settings. The user profile solution chosen must align with the personalization characteristics of the user group captured during the assess phase

as well as the FlexCast model selected.

Decision: Profile Type

This section provides an overview on the different profile types available and provides guidance on the optimal user profile for each FlexCast model.

• Local profiles – Local profiles are stored on each server or desktop operating system and are initially created based on the default user profile. Therefore, a user accessing these resources would create an independent profile on each system. Users are able to retain changes to their local profile on each individual system, but changes are only accessible for future sessions on that system. Local profiles require no configuration; if a user logging into a server or desktop operating system does not have a profile path administratively defined, a local profile is created by default.

• Roaming profiles – Roaming profiles are stored in a centralized network repository for each user. Roaming profiles differ from local profiles in that the information in the profile (whether it is a printer, a registry setting, or a file stored in the documents folder) can be made available to user sessions accessed from all systems in the environment. Configuring a user for a roaming profile requires an administrator to designate the user’s profile path (for virtual desktops) or terminal server profile path to a particular network share. The first time the user logs on to a server or desktop operating system, the default user profile is used to create the user’s roaming profile. During logoff, the profile is copied to the administrator-specified network location.

• Mandatory profiles – Mandatory profiles are typically stored in a central location for many users. However, the user’s changes are not retained at logoff. Configuring a user for a mandatory profile requires an administrator to create a mandatory profile file (NTUSER.MAN) from an existing roaming or local profile and assign users’ with a terminal services profile path. This can be achieved by means of Microsoft Group Policy, customizing the user properties in Active Directory or Citrix Profile Management.

• Hybrid profiles – Hybrid profiles combine a robust profile core (a mandatory profile or a local default profile) with user specific registry keys or files that are merged during logon. This technique enables administrators to tightly control which changes are retained and to keep the user profiles small in size. Furthermore, hybrid profiles address the last write wins issue using mature queuing techniques that automatically detect and prevent simultaneous writes that could potentially overwrite changes made in another session. Thus minimizing, user frustration resulting from lost profile changes when accessing multiple servers or virtual desktops simultaneously. In addition, they capture and record only the changes within the profile, rather than writing the entire profile at logoff. A good example of a hybrid profile solution is Citrix Profile Management, which will be discussed in detail within this chapter.

In order to select the optimal profile type for each user group it is important to understand their personalization requirements in addition to the FlexCast model assigned.

NetScaler Gateway

NetScaler Gateway

User groups utilizing NetScaler Gateway as their authentication point have additional access layer design decisions that must be considered. These design decisions are not applicable for non-

NetScaler Gateway authentication points.

Decision: Topology

Selection of the network topology is central to planning the remote access architecture to ensure that it can support the necessary functionality, performance and security. The design of the remote

access architecture should be completed in collaboration with the security team to ensure adherence to corporate security requirements. There are two primary topologies to consider, each of which provides increasing levels of security:

• 1-Arm (normal security) - With a 1-arm topology, the NetScaler utilizes one physical or logical bonded interface, with associated VLAN and IP subnet, to transport both fronted traffic for users and backend traffic for the virtual desktop infrastructure servers and services.

• 2-Arm (high security) – With a 2-arm topology, the NetScaler Gateway utilizes two or more physically or logically bonded Transport of the frontend traffic for users is directed to one of these interfaces. The frontend traffic is isolated from backend traffic, between the virtual desktop infrastructure servers and services, which is directed to a second interface. This allows the use of separate demilitarized zones (DMZs) to isolate frontend and backend traffic flows along with granular firewall control and monitoring.

Decision: High Availability

If the NetScaler Gateway is unavailable, remote users will not be able to access the Citrix environment. Therefore at least two NetScaler Gateway servers should be deployed to prevent this

component from becoming a single point of failure.

When configuring NetScaler Gateway in a high availability pair, the secondary NetScaler Gateway monitors the first appliance by sending periodic messages, also called a heartbeat message or health check, to determine if the first appliance is accepting connections. If a health check fails, the secondary NetScaler Gateway tries the connection again for a specified amount of time until it determines that the primary appliance is not working. If the secondary appliance confirms the health check failure, the secondary NetScaler Gateway takes over for the primary NetScaler Gateway.

Each NetScaler Gateway appliance must be running the same version of the NetScaler Gateway software and have the same license. For additional considerations when configuring a NetScaler

Gateway high availability pair please reference Citrix eDocs – How High Availability Works.

Decision: Platform

In order to identify an appropriate NetScaler platform to meet project requirements, the key resource constraints must be identified. Since all remote access traffic will be secured using the secure sockets layer (SSL_, transported by Hypertext Transfer Protocol (HTTP) in the form of HTTPs, there are two resource metrics that should be targeted:

• SSL throughput – The SSL throughput is the gigabits of SSL traffic that may be processed per second (Gbps).

• SSL transaction per second (TPS) – The TPS metric identifies how many times per second an Application Delivery Controller (ADC) may execute an SSL transaction. The capacity varies primarily by the key length required. TPS capacity is primarily a consideration during the negotiation phase when SSL is first setup and it is less of a factor in the bulk encryption / decryption phase, which is the majority of the session life. While TPS is an important metric to monitor, field experience has shown that SSL Throughput is the most significant factor in identifying the appropriate NetScaler Gateway.

For more information, please refer to the Citrix white paper – Best Practices for Implementing 2048-bit SSL.

The SSL bandwidth overhead average is often considered negligible relative to the volume of virtual desktop traffic and is not typically accounted for as part of required SSL Throughput. However making provisions for SSL bandwidth will help ensure the total throughput estimated is sufficient. The fixed bandwidth added to packet headers can vary according to the encryption algorithms used and the overall percentage of bandwidth may vary widely according to packet size. Ideally, the overhead should be measured during a proof of concept or pilot. However, in the absence of such

data incrementing the workload bandwidth by 2% is a reasonable rule of thumb. Therefore, to determine the SSL throughput required by a NetScaler platform, multiply the maximum concurrent

bandwidth for a datacenter by 1.02:

For example, assuming 128Mbps maximum concurrent bandwidth, the appropriate NetScaler model can be determined as follows:

The SSL throughput value should be compared to the throughput capabilities of various NetScaler platforms to determine the most appropriate one for the environment. There are three main platform

groups available, each of which provides broad scalability options.

• VPX – A NetScaler VPX device provides the same full functionality as hardware NetScaler. However, NetScaler VPXs can leverage ‘off the shelf’ servers for hosting and are suitable for small to medium sized environments.

• MDX – A NetScaler MDX is the hardware version of the NetScaler devices. The MDX device is more powerful than the virtual NetScaler and can support network optimizations for larger scale

enterprise deployments.

• SDX – A NetScaler SDX is a blend between the virtual and physical NetScaler devices. An SDX machine is a physical device capable of hosting multiple virtual NetScaler devices. This consolidation of devices aids with reducing required shelf space and device consolidation. NetScaler SDXs are suitable for handling network communications for large enterprise deployments.

SSL throughput capabilities of the NetScaler platforms may be found in the Citrix NetScaler data sheet. Therefore, based on the example calculation above, a NetScaler MPX 5500 appliance would be sufficient to handle the required load. However, actually scalability will depend on security requirements. NetScaler SSL throughput decreases with the use of increasingly complex encryption algorithms and longer key lengths. Also, this calculation represents a single primary NetScaler. At a minimum, N+1 redundancy is recommended which would call for an additional NetScaler of the identical platform and model.

Note: The Citrix NetScaler data sheet typically represents throughput capabilities under optimal conditions for performance. However, performance is directly affected by security requirements. For example, if the RC4 encryption algorithm and a 1k key length are used, a VPX platform may be able to handle more than 500 HDX proxy connections. However, if a 3DES encryption algorithm and

2k key length are used (which are becoming more common), the throughput may be halved.

Decision: Pre-Authentication Policy

An optional pre-authentication policy may be applied to user groups with NetScaler Gateway as their authentication point (this design decision is not applicable for non-NetScaler Gateway authentication

points). Pre-authentication policies limit access to the environment based on whether the endpoint meets certain criteria through Endpoint Analysis (EPA) Scans.

Pre-authentication access policies can be configured to test antivirus, firewall, operating system, or even registry settings. These policies are used by XenDesktop to control features such as clipboard mapping, printer mapping and even the availability of specific applications and desktops. For example, if a user device does not have antivirus installed, a filter can be set to hide sensitive

applications.

Load Balancing Traffic on a Citrix NetScaler

Load Balancing Traffic on a Citrix NetScaler

Load balancing improves server fault tolerance and end-user response time. This chapter lists the basic and a few advanced settings that you can configure.

In This Chapter

How Load Balancing Works

Configuring Load Balancing

How Load Balancing Works

The load balancing feature distributes client requests across multiple servers to optimize resource utilization. In a real-world scenario with a limited number of servers providing service to a large number of clients, a server can become overloaded and degrade server performance. A NetScaler uses load balancing criteria to prevent bottlenecks by forwarding each client request to the server best

suited to handle the request when it arrives.

To configure load balancing, you define a virtual server (vserver) to proxy multiple servers in a server farm and balance the load among them. When a client initiates a connection to the server, the vserver terminates the client connection and initiates a new connection with the selected server to perform load balancing. The load balancing feature provides traffic management from Layer 4 (TCP and UDP) through Layer 7 (FTP, HTTP, and HTTPS).

The NetScaler uses a number of algorithms, called load balancing methods, to determine how to distribute the load among the servers. The default load balancing method is the Least Connections method.

The entities that you must configure in a typical load balancing setup are:

• Vserver. An entity that is represented by an IP address, a port, and a protocol. The vserver IP address (VIP) is usually a public IP address. The client sends connection requests to this IP address. The vserver represents a bank of servers.

• Service. An entity that is represented by an IP address, a port, and a protocol. A service is a logical representation of a server or an application running on a server. The services are bound to the vservers.

• Server object. An entity that is represented by an IP address. The server object is created when you create a service. The IP address of the service is taken as the name of the server object. You can also create a server object and then create services by using the server object.

• Monitor. An entity that tracks the health of the services. The NetScaler periodically probes the servers using the monitor bound to each service. If a server does not respond within a specified response timeout, and the specified number of probes fails, the service is marked DOWN. The NetScaler then performs load balancing among the remaining services.

To configure load balancing, you must first create services. Then, you must create vservers and bind services to the vservers. By default, the NetScaler binds a monitor to each service. You can also assign weights to a service. The load balancing method uses the assigned weight to select a service. You need to perform these tasks in the sequence illustrated in the following flow chart.

Prerequisites

Prerequisites

You need to complete the following prerequisites before you run the XenMobile 10 MDM Upgrade Tool.

Citrix License Server

Make sure that you install the 11.12.1 Citrix License Server (available on the page) and that you configure the server with the latest V6 MDM-only license. Ensure that the licensing server ports 27000 and 7279 are open to the server. This step is crucial to prevent unintentionally upgrading users' devices to XenMobile Enterprise mode, which may lead to a licensing violation and also force users to re-enroll their devices.

Database

Migration can only be done between databases of the same type. For example:

Supported

• PostgreSQL to PostgreSQL
• MSSQL to MSSQL

Not supported

• MSSQL to PostgreSQL
• PostgreSQL to MSSQL

During the data migration process, XenMobile needs the ability to access the database solution implemented on XenMobile 9.0 Device Manager. For example, the following ports must be open:

• For Microsoft SQL Server, the default port is 1433.
• For PostgreSQL, the default port is 5432.

To allow remote connections to PostgreSQL, you must complete the following steps:

1. Open the file pg_hba.conf and locate the following line: "host all all 127.0.0.1/32 md5"
2. Append a new line host all all [XMS address/external address]/32 md5
3. Save the file.
4. Stop and start the service.
5. Locate and open the postgresql.conf file and change this line from:

"#listen_addresses = 'localhost'"

to

"listen_addresses = ‘*’"

Note: The line must be uncommented. This can be made restrictive by allowing only XenMobile 9.0 and XenMobile 10 server IPs to access the PostgreSQL database (listen_addresses = '10.x.x.1,10.x.x.2').

     6. Stop and start the PostgreSQL service for changes take effect.

     7. Ensure that XMS and the database are able to communicate with each other. (This also checks that the database is able to accept remote connections.)

If a custom port has been assigned to the database solution, you have to ensure that the port is allowed and open in the firewall protecting XenMobile 9.0 Device Manager. Doing so enables XenMobile 10 to connect to the database and to migrate the required information.

External SSL certificate

External SSL certificates must meet the conditions outlined in . Be sure to review your pki.xml before starting the migration to ensure that the SSL certificate meets those conditions.

Administrator account user name

The administrator account used to log on to the XenMobile 10 console can contain only lowercase letters; you will not be able to log on to the XenMobile 10 console after migration if the account contains uppercase letters. Create an administrator user account with all lowercase letters and with all permissions enabled so that after migration you can use that account to log on to the XenMobile 10 console.

Deployment Package names with special characters

Deployment package names in XenMobile 9.0 that contain special characters (!, $, (), #, % , +, *, ~, ?, |, {}, and []) migrate, but the Delivery Groups in XenMobile 10 cannot be edited after migration. In addition, local users and local Citrix Licensing How to Configure an External SSL Certificate citrix.com 63 groups created in XenMobile 9.0 that contain an open square bracket ([) cause problems in XenMobile 10 when creating enrollment invitations. Before migration, remove all special characters from Deployment Package names as well as open square brackets from local user and local group names.

Copy files from XenMobile 9.0 Device Manager

Assuming Device Manager is installed in the default location (C:\Program Files(x86)\Citrix\XenMobile Device Manager\tomcat), copy the following files into a temporary folder:

From C:\Program Files (x86)\Citrix\XenMobile Device Manager\tomcat\conf folder:

• server.xml
• https.p12
• cacerts.pem.jks
• pki-ca-root.p12
• pki-ca-devices.p12
• pki-ca-servers.p12

Note: If custom server SSL server certificates (.p12) were used on the server running Device Manager, make sure that you copy that certificate instead of https.p12 to the temporary folder.

From the C:\Program Files (x86)\Citrix\XenMobile Device Manager\tomcat\webapps\zdm\WEB-INF\classes\ folder, copy the following files into the same temporary folder:

• ew-config.properties
• pki.xml
• variables.xml

After you have copied all the preceding files, open the temporary folder and zip the files; do not zip the folder, only the files. The zipped files will be uploaded during the upgrade.

When you understand the known issues and meet all the prerequisites, start the upgrade.