In this blog I’d like to give some information on what Named Pipes are, what a Named Pipes connection looks like, and some common things to look for if there is an issue. I do hope you have read RPC to Go v.1 and v.2. It makes this much easier to understand. Either way, I’ll try to keep this blog from getting complicated. I considered making it ‘less technical,’ but if you’re reading about RPC, you’re likely technical to a degree.

A customer case I worked on inspired this blog. I went onsite as they had a problem that was approaching its first birthday. The resolution was two-fold. The initial problem was resolved using Process Explorer to find handle leaks (tool available at www.systinternals.com ). The other issue could only be found by someone having a watchful eye on the flow of traffic.

This particular issue involved one client machine (XP SP2), a web server (Server 2003 with IIS), and a database server (Server 2003 with SQL 2005). The users accessed a web-based application in which they performed multiple tasks in one window. During certain tasks, they received varying errors. Most of the errors pointed to the file not existing (even though it did) or the response for query timing out.

After the initial issue was resolved, I crossed my fingers and had the customer start testing. I focused on three key areas: the process explorer (or task manager), the number of concurrent connections to both servers (using “netstat –ano” from a command prompt at the servers), and a network capture. As the number of connections to the server grew I noticed that the response time from the server to the clients increased. I checked process explorer. System resources were minimal on the application server. The same was true for the SQL server.

I filtered my capture for web (TCP port 80) and SQL (TCP port 1433 natively) traffic. These connections opened and closed with no issues. Becoming more perplexed, I removed the filter. I noticed an alarming number of connections on port 445 between the web and SQL servers. The SQL server sent an overwhelming number of its responses with STATUS_PIPE_DISCONNECTED. As it turned out, in the application code, the “call socket” function for the SQL query procedure was written to use Named Pipes to connect to the SQL server. We configured SQL to listen for Named Pipes. Issues resolved. This must be configured.

WHAT ARE NAMED PIPES?

Named Pipes, like RPC, allow inter-process communications (IPC). According to MSDN, named pipes are used to transfer data between processes that are not related processes and between processes on different computers. The differences between inter-process communications protocols include their capabilities and the way the socket connections are made. For a complete list of differences, visit the following link.

http://msdn.microsoft.com/en-us/library/aa365574(VS.85).aspx#base.using_pipes_for_ipc

I just want to focus on a Named Pipes connection establishment. Unlike RPC, there is no end point mapper (EPM) connection. Inter-process communications between separate hosts must accomplish several things:

• A connection must be established on a pre-determined port number.
• A level of authentication must be agreed upon and then met.
• The remote process must be identified (even though the listening port is specified)
  • RPC uses a Universally Unique Identifier (UUID) for process identification
  • Named Pipes uses \\MachineName\IPC$

