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.

Configuring XenMobile for the First-Time Use

Configuring XenMobile for the First-Time Use

Configuring XenMobile for the first time is a two-part process.

1. Configure the IP address and subnet mask, default gateway, and DNS servers for XenMobile by using the XenCenter or vSphere command-line console.

2. Log on to the XenMobile management console and follow the steps in the initial logon screens.

Configuring XenMobile in the Command Prompt Window

1. Import the XenMobile virtual machine into Citrix XenServer, Microsoft Hyper-V, or VMware ESXi. For details, see , , or documentation.

2. In your hypervisor, select the imported XenMobile virtual machine and start the command prompt view. For details, see the documentation for your hypervisor.

3. From the hypervisor’s console page, create an administrator account for XenMobile in the Command Prompt window.

Note: No characters, such as asterisks, are shown when you type the new password. Nothing appears.

4. Provide the following:

a. IP address

b. Netmask

c. Default gateway

d. Primary DNS server

e. Secondary DNS server (optional)

Note: The addresses shown in this image are non-working and are provided as examples only.

5. Type y to increase security by generating a random passphrase or n provide your own passphrase. Citrix recommends typing y to generate a random passphrase. The passphrase is used as part of the protection of the encryption keys used to secure your sensitive data. A hash of the passphrase, stored in the server file system, is used to retrieve the keys during the encryption and decryption of data. The passphase cannot be viewed.

Note: If you intend to extend your environment and configure additional servers, you should provide your own passphrase. There is no way to view the passphrase if you selected a random passphrase.

6. Optionally, enable Federal Information Processing Standard (FIPS). For details about FIPS, see  2 Compliance. Also, be sure to complete a set of prerequisites, as discussed in .

7. Configure the database connection. Your database can be local or remote. When asked Local or remote, type r or l. Important:

->Citrix recommends using Microsoft SQL remotely. PostgreSQL is included with XenMobile and should be used locally or remotely only in test environments.

->Database migration is not supported. Databases created in a test environment cannot be moved to a

production environment. Important: The default port for PostgreSQL is 5432.

Note: The addresses shown in this image are non-working and are provided as examples only.

8.Provide the fully qualified domain name (FQDN) for the server hosting XenMobile. This one host server provides both device management and app management services.

Important: You will not be able to change the FQDN without completely reinstalling the server.

9. Identify the communication ports. For details on ports and their uses, see .

Note: Accept the default ports by pressing Enter (Return on a Mac).

10. You are asked to provide passwords for all the Public Key Infrastructure (PKI) server certificates and given the option to use the same password for each certificate. For details on the XenMobile PKI feature, see XenMobile. Important: If you intend to cluster nodes, or instances, of XenMobile together, you will need to provide the identical passwords for subsequent nodes.

Note: No characters, such as asterisks, are shown when you type the new password. Nothing appears.

11. Create an administrator account for logging on to the XenMobile console with a web browser. Be sure to remember these credentials for later use.

Note: No characters, such as asterisks, are shown when you type the new password. Nothing appears.

12. When asked if this is an upgrade, type n because it is a new installation.

13. Copy the complete URL that appears on the screen and continue this initial XenMobile configuration in your web browser.

Configuring Link Aggregation

Configuring Link Aggregation

Link aggregation combines incoming data from multiple ports into a single high speed link. Configuring the link aggregate channel increases the capacity and availability of the communication channel between a NetScaler and other connected devices. An aggregated link is also referred to as a channel. You can configure the channels manually or by using Link Aggregation Control Protocol

(LACP).

Configuring Link Aggregation Manually

This section describes the procedures to configure a link aggregate channel manually.

Topics include:

• Creating channels

• Binding a channel to a network interface

• Verifying the configuration

Creating Link Aggregate Channels

You can create a channel manually and bind network interfaces to it. The new channel is in the DOWN state until you bind one or more active network interfaces to the channel.

Note: Adding a channel without specifying the network interface number parameter can cause a failover.

Use either of the following procedures to add a channel.

To create a link aggregate channel using the configuration utility

1. In the navigation pane, expand Network and click Channels. The Channels page appears in the details pane.

2. Click Add. The Add Channel dialog box appears.

3. In the Channel ID drop-down list, select the link aggregate ID that you want to add, for example,

LA/1.

4. Click Create and click Close. The link aggregate channel you added appears in the Channels page.

To create a link aggregate channel using the NetScaler command line

At a NetScaler command prompt, type:

add channel LA/1

Binding a Network Interface to a Link Aggregate Channel

When a network interface is bound to a channel, the channel parameters have precedence over the network interface parameters. A network interface can be bound to only one channel.

