Ошибка 1306 microsoft windows terminal

1306 ошибка microsoft windows terminalservices sessionbroker client

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов России Pyatilistnik.org. В прошлый раз мы с вами успешно научились решать ошибку «pfn list corrupt» в операционной системе Windows 10. Движемся дальше, в данной публикации я бы хотел с вами поделиться небольшим опытом поиска проблемы с подключением по RDP. В данной публикации мы рассмотрим вопрос, почему удаленный пользователь не может подключиться к RDS ферме Windows Server 2012 R2.

Описание проблемы

И так, есть RDS ферма построенная на базе Windows Server 2012 R2, состоящая из 15 хостов. В нее было добавлено еще 5 RDSH хостов. В компании люди работают с терминальным столом, как локально, так и удаленно, посредством подключения через VPN в корпоративную сеть и дальше уже к ферме. Вот как раз у таких VPN пользователей и стали возникать непонятные ситуации. При попытке подключения по RDP у них появлялась ошибка:

1. Не включен удаленный рабочий стол
2. Удаленный компьютер выключен
3. Удаленный компьютер не подключен к сети

Удостоверьтесь, что удаленный компьютер включен, подключен к сети и удаленный доступ к нему включен

Решение проблемы

Ошибка вроде очевидная, что не включен RDP доступ, если бы это был рядовой сервер я бы понял, но тут служба удаленного доступа точно работала и была включена, так как на данный сервер так же распространялась групповая политика делающая, это автоматически, я проверил применение GPO, все было хорошо. Первым делом я полез смотреть логи Windows, это можно сделать классическим методом или через модный Windows Admin Center.

Журналы которые нас будут интересовать находятся в таких расположениях:

• Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
• Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational
• Microsoft-Windows-TerminalServices-SessionBroker/Admin
• Microsoft-Windows-TerminalServices-SessionBroker/Operational
• Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational

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

Первое, что мне бросилось в глаза, это предупреждение с кодом ID 101:

Далее было такое предупреждение:

Далее нужно посмотреть, как RDCB брокеры взаимодействовали с сессией пользователя. В журнале «Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational» я обнаружил событие с кодом ID 1149, в котором я вижу, что определенный пользователь был успешно аутентифицирован на RDS ферме, он получил некий IP адрес.

Далее я стал изучать информацию из журнала «Microsoft-Windows-TerminalServices-SessionBroker/Operational». Тут я так же обнаружил, что брокер успешно ответил и отправил пользователя на определенный RDSH хост. Тут есть событие с кодом ID 787.

За ним я видел событие с кодом ID 801, которое имело вот такое сообщение:

тут видно, что брокер даже смог обнаружить предыдущую сессию на данном терминале, о чем говорит строка Disconnected Session Found = 0x0

И вы увидите событие с кодом ID 800:

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

Далее переходим в журнал «Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational» тут будет два события,об успешном общении RDS брокера и клиента.

Исходя из данной информации я точно вижу, что брокер подключения все успешно обработал и перенаправил пользователя на хост RDSH.

Что стоит проверить

Первым делом проверьте не пытается ли по какой-то причине ваш RDSH брокер, направить пользователя на хост находящийся в режиме стока (Drain Mode). По идее туда могут попадать, только те пользователи, у кого там была сессия, так как режим стока обрубает новые. Если такая старая сессия есть, то попробуйте ее завершить, это можно сделать из консоли управления RDS фермой, или же специализированными утилитами rwinsta и ее аналогами.

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

Далее если у вас есть оборудование фильтрующее трафик и ограничивающее порты при подключении к VPN, убедитесь, что они пропускают порт 3389. У меня как раз не хватало в правиле новой подсети. Проверить доступность порта можно через утилиту Telnet. Как выяснилось, все было банально просто. В результате чего у меня исчезла ошибка «Удаленному рабочему столу не удалось подключиться к удаленному компьютеру по одной из следующих причин». У вас не должно быть ошибок в виде «Не удалось открыть подключение к этому узлу, на порт 3389: Сбой подключения«.

Также в командной строке проверьте, что у вас правильно разрешаются имена, для этого есть команда nslookup, особенно актуально, кто балансирует подключения к брокеру по DNS, а не NLB. Если на RDSH сервере установлен антивирус, то так же посмотрите его монитор сетевой активности и логи, может быть он блокирует определенный вид трафика.

1306 ошибка microsoft windows terminalservices sessionbroker client

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I’m attempting to setup a Windows 2016 RDS Standard Deployment for Session Hosting. The layout is as follows:
RDS01 — RDS Connection Broker and Web Access
TS02 — RDS Session Host
TS03 — RDS Session Host

The domain these servers are part of has (1) Windows 2008 Server and (2) Windows 2016 Servers acting as DCs. The domain is running at Windows 2003 Functional Level.

All servers are on a single routed network with no firewall between them. All DNS A and PTR records for all servers exist and resolve on all hosts. All servers can be pinged by each other. In other words, there are no network connectivity issues.

I’ve setup the RDS deployment several times w/ the same results.

The Issue
I can login via the RDWeb interface on RDS01 from a Win10 desktop and connect to the published RDP desktop without issue (i.e. no error messages to the user) and no errors in the logs. When I try to directly RDP to RDS01, I successfully authenticate as a user (per the event log) but get an error stating that the user doesn’t have access to the system. In the event log I get event id 1306 with the message of «Remote Desktop Connection Broker Client failed to redirect the user . Error: NULL».

1306
0
2
104
13
0x2000000000000000

47

Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational
rds01.[redacted.domain]

—
—

If I RDP to RDS01 as an administrator, I get the same error message but the RDP session opens and presents the desktop on RDS01.

I can RDP directly to TS02 or TS03 and login as a user and open the RDP session. Redirection to some degree appears to be working in that I can disconnect a user session from TS02 and RDP to TS03 and the session is redirected back to TS02. The event logs on RDS01 record this happening as well.

