none
Creating Mandatory request for advert XXX20000, program Configuration Manager Client Upgrade Program, package XXX00003 RRS feed

  • Question

  • After upgrading an SCCM 2012 R2 CU3 environment to SCCM 2012 R2 SP1 CU1, I expected to then manually be upgrading client systems. However, I find a few dozen client systems which have upgraded automatically to 5.00.8239.1000 without my saying so.  The Hierarchy setting to upgrade clients automatically was/is not enabled - yet, here we are.  Automatic Client push was/is also not enabled.  Installation of the SCCM Client via Software Updates was/is not enabled.

    The AdvertID that caused these clients to upgrade, according to execmgr.log is XXX20000 and this corresponds to an inbuilt/hidden offer in the database.  I'd have expected this advert to be dormant/disabled UNLESS I enable the client upgrade option?

    I find this quite disturbing, how else could these clients be upgrading themselves?  Is there a bug in the upgrade process that allows this advert to slip through the net for a while?  No other clients seem to be upgrading themselves.


    My Personal Blog: http://madluka.wordpress.com

    Tuesday, September 8, 2015 1:09 PM

All replies

  • Just to verify, these were systems previously installed with the client agent, correct?

    ccmsetup.log or ccm.log may give a clue. If there's activity in ccm.log for these clients, then you know the install was initiated using client push -- manual client push based on your statements. ccmsetup.log would just show a time when the installation took place but may show some other interesting fact that may help.

    I can't say I've seen this happen though so that's all I can really offer.


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

    Tuesday, September 8, 2015 1:34 PM
    Moderator
  • We have discovered that these client systems have been running ccmsetup.exe every day for the last x weeks, evident by examing the ccmsetup-ccmeval.log.  This looks to be caused by the failure to remove the Scheduled Task for the CCMSETUP.EXE, even though the process returned 0 (zero.)

    It seems that these clients, when they re-installed themselves, simply started picking up the new setup files from the server and also the revised client push properties.

    Just some cleanup to do, removing the Scheduled Task from those machines.  Client Push to one of these systems, even with the 'uninstall previous version' does not seem to remove the stuck scheduled task.


    My Personal Blog: http://madluka.wordpress.com



    • Edited by MadLuka Tuesday, September 8, 2015 2:30 PM
    Tuesday, September 8, 2015 2:25 PM
  • To my knowledge, there is a known "issue" involving this scheduled task not being properly deleted all of the time so that looks to be the source of your issue. I don't think there is any recommended work-around or resolution at this time though :-(

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

    Tuesday, September 8, 2015 2:39 PM
    Moderator
  • Hi Jason, well it seems even after performing a client push with the 'uninstall previous client' option and then ensuring there is no scheduled task configured - the ccmsetup.exe still ran again this morning.  How frustrating.

    I am hoping this may not happen tomorrow, as the command line differs from what has been occuring in the past;

    Loaded command line: "C:\Windows\ccmsetup\cache\ccmsetup.exe" "/runservice"  "/config:C:\Windows\ccmsetup\MobileClientUnicode.tcf" "/RetryWinTask:1"

    is now

    Loaded command line: "C:\Windows\ccmsetup\cache\ccmsetup.exe" "/runservice"  "/config:C:\Windows\ccmsetup\MobileClientUnicode.tcf"

    There are no pending client push tasks or in ccrretry and no activity in the server ccm.log for this machine.

    Nothing in the ccmrepair.log, 


    My Personal Blog: http://madluka.wordpress.com

    Wednesday, September 9, 2015 11:40 AM
  • Best thing to do is to open a case with Microsoft and push them for a fix. They have purposefully not released any info on the technical details of the upgrade process so it's really hard to troubleshoot.

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

    Wednesday, September 9, 2015 2:06 PM
    Moderator