Note: The state of the channel is UP only when the state of any of the interfaces bound to it is UP.

Binding a network interface to a link aggregate channel changes the VLAN configuration. That is, binding network interfaces to a channel, manually or using LACP, removes them from the VLANs that they originally belonged to and adds them to the default VLAN. However, you can bind the channel back to the old VLAN, or to a new one. For example, if you have bound network interfaces 1/2 and 1/3 to a VLAN with ID 2, and then you bind them to link aggregate channel LA/1, the network interfaces are moved to the default VLAN, but you can bind them to VLAN 2. Use either of the following procedures to bind a network interface to a link aggregate channel.

To bind a link aggregate channel using the configuration utility

1. In the navigation pane, expand Network and click Channels. The Channels page appears in the details pane.

2. Select the channel that you want to bind to a network interface, for example, LA/1.

3. Click Open. The Modify Channel dialog box appears.

4. In the Available Interface list box, select the network interface, for example, 1/8.

5. Click Add. The network interface you selected appears in the Configured Interface list.

6. Click OK.

To bind a link aggregate channel using the NetScaler command line

At a NetScaler command prompt, type:

bind channel LA/1 1/8

Verifying the Configuration

Viewing the channels enables you to troubleshoot any problem in the configuration. You must follow the procedures described in this section to view the configured channels.

Viewing the Properties of Link Aggregate Channels

You can view channel properties such as channel ID, description, uptime, virtual router identification (VRID), and state. Use either of the following procedures to view the properties of the configured channels. The LACP settings appear as a part of the output.

To view the properties of link aggregate channels using the configuration utility

1. In the navigation pane, expand Network and click Channels. The Channels page appears in the details pane. The details of the available channels appear on this page.

2. Verify that the configured channel (LA/1 if you used the example in the previous procedure) appears.

3. Select the configured channel and, in the Details section, and verify that the parameters displayed are correctly configured.

To view the properties of link aggregate channels using the NetScaler command line

At a NetScaler command prompt, type:

show channels

For more information about channels, see the Citrix NetScaler Networking Guide.

Configuring Clock Synchronization

You can configure your NetScaler to synchronize its local clock with a Network Time Protocol (NTP) server. This ensures that its clock has the same date and time settings as the other servers on your network. NTP uses User Datagram Protocol (UDP) port 123 as its transport layer. You have to add NTP servers in the NTP configuration file so that the NetScaler periodically gets updates from these

servers.

To enable clock synchronization on your system

1. Log on to the Citrix NetScaler command line.

2. Change to the shell prompt.

3. Copy the /etc/ntp.conf file to /nsconfig/ntp.conf.

4. Edit /nsconfig/ntp.conf to add the IP address for the desired NTP server under the file’s server and restricting entries.

5. Edit /nsconfig/rc.conf by adding the text ntpd_enable="YES", or, if necessary, create an nsconfig/rc.conf file that includes this text.

6. Reboot the NetScaler to enable clock synchronization.

If you do not have a local NTP server, you can find a list of public, open access, NTP servers at the official NTP site, http://www.ntp.org, under Public Time Servers List. Before configuring your system to use a public NTP server, be sure to read the Rules of Engagement page, (link included on all Public Time Servers pages).

Configuring DNS

You can configure a NetScaler to function as an Authoritative Domain Name Server (ADNS), DNS proxy server, End Resolver, or Forwarder. You can add DNS resource records such as SRV Records, AAAA Records, A Records, MX Records, NS Records, CNAME Records, PTR Records, and SOA Records. Also, the NetScaler can balance the load on external DNS servers.

This section describes the steps you take to configure a NetScaler as a forwarder.

To configure a NetScaler as a forwarder, you need to add external name servers.

Topics include:

• Adding a Name Server (includes an example that you can use in your initial configuration)

• Verifying the Configuration

Decision: StoreFront or Web Interface

Decision: StoreFront or Web Interface

Web Interface and StoreFront are two different solutions, whose feature sets overlap in many areas, but also offer a variety of distinct features. Therefore it is very important for organizations to review

the capabilities of each product against their requirements. In general, it is strongly recommended to build new solutions based on StoreFront. Since new features will not be added to Web Interface,

this chapter will focus on StoreFront only.

Note: Web Interface 5.4 support has been extended for XenDesktop 7.6 & XenApp 7.6. For more information please view the Citrix Product Matrix.

While StoreFront goes beyond Web Interface in many areas, StoreFront 2.5 and 2.6 does not support all features of Web Interface.

Note: With StoreFront 2.0 and higher, it is no longer necessary to store user subscription data in Microsoft SQL database.

