locked
SCCM 2012 R2 SP1 Client Upgrade Issue RRS feed

  • Question

  • Hello all!

    I upgraded my lab environment to SCCM 2012 R2 SP1 from 2012 R2, and now I am working on testing the new client. I can push the new client via the SCCM console and existing clients will upgrade perfectly. I took another step and created a SCCM package which uses <Site Server Name>\SMS_<Site Code>\Client as the source media, and using the following program.

    • Ccmsetup.exe /MP: cmtest-site.vlab.com DNSSUFFIX=vlab.com SMSSITECODE=PS1 SMSCACHESIZE=51200

    This approach works flawlessly just as pushing the new client from SCCM Console.

    Next, I went to test installing the new client using a package and program that calls the source location of the client bits from the actual site server.

    • Ccmsetup.exe /source:\\cmtest-site.vlab.com\SMS_VLAB\Client DNSSUFFIX=vlab.com SMSSITECODE=VLB SMSCACHESIZE=51200

    This method is being used in production now to successfully deploy the 2012 R2 client. When I test this approach in my 2012 R2 SP1 Lab, I do not have satisfactory results. The package reports back that it completed successfully but when in fact it did not. This method is currently working in a 2012 R2 production environment. When checking the client version on a machine that reported a successful install, the version was still the existing version (5.00.7958.1000).

    I have also tested the same syntax manually on a client (not using a package\program), CCMSETUP.exe launches and shows up in Task Manager, but when the process is finished the client is still the old version. The process seems as if the old client just reinstalled and nothing else.

    Now I have a few questions.

    • Has anyone else not be able to create to working package in this manor with SP1 for 2012 R2?
    • Is anyone else out there willing to test this approach to sanity check my results?
    • Did MS change the location of the bits with SP1? Is there a new folder location for CCMsetup.exe?
      • The data source for non-deployable (can’t right click deploy by design) built in client package still shows <Site Server Name>\SMS_<Site Code>\Client. Since there is no program associated with the package, I have not been able to determine where CCMsetup.exe is being called from. Same place? Different place?
    • Anyone have an explanation why this specific client upgrade process is failing while it works with SCCM 2012 R2?
    • BUG?

    Any help from the community is greatly appreciated!

    -Tony




    Sunday, July 12, 2015 4:27 AM

Answers

  • You should not ever use <Site Server Name>\SMS_<Site Code>\Client; the permissions on the share and at an NTFS level are not set for clients or users to gain access and you should not modify them.

    As Peter pointed out, what you are doing "doesn't compute". The default behavior of ccmsetup is to query the MP to find a DP to download the content from; same thing that /mp does but of course it must find an MP from AD or DNS to perform this query. If for whatever reason it cannot get the content from a DP, it will fallback to the MP.

    If you have a scenario where this doesn't work for you, then you could use /source but then that implies that you are manually creating a share somewhere for the client to get the content from. If the client could get the content from the MP, then there's no reason to use /source. However, having a system directly access the primary site server totally has no place.

    "The data source for non-deployable (can’t right click deploy by design) built in client package still shows <Site Server Name>\SMS_<Site Code>\Client. Since there is no program associated with the package, I have not been able to determine where CCMsetup.exe is being called from. Same place? Different place?"

    Called from for what? This package is meant to be used by OSD which knows how to call ccmsetup. There's generally no other need to use it. Client push does not use it. When you use client push, ccmsetup is copied to the target system directly by the site server and then executed.

    As for the clientupgrade folder, it is for exactly what its name implies, the client upgrade package. Which begs the question, why aren't you using the built in client upgrade feature instead of trying to push out package to do this?

    Finally, unless you've published the MP to DNS, which does not happen by default and is something most folks never do, using the DNSSUFFIX is meaningless.


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

    • Marked as answer by Tony Chirillo Tuesday, July 21, 2015 3:57 PM
    Sunday, July 12, 2015 1:35 PM

