Terminal Services Team Blog : API

TS Session Broker Extensibility (Part 2)

termserv — Thu, 25 Sep 2008 18:41:52 GMT

In a previous blog post, Christa gave a high level explanation of the extensibility points we introduced to Session Broker (SB) in Windows Server 2008. In this post, we will dive a bit deeper to see how we can use SB Extensibility to build our own load balancing logic.

As Christa mentioned, when a new incoming connection is received by a terminal server, the terminal server contacts the SB for directions on where to redirect this new user. To answer this question, the SB must go through its load balancing logic. Our implementation of this logic consists of:

The SB looking through its database and picking the terminal server with the least number of sessions. (This is a slight simplification as the SB takes some other factors into account, but for now it is safe to ignore them for this discussion.)
The SB then returns that information to the terminal server to which the user initially connected.
The terminal server uses the returned data to execute the actual redirection.

Since the debut of Windows Server 2008, we’ve received some feedback regarding SB load balancing logic, labeling it too simplistic. While this may or may not be the case, with the extensibility points we’ve provided, you can fully replace the SB load logic with your own to load balance based on what might be important to you in your organization.

To implement your own load balancing logic and make use of these extensibility points, you will have to construct a COM server which implements the IWTSSBPlugin interface. This COM server (which I’ll refer to as an “extensibility plug-in”) will be called by the SB for passive notifications as well as requests to make load balancing decisions.

The IWTSSBPlugin interface has five methods which SB calls at different points. We will temporarily ignore WTSSBX_GetUserExternalSession and revisit it in a later blog post.

Let’s quickly review the four methods and when SB calls them:

· Initialize – called by SB when the SB service starts to allow the plug-in to do its initialization.

· Terminated – called by SB when the SB service shuts down to allow the plug-in to do its termination cleanup.

· WTSSBX_GetMostSuitableServer – called by SB when a load balancing decision needs to be made. We can use this method to override the SB’s default load balancing logic.

· WTSSBX_MachineChangeNotification – called by SB when a change occurs in one of the servers in the farm. We can use this method to get information on new terminal servers that have joined or left the farm.

· WTSSBX_SessionChangeNotification – called by SB when a change occurs in a session on a terminal server that is part of the farm. We can use this method to detect session state changes (such as when a user disconnects from his session).

The order in which these methods are called depends on what is happening in the farm. Let’s first look at the machine notifications:

When a server joins a farm the following notifications are called on the plug-in in the following order:

WTSSBX_MachineChangeNotification is called with WTSSBX_NOTIFICATION_TYPE set to WTSSBX_NOTIFICATION_ADDED. This notification also provides the unique Machine ID which SB will use to identify this terminal server in all subsequent calls to the plug-in.
WTSSBX_SessionChangeNotification is called with WTSSBX_NOTIFICATION_TYPE set to WTSSBX_NOTIFICATION_RESYNC. This notification reports the state of the sessions already existing on the terminal server joining the SB.
WTSSBX_MachineChangeNotification is called with WTSSBX_NOTIFICATION_TYPE set to WTSSBX_NOTIFICATION_CHANGED. This notifies the plug-in that the terminal server is now part of the farm and is ready for incoming connections.

Similarly, when a server leaves the farm WTSSBX_MachineChangeNotification is called with WTSSBX_NOTIFICATION_TYPE set to WTSSBX_NOTIFICATION_REMOVED.

The session notifications are also quite simple:

When a user connects to a terminal server in the farm, a WTSSBX_SessionChangeNotification is called with WTSSBX_NOTIFICATION_TYPE set to WTSSBX_NOTIFICATION_ADDED.
Similarly, when a user logs off a session WTSSBX_NOTIFICATION_REMOVED is used.
Session state changes are called through WTSSBX_SessionChangeNotification with WTSSBX_NOTIFICATION_TYPE set to WTSSBX_NOTIFICATION_CHANGED.

These notifications provide the plug-in with enough information to make load balancing decisions.

The actual decisions are communicated to the SB via the WTSSBX_GetMostSuitableServer method. Let’s look back at the original explanation of how the SB load balancing logic is invoked to see where in that process WTSSBX_GetMostSuitableServer is called.

