Retire or wipe mobile devices via PowerShell

This blog post will be about a new tool, written in PowerShell, to retire and/ or wipe a mobile device. Let’s start with the fact that I know that it’s possible to retire and/ or wipe a mobile device through the ConfigMgr console, but that didn’t stop me from creating this tool. The reason for that is related to how mobile devices are managed and who is usually responsible.

In most cases the service desk is responsible for helping end-users with their mobile devices. Now what if a company rather not provides the ConfigMgr console to the service desk, or a company wants to prevent the service desk from wiping a mobile device? That’s were this tool comes in place.

>> Available via download here on the TechNet Galleries! <<

Overview

RW_Overview

Now lets start with a quick overview of this tool. The interface is pretty straight forward. It provides a textbox to provide a username. This textbox has a tooltip to provide information about the required information. After providing a username the Get button can be used to get the registered mobile devices of the specified user. The mobile devices, of the specified user, will be shown in the datagridview. After selecting a mobile device, in the datagridview, the Retire and/or Wipe buttons will enable, if applicable. Wiping a mobile device is not applicable for Windows (RT) devices.

Messages

This tool provides a few messages based on the actions performed by the administrative user. The following message can show, based on the provided input.

RW_ValidUsernameThe message Please provide a valid username will show when the textbox was left empty and the Get button was used already.

Together with this message, also the error message Please verify the username will show next to the textbox.

RW_ExistingUsernameThe message Please provide an existing username will show when a wrong username was specified.

Together with this error message, also the error message Please verify the username will show next to the textbox.

RW_DeviceUsernameThe message Please provide an user with a primary mobile device will show when an username was specified that doesn’t have a (primary) mobile device configured.

Together with this message, also the error message Please verify the username will show next to the textbox.

RW_GenericIssueThe message Please verify the connection with the specified site server will show when anything else will go wrong. In most cases that will be an issue with the provided information for starting the tool.
RW_VerificationRetireThe message Are you sure that you want to retire the mobile device with the ResourceId <ResourceId> will show when a mobile device was selected and the Retire button was used.
RW_InitiatedRetireThe message The action to retire the mobile device is successful initiated will show when the action to retire the mobile device was successfully initiated.
RW_VerificationWipeThe message Are you sure that you want to wipe the mobile device with the ResourceId <ResourceId> will show when a mobile device was selected and the Wipe button was used.
RW_InitiatedWipeThe message The action to wipe the mobile device is successful initiated will show when the action to wipe the mobile device was successfully initiated.

Usage

Before this tool can be used, the user, or service account, used to start this tool, requires at least the permissions as described in this post. Besides those permissions, there are no special requirements for using this tool. I also didn’t use the ConfigMgr cmdlets, which completely removes the dependency to install the ConfigMgr console (or do something creative with the cmdlets).

To start this tool the following parameters are available.

  • SiteServer: This parameter is mandatory and should point to a server containing the SMS provider;
  • SiteCode: This parameter is mandatory and should be the (primary) site code of the mobile devices;
  • AllowWipe: This switch is optional and enables an additional button to wipe a mobile device.

All these parameters together will make a complete example look like this.

.\Retire-MobileDevice.ps1 -SiteServer CLDSRV02 -SiteCode PCP -AllowWipe

Troubleshooting Windows Phone 8.1 enrollment – Part 2

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.

FieldMedic FieldMedic_Advanced FieldMedic_Advanced_Providers
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>.
FieldMedic_Advanced_Enterprise FieldMedic_Advanced_Logging FieldMedic_Advanced_Report
In the categories screen select Enterprise and return to the begin screen of the app. Start logging by selecting Start Logging. Now perform a normal enrollment and select Stop Logging. Provide a Report title and Save the logging.

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.

The MDM distribution point

imageThis blog post will be about the MDM distribution point. The MDM distribution point is the distribution point that’s added after completing the Microsoft Intune integration. To be honest, I didn’t even know that the distribution point was named MDM distribution point. Also, I don’t know if it’s the official name, but I do know that it’s being referenced like that in every related log file.

In the rest of this blog post I’ll describe the high level flow of a package to the MDM distribution point.

SMS_DISTRIBUTION_MANAGER

