The DFS Replication service failed to replicate the replicated folder at local path F:\Files\Enterprise because the local path is not the fully qualified path name of an existing, accessible local folder.

Additional Information:
Replicated Folder Name: Enterprise
Replicated Folder ID: C5E44E34-773F-4CC5-8BA3-B60DE9C3F78E
Replication Group Name: File Servers Group
Replication Group ID: 9BD925FD-AD73-45F8-8473-2A0AFAEEE52A
Member ID: 2073F8D1-1D51-4AB4-B1DB-2631E05EF836

Операционная система: Windows 2008, Windows 2008 R2

Решение:
Причина возникновения ошибки – недоступность целевой папки на которую указывает ссылка F:\Files\Enterprise\DfsrPrivate.

• Остановить службу DFSR

  net stop dfsr

• Удалить ссылку F:\Files\Enterprise\DfsrPrivate
• Запустить службу DFSR

  net start dfsr

Применяются два метода разрешения конфликтов:

1. метод основанный на модели – выигрывает записавший последним. Он применяется для файлов обновляемых одновременно на нескольких серверах.
2. метод основанный на модели – выигрывает создавший первым. Он применяется для разрешения конфликтов имен.

В обоих случаях файлы и папки, отмеченные как конфликтные, перемещаются в папку конфликтов и удалений. Для каджок группы репликации она индивидуальна и расположена в папке \dfsrprivate\conflictanddeleted.

Давайте рассмотрим типовые сценарии разрешения конфликтов.

Сценарий 1: Первоначальная синхронизация папок.

Имеется два сервера SRV-01 и SRV-02 с папками D:\Files.
Для примера будем использовать файл primer.doc находящийся в папке D:\Files.

На сервере SRV-01 файл primer.doc имеет дату создания август 2010.
На сервере SRV-02 файл primer.doc имеет дату создания сентябрь 2010 и дату последней модификации от текущего дня.

1. Настраиваем группу репликации для обоих серверов
2. Включаем в группу папки D:\Files на обоих серверах
3. Устанавливаем SRV-01 как основной сервер

Результат: primer.doc имеющий дату создания «август 2010″ и присутствует на обоих серверах, файл со второго сервера, созданный в сентябре, удален как конфликтный.
Пояснение: Данные с первого сервера, он установлен как основной, будут выигрывать во всех конфликтных ситуациях.
Что делать: При настройке репликации копия данных должна создаваться в пустой папке. Если папка содержала данные то одинаковые файлы остаются на месте а все остальное перемещается в папку preexisting.

Сценарий 2: Существующие файлы были модернизированы на обоих серверах.

Даны два сервера – SRV-01 и SRV-02.
Настроена группа репликации в которую входят папки D:\Files.
В папках есть файл primer.doc.

Предположим что вы изменили данные на первом сервере и дождались окончания репликации.
Теперь имитируем недоступность файлового сервера методом выдергивания из него сетевого кабеля.
Производим изменения в файле primer.doc на втором сервере.
Включаем сетевой кабель на первом (вроде как «устраняем сбой»).

Результат: Файл измененный последним реплицируется на первый сервер, а версия находящаяся на нем удаляется как конфликтная.
Пояснение: В данной ситуации будет выигрывать версия файла который изменяли последним.
Что делать: В случае если файл необходим то «достать» его можно в папке конфликтов (ConflictAndDeleted). Следует помнить что при помещении файла в папку конфликтов запись об этом заносится в файл ConflictAndDeletedManifest.xml. Если один из сервер долгое время был не доступен то перед его включением, на всякий случай стоит поднять размер квоты с 660 мб на более высокое значение.

Сценарий 3: Файлы с одинаковыми именами созданы на обоих серверах.

Даны два сервера – SRV-01 и SRV-02.
Настроена группа репликации в которую входят папки D:\Files.
На первом сервере присутствует файл primer.doc
Имитируем сбой сетевого адаптера на первом сервере.

1. Создаем файл primer.doc на втором сервере.
2. Модифицируем файл на втором сервере.
3. Подключаем сетевой кабель в первый сервер.

