Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm migrating servers from colo locations to Amazon's VPC EC2 instances. If anyone hasn't worked with Amazon VPC before, VPN is a pain in the arse!

Anyways, I setup a new server that acts as the domain controller for our Amazon VPC. In order to migrate all the user accounts from our existing domain controllers I manually connected to our colo VPN using my user account on the new Amazon EC2 machine.

I was able to join the domain and the new Amazon server became another domain controller on our network. So far so good.

The problem I'm having is that when booting the EC2 domain controller (which is no longer connected to the VPN so it can't communicate with the existing controllers), it takes a good 6-8 minuted before I can remote into the server (instead of the 1-2 minutes it should take). Also, during this time most of the services we also run (like IIS) also give 404 errors until the 6-8 minutes have passed.

It's almost like the domain controller is attempting to reach the other domain controllers first and after 6-8 minutes it falls back to the one located on the local machine? I don't think that's what's happening though, because Server 2008 R2 doesn't have primary and backup domain controllers. They're all equal as far as Windows is concerned.

For my network adapter I have only one DNS listed, 127.0.0.1, so it should be looking up the local domain controller and not the other domain controllers it connected to over VPN when VPN was enabled.

In the server logs I'm seeing these warnings pop up during a reboot:

The winlogon notification subscriber is taking long time to handle the notification event (CreateSession).

The winlogon notification subscriber took 409 second(s) to handle the notification event (CreateSession).

Any ideas on what's happening here? I would try removing the existing domain controllers from the new Amazon EC2 machine, but I still need to connect over VPN a few times to migrate some data between the servers, and I don't want that change being reflected back to the other domain controllers in our colo locations.

share|improve this question
    
I have seen similar behavior when rebooting the only DC on a remote site while the VPN is offline. Only mine was more like 20 minutes of sitting around rather than just 6-8. –  Mark Henderson Oct 18 '12 at 0:21
    
Just to add, when I try and remote onto the server before the 8 or so minutes are passed, I'm allowed to log in but I'm presented with this message: "Please wait for the Group Policy Client...". That message stays on the screen and then it eventually logs me in and takes me to the desktop after the 8 or so minutes have passed. –  Kris Anderson Oct 18 '12 at 0:33
    
Isn't this normal AD behavior? I'm no Windows/AD guru but I would think that the new DC is trying to replicate to the other DC, which probably still has the FISMO roles, etc. –  gravyface Oct 18 '12 at 0:37
add comment

1 Answer

Do you have AD Sites and Services set up for both sites and subnets and do you have the relevant DC's in each Site? The VPC server may use itself for DNS but it may be referred to another DC based on what SRV records are returned. That's what Sites and Services is intended for, to make sure that domain clients (of which the DC is a client of the domain) are referred to DC's in their own site. I can't say that I have any firsthand knowledge of whether or not a DC authenticates to itself in a multi DC domain but I would look at ADS&S and make sure it's configured correctly.

After the logon completes run "echo %logonserver%" from a command prompt on the VPC DC and see what DC authenticated it last.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.