Потребителите започнаха да се оплакват, че когато се опитват да се свържат с ферма RDS (Remote Desktop Server), базирана на Windows Server 2008 R2, използвайки стандартния RD клиент (mstsc.exe), от време на време се появява грешка.
Връзката не може да бъде завършена, тъй като отдалеченият компютър, който е достигнат, не е този, който сте посочили. Това може да бъде причинено от остарял запис в кеша на DNS. Опитайте да използвате IP адреса на компютъра вместо името.
Конфигурация на фермата на RDS: 3 сървъра, работещи с Windows Server 2008 R2 с RD Connection Broker, използвани за разпределяне на натоварването на терминалите и възможност за повторно свързване към сесии. Фактът, че грешката плава, веднага подсказва, че има проблем с един от фермерските сървъри. Чрез последователно търсене намерихме проблемния сървър и се свързахме към работния плот по IP адрес.
За всеки случай започнах да регистрирам отново записа на сървъра в DNS:
ipconfig / registerdns
И на клиента след няколко минути изпусна локалния кеш на DNS:
ipconfig / flushdns
Но ефект нямаше. Нямаше повече странности със сървъра, така че трябваше да използвам услугите на Google. По грешка веднага отидох в статия в базата знания на Microsoft: https://support.microsoft.com/en-us/kb/2493594 (RDP връзката към сървъра за отдалечен работен плот, работещ под Windows Server 2008 R2, може да се провали със съобщение „Местният орган за сигурност не може да бъде свързан“).
В решението, предложено в статията, беше предложено да се опита да понижи нивото на протокола, използван за криптиране на RDP връзки с SSL (TLS 1.0 се използва за удостоверяване) на RDP слой за сигурност (вградено, по-малко защитено RDP криптиране).
забележка. Тази настройка се намира под Конфигурация на хоста на отдалечен работен плот -> Microsoft RDP 7.1 -> Свойства -> Защитен слой
Но нашата конфигурация вече използва метода Negotiate, който предполага автоматично преминаване от TLS към RDP слой за сигурност, ако клиентът не поддържа първия метод.
И тук случайно откривам, че времето на проблемния сървър е зад времето на контролера на домейна. И всъщност се оказа, че този сървър (той беше виртуален) се намира на хоста на ESXi с грешно време и опцията за синхронизиране на времето с хост хипервизора (Синхронизация на времето между виртуалната машина и ESX сървъра) е активирана в настройките на VMWare Tools.
Трябваше да изключа синхронизацията с ESXi и да рестартирам времевата услуга на Windows, така че времето да се синхронизира с DC.
нетно спиране w32time
нетен старт w32time
След това потребителите започнаха да се свързват към всички RDS сървъри във фермата без грешки..
