dmzportwindowswindows-service
Our team runs the following commands to turn on and off Windows Services (e.g. JBoss Native) from the Windows command line as well as through source code in a program. It connects to a remote box. We are now placing this box (\DEV-A1) into our DMZ. How can we still run this command remotely but use a secure port?
sc \\DEV-A1 stop JBAS50SVC
sc \\DEV-A1 start JBAS50SVC
I think the problem isn't actually related to the password at all: probably you neglected to give the account the SeServiceLogonRight bit (Typically "Log on as a service" in GUIs). I found the name in this Windows XP Resource Kit help page on TechNet See knowledge base article kb259733 (Windows 2000) or kb327545 (Windows Server 2003) for how to do this from the GUI, but I'm assuming you really want to do this from the command line, for which you should look at ntrights.
This is based on my actually attempting to create the same simple service first with my own user account and with an existing service account that I had created earlier. With my own account, I got what I presume to be the same error as you've been getting from "sc start":
The service did not start due to a logon failure.
With the service account, I got this error instead:
The service did not respond to the start or control request in a timely fashion.
I assume this latter error is because the program I tried to start was not prepared to act as an NT service. (If it helps, the sc command that worked did not use quotes around the password.)
FYI, both commands were of the form:
sc create xemacs-beta-repo binPath= "C:\Program Files\TortoiseHg\hg.exe serve -d -R C:\code\xemacs-beta -E C:\code\xemacs-beta.hg-serve.log" obj= Sam10\foo password= bar
where Sam10 is the name of my (Windows XP Pro SP3) system.
I really can't say why re-entering the password in the GUI would fix anything, other than to suggest that it might add SeServiceLogonRight to the account in question -- have you been using fresh accounts each time you tried this, or have you also tried with accounts that you have manually made to work?
Best Answer
sc.exeuses RPC to connect to remote hosts; RPC calls always start with a control connection to TCP port 135, but then another connection is opened using a random dynamic port to carry out the actual RPC call; the range of these dynamic ports can be limited, but how many of them are needed depends heavily on what the computer is doing.Also, keep in mind that if the server is a domain member (which it probably is, since you are controlling it remotely with a command that uses integrated authentication), you will anyway need to open lots of ports in your firewall(s) in order for it to operate properly.