FSMO Role duplication.

I have a client who has 3 sites, which until this spring were connected by a VPN, managed by their ISP.  This WAN had a single domain, and 3 WIn2000 AD DC's.  This summer sometime, the client decided to begin managing their own WAN, and broke the VPN.  However, it wasn't noticed until the start of the school year.  (It's a school system)

I was on-site there for the 1'st time on Fri, and made a mistake... since the other servers were unavailible do to the VPN, (the previous network manager is unavailable to explain anything) I siezed all the FSMO roles I could at a remote site, thinking they had an improperly performed upgrade.  (they had obsolete hardware that I thought was the other 2 servers, taken offline)

I can NOT seize the GC role...  This will be a big problem.

Repairing the VPN will be the 1'st step, but what kind of trouble can I expect when I get them back on the same WAN, with the duplication of FSMO's?  2 RID & Schema Masters?  If I remember right, I even went so far as to delete the machine account for the REAL Schema & RID Master... Is this going to take an Authoritative Restore to fix?
Who is Participating?
redseatechnologiesConnect With a Mentor Commented:
Yes, there must be a GC - but this is not an FSMO role, and is not "seized"


If you perform a system state backup of the one that was holding all the roles, and restore it to the same server, what are you expecting that will do?

You will need to format and reinstall it with a different name - join it to the domain, and start again

Here is what i would do since its early in the game. Do a system state restore as the dc was on thursday. Its going to create many many problems not only with your server but the other servers also if you bring that VPN up. You best solution would be to restore, it's early so now is the time to do it.
Hi hvymtl0u812,

Once you seize a role, you can not bring the old server back into the equation.  plimpias is correct, a restore is the way to go.

Also, there is no GC role to seize.


hvymtl0u812Author Commented:
I would have restored a sys-state backup already... only 1 prob... they weren't DOING backups.  None... nada.  EVER.

(This is why they needed my help in the 1'st place.)

Ok... so because of that, my thought is: perform a sys-state backup of the other machine... (the one that had been holding all the roles)  Then use AD Recovery Console and perform a non-authoratative restore.  (After bringing up the VPN).  Wouldn't that just tell the screwed up server to re-aquire all its AD info from another AD server?

And there must be a GC.  Global Catalogs are necessary to service logon requests... (and since I couldn't get that role to seize, the EVENT VIEWER will see alot of errors related to "a Global Catalog Server could not be contacted")
mikeleebrlaConnect With a Mentor Commented:
the GC isn't a ROLE at all!!!!!

making a DC a GC is just giving that DC a FULL copy of the AD database.  It is NOT a role and thus cannot be 'transfered' like the 5 FSMO roles.  Also, EVERY DC can be a GC if you would like it to be (and SHOULD be done for redundancy as you are finding out).  

also, you stated that a GC is needed for authentication which is only 1/2 true.  A GC is needed for authentication BY DEFAULT, but it can be changed if you wish.  Sorry, i just don't like seeing technically incorrect info on here since others will search the site later for reference.  
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.