locked
Jump from client 5.00.7958.1000 to client 5.00.8239.1301 RRS feed

  • Question

  • We move our Primary site from SCCM2012 R2  to SCCM2012 R2 SP1 CU2. 

    When we were doint this, we first did the SCCM2012 R2 SP1 that bring us the client 5.00.8239.1000
    Before even deploying to all my enviroment to that one (5.00.8239.1000)  , i went and place the CU2 update to the primary site (i got 5.00.8239.1301 after that).

    So i was trying to deploy the package CU2 KB3100144 - X64 to my all clients,   (to make going from  5.00.7958.1000 to 5.00.8239.1000) and i got a fail message (Error: 0x66A(1642).

    In order to make it work, i had first to install the 5.00.8239.1000 and then to 5.00.8239.1301.    Is this correct?  I had to first install the 5.00.8239.1000 and then the 5.00.8239.1301 ???  Is there a way to avoid it.

    Wednesday, January 27, 2016 5:56 PM

Answers

  • Ultimately, you must go to SP1 on the client first because CU2 is a patch for SP1 and thus doesn't apply to anything else; i.e., you can't just deploy CU2 (or CU1)

    The method Matt is talking about above though effectively "slipstreams" the CU into the SP1 client installation though so both can be done in one fell swoop. Notice in his install string he's using the PATCH property to specify the CU .msp file. This is simply taking advantage of Windows Installer's ability to install a patch (.msp file) at the same time as the product it applies to and is fully supported.

    Alternatively, you could do things in two passes, but IMO, using the PATCH property is the best way and certainly quicker.

    Do note that the location specified in the PATCH property must be fully qualified and so cannot be a relative location. Thus you either need to copy the .msp locally somewhere (as it appears Matt did for his command-line) or you need to place it on some universally accessible share that is accessible to the "Domain Computers" security group since this group automatically includes all computer accounts which is what will be used to access this location. This later won't work for non-domain joined computers though so keep that in mind also.


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

    Wednesday, January 27, 2016 7:21 PM

All replies

  • In order to make it work, i had first to install the 5.00.8239.1000 and then to 5.00.8239.1301. Is this correct?

    If you deploy the Client and the CU manually, Yes.

    Is there a way to avoid

    You should checkout Automatic Client Upgrade:

    http://blogs.technet.com/b/configmgrteam/archive/2015/08/04/automatically-updating-the-configuration-manager-client.aspx


    Simon Dettling | msitproblog.com | @SimonDettling


    Wednesday, January 27, 2016 6:22 PM
  • We jump from R2 to R2 Sp1 cu1 without incident.  What was your install string?

    Automatic upgrade is the way to go but if you are targeting a specific group then it might be complex like this

      SMSSITECODE="Auto" DNSSUFFIX="foo.com" CCMHTTPPORT="34" CCMHTTPSPORT="381" SMSCACHESIZE="40000" SMSCACHEDIR="C:\cachefolders\" PATCH="C:\ClientFolder\SCCM2012\configmgr2012-x64.msp"

    This is unique because we keep a copy of the client installs on the machine if needed for repairs, etc.

    So the package first copies the files to the client folder and then runs them from there, thus removing the sccm client cache from the mix. 


    http://www.sccm-tools.com http://sms-hints-tricks.blogspot.com

    Wednesday, January 27, 2016 6:38 PM
  • I uncheck the automatically update client, we were trying to do a more controled way to do it.  But if i got straight to CU2 i got a fail message(Error: 0x66A(1642), i google that error and it says that you got it when you are trying to install the wrong version. 

    So the only way to make that deployment works , its first get the SP1 client, and then the CU2 client (at leas for our enviroment, i tried to many computers).  


    Wednesday, January 27, 2016 6:44 PM
  • Ultimately, you must go to SP1 on the client first because CU2 is a patch for SP1 and thus doesn't apply to anything else; i.e., you can't just deploy CU2 (or CU1)

    The method Matt is talking about above though effectively "slipstreams" the CU into the SP1 client installation though so both can be done in one fell swoop. Notice in his install string he's using the PATCH property to specify the CU .msp file. This is simply taking advantage of Windows Installer's ability to install a patch (.msp file) at the same time as the product it applies to and is fully supported.

    Alternatively, you could do things in two passes, but IMO, using the PATCH property is the best way and certainly quicker.

    Do note that the location specified in the PATCH property must be fully qualified and so cannot be a relative location. Thus you either need to copy the .msp locally somewhere (as it appears Matt did for his command-line) or you need to place it on some universally accessible share that is accessible to the "Domain Computers" security group since this group automatically includes all computer accounts which is what will be used to access this location. This later won't work for non-domain joined computers though so keep that in mind also.


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

    Wednesday, January 27, 2016 7:21 PM
  • Thank you all very much for the help, it totally ease my work.

    Wednesday, January 27, 2016 10:10 PM
  • Dear Sir,

        Here is an article about upgrading clients from sp1 to sp1 cu1, you could take a look:

    http://www.scconfigmgr.com/2013/04/02/upgrade-configmgr-2012-sp1-clients-with-the-cu1-update/

    Best regards,

    Jimmy

    Thursday, January 28, 2016 8:14 AM