SCSM Apps

User Guide: SCSM Lifecycle Management Best Practices

This article applies to: Cireson Lifecycle Management, v1.1 and above.

Overview

The Cireson Lifecycle Management (also known as "LMA") app allows for users to complete a migration of key components from one instance of System Center Service Manager (SCSM), to another instance located on a separate server. These components includes work items, management packs, templates, configuration items, and other settings that are crucial to their organization.

The following are best practices for a SCSM 2012 to SCSM 2016 migration, in order to ensure that it is complete, successful, while minimizing errors or issues.

 

SCSM Installation

  1. You will want to make sure that both the Source SCSM Server along with the Target SCSM Server have been allocated sufficient resources for the migration.
    • LMA will use a decent amount of memory and CPU on the target server. The exact amount depends on the number of objects, the type of objects, and if multi-threading mode is enabled within LMA.
    • If SQL is installed on the same server as the target server, make sure to limit memory usage within SQL Management Studio. If the target server is unable to allocate enough memory for the SCSM SDK service, then LMA operations will become terrifyingly slow.
    • For production server specs, see Microsoft's hardware guide: https://docs.microsoft.com/en-us/system-center/scsm/sm-sys-reqs . 

  2. Confirm that SCSM (whether 2012, or 2016) is fully functional, with the latest rollup updates installed on both servers.

Connectors and Channels

  1. Confirm that connectors on both the source and the target SCSM Servers are created and properly confirmed to bring in the required data. Connectors will bring in CI data, and allows LMA to use the existing resources instead of creating new ones, resulting in faster, more efficient copies. This list of connectors most commonly includes:
    1. One or more AD Groups connectors, which have an LDAP filter for Active Directory Groups.
    2. One or more AD Users connectors, which have an LDAP filter for Active Directory Users, such as enabled user accounts.
    3. One ConfigMgr connector.
    4. One Orchestrator connector, if using runbooks.
    5. One or more Exchange connectors.
    6. Any other manually-created connectors, such as a CAM Import connector using CSV or SQL data.
    7. Many environments do not have an Active Directory Computers connector, as the ConfigMgr connector will bring in the desired relevant computer CI data. This varies per environment.

  2. Create your new user roles in the target SCSM Server prior to completing a migration. LMA does not copy user roles at the moment. Thus, these must be created manually.

  3. Create the notification channel on your Target SCSM Server. LMA will not copy over the notification channel.

  4. Once the notification channel is created in your Target SCSM Server, disable it. Common notification subscriptions occur during work item creation, such as emailing the affected user that their work item has been created. By disabling the notification channel, these subscriptions will still fire, but will not send any email, and will generate an error in the event log saying that the notification channel is disabled. The emails will not attempt to resend after the notification channel is re-enabled.

  5. If you have a connecting System Center Configuration Manager environment, ensure that the ConfigMgr connector is not running during the migration process. This will have a negative impact on overall system performance, and potentially create issues during the migration process. .

Management Packs

  1. If you are performing a migration from SCSM 2012 to SCSM 2016, if you have Management Packs that are SCSM 2012-dependent, import only the 2016-dependent Management Pack manually. Do not import or migrate the 2012 Management packs. This may require you to perform a manual migration of the Management pack to ensure issues do not arise post-migration.
    1. Several UI components have changed between SCSM 2012 and SCSM 2016. Several SCSM 2012 versions of forms, such as Cireson Settings in Administration > Settings, will not work when imported into SCSM 2016. This also includes custom management packs, such as task customizations created for SCSM 2012 which may or may not work within the SCSM 2016 console.
    2. LMA will copy management packs, but it will not upgrade them to a 2016 version. However, if a newer/upgraded version of the management pack exists on the target server, then LMA will ignore that MP and will not try to import it.
    3. Templates that use a SCSM 2012 form customization may not be able to be opened from an SCSM2016 console. For example, a service request form created with the SCSM 2012 authoring tool will open properly in SCSM 2012, but may not open properly on SCSM 2016.

  2. LM App > Migrate Management Packs and Settings
    1. Ensure that all sealed and unsealed management packs imported successfully. Review the log file for specific exceptions that may have occurred.
    2. LMA uses the Microsoft SDK to export management packs. If a management pack fails to import, then try to import it manually into the target environment. The target environment will very likely give you the same exception that LMA provided, which lets you verify if the management pack itself is problematic.
    3. Some management pack errors have multiple failure exceptions. Be sure to read all exceptions listed for a particular management pack, not just the first one.
    4. Optionally back up the Service Manager database.

  3. LM App > Migrate Configuration Items
    1. Primary CIs like users and computers are normally imported via a connector. But LM App can import them instead.
    2. Common configuration items include Business Services, Knowledge Articles, custom classes, and Cireson Asset Management classes.
    3. Optionally back up the Service Manager database.

Work Items

  1. Before copying work items, stop the 'Microsoft Monitoring Agent' (HealthService) workflow service on the target environment's SCSM workflow server. This prevents the workflow engine from processing default workflows while LM App is creating work items. When copying a large number of work items, this will have a significant negative impact on workflow performance and simultaneously will drastically slow down LMA while committing new work items on the target server.

  2. LM App > Migrate Work Items
    1. For large data sets (500+ work items per class) It is best to migrate work items one class at a time. For enterprise-class data sets (5000+ work items per class) it is best to migrate work items in blocks based on date.
    2. Remember, once the work items are migrated, and the workflow engine is re-enabled, it will process all of the work items. Depending on your hardware, your workflow server CPU will be busy processing internal workflows for several hours. Also, depending on your SQL hardware, disk speed and disk space may need to be monitored. 
    3. When copying large data sets in batches, it is recommended to start the previously-stopped Microsoft Monitoring Agent service between certain batches (~20,000 work items, depending on hardware). This will allow internal workflows to run catch up. Otherwise, enabling the service after tens of thousands of work items are copied will tax the workflow server and SQL server longer than necessary.. Once the Operations Manager event log has stopped posting an influx of events/warnings, then it is safe to re-stop the service and resume LMA copies.
    4. Also note, the workflow engine is responsible for assigning and relating SLO Time Instance objects to work items. LMA does copy the SLO objects (Administration > Service Level Management > Service Level Objects). But the target server's workflow engine is responsible for applying these SLO objects to each work item.
    5. Optionally back up the Service Manager database.

Post-Migration

  1. Review the LMA log file(s). Search for any lines that start with the word "Exception:" throughout the file, or any listed exceptions at the end of the log file.

  2. Enable the Microsoft Monitoring Agent service

  3. Review the target server's Operations Manager event log.
    1. Ensure that there are no errors in the event log.
    2. Ensure that the workflow engine has caught up, and that there are no recent warnings about CMDB Subscriptions being slow.

  4. Enable your notification channels.
  5. If you use the Cireson Portal for Service Manager, you can go ahead and install the portal on the target server.

Common Errors

  1. LMA will sometimes crash with a "System.OutOfMemory" exception. This usually happens when the target server is out of memory, and LMA cannot allocate a continuous block of memory for a specific object. This can also happen when the machine that LMA is running on, which could be the source server, target server, or an in-between workstation, does not have enough memory to process objects. 

Further Reading

KB1354 - User Guide: SCSM Lifecycle Management