Friday 30 September 2016

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
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

• 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.

Managing Your Desktop Delivery Controller Deployment

Managing Your Desktop Delivery Controller Deployment

Overview

This section describes how to carry out the following tasks:

• Putting desktops into maintenance mode.
• Managing sessions. You can view, disconnect, and log off sessions. You can also send messages to users.
• Manually controlling VMs.
• Migrating controllers to other farms.
• Migrating desktops to other farms.
• Updating license server settings.

The details of all these tasks are described in the following topics. Other general management tasks, such as configuring connections and securing farms, are described in detail in the Citrix Presentation Server Administrator’s Guide.

Putting Desktops into Maintenance Mode

If you want to temporarily stop connections to a desktop so that maintenance tasks can be carried out, you can put the desktop into maintenance mode. If the desktop is in a group that uses the idle pool settings, note that it will be entirely under manual control until you take it out of maintenance mode again.

To put a desktop into maintenance mode

1. Select the relevant desktop group.
2. Select the Virtual Desktops view so that all the desktops for that group are listed.
3. Select the relevant desktop.
4. From the task pane, select Enable maintenance mode.

No user can now log on to that desktop. If a user is logged on when you select maintenance mode, maintenance mode takes effect as soon as that user logs off. If a user tries to connect to an assigned desktop while it is in maintenance mode, a message appears telling them that the desktop is currently unavailable and to try reconnecting.

When a desktop is in maintenance mode, the Disable maintenance mode task becomes available. To take a desktop out of maintenance mode, select the desktop, then select Disable maintenance mode.

Managing Sessions

To view sessions for a desktop group

1. Select the relevant desktop group in the console tree.
2. Select the Virtual Desktops In Use view.

To view all sessions for a particular user

1. From the Search options in the tasks pane, select Advanced search.
The Advanced Search dialog box appears.
2. From the Find list, select Session by user.
3. Type the user name.
4. Select the relevant node of the console tree (for example, Desktop Groups).
5. Click Search.

To disconnect or log off a session

1. From the Virtual Desktops In Use view, select the session.
2. From the task pane, select Disconnect or Logoff respectively.

If you log off a session, it closes and the desktop becomes available to other users, unless it is assigned to a specific user.

If you disconnect a session, the user’s applications continue to run and the desktop remains assigned to that user. If the user reconnects, the same desktop is assigned. You can configure a time-out to ensure that disconnected sessions are logged off automatically after a certain number of minutes; for further information about this, see “Configuring Connection Timers”

To send a message to users

1. From the task pane, select Send message.
2. In the dialog box that appears, type your message, then click OK to send the message to all selected users.

Manually Controlling Virtual Machines

For VM-based desktop groups, you can manually control VMs through the Access Management Console.

To start virtual machines

1. Select the relevant desktop group in the console tree.
2. From the Virtual Desktops view, select the relevant desktops.
3. To start powered-off or suspended VMs, from the Tasks list, select Start. 
The VMs are powered-on or resumed and the list of desktops is refreshed to show the new state.

To shut down and restart virtual machines

1. Select the relevant desktop group in the console tree.
2. From the Virtual Desktops view, select the relevant desktops.
3. From the Tasks list, select Shutdown/suspend. The Shutdown/Suspend Virtual Machine dialog box appears.
4. Select from the following options. Depending on the state of the machine, some of these options may not be available:

• Shutdown. Requests the VM’s operating system to shut down.
• Power off. Forcibly powers off the VM and refreshes the list of
desktops.
• Shutdown and Restart. Requests the VM’s operating system to shut down and then start the VM again. If the operating system is unable to do this, the VM remains in its current state.
• Power off and Restart. Forcibly restarts the VM.
• Suspend. Pauses the VM without shutting it down and refreshes thelist of desktops.

Migrating Controllers to Other Farms

If, for example, you want to move a controller from a test or pilot farm into production, you may need to migrate it to another farm. To do this, you need Active Directory permissions over the OU structure of both the controller’s existing farm and the controller’s new farm.

If you remove all the controllers from a farm, Citrix recommends that you delete the farm OU.

Citrix recommends that you do not move controllers to a farm created using an earlier version of XenDesktop, Desktop Delivery Controller or Desktop Server; if you do this your farm may become unusable.

To migrate a controller to another farm

1. Remove the controller from the old farm OU. To do this, use the ADSetup tool with the REMOVECONTROLLER parameter, as described in “Configuring Active Directory Using ADSetup”
2. Use the chfarm utility to either create a new farm (if this is the first controller in the farm) or move the controller to the new farm (if this is the second or subsequent controller in the farm). For further information on chfarm, see the Citrix Presentation Server Administrator’s Guide. 
When using chfarm to move a controller to a new farm, make sure you configure the zone name, zone preference, and license server details correctly, because you cannot easily change these later.
3. Add the controller to the new farm OU. To do this, use the ADSetup tool with the ADDCONTROLLER parameter, as described in “Configuring Active Directory Using ADSetup
4. Restart the controller to make the new farm settings take effect.

Migrating Desktops to Other Farms

