Updated tool: Remote Mobile Device Manager

My early Christmas present, for the community, is an updated version of my Remote Mobile Device Manager tool! This version includes a couple of bug fixes, a couple of added functionalities and a couple of look-and-feel adjustments. In this blog post I’ll provide an overview of those changes, I’ll provide an overview of the new look-and-feel and I’ll show the usage. For an overview of all the previously available features, please refer to my blog post about the previous version of my Remote Mobile Device Manager tool.

>> The updated version is now available for download <<

Changes

Now let’s start with a quick overview of the changes to this new release of my Remote Mobile Device Manager tool. This version includes the following changes and bug fixes:

  • Bug fix 1: In the previous release it was possible to perform remote actions on Windows 10 devices that were not applicable. This has been adjusted by first verifying the platform of the selected device, before providing the list of applicable remote actions;
  • Bug fix 2: In the previous release it could happen that devices were shown that didn’t belong to the provided user. This has been adjusted by adjusting the query, to select the devices of a user, to join on device identifier instead of device name (thanks for the suggestion Iain Fairbairn);
  • Functional 1: Added functionality to sent a sync request to
    de selected device (new functionality starting with Configuration Manager 1610);
  • Functional 2: Added functionality to get the status of a
    sync request for the selected device (new functionality starting with
    Configuration Manager 1610);
  • Look-and-feel 1: In the previous release it would show a button for every remote action. This has been adjusted to a combo box that shows applicable items based on the platform of the selected device (thanks for the suggestion Nickolaj);
  • Look-and-feel 2: Added additional columns to provide information about the serial number and the IMEI of the device (thanks for the suggestion Kent).

Overview

Let’s continue with how these changes impact the new look-and-feel of my Remote Mobile Device Manager tool. This version provides the following look-and-feel.

RMDM_v12

In this look-and-feel there are three sections that I would really like to highlight:

  1. The Remote Actions section has changed. It now provides a combo box and a single button. This combo box will only show the remote actions that are applicable to the platform of the selected device;
  2. The Sync Request and Sync Request State remote actions have been added. The Sync Request remote action will trigger a device to check for new polices and the Sync Request State remote action will show the status of the Sync Request remote action. These remote actions require Configuration Manager 1610;
  3. The Serial number and IMEI columns have been added. These columns provide information that can help with easily getting an overview of relevant information for a device.

Usage

Let’s end this post with the usage of my Remote Mobile Device Manager tool. The good news is. this hasn’t changed. It’s still built on WMI and it still doesn’t require the Configuration Manager cmdlets. Also, to start this tool the following parameters are still available:

  • SiteServer: This parameter is mandatory and should point to a server containing the SMS provider;
  • AllowWipe: This switch is optional and enables the button to wipe (factory reset) a device.
Share

Send sync request to devices

In preparation for an upcoming new release of my Remote Mobile Device Manager tool, this week a short blog post about the Send Sync Request feature. This feature enables the administrator, in a Microsoft Intune hybrid environment, to remotely trigger a synchronization of a device and is available starting with Configuration Manager 1610. In this post I’ll provide some basic information, go through the methods to trigger this action, the Configuration Manager console and PowerShell, and I’ll provide some information about the administrator experience.

Information

Before showing the methods to use the Send Sync Request feature, it’s good to provide some information about when a device typically checks in. The first thing to keep in mind is that when an app, or policy, is deployed, Microsoft Intune will immediately attempt to notify the targeted devices to check in. This should take less than five minutes. If the device doesn’t check in to get the deployed app, or policy, Microsoft Intune tries three more times. When Microsoft Intune couldn’t reach the device, the device will get the deployed app, or policy, on the next scheduled check in. The default check in interval is shown in the table below.

Platform Just enrolled device Default
iOS and Mac OS X Every 15 minutes for 6 hours Every 6 hours
Android Every 3 minutes for 15 minutes, then every 15 minutes for 2 hours Every 8 hours
Windows Phone Every 5 minutes for 15 minutes, then every 15 minutes for 2 hours Every 8 hours
Windows 8.1/10 PCs Every 3 minutes for 30 minutes Every 8 hours

Besides the mentioned check in interval of the device, the end-user can always use the Company Portal app to immediately make the device check for policies. New in this chain is the ability of the administrator to use the Send Sync Request feature. This will request a policy sync on the device.

