Monitoring servers remotely

Staying on top of customer servers without making a visit using logs, scripts and consoles – and how Windows Server 2008 helps

The daily ‘care and feeding’ of managing and monitoring Windows servers can take enough of your time when those servers are on the other side of the building. But, when they’re on the other side of the city or even the world, your daily activities grow ever more challenging.

See the Windows Server 2008 tools described in this feature in action:

Click here to see Greg Shields walk you through Data Collector Sets in Windows Server 2008

Click here to see Greg Shields walk you through Event Subscriptions in Windows Server 2008

When Windows servers aren’t easily accessible directly through their native console, the traditional mechanisms for managing them don’t work as well or in some cases don’t work at all. Clicking ‘Next, Next, Finish’ to install applications, bringing up the Event Viewer to check on server health, verifying performance through PerfMon; all become more challenging when you’re far removed from the physical systems themselves. And as always, the tools are subtly different with Windows Server 2008. Especially when you have a wide range of customers each with different systems, you need a different way of thinking if you’re to stay on top of the administrative requirements of servers spread across multiple locations.

Before getting into the specifics of how to simplify these administrative tasks, it’s worth thinking about how you can organise them. The actual management and monitoring of Windows servers breaks down into a fairly discrete set of tasks, each of which you can approach in ways that make sense in remote server scenarios.

Interacting with the console
Though the actual console session isn’t something you’ll easily be able to access with native Windows tools, a remote session using Remote Desktop can provide a nearly similar experience. Getting that Remote Desktop connection to work through firewalls and over the Internet is a key technique for enabling access to server desktops.

Collecting and viewing event logs

The Windows server system includes an extensive system for capturing and collecting information about events on the system. The Windows Event Log collects events across each system component and installed software into its centralized log for later review. But one historical limitation of that log is its per-server configuration. Collecting event information across multiple systems has traditionally required additional tools or coding expertise to accomplish.

Collecting and viewing performance information
Gathering and logging performance information through PerfMon is another critical activity for administrators. Without good performance data, it is impossible to determine the health of servers over the long term and in comparison with other servers. As with the Windows Event Log, collecting this information across multiple servers can be a complex undertaking.

Scripted actions

When the count of servers you need to manage is small and their location is centralized, you can easily complete most actions through GUI tools at the console. But as the number goes up you need alternate mechanisms for configuring them. Using scripted actions with remote support is one way to ease the management burden.

For each, we’ll take a look at the tools that natively available in Windows Server 2008, that you can use with a remote server.

Accessing Remote Desktops
The Remote Desktop Protocol (RDP) is natively available on all instances of Windows Server 2008. This means that every Windows server has the built-in ability to transfer the display of desktop sessions across the network to any receiving client. Enabling this capability is as easy as opening Server Manager and clicking the link to Configure Remote Desktop. The screen that opens gives you three options to enable or disable Remote Desktop capabilities. Of these, the third option, ‘Allow connections only from computers running Remote Desktop with Network Level Authentication’, is the most secure. Enabling this option requires incoming Remote Desktop clients to authenticate to the server using domain credentials before any access to the desktop session is allowed.

One problem with the way in which this checkbox is exposed is that it requires console access to initially enable Remote Desktop. As an alternative, you can enable Remote Desktop remotely by changing the registry DWORD value of the key

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\fDenyTSConnection

