Introduction
Installing this update is very similar to previous versions but a few things have changed since I did the last post on CU updates. In this blog post, I’ll walk you through the upgrade process step-by-step in a standalone primary scenario.
The full list of fixes and a link to request the hotfix is available here: http://support.microsoft.com/kb/3026739/
As always, you should start by checking the health of the system, verify the backup, etc.
At a minimum, you should check the following:
- Install any missing updates (security, critical and important).
- Verify you don’t have a pending restart.
- Verify that you have a valid SQL backup.
- Verify that the current installation of ConfigMgr is healthy.
- Verify that ConfigMgr 2012 R2 has been installed.
Download the update
After we have checked that the system is healthy, we need to download the update. SCCM 2012 R2CU4 is available for download here: http://support.microsoft.com/kb/3026739/
This update can be applied directly to the following Systems/Roles:
- The Central Administration Site (CAS)
- Primary Site
- Secondary Site
- SMS Provider
- Configuration Manager Console
Update the Site Primary Site Server
To start the installation, log on to the Primary Site Server, and run “CM12-R2CU4-KB3026739-X64-ENU.exe“. The default settings should be ideal for most customers.
Note: You can follow the installation process in the “C:\Windows\Temp\cm12-r2cu4-kb3026739-x64-enu.log” file.
On the Welcome Screen, click Next.
Accept the license and click Next.
On the Prerequisite Check page, make sure to click “View Log”. This will open the setup log file and allow you to monitor the process as we move forward. Click Next.
If you check the log file, you’ll find all kinds of interesting information. Like the current CU Level.
Continue to follow the setup wizard. Default should be suitable for most.
Yes… Please update the database…
On the Deployment Assistance Options page, make sure all boxes are selected and click Next.
Continue through the wizard and accept all the default settings for creating the update packages.
Keep monitoring the process.
For most ConfigMgr Admins, the log file might be more fun compared to the UI. 
When the job is done, complete the wizard and click Finish.
Verify that the setup was successful
After the setup is complete, there are a few things you can and should do to verify that setup was successful.
The first thing you should do is check the log file. But if you followed this guide, you have already done that.
The next thing you should do is Launch the System Center 2012 Configuration Manager Console directly on the Site Server and verify the build number of the console. If the upgrade was successful, the build number should be 5.0.7958.1501.
If you right-click and select “Properties” of the Primary Site to check the version number, you will notice that the build number is 5.00.7958.1000 (R2 RTM). This is expected; CU updates do not update the site server version.
An overview of all versions and build numbers can be found here: https://www.ronnipedersen.com/2014/07/configmgr-2012-versionbuild-numbers/
For additional verification, you may also check the CULevel registry data under HKLM\Software\Microsoft\SMS\Setup\. If the upgrade was successful, the value should now be “4”.
Update the Boot Images
As a best practice, I always recommend to update the boot images.
Just right-click your boot image and select Update Distribution Points.
Updating Clients
The packages for SCCM 2012 R2 CU4 were created as part of the setup wizard but we need to distribute the packages to all distribution points before we deploy them.
Locate the new packages here:
\Software Library\Overview\Application Management\Packages\Configuration Manager Updates\
Select client packages. Right-Click and select Distribute Content. (Just follow the wizard).
Creating collections
Before we can deploy the CU updates, we need to create some collections.
You can create them yourself or you can use PowerShell.
I’ve created a small PowerShell script that will help you create the required collections for CU updates right here:
https://www.ronnipedersen.com/2015/02/creating-collections-for-cu-updates-using-powershell/
Deploy the updates
The default settings on the update packages are sufficient. However, I don’t want my users to get notified of this update so I prefer to suppress the program notifications.
I use maintenance windows for all of my servers, but this update in particular, I want to deploy now. So for this update, I will ignore the maintenance windows.
On the User Experience page of the Deployment Wizard make sure that Software installation will be performed outside maintenance windows.
That’s it… Deploy the package to the right collection, sit back and monitor the reports.
It goes without saying that you should test this on a limited number of clients first!
That’s it..
Update: Don’t forget to delete the old packages from previous CU updates versions.
More info: https://www.ronnipedersen.com/2015/02/sccm-2012-r2-deleting-old-cu-packages-using-powershell/
Enjoy.
34 Comments
Pingback: Cumulative Update 4 for System Center 2012 R2 Configuration Manager released! | Tim DK
Hello,
Do I have to apply CU 2,3 before I install CU4?
No. This update replaces Cumulative Update 3 and earlier updates for System Center 2012 Configuration Manager R2.
I’d also recommend, post CU4 installation, monitoring the sitecomp.log and waiting until any and all site role re-installs that the CU4 triggers to complete before doing anything further.
I totally agree. But this is a “quick start guide”, so I wanted to make it short.
But your feedback is absolutely valid, so I’ll update the post to include this validation step.
Thank you.
Hello,
Is it safe to execute update during daytime while in production ?
No problem when the functionality is not available but will the update not fail ?
Greetings,
Hanna
It’s a safe… Many of my customers has clients all over the world, and we can ask them all to go home 🙂
I’ve upgraded 3 customer sites today. All of them during normal work hours.
Ronni, could you add post how to install this CU4 in OSD TS or PUSH installation?
1. You can install the CU update using the PATCH parameter (not sure if it’s still supported, but I know it works).
2. You can’t update the CU update using Client Puch. It would simply just reinstall the R2 RTM version (build 1000).
Collection queries can also be generated using the Microsoft Site Servicing Extension
http://happysccm.com/Microsoft-will-make-them-Update-Collections-for-you
Try it out!
That is correct. But using a PowerShell script is still much easier 🙂
And my query is better too 🙂
Example:
My query checks for the major version too… You cant upgrade a 2012 SP1 CU3 client to R2 CU4, so you need to validate that the client is at least at CU4
But… It is a good start 🙂
I get this 🙁
Distribution Manager has not tried to install IIS component of operating system to distribution point “[“Display=\SCxxx”]MSWNET:[“SMS_SITE=xxx”]\xxx”. You should install and configure IIS manually. Please ensure RDC is also enabled.
I know this an old post, but I’m trying to catch up on all comments.
Did you fix it?
This guide is perfect 🙂 Updating SCCM 2012 R2 to CU4 was smooth
Thank you! 🙂
I also get the Distribution Manager “warning” after installing this update. What could be causing this issue?
Did you check the log files?
Hi, looking for a bit of advice – do you recommend that everyone installs the CU’s?
I’ve setup my SCCM 2012 R2 site and am about to migrate from 2007 but the MS info says “WARNING This hotfix has not undergone full testing. Therefore, it is intended only for systems or computers that are experiencing the exact problem that is described in the one or more Microsoft Knowledge Base articles that are listed in “KB Article Numbers” field in the table at the end of this e-mail message”
Should I update before migration?
Then should i update to CU5 when it comes out once i’ve migrated- or only if i then experience issues? Thanks- feeling a little lost here!
That is a standard comment for all these updates. CU3 had the same disclaimer and CU5 will have the same (most likely) 🙂
I would recommend that you install CU4.
Ok, thanks for the advice. I will do! 🙂
Did the upgrade on site server and supporters with consoles. I have remote distribution site. Do I need to run anything besides the client update on it?
I’m also supposing that the client update will cause a reboot on the client?
I’m curious, why the x86 and x64 separate client updates? I have always used one ccmsetup.exe for both 32 and 64 bit clients.
Hi Ed,
1. If you by “Remote Distribution site” means a remote distribution point, then no. All components will be updated automatically.
2. Normally the client update will not require a restart. But just in case, you should always suppress the restart anyway.
3. The CCMSETUP.EXE will detect what architecture you nee, and then just the matching version.
Why did MS not just make one update? I can’t give you a good answer to that. You should ask Microsoft about that 🙂
Thanks for the answers!
I have a supporter in another building, that I have pushed the console update to, that is getting Configuration Manager cannot connect to the site
The configuration manager console cannot connect to the configuration manager site database. Verify the following: (I type too slow to type all the things listed
My system and my boss’s system is connecting just fine from our computers.
Does CU4 updated the base client? or do you always have to push the update package?
When I create a new machine and sccm installs the client it is still version .1000
Thanks,
Randy
Yes. The CU Update is a separate deployment. if you push a new version, it will be CU0 (RTM).
Last week I installed the update following the same process you outline above and everything seemed to be working until I heard from a technician that the current method used for installation wasn’t working. Because of a spin into two companies our AD is currently shared and we cannot have the client install manually so we either to it via the console or via a cmd to the.exe on the file (nts#sccm2012ccmsetup.exe SMSSITECODE=AUTO SMSSLP=nts#.dc=.dc=.com FSP=nts#.dc=.dc=.com).
Currently the client install from the console is still installing the old client, which if what I have read is actually expected behavior and the update has to be pushed from the packages but I’m not certain why the cmd line simply fails to do anything. What’s even stranger is that our old SCCM 2007 server is now displaying in the ccmeval.log in the FSP= field.
I’ve read some posts regarding the issues with the ccmsetup.xml file inside the ccmsetup.cab and when I review this even on machine’s that have been updated via the package created by the update it is referencing the .1000 version of the client instead of the .1501 version. Is there a step I missed, do I have gremlins or is what I am seeing expected behavior?
If I understand you question correct, I can confirm that this is by design.
When you install the client is will be the main version (.1000) by design.
The CU4 update (.1501) should be deployed as a separate deployment.
Thank you for the reply, it’s appreciated.
Thanks for the guide. Perhaps you can help with an issue. I created a deployment from the installs client update. The x64 is going fine, but the x86 has about 35% failure so far. The execmgr.log error is “The exit code is 1642, the execution status is FailureNonRetry” Can’t find any documentation. Any ideas?
This is a generic failure. The only way would be go go though the log files.
If a client is at 5.00.7804.1600 or an earlier version, and the environment has been recently upgraded to R2 CU3, then then upgraded to CU4, does this client need to be upgraded to R2 (5.00.7958.1000) first, or can we go straight to CU4 ?
You need to upgrade to R2 first. Then you can apply the CU update.
We have problem with ccmeval task on client where we have updated client to CU4 via msu package.
Problem is that client itself is upgraded to version (1501), but install files inside c:windowsccmsetup
Are still on version (1000). If ccmeval task recognize that something is not ok, then try to reinstall client. If you look inside ccmsetup-ccmeval.log setup files are taken from c:windowsccmsetup location. They all too old and CM client perform »self-destroy action«. Reinstallation newer finish. Client is death till you don’t install client via push method.
2012r2sp1cu4 1 parent 50 2nds post cu4
help – mp role now reinstalling on parent and all secondary’s over and over. exact same thing happened in cu3
all servers show cu4 installed successfully after reboot bit how to I stop the bootstarp from trying to re-install the mp role every ~60 minutes.