Terminal Services is both a collection of features and a platform for the TS team’s independent software vendor (ISV) partners. As a platform, we want to make sure that our components can be easily extended to support our partners’ vision of what Terminal Services can do—and we want to be sure that people know about those extensibility points.
One of the new Terminal Services roles in Windows Server 2008 is the TS Session Broker, responsible for routing incoming connections to the right terminal server. When the TS Session Broker gets an incoming connection, it checks first to see if that user has an existing session on a terminal server in the farm. If they do, then the connection goes to that terminal server. If they don’t, then the Session Broker will redirect to the terminal server with the lowest number of sessions. (The TS Session Broker supports redirection to Windows Server 2003 terminal server sessions, but the Win2K3 terminal servers can’t participate in load balancing.) In another blog entry, we’ve explained how CredSSP can even speed the redirection process to terminal servers.
But what about destinations, such as virtual desktops, blade PCs, or even PCs? While the built-in functionality of the TS Session Broker in WS08 only supports routing connections to terminal server sessions, we’ve created a set of APIs that ISVs can use to create connection brokers for other kinds of devices. Basically, these APIs allow you to lobotomize the TS Session Broker and replace its brain—its brokering mechanism—with a new plug-in. This plug-in can contain a new set of rules that support redirection to other types of destinations. It can also provide different means of deciding the best target for new connections, such as load balancing rules based on server resources or login time.
ISVs can extend the capabilities of TS Session Broker through the IWTSSBPlugin interface. This interface includes several benefits:
· It doesn’t need an agent on the client or terminal server to support connection brokering, so there’s never anything to update.
· Plug-ins using this interface can easily interact with other Terminal Services role services, such as Terminal Services Gateway (TS Gateway) and rely on information from TS Session Broker about session and computer states (available through WMI).
· The plug-ins can manage connections with client or server devices that support RDP 5.2 or later.
The IWTSSBPlugin interface can:
· Return the ID of the server to which TS Session Broker should direct the incoming connection.
· Direct an incoming connection to an external computing resource.
· Notify the plug-in that a change occurred in the server environment.
· Notify the plug-in that a change, such as a logon, logoff, disconnect, or reconnect, occurred in a user session.
You can learn more about the methods for the IWTSSBPlugin interface at http://msdn.microsoft.com/en-us/library/cc644955(VS.85).aspx and Roman Porter will include some code samples in a follow-up blog entry.
Finally, here’s a question to everyone reading this: When it comes to Terminal Services as a platform, what other extensibility points would you find useful?
PingBack from http://blog.a-foton.ru/2008/08/how-to-extend-the-ts-session-broker-to-support-vdi-part-1/
A smarter method of detecting bandwidth and latency and optimising display experience accordingly. Some way of feeding this back up to the application layer would be good.
Case in point: nothing worse than opening up IE in a session across a slow link only to find that the home page is set to a Flash-enabled site. Aargh!
The ability to access the Terminal Services API with Visual Basic .Net 2008 without having to wrap a bunch of C classes. If the ability to do this exists, please let me know.
For example, I'd like to write a program that will loop through all connections and log off anyone that is not an Administrator - and block anyone from logging on that is not an Administrator. That way I can upgrade our app that we host via TS without some clueless user logging on and ruining the upgrade.
Ask the Directory Services Team : MCS Talks Infrastructure Architecture joeware - never stop exploring…
Sorry for posting off topic!
But I have a real problem with RDP 6.1 on Windows Vista. I somehow screwed up my RDP-Sound which worked for a long time. Maybe you can explain the archtitecture and files and registry keys which are involved in playing RDP Sound on the server to the client.
When I play the sound on the console everything is fine, when I play the sound via RDP on another Vista machine I can't here any sound. I use the option to play the sound on the remote machine. There is no mute active. But there is also no visual indicator for playing sound. How to debug this case? Somehow I think it's muted but just doesn't show.
Maybe you can help. Thanks.
One option for the scenario you describe is to use the logoff command to log off all connections on the terminal server, then use change logon /drain to put the terminal server into drain mode. When a TS is in drain mode, users can only reconnect to disconnected sessions (which you already logged off), but you can still connect using a /admin connection.
Hope this helps,
What is the OS version of the machine you are conencting to? Also is this machine running server OS or Client OS? That makes a difference when you choose the option "Leave at remote computer" in your RDP client.
thanks for replying.
The OS version of the machine I connect to is Vista SP1 Business. The Client OS is also Vista SP1 Ultimate, so both of them should speak the same language (protocol) RDP 6.1.
If you could provide technical details of registry keys and drivers in use for playing sound over RDP protocol would be great.
As stated before it has worked at the beginning but somehow something has happend.
Is there a way to remove the rdp audio drivers and let the system automatically reinstall the needed drivers? Maybe this way it is possible the get the right settings again.
I think my problem has something to do with the audio redirection as described by larry osterman:
Adding the concept of an audio endpoint also makes some scenarios like the RDP scenario I mentioned above orders of magnitude simpler. Before Vista, remote desktop audio was implemented with a DLL that effectively replaced winmm on the RDP server and redirected audio to the RDP client. With this architecture, it would have been extremely difficult to implement features like per-application volume and other DSP related scenarios for remote clients. For Vista, remote desktop audio was implemented as an audio endpoint. As such, applications running on a remote desktop server function just like they would on the local machine - instead of bypassing the audio engine in the client application, remote desktop audio runs through the audio engine just like local audio does, it gets redirected at the back end of the engine - instead of playing out the local audio adapter, the audio is redirected over the RDP channel.
Thanks for your help.
Like many features of Windows Server, the TS Session Broker is a "platform" feature that provides basic functionality, but Microsoft wrote it in such a way that it's highly extensible. To that end, the Microsoft Terminal Server team has
Can you please provide the ability to have many people connect to the same RDP session for viewing. This could be used in a training scenario.
So how do we implement this? Has anyone found an implmentation for .net 2008
Matthew, since WS08 R2 has been releaed since this blog post we'd recommend that you build any brokering extensibility on the WS08 R2 platform. See our Code Gallery site for samples and more documents. archive.msdn.microsoft.com/rdsdev.