Method 1: Configuration Manager console

Now let’s start with the easiest method to use the Send Sync Request feature, which is using the Configuration Manager console. This can be achieved by simply performing the next steps.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Devices.

2

MenuOptionSelect a device, managed via Microsoft Intune, right click the device and select Remote Device Actions > Send Sync Request.

Note: The same action is available when selecting a device, managed via Microsoft Intune, and selecting Remote Device Actions > Send Sync Request in the Device section of the Home tab.

Method 2: PowerShell

Next is the method that was the trigger for this blog post, which is using PowerShell. The first thing I noticed is that the Send Sync Request feature is not yet available via the Invoke-CMDeviceAction cmdlet. Not a problem, as I wanted to use WMI. Using WMI removes the requirement of the Configuration Manager cmdlets, which is great for my tool.

This can be achieved by using the Invoke-WmiMethod cmdlet. First connect to the site server (ComputerName) and the correct namespace (Namespace). Now use the SyncNow (Name) method, of SMS_DeviceMethods (Class), with the device identifier as parameter (ArgumentList). Below is an example that brings these parameters together.

Invoke-WmiMethod -ComputerName $SiteServer ` -Namespace root/SMS/site_$($SiteCode) ` -Class SMS_DeviceMethods ` -Name SyncNow ` -ArgumentList ($MobileDeviceId) ` -ErrorAction Stop

Administrator experience

Usually I’ll end my post with showing the end-user experience, but in this case it’s more interesting to look at the administrator experience. The administrator can add an additional column, named Sync Request State, in the Configuration Manager administration console, when looking at devices. That column will provide the status of the sync request, as shown below.

SyncAdminConsole

Another interesting location, to look at, is the SMSProv.log. That log file shows the execution of the sync request. Once the administrator uses the Send Sync Request feature, a similar activity, as shown below, will be available in the log file.

SyncSMSProv

More information

Fore more information about the Send Sync Request feature and the device check in interval, please refer to:

Share

Use PowerShell and Microsoft Graph to access data in Microsoft Intune

This week a short blog about using PowerShell to access data in Microsoft Intune. This can be achieved by using Microsoft Graph. A couple of weeks ago there was a blog post on the Microsoft Intune Support Team Blog about Using the Microsoft Graph API to access data in Microsoft Intune. That post triggered me to look at the PowerShell possibilities, as the Microsoft Graph has an API and an API can be used with PowerShell.

In this blog post I’ll provide the high-level prerequisites for connecting to the Microsoft Graph API and I’ll provide a few examples for querying Microsoft Intune data.

Prerequisites

This blog post is really focused on the queries to the Microsoft Intune data. However, to successfully connect with the Microsoft Graph API there are a few prerequisites that should be in place.

Examples

Now let’s have a look at the PowerShell versions of the published Microsoft Graph Explorer commands and the results of them. I’ll go through all of them and provide the required input and show an example result

User

The first example is to get data related to a single user. This requires a user principal name (UPN), in my case pvanderwoude@petervanderwoude.nl, and the token as input.

Invoke-RestMethod https://graph.microsoft.com/v1.0/users/$UPN ` -Method Get ` -Headers @{"Authorization" = "Bearer $accessToken"}

userUPN

Owned devices

The second example is to get data related to the devices of a single user. Thee information is about the compliance state of the devices of the user. This requires a user principal name (UPN), in my case pvanderwoude@petervanderwoude.nl, and the token as input. The returned information is stored in a hash table.

Invoke-RestMethod https://graph.microsoft.com/v1.0/users/$UPN/ownedDevices ` -Method Get ` -Headers @{"Authorization" = "Bearer $accessToken"}

registeredDevices

Registered owners

The third example is to get the owners of a device. This requires a device GUID and the token as input. The returned information is stored in a hash table.

Invoke-RestMethod https://graph.microsoft.com/v1.0/devices/$GUID/registeredOwners ` -Method Get ` -Headers @{"Authorization" = "Bearer $accessToken"}

registeredOwners

Registered users

The fourth example is to get the users of a device. This requires a device GUID and the token as input. The returned information is stored in a hash table.

Invoke-RestMethod https://graph.microsoft.com/v1.0/devices/$GUID/registeredUsers ` -Method Get ` -Headers @{"Authorization" = "Bearer $accessToken"}

registeredUsers

Applications

The fifth example is to get a list of uploaded applications in Microsoft Intune. This requires the token as input and the returned information is stored in a hash table. However, based on the returned  information, it currently seems to return the applications registered in Azure AD.

Invoke-RestMethod https://graph.microsoft.com/beta/applications ` -Method Get ` -Headers @{"Authorization" = "Bearer $accessToken"}

petervanderwoude.nl

More information

Fore more information about the Microsoft Graph API, in combination with Microsoft Intune and the different tokens, please refer to:

Share

Windows 10 MDM and the MDM Bridge WMI Provider

This week another blog post about Windows 10 and OMA-DM, but this week will be short and different. Starting this week I won’t be referring to OMA-DM anymore, instead I’ll be referring to Windows 10 MDM. The main reason for that is change is to align with Microsoft. Also, it simply makes more sense. OMA-DM is the standards based protocol on which the Windows 10 MDM protocol is based. In other words, Windows 10 MDM is not exactly the same as the OMA-DM standards. Technically speaking it’s not wrong to refer to OMA-DM, but it simply makes more sense to refer to Windows 10 MDM.

That being said, this blog post will be different for another reason. This week I’ll try to bring Windows 10 MDM closer to the regular methods, by simply pointing out the existence of the MDM Bridge WMI Provider. This post is all about creating awareness.

MDM Bridge WMI Provider

One of the most heard comments about Windows 10 MDM is related to the lack of knowing what’s happening. Well, I can’t really take that away, maybe the newly introduced logging in 1607 can, but I can show how to see the changes of the Windows 10 MDM configurations.

The MDM Bridge WMI Provider is the bridge to the Windows 10 MDM capabilities. An easy method to see what’s happening is using a WMI Explorer, or something simple as Windows Management Instrumentation Tester (wbemtest). Simply connecting to the root\cimv2\mdm\dmmap namespace is similar to connecting to the MDM Bridge WMI Provider. The classes in this namespace all translate to a configuration service provider (CSP) of Windows 10 MDM. This makes it fairly easy to see what’s happening to the configurations done via Windows 10 MDM.

Below is an example of the MDM_Policy_Result01_Experience02 class, in which the AllowManualMDMUnenrollment instance property was changed during the enrollment of the device. That class and instance property relates to the configuration OMA-URI of ./Vendor/MSFT/Policy/Config/Experience/AllowManualMDMUnenrollment.

Before After
BeforeEnroll AfterEnroll

Knowing this immediately opens up another world. This enables everyone to get information through the MDM Bridge WMI Provider by simply using PowerShell. Looking at the previous example, I can simply use the following PowerShell command, as there is only one instance, to get the information as shown in the table below.

Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" ` -ClassName "MDM_Policy_Result01_Experience02"