When a new connection comes to a terminal server, the server asks the SB to provide the Machine ID of the terminal server which has an existing session for the user. The SB queries its database and if no such session exists, the SB uses its standard load balancing logic to determine a Machine ID to which the user should be redirected. At this point, instead of returning this ID to the terminal server, the SB calls into the plug-in via the WTSSBX_GetMostSuitableServer method and passes the Machine ID it has just calculated as one of the parameters. The plug-in can then change this parameter to redirect to a different terminal server than the one originally intended.

So we see that by returning a different Machine ID in response to a WTSSBX_GetMostSuitableServer method call, we can override the default SB load balancing logic and provide our own.

In the next blog post, I will provide some design guidelines on how to construct your plug-in as well as an example of a plug-in that does resource-based load balancing.

How To: Extend the TS Session Broker to Support VDI (Part 1)

termserv — Wed, 13 Aug 2008 04:09:25 GMT

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?

Dynamic Virtual Channels

termserv — Thu, 20 Sep 2007 17:02:00 GMT

An important goal of the Terminal Services (TS) team is to provide a product that can easily be extended by third parties to better meet their needs. While TS has always supported virtual channels, they had their limitations, including the limited number of channels and the difficulty involved in writing virtual channel applications. For the 6.1 version of the client, and Windows Vista SP1 or Windows Server 2008 on the server side, Dynamic Virtual Channels (DVCs) can be used. DVCs address the limitations of the old virtual channels. This article outlines the basics of DVCs and shows how to write a complete DVC application and client plug-in to add basic file transfer support to Terminal Services.

DVC Basics

What are Virtual Channels?

Virtual channels are bi-directional connection streams provided through the RDP protocol. Virtual channels allow third parties to establish a data pipe between the TS client and server to extend the functionality of the Remote Desktop Protocol (RDP). Examples of extra functionality provided through virtual channels are cross-TS-connection clipboard, drive, printer and smart card redirection. There are two types of virtual channels: static and dynamic. Due to the limitations of static virtual channels referenced above, dynamic virtual channels are the preferred way to extend TS functionality.

Client and Server DVC components

On the TS client side the DVC is handled through a TS client plug-in. This plug-in is a COM object, whose registered CLSID is passed to the TS client through the registry (see the attached sample). The COM object must implement the IWTSPlugin interface. On the server side any arbitrary component running in the current session can use the WTS API to establish the DVC connection, as well as send and receive data.

Channel Initialization and Usage

Client Side

1) The TS client loads the DVC plug-ins from the registry:

HKCU\Software\Microsoft\Terminal Server Client\Default\AddIns

2) The TS client invokes the Initialize() method on IWTSPlugin; and passes an IWTSVirtualChannelManager

HRESULT CTsClientPlgn::Initialize(

IWTSVirtualChannelManager *pChannelMgr

)

3) During initialization, or at any arbitrary point, the plug-in is expected to use the IWTSVirtualChannelManager to create a connection listener and pass an IWTSListenerCallback

hr = pChannelMgr->CreateListener(TSTELE_CHANNEL_NAME,

0,

pListenerCallback,

&pListener);

4) IWTSListenerCallback is notified of connection requests on the channel; IWTSListenerCallback receives an IWTSVirtualChannel for every new connection and returns a corresponding IWTSVirtualChannelCallback

HRESULT CTsListenerCallback::OnNewChannelConnection(

IWTSVirtualChannel *pChannel,

BSTR data,

BOOL *pbAccept,

IWTSVirtualChannelCallback **ppCallback )

{

*pbAccept = TRUE;

_pChannelCallback->AddRef();

*ppCallback = _pChannelCallback;

pChannel->AddRef();

_pChannel = pChannel;

5) The plug-in uses the IWTSVirtualChannel to write to and close the channel

hr = _pChannel->Write(sizeof(HRESULT), (PBYTE) &hr, NULL);

hr = _pChannel->Close();

6) The plug-in receives incoming data and channel close notifications on the IWTSVirtualChannelCallback

HRESULT CTsChannelCallback::OnDataReceived(

ULONG cbSize,

BYTE *pBuffer

);

HRESULT CTsChannelCallback::OnClose();

Server Side