In order to accomplish all three, Named Pipes uses the Microsoft implementation of CIFS – the Server Message Block protocol, or SMB (blog coming within a couple months for clarity – promise. In the interim, here’s a great link: http://msdn.microsoft.com/en-us/library/aa365233.aspx )

Once there’s a connection to the IPC$ tree, subsequent RPC binds and calls are encapsulated in SMB and sent over the wire using TCP port 139 or 445 natively. When binding to a new process, an SMB Create Andx Request is sent. The request for the new process is \\machinename\IPC$\ServiceName i.e. “wkssvc,” which is the workstation service.

The RPC portion does have typical RPC information. There is still a UUID, a transfer syntax and OpNum. There is also an ‘AssociationGroupID.’ The latter isn’t covered in previous blogs and is overkill for this blog.

WHAT TO LOOK FOR

• Does my traffic hit the wire? If no:
  • Make sure the name is resolvable.
  • Make sure there is a route the resolved IP address
• Hits the wire, but no connection is made to the remote host:
  • Make sure the remote host is listening on port 139 or 445. The Server service must start.
  • Check for firewall issues at the client, server and intermediate network devices.
• Makes a connection but is reset during the SMB portion:
  • Make sure the authenticating user has rights to the IPC$ share on the remote host.
  • Check your auth type. The source host must have a route to the DC for Kerberos auth.
• SMB works fine, but RPC call gets a BIND_NAK response.
  • Verify the remote service is running. (Check the UUID in the RPC portion of the frame.) Refer to previous “RPC to Go” versions for more troubleshooting info.
• Looking at a network capture? IPC$ is good about sending error messages back. There aren’t many blogs for these errors. Carefully examine where, in transmission, the errors occurred.

NETWORK CAPTURES

This is a concise example of a Named Pipes connection to a server named Fabfile-1 using remote registry. I’ll show the SMB tree connection to IPC$, the connection to the remote procedure, and the relevant RPC info.

1. In the Tree Connect Request, notice the file structure:

2. In the Create Andx Request, notice WinReg is requested as a file in the IPC$ share

67 08:43:34.725799 192.168.3.100         192.168.3.5           SMB      NT Create AndX Request, FID: 0x4000, Path: \winreg
SMB (Server Message Block Protocol)
    SMB Header
        Server Component: SMB
        [Response in: 68]
        SMB Command: NT Create AndX (0xa2)
        NT Status: STATUS_SUCCESS (0x00000000)
        Flags: 0x18
        Flags2: 0xc807
        Process ID High: 0
        Signature: 0000000000000000
        Reserved: 0000
       Tree ID: 2048  (\\FABFILE-1\IPC$)
        Process ID: 792
        User ID: 2048
        Multiplex ID: 192
    NT Create AndX Request (0xa2)
      [FID: 0x4000 (\winreg)]

3. In the encapsulated RPC bind, notice the UUID for WINREG and the’ x86’ transfer syntax. This is presented to the remote process when a procedure call is made.

Ctx Item[1]: ID:0
        Context ID: 0
        Num Trans Items: 1
        Abstract Syntax: WINREG V1.0
            Interface: WINREG UUID: 338cd001-2244-31f1-aaaa-900038001003
            Interface Ver: 1
            Interface Ver Minor: 0
       Transfer Syntax[1]: 8a885d04-1ceb-11c9-9fe8-08002b104860 V2
            Transfer Syntax: 8a885d04-1ceb-11c9-9fe8-08002b104860  ver: 2

Hopefully you’ve gained some insight on Named Pipes, its connection establishment and some “gotcha” to keep an eye on. I do hope the “RPC to Go” saves a couple of support calls in the near future.

-Rich Chambers

There is often confusion about how a computer chooses which adapter to use when sending traffic. This blog describes the process by which a network adapter is chosen for an outbound connection on a multiple-homed computer, and how a local source IP address is chosen for that connection.

What is Source IP address selection?

Source IP address selection is the process by which the stack chooses an IP address.

Windows XP and Windows Server 2003 are based on the weak host model.

When a Windows Sockets program binds to a socket, one of the parameters that is passed in the bind() call is the local (source) IP address that should be used for outbound packets. Most programs do not have any knowledge of network topology, so they specify IPADDR_ANY instead of a specific IP address in their bind() call. IPADDR_ANY tells the stack that the program is going to let the stack choose the best local IP address to use;

Windows XP behavior

KB175396 - Windows Socket Connection from a Multiple-Homed Computer

The TCP/IP component of all Microsoft Windows operating systems prior to Windows Vista is based on a Weak Host model. This model gives program developers the greatest amount of leeway when they design programs that use the network and are compatible with Microsoft products. This model also puts the responsibility of the behavior of the networking program on the developers, because the developers specify how the program accesses the TCP/IP stack and responds to incoming and outgoing frames.

On a computer that has one network adapter, the IP address that is chosen is the Primary IP address of the network adaptor in the computer. However, on a multiple-homed computer, the stack must first make a choice. The stack cannot make an intelligent choice until it knows the target IP address for the connection.

When the program sends a connect() call to a target IP address, or sends a send() call to a UDP datagram, the stack references the target IP address, and then examines the IP route table so that it can choose the best network adapter over which to send the packet. After this network adapter has been chosen, the stack reads the Primary IP address associated with that network adapter and uses that IP address as the source IP address for the outbound packets.

Example:
Source supplied in the call: IPADDR_ANY
Target IP:192.168.1.5
Route Table:
Nic 1 - 192.168.1.10/32
Nic 1 - 192.168.1.11/32
Nic 2 - 10.0.0.10/32
Nic 2 - 10.0.0.11/32
The chosen source IP:192.168.1.10
The chosen source NIC: Nic 1

If the program specifies a source IP address to use in the bind() call, that IP address is used as the source IP address for connections sourced from that socket. However, the route table is still used to route the outbound IP datagrams, based on the target IP address. As a result of this behavior, the source IP address may not be the one associated with the network adapter that is chosen to send the packets.

Example:
Source supplied in the call:10.0.0.10
Target IP:192.168.1.5
Route Table:
Nic 1 - 192.168.1.10/32
Nic 1 - 192.168.1.11/32
Nic 2 - 10.0.0.10/32
Nic 2 - 10.0.0.11/32
The chosen source IP:10.0.0.10
The chosen source Nic: Nic 1 <- Note this is not the Nic the source IP is on.

Summary

If a source IP is not given the Primary IP address of the adapter with a route that most closely matches the target IP address is used to source the packet and the adapter that the Primary IP is associated with is used as the source adapter.

If the source IP is specified the adapter that is used to send the packet is the one with a route that most closely matches the target IP address and this may not be the adapter that is associated with the source IP.

Windows Vista/Windows Server 2008 behavior

Windows Vista and later are based on the strong host model. In the strong host model, the host can only send packets on an interface if the interface is assigned the source IP address of the packet being sent. Also the concept of a primary IP address does not exist.

Similar to XP when if a program doesn't specify a source IP, the stack references the target IP address, and then examines the entire IP route table so that it can choose the best network adapter over which to send the packet. After the network adapter has been chosen, the stack uses the address selection process defined in RFC 3484 and uses that IP address as the source IP address for the outbound packets.

Example:

Source supplied in the call: IPADDR_ANY
Target IP:192.168.1.5
Route Table:
Nic 1 - 192.168.2.10/32
Nic 1 - 192.168.1.11/32
Nic 2 - 10.0.0.10/32
Nic 2 - 10.0.0.11/32
The chosen source IP:192.168.1.11
The chosen source NIC: Nic 1

If the program specifies a source IP address, that IP address is used as the source IP address for connections sourced from that socket and the adapter associated with that source IP is used as the source interface. The route table is searched but only for routes that can be reached from that source interface.

Example:
Source supplied in the call:10.0.0.10
Target IP:192.168.1.5
Route Table:
Nic 1 - 192.168.1.10/32
Nic 1 - 192.168.1.11/32
Nic 2 - 10.0.0.10/32
Nic 2 - 10.0.0.11/32
The chosen source IP:10.0.0.10
The chosen source Nic: Nic 2 <- Note this is the Nic the source IP is on.
Note: the packet would be sent to the default gateway associated with Nic 2.

RFC 3484 and Source IP address selection

The last thing I want to talk about is RFC 3484.

Even though RFC 3484 says it only applies to IPV6 in Windows implementations IPV4 does follow the same rules when possible.

Windows Source IP V4 address selection:
Rule 1 Prefer same address (applies)
Rule 2 Prefer appropriate scope (applies)
Rule 3 Avoid deprecated addresses (applies)
Rule 4 - Prefer home addresses - does not apply to IP v4
Rule 5 Prefer outgoing Interfaces (applies)
Rule 6 Prefer matching label - does not apply to IP v4
Rule 7 Prefer public addresses - does not apply to IP v4
Rule 8a: Use longest matching prefix with the next hop IP address. (not in RFC!)
"If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. Similarly, if
CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then prefer SB. "
This says that the IP with the most high order bits that match the destination of
the next hop will be used.
Note: Rule 8 - Use longest matching Prefix is similar to rule 8a except the match
is with the destination IP address rather than the next hop IP address.

For example, consider the following addresses:

Client machine
IP Address
192.168.1.14 /24
192.168.1.68 /24
Default Gateway
192.168.1.127

The server will use the 192.168.1.68 address because it has the longest matching prefix.

To see this more clearly, consider the IP addresses in binary:

11000000 10101000 00000001 00001110 = 192.168.1.14 (Bits matching the gateway = 25)
11000000 10101000 00000001 01000100 = 192.168.1.68 (Bits matching the gateway = 26)
11000000 10101000 00000001 01111111 = 192.168.1.127

SkipAsSource

There is a new twist in the source IP selection process.

Note: There are two variants of the below mentioned hotfix; one for Windows Vista / Windows Server 2008 and one for Windows 7 / Windows Server 2008 R2.

975808 All IP addresses are registered on the DNS servers when the IP addresses are assigned to one network adapter on a computer that is running Windows Server 2008 SP2 or Windows Vista SP2

2386184 IP addresses are still registered on the DNS servers even if the IP addresses are not used for outgoing traffic on a computer that is running Windows 7 or Windows Server 2008 R2

After you install the hotfix discussed above, you can create IP version 4 (IPv4) addresses or IP version 6 (IPv6) addresses by using the netsh command together with the new "skipassource" flag. By using this flag, the added new addresses are not used for outgoing packets unless explicitly set for use by outgoing packets.

Note: This command only works when adding an address you can’t apply it to an address already on the machine. You would need to remove it and add it again.

Additional Information

Default Address Selection for Internet Protocol version 6 (IPv6)

For more information about Strong and Weak Host Models, see the following Cable Guy article:

http://technet.microsoft.com/en-us/magazine/2007.09.cableguy.aspx

The gethostbyname function has been deprecated. We recommend that you use the getaddrinfo function instead. However, we still cannot guarantee that primary IP address will be returned first.
For more information about the gethostbyname function, visit the following Microsoft Web site:

http://msdn2.microsoft.com/en-us/library/ms738524.aspx

For more information about the getaddrinfo function, visit the following Microsoft Web site:

http://msdn2.microsoft.com/en-us/library/ms738520(VS.85).aspx

- David Pracht

Network Monitor 3.3 has released and can be downloaded now!

Download details: Microsoft Network Monitor 3.3

For information about the features of this release, check out the following post on the Netmon blog:

Network Monitor 3.3 has arrived!

- Mike Platts

This post is meant to discuss the issues that can occur with Destination IP address selection and its affect on the DNS Round Robin process.

What is Round Robin and Netmask Ordering

DNS Round Robin is a mechanism for choosing an IP address from the list returned by a DNS server so that all clients won't get the same IP address every time. Netmask ordering is a mechanism for further optimizing which IP address is used by attempting to determine the closest result.

842197 Description of the netmask ordering feature and the round robin feature in Windows Server 2003 DNS http://support.microsoft.com/default.aspx?scid=kb;EN-US;842197

The netmask ordering feature is used to return addresses for type A DNS queries to prioritize local resources to the client. For example, if the following conditions are true, the results of a query for a name are returned to the client based on Internet protocol (IP) address proximity:

• You have eight type A records for the same DNS name.
• Each of your eight type A records has a separate address.

The round robin feature is used to randomize the results of a similar type of query to provide basic load-balancing functionality. In the earlier example, eight type A records with the same name and different IP addresses cause a different answer to be prioritized to the top with each query. Because a new IP address is prioritized to the top with each query, clients are not repeatedly routed to the same server.

The key points here are that DNS Round Robin only provides a simple load-balancing system by alternating the IP at the top of the list the DNS server returns and that Netmask Ordering will return a list with the "closest" IP at the top of the list the DNS server returns. Both are server side mechanisms commonly used to provide simple load balancing functionality.

Destination Address Selection

Destination address selection is how the client decides which destination IP address is selected when it gets a list of IP addresses.

IPv4: When using IPv4 only (Windows XP, Windows 2003 Server and prior),  destination address selection is fairly simple and done by selecting the IP address at the top of the list that was returned by the DNS server. This works well with DNS Round Robin as it lets the Server decide what address the client will use by putting it at the top of the list.

IPv6: IPv6 introduces a change in this behavior per RFC 3484.

RFC 3484 Default Address Selection for IPv6 - http://www.ietf.org/rfc/rfc3484.txt

6. Destination Address Selection

   The destination address selection algorithm takes a list of
   destination addresses and sorts the addresses to produce a new list.
   It is specified here in terms of the pair-wise comparison of
   addresses DA and DB, where DA appears before DB in the original list.
   The algorithm sorts together both IPv6 and IPv4 addresses.
   ...
   The pair-wise comparison of destination addresses consists of ten
   rules, which should be applied in order.  If a rule determines a
   result, then the remaining rules are not relevant and should be
   ignored.  Subsequent rules act as tie-breakers for earlier rules.

There are 10 rules, but it is rule 9 that we need to consider.

Rule 9:  Use longest matching prefix.
   When DA and DB belong to the same address family (both are IPv6 or
   both are IPv4): If CommonPrefixLen(DA, Source(DA)) >
   CommonPrefixLen(DB, Source(DB)), then prefer DA.  Similarly, if
   CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)),
   then prefer DB.

