Далі починається обов'язкова частина настройки, але напевно теж потрібна.
Створюємо високо-доступний RD Connection Broker
Після закінчення процесу установки ролей в консолі Server Manager і перейдемо на вкладку управління службами Remote Desktop Services> Overview. щоб приступити до створення відмовостійкої конфігурації RD Connection Broker.
На схемі інфраструктури RDS виберемо зображення ролі RD Connection Broker і правою кнопкою миші викличемо меню, в якому виберемо пункт Configure High Availability.
На наступному кроці майстра Configure High Availability заповнюємо значення трьох полів:
У нашому випадку це значення буде мати наступний вигляд:
В ході цього процесу на SQL-сервері буде створена БД високо-доступного примірника RDCB.
Перемкнемося на наш SQL Server з щойно створеної БД і виконаємо пару налаштувань ...
В обов'язковому порядку для SQL-логіна, який ми створювали на підготовчому етапі (KOM-AD01-RDS-Connection-Broker-Computers), потрібно дати роль db_owner для створеної базиRDS_ConnectionBroker
Крім цього, для даного SQL-логіна можна відключити додану раніше серверну роль dbcreator. так як БД вже створена і більше дана привілей цього SQL-логіну не буде потрібно.
Повернемося на наш сервер KOM-AD01-RDS21 і звернемо увагу на те, що в консолі Server Manager в схемі інфраструктури RDS статус ролі RDCB змінився на High Availability Mode
Тепер для того щоб задумана нами зв'язка NLB + RDCB працювала так як потрібно, нам необхідно до-встановити роль RD Connection Broker на решту чотири сервера.
Додаємо сервера в високо-доступний RD Connection Broker
Додавання серверів до високо-доступної конфігурації RDCB робиться через те ж саме контекстне меню в схемі розгортання RDS на сторінці Overview.
Аналогічним чином ми по одному сервера повинні додати роль HA RDCB на все решту сервера, ті. KOM-AD01-RDS23, KOM-AD01-RDS24 і KOM-AD01-RDS25.
Додаємо на сервера роль RD Web Access
Так як ми хочемо мати отказоустойчивую конфігурацію ролі RD Web Access. нам потрібно до-встановити цю роль на решту чотири сервера (на KOM-AD01-RDS21 ця роль вже встановлена). Робимо це у вже знайомому нам місці через майстер додавання ролей
Створюємо колекцію сеансів - Session Collection
Всі наші сервера з роллю RD Session Host ми повинні об'єднати в логічну одиницю - колекцію сеансів (Session Collection). Робимо це в оснащенні Server Manager на вкладці Remote Desktop Services> Collections вибравши задачу Create Session Collection в таблиці перерахування колекцій.
У відкритому майстра створення колекції задамо ім'я колекції і при бажанні опис
Потім вибираємо все сервера, які хочемо зробити членами колекції ...
Далі ми повинні визначити доменну групу безпеки якої буде дозволено підключатися до колекції сеансів. Прибираємо обрану за замовчуванням групу доступу Domain Users і додаємо спеціально створену групу доступу, в нашому випадку KOM-AD01-RDS-AllUsers. обмеживши тим самим коло користувачів які зможуть підключатися до серверів колекції.
А поки не будуть вирішені наявні на даний момент проблеми з UPD будемо використовувати зв'язку технологій Roaming User Profiles і Folder Redirection. настройка яких розглядалася раніше в замітці Remote Desktop Services - Використовуємо перенаправлення профілів користувачів і переміщувані папки
В результаті роботи майстра всі наші сервера успішно додаються в колекцію з попередженнями про те, що бажана настройка групових політик для завдання параметрів RDP на цих серверах ...
Налаштовуємо цифрові сертифікати
При спробі підключення до ферми RD Connection Broker по FQDN-саме кластера NLB клієнти можуть отримувати попередження безпеки, яке говорить про те, що немає довіри сертифікату того сервера сеансів, на який він був перенаправлений. Якщо відкрити властивості цього сертифіката, ми побачимо, що сертифікат створюваний на сервері RDSH за замовчуванням є самоподпісанного. Щоб уникнути таких попереджень нам потрібно створити для розгортання RDS сертифікат підписаний довіреною Центром сертифікації (ЦС), наприклад локальним ізольованим або доменним ЦС. Цей сертифікат після створення ми розгорнемо на всіх серверах ферми.
При створенні запиту на сертифікат потрібно використовувати як мінімум 2 політики застосування:
Хоча в нашій ситуації альтернативні імена в сертифікаті Subject Alternative Name (SAN) мати зовсім необов'язково, я все-таки розгляну варіант створення саме такого сертифіката, тобто щоб крім імені NLB кластера в сертифікаті містилися імена окремих серверів.
Для того щоб наш локальний ЦС міг коректно обробляти запити сертифікатів з SAN він повинен бути налаштований для цього. Про те як це зробити можна прочитати в замітці Remote Desktop Services - Будуємо отказоустойчивую ферму RD Connection Broker
Підготуємо файл параметрів для створення запиту на отримання потрібного нам сертифіката. Це звичайний текстовий файл, назвемо його наприклад RequestPolicy.inf
Вміст цього файлу в нашому прикладі виглядає так: