TS-Teleport: Sample Instructions

TS-Teleport: Sample Instructions

  • Comments 30

Installation

To install the sample the user needs to register both client plug-in and shell extension on the TS client and server machines respectively.

NOTE: The VS support DLLs need to be copied to the same path as the sample DLLs.  Please choose the right VS support DLLS for the architecture (x86/x64) and binary type (debug/release); e.g.:

"%programfiles(x86)%\Microsoft Visual Studio 9.0\vc\redist\Debug_NonRedist\x86\Microsoft.VC90.DebugCRT\*"

Client Installation (on the TS client machine)

1.       Copy the right VS support DLL files to the same directory as TsTelePlgn.dll

2.       Register the Plug-in COM object: “RegSvr32 TsTelePlgn.dll”, this will:

a.       Register the COM object

b.      Add the following TS specific key/value to load the plug-in

HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default\AddIns\TsTelePlgn

Name    REG_SZ    {0350DF61-30CF-451B-B292-3CE3A330F958}

Server Installation (on the TS server machine)

3.       Copy the right VS support DLL files to the same directory as TsTeleport.dll

4.       Register the shell extension COM object: “RegSvr32 TsTeleport.dll”, this will

a.       Register the COM object

b.      Add the shell extension keys/values

5.       Manually create the following empty file to trigger loading the COM object by Shell

a.       Locate the SendTo folder (for the current user or all users); e.g.:

C:\Users\<User>\AppData\Roaming\Microsoft\Windows\SendTo

b.      Create an empty file with the following name: “RDP Client Desktop.tsteleport

Usage

1.       Use the machine with the client plug-in to establish a TS connection

2.       TS to the server with the shell extension

3.       Highlight a group of files and/or directories and right-click

4.       Select the send-to menu and then “RDP Client Desktop”

Debugging and Troubleshooting

Attach a debugger to the running instance of mstsc.exe hosting the client side plug-in, or explorer.exe hosting the shell extension and watch messages in the debugger output area in case of errors.

Sample Assumptions

This section outlines assumptions made to simplify the sample and focus on demonstrating the DVC API usage.  The reader is advised to go through it if basing an application on the provided sample.  If the intent is just familiarity with DVCs, this section can be skipped.

Protecting State and State Sensitive Protocol

The TS client serializes calls to the plug-in so we don’t use a lock to protect state changes.  Moreover, we are guaranteed to have only a single DVC connection from our server which allows for a state-ful protocol.  On the server side explorer calls our methods synchronously and doesn’t allow a new “Send to RDP Client Desktop” invocation while one is in progress.  The whole scheme does not require the use of any locks on the client or the server.  In real-life applications most of these assumptions are invalidated, which requires caution when using this code as core for other implementations.

One COM Object

Another simplification is the use of the same COM object as the client plug-in, listener and channel callbacks.  This might or might not be the case in more complex protocols depending on the problem addressed and the assumptions.

Error Reporting and Verbosity

Again TS-Teleport is far from an application with a fully furnished UI.  The UI consists of a single dialog box that echoes the success or failure of transporting the requested set of files.  More verbose output for debugging and understanding is provided through the debugger spew.

Shell Blocking

Again this is another limitation since we do all the teleportation on a synchronous shell call, certain shell features are blocked during the whole operation which can take a significant time depending on the cumulative size of the transported files.

Sample Code

The sample code is attached to this article.  Windows Server 2008 SDK is needed to get the DVC definitions.  Also attached is the VS2008 Beta-2 solution file for the sample (Visual Studio 2008 Beta2 is needed from the microsoft.com website to compile the sample).

Build FAQ:

Why can’t I open the .sln or .vcproj files with Visual Studio 2005?

Because you need Visual Studio 2008 (or VS 2008 Beta 2) as previously stated (link below).

Why am I getting one or more of the following erros?

fatal error C1083: Cannot open include file: 'TsVirtualChannels.h': No such file or directory

