Ошибка dfsr 4412

Problem Description

You can experience Event ID 4412 Storm from Source DFSR with the following Message : "The DFS Replication service detected that a file was changed on multiple servers. A conflict resolution algorithm was used to determine the winning file. The losing file was moved to the Conflict and Deleted folder." and your boot volume can run out of free space on Domain Controllers with DFS Replication installed.

Error Message

Log Name:      DFS Replication
Source:        DFSR
Date:          09/10/2021 5:55:18 PM
Event ID:      4412
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      DC.Domain.local
Description:
The DFS Replication service detected that a file was changed on multiple servers. A conflict resolution algorithm was used to determine the winning file. The losing file was moved to the Conflict and Deleted folder.

Below a screenshot of the related Event Storm :

Root Cause Analysis

A few days ago one of our customers asked for help because he run very fast out of free disk space on his Domain Controllers. I immediately requested from him to run the free TreeSize Tool to figure out what is filling up the disk so quickly.

Once we run the TreeSize Tool we saw that the ConflictAndDeleted folder under DFSR is increasing 100MB every 1 Minute.

C:System Volume InformationDFSRPrivate{UR934RU-JDJ984S-JDEW89D-8789RR}ConflictAndDeleted

Below a screenshot of the free TreeSize Tool :

Our first action was to free up some space on the C: Volumes on all affected Domain Controllers so that they can continue with his normal operations. At the time of the problem we had nearly 8% to 22% free space on different affected Domain Controllers.

After some search on the Internet we saw the article mentioned below from Microsoft and decided to run the cleanup command on the affected Domain Controllers :

The ConflictAndDeleted folder size may exceed its configured limitation

wmic /namespace:\rootmicrosoftdfs path dfsrreplicatedfolderinfo where "replicationgroupname=''" call cleanupconflictdirectory

Once done we then checked the DFS Replication Event Logs in Event Viewer and saw that 1 Second nearly up to 30 Event ID 4412 gets logged. Even if it is an Informational Event it is not normal to get so much Informational Events with the same Event ID every 1 Second.

Afterwards we checked the DFS Health Status and also tried to replicate some new files by placing the files into the Replication folder to figure out if it is working fine and saw that the replication works as expected on our Domain Controllers.

Furthermore we checked the files, which were reported as changed in Event ID 4412, but none of the files were changed or modified based on the "Date Modified" Date in Explorer. The files files were nearly 4-5 Month old.

We then decided to compare the HASH Value of the files between the Domain Controllers with Get-FileHash Powershell Command.

Get-FileHash -Path

BINGO !

All files reported in Event ID 4412 had a different HASH Value on the Domain Controllers. This means basically that a Remote or Local Scanning Software or Agent is continuously changing the HASH Value of the files. As a result DFS thinks that the file has been really changed and an endless replication begins between the Domain Controllers.

We then run Process Monitor Tool from Microsoft to figure out which Process is changing the HASH Value of the files in DFS Replication folder and saw that CyberArk Endpoint Privilege Manager Agent (vf_agent.exe) continuously doing changes to the DFSR folder.

Below a screenshot of the related ProcMon Logs :

Solution

We decided to remove CyberArk Endpoint Privilege Manager Agent (vf_agent.exe) from all of our Domain Controllers and BINGO !

After nearly 30-60 Minutes Event ID 4412 Storm stopped on all of our Domain Controllers. It can take some time till the winners file mentioned in Event ID 4412 gets replicated as a last time to all Domain Controllers and stops continuously replicating the same file again but it should not take more then 90 Minutes.

Important !

Please be aware that even if you add the DFSR Folder to the Exception List in CyberArk Endpoint Privilege Manager Agent it can still access, scan and do changes inside the DFSR Folder because CyberArk Agent has an Artificial Intelligence and can decide by itself if it sees an high activity or anomaly inside an folder.

Good luck !

4
2011-05-10T08:21:33+00:00
2

Hi there

Have 2 servers in different sites running DFSR .. Sometimes, I get random files being deleted, and Event ID 4412 being thrown.

I dont actually understand how the 4412 can happen,  (conflict of files, so it moves it to the conflict detection folder). Is it when it is somehow modified at both sites at the same time?

