Не работает rdp windows server 2008 r2

Обновлено: 08.07.2024

Из Ваших объяснений, Вы пробуете, находясь в локсети за TPLink войти на сервер не под его локадресом, а под интернет адресом(внешним адресом) TPlink?

Заход через интернет по перенаправлению на порт 3389 ведь действует только для внешних к Вашей локсети компьютеров, но не для внутренних в локсети. Внутренние должны заходить на сервер в терминальный сеанс по внутреннему ip-адресу сервера.
Потом п.5 где Вы ставили (покажите скрин), может это избыточно.

В локсети все нужные пользователи заходят по лок адресу сервера в терминал без проблем?

(4) В локсети все нужные пользователи заходят по лок адресу сервера в терминал
Все верно

Из Ваших объяснений, Вы пробуете, находясь в локсети за TPLink войти на сервер не под его локадресом, а под интернет адресом(внешним адресом) TPlink?

Находясь в локальной сети можно подключиться по iP-адресу который указан в роутере в меню статус, в пункте WAN

Находясь в локальной сети можно подключиться по iP-адресу который указан в роутере в меню статус, в пункте WAN

Нет, в TPLink нельзя. Только извне с внешним IP адресом на Вашем компьютере.
Изнутри локсети подключайтесь по внутренним/ему IP адресам/у сервера.
И зачем, кстати, Вам подключаться по внешнему адресу? Для проверки перенаправления TPLink на ваш сервер? Если так, то проверяйте из дома.

стоит сменить роутер, то выдается ошибка подключения стандартная (не включен удаленный доступ к серверу/удаленный компьютер не включен) Вопрос 1: а зачем менять сервер? Вопрос 2: на другом сервере порт 3389 проброшен?

Это - не проблема, а затруднение. Проблема начнется, когда ваш сервер взломают и зашифруют (или удалят) данные на нем.

Какое решение тогда нужно использовать?

Вопрос 1: а зачем менять сервер? Вопрос 2: на другом сервере порт 3389 проброшен?
нет, не менял сервер, неправильно выразился, имелось ввиду сменить подключение на клиенте. Изначально сервер и клиент подключены к одному роутеру, в этом случае все происходит нормально, но если сервер оставить на этом же роутере, а клиент подключить к другому, то не происходит подключение к удаленному рабочему столу. как я писал уже что если сервер и клиент подключены к одному роутеру то по адресу, указанному в WAN происходит подключение по RDP, а если клиент подключается к другому роутеру, то нет

Может в каком-нибудь более серьезном cisco это сработает, я пробовал, но не всегда и так не делают. Изнутри подключаются по внутренним адресам к серверу.

Потому что открывать доступ к серверу из Интернета через стандартный RDP настоятельно не рекомендуется

Не рекомендуется, но открывают и подолгу годами работают. Можно сменить порт 3389 на какой-нибудь нестандартный. Лучше, конечно, настроить роутер с vpn. Есть, например, надежные недорогие (около 30 тыс) cisco, которые ставят на банкоматы.

Ответы

2. slmgr.vbs -ckms

4. slmgr.vbs -ipk <лицензионный ключ>

6. Перезагрузка сервера

Все ответы

Событий 1035/1036 нет. Порт в реестре прописан правильно: 3389. Результат выполнения QWINSTA:

C:\Users\. >qwinsta
SESSIONNAME USERNAME ID STATE TYPE DEVICE
services 0 Disc
>console . 4 Active

C:\Users\. >qwinsta /mode
SESSIONNAME STATE DEVICE TYPE BAUD PARITY DATA STOP
services Disc none 1
>console Active none 1

C:\Users\. >qwinsta /flow
SESSIONNAME STATE DEVICE TYPE FLOW CONTROL
services Disc
>console Active

C:\Users\. >qwinsta /counter
SESSIONNAME USERNAME ID STATE TYPE DEVICE
services 0 Disc
>console . 4 Active
Total sessions created: 5
Total sessions disconnected: 3
Total sessions reconnected: 0

