Specifying the TS Client Start Location on the Virtual Desktop

Specifying the TS Client Start Location on the Virtual Desktop

  • Comments 10

The location on the virtual desktop where the TS Client initially positions itself can be controlled via the winposstr setting in the RDP file (Default.rdp or any other custom RDP file that you use).

An example winposstr is:

winposstr:s:0,1,1370,92,2500,992

So, let’s break it down and see what each field means:

winposstr:s:0,ShowCmd,Left,Top,Right,Bottom

The first field is always set to zero. Next, the ShowCmd field can be set to one of the following two values:

Value Meaning
1 Displays the TS Client as using the virtual desktop-relative coordinates specified in the Left, Top, Right and Bottom fields.
3

Displays the TS Client as a maximized window.

The Left, Top, Right and Bottom fields are the coordinates which specify where the TS Client window must be positioned on the local desktop when it is not maximized.

Closely related to winposstr is the screen mode id RDP file setting. This field can be set to one of the following two values:

Value Meaning
1 Start the TS Client in “windowed” mode.
2 Start the TS Client in “full-screen” mode.

 

An example screen mode id is:

screen mode id:i:1

If the screen mode id is set to use the full screen, the winposstr value helps to determine which monitor the client will start on by choosing the monitor with the largest area of intersection with the rectangle specified by the Left, Top, Right and Bottom fields.

Leave a Comment
  • Please add 5 and 5 and type the answer here:
  • Post
  • NOTE: .net 3.0 conflicts with terminal services.

    To repeat:

    Install a fresh copy of XP Pro, update to SP3 and install .net 3.0 on the XP Pro (server) machine.  Try to RDP from another machine (client) into the XP Pro machine - the client dies without error message or notice in the event viewer.

    The connection is there, you can see packets going back and forth to 3389, but the connection is not maintained.

    Remove .net 3.0 and the XP Pro machine (server) will allow connections and the server and client can establish and maintain connections.

    On the client side you can use a fresh install of XP Pro SP3 to duplicate the problem.

    Good luck.

  • We are not seeing this issue with .NET 3.0 on XP-SP3 (remote computer). Can you please report your case to Microsoft product support? Thanks

  • Yes, I have tried it.. after installing sp3 on xp.. that machine cannot rdp to any machine.. other machine can rdp to that xp sp3 box though.

    If you uninstall SP3.. it works again

  • It's been reported again to MSFT Product Support, although it has been reported by others previously, see

    http://help.wugnet.com/windows/Remote-Desktop-working-anymore-ftopict623133.html.

    and other references on the Internet.

    If you want me to provide you with the ethereal capture just let me know, or you can try to RDP into the machine while debugging into your client code - that would enable you to immediately track it down.

    Pretty standard setup on this machine.

    Have a nice day.

  • Reinstalled a clean copy of XP Pro and it does the same thing.  Cannot connect to the XP Pro machine from the TS client when .net 3.0 is installed.

    Works when connecting to some XP Pro machines but not others.  No particular rhyme or reason to it.  Could be easily debugged from within the TS client code, if you have an interest in fixing this problem.

    Also does this on a clean install of XP MCE 2005 with all updates applied.

    Take .net 3.0 off on the server and you can RDP in.

    Since there's been no response I will assume that your department has no interest in fixing this problem.

    If this changes please let us know.  I can be reached through this forum.

    In the meantime our firm will switch to an alternative on the affected machines.

    Have a nice day.

  • Philbert,

    (1) Have you checked that Remote Desktop is enabled on the target machine? Please run "qwinsta" and send us the output.

    (2) Is port 3389 open on the firewall on the target machine? See if you can telnet to port 3389 as a simple test.

  • Thanks for this information.

    How about a discussion (I think it merits a separate thread) about how the TS client decides which monitor to use when set to 'full screen' mode?  When running multiple monitors, it seems that TS client has a mind of its own.  

  • Quest vWorkspace has an enhanced RDP client that has this capability.

  • The problem is the nVidia display adapter, specifically how it interacts with RDP.

    The solution is this:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]

    Edit/create the DWORD Value: "SessionImageSize"

    set it to 20 (which equals 32MB).

    This is apparently something plaguing a very significant number of RDP users, as nVidia cards are very common.

    Rather than crashing the RDP client completely, it might be wise to provide an error message to direct the user to the problem, or in the alternative provide some kind of an event in the server event log.

  • Still has the problem.  The nVidia problem existed on some machines, but apparently not on this set.

    Port 3389 is open.

    It always connects, always logs in and shows the desktop before it disconnects.  Sometimes it stays connected, most times not.

    This is not across routers.  It occurs within one router (i.e. not a packet size issue).

    Here is the output of qwinsta:

    SESSIONNAME       USERNAME                 ID  STATE   TYPE        DEVICE

    console           Administrator             0  Active  wdcon

    rdp-tcp                                 65536  Listen  rdpwd

Page 1 of 1 (10 items)