If that is the case,  would changing the DR side, to read-only, fix this issue? 

I assume because as shown in this photo, either  DRR MAN or OFF can be activated, putting it in read only shouldnt allow changes?

Any other thoughts on this.

Thanks alot

Let’s talk about ports on DFS. Endpoint protection blocks a LOT of ports needed for proper domain functions… SEP manager can grant/deny access… Most IT advocate not using SEP on a domain server…

But, DFSR uses port 135 (the RPC port). It also uses port 5722 for  RPC. Then it uses a number of random upper ports. It’s my guess this is blocked by SEP..

Once replication between the servers has occured, THEN the client logon using netbios. That’s another list of ports that the clients use and are most likely blocked by the server. Ports 138, 139 are netbios datagram ports. These ports being blocked by SEP will be detrimental to a number of services.

Here is a list of ports for you to follow:
http://support.microsoft.com/kb/832017

DFSR is the act of replicating. DFS still replicates some domain information… Clients use Netbios to communicate with your distributive file shares…

Ports are blocked by netbios, and other ports are blocked through the replication part of your file shares.

SEP is really not good for a domain use on a number of different levels..

http://www.symantec.com/connect/articles/guide-dfs-and-dfsr-concerns-when-deploying-symantec-endpoint-protection-110

Distributed File System (DFS) can sometimes have problems replicating, recovering its database, etc. The notes below are meant to provide a very basic guide to troubleshoot your DFS replication issues.

Event IDs

Event ID 4412: The DFS Replication service detected that a file was changed on multiple servers. A conflict resolution algorithm was used to determine the winning file. The losing file was moved to the Conflict and Deleted folder.

This event ID indicates proper operation and function of DFS. Don’t be deceived, however. If you’re having DFS replication problems, you may see this event ID intermittently, but not as often as should be expected. Check event logs on the other replication members to see what the amount of these entries should look like. If you don’t see enough 4412 entries, that server is probably having replication issues. It may also take some time to see the appropriate amount of these log entries after the database recovers and you get event ID 2214.

Event ID 2212: The DFS Replication service has detected an unexpected shutdown on volume C:. This can occur if the service terminated abnormally (due to a power loss, for example) or an error occurred on the volume. The service has automatically initiated a recovery process. The service will rebuild the database if it determines it cannot reliably recover. No user action is required.

Something happened to the server or DFS service. Either the server was forcibly shut down (ie. shutdown /f was run from command prompt), the power button was held long enough to cold boot the server, or the dfsrs.exe proecss was terminated in Task Manager. I’m sure there are other things that could cause this, but you get the idea. Now you have to wait for event ID 2214.

Event ID 2214: The DFS Replication service successfully recovered from an unexpected shutdown on volume C:.This can occur if the service terminated abnormally (due to a power loss, for example) or an error occurred on the volume. No user action is required.

Whew! Good news. The DFS database recovered and can now resume replication with the other members.

Dos and Don’ts

Do: Run chkdsk in read-only mode on the DFS share volume. If chkdsk finds errors, run chkdsk /F or chkdsk /R to fix the disk. DFS uses the NTFS USN Journal to track changes and Chkdsk can determine if there are errors in the USN Journal that need to be repaired. These errors may cause DFS replication issues and prevent the database from recovering. Chkdsk will not trigger DFS replication.

Do: Check the size of your staging quota. DFS shares can grow in size, especially if used with roaming profiles or any other storage repository containing dynamically changing files. Microsoft recommends having the staging quota set as close as possible to the actual size of the data being replicated to maintain replication performance. There are minimum staging quota size recommendations out there that don’t come close to what is needed for large DFS shares. At a minimum, set the staging quota to 25% of the size of the data being replicated.

Do: Determine if Remote Differential Compression (RDC) is necessary for your replication group. RDC is useful for smaller DFS share implementations and for larger file sizes. It is also recommended for replication between branches with slow WAN connections. If your DFS share is large, contains lots of small files, or replicates only between LAN servers, RDC may actually cause replication slowing.

Do: WAIT… yup, just wait. Depending on the size of data being replicated and the number of files, it can take DFS several hours, even a day or more, to recover its database. You may see some 4412 log entries, but until you see 2214 in the log the database is not fully recovered. Just leave everything (yes, everything!) alone and wait it out.