What I’ve tried already
1. In searching this event 1306 issue, I found several posts with this exact same behavior in WS 2012/R2. Most «solutions» suggested point to the fact that the RDS Session Broker doesn’t have sufficient authority to look up the users AD group membership via the tokenGroupsGlobalAndUniversal attribute or AuthzInitializeContextFromSid API function which leverages the tokenGroupsGlobalAndUniversal attribute. (Example: https://social.technet.microsoft.com/Forums/windowsserver/en-US/29733a87-dbda-47bc-8b37-6eeac5ab5a0a/2012-rds-nonadministrators-can-not-access-vdi-pool?forum=winserverTS#97d883f1-7a64-4d02-9492-309638f92e79 )

The service is running as «Network Service» which does have network access via the Computer Object’s authority in AD. So following Microsoft’s instructions (https://support.microsoft.com/en-us/kb/331951), I’ve added RDS01 to both the Windows Authorization Access Group and Pre-Windows 2000 Compatibility Access groups and rebooted RDS01 with the same results.

2. I’ve verified the Windows Authorization Access Group has rights to read the tokenGroupsGlobalAndUniversal property/attribute on my test users and the computer objects of the servers.

3. I’ve setup an AD Service account following Microsoft’s instructions (https://support.microsoft.com/en-us/kb/842423) with a similarly described access issue. The service account user was added to the Windows Authorization Access Group. This was unsuccessfully as well w/ the same event 1306 error.

4. I ran the following powershell commands to verify access of the Connection Broker to the OU (https://technet.microsoft.com/en-us/library/jj215512.aspx#)

This failed so I ran the following to grant access

The Test-RDOUAccess then succeeded.

I repeated this for the OUs that contained the users and the server computer objects.

I’ve disabled all GPOs to ensure there’s no conflicts but have seen no change in the behavior or error messages.

With all that, I’ve exhausted every option that I can find to resolve this error to gain the expected functionality. As a work around for the moment, I’ve setup a round-robin DNS A record that points to TS02 and TS03 w/ a very short TTL. This gives the test users the ability to login and atleast test the desktop functionality.

Sorry for being so long winded with this but I thought it better to put all the cards on the table.

1306 ошибка microsoft windows terminalservices sessionbroker client

Вопрос

Не могу победить проблему. Имеется 2 сервера на server 2012- 1 контроллер домена(PDC) 2- терминальный сервер 1с(1server). Все работало как часы. Решил поднять дополнительный контроллер домена на 1c.Поднял роль и пошли ошибки при подключении к удаленному рабочему столу на 1server ошибка 1306,1296 и пользователи не могут подключиться к серверу 1s.Не стартовала служба. Удалил роль контроллера домена, служба стала стартовать, но пользователи не могут подключиться к серверу 1s.В логах 1306,1296 ошибки. После удаления роли посредника подключений к удаленному рабочему столу пользователей начинает пускать на сервер, но ошибки 1306,1296 остались. И при каждом подключении появляться на каждого пользователя.К уда копать? Из-за разницы во времени, могу отвечать с опозданием, заранее извиняюсь.

• Изменено Alexander Rusinov Moderator 30 марта 2015 г. 11:30 правка орфографии

Ответы

• Предложено в качестве ответа SQx Moderator 28 марта 2015 г. 10:50
• Помечено в качестве ответа max113 28 марта 2015 г. 13:00

Все ответы

1) Уточните какие компоненты терминального сервера установили на 1с(1server) ?

2) В случае если используете компонент «RD Connection Broker» на 1с(1server), уточните настройки (gpedit.msc):
——————-
Local Computer Group PolicyAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session Host:
RD Connection Broker =
——————-

На сторонних форумах в качестве решения предлагается применить:

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

Best Regards, Andrei .
Microsoft Certified Professional

• Изменено SQx Moderator 27 марта 2015 г. 15:02 добавлено

-Лицензирование удаленных рабочих столов

-Узел сеансов удаленных рабочих столов

-Веб доступ к удаленным рабочим столам

Connection Broker я удалил(без него происходит подключение)

Попробую посмотреть ключи реестра, о результатах напишу.

стояло значение 1.

При подключении к удаленному рабочему столу 1s все равно выходят эти

1296 При получении пакета перенаправления от посредника подключений к удаленному рабочему столу в клиенте посредника подключений произошла ошибка.

Ошибка:Посредник подключений к удаленному рабочему столу не готов к RPC

1306 Клиенту посредника подключений к удаленному рабочему столу не удалось перенапрвить пользователя

1296 При получении пакета перенаправления от посредника подключений к удаленному рабочему столу в клиенте посредника подключений произошла ошибка.

Ошибка:Посредник подключений к удаленному рабочему столу не готов к RPC

1306 Клиенту посредника подключений к удаленному рабочему столу не удалось перенапрвить пользователя

Ранее Вы писали, что «Connection Broker я удалил(без него происходит подключение)«, но по каким-то причинам он все же пытается его использовать.

Проверьте в локальной политике терминального сервера (gpedit.msc):

Local Computer Policy/Computer Configuration/Administrative Templates/Windows Components/Remote Desktop Services/Remote Desktop Session Host/RD Connection Broker/

чтобы везде было «not configured».

Best Regards, Andrei .
Microsoft Certified Professional

1) If you remove the Connection Broker while collections are still assigned, the collections can not properly be removed from the registry, and will therefore continue to populate in users’ RDWEB and RemoteApp / Desktop Connection lists.

2) In order to remove orphaned collection resources, first back up, then remove the expired collection entries under HKLMSOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerCentralPublishedResourcesPublishedFarms.

————————
получается так, что Вы удалили посредника, а коллекция сеансов еще назначено.

Best Regards, Andrei .
Microsoft Certified Professional

• Изменено SQx Moderator 28 марта 2015 г. 0:20 исправлено

Проверил политику терминального сервера:

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

Удалил ветку реестра HKLMSOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerCentralPublishedResourcesPublishedFarms.

При подключению к серверу все равно выдает эти ошибки.

В общих сведениях службы удаленных рабочих столов написано:

«Серверы посредников подключений к удаленному рабочему столу отсутствуют в пуле серверов. Для управлений развертыванием необходимо добавить все серверы развертывания в пул серверов.Чтобы создать новое развертывание ,запустите мастер добаывления ролей и компонентов и выберите устаноку служб удаленных рабочих столов.»

Когда я добавляю службу посредника , то клиенты не подключаются к серверу 1s.

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

