Advancing time on production computers and the effect on Active Directory and FRS

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 members

If you advance the system time on a computer that is running, the following situations may occur:

1. 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.
2. 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.
3. 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 members

Advances of the system clock may not affect FRS Replica members if you advance the system time in the following way:

1. Stop NTFRS.
2. Set the time forward.
3. 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.
4. 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.
5. Restart NTFRS.

To determine if local change orders took place in the FRS replicated directories, you can "dump" the IDTABLE and/or the outbound log to verify whether files with "future" date and time stamps exist. The following example describes how to dump the outbound log of the FRS database and how to sort the output by event time by using the PERL script, Iologsum.cmd.

Run the following steps from a command prompt:

1. ntfrsutl outlog >outlog.txt
2. iologsum -sort=eventtime outlog.txt >event.txt
3. notepad event.txt

You can restart computers with "clean" outbound logs or IDtables as normal. For FRS replica members that contain files with future date stamps you need to use the following steps to reinitialize the database and replicated files by performing a non-authoritative restore:

1. Type net stop ntfrs at a command prompt.
2. Set the following registry key
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTFRS\Parameters\Backup/Restore\Process at startup\BURFLAGS
   to D2 (hex) or 210 (decimal).
3. Type net start ntfrs at the command prompt.

Remove any doubt of future inconsistencies between replica members by using the "non-authoritative restore."

Effect of advancing system time on Active Directory

Because 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.

Conclusion

You 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.

Microsoft recommends that you perform the testing of important time and date transitions in a lab environment with servers that you can rebuild as required. In addition, Microsoft recommends that you do not transition test environments, for which the time and dates have been advanced to the future or rolled back, to production environments.

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.