Essentially this says that we should use the longest match and not just pull the first IP address off the list. The key point to understand is that there is a change in behavior by design when IPv6 is on the system and that when IPv6 is installed Windows does not just pull the first IP address off the list.

The affect of RFC3484 on DNS Round Robin

When Vista clients (or XP clients with IPv6 installed) query DNS and receive a list of IP addresses, a destination selection algorithm kicks in and returns the destination address that has the longest prefix match (per RFC3484). This breaks the DNS server's site load balancing as follows.

In the case of Round-Robin this means we can't count on the randomization provided by the DNS server.

Example:

A client with an IP address of 192.168.0.1 queries for Webserver.test.net and receives the following list:

Webserver.test.net A 192.168.1.10
Webserver.test.net A 192.168.5.20
Webserver.test.net A 192.168.6.30
Webserver.test.net A 192.168.0.40
Webserver.test.net A 192.168.4.50

With RFC3484 in effect, the client will always use the 192.168.0.40 address as it is the longest match, negating the effects of DNS round-Robin.

In the case of NetMask Ordering, if some server’s address is “closer” to the client address and would be preferred, it will always get that address.

Example:

A client with an IP address of 192.168.0.1 queries for Webserver.test.net and receives the following list:

Webserver.test.net A 192.168.0.100
Webserver.test.net A 192.168.0.10
Webserver.test.net A 192.168.0.11
Webserver.test.net A 192.168.0.15
Webserver.test.net A 192.168.0.20

With RFC3484 in effect, the client will always use the 192.168.0.10 address as it is the longest match, negating the effects of netmask ordering.

You can see why by looking at the 4th octet in binary. You compare bits until you reach one that doesn't match. With a client IP address of 192.168.0.1, the comparison is 00000001.

11000000 10101000 00000000 00000001 = 192.168.0.1 = Client IP to match.
11000000 10101000 00000000 01100100 = 192.168.0.100 = (24 + 1 = 25 bits matching the client IP)
11000000 10101000 00000000 00001010 = 192.168.0.10 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00001011 = 192.168.0.11 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00001101 = 192.168.0.15 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00010100 = 192.168.0.20 = (24 + 3 = 27 bits matching the client IP)

Then the first entry from the longest match is chosen. In this case, 192.168.0.10.

An Alternative

You can change the behavior on Windows Vista SP1 and Windows Server 2008 with a client side registry entry documented in KB 968920.

Note: Windows 7 and Windows Server 2008 R2 will change the default behavior.

968920 Windows Vista and Windows Server 2008 DNS clients do not honor DNS round robin by default
http://support.microsoft.com/default.aspx?scid=kb;EN-US;968920

Symptom

By default, Windows Vista and Windows Server 2008 follow RFC 3484 for destination IP address selection, which does not honor DNS round robin. 

Resolution

To resolve this issue, add a registry key that disables subnet prioritization.

Add a new registry key with the following settings:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
DWORD = OverrideDefaultAddressSelection
Value data: = 1

- David Pracht

In Windows, the DNS Client service is the client component that resolves and caches Domain Name System (DNS) domain names. When the DNS Client service receives a request to resolve a DNS name that it does not contain in its cache, it queries an assigned DNS server for an IP address for the name. All computers that use DNS to resolve domain names (including DNS servers and domain controllers) use the DNS Client service for this purpose.

To extend or revise the DNS search capabilities, in Windows you have DNS domain suffix search list. By adding additional suffixes to the list you can search for short, unqualified computer names in more than one specified DNS domain. If a DNS query fails, the DNS client service can use this list to append other name suffix endings to your original name and repeat DNS queries to the DNS server for these alternate FQDNs (Fully Qualified Domain names).

When the suffix search list is empty or unspecified, the primary DNS suffix of the computer is appended to short unqualified names and DNS query is used to resolve the resultant FQDN. If no connection-specific suffixes are configured or queries for these connection-specific FQDNs fail, the client can then begin to retry queries based on systematic reduction of the primary suffix (also known as devolution). For example, if the primary suffix were "ad.contoso.corp", the devolution process would be able to retry queries for the short name by searching for it in the "contoso.corp".

When the suffix search list is not empty and has at least one DNS suffix specified, attempts to qualify and resolve short DNS names is limited to searching only those FQDNs made possible by the specific suffix list.

A change with respect to the DNS queries for multi-label names has been made in the default behavior of Windows Vista as compared to that of Windows XP. The change is as follows:

Windows XP:
When a Windows XP machine attempts to resolve an unqualified multi-label name, the
DNS client will attempt to resolve the name as specified, then will append the domains
that are listed in the DNS suffix search order.

Windows Vista:
When a Windows Vista machine attempts to resolve an unqualified multi-label name, the
DNS client will attempt to resolve the name as specified. The DNS suffix search
order will NOT be used.

Example:

Suppose you have a domain structure where you have the following DNS Suffix Search List:

Ad.Contoso.corp

Contoso.corp

From a command prompt, ping the hostname of a machine using the following
unqualified multi-label syntax:

<hostname>.site1

XP will attempt to resolve:

