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

Hi,

I recently installed a RDS farm on Windows Server 2016 with two High Available RD Brokers (RR) with their database on two SQL Server 2016 in AlwaysOn Availability mode.

Last night the backup of the SQL Server databases created an error on the broker servers, that they were no longer able to connect to the SQL server.

«The Remote Desktop Connection Broker server detected that the database is not available and will notify all Remote Desktop Connection Broker plug-ins.»

followed by

«Connection Broker cannot connect to SQL database. Please ensure policy and firewall settings are properly configured to allow connections to the SQL Server. If the SQL Server is configured to listen on a dynamic port either change the port to a static
TCP port or enable outgoing UDP traffic to port 1434 from the Connection Broker»

The problem lasted only for 30 seconds, because after 30 seconds I saw the following in the eventlog.

«The Remote Desktop Connection Broker server detected that the database is available.»

So everything seems ok, but this morning I was not able to connect to the RDS Session hosts via the brokers.

«Remote Desktop Connection Broker Client failed while getting redirection packet from Connection Broker.
User : xxxxyyyyyyy
Error: Remote Desktop Connection Broker is not ready for RPC communication.»

I restarted the Broker service on both service and everything worked again, but I would like this not to happen in the first place of course.

I have a few questions:

— Is the RPC error related to the SQL errors a few hours earlier, eventhough there was an event that SQL connections were restored?

— If there is a relation with the SQL connectivity errors during backup, is there something I can do about this (except ofcourse not backing up the databases)? For example, can it be solved with some higher timeout settings, if possible at all.

— If there is no relation with the SQL connectivity errors during backup, what else could be causing the RPC errors on both Broker servers?

Thanks in advance.

Jos

Обновлено 12.12.2018

Добрый день! Уважаемые читатели и гости, одного из крупнейших IT блогов в русскоязычном сегменте Pyatilistnik.org. В прошлый раз мы с вами разобрали причины, почему не удается подключиться к удаленному столу по RDP. В сегодняшней статье будет очень похожая ситуация, но в 800 раз масштабнее, где не удается корректно подключиться к RDS ферме и, где посредник подключений к удаленному рабочему столу не активен.

Описание проблемы с неактивным брокером RDS

Есть RDS ферма в режиме высокой доступности, состоящая из 2 серверов с ролью «Посредник подключений к удаленному рабочему столу (RD Connection Broker)» и 15 серверов с ролью «Узел сеансов удаленных рабочих столов (RD Session Host)», в какой-то момент в локальной сети произошла небольшая авария и локальная сеть пропадала на некоторое время. Сеть поднялась, пользователи начали пытаться работать в привычном режиме. Так как RDS ферма, очень важный механизм в работе на который заведены многие бизнес процессы, то все ринулись в первую очередь на него. При попытке подключения у пользователей был просто черный экран на удаленном рабочем столе, я вам уже рассказывал как он лечиться, но в случае с RDS, это не помогало, кроме, как перезапуска процесса explorer.

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

Алгоритм решения проблем на RDS ферме

Первым делом я нажал сочетание клавиш CTRL+SHIFT+ESC, что дало вызвать диспетчер задач Windows. В нем перейдите на вкладку «Пользователи» и найдите себя, разверните процессы и найдите там проводник, щелкните по нему правым кликом и выберите перезапустить, если это не поможет, то снимите с него задачу.

После чего нажмите меню «Файл — Запустить новую задачу»

В окне выполнить введите explorer.exe и нажмите Enter, в результате чего у вас будет пере запущен проводник Windows и должен появится рабочий стол,

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

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

на всякий случай я еще перезагрузил по очереди контроллеры домена.

Как говорится семь бед, один ресет. Так как у меня кластерный вариант, то я попытался по очереди перезагрузить RD Connection Broker. Для этого у вас должна быть собрана консоль управления RDS фермой, как я вам рассказывал. В обзоре развертывания нажмите кнопку «Задачи» и выберите пункт «Выберите сервер управления удаленным рабочим столов». После того как передали функцию управления, то перезапускаем первый «Посредник подключений к удаленному рабочему столу».

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

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

В пункте «Параметры высокого уровня доступности» проверьте, что у вас правильное DNS-имя и в строке подключения указан путь до нужной базы данных. Там есть имя сервера я его выделил стрелкой. Проверьте, чтобы он так же отвечал по DNS-имени.

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

На вкладке Aliase убедитесь, что выставлены правильные настройки. У меня в организации за базы данных отвечает другой специалист, он сказал, что подключения с двух посредников подключений к удаленному рабочему столу имеются и тут меня осенило, так как были не доступны контроллеры домена да и вообще сетка, то возможно в базе остались какие-то зависшие подключения с брокеров и хостов. Я попросил базиста перевести базу в offline и убить все текущие подключения. После этих действий, у меня все заработало, но можно еще попробовать еще раз дернуть RD Connection Broker. путем перенастройки выбора активного.

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

Там мне удалось обнаружить вот такие вот события:

Событие с кодом 802: RD Connection Broker failed to process the connection request for user.
Failed while checking for disconnected session.
Error: Element not found.

