tecxx

i noticed the same, and was shocked that Microsoft is installing a three year old SQL Version with the R2 release. but well. SP1 is now installed, i will wait for some days and then post again if this solved the issue.... cheers

hello, same issue here. happens with secondary sites that we upgraded from SCCM2012SP1, and happens with freshly installed SCCM2012R2 sites.

thanks, it worked fine. NOTE: care must be taken that if a third application has "old application" as a requirement, sccm can not uninstall "old application" automatically to install "updated application". (hope what i wrote makes sense ) it cost me quite some time to figure out why it didn't work at first.

Hello, thanks for this informative posting. i am already deploying various applications in SCCM2012, and now i'm at a point where i want to upgrade/supersede one. for example, i have an application SAP GUI version 7.10 with correct and functional install/uninstall and detection methods. i now want to replace it with version 7.20. i am unclear if i should create a new deployment type in the existing application or create a new application, and create a supersedence relationship. can you (or anyone else) help?

I agree with what user juice13610 wrote. a properly configured wsus environment gave me the following procedure: - manual approvement of patches on the main wsus console by admin - auto deployment to all subsidiary wsus servers - clients get patched - monthly cleanup script on wsus servers removes old, unused patches, keeping the file storage requirements small - should a client reconnect to the network after beeing offline for a long time, needed updates are re-downloaded, redistributed, and the client gets patched (because they are still in "approved" state) this is pretty easy to setup and fully automatic. with my current sccm2012 setup neither do i have a good solution for cleaning unused update files from the servers, nor is there an automatic solution for the "old client" problem. to recap, according to the technet post, this is what should be done: - create a compliance-only group to monitor patch state of clients, but dont distribute this group - use ADR to create monthly patch groups, that are distributed and used for actual patching - manually remove old, unused monthly patch groups when they are no longer needed - manually update the compliance-only group each month to include the latest updates - manually handle clients that were offline for a long time ("old client" situation) i wonder that this is really the intended way to do it. or did i misunderstand the concept? any feedback is greatly appreciated.

about 2), i will share my experiences. what i have done is: create automatic deployment rules, for each "product" one. e.g. an automatic deployment rule for windows7, one for xp, one for server2008, one for office, etc. for each automatic deployment rule i have selected "Add to an existing Software Update Group". this makes sure that all windows 7 updates stay in the same windows 7 update group, and so on. in "software updates", i have selected the following: - product windows 7 - superseded "NO" - title (remove beta updates, or things you don't need, e.g. -"Internet Explorer 8" removes all IE8 updates, as we use IE9 already) - update classification "Critical Updates", "Security Updates", "Update Rollups", "Updates" and here comes the key part: - required >= 1 this last setting makes sure that only updates end up in the group that are actually required by our systems. note that i did not make any limitation to the release date of the updates, so the basic idea is to "include all updates that are required by systems to the software update group". this behaviour is exactly what we had with our old WSUS infrastructure. in my tests so far i can see that initially, the software update group contains a lot of updates. after two or three iterations of updating the clients and having them report back their state to the SCCM server, the number of updates with "required > 0" goes down, until at some point the update group is empty (as no client requires any more updates). i did not yet find out if the actual update files are also removed from the harddisks of our sccm servers. it the moment it doesn't seem so, but i will investigate. any input on this is appreciated.

hello again, i am trying to do all this with secondary sites. i have configured client push in my secondary site, however, the secondary site server never tries to install the client. (at least nothing i can see in the logs) i have correctly configured management points and boundary groups for the secondary site server. do we need to enable client push at the primary site? is it even possible to enable it only on the secondary site? for some reason it took just a full day to get things rolling. i have changed nothing, but now everything is installed as excpected. manually uninstalling and "system rediscover" triggers a fresh install on the secondary site server. good! edit: in the secondary sites "client push installation properties" i can specify "installation properties. SMSSITECODE=xxx should i set this to the code of the primary site, or to the secondary site? help appreciated... i have tested this intensively. it must be the primary site code, like in sccm2007. specifying the secondary site code will make the clients install, but then not show up as "installed client" in the devices list. cheers

Hello, and thanks for your helpful posts about sccm2012. i have two questions: 1) during wsus install, i am unsure about the flag "Store Updates Locally". other guides have this checkmark removed. as far as i understand, wsus only downloads the metadata catalog. sccm downloads the updates itself. would you still recommend to leave this checkmark ticked? are updates then downloaded twice (once for wsus, once for sccm)? 2) cleanup. our wsus and all secondary wsus instances are scripted to run a monthly cleanup task which removes no longer needed updates - this saves a great amount of disc space, especially on smaller secondary site servers. is it possible in a sccm2012 environment, with automatic deployment rules in place, to clean up no longer needed updates from the packages? or will the distribution points just grow as new updates arrive? thanks!

Hello anyweb, thank you for your excellent description of the solution. i implemented this on our SCCM 2007, and the user accounts appear in my "OCS.AllUsers" collection. i have then distributed our software package (ocs 2007 client in this case) to this collection, but no matter how hard i try, the users do not get the package. software distribution via computer objects works excellent in our environment. what am i possibly doing wrong?