Windows Phone 8.1

This time a short blog post about the Microsoft Intune Company Portal app for Windows Phone. More specifically, about whitelisting the Microsoft Intune Company Portal app for Windows Phone. When whitelists, also known as Allowed Apps lists, are used, for allowing access to applications on a Windows Phone, even the Microsoft Intune Company Portal app has to be added to that list. In that case the Windows Phone Store variant can simply be added, based on the link in the Windows Phone Store, but the Download Center variant is a bit more challenging.

In this post I’ll provide the required information to find the app product ID for the Microsoft Intune Company Portal app for Windows Phone. As the app might be updated in the future, I’ll provide the procedure to find the information including the current app product ID.

Windows Phone 8.1

For Windows Phone 8.1 an appx variant of the Microsoft Intune Company Portal app for Windows Phone 8.1 is available for download in the Download Center. To get the required app product ID, perform the following steps.

Rename the CompanyPortal.appx to CompanyPortal.zip;

Open the CompanyPortal.zip and navigate to the AppxManifest.xml;

Open the AppxManifest.xml and search for PhoneProductId.

The value shown with the PhoneProductId is the required app product ID. This current value is f20abf45-bf96-4832-984b-34336931a95f.

Windows Phone 8.0

For Windows Phone 8.0 a xap variant of the Windows Intune Company Portal app for Windows Phone is available for download in the Download Center. To get the required app product ID, perform the following steps.

Rename the SSP.xap to SSP.zip;

Open the SSP.zip and navigate to the WMAppManifest.xml;

Open the WMAppManifest.xml and search for App ProductID.

The value shown with the App ProductID is the required app product ID. This current value is 01914a77-09e7-4f01-88d1-099162777f9b.

This blog post will be about the other magical store world of Windows Phone 8.1 and that’s the world of the Windows Phone Store. By now, I think many are already aware of the different possibilities for the Windows Phone Store, but I thought it would be time for a complete overview like I did for Windows Phone 8.1 and the Microsoft Intune Company Portal app.

This post will contain the different scenarios for providing (limited) access to the Windows Phone Store. These scenarios will be explained for Microsoft Intune standalone and Microsoft Intune hybrid.

Scenarios

Now lets start with summarizing the different scenarios that are possible for providing (limiting) access to the Windows Phone Store. I found the following three scenarios and I’ll go through them in detail after listing them:

Scenario 1: Completely block the Windows Phone Store;

This scenario will be about completely blocking the access to the Windows Phone Store;

Scenario 2: Block the Windows Phone Store except…;

This scenario will be about blocking the access to all the apps from the Windows Phone Store except for specifically configured exceptions;

Scenario 3: Allow the Windows Phone Store except…;

This scenario will be about allowing the access to all the apps from the Windows Phone Store except for specifically configured exceptions.

Scenario 1: Completely block the Windows Phone Store

The first scenario is also the most restricting scenario. This scenario will completely block the access to the Windows Phone Store. On a high-level, this can be configured by performing the configurations mentioned below. These configurations are based on the current versions of ConfigMgr and Microsoft Intune.

Environment

Configuration

Microsoft Intune standalone

This can be achieved by creating and deploying a Windows Phone Configuration Policy (Windows Phone 8.1). In the Applications section enable the Allow application store (Windows Phone 8.1 +) setting and configure it to No.

Microsoft Intune hybrid

This can be achieved by creating a Configuration Item of the Mobile device type and selecting the Store mobile device settings group. Configure the Application store setting to Prohibited, add the configuration item to a configuration baseline and deploy it.

Note: In both cases this is also still possible via a custom OMA-URI. The value should be set to 0 and the location would be the following ./Vendor/MSFT/PolicyManager/My/ApplicationManagement/AllowStore.

Scenario 2: Block the Windows Phone Store except…

