Основана на гайде 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 закончена.

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 могут обрабатывать сессии пользователей. Режим работы сервера определяет, будет ли сервер только обрабатывать сессии пользователей (режим 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 список зон можно просматривать и при необходимости создавать новые зоны. В каждой зоне должен быть хотя бы один сервер. Пустые зоны удаляются автоматически.
При создании зоны или при присоединении к зоне нового сервера происходят выборы сборщика данных для данной зоны. Если текущий сборщик данных станет недоступным, то производятся новые выборы.

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.

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 подходит для маленьких, большинства средних инсталляций, физически размещенных в одном месте

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

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

По умолчанию 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, которая будет пытаться переподключить пользователя к отключенной сессии.

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.

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 и перезагрузить сервер.

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 может быть установлен на любом сервере фермы.
Для установки - подключитесь к серверу фермы с учетными данными администратора. Из папки дистрибутива запустите 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.

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. Зависимостей нет.

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

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.

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 через файервол.

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

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

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

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

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

В случае использования одной секции 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 были зашифрованы.

На рисунке приведена схема сети предприятия, отделенная от интернета одной секцией 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 имеет свой сертификат.

В варианте с одной секцией 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.

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

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

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. Тут задаются параметры работы 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 работает на web-сервере, который обеспечивает работу дополнительных функций. Службу Single Sign-on следует устанавливать если планируется использовать одну из этих функций:

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

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

Для работы 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 позволяет удобно настраивать политики использования 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 позволяет использовать существующую инфраструктуру Active Directory, но не вносить изменения в схему AD.

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.

Если на предприятии используется несколько доменов, то администратор может создать несколько 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) позволяют плагину 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).

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

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

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

В зависимости от требований и окружения, 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.

Сервер:
- Двухъядерный 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 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 не запишется.

Для установки используйте 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.
Следуйте указаниям мастера для завершения установки.

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 серверов на одной площадке рекомендуется настраивать одну зону и один выделенный сборщик (хотя можно иметь и резервные).

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 зон.

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

7. В командной строке перейдите в папку:
C:\Program Files\Citrix\Licensing\LS на системе 32-bit
C:\Program Files (x86)\Citrix\Licensing\LS на системе 64-bit

И выполните команду: lmreread -c @localhost

http://support.citrix.com/proddocs/topic/xenapp65-admin/hd-flash-wrapper-ad.html

HDX MediaStream Flash Redirection позволяет обрабатывать контент формата Adobe Flash в браузере клиентского устройства (как windows, так и linux), а не в экземпляре браузера на сервере. Передача контента возможна для широкого круга приложений, в том числе анимации и видео. Перенаправление ресурсоемкого контента для исполнения на клиентском устройстве позволяет снизить нагрузку на сервер и таким образом улучшить масштабируемость XenApp, и повысить качество выводимой пользователю картинки.

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 и на клиентском устройстве и на сервере может быть заблокирован.

Нижеприведенные сведения актуальны на момент публикации, а дополнительную информацию можно найти по адресу: 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.

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

Параметр политики 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-элементы контента перенаправлялись для обработки на пользовательское устройство. Обычно, небольшие ролики flash - это реклама. Функция Flash intelligent fallback выявляет эти элементы и обрабатывает (рендерит) их на сервере. Применение этого параметра политики Citrix User Policy не вызывает неполадок при загрузке страницы или работы Flash-приложений.

Эта настройка имеет два положения - Enabled или Disabled. По умолчанию она включена - Enabled.

Настройка политики Flash latency threshold применима к Legacy mode, то есть доступна только при включенной политике Flash backwards compatibility.

В режиме Legacy, Flash Redirection измеряет время прохождения данных между сервером и пользовательским устройством. Эти данные учитывают как задержку сети, так и другие задержки данных. Если задержка находится в пределах допустимого заданного диапазона, то для рендеринга контента используется Flash Redirection и ендеринг происходит на пользовательском устройстве. Если задержка выше, заданной, то ренедеринг происходит на серверах.
По умолчанию порог задержки имеет значение 30 миллисекунд. Увеличение этого порога может приводить к ухудшению картинки у пользователя. Не рекомендуется увеличивать значение этого порога.