Результат: Файл с первого сервера реплицируется на второй, а файл со второго удаляется как конфликтный.
Пояснение: Это единственный случай когда в конфликте выигрывает файл на первом сервере. По умолчанию считается что в данном случае наиболее важным среди файлов с одинаковыми именами является более старый файл.
Что делать: В случае если файл необходим то «достать» его можно в папке конфликтов (ConflictAndDeleted). Следует помнить что при помещении файла в папку конфликтов запись об этом заносится в файл ConflictAndDeletedManifest.xml.

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

Описание проблемы:
Репликация папок не работает, в журнале «DFS Replication» вот такая ошибка

через некоторое время после старта сервиса он останавливается.

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

Действия:
1. Остановка службы

2. Перенос или удаление всех debug-логов Dfsr#####.log из папки %windir%\debug.
3. Запуск службы

4. Изучение полученных логов
При изучении debug лога находятся следующие строки.

Данное сообщение означает что служба DFSR не смогла получить доступ к служебной базе данных.

Возможные причины:
База недоступна из-за повреждения диска или логической ошибки.
База недоступна из за блокировки сторонним программным обеспечением, например антивирусом.

Действия:
Перезагрузка. Как правило в пятидесяти процентах случае это решает проблему.
Произвести проверку настроек антивируса согласно статье базы знаний Microsoft.
Восстановление базы DFSR. Крайнее средство на которое можно идти только после того как другие методики исчерпаны.

о
1. На папку SystemVolumeInformation проблемного тома, в данном случае D:, назначаем дополнительные разрешения для администратора – полный доступ.
2. Из вышеуказанной папки удаляем подпапку DFSR.
3. Запускаем службу DFSR. После старта службы папка сформируется заново и служба начнет синхронизацию с партнером. В логах появляется сообщение

Которое означает что «первоначальная» репликация начата. Время завершение зависит от многих факторов таких как скорость соединения или объем хранимых файлов.

1. Заголовок (Header)
2. Сообщение (Single-line message)
3. Вложенное сообщение (Nested message)

Заголовок (Header)

Как правило начинается с символа «*», для примера:

* FRS Log Sequence:15 Index:100 Computer:LAB-DC01 TimeZone:Russian Standard Time (GMT+-3:00) Build:[Feb 16 2007 20:14:20 built by: srv03_sp2_rtm] Enterprise=0
* Configuration logLevel:4 maxEntryCount:200000 maxFileCount:100 logPath:\\.\D:\Logs\DFSR-debug\

В заголовке используются следующие поля:

• FRS Log Sequence & Index – Последовательность и индекс
• Computer – имя сервера.
• TimeZone – временная зона.
• Build – версия сборки.
• Configuration loglevel – уровень детализации журнала.
• Maxentrycount – количество хранимых в журнале сообщений.
• Maxfilecount – максимальное количество хранимых файлов журналов.
• Logpath – путь к папке где хранятся журналы.

Сообщение (Single-line message)

Single-line message фактически является описанием всех действий, детализация которых зависит от установленного параметра LogLevel, об установке значения я уже писал вот в этой статье.
Single-line message всегда начинается со строки даты-времени в формате YYYYMMDD HH:MM:SS:MS.

Пример сообщения:

20100225 16:45:09.563  724 MRSH  2957 MarshalContext::Initialize Create file:[lang-1034.dll-{AF7C15F9-60F0-4AE8-95D0-A5860F1BC208}-v5777330] with attributes:0x20

Сообщение имеет следующие поля:

• Date-Time – Время в формате YYYYMMDD HH:MM:SS:MS. В данном примере – 20100225 16:45:09.563
• Thread – описание «нити» в пределах DFSR.EXE. В данном примере – 724
• Module ID – ID модуля DFSR. В данном примере – MRSH
• Line – Строка из исходного кода. В данном примере – 2957
• Class – Запускаемый класс. В данном примере – MarshalContext
• Method – Метод или функция запущенные в пределах класса. В данном примере – Initialize Create file
• Data – Детальная информация о действии. Детализация зависит от уровня журналирования. В данном примере – [lang-1034.dll-{AF7C15F9-60F0-4AE8-95D0-A5860F1BC208}-v5777330] with attributes:0×20

Вложенное сообщение (Nested message)

Всегда идет после Single-line message и детализирует его.
Всегда начинается со знака «+»

