I need to install the free powershell MP into SCOM 2007 environment and I get the below message. As you know SCOM 2007 doesn’t recognise .mpb files, so I extracted the mp as a xml file using MP Viewer.
‘This management pack cannot be imported. :XSD verification failed for management pack. [Line: 1, Position: 17]. The ‘SchemaVersion’ attribute is not declared.
More than just the file format changed between 2007 and 2012 - significant parts of the MP schema did as well. 2012 is backwards compatible with the previous version, and automatically upgrades any imported MP (try importing an unsealed MP into 2012, exporting it again and trying to import it into 2007!).
That said, the MP sourcecode is available on Github so you can always download a copy, modify the MpFrameworkVersion to your appropriate version of SCOM 2007 (6.1 should do the trick), and then locate 2007 copies of the referenced management packs (likely found on the SCOM 2007 installation media, if you still have that available). You’ll need a copy of VSAE to do this though, and some MP authoring knowledge.
As noted on the github project though the MP wasn’t tested with SCOM 2007, so after all that, it may not actually work anyway, if any of the referenced template wizards were modified between 2007 and 2012.
I may have to move away from using the Free Powershell MP temporarily until I can get SCOM upgraded to 2012 R2 at least. Until that happens I am stuck with SCOM 2007. It will be really helpful to me if someone can re-code the below script into VB Script.
$ScomAPI = New-Object -comObject “MOM.ScriptAPI”
$propertybag = “”
$PropertyBag = $ScomAPI.CreatePropertyBag()
$errorhash = “”
$errorhash = Invoke-Sqlcmd -Query “select top 1 * from [dbo].[ACTIVITY_TRACE] where Status = ‘failed’ order by ID desc” -ServerInstance “SCOMServer” -Database “PDS”
if ($errorhash -ne “”)
{
$PropertyBag.AddValue(“State”,”Error”)
$PropertyBag.AddValue(“MessageText”,$errorhash)
}
else{
$PropertyBag.AddValue(“State”,”Ok”)
}
$PropertyBag
Just a comment on that SQL query - if the target DB doesn’t clear down entries in that table (Activity_Trace) when a non failed entry is written (or removes them using some other mechanism), once a row is written with a failed status that script would cause a monitor to go critical permanently, even if the failed entry is not the most recent one.