I can't for the life of me get powershell input to work correctly.
I realize this is asked a lot but I'm not able to find a working answer for Splunk 7 after quite a lot of searching.
I have the powershell, windows infrastructure, and AD add-on's installed. Splunk running on server 2016 with system account.
Input in apps\Splunk_TA_windows\local
[powershell://win32share]
script = gwmi Win32_Share | where Type -eq 0 | select name,path,status | Select-Object *,@{n="SplunkHost";e={$Env:SPLUNK_SERVER_NAME}}
sourcetype = Windows:Process
schedule = 0 */5 * * *
This worked once after which I could not get it to work again. I even changed the name, tried changing index and source type, etc.
The reason I changed it was to put this into a script as I'm trying to rebuild the file share monitoring from old Splunk blog posts.
The script input was
[powershell://win32_share]
script = . "$SplunkHome\etc\apps\Splunk_TA_windows\bin\win32_share.ps1"
index = windows
source = Powershell
sourcetype = Windows:Share
schedule = 0 */5 * * *
Test script of
gwmi Win32_Share | where Type -eq 0 | Select-Object name,path,status
I'm having a real hard time finding where to look to see if the command / script are even attempted. I've tried reading splunkd, powershell log, and searching internal.
Also, does the source type need to be pre-defined or can it be anything I want?
PS new to Splunk but this has been the only hurdle so far.
Any help is greatly appreciated.
I've found that from Splunk v6.6+, PowerShell script scheduling is broken (i.e. it runs extremely sporadically, if at all) - there appears to be an issue with sending signals from $SPLUNK_HOME/bin/splunk-powershell.exe to $SPLUNK_HOME/bin/splunk-powershell-common.ps1 - specifically the WaitForWinMultipleObjects statement in the waitCronEvents function just isn't getting anything meaningful to respond to.
I've raised the issue with Splunk and am awaiting a resolution.
Short term work-arounds - I've found two (both work for Splunk v6.6, not tested under 7.0.x)
This should now be fixed in v6.6.6.
Initial testing with this version indicates that PowerShell scripts are being run on schedule again.