Merge branch 'main' into v-smandalika-prtBL-4491111

windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md

@@ -30,9 +30,9 @@ Windows Autopatch can take over software update management control of devices th
 
 You must choose what devices to manage with Windows Autopatch by adding them to the **Windows Autopatch Device Registration** Azure AD assigned group. Devices can be added using the following methods:
 
-- Direct membership 
+- Direct membership
 - Nesting other Azure AD dynamic/assigned groups
-- [Bulk add/import group members](/azure/active-directory/enterprise-users/groups-bulk-import-members) 
+- [Bulk add/import group members](/azure/active-directory/enterprise-users/groups-bulk-import-members)
 
 Windows Autopatch automatically runs its discover devices function every hour to discover new devices added to this group. Once new devices are discovered, Windows Autopatch attempts to register these devices.
 
@@ -77,7 +77,7 @@ To be eligible for Windows Autopatch management, devices must meet a minimum set
             - Windows updates policies
             - Device configuration
             - Office Click-to-run
-- Last Intune device check in completed within the last 28 days.
+- Last Intune device check-in completed within the last 28 days.
 - Devices must have Serial Number, Model and Manufacturer.
 	> [!NOTE]
 	> Windows Autopatch doesn't support device emulators that don't generate Serial number, Model and Manufacturer. Devices that use a non-supported device emulator fail the **Intune or Cloud-Attached** pre-requisite check. Additionally, devices with duplicated serial numbers will fail to register with Windows Autopatch.
@@ -100,7 +100,7 @@ See all possible device readiness statuses in Windows Autopatch:
 
 | Readiness status | Description | Device blade tab |
 | ----- | ----- | ----- |
-| Active | Devices with this status successfully passed all prerequisite checks and subsequently successfully registered with Windows Autopatch. Additionally, devices with this status successfully passed all post-device registration readiness checks. |  Ready |
+| Active | Devices with this status successfully passed all prerequisite checks and then successfully registered with Windows Autopatch. Additionally, devices with this status successfully passed all post-device registration readiness checks. |  Ready |
 | Readiness failed | Devices with this status haven't passed one or more post-device registration readiness checks. These devices aren't ready to have one or more software update workloads managed by Windows Autopatch. | Not ready |
 | Inactive | Devices with this status haven't communicated with Microsoft Endpoint Manager-Intune in the last 28 days. | Not ready |
 | Pre-requisites failed | Devices with this status haven't passed one or more pre-requisite checks and haven't successfully registered with Windows Autopatch | Not registered |
