Unknownforce Posted November 5, 2014 Report post Posted November 5, 2014 We recently updated to 2012 R2 CU3 from Non-SP CU2. After the update, I did a manual forced install of the client on our Main collection to get them all up to date, which went fairly well.. there were a few that I had to re-install a couple times to get it to "take" but overall it worked just fine. Now we're reporting about 91% of "active" compliance, client-wise. A little more background on our infrastructure... We have our PxE boot only available on a separate VLAN with an available D block of IP addresses that we use to load computers with, so when we load machines, they tend to get the same IPs that were recently used, which can confuse DNS and SCCM for a bit because there are potentially stale records that still have a freshly loaded computer on that segregated VLAN... So on to the problem here... After any fresh OSD loads, everything works just fine, but ccmsetup.exe keeps re-running, over and over. It uninstalls the client successfully, and then re-installs the client successfully... over and over and over again... Which logs can I look at to see why this is happening? ccmsetup.log doesn't seem to show WHY it was triggered, it just shows that it starts, downloads the package, removes the current version, and then installs it again. Each time is successful with no errors. Client installation is NOT set to push on our site in any way. The only installation of the client is during most of our OSD Task Sequences. (one is setup as just a plain base load without loading the client) It doesn't matter whether or not the CU3 is deployed to it. It will exhibit this same behavior regardless of the CU3 patch deployment. The CU3 patch does work on it as well, but it will just re-install right over it the next time it is triggered. It also doesn't seem to be time dependent, It can re-install within a few minutes and then go for an hour without re-installing, but it eventually does happen again. The devices that exhibit this behavior on are showing that they Pass the client check... so it is checking in properly... It kind of seems like it has something to do with the manual install I pushed to the collection, because it's using the "force install" option as well as the option to uninstall the old version first. It kind of seems like the server is trying to install to a device that perhaps in SCCM's database has the same IP address registered to it, but isn't the same device name... and thus it's not checking in properly because of that, so it's stuck in a loop trying to get the device updated. Over-analyzing is my specialty, but this seems like a fairly reasonable explanation to me. But, if it's true, how do I cancel those "pending" installs? Any help would be greatly appreciated as this is making it difficult to use my test machine for application/package deployment testing because it ends up killing all the SCCM related tasks/services in order to reinstall! Quote Share this post Link to post Share on other sites More sharing options...
Peter van der Woude Posted November 5, 2014 Report post Posted November 5, 2014 Check the ccmsetup-ccmeval.log, maybe the evaluation task determined something was wrong. Quote Share this post Link to post Share on other sites More sharing options...
Unknownforce Posted November 6, 2014 Report post Posted November 6, 2014 Thanks for the info. This isn't a problem anymore... in fact, it was a real bonehead problem... Our Network Administrator never fully decommissioned our old SMS 2003 server... so it was still broadcasting. And this one WAS set to push clients automatically because we didn't have OSD back then, so the client installed in the background after the AD Discovery and because the client check kept failing, it kept pushing... I should have figured it out easily by seeing the logs mention the old server, but I didn't because the old SMS 2003 server was very similarly named to our current SCCM 2012 server, so when looking at the logs, it just looked like it was coming from the same server... but, in fact, it wasn't. I was also confused by the date on the ccmsetup.exe and the fact that there were two separate ccmsetup.log files... well now it all makes sense... I'm just surprised that it's taken us this long to realize that this was still active, I would have figured it would be causing a LOT more problems across our network... Either way, thanks for the reply. Quote Share this post Link to post Share on other sites More sharing options...