locked
SCCM ConfigMgr 2012 R2 upgrade path to ConfigMgr Version 1602 RRS feed

  • Question

  • In my environment we have the following deployed:
    ConfigMgr 2012 R2 (5.00.7958.1000) (no CU’s)
    And would like to take it up to ConfigMgr Version 1602 (5.00.8355.1000)

    I’m assuming my path would be:
    ConfigMgr 2012 R2 SP1 (5.00.8239.1000)
    ConfigMgr Version 1511 (5.00.8325.1000)
    ConfigMgr Version 1602 (5.00.8355.1000)

    And for each stage would have the following sub steps
    A. Pre-Upgrade Configurations for Configuration Manager Sites
    B. Test the Configuration Manager Site Database for the Upgrade
    C. Upgrade a Configuration Manager Site
    D. Perform Post-Upgrade Tasks on Configuration Manager Sites

    as per https://technet.microsoft.com/en-us/library/jj865691.aspx or similar articles.

    Question(s):
    At what point do I have to upgrade the client on all my workstations?
    Can I leave the client at the ConfigMgr 2012 R2 level (5.00.7958.1000) until I have the server at ConfigMgr Version 1602, and then send out an update client command?
    Or do I have to get the clients up to each level before proceeding to the next upgrade? (which would mean add a week or two between each upgrade.)
    I would like to do this in a day or over weekend and not have to worry about the clients until done.
    Will the “old” clients talk to an updated server with out issues? I understand new features would not be enabled, but would all old features still be active?

    Thanks in advance for the help.


    Virtual Samurai - MCP, CCNA

    Wednesday, April 27, 2016 6:29 PM

Answers

  • You can go directly from 2012 R2 to 1511, which is the base version for CB, and then to 1602 using the new Site Servicing.

    At what point do I have to upgrade the client on all my workstations?
    Can I leave the client at the ConfigMgr 2012 R2 level (5.00.7958.1000) until I have the server at ConfigMgr Version 1602, and then send out an update client command?
    Or do I have to get the clients up to each level before proceeding to the next upgrade? (which would mean add a week or two between each upgrade.)
    I would like to do this in a day or over weekend and not have to worry about the clients until done.
    Will the “old” clients talk to an updated server with out issues? I understand new features would not be enabled, but would all old features still be active?

    You can update your Clients, when you are on 1602. The existing 2012 R2 Clients will work normally, with an upgraded Environment. As you stated, you have no new functionallity until you updated the clients. Daily Tasks like Software Distribution, Updates, etc. will operate as before. However, having a lower Client Version is not ideal for long term usage, so you should update them soon after you hit 1602.


    Simon Dettling | msitproblog.com | @SimonDettling


    Wednesday, April 27, 2016 6:40 PM

All replies

  • You can go directly from 2012 R2 to 1511, which is the base version for CB, and then to 1602 using the new Site Servicing.

    At what point do I have to upgrade the client on all my workstations?
    Can I leave the client at the ConfigMgr 2012 R2 level (5.00.7958.1000) until I have the server at ConfigMgr Version 1602, and then send out an update client command?
    Or do I have to get the clients up to each level before proceeding to the next upgrade? (which would mean add a week or two between each upgrade.)
    I would like to do this in a day or over weekend and not have to worry about the clients until done.
    Will the “old” clients talk to an updated server with out issues? I understand new features would not be enabled, but would all old features still be active?

    You can update your Clients, when you are on 1602. The existing 2012 R2 Clients will work normally, with an upgraded Environment. As you stated, you have no new functionallity until you updated the clients. Daily Tasks like Software Distribution, Updates, etc. will operate as before. However, having a lower Client Version is not ideal for long term usage, so you should update them soon after you hit 1602.


    Simon Dettling | msitproblog.com | @SimonDettling


    Wednesday, April 27, 2016 6:40 PM
  • Thanks for the quick reply.

    I have a follow up question. What would be an appropriate rollback strategy? Our change management always requires one if applicable. Would a rollback be applicable? And if so could it look like below?

    I’m thinking just prior I have our database team take a backup of the database, needed for the “test database” step anyways. Then take a snapshot of the SCCM server, as it’s a VM. Then go through the update process. Once at 1611 confirm basics. – Old and new clients talk with and take commands from server. (remote control works, can install new apps/packages, can install updates) If I can’t get that to work in a reasonable amount of time, roll back. So have to get the database team to restore the backup database, and on the SCCM server VM revert the snap shot. Then correct any machines with new client installed.

    I see this as highly unlikely to be needed, but would that be a workable plan?


    Virtual Samurai - MCP, CCNA


    Monday, May 2, 2016 6:30 PM
  • A snapshot could/would do more harm than good generally -- it depends upon where all of your roles are located but they are explicitly unsupported by Microsoft.

    A DB backup along with a full backup of all required items per the normal backup procedures as outlined on TechNet is sufficient to perform a rollback.


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

    Tuesday, May 3, 2016 1:47 AM