There are several problems with version 1.0.3 of this app. First, the typo: Navigate to TA-sepapp11/default/inputs.conf.local When you use create your inputs.conf be sure to edit the "sourcetype" line in the stanza that references agt_system to say "sep11:..." instead of "se11p:..." This is a typo and should be fixed. Second, there are several thinkos: Whether you are using TA-sepapp11 or TA-sepapp12 you need to adjust the inputs.conf that you create from the supplied inputs.conf.local Adjust the following two stanzas: The monitor stanza for scm_system should have a sourcetype=scm_system The monitor stanza for agt_system should have a sourcetype=agt_system Both of these in the 1.0.3 version of the app point to just sourcetype=system so need to be adjusted to reflect the type of system logs they are (scm or agt). Third, there are empty dashboards as a result of missing fields. The view SEP Manager System... calls a macro `scm_trends` which calls others including `sep_scm_system_sourcetype` which references sourcetype=sepxx:scm_system If you inspect the props for scm_system, you will see the "csv_header_for_sep12_scm_system" transform that creates these fields: FIELDS = "site_name","sep12_server","domain_field","event description","dest_nt_host", "user_name","domain_name" The problem is, these fields don't seem to exists in SEP-12 scm_system data. Here is sample data: 2013-12-12 11:40:30,Info,Site: TestSEP01 FOO,Server: TestSEP01,No updates found for TruScan proactive threat scan commercial application list Win32 11.0. 2013-12-12 11:40:30,Info,Site: TestSEP01 FOO,Server: TestSEP01,No updates found for AP Portal List 12.1 RU2. 2013-12-12 11:40:30,Info,Site: TestSEP01 FOO,Server: TestSEP01,No updates found for SONAR scan engine Win32 11.0. Some of these can be fixed with good extractions, but unfortunately some of the fields presented in the dashboards don't seem to exist in the data. Looking at the sample above from scm_system and at the TA-sepapp12/default/props.conf you will see that there are references to extractions that use DELIM as comma "," only without a key-value delimiter. So, it takes the field that has "Site: TestSEP01" and makes that the value of sep12_server. There is no reason for the string "Site: " to be in your field name. To fix this, we have to override a default extraction. Create a local props.conf that looks like this: [sep12:scm_system] REPORT-1-csv_header_for_sep12_scm_system = extractions_for_sep12_scm_system` Create a local/transforms.conf that looks like this: [extractions_for_sep12_scm_system] REGEX = \,Site\:\s+(?<site_name>[^\,]+)\,Server\:\s+(?<sep12_server>[^\,]+)\,(?<event_description>.*)` Additionally, we need to make a small tweak to the macros, so edit SplunkforSymantec/local/macros.conf: [scm_trends] definition = \`sep_index\` \`sep_scm_system_sourcetype\` | fillnull value=NULL User| rename dest_nt_host as "Host" event_source as "Event Source" event_description as "Log Entry" | timechart count by "Log Entry" [scm_table] definition = \`sep_index\` \`sep_scm_system_sourcetype\` | fillnull value=NULL User | rename sep12_server as "Host" user_name as "User" event_description as "Log Entry" | table "Host" "User" "Log Entry" # Also, the following fixes the "Host With Multiple Infections" panel in "host_overview" View [host_overview_most_viruses_last_24hours] definition = `sep_index` `sep_risk_sourcetype` risk_type="Virus found" | rename actual_action as "Action" dest_nt_host as "Host" dest_ip as "Host IP" user as "User" risk_type as "Detection Type" signature as "Malware Name" | stats count by Host "Host IP" User | sort -count That should get those dashboards working (mostly). ... View more

Although the documentation located here http://apps.splunk.com/app/245 for the Splunk for Bluecoat app mentions you need only to modify the macro to point to where your Bluecoat data is (e.g. what index you have it in) there is another step you need to do that isn't documented. Unfortunately, the app does not use its own macros for the splash page, which is bcoat_overview and instead uses bare searches directly to a static location (index=bcoat_proxy). Until this app is updated to properly use the macro, you need to edit this dashboard's XML to fix the problem. To do this: From the Splunk for Bluecoat app, click on Manager on the top right portion of the screen Click User Interface Click Views Click bcoat_overview In the text-editor, search for index=bcoat_index and replace it with something like: `bcoat_request` (enclosed in back-ticks to signify a macro). Click Save Navigate back to the app, and the splash page should now work. ... View more

Update: Answering my own question here after talking to Support, PM and devs. What we are experiencing is part of a known bug: SPL-59578 that will be fixed in 4.3.6 and 5.0.3 This bug comes up when large amounts of summary data is returned. Support says that in the known cases, the data was not invalid, so excluding the binary section within the input would be sufficient to mitigating the problem You can tell Splunk to read this data and exclude the binary data by using the NO_BINARY_CHECK in your props.conf with something like this: [stash_new] NO_BINARY_CHECK = true One note, if this is particularly a problem with ES (Enterprise Security) then don't spend too much time with this issue and instead upgrade to ES-2.2.x or greater since from this version on, summary data is hardly used at all and won't be driving the majority of the dashboards like it does in previous versions. When I get onsite today, I will finish the upgrade to ES-2.2, then evaluate if any of the other apps/SH are still experiencing this issue. I might put the NO_BINARY_CHECK work-around in place since other apps were having this problem previously. ... View more

Thoree, If I understand your question correctly, you should be able to leave your individual index definitions unchanged. Best, Sean ... View more

Dwoltil, Here are two methods: You can put that specific element in "debug" mode to see more in your splunkd.log by following these instructions: http://docs.splunk.com/Documentation/Splunk/latest/Troubleshooting/Enabledebuglogging#Enable_debug_messages_from_the_CLI_.284.1.4_and_later_versions.29 Or you can do a search to see which events were 10,000 bytes big, for instance, try something like this in your search: index=* | eval size=len(_raw) | where size=10000 The search above should return the events that are 10000 bytes long or rather, the ones that will hit the default TRUNCATE limit. Instead of the equal sign after size, you can instead use the greater than or less than character if you prefer to fine tune what you are looking for. Best, Sean ... View more