Korisnici su se počeli žaliti da se prilikom pokušaja povezivanja s farmom RDS (Remote Desktop Server) temeljenom na Windows Server 2008 R2 pomoću standardnog RD klijenta (mstsc.exe) povremeno pojavljuje pogreška..
Veza se ne može dovršiti jer udaljeno računalo koje je dosegnuto nije ono koje ste naveli. To bi moglo biti uzrokovano zastarjelim unosom u DNS predmemoriju. Pokušajte umjesto IP adrese koristiti računalo.
Konfiguracija RDS farme: 3 poslužitelja koji pokreću Windows Server 2008 R2 s RD Connection Brokerom, a koriste se za raspodjelu opterećenja na terminale i mogućnost ponovnog povezivanja na sesije. Činjenica da je pogreška plutajuća odmah sugerira da postoji problem s jednim od farm poslužitelja. Uzastopnim pretraživanjem pronašli smo problemski poslužitelj i povezali se s radnom površinom putem IP adrese.
Za svaki slučaj, započeo sam ponovno registraciju zapisa na poslužitelju u DNS-u:
ipconfig / registerdns
A klijent je nakon nekoliko minuta spustio lokalnu DNS predmemoriju:
ipconfig / flushdns
Ali nije bilo učinka. Više nije bilo čudnosti s poslužiteljem, pa sam morao koristiti Googleove usluge. Pogreškom sam odmah prešao na članak u Microsoftovoj bazi znanja: https://support.microsoft.com/en-us/kb/2493594 (RDP veza s poslužiteljem udaljene radne površine na kojoj se izvodi Windows Server 2008 R2 možda neće uspjeti s porukom 'Lokalna sigurnosna uprava se ne može kontaktirati').
U rješenju predloženom u članku predloženo je pokušati sniziti razinu protokola koji se koristi za šifriranje RDP veza s SSL-om (TLS 1.0 se koristi za provjeru autentičnosti) na sigurnosni sloj RDP (ugrađena, manje sigurna RDP enkripcija).
primjedba. Ova se postavka nalazi pod Konfiguracija hosta udaljene radne površine -> Microsoft RDP 7.1 -> Svojstva -> Sigurnosni sloj
Ali naša konfiguracija već koristi pregovaračku metodu koja podrazumijeva automatsko prebacivanje s TLS-a na RDP sigurnosni sloj ako klijent ne podržava prvu metodu.
I ovdje slučajno otkrivam da vrijeme na problematičnom poslužitelju stoji iza vremena na kontroleru domene. U stvari, ispostavilo se da se taj poslužitelj (bio je virtualni) nalazio na ESXi host s pogrešnim vremenom, a mogućnost sinkronizacije vremena s hipervizatorom domaćina (Vremenska sinkronizacija između virtualnog stroja i ESX poslužitelja) omogućena je u postavkama VMWare Alatki.
Morao sam isključiti sinkronizaciju s ESXi-om i ponovno pokrenuti Windows vremensku uslugu tako da se vrijeme sinkroniziralo s DC-om.
net stop w32time
neto start w32time
Nakon toga, korisnici su se bez grešaka počeli povezivati na sve RDS poslužitelje na farmi..
