Usn rollback что это

Лучшее решение при USN Rollback?

Возникла следующая ситуация:
Есть 3 КД: DC, DC2, DC3.
DC — бывший основной КД. Находится в состоянии UNS Rollback.
DC2 — основной КД. Владелец ролей FSMO.
DC3 — нормально реплицируется и работает.

Потенциальный метод решения проблемы — понизить/повысить DC и жить дальше(рекомендовано Microsoft), но есть нюанс. На DC развернут единственный AD CS. Понизить КД без удаления службы невозможно. Насколько я понимаю, удаление службы грозит невозможность проверки выданных сертификатов (на основании самоподписного Root). Крайне нежелательно, так как есть куча клиентов на терминальном доступе.

Закралась мысль попробовать восстановить DC с помощью штатного Backup/Restore (чтобы изменить значение Invocation ID). После включить репликацию и удалить значение — DSA not writeable.

Вопрос следующий — лучшее ли это решение в данной ситуации или я упустил какой-то нюанс?
Может можно сделать всё проще?
Не повредит ли восстановление DC службе AD CS?

P.S. Нет практического опыта переноса службы AD CS на другой сервер. Источники в интернете противоречивы. Возможности сделать cname DC на другой КД нет, так как DC обязательно нужен в сети с таким же именем.

• Вопрос задан более года назад
• 329 просмотров

• Facebook
• Вконтакте
• Twitter

«Насколько я понимаю, удаление службы грозит невозможность проверки выданных сертификатов (на основании самоподписного Root).»
Почему вы так думаете?
CA не нужно наличие ADDS на той же машине для функционирования.

Плюс она бекапится и восстанавливается довольно просто. Так что бекапы, DC force removal, install new OS, promote new DC, restore CA.
Последний пункт даже правильнее звучит так — build new VM, restore CA.

• Facebook
• Вконтакте
• Twitter

Sergei Shevchenko, я не в курсе, никогда не имел CA размещенным с какими-то другими ролями.
При force removal вы можете потерять членство бывшего DC в домене, придется после metadata cleanup перевводить в домен.
CA нужно забекапить, а лучше вообще поднять новую VM на любом сервере и перенести.

Вообще главный ответ на ваш вопрос он таков — не стоит в продакшн среде делать то, в чем вы не уверены.

Usn rollback что это

As many of us know, Active Directory replication problems come in all shapes and sizes. It’s particularly confounding when a DC just won’t replicate….anything….whatsoever. No inbound replication, no outbound replication, not one Naming Context coming or going. One of the scenarios we’ve seen a fair amount of here in support is when this happens following the restoration of a physical or virtual DC resulting in a state called USN rollback. If you aren’t familiar with USN rollback, in this post we’ll give you a better idea of what it is, helping ruling it in or out, and how to fix it when it does happen.

What is USN rollback (at a high level)?

First let’s define a USN. USN stands for update sequence number. Put simply, USN’s are how Active Directory keeps track of replication. Let’s use the example of two DC’s that are replication partners. When an object is changed on a given domain controller – let’s say a server named DC1 – the USN is iterated which tells DC1 a change needs to be replicated to its replication partners. Put differently, AD says “Hey DC1, DC2 has a change it needs to pick up.” This is essentially a concept called an “Up-to-Dateness vector.” On the other end, DC2 has what’s called a USN “high-watermark” for DC1 which keeps track of the most recent change it has received from DC1. This is a second measure to help DC2 determine whether or not it needs to pull any updates from DC1. All of this is to say that DC1 keeps track of what has been picked up and what needs to be picked up, and so does DC2. Everyone is keeping track, which is a good thing with changes taking place everywhere all the time.

What happens then when DC1 and DC2 have a conversation and DC1 says “You need to pick up change 0004” and DC2 replies “That’s funny, because I’m showing your last change as 0005. Why would you send something you already sent? You know what, we’re breaking up!” Dramatic Active Directory lover’s quarrel aside, in this scenario DC1 is in USN rollback because it is telling DC2 to come get an update DC2 already has. Instead of enduring the havoc that could ensue, the Active Directory code wisely chooses to just shut down replication on DC1 until someone can intervene. For better or worse, if you’re reading this then that someone is you.

How to tell if you have it.

There are a variety of indicators, all of which can let you know if the server is in a rollback state. The more of these you see, the more you can suspect it to be the case.

