This is probably a bit obscure but writing it up will surely help someone — if not myself next time around…
I use WhatsUp Gold to monitor the machines at work. Been using it for years and it has worked great for us. Recently I hit a little challenge though. Needed to monitor the event log on some servers and if a particular Windows Service threw a specific error message I’d need to get the service restarted.
My first approach was overly convoluted (if you’re really curious you can read more in this support forum post). After some false starts with start and stop events I found Sysinternals’ PsService and realized I could use it with WhatsUp’s ability to run “Program Actions” to just completely restart the service in one step.
I ran the psservice.exe command from the WhatsUp server against a development server, then checked the dev server’s event viewer and confirmed the service was restarted. Next I created the Program Action in WhatsUp and used the Test feature to make sure it all worked. So far so good; more events in the dev server’s event viewer logs.
I went to bed, comfortable in my knowledge that everything was looking good.
This morning I checked WhatsUp’s Activity Log and saw that it had fired the service restart last night. Yay! But looking closer at the server in question, I didn’t see any evidence in the logs of the service actually being restarted. Boo! WhatsUp just thought it was running psservice. (this is post 2 in that support forum thread I linked earlier).
I needed a way to test this more. Clearly I couldn’t just sit around hoping for errors to show up in the event logs to fire up my little process. A quick web search turned up the fact that eventcreate.exe was already on my Windows 2003 server. This little gem lets you easily create event log entries — even on different servers across the network. Brilliant! I’ve been working with Windows for a couple decades now and I’d never even heard of it before.
Now I had a way to create error entries in the logs that would fire off my psservice service restarts. Sadly, all this gained me was a way to not restart the service more frequently. WhatsUp assured me it was firing the program and the dev server continued to not get the service restarted.
Then it hit me. The first time you run any Sysinternals app you get the license agreement and you have to agree to it to actually run the app.
The WhatsUp service is running as the Local System account and I finally realized that it needed to accept the agreement.
Another quick search turned up a blog post with an easy way to fire up a command prompt running as the Local System user using PsExec. Amusingly enough, this app was bundled with PsService.
psexec -i -s cmd.exe
From that prompt I was able to run PsService.exe and did indeed have to Agree to the terms.
Updated a day later: Note that the argument “-accepteula” would have saved me a lot of time here. I didn’t know about it at the time I wrote this post.
But wait, it still didn’t work!
I had one last step to go. The WhatsUp monitoring service (technically, the “Ipswitch Service Control Manager” service) needed to be altered. Specifically, it needed to have “Allow service to interact with desktop” enabled. (and this would be the third post in that earlier support forum post I linked)
That was the final fix. Now it all works as desired — and expected.