Была аналогичная ситуация с MS Windows 2008

If you wake up in a different time, in a different place, could you wake up as a different person?

C:\Users\. >netstat -aon

Proto Local Address Foreign Address State PID
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 688
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:475 0.0.0.0:0 LISTENING 207712
TCP 0.0.0.0:1540 0.0.0.0:0 LISTENING 207408
TCP 0.0.0.0:1541 0.0.0.0:0 LISTENING 160192
TCP 0.0.0.0:1560 0.0.0.0:0 LISTENING 160192
TCP 0.0.0.0:1561 0.0.0.0:0 LISTENING 207408
TCP 0.0.0.0:1562 0.0.0.0:0 LISTENING 206340
TCP 0.0.0.0:1563 0.0.0.0:0 LISTENING 206340
TCP 0.0.0.0:1564 0.0.0.0:0 LISTENING 207464
TCP 0.0.0.0:1565 0.0.0.0:0 LISTENING 207464
TCP 0.0.0.0:1566 0.0.0.0:0 LISTENING 207264
TCP 0.0.0.0:1567 0.0.0.0:0 LISTENING 207264
TCP 0.0.0.0:2301 0.0.0.0:0 LISTENING 2348
TCP 0.0.0.0:2381 0.0.0.0:0 LISTENING 2348
TCP 0.0.0.0:5633 0.0.0.0:0 LISTENING 4240
TCP 0.0.0.0:6101 0.0.0.0:0 LISTENING 5148
TCP 0.0.0.0:6106 0.0.0.0:0 LISTENING 4256
TCP 0.0.0.0:10000 0.0.0.0:0 LISTENING 2356
TCP 0.0.0.0:22350 0.0.0.0:0 LISTENING 1228
TCP 0.0.0.0:47001 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:49152 0.0.0.0:0 LISTENING 408
TCP 0.0.0.0:49153 0.0.0.0:0 LISTENING 788
TCP 0.0.0.0:49162 0.0.0.0:0 LISTENING 836
TCP 0.0.0.0:49164 0.0.0.0:0 LISTENING 504
TCP 0.0.0.0:49252 0.0.0.0:0 LISTENING 496
TCP 0.0.0.0:49255 0.0.0.0:0 LISTENING 5256
TCP 0.0.0.0:61603 0.0.0.0:0 LISTENING 1516

C:\Users\. >netstat -na

Proto Local Address Foreign Address State
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:475 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1540 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1541 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1560 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1561 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1562 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1563 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1564 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1565 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1566 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1567 0.0.0.0:0 LISTENING
TCP 0.0.0.0:2301 0.0.0.0:0 LISTENING
TCP 0.0.0.0:2381 0.0.0.0:0 LISTENING
TCP 0.0.0.0:5633 0.0.0.0:0 LISTENING
TCP 0.0.0.0:6101 0.0.0.0:0 LISTENING
TCP 0.0.0.0:6106 0.0.0.0:0 LISTENING
TCP 0.0.0.0:10000 0.0.0.0:0 LISTENING
TCP 0.0.0.0:22350 0.0.0.0:0 LISTENING
TCP 0.0.0.0:47001 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49157 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49158 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49163 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49185 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49263 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49268 0.0.0.0:0 LISTENING
TCP 0.0.0.0:61603 0.0.0.0:0 LISTENING

Проверка состояния протокола RDP

Проверка состояния протокола RDP на локальном компьютере

Сведения о том, как проверить и изменить состояние протокола RDP на локальном компьютере, см. в разделе How to enable Remote Desktop (Как включить удаленный рабочий стол).

Проверка состояния протокола RDP на удаленном компьютере

В точности следуйте инструкциям из этого раздела. Неправильное изменение реестра может вызвать серьезные проблемы. Прежде чем редактировать реестр, создайте резервную копию реестра, чтобы вы могли восстановить его в случае ошибки.

