Most RDS problems are visible hours before the first user calls. The trouble is that checking each server takes longer than anyone has in the morning, so the check gets skipped until something breaks.
This is a short routine that takes about five minutes if you can see all servers in one place. It covers what to look at, what counts as a problem, and what to do about it.
1. Are all servers online?
The first question is whether every host in your fleet answers. A server that dropped out overnight is the most expensive kind of problem, because its users are already somewhere else, or nowhere.
Look at the count of servers online and at any server with an error state. If one is offline, the rest of the check on that host is pointless until you know why.
2. Is anything running out of room?
The failures that need a human tend to be slow ones: a disk filling up, memory creeping toward the limit, a pagefile growing every day.
Check the least free disk across the fleet and the headroom of memory. A disk at 15 percent free deserves attention this week, and one at 7 percent deserves it today. Read the disk queue and disk busy as well: a queue that stays high on a busy disk, with Avg. Disk sec/Transfer above about 15 to 20 ms, means the disk is the bottleneck, whatever the CPU says.
3. Who is struggling?
Look for sessions with a poor connection or a high loss rate, and for the sessions with the worst readings in general. These are the users who will call before lunch. If you reach them first, with a message or a quick look at their session, the call never happens.
4. What is stale?
Idle and disconnected sessions hold memory and other server resources. Locked sessions that nobody has touched since yesterday do the same. Count them. If the numbers keep growing day after day, set an idle and disconnect policy on the hosts, and clean up what is already there.
5. Did anyone try to get in?
Open the failed logons for the last day. Many failures from many addresses against names such as administrator and admin are a brute-force attempt against an exposed server. A handful of failures for one real user is a forgotten password. The difference is clear when you see the list.
6. Did anything change?
Glance at the session history for the last day or two. Unexpected logons at odd hours, a user who suddenly has many disconnects, or a server that carries far fewer sessions than usual all stand out when the data is next to each other.
How to do this in five minutes
Terminal Services Manager puts the readings for these six questions in one window:
- The summary cards below each list can show servers online, servers with errors, the least free disk, average CPU and memory, and the number of idle, disconnected, and locked sessions. Pick the ones you want under Cards, and they turn amber and red at levels you set.
- The inspector, with nothing picked, lists under Needs attention every reading that has passed its level, and under Pressure the worst server for each reading, each with a name.
- Servers > Administration opens Failed logons and Session history for the period you choose.
- File > Report builds an HTML status report of the monitored servers that you can open in a browser, save, or send to a colleague.
With the cards set up, the routine is a glance at them and a look at the lists they point to.
Make it a habit
Set the cards and levels once and leave them on the same screen every day. The point of the routine is that you recognize a normal morning and notice at once when this one is different.