PC360
Ремонт/настройка ПК и окружающих его устройств.
Настройка контроллера домена на WindowsServer2012.
В предыдущей статье описание подключения и установки сервера.
Нужно отметить, что контроллер домена в нашей сети до этого момента уже существовал на виртуальной машине. Задача состоит в том, чтобы настроить контроллер домена на реальной машине, сделать его вторым резервным, затем передать ему полномочия главного контроллера и отключить (демонтировать) виртуальную машину. Так же за одно осуществится перенос контроллера домена с Windows Server 2008 R2 на более новый Windows Server 2012 R2. Приступим.
Сразу после установки Windows Server 2012 R2 и авторизации под учетной записью администратора на экране открывается приложение «Диспетчер серверов» и предлагает нам настроить сервер. Если он не открылся или случайно закрылся, то найти его можно на панели задач внизу слева.
Нажимаем добавить роли и компоненты.
Установка ролей и компонентов >> Далее.
Выбираем наш сервер >> Далее.
В качестве ролей сервера выбираем DNS-сервер и Доменные службы Active Directory. Как правило, DHCP-сервер идет третьим вместе с двумя предыдущими ролями, однако у нас в сети он не задействован по причине местных обстоятельств.
В разделе «Компоненты» оставляем всё без изменения >> Далее.
Читаем об службах, которые мы добавляем >> Далее.
Подтверждаем выбор и нажимаем >> Установить.
Ждем пока идет установка.
После установки в диспетчере серверов появятся AD DS и DNS. 
Нажимаем на флажок с предупреждением в верхней части окна и выбираем надпись – Повысить роль этого сервера до уровня контроллера домена. 
Откроется мастер настройки доменных служб Active Directory. При выборе операции развертывания отмечаем пункт: Добавить контроллер домена в существующий домен.
Вводим название нашего домена, учетные данные и получаем ошибку – Не удалось связаться с контроллером домена Active Directory для домена «SCRB». Убедитесь что доменное имя DNS введено правильно.
Переходим в настройки сети и в свойствах TCP/IP проверяем, какой введен DNS. DNS-ом должен быть IP-адрес действующего контроллера домена, у нас это 192.168.1.130 (было прописано что-то другое).
Снова пробуем указать сведения о существующем домене. На сей раз ошибка другой тематики – Не удалось войти в домен с указанными учетными данными. Введите действительные учетные данные и попробуйте еще раз.
На самом деле я часто подсматриваю настройки на сайте первоисточника Microsoft. Насчет авторизации там написано, что нужно использовать учетную запись с правами администратора действующего домена.
Значит, применим эту учетную запись.
Когда все настройки введены правильно, при вводе домена можно нажать на кнопку «Выбрать» и наш действующий домен появится в списке. Выбираем его.
На следующем пункте вводим пароль из цифр и букв разного регистра>> Далее.
Следующим пунктом значатся параметры DNS. Оставляем их пока что без изменений. Жмем >> Далее. 
Указываем источник репликации – действующий контроллер домена. Репликация это восстановление (синхронизация) данных Active Directory одного контроллера домена на других. Когда работает репликация изменения в одном контроллере домена (допустим создание нового пользователя) через некоторое время переносятся и во все остальные.
Расположение баз данных AD и файлов оставляем без изменения.
Параметры подготовки >> Далее.
Предоставляется последний шанс проверить параметры. Проверяем, жмем – Далее. Начнется проверка предварительных требований. 
После установки и перезагрузки автоматически начнется репликация. Для того, чтоб в этом убедиться, переходим в Диспетчер серверов >> AD DS. Нажимаем правой кнопкой мыши на наш контроллер домена DCSERVER и выбираем пункт меню – Пользователи и компьютеры Active Directory. 
Откроется оснастка и в директории Managed Service Accounts мы начинаем узнавать знакомых пользователей. Всего в домене у нас пока что около 70 пользователей. Все они со временем появились.
Если зайти в директорию контроллеров доменов, то можно увидеть что их теперь два.
Установка резервного контроллера домена windows 2012 r2
По тем или иным причинам иногда требуется удалить роль «дополнительного» контроллера домена с сервера Windows Server 2012.
Установка дополнительного контроллера домена на базе Windows 2012 R2 (сore)
Желательно это делать полностью корректно и без неприятных последствий.
Процессом понижения роли и удаления служб можно управлять из консоли, но пользуясь новым диспетчером серверов все сделать проще. Итак в диспетчере серверов, в меню Управление нужно выбрать пункт «Удалить роли и компоненты»
Мастер удаления ролей и компонентов предложит на выбор с какого из подключенных серверов нужно произвести удаление.
Далее будет предложен список установленных ролей в котором с удаляемых ролей нужно снять флажок.
После снятия флажка мастер покажет какие сопутствующие средства могут быть так же удалены.
Если уровень роли контроллера домена еще не был понижен мастер сообщит об этом и предложит понизить роль.
Далее мастер настройки доменных служб запросит учетные данные обладающие правами администратора и предложит принудительное удаление роли. Принудительно удалять следует только в крайнем случае поскольку после такого действия придется вычищать метаданные, днс и возможно другие ненужные последствия.
В следующем окне будут показаны сопутствующие роли которые будут удалены.
В процессе понижения роли требуется смена пароля администратора.
Далее показан список производимых изменений и, если этот контроллер домена не последний в домене, то сервер будет присоединен к текущему домену.
В течении нескольких минут будет происходить процесс понижения роли с выводом подробных результатов.
После перезагрузки Windows Server 2012 роль контроллера домена уже удалена, но службы AD DS все еще остались и требуют настройки либо удаления.
Снова в диспетчере серверов, в меню Управление пункт «Удалить роли и компоненты» с удаляемых ролей следует снять флажок.
Подтвердить удаление средств управления.
Если нужно, можно так же удалить ненужные более компоненты, например WINS.
Далее будет предложен список всех производимых изменений в ролях и компонентах, с возможностью автоматической перезагрузки после завершения.
Пока проходит процесс удаления можно проследить за ходом выполнения или закрыть окно. Если закрыть окно, процесс удаления будет выполняться в фоновом режиме и если ранее была выбрана автоматическая перезагрузка, то она будет выполнена после завершения всех операций.
Если не была выбрана автоматическая перезагрузка, то мастер удаления ролей и компонентов, после завершения всех операций, будет ожидать перезагрузки для применения изменений.
После всех вышеуказанных действий перезагрузку можно выполнить вручную.
Вокруг FSMO ролей Active Directory существует некоторое количество мифов, которые происходят, как несложно догадаться, от банального непонимания темы.
В этой статье я расскажу о том, для чего предназначены FSMO роли, что произойдет в случае недоступности сервера с этой ролью и как перенести роли на другой сервер.
Начнем с уровня леса:
Schema master
Схема содержит Классы (например, users, computers, groups) и Атрибуты (например, name, sIDHistory, title). Их использует не только Active Directory, но и некоторое корпоративное ПО (например, Exchange, System Center).
При обновлении уровня домена/леса (после обновления всех ОС контролеров домена разумеется), а также при установке ПО, в схему вносятся дополнительные Классы и Атрибуты, что, разумеется, не влияет на ПО, которое уже установлено. Поэтому не стоит бояться обновления схемы, несмотря на то, что это необратимое действие.
ЕСли Вы все-таки хотите перестраховаться, перед обновлением схемы, можно создать новый контролер, дождаться выполнения репликации и вывести его в offline. Если что-то пойдет не так, вы сможете его вернуть в online, назначить его schema master, предварительно навсегда выведя в offline контролер, на котором обновление прошло неудачно.
Схема едина для всего леса, хранится на каждом контролере домена, а реплицируется с контролера обладающего ролью Schema Master. При установке ПО, которое вносит измениния в схему, изменения будут вносится на контролер с ролью Schema master.
К этому контролеру будут обращаться другие контролеры в случае, если версия схемы на них будет отличаться.
Узнать текущую версию схемы используя PowerShell можно так (разумеется, вместо lab.local будт имя вашего домена):
Get-ADObject “cn=schema,cn=configuration,dc=lab,dc=local” -properties objectVersion
Актуальные на сегодняшний день версии:
69 = Windows Server 2012 R2
56 = Windows Server 2012
47 = Windows Server 2008 R2
44 = Windows Server 2008
31 = Windows Server 2003 R2
30 = Windows Server 2003
Другое ПО, изменяет другие объекты, например для Exchange Server это rangeUpper
Для того, чтобы использовать mmc оснастку Active Directory Schema (Схема Active Directory в русской локализации) необходимо выполнить:
Если контролер с ролью Schema Master будет недоступен, никто в пределах леса не сможет расширять схему (подымать уровень леса и устанавливать “тяжелое” ПО), а т.к. расширение схемы происходит очень редко, то жить без этой роли инфраструктура может годами.
Подробнее о Schema тут – http://msdn.microsoft.com/en-us/library/ms675085(v=vs.85).aspx
Domain naming master
Необходим в первую очередь для того, чтобы обеспечить уникальность NetBIOS имен доменов в пределах леса.
Если контролер с этой ролью будет недоступен, никто в пределах леса не сможет добавлять, удалять и переименовывать домены а т.к.
Как сделать бекап домен контроллера Server 2012 R2
это происходит очень редко, то жить без этой роли инфраструктура тоже может годами.
Кроме того, без Domain naming master не будет работать добавление и удаление разделов каталогов приложений, а также перекрестные ссылки – но это уже совсем экзотика, не думаю что есть смысл об этом писать в рамках этой статьи.
На уровне домена располагаются такие роли:
RID Master
Для каждого Security Principal в домене, генерируется уникальный идентификатор безопасности – SID. В отличии от GUID, SID может меняться, например, при миграции между доменами.
В пределах одного домена, SIDы будут отличаться последним блоком – он называется RID (относительный идентификатор).
При создании нового Security Principal, SID, и, соответственно, RID выдается тем контролером, на котором выполняется создание.
Для того, чтобы предотвратить создание одинаковых RID, каждому контролеру RID marster назначает пул (по-умолчанию 500, но значение можно изменить). Когда у контролера пул приближается к концу (по-умолчанию 100 адресов, также можно изменить) он обращается к RID master, который выдает еще 500 значений.
Всего доступно 2 30 (это 1,073,741,823) RIDов – на первый взгляд это очень много, но если принять во внимание тот факт, что RID не мог быть назначен повторно (создание – удаление – создание объета отнимало 2 RIDa) в ряде случаев разблокировали 31й бит и получали 2,147,483,647 RID’ов.
Об улучшениях, которые были сделаны в 2012 Вы можете подробно узнать тут – http://blogs.technet.com/b/askds/archive/2012/08/10/managing-rid-issuance-in-windows-server-2012.aspx
Посмотреть, что у Вас происходит сейчас можно так:
Таким образом, если контролер с этой ролью будет недоступен, контролеры исчерпавшие выданные им RID-пулы не смогут создавать новых Security Principals.
PDC Emulator
Несмотря на то, что PDC/BDC это термины из далекого NT-прошлого, это наиболее важная FSMO роль в операционной деятельности.
Опустим описание того, как быть с NT машинами, и перейдем к реальным вещам:
- Источник времени. Синхронизация времени важна для работы Kerberos (и не только), поэтому все контролеры (и, соответственно, клиенты) синхронизируют свое время с PDC, который должен синхронизироваться с внешним NTP. Подробнее о настройке времени в домене я уже писал, можно почитать тут.
- Сохранение групповых политик по-умолчанию происходит на контролер с ролью PDC, и с него реплицируется на другие контролеры (начиная с 2008 используется DFS).
- Репликация паролей. Коль уже смена пароля признана важной, реплицируется она не стандартным методом, а так называемым urgent (подробнее о репликации Active Directory – ищите мою статью поиском). Это значит, что контролер, на котором был сменен пароль, срочно реплицируется с контролером, который PDC Emulator. На практике выглядит так: пользователь вводит новый пароль, который ближайший контролер еще не знает. Этот контролер обратится к PDC, и тот подтвердит что пароль правильный, таким образом, предотвращается ряд проблем.
Если контролер с ролью PDC Emalator будет недоступен, не будет работать синхронизация времени и будут сложности с сохранением групповых политик и репликацией паролей, что скажется на операционной деятельности.
Infrastructure Master
Последняя роль – ее задача которой отслеживать пользователей из других доменов леса. Важность этой роли зависит от количества пользователей и ресурсов в разных доменах. Например, если у Вас один домен в лесу, Infrastructure Master будет просто ненужен.