Tips from the Trenches: SCSM Best Practices from 5+ Years of Experience & Expertise

SCSM Best Practices

As an IT Administrator (or prospective Admin), there’s a lot you can do with Microsoft System Center Service Manager (SCSM) to make it work better out-of-the-box for your organization. I’ve been implementing and customizing SCSM since its initial release about 6 years ago. Combined with over 52,000 System Center consulting hours at Cireson, we’ve compiled a list of best practice tips to help maximize your investment and increase productivity. Check them out below:

Infrastructure

Let’s begin at the beginning with the infrastructure build out. When planning your Production environment, it is important to remember two facts about SCSM:

1. While you may have multiple Management Servers, only one (the Primary) processes workflows. It is recommended even in smaller environments that, if you can get away with it, you should have at least two SCSM Management servers. The first one will be the Primary Workflow server and should have the lion’s share of server resources (CPU, RAM, IOPS, etc.) to process workflows. The second will be the Management server that all Consoles will connect to and if you are planning to use a Self-Service Portal, that would be the server to host it on.
   
   
2. SQL needs to be beefy. SCSM has a strong CMDB behind it and the more you use it, the more you are dependent on the interaction between the Management Servers and the SQL database. You are going to want to give SQL as much memory as possible, but the truth is that SQL lives and dies by IOPS. If you are using local storage, use fast disks in a RAID 10 configuration. If you are using SAN-attached storage, make sure you are getting Tier 1 resources. When you configure SQL, ensure that you select the correct SQL collation, Latin1_General_100_CI_AS, for both the SCSM active databases and the Data Warehouse, if you are planning to use one.

System Center Service Manager is scalable but its good to plan for future growth up front. Remember that without a web-based Analyst portal, Analysts will be using the locally installed Console so if your Analyst count grows, you may want to add a few SCSM Management Servers behind a load balancer for Consoles to connect to.

Development

The importance of having a Development environment for SCSM cannot be overstated. During your ITSM lifecycle, you will be introducing the following more often that you probably think:

• Process changes
• Configuration changes
• Custom CI and WI extensions
• Custom CI and WI classe
• Workflows
• Automation
• Form customizations

Many times, smaller (or even larger) organizations start a habit of “cowboying” development in the Production instance to save resources. This is not a good idea with SCSM (or anywhere, really) as HA is typically non-existent and system recovery is very complicated and usually comes with significant impact on IT Service Management.

The Dev environment doesn’t have to mirror Production resources. It can be a single pathetic VM (4gb memory, 2 CPU, 40gb+ hdd) running SQL and SCSM which is well below Microsoft’s minimum recommendations but perfectly adequate for developing and testing. If you can get away with it, having a separate QA environment would also be ideal allowing you to take the above changes through Dev, to QA, and then to Production all using ITIL-based Change Management.

Management Packs

Continuing the theme of development, almost all configurations (list enumerations, views, queues, etc.) and customizations for SCSM are stored in Management Packs. It can be very easy to let MPs get out of control and many MPs have dependency on other MPs which can quickly become a nightmare to untangle. Here are a few tips for Management Pack control:

• Create and enforce a naming convention for your Management Packs.
  • Typically suggest: Organization Name – Class or Modules – Type of content
  • For example: Cireson – Incident – List
    
    
• Keep the content stored in Management Packs as specific as possible. Generally speaking, the more Management Packs the better (keeps you out of dependency hell, and allows for more granularity when migrating content from Dev -> QA -> Prod)
  
  
• Make sure to seal any custom Class Extension MPs you create for your new environment before importing, and backup the sealed MP, unsealed MP, and sealing key.
  
  
• Don’t create your unsealed MPs from the Console. The Console generates a guid to name the Management Pack file which makes keeping them organized when exporting nigh impossible. Create them ahead of time through PowerShell or the SCSM Authoring Tool.
  
  
• Don’t put anything in the built in, out of the box unsealed MPs.

Security

Configuring Security Roles for Analysts and End Users can be a bit overwhelming as it is not as simple as we would like. One important fact to remember is that security is based on most-user privilege, meaning that if an Analyst is a member of more than one Security Role, that person will have the combination of all rights (as opposed to least-user privilege where they would only have the minimum of the combined).

Also, very important to remember is that the application of security scopes (Queues and Groups) to Work Items (WIs) and Configuration Items (CIs) requires SCSM workflow, which adds to the workflow server workload. With this in mind, here are some important tips when planning your SCSM security:

• Create Analyst User Roles based on Advanced Operator (instead of Incident Resolved, Service Request Analyst, etc.) in order to keep the number of roles small.
• Only use Queues to scope Work Items if there is a specific reason for them such as sensitive information WIs (like in HR). Applying queues requires a workflow and the more you have, the possibility longer it would take for such security to apply to the work item.
• The same holds true for CIs and Catalog Items. Try to keep these as simple as possible.

Connectors

When setting up Connectors in SCSM, it is important to remember that all objects imported by a Connector (AD, SCCM, etc.) will be deleted if the Connector is deleted. So if you are replacing a Connector with an updated version for whatever reason, create the new Connector and run the import before you delete the old connector (same resource records will merge), so as not to lose those resources. Here are a couple of tips when planning Connectors:

• Use LDAP filters when creating AD connectors. For Users and Groups, if you have them in specific OUs, be sure to target those directly rather than hit the root of the domain (if this requires multiple Connectors, so be it). This will cut down on unnecessary user and group objects in the CMDB such as mailbox and service accounts. For computers, if bringing in a specific type of machine, use an LDAP filter as to not bring in undesired items.
  
  
• Attempt to only bring in Windows Computer objects from a clean source, like Configuration Manager or Operations Manager, not AD. Don’t bring in Computers from Active Directory unless you have a specific set of machines not included in Configuration Manager (such as MacOS machines, or mobile devices)—Configuration Manager brings in more/better data, and you typically only get junk from AD connector.

