diff --git a/windows/deployment/windows-autopatch/deploy/windows-autopatch-admin-contacts.md b/windows/deployment/windows-autopatch/deploy/windows-autopatch-admin-contacts.md index 4e13034d35..d3cf70f023 100644 --- a/windows/deployment/windows-autopatch/deploy/windows-autopatch-admin-contacts.md +++ b/windows/deployment/windows-autopatch/deploy/windows-autopatch-admin-contacts.md @@ -35,7 +35,7 @@ Your admin contacts will receive notifications about support request updates and **To add admin contacts:** -1. Sign into [Microsoft Endpoint Manager](https://endpoint.microsoft.com/). +1. Sign into the [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431). 1. Under **Tenant administration** in the **Windows Autopatch** section, select **Admin contacts**. 1. Select **+Add**. 1. Enter the contact details including name, email, phone number and preferred language. For a support ticket, the ticket's primary contact's preferred language will determine the language used for email communications. diff --git a/windows/deployment/windows-autopatch/deploy/windows-autopatch-device-registration-overview.md b/windows/deployment/windows-autopatch/deploy/windows-autopatch-device-registration-overview.md index 10d9c81172..d1e52e4ced 100644 --- a/windows/deployment/windows-autopatch/deploy/windows-autopatch-device-registration-overview.md +++ b/windows/deployment/windows-autopatch/deploy/windows-autopatch-device-registration-overview.md @@ -44,7 +44,7 @@ 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.
  1. 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:
    1. **AzureADDeviceID**
    2. **OperatingSystem**
    3. **DisplayName (Device name)**
    4. **AccountEnabled**
    5. **RegistrationDateTime**
    6. **ApproximateLastSignInDateTime**
  2. 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.
| +| **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 Intune and Azure AD when registering devices into its service.
  1. 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:
    1. **AzureADDeviceID**
    2. **OperatingSystem**
    3. **DisplayName (Device name)**
    4. **AccountEnabled**
    5. **RegistrationDateTime**
    6. **ApproximateLastSignInDateTime**
  2. 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.
| | **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:
  1. **Serial number, model, and manufacturer.**
    1. Checks if the serial number already exists in the Windows Autopatch’s managed device database.
  2. **If the device is Intune-managed or not.**
    1. Windows Autopatch looks to see **if the Azure AD device ID has an Intune device ID associated with it**.
      1. If **yes**, it means this device is enrolled into Intune.
      2. If **not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.
    2. **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**.
      1. 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.
      2. 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).
    3. **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.
  3. **If the device is a Windows device or not.**
    1. Windows Autopatch looks to see if the device is a Windows and corporate-owned device.
      1. **If yes**, it means this device can be registered with the service because it's a Windows corporate-owned device.
      2. **If not**, it means the device is a non-Windows device, or it's a Windows device but it's a personal device.
  4. **Windows Autopatch checks the Windows SKU family**. The SKU must be either:
    1. **Enterprise**
    2. **Pro**
    3. **Pro Workstation**
  5. **If the device meets the operating system requirements**, Windows Autopatch checks whether the device is either:
    1. **Only managed by Intune.**
      1. If the device is only managed by Intune, the device is marked as Passed all prerequisites.
    2. **Co-managed by both Configuration Manager and Intune.**
      1. 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:
        1. **Windows Updates Policies**
        2. **Device Configuration**
        3. **Office Click to Run**
      2. 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.
| | **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:
  1. 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%)**.
  2. 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%)**.
| | **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:
  1. **Modern Workplace Devices-Windows Autopatch-First**
    1. 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.
  2. **Modern Workplace Devices-Windows Autopatch-Fast**
  3. **Modern Workplace Devices-Windows Autopatch-Broad**
| 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 e5c4617772..985c852e6f 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 @@ -49,7 +49,7 @@ Windows Autopatch has three tabs within its Devices blade. Each tab is designed | Tab | Description | | ----- | ----- | | Ready | This tab only lists devices with the **Active** status. Devices with the **Active** status successfully:This tab also lists devices that have passed all postdevice registration readiness checks. | -| Not ready | This tab only lists devices with the **Readiness failed** and **Inactive** status. | +| 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. | ## Details about the post-device registration readiness checks @@ -67,9 +67,9 @@ The following list of post-device registration readiness checks is performed in | Check | Description | | ----- | ----- | | **Windows OS build, architecture, and edition** | Checks to see if devices support Windows 1809+ build (10.0.17763), 64-bit architecture and either Pro or Enterprise SKUs. | -| **Windows update policies managed via Microsoft Endpoint Manager-Intune** | Checks to see if devices have Windows Updates policies managed via Microsoft Endpoint Manager-Intune (MDM). | -| **Windows update policies managed via Group Policy Object (GPO)** | Checks to see if devices have Windows update policies managed via GPO. Windows Autopatch doesn’t support Windows update policies managed via GPOs. Windows update must be managed via Microsoft Endpoint Manager-Intune. | -| **Microsoft Office update policy managed via Group Policy Object (GPO)** | Checks to see if devices have Microsoft Office updates policies managed via GPO. Windows Autopatch doesn’t support Microsoft Office update policies managed via GPOs. Office updates must be managed via Microsoft Endpoint Manager-Intune or another Microsoft Office policy management method where Office update bits are downloaded directly from the Office Content Delivery Network (CDN). | +| **Windows update policies managed via Microsoft Intune** | Checks to see if devices have Windows Updates policies managed via Microsoft Intune (MDM). | +| **Windows update policies managed via Group Policy Object (GPO)** | Checks to see if devices have Windows update policies managed via GPO. Windows Autopatch doesn’t support Windows update policies managed via GPOs. Windows update must be managed via Microsoft Intune. | +| **Microsoft Office update policy managed via Group Policy Object (GPO)** | Checks to see if devices have Microsoft Office updates policies managed via GPO. Windows Autopatch doesn’t support Microsoft Office update policies managed via GPOs. Office updates must be managed via Microsoft Intune or another Microsoft Office policy management method where Office update bits are downloaded directly from the Office Content Delivery Network (CDN). | | **Windows Autopatch network endpoints** | There's a set of [network endpoints](../prepare/windows-autopatch-configure-network.md) that Windows Autopatch services must be able to reach for the various aspects of the Windows Autopatch service. | | **Microsoft Teams network endpoints** | There's a set of [network endpoints](../prepare/windows-autopatch-configure-network.md) that devices with Microsoft Teams must be able to reach for software updates management. | | **Microsoft Edge network endpoints** | There's a set of [network endpoints](../prepare/windows-autopatch-configure-network.md) that devices with Microsoft Edge must be able to reach for software updates management. | diff --git a/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md b/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md index 4d7fb522a0..eff03275a8 100644 --- a/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md +++ b/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md @@ -71,9 +71,9 @@ To be eligible for Windows Autopatch management, devices must meet a minimum set - Windows 10 (1809+)/11 Enterprise or Professional editions (only x64 architecture). - Either [Hybrid Azure AD-Joined](/azure/active-directory/devices/concept-azure-ad-join-hybrid) or [Azure AD-joined only](/azure/active-directory/devices/concept-azure-ad-join-hybrid) (personal devices aren't supported). -- Managed by Microsoft Endpoint Manager. +- Managed by Microsoft Intune. - [Already enrolled into Microsoft Intune](/mem/intune/user-help/enroll-windows-10-device) and/or [Configuration Manager co-management](/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites#configuration-manager-co-management-requirements). - - Must switch the following Microsoft Endpoint Manager-Configuration Manager [co-management workloads](/mem/configmgr/comanage/how-to-switch-workloads) to Microsoft Endpoint Manager-Intune (either set to Pilot Intune or Intune): + - Must switch the following Microsoft Configuration Manager [co-management workloads](/mem/configmgr/comanage/how-to-switch-workloads) to Microsoft Intune (either set to Pilot Intune or Intune): - Windows updates policies - Device configuration - Office Click-to-run @@ -102,7 +102,7 @@ See all possible device readiness statuses in Windows Autopatch: | ----- | ----- | ----- | | 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 | +| Inactive | Devices with this status haven't communicated with Microsoft 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 @@ -116,7 +116,7 @@ A role defines the set of permissions granted to users assigned to that role. Yo For more information, see [Azure AD built-in roles](/azure/active-directory/roles/permissions-reference) and [Role-based access control (RBAC) with Microsoft Intune](/mem/intune/fundamentals/role-based-access-control). > [!NOTE] -> The Modern Workplace Intune Admin role is a custom created role during the Windows Autopatch tenant enrollment process. This role can assign administrators to Endpoint Manager roles, and allows you to create and configure custom Endpoint Manager roles. +> The Modern Workplace Intune Admin role is a custom created role during the Windows Autopatch tenant enrollment process. This role can assign administrators to Intune roles, and allows you to create and configure custom Intune roles. ## Details about the device registration process @@ -134,7 +134,7 @@ Since existing Windows 365 Cloud PCs already have an existing Azure AD device ID **To register devices with Windows Autopatch:** -1. Go to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/). +1. Go to the [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431). 2. Select **Devices** from the left navigation menu. 3. Under the **Windows Autopatch** section, select **Devices**. 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. @@ -154,7 +154,7 @@ Windows 365 Enterprise gives IT admins the option to register devices with the W **To register new Windows 365 Cloud PC devices with Windows Autopatch from the Windows 365 Provisioning Policy:** -1. Go to the [Microsoft Endpoint Manager](https://endpoint.microsoft.com/) admin center. +1. Go to the [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431). 1. In the left pane, select **Devices**. 1. Navigate to Provisioning > **Windows 365**. 1. Select Provisioning policies > **Create policy**. @@ -211,7 +211,7 @@ There's a few more device management lifecycle scenarios to consider when planni ### Device refresh -If a device was previously registered into the Windows Autopatch service, but it needs to be reimaged, you must run one of the device provisioning processes available in Microsoft Endpoint Manager to reimage the device. +If a device was previously registered into the Windows Autopatch service, but it needs to be reimaged, you must run one of the device provisioning processes available in Microsoft Intune to reimage the device. The device will be rejoined to Azure AD (either Hybrid or Azure AD-only). Then, re-enrolled into Intune as well. No further action is required from you or the Windows Autopatch service, because the Azure AD device ID record of that device remains the same. diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-deregister-devices.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-deregister-devices.md index 52448ca4c5..15b45c91d4 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-deregister-devices.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-deregister-devices.md @@ -18,7 +18,7 @@ To avoid end-user disruption, device deregistration in Windows Autopatch only de **To deregister a device:** -1. Sign into the [Microsoft Endpoint Manager](https://endpoint.microsoft.com/). +1. Sign into the [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431). 1. Select **Windows Autopatch** in the left navigation menu. 1. Select **Devices**. 1. In either **Ready** or **Not ready** tab, select the device(s) you want to deregister. @@ -42,7 +42,7 @@ You can hide unregistered devices you don't expect to be remediated anytime soon **To hide unregistered devices:** -1. Sign into the [Microsoft Endpoint Manager](https://endpoint.microsoft.com/). +1. Sign into the [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431). 1. Select **Windows Autopatch** in the left navigation menu. 1. Select **Devices**. 1. In the **Not ready** tab, select an unregistered device or a group of unregistered devices you want to hide then select **Status == All**. diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-fu-overview.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-fu-overview.md index 244d0ad114..023003d400 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-fu-overview.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-fu-overview.md @@ -73,7 +73,7 @@ When releasing a feature update, there are two policies that are configured by t During a release, the service modifies the Modern Workplace DSS policy to change the target version for a specific ring in Intune. That change is deployed to devices and updates the devices prior to the update deadline. -To understand how devices will react to the change in the Modern Workplace DSS policy, it's important to understand how deferral, deadline, and grace periods effect devices. +To understand how devices will react to the change in the Modern Workplace DSS policy, it's important to understand how deferral, deadline, and grace periods affect devices. | Policy | Description | | ----- | ----- | @@ -93,7 +93,7 @@ To allow customers to test Windows 11 in their environment, there's a separate D ## Pausing and resuming a release -You can pause or resume a Windows feature update from the Release management tab in Microsoft Endpoint Manager. +You can pause or resume a Windows feature update from the Release management tab in the [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431). ## Rollback diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-microsoft-365-apps-enterprise.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-microsoft-365-apps-enterprise.md index 4386ab7205..3089035470 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-microsoft-365-apps-enterprise.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-microsoft-365-apps-enterprise.md @@ -85,7 +85,7 @@ Since quality updates are bundled together into a single release in the [Monthly [Servicing profiles](/deployoffice/admincenter/servicing-profile) is a feature in the [Microsoft 365 Apps admin center](https://config.office.com/) that provides controlled update management of monthly Office updates, including controls for user and device targeting, scheduling, rollback, and reporting. -A [service profile](/deployoffice/admincenter/servicing-profile#compatibility-with-other-management-tools) takes precedence over other management tools, such as Microsoft Endpoint Manager or the Office Deployment Tool. This means that the servicing profile will affect all devices that meet the [device eligibility requirements](#device-eligibility) regardless of existing management tools in your environment. So, if you're targeting a managed device with a servicing profile it will be ineligible for Microsoft 365 App update management. +A [service profile](/deployoffice/admincenter/servicing-profile#compatibility-with-other-management-tools) takes precedence over other policies, such as a Microsoft Intune policy or the Office Deployment Tool. This means that the servicing profile will affect all devices that meet the [device eligibility requirements](#device-eligibility) regardless of existing management tools in your environment. So, if you're targeting a managed device with a servicing profile it will be ineligible for Microsoft 365 App update management. However, the device may still be eligible for other managed updates. For more information about a device's eligibility for a given [software update workload](windows-autopatch-update-management.md#software-update-workloads), see the Device eligibility section of each respective software update workload. diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-support-request.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-support-request.md index a6b6ffc78b..ab63a52ddf 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-support-request.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-support-request.md @@ -25,7 +25,7 @@ Support requests are triaged and responded to as they're received. **To submit a new support request:** -1. Sign into [Microsoft Endpoint Manager](https://endpoint.microsoft.com/) and navigate to the **Tenant administration** menu. +1. Sign into the [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431) and navigate to the **Tenant administration** menu. 1. In the **Windows Autopatch** section, select **Support requests**. 1. In the **Support requests** section, select **+ New support request**. 1. Enter your question(s) and/or a description of the problem. @@ -42,7 +42,7 @@ You can see the summary status of all your support requests. At any time, you ca **To view all your active support requests:** -1. Sign into [Microsoft Endpoint Manager](https://endpoint.microsoft.com/) and navigate to the **Tenant Administration** menu. +1. Sign into the [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431) and navigate to the **Tenant Administration** menu. 1. In the **Windows Autopatch** section, select **Support request**. 1. From this view, you can export the summary view or select any case to view the details. @@ -52,7 +52,7 @@ You can edit support request details, for example, updating the primary case con **To edit support request details:** -1. Sign into [Microsoft Endpoint Manager](https://endpoint.microsoft.com/) and navigate to the **Tenant Administration** menu. +1. Sign into the [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431) and navigate to the **Tenant Administration** menu. 1. In the **Windows Autopatch** section, select **Support request**. 1. In the **Support requests** section, use the search bar or filters to find the case you want to edit. 1. Select the case to open the request's details. diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-unenroll-tenant.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-unenroll-tenant.md index a92c0fbdef..ec414612c4 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-unenroll-tenant.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-unenroll-tenant.md @@ -41,7 +41,7 @@ Unenrolling from Windows Autopatch requires manual actions from both you and fro | ----- | ----- | | Updates | After the Windows Autopatch service is unenrolled, we’ll no longer provide updates to your devices. You must ensure that your devices continue to receive updates through your own policies to ensure they're secure and up to date. | | Optional Windows Autopatch configuration | Windows Autopatch won’t remove the configuration policies or groups used to enable updates on your devices. You're responsible for these policies following tenant unenrollment. If you don’t wish to use these policies for your devices after unenrollment, you may safely delete them. For more information, see [Changes made at tenant enrollment](../references/windows-autopatch-changes-to-tenant.md). | -| Microsoft Endpoint Manager roles | After unenrollment, you may safely remove the Modern Workplace Intune Admin role. | +| Microsoft Intune roles | After unenrollment, you may safely remove the Modern Workplace Intune Admin role. | ## Unenroll from Windows Autopatch diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-update-management.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-update-management.md index c3548183a3..549d7d5bba 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-update-management.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-update-management.md @@ -64,7 +64,7 @@ The Windows Autopatch deployment ring calculation happens during the [device reg | Test | **zero** | Windows Autopatch doesn't automatically add devices to this deployment ring. You must manually add devices to the Test ring following the required procedure. For more information on these procedures, see [Moving devices in between deployment rings](/windows/deployment/windows-autopatch/operate/windows-autopatch-update-management#moving-devices-in-between-deployment-rings). The recommended number of devices in this ring, based upon your environment size, is as follows:
Devices in this group are intended for your IT Administrators and testers since changes are released here first. This release schedule provides your organization the opportunity to validate updates prior to reaching production users. | | First | **1%** | The First ring is the first group of production users to receive a change.