• The server (or the AD database) has been recently restored or a virtual DC reverted from snapshot – This doesn’t just happen on its own. An action on the part of an administrator is required for USN rollback to even be considered as a possible cause. Otherwise, it’s more likely some other AD replication issue.

• The Netlogon service is Paused – This is pretty rare with the exception of USN rollback.

• Inbound & Outbound replication disabled – Check this by running “repadmin /showreps” from an elevated command prompt.

• If HKLM\System\CurrentControlSet\Services\NTDS\Parameters\DSA not Writable is set to 4 – Also not likely to happen outside USN rollback scenarios.

• Directory Services Events – Look for the following events in the Directory Services log: 2095, 1113, 1115. Events can have a great many causes and are a great way of tracking down replication problems as a whole.

• Repadmin showutdvec output – Run “repadmin /showutdvec DC1 dc=domain,dc=com” on DC1. Run “repadmin /showutdvec DC2 dc=domain,dc=com” on DC2. If the replication partner has a higher USN value than the DC has for itself, it could indicate a problem.

Here’s an example of the repadmin showutdvec command at work:

Output from server 2008DC

Output from server 2008DC2

Notice that 2008 DC has a lower USN value for itself. In this instance, the server actually was not in USN rollback. Instead it was having issues with secure channel. Once I fixed the issue, 2008DC had a higher USN for itself. This illustrates 2 important points about this particular test:

1. I don’t recommend using this command as the single litmus test for USN rollback. The bigger the gap, the better an indicator it is, but I’d still use it in combination with some of these other signs. As with the example above, if there are no other USN rollback symptoms then a replication partner holding a higher USN might simply indicate a garden-variety AD replication issue.

2. This command helps identify which DC might be the problem in a scenario when replication is broken.

How to fix it.

You’ve done your homework and made the determination a domain controller has been rolled back. Now what? Here are some options.

1. Remove the DC. The number one solution per http://support.microsoft.com/kb/875495 and every other blog, forum post, and wiki entry since this KB was written is to remove the problem DC. If removal is an option in your environment I highly recommend this course of action. Admittedly doing so is easier said than done since the domain controller in question won’t, by definition…ahem…..replicate. Thus we are stuck doing a metadata cleanup. To some this may seem rash, but don’t be nervous: if most Escalations Engineers had a nickel for every metadata cleanup we’ve done in our time, we’d be having lunch together at Ruth’s Chris. While I won’t walk through the process here in detail, this is an article that shows a couple different ways of getting this accomplished – http://technet.microsoft.com/en-us/library/cc816907(v=WS.10).aspx. One of the tactical keys to going this route is that the DC in question isn’t running other services because following the metadata cleanup the server should be taken offline.

2. Restore from a good backup. Since this a domain controller, the backup must include the system state. More on why this works in the next section. If you can pinpoint a restore point from prior to rollback, this can fix your issue.

3. Sometimes you are down to 1 DC and have no good backup. Getting to a single DC typically happens because a well-meaning admin (or counterpart in escalations) has already removed the other DC/DC’s involved in the process of troubleshooting. Not having a good backup can happen when either the server has been in this state for a such a prolonged period of time that it has outlasted the backup rotation, or the IT department or IT admin is simply allergic to backing up their systems, which can often result in what I like to call a “resume generating event.” However we got to this point, it’s lucky for you there are still options.

First, as crazy as this sounds it might be easy to assume we don’t need to fix it. After all, why do I need to worry about replication with a single DC? It doesn’t have any replication partners! It’s highly recommended to have at least 2 DC’s for the sake of redundancy, so it would be wise to add a second one at some point. Can’t do that if the first DC isn’t able to replicate. Another consideration is this may be the only DC in the domain, but if there are other domains in the forest it will certainly need to replicate with them. Finally there are other services that just plain aren’t going to function normally (how well do you think the netlogon service works in a Paused state. ) until we get this worked out.So without further delay, here’s what to do:

Single-DC Procedure

• Reboot the DC into DSRM. If you aren’t familiar with this process, read more about it here – http://technet.microsoft.com/en-us/library/cc816897(v=WS.10).aspx

• Open Regedit and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

• Delete the registry value “DSA Not Writable” or set the value to 1

• Next, right-click the Parameters key, click New, and then click DWORD (32-bit) Value.