Чтобы проверить и изменить состояние протокола удаленного рабочего стола на удаленном компьютере, используйте подключение сетевого реестра:

Редактор реестра, в котором отображается запись fDenyTSConnections

  1. Сначала откройте меню Пуск и выберите Выполнить. В появившемся текстовом поле введите regedt32.
  2. В редакторе реестра нажмите Файл и выберите пункт Подключить сетевой реестр.
  3. В диалоговом окне Выбор: "Компьютер" введите имя удаленного компьютера, выберите Проверить имена и нажмите кнопку ОК.
  4. Перейдите в раздел HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server и в раздел HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services.
    • Если раздел fDenyTSConnections имеет значение 0, значит протокол RDP включен.
    • Если раздел fDenyTSConnections имеет значение 1, значит протокол RDP отключен.
  5. Чтобы включить протокол RDP, для fDenyTSConnections замените значение 1 на 0.

Проверка блокировки объектом групповой политики протокола RDP на локальном компьютере

Если не удается включить протокол RDP в пользовательском интерфейсе или для fDenyTSConnections возвращается значение 1 после его изменения, объект групповой политики может переопределять параметры на уровне компьютера.

Чтобы проверить конфигурацию групповой политики на локальном компьютере, откройте окно командной строки с правами администратора и введите следующую команду:

Когда команда будет выполнена, откройте файл gpresult.html. Выберите Конфигурация компьютера\Административные шаблоны\Компоненты Windows\Службы удаленных рабочих столов\Узел сеансов удаленных рабочих столов\Подключения и найдите политику Разрешить пользователям удаленное подключение с использованием служб удаленных рабочих столов.

Если для параметра этой политики задано значение Включено, групповая политика не блокирует подключения по протоколу RDP.

Пример сегмента gpresult.html, в котором показано, что объект групповой политики на уровне домена Block RDP блокирует протокол RDP.

Если же для параметра этой политики задано значение Отключено, проверьте результирующий объект групповой политики. Ниже показано, какой объект групповой политики блокирует подключения по протоколу RDP.

Пример сегмента gpresult.html, в котором объект групповой политики уровня домена Local Group Policy блокирует протокол RDP.

Проверка блокировки объектом групповой политики протокола RDP на удаленном компьютере

Чтобы проверить конфигурацию групповой политики на удаленном компьютере, нужно выполнить почти такую же команду, что и для локального компьютера.

В файле (gpresult-<computer name>.html), который создается после выполнения этой команды, используется такой же формат данных, как в версии файла для локального компьютера (gpresult.html).

Изменение блокирующего объекта групповой политики

Эти параметры можно изменить в редакторе объектов групповой политики (GPE) и консоли управления групповыми политиками (GPM). Дополнительные сведения об использовании групповой политики см. в статье Advanced Group Policy Management (Расширенное управление групповыми политиками).

Чтобы изменить блокирующую политику, используйте один из следующих методов.

  • В GPE укажите определенный уровень для объекта групповой политики (локальный или доменный) и выберите Конфигурация компьютера > Административные шаблоны > Компоненты Windows > Службы удаленных рабочих столов > Узел сеансов удаленных рабочих столов > Подключения > Разрешить пользователям удаленное подключение с использованием служб удаленных рабочих столов.
    1. Задайте для политики значение Включена или Не задана.
    2. На затронутых компьютерах откройте окно командной строки с правами администратора и выполните команду gpupdate /force.
  • В GPM перейдите к подразделению, в котором блокирующая политика применяется к соответствующим компьютерам, и удалите эту политику.

Проверка состояния служб RDP

На локальном компьютере (клиентском) и удаленном компьютере (целевом) должны быть запущены следующие службы:

  • службы удаленных рабочих столов (TermService);
  • перенаправитель портов пользовательского режима служб удаленного рабочего стола (UmRdpService).