+     TOTAL
+     Compression Ratio            43 %
+     Target Uncompress Size            426628
+     Target Compress Size              246079
+     Bytes Received                      5021 Signatures:       3336 Data:       1685
+     Signature Bytes Received            3336           3336
+     Number of remote calls                 3 Signatures:          1 Needs:          1 Data:          1
+     SEED
+     Rdc Need Size                     417124        417124
+     Xpress Blocks                         52            52
+     Uncompressed Xpress Blocks            52            52
+     Blocks copied to target                0             0
+     SOURCE
+     Rdc Need Size                       9504           0
+     Xpress Blocks                          2           0
+     Uncompressed Xpress Blocks             1           0
+     Blocks copied to target                1           0

Поля common GUID

Каждая группа репликации, каждая папка имеет уникальные глобальные идентификаторы (GUID-ы) которые используются в работе DFSR при определении топологии репликации и пр.

Как пример можно привести кусок лога где указаны GUID-ы.

20100226 10:27:41.987 2764 SRTR   329 SERVER_EstablishConnection Succeeded on connId:{24098152-99D7-4E9A-AF74-2C5133308DDD} replicaSetId:{663CD41D-A76D-40F7-BB5B-5B7629027F3D} partnerAddress:LAB-DC02.EXAMPLE.COM
20100226 10:27:41.987 2764 OUTC  1876 OutConnection::EstablishSession Replacing content set. csId:{8E6CA826-E8B3-4600-80B1-16D73658D9A6} connId:{24098152-99D7-4E9A-AF74-2C5133308DDD} rgName:LABOffice2

• ReplicaSetId – GUID группы репликации. В данном примере – {663CD41D-A76D-40F7-BB5B-5B7629027F3D}
• partnerAddress – имя партнера по репликации. В данном примере – LAB-DC02.EXAMPLE.COM
• CSID – GUID папки. В данном примере – {8E6CA826-E8B3-4600-80B1-16D73658D9A6}
• ConnID – GUID соединения. В данном примере – {24098152-99D7-4E9A-AF74-2C5133308DDD}
• rgName – имя группы репликации. В данном примере – LABOffice2

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

Предлагаю для всех небольшую «таблетку аспирина» т.к. сегодня речь пойдет об отладочных (debug) журналах DFSR.

Включение отладки
По умолчанию журналирование включено, но при необходимости оно отключается.

Настройка: Enable Debug Logging
По умолчанию: TRUE
Значения: TRUE или FALSE

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

Настройка: Debug Log File Path
По умолчанию: %windir%\debug

Перемещаем отладочные журналы в папку d:\DfsrDebugLogs.
Внимание. Пака должна быть создана вручную, если её не создать то после рестарта сервис будет использовать стандартную для себя %windir%\debug

Уровни журналирования.
DFSR использует циркулярное журналирование файлов журналов в папке %systemroot%\debug и автоматически сжимает журналы в GZ-формат.

На Level 0 (LogLevelNone) ничего не пишется.
На Level 1 (LogLevelAlways) записываются только информационные сообщения.
На Level 2 (LogLevelError) записываются только ошибки и информация из предыдущих уровней.
На Level 3 (LogLevelWarn) записываются предупреждения и информация из предыдущих уровней.
На Level 4 (LogLevelInfo) записывается вся информация и информация из предыдущих уровней.
На Level 5 (LogLevelTrace) максимальный уровень журналирования.

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

Настройка: Debug Log Severity
По умолчанию: 4
Значения: 1-5

Для изменения уровня журналирование можно воспользоваться утилитой WMIC.EXE, в данном примере мы выставляем максимально доступный уровень.

Количество хранимых в журнале сообщений.
Настройка: Debug Log Messages
По умолчанию: 200000
Значения: 1000 до 4294967295 (FFFFFFFF)

Поднимем количество сохраняемых сообщений до 500000.

Количество хранимых сообщений
Теперь определим сколько файлов журналов нам требуется.

Настройка: Debug Log Files
По умолчанию: 100
Значения: от 1 до 10000

Увеличим количество хранимых журналов до 150

Команда WMIC.EXE модификирцет файл конфигурации DfsrMachineConfig.XML который находится в папке %systemdrive%\system volume information\dfsr\config. В примере приведенном ниже установлен максимальный уровень журналирования с ведением более подробных журналов.

<DfsrDebug>
<EnableDebugLog>true</EnableDebugLog>
<DebugLogFilePath>D:\DFSRLogs\debug</DebugLogFilePath>
<MaxDebugLogFiles>200</MaxDebugLogFiles>
<DebugLogSeverity>5</DebugLogSeverity>
<MaxDebugLogMessages>500000</MaxDebugLogMessages>
</DfsrDebug>

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