Параметр Flash server-side content fetching URL list - это список сайтов, с которых разрешено скачивать контент Flash для последующей передачи на пользовательское устройство. Эта функция применима, в случаях, когда у пользовательского устройства отсутствует прямой доступ к источнику flash-контента (отсутствует доступ в интернет, либо контент располагается на внутреннем сайте компании). Хотя в этот список могут входить хоть все сайты интернета, он предназначен для сайтов корпоративной сети и внутренних Flash-приложений.

Эта настройка работает, если для клиента включена опция 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 в список.

Второе поколение 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 второго поколения, настройка недоступна.

По-умолчанию, режим совместимости (Legacy mode Flash Redirection ) включен на сервере. Изменить эту настройку можно с настройки помощью политики Citrix User Policy - Flash acceleration, в категории Flash Redirection .

Сконфигурируйте параметр Flash acceleration , включив или отключив его. По умолчанию - он включен.

Если параметр включен - весь контент Flash, не заблокированный в Flash URL compatibility list , рендерится на пользовательском устройстве, в режиме совместимости (Legacy mode). Если отключен - весь контент 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.

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

Настройте параметр 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: Пользователь должен завершить свою сессию (выйти) и залогиниться снова.

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 для отдельных полей ввода в приложении.

Для настройки функций 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, для настройки параметров этого приложения можно использовать мастер Add New Application , входящий в состав SpeedScreen Latency Reduction Manager.

Прежде чем вы сможете настраивать параметры приложения в Speedscreen Latency Reduction Manager, его нужно туда добавить.

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% от размера диска (что больше). Удаление файлов начинается с наименее редко используемых.

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 поставояется в виде виртуального приложения (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, или другой утилиты.

Убедитесь, что на диске есть как минимум 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 под именем с административной учеткой.

Опционально, Кликните 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, он автоматически выберет запланированную доставку и установит плагины.

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-printing-proximity.html

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

Если в организации есть такие задачи, то полезными будут эти функции:
SmoothRoaming
Proximity Printing

Также эта функция известна под именем Workspace control. Эта функция позволяет пользователям отсоединяться от сессии, и переподключаться с другого устройства к той же сессии. При переподключении сессии, принтеры, прописанные на первом устройстве, будут заменены на принтеры, прописанные на втором устройстве. В результате, пользователь всегда имеет нужные принтеры в сессии.
SmoothRoaming работает с локальными принтерами, подключенными к пользовательскому устройству.

Эта функция дает возможность управлять сетевыми принтерами также как и в случае 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.
При перемещении пользователя на новое клиентское устройство, будут применены соотвествующие политики (мапинг дисков, принтеров). То есть политики и мапинг применяются в соответствии с тем, на каком устройстве пользователь залогинен в данный момент.

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) - это режим, в котором в одном соединении работают несколько приложений. Разделение сессии воникает, пример, когда пользователь имеет уже открытую сессию и запускет еще одно приложение на том же сервере. В результате - два приложения работают в одной сессии. Для того чтобы происходило разделение сессии необходимо, чтобы оба прилодения были опубликованы на одном сервере. Поу-умолчанию, разделение сессии включается при конфигурировании приложения для запуска в бесшовном режиме. Если пользователь запускает несколько приложений в режиме разделения сессии, все приложения используют единственное подключение к серверу.
Если требуется разделять сессии, убедитесь, что все приложения опубликованы с одинаковыми настройками.

Разделение сессий всегда имеет приоритет над балансировкой нагрузки. То есть, если пользователь запускает приложение в режиме разделения сесии на сервере, где уже работает его приложение, но сервер уже испытывает нехватку ресурсов, 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 подключения никак не ограничивает.

http://support.citrix.com/proddocs/topic/web-interface-impington/wi-configure-workspace-control-gransden.html

Функции 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 не работает на сайтах, доставляющих 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.

Этот набор функций позволяет убрать задержку при запусек сессий. С помощью настраиваемой политики Session Pre-launch , сессия стартует автоматически при входе пользователя на ферму XenApp. При помощи политики Session Linger , можно задать промежуток времени, когда сессия пользователя остается активной на сервере, после закрытия приложения пользователем.
Fast Reconnect, встроен в XenApp и не требует конфигурирования. Эта функция позволяет уменьшить задержку при переподключении пользователя к существующим сессиям.

Сессия пользователя завершается при завершении запущенных процессов и закрытии окон. 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, то сессия анонимного пользователя будет уничтожена по истечении любого из этих интервалов.

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-policies-creating-wrapper-v2.html

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

Управлять политиками можно как через консоль управления групповыми политиками Windows (Group Policy Management Console), так и с помощью AppCenter (бывшая Delivery Services Console). Использование той или иной консоли определяется наличием или отсутсвием инфраструктуры Active Directory, а
также наличием разрешений на изменение объектов групповой политики.

Если в сети настроена инфраструктура Active Directory и вы имеете права на изменение объектов групповой политики, то для создания политик следует использовать редактор групповой политики.

Если в сети используются службы каталогов отличные от 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 - обои рабочего стола, анимация меню и ид окон при перетаскивании.

Политики Citrix способны работать в окружении Active Directory на базе доменов Windows 2000 и более новых. Для того чтобы политики Citrix были включены в отчеты о Результирующей политике (Resultant Set of Policy), необходимо, чтобы в лесу домена был как минимум один контроллер домена под управлением Windows Server 2003.

Процесс работы с политиками Citrix включает следующие этапы:
- Создание политики
- Настройка параметров политики
- Применение политики к подключениям, путем добавления фильтров
- Приоритизация политики
- Проверка эффективности политики, путем запуска мастера моделирования политики - Citrix Group Policy Modeling

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 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 зпдпнный по-умолчанию, подсоединяется к порту и отсылает тестовый набор данных и слушает ответ. Тест считается пройденным при получении корректного ответа.

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

Служба Citrix Print Manager service (cpsvc.exe) или Microsoft Print Spooler service (spoolsv.exe) зависает или падает.
При этом автоматически не создаются принтеры, в сессии принтер по-умолчанию не выставляется правильно, а задания печати не становятся в очередь и т.д.

- Используйте встроенные драйвера Windows или драйверы Citrix Universal Print Driver (UPD).
- Используйте переназначение драйверов (driver mapping)
- Избегайте обновления драйверов. Всегда удаляйте старый драйвер, перезагружайтесь и только потом ставьте новый.
- Неиспользуемые драйверы следует удалять или ограничивать их использование.
- Попытайтесь избежать использования драйверов уровня ядра (kernel-mode drivers).
- Дайте пользователям права на запись в папку <root directory>\system\spool для работы драйверов, не на 100 процентов совместимых с сервером термналов.
- Избегайте использования драйверов PCL6. Вместо них старайтесь использовать драйверы PCL5 или PS.
- Никогда не устанавливайте непротестированные драйверы на продакшн ферму.
- Не лишних драйверов на сервер - это замедляет процесс входа пользователя.
- При возможности используйте переназначение (mappings).
- Перезапуск службы печати и очистка временных директорий устраняет симптомы, но не решает проблемы.

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

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 . Это не опубликованное приложение.

- Опубликуйте на ферме 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). Используйте эту политику для разрешения или запрещения доставку потокового аудио или видео пользователям. По-умолчанию - включено.

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

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.

Пользователь или группа (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.

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 и иметь достаточные ресурсы.

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

Также существует двойной режим доставки - 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).

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

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 - это окружение системы, на которой создан профиль приложения. При этом, можно создать несколько окружений, для работы на специфичных системах. Например - некоторые коммерческие приложения способны работать на многих операционных системах и языковых окружениях, а другие - только на определенных ОС и языках.

В зависимости от окружения ваших пользователей, есть возможность добавлять в профиль приложения необходимые сторонние компоненты, такие как 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/.

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) больше никем не используются.

