It would be nice to have an answer from Microsoft on this one, and not MVPs and other users. I've considered a lot of reasons why the agent is not running powershell scripts, and the only conclusion is the following: the agent is already heavy on resource-usage. Especially on heavy loaded servers, Microsoft cannot risk adding the extra load that Powershell brings over wscript.exe?

You are responding yourself i think :)Regards, Samir Farhat Infrastructure Consultant

I think this one is pretty clear cut. VBScripts are supported natively by the Operating System while PowerShell isn't, it requires to be installed on older systems (Windows Server 2000,2003, 2008 as a feature). Come 10-20 years the older Operating Systems will be few and far between and PowerShell will be very prevalent.

A couple reasons: - Powershell did not ship as a default part of Windows Server until Server 2008 R2. VBScript has been shipped with the OS way longer than that, so to maximize compatibility, many critical monitoring scripts are done in VB. As of SCOM 2007 R2 we don't even require the .NET framework on agents, let alone facy stuff like powershell. Good luck convincing all of our Server 2000/2003 customers to go install powershell 2.0 everywhere... - The Operations Manager product line predates powershell, so some monitoring scripts were initially developed before powershell even existed. SCOM 2007 released less than a year after powershell 1.0 debuted. Most newer scripts in SCOM 2012 ARE in powershell, aside from some exceptions according to above. Load is definitely NOT a reason. In fact, it is LESS resource-intensive to run a powershell script through SCOM than a VB script. To run a VB script, we need to start the cscript or wscript process and point it to the location on disk where the script lives. There is no way to host the VB runtime ourselves. Every script that is run requires a whole new process. We CAN, however, host the powershell runtime ourselves, and we do. To run a powershell script (via our dedicated psh module), we simply feed it as a string into the runtime and then grab the result of execution. No new process is required, since we host the runtime within MonitoringHost.exe ourselves. Multiple powershell scripts can be executed in parallel within a single process. Compared to the overhead of starting a process per script, hosting and invoking the psh runtime is very lightweight. Thanks, -Lincoln

A couple reasons: - Powershell did not ship as a default part of Windows Server until Server 2008 R2. VBScript has been shipped with the OS way longer than that, so to maximize compatibility, many critical monitoring scripts are done in VB. As of SCOM 2007 R2 we don't even require the .NET framework on agents, let alone facy stuff like powershell. Good luck convincing all of our Server 2000/2003 customers to go install powershell 2.0 everywhere... - The Operations Manager product line predates powershell, so some monitoring scripts were initially developed before powershell even existed. SCOM 2007 released less than a year after powershell 1.0 debuted. Most newer scripts in SCOM 2012 ARE in powershell, aside from some exceptions according to above. Load is definitely NOT a reason. In fact, it is LESS resource-intensive to run a powershell script through SCOM than a VB script. To run a VB script, we need to start the cscript or wscript process and point it to the location on disk where the script lives. There is no way to host the VB runtime ourselves. Every script that is run requires a whole new process. We CAN, however, host the powershell runtime ourselves, and we do. To run a powershell script (via our dedicated psh module), we simply feed it as a string into the runtime and then grab the result of execution. No new process is required, since we host the runtime within MonitoringHost.exe ourselves. Multiple powershell scripts can be executed in parallel within a single process. Compared to the overhead of starting a process per script, hosting and invoking the psh runtime is very lightweight. Thanks, -Lincoln That is valuable information Lincoln, thanks for sharing!

A couple reasons: - Powershell did not ship as a default part of Windows Server until Server 2008 R2. VBScript has been shipped with the OS way longer than that, so to maximize compatibility, many critical monitoring scripts are done in VB. As of SCOM 2007 R2 we don't even require the .NET framework on agents, let alone facy stuff like powershell. Good luck convincing all of our Server 2000/2003 customers to go install powershell 2.0 everywhere... - The Operations Manager product line predates powershell, so some monitoring scripts were initially developed before powershell even existed. SCOM 2007 released less than a year after powershell 1.0 debuted. Most newer scripts in SCOM 2012 ARE in powershell, aside from some exceptions according to above. Load is definitely NOT a reason. In fact, it is LESS resource-intensive to run a powershell script through SCOM than a VB script. To run a VB script, we need to start the cscript or wscript process and point it to the location on disk where the script lives. There is no way to host the VB runtime ourselves. Every script that is run requires a whole new process. We CAN, however, host the powershell runtime ourselves, and we do. To run a powershell script (via our dedicated psh module), we simply feed it as a string into the runtime and then grab the result of execution. No new process is required, since we host the runtime within MonitoringHost.exe ourselves. Multiple powershell scripts can be executed in parallel within a single process. Compared to the overhead of starting a process per script, hosting and invoking the psh runtime is very lightweight. Thanks, -Lincoln

Hi, Regarding monitoring with PowerShell script, I would like to share the following with you for your reference: How to create a monitor based on a Windows PowerShell script http://technet.microsoft.com/en-us/library/ff381420.aspx How Do I: Create a rule and monitor using a Windows PowerShell script in a System Center Operations Manager Management Pack? http://technet.microsoft.com/en-us/systemcenter/Video/ff770155 Running PowerShell Scripts from a Management Pack - Part 1 http://blogs.technet.com/b/brianwren/archive/2008/02/20/running-powershell-scripts-from-a-management-pack.aspx Hope this can give you some hints. Thanks. Nicholas Li - MSFT Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.