1) An application issues a WTSVirtualChannelOpenEx with the WTS_CHANNEL_OPTION_DYNAMIC flag to establish the DVC connection.

hWTSHandle = WTSVirtualChannelOpenEx(

WTS_CURRENT_SESSION,

TSTELE_CHANNEL_NAME,

WTS_CHANNEL_OPTION_DYNAMIC);

2) Using the WTS handle received from the previous call a WTSVirtualChannelQuery is used to get a read/write file handle for the channel

NOTE: DuplicateHandle() is needed to be able to access the channel after freeing hWTSHandle (i.e. calling WTSVirtualChannelClose()). The output handle from DuplicateHandle() needs to be closed using CloseHandle().

BOOL bSucc = WTSVirtualChannelQuery(

hWTSHandle,

WTSVirtualFileHandle,

&vcFileHandlePtr,

&len);

...

HANDLE hWTSFileHandle = *(HANDLE *)vcFileHandlePtr;

...

bSucc = DuplicateHandle(

GetCurrentProcess(),

hWTSFileHandle,

GetCurrentProcess(),

&_hDVC,

0,

FALSE,

DUPLICATE_SAME_ACCESS);

3) Overlapped ReadFile() and WriteFile() calls are issued on the channel file handle

bRet = ReadFile(_hDVC, ReadBuf, CHANNEL_PDU_LENGTH, &BytesRead, &ovr);

bRet = WriteFile(_hDVC, pPacket, RequiredLen, &BytesWrit, &ovr);

4) To close the connection the channel file handle is closed

CloseHandle(_hDVC);

Sample: TS-Teleport

TS-Teleport is a sample application to demonstrate the end to end use of the DVC APIs. It implements a simple protocol to transport files from the TS server session to the desktop of the client machine. It does not rely on similar TS functionality like drive redirection.

The server component is a shell extension that adds an “RDP Client Desktop” entry to the “Send To” context menu. Upon receiving the list of highlighted files which the user elected to “Send to the RDP Client Desktop”, the shell extension opens the DVC and streams the files through. Upon receiving the file names and data, the client component creates those files and directories on the desktop.

The server sends a series of state dependent requests to the client by writing on the DVC and for each request it reads the status through a DVC read. Requests are start and end pairs for files and directories and data packets for file data.

Sample Files and Instructions

Please follow the link below to access sample files and instructions, including source code and installation how-to.

http://blogs.msdn.com/ts/pages/ts-teleport-sample-instructions.aspx

Author: Ahmed Tolba (SDE TS Devices Team)

Credits: Eric Holk, Zardosht Kasheff, Josh Rosenberg and the rest of the TS Devices Team

Writing a Desktop Sharing Application

termserv — Fri, 23 Mar 2007 19:37:00 GMT

Windows Desktop Sharing (WDS) API provides a rich set of API to share your complete desktop or just individual applications. Below is a step-by-step guide to write a sharing application. I have chosen C#/.Net to make things simpler and we will be using Visual Studio 2005 as the IDE.

Windows Desktop Sharing API Introduction:

Windows Desktop Sharing API allows a Windows Desktop Session to be shared across multiple viewers. More information on the API can be found on MSDN at http://msdn2.microsoft.com/en-us/library/aa373852.aspx. You could also refer to the Windows Desktop Sharing API Introduction blog. Windows Meeting Space & Remote Assistance use WDS API for collaboration and assistance scenarios. Similarly, you can write applications to achieve your sharing, collaboration, assistance, administration and deployment scenarios.

Object Model of the API: API currently is published as an in-proc COM DLL (RdpEncom.dll) and is available in Vista. There are 2 primary objects that can be created:

1. IRDPSRAPISharingSession - COM object that enables sharing of desktop
2. IRDPSRAPIViewer - ActiveX control that can be embedded into a host window for viewing the sharing session.

Other objects can be created or queried from these 2 primary objects. There is also an event sink interface (IRDPSessionEvents) that the API would use to report events to the application. Applications should sink appropriate events as needed.

Desktop Sharing Application: Writing a desktop sharing application involves writing 2 different applications - one for sharing and the other for viewing. These 2 applications can be written as one application working in different modes similar to Windows Meeting Space.

