If you have ever used or maintained System Center Service Manager (SCSM) or Operations Manager you will be aware of Management Packs that are used to store configuration of the System Center products.
It can be quite tricky to understand the best ways of using these and it can have quite a larger impact on the support ability of the product over time.
In this article, we will take a look at the best way create, name and use management packs within SCSM to provide organisations with the best performance and simpler ongoing maintenance.
Naming Convention in SCSM
Having a consistent naming convention is key to being able to track what data needs to go into what Management Pack and also to understand what a management pack would contain when you back it up for storage or hydration of a Dev\Test environment.
Within SCSM, the naming convention that I find most useful is to follow the navigation steps you would use to get to the piece of data that you are storing.
For example: If I wanted to edit the Incident Tier Queue enumeration list, I would have to navigate to Library workspace (1), Select the lists node (2) then select Incident Tier Queue from the workspace (3).
So the naming convention should be: Library.Lists.Incident_Tier_Queue
I also like to put the customer name at the front so I don’t get them confused, so it would read: Cireson.Library.Lists.Incident_Tier_Queue.
Here is a list of all of the management packs I created when first creating an SCSM installation:
- CustomerName.Administration.NotificationTemplates
- CustomerName.Administration.ServiceLevelObjects
- CustomerName.Administration.Subscriptions
- CustomerName.Administration.Workflows
- CustomerName.Administration.Connectors.AssetImport
- CustomerName.Library.Lists.ChangeRequestSupportGroup.EnumerationValues
- CustomerName.Library.Lists.ProblemRecordSupportGroup.EnumerationValues
- CustomerName.Library.Lists.Impact.EnumerationValues
- CustomerName.Library.Lists.IncidentClassification.EnumerationValues
- CustomerName.Library.Lists.IncidentResolution.EnumerationValues
- CustomerName.Library.Lists.IncidentSource.EnumerationValues
- CustomerName.Library.Lists.IncidentTierQueue.EnumerationValues
- CustomerName.Library.Lists.ManualActivitySupportGroup.EnumerationValues
- CustomerName.Library.Lists.ServiceRequestCategory.EnumerationValues
- CustomerName.Library.Lists.ServiceRequestSupportGroup.EnumerationValues
- CustomerName.Library.Lists.CatalogItem.EnumerationValues
- CustomerName.Library.Lists.CatalogItemModel.EnumerationValues
- CustomerName.Library.Lists.Consumables.EnumerationValues
- CustomerName.Library.Lists.Asset.EnumerationValues
- CustomerName.Library.Lists.Invoice.EnumerationValues
- CustomerName.Library.Lists.Currencies.EnumerationValues
- CustomerName.Library.Lists.Urgency.EnumerationValues
- CustomerName.Library.Queues
- CustomerName.Library.Templates
- CustomerName.ServiceCatalog.GenericServiceRequest
- CustomerName.ServiceCatalog.NewUserAccount
- CustomerName.ServiceCatalog.RaiseNewIncident
- CustomerName.ServiceCatalog.ServiceOfferings
- CustomerName.ServiceRequest.DataWarehouse
- CustomerName.WorkItems.Views
Number of MP’s
I sometimes hear people justify putting all of their List values into a single Management Pack by saying they didn’t want to create too many management packs for the system to have to process. However, I’m yet to find a limit of the number of management packs where the performance becomes an issue. (I’m sure there is a limit, but I’ve not hit it yet).
As a rule of thumb, I suggest anything that you might want to update or manage independently should have it’s own Management pack.
Some examples are:
- Every enumeration list.
- Every Request Offering.
- Every Notification template type.
- Etc.
I’ve seen customers with hundreds of management packs and that is OK.
I’ve also seen customers with one single management pack, and that takes forever to find any values they might want to alter…..
Backing Up Unsealed MP’s
One task that people often miss is backing up of unsealed MP’s. If you have a management pack that is unsealed then it is not getting merged with the database and therefore does not get backed up via SQL. Instead, you have to make a copy of the management pack on a regular basis as a method of maintenance if the SCSM server was ever to have issues.
This can be done with a fairly simple PowerShell script and run on a regular basis from some automated schedule…… Orchestrator anyone??? 🙂
Let us know if this is of help and feel free to reach out through the Cireson Community for more tips and tricks!