The following table outlines the Web Interface features that are not available in StoreFront 2.6:

StoreFront

Citrix StoreFront, the successor to Citrix Web Interface, authenticates users to XenDesktop, XenApp, and App Controller (SaaS Apps) resources. StoreFront enumerates and aggregates available desktops and applications into stores that users access through Citrix Receiver for Windows, iOS, Android, Win8/RT or Receiver for Web sites. StoreFront is an integral component of XenDesktop 7.x and can be used with XenApp 5.0/XenDesktop 5.5 and higher deployments. StoreFront is essential for managing multisite XenDesktop deployments. For more information on StoreFront, see the Citrix eDocs – About StoreFront.

Decision: Unauthenticated Access

Unauthenticated access allows users to access XenApp published desktops and applications via Citrix StoreFront without having to provide Active Directory domain credentials. Unauthenticated access offers a fast logon experience and is generally used with public or kiosk workstations, or applications with built-in user management features. 

Building a XenApp environment with unauthenticated access requires the following components:

• XenApp 7.6 Delivery Controller

• StoreFront 2.6 store that has been configured for unauthenticated users

• Virtual Delivery Agent running on Windows Server 2008 R2 or higher

• A client with Citrix Receiver installed

When a XenApp unauthenticated access session is launched, a local user account becomes associated with the session. When the session logs off, the local user account is returned to the pool to be used by another connection. The local accounts are typically named AnonXYZ, where XYZ is a unique 3-digit value.

Unauthenticated access is enabled in Citrix Studio when specifying the users or user groups allowed access to applications and/or desktops in the Delivery Group.

The server VDA will create the anonymous local accounts on demand up to the maximum specified in the registry or 99 if no maximum is provided. This number can be changed by editing the

value for the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\ MaxAnonymousUsers

The Anonymous Users’ profiles are reset after each session ends. For considerations and requirements for unauthenticated access please refer to Citrix eDocs – Manage users in a Delivery Group.

Experience from the Field

A hospital is using XenApp to deliver their EMR application to users. ThinClient devices on stationary and mobile carts are being used by doctors and nurses to capture and retrieve patient data.

Unauthenticated access has been configured to prevent medical staff from having to authenticate to the domain as well as the EMR application.

Decision: High Availability

If the server hosting StoreFront or the respective web service is unavailable, users will not be able to launch new virtual desktops, published applications or manage their subscriptions. Therefore

at least two StoreFront servers should be deployed to prevent this component from becoming a single point of failure. By implementing a load balancing solution, users will not experience an interruption in their service. Options include:

• Hardware load balancing – An intelligent appliance, which is capable of verifying the availability of the StoreFront service and actively load balance user requests appropriately. Citrix NetScaler is a great example of a hardware load balancer. Citrix NetScaler is an ideal load balancer, coming pre-configured with StoreFront health checks.

• DNS Round Robin – Provides rudimentary load balancing across multiple servers without performing any checks on availability. If a StoreFront server becomes unavailable, DNS round robin would still route users to the failed server. Because of this, DNS round robin is not recommended by Citrix.

• Windows network load balancing – A Windows service capable of performing rudimentary checks to verify the server is available but cannot determine the status of individual services. This can cause users to be forwarded to StoreFront servers which are not able to process new requests. The user would then not be able to launch applications in their session.

The following figure (on the next page) shows a typical StoreFront deployment using Citrix NetScaler, operating as a load balancer for the environment. External users authenticate and gain access to StoreFront with the help of a NetScaler Gateway. NetScaler will also authenticate internal users as well.

Decision: Delivery Controller High Availability and StoreFront

To provide users with desktops and applications, StoreFront must be configured with the IP address or DNS name of at least one Controller in each XenDesktop and XenApp site. For fault tolerance,

multiple controllers should be entered for each site and/or farm specified. StoreFront will automatically failover to the second server in the list if the first server becomes unavailable (active/passive). For large deployments or environments with a high logon load an active distribution of the user load (active/active) is recommended. This can be achieved by means of a load balancer with built-in XML monitors and session persistency, such as Citrix NetScaler.

Configuring Network Interfaces

Configuring Network Interfaces
This section describes the tasks for configuring network interfaces, virtual LANs (VLANs), and link aggregate channels. To perform the tasks, you set, modify, and view parameters.
Topics include:
• Modifying Network Interfaces
• Configuring Virtual LANs
• Configuring Link Aggregation

Note: Some of the command-line instructions in this section include specific identifiers and/or settings. These values are only examples, but you can use them in your initial configuration.

Modifying Network Interfaces
configure interfaces and verify that the interfaces are configured correctly, perform the following procedures.

