Redircmp windows server 2012

Redircmp windows server 2012

Добрый день! Уважаемые читатели и гости популярного IT блога Pyatilistnik.org. В предыдущий раз мы с вами подробнейшим образом рассмотрели, как самостоятельно проводить диагностику синего экрана Windows, рад что та статья вам понравилась, если вы ее пропустили, то советую наверстать это. В сегодняшней публикации я вам хочу рассказать и показать применение утилит командной строки Redircmp и Redirusr и как благодаря их возможностям вы поможете перенаправить пользователей и компьютеры при создании со стандартных контейнеров Computers и Users на нужные вам. Я покажу сценарии, когда это полезно и применимо.

Описание задачи

Когда у вас в Active Directory вводят в домен новый компьютер или создается скриптом новый пользователь, то по умолчанию их местоположение в иерархии подразделений определено с самого начала, для компьютеров, это контейнер «Computers», а для пользователей, это контейнер «Users«. Вроде бы в этом нет ничего плохого и я с этим соглашусь, но это можно улучшить и сделать более функциональным. Если вы знакомы с инструментом групповых политик, то должны знать, что к контейнерам новые политики, созданные вами не применяются, в этом их ограничение и слабость.

Простой пример, вы добавили новый компьютер в домен, он попал в «Computers». Далее вам по корпоративным стандартам хотелось бы применить к данному компьютеру групповые политики, которые у вас есть на предприятии, напоминаю, что к контейнерам вы это сделать не можете и вам приходится перемещать сам объект в нужную OU, вроде не сложно но согласитесь не так удобно. Теперь представим, что у вас есть SCCM или WDS-сервер с которого идет автоматическая установка новых систем, и если они попадают уже не в контейнер а в OU, то к ним сразу применяются групповые политики, которые уже делают тот минимальный корпоративный стандарт, позволяющий вам их легко администрировать в любом виде, так как вы сразу можете включить RDP или назначить нужные права на доступ, выполнить скрипты и многое другое, потом вам никто не мешает так же перенести объект в нужное месторасположение, с единственной разницей, что он уже будет настроен. Ниже я покажу, как это исправить.

Что такое Redircmp и Redirusr

Чтобы произвести перенаправление пользователей и компьютеров в Active Directory в нужное расположение есть две утилиты командной строки Redircmp и Redirusr.

Redircmp — Перенаправляет контейнер по умолчанию для вновь созданных компьютеров в указанную целевую организационную единицу (OU), чтобы вновь созданные объекты компьютеров создавались в определенной целевой OU, а не в CN=Computers.

Redirusr — Перенаправляет контейнер по умолчанию для вновь созданных пользователей в указанную целевую организационную единицу (OU), чтобы вновь созданные пользовательские объекты создавались в определенной целевой OU, а не в CN=Users.

Данная утилита идет по умолчанию на контроллерах домена, если вы ее хотите поставить на другом сервере, то придется установить Windows Resource Kit.

Читайте также:  Планировщик задач аналог windows

Как проверить контейнеры по умолчанию

Если вы так же как и я давно знакомы с архитектурой Active Directory, то должны знать, что в схеме есть атрибут wellKnownObjects, описывающий какие контейнеры имеют значения по умолчанию, для новых компьютеров и пользователей. Для начала вы можете найти данный атрибут в вашей схеме, подключившись их редактора ADSIEdit.msc в контекст именования имен.


Откройте свойства корневого контейнера и найдите атрибут wellKnownObjects, попытавшись посмотреть его значение вам покажут, что «Не существует зарегистрированного редактора для атрибута этого типа (There is no editor registered to handle this attribute type)». Это означает, что это защита от дурака, чтобы новоявленный системный администратор не натворил дел.


Когда я, что-то не могу сделать в ADSIEdit, то всегда вспоминаю про замечательную утилиту от Марка Русиновича AD Explorer. Она дает большие возможности для просмотра и изменения значений атрибутов Active Directory. Открыв AD Explorer. вам необходимо указать сервер и учетные данные, которые будут использоваться для подключения, если вы работаете в учетной записи с нужными правами, то можете ничего не вводить, утилита сама найдет значения по умолчанию.

Тут вы сразу увидите все составляющие базу данных Active Directory, файл NTDS.dit:

  • Контекст по умолчанию
  • Раздел конфигурации
  • Схема
  • DNS зоны на уровне домена
  • DNS зоны на уровне леса

