Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We're having RDP issues with Amazon cloud servers that we recently joined to an Active Directory domain. The setup is:

  • A local office network
  • A virtual private cloud in Amazon
  • An IPSec tunnel between the two networks
  • A number of Windows 2008 R2 servers on both networks
  • An AD domain (call it, with one domain controller in each network.

The domain controllers are both new, fresh installs. Before we had the domain set up we had local accounts for the cloud computers which were used for RDP access. Our idea was to get all of the servers on to the domain so we could use domain logins instead of per-server local logins.

Before the cloud servers were in the domain, RDP (from the office network or through a VPN to the cloud) worked great. After we joined the cloud servers to the domain, RDP from the office became very slow - a few minutes to log in, long frequent pauses when the interface is unresponsive, generally just a slow and frustrating experience. This is a problem regardless of whether a domain or local login is used for RDP.

Oddly, when outside of the office network and connecting to the cloud directly with the VPN, RDP is still very responsive.

Any idea why RDP from office to cloud is suddenly very slow after the cloud servers join the domain? What can I look at in our configuration to address this? Any help is greatly appreciated.

share|improve this question
The long logon time sounds like it might be a problem with the TS/RDS server authenticating against the DC in the local office instead of against the DC in the cloud. Do you have your sites and subnets set up in ADS&S? – joeqwerty Apr 6 '12 at 14:35
Sounds plausible, I'll check out the sites and subnets. I suspect they are not set up optimally (for the record, I'm absolutely the wrong person to be doing this, but it's fallen to me so I'm learning as I go). Do you have any links to how I should be going about this? Thanks! – Chris Grove Apr 6 '12 at 14:54
Sure. This should help: – joeqwerty Apr 6 '12 at 15:03
Great, thanks Joe! I'll do some reading and see what I can do. – Chris Grove Apr 6 '12 at 15:08
Glad to help... – joeqwerty Apr 6 '12 at 15:10

Joeqwerty gave the tips that led to a solution in a comment, so I'll repeat the solution here.

Setting up the sites and subnets correctly resolved the problem. If anyone else is looking at a similar setup, we configured this to have two AD sites, each with a relevant subnet (one for the local office, one for the cloud). One domain controller is assigned to each site, and replication is configured through a site link containing both sites.

Thanks again to joeqwerty for the help.

share|improve this answer

You could try the nltest utility

I would try with the following switches :

/dsgetdc (and note where the GCs for the site/domain are)


/whowill is also an option to see where a given user account is.

This may give you enough clues to figure out why...

share|improve this answer

This is a MTU size problem definitevely. Because of IPSEC tunnel you should reduce NIC MTU to avoid packet fragmentation from default to 1400. Use netsh command to show your actual MTU:

netsh interface ipv4 show interfaces

Take note of your NIC ID (first column, example Idx = 10) and then change MTU:

netsh interface ipv4 set subinterface "10" mtu=1400 store=persistent

share|improve this answer
That can be a good avenue to investigate, but in this case we know that's not the cause. "Before the cloud servers were in the domain, RDP (from the office network or through a VPN to the cloud) worked great." – mfinni Apr 9 '12 at 14:23

Your Answer


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.