Don’t: Do not restart the server (forcibly or otherwise); do not end the dfsrs.exe process in Task Manager if the DFS Replication service remains in a “Stopping” state for an extended period of time; do not attempt to delete the server as a member in the DFS replication group; do not modify the server’s connections in the DFS Management console. Restarting the server or ending the dfsrs.exe process will only cause more 2212 Warnings to be issued in the log and make DFS start all over trying to recover. Deleting the server as a member from the replication group and adding it back will also merely prompt the database to try to recover again. A brief review of the debug logs (located @ C:Windowsdebug) will reveal journal wrap notices. These are normal as the database tries to recover. Just… don’t do anything with anything.

Don’t: Do not try to rebuild the replication group. Again, all you will be doing is restarting the database recovery process on a database that isn’t working to begin with.

Alternative: If DFS simply won’t recover, an alternative is to create a new replication group, remove the server from the old group, and join it to the new one. Yes, this starts the database rebuild process all over again, but it’s an entirely new database with new connection and recovery information. This prevents DFS from attempting the rebuild process on a possibly corrupt database.

REFERENCES

Staging folders and Conflict and Deleted folders
You receive DFSR event ID 2212 after you restart the DFSR service in Windows Server 2008
Tuning replication performance in DFSR (especially on Win2008 R2)

[Прим. переводчика. Материал статьи относится к Windows Server 2003/2003R2/2008/2008R2, но большинство из описанного справедливо и для более поздних версий ОС]

Всем привет! Уоррен снова здесь, и этот пост в блоге представляет собой подборку наиболее распространенных проблем DFSR, с которыми я столкнулся за последние несколько лет. Цель этого поста — перечислить распространенные ошибки в конфигурации DFSR, из-за которых возникают эти проблемы, и уберечь вас от совершения аналогичных ошибок. Знать, чего делать не следует, так же важно, как знать, что нужно делать. Многие из описанных пунктов связаны с другими темами, поэтому для углубленного изучения вопроса предоставлены соответствующие ссылки.

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

Увидели в журнале много событий с кодом 4202 и 4204? В таком случае размер для промежуточной папки задан неверно. Неприятным последствием неправильно заданного размера промежуточной папки является снижение производительности репликации, так как вместо того, чтобы реплицировать файлы, служба будет тратить время на очистку промежуточной папки.
Серверы DFSR, для которых настроен достаточный размер промежуточной папки, работают более эффективно, как минимум, по двум причинам:

1. Гораздо эффективнее лишь единожды поместить файл в промежуточную папку, после чего отправить его всем принимающим партнерам по репликации, чем создавать файл, реплицировать его, а затем удалять его копию для каждого принимающего партнера.
2. Если хотя бы на одном члене установлена Enterprise-редакция операционной системы, серверы могут использовать технологию cross-file RDC [прим. переводчика: начиная с Windows Server 2012, данная технология доступна и в Standard-редакции]

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

Не игнорируйте события журнала для промежуточной папки.

Ознакомьтесь с этим постом, в котором описано, как использовать метод определения минимального размера промежуточной папки.

Ознакомиться с разделом «Увеличение промежуточной квоты» можно здесь.

Для получения информации о cross-file RDC можно почитать статью «Сведения об удаленном разностном сжатии», размещенную здесь.

Некорректная или не оттестированная preseeding-процедура

Preseeding-процедура — это копирование данных, которые будут реплицированы на новый сервер-член репликации до их добавления в конечную папку этого сервера, с целью сокращения времени, необходимого для завершения первичной репликации. Большинство сбоев preseeding-процедуры, с которыми я сталкивался, были вызваны тремя причинами.

1. Несоответствие ACL у источника и назначения.
2. После копирования на новый член репликации в файлы вносились изменения.
3. Не проводилось предварительного тестирования, чтобы проверить, что используемая preseeding-процедура работает так, как ожидается.

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

Щелкните здесь, чтобы прочитать блог мистера Пайла о том, как правильно организовать preseeding-процедуру ваших серверов DFSR.

Большой размер очереди копирования в течение долгого времени

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