The second scenario provides a bit more room for movement within the Windows Phone Store. In this scenario the Windows Phone Store will be accessible, but only for specifically specified applications. Every application that’s not specified will be disabled when it was already installed, or will not be available when the installation is tried via the Windows Phone Store. On a high-level, this can be configured by performing the configurations mentioned below. These configurations are based on the current versions of ConfigMgr and Microsoft Intune.

Environment

Configuration

Microsoft Intune standalone

This can be achieved by creating and deploying a Windows Phone Configuration Policy (Windows Phone 8.1). In the Allowed & Blocked Apps list for Windows Phone section make sure the Allow devices to install only the listed apps setting and add the App URL to the app in the Windows Phone Store.

Microsoft Intune hybrid

This can be achieved by creating a configuration item for a mobile device and selecting the Allow and Blocked Apps list (Windows Phone 8.1) mobile device settings group. Make sure the Allowed apps list setting is selected and add the App URL to the app in the Windows Phone Store. Now add the configuration item to a configuration baseline and deploy it.

Note: In both cases this is also still possible via a custom OMA-URI. Via OMA-URI there is also a bit more flexibility, as it also provides the ability to allow a specific publisher. The location of the OMA-URI would be the following ./Vendor/MSFT/PolicyManager/My/ApplicationManagement/ApplicationRestrictions.

Scenario 3: Allow the Windows Phone store except…

The third scenario provides the most room for movement within the Windows Phone Store. In this scenario the Windows Phone Store will be accessible, except for specifically specified applications. Every application that’s specified will be disabled when it was already installed, or will not be available when the installation is tried via the Windows Phone Store. This could even be used to block certain line-of-business applications. On a high-level, this can be configured by performing the configurations mentioned below. These configurations are based on the current versions of ConfigMgr and Microsoft Intune.

Environment

Configuration

Microsoft Intune standalone

This can be achieved by creating and deploying a Windows Phone Configuration Policy (Windows Phone 8.1). In the Allowed & Blocked Apps list for Windows Phone section make sure the Block devices from opening the listed apps setting and add the App URL to the app in the Windows Phone Store.

Microsoft Intune hybrid

This can be achieved by creating a configuration item for a mobile device and selecting the Allow and Blocked Apps list (Windows Phone 8.1) mobile device settings group. Make sure the Blocked apps list setting is selected and add the App URL to the app in the Windows Phone Store. Now add the configuration item to a configuration baseline and deploy it

Note: In both cases this is also still possible via a custom OMA-URI. Via OMA-URI there is also a bit more flexibility, as it also provides the ability to block a specific publisher. The location of the OMA-URI would be the following ./Vendor/MSFT/PolicyManager/My/ApplicationManagement/ApplicationRestrictions.

Results

Now that I’ve gone through the different scenarios it’s time to look at the results of those configurations. Below are screenshots available per scenario. For the first and second scenario I choose to go for a screenshot of the App list, as it provides the best visible result. For a similar reason I choose to go for a screenshot of the specific app, in the Windows Phone Store, for the third scenario.

Scenario 1

Scenario 2

Scenario 3

The result of the first scenario is a completely blocked Windows Phone Store.

The result of the second scenario is that every app from the Windows Phone Store is blocked, except for the Snapcat app.

The result of the third scenario is that every app from the Windows Phone Store is allowed, except for the Snapcat app.

More information

For more information about Microsoft Intune standalone, or Microsoft Intune hybrid, in combination with the Windows Phone Store, please refer to the following links:

This blog post will be about the magical world of Windows Phone 8.1 and the Microsoft Intune Company Portal app. More specifically, about Windows Phone 8.1 and the twoMicrosoft Intune Company Portal apps. The Microsoft Intune Company Portal app of the Windows Phone Store and the Microsoft Intune Company Portal app deployed via either Microsoft Intune or ConfigMgr.

Yes, I know there was recently a KB article released about the same subject. In this post I’ll go through more scenarios and I’ll go in more detail about the possible solutions and the pro’s and cons of those solutions.

