понедельник, 28 марта 2016 г.

Ошибка сертификата vCenter Server после обновления до Horizon View 7

После обновления VMware View Connection Server до версии 7.0 при использовании серверов vCenter Server версии 5.0, 5.1 или 5.5 они перестают быть доступны из интерфейса View Administrator, а на вкладке Dashboard при просмотре свойств vCenter может появиться следующая ошибка.

Нажатие на кнопку Verify не приводит ни к какому результату. При попытке изменить настройки существующего сервера vCenter или добавить новый vCenter из вкладки View Configuration появляется ошибка:
vmware horizon view possibly an invalid vcenter server certificate please verity the identity of the associated vcenter server

В файле debug-*.txt на сервере View Connection Server можно найти следующие сообщения:
Server chose TLSv1, but that protocol version is not enabled or not supported by the client.

Причина проблемы: В Horizon 7 по умочанию отключен протокол TLSv1, который используется в старых версиях VMware vCenter Server. Для решения проблемы следует обновить VMware vCenter Server, либо включить поддержку TLSv1 в Horizon. Для этого выполните следующие действия:
  1. Выполните вход на любой из серверов View Connection Server.
  2. Запустите ADSI Edit.
  3. В поле Distinguished Name or Naming Context укажите "DC=vdi, DC=vmware, DC=int".
  4. В поле Select or type a domain or server укажите "localhost:389".
  5. Раскройте дерево ADSI Edit: "OU=Global, OU=Properties, DC=vdi, DC=vmware, DC=int".
  6. Откройте свойства объекта CN=common.
  7. Найдите и отредактируйте атрибут pae-ClientSSLSecureProtocols, указав в качестве значения: "\LIST:TLSv1.2,TLSv1.1,TLSv1" (не забудьте обратный слэш в начале строки).
  8. Нажмите OK для применения параметров.
  9. Перезапустите службу VMware Horizon View Connection Server на всех серверах View Connection Server.
После выполнения настроек, серверы View Connection Server смогут использовать протокол TLSv1 для подключения к vCenter Server.

понедельник, 21 марта 2016 г.

Teradici PCoIP Workstation Access

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

Помимо разработки и производства процессоров для обработки PCoIP, а также лицензирования протокола для сторонних компаний (PCoIP используется в качестве одного из протоколов доступа в VMware Horizon View, а также Amazon WorkSpaces), Teradici также выпускает ПО для работы с PCoIP: Teradici PCoIP Workstation Access.

PCoIP Workstation Access устанавливается на рабочую станцию и позволяет подключаться к ней по протоколу PCoIP с нулевого клиента или с помощью программного клиента Teradici PCoIP Client. При этом отсутствует необходимость установки в компьютер адаптера PCoIP Remote Workstation Card, обработка протокола PCoIP осуществляется центральным процессором. Подключение клиентов к рабочим станциям с ПО Workstation Access может осуществляться напрямую, в этом случае не требуется разворачивать никаких дополнительных серверных компонентов, вроде брокеров подкючений, шлюзов и т.д. (схожим образом работает агент VMware View Direct Connection Agent). Однако при желании можно использовать Workstation Access совместно со сторонними брокерами подключений, заявлена поддержка Leostream Connection Broker, а также Teradici PCoIP Connection Manager for Amazon WorkSpaces.

Аппаратные решения в виде адаптеров Teradici PCoIP Remote Workstation Card предназначены для обеспечения максимального уровня производительности при работе пользователей с "тяжелыми" приложениями, тогда как ПО PCoIP Workstation Access представляет собой более экономичное и универсальное решение по удаленному доступу, рассчитанное на типовых пользователей рабочих станций.

ПО Workstation Access распространяется по подписке, ориентировочная цена - от 132$ в год, включая поддержку. Существуют две модели лицензирования - по хостам и по пользователям. На сайте доступна для загрузки триальная лицензия на 30 дней (хотя мне после запроса прислали лицензию на 50 с лишним дней).

В качестве ОС для установки Workstation Access поддерживаются как клиентские ОС: Windows 7, 8, 8.1, так и серверные: Windows Server 2008 R2.
Существует два варианта установки Workstation Access:
  • Deskside - для установки на рабочие станции с подключенными мониторами. В данном варианте пользователя может работать с рабочей станцией как локально, используя монитор, клавиатуру, мышь, так и удаленно при подключении по протоколу PCoIP.
  • Cloud or Data Center - для установки на рабочие станции или виртуальные машины без подключенных мониторов. В данном варианте предполагается, что пользователь подключается к рабочей станции только удаленно по протоколу PCoIP.
