Issue 88600 - MS Terminal Services with shared windows usernames
Summary: MS Terminal Services with shared windows usernames
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: OOo 2.4.0
Hardware: All Windows Server 2003
: P3 Trivial with 4 votes (vote)
Target Milestone: AOO Later
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2008-04-22 16:16 UTC by kanderson8281
Modified: 2013-01-29 21:41 UTC (History)
5 users (show)

See Also:
Issue Type: FEATURE
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description kanderson8281 2008-04-22 16:16:51 UTC
We recently installed Open Office 2.4 on two of our site servers. The install 
went well, but we have run into an issue with opening files. 

We have multiple users that use a generic windows account on the terminal 
server (ie sales). If I log in as sales and there are a few other people logged 
in as sales when I open documents they will sometimes open in other peoples 
sessions, and not mine. 

I know that I installed the App as a terminal Services app using the Add/Remove 
programs. I have never had this issue with other applications. 

I have been told that if I disable the quickstarter that will resolve the 
issue.  I have disabled the quick starter and this does appear to have fixed it.

I hope I have given enough information for this bug.
Comment 1 Olaf Felka 2008-04-23 07:19:09 UTC
AFAIK OOo is not designed to work like this. OOo writes a lock file at office
start. This lock file tracks who is using the office. If multiple users with
under one account want to use the office the user who has opened the session is
the 'owner' of the running office.
@ oc: Is this something that we can do with OOo 3.x?
Comment 2 joerg.skottke 2008-04-24 07:43:28 UTC
As OF already wrote we do not support your scenario. The reason is that there
can only be one instance of the office application working on the configuration
layer at a time. So if you run multiple instances your application appears on a
random display, usually the the display that belongs to the first instance.

This has rarely ever been a problem so far (though reported 3 or four times in
the past). Mostly the issue was resolved by creating real users for everyone.
Please see if this is an option for you. Multiple people using the same account
simultaneously is very likely to cause other weird sideeffects.

Setting this issue to WontFix
Comment 3 joerg.skottke 2008-04-24 07:45:34 UTC
I'm closing the issue for now. If you're not happy with my explanation you might
reopen it at any time.
Comment 4 mroper 2009-06-09 09:14:23 UTC
Comment 5 mroper 2009-06-09 09:26:01 UTC

We are looking at deploying OO within our organisation.  I've been doing a fair
amount of searching on the forums and it looks like this is still an issue, and
from testing I've done it also occurs on OO 3.0.  I can understand what your
saying in your below description, however I'm hoping I can convince you to have
another look.

Shared user accounts are more common in a windows environment.  In our situation
we are a hospital, and it is unreasonable to expect 8 nurses, and several
doctors to log in/out of a several PCs on a ward.  Instead, they use a generic
login in, which is the ward name, and then login to the patient care application
they use as a unique user.  This also occurs in emergency and the theatres.  Its
also where OO would be perfect to be deployed, as these are users who are not
power users, all they need is basic office apps, so retraining is not a major issue.

I would suggest, that to get OO into more enterprise organisations fixing this
issue would be a great asset.

Is there any way we could use a session ID parameter in combination with the
lock file, as I would assume TS (or citrix) would have such an ID which could be
pulled from the environment.

We could also assit with testing, as we have several test citrix servers.

Thanks for your time.


Miles Roper
West Coast DHB
New Zealand.
Comment 6 kanderson8281 2009-06-09 17:00:32 UTC
As a workaround I found that disabling the quickstart feature appears to have 
resolved this.  I am not certain that it actually fixes the problem, or the 
users are not using the program to the same extent they once were.  But I 
stopped receiving complaints about the strange behaviour when I disabled the 
quick start.
Comment 7 mroper 2009-06-10 05:58:52 UTC
I tried this as well (as I read something similar), I disabled the option in 
the options menu, confirmed no "quickstart.exe" was running in taskmanager and 
tried using the same user logged into two seperate sessions, same deal, OO 
Writer would open on random sessions, sometimes the right one, sometimes not.