Для локального или удаленного управления службами можно использовать оснастку MMC. Вы также можете использовать PowerShell для управления службами в локальном или удаленном расположении (если удаленный компьютер настроен для приема удаленных командлетов PowerShell).

Службы удаленных рабочих столов в оснастке MMC "Службы" Не изменяйте параметры служб, заданные по умолчанию.

На любом компьютере запустите одну или обе службы, если они запущены.

Если вы запускаете службу удаленных рабочих столов, нажмите кнопку Да, чтобы служба перенаправителя портов пользовательского режима служб удаленного рабочего стола перезапустилась автоматически.

Проверка состояния прослушивателя протокола RDP

В точности следуйте инструкциям из этого раздела. Неправильное изменение реестра может вызвать серьезные проблемы. Прежде чем редактировать реестр, создайте резервную копию реестра, чтобы вы могли восстановить его в случае ошибки.

Проверка состояния прослушивателя RDP

Для выполнения этой процедуры используйте экземпляр PowerShell с разрешениями администратора. На локальном компьютере также можно использовать командную строку с разрешениями администратора. Но для этой процедуры используется PowerShell, так как одни и те же командлеты выполняются локально и удаленно.

Чтобы подключиться к удаленному компьютеру, выполните следующий командлет:

Команда qwinsta выводит список процессов, которые ожидают передачи данных через порты компьютера.

Введите qwinsta.

Если в списке содержится rdp-tcp с состоянием Listen, прослушиватель протокола удаленного рабочего стола работает. Перейдите к разделу Проверка порта прослушивателя протокола RDP. В противном случае перейдите к шагу 4.

Экспортируйте конфигурацию прослушивателя RDP с рабочего компьютера.

  1. Войдите на компьютер с той же версией операционной системы, что и у затронутого компьютера, и получите доступ к реестру компьютера (например, с помощью редактора реестра).
  2. Перейдите к следующей записи реестра:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
  3. Экспортируйте запись в REG-файл. Например, в редакторе реестра щелкните запись правой кнопкой мыши, выберите пункт Экспортировать, а затем введите имя файла для экспортируемых параметров.
  4. Скопируйте экспортированный REG-файл на затронутый компьютер.

Чтобы импортировать конфигурацию прослушивателя протокола RDP, откройте окно PowerShell с разрешениями администратора на затронутом компьютере (или откройте окно PowerShell и подключитесь к этому компьютеру из удаленного расположения).

Чтобы создать резервную копию для существующей записи реестра, воспользуйтесь таким командлетом:

Чтобы удалить резервную копию для существующей записи реестра, воспользуйтесь таким командлетом:

Чтобы импортировать новую запись реестра и перезапустить службу, воспользуйтесь такими командлетами:

Замените <filename> именем экспортированного REG-файла.

Проверьте конфигурацию, попытавшись еще раз подключиться к удаленному рабочему столу. Если подключиться все равно не удается, перезагрузите затронутый компьютер.

Проверка состояния самозаверяющего сертификата протокола RDP

Сертификаты удаленного рабочего стола в оснастке MMC "Сертификаты".

  1. Если подключиться так и не удалось, откройте оснастку MMC "Сертификаты". Когда будет предложено выбрать хранилище сертификатов для управления, выберите Учетная запись компьютера и затронутый компьютер.
  2. В папке Сертификаты в разделе Удаленный рабочий стол удалите самозаверяющий сертификат протокола RDP.
  3. На затронутом компьютере выполните следующие действия, чтобы перезапустить службу удаленных рабочих столов.
  4. Обновите оснастку диспетчера сертификатов.
  5. Если самозаверяющий сертификат протокола RDP не был создан повторно, проверьте разрешения для папки MachineKeys.

