D2 FRS восстановить удаленный sysvol
Я унаследовал два ужасных сервера (не спрашивайте), и оказалось, что он использует FRS для репликации sysvol между PDC и вторым DC. (Я проверил ключ реестра)
Я попытался использовать https://docs.microsoft.com/en-gb/windows/desktop/VSS/backing-up-and-restoring-an-frs-replicated-sysvol-folder что очень полезно и информативно, однако после Я попробовал неавторизованное восстановление D2, содержимое моей папки sysvol было удалено, а сам общий ресурс также удален, если вы можете в это поверить. Он сохранил в нем уже существующие файлы, однако после второго восстановления D2 он даже удалил их. (хорошо, что я поддержал все это)
Почему это удаляет даже общий ресурс, я могу понять, что он удаляет содержимое папки, поскольку это то, что он должен делать, но сам ресурс?
Оба сервера 2008 R2, не знаю, были ли они 2003 раньше.
Какие-нибудь мысли?
Это потому, что я не выполнил "Шаг 2 Восстановите резервные копии данных в папку SYSVOL"? Этот шаг, похоже, нигде не перечислен в сети и не имеет особого смысла, поскольку данные должны просто повторно синхронизироваться с хорошим sysvol на другом сервере, верно?
0 ответов
Это может быть не совсем ответ, и я бы прокомментировал, но не хватает репутации. Я только что завершил этот процесс на паре контроллеров домена Windows Server 2012 R2, также все еще использующих FRS для репликации SYSVOL. Результат был успешным, и SYSVOL теперь хорошо для меня реплицируется (первоначальная проблема заключалась в том, что по какой-то причине я не смог определить, вошел ли он в состояние JRNL_WRAP_ERROR).
Я полагаю, что вы должны указывать авторитетный сервер вместо неавторизованного сервера. Таким образом, полномочный сервер сообщит другим членам реплики получить свой "авторитетный" набор данных. Если вы установите D2 на обоих, ни один из них не будет утверждать, что у них есть надлежащие файлы, поэтому я могу представить, что результатом будет то, что вы описали, где нет авторитетного источника, и поэтому они уничтожат себя и поместят содержимое в -существующая папка (это также то, что мой неавторизованный сервер делал, когда установлен с D2). Я считаю, что D2 действительно предназначен для получения здорового набора данных с сервера D4.
Я думаю, что все, вам нужен авторитетный источник. Кроме того, я практиковал это в тестовой среде, и даже при использовании D4 на одном сервере и D2 на другом, SYSVOL был очищен на обоих серверах (думаю, из-за того, что контроллеры домена действительно теряют разум при восстановлении из полной резервной копии виртуальной машины). как я сделал, но я не уверен). Я восстановил все свои объекты групповой политики, используя Restore-Gpo -All -Path C:\Path\To\GPO\Backups в PowerShell и вручную создайте папку "scripts" в C:\Windows\SYSVOL\domain, которая автоматически использовалась как NETLOGON после перезагрузки. Это исправило мои проблемы с репликацией и сохранило все мои объекты групповой политики. Даже ссылки на объекты групповой политики были в порядке после восстановления объектов групповой политики.
Итак, если у вас есть резервная копия ваших объектов групповой политики (которую вы можете создать с помощью Backup-Gpo -All -Server localhost -Path C:\Path\To\Gpo\Backup) или даже резервную копию сервера, которую вы можете раскрутить в изолированной сети или гипервизоре, затем вы можете использовать резервные копии объектов групповой политики для их восстановления и вручную создать папку сценариев. Это вернуло меня в норму, когда я тренировался в тесте. Удачи, если вы все еще боретесь с этим.