Scenarios

Now lets start with summarizing the different scenarios that are possible with the combination of Microsoft Intune, ConfigMgr, Windows Phone 8.1 and the Microsoft Intune Company Portal app. I found the following three scenarios and I’ll go through them in detail after listing them:

The first scenario is also the easiest scenario. With Microsoft Intune standalone and no need for code-signing certificates, or the management of Windows Phone 8 devices, there will not be a problem with possibly installing the two versions of the Microsoft Intune Company Portal app.

In this scenario simply use the the Microsoft Intune Company Portal app of the Windows Phone Store.

The second scenario will be more complicated. With Microsoft Intune standalone and the requirement of either a code-signing certificate, or the management of Windows Phone 8 devices, there can be challenges with possibly installing the two versions of the Microsoft Intune Company Portal app.

When a code-signing certificate, or the management of Windows Phone 8 devices, is required, it’s also required to upload a signed Microsoft Intune Company Portal app to Microsoft Intune. That process will automatically create a deployment for the Microsoft Intune Company Portal app. After this, even the enrollment of Windows Phone 8.1 is not possible without a deployment of the Microsoft Intune Company Portal app. This gives us two options to choose from for the Microsoft Intune Company Portal app.

Company Store app

The first option is to make the Microsoft Intune Company Portal app, deployed via Microsoft Intune, the only available Microsoft Intune Company Portal app by blocking the version from the Windows Phone Store.

That configuration will make sure that the Microsoft Intune Company Portal app, deployed via Microsoft Intune, truly is the only available Microsoft Intune Company Portal app. It’s now not possible anymore to have two functional Microsoft Intune Company Portal apps on a Windows Phone 8.1 device.

Windows Phone Store app

The other option would be to make the Microsoft Intune Company Portal app, of the Windows Phone Store, (close to) the only available Microsoft Intune Company Portal app by changing the deployment of the Microsoft Intune Company Portal app in Microsoft Intune. That’s possible because the deployment is accepted in both the install and the uninstall state.

This can be achieved by editing the standard created deployment of the Microsoft Intune Company Portal app. The standard Approval configuration is Available Install and that can be adjusted to Uninstall. Using Not applicable is not an option as it will cause failures similar to when no deployment exists.

That configuration will make the Microsoft Intune Company Portal app, of the Windows Phone Store, almost always the only available Microsoft Intune Company Portal app. There remains one situation in which it’s still possible to install the Microsoft Intune Company Portal app, deployed via Microsoft Intune. That situation comes when the workplace settings of the company are opened. This provides the option of download hub, which in fact will download and install the Microsoft Intune Company Portal app that’s deployed through Microsoft Intune. No matter how the deployment is configured, this option will always be available in this scenario.

Scenario 3 – Microsoft Intune integrated with ConfigMgr

The third scenario is as complicated as the second scenario. With Microsoft Intune integrated with ConfigMgr, there can also be challenges with possibly installing the two versions of the Microsoft Intune Company Portal app.

When Windows Phone enrollment is enabled, it’s also required to add an application of a signed Microsoft Intune Company Portal app. That application has to be deployed to be able to enroll a Windows Phone 8.1 device. This gives us two options to choose from for the Microsoft Intune Company Portal app.

Company Store app

The first option is to make the Microsoft Intune Company Portal app, deployed via ConfigMgr, the only available Microsoft Intune Company Portal app by blocking the version from the Windows Phone Store.

This can be achieved by creating a Configuration Baseline in ConfigMgr. That Configuration Baseline has to contain a Configuration Item with at least the following configuration:

That configuration will make the Microsoft Intune Company Portal app, deployed via Microsoft ConfigMgr, truly the only available Microsoft Intune Company Portal app. It’s now not possible anymore to have two functional Microsoft Intune Company Portal apps on a Windows Phone 8.1 device.

Windows Phone Store app

