A key feature of the mobile device management capabilities provided by System Center 2012 R2 Configuration Manager with Windows Intune is the ability to provision client certificates to managed devices.  Organizations that use an enterprise PKI for client authentication to resources like WiFi and VPN can use this feature to provision certificates to Windows, Windows Phone, iOS, and Android devices managed through Windows Intune.  This article provides an in-depth look at how this feature works, and where you can go to find out all of the information you need to get up and running.

For those customers that are using NDES and did an upgrade from System center Configuration Manager 2012 R2 to System center Configuration Manager 2012 R2 SP1  they will notice that their NDES Server hosting the NDES Site Server role will fail to reinstall as shown below in the screenshot :

Investigating the issue a little further and going to look at the logging (CRPSetup.log) on the NDES server hosting the NDES Site Server role , we got the error message “Enabling WCF 40 returned code 50. Please enable WCF HTTP Activation. “

The question is why it would complain now as it worked before . After investigation it turns out that System Center Configuration Manager 2012 R2 Sp1 supports now  the provisioning of  personal information exchange (.pfx) files to user’s devices including Windows 10, iOS, and Android devices. Devices can use PFX files to support encrypted data exchange.

In the Supported Configurations for Configuration Manager ( https://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_SiteSystemRolePrereqs ) , we found out that now “Http activation is required”

After enabling the feature , the role started to reinstall itself .

Looking at the log file it seems that is is installed :

Looks like the role installed itself and thus problem solved.

Hope it helps ,

Kenny Buntinx

MVP Enterprise Client Management

Hi ,

As you already probably knew , new Windows Intune capabilities are added as we speak for Windows Intune standalone thru the so called “November Release” as discussed here : http://blogs.technet.com/b/microsoftintune/archive/2014/11/17/new-microsoft-intune-capabilities-coming-this-week.aspx 

The Microsoft Intune Company Portal for Windows Phone app helps you search, browse and install apps made available to you by your company, through the Microsoft Intune standalone of Hybrid (Configmgr and Windows Intune). Apps can be installed without requiring a connection to your corporate network. You can also enroll your personal computers and devices in the service and locate contact information for your IT team.

One additional change that was not clearly communicated is a change to how the Intune Company Portal or Self Service Portal (SSP) app for Windows Phone 8.1 is offered and installed.

Before , If you wanted to manage and deploy applications on your Windows phone 8 and 8.1 , the Company Portal app was offered as a deployable download at Microsoft’s Download Center, sign it with a Symantec code signing Certificate and deploy it to the management system infrastructure to enable device enrollment for Windows Phone 8 and 8.1 devices. The download was infused with a Symantec certificate to ensure trustworthiness of the app and to help secure enrollments.

Microsoft has now updated the Windows Intune Company Portal app for Windows Phone 8.1. The Symantec certificate is no longer embedded and no longer required because the app is now only available through the Microsoft Store.

However , there are some things to take into account when doing hybrid or standalone implementations.

Starting this week for Windows Intune standalone only , Microsoft removed the requirement that a company have an AET (Application Enrollment Token) and signed Company Portal app before we let them enroll, but devices must be enrolled for management before they can install sideloaded apps from our MDM, and they must also have the AET.

In short this means that you do not longer need the Symantec certificate to enroll and manage WP8.1 devices ( not WP 8.0! ) , but you will still need the Symantec certificate to sideload any application that doesn’t come thru the app store .

Anything else still requires both cert and signed SSP.xap from download center –> so are Hybrid implementations still today.

My advise for now:

1. Admins who want to stay on the old school ssp.xap for now ( For hybrid deployment this is mandatory !!! )

• Don’t tell users about store app
• Add store app to blocked list, for extra insurance, so they can’t run it
• Just keep doing what you’re doing

Hybrid users could still install the SSP from store if you do not blacklist the application. However , if the do install the SSP from the store , they can’t enroll unless a cert and signed ssp have been uploaded, but they can use the portal in the “unenrolled” scenario.

2. Admins who want to move to appx from app store ( Intune standalone only !! )

• Create an app that uninstalls ssp.xap
• Tell users to start by installing store app and using link in app to enroll just like android or IOS

Conclusion:

The only new thing you get with the App Store SSP version is the ability to show users “Terms and Conditions” . Period.

If companies want to sideload applications, there’s still no way around having the Symantec cert

The new App Store SSP is taking the version to 4.1.2777.2 and can be found over here :

http://www.windowsphone.com/s?appid=0b4016fc-d7b2-48a2-97a9-7de3b5ea7424

Hope it Helps ,

Kenny Buntinx

MVP Enterprise Client Management

Scenario :

Last week we had a discussion at a customer during a  Windows Intune UDM Proof of concept and the customer was willing to order about 3000 corporate owned Nokia Lumia 630 Windows Phones. He wanted us to provide the option when a ‘device owner’ in CM12 R2 is set to “corporate” , a user can’t un-enroll a “corporate” device and to prevent them from doing so , unless you are the ConfigMgr 2012 MDM admin.

As this seemed a logic request to me , we couldn’t do it out of the box with windows phone 8 or with Windows Intune. Missed opportunity , I would say. However with the launch of Windows Phone 8.1 at Build conference , there was a new set of OMA-DM management capabilities being added.

At this stage , the writing and the testing of the blog post  is being done with a developer edition of Windows Phone 8.1. I doubt that when being rolled out as RTM , these policies will be changed.

Solution to problem :

First of all , you will need to know what OMA-DM is . OMA-DM is an open standard that Apple – Android and Microsoft are using. All MDM solutions use the OMA-DM API to manage those devices. More information on OMA-DM can be found here .

Microsoft has released together with WP 8.1 , a comprehensive guide called ; ‘Windows Phone 8.1 MDM protocol documentation’ . You will need this guide as a reference to find all custom not-so-out-of-the-box OMA-URI’s. An OMA-URI can be seen as a registry setting or hive. You can download it here .

Panu Saukko , a good friend and fellow Enterprise Client Management MVP , pointed me in the right direction inside the document on how to reach the goal : Blocking a user from un-enrolling their device. Without the golden tip from Panu , we would never succeed as there is an Typo in the document.

Panu pointed out that according to the document, the OMA-URI should be according to page 133 & 143 inside the ‘Windows Phone 8.1 MDM protocol documentation’ :

./Vendor/MSFT/PolicyManager/My/Experience/AllowManulMDMUnenrollment

Again there is a typo in that document , it should be

./Vendor/MSFT/PolicyManager/My/Experience/AllowManualMDMUnenrollment

Now that we have found the error in the OMA-URI , Let’s show some magic with Compliance settings , Configuration Items and Configuration Baselines in CM 12 R2 :

Creating the ‘Configuration Item’ :

1. Go to “Asset & Compliance” , click on “Compliance Settings” , go to “Compliance Items” and create a New Configuration Item as shown below

2. Give the new Compliance item the following Name : ‘Deny WP8.1 MDM UnEnrollment’ and hit “next”

3. Select the checkbox : ‘Configure additional settings that are not in the default settings groups’ and click “next” to continue

4. In the next window that opens , click the ‘Add’ button.

5. Hit the “Create Setting” tab.

6. Now comes the interesting stuff .

• Give it a Name
• 1. Settings Type : OMA-URI
• 2. Data Type : Integer
• 3. OMA-URI : ./Vendor/MSFT/PolicyManager/My/Experience/AllowManualMDMUnenrollment

7. Highlight your recently created ‘Deny MDM Unenrollment’ and hit the ‘Select’ button

8. Now comes the interesting stuff again

• 1. Rule Type : Value
• 2. Data Type : 0 (0 = un-enroll not allowed / 1 =  enroll allowed)
• 3. Set ‘Remediate noncompliant rules when supported’
• 4. Set Noncompliance severity for reports to ‘Warning’ 

9. Click next to continue.

10. As this setting is only applicable for Windows Phone , we select only this platform and click ‘next’ to continue.

11. Click next to continue , until the end .

Once created , you will see something like this in the screenshot below . After creating the ‘Configuration Item’ , we are going to create and deploy the ‘Configuration Baseline’

Creating the ‘Configuration Baseline’ :

1. Now go to baselines and create a new ‘Configuration Baseline’

2. Give the ‘Configuration Baseline’ a name and click “Add” to add your ‘’Configuration Item’’

3. Search for your previously created ‘Configuration Item’ and click add.

4. Hit OK , to continue

5. Click ‘OK’ to continue

When created , you will see something similar in your console as show below in the screenshot :

Deployment of the ‘Configuration Baseline’ ONLY to the ‘Corporate Owned’ devices :

As we only wanted to prevent un-enrollment when a ‘device owner’ in CM12 R2 is set to “corporate” , we first need to create a collection that contains only devices set to corporate as shown below . Devices enrolled using the ConfigMgr 2012/Windows Intune UDM solution can be assigned to be either "Company" or "Personal" devices. Note that a device is automatically assigned to be Personal by default.

Now that that is done , create a ‘Device collection’ that is only containing resources that are ‘Company’ devices. To do that , use the following query where ‘System Resource – Device Owner’ is set to ‘1’ for ‘Company’ . Value 2 is “personal”

Now deploy your ‘Compliance baseline – Deny wp8.1 UnEnrollment’ to the collection called ‘All Mobile Devices set as Corporate Owned Devices’

The END Result ? :

As the policies come down from Configuration Manager 2012 R2 with Windows Intune on the WP8.1 device and the user tries to un-enroll , following message is shown :

Hope it  Helps ,

Kenny Buntinx

Enterprise Client Management MVP

This morning at a customer , I received the following mail in my mailbox , saying that my ADFS token would expire.

AD FS 2.0 or 2.1 and probably 3.0 generates each year by default a new self- signed certificate for token signing 20 days before the certificate expires . Rollover of the certificate , or generate a new certificate when the existing certificate is about to expire , and make them the primary certificate , applies only to self-signed certificates that are generated by AD FS 2.x . The token signing certificate is essential for the stability of the Federation Service . If this is changed, the change must be reported to Windows Azure AD . Otherwise fail applications for cloud services such as my Windows Intune Service.

When the token signing certificate of your home AD FS organization expires, then federation metadata between AD FS and Office 365 falls out of synch. Equally, when changes are made on the Office 365 or Windows Intune that require updating the metadata, a similar issue arises. The “Microsoft Office 365 Federation Metadata Update Automation Installation Tool” script provide by the AD FS team checks the that federation metadata is validated regularly and any changes replicated between the two federating parties.

You must have the Microsoft Federation Metadata Update Automation Installation Tool download and configure your primary federation server or another recordable federation server, the Windows Azure AD Federation Metadata regularly automatically checks and updates so that changes in the certificate token-signing in the AD FS 2.1 Federation service will be copied automatically onto Windows Azure AD.

You can download the script here : http://gallery.technet.microsoft.com/scriptcenter/Office-365-Federation-27410bdc

The script is called : O365-Fed-MetaData-Update-Task-Installation.ps1

To execute this tool successfully:

• You must make sure that you have installed the latest version of the Microsoft Online Services Module for Windows PowerShell 
• You need to have a functioning AD FS 2.0 Federation Service (execute this on your primary ADFS server)
• You need to have access to Global Administrator credentials for your Office 365 tenant
• You need to have at least one verified domain in the Office 365 tenant must be of type ‘Federated’
• This tool must be executed on a writable Federation Server
• The currently logged on user must be a member of the local Administrators group
• The Microsoft Online Services Module for Windows PowerShell must be installed. You can download the module from http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652560.aspx0

When running the tool and you comply with the above prerequisites , the following screenshot appears as shown below :

It’s worth bearing in mind that the password policy will render the script unusable in the event of a password change on either the Windows Intune side with the MSOL account you specify and the Domain side with the user account used to initiate the scheduled task. It is possible to create service accounts to do this on both sides. However, I’d consider the security consequences of such a change before automatically doing so. This can be done on the O365 side with an Office 365 standard account via the Set-MSOLUser cmdlet.

For example:  Set-MSOLUser –identity user@MyPreciousChosenDomain.onmicrosoft.com –PasswordNeverExpires $true –StrongPasswordRequired $true

The account could also technically be a federated account, but I don’t believe that’s a good idea. In the event that the trust is broken, then a federated account won’t be able to connect to MSOL to update the federated domain information and you would be in trouble big time!

To verify the scheduled task is executed correctly , open task scheduler and verify that the task is there :

;-

That’s again an automated task , without worrying that your infrastructure is in danger

Hope it Helps ,

Kenny Buntinx

Enterprise Client Management MVP

In my previous blog posts “Prepare to Install ADFS 2.1 Services to have SingleSignOn (SSO) in Windows Intune (WaveD) – Part 1” I explained the genaeral design and concept for setting up SSO with ADFS  at “http://scug.be/sccm/2013/07/04/prepare-to-install-adfs-2-1-services-to-have-singlesignon-sso-in-windows-intune-waved/”

This article takes it step-by-step through initializing a new domain in Windows Intune WaveD , its verification, and configuration for single sign-on. This guide will show how to perform these steps on Windows Server 2012 with AD FS 2.1.

Again our design we are going to follow :

Determine the ADFS Farm Name

We really need to get this information sorted first, because our certificate requests will be based on the FQDN of the farm name, and it isn’t possible to install ADFS services without a certificate.

We’ll use “Federation.scug.be” – this name will be used by by Windows Intune federation services. This certificate absolutely must be issued by a public CA.

Request a Certificate

Really quick overview of ADFS certificates: there are three certificates used by ADFS; one is used for server authentication and the remaining two certificates are used for ADFS token signing and verification

For best practice and supportability this certificate should NOT a wildcard certificate. However my wildcard certificates were working flawless, but if you go that way and something does not work later down the road, your support options may be limited at this time.

Service Account for ADFS Federation Service

Next, we will create a service account for the purpose of installing and running ADFS Federation Service. This service account will be used to perform initial installation of the service as well as the WID SQL databases. During this initial installation, the service creates certificate containers in Active Directory, as well as SPN records for the shared IIS pool identity. To perform these tasks, the service account must be at least a Domain Admin.

Install ADFS Service on the First Windows Server 2012 Server (FED1PRD.SCUG.BE)

Prerequisites :

• Make sure that you installed the ADFS Services thru “Add Roles and Features”.
• Make sure you have copied your *.SCUG.be certificate on your ADFS Servers
• Make sure they are added to the domain
• Your Active Directory Domain must be in Windows 2003 mixed or native mode.

1. Open the wizard and select “Create a new Federation Wizard” …

2. Provide your SSL certificate and Federation Service Name …

3. Provide your Service Account and password …

4. Click Next tot continue after reviewing…

5. When everything is ok , click close to close the wizard.

Install ADFS Service on the Second Windows Server 2012 Server (FED2PRD.SCUG.BE)

1. Open the wizard and select “Add a federation server to an existing Federation Service” …

2. Specify your primary federation Server name and your ADFS service account .

3. Click next to install and finish

Important :

Create a host file on the FED1PRD.SCUG.BE and FED2PRD.SCUG.BE with the following line:

Now your ADFS Farm is installed and configured correctly.Now let’s show you how to introduce an AD FS Proxy Server.

In addition to adding two federation server proxies, you must make sure that your perimeter network can also provide access to a Domain Name System (DNS) server and to a second hardware Network Load Balancing host. The second NLB host must be configured with an NLB cluster that uses an Internet-accessible cluster IP address, and it must use the same cluster DNS name (federation.SCUG.be) setting as the previous NLB cluster that you configured on the corporate network (Federation.scug.be). The federation server proxies should also be configured with Internet-accessible IP addresses.

Note: All the servers / clients communication is established over port 443, make sure that port 443 is allowed from and to the internal AD FS host server to the AD FS proxy servers, as well from the Internet to the AD FS proxy servers

Importing the Certificate on FED1PRD.SCUG.BE and FED2PRD.SCUG.BE

After that , Import your *.SCUG.BE certificate on FED1PRD.SCUG.BE and FED2PRD.SCUG.BE in your website as described below :

After the certificate has been imported, you’ll want to verify it by going back to Server Certificates in IIS.

Next, you’ll need to add the Certificate to the Default Web Site.  With the Default Web Site Selected click Bindings.

Click Add

Choose Type https, IP addresss All Unassigned, and Port 443.  Then select the newly imported certificate and click Ok.

The site bindings should now look like:

Install ADFS Proxy Servers on Windows Server 2012 Server (ADFSPROXY01 – ADFSPROXY02)

1. Select “ADFS Federation Services Proxy” thru “Add Roles and Features”.

2. Leave the defaults selected and select “Next”

3.Hit “install” button.

Important :

Create a host file on the ADFSPROXY01 and ADFSPROXY with the following line:

Note: All the servers / clients communication is established over port 443, make sure that port 443 is allowed from and to the internal AD FS host server to the AD FS proxy servers, as well from the Internet to the AD FS proxy servers

Importing the Certificate on ADFSPROXY01 and ADFSPROXY02

After that , Import your *.SCUG.BE certificate on ADFSPROXY01 and ADFSPROXY02 in your website as described below :

After the certificate has been imported, you’ll want to verify it by going back to Server Certificates in IIS.

Next, you’ll need to add the Certificate to the Default Web Site.  With the Default Web Site Selected click Bindings.

Click Add

Choose Type https, IP addresss All Unassigned, and Port 443.  Then select the newly imported certificate and click Ok.

The site bindings should now look like:

DNS Configuration

• Configure internal DNS to point to the federation hosts cluster (NLB) IP
• Set up a host (A) record for the domain (federation.scug.be) on a public-facing DNS server for external name resolution to point to the proxy servers cluster (NLB)

Optional – in case the proxy servers doesn’t have DNS connectivity to the internal DNS server, you can configure the host file (see above topic) on each server to resolve the AD FS host servers name

The end

Now your ADFS Farm is completely installed and configured correctly.

This brings us to the end of this post. In the next few posts, we’ll cover additional configuration and troubleshooting steps and bring this Windows Intune SSO / ADFS 2.1 infrastructure on Windows Server 2012 to a usable state.

Stay Tuned !

Hope it Helps ,

Kenny Buntinx

Enterprise Client MVP