Hi all,

I was recently tasked by my boss to upgrade our 2012 R2 environment to 2016, amongst other things we’re going to need it for some screenshots and testing later on so we needed to get it done.  This is my experience of it and I thought I’d share it with you as it will probably something you are tasked to do in the near future.

From now on I’ll be generally posting the blog to my company site (http://www.poweronplatforms.com/news-and-blogs/) and my personal blog site (http://damianshiell.co.uk)

 

Starting place

So with any upgrade for Ops Mgr. I normally check out the TechNet article that’s published:

https://technet.microsoft.com/en-us/system-center-docs/om/deploy/upgrading-to-system-center-2016-operations-manager

 

So in summary the hi level is before we : 

  • Check Build Number to ensure we’re at UR9 or above
  • Check Sequencing Order for other components for System Center
  • Upgrading a distributed management group – order of execution

 

Now I’m doing this Upgrade out of order as we need to get this done but in general you would need to upgrade the existing components of System Center in the environment first and that would be:

 

  1. Configuration Manager
  2. Data Protection Manager
  3. Orchestrator
  4. Operations Manager
  5. Virtual Machine Manager

 

Build Numbers

First off – check your UR level of Operations Manager – it should be at least UR9. Previous blogs have covered this such as <Link to Kev Holman’s Blog here> but essentially you need to have a build number of 1177 or greater.

A really good resource for build numbers is:

https://buildnumbers.wordpress.com/scom/

clip_image001[4]

Essentially you’re looking for at least a file version of 1177 on the core files in the following directory on your Management servers:

%Installation Directory Path%\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server

clip_image002[4]

Order of Execution for Upgrading

If you have done any sort of UR Upgrades before you will notice that this is more similar to that procedure than what we saw when upgrading from 2007 R2.

High level overview of System Center 2016 Operations Manager upgrade steps for a distributed management group

The following steps outline the process for upgrading a distributed management group:

  1. Accomplish Pre-Upgrade Tasks
  2. Upgrade the initial management server and then additional management servers (each management server must be upgraded)
  3. Upgrade ACS (because the ACS server must be on same machine as a management server, we recommend you perform this step along with the upgrade of the management server on which ACS resides.)
  4. *Upgrade Gateway(s)
  5. Upgrade Console
  6. Push install to agent(s) / upgrade manually installed agents
  7. Upgrade Web Console
  8. Upgrade Reporting Server
  9. Perform Post-Upgrade Tasks

*Steps 4 through 8 can be performed in parallel after all management servers have been upgraded.

 

 

Pre-Upgrade Tasks

https://technet.microsoft.com/en-us/system-center-docs/om/deploy/pre-upgrade-tasks-when-upgrading-to-system-center-2016-operations-manager

The following actions are required and I tend to create a checklist to mark what I’ve done 🙂

  • Review the Operations Manager Event Logs
  • Errors found – investigating
  • Clean-up the Database (ETL Table)
  • Configure agents to failover between multiple gateway servers so all agents reporting to a gateway have a failover gateway assigned.
  • Remove Agents from Pending Management
  • Disable Notification Subscriptions
  • Disable any connectors
  • Stop the Microsoft Monitoring Agent, System Center Data Access Service, System Center Configuration Management and Microsoft Monitoring Agent services on all management servers except the one being upgraded
  • Verify that the Operational Database Has More Than 50 Percept Free Space
  • Back up the Operations Manager Databases
  • Update the agent’s health service cache size temporarily to prevent loss of data while Management and Gateway servers are upgraded.
  • Disable the Operations Manager website in IIS.
  • Review the Operations Manager Event Logs

 

Clean-up the Database (ETL Table)

 

So from the TechNet article – there is an instruction to clean up the ETL table on the OpsManager Database so opened up a SQL Management Studio session and ran the following script:

 

— (c) Copyright 2004-2006 Microsoft Corporation, All Rights Reserved —
— Proprietary and confidential to Microsoft Corporation —
— File: CatchupETLGrooming.sql —
— Contents: A bug in the ETL grooming code could have left the customer —
— Database with a large amount of ETL rows to groom. This script will groom —
— The ETL entries in a loop 100K rows at a time to avoid filling up the —
— Transaction log —
———————————————————————————
DECLARE @RowCount int = 1;
DECLARE @BatchSize int = 100000;
DECLARE @SubscriptionWatermark bigint = 0;
DECLARE @LastErr int;
— Delete rows from the EntityTransactionLog. We delete the rows with TransactionLogId that aren’t being
— used anymore by the EntityChangeLog table and by the RelatedEntityChangeLog table.
SELECT @SubscriptionWatermark = dbo.fn_GetEntityChangeLogGroomingWatermark();
WHILE(@RowCount > 0)
BEGIN
DELETE TOP(@BatchSize) ETL
FROM EntityTransactionLog ETL
WHERE NOT EXISTS (SELECT 1 FROM EntityChangeLog ECL WHERE ECL.EntityTransactionLogId = ETL.EntityTransactionLogId) AND NOT EXISTS (SELECT 1 FROM RelatedEntityChangeLog RECL
WHERE RECL.EntityTransactionLogId = ETL.EntityTransactionLogId)
AND ETL.EntityTransactionLogId < @SubscriptionWatermark;
SELECT @LastErr = @@ERROR, @RowCount = @@ROWCOUNT;
END

Ran the above script and got the following output:

clip_image009[9]

 

Configure agents to failover between multiple gateway servers so all agents reporting to a gateway have a failover gateway assigned.

N/A in our environment

 

Remove Agents from Pending Management

None in our environment

 

Disable Notification Subscriptions

None in environment

 

Disable any connectors

Disabled the Connectors from the Service Manager Perspective

clip_image010[9]

 

Stop the Microsoft Monitoring Agent, System Center Data Access Service, System Center Configuration Management and Microsoft Monitoring Agent services on all management servers except the one being upgraded

So I did this across all the Management Servers (5 in our environment – will be reducing this at some point as not needed any more!)

This step is required so there are no calls to either database whilst it is being upgraded.

 

Verify that the Operational Database Has More Than 50 Percept Free Space

This should be a pretty common exercise for anyone who has done a UR before but if not again within your SQL Management Studio session, right click on the Operations Manager Database, choose Reports –> Disk Usage and the following Report is generated:

 

Standard SQL Size Report for the OpsDB

clip_image011[9]

Also checked the DW DB

clip_image012[9]

As you can see All fine 🙂

 

Back up the Operations Manager Databases

Completed

 

Update the agent’s health service cache size temporarily to prevent loss of data while Management and Gateway servers are upgraded.

Not undertaking due to type of environment & amount of data  – if this was a full size production environment I would potentially still skip as the amount of down time the Management Group is down for is minimal (about 1 – 2 hours at most)

 

Disable the Operations Manager website in IIS.

Disabling the Website

 

 

Upgrade Procedure

 

Logged onto my main Management Server (Running the RMSe role)

Ran the install media & downloaded the UR1 Update files

clip_image013[9]

Following Splash screen appeared

clip_image014[9]

Accept the Terms and sign your life away:

clip_image015[9]

Choose the appropriate Installation Location:

clip_image016[9]

clip_image017[9]

The next screen shows us we have a new requirement around the report viewer controls which is Report Viewer Runtime 2015. This in turn also has a dependency on SQL CLR Runtime 2014 so both will be required to be downloaded

Links http://go.microsoft.com/fwlink/?LinkId=816564

SQL CLR 2014 Runtime hides within the SQL Server Feature Packs, 2014 edition!

https://www.microsoft.com/en-us/download/details.aspx?id=42295

Click download as usual:

clip_image018[9]

Scroll down until you find “SQLSysClrTypes.msi – yes we do need the 64 bit version 🙂

clip_image019[9]

Save it, run it and install it.

You won’t get prompted for Install paths etc. as the existing SQL components dictate where this install will end up.

Then do the same for the Report Viewer Runtime 2015

Click “Verify Prerequisites Again”

clip_image020[9]

Enter the SAME Credentials as the Existing DAS Account otherwise you will have serious issues later on:

clip_image021[9]

Confirm the details are correct and then run the upgrade:

clip_image022[9]

A very familiar screen will appear:

clip_image023[9]

And should hopefully end like this:

clip_image024[9]

But mine ended up like this:

clip_image025[9]

Okay – I thought we were running full fat here ?

No bother – I’ll check that out later – running through each of our additional Management Servers now:

This one has the Web Console Role on and is updated automatically:

clip_image026

clip_image024[10]

No ACS or Gateways in our environment so skipping those for the purposes of this install 🙂

Reporting Server – Need to Await the Management Server that it reports to to be upgraded first

Got this error:

clip_image027

Now the server is updated but not currently online – figuring this is the issue – all the servers needed a restart anyway 🙂

Still no joy, restarted the Reporting Server – No joy either.

Google became my pal when the following forum turned up a suggestion

https://social.technet.microsoft.com/Forums/systemcenter/en-US/c2c642e5-8dde-426c-a4ff-273e8a8a6102/the-management-server-to-which-this-component-reports-has-not-been-upgraded-scom-2016?forum=operationsmanagergeneral

Makes sense – the binaries cant connect to check the running data access service???

Rerunning it gives the following

clip_image028

Good – install the Report Viewer & SQL CLR and should be good to go 🙂

clip_image029

This installed and thus completed the install giving us a beautiful 2016 environment with Maintenance Mode, Alert Tuning, Network extensible monitoring …..

 

Post-Upgrade Tasks

https://technet.microsoft.com/en-us/system-center-docs/om/deploy/post-upgrade-tasks-when-upgrading-to-system-center-2016-operations-manager

 

 

I then took the opportunity to upgrade to UR1 which requires the normal UR upgrade procedure.   Lots of people have already blogged about that and the man himself Mr Holman always does a first rate blog and step by step which you can find here:

https://blogs.technet.microsoft.com/kevinholman/2016/10/22/ur1-for-scom-2016-step-by-step/

And the official Support and Catalog articles for UR1:

https://support.microsoft.com/en-us/help/3190029/update-rollup-1-for-system-center-2016-operations-manager

http://catalog.update.microsoft.com/v7/site/Search.aspx?q=3190029

 

All left to do at that point was to re-enable the connectors, subscriptions and check the system over and we have a 2016 Operations Environment ready for use 🙂

 

Hope that helps anyone planning or doing it with the errors I came across and if you need to get in touch Smile

Till next time, happy SCOMMING.

 

Damian

Operations Manager 2012 to 2016 Upgrade–My Experience
Tagged on:                 

Leave a Reply

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