Merge branch 'main' of https://github.com/microsoftdocs/memdocs-pr into ebyignite

Author: dougeby

.openpublishing.redirection.json

@@ -1216,6 +1216,11 @@
             "source_path": "memdocs/analytics/productivity-score.md",
             "redirect_url": "/mem/analytics/adoption-score",
             "redirect_document_id": false
-        }        
+        },
+        {
+            "source_path": "memdocs/intune/fundamentals/multi-admin-approval.md",
+            "redirect_url": "/mem/intune/fundamentals/whats-new",
+            "redirect_document_id": false
+        }       
     ]
 }

README.md

@@ -15,7 +15,7 @@ We **want and encourage contributions** from our community (users, customers, pa
 
 * **Use your browser**: There are two options:
 
-    **Option 1: Edit directly from Microsoft Docs**
+    **Option 1: Edit directly from Microsoft Learn**
 
     1. Browse to the [InTune](/mem/intune) article you want to edit.
     2. Select **Edit** (top right). This shows the markdown file in the GitHub repository.

memdocs/analytics/restart-frequency.md

@@ -46,21 +46,21 @@ The difference between **Shutdown (no update)** and **Restart (no update)** is t
 
 ## Device performance tab
 
-In the device performance tab, two default columns have been added so you can review the total number of restarts and the number of Stop errors (blue screen errors) each device had in the last 14 days. Sort by these columns to find problematic devices. You can also use this tab to review the total number of devices that have sent restart records. For example, the screenshot below has 31 records, meaning 31 devices have sent restart data.
+In the device performance tab, two default columns have been added so you can review the total number of restarts and the number of Stop errors (blue screen errors) each device had in the last 30 days. Sort by these columns to find problematic devices. You can also use this tab to review the total number of devices that have sent restart records. For example, the screenshot below has 31 records, meaning 31 devices have sent restart data.
 
 ## Model performance tab
 
-In the model performance tab, two default columns have been added so you can review both the average number of restarts and the average number of Stop errors (blue screen errors) per model over the last 14 days. Sort by these columns to find problematic device models. Only models with at least 10 devices are shown to ensure the averages are done across enough devices to be meaningful.
+In the model performance tab, two default columns have been added so you can review both the average number of restarts and the average number of Stop errors (blue screen errors) per model over the last 30 days. Sort by these columns to find problematic device models. Only models with at least 10 devices are shown to ensure the averages are done across enough devices to be meaningful.
 
 ## Restart frequency tab
 
-The new restart frequency tab shows aggregates of restart frequency counts for each of the [restart categories](#restart-categories) over the last 14 days. For each restart category, the following information is displayed:
+The new restart frequency tab shows aggregates of restart frequency counts for each of the [restart categories](#restart-categories) over the last 30 days. For each restart category, the following information is displayed:
 
 - Number of devices that have had at least one restart in that category
 - The average number of restarts per device across all devices, to understand the total impact.
   - This average is all devices, not just the ones that had at least one restart in the category.
 
-The trend chart indicates how the rolling 14-day average changes over time. If there is a regression you'll be able to see it and identify when it started. Clicking through the metrics table will take you to the [**Device performance** tab](#device-performance-tab), sorted by number of restarts, so you can quickly identify the devices with the most restarts.
+The trend chart indicates how the rolling 30-day average changes over time. If there is a regression you'll be able to see it and identify when it started. Clicking through the metrics table will take you to the [**Device performance** tab](#device-performance-tab), sorted by number of restarts, so you can quickly identify the devices with the most restarts.
 
 :::image type="content" source="media/restart-frequency-tab.png" alt-text="Restart frequency tab under Startup Performance" lightbox="media/restart-frequency-tab.png":::
 
@@ -76,13 +76,13 @@ The **OS restart history** table has the following information:
 
 :::image type="content" source="media/device-page-os-restart-history.png" alt-text="OS restart history under the Device page" lightbox="media/device-page-os-restart-history.png":::
 
-The **OS restart history** table is truncated to the 10 most recent restarts that occurred in the last 2 months. The table is low latency, so new restarts typically show up here before they appear in the daily aggregates shown in the **Device performance** tab.
+The **OS restart history** table is truncated to the 10 most recent restarts that occurred in the last 30 days. The table is low latency, so new restarts typically show up here before they appear in the daily aggregates shown in the **Device performance** tab.
 
 ## Known issues
 
 - The count of restarts in a device's restart history in the [**Devices page**](#devices-page) may not match the count shown in the **Device performance** tab. This is by design. The differences are: 
-   - The aggregates in the [**Device performance** tab](#device-performance-tab) are computed daily to show counts for the last 14 days
-	- The restart history in the [**Devices page**](#devices-page) is truncated to the 10 most recent restarts and goes back up to the last 2 months. This page also has low latency, so new restarts will typically show up here before they make their way into the daily aggregates shown in the **Device performance** tab. The [**Device performance** tab](#device-performance-tab) doesn't have that truncation and goes back for the last 14 days.
+   - The aggregates in the [**Device performance** tab](#device-performance-tab) are computed daily to show counts for the last 30 days
+   - The restart history in the [**Devices page**](#devices-page) is truncated to the 10 most recent restarts
 
 - Currently, there isn't an aggregation of Stop errors (blue screen errors) by *driver* or *failure bucket ID*.
 

memdocs/autopilot/autopilot-mbr.md

@@ -1,18 +1,14 @@
 ---
 title: Windows Autopilot motherboard replacement
-description: Windows Autopilot deployment Motherboard Replacement (MBR) scenarios
-keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
-ms.prod: w10
-ms.mktglfcycl: deploy
+description: Understand how Windows Autopilot deployments function when you replace the motherboard on a device.
+ms.prod: windows-client
+ms.technology: itpro-deploy
 ms.localizationpriority: medium
-ms.sitesec: library
-ms.pagetype: deploy
-audience: itpro
 author: aczechowski
 ms.author: aaroncz
 ms.reviewer: jubaptis
 manager: dougeby
-ms.date: 10/10/2021
+ms.date: 09/23/2022
 ms.collection: M365-modern-desktop
 ms.topic: how-to
 ---
@@ -24,17 +20,17 @@ ms.topic: how-to
 - Windows 11
 - Windows 10
 
-This document offers guidance for Windows Autopilot device repair scenarios that Microsoft partners can use in Motherboard Replacement (MBR) situations, and other servicing scenarios.
+This document offers guidance for Windows Autopilot device repair scenarios that Microsoft partners can use in motherboard replacement (MBR) situations, and other servicing scenarios.
 
 Repairing Autopilot enrolled devices is complex, as it tries to balance OEM requirements with Windows Autopilot requirements. Specifically, OEM requirements include strict uniqueness across motherboards, MAC addresses, and so on. Windows Autopilot requires strict uniqueness at the hardware hash level for each device to enable successful registration. The hardware hash doesn't always accommodate all the OEM hardware component requirements. So these requirements are sometimes at odds, causing issues with some repair scenarios. The hardware hash is also known as the hardware ID.
 
-**Motherboard Replacement (MBR)**
+Starting in the September 2022 release of Intune (2209), if a motherboard is replaced on an Autopilot registered device, and it goes back to the same tenant without an OS reset, Autopilot will attempt to register the new hardware components. In Intune, you'll see the profile status **Fix pending**. If the OEM resets the OS, you need to re-register the device. If the new hardware components are registered, the device status goes back to the assigned profile. If it's not, you'll see the profile status **Attention required**.
 
 If a motherboard replacement is needed on a Windows Autopilot device, the following process is recommended:
 
-1. [Deregister the device](#deregister-the-autopilot-device-from-the-autopilot-program) from Windows Autopilot
+1. If the device isn't going back to the original tenant, [deregister it from Windows Autopilot](#deregister-the-autopilot-device-from-the-autopilot-program). If it's going back to the same tenant, you don't need to deregister it.
 2. [Replace the motherboard](#replace-the-motherboard)
-3. [Capture a new device ID (4K HH)](#capture-a-new-autopilot-device-id-4k-hh-from-the-device)
+3. If the device needs to be re-registered because of a re-image or will be used by a new tenant, [capture a new device ID (4K HH)](#capture-a-new-autopilot-device-id-4k-hh-from-the-device). 
 4. [Reregister the device](#reregister-the-repaired-device-using-the-new-device-id) with Windows Autopilot
 5. [Reset the device](#reset-the-device)
 6. [Return the device](#return-the-repaired-device-to-the-customer)

memdocs/autopilot/known-issues.md

@@ -1,18 +1,14 @@
 ---
 title: Windows Autopilot known issues
 description: Inform yourself about known issues that may occur during Windows Autopilot deployment.
-keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
-ms.prod: w10
-ms.mktglfcycl: deploy
+ms.prod: windows-client
+ms.technology: itpro-deploy
 ms.localizationpriority: medium
-ms.sitesec: library
-ms.pagetype: deploy
-audience: itpro
 author: aczechowski
 ms.author: aaroncz
 ms.reviewer: jubaptis
 manager: dougeby
-ms.date: 05/18/2022
+ms.date: 09/21/2022
 ms.collection: M365-modern-desktop
 ms.topic: troubleshooting
 ---
@@ -28,6 +24,18 @@ This article describes known issues that can often be resolved by configuration
 
 ## Known issues
 
+### TPM attestation failure with error code 0x81039001
+
+Some devices may intermittently fail TPM attestation during Windows Autopilot pre-provisioning technician flow or self-deployment mode with the error code 0x81039001 E_AUTOPILOT_CLIENT_TPM_MAX_ATTESTATION_RETRY_EXCEEDED. This failure occurs during the 'Securing your hardware' step for Windows Autopilot devices deployed using self-deploying mode or pre-provisioning mode. Subsequent attempts to provision may resolve the issue. A fix is expected by the end of October 2022.
+
+### Autopilot deployment report shows "failure" status on a successful deployment
+
+The Autopilot deployment report (preview) will show a failed status for any device that experiences an initial deployment failure. For subsequent deployment attempts, using the **Try again** or **Continue to desktop** options, it won't update the deployment state in the report. If the user resets the device, it will show as a new deployment row in the report with the previous attempt remaining as failed.
+
+### Autopilot deployment report doesn't show deployed device
+
+Autopilot deployments that take longer than one hour may display an incomplete deployment status in the deployment report. If the device successfully enrolls but doesn't complete provisioning after more than one hour, the device status may not be updated in the report.
+
 ### Autopilot profile not being applied when assigned 
 
 In Windows 10 April and some May update releases, there is an issue where the Autopilot profile may fail to apply to the device and the hardware hash may not be harvested. As a result, any settings made in the profile may not be configured for the user such as device renaming. To resolve this issue, the May (KB5015020) cumulative update needs to be applied to the device.
@@ -62,9 +70,11 @@ When you attempt an Autopilot reset, you see the following message: _Autopilot r
 
 When a device is registered in Autopilot and no profile is assigned, it will take the default Autopilot profile. This behavior is by design. It makes sure that all devices that you register with Autopilot go through the Autopilot experience. If you don't want the device to go through an Autopilot deployment, remove the Autopilot registration.
 
-### White screen during HAADJ deployment
+### White screen during hybrid Azure AD joined deployment
+
+There's a UI bug on Autopilot hybrid Azure AD joined deployments where the Enrollment Status page is displayed as a white screen. This issue is limited to the UI and shouldn't affect the deployment process.
 
-There's a UI bug on Autopilot HAADJ deployments where the Enrollment Status page is displayed as a white screen. This issue is limited to the UI and shouldn't affect the deployment process.
+This issue was resolved in September 2022.
 
 ### Virtual machine failing at "Preparing your device for mobile management"
 

memdocs/autopilot/registration-overview.md

@@ -1,13 +1,9 @@
 ---
 title: Windows Autopilot registration overview
 description: Overview of Windows Autopilot device registration
-keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
-ms.prod: w10
-ms.mktglfcycl: deploy
+ms.prod: windows-client
+ms.technology: itpro-deploy
 ms.localizationpriority: medium
-ms.sitesec: library
-ms.pagetype: deploy
-audience: itpro
 author: aczechowski
 ms.author: aaroncz
 ms.reviewer: jubaptis
@@ -44,6 +40,16 @@ Registration can also be performed within your organization by collecting the ha
 - [Automatic registration](automatic-registration.md)
 - [Manual registration](manual-registration.md)
 
+When you register an Autopilot device, it automatically creates an Azure AD object. The Autopilot deployment process needs this object to identify the device before the user signs in. If you delete this object, the device can fail to enroll through Autopilot. If the device is registered and not enrolled after 180 days, you'll need to re-register the device to complete a successful deployment.
+
+> [!NOTE]
+> Don't register to Autopilot the following types of devices:
+>
+> - [Azure AD registered](/azure/active-directory/devices/concept-azure-ad-register), also known as "workplace joined"
+> - [Intune MDM-only enrollment](/mem/intune/enrollment/windows-enrollment-methods#user-self-enrollment-in-intune)
+>
+> These options are intended for users to join personally-owned devices to their organization's network.
+
 Once a device is registered in Autopilot if a profile is not assigned, it will receive the default Autopilot profile. If you do not want a device to go through Autopilot, you must remove the Autopilot registration. 
 
 ## Terms