ПО Workstation Access предоставляет следующие функциональные возможности:
  • Подключение при помощи нулевых клиентов PCoIP (TERA2 клиенты с версией прошивки 4.8 или выше).
  • Подключение при помощи программных клиентов для Windows, MAC OS, Chrome OS, iOS или Android.
  • Поддержка многомониторных конфигураций. До двух мониторов с разрешением 2560 x 1600 или до 4-х мониторов с разрешением 1920 x 1200.
  • Поддержка аппаратного ускорения графики с использованием GPU (NVIDIA GRID, NVIDIA Quadro и другие). Для ВМ, работающих на VMware vSphere, поддерживается проброс графических адаптеров в режиме vDGA или vGPU.
  • Поддержка проброса USB устройств.
  • Поддержка проброса принтеров.
  • Поддержка передачи звука в обоих направлениях (воспроизведение и запись).
  • Передача буфера обмена между рабочим столом и клиентом в обоих направлениях, включая текст (rich text) и изображения.
  • Поддержка SSO - однократная аутентификация на клиенте PCoIP при подключении и автоматический вход в систему под данной учетной записью.
Установка PCoIP очень проста и не требует каких-либо специфических навыков. После установки агента Workstation Access на рабочем столе в области уведомления появится значок PCoIP Control Panel, из которого можно выполнять базовые настройки агента.

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

При подключении клиент должен пройти аутентификацию.

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

Для управления настройками PCoIP: включение/отключение некоторых функций, качества изображения, используемой полосы пропускания и т.д., применяются групповые политики Microsoft Windows. Файл шаблона располагается в каталоге установки, по умолчанию: "C:\Program Files (x86)\Teradici\PCoIP Agent\configuration". Для тех, кто работал с VMware Horizon View эти настройки могут показаться знакомыми.

Что касается скорости работы с удаленным рабочим столом, то разницы по сравнению с VMware Horizon View не видно. При наличии высокоскоростного, стабильного подключения протокол PCoIP обеспечивает стабильный показатель в 24-30 кадров в секунду. Но при воспроизведении видео с настройками по умолчанию PCoIP может быть весьма прожорлив, даже в разрешении 1280 x 1024 протокол отъедает 30-40 Мбит/с.

Подводя итоги, можно сказать, что ПО Teradici PCoIP Workstation Access является неплохой альтернативой классическим VDI решениям вроде VMware Horizon или Citrix XenDesktop для небольших инсталляций, где не требуется централизованное развертывание и управление виртуальными рабочими станциями, но где нужно обеспечить максимальный уровень производительности удаленного доступа, например, при работе с САПР или 3D редакторами.

воскресенье, 13 марта 2016 г.

Изменение лицензирования в VMware Virtual SAN 6.2

Начиная с версии 6.2 в VMware Virtual SAN в дополнение к трем существующим редакциям: Standard, Advanced и ROBO, появилась новая редакция Enterprise. Функциональные различия редакций представлены в таблице.

В связи с этим важно помнить следующие нюансы:

Функция Stretched Cluster, позволяющая развернуть распределенный кластер Virtual SAN между двумя площадками, переехала в редакцию Enterprise, что может огорчить тех, кто планировал для этих целей использовать Advanced.

Двухузловой кластер Virtual SAN (2-host Virtual SAN) для небольших филиалов с узлом-свидетелем в главном ЦОД не является Stretched Cluster и доступен во всех редакциях Virtual SAN (а не только в ROBO или Enterprise).

Не смотря на то, что в существующих инсталляциях возможно заменить лицензии Virtual SAN ROBO на Virtual SAN Standard, Advanced или Enterprise, например, если вы превысили ограничение в 25 ВМ или вам нужны дополнительные функции старших редакций, в прайс-листе нет позиций апгрейда, т.е. лицензии придется покупать с нуля.

Для VDI сред вместо лицензирования по процессорам можно приобрести конкуретные лицензии по пользователям: Virtual SAN Standard for Desktop, Virtual SAN Advanced for Desktop или Virtual SAN Enterprise for Desktop, функционал которых аналогичен соответствующим редакциям Virtual SAN, лицензируемым по процессорам.

