I recently upgraded the site servers to SCCM SP2 and everything has been running fine. The clients are still on SP1. I started upgrading on a test group of computers and nearly all of them had problems. I have tried doing fresh installs and upgrades from SP1 but the behavior is the same. Here are my three main problems: 1. The client locks up during the upgrade and a hard shutdown has to be performed. Once the client restarts, the SP2 upgrade tries to resume and locks the system up again. The only way out is to disable the ccmsetup service (it runs /service) from Safe Mode then force an uninstall of the client. 2. The client upgrade completes successfully, but the install time takes ~30 minutes. There is a significant delay (over 15 minutes) when I get to this point in the ccmsetup.log: "CcmSetObjectSecurity. Applying security permissions". 3. The client reboots once the install completes. The log shows that a reboot will take place but the user is not prompted. Here are the parameters with the push install: SMSSITECODE=NP1 CCMHTTPSSTATE=1 RESETKEYINFORMATION=TRUE

This shouldn't matter but you don't need resetkeyinformation in an upgrade. I use this: CCMSETUP.EXE /noservice SMSSITECODE=AUTO FSP=SCCM01 John Marcum | http://myitforum.com/cs2/blogs/jmarcum |

I still get the same behavior. I need a point of reference so I know what to expect. Can somebody give me their experience when upgrading or fresh installing a client to SP2? I have tried launching locally, removing all parameters, etc but get the same results. System resources is not an issue. Again I think the problem is during the time where the log says 'CcmSetObjectSecurity. Applying security permissions'. There is a 15-30 minute delay before the log continues with the install and the desktop slows to a near halt. The next line on the log reads ' CcmSetupLogging. Initializing logging...'

Upgrading the clients from SP1 to SP2 is usually easy. I've seen a similar behavior in the past ... you should double-check the number of files in the \ccm directory (and all subdirectorries) and the size of that folders. There were hundreds of thousand files in one of the subdirectories (cannot remember which one) and it took ages for ccmsetup the check/change NFTS permissions. No need to use resetkeyinformation unless you want to reassign clients to a different hierarchy.

Thanks torsten. I ran a treesize on an SP1 client's ccm folder and there wasn't hundreds of thousands of files. There was ~750 files total and about half of them were in the \cache directory. I should mention that I get this behavior even on a fresh install. I have tried installing locally as well as push installs and get the same behavior.

Scratch that. The files came up. It's in \ccm\SDMAgent. There are 181,000 files in this directory. It took a long time for everything to show. Can you please explain why there are so many files? What is the best way to fix this? Edit. I just checked a couple other machines and they are over 450,000 files in the SDMAgent directory (!!!). This is definitely a problem - especially trying to upgrade. What can I do? When I open the directory, I get 450,000 zip files, each with a GUID-like ID. All of them are 0.0 MB in size, contain just 1 file, and show a last change of 12/31/2000.

I've seen that happen when testing some DCM stuff (bad baselines or CIs). Any chance that you are using DCM, too?

Torsten, I did some research and you are the only one that seems to know anything about this. I have a simple question that hopefully you can answer: If I delete all the baselines and CI's from DCM, will the files from \ccm\SDMAgent\PackageLoader\PackageDownloads delete automatically? I only have a single baseline currently in use and I'll just delete it if that will allow me to upgrade my clients.

Just following up to see if anybody has an answer for this?

I can't remember the exact details unfortunately, but deleting the baseline + CIs is not needed in the first step of troubleshooting. Just remove that computer from the collection where the baseline is assigned to or remove the assignment at all. Are other clients also affected (having thousands of files in that directory)? Refresh machine policies after the assignment of the baseline was removed and see if the files get deleted automatically.

Thanks again for the reply, Torsten. This morning I removed the baseline assignments. I took a handful of test computers and did full HW/SW inventories, and refreshed the machine policy, but the files are still there. Any other ideas?

Just an update... I opened a case with Microsoft on this issue and we basically got nowhere. The support rep was able to duplicate the issue and the final solution was a 2 line script to manually delete the folder - I already had this solution in place but the problem is that running the script can take over an hour due to the huge number of files on some clients. I'm actually really upset at Microsoft because I pressed for a cause of the problem and got nothing more than "it was a problem with the baseline". Well, why didn't it flush out? Where in the logs show these files accumilating in the directory? Why, after deleting the baseline weeks ago, did the files not flush out and empty the directory? I basically wasted several hours and $200 for something I already knew. So my next question is (before i leave a poor rating to the rep's manager), if the problem appears to be a legitimate bug, is there some sort of reimbursement for the ticket? I'm still stuck with the problem and have no way of knowing if it will happen again. I pressed the rep for 20 minutes for additional details and got generic responses. :(

If you call CSS and the issue turns out to be a bug the call is free. I think you just have to ask for a credit for the call. If you didn't get satisfactory support email the manager, his contact info should be in the signature line of all emails from the support rep. CSS has some really good support people but they also have a few less than stellar ones. They will however escalate the issue if you press them to. John Marcum | http://myitforum.com/cs2/blogs/jmarcum |

Thanks. I did exactly what you said and the manager escalated me to another rep. It took 15 minutes and he told me exactly what happened and detailed it. Turns out it is indeed a bug and I got my call fees back too. Long story short, if you delete a baseline before it finished processing on a client, the files don't delete out of the packageddownloads folder. They are aware of this issue but unfortunately there is no fix outside of running a batch file. According to the rep, this problem will be resolved with the next version of SCCM (v. Next). Thanks for all your help

Thanks. I did exactly what you said and the manager escalated me to another rep. It took 15 minutes and he told me exactly what happened and detailed it. Turns out it is indeed a bug and I got my call fees back too. Good! I've had to go through the same thing. You can get credited for the call but you have to request it. John Marcum | http://myitforum.com/cs2/blogs/jmarcum |