locked
SCOM 2016: SQL Management Pack: Failed to run the PowerShell script due to exception below, this workflow will be unloaded. RRS feed

  • Question

  • I am repeatedly getting the following error (same for a number of scripts) across all monitored SQL servers, the run as accounts have administrative rights to the affected machines (only for the time being), search foo has failed to reveal any likely resolutions so any suggestions would be very helpful at this point.

    Failed to run the PowerShell script due to exception below, this workflow will be unloaded.

    System.ObjectDisposedException: Cannot access a closed file.
    at System.IO.__Error.FileNotOpen()
    at System.IO.FileStream.Flush(Boolean flushToDisk)
    at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)
    at System.Management.Automation.Host.TranscriptionOption.Dispose()
    at System.Management.Automation.Host.PSHostUserInterface.StopAllTranscribing()
    at System.Management.Automation.Runspaces.LocalRunspace.DoCloseHelper()
    at System.Management.Automation.Runspaces.RunspaceBase.CoreClose(Boolean syncCall)
    at System.Management.Automation.Runspaces.LocalRunspace.Close()
    at System.Management.Automation.Runspaces.LocalRunspace.Dispose(Boolean disposing)
    at Microsoft.EnterpriseManagement.Common.PowerShell.RunspaceController.Dispose(Boolean disposing)
    at Microsoft.EnterpriseManagement.Common.PowerShell.RunspaceController.Dispose()
    at Microsoft.EnterpriseManagement.Common.PowerShell.RunspaceManager.CloseRunspace(RunspaceController runspace)
    at Microsoft.EnterpriseManagement.Modules.PowerShell.PowerShellProbeActionModule.RunScript(RunspaceController runspaceController)
    at Microsoft.EnterpriseManagement.Modules.PowerShell.PowerShellProbeActionModule.RunspaceAvailable(RunspaceController runspaceController)
    at Microsoft.EnterpriseManagement.Common.PowerShell.RunspaceManager.DeliverRunspaceThreadProc(Object appDomainObject)


    Script Name: StolenServerMemory2016.ps1

    One or more workflows were affected by this.


    Workflow name: Microsoft.SQLServer.2016.DBEngine.StolenServerMemoryMonitor

    Instance name: MSSQLSERVER

    Instance ID: {C84A9E35-9EAC-3961-A558-9F63B058B8CD}

    Management group: My Management Group

    Additional scripts with this error

    Script Name: GetHKPoolMemoryConsumption.ps1
    Script Name: ActiveConnectionsDataSource.ps1

    Thursday, December 7, 2017 3:46 PM

All replies

  • Hello,

    >>cannot access a closed file

    I haven't ever heard above error message in SCOM. I suggest you start from checking runas profile "SQL Server Monitoring Account".

    Please make sure there is specified some run as account that has the right permissions on the SQL database.

    Also, this run as account that is specified in the run as profile, should have the credentials distributed to the SQL servers that you are trying to monitor.

    Regards,

    Yan 


    Please remember to mark the replies as answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, December 8, 2017 2:21 AM
  • Hi

    The run as accounts for each set are both system administrators and members of the SQL sysadmins role, I don't intend to leave it like this but wanted to rule out permissions issues, the accounts are distributed to the target machines. I probably should have mentioned that before :)

    Also it only seems to be these 3 scripts that fail, all other monitoring using the same run as accounts is ok.

    Regards

    Sam

    Friday, December 8, 2017 9:17 AM
  • I do also get the same error for a couple of SharePoint servers

    Failed to run the PowerShell script due to exception below, this workflow will be unloaded.

    System.ObjectDisposedException: Cannot access a closed file.
    at System.IO.FileStream.Flush(Boolean flushToDisk)
    at System.Management.Automation.Host.TranscriptionOption.Dispose()
    at System.Management.Automation.Host.PSHostUserInterface.StopAllTranscribing()
    at System.Management.Automation.Runspaces.LocalRunspace.DoCloseHelper()
    at System.Management.Automation.Runspaces.RunspaceBase.CoreClose(Boolean syncCall)
    at System.Management.Automation.Runspaces.LocalRunspace.Close()
    at System.Management.Automation.Runspaces.LocalRunspace.Dispose(Boolean disposing)
    at Microsoft.EnterpriseManagement.Common.PowerShell.RunspaceController.Dispose(Boolean disposing)
    at Microsoft.EnterpriseManagement.Common.PowerShell.RunspaceController.Dispose()
    at Microsoft.EnterpriseManagement.Common.PowerShell.RunspaceManager.CloseRunspace(RunspaceController runspace)
    at Microsoft.EnterpriseManagement.Modules.PowerShell.PowerShellProbeActionModule.RunScript(RunspaceController runspaceController)
    at Microsoft.EnterpriseManagement.Modules.PowerShell.PowerShellProbeActionModule.RunspaceAvailable(RunspaceController runspaceController)
    at Microsoft.EnterpriseManagement.Common.PowerShell.RunspaceManager.DeliverRunspaceThreadProc(Object appDomainObject)


    Script Name: CheckMaxConcurrentAPI.ps1


    One or more workflows were affected by this.


    Workflow name: Microsoft.Windows.Server.2012.MaxConcurrentAPI.Monitor

    Instance name: Microsoft Windows Server 2012 R2 Standard

    Instance ID: {656AF493-FF46-D875-E3A2-FDD98229D564}

    Management group: My Management Group


    • Edited by Sam H------ Friday, December 8, 2017 10:58 AM
    Friday, December 8, 2017 10:57 AM
  • Hi,

    Please see if this helps.

    Windows Server 2012 Max Concurrent API Monitor Monitor

    OpsMgr warning: Power Shell script was dropped (solved)

    Final solution, disable the rules causing the issue.

    Cheers


    Sam (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" wherever applicable. Thanks!)

    Friday, December 8, 2017 2:16 PM
  • Hi Sam,

    any update on this one? Did you manage to resolve the issue? Thnaks for sharing. 

    Regards,


    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" where applicable. This helps the community, keeps the forums tidy, and recognizes useful contributions. Thanks!) Blog: https://blog.pohn.ch/ Twitter: @StoyanChalakov

    Wednesday, May 16, 2018 1:28 PM