• Type the new name “Database restored from backup”, and then press ENTER. Double-click the value that you just created to open the Edit DWORD (32-bit) Value dialog box, and then type 1 in the Value data box. (This is more for the previously mentioned multi-domain forest scenario.)

• Restart the domain controller in normal mode.

• Enable the Inbound and Outbound replication by opening a command prompt using Run As Administrator & run the commands below:

Repadmin /options –disable_inbound_repl

Repadmin /options –disable_outbound_repl

• Force the replication

 Repadmin /syncall /AeP (Again, more for the previously mentioned multi-domain forest scenario since in a single-domain forest there wouldn’t be anything to replicate with.)

How to avoid it.

Restore backups correctly:

Given what you now know, it would be easy to wonder “why doesn’t this happen when we restore from backup?” After all, we’d be restoring back to a point where the server holds “old” USN metadata. The key difference is the Invocation ID. This is essentially the instantiation number of the AD database. Windows Server Backup automatically resets it when it does a restore, which is why all goes smoothly with WSB restores of a DC. The Invocation ID can also be manually changed using the “Database restored from backup” key from the procedure above. When the Invocation ID changes on a given DC, this tells its replication partners “I’ve been restored from backup. Can you fill me in with everything that’s happened since?” Instead of detecting a rollback, the replication partners just update the restored DC will all changes and life for the DC begins anew. It stands to reason then that any backup software that isn’t AD-aware and/or doesn’t do this properly could cause a rollback. It could even happen with Windows Server Backup if used incorrectly. We’ve seen instances in support where an admin will simply try to restore the ntds.dit (which could actually work if done properly.) In the end, it’s far easier to let Windows Server Backup restore the system state and do the work for you.

With virtual DC’s, be careful with snapshots:

Whenever it was that virtualization snapshots were invented and the first virtual domain controller came into being, I suspect the first USN rollback happened about 15 minutes later. Admittedly I have absolutely no data to back that up. The point is, take good care with virtual DC’s and snapshotting. Here are some guidelines.

• If you are running a Server 2012 Hyper-V host or newer and the VM is 2012 or newer, you will be fine. For more on this read here – http://technet.microsoft.com/en-us/library/hh831734.aspx

• If you are running a Server 2008R2 Hyper-V host, do not restore a virtual DC from snapshot.

• If you are running a Server 2012 Hyper-V host or newer and the VM is 2008R2 or older, do not restore from snapshot.

• If you are running Vmware, switch to Hyper-V. I kid. Calm down VMWare zealots; I was just checking to see if you were still reading. Make sure the VM is Server 2012 or newer and use the version of VMWare advised in this article and others – http://blogs.technet.com/b/keithmayer/archive/2012/08/06/safely-cloning-an-active-directory-domain-controller-with-windows-server-2012-step-by-step-ws2012-hyperv-itpro-vmware.aspx

Hopefully this gives you an additional tool to put in your toolbox. Just be careful with it. If knowing how deal with this particular issue is a hammer, not every AD replication problem is a nail. Best of luck and I hope this helps.

Чиню домены.

Представьте себе, что в один не очень прекрасный день вы решили восстановить один из ваших контроллеров домена (КД) из резервной копии, которую вы по привычке сделали старым проверенным средством снятия образа диска, типа Acronis TrueImage. Или решили откатить ваш виртуализованный КД к старому снимку, сделанному средствами гипервизора (и всё это работало не под Windows Server 2012). Или же вам, как и мне однажды, не повезло: из-за сбоя RAID-контроллера, который управляет аппаратным зеркальным томом, содержащим систему КД, некоторое время тому назад из этого зеркала вылетел один диск, а после перезапуска RAID-контроллер решил загрузить систему именно с этой, устаревшей половинки зеркала.

И вот, после перезагрузки вы обнаруживаете, что ваш контроллер домена — уже не совсем контроллер домена: он совершенно не желает авторизовывать пользователей и реплицировать изменения базы данных Active Directory (AD) с другими КД. Если провести стандартную диагностику проблем AD с помощью утилит dcdiag, то мы увидим следующее (часть выдачи dcdiag для краткости опущена, важные для дальнейшего изложения признаки выделены жирным шрифтом):

Doing primary tests

Testing server: Default-First-Site-Name\DC2
Starting test: Advertising
Warning: DsGetDcName returned information for \\DC1.domain.loc, when
we were trying to reach DC2.
SERVER IS NOT RESPONDING or IS NOT CONSIDERED SUITABLE.
……………………. DC2 failed test Advertising
…………………………………………………………………

