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.