The other option would be to make the Microsoft Intune Company Portal app, of the Windows Phone Store, (close to) the only available Microsoft Intune Company Portal app by changing the requirements of the Microsoft Intune Company Portal app in ConfigMgr.

This can be achieved by editing the requirements of the standard Deployment Type of the Microsoft Intune Company Portal app and adding a requirement for only Windows Phone 8.0 devices. This requirement will make sure that the Microsoft Intune Company Portal app will not show in any Company Portal, on a Windows Phone 8.1 device, as an optional installation.

That configuration will make the Microsoft Intune Company Portal app, of the Windows Phone Store, almost always the only available Microsoft Intune Company Portal app. There remains a couple of situations in which it’s still possible to install the Microsoft Intune Company Portal app, deployed via ConfigMgr.

The first situation comes during the enrollment of a Windows Phone 8.1 device. After the account is added there is the option of Install company app, which in fact will download and install the Microsoft Intune Company Portal app that’s deployed via ConfigMgr.

The second situation comes when the workplace settings of the company are opened. This provides the option of download hub, which in fact will download and install the Microsoft Intune Company Portal app that’s deployed via ConfigMgr.

No matter how the application is configured, these option will always be available in this scenario.

Conclusion

Even though I like the Microsoft Intune Company Portal app, of the Windows Phone Store, more, it does not seem to be possible, yet, to completely remove the Microsoft Intune Company Portal app that’s deployed through either Microsoft Intune or ConfigMgr. There always seems to be a way to “secretly” install a second Microsoft Intune Company Portal app that’s deployed via either Microsoft Intune or ConfigMgr. Simply keep this in mind with determining how to manage applications on Windows Phone 8.1 devices. That will save a lot of confusion with the end-user.

A few months ago I did a blog post about How to troubleshoot Windows Phone 8.1 enrollment via Microsoft Intune. By then that was the only method to get log files from a Windows Phone 8.1 device for troubleshooting, but that has changed. A few days ago Microsoft released a document describing a different and easier method to get log files from a Windows Phone 8.1 device. This method is all around the, recently released, Field Medic app. As I previously wrote about troubleshooting Windows Phone 8.1 enrollment, I thought it would be good to do a short follow up with this easier method.

Steps

Let’s go through the required steps on a Windows Phone 8.1 device, to get the required logging. It’s pretty straight forward, but definitely good to know.

Download and install the Field Medic app from the Store.

Start the Field Medic app and select Advanced.

In the advanced screen select <16 categories selected>.

In the categories screen select Enterprise and return to the begin screen of the app.

Now connect the Windows Phone 8.1 device to a computer. On the computer open the File Explorer and navigate to [PhoneName] > Phone > Documents > FieldMedic > reports. The folders are numbered like, WPB_000_yyyymmdd_xxxxx. The folder with the most recent date contains the latest log files.

And we’re back in the cloud, back in Microsoft Intune. One of the things customers like to do is customize, as the standards are often to generic. The nice thing with the Company Portal is that it’s already possible to customize things like the text, logo and colors via both Microsoft Intune standalone and Microsoft Intune hybrid (integrated with ConfigMgr). To add-on to that, it’s now also possible to create custom Terms and Conditions, via Microsoft Intune standalone, and in this blog post I’ll show how easy this can be done.

The nice thing is that I can publish custom Terms and Conditions that the users will see when they first use the Company Portal. It doesn’t matter from which device and it doesn’t matter if that device is already enrolled or not. The users will have to accept the custom Terms and Conditions before they can access the Company Portal. What makes it even better is that when I update the custom Terms and Conditions, I can choose if I want the users to accept the new Terms and Conditions again. In that case the user would have to go through the same process again when logging on to the Company Portal.

The last positive note, for now, about custom Terms and Conditions, that I would like to point out, is that they apply to users and not to devices. That means that the users only has to accept each version once.

Configuration