Starting test: Replications
[Replications Check,Replications Check] Inbound replication is
disabled.
To correct, run «repadmin /options DC2 -DISABLE_INBOUND_REPL»
[Replications Check,DC2] Outbound replication is disabled.
To correct, run «repadmin /options DC2 -DISABLE_OUTBOUND_REPL»
……………………. DC2 failed test Replications
Starting test: RidManager
……………………. DC2 passed test RidManager
Starting test: Services
w32time Service is stopped on [DC2]
NETLOGON Service is paused on [DC2]
……………………. DC2 failed test Services
— то есть, контроллер домена не объявляет себя контроллером домена, репликация базы данных AD отключена, а служба Netlogon («Сетевой вход в систему» в русской версии) находится в приостановленном состоянии. Если вы посмотрите в журнал событий Active Directory, то вы обнаружите в нём два характерных сообщения об ошибках:

с Event ID 2095

и с Event ID 2103

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

Если вы наблюдаете эти признаки, то это означает, что вы столкнулись с героем этой статьи — USN Rollback: возвращением текущего максимального последовательного номера изменений (USN) КД к старому, меньшему значению (с помощью номеров последовательных изменений — USN — Active Directory отслеживает, какие именно изменения следует передавать при репликации между контроллерами домена, подробнее об этом ниже). Прочитать официальную информацию от Microsoft об этой проблеме можно в Technet Library (применительно к специфике виртуализованных контроллеров домена) или статье 885875 MS KB (на английском языке).

Хотя механизм возникновения данной проблемы изложен в указанных выше статьях, считаю необходимым для полноты изложения остановиться на нём и в этой статье (те, кому это не интересно или некогда это читать, могут перейти сразу к описанию процедуры восстановления в разделе Собственно рецепт). Потому что, чтобы понять, чем плохо возвращение текущего максимального универсального номера последовательных изменений к старому значению, нужно знать, как используются эти номера при обновлении копий базы данных Active Directory.

Active Directory спроектирована таким образом, чтобы при синхронизации (репликации) можно было передавать на целевой КД не всю базу данных, а только те изменения, которые не были ещё получены целевым КД. Для этого каждый измененный (в т.ч. вновь созанный) в базе данных AD объект или атрибут объекта маркируется в своих метаданных идентификатором КД (Invocation ID), на котором было первоначально произведено это изменение, и последовательным номером (USN) этого изменения на данном первоначальном КД (посмотреть метаданные для любого объекта и всех его атрибутов можно командой repadmin /showmeta ). При каждом изменении, первоначально произведенном на данном КД, этот номер увеличивается. Кроме того, каждый КД хранит у себя список максимальных номеров реплицированных изменений для каждого из известных ему КД-источников обновлений (идентифицируемых по Invocation ID) для каждого из разделов каталога — up-to-dateness vector (его можно посмотреть командой repadmin /showutdvec ). И при репликации КД запрашивает только те изменения, номер USN которых выше максимального номера уже полученного изменения.

Из этого описания видно, что если текущий максимальный номер USN по какой-то причине уменьшится, то изменения, промаркированные номерами USN в промежутке между новым текущим максимальным номером USN и запомненными на других КД максимальными номерами реплицированных изменений, никогда не будут реплицированы на эти другие КД, то есть, база данных AD окажется в рассогласованном состоянии — её содержимое на разных контроллерах доменов навсегда останется разным.

Поскольку все алгоритмы работы AD опираются на то, что содержимое баз данных на разных КД является (или достаточно быстро становится) одинаковым, то описанное выше положение дел является недопустимым. Чтобы его избежать, в механизм репликации AD был добавлен элемент контроля, проверяющий в момент первой репликации КД, что текущий максимальный номер USN на контроллере домена не меньше, чем максимальный номер реплицированных изменений, известных его партнерам по репликации. Если это условие не соблюдается, то AD блокирует входящую и исходящую репликацию, а также помечает (в реестре) свою копию базы данных как недоступную для записи по причине возвращения номера USN к меньшему значению — что как раз вызывает те самые симптомы, что описаны в начале статьи.

