Ранее мы рассматривали пример построения фермы Remote Desktop Connection Broker (RDCB) на базе Windows Server 2008 R2. С выходом Windows Server 2012 технологии повышения доступности для служб RDS претерпели определённые изменения, в частности теперь для построения отказоустойчивой фермы RDCB не используются механизмы Windows Failover Cluster. В этой заметке мы попробуем рассмотреть процедуру создания новой фермы RDCB на базе Windows Server 2012 с применением Windows NLB, как средства повышения доступности и балансировки сетевой нагрузки для ролей RD Connection Broker и RD Web Access. После создания фермы RDCB выполним ряд настроек, которые позволят нам считать инфраструктуру RDS минимально подготовленной к использованию в соответствии со следующим планом:
- Среда исполнения
- Подготавливаем виртуальные сервера
- Создаём кластер NLB
- Подготавливаем SQL Server
- Устанавливаем роли Remote Desktop Services
- Создаём высоко-доступный RD Connection Broker
- Добавляем сервера в высоко-доступный RD Connection Broker
- Добавляем на сервера роль RD Web Access
- Создаём коллекцию сеансов – Session Collection
- Настраиваем цифровые сертификаты
- Настраиваем веб-узлы RD Web Access
- Настраиваем Roaming User Profiles и Folder Redirection
- Публикуем приложения RemoteApp
- Устанавливаем языковой пакет
- Настраиваем перенаправление печати
Среда исполнения
В рассматриваемом примере мы будем строить ферму RDCB из 5 виртуальных серверов одинаковой конфигурации на базе Hyper-V из Windows Server 2012 Datacenter EN. На всех виртуальных серверах устанавливается Windows Server 2012 Standard EN.
Каждый из виртуальных серверов будет иметь по два сетевых интерфейса, настройка которых будет рассмотрена далее.
Серверам присвоены имена – KOM-AD01-RDS21 , KOM-AD01-RDS22 , KOM-AD01-RDS23 , KOM-AD01-RDS24 , KOM-AD01-RDS25
Создаваемый в процессе описания высоко-доступный экземпляр RD Connection Broker а также NLB-кластер RD Web Access будут использовать общее виртуальное имя KOM-AD01-RDSNLB.
База данных высоко-доступного экземпляра RDCB будет расположена на отдельном кластере SQL Server c именем KOM-SQLCL
С точки зрения сетевого взаимодействия, упрощённая схема отказоустойчивой фермы RDS в нашем случае будет выглядеть следующим образом:
Подготавливаем виртуальные сервера
Итак, у каждого виртуального сервера создадим по 2 сетевых адаптера. Назовём их условно на каждом сервере таким образом, чтобы было понятно за что отвечает этот интерфейс - NIC1 (Management) и NIC2 (NLB Cluster).
При создании второго сетевого адаптера NIC2, который будет использоваться для построения NLB в свойствах виртуальной машины Hyper-V необходимо разрешить спуфинг МАС адресов (Enable spoofing of MAC addresses)
Согласно нашей схемы, выделим и распределим статические IP адреса на серверах следующим образом:
| Имя сервера | Настройки IP NIC1 | Настройки IP NIC2 (NLB Cluster) |
| KOM-AD01-RDS21 | IP 10.160.0.151/24 | IP 10.160.0.141/24 |
| KOM-AD01-RDS22 | IP 10.160.0.152/24 | IP 10.160.0.142/24 |
| KOM-AD01-RDS23 | IP 10.160.0.153/24 | IP 10.160.0.143/24 |
| KOM-AD01-RDS24 | IP 10.160.0.154/24 | IP 10.160.0.144/24 |
| KOM-AD01-RDS25 | IP 10.160.0.155/24 | IP 10.160.0.145/24 |
На всех интерфейсах используются одинаковые настройки адреса шлюза по умолчанию -10.160.0.254 и адресов DNS - 10.160.0.253, 10.160.1.253. Причина использования именно такой сетевой конфигурации для построения NLB на базе Windows Server 2012 была ранее изложена в заметке App-V 5 for RDS — Разворачиваем инфраструктуру повышенной доступности
Интерфейс NIC1 будет отвечать за управление самим сервером (будет зарегистрирован в DNS на FQDN имя сервера), а NIC2 (для которого включён спуфинг MAC адресов) будет участником NLB кластера. Выполним настройку сетевых интерфейсов на каждом из серверов согласно вышеприведённой таблицы на примере сервера KOM-AD01-RDS21
Откроем окно настройки сетевых подключений и в меню Advanced > Advanced Settings и проверим порядок использования подключений (Connections).
NIC1 должен иметь приоритет над NIC2.
В свойствах сетевого подключения, которое будет использоваться для подключения к NLB кластеру (NIC2) можно отключить все компоненты, за исключением TCP/IPv4 и Client for Microsoft Networks:
В свойствах компонента TCP/IPv4 зададим настройки согласно приведённой ранее таблицы и по кнопке Advanced откроем окно дополнительных настроек
В окне дополнительных настроек TCP/IP на закладке DNS отключим механизм регистрации в DNS:
Интерфейс NIC1 настроим согласно вышеприведённой таблицы аналогичным образом, за исключением того, что на нём может быть включена опция регистрации в DNS и обязательно должны быть включены компоненты TCP/IPv4 , Client for Microsoft Networks и File and Printer Sharing for Microsoft Networks
После того как описанным способом настроены сетевые интерфейсы на всех серверах, зарегистрируем их имена в доменной зоне прямого просмотра DNS (если запрещена динамическая регистрация в DNS и/или отключена опция регистрации в свойствах интерфейсов NIC1). Для пакетной регистрации A-записей в DNS можно воспользоваться скриптом описанным в заметке DNS – Пакетное создание А-записей с помощью WMI и Powershell
Дополнительно сразу же создаём статическую А-запись для будущего NLB кластера.
RD Connection Broker использует для хранения БД сессий общий экземпляр SQL Server, поэтому все сервера RDCB должны иметь "на борту" клиентские компоненты SQL Server, а также привилегии доступа к SQL Server. Настройку доступа к SQL Server выполним позже, а пока установим на каждый сервер, где планируется развертывание RD Connection Broker, свежую версию пакета Microsoft SQL Server 2012 Native Client (в нашем случае установка нужна на всех пяти виртуальных серверах). Скачать его можно со страницы загрузки Microsoft SQL Server 2012 SP1 Feature Pack (файл sqlncli.msi)
После установки клиента SQL Server создадим на каждом сервере SQL-Alias, который будем в дальнейшем использовать для подключения серверов RDCB к серверу SQL Server. Этого конечно можно и не делать, но это может оказаться полезным (даст нам дополнительную гибкость) в случае необходимости переноса БД на другой SQL-сервер или даже экземпляр. Запустим встроенную в ОС утилиту SQL Server Client Network Utility (C:\windows\system32\cliconfg.exe) и добавим два новых алиаса – с коротким именем сервера и FQDN
Фактически созданные SQL-алиасы в интерфейсе утилиты были записаны в ключ реестра HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo
Теперь нужно проверить созданные нами SQL-алиасы. Для этого создадим пустой файл Universal Data Link с расширением *.udl и запустим его. На закладке Connection укажем SQL-алиас, выберем режим аутентификации Use Windows NT Integrated security и нажмём кнопку Test Connection
Если мы всё сделали правильно, то получим положительный результат подключения. При этом перечень всех активных БД на новом SQL сервере будет доступен в выпадающем списке Select the database on the server. Таким образом проверим алиас созданный как по NetBIOS имени так и по FQDN.
***
Далее, с помощью PowerShell установим на каждый сервер исполняемые компоненты NLB
Import-Module "ServerManager" Add-WindowsFeature "NLB" -IncludeManagementTools
Создаём кластер NLB
На первом виртуальном сервере (KOM-AD01-RDS21) открываем консоль Network Load Balancing Manager (nlbmgr.exe). Выбираем пункт меню Cluster > New Cluster
Вводим имя первого узла, который хотим добавить в NLB, кнопкой Connect подключаемся к нему, и получив с него набор доступных интерфейсов, выбираем тот который хотим сделать участником кластера:
На странице параметров хоста (Host Parameters) оставляем настройки по умолчанию:
В следующем окне мастера создания кластера добавляем IP адрес NLB кластера, на который мы ранее в DNS зарегистрировали А-запись.
Далее указываем FQDN кластера NLB (по той самой A-записи), а также режим его работы. Режим работы кластера – режим одноадресной рассылки – Unicast.
На странице правил портов (Port rules) удаляем имеющееся по умолчанию правило и добавляем необходимые нам правила. При добавлении правила портов убираем флажок All и указываем конкретный интерфейс NLB и диапазон портов, который хотим добавить в кластер NLB.
В общей сложности, в нашем примере балансировке в NLB кластере мы будем подвергать следующие порты:
TCP 443 – для подключения клиентов к RD Web Access;
TCP/UDP 3389 – для подключения клиентов к RD Connection Broker/Session Host;
Все необходимые параметры кластера заданы, создаем его по нажатию кнопки Finish и после первоначальной инициализации, если в конфигурации не допущены ошибки, NLB кластер запуститься в конфигурации с одним узлом
Далее, переходим на имя NLB кластера и пунктом меню Add Host to Cluster вызываем мастер добавления второго и последующих серверов в кластер.
В конечном итоге после добавления (по аналогии с первым узлом) всех серверов мы получим работоспособный Windows NLB кластер
С помощью Ping -t проверяем из клиентской подсети доступность кластерного интерфейса по очереди перезагружая узлы кластера, а затем друг за другом выключая их до тех пор пока в кластере не останется один живой узел.
Подготавливаем SQL Server
Создадим в AD группу безопасности, например KOM-AD01-RDS-Connection-Broker-Computers, и включим в нее учетные записи наших виртуальных серверов.
После этого подключимся к экземпляру SQL Server на котором будет размещаться БД RDCB (в нашем случае это отдельный кластер SQL Server из двух серверов), создадим новый SQL Login с привязкой к указанной доменной группе. При создании SQL-логина ему будет присвоена серверная роль SQL Server – public, которая даст право подключаться к экземпляру SQL Server. Включим ещё одну серверную роль – dbcreator. Эта роль понадобится нам лишь на время первоначальной инициализации БД RDCB для того, чтобы учетная запись сервера, на котором мы будем запускать процесс создания отказоустойчивого RDCB, смогла выполнить операцию создания новой БД.
Дополнительно на SQL сервере создадим каталог для файлов базы данных RDCB. В нашем случае это будет каталог U:\SQLData_SQL01_RDCB на кластерном диске SQL сервера.
Устанавливаем роли Remote Desktop Services
Так как консоль Server Manager в Windows Server 2012 поддерживает групповую настройку сразу нескольких серверов, перед тем как разворачивать на наши виртуальные сервера роли RDS, объединим их в логическую группу. На любом из виртуальных серверов, например на KOM-AD01-RDS21, откроем консоль Server Manager и выберем пункт меню Manage > Create Server Group
добавим пять наших виртуальных серверов в группу и дадим ей название, например RDS-FARM.
После этого выберем пункт меню Manage > Add Roles and Features Wizard
В открывшемся мастере добавления ролей выберем режим установки служб RDS - Remote Desktop Services installation
Тип развёртывания - Standard deployment
Сценарий развертывания выбираем Session-based desktop deployment, так как планируется развертывание серверов сеансов, а не серверов инфраструктуры VDI 
На этапе выбора ролей RDS нас предупредят о том, что будет выполняться развертывание сразу трёх ролей - RD Connection Broker, RD Session Host, RD Web Access, не оставляя при этом нам никакого выбора…
На этапе выбора серверов для роли RD Connection Broker выбираем один сервер, ибо мастер не даст нам выбрать более одного сервера. Так как всю первоначальную настройку мы выполняем на сервере KOM-AD01-RDS21, то соответственно и выберем его для этой роли…
На этапе выбора серверов для роли RD Web Access включим опцию Install the RD Web Access role on the RD Connection Broker server для того чтобы эта роль была установлена на тот же сервер, который был выбран для роли RDCB. Выбирать какой-то другой сервер в нашей ситуации особого смысла нет, да и потом мастер опять таки не даст нам выбрать для установки этой роли более чем один сервер…
На этапе выбора серверов для роли RD Session Host мы сможем выбрать все сервера…
На странице подтверждения мы видим предупреждение, что серверы могут быть перезагружены после установки роли RD Session Host. Включим опцию автоматической перезагрузки серверов - Restart the destination server automatically if required и запустим процесс развёртывания..
В процессе установки ролей первым будет автоматически перезагружен сервер, с которого мы запустили весь этот процесс, поэтому мы отвалимся от его консоли. Пугаться не надо… После того, как система поднимется из перезагрузки, снова залогинимся и запустим консоль Server Manager, где через несколько секунд автоматически запустится мастер развертывания ролей RDS и мы сможем убедиться в том, что процесс развертывания успешно прошёл до конца на всех серверах.
В нашем примере мастер сообщил о том, что на двух серверах из пяти не удалось установить службу RDSH, хотя последующая проверка этих серверов свидетельствовала об обратном. В системном журнале Applications and Services Logs > Microsoft > Windows > ServerManager-DeploymentProvider > Operational было зарегистрировано событие говорящее об успешной установке компонент…
Ну и соответственно PS-запрос состояния компонент RDS показывал что роль RDSH установлена..
В любом случае если Server Manager упорно будет говорить вам о том, что роль RD Session Host не установлена на каких-то серверах, то для того чтобы заставить её "прокашляться", можно повторить процедуру установки через мастер добавления ролей RDS на вкладке управления службами Remote Desktop Services > Overview
Создаём высоко-доступный RD Connection Broker
После окончания процесса установки ролей в консоли Server Manager и перейдём на вкладку управления службами Remote Desktop Services > Overview, чтобы приступить к созданию отказоустойчивой конфигурации RD Connection Broker.
На схеме инфраструктуры RDS выберем изображение роли RD Connection Broker и правой кнопкой мыши вызовем меню, в котором выберем пункт Configure High Availability.
Запустится мастер создания высоко-доступного экземпляра RDCB, где нас предупредят о необходимых условиях, которые мы уже предварительно выполнили, за исключением последнего пункта, который предполагает создание в DNS A-записей c одинаковым FQDN именем RDCB и IP адресами всех серверов (для работы механизма Round Robin). Откажемся от концепции использования DNS Round Robin для получения клиентами имени точки подключения к ферме RDCB. Вместо этого мы будем использовать имя созданного ранее NLB кластера.
На следующем шаге мастера Configure High Availability заполняем значения трёх полей:
Database connection string – строка подключения к БД SQL Server. Значение должно иметь вид: DRIVER=SQL Server Native Client 11.0 (10.50 для SQL Server 2008 R2);SERVER=<FQDN-Имя или SQL-Alias сервера SQL Server>;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=<Имя БД>
В нашем случае это значение будет иметь следующий вид:
DRIVER=SQL Server Native Client 11.0;SERVER=KOM-AD01-SQL-RDCB.holding.com;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDS_ConnectionBroker
Folder to store database files - путь ранее подготовленного каталога U:\SQLData_SQL01_RDCB на кластерном диске SQL сервера. В этом каталоге будут размещены файл данных и лога транзакций SQL Server при создании БД RDCB.
DNS round robin name – имя точки подключения клиентов. Как я уже сказал, здесь предполагается ввод значения FQDN-имени созданного в DNS с несколькими A-записями. В нашем примере, в качестве такого имени, мы будем использовать имя созданного ранее NLB кластера – KOM-AD01-RDSNLB.holding.com
Далее мы получим предупреждение о том, что указанное нами имя DNS RR имеет отличный IP адрес от того, для которого выполняется установка HA RDCB. Мы идём на этот шаг намеренно и поэтому соглашаемся… 
Дожидаемся успешного окончания процесса конфигурирования высокой доступности.
В ходе этого процесса на SQL-сервере будет создана БД высоко-доступного экземпляра RDCB.
***
Переключимся на наш SQL Server с только что созданной БД и выполним пару настроек…
В обязательном порядке для SQL-логина, который мы создавали на подготовительном этапе (KOM-AD01-RDS-Connection-Broker-Computers), нужно дать роль db_owner для созданной базы RDS_ConnectionBroker
Помимо этого, для данного SQL-логина можно отключить добавленную ранее серверную роль dbcreator, так как БД уже создана и больше данная привилегия этому SQL-логину не потребуется.
Если резервное копирование баз данных SQL Server выполняется такими инструментами как например SC 2012 DPM, то при желании мы можем поменять модель восстановления созданной БД (Recovery Model) c Full на Simple.
***
Вернёмся на наш сервер KOM-AD01-RDS21 и обратим внимание на то, что в консоли Server Manager в схеме инфраструктуры RDS статус роли RDCB поменялся на High Availability Mode 
Теперь для того чтобы задуманная нами связка NLB + RDCB работала так как нужно, нам необходимо до-установить роль RD Connection Broker на оставшиеся четыре сервера.
Добавляем сервера в высоко-доступный RD Connection Broker
Добавление серверов к высоко-доступной конфигурации RDCB делается через то же самое контекстное меню в схеме развертывания RDS на странице Overview.
В открывшемся мастере добавляем следующий сервер (мастер также не даст добавить более одного сервера)
После успешного добавления роли на выбранный сервер и подключение этого сервера к БД HA RDCB мы получим предупреждение о необходимости настройки сертификатов, которое пока можем проигнорировать, так как займёмся сертификатами позже.
Аналогичным образом мы по одному серверу должны добавить роль HA RDCB на все оставшиеся сервера, те. KOM-AD01-RDS23, KOM-AD01-RDS24 и KOM-AD01-RDS25.
Добавляем на сервера роль RD Web Access
Так как мы хотим иметь отказоустойчивую конфигурацию роли RD Web Access, нам нужно до-установить эту роль на оставшиеся четыре сервера (на KOM-AD01-RDS21 эта роль уже установлена). Делаем это в уже знакомом нам месте через мастер добавления ролей
Здесь уже мы сможем выбрать сразу все серверы и выполнить установку роли RDWA оптом…
Создаём коллекцию сеансов – Session Collection
Все наши сервера с ролью RD Session Host мы должны объединить в логическую единицу – коллекцию сеансов (Session Collection). Делаем это в оснастке Server Manager на вкладке Remote Desktop Services > Collections выбрав задачу Create Session Collection в таблице перечисления коллекций.
В открывшемся мастере создания коллекции зададим имя коллекции и при желании описание
Затем выбираем все сервера, которые хотим сделать членами коллекции…
Далее мы должны определить доменную группу безопасности которой будет разрешено подключаться к коллекции сеансов. Убираем выбранную по умолчанию группу доступа Domain Users и добавляем специально созданную группу доступа, в нашем случае KOM-AD01-RDS-AllUsers, ограничив тем самым круг пользователей которые смогут подключаться к серверам коллекции.
На следующем шаге определяемся с тем, хотим ли мы использовать новую технологию Windows Server 2012 – User profile disks (UPD), которая, как я понял, предлагается в качестве альтернативы механизму перемещаемых профилей - Roaming User Profiles. Новая технология подразумевает централизованное хранение файлов пользователя в отдельных VHD дисках, которые располагаются где-то на выделенном файловом ресурсе. В силу того, что на данный момент нет уверенности в стабильности работы данного механизма из-за полученной информации в обсуждении Windows Server 2012 RDS - [User Profile Disk] VS [Roaming Profiles + Folder Redirection] я решил пока не использовать данный функционал и поэтому он не будет рассмотрен в данной заметке.
А пока не будут разрешены имеющиеся на данный момент проблемы с UPD будем использовать связку технологий Roaming User Profiles и Folder Redirection, настройка которых рассматривалась ранее в заметке Remote Desktop Services – Используем перенаправление профилей пользователей и перемещаемые папки
В результате работы мастера все наши сервера успешно добавляются в коллекцию с предупреждениями о том, что желательна настройка групповых политик для задания параметров RDP на этих серверах…
Настраиваем цифровые сертификаты
При попытке подключения к ферме RD Connection Broker по FQDN-имени кластера NLB клиенты могут получать предупреждение безопасности, говорящее о том, что нет доверия сертификату того сервера сеансов, на который он был перенаправлен. Если открыть свойства этого сертификата, мы увидим, что сертификат создаваемый на сервере RDSH по умолчанию является самоподписанным. Чтобы избежать таких предупреждений нам нужно создать для развёртывания RDS сертификат подписанный доверенным Центром сертификации (ЦС), например локальным изолированным или доменным ЦС. Этот сертификат после создания мы развернём на всех серверах фермы.
При создании запроса на сертификат нужно использовать как минимум 2 политики применения:
Client Authentication (1.3.6.1.5.5.7.3.2)
Server Authentication (1.3.6.1.5.5.7.3.1)
Хотя в нашей ситуации альтернативные имена в сертификате Subject Alternative Name (SAN) иметь вовсе необязательно, я всё-таки рассмотрю вариант создания именно такого сертификата, то есть чтобы помимо имени NLB кластера в сертификате содержались имена отдельных серверов.
Для того чтобы наш локальный ЦС мог корректно обрабатывать запросы сертификатов с SAN он должен быть настроен для этого. О том как это сделать можно прочитать в заметке Remote Desktop Services – Строим отказоустойчивую ферму RD Connection Broker
Подготовим файл параметров для создания запроса на получение нужного нам сертификата. Это обычный текстовый файл, назовём его например RequestPolicy.inf
Содержимое этого файла в нашем примере выглядит так:
[Version] Signature="$Windows NT$" [NewRequest] Subject = "CN=KOM-AD01-RDSNLB.holding.com" ; Exportable = TRUE; Private key is exportable KeyLength = 2048 KeySpec = 1; Key Exchange – Required for encryption KeyUsage = 0xA0; Digital Signature, Key Encipherment MachineKeySet = TRUE ProviderName = "Microsoft RSA SChannel Cryptographic Provider" RequestType = PKCS10 [EnhancedKeyUsageExtension] OID=1.3.6.1.5.5.7.3.1 ; Server Authentication OID=1.3.6.1.5.5.7.3.2 ; Client Authentication [RequestAttributes] SAN = "dns=KOM-AD01-RDSNLB.holding.com&" _continue_ = "dns=KOM-AD01-RDS21.holding.com&" _continue_ = "dns=KOM-AD01-RDS22.holding.com&" _continue_ = "dns=KOM-AD01-RDS23.holding.com&" _continue_ = "dns=KOM-AD01-RDS24.holding.com&" _continue_ = "dns=KOM-AD01-RDS25.holding.com&" _continue_ = "dns=KOM-AD01-RDSNLB&" _continue_ = "dns=KOM-AD01-RDS21&" _continue_ = "dns=KOM-AD01-RDS22&" _continue_ = "dns=KOM-AD01-RDS23&" _continue_ = "dns=KOM-AD01-RDS24&" _continue_ = "dns=KOM-AD01-RDS25&"
С помощью встроенной в ОС утилиты CertReq.exe создадим файл запроса на основе файла параметров:
cd /d C:\Temp
CertReq –New RequestPolicy.inf RequestFile.req
Выполнять эту команду надо локально на сервере RDS. В нашем случае команда выполняется на сервере KOM-AD01-RDS21. После выполнения команды откроем консоль управления локальными сертификатами (mmc.exe > Add/Remove snap-in > Certificates > Add > Computer account) для хранилища Local Computer и убедимся в появлении ожидающего запроса в разделе Certificate Enrollment Request
Полученный файл запроса RequestFile.req добавляем в локальный центр сертификации через консоль управления Certification Authority (certsrv.msc) (All Tasks > Submit new request)
Затем в этой же консоли в разделе Pending Requests проверяем наш добавленный запрос и разрешаем выдачу сертификата по нему (Выбираем запрос > All Tasks > Issue )
Переходим в раздел выданных сертификатов - Issued Certificates, находим сертификат, открываем его свойства и на закладке Details вызываем мастер экспорта сертификата (Copy to File)
В открывшемся мастере выбираем формат экспорта DER X.509 и сохраняем файл например с именем NLBCert.cer
Скопируем полученный файл NLBCert.cer на сервер RDS, где мы создавали запрос на сертификат (KOM-AD01-RDS21) и вернёмся в консоль управления локальными сертификатами этого сервера. Выберем хранилище Personal > Certificates и вызовем мастер импорта сертификатов (All Tasks > Import)
В мастере импорта автоматически будет выбрано хранилище Local Machine
Далее выберем импортируемый файл сертификата NLBCert.cer и укажем раздел хранилища Personal\Registry. Чтобы этот раздел был доступен для выбора, нужно включить опцию Show physical stores.
После того как импорт сертификата выполнен, убеждаемся что он появился в соответствующем хранилище и с ним связан его закрытый ключ (присутствует значок ключика на иконке). При этом в разделе Certificate Enrollment Request информация о запросе должна исчезнуть.
Далее выбираем установленный сертификат и вызываем мастер экспорта (All Task > Export). В мастере экспорта выбираем опцию экспорта закрытого ключа при экспорте сертификата – Yes, export the private key
В качестве формата экспорта используем единственно возможный и нужный нам формат .PFX
Далее задаем пароль (он потребуется нам в дальнейшем для назначения этого сертификата в развёртывании RDS)
После того как сертификат экспортирован, переходим в консоль Server Manager\Remote Desktop Services\Overview и на схеме развёртывания в списке задач выбираем пункт редактирования развёртывания (TASKS > Edit Deployment Properties)
На вкладке Certificates используем кнопку Select existing cerificates для того чтобы назначить сделанный нами сертификат для той или иной роли RDS…
В окне выбора сертификата определяем, что мы хотим использовать файл PFX полученный нами ранее и задаём пароль с которым этот сертификат был экспортирован. Хотя опция Allow the certificate to be added to the Trusted Root CA нам по сути не нужна, так как созданный нами сертификат сделан в ЦС, которому предположительно все наши сервера уже доверяют, её всё таки придётся отметить, так как если она не отмечена, кнопка OK недоступна…
После закрытия этого окна по ОК, мы увидим что в таблице статус сертификата изменился на Ready to apply..Нажмём кнопку Apply и через несколько секунд наш сертификат будет назначен роли соответствующей RDS. Описанным методом мы выполним привязку сертификатов ко всем развёрнутым у нас ролям и в конечном итоге получим примерно следующий вид:
Назначенные нами сертификаты будут автоматически установлены на все сервера, которые участвуют в нашем RDS развёртывании.
Настраиваем веб-узлы RD Web Access
По умолчанию при обращении в стартовой веб-странице RDWA от пользователя в явном виде требуется ввод учетной записи и пароля. Если мы используем RDWA для доменных пользователей внутри локальной сети, то для удобства нам нужно будет задействовать механизм прозрачного входа Single sign-on (SSO) при обращении к веб-узлу RDWA. Для этого на каждом сервере с установленной ролью RDWA в оснастке IIS Manager откроем свойства веб-приложения RDWeb > Pages выберем в разделе настроек пункт Authentication…выключим анонимную аутентификацию (Anonymous Authentication), аутентификацию на основе формы (Forms Authentication) и включим Windows Authentication:
***
После входа на веб-страницу RDWA можно обнаружить уже знакомый нам по предыдущей версии опцию I am using a private computer that complies with my organization's security policy (в русском варианте - Я использую личный компьютер, соответствующий политике безопасности моей организации).
Ранее, в заметке RDS Web Access – Опция "Я использую личный компьютер…", я писал о том, как выставить эту опцию во включенное состояние по умолчанию, чтобы избежать повторного запроса аутентификации при подключении к опубликованным приложениям RemoteApp в Windows Server 2008 R2. Это рецепт работает и для Windows Server 2012.
***
Верхняя часть страниц RDWA по умолчанию оформлена в виде заголовочной надписи Work Resources и изображения размером 48*48 пикселей.
Для того чтобы заменить заголовочную надпись можно использовать командлет PowerShell (один раз для всей коллекции серверов):
Set-RDWorkspace -Name "Приложения RemoteApp" -ConnectionBroker KOM-AD01-RDS21.holding.com
Для того чтобы заменить имеющееся изображение на другое, например с корпоративной символикой, можно внести корректировки в файл %windir%\Web\RDWeb\Pages\Site.xsl – найти секцию с комментарием "Replaceable Company Logo Image"…
… и заменить ссылку на файл изображения, указав собственный файл размещённый в соответствующем подкаталоге %windir%\Web\RDWeb\Pages\images
В результате мы получим примерно следующий вид верхней части страниц RDWA:
Настраиваем Roaming User Profiles и Folder Redirection
Так как пользователи нашей фермы RDS от сеанса к сеансу могут попадать на разные сервера, нам необходимо обеспечить идентичность пользовательской среды на всех этих серверах. Для этого мы будем использовать механизмы перемещаемых профилей (Roaming User Profiles ) и перенаправления папок (Folder Redirection). Для настройки этих механизмов настраиваем групповую политику применяемую к серверам нашей фермы RDS. Здесь мы не будем рассматривать эту процедуру, так как она уже была ранее описана мной в заметке Remote Desktop Services – Используем перенаправление профилей пользователей и перемещаемые папки
Публикуем приложения RemoteApp
Чтобы опубликовать в ферме RDS приложения RemoteApp переходим в консоль Server Manager в раздел Remote Desktop Services > Collections > выбираем нашу коллекцию KOM-AD01-RDSH-COLL и публикуем необходимые приложения в окне REMOTEAPP PROGRAMS. В меню задач выбираем пункт публикации TASKS > Publish RemoteApp Programs
Для примера опубликуем два простых приложения Calculator и WordPad
Опубликованные приложения доступны клиентам нашей фермы RDS двумя основными способами – через веб-интерфейс RD Web Access и через непосредственную доставку ярлыков запуска на клиентские компьютеры. С первым способом, полагаю, всё итак понятно, рассмотрим второй. Для того чтобы ярлыки опубликованных приложений RemoteApp стали доступны на клиенте с Windows 7/8, нужно выполнить подписку на узел RDWA в Панели управления (апплет Подключения к удаленным рабочим столам и приложениям RemoteApp). Щелкнув по ссылке Доступ к удалённым приложениям RemoteApp и рабочим столам мы вызовем мастер подключения, где в адресной строке укажем URL RDWA в формате http://KOM-AD01-RDSNLB.holding.com/RDWeb/Feed/WebFeed.aspx
В примерах описанных в окне подключения можно заметить вариант с указанием адреса, похожего на адрес электронной почты - alexeyo@contoso.com. На самом деле такой метод указания адреса не столько имеет отношение к электронной почте, сколько относится к методу автоматического обнаружения сервера публикации RemoteApp с помощью специальных записей в зоне прямого просмотра DNS. То есть мастеру подключения важно лишь то, что указано после символа @ – имя зоны DNS. До символа @ можно написать любую ерунду. Например, в нашем примере в DNS используется зона holding.com и в качестве адреса мы можем указать например blablabla@holding.com
В зоне DNS соответственно при использовании такого метода должна быть создана специальная запись формата TXT c именем _msradc и текстовым значением в формате https://rds.domain.com/rdweb/feed
Соответственно в нашем примере запись будет иметь следующий вид:
После того как запись создана, проверим то, что DNS сервер возвращает нам значение этой записи с помощью утилиты nslookup в режиме set querytype=TXT и если всё в порядке, то теперь в качестве адреса подключения можем указать соответствующее значение
При этом из DNS будет возвращён URL-адрес подключения…
После этого может последовать запрос на ввод учетных данных пользователя, чтобы узел RDWA выполнил идентификацию пользователя и определил какие ярлыки на приложения RemoteApp можно показать пользователю согласно доменных групп безопасности, включенных в правилах публикации. В нашем примере будет отображена информация об успешном подключении и количестве доступных пользователю программ
При этом в меню “Пуск” для Windows 7 и в стартовом экране для Windows 8 в отдельной группе появятся ярлыки на запуск приложений RemoteApp
Если вам потребуется каким-то альтернативным способом распространять ярлыки на приложения RemoteApp, то их можно будет найти на клиентской машине подключённой вышеописанным способом к точке публикации RDWA в каталоге
%APPDATA%\Microsoft\Workspaces{GUID}\Resource
Нововведением Windows 8 стал ещё один способ подключения клиентов к точке публикации – с помощью групповых политик (GPO). За это отвечает параметр
Specify default connection URL в разделе User Configuration/Policies/Administrative Templates/Windows Components/Remote Desktop Services/RemoteApp and Desktop Connections. Для настройки клиентов нужно включить этот параметр и указать значение URL-адреса подключения в формате:
https://KOM-AD01-RDSNLB.holding.com/rdweb/Feed/webfeed.aspx
Как я уже сказал, этот параметр поможет нам настроить только клиентов Windows 8, но если у вас есть сильное желание раздать через GPO настройку и для клиентов Windows 7 – читайте статью Concurrency Blog - How to deliver RemoteApps from Windows Server 2012 RDS. Метод заключается в применении на клиентских машинах PowerShell скрипта Configure RemoteApp and Desktop Connection on Windows 7 Clients с передачей ему в виде параметра файла настроек в следующем формате:
<?xml version="1.0" encoding="utf-8" standalone="yes"?> <workspace name="Enterprise Remote Access" xmlns="http://schemas.microsoft.com/ts/2008/09/tswcx" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <defaultFeed url="https://KOM-AD01-RDSNLB.holding.com/rdweb/Feed/webfeed.aspx" /> </workspace>
Устанавливаем языковой пакет
Так как в нашем примере на серверах фермы RDS используется англоязычная система, нам потребуется установка языкового пакета для локализации интерфейса пользователя. Чтобы получить файлы русского языкового пакета распаковываем образ содержащий все языковые пакеты для Windows Server 2012 RTM SW_DVD5_NTRL_Win_Svr_Language_Pack_2012_64Bit_MultiLang_FPP_VL_OEM_X18-27741.ISO
Извлекаем файл langpacks\ru-ru\lp.cab из состава образа и вызываем на сервере RDS мастер установки языковых пакетов командой lpksetup
Помимо этого установку языкового пакета можно выполнить командой:
Dism /online /Add-Package /PackagePath:"C:\Distributives\WS2012RTMLanguagePack\lp.cab"
Практика показывает, что после выполнения этой команды, для того чтобы в панели управления появилась информация о том, что языковой пакет действительно установлен, – необходима перезагрузка системы. После перезагрузки сервера RDS переходим в панель управления в раздел Language и выделив русский язык кнопкой Move Up поднимаем его на первую позицию, сделав его таким образом приоритетным языком интерфейса.
Далее открываем апплет панели управления Control Panel > Region (intl.cpl) , проверяем и при необходимости настраиваем параметры на родной язык на закладках Formats и Locations , а затем на закладке Administrative нажимаем Copy settings, чтобы скопировать языковые предпочтения текущего пользователя для всех пользователей которые будут первый раз входить в эту систему.
Убедимся что у текущего пользователя установлены такие настройки, которые мы хотим иметь у всех пользователей сервера RDS и включим галочку New user accounts
Не рекомендую использовать опцию копирования русских настроек в системный профиль (галка Welcome screen and system accounts), так как это в перспективе может привести к невменяемой работе некоторых “буржуйских” программ, проблемы в которых возникают чаще всего из-за знака разделителя целой и дробной части.
Настраиваем перенаправление печати
Для того чтобы пользователи служб удалённых рабочих столов смогли выполнять печать на перенаправленные с их клиентских мест устройств печати, выполним ряд нехитрых манипуляций.
Установим на сервера RDS консоль управления службой печати – Print Management, например с помощью PowerShell:
Add-WindowsFeature RSAT-Print-Services
Если есть сильное желание управлять службой печати на всех серверах например с рабочей станции Администратора, то для того, чтобы можно было удалённо подключаться к службе печати, на серверах необходимо включить параметр групповой политики Allow Print Spooler to accept client connections в разделе Computer Configuration\Policies\Administrative Templates\Printers. После применения политики на серверах нужно перезапустить службу очереди печати - Print Spooler.
На мой взгляд использовать локально установленную на серверах консоль – более предпочтительно.
После установки открываем консоль, добавляем в неё наши сервера, и в свойствах сервера печати для каждого сервера выполняем необходимые изменения настроек, например на закладке Advanced отключаем включённые по умолчанию оповещения сетевых и локальных принтеров…
К слову об использовании именно локальной консоли…эти две опции недоступны для изменения (попросту не видны) если вы подключаетесь консолью удалённо.
На закладке Drivers добавляем драйвера принтеров, которые используются для печати на клиентских компьютерах. Драйвера принтеров нужно добавлять исходя из принципа разумного минимума. Например вместо того чтобы для принтеров Hewlett-Packard добавлять несколько драйверов для конкретных моделей лучше добавить один универсальный драйвер HP Universal Print Driver (UPD), в случае если принтеры поддерживают работу на данном драйвере. В нашем примере используется текущая версия (на момент написания этой заметки) UPD совместимая с Windows Server 2012 - 5.6.5.15717. Разумеется добавлять драйвера производителей оборудования вообще имеет резон только в том случае если тесты показывают, что принтер не выполняет поставленные задачи печати на драйвере Remote Desktop Easy Print.
В конфигурации по умолчанию для принтеров перенаправляемых с пользовательских компьютеров система будет использовать драйвер Remote Desktop Easy Print. Если мы загружаем на сервера RDS драйвера производителей принтеров, как например тот же HP UPD, то возможно нам стоит переопределить такое поведение, то есть, чтобы приоритетным для использования считался драйвер вендора железки, а уж если его не удалось найти – использовать RD Easy Print. Задаётся это параметром групповой политики Use Remote Desktop Easy Print printer driver first = Disabled в разделе Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Printer Redirection
После применения GPO в пользовательской терминальной сессии проверяем какой драйвер был назначен для перенаправленного принтера…
На этом, в целом, можно считать, что мы выполнили основные этапы создания и настройки отказоустойчивой фермы RD Connection Broker на базе Windows Server 2012. В отдельной следующей заметке мы рассмотрим пример настройки пользовательского интерфейса на сервера RD Session Host.
Полезные ссылки по теме:
Remote Desktop Services Blog - RD Connection Broker High Availability in Windows Server 2012
VirtualizationAdmin.com - Taking a closer look at RD Connection Broker High Availability in Windows Server 2012
TechNet Articles - RD Connection Broker HA – SQL Permissions
Freek Berson Blog - RD Connection Broker HA and the RDP properties on the client
Blog Working Hard In IT - Reflections on Getting Windows Network Load Balancing To Work (Part 1)
Blog Working Hard In IT - Reflections on Getting Windows Network Load Balancing To Work (Part 2)
RSS - Записи
Спасибо за статью.
Как раз планировали с 2008 на 2012 переходит RDC.
Спасибо, очень содержательно и понятно.
Жду продолжения.
Шикарно!
Обратная ссылка: High Availability RD Connection Broker на базе Windows Server 2012–выявленная закономерность в конфигурации с более чем 3 серверами | Блог IT-KB /
Спасибо за подробное и доступное описание всего процесса, очень познавательно. Хочу узнать, с доступом к RDWeb с клиентских машин под управлением WinXP SP3 проблем не наблюдается? Чуть ранее подобный вопрос был на technet (http://social.technet.microsoft.com/Forums/ru-RU/b6fc0d24-8f5e-4756-a773-628fb91bf9b8/sso-windows-xp-rdweb-windows-2012), помечен "отвеченным", однако как и задающий вопрос, так и я, столкнулись именно с такой проблемой - с клиентов XP невозможно зайти нормально. Кажется есть возможность поднять RD Gateway и пробовать перенаправить всех корпоративных клиентов через него, но это будет всем костылям костыль. Может быть ситуация Вам знакома или подскажете, куда ещё можно обратить свой взор? Заранее благодарен за любую оказанную помощь, с уважением, Василь.
Сходу не скажу. Попробуем у себя, и если проблема будет воспроизведена - отпишусь.
Посмотрел на тестовом клиенте на Windows XP SP3 с IE8 и всеми установленными обновлениями с WSUS - действительно проблема имеет место быть, но для нас она не очень актуальна, т.к. количество WinXP стремительно приближается к нулю. На WinXP проблема проявляется каким-то плавающим образом (от обновления к обновлению страницы по F5), то есть страница то загружается, то возникает ошибка загрузки "unable to display rd web access". Проблема описана также в этой ветке:
http://social.technet.microsoft.com/Forums/windowsserver/en-US/daffe906-be42-418d-8552-ec679ffba0ca/error-message-on-rd-web-access-for-server-2012
Как я понял, проблема проявляется только на связке Windows XP SP3 + IE8 и связана она может быть с тем, что IE как-то некорректно обрабатывает загружаемые стили XSLT.
Пробовал разные методы:
1) Отключал использование прокси (чтобы браузер обращался к узлу RDWA напрямую)
2) Сбрасывал все настройки безопасности в браузере. Узел RDWA должен входить в зону доверенных узлов и/или в зону локальной интрасети.
Плавающая ошибка не исчезает.
Как вариант можете попробовать поменять тип аутентификации на IIS с Windows Integrated на Form Based. Вдруг поможет. Я не пробовал)
Другой вариант на таких клиентах для доступа к RDWA использовать альтернативный браузер, например Mozilla FireFox, который должен без проблем работать с RDWA из WS2012.
В любом случае можете выйти с проблемой на техподдержку Microsoft и если появиться универсальный метод решения проблемы - не забудьте нам об этом сообщить :)
PS: Рекомендую задуматься о том, как избавиться от клиентов на Windows XP, если вы до сих пор этого не сделали. Ибо в следующем году кончается срок расширенной поддержки этой ОС http://support.microsoft.com/lifecycle/?c2=1173 и все возможные риски связанные с использованием этой ОС лягут на хрупкие плечи администраторов :)
Алексей, а как правильно отфильтровать ПК с Вин8/Вин8.1 что бы им через ГПО подключить ремоут_апп через webfeed.aspx ??
Вижу как минимум два варианта.
1) Создать отдельную групповую политику с настроенным параметром Specify default connection URL в разделе User Configuration/Policies/Administrative Templates/Windows Components/Remote Desktop Services/RemoteApp and Desktop Connections и включить для её применения WMI фильтр, в котором указать только системы Windows 8/8.1
О том как создать подобный фильтр написал здесь: GPO WMI Filters: WMI-фильтр c отбором по версии Windows
2) Не использовать параметр Specify default connection URL а вместо этого использовать ключ реестра настраиваемый этим параметром и раздать его на нужных клиентов с помощью GPP с нацеливаеием (targeting) на системы Windows 8/8.1
Вариант 2 кажется мне более удобным, так как нужный параметр GPP можно добавить в любую уже работающую GPO, да и работать он будет на мой взгляд быстрей, чем отдельная политика с WMI-фильтрацией (как в п.1)
Алексей, насколько я понял для отказоустойчивости роли RD Connection Broker необходим и достаточен SQL сервер, а NLB нужен для балансировки нагрузки RD Web Access? Т.е., если я не планирую использовать Web Access, то с NLB можно не заморачиваться?
Помимо RDWA NLB в моём описании используется ещё и как средство направления клиентов на RDCB взамен DNS Round Robin. Если Вас устраивает механизм DNS Round Robin, то вполне сможете обойтись и без NLB.
Возможно глупый вопрос, публикуемые апликации нужно устанавливать на каждом сервере отдельно? Или это делается централизованно?
Публикация приложений выполняется на RD Collections централизованно. То есть, если в коллекции несколько серверов, то при публикации приложения через любой из этих серверов подразумевается что публикуемое приложение одинаково доступно по одному и тому же пути на каждом сервере коллекции.
Это понятно. Если я хочу опубликовать например outlook, надо установить его на каждом сервере по отдельности, или есть централизованная установка реплицирующаяся на все сервера
Установка на каждый сервер по отдельности. Публикация - один раз на всю коллекцию серверов. Если серверов в коллекции много и установку делать отдельно на каждый руками грустно, то можно использовать разнообразные средства автоматизации, например SCCM.
Thnx! Great manual!
Отличный мануал, все работает))
Маленький вопрос, как оживить кластер если упадет SQL?
Высокодоступный RDCB предполагает высокодоступный SQL Server. В противном случае это будет "колосс на глиняных ногах".
:) индусы до сих пор не используют свою же фабрику...а зачем, ведь упадут продажи sql. И так почти во всем и у всех вендоров.
Помогите, не хочет создаваться база в SQL (2012), на каждом сервере сделал алиасы, по файлу udl, соединяется все отлично, но когда пишешь строчку подключения в брокере, выдает ошибку sql сервер недоступен, уже ради интереса поставил SQL на машину, где установлен рдп брокер, результат один и тот же. Делаю вывод если через клиента проходит подключение к бд, значит сервер виден по сети и доступен, брандмауэр выключил, что еще можно посмотреть, подскажите?
Проверьте установлены ли клиентские компоненты SQL Server. Проверьте телнетом доступность порта 1433. Проверьте все параметры Database connection string и удостоверьтесь в том, что в параметре DRIVER верно указана версия клиентских компонент SQL Server. С остальными вопросами http://forum.it-kb.ru/viewforum.php?f=5
Сделал, все получилось спасибо, но есть одна загвоздка айпи адресс нлб кластера не виден в разных подсетях, то беж работают только те люди, которые находятся в подсети кластера, если пинговать, сервера из разных подсетей они видны, кроме нлб кластера. Подскажите куда копать?, чисто теоретически кластеру нужно добавить шлюз, но где это сделать я так и не нашел. Спасибо
Нужно либо настраивать шлюз на NLB-интерфейсе (думаю трудно не увидеть пример такой настройки в скриншотах заметки), либо включать Forwarding между основным Management-интерфейсом и NLB-интерфейсом. Хотя проблема может быть и в другом, и по сути эта проблема связана скорее с неправильной настройкой конфигурации NLB, чем с темой поста - HA RDCB. Можно попробовать разобрать Вашу проблему на нашем форуме http://forum.it-kb.ru/
Есть ли смысл разносить роли RD Connection Broker, Session Host, Web Access по разным серверам?
А про развертывание "Virtual machine-based desktop deployment" у вас нет статьи?
Этот вопрос не предполагает однозначного ответа. Всё зависит от исходных данных и желаемого результата. С VDI не работал и пока не планирую, поэтому и соответствующих заметок нет.
Алексей, подскажите, как подключить Брокера к sql серверу 2008r2? Создал группу в AD, добавил туда запись компьютера брокера. Создал имя входа - эта группа из АД, дал права sysadmin. При попытке подключения "DRIVER=SQL Server Native Client 10.50;SERVER=sql.local;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=FARMRDCB;" выдает ошибку "База данных недоступна". Надо ли привязывать к имени входа учетные данные, создавать базу руками? Со своими учетными данным подключиться могу
Проблема решилась "DRIVER=SQL Server Native Client 10.0"
А можно ли публиковать на разные серверах фермы разные приложения?
Соответственно чтобы какие-то приложения запускались только с определенного узла*
А как Вы собираетесь брокеру объяснить что какого-то конкретного пользователя нужно отправить на какой-то конкретный узел потому, что он запустил какое-то конкретное приложение? Я такого способа не знаю. Публикуется приложение не на сервер а на пул серверов, то есть на ферму и это подразумевает что это самое приложение должно быть доступно на всех серверах фермы.
Жаль. В Citrix такая возможность реализована простым выбором серверов в ферме, к которым привязано приложение. Спасибо за ответ.
подскажите пожалуйста. После импорта сертификата в локальное хранилище нет возможности экспортировать сертификат с закрытым ключом. в чем может быть проблема?
Здравствуйте. Подскажите пожалуйста, как решается проблема профилей пользователей сеансов удаленных рабочих столов? Так как в ферме много серверов и брокер каждый раз перенаправляет пользователя на разный сервер узлов сеансов, то профили будут тоже все время разные. Получается надо использовать перемещаемые профили из общей папки, которые будут постоянно копироваться на тот сервер, к которому произошло подключение. Или же есть какой-то механизм репликации профилей между серверами в ферме, как например это делается с объектами в каталоге AD?
Спасибо.
Здравствуйте. Если Вы внимательно прочитаете всю заметку, то обнаружите в ней раздел "Настраиваем Roaming User Profiles и Folder Redirection", где есть ссылка на более раннюю заметку о том как настроить механизм перемещаемых профилей и перенаправления папок: https://blog.it-kb.ru/2011/12/23/remote-desktop-services-rds-roaming-user-profiles-and-folder-redirection-gpo-settings/.
Она была написана применительно к Windows Server 2008 R2, но вполне справедлива и для Windows Server 2012 / 2012 R2
Спасибо, Алексей. А слона-то я и не заметил :)
Скажите пожалуйста, для работы данной GPO, нужно ли использовать новую технологию репликации папки Sysvol DFS-R или она будет работать и при старой технологии FRS? Дело в том, что у меня лес создавался изначально на 2003, затем был произведен переход на 2012, уровень леса и домена подняты до 2008R2, но технология репликации осталась старая, меня она вполне устраивает. Но теперь, когда я создал по вашему примеру GPO, то она не применяется корректно на серверах фермы. Все остальные GPO для настройки пользовательских окружений, работают. Ошибок в AD нет.
Ваши проблемы с применением GPO не имеют отношения к теме поста. Для обсуждения подобного рода проблем есть форум.
Не работает Ваша схема, если дело касается NAT. Т.е ,если rdscb nlb будет за натом, работать это не будет!
Добрый день. После установки ярлыков на ПК через "Панель управления\Все элементы панели управления\Подключения к удаленным рабочим столам и приложениям RemoteApp" при каждом запуске такого приложения появляется запрос имени и пароля. Птичка "Сохранить пароль" в этом окне отсутствует. Как сделать сквозную авторизацию без запроса пароля. Все машины в домене.
Спасибо.
Посмотрите эту заметку https://blog.it-kb.ru/2011/12/23/microsoft-terminal-services-rds-windows-single-sign-on-via-credssp/
Большое спасибо. Извините за глупый вопрос.
Заметил такую особенность, после перезагрузки любого из серверов фермы, RDP на нём не работает, пока вручную не перезапустить службу "Служба удаленных рабочих столов", притом, что эта служба стартует автоматом. С чем это может быть связано? В логах нет никаких ошибок.
Добрый день. Заметил некую особенность, периодично в логах появляется сообщение The Remote Desktop Connection Broker server detected that the database is not available and will notify all Remote Desktop Connection Broker plug-ins. И через 30 сек все в порядке, также видно что пользователи в это время отваливаются и не могут подключится(пишет восстанавливается подключение ). 5 серверов в ферме, 32 камня + 32 Гб оперативной памяти. Не могу понять в чем причина!?
Отвечу сам - проблема давно решена, причем проблема в тормознутом сиквеле, пришлось перенести базу на другой сиквел сервер. Теперь все - ОК.
Добрый день, подскажите, плиз, как запретить пользователям подключаться по старинке через RDP на рабочий стол сервера терминалов 2012, где развернуты все роли (вебдоступа, узел сеансов, посредник подключения), но оставить возможность запускать опубликованные приложения со своего рабочего стола ярлычком к настроенному соединению (rdp). Если пользователя убрать из традиционной группы "Пользователи удаленного рабочего стола", то и конкретные опубликованные приложения тоже становятся недоступны. Пробовал баловаться в локальной политике безопасности. Тоже самое: нет разрешения на терминальный доступ - невозможно и приложение запустить, есть - велком на рабочий стол. А народ ушлый про Win+R, mstsc все знают. Плиз, Хелп!
Хорошая статья. Спасибо. Но вот с сертификатами застрял. При добавлении RequestFile.req в ЦС ругается, что "В запросе отсутствует информация о шаблоне сертификата и т.д.".. все делается на 2012 R2 .
все просто в самом инф файле в [RequestAttributes] добавьте строку CertificateTemplate = WebServer
после этого снова выполните запрос. Не забудьте после получения crt завершить запрос на сертификат в IIS рдп сервера. Удачи.
сделал. и словил при коннекте эроры, но они правятся. то есть, для рдп все равно на темплейтссертификата ? думалось , что если настраиваем NBL, то там надо для компутертемплейтса делать...
Необходимо ли заводить отдельный SQL-сервер для базы данных RDCB или можно использовать уже существующий? (или рассмотреть вариант миграции существующего на созданный для нужд RDCB, к примеру)
В отдельном SQL-сервере или даже инстансе никакой необходимости нет. Можно использовать существующий.
Добрый день!
А можно создать несколько коллекций, чтоб брокер сам разбрасывал по разным серверам пользователей в зависимости от их группы? Например, ПерваяКол (сервера rds1, rds2), имеют доступ пользователи из группы grFirst; ВтораяКол (сервера rds3, rds4), имеют доступ пользователи из группы grSecond.
Полагаю, что нельзя. Как в таком случае Вы представляете себе поведение брокера если получится так, что подключаемый пользователь входит и в группу grFirst и в группу grSecond...
Пользователь принадлежит одной группе. В таком случае какой смысл в нескольких коллекциях?
Все сделано точь-в-точь по инструкции, но при включении адаптера NLB-кластера перестают пинговаться шлюзы и прочие узлы сети. Куда копать?
Неправильно работает маршрутизация. Проверять конфигурацию сети.
http://technet.microsoft.com/ru-ru/library/cc771300(v=WS.10).aspx
Уважаемый автор, как Вы это прокомментируйте? Вопрос касается в частности пунктов настройки NLB. Согласно мануалу, при использовании посредника сеансов,требуется в настройках портов параметра "Сходство" устанавливать значение "Нет". Вы же указываете, что нужно выбирать "Сходство" - "Один"
Дельное замечание. До этого мой NLB-кластер работал именно в таком режиме, как описано у меня в статье. Хотя по логике действительно более правильно использовать режим Filtering Mode - Multiple host - Affinity: None, как описано в приведённом Вами документе. Я поменял режим работы своего NLB, погоняю его так, и если не столкнусь ни с какими проблемами, то обязательно изменю содержимое статьи. Спасибо.
Здравствуйте Алексей. Хорошая статья, особенно если ни разу не разворачивал.
У меня есть несколько вопросов
1. Зачем создавать сертификат с: Client Authentication (1.3.6.1.5.5.7.3.2), Server Authentication (1.3.6.1.5.5.7.3.1) ? Должно быть достаточно Server Authentication (1.3.6.1.5.5.7.3.1), используются же такие же сертификаты как и в IIS.
2. Если мы создаем NLB кластера, то нам соответственно нужен сертификат на кластерное имя? Альтернативные вроде как и не нужны.
3. Объединение на каждом из хостов по несколько ролей (как то WI,CB,SH) это best practice? Или по возможности лучше распределить, типа WI, SG в DMZ, отдельные пара брокеров и Session Host?
1. Сейчас уже не вспомню, где находил информацию о таких OID. Могу точно сказать только то, что сейчас разворачиваю ферму RDS на Windows Server 2012 R2, и там использую сертификат только с Server Authentication и этого, вроде как, действительно достаточно.
2. Так и есть. В статье это упоминается.
3. Если позволяют ресурсы, то конечно лучше разделить роли.
Обратная ссылка: Windows Server 2012 R2 Remote Desktop Connection Broker — Невозможно подключиться к высоко-доступной ферме RDS — Подключение было запрещено… | Блог IT-KB /
Добрый день, Алексей! Огромное Вам спасибо за рекомендации и комментарии!
Конфигурацию сделал несколько другую - разделил роли. Сделал NLB кластер rdfarm0 из двух виртуальных серверов rdfarm0-0 и rdfarm0-1, на которых крутится session broker в высокодоступном режиме. Также есть два физических session hosts, из которых сделана session collection. Права доступа пользователей по rdp к серверам-членам этой коллекции дадены.
При попытке запуска mstsc /v:rdfarm0 и дальнейшего входа под обычным пользователем я ожидал, что сессия будет образована с одним из session host серверов. Однако, этого не происходит - выдается отлуп, глясящий, что обычный пользователь не имеет прав заходить по rdp на сервер rdfarm0-0 (или rdfarm0-1), что совершенно справедливо, т.к. таковых прав действительно нет и не планируется.
Сие поведение вызвало недоумение. Это, так сказать, by design, или я что-то не так понимаю?
Запланированная конфигурация такова - кластер из пары виртуальных брокеров на двух физически разных хостах + несколько (3-4) физических session hosts, на которых и работают сотрудники + отдельный виртуальный сервер лицензий.
Плиз, растолкуйте, если это Вас не затруднит!
Благодарю!
С увжаением, Константин.
Описанная в статье конфигурация работает, и работает по сей день. Но работает она только потому, что роли RDCB и RDSH совмещены на всех серверах. Вы меняете конфигурацию таким образом, что всё что описано в статье для Вас уже работать не будет. И как Вы понимаете, в этом нет ничего удивительного.
Попробуйте отказаться от NLB в пользу предлагаемой "бай дезайн" Round Robin DNS.
Почитайте последние заметки по RDS, и особенно эту: Windows Server 2012 R2 Remote Desktop Connection Broker — Невозможно подключиться к высоко-доступной ферме RDS — Подключение было запрещено…
Вполне возможно, что из неё Вы получите ответы на свои вопросы.
Добрый день.
При создании высоко-доступного RD Connection Broker выскакивает ошибка о невозможности подключения к SQL серверу. Все права и доступность через файл с расширением udl приверено, пишет что тест пройдет. Подскажите в какую сторону копать.
Осуждение ошибок возникших в вашем конкретном случае - на форуме.
Добрый день!
Вопрос возник, подскажите пожалуйста.
При открытии консоли управления Server Manager и выбора раздела Server Manager\Remote Desktop Services\Overview время от времени на главном поле вижу ошибку
"The Server pool dpes not match the RD Connection Brokers that are in it. Errors:
1.The RD Conenction Broker server test1.int.local is not in the server pool but is part of the cluster test.int.local. Add it the server pool"
Причем ферма построена из двух нод согласно Вашей статье. Доступ по RemoteAPP работает, тестовые выключения какой либо из нод это подтверждают.
Насколько я понимаю, консоль Вам просто сообщает о том, что в неё не добавлен какой-то один из серверов, входящих в ферму (в правом верхнем углу консоли Server Manager - Управление > Добавление серверов)
Так, да, решилось просто. Я создал в консоли группу RDS-FARM (хотя ранее и так создавал согласно статье).
Добавил в нее сервера фермы.
Странно.
Есть у меня маленькая проблема, на одном из серверов слетела цветовая схема, по-дефолту черный цвет области текста, надписей не видно. Где не рыл, но так и не смог найти решения проблемы. А переставлять сервер как-то не хочется.
Тоже сталкивались в своё время с подобной петрушкой. Лечилось только пересозданием профиля пользователя.
Дело как раз в том что профиль перемещаемый и на остальных серверах все хорошо, а на первом такая беда, профиль пересоздал, не помогло(
Временно лечу, применением через полиси темы которую создал. Причем если зайти под пользователем на раб. стол все хорошо но ексель или ворд - беда( Боюсь придется пересобрать ферму с новым сервером, благо уже создал и настроил. Хочу с тем же именем и тем же ИП. Как сделаю отпишусь о результатах.
Тут всё зависит от типа перемещаемости профиля. Если это классические Roaming Profiles + Redirected Folders, то ситуация одна, а если это User Profile Disk (UPD), то ситуация совсем иная. Есть подозрение, что в первом случае на каждом из терминальных серверов в локальной копии профиля несмотря на "перемещаемость" всё равно хранится часть данных уникальных для каждого такого сервера. Поэтому при удалении перемещаемого профиля и перенаправляемых папок из общей сетевой папки, дополнительно нужно выполнить удаление локального кэша профиля на каждом терминальном сервере и, возможно, только тогда проблема связанная с конкретным пользователем будет локализована. Если же используется UPD, то по сути достаточно лишь удалить vhd-образ профиля из общей сетевой папки.
Дополнительно из опыта общения с фермой RDS на Windows Server 2012 могу сказать что, там подобные странности - не редкость. Сейчас перешли на Windows Server 2012 R2 с UPD... пока наблюдаем за ситуацией.
Это классические Roaming Profiles + Redirected Folders. Удалял на нем(проблемном серваке) профиль юзера, и на сервере где профиля храняться тоже, не помогло)))
Такая же проблема на 12R2. Пришлось лечить включением Desktop Experience.
Desktop Experience помимо расширенных функций управления рабочим столом тянет за собой ряд компонент, излишних на мой взгляд для сервера RDS. Поэтому такое решение вопроса не рассматривалось вообще.
Здравствуйте! Подскажите можно ли как-то избавиться от черного фона в RDP сессии? Перепробовал уже, кажется, все. В том числе и Desktop Experience на серверах.
Спасибо.
Данная ферма в данной описанной схеме реализации у меня на пилоте была 3 месяца.
Что могу сказать : проявилась проблема плавающего отсутствия подключения клиентом из других подсетей. (филиалы)
Причем у пользователя может все работать сутками и неделями, а потом вдруг ошибка подключения (хотя инициализация соединения через ярлык происходит).
Проверка на маршрутизаторах показала что порты требуемые открыты. Со стороны пользователя порты к серверу доступны по telnet. Блокировок от спуффинга или иных филтров нет.
Набрел на статью (правда там о 2008): http://blogs.technet.com/b/networking/archive/2009/01/15/unable-to-connect-to-windows-server-2008-nlb-virtual-ip-address-from-hosts-in-different-subnets-when-nlb-is-in-multicast-mode.aspx
Сейчас задумываюсь о переходе на технологию DNS RR, ибо надо уже в пром заводить ферму.
Я использую Unicast NLB.
Виртуальные машины для статистики отказа переместил на один хост HYPER-V.
Я ушёл от описанной конфигурации на Windows Server 2012 R2 c DNS RR (в блоге есть более поздние записи об особенностях использования такой конфигурации) и в целом пока всё хорошо.
извините, я что то не смог найти это в блоге. не ткнете носом, если не сложно? :-)
нашел.
Видимо и меня так же ждет этот вариант.
Добрый день !
Вопрос относительно сертификатов. Для RDS созданы сертификаты доменным ЦС. OID стоят соответсвующие Client Authentication (1.3.6.1.5.5.7.3.2), Server Authentication (1.3.6.1.5.5.7.3.1).
В настройках сертификата указаны все используемые SAN серверов с ролями RDS. Сертификаты применены в настройках фермы.
По факту при запуске приложения из RD Web вылетает окно предупреждения, указан самоподписанный сертификат сервера, а не указанный в настройках фермы, подписанный выдающим ЦС.
Куда копать ? почему используется самоподписанный вместо указанного доменного ?
Спасибо.
Проверьте сертификат в IIS для вашего адреса на вэбсервере.
Обратная ссылка: Виртуализированная терминальная ферма NLB на базе Server 2012 R2 в режиме IGMP Multicast | Nixlie /
Алексей, добрый день! Не сталкивались ли вы с такой проблемой?.... Поднял ферму из двух серверов и кластера sql (always on). Делаю тесты на отказоустойчивость, но ферма отказывается нормально работать. т.е. если пользователь залогинился на одном из серверов и выключить этот сервер например отключив питаение, а не корректно завершив его работу, то этот пользователь не может попасть на другой сервер в ферме. Вроде бы подключается долго думает но потом выдаёт ошибку (удаленному рабочему столу не удалось подключиться к удаленному компьютеру по одной из следующих причин.....) Но если корректно сделать выход из системы и выключить терминальник правильно, то пользователь может зайти на другой и без проблем. Пробовал sql 2014 always on и без кластеризации и sql 2008 не помогло.
Используйте Windows Server 2012 R2 и рекомендованную MS конфигурацию с использованием DNS RR вместо NLB.
Да. кластер устанавливался на Windows Server 2012 R2 со всеми обновлениями и пробовал DNS RR.
Андрей, смогли побороть проблему? У меня аналогичная вам ситуация...Перепробовал все варианты.
то же самое. Кластер просто показывает что сеанс пользователя активен на том сервере который выключен и я вно пытается долбиться именно на него
>>Set-RDWorkspace -Name "Приложения RemoteApp" -ConnectionBroker KOM-AD01-RDS21.holding.com
а для Windows 2008R2 есть аналог?
Имя "Set-RDWorkspace" не распознано как имя командлета, функции, файла скрипта или выполняемой программы. Проверьте пра
вильность написания имени, а также наличие и правильность пути, после чего повторите попытку.
Здравствуйте Алексей, спасибо за труд, очень полезная страница. Удачи в будущем
Вопросы такие:
KOM-AD01-RDSNLB это у вас виртуальный адрес? Если правильно понял.
И в SQL кластере плюс две машины?
Всё верно.
Добрый Вечер Алексей.
После добавления второго Broker сервера в HA он автоматом будет работат в режиме HA?
Да.
Алексей а это нормально что на сервере где я создовал sessionsost ферму, так сказать вывеска видна RDS_FARM например а на втором sessionhost сервере ее нету.
Но когда создовал collection установка пошла на обоих sessionhost серверах.
https://www.dropbox.com/s/ewy35kocmi1wtwa/farmproblem.JPG?dl=0
RDS_FARM на Вашем скриншоте это всего лишь группа серверов созданная в консоли Server Manager. То есть, это простое логическое объединение нескольких серверов для отображения в консоли. Если Вам удобно, Вы можете создать такую группу и на втором сервере. В любом случае, управление параметрами фермы RDS выполняется через узел консоли "Remote Desktop Server"
Добрый день! А имеет ли значение расположение sessionsost и сonnectionbroker. могут ли они находиться в разных подсетях допустим sessionsost 10.10.10.10-13 сonnectionbroker 10.10.11.10. Сети объединены туннелем gre.
По идее не имеет. Брокер это же по сути просто учётчик сеансов и перенаправитель.
В тестовой среду столкнулся с ошибкой при попытке подключения к приложению. DNS запись устарела.
Здравствуйте Алексей, я установил 2 Broker и 3 Session Host сервера и один SQL, Broker сервера добавил в HA они у меня показывают High Availability, создаю collection с Session Host серверами с UPD дисками подключаюс профил юзера добавляется,вроде все нормально , но после перезагрузки всех серверов вход в Session Host серверы сопроваждется созданием Temprorary Profile и выходит вот такое.
https://www.dropbox.com/s/4b42ukcs6d90fbq/nocon.JPG?dl=0
P.S При инсталлировании ни одной ошибки не вышло.
Я не понимаю о чём Вы говорите. Пишите в форум http://forum.it-kb.ru/
В данной статье было:
"На следующем шаге определяемся с тем, хотим ли мы использовать новую технологию Windows Server 2012 – User profile disks (UPD), которая, как я понял, предлагается в качестве альтернативы механизму перемещаемых профилей — Roaming User Profiles. Новая технология подразумевает централизованное хранение файлов пользователя в отдельных VHD дисках, которые располагаются где-то на выделенном файловом ресурсе. В силу того, что на данный момент нет уверенности в стабильности работы данного механизма из-за полученной информации в обсуждении Windows Server 2012 RDS — [User Profile Disk] VS [Roaming Profiles + Folder Redirection] я решил пока не использовать данный функционал и поэтому он не будет рассмотрен в данной заметке."
И реально технология UPD дисков сырая, об ошибки уже известно давно, но она не исправлена.
Можно еще попытаться решить http://pei.com/2013/05/temporary-profiles-on-server-2012-rds/
А по принскрину: посмотрите, чтоб на вкладке "Все серверы" были добавлены все сервера задействованные в ферме.
Отличная статья. Спасибо, Алексей.
А не подскажете, изменится ли содержимое "строка подключения к базе данных", если инстанс SQL-сервера не стандартный?
Имя экземпляра можно указать в SQL-алиасе. Для наглядности: https://blog.it-kb.ru/wp-content/uploads/2014/05/image_thumb25.png
Спасибо, помогло.
Есть ещё вариант. Если у Вас именованный экземпляр SQL Server работает на нестандартном порту, например, 1433, то строка подключения может иметь следующий вид:
DRIVER=SQL Server Native Client 11.0;SERVER=TCP:SQLSERVER.holding.com,1433;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDS-Connection-BrokerПроверено на Windows Server 2012 R2
Еще один вопросик.
При загрузке файла сертификата *.cer в Personal/Registry сертификат появляется без ключа (открытый), соотв. и экспортировать его не получается. Можете что-нибудь подсказать?
В описании я не уделил отдельного внимания тому, что импортировать готовый сертификат нужно на том-же сервере, на котором до этого генерировался запрос на выдачу сертификата (то есть на том сервере RDS, где выполнялась команда CertReq –New RequestPolicy.inf RequestFile.req). Тогда сертификат в хранилище сертификатов на этой системе будет связан с закрытым ключом и после этого появится возможность его экспорта вместе с закрытым ключом для последующего распространения на другие хосты фермы RDS.
В Pending Requests сертификат действительно закрытый, но! При импорте выданного CA сертификата *.cer в Personal/Registry, из Pending Requests сертификат не исчезает.
Всем спасибо за участие и извините за беспокойство!
Проблема была из-за того, что рутовый сертификат не был добавлен в доверенные корневые центры сертификации.
Сем-ё-ё-ё-н Семёныч... :)
Сначала вам нужно экспортировать сертификат в формате pfx.
До выгрузки в pfx я как раз и не дошел. Сделал запрос в Root CA, получил от него сертификат. Загружаю его в Personal/Registry. Он загружается без ключика. Т.е. выгрузить в pfx уже не получится.
добрый день, как правильней поступить и как поведет себя ферма? Если я соберу кластер (для NLB), и создам в ферме несколько "коллекций" (конкретно 3) для разных групп пользователей. Есть в этом смысл или правильней создать несколько ферм? смогут ли различные пользователи подключаться к разным коллекциям по одному IP? поддерживает ли подобный функционал broker?
Из практики могу порекомендовать использовать не Windows Server 2012 RDS с NLB, а Windows Server 2012 R2 RDS c DNS RR. Разные коллекции, полагаю, нужно разносить по разным фермам.
Подскажите пожалуйста. А можно подключаться к RDS ферме через mstsc обычный не скачивая перед этим файлик подключения к ферме через вебку? Как-то вручную.
Добрый день! Столкнулся с такой проблемой:
Развернул ферму: 2 сервера (на каждом роли брокера + терминальные + web) все это с балансировкой через NLB. При тестировании, захожу через rdweb в приложение. Смотрю на каком сервере сеанс. Выключаю этот сервер и.... Переподключение не происходит. Подумал что проблема в NLB. Сделал аналогично то же самое через Round Robin DNS - проблема осталась. Решил что возможно проблема в том, что совмещены роли брокера и служб терминалов + web. Вынес брокера на отдельный сервер. Проблема остается...Есть идеи - из-за чего не происходит реконнект?
P.S. если закрыть зависшее RemoteApp приложение которое не перепоключилось - то новое уже не открывается или висит в окне Добро пожаловать... Так же в оснастке СОЕДИНЕНИЯ на сервере-брокере, тот сеанс который я наблюдаю - всегда в статусе Активен.
Очень здорово написано.
Есть несколько комментариев, по опыту проектов по RDS
1) Roaming profiles это зло, они бьются. Лучше использовать новую возможность с профильными дисками для коллекций. Только для самого профиля. Остальное - folder redirection. Помогает оно еще и для Legacy Apps, которые хотят тупо букву диска.
2) Несколько RDWA это круто, но редактировать их отдельно неудобно, вероятность расхождения. Вижу два варианта - DFS-R папки RDWeb, или же IIS Shared Configuration
3) Было бы очень здорово почитать ваше видение, как настраивать RemoteFX USB Redirection для ферм RDSH.
В целом по изложенному могу сказать, что в конечном итоге ушёл от такой конфигурации в силу разных причин (ранее писал уже в комментариях). Сейчас используем ферму Windows Server 2012 R2 с родным DNS RR (без NLB), и в целом всё работает успешно.
1. За несколько лет эксплуатации Roaming profiles (с 2008 R2 до 2012) на ферме примерно с 600 профилями проблемы были всего пару раз, и то по причине человеческого фактора. Никаких претензий к этой технологии у меня особых не было. UPD тоже хорошая вещь, - год уже юзаем на 2012 R2 - полёт нормальный.
2. Ну это кому как нравится. Сами RDWA не так уж и часто правятся для того, чтобы утяжелять всю конструкцию ещё и такими вещами как DFS-R/IIS Shared Configuration внося при этом дополнительные компоненты потенциального отказа.
3. Не имел дела с RemoteFX (не было надобности).
Спасибо.
По 1 согласен, дело предпочтений. Сложность с профилми возникает когда ферм много, возникает масса лишнего в реестре. В моих масштабах я пришел к Profile Disks + UE-V
По 3 - понимаю, что копать корявую технологию дело неблагодарное. Мне потребовалось у двух заказчиков реализовывать проброс ключей (госзакупки и eToken) в терминальные приложения. Это нетривиально и нигде не описано отдельно от VDI, но работает.
Соответственно подхожу к 2. Тут хотел бы запросить мнения. У меня проект по миграции нескольких ферм XenApp 4.x/5.x на среду WS2012R2 - и пока не ясно справимся ли RDS+APP-V+UE-V или таки будет XenApp 7.6. Пользователей ферм немногим более 150000. Серверов Citrix сейчас около 5000. К новому проекту требование сократить в 10-20 раз за счет более мощных ВМ и масштабируемости новой ОС. Соответственно, говоря о настройке пяти RDSWA я готов делать руками, но если их тысяча(и)? И некоторые хотфиксы меняют настройки RDWeb, - как потом руками править? Оттого и идут мысли про DFS.
Но еще больше мыслей все же о выносе RDMS/RDCB/RDWA отдельно от самих RDSH. Расскажите предысторию, почему пришли к совмещению ролей? И до какого количества серверов вы бы и далее рекомендовали расширять данную архитектуру.
4. Отдельный вопрос возник по лицензированию SQL. Я правильно понимаю, что RDCB является аггрегатором, и SQL CAL нужен на каждый RDCB? Пробую посчитать, начиная с какого количества серверов в прошлом вопросе это становится уже дороже чем 2/3 выделенных сервера управления (ОС бесплатна, ибо внизу датацентр, так что цена это вопрос ресурсов и обслуживания)
Хотите поговорить, пишите пожалуйста на форум http://forum.it-kb.ru/viewforum.php?f=4, чтобы не захламлять комментарии, а то здесь их итак уже с избытком.
Алексей, в статье указано:
>В силу того, что на данный момент нет уверенности в стабильности работы данного механизма из-за >полученной информации в обсуждении Windows Server 2012 RDS — [User Profile Disk] VS [Roaming Profiles >+ Folder Redirection] я решил пока не использовать данный функционал и поэтому он не будет рассмотрен >в данной заметке.
а в комментарии пишите:
>UPD тоже хорошая вещь, — год уже юзаем на 2012 R2 — полёт нормальный.
Как-то решается проблема с залоченными UPD файлами? У меня на ферма из 4 серверов (1 шлюз+брокер (на нем сетевой ресурс с UPD) и 3 rds). Включены и перемещаемые каталоги.
Так проблема воспроизводилась практически со 100% вероятностью, если пользователь залогинен в ферме и в этот момент перегрузить сервер на котором UPD либо отключить питание у сервера,.
Никто не сталкивался с проблемой описаной мной выше?
2 сервера (на каждом роли брокера + терминальные + web) все это с балансировкой через NLB. При тестировании, захожу через rdweb в приложение. Смотрю на каком сервере сеанс. Выключаю этот сервер и…. Переподключение не происходит. Подумал что проблема в NLB. Сделал аналогично то же самое через Round Robin DNS — проблема осталась. Решил что возможно проблема в том, что совмещены роли брокера и служб терминалов + web. Вынес брокера на отдельный сервер. Проблема остается…Есть идеи — из-за чего не происходит реконнект?
P.S. если закрыть зависшее RemoteApp приложение которое не перепоключилось — то новое уже не открывается или висит в окне Добро пожаловать… Так же в оснастке СОЕДИНЕНИЯ на сервере-брокере, тот сеанс который я наблюдаю — всегда в статусе Активен.
P.S. если сделать плановую перезагрузку - проблема не наблюдается. Такое ощущение, что при жестком падении сервера, брокер не понимает что делать с резко пропавшим сеансом...
Автоматом пользователь не переключается. Нужно чтоб пользователь запросил переподключение.
Попробуйте политику установить, чтоб после закрытия приложения сеанс завершался:
Политики\Административные шаблоны\Компоненты Windows/Службы удаленных рабочих столов/Узел сеансов удаленных рабочих столов/Ограничение сеансов по времени\Задать предел времени для выхода из сеансов RemoteApp
Добрый день !
Совершенно аналогичная ситуация. За исключением, что не используем rdweb.
Нашлось ли решение ?
задал - но этот параметр подходит если пользователь руками закрыл RemoteApp. А если сервер упал - отвалилась сеть, выключился и т.п. - то брокер видит что сеанс есть на неактивном сервере и почему то не закрывает его и пользователь не может повторно подключиться.
Замечал некоторые странности поведения брокера на Windows Server 2012 с применением NLB. Если Вы используете WS2012, то попробуйте перебраться на WS2012 R2 с DNS RR (без NLB), так чтобы по крайней мере Ваше конфигурация была поддерживаемой Microsoft и потом можно будет смело обращаться в саппорт если проблема останется.
проблема остается. собрал ферму на 2008 R2 - аналогичная ситуация - брокер продолжает видеть сеанс на недоступном сервере - но при этом грамотно отправляет повторный запрос пользователя на доступный узел.
если вырубить сервер на котором сеанс, уж больно долго (секунд 30) клиент думает прежде чем закрыть remoteapp.
кстати, не подскажете что пришло на смену Диспетчеру системных ресурсов (wsrm в 2008 R2) в сервере 2012 R2.
нет нормального диспетчера. павершел-скриптами приходиться смотреть и управлять. могу поделиться.
поделитесь если труда не составит
у меня они примитивные. вот такую штуку нашел. http://www.lazywinadmin.com/2014/10/powershell-gui-lazyts-terminal-services.html
А почему нету ничего про сервера лицензирования?
Огромное спасибо за статью.
Дошел до момента отправки запроса сертификата и получил ошибку следующего содержания: В запросе отсутствует информация о шаблоне сертификата. 0x80094801 (-2146875391 certsrv_e_no_cert_type). Модуль политики отверг запрос 0х80094801, Запрос не содержит расширения шаблона сертификата или атрибута запроса CertificateTemplate.
Пробовал гуглить по коду ошибки, но там в основном шаблоны для вебсервера
Помогите пожалуйста решить данную проблему
Читайте предыдущие комментарии.
Добрый день. Выполнил настройку фермы по вашей замечательной инструкции. Единственное отличие в именах и в том, что я не хотел бы использовать сертификаты выданные внутренним ЦС, а хотел бы использовать для всех сервисов wildcard сертификат *.firma.ru, выданный публичным коммерческим УЦ.
Но т.к. сертификат выдан на *.firma.ru, а внутреннее пространство имен firma.local, то столкнулся с проблемой "name missmatch" при запуске RemoteApp приложений. Там где это можно было настроить, настроил имена вида server.firma.ru, используя split-DNS, но всё-равно при подключении к RemoteApp, происходит обращение к "внутреннему" имени сервера.
Подскажите пожалуйста, может быть знаете, как её убрать? Можно где-нибудь перенастроить подключение с "внутренних" имён типа server.firma.local на "внешние" типа server.firma.ru?
Продемонстрировал ошибку на скриншотах https://www.dropbox.com/sh/dipqtad2122zn5a/AAA6lROjOn1EgVPvkGjm-pgra?dl=0
В общем, мне пришлось разобрать RDS ферму и NLB кластер. После чего собрать всё заново, но чуть по другому. Вместо NLB, я использовал Round robin DNS. Вместо нескольких терминальных серверов на которых все роли были совмещены, использовал разделение ролей по отдельным серверам. Теперь у меня несколько отдельных серверов с ролью connection broker'ов и несколько host session серверов. На SSO установлен wildcard сертификат выданный внутренним УЦ, а на публикацию приложений wildcard выданный публичным коммерческии УЦ. Теперь запуск RemoteApp приложений происходит нормально, никаких предупреждений и запросов на ввод учетных данных не появляется.
Вопрос - какую точку входа по RDP надо использовать , если у меня тонкий бездисковый клиент и можно указать только адрес RDP соединения ? С сохранением отказоустойчивости.
Никак не перейти на ферму терминальных серверов из-за следующей проблемы: существует две группы пользователей терминального сервера, которые находятся в разных VLAN (сами сервера находятся в VLAN1 но имеют интерфейс и в VLAN2) при подключении пользователя из VLAN2, он первый раз нормально подключается, но при повторном он уже никак не хочет подключаться. Мои исследования показали что при повторном подключении брокер ищет имя ноды где был пользователь подключен ранее и отдает ему IP адрес этой ноды, но только из 1 влана (возможно я где-то ошибаюсь в выводах или настройках).
Собственно хотел спросить, есть ли положительный опыт использования фермы терминальных серверов (20012к2) с возможностью подключения пользователей из разных VLAN'ов?
Да работает. Оставьте 1 днс А запись для хоста фермы , либо прописывайте маршруты на ферме
С днс у меня ничего не получилось, а вот с маршрутами я не пробовал, может и получится. Спасибо.
Добрый день. А с помощью чего вы рисуете такие схемы? Как на первой картинке из статьи?
Microsoft Visio
а что за шаблон элементов?
Большое спасибо за статью! Для тестирования возможностей настроил ферму из 2 серверов (пока что без кластера NLB). Разворачивал всё с первого сервера test1, добавил второй test2, перевёл в режим высокой доступности. Всё понятно, всё получилось. Интересует прежде всего восстанавливаемость всей фермы после отказа одного из серверов. Переустановил для теста ОС на test1 (из схемы его специально не удалял), но не могу понять, как теперь его вернуть в строй в ту же ферму, разворачивая уже с сервера test2. Аналогичными действиями (добавление сервера в диаграмме фермы) добавить переустановленный сервер не даёт. Пробую разные способы, но пока безуспешно. MsSQL на отдельном от этих 2-х серверов.
Вроде бы разобрался. Нужно поставить на новом сервере (или переустановленном) роль узла сеансов удалённых рабочих столов, а добавление ролей посредника узла сеансов и веб-доступа выполнить в диаграмме фермы с работающего в ферме сервера.
Коллеги, а кто-нибудь смог настроить механизм прозрачного входа Single sign-on (SSO) не только при обращении к веб-узлу RDWA, но и дальше, когда выбранное приложение запускается в сеансе RDP. Вход без авторизации на страницу RDWA я сделал, а вот дальше не получается.
Да. Тут у вас должно приложение поддерживать Windows авторизацию.
Например, 1С - работает.
Алексей, доброго времени суток. Может подскажете кто. Собрал ферму тестовую. Структура такова - DNS RR + RDCB два сервера(на них же и RDW) в режиме высокой доступности + три сервера RDSB физических 2х-процессорных 12 юнитовых. Профили юзеров - UPD. Так вот вопрос. Можно ли с помощью например того же DFS использовать сервера RDSH, расшарить на всех трех папку, настроить репликацию и использовать их? Теоритически, там можно собрать будет RAID10 из 8 дисков SATA Int. И хватит ли пропускной способности 4х гиабитных интерфейсов?
Вы хотите использовать перемещаемые профили, расположив их на тех-же серверах RDSH? Да ещё и DFS сюда приплести??. По моему это полное извращение, и предсказать как такая конфигурация будет работать, наверно не решатся даже на "Битве экстрасенсов".
Просто я пока не очень понимаю как это все организовать. потому как денег много не дадут.
Алексей. Так скажите, что не так то? DFS зло? Так на сколько я понимаю у Вас тут тоже оно используется? Или репликация вещь не хорошая?
Я согласен с Алексеем. Сами подумайте. Учтем тот факт, что DFS синхронизируется виртуальный диск с профилем только после того как пользователь завершил сеанс. Второй момент DFS реплицировать должен будет по всем вашим серверам RDSH.
В итоге получаем:
1. Пользователь может разлогиниться на одном сервере и войти на другой, а синхронизация еще не прошла или не успела закончиться в зависимости от того как быстро он решил зайти, на какой сервер его кинет в этот раз и еще куча моментов. Но такая ситуация будет 100%. А именно конфликты репликаций и пропадание данных. На файловых же серверах можно выставить в приоритет один сервер, который будет реплицировать на второй и в случаее падания первого перехватит роль.
2. Нагрузка на сеть. Т. к. каждое изменение должно будет реплицироваться на каждый RDSH.
Данная схема возможно только в том случае если количесво ваших RDSH 2 шт. и путь к виртуальным дискам вы указываете все равно сетевой а не локальный. Само собой в DFS сервере вы выставите приоритетный сервер один ... и Пользователи будут мапить свои диски всегда только с одного файлового сервера по сетевому пути, а не с того на который вошли.
Так. А если складировать профили на одном из серверов? А второй делать холодную реплику тем же DFS или тупо бекап с помощью встроенного функционала Windows Server. В случае чего просто переключаю в настройках на другую папку на тором таком же сервере и все долно будет дальше работать. Ну не автоматом, но хоть так. Больше 600 тыр мне на это не дают все равно.
НУ в тестовой среде у меня работает.. с 7 пользователями на виртуалках все работает. Понимаю что при нагрузках будет как то по другому. То есть Вы уверены, что для профилей все таки надо использовать сервера в файловом кластере?? Просто так угораем на винде достаточно сильно ибо только винсервер - 200 тыр и это не считая еще двух серверов железа. Попробовал положить профили vhdx на хранилище Synology - не прокатило конечно, FS нужна NTFS, которую можно там получить только через ISCSI.
Если нет виртуализации, то поднять файловый сервер на винде и расшарить папку, что может быть проще?
Есть виртуализация, но она то тут причем?.. Ваш вариант самый простой, но совсем не отказоустойчивый. По-этой причине надо два получается файловых сервера. А если два, то уже совсем другие деньги (( Или я что то не понимаю?
Ну если есть прослойка виртуализации, к примеру ESXi, то можно подключить по любому протоколу, кроме CIFS конечно любую хранилку, в том числе и synology, к примеру NFS или в вашем случае iSCSI будет выгодней с 1Гбит каналами. Создать на ней виртуалку с сервером или даже двумя файловыми серверами, включить на хранилке дедуплекацию для экономии места, объеденить в файловый кластер или настроить dfs репликацию (репликация виртуальных дисков с профилями пользователей будет происходить только тогда, когда эти виртуальные диски будут свободны, а именно когда пользователь разлогинится).
Тем самым получаем.
1. Независим от протокола по которому подключаем массив для хранения.
2. Высокую доступность. Простоту миграции между хостами этих виртуальных файловых серверов, т. к. даже сами виртуалки можно положить на синолоджи и пустить по 4-ем 1Гбитным каналам.
3. Отказоустойчивость. Высокую степень защиты самой системы файловых серверов за счет наличия двух файловых серверов.
4. Дедуплекация поможет решить проблему с недостатком места.
5. Ну и в идеале куда-то это все дело бекапить. Т. к. единственное узкое и небезопасное место получилась синолоджи.
У меня была идея такая. НО все равно на виртуалки ставить ОС.. А они стоят денег. Одна что то как то страшно, а два на два разных хостовых сервера - это уже много. Да и честно говоря мне не очень нравится идея с ISCSI Очень часто он по разным причинам не подключается автоматом и отваливается. По мне так получается проще купить сервер с дохлым процом 16 гигами оперативы и 14 дисковыми юнитами. Вообще не понимаю почему автор заметки забраковал первоначальную идею? не уж то так сильно жрет процессор и память файловая составляющая? Ведь диски для всего этого дела разные. Я только за сеть переживаю, но не думаю что реально там будет большой трафик..
Писал, писал ... сайт разорвал соединение и все пропало :(
Короче:
1. Виндовый сервер можно заменить FreeNAS и т. д.
2. iSCSI хороший протокол, и просто так не падает, почитай те про тонкости настройки. Темболее для Вас он выгоднее чем NFS с 1Гбитными каналами.
3. Купить дополнительный сервер никогда не помешает, дальше все в Ваших руках.
Так. По очереди..
1. FreeNas не пойдет, ведь там разделы нельзя делать NTFS насколько я помню.По этому он не лучше Synology.
2. Да все верно настроено. Но при рестарте, что бывает часто, у нас тут с электричеством беда не всегда все успевает нормально запуститься (( Да и все равно внутри сервера подключенное железно лучше. Оптика типа FC хорошо, но у нас такого не будет никогда )))
3. Купить ДА.. Но сейчас есть задача внедрить чтобы на это денег дали . Главное чтобы денег дали, а чем дороже тем шансов меньше.
4. Про DFS понял.. Не подумал про эти косяки с реплакацией. Действительно может случиться беда. Но тогда вопрос остается открытым - варианта с отказоустойчивым файловым хранилищем нет?
Настроил по инструкции тестовую ферму из 3 серверов + SQL(пока без сертификатов). Вместо NLB использую DNS RR. Все развернуто в виртуальной среде VMware.
Эксперимент: подключаю 6 пользователей к ферме. RDCB раскидывает по 2 пользователя на каждый RDSH. Отключаю от сети один из серверов. 2 пользователя отваливаются. Пытаюсь подключиться снова — RDCB запрашивает авторизацию, а после успешной авторизации не происходит создание новой сессии на другом RDSH. Клиент просто не может установить соединение.
Сессии «отвалившегося» сервера продолжают фигурировать в списке, закрыть их не получается. Пользователи не могут работать.
Если я правильно понимаю ситуацию, RDCB проводит авторизацию, видит, что у пользователя уже есть активная сессия и пытается переправить пользователя на «мертвый» сервер.
Google молчит. Натыкался на несколько подомных случаев, но все они остались без ответа.
Да, похоже не у Вас одного такая ситуация, когда RDCB редиректит на мертвый хост. Есть мнение, что такое поведение из-за совмещенных ролей RDCB и Session Host и механизм перестает корректно отрабатывать. https://social.technet.microsoft.com/Forums/windowsserver/en-US/757c747f-b390-4f0a-aeb2-493400f6029a/windows-server-2012-r2-session-broker-offline-server-detection?forum=winserverTS
А еще нельзя делать ha rdcb и нацеливать его на ha sql размещенном на тех же узлах что и брокер. Брокер не видит sql.
Сергей, на мой взгляд, скрещивать DFS-R с перемещаемыми профилями идея скверная. Если есть 3 мощных сервера, то почему бы не сделать из них 3 хоста виртуализации и сделать все нужные серверы (RDSH/RDCB/FS) виртуальными. Хранилище с ISCSI использовать для общей дисковой ёмкости для построения кластеров Hyper-V и FS.
Виртуализировать RDSH мне точно не хочется. Терять в производительности не хочется.. Сейчас один из таких серверов тянет 120 юзеров активных, при этом он еле справляется и реально тормозит. второй 90.. Сейчас куплено 350 юзеров, то есть все сервера будут загружены по 110-120 юзеров и этом прямо тяжело и без виртуализации. RDCB виртуализирую, ибо на них не будет никакой нагрузки как я понимаю, они чистые посредники. Синолоджи тухловаты для построения кластера, его можно только как файловое хранилище использовать. Вообще я отказался от виртуализации в Exchange. И тут мне кажется виртуализировать можно только RDCB. А может вообще не делать перемещаемые профили?? правда беда будет если накроется один из них..
Полная виртуализация всех сервисов это удобно и правильно. Вопрос лишь в корректности распределения нагрузок. Нравятся вам железные серверы, ради бога. Тогда не спрашивайте, как сшить десять шапок из трёх маленьких шкурок :)
Ой.. Не, все виртуализировать это хорошо когда блейды, когда виндатацентры.. А мне нет смысла.. У меня как гугле сейчас.. Огромное колличество мелких серверов. Смысл виртуализировать если на него все равно больше двух виртуалок не разместишь нормально.
я новичок в этом деле... вот хоть ты тресни не работает строка подключения к SQL.. пишет что БД недоступна с посредника.
Пишите на форум
Доброго времени суток Алексей. У меня имеется два хоста с WS 2012 R2 Hyper-V. Стоит задача развернуть отказоустойчивую ферму RDS на трех виртуальных машинах WS 2012 R2 с перемещаемыми профилями. Скажите - какую схему балансировки предпочесть ,обычный RDCB или + NLB ?
То есть сам кластер виртуальных машин на Hyper-V+ отказоустойчивая виртуализация RDS с балансировкой нагрузки. Общее количество пользователей , кто работает с удаленными рабочими столами- где то 170. Есть ли у вас что-то похожее из настроек, что посоветуете ?
Спасибо!
Здравствуйте Дмитрий.
С NLB не рекомендую связываться вообще.
Используйте DNS RR балансировку для RDCB.
Серверы с роль RDCB отделяйте от серверов с ролью RDSH. В такой конфигурации "непоняток" в поведении RDS будет меньше всего.
Я про это всё уже писал ранее в комментариях.
извиняюсь, может пропустил, а почему с NLB не стоит связываться ?
Ваша статья пойдет для моей задачи (выборочно) ?
Спасибо!
Ну это не мне решать, а Вам :)
Да я хотел узнать- есть ли у вас статья для построение фермы RDSH+RDCB+DNS RR и все это для Windows Server 2012 R2 ?
Спасибо!
Описанные манипуляции можно взять за основу, откинув часть про NLB. Что касается построения классической схемы с DNS RR, то про нюансы читайте следующие статьи про RDS в блоге.
Да, спасибо.Просто в подавляющем большинстве , даже на англоязычных страницах, почему то все заточены именно на HA RDCB.А что же без HA и без SQL просто два, или три RDCB не поставить, либо это для повышения отказоустойчивости ? Если RDWeb и RemoteAPP не нужен, а нужно только одно, что бы пользователи попадали на свой рабочий стол и имели бы все те же папки и документы на всех трех RDSH и в случае отказа одного из RDSH сессии были бы перенаправлены на оставшиеся при помощи RDCB+DNS RR.
При схеме работы RDS HA из двух серверов со всеми ролями, при отключении одного из серверов, нет возможности завершить зависшие сессии работающих пользователей. Никаким доступным способом, ни через PowerShell ни через GUI. И даже перезагрузка оставшегося рабочего брокера не решает проблему. Т.е. для того, чтобы отключить зависших пользователей необходимо разобрать ферму. Вот обсуждение, к которому хочу привлечь Ваше внимание https://social.technet.microsoft.com/Forums/ru-RU/2372c220-47eb-4d96-b12a-39fe4f699120/rds-ha-?forum=WS8ru
Момент действительно интересен. Влезать в переписку на технете не стал. Ждем ответа от Microsoft. Но на мой взгляд надо ковырять SQL базу конект брокеров. У нас лично я не поднимал HA конект брокеров. Они на сколько я помню должны подключаться к одной и тоже базе, а так как SQL кластера у нас нет, все равно остается одна точка отказа. Так что я выбрал просто бекапить один единственный конект брокер :)
Коллеги, способ есть. Как правильно заметил AlektroNik, необходимо лезть в SQL базу CB. Нужно дать ему (брокеру) понять, что одного из серверов больше нет. В случае возникновения вышеописанной ситуации мне помогает небольшой скрипт. Здесь Servername - имя "упавшего" сервера.
delete from EnvironmentProperty where EnvironmentId in (select id from Environment where name='Servername');
delete from Environment where name='Servername ';
delete from TargetProperty where targetid in (select id from target where name='Servername ');
delete from TargetIp where targetid in (select id from target where name=' Servername');
delete from session where targetid in (select id from target where name=' Servername')
delete from target where name='Servername ';
Используйте на свой страх и риск. Я проверял 3 раза, помогало.
Как часто брокер проверят доступность SH ? Этот интервал уменьшить как-то можно?
А их и не надо завершать, отвиснут при перезапуске ВМ на другой ноде кластера Hyper-V.
Добрый день коллеги!
Да, неправильно выразился по поводу переключения на другой RDSH в случае падения ноды кластера. Но все таки сессия оживет, при перезапуске ВМ с RDSH на другой ноде кластера Hyper-V.
Но плохо что нет какого-то официального решения на предмет - если ВМ не может запуститься, а пользователи были залогинены на этом RDSH- и как тут корректно "отстрелить сессии" , что бы пользователи использовали другой EDSH ? И GPO cо своими настройками неактивности сессий так же не поможет- в случае падения самой ВМ..
Есть решения ?
Коллеги, подскажите по такому вопросу. У меня для удаленного доступа к ферме работает шлюз удаленных рабочих столов. Так получилось, что пришлось его включить и для локальных адресов. Это было сделано для одного важного человека с Макбуком, чтобы он, не меняя настройки подключения, входил на ферму и внутри офиса и снаружи. Но для других сотрудников входить изнутри через шлюз не надо и поэтому через групповую политику я запретил использовать шлюз. В итоге, если любой сотрудник запускает RDP-клиент и подключается к ферме, то подключение через шлюз не идет, НО, при попытке войти в опубликованное приложение RemoteApp через браузер или через распространенный ярлык, соединение всё равно идет через шлюз.
Вопрос: как отключить шлюз при входе в приложение RemoteApp?
Чет, по-моему, Игорь вы перемудрили. Возможно я просто не до понял весь план :)
1. Для того, чтобы пользователи одинаково могли подключаться и с внутренней сети и снаружи можно воспользоваться DNS. Т. е. прописываем одинаково внешнее имя, к примеру, rds.domain.ru на внешнем DNS 200.200.200.200 и на внутреннем 10.10.10.10. Знаю что есть проблема указать внешнее имя ... но это не проблема :), вот решение https://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80
2. В настройках ярлыков, которые вы распространяете, можно настроить использовать шлюз или нет. У меня, на пример, настроено использовать шлюз, но не использовать его для локальных адресов. А для пользователей. Скорей всего есть возможность редактировать генерируемые ярлыки через реестр, именно там хранятся настройки для этих ярлыков.
Сейчас постараюсь объяснить подробнее :)
Доступ на ферму снаружи без VPN возможен только через шлюз удаленных рабочих столов, имеющий имя rdgw.company.ru. Это имя прописано во внешней зоне DNS и разрешается отовсюду. В RDP-клиенте Windows есть галочка - не использовать шлюз из локальной сети, что позволяет не меняя настроек подключаться из офиса без шлюза, а снаружи через шлюз. Для этого не надо прописывать одинаковое имя во внешней и внутренней зонах. Более того, внутреннее имя фермы вообще не светится наружу. Наружу смотрит только шлюз.
Но в RDP-клиенте Макбука нет такой галочки и поэтому надо либо делать 2 соединения (изнутри и снаружи), либо подключаться по VPN. Но человек упёрся и не хочет, поэтому пришлось разрешить доступ через шлюз из локальной сети.
Как в настройках ярлыков указать не использовать шлюз? Ярлык RemoteApp - это запуск rdp-клиента mstsc.exe с определенными параметрами, например "%systemroot%\system32\mstsc.exe "C:\Users\user.name\AppData\Roaming\Microsoft\Workspaces\{9EA9CB68-5ED3-4BC1-8D86-92F8E0F0A81E}\Resource\Excel 2016 (Work Resources).rdp"
Какой параметр ему указать, чтобы не использовать шлюз?
Самое интересное то, что я через ГПО запретил для всех использовать шлюз изнутри и если просто запустить mstsc.exe, то вкладка со шлюзом серая, туда нельзя внести изменения и шлюза там нет.
Но RemoteApp видимо подключается как-то по-своему :)
1. Я имел введу что если прописать во внутреннем DNS сервере запись rdgw.company.ru = 10.10.10.10, то галочка "не использовать шлюз из локальной сети" работать будет, иначе будет резолвить rdgw.company.ru = 200.200.200.200 и всех подряд будет кидать через шлюз, т. к. будет видеть интернетовский IP. Ну возможно у вас так и сделано :)
2. Я не пойму почему проблема с человеком на маке, а изменить Вам нужно ярлыки на винде. Хотя и догадываюсь, что именно по тому, что у Вас именно не корректно отрабатывает галочка "не использовать шлюз из локальной сети", собственно причина описана в первом пункте. И вы так сказать из-за того, что на маке настроить не получается решили пойти от обратного и перенастроить тогда для всех остальных.
3. Просмотреть параметры можно открыв rdp ярлык банально в блокноте. Параметр, которым можно отключить "gatewayusagemethod:i:0" и удалить два последних параметра, которые за подпись отвечают "signscope" и "signature" иначе будет ругаться что ярлык не действителен. Данный rdp потом можно ручками раздать. НО как я уже говорил ранее такая фишка не прокатит, если пользователь скачает ярлык с портала сам, данный ярлык можно поправить самому зайдя в реестр, тогда будет все красиво и с подписями.
4. GPO скорей всего просто блокирует вкладку настроек, наврятли GPO настолько крут и безрассуден чтобы поменять параметры внутри подписанного rdp файла (после чего он соответственно не будет работать) или запретить 443 порт для пользователя ... сомневаюсь в общем. А вот то, что оно влияет просто на mstsc.exe и запуск его с параметрами это нормально, так и должно быть, но не *.rdp.
P. S. Если нужна будет помощь в поиске параметров в реестре, напишите, гляну.
rdgw.company.ru у меня прописан и во внешней и во внутренней зонах, как вы правильно сказали.
С клиентами RDP от Microsoft как раз нет проблем из-за наличия в настройках "волшебной" галочки. Если она стоит, то при подключении изнутри, RDP-клиент игнорирует шлюз и подключается на сервера фермы напрямую. А вот с того же самого ноутбука снаружи подключение идет через шлюз.
Более того, до этого случая с Макбуком в настройках шлюза стоял запрет на внутренние подключения.
А на Макбуке такой галочки нет и мне пришлось включить шлюз для внутренних подключений и прописать в настройках клиента на маке доступ через шлюз, и теперь ему не приходится менять настройки в зависимости от того, где он находится.
Теперь проблем на Маке нет, а есть проблема, что кликая на ярлык опубликованного приложения RemoteApp, соединение идет через шлюз, а не напрямую.
Это неудобно вдвойне, так как во-первых, перестала работать сквозная авторизация SSO, а во-вторых это просто нелогично, ходить через шлюз из локальной сети, где сервера и так доступны.
Ярлыки приложений RemoteApp у меня распространяются автоматом через скрипт (клиенты Windows 7) как написано здесь - https://gallery.technet.microsoft.com/scriptcenter/313a95b3-a698-4bb0-9ed6-d89a47eacc72
Как сделать так, чтобы в ярлыках параметр gatewayusagemethod автоматически был как вы написали в нуле, а не в двойке как у меня?
Делать это вручную нереально.
Спасибо.
А мой совет с редактированием ярлыков в реестре не помог?
Как их редактировать в реестре? Ярлыки опубликованных приложений RemoteApp у меня распространяются автоматически средствами скрипта power shell c файлом параметров, как указано по ссылке. В Windows 8 это делается через ГПО, но в семёрке такой политики нет и приходится делать через скрипт.
В итоге его выполнения, у юзеров появляются ярлыки в разделе "подключения к удаленным рабочим столам".
В реестре клиентских компов нет параметров этих ярлыков. Поэтому я не совсем понимаю ваш совет.
Мне нужно понять механизм формирования этого ярлыка и как сделать так, чтобы во всех ярлыках было: «gatewayusagemethod:i:0»
То, что можно открыть ярлык в блокноте и изменить 1 на 0 понятно, но это ручной труд.
Так, походу надо это менять в реестре на стороне сервера сеансов (он же у меня сервер веб-доступа), а не на стороне клиента. Там у каждого опубликованного приложения RemoteApp есть своя ветка. Сейчас попробую изменить и по результатам отпишусь.
1. Вчера не было времени отписаться
2. А кто говорил, что менять реестр надо на стороне клиента? Куча статей по настройке RDS, включая вчерашнюю или позавчерашнюю статью Максимова Алексея и везде указываются ветки реестра именно серверной стороны. Само собой на стороне сервера, и при том на стороне сервера с ролью Connection Broker. Рад, что всего лишь с третьего раза упоминания реестра, вы меня услышали и начали двигаться в нужном направлении :)
Вот ветка на сервере с ролью Connection Broker:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\\Applications\]
Вот параметр который формирует файл *.rdp:
"RDPFileContents"
Движок wordpress удалил часть пути в ветке :)
Повтор.
Вот ветка на сервере с ролью Connection Broker:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\"Коллекция"\Applications\"Приложение"]
Вот параметр который формирует файл *.rdp:
«RDPFileContents»
Я подозреваю, что эти параметры изначально берутся от настройки самой Коллекции, так что я бы предложил еще подумать на тему изменения настоек именно коллекции, а для пользователя мака сделать отдельный RDP файлик (лень перечитывать, вроде вы все равно создавали отдельный файлик для маковода).
AlektroNik, спасибо. Я опубликовал тестовое приложение и на всех серверах-брокерах изменил указанные настройки реестра, в итоге доступ к нему пошел минуя шлюз :)
Про единые настройки коллекции RDS_Collection тоже подумал. Скорее всего достаточно будет изменить в одном месте здесь для всех опубликованных приложений.
ps: для маковода я вообще не распространяю приложения, он тупо заходит на удаленный рабочий стол через rdp-клиент.
В любом случае, большое спасибо за помощь.
Был рад помочь.
А как вы даете доступ макаводу к коллекции RDS_Collection. Если мне память не изменяет, подключиться к серверу с ролью RDSH после ввода его в коллекцию невозможно (консольный сеанс не считаю). Но Алексей Максимов 04.04 написал статью по поводу того как это можно обойти (https://blog.it-kb.ru/2016/04/04/rds-connection-broker-redirection-session-hint-tsvurl-defaulttsvurl-workaround-for-incompatible-and-legacy-rdclient-rdp-clients-on-windows-server-2012-r2/). Я правда пока не тестил.
Интересно, а как вы решили эту проблему?
Да никак собственно. Маковод не пользуется опубликованными приложениями. Он заходит на ферму через RDP-клиент и тупо запускает приложение на своем удаленном рабочем столе.
Доступ же к коллекции через доставку ярлыков используют клиенты Windows.
Есть еще web-app, но он как-то не пользуется популярностью.
У меня все 8 серверов с ролью и хоста, и брокера + один сервер с ролью шлюза и лицензирования.
Виталий мне тут подсказывает, что под OS X есть нативный RDP клиент от Microsoft, который поддерживает в том числе и получение RemoteApp приложений из фида RDS. О подробностях можете распросить его на форуме.
Клиент-то есть, только вот со шлюзом он работать, зараза не умеет. Да и в домен данный Мак не входит.
Коллеги приветствую!
Первым делом спасибо за материал , очень доступно и просто!
Может Вы поможете мне решить задачу ?
Есть сервер с роль RDSH. Второй сервер – роли RD Connection Broker, Licensing. Оба WS 2012 R2.
Надо – определенной группе пользователей дать право на просмотр удаленных сессий (Shadow). При этом они не должны быть админами ни на первом, ни на втором сервере. Реализуем ли данный вопрос ?
Спасибо!
Возможно запоздал, но до этого идей небыло, а тут чет поперло :)
Наткнулся тут на фразу с какого-то сайта:
"Подключаться к чужим сессиям может только администратор сервера. Делегировать эти права обычным пользователем нельзя"
Попробуйте реализовать данный функционал через "Удаленный помощника Windows" в группу админов там точно добавлять не надо
Друзья мои, ещё раз прошу не писать в ветку комментариев вопросы не связанные с темой статьи. Все подобные комментарии будут удаляться. Убедительно прошу вас пользоваться нашими Форумом для подобных обсуждений.
Да, извините. Черканул в форум..
Пытаюсь настроить RD Web SSO на Win 2012 R2 - не получается.
1. "выключим анонимную аутентификацию (Anonymous Authentication), аутентификацию на основе формы (Forms Authentication) и включим Windows Authentication" - сделано на обоих серверах RD WEB
2. iisreset /noforce - сделано на обоих серверах RD WEB
3. На клиенте назначен в свойствах безопасности IE "Автоматический вход с текущим именем пользователя и паролем" (без данной настройки появляется маленькое окошко ввода логина и пароля)
Итог. Все равно попадает на оригинальную форму входа RDS WEB. Такое ощущение что не выключена настройка IIS аутентификацию на основе формы (Forms Authentication), но в Win 2012 R2 она выключена по умолчанию на папке RDWeb, я ее в принципе и не трогал.
Кто-нибудь сталкивался с такой проблемой? Может на 2012 R2 как-то залочили или еще чего?
Вопрос РЕШЕН.
Не обратил внимание, а еще точнее перечитав не мало статей все они указывают на то, что нужно настройки проверки подлинности указывать для папки RDWeb, а надо для RDWeb > Pages (здесь в статье все правильно).
Заметил, кстати, что в статье не упоминается "в свойствах безопасности IE «Автоматический вход с текущим именем пользователя и паролем» (без данной настройки появляется маленькое окошко ввода логина и пароля)". Т. е. если вы не включите параметр "Параметры входа" (В самом IE называется просто "Вход") любым из доступных методов, то автоматического входа все равно не произойдет.
Было бы неплохо добавить это в статью.
Вот моя конкретная рекомендация:
Проще всего раздать групповой политикой назначение сайта с веб админкой (тот сервер, который вы в адресной строке вписываете, чтобы в веб интерфейс попасть) в зону "Местной интрасети" (цифра "1"). "Параметры входа" в разделе "Зона интрасети" вообще можно не трогать т. к. если этот параметр политики не настроен, параметр входа имеет значение "Автоматический вход только в зону интрасети".
Путь размещения параметров:
Конфигурация пользователя или Конфигурация компьютера/Шаблоны администрирования/Компоненты Windows/Internet Explorer/Панель управления браузером/Вкладка «Безопасность»
Параметр:
Список назначений зоны для веб-сайтов - Включить
Имя значения: rdwh.company.com
Значение: 1
Доброго времени суток Алексей. Назначенные нами сертификаты будут автоматически установлены на все сервера, которые участвуют в нашем RDS развёртывании.
К сожалению и увы не вижу что бы сертификат распространился на узлы коллекции.С брокером все хорошо он принимает запрос и не ругается более, но а вот узлы в коллекции как ругались на свой собственный сертификат, так и продолжают. Я в ручную даже импортировал PFX сертификат в personal и пробовал в Remote Desctop их так же импортировать, перезагружал, выключал файервол- все напрасно...ругань осталось.
Что-то еще можно попробовать сделать ?
Спасибо!.
Вобчем хоть ты тресни, а узлы сеансов выдают самозаверенный сертифкат! Удаление и пеерзаведение в домен так же не помогает...куда еще копать ?
AlektroNik, привет. Хочешь прикол? Я изменил на всех серверах фермы настройку gatewayusagemethod с 1 на 0 для одного приложения и запросы на него пошли миную шлюз. Но, через некоторое время параметр опять стал 1 :)
Привет. Я подозреваю, что это могло произойти из-за того, что заходили в приложение и, даже если не меняли свойства разворачиваемого приложения, просто нажали "ОК" и подтянулись настройки из коллекции. В принципе я подозревал, что так может случиться, поэтому сразу и предложил подумать над изменением именно коллекции или распространять ярлыки не через веб-интерфейс, а через скрипты (грубо говоря копируя клиенту на рабочий стол или в программы, есть аналогичная политика). Ну и третий вариант. Создать политику правки реестра с действием "Замена" этих параметров реестра, тогда каждые 40 минут (если мне не изменяет память именно через столько происходит автоматическое обновление политик) будет происходить замена автоматом. Можно попробовать пойти дальше и создать напрямую в реестре отдельное приложение таким способом, что бы его не правили или не видели из панели управления Коллекцией ... а еще можно поиграться с правами безопасности, чтобы данный параметр реестра могли править только Вы, а сам сервер не мог ...
Ну вот как-то так :)
Алексей, как вы делали отказоустойчивый экземпляр SQL Server?
Так же хотелось бы подробно услышать, почему вас не устроила схема с NLB? В комментариях вы писали про сетевые проблемы, это и все? Или что-то не прокатило в работе службы RDCB на NLB?
Если использовать механизм с RR DNS, то как Вы убираете из работы недоступные серверы в случае отказа или мэинтейнса? Руками из DNS? Так же из этого вопроса вытекает еще один. Если использовать RR DNS, и клиенты все внешние, то нужно вешать роль RD Gateway, её так же надо дублировать для обеспечения бесперебойности сервиса. У Вас был такой опыт?
БД брокера у меня лежит в двух-узловом кластере SQL Server 2012.
C NLB узлы брокера вели себя непредсказуемо, например могли продолжать перенаправлять клиентов на упавший узел RDSH. Это всё было в пору WS2012. Новую ферму на WS2012R2 поднимали уже с нативными механизмами DNS RR. При падении узла всё работает штатно, клиенты практически сразу начинают перенаправляться на другие доступные узлы RDSH без каких-то ручных шаманств. С RDGW дела к сожалению не имел, а может к счастью :)
Не очень понятно, как брокер понимает, что хост сессий перестал быть доступен и не возвращает клиентам его IP?
В базе данных брокера есть информация о последних отметках времени проверки доступности хостов. Пример есть здесь http://www.virtualizationadmin.com/articles-tutorials/vdi-articles/microsoft-hyper-v/taking-closer-look-rd-connection-broker-high-availability-windows-server-2012.html
NLB лично мне тоже не понравился ... пробовал как-то больно нестабильно работал и геморойно по сравнению с RR DNS.
По поводу RD Gateway. Лично у меня алиас ссылает на 2 IP от двух разных RD Gateway. Подключаюсь к одному (к какому именно видно через консоль управление). Тушу у сервака сеть ... бывает несколько секунд заминка и автоматическое подключение ко второму, а бывает даже и окошко переподключения не успевает появиться. Просто поделился практикой.
На сегодняшний день я исхожу из мысли, что серверы с ролью RDCB должны быть отделены от серверов с ролью RDSH.
Мой опыт показывает, что именно в такой конфигурации связка RDS + DNS RR работает так, как должна, без каких-либо странностей.
Например, 2 сервера RDCB записаны с одним виртуальным именем в DNS (это и есть имя фермы брокера)
Хосты RDSH стоят особняком, например их 5 штук.
1) RDP-клиент посылает запрос в DNS на разрешение FQDN имени фермы брокера.
2) DNS сервер отдаёт клиенту несколько IP адресов серверов с ролью брокера
(при каждом новом запросе клиента приоритет выдаваемых DNS сервером IP-адресов меняется, таким образом обеспечивается элементарная балансировка нагрузки между хостами брокера. это и есть суть DNS RR)
3) RDP-клиент пытается подключиться к первому IP из списка, который получил из DNS. Если брокер с таким IP недоступен, клиент моментально пытается использовать следующий IP (задержек при этом практически не ощущается).
4) Подключившись к живому брокеру RDCB клиент получает от него информацию о том, к какому хосту RDSH он должен подключиться и перенаправляется на этот хост.
(брокер имеет базу данных, где хранит информацию о всех активных клиентских сессиях на всех хостах RDSH и сам определяет какой хост менее нагружен по количеству сессий и направляет клиента именно на менее нагруженный RDSH)
До WS2012 логика работы брокера была несколько иная. И высоко-доступный брокер там работал в модели активный/пассивный (использовалась функциональность Windows Failover Clustering)
Для старых версий Windows Server есть наглядная картинка, например здесь https://technet.microsoft.com/en-us/library/cc772418(v=ws.10).aspx
Начиная с WS2012 брокер изменил модель на активный/активный, и Windows Failover Clustering теперь больше не используется, вместо этого предлагается простая балансировка между активными брокерами с помощью DNS RR
Вот очень наглядное объяснение с картинкой https://blogs.technet.microsoft.com/enterprisemobility/2012/06/27/rd-connection-broker-high-availability-in-windows-server-2012/
А вот это просто шикарное объяснение. Спасибо!
Добрый день! В статье никак не отражен факт настройки брандмауэра. В тестовой среде настраиваю ферму с использованием NLB, первая машина в кластере, но другие не добавляются по причине того, что невозможно их обнаружить. При выключении брандмауэра хосты находятся, но хотелось бы иметь фаер включённым. Впрочем, прочитав все комментарии понимаю, что автор ушёл с NLB на RR и активно советует последовать примеру. Однако - там стоит ожидать подвоха с фаером?
Всё верно.
Не думаю.
коллеги, у меня есть 2 отдельных хоста с ролью RD Web Access. Юзерам нужно предоставить единый URL. Нужно создавать отдельную RR DNS-запись для этого или можно использовать RR DNS-запись фермы в RD CB ???
У меня используется одно и тоже FQDN-имя (RR) и для Connection Broker и для Web Access (эти роли совмещены в рамках одного узла).
Добрый день.
Используя связку RDS + DNS RR с условием, что "серверы с ролью RDCB, отделены от серверов с ролью RDSH". Получится ли сделать разделение пользователей на разные серверы в соответствии с определенной коллекцией.
Допустим есть user1 (группа Group1) и user2 (группа Group2), так же я 3 сервера - RDS1, RDS2, RDS3
есть две коллекции Collection1 (доступна пользователям из Group1, сервера RDS1, RDS2) и Collection2 (доступна пользователям из Group2, сервера RDS3).
Можно как то сделать чтоб user1 ходил либо на RDS1 либо на RDS2, а пользователь user2 на RDS3.
Здравствуйте Сергей. Здесь в комментариях этот вопрос поднимался уже не однократно.
Из комментариев понял что разнесением ролей RDCB и RDSH решается проблема с зависанием сессий и переподключением пользователей. А вот про распределение пользователей на разные сервера на основе сеансов/групп пользователей ответа не нашел, кроме того как "а зачем это делать вообще"
Насколько я понимаю, архитектура RDS такова, что классическое использование подразумевает принцип "1 Коллекция = 1 Брокер (или ферма Брокеров)". Дополнительно можете почитать рассуждения на эту тему здесь и здесь.
у меня на 2016 есть НА-брокер и 8 хостов. для коллекция1 юзается 6 серверов, для коллекция2 - 2 сервера. доступ в коллекция1 предосавлен лишь для группа1 ну и со 2й коллекцией аналогично. т.е. решена такая же задача в лоб )
Тогда возникает ряд вопросов. Пользователи используют один и тот же ярлык для подключения к ферме брокера или Вы делали какую-то модификацию RDP-файлов под разные коллекции? Каким образом брокер понимает, что пользователя user1 нужно направить на любой из доступных серверов именно коллекции Collection1, а не Collection2 ?
Алексей Максимов, РДП-файлов два.
Я в коллекции четко задал группу которая может к ней подключаться.Юзеры разбросаны по группам
Ну и теперь ещё осветите различие параметров, которые отличаются в Ваших RDP-файлах для двух разных коллекций, чтобы у Сергея, который задал вопрос, была полная логическая цепочка того, как построить такое разделение используя единый пул брокеров.
параметром loadbalanceinfo:s:tsv:
там соответствующие коллекции прописаны. Но сам РДП-файл я руками не менял. скачал их с веб-апп
Как я понимаю, данном случае сперва работает DNS RR и выдается определенный сервер, а уж потом проверяется в соответствии с коллекцией и группой, можно ли пользователю к нему подключится.
Т.е user1 подключается, DNS RR дает ему допустим сервер RDS3, а потом проверяется коллекция и права доступа в ней (а там доступ только для Group2 с пользователем user2). В результате пользователь user1 не может подключиться, пока DNS RR не выдаст ему сервер RDS1 или RDS2
Добрый день, все настроил по статье, 2 Server 2012 R2 + NLB. из внутренней сети все подключаются по имени NLB кластера прекрасно, RDSH распределяет как нужно. Из внешки проброшен порт на 3389 кластера - тут начинаются проблемы - часть пользователей входит на сервер1, часть нет. Я пробую с телефона под пользователем testtest - входит на сервер1, под пользователем testtest1 висит 30 сек черный экран и отключается сеанс. В логах принимающего сервера вижу подключение "Клиент посредника подключений к удаленному рабочему столу успешно перенаправил пользователя ..." но в логах этого конечного сервера нет ничего о том, что он что то принимает (или где смотреть я не нашел). Видимо первое мое подключение отправило пользователя на сервер1 и он сразу принял подключение, а второго пользователя перенаправляет - но второй сервер его уже не принимает и в логах я нигде найти не могу почему
Алексей, здравствуйте.
Строю высокую доступность на сервере 2016. Вопрос по брокерам. Собрал на двух серверах GW-01 и GW-02 HA, общее имя remote.contoso.com. Нужно создать коллекцию средствами powershell , что нужно указывать в качестве брокера ? GW-01,GW-02 или общее имя remote.contoso.com ? С общим не получается, мол, такой брокер не существует.
Здравствуйте, Стас. Не имел дела с WS2016, поэтому адекватный ответ дать не смогу.
Алексей приветствую, делаю под статье настройку, однако при заведении группу куда я включил все хосты для фермы используется проверки Windows, и появляется ошибка о которой в начале комментарием ктото говорил, в логах скуля вот это "Ошибка входа пользователя "". Причина: не удалось выполнить вход с использованием проверки подлинности SQL Server. Конфигурация сервера поддерживает только проверку подлинности Windows. [КЛИЕНТ: IP хоста терминалов]
Как быть? как ему сказать что надо использовать проверку подлинности windows?
Вам вероятно надо завести имена входа в свойствах MSSQL. И выдать права на нужную базу. А если база еще не создана - выдать db_creator, а после отобрать, оставить только public и db_owner на нужной базе. Добавить логины - развернуть сервер в консоли, выбрать Безопасность - Имена входа. Там можно добавить имя, группу, управляемую сервисную учетку.
NLB - это балансер на уровне сети, а не на уровне приложения. Вы сами в вопросе ответили себе. Одних пользователей в одну коллекцию, других - в другую. Они даже не увидят неположенные себе коллекции
Сергей спасибо, да пропустил какие-то моменты, но собрался, посмотрел еще раз и провернул - теперь все работает. Остался вопрос - я сделал две коллекции, для разных типов пользователей и помести лв них разные серверы сессий. использовал так же разные группы, можно ли как то разруливать доступ на разные коллекции обращаясь к одному имени NLB и в соответствии с вхождением в ту или иную группу перенаправлять пользователя между коллекциями?
мне нужна одна точка входа, и управления принадлежностью к группе. средствами виннлб понятно не получится. так каким же образом этого добиться используя одну точку входа?
только два разных имени и объяснив одним куда им идти и другим так же показав другую дорогу?
Есть развертывание - в него входят сервера, в развертывании есть несколько коллекций, каждая коллекция для определенной группы пользователей, есть имя для входа - rds.contoso.com - каждый, кто придет сюда за ресурсами, будет видеть то, что разрешено видеть его группе. Или я в корне не понимаю вопроса.
Я хочу получить в итоге ситуацию когда одни пользователи входящие в группу к примеру rdp-adm ходили на один сервер используя одно и тоже имя к примеру "terminal" а другие используя пользователи входящие в другую группу rdp-user и используя для входа тоже самое имя terminal попадали уже на другой сервер. Вот этот функционал возможно реализовать?
вот эта схема у меня как раз и не работает.
я только сертификаты и иконки не менял как по статье остальное все как должно быть.
Пользователь входящий в группу rdp-adm должен идти по кластерному имени terminal через програмульку mstsc. В коллекции я выделил для этой группу сервер term-app02.
Пользователь входящий в группу rdp-usr должен идти по кластерному имени terminal через програмульку mstsc. В коллекции я выделил для этой группу сервер term-app03.
по факту происходит следующее, программа несколько раз переспрашивает пароль а потом говорит что пользователь не имеет права ходить на терминал. так как смотрит почему то в сторону группы rdp-usr хотя пользователь входит в группу rdp-adm и должен попадать на term-app02, но попадает он судя по ошибке на term-app03 где коллекция для пользователей..... как еще обьяснить....
Развертывание так не работает. Вы не сможете подключиться, используя простой rdp-файл или имя перебора в mstsc - так вы всегда будете ломиться именно на сами брокеры подключений, а не в ресурсы развертывания. Если вы обратили внимание, то развертывание невозможно без серверов веб-доступа, потому что именно там на страницах заготовлены специальные параметры подключения к ферме - к ресурсам коллекции.
или я многого хочу от терминальной фермы на базе мыкрософты?
эх... понятно. значит есть вероятность веб-доступа по той или иной коллекции ромт-апп
мой опыт использования показал, что без веб-доступа все это сильно геморнее для конечных пользователей. И сам веб доступ надо использовать через Internet Explorer с разрешением специального rdp-плагина (всплывает при посещении страницы веб-доступа)
Да согласен. проще будет просто всем инструкции разослать. и тыкать потом ими в монитор - читайте инструкции куда вам можно а куда вам ходу нет.
В этом нет необходимости особой. Правильно настроенный веб-доступ и шлюз будут авторизовать человека только в браузере, а вся дальнейшая авторизация не потребуется. Пользователи заходят на веб-доступ, вводят логин пароль, выбирают ресурс и все - магия.
магия портиться клиентами из под remine rdp. Линукс банально скачивает рдп каждый раз при ображщении к ресурсы в ремот-аппе. и с сертификатом постоянные проблемы даже из инт-пки. клиенты иногда просят врод визио прожекты... но религия не позвоялет им переползти просто на винды не не утомлять глаза админам. посему и думал что рдс наше все .. оказалось не все.
Можно для сторонних клиентов добавлять ресурс-фиды. Если, конечно, клиенты их поддерживают. MAC OS без проблем, под Linux, я думаю, их тоже найти не проблема. Ресурс фид настраивается так: в приложение вписывается ссылка на ресурсы вида https://rds.contoso.com/rdweb/feed/webfeed.aspx, логин и пароль, и клиент выкачаивает себе все ресурсы из коллекции
есть так же вариант импортировать в такие клиенты скачанный через google chrome rdp-файл из веб-доступа, но это уже костыль.
Если кол-я одна можно зають параметр DefaultTsvUrl REG_SZ tsv://vmresource.1.
если много то можно пробовать извращаться разными ДНСами как сделал я :)
Но у меня тонкие клиенты на Вин7 Ебм. как будет на remine rdp - хз
https://isazonov.wordpress.com/2014/02/06/windows-server-2012-r2-remote-desktop-коллекция-по-умолчанию
Целый день меня эта спам атака добивала.
Во-первых все написано в статье (серии статей) по поводу групп и коллекций, достаточно просто прочитать.
Во-вторых что мешает просто взять без всяких вебок создать ярлыки и разослать их хоть по почте хоть групповыми политиками ... да хоть скриптом прям на месте под конкретного пользователя делать, все зависит от среды. По поводу Remmina также можно спокойно создать и скопировать файл подключения. Раз любят Linux значит и работать с ним элементарно должны уметь. Файлы подключений складываются в /home/USER_NAME/.local/share/remmina.
P. S. Единственный момент, который здесь не освещали (хотя я могу и ошибаться) это настройка RDGW. Особое внимание нужно обратить на то, что в устройствах, на которые, нужно разрешить доступ нужно указать все сервера RDSH и RDCB иначе перенаправление будет работать только с настройкой "на любое устройство". (описание пунктов приблизительное, все гуглится).
вопрос с ярлыками, гпо и хождениям по пользователям хотелось как раз избежать настроив группы и ряды серверов. Если спам-атака добивает можно ведь и отписаться от этой части рассылки. всего то..
Ну прям волшебство ... гпо как раз для того и придумано, чтобы не ходить по пользователям. Нет GPO, есть ssh. Пользователи не дают пароль или запрещает политика партии, пусть настривают сами, инструкцию им в руки.
Рассылки можно и отменить и т. д. Но сколько я уже сижу на этом блоге такая атака впервые, я еще мог бы понять если это не обсуждалось или не описывалось. И опять же малоли кому-то действительно понадобится помощь )))
Всем привет, все сделал по инструкции , но на этапе Configure High Availability, выдает ошибку "Не удается создать базу данных". Все перепроверил, хз куда смотреть.....
Алексей, добрый день.
Подскажите, пожалуйста, какие данные пишутся в БД и как рассчитать необходимое дисковое пространство под нее (с учетом роста). Планируется ферма из 40 терминальных серверов на 2000 пользователей.
Здравствуйте, Константин.
В БД хранится информация о брокерах, хостах, активных сессиях брокера, есть какие-то таблицы с логами и т.д. У нас в ферме несколько сотен пользователей, из них одновременно работающих - не больше сотни. Размер базы 80MB/лога 150MB (это за 3 года). Какой будет размер БД в Вашем случае, предсказать не возьмусь. Каких-либо документов по сайзингу БД я не встречал.
Алексей, спасибо! Хоть какие-то цифры полезные - будет от чего "плясать".. Я, к сожалению, тоже не нашел абсолютно никакой информации ни в документации, ни на просторах инета.. ))
Алексей, здравствуйте.
Не смог найти в документации списка необходимых прав в AD для развертывания RDS.. Не поделитесь информацией?
Не знаю, насколько это актуально сегодня, времени прошло достаточно много.
Вообще, перечитывая статью, никак не мог понять, в чём "феншуйность" NLB. И до сих пор не понимаю, ведь RR DNS нормально работает.
В комментариях же видно, что многие получают проблемы, пропадают пинги etc. В одной сети виден, в другой не виден...
Дело в том, что свитчи уровня L3 не допускают подмену MAC адреса, которая происходит при использовании NLB. Они имеют соответствие IP -- MAC. Кода им надо маршрутизировать (InterVLAN Routing) IP, у которого вдруг другой MAC, то они этот пакте отбрасывают. Соответственно, адрес виден в своём VLAN, но не виден в других.
Их надо соответствующим образом настраивать. Указать, что конкретному IP разрешено подобное действие. Делать это необходимо на свитче, к которому непосредственно подключено оборудование, железные серверы с виртуалками.
Команда в Cisco выглядит так
Switch>en
Password:
Switch#conf t
Switch(config)#arp 172.17.56.34 03bf.ac11.3822
Здесь: IP адресу 172.17.56.34 можно иметь MAC 03-bf-ac-11-38-22
MAC Windows назначает сама, при создании кластера. Важно не потерять его в результате, например, перенастройки. Впрочем, можно перепрограммировать оборудование.
Так как синтаксис команды разный для разных версий iOS, то ориентируйтесь на доки вендора. Гуглится легко по ключевым словам, в данном случае по Cisco
Cisco Microsoft Network Load Balancing
Получаем https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/107995-configure-nlb-00.html#anc6
Думаю, что подобное есть и у других вендоров.
По статье. Большое спасибо за труд. Описаны все моменты, которые могут присниться.
Если возможно, какой-нибудь сводный документ по "допиливанию" RDWA. Здесь есть смена названия и логотипа, это хорошо. Но где-то встречал куда как больше настроек, которые, в принципе, облегчают и украшают работу.
Спасибо
Здравствуйте, Павел. Спасибо за развёрнутый комментарий. Здесь в комментариях я уже неоднократно говорил о том, что Microsoft рекомендует для ферм RDCB WS2012R2 использовать именно DNS RR, а решение в WNLB можно рассматривать исключительно в рамках улучшения доступности/балансировки RDWA. А применение WNLB для доступа к ферме RDCB лучше рассматривать как экспериментальное и официально не поддерживаемое. Что касается сводного материала по RDWA, то, чтобы его сделать на базе каких-то сторонних записок (в том числе всё это проверить и подробно описать доступным языком) потребуется отдельное время. У меня пока не было прямой задачи как-то сильно заморачиваться на кастомизации RDWA. То, что уже было проделано и проверено c RDWA описано в разных заметках блога, найти который можно по соответсвующему тэгу RDWA
Спасибо за Ваш ответ, Максим.
Действительно, RR DNS отлично справится с задачей балансировки внутри локальной сети. На каждый новый запрос - новый IP, где уже "слушают".
Но как быть, когда Ферма публикуется в интернет? Выделять под неё n-ное количество IP это смешно, Но, тогда, на одном IP адресе, можно опубликовать только один TCP/443. Значит - проброс только на один сервер. В этом случае, решение NLB просто незаменимо.
Конечно же, правильный выход, это публикация через Reverse Proxy, который к тому же, умеет балансировать внутренние адреса. Но если нет специалиста, или смущает ценник решения, то NLB "из коробки".
Таким образом, я отвечаю на вопрос о "феншуйности". Скорее это не "феншуйность", а решение исходя из имеющейся архитектуры.
Вторым аргументом, может быть невозможность включения Round Robin на сервере DNS по каким-то причинам.
Возможно, стоит сделать в статье короткую оговорку на счёт NLB. Меня этот параграф смущал долгое время.
Отдельное спасибо за ссылку на статьи по RDWA. Видимо, то что надо.
Для публикации в Интернет есть роль RD Gateway, но по ней никаких комментариев не дам, так как пока не имел практического опыта использования.
В этой строке разве не должно быть указано имя кластера KOM-SQLCL
DRIVER=SQL Server Native Client 11.0;SERVER=KOM-AD01-SQL-RDCB.holding.com;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDS_ConnectionBroker
В нашем случае KOM-AD01-SQL-RDCB - это алиас для хоста KOM-SQLCL. То есть в строке подключения может использоваться либо имя хоста, на котором расположен экземпляр SQL Server с базой брокера, либо алиас этого хоста.
Здравствуйте, спасибо за статью!
Возникла следующая проблема, в один прекрасный момент, отмирает NLB интерфейс на ноде (перестаёт пинговаться), хотя в самой оснастки NLB всё зелёное и с виду всё хорошо. Часть пользователей начинают испытывать проблемы с подключением. Методом эксперимента было обнаружено, что если удалить интерфейс из NLB кластера, то он (интерфейс) опять начинает пинговаться. Можно предположить что проблема в NLB кластере, НО, такая инсталляция работало больше года и проблемы начались буквально месяц назад. При чём не на одной ферме. Гугл дал примерно 0 вариантов решения проблемы. Везде пишут что Windows NLB - это дно и не используйте его. А вот как решить уже имеющуюся проблему, инфы что-то не нашёл. Может кто-то сталкивался с таким? Подскажите пожалуйста как решить.
Здравствуйте, шмфт. Откажитесь от Windows NLB в пользу DNS RR. C Windows NLB проблемы неизбежны. Это лишь вопрос времени.
Алексей, спасибо за замечательные статьи. Многое подчерпнул, многие проблемы у себя нашел.
Может подскажите, столкнулся с такой проблемой. Ферма из 2-х нод. Все работает, но после перезагрузки на одной из нод в разделе группа серверов пропадает соседняя нода, т.е. RD0 не видит RD1, ну и соответственно говорит о том, что пул серверов не соответствует находящимся в нем посредникам, и что второй сервер отсутствует в пуле. Руками изменяем группу, добавляем ноду, все в порядке, до следующей перезагрузки.
Столкнулся 1 в 1 с такой проблемой.
1. Если у Вас RD сервера на Hyper-V, то MS в последних обновлениях сломала NLB Unicast.
Решение - https://support.microsoft.com/ru-ru/help/4457133/windows-81-update-kb4457133
2. Проверьте, что у Вас на NLB интерфейсах включен а на управляющих выключен DHCP Spoofing.
Просто шикарная статья, спасибо автору за труды!
Максим, доброго дня.
Подскажите, а если у меня два RDSH хоста в разных подсетях , например 10.50.1.141 в офисе и 10.50.122.141 в датацентре и у этих хостов NLB кластер с ip адресом 10.50.122.200 - то есть адрес кластера из сети датацентра.
При падении одного из хостов (который является членом кластера в датацентре) кластерное имя с ip адресом 10.50.122.200 более не пингуется. Я так понимаю , если нужен NLB кластер состоящий из двух хостов в разных подсетях, то и кластерное имя должно быть зарегистрировано на две A записи из разных подcетей?
Либо WNLB возможен только в одной подсети и для моего решения подойдет только DNS Round Robin ?
Не используйте NLB, Используйте DNS RR. Я про это здесь в комментариях писал уже много раз.
Максим, ок, спасибо!
Максим, а на да один из данных серверов я могу поставить сервер лицензирования, или лучше для этого использовать другой сервер?
Коллеги, доброго времени суток.
Ферму из двух серверов собрал + UPD для профилей пользователей.
Вопрос такой, а ка кто можно "из коробки" мониторить статистику загрузки распределения пользователей по терминальным серверам. Того же брокера например?
Хм, заметил странную вещь- погасил один из серверов, попробовал по имени фермы зайти, проверить при отказе одного сервера. В общем как бы второй сервер доступен, окно аутентификации появляется, но спустя некоторое время подождав подключения, появляется окно RDP что недоступен пк. А как только вбиваешь ip-адрес второго RDSH, пускает. Пробуешь вновь по имени фермы- пускает.
В чем может быть проблема ? Может побаловаться с приоритетами в свойстве коллекции?
Коллеги, всем привет! Коли в процессе задача по созданию очередной фермы, может кому будет интересно+ комментарии, либо корректировка в процессе тестирования. Буду делиться глюками))
Две подсетки в разных локациях, два сервера Srv-RDSH01 сервер в офисе (10.50.1.151/24) и Srv-RDSH02 сервер в датацентре (ДЦ) (10.50.122.151/24 ) в одном домене. DNS Round Robion на общее имя RDS фермы srv-farm.domain.local c теми же ip адресами и TTL 1 сек.
Установлены и совмещены роли RВСB и RDSH на обоих серверах+ каждый является сервером лицензирования (поделен пополам для выдачи лицензий в случае отказа одного из двух).
Для High Availability роли брокера RDCB в сети ДЦ установлены два сервера SQL 2014 Srv-SQL01 (10.50.122.50) и Srv-SQL02 (10.50.122.60) на которых установлен Windows Failover Cluster с общими томами CSV и все это объединено в FCI Sql Cluster. Диски презентованы с СХД через vmware ESXi как RDM диски в виртуальные машины.
Там же на SQL серверах установлены роли File Server из которых собран SOFS с AccessPoint кластерной шарой \\srv-upd\profiles - для хранение UPD перемещаемых профилей и папок с размером каждого профиля не более 7 гигабайт. Общий диск в 900 Gb для кластерной шары так же презентован с СХД через ESXi как RDM. Права для шары автоматически розданы при ее включении в RDS.
Сертификаты от внутреннего УЦ назначены на службы, на оба узлов и на субъект srv-farm.domain.local.
Задача и условия: Два RDS хоста в разных подсетях и локациях принимают подключения пользователей. Профили и папки следуют за пользователями при балансировки подключений между хостами и в случае недоступности одного из них. В реальности недоступность хоста в офисе, где с периодичностью вырубают свет и проиcходят скачки напряжение. Хоть и не так часто, но редко и метко, офис остается без света, либо веерно. Но удаленщики могут работать и должны работать включая RDS через ДЦ.
На данном этапе в подключение для тестового пользователя проходит успешно между RDSH хостами.
Глюки:
1.Словил временный профиль, при попытке монтировать VHDX профиля- когда прав на диск не оказалось (почему то) "пользователь в этот момент вышел из сессии", но диск остался неотмонтированным. После гугления и рекомендаций, вычитал, что надо быть локальным администратором и диск откроется. UDP профиля пока не особо изучил. И пока есть сомнения стоит ли на них переходить со старого доброго движка перемещения профилей через GPO. Посмотрим, что тестирование покажет..
2. При отработке на отказ (пользователь работает в сессии со всеми запущенными приложениями и виртуалка выдергивается из розетки), как я и писал выше, был один такой глюк с переподключением:
"после ввода учетных данных начался процесс подключения (в окне подключения пишет загрузка виртуальной машины), но он спустя какое то время (около 15 секунд) я получил сообщение, что данный пк недоступен или к нему невозможно подключится. Но заметил странную вещь, если зайти на данный узел персонализировано по его ip или имени, то я попадаю на узел. После еще раз пробую подключиться к общему имени фермы- в этот раз пользователь залогинился без проблем на вторую ноду"
Повторил сие данный опыт еще раз- все прошло штатно, то есть при недоступности одной из нод, повторное подключение перенаправило на работающую ноду. Профиль корректно загрузился с кластерной шары. Но проблему считаю плавающей, так как не нашел каких то явных признаков в логах.
Пока как то так. ..
Следующий этап, тестирование 20-30 подключений активной работы в RDS+ AppLocker.
Спасибо автору за статью.
Коллеги, делаю все по статье но при попытке подключится по имени кластера получаю - Подключение не удается установить, поскольку удаленный компьютер, с которым установлена связь, отличается от указанного пользователем. Это может быть связано с тем, что запись в кэше DNS устарела. Попробуйте использовать IP-адрес вместо имени компьютера."
При этом не важно делаю NLB или DNS RR.
Подскажите пожалуйста куда рыть??? Измучился уже, ей богу.
На Server 2022 долго мучался со строкой подключения для ODBC Driver 18 for SQL Server, в итоге заработало так:
Driver={ODBC Driver 18 for SQL Server};Server=FQDN SQL SERVER,1433;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;Database=rds_db;Encrypt=no;