Проверка разрешений для папки MachineKeys

  1. На затронутом компьютере откройте проводник и перейдите к папке C:\ProgramData\Microsoft\Crypto\RSA\ .
  2. Щелкните правой кнопкой мыши папку MachineKeys, а затем выберите Свойства, Безопасность и Дополнительно.
  3. Убедитесь, что настроены следующие разрешения:
    • Builtin\Администраторы: Полный доступ
    • Все: чтение и запись.

Проверка порта прослушивателя протокола RDP

На локальном компьютере (клиентском) и удаленном компьютере (целевом) прослушиватель протокола RDP должен ожидать передачи данных через порт 3389. Другие приложения не должны использовать этот порт.

В точности следуйте инструкциям из этого раздела. Неправильное изменение реестра может вызвать серьезные проблемы. Прежде чем редактировать реестр, создайте резервную копию реестра, чтобы вы могли восстановить его в случае ошибки.

Чтобы проверить или изменить порт протокола RDP, используйте редактор реестра:

Подраздел PortNumber для протокола RDP.

  1. Откройте меню Пуск, выберите Выполнить и введите regedt32 в появившемся текстовом поле.
    • Чтобы подключиться к удаленному компьютеру, в редакторе реестра щелкните Файл и выберите пункт Подключить сетевой реестр.
    • В диалоговом окне Выбор: "Компьютер" введите имя удаленного компьютера, выберите Проверить имена и нажмите кнопку ОК.
  2. Откройте реестр и перейдите к записи HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\<listener> .
  3. Если PortNumber имеет значение, отличное от 3389, укажите значение 3389.

Для управления службами удаленного рабочего стола можно использовать другой порт. Но мы не рекомендуем делать это. В этой статье не описано, как устранять проблемы, связанные с этим типом конфигурации.

Проверка того, что другое приложение не пытается использовать тот же порт

Для выполнения этой процедуры используйте экземпляр PowerShell с разрешениями администратора. На локальном компьютере также можно использовать командную строку с разрешениями администратора. Но для этой процедуры используется PowerShell, так как одни и те же командлеты выполняются локально и удаленно.

Откройте окно PowerShell. Чтобы подключиться к удаленному компьютеру, введите Enter-PSSession -ComputerName <computer name> .

Введите следующую команду:

Команда netstat выводит список портов, которые должны прослушивать службы.

Найдите запись для TCP-порта 3389 (или назначенного RDP-порта) с состоянием Ожидает вызова.

Идентификатор процесса службы или процесса, использующих этот порт, отобразится в столбце "Идентификатор процесса".

Чтобы определить, какое приложение использует порт 3389 (или назначенный порт протокола RDP), введите следующую команду:

Команда tasklist выводит данные об определенном процессе.

Найдите запись для номера процесса, связанного с портом (в выходных данных netstat). Службы или процессы, связанные с этим идентификатором процесса, отобразятся в столбце справа.

Если порт используется приложением или службой, отличающейся от служб удаленных рабочих столов (TermServ.exe), устранить конфликт можно с помощью одного из следующих методов:

  • В настройках такого приложения или службы укажите другой порт (рекомендуется).
  • Удалите другое приложение или службу.
  • В настройках протокола RDP укажите другой порт, а затем перезапустите службы удаленных рабочих столов (не рекомендуется).

Проверка блокировки порта протокола RDP брандмауэром

С помощью средства psping проверьте, доступен ли затронутый компьютер через порт 3389.

Откройте окно командной строки с правами администратора, перейдите в каталог, где установлено средство psping, и введите следующую команду:

Проверьте выходные данные команды psping на наличие таких результатов:

  • Подключение к <computer IP>: удаленный компьютер доступен.
  • (0% loss) (0 % потерь): все попытки подключения выполнены успешно.
  • The remote computer refused the network connection (Удаленный компьютер отклонил сетевое подключение): удаленный компьютер недоступен.
  • (100% loss) (100 % потерь): не удалось выполнить подключение.

Запустите psping на нескольких компьютерах, чтобы проверить возможность подключения к затронутому компьютеру.

