Почему не проходит репликация dfs в windows server?
Есть два сервера SRV1 и SRV2
SRV1 физический сервер с Windows 2008 r2
SRV2 виртуальная машина(VMWARE esx 5.5) c Windows 2012 r2
На SRV1 поднята роль DFS и между серверами настроена реплика. С SRV1 идет в одну сторону реплика на SRV2
Собственно сама проблема. Репликация на проходит. Точнее она проходила какое-то время, сейчас не идет. При запуске диагностического отчета все ОК.
У вас есть недоделанный кластер сервер DC3 у вас состоит в этом кластере? И ещё вопрос у вас реплика AD между DC1 и DC3 проходит? Ещё как радикальный вариант можете удалить полностью DFS с DC3 перегрузить и заново установить DFS и настроить реплику.
Поддержка транзакций в указанном диспетчере ресурсов не запущена
Пользователи жаловались на невозможность добавлять, редактировать или удалять запланированные задачи в Windows 10. Каждый раз, когда они пытаются выполнить любое из этих действий, они получают следующее сообщение об ошибке:
Поддержка транзакций в указанном диспетчере ресурсов не запущена или была отключена из-за ошибки.
Приведенное выше сообщение об ошибке связано с Центром обновления Windows, так как вы также можете не установить обновления. К счастью, решить эту проблему несложно, и в этом руководстве мы покажем вам, как это сделать.
Аномалия, когда вы испытываете указанную выше ошибку, заключается в том, что она говорит, что работает в службах диспетчера задач, несмотря на то, что планировщик задач не открывается. Мы исправим эту проблему, используя следующие решения:
Продолжайте читать это руководство, чтобы получить полную информацию о вышеуказанных исправлениях.
1]Очистить все содержимое каталога TxR
Откройте проводник Windows и включите просмотр скрытых файлов. Для этого перейдите в Вид меню и проверьте Скрытые предметы флажок, который он показывает.
Затем щелкните адресную строку, введите следующий адрес и нажмите ENTER:
Это подводит вас к TxR папка. нажмите CTRL + A комбинация, чтобы выбрать все в этом каталоге и использовать CTRL + X чтобы все это вырезать.
Затем перейдите в другой каталог и нажмите CTRL + V чтобы вставить файлы в это новое место. Теперь вы можете выйти из проводника.
2]Сбросить диспетчер транзакционных ресурсов с помощью fsutil
Первым шагом этого решения является открытие командной строки от имени администратора.
Для этого нажмите кнопку Window и найдите cmd. Щелкните правой кнопкой мыши командную строку и выберите Запуск от имени администратора.
Введите следующую команду и нажмите клавишу ВВОД, чтобы запустить ее.
ПРИМЕЧАНИЕ: Приведенная выше команда с использованием C . Однако вы должны изменить это на букву вашего системного диска.
Наконец, выйдите из командной строки и перезагрузите компьютер.
3]Замените жесткий диск
Если вы получаете ошибку на виртуальной машине, а два других исправления не решают проблему, это может означать, что ошибка связана с аппаратной проблемой на вашем жестком диске.
Плохой диск (RAID 1) может вызвать эту ошибку, потому что виртуальная машина не может видеть привод. Таким образом, замена жесткого диска может быть последним решением.
Удаление неправильно выведенного из строя сервера Exchange
Бывают случаи, когда сервер исчез/перезалился/потерялся без удаления на нём Exchange, но остался в системе. Избавиться от него и его хвостов одной кнопкой, к сожалению, не получится.
Есть два пути для удаления следов:
Я являюсь категорическим противником второго варианта. Никогда не знаешь, всплывёт где-нибудь когда-нибудь или нет. Поэтому, делюсь удалением через восстановление.
Берём такую же операционную систему, как и на потерянном сервере. Производим установку Exchange через командую строку с использованием ключа /Mode:RecoverServer.
После установки, перезагружаемся и запускаем удаление:
После удаления, у меня подчистились все хвосты неправильно удалённого сервера Exchange.
Возможные ошибки
Сервер может не установиться до конца. Это не страшно. Если была пройдена проверка перед установкой, установка началась и какие-то из компонентов установились, но потом на чём-нибудь свалилось в ошибку — всё ок. Можно перезагрузиться и запустить удаление. В моих случаях происходило полное удаление сервера.
Ошибка «The language pack bundle could not be found or is corrupt
На этапе проверки, перед установкой, возникла следующая ошибка:
Эта ошибка решилась удалением на сервере ветки реестра: HKEY_LOCAL_MACHINESOFTWAREMicrosoftExchangeServerv15Lanaguage Packs
Описание решения есть у Микрософт: https://support.microsoft.com/ru-ru/help/3069005/error-when-you-try-to-install-exchange-server-2013-in-recoverserver-mo
После того, как установка свалилась, не стартует удаление/установка Exchange.
Мне помогло удаление под веткой HKEY_LOCAL_MACHINESOFTWAREMicrosoftExchangeServerv15* всех значений Action и Watermark:
(3 оценок, среднее: 5,00 из 5)
Content freshness is a fairly key concept in the life of an Active Directory/DFS guru. Most of us have seen this in action with AD replication, for example. If two DC’s aren’t replicating then at
best the AD objects & attributes are out of sync and at
worst replication will shut down completely when the disconnect continues beyond the tombstone lifetime. Systematically determining which changes should be applied becomes impossible or even problematic (think: lingering objects in this example) the longer the timeline. The fundamental idea is that directory data needs to stay fresh. If it’s been too long since the data has been synchronized it’s best to just discontinue replication. The same is true for DFS.
Let’s say there are two servers in a Replication Group called Server1 and Server2. When a DFS Replication group falls out of sync, changes are still being made to the files on both servers. So how do we keep track of them? In the short run, those changes can be queued up in the Staging Area of both servers and will be replicated when the communications issue is past. But what if that outage is prolonged? You could have a document on Server 1 where the file is deleted, the deletion doesn’t replicate, and meanwhile on Server2 edits continue to be made to that file. What’s DFS gonna do if the members of the DFS Replication group actually do see one another again? Does this sound familiar? It’s like the DFS version of a lingering object! In other words, content freshness is a critical aspect of replication. If the content gets stale enough – like in this scenario – you actually don’t want it to replicate. In response Microsoft’s code sets replication thresholds and shuts it down for you. In so doing, they’ve saved us from ourselves. For an even deeper dive on this, and put much more eloquently than I ever could, here is a post from the official DS Team blog on the subject – http://blogs.technet.com/b/askds/archive/2009/11/18/implementing-content-freshness-protection-in-dfsr.aspx
Follow the Recovery Procedure in the aforementioned DS blog post.
The specifics are already in the link. However, at a high level this essentially boils down to:
Recreate the Replication Group. Best to consider this a second option to Solution1.
Hopefully this help fill in your understanding of content freshness and why in certain circumstances the Microsoft code is actually built to halt replication. Getting out of this jam isn’t perfect and often data can be lost. However this builds the perfect business case for why you need a tool to help you monitor DFSR.