Hi All. To cut a very long-winded story short I have an SBS 2008 server with a secondary server 2008 for SQL which is also runnning as a backup DC. They are both virtualised on the same box. A few months ago I had to restore the SBS back to a week earlier by using a backed up copy of the VHD. Soon after the server displayed the following issues: - user login problems - inbound and outbound AD replication had become disabled - PCs couldn't authenticate to server - NETLOGON service paused on each boot After I re-enabled replication and started the netlogon service everything seems fine. The only thing I have to do is manually start the netlogon service whenever I reboot the server. AD now replicates fine with no errors, there are no 2095 or 2103 NTDS General errors in the Directory Services event log and as far as I can understand there is no discrepancy in the USN numbers that the DCs hold for each other (see pic below). The only issue I have is that the NETLOGON service is paused everytime I start the SBS box! Do I have USN rollback or not??!! Thanks :) dug.

sorry, that picture sucks:

Hi, > The only issue I have is that the NETLOGON service is paused everytime I start the SBS box! Do I have USN > rollback or not??!! Thanks :) Yes, you Domain have the issue USN rollback. Below sentence is quoted form MS KB 875495: Because a USN rollback is difficult to detect, a Windows Server domain controller that has the 875495 hotfix functionality installed logs event 2095 when a source domain controller sends a previously acknowledged USN number to a destination domain controller without a corresponding change in the invocation ID. And in general, if you recovery DC from snapshot, you DC will occur USN rollback issue. (I mean Windows 2008 R2 or previous DC, Windows Server 2012 RC has new feature which support recovery from snapshot) USN rollback is very harmful, because some time you cant even detect USN rollback issue, and it will cause unpredictable problems in the feature. Its not a short story to describe or understand USN rollback, refer to below articles to understand USN rollback and its affect: USN and USN Rollback http://technet.microsoft.com/en-us/library/d2cae85b-41ac-497f-8cd1-5fbaa6740ffe(v=ws.10)#usn_and_usn_rollback How the Active Directory Replication Model Works http://technet.microsoft.com/en-us/library/cc772726(v=WS.10).aspx A Guide to Active Directory Replication http://technet.microsoft.com/en-us/magazine/2007.10.replication.aspx We have two approaches to Restore the system state of a good backup: Remove the Domain Controller from the domainRestore the system state of a good backup. Refer to this article to implement that: How to detect and recover from a USN rollback in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 http://support.microsoft.com/kb/875495 Hope this helps! TechNet Subscriber Support If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here. Lawrence TechNet Community Support

Hello, "few months ago I had to restore the SBS back to a week earlier by using a backed up copy of the VHD." This is NOT supported way of backup as snapshots and clones/images and result in USN rollback, what you have now. How to solve is already added from Lawrence LV.Best regards Meinolf Weber MVP, MCP, MCTS Microsoft MVP - Directory Services My Blog: http://msmvps.com/blogs/mweber/ Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.

Hi again. Thanks for your responses. I was just a little confused, as I don't have any AD replication probs, and no errors in the event logs, and my USN values held by the two DCs seem correct. I don't personally think that microsoft's solution is very feasible, as the issue is on an SBS. Demoting and removing AD from an SBS server doesn't sound very sensible to me!! To be honest I don't need the SQL server to be a backup DC. I'm going to look into the prospect of demoting the SQL server back to just a member server, and then following the steps that I found in this article, which remove USN rollback issues on Standalone DCs simply by editing the registry. I know this obviously isn't supported either, but to me it seems the best option! ...I don't know whether you guys have any opinions on this, or any experience with this workaround? thanks agin, dug.

Hi, Because errors are not logged in the event log or in the replication engine, a USN rollback can be difficult to detect. One way to detect a USN rollback is to use the Windows Server version of Repadmin.exe to run the repadmin /showutdvec command. This version of Repadmin.exe displays the up-to-dateness vector USN for all domain controllers that replicate a common naming context. To detect a USN rollback, compare the output of the repadmin /showutdvec command on the domain controller with the output of the same command on the domain controller's replication partners. If the direct replication partners have a higher USN number for the domain controller than the domain controller has for itself, and the repadmin /showreps command does not report replication errors between direct replication partners, you have compelling evidence of a USN rollback. The following example shows the output of the repadmin /showutdvec command on DC1 and DC2 in the contoso.com domain. In this example, the command is run immediately following the rollback in step 5. C:\>Repadmin /showutdvec dc1 dc=contoso,dc=com Caching GUIDs... Site1\DC1 @ USN 10 @ Time 2004-08-04 15:07:15 Site2\DC2 @ USN 24805 @ Time 2004-08-04 15:06:59 C:\>Repadmin /showutdvec dc2 dc=contoso,dc=com Caching GUIDs... Site1\DC1 @ USN 50 @ Time 2004-08-04 15:07:15 Site2\DC2 @ USN 24805 @ Time 2004-08-04 15:06:59 The output from DC1 shows a local USN of 10. DC2 has inbound-replicated USN 50 and will ignore the Active Directory updates that correspond to the next 40 USN numbers from the originating DC1. Please try this method to check up-to-dateness vector USN for your two domain controllers, check whether it has USN rollback issue. I checked the solution you provided, thats not been test or confirmed by Microsoft, we dont recommend you try that solution. Hope this helps! TechNet Subscriber Support If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.Lawrence TechNet Community Support