Новейшие операционные системы, которые будут издаваться в будущем - не поддерживаются. То есть приложение не сможет запуститься, если будет запущено в неподдерживаемой ОС.

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.

http://support.citrix.com/proddocs/topic/xenapp65-publishing/ps-pub-content-redirect-server-task-v2.html
Перенаправление контента с сервера к клиенту используется для того, чтобы открывать некоторые типы ссылок на клиенте, сохраняя ресурсы сервера.
Например на севрере может быть опубликован почтовый клиент и пользователи могут часто открывать Web-страницы и мультимедийные URL, ссылки на которые приходят по почте. В этом случае, включение перенаправления контента (content redirection) от сервера к клиенту позволит воспроизводить мультимедию и открывать страницы средствами клиентских устройств.

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 либо для фермы в целом, либо для сервера, либо для группы пользователей.

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 можно назначить специальные права.

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

Для включения журналирования:
- СОздайте базу данных журнала.
- Создайте учетные данные для доступа к базе журнала.
- Сконфигурируйте подключение к базе данных.
- Задайте параметры журналирования
- Делегируйте административные права

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

Для создания отчета используется команда 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

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

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.

Команда 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

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) профили.

Профили, используемые в 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

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.

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.
- В диалоговом окне выберите необходимый оценщик нагрузки.

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-printing-network-configuring.html
В случае отсутствия драйвера принтера на сервере его не удастся автоматически прописать в сессии пользователя.
Добавить драйвер принтера в Windows можно так:
- Установить принтер вручную, с помощью мастера Добавление принтера, либо обнаружив принтер на соответствующем сервере в Проводнике, дважды кликнув по нему. Драйвер принтера установится в локальное хранилище драйверов Windows.

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

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-console-policies-universal-printing.html

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

Этот параметр определяет метод обработки файла EMF spool на пользовательском устройстве Windows. По-умолчанию, записи EMF направляются сразу на принтер.
Этот параметр имеет следующие варинты значений:

Reprocess EMFs for printer - предписывает принудительно обрабатывать файл EMF и посылать его на принтер через подсистему GDI пользовательского устройства. Этот параметр можно использовать с драйверами, которые требуют постобработки EMF, но могут не быть автоматичсеки выбраны в сессии.
Spool directly to printer - при использовании Citrix Universal Printer driver, обеспечивает помещение в очередь и перердачу данных EMF на пользовательское устройство для последующей обработки. Обычно файлы EMF направляются напрямую в очередь печати клиентского устройства. Для устройств поддерживающих формат EMF этот метод обеспечивает наибольшее быстродействие.

Этот параметр задает максимальное качество и минимальный уровень сжатия для изображений, печатаемых через 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 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 - разрешает или запрещает пользователям изменять настройки уровня оптимизации при печати в сессии. По-умолчанию - пользователям не разрешается менять настройки.

Этот параметр политики разрешает или запрещает использование функции предпросмотра для автоматически создаваемых 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 - Использование универсального драйвера печати.