1. Remove the desktops from the desktop group in the old farm. For details of how to do this, see “To update a desktop group” 
2. Note the farm GUID of the new farm. This is one of the read-only farm properties in the Access Management Console.
3. In the new farm, add the desktops to an existing or new desktop group. There are various ways in which you can do this; for details, see “Creating and Updating Desktop Groups” 
4. Apply the new farm’s GUID to the desktops. To do this, use Group Policy. The Desktop Delivery Controller Farm GUID policy enables you to use a generic desktop image with multiple XenDesktop deployments. The administrative template (ADM) file is supplied on the Desktop Delivery Controller installation media: 
platform\lang\support\configuration\FarmGUID.adm 
For information about how to use ADM files, consult your Active Directory documentation.
5. Check the registry to ensure that the group policy has propagated to the desktop computer, then restart the computer. This registers the desktop with a controller in the new farm. Until you do this, the desktop is not available to users.

Updating License Server Settings

During installation you specify the name of the license server your farm accesses to check out licenses and the port number the license server uses to communicate.

You may want to change these settings in the following instances:

• You rename your license server
• The default port number (27000) is already in use
• You have a firewall between the license server and the computers running your Citrix products, and you must specify an alternative Citrix vendor daemon port number

Use the License Server page of the farm’s properties to change the name of the license server or port number that the license server uses to communicate. You can apply the changes to either an individual server or an entire farm. You must also take the following actions:

• If you decide to change the license server name, first ensure that a license server with the new name already exists on your network. Because license files are tied to the license server’s host name, if you change the license server name, you must download a license file that is generated for the new license server. This may involve returning and reallocating the licenses. To return and reallocate your licenses, go to www.mycitrix.com. For additional information, see Licensing: Migrating, Upgrading, and Renaming, which you can download from http://support.citrix.com/pages/licensing/.

• If you change a port number, you must specify the new number in all license files on the server. For additional information, see Licensing: Firewalls and Security Considerations, which you can download from http://support.citrix.com/pages/licensing/.

To specify a license server for the farm

1. In the left pane of the Access Management Console, select the farm.
2. From the Action menu, select Modify farm properties > Modify all properties.
3. From the Properties list, select License Server.
4. Enter the name or IP address of the license server in the Name box.
5. Enter the license server port number in the Port number (default 27000) box.
6. Click Apply to implement your changes.

To specify a license server for an individual controller

1. In the left pane of the Access Management Console, select the controller.
2. From the Action menu, select Modify controller properties > Modify license server properties.
3. Clear the Use farm settings check box.
4. Enter the name or IP address of the license server in the Name box.
5. Enter the license server port number in the Port number (default 27000) box.

Thursday 22 September 2016

Command-Line Tools

Command-Line Tools
Tools are provided to enable you to install and remove controllers and the Virtual Desktop Agent using the command line. You can also use a command-line tool to configure Active Directory.

Installing and Removing Controllers Using Setup.exe
The Setup.exe file supports several command-line options for controlling the installation and removal of Desktop Delivery Controller.

If you control the installation through the command line, you must also configure Active Directory from the command line. For further information, see “Configuring Active Directory Using ADSetup” on page 122. You have to configure Active Directory not only when you create a new farm, but also when you add a controller to a farm.

Examples
The -passive option is an efficient way to install a large number of controllers compared with using the Installation wizard on individual controllers.

Example 1: Installing a Single Component
setup.exe -passive -components CONSOLES where CONSOLES (the management consoles) is the component you are installing.

Example 2: Installing all the Desktop Delivery Controller
Components on a Single Server setup.exe -passive -createfarm MyFarm
-components DDC,LIC_SERVER,CONSOLES
-edition STD
where:
MyFarm is the farm you are creating, DDC, LIC_SERVER, and CONSOLES are the components you are installing on the server, and you are licensed to use XenDesktop Standard Edition.

Example 3: Creating a New Controller and Adding it to a Farm
The following example shows how to create a new controller, installing only the core Desktop Deliver Controller component, and then add that controller to an existing farm that is using an external database on a separate server:
setup.exe -passive -joinfarm ele1985 -components DDC
-dsnfilepath c:\MF20.dsn -dbusername alexco -dbpassword libby02
where:
ele1985 is an existing controller in the farm, DDC is the component you want to install, c:\MF20.dsn is the path to the dsn file, alexco is the user name for accessing the database, and libby02 is the password for accessing the database.
In this example the MF20.dsn file was copied to the server before the installation process started.

Installing and Removing the Virtual Desktop Agent Using XdsAgent.msi
The Virtual Desktop Agent installer (XdsAgent.msi) supports the standard msiexec command-line options. For details of these options, go to:
http://msdn2.microsoft.com/en-us/library/aa367988.aspx

You can set the following properties as msiexec property arguments:
You must ensure that Microsoft .NET Framework 3.5 has already been installed before you install the Virtual Desktop Agent.

Configuring Active Directory Using ADSetup
configuration. You can use it to start the wizard described in “Configuring Active Directory” on page 50. You can also run it using any of the other parameters described in the table below.

Note: If you need to relocate or rename the farm OU, Citrix recommends that you use standard Active Directory management tools to do this.
Several of the options described in the table below refer to OU distinguished names. For more information about character-handling in these names, refer to:
http://msdn2.microsoft.com/en-us/library/aa366101(VS.85).aspx
and
http://www.ietf.org/rfc/rfc2253.txt