|Posted on: Friday, May 30, 2014 3:06 PM
Subject: Sideloading Store Apps to Windows 8.1 DevicesView article…The term sideloading refers to the installation of Store Apps by an IT Administrator on a Windows device. Typically, the App in question is a line of business (LOB)application that is internal to the company. Therefore, the company (maybe your customer if you are and ISV) will want to make it available only to its employees rather than making it publically accessible Windows Store. This is not to say that there are no LOB Store Apps published in the Windows Store. Have a look at the SAP client Apps, for example.
There a three aspects that you may have to deal with when considering LOB sideloading: licensing requirements, technical requirements and management of sideloaded apps. You will want to understand all of them to understand if there is additional cost, how plan for the best way to enable your devices for sideloading or what are your options for handling new App version updates. Let´s have a look then.
1. Sideloading Licensing Requirements
Sideloading functionality is available “out of the box” for Windows 8.1 Professional and Windows 8.1 Enterprise but only if they are domain-joined. The addition of the Professional edition is new and has been announced as recently as April 2014:
“Easier Deployment – Delivering Windows 8.1 Update via Windows Update allows businesses to deploy updates with increased predictability. And, to help businesses develop and deploy modern apps for their workforce, we are enabling sideloading for any domain-joined Windows Pro PC or tablet”
The Windows 8.1 Professional, Windows 8.1 Enterprise that are not domain-joined and the Windows 8.1 RT edition (that cannot be domain-joined) still can be enabled for sideloading but will require a sideloading key that has to be installed and activated on the device. It is a multiple activation key (MAK) and you can obtain it from the reseller.
page 12 and further has a full detail in section “Windows 8.1 Enterprise Sideloading”.
Typically, the sideloading activation key will have to be acquired by to owner of the operating system license. So how much it is going to cost? Well, the thing to check is if you have existing volume licensing Enterprise Agreement with Microsoft. The licensing guide mentioned above lists all of the programs that include them free of charge as of 1 May. If you are in a qualifying licensing program, just contact your reseller who will make the keys available to you.
If you do not have a qualifying volume licensing program then you can purchase from a reseller unlimited number of sideloading activation keys for approx. $100 through the Open contract as also mentioned by . The best thing is to contact the reseller that you normally work with to check out all these options for your particular case.
So in summary, if you are dealing with devices that will not be in domain and you want to install LOB Store App you will need the sideloading activation key. Before you attempt the installation, however, the devices will have to be prepared by your IT pro, so read on.
2. Technical Requirements for Sideloading
There are three technical requirements that have to be met by the device before you attempt to install Store App on it regardless if you are doing it manually, via Powershell scripts or via Mobile Device Management system such as Windows Intune. You will find them explained in
but here they are summarized and I illustrate them with screenshots taken on Windows 8.1 Professional with Update 1 that is not domain joined and therefore requires all the steps.
1. Enable the Windows Registry key HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Appx\AllowAllTrustedApps = 1.
If you are dealing with domain joined device you get this key set via group policy Allow all trusted applications to install. If you are preparing a device that will not domain joined you will most likely find out that the Appx in not present in HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows. In that case: a) create a New Key named Appx b) right click the Appx node you just created and select New-> DWORD (32-Bit) Value, assign it a Name AllowAllTrustedApps c)right click the DWORD you just created and select Modify and type 1 in the Value Data. You should have an entry as per figure below:
Figure 1. AllowAllTrustedApps Windows Registry Key2. Ensure that the
2. Ensure that the code signing certificate has been issued by a trusted certification authority.
All Store App packages are signed with a code signing certificate. If the developer uses an Authenticode code signing certificate that has been purchased from common certificate authority (e.g.: Symantec, VeriSign) then you do not need to take an action because the root certificates for these authorities are already present in the Local Machine\Trusted Root Certification Authority certificate store. However, if the application package has been signed with the certificate emitted by customers own Certification Authority or the developer used the self-signed certificate generated by Visual Studio then you will have to make sure the root certificate is present in the Trusted Root Certification Authority store.
You can locate the code signing certificate in Visual Studio solution by looking up the application manifest as shown in the figure below
Figure 2. Application Manifest with code signing certificate
Configure Certificate button allows developer to pick existing code signing certificate from the certificate store a file or get Visual Studio to generate a self signed certificate. If you click the View Full Certificate button you can get the full certification path, copy the certificate to a file, etc. When the Store App is packaged (using the Store->Create App Packages option) the code signing certificate will also be available in the AppPackages solution subfolder. So if you are using self-signed certificate you could just pick it up together with the .appxbundle that contains the application package and take both to your target machine.
On the device that you want to configure simply double click the self signed certificate (.cer) file, select Install Certificate and then in the Certificate import Wizard select Local Machine as the Store Location instead of Current User that will be selected. In the next step select Place all certificates in the following store and browse for the Trusted Root Certification Authorities store to get it installed.
Should you install incorrectly then on Windows 8.1 with Update 1 you will get explicit error message (on Windows 8 you may get more cryptic error HRESULT: 0x80073CFF) as per figure below:
Figure 3. Lack of root certificate error
If all is well the command will complete silently and you should be able to locate the application installed. For domain joined machines you would be able to run the app at this stage, however, for cases that require sideloading key you will see the message App can´t open as in the figure below
Figure 4. App can´t open message
This is because we are missing the step 3 described below.
3. Install and Activate the sideloading key on the devices that require it (as described it in previous section).
There are two commands that we have to execute exactly as described in the “To activate a sideloading product key” section of the sideloading requirements: one to install the key and the second to activate it. You need Administrator privilege to execute these commands as per figures below:
Figure 5. Installation of the sideloading key
Note that the key you type here is the sideloading key that you have purchased from your reseller.
Figure 6. Activation of the key.
In this second step the string supplied (ec67814b….) is always the same because it is a guid that identifies the sideloading feature that we are enabling. If you are unsure if the device has already the sideloading key activated you can check it with command slmgr / dlv that will display the license information. Then scan it for the section with Name: APPXLOB-Client add-on and ensure that the line License Status is showing Licensed.
With all these steps concluded you can install and launch the Store Application successfully.
I should mention for completeness that in development environment you do not require sideloading key. The store apps can run thanks to the Developer License. This license is temporal and periodically will expire. If you are putting in production the machine that was perhaps previously a test machine you can check if it has developer license installed (Get-WindowsDeveloperLicense) and remove it (Unregister-WindowsDeveloperLicense) before configuring production sideloading key using the powershell commands documented in
3. Application Management
The licensing requirements and the technical requirements mentioned in the two previous sections have to always be met regardless of the actual method you choose for installing the applications. You have already seen that you can install the application using the Add-AppxPackage command. The command will take an application package (.appx) or the newer application bundle (.appxbundle) as an argument. You can use the Remove-AppxPackage to remove the application.
However, most customers will require more sophisticated solution to manage the application. They will want to assign specific LOB Apps to users in certain groups (Finance, HR) and will want to have a mechanism to install the new versions of the applications even for users with no access to domain.
Windows Intune offers a complete Mobile Device Management solution. It can help not only manage the applications but also (in case of Windows RT) activate the sideloading keys and install root certificates on devices that user enroll for management. Also Windows Intune integrates with System Center Configuration Manager that many customers already have deployed.
The end user has access to the Company Portal application that lists the applications that the Administrator made available in Windows Intune. The Company Portal is essentially a Store App that communicates with the Windows Intune tenant.
You can view two videos that show Windows Intune capabilities with respect to App sideloading:
Also you can see the commercial information in
The alternative to Windows Intune is to build this capability yourself. This could be as basic as the network share containing the scripts or a more complex application equivalent to the Company Store communicating with your package repository of choice (Azure Storage / SharePoint, etc.) but you would need to decide if the development effort would be worth it.
SC Configuration Manager 2012
Author: Enterprise Mobility Team
Subject: How-to deploy apps to mobile devices
|This is the fourth installment in my series on mobile device management (MDM) using Microsoft System Center 2012 R2 Configuration Manager and Windows Intune. If you haven’t read the previous three posts: preparing for mobile device management, how-to perform device enrollment for mobile devices, and how-to configure mobile devices settings, you should check them out! In this installment, I discuss how-to deploy apps to mobile devices by using System Center 2012 R2 Configuration Manager applications. So, let’s start off with a bit of background on the System Center 2012 R2 Configuration Manager application model.
System Center 2012 R2 Configuration Manager application model
The System Center 2012 R2 Configuration Manager application model is the only method for deploying apps to mobile devices. Although System Center 2012 R2 Configuration Manager still supports the Configuration Manager package and program model, it’s not designed to deploy apps.
A Configuration Manager application can have one or more deployment types. A deployment type is used to define different ways of deploying the same application. For example, you could define a Configuration Manager application for Microsoft Skype, and create a separate deployment type for the Windows desktop version, Windows Store version, Windows Phone version, Apple iOS version, and Andrord verion (for a total of five deployment types).
This powerful model allows you to define an application once, and then add or remove deployment types as necessary. The Configuration Manager application model also supports automatic updates to an application, supersedence (replacing one application with another), and application retirement (removal), so you can manage your apps throughout their entire life cycle!
Sideloading and deeplinking
There are two ways to deploy apps to mobile devices: sideloading and deeplinking. Sideloading is when you have the actual installation files (such as an .appx, .xap, .iap, or .apk file) and you want to install your app by using the installation files on the appropriate device type. Some devices may require special certificates or sideloading keys for this (see my second blog post on performing device enrollment). When you create a deployment type for a sideloaded app, you provide a Universal Naming Convention path to where the installation files are located.
Deeplinking is when the app is located in the device store and you provide a link to that app. The app is not actually installed; rather, the user is provided with a link to the app that appears in the Company Portal app. When the user installs the app from the Company Portal app (, the app page is automatically displayed in the device store. When you create a deployment type for a sideloaded app, you provide a URL to where the app is located in the device app store.
Now, let’s look at the types of apps that you can deploy to mobile devices.
Application deployment types
The following is a list of the deployment types that System Center 2012 R2 Configuration Manager supports for mobile devices:
As you can see, these deployment types tend to fall into the two categories I mentioned earlier: sideloading and deeplinking. You select the particular deployment type based on the targeted device and whether you are sideloading or deeplinking the app.
However, there is one exception: Web Application. This deployment type allows you to add links (think tiles in Windows and Windows Phone) to a web app. For this deployment type, you specify the URL for the web app.
So, for example, if I wanted to deploy Skype to Windows, Windows Phone, iOS, and Android devices, I would create a Skype application, and then create a deployment type for each targeted device. The one twist is that for Windows, I would probably deploy both the desktop version by using a Windows Installer deployment type and the Windows Store version by using a deeplink to the Skype app in the Windows Store. The other deployment types would also be deeplinks to the Skype app in the respective device stores.
Application creation and deployment
Now, with all the background information, how do you actually create and deploy apps to your mobile devices? That’s the easy part! Just follow these simple steps:
After you have deployed the Configuration Manager application, the app shows up in the Company Portal app on each device. Users can install the app and immediately start using it.
Now you seen how easy it is to deploy apps to mobile devices. System Center 2012 R2 Configuration Manager and Windows Intune can help you manage your apps throughout their life cycle. In my next, and final post in this series, I’ll talk about how to protect business data stored on mobile devices.
NEXT BLOG POST IN THIS SERIES: How-to protect business apps and data on mobile devices (Coming later today!)
Author: Enterprise Mobility Team
Subject: How-to configure mobile device settings
|This is the third blog post in my five-part series on mobile device management (MDM). If you missed the first two parts: preparing for mobile device management and how-to perform device enrollment for mobile device management, I invite you to check them out. Today, I’m going to talk about configuring mobile device settings by using Microsoft System Center 2012 R2 Configuration Manager and Windows Intune.
Can’t be all things to all devices
I’d like to point out before we get started that not all configuration settings are supported on all devices. For example, one configuration setting may be available on a Windows RT 8.1 device, but not on an Apple iOS device. Of course, the same could be said about a setting that is available for a Google Android device that is not available in the Windows 8.1 operating system. That said, many of the settings available in System Center 2012 R2 Configuration Manager are applicable to most of the devices.
To help you, System Center 2012 R2 Configuration Manager tells you if a configuration setting that you have set is supported on a specific device platform. I’ll talk about this more later as we walk through the process for creating configuration settings.
The question is, how does System Center 2012 R2 Configuration Manager know so much about these different mobile devices? And how does Microsoft add support for new devices that are released (such as Windows Phone 8.1)? The answer is extensions for Windows Intune.
System Center 2012 R2 Configuration Manager lists the Windows Intune extensions as they are released. You need to enable Windows Intune extensions to use them. Once you enable an extension, Configuration Manager automatically downloads the extension through the Windows Intune Connector. The Configuration Manager console installs the extension and add new user interface items to make System Center 2012 R2 Configuration Manager aware of the new or different capabilities and features of a device. After the extension is installed, you will need to restart the Configuration Manager console to use the new extension. For more information about extensions for Windows Intune and the Windows Intune Connector, see my first blog in this series.
For those of you who are familiar with Desired Configuration Management in System Center 2012 R2 Configuration Manager, you already know how to create compliance settings. Creating compliance settings is a three-part process. First, you create configuration items (CIs); next, you create configuration baselines; finally, you deploy the configuration baselines to System Center 2012 R2 Configuration Manager user or device collections. A configuration item can contain one or more configuration settings. For example, you could create a CI to manage mobile password settings, but that one CI could have different individual settings, such as minimum password length, password expiration, and password complexity.
A configuration baseline contains one or more CIs, and you deploy the baseline to System Center 2012 R2 Configuration Manager user or device collections. For example, you could create one configuration baseline that contains all the CIs for a sales force, and then create yet another baseline that contains less restrictive CIs for your IT pros. Then, you would deploy the configuration baselines to the respective user collections.
Configuration Manager configuration items and baselines work the same for Windows Intune mobile device management as they do for devices directly managed by Configuration Manager. This allows you to create configuration items and baselines that you can apply to both sets of devices.
You can include however many settings you want in a CI, but typically you want a CI to be somewhat granular. This allows you to reuse the same CI across multiple configuration baselines. For example, if your organization has a policy about app store access, you could create a CI that contains the app store settings. Then, you could include that one CI in all of your baselines.
When you deploy the configuration baselines to the devices, MDM does its magic! The configuration settings are pushed to the devices (as applicable), and the devices are configured to match your published configuration baselines. And if a user resets their device and enrolls the device again, then the device will be brought back into compliance. What happens if the user purchase a new device? If you deploy the configuration baseline to the user, when the user enrolls their new device, that device will be brought into compliance! Who says MDM isn’t easy?
Company resource access settings
Invariably, users will want to access your organization’s resources from their mobile devices, whether they are in your office, at a Wi‑Fi hotpot, at the airport, or at home. But you need to control how these users access your resources. System Center 2012 R2 Configuration Manager has just the answer in the Company Resource Access features, which you configure by using profiles. The following table lists the profile types that you can create and provides a brief description of each.
So, now you’ve seen how to configure mobile device settings by using System Center 2012 R2 Configuration Manager and Windows Intune. Pretty easy, wasn’t it? And centrally managing device configuration helps ensure that all your mobile devices are configured the same way and are compliant with your organization’s standards. You can help protect your organization’s resources by ensuring that users use secure settings when remotely connecting. In my next post, we’ll look at how to deploy apps to mobile devices.
NEXT BLOG POST IN THIS SERIES: Deploying apps to mobile devices (Coming May 30)
Posted on: Wednesday, May 28, 2014 11:00 AM
Author: Enterprise Mobility Team
|In today’s post, I continue my discussion of mobile device management (MDM). In my last post preparing for mobile device management, I described how to prepare for MDM. Now, I talk about how to prepare for and execute device enrollment for Windows, Windows Phone, Apple iOS, and Google Android devices. Let’s start off by talking about how you prepare for device enrollment.
Device enrollment preparation
You can think of device enrollment preparation as the next logical step after preparing for MDM. But device enrollment preparation is specific to the types of devices you want to support. So, you only need to prepare for those devices that you need to support. In the next few paragraphs, I’ll walk you through each device type and how you can prepare for its enrollment.
Prepare for Windows device enrollment
To prepare your Windows Intune subscription for Windows devices, complete the following steps:
Sideloading keys are not required for the Windows 8.1 Enterprise, Windows 8.1 Pro, and Windows 8 Enterprise devices that are domain joined.
Prepare for Windows Phone device enrollment
Preparing your Windows Intune subscription for Windows Phone devices is almost as easy as for Windows devices. Complete the following steps for Windows Phone devices:
But what if you want to evaluate Windows Phone management? Do you have to go through all these steps? Not to fear! You can download the Support Tool for Windows Intune Trial Management of Windows Phone. This tool helps simplify the configuration process; but remember that it’s for evaluation purposes only. For production environments, use the process above.
Preparation for iOS device enrollment
Preparing for iOS device enrollment is similar to the process for Windows Phone. Here are the steps you must complete:
Prepare for Android device enrollment (including Samsung KNOX)
To prepare for Android device enrollment (including Samsung KNOX), simply select the Enable Android enrollment check box on the Android tab of the Windows Intune Subscription Properties dialog box.
Device enrollment process
Just as with preparation for device enrollment, the device enrollment process is different for each device type. Let’s look at how you would enroll each type of device.
Windows device enrollment process
The Windows device enrollment process is the same for Windows 8.1 and Window RT 8.1 devices. Complete the following steps:
It can take 5 to 10 minutes after enrollment begins before the Company Portal can be accessed.
Note If your Windows account does not have a public domain and you are using a *.onmicrosoft.com account, you will need to create a new REG_SZ registry key called DiscoveryService with the value manage.microsoft.com in the following registry subkey:
Windows Phone device enrollment process
Just as with the Windows device enrollment process, Windows Phone device enrollment is slightly different for Windows Phone 8 and Windows Phone 8.1. Here are the steps you must complete:
Note If your Windows Intune account does not have a public domain and you’re using a *.onmicrosoft.com account, you must manually enter the Windows Intune server address as manage.microsoft.com.
iOS device enrollment process
To enroll an iOS device, complete the following steps:
After you have signed in to Windows Intune, you will see an exclamation point ("!").
Android device enrollment process
Enroll an Android device (including Samsung KNOX) by completing the following steps:
Well, now you know how easy it is to prepare for device enrollment and enroll devices. You can find more about device enrollment preparation and the device enrollment process for each type of device at Mobile Device Enrollment. In my next installment, I’ll discuss how to configure compliance settings for mobile devices by using System Center 2012 R2 Configuration Manager and Windows Intune.
NEXT BLOG POST IN THIS SERIES: How-to configure mobile device settings (Coming May 29)
|From: Enterprise Mobility Teamhttp://blogs.technet.com/b/enterprisemobility/archive/2014/05/28/how-to-perform-device-enrollment-for-mobile-devices.aspx
Over the next few days, I’ll be writing a series of blog posts about mobile device management (MDM). Microsoft’s focus is on providing best-in-class mobile and cloud services.Today, everyone has a mobile device, whether it’s a tablet, convertible, laptop, or smartphone. Users are never out of touch with one another and their information. But how can we manage devices that are never in one place for long? Well, because mobile devices mostly use cloud services, the best way to manage these devices is through a cloud service.Enter Microsoft System Center 2012 R2 Configuration Manager and Windows Intune. These products provide user-centric management for devices that are mobile or at your offices. Over the next few posts, I’ll be focusing on how to use System Center 2012 R2 Configuration Manager and Windows Intune to manage your mobile devices and reduce the level of effort (and worry) you spend doing so.Watch this video to see Microsoft mobile device management in action.
Now that we’ve seen how Microsoft mobile device management works, let’s talk more about the products that are used and how they work together.
Microsoft mobile device management products
I’ll start off by talking about the products in a Microsoft MDM solution: Microsoft System Center 2012 R2 Configuration Manager and Windows Intune. Why do you need both products? The short answer is that you don’t. For example, many organizations are using System Center 2012 R2 Configuration Manager and Microsoft Exchange Server to manage their mobile devices through Microsoft Exchange ActiveSync. Other organizations use only Windows Intune to manage their on-premises and mobile devices.
So, why use both System Center 2012 R2 Configuration Manager and Windows Intune? To be able to manage all of your devices and users in one place. When you integrate these two products, you can manage users and devices regardless of whether they are in your office or out in the field, and you can do so from one management console: the Configuration Manager console. This integration allows you to manage all phases of the device life cycle, too, from device enrollment through device retirement and all phases in between.
In fact, when you enable System Center 2012 R2 Configuration Manager and Windows Intune integration, Windows Intune becomes transparent for the most part. You manage devices through System Center 2012 R2 Configuration Manager, which communicates with Windows Intune through the Windows Intune Connector in System Center 2012 R2 Configuration Manger. Windows Intune communicates with your mobile devices. Conceptually, after you set up the System Center 2012 R2 Configuration Manager–Windows Intune integration, Windows Intune appears as a logical extension of System Center 2012 R2 Configuration Manager.
So, let’s look at how to prepare for MDM by examining the prerequisites.
Mobile device management prerequisites
How do you go about creating an enterprise-class MDM solution? You need:
For more information about these prerequisites, see Prerequisites in How to Manage Mobile Devices by Using Configuration Manager and Windows Intune.
That’s all you need as far as prerequisites. When these elements are in place, you’re ready to configure integration between System Center 2012 R2 Configuration Manager and Windows Intune.
Synchronize on-premises Active Directory with Microsoft Azure Active Directory
In most cases, you’ll have an on-premises Active Directory Domain Services (AD DS) infrastructure, which is where your user accounts are managed. Ideally, you want to provide a single sign-on experience for your users so that they can use the same credentials to access on-premises and Windows Intune services.
To do this, install and configure the Microsoft Azure Active Directory Sync Tool. This tool synchronizes the user and group accounts in your on-premises AD DS forest with Azure Active Directory (which Windows Intune uses). You install the tool on an on-premises server (virtual or physical). The installation process is wizard-driven and simple.
Configure the Azure Active Directory Sync Tool by providing:
After you have configured the Azure Active Directory Sync Tool, it automatically starts the synchronization process. Depending on the number of users in your AD DS forest, synchronization can take a few minutes or a couple of hours. The tool continues to run and keeps both directory services in sync with each other, which helps ensure that users need to remember only one set of credentials.
You can also use Active Directory Federation Services (AD FS) with Windows Intune to enable single sign-on. Implementing single sign-on with AD FS means that password hashes do not have to be synchronized between your on-premises AD DS cloud and Azure Active Directory.
For more information about how to install and configure the Azure Active Directory Sync Tool, see Set up your directory sync computer and Directory integration. For more information about implementing Windows Intune sign-on with AD FS, see Checklist: Use AD FS to implement and manage single sign-on.
Configure the Windows Intune subscription
With the user accounts synchronized, you’re ready to configure the Windows Intune subscription in System Center 2012 R2 Configuration Manager. Windows Intune subscriptions that are:
Note You configure a Windows Intune subscription for integration with System Center 2012 R2 Configuration Manager only once. The process cannot be reversed for that subscription.
You configure the Windows Intune subscription by completing the Add Windows Intune Subscription Wizard. In that wizard, you provide the following information:
You can also configure some of these settings after you have added the Windows Intune subscription in the Configuration Manager console.
Add the Windows Intune Connector site system role
Adding the Windows Intune Connector site system role in System Center 2012 R2 Configuration Manager is like adding any other System Center 2012 R2 Configuration Manager site system role: you use the Add Site System Roles Wizard in the Configuration Manager console. You don’t have to provide configuration settings; just ensure that you select the Windows Intune Connector site system role on the System Role Selection wizard page. For more information about adding the Windows Intune Connector site system role in System Center 2012 R2 Configuration Manager, see The Windows Intune Connector Site System Role.
Enable Windows Intune extensions
Windows Intune has Configuration Manager console extensions that allow the Configuration Manager console to be aware of new capabilities. You can find these extensions in the Extensions for Windows Intune node in the Administration workspace.
For example, the iOS 7 Security Settings extension adds support for the new iOS 7 security configuration settings; the Windows Phone 8.1 Extension adds support for Windows Phone 8.1 features and management. Depending on the devices you’re managing, you may need to enable some or all of the extensions.
After you enable the Windows Intune extensions for the Configuration Manager console, close the console, and then reopen it to complete the process. When you restart the Configuration Manager console, the new features and configuration options appear.
For more information about Windows Intune extensions in System Center 2012 R2 Configuration Manager, see Planning to Use Extensions in Configuration Manager.
Now you’ve seen how easy it is to prepare for MDM by using System Center 2012 R2 Configuration Manager and Windows Intune. You can try out these steps by downloading the evaluation copy of System Center 2012 R2 Configuration Manager and signing up for a trial version of Windows Intune. In my next blog post, I’ll walk through the process of enrolling different types of devices.
NEXT BLOG POST IN THIS SERIES: Performing device enrollment (Coming May 28th)
Guys, Microsoft updated the TechNet documentation to upgrade your SCCM 2012 SP1 to R2.
Configuration Manager supports installing System Center 2012 R2 Configuration Manager to upgrade a site that runs Configuration Manager SP1. You can run the upgrade on the site servers of central administration sites and primary sites. After a primary site upgrades, you can then use the Configuration Manager console to upgrade secondary sites to System Center 2012 R2 Configuration Manager. It is not supported to upgrade a site that runs System Center 2012 Configuration Manager with no service pack to System Center 2012 R2 Configuration Manager. Instead, you must first upgrade to System Center 2012 Configuration Manager with SP1, and then upgrade to System Center 2012 R2 Configuration Manager.
Use the information in the following sections to help you plan for the upgrade to System Center 2012 R2 Configuration Manager.