For the one that works, my guess is that you just got lucky as it had a 50/50 chance of picking the one you wanted. It's probably too late for this, but it may have behooved you to have your private and public IPs on separate subnets. ... View more

So, your "private" and "public" IP addresses are on the same subnet? In that case, you'll need to add a static route that points to your Splunk server and specifies which interface to use: Do a netsh interface ip show interface to get your interface indexes (Idx column). Then, do a: netsh interface ip add route 1.2.3.4/32 interface=1 nexthop=142.16.7.1 Where 1.2.3.4 is the IP address of your Splunk deployment server, 1 is the interface index you got from the show interface command, and 142.16.7.1 is the gateway for the 142.16.7.0/24 subnet. Modify appropriately with your real world values. You'll probably want to set up a static route to point to your indexer too. You can to a netsh interface ip add route /? to get help for the command. ... View more

Here's an example event: 08/09/11 12:09:26 PM LogName=Security SourceName=Microsoft Windows security auditing. EventCode=4768 EventType=0 Type=Information ComputerName=XXXX.YYYY.ZZZZ TaskCategory=Kerberos Authentication Service OpCode=Info RecordNumber=166028364 Keywords=Audit Success Message=A Kerberos authentication ticket (TGT) was requested. Account Information: Account Name: XXXX$ Supplied Realm Name: YYYY.ZZZZ User ID: S-1-5-21-9999999999-9999999999-9999999999-9999 Service Information: Service Name: krbtgt Service ID: S-1-5-21-9999999999-9999999999-9999999999-999 Network Information: Client Address: ::ffff:999.999.999.999 Client Port: 13340 Additional Information: Ticket Options: 0x40810010 Result Code: 0x0 Ticket Encryption Type: 0x17 Pre-Authentication Type: 2 Certificate Information: Certificate Issuer Name: Certificate Serial Number: Certificate Thumbprint: Certificate information is only provided if a certificate was used for pre-authentication. Pre-authentication types, ticket options, encryption types and result codes are defined in RFC 4120. ... View more

I checked by doing a source=WinEventLog:Security TaskCategory=Kerberos* | eval raw=_raw | table raw And fields are definitely delimited by = ... View more

Actually, the default behavior appears to be to look for a date in the filename if it can't find a date in the event. ... View more

Thanks, but what I'd like to do is use the timestamp from the log entry plus the modification date of the file to form the timestamp for the event. Is there a way to do that? ... View more

Here's another thing, isn't my sourcetype override happening at index time and my field extractions happening at search time? ... View more

I tried putting REPORT-bsf = bsf_scan, bsf_send, bsf_recv in my [source::udp:514] , but unfortunately I still didn't get my field extractions. ... View more

My concern would be that my REPORT and KV_MODE keywords would affect all of my syslog stuff. Maybe this is another example of why one shouldn't pump syslog directly into Splunk? 😕 ... View more

Your method makes sense, but my implementation has some suck in it. I've posted my failing as a separate question here. I like mw's idea of using the EXTRACT keyword, but I'm failing in the same way when I try to implement it. ... View more

Another option would be to have your ESXi hosts send to Splunk directly. See VMware KB article Enabling syslog on ESXi ... View more

I'm no rsyslog expert, but I've been doing some reading and it looks like, by default, rsyslog ignores incomming timestamps and substitutes its own. This makes me think that either you have a timezone issue on the server running rsyslog or that maybe you want to set the appropriate "...IgnoreMsgTimestamp" directive in rsyslog to off for the socket being used to accept the incomming ESXi logs. ... View more

Could it be that the first timestamp is put in by rsyslogd and the second timestamp (the one after "Vpxa: [" is the real timestamp from ESXi? In that case, you could use TIME_PREFIX = Vpxa: TZ = UTC In your props.conf. This will tell it to skip anything that comes before the text, "Vpxa:", thus skipping the first timestamp and using the second one. The second timestamp is cooler anyway, as it has subsecond resolution. 🙂 NOTE: in this case, you wouldn't need the MAX_TIMESTAMP_LOOKAHEAD parameter. FYI, The docs for timestamp recognition are here. ... View more

From props.conf: TZ = <timezone identifier> * The algorithm for determining the time zone for a particular event is as follows: * If the event has a timezone in its raw text (for example, UTC, -08:00), use that. * If TZ is set to a valid timezone string, use that. * Otherwise, use the timezone of the system that is running splunkd. * Defaults to empty. Because your events are saying they're UTC+2 (note the +02:00 on your timestamp), the timestamp in the event is taking precedence over your TZ setting. Per VMware KB article 1436, ESXi is always in UTC, so my guess is that either rsyslog is adding the timestamp, or maybe you're using the full ESX instead of ESXi. If you're using ESX, the KB article above will show you how to fix your timezone. Although fixing your timezone in your source is the preferred fix, you could also try adding MAX_TIMESTAMP_LOOKAHEAD = 19 To your props.conf so timestamp extraction ignores the timestamp in the event. This is a hack though. Fixing the timestamp on the incomming events is a better deal. ... View more

Maybe try msg.exe like in this answer? ... View more

Here's my guess on why the splunkd service couldn't pop a window... Think of two administrators logged into RDP sessions. When admin A runs your popup script, you wouldn't expect Admin B to see the window because they're in different sessions. Same idea with the splunkd service. It's in a different session. Plus, I think that services are normally "non-interactive". That is, they're specifically disallowed from manipulating the local GUI. That's why things like SQL Server need those little helpers running in your system tray. So something exists that the service can interact with. ... View more

Sorry, it was a typo on my part. The subsearch (the part in the square brackets) needs to start with the search command. I fixed the query above. I'm pretty sure Araitz's approach is more efficient. I was just trying to illustrate a different approach. Unfortunately, I've been indexing Windows DHCP events since before Araitz wrote his app, so my field names are guesses based on Araitz's comment. Hopefully I got them right. 🙂 ... View more