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

• 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
    правка орфографии

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».  

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

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».  

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

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!