from 0 to 1. Reboot the computer for the change to take effect. If you prefer using a graphical tool to make a change like this, the Remote Desktop Enable Utility ( does the same as changing this registry key
on remote systems.

You need to extend this solution for servers that are separated by the Internet. Remote Desktop by default functions over TCP port 3389, which is not a port that is typically passed over the Internet. You can however change that to another suited for the environment. By changing the DWORD value for the key

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\ RDP-Tcp\PortNumber

to an alternate value such as TCP port 80 or 443, Remote Desktop traffic can pass through customer firewalls.

If you set up and secure a specified ‘management server’ at the remote location and enable Internet-based Terminal Services access to that server, you can use it as a gateway for managing other servers on the remote LAN. Be aware that this configuration is not the most secure solution possible, requiring what is effectively direct connectivity from the Internet into the internal LAN for management. That being said, as Network Level Authentication requires pre-authentication prior to any RDP connections, this solution can be acceptable in low-risk circumstances.

Collecting Remote Event Logs
The Windows Event Log is a significant source of useful monitoring information, telling the tale of what problems and issues there might be on a server. The problem with the Windows Event Log, however, is its server-centric approach to storing log information. Storing log information just for that single server makes it difficult to gain a holistic view of problems across the network. If a problem occurs between two servers used to drive a particular network service, you have to trawl through both event logs separately for information about the problem.

Until the release of Windows Server 2008, it was not easily possible to aggregate event log entries into a single location using native tools. You could kludge together solutions from scripts and batch files when you absolutely had to, but the wholesale consolidation of event log data into a single store hasn’t been easy to do with Windows tools alone.

Windows Server 2008 adds a new service called Windows Remote Management to the mix. This service provides a way to manage and monitor Windows servers using firewall-friendly Web services-based protocols. Although much of Windows Remote Management is relegated to use by code developers, one functionality it gives you is the ability to transfer Event Log information from one server to another.

With your management server in place, you can create an event subscription that will transfer either the entire contents or merely a subset of log data from one server to another. This lets you aggregate Event Log data from multiple machines into a single place, eliminating your need to look in multiple locations for information when you’re already busy troubleshooting.

By default the destination log on the management server will be the Forwarded Events log, though you can select a different log to store events.

Subscriptions like those created here are intended for use in small environments. Collecting logs from large numbers of servers or events will have a negative impact on the performance of the server. But, for environments that need a simple answer for collecting logs, this costs you nothing and brings monitoring data together into a single, easy to read location.

 -- click image to enlarge --

Subscriptions provide a mechanism for gathering log data from other server event logs.

Managing Remote Performance
Performance monitoring is another source of critical information about your servers. Yet the idiosyncrasies of the traditional PerfMon tool have made long it a difficult solution for historical performance monitoring. PerfMon’s file-based mechanism for storing performance data can get unwieldy over time, especially when each reboot forces the creation of a new and separate log. The end result can be numerous log files, stored on each individual machine, of which each must be separately analysed to get a true sense of long term performance. Windows Server 2008 (and Windows Vista) simplify some of the historical problems with this solution through the addition of what are now called Data Collector Sets. These Data Collector Sets, similar to PerfMon’s old abilities, can monitor multiple machines while storing counters in a single location rather than local to each monitored machine.

Again, the free way of doing this involves using your management server. In small environments with only a few servers to monitor, it is possible to use a single Data Collector Set to monitor a few key counters on multiple remote computers. By setting up PerfMon in this way, you can view counters across all monitored machines in one place, aligned by their time of measurement. This gives you not just a view of how servers are performing across all managed computers, but a way to quickly see if the performance of one computer is affecting others. Do this in the Reliability and Performance Monitor console.

Scripted Remote Actions

Monitoring server behaviour is important, but administrating servers means more than just watching their behaviour. When you want to make a change, improve a behaviour, add or update additional functionality or troubleshoot the server when it experiences problems, often that means changing and updating the configuration. As with other server admin tasks, performing these actions is easy when you have direct access to the server’s console. But when you’re far away from that server, often the only solution is to move away from GUI-based tools to those you can initiate and run from the command line.

The various flavours of UNIX and Linux benefi ted from command line-based administration for many years before Windows brought about GUI-centric administration. Windows has traditionally lagged behind other OSs in its ability to perform actions at the command line. But those tools are getting better.

Two that any remote administrator should seriously consider are the Sysinternals PSTools toolset (now owned by Microsoft) and Microsoft’s new scripting language PowerShell. While there are entire books covering the uses and syntax associated with PowerShell and we’ll be looking at it in depth in future issues, basically the PowerShell command shell offers you the ability to view and change information on local and remote servers. Though the use of easily-understood “cmdlets” that use a verb-noun format, administrators who’ve struggled with other scripting languages can now easily grab and update configurations from remote computers.

The PSTools toolset was originally designed by Sysinternals as a solution for accomplishing many common administrative tasks from the command line. Making them even more useful is their ability to remote other servers to accomplish the same tasks. The PSTools include a large number of tools that run from the command prompt to accomplish certain tasks. Going back to the concept of a management server, these tools can be run from that location against any of the computers in the environment. The most useful to start with is psexec. This can launch processes on remote computers, allowing you to accomplish any action that could normally be done via the command prompt – but with the ability to do it on any number of remote computers.

For example, you can instantiate a command prompt on the local computer that runs in the context of a remote computer. Much as a Telnet or SSH session enables you to run command line actions on a remote UNIX or Linux server, Psexec can do the same on a Windows computer. Once you’ve downloaded, unpacked and copied the PSTools to somewhere in your management server’s path, you can launch a remote command prompt by using the command

psexec \\{computerName} cmd.

After you run this command, any other command you run within this shell actually runs on the remote computer; that means you can do anything you could do sitting in front of the machine.

Commercial tools
All of these capabilities are great for remotely monitoring and even managing servers no matter where they may be in the world. But each involves a certain amount of work to set up. Some are not the best in terms of security. Others may not provide the holistic systems management approach you may need across multiple sites, multiple customers and multiple domains. If you’re providing IT support for many companies, these zero-cost solutions might not scale well across all your customers.

And when it comes to extending systems management tasks to software installation, patch management, software update, configuration control and personality migration as well as the simpler tasks covered here, you’ll need to look elsewhere for additional management platforms that offer capabilities over and above what Microsoft can provide with the native and on-board tools.

Microsoft System Center Essentials (SCE) is an excellent collection of the systems management functionality commonly associated with System Center Configuration Manager plus the monitoring capabilities you get with System Center Operations Manager. However, SCE works best when used within a single domain structure that doesn’t need to span the Internet.

Other third-party solutions from vendors like Kaseya, KACE, and Silverback (now owned by Dell) can provide better support for managing computers over the Internet. In addition to the administrative tasks covered here, these management platforms often provide their own graphically- oriented mechanism for creating scripted actions and deploying software, eliminating the need for creating complex custom scripts or batch files otherwise required through native tools.

Best of all, if you manage multiple environments, some of these management platforms support the ability to securely manage multiple environments from a single console. This “multi-tenant” capability can be a major competitive advantage when you need to quickly resolve client problems without the hassle of physically being on site.

With the widespread scaling of servers and hosted services, as well as the movement of services into ‘the cloud’ it is inevitable that even if you’re not needing to manage servers remotely yet, it’s going to be part of your job soon. Knowing just what you can achieve can make the difference between getting the job done effectively and long bouts of overtime.

Share |
Write comment
security image
smaller | bigger



Subscribe and get the magazine in the post before it's online

Subscribe and get access to all of the back issues

To read a sample eMagazine - March 2010



None of your customers are complaining about viruses, their network being slow or strange things happening on their new PDAs and laptops; is it time to take the afternoon off? Maybe, but before you do, make sure things will look as good next week by making sure you know what you’re defending against. Microsoft has a set of resources at covering the current threat landscape and showing ways to help protect your clients and their customers, including analyses of data collected from millions of users, strategies, mitigations and countermeasures. read more


Unified communications


The #1 Bestseller for Only 77p

Key resources

Login to view Key Resources