Domain Controller Issue

michaelson99

Beta member
Messages
4
Location
Michigan, USA
Hello,

I manage a network for a medium size business (which I also own). The Windows 2008 R2 domain controller at the main office has one power supply and is currently offline until I get the replacement. People have been complaining about very long login times since the DC went offline, but everything is working as expected. DNS lookups are also obscenely slow.

It just occurred to me that there's another office with another domain controller/print/file server. There's a managed 1mbps/1mbps satellite link to connect the remote office to us. Is it possible that the other server is processing logins for main office users? It is a different "Site" in AD, but the same domain.

Is there a procedure to "sync up" the DCs once I get this one back online or can I just turn it back on and let it sync up on its own?
 
Last edited:
If your main DC is down, more than likely people are already authenticating to that satellite office - which is why you are seeing really slow load times. You can check this by running the set command from the command prompt of the authenticating user. Look for the logonserver in the list to see which DC you are authenticating to.

Once the main DC is back online, logins will be processed at the closest DC - in your case the one that has been down the entire time.

In the future, it would be good practice to either have a backup DC on site for situations like this, or at least a RODC to ensure that logins are processes locally instead of being pushes accross your slow WAN connection.
 
Last edited:
This main DC is a few days behind now. There have been a few password changes which would have been processed at the other office. I'm wondering what will happen when this DC comes back up and sees that it's behind.
 
Just occurred to me, which DC contains your FSMO roles? It may be a better idea to add the broken DC back online as a new DC. My concern with putting it back on as the original is there are a LOT of things that have changed over the time it was down - you are going to have a lot of discrepancies which will cause issues if put back on the network.

Best practice would be to demote the broken DC, remove the roles (if any were on in the first place) and put them on another DC. Once it's fixed bring it back online as a new DC.
 
The broken DC was the first DC on our network so it probably contains the FSMO roles. We just brought up the new one for the remote office when we brought them onto the domain. I'm thinking we might need to hire in some help; we've got a company we call when things are out of control like this.
 
If your main DC is down, more than likely people are already authenticating to that satellite office - which is why you are seeing really slow load times. You can check this by running the set command from the command prompt of the authenticating user. Look for the logonserver in the list to see which DC you are authenticating to.

Sorry to be OT but what is the syntax to this command?

Set - Environment Variable | Windows CMD | SS64.com
 
The broken DC was the first DC on our network so it probably contains the FSMO roles. We just brought up the new one for the remote office when we brought them onto the domain. I'm thinking we might need to hire in some help; we've got a company we call when things are out of control like this.

When your main site's DC comes back online the most recent changes should replicate from the other site's DC. It might be pretty slow to replicate because of the slow connection.
 
Set is the command, go to your cmd line and type "set" (remove the quotes).

If the server that was lost help the FSMO roles you REALLY need to promote another DC to fill those roles.
 
So, I fixed the domain controller and we made the decision to try turning on the DC since we had an image backup of the DCS. After about 30 minutes both DCs were authenticating users with their latest passwords.

Our IT company advised that we should look into more reliable server hardware and I have just approved a project with them to implement another 2012 R2 DC running on better hardware. The other DC will remain but will function as a secondary DC at our main office.

They agreed with your opinion that the operations master being offline is worthy of some caution. Since we had good backups we decided to turn on the server and see how it goes.
 
All good man - i'm glad it worked out for you. Since you had another DC running up on the site i would HOPE everything would authenticate and sync up - I just had to throw that in there that it may not work.

I would definitely have at least two DC's local for redundancy purposes. Hardware fails, no matter how new the equipment is. Have two DC ensures when one fails you are still up and running.

Good luck with your new project - let us know if you have questions.
 
Back
Top Bottom