Как видно, что терялась связь с контроллерами домена и DNS-серверами. Надеюсь вы поняли как решается ситуация, когда посредник подключений к удаленному рабочему столу не активен или не работает. Если будут вопросы, то пишите их в комментариях, а с вами был Иван Семин, автор и создатель IT блога Pyatilistnik.org.

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 подключается к серверу, но ошибками,хотя посредник удален,его нет.

• Remove From My Forums

• Question

• Seeing the error listed here.

  The Remote Desktop Connection Broker server could not enumerate the targets for the provider named NULL from the database.

  Pooled virtual desktop collection name: NULL
  Error: Error code: 0xFFFFFFFF.

  Broker and Hyper-V are on the same physical machine.

  Any ideas on where to start troubleshooting this?

  Used the happy wizard to create everything, and got no errors.
  I have created a small pool collection, and given rights to domain users. Everything «looks» good.

  • Edited by

    Wednesday, September 5, 2012 4:57 PM
    Clarity

Answers

• Solution:

  http://support.microsoft.com/kb/331951

  Adding the broker to «Windows Authorization Access Group»

  This is only needed if the Domain the system is connected to was setup with as Pre-Windows 2000 Compatible.

  • Marked as answer by
    The_Ron
    Friday, September 14, 2012 8:13 PM

Проявилась проблема.

server 2019

подняты службы RDS (стандартное развертывание на одном сервере)

После перезагрузки сервера невозможно зайти по рдп.

Сообщение ошибки: «Не удается подключиться к удаленному компьютеру. Повторите попытку подключения. Если проблема повторится, обратитесь к владельцу удаленного компьютера или администратору сети.»

Можно зайти только локально, либо через IPMI консоль

События в диспетчере серверов показывают следующее:

код 1296

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

код 1306 

Клиенту посредника подключений к удаленному рабочему столу не удалось перенаправить пользователя ———- 
Ошибка: NULL

Помогает перезапуск всех служб подряд 

служба лицензирования, Локатор удаленного вызова процедур (RPC), служба посредник подключения к удаленному раб. столу, Перенаправитель портов пользовательского режима служб удаленных рабочих столов, Служба инициатора Майкрософт iSCSI(тоже
после ребута сервера, другой сервак теряет диск ICSI, и пока службу не рестартнем, он его не увидит). 

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

Если все это проделать, то доступ восстанавливается.

Пробовал делать DISM /Online /Cleanup-Image /RestoreHealth с указанием источника пакета wim (без него он не делал), писал что восстановлено, но проблема осталась.

Кто сталкивался. куда смотреть, копать? что делать? 

• Remove From My Forums

• Вопрос

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

  • Изменено

    30 марта 2015 г. 11:30
    правка орфографии

Ответы

• ФУХ, тема закрыта,победил.В чем была причина так и не понял, танцы с бубном.Огромное спасибо за советы.Пробовал разные варианты со всех форумов,видимо какой-то помог.Правда пришлось восстановить ветку реестра,которую
  удалил.Сервер заработал в штатном режиме,ошибка не появляется.Правда возникли проблемы с лицензиями, перестал их видеть,но через локальные политики  поправил.Еще раз огромное спасибо.

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

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 <domain><test
user>.  Error: NULL».  

— <Event xmlns=»http://schemas.microsoft.com/win/2004/08/events/event»>
— <System>
  <Provider Name=»Microsoft-Windows-TerminalServices-SessionBroker-Client» Guid=»{2184B5C9-1C83-4304-9C58-A9E76F718993}» />
  <EventID>1306</EventID>
  <Version>0</Version>
  <Level>2</Level>
  <Task>104</Task>
  <Opcode>13</Opcode>
  <Keywords>0x2000000000000000</Keywords>
  <TimeCreated SystemTime=»2016-12-29T16:47:27.634726700Z» />
  <EventRecordID>47</EventRecordID>
  <Correlation ActivityID=»{F4209120-29ED-44E4-845A-25A2570F0000}» />
  <Execution ProcessID=»828″ ThreadID=»3668″ />
  <Channel>Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational</Channel>
  <Computer>rds01.[redacted.domain]</Computer>
  <Security UserID=»S-1-5-20″ />
  </System>
— <UserData>
— <EventXML xmlns=»Event_NS»>
  <param1>[redacted.domain]</param1>
  <param2>[redacted.user]</param2>
  <param3>NULL</param3>
  </EventXML>
  </UserData>
  </Event>

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#)

Test-RDOUAccess -Domain [redacted.domain] -OU "Computers" -ConnectionBroker rds01.[redacted.domain] -verbose

This failed so I ran the following to grant access

Grant-RDOUAccess -Domain watsons.local -OU "Computers" -ConnectionBroker rds01.watsons.local -verbose 

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.

I’m open to any and all suggestions.

Thx!

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 <domain><test
user>.  Error: NULL».  