Описание проблемы:
Есть две активных DFS-реплики.
Репликация успешно проходит с первой на вторую, но назад не идет.

Действия:
Приступим к анализу debug логов которые лежат в папке %windir%\debug.
В файлах \Dfsr#####.log на сервере откуда НЕ реплицируются данные присутствует такой фрагмент.

Означает это примерно следующее – с удаленного сервера было получено сообщение о том что он не готов произвести репликацию из-за возникшей ошибки и через некоторое время повторит попытку.

Причина подобного отказа кроется в debug-логах на downstream-сервере.

Идем на второй сервер и в логах видим что то подобное.

Решение:

1. Временно выключить File Screening на реплике откуда не реплицируются файлы.
2. Перезапустить DFSR
3. Если это исправляет ситуацию нужно смотреть что написано в конфигурации FSRM-а.
4. Удалить все файлы которые являются причиной блокировки.

Рекомендации:
Перед принятием решения использования File Server Resource Manager на DFS-реплике необходимо удалить все файлы на которые планируется наложить ограничение, например все исполняемые файлы.

Произвести это проще всего powershell-ом

Если необходимо для начала выяснить что именно будет удалено то в строку добавьте -WhatIf

Традиционная методика анализа у многих администраторов к сожалению такова – останавливаем службу, чистим логи, запускаем службу… И ничего не находя идем доставать с полки бубен.
Коллеги! логи не резиновые но довольно большие и чистить их каждые пять минут не обязательно, DFSR не многословна и журналы её довольно часто помогают понять что именно и в какой момент времени произошло.

Речь сегодня пойдет о самой опасной ошибке, после появления которой репликация останавливается.

Три причины возникновения ошибки DFSR eventid:4502:

Вариант №1
Статья с описанием находится по адресу.

Проблема наблюдается при ошибках конфигурирования квот.
Например, на папку DfsrPrivate действует квота которая препятствует записи в staging folder и как следствие DFSR служба останавливает репликацию.

Диагностика и устранение неполадок:

1. Останавливаем службу DFSR.
2. Удаляем папку Staging.
3. Запускаем службу DFSR.
4. При повторении устанавливаем хот-фикс из ссылки выше.

Вариант №2
Статья с описанием находится по адресу.

При наличии одного или нескольких upstream серверов и нескольких downstream серверов и созданных на них средствами File Server Resource Management hard квот, при условии того что размер квоты на исходном сервере больше чем на целевом или вообще отключен наблюдаются следующие симптомы:

1. На сервере-источнике файл помещается в папку.
2. На целевом сервере при достижении квоты репликация останавливается.

Рекомендации:

1. Перед установкой квоты проверить не превышает ли объем папки размер квоты.
2. Применять hard квоты осторожно.
3. На папку DfsrPrivate квоту лучше не ставить вообще.

Диагностика:

1. Проверить размеры установленных квот на всех серверах.
2. При наличии проблемы отключить квотирование на папке.
3. Перезапустить службу DFSR.
4. В случае повторения установить хот-фикс хот-фикс из ссылки выше.

Вариант №3
Статья с описанием находится по адресу.

Самый интересный вариант. Проблема звучит примерно так – фильтр драйвера Quota.sys неверно считает использованное пространство и учитывает место занятое теневыми копиями.
Результатом является следующий эффект.

1. В логе имеется ошибка 4502
2. В проводнике выдается что размер папки составляет xx Гб, а квота которая составляет ххх Гб исчерпана.

Диагностика и устранение неполадок:

1. Удаляем теневые копии
2. Перезапускаем сервис DFSr
3. При повторении проблемы ставим хот-фикс хот-фикс из ссылки выше.

Послесловие:

Не стоит забывать что использование FSRM-а совместно со службой DFSR накладывает на DFS-реплику некоторые ограничения.

• Планируйте ограничения и дизайн файловых ресурсов так что бы к скрытой папке DfsrPrivate не применялись никакие фильтры.
• Перед включением блокировки ни одна из реплицируемых папок не должна содержать блокированных файлов.
• Не лишним будет заскочить на страничку DFS FAQ
• И заодно ознакомится с рекомендациями по дизайну