Pull to refresh

Comments 17

Поясните, а что страшного в восстановлении АД из резервной копии? Допустим, инфраструктура минимальна и состоит из пары КД в одном домене. В этом случае, если бекап создан и восстановлен корректно, то КД сами разберутся чья версия АД верная и проблем быть не должно.
Хотя бы исходя из трудозатрат, восстановить копию в пару кликов на порядок проще, чем все переустановить и вычистить хвосты от старого КД.

Для того, чтобы этого избежать нам нужно провести операцию «инвалидации» (если кто-то встречал или знает более подходящее русское слово, то озвучьте его, пожалуйста, в комментариях).

«операция исключения идентификаторов»?
«Страшного» ничего. Просто в зависимости от того как давно была снята копия, был ли контроллер держателем FSMO ролей на момент резервного копирования и сейчас, был ли он физическим или виртуальным сервером список действий может несколько меняться.

Со времён 2008 сервера чистка метаданных старого контроллера делается в пару кликов. Установка нового сервера, как правило операция автоматизированная. Соответственно, создание новго контроллера не очень трудозатратная, безрисковая и всегда проходящая одинаково операция.

Именно поэтому Microsoft рекомендует избегать восстановления контроллеров из резервной копии, если есть возможность просто ввести новый. Т.е. не то чтобы этого нельзя было делать. Просто, обычно, лучше сделать по другому.

«операция исключения идентификаторов» не гуглится совсем. «инвалидация» всё таки исопльзовалась раньше и при чтении статей на английском сразу ассоциируется с правильным термином. Я надеялся, что кто-то знает общеупотребимый термин, который я пропустил.
По порядку. Копии следует делать как можно чаще, ну раз в сутки уж точно. Бекап и восстановление средствами Veeam сильно упрощает эти операции и не идет ни в какое сравнение со штатным недобекапом.

Вроде как раз начиная с 2008 dcpromo не вычищает данные DNS, да и вообще захват ролей и поднятие нового сервера — не операция в два клика. Сервер КД у меня точно не та «роль», которая деплоится чуть ли не автоматически.

Повторюсь, восстановить КД из бекапа VEB как раз операция в «2 клика». Я не голословен, возможно в масштабной среде из десятков КД, проще переподнять, чем восстанавливать, но в среде из двух КД, рестор из бекапа проще на порядок. Т.е. я бы не стал так безаппеляционно заявлять, что ну его, переподнять проще и надежнее.

«операция исключения идентификаторов» не гуглится совсем.
согласен. но «инвалидация», в этом контексте как раз неплохо заменяется «исключением».
Спасибо, хотелось бы побольше таких материалов на общедоступном языке.
Помнится лет 10 назад, когда я только пришел в профессию — FSMO for Dummies-like статей не было.
Приходилось изучать сложный для новичка technet и набивать шишки.
Ждем нового дежурного вопроса на собеседованиях.
Думаю, что какой-нить ИТ-рук прочитает статью, узнает про RID, SID и прочие ID, и будет задавать «каверзный вопрос» ))

В DSYS их наверняка задают уже сейчас, а нафига это обычному админу на собеседовании? Даже в «библии AD» этот вопрос не рассматривается.
Это будет очень странный «каверзный вопрос»:) Всё таки, такие вещи стоит знать обычно для широты кругозора, в реальной работе большая часть админов с ними не пересекается никогда.
Я вас удивлю, но в при собеседовании в местный банк именно этот вопрос мне и задали.
Было это лет 5 назад и, конечно же, ответить на него я не смог.

Тема достаточно каверзная, и "простые" админы, у кого в подчинении мелкие ИТ инфраструктуры на 2-4 сервера и десяток станций действительно об этой "низкоуровневой" области AD знают мало и редко, как, в прочем и о том, что ролей у контроллера домена несколько.
Я лично бы не ставил этот вопрос ключевым для отказа соискателю, если ответ на данный вопрос ему неизвестен, потому как и сам с этой областью и изучением деталей столкнулся лет через 5 практики, когда у одного из клиентов обозлённый на руководство админ очень тонко и незаметно для не-экспертов попортил AD

как обнаружили данную проблему? Он ввел в работу пересекающие диапазоны RID?

Да нет, просто домен глючил, глючил, тихо и почти незаметно, пока не заглючило настолько, что работать можно было только локально. пока не подключили знакомого MCSE

итоговая причина была в чем, смешал RID блоки?
Ну зачем было пугать людей?
Необходимость увеличить нижнюю границу пула RID возникает только в тех редких случаях, когда приходится восстанавливать целиком, как минимум, домен (ну, или весь лес). Собственно поэтому описанная в статье процедура и описана в документации Microsoft как раз в разделе процедур восстановление леса.
Если же в домене остались работоспособные контроллеры, репликация между ними не развалилась, а админ не лазил кривыми руками в реестр для нестандартной настройки, то описанная процедура не требуется. Потому что актуальное значение ridAvailablePool уже есть на оставшихся контроллерах (его туда репликация скопировала), а восстановленый RID Master не начнёт выполнять свои функции, пока не среплицирует раздел домена хотя бы с одного из оставшизся контроллеров — это как раз та настройка по умолчанию, про которую про кривые руки написано было. Так что, можно спокойно восстанавливать RID Master из резервной копии и не париться.
Я и не пытался никого напугать. Собственно, я так и сказал —
Восстанавливать контроллеры из резервной копии не нужно. В случае проблем с контроллером правильным будет удалить его из домена, переставить сервер начисто и заново ввести его в домен в роли контроллера. Однако, есть сценарии, где резервная копия — ваш единственный выбор. Например, если вся ваша AD DS инфраструктура была уничтожена и вам надо её восстановить.


А операцию описывал потому, что многие о ней вообще не знают, а для общего развития, на мой взгляд, знать такие вещи полезно.
Sign up to leave a comment.

Articles