Это параметр политики задает максимальное качество печати в точках на дюйм (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.

Этот параметр включает или отключает автоматическую установку драйверов принтеров, включенных в состав Windows или драйверов, добавленных в состав Windows с помощью утилиты pnputil.exe /a. По-умолчанию эти драйверы устанавливаются по мере необходимости.

Этот параметр задает порядок, в котором используются универсальные драйверы (universal printer drivers) начиная с первого в списке. По-умолчанию порядок такой:
EMF
XPS
PCL5c
PCL4
PS
Вы можете добавлять, удалять и изменять драйверы и порядок их использования.

Это параметр определяет когда следует использовать 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 - использование универсального драйвера в случае его наличия, в противном случае - использование универсального.

Добавление сетевых принтеров при конфигурировании печати сессии.
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-адресам клиентов.

http://support.citrix.com/proddocs/topic/xenapp65-admin/ps-printing-network-configuring.html
В случае отсутствия драйвера принтера на сервере его не удастся автоматически прописать в сессии пользователя.
Добавить драйвер принтера в Windows можно так:
- Установить принтер вручную, с помощью мастера Добавление принтера, либо обнаружив принтер на соответствующем сервере в Проводнике, дважды кликнув по нему. Драйвер принтера установится в локальное хранилище драйверов Windows.

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

Перенаправление контента от 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.

По-умолчанию, таймаут ожидания 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 количество попыток.

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

- 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 из списка, исключая отказавший сервер из работы на заданный интервал времени.

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 задайте время, на которое отказавший сервер будет исключен из списка опрашиваемых.

http://support.citrix.com/proddocs/topic/web-interface-impington/wi-enable-explicit-authentication-gransden.html
Если включена явная (explicit) аутентификация, то для входа на ферму пользователи должны иметь учетные записи и предоставлять учетные данные при входе.
Настройки параметров явной аутентификации производятся в консоли Citrix Web Interface Management. Например, можно указать - разрешено ли пользователям менять пароли в течение сессии.

Для включения явной (explicit) аутентификации:
- Запустите консоль Citrix Web Interface Management (Пуск > Все программы > Citrix > Management Consoles > Citrix Web Interface Management)
- В левой части окна консоли выберите тип сайта - XenApp Web Sites и выберите настраиваемый сайт.
- В панели справа кликните Authentication Methods и поставьте галочку в чекбоксе Explicit.
- Кликните Properties для того чтобы сконфигурировать дополнительные параметры явной аутентификации.

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 необходимо указать параметры хотя бы одной фермы, ресурсы которой будут опубликованы на сайте.
Эти параметры можно впоследствии обновить или изменить с помощью задачи 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.

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

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 задайте время, на которое отказавший сервер будет исключен из списка опрашиваемых.

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”).

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.

http://support.citrix.com/proddocs/topic/web-interface-impington/wi-before-creating-ad-fs-sites-gransden.html

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.

- Сквозная аутентификация (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 смарт-карты.

- Анонимная (Anonymous). Анонимные пользователи могут входить без указания учетных данных и использовать ресурсы, опубликованные для анонимных пользователей.

Если вы планируете включить сквозную аутентифиакцию (со смарт-картой или без) или просто аутентификацию смарт-картой, учитывайте следующее:
- Если пользователи логинятся на свои локальные компьютеры с помощью смарт-карт и вы хотите включить сквозную аутентификацию, то следует выбирать опцию Kerberos authentication
- Если пользователи логинятся на свои компьютеры с помощью явной (explicit) аутентификации, то для этих пользователей не следует включать сквозную (в том числе и со смарт-картой) аутентификацию для доступа к Web-интерфейсу.

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

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.
- Укажите должен ли список доменов быть заполнен по-умолчанию, либо пользователи должны сами вводить имя домена каждый раз.

- Добавьте в список домены, которые будут появляться в диалоге входа.
9. В поле UPN Restriction сконфигурируйте:
- Все ли доменные суффиксы будут приниматься.
- Укажате желаемые суффиксы UPN.

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

Служба Independent Management Architecture (IMA) не запускается.

Причины, по которым IMA не стартует могут быть связаны с:

Время запуска IMA Service
Отсуствует временная директория Temp
Проблемы со службой диспетчера печати Print spooler service
Конфигурация ODBC
Roaming Profile
Другой сервер в сети имеет такое же имя NetBIOS

Если Менеджер управления службами (Service Control Manager) сообщает что служба IMA Service не может быть запущена, но служба все-таки стартует, несмотря на это сообщение.
Менеджер управления службами имеет таймаут 6 минут. Служба IMA может запускаться дольше 6 минут, если нагрузка на сервер с базой данных превышает возможности производительности компьютера, обрабатывающего базу данных или если в сети очень высокая задержка. Если вы считаете, что служба IMA ависла в состоянии запуска (“starting”), то можно просто завершить процесс ImaSrv.exe в Диспетчере задач и снова запустить службу Citrix Independent Management Architecture.

Source: DSView
http://support.citrix.com/article/CTX106232