Windows Insider

Syslog ... 20 Years Later

Greg looks at a "new" feature in Vista and Server 2008: Event Log subscription.

These days everything old seems suddenly new again. A prime example of that adage is the "new" Event Log subscription feature in Windows Vista and Windows Server 2008.

Twenty years ago, computer programmer Eric Allman was working on sendmail and developed the Syslog protocol to transfer Unix log data across the network to a central repository for aggregation, archival and cross-device analysis. With Vista and Server 2008, Windows now has a form of Syslog baked right into the operating system. It's only about twenty years behind schedule, if you're counting.

The idea is that some problems occur on multiple machines, so you may need to analyze log data from more than one computer for troubleshooting. If you consolidate events from each machine into a single log and sort it by time stamp, you'll get a better idea of what's going on. This type of analysis helps when you can't track down the precise nature of the problem.

For example, let's say you're having a problem between a Vista client and a machine running Windows Server 2008. Both systems are pumping data to their respective System Event logs, but you're having trouble aligning what's happening on each machine. In this case, you'll need to create a subscription on the server to inject system log data from the client into the server's system log.

Setting up a subscription isn't difficult. First, launch the Event Log and click the node for "Subscriptions" on the server. You'll be asked to start the Windows Event Collector Service and configure its start mode to Automatic. This service handles collecting Event Logs from your remote machines.

In our example, the Vista client is the "forwarder computer." The forwarder computer forwards events to the "collector computer," which is our Server 2008 box. Both machines must be running the Windows Remote Management (WinRM) service and the server has to be running the Windows Event Collector Service. To start and automatically configure this service, enter the following at the command prompt on each computer: winrm quickconfig.

Figure 1
[Click on image for larger view.]
Figure 1. A configured and active subscription pulls data from a client machine.

Remote Configuration
Windows Remote Management is an interesting new tool for remote management that we'll cover in a future column. We're using it here to complete an initial basic configuration. That configuration starts the service and sets its startup mode to Automatic (Delayed Start), punches a hole in the Windows Firewall and creates a WinRM listener on HTTP://* to accept remote management requests to any IP on the machine.

By default, subscriptions use computer accounts for permissioning, though you can substitute a user account. The benefit of using computer accounts means that you don't need to create old-style service accounts to handle subscriptions. However, you do have to manually drop the computer account of the subscriber computer into the Administrators group on the forwarder computer. You can use Active Directory groups to do this.

Once you've finished these steps, you can create a subscription. Subscription data can flow in either direction depending on how you set it up. You always start by creating a subscription at the subscriber computer. Identify the source computers from which it will pull data. From the Subscriptions node in the Event Log, right-click and choose to "Create Subscription." Give the subscription a name and a description. Then choose the destination log where you want to store the incoming data.

In our example, we want System log data from another machine to merge with our server's System log. To do this, change the default destination log from the "Forwarded Events" log to the System log. In this example, though, we're merging logs for a short time to help troubleshoot a problem.

The Forwarded Events log is well suited as a permanent repository for multiple machines to store their log data for later archival, as well. Storing security log data for compliance purposes is an excellent example of this type of use.

Once you've configured the destination log, select your source computers and the types of events you need to collect. Here's where the real power of the "new" Windows Event Log becomes evident. When selecting events, you can choose your events at a granular level-even down to specific event IDs or keywords. This helps reduce the amount of data you'll need to analyze later.

Subscription Speed
Subscriptions come in three flavors. These depend on the type of problem you're attempting to track down, the quality of your network's bandwidth and the speed at which you want the log data to arrive. The closer to real time you want the log data, the more network resources it will require to gather:

  • "Normal mode" configures the target computer to pull event information from the source computer five items at a time, with a batch timeout of 15 minutes.
  • "Minimize bandwidth" reverses the direction of the delivery, pushing the data from source to destination. This is helpful if bandwidth is an issue. The influx of log data at the destination is slowed with the batch timeout and the heartbeat interval increases to six hours.
  • "Minimize latency" mode works well for gathering real-time or near real-time data. This also uses push mode, but significantly dials up the timeout to every 30 seconds.

You complete this last selection by clicking the "Advanced" button. Once you've completed the selection and configuration process, test the connectivity and start the connection. If you see an Active connection status, you've set it up properly -- you'll soon start seeing log data arriving in the destination log.

Whether you're setting up subscriptions for short-term troubleshooting or consolidating security logs for long-term compliance, this "old" functionality is something you'll appreciate just as much as when it was new.

(10/30/2008: This article contains a correction; Eric Allman developed Syslog. -- MDo)

About the Author

Greg Shields is a senior partner and principal technologist with Concentrated Technology. He also serves as a contributing editor and columnist for TechNet Magazine and Redmond magazine, and is a highly sought-after and top-ranked speaker for live and recorded events. Greg can be found at numerous IT conferences such as TechEd, MMS and VMworld, among others, and has served as conference chair for 1105 Media’s TechMentor Conference since 2005. Greg has been a multiple recipient of both the Microsoft Most Valuable Professional and VMware vExpert award.

comments powered by Disqus

Reader Comments:

Thu, Oct 30, 2008 Michael Domingo Irvine

Yuri, it has been corrected. Thanks for pointing this out (yes, we know it's been a while since the original article was published...).

Tue, Feb 19, 2008 Yuri Denver

Sorry, I just now read the first comment. IMHO "we regret the error" is not enough. Please correct the paragraph. We already have MS taking credit for too much without printed corroboration!

Tue, Feb 19, 2008 Yuri Denver

From Wikipedi: "Syslog was developed in the 1980s by Eric Allman as part of the Sendmail project, and was initially used solely for Sendmail." Please correct your second paragraph.

Thu, Jan 17, 2008 Anonymous Anonymous

Why not give credit where it's due? Eric Allman created it as part of the Sendmail project in the 80's. So you could say "Microsoft is 20 years behind Unix when it comes to collecting and aggregating logs." Hopefully it actually works and the logs have useful information in them.

Mon, Aug 13, 2007 Greg Shields Anonymous

Hi all, Greg Shields here. If you're reading this article you may have noticed the editing error in the first paragraph, "Twenty years ago, Microsoft developed the Syslog protocol..." That sentence should have read, "Twenty years ago, the Syslog protocol was developed..." We regret the error.

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.