Remote Desktop Services 2012 R2. RemoteAPP+RDSession

Логика работы терминальных ферм Windows заключается в том, что для коллекции RDS существует три режима работы:

  • Remote Desktop Sessions (привычный удалённый рабочий стол)
  • Remote Virtualization (виртуальные рабочие станции, VDI)
  • RemoteAPP (приложения)

Если для Remote Virtualization надо петь отдельную песню: там требуется Hyper-V и прочее, то для RD Sessions и RemoteAPP таких требований нет — выделяется один и более Session Host серверов в коллекцию. Далее, если в коллекции не опубликованных приложений, то показывается в RD WebAccess показывается иконка RDP.

А если есть публикация — только иконки на опубликованные приложения.

Вполне может сложиться ситуация, что нам необходимо предоставить как RemoteAPP, так и чистый RDP. В этом случае необходимо на серверах Connection Broker внести правку в реестр:

Раздел HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\<collection>\RemoteDesktops\<collection>

Параметр ShowInPortal поставить в 1.

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

В этом случае мы сталкиваемся с другой проблемой. Доступ к RemoteAPP мы можем настраивать отдельно к каждому приложению:

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

Выходим из этой ситуации следующим способом. Публикуем приложение Remote Desktop Connection (mstsc.exe):

И после этого в настройку приложения в командную строку пишем /v:Session_host_name (без пробела):

После настройки безопасности RemoteApp доступ к удалённому рабочему столу будет только у необходимых лиц. Из недостатков можно определить то, что так можно дать доступ только к одному Session Host, и балансировать через Connection Broker не получится.


В стране невыученных уроков. Детский спектакль

Детский спектакль театральной студии Амплуа средней школы №15 г. Коломны.
Художественный руководитель — Максим Юрьевич Федосеев.


Remote Desktop Services 2012 R2. Боремся с плодящимися сессиями

Так получается, что по умолчанию в RDS 2012 R2 мы можем получить плодящиеся сессии пользователей. Проявляется это так:

Боремся следующими методами.

  1. Устанавливаем время жизни сессии в состояниях Idle и Disconnected:
  2. На Session Hosts открываем оснастку групповой политики и ставим в состояние Enabled следующие параметры:
    — Computer Configuration / Administrative Templates / Windows Coomponents / Remote Desktop Services / Remote Desktop Session Host / Connections / Automatic reconnection
    — Computer Configuration / Administrative Templates / Windows Coomponents / Remote Desktop Services / Remote Desktop Session Host / Connections / Restrict Remote Desktop services users to a single Remote Desktop services session

  3. В настройках сессии ставим галку Enable automatic reconnection (картинка выше)

Погружение в DHCP. Часть 3

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

Всё взаимодействие между клиентом и сервером DHCP происходит на основе сообщений DHCP. Если клиент уже знает свой адрес, некоторые шаги могут быть пропущены.

Сообщения, которыми обмениваются клиент и сервер:

Сообщение Описание
DHCPDISCOVER Клиент: широковещательный запрос на поиск доступных серверов
DHCPOFFER Сервер: ответ на запрос DHCPDISCOVER с предложением параметров
DHCPREQUEST Клиент:

  1. Запрос параметров у конкретного сервера в случае получения множества DHCPOFFER.
  2. Подтверждение корректности полученного ранее адреса после перезагрузки системы, потери сети и т. д.
  3. Запрос на продление аренды.
DHCPACK Сервер: ответ клиенту с конфигурационными параметрами включая подтверждённый адрес
DHCPNAK Сервер: отказ в предоставлении аренды по причинам некорректности запрашиваемого адреса (клиент перемещён в другую сеть), истечения срока аренды и т. п.
DHCPDECLINE  Клиент: сообщение серверу, что предложенный адрес занят
DHCPRELEASE  Клиент: сообщение серверу об освобождении адреса (больше не нужен)
DHCPINFORM  Клиент: запрос только местных конфигурационных параметров (адрес у клиента уже есть), например серверы времени или WINS сервер.

 

dhcp_way

 

1

Для начала клиент совершает широковещательный запрос DHCPDISCOVER в своей локальной сети (широковещательном домене). Этот запрос может содержать IP-адрес и время аренды, которые хост хочет получить. Если клиент и сервер находятся в разных сетях, то используются агенты пересылки (DHCP relay, ip helper) для передачи запроса напрямую серверу DHCP.

2

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

  1. Временная резервация адреса, чтобы предотвратить работу с этим адресом по другим запросам (свободный адрес берётся из базы).
  2. Сервер должен сделать пинг по этому адресу для проверки занятости.

По второму пункту стоит отметить, что сервер должен пинговать, но администратор может отключить эту функцию. Опять же важно, что в реализации Microsoft DHCP Server проверка адреса по умолчанию отключена! Её включение производится для протокола:

dhcp1 dhcp2

3

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

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

4

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

В случае, если клиент не получил ни одного ответа DHCPOFFER, после истечения таймаута посылается ещё один запрос DHCPDISCOVER.

5

Серверы принимают сообщение DHCPREQUEST от клиента. Все отброшенные серверы снимают блокировку с предложенного клиенту адреса. Выбранный клиентом сервер подтверждает сопоставление клиента в своей базе (закрепляет IP-адрес за клиентом) и посылает ему сообщение DHCPACK. Также в этом сообщении посылаются все запрошенные клиентом дополнительные параметры. Всё, что передаётся в сообщении DHCPACK должно не конфликтовать с ранее отправленным DHCPOFFER. Также в этой точке протокола сервер не должен проверять выдаваемый адрес на дублирование.

6

Если сервер не может удовлетворить запрос DHCPREQUEST (например, запрашиваемый IP-адрес уже занят), сервер должен послать сообщение DHCPNAK.

Сервер может пометить адрес, предложенный клиенту в сообщении DHCPOFFER как недоступный. Сервер должен пометить адрес, предложенный клиенту в сообщении DHCPOFFER как недоступный, если сервер не получил сообщение DHCPREQUEST от клиента.

7

Клиент получает пакет DHCPACK с конфигурационными параметрами. В этот момент хост должен провести финальную проверку дублирования адресов (ARP запрос) и в случае совпадения обязан послать сообщение DHCPDECLINE серверу и начать снова процесс конфигурации. Перед возобновлением процесса клиент должен выждать минимум 10 секунд чтобы не создавать излишнюю нагрузку на сеть в случае закольцовывания процесса.

Опять же клиент начинает процесс получения адреса с начала, если получает от сервера пакет DHCPNAK.

Если за определённое время (зависит от конкретной конфигурации) клиент не получает ни DHCPACK, ни DHCPNAK, он повторяет запрос DHCPREQUEST. После определённого (конфигурацией клиента) количества повторений DHCPREQUEST клиент должен оповестить пользователя от сбое процесса DHCP и начать с начала, послав широковещательный запрос DHCPDISCOVER.


Погружение в DHCP. Часть 2

Взаимоотношения с другими протоколами

Протокол DHCP задействует в своей работе следующие протоколы:

  1. RARP (Reverse Address Resolution Protocol). С помощью RARP DHCP-клиент проверяет, не занят ли предлагаемый DHCP-сервером адрес. Упрощенно работает это так: клиент делает широковещательный ARP запрос «кто здесь с адресом х.х.х.х?». Если в широковещательном домене (как правило — до маршрутизатора) присутствует хост с данным ip-адресом, то наш DHCP-клиент поймёт, что адрес занят и сообщит об этом DHCP-серверу.
  2. ICMP (Internet Control Message Protocol). DHCP-сервер использует одну из возможностей данного протокола — ping — для обнаружения занятости предлагаемого им адреса. Надо понимать, что на хосте (с нужным адресом) ICMP может быть закрыт файрволом, и данная проверка не пройдёт. В этом случае как раз и нужна проверка конечным клиентом через RARP. Но в реальности нередки случаи, когда пинг от DHCP-сервера не проходит (файрвол, настройки маршрутизации между сегментами сети), а клиент сеть опрашивать не стал (этим славятся многие производители железок вроде IP-телефонов). В результате — дубликат.
  3. BOOTP. Используется как транспортный механизм для передачи набора параметров.

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

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

  • обязан — участник протокола должен безальтернативно совершить некие действия
  • обязан не — участник протокола не имеет права совершать действие
  • должен — участник протокола должен произвести некое действие, но отсутствие деяния работу протокола не нарушит
  • должен не — участник протокола должен не делать действие, но в случае невыполнения требования работу протокола не нарушит
  • может — участник протокола волен совершить дополнительные действия
  • может не — участник протокола волен не совершать данное действие

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

  • сопоставление (bind) — привязка конкретного клиента к IP-адресу.
  • аренда (lease) — со стороны сервера запись в базе о том, что данный IP-адрес занят на определённое время (время аренды); со стороны клиента — набор сетевых параметров, переданных ему сервером + время аренды, в течение которого этим параметры считаются правильными.
  • DHCP relay, ретранслятор — агент (как правило, служба на маршрутизаторе), совершающий пересылку широковещательных запросов от клиента к серверу в другую подсеть.

Требования

Во время разработки протокола DHCP были поставлены и, страшно сказать, удовлетворены следующие требования:

  1. Протокол не должен собой подменять политики. Локальным администраторам оставляется возможность контролировать вручную любые параметры.
  2. Клиент не должен требовать ручного конфигурирования. Автоматическое конфигурирование сетевых параметров по умолчанию стоит в подавляющем большинстве операционных систем.
  3. Для всей сети не должно быть необходимости в конфигурировании каждого клиента.
  4. Для работы DHCP не требуется сервер в каждой подсети. Для прохождения протокола через маршрутизаторы используются ретрансляторы.
  5. DHCP клиент должен быть готов к приёму ответов от нескольких серверов.
  6. Настраиваемые через DHCP клиенты должны сосуществовать вместе с хостами, которым сетевые настройки даны статически.
  7. Сервер DHCP должен предоставлять сервис для существующих BOOTP клиентов (в 1997 году ещё было актуально).
  8. Гарантия того, что выданный адрес не дублируется в сети.
  9. Сохранение клиентом конфигурации после перезагрузки клиента.
  10. Сохранение клиентом конфигурации после перезагрузки сервера.
  11. Предоставление возможности автоматического назначения параметров новым клиентом без их ручной настройки.
  12. Поддержка постоянной или временной конфигурации для определённых клиентов.

Репозиторий и идентификатор

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

То есть как пример идентификатором может послужить следующее: 192.168.0.0|00-FF-1F-1B-BD-DB.

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

Динамическая выдача

Вторая функция сервера DHCP — динамически выдавать IP-адрес клиентам (и бонусом — другие параметры) на временной или постоянной основе. Упрощённо данная функция описывается так: клиент запрашивает у сервера адрес на некоторое время, а сервер этот адрес предоставляет, гарантируя при этом, что в течение определённого времени данный адрес больше никому выдаваться не будет.

Период, на который выдаётся адрес называется временем аренды. В течение этого времени клиент может:

  1. Попросить сервер продлить аренду.
  2. Информировать сервер, что адрес больше не нужен.
  3. Попросить сервер выделить данный адрес в постоянное пользование (бесконечная аренда).

Стоит пояснить, что последний вариант серверами практически не реализуется. Если клиент периодически запрашивает продление адреса (или не продление, а выдачу, а у сервера для данного клиента адрес стоит в «резерве»), серверу будет знать, что хост жив.


Погружение в DHCP. Часть 1

Дискляймер

Анализ Интернета говорит о том, что информации по DHCP на русском много, но она либо поверхностна, либо разрознена. Самым лучшим источником по протоколу является RFC 2131. Но, во-первых, это (хоть и небольшой) текст на английском, что является препятствием для чтения для многих сограждан, во-вторых, несмотря на то, что написан лёгким языком, картинок не содержит, только буквы. Как следствие — никто из моих знакомых данный документ не читал или в этом не признался.

Первая редакция протокола была опубликована в 1993 году, RFC 1541. В настоящий момент действует вторая версия от 1997 года.

Dynamic Host Configuration Protocol является продолжением и расширением протокола сообщений BOOTP (Boot Proto), изначально создававшегося для различных целей, например для загрузки бездисковых станций.

В данном тексте будет использоваться привычное для русскоязычного человека, словосочетание «протокол DHCP», являющееся по сути чистой тавтологией.

Введение

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

При помощи DHCP клиент может получить:

  • Джентельменский набор в виде IP-адреса, маски подсети, шлюза, DNS-серверов
  • Большой набор дополнительных параметров, например: серверы времени, адрес образа для автозагрузки, доменное имя клиента, адрес и предварительные настройки АТС (для IP-телефонов).

Использование протокола DHCP исключено для всех устройств, кому необходим постоянный адрес: серверы DHCP, контроллеры домена, DNS-серверы, management-адреса сетевого оборудования и некоторые другие. Во всех остальных случаях привязка к сервису должна осуществляться по FQDN (Fully Qualified Domain Name, полное доменное имя).

DHCP позволяет массово сменить настройки сети у всех клиентов. Самые частые возможные изменения: адреса серверов DNS, маска подсети (например, для расширения адресного пространства). Поскольку работа протокола связана с понятием времени аренды (lease time, период, в течение которого IP-адрес, а с ним и остальные сетевые параметры, считаются действующими), перед планируемым изменением передаваемых клиенту параметров необходимо снизить время аренды.

К примеру, на нашем сервере стоит стандартное время аренды в 8 дней. Это значит, что последние получившие аренду клиенты обратятся к DHCP-серверу только через 4 дня (половина времени аренды). Исключением будут те хосты, которые пройдут цикл перезагрузки или у которых будет зафиксировано отключение сети. Если мы сменим настройки на сервере, то в ближайшие 4 дня в инфраструктуре будет нарушена консистентность (целостность) настроек у клиентов. Те, кто общался с сервером недавно будут иметь другой набор данных, отличный от тех клиентов, что обращались к службе DHCP условных 3-4 дня назад. Поэтому правильный сценарий будет следующим:

  1. Определить текущее время аренды (например, 8 дней).
  2. Установить время аренды в короткий период, например, — 10 минут.
  3. Подождать до истечения половины времени изначальной аренды (в нашем случае 4 дня).
  4. Сменить настройки.
  5. Через 15-20 минут проверить, что у всех зарегистрировавшихся клиентов свежая аренда.
  6. Установить время аренды на 8 дней.

Правильное время аренды зависит в первую очередь от того, насколько в данной сети постоянны клиентские устройства. К примеру, для стандартной стабильной офисной сети с минимальной мобильностью, возможно установить время аренды в 1 месяц. Если основные клиенты нашей сети — мобильные устройства на WiFi, то нормальным срок аренды будет 6-8 часов. Стоит отметить, что DHCP-сервер не удаляет не истекшую по времени аренду, а значит в случае мобильных устройств при большом времени аренды, установленном для клиентов, будет образовываться куча «мёртвых душ», которые будут забивать область IP-адресов, предназначенную для выдачи клиентам. Распространённый случай: в подсети с маской /24 (254 адреса) около 50 активных клиентов, а свободных адресов для выдачи нет. В смешанных сетях (стационарные и мобильные клиенты, например, офис с WiFi точкой доступа) необходимо клиентов разделять по разным подсетям с различными сроками аренды.

Наконец, надо отметить, что служба сервера DHCP не является сколько либо требовательной к процессорному времени или памяти. Основная нагрузка может лечь на дисковую подсистему — как правило сервер много логирует.


Хинты №4. Массовое добавление записей в DNS

Бывает ситуация, когда необходимо добавить массу однотипных записей в DNS. При этом мало того, что имена хостов идут по шаблону, так ещё и IP-адреса подряд из одного пула. Если брать конкретно мою деятельность, то хорошим примером будет ввод в эксплуатацию блейд-сервера, где нужно завести два пула: адреса ESXi и управлялка серверами (iLO, AMM и т. д., нужное подчеркнуть).

Скрипт для PowerShell:

Принцип работы следующий. В переменную $startoct мы записываем то, с чего будет идти отсчет адресов с учетом шаблона адресов. В моём примере первый хост получит адрес 172.16.100.151, а последний, соответственно, 172.16.100.166.

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

Также скрипт не имеет защиты от дурака. То есть, если при стартовом адресе 201 поставить количество хостов в 60, то последние вывалятся в ошибку. Поэтому сначала планируем, потом запускаем.

Параллельно с A-записями создаются PTR-записи в зоне обратного просмотра. Чтобы не было ругани, нужно эту зону предварительно создать. Если обратные указатели не нужны, необходимо удалить «-CreatePtr» в третьей снизу строчке.

Последнее: в данном примере хосты будут именоваться «hostname-01», «hostname-02″…»hostname-15», «hostname-16». Для количества хостов больше 99 надо модифицировать скрипт. Формирование нулей слева можно автоматизировать, но у меня не было необходимости.


Хинты №3. Разрешение vMotion на виртуальном адаптере VMKernel

После подключения хостов к vCenter на стандартном адаптере VMkernel (а первоначальный адаптер будет называться vmk0) не разрешён vMotion. То есть виртуальные машины переезжать не смогут. Для этого его нужно включить.

Для единичного хоста это делается просто:

vmk0_1

vmk0_2

Если хостов много, используем PowerCLI:

 


Хинты №2. Удаление стандартных vSwitch

Я в своей работе пользуюсь исключительно распределёнными виртуальными свичами. Это упрощает настройку и минимизирует ошибки.

После добавления хостов к vCenter и применения Distributed vSwitch (распределённого свича) к хостам остаются пустые стандартные виртуальные свичи. Удалить их «одним махом» можно следующим образом:

 


Хинты №1. Массовое подключение хостов к vCenter

Стандартная ситуация: установили несколько новых серверов (в моём случае обычно партиями по 32 штуки — две полных blade-корзины), раскатали ESXi, и нужно подключить к vCenter. На вопрос, почему не пользуемся Auto Deploy отвечу при появлении самого вопроса.

Можно 32 раза сделать «Add Host», вбить логин и пароль, имя хоста, подтвердить сертификат и несколько раз тнуть «далее». Или так:

Все изменяемые параметры кроме имени сервера vCenter вынесены в переменные.