ГлавнаяРазноеRds windows server 2018 настройка

Установка и активация сервера лицензирования RDS на Windows Server 2016. Rds windows server 2018 настройка


Установка и активация сервера лицензирования RDS на Windows Server 2016

В это статье мы рассмотрим процесс установки, настройки и активации роли сервера терминальных лицензий (Remote Desktop Licensing) на базе Windows Server 2016, а также процедуру установки и активации клиентских терминальных (CAL).

Напомню, что после установки роли терминального сервера Remote Desktop Session Host, пользователи могут использовать его только в течении пробного периода 120 дней, после окончания которого возможность подключения к удаленному RDS серверу пропадает. Согласно схеме лицензирования Microsoft, все пользователи или устройства, использующие возможности RDS, должны быть лицензированы. Для учета и выдачи терминальных лицензий (RDS CAL) существует отдельная служба роли RDS под названием Remote Desktop License Server.

Установка роли Remote Desktop Licensing

Переда началом установки нужно добавить (или убедиться, что у вас есть право на добавление) нового сервера в доменную группу Terminal Server License Servers, иначе сервер не сможет выдать CAL типа RDS Per User пользователям домена.

Установить службу Remote Desktop Licensing можно через консоль Server Manager. Для этого в мастере Add Roles and Features выберите роль Remote Desktop Services.

В качестве компонента роли нужно выбрать службу Remote Desktop Licensing.

Осталось дождаться окончания установки роли.

Активация сервера лицензий RDS

Чтобы сервер лицензирования RDS мог выдавать лицензии клиентам, его необходимо активировать. Для этого, откройте консоль Remote Desktop Licensing Manager, щелкните ПКМ по имени вашего сервера и выберите пункт меню Activate Server.

Запустится мастер активации сервера, в котором нужно будет выбрать желаемый метод активации. Если ваш сервер имеет доступ в Интернет, он может автоматически подключиться к серверам Microsoft. Если доступа в интернет с сервера нет, можно активировать сервер через веб браузер или по телефону.

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

Осталось нажать кнопку Finish.

Теперь, если в консоли щелкнуть ПКМ по имени сервера и выбрать пункт Review Configuration, можно убедится что данный сервер сервер лицензий RDS является активированным и может быть использован для активации RDS клиентов в домене.

Типы клиентских терминальных лицензий (RDS CAL)

Каждый пользователь или устройство, которое подключается к серверам Remote Desktop Session должно иметь клиентскую лицензию (CAL — client access license). Есть два типа терминальных CAL.

  • На устройство (Per Device CAL) – это постоянный тип лицензии, назначающаяся компьютеру или устройству, которое подключается к RDS серверу более одного раза (при первом подключении устройства ему выдается временная лицензия). Данные лицензии не являются конкурентными, т.е. если у вас 10 лицензий Per Device, то к вашему RDS серверу смогут подключится всего 10 хостов.
  • На пользователя (Per User CAL) – такой тип лицензии позволяет одному пользователю подключаться к серверу RDS с любого количества компьютеров/устройств. Данный тип лицензий привязывается к пользователю Active Directory, но выдается не навсегда, а на определенный период времени (90 дней по-умолчанию).

Примечание. Отметим, что 2016 RDS CAL можно установить только на сервере лицензирования под управлением Windows Server 2016, установка новых CAL на предыдущие версии Windows Server на поддерживается.

Установка RDS CAL

Теперь на сервер лицензирования нужно установить приобретенный пакет терминальный лицензий (RDS CAL).

В консоли Remote Desktop Licensing Manager щелкните ПКМ по серверу и выберите Install Licenses.

Выберите способ активации (автоматически, через веб или по телефону) и программу лицензирования (в нашем случае Enterprise Agreement).

Следующие шаги мастера зависят от того, какой тип лицензирования выбран. В случае Enterprise Agreement нужно указать его номер. Если выбран тип лицензирования License Pack (Retail Purchase), нужно будет указать 25-символьный ключ продукта, полученный от Microsoft.

Тип продукта (Windows Server 2016), тип лицензии (RDS Per user CAL) и количество лицензий, которые нужно установить на сервере.

После этого, сервер может выдавать лицензии (RDS CAL) клиентам.

Настройка сервера лицензий на серверах RD Session Host

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

Чтобы выбрать, какой тип лицензий использовать, выполните команду:

$obj = gwmi -namespace "Root/CIMV2/TerminalServices" Win32_TerminalServiceSettingЗатем укажите желаемый тип лицензирования

$obj.ChangeMode(4)

Примечание. 4 указывается, если сервер должен использовать тип лицензирования Per User, 2 – если Per Device.

Теперь можно указать имя сервера лицензирования RDS:

$obj.SetSpecifiedLicenseServerList("rds-lic1.winitpro.ru")

И проверить настройки:

$obj.GetSpecifiedLicenseServerList()

При настройке через GPO, нужно создать новую GPO и назначить ее на OU с RDS серверами. Настройки лицензирования задаются в разделе:

Computer Configuration -> Policies -> Admin Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Licensing

В этом разделе имеется 2 интересующие нас политики:

  • Use the specified Remote Desktop license servers – задается адрес сервера лицензирования
  • Set the Remote Desktop licensing mode – выбор метода лицензирования

Проверить статус сервера лицензий и количество выданных лицензий можно с помощью консоли RD Licensing Diagnoser (Administrative Tools -> Remote Desktop Services -> RD Licensing Diagnoser).

Примечание. В нашем случае после указания нового сервера лицензирования, при подключении, на RDP клинте стала появляться ошибка «The remote session was disconnected because there are no Remote Desktop License Servers available to provide a license». Решение – удаление ключа L$RTMTIMEBOMB из реестра.

winitpro.ru

User Profile Disks в RDS Windows Server 2012 / 2016

User Profile Disks (UPD, диски профилей пользователей) – новый функционал Remote Desktop Services в Windows Server 2012. User Profile Disks представляют собой альтернативу использованию технологий перемещаемых профилей (roaming profile) и перенаправления папок (folder redirection) в терминальных сценариях RDS. Идея UPD – данные пользователя и его приложений (т.е. его профиль) хранятся в виде отдельного виртуального vhdx диска на неком выделенном общем файловом ресурсе. Этот виртуальный диск монтируется в сессию пользователя при его входе на RDS-сервер, и отключается при выходе (конечно, с сохранением всех изменений в профиле).