• Modify network interface characteristics such as speed, duplex mode, flow control, and monitoring. You can modify a network interface to match the settings on the other side of the communication link.

• View the settings of the configured interfaces. If the network interface number appears on the Interfaces page, the information shown applies only to that network interface. For example, information on the loopback network interface appears on the Interfaces page.

To modify a network interface using the configuration utility
1. In the navigation pane, expand Network and click Interfaces. The Interfaces page appears in the details pane.
2. Select the network interface that you want to modify, for example, 1/8.
3. Click Open. The Modify Interfaces dialog box appears.
4. In the Duplex drop-down list, select the duplex you want, for example, FULL.
5. Click OK.

To modify a network interface using the NetScaler command line
At a NetScaler command prompt, type:
set interface 1/8 -duplex full

Note: The network interface configuration is neither synchronized nor propagated. You must perform the configuration on each unit in a high availability (HA) pair independently.

Verifying the Configuration
Viewing the configuration enables you to troubleshoot any problem in the configuration.

Viewing the Properties of Network Interfaces
You can view network-interface properties such as description, MAC address, uptime, and virtual media access control (VMAC).

To view the properties of network interfaces using the configuration utility
1. In the navigation pane, expand Network and click Interfaces. The Interfaces page appears in the details pane, displaying details of the available network interfaces.
2. Verify that the configured interface appears (1/8 if you used the example in the previous procedure).
3. Select the configured interface and, in the Details section, verify that the parameters displayed are correctly configured.

To view the properties of network interfaces using the NetScaler command
line
At a NetScaler command prompt, type:
show interface

Viewing the Statistics of a Network Interface
To check the health of a network interface, you can view network-interface statistics such as throughput, Link Aggregation Control Protocol (LACP), and error statistics. Use either of the following procedures to view the statistics of a network interface.

To view the statistics of a network interface using the configuration utility
1. In the navigation pane, expand Network and click Interfaces. The Interfaces page appears in the details pane.
2. Select the network interface whose statistics you want to view, for example, 1/8.
3. Click Statistics. The Interface Statistics dialog box appears.

To view the statistics of a network interface using the NetScaler command
line
At a NetScaler command prompt, type:
stat interface 1/8

Decision: Authentication Point

Decision: Authentication Point
Before a user connects to a virtual resource, they must first authenticate. The place of authentication is often determined by the user group’s mobility requirements, which were defined during the user segmentation process. There are two authentication points available in XenDesktop 7:

• StoreFront – Citrix StoreFront provides authentication and resource delivery services for Citrix Receiver, enabling centralized enterprise stores to deliver desktops, applications and other resources.

• NetScaler Gateway – NetScaler Gateway is an appliance providing secure application access and granular applicationlevel policy controls to applications and data while allowing users to work from anywhere.

Authentication for user groups with a mobility requirement of remote or mobile may occur directly on StoreFront where required. For example, DMZ security policies may prohibit access from the
NetScaler Gateway to the domain, which is required to support SmartCard client certificate authentication. Access to StoreFront for authentication may then be delivered via a NetScaler SSL_BRIDGE virtual server, which provides a conduit for https traffic. Typically, the virtual server would be hosted alongside a NetScaler Gateway on the same NetScaler configured to provide HDX Proxy access to the virtual desktop environment. Although such a use case may sometimes be necessary, the recommended best practice is to authenticate external users via NetScaler Gateway.

Decision: Authentication Policy
Once the authentication point has been identified, the type of
authentication must be determined. The following options are the
primary methods available:

• StoreFront – Supports a number of different authentication methods, although not all are recommended depending on the user access method, security requirements and network location.

• User name and password – Requires users to logon directly to the site by entering a user name and password.

• Domain pass-through – Allows pass-through of domain credentials from users’ devices. Users authenticate to their domain-joined Windows computers and are automatically logged on when they access their stores.

• NetScaler Gateway pass-through – Allows pass-through authentication from NetScaler Gateway. Users authenticate to NetScaler Gateway and are automatically logged on when they access their stores.

• Smart card – Allows users to authenticate using smart cards and PINs through Citrix Receiver for Windows and NetScaler Gateway. To enable smart card authentication, user accounts must be configured either within the Microsoft Active Directory domain containing the StoreFront servers or within a domain that has a direct two-way trust relationship with the StoreFront server domain. Multi-forest deployments involving one-way trust or trust relationships of different types are not supported.

• Unauthenticated access – Allow users to access applications and desktops without presenting credentials to StoreFront or Citrix Receiver. Local anonymous accounts are created on demand on the Server VDA when sessions are launched. This requires a StoreFront store configured for unauthenticated access, a Server OS based VDA, and a XenApp 7.6 Delivery Group configured for unauthenticated users.