файл логов 1s сервера с момента перезагрузки и попытки войти на удаленный рабочий стол:

Уровень,Дата и время,Источник,Код события,Категория задачи
Сведения,28.03.2015 13:13:29,Microsoft-Windows-TerminalServices-LocalSessionManager,24,Отсутствует,»Службы удаленных рабочих столов: Сеанс был отключен:

Пользователь: ***********int113
Код сеанса: 2
Адрес сети источника: »
Сведения,28.03.2015 13:13:15,Microsoft-Windows-TerminalServices-LocalSessionManager,22,Отсутствует,»Службы удаленных рабочих столов: Получено уведомление о запуске оболочки:

Пользователь: ***********int113
Код сеанса: 2
Адрес сети источника: »
Сведения,28.03.2015 13:13:15,Microsoft-Windows-TerminalServices-LocalSessionManager,21,Отсутствует,»Службы удаленных рабочих столов: Успешный вход в систему:

/Пользователь: ***********int113
Код сеанса: 2
Адрес сети источника: »
Сведения,28.03.2015 13:13:15,Microsoft-Windows-TerminalServices-RemoteConnectionManager,20482,Отсутствует,Справедливое распределение ресурсов сети для служб удаленных рабочих столов включено для учетной записи пользователя ***********int113 с весом 1.
Ошибка,28.03.2015 13:13:12,Microsoft-Windows-TerminalServices-SessionBroker-Client,1306,Клиент посредника подключений к удаленному рабочему столу обрабатывает запрос пользователя,»Клиенту посредника подключений к удаленному рабочему столу не удалось перенаправить пользователя ***********int113.
Ошибка: NULL»
Ошибка,28.03.2015 13:13:12,Microsoft-Windows-TerminalServices-SessionBroker-Client,1296,Клиент посредника подключений к удаленному рабочему столу обрабатывает запрос пользователя,»При получении пакета перенаправления от посредника подключений к удаленному рабочему столу в клиенте посредника подключений произошла ошибка.
Пользователь:***********int113
Ошибка: Посредник подключений к удаленному рабочему столу не готов к RPC.»
Подробно,28.03.2015 13:13:12,Microsoft-Windows-TerminalServices-SessionBroker-Client,1301,Клиент посредника подключений к удаленному рабочему столу обрабатывает запрос пользователя,»Клиент посредника подключений к удаленному рабочему столу получил запрос на перенаправление.
Пользователь: ***********int113
Версия RDP-клиента: 5″
Сведения,28.03.2015 13:13:12,Microsoft-Windows-TerminalServices-RemoteConnectionManager,1149,Отсутствует,»Службы удаленных рабочих столов: Успешная проверка подлинности пользователя:

Пользователь: int113
Домен: ***********
Адрес источника сети: »
Сведения,28.03.2015 13:13:03,Microsoft-Windows-TerminalServices-RemoteConnectionManager,261,Отсутствует,Прослушиватель RDP-Tcp получил соединение
Сведения,28.03.2015 13:11:09,Microsoft-Windows-TerminalServices-LocalSessionManager,22,Отсутствует,»Службы удаленных рабочих столов: Получено уведомление о запуске оболочки:

Пользователь: ***********администратор
Код сеанса: 1
Адрес сети источника: ЛОКАЛЬНЫЕ»
Сведения,28.03.2015 13:11:09,Microsoft-Windows-TerminalServices-RemoteConnectionManager,20482,Отсутствует,Справедливое распределение ресурсов сети для служб удаленных рабочих столов включено для учетной записи пользователя ***********Администратор с весом 1.
Сведения,28.03.2015 13:11:09,Microsoft-Windows-TerminalServices-LocalSessionManager,21,Отсутствует,»Службы удаленных рабочих столов: Успешный вход в систему:

/Пользователь: ***********администратор
Код сеанса: 1
Адрес сети источника: ЛОКАЛЬНЫЕ»

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

Hello,

This is my first post, and it’s more of a «this is what worked for us and I couldn’t find this fix ANYWHERE» thing.

We have recently setup a new RDS environment to replace a pathetic wheezing old TS system.

We are running 9 session host servers in three pools hosting three collections — A, B and C. All the session host servers appear in the pools, accept new connections, and apps are configured and working. No problems here.

We have 2 web front end servers in our DMZ, Port 443 is open, things work fine.

We have 2 gateway servers, also in our DMZ in a gateway farm. Work great, no problem. Connectivity is excellent, internal firewalls on but the necessary configuration has been done so everything is talking and happy.

We have two connection broker servers in a high availability configuration and a different namespace for the front end than the domain (we can’t use our internal domain name for our externally facing RDS farm).

However, we would get intermittent failures upon logging in, no matter what collection we were accessing.The web servers present the login page and we could successfully authenticate (using ADFS proxies in our DMZ back into the domain) against AD — I verified
this in the logs on the broker servers. The user would still fail to connect to the remote computer. The error we received was a generic «unable to connect to remote computer. If problem persists, contact your System Administrator» and the connection
broker would record the following 3 alerts:

Event 802: RD Connection Broker failed to process the connection request for user domainusername. Error: Element not found.

Event 1296: Remote Desktop Connection Broker Client failed while getting redirection packet from Connection Broker.
User : domainusername
Error: Element not found.

Event 1306: Remote Desktop Connection Broker Client failed to redirect the user domainusername. Error: NULL

The user can try again, but the same error would likely be thrown, although sometimes they can log in and connect.

I googled constantly. Some had success modifying GPO Default Domain Policy: Computer Configuration / Administrative Templates / Windows Components / Remote Desktop Services / Remote Desktop Session Host / RD Connection Broker / Use RD Connection Broker load
balancing — ENABLED. Didn’t help; backed it out.

Others had success modifying a registry key on the broker servers: HKLM – System – Current Control Set – Control – Terminal Server – WinStations – RDP-TCP – Security Layer changed from 1 to 0.I didn’t like doing this (not fully aware of the security «feature(s)»
this disabled). Made no difference — backed it out.

Deleting and recreating collections did not help. Tried adding the server farm to the «Windows Authorization Access Group» (really only helpful for systems that began as Win 2k boxes). No go.

