Create service (note the space after binPath=):
sc create "[service name]" binPath= "[path to executable]"

Delete service:
sc delete "[service name]"

<rant>
And as long as we're on the subject, I really wish our "enterprise" software vendors would stop setting things up to run as Windows console apps when all they do is display a logfile in a window. If the app has the ability to run as a service, run it as a service. I can tail a logfile to debug issues, even if your support people don't know how to do that.

Running apps on the console tends to cause problems if people login via RDP. I can either:

1. Explain to people that they have to login via RDP using a particular account with an obscure password in order to restart an app, making sure to include a "/console" after mstsc on the commandline.
2. Tell them to login using their own account, double-click the Services icon on the desktop, right-click the app on the list and click Start.

Hmm. I think I prefer option 2.
</rant>

Solution:

1. Create a file named "agentid.txt" under the Navisphere Agent directory.
2. The first line of the file should contain the server's fully-qualified hostname.
3. The second line should contain the IP address that Navisphere should use to contact the server. This determines which adapter will be used.
4. Stop/start Navisphere Agent service. Do not restart the service, as that doesn't seem to work.

In Navisphere, right-click on the host and click "Update Now". It should show up as managed.

I did a little googling and found a solution on the somewhat-horrendous-but-ubiquitous Experts Exchange site. With a little tweaking, it works great.

1. Create a file: /bin/ftponly
   
   #!/bin/bash
echo "This account is only allowed FTP access."
   
   
   
2. Add /bin/ftponly to /etc/shells file
3. Change shell for user account either by using chsh or editing /etc/passwd directly

Once this is done, ProFTPd considers ftponly a valid shell and allows FTP access. As a side bonus, attempting to login via ssh or other means displays a useful message rather than just dropping the connection.

Now, on to finding a solution for the continuous brute force login attempts that are filling up the ProFTPd logfiles...

First, change the user's password to a temporary:
passwd [username]

Next, reset the password expiration to 90 days (-M) and set the last change date to 0 (-d) to force a change:
chage -M 90 -d 0 [username]

Finally, verify the info:
chage -l [username]

Since svchost.exe can host many things, I did a little research and sent the following command to him to help us identify what's consuming so much memory:
tasklist /svc /fo list /fi "imagename eq svchost.exe" /fi "memusage gt 1000000"

That will show any svchost.exe processes that are consuming more than 1GB of memory. It will also list all the hosted DLLs so we can track down the culprit. Of course, all the same info is available in Process Explorer, but we don't have that installed on the box in question (although I am thinking of suggesting that we make that a standard part of our server loadout).

I may also encapsulate the tasklist command above into a Nagios check and run it against all our Windows boxen. That's what I like about having a flexible monitoring system like Nagios in place. As we find new things to check, we can just add them and the whole thing is automated from that point on.

The output file is slowly growing, so it's still working. I attached an strace to the process and see it mostly waiting in a read state, so I assume that we just need to optimize the indexes on the database to make it run faster. That's mostly outside my responsibility, but I did want to check to see how long the process had been running in order to make a preliminary report to my coworkers. Digging around in the /proc directory for the process didn't immediately show me what I wanted to know, so I turned to the "ps" command. I had to do some reading, but ended up with the following:
ps -o etime,stime,time,cmd -C sqlplus

This gave me what I was looking for: elapsed time, system time, wait time, and the command for all sqlplus processes.

Total elapsed time so far: 5 hours. Wow. That's quite a while for a single query.

As soon as I hung up the phone, I brought up my Centera Viewer client and tried to login to the cluster. No response. No ping response either. As I walked down the hall to the datacenter, I was reviewing network connectivity for the cluster in my mind. If a system isn't working correctly, blame it on the network, right?

Once in the datacenter, I opened the back of the rack and found the modem dead. No lights at all. After checking cables, it occurred to me that I wasn't feeling any breeze from the fans in all the nodes. A quick glance told me that there were no lights on the back of the cluster. I walked around to the front and found no lights there either.

As possible causes for a complete power failure to the rack began whizzing through my head, one tidbit floated to the surface: About two weeks before, we had been coordinating with the Maintenance department on moving our datacenter power feeds to a new powerhouse the hospital recently built. We have big APC UPSes that will power the datacenter for a few minutes until generators kick in. Since Maintenance wasn't sure how long it would take to reroute power through the new powerhouse and generators were out of the question, we had to prepare for the worst and assume the UPSes would drain and shut down before power was restored. One of the steps we took was powering down all non-critical systems. Since the new Centera was a replication target and replication was not in full swing yet, I decided to power it down for the move.

Of course, I'm sure you've already determined the problem. We forgot to power it back up! Since the Centera was new, I had not yet added it to our Nagios monitoring system and was not paying much attention to it. I powered the cluster up and sheepishly called EMC Support to report my little flub.

Take-aways (don'tcha love biz-speak terms like that?):

• Even experienced tech guys like me fall victim to noob shenanigans like forgetting to check power on a system before diving into troubleshooting.
• Add systems to your monitoring solution early, even if they're not in production yet. You can always disable alerting for that particular system until it's in production, and it's a good shakedown to make sure your thresholds are reasonable. It will also tell you if you maybe shut down the system and forget to turn it back on! (Like anybody would ever do something like that...)

On the first Sunday in November you need to shut down blah applications during the time change to avoid duplicate chart times.

This is for a mission-critical 24x7 application that is used daily by hundreds of people.

Why don't we just go ahead and close the hospital for an hour to avoid duplicating any information?

Wow.

User: Um, is that the number zero or the letter zero?

Me: (Dumbfounded silence) That would be the number zero.

User: Ok, thanks!