Merge branch 'main' into patch-8

Author: baardhermansen

autopilot/includes/deregister-autopilot-device.md

@@ -1,6 +1,6 @@
 ---
 ms.topic: include
-ms.date: 06/13/2025
+ms.date: 02/27/2026
 ---
 
 <!-- This file is shared by the following articles:
@@ -16,7 +16,7 @@ Below we describe the steps an admin would go through to deregister a device fro
 
 ### Delete from Intune
 
-Before a device is deregistered from Windows Autopilot, it first has to be deleted from Intune. To delete an Windows Autopilot device from Intune:
+Before a device is deregistered from Windows Autopilot, it first has to be deleted from Intune. To delete a Windows Autopilot device from Intune:
 
 1. Sign into the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
 
@@ -34,7 +34,7 @@ Before a device is deregistered from Windows Autopilot, it first has to be delet
 
 ### Deregister from Windows Autopilot using Intune
 
-Once the device is deleted from Intune, it can then be deregistered from Windows Autopilot. To deregister a device from Windows Autopilot:
+Once the device is deleted from Intune, it can then be deregistered from Windows Autopilot. This process includes required cleanup steps in Intune and Microsoft Entra ID to prevent orphaned or unrecoverable devices. To deregister a device from Windows Autopilot:
 
 1. Make sure the device is deleted from Intune as described in the [Delete from Intune](#delete-from-intune) section.
 
@@ -67,11 +67,24 @@ Once the device is deleted from Intune, it can then be deregistered from Windows
 
 > [!IMPORTANT]
 >
-> - For Microsoft Entra join devices, no additional steps are necessary to remove the device from Intune and Windows Autopilot. Unneeded steps include manually deleting the device from Microsoft Entra ID. Manually deleting the device from Microsoft Entra ID might cause unexpected problems, issues, and behavior. If needed, the device will be automatically removed from Microsoft Entra ID after these steps are followed.
+> - For Microsoft Entra joined devices, no additional steps are required after deregistering the device from Windows Autopilot using Intune. Avoid manually deleting the device from Microsoft Entra ID, as this can cause unexpected issues.  
 >
-> - For Microsoft Entra hybrid join devices, delete the computer object from the on-premises Active Directory Domain Services (AD DS) environment. Deleting the computer object from the on-premises AD DS ensures that the computer object isn't resynced back to Microsoft Entra ID. After the computer object is deleted from the on-premises AD DS environment, no additional steps are necessary to remove the device from Intune and Windows Autopilot. Unneeded steps include manually deleting the device from Microsoft Entra ID. Manually deleting the device from Microsoft Entra ID might cause unexpected problems, issues, and behavior. If needed, the device will be automatically removed from Microsoft Entra ID after these steps are followed.
+> - For Microsoft Entra hybrid joined devices, delete the computer object from the on‑premises Active Directory Domain Services (AD DS) environment to prevent it from being resynced to Microsoft Entra ID. After this step, no additional actions are required in Intune or Windows Autopilot. Avoid manually deleting the device from Microsoft Entra ID.
+>   
+> For information about what to expect in Microsoft Entra ID after deregistration, see [What happens to the Microsoft Entra device object after deregistration?](#what-happens-to-the-microsoft-entra-device-object-after-deregistration) 
 
-The above steps deregister the device from Windows Autopilot, unenroll the device from Intune, and disjoin the device from Microsoft Entra ID. It might appear that only deregistering the device from Windows Autopilot is needed. However, there are barriers in Intune that require all the above steps to avoid problems with lost or unrecoverable devices. To prevent the possibility of orphaned devices in the Windows Autopilot database, Intune, or Microsoft Entra ID, it's best to complete all the steps. If a device gets into an unrecoverable state, contact the appropriate [Microsoft support alias](../autopilot-support.md) for assistance.
+This process ensures that related records in Windows Autopilot, Intune, and Microsoft Entra ID are handled correctly. Skipping steps or removing records out of order can result in orphaned records or unrecoverable devices. If a device goes into an unrecoverable state, contact the appropriate [Microsoft support alias](../autopilot-support.md) for assistance.  
+
+### What happens to the Microsoft Entra device object after deregistration?  
+
+Deregistering a device from Windows Autopilot removes the device’s registration from the Windows Autopilot deployment service. However, this action doesn’t always remove the corresponding Microsoft Entra device object.   
+
+What happens in Microsoft Entra ID depends on the device’s join and enrollment state:  
+
+- **Devices that aren’t currently enrolled in MDM:** Removing the Windows Autopilot registration can also result in the associated Microsoft Entra device object being removed.  
+- **Devices that are or were enrolled in MDM:** Removing the Windows Autopilot registration doesn’t automatically delete the Microsoft Entra device object. In this case, the device can remain in Microsoft Entra ID even though it’s no longer registered with Windows Autopilot.
+
+Because this behavior varies, avoid manually deleting the device from Microsoft Entra ID unless a specific scenario requires it. The Windows Autopilot deployment process relies on the Microsoft Entra device object, and deleting it can cause enrollment failures.  
 
 ### Deregister from Windows Autopilot using Microsoft 365 admin center
 

intune/advanced-analytics/device-query-multiple-devices.md

@@ -1,7 +1,7 @@
 ---
 title: Device Query for Multiple Devices in Advanced Analytics
 description: Use device query for multiple devices in Microsoft Intune to run Kusto Query Language (KQL) queries, analyze device inventory, and gain cross-platform insights.
-ms.date: 12/01/2025
+ms.date: 01/23/2026
 ms.topic: how-to
 ---
 
@@ -70,7 +70,7 @@ Additional prerequisites for device query for multiple devices:
 1. Input a query in the query box using the supported properties and supported operators.
 1. Select **Run** to execute the query.
 1. Results are displayed in the **Results** tab area.
-   - If you only want to run part of the query, or if you have multiple queries in the query window and only want to run one, you can highlight the query you want to run and select **Run**. Only that query is run.
+   - To run part of a query or a single query when multiple queries are in the window, highlight the query you want to run and select **Run**. Only the highlighted query runs.
 
 You can expand the view on the left side to see all the properties that can be queried. Select any one to populate into your query. You can select and drag the edges of both the left side and the query window to make any adjustments.
 
@@ -87,50 +87,66 @@ To help you get started, some sample queries are provided in this section. To ac
 
 ### Top processors by Core Count
 
-This query lists the top five CPUs sorted by core count.
+This query shows the top five CPUs by core count.
 
 ```kusto
-Cpu| project Device, ProcessorId, Model, Architecture, CpuStatus, ProcessorType, CoreCount, LogicalProcessorCount, Manufacturer, AddressWidth| order by CoreCount asc| take 5
+Cpu
+| project Device, ProcessorId, Model, Architecture, CpuStatus, ProcessorType, CoreCount, LogicalProcessorCount, Manufacturer, AddressWidth
+| order by CoreCount asc
+| take 5
 ```
 
 ### Devices with unprotected disks
 
 This query lists devices with unencrypted disks.
 
 ```kusto
-EncryptableVolume| where ProtectionStatus != "PROTECTED"| join LogicalDrive
+EncryptableVolume
+| where ProtectionStatus != "PROTECTED"
+| join LogicalDrive on Device
 ```
 
 ### Arm64 devices
 
 This query lists all devices with an ARM64 processor.
 
 ```kusto
-Cpu | where Architecture == "ARM64"
+Cpu
+| where Architecture == "ARM64"
 ```
 
 ### Device count by processor architecture
 
 This query provides a summary of devices by CPU architecture.
 
 ```kusto
-Cpu| summarize DeviceCount=count() by Architecture
+Cpu
+| summarize DeviceCount = count() by Architecture
 ```
 
 ### Top devices by battery capacity
 
 This query lists the top 10 devices by fully charged battery capacity.
 
 ```kusto
-Battery| project Device, InstanceName, Manufacturer, Model, SerialNumber, CycleCount, DesignedCapacity, FullChargedCapacity, FullChargedCapacityPercent = (FullChargedCapacity*100)/DesignedCapacity| top 10 by FullChargedCapacityPercent asc
+Battery
+| project Device, InstanceName, Manufacturer, Model, SerialNumber, CycleCount,
+          DesignedCapacity,
+          FullChargedCapacity,
+          FullChargedCapacityPercent = (FullChargedCapacity * 100) / DesignedCapacity
+| top 10 by FullChargedCapacityPercent asc
 ```
 
 ### Devices memory information
 
 This query lists devices with physical and virtual memory in GB.
 
 ```kusto
-MemoryInfo| project Device, PhysicalMemoryGB = PhysicalMemoryTotalBytes/(1000*1000*1000), VirtualMemoryGB = VirtualMemoryTotalBytes/(1000*1000*1000) | order by PhysicalMemoryGB asc
+MemoryInfo
+| project Device,
+          PhysicalMemoryGB = PhysicalMemoryTotalBytes/(1000*1000*1000),
+          VirtualMemoryGB = VirtualMemoryTotalBytes/(1000*1000*1000)
+| order by PhysicalMemoryGB asc
 ```
 
 ### Device count by OS version
@@ -165,17 +181,20 @@ Device query supports only a subset of the operators supported in the Kusto Quer
 
 Table operators can be used to filter, summarize, and transform data streams. The following operators are supported:
 
-| Table Operators | Description |
+| Table operator | Description |
 | --- | --- |
 | `count` | Returns a table with a single record containing the number of records. |
-| `distinct` | Produces a table with the distinct combination of the provided columns of the input table. |
-| `join` | Merge the rows of two tables to form a new table by matching row for the same device. Only the join types of `innerunique`, `Leftouter`, `Fullouter`, `Rightouter`, and inner are supported. If you type in a join type other than the ones supported, they're ignored. Join statements support `on` syntax if joined with `Device` or `Device.Deviceid`. Common syntax for join is LeftEntity \| join [hints] (RightEntity) on Conditions. For more info, see [Join](/kusto/query/join-operator) documentation.|
-| `order by` | Sort the rows of the input table into order by one or more columns. |
-| `project` | Select the columns to include, rename or drop, and insert new computed columns. |
-| `take` | Return up to the specified number of rows. |
+| `distinct` | Produces a table with distinct combinations of the provided columns from the input table. |
+| `join` | Merges rows from two tables to form a new table based on matching values in the specified columns. The following join types are supported:<br>- `innerunique` (default)<br>- `inner`<br>- `leftouter`<br>- `rightouter`<br>- `fullouter`<br>- `leftsemi`<br>- `rightsemi`<br>- `leftanti`<br>- `rightanti`<br><br>Join statements support an optional `on` clause. In device query scenarios, you typically use `on Device` when joining tables that contain a `Device` entity. Common syntax for `join` is: `LeftTable | join [hints] (RightTable) on Conditions`.<br><br> **Important:** Joins that use `on Device.DeviceID` are no longer supported. Queries that currently specify `on Device.DeviceId` should switch to using `on Device`, or omit the `on` clause when joining on the `Device` entity.<br><br>For more information, see [Join operator](/kusto/query/join-operator). |
+| `order by` | Sorts the rows of the input table by one or more columns. |
+| `project` | Selects columns to include, rename, or drop, and inserts new computed columns. |
+| `take` | Returns up to the specified number of rows. |
 | `top` | Returns the first N records sorted by the specified columns. |
-| `where` | Filter a table to the subset of rows that satisfy a predicate. |
-| `summarize` | produces a table that aggregates the contents of the input table. |
+| `where` | Filters a table to the subset of rows that satisfy a predicate. |
+| `summarize` | Produces a table that aggregates the contents of the input table. |
+
+> [!NOTE]
+> `Device` is an entity-type and can't be used directly in operators that require scalar values (such as `distinct`, `summarize`, and `order by`). For these operators, use a specific scalar property of the device (for example, `Device.SerialNumber` or `Device.OSVersion`).
 
 ### Scalar operators
 
@@ -297,60 +316,70 @@ Device query for multiple devices supports a linked entity. The Device entity ca
 | `LastSeenDateTime` | String | The date and time that the device last connected to Intune. |
 | `Ownership` | String | Ownership of the device. |
 
-Device entity allows you to reference the device associated with a resulting row without needing to write a separate query to join them together. Essentially, it acts as an automatic join to include device information in your query results.
 
-The device entity is automatically joined to every other entity for ease of use. The device entity is the first column in they query results, unless the query updates the return type through use of operators like a `project`, `summarize`, or `distinct`.
+The `Device` entity allows you to reference device information associated with each resulting row without needing to explicitly join to a device table.
+
+By default, query results include a `Device` entity column that provides device context for each row. Operators such as `project`, `summarize`, or `distinct` can change which columns are returned.
+
+`Device` represents the device associated with the resulting row and can be referenced directly as an entity-type column. When displayed in query results, the `Device` entity is shown using a friendly identifier, such as the device name, to make it easier to identify devices.
 
-Using Device by itself in a query parses to `Device.DeviceId`. In the Device column returned by default, the DeviceId is translated to DeviceName to allow for easier identification of devices.
-The device entity and its properties can also be referenced in queries by referencing Device.[Insert property].
+You can reference properties of the `Device` entity in queries using `Device.[Property]`.
 
-The following query returns all the DiskDrive information for all devices with serial number 123:
+The following query returns all `DiskDrive` information for devices with a specific serial number:
 
 ```kusto
 DiskDrive
-where Device.SerialNumber = 123
+| where Device.SerialNumber == "123"
 ```
 
-The following query projects the Device ID and Manufacturer properties of the entity DiskDrive:
+
+The following query projects the `Device` entity and the `Manufacturer` property from the `DiskDrive` entity:
 
 ```kusto
-DiskDrive | project Device.DeviceId, Manufacturer
-```
 
-Although the Device entity that is shown as the first column by default appears as device names using Device by itself in a query parses to Device.DeviceId.
-This query returns results ordered by the DeviceID, not by DeviceName:
+DiskDrive
+| project Device, Manufacturer
 
-```kusto
-MemoryInfo | order by Device
 ```
 
-Similarly, this query returns no results unless the device ID is Desktop123. It doesn't query on device name:
+By default, query results include a `Device` entity that represents the device associated with each row. The `Device` entity is an entity-type column and does not implicitly resolve to a specific scalar property.
+When sorting or filtering results, explicitly reference the device property you want to use. For example, this query orders results by device name:
 
 ```kusto
-Cpu | where Device == "Desktop123"
+
+MemoryInfo
+| order by Device.DeviceName
+
 ```
 
-Use the following example to query on device name:
+Similarly, to filter by device name, reference the `DeviceName` property directly:
 
 ```kusto
-Cpu | where Device.DeviceName == 'Desktop123"
+
+Cpu
+| where Device.DeviceName == "Desktop123"
+
 ```
 
 ## Known limitations
 
-- Using the Device entity in aggregation functions shows a red underline. However, the query can  still run and can return results as expected. For example, the following query shows a red underline under **Device** but still runs:
+
+- Using entity-type columns such as `Device` in aggregation functions can show a red underline in the editor because aggregation functions require scalar values. To avoid this, reference a specific scalar property of the entity. For example:
 
   ```kusto
-  Cpu | summarize max(Device) by Manufacturer.
+  Cpu
+  | summarize max(CpuUsage) by Device.Manufacturer
   ```
 
-- Queries with a join operator, $left and $right parameters show a red underline under $left and $right. However, the query can still run and returns results as expected.
-- A single query can contain a maximum of three join operators. Queries with more joins fail.
-- A max of ~50,000 records are returned for a query.
-- A maximum of 10 queries can be submitted per minute. Any other queries within the same minute fail.
+- Queries that use the `join` operator with `$left` and `$right` parameters may show a red underline in the editor. However, the query can still run and return results as expected.
+- A single query can contain a maximum of three `join` operators. Queries with more joins fail.
+- A maximum of ~50,000 records are returned for a query.
+- A maximum of 10 queries can be submitted per minute. Additional queries within the same minute fail.
 - A maximum of 1,000 queries can be submitted per month.
-- Negative values for the amounts parameter of the datetime_add() function aren't supported.
-- Referencing a variable that has been summarized by an aggregation function throws an error. Explicitly naming the variable allows the query to succeed again. For example, the query Device | summarize dcount(DeviceId) | order by dcount_DeviceId will fail. Device | summarize DCountDeviceIdRename=dcount(DeviceId) | order by DCountDeviceIdRename succeeds.
+- Negative values for the `amount` parameter of the `datetime_add()` function aren't supported.
+- Referencing a variable that was generated by an aggregation function without explicitly naming it can cause a query to fail. Explicitly naming the variable allows the query to succeed. For example:
+  - The query `Device | summarize dcount(DeviceId) | order by dcount_DeviceId` fails.
+  - The query `Device | summarize DCountDeviceIdRename = dcount(DeviceId) | order by DCountDeviceIdRename` succeeds.
 
 <!--links-->
 

intune/configmgr/cloud-attach/use-intune-rbac.md

@@ -30,7 +30,7 @@ The three high-level steps to configure Intune as the role-based access control
 
 ## Limitations
 
-- Currently [scoping](../../intune-service/fundamentals/scope-tags.md) isn't supported when using only Intune role-based access control for for displaying and taking actions on tenant-attached devices from the Microsoft Intune admin center.
+- Currently [scoping](../../intune-service/fundamentals/scope-tags.md) isn't supported when using only Intune role-based access control for displaying and taking actions on tenant-attached devices from the Microsoft Intune admin center.
 - Currently, the [**Software updates** page](../tenant-attach/software-updates.md) isn't available for cloud-only users when using the early update ring of Configuration Manager version 2207.  <!--15287859-->
 
 ## <a name="bkmk_disable-configmgr"></a> Disable enforcement of Configuration Manager role-based access control for cloud-attached clients