Sharer Application: You can choose to create either a console based application or windows based application. It is nice to have a GUI interface to control the viewers, start/stop sharing etc., so let's build a windows application. To create a sharer application you will need to first add a reference to RdpComApi 1.0 Type Library (rdpencom.dll in %windows%\system32 directory) to your project.

Starting the sharing Session: To start the sharer, first create an instance of RdpSession Class and then subscribe to the events published by the WDS API. For this you will need to declare an event handler of the corresponding delegate signature. Here is an example of declaring and defining an event handler:

private void OnAttendeeConnected(object pObjAttendee)

{

IRDPSRAPIAttendee pAttendee = pObjAttendee as IRDPSRAPIAttendee;

pAttendee.ControlLevel = CTRL_LEVEL.CTRL_LEVEL_VIEW;

LogTextBox.Text += ("Attendee Connected: " + pAttendee.RemoteName + Environment.NewLine);

}

Above is the event handler for the delegate:

void _IRDPSessionEvents_OnAttendeeConnectedEventHandler(object pAttendee);

This event is fired by the API when an attendee connects to the sharing session and will pass in the attendee instance to the event handler. Use that attendee instance to query information and also to set control level of the attendee. Control levels define the level of information that an attendee gets. In this implementation of event handler, attendee is given view control which means that attendee can only see the sharing session but cannot interact with it. We also print out some message to a text box so that the user who is running the sharing app can see the status of attendees connecting and disconnecting. Similarly we add event handlers for attendee disconnected and control level change requests.

After subscribing to the events that we are interested in, start the sharing session by calling Open() method on the RdpSession object.

// Create a new RdpSession instance

m_pRdpSession = new RDPSession();

// Subscribe to events

m_pRdpSession.OnAttendeeConnected += new _IRDPSessionEvents_OnAttendeeConnectedEventHandler(OnAttendeeConnected);

m_pRdpSession.OnAttendeeDisconnected += new _IRDPSessionEvents_OnAttendeeDisconnectedEventHandler(OnAttendeeDisconnected);

m_pRdpSession.OnControlLevelChangeRequest += new _IRDPSessionEvents_OnControlLevelChangeRequestEventHandler(OnControlLevelChangeRequest);

// Start the Sharing Session

m_pRdpSession.Open();

LogTextBox.Text += "Presentation Started. Your Desktop is being shared." + Environment.NewLine;

Creating an Invitation: Create an invitation that can be sent to attendees so that they can use the invitation to connect to the sharing session. The invitation can be sent to the attendees using any mechanism desired. For example, Remote assistance allows to save the invitation and send it by email or to send through IM. Windows Meeting space uses "People Near Me" feature to identify and then send the invitations. In this implementation, let's take a simple approach and save it to a file. Here is the corresponding code:

// Create invitation.

IRDPSRAPIInvitation pInvitation = m_pRdpSession.Invitations.CreateInvitation("WinPresenter","PresentationGroup","",5);

string invitationString = pInvitation.ConnectionString;

// Save Connection String to File

WriteToFile(invitationString);

Stopping the Sharing Session: To stop the sharing session, call close method on the RdpSession class instance. Here is the code:

m_pRdpSession.Close();

LogTextBox.Text += "Presentation Stopped." + Environment.NewLine;

Marshal.ReleaseComObject(m_pRdpSession);

m_pRdpSession = null;

You may notice that I am calling ReleaseComObject. Reason being that once Close() is called then that RdpSession class instance cannot be used anymore. We will need to create another instance of RdpSession class to restart sharing.

Viewer Application: You will need to create a windows application and then add RdpViewer Class as an ActiveX control. Adding ActiveX controls to Windows Forms is a good resource to learn about adding ActiveX controls in Visual Studio IDE. Visual Studio will create an instance of AxRdpViewer and you can resize the ActiveX control to fit to your needs on the Windows Form. You can also choose to create this ActiveX control dynamically and place it in the host Form.

Connecting to the Sharing Session: First subscribe to the events that you are interested in. The easiest way in Visual Studio to add event handlers to an event is to click on the Events lightning bolt in the property browser of ActiveX control, then double-click on any events you wish to handle. An empty method signature and the appropriate event hooking and unhooking code are then emitted for you. Subscribe to OnConnectionEstablished, OnConnectionTerminated, OnConnectionFailed and OnError events at a minimum so that you can report status and errors, if there are any. Here is some code for OnError event handler method:

