wiki.autosys.tk

подготовка-к-экзамену-1y0-200-managing-citrix-xendesktop-7-solutions

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Раздел 1: Managing Citrix XenDesktop 7 Solutions

1.1 - Работа с образами серверных и клиентских ОС (в том числе каталогами машин и группами доставки).

Обновление существующего каталога машин до новой версии XenDesktop 7.

http://support.citrix.com/proddocs/topic/xendesktop-7/cds-upgrade-catalog.html
Обновлены могут быть только каталоги машин на базе Windows 7 и Windows 8.
Remote PC Access не поддерживается ОС Windows Vista.
Для ОС Windows XP и Vista обновления VDA до версии 7 нет.

While performing a random allocation type catalog update after updating the master image, the only valid options are

Immediately

‘On the next restart’

A restart can be delayed but not scheduled.

XenDesktop > XenDesktop 7 > Manage > Machine
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-update-master-vm-rho.html

Image
https://citrixxperience.com/content/wp-content/uploads/2013/10/update-machines.jpg

1.2

Task Description: Create Citrix Policies

Testing Aspect: How

A policy is assigned to all objects in the site.

Set priority to 1 to over-write existing policies settings.
1 is the highest priority.
Deny mode
Excludes a policy from applying to the assignment.
By default, new policy is created with largest number for priority.
The lowest priority.

XenDesktop > XenDesktop 7 > Manage > Manage Citrix policies > Use multiple policies > Prioritize policies and create exceptions
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-policies-multiple-prioritizing-rho.html

Private Desktop is also called pooled VDI.

Shared Desktop is also called XenApp published desktop.

Private Application is a published application on a VM.

Shared Application is also called XenApp published application.

Please note: The Citrix eDoc site shows the ‘Assignment type’ as ‘Desktop type’ but the actual product shows it as Delivery Group type.

XenDesktop > XenDesktop 7 > Manage > Manage Citrix policies > Apply policies > To apply a policy
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-policies-applying-task-rho.html

Image
https://citrixxperience.com/content/wp-content/uploads/2013/09/assign-policy.jpg

1.3

Task Description: Create Citrix policies (including printing policies)

Testing Aspect: When

To utilize auto updating of Controllers, an administrator should use Citrix Studio to create and configure a Citrix policy.

Updating the registry of the master image is a manual self-managed method.

To perform an OU-based Controller discovery, run the Set-ADControllerDiscovery.ps1 PowerShell script on the Controller.

XenDesktop > XenDesktop 7 > Manage > Delivery Controller environment > Automatically update
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-mng-cntrlr-autoupdate.html

1.4

Task Description: Manage license usage

Testing Aspect: How

In the Citrix admins group, to assign permissions to administrator to manage a Citrix license server:

Use Citrix Studio to add Citrix admins in Administrators.
Adding a Citrix admin to Domain admins would be correct only if the license server is co-located on Controllers.
Adding a Citrix admin to Licensing administrators only assigns rights in XenDesktop Citrix Studio, not the licensing portion.

XenDesktop > XenDesktop 7 > License > Manage Licensing > To add a licensing administrator group
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-licensing-management.html

1.5

Task Description: Delegate administrative rights

Testing Aspect: How

To view configuration logs:

Use Citrix Studio.
Select Logging in the left pane.

View Configuration Logs rights.

Full Administrator
Read Only Administrator

Always use ‘Read only’ role when View Configuration Logs and minimum rights are needed.

XenDesktop > XenDesktop 7 > Manage > Delegated Administration
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-manage-delegatedadmin.html

Want a PDF of the full 1Y0-200 study guide?
Enter your email and click Join!

1.6

Task Description: Publish server/desktop OS-hosted applications

Testing Aspect: How

To publish an application installed locally on Master Image:

Use Citrix Studio > Delivery Groups > Applications tab.
Click Create Application.
Select a Delivery Group and click Next.
Select an application and click Next.

XenDesktop > XenDesktop 7 > Deliver > Delivery Groups
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-create-update-desktops-wrapper-rho.html

1.7

Task Description: Modify virtual machine settings (XenServer)

Testing Aspect: How

To isolate Personal vDisk to a new storage:

A new writeable shared storage must be first presented to XenServer pool.
NFS storage

OR
FC storage

When share storage is presented:

Use Citrix Studio > Hosting.
Select the XenServer resource.
Click Add Storage.

CIFS share is a read-only storage type for XenServer.

Personal vDisk cannot be attached to master image.

Please note: eDocs describes the concept of Personal vDisk, which should be separate from master image, so master image can be updated without losing personal settings.

XenDesktop > XenDesktop 7 > Manage > Personal vDisks
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-about-personal-vdisks.html

1.8

Task Description: Create device collections, target devices, and vDisks (using the XenDesktop wizard, PV wizard, and manually)

Testing Aspect: How

Correct steps to create a device collection in PVS Console areIn the Console, right-click the Device Collections folder where the new collection will exist:

Select the ‘Create device collection’ menu option.

OR
Select Device Collections folder, click Action from the menu, and select Create Device Collection.
The Device Collection Properties dialog will appear.
On the General tab, type a name for the new device collection in the Name text box.
A description of the collection in the Description text box.
Click the Security tab.
Under the Device Administrators list, click Add.
The Add Security Group dialog will appear.
To assign a group with the Device Administrator role:
Type or select the appropriate domain and group name in the text box and click OK.
Under the Device Operators list, click Add.
The Add Security Group dialog will appear.
To assign a group with the Device Operator role:
Type or select the appropriate domain and group name in the text box and click OK.
Click OK to close the dialog box.

Technologies > Provisioning Services > Provisioning Services 7.0 > Provisioning Services Administration > Managing Device Collections > Device Collection Management Tasks
http://support.citrix.com/proddocs/topic/provisioning-7/pvs-collections-create.html

The following are the necessary prerequisites when creating a vDisk:

Enable Windows Automount on Windows Server operating systems.

Disable Windows Autoplay.

Verify adequate free space exists in the vDisk store.

Approximately 101% of used space on the source volumes.

Make a note of which NIC(s) the master target device was bound to when the Provisioning Services software was installed on the target device.

If a message appears during imaging prompting for reboot, ignore the request until imaging has completed successfully.

Technologies > Provisioning Services > Provisioning Services 7.0 > Installing and configuring Provisioning Services > Creating vDisks Automatically
http://support.citrix.com/proddocs/topic/provisioning-7/pvs-vdisks-image-wizard.html

1.9

Task Description: Manage Personal vDisk

Testing Aspect: What (considerations need to be made)

Personal vDisks are only supported with a desktop OS:

Windows XP

Windows 7

Windows 8

Server OS is not supported.

There can be only one personal vDisk per machine.

Personal vDisk can be moved to another machine if needed.

The minimum size of personal vDisk is 3GB.

Personal vDisk can be placed on any hypervisor supported storage.

It does not necessarily have to be on the same storage as the base VDI image.

XenDesktop FAQ – Personal vDisk
http://support.citrix.com/article/CTX131553

1.10

Task Description: Configure/Modify NetScaler Gateway Policies

Testing Aspect: When

A session policy is a collection of expressions and settings that are applied to:

Users

Groups

Virtual servers

Globally

Session policies are used to configure the settings for user connections, such as:

Defining settings to configure users to log on with the NetScaler Gateway Plug-in for Java or NetScaler Plug-in for Windows.

Session policies are evaluated and applied after the user is authenticated.

Traffic policies allow the configuration of settings for user connections, including:

Enforcing shorter time-outs for sensitive applications that are accessed from untrusted networks.

Switching network traffic to use TCP for some applications.

Identifying situations where other HTTP features for NetScaler Gateway Plug-in traffic should be used.

Defining the file extensions that are used with file type association.

File type association allows users to open documents in applications published through Citrix XenApp or Citrix XenDesktop 7.

NetScaler Gateway > NetScaler Gateway 10.1 > Configure > Configuring Policies and Profiles on NetScaler Gateway
http://support.citrix.com/proddocs/topic/NetScaler-gateway-101/ng-policies-profiles-wrapper-con.html

1.11

Task Description: Configure the store (include remote access and access for mobile devices)

Testing Aspect: How

To make a store and other resources on an internal network available through an SSL VPN tunnel.

Select ‘Full VPN tunnel’.

Users require the NetScaler Gateway Plug-in to establish the VPN tunnel.

If an appliance running NetScaler Gateway 10.1, Access Gateway 10, or Access Gateway 9.3 is added, select from the ‘Logon type’ list the authentication method configured on the appliance for Citrix Receiver users.

The information that is provided during configuration of the NetScaler Gateway appliance is added to the provisioning file for the store, which enables Citrix Receiver to send the appropriate connection request when contacting the appliance for the first time.

If users are required to enter both their domain credentials and a token code obtained from a security token, ‘Domain and security token’ should be selected.

Other selections that can be made, depending on the requirements, are:

Domain
‘Security token’
‘SMS authentication’
‘Smart card’

Technologies > StoreFront > StoreFront 2.1 > Manage > Configure stores
http://support.citrix.com/proddocs/topic/dws-storefront-21/dws-manage-store.html

Image
https://citrixxperience.com/content/wp-content/uploads/2013/10/enable-remote-access.jpg

Image
https://citrixxperience.com/content/wp-content/uploads/2013/10/change-general-settings.jpg

Section 2: Maintaining Citrix XenDesktop 7 Solutions

2.1

Task Description: Back up/restore the XenDesktop database

Testing Aspect: How

XenDesktop utilizes SQL Server to handle database backup and restore.

To perform a one-time backup a XenDesktop 7 site database:

Verify the name of the database.
Verify the database server name.
Obtain the name of the database server data source.
Obtain the database name.
In Microsoft SQL Server Management Studio > Object Explorer:
Select Tasks > Backup.
Verify the backup is set to Full and click OK.
Verify the backup was successful.

How to Backup and Restore your XenDesktop Database
http://support.citrix.com/article/CTX135207

2.2

Task Description: Update the desktop image

Testing Aspect: What factors should be considered

In order for virtual machines to use an updated master image, the virtual machines must be restarted.

Please note that after updating the master image, the user devices must be restarted through Studio.
For the changes to take effect.
For the changes to be available to the users.

XenDesktop 7 > Manage > Machines > Update a master image
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-update-master-vm-rho.html

2.3

Task Description: Configure power management settings

Testing Aspect: When

To power manage Delivery Groups:

In Studio, select the Delivery Group node.
Select the desired Delivery Group power management settings.
Click Edit Delivery Group.

Click ‘Power management’.
Select Weekdays in ‘Power on/off machines’.
For random Delivery Groups, in ‘Machines to be powered on’:
Click Edit.
Specify the pool size during weekdays.
In ‘Machines to be powered on’:
Select the number of machines to power on.
In ‘Peak hours’:
Set the organization’s peak and off-peak hours during weekdays.
Set power state timers for peak and non-peak hours during weekdays.
Select Weekend.

XenDesktop 7 > Manage > Application and desktop delivery > Power manage Desktop OS machines
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-control-power-management-rho.html

2.4

Task Description: Backup/restore XenServer metadata

Testing Aspect: How

To configure a recurring backup of XenServer virtual machine metadata in a XD 7 deployment:

Use the fdisk -l command to determine the device file needed for the USB storage device.
Create the storage repository on the USB storage device.
In the XenServer console (accessible with xsconsole using the command line interface in the XenCenter):
Select ‘Backup, Restore and Update’.
Select Backup Virtual Machine Metadata.
Select the new storage repository created earlier using the xe sr-create command.
Proceed with VM backup using a thumb drive or other USB drive.

How to Back Up Virtual Machine Metadata to a USB Device
http://support.citrix.com/article/CTX121282

2.5

Task Description: Add additional storage to target devices

Testing Aspect: How

Adding a second drive to the master image can be a standard practice for many XenDesktop administrators.

The best method to add a second drive to the master image is to configure a vDisk for the master image and create C: and D: partition.
When the master image is prepared with C: and D: partitions, the administrator can deploy new virtual machines.
The VMs will have local D: drives.
Random Desktop OS machines will drop all of the configurations if rebooted if XenCenter is used to configure a D: drive on all of the VMs.
Use the ‘Net Use’ command to map a network drive; not a local drive.
Citrix policies can control how local Citrix client device drives map to a VDI session.

Although the following source is for a discontinued version of Provisioning Services, multiple partitions on a master image are still created using Provisioning Services.

Archive: How to Create a Two Partition Virtual Disk
http://support.citrix.com/article/ctx116698

Want a PDF of the full 1Y0-200 study guide?
Enter your email and click Join!

2.6

Task Description: Maintain vDisks

Testing Aspect: How

To add Personal vDisks to new hosts when configuring a new XenDesktop site:

Add Personal vDisks and storage for the Personal vDisks to existing hosts.

In Studio:
Click Configuration.
Click Hosting.
Select a host.
Click Add Personal vDisk Storage.
Specify the storage location.

XenDesktop 7 > Manage > Personal vDisks > Manage Personal vDisks
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-manage-personal-vdisks.html

(2.7 and 2.8 intentionally left out. See Citrix Education’s 1Y0-200 Exam Prep Guide)

2.9

Task Description: Configure StoreFront access scenario

Testing Aspect: How

There are three choices for remote access to StoreFront:

None
None means no remote access.
Only users on the internal network with connection to the StoreFront servers can access the store.
No VPN Tunnel
No VPN Tunnel is accessed through NetScaler in ICA Proxy mode.
Full access to the internal network is not provided.
Users do not need an Access Gateway Plug-in.
Full VPN Tunnel
Full VPN Tunnel means that users need Access Gateway Plug-in.
Users can have outside VPN access to the internal network through NetScaler.

Technologies > StoreFront > StoreFront 2.0 > Manage > Configure stores
http://support.citrix.com/proddocs/topic/dws-storefront-21/dws-manage-remote.html

2.10

Task Description: Configure Citrix Receiver updates

Testing Aspect: How

v The options that an administrator can choose when providing users of StoreFront with updates to Citrix Receiver:

Citrix (citrix.com)
Merchandising Server

Technologies > StoreFront > StoreFront 2.1 > Manage > Configure stores
http://support.citrix.com/proddocs/topic/dws-storefront-21/dws-manage-store.html

Image
https://citrixxperience.com/content/wp-content/uploads/2013/10/citrix-StoreFront.jpg

2.11

Task Description: Perform user profile maintenance

Testing Aspect: When

In a pooled VDI, when user login time significantly increases for one user while other users aren’t seeing an increase, the cause is most likely a bloomed or corrupted user roaming profile.

To resolve:

Reset the user’s roaming profile.
When the profile is reset, the user’s login behavior will be restored to normal.

XenDesktop 7 > Monitor > Monitor environment with Director > Troubleshoot user issue
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-help-reset-user-profile.html

Section 3: Monitoring Citrix XenDesktop 7 Solutions

3.1

Task Description: Use Director to monitor the environment

Testing Aspect: How

When troubleshooting a user or virtual desktop issue, the operator is able to shadow the end user by starting a Remote Assistance connection to the virtual desktop machine.

In XenDesktop 7, Citrix Director is the management console.
Remote Desktop is RDP, which can only have one session on Desktop OS, is not used for shadowing.
Shadow Taskbar is used in XenApp, not XenDesktop.

How to Enable Remote Assistance for Citrix Director
http://support.citrix.com/article/CTX127388

XenApp > XenApp 5 Feature Pack for Windows Server 2003 > XenApp Administration > Managing Session Environments and Connections > Viewing User Sessions
http://support.citrix.com/proddocs/topic/xenapp5fp-w2k3/ps-sessions-use-sess-shad-v2.html

Identifying and handling an unregistered VDI:

The administrator should use Citrix Director and filter State is Unregistered.
This shows a VDI’s State is Unregistered and means there is an issue with VDA to DDC communications.
This also includes the situation when Citrix Desktop Service is Stopped or Citrix Desktop Service is Started but still having issues communicating with the DDC.
The Last Connection Failure is historical data.
Using WMI and querying Citrix Desktop Service status is Stopped only shows the VDIs that the VDA service is stopped.
Citrix ICA Service is used to handle ICA sessions, but does not communicate with a DDC.

Troubleshooting XenDesktop brokering process
http://blogs.citrix.com/2012/07/23/troubleshooting-xendesktop-brokering-process-2

XenDesktop 7 > Monitor > Monitor environments with Director > Monitor deployments > Filter data to troubleshoot failures > Filter data to troubleshoot failures
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-use-create-filters.html

3.2

Task Description: Interpret Alerts in Citrix Director

Testing Aspect: How

In Citrix Director, Unavailable Capacity means that the Desktop/Server OS session is not available due to max capacity reached.

When Unavailable Capacity count is greater than 0, it means the VM in a Delivery Group has no more free sessions to hand out.

An administrator should add more VMs to the Delivery Group.

XenDesktop > XenDesktop 7 > Monitor Monitor environments with Director > Monitor deployments on the Dashboard
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-monitor-deployment-wrapper.html

Image
https://citrixxperience.com/content/wp-content/uploads/2013/10/unavailable-capacity-count.jpg

(3.3 intentionally left out. See Citrix Education’s 1Y0-200 Exam Prep Guide)

3.4

Task Description: Monitor Machine Processes and Failures

Testing Aspect: How

View processes running under a user’s VDI session with Citrix Director.

Citrix admins should also use Director to end non-responsive applications or processes.

XenDesktop 7 > Monitor > Monitor environments with Director > Troubleshoot user issues > Resolve application failures
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-help-app-failure.html

3.5

Task Description: Monitor the Virtual Delivery Agent

Testing Aspect: How

Using Citrix Director, administrators can monitor the Usage table.

The Usage table shows whether each machine is:
Off
Ready
Connected
Disconnected
Unregistered
When a machine’s registration state becomes unregistered, there is an issue with virtual delivery agent on the virtual machine.
A user will not be able to login to a VDI.
A disconnected user will not be able to re-connect back to a VDI.

This results in a login failed event.

The Category table can also be monitored for Unregistered machines.

Technologies > Desktop Director > Desktop Director 2.1 > Use > Interpreting the Information Displayed > Dashboard > Usage
http://support.citrix.com/proddocs/topic/director-210/director-dashboard-usage.html

Technologies > Desktop Director > Desktop Director 2.1 > Use > Interpreting the Information Displayed > Dashboard > Machines
http://support.citrix.com/proddocs/topic/director-210/director-dashboard-summary.html

An administrator can monitor machines from Director.

In the Director Dashboard, the Category table lists the machines in the following states, which might require action:

All
Unregistered
High CPU
High Latency
High Profile Load Time
Last Connection Failed
Pending Update

3.6

Task Description: Monitor Configuration Logging

Testing Aspect: How

Configuration Logging is provided through Citrix Studio > Logging.

Anyone that needs to view the logs should be in the Read Only Administrator role.

Don’t allow them the Full Administrator role.

XenDesktop > XenDesktop 7 > Manage > Configuration Logging
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-configlog-wrapper.html

Image
https://citrixxperience.com/content/wp-content/uploads/2013/10/configuration-logging.jpg

Want a PDF of the full 1Y0-200 study guide?
Enter your email and click Join!

3.7

Task Description: Monitor hosted server workload

Testing Aspect: How

IntelliCache is a XenServer host related feature.

The IntelliCache related counter is on a XenServer host.
There are three IntelliCache counters available on a XenServer host Performance tab:
IntelliCache Cache Hits
IntelliCache Cache Misses
IntelliCache Cache Size
Options to monitor Virtual Machine related counters include:
Performance Monitor
Resource Monitor
Selecting a Virtual Machine on a XenServer host’s Performance tab

XenDesktop > XenDesktop 7 > Manage > Connections and resources > Use IntelliCache with XenDesktop
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-manage-hosts-intellicache.html

Image
https://citrixxperience.com/content/wp-content/uploads/2013/10/xenserver-intellicache.jpg

The Hosts table in Director contains:

Health status icons
Display alerts about issues with:
XenDesktop Controller’s connection to a host
CPU
Memory
Bandwidth (network usage)
Storage
Alerts are based on thresholds defined by the hypervisor administrator.

Technologies > Desktop Director > Desktop Director 2.1 > Use > Interpreting the Information Displayed > Desktop Groups > Infrastructure
http://support.citrix.com/proddocs/topic/director-210/director-infrastructure-health.html

3.8

Task Description: Monitor System Performance

Testing Aspect: How (to interpret data)

Before an administrator investigates the reason for a user’s extended logon time, the administrator should:

Look at the user’s current and average logon duration.
Look at the Delivery Group average logon duration.

When an administrator needs further investigation for the extended logon time, the administrator should:

Ask the user to log off and log back on to observe the Logon Duration data.

Examine each phase of the logon process.
The total logon time is not an accurate sum of each of the phases.

XenDesktop > XenDesktop 7 > Monitor > Monitor environments with Director > Troubleshoot user issues > Diagnose user logon issues
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-help-logon-user.html

3.9

Task Description: Use PVS Auditing for Monitoring

Testing Aspect: How

Provisioning Services provides an auditing tool that records configuration actions on components within the Provisioning Services farm, to the Provisioning Services database.

This provides administrators with a way to troubleshoot and monitor recent changes that might impact system performance and behavior.
To enable auditing in the PVS Console:
Right-click on the farm.
Select the farm Properties menu option.
On the Options tab, under Auditing, check the Enable auditing checkbox.

Technologies > Provisioning Services > Provisioning Services 7.x > Provisioning Services Administration > Auditing
http://support.citrix.com/proddocs/topic/provisioning-7/pvs-audit-wrapper.html

3.10

Task Description: Monitor StoreFront logs

Testing Aspect: Monitor Profile Management

When StoreFront tracing is enabled:

Tracing information is written to files in the \Admin\Trace\ directory of the StoreFront installation.
Typically located at C:\Program Files\Citrix\Receiver StoreFront\.
The StoreFront installation log files can be found in C:\Windows\Temp\.
The web.config file for the authentication service, store, or Receiver for Web site, is typically located in the following directories:
C:\inetpub\wwwroot\Citrix\Authentication\
C:\inetpub\wwwroot\Citrix\storename\
C:\inetpub\wwwroot\Citrix\storenameWeb\
Logs created by Windows PowerShell commands are stored in the \Admin\logs\ directory of the StoreFront installation.
Typically located at C:\Program Files\Citrix\Receiver StoreFront\.

Technologies > StoreFront > StoreFront 2.1 > Troubleshoot StoreFront
http://support.citrix.com/proddocs/topic/dws-storefront-21/dws-troubleshoot.html

StoreFront supports Windows event logging for:

The authentication service
Stores
Receiver for Web sites

Any events that are generated are written to the StoreFront application log.

Events can be viewed using Event Viewer under:

Application and Services Logs > Citrix Delivery Services

Windows Logs > Application

Technologies > StoreFront > StoreFront 2.1 > Troubleshoot StoreFront
http://support.citrix.com/proddocs/topic/dws-storefront-21/dws-troubleshoot.html

3.11

Task Description: Monitor Profile Management

Testing Aspect: How (where to find it is implied)

Citrix Profile Manager logs errors in the Windows Event Log.

All other warnings and informational messages are logged in a file named UserProfileManager.log in the directory:

%SystemRoot%\system32\LogFiles\UserProfileManager\

Profile management collects data about the efficiency of a deployment using Microsoft Windows Performance Monitor (Perfmon) counters.

For each session, counters are stored under the object called Citrix Profile Management.

Technologies > Profile Management > Profile Management 3.x > Manage > Performance Optimization > Tuning Profiles > Monitoring and Logging Profile Management
http://support.citrix.com/proddocs/topic/user-profile-manager-kib/upm-perfmon.html

Technologies > Profile Management > Profile Management 3.x > Manage > Performance Optimization > Tuning Profiles > Monitoring and Logging Profile Management > About the Profile Management Log File
http://support.citrix.com/proddocs/topic/user-profile-manager-kib/upm-logging-about-den.html

3.12

Task Description: Monitor the event log for NetScaler

Testing Aspect: How

NetScaler natively supports logging to:

SYSLOG server

AND

NSLOG server
Either server can be running on:
A remote system.

On NetScaler.

Most deployments should have SYSLOG , NSLOG, or both in the environment, so configuring NetScaler to upload logs to one of them is an efficient solution.

NetScaler > NetScaler 10.1 > System > Administration
http://support.citrix.com/proddocs/topic/ns-system-10-1-map/ns-ag-asl-intor-wrapper-con.html

3.13

Task Description: Monitor NetScaler user sessions

Testing Aspect: How

The Citrix NetScaler appliance is a central point of control for all application traffic in the data center.

It collects flow and user-session level information valuable for:
application performance monitoring
analytics
business intelligence applications

AppFlow transmits the information by using the Internet Protocol Flow Information eXport (IPFIX) format.

Using UDP as the transport protocol, AppFlow transmits the collected data, called flow records, to one or more IPv4 collectors.
The collectors aggregate the flow records and generate real-time or historical reports.

NetScaler > NetScaler 10.1 > System > AppFlow
http://support.citrix.com/proddocs/topic/ns-system-10-1-map/ns-ag-appflow-intro-wrapper-con.html

Section 4: Troubleshooting a Citrix XenDesktop 7 Solution

4.1

Task Description: Troubleshoot issues related to communication between the Delivery Controller and other components

Testing Aspect: What is the root cause

Delivery Controllers communicate with XenServer:

Via HTTP on port 80.
Via HTTPs on port 443 when using a secure connection.
Delivery Controllers send commands to XenServer on port 80 or 443 to power on VMs.
If VMs can’t make new connections, chances are the Controllers are unable to communicate with XenServer on port 80 or port 443.
If the Delivery Controllers are unavailable then they can’t connect to XenServer hosts on any port.
New connections and reconnections will be affected.
Connected users will be ok.

Communication ports used by Citrix Technologies
http://support.citrix.com/servlet/KbServlet/download/2389-102-704421/CTX101810_28th_June_2013.pdf

4.2

Task Description: Troubleshoot Virtual Delivery Agent/client issues

Testing Aspect: What is the root cause

A Virtual Desktop Machine (VDM) must have an IP address to communicate on the network, so issues with registration can be attributed to:

A DHCP server being down.
Firewall changes.
The names of the DCs being changed.
Other changes in Group Policies.

A Virtual Delivery Agent (VDA) communicates with the Delivery Controllers (DCs) on port 80.

A VDA must be able to resolve the IP addresses of the DCs in order to register successfully.
If a VDA can’t resolve the IP address of the DCs due to DNS communication issue, registration will fail.
Blocking port 1494 will prevent Receiver from connecting to a VDM.
Kerberos settings allow for 5 minutes of time difference.
A lesser number of minutes delay between a VDM and DC will not cause registration issues.

Troubleshooting Virtual Desktop Agent Registration with Controllers in XenDesktop
http://support.citrix.com/article/ctx117248

4.3

Task Description: Troubleshoot Virtual Delivery Agent/client issues

Testing Aspect: How to resolve the issue

The Citrix Desktop Service manages communication between the Delivery Controller and Virtual Desktop Machines (VDMs). It handles:

initial brokering of connections.
settings for connections.
interaction with sessions.

Restarting the Citrix Desktop Service will cause a VDM to re-register with a Delivery Controller.

The Citrix Desktop Service is the display name.
BrokerAgent is the actual service name.

Used at the command line.
The Citrix ICA Service manages communication between the endpoint device and the VDM.
It does not handle the registration with the Delivery Controllers.
PorticaService is the actual service name for the Citrix ICA Service.

Troubleshooting XenDesktop brokering process
http://blogs.citrix.com/2012/07/23/troubleshooting-xendesktop-brokering-process-2

4.4

Task Description: Troubleshoot licensing issues

Testing Aspect: How to resolve the issue

Citrix license files are allocated on MyCitrix.com using the case sensitive license server name.

When license files are installed on a license server, any change to the server name or to the license file will invalidate them.
If a server name changes, an administrator must:
go to MyCitrix.com.
return the licenses.
reallocate the licenses using the new server name.

Technologies > Licensing Your Product > Citrix Licensing 11.11.1 > Backing up the license server
http://support.citrix.com/proddocs/topic/licensing-1111/lic-backup.html

Technologies > Licensing Your Product > Citrix Licensing 11.11.1 > Frequently Asked Questions for Licensing
http://support.citrix.com/proddocs/topic/licensing-1111/lic-faq.html

4.5

Task Description: Troubleshooting common printing issues

Testing Aspect: What is the root cause

When ‘Auto-create client printers’ is added to a policy, by default, all client printers are auto-created.

This setting only takes effect if ‘Client printer redirection’ is set to Allowed.

XenDesktop > XenDesktop 7 > Reference > Policy settings reference > ICA policy settings > Printing policy settings > Client Printers policy settings
http://support.citrix.com/proddocs/topic/xendesktop-7/ps-console-policies-rules-printer-clients-v2.html

4.6

Task Description: Troubleshoot user connectivity issues related to Application and Desktop launch

Testing Aspect: What is the root cause

If a user logs on to StoreFront Receiver for Web using a web browser while on the internal network and is presented with a list of applications, clicks an application, and receives a Citrix Receiver error message…

The issue is most likely that the user’s machine cannot communicate with the server running the application over port 2598.
Port 2598 is used when Session Reliability is enabled.
Session Reliability is enabled by default in XenDesktop 7.
If Session Reliability was disabled, port 1494 would be used.

Explaining ICA Session Reliability, Common Gateway Protocol, on TCP Port 2598
http://support.citrix.com/article/CTX104147

XenDesktop > XenDesktop 7 > Reference > Policy settings reference > ICA policy settings > Session Reliability policy settings
http://support.citrix.com/proddocs/topic/xendesktop-7/ps-ref-policies-session-reliability.html

XenDesktop Administration Guide, Page 191
http://citrix.edocspdf.com/media/output/en.xendesktop.cds-xd-7landing-page.pdf

4.7

Task Description: Troubleshoot user connectivity issues related to Application and Desktop launch

Testing Aspect: How to resolve the issue

With first time users, to avoid a machine taking an extra-long time before the login screen appears…

Select the Microsoft SVGA video driver for new dedicated virtual desktops.
When the WDDM video driver is installed and used on certain VDMs, users might experience:
a blank screen.
being unable to connect.
connecting briefly and then losing connection.
a long startup time if it’s their first time logging in Logging on to Windows 8.
a black screen might be presented to users during this process before the Start screen appears.

These issues will most likely be experienced with dedicated desktops when they are first assigned or with pooled-random desktops created with Provisioning Services.
To resolve any of these issues, uninstall the WDDM video driver and use the Windows SVGA video driver instead.

XenDesktop > XenDesktop 7 > About this release > Known issues
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-70-known-issues.html

Unable to Connect to XenDesktop Virtual Desktop Agent on Vista or Windows 7 with WDDM Driver
http://support.citrix.com/article/CTX124877

4.8

Task Description: Troubleshoot Citrix policies

Testing Aspect: How they are taking effect

If a policy is configured that doesn’t allow connections to client drives for an OU group and no one can connect to client drives…

The policy was probably configured with ‘Assign to all objects in a site’.
When assigning a policy to a defined group, avoid using ‘Assign to all objects in a site’ option.

XenDesktop > XenDesktop 7 > Manage > Manage Citrix policies > Create policies
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-policies-creating-rho.html

Image
https://citrixxperience.com/content/wp-content/uploads/2013/11/assign-to-all-objects-in-site.jpg

4.9

Task Description: Troubleshoot issues with application performance

Testing Aspect: What is the root cause

If a user tries launching an application hosted on a XenDesktop 7 App Edition Server and they receive an error that informs them that the application failed to start, a likely cause is…

Third-party software is using cmstart.exe and it modified environment variables to point to that executable.
Because XenDesktop 7 uses an executable named cmstart.exe for the launch of published applications, it might confuse and locate the cmstart.exe of the third party software instead.
By using the wrong version of cmstart.exe the launch process breaks.
XenDesktop 7 also modifies the environment variables to locate cmstart.exe for published application launch process.
The variables provided by the third party software get the priority.

Application Launch Error: The Citrix server is unable to process your request to start this published application at this time.
http://support.citrix.com/article/CTX132243

4.10

Task Description: Troubleshoot XenServer networking issues

Testing Aspect: What is the root cause

When a XenServer host is added to a pool, it inherits most network settings from the pool, particularly:

VLANs
bonds
external networks
A new host can’t have an external network configured with a VLAN different than all other hosts.
If connections to VDMs on all the other hosts are working, there is obviously an issue outside of the pool.
The issue is most likely on the switch to which the new host is connected.
A wrong VLAN on the physical switch or a speed mismatch could be causing the problem.

Network Interface Card Bonds in XenServer
http://support.citrix.com/article/CTX137599
Want a PDF of the full 1Y0-200 study guide?
Enter your email and click Join!

4.11

Task Description: Troubleshoot Provisioning Services related issues

Testing Aspect: What is the root cause

If a user running a recently rolled out Windows 8 virtual desktop, while waiting for a virtual desktop machine (VDM) to start…

It might take an extra-long time
The user might be staring at a blank screen, not sure if it the desktop is starting up.
A likely issue is that:
The virtual desktop was created with Provisioning Services.

This issue will likely be experienced with:
dedicated desktops when they are first assigned.
pooled-random desktops created with Provisioning Services.

XenDesktop > XenDesktop 7 > About this release > Known issues
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-70-known-issues.html

4.12

Task Description: Troubleshoot Provisioning Services related issues

Testing Aspect: How to resolve the issue

If a Citrix administrator is using the Provisioning Services Streamed VM Setup Wizard to deploy a streamed vDisk to several cloned virtual machines on a XenServer host and is unable to create new computer accounts in Active Directory (AD)…

An Active Directory administrator will need to delegate rights to the Citrix administrator to allow Active Directory account creation.

Technologies > Provisioning Services > Provisioning Services 7.x > Provisioning Services Administration > Using the Streamed VM Setup Wizard
http://support.citrix.com/proddocs/topic/provisioning-7/pvs-vm-wizard-using.html

4.13

Task Description: Troubleshoot personal vDisk failures

Testing Aspect: How to resolve the issue

If the value of the Personal vDisk registry key EnableProfileRedirection is set to 1 or ON, and later, while updating the image, it is changed to 0 or OFF…

the entire Personal vDisk space might get allocated to user-installed applications.
Leaves no space for user profiles.
The profiles remain on the vDisk, not being redirected to a file server.
To prevent this issue, do not adjust the registry key when updating the image.

XenDesktop > XenDesktop 7 > About this release > Known issues
http://support.citrix.com/proddocs/topic/xendesktop-7/cds-70-known-issues.html

4.14

Task Description: Troubleshoot Machine Creation Services

Testing Aspect: What is the root cause

A requirement to utilize MCS is that a master image must be on each shared storage.

An NFS share is OK for MCS.
FC storage is OK for MCS.
Intellicache utilizes local storage on the hosts so is not OK.

Machine Creation Services Primer – Part 1
http://blogs.citrix.com/2011/06/28/machine-creation-services-primer-part-1

4.15

Task Description: Troubleshooting Machine Creation Services

Testing Aspect: How to resolve the issue

One of the most overlooked design elements involving IntelliCache is XenServer host local storage.

When IntelliCache is enabled…
most of the I/O is shifted from the enterprise storage array to local host storage.
resulting in I/O bottleneck if there is a high density of running VMs on each host.
Low resource utilization (10%) on enterprise storage array shows an indication of I/Os that are shifted to the hosts’ local storage.
An indication that IntelliCache is enabled.
To resolve the issue, an administrator should:
replace local storage with SSD drives to handle the I/O demand.

disable IntelliCache so the VDI will utilize the enterprise storage array, which is being underutilized.

Troubleshooting and identifying data storage performance bottlenecks
http://searchstorage.techtarget.com/report/Troubleshooting-and-identifying-data-storage-performance-bottlenecks

4.16

Task Description: Troubleshoot issues related to user being unable to access desktops and/or apps through StoreFront

Testing Aspect: What is the root cause

When accessing a store website on StoreFront and the following error message is displayed: ‘Cannot complete your request. You can log on and try again, or contact your help desk for assistance’…

A likely cause is that the Citrix Credential Wallet Service is not started.
Ensure the Citrix Credential Wallet Service is started on the StoreFront server.
If it is already started, restart the service.
Note: Change this service Startup Type to Automatic (Delayed Start) and restart the server.

StoreFront Error: Cannot complete your request
http://support.citrix.com/article/CTX133904

4.17

Task Description: Troubleshoot issues related to user being unable to access desktops and/or apps through StoreFront

Testing Aspect: How to resolve the issue

To integrate pass-through authentication through StoreFront:

Enable the Domain Pass-through authentication method in StoreFront.
On the domain workstation, install CitrixReceiver.exe with the /includeSSON switch from the command line.
Install the icaclient.adm template.
Configure ‘Enable pass-through authentication’.
‘Allow pass-through authentication for all ICA connections’.
After enabling the policies in the icaclient.adm template, run the command ‘gpupdate/force’.
Add the StoreFront FQDN to the Local Intranet zone in Internet Explorer.
Restart the workstation.

How to Configure Desktop Pass-Through with StoreFront and Receiver 3.x
http://support.citrix.com/article/CTX133855

4.18

Task Description: Troubleshoot issues related to NetScaler and load balancing StoreFront servers

Testing Aspect: What is the root cause

While monitoring back end servers, NetScaler uses various probes, with ping being one of them.

Ping is not recommended to monitor a server as it doesn’t account for applications running on the server.
StoreFront relies on Internet Information Services (IIS).
If IIS is down and ping is running, NetScaler will continue to send traffic to the server and users may be unable to connect.

Citrix StoreFront 2.0 Proof of Concept Implementation Guide
http://www.citrix.com/content/dam/citrix/en_us/documents/products-solutions/citrix-storefront-2.0.pdf

4.19

Task Description: Troubleshoot Receiver issues

Testing Aspect: What is the root cause

If a user tries to add a StoreFront URL “http://thecx-storefront.com” to Citrix Receiver but fails and receives the following warning: The specified URL is not secure…

The cause of the failure of adding the URL is most likely:
The default configuration requires SSL communication to a store.

Citrix Receiver 3.1 does not allow a non-secure URL to StoreFront by default.

To force Receiver to allow a non-secure URL, the client registry must be modified.

Citrix Receiver 3.1 does not Allow you to Add Non-Secure URL
http://support.citrix.com/article/CTX131857

4.20

Task Description: Troubleshoot Receiver issues

Testing Aspect: How to resolve the issue

If a user running Citrix Receiver on a Windows machine is connected to a published desktop and is unable to save a file to a folder on the local hard drive but is able to copy files to the folder when disconnected from the published desktop, two ways an administrator can resolve the issue are:

On the client machine:
Configure Read and Write in Desktop Viewer Preferences > File Access.
Configure Full Access in Citrix Connections Center > Session Security > Files.
Users sometimes unknowingly change the settings on their local machine.
Although an error message might seem to be user permission related, it is not.
The user most likely received a pop-up message asking to choose the level of access to grant to local files and the user selected ‘Read-only access.’
This would not allow files to be saved to the client drive.
This access issue can be resolved either by configuring Read and Write in Desktop Viewer Preferences > Files.

OR
Configuring Full Access in Citrix Connections Center > Session Security > Files.

How to Configure Default Device Access Behavior of Receiver 3.x, XenDesktop and XenApp
http://support.citrix.com/article/CTX133565

4.21

Task Description: Troubleshoot user profile issues

Testing Aspect: How to resolve the issue

When changes are made to a Group Policy setting but it is not operative on the server running the Citrix Profile Management Service…

This might be because Group Policy does not refresh immediately.
Instead it is based on events or intervals specified in the deployment.
To refresh the Group Policy immediately:
Run gpupdate /force on the Profile Management server.

Technologies > Profile Management > Profile Management 5.x > Troubleshoot > Troubleshooting Common Issues Technologies > Profile Management > Profile Management 5.x > Troubleshoot > Troubleshooting Common Issues
http://support.citrix.com/proddocs/topic/user-profile-manager-5-x/upm-troubleshoot-specifics.html

Windows Library: Gpupdate
http://technet.microsoft.com/en-us/library/bb490983.aspx

4.22

Task Description: Troubleshoot issues related to NetScaler and ICA proxy

Testing Aspect: How to resolve the issue

When ICA proxy is enabled on Access Gateway, if users connecting to XenDesktop attempt to open a published application…

The Secure Ticket Authority (STA) issues a session ticket with an invalid format.
The connection fails.
To resolve this issue:
Disable ICA proxy on Access Gateway.

NetScaler Gateway > Access Gateway 10 > About This Release > Known Issues
http://support.citrix.com/proddocs/topic/access-gateway-10/agee-known-issues-10-con.html

citrix_vdi_handbook_2017_v.2.01

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

перевод Citrix VDI Handbook 2017 v.2.01. При копировании ссылка на оригинал обязательна.

Citrix Consulting Methodology

В рамках методологии Citrix Consulting выделяется 5 этапов развертывания и подержки решения VDI.

1. Определение потребностей (Define). Формулирование и изучение бизнес-кейса. Составление роадмапа внедрения высокого уровня (с низкой детализацией).
2. Оценка (Assess). Выработка требований к решению VDI. Оценка задач и приоретизация усилий. Оценка текущей инфраструктуры для определения круга задач внедрения и выявления потенциальных проблем.
3. Разработка решения (Design). Определение архитектуры будущего решения, удовлетворяющее задачам бизнеса и требованиям, выработанным на этапе оценки. Также, на этом этапе прорабатываются требования к масштабируемости и отказоустойчивости.
4. Развертывание (Deploy). Фаза развертывания включает в себя реализацию решений и требований, сформулированных на этапах оценки и разработки. Компоненты инфраструктуры должны быть обособлены. Перед запуском в эксплуатацию должно быть проведено тестирование отказоустойчивости.
5. Контроль (Monitor). Формирование регламента и процедур обслуживания системы.

Оценка (Assess)

Процесс оценки включает в себя:

1. Определение круга решаемых с помощью VDI задач и требований менеджмента к решению VDI.

Лучший сбособ сбора сведений - опросники.
Примеры задач и требований:

Со стороны менеджеров от бизнеса:

Agilty. Более высокая гибкость инфраструктуры IT. Способность подстроиться под быстро появляющиеся задачи. Например - открытие новых офисов организации.
BYOD. Использоваие сотрудниками тех устройств, которые в данный момент наиболее эффективны. В том числе и их собственных.
Эффективная совместная работа сотрудников из разных географических локаций.
Возможность работать откуда угодно.

Со стороны принимающих решения IT-менеджеров:

Высокая управляемость инфраструктуры рабочих столов.
Высокая безопасность. Защита данных от потери.
Расширение жизненного цикла оборудования (настольные компьютеры).
Уменьшение круга рутинных задач IT-подразделения за счет использования облачных вычислительных ресурсов.
Увеличение производительности рабочих мест пользователей и возможность использования ранее недоступных технологий.

2. Определение групп пользователей и их потребностей.

Пользователей логично делить на группы в соотвествии с их функциональными обязанностями, подразумевая, что функциональные обязанности определяют круг необходимых для работы приложений.

Среди потребностей пользователей выделяют:

Уровень персонализации рабочего места.

Возможные уровни персонализации - никакая (пользователь не имеет прав менять настройки), базовая (можно менять параметры рабочего стола) и полная персонализация (любые настройки, в том числе установка ПО).

Уровень безопасности.

Низкая безопасность - пользователю можно выгружать данные с виртуального рабочего места и загружать их туда.
Средняя безопасность - трафик виртульного рабочего места шифруется и контролируется. Пользователю нельзя изменять параметры рабочего окружения.
Высокая безопасность - Трафик шифруется. Любой вывод информации (копирование, печать) зпрещен. Все изменения виртуальной среды журналируются.

Уровень мобильности

Локальный пользователь - Всегда работает за локальным рабочим местом.
Перемещающийся локальный пользователь - Работает за разными рабочими местами в пределах высокоскоростной локальной сети.
Удаленный пользователь - Иногда подключается с помощью незащищенных каналов с различной скоростью.
Мобильный - Нуждается в доступе к приложениям в условиях отсутствия подключения.

Критичность неработоспособности рабочего места

Эта метрика определяет необходимость резервирования элементов инфраструктуры VDI и балансировки нагрузки. Низкая критичность - В случае неработосопсобности VDI риск для бизнес-процессов отсуствует.
Средняя критичность- В случае неработосопсобности VDI существует потенциальный риск для бизнес-процессов.
Высокая критичность- В случае неработосопсобности VDI бизнес-процессы останавливаются либо подвургаются существенным рискам.

Рабочая нагрузка

Тип и число приложений, влияющих на плотность сессий и выбор типа VDI.
Легкая нагрузка - 1-2 офисных приложения или информационный киоск.
Средняя нагрузка - 2-10 приложений с небольши количеством мультимедиа.
Высокая нагрузка - Тяжелые мультимедийные приложения.

Расчет нагрузки не должен включать в себя критерии загрузки процессора, оперативной памяти и дисковой подсистемы, поскольку эти метрики существенно зависят от оптимизации тех или иных операций внутри ПО. Напротив - предполагаемая нагрузка расчитывается исходя из числа и типа приложений запускаемых каждым пользователем.

3. Модели VDI

Различные типы нагрузки скорее всего потребуют применения различных типов VDI. Применение единой модели VDI для разных типов нагрузки в рамках крупного внедрения скорее всего не приведет к хорошим результатам.
Citrix предлагает полный спектр технологических решений VDI,которые объединяются в интегрированное решение:

Опубликованные приложения (Hosted Apps). Среди них можно выделить:
- Windows-приложения, развернутые на Windows Server. В этом случае много пользователей могут работать на одном сервере (физическом или виртуальном).
- Windows-приложения, развернутые на виртуальных машинах с десктопной версией Windows. В этом случае каждый пользователь получает доступ к приложению, работающему на выделенной виртуальной (или физической) машине.
- Linux-приложения, развернутые на сервере Linux. В этом случае много пользователей могут работать на одном сервере (физическом или виртуальном).
- Приложения с Web-интерфейсом. Приложение, развернутое на Windows-сервере доставляется во вкладку локального браузера (IE, Chrome или Firefox).
Опубликованный рабочий стол (Shared desktop). Рабочий стол опубликованный на серверной ОС (Windows или Linux).
Пул рабочих столов (Pooled Desktop). Пользователю предоствляется динамичейский доступ к случайной неизменяемой виртуальной машине из определенного пула машин. Возможная плотность размещения несколько уступает Shared Desktop.
Персональный рабочий стол (Personal Desktop) - Пользователь получает доступ к статически выделенной машине, которая сохраняет произведенные им изменения. Возможная плотность размещения несколько уступает Shared Desktop.
Рабочий стол с поддержкой GPU (Pro Graphics Desktop) - виртуальная машина для работы с 3D-графикой.
Образ ОС, загружаемый по сети (Local Streamed Desktop)- Централизованно поддерживаемый образ машины загружается по сети и работает на локальной машине пользователя.
Локальная виртуальная машина (Local VM Desktop) - Централизованно распространяемый локально исполняемый образ виртуальной машины, способный работать без доступа к сети предприятия.
Удаленный доступ к рабочему месту - удаленный доступ к физической машине.

4. Приложения

Оценка количества и качества приложений включает два этапа:

Инвентаризация текущего набора приложений и оптимизация этого списка.
Привязка приложений к группам пользователей.

Инвентаризация приложений

При инвентаризации важно учитывать:

Наличие многих версий одного и того же приложения. Причин для этого может быть много.
Приложения не актуальные для бизнеса.
Старые (уже не используемые) приложения.
Инфраструктурные приложения (антивирусы, бекапы и прочие).

Общие пожелания - максимальное сокращение списка виртуализируемых приложений.

Категоризация приложений

Все виртуализируемые приложения следует категоризировать и выбрать для каждого наиболее подходящий способ доставки:

Приложение может быть установлено непосредственно в образ.
Приложение может быть упакованно в контейнер Microsoft App-V.
Приложение может быть выделено в собственный слой - Citrix App Layering.
Приложение может работать на локальной машине пользователя и бесшовно интегрироваться в виртуальный рабочий стол - Citrix Local App Access.

Для каждого приложения следует определить характеристику, которая поможет выбрать способ доставки:

Сложные приложения - приложения сложные в техническом отношении, требующие увязывания многих компонент в единый комплекс. Как правило успешно доставляются как Hosted Apps.
Приложения требовательные к ресурсам - следует корректно опредлелять требования приложений к ресурсам для их своевременного выделения. Например требовательные приложения не следует публиковать в pooled/personal desktop средах, поскольку в этом случае невозможно адекватно контролировать выделение необходимых ресурсов.
Мобильные приложения - некоторые приложения должны исполняться в условиях отсутствия доступа к сети и доствляться с помощью Microsoft App-V.
Приложения работающие с периферией - приложения, работающие с периферией должны иметь доступ к локально установленным устройствам из виртуальной среды. Часто реализовать такой сценарий удается с помощью бесшовной интеграции приложения в виртуальный рабочий стол - Citrix Local App Access.
Приложения, использовапние которых ограничено - например, приложения с ограниченным числом лицензий не следует устанавливать в образ polled desktop.

Роли в команде внедрения

Напишу как-нибудь потом. Когда сделаюсь архитектором :)

Разработка решения (Design)

В качестве стандарта разработки рекомендуется использовать пятиуровневую модель: Три верхних уровня - разрабатываются индивидуально для каждой группы пользователей в соответсвтии с критериями, определенными на этапе оценки (assess). Эти уровни опеределяют ресурсы, доступные пользователям, и способ доступа к ним.
Два нижних уровня - управление и аппаратный уровень разрабатываются для всего внедрения вцелом.

Уровень 0: Концепция архитектуры

На первом этапе важно выбрать стратегию, основанную на целях заказчика и организационной структуре.
Необходимо определить лучшую модель доставки приложений и физическое (географическое) распределение вычислительных ресурсов.

Размещение вычислительных ресурсов

Независимо от выбранного способа размещения вычислительных ресурсов, инфраструктура остается той же самой, а меняются только подходы к управлению ею.

On premises. Вычислительные ресурсы размещены на площадке заказчика (on premises). IT-команда заказчика полностью обеспечивает работоспособность решения.

Public Cloud. Вычислительные ресурсы размещены (арендованы) в публичном облаке (IaaS). IT-команда заказчика не отвечает за аппаратные средства.

Hybrid Cloud. Вычислительные ресурсы размещены как на площадке заказчика (on premises), так и в публичном облаке (IaaS).

Citrix Cloud. В этом случае управляющие элементы инфраструктуры XenApp и XenDesktop работают в Облаке Citrx (Citrix Cloud), а слой ресурсов доступных пользователю (resource layer) управляется IT-командой заказчика. Citrix берет на себя обслуживание аппаратных средств, масштабирование и поддержание в актуальном состоянии управляющих элементов инфраструктуры.

Выбор топологии

В рамках архитектуры XenApp и XenDesktop сайтом (site) называется группа рабочих столов и приложений, управляемых как единая сущность. Вся информация о текущей конфигурации, выделенных ресурсах и подключениях хранится в базе данных сайта.
Компоненты сайта XenDesktop могут быть физически размещены в одном или нескольких локациях. Нагрузочное тестирование показывает, что один сайт способен одновременно обслуживать более 40 000 сессий.
Сайт может быть разделен на зоны в соотвествии с географическим принципом разделения ресурсов. При планировании топологии сайта учитываются несколько факторов:

Отказоустойчивость (Risk Tolerance). Создание нескольких сайтов позволит минимизировать влияние отказов на бизнес-процессы. Например - повреждение базы данных одного сайта не повлияет на другие сайты.
Безопасность (Security). В некоторых случаях регулирующие органы могут предъявлять требования, которые подразумевают физическое разделение вычислительных ресурсов, обрабатывающих критичные и некритичные данные. Например - разделение складского и финансового учета.
Административные границы (Administrative Boundaries). В пределах компании IT-ресурсы могут быть разделены административно и управляться различными IT-командами.
Географическая связанность (Geographical Connectivity). В общем случае - реализация зон не подразумевает распределения инфраструктуры сайта по нескольким географическим локациям (потому что база все равно одна), однако если между локациями (основной и дополнительными зонами) существует достаточно производительный и стабильный канал связи, то реализация зон может быть оправдана. Большой размер зоны и высокие задержки в канале связи отражаются на времени отклика для пользователя.

	XenApp/XenDesktop 7.13	XenApp/XenDesktop 7.11
Latency (ms)	90	250
Concurrent Requests	48	48
Average Response Time	3.7	7.6
Brokering Requests per second	12.6	6.3
Time to launch 10,000 users	13 minutes	26 minutes

Производительность зон Citrix Xendesktop

Session count	Max concurrent session launches	Min zone-to-zone bandwidth	Max zone-to-zone round trip latency
Less than 50	20	1 Mpbs	250 ms
50 to 500	25	1.5 Mbps	100 ms
500 to 1,000	30	2 Mbps	50 ms
1,000 to 3,000	60	8 Mbps	10 ms
Over 3,000	60	8 Mbps	5 ms

Требования к каналам связи для реализации зон

В общем случае - администраторам следует минимизировать количество сайтов и зон для упрощения структуры.

Выбор стратегии управления мастер-образами

При развертывании XenApp или XenDesktop, как правило, создаются мастер-образы (master images). Важно зараее определиться со стратегией управления мастер-образами. Возможные варианты:

Установленный образ (Installed Image). В таком варианте администратор устанавливает ОС и прикладное ПО при создании каждого мастер-образа. Это самый простой вариант, однако в этом случае при создании и обновлении каждого мастер-образа администратор вынужден повторять одни и те же действия, что может быть очень затратно по времени.
Мастер-образ формируемый скриптом (Scripted Image). Образ формируемый скриптом (настройки и установка ПО).
Многослойный образ (Layered Image). В этом варианте - ОС и прикладное ПО рассматриваются в качестве элементов многослойной структуры. В этом случае любой элемент (слой) доступен любому мастер-образу и может быть добавлен при необходимости.

Уровень 1: Пользователи

Верхним уровнем методологии дизайна является пользовательский уровень. На этом уровне определяются потребности различных групп пользователей и стратегии их реализации. Решения, принимаемые на этом этапе в конечном счете оказывают сильное влияние на функциональность

Выбор пользовательского устройства

В качестве пользовательского устройтсва могут выступать:

Планшет
Ноутбук
Настольный ПК
Тонкий клиент
Смартфон

В любом случае - пользовательское устройство должно удовлетворять требованиям.

Владелец конечного устройства

Обычно - пользовательские устройства принадлежат и управляются компанией. Альтенативный подход - BYOD, когда пользователь подключается к корпоративным ресурсам с помощью личного устройства. Критерии допустимости BYOD зависят от сценария использования:

Безопасность. В случае обработки критичных данных личные устройства недопустимы.
Мобильность. Если пользовательработает без доступа к сети, то при использовании личного устройства, скорее всего, ему будет недоступен сценарий local VM desktop, предъявляющий определенные требования к аппаратным возможностям устройства.
Критичность отказа. Если отказ критичен, то должно быть предусмотрено резервирование пользовательского устройства, что может быть непросто в случае BYOD.
Модель VDI - При использовании local VDI (streamed desktop или local VM desktop) предъявляются определенные требования к аппаратным возможностям устройства.

Жизненный цикл конечных устройств

Современные устройства могут с успехом выходить за рамки типичного трехгодичного жизненного цикла и использоваться гораздо дольше в качестве конечных устройств при доступе к ресурсам VDI. Конечные устроства должны соотвествовать нескольким критериям:

Минимальные требования. В общем случае для нормальной работы достаточно конфигурации - 1GHz, 1Gb RAM, 16Gb HDD.
Корпоративные цели. Если приоритет - сокращение затрат, то расширение жизненного цикла оборудования - благо, но если приоритет - удобство и сокращение энергопотребления, то нет.
Сценарий использования. Если предполагается активно использовать локально исполняющиеся приложения, то оборудование должно соответствовать задачам.

Управление мобильными пользовательскими устройствами

Вследствие того, что VDI позволяет получать доступ к корпоративным ресурсам с любых (в том числе мобильных) устройств, возникает потребность управления этими устройствами и контроля их состояния:

Удаленно уничтожать информацию на потеряных или украденых устройствах.
Соблюдать регламент паролей.
Устанавливать ограничения в соответствии с географическим положением устройств.
Упрощать конфигурацию Exchange ActiveSync.
Настраивать конфигурацию Wi-Fi.
Распространять сертификаты безопасности.

Также важно разграничивать уровни безопасности в зависимости от различных условий:

Доступ к опубликованным ресурсам со “взломанных” устройств (rooted Android OS или jailbroken iOS).
Копирование/Вставка данных между опубликованными и локальными приложениями.
Доступ к опубликованным ресурсам с устройств незащищенных паролем.
Доступ к корпоративной почте небезопасными почтовыми клиентами.
Доступ к корпоративным сайтам с помощьюб мобильных браузеров или с помощью опубликованного настольного браузера.

Citrix предлагает решение для унификации управления пользовательскими устройствами Unified Endpoint Management (UEM) для приложений или Mobile Device Management (MDM) для корпоративных мобильных устройств или Mobile Application Management (MAM) для личных мобильных устройств - Citrix XenMobile.

Выбор формфактора конечных устройств

V - рекомендовано, X - не рекомендуется, o - допустимо.

В общем случае - конечное устройство должно соответствовать задачам. Плохой идеей может оказаться установка тупого тонкого клиента, если на рабочем месте нужно работать с мультимедией или большим количеством локальных периферийных устройств.

Выбор Citrix Receiver

Citrix Receiver - клиент для доступа к опубликованным ресурсам.
При установке Citrix Receiver в рамках организации возможны различные варианты как в части функциональности, так и в части способа распространения и конфигурирования.

Распространение Citrix Receiver

Как правило - лучшим вариантом является установка полной версии Citrix Receiver, совместимой с клиентским устройством. Для случаев, когда установка невозможна существует версия HTML5 Receiver (раньше его место занимал Java-клиент). HTML5 Receiver не рекомендуется для масштабных внедрений из-за ограниченной функциональности и ограничений в современных браузерах. Для распространения Citrix Receiver могут использоваться следующие механизмы:

Store Front. При наличии Store Front можно включить опцию “Client Detection”, которая сможет автоматически определять наличие климента и при необходимости предлагать установку Citrix Receiver for Web. Этот функционал совместим не со всеми браузерами и зависит от настроек ActiveX.
Корпоративный сайт. Дистрибутив Citrix Receiver может быть размещен для скачивания и установки на локальном корпоративном сайте.
Магазины приложений различных ОС (Windows, Android, iOS и т.д).
Корпоративные системы распространения ПО - Enterprise software deployment deployment (ESD) или Mobile Application Management (MAM) для корпоративных мобильных устройств.
Citrix Receiver может быть встроен в предустанавливаемый корпоративный образ ОС.
Групповые политики AD. В ситуациях, коргда отсутствуют специализированные Корпоративные системы распространения ПО можно использовать функционал Групповых политик AD. Простые скрипты для установки доступны в каждом *.iso образе XenApp или XenDesktop - X:\Citrix Receiver and Plugins\Windows\Receiver\Startup_Logon_Scripts
Установка вручную. Просто скачать с сайта http://receiver.citrix.com/ и установить.

Выбор механизма начальной конфигурации Citrix Receiver

Citrix Receiver перед началом работы должен быть сконфигурирован. Способ конфигурации может зависеть от типа пользовательского устройства, версии Citrix Receiver и способа подключения (локальный или удаленный):

Получение настроек при введении адреса e-mail. ( Email based discovery). Для того, чтобы этот способ работал необходимо настроить StoreFront и соотвествующую SRV-запись на DNS-сервере - Configuring Email-Based Account Discovery for Citrix Receiver.
Групповая политика AD. В центральное хранилище шаблонов групповых политик ADMX/ADML импортируется шаблон, входящий в состав Citrix Receiver, и настраивается политика. Способ применим при доступе к ресурсам из корпоративной сети.
Настройки распространяются с помощью StoreFront (Provisioning File). В случаях, когда развернут StoreFront, пользователю можно предоставлять конфигурационный файл *.cr, который можно просто открыть на пользовательском устройстве с помощью Citrix Receiver. Файл доступен по сслыке Activate в Web Interface.
Конфигурирование вручную - при запуске Citrix Receiver вводится адрес сервера StoreFront или Web Interface.
Citrix Studio. Citrix Receiver, установленный на виртуальных машинах, доступ к которым предоставляется через Citrix XenDesktop, можно сконфигурировать в свойствах Delivery Group.

Обновления Citrix Receiver

Обновления Citrix Receiver могут выполнятьтяр тремя способами:

Автоматически (начиная с версии 4.8).
В помощью корпоративной системы распространения ПО. (Enterprise software deployment deployment (ESD)).
Вручную.

Уровень 2: Доступ к ресурсам

Второй уровень методологии разработки решения - разграничение доступ к ресурсам. На этом этапе рассматриваются способы авторизации всех групп пользователей при доступе к ресурсам.

Аутентификация

Для авторизованного доступа к ресурсам пользователь должен быть аутентифицирован :)
Для начала следует определиться со стратегией аутентификации.

Выбор провайдера аутентификации

Обычно, для доступа к ресурсам пользователь предоставляет свои учетные данные Active Directory (логин и пароль). В большинстве случаев - инфраструктура AD уже существует на предприятии и этот этап внедрения сложностей не предстваляет.
Также, могут встречаться более экзотичные варианты - аутентификация пользователей с помощью внешний провайдеров - Azure Active Directory, Google, LinkedIn и других. Внешние провайдеры аутентификации поддерживаются с помощью компонента Citrix Federated Authentication.

Выбор точки аутентификации

В XenDesktop пользователь может аутентифицироваться в двух точках:

Citrix StoreFront (ранее - Web Interface) - явялется веб-интерфейсом для доступа к ресурсам и применяется внутри корпоративной сети.
NetScaler Gateway - инструмент для безопасного доступа к ресурсам из незащищенных сегментов сети Internet. Реализует различные политики безопасности при доступе к ресурсам и позволяет проверять состояние канала связи и клиентского устройства перед предоставлением доступа.

Желательно, чтобы аутентификация удаленных клиентов всегда проходила на Netscaler Gateway, однако в некоторых случаях, аутентификация удаленных клиентов может происходить и на StoreFront. Например - если политики безопасности исключают подключение Netscaler Gateway к Active Directory, то на Netscaler может реализован виртуальный сервер, предоставляющий доступ к корпоративному StoreFront (NetScaler SSL_BRIDGE).

Выбор способа (политики) аутентификации

После выбора точки аутентификации следует выбрать способ аутентификации.
StoreFront поддерживает следующие типы:

Имя и пароль.
Сквозная доменная аутентификация (Domain pass-through). Пользователь логинится на своё устойство, и далее его учетные данные прозрачно используются для аутентификации на StoreFront.
Сквозная аутентифиакция на Netscaler Gateway (NetScaler Gateway pass-through). Пользователь вводит логин и пароль на NetScaler Gateway и далее его учетные данные прозрачно используются для аутентификации на StoreFront.
Смарт-карты. Пользователь может аутентифициоваться с помощью смарт-карты на Citrix Receiver или Netscaler Gateway. Для использования этого типа аутентификации учетные записи пользователей должны быть сконфигурированы в домене AD в котором находится сервер Storefront, либо в домене, который имеет двусторонние доверительные отношения (two-way trust)с доменом, в котором находится сервер Storefront. Конфигурации с односторонними доверительными отношениями не поддерживаются.
Анонимный доступ. При анонимном доступе от пользователей не требуется предоставлять учетные данные, а временные локальные учетные записи автоматически создаются в момент подключения на сервере, к которому происходит подключение.

NetScaler Gateway поддерживает несколько методов аутентификации:

LDAP - используется для аутентификации в Active Directory и других подобных службах каталога, поддерживающих протокол LDAP.
RADIUS (token) - протокол, работающий на базе UDP и обеспечивающий аутентификацию, авторизацию и учет пользователей. Шлюз Citrix (Netscaler gateway или старый Web Interface), к которому подключается пользователь, направляет учетные данные серверу RADIUS, который проверяет их локально или в службе каталога (AD).
Клиентские сертификаты - при подключении к Netscaler gateway производится проверка аттрибутов сертификата клиента. Обычно клиентские сертификаты выпускаются в виде смарт-карт (или других аппаратных устройств) и считываются специальным считывателем.

Citrix StoreFront

Citrix StoreFront аутентифицирует пользователей для доступа к ресурсам XenApp и XenDesktop. StoreFront предоставляет пользователю единый интерфейс для доступа к ресурсам XenApp и XenDesktop.

Обеспечение высокой доступности Storefront

При недоступности сервера Citrix Storefront пользователи не смогут получить доступ к ресурсам. Следовательно, для исключения этой точки отказа необходимо разворачивать не менее двух серверов Storefront, а также балансировку нагрузки между ними. Тут доступны следующие варианты:

Аппаратные средства балансировки. Citrix Netscaler способен отслеживать состояние балансируемых серверов Storefront и распределять нагрузку между работоспособными серверами. Рекомендовано к применению.
Балансировака на уровне DNS. Простейший вариант балансировки. В этом случае никакой проверки работоспособности серверов Storefront не производится и в случае выхода севрера из строя к нему все равно будут производиться попытки подключения. Не рекомендуется к применению.
Балансировка на уровне сетевых интерфейсов средствами Windows. Сетевые средства балансировки Windows позволяют производить простейшую проверку доступности сервера, но не могут оценить работоспособность сервисов Storefront. Не рекомендуется к применению.

Обеспечение высокой доступности контроллеров DDC

Citrix Storefront получает список доступных пользователю ресурсов от контроллеров доставки - Desktop Delivery Controler (DDC). Для обеспечения отказоустойчивости необходимо разворачивать несколько DDC и возможны два варианта балансировки XML-сервисов, предоставляемых DDC: средствами Citrix NetScaler в режиме active/active, либо - встроенные в Storefront средства обеспечения отказоустойчивости DDC, которые могут работать как в режиме active/passive, так и в режиме active/active.

Точки покдлючения (beacons)

Пользователь может подключаться из внутренней (локальной) сети непосредственно к Storefront или из внешней сети через Netscaler Gateway и в зависимости от этого, ему может быть предоставлен различный набор ресурсов. При первичном подключении Citrix Receiver получает список доступных точек подключения (beacons) в который входят имена внутреннего сайта Storefront и внешних Citrix Netscaler Gateway.
Во время работы Citrix Receiver постоянно отслеживает состояние сетевого подключения и при его изменении (отключение, подключение, изменение дефолтного шлюза) сначала проверяет доступность локальной точки подключения Storefront и если она недоступна - перебирает доступные адреса внешних точек подключения Citrix Netscaler Gateway. Для обеспечения отказоустойчивости необходимо, чтобы было сконфигурировано как минимум две точки подключения из внешних сетей Citrix Netscaler Gateway.

Представление списка ресурсов

По-умолчанию пользователь выбирает (self-service) из списка ресурсов те, которыми он планирует пользоваться и они помещаются в главное окно Citrix Receiver. Список ресурсов, выбранных пользователем хранится на группе серверов Storefront для того, чтобы, независимо от того с какого устройства пользователь производит подключение, список его “избранных” приложений сохранялся. Также списки избранных ресурсов могут сихронизироваться между двумя магазинами (store) в пределах одной серверной группы или между двумя магазинами с одинаковыми именами находящимися в разных серверных группах.
Администратор может задать какие приложения должны всегда отображаться в окне Citrix Receiver. Представление приложения по-умолчанию задается с помощью ключесого слова в строчке Description в свойствах приложения.

Ключевое слово	Описание
Auto	Ярлык приложения автоматическим появится в окне Citrix Receiver. Пользователь может удалить приложение из окна.
Mandatory	Начиная со Storefront 2.5 при использовании этого ключевого слова ярлык приложения автоматически появится в окне Citrix Receiver и пользователь не сможет его удалить.
Featured	Приложение будет рекомендовано пользователю через список Citrix Receiver Featured
Prefer	При использовании этого ключевого слова Citrix Receiver будет искать локальное приложение по пути опубликованного приложения. Если локальное найдется - ярлык будет автоматически создан, но при запуске приложения из Citrix Receiver будет запускаться локальное приложение. Если локальное приложение будет удалено (uninstall), то Citrix Receiver удалит ярлык при первом обновлении приложений.
TreatAsApp	При использовании этого ключевого слова опубликованные рабочие столы (desktops) будут появляться на вкладке Applications, а не на вкладке Desktops в интерфейсе Receiver for Web.
Primary	В многосайтовой инфраструктуре, если приложение опубликовано с одинаковым именем на нескольких площадках, то у пользователя будет отображаться только ярлык именно этого (основного) приложения. Если primary приложение не доступно, то будет отбражаться приложение с доступной площадки.
Secondary	Используется аналогично слову Primary, но для обозначения неосновного приложения.

Группировка ресурсов - Aggregation Groups

Если в инфраструктуре Citrix есть несколько ферм, то Storefront объединит все доступные пользователю ресурсы в единый интерфейс. Однако, если на разных фермах есть приложения с одинаковыми названиями - это может привести пользователя в замешательство. Группировка ресурсов(Storefront Aggregation Groups) позволяет объединить приложения нескольких ферм в единый интерфейс для лучшего восприятия, напрмиер - исключив дублирование ярлыков одинаковых приложений. При включении группировки ресурсов на Storefront необходимо задать способ распределения пользователей между фермами:

Балансировка нагрузки (Load Balancing) - Если большие фермы соотвествуют рекомендациям по количеству пользователей и предоставляют одинаковые ресурсы. В этом случае Storefront равномерно распределяет нагрузку по доступным фермам.
Обработка отказа (Failover) - при недоступности основной (локальной) фермы пользователям предоставляются ресурсы резервной (удаленной).

Масштабируемость

Число пользователей, которое может обработать один сервер Storefront зависит от аппаратных ресурсов сервера. При большом количестве пользователей Web-интерфейса возрастает потребление опреативной памяти (RAM). Минимальное рекомендованное количество памяти - 4Gb. тестироание покащзывает,что эффективность масштабирования заметно падает при увеличении числа Storefront до 3-4, а максимальное рекомендуемое число серверов в группе - 5-6.

NetScaler Gateway

https://docs.citrix.com/en-us/netscaler.html
При разработке решения, включающего NetScaler Gateway следует учитывать несколько особенностей, не возникающих при аутентификации на Storefront:

Топология

Выбор сетевой топологии является важнейшим решением, принимаемым при планировании удаленного доступа к опубликованным ресурсам. Разработка решения для удаленного доступа должна проводиться совместно с подразделением, обеспечивающим информационную безопасность. Существует два основных варианта топологии, отличающихся обеспечиваемым уровнем безопасности:

1-Arm. Нормальный уровень безопасности. В этом случае NetScaler Gateway использует единственный сетевой интерфейс (один VLAN и одна IP-подсеть) как для внешнего, так и для внутреннего траффика.

2-Arm. Высокий уровень безопасности. В этом случае NetScaler Gateway использует два или более сетевых интерфейса и соответвующие VLANы и IP-подсети для внутреннего и внешнего траффика. Таким образом удается полностью изолировать внутренние ресурсы сети и обеспечить полный контроль над траффиком.

Высокая доступность

При недоступности NetScaler Gateway удаленные пользователи не смогут получить доступ к опубликованным ресурсам. Для отказоустойчивости необходимо иметь как минимум два хоста NetScaler Gateway.
Два хоста NetScaler Gateway могут работать в режиме кластера active/passive. В таком режиме один основной хост принимает подключения (active), а второй резервный хост (passive) следит за состоянием основного хоста с помощью heartbeat-сообщений. Если основной хост не отвечает на heartbeat-сообщение, то резервный хост повторяет проверку через заданный интервал а, в случае неудачи, фиксирует отказ основного хоста и сам становится основным и принимает подключения.
Версии NetScaler Gateway 10.5 и более новые поддерживают кластер из большего числа хостов. В зависимости от версии Netscaler Gateway поддерживаются кластеризации в вариантах Spotted и Stripped.
В варианте Spotted IP-адрес назначен единственной ноде в каждый момент времени и используется в кластерах active/passive, а в варианте Stripped IP-адрес назначается одновременно нескольким нодам и используется для балансировки нагрузки.
http://docs.citrix.com/en-us/netscaler/11-1/clustering/cluster-features-supported.html

Платформа NetScaler Gateway

Для правильного выбора платформы NetScaler Gateway нужно правильно оценить предполагаемую нагрузку. Для оценки требуемой производительности используются две метрики:

Пропускная способность SSL (SSL throughput ). С какой скорость NetScaler Gateway может генерировать SSL-траффик.
Количество SSL-транзакций в секунду (SSL transactions per second (TPS)). Эта величина сильно зависит от длинны ключа шифрования. Метрика существенно ограничивает число SSL-сессий, которые могут быть одновременно инициированы и не существенно влияет на число одновременно поддерживаемых сессий.

Таким образом, требуемая пропускная способность SSL является основной метрикой, применяемой при выборе платформы Citrix Netscaler.
Использование протокола SSL немного (примерно на 2%) увеличивает количество передаваемых данных. Таким образом, максимальная требуемая пропускная способность SSL будет равна максимальной загрузке внешнего канала фермы + 2%.
Используются три основных платформы NetScaler Gateway:

VPX - виртуальная машина NetScaler Gateway, которая функционально полностью идентична аппаратным решениям, но может работать на стандартных серверах. Подходит для обслуживания внедрений до 500 пользователей.
MPX - аппаратное решение NetScaler Gateway, в котором применено аппаратное ускорение обработки SSL-траффика.
SDX - платформа для виртуализации NetScaler Gateway, котрая позволяет в запустить несколько VPX с аппаратной поддержкой шифрования SSL и большой пропускной способностью. Предназначено для крупных внедрений, нуждающихся в большом числе NetScaler Gateway.

Конкретные характеристики различных платформ можно найти тут: https://www.citrix.com/content/dam/citrix/en_us/documents/products-solutions/netscaler-data-sheet.pdf.
Следует учесть, что реальная пропускная способность SSL может существенно отличаться от заявленной, поскольку зависит от требований безопасности - длинны ключей шифрования и используемых алгоритмов. В даташитах указывается максимальная пропускная способность SSL, достижимая в идеальных с точки зрения производительности условиях. Например - при использовании шифрования по алгоритму RC4 с ключем длинной 1024 бит, платформа VPX может обеспечить работу более 500 подключений с использованием HDX. Однако, если использовать алогритм 3DES и ключ длинной 2048 бит, то количество одновременно поддерживаемых подключений упадет вдвое.

Политики пользовательских устройств (Pre-Authentication Policy и Smart Access)

Если Netscaler используется для аутентификации пользователей, то к ним могут применяться политики, которые проверяют соответствие пользовательского устройства корпоративным политикам с помощью Endpoint Analysis Scan (EPA Scan) и ограничивают доступ к корпоративной среде при несоответствии устройства политикам.
Политики Endpoint Analysis Scan могу проверять наличие и состояние антивируса, файервола, операционной системы и даже записей реестра. Эти политик могут либо полностью блокировать доступ к ресурсам при несоответствии, либо блокировать заданную функциональность XenDesktop (например - буфер обмена, принтеры а также доступ к приложениям и десктопам и прочие). Например - если у пользователя нет антивируса,то политика может скрыть опеределенные приложения.
Приведенная ниже схема демонстрирует применение политик в зависимости от результатов проверок Endpoint Analysis Scan:

Сеансовые политики (Session Policy)

Для того, чтобы пользователи могли аутентифицироваться на Netscaler Gateway необходимо, чтобы для групп пользователей были созданы сеансовые политики (session policy).
Политики сеансов могут применяться в зависимости от версии Citrix Receiver. Для привязки политик сеансов, устройства обычно группируются по принципу мобильности - мобильные (iOS, Android и другие) и немобильные (Windows, Mac и Linux).
Для идентификации типа устройства (и возможностей Citrix Receiver) используются выражения, проверящие заголовки HTTP, предоставляемые клиентским устройством: http://docs.citrix.com/en-us/netscaler-gateway/11-1/storefront-integration/ng-clg-session-policies-overview-con.html
Также, политики сеансов можно использовать для применения политик пользовательских устройств. То есть политики сеансов могут имитировать работу политик пользовательских устойств. Политики сеансов могу использоваться в качестве резервного сценария для пользовательских устройств, которые не удовлетворяют требованиям безопасности (например - предоставление доступа только для чтения для заданных приложений).

Профиль сеанса

К каждой сеансовой политике должен быть привязан сеансовый профиль. Сеансовый профиль опеределяет конкретные критерии, которые должны удовлетворяться для предоставления доступа. Существует два основных вида сеансовых профилей, которые опеределяют способ доступа к опубликованным ресурсам:

SSLVPN - Пользовательское устройство создает VPN-туннель и траффик перенаправляется во внутреннюю сеть компании. Пользователь получае доступ к корпоративным ресурсам (ресурсам Citrix XenDesktop, файловым ресурсам, сайтам в корпоративной сети и т.д) так же как это происходило бы в корпоративной сети.

Данный вариант расматривается как потенциально небезопасный, поскольку пользователь получает прямой доступ к корпоративной сети, минуя виртуальную инфраструктуру. Возможные риски включают в себя атаки на приложения и серверы, возможность распространения вирусов, троянов и другого нежелательного ПО.
Для предотвращения этих рисков существует опция ограничения туннелируемого траффика (split tunneling), которая дает администратору возможность предоставить доступ только к требуемым маршрутам, ресурсам и портам. Включение split tunneling позволяет обеспечить требуемый уровне безопасности, в то же время отключение split tunneling и направление пользовательского траффика во внутреннюю сеть позволяет производить мониторинг содержимого траффика - фильтровать web-ресурсы и использовать системы обнаружения проникновения (intrusion detection systems).

HDX Proxy - с профилем HDX proxy пользователь подключается только к опубликованным приложениям и рабочим столам Citrix XenDesktop, и пользовательское устройство не имеет сетевого доступа ни к каким другим ресурсам внутренней сети. Доступ к корпоративным ресурсам осуществляется только в рамках сессии Citrix XenDesktop. Решение об использовании этого профиля принимается для каждой группы пользователей, учитывая тип конечного устройства и вариант Citrix Receiver. Этот сеансовый профиль является предпочтительным:

Распределение подключений между датацентрами

Довольно часто, для обеспечения отказоустойчивости критичные опубликованные приложения могут быть размещены в двух и более датацентрах, но в то же время некритичные приложения могут быть опубликованы только в одном датацентре. Таким образом, в конфигурации с несколькими активными Citrix Netscaler может возникнуть ситуация, когда пользователь аутентифицировался на Netscaler, находящемся в одном датацентре, а приложение опубликовано в другом. В таком случае Citrix Storefront способен определить расположение запрошенного ресурса и направить сессию HDX по назначению. Однако, результирующий путь может быть не оптимальным и доступ опубликованного приложения к данным может осуществляться по медленным WAN-каналам, а не быстрым LAN.
Существуют динамические и статические методы для подключения сессии пользователя к ресурсам в его основном датацентре через Netscaler Gateway. Выбор метода в каждом конкретном случае определяется технологическими возможностями - Global Server Load Balancing (GSLB позволяет динамически изменять ответ на DNS-запросы клиентов, напрявляя их в нужный датацентр), правильной оценкой пропускной способностей каналов связи и возможностями QoS. http://support.citrix.com/proddocs/topic/netscaler-traffic-management-10-map/ns-gslb-config-proxmt-con.html

Статические методы

Прямая привязка пользователей (Direct) - Netscaler Gateway в каждом датацентре имеет собственное DNS-имя и каждый пользователь подключается к ресурсам используя DNS-имя Netscaler Gateway, расположенного в его основном датацентре. Никакого динамического направления пользователей не происходит. Это самый простой метод, однако он не реализует никакой отказоустойчивости.

Динамические методы

Intranet - В большинстве случаев, при реализации динамической балансировки, пользователь подключается к Netscaler Gateway в ближайшем датацентре. Например - при использовании GSLB dynamic proximity - к Netscaler Gateway в датацентре с минимальным временем отклика по сети. После подключения, HDX-сессия пользователя направляется к ресурсам через тот же Netscaler Gateway, не зависимо от того, в каком датацентре расположены ресурсы. В результате данные будут передаваться по корпоративным WAN-каналам, в которых можно использовать QoS.

Internet - альтернативный вариант - пользователь аутентифицируется в ближайшем Netscaler Gateway, но затем HDX-сессия динамически передается на Netscaler Gateway, который расположен в основном датацентре пользователя (в котором расположены ресурсы к которым подключается пользователь). Такой метод снижает нагрузку на корпоративные WAN-каналы и рекомендуется в случаях, когда надежность корпоративных WAN-каналов сравнима или ниже, чем надежность подключения пользователя к сети Internet.

Возможно использоватнеи сочетания этих методов, например - для определенного географического региона используются динамические URL, таким образом обеспечивается отказоустойчивости в пределах региона, без использования глобального GSLB.

Взаимодействие между сайтами

Инфраструктура Citrix XenDesktop и XenApp может быть распределена по нескольким площадкам (sites). Для того, чтобы успешно реализовать многосайтовое решение нужно на этапе проектирования уделить внимание связям между сайтами и маршрутизации сессий.

Оптимизация маршрутизации сессий HDX

В многосайтовой конфигурации для правильной маршрутизации сессий учитываются несколько критериев (например - минимальная задержка в сети). Эти алгоритмы не учитывают особенности ресурсов, к которым осуществляется доступ.
Неоптимизированная маршрутизация сессий может приводить к таким результатам: 1. Пользователь авторизуется на ближайшем Citrix Netscaler Gateway с минимальной сетевой задержкой.
2. Citrix Netscaler Gateway проксирует HDX-сессию к ресурсам, находящимся в другом датацентре через корпоративные WAN-каналы.

Оптимизированная маршрутизация выглядит так: 1. Пользователь авторизуется на ближайшем Citrix Netscaler Gateway с минимальной сетевой задержкой.
2. Ближайший Netscaler Gateway перенаправляет сессию в основной (preffered) датацентр пользователя, в котором расположен запрошенный ресурс.
3. Netscaler Gateway основного (preffered) датацентра пользователя проксирует ICA-траффик к ресурсам, расположенным в основном датацентре по локальной сети LAN.
Использование опции оптимизированной маршрутизации HDX в Citrix Storefront позволяет разгрузить корпоративные WAN-каналы связи и перенести этот траффик в публичные каналы.

Виртуальные WAN-каналы

При разработке решения следует обращать внимание на скорость и качество каналов связи между датацентром и офисами, в которых размещены пользователи. Если у компании есть несколько крупных офисов, то скорость и качество каналов связи будет оказывать существенное влияние на качество доступа к опубликованным в датацентре ресурсам.
Существует два основных способа масштабирования каналов связи между офисами и датацентром:

Экстенсивный (Scale Up) - при нехватке пропускной способности можно просто расширить пропускную способность канала.
Интенсивный (Scale Out) - Можно увеличить число каналов связи между офисами и датацентром и объединить их в виртуальный канал WAN (virtual WAN). В результате создается программно определяемый виртуальный канал, например - на базе технологии Netscaler SD-WAN (software defined WAN). В таком случае Netscaler одновременно посылает пакеты по всем доступным каналам связи, на другом конце Netscaler реконструирует траффик используя пакеты, пришедшие первыми, а остальные пакеты отбрасываются. В результате удается достичь максимальной производительности каналов связи, которая независит от состояния и загрузки каналов в течение дня.

Уровень 3. Ресурсы

Уровень ресурсов - третий уровень методологии разработкию
Общее впечатление пользователей от работы с продуктиами Citrix определяется решениями, принятыми на уровне ресурсов. Профили, печать, приложения и общий дизайн рабочего стола должны соответствовать требованиям, оперделенным на этапе оценки.

Впечатления пользователя от работы (User Experience)

Впечатления пользователя от работы - наиболее важный аспект при проектировании VDI. Пользователи ожидают от VDI ощущений на уровне настольного компьютера.
Кодеки,транспортные протоклы и средства самообслуживания влияют на общее впечатление. Низкое качество картинки, лагающие видеоролики или двухминутное ожидание при подключении к рабочему месту могут сильно ухудшить отношение пользователей к VDI.

Выбор протокола передачи изображения (Display Protocol)

Выбор протокола передачи изображения определяет качество статических изображений, видео и текста при работе с VDI, а также влияет на количество пользователей, которое сможет нормально работать на одном физическом сервере.
В распоряжении администратора есть следующие варианты:

Legacy - оптимизированный для Windows 7 и Windows 2008R2 (GDI/GDI+).
Desktop Composition Redirection - позволяет разгрузить менеджер окон (Windows manager) сервера, направляя на пользовтельское устройство только команды для формирования изображения, а не растровую картинку. Этот протокол поддерживается только VDA для Windows и в Citrix XenDesktop 7.15 LTSR уже считается устаревшим.
Framehawk - протокол, использующий UDP для передачи данных и обеспечивающий высокую скорость обновления изображения (refresh rate) в условиях нестабильных каналов связи с высокими задержками и высоким уровнем потерь пакетов, компенсируя наличие этих недостатков более высокими требованиями к пропускной способности канала связи. Эти условия характерны для широкополосных и мобильных каналов связи.
H.264 - Эта аббревиатура часто используется для обозначения видеокодека, которы обеспечивает высокое качечтво картинки при невысоком битрейте. Этот протокол потребляет много процессорного времени сервера и снижает максимальное количество пользователей, работающих на одном физическом сервере, однако именно он рекомендуется для применения в случаях, когда пользователь работает с мультимедийными приложениями.
ThinWire - протокол основанный на ранних патентах Citrix, который позволяет передавать картинку при минимальной пропускной способности канала связи. Использование этого протокола в большинстве случаев обеспечивает приемлемое качество картинки при минимальных требованиях к ресурсам сервера. Существует две разновидности ThinWire:
- Legacy - оптимизированный для Windows 7 и Windows 2008R2 (GDI/GDI+).
- ThinWire+ - оптимизированный для Desktop Windows Manager (DWM), входящего в состав Winodows 8, Windows 10, Windows 2012 и Windows 2016.
Selective H.264 (Adaptive Display) - использует несколько кодеков (H.264 и ThinWire+) для разных участков экрана. Возможны три опции:
- Не использовать Adaptive Display - используется только ThinWire+. Лучший вариант для пользователей приложений с преимущественно статичной картинкой.
- Для всего экрана целиком (For entire screen) - Используется только протокол H.264. Рекомендуется для мультимедийных и 3D приложений, особенно на каналах связи с низкой пропускной способностью.
- Для активно меняющихся участков экрана (For actively changing regions) - Для обработки активно меняющихся участков используется H.264, а для статичных участков - ThinWire+. Оптимальный вариант для любых приложений.

Выбор правильного кодека (протокола) не только влияет на ощещения пользователя от работы, но влияет и на максимальное количество пользователей, работающих на одном физическом сервере.

Выбор сетевого транспортного протокола

Трафик HDX может передаваться с помощью одного из трех сетевых протоколов транспортного уровня:

TCP - Протокол является индустриальным стандартом. Применяется в локальных сетях и каналях связи с невысокими задержками. При увеличении дистанции и задержек становится неэффективным из-за высокого числа повторных передач.
EDT( Enlightened Data Transport) - Проприетарный протокол Citrix, основанный на UDP. Подходит для каналов связи с высоким уровнем потерь и высокими задержками. Обеспечивает приемлемую скорость работы без существенной нагрузки на сервер, при некотором увеличении требований к пропускной способности канала связи.
Адаптивный протокол (Adaptive Transport) - протокол сочетающий TCP и EDT. Если возможно используется EDT, а если использование EDT невозможно - используется TCP.

В большинстве случаев рекомендуется использовать адаптивный протокол (Adaptive Transport).

Выбор оптимизации входа (Logon Optimization)

При каждом подключении пользователя (если это не переподключение - reconnection) должен завершиться процесс входа (logon process), который включает в себя инициализацию сессии, загрузку профиля пользователя, применение политик, подключение сетевых дисков и принтеров, выполнение логон-скриптов и инициализацию рабочего окружения. Каждый из этих элементов занимет время и удлинняет процесс входа. Citrix Workspace Environment Management позволяет существенно оптимизировать процесс входа и ускорить его. При иcпользовании WEM во время входа не мапятся диски и принтеры, не выпоняются логон-скрипты и не загружается перемещаемый профиль. Все эти действия производятся в многопоточном фоновом режиме после инициализации сессии и рабочего стола. Таким образом, пользователь получает доступ к своему рабочему месту значительно быстрее.
В большинстве случаев оптимизацию входа следует включать по-умолчанию.

Средства самообслуживания пользователей

Средства самообслуживания позволяют пользователям изменять параметры рабочего окружения и самостоятельно решать возникающие проблемы. Например - в большинстве организаций политка паролей предусматривает периодическую смену паролей. Если у пользователя есть несколько устройств, на которых пароли сохранены, то обновить пароли придется на каждом устройстве. В противном случае - очень вероятно, что при смене пароля учетка заблокируется, потому что каждое устройство попытается залогиниться со старым паролем.
StoreFront позволяет облегчить работу администратора предоставляя следующие функции:

Разблокировка учетной записи (Account Unlock). Если пользователь знает ответ на секретный вопрос - он сможет самостоятельно разблокировать свою учетную запись через интерфейс StoreFront/
Сброс пароля (Password Reset). Если пользователь знает ответ на секретный вопрос - он сможет самостоятельно сбросить забытый пароль.

Архетектура подсистемы самообслуживания пользователей (self-service password reset - SSPR) включает в себя: SSPR Service, Central Store (хранилище ответов на контрольные вопросы) и пару учетных записей:

Data Proxy Account - учетная запись, используемая для доступа к Central Store, в котором хранятся зашифрованные ответы на контрольные вопросы.
Self Service Account - учетная запись в AD, которая имеет права на сброс паролей и разблокировку учетных записей пользователей.

Кроме того, сервис SSPR требует составления секретных вопросов. Лучше всего, если будут созданы группы вопросов группы вопросов на разные темы.

Пользовательские профили

Пользовательский профиль играет важнейшую роль. Даже если вам удалось идеально настроить инфраструктуру, все впечатление от использования VDI может быть испорчено очень долгим входом из-за некорректно настроенного профиля.
Тип применяемого профиля пользователя должен соотвествовать задачам определенным на этапе оценки.

Тип профиля

Локальный профиль (Local Profile) - локальные профили создаются на базе дефолтногопрофиля и хранятся непосредственно на сервере или виртуальной машине, к которой подключается пользователь. Таким образом, если пользователь подключается к нескольким машинам, то на каждой будет создан локальный профиль. Изменения, произведенные пользователем сохраняются, однако доступны только на машине на которой были произведены.
Перемещаемый профиль (Roaming Profile) - перемещаемые профили хранятся на сетевом ресурсе. Информация, хранящаяся в перемещаемом профиле доступна пользователю при работе на нескольких машинах. Для настройки перемещаемого профиля администратору необходимо прописать путь к профилю в настройках пользовательской учетной записи. При первом входе пользователя его профиль создается на базе дефолтного профиля. При выходе пользователя из системы содержимое папки профиля копируется на заданный сетевой ресурс.
Неизменяемые профили (Mandatory Profiles) - неизменяемые профили обычно хранятся централизованно на сетевом ресурсе. При выходе пользователя из системы изменения в профиле не сохраняются. Сделать из обычного профиля неизменяемый можно просто переименовав файл профиля NTUSER.DAT в NTUSER.MAN. Также неизменяемые профили можно конфигурировать с помощью групповых политик или Citrix Profile Management.
Гибридные профили (Hybrid Profiles) - в рамках гибридного профиля объединяются “ядро” профиля на базе дефолтного (или кастомизированного) профиля и настройки реестра и файлы, подключаемые при логоне. Этот метод позволяет администраторам контролировать то, какие изменения сохранятся в профиле, а какие будут оставаться неизменными. Таким образом, размер профиля будет оставаться в пределах разумного. Кроме того, гибридные профили позволяют использовать функцию last writes wins, которая отслеживает все записи в профиль из нескольких сеансов и позволяет избежать коллизий. Также в профиль записываются только изменения, что позволяет сократить время выхода из системы. Хорошим примером системы управления гибридными профилями является Citrix Profile Management.

В таблице сравниваются возможности различных профилей: Для того, чтобы правильно выбрать тип профиля для каждой группы важно понять их требования к персонализации в рамках выбранной модели VDI.
В таблице ниже приведены рекомендации по выбору типа профиля в зависимости от типа ресурсов VDI:

Перенаправление папок

Перенаправаление папок может дополнить любой из типов профилей. Перенаправление папок это хорошее решение, которое позволяет подключать выбранные папки как сетевые ресурсы и тем самым существенно уменьшает размеры пользовательского профиля. Однако, следует избегать перенаправления папок в которые постоянно производится интенсивная запись или чтение (например - AppData), потому что это может приводить к замедлению работы приложений и неоправданной нагрузки на сервер. При планировании перенаправления папок важно исследовать активность приложений при чтении/записи данных во избежание проблем. Например - Microsoft Outlook постоянно выполняет чтение подписи пользователя из профиля при создани сообщений.
В таблице приведены рекомендации по перенаправлению папок:

Исключение папок из профиля

Некоторые папки нужно исключать из профилей пользователей для уменьшения размеров профилей. По умолчанию, Windows не хранит в перемещаемых и гибридных профилях папки AppData\Local и AppData\LocalLow, в том числе History, Temp и Temporary Internet Files. Кроме того, следует исключать и другие папки, например Downloads и прочие. Все перенаправляемые папки нужно исключать из перемещаемых и гибридных профилей.

Кеширование профиля

Кешировани перемещаемого или гибридного профиля на локальном диске может существенно снизить время входа и нагрузку на сеть. При использовании кеширования на сетевой ресурс сохраняются только изменения в профиле. Недостатком включения кеширования профилей является существенное повышение требований к дисковой подсистеме и объему незанятого места на диске.
В некоторых вариантах внедрения VDI, при завершении работы пользователя состояние виртуальной машины приводится в исходное состояние. В такой конфигурации удаление локально кешированных профилей - это бессысленная трата ресурсов. НЕ рекомендуется удалять локально кешированные профили в следующих конфигурациях:

Пул рабочих столов (Hosted Pooled Desktops) (можно не удалять, если виртуальная машина принудительно перезагружается при выходе пользователя).
Персональный рабочий стол (Hosted Personal Desktops)
Локальная виртуальная машина (Local VM Desktop)
Удаленный доступ к рабочему месту (Remote PC Access)

Для ускорения завершения сеанса пользователя существует опция политик Citrix - “Delay before deleting cached profiles”. Включение этой опции позволяет завершить сеанс, а также дать возможность завершиться процессам, работающим с файлами профиля, отложив удаление локально кешированного профиля на заданное время.

Размещение профилей (Profile Path)

Выбор сетевого ресурса для размещения профилей - важный этап. В общем случае - рекомендуется размещать профили на высокопроизводительных NAS или файловых серверах.
При выборе сетевого ресурса важно учитывать четыре момента:

Производительность (Performance) - В крупных инфраструктурах файловый сервер будет испытывать пиковые нагрузки при массовом подключении и отключении пользователей и скорее всего для нормальной работы потребуется создание кластера файловых серверов для балансировки нагрузки.
Физическое расположение (Location) - Доступ к профилям осуществляется по протоколу SMB, для которого очень критична величина задержки в локальной сети. Кроме того, пропускная способность WAN-каналов обычно ограничена, что может вызывать существенные задержки в процессе доступа к файлам профиля. Таким образом - файловый сервер должен быть размещен поблизости от серверов приложений и рабочих столов.
Операционные системы (Operating system platforms) - профили, созданные в разных версиях ОС Windows(различные поколения и разрядность), как правило не совместимы между собой. Таким образом, для ресурсов с различными ОС следует предусмотреть отдельные папки профилей.
Индексирование (Index capabilities) - Для того, чтобы пользоваться преимуществами Windows Search профили следует размещать на файловых серверах Windows с поддержкой индексирования.

Путь к перемещаемому профилю можно задать двумя способами:

User object - с помощью соответствующего поля в параметрах свойств учетной записи пользователя.
Computer GPO variables - с помощью групповой политики компьютера к которому производится подключение. В этому случае можно разным группам компьютеров (с разными версиями ОС) назначить различные пути к профилям. Для балансировки нагрузки на файловые серверы нужно учитывать, что объект политики, которая настраивает Citrix Profile Manager, привязана к OU в AD, соответственно, для балансировки достаточно, чтобы компьютеры к которым подключаются пользователи находились в разных OU. Также логично выделять на каждую Delivery Group собственный файловый сервер.

Примечание: Microsoft не поддерживает связку DFS-N + DFS-R для хранения активно используемых профилей. Дополнительную информацию можно найти в статьях:

При использовании Citrix Profile Manager возможно использование третьего способа указания пути к профилям:

Аттрибуты и переменные объекта пользователя (User object attributes and variables) - Citrix Profile Manager позволяет сконфигурировать путь к профилю в объекте GPO, используя аттрибуты объекта пользователя в AD. Для этого нужно:
- Создать DNS-алиас (например - fileserver1), который ссылается на реальный файловый сервер.
- Занести имя DNS-алиаса в LDAP-аттрибут, который не имеет значения (например - I или UID).
- Сконфигурировать Citrix Profile Manager с помощью объекта GPO, а в пути к профилям указать ссылку на этот аттрибут. Например, если имя сервера прописано в аттрибуте UID, то путь в настройках GPO будет выглядеть так: \\#UID#\profiles\.

Кроме того, Citrix Profile Manager предоставляет доступ к переменным, значения которых соответствуют параметрам системы. Таким образом можно динамически строить путь к нужному профилю в зависимости от того на какую систему заходит пользователь. Доступны такие переменные:

!CTX_PROFILEVER! - содержит версию профиля - v1 или v2.
!CTX_OSBITNESS! - содержит битность ОС - x86 или x64.
!CTX_OSNAME! - содержит краткое наименование ОС, напрмиер - Win7.

таким образом, сочетая эти приемы можно добиться формирования полностью динамического пути к профилю, который позволит балансировать нагрузку между файловыми серверами и иметь для каждой версии ОС собственный путь к профилю:

\\#UID#\profiles$\%USERNAME%.%USERDOMAIN%\!CTX_OSNAME!!CTX_OSBITNESS!

Profile Streaming

Функция Profile Streaming доступна при использовании Citrix Profile Manager и позволяет значительно уменьшить время входа пользователя на компьютер. При использовании Profile Streaming система получает сообщение об окончании загрузки профиля сразу после входа пользователя, а файлы копируются на компьютер по мере необходимости (при доступе к ним).
Citrix рекомендует использовать Profile Streaming во всех сценариях развертывания. Если необходимо всегда иметь локальный кеш профиля (для увеличения быстродействия), то следует включать опцию Always Cache и устанавливать размер 0. В этом случае профиль пользователя будет скопирован на компьютер в фоновом режиме и система сможет пользоваться кешированной копией. Это может быть полезно в случае, если приложение пытается получить данные из папки AppData раньше, чем они были скопированы. Включение Always Cache позволяет увеличить быстродействие в случае когда папка AppData не перенаправлена (not redirected).

Active Write Back

Функция Profile Streaming доступна при использовании Citrix Profile Manager. Она следит за открытыми файлами и при закрытии файла копирует его на сетевой ресурс в фоновом режиме. Эта функция может быть очень полезна в сценариях, когда пользователь одновременно работает на нескольких рабочих столах. Однако, копируются только файлы, но не записи реестра.

подготовка-к-экзамену-xendesktop

anonymous@undisclosed.example.com (Anonymous) — Mon, 16 Dec 2019 12:38:57 +0000

Тут собрана информация из видеокурса по Citrix XenDesktop и сведения из официальной документации с сайта http://support.citrix.com/

Разделы курса обучения

2. XenDesktop Components, Architecture, and Prerequisites
3. Preparing for and Installing the XenDesktop Controller
4. Configuring and Licensing a XenDesktop Site
5. Creating a Catalog and Provisioning VMs
6. Managing Desktops with Citrix Desktop Studio
7. Connecting to Desktops: Plugins, Receiver, and Web Interface
8. Configuring XenDesktop Policies
9. Best Practices in Implementing XenDesktop Policies
10. XenDesktop Roles and Permissions
11. Preparing for and Installing Citrix Provisioning Services
12. Creating and Managing Private vDisks
13. Creating and Managing Standard vDisks
14. Updating Standard Mode vDisks
15. Managing the Boot Process for Devices
16. Additional Management Tasks in Provisioning Services
17. Integrating XenApp with XenDesktop
18. Delegating Daily Activities with Desktop Director
19. Troubleshooting XenDesktop and Provisioning Services
20. Building a Highly-Available XenDesktop Infrastructure

Разделы экзамена

Приведены темы, которые охватывают разделы экзамена и относительное количество вопросов на данную тему. Всего вопросов в экзамене 53.

■ 14% - Системные требования для установки XenDesktop
о Требования к серверу и базе данных SQL в зависимости от условий.
о Оптимальное размещение кеша записи (write cache location).
о Требования к системе хранения данных.
о Определение количества контроллеров и/или серверов обеспечения (Provisioning services servers).

■ 13% - Установка и настройка инфраструктуры
о Установка и конфигурирование серверов обеспечения (Provisioning services)
о Установка и конфигурирование контроллера XenDesktop (Controller).
о Создание шаблона (образа) Windows 7.
о Настройка исключений файервола в зависимости от условий.

■ 35% - Начальное конфигурирование XenDesktop
о Конфигурирование мастер-образа (master image).
о Определение оптимального способа доставки приложения, который будет учтен при установке приложения в мастер-образ (golden image).
о Конвертирование мастер-обрахза (golden image) в формат vDisk.
о Создание каталога или группы рабочих столов (desktop group).
о Настройка планов электропитания.
о Использование функций HDX и конфигурирование политик HDX.
о Конфигурирование функций интергации клиента (client integration).
о Конфигурирование политик Citrix в соответствии с требованиями.
о Конфигурирование стримминга (streaming) на физическое устройство.
о Конфигурирование удаленного доступа.

■ 17% - Управление инфраструктурой XenDesktop
о Управление политиками Citrix в соответствии с требованиями.
о Способы управления группами рабочих столов (desktop groups).
о Анализ данных, поступающих от Virtual Desktop Agent.
о Обновление образов vDisks вручную или автоматически в соответствии с текущими требованиями.
о Конфигурирование ролей (roles).

■ 21% - Решение проблем
о Решение проблем с контроллером (Controller) по описанию проблемы
о Обнаружение причин проблем с Provisioning services.
о Обнаружение причин проблем в Virtual Desktop Agent/client.

Полезные статьи:
■ Руководство по разработке и внедрению решения XenDesktop масштаба предприятия - http://support.citrix.com/article/CTX121478
■ Включение журналирования для Desktop Delivery Controller и Virtual Desktop Agent - http://support.citrix.com/article/CTX117452
■ Решение проблем с XenDesktop Deployments - http://support.citrix.com/article/CTX125177
■ Мониторинг функций HDX - http://support.citrix.com/article/CTX123058

Терминология XenDesktop 5.x

• Теперь то что называлось фермы (Farms) называется сайтами (Sites). То ест географически обособленные инсталляции XenDesktop.
• Каталог (Catalog) - это набор виртуальных рабочих мест пользователей, управляемый как единое целое. Принадлежность к какому-либо каталогу указывает на то где исполняется это рабочее место. Например - “каталог виртуальных машин, работающих на VSphere”, или “каталог виртуальных машин, работающих на XenDesktop” и т.д.
• Группы рабочих столов (Desktop Groups) - это набор виртуальных рабочих мест, принадлежащих одному или нескольким каталогам и доступных определенным группам пользователей. Например - группа рабочих мест, исполняемых на VSphere и доступных торговым агентам. Группа рабочих столов также указывает на характер использования рабочих мест - они могут быть персонализированными, либо разворачиваемыми из общего шаблона.
• Хосты (Hosts) - это серверы, на которых исполняются виртуальные рабочие места.

Ключевые отличия от предыдущих выпусков

• XenDesktop больше не использует хранилище IMA (IMA store), больше нет выделенного мастера зоны (dedicated Zone master) или сборщика данных (Data Collector). Вместо этого все данных хранятся в базе данных SQL.

• XenDesktop теперь очень полагается на базу SQL и она является потенциально единственной точкой отказа.

• Базы данных Microsoft Access и Oracle больше не поддерживаются.

• На контроллерах (Controllers) больше не нужны службы терминалов и удаленных рабочих столов (TS/RDS).

• Обнаружение контроллера (Controller) теперь по-умолчанию происходит на основании записей реестра (Registry-based), с воможностью включить обнаружение в Active Directory. То есть хосты должны знать где находится контроллер и он может быть жестко прописан в реестрах хостов (что есть хорошо), либо может обнаруживаться в AD.

• XenDesktop теперь содержит SDK на базе PowerShell, что позволяет производить некоторые операции, недоступные из графической консоли.

• Некоторые утилиты командной строки больше недоступны.

Установка XenDesktop

Ниже приведена простая схема взаимодействия компонентов XenDesktop

Требования к серверу, на котором будет работать Контроллер (Controller)

XenDesktop Controller Requirements
■ Windows Server 2008 SP2 or R2, Standard or Enterprise Edition.
о .NET Framework v3.5 SP1
о IIS 7.0 or 7.5 with ASP.NET 2.0 (Web Interface, License Server, and/or
Desktop Director).
о Microsoft Visual J# 2.0 Redistributable, Second Edition (Web Interface)
о Microsoft Visual С++ 2008 with SP1 Redistributable
о Microsoft Windows PowerShell 2.0
о Internet Explorer 7.0 or later (License Server)
о Disk Space: 100MB for Controller and SDKs, 50MB for Desktop Studio,
50MB for Desktop Director, 40MB for licensing components, 100MB for
Web Interface and clients.

XenDesktop Controller Database Requirements
о Microsoft SQL Server 2008 R2 Express Edition
о Microsoft SQL Server 2008 R2
о Microsoft SQL Server 2008 SP1 (or later)
■ Поддерживаются как x86, так и x64 версии SQL Server в режимах одиночного сервера, кластера или зеркалирования. Аутентификация - Windows.

Терминология XenDesktop 7

Терминология XenDesktop 7 немного отличается от 5.x
Некоторые термины:
Каталог машин (machine catalog) - набор виртуальных и физических машин, управляемых как единое целое. Для определения каталога машин нужно:
- Физические или виртуальные машины.
- Учетные записи в Active Directory этих физических или виртуальных машин.
- В некоторых случаях - мастер-образ, копируемый при создании виртуальных машин.

Группа доставки (Delivery Group) - это группа пользователей, которой доступен набор приложений. Одной группе доставки могут быть доступны приложения из нескольких каталогов машин, а не из одного пула. Также единственная Delivery Group может быть опубликована для пользователя, таким образом пользователь получит доступ к приложениям группы.

Ключевые различия XenApp и XenDesktop

Для настройки параметров окружения и публикации приложений используется Citrix Studio.

Например, вместо папок приложений (folders) и Worker Groups в Studio ресурсы организуются с помощью комбинации каталогов машин (machine catalogs), меток (tags), групп доставки (Delivery Groups), и делегирования административных прав (Delegated Administrators).

Делегирование администратативных прав (Delegated Administration) — в XenDesktop можно создавать администраторов, права которых регулируются ролями (role) и областями влияния (scope). Роль - это набор функций и прав на их выполнение. Область влияния (scope) - это набор объектов. Области влияния создаются в соответствии со структурой предприятия (например набор групп доставки, используемых командой продавцов). Кроме того, доступны несколько строенных административных ролей - администраторы службы поддержки, администраторы приложений, администраторы серверов и каталога. Каждая встроенная роль имеет определенный набор прав.

- Отсутствует хранилище IMA (IMA data store) — данном релизе (XenDesktop 7) нет централизованного хранилища IMA (data store), хранящего информацию о конфигурации. Вместо этого используется база данных Microsoft SQL Server, в которой хранится как иформацтя о конфигурации. так и информация о текущих сессиях. Это означает что:

Требования к базе данных отличаются. Не поддерживаются Microsoft Access и Oracle.
Службы удаленных рабочих столов (Terminal Services - Remote Desktop Services) больше не нужны на серверах, на которых работает Controller. При этом, лицензии для удаленных рабочих столов по прежнему (Terminal Services Client Access Licenses - TS CALs) нужны.
Теперь нет выделенного мастера зоны (dedicated zone master). В XenApp было понятие мастера зоны (zone master) или сборщика данных (data collector), который отвечал на запросы пользователей и взаимодейтсвовал с гипервизорами. Теперь эти функции распределены равномерно по всем контроллерам (Controllers).
При необходимости обеспечения отказоустойчивости Microsoft SQL Server, можно сконфигурировать кластер или репликацию (clustering или mirroring). Или же просто разместить сервер с базой данных в виртуальной машине и использовать функкции гипервизора для обеспечения отказоустойчивости.

- Архитектура FlexCast Management Architecture (FMA) — FMA требует наличия домена. Напрмер, для установки серверов нужно иметь права как локального администратора, так и администратора домена Active Directory.

- Вместо понятия ферма (Farm) в XenDesktop используется понятие сайта (Site). Сайт должен размещаться в пределах одного ЦОД.

- Citrix Director - это средство мониторинга, по-умолчанию устанавливаемое как web-сайт на контроллере доставки (Delivery Controller). Из консоли Citrix Director администратор (в соотвествии со своей ролью) может следить за состоянием инфраструктуры, устройств пользователей и решать проблемы, возникающие при работе.

- Для удаленного взаимодействия с сеансами пользователей в консоли Citrix Director есть функция удаленного помощника (shadow), которая работает на базе Microsoft Remote Assistance. Remote Assistance устанавливается по-умолчанию и включается/отключается соответствующей галочкой.

Компоненты XenDesktop

На рисунке ниже приведена схема взаимодействия компонентов Citrix XenDesktop:

Director — средство мониторинга с web-интерфейсом. Director позволяет службам поддержки выявлять и решать проблемы, возникающие как в инфраструктуре, так и у конечных пользователей.

Receiver — Это приложение установленное на компьютерах пользователей для доступа к сервиса Citrix XenDesktop.

StoreFront — этот компонент аутентифицирует пользователей и предоставляет им доступ к рабочим столам и приложениям.

Studio — это единая консоль управления инфраструктурой XenDesktop.

Delivery Controller — компонент, устанавливаемый на серверы, который взаимодейтсвует с гипервизорами, распределяя приложения и виртуальные рабочие столы, аутентифицирует пользователей, управляет подключениями пользователей к их приложениям. Controller управляет состоянием виртуальных рабочих мест, запускает и останавливает их по мере необходимости в соответствии с конфигурацией. В некоторых редакциях продукта Controller позволяет установить компонент Profile management, который управляет персональными настройками рабочих мест пользователей. На каждом сайте XenDesktop есть как минимум один Delivery Controller.

XenServer — это гипервизор, на котором запускаются виртуальные рабочие места пользователей (виртуальные машины).

Virtual Delivery Agent (VDA) — компонент. устанавливаемый на серверы и рабочие станции, позволяющий подключаться к рабочим станциям и приложениям. Для удаленного доступа к ПК следует установить на нем VDA.

Machine Creation Services (MCS) — набор служб, по требованию создающих виртуальные серверы и рабочие места из мастер-образов. Также эти службы оптимизируют хранение образов. Machine Creation Services полностью интегрированы в Citrix Studio.

Windows Server OS machines — виртуальные или физические машины под управлением серверной ОС Windows Server, на которых исполняются приложения и виртуальные рабочие места.

Desktop OS machines — виртуальные или физические машины под управлением настольной ОС Windows Desktop, на которых исполняются приложения, работающие в настольной ОС или персонализированные виртуальные рабочие места.

Дополнительные компоненты предоставляют следующие функции:

Безопасная доставка (Secure delivery) — Для безопасного подключения пользователей из внешней сети (интернет) может использоваться Citrix NetScaler Gateway (ранее - Access Gateway). NetScaler Gateway или виртуальное приложение NetScaler VPX - это приложение SSL VPN, размещаемое в DMZ и предоставляющее единую точку безопасного подключения через корпоративный фаейрвол.

Оптимизация WAN - в случаях, когда виртуальные рабочие места доставляются удаленным пользователям, для повышения производительности может использоваться Citrix CloudBridge (ранее - Citrix Branch Repeater или WANScaler). Репитеры (Repeaters) повышают производительность при работе в глобальных сетях. CloudBridge приоретизирует трафик для максимального комфорта пользователей. HDX WAN Optimization с CloudBridge обеспечивают сжатие и дедупликацию данных, существенно уменьшая необходимую полосу пропускания сетевых интерфейсов.

Доставка приложений

В XenApp для подготовки приложений и доставки их пользователям применяется мастер доставки (Publish Application wizard). В XenDesktop для создания приложений и публикации их пользователям, принадлежащим группам доставки (Delivery Group), используются компоненты Studio. С помощью Studio сначала конфигурируется сайт (site), затем создается каталог машин (machine catalogs), а затем в рамках этого каталога машин создаются группы доставки (Delivery Groups). После этого Delivery Groups используется для определения прав пользователей на доступ к приложениям. Дополнительно тут: http://support.citrix.com/proddocs/topic/xendesktop-7/cds-create-update-desktops-wrapper-rho.html#cds-distribute-update-desktops-wrapper-rho

После создания групп доставки можно создать приложение и указать какие группы доставки будут иметь доступ к этим приложениям. В Studio можно посмотреть какие приложения назначены группе доставки, а также включить или отключить приложения.

Для доставки приложений используются следующие методы:

Hosted applications and desktops — Этот метод доставки аналогичен функциям XenApp. Приложение устанавливается и исполняется на сервере XenDesktop.
Local App Access - Этот метод доставки позволяет интегрировать локальные приложения пользователя (установленные на его рабочем месте) и приложения, опубликованные в XenDesktop. То есть пользователь получает доступ и к локальным и к опубликованным в XenDesktop. Ярлыки локальных приложений публикуются на виртуальном десктопе. При запуске локального приложения в виртуальном рабочем месте окно приложения отображается на виртуальном рабочем столе, хотя само приложение исполняется на локальном компьютере пользователя.
Streamed applications** — в этом выпуске XenDesktop использует App-V 5.0 в качестве основной технологии доставки потоковых (streamed) приложений. Для профилирования приложений можно использовать те же средства, что и для XenApp - Streaming Profiler и Offline Plug-in.

Manage multiple versions of XenApp and XenDesktop

There is no XenApp to XenDesktop 7 upgrade. Citrix will support customers in their migration from XenApp 6.5 to XenDesktop in a future release and plans to release tools and or scripts to assist in this transition.

The Studio management and Director can monitor and manage only XenDesktop 7 sites. The monitoring and management tools do not support past versions of XenDesktop or XenApp.

For example, XenDesktop 7 Director requires a XenDesktop 7 Delivery Controller. Director 7 can monitor XenDesktop 5.x VDAs; however, some data, including logon duration, will not be available with the XenDesktop 5.x VDAs.

Citrix recommends that if you continue running deployments of past versions of XenApp or XenDesktop, you run them in parallel with the XenDesktop 7 Site and continue running the management consoles with each release for that site.

For example, in a mixed environment, to continue using Desktop Director 2.1 to monitor XenApp 6.5, make sure that Desktop Director 2.1 is installed on a separate server from Director 7.

Use StoreFront to aggregate applications and desktops from the different versions of XenApp and XenDesktop. For details, see the StoreFront section.

подготовка-к-экзамену-1y0-a20-citrix-xenapp-6-5

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Компиляция и перевод - Усик Михаил aka Mike - mike@autosys.tk
Публикация и тиражирование только с разрешения. :)
Экзамен сдан с первой попытки. Результат - 88%.

Подготовка к экзамену 1Y0-A20 Citrix® XenApp 6.5

Основана на гайде Jeffrey C Rohrer (Jeff Rohrer), сайт Citrixxperience.com.
http://citrixxperience.com/free/A20ResourceGuide.pdf
Гайд содержит ссылки в документации на 53 топика.

Дампы ~~реальных~~ пробных экзаменов можно взять тут: Дампы экзаменов 1Y-A20
~~Вопросы, которые попались мне на экзамене все были в этих дампах :)~~

Общие сведения и подготовка стенда

Об инфраструктуре

В рамках Citrix XenApp можно говорить о двух типах инфраструктуры:
1. Инфраструктура виртуализации, которая включает в себя серверы на которых исполняются приложения и серверы-контроллеры, которые обеспечивают создание сессий и администрирование - хранилище (data store) статичной информации, сборщик (data collector) хранилище динамической информации, брокер XML, сервер лицензий, база данных изменений конфигурации(опционально), компоненты мониторинга.

2. Инфраструктура предоставления и администрирования доступа к приложениям - Web-интерфейс, Шлюз безопасности Secure Gateway (опционально), Шлюз доступа Access Gateway (опционально).

Функции контроллеров могут объединяться в рамках одного сервера, в зависимости от размеров фермы и нагрузки.
Принцип объединения - общие функции. Например - data collector объединяется с data store и XML broker, а также, возможно, с сервером лицензий и web-интрефейсом.

Компоненты

Data Store
База данных MS SQL или Oracle, хранящая статическую информациюб о конфигурации фермы - приложениях, пользователях, принтерах и т.д. Каждая ферма XenApp имеет единственный Data Store. Первый конфигурируемый в ферме сервер становится по-умолчанию data store.
Не следует устанавливать XenApp на сервер с базой данных!
Скорость сервера с базой данных влияет на:
- Скорость запуска многих серверов одновременно.
- Скорость добавления/удаления серверов из фермы.
- Скорость работы инструментов администрирования.
При этом, скорость работы других функций, например запуск IMA на одном сервере и обновление его кеша будет гораздо сильнее зависеть от размеров фермы, чем от производительности Data Store.
Размер базы варьируется от 32 Мб для фермы из 50 серверов и до 211 для фермы из 1000 серверов.
Двухъядерного процессора и 2 Гб RAM достаточно для Data Store фермы из 250 серверов, 4 Гб Ram для фермы от 500 серверов.
БОльшая честь операций с Data Store - это чтение.
Более чем 1 DataStore и репликация актуальны в распределенных конфигурациях, где компоненты связаны каналами с высокой задержкой.

Data Collector
Это база данных, работающая в оперативной памяти, которая хранит динамически изменяемую информацию - о текущей нагрузке, состоянии сессий, опубликованных приложениях, подключенных пользователях и использовании лицензий. Первый конфигурируемый в ферме сервер становится по-умолчанию data store. По-умолчанию все серверы в ферме конфигурируются как Data Collector с равными правами. При выходе из строя текущего основного Data Collector для продолжения нормальной работы происходят выборы нового Data Collector. Обычно на сервере с Data Collector не публикуют приложения.
Потребление памяти Data Collector возрастает по мере роста фермы. Для фермы из 1000 серверов потребление составит порядка 300 Мб.
Ресурсы процессора также потребляются незначительно и для фермы из 1000 серверов достаточно двухъядерного процессора Data Collector.
Так как взаимодействие DataCollector между собой создает трафик следует стремиться к уменьшению количества зон и Data Collector. Для зоны из 100 серверов, расположенных на одной площадке достаточно будет одного выделенного Data Collector, хотя не исключается и существование резервных Data Collector.

Zone
Зона это группа серверов, объединенных общим Data Collector. В фермах, где больше одной зоны, Data Collector работают как шлюзы между зонами.
Для нормальной работы зоны критичны высокая пропускная способность и низкая задержка сети. Наиболее критична - задержка. Каждый Data Collector постоянно держит открытое соединение с каждым Data Collector в зоне. Рекомендуется минимально возможное количество зон.
Несколько зон рекомендуется только в случае, когда серверы в одной ферме географически распределены по нескольким площадкам, связанным каналами с низкой пропускной способностью (например на разных континентах).
Не рекомендуется создавать более 5 зон.
Площадки с малым количеством серверов следует включать в зону с наибольшим количеством серверов.

Citrix XML Service и Citrix XML Broker
Citrix XML Service устанавливается на каждый сервер в ферме. XML Broker определяет, какие приложения будут отображаться в web-интерфейсе пользователя, в зависимости от разрешений. Когда пользователь аутентифицируется на web-сервере, XML Broker:
- Получает учетные данные от пользователи делает запрос к Independent Management Architecture (IMA) и формирует список опубликованных приложений, доступных пользователю и возвращает список в web-интерфейс.
- При получении запроса от пользователя на запуск приложения XML Broker находит серверы с этим приложением, выбирает подходящий и возвращает его адрес Web-интерфейсу.
Рекомендуется размещать XML Broker на одном сервере с Data Collector.
Не рекомендуется публиковать приложения на сервере с XML Broker.

Методы доставки приложений

Приложения бывают streamed - упакованные в контейнер и hosted - установленные на сервер XenApp.
Для streamed приложений создается профиль приложения, который размещается на сервере профилей или web-сервере и содержит XML-файл манифеста (.profile), файлы приожения, контрольную сумму, иконки (Icondata.bin), и скрипты исполняемые перед запуском и после завершения приложения.
Приложения могут быть опубликованы тремя разными способами, либо их сочетанием:
1. Installed on server - приложение устанавливается как на сервер терминалов. Преимущества - независимость от пользовательского устройства, централизация.
2. Streamed to server - приложение инкапсулируется в профиль приложения, хранится на сервере и при запуске обрабатывается на сервере. Преимущества - возможность запуска разных версий приложений на одном сервере, удобный централизованный апдейт приложений, независимость от пользовательского устройства. Недостатки - некоторые приложения будут неправильно работать из профиля (например .NET).
3. Streamed to desktop - приложение инкапсулируется в профиль приложения, хранится на сервере, а при запуске обрабатывается на компьютере пользователя. Преимущества - ресурсоемкие приложения используют ресурсы десктопа, возможность работы off-line. Недостатки - пользовательское устройство должно работать под управлением WIndows и иметь достаточные ресурсы.

Опубликовать можно как целиком рабочий стол, так и отдельное приложение.
Профили Streamed-приложений должны размещаться на файловом сервере с доступом CIFS либо HTTP/HTTPS. HTTP-доступ работает быстрее и может применяться для централизованной публикации для удаленных филиалов.

Группировка приложений на серверах

Приложения могут размещаться по принципу одно приложение - на один или несколько серверов. Это называется siloing. Каждое приложение запускается четко на заранее заданных серверах. Рекомендуется для критичных высоконагруженных приложений.

Напротив - non siloing - это когда все приложения опубликованы на всех серверах. Не рекомендуется в случае конфликта приложений в рамках одного сервера. Для предотвращения конфликтов можно публиковать приложения как streamed. В этом случае приложение эффективно изолируется и конфиликтующие приложения нормально исполняются на одном сервере.

Рекомендуется тесно взаимодействующие между собой приложения публиковать на одном сервере. Это ускорит работу и снизит нагрузки на сети.

Балансировка нагрузки

Балансировка нагрузки может приследовать следующие цели: увеличение коэффициента использования серверов, обеспечение работы критичных приложений, обеспечение высокой доступности.
XenApp предлагает два метода балансировки:
1. Load Manager - этот метод распределяет новые подключения к ферме. При запуске первого приложения, сессия пользователя будет размещена на наименее загруженном сервере фермы, в соответствии с заданными критериями. При запуске последующего приложения, если оно опубликовано на том же сервере, то распределения нагрузки происходить не будет. Если запускаемое приложение опубликовано на другом сервере, то сессия будет расшарена между серверами и будет будет произведено распределение.
2. Preferential Load Balancing - балансировка на основе предпочтений. Для каждого приложения или пользователя можно задать лимиты потребления ресурсов CPU или уровень важности (Low, Normal, or High). По-умолчанию, всем приложениям и пользователям дается уровень важности Normal.

Различие между Load Manager и Preferential Load Balancing состоит в том, что для Load Manager все сессии одинаковые, а Preferential Load Balancing позволяет задавать для каждой сессии свои настройки.

Для балансировки нагрузки, приложения, опубликованные на разных серверах, должны иметь одинаковые настройки. Этого можно добиться либо с помощью скриптов установки, либо Installation Manager, либо Microsoft System Center Configuration Manager, либо сделав приложения streamed.

Сколько нужно серверов

Для правильного определения нужного количества серверов в ферме используется инструмент Load Testing Services, которые позволяет сымитировать запуск приложений пользователями и отследить важные параметры производительности - Total Processor Time, Thread Queue Length, Memory Consumption и Pages Per Second.

Планирование инфраструктуры

Планирование контроллеров

Независимо от размеров фермы понадобится как минимум один сервер-контроллер. На контроллере не рекомендуется публиковать приложения, хотя это и не запрещено. Запуск высоконагруженных опубликованных приложений на контроллере замедлит перечисление приложений.
Состояние контроллера следует оценивать по счетчикам производительности windows:
CPU - > 85% - 90%
Memory - > 80%
ResolutionWorkItemQueueReadyCount - > 0 for extended periods of time
WorkItemQueueReadyCount - > 0 for extended periods of time
LastRecordedLicenseCheck-OutResponseTime - > 5000 ms

Установка

ВАЖНО!
XenApp нельзя устанавливать на контроллер домена.
В одной ферме нельзя сочетать XenApp 6 XenApp более ранних версий.

ВАЖНО!!
Необходимо присвоить серверу имя перед началом установки XenApp.

http://habrahabr.ru/post/134334/

1. Ставим и обновляем Windows Server 2008 R2. Ставим Microsoft NetFramework 4 и снова обновляем систему.
2. В папке с дистрибутивом XenApp запускаем autorun.exe.
После этого установщик предложит нам установить NetFramework 3.5 с первым сервиспаком.
3.Далее необходимо установить роли. Нажимаем кнопку с Add server roles.
Выбираем роли:

License server
XenApp
Web Interface

Жмём «далее» на следующей вкладке выбираем

XML Service IIS Integration - (обязательная компонента!).

Больше НИЧЕГО выбирать не надо!
Два раза жмём Next, Install и ждём, чем закончится.

После непродолжительной установки XenApp выдаст окно с кучей восклицательных знаков и кнопкой «Finish».
В этом нет ничего страшного, просто нужна перезагрузка. Закрываем все окна и перезагружаем сервак. После перезагрузки setup возобновит свою работу автоматически, нужно выбрать «Resume install».

ВНИМАНИЕ! Все компоненты должны установиться без ошибок!
Т.е. все пункты должны быть отмечены зелёной галочкой! В противном случае придётся сносить и ставить систему заново!

В итоге всех телодвижений у нас должно появиться окно установщика со списком установленных компонент, напротив каждой из которых появится слово «configure».

Настройка

Итак, XenApp установился и предлагает нам его настроить. В окне программы мы видим:

XenApp — Specify Licensing
Web Interface — Configure
License Server — Configure

Начать надо с License Server — Configure.
По умолчанию предполагается наличие у вас лицензий Citrix XenApp Platinum Edition. Жмём Configure. Он предлагает настроить порты:

License Server Port: 27000
Vendor Daemon Port: 7279
Management Console Web Port: 8082

Порты менять не следует!
Задаём пароль админа и жмём ОК. License Server помечен зелёной галочкой и перешёл в состояние Configured.

После этого нужно добавить лицензию в сервер лицензирования. Для этого идём Пуск — Все программы — Citrix — Management Consoles — License Administration Console.

В открывшемся Web-интерфейсе, справа в углу жмём Administration, и вводим пароль админа, который мы указали ранее. Затем слева внизу переходим в раздел Vendor Daemon Configuration, и жмём кнопку Import License. Выбираем наш файл лицензии, ставим галку Overwrite License File (ведь лицензия у нас только эта), и жмём Import License. Далее жмём ОК, в списке лицензий выбираем нашу лицензию, и жмём кнопку Reread License.
image

На этом настройка лицензий завершена. Закрываем Web-интерфейс и переходим обратно к установщику.
В установщике нам нужно нажать Specify Licensing, чтобы XenApp увидел сервер лицензий и рабочие лицензии.
image

Вводим имя компьютера (тот, на котором мы и производим установку), жмём Test Connection, и жмём Next.

Если XenApp распознал лицензии, то ничего менять не надо, он укажет параметры автоматом. Если не распознал — значит все предыдущие шаги нужно проделать заново. Жмём Apply и видим, что Specify Licensing перешло в состояние Configured и помечено зелёной галочкой.
Теперь сконфигурируем сам сервер XenApp, нажав на Configure.

Т.к. это единственный и новый сервер XenApp в нашей сети, мы выбираем пункт Create a new server farm, т.е. создаём новую ферму серверов XenApp.
Указываем имя фермы, остальные параметры на этой вкладке оставляем по умолчанию. Дальше установщик предлагает выбор: Создать новую базу Data Store или использовать существующую. Т.к. предполагается, что никаких баз у нас нет, мы жмём New Database.
После этого вводим логин и пароль администратора сервера (только локального, даже если сервер в домене!), всё время жмём Next, оставляя параметры по умолчанию, и после нажатия Apply видим процесс настройки базы данных. Жмём Finish и Reboot.
В результате установится экземпляр Microsoft SQL Server Express с именем CITRIX_METAFRAME и создастся база данных с именем MF20 с аутентификацией Windows.

После перезагрузки мы видим, что несконфигурированным у нас остался только Web-Interface. Перед его конфигурацией ОБЯЗАТЕЛЬНО нужно сделать следующее:

cmd: altaddr /SET ВАШ_ВНЕШНИЙ_АЙПИ

Сворачиваем установщик и запускаем:

Пуск — Все программы — Администрирование — Citrix — Management Consoles — CitrixApp Center

В открывшемся окне выбираем:

Disable Authenticode Signature Checking

Откроется окно настройки фермы XenApp, жмём Далее, снимаем галочку с позиции Single Sign-On, жмём Далее, жмём Add Local Computer — тут мы добавляем серверы, где установлен XenApp.

В нашем случае это локальный комп, его и добавляем.

Потом всё время далее, установщик дисковерит сеть и сервер на предмет соответствия всем указанным параметрам, и, если его всё устраивает, то предлагает нажать Apply. Жмём, и вот мы в консоли управления XenApp.
В целом на этом настройка самого XenApp закончена.

Раздел 1 - Введение в архитектуру Citrix

1.1 - Начало конфигурирования. Как создать и выбрать выделенный контроллер.

http://support.citrix.com/proddocs/topic/xenapp65-install/ps-config-prep.html

При конфигурировании фермы XenApp задается тип базы данных, используемый для Data Store.
Если выбран вариант базы данных Microsoft SQL Server Express, то он будет установлен автоматически в процессе конфигурирования.
Если выбран вариант базы данных Microsoft SQL Server или Oracle, то перед началом конфигурирования следует создать базу, а в случае использования Oracle - установить соответствующий клиент и перезапустить сервер.

Если осуществляется установка с помощью сценария командной строки и используется вариант базы данных Microsoft SQL Server или Oracle, то перед началом конфигурирования следует создать файл Data Source Name (DSN). Каждый сервер фермы должен иметь файл DSN, доступны либо локально, либо на сетевом ресурсе. Для указания месторасположения файла используется опция /DsnFile:dsn_file .

Если используется опция Configuration Logging и необходимо зашифровать журналируемые данные, то на серверы, присоединяемые к ферме, следует установить ключи шифрования. Это необходимо сделать после конфигурирования, но до перезагрузки сервера.

Режим работы сервера XenApp

Все серверы XenApp могут обрабатывать сессии пользователей. Режим работы сервера определяет, будет ли сервер только обрабатывать сессии пользователей (режим session-only), либо кроме того будет выполнять функции сборщика данных(data collector) и на нем будет выполняться XML broker (режим controller and session-host).
Конфигурирование сервера в режим session-only может увеличить производительность, особенно в больших фермах с несколькими зонами. Количество серверов, сконфигурированных в режиме контроллера должно гарантировать бесперебойную работу фермы, при выходе одного из контроллеров из строя.

- Сервер XenApp в режиме контроллера следит за состоянием других контроллеров в ферме и инициирует выборы сборщика данных (data collector), в случае необходимости.
- Citrix XML Service должен запускаться на сервере, сконфигурированном в режиме контроллера.
- Перечисление приложений выполняется только сервером в режиме контроллера.
- AppCenter может обнаружить и подключить только серверы в режиме контроллера.
- В каждой ферме и в каждой зоне должен быть как минимум один сервер в режиме контроллера.
- Если выполняется миграция с XenApp ранних версий, то процердура миграции должна запускаться на сервере в режие контроллера XenApp 6.5.

При создании новой фермы, утилита XenApp Server Configuration Tool автоматически конфигурирует сервер в режиме контроллера. Первый сервер в ферме не может быть сконфигурирован в режиме session-only. Это гарантирует, что в ферме будет хотя бы один сборщика данных (data collector). При присоединении к ферме новых серверов можно выбрать режим. По-умолчанию сервер присоединяется к ферме в режиме контроллера. В предыдущих версиях XenApp была недоступна опция выбора режима сервера - все серверы работали в режиме контроллера.

При конфигурировании в режиме командной строки следует указать опцию /ImaWorkerMode:False для работы в режиме контроллера (по-умолчанию) или /ImaWorkerMode:True для работы в режиме session-only.

Для того чтобы изменить режим работы уже сконфигурированного сервера следует отключить его от фермы и присоединить заново.

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-console-zones-config-v2.html

Конфигурирование зон и сборщиков данных.

Зона это группа серверов XenApp. Создавать зоны можно как во время инсталляции фермы, так и после.
По-умолчанию - все серверы фермы принадлежат одной зоне - Default Zone. Каждая зона имеет один сервер, который хранит информацию о серверах и опубликованных приложениях зоны - это сборщик данных зоны (data collector).
В фермах, где зона не одна, сборщики данных функционируют как шлюзы между зонами.
В AppCenter список зон можно просматривать и при необходимости создавать новые зоны. В каждой зоне должен быть хотя бы один сервер. Пустые зоны удаляются автоматически.
При создании зоны или при присоединении к зоне нового сервера происходят выборы сборщика данных для данной зоны. Если текущий сборщик данных станет недоступным, то производятся новые выборы.

ВАЖНО: Никогда не следует делать сборщиком данных контроллер домена Windows. Эта ситуация может возникнуть при установке XenApp на контроллер домена. Citrix не поддерживает установку XenApp на контроллер домена.

1. В AppCenter выберите ферму.
2. В панели слева раскройте дерево зон, чтобы увидеть текущие зоны.
3. Для создания новой зоны - кликните Zones в левой панели, в меню Действие (Actions), кликните New > Create a new zone(эти опции меню доступны только если ферма содержит два или более серверов). Откроется мастер создания зоны. Следуйте инструкциям - задайте имя зоны и добавьте или удалите серверы.
4. На странице управления предпочтениями выбора серверов Election Preference выберите сервер, кликните правой кнопкой и выберите Set server's zone election preference для того чтобы выбрать какое место сервер займет в ранге:
- Most Preferred. Сервер всегда будет первым в списке на выборах нового сборщика данных (data collector). Рекомендуется, чтобы только один сервер в зоне имел такой статус.
- Preferred. При выборе нового сборщика данных XenApp выберет сервер с этим статусом, если север Most Preferred недоступен.
- Default Preference. Настройка по-умолчанию для всех серверов. Если при выборах недоступны Most Preferred и Preferred, то будет выбран сервер с этим статусом.
- Not Preferred - При этой настройке сервер будет участвовать в выборах только если нет других кандидатов на роль сборщика данных со статусами Most Preferred, Preferred или Default Preference.
5. Перезагрузите серверы с измененными настройками, чтобы они вступили в силу. Это необходимо, чтобы настройки были обновлены на текущих сборщиках данных в зонах.

Список зон отображается на центральной панели в соответствии с предпочтениями выборов.
Для изменения настроек существующих зон:

- Для того чтобы переименовать зону кликните в панели слева по ней правой кнопкой мыши и выберите Переименовать (Rename).
- Для того чтобы изменить настройки выборов сборщика данных выберите зону, затем в центральной панели выберите вкладку Election Preference, кликните правой кнопкой по серверу в центральной панели и выберите Set server's zone election preference.
- Для того чтобы переместить сервер в другую зону кликните правой кнопкой по серверу в центральной панели и выберите Change server's zone membership.

1.2 - Определение типа хранилища для Data Store в соответствии с требованиями и его установка

http://support.citrix.com/proddocs/topic/xenapp65-planning/ps-planning-datastore-intro-v2.html

Для создании фермы XenApp должно быть создано хранилище конфигурации, к которому обращаются сервера при загрузке. В хранилище содержатся следующая информация:

- Сведения о конфигурации фермы
- Сведения об опубликованных приложениях
- Конфигурации серверов
- Учетные записи администраторов Citrix
- Информация о конфигурации принтеров

Выбор базы данных

При выборе базы данных следует учитывать следующие факторы:
- Количество серверов в ферме и перспективы его увеличения
- Компетентность администратора баз данных. (MS SQL или Oracle)
- Перспектива расширения предприятия и соответствующего расширения базы данных и усложнения обслуживания
- Требования к обслуживанию базы данных - резервное копирование, избыточность для отказоустойчивости, репликация

Основные рекомендации по размерам БД приведены в таблице:

Маленькая|Средняя|Большая|Очень большая
Серверов|1-50|25-100_|50-100_|100 или больше
Пользователей_|_< 150|< 3000_|< 5000_|> 3000
Приложений|< 100_|< 100|< 500|< 2000

- Microsoft SQL Server и Oracle подходят инсталляций для любого размера. При их использовании в распределенных фермах можно добиться прироста производительности с помощью репликации и распределения нагрузки по нескольким серверам баз данных.
- Не устанавливайте XenApp на серверах SQL Server или Oracle
- SQL Server Express подходит для маленьких, большинства средних инсталляций, физически размещенных в одном месте

1.3 - Определение необходимых служб, протоколов и сетевых портов

Номера портов

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-securing-cfg-tcp-ports.html

В таблице приведены номера сетевых портов, используемые службами XenApp. Эта информация полезна для конфигурирования межсетевых экранов.

Citrix AppCenter - порт 135, не конфигурируется
Citrix SSL Relay - порт 443, конфигурируется в настройках Microsoft Internet Information Service (IIS)
Citrix XML Service - порт 80, конфигурируется при установке
Client-to-server (directed UDP) - порт 1604, не конфигурируется
ICA sessions (входящий clients to servers) - порт 1494 See ICAPORT
License Management Console - порт 8082, See the licensing documentation
Server to license server - порт 27000, для изменения в консоли откройте свойства фермы или сервера и выберите License Server
Server to Microsoft SQL Server or Oracle server - порты 139, 1433, or 443 for MS-SQL, за дополнительно инфрмацией обращаться в документацию сервера баз данных
Server to server - порт 2512 See IMAPORT
Remote AppCenter to server - порт 2513 See IMAPORT
Session reliability - порт 2598, конфигурируется с помощью политики Citrix Computer.
—————————————

Конфигурирование средств поддержания сессий - '''Session Reliability'''

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-sessions-sess-rel-v2.html
Средства поддержания сессий (Session Reliability) поддерживает сессии пользователей в рабочем состоянии на устройстве пользователя при разрывах сетевого соединения. Пользователи продолжают видеть приложения, с которыми они работают пока не наладится связь.
Принцип действия - на сервере есть специальный сервис - XTE, который продолжает взаимодействие с сессией пользователя на сервере. Таким образом сервер не считает, что пользователь отключился.
Этот функционал особенно полезен для мобильных пользователей, использующих беспроводные подключения.
С функцией Session Reliability, сессия пользователя остается активной на сервере. Для индикации того что связь разорвана, экран пользователя замирает, а курсор принимает вид песочных часов до тех пор, пока связь не восстановится. Переподключение к сеcсии производится без запроса учетных данных.
Пользователи Citrix Receiver не могут повлиять на настройки, сделанные на сервере.

Примечание: доступно использование Session Reliability с Secure Sockets Layer (SSL).

По умолчанию Session Reliability включена с помощью политик на сервере. Вы можете изменить эту политику нужным образом. Можно задать сетевой порт, который прослушивается сервером XenApp для реализации Session Reliability и задать время, в течение которого сохраняется сессия пользователя на сервере.
Можно задать три параметра политики (Citrix Computer → ICA → Session reliability):
- Параметр политики Session reliability connections включает или отключает этот функционал.
- Параметр Session reliability port number - задает номер порта. на котром будет прослушивать сервис XTE
- Параметр Session reliability timeout по-умолчанию составляет 180 секунд. Он задает, сколько времени сессия может висеть на сервере, при переподключении пользователя. В течение этого времени не потребуется вводить учетные данные. Слишком большой интервал создает потенциальную угрозу безопасности - если пользователь покинет клиентское устройство, то неавторизованный пользователь может получить доступ к сессии.
Для входящего трафик сервис Session reliability по-умолчанию использует порт 2598, если данная настройка не была изменена с помощью политик.
Если требуется включить повторную аутентификацию при разрывах связи, то следует включить функцию Auto Client Reconnect с помощью политики Citrix Computer.
Если включены обе политики - Session Reliability и Auto Client Reconnect, то они сработают последовательно - политика Session Reliability закроет или отключит сессию пользователя по истечении заданного времени. После этого в силу вступает политика Auto Client Reconnect, которая будет пытаться переподключить пользователя к отключенной сессии.

Как работает ICA Session Reliability и Common Gateway Protocol (CGP)

http://support.citrix.com/article/CTX104147
Клиент Citrix XenApp, сконфигурированный с Session Reliability устанавливает подключения на порт 2598, а не на 1494. При этом ранние версии клиентов (версии до 7.х) даже при использовании Session Reliability подключались на порт 1494.

Порт 2598 прослушивается для переподключения сброшенных подключений. При включенной Session Reliability клиент ICA тунеллирует трафик протокола ICA в протокол Common Gateway Protocol, который как раз и работает на порту 2598. Сервис XTE работает как транслятор, извлекая трафик ICA из пакетов протокла Common Gateway Protocol затем перенаправляя его на порт 1494.
Аналогично и сервер XenApp посылает трафик ICA к клиенту через сервис XTE. Таким образом, при разрыве соединения, сервер XenApp продолжает слать трафик сервису XTE, который буферизует до момента переподключения клиента. Сессия пользователя на сервер XenApp остается в активном состоянии до тех пор, пока сервис XTE буферизует трафик от сервера XenApp.

Ошибка - An error occurred when processing incoming CGP

http://support.citrix.com/article/CTX114680

В логе ошибок приложения появляетс запись - “An error occurred when processing incoming CGP downstream data.” (Event ID 103)
Сообщение возникает когда на сервере нет сессий.
Кроме того, в логе сервися XTE также есть ошибки:

[Fri Jul 20 15:51:14 2007] [notice] Server built: Jan 24 2007 23:31:11
[Fri Jul 20 15:51:14 2007] [notice] Parent: Created child process 4500
[Fri Jul 20 15:50:57 2007] [notice] Child 4500: Child process is running
[Fri Jul 20 15:50:57 2007] [notice] async engine initialized successfully,
8 worker threads started
[Fri Jul 20 15:50:57 2007] [notice] Child 4500: Acquired the start mutex.
[Fri Jul 20 15:50:57 2007] [notice] Child 4500: Starting 150 worker
threads.
[Fri Jul 20 15:53:46 2007] [error] (70014)End of file found: An error
occurred when processing incoming CGP downstream data
[Fri Jul 20 15:53:46 2007] [error] (70014)End of file found: S 0x7AAA08:
ap_get_brigade failed
[Fri Jul 20 15:58:38 2007] [error] (70014)End of file found: An error
occurred when processing incoming CGP downstream data
[Fri Jul 20 15:58:38 2007] [error] (70014)End of file found: S 0x7A9FE8:

Причиной такого поведения может быть сканирование портов. При сканировании сервис XTE получает неопознанные данные и фиксирует ошибку.
Для исключения такого в будущем следует отключить подробное журналирование XTE.
Для этого в файле C:\Program Files\Citrix\XTE\conf\httpd.conf с помощью WordPad следует добавить строки:

    # Log Level
    loglevel emerg
    Following is an excerpt of the file after adding the required content:
    #CGP Listen Port
    Listen 2598

    # Log Level
    loglevel emerg

Затем сохранить файл и закрыть редактор. Перезапустите сервис XTE для вступления изменений в силу.

Во избежание этого следует установить на файл атрибут Read-only и перезагрузить сервер.

Практический случай: SSL Relay и Session Reliability

http://support.citrix.com/article/CTX128705

Проблема:
Для шифрования XML-трафика Web-интерфейса и трафика ICA между сервером и клиентом используется SSL Relay. У заказчика есть вопрос по работе Session Reliability через SSL Relay.
Заказчика беспокоило то, что в конфигурации SSL Relay заданы только порты XML (8080) и ICA (1494), а сервис Session Reliability работает на порту 2598, который не прописан в конфигурации SSL Relay. Заказчик хочет знать - работает ли в этой конфигурации Session Reliability ?

Решение:
Для выяснения, работает ли в данной конфигурации Session Reliability собрана тестовая среда.
Затем сконфигурирован транспорт трафика XML к SSL Relay, а в свойствах приложения включена опция SSL/TLS.

В конфигурацию SSL Relay добавлены порты 8080 для трафика XML и 1494 для трафика ICA. Для фермы включена Session Reliability и выполнено внутреннее подключение с windows 7 клиентом версии 12.1.
В Citrix Connection Centre видно, что к приложению созданы два подключенния - одно зашифрованное SSL/TSL, а второе - нет. В свойствах этих подключений отображен используемый уровень шифрования - 128-bit SSL/TSL для зашифрованного и Basic для незашифрованного.
при запуске TCP view на сервере XenApp видно, что XTE.exe имеет только по одному подключению на порт 2598 для незашифрованного соединения и на порт 443 для зашифрованного SSL. То есть каждая сессия использует только одно соединение только к одному порту.
Если отключить оба клиента - XTE.exe будет слушать два порта - 443 и 2598.

Т.к. в TCP view не видно, чтобы прослушивался порт 1494 - сразу убираем его из конфигурации SSL/Relay.
Также убираем и порт 2598, т.к. при SSL-подключении, подключения на 2598 идут через порт 443.

Проверяем - клиент успешно подключается и в свойствах подключения Session Reliability: Enabled, то есть работает!

В конфигурации SSL Relay остается только порт для XML трафика - 8080.

Для работы Session Reliability через SSL Relay прописывать порт 2598 не требуется!^

Citrix License Server

Citrix License Server может быть установлен на любом сервере фермы.
Для установки - подключитесь к серверу фермы с учетными данными администратора. Из папки дистрибутива запустите autorun.exe и установите компонент Citrix License Server.
Компоненты срвера лицензирования устанавливаются в папку C:\Program Files\Citrix\Licensing на системе 32-bit и в папку C:\Program Files (x86)\Citrix\Licensing на 64-битной системе.

Порты, на которых по-умолчанию работают сервисы Citrix License Server:

License server - 27000
Vendor daemon - 7279
Web-консоль - 8082

После установки порты можно настроить как нужно Через Web-консоль.
Задайте пароль для пользователя admin.
В Web-консоли Citrix License Server порты задаются в разделах Server Configuration и Vendor Daemon Configuration.

Обзор сервисов системных XenApp и учетных записей, под которыми работают эти сервисы

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-services-overview.html

Ниже приведены сведения о названии сервиса в оснастках Windows, имени исполняемого файла, зависимости от других сервисов.
Не приведены сервисы Citrix License Server.

- Citrix 64-bit Virtual Memory Optimization , имя файла - ctxsfosvc64.exe, запуск - Local System/ Manual, описание - Динамическая оптимизация 64-битных приложений на сервере XenApp. Зависимостей нет.

- Citrix Client Network (CdmService), имя файла - cdmsvc.exe, запуск - Local System/ Manual, описание - перенаправляет диски и устройства клиента для доступа в сессии. Зависимости - Client Drive Mapping (CDM), Windows Management Instrumentation Driver Extensions, Workstation

- Citrix CPU Utilization Mgmt/CPU Rebalancer (CTXCPUBal), имя файла - ctxcpubal.exe, запуск - .\ctx_cpuuser/Manual, описание - Улучшает распределение ресурсов на многоядерных CPU. Зависимостей нет.

- Citrix CPU Utilization Mgmt/Resource Mgmt (ctxcpuSched), имя файла - ctxcpusched.exe, запуск - Local System/ Manual, описание - Распределяет ресурсы в соответствии с заданными политиками. Зависимости - Remote Procedure Call (RPC)
- Citrix Diagnostic Facility COM Server (CdfSvc), имя файла - CdfSvc.exe, запуск - NT AUTHORITY\ Network Service/Automatic, описание - Управляет диагностическими сессиями, которые позволяют обнаружить проблемы на сервере XenApp. Зависимости - Remote Procedure Call (RPC)

- Citrix Encryption Service , имя файла - encsvc.exe, запуск - NT AUTHORITY\ Network Service/Automatic, описание - Реализует безопасное взаимодействие с 128-бит RC5 шифрованием между Citrix Receiver и XenApp. Зависимости - Windows Management Instrumentation Driver Extensions.

- Citrix End User Experience Monitoring (Citrix EUEM), имя файла - SemsService.exe, запуск - Local System/ Manual, описание - Собирает и сопоставляет сведения о использовании системы конечными пользователями. Зависимости - Citrix SMC Support Driver.

- Citrix Health Monitoring and Recovery (CitrixHealthMon), имя файла - HCAService.exe, запуск - NT AUTHORITY\ Local Service/ Automatic, описание - Обеспечивает мониторинг состояния и восстановление в случае проблем. Зависимости - Citrix Independent Management Architecture service

- Citrix Independent Management Architecture (IMAService), имя файла - maSrv.exe, запуск - NT AUTHORITY\ NetworkService/ Automatic, описание - Обеспечивает управление фермой XenApp. Зависимости - Citrix Services Manager service, IPsec Policy Agent, Remote Procedure Call (RPC), TCP/IP Protocol Driver, Server, Windows Management Instrumentation Driver Extensions, Workstation.

- Citrix MFCOM Service (MFCom), имя файла - mfcom.exe, запуск - NT AUTHORITY\ NetworkService/ Automatic, Описание - Обеспечивает сервис COM, который реализует функции удаленного управления. Зависимости - Remote Procedure Call (RPC), Citrix Independent Management Architecture service, Citrix Services Manager service.

- Citrix Print Manager Service (cpsvc), имя файла - CpSvc.exe, запуск - Local Service/Automatic, Описание - Управляет созданием принтеров и перенаправлением дисков в сессиях XenApp. Поддерживает функицю Citrix Universal Printing.Зависимости - Print Spooler, Remote Procedure Call (RPC).

- Citrix Secure Gateway Proxy (CtxSecGwy), имя файла - CtxSGSvc.exe, запуск - NT AUTHORITY\ Network Service/ Automatic. Описание - Proxy для сервера Citrix Secure Gateway. Зависимостей нет.

- Citrix Services Manager (IMAAdvanceSrv), имя файла - IMAAdvanceSrv.exe, запуск - Local System /Automatic, Описание - Предоставляет XenApp интерфейс к операционной системе. Другие сервисы используют этот для elevated operations. Зависимостей нет.

- Citrix Streaming Service (RadeSvc), имя файла - RadeSvc.exe, запуск - .\Ctx_StreamingSvc /Automatic, Описание - Управляет плагином Citrix Offline, при стриминге (streaming) приложений. Зависимости - Remote Procedure Call (RPC).

- Citrix Virtual Memory Optimization, имя файла - CTXSFOSvc.exe, запуск - Local System /Manual, Описание - Динамически оптимизирует приложения, исполняемые на сервере XenApp, высвобождая оперативную память. Зависимостей нет.

- Citrix WMI Service (CitrixWMIservice), имя файла - ctxwmisvc.exe, запуск - NT AUTHORITY\ Local Service/Manual, Описание - Предоставляет классы Citrix WMI для мониторинга и управления. Зависимости - Citrix Independent Management Architecture service , Citrix Services Manager service, IPsec Policy Agent, Remote Procedure Call (RPC), TCP/IP Protocol Driver, Server, Windows Management Instrumentation Driver Extensions, Workstation

- Citrix XenApp Commands Remoting Service, имя файла - Citrix.XenApp.Commands.Remoting.Service.exe, запуск - Local System /Automatic, Описание - Предоставляет удаленную поддержку XenApp Commands. Зависимостей нет.

- Citrix XML Service (CtxHttp), имя файла - ctxxmlss.exe, запуск - Network Service /Automatic, Описание - Обслуживает XML-запросы данных от компонентов XenApp. Зависимостей нет.

- Citrix XTE Server (CitrixXTEServer), имя файла - XTE.exe, запуск - NT AUTHORITY\ NetworkService /Manual, Описание - Обслуживает сетевые запросы session reliability и SSL от компонентов XenApp. Зависимостей нет.

Права учетных записей служб XenApp:

Local Service Ограниченые Права - (NT AUTHORITY\LocalService)
Network Service Ограниченые Права, сетевой доступ - (NT AUTHORITY\NetworkService)
Local System Права АДминистратора - (NT AUTHORITY\System)
Ctx_StreamingSvc Права пользователя (User) локального/доменного.
Ctx_ConfigMgr Права опытного пользователя (Power User) локального/доменного.
Ctx_CpuUser Права пользователя (User) локального/доменного.

Привилегии учетных записей служб:

Ctx_ConfigMgr - Log on as a batch job, Log on as a service.
Ctx_CpuUser - Log on as a batch job, Log on as a service, Debug programs, Increase scheduling priority.

Если политика организации требует, чтобы учетные записи сервисов были доменные, а не локальные - следует создать учетки Ctx_ConfigMgr и Ctx_CpuUser перед установкой XenApp и назначить им указанные права.
Citrix не поддерживает изменение учетной записи для Citrix Streaming Service (Ctx_StreamingSvc), которая имеет следующие привилегии: log on as a batch job, log on as a service, backup files and directories, restore files and directories, deny log on locally, deny remote log on, and take ownership of files or other objects

1.4 - Для чего конфигурировать Worker Groups

http://support.citrix.com/article/CTX124481

Worker Group - это просто способ объединения серверов в ферме, с целью дальнейшего управления ими как единым целым.
Термин Worker обозначает серверы, сконфигурированные в режиме session-only. Довольно часто ферма XenApp содержит группы серверов, сконфигурированных идентично для выполнения одинаковых приложений.
Worker Group упрощает создание таких групп, обеспечивая синхронизацию опубликованных приложений и настроек для группы серверов.
В предыдущих версиях XenApp серверы объединялись в зоны и папки (zones and server folders). Эти контейнеры сохранились в XenApp 6 и были дополнены worker groups.

Worker groups похожи на зоны и папки, но преследуют несколько иные цели.
Зоны используются в XenApp для управления и объединения данных в ферме. Ферма XenApp делится на зоны в соотвествии с топологией сети. Каждая зона выбирает сборщика данных (data collector), который собирает динамичеки изменяемые данные с серверов зоны и реплицирует эти данные в другие зоны. Однако, Citrix рекомендует создавать зоны для больших площадок, соединенных высокоскоростными каналами. Маленькие площадки следует объединять в зоны для предотвращения большого количества трафика, генерируемого при репликации.
В последних версиях зоны используются для управления распределением нагрузки с помощью функций Zone Preference и Failover, хотя в версии XenApp 6 эту задачу выполняют политики. Политики делают ненужным объединение серверов в зоны для балансировки нагрузки. Теперь для балансировки нагрузки используются Worker groups, а зоны используются для репликации между сборщиками данных.

Папки серверов (Server folders) используются для двух целей - создают древовидную иерархию в консоли управления и позволяют делегировать административные права. Как и папки, worker groups позволяют произвольно группировать серверы, однако worker groups гораздо более гибкие.

Вот преимущества, предоставляемые worker groups:
- В отличиет от папок, каждый сервер может принадлежать нескольким worker groups. Соотвественно серверы могут быть одновременно объединены как по географическому признаку, так и в соотвествии с исполняемыми приложениям.
- Worker groups гораздо более мелкие, чем зоны (которых не рекомендуется иметь больше чем 5). Worker group модет состоять даже из одного сервера.
- Worker groups гораздо более динамичны. Например, при дод\бавлении в Worker group контейнера AD, изменения, вносимые в контейнере AD автоматически отображаются в конфигурации Worker group.

Описание архитектуры Web-интерфейса на примере с "двойным пробросом"

http://support.citrix.com/proddocs/topic/xenapp65-sec/ps-sec-sample-c-sg-double-hop-xa6.html

Решение использует Secure Gateway обеспечивает шифрование SSL/TLS HTTPS-соединений между Secure Gateway сервером и SSL-плагином, между Secure Gateway и Web-браузером, и между Secure Gateway и Web-интерфейсом (так называемая double-hop configuration). Внутри локальной сети ICA трафик защищен с помощью IPSec.

Ниже приведены компоненты и операционные системы, на которых работают компоненты.
Ферма XenApp
Компоненты - XenApp 6.5 for Microsoft Windows Server 2008 R2, работает SSL Relay, на XenApp установлен Secure Ticket Authority.
ОС - Windows Server 2008 R2

Web server
Компоненты - Web Interface 5.4 for Internet Information Services
ОС - Windows Server 2008 R2, Windows Server 2008, Windows Server 2003 with Service Pack 2, .NET Framework 3.5 or 2.0 (IIS 6.0 only), Visual J#.NET 2.0 Second Edition

Secure Gateway Service, Secure Gateway Proxy
Компоненты - Secure Gateway 3.3 for Windows
ОС - Windows Server 2008 R2, Windows Server 2008, Windows Server 2003 with Service Pack 2

Пользовательские устройства
Компоненты - Citrix Receiver for Windows 3.0, TLS-enabled Web browser
ОС - Windows 7, Windows Vista, Windows XP Professional

Как взаимодействуют компоненты?

Для создания безопасного соединения между клиентским устройством и Secure Gateway применяется TLS. Для этого необходимо установить плагины SSL/TLS и сконфгурировать Secure Gateway по периметру сети - как правило в DMZ.
В данном случае, DMZ разделена на две секции дополнительным файерволом. Сервер, на котором работает сервис Secure Gateway, располагается в первой секции DMZ. Web-интерфейс и Secure Gateway Proxy расположены во второй секции. Трафик между Secure Gateway Proxy и фермой XenApp защищен с помощью IPSec.

В этом варианте инсталлиции Secure Gateway позволяет не публиковать адрес каждого сервера фермы и обеспечивает единую точку доступа и шифрования. Secure Gateway представляет собой шлюз, который отделен от серверов фермы и позволяет не транслировать порты для трафика ICA через файервол.

Информационная безопасность в данном приемере

IPSec

Для того чтобы защитить соединение между Secure Gateway Proxy и фермой XenApp с помощью IPSec необходимо сконфигурировать IPSec на каждом сервере фермы, включая Secure Gateway Proxy.
IPSec конфигурируется путем изменения настроек локальной безопасности (Политики IPSec) на всех серверах. В приведенном примере IPSec включен на серверах с Secure Gateway Proxy, Web-интерфейсом и всех серверах фермы XenApp с параметрами шифрования Triple DES encryption и SHA-1 для соотвествия FIPS 140.

Соответствие FIPS 140

В данном примере SSL Relay использует службы криптопровайдера Microsoft (cryptographic service providers - CSPs) и алгоритмы Microsoft Windows CryptoAPI для шифрования соединения между клиентскими устройствами и серверами.
Поддержка SSL/TLS и средства шифрования настраиваются опцией операционной системы “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing”.

Поддержка SSL/TLS

Secure Gateway и Web-интерфейс можно сконфигурировать с поддержкой либо с поддержкой Transport Layer Security 1.0, либо Secure Sockets Layer 3.0. В данном примере используется TLS.

Поддерживаемые алгоритмы шифрования (ciphersuites)

В данном примере Secure Gateway, Secure Gateway Proxy и Web-интерфейс необзходимо сконфигурировать с применением надежного алгоритма RSA_WITH_3DES_EDE_CBC_SHA.
Для TLS-соединений можно выбрать и другие алгоритмы, использующие обмен ключами RSA и стандарт шифрования AES.
Продукты Citrix испольуют для проверок инфраструктуру публичных ключей (PKI). В данном примере на серверах Secure Gateway, Secure Gateway Proxy, и Web-интерфейса, а также на всех серверах фермы должны быть сформированы сертификаты. На всех клиентских устройствах должны быть установлены корневые сертификаты.

Поддержка смарт-карт (Smart Card)

В даном примере аутентификация с помощью смарт-карт не поддерживается. При использовании Secure Gateway между клиентским устройством и Web-интерфейсом смарт-карты использованы быть не могут.

Необходимые плагины

В данном примере пользователи получают доступ к своим приложениям с помощью Citrix Receiver. Его плагины описаны тут - http://support.citrix.com/proddocs/topic/xenapp65-sec/ps-sec-xa-plugins-xa6.html.

Пример с Single-Hop DMZ

В случае использования одной секции DMZ пользователи могут подключиться к системе двумя способами. Первый - это когда Secure Gateway перехватывает клиентское подключение, производит аутентификацию пользователя и направляет его к Web-интерфейсу. Второй - когда пользователь подключается к Web-интерфейсу и аутентифицируется на нем, а затем Secure Gateway защищает подключение. Первый вариант компоненты работают - последовательно, а второй - параллельно.

Необходимые сертификаты

Если Secure Gateway находится в DMZ, то серверам и клиентам потребуются слудующие сертификаты.

- Корневые сертификаты на всех клиентстких устройствах, подключаемых через Secure Gateway.
- Корневце сертификаты на всех компонентах Secure Gateway, которые подключаются к защищенному серверу. Например, корневой сертификат должен присутствовать на сервере на котором работает Secure Gateway для проверки сертификата сервера, на котором работает сервер Secure Ticket Authority (STA).
- Сертификат сервера на сервере с Secure Gateway.
- Опционально - сертификаты сервера на серверах STA. STA устанавливается по-умолчанию, при установке XenApp.

Все компоненты Secure Gateway поддерживают сертификаты. Citrix рекомендует, чтобы все каналы связи между Secure Gateway и другими серверами в DMZ были зашифрованы.

Пример использования Secure Gateway в одной секции DMZ

На рисунке приведена схема сети предприятия, отделенная от интернета одной секцией DMZ. Предприятие имеет ферму XenApp с одним сервером, на котором работает Secure Ticket Authority (STA). На файерволе, отделяющем безопасную сеть от DMZ открыты порты 80 (HTTP), 443(HTTPS) и 1494(ICA) и при включенной Session Reliability - порт 2598.
В DMZ находится единственный сервер, на котором работает Secure Gateway и Web-интерфейс. Трафик к Web-интерфейсу проксируется через Secure Gateway, который взаимодействует с Web-интерфейсом по HTTP.

DMZ отделена от интернета файерволом, на котором открыт порт 443.
Клиенты используют ноутбуки с 32-битной Windows, Internet Explorer и Citrix online plug-in.

Специалист по безопасности рекомендовал зашифровать соединение между Secure Gateway и Secure Ticket Authority (STA).
Для этого компания приобрела два сертификата для серверов у коммерческого центра сертификации (certificate authority - CA). На сервере с Secure Gateway и Web-интерфейсом установлен корневой сертификат. Сервер с XenApp имеет свой сертификат.

Последовательное взаимодействие Secure Gateway и Web-интерфейса

В варианте с одной секцией DMZ весь траффик перехватывается Secure Gateway. Web-интерфейс можно установить как на одном сервере с Secure Gateway так и на отдельном. Весь обмен данными между пользовтаельскими устройствами и Web-интерйесом транслируется через Secure Gateway.
На внешнем интерфейсе файрвола открыт порт 443. Пользователи подключаются к Secure Gateway при помощи URL вида: https://Secure Gateway FQDN/.

Преимущества этого варинта:
Для двух серверов - Secure Gateway и Web-интерфейса нужен один сертификат.
На файерволе открыт единственный порт - 443.
Из интернета нет прямого доступа к Web-интерфейсу, что повышает безопасность.
Недостатки:
Работа в таком режиме ограничивает функциональность Web-интерфейса. Во-первых не работает аутентификация с помощью смарт-карт, интегрированная в web-интерфейс. Во-вторых - невозможно определить IP-адрес конкретного пользователя. Все подключения к web-интерфейсу будут исходить от IP-адреса Secure Gateway.

Citrix рекомендует устанавливать Secure Gatewayв такой конфигурации в небольших сетях и сетях среднего размера до нескольких сотен пользователей.

Если перечисленные недостатки критичны или имеется большое число пользователей, подключающихся из локальной сети то следует использовать вариант параллельной работы Web-интерфейса и Secure Gateway.

ВНИМАНИЕ! Во-избежание недоразумений, на сервере с Secure Gateway следует отключить IIS.

Раздел 2 - Установка и лицензирование

2.1 - Установка XenApp с помощью Wizard-Based Server Role Manager

Что вообще нужно для установки XenApp с помощью менеджера ролей.

http://support.citrix.com/proddocs/topic/xenapp65-install/ps-install-wizard.html

Single Sign-on

http://support.citrix.com/proddocs/topic/technologies/pm-library-wrapper.html

Citrix Single Sign-on (бывший Citrix Password Manager) предоставляет сервис единого входа по паролю в Windows, Web-интерфейс и приложения, работающие в окружении Citrix. Пользователь аутентифицируется единожды и затем Single Sign-on обеспечивает автоматический доступ к защищенным системам и приложениям, применяет политики паролей, следит за всеми событиями, связанными с паролями, а также автоматизирует пользовательские задачи, в том числе смену паролей.

Single Sign-on состоит из следующих компонентов:

- Центральное хранилище (central store)
- Компонент Single Sign-on в Citrix AppCenter
- Single Sign-on Plug-in
- Служба Single Sign-on Service (опционально)

Центральное хранилище

Центральное хранилище Single Sign-on обеспечивает хранение и управление пользовательскими (пароли, скретные вопросы) административными (политики паролей, определения приложений, секретные вопросы и пр.) данными. КОгда пользователь входит в систему, Single Sign-on сравнивает введенные учетные данные с хранимыми в центральном хранилище. По мере того, как пользователь запрашивает доступ к защищенным приложениям или web-страницам, из центрального хранилища извлекаются необходимые учетные данные.

Компонент Single Sign-on в Citrix AppCenter

Компонент Single Sign-on в Citrix AppCenter это средство управления Single Sign-on. Тут задаются параметры работы Single Sign-on, включенные функции, меры безопасности и другие важные свойства парольной защиты. Средства управления Single Sign-on состоят из четырех основных элементов, доступ к которым осуществляется из левой панели AppCenter:

User Configurations - тут настраиваются параметры пользователей, основанные на их географическом положении или деловых ролях.
Application Definitions - тут настраиваются параметры, необходимые для работы плагина Single Sign-on Plug-in, который предоставояет приложениям учетные данные пользователя и определяет условия, при которых возникают ошибки. Для облегчения процесса настройки Single Sign-on предусмотрены как предустановленные, так и настраиваемые шаблоны приложений. Дополнительные шаблоны можно найти на сайте http://www.citrix.com/passwordmanager/gettingstarted.
Password Policies - здесь задаются параметры допустимой длины и сложности паролей в соответствии с полотикий информационной безопасности организации. Также политики паролей позволяют запретить повторное использование паролей или исключить из набора символов отдельные символы.
Identity Verification - тут задаются - секретные вопросы, которые позволяют пользователю самостоятельно и безопасно восстановить пароль в случае его утраты.

Плагин Single Sign-on

Плагин Single Sign-on предоставляет запускаемым приложениям соответствующие учетные данные, применяет политики безопасности, обеспечивает функции самообслуживания для пользователей и позволяет изменять учетные данные пользователя. Дополнительные функции плагина Single Sign-on настраиваются в конфигурации пользователя.

Служба Single Sign-on

Служба Single Sign-on работает на web-сервере, который обеспечивает работу дополнительных функций. Службу Single Sign-on следует устанавливать если планируется использовать одну из этих функций:

- Самообслуживание пользователей. Дает пользователям возможность самостоятельно изменять и сбрасывать пароль от учетных записей Windows
- Целостность данных (Data Integrity) - защищает данные от перехвата на пути от центрального хранилища к плагину Single Sign-on
- Управление ключами - дает пользователям возможность восстанавливать вспомогательные учетные сведения при изменении основного пароля
- Функции управления, которые позволяют использовать компонент Single Sign-on в Citrix AppCenter для добавления, удаления или обновления учетных данных пользователя
- Синхронизация учетных данных в домене с помощью Web-интерфейса

Если вы не планируете использовать вышеприведенные функции - устанавливать службу Single Sign-on не нужно.

Развертывание Single Sign-on

Типы Central Store

Для работы Single Sign-on необходимо хранилище (central store), для хранения и предоставления информации о пользователях и окружении. Создать central store можно автоматически, на этапе установки Single Sign-on или вручную, с помощью утилит Single Sign-on. Центральное хранилище (central store) Single Sign-on содержит следующую информацию:

- Данные о пользователе, включая вспомогательные учетные данные, секретные вопросы и ответы и другие данные, а также данные реестра пользователя Windows, связанные с Single Sign-on.
- Административные данные, включая определения приложений, политики паролей, секретные вопросы и другие настройки, сделанные в консоли Single Sign-on.

Центральное хранилище Single Sign-on взаимодействует с плагином, работающем на пользовательском устройстве и фермой Citrix XenApp и предоставляет учетные данные приложениям, к которым пользователь имеет доступ.
Плагин имеет собственное локальное хранилище на компьютере пользователя, которое хранит только вспомогательные настройки, информацию для восстановления ключей и секретные вопросы и ответы. Эти сведения синхронизируются с центральным хранилищем, для того чтобы пользователь всегда имел доступ к сохраненным сведениям.
Центральное хранилище Single Sign-on может быть двух типов:
- Active Directory - информация необходимая для работы Single Sign-on хранится в Active Directory.
- Сетевая папка NTFS

При необходимости можно мигрировать с одного типа хранилища на другой.

Active Directory Central Store

Использование Active Directory Central Store позволяет удобно настраивать политики использования Single Sign-on. Например, их можно применять как на уровне домена, так и на уровне OU или отдельного пользователя.

При использовании Active Directory Central Store в схему будут добавлены два новых класса :
citrix-SSOConfig - Класс описывает объект, содержащий данные для плагина - настройки ПО, состояние синхронизации, определения приложений. Этот класс содержит аттрибуты citrix-SSOConfigData - содержащий актуальные данные и citrix-SSOConfigType - указывает тип данных.

citrix-SSOSecret - Класс описывает объект, используемый для аутентификации пользователя Single Sign-on. Класс содержит аттрибут citrix-SSOSecretData - который хранит зашифрованные учетные данные для приложения и данные для самостоятельно восстановления пароля.

Active Directory Central Store следует выбирать если:
- Есть возможность безболезненно расширить схему Active Directory
- Вы хотите использовать преимущества высокой доступности Active Directory

Преимущества Active Directory в качестве Central Store Single Sign-on втом что, AD отказоустойчива (контроллеры доменов резервируются) и масштабируема, благодаря репликации.

Рашаренная папка NTFS в качестве Single Sign-on Central Store

Использование папка NTFS в качестве Single Sign-on Central Store позволяет использовать существующую инфраструктуру Active Directory, но не вносить изменения в схему AD.

ВАЖНО: для Single Sign-on Central Store следует создавать скрытую (hidden) расшаренную папку

Single Sign-on создает папку CITRIXSYNC$ с двумя вложенными папками - People и CentralStoreRoot.

Папка People содержит вложенные папки для каждого пользователя с соответствующими разрешениями на запись для конкретного пользователя.
Папка CentralStoreRoot содержит административную информацию.

Преимущества сетевой папки NTFS в качестве Single Sign-on Central Store:

- Не требуется расширять схему AD, при этом функциональность такая же как и при использовании Active Directory central store
^ ПРИМЕЧАНИЕ: Объединение пользовательских конфигураций в группы возможно только в доменах, использующих аутентификацию Active Directory.^
- Данные о пользователях всегда актуальны, потому что не используется репликация и поэтому отсутствует задержка при обновлении данных Active Directory.
- Для повышения надежности можно организовать распределение нагрузки (load balance) между несколькими NTFS network share.
- Снижается нагрузка на подсистему Active Directory.
- Single Sign-on позволяет миграцию central store из NTFS shared folder в Active Directory.

При использовании сетевой папки NTFS в качестве central store следует учесть:
- Следует осуществлять резервное копирование файлов central store (в том числе и разрешения)
- Если топология сети предполагает наличие каналов WAN между сегментами, то следует использовать DFS - Distributed File System.

Использвание Account Association и нескольких Central Stores на предприятии с несколькими доменами

Если на предприятии используется несколько доменов, то администратор может создать несколько central store для каждого домена. Тип используемого central store может быть разным - то есть один домен может иметь central store в сетевой папке, а второй в Active Directory.

Т.к. в компаниях с несколькими доменами пользователь может иметь в каждом домене отдельную учетную запись, Single Sign-on имеет функцию Account Association, которая позволяет пользователю подключаться к приложению с помощью любой учетной записи.
Т.к. Single Sign-on обычно привязывает учетные данные к одной учетной записи windows, учетные данные автоматически не синхронизируются, но администратор может настроить синхронизацию учетных данных с помощью модуля Credential Synchronization Module и пользователи получат доступ ко всем своим приложениям с помощью единственной учетной записи. Если изменить учетные данные пользователя в одной учетной записи, то они автоматически синхронизируются и в других.

Без Account Association пользователи с несколькими учетными записями Windows вынуждены использовать правильные учетные данные для каждой учетки.
Для того, чтобы дать пользователям разрешение использовать Account Association, нужно предоставить доступ к файлу AccAssoc.exe как к опубликованному приложению.

Определение приложений (Application Definition)

Функции определения приложений (Application Definition) позволяют плагину Single Sign-on распознавать и автоматически заполнять формы авторизации, генерируемые приложениями.
Application Definition содержат набор полей, которые необходимо заполнить для авторизации. Мастер создания Application Definition поможет создать правильный набор параметров - он автоматически определяет формы и поля, которые необходимо заполнить в большинстве приложений.

Поддерживаются следующие типы приложений:
- 32-bit Windows (в том числе и Java-приложения), например Microsoft Outlook, Lotus Notes, SAP и любые другие приложения, запрашивающие пароль.
- Web-приложения , работающие через Microsoft Internet Explorer(в том числе и Java-апплеты и SAP).
- Приложения, доступ к которым осуществляется с помощью HLLAPI-совместимого эмулятора терминала.(Single Sign-on не поддерживает эмуляторы терминала 64-bit)

Смарт-карты

Компанией Citrix протестированы смарт-карты, удовлетворяющие стандарту ISO 7816 и считываемые с помощью кард-ридера.
Поддерживаются PC/SC-based криптографичесике карты, поддерживающие операции цифровой подписи и шифрование. Смарт-карты предназначены для безопасного хранения секретных ключей, используемых в PKI-инфраструктуре.
Эти карты выполняют операции шифрования внутри себя так, что секретные приватные ключи никогда не покидают карту. Кроме того, поддерживается двухфакторная аутентификация, которая повышает безопасность - сама карта и пин-код. Таким образом подтверждается, что тот, у кого сейчас карта является полноправным владельцем карты.

Требования к ПО

Дополнительную информацию о необходимом ПО следует уточнять у производителя смарт-карты. На сервере и киленте потребуются следующие компоненты:

- программное обеспечение PC/SC
- криптопровайдер (CSP)
- драйверы считывающего устройства для смарт-карт

Вероятно сервер и клиенты под управлением Windows уже имеют необходимое ПО - PC/SC, CSP и драйверы.
Для правильной работы смарт-карт в конфигурации пользователей следует включить Microsoft Data Protection API (requires roaming profiles).

SmartAuditor - запись сессий пользователей

http://support.citrix.com/proddocs/topic/xenapp65-w2k8/ps-sa-library-wrapper-v2.html

SmartAuditor позволяет записывать активность на экране пользователя во время сессии, независимо от того откуда подключился пользователь к ферме XenApp. SmartAuditor записывает, каталогизирует, хранит и воспроизводит записанные данные.

SmartAuditor использует гибкие политики, для включения записи сессии автоматически. Это позволяет наблюдать за анализировать активность пользователя при доступе к критичным приложениям - например, финансовым или для здравоохранения. Кроме того, SmartAuditor помогает решать технические проблемы, возникающие при работе приложений в среде XenApp.
SmartAuditor фиксирует изменения на экране, движения мышью и нажатия на кнопки клавиатуры.

Преимущества:

- Аудит активности пользователей для соответствия законодательству в критичных сферах (например - финансы и здравоохранение).
- Защита компаний от нежелательной криминальной активности и сбор соответствующих доказательств.
- Быстрое разрешение возникающих проблем с приложениями.

Системные требования для SmartAuditor

SmartAuditor доступен на языках English, French, German, Japanese, Spanish, and simplified Chinese. Все компоненты SmartAuditor должны быть одной языковой редакции. Смешение компонентов с разными языками не поддерживается.

Англоязычная редакция SmartAuditor поддерживается на операционных системах следующих языковых редакций - English, Russian, traditional Chinese, and Korean. SmartAuditor версий French, German, Japanese, Spanish, and simplified Chinese поддерживается на ОС соответствуцющих языковых редакций.

АДминистративные компоненты SmartAuditor

АДминистративные компоненты SmartAuditor - SmartAuditor Database, SmartAuditor Server и SmartAuditor Policy Console могут устанавливаться как на одном сервере, так и на разных серверах.
SmartAuditor Database
Поддерживаемые ОС:
Microsoft Windows Server 2008 R2 with Service Pack 1
Microsoft Windows Server 2008 R2
Microsoft Windows Server 2003 with Service Pack 2
Microsoft Windows 2000 with Service Pack 4
Требования:
Microsoft SQL Server 2008 R2 (Enterprise and Express editions), Microsoft SQL Server 2008 (Enterprise and Express editions), or Microsoft SQL Server 2005 (Enterprise and Express editions) with Service Pack 2
.NET Framework Version 3.5 Service Pack 1 or .NET Framework Version 4

SmartAuditor Server
Поддерживаемые ОС:
Microsoft Windows Server 2008 R2 with Service Pack 1
Microsoft Windows Server 2008 R2
Требования:
.NET Framework Version 3.5.
If the SmartAuditor Server uses HTTPS as its communications protocol, SSL. SmartAuditor uses HTTPS by default, which Citrix recommends.
Microsoft Message Queuing (MSMQ), with Active Directory integration disabled, and MSMQ HTTP support enabled.

SmartAuditor Policy Console
Поддерживаемые ОС:
Microsoft Windows Server 2008 R2 with Service Pack 1
Microsoft Windows Server 2008 R2
Microsoft Windows 7
Microsoft Windows Vista
Требования:
Перед установкой SmartAuditor Policy Console следует вручную установить консоль управления Microsoft IIS.
Microsoft IIS Management Console

SmartAuditor Agent
Установите SmartAuditor Agent на всех серверах XenApp, на которых вы хотите записывать сессии
Требования:
XenApp 6.5 for Windows Server 2008 R2 Platinum edition or XenApp 6 for Windows Server 2008 R2 Platinum edition server software
Microsoft Windows Server 2008 R2 with Service Pack 1 or Microsoft Windows Server 2008 R2
.NET Framework Version 3.5 Service Pack 1 or .NET Framework Version 4
Microsoft Message Queuing (MSMQ), with Active Directory integration disabled, and MSMQ HTTP support enabled

SmartAuditor Player
Поддерживаемые ОС:
Microsoft Windows XP
Microsoft Windows Vista
Windows 7
SmartAuditor Player требует .NET Framework Version 3.5 Service Pack 1 or .NET Framework Version 4.

Для использования SmartAuditor Player на сервере XenApp следует установить обновление, описанное в базе знаний Microsoft Knowledge Base article 961118.

Для нормальной работы SmartAuditor Player необходимо:
Экран с разрешением не менее 1024 x 768
Цвет - 32-bit
Память - минимум 1GB RAM. Большее количество памяти увеличит производительность при воспроизведении больших файлов.

Схема SmartAuditor

SmartAuditor состоит из пяти компонент:
SmartAuditor Agent. Компонент позволяющий записывать сессии. Его устанавливают на все серверах XenApp.
SmartAuditor Server. На этом сервере работают два приложения:
Брокер (Broker). Это Web-приложение, работающее в IIS 6.0 и старше. Оно обрабатывает запросы поиска и позволяет скачивать файлы. для SmartAuditor Player, обрабатывает административные запросы от SmartAuditor Policy Console и применяет политики разрешения записи для всех сессий пользоватетелей.
Storage Manager. Служба Windows, которая управляет файлами с записанными сессиями, поступающими от других серверов XenApp с SmartAuditor.
SmartAuditor Player. Пользовательский интерфейс, позволяющий просматривать записанные сессии.

Планирование установки SmartAuditor

В зависимости от требований и окружения, SmartAuditor может быть выбран один из нескольких сценариев.

Инсталляция SmartAuditor не ограничивается одной фермой. Все компоненты, за исключением SmartAuditor Agent, независят от фермы. То есть можно сконфигурировать несколько ферм и один SmartAuditor Server.

И наоборот - если работает большая ферма, где много агентов и планируется записывать много сессий графических приложений, то (AutoCAD), или просто большое число сессий, от сервера SmartAuditor может потребоваться высокая производительность. Для нормальной работы в данном случае можно установить несколько серверов SmartAuditor на разных компьютерах и направить агентов SmartAuditor на разные сервера. В каждый момент времени один агент может работать только с одним сервером.

Установка сертификатов

На системе с сервером SmartAuditor работает IIS, который при установке SSL-соединения посылает свой сертификат сервера клиенту - SmartAuditor Agent, SmartAuditor Player или SmartAuditor Policy Console. При получении сертификата сервера клиент определяет центр сертификации, выдавший рертификат и проверяет, что разрешено доверять этому центру сертификации. Если центр сертификации не доверен, то сертификат отклоняется и в системном журнале приложений фиксируется ошибка.
При установке сертификата сервера собрается инфоормация о сервере, затем он отсылается в центр сертификации и тот выпускает сертификат для данного сервера. При запросе сертификата следует удостовериться, что указано правильное имя сервера. Если для подключения клиентов (SmartAuditor Agent, SmartAuditor Player и Policy Console) используется имя FQDN, то при запросе сертификата следует указывать именно это FQDN-имя, а не NetBIOS-имя. Если при выдаче сертификата указано NetBIOS-имя, то при запросе сертификата не следует использовать FQDN-имя. Установите сертификат сервера в локальное хранилище сертификатов. Также установите сертификат доверенного центра сертификации в клиентские хранилища сертификатов.

Организация может иметь собственный центр сертификации, который выпускает сертификаты для серверов. В этом случае убедитесь что каждое клиентское устройство имеет сертификат этого центра сертификации. За дополнительной информацией обращайтесь в документацию Microsoft, посвященную использованию сертификатов и центров сертификации.

Все сертификаты имеют срок действия. Убедитесь, что сроки не истекли.

SmartAuditor по-умолчанию сконфигурирован для использования HTTPS и требует наличия у Web-сервера своего сертификата. См. документацию IIS.

Требования SmartAuditor к серверу, сети и базе данных.

Сервер:
- Двухъядерный CPU рекомендуется
- Процессор с поддержкой 64-bitрекомендуется, хотя работать будет и на x86
- Рекомендуется от 2GB до 4GB
Превышение этих спецификаций не сильно повысит производительность.

Производительность сети.
Для работы SmartAuditor достаточно сети 100 Мбит. Использование гигабитной сети увеличит производительность, но не намного.

Несколько серверов.
Можно использовать одновременно несколько серверов SmartAuditor. В этом случае каждый сервер будет иметь свое собственное хранилище, сетевые интерфейсы и базу данных. Для распределения нагрузки следует прописать соотсетсвующие серверы в конфигурации SmartAuditor Agents.

Масштабируемость базы данных.
База данных на базе Microsoft SQL Server 2005 или Microsoft SQL Server 2008 предназначена для хранения метаданных SmartAuditor. Каждая сессия занимает порядка 1KB места в базе данных. Таким образом, ограничение размера базы в 4Gb Express-версий Microsoft SQL позволит сохранить порядка 4 миллионов сессий.

Важные замечания по установке SmartAuditor

- Все компоненты SmartAuditor должны быть установлены на компьютеры, входящие в один домен, либо в доверенные домены с транзитивными доверительными отношениями. SmartAuditor не модет быть установлен в рабочих группах или в недоверенных доменах.
- Кластеризация SmartAuditor Servers не поддерживается.
- Из-за высокой графической нагрузки при воспроизведении сессий, не рекомендуется устанавливать SmartAuditor Player как опубликованное прилождение на ферме XenApp.
- SmartAuditor использует SSL/HTTPS, поэтому следует убедиться, что на компонентах SmartAuditor установлены корневой сертификат и сертификат сервера SmartAuditor Server.
- При размещении базы данных SmartAuditor на отдельном SQL Server 2005 Express Edition или SQL Server 2008 Express Edition следует убедиться что включен протокол TCP/IP и включен SQL Server Browser. Эти настройки по-умолчанию отключены.
- Следите за настройками Session sharing, которые могут конфликтовать с политиками записи SmartAuditor.
- SmartAuditor сопоставляет активную политику с первым запущенным пользователем приложением. После запуска первого приложения, все последующие запускаемые будут следовать уже примененной политике. Например, политика утверждает, что записывать нужно только Microsoft Outlook и действительно при запуске Microsoft Outlook сессия записывается. При этом, если после запуска Microsoft Outlook запустить Microsoft Word, то он тоже будет записан. Напротив, если в политике указано, что Word не нужно записывать, то если первым запустить Word, а потом Outlook (для которого запись разрешена), то сессия Outlook не запишется.

Установка SmartAuditor

Для установки используйте Autorun

Кмопненты SmartAuditor это - SmartAuditor Database, SmartAuditor Server и the SmartAuditor Policy Console. Выберите, что конкретно из них устанавливать на каждый сервер.

В меню Autorun выберите: Manually install components > Server Components > Miscellaneous > SmartAuditor > SmartAuditor Administration.
Следуйте указаниям мастера.
На странице конфигурирования базы данных:
- Если устанавливаете административные компоненты на том же сервере, то выберите localhost в качестве параметра Accessing user account for computer or localhost .
- Если SmartAuditor Server и SmartAuditor Database устанавливаются на разных серверах, то введите имя компьютера, на котором работает SmartAuditor Server в таком виде: domain\machine-name$. Убедитесь, что символ ($) есть после имени.
Следуйте указаниям мастера для завершения установки.

Установка SmartAuditor Agent
SmartAuditor Agent должен быть установлен на севрерах XenApp.

В меню Autorun выберите: Manually install components > Server Components > Miscellaneous > SmartAuditor > SmartAuditor Agent.
На странице конфигурирования SmartAuditor Agent введите имя компьютера, на котором установлен SmartAuditor Server.
Следуйте указаниям мастера для завершения установки.

Установка SmartAuditor Player
SmartAuditor Player устанавливается на рабочей станции пользователя, который будет просматривать записанные сессии.

В меню Autorun выберите: Manually install components > Server Components > Miscellaneous > SmartAuditor > SmartAuditor Player.
Следуйте указаниям мастера для завершения установки.

2.2 - Определение того, какую роль должен играть сервер

Планирование сборщиков данных (Data Collectors)

http://support.citrix.com/proddocs/topic/xenapp65-planning/ps-planning-data-collectors-planning-v2.html
При планировании сборщиков данных (data collector) решите:

- Нужен ли вам выделенный сборщик (data collector)?
- Если не нужен выделенный, то какие компоненты инфраструктуры должны работать вместе со сборщиком на одном сервере?
- Нужны ли вам зоны на каждой площадке вашей фермы XenApp? В каждой зоне должен быть хотя бы один сборщик.

Для поддержания связанной работы зон фермы, сборщики данных используют информацию сборщиков из других зон, что создает некоторый трафик в сети.
Потребление памяти сборщиком незначительно растет по мере роста фермы. Например, служба Independent Management Architecture (IMA) в ферме из 1000 серверов потребляет порядка 300 мегабайт памяти.
Потребление ресурсов процессора также не велико. Сборщик работающий на двухъядерном процессоре может обслужать зону из 1000 серверов. Потребление растет по мере увеличения числа серверов, зон и приложений.
В большинстве случаев Citrix рекомендует иметь как можно меньше зон и сборщиков. Например, в случае размещения 1000 серверов на одной площадке рекомендуется настраивать одну зону и один выделенный сборщик (хотя можно иметь и резервные).

Настройка зон для XenApp

http://support.citrix.com/proddocs/topic/xenapp65-planning/ps-planning-zones-wans-v2.html

Зона - это группа серверов. В любой ферме есть хотя бы одна зона. Все серверы фермы должны принадлежать какой-то зоне. По-умолчанию, при установке XenApp все серверы принадлежат одной зоне с именем Default Zone.
Создание зон преследует две цели:
- Собирать данные от серверов зоны в иерархическую структуру
- Эффективно распространять изменения конфигурации на все серверы фермы

В каждой зоне есть сервер, который определен как сборщик данных (data collector). Сборщики данных хранят информацию о серверах зоны и опубликованных приложениях. В фермах, где больше одной зоны, сборщики выполняют роль шлюзов между зонами.

На рисунке приведен пример фермы с двумя зонами. Сборщики данных взаимодействуют по каналу WAN.

Так как в крупной ферме объем информации о сессиях и нагрузке может быть довольно значительным (несколько мегабайт) для эффективного масштабирования фермы важно, чтобы структура зон соответствовала топологии сети.
Серверы фермы XenApp реплицируют свои динамически обновляемые данные на коллектор зоны. XenApp использует топологию “звезда” для репликации в пределах зоны - каждый сборщик данных реплицирует динамические данные зоны всем другим сборщикам данных в ферме. Таким образом, важно, чтобы при планировании зон, между сборщиками данных предполагались каналы связи с соответствующей пропускной способностью.

При планировании зон наиболее критичными значениями являются пропускная способность канала связи и его задержка. Чем ниже пропускная способность канала связи между зонами и выше задержка, тем больше времени требуется зоне для синхронизации.

В географически распределенных фермах формирование зон, соединенных каналами WAN, повышает производительность. Citrix не рекомендует иметь больше одной зоны в ферме, если серверы не распределены по нескольким удаленным площадкам.

Сборщики данных генерируют большое количество сетевого трафика, т.к. постоянно обмениваются данными друг с другом:
- Каждый сборщик данных зоны постоянно поддерживает подключения ко всем другим сборщикам фермы.
- При обновлении зоны, рядовые сервера обновляют данные на сборщике при каждом запросе и изменении конфигурации.
- Сборщики данных передают изменения другим сборщикам, следовательно, сборщики данных имеют сведения обо всех сессиях во сех зонах.

Выделять зоны требуется не всегда, даже если площадки, на которых размещены серверы фермы расположены на разных континентах. Наиболее критичным фактором для взаимодействия серверов внутри зоны является задержка в каналах связи.
Также следует определить нужны ли зоны для обработки отказов (failover) или зоны предпочтения (preference). То есть можно указать к какой зоне будут перенаправлены пользователи в случае отказа, также жестко указать к какой зоне следует подключаться каждому пользователю. Требования к обработке отказов могут определять необходимое число зон.

Например, в организации есть 20 серверов на площадке в Лондоне, 50 серверов в Нью-Йорке и три сервера в Сиднее. В этом случае следует создать две или три зоны. Если площадка в Сиднее имеет хороший канал связи с Нью-Йорком или Лондоном, то рекомендуется объединить серверы в Сиднее с наиболее крупной зоной - в даном случае с Нью-Йорком. Однако, если качество канала связи не высоко, а также требуется обеспечить обработку отказов и предпочтения зон, то Citrix рекомендует сконфигурировать три зоны.

При планировании конфигурации зон учитывайте:
- Всегда по возможности следует минимизировать число зон.
- Создавайте зоны в крупных центрах обработки данных в разных регионах.
- Если на площадке установлено небольшое число серверов - присоедините их к зоне на другой площадке с большим числом серверов.
- Если у организации есть филиалы с плохими каналами связи, то не следует там создавать отдельные зоны, а следует присоединять серверы этих площадок к зонам на более крупных площадках, с связь с которыми наилучшая. При таком варианте возможна конфигурация зоны типа hub-and-spoke(так называемая “осевая”).
- Если есть больше пяти площадок, то следует объединять наиболее мелкие с крупными. Citrix не рекомендует иметь в ферме более 5 зон.

2.3 - Лицензирование XenApp. Где и как получить файл с лицензией?

http://support.citrix.com/proddocs/topic/licensing-119/lic-install-license-files.html#lic-install-license-files
После установки компонентов лицензирования необходимо получить файлы лицензий от Citrix. На сайте http://citrix.com необходимо сгенерировать файл лицензий, скачать его и поместить на сервер лицензий, а затем импортировать с помощью консоли администрирования лицензий (License Administration Console).
Перед тем как обращаться на сайт Citrix за лицензией следует удостовериться что у вас имеется следующее:
1. Код лицензии. Этот код можно найти на носителе, с которого устанавливается XenApp, в электронном письме от citrix или от автоматической системы подписки и обновления (Subscription Advantage Management-Renewal-Information system (SAMRI)).
2. Ваш идентификатор пользователя и пароль с сайта MyCitrix. Для того чтобы получить эти сведения следует зарегистрироваться на сайте MyCitrix.
3. Имя сервера, на который установлены компоненты лицензирования. Поле для ввода этого имени чувствительно к регистру. Введите имя точно также как оно задано на сервере. Это имя можно узнать, выполнив в командной строке команду hostname.
4. Следует знать, сколько лицензий вы хотите включить в файл лицензий. Учтите, что получить сразу все запрошенные лицензии не получится. Например, если вы запросили 100 лицензий, то сразу сможете скачать файл только на 50 лицензий, и затем через некоторое время еще на 50. Допустимо иметь несколько файлов лицензий.

Для получения лицензий с помощью консоли администрирования лицензий (License Administration Console):
1. Запустите консоль (Start > All Programs > Citrix > Management Consoles > License Administration Console).
2. Кликните Administration and Vendor Daemon Configuration.
3. Кликните Import License.
4. Кликните по ссылке My Citrix.
5. На странице My Citrix введите ваш ID и пароль.
6. Выберите пункт Select Manage Licenses в меню Choose a Toolbox.
7. В меню Manage Licenses выберите Allocate.
8. Выделите лицензии и сгенерируйте файл.
9. Скачайте необходимый лицензии и сохраните файл в папку:
C:\Program Files\Citrix\Licensing\MyFiles на системе 32-bit
C:\Program Files (x86)\Citrix\Licensing\MyFiles на системе 64-bit

10. В консоли администрирования лицензий на странице Import License File укажите файл лицензий.
11. Если вы скопировали файл непосредственно в папку MyFiles или файл имеет такое же имя, как и существующий, выберите Overwrite License File on License Server.
12. Кликните Import License.
13. Кликните Vendor Daemon Configuration и затем Administer на строке вендора Citrix.
14. Кликните Reread License Files для того, чтобы сервер лицензий прочитал новый файл.

После этого пользователи могут начать использовать добавленные лицензии.

Для того чтлбы вручную получить файл лицензий:

1. Зайдите на сайт http://www.citrix.com.
2. Кликните Log In и введите имя пароль.
3. Из выпадающего меню выберите License Management.
4. В меню Manage Licenses выберите Allocate.
5. Сгенерируйте файл лицензий.
6. Скачайте необходимый лицензии и сохраните файл в папку:
C:\Program Files\Citrix\Licensing\MyFiles на системе 32-bit
C:\Program Files (x86)\Citrix\Licensing\MyFiles на системе 64-bit

Совет: Убедитесь, что файл лицензий имеет расширение “.lic”. В некоторых случаях файл получает расширение “.txt”. Файлы лицензий с неправильным расширением не импортируются.

7. В командной строке перейдите в папку:
C:\Program Files\Citrix\Licensing\LS на системе 32-bit
C:\Program Files (x86)\Citrix\Licensing\LS на системе 64-bit

И выполните команду: lmreread -c @localhost

Раздел 3. Конфигурирование сессий пользователей XenApp

3.1 - Конфигурирование технологий HDX/Speedscreen, MediaStream Flash Redirection

http://support.citrix.com/proddocs/topic/xenapp65-admin/hd-flash-wrapper-ad.html

HDX MediaStream Flash Redirection позволяет обрабатывать контент формата Adobe Flash в браузере клиентского устройства (как windows, так и linux), а не в экземпляре браузера на сервере. Передача контента возможна для широкого круга приложений, в том числе анимации и видео. Перенаправление ресурсоемкого контента для исполнения на клиентском устройстве позволяет снизить нагрузку на сервер и таким образом улучшить масштабируемость XenApp, и повысить качество выводимой пользователю картинки.

Примечание: для использования Flash Redirection требуется один из двух типов Adobe Flash Player. Первый - Adobe as Flash Player для Windows Internet Explorer (иногда называемый ActiveX player). ВТорой - Adobe Flash Player для других браузеров, иногда называемый NPAPI (Netscape Plugin Application Programming Interface) Flash Player.

Второе поколение Flash Redirection

Flash Redirection используется с:

Citrix XenApp 6.5
Citrix XenDesktop 5.5
Citrix Receiver 3.0

Второе поколение Flash Redirection включает функции:

- поддержка пользователей подключенных по каналам WAN
- Flash Redirection второго поколения и более ранних версия работают в разных виртуальных каналах
- функция Intelligent Fallback, которая позволяет определять, эффективно ли работает устройство пользователя и, при необходимости, осуществлять обработку контента на сервере
- Список Flash URL Compatibility List заменил Flash URL Blacklist. Рендеринг указанных URL и на клиентском устройстве и на сервере может быть заблокирован.

Системные требования для Flash Redirection

Нижеприведенные сведения актуальны на момент публикации, а дополнительную информацию можно найти по адресу: https://www.citrix.com/support/product-lifecycle/product-matrix

Для пользовательских устройств требуется:
- Для работы второго поколения Flash Redirection требуются Citrix Receiver for Linux 12.0 или Receiver for Windows 3.0 (ранее назывался online plug-in). Online plug-in 12.1 поддерживает работу только функций старой версии Flash Redirection.
- Включенное и работающее сетевое подключение. Для работы XenDesktop Virtual Desktop Agents установите сетевое соединение между пользовательским устройством Windows и агентом.
- На пользовательских устройствах должен быть установлен Adobe Flash Player for Windows - Other Browsers. Версия Flash Player на пользовательском устройстве должна быть такой же или выше, чем версия Flash Player for Windows Internet Explorer, установленная на сервере Citrix XenApp 6.5 или Citrix XenDesktop 5.5.
^ Примечание: если на килентском устройстве установлена старая версия Flash Player или Flash Player сообще не может быть установлен на устройстве, то Flash-контент будет обрабатываться (рендериться) на сервере.^

Системные требования для серверов Citrix XenApp 6.5 или Citrix XenDesktop 5.5:

- Flash Player 10.1 или выше для Windows Internet Explorer на серверах XenApp и XenDesktop's Virtual Desktop Agents.
- Internet Explorer 9, Internet Explorer 8 или Internet Explorer 7.

Второе поколение Flash Redirection on XenDesktop 5.5 поддерживает Internet Explorer 9.

Для того, чтобы включить поддержку Internet Explorer 9 на серверах XenApp 6.5 нужно отредактировать реестр сервера XenApp.

Предупреждение: Перед правкой реестра следует сделать его резервную копию. Неправильные изменения в реестре могут привести операционную систему в нерабочее состояние.

На операционной системе 32-bit:
В ветке HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\HdxMediaStreamForFlash\Server\PseudoServer
Добавьте параметр типа DWORD с именем IEBrowserMaximumMajorVersion и значением 00000009.

На операционной системе 64-bit:
В ветке HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\HdxMediaStreamForFlash\Server\PseudoServer
Добавьте параметр типа DWORD с именем IEBrowserMaximumMajorVersion и значением 00000009.

Предупреждение: Flash Redirection требует постоянного взаимодействия между пользовательским устройством и сервером. Это создает возможность атаки клиентских устройств специально сформированным flash-контентом или flash-плеером. Используйте Flash Redirection только с доверенными серверами.

Конфигурирование HDX MediaStream Flash Redirection на сервере

http://support.citrix.com/proddocs/topic/xenapp65-admin/hd-flash-configure-server-ad.html
Настройки HDX MediaStream Flash Redirection на стороне сервера конфигурируются с помощью политик в инструментах Citrix Desktop Studio или Citrix AppCenter. Управлять функциями Flash Redirection можно с помощью следующих политик (Citrix User Policy):

Flash backwards compatibility - Обратная совместимость Flash
Flash default behavior - Поведение по-умолчанию
Flash intelligent fallback - Интеллектуальное “отступление” - обработка некоторого flash-контента на сервере
Flash latency threshold - Порог задержки
Flash server-side content fetching URL list - Список сайтов, контент с которых скачивается на сервер и потом передается клиенту для обработки.
Flash URL compatibility list - Список совместимых URL
Flash event logging - Журналирование событий
Flash acceleration - Ускорение обработки Flash. Будет или не будет использована оптимизация Flash.
Flash background color list - Список фоновых оттенков

Включение обратной совместимости - '''Flash backwards compatibility'''

Второе поколение Flash Redirection может быть настроено для совместимости с пользовательскими устройствами с ранними версиями online plug-in (теперь - Citrix Receiver). Эти устройства смогут использовать только старые функции Flash Redirection. Это обеспечивается созданием двух отдельных виртуальных каналов - по одному для новой и старой версий Flash Redirection. Соответственно, набор работоспособных функций определяется самой старой версией ПО на сервере и на клиенте.
На пользовательском устройстве должны быть включена опция Enable HDX MediaStream Flash Redirection.

Чтобы использовать обратную совместимость:
На сервере с Desktop Studio или AppCenter, в политике Citrix User Policy включите Flash backwards compatibility.
На пользовательском устройстве включите Enable HDX MediaStream for Flash , выбрав опцию Всегда (Always) или С подтверждением (Ask).

Примечание: Обратная совместимость недоступна, если выбрана опция Only with Second Generation .

Настройка поведения по-умолчанию функций ускорения flash - '''Flash acceleration'''

Параметр политики Citrix User Policy - Flash Default Behavior позволяет задать поведение по-умолчанию функций ускорения Flash. Эта настройка может быть перекрыта настройками для конкретной Web-страницы или элемента Flash, заданных в Flash URL Compatibility List.
Доступны три опции:

Block Flash player - Пользовтаель не может просматривать Flash-контент. Перенаправление Flash-контента не используется.
Disable Flash acceleration - Пользотваель может просматривать Flash-контент, обрабатываемый на сервере. Перенаправление Flash-контента не используется.
Enable Flash acceleration - Используется Flash Redirection. Второе поколение Flash Redirection доступно при соблюдении соответвующих требований. Режим совместимости со старыми версиями доступен, если включен.

По умолчанию ускорение flash-контента (Enable Flash acceleration) включено. Если никакая другая опция не задана - используется эта.

Настройка "умного отступления" - '''Flash intelligent fallback'''

Используйте этот параметр, если не хотите, чтобы все flash-элементы контента перенаправлялись для обработки на пользовательское устройство. Обычно, небольшие ролики flash - это реклама. Функция Flash intelligent fallback выявляет эти элементы и обрабатывает (рендерит) их на сервере. Применение этого параметра политики Citrix User Policy не вызывает неполадок при загрузке страницы или работы Flash-приложений.

Эта настройка имеет два положения - Enabled или Disabled. По умолчанию она включена - Enabled.

Настройка Flash latency threshold

Настройка политики Flash latency threshold применима к Legacy mode, то есть доступна только при включенной политике Flash backwards compatibility.

В режиме Legacy, Flash Redirection измеряет время прохождения данных между сервером и пользовательским устройством. Эти данные учитывают как задержку сети, так и другие задержки данных. Если задержка находится в пределах допустимого заданного диапазона, то для рендеринга контента используется Flash Redirection и ендеринг происходит на пользовательском устройстве. Если задержка выше, заданной, то ренедеринг происходит на серверах.
По умолчанию порог задержки имеет значение 30 миллисекунд. Увеличение этого порога может приводить к ухудшению картинки у пользователя. Не рекомендуется увеличивать значение этого порога.

Список сайтов, контент с которых обрабатывается сервером

Параметр Flash server-side content fetching URL list - это список сайтов, с которых разрешено скачивать контент Flash для последующей передачи на пользовательское устройство. Эта функция применима, в случаях, когда у пользовательского устройства отсутствует прямой доступ к источнику flash-контента (отсутствует доступ в интернет, либо контент располагается на внутреннем сайте компании). Хотя в этот список могут входить хоть все сайты интернета, он предназначен для сайтов корпоративной сети и внутренних Flash-приложений.

Примечание: Server-side content fetching не поддерживает приложения, использующие Real Time Messaging Protocols (RTMP). Для таких приложений и сайтов применяется рендеринг на стороне сервера.

Эта настройка работает, если для клиента включена опция Enable server-side content fetching. Она включается в редакторе групповой политики.
http://www.jackcobben.nl/?p=2872
http://wiki.autosys.tk/XenApp.%d0%9f%d0%be%d0%b4%d0%b3%d0%be%d1%82%d0%be%d0%b2%d0%ba%d0%b0-%d0%ba-%d1%8d%d0%ba%d0%b7%d0%b0%d0%bc%d0%b5%d0%bd%d1%83-1Y0-A20-Citrix-XenApp-6-5.ashx#%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_HDX_MediaStream_Flash_Redirection_%D0%BD%D0%B0_%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D1%81%D0%BA%D0%BE%D0%BC_%D1%83%D1%81%D1%82%D1%80%D0%BE%D0%B9%D1%81%D1%82%D0%B2%D0%B5_124

Эта настройка листа, как правило используется, если клиентское устройство не имеет прямого соединения с интернетом и сервер XenApp или XenDesktop обеспечивает это соединение.
При конфигурировании Flash server-side content fetching URL list учитывайте следующее:

- Добавляйте URL самого приложения Flash, а не всей страницы.
- Используйте звездочку “*” в начале и в конце URL, в качестве маски для расширения списка.
- Звездочка в конце URL позволяет включить все страницы ресурса в список. Например - http://www.sitetoallow.com/*.
- Префиксы http: и https: используются, если указано. В общем случае они не требуются.

Сконфигурируйте список Flash server-side content fetching URL list , кликнув New, для добавления URL в список.

ВАЖНО: Для работы этого параметра для клиентского устройства нужно включить опцию Enable server-side content fetching.

Настройка того, где будет рендериться flash-контент

Второе поколение Flash Redirection позволяет указать, где будет рендериться контент с указанных сайтов:
- Rendered on the user device - Рендер на пользовательском устройстве
- Rendered on the server - Рендер на сервере
- Blocked from rendering - Рендер заблокирован

При настройке списка Flash URL compatibility list учитвайте:
- Наиболее важные URL должны располагаться вверху списка
- Используйте звездочку “*” в начале и в конце URL, в качестве маски для расширения списка.
- Звездочка в конце URL позволяет включить все страницы ресурса в список. Например - http://www.sitetoallow.com/*.
- Префиксы http: и https: используются, если указано. В общем случае они не требуются.
- Если ресурс не рендерится нормально на пользовательском устройстве, дл янего следует казать опцию Render on Server или Block.

Для того чтобы сконфигурировать список Flash URL compatibility list:
- Кликните New и откроется диалоговое окно Add Flash URL Compatibility list entry
- Выберите действие и (Render on Client, Render on Server, или Block)
- В поле URL Pattern введите URL сайта
- Выберите элемент Flash, к которому буде применена натройка - Any - ко всем, Specific - к выбранным (Flash player ID).

Включение журналирования серверных событий

Flash Redirection использует журнал Windows для записей событий Flash. Вы можете просмотреть журнал и определить, когда используется Flash Redirection и собрать дополнительную информацию о проблеме.
При записи событий Flash Redirection они все попадают в журнал Приложений (Application log), имеют значение поля источник - Flash и пустое поле категории.
Кроме того, на компьютерах под управлением Windows 7 и Windows Vista появляется отдельный журнал Flash Redirection в разделе журнала приложений и служб (Applications and Services Logs). В Windows XP события Flash Redirection попадают только в журнал приложений.

По умолчанию параметр Flash event logging - включен (Enabled).
Для Flash Redirection второго поколения, настройка недоступна.

Включение и отключениережима совместимости Flash Redirection ('''Legacy mode HDX MediaStream Flash Redirection''') на сервере

По-умолчанию, режим совместимости (Legacy mode Flash Redirection ) включен на сервере. Изменить эту настройку можно с настройки помощью политики Citrix User Policy - Flash acceleration, в категории Flash Redirection .

Сконфигурируйте параметр Flash acceleration , включив или отключив его. По умолчанию - он включен.

Если параметр включен - весь контент Flash, не заблокированный в Flash URL compatibility list , рендерится на пользовательском устройстве, в режиме совместимости (Legacy mode). Если отключен - весь контент Flash рендерится на сервере.

Включение сопоставления цвета в контенте Flash и на странице

С помощью настройки Flash background color list , политики Citrix User Policy , можно задать режим соотвествия цвета страницы и цвета фрна flash-контента. Это может улучшить восприятие страницы при просмотре с использованием Flash Redirection.

Кликните New и введите URL Web-сайта и 24-bit шестнадцатеричный номер цвета. Например: http://www.sitetomatch.com/ FF0000. Для наилучших результатов - используйте цвета, обычно не встречающиеся на странице, например - черный.

Используйте замыкающий символ “*” для заменемы цвета на всех страницах ресурса по маске - http://www.sitetomatch.com/* FF0000.

Настройка HDX MediaStream Flash Redirection на пользовательском устройстве

http://support.citrix.com/proddocs/topic/xenapp65-admin/hd-flash-enable-client-ad.html
Настройки, применяемые по-умолчанию на пользовательском устройстве, можно настроить с помощью редактора объектов групповой политики (Group Policy Object Editor).

Для настройки HDX MediaStream Flash Redirection на пользовательском устройстве:
- Создайте или выберите существующий объект групповой политики ActiveDirectory.
- Импортируйте и добавьте шаблон HDX MediaStream Flash Redirection - Client administrative template (HdxFlash-Client.adm), который лежит:
На 32-бит системах: %Program Files%\Citrix\ICA Client\Configuration\language.
На 64-бит системах: %Program Files (x86)%\Citrix\ICA Client\Configuration\language.

Для импорта - в редакторе групповой политики (gpedit.msc) выберите Административные шаблоны, затем в меню Действие выберите Добавление и удаление шаблонов, затем выберите шаблон. После этого в Административных шаблонах появится раздел Классические административные шаблоны (ADM).

Включение Flash Redirection на пользовательском устройстве

Настройте параметр Enable HDX MediaStream Flash Redirection on the user device для того чтобы задать, когда Flash Redirection включен на пользовательских Windows-устройствах. Если не задано никакой настройки, то Flash Redirection включена по-умолчанию, либо у пользователя будет запрошено включение.

- В редакторе групповой политики (Group Policy Object Editor), в разделе Computer Configuration или User Configuration кликните Administrative Templates и затем Classic Administrative Templates (ADM), а затем HDX MediaStream Flash Redirection - Client.
- В списке параметров выберите Enable HDX MediaStream Flash Redirection on the user device
Этот параметр может быть включен, выключен или не задан.
При выборе включен - можно выбрать один из вариантов:

Если выбран вариант “Всегда”, это устройство всегда будет разрешать визуализацию материалов Adobe Flash на стороне клиента. Если выбран вариант “Только версия 2”, это устройство будет разрешать визуализацию материалов Adobe Flash на стороне клиента только при использовании второй версии компонента. Если выбран вариант “Запрашивать”, пользователи получат запрос перед визуализацией на стороне клиента. Вариант “Никогда” активирует

Примечание: Выбор “Запрашивать” приведет к тому, что в каждой сессии пользователя при первом обращении к flash-содержимому, пользователь получит запрос. Если пользователь не включит Flash Redirection, контент будет рендериться на сервере.

Порядок вступления политик в силу:
Computer Configuration: политика вступит в силу после перезагрузки компьютера.
User Configuration: Пользователь должен завершить свою сессию (выйти) и залогиниться снова.

Использование синхронизации клиентских куки-файлов с серверными куки-файлами
Эта политика определяет, будут-ли синхронизированы HTTP куки-файлы на клиенте и сервере. После получения этих куки-файлов на клиенте, они могут быть использованы при запросе HTTP-контента клиентом. При синхронизации куки-файлы клиента не перезаписываются. Они будут доступны, если впоследствии синхронищация будет отключена.
Порядок вступления политик в силу:
Computer Configuration: политика вступит в силу после перезагрузки компьютера.
User Configuration: Пользователь должен завершить свою сессию (выйти) и залогиниться снова.

Извлечение контента на стороне сервера (server-side content fetching)
По-умолчанию, HDX MediaStream Flash Redirection скачивает и воспроизводит flash-контент на клиентском устройстве. И для этого на клиентском устройстве нужен доступ к интернету. Включение этой политики приведет к тому, что сервер будет скачивать flash-контент, а затем передавать его клиенту. И если не задано никаких других ограничеий, например блокировок через список разрешенных URL (Flash URL compatibility list), то контент будет воспроизведен на пользовательском устройстве.
Эта политика часто используется если:
- Пользовательское устройство не имеет прямого доступа в интернет.
- Пользовательское устройство полдключается к сайтам корпоративной сети через Citrix Access Gateway.
Механизм Server-side content fetching не поддерживает приложения Flash, использующие Real Time Messaging Protocols (RTMP). В этому случае необходимо использовать рендеринг на сервере.
Второе поколение Flash Redirection добавляет три новых опции - возможность кешировать контент на клиенте временно во время сеанса или выполнять постоянное кэширование, когда контент сохраняется и между сеансами, а также запрет кеширования. Кеширование повышает производительность, предотвращая повторное скачивание контента.
Кешированный этим механизмом контент хранится отдельно от другого HTTP контента.
Также добавлен механизм server-side content fetching fallback. Если включено получение контента сервером, то при ошибках получения контента клиентом, flash-контент будет запрошен сервером и передан клиенту.

ВАЖНО: Для работы механизма server-side content fetching должна быть включен и настроен список Flash server-side content fetching URL list

Перенаправление запросов клента на нужный сервер (URL rewriting rules for client-side content fetching)
Есть возможность перенаправить запрос клиента на нужный сервер при помощи механизма, изменяющего URL запроса. При конфигурировании этой опции, можно задать паттерны URL, с помощью регулятных выражений Perl. Если пользовательское устройство запрашивает контент, подходящий под паттерн, то запрос перенаправляется в соответствии с указанным паттерном.
Это полезно для компенсации задержек, возникающих при доставке контента с ближайшего сервера, входящего в сеть доставки контента (content delivery network - CDN). При использовании Flash Redirection, flash-контент будет запрошен пользовательским устройством, а вся остальная web-страница - запрошена сервером. Если используется CDN, то запрос сервера XenApp будет перенаправлен на ближайший HTTP-сервер и пользовательский запрос будет направлен туда же. Если клиент и сервер XenApp находятся в разных географических зонах, то между загрузкой web-страницы на сервер XenApp и загрузкой flash-контента на клиентское устройство может возникать серьезная задержка, т.к. весь контент загружается с HTTP-сервера, ближайшего к серверу XenApp. Чтобы избежать этого, следует переписать URL, запрашиваемый клиентом в соответствии с тем, какой HTTP-сервер к клиенту ближе всего.
Порядок вступления политик в силу:
Computer Configuration: политика вступит в силу после перезагрузки компьютера.
User Configuration: Пользователь должен завершить свою сессию (выйти) и залогиниться снова.

Повышение производительности и масштабируемости приложений 2D и 3D

http://support.citrix.com/proddocs/topic/xenapp65-admin/hd-hardware-acceleration.html

HDX 3D позволяет высоконагруженным графическим приложениям, работающим на XenApp, рендерить картинку на графическом ускорителе (GPU), установленном в сервере. Перемещение нагрузки, связанной с обработкой DirectX, Direct3D и Windows Presentation Foundation (WPF) на GPU позволяет разгрузить центральный процессор. Эти функции доступны только на адаптерах, поддерживающих display driver interface (DDI) версии 9ex, 10 или 11. DirectX и Direct3D не требуют специальной настройки.

HDX 3D поддерживает распределение нагрузки на GPU между несколькими пользователями. При использовании HDX 3D совместно с XenServer GPU Passthrough, в одном сервере могут быть несколько графических адаптеров, по одному на каждую виртуальную машину.

Для того чтобы включить обработку приложений WPF на GPU сервера, на сервере XenApp, в ключе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook\AppInit_Dlls\Multiple Monitor Hook создайте параметр типа REG_DWORD с именем EnableWPFHook, со значением 1.

Оптимизация "отзывчивости" клавиатуры и мыши

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-sessions-ss-latency-reduction-mgr-using-v2.html
Термин SpeedScreen Latency Reduction используется для обозначения функций, таких как Local Text Echo и Mouse Click Feedback, которые помогают сделать работу пользователя более комфортной при медленном сетевом соединении.

Mouse Click Feedback
При использовании каналов свЯзи с высокой задержкой, пользователи часто кликают мышкой несколько раз, т.к. не получают визуального подтверждения того, что клик был. Функция Mouse Click Feedback включена по-умолчанию. Она меняет указатель мыши на “песочные часы”, после клика пользователя, демонстрируя пользователю, что система обрабатывает его запрос. Когда пользователь кликает, клиент ICA сразу меняет вид указателя мыши. Функцию Mouse Click Feedback можно включить или выключить на сервере.

Local Text Echo
При использовании каналов связи с высокой задержкой, пользователи часто наблюдают серьезную задержку между тем как они ввели текст на клавиатуре и отображением его на экране. Это происходит потому что после нажатия клавиши, информация об этом попадает на сервер, затем сервер использует шрифты, генерирует новое изображение и посылает клиенту. Функция Local Text Echo временно использует локальные шрифты для быстрого отображения вводимого текста.
По-умолчанию функция Local Text Echo отключена. Включить её можно как на уровне сервера, так и на уровне приложения. Также можно сконфигурировать Local Text Echo для отдельных полей ввода в приложении.

Примечание: Приложения, которые не используют стандартный Windows API для отображения текста, могут не работать с Local Text Echo.

Настройка '''SpeedScreen Latency Reduction'''

Для настройки функций SpeedScreen Latency Reduction предусмотрена утилита SpeedScreen Latency Reduction Manager. С её помощью можно задать параметра как для целого сервера XenApp, так и для одного или нескольких приложений или отдельных полей ввода.

SpeedScreen Latency Reduction Manager должен быть установлен на сервере XenApp.

Для запуска SpeedScreen Latency Reduction Manager, кликните Пуск > Администрирование > Citrix > Administration Tools > SpeedScreen Latency Reduction Manager.

Примечание: Для запуска Speedscreen Latency Reduction Manager на сервере, где включен User Account Control (UAC), нужно иметь административные права. В противном случае - система запросит авторизоваться как администратор.

Настройка '''SpeedScreen Latency Reduction''' для отдельного приложения

Если опубликованое приложение демонстрирует ненормальное поведение после конфигурирования SpeedScreen Latency Reduction, для настройки параметров этого приложения можно использовать мастер Add New Application , входящий в состав SpeedScreen Latency Reduction Manager.

Примечание: перед использованием этого мастера, приложение должно быть запущено.

Прежде чем вы сможете настраивать параметры приложения в Speedscreen Latency Reduction Manager, его нужно туда добавить.

3. Обзор клиентских средств Citrix

Citrix Offline Plug-in

http://support.citrix.com/proddocs/topic/xenapp-application-streaming-edocs-v6-0/ps-stream-plugin-description-v3.html

Offline plug-in - это новое название Citrix Streaming Client. Плагин работает как служба на клиентском устройстве и запускает приложения, выбранные пользователем и приложения, перечисляемые online-плагином, Citrix Receiver или Web-интерфейсом.
Offline-плагин находит павильную цель в профиле в App Hub, создает изолированное окружение на устройстве пользователя и затем передает приложение из профиля в изолированное окружение на устройстве пользователя.
Плагин не требует никакой конфигурации при установке. Соответственно, пользователи, имеющие права администратора на своих компьютерах, могут установить плагин самостоятельно.
Плагин устанавливается по-умолчанию на сервере, при установке XenApp. Это позволяет сконфигурировать сервер для “стриминга на сервер” и двухрежимного стриминга.
Для аутентификации профилей, к которым осуществляют достп пользователи, плагин следует устанавливать с цифровым сертификатом. В результате - плагин будет стримить приложения только из профилей с правильным сертификатом.
Также плагин проверяет размер кеша пользовательского устройства. Если размер кеша превышает максимальный лимит, плагин удаляет файлы приложения из кеша. Размер кеша по-умолчанию составляет 1000Mb или 5% от размера диска (что больше). Удаление файлов начинается с наименее редко используемых.

Средства доставки утилит и приложений

Merchandising Server

http://support.citrix.com/proddocs/topic/technologies/receivers-merchandising-wrapper.html

Для доставки клиентских средств и приложений существует центр доставки - Citrix Delivery Center. В его состав входят Citrix Receiver for Windows, Receiver for Mac, и Merchandising Server.
Citrix Delivery Center - это инструмент доставки приложений, с которым работает администратор, а Citrix Merchandising Server и Citrix Receiver - это средства, используемые для установки приложений и управления ими на рабочих местах пользователей. Merchandising Server предоставляет административный интерфейс для конфигурирования, доставки и обновления плагинов на компьютерах пользователей.

Установка Merchandising Server

Merchandising Server поставояется в виде виртуального приложения (virtual appliance), который содержит все необходимое для работы. Это виртуальное приложение можно импортировать в Citrix XenCenter или VMware (VMware vSphere 4.0, VMware Server 2.x, or ESX 3.5 and later).

Скачать Merchandising Server можно с сайта Citrix, из раздела Citrix Receiver.

Для XenCenter имя виртуального приложения будет: citrix-merchandising-server-releaseNumber.bz2
Для vSphere имя виртуального приложения будет: citrix-merchandising-server-VMwarereleaseNumber.ova
При необходимости, распакуйте файл zip с помощью bz2, winzip, или другой утилиты.

Импортирование Virtual Appliance в XenCenter

Убедитесь, что на диске есть как минимум 20 GB свободного места.
Citrix рекомендует выделить как минимум 4 GB и 2 VCPUs.
Перед запуском следует сконфигурировать сетевые адаптеры, а после запуска - имя хоста. Убедитесь, что имя хоста (hostname) -это правильное FQDN имя. В противном случае, Receiver Updater не сможет присоединиться к Merchandising Server.

Конфигурирование Администраторов

В браузере откройте страницу Administrator Console по адресу: https://[[server_address]]/appliance, где server_address это адрес Merchandising Server.
Введите root в качестве имени пользователя и C1trix321 в качестве пароля и кликните Log on.
Выберите Configuration > Configure AD. Введите сведения для подключения к серверу Active Directory.
Кликните Save Changes and Sync для того, чтобы загрузить пользователей в базу данных Merchandising Server.
Выберите Configuration > Permissions. Введите свое имя или фамилию в поле Search и кликните Search.
Выберите свое имя в результатах поиска и кликните Edit.
Выберите Administrator permissions и кликните Save.
Повторите процедуру для каждого пользователя, которому нужны административные права.
Кликните Log out .

Конфигурирование '''Administrator Console'''

Войдите в Administrator Console под именем с административной учеткой.

Опционально, Кликните Configuration > SSL Certificate Management.
Выберите Export certificate signing request для создания запроса.
Введите размер ключа и информацию о компании, кликните Export, и отправьте это в центр сертификации.
При получении сертификата из выпадающего меню выберите Import certificate from certificate authority .
Кликните Browse , укажите место расположения файла сертификтата *.cer и кликните Submit.

Выберите Configuration > Options.
Введите информацию о поддержке для пользователей.
Введите имя домена Active Directory.
Укажите частоту опроса Citrix Update Service.
Укажите срок действия токенов пользователей.

Опционально, выберите Configuration > Network Settings.
Если используется proxy, введите его параметры.

Подготовка к работе

Перед созданием дотавки, скачайте плагины и создайте правила доставки.

Для того чтобы скачать плагины:
В Administrator Console, выберите Plug-ins > Get New.
Выберите плагин из списка и кликните Download to Server ил кликните Download All to Server.
Кликните Close в окне с соообщением об успешном скачивании.
Скачайте все поагины, которые необходимо доставлять.

Создание правил для получателей

В Administrator Console, выберите Deliveries > Rules.
Кликните Create в нижней части страницы.
Введите имя и описание - Name and Description.
Выберите тип правила из меню Field. Возможные значения - Machine Name, User Domain Membership, Computer Domain Membership, Operating System, LDAP User, and LDAP User Group, Machine Name, IP Address Range.
Если выбран LDAP User or LDAP User Groups, отобразится инструмент поиска по AD.
Если выбран User Domain Membership, Machine Domain Membership, Operating System, or IP Address Range, выберите тип сравнения (совпадаетили не совпадает) - Is или Is Not в поле Operator введите значение в поле Value.
Если выбран Machine Name, то можно задать либо точное значение, либо маску - выберите Begins With, Contains или Is Exactly и введите значение в поле Value.
Кликните Save для сохранения правила.

Создание "доставок"

для создания доставки:
В Administrator Console, выберите Deliveries > Create / Edit.
Кликните Create внизу страницы.
На вкладке General введите информацию о доставке.
На вкладке Plug-ins кликните Add и выберите плагины для доставки и кликните Add снова.
На вкладке Config введите специфичные для плагина значения.
На вкладке Rules задайте правила
На вкладке Schedule задайте расписание доставки.
Кликните Schedule для завершения.

Теперь Merchandising Server готов предоставить Citrix Receiver пользователям. Как только пользователь скачает Receiver, он автоматически выберет запланированную доставку и установит плагины.

3.5 smooth roaming

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-printing-proximity.html

Печать и мобильные сотрудники

В случае, когда мобильные сотрудники работают с разных площадок, может потребоваться, чтобы им был предоставлен ближайший к ним принтер. Примером могут являться сотрудники больниц, работающие в разных палатах и переподключающиеся к одной и той же сессии с разных рабочих станций или сотрудники в командировках.

Если в организации есть такие задачи, то полезными будут эти функции:
SmoothRoaming
Proximity Printing

SmoothRoaming

Также эта функция известна под именем Workspace control. Эта функция позволяет пользователям отсоединяться от сессии, и переподключаться с другого устройства к той же сессии. При переподключении сессии, принтеры, прописанные на первом устройстве, будут заменены на принтеры, прописанные на втором устройстве. В результате, пользователь всегда имеет нужные принтеры в сессии.
SmoothRoaming работает с локальными принтерами, подключенными к пользовательскому устройству.

Proximity Printing

Эта функция дает возможность управлять сетевыми принтерами также как и в случае SmoothRoaming. То есть клиенту будут передаваться в сессию сетевые принтеры, в соответствии с текущим IP-адресом клиентского устройства.
Proximity Printing включается с помощью политики Citrix - Default printer.

Proximity Printing модет помочь администрировать даже если нет мобильных сотрудников.
Пример - пользователь берет ноутбук и перемещается на другой этаж здания компании. С Proximity Printing автоматически определяется новый IP-адрес мобильного устройства и прописываются принтеры, соответствующие данному диапазону IP-адресов.
При этом, если сконфигурирована Proximity Printing, то надо поддерживаь политику Session printer . Например, если сетевые принтеры добавляются или удаляются, нужно обновлять эту политику. Аналогично, если меняются настройки выдачи адресов на сервере DHCP, то политику надо обновить.

Непрерывность сессии

http://support.citrix.com/proddocs/topic/xenapp6-w2k8-admin/ps-sessions-prov-usrs-ws-cont-v2.html
Функция Workspace Control предоставляет пользователям возможность быстро отключаться от всех запущенных приложений и переподключаться к ним или выполнять выход из всех запущенных приложений. Workspace Control позволяет пользователям перемещаться между клиентскими устройствами и предоставляет доступ к уже открытым приложениям при переподключении.

Для пользователей подключающихся через Web-интерфейс или online plug-in можно сконфигурировать следующие возможности:

Вход (Logging on). По-умолчанию, Workspace Control позволяет пользователям переподключаться ко всем запущенным приложениям при входе, не требуя повторного их запуска. С помощью Workspace Control пользователи могут открывать отключенные и активные приложения на другом клиентском устройстве.
Отключение от приложения оставляет его запущенным на сервере.
Переподключение (Reconnect). После входа на сервер пользователи могут переподключаться ко всем приложениям, кликнув Reconnect. По-умолчанию Reconnect открывает отключенные сессии приложений и все приложения в настоящий момент запущенные на другом клиентском устройстве. Можно сконфигурировать Reconnect так, чтобы открывались только отключенные приложения, а не активные в данный момент.
Выхо (Logging off). Для пользователей, открывающих приложения через Web-интерфейс, можно сконфигурировать команду Log Off , которая завершит сессию пользователя в Web-интерфейсе и все запущенные приложения или просто отключит пользоателя от Web-интерфейса.
Отключение (Disconnecting). Пользователи могут отключаться от всех запущенных приложений сразу одной командой.

По-умолчанию, Workspace Control включен и доступен только для пользователей Web-интерфейса и Citrix online plug-in.
При перемещении пользователя на новое клиентское устройство, будут применены соотвествующие политики (мапинг дисков, принтеров). То есть политики и мапинг применяются в соответствии с тем, на каком устройстве пользователь залогинен в данный момент.

Что такое session sharing и для чего его конфигурировать

Разделяемые сессии и соединения

http://support.citrix.com/proddocs/topic/xenapp6-w2k8-admin/ps-session-sharing2-v2.html
В зависимости от плагина, при открытии приложения оно может появиться в бесшовном (seamless), либо небесшовном (non-seamless). Эти режимы окон доступны для всех плагинов, включая Web-интерфейс и Citrix online plug-in.
В бесшовном (seamless) режиме опубликованное приложение не находится внутри окна сессии ICA. Каждое опубликованное приложение и десктоп появляются в собственном изменяемом окне, как буд-то приложение установлено на компьютере пользователя. И пользователь может переключаться между опубликованым приложением и локальным десктопом.
В небесшовном (non-seamless) режиме опубликованное приложение или десктоп располагается с окне сесии ICA. Это создает впечатление, что приложение как бы в двух окнах.

Выбираемый режим зависит от типа используемого клиентского устройства. Обычно десктопы публикуют в бесшовных окнах. Как правило десктопы публикуются для тонких клиентов, когда производительность клиентского устройства не позволяет запускать на нем ничего, кроме клиента ICA.
Когда пользователь запускает опубликованное приложение, плагин устанавливает соединение с фермой XenApp и инициирует сессию. Если разделение сессии (session sharing) не сконфигурировано, то при открытии каждого приложения на сервере открывается новая сессия. Аналогично - при открытии каждого нового приложения, создается новое клиентское подключение к ферме.

Разделение сессии (session sharing) - это режим, в котором в одном соединении работают несколько приложений. Разделение сессии воникает, пример, когда пользователь имеет уже открытую сессию и запускет еще одно приложение на том же сервере. В результате - два приложения работают в одной сессии. Для того чтобы происходило разделение сессии необходимо, чтобы оба прилодения были опубликованы на одном сервере. Поу-умолчанию, разделение сессии включается при конфигурировании приложения для запуска в бесшовном режиме. Если пользователь запускает несколько приложений в режиме разделения сессии, все приложения используют единственное подключение к серверу.
Если требуется разделять сессии, убедитесь, что все приложения опубликованы с одинаковыми настройками.

Примечание: Разделение сессий не поддерживается клиентами PocketPC.

Разделение сессий всегда имеет приоритет над балансировкой нагрузки. То есть, если пользователь запускает приложение в режиме разделения сесии на сервере, где уже работает его приложение, но сервер уже испытывает нехватку ресурсов, XenApp все равно откроет приложение на этом сервере. Менеджер нагрузки не передаст подключение на более свободный сервер.

Ограничения на соединение

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-sessions-est-conn-cont-v2.html
Для того, чтобы обеспечить доступность ресурсов фермы, вы можете ограничить число соединений к серверам и опубликованным приложениям.
Установка ограничений на подключений помогает предотвратить:
- Падение производительности и ошибки, в случае, если пользователь запускает больше одной копии приложения одновременно
- Отказ в обслуживании, вызванный атакой, во время которой запускается много копий приложения, потребляющих ресурсы и лицензии
- Черезмерное потребление ресурсов некритичными приложениями, например Web-браузингом

Ограничения подключений, в том числе и запрет входа, конфигурируются в разделе политик и свойств приложений.

Есть несколько типов ограничений:
- Ограничение количества одновременных подключений к ферме. Это раздел политик компьютера Server Settings > Connection Limits, политики Limit user sessions и Limits on administrator sessions, ограничивающие количество подключений от пользователей и администраторов. Локальные администраторы не попадают под эти ограничения.
- Ограничение количества одновременных подключений данного пользователя. Это раздел политик пользователя Sssion Limits, политика Concurrent Logon Limit
- Ограничение числа одновременно запущенных копий приложения. Ограничение задается в свойствах опубликованного приложения, на вкладке Limits

По-умолчанию XenApp подключения никак не ограничивает.

3.7 Настройка '''Logon Control''' для переподключения пользователей

http://support.citrix.com/proddocs/topic/web-interface-impington/wi-configure-workspace-control-gransden.html

Workspace Control

Функции workspace control позволяют пользователям быстро отключаться от всех запущенных приложений и ресурсов и переподключаться на другом пользовательском устройстве.

Требования для работы Workspace Control

Для работы workspace control нужно:
- Для работы workspace control с клиентами для windows версий 8.x и 9.x нужно включить опцию Override user device names в Session Preferences в консоли конфигурирования Web-интерфейса Citrix.
- Если Web-интерфес обнаруживает, что доступ к сессии осуществляется через из сессии Citrix, то функция workspace control отключается.
- В зависимости от настроек безопасности, Internet Explorer может блокировать загрузку файлов, инициированную не напрямую пользователем и попытки повторного подсоединения к ресурсам с помощью нативного клиента блокируются. Если переподключение невозможно, пользователь увидит соответсвующее сообщение и приглашение сконфигурировать Internet Explorer.
- У каждой Web-сессии случается тайм-аут, после заданного периода бездействия (обычно - 20 минут). При тайм-ауте сессии появляется “logoff screen”, однако все ресурсы сессии не отключаются. Пользователь должен вручную отсоединиться или завершить сессию, или зайти обратно и в Web-интерфейсе нажать кнопку Log Off или Disconnect .
- Ресурсы опубликованные для анонимного доступа закрываются (terminated) как после отсоединения авторизованного пользователя, так и анонимного. Короче - переподключение к анонимным ресурсам невозможно.
- Для использования pass-through, smart card, или pass-through with smart card нужно установить доверительные отношения между сервером, на котором работает Web-интерфейсо и Citrix XML Service.
- Если не включена сквозная (pass-through) передача учетных данных для сайтов XenApp Services, то пользователи смарт-карт будут вынуждены вводить PIN при каждом переподключении.

Ограничения Workspace Control

Если вы планируете включить workspace control, избегайте следующего:

- Workspace control не работает на сайтах, доставляющих offline-приложения. Если сайт сконфигурирован для двухрежимной доставки, то workspace control будет работать только с online-реурсами.
- Нельзя использовать workspace control с клиентами для 32-bit Windows версий старее, чем 8, а также клиентами Remote Desktop Connection (RDP). Кроме того, эта функция работает только с серверами Presentation Server 4.5 или более поздними.
- Workspace control позволяет переподключение только для отключенных виртуальных столов XenDesktop. ПОльзователи не смогут подключиться к виртуальным столам, находящимся в режиме suspended.

Использование Workspace Control с Integrated Authentication Methods на XenApp Web Sites
http://support.citrix.com/proddocs/topic/web-interface-impington/wi-configure-workspace-control-gransden.html

Этот раздел применим только к Web-сайтам XenApp. Если пользователи используют для входа pass-through, smart card, или pass-through with smart card authentication, необходимо настроить доверительные отношения между сервером Web-интерфейса и всем серверами, на кторых работает Citrix XML Service и с которыми взаимодействует этот web-интерфейс. Citrix XML Service передает информацию о ресурсах Web-интерфейсу от серверов XenApp и XenDesktop. Без доверительных отношений, кнопки Disconnect, Reconnect и Log Off не работают у пользователей, прошедших сквозную (pass-through) аутентификацию или с помощью смарт-карт.

Вам не не нужно настраивать доверительные отношения, если пользователи аутентифицируются на server farm, а также если пользователи не аутентифицируются смарт-картами или pass-through.

Настройка доверительных отношений между серверами

Если вы настраиваете сервер так, чтобы он доверял запросам к Citrix XML Service, учитывайте следующее:
- При настройке доверительных отшений, аутентификацию пользователя будет осуществлять сервер Web-интерфейса. Для исключения рисков информационой безопасноти, следует использовать IPSec или файрвол и т.д., для того ,что гарантировать, что с Citrix XML Service взаимодействуют только доверенные сервисы. В противном случае, в отсутствие технологии, фильтрующей сервисы, взаимодействующие с XML Service, любой клиент сети сможет отключить или уничтожить сессию пользователя. Доверительные отношения не нужны, если сайты сконфигурированы для использования только explicit authentication .
- Включайте доверительные отношения только на серверах, которые напрямую взаимодействуют с Web-интерфейсом. Эти сервера присутствуют в списке Server Farms task в консоли Citrix Web Interface Management .
- Технологии безопасности, которые защищают Citrix XML Service, нужно настраивать так, чтобы доступ имел только сервер Web-интерфейса. Например, если Citrix XML Service разделяет порт с Microsoft Internet Information Services (IIS), можно использовать ограничение по IP-адресу, в IIS для ограничения доступа к Citrix XML Service.

Настройка:
На сервере фермы кликните Start > All Programs > Citrix > Management Consoles > Citrix Delivery Services Console.
- В левой части консоли кликните Citrix Resources > XenApp, разверниет список и кликните Policies.
- In the details pane of the console, select the Computer tab and click New.
Enter a name and, optionally, a description for your new policy and click Next.
In the Categories list, click XML Service and, under Settings, select Trust XML requests and click Add.
Select Enabled and click OK. Click Next.
If required, apply filters to your policy to determine the circumstances under which it is applied and click Next.
Ensure that the Enable this policy checkbox is selected and click Save.

3.8 Ускорение запуска приложений - Session Pre-launch и Session Linger

Session Pre-launch, Session Linger и Fast Reconnect

Этот набор функций позволяет убрать задержку при запусек сессий. С помощью настраиваемой политики Session Pre-launch , сессия стартует автоматически при входе пользователя на ферму XenApp. При помощи политики Session Linger , можно задать промежуток времени, когда сессия пользователя остается активной на сервере, после закрытия приложения пользователем.
Fast Reconnect, встроен в XenApp и не требует конфигурирования. Эта функция позволяет уменьшить задержку при переподключении пользователя к существующим сессиям.

Session Linger

Сессия пользователя завершается при завершении запущенных процессов и закрытии окон. Session Linger можно использовать для того, чтобы сессия пользователя оставалась активной некоторое время после закрытия приложения и следующее приложение, запущенное в течение заданного периода времени откроется быстрее, т.к. сессия пользователя уже существует.
Для использования Session Linger нужна настроить следующие параметры политики пользователя Citrix User policy:

- Linger Terminate Timer Interval задает количество минут, в течение которых сессия остается активной, после закрытия последнего приложения. Если в течение этого интервала запускается новое приложение, то оно запускается в существующей сессии. Если по истечении заданного промежутка времени пользователь ничего не запускает, то сессия завершается.
Если этот параметр не задан, то session linger отключен.

- Linger Disconnect Timer Interval задает количество минут, по истечении которых сессия пользователя будет отключена. При отключении освобождается лицензия. Если параметр не занан, то перед закрытием сессий, они не отключаются, а закрываются сразу.

Сессии анонимных пользователей не имеют отключенного состояния. Они либо активны, либо их нет. Таким образом, если заданы параметры Linger Terminate Timer Interval и Linger Disconnect Timer Interval, то сессия анонимного пользователя будет уничтожена по истечении любого из этих интервалов.

Раздел 4: Конфигурирование политик XenApp

4.1 - Как определить результирующую политику для заданной группы или пользователя.

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-policies-creating-wrapper-v2.html

Работа с политиками Citrix

Для управления доступом пользователей к сессиям и окружением сессий используются политики Citrix. Политики - это наиболее эффективный способ управления соедиениями, безопасностью и полосой пропускания.
Политики можно создавать для определенных групп пользователей, устройств или типов соединений.
Каждая политика может содержать целый набор параметров.

Управлять политиками можно как через консоль управления групповыми политиками Windows (Group Policy Management Console), так и с помощью AppCenter (бывшая Delivery Services Console). Использование той или иной консоли определяется наличием или отсутсвием инфраструктуры Active Directory, а
также наличием разрешений на изменение объектов групповой политики.

Использование редактора групповой политики.

Если в сети настроена инфраструктура Active Directory и вы имеете права на изменение объектов групповой политики, то для создания политик следует использовать редактор групповой политики.

Использование AppCenter

Если в сети используются службы каталогов отличные от AD, или у вас не прав на изменение объектов групповой политики, то для управления политиками Citrix нужно использовать AppCenter. Созданные объекты групповой политики будут храниться в data store.

Обработка политик и их приоритеты

Групповые политики обрабатываются в следующем порядке:

- Локальные
- Политики фермы XenApp (хрянящиеся в data store)
- Политики уровня сайта (Site-level)
- Политики уровня домена (Domain level)
- Политики Organizational Units

В случае конфликта, настройки политик применяемые позднее, перекрывают примененные ранее. Это означает, что политики имеют следующий порядок приоритетов (от более высокогоко к менее высокому приоритету):

- Политики Organizational Units
- Политики уровня домена (Domain level)
- Политики уровня сайта (Site-level)
- Политики фермы XenApp (хрянящиеся в data store)
- Локальные

Например, администратор Citrix создал политику (Policy A) с помощью AppCenter, которая включает перенаправление клиентских файлов для сотрудников отдела продаж. Тем временем, другой администратор, создал политику (Policy B) через редактор групповой политики в домене, которая отключила перенаправление клиентских файлов для сотрудников отдела продаж. Когда сотрудники подключаются к ферме, то применяется политика Policy B, а политика Policy A игнорируется. Это происходит потому, что политика Policy B обрабатывается на уровне домена, а политика Policy A обрабатывается на уровне фермы XenApp.

Заметьте, при запуске сессии ICA или RDP, настройки сессии Citrix имеют больший приоритет над аналогичными настройками, сделанными в политике Active Directory или в настройках сервера RDP (Remote Desktop Session Host Configuration). Сюда входят настройки, обычные для сессии RDP - обои рабочего стола, анимация меню и ид окон при перетаскивании.

Функциональные уровни Active Directory

Политики Citrix способны работать в окружении Active Directory на базе доменов Windows 2000 и более новых. Для того чтобы политики Citrix были включены в отчеты о Результирующей политике (Resultant Set of Policy), необходимо, чтобы в лесу домена был как минимум один контроллер домена под управлением Windows Server 2003.

Работа с политиками Citrix

Процесс работы с политиками Citrix включает следующие этапы:
- Создание политики
- Настройка параметров политики
- Применение политики к подключениям, путем добавления фильтров
- Приоритизация политики
- Проверка эффективности политики, путем запуска мастера моделирования политики - Citrix Group Policy Modeling

4.2 Мониторинг состояния - Health Monitoring & Recovery (HMR)

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-maintain-monitor-server-perf.html
Health Monitoring and Recovery можно использовать для запуска тестов на серверах фермы, для наблюдения за их состоянием и определением вероятных проблем. Citrix предоставляет стандартный набор тестов, а также есть возможность импортировать дополнительные тесты, в том числе и разработанные самостоятельно. Тесты Citrix, поставляемые с XenApp, позволяют наблюдать за службами - Remote Desktop Services, XML Service, Citrix IMA Service, и событиями входа-выхода пользователей.

По-умолчанию Health Monitoring and Recovery включен на всех серверах фермы и тесты запусакаются на всех серверах, в том числе и на data collector. Обычно, запускать тесты на data collector не требуется, т.к. data collector не используется для запуска приложенй, особенно в больших фермах. Если запуск Health Monitoring & Recovery на сервере data collector не требуется - его надо отключить вручную.

Все создаваемые тесты нужно хранить в этой папке: %Program Files%\Citrix\HealthMon\Tests\Custom\

где %Program Files% это папка в которой установлен XenApp. При сохранении тестов, не используйте пробелы в именах файлов.

Конфигурируется Health Monitoring and Recovery путем изменения настроек политики Компьютера:

- Health monitoring (по-умолчанию включена). Включает или отключает Health Monitoring and Recovery.
- Health monitoring tests. Используйте это параметр для того, чтобы указать какие тесты запускать. Выберите из стандартного набора тестов Citrix или добавьте свои тесты. Описания действий по восстановлению ищите тут - http://support.citrix.com/proddocs/topic/xenapp6-w2k8-admin/ps-maintain-mod-tst-settings-v2.html.
- Maximum percent of servers with logon control (по-умолчанию - 10%). Используйте этот параметр для того, чтобы указать, какой процент серверов может быть отключен и исключен из балансировки нагрузки.

Дополнительную информацию о том, как освободить сервер от пользователей, перед его отключением, смотрите тут - http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-sf-logons-control-v2.html#ps-sf-logons-control-v2
Для определения того, испытывает ли сервер проблемы, используйте балансировку нагрузки и инструмент Health Monitoring and Recovery.

Тесты Citrix

Тест Citrix IMA Service test
Этот тест опрашивает службу, для того, чтобы убедиться, что она работает и перечисляет приложения опубликованные на сервере.

Тест Logon monitor test
Этот тест следит за циклами входа-выхода пользователей для определения проблем с инициализацией сессий или возможных отказов приложения.

Тест Remote Desktop Services test
Этот тест перечисляет список сессий на сервере и дополнительную информацию.

Тест XML Service test
Этот тест запрашивает тикет от службы XML, работающей на сервере и выводит его содержимое.

Проверка DNS
В этом тесте производится прямой DNS запрос имени сервера у локального DNS сервера и сервер должен получить свой IP адрес. Тест считается непройденным, если полученный IP-адрес не совпадает с выданным серверу. Для выполнения дополнительного обратного DNS запроса, используйте флаг /rl .

Проверка локального кеша Check Local Host Cache test
Citrix не рекомендует запускать этот тест, если вы не испытываете проблем с локальным кешем хоста. Этот тест проверяет, что данные, хранящиеся в локальном кеше сервера фермы XenApp не повреждены и не имеют повторяющихся записей. Т.к. этот тест может потреблять много ресурсов процессора, используйте 24-часовой интервал (86,400 секунд), а таймаут и порг оставляйте по-умолчанию.

Перед запуском этого теста, убедитесь, что имеются разрешения на соотвествующие файлы и ветки реестра. Для этого запустите файл LHCTestACLsUtil.exe, расположенный в папке C:\Program Files (x86)\Citrix\System32 на сервере XenApp. Для запуска этой утилиты нужно иметь права локального администратора.

Тест XML Threads test
Этот тест проверяет предел текущего количества вычислительных потоков службы Citrix XML Service. При запуске этого теста, задается максимальное допустимое количество. Тест сравнивает текущее количество и заданное и при превышении текущего над заданным фиксируется ошибка.

Тест службы печати - Citrix Print Manager Service test
Этот тест перечисляет принтеры сессии, для определения состояния службы печати Citrix Print Manager service. Отказ фиксируется при невозможности перечисления принтеров.

Тест системной службы печати Microsoft Print Spooler Service test
Этот тест перечисляет драйверы принтера, обработчики печати и принтеры для определения состояния службы печати Windows - Print Spooler Service .

Тест ICA Listener test
Этот тест определяет, может ли сервер XenApp принимать подключения ICA. Тест определяет порт ICA зпдпнный по-умолчанию, подсоединяется к порту и отсылает тестовый набор данных и слушает ответ. Тест считается пройденным при получении корректного ответа.

Зависания и падения служб печати Citrix Print Manager Service (cpsvc.exe) и Microsoft Print Spooler Service (spoolsv.exe)

http://support.citrix.com/article/CTX113789

Симптомы

Служба Citrix Print Manager service (cpsvc.exe) или Microsoft Print Spooler service (spoolsv.exe) зависает или падает.
При этом автоматически не создаются принтеры, в сессии принтер по-умолчанию не выставляется правильно, а задания печати не становятся в очередь и т.д.

4.3 - Оптимизация HDX

Source: XenApp > XenApp 6.5 for Windows Server 2008 R2 > Manage >
Enhancing the User Experience With HDX > Configuring HDX MediaStream Flash
Redirection > Configuring HDX MediaStream Flash Redirection on the Server
http://support.citrix.com/proddocs/topic/xenapp65-admin/hd-flash-configure-server-ad.html

Это мы уже описывали тут:
http://wiki.autosys.tk/XenApp.%d0%9f%d0%be%d0%b4%d0%b3%d0%be%d1%82%d0%be%d0%b2%d0%ba%d0%b0-%d0%ba-%d1%8d%d0%ba%d0%b7%d0%b0%d0%bc%d0%b5%d0%bd%d1%83-1Y0-A20-Citrix-XenApp-6-5.ashx#%D0%9A%D0%BE%D0%BD%D1%84%D0%B8%D0%B3%D1%83%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_HDX_MediaStream_Flash_Redirection_%D0%BD%D0%B0_%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B5_89

Удаление эха, в конференциях, с помощью HDX RealTime

http://support.citrix.com/proddocs/topic/xenapp65-admin/hd-audio-echo-ad.html

При участии пользователя в аудио-видео конференциях, может возникать эхо. Обычно, эхо возникает когда колонки и микрофон расположены слишком близко друг к другу. Поэтому Citrix рекомендует использовать гарнитуры (headsets).

HDX RealTime обеспечивает подавление эха. Эта функция включена по-умолчанию. Для наиболее эффективного подавления - пользователь должен выбрать либо среднее качество - Medium - optimized for speech либо низкое, оптимизированное для медленных соединений - Low - for low-speed connections . Настройка высого качества - High - high definition предназначена для воспроизведения музыки, а не конференций и при конференциях её следует избегать.

Эффективность подавления эха зависит от расстояния между микрофоном и колонками.

Подавление эха доступно в Citrix Receiver 3.0 for Windows и Citrix Online Plug-in 12.1 for Windows, а также в Web Interface 5.3.
Для включения или отключения

На компьютерах 32-bit: На устройстве пользователя откройте реестр и перейдите в раздел HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\ClientAudio\EchoCancellation.
На компьютерах 64-bit: а устройстве пользователя откройте реестр и перейдите в раздел HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\ClientAudio\EchoCancellation.

В поле Значение введите TRUE для включения или FALSE для отключения подавления эха.

Видеоконференции и сжатие видео в реальном времени

http://support.citrix.com/proddocs/topic/xenapp65-admin/hd-realtime-video-conf-wrapper-xa.html

HDX RealTime обеспечивает пользователей полноценными функциями видеоконференцсвязи.

Для использования HDX RealTime Webcam Video Compression нужно:

- На пользовательском устройстве Установить Install Citrix Receiver 3.0 for Windows или Citrix Online Plug-in 12.1 for Windows.
- В том же окружении, где работает XenApp установить Microsoft Office Communications Server 2007 . Это не опубликованное приложение.

Примечание: Microsoft Office Communications Server 2007 лучше устанавливать на отдельный компьютер, а не на сервер с XenApp.

- Опубликуйте на ферме XenApp Microsoft Office Communicator 2007 .
- Убедитесь, что на пользовательском устройстве есть возможность воспроизводить звук.
- Назначте по дному процессору на пользовательскую сессию, в которых используется видеоконференцсвязь.
- Web-камеру используйте с настройками по-умолчанию.
- Включите следующие настройки политики:
Client audio redirection
Client microphone redirection
Multimedia conferencing
Windows Media Redirection
- Установите драйверы для вебкамеры на пользовательском устройстве. Рекомендуется использовать драйверы производителя.

Параметр Client Audio redirection
Это политика пользователя Citrix (User Policy). Она позволяет включить или отключить перенаправление звука от приложения, работающего на сервере XenApp на звуковое устройство клиента. По-умолчанию - включено.

Параметр Client Microphone Redirection
Это политика пользователя Citrix (User Policy). Она позволяет включить или отключить перенаправление микрофона. По-умолчанию - включено.

Параметр Multimedia Conferencing
Это политика компьютера Citrix (Computer Policy). Она позволяет включить или отключить поддержку мультимедийных приложений для видеоконференций. По-умолчанию - включено.

Параметр Windows Media Redirection
Это политика компьютера Citrix (Computer Policy). Используйте эту политику для разрешения или запрещения доставку потокового аудио или видео пользователям. По-умолчанию - включено.

4.4 Конфигурирование политики перезагрузки серверов и ограничения входа на время перезагрузки

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-ref-policies-reboot.html

Политик перезагрузки серверов доступны только в редакицях XenApp Enterprise и Platinum.

Reboot custom warning
Эта настройка включает или отключает рассылку предупреждений пользователям (помимо стандартного сообщений о перезагрузке), перед запланированной переазгрузкой. По-умолчанию рассылается только стандартное оповещение.

Reboot custom warning text
Этот параметр задает текст сообщения о перезагрузке. По умолчанию - пусто.

Reboot logon disable time
Этот параметр задает интервал времени (количество минут), перед запланированной перезагрузкой, в течение которого отключен вход на сервер. По-умолчанию, вход на сервер отключается за 60 минут до перезагрузки.

Reboot schedule frequency
Этот параметр задает частоту запланированной перезагрузки в днях. По-умолчанию, планируеттся перезагрузка раз в неделю.

Reboot schedule randomization interval
Этот параметр служит для того, чтобы все серверы не перезагружались одновременно, а перезагружались в течение этого интервала до или после назначенного времени перезагрузки. По-умолчанию - 0.
Например - Если перезагрузка запланирована на 11:00 PM и randomization interval составляет 15 минут, то перезагрузка произойдет в люьое время между 10:45 PM и 11:15 PM.

Reboot schedule start date
Этот параметр задает жата, начиная с коротой серверы будут перезагружаться. Формат - MM/DD/YYYY. По-умолчанию - не задано.

Reboot schedule time
Этот параметр задает когда будет перезагружен сервер. ФОрмат - H:MM TT, TT - время дня (AM или PM). Время перезагрузки задается в локальной тайм-зоне в формате 12-часов. По-умолчанию - 12:00 AM (полночь).
Если будет введено время в формате 24-часа, то оно автоматически сконвертируется в формат 12-часов. Если вы введете время без значения TT, то по -умолчанию будет задано AM.

Reboot warning interval
Этот параметр задает как часто будут отправляться пользователям предупреждения о грядущей перезагрузке. По-умолчанию, сообщения отсылаются раз в 15 минут.

Reboot warning start time
Этот параметр задает количество минут до перезагрузки, когда будут начаты отправляться предупреждения пользователям. По-умолчанию, предупреждения начинают отправляться за 60 минут.

Reboot warning to users
Этот параметр разрешает или запрещает рассылку стандартных предупреждений о перезагрузке. По-умолчнию - стандартные сообщения не рассылаются.

Scheduled reboots
Этот параметр разрешает или отключает запланированные перезагрузки. По-умолчанию, перезагрузка серверов отключена.
Вы можете сконфигурировать автоматичсекую перезагрузку в заданное время и с заданной частотой. При включении этого параметра, в силу вступают следующие параметры:
Reboot schedule frequency
Reboot logon disable time
Reboot schedule randomization interval
Reboot schedule start date
Reboot schedule time

4.5 Применение политик и фильтры

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-policies-applying.html

При добавлении к политике фильтра, настройки политики применяются не ко всем подключениям, а только к тем, которые подходят по критериям фильтра. Если же фильтр не задан, то политика применяется ко всем подключениям.
К политикам можно применять неограниченное количество фильтров. Состав достпных фильтров зависит от типа политики - Computer или User. Ниже приведены доступные фильтры:

Контроль доступа (Access Control) - Применяет политику на основании разрешений доступа пользователя. Только User policies.

Branch Repeater - Применяет политику, в зависимости от того, работает ли сессия через Citrix Branch Repeater. Только User policies.

IP адрес клиента (Client IP Address) - Применяет политику в зависимости от IP-адреса устройства клиента. Только User policies.

Имя устройства клиента (Client Name)- Применяет политику в зависимости от имени клиентского устройства. Только User policies.

Organizational Unit - Применяет политику в зависимости от того, какому organizational unit (OU) принадлежит рабочее место. Computer и User policies.

Примечание: Фильтр Organizational Unit применим только в контексте фермы XenApp и сконфигурировать его можно только из консоли AppCenter. В редакторе групповой политики этот фильтр недоступен.

Пользователь или группа (User or Group) - Применяет политику в зависимости от имени пользователя или принадлежности группе. Только User policies.

Worker Group - Применяет политику в зависимости от того, какой группе воркеров (worker group) принадлежит сервер, на котором работает сессия пользователя. Computer и User policies

При входе пользователя, XenApp определяет политики, которые подходят заданным для этого подключения фильтрам. XenApp сортирует политики в порядке приоритета, сравнивает настройки политик и применяет политику в соответствии с приоритетами. XenApp пересчитывает результирующую политику каждые 90 минут, после входа пользователя на ферму.

Любая настройка политик в состоянии “отключено” имеет приоритет над настройкой в состоянии “включено”, политики более низкого приоритета. Не настроенные параметры политик игнорируются.

Нефильтрованные политики

По-умолчанию, в XenApp настройки политик Computer и User нефильтрованы(Unfiltered policies) и применяются ко всем подключениям.

Если вы работаете в среде Active Directory и используете редактор групповой политики для настроек политик Citrix, то настройки, которые добавляются к нефильтрованным политикам, применяются ко всем серверам фермы и всем подключениям, на которые распространяется действие объектов политики.

Например - Sales OU содержат объект групповой политики (GPO), названный Sales-US, который включает в себя всех членов US sales team. В объекте групповой политики Sales-US GPO сконфигурирована нефильтрованная политика, включающая в себя несколько настроек. Когда менеджер US Sales входит на ферму, настройки нефильтрованной политики автоматически применяются к его сессии, т.к. пользователь является членом Sales OU и на него распространяется действие объекта групповой политики Sales-US GPO.

При использовании консоли AppCenter для настроек политик Citrix, настроки, добавляемые к нефильтрованным политикам применяются ко всем серверам и подключеням фермы.

Режимы фильтров

Режим фильтра задает, будет ли политика применяться подключениям, соответствующим критериям фильтра или к не соответствующим. Если режим установлен в значение Allow (по-умолчанию), политика применяется только к подключениям, соответствующим критериям фильтра. Если режим установлен в значение Deny, политика будет применяться только к подключениям не соответствующим фильтру. Ниже рассмотрен пример, показывающий работу режимов фильтров политик Citrix в тех случаях, когда задано несколько фильтров.

Пример: Фильтры подобного типа с разными режимами.

В политиках есть два фильтра, одного типа. Один имеет режим Allow и второй - Deny. Фильтр в режиме Deny имеет приоритет, если подключение соответствует обоим фильтрам. Например:
Политика 1 содержит такие фильтры:
Фильтр A - Фильтр пользователей, который задает группу Sales и находится в режиме Allow.
Фильтр B - Фильтр пользователей, который задает пользователя Sales manager и находится в режиме Deny.

Вследствие того, что режим фильтра B - это Deny,политика не применяется, когда Sales manager входит на ферму, хотя он и принадлежит группе Sales.

Пример: Фильтры разного типа в одинаковом режиме.

В политиках два или более фильтров разного типа в режиме Allow. Для того чтобы политика была применена к подключению нужно, чтобы подключение подходило хотя бы под один фильтр каждого типа. То есть - в случае наличия двух разнотипных фильтров в режиме Allow, для применения политики нужно чтобы подключение подошло под критерии обеих фильтров!
Например:
Политика 2 содержит такие фильтры:
Фильтр C - Фильтр пользователей, задает группу Sales и находится в режиме Allow.
Фильтр D - Фильтр IP-адресов, задает сеть 12.0.0.* (диапазон сети корпоративной сети) и находится в режиме Allow.

При входе Sales manager из офиса, политика применяется, потому что подключение удовлетворяет обоим фильтрам.

Политика 3 содержит такие фильтры:
Фильтр E - Фильтр пользователей, задает группу Sales и находится в режиме Allow.
Фильтр F - Фильтр контроля доступа (Access Control), который задает подключения через Access Gateway и находится в режиме Allow.

При входе Sales manager из офиса, политика НЕ применяется, т.к. подключение не соответствует фильтру F.

Раздел 5: Публикация приложений и контента

5.1 - Методы доставки приложений

http://support.citrix.com/proddocs/topic/xenapp65-publishing/ps-planning-application-delivery-v2.html
Приложения бывают streamed - упакованные в контейнер и hosted - установленные на сервер XenApp.
Для streamed приложений создается профиль приложения, который размещается на сервере профилей или web-сервере и содержит XML-файл манифеста (.profile), файлы приожения, контрольную сумму, иконки (Icondata.bin), и скрипты исполняемые перед запуском и после завершения приложения.
Приложения могут быть опубликованы тремя разными способами, либо их сочетанием:
1. Installed on server - приложение устанавливается как на сервер терминалов. Преимущества - независимость от пользовательского устройства, централизация.
2. Streamed to server - приложение инкапсулируется в профиль приложения, хранится на сервере и при запуске обрабатывается на сервере. Преимущества - возможность запуска разных версий приложений на одном сервере, удобный централизованный апдейт приложений, независимость от пользовательского устройства. Недостатки - некоторые приложения будут неправильно работать из профиля (например .NET).
3. Streamed to desktop - приложение инкапсулируется в профиль приложения, хранится на сервере, а при запуске обрабатывается на компьютере пользователя. Преимущества - ресурсоемкие приложения используют ресурсы десктопа, возможность работы off-line. Недостатки - пользовательское устройство должно работать под управлением WIndows и иметь достаточные ресурсы.

Также существует двойной режим доставки - Dual mode delivery:
Если для приложения выбран метод - streamed if possible, otherwise accessed from a server (то есть двойной или резервный), XenApp будет пытаться запустить приложение в режиме streamed to desktop на устройстве пользователя, при этом, если стримминг приложения невозможен - будет использован резервный метод. Например - можно указать, что приложение должно запускаться как streamed to desktop при доступе с устройства под управлением Windows и запускать его как установленное на сервере приложение, при доступе к нему с мобильного не Windows-устройства.
Данный метод позволяет по возможности разгрузить серверы фермы с помощью фильтров и балансировки нагрузки (Load Balancing Policies for Streamed App Delivery).

Выбор между доставкой приложения, либо целого рабочего стола

Перед публикацией приложений следует решить - будет ли осуществляться доставка всего рабочего стола, либо будут доставляться только приложения.
Публикация приложений осуществляется наиболее часто и предоставляет наибольшую гибкость при администрировании.
Вы можете использовать политики для предотвращения доступа пользователей к дискам сервера и вводить прочие ограничения для обеих методов доставки.

5.2 - Создание профилей приложений и связей между ними

http://support.citrix.com/proddocs/topic/xenapp65-publishing/ps-stream-profiler-wrapper-v6-1.html
Профиль (profile) - это приложение, упакованное для стримминга с помощью инстпумента Citrix Streaming Profiler. Профиль может содержать единственное приложение или набор приложений. Например - можно упаковать в профиль только Microsoft Word, или же весь Microsoft Office. Также можно упаковать в профили отдельные приложения и наладить между ними межпрофильную связь (inter-isolation communication).
Для создания профилей необходимо установить Streaming Profiler (профайлер) на чистый компьютер, называемый - профилирующая рабочая станция (profiler workstation). Мастер профилирования фиксирует изменения в системе, происходящие при установке приложения и метаданные, необходимые для доставки приложения в виде профиля. Профайлер объединяет файлы и конфигурационные настройки в профиль приложения.

Individual targets - это пользовательские окружения, содержащиеся в профиле приложения. Initial target - это окружение системы, на которой создан профиль приложения. При этом, можно создать несколько окружений, для работы на специфичных системах. Например - некоторые коммерческие приложения способны работать на многих операционных системах и языковых окружениях, а другие - только на определенных ОС и языках.

ВАЖНО: Приложения, скомпилированные как 64-бит приложения не подходят для стримминга. При этом, 32-бит приложения, могут упаковываться в профиль на 64-бит системах и конфигурироваться для стримминга на 64-бит системы.

В зависимости от окружения ваших пользователей, есть возможность добавлять в профиль приложения необходимые сторонние компоненты, такие как Java Runtime Environment. В некоторых случаях, может понадобиться помещать несколько приложений профиль, для того чтобы гарантировать их нормальную совместную работу. Кроме того, есть возможность связывать профили разных приложений, для взаимодействия приложений, работающих в изолированных окружениях.

После создания профиля и сохранения его на разделяемый ресурс в App Hub, сконфигурируйте пользователей и опубликуйте приложение в режиме стримминга с помощью мастера в Citrix AppCenter. Когда пользователь запускает приложение, опубликованное в режиме стримминга, Citrix Plug-in на пользовательском устройстве автоматически выбирает правильное окружение из профиля, которое соответствует конфигурации пользовательского устройства.

За дополнительной информацией обращайтесь на соответствуюшие страницы Citrix Knowledge Center:

Часто задаваемые вопросы об Application Streaming - http://support.citrix.com/article/CTX118181
Повышение уровня безопасности Application Streaming - http://support.citrix.com/article/CTX110304
Application Streaming Delivery and Profiling Best Practices for XenApp at http://support.citrix.com/article/CTX118623

Дополнительно - выберите свою версию XenApp на сайте поддержки и кликните вкладку Technotes, а затем Application Streaming.

Примечание: Streaming Profiler SDK содержит набор объектов COM и интерфейсов .NET, которые предоставляют программный интерфейс для профайлера. Дополнительную информацию можно найти в справочной системе SDK и Readme с сайта Citrix Developer Network - http://community.citrix.com/.

Обзор доступных пользовательских окружений ('''Targets Overview''')

http://support.citrix.com/proddocs/topic/xenapp65-publishing/ps-stream-profile-targets-v2.html

Пользовательское окружение (target) - это набор файлов, данных реестра и другой информации, необходимой для изоляции приложения в заданном окружении. Кроме того, в каждом варианте окружения задана комбинация операционной системы, сервис пака, буква системного диска, и язык. Приложения могут быть спрофилированы с нужным вариантом этих параметров - например: Microsoft Vista, все сервиспаки, буква системного диска - C, и язык - English.

Внутри target может быть несколько исполняемых файлов и приложений, которые обычно получают значек в меню Пуск. Например - “Microsoft Office” это профиль, а “Microsoft Word” - это приложение внутри этого профиля. Профиль может поддерживать несколько окружений (targets) - в этом случае target - это отдельная установка профилируемого приложения, предназначенного для запуска на специфичной версии ОС.

Пользовательские устройства выбирают окружение из тех, что были заданы при создании профиля. По-умолчанию, окружение соответствует операционной системе и конфигурации, рабочей станции, на которой создавался профиль, хотя могут быть выбраны и другие ОС.

Для задания параметров пользовательских окружений, включенных в профиль, используется профайлер. Один или несколько администраторов могут запускать профайлер несколько раз в разных вариантах ОС, для получения необходимого набора пользовательских окружений, включенных в профиль приложения.

Параметры каждого пользовательского окружения, включенного в профиль хранятся в манифесте профиля - файле .profile.

Перекрывающие друг-друга определения пользовательских окружений запрещены. К любому пользовательскому компьютеру должен походить только один вариант вариант пользовательского окружения из хранимых в профиле.

Администратор может обновлять профиль и пользовательское окружение в любой момент, не влияя на исполнение приложения в уже запущенных сессиях. При этом потребуется дополнительное место на диске файл-сервера для хранения старых версий профиля. Профайлер не обеспечивает удаления старых версий пользовательских окружений - то есть их придется удалять вручную. При этом нужно следить, что удаляемые варианты пользовательского окружения (targets) больше никем не используются.

Новейшие операционные системы, которые будут издаваться в будущем - не поддерживаются. То есть приложение не сможет запуститься, если будет запущено в неподдерживаемой ОС.

5.3 - Публикация приложений

http://support.citrix.com/proddocs/topic/xenapp65-publishing/ps-pub-deliverymethod.html

Типы публикуемых ресурсов:

Server desktop - Публикуется рабочий стол сервера Windows. При подключении пользователь видит рабочий стол, с которого можно запустить любое приложение, установленное на сервере. После выбора этого типа ресурса следует указать сервер, рабочий стол которого будет опубликован.
Для публикации рабочего стола на сервере должен быть установлен XenApp.
Content - Публикуется неисполняетмая информация - типа медиафайлов, веб-страниц, документов. При выборе этого типа контента нужно будет указать путь URL (Uniform Resource Locator) или UNC (Uniform Naming Convention) к публикуемому файлу. Кликните Browse для того чтобы увидеть доступные ресурсы.
Application (по-умолчанию) - Публикация приложения, установленного на одном или нескольких серверах фермы.
Необходимо указать тип публикуемого приложения:
Accessed from a server. Grants users access to applications that run on a XenApp server and use shared server resources. If you choose this option, you must then enter the location of the executable file for the application and the XenApp server on which it will run. Choose this option as the application type unless you intend to stream your applications.
Streamed if possible, otherwise accessed from a server (also called dual mode streaming). Grants users access to a profiled application that streams from the file share to their user devices and launches locally from within an isolation environment. Alternatively, for user devices that do not support streamed applications (for example, if the Offline Plug-in is not installed), this setting allows the use of an ICA connection to access the application installed on or streamed from a XenApp server.
Нельзя стриммить некоторые типы приложений, например - .NET приложения.
Streamed to client. Grants users access to a profiled application that streams from the file share to their user devices and launches locally from within an isolation environment. With this option, the application uses client resources instead of server resources. Users must have the Offline Plug-in installed and access the application using Online Plug-in or a Web Interface site. If selected, user devices that do not support client-side application virtualization (such as, they use a non-Windows client) or do not have the Offline Plug-in installed locally cannot launch the application.

5.6 - Перенаправление контнета с сервера клиентам и от клиентов к серверу.

От сервера клиенту

http://support.citrix.com/proddocs/topic/xenapp65-publishing/ps-pub-content-redirect-server-task-v2.html
Перенаправление контента с сервера к клиенту используется для того, чтобы открывать некоторые типы ссылок на клиенте, сохраняя ресурсы сервера.
Например на севрере может быть опубликован почтовый клиент и пользователи могут часто открывать Web-страницы и мультимедийные URL, ссылки на которые приходят по почте. В этом случае, включение перенаправления контента (content redirection) от сервера к клиенту позволит воспроизводить мультимедию и открывать страницы средствами клиентских устройств.

Примечание: Если клиентское устройство не может открыть страницу, то URL перенаправляется обратно на сервер.

1. Настройка перенаправления контента осуществляется с помощью политик пользователя - Citrix policy setting > User > ICA > File Redirection. Параметр Host to client redirection включает перенаправление. По-умолчанию этот параметр отключен и контент обрабатывается на сервере.
2. В Citrix AppCenter опубликуйте ресурс и выберите пользователей, которым он доступен.

При перенаправлении контента открываются следующие типы URL (в Windows и Linux):
HTTP (Hypertext Transfer Protocol)
HTTPS (Secure Hypertext Transfer Protocol)
RTSP (Real Player and QuickTime)
RTSPU (Real Player and QuickTime)
PNM (Legacy Real Player)
MMS (Microsoft Media Format)

Если перенаправление не работает для некоторых ссылок HTTPS, то следует проверить что на устройстве пользователя установлены соответствующие сертификаты. Если сертификатов нет, то HTTP ping от клиента к URL не пройдет и будет перенаправлен обратно серверу. Для старых плагинов перенаправление контента требует Internet Explorer Version 5.5 with Service Pack 2 на системах Windows 98 или выше.

Перенаправление контента от клиента серверу

Настройка перенаправления контента от клиента серверу позволяет ассоциировать определенные типы файлов с опубликованными приложениями. Перенаправление контента от клиента к серверу работает только для клиентов, использующих Citrix Receiver.

Конфигурирование:

1. Перенаправление контента от клиента к серверу конфигурируется в консоли Citrix Web Interface Management при конфигурировании XenApp Services site (если сайт XenApp Services не создан, то его надо создать). Опция доступна тут: PNAgent settings > Server Farms > Manage Server Farms > Advanced.
2. В консоли Citrix AppCenter при публикации приложения следует указать связанные с ним типы (расширения) файлов. При запуске приложения пользователем будут выполнены необходимые ассоциации приложения с типом файлов в реестре Windows.
3. Убедитесь, что включена политика Client drive redirection в разделе User policy либо для фермы в целом, либо для сервера, либо для группы пользователей.

Раздел 6: Дополнительное управление

6.1 - Делегирование административных прав

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-admin-acct-mgmt-wrapper-v2.html
Для создания дополнительных административных учетных записей в Citrix AppCenter в меню слева есть нода Administrators.
Для создания админа - кликнуть правой кнопкой и выбрать Add Administrator.
Затем выбрать пользователя или группу, затем задать уровень привилегий - View only, Full Administration или Custom.
При выборе Custom можно назначить специальные права.

6.2 - Журналирование изменений конфигурации фермы

Эта функция предназначена для протоколирования изменений, вносимых в конфигурацию фермы. В специальную базу данных заносятся изменения конфигурации, сделанные как с помощью Citrix AppCenter, так и с помощью утилит командной строки и утилит, входящих в состав SDK.
Перед включение этой функции следует:
- Определить уровень безопасности и контроля журнала. Например, будут ли запрашиваться учетные данные перед очисткой логов.
- Определить как строго будут протоколироваться события конфигурирования. Например - будет ли разрешено внесение изменений в конфигурацию фермы, если эти изменения нельзя внести в протокол (например при отключенной базе данных журнала).

ВАЖНО: Для безопасного хранения учетных данных от базы данных журнала, при конфигурировании фермы следует включать шифрование IMA (IMA encryption feature). После включения этой функции её невозможно отключить, не потеряв зашифрованные данные. Citrix рекомендует конфигурировать шифрование IMA до настройки и использования функции журналирования.

Для включения журналирования:
- СОздайте базу данных журнала.
- Создайте учетные данные для доступа к базе журнала.
- Сконфигурируйте подключение к базе данных.
- Задайте параметры журналирования
- Делегируйте административные права

После включения, функция журналирования работает в фоне. Пользователь может инициировать только генерацию отчетов, очистку баз данных журнала и отображение опций журналирования.

Для создания отчета используется команда PowerShell Get-CtxConfigurationLogReport. Дополнительную информацию можно найти в справке команды Get-CtxConfigurationLogReport .

Администраторы, обладающие полными административными правами (Full Citrix administrators) могут изменять настройки журналирования и очищать журнал, а также делегировать эти права другим администраторам (опция разрешений Edit Configuration Logging Settings).

Включение журналирования

- В AppCenter кликните правой кнопкой по ферме.
- Выберите свойства фермы (Farm properties).
- Кликните Configuration Logging.
- Сконфигурируйте доступ к базе данных Configure Database….
- Включите журналировани с помощью чекбокса Log administrative tasks to Configuration Logging database .
- Для разрешения внесения изменений в конфигурацию фермы при отключенной базе журнала отметььте чекбокс Allow changes to the farm when logging database is disconnected .
- Для запроса учетных данных администратора перед очисткой журнала отметьте чекбокс Require administrators to enter database credentials before clearing the log .

Очистка журнала

Для очистки журнала используйте один из нижеприведенных способов:
- В AppCenter разверните ферму, выберите History. Выберите Clear history в меню Actions.
- Используйте команду PowerShell Clear-XAConfigurationLog. За дополнительной информацийе обращайтесь к справке команды Clear-XAConfigurationLog

6.3 - Утилиты командной строки

Утилита DSMAINT

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-commands-dsmaint-v2.html
Команда dsmaint может быть выполнена на серверах, входящих в состав фермы и предназначена для работы с хранилищем конфигурации (data store).
В том числе - резервного копирования хранилища, миграции на новый сервер, сжатия базы данных хранилища и других операций. Не все команды утилиты dsmaint применимы ко всем типам базы данных хранилища.
При использовании этой команды следует учитывать регистр символов при вводе имен и паролей.

Синтакс:

dsmaint config [/rade] [/user:username] [/pwd:password] [/dsn:filename]

dsmaint backup destination_path 

dsmaint compactdb [/lhc]

dsmaint migrate [{/srcdsn:dsn1 /srcuser:user1 /srcpwd:pwd1}] [{/dstdsn:dsn2 /dstuser:user2
 /dstpwd:pwd2}]

dsmaint publishsqlds {/user:username /pwd:password}

dsmaint recover

dsmaint recreatelhc

dsmaint recreaterade

dsmaint verifylhc [/autorepair]

dsmaint [/?]

Параметры:

destination_path
Локальный путь к файлу бекапа базы данных data store. Не используйте такой же путь при указании оригинальной базы.
dsn1
Имя файла DSN с указанием исходной (source) базы данных data store.
dsn2
Имя файла DSN с указанием конечной (destination) базы данных data store.
filename
Имя data store.
password
Пароль для подключения к data store.
pwd1
Пароль для подключения к исходной (source) базе data store.
pwd2
Пароль для подключения к конечной (destination) базе data store.
user1
Имя пользователя для подключения к исходной (source) базе data store.
user2
Имя пользователя для подключения к конечной (destination) базе data store.
username
Имя пользователя для подключения к базе data store.

Опции запуска

config
Изменяет параметры, используемые для доступа к data store. Введите полный путь к файлу DSN в кавычках.

dsmaint config /user:ABCnetwork\administrator /pwd:Passw0rd101
    /dsn:"C:\Program Files (x86)\Citrix\Independent Management Architecture\mf20.dsn"

Перед запуском с параметром /pwd следует остановить Citrix Independent Management Architecture.
^ВНИМАНИЕ! Указывайте /dsn в параметрах dsmaint config, в противном случае нужно будет изменить security context для доступа к базе SQL Server или Oracle.^
/rade
Compacts the offline data store.
/user:username
The user name to connect to a data store.
/pwd:password
The password to connect to a data store.
/dsn:filename
The filename of an IMA data store.

backup
Создает резервную копию data store, размещенную в SQL Server Express, устанавливаемом по-умолчанию при установке XenApp. Запускать эту команду следует на сервере, на котором размещен data store. Необходимо задать путь к локальной папке, в которую будет скопирована резервная копия. Не следует использовать эту команду для резервного копирования data store, размещенного на сервере SQL Server или Oracle.
ВНИМАНИЕ! Указание той же папки, в которой лежит исходная база при запуске dsmaint backup может необратимо повредить data store.

compactdb
Сжимает файл базы данных. Во время процесса сжатия база недоступна ни на чтение, ни на запись. Время сжатия может быть от нескольких секунд, до нескольких минут, в засисимости от размера и интенсивности использования.

/lhc
Сжимает локальный кеш хоста фермы. Следует периодически запускать dsmaint /lhc при длительной работе фермы.

migrate
Migrates data from one data store database to another. Run this command on any XenApp server that has a connection to the data store. Use this command to move a data store to another server, rename a data store in the event of a server name change, or migrate the data store to a different type of database (for example, migrate from SQL Server Express to SQL Server).
To migrate the data store to a new server:

Prepare the new database server using the steps you did before running XenApp Setup for the first time.
Create a DSN file for this new database server on the server where you will be running dsmaint migrate.
Run dsmaint migrate on any server with a connection to the data store.
Run dsmaint config on each server in the farm to point it to the new database.

/srcdsn:dsn1
The name of the data store from which to migrate data.
/srcuser:user1
The user name to use to connect to the data store from which the data is migrating.
/srcpwd:pwd1
The password to use to connect to the data store from which the data is migrating.
/dstdsn:dsn2
The name of the data store to which to migrate the data.
/dstuser:user2
The user name that allows you to connect to the data store to which you are migrating the source data store.
/dstpwd:pwd2
The password that allows you to connect to the data store to which you are migrating the source data store.

publishsqlds
Publishes a SQL Server data store for replication. Run publishsqlds only from the server that created the farm. The publication is named MFXPDS.

recover
Restores a SQL Server Express data store to its last known good state. Run this directly on the server while the Citrix Independent Management Architecture service is not running.

recreatelhc
Recreates the local host cache database. Run if prompted after running dsmaint verifylhc. After running dsmaint recreatelhc, restart the IMA Service. When the IMA Service starts, the local host cache is populated with fresh data from the data store.

recreaterade
Recreates the application streaming offline database. Run as a troubleshooting step if the Citrix Independent Management Architecture service stops running and the local host cache is not corrupted.

verifylhc
Verifies the integrity of the local host cache. If the local host cache is corrupt, you are prompted with the option to recreate it. With the verifylhc /autorepair option, the local host cache is automatically recreated if it is found to be corrupted. Alternatively, you can use dsmaint recreatelhc to recreate the local host cache.

/?
Displays the syntax and options for the utility.

Примечание

После запуска dsmaint, рекомендуется запускать dscheck для проверки состояния XenApp data store.

Команды dsmaint config и dsmaint migrate следует запускать только пользователю с нужными правами доступа к базе.

Утилиты командной строки для стримминга приложений

CLIENTCACHE
Эта утилита используется для изменения максимального размера и места хранения кэша клиента. По-умолчанию, если приложение доставляется стриммингом, то изолированное окружение распаковывется и хранится в папке \Program Files\Citrix\RadeCache, а максимальный размер составляет 1024 мегабайт (MB). Эта утилита запускается на компьютере клиента и располагается в папке \Program Files\Citrix\Streaming Client. Для запуска - перейдите в эту даиректорию и кликните clientcache.exe.

Дополнительную информацию можно найти в http://support.citrix.com/article/CTX112526.

DSMAINT RECREATERADE
Эта утилита используется для воссоздания базы данных клиентских лицензий на сервере XenAPp. База данных называется radeoffline.mdb и лежит в папке \Program Files\Citrix\Independent Management Architecture . Эта база данных присутствует на каждом сервере XenApp в ферме и входит в комплект установки. Для запуска этой утилиты следует остановить службу Citrix Independent Management Architecture , открыть командную строку и выполнить dsmaint recreaterade .

RADECACHE
Эта утилита используется для очистки кэшированных файлов и записей реестра на компьютере клиента. Для запуска - в окне командной строки перейдите в папку \Program Files\Citrix\Streaming Client и выполните команду с таким синтаксисом:
radecache options /flush:”<appname>”

Options for this command:
-i = очистить файлы инсталляции и записи реестра
-if = очистить только файлы инсталляции
-ir = очистить только записи реестра инсталляции
-u = очистить файлы пользователя и записи реестра
-uf = очистить файлы пользователя
-ur = очистить записи реестра пользователя

Пример:
radecache –i /flush:“adobe”

RADEDEPLOY
Утилита используется для предварительной доставки приложений. Эта процедура помогает избежать черезмерной нагрузки на хранилище профилейи приложений и сеть. Во время предварительной доставки, файлы профиля извлекаются и затем исполняются локально и папки \Program Files\Citrix\Deploy. Утилита располагается на диске дистрибутива XenApp и для использования ее надо скопировать в папку, куда установлен Streaming Client. Для запуска используется следующий синтаксис:
radedeploy -m /deploy:“\\server\share\app.profile”

Указывается имя файла профиля .profile . Если оно имеет пробелы, то должно быть заключено в кавычки.
-m - позволяет следить за ходом деплоя.

radedeploy /enum
radedeploy /delete:BrowserName
Эта команда используется для удаления приложения из папки \Program Files\Citrix\Deploy . BrowserName соответсвует имени приложения, которое можно найти выполнив radedeploy /enum .

Примеры:

radedeploy /deploy:\\2003Server\packages\adobe\adobe.profile
radedeploy /delete:Adobe

RADEMAINT OFFLINELICENSE
Эта утилита используется для управления streaming offline licenses. Она расположена на диске с дистрибутивом XenApp в папке \Support\debug . Скопируйте её на сервер и используйте следующий синтаксис:

Rademaint OFFLINELICENSE
/r:username – удаляет offline лицензию для указанного пользователя.
/l:username (or *) – выводит список лицензий указанного пользователи или для всех *
/s – выводит список всех сессий из кэша сессий.

Пример:
Rademaint OFFLINELICENSE /r:user1

Определение состояния серверов фермы - '''QUERY FARM'''

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-commands-query-farm-v2.html

Команда query используется для выводи информации о серверах фермы и фермах.

Синтакс:

 query farm server [/addr | /app | /app appname | /load | /ltload]

query farm [ /tcp ] [ /continue ]

query farm [ /app | /app appname | /disc | /load | /ltload | /lboff | /process]

query farm [/online | /online zonename]

query farm [/offline | /offline zonename]

query farm [/zone | /zone zonename]

query farm [/?]

Параметры
appname
The name of a published application.
server
The name of a server within the farm.
zonename
The name of a zone within the farm.

Options

farm
Displays information about servers within an IMA-based server farm. You can use qfarm as a shortened form of query farm.
server /addr
Displays address data for the specified server.
/app
Displays application names and server load information for all servers within the farm or for a specific server.
/app appname
Displays information for the specified application and server load information for all servers within the farm or for a specific server.
/continue
Do not pause after each page of output.
/disc
Displays disconnected session data for the farm.
/load
Displays server load information for all servers within the farm or for a specific server.
/ltload
Displays server load throttling information for all servers within the farm or for a specific server.
/lboff
Displays the names of the servers removed from load balancing by Health Monitoring & Recovery.
/process
Displays active processes for the farm.
/tcp
Displays TCP/IP data for the farm.
/online
Displays servers online within the farm and all zones. The data collectors are represented by the notation “D.”
/online zonename
Displays servers online within a specified zone. The data collectors are represented by the notation “D.”
/offline
Displays servers offline within the farm and all zones. The data collectors are represented by the notation “D.”
/offline zonename
Displays servers offline within a specified zone. The data collectors are represented by the notation “D.”
/zone
Displays all data collectors in all zones.
/zone zonename
Displays the data collector within a specified zone.
/?
Displays the syntax for the utility and information about the utility’s options.

Remarks

Запрос Query farm возвращает сведения о IMA-based северах фермы.

Для выполнения запросов Query farmнужно входить в группу Citrix administrators.

Проверка состояния data storage DSCHECK

Команда dscheck используется для проверки и восстановления целостности базы данных data storage. Как правило dscheck необходимо выполнять после запуска dsmaint.

Синтакс:

dscheck clean mainpage

Параметры:

/clean - Утилита попытается исправит найденные ошибки и восстановить целостность базы

/? - Вывод справки

Примечания
Dscheck выполняет ряд тестов, для проверки целостности хранилища фермы. При запуске без параметров выполняется только тестирование базы. Запускать dscheck следует на сервере, имеющем прямой доступ к хранилищу data store.

При запуске с параметром /clean , утилита выполняет тестирование и удаляет некорректные записи (обычно о серверах и приложениях) из базы. Так как вносимые изменения влияют на работоспособность фермы, перед запуском следует выполнять резервное копирование базы.

При запуске с параметром /clean вероятно понадобится обновить локальный кэш на каждом сервере фермы с помощью команды dsmaint с параметром recreatelhc . Запуск этой команды устанавливает параметр реестра PSRequired в значение 1 в ключе HKLM\SOFTWARE\Wow6432Node\Citrix\IMA\RUNTIME или HKLM\SOFTWARE\Citrix\IMA\RUNTIME для 32-бит систем.

Dscheck сообщает результаты в журнал Windows и в окно командной строки. Кроме того, вывод можно направить в файл.

Также обновляются некоторые значения параметров монитора производительности, в том числе счетчик ошибок, счетчик ошибок приложений, ошибок групп и общий флаг, указывающий на наличие ошибок.

dscheck возвращает код ошибки “ноль”, при отсутствии ошибок и код ошибки, при их наличии.

Dscheck сканирует преимущественно три группы объектов: серверы, приложения и группы. тесты выполняются как для каждой группы объектов, так и для отдельных записей.

Примеры:

Только проверка целостности:
dscheck

Проверка и исправление ошибок:
dscheck /clean

6.4 - Управление профилями пользователей

http://support.citrix.com/proddocs/topic/user-profile-manager-sou/upm-use-cases.html

Citrix Profile management предназначен для управления профилями пользователей при разных сценариях использования, не зависимо от того как доставляются приложения. Вот примеры таких сценариев:

Citrix XenApp with published applications

Citrix XenApp with published desktops

Citrix XenApp with applications streamed into an isolation environment

Applications streamed to XenDesktop virtual desktops

Applications installed on XenDesktop virtual desktops

Applications streamed to physical desktops

Applications installed locally on physical desktops

Вероятны следующие варианты:

Проблема множественных сессий. Пользователь получает доступ к нескольким серверам XenApp и таким образом работает в нескольких открытых сессиях.
Проблема “последней записи” и перемещаемые профили. Вследствие того, что последняя запись в профиль пользователя перезаписывает все настройки профиля, в перемещаемый профиль могут не сохраниться данные из нескольких открытых сессий, т.к. они будут перезаписан “последней записью”. Кроме того, данные могут не быть записаны в результате сбоя сети или хранилища.
Проблема большого размера профиля. При большом размере профиля требуется время для его скачивания на компьютер пользователя, а это увеличивает время входа.

Множественные сессии

В крупных инсталляциях бывает необходимо, чтобы у пользователя было открыто несколько сессий на разных серверах, например - для одновременного доступа к приложениям, опубликованным на разных серверах или даже в разных фермах.

Там, где возможно, Citrix рекомендует изолировать приложения (стриммить) и пытаться сделать так, чтобы все приложения пользователя размещались на одном сервере и у каждого пользователя при работе была только одна сессия.
Если выясняется, что пользователям придется иметь более одной сессии, то нужно подготовить к этому профили.

Например. Пользователь запускает приложения AppA, AppB и AppC и подключается к Server 1, Server 8 и Server 12 соотвественно. При входе на каждый сервер, профиль пользователя скачивается на сервер и папки перенаправляются в сессию каждом сервере. При работе с приложением AppA на Server1, пользователь меняет Setting1 и завершает сессию. Затем завершает сессии с другими приложениями.

При выходе, изменения, сделанные в сессии на Server 1 перезаписываются настройками из сессий других серверов. При последующем открытии приложения AppA, пользователь не увидит изменений настроек, т.к. они были перезаписаны.
Profile management может решить большую часть таких проблем. Profile management позволяет записывать только конкретные изменения в профиль, а не перезаписывать его целиком. Таким образом, вероятным остается только конфликт, когда параметр Setting1 будет изменен в двух сессиях одновременно. Хотя и в этом случае, при использовании Profile management будут сохранены последние изменения.

Проблема "последней записи" и целостность перемещаемых профилей

Этот сценарий аналогичен множественным сессиям. Проблемы “последней записи” могут возникать по разным причинам и могут обостряться по мере роста количества клиентских устройств, которые использует пользователь.
Из-за того, что в перемещаемыом профиле перезаписываются все пользовательские данные, за исключением перенаправленных папок, размер профиля может расти довольно быстро. Таким образом не только увеличивается время входа в систему и выхода из нее, но и возрастает вероятность повреждения профиля, особенно в случае нестабильной сети.
Profile management позволяет выделить из профиля необходимые часто обновляемые данные и таким образом уменьшить размер профиля до минимального размера. Благодаря тому, что в профиль записываются только изменения, время требуемое для выхода пользователя из системы существенно сокращается. Profile management может быть очень полезен для приложений, которые используют профили для хранения временных данных, но не удаляют их при закрытии приложения.

О типах профилей

http://support.citrix.com/proddocs/topic/user-profile-manager-sou/upm-about-profiles.html

Профиль пользователя Windows - это набор папок, файлов, записей реестра, и параметров конфигурации, которые задают параметры пользовательского окружения при входе в систему с конкретной учетной записью. Эти параметры могут быть настроены пользователем, в соответствии с административными установками. Примеры конфигурируемых параметров:

Настройки рабочего стола - фон и заставка.
Ярлыки и параметры меню “Пуск”.
Папка “Избранное” и домашняя страница обозревателя
Подпись Microsoft Outlook
Принтеры

Некоторые параметры могут быть переданы средствами перенаправления папок, но если перенаправление папок отключено, то параметры будут сохраняться в профиле.

Типы профилей:

Локальный. Данные хранятся на локальном устройстве. Конфигурация хранится на локальном устройстве. Приложения хранят данные только на локальном устройстве. Изменения сохраняются.

Перемещаемый (Roaming). Данные хранятся на сетевом ресурсе. Параметры конфигурации хранятся в Active Directory. Приложения хранят данные на любом доступном ресурсе. Изменения сохраняются.

Принудительный (Mandatory Roaming). Данные хранятся на сетевом ресурсе. Параметры конфигурации хранятся в Active Directory. Приложения хранят данные на любом доступном ресурсе. Изменения НЕ сохраняются.

\\

Временный (Temporary). Данные нигде не хранятся. Параметры нигде не хранятся. Приложения хранят данные только на локальном устройстве. Изменения НЕ сохраняются.
Временный профиль используется только в случаях, когда никакой другой тип профиля не может быть использован. У каждого пользователя есть свой отдельный профиль, за исключением случаев, когда используются принудительные профили (Mandatory Roaming), которые не позволяют пользователям сохранять изменения.
Если пользователь работает со Службами удаленного рабочего стола (Remote Desktop Services) и в то же время работает локально, то во избежание конфликтов между профилем, используемым в локальной сессии и профилем, используемым в сессии RDP, для сессий RDP могут быть назначены либо специально созданные перемещаемые (roaming), либо принудительные (mandatory) профили.

Версии профилей - Version 1 и Version 2

Профили, используемые в Microsoft Windows XP и Windows Server 2003 известны как профили версии 1 (Version 1). Пофили в Windows Vista, Windows 7, Windows Server 2008 и Windows Server 2008 R2 имеют версию 2 (Version 2). Структура папок этих версий профилей различается.

В более новых операционных системах структура папок профиля была изменена для того чтобы изолировать данные пользователя и данные приложений. Профили версии 1 хранили данные в корневой папке Documents and Settings. Профили версии 2 хранят данные в более интуитивно понятной папке Users. Например содержимое папки AppData\Local в Windows Vista это тоже самое что Documents and Settings\<username>\Local Settings\Application Data в Windows XP.

For more information about the differences between Version 1 and Version 2 profiles, see

Раздел 7. Мониторинг и управление распределением нагрузки

7.1 - Оценщики нагрузки - Default, Advanced и Custom

http://support.citrix.com/proddocs/topic/xenapp65-admin/lm-wrapper-v2.html
Для эффективного использования ресурсов фермы, в состав XenApp вхояд средства мониторинга и оценки нагрузки.
XenApp расчитывает нагрузку на серверы с помощью оценщиков (evaluators) и правил. Каждый оценщик нагрузки содердит одно или более правил. Каждое правило задает диапазон рабочих параметров для сервера или приложения, к которым привязан оценщик.

В состав XenApp входят следующие типы оценщиков нагрузки:

Default (по-умолчанию) - XenApp привязывает данный тип оценщика к каждому серверу. Этот оценщик содержит два правила - Server User, которое сообщает о полной нагрузке при входе 100 на сервер и Load Throttling, который задает какую долю нагрузки на сервер могут составлять процедуры входа и ограничивает количество одновременно входящих пользователй на сервер.
Advanced - Этот оценщик нагрузки содержит правила, которые задают предельную нагрузку на процессор, на использование памяти, на использование файла подкачки и регуляторы нагрузки (Load Throttling).

При запуске приложения пользователем, клиент Citrix связывается с сервером фермы и получает адрес сервера, на котором есть нужное приложение. XenApp поддерживает в актуальном состоянии список опубликованных приложений и серверов фермы и при получении запроса от клиента, XenApp выбирает наименее загруженный сервер и возвращает его адрес клиенту. Клиент запускает сессию на выбранном сервере и запускает приложение.
XenAPp вычисляет нагрузку на сервер используя оценщики нагрузки, привязанные к серверу или приложению. Если хотя бы по одному правилу из привязанных оценщиков сервер оказывается полностью нагруженным (превышаются заданные лимиты), XenApp исключает этот сервер из списка серверов, доступных клиентам. Следующий запрос клиента на соединение ICA перенаправляется к следующему доступному серверу из списка.

Работа с оценщиками нагрузки
Для начала работы c оценщиками нагрузки в AppCenter следует выбрать ноду Load Evaluators в левой панели. Откроются следующие вкладки:
Load Evaluators - отображает список всех оценщиков нагрузки, созданных для данной фермы. При выборе какого-либо оценщика, внизу появляются сведения о текущих правилах, входящих в его состав.
Usage by Application - отображает оценщики, привязанные к приложениям, опубликованным на ферме.
Usage by Server - отображает оценщики, привязанные к серверам фермы.

Примечания:
При использовании оценщиков нагрузки следует учитывать следующее:

- Изменять установленные по-умолчанию оценщики Default и Advanced нельзя ни удалить, ни изменить.
- Нельзя удалить или изменить существующие правила (в оценщиках по-умолчанию). Также нельзя создать дополнительные правила.
- Каждому серверу или приложению можно привязать только один оценщик производительности.
- Для привязки оценщиков нагрузки используется механизм Групповой политики. Оценщики нагрузки можно привязывать к отдельным приложениям.
- Каждый сервер фермы XenApp учитывается при балансировке нагрузки до того момента, как он сообщит о полной нагрузке. Если сервер сообщает о полной загрузке, он исключается из механизма балансировки, до того момента, как нагрузка не него не снизится. После снижения нагрузки сервер автоматически возвращается в список доступных серверов. Таким образом, сервера постоянно исключаются и добавляются в список доступных по мере изменения нагрузки на ферму.

Список правил оценщиков нагрузки

http://support.citrix.com/proddocs/topic/xenapp65-admin/lm-rules-list.html

В XenApp используются следующие правила для оценки нагрузки:

Application User Load - Ограничивает количество пользователей, которым разрешено подключаться к данному опубликованному приложению. Это правило следит за количеством активных сессий ICA, в которых запущено приложение. По умолчанию, о полной нагрузке сообщается, когда 100 пользователей используют приложение.

Context Switches - Задает диапазон количества переключений контекста в секунду для данного сервера. Переключение контекста происходит когда операционная система переключается с одного процесса на другой. Значение по-умолчанию для полной нагрузки составляет 16000. При значениях ниже 900 это правило игнорируется. Для получения данных это правило использует системный счетчик прозводительности - System: Context Switches/sec .

CPU Utilization - Задает диапазон загрузки процессора сервера. По-умолчанию о полной загрузке сообщается при загрузке 90 процентов. Правило игнорируется при загрузке 10 и менее процентов. Это правило использует системный счетчик производительности - Processor: % Processor Time .

Disk Data I/O - Задает диапазон скорости передачи данных в килобайтах в секунду. По-умолчанию полной загрузке соответствует скорость 32767 килобайт в секунду. Правило игнорируется при скорости 0 килобайт в секунду. Это правило использует системный счетчик производительности PhysicalDisk: Disk Bytes/sec .

Disk Operations
Defines a range of disk operation, in read/write cycles per second, for a selected server. The default full load value is 100 operations per second. The default no load value is 0—at that value this rule is ignored. This rule uses the PhysicalDisk: Disk Writes/sec and Disk Reads/sec performance counters to determine load.

IP Range
Defines a range of allowed or denied client IP addresses for a published application. It controls access to a published application based on the IP addresses of the clients. You can define ranges of IP addresses, then select to allow or deny access if the client IP addresses are within the defined ranges.

This rule must be used in conjunction with another.

Load Throttling
Limits the number of concurrent connection attempts that a server handles. This prevents the server from failing when many users try to connect to it simultaneously. The default setting (High impact) assumes that logons affect server load significantly. This rule affects only the initial logon period, not the main part of a session.

The Load Throttling rule can be applied only to a server, not to an individual application.

Memory Usage
Defines a range of memory usage by a server. The default full load value is 90. The default no load value is 10—at that value this rule is ignored. This rule uses the Memory: % Committed Bytes in Use performance counter to determine load.

Page Fault
Defines a range of page faults per second for a selected server. A page fault occurs when the operating system tries to access data that was moved from physical memory to disk. The default full load value is 2000. The default no load value is 0—at that value this rule is ignored. This rule uses the Memory: Page Faults/sec performance counter to determine load.

Page Swaps
Defines a range of page swaps per second for a selected server. A page swap occurs when the operating system moves data between physical memory and the swap file. The default full load value is 100. The default no load value is 0—at that value this rule is ignored. This rule uses the Memory: Pages/sec performance counter to determine load.

Scheduling
Schedules the availability of selected servers or published applications. This rule sets the weekly days and hours during which the server or published application is available to users and can be load managed.

Server User Load
Limits the number of users allowed to connect to a selected server. The default full load value is 100 and represents the maximum number of users the system can support on a server. Load Manager user loads are calculated using active ICA sessions only.

7.2 - Привязка оценщиков нагрузки к приложению или серверу

http://support.citrix.com/proddocs/topic/xenapp65-admin/lm-using-attach-loadval-all.html

Для управления нагрузкой, к каждому серверу и каждому приложению должен быть привязан оценщик нагрузки. К каждому серверу или приложению можно привязать только единственный оценщик нагрузки.

Для того чтобы привязать к серверу XenApp оценщик нагрузки нужно сконфигурировать политику, содержащую параметр Load Evaluator Name, в котором указано имя используемого оценщика нагрузки, а затем установить фильтр по worker group или по серверу, куда входит сервер. Назначить можно люоой оценщик нагрузки, сконфигурированный для фермы.
Например, если есть опубликованное приложение, которое использует значительный объем памяти сервера и вычислительных ресурсов, то к политике можно добавить параметр Load Evaluator Name, указав Advanced load evaluator и установить фильтр по worker group, в который входят все сервера XenApp, на которых опубликовано данное приложение. В результате, XenApp распределит доступную память и вычислительные мощности в зависимости от потребностей.

Во время работы с оценщиками нагрузки, XenApp не проверяет имя оценщика в момент применения его параметров к сессии пользователя. Таким образом, если оценщик нагрузки впоследствии будет переименован или удален, то оценка нагрузки производиться не будет, а в журнале будет зафиксирована ошибка и сервера, попавшие в такую ситуацию будут сообщать о полной загрузке (индекс загрузкти будет равен 10000). Кроме того, вкладка Usage by Server в разделе Load Evaluators не показывает, что оценщик нагрузки привязан. Для того чтобы убедиться, что в политике указано правильное имя оценщика нагрузки нужно отредактировать параметр политики Load Evaluator Name и указать имя оценщика.

Если указанный в настройках политики оценщик удален и никакой другой политики с указанием оценщика не задано, то XenApp будет применять Default load evaluator.

Для того чтобы привязать оценщик нагрузки к серверу:
- Создайте новую политику Computer policy или выберите существующую.
- В списке параметров найдите Load evaluator name (в разделе Server Settings) и кликните Add.
- Из выпадающего списка выберите оценщик нагрузки и кликните ОК.
- Добавьте фильтр по Worker Group и укажите worker group, в который входят серверы, которым привязываем оценщика.

Для того чтобы привязать оценщик нагрузки к опубликованному приложению:
- В AppCenter в левой части окна выберите раздел Applications.
- Выберите опубликованное приложение, к которому надо привязать оценщик нагрузки.
- На панели действий (справа) или кликнув правой кнопкой по приложению, в меню Other Tasks выберите Attach application to load evaluator.
- В диалоговом окне выберите необходимый оценщик нагрузки.

8.3 - Установка новых драйверов принтеров.

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-printing-network-configuring.html
В случае отсутствия драйвера принтера на сервере его не удастся автоматически прописать в сессии пользователя.
Добавить драйвер принтера в Windows можно так:
- Установить принтер вручную, с помощью мастера Добавление принтера, либо обнаружив принтер на соответствующем сервере в Проводнике, дважды кликнув по нему. Драйвер принтера установится в локальное хранилище драйверов Windows.

Раздел 9. Включение безопасного Web-доступа к опубликованным приложениям

9.1 Конфигурирование обработки отказов и дополнительных параметров в настройках WEb-интерфейса (WI)

Конфигурирование обработки отказов

http://support.citrix.com/proddocs/topic/web-interface-impington/wi-configure-fault-tolerance-gransden.html
We-интерфейс предусматривает обработку отказов серверов фермы, на которых исполняется Citrix XML Service, перечисляющий опубликованные приложения. В консоли Citrix Web Interface Management в правой части окна расположен список задач. обработка отказов настраивается в задаче Server Farms. В случае невозможности соединиться с заданным сервером, WI отложит попытки связи с вышедшим из строя сервером на время, указанное в параметре Bypass any failed server for и будет пытаться соединиться с другими серверами, указанными с списке.
По-умолчанию, отказавший сервер не опрашивается в течение часа. Если вышили из строя все серверы, указанные в списке - Web-Интерфейс XenApp будет повторять попытки соединиться каждые 10 секунд.
Чтобы настроить обработку отказов Citrix XML Service:
- Запустите консоль Citrix Web Interface Management (Пуск > Все программы > Citrix > Management Consoles > Citrix Web Interface Management)
- В левой части окна консоли выберите тип сайта - XenApp Web Sites или XenApp Services Site и выберите настраиваемый сайт.
- В панели справа кликните Server Farms.
- Выберите настраиваемую ферму и кликните Edit, или добавьте новую - Add.
- В списке серверов с помощью кнопок Move Up и Move Down расположите сервера, на которых исполняется Citrix XML Service, в порядке приоритета.
- В поле Bypass any failed server for задайте время, на которое отказавший сервер будет исключен из списка опрашиваемых.

Дополнительные параметры

http://support.citrix.com/proddocs/topic/web-interface-impington/wi-specify-advanced-settings-gransden.html
Среди дополнительных параметров можно настроить опрос сокетов - socket pooling и перенаправление контента - content redirection, указать тайм-аут Citrix XML Service и количество попыток получить данные от Citrix XML Service, прежде чем признать отказ сервиса.

Включение опроса сокетов - '''socket pooling'''

При включении опроса сокетов - socket pooling, WI поддерживает определенный пул созданных сокетов, всесто того, чтобы создавать сокет при каждом новом подключении. Включение socket pooling повыщает производительность, особенно при использовании SSL.
Socket pooling поддерживается только для сайтов, на которых настроена аутентификация At Web Interface или At Access Gateway. На таких сайтах Socket pooling включен по-умолчанию. Socket pooling не следует включать, если WI настроен на работу с XenApp for UNIX.
Чтобы настроить Socket pooling:
- Запустите консоль Citrix Web Interface Management (Пуск > Все программы > Citrix > Management Consoles > Citrix Web Interface Management)
- В левой части окна консоли выберите тип сайта - XenApp Web Sites или XenApp Services Site и выберите настраиваемый сайт.
- В панели справа кликните Server Farms.
- Нажмите кнопку Advanced.
- Поставьте (чтобы включить) или снимите галочку в поле Socket pooling.

To enable content redirection
You can use the Server Farms task in the Citrix Web Interface Management console to enable and disable content redirection from plug-in to server for individual XenApp Services sites. This setting overrides any content redirection settings configured for XenApp.

When you enable content redirection from plug-in to server, users running the Citrix online plug-in open online content and local files with applications delivered from servers. For example, a Citrix online plug-in user who receives an email attachment in a locally running email program opens the attachment in an online application. When you disable content redirection, users open online content and local files with locally installed applications.

By default, content redirection is enabled from plug-in to server for XenApp Services sites.

You configure content redirection from plug-in to server by associating applications with file types. For more information about file type association, see XenApp Administration.

On the Windows Start menu, click All Programs > Citrix > Management Consoles > Citrix Web Interface Management.
In the left pane of the Citrix Web Interface Management console, click XenApp Services Sites and select your site in the results pane.
In the Action pane, click Server Farms.
Click Advanced.
In the Content Redirection area, select the Enable content redirection check box.
To configure Citrix XML Service communication
By default, contact with the Citrix XML Service times out after one minute and the service is considered failed after two unsuccessful attempts are made to communicate with it. You can change these default settings using the Server Farms task in the Citrix Web Interface Management console.

On the Windows Start menu, click All Programs > Citrix > Management Consoles > Citrix Web Interface Management.
In the left pane of the Citrix Web Interface Management console, click XenApp Web Sites or XenApp Services Sites, as appropriate, and select your site in the results pane.
In the Action pane, click Server Farms.
Click Advanced.
To configure the Citrix XML Service time-out duration, enter appropriate values in the Socket timeout boxes.
To specify how many attempts are made to contact the Citrix XML Service before it is considered failed and is bypassed, enter a value in the Attempts made to contact the XML Service box.

Раздел 8: Конфигурирование печати

8.1 - Драйверы принтеров

Какой драйвер принтера использовать?(UPD, native, other)

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-console-policies-universal-printing.html

Политики печати - Universal Printing Policy Settings

В данном разделе описаны параметры политик, используемые для настройки печати.

Universal printing EMF processing mode

Этот параметр определяет метод обработки файла EMF spool на пользовательском устройстве Windows. По-умолчанию, записи EMF направляются сразу на принтер.
Этот параметр имеет следующие варинты значений:

Reprocess EMFs for printer - предписывает принудительно обрабатывать файл EMF и посылать его на принтер через подсистему GDI пользовательского устройства. Этот параметр можно использовать с драйверами, которые требуют постобработки EMF, но могут не быть автоматичсеки выбраны в сессии.
Spool directly to printer - при использовании Citrix Universal Printer driver, обеспечивает помещение в очередь и перердачу данных EMF на пользовательское устройство для последующей обработки. Обычно файлы EMF направляются напрямую в очередь печати клиентского устройства. Для устройств поддерживающих формат EMF этот метод обеспечивает наибольшее быстродействие.

Universal printing image compression limit

Этот параметр задает максимальное качество и минимальный уровень сжатия для изображений, печатаемых через Universal Printer driver. По-умолчанию уровень сжатия установлен в значение Best quality (lossless compression). Если выбрано значение No Compression , то сжатие отключено только для печати через EMF.

Параметр имеет следующие варианты значений:
No compression
Best quality (lossless compression)
High quality
Standard quality
Reduced quality (maximum compression)

При добавлении этого параметра к политике следует учитывать следующее:
- Если уровень сжатия в параметре Universal printing image compression limit меньше, чем уровень сжатия, заданный в Universal printing optimization defaults , то используется уровень сжатия заданный в Universal printing image compression limits .
- Если сжатие отключено, то параметры Desired image quality и Enable heavyweight compression в памаетре политики Universal printing optimization defaults не действуют.

Universal printing optimization defaults

Эта политика задает параметры по-умолчанию для оптимизации печати, если в сессии используется драйвер Universal Printer.

Desired image quality - задает уровень сжатия для universal printing. По-умолчанию устанавливается значение Standard Quality, что позволяет печатать со сжатием, обеспечивающим стандартное или более низкое качество. При этом, параметр Universal printing image compression limit перекрывает данные значения. Например - если по-умолчанию задано Best Quality, а Universal printing image compression limit установлен в значение Standard Quality, пользователи смогу печатать только со стандартным качеством или ниже стандартного.
Enable heavyweight compression - включает или отключает мощный алгоритм сжатия без потери качества. По-умолчанию - отключено.
Image and Font Caching - параметр включает или отключает кеширование часто встречающихся изображений и шрифтов, предотвращая многократную передачу часто используемых фрагментов. По-умолчанию - встроенные изображения и шрифты кешируются. Этот параметр работает только с устройствами, поддерживающими данную функцию.
Allow non-administrators to modify these settings - разрешает или запрещает пользователям изменять настройки уровня оптимизации при печати в сессии. По-умолчанию - пользователям не разрешается менять настройки.

Примечание - Эти параметры поддерживаются при печати EMF. При печати XPS работает только параметр Desired image quality .

Universal printing preview preference

Этот параметр политики разрешает или запрещает использование функции предпросмотра для автоматически создаваемых universal printers. По-умолчанию - предпросмотр для автоматически созданных принтеров не используется.

При добавлении этого параметра в политику следует выбрать одну из опций:

Do not use print preview for auto-created or generic universal printers - Не использовать предпросмотр
Use print preview for auto-created printers only - использовать предпросмотр только для автоматически созданных universal принтеров
Use print preview for generic universal printers only - использовать предпросмотр только для “обычных” universal принтеров
Use print preview for both auto-created and generic universal printers - использовать предпросмотр как для “обычных” universal, так и для автоматически созданных universal принтеров принтеров

Связанные параметры политики

Universal print driver usage - Использование универсального драйвера печати.

Universal printing print quality limit

Это параметр политики задает максимальное качество печати в точках на дюйм (dpi) для генерируемых сессией заданий печати. По-умолчанию - лимит не задан, что позволяет пользователям печатать с максимальным разрешением.
Доступные значения:
Draft (150 DPI)
Low Resolution (300 DPI)
Medium Resolution (600 DPI)
High Resolution (1200 DPI)
No limit

Параметры политики драйверов

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-console-policies-rules-printer-drivers-v2.html
Этот раздел описывает политики связанные с драйверами принтеров XenApp.

Automatic installation of in-box printer drivers

Этот параметр включает или отключает автоматическую установку драйверов принтеров, включенных в состав Windows или драйверов, добавленных в состав Windows с помощью утилиты pnputil.exe /a. По-умолчанию эти драйверы устанавливаются по мере необходимости.

Universal driver preference

Этот параметр задает порядок, в котором используются универсальные драйверы (universal printer drivers) начиная с первого в списке. По-умолчанию порядок такой:
EMF
XPS
PCL5c
PCL4
PS
Вы можете добавлять, удалять и изменять драйверы и порядок их использования.

Universal print driver usage

Это параметр определяет когда следует использовать universal printing. По-умолчанию, universal printing используется только если нужный драйвер недоступен.

Universal printing использует общие (generic) драйверы принтеров, вместо специфичных для данной модели, что теоретически упрощает эксплуатацию фермы XenApp. Работоспособность драйверов universal printing зависит от возможностей принтера, узла фермы XenApp и программного обеспечения сервера печати. В некоторых случаях функции universal printing недоступны.

При добавлении этого параметра к политике следует выбрать одну из опций:
Use only printer model specific drivers - предписывает использовать только “родные” драйверы принтера. Если они недоступны, то принтер не может быть автоматически создан при входе пользователя.
Use universal printing only - будут использоваться только драйверы universal printing.
Use universal printing only if requested driver is unavailable - предписывает использовать универсальные драйверы, если оригинальные драйверы принтера недоступны.
Use printer model specific drivers only if universal printing is unavailable - предписывает использовать оригинальные драйверы, если универсальные драйверы принтера недоступны.

Связанные параметры политики

Auto-create generic universal printer

Администрирование драйверов принтеров

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-printer-driver-managing.html
При входе пользователя на ферму XenApp и запуске приложения, в сессии пользователя автоматически создается принтер, подключенный к его устройству. Хост фермы XenApp пытается обнаружить “родной” драйвер принтера и установить его. По-умолчанию, XenApp автоматически устанавливает “родной” драйвер принтера, если он не найден на хосте.
Так как пользователь может подключаться к ферме XenApp с различных устройств, драйверы принтеров не могут храниться на клиентском устройстве. Для печати на локальный принтер клиента XenApp должен обнаружить соответствующий драйвер как на хосте фермы, так и на клиентском устройстве. На рисунке показано как используется драйвер принтера при печати.
На рисунке показана печать клиента на локальный принтер. Драйвер принтера на сервере перенаправляет задание печати по каналу ICA на клиентское устройство. Затем клиентское устройство перенаправляет задание через тот же драйвер в очередь диспетчера печати и он в свою очередь контролирует работу принтера.

Драйвер принтера на сервере и драйвер на клиенте должны быть одинаковыми. В противном случает - печать не пойдет. Для этого XenApp имеет встроенные средства для управления драйверами, их автоматической установки и репликации в пределах фермы.

Вследствие неправильного обращения с драйверами принтеров возможны следующие проблемы:

- Любой отсутсвующий драйвер может привести к ошибкам печати. Если на ферме установлены драйверы имеющие несколько названий или некорректные названия, то сессия пользователя может не обнаружить нужный драйвер.
- Печать на клиентский принтер через некорректный драйвер может привести к фатальной ошибке на сервере.
- XenApp не скачивает драйверы с сервера печати. На серверах XenApp должны быть установлены правильные драйвера (корректная версия и разрядность) для принтеров, не работающих с универсальными драйверами.
- Если некорректный драйвер реплицируется по всей ферме, то удалить его будет трудно и долго.

При планировании подсистемы печати следует сразу определиться - будут ли использоваться “родные” драйверы принтеров, либо универсальные . либо и те другие.
А если будут использованы универсальные драйверы, то нужно определить:
- Драйверы какого типа будут использованы.
- Нужна ли автоматическая установка отсутствующих на серверах фермы драйверов?
- Нужен ли список совместимости драйверов?
- Нужно ли автоматически реплицировать драйверы принтеров в пределах фермы

Управление автоматической установкой драйверов принтеров

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-printing-drivers-compatibility-lists-all.html

Когда XenApp автоматически создает принтеры, оно определяет наличие всех необходимых драйверов. По-умолчанию, XenApp устанавливает все недостающие драйверы из набора драйверов Windows. Если автоматически будет установлен глючный драйвер - это может привести к серьезным проблемам.
Для того чтобы недопустить подобной ситуации нужно либо запретить автоматическую установку драйверов, либо создать список совместимых драйверов:

- Если точно известно какой драйвер глючит - его можно просто запретить в списке совместимых.
- Если не известно, какие драйвера могут глючить, то следует разрешить только установку драйверов из списка совместимости.

При входе пользователя:
- XenApp проверяет список совместимых драйверов перед установкой принтеров клиента.
- Если драйвер указан среди запрещенных и не включена опция Universal Printing, то принте не устанавливается.
- Когда принтер клиента не устанавливается по причине запрета в списке совместимости, то в журнал вносится соответствующая запись.

Для того чтобы предотвратить автоматическую установку драйверов, сконфигурируйте соответствующую политику Citrix - Automatic installation of in-box printer drivers
Для того чтобы указать способ установки драйверов клиентских принтеров на серферы фермы XenApp нужно сконфигурировать следующие политики Citrix:

Automatic installation of in-box printer drivers - Разрешает или запрещает автоматическую установку драйверов из поставки Windows и драйверов установленных с помощью команды pnputil.exe /a. По-умолчанию драйверы устанавливаются в случае необходимости.
Printer driver mapping and compatibility - Список переназначения драйверов принтеров. Позволяет назначить принтерам конкретный драйвер, или универсальный драйвер.

Параметр Printer driver mapping and compatibility может работать как “белый список”, в котором перечислены только разрешенные драйверы - указав * в поле “Driver name” и установив Do not create for all drivers other than those specified. Также можно использовать значение Create with universal driver only для того чтобы разрешить только универсальные драйверы, для неуказанных драйверов.

Конфигурирование универсальных драйверов принтеров на серверах фермы

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-configuring-universal-printer-all.html
Если вы сконфигурировали использование универсальных драйверов, то по-молчанию, XenApp всегда будет использовать драйвер Citrix Universal (EMF). Если этот драйвер недоступен, то XenApp будет использовать XPS Universal Printer driver. Назначить используемый по-умолчанию драйвер можно с помощью параметра политики Universal driver preference.
Универсальные драйверы принтеров Citrix перечислены в оснастке MMC Print Management. Если были соблюдены все требуемые условия при запуске XenApp, то должны появиться следующие драйверы:
- Citrix Universal Printer, which is the .EMF driver
- Citrix XPS Universal Printer
- HP Color LaserJet 2800 PS (Citrix PS Universal Printer Driver)

Если нужен универсальный драйвер, отсутствующий в списке, то его нужно установить.

Указать какой драйвер будет использоваться в сессиях пользователей можно с помощью параметра политики Universal print driver usage:
- Use universal printing only if requested driver is unavailable - использование универсального драйвера только при отсутствии оригинального.
- Use only printer model specific drivers - использование только оригинального драйвера. Если драйвер не найден, принтер автоматически создан не будет.
- Use universal printing only - использование только универсального драйвера.
- Use printer model specific drivers only if universal printing is unavailable - использование универсального драйвера в случае его наличия, в противном случае - использование универсального.

8.2 - Конфигурирование сетевых принтеров и принтеров мобильных сотрудников

Добавление сетевых принтеров при конфигурировании печати сессии.
http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-console-dialogs-add-network-printer.html
В параметре политики Session printers можно прописать сетевой принтер одним из методов:
- С помощью UNC пути к принтеру в формате \\servername\printername.
- С помощью кнопки Browse. Укажите нужный принтер в окне обзора сети.
- Укажите имя сервера в формате \\servername и нажмите Browse для того чтобы указать конкретный принтер.

Важно: Принтеры указанные в различных экземплярах политик будут объединены, начиная с политики с наивысшим приоритетом. Будут применены настройки по-умолчанию только из политики с наивысшим приоритетом.

Конфигурирование принтеров для мобильных пользователей

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-proximity-printing-configuring-v2.html
При настройке печати для мобильных пользователей важно, чтобы пользователи имели доступ к ближайшему принтеру. Для этого предусмотрена функция Proximity printing, которая автоматически прописывает пользователю сетевые принтеры из того же диапазона IP адресов, в котором находится и пользователь.
Использование этой функции предполагает что:
- Для присвоения адресов используется протокол DHCP, настроенный так, чтобы выдавать адреса в соответствии с физическим размещением (этаж, здание).
- Все этажи или корпуса здания компании имеют собственные непересекающиеся диапазоны IP-адресов.
- Принтеры получают адреса из диапазонов этажей (корпусов) на которых расположены.

Конфигурирование Proximity Printing:
- Создайте отдельную политику для каждой подсети в соответствии с расположением принтеров.
- В каждой политике добавьте соответствующие принтеры.
- Установите значение параметра Default printer в значение Do not adjust the user's default printer
- Настройте фильтры политик по IP-адресам клиентов.

8.3 - Установка новых драйверов принтеров.

Раздел 9. Включение безопасного Web-доступа к опубликованным приложениям

9.1 Конфигурирование обработки отказов и дополнительных параметров в настройках WEb-интерфейса (WI)

Конфигурирование обработки отказов

Дополнительные параметры

Включение опроса сокетов - '''socket pooling'''

Включение перенаправления контента ('''content redirection''')

Перенаправление контента от online plug-in к серверу XenApp позволяет открывать локальные файлы пользователя с помощью приложений, опубликованных в XenApp и доступных через Citrix online plug-in. Это параметр перекрывает все другие параметры перенаправления контента, сконфигурированные в XenApp.

По-умолчанию, перенаправление контента от plug-in к серверу включено только для сайтов XenApp Services .
Более тонкая настройка функции перенаправления контента от plug-in к серверу осуществляется путем ассоцирования расширений файлов с приложениями. http://wiki.autosys.tk/XenApp.%d0%9f%d0%be%d0%b4%d0%b3%d0%be%d1%82%d0%be%d0%b2%d0%ba%d0%b0-%d0%ba-%d1%8d%d0%ba%d0%b7%d0%b0%d0%bc%d0%b5%d0%bd%d1%83-1Y0-A20-Citrix-XenApp-6-5.ashx#Перенаправление_контента_от_клиента_серверу_123
Чтобы настроить перенаправление контента от plug-in к серверу (Content Redirection):
- Запустите консоль Citrix Web Interface Management (Пуск > Все программы > Citrix > Management Consoles > Citrix Web Interface Management)
- В левой части окна консоли выберите тип сайта - XenApp Web Sites или XenApp Services Site и выберите настраиваемый сайт.
- В панели справа кликните Server Farms.
- Нажмите кнопку Advanced.
- Поставьте (чтобы включить) или снимите галочку в поле Content Redirection.

Настройка взаимодействия WI с Citrix XML Service

По-умолчанию, таймаут ожидания Citrix XML Service составляет 1 минуту и сервис признается неработоспособным после двух неудачных попыток. Эти параметры могут быть изменены.
Чтобы настроить параметры взаимодействия WI с Citrix XML Service:
- Запустите консоль Citrix Web Interface Management (Пуск > Все программы > Citrix > Management Consoles > Citrix Web Interface Management)
- В левой части окна консоли выберите тип сайта - XenApp Web Sites или XenApp Services Site и выберите настраиваемый сайт.
- В панели справа кликните Server Farms.
- Нажмите кнопку Advanced.
- В разделе Citrix XML Service communication в поле Socket timeout укажите желаемый таймаут, а в поле Attempts made to contact the XML Service количество попыток.

9.2 Конфигурирование безопасного доступа в соответствии с предъявляемыми требованиями

http://support.citrix.com/proddocs/topic/web-interface-impington/wi-configure-gateway-settings-gransden.html

Конфигурирование параметров шлюза

Если для доступа к ферме XenApp используется Access Gateway или Secure Gateway, то для взаимодействия с ними Web-интерфейс должен быть сконфигурирован соответствующим образом. Сконфигурировать можно как маршрут по-умолчанию, так и специальный машрут для пользовательских устройств из определенного диапазона IP-адресов.
1. Запустите консоль управления параметрами WI - Меню Пуск > Все программы > Citrix > Management Consoles > Citrix Web Interface Management.
2. В левой панели консоли Citrix Web Interface Management выберите тип конфигурируемого сайта - XenApp Web Sites или XenApp Services, а затем в центральной панели выберите сайт.
3. В панели Action (справа) кликните Secure Access.
4. На странице Specify Access Methods можно создать новый маршрут безопасного доступа к ферме или отредактировать существующий. Для этого кликните Add или выберите существующую запись из списка и кликните Edit.
5. Из списка вариантов доступа выберите один из вариантов:
- Gateway Direct. В случае, когда вы можете предоставить шлюзу Secure Gateway действительный (нетранслируемый) адрес сервера Citrix. То есть шлюз и сервер Citrix находятся в одной локальной сети или разделены нетранслирующим сетевым экраном.
- Gateway alternate. В случае, когда шлюз Secure Gateway и сервер Citrix XenApp взаимодействуют через межсетевой экран, транслирующий адреса (NAT).

Примечание: Виртуальные рабочие столы XenDesktop не могут работать в конфигурации Gateway alternate.

- Gateway translated. В случае, когда используется трансляция адресов и перенаправление портов.
6. Введите адрес и маску сети, которой принадлежат клиенты. Используйте кнопки Up и Down для расположения маршрутов в соответствии приоритетом и нажмите Next.
7. Если не используется трансляция адреса шлюза (gateway address translation), то переходите к шагу 10. В противном случае чтобы добавить трансляцию адреса - кликните Add на странице Specify Address Translations или выберите запись из списка и кликните Edit.
8. В поле Access Type выберите один из вариантов:
- Если адрес шлюза транслируется при соединении с сервером Citrix - выберите Gateway route translation
- Если уже настроен клиентский маршрут трансляции в таблице адресов User device и шлюз и клиентское устройство используют транслированный адрес при подключении к серверу Citrix - выберите User device and gateway route translation
9. Введите номера внутреннего и внешнего (транслированного) портов и адреса сервера Citrix и кликните OK. Когда шлюз будет соединяться с сервером Citrix, он будет использовать внешний (external) адрес и порт. Убедитесь, что созданные перенаправления (mappings), соответствуют типу адресации, используемой в ферме XenApp. Кликните Next.
10. На странице Specify Gateway Settings укажите полное доменное имя (FQDN) и номер порта шлюза, который должны использовать клиенты. Полное доменное имя (FQDN) должно в точности соответствовать имени, указанному в сертификате, установленном на шлюзе.
11. Если вы хотите использовать функцию автоматического переподключения отключенных сессий - поставьте галочку Enable session reliability .
12. Если включена функция автоматического переподключения отключенных сессий и вы хотите использовать одновременную выдачу билетов (ticketing) от двух Secure Ticket Authorities (STAs), то выберите Request tickets from two STAs. Если эта опция включена - WI получает билеты (tickets) от двух разных STAs и таким образом сессии пользователей не прерываются, если один STA становится недоступным. Если по какой-то причине WI не сможет соединиться с двумя STA, он продолжит работать с одним STA. Кликните Next.
Примечание: Для использвания этой функции необходимо развернуть Access Gateway. Secure Gateway в настоящий момент не поддерживает несколько STA.
13. На странице Specify Secure Ticket Authority Settings кликните Add для того чтобы указать адрес (URL) Secure Ticket Authorities (STA) или выберите запись из списка и кликните Edit для редактирования параметров уже заданных STA. STA входят в состав службы Citrix XML Service. Например - https://servername.domain.com/scripts/ctxsta.dll. Можно указать более одного STA для обработки отказов, однако Citrix не рекомендует использовать внешние балансировщики нагрузки для этой цели. Используйте кнопки Move Up и Move Down для установки порядка приоритета STA.
14. Задайте будет ли использоваться балансировка нагрузки на STA с помощью опции Use for load balancing. Включение этой опции позволяет равномерно распределить нагрузку на серверы и таким образом избежать их перегрузки.
15. В поле Bypass failed servers for укажите интервал времени, в течение которого недоступный STA будет исключен из работы. Web-интерфейс обеспечивает обработку отказов серверов STA из списка, исключая отказавший сервер из работы на заданный интервал времени.

9.3 - Включение балансировки нагрузки

http://support.citrix.com/proddocs/topic/web-interface-impington/wi-enable-load-balancing-gransden.html
Можно включить балансировку нагрузки на серверы, на которых исполняется сервис Citrix XML Service. Включение балансировки нагрузки позволяет равномерно распределить нагрузку на сервера. По-умолчанию балансировка нагрузки на серверы Citrix XML Service отключена.
Если при взаимодействии с каким либо сервером будет зафиксирована ошибка, балансировка будет осуществляться между оставшимися серверами. Отказавший сервер будет исключен из балансировки на заданный период времени (по-умолчанию - один час).
Для включения балансировки:
- Запустите консоль Citrix Web Interface Management (Пуск > Все программы > Citrix > Management Consoles > Citrix Web Interface Management)
- В левой части окна консоли выберите тип сайта - XenApp Web Sites или XenApp Services Site и выберите настраиваемый сайт.
- В панели справа кликните Server Farms.
- Выберите настраиваемую ферму и кликните Edit, или добавьте новую - Add.
- В список серверов добавьте сервера, на которых исполняется Citrix XML Service, в порядке приоритета.
- Включите балансировку в поле Use the server list for load balancing.
- В поле Bypass any failed server for задайте время, на которое отказавший сервер будет исключен из списка опрашиваемых.

9.4 - Конфигурирование сайтов Web-интерфейса (PNAgent, Services, Access)

Включение явной (explicit) аутентификации

http://support.citrix.com/proddocs/topic/web-interface-impington/wi-enable-explicit-authentication-gransden.html
Если включена явная (explicit) аутентификация, то для входа на ферму пользователи должны иметь учетные записи и предоставлять учетные данные при входе.
Настройки параметров явной аутентификации производятся в консоли Citrix Web Interface Management. Например, можно указать - разрешено ли пользователям менять пароли в течение сессии.

Явная (explicit) аутентификация доступна только для сайтов XenApp Web sites.

Для включения явной (explicit) аутентификации:
- Запустите консоль Citrix Web Interface Management (Пуск > Все программы > Citrix > Management Consoles > Citrix Web Interface Management)
- В левой части окна консоли выберите тип сайта - XenApp Web Sites и выберите настраиваемый сайт.
- В панели справа кликните Authentication Methods и поставьте галочку в чекбоксе Explicit.
- Кликните Properties для того чтобы сконфигурировать дополнительные параметры явной аутентификации.

Начальная конфигурация сайтов XenApp.

http://support.citrix.com/proddocs/topic/web-interface-impington/wi-specify-initial-config-gransden.html
После создания сайта XenApp с помощью консоли Citrix Web Interface Management, необходимо сконфигурировать сайт, отметив галочкой чекбокс Configure this site now на последней странице мастера создания. Запустится мастер создания конфигурации сайта - Specify Initial Configuration, который позволит связать сайт с одной или несколькими фермами и указать тип ресурсов, доступных пользователям сайта.

Подключение к сайту ферм XenApp

При создании сайта XenApp необходимо указать параметры хотя бы одной фермы, ресурсы которой будут опубликованы на сайте.
Эти параметры можно впоследствии обновить или изменить с помощью задачи Server Farms в консоли Citrix Web Interface Management.

Методы аутентификации

При конфигурировании новой сайта XenApp для которого задана точка аутентификации (authentication point) At Web Interface можно задать способ аутентификации пользователей при входе через Web Interface. Эти параметры можно впоследствии изменить с помощью задачи Authentication Methods в консоли Citrix Web Interface Management.

Ограничения доменов

При конфигурировании новой сайта XenApp для которого задана точка аутентификации (authentication point) At Web Interface можно ограничить доступ к сайту пользователям определенных доменов. Эти параметры можно впоследствии изменить с помощью задачи Authentication Methods в консоли Citrix Web Interface Management.

Вид страницы входа

Можно задать внешний вид страницы входа, выбрав между минималистичным дизайном и полным, включающим строку навигации.
Эти параметры можно впоследствии изменить с помощью задачи Web Site Appearance в консоли Citrix Web Interface Management.

Типы ресурсов, доступных пользователям

При конфигурировании нового сайта необходимо указать типы ресурсов, доступных пользователям. Web Interface обеспечивает доступ пользователей к ресурсам (приложениям, контенту и рабочим столам) через браузер, либо через Citrix online plug-in. Интеграция с фукнцией offline-приложений позволяет пользователям получать (stream) приложения на клиентские устройства и и пользоваться ими локально.

Типы ресурсов:
- Online. Пользователи пользуются приложениями, контентом и рабочими столами, размещенными на удаленных серверах фермы. Для работы пользовательские устройства должны быть постоянно подключены к сети.
- Offline. ПОльзователтьские приложения стримятся на рабочие места клиентов и исполняются на них локально. После успешной доставки приложения на рабочее место клиента, постоянное подключение к сети не требуется. При этом, для запуска приложения пользователь должен подключиться к сайту XenApp и аутентифицироваться. После успешного запуска приложения поддержание соединения не требуется.
- Dual mode. Пользовтаели подключаются как к offline, так и online приложениям, а также контенту и рабочим столам. Если offline приложения недоступны, то доставляются online версии приложений.

Эти параметры можно впоследствии изменить с помощью задачи Resource Types в консоли Citrix Web Interface Management.

Ошибка Web-интерфейса: '''The remote server failed to execute the application launch request'''

http://support.citrix.com/article/CTX120605

Симптомы

При подключении к сайту XenApp services через Secure Gateway с помощью XenApp Services Plug-in with Web Interface появляется сообщение об ошибке:
“The remote server failed to execute the application launch request. Please contact your administrator for further details.”

Возможные причины

При работе сайта XenApp services , для его взаимодействия с Citrix Secure gateway, запрашивается билет (ticket) от Secure Ticket Authority (STA) . Эта ошибка наблюдается, когда Web-интерфейс не может запросить тикет STA.

В журнале фиксируются такие ошибки:
Connection Error

Event Type:Error
Event Source:XenApp Services
Event Category:None
Event ID:0
Date:      
Time:12:44:34 PM
User:N/A
Computer:<Server_Name> Description:Site path: c:\inetpub\wwwroot\Citrix\

An error occurred while attempting to connect to the server citrixserver1 on port 80. Verify that the Citrix XML Service is running and is using the correct port. If the XML Service is configured to share ports with IIS, verify that IIS is running. This message was reported from the XML Service at address http://citrixsserver1.citrix.com/scripts/ctxsta.dll. The specified Secure Ticket Authority could not be contacted and will be temporarily removed from the list of active services. [Log ID: f7146d2e]

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

XML Transaction Error

Event Type:Error
Event Source:XenApp Services
Event Category:None
Event ID:0
Date:
Time:12:44:34 PM
User:N/A
Computer:<Server_Name>
Description:Site path: c:\inetpub\wwwroot\Citrix\

All of the configured Secure Ticket Authorities failed to respond to this XML transaction. [Log ID: c9e4c683]

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Причины

Возможные причины:
- Указан неправильный адрес (URL) для STA.
- Не указан номер порта в адресе STA. При использовании нестандартного порта XML, его необходимо указывать явно.

Решение

Для разрешения этой проблемы проверьте правильность STA URL:
Формат URL STA такой:

https://servername.domain.com/scripts/ctxsta.dll

При использовании нестандартного порта XML, его необходимо указывать явно.

https://servername.domain.com:8080/scripts/ctxsta.dll

9.5 - Конфигурирование Web-интерфейса для работы с несколькими фермами

Добавление фермы к Web-интерфейсу

http://support.citrix.com/proddocs/topic/web-interface-impington/wi-add-server-farm-gransden.html
Чтобы добавить ферму:
- Запустите консоль Citrix Web Interface Management (Пуск > Все программы > Citrix > Management Consoles > Citrix Web Interface Management)
- В левой части окна консоли выберите тип сайта - XenApp Web Sites или XenApp Services Site и выберите настраиваемый сайт.
- В панели справа кликните Server Farms.
- Добавьте новую ферму - кликните Add.
- Введите имя фермы в поле Farm name.
- Добавьте сервер фермы, на котором исполняется Citrix XML Service, кликнув Add.
- В списке серверов с помощью кнопок Move Up и Move Down расположите сервера, на которых исполняется Citrix XML Service, в порядке приоритета.
- В поле Bypass any failed server for задайте время, на которое отказавший сервер будет исключен из списка опрашиваемых.

Добавление фермы к Web-интерфейсу с помощью конфигурационного файла

http://support.citrix.com/proddocs/topic/web-interface-impington/wi-configure-communication-server-gransden.html
Сайт Web-интерфейса XenApp хранит конфигурационную информацию в файле. Этот файл можно редактировать вручную.
Если в при редактировании конфигурационного файла туда будут внесены не корректные значения, то последующий запуск консоли Citrix Web Interface Management заменит некорректные сведения на значения по-умолчанию.
Citrix рекомендует закрывать консоль Citrix Web Interface Management перед редактированием конфигурационного файла вручную. При внесении изменений в конфигурацию с помощью консоли, конфигурационный файл каждый раз перезаписывается полностью. Если закрыть консоль на время редактирования невозможно, то после внесений изменений в конфигурационный файлы следует обновлять консоль и только потом вносить изменения в конфигурацию.

Конфигурационный файл WebInterface.conf находится в дирректории:
- При использовании Microsoft Internet Information Services (IIS) обычно это директория C:\inetpub\wwwroot\Citrix\SiteName\conf
- На сервере приложений Java (например Apache Tomcat), это может быть такой путь: /usr/local/tomcat/webapps/Citrix/XenApp/WEB-INF. После внесения изменений в конфигурационный файл сервера приложений Java, может потребоваться его перезапуск.

Для добавления сервера с Citrix XML Service в конфигурацию Web-интерфейса:
Например в конфигурации уже есть сервер, названный “rock” и теперь требуется добавить второй сервер. названный “roll”. Для этого нужно в файле WebInterface.conf строку вида:

Farm1=rock,Name:Farm1,XMLPort:80,Transport:HTTP, SSLRelayPort:443,…

Привести к виду:

Farm1=rock,roll,Name:Farm1,XMLPort:80,Transport:HTTP, SSLRelayPort:443,…

То есть к параметру Farm1, через запятую дописать имя добавляемого сервера (“roll”).

Использование Workspace Control совместно с Integrated Authentication Methods для Web-сайтов XenApp

http://support.citrix.com/proddocs/topic/web-interface-impington/wi-use-workspace-control-integrated-gransden.html
Следующий раздел применим только к сайтам XenApp Web sites. Если пользователи подключаются с помощью сквозной (pass-through) аутентификации, либо с помощью смарт-карт, то необходимо настроить доверительные отношения между сервером на котором исполняется Web-интерфейс и всеми прописанными на нем серверами Citrix XML Service.
Citrix XML Service передает информацию о ресурсах от серверов XenApp к серверу Web-интерфейса. Без доверительных отношений, кнопки Disconnect, Reconnect, и Log Off будут неработоспособны дял пользователей, аутентифицированных с помощью сквозной (pass-through) аутентификации, либо с помощью смарт-карт.
Устанавливать доверительные отношения не нужно, если пользователи аутентифицируются серверами фермы или не используют сквозную аутнтификацию и аутентификацию с помощью смарт-карт.

Если вы конфигурируете сервер для доверительных отношений к запросам Citrix XML Service, то учтите следующее:

- После установления доверительных отношений аутентификацию пользователей осуществляет Web-сервер. Для повышения безопасности используйте IPSec, межсетевые экраны и другие технологии, повышающие безопасность. Доверительные отношения не нужны, если используется явная (explicit) аутентификация.
- Включайте доверительные отношений только на серверах, которые непосредственно взаимодействуют с Web-интерфейсом. Эти серверы перечислены в консоли Citrix Web Interface Management, в задаче Server Farms
- Настраивайте технологии обеспечивающие безопасность таким образом, чтобы с серверами Citrix XML Service могли взаимодействовать только сервер Web-интерфейса. Например, если Citrix XML Service разделяет один порт с Microsoft Internet Information Services (IIS), то можно использовать ограничение IP-адресов, взаимодействующих с Citrix XML Service.

1.Log on to a server in the farm and click Start > All Programs > Citrix > Management Consoles > Citrix Delivery Services Console.
2.In the left pane of the console, navigate to Citrix Resources > XenApp, expand the node for your farm, and click Policies.
3.In the details pane of the console, select the Computer tab and click New.
4.Enter a name and, optionally, a description for your new policy and click Next.
5.In the Categories list, click XML Service and, under Settings, select Trust XML requests and click Add.
6.Select Enabled and click OK. Click Next.
7.If required, apply filters to your policy to determine the circumstances under which it is applied and click Next.
8.Ensure that the Enable this policy checkbox is selected and click Save.

Создание сайта Active Directory Federation Services

http://support.citrix.com/proddocs/topic/web-interface-impington/wi-before-creating-ad-fs-sites-gransden.html

9.7 - Конфигурирование аутентификации для Web-интерфейса

Доступные типы аутентификации

http://support.citrix.com/proddocs/topic/web-interface-impington/wi-authenticate-wrapper-gransden.html
Для Web-интерфейса можно сконфигурировать следующие типы аутнтификации:
- Explicit (XenApp Web sites) или prompt (XenApp Services sites). Это явная аутентификация. ПОльзователм требуется входить с помощью Имени пользователя и Пароля, а также помощью User principal name (UPN) в формате user@domain.com, доменной аутентифиакции Microsoft или аутентификации Novell Directory Services (NDS). Для сайтов XenApp Web sites, также доступны методы RSA SecurID и SafeWord.

Примечание: аутентификация Novell недоступна для серверов Web Interface for Java Application Servers и не поддерживается XenApp 6.0, XenApp 5.0 for Windows Server 2008 и XenDesktop. Но XenApp 6.0 совместим с Novell Domain Services for Windows.

- Сквозная аутентификация (Pass-through). Пользователи могут аутентифицироваться учетными данными, с которыми они вошли в домен на своих клиентских устройствах. Пользователю не надо повторно вводить учетные данные, а их ресурсы конфигурируются автоматически. Кроме того, можно использоватб встроенную в Windows аутентификацию Kerberos. Если указана опция аутентификации Kerberos, но она прошла неудачно, то также не удастся авторизоваться и с помощью сквозной (pass-through) аутентификации.
- Сквозная со смарт-картой (Pass-through with smart card). Пользователи аутентифицируются с помощью смарт-карты, считываемой на пользовательском устройстве. Если на пользовательском устройстве установлен Citrix online plug-in, у то при входе будет запрошен PIN смарт-карты. После входа, пользователь получит доступ к своим ресурсам без повторных запросов аутентификации. У пользователи подключающихся к сайтам XenApp Web sites PIN не запрашивается. Если вы конфигурируете сайт XenApp Services, то можно использовать встроенную в Windows аутентификацию Kerberos и для подключения к Web Interface, которая задействует смарт-карту, использованную для аутентификации на ферме. Если указана опция аутентификации Kerberos, но она прошла неудачно, то также не удастся авторизоваться и с помощью сквозной (pass-through) аутентификации.
- Смарт-карта (Smart card). ПОльзователи могут аутентифицироваться с помощью смарт-карт. У пользователя будет запрошен PIN смарт-карты.

Примечание: Аутентификация Pass-through, pass-through with smart card и smart card недоступна при использовании Web Interface for Java Application Servers

- Анонимная (Anonymous). Анонимные пользователи могут входить без указания учетных данных и использовать ресурсы, опубликованные для анонимных пользователей.

Важно: Анонимные пользователи могут получать тикеты Secure Gateway несмотря на то что они не аутентифицированы в Web Interface. Т.к. Secure Gateway полагается на Web Interface, который выдает тикеты только аутентифицированным пользователям - это компрометирует преимущества, которые предоставляет использование Secure Gateway.

Примечание: XenDesktop не поддерживает анонимных пользователей.

Использование аутентификации в домене

http://support.citrix.com/proddocs/topic/web-interface-impington/wi-use-domain-authentication-gransden.html
Если для входа пользователей используется явная (explicit) или prompt аутентификация, то для настройки аутентификации пользователей в домене Windows или Novel используйте задачу Authentication Methods в консоли Citrix Web Interface Management.

1. Запустите консоль Citrix Web Interface Management (Пуск > Все программы > Citrix > Management Consoles > Citrix Web Interface Management)
2. В левой части окна консоли выберите тип сайта - XenApp Web Sites или XenApp Services Site и выберите настраиваемый сайт.
3. В панели справа кликните Authentication Methods и выберите Explicit, Promp и/или Pass-through.
4. Кликните Properties и выберите Authentication Type.
5. Выберите Windows or NIS (UNIX).
6. Укажите формат учетных данных для входа пользователей. Выберите одну из опций:
- Ввод имен пользоватлей в формате Domain\User или UPN (user@domain.com) - опция Domain user name and UPN
- Ввод имен пользователей только в формате Domain\User - опция Domain user name only
- Ввод имен пользователей только в формате UPN (user@domain.com) - опция UPN only
7. Кликните Settings.
8. В зоне Domain Display сконфигурируйте:
- Выводить или нет поле для ввода имени домена на странице входа - Hide domain box или Display domain box.
- Укажите должен ли список доменов быть заполнен по-умолчанию, либо пользователи должны сами вводить имя домена каждый раз.

Примечание: Если пользователи при входе получают сообщение “Domain must be specified”, то возможно в поле домена ничего не введено. Для решения этой проблемы выберите Hide Domain box. Если в ферму входят только серверы XenApp for UNIX, то следует выбрать Pre-populated и добавить в список домен с именем - UNIX.

- Добавьте в список домены, которые будут появляться в диалоге входа.
9. В поле UPN Restriction сконфигурируйте:
- Все ли доменные суффиксы будут приниматься.
- Укажате желаемые суффиксы UPN.

Раздел 10: Решение проблем

10.1 - Решение проблем со службой IMA

Решение проблем с запуском IMA

http://support.citrix.com/article/CTX105292

Симптом

Служба Independent Management Architecture (IMA) не запускается.

Причины

Причины, по которым IMA не стартует могут быть связаны с:

Время запуска IMA Service
Отсуствует временная директория Temp
Проблемы со службой диспетчера печати Print spooler service
Конфигурация ODBC
Roaming Profile
Другой сервер в сети имеет такое же имя NetBIOS

Время запуска IMA Service

Если Менеджер управления службами (Service Control Manager) сообщает что служба IMA Service не может быть запущена, но служба все-таки стартует, несмотря на это сообщение.
Менеджер управления службами имеет таймаут 6 минут. Служба IMA может запускаться дольше 6 минут, если нагрузка на сервер с базой данных превышает возможности производительности компьютера, обрабатывающего базу данных или если в сети очень высокая задержка. Если вы считаете, что служба IMA ависла в состоянии запуска (“starting”), то можно просто завершить процесс ImaSrv.exe в Диспетчере задач и снова запустить службу Citrix Independent Management Architecture.

Source: DSView
http://support.citrix.com/article/CTX106232

если_пропало_подключение_к_базе_данных_xendesktop_7.6

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Настройки подключения к базе в реестре прописаны для каждого сервиса и находятся тут: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\XDservices. У каждого сервиса в папке Datastore есть ConnectionString.

SiteGuid лежит тут: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Broker\Service\State\ConnectionLeasing

Замена админа

Замена админа если потерялись права: http://support.citrix.com/article/CTX201779
Получаем SID текущего пользователя:

wmic useraccount where name='username' get sid

Затем в PowerShell выполняем:

Asnp citrix.*
$sid = "----SID----"
$securityId = New-Object System.Security.Principal.SecurityIdentifier($sid)
$securityId.Translate([System.Security.Principal.NTAccount])

Например ситутация - сдох DDC (или кто-то отломил ему DBconnections) и надо натравить вновь установленный DDC настравить на существующую базульку.

На DDC запускаем powershell

Add-PSSnapin Citrix*

Текущее состояние подключений можно получить так:

Get-LogDataStore
Get-MonitorDataStore

Формируем строку подключения:

$cs = "Server=env3-sql2\AON;Initial Catalog=CitrixXD7;Integrated Security=True"

Тут меняем имя сервера\инстанса Server и имя базы данных Catalog. Отключаем Configuration Logging:

Set-LogSite -State Disabled
Set-MonitorConfiguration -DataCollectionEnabled $False

Затем заменяем все строки подключений на NULL:

Set-LogDBConnection -DataStore Logging -DBConnection $null
Set-MonitorDBConnection -DataStore Monitor -DBConnection $null
Set-MonitorDBConnection -DBConnection $null
Set-AcctDBConnection -DBConnection $null
Set-ProvDBConnection -DBConnection $null
Set-EnvTestDBConnection -DBConnection $null
Set-SfDBConnection -DBConnection $null
Set-HypDBConnection -DBConnection $null

Для некоторых опций нужно применить -force

Set-ConfigDBConnection -DBConnection $null -force
Set-LogDBConnection -DBConnection $null -force
Set-AdminDBConnection -DBConnection $null -force

В результате все компоненты XenDesktop будут отключены от базы данных.

На всякий случай следует проверить что DDC имеют права на SQL-сервере:

sqlcmd -S env3-sql2\AON -q "create login [2k3\DDC1$] from windows"

Тут также поправляем имя SQL-сервера\инстанса и имя домена\компа$

Теперь заново указываем строку для подключения сервисов к базе:

set-ConfigDBconnection -dbconnection $cs
set-AdminDBconnection -dbconnection $cs
set-LogDBconnection -dbconnection $cs
set-AcctDBconnection -dbconnection $cs
set-BrokerDBconnection -dbconnection $cs
set-EnvTestDBconnection -dbconnection $cs
set-HypDBconnection -dbconnection $cs
set-MonitorDBconnection -dbconnection $cs
set-ProvDBconnection -dbconnection $cs
set-SfDBconnection -dbconnection $cs
Set-LogDbConnection -DataStore logging -DbConnection $cs
Set-MonitorDbConnection -DataStore monitor -DbConnection $cs

Теперь снова включаем журнал конфигурирования:

Set-LogSite -State Enabled

И выполняем маленький тест подключения:

$testString = Get-BrokerDBConnection
Test-BrokerDBConnection $testString | fl

Теперь можно попробывать запустить Studio и проверить что получилось. Очень может быть, что система выдаст ServiceNotInSiteDB Скорее всего (как написано тут: https://discussions.citrix.com/topic/295003-broker-service-not-connecting-to-database/?p=1586659) возникло несоотвествие SID DDC, записанного в базе SID нового DDC.

Для начала нужно удалить текущие записи из базы. Получаем SID текущего контроллера и присваиваем его переменной:

sqlcmd -S .\SQLEXPRESS -d CitrixXenDesktopDB -Q 'select Sid from chb_Config.Controllers'

и присваиваем его переменной:

$sid = 'S-1-5-21...'

Дальше с помощью powershell генерируем запрос к базе, который выполнит удаление SID старого DDC из базы. При возникновении ошибок нужно с ними внимательно разбираться, поскольку дальнейшие действия могут все порушить.

$sid = 'S-1-5-....'
Get-ConfigDBSchema -DatabaseName CitrixXenDesktopDB -ScriptType Evict -SID $sid -Local > EvictDDC.sql
Get-AcctDBSchema -DatabaseName CitrixXenDesktopDB -ScriptType Evict -SID $sid -Local >> EvictDDC.sql
Get-HypDBSchema -DatabaseName CitrixXenDesktopDB -ScriptType Evict -SID $sid -Local >> EvictDDC.sql
Get-ProvDBSchema -DatabaseName CitrixXenDesktopDB -ScriptType Evict -SID $sid -Local >> EvictDDC.sql
Get-PvsVmDBSchema -DatabaseName CitrixXenDesktopDB -ScriptType Evict -SID $sid -Local >> EvictDDC.sql
Get-BrokerDBSchema -DatabaseName CitrixXenDesktopDB -ScriptType Evict -SID $sid -Local >> EvictDDC.sql
sqlcmd -S .\SQLEXPRESS -Q ':r EvictDDC.sql'

После удаления из базы SID старого DDC можно сформировать запрос, прописывающий в базу SID нового DDC:

Get-ConfigDBSchema -DatabaseName CitrixXenDesktopDB -ScriptType Instance -Local > AddDDC.sql
Get-AcctDBSchema -DatabaseName CitrixXenDesktopDB -ScriptType Instance -Local >> AddDDC.sql
Get-HypDBSchema -DatabaseName CitrixXenDesktopDB -ScriptType Instance -Local >> AddDDC.sql
Get-ProvDBSchema -DatabaseName CitrixXenDesktopDB -ScriptType Instance -Local >> AddDDC.sql
Get-PvsVmDBSchema -DatabaseName CitrixXenDesktopDB -ScriptType Instance -Local >> AddDDC.sql
Get-BrokerDBSchema -DatabaseName CitrixXenDesktopDB -ScriptType Instance -Local >> AddDDC.sql
sqlcmd -S .\SQLEXPRESS -Q ':r AddDDC.sql'

книжка-xendesktop-5-6-cookbook

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Введение

XenDesktop 5.6 - это платформа виртуализации, которую можно использовать в двух вариантах: Machine Creation Services (MCS) и Provisioning Services (PVS).
Модель Machine Creation Services (MCS) предполагает, что рабочие места и приложения публикуются на серверах виртуальных машин (XenServer или VmWare ESXi), а пользователи осуществляют доступ к ним в соответствиии с разрешениями.
Модель Provisioning Services (PVS) предполагает наличие одного или нескольких образов рабочих мест, предоставляемых пользователям по требованию - загружаемых по сети работающих на компьютерах пользователей.
В обоих случаях сведения о рабочем окружении хранятся в базе данных Citrix под управлением Microsoft SQL Server. В ней содержатся сведения об инфраструктурных компонентах (Desktop Controller, Desktop Studio, Provisioning Services server), так и о ресурсах, например - виртуальных рабочих местах, доступ к которым предоставляется через web-портал - Web Interface.
Обе модели доступа к ресурсам могут сочетаться в рамках одной инсталляции. Этот подход называется Citrix FlexCast.

В каком случае лучше использовать MCS?

- MCS это отличный выбор, если нужна только инфраструктура виртуальных рабочих столов (VDI).
- Если количество виртуализируемых рабочих мест не превышает 2500.
- MCS предпочтителен, если нужны не только стандартизованные рабочие места, но также требуется чтобы пользователи могла устанавливать свое ПО.
- MCS предпочтителен, если требуется часто обновлять базовые образы рабочих мест. В отличие от PVS, где для обновления потребуются довольно сложные процедуры, в MCS обновления осуществляются довольно просто.
- MCS разумно использовать когда имеется быстрое общее сетевое хранилище (shared storage), например - Network File System (NFS) или Storage Area Network (рекомендуется). MCS довольно требовательна к скорости ввода-вывода СХД.

Для реализации модели MCS потребуются следующие компоненты:
- Desktop Director
- Desktop Controller
- Web Interface
- License server

В каком случае рекомендуется использовать PVS

- Если нужно предоставлять не только виртуальные рабочие столы размещенные на сервере, а использовать вычислительные ресурсы компьютеров пользователей.
- Когда есть несколько площадок, на каждой из которых более 2500 рабочих мест.
- Когда нет производительного сетевого хранилища (СХД). В этом случае можно использовать преимущества кеширования PVS.
- Когда есть много пользователей входящих в систему или выходящих из нее одновременно (явление известное как boot storm). В этому случае PVS позволяет обойти ограничения СХД.

Для реализации модели PVS потребуются следующие компоненты:
- Desktop Director
- Desktop Controller
- Web Interface
- License server
- Citrix Provisioning Services

Подход Citrix FlexCast при котором сочетаются преимущества PVS и MCS позволяет получить наилучший результат в самых разнообразных условиях.

Подготовка базы данных SQL

Для работы XenDesktop 5.6 нужна база данных SQL. Поддерживаются следующие версии Microsoft SQL Server:
- SQL Server 2008 Express Service Pack 1 (32 или64 bit)
- SQL Server 2008 Service Pack 2 or 3 (32 или 64 bit)
- SQL Server 2008 R2 Express (только 64 bit)
- SQL Server 2008 R2 (только 64 bit)

Выбор версии MS SQL Server зависит от размеров инсталляции и требований к отказоустойчивости. Небольшие инсталляции могут ограничиться интегрированной версией MS SQL Server Express.
Если нужно обеспечить работу тысяч клиентов, то возможно понадобится кластер серверов MS SQL и более продвинутые версии.
Версия MS SQL Server Express интегрирована в дистрибутив и для того чтобы ее установить достаточно при установке выбрать опцию Install SQL Server Express.

Установка экземпляра MS SQL Server не вызывает сложностей. При установке по соображениям безопасности рекомендуется создавать именованный экземпляр SQL Server (MSSQLSERVER), который будет выделен для работы с XenDesktop.

На сервере SQL необходимо создать базу данных со следующими параметрами:
- Порядок сортировки (Collation sequence) - Latin1_General_CI_AS_KS.
- Аутентификация только Windows. XenDesktop не поддерживает аутентификацию SQL и смешанный режим (Mixed mode).
- Разрешения такие:
<nobr>

<TABLE BORDER VALIGN="top">
        <TR>
                <TD><b>Activity</b></TD> <TD><b>Server role</b></TD> <TD><b>Database role</b></TD>
        </TR>
        <TR>
                <TD>Database creation</TD> <TD>dbcreator</TD> <TD> </TD>
        </TR>
         <TR>
                <TD>Schema creation</TD> <TD>securityadmin</TD> <TD>db_owner</TD>
        </TR>
<TR>
                <TD>Controller addition</TD> <TD>securityadmin</TD> <TD>db_owner</TD>
        </TR>
<TR>
                <TD>Controller removal</TD> <TD> </TD> <TD>db_owner</TD>
        </TR>
<TR>
                <TD>Schema update</TD> <TD> </TD> <TD>db_owner</TD>
        </TR>
</TABLE>

</nobr>
Эти разрешения будут даны пользователю Windows, который будет выполнять конфигурирование с помощью Desktop Studio.

В качестве порядка сортировки (Collation sequence) можно выбрать не только Latin1_General_CI_AS_KS, а любой порядок из группы *_CI_AS_KS.
Следует внимательно следить за размером журнала транзакций базы данных. Размер самой базы данных не будет превышать 250 MB для нескольких тысяч пользователей, но вот размер журнала транзакций может расти очень быстро.
Следующая таблица поможет оценить размер файла базы и журнала в зависимости от количества пользователей:
<nobr>

<table border>
<tr>
<td><b>Компонент</b></td><td><b>Тип Данные/Журнал</b></td><td><b>Размер</b></td>
</tr>
<tr>
<td>Регистрационная информация</td> <td>Данные</td><td>2.9 KB на рабочее место</td>
</tr>
<tr>
<td>Состояние сессии</td> <td>Данные</td><td>5.1 KB на рабочее место</td>
</tr>
<tr>
<td>Учетные данные компьютера в AD</td> <td>Данные</td><td>1.8 KB на рабочее место</td>
</tr>
<tr>
<td>Сведения о машине MCS</td> <td>Данные</td><td>1.94 KB на рабочее место</td>
</tr>
<tr>
<td>Журнал транзакций для простаивающего рабочего места</td> <td>Журнал</td><td>62 KB в час</td>
</tr>
</table>

</nobr>

В случае необходимости переконфигурирования (redeploy) одного или нескольких контроллеров Desktop Delivery Controller, в первую очередь следует очистить сконфигурированную базу данных Citrix XenDesktop, то есть обнулить сведения о подключениях компонентов Citrix. Это можно сделать с помощью команд Citrix PowerShell:

Set-ConfigDBConnection -DBConnection $null
Set-AcctDBConnection -DBConnection $null
Set-HypDBConnection -DBConnection $null
Set-BrokerDBConnection -DBConnection $null

После выполнения этих команд можно вручную удалить и заново создать базу данных.

Установка

Установка и конфигурирование сервера лицензирования

ВНИМАНИЕ! Предполагается наличие у вас лицензий Citrix XenApp.

Запускам autorun из дистрибутива, автоматически устанавливаются необходимые компоненты. В Citrix XenApp Role manager жмем Add Or remove Server Roles и устанавливаем сервер лицензирования. После установки, в меню Citrix XenApp Role manager жмём Configure рядом с License Server. Он предлагает настроить порты:

License Server Port: 2700
Vendor Daemon Port: 7279
Management Console Web Port: 8082

Также можно установить сервер лицензирования с помощью командной строки, задав все необходимые параметры:

msiexec /I /qn INSTALLDIR=C:\LICSERVER LICSERVERPORT=27004 ADMINPASS=TestCase01

Значения параметров:
/I - Указываем msiexec, что надо начать установку.
/qn - “Тихий” режим установки.
INSTALLDIR - Указывет путь для установки. По-умолчанию - C:\Program files\Citrix\Licensing или C:\Program files(x86)\Citrix\Licensing для 32-х и 64-х битных систем.
LICSERVERPORT - Задает порт, который будет прослушивать служба лицензирования Citrix. По-умолчанию - 27000.
ADMINPASS - Задает пароль администратора.
VENDORDAEMONPORT - Задает порт для компонента vendor daemon. По-умолчанию - 7279.
MNGMTCONSOLEWEBPORT - Порт на котором будет работать web-консоль. По-умолчанию - 8082.

В открывшемся Web-интерфейсе, справа в углу жмём Administration, и вводим пароль админа, который мы указали ранее.
Затем слева внизу переходим в раздел Vendor Daemon Configuration, и жмём кнопку Import License.
Выбираем наш файл лицензии, ставим галку Overwrite License File (ведь лицензия у нас только эта), и жмём Import License.
Далее жмём ОК, в списке лицензий выбираем нашу лицензию, и жмём кнопку Reread License.

Установка XenDesktop

Основным элементом XenDesktop 5.6 является Desktop Director Controller - сокращенно DDC. Этот компонент осуществляет взаимодействие с гипервизорами, управляет пулами виртуальных машин и предоставляет пользователям рабочее окружение. Этот компонент часто называют брокером (broker).
С ним взаимодействует Desktop Studio - интерфейс управления, выполненный в виде оснастки windows.
И есть еще один важный элемент - Desktop Director - основная консоль, которая предоставляет информацию о производительности и использовании рабочих мест, а также управляет правами пользователей.

XenDesktop в режиме PVS

Начало работы

citrix_vda_on_ubuntu_1604_kde

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Проблема

Пакет Citrix XenDesktop VDA 7.13 для Ubuntu 16.04 расчитан на установку в стандартной поставке Ubuntu с Unity (Gnome). Если попытаться установить пакет в Kubuntu 16.04 (или ubuntu server + KDE), то он не установится, ссылаясь на отсутствующую зависимость ubuntu-desktop.

Решение

Для того, чтобы установить Citrix XenDesktop VDA для Ubuntu 16.04 в Kubuntu 16.04 нужно отредактировать список зависимостей в пакете. Для этого:

dpkg-deb -x xendesktopvda_7.13.0.382-1.ubuntu16.04_amd64.deb vda_temp
dpkg-deb --control xendesktopvda_7.13.0.382-1.ubuntu16.04_amd64.deb vda_temp/DEBIAN
sed -i 's/, ubuntu-desktop.\{5,10\})//' ./vda_temp/DEBIAN/control
dpkg -b vda_temp xendesktopvda_7.13.0.382-1.Kubuntu16.04_amd64.deb

citrix_vda_remove_errors

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Проблема

На одном из серверов фермы Xendesktop 7.6 LTSR CU1 понадобилось переустановить VDA.
Однако, удалить VDA не удается. В моем случае возникали ошибки при удалении Citrix Profile Management - error 1603.
При этом, в списке сервисов сервис Citrix Profile Management отсутствовал.
При попытке удалить или починить (repair) Citrix Profile Management с помощью пакета profilemgt_x64.msi выводилось сообщение:

This action is only for products that are currently installed

При попытке заново установить пакет profilemgt_x64.msi выводилось сообщение, что продукт уже установлен (already installed).
Попытки обновить VDA до версии выше, чем 7.6 LTSR CU1 (например 7.8) обновление проходило, однако Citrix Profile Management не устанавливался и сервис не появлялся.

Причина

Судя по всему, причиной является то, что у инсталлятора не хватает прав на удаление некоторых файлов и записей в реестре поэтому в реестре остаются записи об установленном продукте, однако компоненты этого продукта уже удалены. Такие проблемы могут возникать не только с Citrix Profile Management. В логе инсталлятора VDA это выглядит примерно так:

09:25:21.9219 : XenDesktopSetup:Process completed with error code 1603
09:25:21.9219 $ERR$ : XenDesktopSetup:Installation of MSI File 'personalvDisk_x64.msi' failed with code 'InstallFailure' (1603).
09:25:21.9229 $ERR$ : XenDesktopSetup:InstallComponent: Failed to install component 'Personal vDisk'. Installation of MSI File 'personalvDisk_x64.msi' failed with code 'InstallFailure' (1603).
09:25:21.9239 $ERR$ : XenDesktopSetup:Recording installation failure. Installation of MSI File 'personalvDisk_x64.msi' failed with code 'InstallFailure' (1603).

Решение

В моем случае помогло удаление из реестра записи об установленном Citrix Profile Management в ветке HKEY_CLASSES_ROOT\Installer\Products\. Тут я с помощью поиска обнаружил ветку относящуюся к Citrix Profile management - она имела имя C0391239F35AC254085DEAA1D8969D0C и удалил ее.
После этого удалось штатным инсталлятором удалить VDA и установить нужную версию - 7.6 LTSR CU1.

powershell_script_for_batch_update_vda

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Для чего это всё

Данный скрипт предназначен для массового апдейта Citrix VDA (в моем случае с версии 7.8 до 7.15) на виртуальных (Machine Creation Service) либо физических машинах.
Разработка и тестирование этого скрипта проводились в сети с жесткими политиками безопасности, где запрещены файловые шары, невозможно использование RPC (в том числе psexec.exe - на машинах выключена служба “Сервер”), невозможно использование удаленного powershell, запрещена даже установка пакетов MSU с помощью wusa.exe. Есть только учетные данные локального администратора. Все манипуляции на удаленных машинах производятся с помощью вызова методов WMI.
В процессе тестирования были выявлены проблемы, связанные с библиотеками С++ (ошибки 1603, 1157 и 1723). Решение этой проблемы - ТУТ.

Как работает

Скрипт берет из указанного пула машины, версия VDA на которых не соответствует целевой.
Затем обрабатывает каждую машину в отдельном job. Переводит машину в Maintenance Mode, включает ее, дожидается включения, затем проверяет версию установленного VDA средствами WMI (на случай, если нужная версия уже установлена, но машина не регистрируется и на DDC новая версия не видна).
Затем скачивает с http-сервера VDA CleanUp Utility и запускает его. Выполняется удаление VDA (с нужным количеством перезагрузок).
Затем c http-сервера скачивается дистрибутив VDA, распаковывается, устанавливаются prerequisites, устанавливается нужный апдейт(ы) (пакет MSU).
Затем устанавливается VDA и проверяется его версия, а также возможность регистрации на DDC.
Скрипт способен выполняться параллельно на заданном числе машин. Сведения о проделанной работе сваливаются в файлик.

#$ErrorActionPreference='SilentlyContinue'

$catalogName='Developers'                         # Citrix Machine Catalog name
$MachinesPerRound=15                              # Number of simultaneously upgraded machines
$TargetAgentVersion='7.15.0.15097'                # Verision of VDA, showed in Citrix Studio and Director
$Citrix_DDC='ddc.domain.local'                    # FQDN of Citrix Delivery Controller
$timeout=1500                                     # Timeout for jobs in seconds
Asnp Citrix*


$jobContent={
    ########################################### Job Block ############################################################ 
            $update_server='http://updates.domain.local'                                         # HTTP Resource from which updates to be downloaded
            $VDA_sourcefile='VDAWorkstationSetup_7.15.exe'                                       # VDA distr file name on update server
            $VDA_destfile='c:\windows\temp\VDAWorkstationSetup_7.15.exe'                         # VDA distr file name on target machine
            $VDA_CleanUp_source_file='VDACleanupUtility.exe'                                     # VDA CleanUpUtility file name on update server
            $VDA_CleanUp_dest_file='c:\windows\temp\VDACleanupUtility.exe'                       # VDA CleanUpUtility file name on target machine
            $VDA_ExtractDir='c:\windows\temp\VDA_Install\'                                       # 
            $path_to_VDASetup='\Extract\Image-full\x64\XenDesktop Setup\XenDesktopVdaSetup.exe'  # Path to XenDesktopVDASetup.exe file
            $setupargs='/quiet /components VDA /controllers "ddc.domain.local ddc2.domain.local" /remotepc /optimize /virtualmachine /enable_hdx_ports /enable_real_time_transport'
            $ApplicationName = 'Citrix Virtual Desktop Agent - x64'
            $TargetVersion = '7.15.0.82' ### Version of $ApplicationName (Citrix Virtual Desktop Agent - x64) component 
            $Citrix_DDC='ddc.domain.local'
            $logfile='c:\temp\VDA_Update_Results.txt'

            $username='.\Администратор'
            $password='P@ssw0rd'

            $password = ConvertTo-SecureString $password -asplaintext -force
            $credentials = New-Object -Typename System.Management.Automation.PSCredential -argumentlist $username,$password
            $MachineName=$args[0]
            $Machine=Get-Brokermachine -MachineName $MachineName -AdminAddress $Citrix_DDC
            $node=$Machine.DNSName
    ############################################### Functions ##################################################

            function DownloadFile ($node, $credentials, $update_server, $source_file, $destination_file) {
                $link=$update_server+'/'+$source_file
                $posh_string = 'powershell -nop -exec bypass -c (New-Object Net.WebClient).DownloadFile(' + '''' + $link + '''' + ', ' + '''' + $destination_file + '''' + ')'
                Write-Host "Starting download file" $link to $destination_file
                $proc=Invoke-WmiMethod -Class win32_process -Name Create -Argumentlist $posh_string -Credential $credentials -Computername $node
                $duration=Measure-Command { 
                    do {
                    Start-Sleep -Seconds 1 
                    } 
                    until ((Get-WMIObject -Class Win32_process -Credential $credentials -Computername $node | where {$_.ProcessID -eq $proc.ProcessId}) -eq $null)
                }
                $query='Select * From CIM_datafile Where Name = ' + ''''+($destination_file -replace '\\', '\\')+''''
                $file=Get-WmiObject -query $query -Credential $credentials -Computername $node
                If ( $file -ne $null ) { 
                    Write-Host "Download completed in" $([math]::Round($duration.TotalSeconds,1)) "Seconds"
                    return 'OK' }
                else { 
                Write-Host "Download Failed"
                return 'DWNLD_FAILED' }
            }
            function VDACleanUp ($node, $credentials, $cleanuputility) {
            $runstring = 'cmd /c "'+ $cleanuputility + ' /unattended && mkdir c:\windows\temp\vdacleanup_ok || mkdir c:\windows\temp\reboot_needed"'
            $removerebootflag = 'cmd /c "rmdir /Q /S c:\windows\temp\reboot_needed"'
            $executable = Split-Path $cleanuputility -leaf
            do {
                if ((Get-WMIObject win32_bios -Credential $credentials -Computername $node) -ne $null) {
                    if ((Get-WmiObject -Class Win32_Directory  -Credential $credentials -Computername $node -Filter "Name='c:\\windows\\temp\\vdacleanup_ok'") -eq $null) {
                        if ((Get-WmiObject -Class Win32_Directory -Credential $credentials -Computername $node -Filter "Name='c:\\windows\\temp\\reboot_needed'") -eq $null) {
                            if ((Get-WMIObject -Class Win32_process -Credential $credentials -Computername $node | where {$_.Name -eq $executable}) -eq $null) {
                                Write-Host -NoNewLine 'VDA CleanUp in progress...'
                                $proc=Invoke-WmiMethod -Class win32_process -Name Create -Argumentlist $runstring -Credential $credentials -Computername $node
                                Start-Sleep -Seconds 10
                            } else { (Write-Host -NoNewLine "."), (Start-Sleep -Seconds 3) }
                        } else {
                        Write-Host ""
                        Write-Host "Rebooting..."
                        Invoke-WmiMethod -Class win32_process -Name Create -Argumentlist $removerebootflag -Credential $credentials -Computername $node | Out-Null
                        Start-Sleep -Seconds 4
                        if ((Get-WmiObject -Class Win32_Directory -Credential $credentials -Computername $node -Filter "Name='c:\\windows\\temp\\reboot_needed'") -eq $null) {
                            $Win32OS=Get-WMIObject Win32_OperatingSystem -computername $node -Credential $credentials -EnableAllPrivileges
                            $Win32OS.win32shutdown(6) | Out-Null }
                        else { Write-Host "Cannot remove c:\windows\temp\reboot_needed..." }
                        Start-Sleep -Seconds 30 
                        }
                    }
                    else {
                        Write-Host "CleanUp Completed"
                        $cleanup='OK'
                        Invoke-WmiMethod -Class win32_process -Name Create -Argumentlist 'cmd /c "rmdir /Q /S c:\windows\temp\vdacleanup_ok"' -Credential $credentials -Computername $node  | Out-Null
                        $setup_string='cmd /c "del /F /Q /S '+$cleanuputility+'"'
                        Invoke-WmiMethod -class Win32_Process -Name Create -Argumentlist $setup_string -Credential $credentials -Computername $node | Out-Null
                        return $cleanup
                    }
                }
                else {Start-Sleep -Seconds 15}
            }
            while ($cleanup -ne 'OK')

            }
            Function ExtractVDA ($node, $credentials, $VDA_distr, $VDA_ExtractDir) {
                $executable = Split-Path $VDA_distr -leaf
                Write-Host -NoNewLine "Extracting VDA..."
                $setup_string = 'cmd.exe /c "mkdir ' + $VDA_ExtractDir +'"'
                Invoke-WmiMethod -Class win32_process -Name Create -Argumentlist $setup_string -Credential $credentials -Computername $node | Out-Null
                $setup_string = $VDA_distr + ' /extract '+ $VDA_ExtractDir
                Invoke-WmiMethod -Class win32_process -Name Create -Argumentlist $setup_string -Credential $credentials -Computername $node | Out-Null
                Start-Sleep -Seconds 1
                do {(Write-Host -NoNewLine ".."), (Start-Sleep -Seconds 1)}
                while ((Get-WMIObject -Class Win32_process -Credential $credentials -Computername $node | where { $_.Name -eq $executable }) -ne $null)
                Write-Host "VDA extraction completed!"
                $setup_string='cmd /c "del /F /Q /S '+$VDA_distr+'"'
                Invoke-WmiMethod -class Win32_Process -Name Create -Argumentlist $setup_string -Credential $credentials -Computername $node | Out-Null
                return 'OK'
            }
            function InstallVDA ($node, $credentials, $VDA_ExtractDir, $path_to_VDASetup, $setupargs, $ApplicationName) {
                $executable = Split-Path $path_to_VDASetup -leaf
                $setup_string = $VDA_ExtractDir + '\' + $path_to_VDASetup + ' ' + $setupargs
                $iteration=0
                do {
                    Write-Host -NoNewLine "Setting up VDA... Running" $executable
                    Invoke-WmiMethod -class Win32_Process -Name Create -Argumentlist $setup_string -Credential $credentials -Computername $node | Out-Null
                    Start-Sleep -Seconds 2
                    do {(Write-Host -NoNewLine "."), (Start-Sleep -Seconds 1)}
                    while ((Get-WMIObject -Class Win32_process -Credential $credentials -Computername $node | where { $_.Name -eq $executable }) -ne $null)
                    $Win32OS=Get-WMIObject Win32_OperatingSystem -computername $node -Credential $credentials -EnableAllPrivileges
                    $Win32OS.win32shutdown(6) | Out-Null
                    Write-Host ""
                    Write-Host -NoNewLine "Rebooting..."
                    Start-Sleep 15
                    do { (Write-Host -NoNewLine "."), (Start-Sleep 15) }
                    While ((Get-WMIObject win32_bios -Credential $credentials -Computername $node) -eq $null)
                    $iteration++
                    $VDA_Present=Get-WMIObject -Class Win32_Product -Credential $credentials -Computername $node | Where-Object { $_.Name -like "*"+$ApplicationName+"*" }
                }
                While ( $VDA_Present -eq $null -and $iteration -lt 3 )
                if ( $VDA_Present -ne $null ) { (Write-Host "VDA Update Completed !!!")
                $status='OK' }
                else { $status='VDA_Not_Installed' }
                $setup_string='cmd /c "rmdir /Q /S '+$VDA_ExtractDir +'"'
                Invoke-WmiMethod -class Win32_Process -Name Create -Argumentlist $setup_string -Credential $credentials -Computername $node | Out-Null
                Return $status
            }
            function InstallPrerequisite ($node, $credentials, $VDA_ExtractDir, $path_to_setup) {
                $executable = Split-Path $path_to_setup -leaf
                $setup_string = $VDA_ExtractDir + $path_to_setup + ' /q /norestart'
                Write-Host -NoNewLine 'Setting up ' $setup_string
                Invoke-WmiMethod -class Win32_Process -Name Create -Argumentlist $setup_string -Credential $credentials -Computername $node | Out-Null
                Start-Sleep -Seconds 2
                do {(Write-Host -NoNewLine "."), (Start-Sleep -Seconds 1)}
                while ((Get-WMIObject -Class Win32_process -Credential $credentials -Computername $node | where { $_.Name -eq $executable }) -ne $null) 
                Write-Host "Complete!"
            }
            function Install_MSU ($node, $credentials, $update_server, $MSU_KBName) {
                $link=$update_server+'/'+$MSU_KBName
                $destination_file='c:\windows\temp\'+$MSU_KBName
                $posh_string = 'powershell -nop -exec bypass -c (New-Object Net.WebClient).DownloadFile(' + '''' + $link + '''' + ', ' + '''' + $destination_file + '''' + ')'
                $proc=Invoke-WmiMethod -Class win32_process -Name Create -Argumentlist $posh_string -Credential $credentials -Computername $node
                do {Start-Sleep -Seconds 1} 
                until ((Get-WMIObject -Class Win32_process -Credential $credentials -Computername $node | where {$_.ProcessID -eq $proc.ProcessId}) -eq $null)
                $query='Select * From CIM_datafile Where Name = ' + ''''+($destination_file -replace '\\', '\\')+''''
                $file=Get-WmiObject -query $query -Credential $credentials -Computername $node
                if ( $file -ne $null ){
                    Write-Host -NoNewLine "Start installation of " $MSU_KBName "...."
                    $MSU_ExtractDir='c:\windows\temp\'+($destination_file -replace '\.[^.\\/]+$').split('\')[-1]
                    $setup_string = 'cmd.exe /c "mkdir ' + $MSU_ExtractDir +'"'
                    $proc=Invoke-WmiMethod -Class win32_process -Name Create -Argumentlist $setup_string -Credential $credentials -Computername $node | Out-Null
                    do {Start-Sleep -Seconds 1} 
                    until ((Get-WMIObject -Class Win32_process -Credential $credentials -Computername $node | where {$_.ProcessID -eq $proc.ProcessId}) -eq $null)
                    $setup_string='wusa.exe '+$destination_file+' /extract:'+$MSU_ExtractDir 
                    $proc=Invoke-WmiMethod -class Win32_Process -Name Create -Argumentlist $setup_string -Credential $credentials -Computername $node | Out-Null
                    do {Start-Sleep -Seconds 1} 
                    until ((Get-WMIObject -Class Win32_process -Credential $credentials -Computername $node | where {$_.ProcessID -eq $proc.ProcessId}) -eq $null)
                    $cabname=($destination_file -replace '\.[^.\\/]+$').split('\')[-1] +'.cab'
                    $setup_string='cmd.exe /c "dism.exe /online /add-package /PackagePath:'+$MSU_ExtractDir+'\'+$cabname+'"'
                    $proc=Invoke-WmiMethod -class Win32_Process -Name Create -Argumentlist $setup_string -Credential $credentials -Computername $node | Out-Null
                    do {Start-Sleep -Seconds 1} 
                    until ((Get-WMIObject -Class Win32_process -Credential $credentials -Computername $node | where {$_.ProcessID -eq $proc.ProcessId}) -eq $null)
                    Start-Sleep -Seconds 15
                }
                else { (Write-Host "Download " $MSU_KBName "failed"), ($status='DWNLD_FAILED') }
                if ((Get-WMIObject -Class Win32_QuickFixEngineering -Credential $credentials -Computername $node | Where-Object { $_.HotFixID -like $cabname.split('-')[-2] }) -ne $null){(Write-Host 'Installation of ' $MSU_KBName 'completed!'), ($status='OK')}
                else { (Write-Host 'Installation of ' $MSU_KBName 'NOT completed!'), ($status='INSTALLATION_NOT_COMPLETED') }
                $setup_string='cmd /c "del /F /Q /S '+$destination_file+'"'
                Invoke-WmiMethod -class Win32_Process -Name Create -Argumentlist $setup_string -Credential $credentials -Computername $node | Out-Null
                $setup_string='cmd /c "rmdir /Q /S '+$MSU_ExtractDir+'"'
                Invoke-WmiMethod -class Win32_Process -Name Create -Argumentlist $setup_string -Credential $credentials -Computername $node | Out-Null
                return $status
            }
            function CheckVersion ($node, $credentials, $ApplicationName, $TargetVersion) {
                $App = Get-WMIObject -Class Win32_Product -Credential $credentials -Computername $node | Where-Object { $_.Name -like "*"+$ApplicationName+"*" }
                If (($App.Version).Equals($TargetVersion)) { 
                    Write-Host 'Installed version of the' $ApplicationName 'match target version'
                    return 'OK' }
                Else  { Write-Host 'Installed version of the' $ApplicationName 'NOT match target version'
                    return 'VersionBAD'}
            }
            function CheckFreeSpace ($node, $credentials){
                $Disk=get-WmiObject win32_logicaldisk -Credential $credentials -Computername $node | Where { $_.DeviceId -eq 'C:' }
                If ($Disk.FreeSpace -gt 1080000000) { return 'OK'}
                else { return 'LowDiskSpace'}
            }
    ######################################## Script ########################################################

            $duration=Measure-Command {
            $Result=$node+' '
            if ($args[0].SessionState -ne 'Active') {
            $InitialMaintenanceMode=(Get-BrokerMachine -MachineName $MachineName).InMaintenanceMode
            $InitialPowerState=(Get-BrokerMachine -MachineName $MachineName).PowerState
            #Enable MaintenanceMode
            Set-BrokerMachineMaintenanceMode -InputObject $MachineName $true
            if ((Get-BrokerMachine -MachineName $MachineName | fl InMaintenanceMode) -ne $null) {
                if ((Get-WMIObject win32_bios -Credential $credentials -Computername $node) -eq $null) { 
                    #PowerOn Machine
                    New-BrokerHostingPowerAction  -Action "TurnOn" -MachineName $MachineName
                    Write-Host -NoNewLine 'Starting Machine ' $node 
                    do { (Start-Sleep 5), (Write-Host -NoNewLine '.') }
                    while ((Get-WMIObject win32_bios -Credential $credentials -Computername $node) -eq $null)
                } 
                Start-Sleep 30
                #CheckVersion
                if ( (CheckVersion -node $node -credentials $credentials -ApplicationName $ApplicationName  -TargetVersion $TargetVersion) -ne 'OK' ) {
                    #Check FreeSpace on disk
                    if ((CheckFreeSpace -node $node -credentials $credentials) -eq 'OK') {
                        if ((DownloadFile -node $node -credentials $credentials -update_server $update_server -source_file $VDA_CleanUp_source_file -destination_file $VDA_CleanUp_dest_file) -eq 'OK') {
                            if ((VDACleanUp -node $node -credentials $credentials -cleanuputility $VDA_CleanUp_dest_file) -eq 'OK') {
                                if ((DownloadFile -node $node -credentials $credentials -update_server $update_server -source_file $VDA_sourcefile -destination_file $VDA_destfile) -eq 'OK') {
                                    ExtractVDA -node $node -credentials $credentials -VDA_distr $VDA_destfile -VDA_ExtractDir $VDA_ExtractDir
                                    InstallPrerequisite -node $node -credentials $credentials -VDA_ExtractDir $VDA_ExtractDir -path_to_setup '\Extract\Image-Full\Support\VcRedist_2013_RTM\vcredist_x86.exe'
                                    InstallPrerequisite -node $node -credentials $credentials -VDA_ExtractDir $VDA_ExtractDir -path_to_setup '\Extract\Image-Full\Support\VcRedist_2013_RTM\vcredist_x64.exe'
                                    InstallPrerequisite -node $node -credentials $credentials -VDA_ExtractDir $VDA_ExtractDir -path_to_setup '\Extract\Image-Full\Support\VcRedist_2015\vc_redist.x86.exe'
                                    InstallPrerequisite -node $node -credentials $credentials -VDA_ExtractDir $VDA_ExtractDir -path_to_setup '\Extract\Image-Full\Support\VcRedist_2015\vc_redist.x64.exe'
                                    if ((Install_MSU -node $node -credentials $credentials -update_server $update_server -MSU_KBName 'Windows6.1-KB2999226-x64.msu') -eq 'OK') {
                                        if ((InstallVDA -node $node -credentials $credentials -VDA_ExtractDir $VDA_ExtractDir -path_to_VDASetup $path_to_VDASetup -setupargs $setupargs -ApplicationName $ApplicationName) -eq 'OK') {
                                            if ((CheckVersion -node $node -credentials $credentials -ApplicationName $ApplicationName  -TargetVersion $TargetVersion) -eq 'OK'){ $result=$result+'VDA Installed. Version Checked.' }
                                            else { $result=$result+'VDA Present, But Version Mismatch.'}
                                        } else {  $result=$result+'VDA NOT Installed.' }
                                    } else {  $result=$result+'MSU Install failed.' }
                                } else {  $result=$result+'VDA Download Failed.' }
                            } else {  $result=$result+'VDA CleanUp Failed.' }
                        } else {  $result=$result+'VDA CleanUp Utility Download Failed.' }
                    } else { $result=$result+'Not enough disk free space.'}
                } else {  $result=$result+'No need to upgrade VDA.' }
            } else { $result=$result+'Can not enable maintenance mode.' }



            #Check if Machine registered successfully
            if ((Get-BrokerMachine -MachineName $MachineName -RegistrationState 'Registered') -ne $null) {
            $result=$result+' Machine Registered.' 
            #Revert to Initial MaintenanceMode
            Set-BrokerMachineMaintenanceMode -InputObject $MachineName $InitialMaintenanceMode
            }
                else {
                $result=$result+' Machine UnRegistered. Leave Machine in Maintenance Mode.'
                New-BrokerHostingPowerAction  -Action "ShutDown" -MachineName $MachineName
                }
            }
            #Revert to Initial Power State
            if ( $InitialPowerState -eq 'Off' ) { New-BrokerHostingPowerAction  -Action "ShutDown" -MachineName $MachineName } 
            $result=$result+' Initial Maintenance Mode - '+ $InitialMaintenanceMode + "Job completed in" $([math]::Round($duration.TotalSeconds,1)) "Seconds."
            $Result >> $logfile
            }
   }########################################## End of Job #######################################################

###################################################################################################################
$Filter='CatalogName -like "'+$catalogName+'" -and AgentVersion -ne "'+$TargetAgentVersion+'"'
Get-BrokerMachine -Filter $Filter -ReturnTotalRecordCount -AdminAddress $Citrix_DDC | out-null
$machinescount = $error[0].TotalAvailableResultCount
$rounds=[math]::floor($machinescount / $MachinesPerRound)

for ( $round=0; $round -le $rounds; $round++) {
    Write-Host 'Round - ' $round
    Get-Brokermachine -Filter $Filter -Skip ($round*$MachinesPerRound) -MaxRecordCount $MachinesPerRound -AdminAddress $Citrix_DDC | Select MachineName
    Get-Brokermachine -Filter $Filter -Skip ($round*$MachinesPerRound) -MaxRecordCount $MachinesPerRound -AdminAddress $Citrix_DDC | ForEach-Object {
    $jobname='VDA_Install_'+$_.HostedMachineName
    if ((Get-Job -name $jobname | Where { $_.State -eq "Running" } ) -eq $null) {
        Start-Job -name $jobname -initializationScript { Asnp Citrix* } -ArgumentList $_.MachineName -scriptblock $jobContent | out-null }
}
$timer=0
Do { 
    Start-Sleep 10
    Write-Host -NoNewline '.'
    $timer=$timer + 10
    }
while ((Get-Job | Where { $_.State -eq "Running" }) -ne $null -and $timer -lt $timeout)
If ($timer -ge $timeout) { 
    Write-Host 'Timeout for Jobs:'
    Get-Job | Where { $_.State -eq "Running" } | Select Name
    Get-Job | Where { $_.State -eq "Running" } | Stop-Job
}
Write-Host ' '
}

подготовка-к-экзамену-1y0-a26-citrix-xenserver-6-administration

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Компиляция и перевод - Усик Михаил aka Mike - mike@autosys.tk
Публикация и тиражирование только с разрешения. :)

Основано на гайде от CitrixExpierence - http://citrixxperience.com/free/A26ResourceGuide.pdf

Раздел 1 - Implementing XenServer

1.1 - Настройка параметров хоста XenServer для загрузки с SAN

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/installation.html#boot_from_san
Загрузка с SAN предоставляет ряд преимуществ - высокую производительность, избыточность и консолидацию ресурсов. В такой конфигурации загрузочный том находится в SAN, а не на локальном диске хоста. Бездисковый хост взаимодействует с SAN через соответствующий адаптер шины - host bus adapter (HBA). BIOS адаптера HBA содержит параметры, необходимые для того чтобы хост обнаружил загрузочный том.
Для загрузки с SAN требуется дисковый массив с интерфейсом Fibre Channel или iSCSI и соответствующий адаптер. Для создания полностью избыточной конфигурации нужно обеспечить несколько путей для доступа к массиву. Для этого на массиве нужно сконфигурировать поддержку multipath и включить multipathing на хосте XenServer после установки.

Для того чтобы установить XenServer на удаленный том SAN c multipathing:
- На экране приветствия (Welcome to XenServer) нажмите F2.
- At the boot prompt, enter multipath

Для того чтобы включить filesystem multipathing при установке PXE необходимо добавить device_mapper_multipath=yes в файл конфигурации PXE Linux. Пример файла:

default xenserver
label xenserver
  kernel mboot.c32
  append /tftpboot/xenserver/xen.gz dom0_mem=752M com1=115200,8n1 \
  console=com1,vga --- /tftpboot/xenserver/vmlinuz \
  xencons=hvc console=hvc0 console=tty0 \ 
  device_mapper_multipath=yes \
  --- /tftpboot/xenserver/install.img

1.2 - Конфигурирование сетевого интерфейса управления

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#networking-standalone_host_changing_network_config
Для того, чтобы изменить адаптер, используемый для управления хостом XenServer.
1. С помощью команды pif-list определите физический интерфейс (PIF) соответствующий сетевому адаптеру, который будет использоваться для управления. Команда вернет идентификаторы UUID всех PIF.

xe pif-list

2. С помощью команды pif-param-list проверьте конфигурацию адресов IP. Если необходимо - с помощью команды pif-reconfigure-ip сконфигурируйте IP.

xe pif-param-list uuid=<pif_uuid>

3. С помощью команды host-management-reconfigure задайте PIF, который должен использоваться для управления. Если хост входит в состав пула, то эту команду нужно выполнять из консоли хоста входящего в пул.

xe host-management-reconfigure pif-uuid=<pif_uuid>

ВНИМАНИЕ! Помещение основного интерфейса управления в сеть VLAN не поддерживается.

Отключение интерфейса управления

Для отключения интерфейса удаленного управления используйте команду host-management-disable.

ВНИМАНИЕ! Если интерфейс управления отключен, то для управления хостом и повторного включения интерфейса управления потребуется физический доступ к его консоли.

Изменение интерфейса управления с помощью XenCenter и xsconsole

http://support.citrix.com/article/CTX121235
Настройка в XenCenter
1. В XenCenter, кликните правой кнопкой на хосте и выберите Management Interfaces.
2. Из списка Network выберите сетевой адаптер, который должен быть назначен интерфейсом управления. Сконфигурируйте его параметры.

Настройка в xsconsole
1. В консоли сервера введите xsconsole. Запустится консоль управления хостом.
2. Выберите Network and Management Interfaces. Отобразится теуущий интерфейс управления - Network 0 или eth0. Нажмите Enter.
3. Выберите Configure Management Interface и нажмите Enter.
4. Введите учетные данные пользователя, имеющего права для настройки интерфейсов XenServer.
5. Выберите физический интерфейс, который должен стать интерфейсом управления (например eth1) и нажмите Enter.
6. Выберите способ конфигурирования - DHCP, DHCP with Manually Assigned Hostname, или Static IP address.
7. Если выбран Static - укажите IP address, Netmask, Gateway, и Hostname, и нажмите Enter.

1.3 - Конфигурирование сетевых параметров хоста XenServer

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#networking-standalone_host_changing_network_config

Изменение имени хоста - hostname

xe host-set-hostname-live host-uuid=<host_uuid> host-name=<host-name>

Доменное имя изменится автоматически.

Изменение IP-адреса для хоста не включенного в пул (standalone host)

Конфигурация сетевого интерфейса может быть изменена из командной строки с помощью команды pif-reconfigure-ip.

pif-reconfigure-ip uuid=<uuid_of_pif> [ mode=<dhcp> | mode=<static> ] \
gateway=<network_gateway_address> IP=<static_ip_for_this_pif> \
netmask=<netmask_for_this_pif> [DNS=<dns_address>]

Если указан режим

mode=<dhcp>

, то никакие дополнительные параметры можно не указывать.
Если указан режим

mode=<static>

, то нужно указать и все остальные параметры -

gateway=<network_gateway_address> IP=<static_ip_for_this_pif> netmask=<netmask_for_this_pif> [DNS=<dns_address>]

Изменение IP-адреса хоста, входящего в состав пула (не мастер-хоста)

Для изменения IP-адреса используется команда pif-reconfigure-ip.
Например:

xe pif-reconfigure-ip uuid=<pif_uuid> mode=DHCP

Затем с помощью команды host-list следует убедиться, что хост успешно переподключился к мастер-хосту пула и видны все хосты пула.

xe host-list

Изменение IP-адреса мастер-хоста пула

Изменение IP-адреса мастер-хоста пула требует дополнительных действий для того, чтобы каждый хост пула смог использовать измененный адрес.

ВНИМАНИЕ! Всегда, когда возможно следует использовать единственный выделенный адрес для мастер-хостов, не изменяющийся все время жизни пула.

xe pif-reconfigure-ip uuid=<pif_uuid> mode=DHCP

После изменения IP-адреса мастер-хоста все члены пула перейдут в сосотояние emergency mode, т.к. не смогут соединиться с мастер-хостом.
Для того чтобы мастер-хост смог уведомить членов пула об изменении своего IP-адреса используется команда pool-recover-slaves

xe pool-recover-slaves

Аутентификация с помощью AD

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#ad_int_configuring
XenServer поддерживает аутентификацию пользователей в домене Windows 2003 или более новой.

Для аутентификации в Active Directory на хосте XenServer должны быть прописаны серверы DNS, используемые в домене. В некоторых случаях, необходимые параметры DNS могут раздаваться централизовано, с помощью DHCP. Citrix рекомендует использовать DHCP для правильного конфигурирования хостов XenServer (например не следует использовать имена хостов типа localhost или linux).

ВНИМАНИЕ! Имена хостов XenServer должны быть уникальны в пределах инсталляции

Учитывайте следующее:
- Хосты XenServer прописываются в базу данных AD с помощью имен хостов (hostname). Следовательно, если два хоста XenServer присоединятся к домену с одинаковыми именами, то второй присоединившийся сервер перезапишет запись в AD первого сервера, независимо от того, входят сервера в один пул или нет. В результате - у первого сервера аутентификация AD работать не будет.
- Использовать одинаковые hostname у двух хостов XenServer можно, если они входят в разные домены.
- Хосты XenServer могут быть в разных временных зонах (time-zones), т.к. время на хостах сравнивается в формате UTC. Для того чтобы гарантировать синхронизацию времени в пределах домена следует использовать один и тот же сервер времени NTP на хостах XenServer и сервере AD.
- В пределах пула не поддерживается смешанная аутентификация. Это означает, что невозможно создать пул, в котором часть серверов входят в домен, а часть нет.
- Для взаимодействия с сервером домена AD хосты XenServer используют протокол Kerberos. Таким образом, хосты XenServer не смогут работать с серверами Active Directory, на которых отключен протокол Kerberos.
- Для корректной работы аутентификации XenServer в Active Directory важно, чтобы часы хостов XenServer были сонхронизированы с часами сервера AD. При присоединении хоста XenServer к домену синхронизация часов проверяется и если часы идут неверно, то присоединение не удастся.

ВНИМАНИЕ! Имена хостов XenServer присоединяемых к AD не могут состоять целиком из цифр и быть длиннее 63 символов

Если вы включили для пула аутентификацию AD и затем присоединяете к пулу хост XenServer, то потребуется присоединить новый хост XenServer к домену. Для присоединения понядобится ввести учетные данные пользователя, обладающего привилегиями, достаточными для присоединения хоста к домену.

Если между сервером AD и хостами XenServer есть межсетевой экран (firewall), то для корректной работы нужно открыть порты для исходящего трафика от хостов к серверу AD:

Port Protocol Use
53 UDP/TCP DNS
88 UDP/TCP Kerberos 5
123 UDP NTP
137 UDP NetBIOS Name Service
139 TCP NetBIOS Session (SMB)
389 UDP/TCP LDAP
445 TCP SMB over TCP
464 UDP/TCP Machine password changes
3268 TCP Global Catalog Search

Примечание. Для просмотра заданных правил firewall на хосте linux c iptables нужно использовать команду: iptables - nL

Примечание. Для аутентификации в AD XenServer использует Likewise, а Likewise использует Kerberos для шифрования трафика между сервером AD и хостом XenServer.

Также как и машины Windows, Likewise автоматически обновляет пароль учетной записи хоста XnServer каждые 30 дней (или в соответствии с заданной политикой). Дополнительная информация - http://support.microsoft.com/kb/154501.

Включение аутентификации в AD

Аутентификация в AD может быть включена как с помощью XenCenter, так и в CLI:

    xe pool-enable-external-auth auth-type=AD \
      service-name=<full-qualified-domain> \
      config:user=<username> \
      config:pass=<password>

Пользователь должен обладать правами добавления/удаления учетных записей компьютеров в домене (Add/remove computer objects or workstations privileges).

Отключение внешней аутентификации

Испоьзуйте XenCenter для отключения аутентификации Active Directory или такую команду CLI:

    xe pool-disable-external-auth

1.4 - Конфигурирование синхронизации времени на хосте XenServer

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/installation.html#installing_xs_host
Задать временную зону и сервер с которым XenServer будет синхронизировать часы можно при установке XenServer. Кроме того, текущее время можно установить и вручную.
Задать сервер NTP можно как вручную, так и использовать заданный в конфигурации DHCP.

Установка и конфигурирование локального сервера NTP

http://support.citrix.com/article/CTX116307
Если при работе XenServer с удаленной административной консолью возникают ошибки SSL, возможно, часы хоста XenServer несихронизированы с часами хоста на котром исполняется удаленная консоль.
Решить эту проблему можно установив локальный NTP сервер, с которым будут синхронизированы хосты XenServer и хост с управляющей консолью.
- Установите пакет сервера NTP. Он может называться примерно так: ntp- и номер версии. Например - ntp-4.2.0.xxxxx.
- После установки отредактируйте файл /etc/ntp.conf и укажите в нем серверы stratum1 и stratum2, с которыми будет синхронизирован локальный сервер NTP:

server yourntp.server.org # stratum1
    server secondntp.some.org # stratum2

- Укажите параметры доступа, для того чтобы разрешить использование этих серверов на вашем сервере. Приведенные строки запрещают изменять информацию во время исполнения или делать запросы к вашему серверу NTP:

    restrict yourntp.server.org mask 255.255.255.255 nomodify notrap noquery
    restrict secondntp.server.org mask 255.255.255.255 nomodify notrap noquery

- Если вы планируете использовать этот сервер для синхронизации времени в вашей локальной сети - следует разрешить запросы синхронизации из этой сети. Добавьте:

restrict 192.168.0.1 mask 255.255.255.0 nomodify notrap

^Примечание: тут отсутствует параметр noquery^
- Запустите сервис с помощью команды:

service ntp start

- С помощью следующей команды включите автозагрузку сервиса:

chkconfig ntpd on

- Укажите имя этого сервера при установке XenServer на хост. На уже установелнном хосте XenServer отредактируйте файл /etc/ntp.conf и добавьте в него строку:

server ntp-server_ip

- С помощью следующей команды синхронизируйте хост XenServer с заданным сервером NTP:

ntpdate -u NTP_server_ip

- С помощью следующей команды убедитесь, что хост XenServer использует правильный сервер NTP:

ntpq -p

Как сменить таймзону на работающем хосте XenServer

Есть возможность сменить таймзону на рвботающем хосте XenServer.
Информация о текущей таймзоне задается в файле /etc/localtime. Этот файл является симлинком (symlink) на конкретный файл таймзоны, хранящийся в папке /usr/share/zoneinfo. В этой папке хрянятся файлы соответствующие разным таймзонам. Например, если при установке выбрана зона America и location New York, то в /etc/localtime будет ссылаться на /usr/share/zoneinfo/America/New_York.
Если нужно сменить таймзону, то нужно просто перезаписать симлинк /etc/localtime.

В нижеприведенном примере изменяется таймзона с America/New York на Pacific/Auckland:

1. Войдите на хост XenServer с учеткой root.
2. Проверьте текущую таймзону:

# date
Wed Dec 6 15:54:01 EST 2006

# ls -l /etc/localtime
lrwxrwxrwx 1 root root 36 Dec 6 15:55 /etc/localtime --> /usr/share/zoneinfo/America/New_York

3. Переименуйте текущий симлинк на всякий случай:

# mv /etc/localtime /etc/localtime.bak

4. Создайте новый симлинк на нужный файл таймзоны:

# ln -s /usr/share/zoneinfo/Pacific/Auckland /etc/localtime

5. Убедитесь, что новый симлинк создался:

# ls -l /etc/localtime
lrwxrwxrwx 1 root root 36 Dec 6 10:04 /etc/localtime --> /usr/share/zoneinfo/Pacific/Auckland

6. Убедитесь, что таймзона сменилась:

# date
Wed Dec 7 10:05:41 NZDT 2006

Раздел 2 - Управление и поддержка хостов XenServer

Выбор конфигурируемого хоста

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#cli-xe-commands_hostselectors
Многие команды команды конфигурирующие хосты XenServer требуют явного указания хоста, к которому происходит обращение. Самый простой способ указать имя хоста с помощью аргумента host=uuid_or_name_label. Кроме того, хосты могут быть указаны с помощью фильтрации полного списка хостов по значениям заданных полей. Например - указав enabled=true можно выбрать только те хосты, у которых включено заданное свойство. Если фильтру соответствуют несколько хостов и операция должна быть выполнена над всеми ними, то следует указывать опцию

--multiple

. Полный список параметров хостов может быть получен командой xe host-list params=all. Если в команде явно не указан никакой хост, то команда будет выполнена на всех хостах пула.

2.1 - Применение патчей и хотфиксов

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/installation.html#applying_hotfixes
Между релизами XenServer, Citrix выпускает апдейты и хотфиксы (updates and hotfixes). Хотфиксы исправляют отдельные ошибки, а апдейты содерждат в себе множественные кумулятивные исправления и обновления функционала.
Публичные хотфиксы и апдейты бывают доступны для скачивания из Citrix Knowledge Center. Конкретная информация и инструкции, касающиеся каждого пакета также публикуются.
Хотфиксы и апдейты как правило устанавливаются с минимальным воздействием на инфраструктуру XenServer. При использовании пула серверов XenServer можно сократить время простоя обновляя сервера по одному, перемещая работающие на них виртуальные машины на другие сервера. XenCenter позволяет осуществить эти действия в правильной последовательности автоматически. При использовании интерфейса командной строки xe, эти действия нужно делать вручную.

Перед применением хотфикса или апдейта

ВАЖНО! При применении обновлений важно четко следовать инструкциям.

Перед применением обновлений важно знать:
- Лучше всего применять обновления в течение короткого промежутка времени, т.к. работа пулов в смешанном режиме (когда одни сервера уже имеют обновления, а другие нет) не поддерживается.
- Citrix рекомендует, перед применением обновлений перезагрузить каждый хост XenServer, что позволит убедиться в его работоспособности и корректности конфигурации.

ПРИМЕЧАНИЕ: XenCenter перезагрузит каждый хост автоматически во время работы мастера обновления, перед применением обновления. Если для обновления используется интерфейс xe CLI, то перезагрузку нужно выполнить вручную.

- Citrix также рекомендует сделать резервную копию состояния обновляемого пула (или индивидуальных хостов).

Перед обновлением:
- Войдите на сервер с учетной записью, имеющей полные права (Pool Administrator или локальный root).
- У всех останавливаемых виртуальных машин нужно извлечь CD/DVD (сделать empty).
- Если включена высокая доступность (HA) - отключите ее.

Если планируется применить обновление с помощью XenCenter, то XenCenter запустит ряд проверок, которые позволят убедиться, что хост готов к обновлению и совместим с данным обновлением. Эти проверки являются частью работы мастера обновлений и в случае неудачной проверки будет выведено соответствующее сообщение.

Обновление отдельных хостов XenServer

Для обноления хоста с помощью XenCenter:

1. Скачайте обновление (файл с расширением .xsupdate) на компьютер, на котором работает XenCenter.
2. Остановите (Shut down или suspend) все виртуальные машины на обновляемом хосте.
3. В меню Tools выберите Install New Update. Откроется мастер обновления.
4. Прочитайте информацию и кликните Next для продолжения.
5. Выберите Add, и затем укажите скачанный файл обновления. Кликните Open. После того как файл добавится кликните Next для продолжения.
6. Выберите один или более хостов для применения обновления.
7. Следуйте рекомендациям для разрешения проблем, выявленных при проверках. Если вы хотите, чтобы XenCenter автоматически решил все обнаруженные проблемы - кликните Resolve All. После успешного прохождения всех проверок кликните Next для продолжения.
8. Выберите режим обновления - автоматический (automatic) или вручную (manual).
Если выбран автоматический режим, то XenCenter выполнит все необходимые действия после обновления (например перезагрузку хоста). Если выбран ручной, то требуемые дейтсвия надо выполнить вручную. Необходимые действия, выполняемые после обновления перечислены в списке ниже. Если вы хотите сохранить список в текстовый файл - кликните Save to File.
Кликните Install update для продолжения обновления.
Мастер обновления отобразит прогресс обновления, сообщая об основных произведенных операциях.

9. По окончании обновления кликните Finish для того чтобы закрыть мастер обновления.
10. Если был выбран способ обновления вручную, то сейчас следует выполнить предписанные действия.

Обновление отдельного хоста с помощью интерфейса xe CLI:

1. Скачайте обновление (файл с расширением .xsupdate) на компьютер, на котором выполняются команды xe CLI. Запомните путь к файлу.
2. Остановите (Shut down или suspend) все виртуальные машины на обновляемом хосте с помощью команд vm-shutdown или vm-suspend.
3. Загрузите файл обновления на обновляемый хост командой:

xe -s <server> -u <username> -pw <password> patch-upload file-name=<filename>

Тут ключ -s указывает имя хоста (то есть имя FQDN или просто IP-адрес). XenServer присвоит файлу обновления UUID, который будет отображен. Запомните UUID.

СОВЕТ: После загрузки файла обновления на хост можно использовать команды patch-list и patch-param-list для просмотра информации о файле обновления.

4. Если XenServer обнаружит ошибки или то, что не были выполнены подготовительные действия - (например на хоте остались запущенные виртуальные машины) он предупредит. Перед тем как продолжить обновление убедитесь, что все нужные шаги выполнены.
5. Обновите хост, указав UUID хоста и файла обновлений:

xe patch-apply host-uuid=<UUID_of_host> uuid=<UUID_of_file>

Обновление пула серверов XenServer

При обновлении пула с помощью XenCenter, мастер обновления Install Update автоматически определяет этапы обновления и выполняет миграцию виртуальных машин. Если требуется управлять процессом обновления и миграцией виртуальных машин вручную, то можно обновлять каждый хост отдельно, при этом основхой хост пула (pool master) следует обновлять в первую очередь.

Обновление пула с помощью XenCenter:
1. Скачайте обновление (файл с расширением .xsupdate) на компьютер, на котором работает XenCenter.
2. Если в пуле есть виртуальные машины, которые надо остановить вручную (а не автоматически) - сделайте это.
3. В меню Tools выберите Install New Update. Откроется мастер обновления.
4. Прочитайте информацию и кликните Next для продолжения.
5. Выберите Add, и затем укажите скачанный файл обновления. Кликните Open. После того как файл добавится кликните Next для продолжения.
6. Выберите пул для применения обновления. Кликните Next.
7. Следуйте рекомендациям для разрешения проблем, выявленных при проверках. Если вы хотите, чтобы XenCenter автоматически решил все обнаруженные проблемы - кликните Resolve All. После успешного прохождения всех проверок кликните Next для продолжения.
8. Выберите режим обновления - автоматический (automatic) или вручную (manual).
Если выбран автоматический режим, то XenCenter выполнит все необходимые действия после обновления (например перезагрузку хостов). Если выбран ручной, то требуемые действия надо выполнить вручную. Необходимые действия, выполняемые после обновления перечислены в списке ниже. Если вы хотите сохранить список в текстовый файл - кликните Save to File.
Кликните Install update для продолжения обновления.
Мастер обновления отобразит прогресс обновления, сообщая об основных произведенных операциях на каждом хосте пула.
Во время обновления основного хоста пула (pool master) XenCenter временно отсоединится от пула.

Обновление пула серверов XenServer с помощью '''xe CLI''':

1. Скачайте обновление (файл с расширением .xsupdate) на компьютер, на котором выполняются команды xe CLI. Запомните путь к файлу.
2. Загрузите файл обновления на основной хост пула (pool master) командой:

xe -s <server> -u <username> -pw <password> patch-upload file-name=<filename>

Тут ключ -s указывает имя хоста pool master. XenServer присвоит файлу обновления UUID, который будет отображен. Запомните UUID.

СОВЕТ: После загрузки файла обновления на хост можно использовать команды patch-list и patch-param-list для просмотра информации о файле обновления.

4. Если XenServer обнаружит ошибки или то, что не были выполнены подготовительные действия - (например в пуле остались запущенные виртуальные машины) он предупредит. Перед тем как продолжить обновление убедитесь, что все нужные шаги выполнены.

5. Обновите хост, указав UUID хоста и файла обновлений:

xe patch-apply host-uuid=<UUID_of_host> uuid=<UUID_of_file>

6. Убедитесь, что обновление прошло правильно с помощью команды patch-list. Если обновление прошло успешно, то поле hosts содержит UUID хоста.
7. Выполните необходимые после обновления операции (перезагрузка и др.).
Если нужно - остановите (Shut down или suspend) виртуальные машины в обновляемом пуле с помощью команд vm-shutdown или vm-suspend.
Для того чтобы конкретные виртуальные машины мигрировали на конкретный хост можно использовать команду vm-migrate. С помощью команды vm-migrate можно осуществлять полный контроль над распределением виртуальных машин по хостам пула.
Для автоматической “живой” миграции всех виртуальных машин внутри пула используйте команду host-evacuate.

5. Обновите пул, указав UUID файла обновлений:

xe patch-pool-apply uuid=<UUID_of_file>

Эта команда применит обновление ко всем хостам пула.
Кроме того. можно применять обновления и к конкретным хостам командой. содержащей UUID конкретного хоста:

xe patch-apply host-uuid=<UUID_of_host> uuid=<UUID_of_file>

ПРИМЕЧАНИЕ: Если после обновления нужно освободить место на дисках мастерхоста, то это можно сделать удалив файлы обновлений командой patch-clean. При необходимости эти файлы можно закачать повторно командой patch-upload.

При применении обновлении появляется сообщение: '''The upload update already exist. Check your settings and try again'''

http://support.citrix.com/article/CTX121325
Симптомы:
На хост уже установлены пакеты обновлений 1 и 2. При применении пакета обновления 3 появляется сообщение:
“Update Uploaded to Server <your server>
The upload update already exists
Check your settings and try again.”

2.2 - Как выключить (shut down) хост XenServer без ущерба общей производительности

Для выключения или перезагрузки хоста XenServer, входящего в состав пула следует выполнить несколько предварительных шагов, которые подготовят хост к выключению.

Отключение хоста - запрет на запуск новых виртуальных машин

Для того чтобы запретить запуск на хосте виртуальных машин предусмотрена команда host-disable:

host-disable [<host-selector>=<host_selector_value>...]

Хосты на которых следует выполнить эту операцию выбираются с помощью стандартных селекотров. Дополнительными аргументами могут быть любое число параметров хоста, описанных тут: http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#cli-xe-commands_hostparameters .

Эвакуация хоста - '''host-evacuate'''

host-evacuate ''<host-selector>=<host_selector_value>''...

Эта команда осуществляет “живую” миграцию виртеальных машин на другие хосты пула. Перед использованием этой команды хот должен быть отключен с комопщью команды host-disable.
Если эвакуируемый хост является мастер-хостом пула, то должен быть выбран другой мастерхост. Для переназначения мастер-хоста при отключенной высокой доступности (HA) необходимо выполнить команду pool-designate-new-master (см. http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#cli-xe-commands_pool-designate-new-master). При включенной высокой доступности (HA) можно просто выключить хост. Выборы нового мастер-хоста произойдут автоматически путем случайного выбора из имеющихся хостов.
Хосты на которых должна быть выполнена эта команда задаются с помощью стандартных селекторов.

Перезагрузка хоста - '''host-reboot'''

host-reboot [<host-selector>=<host_selector_value>...]

Эта команда перезагружает указанный хост(ы). Перед перезагрузкой на хостах нужно запретить запуск новых виртуальных машин командой xe host-disable , в противном случае будет выведено сообщение об ошибке - HOST_IN_USE.
Хосты на которых должна быть выполнена эта команда задаются с помощью стандартных селекторов.

Если указанный хост является членом пула, то после перезагрузки он восстановится в пуле. Если перезагружается мастер-хост пула, то пул не будет работать до тех пор, пока мастер-хост пула не будет доступен снова. При включенной высокой доступности (HA) выборы нового мастер-хоста пройдут автоматически.

Обработка отказов хостов XenServer

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#pool_failures

Отказ рядовых хостов пула

При отсутствии высокой доступности (HA) мастер-хост следит за регулярными хертбитами (heartbeat messages). Если от хоста не приходит хертбит в течение 600 секунд - хост считается не работающим. Решить эту проблему можно двумя путями:
Первый - восстановить работоспособность хоста (т.е. просто физически перезагрузить). После перезагрузки хост снова начнет слать хертбиты и восстановится в пуле.
Второй - Полностью выключить отказавший хост и указать мастер-хосту чтобы он “забыл” отказавший хост с помощью команды xe host-forget. После того как отказавший хост “забыт” все виртуальные машины на нем работавшие помечаются как выключенные и могут быть повторно запущены на других хостах пула. Учтите, что крайне важно, чтобы отказавший хост XenServer был действительно выключен. В противном случае - возможно, что оставшиеся на нем работать экземпляры виртуальных машин будут конфликтовать с вновь запущенными в пуле, что может привести к повреждению данных виртуальных машин. Также возможно, что в результате выполнения команды xe host-forget единый пул будет разделен на множество пулов, состоящих из одного хоста. Это приведет к тому, что все эти пулы будут обращаться к одному общему хранилищу (shared storage), что также может привести к повреждению данных виртуальных машин.

Не используйте команду xe host-forget при включенной высокой доступности (HA). Перед применением xe host-forget следует выключить (HA), а после применения включить снова.^
Может так случиться, что хост вышел из строя, но виртуальные машины по прежнему имеют статус работающих (running state). Если вы уверены в том, что хост действительно выключен, выполните команду xe vm-reset-powerstate для того чтобы изменить состояние виртуальных машин на halted (см. http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#cli-xe-commands_vm-reset-powerstate).

ВНИМАНИЕ! используйте эту команду только если вы полностью уверены в ее необходимости, т.к. неправильное использование может привести к повреждению данных.

Перед тем как запустить виртуальные машины на другом хосте понадобится снять блокировки на хранилище виртуальных машин. Каждый диск виртуальной машины, хранящийся в хранилище в каждый момент времени может использоваться только одним хостом XenServer. Таким образом, для того чтобы другой хост вместо отказавшего мог использовать диски виртуальных машин следует запустить скрипт на мастер-хосте пула для каждого хранилища (SR), хранящего диски пострадавших виртуальных машин:

/opt/xensource/sm/resetvdis.py <host_UUID> <SR_UUID> [master]

Третий аргумент master следует использовать только если хост был мастером хранилища (SR) - то есть мастер-хостом пула или если хост XenServer использовал локальное хранилище в момент отказа.

ВНИМАНИЕ! используйте эту команду только если вы полностью уверены что пострадавший хост выключен, т.к. неправильное использование может привести к повреждению данных.

Если вы попытаетесь запустить виртуальную машин на другом хосте, перед тем как выполнили этот скрипт (если на хранилище остались блокировки), то будет выведено сообщение об ошибке - VDI <UUID> already attached RW.

Отказ мастер-хоста

Каждый член пула имеею всю необходимую информацию, чтобы стать мастер-хостом в случае необходимости. При отказе мастер хоста происходит следующее:
1. Если высокая доступность (HA) включена - новый мастер-хост выбирается автоматически.
2. Если высокая доступность (HA) отключена, то члены пула будут ждать появления нового мастер-хоста.
Если мастер-хост вернется к работе в этот момент, то соединения в пуле будут восстановлены и пул продолжит нормальную работу.
Если мастер-хост действительно сдох, то нужно выбрать новый мастер-хост и запустить а нем команду xe pool-emergency-transition-to-master и он станет мастер-хостом. Затем для восстановления подключений членов пула к новому мастер-хосту следует выполнить команду xe pool-recover-slaves.
Если старый мастер-хост буде впоследствии восстановлен, то на нем следует просто переустановить XenServer и просто добавить его в пул.
После того, как был назначен новый мастер-хост следует проверить, что используется правильное хранилище пула по-умолчанию (default pool storage repository). Это можно сделать командой xe pool-param-list, в выводе которой есть параметр default-SR.

Отказы пула вцелом

Иногда бывает так, что пул разваливается совсем и нужно восстановить базу данных пула. Убедитесь, что вы регулярно делаете резервные копии базы данных пула с помощью команды xe pool-dump-database (см. http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#cli-xe-commands_pool-dump-database).
Для восстановления разваленного пула:
1. Установите на новые хосты XenServer. Не создавайте пул.
2. На хосте которы должен стать мастер-хостом восстановите базу данных пула из резервной копии командой xe pool-restore-database (см. http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#cli-xe-commands_pool-restore-database).
3. Подключитесь к мастер-хосту консолью XenCenter и убедитесь, что общее хранилище и виртуальные машины на месте.
4. Выполните присоединение членов пула к пулу и запустите виртуальные машины.

Если новый мастер-хост не видит хранилище, то следует восстнаовить физичесоке подключение к хранилищу, а затем изменить конфигурацию хоста с помощью команд pbd-destroy (уничтожение неработающего хранилища) и pbd-create (создание нового) (см.http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#cli-xe-commands_pbd).
Если вы создали новое хранилище, то затем присоедините физическое устройство к нему командой pbd-plug или с помощью XenCenter - Storage > Repair Storage Repository.

Перезагрузка хоста - '''host-reboot'''

host-reboot [<host-selector>=<host_selector_value>...]

Обработка отказов хостов XenServer

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#pool_failures

Отказ рядовых хостов пула

Первый - восстановить работоспособность хоста (т.е. просто физически перезагрузить). После перезагрузки хост снова начнет слать хертбиты и восстановится в пуле.
Второй - Полностью выключить отказавший хост и указать мастер-хосту чтобы он “забыл” отказавший хост с помощью команды xe host-forget. После того как отказавший хост “забыт” все виртуальные машины на нем работавшие помечаются как выключенные и могут быть повторно запущены на других хостах пула. Учтите, что крайне важно, чтобы отказавший хост XenServer был действительно выключен. В противном случае - возможно, что оставшиеся на нем работать экземпляры виртуальных машин будут конфликтовать с вновь запущенными в пуле, что может привести к повреждению данных виртуальных машин. Также возможно, что в результате выполнения команды xe host-forget единый пул будет разделен на множество пулов, состоящих из одного хоста. Это приведет к тому, что все эти пулы будут обращаться к одному общему хранилищу (shared storage), что также может привести к повреждению данных виртуальных машин.

2.3 - Восстановление работы хоста при включенной высокой доступности (HA)

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#id873168
Если на хосте включена HA, но по какой-то причине хосту не доступен файл состояния HA (HA statefile), то хост может стать недоступным (unreachable). Для восстановления нормальной работы может понадобиться отключить HA с помощью команды host-emergency-ha-disable:

xe host-emergency-ha-disable --force

Если хост был мастером пула (pool master), то он должен запуститься нормально с отключенной HA. Подчиненные хосты должны переподключиться и также автоматически отключить HA. Если хост был подчиненным (Pool slave) и не может подключиться к мастерхосту, то может понадобиться принудительная перезагрузка хоста в режиме мастерхоста (xe pool-emergency-transition-to-master) или сообщить хосту где теперь новый мастерхост (xe pool-emergency-reset-master):

xe pool-emergency-transition-to-master uuid=<host_uuid>		
xe pool-emergency-reset-master master-address=<new_master_hostname>

Когда все хосты успешно стартовали, можно заново включить HA:

xe pool-ha-enable heartbeat-sr-uuid=<sr_uuid>

2.4 - Настройка e-mail уведомлений на уровне пула, хоста или виртуальной машины

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#monitoring_xenserver
http://support.citrix.com/article/CTX136679
Можно настроить XenServer так, чтобы он оповещал администратора о различных системных событиях. Настройки можно произвести либо с помощью XenCenter, либо с помощью консоли командной строки.
По-умолчанию для отправки уведомлений используется SMTP сервер, не требующий аутентификации.
Для отправки оповещений через SMTP сервер, требующий аутентификации нужно указать соответствующие данные в конфигурационном файле /etc/mail-alarm.conf.

Включение уведомлений в XenCenter:
- Кликните правой кнопкой по хосту или пулу и выберите Properties.
- В окне Properties выберите Email Options.
- Поставьте флажок Send email alert notifications и введите адрес e-mail и SMTP сервер (не требующий аутентификации).

Включение уведомлений с помощью командной строки:
- Зайдите на сервер по учетной записью root (неважно, в консоли XenCenter или по SSH).
- Выполните следующие команды:

 xe pool-param-set uuid=<uuid> other-config:mail-destination=<joe.bloggs@domain.tld>
        xe pool-param-set uuid=<uuid> other-config:ssmtp-mailhub=<smtp.domain.tld[:port]>

Конфигурирование отправки алертов через SMTP-сервер, требующий аутентификации

Утилита mail-alarm перед отправкой уведомления проверяет конфигурационный файл /etc/mail-alarm.conf. Если файл существует - его содержимое используется для отправки. Если его не существует - используются данные из базы XAPI (сконфигурированные в XenCenter или xe CLI).
Содержимое файла /etc/mail-alarm.conf должно быть таким:

    root=postmaster
    authUser=<username>
    authPass=<password>
    mailhub=<server address>:<port>

2.5 - Интеграция XenServer в Active Directory

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#ad_int
Если вы хотите аутентифицировать много пользователей для работы с XenServer, то нужно использовать учетные записи Active Directory. Это даст возможность подключаться к XenServer с учетными данными домена Windows.
Единственный способ управлять уровнем доступа к XenServer - это включить аутентификацию Active Directory, добавить учетные записи пользователей и назначить им роли.
Пользователи Active Directory могут использовать и интерфейс командной строки (указывая свои учетные данные в аргументах -u и -pw), а также подключаться к хостам XenServer c помощью XenCenter.
Контроль доступа осуществляется на уровне субъектов (subjects). Субъект в XenServer соответствует учетной записи в AD (пользовательской или групповой). При включенной внешней аутентификации введенные учетные данные сначала сравниваются с данными локального пользователя root, а затем со списком субъектов. Для предоставления прав доступа необходимо создать запись субъекта для пользователя или группы AD. Это может быть сделано из командной строки или XenCenter.

ПРИМЕЧАНИЕ: При входе пользователя с учетными данными AD не требуется указывать полное имя (в формате mydomain\myuser или myser@mydomain.com), потому что XenCenter всегда пытается войти в домен к которому присоединен XenServer. Исключение составляет учетная запись локального суперпользователя (LSU), которая всегда аутентифицируется локально.

Порядок аутентификации обычно такой:
- Учетные данные передаются контроллеру домена Active Directory.
- Контроллер домена проверяет учетные данные и если они не верны, то аутентификация немедленно прерывается.
- Если учетные данные верны, то у контроллера домена запрашивается идентификатор субъекта и групповая принадлежность.
- Если идентификатор субъекта соответствует тому, который хранится в XenServer, аутентификация завершается успешно.

Примечание: не поддерживается изменение вручную DNS серверов, назначенных с помощью DHCP, т.к. неправильная конфигурация может привести к неправильной работе Active Directory и невозможности аутентифицироваться.

Присоединение пула XenServer к домену уже описано тут: http://wiki.autosys.tk/XenApp.%d0%9f%d0%be%d0%b4%d0%b3%d0%be%d1%82%d0%be%d0%b2%d0%ba%d0%b0-%d0%ba-%d1%8d%d0%ba%d0%b7%d0%b0%d0%bc%d0%b5%d0%bd%d1%83-1Y0-A26-Citrix-XenServer-6-Administration.ashx#%D0%90%D1%83%D1%82%D0%B5%D0%BD%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F_%D1%81_%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%D1%8C%D1%8E_AD_11

Даем разрешение пользователю на доступ к XenServer с помощью командной строки

Добавляем в XenServer субъекта:

xe subject-add subject-name=<entity name>

В данном случае entity name - это имя пользователя или группы. Дополнительно можно указать домен - '<xendt\user1>'. Хотя это и не обязательно - можно просто'<user1>'.

Запрещаем доступ к XenServer с помощью командной строки

Сначала нужно определить имя пользователя или группы которым мы запрещаем доступ:

xe subject-list

К списку пользователей можно применить фильтр (например - получить идентифиатор субъекта для пользователя с именем user1):

xe subject-list other-config:subject-name='<domain\user>'

Удаляем пользователя с помощью команды subject-remove, передавая в качестве аргумента идентификатор:

xe subject-remove subject-uuid=<subject-uuid>

Также может понадобиться завершить все открытые сессии указанного пользователя. Как это сделать написано тут: http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#terminating_all_authenticated_sessions. Если этого не сделать, то удаленный пользователь будет иметь возможность работать с XenServer, пока не выйдет .

Получение списка пользователей и их прав

Для получения списка пользователей и групп и их прав используется следующая команда:

xe subject-list

2.6 - Управление правами доступа на основе ролей XenServer

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#rbac

Внимание! Полная функциональность управления правами доступа на основе ролей доступна только в версии Citrix XenServer Enterprise Edition или выше.

Делегирование прав в Citrix XenServer использует механизм ролей. Каждому пользователю назначается роль, которая определяет список доступных прав. Этот механизм называется Role Based Access Control (RBAC).
Для аутентификации пользователей RBAC использует инфораструктуру Active Ditrectory. Таким образом, для назначения пользователям ролей необходимо присоединить пул XenServer к домену.
Локальный суперпользователь (local super user - LSU), или root, это специальная учетная запись, создаваемая при установке XenServer и используемая в административных целях, имеющая полные права в системе. Аутентификация root'а происходит локально и в случае отказа внешних механизмов аутентификации root может подключиться к системе с помощью XenCenter или SSH.

Для использования RBAC надо:
1. Присоединить пул к домену.
2. Добавить пользователя (или группу) Active Directory в пул и он станет субъектом (subject).
3. Назначить субъекту роли.

Роли

В XenServer преднастроены следующие шесть ролей:

Pool Administrator (Pool Admin) – полные права, аналогичные root.

ПРИМЕЧАНИЕ. Локальный суперпользователь root всегда имеет роль “Pool Admin”.

Pool Operator (Pool Operator) – имеет права на все операции, кроме добавления/удаления пользователей и изменения их ролей. Пользователи с этой ролью обслуживают хосты пула и пул вцелом.
Virtual Machine Power Administrator (VM Power Admin) – права на создание и управление виртуальными машинами. Пользователи этой роли готовят виртуальные машины к работе с ними пользователей с ролью VM operator.
Virtual Machine Administrator (VM Admin) – тем же права, что и у VM Power Admin, за исключением прав на миграцию виртуальных машин и создание снимков (snapshots).
Virtual Machine Operator (VM Operator) – те же права, что и у VM Admin, в том числе и включение/выключение виртуальных машин, кроме прав на создание/удаление виртуальных машин.
Read-only (Read Only) – права только на просмотр состояния пула и данных о производительности.

ПРИМЕЧАНИЕ: В данной версии XenServer (версия 6.0.0) создание новых ролей и изменение существующих не предусмотрено.

ВНИМАНИЕ! Нельзя назначить роль pool-admin группе Active Directory, содержащей более 500 пользователей, в случае, если этм пользователям нужен доступ по SSH.

Список ролей и субъектов

Получение списка пользователей: xe role-list. Эта команда возвращает список ролей.

uuid( RO): 0165f154-ba3e-034e-6b27-5d271af109ba
name ( RO): pool-admin
description ( RO): The Pool Administrator role can do anything
               
uuid ( RO): b9ce9791-0604-50cd-0649-09b3284c7dfd
name ( RO): pool-operator
description ( RO): The Pool Operator can do anything but access Dom0 \
and manage subjects and roles

uuid( RO): 7955168d-7bec-10ed-105f-c6a7e6e63249
name ( RO): vm-power-admin
description ( RO): The VM Power Administrator role can do anything \
affecting VM properties across the pool

uuid ( RO): aaa00ab5-7340-bfbc-0d1b-7cf342639a6e
name ( RO): vm-admin
description ( RO): The VM Administrator role can do anything to a VM
                
uuid ( RO): fb8d4ff9-310c-a959-0613-54101535d3d5
name ( RO): vm-operator
description ( RO): The VM Operator role can do anything to an already 
                
uuid ( RO): 7233b8e3-eacb-d7da-2c95-f2e581cdbf4e
name ( RO): read-only
description ( RO): The Read-Only role can only read values

Для получения списка субъектов используется команда xe subject-list.

uuid ( RO): bb6dd239-1fa9-a06b-a497-3be28b8dca44
subject-identifier ( RO): S-1-5-21-1539997073-1618981536-2562117463-2244
other-config (MRO): subject-name: example01\user_vm_admin; subject-upn: \
  user_vm_admin@XENDT.NET; subject-uid: 1823475908; subject-gid: 1823474177; \
  subject-sid: S-1-5-21-1539997073-1618981536-2562117463-2244; subject-gecos: \
  user_vm_admin; subject-displayname: user_vm_admin; subject-is-group: false; \
  subject-account-disabled: false; subject-account-expired: false; \
  subject-account-locked: false;subject-password-expired: false
roles (SRO): vm-admin
                
uuid ( RO): 4fe89a50-6a1a-d9dd-afb9-b554cd00c01a
subject-identifier ( RO): S-1-5-21-1539997073-1618981536-2562117463-2245
other-config (MRO): subject-name: example02\user_vm_op; subject-upn: \
  user_vm_op@XENDT.NET; subject-uid: 1823475909; subject-gid: 1823474177; \
  subject-sid: S-1-5-21-1539997073-1618981536-2562117463-2245; \
  subject-gecos: user_vm_op; subject-displayname: user_vm_op; \
  subject-is-group: false; subject-account-disabled: false; \
  subject-account-expired: false; subject-account-locked: \
  false; subject-password-expired: false
roles (SRO): vm-operator
                
uuid ( RO): 8a63fbf0-9ef4-4fef-b4a5-b42984c27267
subject-identifier ( RO): S-1-5-21-1539997073-1618981536-2562117463-2242
other-config (MRO): subject-name: example03\user_pool_op; \
  subject-upn: user_pool_op@XENDT.NET; subject-uid: 1823475906; \
  subject-gid: 1823474177; subject-s id:
  S-1-5-21-1539997073-1618981536-2562117463-2242; \
  subject-gecos: user_pool_op; subject-displayname: user_pool_op; \
  subject-is-group: false; subject-account-disabled: false; \ 
  subject-account-expired: false; subject-account-locked: \
  false; subject-password-expired: false
  roles (SRO): pool-operator

Добавление субъектов

Добавление субъекта:

xe subject-add subject-name=<AD user/group>

Назначение роли субъекту

После создания субъекта ему можно назначить роль. На роль можно сослаться по uuid или по имени роли:

xe subject-role-add uuid=<subject uuid> role-uuid=<role_uuid>

или

xe subject-role-add uuid=<subject uuid> role-name=<role_name>

Например следующая команда назначает роль Pool Administrator субъекту с uuid=b9b3d03b-3d10-79d3-8ed7-a782c5ea13b4:

xe subject-role-add uuid=b9b3d03b-3d10-79d3-8ed7-a782c5ea13b4 role-name=pool-admin

Изменение роли

Для изменения роли нужно удалить текущую роль и добавить новую:
Выполните команды:

xe subject-role-remove uuid=<subject uuid> role-name= \ 
      <role_name_to_remove>
    xe subject-role-add uuid=<subject uuid > role-name= \    
      <role_name_to_add>

Для того чтобы гарантировать, что новая роль применена нужно чтобы пользователь вышел изи системы и вошел снова (logged out and logged back in again).

ВНИМАНИЕ! При назначении/удалении субъекту роли pool-admin может быть задержка в несколько секунд пока все хосты пула примут изменения для сессий ssh.

Раздел 3: Управление виртуальными машинами и шаблонами

3.1 - Копирование виртуальной машины

http://docs.vmd.citrix.com/XenServer/5.6.0fp1/1.0/en_gb/reference.html#pool_removal
http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/guest.html#creatingVMs-clone

Сделать копию существующей виртуальной машины можно путем клонирования шаблона. Шаблон представляет собой обычную виртуальную машину, используемую как мастер-копия для создания новых машин. Виртуальную машину можно сконвертировать в шаблон, выполнив перед этим подготовительные шаги описнные тут: http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/guest.html#clone_considerations_Windows, http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/guest.html#clone_considerations_Linux.

Виртуальные машины могут быть скопированы XenServer двумя способами:
1. Полное копирование.
2. Копирование при записи (Copy-on-Write - CoW).

Быстрый режим копирования при записи записывает только измененные с момента копирования блоки. Механизм CoW спроектирован так, чтобы сохранять место на дисках и обеспечивать возможность быстрого клонирования, однако он немного снижает быстродействие дисковой подсистемы. Шаблон может быть быстро склонирован много раз без замедления.

ПРИМЕЧАНИЕ: Если из шаблона склонировать виртуальную машину и потом обратно создать из виртуальной машины шаблон, то производительность дисковой подсистемы будет снижаться линейно, пропорционально тому, сколько раз произведено клонирование. Во избежание этого эффекта следует использовать команду vm-copy, которая осуществляет полное копирование виртуальной машины и позволяет получить самое высокое быстродействие.

Копирование виртуальной машины на другой сервер:

xe vm-list (note the name of the VM you wish to copy)
xe sr-list (note the name of the storage you will to copy the VM to)
xe vm-copy (needs the following parameters to complete)
xe vm-copy vm=<name of VM to copy> sr-uuid=<UUID of SR to copy VM to> new-name-label=<NewNameofVM> new-name-description=”Description of VM”

3.2 - Импорт-экспорт виртуальных машин

Экспорт VM

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/guest.html#exporting_vms
Экспортировать виртуальные машины в форматах OVF/OVA и XVA можно как с помощью XenCenter Export wizard, так и в формате XVA с помощью командной строки.

Экспорт в формате OVF/OVA

С помощью XenCenter Export wizard, можно экспортировать одну или несколько виртуальных машин в пакет OVF/OVA. При экспорте в этом формате в пакет инкапсулируются конфигурационные данные и виртуальные диски.

ПРИМЕЧАНИЕ: Для экспорта в формате OVF или OVA нужно войти в систему как root или с правами Pool Administrator.

Экспорт в формате OVF/OVA с помощью XenCenter:
1. Выключите (Shut down) или приостановите (suspend) виртуальную машину, которая будет экспортирована.
2. Откройте мастер экспорта: В панели ресурсов (справа) кликните правой кнопкой по пулу или хосту, на котором находится экспортируемая виртуальная машина, а затем кликните Export.
3. На первой странице мастера введите имя экспортируемого файла, укажите папку, куда будет экспортирован файл. Затем из выпадающего списка выберите формат OVF/OVA Package (*.ovf, *.ova) и нажмите Next.
4. Из списка доступных виртуальных машин выберите одну или несколько, которые будут включены в в пакет OVF/OVA и нажмите Next.
5. Можно добавить предварительно подготовленный текст лицензионного соглашения в виде файла в формате .rtf или .txt. Другие форматы файлов (XML or binary) не поддерживаются. Нажмите Next для продолжения.
6. На странице Advanced options укажите манифест, цифровую подпись и параметры выходного файла или просто нажмите Next для продолжения.
7. Сконфигурируйте сетевые свойства виртуальной машины: Выберите сеть из списка и укажите способ конфигурирования (вручную или автоматически) и нажмите Next.
8. Проверьте параметры экспорта и при необходимости поставьте флажок Verify export on completion для проверки экспортированного файла. Нажмите Finish для начала процесса экспорта.

Экспорт в формате XVA выполянется аналогично, только на этапе 3 надо выбрать формат XVA File.

Экспорт в формате XVA с помощью интерфейса командной строки:

1. Выключите (Shut down), виртуальную машину, которая будет экспортирована.
2. Экспортируйте виртуальную машину командой:

    xe vm-export -h <hostname> -u <root> -pw <password> vm=<vm_name> \
    filename=<pathname_of_file>

ПРИМЕЧАНИЕ: Убедитесь, что в конце имени файла есть расширение .xva. После экспорта в файл без расширения могут возникнуть сложности при импорте.

3.3 - Конвертирование работающего сервера с помощью XenConvert - Physical to Virtual (P2V) или Virtual to Virtual (V2V)

Описание процесса конвертирования приведено в документации по XenConvert. Она короткая.
http://support.citrix.com/article/CTX125530
http://support.citrix.com/servlet/KbServlet/download/28774-102-666402/XenConvertGuide.pdf

3.4 - Управление виртуальными машинами

Команды управления виртуальными машинами

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#cli-xe-commands_vm

Селекторы виртуальных машин

Некоторые из описываемых команд позволяют использовать стандартный механизм селекторов для выбора одной или нескольких виртуальных машин по определенному признаку (параметру). Простейший способ выбора виртуальной машины - это указание ее идентификатора: vm=<name_or_uuid>.
Получить значения идентификаторов можно с помощью команды, которая также поддерживает селекторы: xe vm-list power-state=running.
Полный список параметров, свойственных виртуальным машинам можно получить с помощью команды: xe vm-list params-all.
Например применение аргумента power-state=halted приведет к тому, что команда будет выполнена только для машин находящихся в состоянии halted. При этом, если под фильтр попадают много машин - нужно добавлять дополнительный параметр:

--multiple

, указывающий что действие нужно выполнить над всем списком.

Описание команд:

vm-assert-can-be-recovered

vm-assert-can-be-recovered <uuid> [<database>] <vdi-uuid>

Проверяет доступно ли хранилище для восстановления VM

vm-cd-add

vm-cd-add cd-name=<name_of_new_cd> device=<integer_value_of_an_available_vbd>
[<vm-selector>=<vm_selector_value>...]

Добавляет новый виртуальный привод CD. Параметры устройства должны быть выбраны из списка доступных устройств VBD.

vm-cd-eject

vm-cd-eject [<vm-selector>=<vm_selector_value>...]

Извлекает CD из виртуального привода. Если приводов больше, чем один, то следует использовать команду xe vbd-eject и указать UUID устройства VBD.

vm-cd-insert

vm-cd-insert cd-name=<name_of_cd> [<vm-selector>=<vm_selector_value>...]

Вставлет CD в виртуальный привод. Если приводов больше, чем один, то следует использовать команду xe vbd-insert и указать UUID устройства VBD.

vm-cd-list

vm-cd-list [vbd-params] [vdi-params] [<vm-selector>=<vm_selector_value>...]

Выводит список CD, присоединенных к указанной машине.

vm-cd-remove

vm-cd-remove cd-name=<name_of_cd> [<vm-selector>=<vm_selector_value>...]

Удаляет CD из указанных VMs.

vm-clone

vm-clone new-name-label=<name_for_clone>
[new-name-description=<description_for_clone>] [<vm-selector>=<vm_selector_value>...]

Клонирует указанную VM, с помощью быстрого механизма хранилища(storage-level fast disk clone). Нужно указать имя и описание результирующей машины в параметрах new-name-label и new-name-description.

vm-compute-maximum-memory

vm-compute-maximum-memory total=<amount_of_available_physical_ram_in_bytes>
[approximate=<add overhead memory for additional vCPUS? true | false>]
[<vm_selector>=<vm_selector_value>...]

Вычисляет максимальное количество статической памяти, которое может быть выделено виртуальной машине. Опциональный аргумент approximate резервирует дополнительную память для добавляемый впоследствии новых vCPU.

Пример:

xe vm-compute-maximum-memory vm=testvm total=`xe host-list params=memory-free --minimal`

Эта команда использует значение параметра memory-free, возвращаемое командой xe host-list, для того, чтобы выделить виртуальной машине максимальное количество свободной памяти виртуальной машине testvm.

vm-copy

vm-copy new-name-label=<name_for_copy> [new-name-description=<description_for_copy>]
[sr-uuid=<uuid_of_sr>] [<vm-selector>=<vm_selector_value>...]

Команда копирует существующую виртульную машину без использования механизмов быстрого копирования. Получаемая копия - это полная копия, не являющаяся частью цепочки copy-on-write (CoW).
Нужно указать имя и описание результирующей машины в параметрах new-name-label и new-name-description, а также идентификатор системы хранения, куда будет скопирована VM с помощью аргумента sr-uuid. Если sr-uuid не указан - копирование будет произведено на то же хранилище, где находится оригинальная VM.

vm-crashdump-list

vm-crashdump-list [<vm-selector>=<vm selector value>...]

Выводит список аварийных дампов указанной VM.
Если используется опциональный аргумент params - в нем можно указать список параметров, которые нужно отобразить. Кроме того, можно использовать ключевое слово all, для отображения всех параметров. Если аргумент params не используется, то выводится набор параметров, заданный по-умолчанию.

vm-data-source-list

vm-data-source-list [<vm-selector>=<vm selector value>...]

Выводит список источников данных о производительности виртуальной машины.
Источники данных имеют два параметра: standard и enabled. Если источник данных имеет параметр enabled со значением true, то данные записываются в базу данных производительности.
Если источник данных имеет параметр standard со значением true то данные записываются в базу данных производительности по-умолчанию.
Если параметры источника данных имеют значение false, то запись значений в базу данных не ведется.
Для начала записи значений в базу данных нужно выполнить команду vm-data-source-record. Эта команда установит параметру enabled значение true. Для остановки записи нужно выполнить команду vm-data-source-forget.

vm-data-source-record

vm-data-source-record data-source=<name_description_of_data-source> [<vm-selector>=<vm selector value>...]

Начинает запись значений указанного источника данных в базу данных о производительности.

vm-data-source-forget

vm-data-source-forget data-source=<name_description_of_data-source> [<vm-selector>=<vm selector value>...]

Останавливает запись значений указанного источника данных в базу данных о производительности.

vm-data-source-query

vm-data-source-query data-source=<name_description_of_data-source> [<vm-selector>=<vm selector value>...]

Отображает значение указанного источника данных.

vm-destroy

vm-destroy uuid=<uuid_of_vm>

Уничтожает указанную виртуальную машину. При этом, виртуальные диски этой машины остаются в хранилище. Для уничтожения машины и удаления дисков используется команда xe vm-uninstall.

vm-disk-add

vm-disk-add disk-size=<size_of_disk_to_add> device=<uuid_of_device>
[<vm-selector>=<vm_selector_value>...]

Добавляет новый виртуальный диск указанной VM. Параметр device выбирается из значений allowed-VBD-devices данной VM.
Параметр disk-size может быть указан в байтах или с помощью суффиксов KiB (2^10 bytes), MiB (2^20 bytes), GiB (2^30 bytes), и TiB (2^40).

vm-disk-list

vm-disk-list [vbd-params] [vdi-params] [<vm-selector>=<vm_selector_value>...]

Выводит список дисков, присоединенных к данной VM. Аргументы vbd-params и vdi-params задают поля соответсвующих объектов, указанные через запятую или всемто них можно использовать ключевое слово all, для полного списка.

vm-disk-remove

vm-disk-remove device=<integer_label_of_disk> [<vm-selector>=<vm_selector_value>...]

Удаляет диск из указанной виртуальной машины и уничтожает его.

vm-export

vm-export filename=<export_filename>
[metadata=<true | false>]
[<vm-selector>=<vm_selector_value>...]

Экспортирует указанную VM (включая и диски) в файл на локальной машине. В параметре filename нужно указать имя файла, куда будет экспортирована VM. Имя файла должно содержать расширение .xva.
Если параметр metadata имеет значение true, то экспортируются только метаданные, а диски экспортированы не будут. Этот режим используется в случаях, когда в качестве виртуальных дисков подключены физические носители и требуется только экспорт информации о них.

vm-import

vm-import filename=<export_filename>
[metadata=<true | false>]
[preserve=<true | false>]
[sr-uuid=<destination_sr_uuid>]

Выполняет импорт предварительно экспортированной машины. Если параметр preserve имеет значение true, то будет сохранен MAC-адрес оригинальной машины. Параметр sr-uuid задает на каком хранилище будут размещены виртуальные диски, а если он не указан, то будет использовано хранилище по-умолчанию.
Старые версии XenServer (начиная с версии 3.2)экспортировали машины в папку, а не в файл, поэтому параметр filename также может указывать на на корневую директорию экспорта XVA, а не на конкретный файл. Последующий экспорт импортированной машины будет производиться уже в новом формате. ^Примечание: Старый формат экспорта в папку не полностью сохранял аттрибуты виртуальной машины. В частности, не сохранялась информация о сетевых интерфейсах, которые придется создать заново с помощью команд vif-create и vif-plug.^
Если параметр metadata имеет значение true, то экспортированные метаданные могут быть импортированы без дисков. Импорт только метаданных завершится неудачно, если какие-либо VDI не будут обнаружены. Использование опции

--force

позволит импортировать машину в отсутствие ее VDI. Импорт-экспорт метаданных может быть полезен в случаях, когда нужно перенести машины между пулами, имеющими доступ к одной системе хранения.

Примечание: Импорт машин происходит быстрее в последовательном режиме, а не в параллельном.

vm-install

vm-install new-name-label=<name>
[ template-uuid=<uuid_of_desired_template> | [template=<uuid_or_name_of_desired_template>]]
[ sr-uuid=<sr_uuid> | sr-name-label=<name_of_sr> ]
[ copy-bios-strings-from=<uuid of host> ]

Устанавливает или клонирует виртуальную машину из шаблона. Нужно указывать либо название шаблона в параметром template, либо его идентификатор uuid в параметре template-uuid. Укажите хранилище параметром sr-uuid или sr-name-label. Укажите uuid хоста, с которого будут скопированы данные BIOS.

Примечание: при установке из шаблона, в котором есть диски, новые диски будут созданы на том же хранилище, на котором лежат диски шаблона. Если хранилище поддерживает механизмы быстрого копирования, то новые диски будут клонированы "быстрым" методом. Если указано другое хранилище, то новые диски будут созданы там. Если быстрое копирование невозможно, то новые диски будут скопированы полностью.

Если происходит установка из шаблона, в котором нет дисков, то новые диски будут создаваться на указанном хранилище, или на хранилище по-умолчанию.

vm-memory-shadow-multiplier-set

vm-memory-shadow-multiplier-set [<vm-selector>=<vm_selector_value>...]
[multiplier=<float_memory_multiplier>]

Задает коэффициент “теневой” памяти для VM.
Этот параметр задает количество shadow memory, выделенной аппаратно-поддержаной (hardware-assisted) VM. В некоторых случаях специализированных нагрузок, например - Citrix XenApp, дополнительная “теневая память” необходима для достижения максимального быстродействия.
Эта память будет избыточной. Она отделена от объема памяти, используемого VM. При выполнении этой команды количество свободной памяти XenServer будет уменьшено соответственно множителю. В случае нехватки физической памяти будет зафиксирована ошибка.

vm-migrate

vm-migrate [[host-uuid=<destination XenServer host UUID> ] | [host=<name or UUID of destination XenServer host> ]] [<vm-selector>=<vm_selector_value>...] [live=<true | false>]

Команда запускает миграцию виртуальной машины между физическими хостами. Параметр host может быть либо именем, либо идентификатором UUID хоста XenServer.
По-умолчанию, виртуальная машина будет остановлена (suspended), перемещена и затем оживлена на другом хосте. Параметр live активирует механизм XenMotion и позволяет машине работать во время перемещения, минимизируя время простоя до секунды. В некоторых случаях (например высокая нагрузка на память), XenMotion автоматически откатится к режиму миграции по-умолчанию и остановит VM на короткой промежуток времени, перед переносом состояния памяти.

vm-reboot

vm-reboot [<vm-selector>=<vm_selector_value>...] [force=<true>]

Перезагружает указанную машину.
Принудительную перезагрузку можно произвести с помощью аргумента force.

vm-recover

vm-recover <vm-uuid> [<database>] [<vdi-uuid>] [<force>]

Восстанвливает виртуальную машину из указанной базы.

vm-reset-powerstate

vm-reset-powerstate [<vm-selector>=<vm_selector_value>...] {force=true}

Эта команда используется в случаях, когда хост пула выходит из строя и работавшие на нем машины не возможно выключить. Эта команда принудительно переводит машины в состояние halted. На самом деле, эта команда разблокирует диски виртуальной машины и после этого ее можно запустить на другом хосте пула. Эта команда требует обязательного указания аргумента force.

vm-resume

vm-resume [<vm-selector>=<vm_selector_value>...] [force=<true | false>] [on=<XenServer host UUID>]

Возвращает к работе машину, находящуюся в приостановленном состоянии.
Если машина находится на общем (shared) хранилище пула, то следует использовать аргумент on, который указывает на каком хосте следует запустить машину. По-умолчанию, система сама определяет подходящий хост.

vm-shutdown

vm-shutdown [<vm-selector>=<vm_selector_value>...] [force=<true | false>]

Выключает указанную виртуальную машину.
Аргумент force позволяет принудительно выключить VM.

vm-start

vm-start [<vm-selector>=<vm_selector_value>...] [force=<true | false>] [on=<XenServer host UUID>] [--multiple]

Запускает указанную машину.
Если машина находится на общем (shared) хранилище пула, то следует использовать аргумент on, который указывает на каком хосте следует запустить машину. По-умолчанию, система сама определяет подходящий хост.

vm-suspend

vm-suspend [<vm-selector>=<vm_selector_value>...]

Приостанавливает работу указанной машины.

vm-uninstall

vm-uninstall [<vm-selector>=<vm_selector_value>...] [force=<true | false>]

Полностью удаляет виртуальную машину, включая метаданные и подключенные диски (только те VDI, которые имеют режим RW и присоединены только к этой машине).
Для удаления только метаданных используется команда xe vm-destroy.

vm-vcpu-hotplug

vm-vcpu-hotplug new-vcpus=<new_vcpu_count> [<vm-selector>=<vm_selector_value>...]

Динамически изменяет количество VCPU, доступных виртуальной машине Linux, в пределах, ограниченных параметром VCPUs-max. Виртуальные машины Windows всегда используют число VCPU, заданное параметром VCPUs-max и для его изменения должны быть перезагружены.

vm-vif-list

vm-vif-list [<vm-selector>=<vm_selector_value>...]

Выводит список виртуальных сетевых адаптеров данной VM.

Команды для работы с хостами XenServer

host-backup

host-backup file-name=<backup_filename> host=<host_name>

Сохраняет резервную копию управляющего домена (control domain) указанного хоста XenServer на машину, с коротой запущена команда. ^Внимание! Несмотря на то, что команду можно запустить на локальном хосте (не указывая параметр host), в таком образом её использовать не следует, потому что раздел управляющего домена (control domain) будет полностью заполнен файлом бекапа. Эту команду следует выполнять с другого хоста, на котором есть место для сохранения бекапа. ^

host-bugreport-upload

host-bugreport-upload [<host-selector>=<host_selector_value>...] [url=<destination_url>]
[http-proxy=<http_proxy_name>]

Создает свежий отчет о багах (утилитой xen-bugtool со всеми включенными опциями) и загружает его на сервер службы поддержки Citrix Support или указанный сервер ftp.
Дополнительные параметры - http-proxy и url предписывает использовать указанный proxy и удаленый сервер. По-умолчанию отчет выгружается на серер Citrix Support.

host-crashdump-destroy

host-crashdump-destroy uuid=<crashdump_uuid>

Удаляет дамп, с заданным UUID.

host-crashdump-upload

host-crashdump-upload uuid=<crashdump_uuid>
[url=<destination_url>]
[http-proxy=<http_proxy_name>]

Выгружает аварийный дамп на сервер Citrix Support или указанный сервер.
Дополнительные параметры - http-proxy и url предписывает использовать указанный proxy и удаленый сервер. По-умолчанию дамп выгружается на серер Citrix Support.

host-disable

host-disable [<host-selector>=<host_selector_value>...]

Отключает указанный хост XenServer. После выполнения этой команды на хосте запрещен запуск виртуальных машин. Это действие подготавливает хост к выключению или перезагрузке.

host-dmesg

host-dmesg [<host-selector>=<host_selector_value>...]

Выводит журнал ядра указанного хоста (dmesg).

host-emergency-management-reconfigure

host-emergency-management-reconfigure interface=<uuid_of_management_interface_pif>

Переконфигурирует основной интерфейс управления данного хоста XenServer. Эту команду следует использовать только если хост находится в аварийном режиме (emergency mode), то есть является членом пула, мастер-хост которого пропал из сети и не доступен после нескольких попыток связаться с ним.

host-enable

host-enable [<host-selector>=<host_selector_value>...]

Включает указанный хост, разрешая запуск на нем виртуальных машин.

host-evacuate

host-evacuate [<host-selector>=<host_selector_value>...]

Запускает миграцию виртуальных машин на другие подходящие хосты пула. Перед запуском этой команды хост должен быть отключен командой host-disable.
Если эвакуируемый хост - это мастер-хост пула, то нужно назначить другой мастер-хост. Для назначения нового мастер-хоста при выключенной высокой доступности (HA) нужно выполнить команду pool-designate-new-master.
При включенной HA - выборы мастер-хоста произойдут автоматически.

host-forget

host-forget uuid=<XenServer_host_UUID>

Агент xapi “забудет” об указанном хосте XenServer, не связываясь с ним.
Аргумент

--force

следует использовать для того чтобы запретить запрос подтверждения этой операции.

ВНИМАНИЕ! Не используйте эту команду при включенной высокой доступности (HA). Сначала следует отключить HA, затем “забыть” хост и потом включить HA снова.
Совет: Эта команда применима, если хост сдох. Если хост все-таки жив, то следует использовать команду xe pool-eject.

host-get-system-status

host-get-system-status filename=<name_for_status_file>
[entries=<comma_separated_list>] [output=<tar.bz2 | zip>] [<host-selector>=<host_selector_value>...]

Выгружает информацию о состоянии системы в указанный файл. Дополнительные параметры вводятся через запятую.

host-get-system-status-capabilities

host-get-system-status-capabilities [<host-selector>=<host_selector_value>...]

Получает характеристики состояния системы указанного хоста в виде файла XML, который выглядит примерно так:

<?xml version="1.0" ?>	<system-status-capabilities>
 		<capability content-type="text/plain" default-checked="yes" key="xenserver-logs"  \
           max-size="150425200" max-time="-1" min-size="150425200" min-time="-1" \
		   pii="maybe"/>
 		<capability content-type="text/plain" default-checked="yes" \
		   key="xenserver-install" max-size="51200" max-time="-1" min-size="10240" \
		   min-time="-1" pii="maybe"/>
 		...
	</system-status-capabilities>

Каждя запись имеет ряд аттрибутов:
key Уникальный идентификатор характеристики
content-type Имеет значение либо text/plain либо application/data. Показывает, может ли интерфейс отобразить запись в читаемом виде.
default-checked Имеет значение либо yes либо no. Показывает, будет ли запись отображена по-умолчанию.
min-size, max-size Показвает примерный диапазон размера записи в байтах. Значение -1 говорит, что размер не важен.
min-time, max-time Показывает примерную продолжительность сбора данных записи. Значение -1 говорит, что продолжительность не важна.
pii Персонально идентифицируемая информация. Показывает, будет ли в записи информация, идентифицирующая владельца системы или подробности сетевой топологии. Принимает значения: no, yes, maybe, if_customized

Пароли никогда не указываются ни в каких отчетах. Они могут быть указаны только в самим администратором в PII.

host-is-in-emergency-mode

host-is-in-emergency-mode

Возвращает true, если хост находится в аварийном режиме. Эта команда работает на подчиненных хостах (slave hosts), даже если мастер-хост недоступен.

host-apply-edition

host-apply-edition [host-uuid=<XenServer_host_UUID>] [edition=xenserver_edition=<"free"><"advanced"><"enterprise"><"platinum"><"enterprise-xd">]

Назначает лицензию хосту XenServer. При назначении лицензии XenServer соединяется с сервером лицензий Citrix License Server и запрашивает нужный тип лицензии. Если лицензия доступна - он получает ее от сервера лицензий.

Для Citrix XenServer for XenDesktop используется <“enterprise-xd”>.
Для начальной конфигурации - нужно сконфигурировать параметры license-server-address и license-server-port.

host-license-add

host-license-add [license-file=<path/license_filename>] [host-uuid=<XenServer_host_UUID>]

For XenServer (free edition), use to parses a local license file and adds it to the specified XenServer host.

host-license-view

host-license-view [host-uuid=<XenServer_host_UUID>]

Отображает содержимое лицензии хоста XenServer.

host-logs-download

host-logs-download [file-name=<logfile_name>] [<host-selector>=<host_selector_value>...]

Выгружает копию логов указанного хоста XenServer. Копия сохраняется по-умолчанию в файле с именем соотвествующим дате в формате hostname-yyyy-mm-dd T hh:mm:ssZ.tar.gz. Также можно указать и другое имя с помощью соответствующего аргумента.

host-management-disable

host-management-disable

Отключает интерфейс управления хостом и отключает всех подключенных клиентов.

Внимание! После отключения интерфейса управления включить его можно только с помощью локальной консоли хоста.

host-management-reconfigure

host-management-reconfigure [interface=<device> ] | [pif-uuid=<uuid> ]

Конфигурирует хост Xenserver для использования указанного интерфейса в качестве основного интерфейса управления (для подключения XenCenter).
Эта команда изменяет параметр MANAGEMENT_INTERFACE в файле /etc/xensource-inventory.
Если интерфейсу присовен IP-адрес в команде указано имя устройства интерфейса (device name), то конфигурирование произойдет сразу. Команда работает как в номальном, так и в аварийном (emergency) режиме.
Если указн идентификатор UUID объекта PIF, то XenServer определяет IP адрес. В таком варианте команда работает только в нормальном режиме хоста (не аварийном).
Внимание! Используйте эту команду осторожно, т.к. возможна потеря связи с хостом. Предварительно надо настроить интерфейс командой pif-reconfigure.

host-power-on

host-power-on [host=<host_uuid> ]

Включает хост, на котором включена соответствующая функциональность (Host Power On functionality). Перед использованием этой команды, на хосте следует выполнить команду host-set-power-on.

host-get-cpu-features

host-get-cpu-features {features=<pool_master_cpu_features>} [uuid=<host_uuid>]

Выводит в шестнадцатеричном виде список возможностей физического процессора.

host-set-cpu-features

host-set-cpu-features {features=<pool_master_cpu_features>} [uuid=<host_uuid>]

Эта команда пытается привести список возможностей физического процессора к заданному. СТрока-аргумент представляет собой 32-х символьную шестнадцатеричную строку (возможно содержащую пробелы), аналогичную выводу команды host-get-cpu-features.

host-set-power-on

host-set-power-on {host=<host uuid> {power-on-mode=<""> <"wake-on-lan"> <"iLO"> <"DRAC"> <"custom"> } | [power-on-config=<"power_on_ip"><"power_on_user"><"power_on_password_secret">] }

Включает возможность удаленного включения питания хоста. При балансировке нагрузке в режиме максимальной плотности (Maximum Density mode) может понадобиться включать и выключать неиспользуемые хосты. При выполнении этой команды нужно указать тип используемого решения управления питанием (аргумент <power-on-mode>). Затем, указать опции конфигурации с помощью аргумента <power-on-config> и пар параметр-значение.

host-reboot

host-reboot [<host-selector>=<host_selector_value>...]

Перезагружает указанный хост XenServer. Перед перезагрузкой хост должен быть отключен командой xe host-disable. В противном случает будет зафиксирована ошибка HOST_IN_USE.
Если указанный хост член пула, то после перезагрузки его возвращение в пул будет обработано правильно, а во время перезагрузки мастер-хост и другие члены пула будут нормально работать. Если перезагружается мастер-хост, то пул не будет доступен пока мастер-хост не вернется в строй или до тех пор, пока не будет назначен новый мастер-хост.

host-restore

host-restore [file-name=<backup_filename>] [<host-selector>=<host_selector_value>...]

Восстанавливает из указанной резервной копии состояние хоста XenServer. В данном случае под восстановлением понимается не полное восстановление, а просто распаковка конфигурационных файлов на строй раздел диска. После выполнения xe host-restore нужно загрузиться с установочного диска и выбрать опцию Restore from Backup.

host-set-hostname-live

host-set-hostname host-uuid=<uuid_of_host> hostname=<new_hostname>

Меняет имя хоста XenServer с указанным UUID. Эта команда изменяет имя хоста как на самом хосте, так и в базе данных домена.

Примечание: имя хоста (hostname) это не тоже самое, что и name_label

host-shutdown

host-shutdown [<host-selector>=<host_selector_value>...]

КОманда выключает указанный хост XenServer. Перед выключением следует отключить (запретить запуск новых виртуальных машин на нем) хост командой xe host-disable. В противном случае - будет выведено сообщение об ошибке: HOST_IN_USE.
Если указанный хост является членом пула, то его выключение (и последующее возвращение в работу) будет правильно обработано без прерывания работы пула. Если выключается мастер-хост, то пул не будет доступен пока мастер-хост не вернется в строй или до тех пор, пока не будет назначен новый мастер-хост. Если включена высокая доступность (HA), то новый мастер-хост назначается автоматически. Если HA отключена, то нужно вручную назначить мастерхост командой pool-designate-new-master.

host-syslog-reconfigure

host-syslog-reconfigure [<host-selector>=<host_selector_value>...]

Переконфигурирует демон syslog на указанном хосте.

host-data-source-list

host-data-source-list [<host-selectors>=<host selector value>...]

Выводит список источников данных о производительности хоста.
При запуске команды без уточнения хоста - команда будет выполнена для всех хостов.
Источники данных о производительности хоста имеют два параметра - standard и enabled. Если параметр enabled имеет значение true - это значит, что данные из этого источника фиксируются в базе данных производительности хоста.
Если параметр standard имеет значение true - это значит, что данные фиксируются в базе по-умолчанию (то есть параметр enabled также имеет значение true).
Если параметр standard имеет значение false - это значит, что данные не фиксируются в базе по-умолчанию (то есть параметр enabled также имеет значение false).
Для того чтобы начать фиксировать данные о производительности в базе предназначена команда host-data-source-record (параметр enabled будет установлен в значение true).
Для того чтобы прекратить фиксировать данные о производительности в базе предназначена команда host-data-source-forget (параметр enabled будет установлен в значение false).

host-data-source-record

host-data-source-record data-source=<name_description_of_data-source> [<host-selectors>=<host selector value>...]

При выполнении этой команды начинается запись данных о производительности с указанного источника для указанного хоста.
При запуске команды без уточнения хоста - команда будет выполнена для всех хостов.

host-data-source-forget

host-data-source-forget data-source=<name_description_of_data-source> [<host-selectors>=<host selector value>...]

Команда останавливает запись данных о производительности с указанного источника для указанного хоста.
При запуске команды без уточнения хоста - команда будет выполнена для всех хостов.

host-data-source-query

host-data-source-query data-source=<name_description_of_data-source> [<host-selectors>=<host selector value>...]

Отображает данные о производительности с указанного источника.
При запуске команды без уточнения хоста - команда будет выполнена для всех хостов.

Раздел 4. Конфигурирование и работа с пулами серверов

4.1 - Добавление серверов в пул и удаление их из пула

Серверы XenServer могут быть объединены в пул. Такое объединение дает возможность управлять множеством хостов XenServer как единым ресурсом, внутри которого исполняются виртуальные машины. Пул предствляет собой множество (два и более) хостов XenServer, использующих общее (shared) хранилище, на котором хранятся данные виртуальных машин. Таким образом виртуальная машина может быть запущена на любом хосте пула, а также может динамически мигрировать с одного хоста на другой, обеспечивая минимальное время простоя (технология XenMotion).
При выходе из строя отдельных хостов пула, администратор может перезапустить остановленные виртуальные машины на рабочих хостах пула, а при включенной функции высокой готовности (high availability - HA), виртуальные маишны будут перезапущены автоматически. В пул могут входить до 16 серверов, хотя это ограничение не является строгим.
В состав пула всегда входит хотя бы один хост, который является мастер-хостом. Только мастер-хост предоставляет административный интерфейс для работы с пулом, перенаправляя команды XenCenter и XenServer Command Line Interface (xe CLI) отдельным хостам.

Примечание. При выходе из строя мастер-хоста автоматические перевыборы мастер-хоста происходят только при включенной HA.

Пулы бывают гомогенные (то есть состоящие из хостов с одинаковыми CPU) либо гетерогенные (состоящие из хостов с разными CPU).

Условия, которые должны быть соблюдены для создания пула:
- в хостах XenServer установлены одинаковые процессоры (производитель, модель и функции)
- хосты работают под управлением одной версии XenServer

Также должны быть соблюдены некоторые условия конфигурации:
- Хост присоединяемый к пулу не должен входить в состав других пулов.
- На нем не должно быть сконфигурировано общего (shared) хранилища
- на присоединяемом хосте не должно быть запущенных или приостановленных (suspended) виртуальных машин
- на присоединяемом хосте не должно выполняться никаких текущих процедур с виртуальными машинами (например выключение ВМ)

Также следует проверить, что часы присоединяемого хоста и мастер-хоста пула синхронизированы с одним сервером NTP. Также интерфейс управления хостом должен иметь статический IP (сконфигурированный на хосте или через DHCP) и не должен быть объединен с другим интерфейсов в группу (bonded) - объединение можно сконфигурировать после присоединения к пулу.
Хосты могут иметь разное количество сетевых интерфейсов и локальные хранилища разного размера. Кроме того допускаются незначительные отличия в используемых CPU. Если вы уверены, что отличия в CPU хостов незначительны, то для присоединеня к пулу может понадобиться использовать параметр

--force

Примечание. Статический IP адрес должен быть также у хранилищ NFS или iSCSI, используемых пулом.

Хотя наличие общего (shared) хранилища не является обязательным условием работы пула, однако использование общего хранилища позволяет указывать на каком конкретно хосте должна исполняться виртуальная машина, а также динамически перемещать ВМ между хостами XenServer.
По возможности не следует создавать пул без общего хранилища, а после того как в пуле появляется общее хранилище следует переместить ВМ на общее хранилище с помощью команды xe vm-copy или XenCenter.

Создание Resource Pool

Пул XenServer можно создать либо из XenCenter, либо с помощью консоли и CLI. При присоединении хоста к пулу, хост синхронизирует свою локальную базу данных с базой данных пула и наследует некоторые настройки:
- Информация о виртуальных машинах, а также локальных и удаленных хранилищах попадает в базу данных пула, но локальные ресурсы все еще будут привязаны к хосту, до тех пор, пока они не будут объявлены общими.
- Присоединяемый к пулу хост наследует настройки общего хранилища пула и соответствующее PBD (физическое блочное устройство) будет создано автоматически.

- Информация о сетевых настройках наследуется частично. Наследуются структурные детали сетевых адаптеров, VLANов и объединенных интерфейсов, но не наследуются политики, в частности НЕ наследуются:
- не наследуются настройки IP-адреса интерфейса управления.
- не наследуются параметры основного интерфейса управления хоста.
- не наследуются параметры адаптеров, выделенных для работы с общим хранилищем. Адаптеры выделенные для присоединения хранилищ должны быть перенастроены, а PBD переподключены. Это происходит потому что в процессе присоединения не присваиваются IP-адреса адаптерам хоста. Подробнее конфигурирование выделенного адаптера для взаимодействия с хранилищем описано тут: http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#networking-standalone_host_config-config_dedicated_storage_nic

Для объединения хостов XenServer host1 и host2 в один пул XenServer с помощью интерфейса командной строки:
- откройте консоль host1 и host2
- В консоли host2 выполните команду присоединения к host1:

xe pool-join master-address=<host1> master-username=<administrators_username> master-password=<password>

Параметр master-address - это полное FQDN имя хоста host1, а password - это пароль администратора, задаваемый при установке XenServer.

Именование пула

По-умолчанию хосты принадлежат к пулу без имени. Переименовать пул можно командой (для завершения строки и заполнения uuid можно использовать tab):

xe pool-param-set name-label=<"New Pool"> uuid=<pool_uuid>

Создание гетерогенных пулов

Примечание: гетерогенные пулы можно создавать только в версиях XenServer Advanced и старше.

XenServer 6.0 упрощает расширение ферм, позволяя объединять в пулы хосты с разным аппаратным обеспечением - так называемые гетерогенные пулы. Создание гетерогенных пулов стало возможным благодаря использованию таких технологий как Intel (FlexMigration) и AMD (Extended Migration), которые позволяют конфигурировать CPU так, чтобы он представлял нужный набор функций. Таким образом, можно создавать пулы на базе хостов с разными процессорами, и поддерживающими “живую миграцию”.
“Маскирование” CPU новых серверов для того, чтобы они соответствовали старым CPU требует соблюдения следующих условий:
- CPU существующих и добавляемых серверов должны быть одного производителя (AMD или Intel)
- CPU добавляемых серверов должны поддерживать либо технологию Intel FlexMigration либо AMD Enhanced Migration.
- Набор функций CPU существующих серверов должен поддерживаться CPU устанавливаемых серверов
- На устанавливаемых серверах должна быть та же версия XenServer (включая хотфиксы), что и на существующих
- XenServer Advanced edition или выше

Наиболее просто создавать гетерогенные пулы с помощью XenCenter, который автоматически применяет “маскирование” CPU.
Для добавления хоста в гетерогенный пул с помощью командной строки:
- Определите набор функций процессоров существующих серверов пула с помощью команды: xe host-get-cpu-features
- На добавляемом хосте с помощью команды xe host-set-cpu-features надо установить нужный набор функций CPU:

xe host-set-cpu-features features=<pool_master's_cpu_ features>

- Перезагрузите добавляемый сервер
- Выполните команду xe pool-join для присоединения у пулу

Для возвращения “замаскированного” CPU к нормальному состоянию нужно выполнить команду xe host-reset-cpu-features

Примечание: Для отображения списка всех свойств CPU используется команда xe host-cpu-info

Добавление общего хранилища (Shared Storage)

В данном разделе описано добавление общего хранилища NFS.
Добавление общего хранилища NFS с помощью командной строки:
- Подготовьте разделяемый ресурс NFS по адресу <server:/path>
- Откройте консоль
- Создайте хранилище (storage repository) по адресу <server:/path> командой:

xe sr-create content-type=user type=nfs name-label=<"Example SR"> shared=true \
      device-config:server=<server> \
      device-config:serverpath=<path>

Параметр device-config:server указывает на имя хоста (hostname) на котором размещен ресурс NFS. Параметр device-config:serverpath указывает путь на сервере NFS. Так как shared имеет значение true, общее хранилище будет автоматичсеки подключено ко всем хостам пула и ко всем хостам, которые будут впоследствии подключены к пулу. Универсальный идентификатор (UUID) созданного хранилища будет выведен на экран.

- Определите UUID пула командой

xe pool-list

- Установите созданное общее хранилище как хранилище для пула по-умолчанию:

xe pool-param-set uuid=<pool_uuid> default-SR=<sr_uuid>

Так как было задано общее хранилище для пула по-умолчанию, все виртуальные машины, создаваемые в будущем будут размещены на этом хранилище.

Удаление хоста XenServer из пула

Примечание: Перед удалением хоста из пула убедитесь, что выключены все виртуальные машины на этом хосте. В противном случае будет выведено предупреждение и хост не удастся удалить.

После удаления хоста из пула, система перезагружается, инициализируется и остается в том состоянии как после чистой установки XenServer.
Таким образом важно не извлекать (eject) хост из пула, если на нем есть важные данные на локальных дисках.

Для удаления хоста из пула с помощью командой но строки:
- Откройте консоль хоста
- Определите UUID хоста командой:

xe host-list

- Извлеките хост из пула командой:

xe pool-eject host-uuid=<host_uuid>

Хост будет извлечен и приведен в состояние как после чистой установки XenServer.

Не извлекайте хост из пула, если на нем есть важные данные на локальных дисках. При извлечении из пула все данные будут уничтожены.
Если нужно сохранить эти данные - скопируйте виртуальные машины на общее хранилище (shared storage) пула с помощью XenCenter или команды xe vm-copy.^

При извлечении из пула хоста XenServer, содержащего на своем локальном хранилище виртуальные машины, эти ВМ будут представлены в базе данных пула и доступны остальным хостам пула, однако не смогут быть запущены до тех пор, пока их виртуальные диски не будут перемещены на хранилище, доступное хостам пула. Именно по этой причине при присоединении к пулу настойчиво рекомендуется перемещать данные с локальных хранилищ на общее, для того чтобы отдельные хосты XenServer можно было извлечь быстро и безопасно без потерь данных.

Подготовка хостов пула к обслуживанию (Maintenance)

Перед проведением обслуживания хоста XenServer, входящего в пул, следует отключить (disable) его (то есть запретить запуск виртуальных машин на хосте), затем мигрировать виртуальные машины на другие хосты пула. Это проще всего осуществить установив для хоста режим обслуживания (Maintenance mode) с помощью XenCenter.

Примечание: перевод мастер-хоста в режим обслуживания приведет к тому, что будут потеряны последние обновления RRD для выключенных виртуальных машин за последние 24 часа, т.к. синхронизация выполняется раз в сутки.

Citrix настойчиво рекомендует перезагружать все хосты XenServer ПЕРЕД установкой обновлений и затем проверять их конфигурацию. Некоторые изменения в конфигурации вступают в силу только после перезагрузки и таким образом перезагрузка может помочь выявить проблемы в конфигурации, которые могут сделать невозможным обновление.

Для подготовки хоста XenServer к обслуживанию (maintenance):
- Выполните команды:

xe host-disable uuid=<xenserver_host_uuid>
    xe host-evacuate uuid=<xenserver_host_uuid>

В результате хост будет отключен, а затем виртуальные машины мигрируют на другие хосты пула.

- Выполните нужные операции обслуживания.
- После выполнения обслуживания задействуйте хост, для чего выполните команду:

xe host-enable

- Запустите выключенные и приостановленные виртуальные машины.

Также перевести хост в режим обслуживания можно с помощью XenCenter.
Нужно кликнуть правой кнопкой по хосту и в меню кликнуть пункт Enter Maintenance Mode, или выделить хост, а затем в меню Server кликнуть пункт Enter Maintenance Mode.

4.2 - Обслуживание пула (Maintenance) при включенной высокой доступности (HA)

http://citrixxperience.com/2012/06/06/ha-best-practices-xenserver-host-maintenance/
http://citrixxperience.com/2012/06/05/xenserver-maintenance-mode-and-workload-balancing/

При работе с включенной высокой доступностью (HA) не следует вносить изменения в конфигурацию пула. Если необходимо внести существенные изменения в конфигурацию (например - установить обновления) следует сначала отключить HA, внести изменения, а затем включить HA снова.

Отключение HA:
1. В XenCenter в панели ресурсов выбрать пул.
2. Перейти на вкладку HA.
3. Кликнуть Disable HA и затем подтвердить - OK.

4.3 - Назначение нового мастер-хоста при включенной и отключенной HA

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#cli-xe-commands_ref_host-evacuate
Для переназначения мастер-хоста при отключенной высокой доступности (HA) необходимо выполнить команду pool-designate-new-master (см. http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#cli-xe-commands_pool-designate-new-master).

pool-designate-new-master host-uuid=<UUID of member XenServer host to become new master>

Данная команда назначает указанный хост мастер-хостом пула. В результате - роль мастер-хоста передается указанному хосту. Эту команду можно выполнить только если текущий мастер-хост присутствует в пуле. Если текущий мастер-хост вышел из строя, то нужно выполнить команду pool-emergency-transition-to-master

pool-emergency-transition-to-master

Команда предписывает хосту стать мастер-хостом. Команда будет выполнена только хостом, находящимся в режиме emergency mode. Подразумевается, что мастер-хост пропал из сети и остается недоступен после нескольких попыток связаться с ним.

При включенной высокой доступности (HA) можно просто выключить хост. Выборы нового мастер-хоста произойдут автоматически путем случайного выбора из имеющихся хостов.

4.4 - Создание хранилища для заданной конфигурации

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#ck_reference_storage_repository_types
Различные типы хранилищ поддерживаются XenServer с помощью подключения плагинов. Новые плагины могут быть добавлены в дирректорию /opt/xensource/sm. Изменение этих файлов не поддерживается, однако они доступны для просмотра и могут быть полезны разработчикам и продвинутым пользователям. Новые плагины, размещенные в этой директории автоматически распознаются XenServer. Для просмотра списка поддерживаемых типов хранилищ (SR types) используется команда sm-list.
Новые хранилища создаются в XenCenter с помощью мастера New Storage. Также для создания хранилища можно использовать команду sr-create, которая создаст хранилище на указанном устройстве, уничтожив там все данные. Также автоматически будут созданы объекты SR API и записи о физическом блочном устройстве (PBD). При успешном создании хранилища PBD подключается автоматически. Если указан флаг shared=true, то запись о физическом блочном устройстве (PBD) появится на всех хостах пула.
Все типы хранилищ XenServer поддерживают изменение размера VDI (VDI resize), быстрое клонирование (fast cloning) и создание мгновенных снимков (snapshot).
Хранилища на базе LVM (local, iSCSI или HBA) поддерживают «thin provisioning» (методика выделения пространства хранения приложениям не сразу при создании диска, а по мере возникновения в нем потребности у данных приложения, «on demand») для снэпшотов и скрытых родительских нод. Другие типы хранилищ поддерживают полных механизм thin provisioning (full thin provisioning), в том числе для активных виртуальных дисков.

Примечание: Автоматическое архивирование метаданных LVM по-умолчанию отключено. Однако это не мешает восстанавливать метаданные для групп LVM.

По-умолчанию неприсоединенные к виртуальной машине (например снэпшот) VHD VDI (логический том lvm с образом диска виртуальной машины) хранится в режиме «thin provisioning». Следовательно, перед присоединением к виртуальной машине и запуском следует убедиться, что на хранилище достаточно места для того, чтобы образ диска развернулся полностью (стал thickly provisioned).^

\\

Максимальные поддерживаемые размеры VDI:

Тип хранилища - - Максимальный размер VDI
EXT3 - - - - - - - - 2TB
LVM - - - - - - - - 2TB
NetApp - - - - - - - 2TB
EqualLogic - - - - 15TB
ONTAP(NetApp) - - - 12TB

Local LVM

Тип хранилища Local LVM - это локальный диск хоста, на котором размещена группа томов LVM (Volume Group).
По-умолчанию XenServer использует локальный диск хоста, на который он установлен. Для управления хранилищем используется Linux Logical Volume Manager (LVM). VDI (образы дисков виртуальных машин) хранятся в формате VHD в виде томов LVM нужного размера.
Версии XenServer до 6.0 не исползовали формат VHD. Дополнительную информацию о переводе хранилищ в новый формат можно найти тут: http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#upgrading_to_lvhd

Создание Local LVM SR (lvm)

Для создания local lvm SR на устройстве /dev/sdb используется следующая команда:

xe sr-create host-uuid=<valid_uuid> content-type=user \
name-label=<"Example Local LVM SR"> shared=false \
device-config:device=/dev/sdb type=lvm

Local EXT3 VHD

Хранилище типа Local EXT3 VHD - это набор файлов в формате VHD, хранящихся в каталоге, доступном локально.
Локальные диски хоста могут быть хранилищем типа EXT3 VHD.
Локальные хранилища типа EXT3 VHD не могут быть общими в пуле (shared) и, следовательно, хранящиеся на них образы виртуальных машин не могут мигрировать в пуле.

Создание хранилища типа Local EXT3 SR (ext)

Для создания local ext3 SR на устройстве /dev/sdb используется следующая команда:

xe sr-create host-uuid=<valid_uuid> content-type=user \
   name-label=<"Example Local EXT3 SR"> shared=false \
   device-config:device=/dev/sdb type=ext

Хранилище ISO

В хранилище типа ISO хранятся образы дисков CD в формате ISO. Этот тип предназначен для создания библиотек образов дисков в формате ISO. Для таких хранилищ параметр content-type должен иметь значение iso.
Например:

xe sr-create host-uuid=<valid_uuid> content-type=iso \
  type=iso name-label=<"Example ISO SR"> \
  device_config:location=<nfs server:path>>

Хранилища Software iSCSI

XenServer поддерживает хранилища на базе iSCSI LUNs. iSCSI поддерживается с помощью программного open-iSCSI инициатора, либо с помощью аппаратного адаптера iSCSI Host Bus Adapter (HBA).
Программный инициатор iSCSI позволяет работать с общим (shared) хранилищем на базе Linux Volume Manager (LVM) и предоставляет такую же производительность и функционал как и хранилище типа Local LVM, в том числе и “живую” миграцию XenMotion.
Хранилища iSCSI используют целый LUN, указываемый при создании хранилища и не могут включать в себя больше одного LUN. Для аутентификации поддерживается CHAP (как на этапе data path initialization, так и LUN discovery).

Конфигурирование хоста XenServer для использования iSCSI

Все инициаторы и таргеты iSCSI должны иметь уникальные имена. Инициатор и таргет имеют адреса iSCSI - iSCSI Qualified Names или коротко - - IQN.
Хост XenServer поддерживает один инициатор iSCSI, автоматически создаваемый при установке хоста, которому дается случайное имя IQN. Этот инициатор может подключаться к нескольким таргетам одновременно.
Таргеты iSCSI обычно предоставляют доступ данным в соответствии с заданным списком разрешенных инициаторов iSCSI. Таким образом, для того чтобы хост XenServer могу получить доступ к таргету может понадобиться внести имя его инициатора в список доступа. Аналогично, для того чтобы выступать в роли общего хранилища пула, таргет и LUN должны быть настроены соответсвующим образом, предоставляя доступ к LUN для всех iSCSI инициаторов хостов пула.

Как правило, если iSCSI таргет не поддерживает списков доступа, то он обеспечивает целостность данных путем предоставления доступа к одному LUN только одного инициатора. Для того чтобы таргет мог использоваться как общее хранилище для хостов пула, он должен поддерживать подключение нескольких инициаторов к одному LUN.^
Значение IQN хоста XenServer может быть переопределено либо с помощью XenCenter, либо командой:

xe host-param-set uuid=<valid_host_id> other-config:iscsi_iqn=<new_initiator_iqn>

Имена таргетов и инициаторов iSCSI обязательно должны иметь уникальные IQN. В противном случае LUN может стать недоступен, или возможны повреждения данных.^

Нельзя изменять IQN хоста XenServer при подключенных хранилищах iSCSI. Если изменить имя, не отключив хранилище, то могут возникнуть проблемы при доступе к новым, либо уже подключенным хранилищам.^

Создание общего хранилища iSCSI в пуле

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/installation.html#id885653
Для создания общего хранилища iSCSI в пуле нужно в консоли любого хоста пула выполнить команду:

xe sr-create name-label=<name_for_sr> \
    content-type=user device-config-target=<iscsi_server_ip_address> \ 
    device-config-targetIQN=<iscsi_target_iqn> \
    device-config-localIQN=<iscsi_local_iqn> \
    type=lvmoiscsi shared=true device-config-LUNid=<lun_id>

Аргумент device-config-target - это FQDN имя или IP адрес сервера iSCSI.
Аргумент device-config-LUNid - это список LUN ID (разделенных запятыми).
Так как аргумент shared имеет значение true, общее хранилище будет добавлено на всех хостах пула и хосты подключатся к хранилищу.
Команда возвращает UUID созданного хранилища.
Можно установить это хранилище используемым по-умолчанию в пуле:
Нужно выяснить UUID пула, с помощью команды pool-list.
Установить хранилище используемым по-умолчанию в пуле:

xe pool-param-set uuid=<pool_uuid> default-SR=<iscsi_shared_sr_uuid>

Теперь все создаваемые виртуальные машины будут размещены на этом хранилище.

Хранилища Citrix StorageLink

Хранилища Citrix StorageLink (CSL) используют прямой доступ к программным интерфейсам (API) аппаратных систем хранения, для разгрузки хостов от типичных “тяжелых” задач, таких как создание снэпшотов, клонирование и других.

CSL поддерживают несколько типов адаптеров, соответствующих API систем хранения. Сконфигурированный адаптер берет на себя задачи предоставления ресурсов СХД хостам XenServer по их требованию.

Так как хранилища CSL могут работать на базе разных СХД, точный набор поддерживаемых функций зависит от конкретной СХД. Все хранилища CSL используют модель LUN-per-VDI, то есть каждому виртуальному диску соответствует (VDI) отдельный LUN.

Хранилища CSL могут сосуществовать на одной СХД с хранилищами других типов. В пуле может быть создано несколько хранилищ Citrix StorageLink.

Хранилища CSL поддерживают СХД следующих типов:

NetApp/ IBM N Series

При использовании СХД NetApp в качестве хранилища StorageLink, на СХД для хоста XenServer автоматически создаются Initiator Groups. Для этих Initiator Groups в качестве Operating System (OS) указан Linux.
Добавление Initiator Groups вручную с другими типами OS не рекомендуется. ^

Dell EqualLogic PS Series

Dell EqualLogic API использует SNMP для взаимодействия. Требуется поддержка SNMP v3 и следовательно версия firmware v5.0.0 или более новая. Если ваша СХД EqualLogic работает под более старой firmware, то следует обновить firmware до версии v5.0.0.
После обновления нужно явно сбросить пароль администратора (grpadmin). Это нужно для того, чтобы пароль сконвертировался в ключи ауетнтификации и шифрования SNMPv3. Сбросить пароль можно подключившись к СХД с помощью telnet или ssh и выполнив команду:

account select grpadmin passwd

Пароль может быть таким же как и был до этого.^

Изменение IQN инициатора iSCSI

http://support.citrix.com/article/CTX131761
По-умолчанию, при установке программному инициатору iSCSI назначается случайный IQN.
Если значение IQN по-умолчанию не устраивает, то следует изменить его.

Необходимо создать файл /etc/iscsi/initiatorname.iscsi, если его не существует.^
Текущее значение IQN инициатора хоста можно найти в XenCenter на вкладке General данного хоста.
Для определения uuid хоста на до в консоли выполнить команду

xe host-list

Затем для изменения IQN выполнить команду:

xe host-param-set uuid=<host UUD> other-config:iscsi_iqn=<New IQN>

Дальше следует убедиться, что в файле /etc/iscsi/initiatorname.iscsi указано новое имя IQN.
Если это не так, то нужно открыть файл в редакторе (например nano) и изменить указанный там IQN вручную. Содержимое файла должно соотвествовать фомату:

InitiatorName=iqn.yyyy-mm.<reversed domain name>[:identifier]

То есть быть примерно таким:

 InitiatorName=iqn.2001-04.com.redhat:fc6

После этого надо перезапустить службу iSCSI:

service open-iscsi restart

Удостовериться, что сервис iSCSI запускается автоматически при старте системы:

chkconfig open-iscsi on
chkconfig --list

4.5 - Конфигурирование хранилища Intellicache

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/installation.html#intellicache
Применение IntelliCache позволяет более эффективно использовать ресурсы инфраструктуры, благодаря комбинации общего и локального хранилищ. В частности - в случаях когда есть много виртуальных машин, использующих один образ операционной системы, применение IntelliCache позволяет снизить нагрузку на СХД и повысить производительность. Благодаря тому что образ ОС кешируется на локальном хранилище, также снижается и сетевой трафик от СХД.
IntelliCache кеширует данные из основного VDI виртуальной машины на локальном хранилище хоста, на котором работает виртуальная машина.
Для работы IntelliCache требуется чтобы локальное хранилище поддерживало Thin Provisioning, то есть выделение требуемого места по требованию.

Включение Thin Provisioning изменяет тип локального хранилища с LVM на EXT3.^
Thin Provisioning позволяет использовать отображать больше места, чем есть на хранилище. Фактическое выделение пространства на хранилище происходит только когда виртуальная машина записывает данные.

Хранилища использующие Thin Provisioning могут быть переполнены, в результате активной записи данных виртуальными машинами. IntelliCache обрабатывает эту ситуацию автоматически, перенося образы дисков виртуальных машин обратно на общее хранилище. Не рекомендуется на одном хранилище смешивать обычные виртуальные машины и виртуальные машины поддержкой IntelliCache, так как образы дисков машин IntelliCache могут быстро расти.^

IntelliCache можно включить как при установке хоста XenServer, так и вручную с помощью командной строки.
Citrix рекомендует использовать максимально быстрые устройства в качестве локального хранилища (SSD или RAID). Общее хранилище может быть либо NFS, либо EXT.

Включение IntelliCache при установке

Для включения IntelliCache при установке, на стадии Virtual Machine Storage следует выбрать Enable thin provisioning (Optimized storage for XenDesktop).

Преобразование существующего локального хранилища в хранилище с поддержкой Thin Provisioning

Для того чтобы заменить текущее локальное хранилище LVM на хранилище типа EXT3 с поддержкой Thin Provisioning выполните следующие команды:

Выполнение этих команд уничтожит все данные на локальном хранилище.^

localsr=`xe sr-list type=lvm host=<hostname> params=uuid --minimal`
    echo localsr=$localsr
    pbd=`xe pbd-list sr-uuid=$localsr params=uuid --minimal`
    echo pbd=$pbd

    xe pbd-unplug uuid=$pbd
    xe pbd-destroy uuid=$pbd
    xe sr-forget uuid=$localsr
    sed -i "s/'lvm'/'ext'/" /etc/firstboot.d/data/default-storage.conf
    rm -f /etc/firstboot.d/state/10-prepare-storage
    rm -f /etc/firstboot.d/state/15-set-default-storage
    service firstboot start
    xe sr-list type=ext

Для того чтобы включить кеширование на локальном хранилище:

xe host-disable host=<hostname>
    localsr=`xe sr-list type=ext host=<hostname> params=uuid --minimal`
    xe host-enable-local-storage-caching host=<hostname> sr-uuid=$localsr
    xe host-enable host=<hostname>

Варианты загрузки виртуальной машины

Виртуальная машина может быть загружена в двух вариантах:
Shared Desktop Mode - В этом режиме виртуальная машина НЕ сохраняет сделанные пользователем изменения и всегда загружается в одном и том же состоянии.

Private Desktop Mode - В этом режиме виртуальная машина сохраняет сделанные пользователем изменения и загружается в том же состоянии, в котором была выключена.

Параметры, управляющие кешированием виртуальных машин

Параметр VDI allow-caching задает режим кеширования:

Shared Desktop Mode - параметр on-boot имеет значение reset, а флаг allow-caching установлен в значение true. Новые данные, генерируемые во время работы, будут записываться только на локальном хранилище. Таким образом, нагрузка на общее хранилище будет существенно снижена. В этом режиме машина НЕ сможет мигрировать между хостами.

Private Desktop Mode - параметр on-boot имеет значение persist, а флаг allow-caching установлен в значение true. Новые данные, генерируемые во время работы, будут записываться и на локальное и на общее хранилище. Таким образом, нагрузка на общее хранилище снижается только при чтении данных. В этом режиме машина сможет мигрировать между хостами.

4.6 - Конфигурирование DMP и MPP multipathing

http://support.citrix.com/article/CTX129309
Протокол iSCSI не приспособлен к обработке отказов оборудования и не поддерживает обработку отключения соединения или повторную отправку пакетов. Таким образом, крайне важно обеспечить максимальную надежность подключения хостов XenServer к СХД.
Multipathing - это механизм, позволяющий подключить СХД к хосту или пулу XenServer с помощью двух адаптеров одновременно. Таким образом обеспечивается повышение отказоустойсивости подключения (защита от выхода из строя аппаратных компонент), а также увеличение производительности.
В отличие от механизма объединения адаптеров (NIC bonding), который обеспечивает только избыточность, multipathing работает в режиме active-active, что позволяет не только повысить надежность, но и увеличить производительность.
Citrix рекомендует всегда вместо объединения адаптеров (NIC bonding) использовать multipathing и никогда не смешивать их в одной конфигурации.

Multipathing поддерживается при работе с хранилищами NFS и iSCSI.

При конфигурировании Multipathing следует учитывать следующее:
- Тип Multipathing, поддерживаемый СХД
- Количество IQN, предоставляемых СХД - один или много.
При включении Multipathing в пуле следует его сконфигурировать на всех хостах.

Совет: Узнать включен ли multipathing на хосте можно выбрав в XenCenter хост, на вкладке Multipathing.

Multipathing создает несколько подключений между хостом и хранилищем. Эти подключения называются пути (paths).
XenServer поддерживает обработчик DM-MP multipath handler. Основная задача DM-MP handler - представление в системе одного устройства хранения для каждого LUN ( которому установлено несколько подключений), а не множества устройств на каждое подключение (path). То есть DM-MP объединяет множество подключений к одному LUN в единое устройство хранения в системе. Без DM-MP Linux создает по одному устройству на каждый path.

Для подключения хоста XenServer к СХД должо быть установлено соединение между инициатором (клиентом) iSCSI и таргетом (сервером). Инициатор XenServer делает запрос к таргету СХД и ждет ответа о готовности со списком доступных IQN. Затем XenServer подключается к нужному IQN.
Установленное соединение между хостом XenServer и таргетом остается активным и должно быть установлено повтороно только в случае перезагрузки хоста. После конфигурирования multipath XenServer может создавать два (и более) подключения к СХД - по одному на каждое физичекое подключение (link).
Получив список IQN, который включает в себя серийные номера LUN, обработчик Multipath сравнивает серийные номера LUN на разных подключениях и определяет, являются ли обнаруженные LUN несколькими разными LUN, либо это один LUN и к нему установлено несколько подключений, а также определяет количество подключений установленных к одному LUN.
При создании хранилища (storage repository) с влюченным multipath, а именно - при создании Physical Block Device (PBD), XenServer добавляет параметр multihome, который указывает на то что логическое устройство связано с СХД несколькими подключениями.
Если в конфигурации XenServer не указано, что устройство хранения multihomed (например - multipath не был включен в момент создания PBD или хранилища (storage repository)), то XenServer сможет устанавливать к этому LUN только одно подключение.

При подключении к СХД с интерфейсом iSCSI лучше всего создавать конфигурацию multipath сразу. Хотя, если хранилище было создано при отключенном multipath, то можно перевести хост в режим обслуживания (maintenance mode) и сконфигурировать multipathing.

Для СХД с интерфейсом Fibre Channel, Citrix настойчиво рекомендует конфигурировать multipath и ставить флажок multipathing в XenCenter перед созданием хранилища (storage repository).
Для всех типов СХД рекомендуется планировать и конфигурировать подключения к массивам дисков заранее, до запуска пула в работу. Настройка multipathing после запуска пула в работу приведет к остановкам - настройка multipath повлияет на все виртуальные машины, размещенные на хранилище.

Поддержка обработчиков Multipath

XenServer поддерживает два обработчика multipath - Device Mapper Multipathing (DM-MP) и Multipathing Proxy Redundant Disk Array Controller (MPP RDAC). Кроме того, поддерживается и сочетание DMP RDAC.
По-умолчанию XenServer использует встроенный в Linux multipath - DM-MP. При этом, XenServer поддерживает различные расширения этого обработчика и может использовать различные функции, сецифичные для СХД разных производителей (vendor-specific features). Типичные примеры СХД с поддержкой режима портала (portal mode) - это многие СХД NetApp, HP Storage Works Modular Smart Array (MSA) и HP Storage Works Enterprise Virtual Array (EVA).
Для работы с СХД производства LSI XenServer поддерживает LSI Multi-Path Proxy Driver (MPP) для Redundant Disk Array Controller (RDAC). MPP RDAC работает иначе, чем DMP и требует некоторых подготовительных действий, выполненных в правильной последовательности. Начиная с XenServer 5.6 Feature Pack 1, XenServer имеет специальную команду интерфейса CLI, которая включает поддержку MPP RDAC и выполняет нужную последовательность действий в правильном порядке. Типичным примером СХД MPP RDAC является серии СХД Dell MD3000-series, IBM DS4000 и другие, указанные в статье CTX122824.
За дополнительными сведениями о поддерживаемых алгоритмах multipath Citrix рекомендует обращаться к документации, поставляемой с СХД. При возникновении разногласий следует учесть, что СХД на базе LSI как правило лучше всего работают с MPP RDAC.

Правильная настройка физических подключений и подсети

Самым правильным решением, для обеспечения отказоустойчивости, является использование двух коммутаторов. Однако, в случае если два коммутатора не используются, то следует логически разделить пути (paths), то есть назначить каждому сетевому адаптеру СХД (NIC) свою подсеть и соотвествующим образом настроить адаптеры хостов XenServer. И, разумеется, правильно настроить параметры TCP/IP.

После правильного физического подключения можно включить или выключить поддержку multipathing в XenCenter на вкладке хоста Multipathing. Это проще сделать, когда хранилище (storage repository) еще не создано. Вцелом процесс включения multipathing требует выполнения ряда задач, приведенных далее.

ВАЖНО! не следует использовать основной интерфейс управления хостом XenServer для передачи трафика iSCSI

Настройка программного инициатора iSCSI для поддержки Multipathing

ВАЖНО! Citrix рекомендует либо включать multipathing с помощю XenCenter перед подключением пула к СХД, либо (если хранилище XenServer уже создано) переводить хост в Maintenance Mode перед включением multipathing.

Если multipathing включен когда хост подключен к хранилищу (storage repository), то XenServer может не суметь правильно сконфигурировать multipathing. Если хранилище (storage repository) уже создано и нужно сконфигурировать multipathing, то сначала следует перевести все хосты пула в режим Maintenance Mode, а затем сконфигурировать multipathing на всех хостах пула. Это гарантирует, что данные всех работающих виртуальных машин мигрируют, перед применением изменений.

Приведенная ниже инструкция предполагает использование XenCenter.
Настройка программного инициатора iSCSI с использованием multipathing:
1. Создайте избыточные (резервные) физические подключения и настройте параметры подсетей TCP/IP. Убедитесь, что созданы подсети как для адаптеров хостов XenServer, так и для адаптеров СХД и адаптеры подключены правильно.
2. В соотвествии с рекомендациями производителя СХД сконфигурируйте СХД и создайте LUN с поддержкой multipathing.

ВАЖНО! следите за тем, чтобы все IQN (и таргетов и инициаторов) были уникальны! В случае наличия в сети одинаковых IQN возможно повреждение данных, а также нарушение доступа к iSCSI таргету.

3. Убедитесь, что порты таргета iSCSI работают в режиме портала (portal mode):
В XenCenter, запустите мастер New Storage Repository (Storage menu > New Storage Repository).
i. На странице мастера Enter a name and path for the new iSCSI storage кликните Discover IQNs. XenServer запросит у таргета список IQN.
ii. Проверьте, что список Target IQN на странице Location. Если порты таргета iSCSI работают в режиме портала (portal mode), то все IP таргета должны показаться на странице Location.

4. Включите обработчик multipath одним из способов:
• В случае MPP RDAC, включите multipathing в XenCenter (то есть выберите Enable multipathing на сервере на вкладке Multipathing), дополнительную информацию о работе СХД LSI смотрите раздел “Enabling MPP RDAC Handler Support for LSI Arrays”.

ПРИМЕЧАНИЕ: Citrix рекомендует обратиться к документации СХД для выбора оптимального обработчика multipath. СХД LSI обычно лучше работают с MPP RDAC.

• При использовании DMP, то есть выберите Enable multipathing на сервере на вкладке Multipathing в свойствах хоста.

Включение обработчика '''MPP RDAC''' для СХД LSI

Для включения поддержки MPP RDAC нужно выполнить приведенную ниже процедуру на всех хостах пула:
1. В консоли хоста выполните следующую команду:

# /opt/xensource/libexec/mpp-rdac --enable

2. Перезагрузите хост.

Создание хранилища (Storage Repository) после включения Multipathing

Лучше всего создавать хранилище (storage repository) после конфигурирования multipathing на всех хостах пула. При создании хранилища на хостах с включенным multipathing нужно указать правильное количество IQN таргета, возвращаемое СХД.
При создании хранилища нужно указать IQN таргета, то есть адреса, указывающего на нужное устройство iSCSI, однако в ответ на запрос СХД может возвращать несколько IQN, в зависимости от конфигурации СХД.
После включения multipathing оба пути (paths) должны указывать на один и тот же LUN, а таргет должен возвращать единственный IQN. Однако, некоторые СХД даже после включения multipath возвращают разные IQN (одного и того же LUN) на разных подключениях.
Вид IQN-ов в мастере Storage Repository может несколько удивить, так как там отображаются некоторые дополнительные сведения. В отличие от вывода консольной команды xe sr-probe, в XenCenter отображаются IP-адреса сетевых адаптеров контролера СХД, а такде номер порта, хост и имя СХД.
Если СХД возвращает один или несколько IQN, то в XenCenter будет отображаться примерно следующее:

Первая часть IQN - указывает на тип, дату создания и имя. ВТорая часть - задается производителем СХД. Третья - IP адрес контроллера СХД и порт.

Некоторые СХД, например DataCore и StarWind имеют возмжность возвращать несколько IQN (multi-IQN feature). Для работы с данным типом СХД следует указывать IP-адреса всех таргетов в поле Target Host на странице мастера Location. и разделять IP-адреса запятыми. После ввода адресов и нажатия на кнопку Discover IQNs, XenCenter покажет несколько IQN-ов с разными именами.
Для СХД, возвращающих несколько IQN, при создании хранилища следует выбирать опцию Wildcard Masking (*) в XenCenter, которая обозначается звездочкой (*) в начале поля Target IQN как показано ниже:

Для создания хранилища после включения multipathing:
1. В XenCenter создайте новое хранилище (storage repository) с помощью мастера New Storage Repository.
2. На этапе ввода параметров iSCSI (Enter a name and path for the new iSCSI storage) заполните поля до этапа Discover IQNs.
3. Кликните Discover IQNs. XenServer получит от СХД список IQN-ов. Затем:
• Если возвращается только одно (одинаковое) значение IQN, то выберите нужный LUN и сконфигурируйте его.
• Если возвращается много IQN-ов, то выберите опцию (*) из списка Target IQN.
4. Finish creating the storage repository and exit the wizard.

4.7 - Создание сети и назначение VLAN

Source: Citrix XenServer Design: Designing XenServer Network Configurations,
Pages 30 - 32
http://support.citrix.com/article/CTX129320
Source: Citrix XenServer 6.0 Administrator’s Guide
http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#network
ing-standalone_host_config-vlans

тормозит-курсор-мыши-в-autocad-опубликованном-на-сервер ...

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Проблема

Тормозит курсор мыши в Autocad, опубликованном в XenApp 6.5.

Решение

Citrix рекомендует сделать несколько вещей.
Первое - отключить Desktop Viewer Toolbar Functionality (http://support.citrix.com/article/CTX119784).
Для этого:
1. В файле WebInterface.conf, расположенном на сервере WebInterface тут C:\inetpub\wwwroot\Citrix\SiteName\conf\ нужно вставить строку

FarmsWithNoConnectionBar=Farm1, Farm2, Farm3, ...

В этой строке перечислены имена ферм, для которых надо отключить Desktop Viewer Toolbar.

2. Убедиться, что в файле c:\inetpub\wwwroot\citrix\SiteName\conf\webinterface.conf присутсвует строка ShowDesktopViewer=On. По-умолчанию она имеет вид: #ShowDesktopView=Off.

3. Также надо убедиться, что в файле c:\inetpub\wwwroot\citrix\SiteName\conf\default.ica отсутсвуют строки ConnectionBar=0 или ConnectionBar=1.

Еще можно на клиенте уменьшить задержку между движением мыши и пересылкой информации о движении на сервер. http://support.citrix.com/proddocs/topic/ica-settings/ica-settings-mousetimer.html

Для этого нужно изменить значение параметра MouseTimer в реестре в ветках:

HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Virtual Channels\Mouse 	
HKEY_CURRENT_USER\Software\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Virtual Channels\Mouse

Там лежит время задержки в милисекундах. По умолчанию - 100 мс. Актуально ставить 20.

Вот тут еще немного шаманства:
http://autocadtipoftheday.com/tips/how-to-fix-lagging-mouse-movement-in-autocad

Оптимизация XenApp вцелом:
http://www.norskale.com/articles/article/xendesktop-tuning-tips

Вот тут про оптимизацию схемы курсоров мыши:
http://citrixblogger.org/2008/02/07/cursor-shadowing-turn-it-off/
http://citrix-xendesktop.blogspot.ru/2012/06/appsense-mouse-lags-in-xenapp.html
http://geekcubo.com/2014/04/group-policy/
http://citrixblogger.org/2008/02/07/cursor-shadowing-turn-it-off/

installation_of_msi_file_failed_with_code_installfailure_1603

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Проблема

Попытка установки (переустановки) VDA-агента версии 7.6.1000 (и других) заканчивается ошибками типа:

 Installation of MSI File 'IcaTS_x64.msi' failed with code 'InstallFailure' (1603).

Причина

В соотвествии со статьей microsoft: https://support.microsoft.com/ru-ru/kb/834484 эти ошибки связаны с тем, что MSInstaller не может получить права на запись либо в какую-то папку либо в реестр.

Решение

Лучше всего в этих случаях пользоваться VDA CleanUp Utility, которая исправно обновляется, а в новых версиях VDA, она уже входит в дистрибутив и может быть установлена вместе с VDA.

После удаления VDA на Windows server 2008 R2 я просто удалил папки Citrix из Program Files и Program Files(x86) и удалил ветки Citrix из реестра:

[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix]
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\citrix]

Вот тут указывают более конкретную ветку реестра на котрую не хватает прав:
https://discussions.citrix.com/topic/379383-ltsr-cu1-install-error-1603/
Нужно дать всем пользователям полные права на ветку:

HKLM\SOFTWARE\Wow6432Node\CITRIX\EUEM

Эти ветки реестра иногда не удаляются даже с помощью VDA CleanUp Utility. Также у меня не получилось удалить их от имени SYSTEM с помощью psexec. Оказалось, как написано тут: https://support.citrix.com/article/CTX215992 на проблемную ветку HKLM\Software\Wow6432Node\Citrix\EUEM\LoggedEvents имеют полные права юзеры из локальной группы Remote Desktop Users. То есть, для того, чтобы получить права на удаление этой ветки нужно включить себя в группу Remote Desktop Users и перелогиниться:

net localgroup "Remote Desktop users" "DOMAIN\USER" /add

migrate_roaming_profiles_to_citrix_profile_management

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Задача

Есть ферма Citrix XenDesktop 7.15. Она раздает рабочие столы Windows Server 2016 - hosted shared.
В данный момент используются roaming profiles, которые лежат на файловом сервере и доступны через DFS.
Нужно внедрить Citrix Profile Management и мигрировать туда все профили.
https://docs.citrix.com/en-us/profile-management/downloads/profile-management-7-15.pdf
https://www.carlstalhood.com/citrix-profile-management/

Решение

Пути к профилям (NUS - network user store)

В путях к профилям могут быть использованы значения аттрибутов, заключенные в # - #attributename# и переменные окружения - заключенные в % - %VARIABLE_VALUE%, а также параметры OS. Например - \\server\profiles$\#attributename#\%USERNAME%.%USERDOMAIN%\!CTX_OSNAME!!CTX_OSBITNESS!
Путь к профилям (NUS - network user store)- \\domain\#extensionAttribute1#\Profiles\

Перенаправление папок

Citrix рекомендует перенаправлять все папки, содержимое которых используется нерегулярно или не изменяется в процессе работы. Список папок, перенаправление которых возможно в данной ОС можно найти в реестре - HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
В XenDesktop 7 перенапрвляемые папки должны быть сконфигурированы в политике Xendesktop с помощью Studio. В моем случае Групповые политики перенаправляют папки:

Documents (и вложенные My Music, My Pictures, My Videos) - \\domain\#extensionAttribute1#\Users\#samAccountName#\Documents
Desktop - \\domain\#extensionAttribute1#\Environment\Standard\Desktop
StartMenu - \\domain\#extensionAttribute1#\Environment\Standard\StartMenu

Установка

Обычно, компоненты Citrix Profile management устанавливаются в составе VDA.
проверить, установлен ли Citrix Profile management можно командой:

wmic product list | find "Citrix Profile management"

Мне придется переустановить VDA на многих серваках. Предварительно, удалив его с помощью VDACleanupUtility. Важно помнить, что для корректного удаления всех элементов VDA, пользователь, производящий удаление должен не только быть локальным админом, но и членом группы Remote Desktop Users.

Для того, чтобы настраивать эти компоненты нужно добавить в домен шаблоны политик (admx templates), которые есть в составе ISO-образа в папке \x64\ProfileManagement\ADM_Templates. Раскладывать так:

\x64\ProfileManagement\ADM_Templates\en\ctxprofile7.15.300.admx → \\domain\SYSVOL\domain_fqdn\Policies\PolicyDefinitions\ (или в C:\Windows\PolicyDefinitions на контроллере домена). Старые шаблоны политик (файлы ctxprofile*.admx) надо удалять.
\x64\ProfileManagement\ADM_Templates\en\ctxprofile7.15.3000.adml → \\domain\SYSVOL\domain_fqdn\Policies\PolicyDefinitions\en-us\ (или в C:\Windows\PolicyDefinitions\en-us\ на контроллере домена). Старые файлы ctxprofile*.adml надо удалять.
Файлы CitrixBase.admx и CitrixBase.adml из папки \x64\ProfileManagement\ADM_Templates\CitrixBase нужно разложить аналогично в папки PolicyDefinitions и PolicyDefinitions\en-us\. Старые файлы CitrixBase*.* удалить/заменить.

сессия_пользователя_на_2008r2_active_но_ни_подключиться_к_� ...

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Проблема

На терминальных серверах под управлением Windows 2008R2 в составе фермы Citrix Xendesktop 7.6 периодически возникает ситуация, когда сессия пользователя есть на сервере, она в состоянии Active, однако у нее отсутствует Session ID (вида ica-tcp#–). При этом ни подключиться к этой сессии. ни закрыть ее не получается. TaskManager при попытке завершения процессов пользователя перестает отвечать. Не удалется завершить ни один процесс пользователя и из командной строки с помощью

taskkill /f /FI "USERNAME eq Domain_name\user_name"

При этом, сервер невозможно штатно перезагрузить. Он не уходит в перезагрузку и помогает только кнопка Reset.

Решение

Microsoft утверждает. что причина в deadlock'e в файлике Win32k.sys - https://support.microsoft.com/en-us/kb/2866519

Напрямую можно скачать тут: http://hotfixv4.microsoft.com/Windows%207/Windows%20Server2008%20R2%20SP1/sp2/Fix462371/7600/free/465697_intl_x64_zip.exe

Package: Win32k.sys
----------------------------------------------------------- 
KB Article Number (s) : 2866519  
Language: All (Global)  
Platform: x64  
Location: ( http://hotfixv4.microsoft.com/Windows%207/Windows%20Server2008%20R2%20SP1/sp2/Fix462371/7600/free/465697_intl_x64_zip.exe )

Или тут: windows2008r2_sessiondeadlockfix_windows6.1-kb2866519-x64.msu.zip

Установка

При установке патча система может ругнуться, что This update does not apply to this system. В этом случае можно распаковать и установить патч вручную:

expand -F:* Windows_patchname.msu %temp%\kb_xxxxxx\
start /w %SystemRoot%\system32\pkgmgr.exe /ip /m:%temp%\kb_xxxx\Windows_patchname.cab

Также можно и удалить этот патч, заменив /ip на /up.

Если это не помогает

Вот еще апдейты на эту тему:
KB2578159 - The logon process stops responding in Windows Server 2008 R2 or in Windows 7
KB2383928 - Remote desktop sessions do not completely exit, and you cannot establish new remote desktop sessions to a computer that is running Windows Server 2008 R2
KB124873 - Disabling System Hard Error Message Dialog Boxes
KB2661332 - You cannot reestablish a Remote Desktop Services session to a Windows Server 2008 R2-based server
KB2526870 - Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2 may stop responding at the Welcome screen - важная хрень (входит в состав KB2775511) !

также сообщают что кумулятивный апдейт KB2775511 ( http://support.microsoft.com/kb/2775511/en-us) чинит ситуацию с зависанием на этапе Welcome Screen, но я не смог его поставить. Ставился сутки.

Ответ поддержки Citrix

Поддержка Citrix (росийская от софтлайн) утвержает, что для решения этой проблемы должен быть установлен следующий набор патчей:

KB2479943
KB2506212
KB2509553
KB2511455
KB2544893
KB2560656
KB2564958
KB2570947
KB2585542
KB2604115
KB2620704
KB2621440
KB2631813
KB2654428
KB2667402
KB2676562
KB2690533
KB2698365
KB2705219
KB2706045
KB2727528
KB2728738
KB2732673
KB2736422
KB2742599
KB2758857
KB2765809
KB2770660
KB2803821
KB2807986
KB2813347
KB2847927
KB2878378

Получить список уже установленных патчей можно командой:

systeminfo

или

wmic qfe list brief

Затем я кладу список установленных патчей в файлик installed (только hotfixID), а список необходимых - musthave и сравниваю в linux командой:

grep -viFf installed musthave

В моем случае на большинстве серверов отсутствовали следующие патчи:

KB2479943
KB2727528
KB2728738
KB2732673
KB2736422
KB2803821
KB2847927
KB2878378

linux_vda_errors

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

The Citrix Desktop Service detected that a user session has ended. Session has ended; reason code 'Logoff'.

ОС - OpenSuse Leap 42.1. VDA - XenDesktopVDA-7.13.0.382-1.sle11_4.x86_64.rpm
В журналах:

journalctl -f

При открытии сессии сообщение такое:

citrix-ctxgfx[13256]: Exiting due to errors.

Вот тут: http://discussions.citrix.com/topic/368033-pclinuxos64-mate/ Советуют попробывать вручную запустить:

/opt/Citrix/VDA/bin/ctxvfb

И посмотреть что будет. У меня начали вываливаться сообщения об отсутствии shared libraries.
libhal брал тут: http://ftp.gwdg.de/pub/opensuse/repositories/home:/m407/openSUSE_42.1/x86_64/libhal1-0.3.1-4.1.x86_64.rpm
и еще устанавливал:

sudo zypper -n in libsmbios2 libssl37

libssl.so.0.9.8 брал тут: http://download.opensuse.org/update/11.3/rpm/x86_64/libopenssl0_9_8-0.9.8m-3.3.2.x86_64.rpm

Failed to obtain computer SID from LDAP

Лог содержит такое:

[ERROR] Failed to query LDAP server 'my_dc_name:389' for computer SID. Error: LDAP Search error: LDAPSearch.GetKerberosAgentClientSubject: Unable to obtain LDAP Login Context.
[ERROR] - LDAPSearch.GetKerberosAgentClientSubject: Unable to obtain LDAP Login Context for 'agent.client'. Error: Unable to obtain password from user
[WARN ] - InformationManager.GetComputerSID: Failed to obtain computer SID from LDAP.
[ERROR] - InformationManager.GetComputerSID: Failed to determine Computer SID for FQDN: myhost.mydomain.ru.

При этом:

  sudo wbinfo --name-to-sid=$computerName
  S-1-5-21-2734858679-1761669737-1885829517 SID_DOMAIN (3)
 
  sudo wbinfo --name-to-sid=myhost.mydomain.ru\$
  failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND
  Could not lookup name myhost.mydomain.ru$

  sudo wbinfo --name-to-sid=myhost\$
  S-1-5-21-2734858679-1761669737-1885829517-374696 SID_USER (1)

То есть судя по всему удается корректно получить SID по имени хоста, но не удается получить SID по FQDN.

Решение - Failed to obtain computer SID from LDAP.

В моем случае VDA устанавливался скриптом, в котором параметр CTX_XDL_SEARCH_BASE был задан так:

CTX_XDL_SEARCH_BASE=' '

То есть был ненулевой и не <none>, а был равен символу “пробел”. В результате VDA пытался обнаружить учетку компа в OU с именем “пробел” и обламывался. Чтобы все работало правильно в установочном скрипте параметры без значений нужно задавать так: <none>.

manual_configure_license_server_for_rds_2012

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Проблема

Сервера Windows 2012 в составе фермы XenDesktop 2012 не видит никаких серверов лицензирования RDS и не пускает пользователей. Задать сервер лицензирования с помощью GUI или Powershell можно только в составе фермы RDS Microsoft.

Решение

Можно указать сервер лицнзирования с помощью локальной политики. Запускаем gpedit.msc Дальше идем в раздельчик: Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Licensing и тут указываем необходимые параметры.

Также можно задать сервер лицензирования напрямую в реестре: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

LicenseServers 	<license server>
LicensingMode 	2 for PerDevice; 4 for PerUser

настройка_citrix_reciever_4.3_c_помощью_admx_based_gpo

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Задача

Настроить сквозную аутентифкацию (Pass-Through Authentication) Citrix Reciever 4.3 с помощью GPO.

Для этого понадобится:
- Установить Citrix Receiver с включенным SSO (SingleSignOn). - Создать централизованное хранилище шаблонов admx и разместить там шаблоны.
- Создать объекты GPO на базе шаблонов admx и настроить параметры.

Новый Citrix Receiver (от 30 июня 2015) при установке предлагает поставить галочку SSO. Старый нужно ставить с ключем /includeSSON

Создание централизованного хранилище шаблонов admx

Описано тут: https://technet.microsoft.com/ru-ru/library/cc748955%28v=ws.10%29.aspx

В двух словах.
Создаем папки %systemroot% \sysvol\domain\policies\PolicyDefinitions и %systemroot% \sysvol\domain\policies\PolicyDefinitions\EN-US

Потом в папку %systemroot% \sysvol\domain\policies\PolicyDefinitions кладем файлики:
C:\Program Files (x86)\Citrix\ICA Client\Configuration\HdxFlash-Client.admx
C:\Program Files (x86)\Citrix\ICA Client\Configuration\ica-file-signing.admx
C:\Program Files (x86)\Citrix\ICA Client\Configuration\receiver.admx

А в папку %systemroot% \sysvol\domain\policies\PolicyDefinitions\EN-US кладем файлики:
C:\Program Files (x86)\Citrix\ICA Client\Configuration\receiver.adml
C:\Program Files (x86)\Citrix\ICA Client\Configuration\ica-file-signing.adml
C:\Program Files (x86)\Citrix\ICA Client\Configuration\en-US\HdxFlash-Client.adml

Создание объекта политики GPO на основе шаблонов admx

Шаблоны admx из центрального хранилища подтянутся автоматически. Просто создаем объект GPO и связваем его с нужной OU.

Теперь настраиваем сквозную аутентификацию. Этот процесс описан тут: http://support.citrix.com/article/CTX200157 Но некторыми шагами я пренебрегаю.

Вообще моя цель настроить все так, чтобы авторизация проходила прозрачно и автоматически на рабочем столе создавались ярлыки, а режим SelfServiceUI был отключен. То есть чтобы все работало как в CitrixOnlinePlugin 12.3.

Итак настраиваем параметры:

Включаем сквозную авторизацию. Редаектируем параметр: Local user name and password в ветке Computer Configuration\Administrative Templates\Classic Administrative Templates\Citrix Components\Citrix Receiver\User authentication\.
В ней ставим галочку Enable pass-through authentication and Allow pass-through authentication for all ICA connections.

Включаем размещение ярлыков на рабочий стол. В Computer Configuration\Administrative Templates\Classic Administrative Templates\Citrix Components\Citrix Receiver\SelfService отключаем параметр Manage SelFService Mode.
Настраиваем Manage App ShortCuts. Включаем его и указываем в Desktop Directory просто слеш: /. В результате ярлыки будут попадать прямо на рабочий стол. Ставим также галку Enable Desktop Shortcut .

Также надо указать адрес storefront или web-интерфейса фермы: Computer Configuration\Administrative Templates\Classic Administrative Templates\Citrix Components\Citrix Receiver\Storefront. тут Storefront прописываем в таком формате:

Имя_Storefront;https://_адрес_storefront;On_или_Off;Описание_Storefront

Например:

SalesStore;https://sales.example.com/Citrix/Store/discovery;On;Store for Sales staff

Старый Web-интерфейс 5.4 прописывается так:

CitrixAppstore;https://appstore.domain.com/Citrix/PNAgent/Config.xml;On;Citrix Appstore

То есть надо указать путь до файла PNAgent/Config.xml

citrix-reciever-под-ubuntu-14-04-x64

anonymous@undisclosed.example.com (Anonymous) — Tue, 21 May 2019 09:50:55 +0000

Этот мануал уже не актуален. Citrix Reciever 13.1 устанавливается нормально. Хотя и небезглючен

Часть Первая - запуск в 64-битной среде

Довольно странным оказался тот факт, что пакет Citrix Reciever, скачиваемый с сайта citrix.com просто так не ставится и нуждается в доработке напильником. Это происходит по двум причинам. Во-первых - сам пакет 32-битный, а во вторых - пакеты, от которых он зависит в новой Ubuntu заменены другими. Это касается версий пакета 12.x и 13.

Процедура описана тут: https://help.ubuntu.com/community/CitrixICAClientHowTo

В двух словах. Нужно скачать пакет, распаковать его и отредактировать зависимости.
Включаем поддержку 32-битных пакетов:

sudo dpkg --add-architecture i386 # only needed once
sudo apt-get update

Ставим зависимости:

sudo apt-get install libmotif4:i386 nspluginwrapper lib32z1 libc6-i386 libxp6:i386 libxpm4:i386 libasound2:i386

Скачиваем пакет x64 Citrix Receiver 12.1 .deb

https://www.citrix.com/downloads/citrix-receiver/receivers-by-platform/

Ремонтируем пакет. Распакуем его:

cd ~/Downloads
mkdir ica_temp
dpkg-deb -x icaclient_13.0.0.256735_amd64.deb ica_temp
dpkg-deb --control icaclient_13.0.0.256735_amd64.deb ica_temp/DEBIAN

Корректирум список зависимостей:

nano ./ica_temp/DEBIAN/control

И меняем строку Depends: … на:

Depends: libc6-i386 (>= 2.7-1), lib32z1, nspluginwrapper, libxp6:i386, libxpm4:i386

Теперь отредактируем постинсталляционный скрипт:

nano ./ica_temp/DEBIAN/postinst

Ищем строку:

echo $Arch|grep "i[0-9]86" >/dev/null

и заменяем ее на :

echo $Arch|grep -E "i[0-9]86|x86_64" >/dev/null

Пересобираем пакет:

dpkg -b ica_temp icaclient-modified.deb

Ставим его:

sudo dpkg -i icaclient-modified.deb

Теперь добавляем сертификаты. Я сначала брал сертификат центра сертификации с сервера WIndows в файле .cer, потом импортировал его в Firefox (Edit → Prefrences → Advanced → Certificates → View Certs → Authorities → Import).
А потом делал ссылку на серты Firefox в папку с сертами Citrix:

sudo ln -s /usr/share/ca-certificates/mozilla/* /opt/Citrix/ICAClient/keystore/cacerts/

Все. Теперь можно работать. Заходим на свой сайт Citrix Web Interface, логинимся и тыкаем в ярлычок с приложением. Firefox спросит что делать с файлом launch.ica. Нужно указать ему путь к исполняемом файлу клиента ICA - /opt/Citrix/ICAClient/wfica

Всё.

Часть Вторая - нормальный полноценный запуск

Сначала я думал, что всё… Будет работать…Однако, это оказалось совсем не всё… К сожалению, .deb пакет Citrix Reciever на данный момент (июль 2014 года) собран очень похабно. Фактически - в нем просто прописали что архитекртура теперь amd64.. И всё. Будучи установленным непосредственно в 64-bit систему он нуждается в некоторых 32-bit пакетах, которые невозможно установить рядом с 64-bit. То есть - работает запуск приложений из браузера, но вот получить окошко Reciever с приложенимя так просто не удается. Но выход есть! Это создание 32-х битного окружения chroot и запуск Reciever в нем.

Итак, поехали.
Делаем chroot.

Ставим то что нам понадобится:

sudo apt-get install debootstrap schroot

Создаем директорию и конфигурационный файл для нашего chroot:

sudo mkdir /trusty_i386
sudo nano /etc/schroot/chroot.d/trusty_i386.conf

И записываем туда вот что:

[trusty_i386]
description=Ubuntu 14.04 Trusty for i386
directory=/trusty_i386
personality=linux32
root-users=mike
type=directory
users=alice,mike

Тут:
directory (раньше - location) - Директория где будут лежать файлы этого environment. Директория должна быть за пределами /home. tree.
По-умолчанию - /srv/chroot.

personality - Эта строка нужна, если хост-система 64-bit, а chroot-система - 32-bit. В противном случае можно отключить или закомментировать “#”.

root-users - Пользователи хост-системы, которые имеют права запускать schroot и получат root-доступ к chroot-окружению.

users - Пользователи хост-системы, которые имеют права запускать schroot и получат пользовательский доступ к chroot-окружению.

Выполнем установку нашей Ubuntu 14.04 Trusty 32-bit системы в указанную папку:

sudo debootstrap --variant=buildd --arch=i386 trusty /trusty_i386 http://archive.ubuntu.com/ubuntu/

Для других дистрибутивов просто меняем trusty на название дистра (например для Ubuntu 13.04 - precise)

Смотрим на список сконфигурированных chroot:

schroot  -l

Копируем туда пользователей и группы из хостовой системы:

sudo cp /etc/group /trusty_i386/etc/
sudo cp /etc/passwd /trusty_i386/etc/

Теперь запустим наше chroot-окружение и убедимсо, что там внутри 32-bit:

schroot -p -c trusty_i386 -u root
(trusty_i386)root@host-system:/home/mike# uname -a
Linux host-system 3.16.0-031600rc2-generic #201406220135 SMP Sun Jun 22 05:36:21 UTC 2014 i686 i686 i686 GNU/Linux

В данном случае -p указывает на то, что мы хотим передать в chroot текущее окружение пользователя. Это необходимо для того, чтобы правильно передалась переменная DISPLAY, которая важна для запуска GUI-приложений.

Затем в окружении chroot ставим компоненты системы:

(trusty_i386)root@host-system:/home/mike# apt-get install ubuntu-minimal

Обязательно нужно реконфигурировать locales. Признаком ошибок в конфигурации locales является появление при запуске Citrix Reciever сообщений типа: Gtk-WARNING **: Locale not supported by C library.. Выполянем:

sudo locale-gen en_US en_US.UTF-8 ru_RU ru_RU.UTF-8
sudo dpkg-reconfigure locales

Теперь ставим сам Citrix Reciever.
Скачиваем 32-битный пакет и кладем его куда-нить в папку /trusty_i386.
Дальше нужно удовлетворить зависимости. Для этого я просто попытался установить пакет в лоб, а затем доставил зависимости:

(trusty_i386)root@host-system:/home/mike#  dpkg -i /opt/icaclient_13.0.0.256735_i386.deb
(trusty_i386)root@host-system:/home/mike#  apt-get -f install

Однако этого оказалось маловато. Есть такой пакетик libxerces-c3.1, который почему-то не входит в стандартный репозиторий Ubuntu.
Его ставим так:

echo "deb http://cz.archive.ubuntu.com/ubuntu trusty main universe" >> /etc/apt/sources.list
apt-get update
apt-get install libxerces-c3.1

И уже потом делаем

(trusty_i386)root@host-system:/home/mike#  dpkg -i /opt/icaclient_13.0.0.256735_i386.deb

У меня все поставилось.
Дальше надо положить сертификаты из хост-системы в chroot в папку /opt/Citrix/ICAClient/keystore/cacerts/.
Их можно скопировать из папки с сертификатами mozilla. В хостовой системе выполняем:

cp /usr/share/ca-certificates/mozilla/* /trusty_i386/opt/Citrix/ICAClient/keystore/cacerts/

И это еще не все. По непонятной причине из браузера приложения запускаются с сертификатом в виндовом формате .cer (x509 der), а вот Citrix Receiver в режиме kiosk-mode cс таким сертификатом запускаться отказывается с сообщением “Your account cannot be added using this server address. Make sure you entered it correctly”. И отладочных сообщений никаких. В лучших традициях Microsoft.
Для того чтобы все заработало нужно сконвертировать сертификат в форма .pem и выполнить rehash:

openssl x509 -inform der -in /opt/Citrix/ICAClient/keystore/cacerts/your_CA_root_cert.cer  -out /opt/Citrix/ICAClient/keystore/cacerts/your_CA_root_cert.pem
c_rehash /opt/Citrix/ICAClient/keystore/cacerts/

После этого можно смело запускать Citrix Reciever:

(trusty_i386)root@host-system:/home/mike# /opt/Citrix/ICAClient/selfservice &

Для того чтобы запускать Citrix Reciever скриптом я сделал так вот что.
В окружении trusty_i386 с сделал скрипт /opt/CitrixReciever.sh:

#! /bin/sh
/opt/Citrix/ICAClient/selfservice

Сделал его исполняемым:

chmod a+x /opt/CitrixReciever.sh

После этого в хост-системе я могу запускать Citrix Reciever командой:

SESSION=$(schroot --begin-session -p -c trusty_i386 --session-name CitrixReciever) && schroot --run-session -p -c "$SESSION" -- /opt/CitrixReciever.sh && schroot --end-session -c "$SESSION" &

Эту же команду я засунул в Link to application, а в файле .desktop потом прописал icon - /trusty_i386/opt/Citrix/ICAClient/icons/025_Receiver_h32bit_48.png и получился ярлык как в Windows.

Настроить параметры Reciever можно с помощью утилиты configmgr, которая запускается так:

/opt/Citrix/ICAClient/util/configmgr

Там среди всего прочего можно настроить доступ к файловой системе. Но так как мы работаем из chroot, то понадобится пробросить папки из хостовой системы в chroot.

Установка ctxusb

При установке ctxusb возникают проблемы с запуском.
Система пишет:* Starting Citrix USB daemon [fail]

В логах следующее:

libcap: 
# cat /var/log/syslog | grep ctxusbd
libcap.so.1: cannot open shared object file: No such file or directory

Проблема в отсутствии libcap.so.1 в репозиториях Ubuntu. Но она есть в параллельной вселенной в .rpm Так поставим же ее:

sudo apt-get install alien
wget ftp://rpmfind.net/linux/opensuse/distribution/13.2/repo/oss/suse/x86_64/libcap1-32bit-1.10-60.2.1.x86_64.rpm
sudo alien -i ./libcap1-32bit-1.10-60.2.1.x86_64.rpm

После этих манипуляций ctxusb ставится и запускается.

citrix_course_cns-207-3i

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Курс Citrix Course CNS-207-3I
Информация о курсе
Сам курс
Лабораторные работы
Лицензия на Netscaler VPX версии Education
Exam Prepereation Guide
1y0-253_exam_dumps - Дампы экзамена 1y0-253
sergey _@_ bacherikov_ .com

citrix_licensinsing_server_citrix.exe_high_cpu_load

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Проблема

На Windows Server 2008 R2 установлен Citrix Licensing Server версии 15.5.0.25000, который идет в комплекте с Citrix XenDesktop 7.15 LTSR CU3 (7.15.3000).
Процесс CITRIX.exe на 100% занимает одно ядро CPU.

В логах ничего подозрительного нет, за исключением странных времен событий.

Решение

Причина оказалась в тайм-зоне, установленной на сервере.
Все остальные серверы окружения (контроллер домена ActiveDirectory, Citrix Desktop Delivery Controller и прочие) настроены на таймзону UTC+3:00 Moscow, а Citrix Licensing Server был настроен на UTC-8:00 Pacific Time. В результате, в логах можно было встретить события, которые для данного сервера были бы в будущем.
После установки корректной таймзоны и перезагрузки сервера все пришло в норму.
Следите за таймзонами!

citrix_storefront_our_logon_has_expired_please_log_on_again_to_continue

anonymous@undisclosed.example.com (Anonymous) — Mon, 13 May 2019 10:00:51 +0000

Конфигурация

Ферма Citrix Xendesktop 7.13
Storefront -
Netscaler Gateway -

Проблема

В моей инсталляции мониторинг состояния фермы осуществляется с помощью скрипта, который периодически (раз в пол часа) логинится на Storefront и запускает все доступные тестовой учетке приложения.
Иногда (не всегда) пользователь нормально логинится на StoreFront (через Netscaler Gateway), видит список ресурсов, но после клика по иконке ресурса видит сообщение:

Your logon has expired. Please log on again to continue.
The Server hosting "Desktop" is either not accepting Logons, is down, or there is a load issue. Check the Event Log, "Citrix Delivery Services", on the Storefront server for more information.

В логах на Storefront в момент возникновения такой ситуации ошибки с Event ID 5074:

A worker process with process id of '2880' serving application pool 'Citrix Configuration Api' has requested a recycle because the worker process reached its allowed processing time limit.
A worker process with process id of '1972' serving application pool 'Citrix Delivery Services Resources' has requested a recycle because the worker process reached its allowed processing time limit.
A worker process with process id of '7536' serving application pool 'Citrix Delivery Services Authentication' has requested a recycle because the worker process reached its allowed processing time limit.
A worker process with process id of '10112' serving application pool 'Citrix Receiver for Web' has requested a recycle because the worker process reached its allowed processing time limit.

В дальнейшем всё работает нормально. Пользователь нормально запускает опубликованные приложения.

Решение

Очевидно, что нужно как-то изменить настройки Application Pool Recycling. Внятного гайда от Citrix на эту тему я не нашел.
Существуют рекомендации совсем отключить Application Pool Recycling, однако это кажется немного опасным.
Я попробую четко указать время, когда следует перезапускать application pool, в котором работают сервисы Citrix.
В итоге - на серверах Storefront для всех Application Pools, названия которых начинаются с Citrix и для DefaultAppPool в Advanced Settings в разделе Recycling я выставил

Regular Time Interval (minutes) = 0

вместо дефолтного 1740, а также добавил значение

Specific Times = 00:55:00

citrix_usb_redirection_troubleshooting

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Проблемы с пробросом устройств в Citrix Receiver 13.3 под Ubuntu 16.04

Проброс устройств подключеных к системе в момент создания сессии

Чтобы уже подключенные к системе устройства пробрасывались в сессию при открытии сессии нужно в /opt/Citrix/ICAClient/config/module.ini в секцию [WFClient] добавить строку

DesktopApplianceMode=True

Кроме того, для того чтобы web-камера пробрасывалась через виртуальные каналы (не Generic USB) в /opt/Citrix/ICAClient/config/module.ini должно быть выставлено:

Multimedia=On

Не работает проброс Generic USB

Если девайсы не пробрасываются совсем, а в /var/log/syslog при подключении появляются сообщения типа:

 wfica: ctxusb: No such process

Значит не хватает прав и нужно запустить подключение через sudo. Например - просто запустить firefox для доступа к web-интерфейсу так:

sudo firefox

Либо скачивать launch.ica и подсовывать его wfica:

sudo /opt/Citrix/ICAClient/wfica ~/Downloads/launch.ica

Не пробрасывается Web-камера в Xendesktop 7.6 на Windows 2012

https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-6/xad-whats-new/xad-xaxd76-knownissues.html
Этот баг описан:

HDX RealTime Webcams are not supported for these applications:

    Citrix GoToMeeting when hosted on Server OS Machines with Windows 2012 operating systems. [#346430]
    GoToMeeting (on any platform) if the webcam is attached after a meeting has started. [#346140]
    Microsoft Lync 2013 and Adobe Connect with VDAs on Windows 8, Windows 8.1, and Windows 2012 operating systems. [#340784, 348506, 459732]
    Microsoft Office Communications Server (OCS) video calls if the Webcam is attached after the call is in progress. [#370236]
    Microsoft Silverlight. This is an intermittent issue. As a workaround, on the user device, enable the legacy codec by adding a DWORD registry key value name EnableDeepcompress_Client at HKEY_CURRENT_USER\Software\Citrix\HdxRealTime and setting it to 0. [#379779]
    64-bit video conferencing applications. Video compression for 64-bit applications is not supported. [#366515]

По идее, web-камера должна пробрасываться через виртуальные каналы (не Generic USB), при условии, что в /opt/Citrix/ICAClient/config/module.ini выставлено:

Multimedia=On

Однако, оказалось, что в Windows Server 2012 и Windows 8 это не работает и пробросить камеру можно только Generic USB. При этом, в режиме Generic USB при разрешении 640×480 и 30 кадрах в секунду клиент генерирует трафик в сторону сервера со скоростью 80 Мбит в секунду.

https://www.citrix.com/content/dam/citrix/en_us/documents/downloads/citrix-receiver/citrix-receiver-for-linux-oem-reference-guide-version-133.pdf https://www.citrix.com/content/dam/citrix/en_us/documents/downloads/citrix-receiver/Linux/Citrix_Receiver_for_Linux_OEM_Reference_Guide_13_4.pdf

После установки HDX Real Time Optimization Pack for Linux в каталоге $ICAROOT появляется плагин HDXRTME.so, который и должен пробрасывать камеру, однако при настройках по-умолчанию он этого не делает. Более того. В версии Citrix Receiver 13.3 этот плагин даже не подгружется (судя по strace). В версии Citrix Receiver 13.4 он загружается, однако камера по прежнему не пробрасывается.

В документации Citrix написано как отлаживать этот процесс. нужно заменить файл $/ICAROOT/util/gst_read на скрипт, который будет запускать этот файл с ключом -d. Длеаем так:

cd /opt/Citrix/ICAClient/util/
sudo mv gst_read gst_read.bin
sudo nano ./gst_read

Вставляем туда вот что:

#!/bin/bash
/opt/Citrix/ICAClient/util/gst_read.bin -d $@ 2>&1 >/tmp/gst_read.log

И делаем его исполняемым.

sudo chmod a+x ./gst_read

В результате логи будут падать в файл /tmp/gst_read.log Кроме того, можно просто попытаться запустить gst_read и посмотреть что он скажет:

/opt/Citrix/ICAClient/util/gst_read.bin -b 20

По идее в результате gst_read должен считать 20 кадров в буфер и показать. У меня сразу возникла ошибка:

/opt/Citrix/ICAClient/util$ ./gst_read.bin -b 20
Failed to create element of type 'v4l2src'

В логах примерно такое:

Enable H264 = 0
debug = 1
num_buffers = 20
height = 288
width = 352
device = /dev/video0
Failed to create element of type 'v4l2src'

Причина, судя по всему, в том, что в комплекте с Ubuntu 16.04 идет gstreamer 1.0, а gst_read пытается использовать gstreamer0.10. Устанавливаем его:

sudo apt-get install gstreamer0.10-alsa gstreamer0.10-plugins-base gstreamer0.10-plugins-good gstreamer0.10-pulseaudio gstreamer0.10-tools gstreamer0.10-x libgstreamer-plugins-base0.10-0 libgstreamer0.10-0 libx264-148 x264

После этого при запуске:

/opt/Citrix/ICAClient/util/gst_read.bin -d $@ 2>&1 >/tmp/gst_read.log

Открывается окошко и показывает картинку с камеры.

По-умолчанию, конвейер для Citrix Receiver 13.3 с кодеком theora в gstreamer такой:

gst-launch-0.10 v4l2src ! ffmpegcolorspace ! videoscale ! capsfilter ! theoraenc ! appsink

ddc_certs_renew

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Обновление сертификатов на Desktop delivery controller (DDC) 7.x.
https://support.citrix.com/article/CTX227572
https://www.torivar.com/2016/03/16/replace-ssl-certificates-on-citrix-storefront-and-delivery-controller/

netsh http show ssl
netsh http delete sslcert ipport=0.0.0.0:443
netsh http add sslcert ipport=0.0.0.0:443 certhash=bc3f4796d6ef09608119a4e9323e2534f45ef555 appid={CE24291B-1344-DC94-DB16-51875A6501C3}

Open the registry and navigate to HKEY_CLASSES_ROOT\Installer\Products\
Then search for the next “Broker Service” entry. The key GUID is the required “appid” value.
Note that you may have to add hyphens in the GUID. For instance, from this:
CE24291B1344DC94DB1651875A6501C3 to this:
CE24291B-1344-DC94-DB16-51875A6501C3

certhash=bc3f4796d6ef09608119a4e9323e2534f45ef555 (just a sample shown here).
This is the thumbprint of the new certificate.

get_latest_login_date

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Для того, чтобы получить список машин с именами пользователей и датой последнего логина с подключением к удаленному DDC:

asnp citrix.*
Get-BrokerDesktop -adminaddress "ddc.domain.local" | Select-Object AssociatedUserNames,DNSName,LastConnectionTime

remote_desktop_services_is_currently_busy

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Проблема

При попытке пользователя подключиться к уже существующей сессии появляется сообщение: “The task you are trying to do can't be completed because remote desktop services is currently busy. Please try again in a few minutes. Other users should still be able to log on.”

Подключиться не удается никому больше. При этом, те сессии на сервере, которые активны продолжают работать. Проблема актуальна для Windows Server 2008 R2 (SP1) и XenApp 6.0/6.5 - Xendesktop 7.x

Причина

Причина скорее всего в каком-то deadlock'е. У Microsoft есть патч на этот случай: https://support.microsoft.com/en-us/kb/2661332

Как оживить сервер без перезагрузки

Нужно подключиться в командную строку сервера и завершить сессию пользователя у которого произошел deadlock. Скорее всего это пользователь, который раньше всех заметил эту проблему. Я пользуюсь Ubuntu и в ней для подключения к Windows-машинам я использую winexe: http://sourceforge.net/projects/winexe/ В командной строке сервера нужно выполнить:

query session

Получить список сессий. Какая-то сессия будет в состоянии Conn. Имя сессии будет типа ica-tcp#1 Её надо завершить:

reset session <session-name>

Если команды quser, query session не отрабатывают, то нужно завершить все процессы пользователя. Это можно сделать командой taskkill:

taskkill /F /FI "USERNAME eq DOMAIN_NAME\User_Name" /IM *

Обычно эту команду нужно выполнить дважды, чтобы не осталось никаких процессов данного пользователя.

постоянные_частые_отключения_сессий_xendesktop_7.x

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

https://discussions.citrix.com/topic/362165-xendesktopapp-76-frequent-disconnects/

https://support.citrix.com/article/CTX200841?_ga=1.9767986.628758807.1424775546

сессия_xenapp_сразу_закрывается_а_в_журнале_event_id_9009

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Проблема

Сразу после подключения сессия Xenapp 6/6.5/7/7.6 отключается, а в журнале сервера фиксируется: Error 9009: The Desktop Window Manager has exited with code (0x40010004)

Решение

http://support.citrix.com/article/CTX127883
Просто citrixreciever не успевает подключиться.
Для решения нужно добавить в реестре в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\Wfshell\TWI добавить параметр LogoffCheckerStartupDelayInSeconds типа REG_DWORD со значением 10.

После добавления параметра перезагружать сервер не нужно. Настройки считываются при запуске каждой сессии.

скрещиваем-xendesktop-7-x-с-webinterface-5-4-и-securegateway-на-одном-сер� ...

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Версия Citrix WebInterface 5.4 стала последней и на смену ему в XenDesktop 7.x пришел Storefront.
Функциональность их аналогична, но для публикации приложений в Интернет теперь требуется NetScaler, а именно - его компонент AccessGateway.

К счастью, XenDesktop 7.x остался совместим с Citrix WebInterface 5.4.
Для того, чтобы запустить связку XenDesktop 7.x с WebInterface 5.4 и SecureGateway на одном сервере нужно:
1. При установке XenDesktop 7.x не устанавливать Storefront или, если он уже установлен, удалить его.
2. В реестре запретить использование сервисом CitrixBrokerService порта 443, который понадобится для работы Secure Gateway. Для этого в реестре сервера в ветке HKLM\Software\Citrix\DesktopServer\ нужно добавить параметр типа REG-DWORD - XmlServicesEnableSsl и дать ему значение 0, а затем перезагрузить сервер. Подробности тут: http://support.citrix.com/proddocs/topic/xendesktop-7/cds-mng-cntrlr-ssl.html
3. Установить на сервер Citrix WebInterface 5.4 и SecureGateway.
4. Создать для сервера сертификат SSL и установить его.
5. Настроить Citrix WebInterface 5.4 и SecureGateway в режиме Gateway Direct.

терминальный_сервер_100_cpu_и_не_зайти_по_rpd

anonymous@undisclosed.example.com (Anonymous) — Mon, 11 Feb 2019 09:13:26 +0000

Проблема

Терминальный сервер Windows 2008 R2 в ферме XenDesktop 7.6 перестал пускать пользователей. В Desktop Director видно загрузку 100% CPU. При том, что в сервере 32 физических ядра (два проца AMD Opteron™ 6376).

При попытках зайти по RDP ничего не происходит. Сервер просто не отвечает. При этом, удается подключиться к нему с помощью psexec.

Citrix Insight Sevices

Citrix Insight Sevices предлагает установить ICATS760WX64032. Утверждает, что патч лечит проблему, когда вход замирает на Welcome Screen и по RDP также подключиться нельзя.

Диагностика

Удается получить список процессов. С помощью команды:

tasklist /v /FI "CPUTIME gt 00:25:00"

Удалось получить список особо прожорливых процессов. Оказалось, что самые жрущие - WmiPrvSE.exe.

Осталось только убить их.

taskkill /F /IM WmiPrvSE.exe /T

Сервак тут же ожил. Вот тут пример расследования причин такого поведенияЖ http://www.admblog.ru/wmiprvse-%D0%B3%D1%80%D1%83%D0%B7%D0%B8%D1%82-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%83/

wiki.autosys.tk

подготовка-к-экзамену-1y0-200-managing-citrix-xendesktop-7-solutions

Раздел 1: Managing Citrix XenDesktop 7 Solutions

1.1 - Работа с образами серверных и клиентских ОС (в том числе каталогами машин и группами доставки).

Обновление существующего каталога машин до новой версии XenDesktop 7.

citrix_vdi_handbook_2017_v.2.01

Citrix Consulting Methodology

Оценка (Assess)

1. Определение круга решаемых с помощью VDI задач и требований менеджмента к решению VDI.

2. Определение групп пользователей и их потребностей.

Уровень персонализации рабочего места.

Уровень безопасности.

Уровень мобильности

Критичность неработоспособности рабочего места

Рабочая нагрузка

3. Модели VDI

Рекомендации Citrix по выбору модели VDI

4. Приложения

Инвентаризация приложений

Категоризация приложений

Роли в команде внедрения

Разработка решения (Design)

Уровень 0: Концепция архитектуры

Размещение вычислительных ресурсов

Выбор топологии

Выбор стратегии управления мастер-образами

Уровень 1: Пользователи

Выбор пользовательского устройства

Владелец конечного устройства

Жизненный цикл конечных устройств

Управление мобильными пользовательскими устройствами

Выбор формфактора конечных устройств

Выбор Citrix Receiver

Распространение Citrix Receiver

Выбор механизма начальной конфигурации Citrix Receiver

Обновления Citrix Receiver

Уровень 2: Доступ к ресурсам

Аутентификация

Выбор провайдера аутентификации

Выбор точки аутентификации

Выбор способа (политики) аутентификации

Citrix StoreFront

Обеспечение высокой доступности Storefront

Обеспечение высокой доступности контроллеров DDC

Точки покдлючения (beacons)

Представление списка ресурсов

Группировка ресурсов - Aggregation Groups

Масштабируемость

NetScaler Gateway

Топология

Высокая доступность

Платформа NetScaler Gateway

Политики пользовательских устройств (Pre-Authentication Policy и Smart Access)

Сеансовые политики (Session Policy)

Профиль сеанса

Распределение подключений между датацентрами

Статические методы

Динамические методы

Взаимодействие между сайтами

Оптимизация маршрутизации сессий HDX

Виртуальные WAN-каналы

Уровень 3. Ресурсы

Впечатления пользователя от работы (User Experience)

Выбор протокола передачи изображения (Display Protocol)

Выбор сетевого транспортного протокола

Выбор оптимизации входа (Logon Optimization)

Средства самообслуживания пользователей

Пользовательские профили

Тип профиля

Перенаправление папок

Исключение папок из профиля

Кеширование профиля

Размещение профилей (Profile Path)

Profile Streaming

Active Write Back

подготовка-к-экзамену-xendesktop

Разделы курса обучения

Разделы экзамена

Терминология XenDesktop 5.x

Ключевые отличия от предыдущих выпусков

Ключевые различия XenApp и XenDesktop