Проверьте, блокирует ли этот компьютер подключения от всех остальных компьютеров, некоторых других компьютеров или только одного компьютера.

Хэлп! Перестал работать RDP на WinServ 2008R2

Компьютерный форум Хабаровска. Все о компьютерах и цифровой технике в Хабаровске. Мобильные телефоны, цифровые камеры, короче все что с этим связано.

Модератор: Catzilla

Хэлп! Перестал работать RDP на WinServ 2008R2

как-то прям внезапно - никаких обновлений, софта и т.п. не устанавливалось

процесс запущен, нетстат его видит на нужном 3389-м порту,
локально сам к себе на 127.0.0.1 замечательно подключается, а вот по сети - нихуа.
пишет, комп выключен или недоступен.
порт в файрволе открыт, ессна.

а, и все остальные сервисы типа DHCP, TFTP, DNS работают, как файл-сервер машинка тоже функционирует без замечаний Конектишься по IP? Может ДНС скуксился?
Пошерсти журнал все таки.
На клиентской машине поищи в реестре MSLicensing и грохни целиком ветку. по IP
в журналах - типа все пучком, шерстил уже и писал
клиентские машины - wtware thinstation etc
одинаково не работает и с линуксов и с виндовых клиентов genok
на каком интерфейсе 3389 bined? может просто на 127.х.х.х из-за отсутствия других интерфейсов в момент старта службы. genok
попробуй откатить дату на пару месяцев, так, в порядке бреда, чисто для эксперимента В) В оснастке Конфигурация служб терминалов/Диагностика лицензирования молчит?

по лицензированию нормально все, не ругается

локально подключается и на 127. и на 192.168.
что интересно, нетстат показывает про сидящий на интерфейсе процесс, файрвол открыт, а сканирование портов извне 3389-го порта не видит

внезапно? - работал-работал и вдруг в 12:19 перестал? = сгорела сетевушка или вылез конфликт IP..
или внезапно после перезагрузки?

проблема решилась
в правилах брандмауэра правило для РДП было продублировано для разных профилей - частного и общего
для одного включено правило, для другого отключено.
Выходит, что в какой-то момент времени либо отключилось самопроизвольно одно из правил, что маловероятно,
либо сеть каким-то образом опять таки сама поменяла статус с частной на общую

х.з., в общем, причина неясна, что за самодеятельность

внезапно? - работал-работал и вдруг в 12:19 перестал? = сгорела сетевушка или вылез конфликт IP..
или внезапно после перезагрузки?

а хрен его знает, я тут не работаю - вчера люди подключались, а сегодня с утра - нет уже
перезагрузок ночью не было, смотрел по логам

Причины черного экрана по RDP сессии

Я довольно часто встречаю эту проблему, и в 99 процентах случаев она связана с зависшей сессией пользователя, на удаленном сервере. Большинство пользователей в большинстве случаев, не разлогиниваются от удаленной сессии, а просто закрывают окно удаленного подключения, чтобы, подключившись снова они могли продолжить свою работу с прежнего места. В некоторых случаях это оправдано, когда человек запустил какой-то процесс, и проверяет его выполнение, через периодическое подключение, но это единичные случаи, чаще всего люди просто забивают на это, а многие системные администраторы не настраивают отключение после некоторого времени бездействия, вот и выходит ситуация с черным экраном при подключении по RDP,

Сразу хочу отметить, что данная проблема не связана с теми, что я описывал ранее в статьях:

Как исправляется ошибка при подключении по rdp черный экран рабочего стола

Как я и писал выше, проблема в зависшей сессии пользователя и логично, чтобы ее решить нужно его разлогинить, тут два варианта, либо системный администратор или другой сотрудник должен в диспетчере задач сделать выход зависшей учетной записи, либо пользователь сам это делает.

