Best Practices for Working with Microsoft System Center Service Manager

SCSM and ITSM best practices by Cireson

IT administrators can do a lot with Microsoft System Center Service Manager (SCSM) to improve its functionality out-of-the box. You can get a head start by following these best practices that help maximize your investment and increase productivity.

Infrastructure and Planning Your Production Environment

Let’s start at the beginning: planning your production environment. There are a few things to keep in mind:

  1. Two SCSM management servers are ideal, even in small environments. Only one management server (the primary) processes workflows, so it should contain most server resources, including CPU, RAM, IOPS, etc. The second management server will connect to all consoles and host a self-service portal.
  2. Beef up SQL. SCSM contains a Configuration Management Database (CMDB) among others, and it needs memory:
    1. Local storage: use fast disks in a RAID 10 configuration
    2. SAN-attached storage: get tier 1 resources
  3. Choose the correct SQL collation during configuration. Use “Latin1_General_100_CI_AS” for both active SCSM databases.

Although SCSM is scalable, you’ll want to plan for growth—and potential future investment. For example, in the absence of a web-based analyst portal, analysts will use the locally-installed console. As your team grows, consider adding more SCSM Management Servers behind a load balancer to connect consoles.

Create a Development Environment

It may be tempting to “cowboy” development in production. It’s not a good idea in general, but it can be particularly troublesome in SCSM because system recovery is complicated. And that would greatly affect IT Service Management across the board.

A development environment spares you such pain and helps you execute a broad range of ITSM lifestyle functions, including:

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

You don’t need to mirror the production environment; you could set up:

  • A single VM (4gb memory, 2 CPU, 40gb+ hdd) running SQL and SCSM, which is below Microsoft’s minimum recommendations but just fine for developing and testing
  • A separate QA environment, so that you could progress changes from Dev to QA to Production–all using ITIL-based Change Management

Take Control of Management Packs

Management Packs store almost all configurations, including list enumerations, views, queues, etc. To prevent interdependency and unruliness, try:

  • Setting up a naming convention for management packs:
    • Organization Name – Class or Modules – Type of content
    • Example: Cireson – Incident – List
  • Creating more management packs that store specific content. This prevents dependency and allows for more granularity when migrating content from Dev -> QA -> Prod
  • Sealing custom class extension MPs created for your new environment before importing and backing up the sealed MP, unsealed MP and sealing key
  • Creating unsealed MPs ahead of time using PowerShell or the SCSM authoring tool. Don’t create them from the Console. The Console generates a guide to name the Management Pack file, which makes it practically impossible to keep them organized when exporting
  • Don’t put anything in the built-in, out-of-the-box unsealed MPs

 Security Isn’t Simple, But There Are Ways to Simplify It

Configuring security roles for analysts and end users can get complicated. Especially when you consider that security is based on most-user privilege: if an analyst is a member of more than one security role, they will have the combination of all rights (as opposed to least-user privilege where they would only have the minimum of the combined).

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 tips when planning SCSM security:

  • Maintain a small number of roles: create analyst user roles based on “advanced operator” (instead of incident resolved, service request analyst, etc.)
  • Only use queues to scope “work items” if there is a specific reason to use them: applying queues requires a workflow. The more you have, the longer it could take for a security measure to apply to the work item. It may make sense, however, when dealing with sensitive information WIs (like in HR)
  • Keep CIs and “catalog items” simple as well

Test Process with New Connectors Before Deleting Anything

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, create the new connector and run the import before deleting the old connector (the same resource records will merge). This way you won’t lose anything.

When planning connectors:

  • Use LDAP filters when creating AD connectors and bringing in a type of machine to computers
  • Target users and groups directly if they are in specific OUs. This is preferable to hitting the root of the domain (it’s fine if you need multiple connectors). You’ll be able to cut down on unnecessary user and group objects in the CMDB, like mailbox and service accounts
  • Only bring in Windows computer objects from a clean source, like configuration manager or operations manager–not AD. Configuration manager brings in more and higher-quality data. We don’t recommend bringing 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)

 Enumeration Lists: Routing and Reporting

