locked
PowerShell 2/3-state Monitors not working for SharePoint RRS feed

  • Question

  • Hi,

    I am trying to create some PowerShell-based monitors in SCOM. Initially I thought it is a problem with health state, but when I used scom API to return the property bags, I saw it was actually working properly. So what I did is wrap the script into a try {} catch {} block and in the catch block I would set the value of a variable to $override =1. If it is 1, I would then return the message of the error.

    Then it hit me - SCOM is actually unable to load the SharePoint Snapin (asnp microsoft.sharepoint.powershell):

    (Microsoft.SharePoint.PowerShell.SPCmdletException: Cannot access the local farm. Verify that the local farm is properly configured, currently available, and that you have the appropriate permissions to access the database before trying again.
       at Microsoft.SharePoint.PowerShell.SPCmdlet.BeginProcessing())
    

    So that would mean that it is not executed by the agent locally, like I suspected, but in a remote PowerShell session!

    Does anybody know how is the SharePoint Management pack able to run checks, since it is not working as regular PowerShell script monitors?


    [SharePoint lurker]

    Wednesday, July 8, 2020 5:02 AM

All replies

  • Hello,

    Have you tried the Cookdown's Powershell authoring MP? https://cookdown.com/scom-essentials/powershell-authoring/

    Cheers


    Sam (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" wherever applicable. Thanks!) Blog:AnalyticOps Insights Twitter:Sameer Mhaisekar

    Wednesday, July 8, 2020 6:52 AM
  • Yes, that is how I got the PowerShell scripting option for monitors.

    [SharePoint lurker]

    Wednesday, July 8, 2020 8:26 AM
  • I also never managed to use the SharePoint module in scom scripted rules or monitors, but also never really took the time to troubleshoot it.

    However if you have a look at how it's done in the SharePoint MP, you'll see they actually load SharePoint dlls and use native C# methods instead of powershell cmdlets: https://systemcenter.wiki/?GetElement=Microsoft.SharePoint.2019.MonitorType.SPHARule&Type=UnitMonitorType&ManagementPack=Microsoft.SharePoint.2019.Monitoring&Version=16.0.11426.3000

    So I guess there is "something" preventing the use of the powershell module...

    Wednesday, July 8, 2020 8:44 AM
  • Hi,

    What permissions does your account have on the SharePoint servers?

    Does it have local administrator, and also SharePoint farm administrative privileges and access to the related databases and application programming interface (API)?

    Best regards,
    Leon


    Blog: https://thesystemcenterblog.com LinkedIn:

    Wednesday, July 8, 2020 8:47 AM
  • @Leon, yes permission are fine, as I can run it as the action account and I already inspected the property bags. It works there.

    @CyrAz, yes you are right. I wish there was an easy way to overcome it. If the script was executed on the agent, then it would not be a problem at all. However since it runs as a PSSession, it faces a double-hop scenario, which I cannot make work for WinRM. You would get the same if you ran a script, which opens a connection to a SQL server .open(). Ironically, if you set the machine 'Trust this computer for delegation to any service', opening a connection to SQL works. I did not test in my lab if it also works with SharePoint. But this option itself is impossible, since it brings such a high risk...


    [SharePoint lurker]

    Wednesday, July 8, 2020 9:17 AM
  • You might be jumping to conclusions a bit quickly here.

    I never heard that SCOM was running scripts in a pssession, however it does have its own powershell implementation.

    And SharePoint is the only powershell module I've ever had trouble with, and I've used a lot of them!

    Also the powershell probeaction module has a SnapIns parameter that I have never seen used but I would give it a try in this specific scenario. That would require a bit of manual modification to y our code though, as it's not natively supported in the cookdown powershell mp

    Wednesday, July 8, 2020 9:38 AM
  • You might be right, but in my frustration that was the only explanation I could see, since this error is easily seen when you do a PSSession to a SharePoint server, which uses a SQL server on a different node.

    Thanks for the hint!


    [SharePoint lurker]

    Wednesday, July 8, 2020 9:44 AM
  • That's an interesting deduction and I honestly don't know if a credential double hop could be an issue with scom scripted monitors...

    However I don't believe that this is the issue here, otherwise it would be present even with loading directly the assemblies as it's done in the native MP, wouldn't it?

    Wednesday, July 8, 2020 9:49 AM