Advancing time on production computers and the effect on Active Directory and FRS
This article was previously published under Q289668
This article has been archived. It is offered "as is" and will no longer be updated.
In the course of troubleshooting Active Directory or File Replication Service (FRS) replication issues, as the administrator, you may want to advance the system time of a computer to make the content of one computer have authority over another, or to force deletion of tombstoned objects in Active Directory.
The effect of advancing the system clock on FRS replica membersIf you advance the system time on a computer that is running, the following situations may occur:
- Tombstones for deleted files in the IDTable are prematurely deleted, which causes incorrect reconciliation decisions later. If the deleted tombstone is gone, then a concurrent update, which arrives at this member, produces a different reconciliation result from other members. The end result is that the files and folders in the affected DFS or SYSVOL replica sets are inconsistent between members. FRS data reconciliation between two partners that were not subjected to the time advance occurs as expected. Data replication between a member that was time-advanced and a non-advanced member will not work as expected, if at all.
- The computer with the advanced clock does not join with partners that remain at the correct time. The join protocol, which is used by DFS or SYSVOL replica members to exchange data, ensures that the time clock on the two partners is within a certain tolerance.
- Local file changes create change orders with event times while using the advanced clock time. These change orders are inserted into the outbound log but are not sent because of the reason that is outlined in step 2. When you restore the time on this computer to normal time, the computer joins with its outbound partners. Change orders, with the advanced time, are sent to downstream partners and the downstream partners ignore these change orders because the event time is invalid (it is too far in the future).
As a result, files that you changed while the time was advanced are not replicated to the other members (but they do remain on the changed computer). In addition, because of the invalid (advanced) event times in the IDTable entry, this member rejects updates to these files that originate from other members.
How to determine if a time advance will affect FRS replica membersAdvances of the system clock may not affect FRS Replica members if you advance the system time in the following way:
- Stop NTFRS.
- Set the time forward.
- Do not make any new additions or changes to the existing DFS or SYSVOL replica trees while the NTFRS is stopped because any additions or changes result in local change orders.
- Set the time back to the current time. By definition, this time is to be ahead of the time that the service was last shut down as FRS compares the startup time to last shutdown time.
- Restart NTFRS.
Run the following steps from a command prompt:
- ntfrsutl outlog >outlog.txt
- iologsum -sort=eventtime outlog.txt >event.txt
- notepad event.txt
- Type net stop ntfrs at a command prompt.
- Set the following registry keyHKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTFRS\Parameters\Backup/Restore\Process at startup\BURFLAGSto D2 (hex) or 210 (decimal).
- Type net start ntfrs at the command prompt.
Effect of advancing system time on Active DirectoryBecause Windows 2000 Active Directory reconciles by version number first, and then by timestamp as a tie breaker, Active Directory may be less sensitive to radical clock changes. Time sensitive operations in Active Directory include:
- Tie-breaking replication conflicts - When you change the same attribute on the same object on two different servers during a latency period, the tie goes to the most recent change. Therefore, changes that originate in the future win.
- In the case of two different objects that you created with the same name on two servers, the resolution of the name conflict is resolved in favor of the RDN with the most recent change time.
- Backups are only good for a tombstone lifetime. When you create a backup, an "expiry token" is generated. The token must be submitted at restore time, and it is used to verify that the backup is not too old. When you attempt a restore at a future time, this may not work if the backup seems too old. Even if you are able to do this, restoring a backup that you created in the "future" to the past, Microsoft does not recommend this.
- Kerberos authentication is based on clock synchronization. Kerberos ticket lifetimes may be exceeded if the clock is set too far ahead.
ConclusionYou should never advance the system time on production Windows 2000 domain controllers beyond the current UTC time, or to some future time and then roll the clock back. This includes, but is not limited to, attempts to:
- Test significant time and date transitions (such as Year 2000 testing).
- Force the deletion of tombstoned objects in conjunction with the TombStoneLifetime setting.
- Make objects on one computer take precedence over the objects on another computer by using the advancement and/or rollback of time.
- Extend the useful life of a system backup.
- Return a computer to an earlier "system state" including schema rollback.
Advancing or rolling back the system time is not a productive method by which to resolve Active Directory or FRS replication problems. The purposeful alteration of system time adds additional complexity to often difficult troubleshooting scenarios. Microsoft does not support Windows domain controller scenarios in which you are using this method of problem resolution.
Article ID: 289668 - Last Review: 12/06/2015 00:38:46 - Revision: 2.5
Microsoft Windows Server 2003, Standard Edition (32-bit x86), Microsoft Windows Server 2003, Enterprise Edition (32-bit x86), Microsoft Windows 2000 Advanced Server, Microsoft Windows 2000 Datacenter Server, Microsoft Windows 2000 Server
- kbnosurvey kbarchive kbinfo kbnetwork KB289668