none
Automatic Client Upgrade not working for most devices RRS feed

  • Question

  • Hi,

    I've used the Automatic Client Upgrade feature in a test environment and it worked like a charm. Clients were SP1 (CU5) and upgraded to R2 over 1 day. There were about 50 clients; all upgraded properly within the timeframe.

    After enabling the feature, on the next machine policy evaluation cycle on the clients, a task was created (task scheduler) to upgrade the client... And it did.

     Now, I'm doing the same in Pre-Prod (same configuration as test) and it's not working for most devices (only working for a very few)... Not totally broken...

    I have about 150 devices in this pre-prod environment. It was upgraded (1 PS, 1 SS) to R2. The Automatic Client Upgrade feature was enabled with a 1 day setting.

    It is now, 24 hours after the upgrade & enabling of the feature, and only 15 devices had their client agent upgraded. Most clients are Win2008 R2, like in the test environment.

    The other 135 devices have ran several Machine Evaluation Cycles since, but the task to upgrade the client was not created (Configuration Manager Client Upgrade Task)...

    Any idea how to troubleshoot?

    thanks


    Tuesday, May 5, 2015 12:02 PM

Answers

  • The auto-upgrade is most likely being triggered by the updated ccmsetup version in CU5 which was updated because of the updated SCEP client in CU5 and not the presence of the MSP in the clientpatch folder.

    I've said it before, and I'll say it again just for prosperity: the devs have explicitly said not to use clientpatch and that's good enough for me.


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

    • Marked as answer by fern.santos Thursday, May 21, 2015 3:09 PM
    Thursday, May 21, 2015 3:06 PM
    Moderator

