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 366aeefe9e..0b0eb1985d 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 @@ -16,9 +16,9 @@ msreviewer: andredm7 One of the most expensive aspects of the software update management process is to make sure devices are always healthy to receive and report software updates for each software update release cycle. -Having a way of measuring, quickly detecting and remediating when something goes wrong with on-going change management processes is very important; it helps mitigate high Helpdesk ticket volumes, reduces cost, and improves overall update management results. +Having a way of measuring, quickly detecting and remediating when something goes wrong with on-going change management processes is important; it helps mitigate high Helpdesk ticket volumes, reduces cost, and improves overall update management results. -Windows Autopatch provides proactive device readiness information about devices that are and are not ready to be fully managed by the service. IT admins can easily detect and fix device-related issues that are preventing them from achieving their update management compliance report goals. +Windows Autopatch provides proactive device readiness information about devices that are and aren't ready to be fully managed by the service. IT admins can easily detect and fix device-related issues that are preventing them from achieving their update management compliance report goals. ## Device readiness scenarios @@ -27,7 +27,7 @@ Device readiness in Windows Autopatch is divided into two different scenarios: | Scenario | Description | | ----- | ----- | | Prerequisite checks | Ensures devices follow software-based requirements before being registered with the service. | -| Post-device registration readiness checks | Provides continuous monitoring of device health for registered devices.

IT admins can easily detect and remediate configuration mismatches in their environments or issues that prevent devices from having one or more software update workloads (Windows quality, feature updates, Microsoft Office, Teams, or Edge) fully managed by the Windows Autopatch service. Configuration mismatches can leave devices in a vulnerable state, out of compliance and exposed to security threats.

| +| Post-device registration readiness checks | Provides continuous monitoring of device health for registered devices.

IT admins can easily detect and remediate configuration mismatches in their environments or issues that prevent devices from having one or more software update workloads (Windows quality, feature updates, Microsoft Office, Microsoft Teams, or Microsoft Edge) fully managed by the Windows Autopatch service. Configuration mismatches can leave devices in a vulnerable state, out of compliance and exposed to security threats.

| ## Device readiness @@ -35,11 +35,11 @@ Device readiness in Windows Autopatch is divided into two different scenarios: | ----- | ----- | | | | -The status of each post-device registration readiness check is shown in the Windows Autopatch’s device blade under the Not ready tab. You can take appropriate action(s) on devices that are not ready to be fully managed by the Windows Autopatch service. +The status of each post-device registration readiness check is shown in the Windows Autopatch’s Devices blade under the **Not ready** tab. You can take appropriate action(s) on devices that aren't ready to be fully managed by the Windows Autopatch service. ## About the three tabs in the Devices blade -You deploy software updates to secure your environment, but these deployments only reach healthy/active devices. Unhealthy or not ready devices affect the overall software update compliance. Figuring out device health can be challenging and disruptive to the end user when IT can’t obtain proactive data sent by the device to the service so IT admins can proactively detect, troubleshoot, and fix issues. +You deploy software updates to secure your environment, but these deployments only reach healthy/active devices. Unhealthy or not ready devices affect the overall software update compliance. Figuring out device health can be challenging and disruptive to the end user when IT can’t obtain proactive data sent by the device to the service for IT admins to proactively detect, troubleshoot, and fix issues. Windows Autopatch has three tabs within its Devices blade. Each tab is designed to provide a different set of device readiness statuses so IT admins know where to go to monitor, and troubleshoot potential device health issues: @@ -49,7 +49,7 @@ Windows Autopatch has three tabs within its Devices blade. Each tab is designed | Not ready | This tab only lists devices with the **Readiness failed** and **Inactive** status. | | Not registered | Only lists devices with the **Prerequisite failed** status in it. Devices with the **Prerequisite failed** status didn’t pass one or more prerequisite checks during the device registration process. | -More details about the post-device registration readiness checks +## Details about the post-device registration readiness checks A healthy or active device in Windows Autopatch is: @@ -57,7 +57,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, which is an agent or app, that is installed right after devices are successfully registered with Windows Autopatch. The Microsoft Cloud Managed Desktop Extension has the Device Readiness Check Plugin responsible for performing the readiness checks in devices and report back to the 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 has the Device Readiness Check Plugin responsible for performing the readiness checks in devices and report back to the service. See the following list of checks performed in Windows Autopatch in the first release of the post-device registration readiness checks: @@ -86,14 +86,14 @@ See the following end-to-end IT admin operation workflow: | **Step 8: Perform readiness checks** | Once devices are successfully registered with Windows Autopatch, the Microsoft Cloud Managed Desktop Extension agent performs readiness checks against devices every 24 hours. | | **Step 9: Check readiness status** |
  1. The Microsoft Cloud Managed Desktop Extension service evaluates the readiness results gathered by its agent.
  2. The readiness results are sent to the Windows Autopatch’s device readiness 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 into the **Not ready** tab so IT admins can remediate devices. | -| **Step 11: IT admin understands what the issue is and remediates** | IT admin checks remediates issues surfaced by Windows Autopatch in its device blade (**Not ready** tab), it can take up to 24 hours for devices to show back up into the **Ready** tab. | +| **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 back up into the **Ready** tab. | ## FAQ | Question | Answer | | ----- | ----- | | **How frequent are the post-device registration readiness checks performed?** || -| **What to expect when one or more checks fail?** | Devices are automatically sent to the Ready tab once they are 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 will provide information about the failure and how to potentially remediate devices.