Обнаружение USN Rollback срабатывает, к сожалению, не всегда. Если контроллер домена после восстановления из образа долго не имеет связи с другими КД, и на нём за это время происходит много изменений, то после восстановления связи может оказаться, что на момент первой репликации после восстановления текущий максимальный номер USN окажется больше максимального номера реплицированных изменений, то условие отсутствия USN Rollback будет формально соблюдено, фактически имевший место откат назад номеров изменений обнаружен не будет и часть изменений так и останется не реплицированной. Такой вариант вполне реален при восстановлении КД после катастрофического отказа где-нибудь в филиале, где из-за того же отказа пострадала и связь. Так что, обнаружив приведенные в начале статьи симптомы, можно даже порадоваться — всё могло быть и хуже.

Как лечить USN Rollback

Лучшее лечение — это, как известно, профилактика. В применении к теме данной статьи это означает: делать резервные копии базы данных AD (она входит в раздел Состояние системы для КД) регулярно, и делать их программой, которая знает, как копировать и, главное — как восстанавливать базу данных AD. Простейшая из таких программ — это встроенная Windows Server Backup. Использование правильных программ исключает большинство возможных случаев возникновения USN Rollback, а если вдруг такая беда случилась (например, из-за сбоя RAID-контроллера, зеркалирующего системный диск) — без особых проблем восстановить базу данных AD.

Но вот что делать если беда уже случилась, а резервной копии базы данных AD нет? Рекомендации производителя — Microsoft — просты и незатейливы: понизить принудительно контроллер домена, удалить его метаданные из AD и повысить обратно. Процедуры эти просты и многократно описаны, здесь я на них останавливаться не буду. В большинстве случаев это можно проделать вполне безболезненно, и, собственно говоря, при наличии возможности именно так и стоит делать.

Интереснее другой вопрос — что делать, если принудительное понижение с последующим понижением — не вариант? Например, если на КД стоит какая-то программа, которая, с немалой степенью вероятности, не перенесёт такие манипуляции. Или USN Rollback возник на единственном контроллере вновь созданного домена, в котором уже были созданы учётные записи новых пользователей. Или вот, например, был случай на русском форуме Technet, когда системный администратор умудрился загнать в состояние USN Rollback все контроллеры корневого домена леса — как сохранить лес? В таких случаях рекомендованный производителем способ решения проблемы не годится. Но выход, тем не менее, есть.Чтобы понять, как этот выход работает, следует рассмотреть две вещи: как при корректном восстановлении базы данных AD удаётся избежать USN Rollback, и какие именно изменения вносятся в конфигурацию КД при обнаружении этого состояния.

Для обеспечения корректности работы восстановленной базы данных программа восстановления делает одну простую вещь: она после завершения восстановления (а оно производится при загрузке в режиме службы восстановления каталогов) записывает в реестр новое значение для Invocation ID в параметр «HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\New Database GUID», заставляя AD при запуске во время следующей загрузки в нормальном режиме сменить Invocation ID — то есть заставляет выглядеть (с точки зрения механизма репликации базы данных AD) восстановленный контроллер домена как новый, совершенно другой КД, изменения на котором учитываются независимо от прежних, сделанных его до восстановления.

Что же касается реакции на USN Rollback то она включает в себя две вещи: во-первых, для подверженного ей КД отключается (установкой флагов DISABLE_INBOUND_REPL и DISABLE_OUTBOUND_REPL в атрибуте Options объекта «NTDS Settings», связанного с объектом данного КД в разделе конфигурации) входящая и исходящая репликация, во-вторых в реестре этого КД в параметре «HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\DSA not writeable» (типа REG_DWORD) фиксируется, что база данных AD не является допустимой по причине возникновения USN Rollback (значение параметра устанавливается равным 4). При обнаружении этого последнего параметра происходит запись в журнал события с кодом 2103, а служба Netlogon ставится в приостановленное состояние.

И в свете всего вышеизложенного становится понятно, что нужно делать, чтобы вывести контроллер домена из состояния USN Rollback:

Собственно рецепт.

Предупреждение. Приведенные ниже действия не опираются на официальные рекомендации Microsoft (хотя и проверены мной лично). Они могут привести к возникновению рассогласованных копий базы данных Active Directory на разных контроллерах доменов (см. ниже). Поэтому используйте их под свою ответственность и только в крайнем случае.

