In my lab I don’t really have any monitoring system (yet) like Operations Manager. I have however played around in forwarding events using syslog to both Kiwi Syslog Viewer and Splunk (which I love by the way).

But I’m amazed that so few mention the possibility to use the built-in features of Event Log forwarding (subscription) using WinRM in Windows 2008/7/Vista. Imagine getting all your event logs to one common place without any extra products in just a few minutes! I guess it might be because the Event Viewer haven’t changed much since last decade prior to Windows 2008, and honestly, event logging is simply not that sexy…

So what we have is a Windows 2008 server running as an event log collector which gets the event log from one or several sources. To prepare, we need to do 3 steps:

  1. On the collector, on an elevated command prompt, run the following command to start the Windows Event Collector Service, change it to Automatically (Delayed Start) and enable ForwardedEvents channel if it is disabled. See this for more info.

    wecutil qc
  2. On each source, we need to enable WinRM:

    winrm quickconfig
  3. By default, the collector server can’t simply get the event logs from the sources, so you have to add the collector computer account to the local Administrators (if the source is 2008 R2, Event Log Readers group is said to be enough if you’re not collecting Security log, but see Possible Problems later in this article for more info).

Read here for some more additional considerations if you’re running in a workgroup.

Then we’re ready to add Subscriptions to the collector server. Login to the collector, add the Event Viewer MMC, right-click Subscriptions and choose Create Subscription:

Here you can choose some various settings.

When adding Collector initiated computers, it’s good to know that you can test the connectivity:

You have to choose events to collect using a filter you define where you can choose only to filter out Errors and Warnings, just certain sources, Event ID numbers within certain ranges, keywords etc. Ah, just make sure not to select too much (it will warn you), see possible problems below.

The Advanced settings might be important if you’re using another port for WinRM, running HTTPS (this might be a future post here if you’re interested), getting the logs over slow WAN-links or want to use a dedicated user to get the event logs.

Selecting OK will add the collection. Here you can right-click to get the Runtime Status and also Retry if it fails. Notice that even you see that green icon here, collecting the logs might fail so make sure to check Runtime Status.

Once working, you will find the forwarded event logs. Keep in mind if the logs are huge, the initial collection it might take some time.

You can also do Properties -> Subscriptions tab to get the configuration.

Possible problems

If it doesn’t work, check the source and make sure it has a local firewall rule which is correctly configured which allows the WinRM traffic. One comment on this article shows there’s a different port on 2008 vs 2008 R2.

At one point I got the following error message when I tried to put the collector computer account in Event Log Readers group only and not in local Administrators group.

[WDS1.ad.local] – Error – Last retry time: 2010-09-28 16:46:22. Code (0x5): <f:ProviderFault provider=”Event Forwarding Plugin” path=”%systemroot%\system32\wevtfwd.dll” xmlns:f=”http://schemas.microsoft.com/wbem/wsman/1/wsmanfault”><t:ProviderError xmlns:t=”http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog”>Windows Event Forward Plugin failed to read events.</t:ProviderError></f:ProviderFault>  Next retry time: 2010-09-28 16:51:22.

Putting the collector computer account in the local Administrators group of the source computer, instead gave me:

[WDS1.ad.local] – Error – Last retry time: 2010-09-28 16:43:18. Code (0x7A): The data area passed to a system call is too small.   Next retry time: 2010-09-28 16:48:18.

Turns out I did select too many logs to collect in the filter. Selecting for example only the System logs got rid of this. Maybe this was a problem in my lab only but keep that in mind.

wecutil