Now let’s go on with the configuration, which, to be quite hones, is not very difficult, but good to know. I’ll go through the different settings and I’ll also try to show the behavior of the different settings. First let’s go through the different available settings, by going through the following three steps.

Select Require users to accept company terms and conditions before using the Company Portal, provide the following information and click Save:

Title: <Provide a title for the custom terms and conditions>;

Text for terms: <Provide a text for the custom terms and conditions>;

Text to explain what it means if the user accepts: <Provide a text describing what it means when the user accepts the custom terms and conditions>;

With Decide whether to require users to re-accept updated terms select one of the following options:

Increase the version number, and require all users to accept the updated terms the next time they open the Company Portal;

Keep the current version number, and require only new users to accept the updated terms;

In my opinion the most important setting is the last setting of the third step. With that specific setting I can decide what happens when I update the custom Terms and Conditions. Let me show that setting in a bit more detail by showing an example. When I create initial custom Terms and Conditions, it will look like the following screenshots that include an example of what it looks like on Windows Phone 8.1.

Configuration

Windows Phone 8.1 Example

Now let’s have a look at what will happen when I update the custom Terms and Conditions. When I update the custom Terms and Conditions and select Increase the version number, and require all users to accept the updated terms the next time they open the Company Portal the version number will increase and it will directly impact the users as shown in the following screenshots.

Configuration

Windows Phone 8.1 Example

When I update the custom Terms and Conditions and select Keep the current version number, and require only new users to accept the updated terms nothing will change for the end user. Simple conclusion is that a major change should always require an increase of the version number.

Besides accepting the custom Terms and Conditions the user can, off course, also decline them. In that case the user will be given an additional question of Are you sure you want to decline the terms and conditions?, including an explanation of what it would mean for the user.

Report

Now the last thing I would like to know is which users accepted the custom Terms and Conditions. The good thing is that Microsoft Intune standalone has a canned report that shows which users accepted the custom Terms and Conditions. This includes the information about the most recent version number that the user accepted and the date and time it was accepted. For example, below are two examples about a user that accepted the initial custom Terms and Conditions and later also accepted the renewed custom Terms and Conditions.

Let’s start my first blog post of this new year with a nice story about a XML that can be used to configure a Windows Phone 8.1 device in a kiosk mode. This XML can be applied on a Windows Phone 8.1 device via OMA-URI settings. As it’s now possible to configure OMA-URI via Microsoft Intune and via Microsoft Intune integrated with ConfigMgr 2012, the information in the post is applicable to both scenario’s. I have to admit that it’s not as simple to configure as kiosk mode for an iOS device, or an Andriod device (via Microsoft Intune), but it does provide a lot more options to configure. In this blog post I will go through the different required elements of the XML and the different configuration options.

<Apps>

The first required element is <Apps>. The list of applications listed in this element is an allowed list of applications. That means that only the listed applications are visible to the end-user. To add applications to this list the productId of an application is required. The following table shows the productId of the default applications, also known as first party applications.

Application

ProductId

Alarms

{5B04B775-356B-4AA0-AAF8-6491FFEA560A}

Battery Saver

{C551F76F-3368-42BB-92DF-7BFBB9265636}

Bing Finance

{1E0440F1-7ABF-4B9A-863D-177970EEFB5E}

Bing Food

{CC512389-0456-430F-876B-704B17317DE2}

Bing Health

{CBB8C3BD-99E8-4176-AD8C-95EC6A3641C2}

Bing News

{9C3E8CAD-6702-4842-8F61-B8B33CC9CAF1}

Bing Sports

{0F4C8C7E-7114-4E1E-A84C-50664DB13B17}

Bing Travel

{19CD0687-980B-4838-8880-5F68ABA1671E}

Bing Weather

{63C2A117-8604-44E7-8CEF-DF10BE3A57C8}

Calculator

{5B04B775-356B-4AA0-AAF8-6491FFEA5603}

Calendar

{36F9FA1C-FDAD-4CF0-99EC-C03771ED741A}

