I'm a little more lenient with SCCM (and most other System Center products) due to the fact that if it goes down for a little while while I restore from Veeam backup, users generally wouldn't notice or care. Now Exchange CUs----I usually let the "IT Marines" out there storm the beach first and soak up all the enemy fire before I deploy my troops.
On Wed, May 6, 2015 at 10:40 AM, Juelich, Adam <[email protected] > wrote: > Hey Satch, > > Generally it seems that the consensus is to do the CU's as soon as > possible for everything. That's what I've followed and was relayed to me > from some of the MVPs. > > > *-----------------------------------------------* > > *Adam Juelich* > > Pulaski Community School District <http://www.pulaskischools.org> > > Client Management Specialist > > 920-822-6075 > > > On Wed, May 6, 2015 at 9:32 AM, Al Corsi <[email protected]> wrote: > >> Good thread, thanks for the info... >> >> On a side but related note, and for the CUs, the download notice >> indicates "this hotfix has not undergone full testing.". At what point >> are you comfortable with deploying to your production sites? >> >> We're just standing up a new R2 site, and figure go straight to the >> latest! Regards, Al >> >> >> On Thu, Apr 30, 2015 at 03:08 PM, ccollins9 wrote: >> >> @Jeff Spengler, >> >> These links to MS's website explain it more. I am going to look into >> using the SCUP method instead of messing with and figuring out x86 vs. x64, >> etc. >> >> https://support.microsoft.com/en-us/kb/907423 >> >> http://blogs.technet.com/b/jamess_configmgr_blog/archive/2012/02/11/installation-of-configmgr-client-hotfixes-during-client-installation.aspx >> >> >> >> Also, I forgot to mention, using the package MS gives you produces this >> in the execmgr.log, which in turn treats the install as a failure because >> the upgrade causes ccmexec.exe to restart. So, yeah, probably the least >> best way of deployment IMO. With an application, it would use the >> deployment criteria to check for actual installation afterwards and report >> correctly. >> >> Running "C:\Windows\ccmcache\2d\ccmsetup.exe" /noservice SMSSITECODE=AUTO >> with 32bitLauncher execmgr 4/30/2015 2:57:47 PM 49104 (0xBFD0) >> Service stopped while program Configuration Manager agent silent upgrade >> is running execmgr 4/30/2015 3:04:16 PM 58384 (0xE410) >> OpenProcess failed for process 45504, error 80070057 execmgr 4/30/2015 >> 3:04:16 PM 58384 (0xE410) >> Can not continue monitoring the program after service restart because the >> process exited. Assume failed execmgr 4/30/2015 3:04:16 PM 58384 >> (0xE410) >> >> >> >> >> >> >> >> >> On Thu, Apr 30, 2015 at 2:18 PM, ccollins9 <[email protected]> wrote: >> >>> Remember, I am not only deploying CU4, but I am also deploying the >>> upgrade for the R2 client at the same time. Slipstreaming an update into >>> the initial install of an application is usually preferable to most people, >>> otherwise we as admins wouldn't be bending over backwards to often find >>> ways of doing it for various MS products. Their also wouldn't be blog >>> after blog on technet explaining how to do it. >>> >>> I get that MS provides a CU4 package, but I really don't understand why >>> everyone is being so dogmatic about using it when we all know that >>> applications are better in most every way. Just because MS provides us the >>> bare minimum to update the clients (packages), it doesn't mean we can't >>> that and improve it. Packages are archaic and require babysitting and many >>> times redeployment or recurring deployment. I stopped using them years ago. >>> >>> I do like the SCUP idea, I am going to look into that as well because >>> using Software Updates would afford the same level of automation. >>> >>> >>> >>> On Thu, Apr 30, 2015 at 2:02 PM, Azeem Patel <[email protected]> >>> wrote: >>> >>>> As metioned earlier CU4 update on server creates a deployment package. >>>> >>>> If you want to do in controlled manner, few systems at time. THEN >>>> >>>> Create collection for CU4 update and deploy CU4 package on the >>>> collection. >>>> moving systems set by set for installation. >>>> >>>> >>>> >>>> >>>> On Thu, Apr 30, 2015 at 10:05 PM, ccollins9 <[email protected]> >>>> wrote: >>>> >>>>> Thanks Justin! >>>>> >>>>> On Thu, Apr 30, 2015 at 12:31 PM, Justin Chalfant < >>>>> [email protected]> wrote: >>>>> >>>>>> Guide here: >>>>>> http://blogs.technet.com/b/jchalfant/archive/2013/06/23/installing-configuration-manager-sp1-cumulative-update-2-patches-using-scup.aspx >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>>> >>>>>> *Justin Chalfant* >>>>>> >>>>>> Premier Field Engineer - Configuration Manager >>>>>> >>>>>> Public Sector >>>>>> >>>>>> Microsoft Services >>>>>> >>>>>> >>>>>> >>>>>> Tel : (303) 846-2701 >>>>>> >>>>>> Email: [email protected] >>>>>> >>>>>> >>>>>> >>>>>> If you have any feedback about my work, please let either myself or >>>>>> my manager Rusty Gray know at [email protected] >>>>>> >>>>>> >>>>>> >>>>>> *From:* [email protected] [mailto: >>>>>> [email protected]] *On Behalf Of *Jason Sandys >>>>>> *Sent:* Thursday, April 30, 2015 10:28 AM >>>>>> *To:* [email protected] >>>>>> *Subject:* RE: [mssms] 2012 R2 CU4 update >>>>>> >>>>>> >>>>>> >>>>>> Because it's a patch and not an application. Honestly, the best >>>>>> option for this is SCUP and Software Updates because that's designed for >>>>>> patches. >>>>>> >>>>>> >>>>>> >>>>>> J >>>>>> >>>>>> >>>>>> >>>>>> *From:* [email protected] [ >>>>>> mailto:[email protected] >>>>>> <[email protected]>] *On Behalf Of *ccollins9 >>>>>> *Sent:* Thursday, April 30, 2015 8:34 AM >>>>>> *To:* mssms >>>>>> *Subject:* Re: [mssms] 2012 R2 CU4 update >>>>>> >>>>>> >>>>>> >>>>>> Yeah, I know it creates those packages. I don't like using packages >>>>>> when I can avoid it. I'd be curious to know why MS has the CU4 installer >>>>>> create packages instead of applications, but that's now really germane to >>>>>> this discussion. >>>>>> >>>>>> >>>>>> >>>>>> I got it figured out---seemed to be just an issue with that one test >>>>>> machine. I ended up rolling the patch into the install/upgrade with >>>>>> (ccmsetup.exe PATCH=xxxx) and having the application's detection criteria >>>>>> check for both the R2 productID and the 5.0.7958.1501 (CU4) patch level. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> http://blogs.technet.com/b/jamess_configmgr_blog/archive/2012/02/11/installation-of-configmgr-client-hotfixes-during-client-installation.aspx >>>>>> >>>>>> >>>>>> >>>>>> It's working well so far on other machines and I get the added >>>>>> benefit that if it fails it will retry because it's an application. >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Apr 30, 2015 at 3:11 AM, Mawdsley R. <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Yes, providing you selected the option when you upgraded the >>>>>> server, it would have automatically created client (and server) update >>>>>> *packages* for you located under: Software Library>Application >>>>>> Management>Packages>Configuration Manager Updates. >>>>>> >>>>>> >>>>>> >>>>>> Just deploy these (remember to distribute), it's what they are there >>>>>> for J. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> You could even make device collections with a query to automatically >>>>>> show you what machines have or have not been upgraded. >>>>>> >>>>>> >>>>>> >>>>>> Rich >>>>>> >>>>>> >>>>>> >>>>>> *From:* [email protected] [mailto: >>>>>> [email protected]] *On Behalf Of *ccollins9 >>>>>> *Sent:* 29 April 2015 23:33 >>>>>> *To:* mssms >>>>>> *Subject:* [mssms] 2012 R2 CU4 update >>>>>> >>>>>> >>>>>> >>>>>> This has been kicking my butt all day. Our system was SCCM 2012 >>>>>> SP1. I upgraded the site server to 2012 R2 CU4. I now need to update the >>>>>> client systems >>>>>> >>>>>> >>>>>> >>>>>> I know I can do automatic upgrade, but I also want to create an >>>>>> application for the new client to target machines during a maintenance >>>>>> window before turning on automatic updating. >>>>>> >>>>>> >>>>>> >>>>>> I created an application basically just using the same install >>>>>> command that the built-in update package uses after installing R2. I >>>>>> have >>>>>> the detection criteria set to look >>>>>> for {8864FB91-94EE-4F16-A144-0D82A232049D}. >>>>>> >>>>>> >>>>>> >>>>>> Anyway, it's doing something I've NEVER seen in all my years working >>>>>> with SCCM 2012. >>>>>> >>>>>> >>>>>> >>>>>> The application starts and I'm viewing the AppEnforce.log: >>>>>> >>>>>> >>>>>> >>>>>> "Waiting for process 6920 to finish. Timeout = 15 minutes" >>>>>> >>>>>> >>>>>> >>>>>> And there it sits, FOREVER. Long past the 15 minute timeout. >>>>>> ccmsetup.exe is tied to process 6920 in this case. It starts, uninstalls >>>>>> ccmexec.exe, reinstalls it, then ccmsetup.exe closes, meaning process >>>>>> 6920 >>>>>> closes from the list of running processes. Yet there it sits. So the >>>>>> client is successful, but it never seems to "finish" properly. My >>>>>> initial >>>>>> thought is that it is getting messed up because it's the client and it's >>>>>> reinstalling, so who knows how that will make the logs look to me. I >>>>>> knocked down the timeout down to 15 minutes to at least see if it >>>>>> terminates itself with an error, but no, it just sits. >>>>>> >>>>>> >>>>>> >>>>>> How are others deploying UPGRADES to SCCM 2012 R2 clients? And for >>>>>> that matter, how are folks handling the subsequent client update to CU4? >>>>>> >>>>>> >>>>>> >>>>>> Are y'all just using the built-in packages and hoping they work? I >>>>>> wanted to try it as an application because: >>>>>> >>>>>> >>>>>> >>>>>> A. it would check for failure and try again until it was successful >>>>>> >>>>>> B. I created an app for the R2 upgrade and another one for the CU4 >>>>>> patch, then made the CU4 patch application depend on the R2 Upgrade >>>>>> application >>>>>> >>>>>> >>>>>> >>>>>> Am I just making this all harder on myself? >>>>>> >>>>>> >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> -Regards >>>> Azeem >>>> [email protected] >>>> +91-9892411957 >>>> Linkedin Profile >>>> <http://qa.linkedin.com/pub/azeem-patel-mcsa-mcts-exchange-vcp-itil/33/2aa/510/> >>>> >>>> >>> >>> >> >> >> > >
