locked
Clients running ccmsetup daily RRS feed

  • Question

  • Hi,

    We are using SCCM 2012 R2 SP1 CU1.  Clients are running client version 5.00.8239.1203 (R2 SP1 CU1).

    On many clients (mostly 7 x64) I have looked at ccmsetup.log is getting updated every day and ccmsetup appears to be running, e.g.

    ==========[ ccmsetup started in process 12504 ]==========	ccmsetup	12/2/2015 9:51:40 PM	16040 (0x3EA8)
    Updated security on object C:\WINDOWS\ccmsetup\cache\.	ccmsetup	12/2/2015 9:51:40 PM	16040 (0x3EA8)
    Launch from folder C:\WINDOWS\ccmsetup\	ccmsetup	12/2/2015 9:51:40 PM	16040 (0x3EA8)
    CcmSetup version: 5.0.8239.1203	ccmsetup	12/2/2015 9:51:40 PM	16040 (0x3EA8)
    Running on 'Microsoft Windows 10 Enterprise' (10.0.10586). Service Pack (0.0). SuiteMask = 272. Product Type = 18	ccmsetup	12/2/2015 9:51:40 PM	16040 (0x3EA8)
    Ccmsetup command line: C:\WINDOWS\ccmsetup\ccmsetup.exe /AutoUpgrade /UpgradePackageVersion:9 /UpgradeWinTask	ccmsetup	12/2/2015 9:51:40 PM	16040 (0x3EA8)
    Upgrade code '{252DA259-82CA-4177-B8D0-49C78937BA3E}': product = '{343D4507-997F-4553-9F86-2BB81F19A05E}', installed = 1, version = 5.00.8239.1000	ccmsetup	12/2/2015 9:51:40 PM	16040 (0x3EA8)
    Loaded command line: C:\WINDOWS\ccmsetup\ccmsetup.exe /AutoUpgrade /UpgradePackageVersion:9 /UpgradeWinTask "/UsePKICert" "CCMHTTPPORT=80" "CCMHTTPSPORT=443" "CCMCERTISSUERS=CN=XXXX; DC=XXX; DC=XX; DC=XX" "CCMFIRSTCERT=1"	ccmsetup	12/2/2015 9:51:40 PM	16040 (0x3EA8)
    Ccmsetup is launched by Windows Task Scheduler for client upgrade.	ccmsetup	12/2/2015 9:51:40 PM	16040 (0x3EA8)
    

    It appears to be caused by the client upgrade task.  Why would this be executing when clients are already at the correct client version?  I've seen another thread but that seemed to be an issue with a single machine

    https://social.technet.microsoft.com/forums/en-US/1073437b-ba99-4130-bd24-629a05506e87/ccmsetup-still-runs-after-sccm-2012-sp1-client-is-installed

    Thursday, December 3, 2015 9:45 AM

All replies

  • It would seem that for some reason the scheduled task for upgrade of the clients are not automatically deleted. I don't see this in my environment on Windows 10 clients. Have you made any security baseline that might conflict with the task being deleted?

    Nickolaj Andersen | www.scconfigmgr.com | @NickolajA

    Thursday, December 3, 2015 10:15 AM
  • Hi,

    The log was from a W10 client but it is there on W7 clients as well.  I have just disabled the automatic upgrade for the moment whilst I investigate further

    Thursday, December 3, 2015 11:11 AM
  • I don't know of exact details, but I know this was reported and is a known potential issue in CU1. I don't think it always happens and don't know if CU2 fixes it or not. You may want to open a support case or consider moving to CU2.

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

    Thursday, December 3, 2015 2:20 PM
  • check if any other deployment for agent on this collection and review software evaluation log.


    Thanks Mohamed Fouad

    Thursday, December 3, 2015 2:37 PM
  • So just to provide my 2 cents we ran into this exact problem. We waited until CU2 to even try the ACU feature. It had been touted on many technet sites and other blogs as being a good solution for upgrading clients to the new current version.

    Our story went like this.

    Day 1. Turned on ACU set for 30 days without upgrading servers. Discovered all of the embedded devices upgraded that night after their MW. The other devices did seem to stick to the math. About 800 devices aside from the embedded devices upgraded to CU2.

    Day 2. Discovered about 30 embedded devices were stuck at the lock screen. Quick fix was uninstall the SCCM client and reinstall on the device. Took care of the issue.

    Day 3. Devices continued to upgrade at the appropriate frequency but all 5,000 embedded devices rebooted the previous night.

    Day 4. Embedded devices rebooted again. Opened a ticket with MS. At the time, they didn't even know how the ACU worked, and i had to convince the tech that ACU creates a scheduled task for the upgrade.

    Day 5. Changed the 30 day value down to 14. Embedded devices continued to reboot every night.

    Day 6. With the embedded devices still rebooting every night we changed the value to 3 days.

    Fast forward 3 days. About 80% upgraded. Turned off ACU at that point. Then I discovered the clients that did upgrade via ACU left behind a nice treat. A ccmsetup service that it didn't delete, which was wonderful when the nightly eval kicked off....

    So I cleaned up all the lingering CCMSetup Services and the environment is all over the place. Now that were on 1602 I need to get our enterprise up to that version and make certain the new Software Center gets installed.

    With the issues of ACU fresh in everyones mind, that wasn't an option. Didn't see anything posted anywhere that they fixed the lingering service issue and i called MS. They closed the ticket as "known bug" LMFAO. At least it didn't cost us any hours. I tested CP witch did install the new client 8355 but the new software center for whatever reason wasn't installing. So i tried Client Push with the uninstall check box.

    That ended up doing the trick but the client lost its execution history, which made content going over a wan which was already a nightmare a complete CF!

    So what i've been testing is just a package with the 2 meg ccmsetup inside a CMD file. That has worked so far. I'm going to incrementally push that across the enterprise and unless we run into a major problem so far it seems to be the best option.

    I've heard of people having good success with ACU. For us, it just didn't go that way, embedded aside the normal clients still had the lingering service on almost exactly 50% of our client base.

    I had hoped with the 2 calls to M$ that we'd find a config issue or something simple that i missed, but in the end its just a bug in the process. If you have any specific questions for me feel free to email me. samdotkachardot2atgmaildotcom.


    Cheers,

    Sam Kachar

    Saturday, May 7, 2016 12:59 AM