• NetScaler Gateway – The NetScaler Gateway supports several authentication methods. The list below includes those primarily used in virtual desktop environments. Each may be used individually, but are often combined to provide multi-factor authentication.

• LDAP – The lightweight directory access protocol (LDAP) is used to access directory information services such Microsoft Active Directory. NetScaler Gateway uses LDAP to authenticate users and extract their group membership information.

• RADIUS (token) – Remote authentication dial in user service (RADIUS) is a UDP based network security protocol that provides authentication, authorization and accounting. A network access server (NetScaler Gateway in this case) forwards credentials to a RADIUS server that can either check the credentials locally, or check them against a directory service. The RADIUS server could then accept the connection, reject the connection, or challenge and request a second form of authentication such as a token.

• Client certificate – Users logging on to a NetScaler Gateway virtual server can also be authenticated based on the attributes of a client certificate presented to the virtual server. Client certificates are usually disseminated to users in the form of smartcards or common access cards (CACs) that are read by a reader attach to each user’s device.

The authentication type for a user group is often determined based on security requirements as well as the authentication point used. The table shown below helps define the appropriate solution for each user group based on the level of security required:

Experience from the Field
Retail – A small private retail company provides virtual desktop users with access to non-sensitive data such as marketing catalogs and email. They are not required to adhere to security regulations
such as Sarbanes Oxley. Therefore, LDAP authentication has been implemented based on user name and password.

Financial – A medium financial enterprise provides their virtual desktop users with access to confidential data such as banking transaction records. They are governed by security regulations
such as the Statement on Accounting Standards (SAS) 70 and are required to utilize multi-factor authentication for remote access users. LDAP authentication has been implemented based on user
name and password along with RADIUS authentication using tokens.

Government – A large federal institution provides virtual desktop users with access to highly confidential data such as private citizens’ personal records. They are subject to regulation by Department of Defense (DOD) security standards. LDAP authentication has been implemented based on user name and password, along with Client Certificate authentication using CAC cards.

Decision: Initial Configuration

Decision: Initial Configuration

Citrix Receiver must be configured in order to provide access to enterprise resources. The method of configuration varies by Citrix Receiver edition, the form factor of the device, and lastly the access

method (local or remote) that is involved. Several methods may be viable for an organization. The method utilized is contingent on the resources (people, systems, time) available as well as larger

organizational initiatives such as BYOD programs.

The following methods can be used to configure Citrix Receiver:

• Email based discovery – The latest releases of Citrix Receiver can be configured by entering an email address. Email based Discovery requires Citrix StoreFront as well as an SRV DNS record which points to the FQDN of the StoreFront server.

Note: Any DNS platform should support email-based discovery, however only Windows DNS has been explicitly tested.

For remote access, NetScaler Gateway must be utilized with the corresponding SRV record in DNS. A valid server certificate on the NetScaler Gateway appliance or StoreFront server must be present in order to enable email-based account discovery.

• Group policy – Microsoft Group Policy can be used to configure Citrix Receiver. Once startup scripts have been deployed for Citrix Receiver, edit the corresponding script and ensure there is a value for the following parameter: SERVER_ LOCATION=Server_URL. The default value is blank. Provide the URL of the server running Citrix StoreFront. The URL must be in the format http://servername or https://servername.

• Provisioning file – For environments running StoreFront, it is possible to provide users with a provisioning file that contains store information. Provisioning files are exported from the StoreFront console. The file is saved with a “*.cr” extension and can then be placed on a shared network resource, a Receiver for Web site, or other web based resource. The file can then be launched from an endpoint, which automatically configures Citrix Receiver to use the store.

• Manually – If allowed, it is usually possible to configure Citrix Receiver manually. This method should be reserved for administrators or users that have advanced knowledge.

Decision: Updates

Citrix Receiver and plug-ins are in active development. As such, periodic updates are released that provide enhanced functionality or address user issues. As with any actively developed product, the latest version of these products should be deployed to the endpoints so that users benefit from the latest functionality. There are multiple methods available to update Citrix Receiver and, if applicable, associated plug-ins.

• Citrix.com update service – Citrix Receiver can be configured to use Citrix.com as its source for updates. This configuration, which is set inside the StoreFront administration panel, allows receiver and plugin updates to be downloaded automatically from Citrix.com. Since the updates will be downloaded from an external host, this is inefficient approach when a large number of users at the same site request an update.

• Merchandising Server – For platforms that support the Citrix Receiver updater plug-in (Citrix Receiver, Citrix Receiver Enterprise, and Citrix Receiver Mac). The Citrix Receiver updater plug-in communicates with Merchandising Server and identifies package updates for deployment.

