- Remove From My Forums
-
Question
-
Looking up the Error: 9098 (A tombstoned content set deletion has been scheduled)
Most of the fixes are to go into SysVol and Delete the DFSR Database.
Though I’m not ready to do that as its not Specific to the replica folder that is having the issue. I have three Replica Groups on the server and one works perfectly, one has 1/2 its folders in some funny state and the other 1/2 are fine. So wiping
out the Database on Replica sets and folders that are working seems odd thing to do.Is there no way to repair the DB for the folders that are not cooperating? I’ve tries removing them and then readding them (Same Name as the name is used for Namespace too) and that didn’t help.
Thanks,
Answers
-
Hi Scooter_,
Thanks for your reply.
According to your scenairo involve large data. You might consider to use following step to remove the data on the non replicating server and rename the folder to have a try.
- Backup Data
- Delete the replication group
- Force AD replication
- dfsrdiag pollad
- Confirm in the DFS Replication Events that there is an event 4010 stating that the replication folder has been removed.
- Rename the replicated folder in Explorer to something else
- Create a new folder which will be the new replication folder
- re enable replication between servers ensuring the correct server is set to Primary
- dfsrdiag pollad
- Monitor logs and resource monitor disk activity on the source and destination servers to confirm replication is occurring
Please refer to the article below.
http://www.falconitservices.com/support/KB/Lists/Posts/Post.aspx?ID=195
Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.
If it still doesn’t work, I’m afraid that you might need to consider to reset database.
Best Regards,
Mary Dong
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.
-
Proposed as answer by
Friday, March 4, 2016 8:24 AM
-
Marked as answer by
Mary Dong
Monday, March 7, 2016 7:54 AM
- Remove From My Forums
-
Question
-
Looking up the Error: 9098 (A tombstoned content set deletion has been scheduled)
Most of the fixes are to go into SysVol and Delete the DFSR Database.
Though I’m not ready to do that as its not Specific to the replica folder that is having the issue. I have three Replica Groups on the server and one works perfectly, one has 1/2 its folders in some funny state and the other 1/2 are fine. So wiping
out the Database on Replica sets and folders that are working seems odd thing to do.Is there no way to repair the DB for the folders that are not cooperating? I’ve tries removing them and then readding them (Same Name as the name is used for Namespace too) and that didn’t help.
Thanks,
Answers
-
Hi Scooter_,
Thanks for your reply.
According to your scenairo involve large data. You might consider to use following step to remove the data on the non replicating server and rename the folder to have a try.
- Backup Data
- Delete the replication group
- Force AD replication
- dfsrdiag pollad
- Confirm in the DFS Replication Events that there is an event 4010 stating that the replication folder has been removed.
- Rename the replicated folder in Explorer to something else
- Create a new folder which will be the new replication folder
- re enable replication between servers ensuring the correct server is set to Primary
- dfsrdiag pollad
- Monitor logs and resource monitor disk activity on the source and destination servers to confirm replication is occurring
Please refer to the article below.
http://www.falconitservices.com/support/KB/Lists/Posts/Post.aspx?ID=195
Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.
If it still doesn’t work, I’m afraid that you might need to consider to reset database.
Best Regards,
Mary Dong
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.
-
Proposed as answer by
Friday, March 4, 2016 8:24 AM
-
Marked as answer by
Mary Dong
Monday, March 7, 2016 7:54 AM
Почему не проходит репликация dfs в windows server?
Есть два сервера SRV1 и SRV2
SRV1 физический сервер с Windows 2008 r2
SRV2 виртуальная машина(VMWARE esx 5.5) c Windows 2012 r2
На SRV1 поднята роль DFS и между серверами настроена реплика. С SRV1 идет в одну сторону реплика на SRV2
Собственно сама проблема. Репликация на проходит. Точнее она проходила какое-то время, сейчас не идет. При запуске диагностического отчета все ОК.
- Вопрос задан более трёх лет назад
- 3109 просмотров
alexq2: Исходя из этих строк лога:
20160317 08:45:32.521 8940 CFAD 8716 Config::AdConfig::GetComputer [CLUSTER] This computer is a cluster node. Get list of owned VCOs.
20160317 08:45:32.521 8940 CLUS 4280 Cluster::ClusterUtil::GetVcoList [CLUSTER] Searching for locally owned VCOs
20160317 08:45:32.521 8940 CFAD 8779 Config::AdConfig::GetComputer [CLUSTER] Cluster service is not installed or configured. Skipping the VCO polling.
20160317 08:45:32.521 8940 ADWR 1293 Config::AdWriter::CreateSysVolObjects [SYSVOL] IsDc:1 isSysVolCreated:0
У вас есть недоделанный кластер сервер DC3 у вас состоит в этом кластере?
И ещё вопрос у вас реплика AD между DC1 и DC3 проходит?
Ещё как радикальный вариант можете удалить полностью DFS с DC3 перегрузить и заново установить DFS и настроить реплику.
Поддержка транзакций в указанном диспетчере ресурсов не запущена
Пользователи жаловались на невозможность добавлять, редактировать или удалять запланированные задачи в Windows 10. Каждый раз, когда они пытаются выполнить любое из этих действий, они получают следующее сообщение об ошибке:
Поддержка транзакций в указанном диспетчере ресурсов не запущена или была отключена из-за ошибки.
Приведенное выше сообщение об ошибке связано с Центром обновления Windows, так как вы также можете не установить обновления. К счастью, решить эту проблему несложно, и в этом руководстве мы покажем вам, как это сделать.
Поддержка транзакций в указанном диспетчере ресурсов не запущена
Аномалия, когда вы испытываете указанную выше ошибку, заключается в том, что она говорит, что работает в службах диспетчера задач, несмотря на то, что планировщик задач не открывается. Мы исправим эту проблему, используя следующие решения:
- Очистите все содержимое каталога TxR.
- Сбросьте диспетчер транзакционных ресурсов с помощью fsutil.
- Замените жесткий диск.
Продолжайте читать это руководство, чтобы получить полную информацию о вышеуказанных исправлениях.
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
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)
Загрузка.
источники:
http://zanz.ru/podderzhka-tranzakczij-v-ukazannom-dispetchere-resursov-ne-zapushhena/
http://bgelov.ru/microsoft-exchange/udalenie-nepravilno-vyvedennogo-iz-stroya-servera-exchange/
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
So what do we do if we find ourselves in this predicament???? That’s probably the reason you’re here at our blog. You’ve likely seen an event 4004 in the DFSR log that shows an error 9098 and makes the statement “A tombstoned content set deletion has been scheduled.” Content freshness is the reason this has occurred. AFTER fixing the root cause of the blockage (firewalls, DFSR in dirty shutdown, etc.) here are some options on how to get things back up and running:
Solution1: 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:
- Get a backup
- Disabling the affected member in the RG
- Force AD replication
- Enable DFS Replication again on the member.
- Force AD replication.
- The node will then go through initial sync again where it catalogs the files in the jet, so you’ll need to wait for that to complete before letting users back in.
As further evidence that this is a good course to follow, if you happen to see a 4012 in the DFSR log it suggests the very same. Picture below.
Solution2: Recreate the Replication Group. Best to consider this a second option to Solution1.
- Get a backup of the Replicated Folder on both/all nodes.
- In the DFS Console, delete the Replication Group
- Force AD Replication.
- From an elevated command prompt run DFSRDiag pollad on each of the former Replication Group members.
-
On each (former)member of the RG, delete the hidden DFSRPrivate folder.
- This holds the Staging and ConflictAndDeleted folders. You may want/need to restore some of this from backup after all is said and done if the authoritative server’s copy of the file isn’t actually the one you want.
- Where is this???? It’s in the Replicated folder. If the Replicated Folder is e:homes, then from a command prompt you can see it from e:homesdfsrprivate. You’ll need to unhide system files in order to see it in Windows Explorer.
- Recreate the Replication Group in the DFSR Console.
- DFSRDIAG pollad from each RG member, so it picks up the new configuration from Active Directory.
- This will kick off an initial sync on the Replication Group, which is going to take some time. You won’t want to let the users back in until this is complete. Keeping checking the DFSR log for a 4104 which indicates this is finished.
- As the event suggests, check the PreExisting & ConflictAndDeleted folders for any fallout and don’t be afraid to check the backups for a more relevant version of files from the old Staging folders.
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.