TS Gateway Network access Policy engine received failure from IAS and the error was "16388"
- Hello,
I'm not sure if this is more appropriate here, or in the Network Access Protection forum...
When I try to connect to my Terminal Services server through my TS Gateway I get the following two events logged on the TS Gateway:
Log Name: Microsoft-Windows-TerminalServices-Gateway/Operational
Source: Microsoft-Windows-TerminalServices-Gateway
Date: 10/24/2008 8:26:47 AM
Event ID: 641
Task Category: (4)
Level: Error
Keywords: (33554432)
User: NETWORK SERVICE
Computer: $TS_GATEWAY_NAME
Description:
TS Gateway Network access Policy engine received failure from IAS and the error was "16388"
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-TerminalServices-Gateway" Guid="{4d5ae6a1-c7c8-4e6d-b840-4d8080b42e1b}" />
<EventID>641</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>4</Task>
<Opcode>22</Opcode>
<Keywords>0x4000000002000000</Keywords>
<TimeCreated SystemTime="2008-10-24T14:26:47.651Z" />
<EventRecordID>443</EventRecordID>
<Correlation />
<Execution ProcessID="348" ThreadID="3744" />
<Channel>Microsoft-Windows-TerminalServices-Gateway/Operational</Channel>
<Computer>$TS_GATEWAY_FQDN</Computer>
<Security UserID="S-1-5-20" />
</System>
<UserData>
<EventInfo xmlns="aag">
<Name>
</Name>
<ErrorCode>16388</ErrorCode>
</EventInfo>
</UserData>
</Event>
Log Name: Microsoft-Windows-TerminalServices-Gateway/Operational
Source: Microsoft-Windows-TerminalServices-Gateway
Date: 10/24/2008 8:26:47 AM
Event ID: 201
Task Category: (2)
Level: Error
Keywords: Audit Failure,(16777216)
User: NETWORK SERVICE
Computer: $TS_GATEWAY_NAME
Description:
The user "$USER_NAME", on client computer "$COMPUTER_IP", did not meet connection authorization policy requirements and was therefore not authorized to access the TS Gateway server. The following authentication method was attempted: "NTLM". The following error occurred: "23003".
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-TerminalServices-Gateway" Guid="{4d5ae6a1-c7c8-4e6d-b840-4d8080b42e1b}" />
<EventID>201</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>2</Task>
<Opcode>30</Opcode>
<Keywords>0x4010000001000000</Keywords>
<TimeCreated SystemTime="2008-10-24T14:26:47.651Z" />
<EventRecordID>444</EventRecordID>
<Correlation />
<Execution ProcessID="348" ThreadID="3744" />
<Channel>Microsoft-Windows-TerminalServices-Gateway/Operational</Channel>
<Computer>$TS_GATEWAY_FQDN</Computer>
<Security UserID="S-1-5-20" />
</System>
<UserData>
<EventInfo xmlns="aag">
<Username>$USER_NAME</Username>
<IpAddress>$CLIENT_IP_ADDRESS</IpAddress>
<AuthType>NTLM</AuthType>
<Resource>
</Resource>
<ErrorCode>23003</ErrorCode>
</EventInfo>
</UserData>
</Event>
The TS Gateway is a Server 2008 machine, the Terminal Services server is a Server 2008 machines, the client is Windows XP SP3
Here's the rub, the computer belongs to another domain. The computer is owned by another department within our larger infrastructure, it is in the same forest. I do not have any TS RAPs applied at this moment; and, it doesn't even look like it's getting far enough for the SoH to be analyzed.
I cannot find absolutely anything online about the ' TS Gateway Network access Policy engine received failure from IAS and the error was "16388" ' error; besides this technet discription of the error.
So, I really don't know where to look for more information.- BearbeitetmoomanX Freitag, 24. Oktober 2008 18:53
Alle Antworten
- The feature team is looking into this issue. I will get back to you once we find anything
Thanks,
Vikash - Eeerp!
My bad, I never ran tsgqecclientconfig.cmd on this client... Thus, it was Non-NAP Capable; I don't know how/if that error correlates, but there you go.
There's still this issue of being in a different domain. For some reason the TS Gateway tries to contact the computer's domain; even though there is no computer-based authentication happening(?), it should just be authenticating the user that is part of my domain, right?
Anyway, can probably close this.
- Alright, I was going to come in here and close ('Mark as Answer') this; but, this is odd...
I'm receiving those same two errors in the Terminal Services events whenever I attempt to log on.
The client Disconnects from Remote Desktop with the following message:
Terminal Services connection authorization policy (TS CAP) is preventing connection to the remote computer through TS Gateway, possibly due to one of the following reasons: You do not have permission to connect to the TS Gateway server. You used password authentication but the TS Gateway server is expecting smart card authentication (or vice versa). Contact your administrator for further assistance.
On the NPS side I get the following three events when I attempt to log on:
Log Name: System
Source: NPS
Date: 10/27/2008 12:52:05 PM
Event ID: 4402
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: $TS_GATEWAY_FQDN
Description:
There is no domain controller available for domain $OTHER_DOMAIN_NAME.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="NPS" />
<EventID Qualifiers="49152">4402</EventID>
<Level>2</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2008-10-27T18:52:05.000Z" />
<EventRecordID>3702</EventRecordID>
<Channel>System</Channel>
<Computer>$TS_GATEWAY_FQDN</Computer>
<Security />
</System>
<EventData>
<Data>HFS</Data>
</EventData>
</Event>
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 10/27/2008 12:52:05 PM
Event ID: 6272
Task Category: Network Policy Server
Level: Information
Keywords: Audit Success
User: N/A
Computer: $TS_GATEWAY_FQDN
Description:
Network Policy Server granted access to a user.
User:
Security ID: NULL SID
Account Name: $DOMAIN\ACCOUNT_NAME
Account Domain: $DOMAIN
Fully Qualified Account Name: $DOMAIN\ACCOUNT_NAME
Client Machine:
Security ID: NULL SID
Account Name: $COMPUTER_FQDN(different domain than one I am attempting to connect to)
Fully Qualified Account Name: $COMPUTER_FQDN
OS-Version: 5.1.2600 3.0 x86 Domain Controller
Called Station Identifier: UserAuthType:PW
Calling Station Identifier: -
NAS:
NAS IPv4 Address: -
NAS IPv6 Address: -
NAS Identifier: -
NAS Port-Type: Virtual
NAS Port: -
RADIUS Client:
Client Friendly Name: -
Client IP Address: -
Authentication Details:
Proxy Policy Name: NAP TS Gateway
Network Policy Name: NAP TS Gateway Compliant
Authentication Provider: Windows
Authentication Server: $TS_GATEWAY_FQDN
Authentication Type: Unauthenticated
EAP Type: -
Account Session Identifier: -
Quarantine Information:
Result: Full Access
Session Identifier: {A1FC7E35-8827-4BC4-86D2-920E2A4FFCBC} - 2008-10-27 18:51:34.656Z
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
<EventID>6272</EventID>
<Version>0</Version>
<Level>0</Level>
<Task>12552</Task>
<Opcode>0</Opcode>
<Keywords>0x8020000000000000</Keywords>
<TimeCreated SystemTime="2008-10-27T18:52:05.181Z" />
<EventRecordID>6347</EventRecordID>
<Correlation />
<Execution ProcessID="636" ThreadID="760" />
<Channel>Security</Channel>
<Computer>$TS_GATEWAY_FQDN</Computer>
<Security />
</System>
<EventData>
<Data Name="SubjectUserSid">S-1-0-0</Data>
<Data Name="SubjectUserName">$DOMAIN\ACCOUNT_NAME(my domain)</Data>
<Data Name="SubjectDomainName">$DOMAIN_NAME</Data>
<Data Name="FullyQualifiedSubjectUserName">$ACCOUNT_NAME</Data>
<Data Name="SubjectMachineSID">S-1-0-0</Data>
<Data Name="SubjectMachineName">$CLIENT_COMPUTER_FQDN</Data>
<Data Name="FullyQualifiedSubjectMachineName">$CLIENT_COMPUTER_FQDN</Data>
<Data Name="MachineInventory">5.1.2600 3.0 x86 Domain Controller </Data>
<Data Name="CalledStationID">UserAuthType:PW</Data>
<Data Name="CallingStationID">-</Data>
<Data Name="NASIPv4Address">-</Data>
<Data Name="NASIPv6Address">-</Data>
<Data Name="NASIdentifier">-</Data>
<Data Name="NASPortType">Virtual </Data>
<Data Name="NASPort">-</Data>
<Data Name="ClientName">-</Data>
<Data Name="ClientIPAddress">-</Data>
<Data Name="ProxyPolicyName">NAP TS Gateway</Data>
<Data Name="NetworkPolicyName">NAP TS Gateway Compliant</Data>
<Data Name="AuthenticationProvider">Windows </Data>
<Data Name="AuthenticationServer">$TS_GATEWAY_FQDN</Data>
<Data Name="AuthenticationType">Unauthenticated </Data>
<Data Name="EAPType">-</Data>
<Data Name="AccountSessionIdentifier">-</Data>
<Data Name="QuarantineState">Full Access </Data>
<Data Name="QuarantineSessionIdentifier">{A1FC7E35-8827-4BC4-86D2-920E2A4FFCBC} - 2008-10-27 18:51:34.656Z</Data>
</EventData>
</Event>
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 10/27/2008 12:52:05 PM
Event ID: 6278
Task Category: Network Policy Server
Level: Information
Keywords: Audit Success
User: N/A
Computer: $TS_GATEWAY_FQDN
Description:
Network Policy Server granted full access to a user because the host met the defined health policy.
User:
Security ID: NULL SID
Account Name: $ACCOUNT_NAME
Account Domain: $DOMAIN_NAME
Fully Qualified Account Name: $DOMAIN\ACCOUNT_NAME
Client Machine:
Security ID: NULL SID
Account Name: $CLIENT_COMPUTER_FQDN
Fully Qualified Account Name: $CLIENT_COMPUTER_NAME
OS-Version: 5.1.2600 3.0 x86 Domain Controller
Called Station Identifier: UserAuthType:PW
Calling Station Identifier: -
NAS:
NAS IPv4 Address: -
NAS IPv6 Address: -
NAS Identifier: -
NAS Port-Type: Virtual
NAS Port: -
RADIUS Client:
Client Friendly Name: -
Client IP Address: -
Authentication Details:
Proxy Policy Name: NAP TS Gateway
Network Policy Name: NAP TS Gateway Compliant
Authentication Provider: Windows
Authentication Server: $TS_GATEWAY_FQDN
Authentication Type: Unauthenticated
EAP Type: -
Account Session Identifier: -
Quarantine Information:
Result: Full Access
Extended-Result: -
Session Identifier: {A1FC7E35-8827-4BC4-86D2-920E2A4FFCBC} - 2008-10-27 18:51:34.656Z
Help URL: -
System Health Validator Result(s):
Windows Security Health Validator..
Compliant
No Data
None
(0x0 - )
(0x0 - )
(0x0 - )
(0x0 - )
(0x0 - )
(0x0 - )
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
<EventID>6278</EventID>
<Version>0</Version>
<Level>0</Level>
<Task>12552</Task>
<Opcode>0</Opcode>
<Keywords>0x8020000000000000</Keywords>
<TimeCreated SystemTime="2008-10-27T18:52:05.181Z" />
<EventRecordID>6348</EventRecordID>
<Correlation />
<Execution ProcessID="636" ThreadID="760" />
<Channel>Security</Channel>
<Computer>$TS_GATEWAY_FQDN</Computer>
<Security />
</System>
<EventData>
<Data Name="SubjectUserSid">S-1-0-0</Data>
<Data Name="SubjectUserName">$DOMAIN\ACCOUNT_NAME</Data>
<Data Name="SubjectDomainName">$DOMAIN</Data>
<Data Name="FullyQualifiedSubjectUserName">$DOMAIN\ACCOUNT_NAME</Data>
<Data Name="SubjectMachineSID">S-1-0-0</Data>
<Data Name="SubjectMachineName">$CLIENT_COMPUTER_FQDN</Data>
<Data Name="FullyQualifiedSubjectMachineName">$CLIENT_COMPUTER</Data>
<Data Name="MachineInventory">5.1.2600 3.0 x86 Domain Controller </Data>
<Data Name="CalledStationID">UserAuthType:PW</Data>
<Data Name="CallingStationID">-</Data>
<Data Name="NASIPv4Address">-</Data>
<Data Name="NASIPv6Address">-</Data>
<Data Name="NASIdentifier">-</Data>
<Data Name="NASPortType">Virtual </Data>
<Data Name="NASPort">-</Data>
<Data Name="ClientName">-</Data>
<Data Name="ClientIPAddress">-</Data>
<Data Name="ProxyPolicyName">NAP TS Gateway</Data>
<Data Name="NetworkPolicyName">NAP TS Gateway Compliant</Data>
<Data Name="AuthenticationProvider">Windows </Data>
<Data Name="AuthenticationServer">$TS_GATEWAY_FQDN</Data>
<Data Name="AuthenticationType">Unauthenticated </Data>
<Data Name="EAPType">-</Data>
<Data Name="AccountSessionIdentifier">-</Data>
<Data Name="QuarantineState">Full Access </Data>
<Data Name="ExtendedQuarantineState">-</Data>
<Data Name="QuarantineSessionID">{A1FC7E35-8827-4BC4-86D2-920E2A4FFCBC} - 2008-10-27 18:51:34.656Z</Data>
<Data Name="QuarantineHelpURL">-</Data>
<Data Name="QuarantineSystemHealthResult">
Windows Security Health Validator..
Compliant
No Data
None
(0x0 - )
(0x0 - )
(0x0 - )
(0x0 - )
(0x0 - )
(0x0 - )</Data>
</EventData>
</Event>
So, it looks like the client computer is passing the TS CAP; but, the client side still thinks it failed?
- Okay...
If I allow my TS Gateway to access (through our firewall) the Domain Controllers in the computer owner's domain it successfully logs on.
According to our firewall logs it looks like some Kerberos authentication was happening between the TS Gateway and the outside Domain Controller. I can live with this for this client; but, it begs the question...
Can I get by without this computer domain check? What if I am trying to connect from a computer that is NAP Capable; but I do not know where it's 'home domain' is?
- Did you ever find a solution to this. We are experiencing this same problem trying to connect with another organization through a TS Gateway. The same workstation when taken off the domain works just fine. When it is on the domain it does not work.
Thanks
Rob - What error do you get on the client when you say that the connection does not work?
Thanks
Vikash - The error we received is below:
[Window Title]
RemoteApp Disconnected[Content]
Terminal Services connection authorization policy (TS CAP) is preventing connection to the remote computer through TS Gateway, possibly due to one of the following reasons:* You do not have permission to connect to the TS Gateway server.
* You used password authentication but the TS Gateway server is expecting smart card authentication (or vice versa).Contact your administrator for further assistance.
The authentication (username and password from an account on their domain) is correct. For testing we are also logging in with a local machine account and not a domain account. The strange thing is that with the same computers taken off our domain, the connection through the gateway always works and we are able to get to the affiliates apps. The same computer rejoined to the domain again fails everytime.
I was thinking this was due to some policy we have in our domain that may be blocking the connection for some reason so I created an OU that blocks all policies on the domain and put all the computer accounts that we were testing as well as a few domain user accounts. We verified that no policies were being brought down to the system with a gpresult command. We receive the same error with all policies blocked but just on the domain. - Hello Rob,
I am assuming that the computers that you are moving in and out of domain are client computers. And when the clients are domain joined you get a CAP error and when they are non domain joined connections go through. Please correct me if i am wrong.
Please answer the following questions.
1. Is TS Gateway configured for a NAP scenario ? Is TS Gateway QEC is enabled on your client ( netsh nap client show state and see whether gateway QEC is enabled ). Please list the CAP settings on the TS Gateway.
2. when you try to login from domain joined client machine , is it asking for gateway credentials ? Or picking up logged on credentials. This is one GP setting. Ultimately what i am asking here is "Is the same user name is used to connect to Gateway in both the cases ( when client is domain joined and not joined to domain ) ?"
There can be a machine level gorup policy setting which is causing this, so by logging in with local user account you can not rule out that domain GP is not a problem.
Thanks & Regards,
Rajesh.
- I found this thread because I am having the same exact problem and can recreate it as necessary for testing. Remote Desktop Client PC's (Windows XP SP3 or Vista SP1) in a domain environment trying to connect through a TS Gateway to a computer in an entirely different domain/forest and remote network.
If the client PC is a member computer of the domain (even if a user logs on locally), we get the above-mentioned error:
Terminal Services connection authorization policy (TS CAP) is preventing connection to the remote computer through TS Gateway, possibly due to one of the following reasons:
* You do not have permission to connect to the TS Gateway server.
* You used password authentication but the TS Gateway server is expecting smart card authentication (or vice versa).
Contact your administrator for further assistance.
If I remove the client PC from its domain, I can successfully connect to the remote TS Gateway (in an entirely different domain/forest), but if I add the PC back to its local domain, I get the error again.
Looking at the TS Gateway logs, on success (when client computer is not a member of its domain), I see:
The user "domain\user", on client computer "xxx.xxx.xxx.xxx", met connection authorization policy requirements and was therefore authorized to access the TS Gateway server. The following authentication method was used: "NTLM".
On failure (when client computer is a member of its domain), I see two entries in the log:
1. TS Gateway Network access Policy engine received failure from IAS and the error was "16388"
2. The user " domain\user", on client computer " xxx.xxx.xxx.xxx", did not meet connection authorization policy requirements and was therefore not authorized to access the TS Gateway server. The following authentication method was attempted: "NTLM". The following error occurred: "23003".
Note that I am not changing any settings on the TS Gateway. I am only adding/removing the client from its domain for testing. In the logs "domain\user" are the correct credentials for the TS Gateway's domain, I am not incorrectly passing the client's domain and login credentials to the TS Gateway. As for the TS CAP settings on the Gateway server, I am allowing passwords and I am allowing all "Domain Users" to connect (Domain Users referring to users in the TS Gateway's domain, not the client's domain.) Client group membership is blank (I want any computer to be able to connect) and I have "Enable device redirection for all client devices."
To answer Rajesh's questions, 1. We are not using NAP and the "Network Access Protection Agent" on the client is set on manual and is not running. (Turning it on doesn't help.) And when I connect to the Gateway, I am explicitly entering the correct credentials of the remote domain (not the credentials of the local client's domain).
Is this a bug in the TS client/gateway handshake? Any possible machine-level GPO settings on the client that could cause it fail the TS_CAP policy that gets "fixed" when it's removed from its domain? Any suggestions are welcome -- I have a good setup for testing and finding a resolution sounds like it will help others as well. Thanks, Joe
- P.S. I think the key to this issue is what moomanX wrote above:
There's still this issue of being in a different domain. For some reason the TS Gateway tries to contact the computer's domain; even though there is no computer-based authentication happening(?), it should just be authenticating the user that is part of my domain, right?
Why is the TS Gateway in the destination domain trying to talk to the domain controllers of the client domain? Is NAP mistakenly trying to talk to the client's domain to verify the identity or integrity of the client computer? If the domains are unrelated (two different companies in two different locations), firewall rules or other protective measures would prevent this communication. Why is this verification not necessary if the client PC is in a workgroup instead? Hoping that somebody has some ideas.... -Joe - I am still seeing this error as well and have an open case with Microsoft. The variable of the domain still exists even when I bring a domain machine home using my home network. Taking that machine off the domain while at home and puting it in workgroup gives successful results on connecting through the TS Gateway. The strange thing is, there are other users that are part of other domains that can connect correctly to this affiliate TS Web Gateway. Currently we are the only one. I can even connect from workstations added to my home domain. I will reference this thread to Microsoft, maybe we can get some more info.
-Rob - Are you still facing this issue? If yes, i would like to help you investigate it further. Can you please provide me your email id so that i can contact you directly?
Thanks
Vikash I seemed to be having the exact same problem. I am running Small Business Server 2008 which is migrated from SBS2003.
I got this error on the client machine running Windows Vista x64 Enterprise on a different domain. TS Gateway Server and the client computer are on different domain. I am using RWW to connect to a computer on the SBS domain.
NAP is running on the client computer with QEC enabled. Stopping or restarting NAP does not help. I ran tsgqecclientconfig.cmd to add the TS gateway server FQDN to the client machine.
VBScript: remote Desktop Disconnected
An internal error has occurred (error 50331676). For more information, please contact your network administer or Microsoft Product Support.
TS gateway server also logged the exact log as moomanX in the TerminalServices-Gateway:Operational.
Has anyone found the solution to this problem? I tried the hotfix KB954034. As everyone else in the forum, I didn't have this problem from a non-domain client.
Any idea? Thanks.
~Linn
- Hi,
How are you connecting through gateway ? using mstsc ? Please tell the details like how this VBScript error is generated. on your client can you please execute the command "netsh napclient show state" and see whether TSGQEC is properly intialized. And tell the exact error message that is returned from mstsc client.
Regards,
Rajesh.
Regards, Rajesh. Hi Rajesh,
Thanks for replying. I was connecting through the SBS2008 Remote Web Workplace portal. Once I logged into RWW, I saw there options. One is to check my emails, another is “Connect to a computer”, and last one is for the company internal website.
From any computer (either on domain or not), I have no problem using email and internal website. But as I said before and other mentioned, I got the VBScript Error from a computer with a different domain than my SBS2008. Once I clicked on connect to a computer link,
1. It asked me to choose a computer
2. And then I clicked "Connect" button
3. And then it asked me for my user name and password.
(I have tried domain\username and username.)
4. Then a window with this message popped up.(If it is a new computer that I have never used RWW, it asked me to install an ActiveX component.)
~~Please wait while a connection to your computer is established. This may take several seconds …
~~
5. It stayed at this window for while. But after 30 seconds or so, I got the VBScrtip error.
And I think TSGQEC is initialized. When I ran netsh nap client show state, it generated this:
--------------------------------------------------------------------------------------
Client state:
----------------------------------------------------
Name = Network Access Protection Client
Description = Microsoft Network Access Protection Client
Protocol version = 1.0
Status = Enabled
Restriction state = Not restricted
Troubleshooting URL =
Restriction start time =
Extended state =
Enforcement client state:
----------------------------------------------------
Id = 79617
Name = DHCP Quarantine Enforcement Client
Description = Provides DHCP based enforcement for NAP
Version = 1.0
Vendor name = Microsoft Corporation
Registration date =
Initialized = No
Id = 79618
Name = Remote Access Quarantine Enforcement Client
Description = Provides the quarantine enforcement for RAS Client
Version = 1.0
Vendor name = Microsoft Corporation
Registration date =
Initialized = No
Id = 79619
Name = IPSec Relying Party
Description = Provides IPSec based enforcement for Network Access Pro
tection
Version = 1.0
Vendor name = Microsoft Corporation
Registration date =
Initialized = No
Id = 79621
Name = TS Gateway Quarantine Enforcement Client
Description = Provides TS Gateway enforcement for NAP
Version = 1.0
Vendor name = Microsoft Corporation
Registration date =
Initialized = Yes
Id = 79623
Name = EAP Quarantine Enforcement Client
Description = Provides EAP based enforcement for NAP
Version = 1.0
Vendor name = Microsoft Corporation
Registration date =
Initialized = No
System health agent (SHA) state:
----------------------------------------------------
Id = 79744
Name = Windows Security Health Agent
Description = The Windows Security Health Agent checks the compliance
of a computer with an administrator-defined policy.
Version = 1.0
Vendor name = Microsoft Corporation
Registration date =
Initialized = Yes
Failure category = None
Remediation state = Success
Remediation percentage = 0
Fixup Message = (3237937214) - The Windows Security Health Agent has fi
nished updating its security state.
Compliance results =
Remediation results =
Ok.
_____________________________________________________________________________________________
Thanks.
~LinnThe feature team is looking into this issue. I will get back to you once we find anything
Thanks,
Vikash
Hello,
This is happening to us as well. Our clients are NAP capable and work 95% of the time. But over the past month we have recieved the above error on our 2 terminal servers that belong to one session broker.
TS Gateway Network access Policy engine received failure from IAS and the error was "16388"
<Provider Name="Microsoft-Windows-TerminalServices-Gateway" Guid="{4d5ae6a1-c7c8-4e6d-b840-4d8080b42e1b}" /><EventID>641</EventID><Version>0</Version><Level>2</Level><Task>4</Task><Opcode>22</Opcode><Keywords>0x4000000002000000</Keywords><TimeCreated SystemTime="2009-06-16T12:30:47.759Z" /><EventRecordID>5966</EventRecordID><Correlation /><Execution ProcessID="2324" ThreadID="6964" /><Channel>Microsoft-Windows-TerminalServices-Gateway/Operational</Channel><Computer>OurServerName</Computer><Security UserID="S-1-5-20" /></System><Name /><ErrorCode>16388</ErrorCode></EventInfo></UserData></Event>
The connection seems to reset itself after the above error anywhere from 40 seconds to 5 minutes. Can not find any information as to what could be causing this. Any help would be greatly appreciated.
Thanks!- Hi,
The error "TS Gateway Network access Policy engine received failure from IAS and the error was "16388"" happens when the communication between NPS and TS Gateway times out.
Can you please provide the NPS logs? Here is the command to start the logging
netsh ras set tracing * enableSend us the all the log files in %windir%\tracing directory. Also Please also send us the event logs
Thanks.
Regards, Rajesh. - Thank you for the response. I will enable tracing now and post\send logs as soon as we receive another 641.
- Hello,
This has just happened now. I have the trace logs and the event logs, where can I send them too?
Thanks. - I dont want to interced on Rajesh, but if you don't mind, I would like to see them too: kristin.l.griffin@gmail.com.
Thanks!
Kristin L. Griffin
The Microsoft Windows Server 2008 Terminal Services Resource Kit is available at: http://www.amazon.com/Windows-Server%C2%AE-Terminal-Services-Resource/dp/0735625859/ref=sr_1_1?ie=UTF8&s=books&qid=1245947488&sr=8-1 - I have placed both the log files as well as the tsgateway eventlogs on our webserver at http://files.progressive-solutions.com/TSGateWay/ I will keep this up for a couple of days. Thank you again for any assistance you can provide!
- Hello,
Has anyone had a chance to look at the logs for this issue? Or is there any other information that I can provide?
Thanks,
The Dr. - Hi Zaius,
We are following up with NPS team and working on it.
NPS team says this error happens when NPS can not validate the client machine by contacting AD. In your case NPS failed to validate client computer name: TPUGHPC.CoxIndustries.local
Is the client machine domain and TS Gateway server domain are trusted ?
Do you have any client machine group specified in CAP ?
Also are you getting the failure from same client ( TPUGHPC.CoxIndustries.local ) always ?
Thanks.
Regards, Rajesh. - Hello,
I am still waiting for the answer as well.
Has anyone found a workaround?
Thanks.
~Linn
@Dr. Zaius, Can you please confirm that the logs that you have shared are for the failure connection case only? I am asking this because the NPS logs seem to indicate that NPS returned success. Else can you please share the logs for the connection failure case one more time?
@Linnpmin, can you also please share logs for the failure case that you are seeing?
Here is the command to start the logging
1. netsh ras set tracing * enable
2. Repro the issue
3. Send us the all the log files in %windir%\tracing directory. Also Please also send us the event logs
Thanks
Vikash- Can anyone facing this issue share the logs again please?
Thanks
Vikash - Hi,
I have posted the logs here: http://cid-ba1f0c40eb76ee9c.skydrive.live.com/browse.aspx/Public?authkey=cx0Syf4DUYU%24.
~Linn I am sorry, I was unavailable last week. The logs that I posted did include the error event, but also successful events. I will clear out the logs and repost as soon as the event occurs. Here are some answers to a couple of the questions:
Also are you getting the failure from same client ( TPUGHPC.CoxIndustries.local ) always ? -- Not sure on this, will need to check when event occurs again.
Do you have any client machine group specified in CAP ? -- There are no client machine groups specified in the CAP.
Is the client machine domain and TS Gateway server domain are trusted ? -- The clients are connecting to a Hosted provider and Domains are NOT trusted.
FYI ~ I have left the logs up at the site noted above and will repost to there if\when event occurs again.
Thanks~!- Did anyone find a answer. I have the NPS "There is no domain controller available for domain" issue while trying to connect via RD Gateway in Windows 2008 R2. I can however connect via TS Gateway in Windows 2008 SP2 without any problems. All my clients and servers are in a single Windows 2003 domain.
- Can you please share the logs as has been asked in this post above? This will help us to investigate it further.
When you say you are using WS 2008 R2, which release are you using? Is it Beta or RC build?
Thanks
Vikash - Just an FYI here....we haven't had the issue since we upgraded to SP2. At this time we don't have plans to move R2 into production as SP2 is working very solidly.
Thanks,
Dr. Z Just to add a little to this thread...
-We can successfully connect to the TSGateway server with a NON domain connected machine.
-We can NOT connect to the TSGateway server with a machine that is connected to ANY domain, including our own.
I did some research into the tracing logs (IASSAM.log in particular) and found that the TSGateway server is trying to communicate with the domain machines domain controller to "crack" it's FQDN into a NetBIOS name. Obviously no one wants a DC to be internet facing, thus our session fails. It throws some sort of COM exception which I have not got my finger on yet. Take a look at a snippet from my log...
Successful login:[3392] 10-16 13:01:20:500: NT-SAM Names handler received request with user identity XXX\xxxx.
[3392] 10-16 13:01:20:500: Username is already an NT4 account name.
[3392] 10-16 13:01:20:500: SAM-Account-Name is "XXX\xxxx".
[3392] 10-16 13:01:20:500: Get machine name xp-demo2 from non SOH
[3392] 10-16 13:01:20:500: Skipping cracking since machine name is in NetBIOS format: xp-demo2
Unsuccessful login:
[3084] 10-16 13:10:48:993: NT-SAM Names handler received request with user identity XXX\xxxx.
[3084] 10-16 13:10:48:993: Username is already an NT4 account name.
[3084] 10-16 13:10:48:993: SAM-Account-Name is "XXX\xxxx".
[3084] 10-16 13:10:48:993: Get machine name xp-demo.AnyDomain.com from non SOH
[3084] 10-16 13:11:31:086: Failed to crack machine name failed: The RPC server is unavailable.
[3084] 10-16 13:11:31:086: Caught COM exception: The system cannot open the file.
The 2 XP machines are clones. XP Pro on SP3. Obviously different names and one is connected to a domain, one is not
I've tried everything you guys have mentioned in this thread, so thanks for the ideas. I've sent my findings to MS, but have not heard back. I'll post any sort of fix I recieve.
Thanks,
Jarett
