Ahh, a lovely fresh install of Microsoft Service Manager (SCSM), nothing beats it. No random badly named management packs. No old subscriptions that no one can remember what they are for. The excitement of creating our very first Incident (IR1).
But wait, Microsoft has provided for me some Out of the Box items that are messing up my Zen. I didn’t want three Incident Support Groups (Tier Queues) called Tier 1, Tier 2 and Tier 3. I didn’t want a default SR Template that I can’t edit but is of no use to me. And I definitely didn’t want a Generic Incident Request offering in every possible language.
It is true that some of these items are useful as they give us an idea of how to use the product and examples of how to configure things. However, not very much of it is actually useful in a production environment. It is not good practice to use these items as they come and even worse to edit them because they live in the out of the box management packs. Some of the items can be easily deleted, some of the items can be deleted but it takes a few steps and some of the items cannot be deleted but we can work around that and hide them in the Cireson Portal.
Request Offerings
All but one of the out of the box Request Offerings are in unsealed management packs so can be deleted. The one complication here is that SCSM will place one of these (the one corresponding with the language in which we installed SCSM) into the Generic Incident Request Catalog Items Group which means we cannot delete it. We will need to first remove it from that.
This task in itself is unfortunately not super simple as just removing it would leave the Generic Incident Request Catalog Items Group empty which is not allowed. I suggest you leave a dynamic member including all Service Offerings with the Category of General that we are stuck with (see Enumerations section). Once that is done we can remove the final unsealed offering.
The final offering you will find cannot be deleted as it is in a sealed management pack. In fact, crazily it cannot even be unpublished as that would involve changing something in a sealed management pack. There’s no way to remove it from SCSM but we can ensure it will never be shown in the Portal by not putting it into a Service Offering.
Templates
There are a number of templates that come out of the box. Some are in unsealed management packs such as the various Incident templates for Networking, Printing etc. They can be deleted once any Request Offerings they rely on have been deleted so ensure you have followed the above sections first.
Some of them however, are in sealed management packs and cannot be removed. We need to ensure these will not ever be selected by an analyst creating a Work Item from a Template as they will not follow any valid process within the organisation.
This can be done with a piece of custom JavaScript called via the custom.js file which hides templates matching certain criteria.
[code language=”javascript”]
$(document).ready(function () {
var templateObserver = new MutationObserver(function (mutations) {
$(“.templatename”).each(function (index) {
var tplName = $(this).children(‘strong’);
console.log(tplName[0].innerText)
if (tplName[0].innerText.match(“Default”) ||
tplName[0].innerText.match(“Generic Incident Request”) ||
tplName[0].innerText.match(“Incident portal template”) ||
tplName[0].innerText.match(“Publish Offering”) {
$(this).parent(‘tr’).eq(0).hide();
console.log(“1: ” + tplName[0].innerText)
}
});
});
var drawerActionNode = $(strong “.drawerdetails-actions-box”)[0];
var observerConfig = {attributes: false, childList: true,subtree: true,
characterData: false};
templateObserver.observe(drawerActionNode, observerConfig);
});
[/code]
Enumerations
The Enumerations (List Values) that come out of the box are an odd mix. Some are empty, a lovely blank canvas to add items to, some are filled with unsealed items that we can remove if we want and some are sealed meaning we are stuck with them.
Empty Lists
We can go ahead and add our list items. Remember, as per good SCSM practise, we want to put all list items in our own custom Management Pack (not the ‘Suggested’ out of the box Management Packs from Microsoft), preferably broken down by type of Item, eg Incident, Service Request etc. If the list is completely empty, SCSM will ask us where we want to put our new list item when we add one. Select the right management pack and we’re good to go. When we add subsequent items (even on a different occasion) SCSM will not ask about a Management Pack as it will automatically put any further list items into the same Management Pack as the first.
Filled Lists
An example of this might be the Incident Classification List or the Activity Area List. Both these come prepopulated with some nice items but are unlikely to be everything we need. We can off course add more. However, as above, when we add items to a non-black list, SCSM won’t ask us what Management Pack to store them in, it will automatically put them in the same Management Pack as the existing items. In the case of an Out of the Box Filled list, this is a Out of the Box Management Pack. It is not a good idea to store any customisations in these.
The trick is to completely empty all these Lists that come filled out of the box. (Remember, we need to delete any Templates referencing these Enumerations first so see above.) Even if we like the list items, it’s worth deleting the lot, clicking OK, then reopening and adding them back in. This will cause SCSM to ask where to store the values and our custom items will be in a custom Management Pack, not an Out of the Box one. Perfect!
There is one particular list that is made even more tricky and has pretty useless values in it we will definitely want to remove. The Incident Tier Queue, also known as Support Group, list. These are not sealed but are reference in a number of places making them tricky to delete. However, it is worth doing for the reasons above. We will need to ensure that no Incident Templates have these set as the Support Group in them and then also delete the 6 Out of the Box views that reference them. Then we can remove the List Items and re-add our required values.
Sealed Lists
A number of the lists in SCSM are completely stored in sealed management packs meaning the items we get Out of the Box cannot be removed. We can add more items to these lists, and we can override the Display Name of the sealed items but we cannot get rid of them. Some of the List Items are sealed for good reason. All of the Work Item Status List Items are sealed because they have fundamental process, workflows and tasks that rely on them.
If we delete the Incident ‘Resolved’ status List Item, then all the Resolving processes (manually using the task, auto resolved by parent etc) would break. The only thing I would recommend to do with these lists is potentially override the DisplayNames to suit your own business language, eg Active à Open. NB: I do not recommend you rename in an attempt to re-purpose a list item.
But, one particular list is sealed for no good reason and that is Service Request Area. It contains a bunch of items, some of which seem useful, some of which are definitely not for most people and we cannot delete them. The pretty simple and yet not at all obvious: Just don’t use them. As mentioned, we can add our own List Items, even to these sealed Lists and we can even move our Items to the top so all the Out of Box ones will be at the bottom. We can append a little message to these (using the DisplayName override technique) to make it clear these are not to be used. I like to go with something not so subtle.
SCSM List Properties
With a host of our own values at the top, and these items clearly marked at the bottom, we should be ok, and hopefully our analysts will select a ‘valid’ option each time. However, this isn’t totally robust and its certainly not an elegant solution. We can complete this work with the final trick, the pièce de résistance, which is to then hide these items from showing in the Cireson Portal. Assuming most of our analysts do all their day to day with in the Cireson Portal, this means they will never see, worry about or even know about these unremovable items. For other interfaces, we can still rely on the above ‘DO NOT USE’ method.
We hide the items in the Cireson Portal by making a small change to the Enumeration table in the ServiceManagement database (assuming you gave it the default name). The tables contains one row for each List Item in our environment and has a column called Enabled which by default is a ‘1’ for all rows but can be changed to a ‘0’ to effectively remove the list item from the scope of the Cireson portal. This could be done row by row with the EnumerationId but assuming we have implemented the above concept of adding ‘(DO NOT USE)’ we can do it in one go with the below SQL query which joins to the DisplayString table to check which Items have ‘(DO NOT USE) in the DisplayName.
[code language=”javascript”]
UPDATE [ServiceManagement].[dbo].[Enumeration]
SET [Enabled] = 0
WHERE [EnumerationID] IN (
SELECT [EnumerationID]
FROM [ServiceManagement].[dbo].[Enumeration]
JOIN [ServiceManagement].[dbo].[DisplayString]
ON [ServiceManagement].[dbo].[Enumeration].[EnumerationID] = [ServiceManagement].[dbo].[DisplayString].[ElementID]
WHERE [ServiceManagement].[dbo].[DisplayString].[DisplayString] LIKE ‘%(DO NOT USE)%’
)
[/code]
From the next Application Pool recycle, these List Items will not show up in any drop downs within the Cireson Portal.
So, follow these steps and you will have the Perfect Service Manage environment. Ahh.
