What's wrong with services.msc on a Windows Server machine? Any serious answers from people who actually used it?
One of the biggest issues, is that in case I want to run a service as a certain local user --- login credentials have to be entered and saved in an insecure fashion (Yes... there are tools that can extract the password used to run a service from the "secure credentials store); in UNIX you don't have this problem --- you can run a service as any user, just SU in the startup script -- no password needed.
If a kerberos credential is needed in unix? No problem.... kinit a service credential and configure the service with the proper ticket cache directory. Again, no user passwords need to be leaked into an insecure format!
Next, For starters... I can't control+click and choose Stop, Start, or Restart, Enable, or Disable, on multiple services at the same time.
If I send a Start or Stop command using services.msc; I can't use it to send any other Start or Stop commands until my first command is done, including all dependent services ---- I guess the service control manager is "locked" until the operation is done.
Nothing like the concept of init runlevels or commands in a shell script.
Next..... it's really quite a mess to attempt to go add or remove a service from services.msc. I have to pull out a registry editor and go through a bunch of complicated steps.
In CentOS5 it was simply a matter of create a script in
Next we have the issue of checking the status of a service and getting a simple status code that can be readily used in a script to take arbitrary actions.
The relatively limited nature of choices in services.msc of what to do if a service fails.