Użytkownicy zaczęli narzekać, że podczas próby połączenia się z farmą RDS (Remote Desktop Server) opartą na systemie Windows Server 2008 R2 przy użyciu standardowego klienta RD (mstsc.exe), czasami pojawiał się błąd.
Nie można nawiązać połączenia, ponieważ osiągnięty komputer zdalny nie jest tym, który podałeś. Może to być spowodowane nieaktualnym wpisem w pamięci podręcznej DNS. Spróbuj użyć adresu IP komputera zamiast nazwy.
Konfiguracja farmy RDS: 3 serwery z systemem Windows Server 2008 R2 z usługą RD Connection Broker, używane do rozdzielenia obciążenia terminali i możliwości ponownego połączenia się z sesjami. Fakt, że błąd natychmiast się zmienia, sugeruje, że wystąpił problem z jednym z serwerów w farmie. W wyniku wyszukiwania sekwencyjnego znaleźliśmy problematyczny serwer i połączyliśmy go z komputerem za pomocą adresu IP.
Na wszelki wypadek zacząłem ponownie rejestrować rekord serwera w DNS:
ipconfig / registerdns
A na kliencie, po kilku minutach, upuścił lokalną pamięć podręczną DNS:
ipconfig / flushdns
Ale nie było efektu. Z serwerem nie było już więcej osobliwości, więc musiałem skorzystać z usług Google. Przez pomyłkę natychmiast przeszedłem do artykułu z bazy wiedzy Microsoft: https://support.microsoft.com/en-us/kb/2493594 (Połączenie RDP z serwerem pulpitu zdalnego z systemem Windows Server 2008 R2 może się nie powieść z komunikatem „Nie można się skontaktować z lokalnym organem bezpieczeństwa”).
W rozwiązaniu zaproponowanym w tym artykule zaproponowano próbę obniżenia poziomu protokołu używanego do szyfrowania połączeń RDP za pomocą SSL (TLS 1.0 służy do uwierzytelniania) do warstwy zabezpieczeń RDP (wbudowane, mniej bezpieczne szyfrowanie RDP).
Uwaga. To ustawienie znajduje się w obszarze Konfiguracja hosta sesji pulpitu zdalnego -> Microsoft RDP 7.1 -> Właściwości -> Warstwa zabezpieczeń
Ale nasza konfiguracja wykorzystała już metodę Negotiate, co oznacza automatyczne przełączanie z TLS na RDP Security Layer, jeśli klient nie obsługuje pierwszej metody.
I tutaj przypadkowo odkrywam, że czas na problematycznym serwerze jest opóźniony na kontrolerze domeny. I faktycznie okazało się, że ten serwer (był wirtualny) został umieszczony na hoście ESXi z niewłaściwym czasem, a opcja synchronizacji czasu z hiperwizorem hosta (synchronizacja czasu między maszyną wirtualną a serwerem ESX) została włączona w ustawieniach narzędzi VMWare.
Musiałem wyłączyć synchronizację z ESXi i ponownie uruchomić usługę czasu Windows, aby czas zsynchronizował się z DC.
stop netto w32time
start netto w32time
Następnie użytkownicy zaczęli bezbłędnie łączyć się ze wszystkimi serwerami RDS w farmie..