Once devices are remediated, it can take up to 24 hours to show up in the **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 will provide information about the failure and how to potentially remediate devices.

Once devices are remediated, it can take up to 24 hours to show up in the **Ready** tab.

| ## Additional resources diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-maintain-environment.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-maintain-environment.md index 2515a08a9a..9fa7e60794 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-maintain-environment.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-maintain-environment.md @@ -27,3 +27,7 @@ After you've completed enrollment in Windows Autopatch, some management settings | Setting | Description | | ----- | ----- | | Update rings for Windows 10 or later | For any update rings for Windows 10 or later policies you've created, exclude the **Modern Workplace Devices - All** Azure AD group from each policy. For more information, see [Create and assign update rings](/mem/intune/protect/windows-10-update-rings#create-and-assign-update-rings).

Windows Autopatch will also have created some update ring policies. all of which The policies will have "**Modern Workplace**" in the name. For example:

When you update your own policies, ensure that you don't exclude the **Modern Workplace Devices - All** Azure AD group from the policies that Windows Autopatch created.

**To resolve the Not ready result:**

After enrolling into Autopatch, make sure that any update ring policies you have **exclude** the **Modern Workplace Devices - All** Azure Active Directory (AD) group.For more information, see [Manage Windows 10 software updates in Intune](/mem/intune/protect/windows-update-for-business-configure).

**To resolve the Advisory result:**

  1. Make sure that any update ring policies you have **exclude** the **Modern Workplace Devices - All** Azure Active Directory (AD) group.
  2. If you have assigned Azure AD user groups to these policies, make sure that any update ring policies you have also **exclude** the **Modern Workplace - All** Azure AD group that you add your Windows Autopatch users to (or an equivalent group).

For more information, see [Manage Windows 10 software updates in Intune](/mem/intune/protect/windows-update-for-business-configure).

| + +## Windows Autopatch configurations + +Windows Autopatch deploys, manages and maintains all configurations related to the operation of the service, as described in [Changes made at tenant enrollment](../references/windows-autopatch-changes-to-tenant.md). Don't make any changes to any of the Windows Autopatch configurations. diff --git a/windows/deployment/windows-autopatch/references/windows-autopatch-changes-to-tenant.md b/windows/deployment/windows-autopatch/references/windows-autopatch-changes-to-tenant.md index 5f31bb4692..698612aa82 100644 --- a/windows/deployment/windows-autopatch/references/windows-autopatch-changes-to-tenant.md +++ b/windows/deployment/windows-autopatch/references/windows-autopatch-changes-to-tenant.md @@ -14,6 +14,11 @@ msreviewer: hathind # Changes made at tenant enrollment +The following configuration details are provided as information to help you understand the changes made to your tenant when enrolling into the Windows Autopatch service. + +> [!IMPORTANT] +> The service manages and maintains the following configuration items. Don't change, edit, add to, or remove any of the configurations. Doing so might cause unintended configuration conflicts and impact the Windows Autopatch service. + ## Service principal Windows Autopatch will create a service principal in your tenant allowing the service to establish an identity and restrict access to what resources the service has access to within the tenant. For more information, see [Application and service principal objects in Azure Active Directory](/azure/active-directory/develop/app-objects-and-service-principals#service-principal-object). The service principal created by Windows Autopatch is: