Windows 7 / Windows Server 2008 R2: Remote Desktop IP Virtualization
Happy Sunday everyone! It’s Day Eighteen of our Windows 7 / Windows Server 2008 R2 Launch Series – only four more days to go till the big day! Today we’re wrapping up our look at some of the new Remote Desktop Services features with a quick overview of Remote Desktop IP Virtualization (RD IP Virtualization). RD IP Virtualization allows IP addresses to be assigned to remote desktop connections on a per-session or per-program basis. Prior to Windows Server 2008 R2, every session on a remote desktop server had the same IP address. I’m sure some of you are wondering, “Well, OK – big deal. Why does that matter?” Think about applications that require a unique IP address for each instance of the application. Clearly having a single IP for all the sessions, can cause a number of application compatibility problems – consider the scenario below where the backend database server refuses the second and third client connections based on their use of the same IP address as the first connection.
OK, let’s take a quick look at the architecture of the RD IP Virtualization feature. User mode applications using WinSock will be able to get Virtual IP’s – the application itself does not need to be aware of RD IP Virtualization or need to be changed in any way. However, there are some caveats – services in Session 0 will not be virtualized, nor will applications and services running inside the a remote administrator session. In addition, applications that use named pipes or any other mechanism besides sockets will not be virtualized. The RD IP Virtualization Service depends on a valid DHCP Server being active. A pool of static addresses can also be configured. The actual process for assigning the IP Addresses is as follows (the diagram below shows the sequence):
The RD IP Virtualization Client Layered Service Provider (LSP) intercepts WinSock bind() and connect() calls. It calls the RD IP Virtualization Service and requests IP addresses
The RD IP Virtualization Service calls into the DHCP client. This call returns either a Machine IP (MIP), Virtual IP (VIP) or an access denied error
The RD IP Virtualization Client writes the VIP address to the WTSInfoClass which is returned by WTSQuerySessionInformation().
In order to determine what users have what IP’s at what time, WTSEnumerateSessions is called to get a list of sessions
For sessions in the list, WTSQuerySessionInformation is called to get the IP Address. The session is not virtualized if the call fails and GetLastError() returns ERROR_NOT_SUPPORTED or RPC_S_SERVER_UNAVAILABLE
WTSQuerySessionInformation is also called to retrieve the user name for the session
A couple of things to note about permissions – only administrators will be able to query and see virtual IP addresses from all sessions. Users will only be able to see the IP address of their session – they cannot see the VIP’s of other sessions – also, the Remote Desktop User group cannot query VIP’s for all sessions. Now let’s look at how applications get their IP Addresses and what RD IP Virtualization does in each case.
WinSock provides a pluggable Service Provider Infrastructure (SPI) that facilitates the interception of the WinSock API calls. Applications don’t know about the SPI – they make their normal WinSock API calls to get network addresses. Transport Service Providers (TSP) are services that set up the connection or transfer data. There are two different types of TSP – Layered Service Providers, that we mentioned above, that intercept the WinSock API calls, and Base Service Providers (BSP) that implement lower-level protocols such as TCP/IP. Namespace Providers (NSP) are services that associate network addresses with human-friendly names. Since the applications using Namespace Service Providers are also WinSock applications, they are intercepted and assigned VIP’s as well. The diagram below gives you an idea of how this all interacts:
社区：
