Menu Close

Upgrade from SCOM 2012R2 to SCOM 2016 Checklist

image

As many customers prepare to move to SCOM 2019, one thing I have been hearing is how many customers are still on SCOM 2012R2.  There is no direct in-place upgrade path from SCOM 2012R2 to SCOM 2019.  You have to upgrade 2012R2 > 2016 > 2019.  Many years ago I wrote an in-place upgrade checklist for SCOM 2012R2 to SCOM 2016, and realized it was never published, and might help some customers during this transition. 

Here goes!

 

1. Verify we are moving from a supported version of SCOM to SCOM 2016.

2. Verify the SQL server versions and service pack levels are supported for both SCOM 2012 R2 and SCOM 2016

3. Verify all OS versions for SCOM server roles will be supported for SCOM 2012 R2 and SCOM 2016

4. Verify all server roles meet minimum hardware sizing for SCOM 2016

5. Verify all agent managed Operating Systems are supported for SCOM 2016.

6. Verify all management packs in use are supported for SCOM 2016.

  • Check with 3rd party MP vendors and ensure their MP does not have any known support issues with SCOM 2016. Update these MP’s in advance if required.

7. SCOM Database: Verify the OperationsManager database has more than 50 percent free space

8. Optimize Registry settings for management servers

9. Export and review the SCOM management server event logs on all management server roles

  • Look for critical and warning events that indicate major issues that should be resolved before upgrading.
  • Save these for comparison after the upgrade to verify any new issues are actually new

10. Verify SCOM is healthy

  • Review the “Management Group Health” dashboard in addition to the event logs and ensure all issues are managed

11. T-SQL: Clean up the database ETL table in the OperationsManager database

12. SCOM Console: Remove agents from Pending Management

13. Backup unsealed management packs

  • Get a fresh backup of all your unsealed MP’s which contain all your customizations, for disaster recovery
  • Example:    Get-SCOMManagementPack | where {$_.Sealed -eq $false}|Export-SCOMManagementPack -Path c:\mpbackup

14. SCOM Console: Disable Notification subscriptions

15. Disable product connectors or any external connections to the SDK.

16. Stop the Operations Manager services on Management servers

  • Stop the following services on all management servers in the management group, to ensure NO changes are being made to SQL, so we can get a good backup right before the upgrade:
  • Microsoft Monitoring Agent
  • System Center Data Access
  • System Center Configuration

17. Backup the SCOM databases

18. Backup the Management Servers

  • Take a VM snapshot or a full bare-metal backup that is restorable, with the SCOM services stopped, so there should be no transient data. This will be for use in the case of disaster recovery only.

19. Install SCOM prerequisites on management servers with consoles

20. Ensure .Net 3.5, and .Net 4 (or 4.5) are both installed on all management servers

21. Remove any old SDK reference software from the management server

  • Some programs install DLL’s that might block upgrade, consider removing them if installed on your management servers:
  • SCOM 2007 R2 Authoring Console
  • Silect MP Author/MP Studio

22. Optional – uninstall the SCOM Console and Web Console on the FIRST management server you plan to upgrade and REBOOT.

  • Removing these roles reduce the risk of an upgrade failure.
  • These roles are easy to reinstall once the management group upgrade is completed.
  • A REBOOT of all servers before attempting an upgrade is recommended. It is hard to know what patches might have been applied already pending reboot, and you want to ensure that the server can reboot reliably before attempting an upgrade.

23. Optional – Restart the SQL server service on the OpsDB server and DW server

  • This will kill any stuck or old blocking processes, and free up any buffer cache
  • Wait at least 5 minutes after restarting to ensure the DB’s are online and functioning.
  • Ensure there is no active blocking in the OpsDB before continuing.
  • Consider a reboot.

24. Upgrade the first management server

25. Upgrade additional management servers

  • It is CRITICAL not to upgrade multiple management servers at the same time. You should wait for one to complete FULLY and inspect the logs to ensure it is working, before continuing with the next.

26. Upgrade ACS (if applicable)

27. Upgrade all gateways (if applicable)

28. Upgrade Stand Alone Web Console servers (if applicable)

29. Upgrade Reporting Server

30. Upgrade Stand-Alone Consoles

31. Post Upgrade tasks

32. Reject Pending Management updates for any agents

  • We will update agents later, after applying the latest Update Rollup.

33. Fix scheduled maintenance mode permissions

34. Verify your SCOM license is reporting correctly as licensed

35. Apply the latest Cumulative Update Rollup for SCOM 2016

  • You should wait 24 hours after an upgrade from SCOM 2012R2 before applying the latest SCOM 2016 update rollup. There are scripts as part of the upgrade that can take several hours to complete, and it is a best practice to not interrupt these.

36. Upgrade Agents

  • Using whatever method you choose, consider upgrading your agents to SCOM 2016 with the latest UR at this point.
  • Be cautious of the APM issue in SCOM 2016 agent:
  • Reference:  https://kevinholman.com/2017/08/05/reinstalling-your-scom-agents-with-the-noapm-switch/
  • The APM issue is resolved in current Update Rollups for SCOM, but this must be applied immediately after deploying a SCOM 2016 agent if you have not removed the APM MP’s as discussed in the article above.  If you do not use APM, I recommend removing those MP’s.

3 Comments

  1. Sarah

    Hi Kevin,

    What are the rollback procedure and how could we restore to old environment in case of any issues while performing up gradation. Please pour your thoughts. Thanks .

    • Kevin Holman

      The rollback procedure will be somewhat customer specific on how you do backup/restore/protection. However, generally speaking, the rollback is to restore your management servers/gateway/reportingservers (from backup and/or VM snapshot) and then restore your SQL databases from a SQL backup (OperationsManager, OperationsManagerDW, and ReportServer)

Leave a Reply

Your email address will not be published. Required fields are marked *