В бандлах VMware Horizon Advanced и VMware Horizon Enterprise включены лицензии Virtual SAN Advanced for Desktop. Поэтому если вы планировали развертывание VDI на Stretched Cluster VSAN, то вам придется приобрести Virtual SAN Enterprise for Desktop. Пока не понятно, можно ли будет воспользоваться позицией апгрейда с Virtual SAN Advanced for Desktop на Enterprise для лицензий из бандла Horizon, или лицензии Virtual SAN Enterprise придется покупать с нуля.

Более подробно о лицензировании Virtual SAN можно прочитать в документе: http://www.vmware.com/files/pdf/products/vsan/vmware-vsan-62-licensing-guide.pdf

среда, 24 февраля 2016 г.

Raspberry Pi в качестве экономичной альтернативы тонким клиентам

Одной из существенных статей расходов при внедрении терминальных ферм или VDI инфраструктуры является покупка тонких клиентов - устройств, обеспечивающих подключение к удаленным рабочим столам. На рынке присутствует множество производителей тонких клиентов - это и широко известные компании: Dell (в свое время купивший крупнейшего производителя ТК Wyse), HP, NComputing, так и менее известные: Igel, Lenovo, Centerm, и даже местные российские производители: Тонк, Kraftway.

Стоимость тонкого клиента зависит от производителя, аппаратных характеристик, используемой ОС и поддерживаемого функционала, но даже самые экономичные решения начинаются, как правило, от 200$.

На фоне этого весьма интересной выглядит идея использовать дешевые компьютеры на базе процессоров ARM в качестве тонких клиентов. Так, например, несколько лет назад на рынке появились Computer Stick - крошечные компьютеры с ОС Andoid на борту, выполненные в форм-факторе USB flash-накопителей, снабженные HDMI портом, Wi-Fi адаптером, USB портом для подключения периферии и разъемом для Micro SD карт. В основном данные устройства использовались в качестве медиа плееров для того, чтобы сделать из обычных телевизоров т.н. Smart TV, хотя Dell даже выпустила устройство Wyse Cloud Connect.

Однако, не смотря на привлекательную цену (можно без проблем найти Compute Stick от какого-нибудь китайского производителя за 70$), ограничения со стороны ОС Android и программ-клиентов, отсутствие Ethernet разъема для подключения к проводной сети (хотя при желании можно использовать USB-Ethernet адаптеры), не привели к широкому распространению подобных устройств в качестве тонких клиентов.

Raspberry Pi

Появление одноплатных компьютеров Raspberry Pi, поддерживающих ОС Linux, имеющих весьма производительную аппаратную начинку при цене всего в 35$, возродило интерес к созданию дешевого ТК.

Благодаря своей компактности, производительности и невысокой цене RPi стал интересной основой для построения различных DIY (Do It Yourself) устройств: медиа центров, игровых приставок, устройств для умного дома и т.д.  Более того, некоторые производители бизнес-решений также заинтересовались в RPi, например, компания ThinPrint объявила о скором выходе принт-сервера ThinPrint Hub на базе RPi.

За несколько лет пребывания RPi на рынке вышло несколько поколений устройств. Последняя и наиболее продвинутая на сегодня версия Raspberry Pi 2 Model B имеет следующие характеристики:
  • Четырехъядерный процессор ARM Cortex-A7 с частотой 900 МГц (Broadcom BCM2836).
  • 1 ГБ оперативной памяти.
  • Четыре порта USB 2.0.
  • Один порт HDMI 1.3a.
  • Один Ethernet порт 10/100 Мбит/с.
  • Один 3.5 мм стерео аудио разъем, совмещенный с композитным видео разъемом.
  • Micro USB разъем для подключения питания.
  • Micro SD слот для установки карт памяти.
Если взглянуть на характеристики многих ТК начального уровня, например, Dell T10, то можно увидеть, что RPi крайне схож по параметрам, а в чем-то даже превосходит своих коллег.

При покупке RPi следует понимать, что за 35$ вы получите только саму плату-компьютер. Дополнительно вам придется раскошелиться на корпус, карту памяти, блок питания (рекомендуется использовать БП, выдающие 1.8А и выше), USB кабель к нему, мышь и клавиатуру.

Из дополнительных аксессуаров может потребоваться VESA крепление для установки на монитор и адаптеры для питания через PoE (Power over Ethernet).

Операционные системы для ТК на Raspberry Pi

