Содержание
- 1306 ошибка microsoft windows terminalservices sessionbroker client
- Описание проблемы
- Решение проблемы
- Что стоит проверить
- 1306 ошибка microsoft windows terminalservices sessionbroker client
- Answered by:
- Question
- 1306 ошибка microsoft windows terminalservices sessionbroker client
- Вопрос
- Ответы
- Все ответы
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 у них появлялась ошибка:
- Не включен удаленный рабочий стол
- Удаленный компьютер выключен
- Удаленный компьютер не подключен к сети
Удостоверьтесь, что удаленный компьютер включен, подключен к сети и удаленный доступ к нему включен
Решение проблемы
Ошибка вроде очевидная, что не включен 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 подключается к серверу, но ошибками,хотя посредник удален,его нет.
Привет!
Проблемища.
фф2+ 1.8 2008 на улице -13
Вчера 31 с утра вышел, завожу, заводится как не в чем не бывало, через 3-5 сек, и больше не заводится.
Крутит бодро, но не схватывает, не хватает чтоли.
Бензонасос первый попал под подозрение — гудит при включении зажигания.
Выкрутил свечу, хз посмотреть — залита, вкрутил новые (покупал год назад, лежали в бардачке), зх незаводится.
С помощью ЕЛМ327 посмотрел ошибки
C1306 — это я так понимаю с ESP и она то есть то нет.
B1600 и P1260 — запомнил, скинул — не заводится.
при повторном сканировании их не было.
Потом сходил домой за 2 ключом — не заводится
считал ошибки, появилась P2112.
Потом
цитата: |
FeodorY Вчера в 12:36 # « » AndreyChinc Можно и рукой потихоньку, нашел еще такое: Удалите коды DTC (даже если нет сохраненных DTC, выполните процедуру удаления DTC). Выключите зажигание и подождите не менее 30 секунд. Включите зажигание Запустите двигатель и быстро нажмите педаль акселератора до упора, а затем отпустите ее (для полного открывания и закрывания дроссельной заслонки). зы. У меня разок было, что разъем на дросселе не контачил, пошевелил и как бы нажал чтобы до конца фишка оделась на дроссель и все прошло. |
Снял патрубок, подигал заслонку, сопротивления с первого движения не почувствовал — врядли она зависла.
Просканил на ошибки только P1260 и U1900
В общем завел с грехом пополам.
Обороты 1800 потом упали до 1600, потом плавали в диапазоне 1050-1250, потом вообще в 800-700 падали пару раз.
Сканю ошибки и уже P1132 и U2023. (чек не горит)
Сейчас прокатился до заправки, есп загорелся и Чек загорелся P1132 и U2023.
ХЗ в чем ситуёвина, ДВС шит, но давно.
Прям не знаю что и делать, далеко ехать боюсь.
потом
цитата: |
FeodorY Вчера в 14:45 # « »
AndreyChinc |
Вчера в 15:58 # « »
FeodorY
В общем пошел сейчас, просканил ошибки
выдало P1132 и U2023., скинул чек, завел, прокатился.
Показалось, что обороты высоковаты.
а еще на праковке ТЦ на второй, как на дизеле(без ноги на газе) ехала на 1900об/мин
потом вроде нормально всё.
Воздушный фильтр грязноват, но не срань, состояние на 3 (из 5).
Прокатился, опять ошибки глянул.
нет ошибок, в общем я в прострации.
цитата: |
FeodorY Вчера в 16:01 # « »
AndreyChinc |
AndreyChinc Вчера в 16:06 # « »
FeodorY
тоже думал об этом, но такого вроде не было(чтоб стрелки прыгали или гасла), но спасибо.
107 и 114 преды целы
сниму, гляну, может обновлю пайку, если подозрительная будет.
Вечером по городу проехал, так обороты подвисают у 1600-1700
Но едет и не тупит.
1.01.16
Сегодня с утра пришел, завелась и заглохла. на улице -17
Ошибок не было.
Не заводится.
Прошил на прошивку, на которой прошлой зимой катал, та что была до прошивки авто.
Еле завел.
обороты около 1900-2000 белый пар-дым.
Поехал к другу, чтобы разбираться, смотреть может что отвалилось.
по пути тупила, загорелось есп U2023
Заслонка не зависает, двигается без заеданий.
Попробовал скинуть клапан адсорбера-реагирует моментом, сам он не продувается.
Покатался с отключеными лямдами -едет только в путь
Я не понимаю почему он не хочет заводится с утра.
в течении дня вроде без проблем, но беда с оборотами.
Такое ощущение, что как-то виновата температура.
PS:
на прогретом померяли компрессию, что-то много во всех горшках 17ю5 примерно, но стабильно, если прибор и врет, то она одинакова везде.
масло при пробеге в 162 не доливаю, как залил на мах так и стоит.
круиз работает корректно.
двигатель тянет на 5 с 1900, довольно бодро.
Раньше вообще не было таких проблем.
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!
На нашем ресурсе имеется возможность задавать вопросы и делиться собственным опытом по устренению неисправностей связанных с ошибкой C1306. Задав вопрос в течении нескольких дней Вы сможете найти ответ на него.
Принимая во внимание тот факт, что OBD2 ошибки работы двигателя или других электронных систем автомобиля не всегда на прямую указывают на неработающий элемент, и то что разных марках и моделях автомобилей одна и таже ошибка может возникать как следствие неисправности абсолютно разных элементов электронной системы мы создали этот алгоритм помощи и обмена полезной информацией.
Мы надеемся, с Вашей помощью, сформировать причино-следственную связь возникновения той или иной OBD2 ошибки у конкретного автомобиля (марка и модель). Как показал опыт если рассматривать определенную марка-модель автомобиля, то в подавляющем большинстве случаев причина ошибки одна и таже.
Если ошибка указывает на неверные параметры (высокие или низкие значения) какого нибудь из датчиков или анализаторов, то вероятней всего этот элемент исправен, а проблему надо искать так сказать «выше по течению», в элементах работу которых анализирует датчик или зонд.
Если ошибка указывает на постоянно открытый или закрытый клапан, то тут надо подойти к решению вопроса с умом, а не менять бездумно этот элемент. Причин может быть несколько: клапан засорен, клапан заклинил, на клапан приходит неверный сигнал от других неисправных узлов.
Ошибки работы двигателя OBD2 и других систем автомобиля (ELM327) не всегда на прямую указывают на неработающий элемент. Сама по себе ошибка является косвенными данными о неисправности в системе, в некотором смысле подсказкой, и только в редких случаях прямым указанием на неисправный элемент, датчик или деталь. Ошибки (коды ошибок) полученные от прибора, сканера требуют правильной интерпретации информации, дабы не тратить время и деньги на замену работающих элементов автомобиля. Проблема зачастую кроется намного глубже чем кажется на первый взгляд. Это вызвано теми обстоятельствами, что информационные сообщения содержат, как было выше сказано, косвенную информацию о шарушении работы системы.
Вот пару общих примеров. Если ошибка указывает на неверные параметры (высокие или низкие значения) какого нибудь из датчиков или анализаторов, то вероятней всего этот элемент исправен, так как он анализирует (выдает некие параметры или значения), а проблему надо искать так сказать «выше по течению», в элементах работу которых анализирует датчик или зонд.
Если ошибка указывает на постоянно открытый или закрытый клапан, то тут надо подойти к решению вопроса с умом, а не менять бездумно этот элемент. Причин может быть несколько: клапан засорен, клапан заклинил, на клапан приходит неверный сигнал от других неисправных узлов.
Еще один момент который хотелось бы отметить — это специфика той или иной марки и модели. Поэтому узнав ошибку работы двигателя или дрогой системы Вашего автомобиля не спешите делать поспешных решений, а подойдите к вопросу комплексно.
Наш форум создан для всех пользователей, от простых автолюбителей до профессиональных автоэлектриков. По капле от каждого и всем будет полезно.