@@ -161,17 +161,48 @@ Windows 365 Enterprise gives IT admins the option to register devices with the W
 1. Provide a policy name and select **Join Type**. For more information, see [Device join types](/windows-365/enterprise/identity-authentication#device-join-types).  
 1. Select **Next**.
 1. Choose the desired image and select **Next**.
-1. Under the **Microsoft managed services** section, select **Windows Autopatch**. Then, select **Next**. If the *Windows Autopatch (preview) cannot manage your Cloud PCs until a Global Admin has finished setting it up.* message appears, you must [enroll your tenant](../prepare/windows-autopatch-enroll-tenant.md) to continue.
+1. Under the **Microsoft managed services** section, select **Windows Autopatch**. Then, select **Next**. If the *Windows Autopatch (preview) can't manage your Cloud PCs until a Global Admin has finished setting it up.* message appears, you must [enroll your tenant](../prepare/windows-autopatch-enroll-tenant.md) to continue.
 1. Assign your policy accordingly and select **Next**.
 1. Select **Create**. Now your newly provisioned Windows 365 Enterprise Cloud PCs will automatically be enrolled and managed by Windows Autopatch.
 
 For more information, see [Create a Windows 365 Provisioning Policy](/windows-365/enterprise/create-provisioning-policy).
 
+### Windows Autopatch on Azure Virtual Desktop workloads
+
+Windows Autopatch is available for your Azure Virtual Desktop workloads. Enterprise admins can provision their Azure Virtual Desktop workloads to be managed by Windows Autopatch using the existing [device registration process](#steps-to-register-devices).
+
+Windows Autopatch provides the same scope of service with virtual machines as it does with [physical devices](#steps-to-register-devices). However, Windows Autopatch defers any Azure Virtual Desktop specific support to [Azure support](#contact-support-for-device-registration-related-incidents), unless otherwise specified.
+
+#### Prerequisites
+
+Windows Autopatch for Azure Virtual Desktop follows the same [prerequisites](../prepare/windows-autopatch-prerequisites.md) as Windows Autopatch, and the [Azure Virtual Desktop prerequisites](/azure/virtual-desktop/prerequisites).
+
+The service supports:
+
+- Personal persistent virtual machines
+
+The following Azure Virtual Desktop features aren’t supported:
+
+- Multi-session hosts
+- Pooled non persistent virtual machines
+- Remote app streaming
+
+#### Deploy Autopatch on Azure Virtual Desktop
+
+Azure Virtual Desktop workloads can be registered into Windows Autopatch by using the same method as your [physical devices](#steps-to-register-devices). For more information, see [Register your devices](#steps-to-register-devices).
+
+For ease of deployment, we recommend nesting a dynamic device group in your Autopatch device registration group. The dynamic device group would target the **Name** prefix defined in your session host, but **exclude** any Multi-Session Session Hosts. For example:
+
+| Group name | Dynamic membership name |
+| ----- | ----- |
+| Windows Autopatch - Host Pool Session Hosts | <ul><li>`(device.displayName -contains "AP")`</li><li>`(device.deviceOSType -ne "Windows 10 Enterprise for Virtual Desktops")`</li></ul> |
+
 ### Contact support for device registration-related incidents
 
 Support is available either through Windows 365, or the Windows Autopatch Service Engineering team for device registration-related incidents.
 
-- For Windows 365 support, see [Get support](/mem/get-support).  
+- For Windows 365 support, see [Get support](/mem/get-support).
+- For Azure Virtual Desktop support, see [Get support](/support/create-ticket/).
 - For Windows Autopatch support, see [Submit a support request](/windows/deployment/windows-autopatch/operate/windows-autopatch-support-request).  
 
 ## Device management lifecycle scenarios

windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-communications.md

@@ -22,7 +22,7 @@ There are three categories of communication that are sent out during a Windows q
 
 Communications are posted to Message center, Service health dashboard, and the Windows Autopatch messages section of the Microsoft Endpoint Manager admin center as appropriate for the type of communication.  
 
-:::image type="content" source="../media/update-communications.png" alt-text="Update communications timeline":::
+:::image type="content" source="../media/update-communications.png" alt-text="Update communications timeline" lightbox="../media/update-communications.png":::
 
 ## Standard communications
 

windows/privacy/configure-windows-diagnostic-data-in-your-organization.md

@@ -88,6 +88,53 @@ The following table lists the endpoints related to how you can manage the collec
 | [Online Crash Analysis](/windows/win32/dxtecharts/crash-dump-analysis) | oca.telemetry.microsoft.com <br></br> oca.microsoft.com <br></br> kmwatsonc.events.data.microsoft.com <br></br> *-kmwatsonc.events.data.microsoft.com |
 |Settings | settings-win.data.microsoft.com <br></br> <br></br> IMPORTANT: This endpoint is used to remotely configure diagnostics-related settings and data collection. For example, we use the settings endpoint to remotely block an event from being sent back to Microsoft. We do not recommend disabling this endpoint. This endpoint does not upload Windows diagnostic data. |
 
+### Proxy server authentication
+
+If your organization uses proxy server authentication for internet access, make sure that it doesn't block the diagnostic data because of authentication. 
+
+#### Bypass (recommended)
+
+Configure your proxy servers to not require proxy authentication for traffic to the diagnostic data endpoints. This option is the most comprehensive solution. It works for all versions of Windows 10 and Windows 11.  
+
+#### User proxy authentication
+
+Configure devices to use the signed-in user's context for proxy authentication. This method requires the following configurations:
+
+- Devices have the current quality update for a supported version of Windows
+
+- Configure user-level proxy (WinINET proxy) in **Proxy settings** in the Network & Internet group of Windows Settings. You can also use the legacy Internet Options control panel.
+
+- Make sure that the users have proxy permission to reach the diagnostic data endpoints. This option requires that the devices have console users with proxy permissions, so you can't use this method with headless devices.
+
+> [!IMPORTANT]
+> The user proxy authentication approach is incompatible with the use of Microsoft Defender for Endpoint. This behavior is because this authentication relies on the **DisableEnterpriseAuthProxy** registry key set to `0`, while Microsoft Defender for Endpoint requires it to be set to `1`. For more information, see [Configure machine proxy and internet connectivity settings in Microsoft Defender for Endpoint](/windows/security/threat-protection/windows-defender-atp/configure-proxy-internet-windows-defender-advanced-threat-protection).
+
+#### Device proxy authentication
+
+This approach supports the following scenarios:
+
+- Headless devices, where no user signs in, or users of the device don't have internet access
+
+- Authenticated proxies that don't use Windows Integrated Authentication
+
+- If you also use Microsoft Defender for Endpoint
+
+This approach is the most complex because it requires the following configurations:
+
+- Make sure devices can reach the proxy server through WinHTTP in local system context. Use one of the following options to configure this behavior:
+
+  - The command line `netsh winhttp set proxy`
+
+  - Web proxy autodiscovery (WPAD) protocol
+
+  - Transparent proxy
+
+  - Configure device-wide WinINET proxy using the following group policy setting: **Make proxy settings per-machine (rather than per-user)** (ProxySettingsPerUser = `1`)
+
+  - Routed connection, or that uses network address translation (NAT)
+
+- Configure proxy servers to allow the computer accounts in Active Directory to access the diagnostic data endpoints. This configuration requires proxy servers to support Windows Integrated Authentication.
+
 ### Data access
 
 The principle of least privileged access guides access to Windows diagnostic data. Microsoft does not share personal data of our customers with third parties, except at the customer’s discretion or for the limited purposes described in the [Privacy Statement](https://privacy.microsoft.com/en-US/privacystatement). Microsoft may share business reports with hardware manufacturers and third-party partners that include aggregated and deidentified diagnostic data information. Data-sharing decisions are made by an internal team including privacy, legal, and data management.