error C2065: 'WTS_CHANNEL_OPTION_DYNAMIC' : undeclared identifier

error C3861: 'WTSVirtualChannelOpenEx': identifier not found

 

Since Windows Server 2008 SDK in the link below needs to be installed and configured with Visual Studio (i.e. add the new SDK include and lib directories to VS – Tools->Options->Projects and Solutions->VC++ directories).

Links:

Windows Server 2008 SDK:

http://www.microsoft.com/downloads/details.aspx?FamilyId=58726ACA-8D84-4683-8959-BE0038DA7084&displaylang=en

VS2008 Beta2:

http://msdn2.microsoft.com/en-us/vstudio/aa700831.aspx

More information about Dynamic Virtual Channels can be found on MSDN:

http://msdn.microsoft.com/en-us/library/windows/desktop/bb540855(v=vs.85).aspx

 

Leave a Comment
  • Please add 7 and 7 and type the answer here:
  • Post
  • When I tried to register the COM Object, I get the following error :

    //////////////////////////////////////////

    Debug Error!

    Program: c:\WINDEOS\system32\regsvr32.exe

    R6034

    An application has made an attempt to load the C runtime library without using a manifest.

    This is an unsupported way to load Visual C++ DLLs. You need to modify your application to build with a manifest.

    For more information, see the "Visual C++ Libraries as Shared Side-by-Side Assemblies" topic in the product decumentation.

    //////////////////////////////////////////

    Given that I put the following files with the output dll file :

    Microsoft.VC90.DebugCRT.manifest

    msvcm90d.dll

    msvcp90d.dll

    msvcr90d.dll

  • Is there a way to load the Static Virtual Channels by RDP 6.1 I mean on windows Vista or Server 2008.

    Since the "WTSVirtualChannelOpenEx" can be used only on Windows 2008 then we have to develop two versions of the server side, one for Win 2008 that accepts both the dynamic and static channels and the other version for windows 2003 that accepts only the static channels.

    I'd like to find a way to develop a server application that can work on both 2008 and 2003 and accept sessions from any windows version (vista, XP, ...).

    Regards

  • Mohammed N,

    Assuming you are only using static channels, WTSVirtualChannelOpen still works on Windows Server 2008 the same as it did in previous versions. You don't have to use WTSVirtualChannelOpenEx unless you need dynamic channels.

    If you want to you WTSVirtualChannelOpenEx, you can use GetProcAddress to see if the function exists. If it does, you can use it, otherwise you can fall back on WTSVirtualChannelOpen. This will let you keep one version of your server code, which uses the newer APIs if they are present.

    -Eric

  • Thanks Eric for replying.

    In fact I'd like to continue using only static channels, but the problem I faced that Static Virtual Channels can't be integrated with RDP 6.1 running on Windows Vista or 2008. Am I right?

    As you may know, the Static Virtual Channels were registered to the RDC by adding a registry key in

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

    This is working fine on Windows XP, 2003. But when I try to do this for Windows Vista or 2008 to load the same SVC, the RDC will not connect to the server! is there another way to register the SVC?

    If I find a way to do that I will continue to use the same SVC and "WTSVirtualChannelOpen", which is better for me.

    Please, I am waiting your reply

  • Hi again, Mohammed. We have not changed the way static virtual channel plugins are registered in Windows Vista or Windows Server 2008. The way you are describing should work. Is it possible that your plugin is returning some error that it doesn't return on earlier versions of Windows?

    I'd suggest trying to run RDC under a debugger, and see if you can find anything interesting in your code that way.

    -Eric

  • Hi again, Mohammed. We have not changed the way static virtual channel plugins are registered in Windows Vista or Windows Server 2008. The way you are describing should work. Is it possible that your plugin is returning some error that it doesn't return on earlier versions of Windows?

    I'd suggest trying to run RDC under a debugger, and see if you can find anything interesting in your code that way.

    -Eric

  • Thanks agian Eric for replying and for this information.

    I added a key into the key "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default\AddIns" for my virtual channel and added the value:

    Name REG_SZ [Virtual Channel DLL path]

    in you sample code, you are registering the COM object first by regsvr32 and then adding the class ID in the "Name" value, while I am adding the dll file path directly, Is that make any difference?

    I tried to debug the RDC, and yes it entered the dll entry point which is:

    extern _declspec(dllexport) BOOL _cdecl VirtualChannelEntry(PCHANNEL_ENTRY_POINTS pEntryPoints)

    and it executes all this function correctly, the API "VirtualChannelInit" was also executed successfully and returned "CHANNEL_RC_OK", and the entry point returned TRUE as expected, now it should go to the "VirtualChannelInitEventProc" callback function to handl the Initialization Event, but instead it breaks giving me the following error:

    "Unhandled exception at 0x6c51584d in mstsc.exe: 0xC0000005: Access violation writing location 0x5ed88c89"

    Iam trying to get extra info about this error cause.

    Can you redirect me to a code that is definitly working on Win Server 2008 to compare with? or can I send you my code?

    Thank you very much

  • Thanks Eric Very Much, The Problem has been Solved. I really appreciate your help. It is now working on Win Vista and 2008.

    As you may have figured out from my previous post, the problem was in the Virtual Channel Entry Point definition:

    extern _declspec(dllexport) BOOL _cdecl VirtualChannelEntry(PCHANNEL_ENTRY_POINTS pEntryPoints)

    I was using _cdecl where it should be _stdcall I am now using:

    BOOL VCAPITYPE VirtualChannelEntry(PCHANNEL_ENTRY_POINTS pEntryPoints)

    Which is working fine, it was working on Win2003 and XP even that it is _cdecl, but in 2008 and Vista it should be _stdcall

    Thank you Eric again

  • Mohammed, I'm glad to hear everything is working well for you now.

    Good luck,

    -Eric

  • Hi Eric,

     I met a problem when I run it, WTSVirtualChannelOpenex() failed, I think I have the same problem with Ravi, can you tell me how to operate it correctly? how to establish TS connection in client side?

  • I can register the 32-bit client and server dlls (on both XP SP3 and 2008 x64) successfully, however the TS 'ignores' the presence of the .tsteleport file in the user's SendTo directory, only presenting all other items in the directory through the context menu.

    The TS is Windows 2008 x64, will registering the 32-bit dll be a problem here or can it run successfully under WoW?

  • We have a problem using RDP 6.1 Client with  static virtual channels.

    I our case everthing is working fine with the RDP 5.X client, but with RDP 6.1 (shipped with XP SP3) client, the static virtual channel doesn't work anymore.

    As you saíd before, the RDP 6.1 Client should still support static virtual channels. Are there any known problems?

  • Will the client dll(TsTelePlgn.dll) work in Windows Server machine?

    I put a messagebox in function

    HRESULT CTsClientPlgn::Initialize(

       IWTSVirtualChannelManager *pChannelMgr

       )

    This message box is coming in Windows 7 machine.

    Same dll is used in windows server machine and registered as addin.

    But message box is not coming in Windows server 2008 R2 machine.

    Please tell me what should be the reason.

  • This stuff does not "just" work in Visual Studio 2010, Windows Server 2008 R2 while Windows 7 installed, I have updated this source code to work in new versions..

    Here is the link

    developerstyle.posterous.com/virtual-channels-more-awesome-than-you-think

  • Is there a way to specify the TS specific registry key across all users for the client. Say we have multiple different users only one is an admin so only one can regsvr32 the TsTelePlgn.dll. Does Terminal Services only check the HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default\AddIns\TsTelePlgn or can we put the key into HKLM? How would we go about making sure that all users for the machine can use the dll assume the users themselves can't change the registry?

Page 2 of 2 (30 items) 12