If you take a look at this event, you can see that you are actually using up more disk space/license on the ending event description than the actual event text. There is no benefit to keeping this text in the event. The way you would get rid of this text is by using a props/transforms set that discards that text and keeps the rest of the event in tact.
Remember, this configuration needs to go on the first Splunk Enterprise system where your Windows Event Logs are being forwarded (hopefully straight to your indexers).
We can do this easily with the configuration example below:
Let’s dive into what exactly is happening with this transforms call.
First we’re setting a large lookahead value that allows us to grab all the actual event text we care about. Next we’re using regex to capture the entirety of the event text and store it in a capture group, leaving off the wall of text that we don’t care about which starts with “This event is generated”.
Ultimately this entire operation is going to discard everything except what is inside the capture group when it writes the event to a bucket.
Now, if we take a peek at the props stanza, you’ll notice I have both a source and sourcetype stanza for the same thing. I felt this was worth noting because in the older version of the Windows Add-on all of the configuration was done by sourcetype. In the newer version of the Windows Add-on all of the configuration is done by source instead of sourcetype. If you’re not certain which one to use, just go with the source call because that should work for the new and old version alike.
It’s also important to remember that you are responsible for understanding how this will permanently alter your own production data in Splunk, so please be careful!
How Do I Apply This?
Now that you have all the information you need to make these changes, you might be wondering “Where on Earth does this configuration go?”
I’m going to assume you’re following Splunk best practices, meaning you have a Deployment Server setup with your Splunk Universal Forwarders configured as clients and a standalone indexer (or index cluster) where those universal forwarders send data to. If your environment is setup differently, you may have to adjust this process and put the configuration somewhere else.
Whitelists, Blacklists, and Input Layering
TL;DR: Get your inputs.conf (optionally containing whitelists/blacklists) to your UF’s using a Deployment Server.
If you have administrative experience with Splunk, you’re probably used to putting configuration similar to this on an indexer or heavy forwarder since it’s altering data you index. Winevent Log whitelists and blacklists are a special exception because these operate at the input level, directly on the UF (they have a special pipeline/processor set). This means we need to put this configuration on the Deployment Server within $SPLUNK_HOME/etc/deployment-apps.
If you think back to earlier, you’ll remember that I mentioned most people will put this configuration directly in Splunk_TA_windows/local/inputs.conf. However, since you’re reading this, I hope to steer you in a direction that will allow you to make this configuration more modular as your environment scales.
Leave “Splunk_TA_windows” alone, don’t modify it at all. Instead, create a set of apps following a naming scheme. You want to think about how you can apply this with a layered strategy to create “base” layer and then add any custom layers on top which may be applied to a specific server or set of servers.
Here’s an example of what this list might look like when you’re done:
The uf_winevent_base_inputs would be deployed to all of your Windows systems, and you would deploy other apps as needed depending on the role of each server.
For example, your Domain Controllers would end up with both the uf_winevent_base_inputs and uf_winevent_ad_inputs apps in this example. Remember that if you have overlapping whitelist/blacklist numbers in two apps, lexicographical order is going to determine which whitelist/blacklist wins (meaning you might need to adjust an app name so that it wins).
Once you have your naming scheme and apps created you’re going to define the stanzas you want in inputs.conf with the whitelists/blacklists configured under each relevant stanza. Your end result might look something like this:
Now that you have your strategy in place, you need to create serverclasses which follow the same pattern of one serverclass per “layer”.
For simplicity sake, I like to follow the same naming convention and call the serverclass something similar to the relevant app name. Lastly, make sure when you create your server classes to watch the scope of your client list so that you’re not missing any hosts or applying configuration to the wrong hosts.
Eventually, what you end up with may look like this on your deployment server: