System Center Service Manager / Operations Manager Management Pack and Naming Convention Best Practices

Every engagement I do, I end up discussing management pack best practice.  In Operations Manager it is a simpler answer, but in Service Manager, it can become a philosophical discussion with different answers and possibilities, often each with valid justifications, so this blog post outlines some of the approaches, guidelines and pros and cons.  Think of this as System Center Management Pack 101  

Please feel free to add to the comments below with your thoughts / agreements / disagreements or if some of these best practices worked / didn’t work for you, and why, as some of this is debatable.  This is simply my take on the whole thing

Summary

Detail for all these points is provided below, but here is the quick summary of the key points.

BOTH Service Manager (SCSM) and Operations Manager (SCOM)

• A .MP file is a sealed MP, A .XML  file is an unsealed MP, A .MPB file is an MP Bundle
• A sealed MP cannot be modified.
• In order to customize an MP, it is necessary to make your configuration change in an unsealed MP, and the sealed MP you are customizing will be referenced in the unsealed MP.
• When a sealed MP is referenced from an unsealed MP, it makes the sealed MP dependent on that unsealed MP, such that the sealed MP cannot be removed unless the dependency is removed.
• Once a reference is created in an unsealed MP, the reference needs to be manually removed.  Removing the last override or element using that reference will not automatically remove the reference.
• Sealed / Unsealed architecture allows for more predictability with upgrading MP versions, preserving customizations stored in unsealed MPs.
• Always add a prefix such as 'Contoso' to your custom Management Pack names.
• Make names of elements with management packs as meaningful and as detailed as possible
• Use the description field for documentation.
• You cannot reference one unsealed MP from another unsealed MP. Therefore if you want to customize an unsealed MP, you either have to keep it all (original configuration and customization) within the one MP, or seal the MP that you are customizing and then you will be able to reference and make changes to it from an unsealed MP.
• Deleting an MP will delete the data in SCOM / SCSM that it defines.  For instance deleting the SQL 2008 MP from SCOM will delete all SQL 2008 databases that are being monitored from SCOM.  Deleting an MP defining a custom class in SCSM (a customized incident class for example) will remove all instances of that customized class.

SCOM

• A management pack configuration change in SCOM (disabling / enabling / tuning) is called an override.
• An Override is purely the configuration change.  It is not a modified copy of the rule / monitor you are changing.
• Best practice is to create One Unsealed MP per Sealed MP, for storing customizations in.
• Do not store anything in the Default Management Pack
• Consider renaming the default management pack to 'DO NOT USE - Default Management Pack'
• The Authoring>Overrides view shows all overrides configured in the management group
• Overrides can be moved using the uncheck, apply, re-create technique.

 SCSM

• Do not store anything in the unsealed management packs that are provided out of the box (such as 'Service Manager Incident Management Configuration Library'
• Create a custom MP Per class e.g. Contoso Incident Custom MP for storing all your class-related (Incident) customizations in.
• Store customizations to a list in an MP created specifically for that list customization
• Upon initial modification of a list, you will be asked where to store the customization once, and all future modifications to that same list will be stored in that initial selection without future prompts.
• Avoid Renaming list values - better to delete OOB values and create new customized ones.
• For Custom Scenarios requiring class extensions such as a New Hire Provisioning Service Request, use the same best practice of having a Contoso Custom New Hire Provisioning SR MP where you store all your templates and elements referencing that class.
• Management Packs containing class customizations must be sealed in order for those customizations to be available in the data warehouse.
• Use acronyms such as RA / IR / SR in the template name when creating templates.
• Management Packs can be sealed from the Service Manager Authoring Tool

SCOM Management Pack Best Practice    
First things first, to normally give the best explanation possible of management pack architecture, I start with my old friend SCOM (System Center Operations Manager), because it’s no secret that SCSM uses much of the same architecture and engine as SCOM.  If you have a good understanding of SCOM sealed and unsealed management packs, overrides, and the best practices for managing these in SCOM, you may want to skip this section.

Ok lets start real basic – what is a management pack?

A SCOM management pack is a .xml file (or a .mp file if it has the certificate applied to it) that defines monitoring objects such as rules, monitors and other elements such as groups, views etc.

SCOM Monitoring Management Packs that you download from Microsoft.com like AD / Exchange / SQL are all sealed management packs (with a .mp extension).  This means that you cannot change their contents in any way.  For instance if you try changing a view stored in a sealed MP, you will not be able to do so.  You will also be unable to change a rule (alert monitoring rule for example) in the sealed MP. 

Therefore, the only way you can customize a rule or a monitor such as whether it is enabled or disabled, or a threshold for example, is by creating an override (important to think of this as just a configuration change / setting, NOT a customized copy of the rule) in an Unsealed Custom MP (which has a .xml extension).

Therefore, our recommended best practice is that for each sealed MP (let’s say you have SQL, AD and Exchange), you have an unsealed MP.  So if you have the SQL, AD and Exchange Sealed MPs, you would also have a Contoso SQL Custom MP, Contoso AD Custom MP and Contoso Exchange Custom MP where you store your customizations.   If you want to enable / disable / change the threshold of a rule in the sealed SQL MP, you store the override (configuration change)  in the Contoso SQL Custom MP.

The reason for this best practice is that when you create an override, you create a dependency between the sealed MP and the unsealed MP.  So let’s say you didn’t know this best practice and had stored all your overrides (for SQL, AD, Exchange etc.) in a single ‘Contoso Customizations MP’.  If you then tried to remove one of those sealed MPs (let’s say SQL for example) from the SCOM console, it will prevent you from doing so, as it will say that you have dependencies in your Contoso Customizations MP.  In order to resolve this, you would need to remove all the SQL overrides from the Contoso Customizations MP, before you can remove the sealed SQL MP.  Another way of resolving it, would be to delete the Contoso Customizations MP, but then of course you would lose your Exchange / AD Customizations if they were all stored in that same single management pack.
  
If you have followed best practice and have all your SQL overrides in your Contoso SQL Custom MP, that means if you ever needed to remove the sealed SQL MP, then the only dependent unsealed MP you need to remove first (that will have all dependent overrides) is the Contoso SQL Custom MP, and you don’t have to go anywhere near any other management pack. 

There is a somewhat debatable point here, in terms of how granular you should get with your unsealed MPs.  For instance you may have the SQL 2008 monitoring and SQL 2012 monitoring Management packs deployed.  And then the question may arise of whether you should have a ‘Contoso Custom SQL 2008 MP’ (for storing SQL 2008 overrides) and then a separate ‘Contoso Custom SQL 2012 MP’ (for storing SQL 2012 Overrides), or is it ok just to have a ‘global’ Contoso Custom SQL MP for storing all SQL Overrides.  Best practice would dictate you be as granular as possible, and that you do have one unsealed MP per sealed MP (so have separate Contoso ones for SQL 2008 and SQL 2012).  The advantage of this, is lets say you decommission all SQL 2008 machines and no longer need the sealed SQL 2008 MP.  If all your SQL 2008 overrides are in Contoso Custom SQL 2008 MP, you will be able to remove the Contoso custom SQL 2008 MP, and then the sealed SQL 2008 MP because all the dependencies were in the Contoso custom SQL 2008 MP.  If all your overrides are in a generic Contoso SQL Custom MP, you would have to clear up just the SQL 2008 overrides / references in that MP, before the sealed SQL 2008 MP can be removed. 

Most customers I work with, tend to have one unsealed MP per product / technology (a Contoso Custom SQL MP) and find this manageable in terms of the dependencies it creates.  However, for true perfect best practice and to reduce the risk of creating dependencies that may cause issues down the line, I would recommend being as granular as possible.

For those of you that have heard the golden rule of not storing anything in the ‘Default management pack’, hopefully the above explanation provides insight into why this is the case.   It is even good practice to change the display name of ‘Default Management Pack’ to ‘DO NOT USE – Default Management Pack’ which adds an extra safeguard, making it less likely for users to store elements in the default management pack.  You can do this in the management pack properties and it won’t break anything as you are just changing a display name.

The Authoring>Overrides view in SCOM shows all the overrides configured in the management group: 

It can be useful to right-click and personalize the view, then group the view by ‘override management pack’, and then ‘override target management pack’, in order to make the view more useful and display overrides as shown above.   This is how you set this up in the personalize view dialog:

If you have accidentally stored an override in an undesired MP, the easiest way to move an override is as follows:

1) Open it by either double clicking the override from the authoring>overrides view, or accessing it from the overrides summary which is available when right clicking a rule / monitor

