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.

Accessing and Configuring a Citrix NetScaler

Accessing and Configuring a Citrix NetScaler

This chapter describes how to configure a NetScaler after installing the hardware.

In This Chapter

1. Accessing a Citrix NetScaler

2. Configuring a Citrix NetScaler for the First Time

3. Setting up a High Availability Pair

Accessing a Citrix NetScaler

You can access and configure a NetScaler using either the Command Line Interface (CLI) or the Graphical User Interface (GUI). All NetScaler units ship with the default NSIP address of 192.168.100.1 and default subnet mask of 255.255.0.0. Use the NSIP address to access your NetScaler. You can assign a new NSIP and an associated subnet mask during initial configuration.

If you encounter an IP address conflict when deploying multiple NetScaler units, check for the following possible causes:

• Did you select an NSIP that is an IP address already assigned to another device on your network?

• Did you assign the same NSIP to multiple NetScalers?

The NSIP is reachable on all physical ports. The ports on a NetScaler are host ports, not switch ports.

Using the Command Line Interface

You can access the CLI either by connecting a workstation to a console port on the NetScaler or by connecting through secure shell (SSH) from any workstation on the same network.

For general information about the features of the CLI, including SSH, see the Citrix NetScaler Command Reference Guide.

Logging on to the Command Line Interface Using a Console Port 

Connect a NetScaler’s serial port to your PC serial port using a crossover cable, and start the Hyper Terminal program or any other terminal emulation program. If the logon prompt does not appear, you may need to press ENTER one or more times to display it. Enter your login credentials and press ENTER. The CLI prompt (>) is displayed on the workstation monitor.

Logging on to the Command Line Interface using SSH

The SSH protocol is the preferred remote access method for accessing a NetScaler remotely from any workstation on the same network. You can use either SSH version 1 (SSH1) or SSH version 2 (SSH2.)

If you do not have a working SSH client, you can download and install any of the following SSH client programs:

• PuTTY

Open Source software supported on multiple platforms. Available at:

http://www.chiark.greenend.org.uk/~sgtatham/putty/

• AttachmateWRQ Reflection for Secure IT

Commercial software supported on the Windows platform. Available at:

http://www.wrq.com/products/reflection/ssh/

• Vandyke Software SecureCRT

Commercial software supported on the Windows platform. Available at:

http://www.vandyke.com/products/securecrt/

All of these programs have been tested by the Citrix NetScaler team, which has verified that they work correctly with a NetScaler. Other programs may also work correctly, but have not been tested.

To verify that the SSH client is installed properly, use it to connect to any device on your network that accepts SSH connections.

To log on to a NetScaler using an SSH client

1. On your workstation, run the SSH client.

2. Use the NSIP you assigned to your NetScaler during initial configuration, selecting either SSH1 or SSH2 as the protocol.

3. Log on as nsroot, using the administrative password you assigned during initial configuration.

The following output appears on the your SSH client screen:

login as: nsroot

nsroot@10.102.29.60's password:

Last login: Wed May 23 17:18:31 2007

Done

Using the Graphical User Interface

The Graphical User Interface has two main components:

• Configuration Utility

• Statistical Utility

The system requirements for a workstation running the GUI are as follows:

• For Windows-based workstations, a Pentium® 166 MHz or faster processor with at least 48 MB of RAM is recommended for applets running in a browser using a Java plug-in product. You should have 40 MB free disk space before installing the plug-in.

• For Linux-based workstations, a Pentium platform running Linux kernel v2.2.12 or above, and glibc version 2.12-11 or later. A minimum of 32 MB RAM is required, and 48 MB RAM is recommended. The workstation should support 16-bit color mode, KDE and KWM window managers used in conjunction, with displays set to local hosts.

• For Solaris-based workstations, a Sun running either Solaris 2.6, Solaris 7, or Solaris 8, and the Java 2 Runtime Environment, Standard Edition, version 1.4.2_04 or later.

Your workstation must have a supported web browser and version 1.4.2_04 or above of the Java® applet plug-in installed to access the Configuration Utility and the Statistical Utility. The following Web browsers and platforms have been tested and can be used to access the GUI:

• Internet Explorer version 4, 5, or 5.5 on Windows 95/98/2000/NT

• Internet Explorer version 6 or 7 on Windows XP Home or Professional editions