Для RPi существует много официальных и неофициальных дистрибутивов ОС, которые так или иначе могут использоваться для создания ТК.

Первый вариант, который приходит на ум - использовать один из официальных дистрибутивов: Raspbian, основанный на Debian, или Ubuntu MATE, основанный, соответственно, на Ubuntu.

Из плюсов - стабильность работы, симпатичные оболочки для рабочего стола (LXDE или MATE), большой набор сторонних приложений, устанавливаемых из репозиториев, что позволит использовать устройство в качестве более-менее полноценной замены обычному ПК (есть web-браузер, офисный пакет Libre Office). Из минусов - устанавливать клиентское ПО и настраивать ТК придется самостоятельно. И если найти клиент Citrix Receiver не проблема, то, например, VMware Horizon Client для Linux под процессоры ARM доступен только технологическим партнерам, доставать его с какого-нибудь ТК - удовольствие сомнительное.

Альтернативный вариант, Raspberry Pi Thin Client Project (RPiTC2) обладает, пожалуй, самым широким перечнем функциональных возможностей. RPiTC2 поддерживает клиенты для многих популярных терминальных сред и VDI инфраструктур, включая Citrix XenApp и XenDesktop, VMware Horizon View, Microsoft RDS, NoMachine NX, Thinlinc, Parallels 2X, Red Hat SPICE.

RPiTC2 представляет собой дистрибутив на базе Debian с оболочкой XFCE4, из которого убрано все лишнее (по умолчанию установлен только web-браузер Iceweasel). Установка клиентов для удаленного подключения и дополнительного ПО выполняется из мастера RPiTC Builder.

В PRiTC2 присутствует несколько интересных функций, например, разгон CPU, плагин для Citrix с аппаратной поддержкой декодирования H.264, VNC сервер, несколько клиентов для RDP, включая собственную сборку - dFreeRDP, отличающуюся более высоким уровнем производительности.

Еще один вариант может подойти тем, кто использует терминальные решения Microsoft. Компания WTware, разработчик одноименного ПО, позволяющего создавать нулевые клиенты из обычных ПК, предлагает бесплатную версию и для Raspberry Pi 2.

Несмотря на то, что WTware работает только с RDP протоколом, поддерживаются такие функции, как воспроизведение звука, проброс в удаленную сессию дисков, принтеров и serial-устройств. Кроме того, WTware имеет встроенный VNC сервер, с помощью которого можно наблюдать за работой пользователей ТК, и web-браузер Chrome.

Огромным плюсом WTware является возможность централизованного управления ТК (можно править конфигурационные файлы клиентов, удаленно перезагружать устройства и просматривать их журналы) через административную консоль WTware Center, устанавливаемую на отдельный компьютер с ОС Windows.

Разработчик активно дорабатывает свое ПО, в будущем планируется поддержка аутентификации по смарт-картам и проброс USB устройств.

Последний и довольно экзотический вариант - сборка Chromium OS под Raspberry Pi.

Chromium OS имеет встроенный браузер Chomium, что позволяет подключаться к инфраструктуре VMware View, используя протокол Blast, или Citrix XenApp/XenDesktop (при помощи Citrix Receiver for HTML5).

Недостатки Raspberry Pi

Кратко описав варианты ОС для создания ТК, перейдем к недостаткам использования RPi в качестве ТК.

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

Сырость ОС и ограничения клиентского ПО под архитектуру ARM. Например, клиент VMware Horizon Client под Linux ARM не поддерживает RTAV (Real Time Audio-Video), Scanner Redirection, Multimedia Redirection, Serial-port Redirection. Клиенты RDP не отличаются высокой производительностью и стабильностью работы. Клиенты Citrix Receiver и VMware Horizon Client требуется доводить до кондиции, особенно если вы устанавливаете их самостоятельно. Но следует отметить, что во многих "готовых" тонких клиентах под ARM присутствуют подобные недостатки.

Отсутствие ПО для централизованного управления и обновления ТК (кроме WTware). Если для ТК Dell или HP вы можете использовать Wyse Device Manager или HP Device Manager, то для RPi вам придется самому писать скрипты или осваивать что-нибудь вроде Ansible.

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

Отсутствие поддержки загрузки по PXE - RPi поддерживает загрузку только с Micro SD карт (справедливо для старых поколений устройств, в RPi 3 добавлена загрузка по PXE и с USB накопителя).

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

