You are browsing the archive for 2014 April.

Excited : Speaking at Briforum London this year

2:13 pm in BRIFORUM, speaking by Kenny Buntinx [MVP]

This year is my first and therefore also special BRIFORUM event for me and my dear friend “Tim De Keukelaere” as we are presenting “ConfigMgr 2012 R2 and Intune: Setup and Deployment Notes from the Field (with focus on Single Sign-on & ADFS)” on 20-21 May 2014 . It’s so special as it is  the 10th occurrence of this event for the past ten years in London !


This conference has great International speakers and I think this is one of the few events where they are presenting “vendor independent” and makes this conference unique.


I will be not to late to join these magnificent sessions ! So if you haven’t already registered , do so on Briforum Website!

Hope it Helps ,

Kenny Buntinx

Enterprise Client Management MVP

ConfigMgr 2012 R2 & Windows Intune UDM : How to prevent an “End-User” can un-enroll his “Corporate” Windows Phone 8.1

8:30 pm in 2012R2, 8.1, Compliance Management, configmgr 2012 R2, intune, MDM, OMA-DM, OMA-URI, policy, sccm 2012 R2, UDM, Windows Intune, Windows Intune Extensions, windows inune, Windows Phone 8.1, Windws Intune, WP 8.1 by Kenny Buntinx [MVP]


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’ :


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


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

Configmgr 2012 & Windows Intune SSO : Self- signed certificate for token signing is about to expire. Now What?