В этой статье мы опишем особенности настройки и работы технологии User Profile Disks на сервере с ролью Remote Desktop Services на Windows Server 2012 / 2012 R2 / 2016.

Настройка User Profile Disks в Windows Server RDS

В первую очередь необходимо на любом файловом сервере организации создать общую сетевую папку, в которой будут храниться файлы с профилями пользователей в формате VHDX дисков (если вы хотите обеспечить высокую доступность UPD дисков, можно разместить файлы UPD на кластерном файловом ресурсе). В нашем примере, путь к такому каталогу будет выглядеть так: \\srv01\DemoLabOficeApps. Необходимо предоставить серверам, входящим в коллекцию RDS полные права доступа на данный каталог и файловую систему.

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

Режим User Profile Disks включается и настраивается в параметрах коллекций Remote Desktop. Этот режим можно включить непосредственно при создании коллекции, или уже после того, как коллекция создана.

В нашем примере коллекция уже существует, поэтому в консоли Server Manager выбираем имеющуюся коллекцию, и в верхнем левом углу выбираем Tasks-> Edit Properties.

Затем в разделе User Profile Disks ставим чекбокс на Enable user profile disks, указываем путь к созданной ранее сетевой папке (\\srv01\DemoLabOficeApps) и максимальный размер диска с профилем (пусть это будет 20 Гб). Сохраняем изменения.

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

На уровне сетевой папки (шары) серверу RDSH01$ предоставлены права Full Control. При добавлении новых серверов RD Session Host в коллекцию RDS серверов, мастер автоматически изменит разрешения на каталог, предоставив доступ новым серверам. Это очень удобно, т.к. при масштабировании терминальной фермы не нужно каждый раз вспоминать о настройке разрешений на сетевую папку с профилями.

VHDX файл с UPD профилем пользователя

Перейдем в наш общий сетевой каталог с профилями пользователей. Теперь в нем хранится файл вида UVHD-template.vhdx.

Этот файл представляет собой шаблон диска с профилем пользователя. При первом RDP входе пользователя на сервер RDS, этот шаблон копируется и переименовывается в vhdx файл, содержащий в имени SID пользователя.

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

На стороне сервера RD Session Host .vhdx файл пользователя монтируется в каталог C:\users\<username> и выглядит таким образом:

Обратите внимание, что UPD диск привязан к версии Windows RDS сервера. Вы не сможете перенести UPD профиль пользователя с RDS сервера с одной версии Windows Server на другую.

Запись данных в файл vhdx ведется в реальном времени. Т.е. при копировании данных в профиль пользователя на сервере RDS, размер vhdx файла на общем хранилище увеличивается сразу.

В том случае, если в системе уже присутствует каталог с профилем пользователя, каталог со старым профилем переименовывается в формат <username>-BACKUP-<number>.

VHDX диск монтируется при старте сессии пользователя на VDI или RDS сервере. Список подключенных UPD дисков с профилями можно вывести с помощью утилиты mountvol.

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

Второй вариант позволяет настроить сохранение в UPD профиле только указанных каталогов.

В случае необходимости, второй вариант позволяет реализовать сценарии сохранения настроек стартового экрана, хранящихся в файле appsfolder.itemdata-ms. В данном примере мы просто добавили путь к каталогу \AppData\Local\Microsoft\Windows в качестве дополнительного пути, который нужно сохранять в UPD.

Как расширить диск User Profile Disk с помощью PowerShell

Вы можете расширить виртуальный vhdx диск с UPD профилем конкретного пользователя с помощью PowerShell командлета Resize-VirtualDisk из модуля Hyper-V.

Net use U: \\srv01\DemoLabOficeAppsResize-VHD -Path u:\UVHD-<SID>.vhdx -SizeBytes 30GBNet use U: /delete

Если вы используете командлет Resize-VHD с рабочей станцией под Windows 10, то в системе необходимо установить роль Hyper-V -> ПлатформаHyper-V -> Службы Hyper-V.

Теперь нужно расширить диск из графического интерфейса консоли Управления дисками (Disk Manager). Действие –> Подключить виртуальный жесткий диск -> Расширить том.

Либо воспользуйтесь таким PoSh скриптом:<#.SynopsisThis script extend size of VHDX file and resize the disk partition to Max#>Param([Parameter(Mandatory=$true,ValueFromPipeline=$true)][alias("Path")][string]$vhdxFile,[Parameter(Mandatory=$true,ValueFromPipeline=$true)][alias("Size")][int64]$vhdxNewSize)begin{try {Mount-VHD -Path $vhdxFile -ErrorAction Stop}catch {Write-Error "File $vhdxFile is busy"Break}$vhdx = Get-VHD -Path $vhdxFileif ($vhdx.Size -ge $vhdxNewSize){Write-Warning "File $vhdxFile already have this size!"$vhdx | Dismount-VHDBreak}}process{Dismount-VHD -Path $vhdxFileResize-VHD -Path $vhdxFile -SizeBytes $vhdxNewSize$vhdxxpart = Mount-VHD -Path $vhdxFile -NoDriveLetter -Passthru | Get-Disk | Get-Partition$partsize = $vhdxxpart | Get-PartitionSupportedSize$vhdxxpart | Resize-Partition -Size $partsize.SizeMax}end{Dismount-VHD -Path $vhdxFile}

Обратите внимание, что нельзя расширить UPD диск пользователя с активной RDS сессией.

Чтобы уменьшить размер файла UPD (при условии, что вы удалили данные пользователя внутри vhdx файла и размер файлов на диске меньше выделенного ему размера) можно воспользоваться командами:

resize-VHD \\srv01\DemoLabOficeApps\UVHD-<SID>.vhdx –ToMinimumSize

А затем:

Optimize-vhd -path \\srv01\DemoLabOficeApps\UVHD-<SID>.vhdx -mode full

Итак, мы рассмотрели основные особенности работы технологии User Profile Disks в RDS/VDI решениях на базе Windows Serer 2016 и 2012 R2. Настройка UPD намного проще чем процесс настройки перемещаемых профилей и перенаправляемых папок. Диски привязаны к коллекции RDS и не могут повредиться при попытке совместного использования профиля несколькими терминальными серверами (в отличии от обычных профилей). Диски профилей пользователей могут храниться на SMB шарах, CSV,  SOFS, в SAN или на локальных дисках. Также Microsoft отмечает, что скорость загрузки рабочей среды пользователя в случае использования UPD уменьшается.

