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!
>
>
>
>
>
>


Reply via email to