/ ____|
| |  __
| | |_ |
| |__| |
 / _ \
| (_) |
 _ __
| '__|
| |
| |
| |
| |
| |
  __ _ 
 / _` |
| (_| |
 _ __  
| '_ \ 
| | | |
|_| |_|
| |
| |
      ___    ___    _ __ ___  
     / __|  / _ \  | '_ ` _ \ 
 _  | (__  | (_) | | | | | | |
(_)  \___|  \___/  |_| |_| |_|
Reverse, Repurpose, Resolve

Windows event forwarding and missing event text

2018-08-16 (from old web site)

Windows Server has, since some time, a beautiful new feature: event forwarding.
The idea is not all that new, we had syslog in the Unix world since some time, but this system is lots more interesting.
To make it short, just google around to find the way to setup subscriptions and have your machine receive logs from other servers. It takes 5 minutes to configure and can be done via GPO also.
The problem arises when you try to read these logs. You can incur in lots of these messages:

The description for Event ID xxx from source Microsoft-Windows-Security-Auditing cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

The explanation is simple. The event log does not contain the full message text, but only a reference to a (usually) localized DLL. You must have the right DLLs on your system. This is not new, you can find this everywhere on the net, I would only clarify several things.

Where to find these DLLS
Jump to this registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog, find the event source you need (securityfor the message I posted) and then the right subkey (you can read Microsoft-Windows-Security-Auditing) in the message.
The EventMessageFile contains %SystemRoot%\system32\adtschema.dll. That is the DLL we need on the collector. You can copy it from the original server and copy to your log collector, even changing the path if you feel. Then you need to setup the same keys in the registry to point to that DLL. The easies way is to export the key from the original server and import on the collector, eventually changing the dll paths.

Just a final reboot and... The same problem arises again. You have the DLLs, the registry settings, but events are not resolved to their text.
After deep searching and experimenting I found the solution:
- list the subscriptions on your collector by issuing wecutil enum-subscription
- change the event format from RenderedText (default) to Events: wecutil ss <sub_name_from_preceding_command> /cf:Events

Now, according to documentation, RenderedText should contain exactly that, the complete message text, but seems not working. Using the Events format it works just fine and, as an added bonus, it reduces the network traffic.

Just a little hint: the collector service is a delayed start one, so wait some moments before issuing wecutil commands, or you'll get RPC not available errors.

Simple, once you know what to do :)