Put in a call with Microsoft. They give me a hotfix (which makes me a bit dubious — I didn’t install it), and about 7 patches to run (which had been — our servers were up to date). I wasn’t feeling it.

So I fired up procmon and monitored tssdis.exe on the broker servers. According to procmon, everything was a success — except for two keys missing from the registry on both broker servers: HKLMSoftwarePoliciesMicrosoftSystemDNSClient. Procmon showed
that key could not be read. Googling was useless, so I decided to manually create the key. Failed — procmon showed the key name as «New Key #1» no matter what I called it. Deleted it and used the following powershell command to successfully create
the key: New-Item -Path HKLM:SoftwarePoliciesMicrosoftSystem -Name DNSclient -Value «Default Value»

The key was created. YAY! I still didn’t know what needed going in there, it was just an empty key. I ran procmon again, and got a clue: tssids was trying to read a value: «PrimaryDNSSuffix» and returning blank. OK — inside of the «DNSclients»
new key I created a new string value containing our internal domain name, doing this on both connection broker clients. The end result looked like this:

HKLM:SoftwarePoliciesMicrosoftSystemDNSClient — «PrimarydnsSuffix»  «yourdomainname.com»

INSTANTLY, everyone connected. I could access everything using my acct and my testing accounts. The errors cleared up in the event logs. The sun began shining and the IT gods were, for awhile, placated.

OK — if you are getting 802, 1296, and 1306 errors in RDS 2012 R2 — before lessening security, and before modifying global GPO settings, just check procmon against tssdis.exe on the broker service and see if that key is missing. It’s the only thing that
worked for us.

Photo by Campaign Creators on Unsplash

After activating a new management pack to monitor remote desktop services in SCOM, some servers started throwing alerts with Event ID 1306 from source TerminalServices-SessionBroker-Client in their eventlogs (Eventvwr -> Applications and services -> Microsoft -> Windows -> TerminalServices-SessionBroker-Client -> Operational).

The event description states that “Remote Desktop Connection Broker Client failed to redirect the user <username>. Error: NULL”:

What all the affected servers had in common: they had the Remote Desktop Session Host role installed but did not have any RDS Collections configured. So after adding an RDS Collection to each of the servers and a re-login, the error events stopped appearing and instead some informational events 1308 and 1301 stating that “RD Connection Broker Client processes a request from a user” showed up.

In case the errors still appear when an RDS Collection is already in place, you might try to change the collection’s security layer.

Therefore, go to the collection, choose Tasks -> Edit Properties and then click Security.  Now under Security Layer select RDP Security Layer:

That’s it, you should be done.

1306 ошибка microsoft windows terminalservices sessionbroker client

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов России Pyatilistnik.org. В прошлый раз мы с вами успешно научились решать ошибку «pfn list corrupt» в операционной системе Windows 10. Движемся дальше, в данной публикации я бы хотел с вами поделиться небольшим опытом поиска проблемы с подключением по RDP. В данной публикации мы рассмотрим вопрос, почему удаленный пользователь не может подключиться к RDS ферме Windows Server 2012 R2.

Описание проблемы

И так, есть RDS ферма построенная на базе Windows Server 2012 R2, состоящая из 15 хостов. В нее было добавлено еще 5 RDSH хостов. В компании люди работают с терминальным столом, как локально, так и удаленно, посредством подключения через VPN в корпоративную сеть и дальше уже к ферме. Вот как раз у таких VPN пользователей и стали возникать непонятные ситуации. При попытке подключения по RDP у них появлялась ошибка:

1. Не включен удаленный рабочий стол
2. Удаленный компьютер выключен
3. Удаленный компьютер не подключен к сети

Удостоверьтесь, что удаленный компьютер включен, подключен к сети и удаленный доступ к нему включен

Решение проблемы

Ошибка вроде очевидная, что не включен RDP доступ, если бы это был рядовой сервер я бы понял, но тут служба удаленного доступа точно работала и была включена, так как на данный сервер так же распространялась групповая политика делающая, это автоматически, я проверил применение GPO, все было хорошо. Первым делом я полез смотреть логи Windows, это можно сделать классическим методом или через модный Windows Admin Center.

Журналы которые нас будут интересовать находятся в таких расположениях:

• Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
• Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational
• Microsoft-Windows-TerminalServices-SessionBroker/Admin
• Microsoft-Windows-TerminalServices-SessionBroker/Operational
• Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational

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

Первое, что мне бросилось в глаза, это предупреждение с кодом ID 101:

Далее было такое предупреждение:

Далее нужно посмотреть, как RDCB брокеры взаимодействовали с сессией пользователя. В журнале «Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational» я обнаружил событие с кодом ID 1149, в котором я вижу, что определенный пользователь был успешно аутентифицирован на RDS ферме, он получил некий IP адрес.

Далее я стал изучать информацию из журнала «Microsoft-Windows-TerminalServices-SessionBroker/Operational». Тут я так же обнаружил, что брокер успешно ответил и отправил пользователя на определенный RDSH хост. Тут есть событие с кодом ID 787.

За ним я видел событие с кодом ID 801, которое имело вот такое сообщение:

тут видно, что брокер даже смог обнаружить предыдущую сессию на данном терминале, о чем говорит строка Disconnected Session Found = 0x0

И вы увидите событие с кодом ID 800:

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

Далее переходим в журнал «Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational» тут будет два события,об успешном общении RDS брокера и клиента.

Исходя из данной информации я точно вижу, что брокер подключения все успешно обработал и перенаправил пользователя на хост RDSH.

Что стоит проверить

Первым делом проверьте не пытается ли по какой-то причине ваш RDSH брокер, направить пользователя на хост находящийся в режиме стока (Drain Mode). По идее туда могут попадать, только те пользователи, у кого там была сессия, так как режим стока обрубает новые. Если такая старая сессия есть, то попробуйте ее завершить, это можно сделать из консоли управления RDS фермой, или же специализированными утилитами rwinsta и ее аналогами.

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

Далее если у вас есть оборудование фильтрующее трафик и ограничивающее порты при подключении к VPN, убедитесь, что они пропускают порт 3389. У меня как раз не хватало в правиле новой подсети. Проверить доступность порта можно через утилиту Telnet. Как выяснилось, все было банально просто. В результате чего у меня исчезла ошибка «Удаленному рабочему столу не удалось подключиться к удаленному компьютеру по одной из следующих причин». У вас не должно быть ошибок в виде «Не удалось открыть подключение к этому узлу, на порт 3389: Сбой подключения«.