Before After
BeforeEnroll_PS AfterEnroll_PS

This also means that the MDM Bridge WMI Provider can be used to trigger configuration changes through Windows 10 MDM. For now, I’ll leave that up to everyone’s imagination.

Important notes

There are a few important notes about the MDM Bridge WMI Provider that should be known and I’ll try to summarize them briefly:

  • Administrative permissions are required to connect with the MDM Bridge WMI Provider. Without those permissions there will be an access denied error when connecting to the MDM Bridge WMI Provider;
  • The local system context is required to view and adjust device settings. This can be achieved by using something like PsExec.exe;
  • Be aware that there is a difference between user settings and device settings. Specific user settings won’t show when connected in the system context and specific device settings won’t show when connected in the user context;
  • Be aware that my example mixed Config and Result properties and nodes. That’s related to the design of the Policy CSP. The Config section handles the configurations requests and the Result section provides a read-only path to the actual configuration.

More information

Fore more information about Windows 10 MDM, the Windows 10 CSP and the MDM Bridge WMI Provider, please refer to:

Share

New tool: Remote Mobile Device Manager

This blog post will be about a new tool, written in PowerShell, to remotely manage mobile devices. This tool is based on the ConfigMgr SDK and contains all the available options for remotely managing mobile devices. That means it can retire, wipe, lock and pin reset mobile devices. Basically, it’s a version 2.0 of the tool I made a couple of months ago. That tool is limited to the ConfigMgr 2012 R2 functionality, of wipe and retire, and this new tool also contains the ConfigMgr 2012 R2 SP1 functionality, of lock and pin reset.