1. <hostname>.site1
2. <hostname>.site1.ad.contoso.com
3. <hostname>.site1.contoso.com

When viewed in a network capture:

192.168.1.1 192.168.1.5 DNS Query for hostname.site1 of type Host Addr on class Internet

192.168.1.5 192.168.1.1 DNS Response - Name Error 

192.168.1.1 65.52.16.29 DNS Query for hostname.site1.ad.contoso.corp of type Host Addr on class Internet

192.168.1.5 192.168.1.1 DNS Response - Name Error 

192.168.1.1 65.52.16.29 DNS Query for hostname.site1.contoso.corp of type Host Addr on class Internet

192.168.1.5 192.168.1.1 DNS Response - Name Error

1. <hostname>.site1

Vista does not attempt name resolution any further.

When viewed in network capture:

192.168.1.1 192.168.1.5 DNS Query for hostname.site1 of type Host Addr on class Internet

192.168.1.5 192.168.1.1 DNS Response - Name Error

This registry entry works for both Windows XP and Windows Vista

HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\AppendToMultiLabelName
Type = DWORD

Data:

• 0 (Do not Append Suffix)
• 1 (Append suffix)

If the registry entry is not present, the default in Windows XP is 1, and 0 in Windows Vista.

This registry changes and its effect apply only to the ping command, they do not apply to the Nslookup tool. This is because Nslookup contains its own DNS resolver and does not rely on the resolver built into the operating system (DNS Client). The DNS (multi-label) query packets sent by the nslookup tool will append the domains listed in the suffix search order irrespective of the registry key settings mentioned here.

Group Policy location (for Windows Vista only) - (run gpedit.msc):

Computer Configuration -> Administrative Templates -> Network -> DNS Client -> “Allow DNS Suffix Appending to Unqualified Multi-Label Name Queries”

Note: As with other GPOs, if you change the registry and there is also a GPO configured then GPO will override this registry value.

- Sneh Shah with additional information from Kapil Thacker

Hello All! It’s Brett Crane from the Networking teams here at Microsoft. Today I wanted to take a few minutes to talk a little about an issue that we have found regarding Terminal Services Gateway.

The problem that we have seen may occur when a TSG client tries to connect up through the Terminal Server Gateway. It gives an error stating the following information in the popup:

Terminal Services Resource Authorization Policy (TS RAP) 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 this remote computer through the TS Gateway server.

- The name specified for the remote computer does not match the name in the TS RAP.

Contact your administrator for further assistance.

But if you look at your Resource Authorization Policy there doesn’t seem to be any problem. “I am trying to connect to a client that’s listed in my policy!” Well, that just may be the case…

There are a few things you should check in your environment to see if you are in a situation where your clients will notice this behavior even though you are configured properly:

1. How are you requesting your resource from your client? By this I mean... go into the RDP Client settings and look at the "General" tab. Under Logon settings, what does your client have listed as "Computer"? This will be the backend resource when going through TSG. Are you requesting the resource by NetBIOS machine name or by FQDN?

2. Do you have TSG configured to use Active Directory Security Groups?

3. What is the FQDN of the domain your clients are connecting to?

4. What is the NetBIOS name of the domain your clients are connecting to?

So now you have done the research and answered the questions listed above… what is the problem? Well, basically, when your Fully Qualified Domain Name differs from your NetBIOS domain name and you are using Existing AD security groups, we don’t complete a process properly when we access security rights for a RAP check. So when you use an FQDN when trying to request a specific back-end resource the failure happens.

“What can we do?” Well, we have found out what the problem was and have fixed the issue in future releases of the product.

“What about those of us who are in the predicament now?” We’ve released a Hotfix that will resolve this issue. You can download the hotfix by going to this link:

http://support.microsoft.com/kb/967933

Once there, click on “View and request hotfix downloads” found at the top of the page.

* When choosing the hotfix you will notice that the “Product” is listed as “Windows Vista”. This is normal. Windows Server 2008 and Windows Vista are built around the same platform.

** This hotfix will be included in Windows Server 2008 Service Pack 2.

“With all that known, is there a workaround?”  Yes! The easiest workaround to this whole issue is to not use a FQDN to reference the back-end resource in your Remote Desktop Client. Just call the resource by its NetBIOS name and everything should work fine. If there is an instance to where you need to use the FQDN, then configure the option in your TSG Resource Authorization Policy to use TS Gateway managed groups instead of existing Active Directory Security groups.

I hope this information has been very informative. Until next time… Safe computing!

- Brett Crane