Также в командной строке проверьте, что у вас правильно разрешаются имена, для этого есть команда nslookup, особенно актуально, кто балансирует подключения к брокеру по DNS, а не NLB. Если на RDSH сервере установлен антивирус, то так же посмотрите его монитор сетевой активности и логи, может быть он блокирует определенный вид трафика.

1306 ошибка microsoft windows terminalservices sessionbroker client

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I’m attempting to setup a Windows 2016 RDS Standard Deployment for Session Hosting. The layout is as follows:
RDS01 — RDS Connection Broker and Web Access
TS02 — RDS Session Host
TS03 — RDS Session Host

The domain these servers are part of has (1) Windows 2008 Server and (2) Windows 2016 Servers acting as DCs. The domain is running at Windows 2003 Functional Level.

All servers are on a single routed network with no firewall between them. All DNS A and PTR records for all servers exist and resolve on all hosts. All servers can be pinged by each other. In other words, there are no network connectivity issues.

I’ve setup the RDS deployment several times w/ the same results.

The Issue
I can login via the RDWeb interface on RDS01 from a Win10 desktop and connect to the published RDP desktop without issue (i.e. no error messages to the user) and no errors in the logs. When I try to directly RDP to RDS01, I successfully authenticate as a user (per the event log) but get an error stating that the user doesn’t have access to the system. In the event log I get event id 1306 with the message of «Remote Desktop Connection Broker Client failed to redirect the user . Error: NULL».

1306
0
2
104
13
0x2000000000000000

47

Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational
rds01.[redacted.domain]

—
—

If I RDP to RDS01 as an administrator, I get the same error message but the RDP session opens and presents the desktop on RDS01.

I can RDP directly to TS02 or TS03 and login as a user and open the RDP session. Redirection to some degree appears to be working in that I can disconnect a user session from TS02 and RDP to TS03 and the session is redirected back to TS02. The event logs on RDS01 record this happening as well.

What I’ve tried already
1. In searching this event 1306 issue, I found several posts with this exact same behavior in WS 2012/R2. Most «solutions» suggested point to the fact that the RDS Session Broker doesn’t have sufficient authority to look up the users AD group membership via the tokenGroupsGlobalAndUniversal attribute or AuthzInitializeContextFromSid API function which leverages the tokenGroupsGlobalAndUniversal attribute. (Example: https://social.technet.microsoft.com/Forums/windowsserver/en-US/29733a87-dbda-47bc-8b37-6eeac5ab5a0a/2012-rds-nonadministrators-can-not-access-vdi-pool?forum=winserverTS#97d883f1-7a64-4d02-9492-309638f92e79 )

The service is running as «Network Service» which does have network access via the Computer Object’s authority in AD. So following Microsoft’s instructions (https://support.microsoft.com/en-us/kb/331951), I’ve added RDS01 to both the Windows Authorization Access Group and Pre-Windows 2000 Compatibility Access groups and rebooted RDS01 with the same results.

2. I’ve verified the Windows Authorization Access Group has rights to read the tokenGroupsGlobalAndUniversal property/attribute on my test users and the computer objects of the servers.

3. I’ve setup an AD Service account following Microsoft’s instructions (https://support.microsoft.com/en-us/kb/842423) with a similarly described access issue. The service account user was added to the Windows Authorization Access Group. This was unsuccessfully as well w/ the same event 1306 error.

4. I ran the following powershell commands to verify access of the Connection Broker to the OU (https://technet.microsoft.com/en-us/library/jj215512.aspx#)

This failed so I ran the following to grant access

The Test-RDOUAccess then succeeded.

I repeated this for the OUs that contained the users and the server computer objects.

I’ve disabled all GPOs to ensure there’s no conflicts but have seen no change in the behavior or error messages.

With all that, I’ve exhausted every option that I can find to resolve this error to gain the expected functionality. As a work around for the moment, I’ve setup a round-robin DNS A record that points to TS02 and TS03 w/ a very short TTL. This gives the test users the ability to login and atleast test the desktop functionality.

Sorry for being so long winded with this but I thought it better to put all the cards on the table.

1306 ошибка microsoft windows terminalservices sessionbroker client

Вопрос

Не могу победить проблему. Имеется 2 сервера на server 2012- 1 контроллер домена(PDC) 2- терминальный сервер 1с(1server). Все работало как часы. Решил поднять дополнительный контроллер домена на 1c.Поднял роль и пошли ошибки при подключении к удаленному рабочему столу на 1server ошибка 1306,1296 и пользователи не могут подключиться к серверу 1s.Не стартовала служба. Удалил роль контроллера домена, служба стала стартовать, но пользователи не могут подключиться к серверу 1s.В логах 1306,1296 ошибки. После удаления роли посредника подключений к удаленному рабочему столу пользователей начинает пускать на сервер, но ошибки 1306,1296 остались. И при каждом подключении появляться на каждого пользователя.К уда копать? Из-за разницы во времени, могу отвечать с опозданием, заранее извиняюсь.

• Изменено Alexander Rusinov Moderator 30 марта 2015 г. 11:30 правка орфографии

Ответы

• Предложено в качестве ответа SQx Moderator 28 марта 2015 г. 10:50
• Помечено в качестве ответа max113 28 марта 2015 г. 13:00

Все ответы

1) Уточните какие компоненты терминального сервера установили на 1с(1server) ?

2) В случае если используете компонент «RD Connection Broker» на 1с(1server), уточните настройки (gpedit.msc):
——————-
Local Computer Group PolicyAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session Host:
RD Connection Broker =
——————-

На сторонних форумах в качестве решения предлагается применить:

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

Best Regards, Andrei .
Microsoft Certified Professional

• Изменено SQx Moderator 27 марта 2015 г. 15:02 добавлено

-Лицензирование удаленных рабочих столов

-Узел сеансов удаленных рабочих столов

-Веб доступ к удаленным рабочим столам

Connection Broker я удалил(без него происходит подключение)

Попробую посмотреть ключи реестра, о результатах напишу.

стояло значение 1.

При подключении к удаленному рабочему столу 1s все равно выходят эти

1296 При получении пакета перенаправления от посредника подключений к удаленному рабочему столу в клиенте посредника подключений произошла ошибка.

Ошибка:Посредник подключений к удаленному рабочему столу не готов к RPC

1306 Клиенту посредника подключений к удаленному рабочему столу не удалось перенапрвить пользователя

1296 При получении пакета перенаправления от посредника подключений к удаленному рабочему столу в клиенте посредника подключений произошла ошибка.

Ошибка:Посредник подключений к удаленному рабочему столу не готов к RPC

1306 Клиенту посредника подключений к удаленному рабочему столу не удалось перенапрвить пользователя

Ранее Вы писали, что «Connection Broker я удалил(без него происходит подключение)«, но по каким-то причинам он все же пытается его использовать.

Проверьте в локальной политике терминального сервера (gpedit.msc):

Local Computer Policy/Computer Configuration/Administrative Templates/Windows Components/Remote Desktop Services/Remote Desktop Session Host/RD Connection Broker/

чтобы везде было «not configured».

Best Regards, Andrei .
Microsoft Certified Professional

1) If you remove the Connection Broker while collections are still assigned, the collections can not properly be removed from the registry, and will therefore continue to populate in users’ RDWEB and RemoteApp / Desktop Connection lists.

2) In order to remove orphaned collection resources, first back up, then remove the expired collection entries under HKLMSOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerCentralPublishedResourcesPublishedFarms.

————————
получается так, что Вы удалили посредника, а коллекция сеансов еще назначено.

Best Regards, Andrei .
Microsoft Certified Professional

• Изменено SQx Moderator 28 марта 2015 г. 0:20 исправлено

Проверил политику терминального сервера:

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

Удалил ветку реестра HKLMSOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerCentralPublishedResourcesPublishedFarms.

При подключению к серверу все равно выдает эти ошибки.

В общих сведениях службы удаленных рабочих столов написано:

«Серверы посредников подключений к удаленному рабочему столу отсутствуют в пуле серверов. Для управлений развертыванием необходимо добавить все серверы развертывания в пул серверов.Чтобы создать новое развертывание ,запустите мастер добаывления ролей и компонентов и выберите устаноку служб удаленных рабочих столов.»

Когда я добавляю службу посредника , то клиенты не подключаются к серверу 1s.

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

файл логов 1s сервера с момента перезагрузки и попытки войти на удаленный рабочий стол:

Уровень,Дата и время,Источник,Код события,Категория задачи
Сведения,28.03.2015 13:13:29,Microsoft-Windows-TerminalServices-LocalSessionManager,24,Отсутствует,»Службы удаленных рабочих столов: Сеанс был отключен:

Пользователь: ***********int113
Код сеанса: 2
Адрес сети источника: »
Сведения,28.03.2015 13:13:15,Microsoft-Windows-TerminalServices-LocalSessionManager,22,Отсутствует,»Службы удаленных рабочих столов: Получено уведомление о запуске оболочки:

Пользователь: ***********int113
Код сеанса: 2
Адрес сети источника: »
Сведения,28.03.2015 13:13:15,Microsoft-Windows-TerminalServices-LocalSessionManager,21,Отсутствует,»Службы удаленных рабочих столов: Успешный вход в систему:

/Пользователь: ***********int113
Код сеанса: 2
Адрес сети источника: »
Сведения,28.03.2015 13:13:15,Microsoft-Windows-TerminalServices-RemoteConnectionManager,20482,Отсутствует,Справедливое распределение ресурсов сети для служб удаленных рабочих столов включено для учетной записи пользователя ***********int113 с весом 1.
Ошибка,28.03.2015 13:13:12,Microsoft-Windows-TerminalServices-SessionBroker-Client,1306,Клиент посредника подключений к удаленному рабочему столу обрабатывает запрос пользователя,»Клиенту посредника подключений к удаленному рабочему столу не удалось перенаправить пользователя ***********int113.
Ошибка: NULL»
Ошибка,28.03.2015 13:13:12,Microsoft-Windows-TerminalServices-SessionBroker-Client,1296,Клиент посредника подключений к удаленному рабочему столу обрабатывает запрос пользователя,»При получении пакета перенаправления от посредника подключений к удаленному рабочему столу в клиенте посредника подключений произошла ошибка.
Пользователь:***********int113
Ошибка: Посредник подключений к удаленному рабочему столу не готов к RPC.»
Подробно,28.03.2015 13:13:12,Microsoft-Windows-TerminalServices-SessionBroker-Client,1301,Клиент посредника подключений к удаленному рабочему столу обрабатывает запрос пользователя,»Клиент посредника подключений к удаленному рабочему столу получил запрос на перенаправление.
Пользователь: ***********int113
Версия RDP-клиента: 5″
Сведения,28.03.2015 13:13:12,Microsoft-Windows-TerminalServices-RemoteConnectionManager,1149,Отсутствует,»Службы удаленных рабочих столов: Успешная проверка подлинности пользователя:

Пользователь: int113
Домен: ***********
Адрес источника сети: »
Сведения,28.03.2015 13:13:03,Microsoft-Windows-TerminalServices-RemoteConnectionManager,261,Отсутствует,Прослушиватель RDP-Tcp получил соединение
Сведения,28.03.2015 13:11:09,Microsoft-Windows-TerminalServices-LocalSessionManager,22,Отсутствует,»Службы удаленных рабочих столов: Получено уведомление о запуске оболочки:

Пользователь: ***********администратор
Код сеанса: 1
Адрес сети источника: ЛОКАЛЬНЫЕ»
Сведения,28.03.2015 13:11:09,Microsoft-Windows-TerminalServices-RemoteConnectionManager,20482,Отсутствует,Справедливое распределение ресурсов сети для служб удаленных рабочих столов включено для учетной записи пользователя ***********Администратор с весом 1.
Сведения,28.03.2015 13:11:09,Microsoft-Windows-TerminalServices-LocalSessionManager,21,Отсутствует,»Службы удаленных рабочих столов: Успешный вход в систему:

/Пользователь: ***********администратор
Код сеанса: 1
Адрес сети источника: ЛОКАЛЬНЫЕ»

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

