Deploy Wi-Fi profiles to Windows Phone devices with Microsoft Intune OMA-URI policy

One of our partners in The Netherlands that has a lot of experience with EMS deployments is Inovativ. In this blog Ronny de Jong will explain how to deploy WiFi Profiles using OMA-URI policies using Microsoft Intune Cloud (also known as Standalone).

Hi, I am Ronny de Jong and as consultant I am working for Inovativ – a Dutch Microsoft Partner specialized in System Center, Cloud & Data Center Management. My primary focus is on Enterprise Mobility, System Center and Microsoft Azure. As trainer I'm delivering Microsoft courses and being active in the community as blogger & member of System Center User Group NL . Further I'm speaker at community events like TechDays, Experts Live & UG meetings.

With the December update of Microsoft Intune a cool feature OMA-URI support has been added. This seemingly small a feature but it introduces ‘endless’ management capabilities and scenario’s which allows you to take full advantage of managing Windows Phone with Microsoft Intune. This is useful when the setting you need is not configurable in a mobile device security policy.

A good example is the missing feature of deploying Wi-Fi profiles to Windows Phone devices with default policy templates. This is currently only available yet for Android and iOS. With the introduction of OMA-URI support in Microsoft Intune for Windows Phone devices we are able to deploy Wi-Fi profiles with Microsoft Intune. In this blog I’ll show you how to add multiple settings including a Wi-Fi profile with a single OMA-URI policy.

Creating a new policy select Windows Phone OMA-URI Policytemplate.


Provide a meaningful description for further reference as a policy can be used to configure one or more settings.


Next step is to add a OMA-URI WiFi setting, is this example we’ll add DonnystyleWi-Fi profile (WPA2PSK) to our OMA-URI policy. Hereby some imported pointers take into account!

  • There is an undocumented value which requires for the hex value of the Wi-Fi name. This value should be added before the SSID name (see example below). If this value is not configured, the Wi-Fi profile will function but Microsoft Intune will report this as an error (0x87D1FDE8) non-compliant.


  • The OMA-URI must contain the SSID of you Wi-Fi profile further the name used must match the SSID name
  • The pre-shared key value must be unencrypted value when configured in the Intune Management Portal
  • The OMA-URI value is case sensitive



Data Type

String XML


<?xml version="1.0"?>

<WLANProfile xmlns="">


























When complete you can add more settings configured by this OMO-URI policy. As mentioned before in this example we configure a Wi-Fi profile and previous configured settings to lock-down our Windows Phone devices.


When all settings are configured we’ll deploy the policy to a device group which our Windows Phone is member of.


When successfully deployed the OMA-URI Wi-Fi profile policy, the DonnystyleWi-Fi profile is available now on the Windows Phone devices. Based on the configuration (connection mode) automatically a Wi-Fi connection is established. The Wi-Fi profile can’t be edited neither removed.

clip_image009 clip_image011 clip_image013

In this example we deployed a Wi-Fi profile based on WPA2PSK including the pre-shared key. This is just an example how powerful OMA-URI is and how it can be used to deploy Windows Phone settings that are not configurable with a Microsoft Intune policy. An overview of Wi-Fi profile samples for various wireless configurations can be found here. Further you can use your Windows 8.x device to easily retrieve your Wi-Fi profile(s) definition at C:\programdata\Microsoft\Wlansvc\Profiles\Interfaces. In that location should be the various Wi-Fi profiles the machine is aware of in XML format.

For completeness there’re several requirements of defining Wi-Fi profiles which are described in the Windows Phone 8.1 MDM Protocol guide (P.164). Further this guide provides an overview of all possible settings which can be configured by OMA-URI. Special thanks to Joel Stevens (MSFT) for figuring out this problem!