DFSR используется в качестве решения для резервного копирования

Хотите верьте, хотите нет, но некоторые администраторы внедряют DFSR без автономных бэкапов реплицируемых данных. DFSR не был спроектирован как решение для резервного копирования. Одна из целей разработки DFSR — быть частью стратегии резервного копирования на предприятии, поскольку DFSR позволяет собрать ваши географически распределенные данные на централизованной площадке для последующего резервного копирования, восстановления и архивирования. С помощью нескольких членов репликации реализована защита от сбоя сервера, однако это не защитит вас от случайных удалений. Чтобы быть полностью защищенным, необходимо делать резервные копии своих данных.

Односторонняя репликация: ее использование и неверные методы исправления

В попытке предотвратить появление нежелательных обновлений на серверах, где никогда не будут изменяться данные, (или при желании предотвратить изменения на них) многие заказчики настраивали одностороннюю репликацию путем удаления исходящих подключений для членов репликации. Односторонняя репликация не поддерживается ни в одной из версий DFSR до Windows Server 2008 R2. В Windows 2008 R2 поддерживается односторонняя репликация, которая дает возможность настроить для реплицируемых папок режим «только для чтения».

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

Нажмите здесь и здесь, чтобы узнать о режиме репликации DFSR «только для чтения».

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

Нажмите здесь, чтобы узнать, как исправить проблему односторонней репликации.

Узловой сервер как единая точка отказа и перегруженные узловые серверы

Я видел много развертываний с единственным узловым сервером. Если этот узловой сервер выйдет из строя, то риску подвергнется все развертывание. Если вы используете Windows Server 2003 или 2008, у вас должно быть не менее двух узловых серверов, и если один из них выйдет из строя, то другой должен справиться с нагрузкой на время восстановления первого с минимальным влиянием на конечных пользователей. Начиная с Windows Server 2008 R2, можно развернуть DFSR на отказоустойчивом кластере Windows, что обеспечит высокую доступность при уменьшенной вдвое потребности в хранилище.

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

Прочтите раздел «Настройка топологии» здесь, чтобы узнать о развертывании узловых серверов.
Нажмите здесь, чтобы узнать, как настроить DFSR на отказоустойчивом кластере Windows Server 2008.

Слишком много папок для репликации на одну базу данных Jet

DFSR использует одну базу данных Jet на том. В результате размещение всех реплицируемых папок на одном томе приводит к размещению их всех в одной базе данных Jet. Если в этой базе возникнет проблема, требующая исправления или восстановления базы данных, то она затронет все реплицируемые папки на этом диске. [Прим. переводчика. очевидно, имеется в виду не диск (disk), а том (volume).] Правильнее будет использовать как можно больше дисков и распределить реплицируемые папки между ними, обеспечив тем самым максимальное время доступности данных.

Развертывания на основе бюджетных iSCSI-решений

Я не раз видел развертывания DFSR, где использовалось самое дешевое оборудование iSCSI. Обычно, если вы используете DFSR, то делаете это для достижения критически важных целей, таких как избыточность данных, консолидация резервных копий, доставка приложений и обновлений ОС по расписанию. Поставить себя в зависимость от низкокачественного оборудования, у которого нет нормальной поддержки от вендора, — не лучшая идея. Если для вашего бизнеса важны данные, значит, для него будет важным и оборудование, на котором работает ОС и механизм репликации.

Для службы DFSR не устанавливаются актуальные патчи

DFSR активно поддерживается корпорацией Майкрософт и для нее по мере необходимости выпускаются обновления. Обновляйте DFSR, если на момент вашего очередного цикла установки обновлений для нее есть новый релиз. Убедитесь, что ваши серверы обновлены согласно статьям базы знаний, перечисленным ниже.

Исправления DFSR для Windows 2003 R2
Исправления DFSR для Windows 2008 и Windows 2008 R2

Обратите внимание, что, помимо DFSR.EXE/DFSRS.EXE, перечисленные обновления предназначены также для NTFS.SYS и других файлов. Для корректной работы репликации всегда проверяйте, что самые последние версии патчей установлены как минимум для DFSR и NTFS. Другие исправления из списка в основном касаются проблем пользовательского интерфейса, и вам потребуется их установить хотя бы на тех системах, где выполняются задачи настройки DFSR.