• Netscape 4.51/4.61/4.72/4.75 on Windows 95/98/2000/NT

• Netscape 4.51 on Solaris 5.6/5.7/5.8

• Netscape 4.61/4.72/4.75 on Red Hat Linux 6.2

• Netscape 4.77 on Windows 2000/NT, or on Windows XP Home or Professional editions

• Netscape 6.2 on Windows 98/2000/NT, or on Windows XP Home or Professional editions

Installing XenMobile

Installing XenMobile

The XenMobile virtual machine (VM) runs on Citrix XenServer, VMware ESXi, or Microsoft Hyper-V. You can use XenCenter or vSphere management consoles to install XenMobile. Before you start, see the and the . 

Note: Ensure the hypervisor is configured with the correct time because XenMobile uses that time.

XenServer or VMware ESXi prerequisites: Before installing XenMobile on XenServer or VMware ESXi, you must do the following. For details, refer to your or documentation.

-->Install XenServer or VMware ESXi on a computer with adequate hardware resources.

-->Install XenCenter or vSphere on a separate computer. The computer that hosts XenCenter or vSphere connects to XenServer or VMware ESXi host through the network.

Hyper-V prerequisites: Before installing XenMobile on Hyper-V, you must do the following. For details refer to your documentation.

-->Install Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2 with Hyper-V enabled, role enabled, on a computer with adequate system resources. While installing the Hyper-V role, be sure to specify the network interface cards (NICs) on the server that Hyper-V will use to create the virtual networks. You can reserve some NICs for the host.

FIPS 140-2 mode: If you plan to install XenMobile server in FIPS mode, you need to complete a set of prerequisites, as discussed in .

Downloading XenMobile Product Software

You can download product software from the . You need to log on to the site and then click the Downloads link on the Citrix web page. You can then select the product and type you want to download. For example, the following figure shows XenMobile and Product Software selected from the lists:

When you click Find, a page listing the available downloads appears with the most recent version at the top of the list. You can select your software from the available list of options.

To download the software for XenMobile

1. Go to the .

2. Click My Account and log on.

3. Click Downloads.

4. Under Find Downloads, from the product list, click XenMobile.

5. Under Find Downloads, from the download type list, click Product Software and then click Find.

6. On the XenMobile Product Software page, click the XenMobile 10.0 edition you want to download.

7. On the XenMobile 10.0 Edition page, click Download for the appropriate virtual image in order to install XenMobile on XenServer, VMware, or Hyper-V.

8. Follow the instructions on your screen to download the software.

To download the software for NetScaler Gateway

You can use this procedure to download the NetScaler Gateway virtual appliance or software upgrades to your existing NetScaler Gateway appliance.

1. Go to the .

2. Click My Account and log on.

3. Click Downloads.

4. Under Find Downloads, from the product list, click NetScaler Gateway.

5. Under Find Downloads, from the download type list, click Product Software and then click Find.

Note: You can also click Virtual Appliances to download NetScaler VPX. When you select this option, you receive a list of software for the virtual machine for each hypervisor.

6. On the NetScaler Gateway page, expand 10.5(4).

7. Click the appliance software version you want to download.

8. On the appliance software page for the version you want to download, click Download for the appropriate virtual appliance.

9. Follow the instructions on your screen to download the software.

Installing an SFP

Installing an SFP

A Small Form Factor Pluggable (SFP) is a compact transceiver that can operate at speeds of up to 1 gigabit per second and is available in both copper and fiber types. Inserting an SFP copper transceiver converts the SFP port to a 1000BASET port. Inserting an SFP fiber transceiver converts the SFP port to a 1000BASE-X port. Auto-negotiation is enabled by default on the SFP port into which you insert

your SFP transceiver. As soon as a link between the port and the network is established, the speed and mode are matched on both ends of the cable.

Caution! Only SFP transceivers provided by Citrix Systems are supported on NetScaler appliances. Attempting to install third-party SFP transceivers on your NetScaler appliance voids the warranty.

Insert SFP transceivers into the SFP ports on the front panel of the appliance. Removing an SFP transceiver does not affect the functioning of the appliance, except that the port is no longer available for traffic. However, frequent installation and removal of transceivers shortens their life span. Follow the removal procedure carefully to avoid damaging the SFP transceiver or the appliance.

Caution! Do not install the transceivers with the cables attached. Doing so can damage the cable, the connector, or the optical interface of the transceiver.

