SysAdmin
Windows Server
818
В данной статье я расскажу, как решить проблему с кнопкой «Пуск» в Windows Server 2016, когда она перестает реагировать на левый клик мыши, хотя правый клик работает корректно, отображая контекстное меню. Эта неисправность часто возникает на серверах, где значки меню «Пуск» настраиваются через XML-файл, развернутый с помощью групповой политики.
Содержание:
- Меню «Пуск» не реагирует в Windows Server 2016
- Решение проблемы
- Заключение
Меню «Пуск» не реагирует в Windows Server 2016
Эта проблема часто встречается на серверах под управлением Windows Server 2016. Несмотря на многочисленные попытки устранить неисправность, стандартные методы, такие как сброс профиля пользователя, не приводят к положительному результату. Она продолжает вызывать неудобства для администраторов и пользователей, затрудняя выполнение повседневных задач.
Решение проблемы
Чтобы временно устранить проблему с неработающим меню «Пуск» в текущем сеансе пользователя, выполните следующую команду в PowerShell:
Get-AppXPackage | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register “$($_.InstallLocation)\AppXManifest.xml”}
После выполнения этой команды функциональность меню «Пуск» должна восстановиться. Однако имейте в виду, что проблема может повториться через некоторое время, например, на следующий день.
Для постоянного исправления проблемы выполните следующие действия от имени администратора:
Важно: Рекомендуется создать резервную копию реестра перед внесением изменений, чтобы избежать непредвиденных последствий.
- Откройте PowerShell с правами администратора.
- Выполните следующую команду для удаления проблемного элемента реестра:
Remove-Item "HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System"
- Затем создайте новый элемент с помощью следующей команды:
New-Item "HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System"
Эти изменения будут применены ко всем пользователям на сервере и должны устранить проблему с меню «Пуск» на постоянной основе.
Важно отметить, что проблема, скорее всего, связана с отключением брандмауэра Windows на этих серверах. Приведенное выше решение предназначено для полного и постоянного устранения этой неисправности.
Заключение
В заключение, проблема с неработающим меню «Пуск» в Windows Server 2016 может существенно повлиять на удобство работы пользователей и администраторов. Мы рассмотрели временные и постоянные способы устранения этой неисправности, включая команду PowerShell для быстрого восстановления функциональности и изменение параметров реестра для долговременного решения.
Регулярное обслуживание серверов, корректная настройка групповых политик и мониторинг состояния системы помогут избежать подобных проблем в будущем. Надеюсь, предложенные методы окажутся полезными и позволят вам вернуть стабильную работу ваших серверов.
Вам понравилась эта статья? Тогда вам, скорее всего, будет интересна другая полезная статья Как проверить работоспособности Active Directory с помощью скрипта PowerShell.
Интересуешься IT и системным администрированием? Подпишись на SysAdminHub в телеграмм, чтобы узнавать обо всем первым — t.me/SysAdminHub
Статья была полезна? Поддержи автора, и благодаря твоей помощи новые материалы будут выходить еще чаще:
In this article, I’ve put together some solutions to common performance problems with RDS servers or published RemoteApp that I’ve encountered in my infrastructure. Before implementing any of the solutions or workarounds, check if it is suitable for your infrastructure and environment.
Contents:
- Fixing RDS Performance on Windows Server 2016/2019 with UPD
- Poor RDS/RemoteApp Performance Due to High Mouse Polling Rate
- Slow RemoteAPP, Mouse, and Menu Lags after Windows 10 Upgrade
Fixing RDS Performance on Windows Server 2016/2019 with UPD
RDS servers running Windows Server 2019/2016 with a large number of users may experience slow performance when using User Profile Disks.
The problem is that new inbound and outbound rules are created in Windows Defender Firewall every time a user logs in. Those firewall rules are not automatically removed when the user logs out.
Over time, a lot of duplicate rules appear in the firewall, which leads to a dramatic decrease in performance of the RDS server (slow login, RDS hosts freeze, menus don’t open, and the Start button does not appear).
Check the number of rules in Windows Defender Firewall using the PowerShell command:
(Get-NetFirewallRule).count
In my case, one of the RDS hosts had 18,000 firewall rules! These rules are created for Windows UWP Store apps each time a user signs in.
To fix the issue, you must first install the latest security updates for your version of Windows Server (at least KB4467684 on Windows Server 2016 and KB4490481 for Windows Server 2019). Then create the following registry parameter on your RDSH:
- Reg key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy
- Type: REG_DWORD
- Property: DeleteUserAppContainersOnLogoff
- Value:
1
You can create a registry property using the PowerShell command:
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy" -Type DWord -Name DeleteUserAppContainersOnLogoff -Value 1
Don’t forget to manually clear the inbound and outbound rules in Windows Defender Firewall. If there are few firewall rules, you can use a PowerShell script from the TechNet thread (https://social.microsoft.com/Forums/Azure/en-US/992e86c8-2bee-4951-9461-e3d7710288e9/windows-servr-2016-rdsh-firewall-rules-created-at-every-login?forum=winserverTS).
Poor RDS/RemoteApp Performance Due to High Mouse Polling Rate
Many users complain about poor RDP session performance, high latency, and mouse lags after migrating the RDS farm to Windows Server 2019. The mouse is very slow to respond to movement, the cursor shakes, and freezes.
This problem can be related to the high DPI and polling rate settings of some optical mice (usually gaming mice). For example, the popular Logitech G203 mouse has a default polling rate of 1000 times per second (1000 Hz). A high mouse polling rate seems to cause a high load on the RDP connection, and you may encounter lags when working with RemoteApps. If you reduce this value to 125 times per second (125 Hz), the mouse problem in the RDP session will disappear.
You can reduce the Polling Rate using the vendor’s mouse tools.
If you can’t reduce the polling rate, try to disable the mouse cursor shadow (uncheck the Enable pointer shadow option) and select the None scheme for the pointer in the mouse settings in the Windows Control Panel (main.cpl).
Slow RemoteAPP, Mouse, and Menu Lags after Windows 10 Upgrade
Users may experience performance issues with RemoteApps published on Windows Server 2019/2016/2012R2 RDS servers after the Windows 10 build upgrade. RDS RemoteApps may start to work much slower, any action that is caused by a mouse click is performed (drawn) 2-3 times longer, and context menus in RemoteApps are displayed slowly (menu items blink, you have to click on them several times, sometimes they do not appear at all). Similar problems occurred when upgrading Windows 10 builds on clients to 1803 and 20H2.
In this case, problems don’t occur in the full-screen RDP connection mode established with the built-in Mstsc.exe or RDCMan client.
To work around this problem, you can try to change the value of the Use Advanced RemoteFX graphics for RemoteApp parameter to Disabled using the local GPO editor (gpedit.msc) (GPO section: Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Environment).
If graphics programs (usual, the CAD apps) are published as RemoteAPPs, then they will not work without Remote FX support.
However, there is also a workaround to replace the RDP client version with an older one. Because performance issues with RemoteApp have been encountered also in Windows 10 1709, it’s best to use RDP libraries from 1607 or 1703. The thing is that after upgrading the Windows 10 build, a new version of the RDP client is installed, which doesn’t work correctly with the programs published via RDS RemoteApp.
You can fix poor RemoteApp performance on clients by replacing the mstsc.exe and mstscax.dll files in the C:\Windows\System32 folder with the versions from a previous build of Windows 10 (1703 or 1607).
How to replace RDP client files in Windows 10?
- Close all RDP connections and running RemoteApp (it is better even to restart the computer);
- Download the archive with the versions of mstsc.exe and mstscax.dll from Windows 10 1607 build (mstsc-w10-1607.zip);
- Copy the original mstsc.exe and mstscax.dll files from the C:\windows\system32\ to the C:\BackUp using the commands:
md c:\backup\
copy C:\windows\system32\mstsc.exe c:\backup
copy C:\windows\system32\mstscax.dll c:\backup - Then you need to assign your account to the owner of the mstsc.exe and mstscax.dll files in the C:\windows\system32\ directory, disable inheritance and grant yourself the permissions to modify the files:
takeown /F C:\windows\system32\mstsc.exe
takeown /F C:\windows\system32\mstscax.dll
icacls C:\windows\system32\mstsc.exe /inheritance:d
icacls C:\windows\system32\mstscax.dll /inheritance:d
icacls C:\windows\system32\mstsc.exe /grant root:F
icacls C:\windows\system32\mstscax.dll /grant root:F
In this example, the name of the local account with administrator permissions is root. Replace it with your account name.
- Replace the files in the C:\windows\system32\ directory with the files from the archive;
- Restore the original permissions on the copied files. To do this, enable inheritance of NTFS permissions and set the owner of the files to “NT Service\TrustedInstaller” using the ICACLS tool:
icacls C:\windows\system32\mstsc.exe /inheritance:e
icacls C:\windows\system32\mstscax.dll /inheritance:e
icacls C:\windows\system32\mstsc.exe /setowner "NT Service\TrustedInstaller" /T /C
icacls C:\windows\system32\mstscax.dll /setowner "NT Service\TrustedInstaller" /T /C - It remains to re-register the library::
regsvr32 C:\Windows\System32\mstscax.dll
This will temporarily fix the RemoteApp performance issue on Windows 10 clients.
Синхронизация времени в домене Active Directory критически важна для корректного функционирования сервисов и механизмов безопасности. Если в домене не настроена четкач схема синхронизации времени, это может вызвать проблемы с аутентификацией, работой криптографических протоколов, сертификатов при взаимодействии со внутренними и внешними системами. Так, например, Kerberos аутентификация требует, чтобы время между клиентом и сервером не отличалась более чем на пять минут. В этой статье, мы рассмотрим, как должна работать синхронизация времени в домене AD, и как настроить синхронизацию контроллера домена с внешним источником точного времени (NTP).
Содержание:
- Как работает синхронизация времени в домене AD?
- Ручная настройка синхронизация времени контроллера домена PDC с внешним NTP источником
- Настройка групповой политики для синхронизации времени PDC с NTP
- Настройка синхронизации времени на клиентах домена
Как работает синхронизация времени в домене AD?
Схема синхронизации времени в домене Active Directory имеет строгую иерархию:
- Главным источником времени в домене является контроллер домена с FSMO ролью эмулятора PDC.
- С PDC синхронизируют время все остальные контроллеры домена.
- Рядовые сервера и рабочие станции синхронизируют свое время с ближайшими DC согласно топологии AD (по умолчанию компьютеры Windows синхронизируют время внешним
time.windows.com
, но после добавления в домен синхронизация выполняется согласно иерархии домена)
Источник
Для обеспечения точного времени на всех компьютерах домена, нужно настроить синхронизацию PDC с неким внешним источником точного времени по протоколу NTP.
Чтобы определить имя контроллера домена, на котором запущена FSMO роль эмулятора PDC, выполните PowerShell команду:
Get-ADDomain | Select-Object PDCEmulator
Ручная настройка синхронизация времени контроллера домена PDC с внешним NTP источником
По умолчанию PDC синхронизирует время с аппаратными часами материнской платы физического сервера, на котором он запущен. Это можно проверить, выполнив на нем команду:
w32tm /query /source
Local CMOS Clock
указывает, что в качестве источника времени используются локальные часы. При этом в логе Event Viewe на PDC будет регистрироваться событие Event ID 12 от Time-Service:
Time Provider NtpClient: This machine is configured to use the domain hierarchy to determine its time source, but it is the AD PDC emulator for the domain at the root of the forest, so there is no machine above it in the domain hierarchy to use as a time source. It is recommended that you either configure a reliable time service in the root domain, or manually configure the AD PDC to synchronize with an external time source. Otherwise, this machine will function as the authoritative time source in the domain hierarchy. If an external time source is not configured or used for this computer, you may choose to disable the NtpClient.
Если DC запущен на виртуальной машине, в настройках которой включена синхронизация времени с хостом (гипервизором), эта команда вернет:
VM IC Time Synchronization Provider
Поэтому для всех DC нужно отключить синхронизацию времени в настройках ВМ, или запретить DC получать время с хоста, создав параметр реестра:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\VMICTimeProvider /v Enabled /t REG_DWORD /d 0 /f
Перенастроим настройки Windows Time на PDC так, чтобы он использовал в качестве источника времени внешний NTP сервер. В качестве источника времени можно использовать ближайшие к вам сервера NTP из пула проекта https://www.ntppool.org
Для России это будут сервера 0.ru.pool.ntp.org, 1.ru.pool.ntp.org и 2.ru.pool.ntp.org
Проверьте с PDC эмулятора, что доступ к этим NTP серверам доступен (и порт 123/UDP не блокируется файерволами):
w32tm /stripchart /computer:0.ru.pool.ntp.org
Если вы получили ответ от NTP сервера, можно задать эти внешние сервера в качестве источников времени для Primary DC. Выполните команды:
net stop w32time
w32tm /config /syncfromflags:manual /manualpeerlist:"0.ru.pool.ntp.org,0x8 1.ru.pool.ntp.org,0x8 3.ru.pool.ntp.org,0x8 4.ru.pool.ntp.org,0x8"
w32tm /config /reliable:yes
net start w32time
w32tm /config /update
Выполните синхронизацию времени с NTP:
w32tm /resync
Проверьте, что теперь источником времени на PDC является внешние NTP сервера:
w32tm /query /configuration
Настройка групповой политики для синхронизации времени PDC с NTP
Так как роль эмулятора PDC может быть передана на другой контроллер домена, можно настроить групповую политику, которая будет автоматически применять настройки синхронизации с внешним NTP источников времени на текущем DC с ролью PDC.
Для этого в консоли управления Group Policy Management Console (
GPMC.msc
), создайте новый WMI фильтр групповых политик. Перейдите разделе WMI Filters, создайте фильтр с именем PDC Emulator и WMI запросом:
Select * from Win32_ComputerSystem where DomainRole = 5
Создайте новую GPO, откройте ее и перейдите в раздел Computer Configuration-> Administrative Templates -> System -> Windows Time Service -> Time Providers
Нас интересуют три политики:
- Configure Windows NTP Client: Enabled (настройки политики описаны ниже)
- Enable Windows NTP Client: Enabled
- Enable Windows NTP Server: Enabled
В настройках политики Configure Windows NTP Client укажите следующие параметры:
- NtpServer: 0.ru.pool.ntp.org,0x8 1.ru.pool.ntp.org,0x8 2.ru.pool.ntp.org,0x8 3.ru.pool.ntp.org,0x8
- Type: NTP
- CrossSiteSyncFlags: 2
- ResolvePeerBackoffMinutes: 15
- Resolve Peer BAckoffMaxTimes: 7
- SpecilalPoolInterval: 1024
- EventLogFlags: 0
Примените созданный ранее фильтр PDC Emulator к GPO.
Осталось прилинковать новую GPO на контейнер Domain Controllers.
Настройка синхронизации времени на клиентах домена
В домене нужно настраивать время только на контроллере домена с ролью PDC. Он должен синхронизировать время с внешним NTP. Специально какие-то отдельные политики или настройки для синхронизации времени на оставшихся DC или компьютерах делать не нужно (это может быть даже вредно). Синхронизация времени должна отлично работать согласно иерархии AD (NT5DS).
На оставшихся (дополнительных) контроллерах домена и остальных клиентах синхронизация времени должна выполняться согласно иерархии домена. Проверим это:
w32tm /query /configuration
Если все настроено правильно, в качестве типа источника времени в разделе
TimeProviders
должен быть задан NT5DS.
Настройки службы времени хранятся в ветке реестра
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
.
Если это не так, можно сбросить настройки синхронизации времени на клиенте и принудительно указать, что нужно использовать схему синхронизации по-умолчанию (по доменной иерархии):
net stop w32time
w32tm.exe /unregister
w32tm.exe /register
net start w32time
w32tm /config /syncfromflags:DOMHIER /update
w32tm /resync
Проверьте что теперь в качестве источника времени на клиенте используется ближайший контроллер домена (LogonServer):
w32tm /query /source
Типовые ошибки синхронизации времени на клиентах Windows описаны в статье.
В данной статье мы рассмотрим базовые настройки Windows Server 2016, которые осуществляются сразу после установки системы и которые обычно обязательные к использованию. Как установить Windows Server 2016 можете ознакомиться в нашей прошлой статье.
Итак, приступим. Для начала нам нужно задать имя нашему серверу, для этого заходим в свойства системы => изменить параметры => изменить. Задаем «Имя компьютера», и если нужно, то имя рабочей группы. После изменения параметров нужно перезагрузиться.
После нам нужно задать сетевые настройки. Если у Вас сервер подключен к маршрутизатору, то задаем IP шлюза, вводим статический адрес, это обязательно для сервера и маску подсети. Информацию об IP адресах в Вашей локальной сети можно посмотреть через командную строку командной «ipconfig». Ниже на скриншотах указаны примеры, у Вас IP адреса будут отличаться.
Заходим в настройки сетевых подключений:
Заходим в свойства пункта IPv4.
И вводим задаем здесь статические IP адреса. После ставим галку «Подтвердить параметры при выходи», тем самым сохраняя настройки.
Перейдем наконец к самым главным настройкам, к Active Directory. Меню «Пуск» => Диспетчер серверов.
В панели мониторинга => Добавить роли и компоненты.
В типе установки выбираем «Установка ролей или компонентов».
Выбираем нужный сервер в пуле, он будет с именем, который Вы назначили по инструкции выше.
В ролях сервера мы выбираем следующие стандартные роли. Вы можете выбрать что-то еще, если Вам необходимо под Ваши задачи.
В компонентах оставляем по стандарту следующие пункты. Мы рекомендуем вам дополнительно установить «Службу беспроводной локальной сети», т.к без этой службы на сервер нельзя будет поставить Wi-Fi адаптер и производить настройку беспроводной сети.
В службе ролей мы выбираем следующие пункты. Далее в инструкции мы будем лицензировать терминальный сервер.
Далее оставляем все по стандарту (если Вам не нужно самим, что-то дополнительно установить). Доходим до пункта «Подтверждение» и устанавливаем.
После установки служб нужно перезагрузиться.
Приступаем к настройкам DNS. В Active Directory нажимаем на флажок справа на верху и после заходим в настройки повышения роли этого сервера до контроллера домена.
Выбираем пункт «Добавить новый лес» и придумываем имя Вашему домену. На нашем примере это будет «softcomputers».
Настройки оставляем по стандарту. Вы должны только придумать пароль для Вашего домена.
Проходим проверку. Если вы все сделали правильно, то должно установиться все корректно
После установки и перезагрузки заходим в меню «Средства» => DNS.
Раскрываем древо DNS => «Имя вашего сервера» => Зоны прямого просмотра => Зоны обратного просмотра => Правой кнопкой мыши на данный пункт и «Создать новую зону».
Выбираем «Основная зона» и далее по скриншотам ниже.
На этом пункте выбираете диапазон Вашей локальной сети. У нас на примере она будет 192.168.0. у Вас она может будет своя (см. cmd => ipconfig).
На этом настройки DNS закончены. Приступим к настройкам DHCP. Так же заходим в Active Directory и во флажке справа на верху выбираем соответствующую настройку.
После создания DHCP переходим в меню средства => DHCP для его настройки.
В древе DHCP => Ваш сервер => IPv4 => Правой кнопкой мыши => Создать область.
Задаем имя новой области, у нас это будет «basic».
Далее будет меню для исключения диапазона, если нужно исключить что-то можете сделать в этом меню, если не нужно, то пропускаете.
Далее создаем новый диапазон IP адресов, который будет раздавать сервер в локальную сеть. У нас на примере это новый диапазон 192.168.1
Вы можете создать любой другой диапазон на свое усмотрение.
Далее в древе DHCP => Имя сервера => Область => Пул адресов — будет создан новый диапазон.
Дальше по списку настроек перейдем к созданию терминального сервера и его лицензирования. Это нужно для того, чтобы пользователи могли подключаться по RDP к серверу по своей учетной записи. (Учетную запись для пользователей будем рассматривать в этой инструкции ниже).
Переходим в «Панель управления» => Администрирование => Remote Desktop Services => Диспетчер лицензирования удаленных рабочих столов.
Выбираем пункт во «Все серверы», далее в списке видим имя вашего сервера => правой кнопкой мыши на этот пункт => Активировать сервер.
Переходим в «Мастер активации».
Выбираем «Авто».
Далее вводите опционально имя и фамилию, название Вашей организации и страну размещения сервера.
Приступаем к самому лицензированию после регистрации выше. Вам нужен ключ активации для лицензирования терминального сервера — CAL (Client Access Licence) будет в нашем случае. Он обеспечивает подключение 50 пользователей (клиентов) по RDP к серверу Приобрести ключ активации для данной функции можете в нашем интернет-магазине на следующей странице.
Выбираем «Пакет лицензий в розницу» => Далее.
Вводим ключ активации, который Вы приобрели.
Далее в зависимости от лицензии она может определиться сразу на 50 пользователей, либо Вам нужно будет это указать самим как на скриншоте ниже. (указав больше пользователей, чем позволяет лицензия — данная настройка просто не активируется). Тип лицензии соответственно выбираем «По пользователю».
Далее заходим в редактор локальной групповой политики поиск => gpedit.msc => Конфигурация компьютера => Административные шаблоны => Компоненты Windows => Службы удаленных рабочих столов => Узел сеансов удаленных рабочих столов => Лицензирование.
Переходим в меню «Использовать указанные серверы лицензирования удаленных рабочих столов» и вводим в поле имя Вашего сервера, либо его IP.
После переходим в меню «Задать режим лицензирования удаленных рабочих столов», в раскрывающемся меню выбираем «На пользователя».
После возвращаемся в диспетчер лицензирования удаленных рабочих столов. И смотрим активирован ли сервер. Если да, то все ок. Но у Вас еще может быть «желтое предупреждение» на иконке сервера. Чтобы устранить проблемы переходим в «Рецензия». В меню данной «Рецензии» могут быть пункты которые нужно отметить, нажмите соответствующие кнопки, если они у вас будут.
На настройках RDP все. Теперь нам осталось создать первого пользователя, который будет подключен по RDP к этому серверу.
Active Directory => Средства => Пользователи и компьютеры Active Directory.
В правом списке выбираете Ваш сервер => Правой кнопкой мыши => Создать => Подраздаление. В этом меню мы создадим пул, в котором будет содержаться список наших пользователей.
Задаем ему соответствующее имя. На всякий случай поставьте галку для защиты от случайного удаления.
Далее в новой созданной папке слева в списке => Правой кнопкой мыши => Создать => Пользователь.
Опционально вводим ФИО пользователя и обязательно имя для входа, желательно это делать на латинице.
В следующем окне задаем пароль для пользователя поставив соответствующие галки.
В списке в меню «Пользователи» Вы можете управлять пользователями, удалять их, менять им пароль и т.п. Теперь наш новый пользователь «Петр Петров» может зайти по IP сервера, или по его имени в RDP находясь в одной локальной сети с сервером, либо если он добавлен в домен сервера.
На этом с настройками все. Мы рассмотрели самые важные аспекты в настройки и лицензирования Windows Server 2016. Следите за нашим блогом SoftComputers, у нас еще много всего полезного! 🙂
Что вызывает Internal Error удаленного рабочего стола в Windows
Различные факторы могут вызвать сообщение внутренней ошибке при подключении к удаленному рабочему столу. К этим факторам относятся неправильные настройки подключения к удаленному рабочему столу, проблемы с сетью, настройки безопасности, конфигурация брандмауэра Windows и проблемы с самой службой удаленного рабочего стола.
Как решить проблему Internal Error удаленного рабочего стола
Чтобы подключиться к серверу через VNC, мы сначала должны попасть в панель управления сервером. Чтобы попасть в панель управления сервером, из личного кабинета мы должны в разделе Услуги нажать на Виртуальные серверы, затем на сам сервер, а затем на кнопку Перейти.
Когда откроется панель, нажимаем на кнопку Управление, затем на Виртуальные машины, после этого мы нажимаем на сам сервер и как последний шаг, мы нажимаем на кнопку VNC и авторизируемся на наш сервер.
Чтобы решить проблему с невозможности подключиться на наш сервер через RDP, мы открываем Windows Defender Firewall
После того как сам фаерволл открылся, нажимаем на Allow an app or feature through Windows Defender Firewall.
В новом окне мы ищем Remote Desktop и также включаем галочку чтобы как на Public (публичной сети), так и на Private (приватная сеть) был доступ к RDP. Нажимаем на галочку, затем на кнопку ОК и перезагружаем сам сервер, затем пробуем войти по RDP.
Инструкция выше мне не помогла, что мне делать чтобы исправить работу RDP?
К сожалению если к Вашем серверу по RDP приходит много запросов на подбор паролей, Ваш фаервол может не пускать вас на сервер, даже после действия выше. В таком случае мы должны выключить сам фаервол.
Чтобы это сделать, снова открываем сам фаервол и нажимаем на кнопку Turn Windows Defender Firewall on or of
А затем выключаем сам фаерволл как для пользователей, так и для администратора, нажав на кнопку в оба раздела Turn off Windows Defender Firewall (not recommended)
Нажимаем на кнопку ОК, перезагружаем сервер и проверяем.
Если данный вариант не сработал для вас, внизу вы можете нажать на ссылку и посмотреть инструкцию, как можно сменить RDP порт как это лучший вариант обеспечить безопасность сервера.
https://firstbyte.ru/manuals/kak-zamenit-rdp-port-v-windows-server-2012-2016-2019-2022/