Ошибка 1306 при удалении касперского

Статья обновлена: 16 августа 2022
ID: 15351

При установке программы «Лаборатории Касперского» может появиться сообщение «Ошибка 1306. Другая программа имеет монопольный доступ к файлу [путь к файлу]».

Решение

Что делать, если решение не помогло

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

Спасибо за ваш отзыв, вы помогаете нам становиться лучше!

Спасибо за ваш отзыв, вы помогаете нам становиться лучше!

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

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

Как полностью удалить касперского с компьютера? Ответ на подобный вопрос можно отыскать в моей статье ниже. «Kaspersky Lab» оставляет много следов после своей работы, так что удалить данную программу является непростым делом. Для установки нового антивирусного ПО желательно избавиться от «Kaspersky» полностью. На жёстком диске остаётся множество папок и файлов, мешающих нормальной работе нового антивирусного программного обеспечения, и помимо стандартной очистки требуется провести дополнительный анализ наличия этих файлов и папок и стереть их полностью.

Как полностью удалить касперского с компьютера? Ошибки при удалении «Kaspersky»

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

Окно ошибки удаления «Kaspersky»

Кроме того, существует ошибка 1316, возникающая после неправильной установки программы или попыток её удаления.

При наличии пробной версии антивирусного ПО может выпадать такое окно, что показано на изображении далее.

Ошибка с кодом 1316

Такая ошибка является следствием попыток удаления ПО стандартным путём через панель управления. Дальше я разъясню, как побороть такие проблемы с данным ПО.

Стандартные методы удаления

Этот метод подходит для систем от седьмой версии «Windows» и в случае использования следующих версий ПО «Kaspersky Lab»:

• Версии 2012 и 2013
• «Kaspersky One»
• «Internet Security 2013»
• Версия «Crystal».

Важное замечание: Никогда нельзя удалять всю папку с установленным ПО в «Program Files». Это может привести ко всевозможным ошибкам.

Здесь приведу пошаговую инструкцию по удалению ПО стандартным методом:

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

Далее требуется войти в панель управления и открыть там окно установки и удаления компонентов.

После этого следует выбрать желаемую для удаления программу, кликнуть дважды на ней и выбрать «Удаление/Изменение».

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

• В окне мастера установки/удаления необходимо нажать «Далее».
• В следующем окне нужно снять все галочки и выбрать «Далее».

• Далее следует подтвердить удаление от лица администратора.

• Теперь нужно ожидать завершения удаления и после закрыть окно. После всей процедуры необходим перезапуск компьютера.

«Remover Tool»

В случае неудачного удаления программы стандартными методами советую использовать программу «Remover Tool». Официально данная программа называется «Kaspersky Lab Products Remover», и она создана разработчиками «Kaspersky» специально. Утилита даёт возможность удаления всех программных продуктов «Kaspersky».

Официальный сайт, где можно скачать утилиту: https://media.kaspersky.com/utilities/consumerutilities/kavremover.zip. После скачивания распакуйте архив и запустите установочный файл. После установки необходима перезагрузка компьютера, и последующий запуск утилиты.

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

Минутку внимания, друзья! Предлагаю вашему вниманию еще парочку полезных статей на тему как удалить антивирус аваст или как продлить лицензию Касперского, а так же как проверить компьютер на вирусы онлайн. Так же советую не пропустить еще не менее полезные статьи про то как раздать wifi с iphone или как убрать рекламу в браузере Яндекс навсегда.

«Crystalidea Uninstall Tool»

В случае, если «Remover» не помогла, рекомендую использовать «Crystalidea Uninstall Tool», тоже позволяющую удалить компоненты программ. Официальная ссылка для установки: https://www.crystalidea.com/ru

Пользоваться программой тоже очень просто. Следует найти необходимую программу в списке и выбрать «Uninstall» слева. После окончания процедуры не забудьте нажать «Force removal of all traces» для удаления временных файлов, ярлыков и записей в реестре, связанных с антивирусной программой.

Заключение

Ну что друзья, теперь вы знаете как полностью удалить касперского с компьютера. Если у вас есть ко мне вопросы, то вы их всегда можете задать в комментариях или онлайн поддержке. Так же не забывайте нажимать на кнопки соц.сетей, этим вы мне скажете спасибо! Мира вам и добра!