mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-27 08:13:39 +00:00
Merge pull request #2222 from MicrosoftDocs/master
Publish 3/06/2020 10:32 AM PST
This commit is contained in:
Thomas Raya
GitHub
@ -17,6 +17,11 @@ ms.topic: article
|
||||
|
||||
# Monitor Windows Updates with Update Compliance
|
||||
|
||||
> [!IMPORTANT]
|
||||
> While [Windows Analytics was retired on January 31, 2020](https://docs.microsoft.com/windows/deployment/update/update-compliance-monitor), support for Update Compliance has continued through the Azure Portal; however, please note the following updates:
|
||||
>
|
||||
> * On March 31, 2020, the Windows Defender Antivirus reporting feature of Update Compliance will be removed. You can continue to define and review security compliance policies using [Microsoft Endpoint Manager](https://docs.microsoft.com/configmgr/), which allows finer control over security features and updates.
|
||||
> * The Perspectives feature of Update Compliance will also be removed on March 31, 2020 in favor of a better experience. The Perspectives feature is part of the Log Search portal of Log Analytics, which was deprecated on February 15, 2019 in favor of [Azure Monitor Logs](https://docs.microsoft.com/azure/azure-monitor/log-query/log-search-transition). Your Update Compliance solution will be automatically upgraded to Azure Monitor Logs, and the data available in Perspectives will be migrated to a set of queries in the [Needs Attention section](update-compliance-need-attention.md) of Update Compliance.
|
||||
|
||||
|
||||
## Introduction
|
||||
@ -46,8 +51,8 @@ The Update Compliance architecture and data flow follows this process:
|
||||
4. Diagnostic data is available in the Update Compliance solution.
|
||||
|
||||
|
||||
>[!NOTE]
|
||||
>This process assumes that Windows diagnostic data is enabled and data sharing is enabled as outlined in the enrollment section of [Get started with Update Compliance](update-compliance-get-started.md).
|
||||
> [!NOTE]
|
||||
> This process assumes that Windows diagnostic data is enabled and data sharing is enabled as outlined in the enrollment section of [Get started with Update Compliance](update-compliance-get-started.md).
|
||||
|
||||
|
||||
|
||||
|
||||
@ -16,6 +16,10 @@ ms.topic: article
|
||||
|
||||
# Perspectives
|
||||
|
||||
> [!IMPORTANT]
|
||||
> On March 31, 2020, the Perspectives feature of Update Compliance will be removed in favor of a better experience. The Perspectives feature is part of the Log Search portal of Log Analytics, which was deprecated on February 15, 2019 in favor of [Azure Monitor Logs](https://docs.microsoft.com/azure/azure-monitor/log-query/log-search-transition). Your Update Compliance solution will be automatically upgraded to Azure Monitor Logs, and the data available in Perspectives will be migrated to a set of queries in the [Needs Attention section](update-compliance-need-attention.md) of Update Compliance.
|
||||
|
||||
|
||||
|
||||
|
||||
Perspectives are elaborations on specific queries hand-crafted by developers which data views that provide deeper insight into your data. Perspectives are loaded whenever clicking into more detailed views from both the Security Update Status section and Feature Update Status section of Update Compliance.
|
||||
@ -33,10 +37,10 @@ The third blade is the **Deployment Status** blade. This defines how many days i
|
||||
| State | Description |
|
||||
| --- | --- |
|
||||
| Update Completed | When a device has finished the update process and is on the queried update, it will display here as Update completed. |
|
||||
| In Progress | Devices that report they are “In Progress” are one of the various stages of installing an update; these stages are reported in the Detailed Deployment Status blade. |
|
||||
| Deferred | When a device’s Windows Update for Business deferral policy dictates that the update is not yet applicable due to deferral, it will report as such in this blade. |
|
||||
| Progress stalled | Devices that report as “Progress stalled” have been stuck at “In progress” for more than 7 days. |
|
||||
| Cancelled | The update was cancelled. |
|
||||
| In Progress | Devices that report they are "In Progress" are one of the various stages of installing an update; these stages are reported in the Detailed Deployment Status blade. |
|
||||
| Deferred | When a device's Windows Update for Business deferral policy dictates that the update is not yet applicable due to deferral, it will report as such in this blade. |
|
||||
| Progress stalled | Devices that report as "Progress stalled" have been stuck at "In progress" for more than 7 days. |
|
||||
| Cancelled | The update was canceled. |
|
||||
| Blocked | There is a hard block on the update being completed. This could be that another update must be completed before this one, or some other task is blocking the installation of the update. |
|
||||
| Unknown | Devices that do not report detailed information on the status of their updates will report Unknown. This is most likely devices that do not use Windows Update for deployment. |
|
||||
| Update paused | These devices have Windows Update for Business pause enabled, preventing this update from being installed. |
|
||||
@ -48,8 +52,8 @@ The final blade is the **Detailed Deployment Status** blade. This blade breaks d
|
||||
|
||||
| State | Description |
|
||||
| --- | --- |
|
||||
| Update deferred | When a device’s Windows Update for Business policy dictates the update is deferred. |
|
||||
| Update paused | The device’s Windows Update for Business policy dictates the update is paused from being offered. |
|
||||
| Update deferred | When a device's Windows Update for Business policy dictates the update is deferred. |
|
||||
| Update paused | The device's Windows Update for Business policy dictates the update is paused from being offered. |
|
||||
| Update offered | The device has been offered the update, but has not begun downloading it. |
|
||||
| Pre-Download tasks passed | The device has finished all necessary tasks prior to downloading the update. |
|
||||
| Compatibility hold | The device has been placed under a *compatibility hold* to ensure a smooth feature update experience and will not resume the update until the hold has been cleared. For more information see [Feature Update Status report](update-compliance-feature-update-status.md#compatibility-holds) |
|
||||
@ -62,5 +66,5 @@ The final blade is the **Detailed Deployment Status** blade. This blade breaks d
|
||||
| Reboot Initiated | The scheduled reboot has been initiated. |
|
||||
| Update Completed/Commit | The update has successfully installed. |
|
||||
|
||||
>[!NOTE]
|
||||
>Interacting with any rows in the perspective view will automatically apply the given value to the query and execute it with the new parameter, narrowing the perspective to devices that satisfy that criteria. For example, clicking “Not configured (-1)” devices in Deferral Configurations will filter the query to only contain devices that do not have a deferral configuration. These filters can also be applied to queries via the filter sidebar.
|
||||
> [!NOTE]
|
||||
> Interacting with any rows in the perspective view will automatically apply the given value to the query and execute it with the new parameter, narrowing the perspective to devices that satisfy that criteria. For example, clicking "Not configured (-1)" devices in Deferral Configurations will filter the query to only contain devices that do not have a deferral configuration. These filters can also be applied to queries via the filter sidebar.
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
---
|
||||
title: Update Compliance - Windows Defender AV Status report
|
||||
title: Update Compliance - Perspectives
|
||||
ms.reviewer:
|
||||
manager: laurawi
|
||||
description: an overview of the Windows Defender AV Status report
|
||||
description: an overview of Update Compliance Perspectives
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.pagetype: deploy
|
||||
@ -14,30 +14,57 @@ ms.collection: M365-analytics
|
||||
ms.topic: article
|
||||
---
|
||||
|
||||
# Windows Defender AV Status
|
||||
# Perspectives
|
||||
|
||||
|
||||
> [!IMPORTANT]
|
||||
> On March 31, 2020, the Perspectives feature of Update Compliance will be removed in favor of a better experience. The Perspectives feature is part of the Log Search portal of Log Analytics, which was deprecated on February 15, 2019 in favor of [Azure Monitor Logs](https://docs.microsoft.com/azure/azure-monitor/log-query/log-search-transition). Your Update Compliance solution will be automatically upgraded to Azure Monitor Logs, and the data available in Perspectives will be migrated to a set of queries in the [Needs Attention section](update-compliance-need-attention.md) of Update Compliance.
|
||||
|
||||
The Windows Defender AV Status section deals with data concerning signature and threat status for devices that use Windows Defender Antivirus. The section tile in the [Overview Blade](update-compliance-using.md#overview-blade) provides the percentage of devices with insufficient protection – this percentage only considers devices using Windows Defender Antivirus.
|
||||
|
||||
>[!NOTE]
|
||||
>Update Compliance's Windows Defender Antivirus status is compatible with E3, B, F1, VL Professional and below licenses. Devices with an E5 license are not shown here; devices with an E5 license can be monitored using the [Windows Defender ATP portal](https://docs.microsoft.com/windows/security/threat-protection/windows-defender-atp/configure-endpoints-windows-defender-advanced-threat-protection). If you'd like to learn more about Windows 10 licensing, see the [Windows 10 product licensing options](https://www.microsoft.com/Licensing/product-licensing/windows10.aspx).
|
||||
|
||||
|
||||
## Windows Defender AV Status sections
|
||||
The **Protection Status** blade gives a count for devices that have either out-of-date signatures or real-time protection turned off. Below, it gives a more detailed breakdown of the two issues. Selecting any of these statuses will navigate you to a Log Search view containing the query.
|
||||
Perspectives are elaborations on specific queries hand-crafted by developers which data views that provide deeper insight into your data. Perspectives are loaded whenever clicking into more detailed views from both the Security Update Status section and Feature Update Status section of Update Compliance.
|
||||
|
||||
The **Threat Status** blade shows, among devices that have encountered threats, how many were and were not remediated successfully. It also provides a detailed count. Selecting either of these will take you to the respective query in Log Search for further investigation.
|
||||
There is only one perspective framework; it is for **Update Deployment Status**. The same framework is utilized for both feature and quality updates.
|
||||
|
||||
Here are some important terms to consider when using the Windows Defender AV Status section of Update Compliance:
|
||||
* **Signature out of date** devices are devices with a signature older than 14 days.
|
||||
* **No real-time protection** devices are devices that are using Windows Defender AV but have turned off real-time protection.
|
||||
* **Recently disappeared** devices are devices that were previously seen by Windows Defender AV and are no longer seen in the past 7 days.
|
||||
* **Remediation failed** devices are devices where Windows Defender AV failed to remediate the threat. This could be due to a number of reasons, including a full disk, network error, operation aborted, etc. Manual intervention might be needed from IT team.
|
||||
* **Not assessed** devices are devices where either a non-Microsoft AV solution is used or it has been more than 7 days since the device recently disappeared.
|
||||
The first blade is the **Build Summary** blade. This blade summarizes the most important aspects of the given build being queried, listing the total number of devices, the total number of update failures for the build, and a breakdown of the different errors encountered.
|
||||
|
||||
## Windows Defender data latency
|
||||
Because of the way Windows Defender is associated with the rest of Windows device data, Defender data for new devices might take much longer to appear than other data types. This process could take up to 28 days.
|
||||
The second blade is the **Deferral Configurations** blade, breaking down Windows Update for Business deferral settings (if any).
|
||||
|
||||
## Related topics
|
||||
## Deployment status
|
||||
|
||||
- [Windows Defender Antivirus pre-requisites](https://docs.microsoft.com/windows/security/threat-protection/windows-defender-antivirus/troubleshoot-reporting#confirm-pre-requisites)
|
||||
The third blade is the **Deployment Status** blade. This defines how many days it has been since the queried version has been released, and breaks down the various states in the update funnel each device has reported to be in. The possible states are as follows:
|
||||
|
||||
| State | Description |
|
||||
| --- | --- |
|
||||
| Update Completed | When a device has finished the update process and is on the queried update, it will display here as Update completed. |
|
||||
| In Progress | Devices that report they are "In Progress" are one of the various stages of installing an update; these stages are reported in the Detailed Deployment Status blade. |
|
||||
| Deferred | When a device's Windows Update for Business deferral policy dictates that the update is not yet applicable due to deferral, it will report as such in this blade. |
|
||||
| Progress stalled | Devices that report as "Progress stalled" have been stuck at "In progress" for more than 7 days. |
|
||||
| Cancelled | The update was canceled. |
|
||||
| Blocked | There is a hard block on the update being completed. This could be that another update must be completed before this one, or some other task is blocking the installation of the update. |
|
||||
| Unknown | Devices that do not report detailed information on the status of their updates will report Unknown. This is most likely devices that do not use Windows Update for deployment. |
|
||||
| Update paused | These devices have Windows Update for Business pause enabled, preventing this update from being installed. |
|
||||
| Failed | A device is unable to install an update. This failure could be linked to a serious error in the update installation process or, in some cases, a [compatibility hold](update-compliance-feature-update-status.md#compatibility-holds). |
|
||||
|
||||
## Detailed deployment status
|
||||
|
||||
The final blade is the **Detailed Deployment Status** blade. This blade breaks down the detailed stage of deployment a device is in, beyond the generalized terms defined in Deployment Status. The following are the possible stages a device can report:
|
||||
|
||||
| State | Description |
|
||||
| --- | --- |
|
||||
| Update deferred | When a device's Windows Update for Business policy dictates the update is deferred. |
|
||||
| Update paused | The device's Windows Update for Business policy dictates the update is paused from being offered. |
|
||||
| Update offered | The device has been offered the update, but has not begun downloading it. |
|
||||
| Pre-Download tasks passed | The device has finished all necessary tasks prior to downloading the update. |
|
||||
| Compatibility hold | The device has been placed under a *compatibility hold* to ensure a smooth feature update experience and will not resume the update until the hold has been cleared. For more information see [Feature Update Status report](update-compliance-feature-update-status.md#compatibility-holds) |
|
||||
| Download Started | The update has begun downloading on the device. |
|
||||
| Download Succeeded | The update has successfully completed downloading. |
|
||||
| Pre-Install Tasks Passed | Tasks that must be completed prior to installing the update have been completed. |
|
||||
| Install Started | Installation of the update has begun. |
|
||||
| Reboot Required | The device has finished installing the update, and a reboot is required before the update can be completed.
|
||||
| Reboot Pending | The device has a scheduled reboot to apply the update. |
|
||||
| Reboot Initiated | The scheduled reboot has been initiated. |
|
||||
| Update Completed/Commit | The update has successfully installed. |
|
||||
|
||||
> [!NOTE]
|
||||
> Interacting with any rows in the perspective view will automatically apply the given value to the query and execute it with the new parameter, narrowing the perspective to devices that satisfy that criteria. For example, clicking "Not configured (-1)" devices in Deferral Configurations will filter the query to only contain devices that do not have a deferral configuration. These filters can also be applied to queries via the filter sidebar.
|
||||
|
||||
@ -251,6 +251,9 @@ See the following examples.
|
||||
|
||||
25. Click **OK** to close the Task Sequence Editor.
|
||||
|
||||
> [!NOTE]
|
||||
> On Windows 10 1903 and 1909, the **AutopilotConfigurationFile.json** is deleted by the **Prepare Windows for Capture** step. See [Windows Autopilot - known issues](https://docs.microsoft.com/windows/deployment/windows-autopilot/known-issues) for more information and a workaround.
|
||||
|
||||
### Deploy Content to Distribution Points
|
||||
|
||||
Next, ensure that all content required for the task sequence is deployed to distribution points.
|
||||
|
||||
@ -32,9 +32,9 @@ ms.topic: article
|
||||
<li>Run the command <b>w32tm /resync /force</b> to sync the time with the default time server (time.windows.com).</ol>
|
||||
</tr>
|
||||
|
||||
<tr><td>Windows Autopilot for existing devices does not work for Windows 10, version 1903; you see screens that you've disabled in your Windows Autopilot profile, such as the Windows 10 License Agreement screen.
|
||||
<tr><td>Windows Autopilot for existing devices does not work for Windows 10, version 1903 or 1909; you see screens that you've disabled in your Windows Autopilot profile, such as the Windows 10 License Agreement screen.
|
||||
<br> <br>
|
||||
This happens because Windows 10, version 1903 deletes the AutopilotConfigurationFile.json file.
|
||||
This happens because Windows 10, version 1903 and 1909 deletes the AutopilotConfigurationFile.json file.
|
||||
<td>To fix this issue: <ol><li>Edit the Configuration Manager task sequence and disable the <b>Prepare Windows for Capture</b> step.
|
||||
<li>Add a new <b>Run command line</b> step that runs <b>c:\windows\system32\sysprep\sysprep.exe /oobe /reboot</b>.</ol>
|
||||
<a href="https://oofhours.com/2019/09/19/a-challenge-with-windows-autopilot-for-existing-devices-and-windows-10-1903/">More information</a></tr>
|
||||
|
||||
@ -26,7 +26,7 @@ ms.reviewer:
|
||||
- Key trust
|
||||
|
||||
> [!NOTE]
|
||||
>There was an issue with key trust on Windows Server 2019. To fix it, refer to [KB4487044](https://support.microsoft.com/en-us/help/4487044/windows-10-update-kb4487044).
|
||||
>There was an issue with key trust authentication on Windows Server 2019. To fix it, refer to [KB4487044](https://support.microsoft.com/en-us/help/4487044/windows-10-update-kb4487044).
|
||||
|
||||
## How many is adequate
|
||||
|
||||
|
||||
@ -15,7 +15,7 @@ manager: dansimp
|
||||
ms.collection: M365-identity-device-management
|
||||
ms.topic: article
|
||||
localizationpriority: medium
|
||||
ms.date: 08/19/2018
|
||||
ms.date: 03/05/2020
|
||||
---
|
||||
|
||||
# Windows Hello biometrics in the enterprise
|
||||
@ -28,34 +28,36 @@ Windows Hello is the biometric authentication feature that helps strengthen auth
|
||||
>[!NOTE]
|
||||
>When Windows 10 first shipped, it included Microsoft Passport and Windows Hello, which worked together to provide multi-factor authentication. To simplify deployment and improve supportability, Microsoft has combined these technologies into a single solution under the Windows Hello name. Customers who have already deployed these technologies will not experience any change in functionality. Customers who have yet to evaluate Windows Hello will find it easier to deploy due to simplified policies, documentation, and semantics.
|
||||
|
||||
Because we realize your employees are going to want to use this new technology in your enterprise, we’ve been actively working with the device manufacturers to create strict design and performance recommendations that help to ensure that you can more confidently introduce Windows Hello biometrics into your organization.
|
||||
Because we realize your employees are going to want to use this new technology in your enterprise, we've been actively working with the device manufacturers to create strict design and performance recommendations that help to ensure that you can more confidently introduce Windows Hello biometrics into your organization.
|
||||
|
||||
## How does Windows Hello work?
|
||||
Windows Hello lets your employees use fingerprint or facial recognition as an alternative method to unlocking a device. With Windows Hello, authentication happens when the employee provides his or her unique biometric identifier while accessing the device-specific Windows Hello credentials.
|
||||
|
||||
The Windows Hello authenticator works to authenticate and allow employees onto your enterprise network. Authentication doesn’t roam among devices, isn’t shared with a server, and can’t easily be extracted from a device. If multiple employees share a device, each employee will use his or her own biometric data on the device.
|
||||
The Windows Hello authenticator works to authenticate and allow employees onto your enterprise network. Authentication doesn't roam among devices, isn't shared with a server, and can't easily be extracted from a device. If multiple employees share a device, each employee will use his or her own biometric data on the device.
|
||||
|
||||
## Why should I let my employees use Windows Hello?
|
||||
Windows Hello provides many benefits, including:
|
||||
|
||||
- It helps to strengthen your protections against credential theft. Because an attacker must have both the device and the biometric info or PIN, it’s much more difficult to gain access without the employee’s knowledge.
|
||||
- It helps to strengthen your protections against credential theft. Because an attacker must have both the device and the biometric info or PIN, it's much more difficult to gain access without the employee's knowledge.
|
||||
|
||||
- Employees get a simple authentication method (backed up with a PIN) that’s always with them, so there’s nothing to lose. No more forgetting passwords!
|
||||
- Employees get a simple authentication method (backed up with a PIN) that's always with them, so there's nothing to lose. No more forgetting passwords!
|
||||
|
||||
- Support for Windows Hello is built into the operating system so you can add additional biometric devices and polices as part of a coordinated rollout or to individual employees or groups using Group Policy or Mobile Device Management (MDM) configurations service provider (CSP) policies.<br>For more info about the available Group Policies and MDM CSPs, see the [Implement Windows Hello for Business in your organization](hello-manage-in-organization.md) topic.
|
||||
|
||||
## Where is Windows Hello data stored?
|
||||
The biometric data used to support Windows Hello is stored on the local device only. It doesn’t roam and is never sent to external devices or servers. This separation helps to stop potential attackers by providing no single collection point that an attacker could potentially compromise to steal biometric data. Additionally, even if an attacker was actually able to get the biometric data, it still can’t be easily converted to a form that could be recognized by the biometric sensor.
|
||||
The biometric data used to support Windows Hello is stored on the local device only. It doesn't roam and is never sent to external devices or servers. This separation helps to stop potential attackers by providing no single collection point that an attacker could potentially compromise to steal biometric data. Additionally, even if an attacker was actually able to get the biometric data from a device, it cannot be converted back into a raw biometric sample that could be recognized by the biometric sensor.
|
||||
|
||||
Each sensor on a device will have its own biometric database file where template data is stored. Each database has a unique, randomly generated key that is encrypted to the system. The template data for the sensor will be encrypted with this per-database key using AES with CBC chaining mode. The hash is SHA256. Some fingerprint sensors have the capability to complete matching on the fingerprint sensor module instead of in the OS. These sensors will store biometric data on the fingerprint module instead of in the database file.
|
||||
|
||||
## Has Microsoft set any device requirements for Windows Hello?
|
||||
We’ve been working with the device manufacturers to help ensure a high-level of performance and protection is met by each sensor and device, based on these requirements:
|
||||
We've been working with the device manufacturers to help ensure a high-level of performance and protection is met by each sensor and device, based on these requirements:
|
||||
|
||||
- **False Accept Rate (FAR).** Represents the instance a biometric identification solution verifies an unauthorized person. This is normally represented as a ratio of number of instances in a given population size, for example 1 in 100 000. This can also be represented as a percentage of occurrence, for example, 0.001%. This measurement is heavily considered the most important with regards to the security of the biometric algorithm.
|
||||
|
||||
- **False Reject Rate (FRR).** Represents the instances a biometric identification solution fails to verify an authorized person correctly. Usually represented as a percentage, the sum of the True Accept Rate and False Reject Rate is 1. Can be with or without anti-spoofing or liveness detection.
|
||||
|
||||
### Fingerprint sensor requirements
|
||||
To allow fingerprint matching, you must have devices with fingerprint sensors and software. Fingerprint sensors, or sensors that use an employee’s unique fingerprint as an alternative log on option, can be touch sensors (large area or small area) or swipe sensors. Each type of sensor has its own set of detailed requirements that must be implemented by the manufacturer, but all of the sensors must include anti-spoofing measures (required).
|
||||
To allow fingerprint matching, you must have devices with fingerprint sensors and software. Fingerprint sensors, or sensors that use an employee's unique fingerprint as an alternative log on option, can be touch sensors (large area or small area) or swipe sensors. Each type of sensor has its own set of detailed requirements that must be implemented by the manufacturer, but all of the sensors must include anti-spoofing measures (required).
|
||||
|
||||
**Acceptable performance range for small to large size touch sensors**
|
||||
|
||||
@ -70,7 +72,7 @@ To allow fingerprint matching, you must have devices with fingerprint sensors an
|
||||
- Effective, real world FRR with Anti-spoofing or liveness detection: <10%
|
||||
|
||||
### Facial recognition sensors
|
||||
To allow facial recognition, you must have devices with integrated special infrared (IR) sensors and software. Facial recognition sensors use special cameras that see in IR light, letting them tell the difference between a photo and a living person while scanning an employee’s facial features. These sensors, like the fingerprint sensors, must also include anti-spoofing measures (required) and a way to configure them (optional).
|
||||
To allow facial recognition, you must have devices with integrated special infrared (IR) sensors and software. Facial recognition sensors use special cameras that see in IR light, letting them tell the difference between a photo and a living person while scanning an employee's facial features. These sensors, like the fingerprint sensors, must also include anti-spoofing measures (required) and a way to configure them (optional).
|
||||
|
||||
- False Accept Rate (FAR): <0.001%
|
||||
|
||||
|
||||
@ -37,7 +37,10 @@ New installations are considerably more involved than existing implementations b
|
||||
The new installation baseline begins with a basic Active Directory deployment and enterprise PKI.
|
||||
|
||||
## Active Directory
|
||||
This document expects you have Active Directory deployed with an _adequate_ number of Windows Server 2016 domain controllers for each site. Read the [Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
|
||||
This document expects you have Active Directory deployed with an _adequate_ number of Windows Server 2016 or later domain controllers for each site. Read the [Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
|
||||
|
||||
> [!NOTE]
|
||||
>There was an issue with key trust authentication on Windows Server 2019. If you are planning to use Windows Server 2019 domain controllers refer to [KB4487044](https://support.microsoft.com/en-us/help/4487044/windows-10-update-kb4487044) to fix this issue.
|
||||
|
||||
Lab environments and isolated proof of concepts may want to limit the number of domain controllers. The purpose of these environments is to experiment and learn. Reducing the number of domain controllers can prevent troubleshooting issue, such as Active Directory replication, which is unrelated to activity's goal.
|
||||
|
||||
@ -93,7 +96,7 @@ If you do not have an existing public key infrastructure, please review [Certifi
|
||||
> * Highly available certificate revocation list (Azure AD Joined devices).
|
||||
|
||||
## Azure Active Directory
|
||||
You’ve prepared your Active Directory. Hybrid Windows Hello for Business deployment needs Azure Active Directory to host your cloud-based identities.
|
||||
You've prepared your Active Directory. Hybrid Windows Hello for Business deployment needs Azure Active Directory to host your cloud-based identities.
|
||||
|
||||
The next step of the deployment is to follow the [Creating an Azure AD tenant](https://docs.microsoft.com/azure/active-directory/develop/active-directory-howto-tenant) process to provision an Azure tenant for your organization.
|
||||
|
||||
|
||||
@ -42,6 +42,9 @@ A hybrid Windows Hello for Business deployment needs an Azure Active Directory s
|
||||
|
||||
You can deploy Windows Hello for Business in any environment with Windows Server 2008 R2 or later domain controllers. However, the key trust deployment needs an ***adequate*** number of Windows Server 2016 or later domain controllers at each site where users authenticate using Windows Hello for Business. Read the [Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
|
||||
|
||||
> [!NOTE]
|
||||
>There was an issue with key trust authentication on Windows Server 2019. If you are planning to use Windows Server 2019 domain controllers refer to [KB4487044](https://support.microsoft.com/en-us/help/4487044/windows-10-update-kb4487044) to fix this issue.
|
||||
|
||||
Review these requirements and those from the Windows Hello for Business planning guide and worksheet. Based on your deployment decisions you may need to upgrade your on-premises Active Directory or your Azure Active Directory subscription to meet your needs.
|
||||
|
||||
### Section Review
|
||||
@ -112,7 +115,7 @@ You can deploy Windows Hello for Business key trust in non-federated and federat
|
||||
|
||||
Windows Hello for Business is a strong, two-factor credential the helps organizations reduce their dependency on passwords. The provisioning process lets a user enroll in Windows Hello for Business using their user name and password as one factor, but needs a second factor of authentication.
|
||||
|
||||
Hybrid Windows Hello for Business deployments can use Azure’s Multifactor Authentication (MFA) service or they can use multifactor authentication provided by AD FS beginning with Windows Server 2012 R2, which includes an adapter model that enables third parties to integrate their MFA into AD FS. The MFA enabled by an Office 365 license is sufficient for Azure AD.
|
||||
Hybrid Windows Hello for Business deployments can use Azure's Multifactor Authentication (MFA) service or they can use multifactor authentication provided by AD FS beginning with Windows Server 2012 R2, which includes an adapter model that enables third parties to integrate their MFA into AD FS. The MFA enabled by an Office 365 license is sufficient for Azure AD.
|
||||
|
||||
### Section Review
|
||||
> [!div class="checklist"]
|
||||
|
||||
@ -25,7 +25,10 @@ ms.reviewer:
|
||||
- Key trust
|
||||
|
||||
|
||||
Key trust deployments need an adequate number of 2016 domain controllers to ensure successful user authentication with Windows Hello for Business. To learn more about domain controller planning for key trust deployments, read the [Windows Hello for Business planning guide](hello-planning-guide.md), the [Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) section.
|
||||
Key trust deployments need an adequate number of 2016 or later domain controllers to ensure successful user authentication with Windows Hello for Business. To learn more about domain controller planning for key trust deployments, read the [Windows Hello for Business planning guide](hello-planning-guide.md), the [Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) section.
|
||||
|
||||
> [!NOTE]
|
||||
>There was an issue with key trust authentication on Windows Server 2019. If you are planning to use Windows Server 2019 domain controllers refer to [KB4487044](https://support.microsoft.com/en-us/help/4487044/windows-10-update-kb4487044) to fix this issue.
|
||||
|
||||
The key registration process for the On-premises deployment of Windows Hello for Business needs the Windows Server 2016 Active Directory schema. The key-trust model receives the schema extension when the first Windows Server 2016 domain controller is added to the forest. The minimum required domain functional and forest functional levels for Windows Hello for Business deployment is Windows Server 2008 R2.
|
||||
|
||||
|
||||
@ -44,19 +44,12 @@ As an administrator in an enterprise or educational organization, you can create
|
||||
|
||||
## Biometric sign-in
|
||||
|
||||
Windows Hello provides reliable, fully integrated biometric authentication based on facial recognition or fingerprint matching. Windows Hello uses a combination of special infrared (IR) cameras and software to increase accuracy and guard against spoofing. Major hardware vendors are shipping devices that have integrated Windows Hello-compatible cameras. Fingerprint reader hardware can be used or added to devices that don’t currently have it. On devices that support Windows Hello, an easy biometric gesture unlocks users’ credentials.
|
||||
Windows Hello provides reliable, fully integrated biometric authentication based on facial recognition or fingerprint matching. Windows Hello uses a combination of special infrared (IR) cameras and software to increase accuracy and guard against spoofing. Major hardware vendors are shipping devices that have integrated Windows Hello-compatible cameras. Fingerprint reader hardware can be used or added to devices that don't currently have it. On devices that support Windows Hello, an easy biometric gesture unlocks users' credentials.
|
||||
|
||||
- **Facial recognition**. This type of biometric recognition uses special cameras that see in IR light, which allows them to reliably tell the difference between a photograph or scan and a living person. Several vendors are shipping external cameras that incorporate this technology, and major laptop manufacturers are incorporating it into their devices, as well.
|
||||
- **Fingerprint recognition**. This type of biometric recognition uses a capacitive fingerprint sensor to scan your fingerprint. Fingerprint readers have been available for Windows computers for years, but the current generation of sensors is significantly more reliable and less error-prone. Most existing fingerprint readers (whether external or integrated into laptops or USB keyboards) work with Windows 10.
|
||||
|
||||
Windows stores biometric data that is used to implement Windows Hello securely on the local device only. The biometric data doesn’t roam and is never sent to external devices or servers. Because Windows Hello only stores biometric identification data on the device, there’s no single collection point an attacker can compromise to steal biometric data.
|
||||
|
||||
## From Windows 10 version 1803, the Windows Hello feature can be used as a safe and secure sign-in method.
|
||||
Fingerprint scan can be enabled on laptop computers using a built-in fingerprint reader or an external USB fingerprint reader, as follows:
|
||||
1. Go to **Settings** > **Accounts** > **Sign-in-options** > **Windows Hello Fingerprint** > **Add fingerprint**
|
||||
2. Users will need to add a PIN after adding their fingerprint(s) to the reader configuration.
|
||||
3. Windows Biometric data is located in the `C:\Windows\System32\WinBioDatabase\` folder (fingerprint data is stored with the .DAT file name extension).
|
||||
4. If you are unable to sign in with previously registered fingerprints, delete the entire content of this folder and register your fingerprints again.
|
||||
Windows stores biometric data that is used to implement Windows Hello securely on the local device only. The biometric data doesn't roam and is never sent to external devices or servers. Because Windows Hello only stores biometric identification data on the device, there's no single collection point an attacker can compromise to steal biometric data. For more information about biometric authentication with Windows Hello for Business, see [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md).
|
||||
|
||||
## The difference between Windows Hello and Windows Hello for Business
|
||||
|
||||
|
||||
@ -23,13 +23,13 @@ ms.reviewer:
|
||||
|
||||
Congratulations! You are taking the first step forward in helping move your organizations away from password to a two-factor, convenience authentication for Windows — Windows Hello for Business. This planning guide helps you understand the different topologies, architectures, and components that encompass a Windows Hello for Business infrastructure.
|
||||
|
||||
This guide explains the role of each component within Windows Hello for Business and how certain deployment decisions affect other aspects of the infrastructure. Armed with your planning worksheet, you’ll use that information to select the correct deployment guide for your needs.
|
||||
This guide explains the role of each component within Windows Hello for Business and how certain deployment decisions affect other aspects of the infrastructure. Armed with your planning worksheet, you'll use that information to select the correct deployment guide for your needs.
|
||||
|
||||
## Using this guide
|
||||
|
||||
There are many options from which you can choose when deploying Windows Hello for Business. Providing multiple options ensures nearly every organization can deploy Windows Hello for Business. Providing many options makes the deployment appear complex, however, most organization will realize they’ve already implemented most of the infrastructure on which the Windows Hello for Business deployment depends. It is important to understand that Windows Hello for Business is a distributed system and does take proper planning across multiple teams within an organization.
|
||||
There are many options from which you can choose when deploying Windows Hello for Business. Providing multiple options ensures nearly every organization can deploy Windows Hello for Business. Providing many options makes the deployment appear complex, however, most organization will realize they've already implemented most of the infrastructure on which the Windows Hello for Business deployment depends. It is important to understand that Windows Hello for Business is a distributed system and does take proper planning across multiple teams within an organization.
|
||||
|
||||
This guide removes the appearance of complexity by helping you make decisions on each aspect of your Windows Hello for Business deployment and the options you’ll need to consider. Using this guide also identifies the information needed to help you make decisions about the deployment that best suits your environment. Download the [Windows Hello for Business planning worksheet](https://go.microsoft.com/fwlink/?linkid=852514) from the Microsoft Download Center to help track your progress and make your planning easier.
|
||||
This guide removes the appearance of complexity by helping you make decisions on each aspect of your Windows Hello for Business deployment and the options you'll need to consider. Using this guide also identifies the information needed to help you make decisions about the deployment that best suits your environment. Download the [Windows Hello for Business planning worksheet](https://go.microsoft.com/fwlink/?linkid=852514) from the Microsoft Download Center to help track your progress and make your planning easier.
|
||||
|
||||
### How to Proceed
|
||||
|
||||
@ -80,13 +80,13 @@ The on-premises deployment model is for organizations that do not have cloud ide
|
||||
> Reset above lock screen - Windows 10, version 1709, Professional</br>
|
||||
> Reset above lock screen (_I forgot my PIN_ link) - Windows 10, version 1903
|
||||
|
||||
It’s fundamentally important to understand which deployment model to use for a successful deployment. Some aspects of the deployment may have already been decided for you based on your current infrastructure.
|
||||
It's fundamentally important to understand which deployment model to use for a successful deployment. Some aspects of the deployment may have already been decided for you based on your current infrastructure.
|
||||
|
||||
#### Trust types
|
||||
|
||||
A deployment's trust type defines how each Windows Hello for Business client authenticates to the on-premises Active Directory. There are two trust types: key trust and certificate trust.
|
||||
|
||||
The key trust type does not require issuing authentication certificates to end users. Users authenticate using a hardware-bound key created during the built-in provisioning experience. This requires an adequate distribution of Windows Server 2016 domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment. Read the [Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
|
||||
The key trust type does not require issuing authentication certificates to end users. Users authenticate using a hardware-bound key created during the built-in provisioning experience. This requires an adequate distribution of Windows Server 2016 or later domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment. Read the [Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
|
||||
|
||||
The certificate trust type issues authentication certificates to end users. Users authenticate using a certificate requested using a hardware-bound key created during the built-in provisioning experience. Unlike key trust, certificate trust does not require Windows Server 2016 domain controllers (but still requires [Windows Server 2016 Active Directory schema](https://docs.microsoft.com/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-prereqs#directories)). Users can use their certificate to authenticate to any Windows Server 2008 R2, or later, domain controller.
|
||||
|
||||
@ -99,14 +99,14 @@ All devices included in the Windows Hello for Business deployment must go throug
|
||||
|
||||
#### Key registration
|
||||
|
||||
The built-in Windows Hello for Business provisioning experience creates a hardware bound asymmetric key pair as their user’s credentials. The private key is protected by the device’s security modules; however, the credential is a user key (not a device key). The provisioning experience registers the user’s public key with the identity provider. For cloud only and hybrid deployments, the identity provider is Azure Active Directory. For on-premises deployments, the identity provider is the on-premises server running Windows Server 2016 Active Directory Federation Services (AD FS) role.
|
||||
The built-in Windows Hello for Business provisioning experience creates a hardware bound asymmetric key pair as their user's credentials. The private key is protected by the device's security modules; however, the credential is a user key (not a device key). The provisioning experience registers the user's public key with the identity provider. For cloud only and hybrid deployments, the identity provider is Azure Active Directory. For on-premises deployments, the identity provider is the on-premises server running Windows Server 2016 Active Directory Federation Services (AD FS) role.
|
||||
|
||||
#### Multifactor authentication
|
||||
|
||||
> [!IMPORTANT]
|
||||
> As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who require multi-factor authentication for their users should use cloud-based Azure Multi-Factor Authentication. Existing customers who have activated MFA Server prior to July 1, 2019 will be able to download the latest version, future updates and generate activation credentials as usual. See [Getting started with the Azure Multi-Factor Authentication Server](https://docs.microsoft.com/azure/active-directory/authentication/howto-mfaserver-deploy) for more details.
|
||||
|
||||
The goal of Windows Hello for Business is to move organizations away from passwords by providing them a strong credential that provides easy two-factor authentication. The built-in provisioning experience accepts the user’s weak credentials (username and password) as the first factor authentication; however, the user must provide a second factor of authentication before Windows provisions a strong credential.
|
||||
The goal of Windows Hello for Business is to move organizations away from passwords by providing them a strong credential that provides easy two-factor authentication. The built-in provisioning experience accepts the user's weak credentials (username and password) as the first factor authentication; however, the user must provide a second factor of authentication before Windows provisions a strong credential.
|
||||
|
||||
Cloud only and hybrid deployments provide many choices for multi-factor authentication. On-premises deployments must use a multi-factor authentication that provides an AD FS multi-factor adapter to be used in conjunction with the on-premises Windows Server 2016 AD FS server role. Organizations can use the on-premises Azure Multi-factor Authentication server, or choose from several third parties (Read [Microsoft and third-party additional authentication methods](https://docs.microsoft.com/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods) for more information).
|
||||
> [!NOTE]
|
||||
@ -156,9 +156,9 @@ Some deployment combinations require an Azure account, and some require Azure Ac
|
||||
|
||||
## Planning a Deployment
|
||||
|
||||
Planning your Windows Hello for Business deployment begins with choosing a deployment type. Like all distributed systems, Windows Hello for Business depends on multiple components within your organization’s infrastructure.
|
||||
Planning your Windows Hello for Business deployment begins with choosing a deployment type. Like all distributed systems, Windows Hello for Business depends on multiple components within your organization's infrastructure.
|
||||
|
||||
Use the remainder of this guide to help with planning your deployment. As you make decisions, write the results of those decisions in your planning worksheet. When finished, you’ll have all the information needed to complete the planning process and the appropriate deployment guide that best helps you with your deployment.
|
||||
Use the remainder of this guide to help with planning your deployment. As you make decisions, write the results of those decisions in your planning worksheet. When finished, you'll have all the information needed to complete the planning process and the appropriate deployment guide that best helps you with your deployment.
|
||||
|
||||
### Deployment Model
|
||||
|
||||
@ -170,8 +170,8 @@ If your organization is federated with Azure or uses any online service, such as
|
||||
|
||||
If your organization does not have cloud resources, write **On-Premises** in box **1a** on your planning worksheet.
|
||||
> [!NOTE]
|
||||
> If you’re unsure if your organization is federated, run the following Active Directory Windows PowerShell command from an elevated Windows PowerShell prompt and evaluate the results.
|
||||
> ```Get-AdObject “CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=corp,DC=[forest_root_CN_name],DC=com" -Properties keywords```
|
||||
> If you're unsure if your organization is federated, run the following Active Directory Windows PowerShell command from an elevated Windows PowerShell prompt and evaluate the results.
|
||||
> ```Get-AdObject "CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=corp,DC=[forest_root_CN_name],DC=com" -Properties keywords```
|
||||
> * If the command returns an error stating it could not find the object, then you have yet to configured AAD Connect or on-premises Device Registration Services using AD FS. Ensure the name is accurate and validate the object does not exist with another Active Directory Management tool such as **ADSIEdit.msc**. If the object truly does not exist, then your environment does not bind you to a specific deployment or require changes to accommodate the desired deployment type.
|
||||
> * If the command returns a value, compare that value with the values below. The value indicates the deployment model you should implement
|
||||
> * If the value begins with **azureADName:** – write **Hybrid** in box **1a**on your planning worksheet.
|
||||
@ -209,13 +209,13 @@ If box **1a** on your planning worksheet reads **on-premises**, write **AD FS**
|
||||
|
||||
### Directory Synchronization
|
||||
|
||||
Windows Hello for Business is strong user authentication, which usually means there is an identity (a user or username) and a credential (typically a key pair). Some operations require writing or reading user data to or from the directory. For example, reading the user’s phone number to perform multi-factor authentication during provisioning or writing the user’s public key.
|
||||
Windows Hello for Business is strong user authentication, which usually means there is an identity (a user or username) and a credential (typically a key pair). Some operations require writing or reading user data to or from the directory. For example, reading the user's phone number to perform multi-factor authentication during provisioning or writing the user's public key.
|
||||
|
||||
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **1e**. User information is written directly to Azure Active Directory and there is not another directory with which the information must be synchronized.
|
||||
|
||||
If box **1a** on your planning worksheet reads **hybrid**, then write **Azure AD Connect** in box **1e** on your planning worksheet.
|
||||
|
||||
If box **1a** on your planning worksheet reads **on-premises**, then write **Azure MFA Server**. This deployment exclusively uses Active Directory for user information with the exception of the multi-factor authentication. The on-premises Azure MFA server synchronizes a subset of the user information, such as phone number, to provide multi-factor authentication while the user’s credentials remain on the on-premises network.
|
||||
If box **1a** on your planning worksheet reads **on-premises**, then write **Azure MFA Server**. This deployment exclusively uses Active Directory for user information with the exception of the multi-factor authentication. The on-premises Azure MFA server synchronizes a subset of the user information, such as phone number, to provide multi-factor authentication while the user's credentials remain on the on-premises network.
|
||||
|
||||
### Multifactor Authentication
|
||||
|
||||
@ -341,6 +341,6 @@ Modern managed devices do not require an Azure AD premium subscription. By forg
|
||||
|
||||
If boxes **2a** or **2b** read **modern management** and you want devices to automatically enroll in your modern management software, write **Yes** in box **6c** on your planning worksheet. Otherwise, write **No** in box **6c**.
|
||||
|
||||
## Congratulations, You’re Done
|
||||
## Congratulations, You're Done
|
||||
|
||||
Your Windows Hello for Business planning worksheet should be complete. This guide provided understanding of the components used in the Windows Hello for Business infrastructure and rationalization of why they are used. The worksheet gives you an overview of the requirements needed to continue the next phase of the deployment. With this worksheet, you’ll be able to identify key elements of your Windows Hello for Business deployment.
|
||||
Your Windows Hello for Business planning worksheet should be complete. This guide provided understanding of the components used in the Windows Hello for Business infrastructure and rationalization of why they are used. The worksheet gives you an overview of the requirements needed to continue the next phase of the deployment. With this worksheet, you'll be able to identify key elements of your Windows Hello for Business deployment.
|
||||
|
||||
@ -153,7 +153,7 @@ In order to preview new features and provide early feedback, it is recommended t
|
||||
- Install the Microsoft GPG public key:
|
||||
|
||||
```bash
|
||||
curl https://packages.microsoft.com/keys/microsoft.asc | apt-key add -
|
||||
curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
|
||||
```
|
||||
|
||||
- Install the https driver if it's not already present:
|
||||
|
||||
@ -35,7 +35,7 @@ This topic describes the structure of this profile (including a recommended prof
|
||||
|
||||
The configuration profile is a .json file that consists of entries identified by a key (which denotes the name of the preference), followed by a value, which depends on the nature of the preference. Values can be simple, such as a numerical value, or complex, such as a nested list of preferences.
|
||||
|
||||
Typically, you would use a configuration management tool to push a file with the name ```mdatp_maanged.json``` at the location ```/etc/opt/microsoft/mdatp/managed/```.
|
||||
Typically, you would use a configuration management tool to push a file with the name ```mdatp_managed.json``` at the location ```/etc/opt/microsoft/mdatp/managed/```.
|
||||
|
||||
The top level of the configuration profile includes product-wide preferences and entries for subareas of the product, which are explained in more detail in the next sections.
|
||||
|
||||
@ -51,7 +51,7 @@ The *antivirusEngine* section of the configuration profile is used to manage the
|
||||
|
||||
#### Enable / disable real-time protection
|
||||
|
||||
Detemines whether real-time protection (scan files as they are accessed) is enabled or not.
|
||||
Determines whether real-time protection (scan files as they are accessed) is enabled or not.
|
||||
|
||||
|||
|
||||
|:---|:---|
|
||||
@ -61,7 +61,7 @@ Detemines whether real-time protection (scan files as they are accessed) is enab
|
||||
|
||||
#### Enable / disable passive mode
|
||||
|
||||
Detemines whether the antivirus engine runs in passive mode or not. In passive mode:
|
||||
Determines whether the antivirus engine runs in passive mode or not. In passive mode:
|
||||
- Real-time protection is turned off.
|
||||
- On-demand scanning is turned on.
|
||||
- Automatic threat remediation is turned off.
|
||||
@ -351,6 +351,16 @@ The following configuration profile contains entries for all settings described
|
||||
}
|
||||
```
|
||||
|
||||
## Configuration profile validation
|
||||
|
||||
The configuration profile must be a valid JSON-formatted file. There are a number of tools that can be used to verify this. For example, if you have `python` installed on your device:
|
||||
|
||||
```bash
|
||||
$ python -m json.tool mdatp_managed.json
|
||||
```
|
||||
|
||||
If the JSON is well-formed, the above command outputs it back to the Terminal and returns an exit code of `0`. Otherwise, an error that describes the issue is displayed and the command returns an exit code of `1`.
|
||||
|
||||
## Configuration profile deployment
|
||||
|
||||
Once you've built the configuration profile for your enterprise, you can deploy it through the management tool that your enterprise is using. Microsoft Defender ATP for Linux reads the managed configuration from the */etc/opt/microsoft/mdatp/managed/mdatp_managed.json* file.
|
||||
|
||||
@ -730,13 +730,24 @@ The following configuration profile contains entries for all settings described
|
||||
</array>
|
||||
```
|
||||
|
||||
## Configuration profile validation
|
||||
|
||||
The configuration profile must be a valid *.plist* file. This can be checked by executing:
|
||||
|
||||
```bash
|
||||
$ plutil -lint com.microsoft.wdav.plist
|
||||
com.microsoft.wdav.plist: OK
|
||||
```
|
||||
|
||||
If the configuration profile is well-formed, the above command outputs `OK` and returns an exit code of `0`. Otherwise, an error that describes the issue is displayed and the command returns an exit code of `1`.
|
||||
|
||||
## Configuration profile deployment
|
||||
|
||||
Once you've built the configuration profile for your enterprise, you can deploy it through the management console that your enterprise is using. The following sections provide instructions on how to deploy this profile using JAMF and Intune.
|
||||
|
||||
### JAMF deployment
|
||||
|
||||
From the JAMF console, open **Computers** > **Configuration Profiles**, navigate to the configuration profile you'd like to use, then select **Custom Settings**. Create an entry with `com.microsoft.wdav` as the preference domain and upload the .plist produced earlier.
|
||||
From the JAMF console, open **Computers** > **Configuration Profiles**, navigate to the configuration profile you'd like to use, then select **Custom Settings**. Create an entry with `com.microsoft.wdav` as the preference domain and upload the *.plist* produced earlier.
|
||||
|
||||
>[!CAUTION]
|
||||
>You must enter the correct preference domain (`com.microsoft.wdav`); otherwise, the preferences will not be recognized by Microsoft Defender ATP.
|
||||
|
||||
Reference in New Issue
Block a user