I have purchased CommandBox Service Manager to replace NSSM on a new Microsoft® Windows® instance.
I have created a non-administrator user to run the CFML application. This user can start the application within CommandBox by running server start as expected.
I updated the server.json in the project root with a service key, defining startType, username, serviceName, displayName, and description.
I attempted to create a Microsoft® Windows® Service™ by running server service create password=****. Microsoft® Windows® displayed the credentials dialog to authenticate as the Administrator. I carefully typed the excruciatingly complex password with my fingers because Microsoft® does not allow pasting, for reasons.
The following is displayed in CommandBox:
Can't open service!
OpenService(): Access is denied.
ERROR (6.0.0+00787)
Command returned failing exit code [3]
The result is that a service is created partially. The displayName is incorrect and the Log On tab is blank. I assume that the administrator credentials were used once to create the service, but not again to make additional modifications.
If I perform the same server service create command when running CommandBox as the local administrator, the service is create properly, but of course the command is incorrect because the path to ServiceTranslator.exe has the wrong user’s .CommandBox directory.
Is there a trick to running CommandBox Service Manager without running the CFML application as the local administrator?
Hey Joseph:
TLDR; before running that command, be sure to open the command prompt “as administrator”
When anyone/anything creates a Windows service, they/it must be running “as administrator”…and yep, this is even if one “is an administrator”, meaning they are in the “Administrators” group. (Only if one IS literally logged in as THE administrator account can they skip this step.)
And FWIW, the Commandbox docs for this box service create do indeed try to convey this, saying:
“Note: you must be using an Administrator user (Windows) or root (*nix) to create services.”
Let us know if that gets you going. BTW, I’m offering this merely as an observer, rather than as one with experience about the specifics of running that command. Perhaps Brad or someone else may have something different or more to say.
Yes, Windows reqiuires an administarator process actually create the service. Also, it sounds like you may have more than one CommandBox home floating around. By default, every user that uses CommandBox gets a different home dir based on their user directory. When setting up a service, this is often undesirable. I recommand “pinning” the CommandBox home dir to a shared folder that all users have permissions to (program files tends to work well). The box.exe can live anywhere really, but place a commandbox.properties file in the same directory as the box.exe with something like
commandbox_home=E:\\CommandBox
as described here:
This will ensure that the same CommandBox home, settings, and modules are used for all users. And then, when creating the actual service, the terminal needs to be started as administrator to make Windows happy.
Also, in case you hadn’t seen, all the configuration for your service can also be set in the `server.json. to make it easy to update the service in the future.
Thank you Charlie. Yes, the service does get created as expected when running within the administrator’s permission context. However, that leads to the problem I pointed out about the executable being located in the administrator’s home directory, rather than the non-administrator user’s home directory. I’m going to follow Brad’s suggestion about pinning the CommandBox resource directory and I’m sure that’ll resolve this.
Thank you Brad. I was not aware of the recommendation to pin the CommandBox resource directory to a shared path. That makes perfect sense.
I pinned the CommandBox home directory and ran server service create as the Administrator user. It all works properly.
1 Like
Yep, Joseph. My reply was addressing only half the problem. Brad’s extra info was indeed critical.
Perhaps over time things may be addressed more readily (in the docs or in the app). Brad and company don’t tend to leave loose ends untied. 
I’d argue that the information in the documentation is sufficient. I just wasn’t aware of the conventions for CommandBox installation on Microsoft® Windows®, so that’s a me problem.
I added some commentary that might be helpful to the next person: Adds note about CommandBox home directory recommendation by jlamoree · Pull Request #1 · ortus-docs/commandbox-service-manager · GitHub