Megosztás a következőn keresztül:

Sealing a Management Pack

  • Cikk

We have a had a variety of comments about our lack of guidance on using MPSeal to seal a management pack.  I admit that we had pretty sparse information out there so the negative comments were well justified.  I just put up a new topic that should fill in the missing information.

https://technet.microsoft.com/en-us/library/hh219340.aspx

Comments

  • Anonymous
    April 23, 2012
    Is there a newer version of the mpsign tool than that which comes with the 6.0.6276.0 authoring resource kit? That one is giving me weird and buggy behaviour.

  • Anonymous
    April 23, 2012
    There is a new version (7.0.8560.0) in the SupportTools folder of the Operations Manager 2012 media.  But can you define "weird and buggy behavior"?

  • Anonymous
    April 24, 2012
    (odd - retyping as my reply vanished) The issue is the one discussed here - social.technet.microsoft.com/.../bd4fd074-3157-48ca-b37c-955f1a824d54 There is nothing sensitive in this pack, so I could send you a copy to play with if you want to reproduce the issue?

  • Anonymous
    April 24, 2012
    Is there any way I can get just the MPSEAL exe from that without having to obtain the 2012 media?

  • Anonymous
    April 24, 2012
    Well I see what you mean about a post not getting out there because I just wrote a pretty lengthy one and had it not show up.  Trying this again with a copy and paste from Word. The CData issue shouldn’t be related to MPSeal.  That’s a matter of the way that the XML is stored within the management group.  The conversion to the & formatting occurs on install so that when you export the management pack, that’s the format that you’re going to get.  It’s a completely valid format, although I admit that it’s tricky to edit. I’m wondering what the scenario is that you’re encountering this though.  You should only see this conversion if you export the MP from the management group and then try to edit it.  I’m not sure why you would do that as opposed to just editing the source in the Authoring Console to begin with.  I could see if you were creating the MP in the Operations Console and then exporting it in order to seal it, but we typically don’t seal MPs that are created in the Operations Console.  And once they are sealed, then they can’t be edited anyway.  So I’m just wondering what the basic scenario is where you’re running into this. The ultimate answer is going to be to move to the Visual Studio Authoring Extensions when it comes available (which will hopefully be very soon).  This tool follows our new approach of separating the source from the final XML.  You will be able to maintain the script as its own file and not even worry about the CData.  It’s still going to converted to the & format when you build the mp file, but since you’re editing the source, you really won’t care.

  • Anonymous
    April 25, 2012
    (again, gone, retrying from the copy I took :) Context is that I am authoring a management pack, from scratch, which uses a fair bit of scripting for discovery and intermittently I get back VBS compilation errors from the target RMS where the script is running. On examination of the output script (post substitution) I can see many of the "protected" characters (such as < > & etc) are replaced with html entities. On the basis of divide and conquer, I checked the XML first and found that the problem script was not CDATA'd but was already stored as entities. copying the script from the gui into the XML (with CDATA wrap) resolved this in all early cases. Moving forward, I was following this as a procedure whenever I encountered the problem (provided I didn't try to edit the script content with the authoring console, it stayed intact) until one day I met a stubborn one - the CDATA tags were clearly still in the XML, but the output MP file gave the error. again using D&C, I checked the MP by reversing the process using the usual PS1 file that reads like this: param($mpFilePath,$outputDirectory) $assembly = [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.OperationsManager") $mp = new-object Microsoft.EnterpriseManagement.Configuration.ManagementPack($mpFilePath) $mpWriter = new-object Microsoft.EnterpriseManagement.Configuration.IO.ManagementPackXmlWriter($outputDirectory) $mpWriter.WriteManagementPack($mp) And found that that contained the entities (and no CDATA tags) despite the original not doing so. Suspecting the authoring console was silently converting prior to sealing, I used the mpseal exe to seal, with the same effect. As other scripts were still working and I wanted to proceed, I took a safe copy of my work (for later analysis), removed the monitoring script, and went forward with adding more objects to the pack and their associated discoveries/monitors. I then later re-added the script and this later return was accepted by the authoring console and sealer without comment, and is now working. I am somewhat at a loss to explain it too, but this sort of thing does make a rapid write-test cycle more difficult.