All replies

  • I'm trying to think of any reason why you would want to use a package and program combination together with the source parameter... ...and I can't think of any reason... You're using a package and program, so you can specify the source in the package configuration. Why would you want to use the source parameter then also?

    My Blog: http://www.petervanderwoude.nl/
    Follow me on twitter: pvanderwoude

    Sunday, July 12, 2015 6:10 AM
  • Hi Peter!

    You do have a point here, I was just trying to duplicate what was in place by a previous admin. Was not really thinking to much about the logic of it all. So you are suggesting to pull the source parameter and just use the bits in the package it self, and have this as the program?

    • Ccmsetup.exe  SMSSITECODE=VLB SMSCACHESIZE=51200

    -Tony

    Sunday, July 12, 2015 11:49 AM
  • Yes, that's exactly what I'm saying.

    My Blog: http://www.petervanderwoude.nl/
    Follow me on twitter: pvanderwoude

    Sunday, July 12, 2015 11:59 AM
  • I will give that a shot. I am now curious if am also using the correct source. Looking at the directories on my site server,  under <Site Server Name>\SMS_<Site Code>  I noticed I had the client folder which has always contained the client installers, but there is also a new folder now. "ClientUpgrade" which also has a ccmsetup.exe file it. Do you know if I should be using it instead of the one in the client folder with my package?

    -Tony



    Sunday, July 12, 2015 12:23 PM
  • You should not ever use <Site Server Name>\SMS_<Site Code>\Client; the permissions on the share and at an NTFS level are not set for clients or users to gain access and you should not modify them.

    As Peter pointed out, what you are doing "doesn't compute". The default behavior of ccmsetup is to query the MP to find a DP to download the content from; same thing that /mp does but of course it must find an MP from AD or DNS to perform this query. If for whatever reason it cannot get the content from a DP, it will fallback to the MP.

    If you have a scenario where this doesn't work for you, then you could use /source but then that implies that you are manually creating a share somewhere for the client to get the content from. If the client could get the content from the MP, then there's no reason to use /source. However, having a system directly access the primary site server totally has no place.

    "The data source for non-deployable (can’t right click deploy by design) built in client package still shows <Site Server Name>\SMS_<Site Code>\Client. Since there is no program associated with the package, I have not been able to determine where CCMsetup.exe is being called from. Same place? Different place?"

    Called from for what? This package is meant to be used by OSD which knows how to call ccmsetup. There's generally no other need to use it. Client push does not use it. When you use client push, ccmsetup is copied to the target system directly by the site server and then executed.

    As for the clientupgrade folder, it is for exactly what its name implies, the client upgrade package. Which begs the question, why aren't you using the built in client upgrade feature instead of trying to push out package to do this?

    Finally, unless you've published the MP to DNS, which does not happen by default and is something most folks never do, using the DNSSUFFIX is meaningless.


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

    • Marked as answer by Tony Chirillo Tuesday, July 21, 2015 3:57 PM
    Sunday, July 12, 2015 1:35 PM
  • Hey Jason!

    Thanks for helping untangle all of this.

    The IT organizational structured for the University of Missouri is very compartmentalized, School of Medicine, College of Business, Campus Faculties, Technical Support Services, Consolidated Server Group, etc. Each of these groups is independent among each other and own their workstations with the exception of the server group. My team runs SCCM and provides it as a service to the other IT groups on campus. Since my team does not own the clients using SCCM, we are not able to use the auto upgrade feature. My hands are tied politically in that space, thus the need to push out a package to upgrade existing clients. Trust me, I would rather approach this differently if it was feasible in our environment.

    Here is where I am at now. Using CCMSetup.exe in the ClientUpgrade folder instead of the Client folder, I now have a manual install of the new client working using the following syntax.

    • CCMSETUP.EXE SMSSITECOD=VLB DNSSUFFIX=vlab.com SMSCACHE=51200

    I took this a step further and made a package/program referencing the CCMSetup.exe file in the ClientUpgrade folder, and that approach successfully upgraded the clients too. I am going to see if we can move away from using the /source switch. If we are not … What would that package look like? Would the data source for the package be the ClientUpgrade folder? I am assuming so. For the program, what would bits should be used for the with the /source switch? The standard client folder? 

    Thanks for all your insight!

    If we ever meet at a conference, I’ll get you a beer! You to Peter! J

    -Tony

    Wednesday, July 15, 2015 9:43 PM
  • I took this a step further and made a package/program referencing the CCMSetup.exe file in the ClientUpgrade folder,

    Did you copy it and create your own share? If not, stop, go back and do this. As mentioned, you shouldn't use the built in ConfigMgr shares for this.

    Using the /source switch has nothing to do with packages, /source simply points to a UNC that the whomever called ccmsetup should have access to.

    CCMSetup in the ClientUpgrade folder and the normal client folder are identical, so it doesn't really matter which you use. CCMSetup is simply a bootsrapper that is responsible for downloading and installing pre-requisites and downloading and installing the client agent itself. It can download these from any number of places. You don't have to specify any location though because by default, it will find an MP, query it for a DP, and download the files from there. Is there a reason you are trying to force it to download the files from some other location?


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

    Thursday, July 16, 2015 11:21 PM
  • I created a separate share. Still using the same naming convention with the folders.

    Stepping back away from using the /source switch for a minute... 

    Building a package using ccmsetup.exe in the ClientUpgrade folder  successfully upgrades the client from  R2 to R2 SP1 using this program:

    • CCMSETUP.EXE SMSSITECODE=VLB DNSSUFFIX=vlab.com SMSCACHE=51200

    Building a package using the ccmsetup.exe in the client folder does not successfully upgrade the client using the same package. Instead the existing client version is reinstalled instead. I am not sure if both copies of CCMSETUP.EXE are "exactly" identical. When checking the details of the file, the one in the ClientUpgrade folder shows version of 5.00.8239.1000 and a size of 1698 KB whereas the file in the Client folder has version of 5.00.8239.1001 and a size of 1,700 KB. Who knows what the small difference is. If the CCMSETUP.EXE in client folder should perform they say way as the one in ClientUpgrade folder, do you have any thoughts why the one in the Client folder does not seem to work?

    I am going to run a few more trails to make sure I am not losing my mind.


    Friday, July 17, 2015 7:34 PM
  • Hey Jason!

    I now have a working package\program that uses the bits from the client folder. Why this was not working previously was because when I made the new share, I copied the wrong bits over to it. I copied in the R2 bits instead of the R2 SP1 bits. Once I corrected that, the package worked as expected.

    -Tony

    Tuesday, July 21, 2015 3:57 PM
  • Glad to hear.

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

    Tuesday, July 21, 2015 4:20 PM