Enumeration Lists

Enumeration Lists in SCSM are critical for efficient routing of Work Items and accurate reporting of WIs and CIs. Here are some tips when planning your lists:

• Think strategically about creating enum values before shelling them out.
  • Keep list of enums to 5-8 values per level is optimal: any more values per level and your analysts will select incorrect values
  • If you believe at some point that the SCSM system will be expanded beyond just the IT department, plan to have all top-level entries be by Department, even if IT will be the only one using the system for a while. Trying to expand Enumeration Lists to other Departments after the fact is a nightmare if you don’t plan ahead.
  • It may sound obvious but avoid similarly named/overlapping values (i.e. “Phone” versus “Mobile Phone”—if someone is logging a record for an iPhone and they see ‘Phone’ first, they select it which you did not intend. In this example, “Desk Phone” and “Mobile Phone” would work better, or just a single value of “Phone”)
    
    
• Remove all OOB unsealed enumeration values, such as Incident Tier Queue’s Tier 1. Next, add your own enumeration values to custom management packs in an organized manner, such as one unsealed MP per class, or per module.

Views

Work Item and Configuration Item Views are a fact of life in the SCSM Console. For WIs, you as an Admin will be very busy creating custom views for your Analyst groups. Take the following into consideration when creating views:

• When creating views, use the smallest available type projection (the joining of multiple classes via relationships) to drastically decrease load times. Don’t be afraid to create a custom type projection.
  
  
• Again, plan out your view structure with an eye towards expanding beyond IT, if you haven’t already. Create root View folders based on Department.

Reporting

When it comes to reporting in SCSM, many folks do not take the time to truly evaluate what their reporting needs will be and typically end up with more infrastructure than they need. Pay particular attention to the Classification (Incident) and Area (SR, CR, MA, etc.) when setting up your Enumeration Lists as these are the key fields for Trend Analysis reporting.

Microsoft SCSM provides the (optional) addition of a Data Warehouse for reporting and archiving. For SCSM 2012 R2, this was a necessity for medium to large organizations as grooming would keep the active SCSM database leaner and performance was a huge factor. In SCSM 2016 and later, Microsoft resolved many of the performance issues which made running SSRS reports against the active database insignificant regarding performance hit. When you are trying to determine whether to implement a Data Warehouse in your SCSM infrastructure, consider the following:

• What is your expected WI & CI count per month and what will you need to report on out of the gate? If you generate 50K + WIs a month and need aggressively complex reports, you may need to go with a DW to keep the SQL queries from hitting your active DB
  
  
• When contemplating a Data Warehouse, keep in mind that WI Action Logs, Comment Logs, and History are not archived with WI information. You can only report on these fields from the active database
  
  
• When using a Data Warehouse, if your policy requires that attachments be retained with the work items, you must create a workflow to extract them in order to keep them. WI attachments are stored in the active database as blob files and are not transferred to the Data Warehouse so they are permanently deleted when a WI is groomed from the active database following the retention period.
  
  
• The SCSM Data Warehouse must be factored in during upgrade of SCSM and if you are migrating from one instance of SCSM to another, including the DW as part of the migration is nigh impossible without professional help.

Notifications

Notifications are a key part of maintaining efficiency as an ITSM organization using SCSM. The quicker you know about a request or issue, the quicker you can set about resolving the issue or fulfilling the request. Keep these tips in mind when setting up your notifications:

• Test notification subscriptions in the Dev environment first, if you have one. If not, set your notification channel to localhost during setup, and use a local SMTP server when creating / testing notifications in Production (to avoid spamming a userbase)
  
  
• Remember that each notification subscription comprises a workflow (for which you only have one server to process) so be judicious about how many you create.
  
  
• Always try to use AD Distribution Groups in your subscriptions rather than individual users. Its easier to maintain.

Workflows and Automation

As you begin to advance your SCSM environment, you will desire to increase efficiency by using workflows and automation. Automation can be provided OOB in the SCSM Console or can be provided by partnering SCSM with System Center Orchestrator. SCO is a highly recommended automation engine as it integrates with all System Center solutions such as Configuration Manager and Operations Manager. Automating ITSM processes is highly recommended but please review these suggestions before embarking on this endeavor:

• When contemplating what processes to automate, consider the ROI to determine if the process even needs to be automated. Just because a process can be automated, it doesn’t mean it should. A process that occurs once a quarter and takes ten minutes to accomplish, does not necessarily benefit from automation.
  
  
• SCSM provides a limited workflow builder in the Console (or you can create workflows using the Authoring Tool) but consider using these for simplified workflows only and leverage System Center Orchestrator for more complex automation. You can use Runbook Automation Activities in your WI workflows or trigger-based Monitor Activities in Orchestrator Runbooks. Orchestrator will allow you to keep the load off the SCSM workflow server and help you maintain maximum performance.
  
  
• If you are going to begin introducing automation, having a development environment (for both SCSM and SCO) is critical for creating and testing automated processes to limit risk to the Production environment.

SCSM Best Practices Conclusion

We hope that these SCSM Best Practices tips and suggestions will help you maximize the value of SCSM in your ITSM world. Again, we at Cireson have a high opinion and have had many positive experiences with SCSM as a cost-effective, scalable solution if you take the time to understand it and learn its capabilities. For more assistance with SCSM, you can visit the Cireson Community website here.