Низкая производительность для ресурсоемких задач (проигрывание видео, графические редакторы, САПР в удаленной сессии). Для типовой офисной работы RPi вполне хватает, но не следует ждать чудес от устройства за 35$ там, где не справляется ТК за 600$.

Вывод

Вывод по поводу использования Raspberry Pi в качестве ТК очень простой. Если на первом месте стоит снижение затрат на покупку, и вы готовы самостоятельно дорабатывать данное решение, то в этом случае RPi - безоговорочный лидер. Вполне возможно, что кто-то из производителей рано или поздно решится сделать ТК на базе RPi.

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

среда, 17 февраля 2016 г.

Уязвимости CVE-2015-7547 могут быть подвержены продукты VMware

Со мной в чате поделились ссылкой касаемо новой глобальной уязвимости CVE-2015-7547, которая затрагивает огромное число устройств, использующих ОС на базе Linux.

Уязвимость содержится в библиотеке glibc, начиная с версии 2.9, и затрагивает механизм разрешения DNS имен. Сформированный специальным образом UDP или TCP пакет может вызвать ошибку переполнения буфера и привести к таким неприятным вещам, как исполнение произвольного кода со всеми вытекающими отсюда последствиями.

Многие продукты VMware также используют уязвимые версии данной библиотеки, например, гипервизор ESXi 5.5 - 6.0, vSphere Data Protection, vSphere Replication, vRealize Operations, vRealize Orchestrator, vRealize Automation, NSX и другие (в которых используется glibc 2.11.1 или 2.11.2).

И если насчет гипервизора нет информации, используется ли glibc для разрешения DNS имен, то виртуальные апплайнсы, вероятно, подвержены уязвимости.

Согласно баг-репорту, уязвимость исправлена в glibc версии 2.23.

Поэтому до выхода обновлений к продуктам рекомендуется предпринять следующие меры для снижения риска эксплуатации уязвимости:
  1. Использовать только доверенные DNS серверы для разрешения имен.
  2. Ограничивать на брандмауэрах длину DNS паветов от сервера 512 байтами для протокола UDP и 1024 для TCP.

вторник, 16 февраля 2016 г.

Миграция с VMware Embedded PSC на External PSC на Windows Server

Начиная с версии vSphere 6.0 U1, стала поддерживаться миграция vCenter Server со встроенного Platform Services Controller на внешний PSC.

Разнесение PSC и vCenter между серверами может потребоваться в больших виртуальных средах, если вы планируете настроить балансировку служб PSC, использовать несколько серверов vCenter, объединенных в Enhanced Linked Mode, или создать отказоустойчивый кластер vCenter Server.

Краткие шаги по миграции:
  1. Если включен брандмауэр Windows, откройте порты 88, 389, 636, 2012,2014, 2020, 7080, 7081, 11711, 11712 на сервере vCenter с установленным PSC. Иногда при перезагрузке сервера может возникать ситуация, когда службы PSC не прослушивают порт 2020, в этом случае помогает перезапуск службы VMware afd Service.
  2. Установите External PSC на отдельный сервер, подключив к тому же домену (по умолчанию, vsphere.local), и указав тот же сайт, что был задан при установке Embedded PSC. Узнать имя сайта можно, выполнив следующую команду на сервере vCenter:
    "C:\Program Files\VMware\vCenter Server\python\python.exe" "C:\Program Files\VMware\vCenter Server\VMware Identity Services\lstool\scripts\lstool.py" get-site-id --url https://psc_node_fqdn/lookupservice/sdk
    Если в процессе установки возникает ошибка "failed to run vdcpromo", то, скорее всего, вы не открыли какой-то из портов. В этом случае проверьте их при помощи Telnet с какого-нибудь компьютера из локальной сети.
  3. Перенастройте vCenter Server на использование нового PSC: http://pubs.vmware.com/vsphere-60/index.jsp?topic=%2Fcom.vmware.vsphere.install.doc%2FGUID-E7DFB362-1875-4BCF-AB84-4F21408F87A6.html
  4. Удалите записи о старом PSC, чтобы исправить ошибку в Perfcharts: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2131327
  5. Удалите старые корневые сертификаты на сервере vCenter: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2133028
  6. Замените Machine и User сертификаты на vCenter Server: http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2112279
  7. и http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2112281
  8. Поправьте сертификаты: http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2121701
  9. Перезагрузите сервер vCenter Server.


