Are you using Amazon EC2 and can’t figure out why your Domain Controller with the FSMO roles logs the Event ID 2092 (This server is the owner of the following FSMO role, but does not consider it valid)? This article may explain why.
I use Amazon EC2 as a test lab and during some FSMO role transfer testing I came across a strange situation. I had duplicated my production environment with 8 Domain Controllers, however only one of the Domain Controllers is usually turned on as it’s a test lab. The Domain Controller that is on all of the time was the FSMO role holder for all roles. For the test I brought up the 7 other Domain Controllers, waited for everything to sync up correctly (approx 1 hr) and then proceeded with the FSMO role transfer. transferring the FSMO roles went exactly as expected, no problems at all. What was strange was approximately 15 mins after the FSMO transfers to the other Domain Controller I saw messages in the event logs for event ID 2092 saying that the server didn’t consider itself valid as it hadn’t replicated successfully with any of its partners since it was restarted. I had to seize the FSMO roles to another Domain Controller to resolve the problem, but could easily recreate the problem exactly the same way (transferring the FSMO roles from a Domain Controller that was always on to a Domain Controller that had recently been booted).
I eventually was able to isolate the problem to something that is probably relatively unique to Amazon EC2. When I booted up the 7 Domain Controllers that are not permanently on in my test lab, their time is off by more than 5 mins and thus they fail replicating with any partners (due to the Kerboros requirement for time to be within 5 mins of each other) until they sync their time. That failing of the initial replication attempt is why the Domain Controller that I transferred the FSMO roles to logs an event ID 2092 and doesn’t consider itself a valid FSMO role holder.
The reason that the time is off by more than 5 mins on the 7 Domain Controllers when they boot is because the time zone I set all the Domain Controllers to is Central Time. When an Amazon EC2 Server boots its Server time is UTC, and thus different from Central time by 6 hours. So this causes the initial replication with other domain controllers to fail until their time syncs.
There are probably some boot parameters that can be applied to Amazon EC2 Servers regarding Server time but I didn’t have time to research it, so I just set the timezone on all of my Domain Controllers to UTC and this works around the problem as by default Amazon EC2 Servers boot sync’d to UTC, so they don’t fail their initial replication attempt.