Обновлено 11.10.2021

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов в рунете Pyatilistnik.org🔝. В прошлый раз мы с вами разобрали «Как поменять часовой пояс в Windows Server 2019». Идем далее, сегодня у меня случился день траблшутинга с терминальной фермой. Произошел инцидент, в результате которого отвалился LUN, где располагался ряд виртуальных машин из RDS фермы. После восстановления работоспособности, стали поступать жалобы от 10% людей, что они не могут подключиться на терминал, в логах на брокерах я увидел огромное количество ошибок с текстом «Cannot create another system semaphore«. Давайте разбираться в чем дело и как все починить.

Ошибки Cannot create another system semaphore и 0x80070064

Как я и писал выше у меня есть RDS HA ферма на базе Windows Server 2019, после аварии 6 хостов вышли из строя и вновь были восстановлены. Успокоившись, что все хороша я продолжил заниматься делами, начали поступать некоторые ошибки подключения к терминалу. Ошибка была стандартная:

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

Проверив под тестовой учетной записью, я так же получил данную ошибку. Первое, что нужно делать в такой ситуации, это делать диагностику на активном брокере подключений. Для начала заходим в журнал событий Microsoft-Windows-TerminalServices-SessionBroker/Admin. Он весь был забит событиями 802:

RD Connection Broker failed to process the connection request for user name. Error: Cannot create another system semaphore.

Код ID 802 говорит, о том, что брокеру не удалось переправить запрос пользователя на RDSH хост.

На неактивном брокере была куча растущих ошибок ID 2308:

ID 230: Failed to retrieve server status, Desktop term139.root.pyatilistnik.org, Collection Term-Coll, error code 0x80070064

Данная ошибка означает: Ваш сеанс служб удаленных рабочих столов завершен. Соединение с удаленным компьютером было потеряно, возможно, из-за проблем с сетевым подключением. Попробуйте снова подключиться к удаленному компьютеру. Если проблема не исчезнет, ​​обратитесь к сетевому администратору или в службу технической поддержки.

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

Переходим в журнал Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational. Там вы можете увидеть ошибки ID 1306.

ID 1306: Remote Desktop Connection Broker Client failed to redirect the user. Error: NULL

И ошибку 1296:

Remote Desktop Connection Broker Client failed while getting redirection packet from Connection Broker. User : name. Error: Element not found

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

Как восстановить работу RDS фермы

В моем случае рецепт был очень простой. Вам необходимо повторно переустановить на сбойных RDSH хостах роль подключения 💪, для этого откройте оснастку управления RDS фермой и попробуйте добавить сбойные хосты заново в состав.

✅Если у вас они уже добавлены, то попробуйте их корректно удалить сначала

Выберите свою коллекцию и в разделе «Host Servers» нажмите «Tasks — Add RD Session Host Servers«.

Выбираем нужный сервер и переносим его в правую область.

Соглашаемся, что будет установлена или переустановлена роль, если потребуется перезагрузка, то сделать ее.

Далее дожидаемся успешного добавления хоста в RDS ферму, после чего ошибки «error code 0x80070064» и «successfully added rdsh host»

Дополнительно, что еще можно проверить

• ✅ Обязательно проверьте на конечных RDSH хостах, что там просто включена возможность подключения по RDP. Я уже подробно об этом останавливался в статье, о том как удаленно или локально это проверить. Главное, чтобы стояла заветная галочка

• ✅ Если подключения разрешены, а ошибка все еще появляется, проверьте доступность порта 3389, через PowerShell или Telnet.
• ✅ Следующим пунктом вам нужно попробовать перенести сбойные хосты в другую OU, на которую не распространяются общие групповые политики RDS фермы, имеется ввиду, GPO производящие настройки RDP подключений. Переносите их в другое организационное подразделение, обновляете групповую политику и перезагружаете сервер, так же можете вручную удалить действие данных политик. После данных манипуляций пробуем вернуть RDSH хосты в OU, накатить на них политики и вернуть в RDS ферму.
• ✅ Заново развернуть сбойные RDSH хосты из шаблонов (Переустановка)
• ✅ Очень радикальное решение — это удаление коллекции и ее пересоздание, надеюсь, что у вас до того не дойдет
• ✅Попробуйте на сбойном хосте вручную добавить в список брокеров ваши сервера. Найти Это можно или в gpedit.msc или в отдельной GPO

Через запятую пишем тут полное FQDN имя.

На этом у меня все. С вами был Иван Сёмин, автор и создатель IT портала Pyatilistnik.org.

Hello,

This is my first post, and it’s more of a «this is what worked for us and I couldn’t find this fix ANYWHERE» thing.

We have recently setup a new RDS environment to replace a pathetic wheezing old TS system.

We are running 9 session host servers in three pools hosting three collections — A, B and C. All the session host servers appear in the pools, accept new connections, and apps are configured and working. No problems here.

We have 2 web front end servers in our DMZ, Port 443 is open, things work fine.

We have 2 gateway servers, also in our DMZ in a gateway farm. Work great, no problem. Connectivity is excellent, internal firewalls on but the necessary configuration has been done so everything is talking and happy.

We have two connection broker servers in a high availability configuration and a different namespace for the front end than the domain (we can’t use our internal domain name for our externally facing RDS farm).

However, we would get intermittent failures upon logging in, no matter what collection we were accessing.The web servers present the login page and we could successfully authenticate (using ADFS proxies in our DMZ back into the domain) against AD — I verified
this in the logs on the broker servers. The user would still fail to connect to the remote computer. The error we received was a generic «unable to connect to remote computer. If problem persists, contact your System Administrator» and the connection
broker would record the following 3 alerts:

Event 802: RD Connection Broker failed to process the connection request for user domainusername. Error: Element not found.

Event 1296: Remote Desktop Connection Broker Client failed while getting redirection packet from Connection Broker.
User : domainusername
Error: Element not found.

Event 1306: Remote Desktop Connection Broker Client failed to redirect the user domainusername. Error: NULL

The user can try again, but the same error would likely be thrown, although sometimes they can log in and connect.

