mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-12 13:27:23 +00:00
Merge branch 'main' into release-win11-22h2
This commit is contained in:
Alma Jenks
commit
fb5182a74f
@ -92,7 +92,7 @@ While Intune for Education offers simple options for Autopilot configurations, m
|
||||
|
||||
An Enrollment Status Page (ESP) is a greeting page displayed to users while enrolling or signing in for the first time to Windows devices. The ESP displays provisioning progress, showing applications and profiles installation status.
|
||||
|
||||
:::image type="content" source="./images/win11-oobe-esp.png" alt-text="Windows OOBE - enrollment status page" border="false":::
|
||||
:::image type="content" source="./images/win11-oobe-esp.gif" alt-text="Windows OOBE - enrollment status page animation." border="false":::
|
||||
|
||||
> [!NOTE]
|
||||
> Some Windows Autopilot deployment profiles **require** the ESP to be configured.
|
||||
|
||||
@ -57,10 +57,9 @@ For more information, see [Install Windows Configuration Designer][WIN-1], which
|
||||
## Enroll devices with the provisioning package
|
||||
|
||||
To provision Windows devices with provisioning packages, insert the USB stick containing the package during the out-of-box experience. The devices will read the content of the package, join Azure AD and automatically enroll in Intune.
|
||||
All settings defined in the package and in Intune will be applied to the device, and the device will be ready to use.
|
||||
|
||||
:::image type="content" source="./images/win11-oobe-ppkg.png" alt-text="Windows 11 OOBE - enrollment with provisioning package." border="false":::
|
||||
|
||||
:::image type="content" source="./images/win11-login-screen.png" alt-text="Windows 11 login screen" border="false":::
|
||||
:::image type="content" source="./images/win11-oobe-ppkg.gif" alt-text="Windows 11 OOBE - enrollment with provisioning package animation." border="false":::
|
||||
|
||||
________________________________________________________
|
||||
## Next steps
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 102 KiB After Width: | Height: | Size: 89 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 79 KiB After Width: | Height: | Size: 76 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.5 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 260 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 3.1 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 265 KiB |
@ -133,7 +133,7 @@ To configure your school's branding:
|
||||
:::image type="content" source="images/entra-branding.png" alt-text="Configure Azure AD branding from Microsoft Entra admin center." lightbox="images/entra-branding.png":::
|
||||
1. To adjust the school tenant's name displayed during OOBE, select **Azure Active Directory** > **Overview** > **Properties**
|
||||
1. In the **Name** field, enter the school district or organization's name > **Save**
|
||||
:::image type="content" alt-text="Configure Azure AD tenant name from Microsoft Entra admin center." source="images/entra-tenant-name.png":::
|
||||
:::image type="content" alt-text="Configure Azure AD tenant name from Microsoft Entra admin center." source="images/entra-tenant-name.png" lightbox="images/entra-tenant-name.png":::
|
||||
|
||||
For more information, see [Add branding to your directory][AAD-5].
|
||||
|
||||
|
||||
@ -78,7 +78,7 @@ To disable Windows Hello for Business at the tenant level:
|
||||
1. Ensure that **Configure Windows Hello for Business** is set to **disabled**
|
||||
1. Select **Save**
|
||||
|
||||
:::image type="content" source="./images/whfb-disable.png" alt-text="Disablement of Windows Hello for Business from Microsoft Endpoint Manager admin center" border="true":::
|
||||
:::image type="content" source="./images/whfb-disable.png" alt-text="Disablement of Windows Hello for Business from Microsoft Endpoint Manager admin center." border="true" lightbox="./images/whfb-disable.png":::
|
||||
|
||||
For more information how to enable Windows Hello for Business on specific devices, see [Create a Windows Hello for Business policy][MEM-4].
|
||||
|
||||
|
||||
@ -38,6 +38,7 @@ Windows 11 SE comes with some preinstalled apps. The following apps can also run
|
||||
| Application | Supported version | App Type | Vendor |
|
||||
| --- | --- | --- | --- |
|
||||
|AirSecure |8.0.0 |Win32 |AIR|
|
||||
|Alertus Desktop |5.4.44.0 |Win32 | Alertus technologies|
|
||||
|Brave Browser |1.34.80|Win32 |Brave|
|
||||
|Bulb Digital Portfolio |0.0.7.0|Store|Bulb|
|
||||
|Cisco Umbrella |3.0.110.0 |Win32 |Cisco|
|
||||
@ -56,27 +57,30 @@ Windows 11 SE comes with some preinstalled apps. The following apps can also run
|
||||
|Google Chrome |102.0.5005.115|Win32 |Google|
|
||||
|Illuminate Lockdown Browser |2.0.5 |Win32 |Illuminate Education|
|
||||
|Immunet |7.5.0.20795 |Win32 |Immunet|
|
||||
|Impero Backdrop Client |4.4.86 |Win32 |Impero Software|
|
||||
|JAWS for Windows |2022.2112.24 |Win32 |Freedom Scientific|
|
||||
|Kite Student Portal |8.0.3.0 |Win32 |Dynamic Learning Maps|
|
||||
|Kortext |2.3.433.0 |Store |Kortext|
|
||||
|Kurzweil 3000 Assistive Learning |20.13.0000 |Win32 |Kurzweil Educational Systems|
|
||||
|LanSchool |9.1.0.46 |Win32 |Stoneware|
|
||||
|Lightspeed Smart Agent |2.6.2 |Win32 |Lightspeed Systems|
|
||||
|MetaMoJi ClassRoom |3.12.4.0 |Store |MetaMoJi Corporation|
|
||||
|Microsoft Connect |10.0.22000.1 |Store |Microsoft|
|
||||
|Mozilla Firefox |99.0.1 |Win32 |Mozilla|
|
||||
|NAPLAN |2.5.0 |Win32 |NAP|
|
||||
|Netref Student |22.2.0 |Win32 |NetRef|
|
||||
|NetSupport Manager |12.01.0011 |Win32 |NetSupport|
|
||||
|NetSupport Notify |5.10.1.215 |Win32 |NetSupport|
|
||||
|NetSupport School |14.00.0011 |Win32 |NetSupport|
|
||||
|NextUp Talker |1.0.49 |Win32 |NextUp Technologies|
|
||||
|NonVisual Desktop Access |2021.3.1 |Win32 |NV Access|
|
||||
|NWEA Secure Testing Browser |5.4.300.0 |Win32 |NWEA|
|
||||
|NWEA Secure Testing Browser |5.4.356.0 |Win32 |NWEA|
|
||||
|Pearson TestNav |1.10.2.0 |Store |Pearson|
|
||||
|Questar Secure Browser |4.8.3.376 |Win32 |Questar, Inc|
|
||||
|ReadAndWriteForWindows |12.0.60.0 |Win32 |Texthelp Ltd.|
|
||||
|Remote Desktop client (MSRDC) |1.2.3213.0 |Win32 |Microsoft|
|
||||
|Remote Help |3.8.0.12 |Win32 |Microsoft|
|
||||
|Respondus Lockdown Browser |2.0.8.05 |Win32 |Respondus|
|
||||
|Respondus Lockdown Browser |2.0.9.00 |Win32 |Respondus|
|
||||
|Safe Exam Browser |3.3.2.413 |Win32 |Safe Exam Browser|
|
||||
|Secure Browser |14.0.0 |Win32 |Cambium Development|
|
||||
|Senso.Cloud |2021.11.15.0 |Win32|Senso.Cloud|
|
||||
|
||||
@ -18,8 +18,8 @@ ms.topic: article
|
||||
- Windows 11
|
||||
- Windows Server 2022
|
||||
|
||||
|
||||
## Summary
|
||||
|
||||
By using Windows operating systems, administrators can determine what devices can be installed on computers they manage. This guide summarizes the device installation process and demonstrates several techniques for controlling device installation by using Group Policy.
|
||||
|
||||
## Introduction
|
||||
@ -60,7 +60,6 @@ It's more difficult for users to make unauthorized copies of company data if use
|
||||
|
||||
You can ensure that users install only those devices that your technical support team is trained and equipped to support. This benefit reduces support costs and user confusion.
|
||||
|
||||
|
||||
## Scenario Overview
|
||||
|
||||
The scenarios presented in this guide illustrate how you can control device installation and usage on the computers that you manage. The scenarios use Group Policy on a local machine to simplify using the procedures in a lab environment. In an environment where you manage multiple client computers, you should apply these settings using Group Policy.. With Group Policy deployed by Active Directory, you can apply settings to all computers that are members of a domain or an organizational unit in a domain. For more information about how to use Group Policy to manage your client computers, see Group Policy at the Microsoft Web site.
|
||||
@ -90,7 +89,6 @@ This scenario, although similar to scenario #2, brings another layer of complexi
|
||||
|
||||
In this scenario, combining all previous four scenarios, you'll learn how to protect a machine from all unauthorized USB devices. The administrator wants to allow users to install only a small set of authorized USB devices while preventing any other USB device from being installed. In addition, this scenario includes an explanation of how to apply the ‘prevent’ functionality to existing USB devices that have already been installed on the machine, and the administrator likes to prevent any farther interaction with them (blocking them all together). This scenario builds on the policies and structure we introduced in the first four scenarios and therefore it's preferred to go over them first before attempting this scenario.
|
||||
|
||||
|
||||
## Technology Review
|
||||
|
||||
The following sections provide a brief overview of the core technologies discussed in this guide and give background information that is necessary to understand the scenarios.
|
||||
@ -126,14 +124,14 @@ Hardware IDs are the identifiers that provide the exact match between a device a
|
||||
|
||||
Windows uses these identifiers to select a driver if the operating system can't find a match with the device ID or any of the other hardware IDs. Compatible IDs are listed in the order of decreasing suitability. These strings are optional, and, when provided, they're generic, such as Disk. When a match is made using a compatible ID, you can typically use only the most basic functions of the device.
|
||||
|
||||
When you install a device, such as a printer, a USB storage device, or a keyboard, Windows searches for driver packages that match the device you are attempting to install. During this search, Windows assigns a "rank" to each driver package it discovers with at least one match to a hardware or compatible ID. The rank indicates how well the driver matches the device. Lower rank numbers indicate better matches between the driver and the device. A rank of zero represents the best possible match. A match with the device ID to one in the driver package results in a lower (better) rank than a match to one of the other hardware IDs. Similarly, a match to a hardware ID results in a better rank than a match to any of the compatible IDs. After Windows ranks all of the driver packages, it installs the one with the lowest overall rank. For more information about the process of ranking and selecting driver packages, see How Setup Selects Drivers in the Microsoft Docs library.
|
||||
When you install a device, such as a printer, a USB storage device, or a keyboard, Windows searches for driver packages that match the device you are attempting to install. During this search, Windows assigns a "rank" to each driver package it discovers with at least one match to a hardware or compatible ID. The rank indicates how well the driver matches the device. Lower rank numbers indicate better matches between the driver and the device. A rank of zero represents the best possible match. A match with the device ID to one in the driver package results in a lower (better) rank than a match to one of the other hardware IDs. Similarly, a match to a hardware ID results in a better rank than a match to any of the compatible IDs. After Windows ranks all of the driver packages, it installs the one with the lowest overall rank. For more information about the process of ranking and selecting driver packages, see [How Windows selects a driver package for a device](/windows-hardware/drivers/install/how-windows-selects-a-driver-for-a-device).
|
||||
|
||||
> [!NOTE]
|
||||
> For more information about the driver installation process, see the "Technology review" section of the Step-by-Step Guide to Driver Signing and Staging.
|
||||
|
||||
Some physical devices create one or more logical devices when they're installed. Each logical device might handle part of the functionality of the physical device. For example, a multi-function device, such as an all-in-one scanner/fax/printer, might have a different device identification string for each function.
|
||||
|
||||
When you use Device Installation policies to allow or prevent the installation of a device that uses logical devices, you must allow or prevent all of the device identification strings for that device. For example, if a user attempts to install a multifunction device and you didn't allow or prevent all of the identification strings for both physical and logical devices, you could get unexpected results from the installation attempt. For more detailed information about hardware IDs, see Device Identification Strings in Microsoft Docs.
|
||||
When you use Device Installation policies to allow or prevent the installation of a device that uses logical devices, you must allow or prevent all of the device identification strings for that device. For example, if a user attempts to install a multifunction device and you didn't allow or prevent all of the identification strings for both physical and logical devices, you could get unexpected results from the installation attempt. For more detailed information about hardware IDs, see [Device identification strings](/windows-hardware/drivers/install/device-identification-strings).
|
||||
|
||||
#### Device setup classes
|
||||
|
||||
@ -143,7 +141,7 @@ When you use device Classes to allow or prevent users from installing drivers, y
|
||||
|
||||
For example, a multi-function device, such as an all-in-one scanner/fax/printer, has a GUID for a generic multi-function device, a GUID for the printer function, a GUID for the scanner function, and so on. The GUIDs for the individual functions are "child nodes" under the multi-function device GUID. To install a child node, Windows must also be able to install the parent node. You must allow installation of the device setup class of the parent GUID for the multi-function device in addition to any child GUIDs for the printer and scanner functions.
|
||||
|
||||
For more information, see [Device Setup Classes](/windows-hardware/drivers/install/overview-of-device-setup-classes) in Microsoft Docs.
|
||||
For more information, see [Device Setup Classes](/windows-hardware/drivers/install/overview-of-device-setup-classes).
|
||||
|
||||
This guide doesn't depict any scenarios that use device setup classes. However, the basic principles demonstrated with device identification strings in this guide also apply to device setup classes. After you discover the device setup class for a specific device, you can then use it in a policy to either allow or prevent installation of drivers for that class of devices.
|
||||
|
||||
@ -154,14 +152,13 @@ The following two links provide the complete list of Device Setup Classes. ‘Sy
|
||||
|
||||
#### ‘Removable Device’ Device type
|
||||
|
||||
Some devices could be classified as _Removable Device_. A device is considered _removable_ when the driver for the device to which it's connected indicates that the device is removable. For example, a USB device is reported to be removable by the drivers for the USB hub to which the device is connected.
|
||||
|
||||
Some devices could be classified as _Removable Device_. A device is considered _removable_ when the driver for the device to which it's connected indicates that the device is removable. For example, a USB device is reported to be removable by the drivers for the USB hub to which the device is connected.
|
||||
|
||||
### Group Policy Settings for Device Installation
|
||||
|
||||
Group Policy is an infrastructure that allows you to specify managed configurations for users and computers through Group Policy settings and Group Policy Preferences.
|
||||
|
||||
Device Installation section in Group Policy is a set of policies that control which device could or couldn't be installed on a machine. Whether you want to apply the settings to a stand-alone computer or to many computers in an Active Directory domain, you use the Group Policy Object Editor to configure and apply the policy settings. For more information, see Group Policy Object Editor Technical Reference.
|
||||
Device Installation section in Group Policy is a set of policies that control which device could or couldn't be installed on a machine. Whether you want to apply the settings to a stand-alone computer or to many computers in an Active Directory domain, you use the Group Policy Object Editor to configure and apply the policy settings. For more information, see [Group Policy Object Editor](/previous-versions/windows/desktop/Policy/group-policy-object-editor).
|
||||
|
||||
The following passages are brief descriptions of the Device Installation policies that are used in this guide.
|
||||
|
||||
@ -210,12 +207,9 @@ This policy setting will change the evaluation order in which Allow and Prevent
|
||||
> If you disable or don't configure this policy setting, the default evaluation is used. By default, all "Prevent installation..." policy settings have precedence over any other policy setting that allows Windows to install a device.
|
||||
|
||||
Some of these policies take precedence over other policies. The flowchart shown below illustrates how Windows processes them to determine whether a user can install a device or not, as shown in Figure below.
|
||||
|
||||
|
||||
<br/>_Device Installation policies flow chart_
|
||||
|
||||
|
||||
|
||||
|
||||
## Requirements for completing the scenarios
|
||||
|
||||
### General
|
||||
@ -259,7 +253,7 @@ To find device identification strings using Device Manager
|
||||
3. Device Manager starts and displays a tree representing all of the devices detected on your computer. At the top of the tree is a node with your computers name next to it. Lower nodes represent the various categories of hardware into which your computers devices are grouped.
|
||||
|
||||
4. Find the “Printers” section and find the target printer
|
||||
|
||||
|
||||
<br/>_Selecting the printer in Device Manager_
|
||||
|
||||
5. Double-click the printer and move to the ‘Details’ tab.
|
||||
@ -273,7 +267,7 @@ To find device identification strings using Device Manager
|
||||
<br/>_HWID and Compatible ID_
|
||||
|
||||
> [!TIP]
|
||||
> You can also determine your device identification strings by using the PnPUtil command-line utility. For more information, see [PnPUtil - Windows drivers](/windows-hardware/drivers/devtest/pnputil) in Microsoft Docs.
|
||||
> You can also determine your device identification strings by using the PnPUtil command-line utility. For more information, see [PnPUtil - Windows drivers](/windows-hardware/drivers/devtest/pnputil).
|
||||
|
||||
### Getting device identifiers using PnPUtil
|
||||
|
||||
@ -316,7 +310,7 @@ Setting up the environment for the scenario with the following steps:
|
||||
|
||||
1. Open Group Policy Editor and navigate to the Device Installation Restriction section.
|
||||
|
||||
2. Disable all previous Device Installation policies, except ‘Apply layered order of evaluation’—although the policy is disabled in default, this policy is recommended to be enabled in most practical applications.
|
||||
2. Disable all previous Device Installation policies, except ‘Apply layered order of evaluation’—although the policy is disabled in default, this policy is recommended to be enabled in most practical applications.
|
||||
|
||||
3. If there are any enabled policies, changing their status to ‘disabled’, would clear them from all parameters
|
||||
|
||||
@ -333,7 +327,7 @@ Getting the right device identifier to prevent it from being installed:
|
||||
- [System-Defined Device Setup Classes Available to Vendors - Windows drivers](/windows-hardware/drivers/install/system-defined-device-setup-classes-available-to-vendors)
|
||||
- [System-Defined Device Setup Classes Reserved for System Use - Windows drivers](/windows-hardware/drivers/install/system-defined-device-setup-classes-reserved-for-system-use)
|
||||
|
||||
3. Our current scenario is focused on preventing all printers from being installed, as such here's the Class GUID for most of printers in the market:
|
||||
3. Our current scenario is focused on preventing all printers from being installed, as such here's the Class GUID for most of printers in the market:
|
||||
|
||||
> Printers\
|
||||
> Class = Printer\
|
||||
@ -347,7 +341,7 @@ Creating the policy to prevent all printers from being installed:
|
||||
|
||||
1. Open Group Policy Object Editor—either click the Start button, type mmc gpedit.msc in the Start Search box, and then press ENTER; or type in the Windows search “Group Policy Editor” and open the UI.
|
||||
|
||||
2. Navigate to the Device Installation Restriction page:
|
||||
2. Navigate to the Device Installation Restriction page:
|
||||
|
||||
> Computer Configuration > Administrative Templates > System > Device Installation > Device Installation Restrictions
|
||||
|
||||
@ -625,12 +619,12 @@ These devices are internal devices on the machine that define the USB port conne
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Some device in the system have several layers of connectivity to define their installation on the system. USB thumb-drives are such devices. Thus, when looking to either block or allow them on a system, it's important to understand the path of connectivity for each device. There are several generic Device IDs that are commonly used in systems and could provide a good start to build an ‘Allow list’ in such cases. See below for the list:
|
||||
>
|
||||
> PCI\CC_0C03; PCI\CC_0C0330; PCI\VEN_8086; PNP0CA1; PNP0CA1&HOST (for Host Controllers)/
|
||||
>
|
||||
> PCI\CC_0C03; PCI\CC_0C0330; PCI\VEN_8086; PNP0CA1; PNP0CA1&HOST (for Host Controllers)/
|
||||
> USB\ROOT_HUB30; USB\ROOT_HUB20 (for USB Root Hubs)/
|
||||
> USB\USB20_HUB (for Generic USB Hubs)/
|
||||
>
|
||||
> Specifically for desktop machines, it's very important to list all the USB devices that your keyboards and mice are connected through in the above list. Failing to do so could block a user from accessing its machine through HID devices.
|
||||
>
|
||||
> Specifically for desktop machines, it's very important to list all the USB devices that your keyboards and mice are connected through in the above list. Failing to do so could block a user from accessing its machine through HID devices.
|
||||
>
|
||||
> Different PC manufacturers sometimes have different ways to nest USB devices in the PnP tree, but in general this is how it's done.
|
||||
|
||||
|
||||
@ -754,7 +754,7 @@ ADMX Info:
|
||||
|
||||
This setting allows you to control how BitLocker-protected operating system drives are recovered in the absence of required startup key information. This setting is applied when you turn on BitLocker.
|
||||
|
||||
The "OSAllowDRA_Name" (Allow certificate-based data recovery agent) data field is used to specify whether a data recovery agent can be used with BitLocker-protected operating system drives. Before a data recovery agent can be used, it must be added from the Public Key Policies item in either the Group Policy Management Console or the Local Group Policy Editor. For more information about adding data recovery agents, see the BitLocker Drive Encryption Deployment Guide on Microsoft Docs.
|
||||
The "OSAllowDRA_Name" (Allow certificate-based data recovery agent) data field is used to specify whether a data recovery agent can be used with BitLocker-protected operating system drives. Before a data recovery agent can be used, it must be added from the Public Key Policies item in either the Group Policy Management Console or the Local Group Policy Editor. For more information about adding data recovery agents, see [BitLocker recovery guide](/windows/security/information-protection/bitlocker/bitlocker-recovery-guide-plan).
|
||||
|
||||
In "OSRecoveryPasswordUsageDropDown_Name" and "OSRecoveryKeyUsageDropDown_Name" (Configure user storage of BitLocker recovery information) set whether users are allowed, required, or not allowed to generate a 48-digit recovery password or a 256-bit recovery key.
|
||||
|
||||
@ -843,7 +843,7 @@ ADMX Info:
|
||||
|
||||
This setting allows you to control how BitLocker-protected fixed data drives are recovered in the absence of the required credentials. This setting is applied when you turn on BitLocker.
|
||||
|
||||
The "FDVAllowDRA_Name" (Allow data recovery agent) data field is used to specify whether a data recovery agent can be used with BitLocker-protected fixed data drives. Before a data recovery agent can be used, it must be added from the Public Key Policies item in either the Group Policy Management Console or the Local Group Policy Editor. For more information about adding data recovery agents, see the BitLocker Drive Encryption Deployment Guide on Microsoft Docs.
|
||||
The "FDVAllowDRA_Name" (Allow data recovery agent) data field is used to specify whether a data recovery agent can be used with BitLocker-protected fixed data drives. Before a data recovery agent can be used, it must be added from the Public Key Policies item in either the Group Policy Management Console or the Local Group Policy Editor. For more information about adding data recovery agents, see [BitLocker recovery guide](/windows/security/information-protection/bitlocker/bitlocker-recovery-guide-plan).
|
||||
|
||||
In "FDVRecoveryPasswordUsageDropDown_Name" (Configure user storage of BitLocker recovery information) set whether users are allowed, required, or not allowed to generate a 48-digit recovery password or a 256-bit recovery key.
|
||||
|
||||
|
||||
@ -160,12 +160,12 @@ Here is a list of CSPs supported on Windows 10 Enterprise:
|
||||
- [Maps CSP](/windows/client-management/mdm/maps-csp)
|
||||
- [NAP CSP](/windows/client-management/mdm/filesystem-csp)
|
||||
- [NAPDEF CSP](/windows/client-management/mdm/napdef-csp)
|
||||
- [NodeCache CSP]( https://go.microsoft.com/fwlink/p/?LinkId=723265)
|
||||
- [NodeCache CSP](https://go.microsoft.com/fwlink/p/?LinkId=723265)
|
||||
- [PassportForWork CSP](/windows/client-management/mdm/passportforwork-csp)
|
||||
- [Policy CSP](/windows/client-management/mdm/policy-configuration-service-provider)
|
||||
- [PolicyManager CSP]( https://go.microsoft.com/fwlink/p/?LinkId=723418)
|
||||
- [PolicyManager CSP](https://go.microsoft.com/fwlink/p/?LinkId=723418)
|
||||
- [Provisioning CSP](/windows/client-management/mdm/provisioning-csp)
|
||||
- [Proxy CSP]( https://go.microsoft.com/fwlink/p/?LinkId=723372)
|
||||
- [Proxy CSP](https://go.microsoft.com/fwlink/p/?LinkId=723372)
|
||||
- [PXLOGICAL CSP](/windows/client-management/mdm/pxlogical-csp)
|
||||
- [Registry CSP](/windows/client-management/mdm/registry-csp)
|
||||
- [RemoteFind CSP](/windows/client-management/mdm/remotefind-csp)
|
||||
|
||||
@ -86,7 +86,7 @@ If you create an issue for something not related to documentation, Microsoft wil
|
||||
- [Product questions (using Microsoft Q&A)](/answers/products/)
|
||||
- [Support requests](#open-a-microsoft-support-case) for Update Compliance
|
||||
|
||||
To share feedback on the fundamental docs.microsoft.com platform, see [Docs feedback](https://aka.ms/sitefeedback). The platform includes all of the wrapper components such as the header, table of contents, and right menu. Also how the articles render in the browser, such as the font, alert boxes, and page anchors.
|
||||
To share feedback about the Microsoft Docs platform, see [Microsoft Docs feedback](https://aka.ms/sitefeedback). The platform includes all of the wrapper components such as the header, table of contents, and right menu. Also how the articles render in the browser, such as the font, alert boxes, and page anchors.
|
||||
|
||||
## Troubleshooting tips
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Device registration overview
|
||||
description: This article provides and overview on how to register devices in Autopatch
|
||||
ms.date: 07/28/2022
|
||||
ms.date: 09/07/2022
|
||||
ms.prod: w11
|
||||
ms.technology: windows
|
||||
ms.topic: conceptual
|
||||
@ -44,12 +44,12 @@ See the following detailed workflow diagram. The diagram covers the Windows Auto
|
||||
| **Step 1: Identify devices** | IT admin identifies devices to be managed by the Windows Autopatch service. |
|
||||
| **Step 2: Add devices** | IT admin adds devices through direct membership or nests other Azure AD assigned or dynamic groups into the **Windows Autopatch Device Registration** Azure AD assigned group. |
|
||||
| **Step 3: Discover devices** | The Windows Autopatch Discover Devices function hourly discovers devices previously added by the IT admin into the **Windows Autopatch Device Registration** Azure AD assigned group in **step #2**. The Azure AD device ID is used by Windows Autopatch to query device attributes in both Microsoft Endpoint Manager-Intune and Azure AD when registering devices into its service.<ol><li>Once devices are discovered from the Azure AD group, the same function gathers additional device attributes and saves it into its memory during the discovery operation. The following device attributes are gathered from Azure AD in this step:</li><ol><li>**AzureADDeviceID**</li><li>**OperatingSystem**</li><li>**DisplayName (Device name)**</li><li>**AccountEnabled**</li><li>**RegistrationDateTime**</li><li>**ApproximateLastSignInDateTime**</li></ol><li>In this same step, the Windows Autopatch discover devices function calls another function, the device prerequisite check function. The device prerequisite check function evaluates software-based device-level prerequisites to comply with Windows Autopatch device readiness requirements prior to registration.</li></ol> |
|
||||
| **Step 4: Check prerequisites** | The Windows Autopatch prerequisite function makes an Intune Graph API call to sequentially validate device readiness attributes required for the registration process. For detailed information, see the [Detailed prerequisite check workflow diagram](#detailed-prerequisite-check-workflow-diagram) section. The service checks the following device readiness attributes, and/or prerequisites:<ol><li>**Serial number, model, and manufacturer.**</li><ol><li>Checks if the serial number already exists in the Windows Autopatch’s managed device database.</li></ol><li>**If the device is Intune-managed or not.**</li><ol><li>Windows Autopatch looks to see **if the Azure AD device ID has an Intune device ID associated with it**.</li><ol><li>If **yes**, it means this device is enrolled into Intune.</li><li>If **not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.</li></ol><li>**If the device is not managed by Intune**, the Windows Autopatch service can't gather device attributes such as operating system version, Intune enrollment date, device name and other attributes. When this happens, the Windows Autopatch service uses the Azure AD device attributes gathered and saved to its memory in **step 3a**.</li><ol><li>Once it has the device attributes gathered from Azure AD in **step 3a**, the device is flagged with the **Prerequisite failed** status, then added to the **Not ready** tab so the IT admin can review the reason(s) the device wasn't registered into Windows Autopatch. The IT admin will remediate these devices. In this case, the IT admin should check why the device wasn’t enrolled into Intune.</li><li>A common reason is when the Azure AD device ID is stale, it doesn’t have an Intune device ID associated with it anymore. To remediate, [clean up any stale Azure AD device records from your tenant](windows-autopatch-register-devices.md#clean-up-dual-state-of-hybrid-azure-ad-joined-and-azure-registered-devices-in-your-azure-ad-tenant).</li></ol><li>**If the device is managed by Intune**, the Windows Autopatch prerequisite check function continues to the next prerequisite check, which evaluates whether the device has checked into Intune in the last 28 days.</li></ol><li>**If the device is a Windows device or not.**</li><ol><li>Windows Autopatch looks to see if the Azure AD device ID has an Intune device ID associated with it.</li><ol><li>**If yes**, it means this device is enrolled into Intune.</li><li>**If not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.</li></ol></ol><li>**Windows Autopatch checks the Windows SKU family**. The SKU must be either:</li><ol><li>**Enterprise**</li><li>**Pro**</li><li>**Pro Workstation**</li></ol><li>**If the device meets the operating system requirements**, Windows Autopatch checks whether the device is either:</li><ol><li>**Only managed by Intune.**</li><ol><li>If the device is only managed by Intune, the device is marked as Passed all prerequisites.</li></ol><li>**Co-managed by both Configuration Manager and Intune.**</li><ol><li>If the device is co-managed by both Configuration Manager and Intune, an additional prerequisite check is evaluated to determine if the device satisfies the co-management-enabled workloads required by Windows Autopatch to manage devices in a co-managed state. The required co-management workloads evaluated in this step are:</li><ol><li>**Windows Updates Policies**</li><li>**Device Configuration**</li><li>**Office Click to Run**</li></ol><li>If Windows Autopatch determines that one of these workloads isn’t enabled on the device, the service marks the device as **Prerequisite failed** and moves the device to the **Not Ready** tab.</li></ol></ol></ol>|
|
||||
| **Step 4: Check prerequisites** | The Windows Autopatch prerequisite function makes an Intune Graph API call to sequentially validate device readiness attributes required for the registration process. For detailed information, see the [Detailed prerequisite check workflow diagram](#detailed-prerequisite-check-workflow-diagram) section. The service checks the following device readiness attributes, and/or prerequisites:<ol><li>**Serial number, model, and manufacturer.**</li><ol><li>Checks if the serial number already exists in the Windows Autopatch’s managed device database.</li></ol><li>**If the device is Intune-managed or not.**</li><ol><li>Windows Autopatch looks to see **if the Azure AD device ID has an Intune device ID associated with it**.</li><ol><li>If **yes**, it means this device is enrolled into Intune.</li><li>If **not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.</li></ol><li>**If the device is not managed by Intune**, the Windows Autopatch service can't gather device attributes such as operating system version, Intune enrollment date, device name and other attributes. When this happens, the Windows Autopatch service uses the Azure AD device attributes gathered and saved to its memory in **step 3a**.</li><ol><li>Once it has the device attributes gathered from Azure AD in **step 3a**, the device is flagged with the **Prerequisite failed** status, then added to the **Not registered** tab so the IT admin can review the reason(s) the device wasn't registered into Windows Autopatch. The IT admin will remediate these devices. In this case, the IT admin should check why the device wasn’t enrolled into Intune.</li><li>A common reason is when the Azure AD device ID is stale, it doesn’t have an Intune device ID associated with it anymore. To remediate, [clean up any stale Azure AD device records from your tenant](windows-autopatch-register-devices.md#clean-up-dual-state-of-hybrid-azure-ad-joined-and-azure-registered-devices-in-your-azure-ad-tenant).</li></ol><li>**If the device is managed by Intune**, the Windows Autopatch prerequisite check function continues to the next prerequisite check, which evaluates whether the device has checked into Intune in the last 28 days.</li></ol><li>**If the device is a Windows device or not.**</li><ol><li>Windows Autopatch looks to see if the Azure AD device ID has an Intune device ID associated with it.</li><ol><li>**If yes**, it means this device is enrolled into Intune.</li><li>**If not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.</li></ol></ol><li>**Windows Autopatch checks the Windows SKU family**. The SKU must be either:</li><ol><li>**Enterprise**</li><li>**Pro**</li><li>**Pro Workstation**</li></ol><li>**If the device meets the operating system requirements**, Windows Autopatch checks whether the device is either:</li><ol><li>**Only managed by Intune.**</li><ol><li>If the device is only managed by Intune, the device is marked as Passed all prerequisites.</li></ol><li>**Co-managed by both Configuration Manager and Intune.**</li><ol><li>If the device is co-managed by both Configuration Manager and Intune, an additional prerequisite check is evaluated to determine if the device satisfies the co-management-enabled workloads required by Windows Autopatch to manage devices in a co-managed state. The required co-management workloads evaluated in this step are:</li><ol><li>**Windows Updates Policies**</li><li>**Device Configuration**</li><li>**Office Click to Run**</li></ol><li>If Windows Autopatch determines that one of these workloads isn’t enabled on the device, the service marks the device as **Prerequisite failed** and moves the device to the **Not registered** tab.</li></ol></ol></ol>|
|
||||
| **Step 5: Calculate deployment ring assignment** | Once the device passes all prerequisites described in **step #4**, Windows Autopatch starts its deployment ring assignment calculation. The following logic is used to calculate the Windows Autopatch deployment ring assignment:<ol><li>If the Windows Autopatch tenant’s existing managed device size is **≤ 200**, the deployment ring assignment is **First (5%)**, **Fast (15%)**, remaining devices go to the **Broad ring (80%)**.</li><li>If the Windows Autopatch tenant’s existing managed device size is **>200**, the deployment ring assignment will be **First (1%)**, **Fast (9%)**, remaining devices go to the **Broad ring (90%)**.</li></ol> |
|
||||
| **Step 6: Assign devices to a deployment ring group** | Once the deployment ring calculation is done, Windows Autopatch assigns devices to one of the following deployment ring groups:<ol><li>**Modern Workplace Devices-Windows Autopatch-First**</li><ol><li>The Windows Autopatch device registration process doesn’t automatically assign devices to the Test ring represented by the Azure AD group (Modern Workplace Devices-Windows Autopatch-Test). It’s important that you assign devices to the Test ring to validate the update deployments before the updates are deployed to a broader population of devices.</li></ol><li>**Modern Workplace Devices-Windows Autopatch-Fast**</li><li>**Modern Workplace Devices-Windows Autopatch-Broad**</li></ol> |
|
||||
| **Step 7: Assign devices to an Azure AD group** | Windows Autopatch also assigns devices to the following Azure AD groups when certain conditions apply:<ol><li>**Modern Workplace Devices - All**</li><ol><li>This group has all devices managed by Windows Autopatch.</li></ol><li>When registering **Windows 10 devices**, use **Modern Workplace Devices Dynamic - Windows 10**</li><ol><li>This group has all devices managed by Windows Autopatch and that have Windows 10 installed.</li></ol><li>When registering **Windows 11 devices**, use **Modern Workplace Devices Dynamic - Windows 11**</li><ol><li>This group has all devices managed by Windows Autopatch and that have Windows 11 installed.</li></ol><li>When registering **virtual devices**, use **Modern Workplace Devices - Virtual Machine**</li><ol><li>This group has all virtual devices managed by Windows Autopatch.</li></ol> |
|
||||
| **Step 8: Post-device registration** | In post-device registration, three actions occur:<ol><li>Windows Autopatch adds devices to its managed database.</li><li>Flags devices as **Active** in the **Ready** tab.</li><li>The Azure AD device ID of the device successfully registered is added into the Microsoft Cloud Managed Desktop Extension’s allowlist. Windows Autopatch installs the Microsoft Cloud Managed Desktop Extension agent once devices are registered, so the agent can communicate back to the Microsoft Cloud Managed Desktop Extension service.</li><ol><li>The agent is the **Modern Workplace - Autopatch Client setup** PowerShell script that was created during the Windows Autopatch tenant enrollment process. The script is executed once devices are successfully registered into the Windows Autopatch service.</li></ol> |
|
||||
| **Step 9: Review device registration status** | IT admins review the device registration status in both the **Ready** and **Not ready** tabs.<ol><li>If the device was **successfully registered**, the device shows up in the **Ready** tab.</li><li>If **not**, the device shows up in the **Not ready** tab.</li></ol> |
|
||||
| **Step 9: Review device registration status** | IT admins review the device registration status in both the **Ready** and **Not registered** tabs.<ol><li>If the device was **successfully registered**, the device shows up in the **Ready** tab.</li><li>If **not**, the device shows up in the **Not registered** tab.</li></ol> |
|
||||
| **Step 10: End of registration workflow** | This is the end of the Windows Autopatch device registration workflow. |
|
||||
|
||||
## Detailed prerequisite check workflow diagram
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Register your devices
|
||||
description: This article details how to register devices in Autopatch
|
||||
ms.date: 08/08/2022
|
||||
ms.date: 09/07/2022
|
||||
ms.prod: w11
|
||||
ms.technology: windows
|
||||
ms.topic: how-to
|
||||
@ -32,7 +32,7 @@ You must choose what devices to manage with Windows Autopatch by adding them to
|
||||
|
||||
- Direct membership
|
||||
- Nesting other Azure AD dynamic/assigned groups
|
||||
- Bulk operations – 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.
|
||||
|
||||
@ -84,14 +84,26 @@ To be eligible for Windows Autopatch management, devices must meet a minimum set
|
||||
|
||||
For more information, see [Windows Autopatch Prerequisites](../prepare/windows-autopatch-prerequisites.md).
|
||||
|
||||
## About the Ready and Not ready tabs
|
||||
## About the Ready, Not ready and Not registered tabs
|
||||
|
||||
Windows Autopatch introduces a new user interface to help IT admins detect and troubleshoot device readiness statuses seamlessly with actionable in-UI device readiness reports for unregistered devices or unhealthy devices.
|
||||
Windows Autopatch has three tabs within its device blade. Each tab is designed to provide a different set of device readiness status so IT admin knows where to go to monitor, and troubleshoot potential device health issues.
|
||||
|
||||
| Tab | Purpose |
|
||||
| ----- | ----- |
|
||||
| Ready | The purpose of the Ready tab is to show devices that were successfully registered to the Windows Autopatch service. |
|
||||
| Not ready | The purpose of the Not ready tab is to help you identify and remediate devices that don't meet the pre-requisite checks to register into the Windows Autopatch service. This tab only shows devices that didn't successfully register into Windows Autopatch. |
|
||||
| Device blade tab | Purpose | Expected device readiness status |
|
||||
| ----- | ----- | ----- |
|
||||
| Ready | The purpose of this tab is to show devices that were successfully registered with the Windows Autopatch service. | Active |
|
||||
| Not ready | The purpose of this tab is to help you identify and remediate devices that failed to pass one or more post-device registration readiness checks. Devices showing up in this tab were successfully registered with Windows Autopatch. However, these devices aren't ready to have one or more software update workloads managed by the service. | Readiness failed and/or Inactive |
|
||||
| Not registered | The purpose of this tab is to help you identify and remediate devices that don't meet one or more prerequisite checks to successfully register with the Windows Autopatch service. | Pre-requisites failed |
|
||||
|
||||
## Device readiness statuses
|
||||
|
||||
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 |
|
||||
| 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 |
|
||||
|
||||
## Built-in roles required for device registration
|
||||
|
||||
@ -125,16 +137,16 @@ Since existing Windows 365 Cloud PCs already have an existing Azure AD device ID
|
||||
1. Go to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/).
|
||||
2. Select **Devices** from the left navigation menu.
|
||||
3. Under the **Windows Autopatch** section, select **Devices**.
|
||||
4. Select either the **Ready** or the **Not ready** tab, then select the **Windows Autopatch Device Registration** hyperlink. The Azure Active Directory group blade opens.
|
||||
4. Select either the **Ready** or the **Not registered** tab, then select the **Windows Autopatch Device Registration** hyperlink. The Azure Active Directory group blade opens.
|
||||
5. Add either devices through direct membership, or other Azure AD dynamic or assigned groups as nested groups in the **Windows Autopatch Device Registration** group.
|
||||
|
||||
> [!NOTE]
|
||||
> The **Windows Autopatch Device Registration** hyperlink is in the center of the Ready tab when there's no devices registered with the Windows Autopatch service. Once you have one or more devices registered with the Windows Autopatch service, the **Windows Autopatch Device registration** hyperlink is at the top of both **Ready** and **Not ready** tabs.
|
||||
> The **Windows Autopatch Device Registration** hyperlink is in the center of the Ready tab when there's no devices registered with the Windows Autopatch service. Once you have one or more devices registered with the Windows Autopatch service, the **Windows Autopatch Device registration** hyperlink is at the top of both **Ready** and **Not registered** tabs.
|
||||
|
||||
Once devices or other Azure AD groups (either dynamic or assigned) containing devices are added to the **Windows Autopatch Device Registration** group, Windows Autopatch's device discovery hourly function discovers these devices, and runs software-based prerequisite checks to try to register them with its service.
|
||||
|
||||
> [!TIP]
|
||||
> You can also use the **Discover Devices** button in either the **Ready** or **Not ready** tab to discover devices from the **Windows Autopatch Device Registration** Azure AD group on demand.
|
||||
> You can also use the **Discover Devices** button in either one of the **Ready**, **Not ready**, or **Not registered** device blade tabs to discover devices from the **Windows Autopatch Device Registration** Azure AD group on demand. On demand means you don't have to wait for Windows Autopatch to discover devices from the Azure AD group on your behalf.
|
||||
|
||||
### Windows Autopatch on Windows 365 Enterprise Workloads
|
||||
|
||||
|
||||
@ -51,7 +51,7 @@ sections:
|
||||
- [Switch workloads for device configuration, Windows Update and Microsoft 365 Apps from Configuration Manager to Intune](/mem/configmgr/comanage/how-to-switch-workloads) (minimum Pilot Intune. Pilot collection must contain the devices you want to register into Autopatch.)
|
||||
- question: What are the licensing requirements for Windows Autopatch?
|
||||
answer: |
|
||||
- Windows Autopatch is included with Window 10/11 Enterprise E3 or higher. For more information, see [More about licenses](../prepare/windows-autopatch-prerequisites.md#more-about-licenses).
|
||||
- Windows Autopatch is included with Window 10/11 Enterprise E3 or higher (user-based only). For more information, see [More about licenses](../prepare/windows-autopatch-prerequisites.md#more-about-licenses).
|
||||
- [Azure AD Premium](/azure/active-directory/fundamentals/active-directory-whatis#what-are-the-azure-ad-licenses) (for Co-management)
|
||||
- [Microsoft Intune](/mem/intune/fundamentals/licenses) (includes Configuration Manager 2010 or greater via co-management)
|
||||
- question: Are there hardware requirements for Windows Autopatch?
|
||||
@ -76,12 +76,13 @@ sections:
|
||||
- question: What systems does Windows Autopatch update?
|
||||
answer: |
|
||||
- Windows 10/11 quality updates: Windows Autopatch manages all aspects of update rings.
|
||||
- Windows 10/11 feature updates: Windows Autopatch manages all aspects of update rings.
|
||||
- Microsoft 365 Apps for enterprise updates: All devices registered for Windows Autopatch will receive updates from the Monthly Enterprise Channel.
|
||||
- Microsoft Edge: Windows Autopatch configures eligible devices to benefit from Microsoft Edge's progressive rollouts on the Stable channel and will provide support for issues with Microsoft Edge updates.
|
||||
- Microsoft Teams: Windows Autopatch allows eligible devices to benefit from the standard automatic update channels and will provide support for issues with Teams updates.
|
||||
- question: What does Windows Autopatch do to ensure updates are done successfully?
|
||||
answer: |
|
||||
For Windows quality updates, updates are applied to device in the Test ring first. The devices are evaluated, and then rolled out to the First, Fast then Broad rings. There's an evaluation period at each progression. This process is dependent on customer testing and verification of all updates during these rollout stages. The outcome is to ensure that registered devices are always up to date and disruption to business operations is minimized to free up your IT department from that ongoing task.
|
||||
For Windows quality updates, updates are applied to devices in the Test ring first. The devices are evaluated, and then rolled out to the First, Fast then Broad rings. There's an evaluation period at each progression. This process is dependent on customer testing and verification of all updates during these rollout stages. The outcome is to ensure that registered devices are always up to date and disruption to business operations is minimized to free up your IT department from that ongoing task.
|
||||
- question: What happens if there's an issue with an update?
|
||||
answer: |
|
||||
Autopatch relies on the following capabilities to help resolve update issues:
|
||||
|
||||
@ -45,17 +45,17 @@ productDirectory:
|
||||
# Card
|
||||
- title: Windows 11 required diagnostic data
|
||||
# imageSrc should be square in ratio with no whitespace
|
||||
imageSrc: https://docs.microsoft.com/media/common/i_extend.svg
|
||||
imageSrc: /media/common/i_extend.svg
|
||||
summary: Learn more about basic Windows diagnostic data events and fields collected.
|
||||
url: required-windows-11-diagnostic-events-and-fields.md
|
||||
# Card
|
||||
- title: Windows 10 required diagnostic data
|
||||
imageSrc: https://docs.microsoft.com/media/common/i_build.svg
|
||||
imageSrc: /media/common/i_build.svg
|
||||
summary: See what changes Windows is making to align to the new data collection taxonomy
|
||||
url: required-windows-diagnostic-data-events-and-fields-2004.md
|
||||
# Card
|
||||
- title: Optional diagnostic data
|
||||
imageSrc: https://docs.microsoft.com/media/common/i_get-started.svg
|
||||
imageSrc: /media/common/i_get-started.svg
|
||||
summary: Get examples of the types of optional diagnostic data collected from Windows
|
||||
url: windows-diagnostic-data.md
|
||||
|
||||
@ -181,4 +181,4 @@ additionalContent:
|
||||
- text: Support for GDPR Accountability on Service Trust Portal
|
||||
url: https://servicetrust.microsoft.com/ViewPage/GDPRGetStarted
|
||||
# footer (optional)
|
||||
# footer: "footertext [linktext](/footerfile)"
|
||||
# footer: "footertext [linktext](/footerfile)"
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user