All replies

  • Are the clients within content location boundary/groups? Automatic client upgrade will only upgrade clients that are able to locate content on 'fast' DPs.

    Torsten Meringer | http://www.mssccmfaq.de

    Tuesday, May 5, 2015 12:15 PM
  • Yes, all within boundary/groups for content location. They are active and healthy. They just got patched (SU) a couple of days before.

    All are configured with FAST DPs (none SLOW).

    Most devices (~140) are within the same boundary/group, but only 15/140 got upgraded.



    Tuesday, May 5, 2015 12:17 PM
  • Hi,

    Have you checked ccm.log and ccmsetup.log?

    Best Regards,

    Joyce


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, May 6, 2015 4:51 AM
    Moderator
  • yes, I checked ccmsetup.log on the client. There is nothing new in the past few months (since last time the client installed).

    CCM.log on the site server has no entries for the timeframe when I run the Machine policy evaluation cycle on the client.

    I also checked ccmsetup-ccmeval.log.

    Strange that MS didn't create a log for to track auto upgrades...

    • Edited by fern.santos Wednesday, May 6, 2015 11:33 AM
    Wednesday, May 6, 2015 11:29 AM
  • Hi,

    Please check c:\windows\ccmsetup\logs\ccmsetup-ccmeval.log, and check the last time for the Ccmsetup has been run as an evaluation, any error regarding the last evaluation?

    Best Regards,

    Joyce


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, May 8, 2015 8:38 AM
    Moderator
  • I had checked ccmsetup-ccmeval.log since it updates every night, but that is only for the client health evaluation task. There are not errors or any information related to the automatic client upgrade.

    It lists:

    - CcmSetup version: 5.0.7804.1000

    - CcmSetup is exiting with return code 0

    Monday, May 11, 2015 12:28 PM
  • Why not create a client update package and push it out initially to a few machines via a collection, it's referenced in this article.

    http://configmgrblog.com/2012/12/03/how-to-update-configmgr-clients-automatically-in-sp1/

    https://technet.microsoft.com/en-us/library/gg712298.aspx?f=255&MSPPError=-2147217396


    Monday, May 11, 2015 12:56 PM
  • My objective is to use the automatic client upgrade feature. If I wanted to use a package, I would use the ones that the wizard creates!

    I'm aware of the link you provided; I found it during my research phase; excellent blog. I already updated the content for the client agent package.

    I know that there is not much monitoring for the auto upgrade (apart from pulling client versions) but that is fine with me. It worked perfectly in my other environment...

    I just can't find any log that shows why the client isn't creating the task to upgrade the software.


    Monday, May 11, 2015 1:06 PM
  • Hi,

    By default, when triggering the Machine Policy Retrieval & Evaluation Cycle you should see appear a Configuration Manager Client Upgrade Task in the Task Scheduler of the client.

    If you can’t find this task on the affected client, maybe the client is unable to communicate with MP at all. We can check it from locationservices.log on the client. Also, make sure Site Server System Account(Computer Account) is a Local Admin on the clients. There are must be some incorrect setting on the clients, since MP is able to upgrade some clients already. Right?

    Try to remove the agent on one client, and install it again, and check if the Configuration Manager Client Upgrade Task appears.

    Also, as best practice, Automatic client upgrades are useful when you want to upgrade a small number of client computers that might have been missed by your main client installation method. For example, you have completed an initial client upgrade, but some clients were offline during the upgrade deployment. You then use this method to upgrade the client on these computers when they are next active. It is not recommended to only use this way to upgrade all client.

    Best Regards,

    Joyce


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, May 13, 2015 9:19 AM
    Moderator
  • Hi Joyce,

    The client is working correctly. It gets deployments, sends heartbeat, etc. The locationservices.log shows the MP being identified, along with DP, AD site, etc. No errors that I can see.

    I tried uninstalling the client and re-installing the SP1 client, then the machine policy ran and still no task for the client upgrade. Strange how some clients get the task but most do not; all use the same MP/DP/Boundary Group.

     It used to be that this feature was supposed to be used for small locations (few clients), but since SP1, it can be used for bigger sites too. SP1 introduced efficiency to the process. This is according to what I read.

    Wednesday, May 13, 2015 2:43 PM
  • Make sure that the client install and client upgrade packages are properly distributed to all of your DPs. Force a DP update to be sure even.

    Also, just to verify, you aren't expecting this to install the CU update, correct?

    And finally, the small site restriction/recommendation is long gone. MSIT uses this feature to perform all of their client upgrades which over the years has been 6 or 7 times given the different builds that they have used in the dog fooding process.


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

    Wednesday, May 13, 2015 2:56 PM
    Moderator
  • Hi Jason,

    Thank you for your reply.

    The client package and upgrade package is properly distributed. Also, I can manually install the client or push it form the admin console. This confirms that the client has access to the R2 binaries. I updated the package 2 times (once after R2 and another time after CU5 today).

    You are correct, I'm talking about the R2 client upgrade. I am aware that this feature does not handle CU updates, only major upgrades, such as SP1 to R2 RTM.

    I recall reading about MSIT using the feature as a main method; I just can't think where I read it. Probably one of your replies on the forum :)

    I'm curious to see what will happen in my prod environment. test=works 100%, pre-prod= works <10%.

    I read that the feature is getting enhancements with the upcoming SP. Hopefully, they'll add some logging to know what is going on and why the task isn't created on the client.

    Thanks

    Wednesday, May 13, 2015 3:18 PM
  • This is very strange... On the environment where the client auto upgrade worked:
    - all clients (servers and workstations) were R2 CU4 (.1501) - April 28th
    - then, yesterday afternoon, I installed CU5 for R2 on the primary site (CU5 packages were not distributed or deployed)
    - this morning, some clients auto upgraded the client from CU4 (.1501) to CU5 (.1604). the others have a task to auto upgraded ("Configuration Manager Client Upgrade Task")!

    From everything I read, the auto upgrade feature only works for upgrades (major), not updates (CU), but it created the task on my clients for the R2 CU4>CU5 update...

    Technet says "You can configure Configuration Manager to automatically upgrade the client software to the latest System Center 2012 Configuration Manager client version when Configuration Manager identifies that a client that is assigned to the System Center 2012 Configuration Manager hierarchy is lower than the version used in the hierarchy."

    It doesn't say anything about a difference between minor updates (CU) and major upgrades... It says when the version is lower than the hierarchy... 1501(CU4) is lower than 1604(CU5)...

    Could MS have changed in recently, e.g. in SP1 or R2?

    On the clients that have not yet been auto upgraded, I see the task "Configuration Manager Client Upgrade Task" with the same command as documented and it is schedule for within 1 day (as configured in the site).

    I also see proof in the ccmsetup.log! Within 1 hour after installing CU5 on the PS, the log on the clients says:
    - CcmSetup version: 5.0.7958.1604
    - Ccmsetup command line: "C:\windows\ccmcache\7\ccmsetup.exe" /AutoUpgrade /UpgradePackageVersion:5
    - Detected client version 5.00.7958.1501 from WMI.
    - Task 'Configuration Manager Client Retry Task' does not exist
    - Last auto-upgrade config time(utc) '04/28/2015 04:29:00 PM' which is more than 1 days ago. Randomize with default 1 day.
    - 'Configuration Manager Client Upgrade Task' is scheduled to run at 05/20/2015 10:47:47 PM (local) 05/21/2015 02:47:47 AM (UTC) time with arguments ' /AutoUpgrade /UpgradePackageVersion:5 /UpgradeWinTask'.
    - then at the scheduled time, the client installs...

    I found the entry about the last auto-upgrade suspicious... Almost like it existed already, but it did not. At the end of the R2+CU4 client upgrade (~3.5 weeks ago), where the client auto upgrade worked, it says "Task 'Configuration Manager Client Upgrade Task' does not exist", meaning  that it deleted the task after the upgrade. I confirmed this. It also says that same statement this time (previous line).


    Any ideas why it handled the update of the client from R2 CU4 to CU5?


    • Edited by fern.santos Thursday, May 21, 2015 12:29 PM
    Thursday, May 21, 2015 12:21 PM
  • The client auto-upgrade also handles upgrading SCEP and is what you are seeing since a new version of SCEP is included with CU5. The ConfigMgr client agent itself won't get upgraded though.

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

    Thursday, May 21, 2015 2:14 PM
    Moderator
  • Hi Jason,

    I see the scepinstall.exe file in the ccmsetup folder, along with other files.

    I don't use SCEP and that software is not installed on the devices.

    The SCCM Client Agent software was automatically upgraded on most clients (since yesterday), the remaining have a task scheduled. It was version 5.00.7958.1501 until yesterday and clients have been automatically upgrading to 5.00.7958.1604.

    The entries form the log above show that auto upgrade created the scheduled task within 1 hour after installing CU5 on the PS.


    I'll try to reproduce on a sandbox environment in the near future.

    Thursday, May 21, 2015 2:32 PM
  • Are you using (the unsupported) clientpatch folder?

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

    Thursday, May 21, 2015 2:36 PM
    Moderator
  • umm, yes.

    I was going to mention, but how does that affect the auto upgrade? Because of the updated CU5 msp being in the source folder?

    Technet says that the client can be auto upgraded if "One or more of the client installation files are a different version.". If files in the ClientPatch folder are different, does it trigger auto upgrade of the client agent? If yes, wouldn't it be same for the SCEP update - when one exists (as you mentioned)?

    If newer file(s) in the ClientPatch folder triggers auto upgrade, that's even a bigger bonus for me to use it. I like being able to use the auto upgrade for all client updates/upgrades even when it's a CU. I don't need more granular control.

    This would explain why people say that Auto Upgrade doesn't install CU updates on clients, as CU update files don't go in the source folder by default. But if you manually add a new file to the source folder (such as ClientPatch), auto upgrade installs the client agent, including the CU because if detects a newer file version.

    It would be more efficient to only install the CU update with a package (smaller), but I'm OK with reinstalling the whole client with the CU, as I'm going from SP1 to R2+CU5.

    I'm still puzzled why my pre-prod environment didn't work the same way though. When I installed R2 with CU4, the auto upgrade only created the task on a a few clients. Then I upgraded the remaining of the clients using another method - to R2 CU4.

    A few days later, I installed CU5, also updated the ClientPatch folder. This did not trigger an auto client upgrade. I used a package to update the clients to CU5.

    Thursday, May 21, 2015 2:56 PM
  • The auto-upgrade is most likely being triggered by the updated ccmsetup version in CU5 which was updated because of the updated SCEP client in CU5 and not the presence of the MSP in the clientpatch folder.

    I've said it before, and I'll say it again just for prosperity: the devs have explicitly said not to use clientpatch and that's good enough for me.


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

    • Marked as answer by fern.santos Thursday, May 21, 2015 3:09 PM
    Thursday, May 21, 2015 3:06 PM
    Moderator
  • Got it. Thank you for your explanation, it makes sense :)
    Thursday, May 21, 2015 3:09 PM
  • Got it. Thank you for your explanation, it makes sense :)

    :-) That doesn't always happen, so I'm glad to hear that.

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

    Thursday, May 21, 2015 3:10 PM
    Moderator