A new Resultant Client Settings option allows you to view the effective client settings that will be applied to the selected device.

Ability to reassign clients, including managed mobile devices, to another primary site in the hierarchy, individually or in bulk.

Wipe and retire functions now include the option to only remove company content from devices.

Deployment of remote connection profiles that allow users to remotely connect to work computers from the company portal, when they are not connected to the domain or if they are connected over the Internet.

Deployment of user and device certificates for managed devices by using the Simple Certificate Enrollment Protocol (SCEP) for Wi-Fi and VPN connections on iOS, Windows 8.1, RT 8.1, and Android.

Deployment of root certification authority (CA) certificates and intermediate CA certificates, so that devices can create a chain of trust when they use server authentication for network connections

Deployment of Wi-Fi profiles that provision devices with the settings and certificates that they need to access corporate Wi-Fi hotspots on on iOS, Windows 8.1, RT 8.1, and Android.

New maintenance window dedicated for software updates installation.

You can now change the deployment package for an existing automatic deployment rule.

You can now preview software updates that meet the property filters and search criteria that you define in an automatic deployment rule.

Web applications – a new deployment type that allows you to deploy a shortcut to a web-based app on users’ devices.

Support for boot images based on Windows PE 3.1.

Virtual hard disk management which allows you to create and modify virtual hard disks, and upload them to Virtual Machine Manager.

Pull-distribution points support the prioritization of their source distribution points.

Pull-distribution points push status for completed actions to the site server (instead of distmgr having to poll each Pull DP periodically).

From the Distribution Status node in the Monitoring workspace of the Configuration Manager console, you can cancel distributions that are in progress to a distribution point, and redistribute distributions that have failed. SWEET!

You can use the new built-in report named Distribution point usage summary to view details about how individual distribution points are utilized, including how many unique clients access the distribution point, and how much data transfers from the distribution point. REALLY SWEET!

Clients that use Windows BranchCache to download content and that have a download interrupted now resume the download where it left off, without having to restart the download from the beginning. NICE!

These additional (and very exciting!)

optimizations are introduced to improve performance during deployment of content:

Each time Configuration Manager transfers content to a distribution point, it calculates the speed of the transfer. During subsequent content deployment, this information is used to prioritize which distribution points receive content first. This is done to maximize the number of distribution points that receive content in the shortest period of time.

To improve concurrent distributions, when Configuration Manager validates content on distribution points, it validates up to 50 files during each WMI call to a distribution point. Prior to R2, we used a single WMI call to a distribution point to validate each individual file.

Reports are now fully enabled for role-based administration. The data for all reports included with Configuration Manager is filtered based on the permissions of the administrative user who runs the report. Administrative users with specific roles can only view information defined for their roles.

<Uber Important Stuff!!!>

Be sure to read through the planning article and notes at http://technet.microsoft.com/library/gg682075.aspx to understand interoperability behaviors between ConfigMgr versions if you’ll be running mixed versions. Your ConfigMgr 2012 hierarchy must be running a minimum of 2012 SP1 in order to upgrade to 2012 R2.

If you’re close to or above 100,000 clients, have an above average amount of politics, or just enjoy extra complexity and therefore have a CAS, start the process on the CAS and work your way down the hierarchy. Otherwise, just upgrade your stand-alone primary and you’re done.

Now that you’re drooling over all the new features you’re about to get which will make your life easier and more complete, let’s get on with the fun part!

The 2012 R2 Upgrade Process…

Step 2: Download Windows 8.1 ADK from http://www.microsoft.com/en-us/download/details.aspx?id=39982. If you have more than one site server to upgrade, select the option to Download for installation on a separate computer. This will save you some time on the remaining site servers. Otherwise, if you’re lucky and only have one site server, select the option to Install the ADK to this computer.

Once the ADK installation is complete, run the splash.hta within the Configuration Manager 2012 R2 ISO.

The next few screens should be pretty self explanatory, so I’ll safe you some bandwidth and forgo going into to much detail. However, I have pasted them below for your reference so you will know what to expect during a smooth R2 installation – which I’m sure you will have!

The product key is the same product key you entered during your Configuration Manager 2012 installation, unless you’re installing the evaluation edition.

If you are installing the R2 upgrade to more than one site server, be sure to download the required files to a UNC path so you can re-use them on the next site server upgrade.

The prerequisite check will run, and if your SQL installation isn’t local, it will remind you of the importance of reserving a minimum of 4GB for a secondary site SQL database and 8GB for a primary site SQL database. Hopefully you have already done this recommendation during your initial site database installation. If not, make sure it’s on the top of your to-do list!