Рекомендуется заблаговременно устанавливать патчи на сервера DFSR, даже если все работает нормально, так как впоследствии это поможет вам избежать появления уже известных проблем.

Не поддерживаются в актуальном состоянии драйверы сетевого адаптера

DFSR сможет работать нормально лишь в том случае, если сеть, которую вы ему предоставите, также работает без проблем. Использование драйверов 5-летней давности — не самое разумное решение. Я имел опыт общения с несколькими заказчиками, для которых проблемы с репликацией DFSR решились обновлением устаревшего NIC-драйвера.

Отсутствует мониторинг DFSR

Несмотря на то, что DFSR используется для перемещения, как правило, критически важных данных, многие админы не имеют представления о том, что делает DFSR, пока не столкнутся с проблемой. Те, кто понаходчивее, создают свои собственные скрипты для мониторинга очередей копирования на своих серверах, но большинство просто надеется на авось. Пакет управления для DFSR был выпущен почти год назад (а другие версии появились еще раньше). Установите его и используйте – и тогда вы сможете обнаружить проблемы и отреагировать на них до того, как они превратятся в кошмар. Если у вас нет возможности использовать пакет управления Operations Management для DFSR, то хотя бы напишите скрипт для отслеживания очереди копирования на ежедневной основе, чтобы понимать, реплицирует DFSR файлы или нет.

Нажмите здесь, чтобы получить информацию о пакете управления Operations Management для DFSR.

Обновлено 19 января 2011:

Внесение изменений в дисковое хранилище без предварительной архивации данных

Если на сервере DFSR требуется заменить жесткий диск или добавить новый для увеличения пространства хранения, крайне важно иметь актуальную резервную копию данных на случай, если что-то пойдет не так. Пойти не так может всё что угодно, чаще всего возникают события конфликтов из-за неожиданных изменений в родительской папке или случайного удаления родительской папки, которая реплицируется на всех партнеров. Необходимо создать резервную копию своих данных перед началом изменений и хранить ее до завершения проекта.

Остановка службы DFSR для временного прекращения репликации

Иногда возникает необходимость временно остановить репликацию. Правильный способ для этого – отключить репликацию для нужной группы с помощью расписания. Служба DFSR должна работать, чтобы иметь возможность читать обновления в журнале USN. Не останавливайте службу DFSR на длительный срок (дни, недели), так как это может привести к переполнению журнала (если за это время было изменено, добавлено или удалено много файлов). DFSR восстановится после переполнения журнала, но в больших развертываниях это займет много времени, и на время восстановления журнала репликация работать не будет или будет очень медленно. Также вы скорее всего будете наблюдать очень большие очереди копирования до тех пор, пока не завершится восстановление журнала.

Надеюсь, этот список вам поможет. Удачной репликации!

Уоррен “wide net” Уильямс

[Прим. переводчика. Если будет интерес читателей, постараюсь позже перевести статьи, размещенные по указанным в тексте ссылкам, а также другие статьи автора оригинала]

Нашли ли Вы у себя ошибки, описанные в статье?

Проголосовали 17 пользователей.

Воздержались 5 пользователей.

Это руководство содержит инструкции по устранению следующего предупреждающего события службы репликации файлов после миграция Active Directory 2003 в AD 2008, 2012 или 2016: «Событие 13577, NtFrs: Служба репликации файлов (FRS) устарело. Чтобы продолжить репликацию папки SYSVOL, необходимо перейти на репликацию DFS с помощью команды DFSRMIG. Если вы продолжите использовать FRS для репликации SYSVOL в этом домене, возможно, вы не сможете добавить контроллеры домена под управлением будущей версии Windows Server ».

Ошибка «Служба репликации файлов (FRS) устарела» появляется потому, что после появления Windows Server 2008 контроллеры домена используют новую распределенную файловую систему. Репликация (DFSR) вместо службы репликации файлов (FRS) для репликации сценариев входа в систему и файлов объектов групповой политики из папки SYSVOL в другой домен. контроллеры.

