0

We're running a certain application on a client's server. The app runs on the console session, and basically manages some batch processing. Every once in a while we discover the app is not running, and obviously this only happens after the client complains about the app's job not getting done. The reasons for the app's shutdown vary from internal error to deliberate shutdown to server restart. If the latter, I can see the evidence in the event viewer. On the other cases, I'm looking for a way to discover who was logged on at the time the app was shut down.

What seems reasonable to me is running the app via a batch file, and once the app is closed the batch commands that will follow will list the currently logged on users, one of which probably responsible for the shutdown. The problem is everyone logs into the server using the network admin credentials(!), and different sessions can be told apart only by the user's machine name.

It is worth mentioning that:

  1. The app does a classic service job, but it can't be converted to one.
  2. I tried some Sysinternal tools, but none listed the info I needed.
  3. I'd rather not use the event viewer. It's swamped as it is. Log files are better.
Flimzy
  • 2,454
  • 18
  • 26
Eran
  • 267
  • 1
  • 6
  • 14

4 Answers4

1

Update:: So maybe

netstat -n -a | findstr 3389

is what you are looking for.

**Before update:**I think that what you are looking for is:

query session
query user

But, at most, those are band-aid. You should take a step back, and solve this on a deeper level. maybe a watchdog service or something like that.

Igal Serban
  • 1,575
  • 10
  • 6
  • As for the query commands, neither show the name or IP of the computer from which the user has connected. Given all users log on as "administrator", the source details is what I'm missing. As for your second comment, in principle you're right, hence my note about running as a service. But life is full of compromises - product versions, priorities, payments etc. A band-aid is just the only option on the table at the moment. – Eran Jun 28 '09 at 17:11
0

You can use the net session command on windows to find out who's logged on(both local and remote). I currently don't have a windows box, so sorry I cannot give you the entire command, but net session help should .....help you? :)

HK_
  • 407
  • 2
  • 5
  • Net session was one of the first things I had in mind too, but it yielded some weird-looking results... On a server with 3 logged in users, only one session was listed, and it was coming from an unreachable IP. On another server with only me logged in, another user was listed. How the command gets its info is beyond me... – Eran Jun 28 '09 at 14:52
  • Oops. Can you use psloggedon and parse the output? – HK_ Jun 28 '09 at 15:29
0

A lot of the network monitoring packages will let you monitor an individual process, and alert you when they stop/restart etc.

We use on called JFFNMS (http://www.jffnms.org/) to monitor QuarkXpress on a few machines that get jobs sent to them. Every so often a job will crash the app, when this happens JFFNMS sends an email out to tell us.

beakersoft
  • 997
  • 15
  • 29
0

Slightly lateral thinking possibly, but on several of our TS servers we have a login script that writes various info to a folder on the server. We do this for reasons completely unrelated to yours, but you could easily do this to keep a log of who is logging in. In a TS session the environment variable CLIENTNAME is set to the name of the workstation doing the connecting, so it could be as simple as:

date /t >>C:\somefolder\%CLIENTNAME%.log
time /t >>C:\somefolder\%CLIENTNAME%.log
echo %USERNAME% >>C:\somefolder\%CLIENTNAME%.log
echo ---------- >>C:\somefolder\%CLIENTNAME%.log

JR

John Rennie
  • 7,776
  • 1
  • 23
  • 35
  • The problem with %clientname% is that it seems to hold the name of the workstation from which the log on has been done, and not the one who's currently connected. In our case, we're using the console session. When I connect to the console and check the clientname, I see the name of some other workstation. It's probably the one who first logged on to the console session, but since we all use the same user, we all connect to the same session. As a result, clientname never changes. Awkward, but given. – Eran Jun 29 '09 at 09:05