• Enterprise software deployment – ESD tools provide a viable alternative to Merchandising Server with receiver updater. Additional thought must be given to updating unmanaged devices and endpoints outside of the corporate firewall, which is a solution that Merchandising Server can address.

• Manual updates – When no automated solution is available, manual methods can be used to update Citrix Receiver. Whether deployed on Receiver for Web site, StoreFront, an internal Citrix Receiver site, or an external site, these options will require user involvement in updating Citrix Receiver and the associated plugins. Due to the involved nature of manual updates coupled with the opportunity for a user mistake, this option should only be considered as a last resort.

Access Layer

The second layer of the design methodology is the access layer, which is defined for each user group.

Creating an appropriate design for the access layer is an important part of the desktop virtualization process. This layer handles user validation through authentication and orchestrates access to all components necessary to establish a secure virtual desktop connection.

The access layer design decisions are based on the mobility requirements of each user group as well as the endpoint devices used.

Accessing and Configuring a Citrix NetScaler Using the XML API

Accessing and Configuring a Citrix NetScaler Using the XML API

The NetScaler can be configured using an external Application Programming Interface (API). The API allows you to create custom client applications to configure and monitor the state of the NetScaler. It is based on Simple Object Access Protocol (SOAP) over HTTP. You can download the API documentation from the Downloads page of the Configuration Utility.

Configuring a Citrix NetScaler for the First Time

This section describes how to configure a new NetScaler that still has the original configuration that it was shipped with. You can configure a NetScaler from the Command Line Interface or the Configuration Utility.

Configuring a Citrix NetScaler Using the Command Line Interface

To set up a NetScaler using the CLI, connect the serial cable provided to the console port located at the right front of the unit, and connect the other end to a workstation. You access the CLI using a terminal emulator.

To configure a NetScaler from the CLI

1. Connect a workstation to the NetScaler.

A. Plug the supplied serial cable into the serial port.

B. Plug the other end of the serial cable into the workstation’s serial port.

C. Run the vt100 terminal emulation program of your choice. For example, Microsoft Windows users can use HyperTerminal, which is included with all modern versions of Windows.

D. Connect to the NetScaler.

2. At the login prompt type the user name nsroot and the password nsroot, and then press ENTER.

3. Change the root password by typing the following command at the CLI, and then press ENTER.

set system user nsroot password

4. Add a MIP by typing the following command at the CLI, and then press ENTER. add ns ip IPaddress netmask -type MIP

5. Set the default gateway by typing the following command at the CLI, and then press ENTER. add route network netmask gateway

6. Set the NSIP by typing the following command at the CLI, and then press ENTER. set ns config -IPAddress IPaddress -netmask netmask

7. Review your changes to make sure that they reflect your deployment goals.

8. Save your configuration by typing the following command at the CLI, and then press ENTER.

save ns config

9. Reboot the NetScaler by typing the following command at the CLI, and then press ENTER. reboot

10. The NetScaler prompts you to confirm the reboot. Type Y and press ENTER to confirm the reboot.

11. Log back on to the workstation as nsroot, using the new administrative password.

12. Confirm connectivity to the NetScaler by typing the following command and pressing the Enter key. ping NSIP

Configuring a Citrix NetScaler Using the Configuration Utility

To set up a NetScaler using the Configuration Utility, you need an administrative workstation or laptop on the same network as the NetScaler. If you prefer to connect the workstation directly to a NetScaler, use an Ethernet crossover cable. You also need version 1.4.2_04 or higher of the Java® runtime environment.

First-time configuration includes changing the NetScaler IP address, adding a Mapped IP address, adding a default gateway, and changing the default administrator password. The Setup Wizard in the Configuration Utility can help you configure all these entities.

A NetScaler is configured with a default IP address and associated netmask for management access. The default IP is 192.168.100.1 and the netmask is 255.255.0.0. This default IP address is used whenever a user-configured value for a NetScaler's IP address (NSIP) is absent. You need to specify at least one MIP when you configure a NetScaler for the first time. The NSIP and MIP need not belong to the same subnet.

To configure a NetScaler for the first time using Configuration Utility

1. Log on to the Configuration Utility as default administrator.

2. The Setup Wizard appears.

3. Follow the instructions to create an initial configuration.

4. When you are finished with the Setup Wizard, the Reboot pop up menu appears.

5. Click Yes.

Setting up a High Availability Pair

