Thursday, January 3, 2013

OM12 SP1 Upgrade Schema & Say Hello To tAP…

When you’re still running a SCOM 2007 R2 environment and have all the required System Center 2012 licenses in place for upgrading to OM12 but waited for Service Pack 1 to arrive, you have an upgrade path ahead of you which isn’t a one stop process.

What You Hoped For But Won’t Get
This upgrade path isn’t possible: SCOM 2007 R2 > OM12 SP1.

Main reason here is that SP1 for OM12 RTM modifies the OM12 databases to such an extend that a direct upgrade from SCOM 2007 R2 to OM12 SP1 isn’t possible. Another reason here are the supported versions of Windows Server OS and SQL Server.

What You Get Instead
This is the way (and only supported one as well!): SCOM 2007 R2 > OM12 RTM > OM12 SP1.

This upgrade process has two stages where the first stage is the most challenging one since many ‘old’ SCOM 2007 R2 environments run Windows 2003 Server and use SQL Server 2005. Both versions (Server OS and SQL Server) aren’t supported by OM12 RTM.

So these issues have to be addressed first before upgrading to OM12 RTM. When you have dealt with this and your ready to upgrade from SCOM 2007 R2 to OM12 RTM, follow this series of postings all about that.

When that OM12 RTM environment is in place and fully healthy and functional, the upgrade to OM12 SP1 is almost a walk in the park, read this posting of mine all about that process.

The Alternative Approach (tAP)
Sometimes however it’s better to start brand new. So along side the existing SCOM 2007 R2 environment a new OM12 SP1 environment is created. Saves a lot of time when the existing SCOM 2007 R2 environment requires many upgrades to another SQL Server version and Windows Server OS.

Also with OM12 SP1 one can run SQL Server 2012 and Windows Server 2012. Both versions are fully supported by OM12 SP1 only, so these version can’t be implemented before OM12 SP1 is in place. And one installs OM12 SP1 for the long term strategy so it’s important to use versions of Windows Server OS and SQL Server which are current and will stay main stream for the first years to come…

Why Using tAP?
For some of my customers I have written business cases why to opt for tAP (the Alternative Approach). Simply the time (resources and budget) required to upgrade the SCOM 2007 R2 environment to the supported (but yet ‘old’ Window Server OS and SQL Server versions) created a No Go.

Instead within a few days a brand new OM12 (RTM or SP1) environment was designed, implemented and configured. Since OM12 Agents are capable of communicating with SCOM 2007 R2 environments, the ‘migration’ from SCOM 2007 R2 went smooth and without any serious issues at all. Per week some components being monitored by SCOM 2007 R2 were moved to OM12 instead.

This saved my customers valuable time, resources and budget and enabled them to focus on their core business instead. A WIN-WIN situation.

4 comments:

devon said...

but, when using tAP don't you then lose all your DW history? or do you have a process to migrate all the historical data to the new 2012 DW ?

Marnix Wolf said...

Hi Devon.

Yes, you'll loose all historical data as there is no supported process to migrate your data to the new 2012 DW. Only some workarounds at best.

Cheers,
Marnix

Unknown said...

Thanks Marnix. Great write up. I have used the tAP method but how do i remove the old management group (AD Integration used)on all my servers? For now i login to the servers one by one but then i have over 800 servers here.

I will appreciate your support on this.

Marnix Wolf said...

Hi Lara.

Try this posting, since it will help to remove the agent through the cmd line. Also to remove the agwnt from a certain Mg. http://www.bictt.com/blogs/bictt.php/2011/05/31/scom-trick-19-remove-agent