A felhasználók panaszkodni kezdtek, amikor megpróbáltak egy Windows Server 2008 R2 alapú RDS farmhoz (Remote Desktop Server) kapcsolódni a szokásos RD kliens (mstsc.exe) használatával, alkalmanként hiba jelentkezett..
A kapcsolat nem fejeződik be, mert az elért távoli számítógép nem az, amelyet Ön megadott. Ezt egy elavult bejegyzés okozhatja a DNS-gyorsítótárban. Próbáljon a név helyett a számítógép IP-címét használni.
RDS farmkonfiguráció: 3 kiszolgáló, amely Windows Server 2008 R2-t és RD Connection Brokert futtat, kiszolgálja a terminálok terhelésének és a szekciókhoz való újracsatlakozás képességének elosztására. Az a tény, hogy a hiba lebeg, azonnal arra utal, hogy probléma van az egyik farmkiszolgálóval. Szekvenciális keresés segítségével megtaláltuk a problémás szervert, és IP-címmel csatlakoztattuk az asztalhoz.
Mindenesetre elkezdtem újra regisztrálni a szerverrekordot a DNS-ben:
ipconfig / registerdns
És néhány perc elteltével az ügyfél eldobta a helyi DNS-gyorsítótárat:
ipconfig / flushdns
De nem volt hatás. Nincs több furcsaság a szerverrel, tehát a Google szolgáltatásait kellett használnom. Véletlenül azonnal eljutottam egy cikkhez a Microsoft tudásbázisában: https://support.microsoft.com/en-us/kb/2493594 (Előfordulhat, hogy az RDP-kapcsolat a Windows Server 2008 R2 rendszert futtató távoli asztali kiszolgálóval "A helyi biztonsági hatósággal nem lehet kapcsolatba lépni" üzenettel meghiúsulhat.).
A cikkben javasolt megoldásban azt javasolták, hogy próbálják csökkenteni az RDP kapcsolatok SSL-rel való titkosításához használt protokoll szintjét (a TLS 1.0-t használják a hitelesítéshez) az RDP biztonsági réteghez (beépített, kevésbé biztonságos RDP-titkosítás)..
megjegyzés. Ez a beállítás a Távoli asztal munkamenet-konfigurációja -> Microsoft RDP 7.1 -> Tulajdonságok -> Biztonsági réteg alatt található.
De a konfigurációnk már a Negotiate módszert is alkalmazta, amely magában foglalja az automatikus váltást a TLS-ről az RDP biztonsági rétegre, ha az ügyfél nem támogatja az első módszert.
És itt véletlenül rájöttem, hogy a problémakiszolgálón eltelt idő lecsökkent a tartományvezérlőn. Valójában kiderült, hogy ez a szerver (virtuális volt) rosszul az ESXi gazdagépen található, és a VMWare Tools beállításaiban engedélyezve volt az idő szinkronizálásának lehetősége a gazdagép hipervizorával (A virtuális gép és az ESX szerver közötti időszinkronizálás)..
Kikapcsolnom kellett az ESXi-vel való szinkronizálást, és újra kell indítanom a Windows időszolgáltatást, hogy az idő szinkronizálva legyen a DC-vel.
net stop w32time
nettó indulás w32 időben
Ezt követően a felhasználók hiba nélkül csatlakoztak a gazdaság összes RDS szerveréhez..