The use case for this tool is still the same. In most cases the service desk is responsible for helping end-users with their mobile devices. What if the company rather not provides the ConfigMgr console to the service desk? What if the company wants to prevent the service desk from wiping a mobile device? Well, that’s were this tool comes in place. This tool provides the possibility to remotely manage mobile devices without using the ConfigMgr console and it also provides the possibility to prevent the usage of the wipe functionality.

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

Overview

RMDM_Overview_v10Now lets start with a good 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 Mobile Devices button can be used to get the registered (primary) 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 Reset Passcode, the View Passcode State, the Remote Lock, the View Remote Lock State, the Retire and the Wipe buttons will enable, if applicable and if allowed. The Wipe and Reset Passcode functionality are not applicable for Windows (RT) devices. Also, the Wipe functionality needs to be specifically enabled via the AllowWipe switch.

Messages

This tool provides a lot of messages based on the actions performed by the administrative user. Based on the action the following messages can show.

RMDM_UseVerVal_v10The error message Please provide a valid username. will show when no username was specified. Together with this error message, also the error message Please verify the username will show next to the textbox.
RMDM_UseVerExi_v10The error message Please provide an existing username. will show when a wrong, not existing, username was specified. Together with this error message, also the error message Please verify the username will show next to the textbox.
RMDM_UseVerPri_v10The error message Please provide an user with a primary mobile device. will show when the specified username has no (primary) mobile device(s) configured. Together with this error message, also the error message Please verify the username will show next to the textbox.

RMDM_UseVerCon_v10The error message Please verify the connection with the specified site server. will show when something else went wrong. Based on the second part of the error message it can be determined at which stage this happened.

In most cases these error messages will be prevented already because of the check at the startup of the tool. During the startup it will try to get the SiteCode based on the specified SiteServer. When this action fails, the tool won’t start and it will show the error message Unable to connect to the SMS Provider location on <SiteServer>..

RMDM_PinStaInf_No_v10The informational message There is no PINRESET state information available for the mobile device named <Name>. will show when the View Passcode State button is used and no PINRESET state information is available.
RMDM_PinVer_v10The verification message Are you sure that you want to PINRESET the mobile device named <Name>? will show when the Reset Passcode button is used.
RMDM_PinNot_v10The informational message The action to PINRESET the mobile device named <Name> is successful initiated. will show when the action to PINRESET the device is successful initiated.
RMDM_PinStaInf_v10The information message about the PINRESET state information will show when the View Passcode State button is used and PINRESET state information is available.
RMDM_LocStaInf_No_v10The informational message There is no LOCK state information available for the mobile device named <Name>. will show when the View Remote Lock State button is used and no LOCK state information is available
RMDM_LocVer_v10The verification message Are you sure that you want to LOCK the mobile device named <Name>? will show when the Remote Lock button is used.
RMDM_LocNot_v10The informational message The action to LOCK the mobile device named <Name> is successful initiated. will show when the action to LOCK the device is successful initiated.
RMDM_LocStaInf_v10The informational message about the LOCK state information will show when the View Remote Lock State button is used and LOCK state information is available.
RMDM_RetVer_v10The verification message Are you sure that you want to RETIRE the mobile device named <Name>? will show when the Retire button is used.
RMDM_RetNot_v10The informational message The action to RETIRE the mobile device named <Name> is successful initiated. will show when the action to RETIRE the device is successful initiated.
RMDM_WipVer_v10The verification message Are you sure that you want to WIPE the mobile device named <Name>? will show when the Wipe button is used.
RMDM_WipNot_v10The informational message The action to WIPE the mobile device named <Name> is successful initiated. will show when the action to WIPE the device is successful initiated.

Usage

Before this tool can be used, the administrative user, or service account, used to start this tool, requires at least the permissions as described in this post and the permissions to read user device affinities (User Device Affinities > Read). 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 to do something creative with the ConfigMgr 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;
  • AllowWipe: This switch is optional and enables the button to wipe a mobile device.

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

.\Manage-MobileDevice_v10.ps1 -SiteServer CLDSRV02 -AllowWipe

Thanks

