Ensemble on Windows : user used to execute Production items processes

Hello,

 

I have a problem with an Ensemble instance on Windows to access to a network shared directory. Ensemble service (services.msc) is executed with a user which has access to this network shared directory :

 - When I try to copy or access files from a terminal ==> this is OK : the command w ##class(%SYS.ProcessQuery).%OpenId($Job).OSUserName returns the user defined in Ensemble service logon screen.

 - When I try to copy or access files from a service, process or operation item of the running Production ==> this is KO and the command ##class(%SYS.ProcessQuery).%OpenId($Job).OSUserName returns a OS user called _Ensemble.

 

What is this _Ensemble user (it doesn't exist on the server) ?

Do I have to create a new user named _Ensemble ?

Why processes started by the Production doesn't use the user which starts the instance (defined in services.msc) ?

Is there a way to define which user is used to execute processes from a Production ?

 

Please note that on Unix, you don't have _Ensemble user on Production processes : the OS user is always the user which executes the Ensemble instance.

 

Thx !

  • 0
  • 0
  • 425
  • 4
  • 2

Answers

From the class documentation on OSUserName:

Operating system username of process.
Username given to the process by the operating system when the process
is created. When displayed, it is truncated to 16 characters. Note that the real O/S
username is only returned when connecting to UNIX or VMS systems; For Windows, it
will return the O/S username for a console process, but for telnet it will return
the $USERNAME of the process. For client connections, it contains the O/S username
of the client. This field is truncated at 16 characters.

_Ensemble is a Caché user under which all Ensemble jobs are run.

If you need to understand the context under which the service runs execute in a BS:

do $zf(-1,"set > vars.txt")

to output all environment variables to a file.

Thx, now I understand why the  OSUserName() function returns " _Ensemble". Sorry, I didn't read this documentation before posting.

When Ensemble runs on Windows its background processes typically run with whatever Windows credentials the Ensemble service (see Windows Service Control Manager) is set to "Log on as". If that is LocalSystem then your background processes won't be able to access UNC paths.

For more information, see my post here

If my answer here resolves your question please click the checkmark alongside it above.

Thx for your answer and your post !

Actually, I think this is an OS issue, maybe explained here : http://serverfault.com/questions/451387/how-to-delete-cached-temporarily...

Since the problem occurs on a PRD quite big Production, I have to be careful.

But I found a workaround : instead of using the host name, I just replace with the IP address and it works fine.

\\srv-appname\mypath\

is just replaced by

\\192.168.0.16\mypath\

Comments

One clarification that might help you: the "Ensemble Controller" Service is not an Ensemble process, so the user assigned to that Service doesn't affect what you're asking about. The "Caché/Ensemble Controller" Service is simply something that allows you to start/stop the local Caché or Ensemble. It's just like start/stop on the Launcher (the cube or the E).

Regarding the user for Caché/Ensemble processes, the user for those is not always the user that starts/stops Caché/Ensemble. My instance of Ensemble runs on the Mac. For several years, I do a custom install so that I can change the answer to the 4th question below from cacheusr to joelsolon.

User who owns instance: joelsolon
Group allowed to start and stop instance: staff
Effective group for Ensemble processes: cacheusr
Effective user for Ensemble SuperServer: joelsolon

All the Ensemble processes run as OS user joelsolon because of this.

I don't actually have an answer to your question, but maybe these points will help.