Hi all, I have a question about your experiences on the best way to upgrade the agent to newer versions. We recently upgraded our ConfigMgr agents from SP1 to SP2. Normally our setup script first uninstalls the previous version using CCMSETUP /UNINSTALL, runs CCMDELCERT, removes remaining folders and registry entries (if any), and then performs a clean install with CCMSETUP.EXE, including RESETKEYINFORMATION=TRUE. Although installations are quite smooth this way at the client side, I noticed that at the server side a new client record is generated for the system for most of the cases, making older record obsolete. But this causes client to re-enter to all collections after some time, re-running some of the advertisements it previously ran successfully (I suppose the ones with "Always rerun"), report full inventory etc. Am I associating the new record generation wrongly with this? Because of the side effects noted above, I decided that upgrade (instead of clean install) might be a more desirable choice, i.e. it will not create a new record at the server side. Is this assumption correct? But with upgrade I came across different problems, the most notable being that the agent directly initiated a self repair at first run after upgrade, in CCMEXEC.log stating: Checking product registrations. Found product code = {CE6A85D8-D6B9-479A-9FE9-A06E56881E61} Found product "Configuration Manager Client" version 4.00.6221.1000 upgrade code {252DA259-82CA-4177-B8D0-49C78937BA3E} Looking for product code '{CE6A85D8-D6B9-479A-9FE9-A06E56881E61}' in WMI Could not get registration for product "Configuration Manager Client". Repair required. WMI returned (80041002) Detected faulty configuration. Repair will be started in 5 minutes. which I supposed is a by-design behavior on upgrades (compared to clean installs), am I wrong? I am seeing the above logs consistently on all clients I choose to upgrade. Repair runs just once and fine but the problem caused by repair is that the client loses its Configuration.mof customization (pushed by primary site from clifiles.src\hinv folder) after repair. More specifically, we customized Configuration.mof to add UninstallString attribute to Win32Reg_AddRemovePrograms class. Normally clients were reporting fine that additional attribute until a repair is initiated either manually or by upgrade process. After repair, they completely stop reporting Add/Remove Programs inventory, giving error 80041017 in InventoryAgent.log for that class (expected because the data class Win32Reg_AddRemovePrograms seems to lose UninstallString attribute). Is this normal, a problem specific to us or a bug? I know that pushing Configuration.mof with software distribution (MOFCOMP) might be a solution to this, but normally I think it shouldn't be required. I cannot know which client will initiate a repair when and for whatever reason, so I'll have to schedule it to run regularly. So I need your experiences and advise on the problems I faced with the above deployment strategies. Any help is much appreciated. Kind Regards,

The process you describe is overkill. Just use software distribution and upgrade the clients. Also, please do not double post questions. If your concern is only about configuration.mof you've asked that in the inventory forum. John Marcum | http://myitforum.com/cs2/blogs/jmarcum |

Hi John, Thank you very much for your answer. So you recommend running directly ccmsetup.exe to upgrade, without removing the previous client. I already do it by software distribution by the way (and by group policy startup scripts as well). Removing the previous client first easies things from time to time, but we do not prefer it for mass version upgrades of otherwise healthy agents. So is it normal that the agent triggers a one time self-repair after this upgrade? Is it normal that repair operation removes Configuration.mof extensions, pushed by the primary site? This question at the other forum is answered as: Extending default / existing classes is not supported. I didn't know that, I don't remember having read it anywhere. Can you confirm this as well? I'm not very clear about what causes a secondary record to be created instead of updating the existing record for a system. Can you please comment on this a bit? Kind Regards,

I don't recall it doing a repair, it just upgrades the clients. all the installs will show failed if you look at them in reports because during the upgrade SCCM looses track of the clients becuase afterall we are basically removing and adding it back. Doing it your way would cause a new record in SCCM everytime which likely has undesirable effects. I'm not sure what you are askign about the secondary sites. Sorry. John Marcum | http://myitforum.com/cs2/blogs/jmarcum |