Проблема репликации Windows 2008 DFS

Это происходит после установки исправления 2663685 http://support.microsoft.com/kb/2663685

Он изменяет поведение после «грязного» выключения DFSR, так что автоматический перезапуск больше не происходит, вместо этого он остается выключенным, позволяя вам делать любые резервные копии, которые могут вам понадобиться, а затем вы запускаете команду WMI в соответствии со статьей, чтобы перезапустить его.

Предупреждение: применение этого исправления в кластере означает, что оно не очень доступно, так как при переключении на резерв DFSR будет отключен на узле. Вы можете настроить это с помощью параметра реестра. Лично я собираюсь отменить это исправление во всем нашем поместье, так как это больше проблем, чем оно того стоит, DFSR падает и не возвращается в сеть, пока мы не приедем в понедельник, а отставания просто растут и растут.

Самый простой способ снова запустить это приложение - зайти в средство просмотра событий и перейти к Applications and Services Log > DFS Replication. Ищите событие 2213:

Там находится точная команда, которую вам нужно запустить.

Кроме того, чтобы вернуть DFS-R к исходным настройкам, запустить это:

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set StopReplicationOnAutoRecovery=FALSE

Я столкнулся с подобной проблемой, но исправление 2663685 не было моей проблемой. В моем случае dfsrdiag будет работать с некоторыми из моих реплицированных папок, но не со всеми. Реплицированные папки были распределены по разным дискам.

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

wmic /namespace:\\root\microsoftdfs path dfsrvolumeinfo get volumepath, VolumeGuid

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

wmic /namespace:\\root\microsoftdfs\ path dfsrVolumeConfig get *

Также проверьте C: \ Windows \ debug \ dfsr * .log на наличие других сообщений о том, что диск не готов или не может прочитать серийные номера.

Чтобы решить эту проблему, мне пришлось остановить DFSR и удалить / переименовать базу данных. Затем он начал синхронизацию, и через некоторое время после перестройки команды наконец заработали.

1. Откройте командную строку как системную (я ненавижу изменять разрешения «информации о системном томе», делая это, вы можете этого избежать. Google, как это сделать.)
2. Перейдите к диску с поврежденной базой данных .ie "D:"
3. cd "информация о системном томе"
4. cd "DFSR"
5. переименовать Config \ Volume_.XML Config \ Volume_.OLD
6. переименовать Config \ Replica_.XML Config \ Replica_.OLD
7. переименовать database_ database__OLD
8. чистый старт dfsr
9. dfsrdiag pollad

https://social.technet.microsoft.com/Forums/windowsserver/en-US/95873844-af76-4b7d-a4ee-2224a2e243cc/distributed-file-system-replication-dfsr-the-content-set-was-not- found-error? forum = winserverfiles & prof = требуется

Также журналы DFSR могут быть подробными и по умолчанию ограничены до 1000 файлов журналов. Пожалуйста, измените уровень журнала на что-нибудь нормальное, потому что как только вы достигнете 1000 DFSR, просто остановится.

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set debuglogseverity=3

https://blogs.technet.microsoft.com/askds/2009/03/23/understanding-dfsr-debug-logging-part-1-logging-levels-log-format-guids/

Поскольку он действительно работает с другим томом, чем D, я бы предположил, что он связан с томом D, и переформатировал этот том (или просто удалил и воссоздал том) или навсегда переместил реплику на другой том. Если что-то действительно не так с самим DFSR, он не будет работать независимо от реплики или тома.

В нашем случае на одном из томов на одном из серверов закончилось место на диске. К счастью, это была виртуальная машина, поэтому я просто расширил ее, перезапустил DFS, и все было хорошо. Я прочитал этот пост и покопался в статьях базы знаний и взломах реестра, прежде чем искать простое решение. Бритва Оккама снова побеждает.