A special thanks goes to everybody that volunteered to do some beta testing of this tool. Thank you Nickolaj, John, Jörgen, Stefan, Kim and Tom!

Share

Invoke remote device actions via PowerShell

This will be a short blog post about a the newly introduced WMI class, in the latest service pack, called SMS_DeviceAction. As I’m currently working on a new tool to remotely manage mobile devices, which will be released soon, I noticed that the SMS_DeviceAction class is used to invoke and query the Lock and PinReset actions. What’s even more important is the fact that the SMS_DeviceAction class isn’t documented, yet. In this blog post I’ll post the required information to successfully query the SMS_DeviceAction class and to successfully invoke the methods of the SMS_DeviceAction class.

Methods

The SMS_DeviceAction class contains the method InvokeAction. The InvokeAction method requires the following input parameters.

Parameter Data Type Description
Action String This parameter is required and should contain the name of the Action. That name can be either Lock or PinReset.
ResourceID Unit32 This parameter is required and should contain the Resource ID of the mobile device.
ResourceType Unit32 This parameter is required and should contain the Resource Type of the mobile device. The Resource Type of a mobile device is 5.

Properties

The SMS_DeviceAction class contains the following properties.

Property Data Type Description
Action String This property contains the name of the Action. That name is either Lock or PinReset.
LastUpdateTime String This property contains the time of the latest status change and is stored in the WMI time format.
ResourceID Unit32 This property contains the Resource ID of the mobile device.
ResourceText String This property contains the Response Text of the PinReset action.
SMSID String This property contains the ID of the mobile device.
SourceType Unit32 This property contains the Source Type of the mobile device.
State Unit32 This property contains the state of the action. The state will be 1 for completed and 4 for pending.

Examples

Now lets go through a couple of examples to show the usage of the SMS_DeviceAction class. This first example shows a simple query to get the information of a specific mobile device and the Lock action.

Get-WmiObject -ComputerName $SiteServer ` -NameSpace root/SMS/site_$($SiteCode) -Class SMS_DeviceAction ` -Filter "Action='Lock' and ResourceID='$MobileDeviceId'"

This second example shows an invoke of the Lock action, on a specific mobile device, via the InvokeAction method.

Invoke-WmiMethod -ComputerName $SiteServer ` -Namespace root/SMS/site_$($SiteCode) -Class SMS_DeviceAction ` -Name InvokeAction -ArgumentList ("Lock",$MobileDeviceId,5)

Share

Automagically set the mobile device owner to company

Before I’ll start with this blog post I would like to say thank you to Kim Oppalfens, for his great suggestion to look at WMI Eventing. I didn’t know that it was that versatile and powerful! Thanks Kim!

Scenario

DeviceOwnerThe scenario for this post is actually quite simple and is applicable to an environment with Microsoft Intune integrated with ConfigMgr. By default, the device owner of a mobile device is set to Personal and that’s not always the desired value. A lot of customers still provide their employees with (mobile) devices and want the tooling to reflect that information. This blog post will provide an automagic method to set the mobile device owner to Company, by default. The best thing is that it’s still possible to switch a mobile device to Personal if that’s required. Only newly added mobile devices will be automagically set to Company.

Solution

Now let’s start about the solution for this scenario. Initially I thought that I could easily tackle this scenario via a Status Filter Rule, only to find out that there is no status message generated for the creation of a new mobile device object. That was the moment that I needed advice and I got pointed in to the direction of WMI Eventing. In the rest of this blog post I’ll describe the key parts of the scripts that I used to automatigally set the mobile device owner to Company after it’s enrolled. The complete scripts are available for download in the TechNet Galleries.

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

The action

Before I’ll start with explaining the key parts of the script for using WMI for monitoring and responding to events, I’ll start with a short piece about changing the device owner, similar to this post about changing the device ownership. As mentioned in that post, I can simply use call the WMI method ChangeOwnership, of the SMS_Collection class, by providing the device owner and the resource id. Together that would make the action to change the device owner look like this.

