В продолжение темы, ранее описанной в заметке Windows Server 2012 R2 Remote Desktop Connection Broker — Невозможно подключиться к высоко-доступной ферме RDS — Подключение было запрещено… один из комментаторов к этой заметке навёл на идею использовать для подключения к высоко-доступному экземпляру RDCB вместо специально настроенного RDP-файла на стороне клиентов, настройку параметра реестра DefaultTsvUrl на серверах RDCB.
-
Windows Server 2012 R2 Remote Desktop Connection Broker - Подключение было запрещено, так как учетная запись пользователя не имеет прав для удаленного входа в систему.
-
Windows Server 2012 R2 Remote Desktop Web Access - Исчез ярлык на RDP файл для подключения к коллекции сеансов после публикации RemoteApp приложения
Как можно заметить, в коллекции сеансов RDS на Windows Server 2012 R2 при публикации первого RemoteApp приложения изменяется тип коллекции с Session Remote Desktop на Session RemoteApp Programs и при этом с веб-страницы опубликованных приложений RD Web Access исчезает rdp-ярлык для подключения к коллекции сеансов. В контексте прошлой заметки можно столкнуться с ситуацией, когда нужно получить доступ к указанному ярлыку, но при этом убирать с публикации все RemoteApp приложения (чтобы изменился тип коллекции и ярлык снова стал отображаться на веб-странице RD Web Access) нет особого желания. Ryan Mangan в своём блоге подсказал, как можно выйти из подобной ситуации. -
Windows Server 2012 R2 Remote Desktop Connection Broker - Невозможно подключиться к высоко-доступной ферме RDS - Подключение было запрещено…
Наконец-то добрались руки до того, чтобы развернуть новую ферму высоко-доступного RD Connection Broker на базе Windows Server 2012 R2. В отличие от конфигурации, которая описывалась ранее, было решено выполнить разделение ролей RDS и отказаться от использования NLB в пользу DNS Round Robin. При планировании развёртывания акцент был сделан на то, чтобы в итоге получить конфигурацию, которую можно будет считать более или менее поддерживаемой Microsoft. В результате получилась конфигурация из двух виртуальных серверов с совмещенными ролями RD Connection Broker/RD Web Access и пяти виртуальных серверов с выделенной ролью RD Session Host. А в силу того, что роли RD Connection Broker и RD Web Access не сильно требовательны к ресурсам, мы не стали создавать для них выделенные сервера, а установили эти роли на уже работающих серверах App-V 5.0 (с ролями Management Server, Publishing Server и Reporting Server, по аналогии с теми, которые были описаны в заметке App-V 5 for RDS - Разворачиваем инфраструктуру повышенной доступности, только уже на базе Windows Server 2012 R2). Читать далее... -
Публикация приложения RemoteApp на в ферме серверов RDS (Windows Server 2012) на примере КонсультантПлюс
В Windows Server 2012 консоль Server Manager работает таким образом, что при попытке публикации приложения RemoteApp, для которого выбран исполняемый файл расположенный на общем сетевом ресурсе, возникает грозное уведомление о том, что мы можем выбирать исполняемые файлы расположенные только на каком-то конкретном сервере RD Session Host (RDSH)…
-
Remote Desktop Services – Строим отказоустойчивую ферму RD Connection Broker на базе Windows Server 2012
Ранее мы рассматривали пример построения фермы 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
- Устанавливаем языковой пакет
- Настраиваем перенаправление печати -
Восстанавливаем доступность приложений RemoteApp через RD Web Access в ферме серверов RDS после сбоя WMI.
В некоторых ситуациях по разным причинам может произойти поломка установленных разрешений в пространстве имён WMI на серверных системах Windows Server 2008 R2. У нас эта ситуация проявляется на серверах RDS. Есть неподтверждённые пока подозрения на то, что виновником этого может быть клиент SCCM 2012. Проблемы с WMI могут порождать другие проблемы, в частности это отражается на том, что перестаёт корректно работать веб-интерфейс RD Web Access, который отображает опубликованные приложения RemoteApp с неисправных серверов RDSH. В такой ситуации RD Web Access начинает попросту отображать пользователям пустую веб-страницу. -
RDS Web Access - Опция "Я использую личный компьютер…"
При запуске приложений RemoteApp опубликованных через веб-страницу Remote Desktop Services Web Access может последовать запрос авторизации для подключения к удалённому терминальному серверу в том случае, если внизу страницы RD Web Access не включена опция "Я использую личный компьютер, соответствующий политике безопасности моей организации"
Данная опция позволяет осуществить прозрачную передачу учетных данных текущего пользователя, залогинившегося на веб-форму RD Web Access без повторного ввода этих учетных данных. По умолчанию эта опция отключена и если вы используете опубликованные приложения из достоверных источников, например собственных терминальных серверов локальной сети, то возможно вы захотите чтобы по умолчанию данная опция была включена, чтобы не создавать дополнительные сложности пользователям, заставляя их каждый раз включать эту опцию или повторно вводить свои учетные данные. К сожалению мне не удалось найти штатного способа сделать эту опцию включённой по умолчанию и поэтому мы воспользуемся небольшим хаком.
Найдём на сервере RD Web Access файл Default.aspx в каталоге C:WindowsWebRDWebPagesru-RU
Подкаталог в котором нужно искать данный файл может различаться в зависимости от языковой версии используемых веб-страниц. В нашем примере это русскоязычная страница.
Создадим на всякий случай копию файла Default.aspx, сохранив оригинальный файл с изменённым названием, например Default_ORIGINAL.aspx.
В файле Default.aspx в секции
<script runat="server">
найдём строку:
public bool fUserAdmin = false, fConfigPage = false, bShowPublicCheckBox = false, bPrivateMode = false;
Поменяем в этой строке значение переменной bPrivateMode = trueСохраним файл и проверим то что теперь при каждом новом открытии веб-страницы RD Web Access чекбокс включен по умолчанию и не происходит повторных запросов учетных данных.
