We recently migrated to a Splunk Environment where the Add-on for Microsoft Windows is installed and now have problems with some of our existing (migrated) dashboards and searches. Events of EventCode 4776 now all had an ErrorCode value of "-". Normally the ErrorCode in this type of event would be something like 0x0 for a successful authentication or C000006A for a wrong password. I looked at the contents of the Add-on and found a calculated field for Error_Code: EVAL-Error_Code = if(isnull(Error_Code), "-", Error_Code) So, if the ErrorCode is null it makes the value "-". BUT even though the ErrorCode in these events is NOT null, the calculated field is still kicking in..... Further looking into the contents of the Add-on revealed the field alias: FIELDALIAS-Status_as_Error_Code = Status AS Error_Code So, since EventCode 4776 does not have a Status field (so it is null), the alias is making the Error_Code field value null, which then gets adjusted to "-" by the calculated field. A different type of event - EventCode 4625 does have a Status field. There is no native field named ErrorCode for it. But with the Add-on there is a Status field and an ErrorCode field with the same value. Is that really needed? Is there any reason why they decided to "clobber" the ErrorCode field? For EventCode 4776, the ErrorCode field is very useful for identifying successful vs unsuccessful authentications and determining the reason for the failed authentications. I can create a field extraction to get the value out but I really don't think I should have to in this case because it seems like this has to be some kind of a bug / undesired outcome. I'm thinking of submitting a support request to Splunk but was curious as to other people's thoughts on this first. ... View more

I have Splunk DB Connect and the Add-on for Oracle Database installed and configured using the oracle:audit:unified template. Initial configuration was done keeping the Timestamp column the default (EVENTTIMESTAMPUTC.) This worked great. Then in order to get the indexed timestamp to be local time I changed the Timestamp column to EVENT_TIMESTAMP. Doing this resulted in being prompted for the Datetime format (Java SimpleDateTimeFormat.) I have tried entering in a few different formats, none of which work. No matter what I have tried, things are not working and I do not get any events indexed. An example of this field's value is: 2018-05-14 11:24:33.349604 America/Chicago The current Datetime formats that I am trying unsuccessfully are: yyyy-MM-dd HH:mm:ss.SSSSSS Z yyyy-MM-dd HH:mm:ss.SSSSSS z yyyy-MM-dd HH:mm:ss.SSSSSS yyyy-MM-dd HH:mm:ss.SSSSSS VV I keep getting the following in splunkappdbconnectserver.log: java.time.format.DateTimeParseException: Text '2018-05-14 11:24:33.3928 America/Chicago' could not be parsed at index 20 Does anyone have any tips to troubleshoot or see what I am doing wrong? ... View more

I have some TSV files that I am forwarding with a Universal Forwarder. I have props.conf configured on the UF with the following for the sourcetype: FIELDDELIMITER = \t HEADERFIELDLINENUMBER = 1 That has worked great. But now I have a need to drop some events so they do not get indexed. On the Indexer I have configured the following for the sourcetype in props.conf: [] TRANSFORMS-null = dropbatchrequests ...and in transforms.conf: [dropbatchrequests] REGEX = batchRequest DEST_KEY = queue FORMAT = nullQueue At first it was not working, I was still getting events that contain batchRequest. So I temporarily removed the structured data configuration on the Universal Forwarder (shown above) and the transform worked as desired - batchRequest events were no longer indexed.... But now the tsv format and field recognition was not there... So I tried to configure everything in one place. On the Indexer I specified the structured data config in props.conf using FIELDDELIMITER and FIELDNAMES (since I can't use HEADERFIELDLINE_NUMBER on the Inedxer.) The result of that was the batchRequests events were not indexed, but the fields (from the header row) still were not extracted. Am I doing something wrong? Or is there some reason why these configurations (TSV/structured data field recognition and dropping certain events to the nullQueue) on the same sourcetype will not work together? I can get each to work independently - but not together. ... View more

I am going to be forwarding CSV and TSV files, and was wondering if I need to configure both INDEXEDEXTRACTIONS and FIELDDELIMITER in props.conf for the sourcetype on the Universal Forwarder. It seems redundant to tell it INDEXEDEXTRACTIONS= csv and FIELDDELIMITER= , and INDEXEDEXTRACTIONS= tsv and FIELDDELIMITER= \t If it is a csv it should be obvious the field delimiter is a comma. And if it is a tsv it should be obvious the field delimiter is a tab. Is there a reason to configure both? Or if only one is needed is there a reason to use one over the other? ... View more