I haven't restarted the server however, but as quickstart.exe isn't running i'm 
assuming this isn't required.  any other thoughts?
Comment 8 mroper 2009-06-12 09:36:24 UTC

just something I wanted to add.  I'm an Open Source advocate from way back, I
use to be the lead developer in an OS project called Thinstation, however work
keeps me busy enough as it is now.  What really interests me is our organisation
giving MS the boot, and if our organisation can do it, others in the health
sector within NZ would see a path which wasn't so MS centric.  For you this
issue may seem minor, but its quite a major issue to solve to gain a foot hold
in NZ health.  Really hoping you guys can have a look at this.

As mentioned, happy to help where i can (ie testing, feedback etc...)


Manager, Information Technology
West Coast DHB
Comment 9 Olaf Felka 2009-06-12 09:56:52 UTC
@ cd: Is it possible to give usable solution for such cases?
Comment 10 carsten.driesner 2009-06-18 09:45:14 UTC
cd: I must confess that I don't know the Citrix/TS environment well. If there is
a way to retrieve something like a "session ID" there would be a unlovely
workaround possible. We could extend the placeholder mechanism to add the
"session ID" to the user folder path. That would guarantee that every session
has it's own user folder. The big drawback would be that over the time many user
folders would be created. They would eat a lot of disk space. That also means
that changes made by a user could be lost when he/she gets a new "session ID" on
the next Citrix/TS login. So this would be a "bad" solution but I don't know how
to fix this without demanding unique logins by every user.
Comment 11 mroper 2009-06-18 11:00:04 UTC
Hi Cd,

Yeah, I think there is, from the Citrix server I'm on at the moment, from 
session 1 as mroper:


From session 2 as mroper:


Terminal services deals with it slightly differently


so it would seem feasible.

To prevent issues with eating disk space, would it be possible to keep the way 
you do it at the moment (one user folder) but if you detect the presence of the 
above environment variables, copy this profile to the session ID user, then 
when the person closes the application, it moves it back to the master copy.  
The idea being, who ever last closes the application gets to keep their 

Another possibility, would be similar how to Citrix/TS generally works.  The 
last person to logout using the same username keeps there settings, as the last 
profile overwrites the others.  You could do something simialar by if you 
detect the presence of the environment variable, and a flag is set in the users 
home folder, then copy the profile to the citrix temporary profile storage 
area.  This is cleared upon logout.  If the flag is not set in the persons home 
folder, but the environment variable is set, then this means its the first 
person to login so just go as normal.  When you logout delete the flag.

Makes sense?

Any of it feasible?


Comment 12 carsten.driesner 2009-06-18 12:01:46 UTC
cd: I think your first propose solution would be easier to implement. Even using
this part would need many changes in the current startup/shutdown code. Locking
must be taken into consideration as it would be possible that one Office copies
the current user data while another user closes the Office and it wants to write
back data. I would guess that at least two weeks of work would be needed to
accomplish this. I and the framework team are very busy with other important
tasls. Therefore we would need to find a volunteer to implement this feature
request. May be you know a student or some other developer. He/she would get
support from the framework team.

cd: I reopen this issue as it makes sense to support this kind of work
environment. No guarantee that this request will be implemented in the near future.
Comment 13 carsten.driesner 2009-06-18 12:02:35 UTC
cd: I take over and accept this issue.
Comment 14 carsten.driesner 2009-06-18 12:03:10 UTC
cd: Set to accepted.
Comment 15 mroper 2009-06-18 20:56:21 UTC
Hi Cd,

Thats great.

I don't know any students but may have an idea, will let you know if something


Comment 16 kanderson8281 2009-11-20 15:36:10 UTC
Is anything going on with this?
Comment 17 carsten.driesner 2009-11-20 15:57:47 UTC
cd->kanderson8281: No. I as wrote some months ago: "We need a volunteer who
wants to work on this issue." Currently we have nobody who can do the work. May
be you know a student or someone who wants to work on this enhancement. I am
definitely not able to work on this enhancement.