TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Fri, 24 Oct 2008 18:52:44 Z

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.

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Mon, 27 Oct 2008 07:14:01 Z

The feature team is looking into this issue. I will get back to you once we find anything

Thanks,
Vikash

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Mon, 27 Oct 2008 17:20:57 Z

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.

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Mon, 27 Oct 2008 19:03:45 Z

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?

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Mon, 27 Oct 2008 20:07:30 Z

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?

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Fri, 20 Mar 2009 17:02:00 Z

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

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Sat, 21 Mar 2009 03:52:10 Z

What error do you get on the client when you say that the connection does not work?

Thanks
Vikash

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Thu, 26 Mar 2009 02:24:38 Z

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.

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Thu, 26 Mar 2009 11:23:57 Z

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.

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Wed, 08 Apr 2009 15:42:41 Z

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

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Fri, 10 Apr 2009 15:11:34 Z

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

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Wed, 15 Apr 2009 14:28:57 Z

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

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Wed, 22 Apr 2009 05:38:28 Z

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

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Wed, 03 Jun 2009 17:00:26 Z

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

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Fri, 05 Jun 2009 13:04:42 Z

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.

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Fri, 05 Jun 2009 15:37:07 Z

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.
~Linn

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Wed, 17 Jun 2009 14:38:00 Z

The 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"

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">

- <System>

<Channel>Microsoft-Windows-TerminalServices-Gateway/Operational</Channel>

<Computer>OurServerName</Computer>

</System>

- <UserData>

- <EventInfo xmlns="aag">

</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!

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Sat, 20 Jun 2009 07:03:19 Z

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 * enable

Send us the all the log files in %windir%\tracing directory. Also Please also send us the event logs

Thanks.

Regards, Rajesh.

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Tue, 23 Jun 2009 18:15:36 Z

Thank you for the response. I will enable tracing now and post\send logs as soon as we receive another 641.

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Thu, 25 Jun 2009 20:23:16 Z

Hello,

This has just happened now. I have the trace logs and the event logs, where can I send them too?

Thanks.

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Thu, 25 Jun 2009 20:24:27 Z

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

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Thu, 25 Jun 2009 21:27:09 Z

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!

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Tue, 30 Jun 2009 22:32:56 Z

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.

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Wed, 01 Jul 2009 11:03:40 Z

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.

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Thu, 02 Jul 2009 18:50:30 Z

Hello,

I am still waiting for the answer as well.

Has anyone found a workaround?

Thanks.

~Linn

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Fri, 03 Jul 2009 08:41:11 Z

@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

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Mon, 13 Jul 2009 06:32:48 Z

Can anyone facing this issue share the logs again please?

Thanks
Vikash

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Mon, 13 Jul 2009 17:43:01 Z

Hi,

I have posted the logs here: http://cid-ba1f0c40eb76ee9c.skydrive.live.com/browse.aspx/Public?authkey=cx0Syf4DUYU%24.

~Linn

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Mon, 13 Jul 2009 19:14:35 Z

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~!

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Tue, 18 Aug 2009 17:18:48 Z

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.

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Wed, 19 Aug 2009 04:21:21 Z

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

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Thu, 15 Oct 2009 23:53:55 Z

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

TS Gateway Network access Policy engine received failure from IAS and the error was "16388"

Fri, 16 Oct 2009 18:52:23 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