CU5 was just released :) 
https://support2.microsoft.com/kb/3054451/en-us?sd=rss&spid=1060

-Stephen

> On May 6, 2015, at 11:57 AM, Barnes,Chris <[email protected]> 
> wrote:
> 
> I would make sure to update the clients with the CU quickly after the Primary 
> is updated. We ran into an issue with the primary at R2 CU4 and the clients 
> at R2 no CU, where the clients would generate 25-30MB of global catalog and 
> LDAP traffic if they happened to have other patches install and cause a 
> reboot.
>  
> We held back on the CU4 client side patch until after our scheduled monthly 
> patches, and the resulting traffic took down our entire WAN for almost a day.
>  
>  
> Chris Barnes
> Senior Technical Specialist
> Penske Automotive Group
> (248) 648-2528 Direct
> (248) 767-4415 Mobile
>  
> 
>  
> From: [email protected] [mailto:[email protected]] 
> On Behalf Of John Aubrey
> Sent: Wednesday, May 6, 2015 10:00 AM
> To: [email protected]
> Subject: RE: [mssms] 2012 R2 CU4 update
>  
> Same here, System Center updates are pretty quickly deployed.  If the user 
> doesn’t notice, we tend to do those during the day and quickly.
>  
> From: [email protected] [mailto:[email protected]] 
> On Behalf Of ccollins9
> Sent: Wednesday, May 6, 2015 10:46 AM
> To: mssms
> Subject: Re: [mssms] 2012 R2 CU4 update
>  
> 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
> 
> 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]] 
> 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
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> 
> 
> Penske Automotive Group and its affiliates will never sell or rent your email 
> address in violation of applicable law. This email and any files transmitted 
> with it are confidential and intended solely for use of the individual or 
> entity to whom they are addressed. Please delete all copies if you are not 
> the intended recipient.
> 

Reply via email to