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]<mailto:[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 :).

[cid:[email protected]]

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]> 
[mailto:[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!








Reply via email to