Выбираете контекст именования и находите там атрибут wellKnownObjects. Смотрим его содержимое, в моем примере оно выглядит вот так:

В самом конце я вижу два контейнера Computers и Users. Тут вы их то же не поменяете.

То же самое можно и посмотреть через оболочку PowerShell. Запустите PowerShell и введите:

Как сменить контейнеры по умолчанию

Чтобы вы могли поменять значения атрибута wellKnownObjects и выставить для новых компьютеров и пользователей контейнер по умолчанию, вы может воспользоваться описанными выше утилитами командной строки redircmp и redirusr.

Предположим, что для компьютеров я хочу сделать OU по умолчанию Client Computers. Для этого смотрим его Distinguished Name и в командной строке от имени администратора введите:


У вас в процессе выполнения команды может выскочить ошибка:


Тут вариантов несколько:

  1. В вашем пути DN присутствуют пробелы, поэтому их нужно брать в кавычки «».
  2. Могут быть лишние проблемы между запятыми, проверьте, что их нет
  3. Удостоверьтесь, что у вас уровень леса не ниже Windows Server 2003. Как узнать и изменить уровень леса, читайте по ссылке
  4. Могут быть проблемы с репликацией, в моем конкретном случае у меня был мертвый контроллер домена, который я удалил из своей инфраструктуры, после очистки метаданных, о его существовании, команда redircmp отработала без проблем.

Так же изменить стандартный контейнер Computers вы можете и через PowerShell, для этого есть вот такая конструкция:

Аналогично мы можем поменять контейнер для пользователя

Скрипт powerShell для смены контейнеров

# Получаем текущие значения (from wellKnownObjects attribute)
$wkos = Get-ADObject -Identity $dnc -pr wellKnownObjects | select -ExpandProperty wellKnownObjects

# Находим наш текущий контейнер для пользователей
$curuwko = $wkos | ? <$_ -like "*OU=Пользователи,*">
# Split the value into its constituent parts
$datusers = $curuwko.split(«:»)

# Находим наш текущий контейнер для компьютера
$curcwko = $wkos | ? <$_ -like "*OU=Client Computers,*">
# Split the value into its constituent parts
$datcomps = $curcwko.split(«:»)

# Заменяем контейнер по умолчанию для пользователей
$newuwko = $datusers[0] + «:» + $datusers[1] + «:» + $datusers[2] + «:» + $newusers
# Заменяем контейнер по умолчанию для компьютера
$newcwko = $datcomps[0] + «:» + $datcomps[1] + «:» + $datcomps[2] + «:» + $newcomps

Читайте также:  Загрузка linux по сети tftp

Теперь откройте AD Explorer и проверьте значение атрибута wellKnownObjects, как видим все удалось.


На этом у меня все, мы с вами познакомились с двумя полезными утилитами Redircmp и Redirusr. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

Redircmp windows server 2012

Доброго времени суток, многоуважаемые инженеры, системные администраторы и просто начинающие пользователи. Рад вас вновь приветствовать на страницах IT блога Pyatilistnik.org. Если вы мой постоянный читатель, то вы заметили, что я очень часто и много пишу про терминальные сервера и RDS фермы. Сегодня я хочу вам показать, как производится управление RDS фермой Windows Server 2012 и Windows Server 16. Я на сто процентов уверен, что данная информация будет вам полезна, так как я часто видел опытных администраторов, кто не знал как это делается, в виду старых знаний и стереотипов, о данной технологии.

Описание ситуации

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

В чем отличие фермы от терминала

Если посмотреть организацию удаленного доступа в Windows Server 2008 R2, то там схема была простой, где-то в сети устанавливался сервер лицензирования удаленных рабочих столов, а уже на нужно из серверов, куда планировалось подключение, ставилась роль «Службы удаленных рабочих столов». Ему назначались лицензии и пользователь подключался.

Если посмотреть концепцию Windows Server 2012 R2 и старше, то выглядит это уже вот так, есть некое виртуальное имя к которому все подключаются, есть серверная роль «Посредник подключения (RD Connection Broker)«, он берет на себя роль распределения нагрузки и количество сеансов пользователей, на сервера удаленного подключения «RD Session Host«, где уже работаю пользователи. Вся эта конструкция объединяется в некий пул. называемый RDS фермой, где легко создать отказоустойчивость на уровне посредников подключения и легко обслуживать хосты конечного подключения.

Схема управления RDS фермой

Тот сотрудник не совсем понимая схему и видя ее впервые, наивно подумал, что все управление Remote Desktop Services фермой осуществляется через посредника подключения (Connection Broker). Он попытался к нему подключиться, но его послали с формулировкой «Удаленный компьютер «имя», попытка подключения к которому выполняется, перенаправляет вас на удаленный компьютер «имя», он то и не знал, что для подключения к нужному хосту фермы нужно использовать специальные ключи.

Далее показав ему, как происходит подключение к посреднику, он попытался отыскать оснастку управления, так как в Windows Server 2008 R2, была именно такая реализация работы, но он там ничего не нашел. Он подглядел у меня, что я управляю RDS, через «Диспетчер серверов». Он его открывает и у него там то же ничего не оказалось, в итоге он побился часок и попросил ему показать. Чтобы знающих людей стало больше и грамотность системных инженеров была больше я вам написал небольшую инструкцию. Не подумайте, что я надменно отнесся к своему коллеге, я просто так же был однажды в на его месте и понимал, что это просто отсутствие опыта, что не смертельно.

Читайте также:  Windows server test questions

Собираем консоль управления RDS фермой

Для управления настройками Remote Desktop Services вам потребуется клиентская операционная система Windows 8.1 или Windows 10, либо это могут быть Windows Server 2012 R2 и выше. Там нам потребуется оснастка «Диспетчер серверов».

Если вы знаете всех участников RDS фермы, то это хорошо, вы немного себе выиграете времени, если нет, то придется слегка пописать команды и помучить DNS-сервер.

Откройте командную строку или запустите PowerShell оболочку. Предположим у вас виртуальное имя для подключения к удаленному рабочему столу TERM. Тут у вас два варианта:

  • Воспользоваться утилитой nslookup
  • Воспользоваться утилитой Resolve-DnsName

И та и другая выдали вам ip-адреса, в которое разрешается ваше виртуальное имя RDS фермы. В моем примере их два. Эти адреса принадлежат посредникам по подключению (Connection Broker), делаем так же запрос:

Стрелками я выделил полученные DNS имена, самое главное мы получили.

Теперь открывает оснастку «Диспетчер серверов» от имени той учетной записи у которой есть права на администрирование RDS фермы. В открывшейся оснастке выберите пункт «Добавить другие серверы для управления»

У вас откроется окно «Добавление серверов», перейдите на вкладку DNS и в поисковой строке укажите нужное имя брокера и нажмите кнопку с изображением лупы. У вас будет осуществлен поиск по базе Active Directory, если такой сервер есть, то он будет отображен в списке. Переносим его в поле выбрано.

Точно так же поступаем и с остальными посредниками подключений к Remote Desktop Services ферме.

У вас начнется процесс добавление в вашу оснастку дополнительных серверов. Когда закончится добавление, то вы увидите, что у вас появились серверные роли, в нашем случае «Службы удаленных рабочих столов» и обратите внимание на иконку «Все серверы», тут стало их уже два.

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

В итоге у меня добавились все мои хосты подключения и сервера лицензирования. Как видите стало 20 серверов.

Переходим в «Службы удаленных рабочих столов», в этот раз у вас уже откроется полноценное управление коллекциями RDS. Вы увидите схему работы, вам будет представлен список всех ваших серверов и кто за какую роль отвечает. Переходим в саму коллекцию.

Попав в коллекцию удаленных рабочих столов, у вас будет несколько областей:

  • Свойства — тут вы зададите права доступа, лимиты и многое другое
  • Подключения — тут будут отображены все ваши сеансы пользователей, в моем примере, это всего 338 человек, так как уже не рабочий день, а вечер пятницы, в пиковое время, эта цифра в районе 950 подключений.
  • Удаленные приложения RemoteApp
  • Серверы узлов — тут вы сможете запрещать или разрешать новые подключения

Так же для удобства администрирования серверов, я вам советую создавать отдельные группы по нужным вам признакам и управлять ими, но об этом уже в другой раз. Либо же вы можете создать группу серверов в Remote Desktop Connection Manager.

Оцените статью