private void OnError(object sender, _IRDPSessionEvents_OnErrorEvent e)

{

int ErrorCode = (int)e.errorInfo;

LogTextBox.Text += ("Error 0x" + ErrorCode.ToString("X") + Environment.NewLine);

}

To connect to the Sharing Session, you will need an invitation. Since we saved the invitation created in the Sharing Application as a file, let's just read the file into a string. Then call Connect method with the invitation file. Please note that we are passing empty string as password. Since we created the invitation on the sharing application with empty string as the password this would work. This is not advised if you are writing a commercial application because anyone can connect to your Sharing Session if they can get hold of the invitation.

Here is the code to connect to the Sharing Session:

string ConnectionString = ReadFromFile();

if (ConnectionString != null)

{

pRdpViewer.Connect(ConnectionString, "Viewer1", "");

}

Once the connection is succesfully established with sharing session, API will fire OnConnectionEstablished event or OnConnectionFailed event if the connection fails.

Disconnecting from the Sharing Session: To disconnect from the sharing session, call Disconnect method on the AxRdpViewer class instance. Here is the code:

pRdpViewer.Disconnect();

API will fire OnConnectionTerminated event once the viewer is disconnected from the sharing session.

Wrapping up:

This is all you need to do to share your desktop. Obviously you will need to do much more if you want to have control on who is connected, display a nice GUI for attendee information, kick attendees etc. This will give you a good start and explore the API provided by WDS API to achieve your other scenarios.

Sample Application:

WinPresenter is a sample Desktop Sharing Suite of applications encompassing both Sharing and Viewing application. You should be able to find source code including the snippets above. I left out error checking, printing messages to user etc., so please modify it to your needs.

Usage of Sample Applications:

Sharer Application: Run winsharer.exe. Invitation file will be saved to the current directory with file name inv.xml

Viewer application: Run winviewer.exe %path to invitation file%. Either specify the directory where you have run the winsharer or copy inv.xml to some other location and specify the path. If there is no path specified it will try to read inv.xml from the current directory.

Windows Desktop Sharing API

termserv — Thu, 08 Mar 2007 19:07:00 GMT

Windows Desktop Sharing API Basics

Microsoft Terminal Services provides a public "Windows Desktop Sharing API" based on RDP to enable customers to write custom collaboration solutions in Windows Vista. These API's are available on all the SKU's starting with Windows Vista Home Basics. You can write a customized collaboration application that can do either or all kinds of sharing including desktop, application and region. Useful MSDN documentation of these API's is available at:

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

Highlights:

Windows desktop sharing is a multi-party screen sharing technology in Windows Vista, wherein a local desktop can be transmitted over an RDP connection without creating an additional session.

a) Connectivity: Windows Desktop Sharing does support connectivity to intelligent appliances, wireless devices and PC's in uPnP framework and also teredo tunneling to provide connectivity to IPV6 machines behind IPV4 NAT's.
b) Reverse Connect: It is an interesting feature, where sharer can connect to the viewer if viewer cannot reach the sharer via direct connect. For example, the viewer may not be able to connect to the sharer because of network address translation (NAT).
c) Authentication: API supports creating tickets/ invitations on the sharer side that can be routed by the API consumer application or IM's to the viewers.
d) Sharing Modes: API supports sharing desktop, application or a region.
e) Control Modes: Sharer always has full control of his desktop/ application/region. Each viewer can be tuned to no-view/view or interactive control. Sharer controls the control level for each viewer and viewers can request promotion in control level to sharer.
f) Smart sizing: Smart sizing is well-supported and is a client/ viewer option that can be turned on and off.
g) Virtual channels: Virtual channels can be used to exchange other data like documents, application data, chat messages etc.

Microsoft Collaboration Solutions:

"Windows Meeting Space" and "Remote Assistance" in Windows Vista are based on these public API's -

a) Remote Assistance: Remote assistance is 1:1 sharing mechanism wherein the helper (expert) can get to see and control novice's desktop. Application and region sharing is not exposed via RA in Windows Vista.
b) Windows Meeting Space: Windows Meeting Space is a peer-to-peer application that enables multiple users to conduct virtual meeting. Participants can share their desktop, documents and applications, exchange notes, give presentations by connecting to a network projector. Network projector in this scenario is a intelligent device in uPnP framework that plays a role of viewer.