This group is the first set of devices to send data to Windows Autopatch and are used to generate a health signal across all end-users. For example, Windows Autopatch can generate a statistically significant signal saying that critical errors are trending up in a specific release for all end-users, but can't be confident that it's doing so in your organization.

Since Windows Autopatch doesn't yet have sufficient data to inform a release decision, devices in this deployment ring might experience outages if there are scenarios that weren't covered during early testing in the Test ring.| | Fast | **9%** | The Fast ring is the second group of production users to receive changes. The signals from the First ring are considered as a part of the release process to the Broad ring.

The goal with this deployment ring is to cross the **500**-device threshold needed to generate statistically significant analysis at the tenant level. These extra devices allow Windows Autopatch to consider the effect of a release on the rest of your devices and evaluate if a targeted action for your tenant is needed.

| -| Broad | Either **80%** or **90%** | The Broad ring is the last group of users to receive software update deployments. Since it contains most of the devices registered with Windows Autopatch, it favors stability over speed in an software update deployment.| +| Broad | Either **80%** or **90%** | The Broad ring is the last group of users to receive software update deployments. Since it contains most of the devices registered with Windows Autopatch, it favors stability over speed in a software update deployment.| ## Moving devices in between deployment rings @@ -72,7 +72,7 @@ If you want to move separate devices to different deployment rings, after Window **To move devices in between deployment rings:** -1. In Microsoft Endpoint Manager, select **Devices** in the left pane. +1. In the [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431), select **Devices** in the left pane. 2. In the **Windows Autopatch** section, select **Devices**. 3. In the **Ready** tab, select one or more devices you want to assign. All selected devices will be assigned to the deployment ring you specify. 4. Select **Device actions** from the menu. @@ -82,7 +82,7 @@ If you want to move separate devices to different deployment rings, after Window When the assignment is complete, the **Ring assigned by** column changes to **Admin** (which indicates that you made the change) and the **Ring** column shows the new deployment ring assignment. > [!NOTE] -> You can only move devices to other deployment rings when they're in an active state in the **Ready** tab.

If you don't see the **Ring assigned by column** change to **Pending** in Step 5, check to see whether the device exists in Microsoft Endpoint Manager-Intune or not by searching for it in its device blade. For more information, see [Device details in Intune](/mem/intune/remote-actions/device-inventory). +> You can only move devices to other deployment rings when they're in an active state in the **Ready** tab.

If you don't see the **Ring assigned by column** change to **Pending** in Step 5, check to see whether the device exists in Microsoft Intune or not by searching for it in its device blade. For more information, see [Device details in Intune](/mem/intune/remote-actions/device-inventory). > [!WARNING] > Moving devices between deployment rings through directly changing Azure AD group membership isn't supported and may cause unintended configuration conflicts within the Windows Autopatch service. To avoid service interruption to devices, use the **Assign device to ring** action described previously to move devices between deployment rings. diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-communications.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-communications.md index 5633916a46..ffb70992db 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-communications.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-communications.md @@ -34,7 +34,7 @@ Communications are posted to Message center, Service health dashboard, and the W ## Communications during release -The most common type of communication during a release is a customer advisory. Customer advisories are posted to both Message center and the Messages blade of the Microsoft Endpoint Manager portal shortly after Autopatch becomes aware of the new information. +The most common type of communication during a release is a customer advisory. Customer advisories are posted to both Message center and the Messages blade of the [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431) shortly after Autopatch becomes aware of the new information. There are some circumstances where Autopatch will need to change the release schedule based on new information. diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-overview.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-overview.md index b4fc0d3673..d922d4a3cc 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-overview.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-overview.md @@ -72,7 +72,7 @@ If Windows Autopatch detects a [significant issue with a release](../operate/win If we pause the release, a policy will be deployed which prevents devices from updating while the issue is investigated. Once the issue is resolved, the release will be resumed. -You can pause or resume a Windows quality update from the Release management tab in Microsoft Endpoint Manager. +You can pause or resume a Windows quality update from the Release management tab in the [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431). ## Incidents and outages diff --git a/windows/deployment/windows-autopatch/prepare/windows-autopatch-enroll-tenant.md b/windows/deployment/windows-autopatch/prepare/windows-autopatch-enroll-tenant.md index 140d728afa..2616f22559 100644 --- a/windows/deployment/windows-autopatch/prepare/windows-autopatch-enroll-tenant.md +++ b/windows/deployment/windows-autopatch/prepare/windows-autopatch-enroll-tenant.md @@ -30,14 +30,14 @@ To start using the Windows Autopatch service, ensure you meet the [Windows Autop > [!IMPORTANT] > The online Readiness assessment tool helps you check your readiness to enroll in Windows Autopatch for the first time. Once you enroll, you'll no longer be able to access the tool again. -The Readiness assessment tool checks the settings in [Microsoft Endpoint Manager](#microsoft-intune-settings) (specifically, Microsoft Intune) and [Azure Active Directory](#azure-active-directory-settings) (Azure AD) to ensure they'll work with Windows Autopatch. We aren't, however, checking the workloads in Configuration Manager necessary for Windows Autopatch. For more information about workload prerequisites, see [Configuration Manager co-management requirements](../prepare/windows-autopatch-prerequisites.md#configuration-manager-co-management-requirements). +The Readiness assessment tool checks the settings in [Microsoft Intune](#microsoft-intune-settings) and [Azure Active Directory](#azure-active-directory-settings) (Azure AD) to ensure they'll work with Windows Autopatch. We aren't, however, checking the workloads in Configuration Manager necessary for Windows Autopatch. For more information about workload prerequisites, see [Configuration Manager co-management requirements](../prepare/windows-autopatch-prerequisites.md#configuration-manager-co-management-requirements). **To access and run the Readiness assessment tool:** > [!IMPORTANT] > You must be a Global Administrator to run the Readiness assessment tool. -1. Go to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/). +1. Go to the [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431). 2. In the left pane, select Tenant administration and then navigate to Windows Autopatch > **Tenant enrollment**. > [!IMPORTANT] diff --git a/windows/deployment/windows-autopatch/prepare/windows-autopatch-fix-issues.md b/windows/deployment/windows-autopatch/prepare/windows-autopatch-fix-issues.md index 77a8ae20a5..4b87f046dd 100644 --- a/windows/deployment/windows-autopatch/prepare/windows-autopatch-fix-issues.md +++ b/windows/deployment/windows-autopatch/prepare/windows-autopatch-fix-issues.md @@ -32,7 +32,7 @@ For each check, the tool will report one of four possible results: ## Microsoft Intune settings -You can access Intune settings at the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/). +You can access Intune settings at the [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431). ### Unlicensed admins diff --git a/windows/deployment/windows-autopatch/references/windows-autopatch-privacy.md b/windows/deployment/windows-autopatch/references/windows-autopatch-privacy.md index 49f08db4a3..c5163c949a 100644 --- a/windows/deployment/windows-autopatch/references/windows-autopatch-privacy.md +++ b/windows/deployment/windows-autopatch/references/windows-autopatch-privacy.md @@ -26,7 +26,7 @@ The sources include Azure Active Directory (Azure AD), Microsoft Intune, and Mic | ------ | ------ | | [Microsoft Windows 10/11 Enterprise](/windows/windows-10/) | Management of device setup experience, managing connections to other services, and operational support for IT pros. | | [Windows Update for Business](/windows/deployment/update/waas-manage-updates-wufb) | Uses Windows 10 Enterprise diagnostic data to provide additional information on Windows 10/11 update. | -| [Microsoft Endpoint Manager](/mem/endpoint-manager-overview) | Device management and to keep your data secure. The following data sources fall under Microsoft Endpoint Manager:

