You should just be able to add keepevicted=true to the transaction command options, then search on evicted=1 : ... | transaction keepevicted=true ... | where evicted=1 http://docs.splunk.com/Documentation/Splunk/5.0/SearchReference/Transaction ... View more

You do need to be aware of quoting rules depending on the shell you are using. For most Unix shells, you can surround with single quotes, and if your search string contains single quotes, you can escape those with a preceding backslash. The rules for Windows cmd.exe and PowerShell are rather more esoteric, but most of the time, you can surround the string with double quotes, even if the search string contains double quotes. Most of the time. ... View more

I'm keeping this: http://www.splunk.com/wiki/Deploying_Splunk_Light_Forwarders up to date as the recommended way to deploy. Please refer to that link, since as Splunk versions change and we develop new practices, I'll maintain the other link. Note the the below applies to 4.0. For 4.1, the script is valid, but the configuration file set required is smaller, as 4.1 does not set as much upon install, and therefore does not need as much to disable functionality. In particular, you will not need: etc\apps\search\local\inputs.conf etc\apps\search\local\savedsearches.conf etc\apps\SplunkLightForwarder\local\inputs.conf etc\apps\windows\local\inputs.conf etc\apps\windows\local\savedsearches.conf but you will still want to have: etc\apps\sample_app\local\app.conf etc\apps\SplunkLightForwarder\local\app.conf etc\apps\deploymentclient\local\deploymentclient.conf You can use any software distribution mechanism you have available. To install Light Forwarders on Windows, I recommending creating a Windows batch file install.cmd containing: setlocal IF "%PROCESSOR_ARCHITECTURE%" == "AMD64" goto b64 IF "%PROCESSOR_ARCHITEW6432%" == "AMD64" goto b64 :b32 set SPLUNK_MSI=%~dp0\splunk-4.0.9-74233-x86-release.msi REM set above to path to 32-bit version goto endb6432 :b64 set SPLUNK_MSI=%~dp0\splunk-4.0.9-74233-x64-release.msi REM set above to path to 64-bit version :endb6432 if not defined ProgramFilesW6432 ( set LOC=%ProgramFiles%\Splunk ) else ( set LOC=%ProgramFilesW6432%\Splunk ) rem the WINEVENLOG*CHECK settings don't do anything in 4.0. They're just carried over from 3.x where they make sure the inputs weren't enabled. msiexec.exe /i "%SPLUNK_MSI%" INSTALLDIR="%LOC%" LAUNCHSPLUNK=0 WINEVENTLOGAPPCHECK=0 WINEVENTLOGSYSCHECK=0 WINEVENTLOGSECCHECK=0 SPLUNK_APP="" /QUIET xcopy "%~dp0\etc" "%LOC%\etc" /s /f /y copy /y "%LOC%\etc\splunk-forwarder.license" "%LOC%\etc\splunk.license" pushd "%LOC%\bin\" splunk restart --accept-license --no-prompt --answer-yes popd endlocal Edit the Splunk MSI path information as appropriate, and place the MSI files in the same directory as this script. Finally, create a directory in the same folder called etc , and place all your initial Splunk configuration files there. To create a bare initial installation that does nothing, with all defaults inputs and scripts disabled, place the following files into the etc directory. Other configurations are possible with different sets of configuration files: etc\apps\sample_app\local\app.conf etc\apps\search\local\inputs.conf etc\apps\search\local\savedsearches.conf etc\apps\SplunkLightForwarder\local\app.conf etc\apps\SplunkLightForwarder\local\inputs.conf etc\apps\windows\local\inputs.conf etc\apps\windows\local\savedsearches.conf etc\apps\deploymentclient\local\deploymentclient.conf The files should contain: etc\apps\sample_app\local\app.conf: [install] state = disabled etc\apps\search\local\inputs.conf: [script://$SPLUNK_HOME\bin\scripts\splunk-wmi.py] disabled = true [script://$SPLUNK_HOME\bin\scripts\splunk-regmon.py] disabled = true etc\apps\search\local\savedsearches.conf: [Top five sourcetypes] enableSched = false [Indexing workload] enableSched = false etc\apps\SplunkLightForwarder\local\app.conf: [install] state = enabled etc\apps\SplunkLightForwarder\local\inputs.conf: [monitor://$SPLUNK_HOME\var\log\splunk] disabled = true etc\apps\windows\local\inputs.conf: [WinEventLog:Application] disabled = true [WinEventLog:Security] disabled = true [WinEventLog:System] disabled = true [script://$SPLUNK_HOME\bin\scripts\splunk-admon.py] disabled = true [monitor://$WINDIR\WindowsUpdate.log] disabled = true etc\apps\windows\local\savedsearches.conf: [CPU Utilization Summary] enableSched = 0 [CPU Utilization by Threshold] enableSched = 0 [Top Processes by Memory] enableSched = 0 [Top Processes by CPU] enableSched = 0 [Disk Utilization] enableSched = 0 [win_eventlog_count_sum_index] enableSched = 0 [performance_snapshot] enableSched = 0 and finally, etc\apps\deploymentclient\local\deploymentclient.conf is only necessary if you will be using the Splunk Deployment Server to manage the forwarder configurations. Unless you have another configuration management system, we recommend you use the Deployment Server to be able to make modifications to forwarder configurations from. However, any system which lets you push configurations files and restart a service can be used instead, e.g., on Linux systems, puppet has been a good and effective solution that can both install Splunk and manage the configuration. [deployment-client] [target-broker:deploymentServer] targetUri = mydeploymentserverhostname:8089 ... View more

The problem is not the number of search results with the tag, but the size of the search query. I'm assuming that you have items tagged pci . These essentially expand out into a long OR sequence of every field/value combination with that tag (and eventtypes are themselves expanded). So the search query is too large. I believe the upper limit is something on the order of a few hundred terms, but I don't know what it is or if it can be raised. ... View more

Actually now that I think about it: | stats count by _time,_raw | rename _raw as raw | where count > 1 might be better. But an ER for search command to showdupes might be best. ... View more

This won't work if the original data is multiline. But you could fix that with | rename duration as original_duration | transaction _time,_raw | search duration=* The transaction will also be rather more efficient if you set maxspan=0 and maxopentxn=1 if your duplicates will be consecutive. ... View more

Actually, if you logins to Splunk as opposed the searches submitted, you can also search: index=_audit action="login attempt" info=succeeded ... View more

@hulahoop, did you delete the vsid parameter in your own private savedsearches.conf, or only in the app one? ... View more

Splunk does not allow execution of programs outside of designated locations for security reasons. If it was allowed, any user who could create inputs could execute any code as the Splunk account. To control this, any code that a user can run must be explicitly placed in designated locations by someone who is authorized to do so. Allowing a special case for cmd.exe or powershell.exe would have the same security hole. Your workaround is perfectly valid, and is the intended one. ... View more

Unfortunately the events don't have newlines or CR between them, so we can't use them to find the breaks. What we're doing is a regex lookahead, which is supposed to basically match the following characters without actually including them as part of the match. ... View more

Seems like a bug to me. Might try >\s as a last resort. ... View more

Or just shorter: earliest=-14d@w0 latest=@w0 | timechart span=7d count by tag::eventtype ... View more

Oh, that's interesting...it's not in the online docs. I'll file a bug on that. In general, you can see docs for the modules in your own Splunk instance by going to http://localhost:8000/modules though. ... View more

Anotherway to avoid "wrapping" via BAT is to ensure that the scripts located in the bin directories are automatically associated with the appropriate script engine by the OS (or by Splunk). In Unix, the convention of using #!/path/to/shell does this. In Windows, .bat files are associated with the cmd.exe , and you can create new associations via FTYPE and ASSOC . In this case, you do not need to wrap your scripts inside of another script, and at the same time, users are limited to only running code that has been explicitly placed in the specified locations (and presumably vetted). ... View more

Well, I guess it depends what you mean by "logically equivalent", but there is a difference in meaning regardless of how Splunk treats them. ... View more

No they are not logically equivalent. There is a difference between being empty, and not existing. ... View more

Note that using field2!=* will not work either. This will never return any events, as it will always be false. This means that field2!=* and NOT field2=* are not entirely equivalent. In particular, in the case where field2 doesn't exist, the former is false, while the latter is true. ... View more

field2="" means something very different. It means that field2 exists, but has an empty string value. ... View more