To install a copper SFP

1. Carefully remove a copper SFP module from the box.

2. Insert the copper SFP in the SFP slot, with the locking hinge in the DOWN position.

3. Push the copper SFP until it is in the locking position.

4. Move the locking hinge to the UP position and push the module into the slot.

To Install a fiber SFP

1. Carefully remove a fiber SFP module from the box.

2. Insert the fiber SFP in the SFP slot, with the locking hinge in the UP position.

3. Push the fiber SFP until it is in the locking position.

4. Move the locking hinge to the DOWN position.

5. Remove the fiber dust protector.

6. Move the locking hinge to the UP position and push the module into the slot.

Installing an XFP

Note: This section applies to the 12000 10G, MPX 15000, and MPX 17000 appliances.

A 10-Gigabit Small Form Factor Pluggable (XFP) is a compact optical transceiver that can operate at speeds of up to 10 gigabits per second. Autonegotiation is enabled by default on the XFP ports into which you insert your XFP transceiver. As soon as a link between the port and the network is established, the speed and mode are matched on both ends of the cable.

Caution! Only XFP transceivers provided by Citrix Systems are supported on NetScaler appliances. Attempting to install third-party XFP transceivers on your NetScaler appliance voids the warranty.

Insert the XFP transceivers into the XFP ports on the front panel of the appliance. Removing an XFP transceiver does not affect the functioning of the appliance, except that the port is no longer available for traffic. However, frequent installation and removal of transceivers shortens their life span. Follow the removal procedure carefully to avoid damaging the transceiver or the appliance.

Caution! Do not install the transceivers with the cables attached. Doing so can damage the cable, the connector, or the optical interface of the transceiver.

To Install an XFP

1. Remove an XFP module carefully from the box.

2. Insert the XFP in the XFP slot, with the locking hinge in the UP position.

3. Push the XFP until it is in the locking position.

4. Move the locking hinge to the DOWN position.

5. Remove the fiber dust protector.

6. Move the locking hinge to the UP position and push the module into the slot.

BlackBerry

BlackBerry

Management of BlackBerry devices is provided through XenMobile Mail Manager. For details, see

Mail Manager.

Port Requirements

To enable devices and apps to communicate with XenMobile, you need to open specific ports in your firewalls. The following tables list the ports that must be open.

Opening Ports for NetScaler Gateway and XenMobile to Manage Apps

You must open the following ports to allow user connections from Worx Home, Citrix Receiver, and the NetScaler Gateway Plug-in through NetScaler Gateway to XenMobile, StoreFront, XenDesktop, the XenMobile NetScaler Connector, and to other internal network resources, such as intranet websites.

Port Requirement for Auto Discovery Service Connectivity

This port configuration ensures that Android devices connecting from Worx Home for Android 10.2 can access the Citrix Auto Discovery Service (ADS) from within the internal network. The ability to access the ADS is important when downloading any security updates made available through ADS.

Note: ADS connections might not work with your proxy server. In this scenario, allow the ADS connection to bypass the proxy server.

Customers interested in enabling certificate pinning must do the following prerequisites:

-->Collect XenMobile Server and NetScaler certificates. The certificates need to be in PEM format and must be a public certificate and not the private key.

-->Contact Citrix Support and place a request to enable certificate pinning. During this process, you are asked for your certificates.

New certificate pinning improvements require that devices connect to ADS before the device enrolls. This ensures that the latest security information is available to Worx Home for the environment in which the device is enrolling. Worx Home will not enroll a device that cannot reach the ADS. Therefore, opening up ADS access within the internal network is critical to enabling devices to enroll.

FIPS 140-2 Compliance

The Federal Information Processing Standard (FIPS), issued by the US National Institute of Standards and Technologies (NIST), specifies the security requirements for cryptographic modules used in security systems. FIPS 140- 2 is the second version of this standard. For more information about NIST-validated FIPS 140 modules, see nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf. Important: You can enable XenMobile FIPS mode only during initial installation.

Note: XenMobile mobile device management-only, XenMobile mobile app management-only, and XenMobile Enterprise are all FIPS compliant as long as no HDX apps are used.

All data-at-rest and data-in-transit cryptographic operations on iOS use FIPS-certified cryptographic modules provided by the OpenSSL and Apple. On Android, all data-at-rest cryptographic operations and all data-in-transit cryptographic operations from the mobile device to NetScaler Gateway use FIPS-certified cryptographic modules provided by OpenSSL.