Camera (built-in)

{5B04B775-356B-4AA0-AAF8-6491FFEA5631}

Cortana

{5B04B775-356B-4AA0-AAF8-6491FFEA568C}

Data Sense

{5B04B775-356B-4AA0-AAF8-6491FFEA5646}

Email

{5B04B775-356B-4AA0-AAF8-6491FFEA5614}

Facebook

{0C340A67-3288-4C76-9375-0F2FEFBA0412}

Games

{50A6AEF0-4F35-434B-9308-CB3251303AE4}

Internet Explorer

{5B04B775-356B-4AA0-AAF8-6491FFEA5660}

Maps

{5B04B775-356B-4AA0-AAF8-6491FFEA5686}

Messaging

{5B04B775-356B-4AA0-AAF8-6491FFEA5610}

Music

{D2B6A184-DA39-4C9A-9E0A-8B589B03DEC0}

Office Hub

{5B04B775-356B-4AA0-AAF8-6491FFEA561E}

OneDrive

{AD543082-80EC-45BB-AA02-FFE7F4182BA8}

OneNote

{5B04B775-356B-4AA0-AAF8-6491FFEA561B}

People

{5B04B775-356B-4AA0-AAF8-6491FFEA5615}

Phone

{5B04B775-356B-4AA0-AAF8-6491FFEA5611}

Photes

{5B04B775-356B-4AA0-AAF8-6491FFEA5632}

Podcasts

{C3215724-B279-4206-8C3E-61D1A9D63ED3}

Settings

{5B04B775-356B-4AA0-AAF8-6491FFEA5601}

Storage Sense

{5B04B775-356B-4AA0-AAF8-6491FFEA564D}

Store

{5B04B775-356B-4AA0-AAF8-6491FFEA5633}

Video

{6AFFE59E-0467-4701-851F-7AC026E21665}

Wallet

{5B04B775-356B-4AA0-AAF8-6491FFEA5683}

The productId of the all the other applications, also known as third party applications, can be found in the Windows Phone Store. Simply navigate to the store and select the required application. This will display an URL that includes the productId. For example see the screenshot below that shows a productId of 3a509cd-61d6-df11-a844-00237de2db9e for the Netflix application.

The nice thing is that this isn’t everything that can be configured for the applications. It’s also possible to pin the applications to start by using the <PinToStart> element. When this element is used it’s also required to specify the size and location of the application by using the <Size> and the <Location> elements. The size can be small, medium and large. The location can be provided by using the <LocationX> and the <LocationY> elements. Good to know with those elements is that they start the first line with 0. This all together can make the <Apps> element look like this:

<Buttons>

The next required element is <Buttons>. The buttons in this element can be part of two groups. One group is to lock down the button, which prevents the button from being used and the other group is to remap the button to start an application. To add buttons to this element the XMLname of the button is required. The following table shows the XMLname of the different buttons an the supported actions.

Button

XML name

Block and Override

Remap

Camera

Camera

Supported

No

Back

Back

Not supported

No

Start (Windows Key)

Start

Supported

No

Search

Search

Supported

Yes (App launch)

Volume Up

—

Not supported

No

Volume Down

—

Not supported

No

Power

—

Not supported

No

Like I mentioned the buttons can be configured to be locked and to be remapped. This can be configured by using the <ButtonLockdownList> and <ButtonRemapList> elements. Within both elements the <ButtonEvent> element can be used to specify which button event should be locked or be remapped. This event can be Press and/ or PressAndHold. Within the remap event it’s possible to specify an application by using the earlier mentioned productId. This all together can make the <Buttons> element look like this:

<Settings>

The next required element is <Settings>. This element is an allowed list for the system and application items from the settings menu. That means that only the listed system and application items are visible to the end-user. To add a system or application item to this list the <System> or the <Application> element can be used with the XMLname of the required system or application item. The following table shows the XMLname of the default system and applications items.

<ActionCenter>

