Determine timestamp for last login onto terminal server (2003)

There are several options for accessing the console remotely without relying on RDP into a working Windows install:

1. Lights Out Management - some servers from Sun, HP, IBM and several others have a Lights Out Management Chip (LOM). I have much of my experience with HP's iLO technology which has saved me several trips. Essentially this chip gives you authenticated remote access to the controls on the front of the server, and most instances much much more. The down side is if you server dosn't have it you can't use it.

2. IP KVM's or Remote Power Management - several vendors provide products that allow you to access either the keyboard, video and mouse remotely (IP KVM) or less expensivly the ability to manage power remotely by cycling the mains power to the server off and on again via a PDU. The latter option is not recommended unless you are sure simply power cycling the server will help.

The final option would be to not install updates over night, and schedule short outages during the day when you or your "hands and eyes" can be at the data center to sort out any problems. This is at the whim of your customer really, although a quaterly downtime is often a good thing to build in to your agreements.

There is a bit of a little-documented annoyance with PAE in windows. Despite the fact that the OS is now capable of allocating all the RAM in the system, some applications still won't use it.

With PAE enabled, each process is still limited to the limits of a 32-bit environment (4gb)... unless it is specifically built to make use of AWE (Address Windowing Extensions).

Despite all this "info" ... I don't think this is the problem you're running into. (do you have processes exceeding 4gb of RAM?) 9GB of paging to me is quite a lot excessive. Doubly-so when you take into account that this is a terminal server. That much disk-IO is bad for performance. As mfinni said, it is more likely that you're running into issues with your disk IO than memory issues. I've seen the exact same symptoms you describe, only to find out that indeed my disk-drives couldn't keep up with the work-load. There are a laundry list of reasons for excessive Disk IO and just as many solutions to the problem.

In my case, I discovered that the print-spooler service was allocating HUGE amounts of RAM (which was mostly dumped to the paging file). It turns out there is a long-standing problem in the print-spooler whenever printers are created/deleted.

(when printers created, memory is allocated for the driver. When they're deleted, the memory is not de-allocated. The result on a terminal-server with users logging in & out all-day-long is a print-spooler service with 2gb+ of allocated RAM... and most of it thrown to the page-file) Where possible, do not use RDP to share the printers.

There are many other hidden gotchyas when it comes to terminal-services and memory.