Using bulk actions for renaming Windows devices

A few months ago, I did a blog post about the different ways of renaming Windows 10 devices. This week is a follow-up on that post, as it will also be about renaming Windows devices. This time it’s about using the recently introduced functionality to perform Bulk actions on devices. Those Bulk actions include the action to rename Windows 10 devices in bulk. That Bulk action is also available as a single action on a device and is currently not available for hybrid Azure Active Directory joined devices, nor available for co-managed devices. In this post I’ll show how to perform this action by using the Microsoft Endpoint Manager admin center, followed by using the Microsoft Graph Explorer. I’ll end this post by showing an example using PowerShell and the Microsoft Graph API.

Rename Windows devices using the Microsoft Endpoint Manager admin center

Now let’s start by having a look at using a Bulk action for renaming a Windows 10 device by using the Microsoft Endpoint Manager admin center. This method is – in my opinion – always the first step towards automating an action. The following 9 steps walk through the Bulk action for renaming Windows 10 devices. While performing these steps make sure to use Microsoft Edge and to turn on the Developer tools (Ctrl + Shift + I), as that will help with identifying the Graph request that should be used for automation purposes.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices All devices > Bulk Device Actions to open the Bulk device actions blade
  2. On the Basics page, provide the following information (see Figure 1) and click Next
  • OS: Select Windows
  • Device action: Select Rename
  • Enter new name: Provide a new naming conform the provided guidelines
  1. On the Devices page, click Select devices to include to select the devices to rename and click Next
  2. On the Review + create page, review the provided information and click Create

Verify request information using the Microsoft Graph Explorer

When following the Bulk action via the Network trace in the Developer tools, it shows the executeAction action that will perform the actual action. The most relevant parts of that action are shown below, as Figure 2 shows the request URL and Figure 3 shows the request payload. That combination is needed for automation purposes.

A closer look shows that the executeAction action is used as the request location to post the request.

https://graph.microsoft.com/beta/deviceManagement/managedDevices/executeAction

That request requires a request body to supply a JSON representation of the different properties. A closer look at that JSON payload shows the properties action, actionName, deviceIds, deviceName, platform, realAction and restartNow. The good thing is that these properties are pretty self explanatory, especially in combination with the action that was performed to retrieve this information. It’s good to specifically point out that the deviceIds property is an array that can currently contain up to a 100 devices and that the deviceName property should contain the naming format for the different applicable devices.

{
	action: "setDeviceName",
	actionName: "setDeviceName",
	deviceIds: ["d8cd02c1-9443-4ad0-8681-937c2e6d7607"],
	deviceName: "CLDCLN%RAND:2%",
	platform: "windows",
	realAction: "setDeviceName",
	restartNow: false
}

The next step toward automating this Bulk action is by trying the correct request URL and request payload via the Microsoft Graph Explorer, as that’s an easy method to try Graph API requests. Simply sign-in, change the action to POST, add the request URL, add the request payload (as shown in Figure 4) and click Run Query.

Note: The application requires the scope DeviceManagementManagedDevices.PrivilegedOperations.All.

Running the query will return a bulkManagedDeviceActionResult result type. That result type provides a JSON representation of the status properties. Those status properties include successfulDeviceIds, failedDeviceIds, notFoundDeviceIds and notSupportedDeviceIds. The good thing is that these properties are also pretty self explanatory. A simple method to verify this behavior is by throwing in some random deviceIds. Those deviceIds should end up as part of the notFoundDeviceIds.

{
    "@odata.context": "https://graph.microsoft.com/beta/$metadata#microsoft.graph.bulkManagedDeviceActionResult",
    "successfulDeviceIds": [
        "d8cd02c1-9443-4ad0-8681-937c2e6d7607"
    ],
    "failedDeviceIds": [],
    "notFoundDeviceIds": [],
    "notSupportedDeviceIds": []
}

Rename Windows devices using PowerShell and the Microsoft Graph API

After verifying the request URL and the request payload, the last step toward automating this Bulk action is putting it all together in a PowerShell script. I’m going to provide a really simple example that would still require administrator interaction, but does show how it can be achieved. That example is shown below and basically performs the following actions:

  • Install the PowerShell SDK for Microsoft Intune Graph API (if it’s not installed).
  • Connect with the Graph API, which will prompt the administrator for credentials.
  • Set the required variables for the request URL and the request payload.
  • Invoke the Graph API request with the configured variables.
#Install PowerShell SDK for Microsoft Intune Graph API
If ((Get-Module Microsoft.Graph.Intune) -eq $null) {
    Install-Module -Name Microsoft.Graph.Intune
}

#Connect to Microsoft Graph
$ConnectGraph = Connect-MSGraph

#Set the request URL
$URL = "https://graph.microsoft.com/beta/deviceManagement/managedDevices/executeAction"

#Set the JSON payload
$JSONPayload = @"
{
	action: "setDeviceName",
	actionName: "setDeviceName",
	deviceIds: ["d8cd02c1-9443-4ad0-8681-937c2e6d7607"],
	deviceName: "CLDCLN%RAND:2%",
	platform: "windows",
	realAction: "setDeviceName",
	restartNow: false
}
"@

#Invoke the Microsoft Graph request
Try {        
    Invoke-MSGraphRequest -HttpMethod POST -Url $URL -Content $JSONPayload -Verbose -ErrorAction Stop
}
Catch {
    Write-Output "Failed to rename the Windows devices"
} 

When the PowerShell script was successfully executed it will also return the bulkManagedDeviceActionResult result type, as shown in Figure 5. Simple improvements to this PowerShell script would be to remove the administrator interaction, add the deviceIds to a variable and query for the required devices.

More information

For more information about renaming Windows devices and , refer to the following articles:

Using policy sets to group objects

This week is all about Policy sets in Microsoft Intune. Policy sets are introduced a few months ago and enable administrators to group management objects that need to be identified and assigned as a single object. That can help with simplifying the administration of the environment. A Policy sets can be a group of almost all different object that are available within Microsoft Intune. That includes objects for different platforms within the same Policy sets. This enables an administrator to use Policy sets for a lot of different use case, from creating a standard for a specific user type to creating a standard set of apps for all users. In this post I’ll walk through the configuration steps and through the different steps I’ll describe the available options and challenges. I’ll end this post with some notes about the assignment of a Policy set.

Creating policy sets

Now let’s have a closer looking at Policy sets by walking through the configuration. The following 9 steps walk through the creation of a Policy set and the different options.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices Policy sets to open the Policy sets blade
  2. On the Policy sets blade, select Policy sets and click Create to open the Create a policy set wizard
  3. On the Basics page, provide the following information (see Figure 1) and click Next: Application management
  • Policy set name: Provide a valid name for the Policy set
  • Description: (Optional) Provide a description of the Policy set
  1. On the Application management page, provide the following information (see Figure 2) and click Next: Device management
  • Apps: Click Select apps to add apps to the Policy set. That can be an iOS/iPadOS store app, an iOS/iPadOS line-of-business app, a Managed iOS/iPadOS line-of-business app, an Android store app, an Android line-of-business app, a Managed Android line-of-business app, an Office 365 ProPlus Suite (Windows 10), a Web link, a Built-in iOS/iPadOS app, or a Built-in Android app. That also means that a Windows app (Win32) is currently not supported. After adding an app to the Policy set, the assignment type can also be configured.
  • App configuration policies: Click Select app configuration policies to add app configuration policies to the Policy set.
  • App protection policies: Click Select app protection policies to add app protection policies to the Policy set. That can be an APP targeted at managed Windows devices, an APP targeted at managed iOS/iPadOSOS devices, an APP targeted at managed Android devices, an APP targeted at unmanaged iOS/iPadOSOS devices, or an APP targeted at unmanaged Android devices. That also means that APP targeted at unmanaged Windows devices are not supported.
  1. On the Device management page, provide the following information (see Figure 3) and click Next: Device enrollment
  • Device configuration policies: Click Select device configuration policies to add device configuration policies to the Policy set.
  • Device compliance policies: Click Select device compliance policies to add device compliance policies to the Policy set. Only the Android Enterprise device owner type policies are not available.
  1. On the Device enrollment page, provide the following information (see Figure 4) and click Next: Scope tags
  • Device type restrictions: Click Select device type restrictions to add custom device type restrictions to the Policy set.
  • Windows autopilot deployment profiles: Click Select Windows autopilot deployment profiles to add Windows autopilot deployment profiles to the Policy set.
  • Enrollment status pages: Click Select enrollment status page profiles to add custom enrollment status page profiles to the Policy set.
  1. On the Scope tags page, provide the following information (see Figure 5) and click Next: Assignments
  • Scope tags: Click Select scope tags to add custom scope tags to the Policy set.
  1. On the Assignments page, provide the following information (see Figure 6) and click Next: Review + create
  • Included groups: Click Select groups to include to include groups to the assignment of the Policy set.
  • Excluded groups: Click Select groups to exclude to exclude groups from the assignment of the Policy set
  1. On the Review + create page, verify the following information and click Create