The next required element is <ActionCenter>. This element can be used to enable or disable access to the quick settings and notifications, by specifying a value of true or false. This can make the <ActionCenter> element look like this:

<ActionCenter enabled="false"/>

<MenuItems>

The next required element is <MenuItems>. This element can be used to prevent menu items from being resized, moved or pinned to start. That will give the end-user the complete locked down experience, as nothing can be adjusted anymore. Within this element the <DisableMenuItems> element can be used to prevent the menu items from be changed. This can make the <MenuItems> element look like this:

<MenuItems><DisableMenuItems /></MenuItems>

<StartScreenSize>

The last required element is <StartScreenSize>. This element can be used to configure the size of the start screen. The supported sizes are small, medium and large. Medium and large represent 3-column start views, while small represents a 2-column start view . Besides that, small and medium are for 720-pixel or lower resolution displays, while large is for 1080-pixel or higher resolution displays. This can make the <StartScreenSize> element look like this:

<StartScreenSize>Large</StartScreenSize>

<HandheldLockdown>

The previous six elements come together in the <Default> element, which is located in the top level element named <HandheldLockdown>. Those six elements must always be part of the XML. This makes the complete example of this post look like this:

Further reading

More information about the possible configurations on a Windows Phone 8.1 device can be found in the Windows Phone 8.1 MDM Protocol document. This is a living document that gets updated by Microsoft when required.

This blog post will be a follow-up on last weeks blog post about THE Windows Phone 8.1 configuration baseline, as I will show this week how those settings can be added to the hardware inventory. Especially with using multiple configuration baselines and Company Resource Access policies, it’s easy to loose track of the current configuration of, in this case, Windows Phone 8.1. That’s why I took the information about the PolicyManagerconfiguration service provider (CSP), again, as provided in the Windows Phone 8.1 MDM Protocol document, but this time to create a MOF file.

Hardware Inventory settings

By default ConfigMgr (and Microsoft Intune) will inventory a lot of great information, but not about the settings managed via the PolicyManager. That is why I created a MOF file for all the settings in the PolicyManager and that MOF file can be used to extend the current hardware inventory. A good thing to note here is that only settings that are currently configured via the PolicyManager will be available for the hardware inventory. This MOF file will contain all reporting string like the following example about the Allow Cellular Data Roaming setting.

This MOF file adds the inventory information for the following settings:

Allow Action Center Notifications;

Allow Adding Non-Microsoft Accounts Manually;

Allow Auto Connect To WiFi Sense Hotspots;

Allow Bluetooth;

Allow Browser;

Allow Camera;

Allow Cellular Data Roaming;

Allow Copy-Paste;

Allow Cortana;

Allow Developer Unlock;

Allow Idle Return Without Password;

Allow Internet Sharing;

Allow Location;

Allow Manual MDM Unenrollment;

Allow Manual Root Certificate Installation;

Allow Manual WiFi Configuration;

Allow Microsoft Account Connection;

Allow NFC;

Allow Save As of Office Files;

Allow Screen Capture;

Allow Search To Use Location;

Allow Sharing of Office Files;

Allow Simple Device Password;

Allow Storage Card;

Allow Store;

Allow Storing Images From Vision Search;

Allow Sync My Settings;

Allow Telemetry;

Allow USB Connection;

Allow User To Reset Phone;

Allow Voice Recording;

Allow VPN Over Cellular;

Allow VPN Roaming Over Cellular;

Allow WiFi;

Allow WiFi Hotspot Reporting;

Alphanumeric Device Password Required;

Application Restrictions;

Device Password Enabled;

Device Password Expiration;

Device Password History;

Maximum Device Password Failed Attempts;

Maximum Inactivity Time Device Lock;

Minimum Device Password Complex Characters;

Minimum Device Password Length;

Require Device Encryption;

Safe Search Permissions.

Available for download