+| [Microsoft Intune](/mem/intune/fundamentals/what-is-intune) | Device management and to keep your data secure. The following endpoint management data sources are used:
| [Windows Autopatch](https://endpoint.microsoft.com/#home) | Data provided by the customer or generated by the service during running of the service. | | [Microsoft 365 Apps for enterprise](https://www.microsoft.com/microsoft-365/enterprise/compare-office-365-plans)| Management of Microsoft 365 Apps. | diff --git a/windows/deployment/windows-autopilot/demonstrate-deployment-on-vm.md b/windows/deployment/windows-autopilot/demonstrate-deployment-on-vm.md index a5a019d47b..14d1e1698a 100644 --- a/windows/deployment/windows-autopilot/demonstrate-deployment-on-vm.md +++ b/windows/deployment/windows-autopilot/demonstrate-deployment-on-vm.md @@ -86,7 +86,7 @@ If you already have Hyper-V and a Windows 10 VM, you can skip directly to the [C - [Create app in Intune](#create-app-in-intune) - [Assign the app to your Intune profile](#assign-the-app-to-your-intune-profile) - [Add Microsoft 365 Apps](#add-microsoft-365-apps) - - [Create app in Microsoft Endpoint Manager](#create-app-in-microsoft-endpoint-manager) + - [Create app in Microsoft Intune](#create-app-in-microsoft-intune) - [Assign the app to your Intune profile](#assign-the-app-to-your-intune-profile-1) - [Glossary](#glossary) @@ -398,7 +398,7 @@ Your VM (or device) can be registered either via Intune or Microsoft Store for B ### Autopilot registration using Intune -1. In the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/), choose **Devices** > **Device enrollment | Enroll devices** > **Windows enrollment** > **Windows Autopilot Deployment Program | Devices** and then on the **Windows Autopilot devices** page, choose **Import**. +1. In the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431), choose **Devices** > **Device enrollment | Enroll devices** > **Windows enrollment** > **Windows Autopilot Deployment Program | Devices** and then on the **Windows Autopilot devices** page, choose **Import**. ![Intune device import.](images/enroll1.png) @@ -603,7 +603,7 @@ To use the device (or VM) for other purposes after completion of this lab, you n ### Delete (deregister) Autopilot device -You need to delete (or retire, or factory reset) the device from Intune before deregistering the device from Autopilot. To delete the device from Intune (not Azure AD), log into the Microsoft Endpoint Manager admin center, then go to **Intune > Devices > All Devices**. Select the device you want to delete, then select the **Delete** button along the top menu. +You need to delete (or retire, or factory reset) the device from Intune before deregistering the device from Autopilot. To delete the device from Intune (not Azure AD), sign into the [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431), then go to **Devices > All Devices**. Select the device you want to delete, then select the **Delete** button along the top menu. > [!div class="mx-imgBorder"] > ![Delete device step 1.](images/delete-device1.png) @@ -805,7 +805,7 @@ For more information on adding apps to Intune, see [Intune Standalone - Win32 ap ### Add Microsoft 365 Apps -#### Create app in Microsoft Endpoint Manager +#### Create app in Microsoft Intune Sign in to the Azure portal and select **Intune**. diff --git a/windows/hub/index.yml b/windows/hub/index.yml index 0794c284fd..7e8837ad3c 100644 --- a/windows/hub/index.yml +++ b/windows/hub/index.yml @@ -230,19 +230,17 @@ additionalContent: - title: Other resources items: - - title: Microsoft Endpoint Manager + - title: Microsoft endpoint management with Intune links: - - text: Microsoft Endpoint Manager documentation - url: /mem - - text: Overview of Microsoft Endpoint Manager + - text: Intune is a family of products url: /mem/endpoint-manager-overview - - text: Getting started with Microsoft Endpoint Manager - url: /mem/endpoint-manager-getting-started + - text: What is Microsoft Intune? + url: /mem/what-is-intune - text: Microsoft Endpoint Manager simplifies upgrades to Windows 11 url: https://techcommunity.microsoft.com/t5/microsoft-endpoint-manager-blog/endpoint-manager-simplifies-upgrades-to-windows-11/ba-p/2771886 - text: Understanding readiness for Windows 11 with Microsoft Endpoint Manager url: https://techcommunity.microsoft.com/t5/microsoft-endpoint-manager-blog/understanding-readiness-for-windows-11-with-microsoft-endpoint/ba-p/2770866 - - text: Microsoft Endpoint Manager blog + - text: Microsoft endpoint management blog url: https://aka.ms/memblog - title: Windows 365 links: diff --git a/windows/privacy/changes-to-windows-diagnostic-data-collection.md b/windows/privacy/changes-to-windows-diagnostic-data-collection.md index 13b8872c26..48eab123cc 100644 --- a/windows/privacy/changes-to-windows-diagnostic-data-collection.md +++ b/windows/privacy/changes-to-windows-diagnostic-data-collection.md @@ -17,7 +17,7 @@ ms.topic: conceptual - Windows 10, version 1903 and later - Windows Server 2022 -Microsoft is committed to providing you with effective controls over your data and ongoing transparency into our data handling practices. As part of this effort, we have moved our major products and services to a model where data sent back to Microsoft from customer devices will be classified as either **Required** or **Optional**. We believe this will provide our customers with a simpler experience – information should be easier to find, easier to understand, and easier to act upon through the tools we provide. +Microsoft is committed to providing you with effective controls over your data and ongoing transparency into our data handling practices. As part of this effort, we've moved our major products and services to a model where data sent back to Microsoft from customer devices will be classified as either **Required** or **Optional**. We believe this change will provide our customers with a simpler experience – information should be easier to find, easier to understand, and easier to act upon through the tools we provide. This article is meant for IT administrators and explains the changes Windows is making to align to the new data collection taxonomy. These changes are focused in two areas: @@ -26,7 +26,7 @@ This article is meant for IT administrators and explains the changes Windows is ## Summary of changes -In Windows 10, version 1903 and later, you will see taxonomy updates in both the **Out-of-box-experience** (OOBE) and the **Diagnostics & feedback** privacy settings page. These changes are explained in the section named **Taxonomy** changes. +In Windows 10, version 1903 and later, you'll see taxonomy updates in both the **Out-of-box-experience** (OOBE) and the **Diagnostics & feedback** privacy settings page. These changes are explained in the section named **Taxonomy** changes. Additionally, starting in Windows 11 and Windows Server 2022, we’re simplifying your diagnostic data controls by moving from four diagnostic data controls to three: **Diagnostic data off**, **Required**, and **Optional**. We’re also clarifying the Security diagnostic data level to reflect its behavior more accurately by changing it to **Diagnostic data off**. All these changes are explained in the section named **Behavioral changes**. @@ -42,9 +42,9 @@ Starting in Windows 10, version 1903 and later, both the **Out-of-Box-Experience ## Behavioral changes -Starting in Windows 11 and Windows Server 2022, we’re simplifying the Windows diagnostic data controls by moving from four diagnostic data settings to three: **Diagnostic data off**, **Required**, and **Optional**. If your devices are set to **Enhanced** when they are upgraded to a supported version of the operating system, the device settings will be evaluated to be at the more privacy-preserving setting of **Required diagnostic data**, which means that analytic services that leverage enhanced data collection may not work properly. For a list of services, see [Services that rely on Enhanced diagnostic data](#services-that-rely-on-enhanced-diagnostic-data). Administrators should read through the details and determine whether to apply these new policies to restore the same collection settings as they had before this change. +Starting in Windows 11 and Windows Server 2022, we’re simplifying the Windows diagnostic data controls by moving from four diagnostic data settings to three: **Diagnostic data off**, **Required**, and **Optional**. If your devices are set to **Enhanced** when they're upgraded to a supported version of the operating system, the device settings will be evaluated to be at the more privacy-preserving setting of **Required diagnostic data**, which means that analytic services that use enhanced data collection may not work properly. For a list of services, see [Services that rely on Enhanced diagnostic data](#services-that-rely-on-enhanced-diagnostic-data). Administrators should read through the details and determine whether to apply these new policies to restore the same collection settings as they had before this change. -Additionally, you will see the following policy changes in Windows Server 2022, Windows 11, and Windows Holographic, version 21H1 (HoloLens 2): +Additionally, you'll see the following policy changes in Windows Server 2022, Windows 11, and Windows Holographic, version 21H1 (HoloLens 2): | Policy type | Current policy | Renamed policy | | --- | --- | --- | @@ -65,9 +65,9 @@ For more info, see [Configure Windows diagnostic data in your organization](conf ## Services that rely on Enhanced diagnostic data -Customers who use services that depend on Windows diagnostic data, such as Microsoft Managed Desktop or Desktop Analytics, may be impacted by the behavioral changes when they are released. These services will be updated to address these changes and guidance will be published on how to configure them properly. +Customers who use services that depend on Windows diagnostic data, such as Microsoft Managed Desktop or Desktop Analytics, may be impacted by the behavioral changes when they're released. These services will be updated to address these changes and guidance will be published on how to configure them properly. -The following provides information on the current configurations: +The following articles provide information on the current configurations: - [Microsoft Managed Desktop](/microsoft-365/managed-desktop/service-description/device-policies#windows-diagnostic-data) - [Desktop Analytics](/mem/configmgr/desktop-analytics/overview) @@ -95,7 +95,7 @@ For Windows devices with diagnostic data turned on and that are joined to an [Az - [Update Compliance](/windows/deployment/update/update-compliance-monitor) - [Windows Update for Business deployment service](/windows/deployment/update/deployment-service-overview) - [Microsoft Managed Desktop](/managed-desktop/intro/) -- [Endpoint analytics (in Microsoft Endpoint Manager)](/mem/analytics/overview) +- [Endpoint analytics (in Microsoft Intune)](/mem/analytics/overview) *(Additional licensing requirements may apply to use these services.)* diff --git a/windows/security/cloud.md b/windows/security/cloud.md index 213647487d..0c96ff69db 100644 --- a/windows/security/cloud.md +++ b/windows/security/cloud.md @@ -23,9 +23,9 @@ Windows 11 includes the cloud services that are listed in the following table:
Non-Microsoft servers can be used to manage Windows 11 by using industry standard protocols.

To learn more, see [Mobile device management](/windows/client-management/mdm/). | +| Mobile device management (MDM) and Microsoft Intune | Windows 11 supports MDM, an enterprise management solution to help you manage your organization's security policies and business applications. MDM enables your security team to manage devices without compromising people's privacy on their personal devices.

Non-Microsoft servers can be used to manage Windows 11 by using industry standard protocols.

To learn more, see [Mobile device management](/windows/client-management/mdm/). | | Microsoft account | When users add their Microsoft account to Windows 11, they can bring their Windows, Microsoft Edge, Xbox settings, web page favorites, files, photos, and more across their devices.

The Microsoft account enables people to manage everything in one place. They can keep tabs on their subscriptions and order history, organize their family's digital life, update their privacy and security settings, track the health and safety of their devices, and even get rewards.

To learn more, see [Microsoft Accounts](identity-protection/access-control/microsoft-accounts.md).| -| OneDrive | OneDrive is your online storage for your files, photos, and data. OneDrive provides extra security, backup, and restore options for important files and photos. With options for both personal and business, people can use OneDrive to store and protect files in the cloud, allowing users to them on their laptops, desktops, and mobile devices. If a device is lost or stolen, people can quickly recover all their important files, photos, and data.

The OneDrive Personal Vault also provides protection for your most sensitive files without losing the convenience of anywhere access. Files are secured by identity verification, yet easily accessible to users across their devices. [Learn how to set up your Personal Vault](https://support.microsoft.com/office/protect-your-onedrive-files-in-personal-vault-6540ef37-e9bf-4121-a773-56f98dce78c4).

In the event of a ransomware attack, OneDrive can enable recovery. And if you’ve configured backups in OneDrive, you have more options to mitigate and recover from a ransomware attack. [Learn more about how to recover from a ransomware attack using Office 365](/microsoft-365/security/office-365-security/recover-from-ransomware). | +| OneDrive | OneDrive is your online storage for your files, photos, and data. OneDrive provides extra security, backup, and restore options for important files and photos. With options for both personal and business, people can use OneDrive to store and protect files in the cloud, allowing users to them on their laptops, desktops, and mobile devices. If a device is lost or stolen, people can quickly recover all their important files, photos, and data.

The OneDrive Personal Vault also provides protection for your most sensitive files without losing the convenience of anywhere access. Files are secured by identity verification, yet easily accessible to users across their devices. [Learn how to set up your Personal Vault](https://support.microsoft.com/office/protect-your-onedrive-files-in-personal-vault-6540ef37-e9bf-4121-a773-56f98dce78c4).

If there's a ransomware attack, OneDrive can enable recovery. And if you’ve configured backups in OneDrive, you have more options to mitigate and recover from a ransomware attack. [Learn more about how to recover from a ransomware attack using Office 365](/microsoft-365/security/office-365-security/recover-from-ransomware). | | Access to Azure Active Directory | Microsoft Azure Active Directory (Azure AD) is a complete cloud identity and access management solution for managing identities and directories, enabling access to applications, and protecting identities from security threats.

With Azure AD, you can manage and secure identities for your employees, partners, and customers to access the applications and services they need. Windows 11 works seamlessly with Azure Active Directory to provide secure access, identity management, and single sign-on to apps and services from anywhere.

To learn more, see [What is Azure AD?](/azure/active-directory/fundamentals/active-directory-whatis) | ## Next steps diff --git a/windows/security/identity-protection/credential-guard/credential-guard-manage.md b/windows/security/identity-protection/credential-guard/credential-guard-manage.md index 9d8bb4a982..3ef2c7372f 100644 --- a/windows/security/identity-protection/credential-guard/credential-guard-manage.md +++ b/windows/security/identity-protection/credential-guard/credential-guard-manage.md @@ -25,7 +25,7 @@ appliesto: ## Default Enablement -Starting in **Windows 11 Enterprise, version 22H2** and **Windows 11 Education, version 22H2**, compatible systems have Windows Defender Credential Guard turned on by default. This changes the default state of the feature in Windows, though system administrators can still modify this enablement state. Windows Defender Credential Guard can still be manually [enabled](#enable-windows-defender-credential-guard) or [disabled](#disable-windows-defender-credential-guard) via the methods documented below. +Starting in **Windows 11 Enterprise, version 22H2** and **Windows 11 Education, version 22H2**, compatible systems have Windows Defender Credential Guard turned on by default. This feature changes the default state of the feature in Windows, though system administrators can still modify this enablement state. Windows Defender Credential Guard can still be manually [enabled](#enable-windows-defender-credential-guard) or [disabled](#disable-windows-defender-credential-guard) via the methods documented below. ### Requirements for automatic enablement @@ -34,7 +34,7 @@ Windows Defender Credential Guard will be enabled by default when a PC meets the |Component|Requirement| |---|---| |Operating System|**Windows 11 Enterprise, version 22H2** or **Windows 11 Education, version 22H2**| -|Existing Windows Defender Credential Guard Requirements|Only devices which meet the [existing hardware and software requirements](credential-guard-requirements.md#hardware-and-software-requirements) to run Windows Defender Credential Guard will have it enabled by default.| +|Existing Windows Defender Credential Guard Requirements|Only devices that meet the [existing hardware and software requirements](credential-guard-requirements.md#hardware-and-software-requirements) to run Windows Defender Credential Guard will have it enabled by default.| |Virtualization-based Security (VBS) Requirements|VBS must be enabled in order to run Windows Defender Credential Guard. Starting with Windows 11 Enterprise 22H2 and Windows 11 Education 22H2, devices that meet the requirements to run Windows Defender Credential Guard as well as the [minimum requirements to enable VBS](/windows-hardware/design/device-experiences/oem-vbs) will have both Windows Defender Credential Guard and VBS enabled by default. > [!NOTE] @@ -55,7 +55,7 @@ The same set of procedures used to enable Windows Defender Credential Guard on p ### Enable Windows Defender Credential Guard by using Group Policy -You can use Group Policy to enable Windows Defender Credential Guard. This will add and enable the virtualization-based security features for you if needed. +You can use Group Policy to enable Windows Defender Credential Guard. When enabled, it will add and enable the virtualization-based security features for you if needed. 1. From the Group Policy Management Console, go to **Computer Configuration** > **Administrative Templates** > **System** > **Device Guard**. @@ -73,32 +73,32 @@ You can use Group Policy to enable Windows Defender Credential Guard. This will To enforce processing of the group policy, you can run `gpupdate /force`. -### Enable Windows Defender Credential Guard by using Microsoft Endpoint Manager +### Enable Windows Defender Credential Guard by using Microsoft Intune -1. From **Microsoft Endpoint Manager admin center**, select **Devices**. +1. In the [Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431), select **Devices**. 1. Select **Configuration Profiles**. 1. Select **Create Profile** > **Windows 10 and later** > **Settings catalog** > **Create**. - 1. Configuration settings: In the settings picker select **Device Guard** as category and add the needed settings. + 1. Configuration settings: In the settings picker, select **Device Guard** as category and add the needed settings. > [!NOTE] > Enable VBS and Secure Boot and you can do it with or without UEFI Lock. If you will need to disable Credential Guard remotely, enable it without UEFI lock. > [!TIP] -> You can also configure Credential Guard by using an account protection profile in endpoint security. For more information, see [Account protection policy settings for endpoint security in Microsoft Endpoint Manager](/mem/intune/protect/endpoint-security-account-protection-profile-settings). +> You can also configure Credential Guard by using an account protection profile in endpoint security. For more information, see [Account protection policy settings for endpoint security in Microsoft Intune](/mem/intune/protect/endpoint-security-account-protection-profile-settings). ### Enable Windows Defender Credential Guard by using the registry -If you don't use Group Policy, you can enable Windows Defender Credential Guard by using the registry. Windows Defender Credential Guard uses virtualization-based security features which have to be enabled first on some operating systems. +If you don't use Group Policy, you can enable Windows Defender Credential Guard by using the registry. Windows Defender Credential Guard uses virtualization-based security features that have to be enabled first on some operating systems. #### Add the virtualization-based security features -Starting with Windows 10, version 1607 and Windows Server 2016, enabling Windows features to use virtualization-based security is not necessary and this step can be skipped. +Starting with Windows 10, version 1607 and Windows Server 2016, enabling Windows features to use virtualization-based security isn't necessary and this step can be skipped. -If you are using Windows 10, version 1507 (RTM) or Windows 10, version 1511, Windows features have to be enabled to use virtualization-based security. -You can do this by using either the Control Panel or the Deployment Image Servicing and Management tool (DISM). +If you're using Windows 10, version 1507 (RTM) or Windows 10, version 1511, Windows features have to be enabled to use virtualization-based security. +To enable, use the Control Panel or the Deployment Image Servicing and Management tool (DISM). > [!NOTE] > If you enable Windows Defender Credential Guard by using Group Policy, the steps to enable Windows features through Control Panel or DISM are not required. Group Policy will install Windows features for you. @@ -201,9 +201,9 @@ DG_Readiness_Tool_v3.6.ps1 -Ready > [!NOTE] > For client machines that are running Windows 10 1703, LsaIso.exe is running whenever virtualization-based security is enabled for other features. -- We recommend enabling Windows Defender Credential Guard before a device is joined to a domain. If Windows Defender Credential Guard is enabled after domain join, the user and device secrets may already be compromised. In other words, enabling Credential Guard will not help to secure a device or identity that has already been compromised, which is why we recommend turning on Credential Guard as early as possible. +- We recommend enabling Windows Defender Credential Guard before a device is joined to a domain. If Windows Defender Credential Guard is enabled after domain join, the user and device secrets may already be compromised. In other words, enabling Credential Guard won't help to secure a device or identity that has already been compromised. So, we recommend turning on Credential Guard as early as possible. -- You should perform regular reviews of the PCs that have Windows Defender Credential Guard enabled. This can be done with security audit policies or WMI queries. Here's a list of WinInit event IDs to look for: +- You should perform regular reviews of the PCs that have Windows Defender Credential Guard enabled. You can use security audit policies or WMI queries. Here's a list of WinInit event IDs to look for: - **Event ID 13** Windows Defender Credential Guard (LsaIso.exe) was started and will protect LSA credentials. @@ -213,13 +213,13 @@ DG_Readiness_Tool_v3.6.ps1 -Ready - The second variable: **0** means that it's configured to run in protect mode. **1** means that it's configured to run in test mode. This variable should always be **0**. - - **Event ID 15** Windows Defender Credential Guard (LsaIso.exe) is configured but the secure kernel is not running; continuing without Windows Defender Credential Guard. + - **Event ID 15** Windows Defender Credential Guard (LsaIso.exe) is configured but the secure kernel isn't running; continuing without Windows Defender Credential Guard. - **Event ID 16** Windows Defender Credential Guard (LsaIso.exe) failed to launch: \[error code\] - **Event ID 17** Error reading Windows Defender Credential Guard (LsaIso.exe) UEFI configuration: \[error code\] -- You can also verify that TPM is being used for key protection by checking **Event ID 51** in *Applications and Services logs > Microsoft > Windows > Kernel-Boot* event log. The full event text will read like this: `VSM Master Encryption Key Provisioning. Using cached copy status: 0x0. Unsealing cached copy status: 0x1. New key generation status: 0x1. Sealing status: 0x1. TPM PCR mask: 0x0.` If you are running with a TPM, the TPM PCR mask value will be something other than 0. +- You can also verify that TPM is being used for key protection by checking **Event ID 51** in *Applications and Services logs > Microsoft > Windows > Kernel-Boot* event log. The full event text will read like this: `VSM Master Encryption Key Provisioning. Using cached copy status: 0x0. Unsealing cached copy status: 0x1. New key generation status: 0x1. Sealing status: 0x1. TPM PCR mask: 0x0.` If you're running with a TPM, the TPM PCR mask value will be something other than 0. - You can use Windows PowerShell to determine whether credential guard is running on a client computer. On the computer in question, open an elevated PowerShell window and run the following command: @@ -238,9 +238,9 @@ DG_Readiness_Tool_v3.6.ps1 -Ready ## Disable Windows Defender Credential Guard -Windows Defender Credential Guard can be disabled via several methods explained below, depending on how the feature was enabled. For devices that had Windows Defender Credential Guard automatically enabled in the 22H2 update and did not have it enabled prior to the update, it is sufficient to [disable via Group Policy](#disabling-windows-defender-credential-guard-using-group-policy). +Windows Defender Credential Guard can be disabled via several methods explained below, depending on how the feature was enabled. For devices that had Windows Defender Credential Guard automatically enabled in the 22H2 update and didn't have it enabled prior to the update, it's sufficient to [disable via Group Policy](#disabling-windows-defender-credential-guard-using-group-policy). -If Windows Defender Credential Guard was enabled with UEFI Lock, the procedure described in [Disabling Windows Defender Credential Guard with UEFI Lock](#disabling-windows-defender-credential-guard-with-uefi-lock) must be followed. Note that the default enablement change in eligible 22H2 devices does **not** use a UEFI Lock. +If Windows Defender Credential Guard was enabled with UEFI Lock, the procedure described in [Disabling Windows Defender Credential Guard with UEFI Lock](#disabling-windows-defender-credential-guard-with-uefi-lock) must be followed. The default enablement change in eligible 22H2 devices does **not** use a UEFI Lock. If Windows Defender Credential Guard was enabled via Group Policy without UEFI Lock, Windows Defender Credential Guard should be [disabled via Group Policy](#disabling-windows-defender-credential-guard-using-group-policy). @@ -262,7 +262,7 @@ If Windows Defender Credential Guard was enabled via Group Policy and without UE ### Disabling Windows Defender Credential Guard using Registry Keys -If Windows Defender Credential Guard was enabled without UEFI Lock and without Group Policy, it is sufficient to edit the registry keys as described below to disable Windows Defender Credential Guard. +If Windows Defender Credential Guard was enabled without UEFI Lock and without Group Policy, it's sufficient to edit the registry keys as described below to disable Windows Defender Credential Guard. 1. Change the following registry settings to 0: diff --git a/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md b/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md index b488757dd8..738c5d164a 100644 --- a/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md +++ b/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md @@ -27,7 +27,7 @@ You may wish to disable the automatic Windows Hello for Business enrollment prom ## Prerequisites -Cloud only deployments will use Azure AD multi-factor authentication (MFA) during Windows Hello for Business (WHfB) enrollment and there's no additional MFA configuration needed. If you aren't already registered in Azure AD MFA, you will be guided though the MFA registration as part of the Windows Hello for Business enrollment process. +Cloud only deployments will use Azure AD multi-factor authentication (MFA) during Windows Hello for Business (WHfB) enrollment and there's no additional MFA configuration needed. If you aren't already registered in Azure AD MFA, you'll be guided through the MFA registration as part of the Windows Hello for Business enrollment process. The necessary Windows Hello for Business prerequisites are located at [Cloud Only Deployment](hello-identity-verification.md#azure-ad-cloud-only-deployment). @@ -37,7 +37,7 @@ Check and view this setting with the following MSOnline PowerShell command: `Get-MsolDomainFederationSettings –DomainName ` -To disable this setting, run the following command. Note that this change impacts ALL Azure AD MFA scenarios for this federated domain. +To disable this setting, run the following command. This change impacts ALL Azure AD MFA scenarios for this federated domain. `Set-MsolDomainFederationSettings -DomainName -SupportsMfa $false` @@ -55,11 +55,11 @@ We recommend that you disable or manage Windows Hello for Business provisioning The following method explains how to disable Windows Hello for Business enrollment without Intune. -1. Sign into the [Microsoft Endpoint Manager](https://endpoint.microsoft.com/) admin center. +1. Sign into the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431). 2. Go to **Devices** > **Enrollment** > **Enroll devices** > **Windows enrollment** > **Windows Hello for Business**. The Windows Hello for Business pane opens. 3. If you don't want to enable Windows Hello for Business during device enrollment, select **Disabled** for **Configure Windows Hello for Business**. - When disabled, users cannot provision Windows Hello for Business. When set to Disabled, you can still configure the subsequent settings for Windows Hello for Business even though this policy won't enable Windows Hello for Business. + When disabled, users can't provision Windows Hello for Business. When set to Disabled, you can still configure the subsequent settings for Windows Hello for Business even though this policy won't enable Windows Hello for Business. > [!NOTE] > This policy is only applied during new device enrollments. For currently enrolled devices, you can [set the same settings in a device configuration policy](hello-manage-in-organization.md). diff --git a/windows/security/identity-protection/hello-for-business/hello-faq.yml b/windows/security/identity-protection/hello-for-business/hello-faq.yml index 88115dc1cb..91cd2ed308 100644 --- a/windows/security/identity-protection/hello-for-business/hello-faq.yml +++ b/windows/security/identity-protection/hello-for-business/hello-faq.yml @@ -47,11 +47,11 @@ sections: Remote Desktop Protocol (RDP) doesn't currently support using key-based authentication and self-signed certificates as supplied credentials. However, you can deploy certificates in the key trust model to enable RDP. For more information, see [Deploying certificates to key trust users to enable RDP](hello-deployment-rdp-certs.md). In addition, Windows Hello for Business key trust can be also used with RDP with [Windows Defender Remote Credential Guard](../remote-credential-guard.md) without deploying certificates. - - question: Can I deploy Windows Hello for Business by using Microsoft Endpoint Configuration Manager? + - question: Can I deploy Windows Hello for Business by using Microsoft Configuration Manager? answer: | Windows Hello for Business deployments using Configuration Manager should follow the hybrid deployment model that uses Active Directory Federation Services. Starting in Configuration Manager version 1910, certificate-based authentication with Windows Hello for Business settings isn't supported. Key-based authentication is still valid with Configuration Manager. For more information, see [Windows Hello for Business settings in Configuration Manager](/configmgr/protect/deploy-use/windows-hello-for-business-settings). - - question: Can I deploy Windows Hello for Business by using Microsoft Endpoint Manager Intune? + - question: Can I deploy Windows Hello for Business by using Microsoft Intune? answer: | Windows Hello for Business deployments using Intune allow for a great deal of flexibility in deployment. For more information, see [Integrate Windows Hello for Business with Microsoft Intune](/mem/intune/protect/windows-hello). @@ -155,11 +155,11 @@ sections: - question: Where is Windows Hello biometrics data stored? answer: | - When you enroll in Windows Hello, a representation of your face called an enrollment profile is created more information can be found on [Windows Hello face authentication](/windows-hardware/design/device-experiences/windows-hello-face-authentication). This enrollment profile biometrics data is device specific, is stored locally on the device, and does not leave the device or roam with the user. Some external fingerprint sensors store biometric data on the fingerprint module itself rather than on Windows device. Even in this case, the biometrics data is stored locally on those modules, is device specific, doesn't roam, never leaves the module, and is never sent to Microsoft cloud or external server. For more details see [Windows Hello biometrics in the enterprise](/windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise#where-is-windows-hello-data-stored). + When you enroll in Windows Hello, a representation of your face called an enrollment profile is created more information can be found on [Windows Hello face authentication](/windows-hardware/design/device-experiences/windows-hello-face-authentication). This enrollment profile biometrics data is device specific, is stored locally on the device, and does not leave the device or roam with the user. Some external fingerprint sensors store biometric data on the fingerprint module itself rather than on Windows device. Even in this case, the biometrics data is stored locally on those modules, is device specific, doesn't roam, never leaves the module, and is never sent to Microsoft cloud or external server. For more details, see [Windows Hello biometrics in the enterprise](/windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise#where-is-windows-hello-data-stored). - question: What is the format used to store Windows Hello biometrics data on the device? answer: | - Windows Hello biometrics data is stored on the device as an encrypted template database. The data from the biometrics sensor (e.g., face camera or fingerprint reader) creates a data representation—or graph—that is then encrypted before it’s stored on the device. Each biometrics sensor on the device which is used by Windows Hello (face or fingerprint) will have its own biometric database file where template data is stored. Each biometrics database file is encrypted with unique, randomly generated key that is encrypted to the system using AES encryption producing an SHA256 hash. + Windows Hello biometrics data is stored on the device as an encrypted template database. The data from the biometrics sensor (like face camera or fingerprint reader) creates a data representation—or graph—that is then encrypted before it’s stored on the device. Each biometrics sensor on the device which is used by Windows Hello (face or fingerprint) will have its own biometric database file where template data is stored. Each biometrics database file is encrypted with unique, randomly generated key that is encrypted to the system using AES encryption producing an SHA256 hash. - question: Who has access on Windows Hello biometrics data? answer: | @@ -167,11 +167,11 @@ sections: - question: When is Windows Hello biometrics database file created? How is a user enrolled into Windows Hello face or fingerprint authentication? answer: | - Windows Hello biometrics template database file is created on the device only when a user is enrolled into Windows Hello biometrics-based authentication. Your workplace or IT administrator may have turned certain authentication functionality, however, it is always your choice if you want to use Windows Hello or an alternative method (e.g. pin). Users can check their current enrollment into Windows Hello biometrics by going to sign-in options on their device. Go to **Start** > **Settings** > **Accounts** > **Sign-in** options. Or just click on **Go to Sign-in options**. To enroll into Windows Hello, user can go to **Start** > **Settings** > **Accounts** > **Sign-in** options, select the Windows Hello method that they want to set up, and then select **Set up**. If you don't see Windows Hello in Sign-in options, then it may not be available for your device or blocked by admin via policy. Admins can by policy request users to enroll into Windows Hello during autopilot or during initial setup of the device. Admins can disallow users to enroll into biometrics via Windows hello for business policy configurations. However, when allowed via policy configurations, enrollment into Windows Hello biometrics is always optional for users. + Windows Hello biometrics template database file is created on the device only when a user is enrolled into Windows Hello biometrics-based authentication. Your workplace or IT administrator may have turned certain authentication functionality, however, it is always your choice if you want to use Windows Hello or an alternative method, like a pin. Users can check their current enrollment into Windows Hello biometrics by going to sign-in options on their device. Go to **Start** > **Settings** > **Accounts** > **Sign-in** options. Or just select on **Go to Sign-in options**. To enroll into Windows Hello, user can go to **Start** > **Settings** > **Accounts** > **Sign-in** options, select the Windows Hello method that they want to set up, and then select **Set up**. If you don't see Windows Hello in Sign-in options, then it may not be available for your device or blocked by admin via policy. Admins can by policy request users to enroll into Windows Hello during autopilot or during initial setup of the device. Admins can disallow users to enroll into biometrics via Windows hello for business policy configurations. However, when allowed via policy configurations, enrollment into Windows Hello biometrics is always optional for users. - question: When is Windows Hello biometrics database file deleted? How can a user be unenrolled from Windows Hello face or fingerprint authentication? answer: | - To remove Windows Hello and any associated biometric identification data from the device, user can go to **Start** > **Settings** > **Accounts** > **Sign-in options**. Select the Windows Hello biometrics authentication method you want to remove, and then select **Remove**. This will unenroll the user from Windows Hello biometrics auth and will also delete the associated biometrics template database file. For more details see [Windows sign-in options and account protection (microsoft.com)](https://support.microsoft.com/en-us/windows/windows-sign-in-options-and-account-protection-7b34d4cf-794f-f6bd-ddcc-e73cdf1a6fbf#bkmk_helloandprivacy). + To remove Windows Hello and any associated biometric identification data from the device, user can go to **Start** > **Settings** > **Accounts** > **Sign-in options**. Select the Windows Hello biometrics authentication method you want to remove, and then select **Remove**. This will unenroll the user from Windows Hello biometrics auth and will also delete the associated biometrics template database file. For more details, see [Windows sign-in options and account protection (microsoft.com)](https://support.microsoft.com/en-us/windows/windows-sign-in-options-and-account-protection-7b34d4cf-794f-f6bd-ddcc-e73cdf1a6fbf#bkmk_helloandprivacy). - question: What about any diagnostic data coming out when WHFB is enabled? answer: | @@ -187,7 +187,7 @@ sections: - question: Can I wear a mask to enroll or unlock using Windows Hello face authentication? answer: | - Wearing a mask to enroll is a security concern because other users wearing a similar mask may be able to unlock your device. The product group is aware of this behavior and is investigating this topic further. Remove a mask if you're wearing one when you enroll or unlock with Windows Hello face authentication. If your working environment doesn’t allow you to remove a mask temporarily, consider unenrolling from face authentication and only using PIN or fingerprint. + Wearing a mask to enroll is a security concern because other users wearing a similar mask may be able to unlock your device. The product group is aware of this behavior and is investigating this article further. Remove a mask if you're wearing one when you enroll or unlock with Windows Hello face authentication. If your working environment doesn’t allow you to remove a mask temporarily, consider unenrolling from face authentication and only using PIN or fingerprint. - question: What's the difference between Windows Hello and Windows Hello for Business? answer: | diff --git a/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md b/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md index af6c28cb74..d44b2c01e7 100644 --- a/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md +++ b/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md @@ -35,7 +35,7 @@ There are two forms of PIN reset called destructive and non-destructive. Destruc - Reset from settings - Windows 10, version 1703 or later, Windows 11 - Reset above Lock - Windows 10, version 1709 or later, Windows 11 -Destructive and non-destructive PIN reset use the same steps for initiating a PIN reset. If users have forgotten their PINs, but have an alternate sign-in method, they can navigate to Sign-in options in *Settings* and initiate a PIN reset from the PIN options. If users do not have an alternate way to sign into their devices, PIN reset can also be initiated from the Windows lock screen in the PIN credential provider. +Destructive and non-destructive PIN reset use the same steps for initiating a PIN reset. If users have forgotten their PINs, but have an alternate sign-in method, they can navigate to Sign-in options in *Settings* and initiate a PIN reset from the PIN options. If users don't have an alternate way to sign into their devices, PIN reset can also be initiated from the Windows lock screen in the PIN credential provider. >[!IMPORTANT] @@ -52,16 +52,16 @@ Destructive and non-destructive PIN reset use the same steps for initiating a PI For Azure AD-joined devices: -1. If the PIN credential provider is not selected, expand the **Sign-in options** link, and select the PIN pad icon. +1. If the PIN credential provider isn't selected, expand the **Sign-in options** link, and select the PIN pad icon. 1. Select **I forgot my PIN** from the PIN credential provider. -1. Select an authentication option from the list of presented options. This list will be based on the different authentication methods enabled in your tenant (e.g., Password, PIN, Security key). +1. Select an authentication option from the list of presented options. This list will be based on the different authentication methods enabled in your tenant (like Password, PIN, Security key). 1. Follow the instructions provided by the provisioning process. 1. When finished, unlock your desktop using your newly created PIN. For Hybrid Azure AD-joined devices: -1. If the PIN credential provider is not selected, expand the **Sign-in options** link, and select the PIN pad icon. +1. If the PIN credential provider isn't selected, expand the **Sign-in options** link, and select the PIN pad icon. 1. Select **I forgot my PIN** from the PIN credential provider. 1. Enter your password and press enter. 1. Follow the instructions provided by the provisioning process. @@ -70,19 +70,19 @@ For Hybrid Azure AD-joined devices: > [!NOTE] > Key trust on hybrid Azure AD-joined devices does not support destructive PIN reset from above the Lock Screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. For this deployment model, you must deploy non-destructive PIN reset for above lock PIN reset to work. -You may find that PIN reset from settings only works post login, and that the "lock screen" PIN reset function will not work if you have any matching limitation of self-service password reset from the lock screen. For more information, see [Enable Azure Active Directory self-service password reset at the Windows sign-in screen - General ](/azure/active-directory/authentication/howto-sspr-windows#general-limitations). +You may find that PIN reset from settings only works post login. Also, the "lock screen" PIN reset function won't work if you have any matching limitation of self-service password reset from the lock screen. For more information, see [Enable Azure Active Directory self-service password reset at the Windows sign-in screen - General ](/azure/active-directory/authentication/howto-sspr-windows#general-limitations). ## Non-Destructive PIN reset **Requirements:** - Azure Active Directory -- Windows 10, version 1709 to 1809, Enterprise Edition. There is no licensing requirement for this feature since version 1903. +- Windows 10, version 1709 to 1809, Enterprise Edition. There's no licensing requirement for this feature since version 1903. - Hybrid Windows Hello for Business deployment - Azure AD registered, Azure AD joined, and Hybrid Azure AD joined -When non-destructive PIN reset is enabled on a client, a 256-bit AES key is generated locally and added to a user's Windows Hello for Business container and keys as the PIN reset protector. This PIN reset protector is encrypted using a public key retrieved from the Microsoft PIN reset service and then stored on the client for later use during PIN reset. After a user initiates a PIN reset, completes authentication and multi-factor authentication to Azure AD, the encrypted PIN reset protector is sent to the Microsoft PIN reset service, decrypted, and returned to the client. The decrypted PIN reset protector is used to change the PIN used to authorize Windows Hello for Business keys and it is then cleared from memory. +When non-destructive PIN reset is enabled on a client, a 256-bit AES key is generated locally. The key is added to a user's Windows Hello for Business container and keys as the PIN reset protector. This PIN reset protector is encrypted using a public key retrieved from the Microsoft PIN reset service and then stored on the client for later use during PIN reset. After a user initiates a PIN reset, completes authentication and multi-factor authentication to Azure AD, the encrypted PIN reset protector is sent to the Microsoft PIN reset service, decrypted, and returned to the client. The decrypted PIN reset protector is used to change the PIN used to authorize Windows Hello for Business keys and it's then cleared from memory. Using Group Policy, Microsoft Intune or a compatible MDM solution, you can configure Windows devices to securely use the **Microsoft PIN Reset Service** which enables users to reset their forgotten PIN without requiring re-enrollment. @@ -95,10 +95,10 @@ Using Group Policy, Microsoft Intune or a compatible MDM solution, you can confi |Category|Destructive PIN Reset|Non-Destructive PIN Reset| |--- |--- |--- | |**Functionality**|The user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, will be deleted from the client and a new logon key and PIN are provisioned.|You must deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature. For more information on how to deploy the Microsoft PIN reset service and client policy, see [Connect Azure Active Directory with the PIN reset service](#connect-azure-active-directory-with-the-pin-reset-service). During a non-destructive PIN reset, the user's Windows Hello for Business container and keys are preserved, but the user's PIN that they use to authorize key usage is changed.| -|**Windows editions and versions**|Reset from settings - Windows 10, version 1703 or later, Windows 11. Reset above Lock - Windows 10, version 1709 or later, Windows 11.|Windows 10, version 1709 to 1809, Enterprise Edition. There is no licensing requirement for this feature since version 1903. Enterprise Edition and Pro edition with Windows 10, version 1903 and newer Windows 11.| +|**Windows editions and versions**|Reset from settings - Windows 10, version 1703 or later, Windows 11. Reset above Lock - Windows 10, version 1709 or later, Windows 11.|Windows 10, version 1709 to 1809, Enterprise Edition. There isn't any licensing requirement for this feature since version 1903. Enterprise Edition and Pro edition with Windows 10, version 1903 and newer Windows 11.| |**Azure Active Directory Joined**|Cert Trust, Key Trust, and cloud Kerberos trust|Cert Trust, Key Trust, and cloud Kerberos trust| |**Hybrid Azure Active Directory Joined**|Cert Trust and cloud Kerberos trust for both settings and above the lock support destructive PIN reset. Key Trust doesn't support this from above the lock screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. It does support from the settings page and the users must have a corporate network connectivity to the DC. |Cert Trust, Key Trust, and cloud Kerberos trust for both settings and above the lock support non-destructive PIN reset. No network connection is required for the DC.| -|**On Premises**|If ADFS is being used for on premises deployments, users must have a corporate network connectivity to federation services. |The PIN reset service relies on Azure Active Directory identities, so it is only available for Hybrid Azure Active Directory Joined and Azure Active Directory Joined devices.| +|**On Premises**|If ADFS is being used for on premises deployments, users must have a corporate network connectivity to federation services. |The PIN reset service relies on Azure Active Directory identities, so it's only available for Hybrid Azure Active Directory Joined and Azure Active Directory Joined devices.| |**Additional Configuration required**|Supported by default and doesn't require configuration|Deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature On-board the Microsoft PIN reset service to respective Azure Active Directory tenant Configure Windows devices to use PIN reset using Group *Policy\MDM*.| |**MSA/Enterprise**|MSA and Enterprise|Enterprise only.| @@ -117,13 +117,13 @@ Before you can remotely reset PINs, you must register two applications in your A #### Connect Azure Active Directory with the PIN Reset Service 1. Go to the [Microsoft PIN Reset Service Production website](https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=b8456c59-1230-44c7-a4a2-99b085333e84&resource=https%3A%2F%2Fgraph.windows.net&redirect_uri=https%3A%2F%2Fcred.microsoft.com&state=e9191523-6c2f-4f1d-a4f9-c36f26f89df0&prompt=admin_consent), and sign in using a Global Administrator account you use to manage your Azure Active Directory tenant. -1. After you have logged in, select **Accept** to give consent to the **PIN Reset Service** to access your organization. +1. After you've logged in, select **Accept** to give consent to the **PIN Reset Service** to access your organization. ![PIN reset service application in Azure.](images/pinreset/pin-reset-service-prompt.png) #### Connect Azure Active Directory with the PIN Reset Client 1. Go to the [Microsoft PIN Reset Client Production website](https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=9115dd05-fad5-4f9c-acc7-305d08b1b04e&resource=https%3A%2F%2Fcred.microsoft.com%2F&redirect_uri=ms-appx-web%3A%2F%2FMicrosoft.AAD.BrokerPlugin%2F9115dd05-fad5-4f9c-acc7-305d08b1b04e&state=6765f8c5-f4a7-4029-b667-46a6776ad611&prompt=admin_consent), and sign in using a Global Administrator account you use to manage your Azure Active Directory tenant. -1. After you have logged in, select **Accept** to give consent for the **PIN Reset Client** to access your organization. +1. After you've logged in, select **Accept** to give consent for the **PIN Reset Client** to access your organization. ![PIN reset client application in Azure.](images/pinreset/pin-reset-client-prompt.png) #### Confirm that the two PIN Reset service principals are registered in your tenant @@ -141,7 +141,7 @@ Before you can remotely reset PINs, your devices must be configured to enable PI You can configure Windows devices to use the **Microsoft PIN Reset Service** using Microsoft Intune. -1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com). +1. Sign in to the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431). 1. Select **Devices** > **Configuration profiles** > **Create profile**. 1. Enter the following properties: - **Platform**: Select **Windows 10 and later**. @@ -163,7 +163,7 @@ You can configure Windows devices to use the **Microsoft PIN Reset Service** usi >[!NOTE] > You can also configure PIN recovery from the **Endpoint security** blade: -> 1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com). +> 1. Sign in to the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431). > 1. Select **Endpoint security** > **Account protection** > **Create Policy**. #### [:::image type="icon" source="../../images/icons/group-policy.svg"::: **GPO**](#tab/gpo) @@ -236,11 +236,11 @@ The _PIN reset_ configuration can be viewed by running [**dsregcmd /status**](/a - Azure AD joined devices -The [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-authentication#authentication-configurewebsigninallowedurls) policy allows you to specify a list of domains that can be reached during PIN reset flows on Azure AD-joined devices. If you have a federated environment and authentication is handled using AD FS or a third-party identity provider, this policy should be set to ensure that authentication pages from that identity provider can be used during Azure AD joined PIN reset. +The [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-authentication#authentication-configurewebsigninallowedurls) policy allows you to specify a list of domains that can be reached during PIN reset flows on Azure AD-joined devices. If you have a federated environment and authentication is handled using AD FS or a third-party identity provider, then this policy should be set. When set, it ensures that authentication pages from that identity provider can be used during Azure AD joined PIN reset. ### Configure Web Sign-in Allowed URLs using Microsoft Intune -1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com) +1. Sign in to the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431) 1. Select **Devices** > **Configuration profiles** > **Create profile** 1. Enter the following properties: - **Platform**: Select **Windows 10 and later** @@ -266,7 +266,7 @@ The [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-au > [!NOTE] > For Azure Government, there is a known issue with PIN reset on Azure AD Joined devices failing. When the user attempts to launch PIN reset, the PIN reset UI shows an error page that says, "We can't open that page right now." The ConfigureWebSignInAllowedUrls policy can be used to work around this issue. If you are experiencing this problem and you are using Azure US Government cloud, set **login.microsoftonline.us** as the value for the ConfigureWebSignInAllowedUrls policy. -## Related topics +## Related articles - [Windows Hello for Business](hello-identity-verification.md) - [Manage Windows Hello for Business in your organization](hello-manage-in-organization.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md index a4c55e0fdd..37f7b13e82 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md @@ -21,23 +21,23 @@ appliesto: # Configure Azure AD-joined devices for On-premises Single-Sign On using Windows Hello for Business ## Prerequisites -Before adding Azure Active Directory (Azure AD) joined devices to your existing hybrid deployment, you need to verify the existing deployment can support Azure AD-joined devices. Unlike hybrid Azure AD-joined devices, Azure AD-joined devices do not have a relationship with your Active Directory domain. This factor changes the way in which users authenticate to Active Directory. Validate the following configurations to ensure they support Azure AD-joined devices. +Before adding Azure Active Directory (Azure AD) joined devices to your existing hybrid deployment, you need to verify the existing deployment can support Azure AD-joined devices. Unlike hybrid Azure AD-joined devices, Azure AD-joined devices don't have a relationship with your Active Directory domain. This factor changes the way in which users authenticate to Active Directory. Validate the following configurations to ensure they support Azure AD-joined devices. - Azure Active Directory Connect synchronization - Device Registration - Certificate Revocation List (CRL) Distribution Point (CDP) - 2016 Domain Controllers - Domain Controller certificate -- Network infrastructure in place to reach your on-premises domain controller. If the machines are external, this can be achieved using any VPN solution. +- Network infrastructure in place to reach your on-premises domain controller. If the machines are external, you can use any VPN solution. ### Azure Active Directory Connect synchronization -Azure AD join, as well as hybrid Azure AD join devices register the user's Windows Hello for Business credential with Azure. To enable on-premises authentication, the credential must be synchronized to the on-premises Active Directory, regardless whether you are using a key or a certificate. Ensure you have Azure AD Connect installed and functioning properly. To learn more about Azure AD Connect, read [Integrate your on-premises directories with Azure Active Directory](/azure/active-directory/connect/active-directory-aadconnect). +Azure AD join, and hybrid Azure AD join devices register the user's Windows Hello for Business credential with Azure. To enable on-premises authentication, the credential must be synchronized to the on-premises Active Directory, regardless whether you're using a key or a certificate. Ensure you have Azure AD Connect installed and functioning properly. To learn more about Azure AD Connect, read [Integrate your on-premises directories with Azure Active Directory](/azure/active-directory/connect/active-directory-aadconnect). If you upgraded your Active Directory schema to the Windows Server 2016 schema after installing Azure AD Connect, run Azure AD Connect and run **Refresh directory schema** from the list of tasks. ![Azure AD Connect Schema Refresh.](images/aadj/aadconnectschema.png) ### Azure Active Directory Device Registration -A fundamental prerequisite of all cloud and hybrid Windows Hello for Business deployments is device registration. A user cannot provision Windows Hello for Business unless the device from which they are trying to provision has registered with Azure Active Directory. For more information about device registration, read [Introduction to device management in Azure Active Directory](/azure/active-directory/devices/overview). +A fundamental prerequisite of all cloud and hybrid Windows Hello for Business deployments is device registration. A user can't provision Windows Hello for Business unless the device from which they're trying to provision has registered with Azure Active Directory. For more information about device registration, read [Introduction to device management in Azure Active Directory](/azure/active-directory/devices/overview). You can use the **dsregcmd.exe** command to determine if your device is registered to Azure Active Directory. ![dsregcmd output.](images/aadj/dsregcmd.png) @@ -48,24 +48,24 @@ Certificates issued by a certificate authority can be revoked. When a certifica ![Domain Controller Certificate with LDAP CDP.](images/aadj/Certificate-CDP.png) -The preceding domain controller certificate shows a CRL distribution path (CDP) using Active Directory. You can determine this because the value in the URL begins with **ldap**. Using Active Directory for domain joined devices provides a highly available CRL distribution point. However, Azure Active Directory-joined devices and users on Azure Active Directory-joined devices cannot read data from Active Directory, and certificate validation does not provide an opportunity to authenticate prior to reading the certificate revocation list. This becomes a circular problem as the user is attempting to authenticate, but must read Active Directory to complete the authentication, but the user cannot read Active Directory because they have not authenticated. +The preceding domain controller certificate shows a CRL distribution path (CDP) using Active Directory. The value in the URL begins with **ldap**. Using Active Directory for domain joined devices provides a highly available CRL distribution point. However, Azure Active Directory-joined devices and users on Azure Active Directory-joined devices can't read data from Active Directory, and certificate validation doesn't provide an opportunity to authenticate prior to reading the certificate revocation list. The authentication becomes a circular problem. The user is attempting to authenticate, but must read Active Directory to complete the authentication, but the user can't read Active Directory because they haven't authenticated. -To resolve this issue, the CRL distribution point must be a location that is accessible by Azure Active Directory-joined devices that does not require authentication. The easiest solution is to publish the CRL distribution point on a web server that uses HTTP (not HTTPS). +To resolve this issue, the CRL distribution point must be a location that is accessible by Azure Active Directory-joined devices that doesn't require authentication. The easiest solution is to publish the CRL distribution point on a web server that uses HTTP (not HTTPS). -If your CRL distribution point does not list an HTTP distribution point, then you need to reconfigure the issuing certificate authority to include an HTTP CRL distribution point, preferably first in the list of distribution points. +If your CRL distribution point doesn't list an HTTP distribution point, then you need to reconfigure the issuing certificate authority to include an HTTP CRL distribution point, preferably first in the list of distribution points. > [!NOTE] > If your CA has published both the Base and the Delta CRL, please make sure you have included publishing the Delta CRL in the HTTP path. Include web server to fetch the Delta CRL by allowing double escaping in the (IIS) web server. ### Windows Server 2016 Domain Controllers -If you are interested in configuring your environment to use the Windows Hello for Business key rather than a certificate, then your environment must have an adequate number of Windows Server 2016 domain controllers. Only Windows Server 2016 domain controllers are capable of authenticating user with a Windows Hello for Business key. What do we mean by adequate? We are glad you asked. Read [Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more. +If you're interested in configuring your environment to use the Windows Hello for Business key rather than a certificate, then your environment must have an adequate number of Windows Server 2016 domain controllers. Only Windows Server 2016 domain controllers are capable of authenticating user with a Windows Hello for Business key. What do we mean by adequate? We're glad you asked. Read [Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more. -If you are interested in configuring your environment to use the Windows Hello for Business certificate rather than key, then you are the right place. The same certificate configuration on the domain controllers is needed, whether you are using Windows Server 2016 domain controllers or domain controllers running earlier versions of Windows Server. You can simply ignore the Windows Server 2016 domain controller requirement. +If you're interested in configuring your environment to use the Windows Hello for Business certificate rather than key, then you're the right place. The same certificate configuration on the domain controllers is needed, whether you're using Windows Server 2016 domain controllers or domain controllers running earlier versions of Windows Server. You can ignore the Windows Server 2016 domain controller requirement. ### Domain Controller Certificates -Certificate authorities write CRL distribution points in certificates as they are issued. If the distribution point changes, then previously issued certificates must be reissued for the certificate authority to include the new CRL distribution point. The domain controller certificate is one the critical components of Azure AD-joined devices authenticating to Active Directory +Certificate authorities write CRL distribution points in certificates as they're issued. If the distribution point changes, then previously issued certificates must be reissued for the certificate authority to include the new CRL distribution point. The domain controller certificate is one the critical components of Azure AD-joined devices authenticating to Active Directory #### Why does Windows need to validate the domain controller certificate? @@ -79,7 +79,7 @@ Windows Hello for Business enforces the strict KDC validation security feature w - The domain controller's certificate's signature hash algorithm is **sha256**. - The domain controller's certificate's public key is **RSA (2048 Bits)**. -Authenticating from a Hybrid Azure AD joined device to a domain using Windows Hello for Business does not enforce that the domain controller certificate includes the **KDC Authentication** EKU. If you are adding Azure AD-joined devices to an existing domain environment, make sure to verify that your domain controller certificate has been updated to include the **KDC Authentication** EKU. If you need to update your domain controller certificate to include the **KDC Authentication** EKU, follow the instructions in [Configure Hybrid Windows Hello for Business: Public Key Infrastructure](hello-hybrid-key-whfb-settings-pki.md) +Authenticating from a Hybrid Azure AD joined device to a domain using Windows Hello for Business doesn't enforce that the domain controller certificate includes the **KDC Authentication** EKU. If you're adding Azure AD-joined devices to an existing domain environment, make sure to verify that your domain controller certificate has been updated to include the **KDC Authentication** EKU. If you need to update your domain controller certificate to include the **KDC Authentication** EKU, follow the instructions in [Configure Hybrid Windows Hello for Business: Public Key Infrastructure](hello-hybrid-key-whfb-settings-pki.md) > [!Tip] > If you are using Windows Server 2008, **Kerberos Authentication** is not the default template, so make sure to use the correct template when issuing or re-issuing the certificate. @@ -88,7 +88,7 @@ Authenticating from a Hybrid Azure AD joined device to a domain using Windows He Use this set of procedures to update your certificate authority that issues your domain controller certificates to include an http-based CRL distribution point. -Steps you will perform include: +Steps you'll perform include: - [Configure Internet Information Services to host CRL distribution point](#configure-internet-information-services-to-host-crl-distribution-point) - [Prepare a file share to host the certificate revocation list](#prepare-a-file-share-to-host-the-certificate-revocation-list) @@ -99,40 +99,40 @@ Steps you will perform include: ### Configure Internet Information Services to host CRL distribution point -You need to host your new certificate revocation list of a web server so Azure AD-joined devices can easily validate certificates without authentication. You can host these files on web servers many ways. The following steps is just one and may be useful for those unfamiliar with adding a new CRL distribution point. +You need to host your new certificate revocation list of a web server so Azure AD-joined devices can easily validate certificates without authentication. You can host these files on web servers many ways. The following steps are just one and may be useful for admins unfamiliar with adding a new CRL distribution point. > [!IMPORTANT] > Do not configure the IIS server hosting your CRL distribution point to use https or a server authentication certificate. Clients should access the distribution point using http. #### Installing the Web Server -1. Sign-in to your server as a local administrator and start **Server Manager** if it did not start during your sign in. -2. Click the **Local Server** node in the navigation pane. Click **Manage** and click **Add Roles and Features**. -3. In the **Add Role and Features Wizard**, click **Server Selection**. Verify the selected server is the local server. Click **Server Roles**. Select the check box next to **Web Server (IIS)**. -4. Click **Next** through the remaining options in the wizard, accepting the defaults, and install the Web Server role. +1. Sign-in to your server as a local administrator and start **Server Manager** if it didn't start during your sign in. +2. Select the **Local Server** node in the navigation pane. Select **Manage** and select **Add Roles and Features**. +3. In the **Add Role and Features Wizard**, select **Server Selection**. Verify the selected server is the local server. Select **Server Roles**. Select the check box next to **Web Server (IIS)**. +4. Select **Next** through the remaining options in the wizard, accepting the defaults, and install the Web Server role. #### Configure the Web Server 1. From **Windows Administrative Tools**, Open **Internet Information Services (IIS) Manager**. -2. Expand the navigation pane to show **Default Web Site**. Select and then right-click **Default Web site** and click **Add Virtual Directory...**. -3. In the **Add Virtual Directory** dialog box, type **cdp** in **alias**. For physical path, type or browse for the physical file location where you will host the certificate revocation list. For this example, the path **c:\cdp** is used. Click **OK**. +2. Expand the navigation pane to show **Default Web Site**. Select and then right-click **Default Web site** and select **Add Virtual Directory...**. +3. In the **Add Virtual Directory** dialog box, type **cdp** in **alias**. For physical path, type or browse for the physical file location where you'll host the certificate revocation list. For this example, the path **c:\cdp** is used. Select **OK**. ![Add Virtual Directory.](images/aadj/iis-add-virtual-directory.png) > [!NOTE] > Make note of this path as you will use it later to configure share and file permissions. -4. Select **CDP** under **Default Web Site** in the navigation pane. Double-click **Directory Browsing** in the content pane. Click **Enable** in the details pane. +4. Select **CDP** under **Default Web Site** in the navigation pane. Double-click **Directory Browsing** in the content pane. Select **Enable** in the details pane. 5. Select **CDP** under **Default Web Site** in the navigation pane. Double-click **Configuration Editor**. 6. In the **Section** list, navigate to **system.webServer/security/requestFiltering**. ![IIS Configuration Editor requestFiltering.](images/aadj/iis-config-editor-requestFiltering.png) - In the list of named value-pairs in the content pane, configure **allowDoubleEscaping** to **True**. Click **Apply** in the actions pane. + In the list of named value-pairs in the content pane, configure **allowDoubleEscaping** to **True**. Select **Apply** in the actions pane. ![IIS Configuration Editor double escaping.](images/aadj/iis-config-editor-allowDoubleEscaping.png) 7. Close **Internet Information Services (IIS) Manager**. #### Create a DNS resource record for the CRL distribution point URL 1. On your DNS server or from an administrative workstation, open **DNS Manager** from **Administrative Tools**. -2. Expand **Forward Lookup Zones** to show the DNS zone for your domain. Right-click your domain name in the navigation pane and click **New Host (A or AAAA)...**. -3. In the **New Host** dialog box, type **crl** in **Name**. Type the IP address of the web server you configured in **IP Address**. Click **Add Host**. Click **OK** to close the **DNS** dialog box. Click **Done**. +2. Expand **Forward Lookup Zones** to show the DNS zone for your domain. Right-click your domain name in the navigation pane and select **New Host (A or AAAA)...**. +3. In the **New Host** dialog box, type **crl** in **Name**. Type the IP address of the web server you configured in **IP Address**. Select **Add Host**. Select **OK** to close the **DNS** dialog box. Select **Done**. ![Create DNS host record.](images/aadj/dns-new-host-dialog.png) 4. Close the **DNS Manager**. @@ -143,37 +143,37 @@ These procedures configure NTFS and share permissions on the web server to allow #### Configure the CDP file share 1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server). -2. Right-click the **cdp** folder and click **Properties**. Click the **Sharing** tab. Click **Advanced Sharing**. -3. Select **Share this folder**. Type **cdp$** in **Share name**. Click **Permissions**. +2. Right-click the **cdp** folder and select **Properties**. Select the **Sharing** tab. Select **Advanced Sharing**. +3. Select **Share this folder**. Type **cdp$** in **Share name**. Select **Permissions**. ![cdp sharing.](images/aadj/cdp-sharing.png) -4. In the **Permissions for cdp$** dialog box, click **Add**. -5. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, click **Object Types**. In the **Object Types** dialog box, select **Computers**, and then click **OK**. -7. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, in **Enter the object names to select**, type the name of the server running the certificate authority issuing the certificate revocation list, and then click **Check Names**. Click **OK**. -8. In the **Permissions for cdp$** dialog box, select the certificate authority from the **Group or user names list**. In the **Permissions for** section, select **Allow** for **Full control**. Click **OK**. +4. In the **Permissions for cdp$** dialog box, select **Add**. +5. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, select **Object Types**. In the **Object Types** dialog box, select **Computers**, and then select **OK**. +7. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, in **Enter the object names to select**, type the name of the server running the certificate authority issuing the certificate revocation list, and then select **Check Names**. Select **OK**. +8. In the **Permissions for cdp$** dialog box, select the certificate authority from the **Group or user names list**. In the **Permissions for** section, select **Allow** for **Full control**. Select **OK**. ![CDP Share Permissions.](images/aadj/cdp-share-permissions.png) -9. In the **Advanced Sharing** dialog box, click **OK**. +9. In the **Advanced Sharing** dialog box, select **OK**. > [!Tip] > Make sure that users can access **\\\Server FQDN\sharename**. #### Disable Caching 1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server). -2. Right-click the **cdp** folder and click **Properties**. Click the **Sharing** tab. Click **Advanced Sharing**. -3. Click **Caching**. Select **No files or programs from the shared folder are available offline**. +2. Right-click the **cdp** folder and select **Properties**. Select the **Sharing** tab. Select **Advanced Sharing**. +3. Select **Caching**. Select **No files or programs from the shared folder are available offline**. ![CDP disable caching.](images/aadj/cdp-disable-caching.png) -4. Click **OK**. +4. Select **OK**. #### Configure NTFS permission for the CDP folder 1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server). -2. Right-click the **cdp** folder and click **Properties**. Click the **Security** tab. -3. On the **Security** tab, click Edit. -5. In the **Permissions for cdp** dialog box, click **Add**. +2. Right-click the **cdp** folder and select **Properties**. Select the **Security** tab. +3. On the **Security** tab, select Edit. +5. In the **Permissions for cdp** dialog box, select **Add**. ![CDP NTFS Permissions.](images/aadj/cdp-ntfs-permissions.png) -6. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, click **Object Types**. In the **Object Types** dialog box, select **Computers**. Click **OK**. -7. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, in **Enter the object names to select**, type the name of the certificate authority, and then click **Check Names**. Click **OK**. -8. In the **Permissions for cdp** dialog box, select the name of the certificate authority from the **Group or user names** list. In the **Permissions for** section, select **Allow** for **Full control**. Click **OK**. -9. Click **Close** in the **cdp Properties** dialog box. +6. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, select **Object Types**. In the **Object Types** dialog box, select **Computers**. Select **OK**. +7. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, in **Enter the object names to select**, type the name of the certificate authority, and then select **Check Names**. Select **OK**. +8. In the **Permissions for cdp** dialog box, select the name of the certificate authority from the **Group or user names** list. In the **Permissions for** section, select **Allow** for **Full control**. Select **OK**. +9. Select **Close** in the **cdp Properties** dialog box. ### Configure the new CRL distribution point and Publishing location in the issuing certificate authority @@ -183,17 +183,17 @@ The web server is ready to host the CRL distribution point. Now, configure the #### Configure the CRL distribution Point 1. On the issuing certificate authority, sign-in as a local administrator. Start the **Certificate Authority** console from **Administrative Tools**. -2. In the navigation pane, right-click the name of the certificate authority and click **Properties** -3. Click **Extensions**. On the **Extensions** tab, select **CRL Distribution Point (CDP)** from the **Select extension** list. -4. On the **Extensions** tab, click **Add**. Type http://crl.[domainname]/cdp/ in **location**. For example, `` or `` (do not forget the trailing forward slash). +2. In the navigation pane, right-click the name of the certificate authority and select **Properties** +3. Select **Extensions**. On the **Extensions** tab, select **CRL Distribution Point (CDP)** from the **Select extension** list. +4. On the **Extensions** tab, select **Add**. Type http://crl.[domainname]/cdp/ in **location**. For example, `` or `` (don't forget the trailing forward slash). ![CDP New Location dialog box.](images/aadj/cdp-extension-new-location.png) -5. Select **\** from the **Variable** list and click **Insert**. Select **\** from the **Variable** list and click **Insert**. Select **\** from the **Variable** list and click **Insert**. -6. Type **.crl** at the end of the text in **Location**. Click **OK**. +5. Select **\** from the **Variable** list and select **Insert**. Select **\** from the **Variable** list and select **Insert**. Select **\** from the **Variable** list and select **Insert**. +6. Type **.crl** at the end of the text in **Location**. Select **OK**. 7. Select the CDP you just created. ![CDP complete http.](images/aadj/cdp-extension-complete-http.png) 8. Select **Include in CRLs. Clients use this to find Delta CRL locations**. 9. Select **Include in the CDP extension of issued certificates**. -10. Click **Apply** save your selections. Click **No** when ask to restart the service. +10. Select **Apply** save your selections. Select **No** when ask to restart the service. > [!NOTE] > Optionally, you can remove unused CRL distribution points and publishing locations. @@ -201,43 +201,43 @@ The web server is ready to host the CRL distribution point. Now, configure the #### Configure the CRL publishing location 1. On the issuing certificate authority, sign-in as a local administrator. Start the **Certificate Authority** console from **Administrative Tools**. -2. In the navigation pane, right-click the name of the certificate authority and click **Properties** -3. Click **Extensions**. On the **Extensions** tab, select **CRL Distribution Point (CDP)** from the **Select extension** list. -4. On the **Extensions** tab, click **Add**. Type the computer and share name you create for your CRL distribution point in [Configure the CDP file share](#configure-the-cdp-file-share). For example, **\\\app\cdp$\\** (do not forget the trailing backwards slash). -5. Select **\** from the **Variable** list and click **Insert**. Select **\** from the **Variable** list and click **Insert**. Select **\** from the **Variable** list and click **Insert**. -6. Type **.crl** at the end of the text in **Location**. Click **OK**. +2. In the navigation pane, right-click the name of the certificate authority and select **Properties** +3. Select **Extensions**. On the **Extensions** tab, select **CRL Distribution Point (CDP)** from the **Select extension** list. +4. On the **Extensions** tab, select **Add**. Type the computer and share name you create for your CRL distribution point in [Configure the CDP file share](#configure-the-cdp-file-share). For example, **\\\app\cdp$\\** (don't forget the trailing backwards slash). +5. Select **\** from the **Variable** list and select **Insert**. Select **\** from the **Variable** list and select **Insert**. Select **\** from the **Variable** list and select **Insert**. +6. Type **.crl** at the end of the text in **Location**. Select **OK**. 7. Select the CDP you just created.
![CDP publishing location.](images/aadj/cdp-extension-complete-unc.png) 8. Select **Publish CRLs to this location**. 9. Select **Publish Delta CRLs to this location**. -10. Click **Apply** save your selections. Click **Yes** when ask to restart the service. Click **OK** to close the properties dialog box. +10. Select **Apply** save your selections. Select **Yes** when ask to restart the service. Select **OK** to close the properties dialog box. ### Publish a new CRL 1. On the issuing certificate authority, sign-in as a local administrator. Start the **Certificate Authority** console from **Administrative Tools**. -2. In the navigation pane, right-click **Revoked Certificates**, hover over **All Tasks**, and click **Publish** +2. In the navigation pane, right-click **Revoked Certificates**, hover over **All Tasks**, and select **Publish** ![Publish a New CRL.](images/aadj/publish-new-crl.png) -3. In the **Publish CRL** dialog box, select **New CRL** and click **OK**. +3. In the **Publish CRL** dialog box, select **New CRL** and select **OK**. #### Validate CDP Publishing Validate your new CRL distribution point is working. -1. Open a web browser. Navigate to http://crl.[yourdomain].com/cdp. You should see two files created from publishing your new CRL. +1. Open a web browser. Navigate to `http://crl.[yourdomain].com/cdp`. You should see two files created from publishing your new CRL. ![Validate the new CRL.](images/aadj/validate-cdp-using-browser.png) ### Reissue domain controller certificates -With the CA properly configured with a valid HTTP-based CRL distribution point, you need to reissue certificates to domain controllers as the old certificate does not have the updated CRL distribution point. +With the CA properly configured with a valid HTTP-based CRL distribution point, you need to reissue certificates to domain controllers as the old certificate doesn't have the updated CRL distribution point. 1. Sign-in a domain controller using administrative credentials. 2. Open the **Run** dialog box. Type **certlm.msc** to open the **Certificate Manager** for the local computer. -3. In the navigation pane, expand **Personal**. Click **Certificates**. In the details pane, select the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**. +3. In the navigation pane, expand **Personal**. Select **Certificates**. In the details pane, select the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**. ![Certificate Manager Personal store.](images/aadj/certlm-personal-store.png) -4. Right-click the selected certificate. Hover over **All Tasks** and then select **Renew Certificate with New Key...**. In the **Certificate Enrollment** wizard, click **Next**. +4. Right-click the selected certificate. Hover over **All Tasks** and then select **Renew Certificate with New Key...**. In the **Certificate Enrollment** wizard, select **Next**. ![Renew with New key.](images/aadj/certlm-renew-with-new-key.png) -5. In the **Request Certificates** page of the wizard, verify the selected certificate has the correct certificate template and ensure the status is available. Click **Enroll**. -6. After the enrollment completes, click **Finish** to close the wizard. +5. In the **Request Certificates** page of the wizard, verify the selected certificate has the correct certificate template and ensure the status is available. Select **Enroll**. +6. After the enrollment completes, select **Finish** to close the wizard. 7. Repeat this procedure on all your domain controllers. > [!NOTE] @@ -250,16 +250,16 @@ With the CA properly configured with a valid HTTP-based CRL distribution point, 1. Sign-in a domain controller using administrative credentials. 2. Open the **Run** dialog box. Type **certlm.msc** to open the **Certificate Manager** for the local computer. -3. In the navigation pane, expand **Personal**. Click **Certificates**. In the details pane, double-click the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**. -4. Click the **Details** tab. Scroll down the list until **CRL Distribution Points** is visible in the **Field** column of the list. Select **CRL Distribution Point**. -5. Review the information below the list of fields to confirm the new URL for the CRL distribution point is present in the certificate. Click **OK**.
+3. In the navigation pane, expand **Personal**. Select **Certificates**. In the details pane, double-click the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**. +4. Select the **Details** tab. Scroll down the list until **CRL Distribution Points** is visible in the **Field** column of the list. Select **CRL Distribution Point**. +5. Review the information below the list of fields to confirm the new URL for the CRL distribution point is present in the certificate. Select **OK**.
![New Certificate with updated CDP.](images/aadj/dc-cert-with-new-cdp.png) ## Configure and Assign a Trusted Certificate Device Configuration Profile -Your domain controllers have new certificate that include the new CRL distribution point. Next, you need your enterprise root certificate so you can deploy it to Azure AD-joined devices. Deploying the enterprise root certificates to the device, ensures the device trusts any certificates issued by the certificate authority. Without the certificate, Azure AD-joined devices do not trust domain controller certificates and authentication fails. +Your domain controllers have new certificates that include the new CRL distribution point. Next, you need your enterprise root certificate so you can deploy it to Azure AD-joined devices. When you deploy the enterprise root certificates to the device, it ensures the device trusts any certificates issued by the certificate authority. Without the certificate, Azure AD-joined devices don't trust domain controller certificates and authentication fails. -Steps you will perform include: +Steps you'll perform include: - [Export Enterprise Root certificate](#export-enterprise-root-certificate) - [Create and Assign a Trust Certificate Device Configuration Profile](#create-and-assign-a-trust-certificate-device-configuration-profile) @@ -267,30 +267,30 @@ Steps you will perform include: 1. Sign-in a domain controller using administrative credentials. 2. Open the **Run** dialog box. Type **certlm.msc** to open the **Certificate Manager** for the local computer. -3. In the navigation pane, expand **Personal**. Click **Certificates**. In the details pane, double-click the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**. -4. Click the **Certification Path** tab. In the **Certification path** view, select the top most node and click **View Certificate**. +3. In the navigation pane, expand **Personal**. Select **Certificates**. In the details pane, double-click the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**. +4. Select the **Certification Path** tab. In the **Certification path** view, select the topmost node and select **View Certificate**. ![Certificate Path.](images/aadj/certlm-cert-path-tab.png) -5. In the new **Certificate** dialog box, click the **Details** tab. Click **Copy to File**. +5. In the new **Certificate** dialog box, select the **Details** tab. Select **Copy to File**. ![Details tab and copy to file.](images/aadj/certlm-root-cert-details-tab.png) -6. In the **Certificate Export Wizard**, click **Next**. -7. On the **Export File Format** page of the wizard, click **Next**. -8. On the **File to Export** page in the wizard, type the name and location of the root certificate and click **Next**. Click **Finish** and then click **OK** to close the success dialog box.
+6. In the **Certificate Export Wizard**, select **Next**. +7. On the **Export File Format** page of the wizard, select **Next**. +8. On the **File to Export** page in the wizard, type the name and location of the root certificate and select **Next**. Select **Finish** and then select **OK** to close the success dialog box.
![Export root certificate.](images/aadj/certlm-export-root-certificate.png) -9. Click **OK** two times to return to the **Certificate Manager** for the local computer. Close the **Certificate Manager**. +9. Select **OK** two times to return to the **Certificate Manager** for the local computer. Close the **Certificate Manager**. ### Create and Assign a Trust Certificate Device Configuration Profile A **Trusted Certificate** device configuration profile is how you deploy trusted certificates to Azure AD-joined devices. -1. Sign-in to the [Microsoft Azure Portal](https://portal.azure.com) and select **Microsoft Intune**. -2. Click **Device configuration**. In the **Device Configuration** blade, click **Create profile**. +1. Sign-in to the [Microsoft Azure portal](https://portal.azure.com) and select **Microsoft Intune**. +2. Select **Device configuration**. In the **Device Configuration** blade, select **Create profile**. ![Intune Create Profile.](images/aadj/intune-create-device-config-profile.png) -3. In the **Create profile** blade, type **Enterprise Root Certificate** in **Name**. Provide a description. Select **Windows 10 and later** from the **Platform** list. Select **Trusted certificate** from the **Profile type** list. Click **Configure**. -4. In the **Trusted Certificate** blade, use the folder icon to browse for the location of the enterprise root certificate file you created in step 8 of [Export Enterprise Root certificate](#export-enterprise-root-certificate). Click **OK**. Click **Create**. +3. In the **Create profile** blade, type **Enterprise Root Certificate** in **Name**. Provide a description. Select **Windows 10 and later** from the **Platform** list. Select **Trusted certificate** from the **Profile type** list. Select **Configure**. +4. In the **Trusted Certificate** blade, use the folder icon to browse for the location of the enterprise root certificate file you created in step 8 of [Export Enterprise Root certificate](#export-enterprise-root-certificate). Select **OK**. Select **Create**. ![Intune Trusted Certificate Profile.](images/aadj/intune-create-trusted-certificate-profile.png) -5. In the **Enterprise Root Certificate** blade, click **Assignments**. In the **Include** tab, select **All Devices** from the **Assign to** list. Click **Save**. +5. In the **Enterprise Root Certificate** blade, select **Assignments**. In the **Include** tab, select **All Devices** from the **Assign to** list. Select **Save**. ![Intune Profile assignment.](images/aadj/intune-device-config-enterprise-root-assignment.png) -6. Sign out of the Microsoft Azure Portal. +6. Sign out of the Microsoft Azure portal. > [!NOTE] > After the creation, the **supported platform** parameter of the profile will contain the value "Windows 8.1 and later", as the certificate configuration for Windows 8.1 and Windows 10 is the same. @@ -298,14 +298,14 @@ A **Trusted Certificate** device configuration profile is how you deploy trusted Sign-in a workstation with access equivalent to a _domain user_. -1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/). +1. Sign in to the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431). 2. Select **Devices**. 3. Choose **Enroll devices**. 4. Select **Windows enrollment**. 5. Under **Windows enrollment**, select **Windows Hello for Business**. ![Create Windows Hello for Business Policy.](images/aadj/MEM.png) 6. Select **Enabled** from the **Configure Windows Hello for Business** list. -7. Select **Required** next to **Use a Trusted Platform Module (TPM)**. By default, Windows Hello for Business prefers TPM 2.0 or falls backs to software. Choosing **Required** forces Windows Hello for Business to only use TPM 2.0 or TPM 1.2 and does not allow fall back to software-based keys. +7. Select **Required** next to **Use a Trusted Platform Module (TPM)**. By default, Windows Hello for Business prefers TPM 2.0 or falls backs to software. Choosing **Required** forces Windows Hello for Business to only use TPM 2.0 or TPM 1.2 and doesn't allow fall back to software-based keys. 8. Enter the desired **Minimum PIN length** and **Maximum PIN length**. > [!IMPORTANT] > The default minimum PIN length for Windows Hello for Business on Windows 10 and Windows 11 is six. Microsoft Intune defaults the minimum PIN length to four, which reduces the security of the user's PIN. If you do not have a desired PIN length, set the minimum PIN length to six. diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md index 2d0fd8eb2a..9dbec8914c 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md @@ -25,7 +25,7 @@ If you plan to use certificates for on-premises single-sign on, then follow thes > [!IMPORTANT] > Ensure you have performed the configurations in [Azure AD-joined devices for On-premises Single-Sign On](hello-hybrid-aadj-sso-base.md) before you continue. -Steps you will perform include: +Steps you'll perform include: - [Prepare Azure AD Connect](#prepare-azure-ad-connect) - [Prepare the Network Device Enrollment Services Service Account](#prepare-the-network-device-enrollment-services-ndes-service-account) @@ -46,7 +46,7 @@ You need to install and configure additional infrastructure to provide Azure AD- The Network Device Enrollment Services (NDES) server role acts as a certificate registration authority. Certificate registration servers enroll certificates on behalf of the user. Users request certificates from the NDES service rather than directly from the issuing certificate authority. -The architecture of the NDES server prevents it from being clustered or load balanced for high availability. To provide high availability, you need to install more than one identically configured NDES servers and use Microsoft Intune to load balance then (in round-robin fashion). +The architecture of the NDES server prevents it from being clustered or load balanced for high availability. To provide high availability, you need to install more than one identically configured NDES servers, and use Microsoft Intune to load balance then (in round-robin fashion). The Network Device Enrollment Service (NDES) server role can issue up to three unique certificate templates. The server role accomplishes this by mapping the purpose of the certificate request to a configured certificate template. The certificate request purpose has three options: @@ -74,9 +74,9 @@ Sign-in to computer running Azure AD Connect with access equivalent to _local ad 1. Open **Synchronization Services** from the **Azure AD Connect** folder. -2. In the **Synchronization Service Manager**, click **Help** and then click **About**. +2. In the **Synchronization Service Manager**, select **Help** and then select **About**. -3. If the version number is not **1.1.819** or later, then upgrade Azure AD Connect to the latest version. +3. If the version number isn't **1.1.819** or later, then upgrade Azure AD Connect to the latest version. ### Verify the onPremisesDistinguishedName attribute is synchronized @@ -89,7 +89,7 @@ The easiest way to verify that the onPremisesDistingushedNamne attribute is sync > [!NOTE] > To successfully query the Graph API, adequate [permissions](/graph/api/user-get?) must be granted. -3. Select **Modify permissions (Preview)**. Scroll down and locate **User.Read.All** (or any other required permission) and select **Consent**. You will now be prompted for delegated permissions consent. +3. Select **Modify permissions (Preview)**. Scroll down and locate **User.Read.All** (or any other required permission) and select **Consent**. You'll now be prompted for delegated permissions consent. 4. In the Graph Explorer URL, enter `https://graph.microsoft.com/v1.0/users/[userid]?$select=displayName,userPrincipalName,onPremisesDistinguishedName`, where **[userid]** is the user principal name of a user in Azure Active Directory. Select **Run query**. @@ -106,7 +106,7 @@ The easiest way to verify that the onPremisesDistingushedNamne attribute is sync GET https://graph.microsoft.com/v1.0/users/{id | userPrincipalName}?$select=displayName,userPrincipalName,onPremisesDistinguishedName ``` -5. In the returned results, review the JSON data for the **onPremisesDistinguishedName** attribute. Ensure the attribute has a value and that the value is accurate for the given user. If the **onPremisesDistinguishedName** attribute is not synchronized the value will be **null**. +5. In the returned results, review the JSON data for the **onPremisesDistinguishedName** attribute. Ensure the attribute has a value and that the value is accurate for the given user. If the **onPremisesDistinguishedName** attribute isn't synchronized the value will be **null**. #### Response