Если вы планируете использовать для хранения UPD профилей DFS сервера, то имейте в виду, что на них должна использоваться Windows Server 2012 R2. При использовании предыдущих версий Windows Server вы получите ошибку:

Unable to enable user disks on rVHDShare. Could not create template VHD.  Error Message: The network location "\\winitpro.ru\namespace\UPD1" is not available.

Также на стороне файлового сервера желательно использовать версию SMB 3.02 (Windows Server 2012 R2) или выше.

В любом случае, т.к. технология User Profile Disks относительно свежая, рекомендуется перед крупными внедрениями UPD откатать их работу и возможные проблемы в тестовой среде.

winitpro.ru

Установка и активация сервера лицензирования RDS на Windows Server 2016

В это статье мы рассмотрим процесс установки, настройки и активации роли сервера терминальных лицензий (Remote Desktop Licensing) на базе Windows Server 2016, а также процедуру установки и активации клиентских терминальных (CAL).

Напомню, что после установки роли терминального сервера Remote Desktop Session Host, пользователи могут использовать его только в течении пробного периода 120 дней, после окончания которого возможность подключения к удаленному RDS серверу пропадает. Согласно схеме лицензирования Microsoft, все пользователи или устройства, использующие возможности RDS, должны быть лицензированы. Для учета и выдачи терминальных лицензий (RDS CAL) существует отдельная служба роли RDS под названием Remote Desktop License Server.

Установка роли Remote Desktop Licensing

Переда началом установки нужно добавить (или убедиться, что у вас есть право на добавление) нового сервера в доменную группу Terminal Server License Servers, иначе сервер не сможет выдать CAL типа RDS Per User пользователям домена.

Установить службу Remote Desktop Licensing можно через консоль Server Manager. Для этого в мастере Add Roles and Features выберите роль Remote Desktop Services.

В качестве компонента роли нужно выбрать службу Remote Desktop Licensing.

Осталось дождаться окончания установки роли.

Активация сервера лицензий RDS

Чтобы сервер лицензирования RDS мог выдавать лицензии клиентам, его необходимо активировать. Для этого, откройте консоль Remote Desktop Licensing Manager, щелкните ПКМ по имени вашего сервера и выберите пункт меню Activate Server.

Запустится мастер активации сервера, в котором нужно будет выбрать желаемый метод активации. Если ваш сервер имеет доступ в Интернет, он может автоматически подключиться к серверам Microsoft. Если доступа в интернет с сервера нет, можно активировать сервер через веб браузер или по телефону.

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

Осталось нажать кнопку Finish.

Теперь, если в консоли щелкнуть ПКМ по имени сервера и выбрать пункт Review Configuration, можно убедится что данный сервер сервер лицензий RDS является активированным и может быть использован для активации RDS клиентов в домене.

Типы клиентских терминальных лицензий (RDS CAL)

Каждый пользователь или устройство, которое подключается к серверам Remote Desktop Session должно иметь клиентскую лицензию (CAL — client access license). Есть два типа терминальных CAL.

  • На устройство (Per Device CAL) – это постоянный тип лицензии, назначающаяся компьютеру или устройству, которое подключается к RDS серверу более одного раза (при первом подключении устройства ему выдается временная лицензия). Данные лицензии не являются конкурентными, т.е. если у вас 10 лицензий Per Device, то к вашему RDS серверу смогут подключится всего 10 хостов.
  • На пользователя (Per User CAL) – такой тип лицензии позволяет одному пользователю подключаться к серверу RDS с любого количества компьютеров/устройств. Данный тип лицензий привязывается к пользователю Active Directory, но выдается не навсегда, а на определенный период времени (90 дней по-умолчанию).

Примечание. Отметим, что 2016 RDS CAL можно установить только на сервере лицензирования под управлением Windows Server 2016, установка новых CAL на предыдущие версии Windows Server на поддерживается.

Установка RDS CAL

Теперь на сервер лицензирования нужно установить приобретенный пакет терминальный лицензий (RDS CAL).

В консоли Remote Desktop Licensing Manager щелкните ПКМ по серверу и выберите Install Licenses.

Выберите способ активации (автоматически, через веб или по телефону) и программу лицензирования (в нашем случае Enterprise Agreement).

Следующие шаги мастера зависят от того, какой тип лицензирования выбран. В случае Enterprise Agreement нужно указать его номер. Если выбран тип лицензирования License Pack (Retail Purchase), нужно будет указать 25-символьный ключ продукта, полученный от Microsoft.

Тип продукта (Windows Server 2016), тип лицензии (RDS Per user CAL) и количество лицензий, которые нужно установить на сервере.

После этого, сервер может выдавать лицензии (RDS CAL) клиентам.

Настройка сервера лицензий на серверах RD Session Host

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

Чтобы выбрать, какой тип лицензий использовать, выполните команду:

$obj = gwmi -namespace "Root/CIMV2/TerminalServices" Win32_TerminalServiceSetting

Затем укажите желаемый тип лицензирования

$obj.ChangeMode(4)

Примечание. 4 указывается, если сервер должен использовать тип лицензирования Per User, 2 – если Per Device.

Теперь можно указать имя сервера лицензирования RDS:

$obj.SetSpecifiedLicenseServerList("rds-lic1.winitpro.ru")

И проверить настройки:

$obj.GetSpecifiedLicenseServerList()

При настройке через GPO, нужно создать новую GPO и назначить ее на OU с RDS серверами. Настройки лицензирования задаются в разделе:

Computer Configuration -> Policies -> Admin Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Licensing

В этом разделе имеется 2 интересующие нас политики:

  • Use the specified Remote Desktop license servers – задается адрес сервера лицензирования
  • Set the Remote Desktop licensing mode – выбор метода лицензирования

Проверить статус сервера лицензий и количество выданных лицензий можно с помощью консоли RD Licensing Diagnoser (Administrative Tools -> Remote Desktop Services -> RD Licensing Diagnoser).

Примечание. В нашем случае после указания нового сервера лицензирования, при подключении, на RDP клинте стала появляться ошибка «The remote session was disconnected because there are no Remote Desktop License Servers available to provide a license». Решение – удаление ключа L$RTMTIMEBOMB из реестра.

bga68.livejournal.com

RDS на основе сеансов в Windows Server 2012 R2 | IT блоги

БЫСТРОЕ РАЗВЁРТЫВАНИЕ В ДОМЕНЕ