Starting today this MOF file, for extending the hardware inventory on Windows Phone 8.1, is available for download via the TechNet Galleries. Keep in mind that it contains the currently configurable enterprise policies that can be used to manage these devices. When this gets updated, I’ll try to update the MOF file accordingly.

To use this MOF file, simply download it and import it in ConfigMgr. After this the different settings can be added to the hardware inventory.

Further reading

The information about the configurable enterprise polices can be found in the Windows Phone 8.1 MDM Protocol document, starting with page 132. As mentioned before, this document is available for downloaded here: http://go.microsoft.com/fwlink/?LinkID=279003

This blog post will be about THE Windows Phone 8.1 configuration baseline, for usage with ConfigMgr 2012 (integrated with Microsoft Intune). This configuration baseline is created based on the information provided in the Windows Phone 8.1 MDM Protocol document. That document describes the PolicyManagerconfiguration service provider (CSP), which is the centralized component to handle all Windows Phone supported enterprise policies. It describes in detail every currently configurable policy, by any mobile device management solution.

Configuration Items

I took all the settings, as described in the Windows Phone 8.1 MDM Protocol document, and created separate configuration items for each one of them. In these configuration items I included all the available information about the specific settings, including their descriptions. Based on the possible values of these settings I created a compliance rule with every configuration item, which I configured to the default values. In the compliance rules I also included the information about the possible values.

This baseline contains the following configuration items:

Allow Action Center Notifications;

Allow Adding Non-Microsoft Accounts Manually;

Allow Auto Connect To WiFi Sense Hotspots;

Allow Bluetooth;

Allow Browser;

Allow Camera;

Allow Cellular Data Roaming;

The configuration of this specific item is shown in the screenshots on the side. This is done to provide an example about the configuration of the different items.

Allow Copy-Paste;

Allow Cortana;

Allow Developer Unlock;

Allow Idle Return Without Password;

Allow Internet Sharing;

Allow Location;

Allow Manual MDM Unenrollment;

Allow Manual Root Certificate Installation;

Allow Manual WiFi Configuration;

Allow Microsoft Account Connection;

Allow NFC;

Allow Save As of Office Files;

Allow Screen Capture;

Allow Search To Use Location;

Allow Sharing of Office Files;

Allow Simple Device Password;

Allow Storage Card;

Allow Store;

Allow Storing Images From Vision Search;

Allow Sync My Settings;

Allow Telemetry;

Allow USB Connection;

Allow User To Reset Phone;

Allow Voice Recording;

Allow VPN Over Cellular;

Allow VPN Roaming Over Cellular;

Allow WiFi;

Allow WiFi Hotspot Reporting;

Alphanumeric Device Password Required;

Application Restrictions;

Device Password Enabled;

Device Password Expiration;

Device Password History;

Maximum Device Password Failed Attempts;

Maximum Inactivity Time Device Lock;

Minimum Device Password Complex Characters;

Minimum Device Password Length;

Require Device Encryption;

Safe Search Permissions.

Available for download

Starting today this configuration baseline for Windows Phone 8.1 is available for download via the TechNet Galleries. Keep in mind that it contains the currently configurable enterprise policies that can be used to manage these devices. When this gets updated, I’ll try to update the configuration baseline accordingly.

To use this configuration baseline, simply download it and import it in ConfigMgr. After this the compliance rules can be adjusted, if needed, and the baseline can be deployed.

Further reading

The information about the configurable enterprise polices can be found in the Windows Phone 8.1 MDM Protocol document, starting with page 132. As mentioned before, this document is available for downloaded here: http://go.microsoft.com/fwlink/?LinkID=279003

Award

Subscribe to updates

About

I’m Peter van der Woude, born in 1983 and I’m living together with my wife and two sons in the Netherlands.

Currently I work for KPN Consulting. At this moment my main focus is Enterprise Client Management via Microsoft Intune and/ or System Center Configuration Manager (ConfigMgr 2007/ 2012/ CB) and I love it!