Invoke-WmiMethod -ComputerName $SiteServer ` -Namespace root\SMS\site_$($SiteCode) -Class SMS_Collection ` -Name ChangeOwnership -ArgumentList @($DeviceOwner,$ResourceId) ` -ErrorAction Stop

The event filter

WMI_EventFilterThe first thing that I need to create now is the event filter, as shown in the picture. An event filter is a WMI class that describes which events WMI delivers to a physical consumer. It also describes the conditions under which WMI delivers the events. Let’s start with the latter and start with describing the conditions. To do this I use the following hash table that contains the conditions for the event filter.

$PropertyHash = @{ QueryLanguage = "WQL"; Query = "SELECT * FROM __InstanceCreationEvent WITHIN 5 ` WHERE TargetInstance ISA 'SMS_R_System' AND ` TargetInstance.DeviceOwner = '2'"; Name = "DeviceOwnerFilter"; EventNameSpace="root\sms\site_$($SiteCode)" }

The most important part of the conditions is the query. In this query I select the creation, by using __InstanceCreationEvent, of mobile devices, by using  TargetInstance ISA ‘SMS_R_System’ AND TargetInstance.DeviceOwner = ‘2’, every 5 seconds, by using WITHIN 5. Effectively this query will run twice every 5 seconds and the differences are my results. I can imagine that running this every 5 seconds might be too aggressive, in that case simply adjust this value to any desired number.

Now, to create an event filter, I need to create a new instance of the __EventFilter class. To do this I can use the New-CimInstance cmdlet together with the just defined hash table, like this.

$InstanceFilter = New-CimInstance -Namespace root\subscription ` -ClassName __EventFilter -Property $PropertyHash -ErrorAction Stop

The event consumer

WMI_EventConsumerThe next thing that I need to create is the event consumer, as shown in the picture. An event consumer can be used to perform actions based on events. Each consumer takes a specific action after it receives an event notification. Let’s start with describing the actions for the consumer. To do this I use the following hash table that contains the actions for the event consumer.

$PropertyHash =@{ Name = "DeviceOwnerConsumer"; CommandLineTemplate = "PowerShell.exe ` -File $ScriptPath\Change-Ownership.ps1 -SiteServer $SiteServer` -SiteCode $SiteCode -DeviceOwner 1 ` -ResourceId %TargetInstance.ResourceId%" }

The most important part in the defined action is, of course, the location of the script file that performs the action. Almost as important is to get the resource id of the mobile device, as input for the action script.  Luckily, every instance creation event contains an embedded object called TargetInstance, which, in this case, is a representation of the created SMS_R_System object. That TargetInstance object is what I can use as input in my script, like this %TargetInstance.ResourceId%.

In this case I choose to use a command line event consumer. That means I need to create a new instance of the CommandLineEventConsumer class. To do this I use the New-CimInstance cmdlet, again, together with the just defined hash table, like this.

$InstanceConsumer = New-CimInstance -Namespace root\subscription ` -ClassName CommandLineEventConsumer -Property $PropertyHash ` -ErrorAction Stop

Binding the filter and the consumer

WMI_EventBindingThe last thing that I have to do, is to bind the event filter with the event consumer, as shown in the picture. This will make sure that when an event occurs that matches the specified filter, the action specified by the consumer will occur. To do this I first create the following hash table that contains a reference to the event filter and the event consumer.

$PropertyHash = @{ Filter = [ref]$InstanceFilter; Consumer = [ref]$InstanceConsumer }

Now I need to relate them by creating a new instance of __FilterToConsumerBinding. To do this I use the New-CimInstance cmdlet, one last time, together with the hash table, like this.

$InstanceBinding = New-CimInstance -Namespace root/subscription ` -ClassName __FilterToConsumerBinding -Property $PropertyHash ` -ErrorAction Stop

Result

The result of all of this is an event consumer that will change the device owner of every mobile device that’s found by the event filter. There are multiple way’s to verify that everything is created and working as expected. To check if everything is created in WMI, as scripted, either use PowerShell or simply use a WMI Explorer.

More importantly, to check if the consumer is working as expected, simply check the event viewer. My script to change the device owner writes a 3000 event in the Application log for every successful change and a 3001 event for every failure. Both of them use the SMS Server as source. A good place to check the functionality of the event filter is to look at the SMSProv.log. This log will show a hit, in this case, every 5 seconds as shown in the example below. Every hit will be performed by the SYSTEM account.

Every5Sec

More information

For a lot more information about the basics of WMI Eventing and about how this can be used in combination with scripting, have a look at the following great posts:

Share

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

Share

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.

Share

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)

Share