Key configurations steps for implementing the ability to deploy certificate profiles with ConfigMgr 2012

This blog post is about key configuration steps, which are often forgotten, for implementing the ability to deploy certificate profiles with ConfigMgr 2012. By key configuration steps, I’m talking about the key configurations of every component used for creating the ability to deploy certificate profiles. That means Internet Information Services (IIS), Network Device Enrollment Service (NDES), the Certificate Registration Point site system role, the Configuration Manager Policy Module and even Web Application Proxy (WAP). To understand these steps, knowledge of certificates, IIS and ConfigMgr is required, because it’s not a step-by-step configuration guide. Good step-by-step information can be found in the More information section of this blog.

Internet Information Services

imageThe first component I would like to mention is probably the most known component, which is IIS. For IIS to support the long URLs, that come with certificate requests, the following adjustments should not be forgotten:

  • The HKLM\System\CurrentControlSet\Services\HTTP\Parameters registry key must have the following DWORD values:
    • MaxFieldLength key to 65534.
    • MaxRequestBytes key to 16777216.
  • The request-filtering on the Default website must also adjusted to the following values.
    • Maximum allowed content length (Bytes): 30000000
    • Maximum URL length (Bytes): 65534
    • Maximum query string (Bytes): 65534

Network Device Enrollment Service

imageThe next component is probably the core component for deploying certificate profiles, which is NDES. NDES is a role service of Active Directory Certificate Services (AD CS). For NDES to deploy the correct certificate template the following important configuration should not be forgotten:

  • The HKLM\SOFTWARE\Microsoft\Cryptography\MSCEP registry key contains the default certificate that will be deployed. These values should be adjusted to the certificate template name that should be deployed;
  • The account used by the NDES application pool must have Read and Enroll permissions on the configured certificate profile. Without these permissions it will not be possible to request certificates.

Certificate Registration Point

imageThe component that brings it all together, from a ConfigMgr perspective, is the Certificate Registration Point site system role. To make this role function on the Internet there are two key things that should not be forgotten:

  • A public FQDN should be registered for publishing NDES on the Internet;
  • The public FQDN should be used in the configuration of the Certificate Registration Point, as that is the address that the clients will use to perform their certificate request.

Configuration Manager Policy Module

imageThe component that provides the communication between NDES and the Certificate Registration Point is the Configuration Manager Policy Module. This installation should not be forgotten! The installer can be found on the installation media in the folder \SMSSETUP\POLICYMODULE\X64.

During the installation it will request the root certificate as input. This certificate can be found on the primary site server in the certmgr.box inbox.

Web Application Proxy

imageThe component that is optional, but can be used to publish NDES to the Internet, is WAP. One key thing that should not be forgotten is that the December 2014 update rollup for Windows Server 2012 R2 should be installed (see: https://support.microsoft.com/kb/3013769/en-us).

More information

Configuring certificate profiles Configuration Manager
Certificate deployment with System Center 2012 R2 Configuration Manager and Windows Intune
SCEP certificate enrolling using ConfigMgr, CRP, NDES and Windows Intune
Hotfix: Large URI request in Web Application Proxy on Windows Server 2012 R2

Permissions required to use Retire/Wipe in ConfigMgr 2012

The idea of this blog post is similar to my blog posts about the permissions required to use Edit Primary Users/Devices and my blog post about the permissions required to use Resultant Client Settings that I both did a couple of months ago. The difference this time is that the permissions, for using the Retire/Wipe option, are not that weird, but it might be good to know what the results will be of providing an administrative user with the required permissions. Also, I’ve seen some questions around the web lately regarding the possibilities to differentiate in the permissions for using the Retire/Wipe option. In the results of this blog post I’ll provide some information about the impact of these required permissions.

Introduction

In this blog post I’ll explain the permissions that are required to use the Retire/Wipe option and, while I’m touching the subject anyway, the permissions required to use the Cancel Retire/Wipe option. These options are only available for mobile devices enrolled via Microsoft Intune and allow the administrator to retire/wipe a mobile device and to cancel the retire/wipe of a mobile device. I’ll explain this by going through the required permissions and providing information about the impact of a specific permissions.  

Permissions

Now the key thing of this blog post, the minimal permissions required to use the Retire/Wipe option and the Cancel Retire/Wipe option. There is nothing really special between the required permissions, which, on itself, might make it a bit special. To provide an administrator with the minimal rights required for using these options, use the following list of permissions:

  • imageCollection;
    • Read – The Read permission provide access to the collections;
    • Read Resource – The Read Resource permission provides access to the detailed information about the resource, like the targeted deployments and the inventory information;
    • Modify Resource – The Modify Resource permission provides access to make modifications to a the resource, like installing a client and canceling a retire/wipe action;
    • Delete Resource – The Delete Resource permission provides access to delete the resource and by that the Retire/Wipe action.

Note: This also really means that without the Modify Resource permission the administrative user will not have the Cancel Retire/Wipe option and without the Delete Resource permission the administrative user will not have the Retire/Wipe option

Result

The fact that there is nothing more required than the Read, Read Resource, Modify Resource, Delete Resource permissions make it a bit special. These permissions together provides the administrative user with the following available actions on a mobile device (see screenshot).

Retire_Wipe_Device_Result

This means that an administrative user, that has the permissions to delete a resource, also has the permission to retire/wipe a mobile device. That makes sense as both actions eventually delete a device. To add-on to that, even if the administrative user could not retire/wipe a mobile device the administrative user could still directly delete the mobile device. In case not every administrative user is allowed to retire/wipe a mobile device, simply use a collection to scope the administrative users to everything but mobile devices.

imageThe last thing I would like to mention is that this also means that it’s currently not possible to allow an administrative user to only use the Wipe company content and retire the mobile device from Configuration Manager option. If an administrative user has the permissions to retire/wipe a mobile device, the administrative user can use the Wipe company content and retire the mobile device from Configuration Manager option AND the Wipe the mobile device and retire it from Configuration Manager option.

Uninstall the Microsoft Intune client via PowerShell

This post will be a short and quick follow-up on my post earlier this week about uninstalling the Microsoft Intune client. The second method I mentioned in that post was about using the ProvisioningUtil.exe. Personally I think the actions mentioned in that method are too many manual actions, so I created a small PowerShell script with two functions to do exactly the same. In this post I’ll go through the two functions, and how they come together, in three steps.

>> The complete script is available via download here on the TechNet Galleries! <<

Step 1: Get the ServiceId

The first step is that I need to get the service ID for the uninstall command line. The following function goes through the registry path that contains the registry key with the service ID. It simply gets all the items in the specified registry path and loops through it until it finds a GUID. There are no special checks required as that registry path will only contain one registry key with a GUID.

function Get-ServiceId { $RegistryPath = ` "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OnlineManagement" try { $RegistryItems = (Get-ChildItem ` -Path Registry::$RegistryPath -ErrorAction Stop).Name foreach ($RegistryItem in $RegistryItems) { if ($RegistryItem.StartsWith("$RegistryPath\{")) { $ServiceId ` = $RegistryItem.Replace("$RegistryPath\","") break } } return $ServiceId } catch { Write-Output "The Microsoft Intune client is not installed" } }

Step 2: Trigger the uninstall

The next step is that I have to use the service ID in the uninstall command line. The following function uses the service ID to trigger the uninstall of the Microsoft Intune client. That’s also why the service ID is a required parameter for this function. It’s good to note that this function uses the default installation path of the Microsoft Intune client. In case this is adjusted, the value of the variable $ProvisioningUtilPath has to be adjusted.

function Start-Uninstall { param ( [parameter(Mandatory=$true)]$ServiceId ) try { $ProvisioningUtilPath = ` "C:\Program Files\Microsoft\OnlineManagement\Common" $ProvisioningUtilExecutable = ` "ProvisioningUtil.exe" $ProvisioningUtilArguments = ` "/UninstallClient /ServiceId $ServiceId ` /TaskName 'tempTask' /SubEventId 16" Start-Process -FilePath "$($ProvisioningUtilPath)\` $($ProvisioningUtilExecutable)" ` -ArgumentList $ProvisioningUtilArguments -Wait -PassThru } catch { Write-Output "Failed to trigger the uninstall of the ` Microsoft Intune client" } }

Step 3: Usage

The third and last step is to bring the two functions together. This can be achieved by calling the second function with the result of the first function as the input. This also means that the complete script, which is available via the TechNet Gallaries, doesn’t require any specific input parameters.

Start-Uninstall (Get-ServiceId)

Uninstall the Microsoft Intune client

This blog post will be relatively short, but will address a common “issue” with the Microsoft Intune client and that’s the uninstall of the client. I know it’s been addressed already in a couple of blogs, but that seems to be all outdated information. Sometimes even an old batch file with all “hard-coded” MSI GUIDs is mentioned, well that’s definitely outdated by now. In my opinion there are only two real methods to uninstall the Microsoft Intune client. The first one is via the Microsoft Intune administration console and the second one is via the ProvisioningUtil.exe on the client machine. In this blog post I’ll go through both methods.

Method 1 – Microsoft Intune administration console

The first method is, by far, the easiest. This method will simply use the method that was designed to uninstall the client, and that’s using the Microsoft Intune administration console. It will simply create a scheduled task to uninstall the Microsoft Intune client and all the related components by using ProvisioningUtil.exe. This whole process can be followed in the Enrollment.log that is located in C:\Program Files\Microsoft\OnlineManagement\Logs. As anyone can imagine, this is many times better than a batch file with hard-coded MSI GUIDs, because those MSI GUIDs happen to change a lot. To trigger the uninstall of the Microsoft Intune client simply follow the next steps:

  • Retire_WipeLogon on to the Microsoft Intune administration console;
  • Navigate to Groups > All Computers and select the Devices tab;
    • Note: This can be any other Group that contains the device;
  • Retire_Wipe_DeviceSelect the device, click  Retire/Wipe and the Retire device: <device> dialog box will show;
  • Notice that Wipe the device before retiring is grayed out and click Yes;
  • Within a couple of minutes the uninstall process will be triggered on the client.

Method 2 – ProvisioningUtil.exe

The second method is a bit more difficult. This method requires one to manually run ProvisioningUtil.exe. The good readers might notice that this is the same executable, that’s being triggered, as via the retire/wipe action of the Microsoft Intune administration console. It also works the same and also creates the same scheduled task. In previous releases the uninstall command was as simple as ProvisioningUtil.exe /UninstallAgents /WindowsIntune, but this has changed with the latest releases. To be completely sure about this statement, simply navigate to C:\Program Files\Microsoft\OnlineManagement\Common and run ProvisioningUtil.exe /?. This will provide an overview about the following possible parameters:

  • image/UninstallClient – Used to uninstall the Microsoft Intune or AIS client from the machine;
  • /ServiceId – Used to specify a specific service id to scan against;
  • /TaskName – Used to specify the task to be deleted after a successful scan/download/install;
  • /SubEventId – Used to specify the sub event Id that needs to be reported for telemetry.

The funny thing, or maybe annoying for some, is that, even though the help information about ProvisioningUtil.exe indicates that not all parameters are required, all parameters are required. What makes it even better is that it doesn’t seem to use them all, but I wouldn’t be surprised to see that change in the near future. This means that it’s simply copying the example of ProvisioningUtil.exe /UninstallClient /ServiceId {GUID} /TaskName “tempTask” /SubEventId 16 and it’s almost good to go. The only piece of missing information is the GUID of the service. Locally on the client this information can be retrieved from at least one of the following places:

1 EnrollmentLogAfter the installation of the Microsoft Intune client the service ID can be found in the Enrollment.log, by searching on the sentence Initializing for service ID. This will show the GUID of the service.
2 RegistryAfter the installation of the Microsoft Intune client the service ID can be found in the OnlineManagement key that is located at HKLM\SOFTWARE\Microsoft\. This will show a key with the GUID of the service.

This completes the required information and in my case this creates a command line like this: Uninstall_CommandProvisioningUtil.exe /UninstallClient /ServiceId “{3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}” /TaskName “tempTask” /SubEventId 16. To follow the uninstallation of the Microsoft Intune client take a look again at the Enrollment.log. This will also show that it slightly changed the last two parameters of the provided command line.

Note: A manual uninstall of the Microsoft Intune client doesn’t remove the device from the Microsoft Intune administration console.

Windows 10 device enrollment

Updated May 21, 2015: Yesterday Microsoft released a new technical preview build of Windows 10 (build 10122). Within this build the look-and-feel of the enrollment process changed. I’ve updated the enrollment process to reflect these changes.

Windows10_TweetAfter the release of Windows 10 Technical Preview 2 (build 9926) I knew my next blog post would include Windows 10. So far I’m really liking the new start menu, the search, the notifications, the settings and I could go on like that for a while. Blogging about these subjects wouldn’t add something new as it’s already be done by many over the last week. Even the deployments of Windows 10 via MDT and/ or ConfigMgr are already done and covered in blogs. That’s why I looked further, to something that I already tweeted about, to enroll a Windows 10 device in Microsoft Intune (with or without ConfigMgr integration).

Disclaimer: This blog post is based on a technical preview build of Windows 10 (build 10122). The configurations described in this post might change in future releases. I’ll update this post with the next release.

How to enroll a Windows 10 device

A new operating system often means that everything is just in slightly different place. The thing that stayed the same is that the feature is still named Workplace. In Windows 8.1 this feature was located under Network and that’s something that really changed in (the early releases of) Windows 10. Now let’s go through the steps to enroll a Windows 10 device.

Step Action
1 10122_SettingsAccountsAfter logging on to a Windows 10 device, navigate to Settings > Accounts > Work access.
2 10122_ConnectWorkThe Connect to work or school feature provides information about the benefits and restrictions of enrolling your device.

Click Connect.

3 10122_ConnectWork_2The Connect to work or school dialog box will show, asking for your account to enroll the device.

Provide your account and click Continue.

4 YourWorkplace_SSOAs I’ve got AD FS configured with single sign-on I’m redirected to my on-premises AD FS to provide my credentials.

Provide your credentials and click Sign in.

5 10122_ConnectedThe Well done! dialog box will show, stating that your workplace is connected.

Click Done.

6 10122_EnrolledBack in the Connect to work or school feature, it now provides information about the user that enrolled the device.

Click on the user information.

7 10122_EnrolledOptionsThe Connect to work or school feature will now display some additional options to Sync the device, to get Info about the device and to Remove the device.

Clicking on Sync will trigger a synchronization with Microsoft Intune/ ConfigMgr and clicking Remove will trigger the removal of the device.

Click Info.

8 10122_EnrolledSettingsThe Work or school info feature, will provide the basic enrollment information about your device.
9

10122_ClientPropertiesIn this example I enrolled my device in to ConfigMgr, but I’ve could have done the same steps with Microsoft Intune standalone.

Now I can look in ConfigMgr to see the device details. I can see that it recognizes the operating system of Windows 10 and that it enrolled as a mobile device.

Custom terms and conditions for using the Company Portal of Microsoft Intune

Updated September 8, 2015: Since the August 2015 update of Microsoft Intune the creation and deployment of custom Terms and Conditions has changed. An update blog post can be found here: https://www.petervanderwoude.nl/post/multiple-custom-terms-and-conditions-for-device-enrollment-and-company-access/

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.

  1. Logon on to the Microsoft Intune administration console;
  2. Navigate to Admin > Company Portal > Terms and Conditions;
  3. 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
CompPortTC_v1 TC_v1

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
CompPortTC_v2 TC_v2

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.

Initial version Increased version
TC_Report_v1 TC_Report_v2

Windows Phone 8.1 Kiosk mode: Inside AssignedAccessXml

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.

NetflixUrl

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:

<Apps> <Application productId="{3a509cd-61d6-df11-a844-00237de2db9e}"> <PinToStart> <Size>Medium</Size> <Location> <LocationX>0</LocationX> <LocationY>2</LocationY> </Location> </PinToStart> </Application> </Apps>

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

<Buttons> <ButtonLockdownList> <Button name="Start"> <ButtonEvent name="PressAndHold" /> </Button> <ButtonRemapList> <Button name="Search"> <ButtonEvent name="Press"> <Application productId= "{3a509cd-61d6-df11-a844-00237de2db9e}" /> </ButtonEvent> </Button> </ButtonRemapList> </ButtonLockdownList> </Buttons>

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

Element Settings name XML name
System about Microsoft.About
System ease of access Microsoft.Accessibility
System email+accounts Microsoft.Accounts
System advertising id Microsoft.AdvertisingId
System airplane mode Microsoft.AirplaneMode
System battery saver Microsoft.BatterySaver
System Bluetooth Microsoft.Bluetooth
System brightness Microsoft.Brightness
System Cellular+SIM Microsoft.CellularConn
System backup Microsoft.CloudStorageCpl
System workplace Microsoft.CompanyAccount
System date+time Microsoft.DateTime
System quiet hours Microsoft.DoNotDisturb
System driving mode Microsoft.DrivingMode
System feedback Microsoft.Feedback
System find my phone Microsoft.FindMyPhone
System kids corner Microsoft.KidZone
System language Microsoft.Language
System location Microsoft.Location
System project my screen Microsoft.MirrorUX
System notifications+actions Microsoft.NocenterSettings
System lock screen Microsoft.PhoneLock
System region Microsoft.Regional
System sync my settings Microsoft.RoamingCpl
System screen rotation Microsoft.RotationLock
System internet sharing Microsoft.SoftAP
System ringtones+sounds Microsoft.Sounds
System speech Microsoft.Speech
System storage sense Microsoft.StorageSettings
System start+theme Microsoft.Themes
System keyboard Microsoft.TouchKeyboard
System phone update Microsoft.Updates
System VPN Microsoft.VPN
System Wi-Fi Microsoft.WiFi
System NFC Microsoft.NFC
System USB Microsoft.USB
System data sense Microsoft.DataSmart
Application internet explorer Microsoft.IE
Application maps Microsoft.Maps
Application messaging Microsoft.Messaging 
Application Office Microsoft.OfficeMobile 
Application people Microsoft.Contacts 
Application phone Microsoft.Phone 
Application photos+camera Microsoft.Photos 
Application search Microsoft.Search 
Application store Microsoft.Marketplace 
Application wallet Microsoft.Wallet 
Application cortana Microsoft.AssistUX

This all together can make the <Settings> element look like this:

<Settings> <System name="Microsoft.CompanyAccount" /> <Application name="Microsoft.AssistUX" /> </Settings>

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

<?xml version="1.0" encoding="utf-8"?> <HandheldLockdown version="1.0" > <Default> <Apps> <Application productId= "{3a509cd-61d6-df11-a844-00237de2db9e}"> <PinToStart> <Size>Medium</Size> <Location> <LocationX>0</LocationX> <LocationY>2</LocationY> </Location> </PinToStart> </Application> </Apps> <Buttons> <ButtonLockdownList> <Button name="Start"> <ButtonEvent name="PressAndHold" /> </Button> <ButtonRemapList> <Button name="Search"> <ButtonEvent name="Press"> <Application productId= "{3a509cd-61d6-df11- a844-00237de2db9e}" /> </ButtonEvent> </Button> </ButtonRemapList> </ButtonLockdownList> </Buttons> <Settings> <System name="Microsoft.CompanyAccount" /> <Application name="Microsoft.AssistUX" /> </Settings> <ActionCenter enabled="false" /> <MenuItems> <DisableMenuItems /> </MenuItems> <StartScreenSize>Large</StartScreenSize> </Default> </HandheldLockdown>

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.

What is DirectorySyncClientCmd.exe?

AADSync_DirectorySyncClientCmdLet’s end this year, on my blog, with a short blog post about DirectorySyncClientCmd.exe. This executable is part of the Microsoft Azure Active Directory Sync Services (AAD Sync), which is the predecessor of the Microsoft Azure Active Directory Sync tool (DirSync). AAD Sync is the (new) way to connect Azure AD with the on-premises AD. In combination with Microsoft Intune (and ConfigMgr) the most common use case, for AAD Sync, is the synchronization of the on-premises users (and their properties) to the Azure AD.

To trigger the synchronization there is the executable named DirectorySyncClientCmd.exe. That means that, unlike in DirSync, there is no need for PowerShell to trigger a synchronization.

Usage

AADSync_ScheduledTask_thumb[2]This executable is actually only used in one way by AAD Sync. During the installation of AAD Sync a new scheduled task, named Azure AD Sync Scheduler, is created. This scheduled task will run DirectorySyncClientCmd.exe once every three hours. This same scheduled task can be adjusted when there is a need to run the synchronization more often, or less.

Also good to know is that DirectorySyncClientCmd.exe can be started manually, by simple double-clicking it. Even better to know is that this executable has more options. Simply run this executable with the “?” parameter to reveal them. It will show the delta and the initial parameters. The delta parameter is simply the default behavior when the executable is started and the initial parameter can be used when the initial synchronization was skipped.

Result

SynchronizationServiceManagerTo follow the results of triggering DirectorySyncClientCmd.exe, simply use the Synchronization Service Manager. This will show an overview of the actions that were performed during the triggered synchronization (and all the previous synchronizations).

Also good to know is that when DirectorySyncClientCmd.exe is triggered directly, is that it will display the progress on-screen in a Command Prompt.

Manage company policies on Windows Phone 8.1 via OMA-URI settings in Microsoft Intune

A bit more than a month ago, I created THE Windows Phone 8.1 Configuration Baseline for usage with ConfigMgr 2012 (integrated with Microsoft Intune). That Configuration Baseline contains all the currently configurable company policies via OMA-URI settings. At that time the management of OMA-URI settings on Windows Phone 8.1 wasn’t possible via Microsoft Intune standalone, but this has changed with the latest update to Microsoft Intune. That’s why I thought it would be good to dedicate this blog post to creating OMA-URI settings in Microsoft Intune standalone.

As it’s not possible, yet, to export a Configuration Policy in Microsoft Intune, like a Configuration Baseline in ConfigMgr, I will simply show how to create an OMA-URI setting in Microsoft Intune. Also good to know, OMA-URI settings can be used for a lot more then “just” company policies. For example, it can also be used to manage WiFi profiles. Like I mentioned in previous blog posts, and like I will keep on mentioning, all the OMA-URI settings can be found in the Windows Phone 8.1 MDM Protocol document.

Configuration

In this example configuration, I’m going to show how to create a Windows Phone OMA-URI Policy to disable cellular data roaming. The same steps are applicable to all the different OMA-URI settings that are currently available for managing company policies on Windows Phone 8.1. To disable cellular data roaming via an OMA-URI setting, simply perform the following steps:

  • MicrosoftIntune_OMAURI_AddEditLogon on to the Microsoft Intune administration console;
  • Navigate to Policy > Configuration Policies;
  • Click Add… and the Create a New Policy dialog box will show;
  • Navigate to Windows > Windows Phone OMA-URI Policy;
  • Select Create and Deploy a Custom Policy, click Create Policy and the Create Policy page will show;
  • Provide a <Name> and click Add… with OMA-URI Settings and the Add or Edit OMA-URI Setting dialog box will show.
  • Provide the following information and click OK:
    • Setting name: Allow Cellular Data Roaming;
    • Setting description: Allow or disallow cellular data roaming;
    • Data type: Integer;
    • OMA-URI (case sensitive): ./Vendor/MSFT/PolicyManager/My/Connectivity/AllowCellularDataRoaming;
    • Value: 0;
  • Click Save Policy and the Deploy Policy: <Name> dialog box will show;
  • Click Yes and the Manage Deployment: <Name> dialog box will show;
  • Select (a) group(s), click Add and click OK.

Note: It’s not necessary to create a new Windows Phone OMA-URI Policy for every OMA-URI setting. To add more OMA-URI settings to an existing policy, simply select the Configuration Policy and click Edit….

Result

In this case I really like to show the results, but not by showing a screenshot of the device. I want to do this by showing something way cooler in the Microsoft Intune administration console, I want to show the Policy tab, of the Mobile Device Properties, of a device. This tab shows an overview of the deployed policies and more importantly the status of the policies. In this case it shows that my Windows Phone 8.1 device now Conforms with the OMA-URI setting.

MicrosoftIntune_OMAURI

Further reading

More information about using OMA-URI settings with ConfigMgr (integrated with Microsoft Intune) can be found in this post about THE Windows Phone 8.1 Configuration Baseline. Additional to that post is this post about Extending the hardware inventory for PolicyManager settings on the Windows Phone 8.1. That post describes the same OMA-URI settings, but then how to add them to the hardware inventory.

More information about the configurable company polices can be found in the Windows Phone 8.1 MDM Protocol document, starting with page 140. This is a living document that gets updated by Microsoft when required. That also means that the mentioned page number might change in the (near) future.

Manage Microsoft Intune users via PowerShell

This week my blog post will contain some PowerShell again! After almost a month finally some PowerShell on my blog again. Even though Microsoft Intune has no PowerShell support, yet, there are parts that can be managed via PowerShell already. In my blog series about how to integrate Microsoft Intune and ConfigMgr with single sign-on I already showed some related PowerShell cmdlets for adding and verifying a domain name and for enabling Active Directory synchronization.

In this post I will show how to manage the Microsoft Intune users. As in the most scenario’s the users and groups will be synchronized from the on-premises Active Directory, I won’t show how to create users and groups. Instead I will show how to get information about the users, how to license the users and how to work with role memberships for users.

Prerequisites

Before I can start, with showing some PowerShell cmdlets for managing the users, it’s required to connect with the Microsoft Online Services and to get the licensing information.

Connect

The first prerequisite is that I have a Microsoft Intune subscription and that I’m connected to the Microsoft Online Services, via PowerShell. To connect to the Microsoft Online Services I can use the Connect-MsolService cmdlet, as shown below, and provide the Microsoft Intune subscription information in the  dialog box that will show directly after.

Connect-MsolService –Credential $cred

Licenses

The second prerequisite is that I have my license information available. The reason for this is simple, a part of managing users is assigning licenses and the only way to assign licenses is by knowing what’s available.  To get an overview of my licenses I can use the Get-MsolAccountSku cmdlet as shown below.

Get-MsolAccountSku

GetMsolAccountSku

Manage users

During this blog post, I’m assuming that the users are synchronized from the on-premises Active Directory, via Microsoft Azure Active Directory Sync Services, to the Azure Active Directory. When this is not the case the users can be created via the New-MsolUser cmdlet, groups can be created via the New-MsolGroup cmdlet and users can be added to a group via the Add-MsolGroupMember cmdlet.

Information

The first thing I would like to do is to check my users to see if they’re licensed and, if required, even more details about that user. To get the basic information about the user, I can use the Get-MsolUser cmdlet as shown below. In case it’s required to get more details about the user pipe the output through a Format-List.

Get-MsolUser -UserPrincipalName tvanderwoude@petervanderwoude.nl

GetMsolUser

Licensing

I can now see that this user is not licensed. There are two methods to provide this user with a license. The first method is via the Microsoft Intune Account Portal and the second method is via PowerShell. Of course I will do this via PowerShell. To add a license to this user I need the AccountSkuId and with that information I can use the Set-MsolUserLicense cmdlet as shown below.

Set-MsolUserLicense -UserPrincipalName ` tvanderwoude@petervanderwoude.nl -AddLicenses "myintunecloud:INTUNE_A"

When I would now run the Get-MsolUser cmdlet again, the isLicensed value will be set to True. Also, running the Get-MsolAccountSku cmdlet again would show that the ConsumedUnits value is set to 25. To remove the license again, I can simply use the Set-MsolUserLicense cmdlet again and replace the AddLicenses parameter with the RemoveLicenses parameter.

Roles

Another thing I would like to do is assign roles to my users. Roles are used to provide a user with specific administrative permissions within the Microsoft Intune subscription. One thing to keep in mind, with working with the different roles, is that the role names used within PowerShell are slightly different from how they are displayed in the Microsoft Intune Account Portal. The following table shows the minor differences between the role names.

MsolRole Account Portal
User Account Administrator User management administrator
Service Support Administrator Service Support Administrator
Helpdesk Administrator Password Administrator
Company Administrator Global Administrator
Billing Administrator Billing Administrator

Now I want to add this user to the Password Administrator role. To add the user to this role I can use the Add-MsolRoleMember cmdlet as shown below.

Add-MsolRoleMember -RoleName "Helpdesk Administrator" ` -RoleMemberEmailAddress "tvanderwoude@petervanderwoude.nl"

After this I would like to verify if the user is indeed a member of the Password Administrator role. To check the members of a role I can use the Get-MsolRoleMember cmdlet as shown below. One thing to keep in mind here is that this specific cmdlet requires the ObjectId of a role to be used as input parameter.

Get-MsolRoleMember -RoleObjectId ` (Get-MsolRole -RoleName "Helpdesk Administrator").ObjectId

GetMsolRoleMember

To remove an user from a role, I can do the same as with adding a user to a role. The only difference would be that the Remove-MsolRoleMember cmdlet needs to be used. The parameters are the same.

Further reading

A while ago my colleague Ronny de Jong did a blog post about a closer look at the user provisioning of Microsoft Intune. This is a very good read that describes the flow of the the user provisioning when using Microsoft Intune integrated with ConfigMgr. That post also shows how users are licensed in that scenario.