Давайте разлогиним пользователя, для этого вы заходите в диспетчер задач, далее вкладка пользователи и находите нужного, щелкаете по нему правым кликом и выбираете Выйти. После чего подключившись по rdp черный экран должен пропасть.

Второй способ, если у вас некому сделать выход учетной записи, то на черном экране нажмите ctrl+alt+end (это аналог CTRL+ALT+DEL в терминальной сессии) и из меню выберите Выход или Выйти из системы, это равносильно разлогированию.

Если это не помогло, а такое может быть на Windows 10, то попробуйте отключить Постоянное кеширование точечных рисунков. Делается это очень просто открываете окно клиента "Подключение к удаленному рабочему столу" . Переходим на вкладку Взаимодействие и снимаем галку Подключение к удаленному рабочему столу.

Так же можно уменьшить разрешение экрана при RDP сессии, для этого переходим на вкладку экран и ставим например 800 на 600 пикселей.

После этого при подключении по rdp черный экран рабочего стола уже не будет вас докучать. Если вам и это не помогло, то можно отключить сжатие для RDP сессий, это маленький шанс но его так же советуют на форумах Microsoft.

Для этого жмем WIN+R и вводим gpedit.msc.

Далее идем по пути Конфигурация компьютера > Административные шаблоны > Компоненты Windows > Службы удаленных рабочих столов > Узел сеансов удаленных рабочих столов > Настройка сжатия данных RemoteFX. Включаем его и ставим не использовать алгоритм сжатия RDP.

Удаление обновлений KB3192404

Помню, что было сбойное обновление KB3192404 для Windows 8.1 или Windows Server 2012 R2, если его обновить, то черный экран пропадал по RDP. Думаю все эти не сложные методы помогут вам решить проблему с черным экраном по RDP подключению. В случае Windows 2008 R2 эта проблема, как известно, вызвана определенным обновлением Microsoft KB2830477, вы можете попробовать удалить его со своего сервера, если он там есть.

Отключение taskoffload

Хоть Microsoft и говорила, что не нужно отключать для Windows Server 2012 R2 параметр у сетевой карты taskoffload, но практика говорит обратное. После его отключения и перезагрузки пропали черные экраны по RDP сессиям.

Откройте командную строку и введите netsh int ip set global taskoffload=disabled, после чего перезагрузите сервер

Превышение времени ожидания (240000 мс)

Черный экран на терминальном сервере из-за драйверов принтера

На сервере Windows 2012 клиент сообщал, о черном экране RDP, он работал нормально в течение нескольких дней, возможно, даже в течение нескольких месяцев, но случайно он завис на черном экране, и единственным выходом была перезагрузка сервера. Если вам не помогли вышеописанные методы, то попробуйте посмотреть вот какую вещь есть ли у вас в просмотре событий Windows события 7011.

Тайм-аут (30000 миллисекунд) был достигнут при ожидании ответа транзакции от службы диспетчера очереди печати.

После исключения всех очевидных причин на сервере, перечисленных выше, мое исследование показало, что эта проблема черного экрана RDP возникает из-за некоторых драйверов принтера, установленных на сервере Windows 2012 R2. Хотя я не очень уверен, какие драйверы принтеров вызывают эту проблему, выполните следующие шаги, чтобы решить эту проблему.

  1. Установите все ожидающие обновления Windows на сервере
  2. Удалите с сервера все возможные драйверы принтера, включая устройства записи PDF. Я рекомендую не удалять драйверы в течение периода мониторинга, если это возможно, в противном случае удалите все драйверы и переустановите самые последние копии только самых необходимых драйверов, выполнив все перечисленные ниже действия.
  3. Если на сервере установлены драйверы HP, обязательно удалите их или остановите службы Драйвер Net Net HPZ12 и Драйвер PML HPZ12 (если есть).
  4. Лучше вообще настройте сервер печати и драйвера Easy Print
  5. Удалите все сторонние поставщики печати и процессоры печати с сервера. выполните следующие шаги