Be sure to resolve any other critical issues that may come up during this check. If you have any site roles running on a server in an untrusted domain, you’ll likely see some warnings about not being able to pre-check those servers, but they won’t prevent you from proceeding.

Once completed, you’ll have a nice stack of green checkmarks, or if upgrading a Primary site, for a period of time you’ll likely see some green checkmarks, and some blue arrows in a circle. Monitor sitecomp.log to see any additional site roles on remote servers being upgraded, and if you haven’t closed this dialog, you’ll notice that eventually all the blue arrows in circles turn into green checkmarks.

For an extra-extra confirmation, click the ‘View Log’ button, and you’ll see a log entry letting you know that your site upgrade completed without any issues.

Repeat this same process for any primary sites you might have until all of your sites are completely upgraded.

Once all sites are upgraded, upgrade any stand-alone ConfigMgr Admin consoles. The Admin Console on each site server will be automatically upgraded, so you can use these to check things out after the upgrade. For R2, the site version is 5.00.7958.1000. Clients will show version 5.00.7958.1404 once upgraded to CU3.

Allow some time for your site resets to complete and any DRS replication to resume normal operations, and check out your Monitoring section in your shiny new admin console to insure things are replicating and happy. Don’t be alarmed if your DRS monitoring link state shows “Link Degraded” for a little while. I recommend waiting a good 15-30 minutes to allow DRS to get caught up before starting to worry. Monitor your rcmctrl.log on each site server, and rcm.box inboxes to watch the BCP processing the cab files process and to verify replication is resuming normally.

If you have Automatic Client Upgrades enabled, clients will automatically upgrade to the new R2 client version within the number of days you have this feature set for. If not, you will need to push out the new client version out using SCUP or by creating a package using the content from the Configuration Manager Client Package which was automatically updated and distributed to your DPs after the upgrade process.

To upgrade all your remote administrator consoles, you can use the following Collection query:

The best way to avoid any restart requirements would be to pre-deploy all minimum requirements which may require a reboot in advance. If a specific pre-requisite is not listed in software updates, you could deploy them as a package or application in instead.

Yes, SCCM relies on WSUS underlying framework to deliver updates. So WSUS is a requirement but easy to install. If you use Server 2012 or 2012 R2 OS for your WSUS server (which you should) you won’t need any WSUS hotfixes, so this is what I recommend for the OS WSUS is on. If your environment is not large or you have an abundance of compute power, you could run the WSUS/SUP role on the primary site server. Typically I recommend off-loading whenever possible, but I work in some moderate-large sized environments. Install WSUS role and then add the SUP role and SCCM will take the config from there. Do not do any configurations in WSUS admin console, and find out what WSUS GPOs you’re applying (if any) and be very careful which you do apply. SCCM does not need many as the SCCM client defines the client updating activities through its policies.

Hi Russ, thanks for posting this. It was helpful for our upgrade to R2.

Your Collection query to upgrade the remote administration consoles is wrong, though. It is looking for computers with “System Center 2012 R2 Configuration Manager Console” installed, but it needs to be looking for “Microsoft System Center 2012 Configuration Manager Console”. Checking the version number is redundant because the product name string for the new version is “Microsoft System Center 2012 R2 Configuration Manager Console”, so the query below is sufficient:

Our client push method is done by GPO, once the R2 upgrade has completed on my primary site and all new client files have been distributed to all my DP’s, when the computers will restart they will automatically get upgraded?

Not sure what you mean by “Where can I see the update R2 for the client.” It doesn’t create a separate package to push out, it updates the client bits and distributes them to all your DPs, and if you have automatic client upgrade enabled, it upgrades them automatically.

Yes, you can create a package for the CCM client and add the switches to the command-line. You can push the client out with your 2007 environment if you’re migrating. If you’re installing a brand new environment so you can’t push a package out, GPO is probably the way to go.

The only requirement for Silverlight comes from the Software Center and Application Catalog. If you do not plan to allow any self-service from managed workstations (even for your technicians), you can choose not to deploy Silverlight to those individual clients.

Thank you for the post, however after installing the Windows 8.1 ADK, the splash.hta does indicate that it has detected a previous installation, but it does not give the option to upgrade, the only options available are “Recover a site” and “Uninstall this Configuration Manager site”.

Russ, Thank you for everything you do for us.
Quick question, I currently do not have a WSUS Server, I am seting up a SCCM 2012 R2, can I use the software update Point Role to be able to update my Systems?
Thank you