— <Event xmlns=»http://schemas.microsoft.com/win/2004/08/events/event»>
— <System>
  <Provider Name=»Microsoft-Windows-TerminalServices-SessionBroker-Client» Guid=»{2184B5C9-1C83-4304-9C58-A9E76F718993}» />
  <EventID>1306</EventID>
  <Version>0</Version>
  <Level>2</Level>
  <Task>104</Task>
  <Opcode>13</Opcode>
  <Keywords>0x2000000000000000</Keywords>
  <TimeCreated SystemTime=»2016-12-29T16:47:27.634726700Z» />
  <EventRecordID>47</EventRecordID>
  <Correlation ActivityID=»{F4209120-29ED-44E4-845A-25A2570F0000}» />
  <Execution ProcessID=»828″ ThreadID=»3668″ />
  <Channel>Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational</Channel>
  <Computer>rds01.[redacted.domain]</Computer>
  <Security UserID=»S-1-5-20″ />
  </System>
— <UserData>
— <EventXML xmlns=»Event_NS»>
  <param1>[redacted.domain]</param1>
  <param2>[redacted.user]</param2>
  <param3>NULL</param3>
  </EventXML>
  </UserData>
  </Event>

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#)

Test-RDOUAccess -Domain [redacted.domain] -OU "Computers" -ConnectionBroker rds01.[redacted.domain] -verbose

This failed so I ran the following to grant access

Grant-RDOUAccess -Domain watsons.local -OU "Computers" -ConnectionBroker rds01.watsons.local -verbose 

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.

I’m open to any and all suggestions.

Thx!

Проявилась проблема.
server 2019
подняты службы RDS (стандартное развертывание на одном сервере)
После перезагрузки сервера невозможно зайти по рдп.
Сообщение ошибки:

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

Можно зайти только локально, либо через IPMI консоль
События в диспетчере серверов показывают следующее:

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

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

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

Ранее помогал перезапуск следующих служб подряд

служба лицензирования, Локатор удаленного вызова процедур (RPC), служба посредник подключения к удаленному раб. столу, Перенаправитель портов пользовательского режима служб удаленных рабочих столов, Служба инициатора Майкрософт iSCSI(тоже после ребута сервера, другой сервак теряет диск ICSI, и пока службу не рестартнем, он его не увидит).

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

Если все это проделать, то доступ восстанавливается.

Пробовал делать DISM /Online /Cleanup-Image /RestoreHealth с указанием источника пакета wim (без него он не делал), писал что восстановлено, но проблема осталась.

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

в событиях продолжает появляться ошибки, которые я писал выше 1306 и 1296
Данную проблему не могу решить уже несколько месяцев.
На форумах натыкался на подобные ситуации, но либо там решения не найдено, либо ответов нет вообще.

Что может быть? как исправить без переустановки системы?

Проявилась проблема.
server 2019
подняты службы RDS (стандартное развертывание на одном сервере)
После перезагрузки сервера невозможно зайти по рдп.
Сообщение ошибки:

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

Можно зайти только локально, либо через IPMI консоль
События в диспетчере серверов показывают следующее:

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

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

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

Ранее помогал перезапуск следующих служб подряд

служба лицензирования, Локатор удаленного вызова процедур (RPC), служба посредник подключения к удаленному раб. столу, Перенаправитель портов пользовательского режима служб удаленных рабочих столов, Служба инициатора Майкрософт iSCSI(тоже после ребута сервера, другой сервак теряет диск ICSI, и пока службу не рестартнем, он его не увидит).

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

Если все это проделать, то доступ восстанавливается.

Пробовал делать DISM /Online /Cleanup-Image /RestoreHealth с указанием источника пакета wim (без него он не делал), писал что восстановлено, но проблема осталась.

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

в событиях продолжает появляться ошибки, которые я писал выше 1306 и 1296
Данную проблему не могу решить уже несколько месяцев.
На форумах натыкался на подобные ситуации, но либо там решения не найдено, либо ответов нет вообще.

Что может быть? как исправить без переустановки системы?

Проявилась проблема.
server 2019
подняты службы RDS (стандартное развертывание на одном сервере)
После перезагрузки сервера невозможно зайти по рдп.
Сообщение ошибки:

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

Можно зайти только локально, либо через IPMI консоль
События в диспетчере серверов показывают следующее:

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

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

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

Ранее помогал перезапуск следующих служб подряд

служба лицензирования, Локатор удаленного вызова процедур (RPC), служба посредник подключения к удаленному раб. столу, Перенаправитель портов пользовательского режима служб удаленных рабочих столов, Служба инициатора Майкрософт iSCSI(тоже после ребута сервера, другой сервак теряет диск ICSI, и пока службу не рестартнем, он его не увидит).

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

Если все это проделать, то доступ восстанавливается.

Пробовал делать DISM /Online /Cleanup-Image /RestoreHealth с указанием источника пакета wim (без него он не делал), писал что восстановлено, но проблема осталась.

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

в событиях продолжает появляться ошибки, которые я писал выше 1306 и 1296
Данную проблему не могу решить уже несколько месяцев.
На форумах натыкался на подобные ситуации, но либо там решения не найдено, либо ответов нет вообще.

Что может быть? как исправить без переустановки системы?