Как узнать, какой VTEP использует ВМ в VMware NSX?

Одной из возможностей VMware NSX является поддержка нескольких VTEP (VXLAN Tunnel Endpoint), через которые осуществляется взаимодействие виртуальных машин с внешним миром (ВМ на других хостах и физическими устройствами).

Каждый VTEP представляет собой отдельный VMKernel интерфейс на хосте ESXi, который использует физические интерфейсы (аплинков) для передачи трафика VXLAN.

При настройке кластера администратор может выбрать - использовать один VTEP на каждом хосте или несколько. При использовании одного VTEP на хост поддерживаются практически все режимы балансировки за исключением балансировки по загрузке физического адаптера (Physical NIC Load).

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

• Route based on Port ID
• Route based on Source MAC hash

Тип балансировки задается для всех хостов кластера.

При выборе режима балансировки по Port ID или MAC hash мастер настройки автоматически задает количество VTEP равное количеству аплинков на распределенном коммутаторе. На всех хостах в кластере создается по одному VMkernel интерфейсу для каждого VTEP (в данном случае vmk1 и vmk2).

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

В ряде случаев требуется узнать - какой VTEP и какой физический интерфейс используется для передачи трифика ВМ?

Сделать это можно двумя способами. Во-первых, подключившись к хосту по SSH или через сервисную консоль, и запустив утилиту esxtop. После запуска нужно нажать клавишу 'n', чтобы переключиться на отображение информации о сети.

Для VMkernel интерфейсов и для сетевых интерфейсов ВМ информация об используемом аплинке будет отображаться в колонке TEAM-PNIC. Определить - какой VTEP используется, можно, сопоставив имя аплинка для сетевого интерфейса ВМ с именем аплинка для VMKernel интерфейса (в данном случае, для nsxsrv04 используется vmk1, а для nsxsrv05 - vmk2). Однако, этот способ работает не всегда.

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

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

Второй способ определить VTEP - подключиться к NSX Manager'у и выполнить команду:
show logical-switch controller <controller_id> vni <vni_id> mac

NSX Manager отобразит информацию об известных MAC адресах ВМ и IP адресах VTEP, через которые осуществляется сетевое взаимодействие с данными ВМ. Зная MAC адрес сетевого адаптера ВМ можно легко определить VTEP, который он использует.

Публикация веб-браузеров Google Chrome и Mozilla Firefox на терминальном сервере Windows Server 2008

Не так давно я столкнулся с несколькими проблемами при публикации веб-браузеров на терминальном сервере под Windows Server 2008 (R2).

Google Chrome

При попытке запустить опубликованный Google Chrome в seamless mode (у разных вендоров этот режим называется по-разному - RemoteApp у Microsoft, Hosted Applications у VMware, Application Publishing у Citrix), в окне браузера не загружались страницы, и через некоторое время он завершал свою работу с ошибкой.

Для решения проблемы при публикации Chrome через Microsoft RDS или VMware View достаточно добавить параметр "--allow-no-sandbox-job".

Для Citrix XenApp 6.5 есть статья в базе знаний (http://support.citrix.com/article/CTX132057), в которой при публикации Chrome также рекомендуется добавить параметр "--disable-gpu". Для решения проблемы мне также пришлось заменить Chrome на 32-битную версию, т.к. 64-битная ни в какую не хотела работать.

Mozilla Firefox

При попытке запустить два экземпляра Firefox на одном терминальном сервере под одним пользователем возникает ошибка "Firefox is already running but is not responding".

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

По умолчанию Citrix использует механизм Session Sharing, который запускает опубликованные приложения внутри одной сессии. Данная ошибка возникает, если отключить Session Sharing, добавив ключ в реестре:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\Wfshell\TWI\:

Type: REG_DWORD

Value: SeamlessFlags = 1

а также настроить разрешение на запуск пользователем нескольких сессий на одном терминальном сервере (Remote Desktop Session Host Configuration -> Restrict each user to a single session: no).

Соответственно, чтобы решить проблему, надо либо включить Session Sharing обратно, либо настроить публикацию Firefox с ключами "-P -no-remote", тогда при запуске пользователь сможет создавать и использовать отдельный профиль для каждого экземпляра браузера.

Механизм IP Discovery в VMware NSX

При настройке логических коммутаторов в VMware NSX по умолчанию включается опция Enable IP Discovery.

Enable IP Discovery включает режим ARP Suppression, который позволяет уменьшить количество широковещательных ARP запросов, генерируемых виртуальными машинами для разрешения IP адресов в MAC адреса.

Проиллюстировать работу ARP Suppression можно на следующем примере. VM1 требуется отправить пакет VM2, подключенной к тому же логическому коммутатору (VXLAN 5001).

1. VM1 генерирует широковещательный ARP запрос с целью узнать MAC адрес VM2 (MAC2).
2. ESXi-1 перехватывает широковещательный запрос и вместо этого отправляет unicast запрос к контроллеру NSX Controller.
3. Контроллер получает ARP запрос.
4. Контроллер проверяет свою ARP таблицу на соответствие IP/MAC из запроса.
5. При наличии совпадения контроллер отправляет эту информацию серверу ESXi-1.
6. ESXi-1 получает сообщение от контроллера и обновляет локальную ARP таблицу, так, что в дальнейшем он будет знать на каком VTEP находится MAC адрес VM2 (10.20.10.11).
7. ESXi-1 генерирует ARP ответ от имени VM2 и отправляет его VM1. 

Если на 4 шаге контроллер не обнаружил соответствующую запись в таблице, то он уведомляет сервер ESXi-1, который затем отправляет широковещательный запрос на все VTEP, подключенные к данному логическому коммутатору.

При выключенном ARP Suppression / Enable IP Discovery - контроллер не сохраняет ARP таблицу, и, соответственно, все ARP запросы разрешаются широковещательно.

Посмотреть содержимое ARP таблицы на контроллере можно из консоли NSX Manager с помощью команды:
show logical-switch controller <controller_id> vni <vni_id> arp

Либо из консоли NSX Controller:
show control-cluster logical-switches arp-table <vni_id>

Информацию для ARP таблицы контроллеру NSX предоставляют сами серверы ESXi. Серверы ESXi могут получить информацию об IP адресах ВМ одним из двух способов:

• Для ВМ со статическими адресами, ESXi серверы узнают об IP адресе ВМ из ARP запроса, который генерирует данная ВМ.
• Для ВМ с динамическими адресами ESXi также может узнать об IP адресе ВМ из DHCP ответа, отправляемого сервером DHCP данной ВМ.

Посмотреть содержимое локальной ARP таблицы на сервере ESXi можно с помощью команды:
esxcli network vswitch dvs vmware vxlan network arp list --vds-name=<dvs_name> --vxlan-id=<vni_id>

IP Discovery можно включить и для обычных групп портов распределенного коммутатора. Делается это на вкладке Manage | Settings | NSX Configuration.

Dell ThinOS и Wyse Device Manager

На сегодняшний день Dell является лидером рынка тонких клиентов. Компания предлагает устройства в разных ценовых сегментах с различными ОС - Windows Embedded, Suse Linux, Ubuntu, ThreadX (ОС для нулевых клиентов на базе процессоров Teradici) и ThinOS. О последней и пойдет речь сегодня.

ThinOS является крайне легковесной ОС, поддерживающей все популярные терминальные и VDI решения на рынке (Citrix XenApp/XenDesktop, VMware Horizon View, Microsoft RDS). Последняя актуальная на сегодня версия ThinOS 8.2 поддерживает проброс USB и COM устройств, проброс принтеров, передачу звука в обоих направлениях, аутентификацию по смарт-картам, функции Multimedia Redirection и Flash Redirection, интеграцию с Lync/Skype for Business клиентом на удаленном рабочем столе.

На рынке присутствуют несколько моделей, поддерживающих ThinOS, наиболее популярные из них: Wyse 3010/3012 (T10/T10D) - тонкий клиент начального уровня с одним или двумя видеовыходами, Wyse 5010/5012 (D10/D10D) - модель среднего ценового диапазона, Wyse 5212 (D10DP) - модель с поддержкой протокола PCoIP.

Одним из плюсов устройств на базе ThinOS является простота настройки и обновления - устройства могут самостоятельно подключаться к серверу-репозитарию по протоколу FTP или HTTP и загружать файл с настройками, обновления прошивки и пакетов.

Настройки клиента описываются в файле wnos.ini.

Пример настроек приведен ниже.

Включает сохранение настроек клиента в NVRAM, а также скрывает стандартные ярлыки Default ICA и Default RDP с рабочего стола.
EnableLocal=yes HideDefault=yes

Данная настройка позволяет клиенту автоматически загружать с сервера более новую версию прошивки и устанавливать ее. После обновления клиент автоматически сбросит настройки в значение по умолчанию - это полезно в том случае, когда в более новых версиях какие-либо из настроек объявлены deprecated или больше не работают.
autoload=2
FactoryDefault=yes

Задать режим привилегий для локального пользователя. По умолчанию все пользователи имеют режим привилегий High, который позволяет изменять любые настройки на клиентах, а также сбрасывать конфигурацию устройства. При переключении клиента в режим low пользователи получат доступ только к некритичным настройкам, что уменьшает риск что-либо сломать. Для переключения обратно в превилегированный режим можно создать административную учетную запись.
Privilege=Low
AdminMode=yes Username=wyseadmin Password=Wyse#123

Настройки интерфейса тонкого клиента и отображения панели инструментов. По умолчанию используется классический интерфейс, который отображает панель в нижней части экрана, схожей с панелью Пуск в ОС Windows. Режим vdi представляет более простой для восприятия интерфейс.
SysMode=vdi ToolbarDisableMouse=yes ToolbarEnableOneSession=yes

Настройки NTP сервера и временной зоны.
Timeserver=ntp.company.local Timeformat="24-hour format"
TimeZone='GMT + 03:00' TimeZoneName="Russian" ManualOverride=no

Включить управление тонким клиентом при помощи сервера WDM, настроить обнаружение сервера по протколам DHCP и DNS.
WDMService=Yes DHCPinform=yes DNSLookup=yes

Включить функцию Wake on LAN на клиенте.
WakeOnLan=yes

Настройка тонкого клиента на автоматическое подключениие к серверу VMware View Connection Server. Включение режима проверки подлинности сертификата.
VDIBroker=vdi.company.local
ConnectionBroker=VMware SecurityMode=Full

Настройка тонкого клиента на подключение к Citrix XenApp/XenDesktop.
PnliteServer=https://storefront.company.local/Citrix/Desktop/ Storefront=yes ReconnectAtLogon=1

Настройка импорта сертификатов в хранилище тонкого клиента. Все сертификаты должны располагаться в дочернем каталоге cacerts.
AddCertificate=RootCA.crt
AddCertificate=InterCA.crt

Настройки подключения к тонкому клиенту по протоколу VNC. Для подключения требуется указать пароль, а также получить подтверждение на подключение от пользователя ТК .
Service=vncd disable=no
MaxVNCD=1 VNCD_8bits=yes VNCD_Zlib=yes
VncPassword="Wyse#123" Encrypt=no
VncPrompt=yes Accept=60 ActiveVisible=yes

Дополнительные параметры описаны в руководстве Dell Wyse ThinOS 8.2 INI Reference Guide, которое доступно на сайте http://www.wyse.com/manuals.

Создать файл вы можете вручную, или с помочью утилиты от сторонних разработчиков - ConfigGen (http://www.technicalhelp.de/configuration-generator/).

Утилита позволяет с помощью простого графического интерфейса или через мастера настройки задать основные параметры тонкого клиента и на выходе получить файл wnos.ini.

Для обновления клиентов достаточно разместить файл с прошивкой в том же каталоге, что и wnos.ini.

Существуют два варианта, как сообщить тонкому клиенту о местоположении файлов настройки и прошивок.

Во-первых, вы можете создать дополнительные опции в DHCP:

• File server - опция 161 типа String, в которой указывается адрес FTP сервера (доменное имя или IP-адрес).
• Root path to the file server - опция 162 типа String, в которой указывается каталог, где располагается конфигурационный файл wnos.ini. Тонкий клиент всегда добавляет к пути дочерний каталог \wyse\wnos, так, что если вы укажите в данной опции путь pub\thinclient, то полный путь к файлу конфигурации, который будет искать клиент: "<server>\pub\thinclient\wyse\wnos\wnos.ini".
• File server Username - опция 184 типа String. В данной опции можно указать имя пользователя, под которым будет выполнено подключение к серверу (в случае, если анонимный доступ запрещен).
• File server Password - опция 185 типа String. В данной опции указывает пароль пользователя, под которым будет выполнено подключение к серверу.

Во-вторых, вы можете настроить сервер Wyse Device Manager, чтобы тот сообщал о расположении файла wnos.ini. Делается это в меню настроек (Preferences) на вкладке WTOS. Требуется включить опцию WTOS INI path upon checkin и в поле WTOS Root Path указать путь к конфигурационному файлу.

После этого расместите файл wnos.ini в каталоге C:\inetpub\ftproot\Rapport\WTOSCONFIG\WNOS, чтобы клиент смог загрузить его.

Помимо предоставления информации о местоположении файла конфигурации сервер Wyse Device Manager позволяет выполнять различные операции с тонкими клиентами:

• Получать информацию о клиенте - модель, версия прошивки, сетевые настройки, указывать расположение и имя устройства.
• Перезагружать и выключать тонкий клиент. 
• Включать ТК при помощи Wake on LAN.
• Подключаться к ТК удаленно (Remote Shadow).

Wyse Device Manager доступен в двух редакция: Workgroup и Enterprise. Workgroup бесплатна для использования и может управлять до 10000 тонких клиентов. Все компоненты WDM в случае Wokgroup устанавливаются на один сервер, в качестве СУБД используется Microsoft SQL Server Express Edition. Enterprise редакция позволяет управлять более 10000 клиентами, поддерживает установку компонентов на разные серверы и подключение к внешнему СУБД Microsoft SQL Server. Допонительные отличия двух редакций приведены в документе Dell Wyse Device Manager Administrator's Guide. Актуальная на текущий момент версия WDM - 5.5.1.

При включении клиент автоматически подключается к серверу по протоколу HTTPS или HTTP и сообщает информацию о своем состоянии.

Для перезагрузки и выключения клиента сервер отправляет команду ТК по протоколу HTTP (TCP 80).

Функция Remote Shadow использует протокол VNC (TCP 5900). В зависимости от настроек, подключение может выполнять автоматически без запроса и уведомления пользователя ТК, администратор может только видеть экран, либо управлять клавиатурой и мышью.

Для обнаружения сервера WDM используется один из механизмов:

• DHCP опции.
• Запись WDMServer в DNS.
• Запись типа SRV _WDMServer в DNS. 

Для обнаружения с использования DHCP опций требуется создать следующие опции:

• WDM server list - опция 186 типа IP Address, в которой требуется указать IP адрес WDM сервера.
• WDM secure port - опция 190 типа Word, в которой требуется указать порт для безопасного подключения к серверу WDM (по умолчанию, 443).
• WDM server port - опция 192 типа Word, в которой требуется указать порт для небезопасного подключения к серверу WDM (по умолчанию, 80).

Для обнаружения сервера через DNS достаточно создать запись типа A и CNAME с именем WDMServer в DNS.

Альтернативный вариант - создать запись типа SRV _WDMServer._TCP.<domain>. Плюсом данного вариант, является то, что вы также можете указать порт, который тонкий клиент будет использовать для подключения.

Подготовка образа Windows Thin PC и установка при помощи VMware Mirage (часть III)

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

Первая часть: http://blog.vmpress.org/2016/05/windows-thin-pc-vmware-mirage-i.html
Вторая часть: http://blog.vmpress.org/2016/06/windows-thin-pc-vmware-mirage-ii.html

Настройка сервера Mirage

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

Я пропушу описание процедуры установки ролей Mirage, отмечу, что для тестов вам потребуется в обязательном порядке Microsoft SQL Server, Mirage Management Server, Mirage Server, Mirage Management Console, и, опционально, Mirage Web Management Server, если вы планируете использовать функцию Self-Service Portal, для выбора и установки эталонного образа с целевого компьютера.

После установки VMware Mirage выполните следующие настройки.

Во-первых, создайте новую CVD Policy, которая будет назначаться всем устройствам с ОС ThinPC. В политике на вкладке Advanced Options включите параметр Layer management only - это позволит не выполнять резервное копирование данных с целевых устройств, и тем самым сэкономить дисковое пространство на сервере. Поскольку на целевых устройствах не предполагается хранить никаких пользовательских данных и устанавливать дополнительное ПО, то и нет смысла их бекапить.

Во-вторых, добавьте драйверы устройств и создайте новый профиль драйверов, указав на вкладке Rules правило OS Equals Win7 Embedded. Это позволит клиенту Mirage загружать необходимые драйверы при установке эталонного образа.

Если вы планируете использовать защищенное подключение к серверу Mirage, добавьте цифровой сертификат в настройках сервера (System Configuration -> Servers -> <Сервер Mirage> -> Configure).

Добавьте информацию о домене, в который будут вводиться компьютеры. Для этого щелкните правой кнопкой мыши по System Configuration и в контекстном меню выберите Settings.

На вкладке General в области Join Domain Account укажите учетную запись, из-под которой будет выполняться ввод компьютера в домен. Для этих целей лучше создать отдельную учетную запись пользователя, которая имеет права Reset Password, Write all properties, Delete, Create computer objects и Delete computer objects.

Если вы все сделано правильно, то в консоли VMware Mirage Console в окне Pending Devices появится компьютер с установленным Windows Thin PC, который можно использовать в качестве источника для эатлонного образа (Reference CVD). Щелкните правой кнопкой мыши по компьютеру и в контекстном меню выберите Create a new Reference CVD.

В открывшемся окне Activate Device выберите Create Reference CVD for Base Layer capture и нажмите Next.

В окне выбора политики Select CVD Policy выберите политику по умолчанию VMware Mirage default CVD policy и нажмите Next.

В окне Select a Base Layer выберите Don't use a Base Layer и нажмите Next.

В окне Select Target Volume выберите том, на котором будет сохранен образ, и нажмите Next.

Завершите мастер и нажмите Finish для начала процедуры централизации компьютера.

После завершения процедуры централизации перейдите на вкладку Reference CVDs, щелкните правой кнопкой мыши по компьютеру и в контекстном меню выберите Create Base Layer...

В открышемся окне выберите Create a new layer, введите имя, описание и версию нового эталонного образа. Нажмите Next.

В окне Check Compatibility проверьте, что компьютер прошел проверку и нажмите Next.

Нажмите Finish для начала создания базового образа. Отслеживать статус процедуры создания образа можно на вкладке Task Monitoring.

Подготовка загрузочного образа

Для того, чтобы применить полученный образ на целевые компьютеры нам потребуется сначала загрузить их, используя специальный установочный образ WinPE. Для создания образа используется сценарий BuildMirageWinPE.cmd, который поставляется вместе с дистрибутивом VMware Mirage. Для создания образа используйте отдельный компьютер с установленным пакетом Windows Assessment and Deployment Kit for Windows 8.1.

Распакуйте архив Mirage.WinPE.x64.119795.zip. Полученный каталог содержит несколько вложенных каталогов и файлов.

Скопируйте в каталог Drivers папки с драйверами устройств, которые вы использовали при подготовке эталонного образа.

Если вы планируете использовать безопасное подключение к серверу Mirage, скопируйте в папку Certificates сертификаты Удостоверяющего Центра. Опционально, если вы настроили Self-service Provisioning, то также скопируйте сертификаты также в каталог Certificates\Browser, чтобы браузер не выдавал предупреждений.

Отредактируйте файл BuildMirageWinPE.cmd, указав в нем правильные значения переменных:

• SERVER_ADDRESS - IP-адрес или DNS имя сервера Mirage для подключения клиентов.
• SERVER_PORT - порт для подключения (по умолчанию, 8000).
• USE_SSL - использовать ли SSL для подключения клиентов к серверу Mirage (TRUE или FALSE).
• USE_SELF_SERVICE_PROVISIONING - разрешить ли клиентам самостоятельно выполнять установку ОС на устройства (TRUE или FALSE). В случае TRUE, после загрузки, автоматически запуститься браузер Mozilla Firefox и подключиться к серверу Mirage Self-Service Portal.
• WEB_SELF_SERVICE_PROVISIONING_URL - адрес веб-сервера Mirage Self-Service Portal (например, https://mirage.domain.local:7443/ssp).
• LANGUAGE - язык оболочки WinPE. Можно оставить пустым.
• OUTPUT_PATH - путь, в котором будет создан каталог с файлами .wim и .iso с образами WinPE.

Запустите скрипт BuildMirageWinPE.cmd, используя права локального администратора. Если вы корректно указали настройки, то через несколько минут вы получите загрузочный образ в виде .ISO файла и .WIM файла (для установки через WDS).

Настройка сервера WDS

Если с загрузкой компьютера с помощью .ISO все более-менее понятно, то на варианте с WDS стоит остановиться чуть подробнее.

Сервер WDS может быть установлен как на выделенном компьютере, так и на сервере Mirage. Для работы потребуется оба компонента WDS (Deployment Server и Transport Server).

После установки WDS выполните следующие настройки. В свойствах сервера на вкладке PXE Response установите параметр Respond to all client computers (known and unknown). Это позволит любому клиенту (и авторизованному и неавторизованному) получать загрузочный образ с сервера WDS.

На вкладке Boot укажите путь к загрузочному .WIM образу (x86 architecture), который был ранее создан при помощи BuildMirageWinPE.cmd. Также установите параметры Always continue the PXE boot, чтобы клиент автоматически продолжал загрузку по PXE.

Настройка DHCP

Для передачи информации о WDS сервере в DHCP должны быть настроены следующие опции:

• Опция 66 тип String - IP-адрес или DNS имя WDS сервера.
• Опция 67 тип String - путь к загрузочному файлу, для 64-разрядных ОС путь "boot\x64\pxeboot.com", для 32-разрядных: "boot\x86\pxeboot.com".

Установка эталонного образа

Теперь достаточно перенастроить целевые компьютеры на загрузку по PXE, чтобы они получили загрузочный образ по сети. После завершения загрузки у вас есть два варианта, как установить ОС на клиентские компьютеры.

Если в скрипте BuildMirageWinPE.cmd вы разрешили использование Self-Service Portal, и соответствующая роль развернута на сервере Mirage, то после загрузки у вас откроется web-браузер Mozilla Firefox с окном аутентификации на портале самообслуживания. Указав учетную запись, которой присвоена роль Web Image Manager в консоли Mirage, администратор сможет выполнить установку образа на компьютер и ввести его в домен. Данный вариант походит, если вам необходимо установить ОС на небольшое количество компьютеров, либо вы хотите делегировать эту задачу администратору на месте.

Второй вариант - воспользоваться мастером Device Provisioning в консоли Mirage Management Console. Этот вариант походит для централизованной установки ОС на большое количество компьютеров.

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

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

Как вы могли убедиться, связка VMware Mirage и Microsoft Windows Thin PC несет в себе ряд преимуществ, и может пригодиться, если вы планируете разворачивать VDI инфраструктуру на базе продуктов VMware и хотите использовать существующие ПК в качестве тонких клиентов. В случае необходимости внесения изменений в конфигурацию компьютереов или установки обновлений достаточно будет обновить эталонный компьютер и сохранить новую версию образа, после чего Mirage сможет загрузить его на все обслуживаемые компьютеры.

Подготовка образа Windows Thin PC и установка при помощи VMware Mirage (часть II)

Продолжаем готовить тонкий клиент на базе Windows ThinPC (первая часть по ссылке). Сегодня - установка дистрибутива на эталонный ПК и допиливание его до кондиции.

Эталонный ПК

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

Для ВМ достаточно выделить небольшой объем ресурсов:

• 2 vCPU.
• 3 ГБ ОЗУ.
• 24 ГБ жесткий диск.
• сетевой адаптер E1000 или VMXNET3. 

Создайте машину и подключите созданный ранее ISO. Установка будет выполнена в автоматическом режиме и через некоторое время появится экран рабочего стола.

Установка ПО

Для тонкого клиента потребуется установить, по крайней мере, клиент VMware Horizon View Client и VMware Mirage Agent.

Установку клиента Horizon View можно выполнить из командной строки:

VMware-Horizon-Client-x86-yyy-xxxxxx.exe /s /v"/qn REBOOT=ReallySuppress VDM_SERVER=view01.company.local ADDLOCAL=Core,TSSO,USB"

, где VDM_Server - задает имя сервера View Connection по умолчанию;
ADDLOCAL - определяет перечень устанавливаемых компонентов дял клиента (Core - базовые компоненты, TSSO - сквозная SSO аутентификация с использованием учетной записи, под которой был выполнен вход, USB - поддержка проброса USB устройств).

Добавление сертификата УЦ

Если вы используете сертификаты, выданные корпоративным удостоверяющим центром, то для работы Horizon View Client и Mirage Client на компьютер потребуется импортировать соответствующий корневой сертификат. Сделать это можно из оснастки MMC Certificate Manager или из командной строки при помощи команды:

certutil -addstore root rootCA.crt

, где rootCA.crt - имя файла корневого сертификата.

Установка клиента Mirage

Для установки Mirage Agent требуется .Net Framework 4.0. Загрузите и установите .Net Framework 4.0 (автоновный установщик .Net Framework 4.0, не требующий подключение к интернету, можно загрузить отсюда: https://www.microsoft.com/en-US/download/details.aspx?id=17718). Установить .Net Framework можно из командной строки при помощи команды:

dotNetFx40_Full_x86_x64.exe /q

Сохраните клиент Mirage Client на компьютере. Для установки клиента из командной строки выполните:

MirageClient.x86.buildnumber.msi SERVERIP=<MirageServer>:<port> USESSLTRANSPORT=true /quiet

, где <MirageServer> - имя или IP-адрес сервера Mirage, например, mirage01.company.local;
<port> - порт для подключения (по умолчанию, 8000);
USESSLTRANSPORT=true - использовать защищенное SSL подключение.

Если все настроено корректно, то вскоре в диспетчере задач появится ярлык клиента Mirage, а сам клиент будет отображать статус Pending Assignment.

Дополнительные настройки

На текущем этапе компьютер уже готов для создания образа при помощи VMware Mirage, однако, вы можете выполнить ряд дополнительных настроек, таких как:

• Настройка сценария, автоматически запускающегося после копирования образа на целевые компьютеры.
• Настройка защиты от записи на диск при помощи File-Based Write Filter.
• Настройка политик запуска приложений AppLocker.
• Кастомизация интерфейса ОС.

Настройка сценария

Как и в случае с установкой ОС из дистрибутива, VMware Mirage предоставляет возможность запускать скрипт, позволяющий выполнить дополнительные настройки, после того, как образ будет скопирован на целевые компьютеры и они будут готовы для использования.

Для выполнения сценария создайте файл post_core_update.bat в каталоге "C:\ProgramData\Wanova\Mirage Service\". Например, следующий скрипт включает учетную запись локального администратора и настраивает автоматический вход в систему под локальной учетной записью User.

REM Activate Administrator account
net user Administrator /active:yes

REM Prevent User account from changing password and password expiration
net user User /Passwordchg:no
wmic path Win32_UserAccount where Name='User' set PasswordExpires=false

REM Enable User account auto logon
REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AutoAdminLogon /t REG_SZ /d 1 /f
REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultUserName /t REG_SZ /d User /f
REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword /t REG_SZ /d "" /f

exit 0

В конце файла обязательно добавьте "exit 0", так клиент Mirage определит, что сценарий завершился без ошибок.

Настройка защиты от записи

Одной из интересных возможностей ОС Windows Embedded является функция защиты от записи File-Based Write Filter, которая позволяет обнулять все изменения, сделанные с ОС с момента загрузки, обеспечивая защиту ОС от вредоносного ПО и кривых рук пользователей.

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

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

bcdedit.exe /set BOOTSTATUSPOLICY IgnoreAllFailures

Создайте файл fbwf-enable.cmd в каталоге "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Maintenance" со следующим содержанием:

fbwfmgr.exe /enable
fbwfmgr.exe /setthreshold 256
fbwfmgr.exe /addvolume C:
fbwfmgr.exe /addexclusion C: \Programdata\
fbwfmgr.exe /addexclusion C: \Users

, где /enable - включает FBWF при следующей загрузке;
/setthreshold - задает размер RAM-диска для буфера записи в МБ;
/addvolume - задает том, для которого следует включить FBWF;
/addexclusion - указывает каталоги, для которых не следует включать FBWF.

Также создайте еще один файл fbwf-disable.cmd в том же каталоге для отключения FBWF:

fbwfmgr.exe /disable

Теперь администратор сможет легко включить или отключить защиту от записи на любом тонком клиенте, созданном из данного образа.

Настройка AppLocker

Настройте службу Application Identity на автоматический запуск.

sc config AppIDSvc start= auto
sc start AppIDSvc

Настройте политики Applocker из оснастки локальных групповых политик или создайте файл applockerpolicy.xml и импортируйте при помощи powershell.

import-module applocker
set-applockerpolicy C:\temp\applockerpolicy.xml

Пример файла политик, блокирующий запуск приложений из любых папок, кроме Program Files и Windows:

<AppLockerPolicy Version="1">
  <RuleCollection Type="Exe" EnforcementMode="Enabled">
    <FilePathRule Id="921cc481-6e17-4653-8f75-050b80acca20" Name="(Default Rule) All files located in the Program Files folder" Description="Allows members of the Everyone group to run applications that are located in the Program Files folder." UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePathCondition Path="%PROGRAMFILES%\*" />
      </Conditions>
    </FilePathRule>
    <FilePathRule Id="a61c8b2c-a319-4cd0-9690-d2177cad7b51" Name="(Default Rule) All files located in the Windows folder" Description="Allows members of the Everyone group to run applications that are located in the Windows folder." UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePathCondition Path="%WINDIR%\*" />
      </Conditions>
    </FilePathRule>
    <FilePathRule Id="fd686d83-a829-4351-8ff4-27c7de5755d2" Name="(Default Rule) All files" Description="Allows members of the local Administrators group to run all applications." UserOrGroupSid="S-1-5-32-544" Action="Allow">
      <Conditions>
        <FilePathCondition Path="*" />
      </Conditions>
    </FilePathRule>
  </RuleCollection>
  <RuleCollection Type="Msi" EnforcementMode="NotConfigured" />
  <RuleCollection Type="Script" EnforcementMode="NotConfigured" />
  <RuleCollection Type="Dll" EnforcementMode="NotConfigured" />
</AppLockerPolicy>

Кастомизация интерфейса ОС

Для отображения информации о системе (имя компьютера, IP адрес, версию клиента и т.д.) на экране вы можете использовать небольшую утилиту BGInfo.

BGInfo можно добавить в автозагрузку для автоматического обновления информации:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
bginfo = "C:\Program Files\bginfo\bginfo.exe" "C:\Program Files\bginfo\configuration.bgi" /timer=0
Файл конфигурации .bgi можно экспортировать из BGInfo.

Если вы хотите изменить изображение на экране входа в систему, то создайте новый параметр OEMBackground типа DWORD в реестре
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Background\ и установите его значение в 0x1. Затем скопируйте в каталог %windir%\System32\oobe\info\backgrounds\ файл с изображением в формате jpg и переименуйте его в BackgroundDefault.jpg для использования в качестве изображения по умолчанию для нестандартных разрешений экрана или в Background<разрешение>.jpg - для одного из стандартных разрешений.

Теперь при входе в систему будут использоваться ваше изображение.

Для настройки логотипа и дополнительной информации о системе отредактируйте следующие параметры в реестре HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\OEMInformation:

• Manufacturer - тип STRING, указывает производителя ПК.
• SupportHours - тип STRING, указывает рабочие часы службы технической поддержки.
• SupportPhone - тип STRING, указывает телефон для связи со службой технической поддержки.
• SupportURL - тип STRING, указывает адрес web-сайта для связи со службой технической поддержки.
• Logo - тип STRING, указывает путь к файлу логотипа в формате bmp (например, C:\Windows\System32\oemlogo.bmp)

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