From deae3a807fd1cc16b4149cf5e9c22447d2506a03 Mon Sep 17 00:00:00 2001
From: Harman Thind <63820404+hathin@users.noreply.github.com>
Date: Tue, 15 Oct 2024 11:32:12 -0700
Subject: [PATCH] Update windows-autopatch-post-reg-readiness-checks.md
Hermes v2 is being introduced. Added the new name Windows Autopatch Client Broker, to go along with v1 until v1 is later deprecated. Some customers will have both apps (until v1 is deprecated), and others with newly registered devices will only have v2 app @tiaraquan FYI
---
.../windows-autopatch-post-reg-readiness-checks.md | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/windows/deployment/windows-autopatch/deploy/windows-autopatch-post-reg-readiness-checks.md b/windows/deployment/windows-autopatch/deploy/windows-autopatch-post-reg-readiness-checks.md
index c5f450553f..c4a299bb50 100644
--- a/windows/deployment/windows-autopatch/deploy/windows-autopatch-post-reg-readiness-checks.md
+++ b/windows/deployment/windows-autopatch/deploy/windows-autopatch-post-reg-readiness-checks.md
@@ -36,7 +36,7 @@ Device readiness in Windows Autopatch is divided into two different scenarios:
### Device readiness checks available for each scenario
-| Required device readiness (prerequisite checks) before device registration (powered by Intune Graph API) | Required post-device registration readiness checks (powered by Microsoft Cloud Managed Desktop Extension) |
+| Required device readiness (prerequisite checks) before device registration (powered by Intune Graph API) | Required post-device registration readiness checks (powered by Microsoft Cloud Managed Desktop Extension and Windows Autopatch Client Broker) |
| ----- | ----- |
| - Windows OS (build, architecture, and edition)
- Managed by either Intune or ConfigMgr co-management
- ConfigMgr co-management workloads
- Last communication with Intune
- Personal or non-Windows devices
| - Windows OS (build, architecture, and edition)
- Windows updates & Office Group Policy Object (GPO) versus Intune mobile device management (MDM) policy conflict
- Bind network endpoints (Microsoft Defender, Microsoft Teams, Microsoft Edge, Microsoft Office)
- Internet connectivity
|
@@ -66,7 +66,7 @@ A healthy or active device in Windows Autopatch is:
- Actively sending data
- Passes all post-device registration readiness checks
-The post-device registration readiness checks are powered by the **Microsoft Cloud Managed Desktop Extension**. It's installed right after devices are successfully registered with Windows Autopatch. The **Microsoft Cloud Managed Desktop Extension** has the Device Readiness Check Plugin. The Device Readiness Check Plugin is responsible for performing the readiness checks and reporting the results back to the service. The **Microsoft Cloud Managed Desktop Extension** is a subcomponent of the overall Windows Autopatch service.
+The post-device registration readiness checks are powered by the **Microsoft Cloud Managed Desktop Extension**. It's installed right after devices are successfully registered with Windows Autopatch. The **Microsoft Cloud Managed Desktop Extension** and **Windows Autopatch Client Broker** has the Device Readiness Check Plugin. The Device Readiness Check Plugin is responsible for performing the readiness checks and reporting the results back to the service. The **Microsoft Cloud Managed Desktop Extension** and **Windows Autopatch Client Broker** are subcomponents of the overall Windows Autopatch service.
The following list of post-device registration readiness checks is performed in Windows Autopatch:
@@ -90,8 +90,8 @@ See the following diagram for the post-device registration readiness checks work
| Step | Description |
| ----- | ----- |
| **Steps 1-7** | For more information, see the [Device registration overview diagram](windows-autopatch-device-registration-overview.md).|
-| **Step 8: Perform readiness checks** |- Once devices are successfully registered with Windows Autopatch, the devices are added to the **Ready** tab.
- The Microsoft Cloud Managed Desktop Extension agent performs readiness checks against devices in the **Ready** tab every 24 hours.
|
-| **Step 9: Check readiness status** |- The Microsoft Cloud Managed Desktop Extension service evaluates the readiness results gathered by its agent.
- The readiness results are sent from the Microsoft Cloud Managed Desktop Extension service component to the Device Readiness component within the Windows Autopatch's service.
|
+| **Step 8: Perform readiness checks** |- Once devices are successfully registered with Windows Autopatch, the devices are added to the **Ready** tab.
- The Microsoft Cloud Managed Desktop Extension and Windows Autopatch Client Broker agents perform readiness checks against devices in the **Ready** tab every 24 hours.
|
+| **Step 9: Check readiness status** |- The Microsoft Cloud Managed Desktop Extension and Windows Autopatch Client Broker service evaluates the readiness results gathered by its agent.
- The readiness results are sent from the Microsoft Cloud Managed Desktop Extension and Windows Autopatch Client Broker service component to the Device Readiness component within the Windows Autopatch's service.
|
| **Step 10: Add devices to the Not ready** | When devices don't pass one or more readiness checks, even if they're registered with Windows Autopatch, they're added to the **Not ready** tab so IT admins can remediate devices based on Windows Autopatch recommendations. |
| **Step 11: IT admin understands what the issue is and remediates** | The IT admin checks and remediates issues in the Devices blade (**Not ready** tab). It can take up to 24 hours for devices to show in the **Ready** tab. |
@@ -99,7 +99,7 @@ See the following diagram for the post-device registration readiness checks work
| Question | Answer |
| ----- | ----- |
-| **How frequent are the post-device registration readiness checks performed?** |- The **Microsoft Cloud Managed Desktop Extension** agent collects device readiness statuses when it runs (once a day).
- Once the agent collects results for the post-device registration readiness checks, it generates readiness results in the device in the `%programdata%\Microsoft\CMDExtension\Plugins\DeviceReadinessPlugin\Logs\DRCResults.json.log`.
- The readiness results are sent over to the **Microsoft Cloud Managed Desktop Extension service**.
- The **Microsoft Cloud Managed Desktop Extension** service component sends the readiness results to the Device Readiness component. The results appear in the Windows Autopatch Devices blade (**Not ready** tab).
|
+| **How frequent are the post-device registration readiness checks performed?** |- The **Microsoft Cloud Managed Desktop Extension** and **Windows Autopatch Client Broker** agents collect device readiness statuses when it runs (once a day).
- Once the agent collects results for the post-device registration readiness checks, it generates readiness results in the device in the `%programdata%\Microsoft\CMDExtension\Plugins\DeviceReadinessPlugin\Logs\DRCResults.json.log`.
- The readiness results are sent over to **Microsoft Cloud Managed Desktop Extension** and **Windows Autopatch Client Broker** service.
- The **Microsoft Cloud Managed Desktop Extension** and **Windows Autopatch Client Broker** service component sends the readiness results to the Device Readiness component. The results appear in the Windows Autopatch Devices blade (**Not ready** tab).
|
| **What to expect when one or more checks fail?** | Devices are automatically sent to the **Ready** tab once they're successfully registered with Windows Autopatch. When devices don't meet one or more post-device registration readiness checks, the devices are moved to the **Not ready** tab. IT admins can learn about these devices and take appropriate actions to remediate them. Windows Autopatch provides information about the failure and how to potentially remediate devices.Once devices are remediated, it can take up to **24 hours** to appear in the **Ready** tab.
|
## Additional resources