API support versus perceived limitations in Windows Meeting Space:

a) Multi-monitor remoting - In Windows Meeting Space the sharer does not allow sharing of both or the secondary monitor in multi-monitor arrangement. However, the API allows you to attach the appropriate region of the composite monitor and hence it can be flexible enough to share any particular monitor, if needed. It could get very interesting with more than 2 monitors.
b) Easy Switching among desktop/ application sharing - "Windows Meeting Space" doesn't allow flexible switching between desktop and application sharing. You need to select either one of them. To switch you need to restart the session (Meeting Space session). The API allows you to switch between various sharing methods without closing the session.
c) Application Sharing (minimize->on-screen) - In "Windows Meeting Space" when the viewer has the control of the sharer's application and viewer minimizes the application then he/she doesn't have a way to work on that application further (until sharer clicks on the taskbar on the minimized application). The API does provide a way for the viewer to bring back the minimized application on desktop. Hence a better user experience can be provided on the viewer side.

Frequently Asked Questions:

What is the behavior with DWM?
Windows desktop sharing API turns off "Desktop Windows Manager/ DWM" on the sharer's machine when the desktop/ application sharing is active.
What is the behavior when "Secure Desktop" pops up while sharing?
"Pause screen- Black screen with two bars(indicating pause) at lower right" is remoted when secure desktop (UAC prompts) is up on sharer's machine, when sharing process is run as a non-system process. Also, the pause screen is shown if sharer opts to suspend graphics encoding for some reason via IRDPSRAPISharingSession::Pause.
Why does the remoted screen refresh for all connected clients whenever a new viewer joins the session?
The protocol tries to make sure that the graphics updates sent to all the connected viewers are synchronized. To do so, it needs to refresh the graphics stream for each previously connected client.
Why does sharer's monitor flash while sharing? Is there anything that I can do to avoid multiple set of DWM on/off flashes, typically in 1:M scenarios?
Currently, the protocol does not support remoting glass so it turns DWM off while sharing. Turning DWM off/ on causes a flash on the sharer's monitor [only in case if DWM was on]. You cannot entirely avoid on/off flash but you can avoid multiple on/off flashes. Depending on your preference you can select dynamic/ static loading of mirror driver. In static mode, sharer will load mirror driver [& turn DWM off if it is on] only once when it puts a session in active state and unload mirror driver [& turns DWM on if it was on earlier] only once when it puts session in inactive state. So, in static mirror driver load mode you won't see multiple set of DWM on/off flashes. However, note that in static mirror driver load DWM/ glass will be turned off even if there are no clients connected. In dynamic mirror driver load mode DWM/ glass is turned off only when there is at least one connected client and is turned on whenever there are no connected clients. There is a property DrvConAttach that you can set via IRDPSRAPISessionProperties to control this behavior.
Can multiple viewers have simultaneous control of sharer's desktop/ application?
Yes. Sharer can permit each viewer a none, view only OR interactive control. Of course, viewers input (mouse movements/ keyboard input) will only be directed to sharer's machine when viewer has interactive control and the active X control has focus.
Can you force sharer or viewer[in reverse connect scenario] to use particular port/ protocol for listening for connection and communication?
Yes. You can use IRDPSRAPISessionProperties property - PortId and PortProtocol to use specific port and protocol.
Why does requesting color depth change from the viewer via IRDPSRAPIViewer::RequestColorDepthChange fail?
Currently, protocol does not allow viewer to request/ control the color depth change. Only the sharer can control the color depth via put property IRDPSRAPISharingSession::put_ColorDepth. IRDPSRAPIViewer::RequestColorDepthChange returns E_NOTIMPL in the current release.
Does the API support clipboard?
No. Windows Desktop Sharing API doesn't provide automatic text/ file clipboard solution yet. This might be a good proposal for new feature in future versions.
Does the API support Audio/ Multi-media?
No audio can be redirected to and fro from viewers/ sharer via "Windows Desktop Sharing API". This might be a good proposal for new feature in future versions.