12:15 pm in ADFS, ADFS 2.1, ADFS 3.0, ConfigMgr 2012, configmgr 2012 R2, ConfigMgr 2012 SP1, intune, SCCM 2012, SCCM 2012 R2, SCCM 2012 SP1, sso, Windows Intune, Windows Intune Extensions, windows inune by Kenny Buntinx [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 :

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

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

Configuration Manager 2012 OSD : Only import the Intel chipset drivers you really need for your brand/model !

6:31 pm in ConfigMgr 2007 R2, ConfigMgr 2012, configmgr 2012 R2, ConfigMgr 2012 SP1, ConfigMgr SP2, configmgr2007, Deployment, Drivers, Operating System Deployment, OSD, sccm, SCCM 2007, SCCM 2007 R2, SCCM 2007 R3, SCCM 2007 SP2, SCCM 2012, sccm 2012 R2, SCCM 2012 R2, SCCM 2012 SP1, sccm RTM, sccm2007 by Kenny Buntinx [MVP]


Yesterday I wrote a blogpost about the reason to keep your “Driver DB” and “driver packages” as clean as possible and that you do not need to import all the junk they provide in those so called “enterprise driver packages” for multiple models.

As a first tip for helping you accomplish that , we show you in this blog post how we can limit the number of *.inf files we need to import from Intel(R) Chipset Device Software . When downloading and extracting that Intel(R) Chipset Device Software package you will see that originally there are about  98 inf files present :


Now reduce the number of INF files :

Two override command switches for setup.exe from Intel(R) Chipset Device Software that will help us to reduce the *.inf files we need to import into our “Driver Package” :

-AONLY Extracts the needed INF files to install on the current system. If the install has been run once successfully, ‘-AONLY’ will not return any INFs when used in conjunction with ‘-OVERALL’ switch, all the needed INFs for the system will be extracted.

-P <Installation Path> Specifies the hard disk location to which the INF program files are copied. If this flag is not specified at the command line, the <Installation Path> directory is as follows: C:\Program Files\Intel\INFInst .

If this flag is used without the ‘-A’ option, only the Readme will be copied to <Installation Path>. The directory name can include spaces, but then a pair of double quotes (") must enclose the directory name. There should not be any space between the switch ‘-p’ and the directory name. This flag works in either Silent Mode or Interactive Mode.

Lets execute on the local brand/model that contains an intel chipset :

The result of running the setup with those parameters:

And then the result after running the tool on your local brand/model , you will see that the number of *.inf files are reduced to five (5) items ! isn’t that great ? Now copy those drivers to your regular driver import process and you reduced the number of bloat in your ConfigMgr driver database by 80% at least !




Hope it Helps ,

Kenny Buntinx

MVP enterprise Client Management

Configuration Manager 2012 and the need of keeping your Driver database lean and clean !

8:03 pm in CM12, CM12 R2, CM12 SP1, Deployment, Drivers, OSD, sccm, SCCM 2012, sccm 2012 R2, SCCM 2012 R2, SCCM 2012 SP1, sccm RTM, Task Sequence by Kenny Buntinx [MVP]


Hi ,

Lately we had an issue on a CM2012 R2  production environment when exporting a “task sequence” from our Acceptance environment and importing that exported “task sequence” into production , and ran into an error where our task sequence import would fail with out of memory message.

The exact message was : “System.OutOfMemoryException , Exception of type ‘System.OutOfMemoryException’ was thrown” as shown in the picture below:


Several people recommended me to increase the WMI memory allocation by doing this : . Anoop links to the “_providerhostquotaconfiguration” class in his article. Anoop’s advice is not uncommon, although supportability of the matter is questionable without PSS/CSS support , it’s a common test/fix giving on PSS/CSS calls related to slow or underperforming console issues.

My advice : DON’T DO THIS BLINDLY or without PSS/CSS support . You’d be crazy doing anything to WMI on a ConfigMgr production environment that you don’t understand the impact off. And if it’s to a component as critical as WMI is to ConfigMgr than you’d better do your homework before implementing it in production.

And this blog post explains what the impact is:

We increased the WMI memory allocation with PSS support until 8Gb memory (Server having 16 Gb physical memory) , but no luck at all.

A little recap and issue definition:

  1. 1. We created a OSD Task sequence deployment in our acceptance environment.
    2. Once validated , we exported the TS without content (Content is located on a shared UNC storage path) but with dependencies.
    3. We tried to import the exported TS into production, the import fails both trough the GUI and via the powershell cmdlts. The import in production of the exported tasksequence fails with an out of memory error as shown in the screenshot above
    4. We tested both on the Primary site server itself as via remote console –> same result
    5. We have sufficient memory available on the server. I saw that the PowerShell session on the primary site server used up to 1.5Gb ram during the import. (memory was not maxed out (74% used))

Further investigation leads us to the size of the exported Task Sequence , which was about 235 Mb ( without content , go figure ! ) . Probably you would say : “What the hell did you put into that task sequence ????? ”. Well , the customer needs to support 55 different hardware models because of the way they need to buy there hardware. Crazy , I know and the fact is that they know that as well , however they can’t change this purchase behavior.

That being said , they have 55 HW driver packs and they have around 4800 drivers imported in there CM12 Driver DB .

After testing , we discovered that if the imported task sequence is more or less bigger then 135Mb in size , it will fail to import with the error displayed above. Once we lowered the number of drivers being referenced in the driver packages and therefore also in the CM12 driver database itself and the exported TS would be below 135mb in size , the import succeeded. However we could never pinpoint the exact size of the task sequence when it would fail as this was between 135 and 145 Mb.

What I recommend you to do:

  • One of the biggest mistakes customers make is to go the manufacturer website and grab every driver with those so called “enterprise driver packs” that contain drivers for multiple models…. Hell no , mostly the drivers are out dated, full of additional crap…
  • Use common sense and  only import drivers that are applicable to machines in your environment. I do not recommend that drivers are blindly imported into ConfigMgr where there is no actual benefit. This will just cause the database to bloat and the task sequences to become unwieldy. I recommend that any unused drivers/driver packages are removed from ConfigMgr
  • If you have a large number of Manufacturers and models or you run into conflicts, you can apply the driver package based on category or apply a specific package, especially when exporting / importing task sequences .
  • Typically graphic cards , Intel Vpro , Soundcard drivers or custom “hotkey” drivers are “bad” drivers. Those should be installed with applications from the setup.exe or msi.

To give you an idea , we went for a Lenovo C30 desktop model from +_ 400 drivers to 22 drivers. Keep it clean and tight . It will cost you more energy in the beginning , but will save you a lot of time when you need to debug. That’s the message I am trying to give you !

Hope it helps ,

Kenny Buntinx

MVP Enterprise Client Management

ConfigMgr 2012 SP1 R2 Intune: CloudUserSync – delta sync to cloud failed

5:14 am in CM12, CM12 R2, CM12 SP1, ConfigMgr, ConfigMgr 2012, intune, MDM, sccm, SCCM 2012, sccm 2012 R2, SCCM 2012 R2, SCCM 2012 SP1, UDM, Windows Intune by Kenny Buntinx [MVP]



After configuring a trial intune subscription I got a funny error in the CloudUserSync log:

ERROR: SetLicensedUsers exception The Dmp Connector cannot connect to Windows Intune. Verify that you are connected to the Internet,….
UserSync: Failed to perform delta sync. error = Unknown error 0x8013150C, 0x8013150C

further down in the log file :

ERROR: GetServiceAddresses – LSU cannot be reached: System.ServiceModel.ProtocolException: The content type text/html; charset=UTF-8 of the response message does not match the content type of the binding (application/soap+xml; charset=utf-8). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly


If you search for this error you can see this happening with other services as well (Azure) and it is where the binding from your local server doesn’t match the endpoint (in this case intune/Azure)

Turned out that the customer provide me with a demo lab environment and it was still sitting on System Center Configuration Manager R2 Preview Smile

#Notetomyself : Check all components on the correct versioning before you start . Never take it for granted Smile with tongue out


Hope it Helps ,

Kenny Buntinx

Enterprise Client Management MVP