Hi, Because errors are not logged in the event log or in the replication engine, a USN rollback can be difficult to detect. One way to detect a USN rollback is to use the Windows Server version of Repadmin.exe to run the repadmin /showutdvec command. This version of Repadmin.exe displays the up-to-dateness vector USN for all domain controllers that replicate a common naming context. To detect a USN rollback, compare the output of the repadmin /showutdvec command on the domain controller with the output of the same command on the domain controller's replication partners. If the direct replication partners have a higher USN number for the domain controller than the domain controller has for itself, and the repadmin /showreps command does not report replication errors between direct replication partners, you have compelling evidence of a USN rollback. The following example shows the output of the repadmin /showutdvec command on DC1 and DC2 in the contoso.com domain. In this example, the command is run immediately following the rollback in step 5. C:\>Repadmin /showutdvec dc1 dc=contoso,dc=com Caching GUIDs... Site1\DC1 @ USN 10 @ Time 2004-08-04 15:07:15 Site2\DC2 @ USN 24805 @ Time 2004-08-04 15:06:59 C:\>Repadmin /showutdvec dc2 dc=contoso,dc=com Caching GUIDs... Site1\DC1 @ USN 50 @ Time 2004-08-04 15:07:15 Site2\DC2 @ USN 24805 @ Time 2004-08-04 15:06:59 The output from DC1 shows a local USN of 10. DC2 has inbound-replicated USN 50 and will ignore the Active Directory updates that correspond to the next 40 USN numbers from the originating DC1. Please try this method to check up-to-dateness vector USN for your two domain controllers, check whether it has USN rollback issue. I checked the solution you provided, thats not been test or confirmed by Microsoft, we dont recommend you try that solution. Hope this helps! TechNet Subscriber Support If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.Lawrence TechNet Community Support

Hey Lawrence. Thanks again for your response. Regarding the checking of the up-to-dateness vector USN that you mentioned in your previous post; I have already posted these results (post #2). As you can see from my results the replication partner of the DC does not hold a higher USN number for the DC than the DC holds for itself (the SBS DC is TPSERVER1). This implies that I do not have USN rollback (if I understand the results correctly). This is what confused me, because apart from the NETLOGON service pausing, there is no evidence of USN rollback. thanks, dug.

Hi, According to screen capture you provided, we can find: The command shows your SBS server TPSERVER1 has local USN of 3787897, TPSERVER2 has inbound-replicated USN of 3787897. For TPSERVER1, its fine so far. But for TPSERVER2, command show SBS server TPSERVER1 has inbound-replicated USN 5997990, however TPSERVER2 itself has local USN of 5997996. TPSERVER2 has about 6 USN numbers higher thanTPSERVER1, in other words, TPSERVER1 dont know 6 USN update initiated from TPSERVER2. If you can accept 6 USN difference, you can keep these two DCs. To resolve these issue, shutdown TPSERVER2 and recovery TPSERVER1. Run metadata clean and recreate DC TPSERVER2 to replicate all data from TPSERVER1. For more information please refer to following MS articles: How to remove data in Active Directory after an unsuccessful domain controller demotion http://support.microsoft.com/kb/216498 metadata cleanup http://technet.microsoft.com/en-us/library/cc731035(v=WS.10).aspx Hope this helps! TechNet Subscriber Support If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.Lawrence TechNet Community Support

Hi, According to screen capture you provided, we can find: The command shows your SBS server TPSERVER1 has local USN of 3787897, TPSERVER2 has inbound-replicated USN of 3787897. For TPSERVER1, its fine so far. But for TPSERVER2, command show SBS server TPSERVER1 has inbound-replicated USN 5997990, however TPSERVER2 itself has local USN of 5997996. TPSERVER2 has about 6 USN numbers higher thanTPSERVER1, in other words, TPSERVER1 dont know 6 USN update initiated from TPSERVER2. If you can accept 6 USN difference, you can keep these two DCs. To resolve these issue, shutdown TPSERVER2 and recovery TPSERVER1. Run metadata clean and recreate DC TPSERVER2 to replicate all data from TPSERVER1. For more information please refer to following MS articles: How to remove data in Active Directory after an unsuccessful domain controller demotion http://support.microsoft.com/kb/216498 metadata cleanup http://technet.microsoft.com/en-us/library/cc731035(v=WS.10).aspx Hope this helps! TechNet Subscriber Support If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.Lawrence TechNet Community Support

Hi, I would like to confirm what is the current situation? Have you resolved the problem? If there is anything that we can do for you, please do not hesitate to let us know, and we will be happy to help. Lawrence TechNet Community Support

Hi, As this thread has been quiet for a while, we assume that the issue has been resolved. At this time, we will mark it as 'Answered' as the previous steps should be helpful for many similar scenarios. If the issue still persists and you want to return to this question, please reply this post directly so we will be notified to follow it up. You can also choose to unmark the answer as you wish. In addition, we'd love to hear your feedback about the solution. By sharing your experience you can help other community members facing similar problems. Thanks!Lawrence TechNet Community Support