Enumeration lists enable efficient routing of “work items” and accurate reporting of WIs and CIs. When planning your lists, remember to:

  • Think strategically about creating enum values before shelling them out:
    • Shoot for 5-8 values per level on enum lists: analysts are more likely to select incorrect values if you include more than this amount
    • Plan for all top-level entries to be by department if SCSM might expand beyond IT. Even if such a change won’t occur for a time, it is very difficult to expand enumeration lists to other departments after established. It is far easier to act proactively
    • Avoid similarly named or overlapping values. Example: “phone” vs. “mobile phone.” If someone is logging a record for an iPhone and they see ‘Phone’ first, they might unintentionally select it. It would be better to use “desk phone” and “mobile phone,” or just a single value, “phone”)
  • Remove all OOB unsealed enumeration values, including incident tier queue tier 1. Next, add your own enumeration values to custom management packs in an organized manner. For example, one unsealed MP per class or per module

 Custom Work Item and Configuration Item Views

You’ll likely engage with “work item” and “configuration item” views a lot in the SCSM Console. Admins spend a lot of time creating custom “work item” views for analyst groups, so you’ll want to:

  • 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
  • Plan your view structure with expansion beyond IT in mind and create root view folders based on department

 Don’t Make Reporting an Afterthought, SCSM Data Can Fuel Great Reports

It’s easy to get caught up in work and neglect reporting needs. But SCSM contains a gold mine of data that can be used to create meaningful reports. Here’s an idea to help you prepare: when setting up enumeration lists pay attention to classification (incident) and area (SR, CR, MA, etc.). These fields are key for trend analysis reporting.

We just launched a new analytics and archiving tool that is a dramatic improvement over SCSM’s data warehouse. You can hear more about it in Cireson’s Q1 webinar.

Maintain Efficiency using Notifications

The faster you know about a request or issue, the quicker you can resolve the issue, fulfill the request or plan when to address it. When setting up notifications, remember to:

  • Test notification subscriptions in the Dev environment first. If you don’t have one, set the notification channel to localhost during setup and use a local SMTP server when creating / testing notifications in production (to avoid spamming a userbase)
  • Be careful about the number of notifications you create, because each notification subscription comprises a workflow (and you only have one server to process them)
  • Use AD distribution groups in subscriptions rather than individual users. They are easier to maintain

Notification activity is another feature just launched in the console app, which greatly simplifies notification use and execution. Find out more!

Simplify Processes and Increase Sophistication with Workflows and Automation

Workflows and automation create efficiency, and they can really help you refocus on more complex work. You can automate in the SCSM Console by partnering SCSM with System Center Orchestrator (SCO). SCO is a highly recommended automation engine that integrates with all System Center solutions, including configuration manager and operations manager. Automating ITSM processes is highly recommended, but you’ll want to keep these suggestions in mind:

  • Consider ROI when deciding what processes to automate—and what doesn’t need to be automated. A process that occurs once per quarter that takes ten minutes to accomplish does not necessarily benefit from automation
  • SCSM offers a limited workflow builder in the console (or you can create workflows using the authoring tool) but consider these options for simplified workflows only. For more complex automation, use SCO. 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, a development environment (for both SCSM and SCO) is critical. You need the space to create and test automated processes to limit risk to the production environment

We hope that these tips and suggestions will help you maximize the value of SCSM in your ITSM environment. It’s a valuable cost-effective, scalable solution if you take the time to understand it and learn its capabilities. We’d love to help. Talk to us in the Cireson Community.

This blog has been updated from its original 2018 version, Tips from the Trenches: SCSM Best Practices from 5+ Years of Experience & Expertise. Need additional help with problems like this? Talk to us!

Experience Teams Ticketing Today

Start your 14-day free trial of Tikit. No credit card required.