OK. Just wanted to let you know how it really _should_ be done because otherwise it can cause many strange issues (like the one you're having). But back to the point. What you need to do is to set the DATETIME_CONFIG=CURRENT in the appropriate place. But which place is it? Well, the first question is - on which component you need this to be set. I assume you're talking about "normal" windows eventlog/perflog data and internal splunk logs. The data is parsed on the first "heavy" (based on a full splunk enterprise installation package, not a UF) component in event's path. So if your setup is UF->HF->indexer(s), you need to set configure it on the HF. And now the tricky part. If you're collecting logs from the ForwardedEvents eventlog, I'm afraid I don't have good news - since the logs from ForwardedEvents are collected with the same host value for all hosts so you have no way of isolating a single host. Unless you do some magic like defining a metadata field in the UF and doing an ingest-time eval overwriting _time but that's a way more advanced topic than we're talking here. So sticking to the basic option - your event by default has its raw data contents, the destination index, and three metadata fields - sourcetype, source, host. The sourcetype and source will (at least in any normal situation should) be the same for all your hosts. So the only field that can differentiate this "problematic" host from other ones is the host field. So you should insert a stanza into the local/props.conf (either in etc/system or - preferably - in your custom app) with contents: [host::my_host] DATETIME_CONFIG=CURRENT Of course substitute "my_host" with the value appropriate for your UF name (but watch out - the host field value can be overwritten in settings for any input on the UF - see my remark about the ForwardedEvents - all inputs reading from wineventlog://ForwardedEvents typically set host=WinEventLogForwardHost - that's why you can't tell one forwarding host from another). Typically you can see the host value "raw" in the internal events your UF sends to _internal index. Final warning - since the "current" time configuration is being applied at the point of parsing, if you have any delay between UF and HF (for example due to network outage or HF restart), your data will have a wrong timestamp since the source-given time will be ignored and the HF-given timestamp will be applied at the time the data reaches HF's input.
... View more