Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We are interested in implementing RemoteApp on Windows 2008 R2 to serve out a few programs.

Since the developers use shared memory to pass messages between processes, it is necessary that we provide them with a solution that will allow this. They have researched and discovered that if the applications exist in the same terminal server session that they will be able to access shared memory.

Is there a way to absolutely ensure that multiple RemoteApps are running within the same session (with the same user) so that they can access the same shared memory?

share|improve this question
up vote 4 down vote accepted

If you use RDS Session Broker then the default behavior is to direct incoming connections (for the second and subsequent Remote Apps launched by the user) to the same RDS server where a session already exists (for the initial RemoteApp launched by the user).

share|improve this answer
Thanks Joe. I'll look into this deeper. This will cross client machines as well? – mbrownnyc Nov 21 '11 at 16:04
I'm not sure what you mean "cross client machines". Session Broker will connect subsequent RemoteApp connections for the same user to the RDS server where the first RemoteApp launched from for that user. At the end of the day, RemoteApp is nothing more than an RDS session where only the application window is displayed, rather than the full desktop. When launching a RemoteApp, if you click the details button you'll see the actual logon process and see the desktop session being created. Once the session is created the RemoteApp application window is displayed to the user. – joeqwerty Nov 21 '11 at 16:12
By "cross client machine," I mean the same user on multiple machines. I believe this must be true by what you've stated, but need to look into it further to be sure. Thanks for your time. – mbrownnyc Nov 21 '11 at 16:15

Nope. Broken design. THat simple. YOu should never have used shared memory.

share|improve this answer
This isn't an answer. It's an opinion. If you can provide some citation, that'd be excellent. Alternate solutions would be excellent as well. – mbrownnyc Nov 21 '11 at 15:47
@mbrownnyc Each user gets their own session, and there's no way to glue them together for shared memory access. Alternatives are pretty much "anything but that" - use APIs for inter-process communication, or a proper event messaging system, or even just a shared database. But that's not a discussion for Server Fault, it's an application design discussion - TomTom's answer is that what you're trying to do is impossible; that's most certainly not opinion. – Shane Madden Nov 21 '11 at 15:59
SIme. Shared memroy = security risk. Cross session sahred memory == security risk squared. Anyone not junior got that idea on my end - he can happily sue me for unlawfull dismissal when I force remove him from his desk right the moment I find ot. At least use named pipes to send data. That uses internally shared memory but is protected by ACL and a driver model. – TomTom Nov 21 '11 at 15:59
Shane: Thanks for replying with some alternate solutions. joeqwerty was able to explain an alternate, and I've changed the question to include that I am discussing sharing data to the same user. TomTom: I am not talking about cross session. Thanks for providing more details on some flaws in shared memory and alternates. – mbrownnyc Nov 21 '11 at 16:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.