You can deploy two NetScalers in a high availability configuration, where one unit actively accepts connections and manages servers while the secondary unit monitors the first. The NetScaler that is actively accepting connections and managing the servers is called a primary unit and the other one is called a secondary unit in a high availability configuration. If there is a failure in the primary unit, the secondary unit becomes the primary and begins actively accepting connections.

Each NetScaler in a high availability pair monitors the other by sending periodic messages, called heartbeat messages or health checks, to determine the health or state of the peer node. If a health check for a primary unit fails, the secondary unit retries the connection for a specific time period. (For more information about time intervals, see the “High Availability” chapter in the Citrix NetScaler Networking Guide.) If a retry does not succeed for the specific time period, the secondary unit takes over for the primary unit in a process called failover. The following diagram shows two high availability configurations, one with NetScalers deployed in one-arm mode and the other with NetScalers deployed in two-arm mode.

In one-arm configuration, both NS1 and NS2 and servers S1, S2, and S3 are connected to the switch.

In two-arm configuration, both NS1 and NS2 are connected to two switches. The servers S1, S2, and S3 are connected to the second switch. The traffic between client and the servers passes through either NS1 or NS2.

Configuring a High Availability Pair for the First Time

To steps to set up a high availability environment, configure one NetScaler as primary and another as secondary. Perform the following tasks on each of the NetScalers:

• Add a node.

• Disable high availability monitoring for unused interfaces.

Note: Some of the command-line instructions in this section include specific identifiers and/or settings. These values are only examples, but you can use them in your initial configuration.

Adding a Node

A node is a logical representation of a peer NetScaler. It identifies the peer unit using a unique ID and its NSIP. A NetScaler uses these parameters to communicate with the peer and track its state. When you add a node, the primary and secondary units exchange heartbeat messages asynchronously. The node ID is an integer that must not be greater than 64.

To add a node using the configuration utility

1. In the navigation pane, expand System and click High Availability. The High Availability page appears in the details pane.

2. Click the Nodes tab. The Nodes page appears in the details pane.

3. Click Add. The Add Node dialog box appears.

4. In the ID text box, type an ID, for example, 3.

5. In the IP Address text box, type an IP Address, for example, 10.102.29.170.

6. Click Create. The node you created appears in the Nodes page.

To add a node using the NetScaler command line

At a NetScaler command prompt, type: add HA node 3 10.102.29.170

Disabling High Availability Monitoring for Unused Interfaces

The high availability monitor is a virtual entity that monitors an interface. You must disable the monitor for the interfaces that are not connected or being used for traffic. When the monitor is enabled on one of the interfaces and the status of this interface is DOWN, the state of the node becomes NOT UP. In a high availability configuration, a primary node entering a NOT UP state might cause a high availability failover. An interface is marked DOWN under the following

conditions:

• The interface is not connected.

• The interface is not working properly.

• The cable connecting the interface is not working properly.

To disable the high availability monitor for an unused interface using the configuration utility

1. In the navigation pane, expand Network and click Interfaces. The Interfaces page appears in the details pane.

2. Select the interface for which the monitor must be disabled.

3. Click Open. The Modify Interface dialog box appears.

4. In HA Monitoring, select the OFF option.

5. Click OK. The Modify Interface dialog box appears.

To disable the high availability monitor for an unused interface using the NetScaler command line

At a NetScaler command prompt, type: set interface 1/8 haMonitor OFF

User Layer

User Layer

The top layer of the design methodology is the user layer, which is defined for each unique user group.

The user layer appropriately sets the overall direction for each user group’s virtualized environment. This layer incorporates the assessment criteria for business priorities and user group requirements in order to define effective strategies for endpoints and Citrix Receiver. These design decisions impact the flexibility and functionality for each user group.

Endpoint Selection

There are a variety of endpoints devices available, all with differing capabilities, including:

• Tablet based on Android or iOS

• Laptop

• Desktop PC

• Thin client

• Smartphone

The user’s primary endpoint device must align with the overall business drivers as well as each user’s role and associated requirements. In many circumstances, multiple endpoints may be suitable, each offering differing capabilities.

Decision: Endpoint Ownership

In most organizations, endpoint devices will be corporate owned and managed. However, more and more organizations are now introducing bring your own device (BYOD) programs to improve

employee satisfaction, reduce costs and to simplify device management. Even if BYOD is a business priority, it does not mean that every user should be allowed to use a personal device in the corporate environment.

Certain user requirements, which were identified during the user segmentation, can greatly impact the suitability of personal devices:

• Security – Users requiring a high-level of security might not be able to bring a personal device into the secured environment for risk of data theft.

• Mobility – Users operating in a disconnected mode might not be able to use a personal device, as the local VM FlexCast model associated with this type of requirement can have specific hardware requirements, or special maintenance requirements. Additionally, the local operating system may be destroyed when the local VM FlexCast option is utilized.