All data-at-rest and data-in-transit cryptographic operations for Mobile Device Management (MDM) on Windows RT, Microsoft Surface, Windows 8 Pro, and Windows Phone 8 use FIPS-certified cryptographic modules provided by Microsoft.

All data-at-rest and data-in-transit cryptographic operations at XenMobile Device Manager use FIPS-certified cryptographic modules provided by OpenSSL. Combined with the cryptographic operations described above for mobile devices, and between mobile devices and NetScaler Gateway, all data-at-rest and data-in-transit for MDM flows use FIPS-compliant cryptographic modules end-to-end.

All data-in-transit cryptographic operations between iOS, Android, and Windows mobile devices and NetScaler Gateway use FIPS-certified cryptographic modules. XenMobile uses a DMZ-hosted NetScaler FIPS Edition appliance equipped with a certified FIPS module to secure these data. For more information, see the .

MDX apps are supported on Windows Phone 8.1 and use cryptographic libraries and APIs that are FIPS-compliant on Windows Phone 8. All data-at-rest for MDX apps on Windows Phone 8.1 and all data-in-transit between the Windows Phone 8.1 device and NetScaler Gateway are encrypted using these libraries and APIs.

The MDX Vault encrypts MDX-wrapped apps and associated data-at-rest on both iOS and Android devices using FIPScertified cryptographic modules provided by the OpenSSL.

For the full XenMobile FIPS 140-2 compliance statement, including the specific modules used in each case, contact your Citrix representative.

Citrix Consulting Tips for Success

Citrix Consulting Tips for Success

1. Lead with hosted shared/VDI – As you can see in the FlexCast capability table above, the hosted VDI and hosted shared FlexCast models can be used in the majority of situations. The streamed VHD and local VM FlexCast models should only be used on an exception basis. By reducing the number of FlexCast models required, you will help to reduce deployment time and simplify management.

2. Perfect match – It may not be possible to select a FlexCast model which is a perfect match for your user group, for example you can’t provide users with a desktop that is highly secure and offers complete personalization at the same time. In these situations, select the FlexCast model which is the closest match.

3. Desktop loss criticality – There are only three FlexCast models that meet the needs of a high criticality user group (backup desktops available) – none of which allow for complete personalization. If a high-criticality user group also requires the ability to personalize their desktop they could be provided with a pool of backup desktops (hosted shared, pooled, streamed) in addition to their primary desktop. Although these desktops would not include customizations made to their primary desktop, they would allow users to access core applications such as mail, Internet and Microsoft Office.

Define the Applications

Once the users have been divided up in to groups the next step is to determine which applications they require. This is a two-step process:

1. Application rationalization – Help to simplify the application assessment by removing redundant applications from the inventory that were captured during the data capture.

2. Link apps to users – Use the results from the data capture process to map applications to user groups.

Application Rationalization

The number of applications identified during the inventory is often surprising, even for organizations that believe they have a high-level of control over applications. To help reduce complexity as well as

overall time required, it’s important to take the time to consolidate the list of applications. Start by arranging an application assessment meeting with all relevant application owners.

Note: Consolidated applications should be identified within the application assessment worksheet by selecting consolidated in the status column. Consolidated applications should not be removed

from the spreadsheet so that the rationalization process can be reviewed within the organization.

The following guidelines will help to ensure that your application list is consolidated appropriately:

• Multiple versions – Different versions of the same application may have been identified during the inventory. There are various reasons for this, including an inconsistent patching or upgrade process, decentralized application management, limited licenses and situations where users require specific application versions for compatibility with other applications, macros and document formats. Where possible, work with the application owners to reduce the number of versions required. The best practice is to standardize on a single version of each application, typically the latest.

• Business applications – Applications, which are not required by the business, should be removed from the application inventory to reduce resource requirements and to help simplify the overall

project. Non-business related applications are typically found in an application inventory when users have been provided with the ability to install their own applications and typically include games, communication clients, screen savers, peripheral software and media players.

• Legacy applications – The inventory may identify legacy applications that have since been retired or that are no longer required within the business. These applications may not have been removed from the desktops because there is no established process to do so or because there are always more

high-priority activities to complete. These applications should be consolidated during the rationalization stage of the application assessment.