You cannot upgrade a site to System Center 2012 R2 Configuration Manager until all sites in the hierarchy run System Center 2012 Configuration Manager with SP1. The version of cumulative updates for Configuration Manager that are installed at sites is not evaluated and you can upgrade a System Center 2012 Configuration Manager SP1 site regardless of the cumulative update version that is installed, or even when no cumulative update is installed. http://technet.microsoft.com/en-us/library/jj822981.aspx#BKMK_UpgradeR2Checklist

No. You’ll need to make sure you update the files that your GPO is using for the application assignment of the client install for new installs. I’m assuming this should work for the upgrade http://technet.microsoft.com/en-us/library/cc783421(v=WS.10).aspx but I would recommend testing first on a small test OU.

So, lets say you've got 130 Secondary Sites attached to a single Primary site. No CAS. Will those secondary sites continue to function for, say, OSD after the R2 upgrade occurs on the Primary and the the new WinPE is distributed out to all of my PXE-enabled secondary sites? Or do they need to be upgraded to R2 via the console before they will work?

You can just check the "Automatic Client Upgrade" box, or use SCUP or push them out manually. I recommend using Automatic Client Upgrade and spreading it out over a few weeks or a month depending on the number of clients and bandwidth, it's the easiest way.

Wanted to ask just upgraded the sccm primary and all the sec sites to R2.

Also deployed KB 2905002 to the primary site.

SCCM console and the site version in 5.0.7958.1000 however after installing the patch on the client the client verison increases to 5.0.7958.1101 is this right? site version less then the client version?

Secondly..it didnt update the default client package with this update so what needs to be done to incluse this update in the Build?

That's correct, the admin console version and site version will still show 5.00.7958.1000 and the client version will be .1101. You can deploy the update as a required deployment, use SCUP to deploy it, integrate it with the PATCH= command, etc, as it will not be merged into the client install so you'll always install the R2 client and then install the upgrade next.

You should just need to run the Discovery Data Collection Cycle after upgrading the client. Check your configuration manager applet in control panel on your client and make sure the upgrade installed and SMS Agent Host service restarted afterwards – it can take a few minutes. Then run the Discovery Data and wait a bit for it to process. And if you have a CAS and are connecting to it vs the primary the clients are assigned to, it will take a few more minutes for it to replicate (or you can connect your console to the primary to check it there.)

Thanks for the awesome article. If we are running our site database on a full version of Microsoft SQL 2008 R2 do we need to do anything differently before, after, or during the installation of the upgrade?

Not sure what you mean by a full version (you can't use SQL Express for a primary site), but just make sure you're running at least the minimum supported SP/CU combination for SQL 2008 R2 (SP1 CU6 or SP2).

Can I check the situation with upgrading clients. Would previous clients , like say 2012 CU2 clients, still be visible to the new 2012 R2 console? We are looking to jump from 2012 CU2 to R2. We do not want to lose visiblity of workstation and server clients.

Just to make you aware I had an issue with my management points where the difference in version number between the site and client was preventing the client from installing on management point machines. I had to delete the CN= folder from system>system management in ADSI edit before I could manually upgrade the client and push the management point upgrade through.

For the automatic client upgrade, does this upgrade the R2 SCCM client and the R2 SCEP client? (R2 SCEP version looks to be 4.3.220). Also if the scep client requires a reboot to complete the installation, how is this handled via automatic client upgrade
i.e. does it just do the reboot, or does it respect client settings for endpoint i.e. if reboots are suppressed then no reboot will occur? Also does the automatic client upgrade respect maintenance windows i.e. upgrades of the clients only occur during maintenance
windows? Otherwise there doesn’t appear to be a satisfactory way of rolling out client upgrades to test/dev/qa/prod as opposed to a random all at once approach.

Thank you for your quick answer, Russ. As i mentioned i am deploying the agente vby GPO (batch with switch to no sylverlight), is there any other way in this version where i can do this in the management console?

I know the solution is to use FEP2010GPTool to publish the exceptions to group policy, but that should not need to happen, Microsoft products should work better together. I bet the two departments are pointing fingers at each other. Group Policy team says "System
Center team you fix it" , System Center team says "Group policy team you fix your reporting of the error"

Hi Russ, very clear the steps, but after upgrading to R2 from sp1 cu3, and the client being updated as well to 79??.1000 , I am not able to capture an image from windows 8.1. I am using a TS created for capturing windows 8 (I pointed it to the new boot
image) and is still working for capturing W8 reference computers. The process start well but crash capturing the operating system or maybe doing sysprep. Can you give me your opinion and where should I start looking for? I mean, which log files, similar problems
posted online. Thanks in advance.