SCSM 2016 upgrade path assistance for unique scenario...
We plan to upgrade our SCSM 2012 R2 environments to SCSM 2016 soon, so I’m just exploring our options and documenting the process at this point, but I’ve hit a bit of a snag in terms of upgrade path and I was hoping to get some advice.
We moved all of our Service Manager databases (ServiceManager and DW databases, SSAS, and SSRS) to SQL 2014 last year (not an easy feat, but we finally got everything working), however our SCSM management servers (Primary/Secondary/Data Warehouse) still run on Windows Server 2008 R2. So our environments look similar to this now:
Server1 is the SCSM Primary Management Server (running Windows Server 2008 R2)
Server2 is the SCSM Secondary Management Server (running Windows Server 2008 R2)
Server3 is the SCSM Data Warehouse Management Server (running Windows Server 2008 R2)
Server4 is the SCSM SQL Server for ServiceManager DB (running SQL Server 2014 and Windows Server 2012 R2)
Server5 is the SCSM SQL Server for Data Warehouse DB’s, SSAS, and SSRS (running SQL Server 2014 and Windows Server 2012 R2)
The problem I see is this – Microsoft documentation for SCSM 2016 upgrade states that the only supported method for upgrade is an IN-PLACE upgrade, which is fine, but in our case we can’t do an in-place upgrade yet because the documentation also states that SCSM 2016 is supported only on Windows Server 2012 and above, so we need to first move our SCSM management servers to Windows Server 2012 before we can do the SCSM 2016 upgrade. However, seeing that our databases are now on SQL Server 2014, that presents some issues for us because SQL Server 2014 is supported only on SCSM 2012 R2 UR6+, and Microsoft didn’t bother to update the installation bits so that new management server installs could make use of SQL Server 2014.
So we know that we can use this process coupled with this process to stand up new Primary and Secondary management servers on Windows Server 2012 (and retire the Windows Server 2008 management servers), however, we’re not sure how to proceed with the move to Windows Server 2012 for the Data Warehouse management server. Ideally, we would just unregister the current Windows Server 2008 DW Management Server, install a new DW Management Server on Windows Server 2012 server (but connect the installation to the current DW databases) and then register it in SCSM, however, the DW Management Server installation bits will not allow us to connect to SQL Server 2014 to connect to our current DW databases. Although this is a supported configuration we’re in, as far as I can tell there isn’t any documentation available from Microsoft that speaks to the SCSM 2016 upgrade path for this scenario.
Some options we’ve considered:
- Move all SCSM DW databases, SSAS, and SSRS back to SQL 2012 so we can upgrade to Windows Server 2012 for the DW Management Server, and then put all the SQL stuff BACK on to SQL Server 2014 (hoping there’s an easier way – what a headache!)
- Maybe we could upgrade the DW Management Server to SCSM 2016 even though it’s on Windows Server 2008 R2 (even though Microsoft says Windows 2008 R2 is not a supported platform), just long enough to then be able to stand up a new DW Management Server on Windows Server 2012 ??
We really appreciate your assistance with this.
Answers
We actually only recommend a side by side migration to 2016! Its the best way to keep the bits you like from the old environment and get rid of or revise processes, settings, etc that you don't! The support statement from Msft is just that they don't provide a migration tool.
Also, as far as I'm aware, all the 2016 upgrades performed by our consultancy teams have been migrations. So you could set up the new environment in exactly the way you want with all the latest supported versions of OS and SQL and migrate the bits you want from the old environment.
You may also know that one of our latest applications (the Cireson Lifecycle Management app here) is designed to support these migrations? It won't move the DW but often customers will just keep the 2012 DW as a historical, separate, reporting database and start new in 2016- not sure that would work for you?
I know I haven't answered your technical questions specifically (I must be honest and say I don't know!) but can confirm that we do recommend migrations to our customers. Hope that helps...?
Davis