Переполнение ветки реестра с правилами брандмауэра

Когда пользователь заходит на сервер, то в определенной ветке реестра добавляются 9 правил, для приложений Cortana, и когда пользователь выходит из системы они должны удалиться, но этого не происходит и при следующем заходе создадутся еще 9 правил, а далее по накатанной. Все это в какой-то момент переполняет ветку реестра. Так же в логах сервера вы легко можете видеть ошибку

Сбой CreateAppContainerProfile для AppContainer Microsoft.Windows.Cortana_cw5n1h2txyewy из-за ошибки 0x800705AA

0x800705AA

Или вот такой вариант:

Ошибка с кодом ID 10: Произошел сбой операции Appx RegisterPackageAsync в Microsoft.XboxGameCallableUI_10.0.14393.0_neutral_neutral_cw5n1h2txyewy для пользователя sil: Ошибка 0x800705AA: Windows не удается создать профиль AppContainer для пакета Microsoft.XboxGameCallableUI_1000.14393.0.0_neutral_neutral_cw5n1h2txyewy.. (Ошибка: Не удалось зарегистрировать пакет.)

Произошел сбой операции Appx RegisterPackageAsync в Microsoft.XboxGameCallableUI

Вот ветка, где создаются данные правила:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules

Черный экран может себя уже проявлять при 25 000 записей.

Удаление ветки реестра FirewallPolicy

Чтобы победить черный экран необходимо удалить их, для это выполните:

Remove-Item "HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess \Parameters\FirewallPolicy\RestrictedServices\Configurable\System"
New-Item "HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess \Parameters\FirewallPolicy\RestrictedServices\Configurable\System"
Remove-Item "HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess \Parameters\FirewallPolicy\FirewallRules"
New-Item "HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess \Parameters\FirewallPolicy\FirewallRules"
Remove-Item "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion \Notifications" -Recurse
New-Item "HKLM:\SOFTWARE\Microsoft\Windows NT\ CurrentVersion\Notifications"

Для Windows Server 2019, вот такую ветку нужно удалить и воссоздать: HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\ Parameters\FirewallPolicy\RestrictedServices\AppIso\FirewallRules

Так же вам необходимо создать дополнительный ключ реестра, чтобы правила больше не создавались повторно, делается это по пути:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\SharedAccess\Parameters\FirewallPolicy

Тип REG_DWORD с именем DeleteUserAppContainersOnLogoff и значением 1. После чего просто перезагрузитесь.

Алгоритм решения черного экрана при сбойном диспетчере печати

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Print\Monitors\Local Port
  • Дважды щелкните ключ драйвера и измените значение. Измените строковое значение на Localspl.dll и нажмите кнопку ОК.

Monitors Local Port

  • Проверьте следующий раздел реестра на наличие сторонних мониторов портов, а затем удалите все мониторы портов, кроме мониторов портов по умолчанию:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Control\Print\Monitors
  • Порты по умолчанию: AppleTalk Printing Devices (если службы для Macintosh установлен), BJ Language Monitor, Локальный порт, PJL Language Monitor , Стандартный порт TCP/IP, USB-монитор, Windows NT Fax Monitor (если установлен)

Control Print Monitors

  • Проверьте следующий раздел реестра на наличие сторонних поставщиков печати, а затем удалите все поставщики печати, отличные от поставщиков печати по умолчанию:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Control\Print\Providers

Print Providers

Поставщики печати по умолчанию - Интернет-провайдер печати Поставщик печати, LanMan

  • Проверьте следующий раздел реестра для сторонних процессоров печати, а затем удалите все процессоры печати, кроме процессора печати по умолчанию:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Print\Environments\Windows x64\

winprint

Процессоры печати Процессор печати по умолчанию: winprint. Закройте редактор реестра. Перезапустите диспетчер очереди печати или перезагрузите сервер.

Читайте также: