locked
Can We Upgrade SCCM When it Has MSSQL Server Reporting Services v2008R2 ? RRS feed

  • Question

  • Hi,

    I've been planning an SCCM upgrade from v1610 to v1702 (or whatever Current Branch is).  The problem we have is the CM database and the MSSQL Server Reporting Services DBs are on a server running MSSQL Server 2008 R2.  Now, I know I need to move the CM database to my new MSSQL Server as MSSQL 2008R2 isn't supported by SCCM Current Branch any more.  The question I have is, do I also need to move the Reporting Services DBs off 2008R2 as well, or does SCCM / MSSQL 2008R2 incompatibility only relate to the CM database ? 

    I suspect the answer will be that I do have to move the Reporting Services databases too.  If so, do I have to also upgrade the Reporting Services application on the SCCM site server too ?  This creates quite a few extra steps in the migration.  So is it like this ?

    1. Migrate the SCCM CM database to new MSSQL server and reconfigure CM to point to it accordingly.
    2. Migrate the SCCM SQL Reporting Services DBs to the new MSSQL Server.
    3. Upgrade the SCCM SQL Reporting Services application on the SCCM site server.
    4. Also migrate the WSUS databases to new MSSQL server and reconfigure WSUS to point to them accordingly.

    I'm not sure if steps 2 and 3 are in the right order, or are even correct.  Please can someone advise, especially if you've actually done this before.  Your help would be greatly appreciated!


    -- huddie71 ~~If you~re not seeking help or offering it, you probably shouldn~t be here.~~

    Thursday, July 26, 2018 1:07 PM

All replies

  • The latest production released build of CB is 1802 (although 1806 is right around the corner). 1610 hasn't been supported in well over a year so you definitely should move to a supported build ASAP.

    The SSRS DBs are irrelevant as ConfigMgr has no visibility into them, however, SSRS itself must be on a supported OS (don't confuse SSRS with the SSRS DBs, they are different).

    #2. Why not just rebuild SSRS? The SSRS DB doesn't contain anything of value except the reports themselves which can easily be exported if you have custom reports. If you have a lot of subscriptions (which are painful at best to export) then you'll definitely need to keep the existing DBs.

    #3. I don't know what you mean by "SSRS Application". ConfigMgr has an SRS Role and there is the actual SSRS install. If you installed the SSRS components (and ConfigMgr role) on the site server, then there's nothing more to do as I'm assuming it's on a supported OS as you haven't called out anything different here.

    #4. Same answer here ultimately. ConfigMgr doesn't have visibility or knowledge of where WSUS has its database.

    Keep in mind here also that SQL Server 2008 R2 has less than one year of life left -- end of life is July 2019. So ultimately, yes you need to move the DBs for those components (WSUS and SSRS) but that is independent of ConfigMgr.


    Jason | https://home.configmgrftw.com | @jasonsandys




    Thursday, July 26, 2018 2:12 PM
  • The latest production released build of CB is 1802 (although 1806 is right around the corner). 1610 hasn't been supported in well over a year so you definitely should move to a supported build ASAP.

    The SSRS DBs are irrelevant as ConfigMgr has no visibility into them, however, SSRS itself must be on a supported OS (don't confuse SSRS with the SSRS DBs, they are different).

    #2. Why not just rebuild SSRS? The SSRS DB doesn't contain anything of value except the reports themselves which can easily be exported if you have custom reports. If you have a lot of subscriptions (which are painful at best to export) then you'll definitely need to keep the existing DBs.

    #3. I don't know what you mean by "SSRS Application". ConfigMgr has an SRS Role and there is the actual SSRS install. If you installed the SSRS components (and ConfigMgr role) on the site server, then there's nothing more to do as I'm assuming it's on a supported OS as you haven't called out anything different here.

    #4. Same answer here ultimately. ConfigMgr doesn't have visibility or knowledge of where WSUS has its database.

    Keep in mind here also that SQL Server 2008 R2 has less than one year of life left -- end of life is July 2019. So ultimately, yes you need to move the DBs for those components (WSUS and SSRS) but that is independent <g class="gr_ gr_2083 gr-alert gr_gramm gr_inline_cards gr_run_anim Grammar multiReplace" data-gr-id="2083" id="2083">from</g> ConfigMgr.


    Jason | https://home.configmgrftw.com | @jasonsandys



    Jason, thanks for this very helpful and informative response.  When I say the Reporting Services application, I mean the SQL Server Reporting Services which is installed on the SCCM site server.  I assume this is what you mean by the SRS Role.  The trouble is the person who set all this up left our organisation before I started and didn't document it, so no build book, etc.  I'm having to work off what I can see by myself in the configuration.  I'm doing the site server database migration now and will leave other DBs and the upgrade until I'm more confident of how exactly I should handle them as part of the upgrade.

    I agree about the WSUS DB.  WSUS is a Win2012R2 role, so I can't see there being a problem there as SCCM won't be looking at it.


    -- huddie71 ~~If you~re not seeking help or offering it, you probably shouldn~t be here.~~

    Thursday, July 26, 2018 2:35 PM
  • > "When I say the Reporting Services application, I mean the SQL Server Reporting Services which is installed on the SCCM site server.  I assume this is what you mean by the SRS Role."

    No. Two different things. The role is specific to ConfigMgr and is basically a light layer of management for SSRS itself.

    > "I'm doing the site server database migration now and will leave other DBs and the upgrade until I'm more confident of how exactly I should handle them as part of the upgrade."

    As noted, there's nothing ConfigMgr specific about the WSUS and SSRS DBs as ConfigMgr doesn't know about them. ConfigMgr interacts with WSUS and SSRS through the API layers provided by these components.

    > "I'm having to work off what I can see by myself in the configuration."

    There's very little (if anything really) that can't be discovered by reviewing the configuration in the console.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Thursday, July 26, 2018 2:44 PM