locked
How to realize only one identical remoteApp per session per user per computer? RRS feed

  • Question

  • If a terminalserver 2008 R1 is configured for only one session per user, everything works like it should if the user connects using the 'normal' remotedesktop session. A second connect with the same credentials kicks the first connect.

    If a remoteApp is used instead of the 'normal' connect, it's possible to start multiple instances of this app within one user a least from one computer. mstsc do run multiple times and seem to link in the existent connection without kicking it. How to change that?

    Continuative:

    The started RemoteApp checks the mutex of all started processes and stops herself if a process is found with the same mutex. This prevents multiple instances of this app within one user with the same sessionID. If a terminalserver is configured for only one session per user, this RemoteApp shouldn't start multiple within one user. Using a "normal" remote desktop session the app doesn't start more than one time, I tested it. Used as RemotApp, the app starts multiple! Possibly I'm able to change this behaviour with a code fix instead of configuring terminal services. Any tips regarding mutex and terminalservers?





    • Edited by G.Fischer Tuesday, May 24, 2011 11:33 AM
    Monday, May 23, 2011 11:11 AM

Answers

  • Hi,

    I tested the following code and it is working for me both in a RemoteApp and Full session:

    Imports System.Threading
    Module Main
      Sub Main()
        Dim createdNew As Boolean
        Dim m As New Mutex(True, "TPMutex", createdNew)
        If Not createdNew Then
          Return
        End If
        Application.Run(Form1)
        GC.KeepAlive(m)
      End Sub
    End Module
    

    -TP

    • Proposed as answer by PrismaComputer Thursday, May 26, 2011 12:58 PM
    • Marked as answer by G.Fischer Thursday, May 26, 2011 1:05 PM
    Tuesday, May 24, 2011 9:02 PM

All replies

  • Hello,

    sorry for pushing this threat, but I really need information. Is there it a possibility to configure terminal services, or is some code fix regarding the mutex (and what kind of code fix) needed? Sorry for my bad english, I'll try to explain the problem in a shorter way:

    If a terminalserver 2008 R1 is configured for only one session per user nevertheless it is possible to start more than one instance of our RemoteApp within one connecting computer. If a second computer starts the remote app with the same credentials, the first RemoteApp-Session is closed, like it should be...

    a) Is the first described behaviour a bug or a feature?

    b) Is it possible to reconfigure terminalservices to change that behaviour?

    c) Or do we have to change the code regarding the mutex questioning. But in which way? In a 'normal' terminalsession the application prevents a second instance correctly. Only if started as RemoteApp the application always thinks that she is running the first time and alone...

    Tuesday, May 24, 2011 8:43 AM
  • I'm one of the developers of the above quoted application. It would be nice to spark someone's interest in this thread. Are there any questions about the circumstances of this case? We really would appreciate a statement of a MSFT to be able to decide on further actions.

    Thank you.

    Tuesday, May 24, 2011 7:29 PM
  • Hi,

    I tested the following code and it is working for me both in a RemoteApp and Full session:

    Imports System.Threading
    Module Main
      Sub Main()
        Dim createdNew As Boolean
        Dim m As New Mutex(True, "TPMutex", createdNew)
        If Not createdNew Then
          Return
        End If
        Application.Run(Form1)
        GC.KeepAlive(m)
      End Sub
    End Module
    

    -TP

    • Proposed as answer by PrismaComputer Thursday, May 26, 2011 12:58 PM
    • Marked as answer by G.Fischer Thursday, May 26, 2011 1:05 PM
    Tuesday, May 24, 2011 9:02 PM
  • Dear TP,

    thank you very much for your effort, we really appreciate it.

    I'm not 100% sure what the program above should do because we are developing with delphi. But I compiled it with VS2008 and I'm able to start this program as often as I want. Just by double clicking it, independent of any remotedesktop context. What should work is, that you're not able to start this app more than one time, within console, remotedesktop or RemoteApp. (Means that it closes itself if it finds a program with the same mutex)

    Would you please be so kind to provide a changed VB-code-snippet, that is conform to these requirements? It is our only chance to see, if the system is doing any wrong or our application. If your snippet works correctly, we'd know we're wrong.

    Thank you very much

    Greg


    Wednesday, May 25, 2011 10:46 AM
  • Hi Greg,

    The code I posted meets your requirements of limiting a program to single instance.  It is just an example of one technique for accomplishing your goal, in .net.  Since you are using Delphi you will need to translate to the equivalent in that.  You should be able to do the same type of thing by calling CreateMutex windows function from your code.

    In order to make what I wrote work you need to set Sub Main as the startup object.

    Here is a link to the TPMutex exe if you want to test it on your system and verify that it works:

    https://onedrive.live.com/redir?resid=F1DA8B2F5D436258!277&authkey=!AE_cRFjkdyh9FPc&ithint=file%2c.exe

    -TP


    • Edited by TP []MVP Wednesday, April 23, 2014 7:43 PM Updated Link
    Thursday, May 26, 2011 10:31 AM
  • Hi TP,

    yep! Your EXE leaded us to the error. It showed us, that it is not an configuration issue of the terminalserver. Our createMutex fails under very specific circumstances.

    THANK YOU VERY VERY MUCH !!!!

    Thursday, May 26, 2011 1:02 PM
  • Hi TP,

    we are working on a quite similar issue, and the TPMutex.exe would be very helpful for testing purposes. Would it be possible for you to make it available again?

    Thank you,

    jp

    Wednesday, April 16, 2014 12:05 PM
  • Hi jp23,

    I updated the link.  You should be able to download the TPMutex.exe file now.

    If you have questions or need help with what you are trying to accomplish please start a new thread.

    Thanks.

    -TP

    Wednesday, April 23, 2014 7:45 PM