• Management applications – The antivirus, application delivery, monitoring, inventory, maintenance and backup applications will be completely re-designed across the organization during the desktop virtualization project. These applications should also be consolidated during this stage.

Experience from the Field

Government: A government organization identified that there were 2,660 applications installed across their desktop estate. Most of which were installed by users with local administrative rights. By

following the application rationalization recommendations above, it was possible to reduce the number of applications required to 160.

Introduction to the Citrix NetScaler Product Line

Introduction to the Citrix NetScaler Product Line

The Citrix NetScaler product line optimizes delivery of applications over the Internet and private networks, combining application-level security, optimization, and traffic management into a single, integrated appliance. You install a Citrix NetScaler in your server room and route all connections to your managed servers through it. The NetScaler then applies the features you enable and the policies

you set to incoming and outgoing traffic.

In This Chapter

Citrix NetScaler Editions

Citrix NetScaler Hardware Platforms

Citrix NetScaler Editions

Citrix NetScaler software consists of the following three editions:

• Citrix NetScaler, Standard Edition. Provides small and medium enterprises with comprehensive Layer 4- Layer 7 (L4-L7) traffic management, enabling increased Web application availability.

• Citrix NetScaler, Enterprise Edition. Provides Web application acceleration and advanced L4-L7 traffic management, enabling enterprises to increase Web application performance and availability and reduce data center costs.

• Citrix NetScaler, Platinum Edition. Provides a Web application delivery solution that reduces data center costs and accelerates application performance, with end-to-end visibility of application performance, and provides advanced application security.

Note: These editions are controlled by licenses. For instructions on how to obtain and install licenses, refer to the Citrix Hardware Installation and Setup Guide.

NetScaler functionality is available on the 7000, 9010, 10010, 12000, 15000, and 17000 hardware platforms.

A NetScaler can be integrated into any network as a complement to existing load balancers, servers, caches, and firewalls. It requires no additional client or server side software, and can be configured using the NetScaler Web-based GUI and CLI configuration utilities. The following table summarizes the features supported by the Citrix NetScaler Application Delivery product line:

Note: While we have taken care to ensure absolute accuracy when compiling this information, it might change. We strongly recommend that you visit our Web site at http://www.citrix.com for the latest information.

Citrix NetScaler Hardware Platforms

A NetScaler is available on the following hardware platforms, each of which supports some combination of Fast Ethernet and Gigabit interfaces.

• Citrix NetScaler 7000

• Citrix NetScaler 9010

• Citrix NetScaler 10010

• Citrix NetScaler 12000

• Citrix NetScaler 15000

• Citrix NetScaler 17000

Note: For more information about the hardware platforms, see the “Introducing the Citrix NetScaler Hardware Platforms” chapter in Citrix Hardware Installation and Setup Guide.

Device Manager 8.7.1 and App Controller 2.10

Device Manager 8.7.1 and App Controller 2.10

Supported NetScaler Gateway versions: 10.1.126.1203.e and 10.1.124.1308.e

* MDX Toolkit 2.3 and 2.2.1 do not support WorxNotes.

** Not applicable

Device Manager 8.6.1 and App Controller 2.9

Supported NetScaler Gateway version: 10.1.124.1308.e

* MDX Toolkit 2.2.1 does not support WorxNotes.

** Not applicable

Supported Device Platforms in XenMobile

XenMobile 10.x supports devices running the following platforms for enterprise mobility management, including app and device management. Due to platform restrictions and security features, not all functionality is supported on all platforms.

To support older versions of mobile operating systems, such as Android 4.1 and iOS 7, see in the

Citrix Support Knowledge Center.

Android

XenMobile 10.3

Operating systems supported for all modes: Android 4.4.x, 5.x, 6.x

Operating systems supported for MDM-only mode: Android 4.1.x, 4.2.x, 4.3

Worx Home is supported on x86-based Android devices for MDM capabilities. App management is ONLY available on ARM-based Android devices. With the MDX Toolkit 10.3, MDX wrapped enterprise apps are supported on Android x86- based devices.

MDX-wrapped applications are not supported on Android x64-based devices.

Some Android devices used for testing with XenMobile 10.3 on the operating systems listed above are:

Nexus 10, 7, 5, 9

Samsung Galaxy S4 and Note 3, 4, 5