After going through the configuration of a Policy set it’s good to note that security baselines are not part of a Policy set configuration. The guided scenario Try out a cloud-managed PC also creates a policy set to group the different objects that are created during the guided scenario and that are supported as being a part of the guided scenario. That scenario also creates a security baseline assignment that is not part of the created Policy set. Guided scenarios are available on the Home page of the Microsoft Endpoint Manager admin center.

For automation purposes, it might be better to know how to automate the device type restriction configuration. That can be achieved by using the policySet object in the Graph API.

https://graph.microsoft.com/beta/deviceAppManagement/policySets

Assignment notes

Let’s end this post with some notes about the assignment of a Policy set. The following should be kept in mind when creating the assignment for the Policy set.

  • The different non-Windows app protection policies (APP) do not support an assignment via a Policy set. In that case the group will be added as a direct assignment. Those assignments will not be deleted when the assignment of the Policy set is removed.
  • The different APPs do not support an assignment to All users or All devices
  • A Windows autopilot deployment profile does not support an assignment to All users
  • An Enrollment status page profile does not support the assignment of virtual groups (All users, All devices or All user & All devices)
  • An Device type restriction profile does not support the assignment of virtual groups (All users, All devices or All user & All devices)

When the assignment of the Policy set is created it will show as a specific assignment with the different objects that are part of the Policy set (as shown in Figure 8).

More information

For more information about using policy sets for managing groups of objects in Microsoft Intune, refer to the documentation about Use policy sets to group collections of management objects.

Block Android device enrollment for specific device manufacturer

This week is all about restricting the enrollment of Android devices. More specifically, about a very recently introduced feature which is the ability to block Android device enrollment based on the manufacturer of the device. That enables the organization to prevent Android devices of specific manufacturers from enrolling in Microsoft Intune. That can be useful when the organization has a specific policy for allowed device manufacturers. In this post I’ll walk through the configuration steps, followed with the end-user experience.

Starting with this post, I’ll provide both the configuration steps via the Microsoft Endpoint Manager admin center portal and the configuration location in the Graph API (including the related JSON-snippet) as part of the configuration steps.

Configuration steps

Now let’s start by having a look at the configuration steps. These configurations can be achieved by either creating custom device type restrictions or by editting the existing default device type restriction. In the following example I’ll walk through these steps by adjusting the default device type restrictions. The following steps show how to add a device manufacturer to a list of blocked manufacturers.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > Enroll devices > Enrollment restrictions to open the Enroll devices – Enrollment restrictions blade
  2. On the Enroll devices – Enrollment restrictions blade, select the Default device type restriction and navigate to Properties to open the All Users – Properties blade
  3. On the All Users – Properties blade, navigate to the Platform settings section and click Edit to open the Platform settings page on the Edit restriction blade
  4. On the Platform settings page, provide the manufacturers to block in the Device manufacturer field (see example below) and click Review + save to continue to the Review + save page

Note: Use a comma-separated list when adding multiple manufacturers.

  1. On the Review + save page, click Save

For automation purposes, it might be better to know how to automate the device type restriction configuration. That can be achieved by using the deviceEnrollmentConfigurations object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/deviceEnrollmentConfigurations

However, keep in mind that the required properties are currently only available in the BETA version of the API. Below is an example snippet of a JSON that contains the Android Enterprise configuration with the blocked manufactures configuration, similar to the configuration via the UI.

"androidForWorkRestriction": {
    "platformBlocked": false,
    "personalDeviceEnrollmentBlocked": false,
    "osMinimumVersion": null,
    "osMaximumVersion": null,
    "blockedManufacturers": [
        "Samsung"
    ]
}

End-user experience

Now let’s end this post by having a look at the end-user experience. I’ll do that by showing the behavior on a personally-owned Android device that should enroll by using Android Enterprise work profiles to manage corporate data and apps. By default, enrollment of this type of personally-owned devices is enabled. That can be limited by using the enrollment restrictions, as shown in this post, or by simply blocking personally-owned devices.

In this scenario, I’m allowing the enrollment of personally-owned and company-owned Android devices, but I’m blocking any enrollment of Android devices from a specific device manufacturer.

When the end-user downloaded and installed the Company Portal app and started the enrollment process, at some point during the enrollment process the end-user will be blocked. While being blocked, the end-user will receive the message “Couldn’t add your device“. That message, of which an example is shown on the right, includes a clear explanation of why the device couldn’t be added. In my example the end-user is being told that the company needs the end-user to use an Android device manufacturer other then samsung.

Note: Keep in mind that the only reason that I’m using Samsung as an example in this post, is that I’ve got test Android devices of that device manufacturer. I don’t have any reasons that would actually require me to block the enrollment of Android devices from that device manufacturer.

More information

For more information about blocking Android device enrollment for specific device manufacturers, refer to the following docs: