Насколько безопасный Windows Active Directory Schema Updates?
Обновления схемы являются одним путем функция. Можно только добавить новую схему к AD, Вы ничего никогда не можете удалять. Поэтому необходимо всегда тщательно оценивать альтернативы, когда программное обеспечение требует расширений схемы или обновлений; убедитесь, что это - что-то, что Вы готовы согласиться на использование.
Первая вещь, удостоверьтесь, что у Вас есть хорошая резервная копия базы данных AD (обычно %SystemRoot %\ntds\NTDS.DIT)! Сохраните его в безопасном месте.
Если у Вас только есть один DC в Вашем лесу, это является очень прямым. Просто выполните adprep, как в инструкциях говорится (или позвольте обновлению программного обеспечения сам AD).
Если у Вас есть больше чем один DC, затем удостоверяются, что нет абсолютно никаких ошибок, о которых сообщают dcdiag и replmon -syncall. Удостоверьтесь, что у Вас есть резервные копии каждой AD Базы данных (от каждого DC). Определите DC с ролью Хозяина схемы. Сделайте все обновления на/к том сервере, если это возможно.
AD защитит себя в большинстве случаев от неудавшихся обновлений схемы. Если файл LDIF не передаст синтаксис (скажите Вас BSOD посреди обновления), то это не будет загружено. Каждое "обновление" имеет свой собственный набор файлов LDIF.
Я никогда не видел обновление схемы (пока оно сделано правильно), идут не так, как надо. MS действительно, кажется, вытащил все остановки в создании этого серьезный и надежный процесс, и это показывает. Единственные реальные сценарии, в которых я видел что-либо плохо случай, были бы то, при потере питания отчасти через (даже затем, я не уверен), или если AD был уже завинчен для начала (в этом случае, у Вас есть большие проблемы).
Все, что действительно делает обновление схемы, расширяют AD с помощью новых классов объектов и свойств (который приложение или более новая версия AD могут использовать), таким образом определите объем для аварии, вполне ограничен. Эта technet статья дает достойный обзор и касается некоторых потенциальных Плохих Вещей, Происходящих случаи.
Стандартный подход для меня должен был бы гарантировать, что все функционирует правильно заранее (через dcdiag, replmon, и т.д.), и удостоверьтесь, чтобы у меня было известное - хорошее резервное копирование AD в случае, если худшее происходит. Я сохранил бы это резервное копирование максимально долго, поскольку AD может быть столь чертовски устойчивым, что проблемы не могут проявить в течение долгого времени впоследствии. Столь стандартное резервное копирование и восстановление были бы моим откатом. Но как я сказал, я никогда не видел, что это имеет место.
Один dc офлайновый подход работал бы на небольшую среду. Для крупной среды я предпочел бы выполнять обновление на dc, который не соединен. Обеспечение процесса обновления завершается успешно, затем подключите его к сети и копируйте изменения. Возврат в этом сценарии был бы так же прост как получение по запросу одного диска зеркального набора, и закрытия dc и перевставки исправного диска, который был текущим до обновления.
В большой сети с сотнями или тысячи dc's, перевставка хороший подход dc не был бы практичен.