locked
SCCM 2012 Reporting point and SQL server migrations RRS feed

  • Question

  • Just migrated our SCCM Site server from a 2008 R2 O/S VM server to a 2012 R2 O/S VM server re-using the same server name, IP and site code etc and also upgraded to version 1511.  But we are also still using a 2008 R2 O/S VM server running SQL 2008 R2 where all of our SCCM  Databases etc live.  We want to migrate our Reporting server and SQL servers to 2012 R2 O/S VM's next and also be using SQl 2014.

    My question is can I or should I try to reuse the same IP and server names when I do this migration or do I need to use new IP and server names.  Also since we want to upgrade our SQL2008 R2 Software to SQl 2014 for both the SQL Server and Reporting points reporting services. What is the best way to do that?

    Does anyone have any recommendations.. Best Practices on how to get there?   Least amount of Heartburn...  Thanks in advance for any recommendation...

    Thursday, October 27, 2016 3:52 PM

Answers

  • For SQL Server, it's best to use a new server name and instance as there is a built-in procedure for this: https://blogs.technet.microsoft.com/configurationmgr/2013/04/02/how-to-move-the-configmgr-2012-site-database-to-a-new-sql-server/

    Reporting is trivial, just remove the existing SRP and install a new one -- there's nothing ConfigMgr specific to migrate and SSRS is a stateless component. You need to manually copy any custom reports though from the old to the new SSRS instance. You will lose any report subscriptions as there simply is no built in functionality in SSRS to move these. If you have a lot of these, you can consider moving the actual SSRS DB (named ReportServer by default) but that would be a better subject for a SQL or SSRS forum as that is specific to SSRS and not ConfigMgr.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Marked as answer by BRCS Friday, October 28, 2016 4:15 PM
    Thursday, October 27, 2016 5:55 PM
  • > "Will that work if I install SQL 2014 on the new reporting point server but continue to use SQL 2008 R2 on our SCCM Site Database server?"

    Yes. They are really two separate components that have no hard dependencies on each other.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Thursday, October 27, 2016 7:17 PM

All replies

  • For SQL Server, it's best to use a new server name and instance as there is a built-in procedure for this: https://blogs.technet.microsoft.com/configurationmgr/2013/04/02/how-to-move-the-configmgr-2012-site-database-to-a-new-sql-server/

    Reporting is trivial, just remove the existing SRP and install a new one -- there's nothing ConfigMgr specific to migrate and SSRS is a stateless component. You need to manually copy any custom reports though from the old to the new SSRS instance. You will lose any report subscriptions as there simply is no built in functionality in SSRS to move these. If you have a lot of these, you can consider moving the actual SSRS DB (named ReportServer by default) but that would be a better subject for a SQL or SSRS forum as that is specific to SSRS and not ConfigMgr.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Marked as answer by BRCS Friday, October 28, 2016 4:15 PM
    Thursday, October 27, 2016 5:55 PM
  • Will that work if I install SQL 2014 on the new reporting point server but continue to use SQL 2008 R2 on our SCCM Site Database server? This is also where the ReportServer and ReportServerTempDB databases are stored. I have read that I would run into a issue due to different version of SQL in use.

    Would it be better to use SQL 2008 R2 to install SQL Reporting Services on the new server then upgrade the SQL 2008 R2 Reporting services to SQL 2014 Reporting Services after I upgraded the SCCM site database server to SQL 2014?  Not sure what is the best way to go.

    Thursday, October 27, 2016 6:39 PM
  • > "Will that work if I install SQL 2014 on the new reporting point server but continue to use SQL 2008 R2 on our SCCM Site Database server?"

    Yes. They are really two separate components that have no hard dependencies on each other.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Thursday, October 27, 2016 7:17 PM
  • Thanks for your Help!
    Friday, October 28, 2016 4:18 PM