Galaxy Tablet 2, S3, S4, S5

HTC One

Samsung Tablet P750

Samsung S6 and S6 Edge

OnePlus X

XenMobile 10 and 10.1

Operating systems supported for all modes: 4.4.x, 5.x, 6.x

Operating systems supported for MDM-only mode: 4.1.x

Android 4.2 and 4.3 are not supported.

Worx Home is supported on x86-based Android devices for MDM capabilities. App management is only available on Android devices with ARM-based processors. MDX-wrapped applications are not supported on Android x86-based devices.

Some Android devices used for testing with XenMobile 10 and 10.1 on the operating systems listed above are:

Nexus 10, 7, 5, 9

Galaxy S4 and Note 2, 3

Galaxy Tablet 2, S3, S4, S5

Moto X

HTC One

HTC Desire, LG

Samsung Tablet P750

These devices are supported for device management only:

Android 3.0–3.2

Android 2.3

SAFE and KNOX

On compatible Samsung devices, XenMobile 10.x supports and extends both Samsung for Enterprise (SAFE) and Samsung KNOX policies. You must enable the SAFE APIs by deploying the built-in Samsung Enterprise License Management (ELM) key to a device before you can deploy SAFE policies and restrictions. To enable the Samsung KNOX API, you also need to purchase a Samsung KNOX license by using the Samsung KNOX License Management System (KLMS) in addition to deploying the Samsung ELM key.

XenMobile supports Amazon Kindle devices running Fire OS 3.0 and earlier versions running proprietary operating systems based on Android.

For HTC-specific policies, XenMobile supports HTC API version 0.5.0. In the case of Sony-specific policies, XenMobile supports Sony Enterprise SDK 2.0.

iOS

XenMobile 10.3

iOS 9.x

iOS 8.4.x

Some iOS devices that XenMobile 10.3 supports:

iPhone 5, 5s, 5c, 6, 6+

iPad 2, 3

Mac OS X

MacBook, Air, Mini, Mini Retina 10.9.5, 10.10, 10.11

XenMobile 10 and 10.1

iOS 9.x

iOS 8.4.x

Some iOS devices that XenMobile 10 and 10.1 support:

iPhone 5, 5s, 5c, 6, 6+

iPad2, 3, Mini, Air, Air2, Mini Retina

Capabilities Assessment

Capabilities Assessment

The information captured during the capabilities assessment will be used to achieve the following objectives:

1. Identify risks – Like traditional desktops, desktop virtualization is dependent on a wide range of supporting technologies, including storage, networking, directory services and applications. In many

cases, issues reported with virtual desktops are a symptom rather than a cause. For example, slow performance and disconnected sessions are more often caused by periods of high-latency than a desktop specific issue. Therefore, a desktop virtualization project is an excellent opportunity to review an organization’s existing infrastructure to ensure that it provides a good solid foundation upon which to build a virtual desktop solution. Any risks identified should be reported to the project

manager so that they can be addressed appropriately.

2. Create roadmap – The capabilities assessment provides the project team with a detailed understanding of the existing environment so that they can estimate implementation time for each user group and prioritize the implementation order.

3. Virtual desktop design – Provide the project team with detailed information on the current state of the environment so that they can successfully integrate the new virtual desktop solution. The capabilities assessment should also determine whether existing infrastructure components can be leveraged or whether new infrastructure needs to be purchased, for example shared storage and virtualization technologies.

Key results from the capabilities gathering exercise should be documented in the Citrix Capabilities Assessment template. A list of questions has been provided per infrastructure technology to highlight key information that needs to be collected. These questions are based on the experiences of Citrix Consulting across numerous desktop virtualization projects and should be answered by the appropriate technology architect for each section. Not all sections need to be completed, for example if the organization does not already have a Citrix environment this section can be left blank. The length of the capabilities assessment will vary based on the size and complexity of the environment but typically takes about three days to complete.

Citrix Consulting Tips for Success

1. Discussions – Meet with the architects rather than sending them a questionnaire so that additional questions can be raised, diagrams drawn and detailed explanations provided.

2. Schedule meetings – It is advisable to schedule meetings with the architects well in advance to ensure availability. Provide each architect with a copy of the questions that you plan to ask them so that they can prepare appropriately. Also, when scheduling the meetings request any relevant documentation for background reading as this may prompt additional questions and discussions.

