1

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 abc.net), 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.

6
  • 1
    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, 2012 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!
    – ufunks
    Apr 6, 2012 at 14:54
  • Sure. This should help: technet.microsoft.com/en-us/library/cc730868.aspx
    – joeqwerty
    Apr 6, 2012 at 15:03
  • Great, thanks Joe! I'll do some reading and see what I can do.
    – ufunks
    Apr 6, 2012 at 15:08
  • Glad to help...
    – joeqwerty
    Apr 6, 2012 at 15:10

3 Answers 3

2

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.

1

You could try the nltest utility http://technet.microsoft.com/en-us/library/cc731935(v=ws.10).aspx

I would try with the following switches :

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

/dsgetsitecov

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

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

0

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

1
  • 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, 2012 at 14:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .