PowerShell version 2

By now, you are probably aware that I love PowerShell as a method of getting things on Windows. It’s your one stop method for getting all sorts of nice things. However, our SA-ModularInput-PowerShell module had certain limitations. Most notably, it could only work with .NET 4.5 and CLR4 – aka PowerShell v3. This was great for your one-off scripts where you weren’t adding in any plug-ins. In particular, Microsoft applications such as SharePoint 2010 and Exchange 2007 require PowerShell v2 support because their plug-ins are distributed for .NET Framework 3.5.

I’m happy to announce that one of our PowerShell MVPs – Joel Bennett – has updated the Splunk Addon for Microsoft PowerShell to support .NET 3.5 and CLR 2.

There are a couple of common gotchas. The first is in handling PowerShell snap-ins using the Add-PsSnapIn cmdlet. If the cmdlet is run twice in a row, then an error occurs. The problem is that our resident PowerShell host continually runs. The major performance increase obtained between the SA-ModularInput-PowerShell and a standard scripted input is that you aren’t spinning up a PowerShell executable every time – it’s always running. That also means that any snapin that you load is perpetually in memory.

You can ignore errors by utilizing the -ErrorAction parameter, like this:

Add-PsSnapIn Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue

The second problem that is common is that you actually need to use Select-Object at the end to ensure that the modular input knows what to log and what not to log. There are a lot of properties and methods on a typical PowerShell object and most of them are ignored. For example, check out this simple usage:

[powershell2://test-service-health]
script = Get-Service | Select-Object Name, DisplayName, Status
schedule = 0 0/5 * ? * *

In this input, we are grabbing the services that are running on the local machine. However, if we don’t select the properties we want, the call will fail because one of the properties is a ServiceHandle, which is not available and we get an error instead. Rule of Thumb is to always end your pipeline with a Select-Object to get the things you are interested in.

My final advice is on errors. We now have two PowerShell hosts, each with different requirements. When installed on a standard Windows Server 2008R2 host with no updates, only PowerShell2.exe will be running because the .NET Framework 4.5 is not available. You will see errors in the splunkd.log pertaining to the inability to start the PowerShell.exe. In a similar manner, when installed on a standard Windows Server 2012 host, only PowerShell.exe will be running because the .NET Framework 3.5 is not available. All our logs are available in the _internal index, so you can do a search for “index=_internal powershell” to find all the problems with PowerShell scripts.

Finally, check out my other posts on using PowerShell!