3. Documentation – Use the capabilities assessment template to capture your discussions with the architects. The document can then be circulated amongst the project team to ensure that everybody has the same information.

4. Future initiatives – Ask the architects whether they are planning any future initiatives, for example upgrading to a new product version, or adjusting the architecture. This will ensure that the

project team is aware of all upcoming changes.

5. Identify risks – It is important that all risks are identified as early as possible so that they can be tracked and appropriate action taken. Risks should be graded in severity and if possible remediation plans should be created stating an estimated timeframe and cost.

How a Citrix NetScaler Communicates with Clients and Servers

How a Citrix NetScaler Communicates with Clients and Servers

A NetScaler is usually deployed in front of a server farm and functions as a transparent TCP proxy between clients and servers, without requiring any clientside configuration. This basic mode of operation is called Request Switching technology and is the core of NetScaler functionality. Request Switching enables a NetScaler to multiplex and offload the TCP connections, maintain persistent

connections, and manage traffic at the request (application layer) level. This is possible because the NetScaler can separate the HTTP request from the TCP connection on which the request is delivered.

Depending on the configuration, a NetScaler may process the traffic before forwarding the request to a server. For example, if the client attempts to access a secure application on the server, the NetScaler might perform the necessary SSL processing before sending traffic to the server. To facilitate efficient and secure access to server resources, a NetScaler uses a set of IP addresses collectively known as NetScaler-owned IP addresses.

Understanding NetScaler-owned IP Addresses

To function as a proxy, a NetScaler a uses a variety of IP addresses. The key NetScaler-owned IP addresses are:

• Mapped IP address (MIP). The MIP is used for server-side connections. It is not the IP address of the NetScaler. In most cases, when the NetScaler receives a packet, it replaces the source IP address with the MIP before sending the packet to the server. With the servers abstracted from the clients, the NetScaler manages connections more efficiently.

• Virtual server IP address (VIP). A VIP is the IP address associated with a vserver. It is the public IP address to which clients connect. A NetScaler managing a wide range of traffic may have many VIPs configured.

• NetScaler IP address (NSIP). The NSIP is the IP address for general system and management access to the NetScaler itself.

• Subnet IP address (SNIP). When the NetScaler is attached to multiple subnets, SNIPs may be configured for use as MIPs providing access to those subnets.

How Traffic Flows Are Managed

Because a NetScaler functions as a TCP proxy, it translates IP addresses before sending packets to a server. When you configure a vserver, clients connect to a VIP on the NetScaler instead of directly connecting to a server. Based on the settings on the vserver, the NetScaler selects an appropriate server and sends the client's request to that server. By default, the NetScaler uses the MIP to establish

connections with the server, as illustrated in the following diagram.

In the absence of a vserver, when a NetScaler receives a request, it transparently forwards the request to the server. This is called the transparent mode of operation. When operating in transparent mode, a NetScaler translates the source IP addresses of incoming client requests to the MIP but does not change the destination IP address. For this mode to work, L2 or L3 mode needs to be configured appropriately.

For cases in which the servers need the actual client IP address, the NetScaler can be configured to modify the HTTP header by inserting the client IP address as an additional field, or configured to use the client IP address instead of the MIP for connections to the servers.

Traffic Management Building Blocks

The configuration of a NetScaleris typically built up with a series of virtual entities that serve as building blocks for traffic management. The building block approach helps separate traffic flows. Virtual entities are abstractions, typically representing IP addresses, ports, and protocol handlers for processing traffic. Clients access applications and resources through these virtual entities. The most

commonly used entities are vservers and services. Vservers represent groups of servers in a server farm or remote network, and services represent specific applications on each server.

Most features and traffic settings are enabled through virtual entities. For example, you can configure a NetScaler to compress all server responses to a client that is connected to the server farm through a particular vserver. To configure the NetScaler for a particular environment, you need to identify the

appropriate features and then choose the right mix of virtual entities to deliver them. Most features are delivered through a cascade of virtual entities that are bound to each other. In this case, the virtual entities are like blocks being assembled into the final structure of a delivered application. You can add, remove, modify, bind, enable, and disable the virtual entities to configure the features.The following diagram illustrates the concepts covered in this section.

XenMobile device enrollment

XenMobile device enrollment

For information about XenMobile enrollment options for the different device platforms, see .

XenMobile support

For details on how to access supported related information and tools in the XenMobile console, see

and Maintenance.

Supporting Mobile Platforms in XenMobile Cloud

After you make a request for a XenMobile Cloud instance, you can, if you like, begin preparing to support Android, iOS, and Windows platforms. As you complete the steps that apply to your environment, keep the information handy so you can use it when configuring settings in the XenMobile console. 

Note that these requirements are a subset of the overall communication and port requirements that make up the XenMobile Cloud onboarding process. For details, see . 

Android

Create Google Play credentials. For details, see Google Play .

Create an Android for Work administrator account. For details, see in XenMobile.

Verify your domain name with Google. For details, see .

Enable APIs and create a service account for Android for Work. For details, see .

iOS

Create an Apple ID and developer account. For details, see the website.

Create an Apple Push Notification service (APNs) certificate. For details, see the Portal.

Create a Volume Purchase Program (VPP) company token. For details, see Program.

Windows

Create a Microsoft Windows Store developer account. For details, see the .

Obtain a Microsoft Windows Store Publisher ID. For details, see the .

Acquire an enterprise certificate from Symantec. For details, see the .

Create an Application Enrollment Token (AET). For details, see the .

Assess the Environment

Assess the Environment

The data capture process collects key information on users, devices, applications and infrastructure that will be required during subsequent phases of the project.

Data Capture Strategy

There are three main techniques that can be used to collect data:

• Manual - For small organizations, it is possible to capture user and application data by visiting each desktop in person or by connecting remotely. Performance counters can be used to acquire raw user data while the Add / Remove Programs applet in Windows XP or the Programs and Features applet

in Windows 7 and Windows 8 can be used to provide a list of installed applications as well as information on how often they are accessed. 

Most medium and large-sized organizations use an enterprise software deployment (ESD) tool such as Microsoft System Center Configuration Manager (SCCM). Since the ESD solution is typically the sole method of deploying application packages to workstations, the project team can query the ESD software to identify which applications are assigned to which desktops. However, most ESD solutions do not provide details on application performance requirements, application usage metrics or user installed applications. In addition, significant effort may be required to extrapolate, analyze and document application and desktop information from the ESD tool. 

The problem with the manual approach is that it is difficult to gain a good understanding of each user and application’s performance requirements over time. In addition, the manual approach is very time intensive per desktop making it inappropriate for medium and large-sized organizations. It can also be difficult to query application requirements of mobile users who may spend extended periods of time away from the office.

• Survey - A questionnaire can be created and distributed to each business manager to identify user and application requirements within their departments. Questionnaires are far less time consuming for the project team than the manual approach because the focus is upon the department managers to identify the applications necessary for their employees to complete their jobs. However, it is unlikely that every manager within the organization will complete the questionnaire and a completion ratio of 70% should be considered normal. The results from a questionnaire are typically less accurate than the manual or automated approach. Although less time consuming than the manual approach, considerable effort is still required to extrapolate, analyze and document the results from the returned

questionnaires.

• Automated - There are a variety of automated inventory tools available that allow for a wide range of information to be collected, including applications installed, access frequency, and performance requirements. This data is uploaded to a central database so that reports can be generated across the

entire user and desktop estate. To help reduce the cost and complexity of desktop virtualization projects, Citrix has partnered with Lakeside Software to provide Citrix Project Accelerator users

with a free 60-day license of Lakeside FastTrack. FastTrack is a sophisticated inventory tool that has been developed based on Citrix methodologies, terminology and best practices. An example LakeSide FastTrack report is available from the LakeSide website. An automated inventory tool is a great solution for medium and large-sized organizations; however the centralized infrastructure and agent deployment effort is unlikely to be appropriate for very small organizations due to the time required when compared to the manual method. In addition, some organizations may not allow inventory agents to be installed across the desktop estate or may not have rights to install the agent on user-owned desktops.

Although the automated method is accurate, fast, and does not inconvenience employees, there are a number of business characteristics that automated tools cannot identify. For example, what is the criticality of the user, will the user need to work offline and should access to the application be restricted due to security or licensing restrictions? Therefore, the recommended approach is to use the automated method to identify technical characteristics and a questionnaire to identify the business characteristics. The User Segmentation and Link Apps to Users sections provide detailed information on the user and application characteristics that you will need to collect. Key results from the user data gathering exercise should be documented in the assess spreadsheet.