I googled constantly. Some had success modifying GPO Default Domain Policy: Computer Configuration / Administrative Templates / Windows Components / Remote Desktop Services / Remote Desktop Session Host / RD Connection Broker / Use RD Connection Broker load
balancing — ENABLED. Didn’t help; backed it out.

Others had success modifying a registry key on the broker servers: HKLM – System – Current Control Set – Control – Terminal Server – WinStations – RDP-TCP – Security Layer changed from 1 to 0.I didn’t like doing this (not fully aware of the security «feature(s)»
this disabled). Made no difference — backed it out.

Deleting and recreating collections did not help. Tried adding the server farm to the «Windows Authorization Access Group» (really only helpful for systems that began as Win 2k boxes). No go.

Put in a call with Microsoft. They give me a hotfix (which makes me a bit dubious — I didn’t install it), and about 7 patches to run (which had been — our servers were up to date). I wasn’t feeling it.

So I fired up procmon and monitored tssdis.exe on the broker servers. According to procmon, everything was a success — except for two keys missing from the registry on both broker servers: HKLMSoftwarePoliciesMicrosoftSystemDNSClient. Procmon showed
that key could not be read. Googling was useless, so I decided to manually create the key. Failed — procmon showed the key name as «New Key #1» no matter what I called it. Deleted it and used the following powershell command to successfully create
the key: New-Item -Path HKLM:SoftwarePoliciesMicrosoftSystem -Name DNSclient -Value «Default Value»

The key was created. YAY! I still didn’t know what needed going in there, it was just an empty key. I ran procmon again, and got a clue: tssids was trying to read a value: «PrimaryDNSSuffix» and returning blank. OK — inside of the «DNSclients»
new key I created a new string value containing our internal domain name, doing this on both connection broker clients. The end result looked like this:

HKLM:SoftwarePoliciesMicrosoftSystemDNSClient — «PrimarydnsSuffix»  «yourdomainname.com»

INSTANTLY, everyone connected. I could access everything using my acct and my testing accounts. The errors cleared up in the event logs. The sun began shining and the IT gods were, for awhile, placated.

OK — if you are getting 802, 1296, and 1306 errors in RDS 2012 R2 — before lessening security, and before modifying global GPO settings, just check procmon against tssdis.exe on the broker service and see if that key is missing. It’s the only thing that
worked for us.

Обновлено 11.10.2021

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов в рунете Pyatilistnik.org🔝. В прошлый раз мы с вами разобрали «Как поменять часовой пояс в Windows Server 2019». Идем далее, сегодня у меня случился день траблшутинга с терминальной фермой. Произошел инцидент, в результате которого отвалился LUN, где располагался ряд виртуальных машин из RDS фермы. После восстановления работоспособности, стали поступать жалобы от 10% людей, что они не могут подключиться на терминал, в логах на брокерах я увидел огромное количество ошибок с текстом «Cannot create another system semaphore«. Давайте разбираться в чем дело и как все починить.

Ошибки Cannot create another system semaphore и 0x80070064

Как я и писал выше у меня есть RDS HA ферма на базе Windows Server 2019, после аварии 6 хостов вышли из строя и вновь были восстановлены. Успокоившись, что все хороша я продолжил заниматься делами, начали поступать некоторые ошибки подключения к терминалу. Ошибка была стандартная:

Проверив под тестовой учетной записью, я так же получил данную ошибку. Первое, что нужно делать в такой ситуации, это делать диагностику на активном брокере подключений. Для начала заходим в журнал событий Microsoft-Windows-TerminalServices-SessionBroker/Admin. Он весь был забит событиями 802:

Код ID 802 говорит, о том, что брокеру не удалось переправить запрос пользователя на RDSH хост.

На неактивном брокере была куча растущих ошибок ID 2308:

Данная ошибка означает: Ваш сеанс служб удаленных рабочих столов завершен. Соединение с удаленным компьютером было потеряно, возможно, из-за проблем с сетевым подключением. Попробуйте снова подключиться к удаленному компьютеру. Если проблема не исчезнет, ​​обратитесь к сетевому администратору или в службу технической поддержки.

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

Переходим в журнал Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational. Там вы можете увидеть ошибки ID 1306.

И ошибку 1296:

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

Как восстановить работу RDS фермы

В моем случае рецепт был очень простой. Вам необходимо повторно переустановить на сбойных RDSH хостах роль подключения 💪, для этого откройте оснастку управления RDS фермой и попробуйте добавить сбойные хосты заново в состав.

Выберите свою коллекцию и в разделе «Host Servers» нажмите «Tasks — Add RD Session Host Servers«.

Выбираем нужный сервер и переносим его в правую область.

Соглашаемся, что будет установлена или переустановлена роль, если потребуется перезагрузка, то сделать ее.

Далее дожидаемся успешного добавления хоста в RDS ферму, после чего ошибки «error code 0x80070064» и «successfully added rdsh host»

Дополнительно, что еще можно проверить

• ✅ Обязательно проверьте на конечных RDSH хостах, что там просто включена возможность подключения по RDP. Я уже подробно об этом останавливался в статье, о том как удаленно или локально это проверить. Главное, чтобы стояла заветная галочка

• ✅ Если подключения разрешены, а ошибка все еще появляется, проверьте доступность порта 3389, через PowerShell или Telnet.
• ✅ Следующим пунктом вам нужно попробовать перенести сбойные хосты в другую OU, на которую не распространяются общие групповые политики RDS фермы, имеется ввиду, GPO производящие настройки RDP подключений. Переносите их в другое организационное подразделение, обновляете групповую политику и перезагружаете сервер, так же можете вручную удалить действие данных политик. После данных манипуляций пробуем вернуть RDSH хосты в OU, накатить на них политики и вернуть в RDS ферму.
• ✅ Заново развернуть сбойные RDSH хосты из шаблонов (Переустановка)
• ✅ Очень радикальное решение — это удаление коллекции и ее пересоздание, надеюсь, что у вас до того не дойдет
• ✅Попробуйте на сбойном хосте вручную добавить в список брокеров ваши сервера. Найти Это можно или в gpedit.msc или в отдельной GPO

Через запятую пишем тут полное FQDN имя.

На этом у меня все. С вами был Иван Сёмин, автор и создатель IT портала Pyatilistnik.org.