Перед тем, как начать установку RDS на сервер необходимо ознакомиться с существующей инфраструктурой сети. В данном случае, это тестовая сеть, состоящая из контроллера домена DC1 со статическим адресом 172.16.7.1/24, сервера на который будут установлены службы  RDS — RAPP, с адресом 172.16.7.2/24 и рабочих станций WS101, WS102, WS103, получающих IP-адреса по DHCP. Все компьютеры сети подключены к домену domain.local

На сервере RAPP необходимо открыть Диспетчер серверов. Для этого можно нажать на соответствующую иконку на панели задач или выполнить команду servermanager.exe В окне диспетчера выбираем Управление —Добавить роли и компоненты, после чего откроется окно мастера добавления ролей и компонентов. В первом его окне предлагается ознакомиться с основными требованиями к серверам, на которые будут устанавливаться роли. Также здесь можно установить галочку, которая позволит пропускать эту информацию при добавлении новых компонентов и ролей. При частой установке бывает полезно её установить. Прочитав информацию нажимаем Далее.

В следующем окне предлагается выбрать тип установки. Отмечаем пунктУстановка служб удалённых рабочих столов.

Так как мы производим установку всех служб RDS на один сервер, то целесообразно в следующем окне мастера выбрать Быстрый запуск.

Далее выбираем сценарий развертывания RDS. Нас интересует создание среды удалённых рабочих столов на основе сеансов. Поэтому выбираем соответствующую опцию и жмём Далее.

В следующем окне мастера предлагается выбрать сервер, на котором будут развернуты службы RDS. В нашем случае это сервер RAPP.domain.local. После того, как выбор сделан, жмём Далее.

 

После выбора сервера мы увидим окно с подтверждением выбранных служб и именем сервера, на который будут установлены эти службы. Тут же необходимо согласиться с тем, что сервер будет перезагружен, поставив соответствующую галочку и нажать кнопку Развернуть, после чего откроется окно в котором будет отображен процесс развёртывания ролей RDS. В процессе выполнения установки сервер будет перезагружен. После перезагрузки сервера, необходимо зайти под той же учётной записью, под которой был начат процесс установки (в данном случае это domain\dcadmin) и спустя некоторое время откроется окно мастера и развёртывание возобновится автоматически.

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

Когда мастер завершит развёртывание RDS, можно будет посмотреть какие роли установлены. Для этого заходим в диспетчер серверов и выбираем в левой панели пункт Службы удалённых рабочих столов. На вкладке Общие сведения мы можем увидеть, что сервер RAPP в данном развёртывании будет выступать в роли посредника подключений к удалённому рабочему столу, узла сеансов удалённых рабочих столов и узла веб-доступа к удалённым рабочим столам.

Так же мы видим, что кроме этих служб была установлена коллекция QuickSessionCollection в которую входят несколько стандартных приложений RemoteApp, а именно Paint, WordPad и Калькулятор.

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

Проверим работу веб-доступа к удалённым приложениям. Для этого перейдем по ссылке, которую мы получили в процессе работы мастера установки ролей и компонентов —  https://rapp.domain.local/rdweb

Как видим, подключение удалось. Это значит, что все роли служб удалённых рабочих столов настроены корректно и могут обслуживать клиентов. Единственное что осталось сделать, перед тем как давать доступ для клиентов — это установить службу лицензирования, но об этом далее в этой статье.

Следует помнить, что в доменной среде пользователей не обязательно добавлять в группу «Пользователи удалённого рабочего стола» т.к. при развёртывании RDS в эту группу автоматически добавляется группа «Пользователи домена».

Стандартное развёртывание

Как уже говорилось выше, стандартное развёртывание обеспечивает более гибкую установку служб удалённых рабочих столов, что позволяет разносить отдельные службы RDS на отдельные серверы инфраструктуры.

Теперь рассмотрим случай посложнее и поинтереснее — необходимо развернуть службы удалённых рабочих столов таким образом, чтобы посредник подключений к удалённому рабочему столу, узел веб-доступа и узлы сеансов располагались на разных серверах. Таким образом, ферма серверов RDS будет располагаться на четырёх серверах:

  • RDCB — сервер, выступающий в роли посредника подключений. Имеет адрес 172.16.7.2/24
  • RDWH — сервер, выступающий в роли узла веб-доступа к службе удалённых рабочих столов. Его адрес — 172.16.7.3/24
  • RDSh2, RDSh3 — серверы, выступающие в роли узлов сеансов. Имеют адреса, соответственно 172.16.7.4/24 и 172.16.7.5/24

Компьютеры WS101, WS102, WS103 — это рабочие станции, с которых осуществляется доступ к ресурсам серверов RDS. Их сетевые интерфейсы конфигурируются с помощью протокола DHCP.

Прежде чем приступать непосредственно к развёртыванию служб RDS, необходимо выполнить некоторый минимум подготовительный действий. А именно, на сервере, с которого будем проводить установку, откроем Диспетчер серверов и добавим в него все необходимые нам сервера. В данном случае в диспетчер серверов на RDCB добавим сервера RDWH, RDSh2 и RDSh3. Сделать это можно зайдя в пункт Управление и выбрав там опцию Добавление серверов.

После того, как все необходимые для развёртывания серверы добавлены, можно приступить непосредственно к установке служб удалённых рабочих столов. Следует отметить, что сама процедура во многом схожа с процедурой рассмотренной ранее, поэтому некоторые шаги мастера добавления ролей и компонентов будут повторяться. Итак, запустим сам мастер. Это можно сделать, выбрав пункт Управление — Добавить роли и компоненты. На первом шаге мастера предлагается выбрать тип установки. Нам необходимо развернуть службы

RDS, поэтому отмечаем Установка служб удалённых рабочих столов и жмём Далее.Далее мастер предложит варианты развёртывания RDS. Нас интересуетстандартное развёртывание. Выбираем соответствующий пункт и жмём Далее.

В следующем окне мастера выбираем пункт Развёртывание рабочих столов на основе сеансов.

Далее мастер отобразит окно, которое вкратце ознакомит нас со всеми службами ролей RDS и сообщит от имени какого пользователя будет производиться процедура установки.

На трёх последующих вкладках следует указать серверы, на которые будут установлены соответствующие роли. В нашем случае роль посредника подключений установим на сервер RDCB, роль узла веб-доступа — на сервер с именем RDWH, роли узлов сеансов — на серверы RDSh2 и RDSh3.

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

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

Проверить работоспособность развёрнутой конфигурации можно зайдя на страницу веб-доступа (https://rdwh.domain.local/rdweb) с одной из рабочих станций.

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

СЕРВЕР ЛИЦЕНЗИРОВАНИЯ

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

Для этого, запустим Диспетчер серверов, если он не запущен, и перейдём вконсоль управления удалёнными рабочими столами, кликнув на соответственную ссылку слева. Для запуска необходимого мастера кликнем на зелёную кнопку с плюсом и подписью Лицензирование удалённых рабочих столов на панели Обзор развёртывания.

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

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

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

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

К этим же свойствам можно получить доступ и после завершения установки. Для этого нужно на панели Обзор развёртывания выбрать пункт Свойства, а затем Изменить развёртывание.

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

Далее мы можем развернуть удаленные приложения RemoteApp на этом RDS

Смотрите также:

adminotes.ru

RDS в Windows Server 2016

RDS в Windows Server 2016

Дата публикации: 26.04.2017

Как вы помните, долгожданный релиз Windows Server 2016 состоялся, и мы продолжаем рассматривать самые главные нововведения этого продукта. Речь сегодня пойдет об одной из наиболее востребованных ролей – службе удаленных рабочих столов, или RDS (Remote Desktop Services).

Прежде чем погружаться в мир нового, рекомендуем ознакомиться со списком тех возможностей, которые появились в прошлой версии RDS – в Windows Server 2012 R2. Следом стоит посмотреть на список нововведений RDS в Windows Server 2016. Давайте рассмотрим, как новые возможности RDS в Windows Server 2016 расширяют возможности по построению терминальных ферм, VDI сред и сервисов доставки приложений на различные типы устройств.

Улучшения RemoteFX

В Windows Server 2012 R2 RemoteFX-адаптер имел ряд ограничений: 256 MB максимальный объем выделенной VRAM, поддержка только DirectX 11.1 и программного OpenGL 1.1, отсутствие поддержки OpenCL. Всё это сказывается на поддерживаемом количестве мониторов, разрешении и адекватной работе новых графических приложений (к примеру, Autocad Re-Cap требует OpenGL 3.3 и 1 GB VRAM, Photoshop CC — OpenGL 2.0 и 512 MB VRAM как минимум).

Windows Server 2016 призван решить данные проблемы и вносит ряд изменений в RemoteFX:

  • Возможность выделения до 1 GB VRAM. Виртуальные машины Hyper-V могут использовать до 1 GB выделенной VRAM + увеличивать количество VRAM за счет системной памяти ВМ, получая до 2 GB VRAM, в зависимости от величины имеющейся у виртуальной машины памяти.
  • Кроме того, динамическое определение объема VRAM на основе количества мониторов и разрешения заменяется возможностью задания конкретного значения VRAM для каждой ВМ вне зависимости от максимального количества мониторов и разрешения.

       

 

  • Поддержка OpenGL 4.4 и OpenCL 1.1. Как итог имеем «карт-бланш» на использование современных графических приложений.
  • Поддержка RemoteFX внутри виртуальных машин с Windows Server 2016. Ранее RemoteFX работал только с клиентскими версиями ОС (Windows 7/8). Это небольшое изменение (наряду с Personal session desktops, о которых мы поговорим чуть позже) значительно упрощает жизнь сервис-провайдерам, которые хотят предоставлять решения VDI с графическим ускорением своим заказчиком.

Параметры RemoteFX определяются как через GUI, так и через PowerShell.

Set-VMRemoteFx3dVideoAdapter

Set-VMRemoteFx3dVideoAdapter [-VM] []> [[-MonitorCount] ][[-MaximumResolution] ]

[[-VRAMSizeBytes] ][-Passthru][-WhatIf][-Confirm]  []

 

Новые клиенты RDS

Еще недавно у Microsoft не было ни одного мобильного клиента для доступа к удаленным рабочим столам, и приходилось использовать платные решения сторонних производителей с поддержкой RD Gateway. Однако по мере продвижения и использования RDS-решений были выпущены и добавлены следующие клиенты:

Клиент RDP (MSTSC.EXE) был обновлен до 10-й версии, которая имеет улучшенную поддержку кодека AVC/H.264 и режима AVC 444, призванного улучшить fps, понизить потерю цветности за счет использования функций аппаратного декодера H.264 в высоких разрешениях вплоть до 4K (GPU должен иметь поддержку DirectX 11.0, H.264 декодер Level 4.1/BT.709). Пока только в рамках полноценного клиента, но планируется добавить поддержку и для мобильных клиентов, обозначенных выше. Режим AVC444 используется по умолчанию в RemoteFX, но есть возможность использования AVC444 и в других сценариях с помощью настройки групповой политики:

Сomputer Configuration/Administrative Templates/Windows Components/Remote Desktop Session Host/Remote Session Environment:Prioritize H.264/AVC 444 Graphics mode for Remote Desktop connectionsиConfigure H.264/AVC hardware encoding for Remote Desktop connections.

Оптимизированный Connection Broker

Посредник подключений был узким местом при одновременных попытках подключений (logon storm) в Windows Server 2012/2012 R2. Поэтому в Windows Server 2016 была значительно улучшена производительность Connection Broker для требуемой нагрузки во время logon storms и при добавлении или перезагрузке узлов сессий в рамках большой rds-фермы (кстати, есть отдельный KB и для Windows Server 2012 R2, улучшающий производительность Connection Broker в подобных сценариях). Эти улучшения позволяют поддерживать до 10K+ одновременных запросов на подключение.

Для HA-конфигурации требуется выделенный внешний SQL Server. В Windows Server 2016 включена поддержка использования Azure SQL Database в качестве конечной точки размещения конфигурации Connection Broker в высокодоступном режиме.

Поддержка виртуальных машин второго поколения

Виртуальные машины Hyper-V второго поколения (Generation 2) стали доступны еще в Windows Server 2012 R2, но их использование в рамках RDS/VDI (и не только) откладывалось. Например, возможность создания шаблонов сервисов VMM на базе Gen2 была добавлена только в рамках UR6. В Windows Server 2016 мы можем задействовать оба поколения для использования в различных типах коллекций (personal/pooled или personal session). Дополнительная конфигурация не требуется.

Поддержка пера и браузера Microsoft Edge

Если ваше устройство, например планшет Microsoft Surface, поддерживает работу с пером, а локальная система не ниже Windows 10, то вы можете использовать перо в рамках RDP-сессии.

В Windows Server 2012/2012 R2 подобные устройства также работали, но по сути просто эмулировали обычную мышь – нажатия пера передвигали курсор на экране. В рамках Windows Server 2016 и Windows 10 стилусом можно рисовать или писать, открыв, например, граффити-приложение в браузере Microsoft Edge, который так же обзавелся поддержкой при работе в удаленной сессии.

Personal Session Desktops

Если Вы сервис-провайдер и хотите предоставить полноценный «десктоп» своим клиентам, то при реализации классического сценария VDI в рамках SPLA вы можете столкнуться с проблемой – в рамках SPLA недоступна клиентская версия Windows (7, 8, 10).

Для обхода подобных ограничений, как правило, строится система на базе классических терминальных решений c Windows Server (Session-based архитектура, конечно, с Desktop Experience на борту) и отдается на «растерзание» клиентам или пользователям.

В Windows Server 2016 решили это дело упростить и добавить метод привязки пользователей к конкретным терминальным узлам (в рамках RDS это узлы Remote Desktop Session Host, RDSH). В итоге получаем новый вид RDS-коллекции — Personal Session Desktops (PSD), или частные рабочие столы на базе терминальных сессий. Очевидно, что можно провести аналогию с Personal Virtual Desktops в VDI, предназначенными так же для выделения «изолированной» среды пользователям.

Давайте посмотрим на пару сценариев, которые успешно решаются благодаря PSD.

  • Если пользователю для работы требуется, чтобы ОС имела все возможности и внешний вид «как у клиентской» (к примеру, Windows 10), то полноценной заменой его рабочего стола будут PSD на базе Windows Server 2016 with Desktop Experience, которые позволяют добиться внешнего вида интерфейса Windows Server близкого к обычной клиентской ОС.
  • Если пользователь имеет административные полномочия на своем привычном ПК и вы хотите перевести его на PSD, то это возможно сделать путем добавления пользователя в группу локальных администраторов (определяется на этапе развертывания PSD, «ручной труд» не требуется).
  • Если пользователь не видит свою дальнейшую жизнь без графических приложений, требующих дополнительных аппаратных ресурсов, то можно предоставить PSD с обновленными возможностями RemoteFX (об этом уже упоминалось выше).

На текущий момент единственный способ развернуть PSD – PowerShell. Опцию GUI планируют добавить позже.

Для целей демонстраций и тестирования можно использовать тип развертывания Quick Start на базе сессий. При этом будут установлены RD Connection Broker, RD Web Access и RD Session Host на одном физическом сервере. Для реального использования рекомендуется сформировать распределенную архитектуру. Не забываем, что каждый компонент RDS поддерживает виртуализацию (к примеру, 1 VM RDSH <-> 1 PSD User) и высокую доступность (например, RD Connection Broker имеет высокодоступную конфигурацию).

На всякий случай привожу шаги по конфигурации «фундамента».

 

Переходим к созданию коллекции PSD. New-RDSessionCollection был дополнен свитчем -PersonalUnmanaged, который используется для создания коллекции типа Personal Session Desktop.

#Переменная для имени RDSH

$rdshost="tp4-root.democorp.ru" 

 

 

#Создание PSD-коллекции с административными привилегиями для пользователя

New-RDSessionCollection -CollectionName Personal -ConnectionBroker $rdshost -SessionHost $rdshost -GrantAdministrativePrivilege -PersonalUnmanaged

 

 

#Привязка пользователя rdsuser к коллекции PSD с именем Personal

Set-RDPersonalSessionDesktopAssignment -CollectionName Personal -User democorp\rdsuser -Name $rdshost

 

 

#Проверяем

Get-RDPersonalSessionDesktopAssignment -CollectionName Personal

CollectionName DesktopName User

-------------- ----------- ----

Personal TP4-ROOT.DEMOCORP.RU DEMOCORP\rdsuser

 

Если RDSH уже находится в одной из PSD-коллекций, то на его основе нельзя создать новую коллекцию. Только после удаления данного RDSH из текущей коллекции появится возможность определить его в новую.

New-RDSessionCollection -CollectionName Personal -ConnectionBroker $rdshost -SessionHost $rdshost -GrantAdministrativePrivilege -PersonalUnmanaged

WARNING: The RD Session Host server tp4-root.democorp.ru already exists in another collection.

New-RDSessionCollection : Unable to create the session collection.

 

 

#Выводим список коллекций

Get-RDSessionCollection

CollectionName Size ResourceType CollectionType CollectionDescription

-------------- ---- ------------ -------------- ---------------------

QuickSessionCollection 1 RemoteApp programs PooledUnmanaged

 

 

#Удаляем коллекцию 

Get-RDSessionCollection|Remove-RDSessionCollection

После создания коллекции PSD и привязки к ней пользователя перейдем в узел RD Web Access (https://hostfqdn/rdweb) для дополнительной проверки, используя учетные данные нашего пользователя. Должен появиться список коллекций, доступных пользователю.

 

Отмечу, что в привычном для администратора списке коллекций (Server Manager –> RDS –> Collection List) данный вид коллекций не отображается, поскольку он создается и управляется только с помощью PowerShell.

Вот такой вид имеет панель «Пуск» в сессии PSD:

 

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

 

Но на этом важные нововведения RDS в Windows Server 2016 не заканчиваются. Двигаемся дальше.

Интегрированные Windows MultiPoint Services

MultiPoint-сервер (MPS) является технологией и решением на базе Windows Server и служб RDS для предоставления базовой функциональности удаленных рабочих столов. Позиционируется для использования в учебных классах или учреждениях, где нет больших требований к нагрузке и масштабируемости. Особенность заключается в том, что пользовательские станции могут состоять только из монитора, клавиатуры и мыши («нулевые» клиенты) и подключаться непосредственно к серверу MPS через USB-хабы, видеокабели или LAN (RDP-over-LAN, если клиентом является, к примеру, ноутбук или тонкий клиент). В итоге конечный потребитель получает решение low-cost для предоставления функциональности рабочих столов с абсолютно минимальными затратами на пользовательские конечные станции.

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

Привычная нам всем возможность подключения через RDP была добавлена только в следующей версии MPS 2011, релиз которой состоялся в марте 2011. Помимо RDP-over-LAN, MPS 2011 обновился следующим образом:

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

В следующей и на данный момент последней версии MPS 2012 были добавлены:

  • Новая консоль для централизованного управления столами.
  • Защита системного раздела от нежелательных изменений.
  • Клиент MPS Connector для мониторинга и управления станций, включая планшеты.

Как уже было сказано выше, MPS поддерживает не только классический RDP, но и дает возможность подключать «нулевые» клиенты (примером может служить Wyse 1000) следующими способами.

Прямое подключение к видеокарте головной станции

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

Подключение через USB

На рисунке ниже показано взаимодействие первичной станции (станция, которая подключена напрямую к MPS и используется для первичной конфигурации вне зависимости от сценария) и двух «нулевых» клиентов, подключенных через USB-хабы (пример: Wise 1000). В отличии от первого способа, нам не нужно дополнительно рассчитывать конфигурацию видеоподсистемы сервера MPS для формирования требуемого количества видеовыходов. Но из-за ограничения по расстоянию между станциями и MPS (для Dell Wise 1000 ~ 5 метров) рекомендуется использовать в малых комнатах при небольшом количестве конечных пользователей.

Использование USB-Over-Ethernet

Более масштабируемый тип подключения. Вместо USB-to-USB используется проброс USB через LAN, тем самым предоставляется возможность построения системы MPS в больших по размеру помещениях (пример клиента: Wise 1003).

Описанная выше функциональность полностью перенесена в Windows Server 2016. MultiPoint Services теперь являются новым типом развертывания служб RDS.  

Опытным инженерам или администраторам, которые уже знакомы с процедурой конфигурации RDS в рамках решений VDI или Session-Based, процесс настройки и использования MPS покажется более простым и быстрым. Это тоже является плюсом, если учитывать целевую аудиторию MPS.

Существует три способа установить MultiPoint Services: через Server Manager (role-based), Powershell и через RDS Installation.

Бегло пройдемся по первым двум и потом перейдем к процессу базовой настройки MPS.

  1. Используя Server Manager и установку ролей, выберите MultiPoint Services, согласитесь с установкой дополнительных компонентов и перейдите к следующему шагу. 
  2. Можно почитать еще раз, что такое MPS. Стоит отметить, что RD Licensing нужно будет активировать после конфигурации MPS. 
  3. Вместе с основной службой MPS дополнительно разворачиваются службы Print and Document Services, предназначение которых всем, я надеюсь, известно. Ничего интересного, идем далее. 
  4. Оставляем все по умолчанию.
    • Print Server — необходим для управления «множеством» принтеров.
    • Distributed Scan Server — управление и предоставление доступа к сканерам, поддерживающим Distributed Scan Management.
    • Internet Printing — веб-доступ к printer jobs с возможностью отправки документов на печать через Internet Printing Protocol.
    • LPD Service — служба Line Printer Daemon предоставляет возможность UNIX-клиентам, используя службу Line Printer Remote, отправлять задачи на печать доступным принтерам.
  5. Полноценный RDS нам не нужен, поэтому оставляем предлагаемые по умолчанию значения. 
  6. После подтверждения сервер отправится на перезагрузку и, используя первичную станцию, необходимо будет произвести требуемую конфигурацию при первом старте MPS. В момент запуска будет предложено произвести идентификацию первичной станции (путем нажатия клавиши “B”), после чего сервер перейдет в режим конфигурации служб RDS/MPS.

MPS добавит учетную запись WmsShell для поддержки работы в режиме multi-station и создаст группу WmsOperators для формирования доступа к консоли управления (Dashboard).

Все шесть пунктов можно “сжать” до одной команды в PowerShell:

Перейдем в диспетчер управления MPS (MPS Manager):

Со своей удаленной станции я хочу настроить доступ к MPS через RDP-over-LAN. Для этого добавим новую учетную запись пользователя MPS:

С точки зрения MPS существует три вида пользователей: стандартный пользователь для доступа к MPS, пользователь для управления пользовательскими сессиями и администратор. По сути, это имитация полноценного RBAC (Role Based Access Control).

 Итак, пользователь добавлен. Проверим подключение. Используя MSTSC и возможности RDP, я подключаюсь к серверу MPS с помощью вышеобозначенной учетной записи. При первом подключении каждого пользователя к MPS будет выведено сообщение: «To assist you with your usage of this computer, your activities may be monitored by your system administrator/Для помощи в использовании данного компьютера ваши действия будут отслеживаться системным администратором».

После подтверждения будет создана новая терминальная сессия для пользователя, при этом администратор сможет управлять пользовательской сессией в интерактивном режиме, используя консоль MultiPoint Dashboard.

Перейдем к MultiPoint Dashboard (отдельная консоль). Основную часть консоли будут занимать динамически меняющиеся мини-экраны пользовательских сессий. Мне это чем-то напоминает экран службы безопасности для мониторинга видеосигналов с камер, но MultiPoint Dashboard позволяет нам не только наблюдать за тем, что происходит в пользовательских сессиях, но и реально управлять и изменять их (забирать управление, блокировать станции или инициировать log off, отправлять IM выбранным пользователям, блокировать USB-устройства или удаленно запускать/закрывать приложения).

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

  • разблокировать/заблокировать станцию и вывести на экран конкретной станции сообщение; 
  • ограничить веб-доступ путем определения списка разрешенных или запрещенных URLs; 
  • проецировать свой рабочий стол на клиентские станции;

Если вернуться обратно в MPS Manager, то можно увидеть, что подключенная станция отображается во вкладе Stations, где можно дополнительно управлять выбранными станциями.

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

Режим Multi-Session несет некоторые риски, связанные с безопасностью, поэтому предоставляется возможность защитить системный диск от нежелательных изменений. Для включения функции Disk Protection достаточно одно клика и подтверждения.

Если имеется приложение, которое требует клиентскую среду, в некоторых случаях изолированную, то в MPS это достигается за счет включения Virtual Desktops. Принцип работы схож с pooled-коллекцией в полноценном VDI. Каждая «виртуализованная станция» будет создаваться из шаблона и делать откат изменений после каждого выхода пользователя из системы. Как видим, полноценной функциональности VDI не достигается, но все же само наличие подобной возможности расширяет область применения MPS.

Выводы

Обновленные RemoteFX и RDP с поддержкой разрешения 4K увеличивают отдачу от ВМ с «тяжелыми» приложениями в рамках VDI и повышают их быстродействие по сравнению с Windows Server 2012/2012 R2 (конечно, необходимо провести тестирование и взглянуть на реальные цифры).

MultiPoint Server, переехавший «под крыло» RDS, расширяет область применения удаленных рабочих столов и делает более привлекательным их использование (интерактивность в dashboard, простота настройки играют в этом не последнюю роль). Помимо стандартных учебных классов, MPS может применяться так же и партнерами для обеспечения демостендов или шоу-румов независимыми тренерами и другими профессионалами, целью которых является грамотно донести информацию до слушателей или заказчиков.

Personal Session Desktop (PSD) упрощает для сервис-провайдеров предоставление рабочих столов в рамках DaaS-услуги и расширяет возможности RDS в Azure.

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

P.S. Если вы планируете переход на новый RDS или настраиваете новую ферму, то полезным будет данный постер, показывающий основные зависимости между сервисами.

Автор статьи: Роман Левченко ( www.rlevchenko.com), MVP – Cloud and Datacenter Management

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

technet.microsoft.com

Настройка стартового экрана RDS в Windows Server 2012

Как вы, вероятно, помните, в Windows 8 полностью отсутствует меню Пуск (Start Menu), функционал которого заменен новым плиточным интерфейсом под названием стартовый экран (Modern UI Start Screen). Этот факт касается и серверной платформы — Windows Server 2012. Это означает, что при входе терминального пользователя на сервер Windows 2012 с ролью   сервера терминалов  (RD Session Host) с установленной функцией «Desktop experience”, пользователю отображается не привычный рабочий стол сервера, а начальный экран Start Screen .

Соответственно, у администраторов терминальных служб появляются вопросы по настройке и управлению этим самым стартовым меню. В Windows Server 2008 R2 управление содержим меню Start осуществлялось (способ, рекомендуемый в best practice) путем перенаправления меню Start с помощью групповой политики в некую общую папку с ярлыками приложений, в которой отображение того или иного ярлыка определялось путем назначением на него NTFS прав и активного режима Access Based Enumeration. Что будет, если применить данную политику (User Configuration -> Windows Settings -> Folder Redirection -> Start Menu) к серверу с Windows 2012 RDS?

В Windows 2012 Remote Desktop при первом входе пользователя на «рабочий стол» терминального сервера он видит полностью пустой Start Screen:

Дело в том, что Start Screen просто не воспринимает политики перенаправления папки стартового меню (Start Menu),  которое использовалось в Windows Server 2008 R2. Ведь по новой концепции Microsoft это не одно и то же. Вместо этого данная политика перенаправляет меню All Apps в указанный в политике каталог.

Чтобы получить доступ к списку установленных программ, щелкните правой клавишей по начальному экрану (или нажмите комбинацию клавиш CTRL-TAB.

В меню All Apps отобразится список ярлыков  приложений, к которым у пользователя есть доступ (если на общем каталоге с ярлыками активна ABE и назначены NTFS права).

Из данного меню пользователь может вынести нужные ему ярлыки на начальный экран, щелкнув правой клавишей по ярлыку и выбрав пункт Pin to Start.

Таким образом, терминальный пользователь может настроить собственный начальный экран Metro UI (ака рабочий стол). Естественно, если данную операцию придется выполнять каждому пользователю сервера терминалов – это вызовет определённые проблемы и неудобства. Попробуем разобраться, можно ли экспортировать настройки стартового экрана у пользователя и групповой политикой назначить их всем остальным пользователям терминального сервера.

В Windows Server 2012 настройки стартового экрана хранятся в файле appsfolder.itemdata-ms, находящимся в каталоге %userprofile% \Default\appdata\local\microsoft\windows\appsfolder.itemdata-ms. Данный файл необходимо скопировать из профиля текущего пользователя и скопировать его в каталог C:\Users\Default\appdata\local\microsoft\windows\appsfolder.itemdata-ms. В этом случае все пользователи при первом входе на терминал получили бы новый профиль с настроенными ярлыками StartScreen.

Примечание.Есть небольшой нюанс, файл appsfolder.itemdata-ms – доступен только для чтения, и для того, чтобы пользователи могли редактировать свой стартовый экран, необходимо сменить его атрибуты. Проще всего это сделать с помощью политик Group Policy Preferences.

Согласитесь, получается не очень гибкая конфигурация. К счастью в релизе Windows Server 2012 R2 (и Windows 8.1) появится новая возможность экспорта конфигурации Start Screen.

Текущие настройки стартового экрана Start Screen пользователя можно выгрузить в XML файл с помощью команды Powershell export-startlayout

export-startlayout -as xml -path \\mskfs01\startscreen

В дальнейшем данный файл можно скопировать в общий каталог и распространить с помощью групповой политики Start Screen Layout, находящейся в разделе User Configuration  -> Policies  -> Administrative Templates -> Start Menu and Taskbar. В данной политике нужно задать путь к сохраненному xml файлу, задающему настройки Start screen.

Подробнее о возможностях и особенностях экспорта/импорта макета стартового экрана в статье: Управление конфигурацией плиточного стартового экрана в Windows 8.1

winitpro.ru

Лицензирование RDS Windows Server 2012

Настраивая RDS для сотрудников на базе Windows Server 2012 я столкнулся с небольшой проблемой лицензирования.

Общая схема RDS в моем случае такова (т.к. пользователей RDS будет не более 5, обеспечивать отказоустойчивость слишком дорого):

После настройки ролей (которая прошла до неприличного просто), я добавил роль лицензирования RDS на том же сервере, активировал его, опубликовал в AD и добавил лицензии:

Но средство диагностики все равно ругалось:

Что ж, решить эту проблему достаточно просто, достаточно обратиться к Локальной политике (gpedit.msc) и в разделе “Конфигурация компьютера” – “Административные шаблоны” – “Компоненты Windows” – “Службы удаленных рабочих столов” – “Узел сеансов удаленных рабочих столов” – “Лицензирование” внести информацию о сервере и режиме лицензирования :

Конечно, предложенный вариант не дает ответа на вопрос почему “пинать” пришлось вручную, но с другой стороны, развертывание RDS в Windows Server 2012 настолько упростилось, что сейчас мне хочется посмотреть на новое в RemoteApp , а не ковырять скучное лицензирование 🙂

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

 

UPD2: Похоже я увидел где настраивается лицензирование в новом интерфейсе:

 

… но увы эти настройки в моем случае не сработали, и я вынужден вернуться на GP. А было так близко =/

it-community.in.ua