Revisiting Remote Administration – The Event Log Collector

Think globally, act locally may be a great mantra for many aspects of computing, but wearing sweaters or a parka in the summer just to cozy up with all your servers in the cooly air conditioned data center hasn’t been considered cool in at least a decade. Remoting is typically far preferred even for most server administrators with just one server room.

Most devices, routers, switches, and of course workstation and server operating systems support one or more forms of remote management. Windows Server 2008 (both releases) support technologies such as Remote Desktop and Web Services Management (WS-Management). Microsoft often refers to their implementation of the industry standard WS-Management as WSMan or Windows Remote Management (WinRM). Microsoft actually started supporting the foundations for such web services back in Windows Server 2003, with IIS 6.0 supporting the Simple Object Access Protocol (SOAP) which is the foundation for a family of Web Services standards.

While most Windows system administrators likely do not care about the details of SOAP itself, I regularly get questions about the features and services which are dependent upon it. Like Remote Procedure Call (RPC) and Windows Management Instrumentation (WMI), peoples’ interests often lay in what can be done with the technology. One particular feature which several students were curious about in a class this week was Event Subscriptions.

Internet standards for collection, storage, and analysis of event log information, derived from the syslog subsystem of UNIX and sendmail heritage, have existed for several years, in the form RFC 3164 and its successor RFC 5424. Syslog’s architecture supports originators, relays, and collectors. Similarly, Microsoft’s Event Collector Service supports originator and collector roles.

Both Windows Server 2008 and 2008 R2 support using the Event Collector service in source initiated and collector initiated subscriptions. An event collector subscription is the configuration of an agreement between two Windows systems for one system to send specific event log entries to be received by the other. Although the configuration of such subscriptions is manual, once configured, these subscriptions are persistent. Yes, if you’re creating event collector subscriptions for hundreds or thousands of computers, automation of these relationships via tools such as Windows PowerShell could be essential. For starters, we shall just look at the basic configuration.

The configuration of the Windows Event Collector (WEC) and WinRM on which it depends could be done with great care for particular details, or there is the quick configuration (QC), a.k.a. quickconfig. Consider the following two commands which could be used on both computers prior to setting up one or more subscriptions.

wecutil qc
winrm qc

What is also needed beyond the quick configuration of the WEC and WinRM is to allow the two (or more) systems to communicate as trusted hosts via WinRM, and then to configure the WEC with one or more subscriptions.

winrm set winrm/config/client @{TrustedHosts=”localhost”}

This command simply configures WinRM to trust itself. While that is useful as a basic test of the functionality on a test machine, in a test network or production system, the names or addresses of the trusted systems would be used instead of merely localhost.

wecutil cs mySubscription.xml

This command creates an event collector subscription (cs = “create subscription”) as defined in the XML file mySubscription.xml. The details of this configuration file are beyond the scope of this article, however we’ll likely delve into such details soon!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.