У нас возникают проблемы с RDP с облачными серверами Amazon, которые мы недавно присоединили к домену Active Directory. Настройка такова:
Контроллеры домена являются новыми, свежими установками. До того, как мы настроили домен, у нас были локальные учетные записи для облачных компьютеров, которые использовались для доступа RDP. Наша идея заключалась в том, чтобы подключить все серверы к домену, чтобы мы могли использовать доменные учетные записи вместо локальных учетных записей для каждого сервера.
До того, как облачные серверы были в домене, RDP (из офисной сети или через VPN в облако) отлично работал. После того, как мы присоединили облачные серверы к домену, RDP из офиса стал очень медленным - несколько минут для входа в систему, длительные частые паузы, когда интерфейс не отвечает, обычно просто медленный и разочаровывающий опыт. Это проблема независимо от того, используется ли для RDP доменный или локальный вход.
Как ни странно, когда вы находитесь за пределами офисной сети и подключаетесь к облаку напрямую через VPN, RDP по-прежнему очень отзывчивый.
Есть идеи, почему RDP из офиса в облако внезапно становится очень медленным после того, как облачные серверы присоединяются к домену? На что я могу посмотреть в нашей конфигурации, чтобы решить эту проблему? Любая помощь приветствуется.
Joeqwerty дал советы, которые привели к решению, в комментарии, поэтому я повторю решение здесь.
Настройка сайтов и подсетей правильно решила проблему. Если кто-то еще смотрит на подобную установку, мы настроили ее так, чтобы иметь два сайта AD, каждый с соответствующей подсетью (один для локального офиса, один для облака). Каждому сайту назначается один контроллер домена, а репликация настраивается через связь сайтов, содержащую оба сайта.
Еще раз спасибо joeqwerty за помощь.
Вы можете попробовать утилиту nltest http://technet.microsoft.com/en-us/library/cc731935(v=ws.10).aspx
Я бы попробовал со следующими переключателями:
/ dsgetdc (и обратите внимание, где находятся GC для сайта / домена)
/ dsgetsitecov
/ whowill также позволяет узнать, где находится данная учетная запись пользователя.
Это может дать вам достаточно подсказок, чтобы понять, почему ...
Это определенно проблема размера MTU. Из-за туннеля IPSEC вам следует уменьшить MTU сетевого адаптера, чтобы избежать фрагментации пакетов со значения по умолчанию до 1400. Используйте команду netsh, чтобы показать ваш фактический MTU:
netsh interface ipv4 show interfaces
Запишите свой NIC ID (первый столбец, например, Idx = 10), а затем измените MTU:
netsh interface ipv4 set subinterface "10" mtu=1400 store=persistent