Итак,после миграции домена AD 2003 в AD 2008, 2012 или 2016, необходимо также обновить тип репликации папки SYSVOL с FRS до DFSR, чтобы устранить ошибку с идентификатором 13577: «NtFrs: Служба репликации файлов (FRS) устарела».

Как перенести репликацию SYSVOL с FRS на DFSR.

Шаг 1. Проверьте работоспособность контроллеров домена с помощью DCDIAG.

1. На каждом контроллере домена откройте командную строку с повышенными привилегиями и введите следующую команду, чтобы проверить работоспособность контроллеров домена. *

• dcdiag

2.Важный:Прежде чем переходить к следующим шагам, убедитесь, что что все тесты, кроме теста «FrsEvent», пройдены.

Шаг 2. Повышение функционального уровня леса и домена

1. На основном контроллере домена AD откройте Диспетчер сервера.
2. От Инструменты меню выберите Домены и доверие Active Directory.

3. Щелкните правой кнопкой мыши имя домена и выберите Повышение функционального уровня домена.

4. Установите функциональный уровень домена на Windows Server 2008 и нажмите Поднимать.

5. Нажмите В ПОРЯДКЕ, чтобы поднять функциональный уровень, а затем снова нажмите OK до успешного сообщения.

6. Затем щелкните правой кнопкой мыши на Домены и доверие Active Directory и выберите Повышение функционального уровня леса

7. Установите функциональный уровень леса на Windows Server 2008 и нажмите Поднимать.

8. Нажмите В ПОРЯДКЕ чтобы поднять функциональный уровень леса, а затем нажмите В ПОРЯДКЕ снова к успешному сообщению.

Шаг 3. Создание объектов DFSR Global AD

1. На основном контроллере домена AD откройте Командная строка от имени администратора и введите следующую команду, чтобы создать необходимые объекты DFSR Global AD. (Это полезно, если контроллер домена только для чтения (RODC) не может начать миграцию в течение длительного времени.)

• dfsrmig / CreateGlobalObjects

2. Перейдите к следующим шагам, чтобы начать миграцию FRS в DFSR.

Шаг 4. Установите FRS в состояние миграции DFSR в значение PREPARED. *

* Информация: В состоянии «PREPARED» служба репликации DFS создает для себя копию содержимого общего ресурса SYSVOL. Затем он приступает к репликации своей копии папки SYSVOL на всех других контроллерах домена с помощью службы репликации DFS, которая также перешла в состояние «ПОДГОТОВЛЕН». На этом этапе процесса миграции основным механизмом репликации для общего ресурса SYSVOL на каждом из контроллеров домена в домене по-прежнему является FRS.

1. В командной строке с повышенными привилегиями введите следующую команду:

• dfsrmig / setglobalstate 1

2. Затем убедитесь, что все контроллеры домена успешно перешли в состояние «ПОДГОТОВЛЕН», введя следующую команду: *

• dfsrmig / getMigrationState

* Примечание: Если вы получили сообщение «Миграция еще не достигла согласованного состояния на всех контроллерах домена. Информация о состоянии может быть устаревшей из-за задержки доменных служб Active Directory. «После выполнения указанной выше команды подождите несколько часов. а затем вводите эту команду еще раз, пока не получите сообщение «Все контроллеры домена успешно перешли в глобальное состояние (« Подготовлено »).
Миграция достигла согласованного состояния на всех контроллерах домена. Успешно «.

3. После успешной миграции в глобальное состояние «Подготовлено» на всех контроллерах домена проверьте следующее:

1. Перейдите к C: Windows каталог и убедитесь, что «SYSVOL_DFSR«папка создана на всех контроллерах домена.

2. Бегать adsiedit.msc

а. Щелкните правой кнопкой мыши на Редактировать ADSI и выберите Подключиться к…. -> Контекст именования по умолчанию и нажмите В ПОРЯДКЕ.

б. Затем разверните Контекст именования по умолчанию > DC = домен > CN = Система и убедиться, что CN = DFSR-GlobalSettings был создан.

3. Убедитесь, что SYSVOL по-прежнему используется совместно с «C: Windows SYSVOL sysvol», введя следующую команду:

• чистая доля

4. Проверьте работоспособность репликации Active Directory, введя эту команду (результат должен показать, что на всех контроллерах домена нет ошибок):

• RepAdmin / ReplSum

Шаг 5. Установите FRS для состояния миграции DFSR на REDIRECTED *

* Информация: В состоянии «REDIRECTED» репликация переключается на службу репликации DFS, которая начинает репликацию новой папки SYSVOL (C: Windows SYSVOL_DFSR sysvol). В то же время FRS реплицирует старую папку SYSVOL (C: Windows SYSVOL sysvol) на другие контроллеры домена.

1. Следующий шаг — заставить все контроллеры домена изменить общий ресурс SYSVOL, чтобы он указывал на новую папку SYSVOL_DFSR. Для этого введите следующую команду:

• dfsrmig / setGlobalState 2

2. Теперь подтвердите, что все контроллеры домена достигли состояния перенаправления, введя следующую команду: *

• dfsrmig / getMigrationState

* Примечание: Если вы получили сообщение «Следующие контроллеры домена не достигли глобального состояния (« Перенаправлено »)…» после выполнения указанной выше команды, тогда подождите несколько часов и снова введите команду, пока не получите следующее: «Все контроллеры домена успешно перешли в глобальное состояние. («Перенаправлено»). Миграция достигла согласованного состояния на всех контроллерах домена. Успешно «.

3. После успешной миграции в глобальное состояние «Перенаправлено» на всех контроллерах домена проверьте следующее:

1. SYSVOL теперь является общим из папки «C: Windows SYSVOL_DFSR sysvol» с помощью команды «net share»:

2а. Откройте редактор реестра на всех контроллерах домена и перейдите по указанному ниже пути:

• HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services DFSR Parameters SysVols Migrating SysVols

2b. Убедитесь, что ‘Путь к SYSVOL DFS-R’ ключ реестра указывает на: «C: Windows SYSVOL_DFSR sysvol«
2c. Убедитесь, что ‘LocalStateРаздел реестра установлен на 2

3. Принудительная репликация Active Directory на контроллере домена. Для принудительной репликации Active Directory введите эту команду на контроллере домена:

• repadmin / syncall / AeD

4. Заставьте службу репликации DFS опросить Active Directory. Чтобы принудительно провести опрос Active Directory, введите команду «dfsrdiag PollAd» на контроллере домена. Для принудительного опроса Active Directory введите эту команду на контроллере домена: *

• dfsrdiag PollAd / Участник:DC_NAME

* Примечание: Измените DC_Name с контроллером домена, который вы хотите принудительно опросить Active Directory.

4. Если все в порядке, переходите к следующему шагу. Если что-то не так, вы можете выполнить откат из состояния «ПЕРЕНАПРАВЛЕН» в состояние «СТАРТ», подав следующую команду:

• dfsrmig / setglobalstate 0

Шаг 6. Установите FRS в состояние миграции DFSR в ELIMINATED.

Информация: В состоянии «ELIMINATED» и после того, как вы убедились, что репликация работает нормально, пора заставить все контроллеры домена остановить службу FRS и удалить папку SYSVOL. Для этого:

1. В командной строке введите следующую команду:

• dfsrmig / setGlobalState 3

2. Наконец, убедитесь, что все контроллеры домена достигли состояния УСТРАНЕНО:

• dfsrmig / getMigrationState

3. После успешной миграции с FRS на DFSR следующие события будут записаны в Просмотрщик событий > Журналы приложений и служб:

а. Служба репликации файлов: Код события 13503 — NtFrs> Служба репликации файлов остановлена.

б. Репликация DFS: Идентификатор события 8019 — DFSR> «DFSR успешно перевел контроллер домена DC_NAME в состояние« УДАЛЕНО ». NTFRS больше не реплицирует общий ресурс SYSVOL, расположенный в C: Windows SYSVOL. DFSR в настоящее время реплицирует папку SYSVOL_DFSR, расположенную в C: Windows SYSVOL_DFSR. Служба NTFRS отключена на этом DC.
Перенос DFSR для контроллера домена% Server_Name% завершен. «

Вот и все! Сообщите мне, помогло ли вам это руководство, оставив свой комментарий о своем опыте. Пожалуйста, поставьте лайк и поделитесь этим руководством, чтобы помочь другим.