пятница, 12 февраля 2016 г.

Использование силосов для хранения индивидуальных настроек VMware User Environment Manager

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

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

С одной стороны, пользователь хочет использовать один профиль и иметь идентичные настройки ОС и приложений на каждом компьютере.

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

Настройка нескольких хранилищ для профилей, например, при использовании стандартных перемещаемых профилей Windows или профилей VMware Persona Management, хоть и решает данную проблему, но, во-первых, приводит к необходимости выделять на файловом сервере дисковое пространство под каждый новый профиль, во-вторых, поскольку профили никак не синхронизируются между собой, потребует от пользователя выполнять одни и те же настройки несколько раз.

Для решения этой проблемы в VMware UEM существует механизм силосов (silo). Вы можете создать несколько силосов, по одному на каждый тип профиля, задать в каждом из силосов нужные настройки приложений и ОС, и для каждой группы серверов или рабочих станций указать путь к своему силосу.

Для начала требуется включить поддержку силосов (Silo support) в окне Settings в консоли UEM Management Console.

После этого в древовидном списке появится новый пункт Silos, в котором можно будет создавать дочерние объекты - силосы.

Каждый силос представляет собой каталог на файловом сервере, где располагается конфигурация UEM, например, \\fileserver\UEMConfig\silos\termfarm1 и т.д.

Настройки силоса выполняются через групповую политику Silo-specific Flex config files. В политике есть две настройки:
Central location of silo-specific Flex config files - указывает путь к каталогу, где хранятся конфигурационные файлы (Flex configuration file) силоса.
Silo-specific suffix - (опциональная настройка) имя дочернего каталога, где будет храниться архив профиля пользователя (UEM profile archive) для данного силоса. Если суффикс не указан, то в качестве имени дочернего каталога будет использоваться имя силоса.

Поскольку эта политика относится к пользовательской части GPO, то для ее применения на компьютеры потребуется использовать group policy loopback processing mode (о том, что это такое, можно почитать по ссылке: https://technet.microsoft.com/en-us/library/cc978513.aspx).

Настройка силоса выглядят следующим образом:
  1. Создайте в консоли UEM Management Console новый силос.
  2. Создайте в Active Directory новое организационное подразделение, например, termfarm1.
  3. Поместите в OU компьютеры, для которых потребуется указать настройки силоса.
  4. Создайте новый объект групповой политике и включите настройку Configure user Group Policy loopback processing mode в режиме Merge.
  5. В этой же политике укажите путь к силосу Central location of silo-specific Flex config files.
  6. Примените групповую политику к созданному OU.
  7. Повторите шаги для другой группы компьютеров.
Теперь вы можете создавать конфигурации для приложений и ОС по аналогии с каталогом General.

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

В плане настройки силосы ничем не отличаются от каталога General, где, по умолчанию, создаются конфигурационные файлы приложений и ОС.

В силосах хранятся только настройки UEM в части Personalization (настройки приложений и ОС), в силосах нельзя задавать настройки User Environment (подключения сетевых дисков, принтеров, задания переменных окружения и т.д.) и Application Migration (перенос настроек между приложениями).

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

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

Для того чтобы рассмотреть, как настройки силоса сочетаются с архивами профиля пользователя, рассмотрим небольшой пример. Пусть ключ реестра HKCU\software\application\key определяется в predefined параметрах на уровне каталога general, в конфигурации силоса, а также сохранен в основном архиве профиля пользователя, а также архиве профиля пользователя на уровне силоса.
  1. Каталог general: key = A
  2. Архив профиля: key = B
  3. Конфигурация силоса: key = C
  4. Архив профиля в силосе: key = D
При входе пользователя в систему (или запуске приложения, если включен Flex Direct) значение параметра key в реестре будет равно D. Если разрешен экспорт настроек в архив профиля пользователя и на уровне каталога General, и на уровне силоса, то после выхода пользователя из системы (или закрытия приложения) значение key станет равным:
  1. Каталог general: key = A
  2. Архив профиля: key = D
  3. Конфигурация силоса: key = C
  4. Архив профиля в силосе: key = D
Из этого следует один важный момент, если вам требуется, чтобы для двух разных компьютеров (например, VDI и терминальном сервере) в профиле пользователя сохранялись разные настройки и не перезаписывали друг друга, то вам потребуется создать два силоса, в каждом из которых создать свой конфигурационный файл приложения.