The SMS_DISTRIBUTION_MANAGER is the default component for handling all the content notifications. Once a distribution point is added to a package, the SMS_DATABASE_NOTIFICATION_MONITOR drops a notification file in the distmgr.box and by that triggers the SMS_DISTRIBUTION_MANAGER to start processing the package. So far nothing different from a normal distribution point.

What makes it different is what follows now. The SMS_DISTRIBUTION_MANAGER detects that the package is targeted to the MDM distribution point. This triggers the SMS_DISTRIBUTION_MANAGER to copy the package to the DMP connector share instead of going the normal route to a (remote) distribution point. The DMP connector share is a shared folder named SMS_OCM_DATACACHE and is located on the site server in the installation directory of ConfigMgr. After that the SMS_DISTRIBUTION_MANAGER is done with its work for this package.

SMS_OUTGOING_CONTENT_MANAGER

The SMS_OUTGOING_CONTENT_MANAGER is the component for sending the packages targeted to the MDM distribution point. Just like with a normal cloud distribution point this action is not performed before encrypting the files. The SMS_OUTGOING_CONTENT_MANAGER picks up the content in the SMS_OCM_DATACACHE and uses it as the content source directory of the package. The next thing the SMS_OUTGOING_CONTENT_MANAGER does is encrypting the content files and for that it uses a temporary folder named SoftwarePublishing located, by default, in C:\Windows\TEMP\. When the content files are encrypted they’re uploaded to the MDM distribution point and, like all the connections with Microsoft Intune, for connecting to the MDM distribution point the certificate issued by SC_Online_Issuing is used. This certificate is generated during the completion of the Microsoft Intune integration.

When its all done the SMS_OUTGOING_CONTENT_MANAGER drops a state message in auth\statesys.box\incoming that will be picked-up by the normal process for state messages.

More information

Read the smsdbmon.log, the statesys.log, the distmgr.log and the outgoingcontentmanager.log for all the information about this whole process. For more information about all the log files see: https://technet.microsoft.com/en-us/library/hh427342.aspx

Updated Configuration Baseline and Hardware Inventory for Windows Phone 8.1

Microsoft has started with releasing the GDR2 update for Windows Phone 8.1. The good thing from a management perspective is that this update contains new management features. There are seven new additions to the PolicyManager configuration service provider (CSP). As I created the Windows Phone 8.1 configuration baseline and the Windows Phone 8.1 hardware inventory extension, I’ve updated both of them with these latest additions. This blog post will describe the newly added settings and a reminder about the download locations.

Note: Another new feature that comes with the GDR2 update is bulk enrollment. Even though it’s not part of this post, I thought it’s definitely worth mentioning. For more information see the Windows Phone 8.1 MDM Protocol document.

New settings

The newly added settings are described in the latest version of the Windows Phone 8.1 MDM Protocol document. Based on that document I’ve added the following policies to the inventory and the baseline:

  • ./Vendor/MSFT/PolicyManager/My/Connectivity/CellularAppDownloadMBLimit;
    This policy specifies the maximum app file size in MB allowed for downloading through cellular connection.
  • ./Vendor/MSFT/PolicyManager/My/Connectivity/AllowManualVPNConfiguration;
    This policy allows the enterprise to enforce a VPN protection by disabling all VPN settings.
  • ./Vendor/MSFT/PolicyManager/My/Wifi/WLANScanMode;
    This policy defines the frequency mode for active Wi-Fi scanning trigger when screen is off and on.
  • ./Vendor/MSFT/PolicyManager/My/Experience/AllowTaskSwitcher;
    This policy allows the company to disable the task switcher completely.
  • ./Vendor/MSFT/PolicyManager/My/Security/AntiTheftMode;
    This policy allows enterprises to prevent users from enabling the Anti Theft mode.
  • ./Vendor/MSFT/PolicyManager/My/DataProtection/RequireProtectionUnderLockConfig;
    This policy allows data encryption of email data and associated attachments.
  • ./Vendor/MSFT/PolicyManager/My/DataProtection/EnterpriseProtectedDomainNames;
    This policy specifies the enterprise domain names.

Note: These settings will fail on devices that are not updated to Windows Phone 8.1 GDR2.

Available for download

Starting today these updated files are available for download via the TechNet Galleries on the following locations:

Further reading

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

Installing the Microsoft Intune client directly after a task sequence

This blog post will be about a bit strange scenario, it will be about deploying a device via a task sequence of ConfigMgr and ending up with the Microsoft Intune client. There are some cases in which the customer elects to manage some devices through Microsoft Intune, instead of ConfigMgr, but still wants to deploy the operating system via ConfigMgr. In those cases creativity is required to get the Microsoft Intune client installed.

The ConfigMgr client and the Microsoft Intune client can’t coexist on one device and it’s not possible to remove the ConfigMgr client during the task sequence (without breaking the task sequence).  That’s were the SMSTSPostAction task sequence variable comes in place. This variable can be used to trigger an (unmonitored) action after the task sequence is completed. In this blog post I’ll provide a simple PowerShell script to remove the ConfigMgr client and to install the Microsoft Intune client. Also, I’ll show how to use this PowerShell script in a task sequence.

Script

Now let’s start with the PowerShell script, by going through it step-by-step. The first step is the declaration of the required variables. Most of these variables are set to the default values. The $NewPath variable will be used as a temporary folder.

$NewPath = "C:\Temp" $CertificateName = "MicrosoftIntune.accountcert" $UninstallPath = "C:\Windows\ccmsetup" $UninstallerName = "ccmsetup.exe" $UninstallerArguments = "/Uninstall" $InstallerName = "Microsoft_Intune_Setup.exe" $InstallerArguments = "/Quiet"

The next step is to copy the Microsoft Intune client installation files to the temporary folder. This is done to overcome installation problems from the initial location after copying the installation files during the task sequence. This can be done by creating the temporary folder via the New-Item cmdlet and by copying the installation files via the Copy-Item cmdlet.

New-Item $NewPath -Type Directory Copy-Item "$PSScriptRoot\$InstallerName" -Destination $NewPath Copy-Item "$PSScriptRoot\$CertificateName" -Destination $NewPath

After everything is in place the removal can be started of the ConfigMgr client. This can be done by triggering the Start-Process cmdlet and waiting for that action to finish.

Start-Process -FilePath "$UninstallPath\$UninstallerName" ` -ArgumentList $UninstallerArguments -Wait -PassThru

After the removal of the ConfigMgr client it’s possible to start the installation of the Microsoft Intune client. This can be done by triggering the Start-Process cmdlet again and letting it wait for the action to finish. Keep in mind that when that process finishes the Microsoft Intune client is not fully installed yet. The processes are started to trigger all the different agent installations.

Start-Process -FilePath "$NewPath\$InstallerName" ` -ArgumentList $InstallerArguments -Wait -PassThru

At the end when the removals and installations are done, it’s time to clean up the installation files that were copied. This can be done by using a simple Remove-Item action on the temporary folder.

Remove-Item $NewPath -Force -Recurse

Save the script as Install-IntuneClient.ps1 and add the script together with the Microsoft Intune client installation files into one old-school Package. This Package does not require a Program and will only be used to provide the content during the task sequence. That means that this Package will contain the following three files, Microsoft_Intune_Setup.exe, MicrosoftIntune.accountcert and Install-IntuneClient.ps1.

Task Sequence

Now let’s have a look at how to use this PowerShell script in a task sequence. Well, the actual PowerShell script will not be started during the task sequence, but it will be added as an action directly after the task sequence is finished.

1 CopyClientFilesThe first action is to copy the content of the old-school Package, used to hold the previously mentioned files, to a local location on the device. This can be achieved by a simple Run Command Line step with a similar command to XCOPY.EXE “.\*.*” “%TEMP%” /HERCIY.
2 PostActionThe second action is to trigger an (unmonitored) action after the task sequence is completed. This can be achieved by a Set Task Sequence Variable step that will set the variable SMSTSPostAction to a similar command as PowerShell.exe -ExecutionPolicy ByPass -File “%TEMP%\Install-IntuneClient.ps1”.

All together this will make sure that after a successful task sequence the created PowerShell script will be started. I’ve tested this now a numerous times and it works like a charm, just keep in mind that it’s triggered after the task sequence is started. That means that this action is not part of the task sequence progress and by that not monitored. To achieve something like that, the PowerShell script can be adjusted to log and sent more information.

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.