2) Note what the override is set to (by looking at the checkbox on the left that corresponds to the overridden parameter.)  For example here you can see the alert severity for this monitor is overridden from generating a critical alert to generating an informational alert:

3) Uncheck the ‘Override’ check box.

4) Click apply and this will make the ‘Select destination management pack’ option available

5) Select the desired management pack

6) Re-enable the override and click apply with the desired destination MP selected.  

You would be forgiven for expecting that deleting all the overrides or moving them to another management pack would  clear all dependencies between the sealed MP and the unsealed MP.  However, this is not quite the case. 

The following example shows how references to Sealed Management Packs are stored in Unsealed management packs, and how their aliases are used in overrides, lower down in the Management Pack XML.  For example if an override enabling a SQL 2005 rule was accidentally created in the default management pack, we would see the following in the default management pack’s XML:
 
 

 

 
In the above example, if we attempted to delete the SQL Server 2005 Monitoring MP, we would receive an error message, notifying us that the dependent default management pack contains a reference to the sealed SQL 2005 MP, thus preventing its removal.
 
To remove this dependency, it is necessary to

1. Delete any dependencies that you can in the Operations console, by deleting / moving / re-creating overrides / views etc.
2. export the default MP, make a backup copy of it (in a separate folder – don’t rename as the filename needs to be the same as the ID),   NOTE: Before modifying the xml of any management pack, it is recommended to make a backup of the unsealed management pack. 
3. Search for the alias (in the above example SQLServer1) in the rest of the MP to ensure the reference is not been used anywhere in the MP before you delete it
4. Assuming you confirmed it is not used anywhere else in the MP, delete the reference,
5. delete the MP containing the reference from the Operations Manager Console,
6. Re-import the default MP without the Unsealed MP reference     
7. After this cleanup is complete, it would be possible to remove the Sealed SQL 2005 MP.     

So knowing all this, the golden rule in SCOM is please, please, please do not store anything (including overrides) in the default management pack (unsealed MP provided out of the box). 

Why do we have this whole unsealed / sealed architecture?

Believe it or not, there is a GREAT reason why we have this architecture.  Let me take you back to MOM 2005 days   In MOM 2005 when you imported an update to a management pack, it was always somewhat uncertain what would happen to your customizations, after choosing any of the options here: 

So much so, that back in the day we would recommend customers create a copy of the MP, disable everything in the original MP, and then perform all customizations on the enabled (copied) version.

Therefore, the sealed / unsealed architecture was introduced in SCOM 2007, and this architecture still exists today in System Center 2012.  Lets say Microsoft releases an update of the (sealed) SQL MP, and then you import this updated (sealed) version.  All your SQL customizations (overrides) are sitting in an unsealed MP and will therefore be untouched / preserved by the sealed SQL MP upgrade (which really is more of a replacement than an upgrade ).  Any rules / monitors that are carried over from the old sealed MP into the new sealed MP keep the same IDs, such that your overrides (customizations) that already map to an ID, continue to map to the same appropriate ID.   If you have overrides configured against rules / monitors that are removed in the new version of the sealed MP, then these overrides just become orphaned, not breaking any functionality.

System Center Service Manager

Ok, lets switch gears from my old friend SCOM to my new best friend in the System Center suite - Service Manager .  

A SCSM management pack is a .xml file (or a .mp file if it has the certificate applied to it) that defines objects such as classes, views, templates and other elements within Service Manager.

Like the golden rule in SCOM is not to store anything in the default management pack, the golden rule of SCSM should be not to store anything in the unsealed Management Packs that are provided out of the box (such as ‘Service Manager Incident Management Configuration Library’).

Be mindful that when you choose a class in the console (for instance when you create an incident template) it will default to one of the OOB Unsealed MPs like this:
    
        

So like with SCOM where the best practice is one unsealed MP per sealed MP,  SCSM is suggesting you store anything relating to the ‘incident’ class (defined in a sealed MP ‘Incident Management Library’) in an OOB unsealed MP called ‘Service Manager Incident Management Configuration Library’.  PLEASE DON’T DO THIS   Relating this back to SCOM MP best practice and the golden rule of not storing anything in the default management pack, think of these OOB class-specific MPs as class-specific default management packs  

Instead, create a new custom MP per class.  So in this case create a Contoso Incident Custom MP, and then store your customizations referring to that specific class (such as incident templates) in there.

The ‘Service Manager Incident Management Configuration Library’ MP contains:

• Support Group Values
• Classification Category Values
• Resolution Category Values
• Incident Folder and Views
• Incident Notification templates (Affected User / Assigned to User)

I have seen issues (specifically where customizations are stored in OOB unsealed MPs like this one) that these customizations get lost following an upgrade.  That’s because the upgrade has no way of verifying whether the contents of the MP at time of upgrade are OOB or custom additions.  We just see it as an unsealed MP and replace it with our newer version. So this is the reason why it is best to store your customizations in your own custom created unsealed MP, and not one of the OOB unsealed MPs.   

So the the next question is should all my incident related customizations go in my Contoso Incident Custom MP or should I split this up along the lines of

• Contoso Incident Support Group List MP
• Contoso Incident View MP
• Contoso Incident Queues MP
• Contoso Incident Notification Templates MP

This is where it can get debatable   I recommend following the general guideline of having one unsealed MP per class that you create customizations for, and then anytime you select that class (like you select the incident class when you create an incident template), store the customization in your Contoso Incident Custom MP for example.

The one exception to this rule is Lists.   As you can see here, most of our Incident related lists (the list itself, NOT necessarily the values in it) are defined in the ‘Incident Management Library’:

The default tier1, Tier2 and Tier3 values (Note – the values rather than the list definition) are stored in the  ‘Service Manager Incident Management Configuration Library’, this unsealed MP (for which an extract is shown in the notepad below) has a reference to the sealed MP where these lists are defined:

NOTE: The MP referred to in the above notepad extract is the ‘Incident Management Library’ in the console, NOT the ‘Service Manager Incident Management Library’.

When we define the list values further down in the ‘Service Manager Incident Management Configuration Library’ unsealed MP, we use the CoreIncident! alias to refer to our sealed MP where the list itself is defined:

So going back to this, it is important to remember that the management pack shown in Library>Lists is where the List itself is defined (Incident Management Library as shown below).  It is rare that the values populated in the list are also stored in this same MP:

So these are the options for storing your list values:

• Create a Contoso List MP where all your list values for every list are stored (definitely don’t do this )
• Create an incident List MP where all your values for lists defined in the CoreIncident (Incident Management Library) are stored
• Create one MP per list that you customize.

Out of all the above I would recommend the third option for list MP management.  From experience, I’ve found that this is the most beneficial way to manage your list MPs for the following reasons:

• You can take that individual list customization and import it into a different service manager environment (for instance if you have test / prod SCSM environments
• It helps to ensure your list values MP is only dependent on one sealed MP as far as list definitions go. 
• After you have selected an MP where you want to store a given list’s values, it can take some effort to verify which MP you’re storing those values in, so if you follow this best practice, you will know that your Incident Classification values for example are in your Contoso Incident Classification MP.
• To Date, (please go ahead and touch wood right now ) I have not seen issues with too many MPs, but in SCOM (not SCSM yet ), I have seen issues with single MPs getting too big.  this typically arises in situations where all customizations have been stored in a single MP for convenience / ease of management.

The disadvantage of this approach is that you have more MPs to manage.  However in my experience, this management overhead outweighs the potential problems of undesired dependencies being created.

Another thing you need to know about list MPs is that when you first modify a list, you will be asked where you want to store your custom values.  For example lets say I go into ‘Incident Source’ because I want to add the source ‘drive-by’.  I know if you’ve read this far, that you know what I mean by that  

When you click the ‘Add Item’ button, you see the ‘Select Management Pack’ dialog box:

I like to refer to this as a one-off ‘life changing decision’ that you will not be able to go back on easily or have the opportunity to reselect later during your next modification.  

Let’s prove it…

Following my recommended best practice above, I want to ultimately store my incident source custom values in a Contoso Custom Incident Source List MP.  However, as shown in the screenshot above, I left the default and stored the customization in the ‘Service Manager Incident Management Configuration Library’, in order to show how to recover from this and ultimately get my customizations into the Contoso Custom Incident Source List MP.

After making this addition, when I go back into the Incident Source List, and click ‘Add Item’ I don’t see the ‘Select Management Pack’ dialog:

This is because I initially chose ‘Service Manager Incident Management Configuration Library’, so that’s where all my future modifications to this list will be stored. The easiest way to figure out where your list values are being stored is to modify a value (you can just modify the description if you don’t wan to modify the value itself) and then go over to Administration>management packs, sort by ‘last modified’, and look at which one was modified last.

Now if I go back and delete the ‘Drive-by’ value, click ok to save this, and then go back in to re-customize, I will get my dialog again as I backed out the Drive-by addition.

 

You may hit a situation where it is necessary to delete list data manually from the XML:

NOTE: Before you perform any manual modifications to the XML, ALWAYS have a backup of the MP before any manual modification.

If you do this, be sure to delete the associated displaystrings (match up based on the ElementId to Enumerationvaule ID) normally at the bottom of the MP file.

You may also want to delete the reference to the sealed MP that contains the list you modified:

However, notice in the above example, we’re at the point where we might as well delete this unsealed MP altogether as there’s nothing there anymore that we need (the entire contents are shown above)

Once the crossed out lines have been deleted, you can delete this MP from the Service Manager console, refresh until you don’t see it anymore and then re-import your modified version without the list data that you don’t want to see anymore (if there’s other things defined in the MP that you want to retain in your environment)   This will have the same effect that deleting the list values had, in terms of when you go in and add a value again, you will get the ‘select management pack’ dialog.

Renaming vs. Add Custom / Delete OOB

Some folks will rename the values, for instance in the ‘incident tier queue’ (support group) list, rename ‘tier1’ to ‘HelpDesk’.  I strongly recommend against doing this, as you may find when you upgrade to a new version of SCSM, you will lost your customized renames.  I always recommend adding your customizations and then deleting the OOB values. 

NOTE: In the case of support group values, these are used in some of the views, and therefore the dependent views must be deleted in order to delete these OOB support group values.  Steps for doing that can be found here: https://blogs.technet.com/b/servicemanager/archive/2012/05/09/removing-the-sample-incident-management-configuration-support-tiers-1-2-3.aspx

Some OOB values are stored in a sealed management pack and therefore cannot be deleted.  You can tell if list values are stored in a sealed MP like this, because the ‘Delete’ button will be greyed out:

For the Incident Classification list, the delete button is available, indicating that the incident classification values must be stored in an unsealed MP:

In this scenario where the OOB values (like Incident Source) are stored in a sealed MP, there are 3 options:

• Leave the default values there and ignore them. 
• Rename the OOB values. however this will preserve the same original internal ID and can sometimes cause confusion.  There is also the risk that they will be renamed back to the originals during upgrade.
• Extend the class, and re-create the property as a custom property of ‘list’ type in the authoring tool, and specify the values you want.

The screenshot below illustrates that when you try to rename a value stored in a sealed management pack, you see the ‘Select Management Pack’ dialog to select an MP that your renamed value’s display string will be stored in:

In this case, we store the modified displaystring in the custom MP:

Internally however, following the displaystring rename,  the list value is always going to have the same internal ID – ServiceRequest!ServiceRequestAreaEnum.Software.Licenses in the above example (even though we renamed the display string to LicensesRenamed).  The Internal ID cannot be changed, as it is defined in the sealed MP.

Custom Scenarios

You may have very specialized scenarios where you create a custom class or extend a class for a customized service Request / Incident or other scenario.  For example, lets say you create a Contoso New Hire Provisioning SR.  Ideally in this scenario, you will seal the MP that defines / extends the class, so the same best practice recommendation applies here in terms of creating a Contoso Custom new Hire Provisioning SR MP, where you will store all your templates and other elements that relate to this class. 

NOTE, in order for the class to be present in the data warehouse, the MP will need to be sealed.

If one of your extended properties is a list type property, you will especially want to ensure the MP is sealed.  If you leave it unsealed, and then add to the list in the same MP, open and update the MP in the Authoring tool (maybe add an extra property), then import the updated MP, you would lose all the values you added to the list in the console, following your initial import.  The trick here is to export the MP from the SCSM console so that it will include your additions created in the console, and then load it into the authoring tool such that it includes all your additions before making further changes in the authoring tool.

The advantage of defining everything related to a custom scenario like this in a specific MP, is that if you should decide to wipe this custom scenario out of the environment (or try it in a different environment), everything associated with it will all be in that one MP.  Or if you wish to update it in some way, everything related to that custom scenario MP, being in a single MP will make it much easier to manage.

Naming Convention for SCOM

The naming convention for management packs in SCOM is really simple – just add some kind of prefix to identify it as your own.  So for instance if you import the SQL 2008 Monitoring MP, create a Contoso Custom SQL 2008 monitoring MP to store your customizations in.  The key part here is to include some kind of prefix such as Contoso as it will make it easier to find customizations and distinguish them from what is provided out of the box.

Also it is good practice to use this naming convention for all other monitoring elements created such as rules, monitors, groups etc., for the same reasons of making them easier to find, and better distinguishing them from OOB elements.

Naming Convention for SCSM

As with SCOM, it is best practice to add some kind of prefix to the MP name to identify it as your own. 

This is how I like to name templates in  Service Manager:

My Prefix is Antoni SCSMCT (SCSMCT stands for System Center Service Manager Chalk Talk) and then the following acronyms:

• MA – Manual Activity
• RA – Review Activity
• SR – Service Request
• RAA – Runbook Automation Activity
• CR – Change Request

Doing this may seem overkill, but implementing this has made my test environment a TON easier to manager and administer. For instance, now in the filter box at the top of the view shown above I can type ‘– SR –’ for example to quickly see all my Service Request templates.

As an added tip, put as much information into the name as possible making it easy to figure out what a customization is, just by looking at the name.  Also, use the description field.  For instance if you create a Review Activity template that has 2 reviewers in it called Antoni H and Emmett H, then a bad name would be 'Review Template 1’ A good name would be: 'Antoni review template containing approvers Antoni H and Emmett H – unanimous approval'.

What is an MPB (Management Pack Bundle)?

To recap, an unsealed MP is an xml file.   A sealed MP is a .mp file. An mpb  is a combination of either an unsealed / sealed MP, together with one or more dll assembly files. An example of when you may need to create one of these, is if you create a custom form using one of the OOB forms (like the service request template) as a starting point.  That OOB form is defined in a form assembly (dll).  Therefore if you have an MP that uses that assembly (extends the OOB form) then your assembly needs to be bundled with the MP containing that customization.  You can read more about the MPB on the product group’s website here:

https://blogs.technet.com/b/servicemanager/archive/2009/09/04/introducing-management-pack-bundles.aspx

To Seal or not to Seal

This link has some great guidance on sealing management packs.

https://blogs.technet.com/b/servicemanager/archive/2009/12/25/sealing-management-packs.aspx

One key lesser known fact described in the above link is that you cannot store customizations that reference an unsealed from another unsealed MP.  For instance, let’s say you create an unsealed MP containing a list property, and then you import this unsealed MP.  You will not be able to store list values for that list in a different unsealed MP.

Therefore if you want to customize an unsealed MP, you either have to keep it all (original configuration and customization) within the one unsealed MP, or seal the MP that you are customizing, so that you can create an unsealed MP which will reference the sealed MP and contain your customizations.

In order to perform the sealing process, one of the most difficult parts of this process can be finding the sn.exe tool:

I got it from the Windows SDK Download:
sn.exe https://www.microsoft.com/en-us/download/details.aspx?id=8279

sn.exe is typically installed with most Visual Studio installs, so you may be able to find it already out there in your environment somewhere.

The screenshot below shows how you Seal a management pack from the authoring tool:

When you click ‘Seal Management Pack’, you just need to fill out the below and then the MP will be sealed.  This will preserve the .xml unsealed MP wherever it was saved most recently, and it will create a sealed version of the MP (.mp file) in the output directory (which you will likely want to change from the default user profile\documents directory) and automatically increment the version number by 1.

MPs can be ‘unsealed’ either by exporting from the console (which for a sealed MP will export it as an xml) or using a command like the following in PowerShell:

> cd c:\program files\Microsoft System center 2012\Service Manager\Powershell
> import-module System.Center.Service.Manager.psd1
> Get-SCSMManagementPack | where-object {$_.Sealed –eq $false} |Export-SCSMManagementPack –path C:\mpbackup

For SCOM, you can run the following from the OpsMgr Command Shell:

> Get-SCOMManagementPack | where-object {$_.Sealed -eq $false} | Export-SCOMmanagementpack  -path “C:\MPbackup\”    

Thank you for taking the time to read this post, and I hope it was helpful  

Cheers, Antoni

Comments

• Anonymous
  January 01, 2003
  Thanks for the share.

• Anonymous
  October 16, 2013
  Great article! A must read for SCSM / SCOM admins!

• Anonymous
  October 18, 2013
  What are your recommendations for "custom scenarios" where there is no class extension/customizations. Ie. scenarios (I call these "themes" in my terminology) where one would produce several offerings of a kind, perhaps both Service, incident, and change requests (OotB classes) which are related by scenario/theme, ex. all things printer: My printer doesn't work (IR), paperjam (IR), need a printer for my office (SR). replace toner-cartridge (SR), upgrade printserver (CR). Last one is a bad example as you would be unlikely to have a specific request offering on printserver upgrades :D What I normally do is keep everything related in the same unsealed MP: Work item templates, request offering, and service offering. If I have subscriptions, email templates, views, SLOs, etc.  made specifically for the scenario they may very likely end in that same MP. Depending on the scope of the scenario I may split up the MP (limited by dependencies ofc.). This way one do not risk inflating a MP for ex. work item templates, one for subscriptions, etc. The downside being that dependencies can be limiting this way of doing it. And if the scenario someday become irrelevant the MP can be deleted and all related configurations are gone like they were never there! With this approach there are still a ton of generic (multi-purpose) views, work item templates, subscriptions, etc. that are allocated just like you recommend in your blogpost.

• Anonymous
  October 18, 2013
  Great post thanks !

• Anonymous
  October 18, 2013
  Anders - this is exactly the kind of scenario where it gets debatable and I don't think there is a true right or wrong answer :-)  It all comes down to understanding the impact of doing it either way, and what makes it easiest for you to manage the SCSM environment. For situations where you're just using the built-in classes like IR / CR / SR, I would stick with the best practice of having one unsealed MP per class (one for incident, one for SR etc.) and still store the appropriate elements (depending on what class it is based on) in the appropriate unsealed MP.   However the disadvantage of this as you say, is that if you want to delete everything related to that scenario/theme/custom scenario, you get into deleting entries from multiple MPs.   Although I think what you're doing makes sense for your methodology, the only reason I recommend the alternative approach of one unsealed MP per class rather then one MP per scenario/theme/custom scenario is that rather than looking at holistic themes / scenarios like 'everything related to print' encompassing multiple work items like CR, SR and IR, I find  most customers tackle each work item sequentially.  So they'll start by looking at incidents, figuring out what incident templates, queues etc. they need.  Then they'll look at SRs and figure out the same, and then CRs and so on. Another reason is that doing one per custom scenario/theme/scenario, you may end up with a lot more MPs than you need (obviously dependent on how many of these scenarios you have) , so for instance lets say I was dealing with print incidents, software incidents, hardware incidents, network incidents (everything in my incident classification list) and I had a different MP for each incident classification, that would potentially be a lot more MPs than I need.   But like I say, not sure there is a true right or wrong answer to this :-) Cheers, Antoni

• Anonymous
  April 13, 2014
  I have been doing a lot of work lately at customers recently (you know who you are ) helping them create

• Anonymous
  May 22, 2014
  Thank you !

• Anonymous
  June 05, 2015
  It has been a while since I last blogged, but I figured as I was sitting on an aeroplane yesterday, it

• Anonymous
  June 22, 2015
  Hi, Antoni, please i need you help me, I change Incident Classification list but no see the update in self portal, one day after the update i see the change in the self portal, but i need see the change same day, thanks for you help

• Anonymous
  July 08, 2015
  Hi Herbert, If you restart cache builder service from the self service portal server after you have made changed to anything (that is linked to portal), it will show the changes the same time. It shows the changes the next day as the cache builder service might be restarting overnight in your case.

• Anonymous
  July 10, 2015
  The comment has been removed

• Anonymous
  October 07, 2015
  Introduction Who said all sequels were rubbish?! This is the sequel to my first blog on this with some