Remote ArcSDE start with multiple databases

[StephanieSnider]

ArcSDE 10.0

We have a development, test and production ArcSDE environment.  While we can log into the development server, our IT group doesn't not allow us to have login access to the test and production environments.  For many ArcSDE functions, we can use ArcCatalog, but to stop and start SDE services, we generally use the SDE command line to remotely interact with the environments that we can't log into directly.  Here's the problem...we have multiple databases in each ArcSDE instance.  While we can use the command line to shut down any SDE service remotely, we cannot remotely start up the services.   For example:


[INDENT]sdemon -o shutdown -s servername -i 5153 -u SDE -p password

ArcSDE Instance 5153 on servername is Shutdown!

sdemon -o start -s servername -i 5153 -u SDE -p password

Error: Service 5153 doesn't exist on servername.
Operation Failed, Unable to start iomgr.[/INDENT]


I have confirmed that the services.sde file has the remote protocol listed and it is uncommented. 
databasename_sde 5153/tcp

I have also added an SDEINSTANCE environmental variable with the path to the services.sde file.  Why would ArcSDE recognize the service to shutdown but not to startup???

[VinceAngelo]

Shutdown works because the remote port is open and able to accept a shutdown
request.  You have to do a lot more than just uncomment the remote start protocol
port to make remote start function [note that remote start is UDP (stateless), not
TCP (stateful)].  The actual procedure is very different depending on whether
the server is Unix or Windows.

Inability to access the server I was using would force me to abandon application
services on that server -- this situation just screams for exclusive Direct Connect.

Be careful not to put any environment variables which are not explicitly called for
in initialization files.

- V

[StephanieSnider]

We are planning to move up to 10.2 by the end of the year...although we may still use application services since we do versioned editing and replication.  This is just something that has annoyed us for quite some time, so I wanted to see if there was a work-around.  If we can avoid having to ask our IT dept to do administrative tasks for us, all the better.

[VinceAngelo]

I don't see any correlation between application service execution and versioned editing
or replication.  If fact, it's quite difficult to access application servers in 10.2 (and is likely
to be impossible post-10.2), so moving to Direct Connect now would be Best Practice.

- V

[WilliamCraft]

Just a quick question... is the "databasename_sde 5153/tcp" entry in your services file then very last entry?  If yes, is there a blank line just after it?  I have found in the past that ArcSDE service entries have trouble with connections as well as starting/stopping the service if there is not a blank entry as the very last line in the services file.  This may not be applicable to your situation, but I thought I would share my thoughts. 

Another option is that your IT Admin could give assign your domain acount to "Deny log on through Terminal Services" under Local Security Policy settings on the server and add your account to the Users local group which might allow you to manage the services remotely but not log into the server itself via RDP.  If he/she did that, you may be able to do the following remotely via command line: SC \\ServerName start databasename_sde 5153/tcp