The following is one of the user requests that was received.
1) being able to forward a log item to a DB, possibly in asyc mode (e.g. MSMQ, BITS) and/or to MOM/SMS for analysis and proactive maintainance (e.g. push out a FIX with SMS)
2) group events into 1 items instead of having hundreds of same items
3) please do the logs in a XML (parsable) format
4) ability to redirect/map logs to a network share
5) Larger default sizes
6) Automatic rollover (daily/weekly/x items)logs - old logs to be stored on disk
Here is the reply
1) It will be possible to subscribe to a log using a filter. The subscriber could then forward the events.
2) Right now there is no plan to support Event aggregation as part of service natively but this can easily be done by enterprise products which are written on top of this infrastructure.
3) The new system is based on xml. The internal format isn’t xml text, but getting an xml representation of the log will be quite easy through rendering. A utility will ship that will take an xpath expression and create an xml text file
4) The issue with that is that the service will not generally have access to network share. It will be possible to create or read backup on the network, but not to have live logs there since that requires the service to have access without an active client. Two things which might help here. The firt one is that new Eventlog does provide the way to change the local location for the log. Secondly, one can use Event forwarding to forward it to other machines.
5) Done
6) We do have the capability to create a backup and clear the log once it hits a certain size. We don’t base the backup on time in eventlog service. Alternatively, one can schedule a task (based on new Task Scheduler) to run a commandline at a certain time.
Welcome to Windows Eventlog BLOG
This blog has been created to allow us at Microsoft to provide information on the new Windows Eventing system and to hear users’ opinions and questions.
Since Windows users at large were able to see the new Event Log with Beta 1 of Windows Vista, a number of questions may arise about the new capabilities of Windows Eventing. We would like to let everyone know that with the new system:
- Developers will get an incredible opportunity to make their software more manageable and easier to debug, and to create better system management utilities and tools.
- Administrators will be able to manage systems more efficiently and diagnose issues faster.
All of this is possible with the new features that
1) Provide structure to events
2) Make events discoverable by allowing one to find which events a program may publish before the events are published
3) Providing reliable asynchronous API for publishing events
4) Improving publishing performance
5) Providing API to control eventing configuration without having to write directly into the registry
6) Providing API for querying events and rendering them into user-readable form
7) Allowing software to create subscriptions to events of interest and triggering scripts or programs based on events in the Event Log
8) Remote subscriptions using WS-Management and WS-Eventing protocols that forward events to be collected at a central location
First and foremost, the information on the new Windows Eventing is available on the MSDN in the Using Windows Event Log section. You can learn how to create an event publisher and find preliminary documentation on the new APIs.
Additionally, the information about the new Windows Eventing is going to be presented at the PDC05 breakout session FUN316 - Windows Vista & "Longhorn" Server: Publishing and Consuming Events. PDC05 attendants can get additional information at the Fundamental Lounge.