• Criticality – Users with a high criticality rating might require redundant endpoints in the event of failure. This would require the user to have an alternative means for connecting in the event their personal device fails, likely making these users poor candidates for a BYOD program.

• FlexCast model – A personal device should not be recommended for user groups utilizing a client-hosted FlexCast model like streamed VHD, local VM or Remote PC. These FlexCast models typically require a specific hardware configuration or installation that will restrict device selection.

The diagram shown below provides guidance on when user owned devices could be used.

Decision: Endpoint Lifecycle

Organizations may choose to repurpose devices in order to extend refresh cycles or to provide overflow capacity for contract workers. Endpoints now offer more capabilities allowing them to have longer useful lifespans. In many cases, these hardware capabilities vastly outstrip the needs of a typical user. When coupled with the ability to virtualize application and desktop workloads, this provides new options to administrators such as repurposing existing workstations. These options go well beyond the simple threeyear PC refresh cycle. However, the benefits of repurposing or

reallocating a workstation should be balanced against the following considerations.

• Minimum standards – While cost factors of repurposing existing workstations may be compelling, certain minimum standards should be met to guarantee a good user experience. At a minimum, it is recommended that repurposed workstations have a 1GHz processor, 1GB of RAM, 16GB of free disk space and a GPU that is capable of supporting HDX features.

• Business drivers – Priorities underpin the success of any major project. Those organizations that have prioritized reducing capital expenditure by means of prolonging the hardware refresh cycle can benefit from repurposing hardware. Conversely, if an organization’s business drivers include reducing power consumption as part of an overall green initiative, purchasing newer endpoints may be beneficial in order to take advantage of the latest generation of power management capabilities available in the most modern devices.

• Workload – The type of work and FlexCast model for an end user can determine whether they are a good candidate for a repurposed endpoint, or may be better served with a new device. If the work performed by the individual involves locally installed applications, the individual may be best served by a new endpoint that offers the most powerful and recently updated processor and graphics architecture. However, if a user is largely performing tasks associated with virtualized applications that do not involve the latest multimedia capabilities such as webcams, VoIP and media redirection, then a repurposed workstation should be a viable alternative.

Decision: Endpoint Form Factor

The capabilities of endpoints have grown along with efficiencies offered in thin client form factors. Even mid-range thin clients now have graphics capabilities that allow utilization of HDX features such as multi-monitor support while offering management and power efficiency benefits. This expansion of capabilities has given IT administrators more options and flexibility than ever before.

Most organizations will likely deploy a mixture of fully featured clients as well as thin clients. It is important to focus on multiple user group attributed in order to best determine the type of endpoint that should be deployed:

Decision: Thin Client Selection

Thin client vendors now offer a range of operating system choices, including Windows Thin PC (based on Windows 7), embedded versions of Windows (XP, Windows 7 and Windows 8), Linux

variants, as well as limited functionality clients that boot directly into a virtual desktop and offer a zero operating system footprint. The following factors should be considered during the selection of a thin-client device:

• User workload – Windows Thin PC or limited functionality solutions such as Dell Wyse Zero clients should be tailored to true task workers or knowledge workers with limited needs. More

capable thin devices such as Windows Embedded solutions can be provided to users that require more graphic capabilities and other intensive activities.

• In-house expertise – Many organizations have management toolsets already in place to handle thin client infrastructure such as retailers that may have kiosks. In-house expertise with a thin client management infrastructure can determine the selection of thin client platform. It is recommended that existing in-house expertise is leveraged, so long as the platform is capable of supporting a virtual desktop infrastructure implementation, as outlined on the Citrix Ready site.

• Licensing cost – There are licensing considerations for most platforms. Windows thin PC and embedded versions incur immediate license costs related to Microsoft licensing, whereas a custom Linux solution may not. However, these costs must be closely balanced against additional add-on licensing that may be required for Linux devices, which are built into Windows. For example, various media codecs may require additional license expenditure in a Linux thin client context. For more information, please refer to the Microsoft Partner Site.

Experience from the Field

Large systems integrator – A large systems integrator recommended that a customer deploy a single type of low-end, limited capability endpoint for all users. Upon deployment to production, users immediately complained that they received a poor user experience when viewing multimedia content over the WAN. At great cost, the systems integrator and customer re-assessed the environment and chose to deploy endpoints that supported HDX MediaStream. The mistake caused a schism between systems integrator and the customer, resulting in lost time, capital and the end of a business relationship that was fostered over many years. It is critical that the endpoints assigned to each user group can support their requirements.