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 Error_Code value of "-". Normally the Error_Code 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 Error_Code is null it makes the value "-". BUT even though the Error_Code 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 Error_Code for it. But with the Add-on there is a Status field and an Error_Code field with the same value. Is that really needed? Is there any reason why they decided to "clobber" the Error_Code field? For EventCode 4776, the Error_Code 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 (EVENT_TIMESTAMP_UTC.) 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 splunk_app_db_connect_server.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: FIELD_DELIMITER = \t HEADER_FIELD_LINE_NUMBER = 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 = drop_batchrequests ...and in transforms.conf: [drop_batchrequests] 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 FIELD_DELIMITER and FIELD_NAMES (since I can't use HEADER_FIELD_LINE_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 INDEXED_EXTRACTIONS and FIELD_DELIMITER in props.conf for the sourcetype on the Universal Forwarder. It seems redundant to tell it INDEXED_EXTRACTIONS= csv and FIELD_DELIMITER= , and INDEXED_EXTRACTIONS= tsv and FIELD_DELIMITER= \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