Предупреждение 2. Если на пострадавшем контроллере домена в БД AD были внесены какие-либо изменения после возникновения состояния USN Rollback, то эти изменения, скорее всего, никогда не будут реплицированы на другие контроллеры домена, даже после восстановления по указанной ниже процедуре (причины были рассмотрены в предыдущем разделе). Из-за этого произойдёт рассогласование копий БД. И впоследствии это может вылиться в странное поведение (например, несовпадающие пароли учётных записей) или даже в нарушение репликации (ошибка 8606). Если USN Rollback был обнаружен сразу же, и контроллер домена был вовремя заблокирован, то вероятность возникновения таких ошибок невелика. Но если это был, например, восстановленный из образа диска контроллер где-нибудь в филиале, то последствия могут быть весьма неприятными. Я надеюсь рассмотреть, как можно заранее вычислить такие изменения и сделать их доступным для репликации, в одной из следующих статей.

1. Заставить AD изменить Invocation ID. Хотя можно сделать это, напрямую записав соответствующий параметр в реестр, я считаю предпочтительным сделать это с помощью штатного Backup/Restore — это заодно устранит и возможные рассогласования копий папки SYSVOL на пострадавшем контроллере домена и других КД и позволит избедать возможных проблем с её репликацией (это другая тема, которую я тут не затрагиваю). Последовательность действий примерно следующая (я не расписываю подробно все шаги, поскольку они отражены во многих руководствах):

1а. Подготовительные действия. Установить, если ещё не установлен, компонент архивации и подготовить место, куда будет записана резервная копия (либо чистый локальный либо съёмный диск, либо пустую общую сетевую папку). Рекомендую также посмотреть (командой repadmin /showrepl ) зафиксировать текущий Invocation ID контроллера домена.

1б. Выполнить резервное копирование состояния системы (а лучше, если позволяет время и место на диске/папке — всего системного тома).

1в. Загрузиться в режиме восстановления службы каталогов и восстановить состояние системы. Рекомендую делать это от имени локальной учётной записи администратора режима восстановления службы каталогов (я наблюдал случаи, когда попытка восстановления состояния системы при регистрации под доменным администраторам приводила к необъяснимым сбоям).

1г. Загрузить контроллер домена в обычном режиме.

2. Разрешить входящую и исходящую репликацию для контроллера домена. Перед включением репликации в качестве меры предосторожности рекомендую проверить, что показываемое командой repadmin /showrepl значение Invocation ID изменилось по сравнению со старым, зафиксированным на шаге 1а

Включение репликации производится командами

repadmin /options имя_КД -DISABLE_INBOUND_REPL

repadmin /options имя_КД -DISABLE_OUTBOUND_REPL

3. Удалить отметку о том, что база данных AD находится в недопустимом для записи состоянии по причине USN Rollback. Для этого надо запустить редактор реестра, выбрать ключ HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters, найти в нём параметр «DSA not writeable» (его значение должно быть равно 4) и удалить этот параметр.

4. Запустить из приостановленного состояния (если она ещё не запустилась сама) службу Netlogon

После выполнения этих шагов я рекомендую (хотя это не обязательно) ещё раз перезагрузить контроллер домена и выполнить его диагностику с помощью команды dcdiag: после ликвидации USN Rollback могут проявиться и другие ошибки (см. например уже упоминавшийся случай на русском форуме Technet — там пришлось устранять и проблемы с SYSVOL, и не удалённые вовремя («застрявшие») из-за неработавшей репликации объекты).

Что за зверь USN Rollback?

Любовь некоторых администраторов к ПО Acronis откровенно удивляет. Это ПО полезно, но без оглядки применять его везде и всюду не стоит…

Как правило “веселые ребята” которые упорно бэкапят контроллеры, после восстановления сильно удивляются тому что останавливается репликация и ничего кроме проблем (я называю эту ситуацию – резюме генерэйшн эвент ) это восстановление не приносит.

При большой любви к Acronis-у и прочим ничто не мешает выполнять сначала резервирование состояния системы (system State Backup) а потом уже снапшот диска. И коли есть желание восстановиться то можно восстановить снапшот а потом System State.

Не буду вдаваться в теорию (совсем немного) и предлагаю рассмотреть следующий сценарий.

Update Sequence Number (USN) это элемент метаданных репликации, называемый номером последовательного обновления. Каждый контроллер домена поддерживает USN, который ему специфичен. При внесении изменений в Active Directory к значению USN прибавляется 1. USN существует только в пределах контроллера домена, никакого отношения к USN на соседнем контроллере он не имеет.

Для простоты понимания можно привести следующий пример.

У двух контроллеров TEST-DC01 (USN=100) TEST-DC02(USN=200) свои значения USN. При репликации они ими обмениваются и каждый запоминает значение USN партнера, что бы после оповещения об изменениях партнер забрал произведенные изменения.

Теоретические изыски дальше будет излишними т.к. это тема для отдельной статьи.

Теперь пример.

У клиента два контроллера TEST-DC1 и TEST-DC2 на Windows Server 2003 и куча проблем в виде неработающей репликации и пр. иначе бы не позвонили

Проблема.

• Репликация между контроллерами остановилась. Местные “админы” заводят пользователей поочереди на обоих контроллерах.
• Контроллеры домена находятся в онлайне и их имена разрешаются через DNS.
• Все необходимые для работы записи присутствуют в DNS.

Приступаем к диагностике.

• Контроллер домена виртуализирован на сервере Hyper-V и его восстановили из снапшота двух недельной давности (хороший пример для USN rollback)
• В журнале присутствует сообщение с ID 2095

Event Type: Error
Event Source: NTDS Replication
Event Category: Replication
Event ID: 2095
Date: 1/06/2011
Time: 4:30:20 PM
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: TEST-DC2
Description:
During an Active Directory replication request, the local domain controller (DC) identified a remote DC which has received replication data from the local DC using already-acknowledged USN tracking numbers.
…

• Так же в журнале присутствует сообщение ID 2103

Event Type: Error
Event Source: NTDS General
Event Category: Service Control
Event ID: 2103
Date: 1/06/2011
Time: 4:30:20 PM
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: TEST-DC2
Description:
The Active Directory database has been restored using an unsupported restoration procedure.
Active Directory will be unable to log on users while this condition persists. As a result, the Net Logon service has paused.

При проверке состояния сервиса NetLogon мы убеждаемся что он действительно стоит на паузе.

Изучая ситуацию дальше, запускаем на первом контроллере TEST-DC1 команду:

На TEST-DC2 аналогичную команду:

В итоге, проблема заключается в том что TEST-DC1 имеет USN равный 13435, а TEST-DC2 знает о том что входящий USN был равен 13409 (ты где был? я не верю что это ты!) и как следствие выполняется блокировка обновления службы каталогов.

Данный метод не является лечением от USN Rollback, он скорее предотвращает его возникновение т.к. основан на ключе реестра который сообщает что служба каталогов была восстановлена из резервной копии.

При восстановлении снапшота виртуальной машины (можно читать как при восстановлении с помощью Акрониса) необходимо.

• Загрузить контроллер в DSRM (Directory Service Restore Mode) режиме. Если вы загрузились в обычном режиме то переходите к методу №2.
• Открыть редактор реестра, найти ветку

в ней ищем параметр DSA Previous Restore Count и ставим его в 0. Если значения нет то создавать его не надо.

• Добавляем Database restored from backupв

• Выполняем перезагрузку.
• Проверяем что значение DSA Previous Restore Count стало равным 1.
• В журнале Directory Service проверьте события ID 1109 или ID 1587. Эти события подтверждают что база Active Directory восстановлена нормально.

Метод №2

Тут все немного сложнее. Придется либо обновлять резюме либо запастись терпением при чтении мануалов.

Вам придется с проблемного контроллера удалять Active Directory, затем очистить метаданные из AD и восстанавливать роль контроллера.

• На проблемном контроллере запускаем утилиту dcpromo с ключом /forceremoval
• После завершения процедуры выключаем контроллер.
• Процедура чистки метаданных подробно описана в статье базы знаний микрософта, но я для объема полноты приведу пошаговую инструкцию.

Осталось совсем немного.

На вкладке “Name Servers” оснастки DNS удаляем записи контроллера из Forest и Domain DNS зон. В завершении открываем оснастку Active Directory Sites and Services и удаляем проблемный контроллер.

PS. Собственно разговор начинался с того что использование Акрониса для бэкапа контроллеров домена не есть хорошая практика, а в итоге получилась заметка про USN rollback.

Думаю что моя статья поможет кому то в борьбе со зверем или заставит скорректировать свои “бэкапные” предпочтения.

Похожие статьи

Информация об авторе

Если Вам понравилась статья, то вы можете подписаться на RSS.
А также бесплатно подписаться по E-mail и получать актуальную информацию в числе первых.