mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-15 02:13:43 +00:00
Merge branch 'main' into sheshachary-6270627
This commit is contained in:
Shesh
GitHub
@ -21,6 +21,7 @@
|
||||
"files": [
|
||||
"**/*.png",
|
||||
"**/*.jpg",
|
||||
"**/*.svg",
|
||||
"**/*.gif"
|
||||
],
|
||||
"exclude": [
|
||||
|
||||
@ -1,104 +0,0 @@
|
||||
---
|
||||
title: Enable or block Windows Mixed Reality apps in the enterprise (Windows 10/11)
|
||||
description: Learn how to enable Windows Mixed Reality apps in WSUS or block the Windows Mixed Reality portal in enterprises.
|
||||
ms.reviewer:
|
||||
author: nicholasswhite
|
||||
ms.author: nwhite
|
||||
manager: aaroncz
|
||||
ms.prod: w10
|
||||
ms.localizationpriority: medium
|
||||
ms.topic: article
|
||||
---
|
||||
|
||||
# Enable or block Windows Mixed Reality apps in enterprises
|
||||
|
||||
[!INCLUDE [Applies to Windows client versions](./includes/applies-to-windows-client-versions.md)]
|
||||
|
||||
|
||||
[Windows Mixed Reality](https://blogs.windows.com/windowsexperience/2017/10/03/the-era-of-windows-mixed-reality-begins-october-17/) was introduced in Windows 10, version 1709 (also known as the Fall Creators Update), as a [Windows Feature on Demand (FOD)](/windows-hardware/manufacture/desktop/features-on-demand-v2--capabilities). Features on Demand are Windows feature packages that can be added at any time. When a Windows client needs a new feature, it can request the feature package from Windows Update.
|
||||
|
||||
Organizations that use Windows Server Update Services (WSUS) must take action to [enable Windows Mixed Reality](#enable-windows-mixed-reality-in-wsus). Any organization that wants to prohibit use of Windows Mixed Reality can [block the installation of the Mixed Reality Portal](#block-the-mixed-reality-portal).
|
||||
|
||||
## Enable Windows Mixed Reality in WSUS
|
||||
|
||||
1. [Check your version of Windows.](https://support.microsoft.com/help/13443/windows-which-operating-system)
|
||||
|
||||
>[!NOTE]
|
||||
>You must be on at least Windows 10, version 1709, to run Windows Mixed Reality.
|
||||
|
||||
2. Windows Mixed Reality Feature on Demand (FOD) is downloaded from Windows Update. If access to Windows Update is blocked, you must manually install the Windows Mixed Reality FOD.
|
||||
|
||||
1. Download the FOD .cab file:
|
||||
|
||||
- [Windows 11, version 21H2](https://software-download.microsoft.com/download/sg/Microsoft-Windows-Holographic-Desktop-FOD-Package~31bf3856ad364e35~amd_64~~.cab)
|
||||
- [Windows 10, version 2004](https://software-static.download.prss.microsoft.com/pr/download/6cf73b63/Microsoft-Windows-Holographic-Desktop-FOD-Package~31bf3856ad364e35~amd64~~.cab)
|
||||
- [Windows 10, version 1903 and 1909](https://software-download.microsoft.com/download/pr/Microsoft-Windows-Holographic-Desktop-FOD-Package-31bf3856ad364e35-amd64.cab)
|
||||
- [Windows 10, version 1809](https://software-download.microsoft.com/download/pr/microsoft-windows-holographic-desktop-fod-package31bf3856ad364e35amd64_1.cab)
|
||||
- [Windows 10, version 1803](https://download.microsoft.com/download/9/9/3/9934B163-FA01-4108-A38A-851B4ACD1244/Microsoft-Windows-Holographic-Desktop-FOD-Package~31bf3856ad364e35~amd64~~.cab)
|
||||
- [Windows 10, version 1709](https://download.microsoft.com/download/6/F/8/6F816172-AC7D-4F45-B967-D573FB450CB7/Microsoft-Windows-Holographic-Desktop-FOD-Package.cab)
|
||||
|
||||
> [!NOTE]
|
||||
> You must download the FOD .cab file that matches your operating system version.
|
||||
|
||||
1. Use `Dism` to add Windows Mixed Reality FOD to the image.
|
||||
|
||||
```powershell
|
||||
Dism /Online /Add-Package /PackagePath:(path)
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> On Windows 10 and 11, you must rename the FOD .CAB file to: **Microsoft-Windows-Holographic-Desktop-FOD-Package~31bf3856ad364e35~amd64~~.cab**
|
||||
|
||||
1. In **Settings** > **Update & Security** > **Windows Update**, select **Check for updates**.
|
||||
|
||||
|
||||
IT admins can also create [Side by side feature store (shared folder)](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj127275(v=ws.11)) to allow access to the Windows Mixed Reality FOD.
|
||||
|
||||
## Block the Mixed Reality Portal
|
||||
|
||||
You can use the [AppLocker configuration service provider (CSP)](/windows/client-management/mdm/applocker-csp) to block the Mixed Reality software.
|
||||
|
||||
In the following example, the **Id** can be any generated GUID and the **Name** can be any name you choose. `BinaryName="*"` allows you to block any app executable in the Mixed Reality Portal package. **Binary/VersionRange**, as shown in the example, will block all versions of the Mixed Reality Portal app.
|
||||
|
||||
```xml
|
||||
<SyncML xmlns="SYNCML:SYNCML1.2">
|
||||
<SyncBody>
|
||||
<Add>
|
||||
<CmdID>$CmdID$</CmdID>
|
||||
<Item>
|
||||
<Target>
|
||||
<LocURI>./Vendor/MSFT/PolicyManager/My/ApplicationManagement/ApplicationRestrictions</LocURI>
|
||||
</Target>
|
||||
<Meta>
|
||||
<Format xmlns="syncml:metinf">chr</Format>
|
||||
<Type xmlns="syncml:metinf">text/plain</Type>
|
||||
</Meta>
|
||||
<Data>
|
||||
<RuleCollection Type="Appx" EnforcementMode="Enabled">
|
||||
<FilePublisherRule Id="a9e18c21-ff8f-43cf-b9fc-db40eed693ba" Name="(Default Rule) All signed packaged apps" Description="Allows members of the Everyone group to run packaged apps that are signed." UserOrGroupSid="S-1-1-0" Action="Allow">
|
||||
<Conditions>
|
||||
<FilePublisherCondition PublisherName="*" ProductName="*" BinaryName="*">
|
||||
<BinaryVersionRange LowSection="0.0.0.0" HighSection="*" />
|
||||
</FilePublisherCondition>
|
||||
</Conditions>
|
||||
</FilePublisherRule>
|
||||
<FilePublisherRule Id="d26da4e7-0b01-484d-a8d3-d5b5341b2d55" Name="Block Mixed Reality Portal" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
|
||||
<Conditions>
|
||||
<FilePublisherCondition PublisherName="CN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" ProductName="Microsoft.Windows.HolographicFirstRun" BinaryName="*">
|
||||
<BinaryVersionRange LowSection="*" HighSection="*" />
|
||||
</FilePublisherCondition>
|
||||
</Conditions>
|
||||
</FilePublisherRule>
|
||||
</RuleCollection>>
|
||||
</Data>
|
||||
</Item>
|
||||
</Add>
|
||||
<Final/>
|
||||
</SyncBody>
|
||||
</SyncML>
|
||||
```
|
||||
|
||||
|
||||
## Related articles
|
||||
|
||||
- [Mixed reality](https://developer.microsoft.com/windows/mixed-reality/mixed_reality)
|
||||
@ -21,6 +21,7 @@
|
||||
"files": [
|
||||
"**/*.png",
|
||||
"**/*.jpg",
|
||||
"**/*.svg",
|
||||
"**/*.gif"
|
||||
],
|
||||
"exclude": [
|
||||
|
||||
BIN
windows/client-management/images/quick-assist-get.png
Normal file
BIN
windows/client-management/images/quick-assist-get.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 6.1 KiB |
@ -18,13 +18,13 @@ The table below shows the applicability of Windows:
|
||||
|Edition|Windows 10|Windows 11|
|
||||
|--- |--- |--- |
|
||||
|Home|No|No|
|
||||
|Pro|No|Yes|
|
||||
|Windows SE|No|Yes|
|
||||
|Pro|Yes|Yes|
|
||||
|Windows SE|Yes|Yes|
|
||||
|Business|No|No|
|
||||
|Enterprise|No|Yes|
|
||||
|Education|No|Yes|
|
||||
|Enterprise|Yes|Yes|
|
||||
|Education|Yes|Yes|
|
||||
|
||||
The Language Pack Management CSP allows a direct way to provision languages remotely in Windows. MDMs like Intune can use management commands remotely to devices to configure language-related settings for System and new users.
|
||||
The Language Pack Management CSP allows a way to easily add languages and related language features and manage settings like System Preferred UI Language, System Locale, Input method (Keyboard), Locale, Speech Recognizer, User Preferred Language List. This CSP can be accessed using the new [LanguagePackManagement](/powershell/module/languagepackmanagement) PowerShell module.
|
||||
|
||||
1. Enumerate installed languages and features with GET command on the "InstalledLanguages" node. Below are the samples:
|
||||
|
||||
@ -95,4 +95,4 @@ The Language Pack Management CSP allows a direct way to provision languages remo
|
||||
|
||||
## Related topics
|
||||
|
||||
[Configuration service provider reference](configuration-service-provider-reference.md)
|
||||
[Configuration service provider reference](configuration-service-provider-reference.md)
|
||||
|
||||
@ -57,11 +57,13 @@ ms.date: 08/01/2022
|
||||
- [MixedReality/AutoLogonUser](./policy-csp-mixedreality.md#mixedreality-autologonuser) <sup>11</sup>
|
||||
- [MixedReality/BrightnessButtonDisabled](./policy-csp-mixedreality.md#mixedreality-brightnessbuttondisabled) <sup>9</sup>
|
||||
- [MixedReality/ConfigureMovingPlatform](policy-csp-mixedreality.md#mixedreality-configuremovingplatform) <sup>*[Feb. 2022 Servicing release](/hololens/hololens-release-notes#windows-holographic-version-21h2---february-2022-update)</sup>
|
||||
- [MixedReality/ConfigureNtpClient](./policy-csp-mixedreality.md#mixedreality-configurentpclient) <sup>Insider</sup>
|
||||
- [MixedReality/DisallowNetworkConnectivityPassivePolling](./policy-csp-mixedreality.md#mixedreality-disablesisallownetworkconnectivitypassivepolling) <sup>Insider</sup>
|
||||
- [MixedReality/FallbackDiagnostics](./policy-csp-mixedreality.md#mixedreality-fallbackdiagnostics) <sup>9</sup>
|
||||
- [MixedReality/HeadTrackingMode](policy-csp-mixedreality.md#mixedreality-headtrackingmode) <sup>9</sup>
|
||||
- [MixedReality/ManualDownDirectionDisabled](policy-csp-mixedreality.md#mixedreality-manualdowndirectiondisabled) <sup>*[Feb. 2022 Servicing release](/hololens/hololens-release-notes#windows-holographic-version-21h2---february-2022-update)</sup>
|
||||
- [MixedReality/MicrophoneDisabled](./policy-csp-mixedreality.md#mixedreality-microphonedisabled) <sup>9</sup>
|
||||
- [MixedReality/NtpClientEnabled](./policy-csp-mixedreality.md#mixedreality-ntpclientenabled) <sup>Insider</sup>
|
||||
- [MixedReality/SkipCalibrationDuringSetup](./policy-csp-mixedreality.md#mixedreality-skipcalibrationduringsetup) <sup>Insider</sup>
|
||||
- [MixedReality/SkipTrainingDuringSetup](./policy-csp-mixedreality.md#mixedreality-skiptrainingduringsetup) <sup>Insider</sup>
|
||||
- [MixedReality/VisitorAutoLogon](policy-csp-mixedreality.md#mixedreality-visitorautologon) <sup>10</sup>
|
||||
|
||||
@ -36,6 +36,9 @@ manager: aaroncz
|
||||
</dd>
|
||||
<dd>
|
||||
<a href="#mixedreality-configuremovingplatform">MixedReality/ConfigureMovingPlatform</a>
|
||||
</dd>
|
||||
<dd>
|
||||
<a href="#mixedreality-configurentpclient">MixedReality/ConfigureNtpClient</a>
|
||||
</dd>
|
||||
<dd>
|
||||
<a href="#mixedreality-disablesisallownetworkconnectivitypassivepolling">MixedReality/DisallowNetworkConnectivityPassivePolling</a>
|
||||
@ -52,6 +55,9 @@ manager: aaroncz
|
||||
<dd>
|
||||
<a href="#mixedreality-microphonedisabled">MixedReality/MicrophoneDisabled</a>
|
||||
</dd>
|
||||
<dd>
|
||||
<a href="#mixedreality-ntpclientenabled">MixedReality/NtpClientEnabled</a>
|
||||
</dd>
|
||||
<dd>
|
||||
<a href="#mixedreality-skipcalibrationduringsetup">MixedReality/SkipCalibrationDuringSetup</a>
|
||||
</dd>
|
||||
@ -307,6 +313,71 @@ Supported value is Integer.
|
||||
<!--/Policy-->
|
||||
<hr/>
|
||||
|
||||
<!--Policy-->
|
||||
<a href="" id="mixedreality-configurentpclient"></a>**MixedReality/ConfigureNtpClient**
|
||||
|
||||
<!--SupportedSKUs-->
|
||||
|
||||
|Windows Edition|Supported|
|
||||
|--- |--- |
|
||||
|HoloLens (first gen) Development Edition|No|
|
||||
|HoloLens (first gen) Commercial Suite|No|
|
||||
|HoloLens 2|Yes|
|
||||
|
||||
<!--/SupportedSKUs-->
|
||||
<hr/>
|
||||
|
||||
<!--Scope-->
|
||||
[Scope](./policy-configuration-service-provider.md#policy-scope):
|
||||
|
||||
> [!div class = "checklist"]
|
||||
> * Device
|
||||
|
||||
<hr/>
|
||||
|
||||
<!--/Scope-->
|
||||
<!--Description-->
|
||||
|
||||
> [!NOTE]
|
||||
> This feature is currently only available in [HoloLens Insider](/hololens/hololens-insider) builds.
|
||||
|
||||
You may want to configure a different time server for your device fleet. IT admins can use thi policy to configure certain aspects of NTP client with following policies. In the Settings app, the Time/Language page will show the time server after a time sync has occurred. E.g. `time.windows.com` or another if another value is configured via MDM policy.
|
||||
|
||||
This policy setting specifies a set of parameters for controlling the Windows NTP Client. Refer to [Policy CSP - ADMX_W32Time - Windows Client Management](/windows/client-management/mdm/policy-csp-admx-w32time#admx-w32time-policy-configure-ntpclient) for supported configuration parameters.
|
||||
|
||||
> [!NOTE]
|
||||
> This feature requires enabling[NtpClientEnabled](#mixedreality-ntpclientenabled) as well.
|
||||
|
||||
- OMA-URI: `./Device/Vendor/MSFT/Policy/Config/MixedReality/ConfigureNtpClient`
|
||||
|
||||
> [!NOTE]
|
||||
> Reboot is required for these policies to take effect.
|
||||
|
||||
<!--/Description-->
|
||||
|
||||
<!--ADMXBacked-->
|
||||
<!--/ADMXBacked-->
|
||||
|
||||
<!--SupportedValues-->
|
||||
|
||||
- Data Type: String
|
||||
- Value:
|
||||
|
||||
```
|
||||
<enabled/><data id="W32TIME_NtpServer"
|
||||
value="time.windows.com,0x9"/><data id="W32TIME_Type"
|
||||
value="NTP"/><data id="W32TIME_CrossSiteSyncFlags"
|
||||
value="2"/><data id="W32TIME_ResolvePeerBackoffMinutes"
|
||||
value="15"/><data id="W32TIME_ResolvePeerBackoffMaxTimes"
|
||||
value="7"/><data id="W32TIME_SpecialPollInterval"
|
||||
value="1024"/><data id="W32TIME_NtpClientEventLogFlags"
|
||||
value="0"/>
|
||||
```
|
||||
|
||||
<!--/SupportedValues-->
|
||||
<!--/Policy-->
|
||||
<hr/>
|
||||
|
||||
<!--Policy-->
|
||||
<a href="" id="mixedreality-disablesisallownetworkconnectivitypassivepolling"></a>**MixedReality/DisallowNetworkConnectivityPassivePolling**
|
||||
|
||||
@ -510,6 +581,48 @@ The following list shows the supported values:
|
||||
- 1 - True
|
||||
|
||||
<!--/SupportedValues-->
|
||||
|
||||
<!--Policy-->
|
||||
<a href="" id="mixedreality-ntpclientenabled"></a>**MixedReality/NtpClientEnabled**
|
||||
|
||||
<!--SupportedSKUs-->
|
||||
|
||||
|Windows Edition|Supported|
|
||||
|--- |--- |
|
||||
|HoloLens (first gen) Development Edition|No|
|
||||
|HoloLens (first gen) Commercial Suite|No|
|
||||
|HoloLens 2|Yes|
|
||||
|
||||
<!--/SupportedSKUs-->
|
||||
<hr/>
|
||||
|
||||
<!--Scope-->
|
||||
[Scope](./policy-configuration-service-provider.md#policy-scope):
|
||||
|
||||
> [!div class = "checklist"]
|
||||
> * Device
|
||||
|
||||
<hr/>
|
||||
|
||||
<!--/Scope-->
|
||||
<!--Description-->
|
||||
> [!NOTE]
|
||||
> This feature is currently only available in [HoloLens Insider](/hololens/hololens-insider) builds.
|
||||
|
||||
This policy setting specifies whether the Windows NTP Client is enabled.
|
||||
|
||||
- OMA-URI: `./Device/Vendor/MSFT/Policy/Config/MixedReality/NtpClientEnabled`
|
||||
<!--/Description-->
|
||||
|
||||
<!--ADMXBacked-->
|
||||
<!--/ADMXBacked-->
|
||||
|
||||
<!--SupportedValues-->
|
||||
- Data Type: String
|
||||
- Value `<enabled/>`
|
||||
|
||||
<!--/SupportedValues-->
|
||||
|
||||
<!--/Policy-->
|
||||
<hr/>
|
||||
|
||||
|
||||
@ -33,6 +33,9 @@ manager: aaroncz
|
||||
<a href="#remotedesktopservices-donotallowpasswordsaving">RemoteDesktopServices/DoNotAllowPasswordSaving</a>
|
||||
</dd>
|
||||
<dd>
|
||||
<dd>
|
||||
<a href="#remotedesktopservices-donotallowwebauthnredirection">RemoteDesktopServices/DoNotAllowWebAuthnRedirection</a>
|
||||
</dd>
|
||||
<a href="#remotedesktopservices-promptforpassworduponconnection">RemoteDesktopServices/PromptForPasswordUponConnection</a>
|
||||
</dd>
|
||||
<dd>
|
||||
@ -130,7 +133,7 @@ ADMX Info:
|
||||
|
||||
<!--/Scope-->
|
||||
<!--Description-->
|
||||
Specifies whether it require the use of a specific encryption level to secure communications between client computers and RD Session Host servers during Remote Desktop Protocol (RDP) connections. This policy only applies when you're using native RDP encryption. However, native RDP encryption (as opposed to SSL encryption) isn't recommended. This policy doesn't apply to SSL encryption.
|
||||
Specifies whether it requires the use of a specific encryption level to secure communications between client computers and RD Session Host servers during Remote Desktop Protocol (RDP) connections. This policy only applies when you're using native RDP encryption. However, native RDP encryption (as opposed to SSL encryption) isn't recommended. This policy doesn't apply to SSL encryption.
|
||||
|
||||
If you enable this policy setting, all communications between clients and RD Session Host servers during remote connections must use the encryption method specified in this setting. By default, the encryption level is set to High. The following encryption methods are available:
|
||||
|
||||
@ -257,6 +260,56 @@ ADMX Info:
|
||||
|
||||
<hr/>
|
||||
|
||||
<!--Policy-->
|
||||
<a href="" id="remotedesktopservices-donotallowwebauthnredirection"></a>**RemoteDesktopServices/DoNotAllowWebAuthnRedirection**
|
||||
|
||||
<!--SupportedSKUs-->
|
||||
|
||||
|Edition|Windows 10|Windows 11|
|
||||
|--- |--- |--- |
|
||||
|Home|No|No|
|
||||
|Pro|Yes|Yes|
|
||||
|Windows SE|No|Yes|
|
||||
|Business|Yes|Yes|
|
||||
|Enterprise|Yes|Yes|
|
||||
|Education|Yes|Yes|
|
||||
|
||||
<!--/SupportedSKUs-->
|
||||
<hr/>
|
||||
|
||||
<!--Scope-->
|
||||
[Scope](./policy-configuration-service-provider.md#policy-scope):
|
||||
|
||||
> [!div class = "checklist"]
|
||||
> * Device
|
||||
|
||||
<hr/>
|
||||
|
||||
<!--/Scope-->
|
||||
<!--Description-->
|
||||
This policy setting lets you control the redirection of web authentication (WebAuthn) requests from a Remote Desktop session to the local device. This redirection enables users to authenticate to resources inside the Remote Desktop session using their local authenticator (e.g., Windows Hello for Business, security key, or other).
|
||||
|
||||
By default, Remote Desktop allows redirection of WebAuthn requests.
|
||||
|
||||
If you enable this policy setting, users can’t use their local authenticator inside the Remote Desktop session.
|
||||
|
||||
If you disable or do not configure this policy setting, users can use local authenticators inside the Remote Desktop session.
|
||||
|
||||
If you don't configure this policy setting, users can use local authenticators inside the Remote Desktop session.
|
||||
<!--/Description-->
|
||||
|
||||
<!--ADMXBacked-->
|
||||
ADMX Info:
|
||||
- GP Friendly name: *Do not allow WebAuthn redirection*
|
||||
- GP name: *TS_WEBAUTHN*
|
||||
- GP path: *Windows Components/Remote Desktop Services/Remote Desktop Session Host/Device and Resource Redirection*
|
||||
- GP ADMX file name: *terminalserver.admx*
|
||||
|
||||
<!--/ADMXBacked-->
|
||||
<!--/Policy-->
|
||||
|
||||
<hr/>
|
||||
|
||||
<!--Policy-->
|
||||
<a href="" id="remotedesktopservices-promptforpassworduponconnection"></a>**RemoteDesktopServices/PromptForPasswordUponConnection**
|
||||
|
||||
@ -367,4 +420,4 @@ ADMX Info:
|
||||
|
||||
## Related topics
|
||||
|
||||
[Policy configuration service provider](policy-configuration-service-provider.md)
|
||||
[Policy configuration service provider](policy-configuration-service-provider.md)
|
||||
|
||||
@ -138,6 +138,9 @@ ms.collection: highpri
|
||||
</dd>
|
||||
<dd>
|
||||
<a href="#update-managepreviewbuilds">Update/ManagePreviewBuilds</a>
|
||||
</dd>
|
||||
<dd>
|
||||
<a href="#update-NoUpdateNotificationDuringActiveHours">Update/NoUpdateNotificationDuringActiveHours</a>
|
||||
</dd>
|
||||
<dd>
|
||||
<a href="#update-pausedeferrals">Update/PauseDeferrals</a>
|
||||
@ -2382,6 +2385,55 @@ The following list shows the supported values:
|
||||
|
||||
<hr/>
|
||||
|
||||
<!--Policy-->
|
||||
<a href="" id="update-NoUpdateNotificationDuringActiveHours"></a>**Update/NoUpdateNotificationDuringActiveHours**
|
||||
|
||||
<!--SupportedSKUs-->
|
||||
The table below shows the applicability of Windows:
|
||||
|
||||
|Edition|Windows 10|Windows 11|
|
||||
|--- |--- |--- |
|
||||
|Home|No|No|
|
||||
|Pro|Yes|Yes|
|
||||
|Windows SE|No|Yes|
|
||||
|Business|Yes|Yes|
|
||||
|Enterprise|Yes|Yes|
|
||||
|Education|Yes|Yes|
|
||||
|
||||
<!--/SupportedSKUs-->
|
||||
<hr/>
|
||||
|
||||
<!--Scope-->
|
||||
[Scope](./policy-configuration-service-provider.md#policy-scope):
|
||||
|
||||
> [!div class = "checklist"]
|
||||
> * Device
|
||||
|
||||
<hr/>
|
||||
|
||||
<!--/Scope-->
|
||||
<!--Description-->
|
||||
This policy can be used in conjunction with Update/ActiveHoursStart and Update/ActiveHoursEnd policies to ensure that the end user sees no update notifications during active hours until deadline is reached. Note - if no active hour period is configured then this will apply to the intelligent active hours window calculated on the device.
|
||||
|
||||
Supported value type is a boolean.
|
||||
|
||||
0 (Default) This configuration will provide the default behavior (notifications may display during active hours)
|
||||
1: This setting will prevent notifications from displaying during active hours.
|
||||
|
||||
<!--/Description-->
|
||||
<!--ADMXMapped-->
|
||||
ADMX Info:
|
||||
- GP Friendly name: *Display options for update notifications*
|
||||
- GP name: *NoUpdateNotificationDuringActiveHours*
|
||||
- GP element: *NoUpdateNotificationDuringActiveHours*
|
||||
- GP path: *Windows Components\WindowsUpdate\Manage end user experience*
|
||||
- GP ADMX file name: *WindowsUpdate.admx*
|
||||
<!--/ADMXMapped-->
|
||||
|
||||
<!--/Policy-->
|
||||
<hr/>
|
||||
|
||||
|
||||
<!--Policy-->
|
||||
<a href="" id="update-pausedeferrals"></a>**Update/PauseDeferrals**
|
||||
|
||||
|
||||
@ -10,6 +10,7 @@ ms.author: vinpa
|
||||
manager: aaroncz
|
||||
ms.reviewer: pmadrigal
|
||||
ms.collection: highpri
|
||||
ms.date: 08/26/2022
|
||||
---
|
||||
|
||||
# Use Quick Assist to help users
|
||||
@ -18,7 +19,7 @@ Quick Assist is a Microsoft Store application that enables a person to share the
|
||||
|
||||
## Before you begin
|
||||
|
||||
All that's required to use Quick Assist is suitable network and internet connectivity. No particular roles, permissions, or policies are involved. Neither party needs to be in a domain. The helper must have a Microsoft account. The sharer doesn't have to authenticate.
|
||||
All that's required to use Quick Assist is suitable network and internet connectivity. No roles, permissions, or policies are involved. Neither party needs to be in a domain. The helper must have a Microsoft account. The sharer doesn't have to authenticate.
|
||||
|
||||
> [!NOTE]
|
||||
> In case the helper and sharer use different keyboard layouts or mouse settings, the ones from the sharer are used during the session.
|
||||
@ -35,24 +36,30 @@ Both the helper and sharer must be able to reach these endpoints over port 443:
|
||||
|
||||
| Domain/Name | Description |
|
||||
|--|--|
|
||||
| `*.support.services.microsoft.com` | Primary endpoint used for Quick Assist application |
|
||||
| `*.login.microsoftonline.com` | Required for logging in to the application (Microsoft account) |
|
||||
| `*.channelwebsdks.azureedge.net` | Used for chat services within Quick Assist |
|
||||
| `*.aria.microsoft.com` | Used for accessibility features within the app |
|
||||
| `*.api.support.microsoft.com` | API access for Quick Assist |
|
||||
| `*.vortex.data.microsoft.com` | Used for diagnostic data |
|
||||
| `*.aria.microsoft.com` | Used for accessibility features within the app |
|
||||
| `*.cc.skype.com` | Azure Communication Service for chat and connection between parties |
|
||||
| `*.channelservices.microsoft.com` | Required for chat services within Quick Assist |
|
||||
| `*.channelwebsdks.azureedge.net` | Used for chat services within Quick Assist |
|
||||
| `*.edgeassetservice.azureedge.net` | Used for diagnostic data |
|
||||
| `*.flightproxy.skype.com` | Azure Communication Service for chat and connection between parties |
|
||||
| `*.login.microsoftonline.com` | Required for logging in to the application (Microsoft account) |
|
||||
| `*.monitor.azure.com` | Service Performance Monitoring |
|
||||
| `*.registrar.skype.com` | Azure Communication Service for chat and connection between parties. |
|
||||
| `*.remoteassistanceprodacs.communication.azure.com` | Azure Communication Services (ACS) technology the Quick Assist app uses. |
|
||||
| `*.support.services.microsoft.com` | Primary endpoint used for Quick Assist application |
|
||||
| `*.trouter.skype.com` | Azure Communication Service for chat and connection between parties. |
|
||||
| `*.turn.azure.com` | Protocol used to help endpoint. |
|
||||
| `*.vortex.data.microsoft.com` | Used for diagnostic data |
|
||||
| `browser.pipe.aria.microsoft.com` | Required diagnostic data for client and services used by Quick Assist. |
|
||||
| `browser.events.data.microsoft.com` | Required diagnostic data for client and services used by Quick Assist. |
|
||||
| `ic3.events.data.microsoft.com` | Required diagnostic data for client and services used by Quick Assist. |
|
||||
| `edge.skype.com` | Azure Communication Service for chat and connection between parties. |
|
||||
| `events.data.microsoft.com` | Required diagnostic data for client and services used by Quick Assist. |
|
||||
|
||||
## How it works
|
||||
|
||||
1. Both the helper and the sharer start Quick Assist.
|
||||
|
||||
2. The helper selects **Assist another person**. Quick Assist on the helper's side contacts the Remote Assistance Service to obtain a session code. An RCC chat session is established and the helper's Quick Assist instance joins it. The helper then provides the code to the sharer.
|
||||
2. The helper selects **Assist another person**. Quick Assist on the helper's side contacts the Remote Assistance Service to obtain a session code. An RCC chat session is established, and the helper's Quick Assist instance joins it. The helper then provides the code to the sharer.
|
||||
|
||||
3. After the sharer enters the code in their Quick Assist app, Quick Assist uses that code to contact the Remote Assistance Service and join that specific session. The sharer's Quick Assist instance joins the RCC chat session.
|
||||
|
||||
@ -89,10 +96,11 @@ Either the support staff or a user can start a Quick Assist session.
|
||||
1. Support staff ("helper") starts Quick Assist in any of a few ways:
|
||||
|
||||
- Type *Quick Assist* in the search box and press ENTER.
|
||||
- From the Start menu, select **Windows Accessories**, and then select **Quick Assist**.
|
||||
- Type CTRL+Windows+Q
|
||||
- Press **CTRL** + **Windows** + **Q**
|
||||
- For **Windows 10** users, from the Start menu, select **Windows Accessories**, and then choose **Quick Assist**.
|
||||
- For **Windows 11** users, from the Start menu, select **All Apps**, **Windows Tools**, and then choose **Quick Assist**.
|
||||
|
||||
2. In the **Give assistance** section, helper selects **Assist another person**. The helper might be asked to choose their account or sign in. Quick Assist generates a time-limited security code.
|
||||
2. In the **Give assistance** section, the helper selects **Assist another person**. The helper might be asked to choose their account or sign in. Quick Assist generates a time-limited security code.
|
||||
|
||||
3. Helper shares the security code with the user over the phone or with a messaging system.
|
||||
|
||||
@ -102,9 +110,51 @@ Either the support staff or a user can start a Quick Assist session.
|
||||
|
||||
6. The sharer receives a dialog asking for permission to show their screen or allow access. The sharer gives permission by selecting the **Allow** button.
|
||||
|
||||
## If Quick Assist is missing
|
||||
## Install Quick Assist
|
||||
|
||||
If for some reason a user doesn't have Quick Assist on their system or it's not working properly, try to uninstall and reinstall it. For more information, see [Install Quick Assist](https://support.microsoft.com/windows/install-quick-assist-c17479b7-a49d-4d12-938c-dbfb97c88bca).
|
||||
### Install Quick Assist from the Microsoft Store
|
||||
|
||||
1. Download the new version of Quick Assist by visiting the [Microsoft Store](https://apps.microsoft.com/store/detail/quick-assist/9P7BP5VNWKX5).
|
||||
1. In the Microsoft Store, select **Get in Store app**. Then, give permission to install Quick Assist. When the installation is complete, you'll see **Get** change to **Open**.</br> :::image type="content" source="images/quick-assist-get.png" lightbox="images/quick-assist-get.png" alt-text="Microsoft Store window showing the Quick Assist app with a button labeled get in the bottom right corner.":::
|
||||
|
||||
For more information, visit [Install Quick Assist](https://support.microsoft.com/windows/install-quick-assist-c17479b7-a49d-4d12-938c-dbfb97c88bca).
|
||||
|
||||
### Install Quick Assist with Intune
|
||||
|
||||
Before installing Quick Assist, you'll need to set up synchronization between Intune and Microsoft Store for Business. If you've already set up sync, log into [Microsoft Store for Business](https://businessstore.microsoft.com) and skip to step 5.
|
||||
|
||||
1. Go to [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/) and navigate to **Tenant administration** / **Connectors and tokens** / **Microsoft Store for Business** and verify that **Microsoft Store for Business sync** is set to **Enable**.
|
||||
1. Using your Global Admin account, log into [Microsoft Store for Business](https://businessstore.microsoft.com).
|
||||
1. Select **Manage** / **Settings** and turn on **Show offline apps**.
|
||||
1. Choose the **Distribute** tab and verify that **Microsoft Intune** is **Active**. You may need to use the **+Add management tool** link if it's not.
|
||||
1. Search for **Quick Assist** and select it from the Search results.
|
||||
1. Choose the **Offline** license and select **Get the app**
|
||||
1. From the Intune portal (Endpoint Manager admin center) choose **Sync**.
|
||||
1. Navigate to **Apps** / **Windows** and you should see **Quick Assist (Offline)** in the list.
|
||||
1. Select it to view its properties. By default, the app won't be assigned to anyone or any devices, select the **Edit** link.
|
||||
1. Assign the app to the required group of devices and choose **Review + save** to complete the application install.
|
||||
|
||||
> [!NOTE]
|
||||
> Assigning the app to a device or group of devices instead of a user is important because it's the only way to install a store app in device context.
|
||||
|
||||
Visit [Add Microsoft Store apps to Microsoft Intune](/mem/intune/apps/store-apps-windows) for more information.
|
||||
|
||||
### Install Quick Assist Offline
|
||||
|
||||
To install Quick Assist offline, you'll need to download your APPXBUNDLE and unencoded XML file from [Microsoft Store for Business](https://businessstore.microsoft.com). Visit [Download an offline-licensed app](/microsoft-store/distribute-offline-apps#download-an-offline-licensed-app) for more information.
|
||||
|
||||
1. Start **Windows PowerShell** with Administrative privileges.
|
||||
1. In PowerShell, change the directory to the location you've saved the file to in step 1. (CD <*location of package file*>)
|
||||
1. Run the following command to install Quick Assist: </br>*Add-appxprovisionedpackage -online -PackagePath "MicrosoftCorporationII.QuickAssist_2022.509.2259.0_neutral___8wekyb3d8bbwe.AppxBundle" -LicensePath "MicrosoftCorporationII.QuickAssist_8wekyb3d8bbwe_4bc27046-84c5-8679-dcc7-d44c77a47dd0.xml"*
|
||||
1. After Quick Assist has installed, run this command: </br>_Get-appxpackage \*QuickAssist* -alluser_
|
||||
|
||||
After running the command, you'll see Quick Assist 2.X is installed for the user.
|
||||
|
||||
## Microsoft Edge WebView2
|
||||
|
||||
The Microsoft Edge WebView2 is a development control that uses Microsoft Edge as the rendering engine to display web content in native apps. The new Quick Assist app is written using this control and is required. For Windows 11 users, this runtime control is built in. For Windows 10 users, the Quick Assist Store app will detect if WebView2 is present on launch and if necessary, it will be installed automatically. If an error message or prompt is shown indicating WebView2 isn't present, it will need to be installed separately.
|
||||
|
||||
For more information on distributing and installing Microsoft Edge WebView2, visit [Distribute your app and the WebView2 Runtime](/microsoft-edge/webview2/concepts/distribution)
|
||||
|
||||
## Next steps
|
||||
|
||||
|
||||
@ -14,6 +14,8 @@ ms.collection: highpri
|
||||
|
||||
# Advanced troubleshooting for stop or blue screen errors
|
||||
|
||||
<p class="alert is-flex is-primary"><span class="has-padding-left-medium has-padding-top-extra-small"><a class="button is-primary" href="https://vsa.services.microsoft.com/v1.0/?partnerId=7d74cf73-5217-4008-833f-87a1a278f2cb&flowId=DMC&initialQuery=31806236" target='_blank'><b>Try our Virtual Agent</b></a></span><span class="has-padding-small"> - It can help you quickly identify and fix common Windows boot issues</span>
|
||||
|
||||
> [!NOTE]
|
||||
> If you're not a support agent or IT professional, you'll find more helpful information about stop error ("blue screen") messages in [Troubleshoot blue screen errors](https://support.microsoft.com/sbs/windows/troubleshoot-blue-screen-errors-5c62726c-6489-52da-a372-3f73142c14ad).
|
||||
|
||||
|
||||
@ -13,6 +13,8 @@ manager: dansimp
|
||||
|
||||
# Advanced troubleshooting for Windows start-up issues
|
||||
|
||||
<p class="alert is-flex is-primary"><span class="has-padding-left-medium has-padding-top-extra-small"><a class="button is-primary" href="https://vsa.services.microsoft.com/v1.0/?partnerId=7d74cf73-5217-4008-833f-87a1a278f2cb&flowId=DMC&initialQuery=31806273" target='_blank'><b>Try our Virtual Agent</b></a></span><span class="has-padding-small"> - It can help you quickly identify and fix common Windows boot issues</span>
|
||||
|
||||
In these topics, you will learn how to troubleshoot common problems that are related to Windows startup.
|
||||
|
||||
## How it works
|
||||
|
||||
@ -21,6 +21,7 @@
|
||||
"files": [
|
||||
"**/*.png",
|
||||
"**/*.jpg",
|
||||
"**/*.svg",
|
||||
"**/*.gif"
|
||||
],
|
||||
"exclude": [
|
||||
|
||||
@ -263,7 +263,7 @@
|
||||
href: update/update-compliance-schema-waasupdatestatus.md
|
||||
- name: WaaSInsiderStatus
|
||||
href: update/update-compliance-schema-waasinsiderstatus.md
|
||||
- name: WaaSDepoymentStatus
|
||||
- name: WaaSDeploymentStatus
|
||||
href: update/update-compliance-schema-waasdeploymentstatus.md
|
||||
- name: WUDOStatus
|
||||
href: update/update-compliance-schema-wudostatus.md
|
||||
|
||||
@ -50,10 +50,10 @@ sections:
|
||||
- For some devices, Windows 10 may be unable to install drivers that are required for operation. If your device drivers aren't automatically installed, visit the manufacturer's support website for your device to download and manually install the drivers. If Windows 10 drivers aren't available, the most up-to-date drivers for Windows 8.1 will often work in Windows 10.
|
||||
- For some devices, the manufacturer may provide more up-to-date drivers or drivers that enable more functionality than the drivers installed by Windows 10. Always follow the recommendations of the device manufacturer for optimal performance and stability.
|
||||
- Some computer manufacturers provide packs of drivers for easy implementation in management and deployment solutions like the Microsoft Deployment Toolkit (MDT) or Microsoft Endpoint Configuration Manager. These driver packs contain all of the drivers needed for each device and can greatly simplify the process of deploying Windows to a new make or model of computer. Driver packs for some common manufacturers include:
|
||||
- [HP driver pack](http://www8.hp.com/us/en/ads/clientmanagement/drivers-pack.html)
|
||||
- [Dell driver packs for enterprise client OS deployment](http://en.community.dell.com/techcenter/enterprise-client/w/wiki/2065.dell-command-deploy-driver-packs-for-enterprise-client-os-deployment)
|
||||
- [Lenovo Configuration Manager and MDT package index](https://support.lenovo.com/us/en/documents/ht074984)
|
||||
- [Panasonic Driver Pack for Enterprise](http://pc-dl.panasonic.co.jp/itn/drivers/driver_packages.html)
|
||||
- [HP driver pack](https://www.hp.com/us-en/solutions/client-management-solutions/drivers-pack.html)
|
||||
- [Dell driver packs for enterprise client OS deployment](https://www.dell.com/support/kbdoc/en-us/000124139/dell-command-deploy-driver-packs-for-enterprise-client-os-deployment)
|
||||
- [Lenovo Configuration Manager and MDT package index](https://support.lenovo.com/us/en/solutions/ht074984)
|
||||
- [Panasonic Driver Pack for Enterprise](https://pc-dl.panasonic.co.jp/itn/drivers/driver_packages.html)
|
||||
|
||||
- question: |
|
||||
Where can I find out if an application or device is compatible with Windows 10?
|
||||
@ -125,7 +125,7 @@ sections:
|
||||
answer: |
|
||||
For an overview of the new enterprise features in Windows 10 Enterprise, see [What's new in Windows 10](/windows/whats-new/) and [What's new in Windows 10, version 1703](/windows/whats-new/whats-new-windows-10-version-1703) in the Docs library.
|
||||
|
||||
Another place to track the latest information about new features of interest to IT professionals is the [Windows for IT Pros blog](https://blogs.technet.microsoft.com/windowsitpro/). Here you'll find announcements of new features, information on updates to the Windows servicing model, and details about the latest resources to help you more easily deploy and manage Windows 10.
|
||||
Another place to track the latest information about new features of interest to IT professionals is the [Windows for IT Pros blog](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/bg-p/Windows10Blog). Here you'll find announcements of new features, information on updates to the Windows servicing model, and details about the latest resources to help you more easily deploy and manage Windows 10.
|
||||
|
||||
To find out which version of Windows 10 is right for your organization, you can also [compare Windows editions](https://www.microsoft.com/WindowsForBusiness/Compare).
|
||||
|
||||
@ -152,4 +152,3 @@ sections:
|
||||
- If you're an IT professional or if you have a question about administering, managing, or deploying Windows 10 in your organization or business, visit the [Windows 10 IT Professional forums](https://social.technet.microsoft.com/forums/home?category=windows10itpro) on TechNet.
|
||||
- If you're an end user or if you have a question about using Windows 10, visit the [Windows 10 forums on Microsoft Community](https://answers.microsoft.com/windows/forum).
|
||||
- If you're a developer or if you have a question about making apps for Windows 10, visit the [Windows Desktop Development forums](https://social.msdn.microsoft.com/forums/en-us/home?category=windowsdesktopdev).
|
||||
- If you have a question about Internet Explorer, visit the [Internet Explorer forums](https://social.technet.microsoft.com/forums/ie/en-us/home).
|
||||
|
||||
@ -22,7 +22,7 @@ WaaSDeploymentStatus records track a specific update's installation progress on
|
||||
|**DeferralDays** |[int](/azure/kusto/query/scalar-data-types/int) |`0` |The deferral policy for this content type or `UpdateCategory` (Windows `Feature` or `Quality`). |
|
||||
|**DeploymentError** |[string](/azure/kusto/query/scalar-data-types/string) |`Disk Error` |A readable string describing the error, if any. If empty, there's either no string matching the error or there's no error. |
|
||||
|**DeploymentErrorCode** |[int](/azure/kusto/query/scalar-data-types/int) |`8003001E` |Microsoft internal error code for the error, if any. If empty, there's either no error or there's *no error code*, meaning that the issue raised doesn't correspond to an error, but some inferred issue. |
|
||||
|**DeploymentStatus** |[string](/azure/kusto/query/scalar-data-types/string) |`Failed` |The high-level status of installing this update on this device. Possible values are:<br><li> **Update completed**: Device has completed the update installation.<li> **In Progress**: Device is in one of the various stages of installing an update, detailed in `DetailedStatus`.<li> **Deferred**: A device's deferral policy is preventing the update from being offered by Windows Update.<li> **Canceled**: The update was canceled.<li> **Blocked**: There's 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.<li> **Unknown**: Update Compliance generated WaaSDeploymentStatus records for devices as soon as it detects an update newer than the one installed on the device. Devices that haven't sent any deployment data for that update will have the status `Unknown`.<li> **Update paused**: Devices are paused via Windows Update for Business Pause policies, preventing the update from being offered by Windows Update. <li> **Failed**: Device encountered a failure in the update process, preventing it from installing the update. This may result in an automatic retry in the case of Windows Update, unless the `DeploymentError` indicates the issue requires action before the update can continue.|
|
||||
|**DeploymentStatus** |[string](/azure/kusto/query/scalar-data-types/string) |`Failed` |The high-level status of installing this update on this device. Possible values are:<br><li> **Update completed**: Device has completed the update installation.<li> **In Progress**: Device is in one of the various stages of installing an update, detailed in `DetailedStatus`.<li> **Deferred**: A device's deferral policy is preventing the update from being offered by Windows Update.<li> **Canceled**: The update was canceled.<li> **Blocked**: There's 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.<li> **Unknown**: Update Compliance generated WaaSDeploymentStatus records for devices as soon as it detects an update newer than the one installed on the device. Devices that haven't sent any deployment data for that update will have the status `Unknown`.<li> **Update paused**: Devices are paused via Windows Update for Business Pause policies, preventing the update from being offered by Windows Update. <li> **Failed**: Device encountered a failure in the update process, preventing it from installing the update. This may result in an automatic retry in the case of Windows Update, unless the `DeploymentError` indicates the issue requires action before the update can continue.<li> **Progress stalled**: The update is in progress, but has not completed over a period of 7 days.|
|
||||
|**DetailedStatus** |[string](/azure/kusto/query/scalar-data-types/string) |`Reboot required` |A detailed status for the installation of this update on this device. Possible values are:<br><li> **Not Started**: Update hasn't started because the device isn't targeting the latest 2 builds<li> **Update deferred**: When a device's Windows Update for Business policy dictates the update is deferred.<li> **Update paused**: The device's Windows Update for Business policy dictates the update is paused from being offered.<li> **Update offered**: The device has been offered the update, but hasn't begun downloading it.<li> **Pre-Download tasks passed**: The device has finished all necessary tasks prior to downloading the update.<li> **Compatibility hold**: The device has been placed under a *compatibility hold* to ensure a smooth feature update experience and won't resume the update until the hold has been cleared. For more information, see [Feature Update Status report](update-compliance-feature-update-status.md#safeguard-holds).<li> **Download started**: The update has begun downloading on the device.<li> **Download Succeeded**: The update has successfully completed downloading. <li> **Pre-Install Tasks Passed**: Tasks that must be completed prior to installing the update have been completed.<li> **Install Started**: Installation of the update has begun.<li> **Reboot Required**: The device has finished installing the update, and a reboot is required before the update can be completed.<li> **Reboot Pending**: The device has a scheduled reboot to apply the update.<li> **Reboot Initiated**: The scheduled reboot has been initiated.<li> **Commit**: Changes are being committed post-reboot. This is another step of the installation process.<li> **Update Completed**: The update has successfully installed.|
|
||||
|**ExpectedInstallDate** |[datetime](/azure/kusto/query/scalar-data-types/datetime)|`3/28/2020, 1:00:01.318 PM`|Rather than the expected date this update will be installed, this should be interpreted as the minimum date Windows Update will make the update available for the device. This takes into account Deferrals. |
|
||||
|**LastScan** |[datetime](/azure/kusto/query/scalar-data-types/datetime)|`3/22/2020, 1:00:01.318 PM`|The last point in time that this device sent Update Session data. |
|
||||
|
||||
@ -9,7 +9,7 @@ ms.author: mstewart
|
||||
ms.localizationpriority: medium
|
||||
ms.collection: M365-analytics
|
||||
ms.topic: article
|
||||
ms.date: 06/06/2022
|
||||
ms.date: 08/24/2022
|
||||
---
|
||||
|
||||
# Configuring Microsoft Endpoint Manager devices for Update Compliance (preview)
|
||||
@ -29,48 +29,79 @@ This article is specifically targeted at configuring devices enrolled to [Micros
|
||||
|
||||
## Create a configuration profile
|
||||
|
||||
Take the following steps to create a configuration profile that will set required policies for Update Compliance:
|
||||
Create a configuration profile that will set the required policies for Update Compliance. There are two profile types that can be used to create a configuration profile for Update Compliance:
|
||||
- The [settings catalog](#settings-catalog)
|
||||
- [Template](#custom-oma-uri-based-profile) for a custom OMA URI based profile
|
||||
|
||||
1. Go to the Admin portal in Endpoint Manager and navigate to **Devices/Windows/Configuration profiles**.
|
||||
1. On the **Configuration profiles** view, select **Create a profile**.
|
||||
### Settings catalog
|
||||
|
||||
1. Go to the Admin portal in Endpoint Manager and navigate to **Devices** > **Windows** > **Configuration profiles**.
|
||||
1. On the **Configuration profiles** view, select **Create profile**.
|
||||
1. Select **Platform**="Windows 10 and later" and **Profile type**="Settings Catalog", and then select **Create**.
|
||||
1. You're now on the Configuration profile creation screen. On the **Basics** tab, give a **Name** and **Description**.
|
||||
1. On the **Configuration settings** page, you'll be adding multiple settings from the **System** category. Using the **Settings picker**, select the **System** category, then add the following settings and values:
|
||||
1. Required settings for Update Compliance:
|
||||
- **Setting**: Allow Commercial Data Pipeline
|
||||
- **Value**: Enabled
|
||||
- **Setting**: Allow Telemetry
|
||||
- **Value**: Basic (*Basic is the minimum value, but it can be safely set to a higher value*)
|
||||
- **Setting**: Allow Update Compliance Processing
|
||||
- **Value**: Enabled
|
||||
1. (*Recommended, but not required*) Add settings for **disabling devices' Diagnostic Data opt-in settings interface**. If these aren't disabled, users of each device can potentially override the diagnostic data level of devices such that data won't be available for those devices in Update Compliance:
|
||||
- **Setting**: Configure Telemetry Opt In Change Notification
|
||||
- **Value**: Disable telemetry change notifications
|
||||
- **Setting**: Configure Telemetry Opt In Settings Ux
|
||||
- **Value**: Disable Telemetry opt-in Settings
|
||||
1. (*Recommended, but not required*) Allow device name to be sent in Windows Diagnostic Data. If this policy is disabled, the device name won't be sent and won't be visible in Update Compliance:
|
||||
- **Setting**: Allow device name to be sent in Windows diagnostic data
|
||||
- **Value**: Allowed
|
||||
|
||||
1. Proceed through the next set of tabs **Scope tags**, **Assignments**, and **Applicability Rules** to assign the configuration profile to devices you wish to enroll.
|
||||
1. Review the settings and then select **Create**.
|
||||
|
||||
### Custom OMA URI based profile
|
||||
|
||||
1. Go to the Admin portal in Endpoint Manager and navigate to **Devices** > **Windows** > **Configuration profiles**.
|
||||
1. On the **Configuration profiles** view, select **Create profile**.
|
||||
1. Select **Platform**="Windows 10 and later" and **Profile type**="Templates".
|
||||
1. For **Template name**, select **Custom**, and then press **Create**.
|
||||
1. For **Template name**, select **Custom**, and then select **Create**.
|
||||
1. You're now on the Configuration profile creation screen. On the **Basics** tab, give a **Name** and **Description**.
|
||||
1. On the **Configuration settings** page, you'll be adding multiple OMA-URI Settings that correspond to the policies described in [Manually configuring devices for Update Compliance](update-compliance-v2-configuration-manual.md).
|
||||
|
||||
|
||||
1. Add a setting to **Allow commercial data pipeline**; this policy is required for Update Compliance:
|
||||
- **Name**: Allow commercial data pipeline
|
||||
- **Description**: Configures Microsoft to be the processor of the Windows diagnostic data collected from an Azure Active Directory-joined device.
|
||||
- **OMA-URI**: `./Vendor/MSFT/Policy/Config/System/AllowCommercialDataPipeline`
|
||||
- **Data type**: Integer
|
||||
- **Value**: 1
|
||||
1. Add a setting configuring the **Windows Diagnostic Data level** for devices:
|
||||
- **Name**: Allow Telemetry
|
||||
- **Description**: Sets the maximum allowed diagnostic data to be sent to Microsoft, required for Update Compliance.
|
||||
- **OMA-URI**: `./Vendor/MSFT/Policy/Config/System/AllowTelemetry`
|
||||
- **Data type**: Integer
|
||||
- **Value**: 1 (*all that is required is 1, but it can be safely set to a higher value*).
|
||||
1. (*Recommended, but not required*) Add a setting for **disabling devices' Diagnostic Data opt-in settings interface**. If this isn't disabled, users of each device can potentially override the diagnostic data level of devices such that data won't be available for those devices in Update Compliance:
|
||||
- **Name**: Disable Telemetry opt-in interface
|
||||
- **Description**: Disables the ability for end-users of devices can adjust diagnostic data to levels lower than defined by the Allow Telemetry setting.
|
||||
- **OMA-URI**: `./Vendor/MSFT/Policy/Config/System/ConfigureTelemetryOptInSettingsUx`
|
||||
- **Data type**: Integer
|
||||
- **Value**: 1
|
||||
1. Add a setting to **Allow device name in diagnostic data**; otherwise, there will be no device name in Update Compliance:
|
||||
- **Name**: Allow device name in Diagnostic Data
|
||||
- **Description**: Allows device name in Diagnostic Data.
|
||||
- **OMA-URI**: `./Vendor/MSFT/Policy/Config/System/AllowDeviceNameInDiagnosticData`
|
||||
- **Data type**: Integer
|
||||
- **Value**: 1
|
||||
- **Value**: 1 (*1 is the minimum value meaning basic, but it can be safely set to a higher value*).
|
||||
1. Add a setting to **Allow Update Compliance processing**; this policy is required for Update Compliance:
|
||||
- **Name**: Allow Update Compliance Processing
|
||||
- **Description**: Opts device data into Update Compliance processing. Required to see data.
|
||||
- **OMA-URI**: `./Vendor/MSFT/Policy/Config/System/AllowUpdateComplianceProcessing`
|
||||
- **Data type**: Integer
|
||||
- **Value**: 16
|
||||
1. Add a setting to **Allow commercial data pipeline**; this policy is required for Update Compliance:
|
||||
- **Name**: Allow commercial data pipeline
|
||||
- **Description**: Configures Microsoft to be the processor of the Windows diagnostic data collected from an Azure Active Directory-joined device.
|
||||
- **OMA-URI**: `./Vendor/MSFT/Policy/Config/System/AllowCommercialDataPipeline`
|
||||
1. (*Recommended, but not required*) Add settings for **disabling devices' Diagnostic Data opt-in settings interface**. If these aren't disabled, users of each device can potentially override the diagnostic data level of devices such that data won't be available for those devices in Update Compliance:
|
||||
- **Name**: Disable Telemetry opt-in interface
|
||||
- **Description**: Disables the ability for end-users of devices can adjust diagnostic data to levels lower than defined by the Allow Telemetry setting.
|
||||
- **OMA-URI**: `./Vendor/MSFT/Policy/Config/System/ConfigureTelemetryOptInSettingsUx`
|
||||
- **Data type**: Integer
|
||||
- **Value**: 1
|
||||
1. (*Recommended, but not required*) Add a setting to **Allow device name in diagnostic data**; otherwise, the device name won't be in Update Compliance:
|
||||
- **Name**: Allow device name in Diagnostic Data
|
||||
- **Description**: Allows device name in Diagnostic Data.
|
||||
- **OMA-URI**: `./Vendor/MSFT/Policy/Config/System/AllowDeviceNameInDiagnosticData`
|
||||
- **Data type**: Integer
|
||||
- **Value**: 1
|
||||
|
||||
|
||||
1. Proceed through the next set of tabs **Scope tags**, **Assignments**, and **Applicability Rules** to assign the configuration profile to devices you wish to enroll.
|
||||
1. Review and select **Create**.
|
||||
1. Review the settings and then select **Create**.
|
||||
|
||||
## Deploy the configuration script
|
||||
|
||||
|
||||
@ -17,6 +17,8 @@ ms.collection: highpri
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
|
||||
<p class="alert is-flex is-primary"><span class="has-padding-left-medium has-padding-top-extra-small"><a class="button is-primary" href="https://vsa.services.microsoft.com/v1.0/?partnerId=7d74cf73-5217-4008-833f-87a1a278f2cb&flowId=DMC&initialQuery=31806295" target='_blank'><b>Try our Virtual Agent</b></a></span><span class="has-padding-small"> - It can help you quickly identify and fix common Windows Update issues</span>
|
||||
|
||||
The following table provides information about common errors you might run into with Windows Update, as well as steps to help you mitigate them.
|
||||
|
||||
## 0x8024402F
|
||||
|
||||
@ -18,6 +18,8 @@ ms.topic: article
|
||||
> This is a 300 level topic (moderately advanced).<br>
|
||||
> See [Resolve Windows 10 upgrade errors](resolve-windows-10-upgrade-errors.md) for a full list of topics in this article.
|
||||
|
||||
<p class="alert is-flex is-primary"><span class="has-padding-left-medium has-padding-top-extra-small"><a class="button is-primary" href="https://vsa.services.microsoft.com/v1.0/?partnerId=7d74cf73-5217-4008-833f-87a1a278f2cb&flowId=DMC&initialQuery=31806293" target='_blank'><b>Try our Virtual Agent</b></a></span><span class="has-padding-small"> - It can help you quickly identify and fix common Windows boot issues</span>
|
||||
|
||||
If a Windows 10 upgrade is not successful, it can be very helpful to understand *when* an error occurred in the upgrade process.
|
||||
|
||||
> [!IMPORTANT]
|
||||
|
||||
@ -117,8 +117,8 @@ 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/).
|
||||
2. Select **Windows Autopatch** from the left navigation menu.
|
||||
3. Select **Devices**.
|
||||
2. Select **Devices** from the left navigation menu.
|
||||
3. Under the **Windows Autopatch** section, select **Devices**.
|
||||
4. Select either the **Ready** or the **Not ready** tab, then select the **Windows Autopatch Device Registration** hyperlink. The Azure Active Directory group blade opens.
|
||||
5. Add either devices through direct membership, or other Azure AD dynamic or assigned groups as nested groups in the **Windows Autopatch Device Registration** group.
|
||||
|
||||
@ -148,6 +148,7 @@ Windows 365 Enterprise gives IT admins the option to register devices with the W
|
||||
1. Select **Create**. Now your newly provisioned Windows 365 Enterprise Cloud PCs will automatically be enrolled and managed by Windows Autopatch.
|
||||
|
||||
For more information, see [Create a Windows 365 Provisioning Policy](/windows-365/enterprise/create-provisioning-policy).
|
||||
|
||||
### Contact support for device registration-related incidents
|
||||
|
||||
Support is available either through Windows 365, or the Windows Autopatch Service Engineering team for device registration-related incidents.
|
||||
|
||||
@ -26,5 +26,4 @@ After you've completed enrollment in Windows Autopatch, some management settings
|
||||
|
||||
| Setting | Description |
|
||||
| ----- | ----- |
|
||||
| Conditional access policies | If you create any new conditional access or multi-factor authentication policies related to Azure AD, or Microsoft Intune after Windows Autopatch enrollment, exclude the Modern Workplace Service Accounts Azure AD group from them. For more information, see [Conditional Access: Users and groups](/azure/active-directory/conditional-access/concept-conditional-access-users-groups). Windows Autopatch maintains separate conditional access policies to restrict access to these accounts.<p>**To review the Windows Autopatch conditional access policy (Modern Workplace – Secure Workstation):**</p><p>Go to Microsoft Endpoint Manager and navigate to **Conditional Access** in **Endpoint Security**. Do **not** modify any Azure AD conditional access policies created by Windows Autopatch that have "**Modern Workplace**" in the name.</p> |
|
||||
| Update rings for Windows 10 or later | For any update rings for Windows 10 or later policies you've created, exclude the **Modern Workplace Devices - All** Azure AD group from each policy. For more information, see [Create and assign update rings](/mem/intune/protect/windows-10-update-rings#create-and-assign-update-rings).<p>Windows Autopatch will also have created some update ring policies. all of which The policies will have "**Modern Workplace**" in the name. For example:</p><ul><li>Modern Workplace Update Policy [Broad]-[Windows Autopatch]</li><li>Modern Workplace Update Policy [Fast]-[Windows Autopatch]</li><li>Modern Workplace Update Policy [First]-[Windows Autopatch]</li><li>Modern Workplace Update Policy [Test]-[Windows Autopatch]</li></ul><p>When you update your own policies, ensure that you don't exclude the **Modern Workplace Devices - All** Azure AD group from the policies that Windows Autopatch created.</p><p>**To resolve the Not ready result:**</p><p>After enrolling into Autopatch, make sure that any update ring policies you have **exclude** the **Modern Workplace Devices - All** Azure Active Directory (AD) group.For more information, see [Manage Windows 10 software updates in Intune](/mem/intune/protect/windows-update-for-business-configure).</p><p>**To resolve the Advisory result:**</p><ol><li>Make sure that any update ring policies you have **exclude** the **Modern Workplace Devices - All** Azure Active Directory (AD) group.</li> <li>If you have assigned Azure AD user groups to these policies, make sure that any update ring policies you have also **exclude** the **Modern Workplace - All** Azure AD group that you add your Windows Autopatch users to (or an equivalent group).</li></ol><p>For more information, see [Manage Windows 10 software updates in Intune](/mem/intune/protect/windows-update-for-business-configure).</p> |
|
||||
|
||||
@ -41,8 +41,6 @@ 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). |
|
||||
| Windows Autopatch cloud service accounts | After unenrollment, you may safely remove the cloud service accounts created during the enrollment process. The accounts are:<ul><li>MsAdmin</li><li>MsAdminInt</li><li>MsTest</li></ul> |
|
||||
| Conditional access policy | After unenrollment, you may safely remove the **Modern Workplace – Secure Workstation** conditional access policy. |
|
||||
| Microsoft Endpoint Manager roles | After unenrollment, you may safely remove the Modern Workplace Intune Admin role. |
|
||||
|
||||
## Unenroll from Windows Autopatch
|
||||
|
||||
@ -46,7 +46,7 @@ Each deployment ring has a different set of update deployment policies to contro
|
||||
Also, during the [device registration process](../deploy/windows-autopatch-device-registration-overview.md), Windows Autopatch assigns each device being registered to one of its deployment rings so that the service has the proper representation of the device diversity across the organization in each deployment ring. The deployment ring distribution is designed to release software update deployments to as few devices as possible to get the signals needed to make a quality evaluation of a given update deployment.
|
||||
|
||||
> [!NOTE]
|
||||
> Windows Autopatch deployment rings only apply to Windows quality updates. Additionally, you can't create additional deployment rings or use your own for devices managed by the Windows Autopatch service.
|
||||
> You can't create additional deployment rings or use your own for devices managed by the Windows Autopatch service.
|
||||
|
||||
### Deployment ring calculation logic
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@ metadata:
|
||||
description: Answers to frequently asked questions about Windows Autopatch.
|
||||
ms.prod: w11
|
||||
ms.topic: faq
|
||||
ms.date: 08/08/2022
|
||||
ms.date: 08/26/2022
|
||||
audience: itpro
|
||||
ms.localizationpriority: medium
|
||||
manager: dougeby
|
||||
@ -67,10 +67,10 @@ sections:
|
||||
No, Windows 365 Enterprise Cloud PC's support all features of Windows Autopatch. For more information, see [Virtual devices](/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices#virtual-devices).
|
||||
- question: Do my Cloud PCs appear any differently in the Windows Autopatch admin center?
|
||||
answer: |
|
||||
Cloud PC displays the model as the license type you have provisioned. For more information, see [Virtual devices](/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices#virtual-devices).
|
||||
Cloud PC displays the model as the license type you have provisioned. For more information, see [Windows Autopatch on Windows 365 Enterprise Workloads](/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices#windows-autopatch-on-windows-365-enterprise-workloads).
|
||||
- question: Can I run Autopatch on my Windows 365 Business Workloads?
|
||||
answer: |
|
||||
No. Autopatch is only available on enterprise workloads. For more information, see [Virtual devices](/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices#virtual-devices).
|
||||
No. Autopatch is only available on enterprise workloads. For more information, see [Windows Autopatch on Windows 365 Enterprise Workloads](/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices#windows-autopatch-on-windows-365-enterprise-workloads).
|
||||
- name: Update Management
|
||||
questions:
|
||||
- question: What systems does Windows Autopatch update?
|
||||
|
||||
@ -14,7 +14,7 @@ msreviewer: hathind
|
||||
|
||||
# Enroll your tenant
|
||||
|
||||
Before you enroll in Windows Autopatch, there are settings and other parameters you must set ahead of time.
|
||||
Before you enroll in Windows Autopatch, there are settings, and other parameters you must set ahead of time.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> You must be a Global Administrator to enroll your tenant.
|
||||
@ -30,7 +30,7 @@ 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 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).
|
||||
|
||||
**To access and run the Readiness assessment tool:**
|
||||
|
||||
@ -43,8 +43,6 @@ The Readiness assessment tool checks the settings in [Microsoft Endpoint Manager
|
||||
> [!IMPORTANT]
|
||||
> If you don't see the Tenant enrollment blade, this is because you don't meet the prerequisites or the proper licenses. For more information, see [Windows Autopatch prerequisites](windows-autopatch-prerequisites.md#more-about-licenses).
|
||||
|
||||
A Global Administrator should be used to run this tool. Other roles, such as the Global Reader and Intune Administrator have insufficient permissions to complete the checks on Conditional Access Policies and Multi-factor Authentication. For more information about the extra permissions, see [Conditional access policies](../prepare/windows-autopatch-fix-issues.md#conditional-access-policies).
|
||||
|
||||
The Readiness assessment tool checks the following settings:
|
||||
|
||||
### Microsoft Intune settings
|
||||
@ -62,9 +60,7 @@ The following are the Azure Active Directory settings:
|
||||
|
||||
| Check | Description |
|
||||
| ----- | ----- |
|
||||
| Conditional access | Verifies that conditional access policies and multi-factor authentication aren't assigned to all users.<p><p>Your conditional access policies must not prevent our service accounts from accessing the service and must not require multi-factor authentication. For more information, see [Conditional access policies](../prepare/windows-autopatch-fix-issues.md#conditional-access-policies). |
|
||||
| Windows Autopatch cloud service accounts | Checks that no usernames conflict with ones that Windows Autopatch reserves for its own use. The cloud service accounts are:<ul><li>MsAdmin</li><li>MsAdminInt</li><li>MsTest</li></ul> For more information, see [Tenant access](../references/windows-autopatch-privacy.md#tenant-access). |
|
||||
| Security defaults | Checks whether your Azure Active Directory organization has security defaults enabled. |
|
||||
| Co-management | This advisory check only applies if co-management is applied to your tenant. This check ensures that the proper workloads are in place for Windows Autopatch. If co-management doesn't apply to your tenant, this check can be safely disregarded, and won't block device deployment. |
|
||||
| Licenses | Checks that you've obtained the necessary [licenses](../prepare/windows-autopatch-prerequisites.md#more-about-licenses). |
|
||||
|
||||
### Check results
|
||||
|
||||
@ -25,7 +25,7 @@ For each check, the tool will report one of four possible results:
|
||||
| Ready | No action is required before completing enrollment. |
|
||||
| Advisory | Follow the steps in the tool or this article for the best experience with enrollment and for users.<p><p>You can complete enrollment, but you must fix these issues before you deploy your first device. |
|
||||
| Not ready | You must fix these issues before enrollment. You won’t be able to enroll into Windows Autopatch if you don't fix these issues. Follow the steps in the tool or this article to resolve them. |
|
||||
| Error | The Azure Active Directory (AD) role you're using doesn't have sufficient permission to run this check or your tenant is not properly licensed for Microsoft Intune. |
|
||||
| Error | The Azure Active Directory (AD) role you're using doesn't have sufficient permission to run this check or your tenant isn't properly licensed for Microsoft Intune. |
|
||||
|
||||
> [!NOTE]
|
||||
> The results reported by this tool reflect the status of your settings only at the time that you ran it. If you make changes later to policies in Microsoft Intune, Azure Active Directory (AD), or Microsoft 365, items that were "Ready" can become "Not ready". To avoid problems with Windows Autopatch operations, review the specific settings described in this article before you change any policies.
|
||||
@ -55,14 +55,13 @@ Your "Windows 10 update ring" policy in Intune must not target any Windows Autop
|
||||
|
||||
You can access Azure Active Directory (AD) settings in the [Azure portal](https://portal.azure.com/).
|
||||
|
||||
### Conditional access policies
|
||||
### Co-management
|
||||
|
||||
Conditional access policies must not prevent Windows Autopatch from connecting to your tenant.
|
||||
Co-management enables you to concurrently manage Windows 10 or later devices by using both Configuration Manager and Microsoft Intune.
|
||||
|
||||
| Result | Meaning |
|
||||
| ----- | ----- |
|
||||
| Advisory | You have at least one conditional access policy that targets all users or at least one conditional access policy set as required for multi-factor authentication. These policies could prevent Windows Autopatch from managing the Windows Autopatch service.<p><p>During enrollment, we'll attempt to exclude Windows Autopatch service accounts from relevant conditional access policies and apply new conditional access policies to restrict access to these accounts. However, if we're unsuccessful, this can cause errors during your enrollment experience.<p><p>For best practice, [create an assignment that targets a specific Azure Active Directory (AD) group](/azure/active-directory/fundamentals/active-directory-groups-create-azure-portal) that doesn't include Windows Autopatch service accounts.</p> |
|
||||
| Error | The Intune Administrator role doesn't have sufficient permissions for this check. You'll also need to have these Azure Active Directory (AD) roles assigned to run this check:<br><ul><li>Security Reader</li><li>Security Administrator</li><li>Conditional Access Administrator</li><li>Global Reader</li><li>Devices Administrator</li></ul> |
|
||||
| Advisory | To successfully enroll devices that are co-managed into Windows Autopatch, it's necessary that the following co-managed workloads are set to **Intune**:<ul><li>Device configuration</li><li>Windows update policies</li><li>Office 365 client apps</li></ul><p>If co-management doesn't apply to your tenant, this check can be safely disregarded, and it won't block device deployment.</p> |
|
||||
|
||||
### Licenses
|
||||
|
||||
@ -71,19 +70,3 @@ Windows Autopatch requires the following licenses:
|
||||
| Result | Meaning |
|
||||
| ----- | ----- |
|
||||
| Not ready | Windows Autopatch requires Windows 10/11 Enterprise E3 (or higher) to be assigned to your users. Additionally, Azure Active Directory Premium, and Microsoft Intune are required. For more information, see [more about licenses](../prepare/windows-autopatch-prerequisites.md#more-about-licenses). |
|
||||
|
||||
### Windows Autopatch cloud service accounts
|
||||
|
||||
Certain account names could conflict with account names created by Windows Autopatch.
|
||||
|
||||
| Result | Meaning |
|
||||
| ----- | ----- |
|
||||
| Not ready | You have at least one account name that will conflict with account names created by Windows Autopatch. The cloud service accounts are:<ul><li>MsAdmin</li><li>MsAdminInt</li><li>MsTest</li></ul><p>You must either rename or remove conflicting accounts to move forward with enrolling to the Windows Autopatch service as we'll create these accounts as part of running our service. For more information, see [Tenant Access](../references/windows-autopatch-privacy.md#tenant-access).</p> |
|
||||
|
||||
### Security defaults
|
||||
|
||||
Security defaults in Azure Active Directory (AD) will prevent Windows Autopatch from managing your devices.
|
||||
|
||||
| Result | Meaning |
|
||||
| ----- | ----- |
|
||||
| Not ready | You have Security defaults turned on. Turn off Security defaults and set up conditional access policies. For more information, see [Common conditional access policies](/azure/active-directory/conditional-access/concept-conditional-access-policy-common). |
|
||||
|
||||
@ -29,7 +29,7 @@ Getting started with Windows Autopatch has been designed to be easy. This articl
|
||||
|
||||
## More about licenses
|
||||
|
||||
Windows Autopatch is included with Window 10/11 Enterprise E3 or higher. The following are the other licenses that grant entitlement to Windows Autopatch:
|
||||
Windows Autopatch is included with Window 10/11 Enterprise E3 or higher (user-based only). The following are the service plan SKUs that are eligible for Windows Autopatch:
|
||||
|
||||
| License | ID | GUID number |
|
||||
| ----- | ----- | ------|
|
||||
|
||||
@ -22,7 +22,7 @@ Windows Autopatch will create a service principal in your tenant allowing the se
|
||||
|
||||
## Azure Active Directory groups
|
||||
|
||||
Windows Autopatch will create Azure Active Directory groups that are required to operate the service. The following groups are used for targeting Windows Autopatch configurations to devices and management of the service by our service accounts.
|
||||
Windows Autopatch will create Azure Active Directory groups that are required to operate the service. The following groups are used for targeting Windows Autopatch configurations to devices and management of the service by our [first party enterprise applications](#windows-autopatch-enterprise-applications).
|
||||
|
||||
| Group name | Description |
|
||||
| ----- | ----- |
|
||||
@ -37,10 +37,6 @@ Windows Autopatch will create Azure Active Directory groups that are required to
|
||||
| Modern Workplace Devices Dynamic - Windows 11 | Microsoft Managed Desktop Devices with Windows 11<p>Group Rule:<ul><li>`(device.devicePhysicalIds -any _ -startsWith \"[OrderID]:Microsoft365Managed_\")`</li><li>`(device.deviceOSVersion -startsWith \"10.0.22000\")`</li></ul><br>Exclusions:<ul><li>Modern Workplace - Telemetry Settings for Windows 10</li></ul> |
|
||||
| Modern Workplace Roles - Service Administrator | All users granted access to Modern Workplace Service Administrator Role |
|
||||
| Modern Workplace Roles - Service Reader | All users granted access to Modern Workplace Service Reader Role |
|
||||
| Modern Workplace Service - Intune Admin All | Group for Intune Admins<p>Assigned to: <ul><li>Modern Workplace Service Accounts</li></ul>|
|
||||
| Modern Workplace Service - Intune Reader All | Group for Intune readers<p>Assigned to: <ul><li>Modern Workplace Service Accounts</li></ul>|
|
||||
| Modern Workplace Service - Intune Reader MMD | Group for Intune readers of MMD devices and users<p>Assigned to:<ul><li>Modern Workplace Service Accounts</li></ul>|
|
||||
| Modern Workplace Service Accounts | Group for Windows Autopatch service accounts |
|
||||
| Windows Autopatch Device Registration | Group for automatic device registration for Windows Autopatch |
|
||||
|
||||
## Windows Autopatch enterprise applications
|
||||
@ -56,19 +52,6 @@ Windows Autopatch creates an enterprise application in your tenant. This enterpr
|
||||
> [!NOTE]
|
||||
> Enterprise application authentication is only available on tenants enrolled after July 9th, 2022. For tenants enrolled before this date, Enterprise Application authentication will be made available for enrollment soon.
|
||||
|
||||
## Windows Autopatch cloud service accounts
|
||||
|
||||
Windows Autopatch will create three cloud service accounts in your tenant. These accounts are used to run the service and all need to be excluded from any multi-factor authentication controls.
|
||||
|
||||
> [!NOTE]
|
||||
> Effective Aug 15th, 2022, these accounts will no longer be added to newly enrolled tenants, and existing tenants will be provided an option to migrate to enterprise application-based authentication. These accounts will be removed with that transition.
|
||||
|
||||
| Cloud service account name | Usage | Mitigating controls |
|
||||
| ----- | ----- | ------ |
|
||||
| MsAdmin@tenantDomain.onmicrosoft.com | <ul><li>This account is a limited-service account with administrator privileges. This account is used as an Intune and User administrator to define and configure the tenant for Microsoft Modern desktop devices.</li><li>This account doesn't have interactive sign-in permissions. The account performs operations only through the service.</li></ul> | Audited sign-ins |
|
||||
| MsAdminInt@tenantDomain.onmicrosoft.com | <ul><li>This account is an Intune and User administrator account used to define and configure the tenant for Modern Workplace devices.</li><li>This account is used for interactive sign-in to the customers’ tenant.</li><li>The use of this account is extremely limited as most operations are exclusively through msadmin (non-interactive).</li> | <ul><li>Restricted to be accessed only from defined secure access workstations (SAWs) through the Modern Workplace - Secure Workstation conditional access policy.</li><li>Audited sign-ins</li></ul> |
|
||||
| MsTest@tenantDomain.onmicrosoft.com | This is a standard account used as a validation account for initial configuration and roll out of policy, application, and device compliance settings. | Audited sign-ins |
|
||||
|
||||
## Device configuration policies
|
||||
|
||||
- Modern Workplace - Set MDM to Win Over GPO
|
||||
@ -145,15 +128,6 @@ Windows Autopatch will create three cloud service accounts in your tenant. These
|
||||
| Modern Workplace - Edge Update Channel Stable | Deploys updates via the Edge Stable Channel<p>Assigned to:<ul><li>Modern Workplace Devices-Windows Autopatch-First</li><li>Modern Workplace Devices-Windows Autopatch-Fast</li><li>Modern Workplace Devices-Windows Autopatch-Broad</li></ul>| `./Device/Vendor/MSFT/Policy/Config/MicrosoftEdgeUpdate~Policy~Cat_EdgeUpdate~Cat_Applications~Cat_MicrosoftEdge/Pol_TargetChannelMicrosoftEdge` | Enabled |
|
||||
| Modern Workplace - Edge Update Channel Beta | Deploys updates via the Edge Beta Channel<p>Assigned to:<ul><li>Modern Workplace Devices-Windows Autopatch-Test </li></ul>| `./Device/Vendor/MSFT/Policy/Config/MicrosoftEdgeUpdate~Policy~Cat_EdgeUpdate~Cat_Applications~Cat_MicrosoftEdge/Pol_TargetChannelMicrosoftEdge` | Enabled |
|
||||
|
||||
## Conditional access policies
|
||||
|
||||
> [!NOTE]
|
||||
> Effective Aug 15, 2022, the following policy will no longer be added to newly enrolled tenants, and existing tenants will be provided an option to migrate to enterprise application-based authentication. This policy will be removed with that transition.
|
||||
|
||||
| Conditional access policy | Description |
|
||||
| ----- | ----- |
|
||||
| Modern Workplace - Secure Workstation | This policy is targeted to only the Windows Autopatch cloud service accounts. The policy blocks access to the tenant unless the user is accessing the tenant from a Microsoft authorized location. |
|
||||
|
||||
## PowerShell scripts
|
||||
|
||||
| Script | Description |
|
||||
|
||||
@ -21,6 +21,7 @@
|
||||
"files": [
|
||||
"**/*.png",
|
||||
"**/*.jpg",
|
||||
"**/*.svg",
|
||||
"**/*.gif"
|
||||
],
|
||||
"exclude": [
|
||||
|
||||
@ -1,42 +0,0 @@
|
||||
---
|
||||
title: WebAuthn APIs
|
||||
description: Learn how to use WebAuthn APIs to enable password-less authentication for your sites and apps.
|
||||
ms.prod: m365-security
|
||||
author: paolomatarazzo
|
||||
ms.author: paoloma
|
||||
manager: aaroncz
|
||||
ms.reviewer: prsriva
|
||||
ms.collection: M365-identity-device-management
|
||||
ms.topic: article
|
||||
localizationpriority: medium
|
||||
ms.date: 02/15/2019
|
||||
---
|
||||
# WebAuthn APIs for password-less authentication on Windows
|
||||
|
||||
### Passwords leave your customers vulnerable. With the new WebAuthn APIs, your sites and apps can use password-less authentication.
|
||||
|
||||
Microsoft has long been a proponent to do away with passwords.
|
||||
While working towards that goal, we'd like to introduce you to the latest Windows 10 (version 1903) W3C/FIDO2 Win32 WebAuthn platform APIs!
|
||||
These APIs allow Microsoft developer partners and the developer community to use Windows Hello and FIDO2 security keys
|
||||
as a password-less authentication mechanism for their applications on Windows devices.
|
||||
|
||||
#### What does this mean?
|
||||
|
||||
This opens opportunities for developers or relying parties (RPs') to enable password-less authentication.
|
||||
They can now use [Windows Hello](./index.yml) or [FIDO2 Security Keys](./microsoft-compatible-security-key.md)
|
||||
as a password-less multi-factor credential for authentication.
|
||||
<br>
|
||||
Users of these sites can use any browser that supports WebAuthn Windows 10 APIs for password-less authentication
|
||||
and will have a familiar and consistent experience on Windows 10, no matter which browser they use to get to the RPs' site!
|
||||
<br> <br>
|
||||
The native Windows 10 WebAuthn APIs are currently supported by Microsoft Edge on Windows 10 1809 or later
|
||||
and latest versions of other browsers.
|
||||
<br> <br>
|
||||
Developers of FIDO2 authentication keys should use the new Windows 10 APIs, to enable these scenarios in a consistent way for users.
|
||||
Moreover, this enables the use of all the transports available per FIDO2 specifications - USB, NFC, and BLE
|
||||
without having to deal with the interaction and management overhead.
|
||||
This also implies browsers or apps on Windows 10 will no longer have direct access to above transports for FIDO-related messaging.
|
||||
|
||||
#### Where can developers learn more?
|
||||
|
||||
The new Windows 10 APIs are documented on [GitHub](https://github.com/Microsoft/webauthn)
|
||||
@ -84,7 +84,7 @@ sections:
|
||||
|
||||
- question: Can I use an external Windows Hello compatible camera when my computer has a built-in Windows Hello compatible camera?
|
||||
answer: |
|
||||
Yes. Starting with Windows 10, version 21H1 an external Windows Hello compatible camera can be used if a device already supports an internal Windows Hello camera. When both cameras are present, the external camera is used for face authentication. For more information, see [IT tools to support Windows 10, version 21H1](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/it-tools-to-support-windows-10-version-21h1/ba-p/2365103). However, using external Hello cameras and accessories is restricted if ESS is enabled, please see [Windows Hello Enhanced Sign-in Security](https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/windows-hello-enhanced-sign-in-security#pluggableperipheral-biometric-sensors).
|
||||
Yes. Starting with Windows 10, version 21H1 an external Windows Hello compatible camera can be used if a device already supports an internal Windows Hello camera. When both cameras are present, the external camera is used for face authentication. For more information, see [IT tools to support Windows 10, version 21H1](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/it-tools-to-support-windows-10-version-21h1/ba-p/2365103). However, using external Hello cameras and accessories is restricted if ESS is enabled, please see [Windows Hello Enhanced Sign-in Security](/windows-hardware/design/device-experiences/windows-hello-enhanced-sign-in-security#pluggableperipheral-biometric-sensors).
|
||||
|
||||
- question: Can I use an external Windows Hello compatible camera or other Windows Hello compatible accessory when my laptop lid is closed or docked?
|
||||
answer: |
|
||||
@ -155,7 +155,7 @@ 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](https://docs.microsoft.com/en-us/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](https://docs.microsoft.com/en-us/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: |
|
||||
@ -261,5 +261,4 @@ sections:
|
||||
|
||||
- question: Does Windows Hello for Business work with Azure Active Directory Domain Services (Azure AD DS) clients?
|
||||
answer: |
|
||||
No, Azure AD DS is a separately managed environment in Azure, and hybrid device registration with cloud Azure AD isn't available for it via Azure AD Connect. Hence, Windows Hello for Business doesn't work with Azure AD.
|
||||
|
||||
No, Azure AD DS is a separately managed environment in Azure, and hybrid device registration with cloud Azure AD isn't available for it via Azure AD Connect. Hence, Windows Hello for Business doesn't work with Azure AD DS.
|
||||
|
||||
@ -234,70 +234,34 @@ The _PIN reset_ configuration can be viewed by running [**dsregcmd /status**](/a
|
||||
|
||||
**Applies to:**
|
||||
|
||||
- Windows 10, version 1803 or later
|
||||
- Windows 11
|
||||
- Azure AD joined
|
||||
|
||||
The [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-authentication#authentication-configurewebsigninallowedurls) policy allows you to specify a list of domains that are allowed to be navigated to 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.
|
||||
|
||||
### Configuring Policy Using Intune
|
||||
|
||||
1. Sign-in to [Endpoint Manager admin center](https://endpoint.microsoft.com/) using a Global administrator account.
|
||||
|
||||
1. Click **Devices**. Click **Configuration profiles**. Click **Create profile**.
|
||||
|
||||
1. For Platform select **Windows 10 and later** and for Profile type select **Templates**. In the list of templates that is loaded, select **Custom** and click Create.
|
||||
|
||||
1. In the **Name** field type **Web Sign In Allowed URLs** and optionally provide a description for the configuration. Click Next.
|
||||
|
||||
1. On the Configuration settings page, click **Add** to add a custom OMA-URI setting. Provide the following information for the custom settings:
|
||||
|
||||
- **Name:** Web Sign In Allowed URLs
|
||||
- **Description:** (Optional) List of domains that are allowed during PIN reset flows.
|
||||
- **OMA-URI:** ./Vendor/MSFT/Policy/Config/Authentication/ConfigureWebSignInAllowedUrls
|
||||
- **Data type:** String
|
||||
- **Value**: Provide a semicolon delimited list of domains needed for authentication during the PIN reset scenario. An example value would be _signin.contoso.com;portal.contoso.com_ (without quotation marks)
|
||||
|
||||
:::image type="content" alt-text="Custom Configuration for ConfigureWebSignInAllowedUrls policy." source="images/pinreset/allowlist.png" lightbox="images/pinreset/allowlist.png":::
|
||||
|
||||
1. Click the **Save** button to save the custom configuration.
|
||||
|
||||
1. On the Assignments page, use the Included groups and Excluded groups sections to define the groups of users or devices that should receive this policy. Once you have completed configuring groups click the Next button.
|
||||
|
||||
1. On the Applicability rules page, click **Next**.
|
||||
|
||||
1. Review the configuration that is shown on the Review + create page to make sure that it is accurate. Click create to save the profile and apply it to the configured groups.
|
||||
|
||||
### Configure Web Sign-in Allowed URLs for Third Party Identity Providers on Azure AD Joined Devices
|
||||
- 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.
|
||||
|
||||
### Configure Web Sign-in Allowed URLs using Microsoft Intune
|
||||
|
||||
#### Configure Web Sign-in Allowed URLs using Microsoft Intune
|
||||
|
||||
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. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com)
|
||||
1. Select **Devices** > **Configuration profiles** > **Create profile**
|
||||
1. Enter the following properties:
|
||||
- **Platform**: Select **Windows 10 and later**.
|
||||
- **Profile type**: Select **Templates**.
|
||||
- In the list of templates that is loaded, select **Custom** > **Create**.
|
||||
- **Platform**: Select **Windows 10 and later**
|
||||
- **Profile type**: Select **Templates**
|
||||
- In the list of templates that is loaded, select **Custom** > **Create**
|
||||
1. In **Basics**, enter the following properties:
|
||||
- **Name**: Enter a descriptive name for the profile.
|
||||
- **Description**: Enter a description for the profile. This setting is optional, but recommended.
|
||||
1. Select **Next**.
|
||||
- **Name**: Enter a descriptive name for the profile
|
||||
- **Description**: Enter a description for the profile. This setting is optional, but recommended
|
||||
1. Select **Next**
|
||||
1. In **Configuration settings**, select **Add** and enter the following settings:
|
||||
- Name: **Web Sign In Allowed URLs**
|
||||
- Description: **(Optional) List of domains that are allowed during PIN reset flows**
|
||||
- OMA-URI: `./Vendor/MSFT/Policy/Config/Authentication/ConfigureWebSignInAllowedUrls`
|
||||
- Data type: **String**
|
||||
- Value: Provide a semicolon delimited list of domains needed for authentication during the PIN reset scenario. An example value would be **signin.contoso.com;portal.contoso.com** (without quotation marks).
|
||||
- Value: Provide a semicolon delimited list of domains needed for authentication during the PIN reset scenario. An example value would be **signin.contoso.com;portal.contoso.com**
|
||||
:::image type="content" alt-text="Custom Configuration for ConfigureWebSignInAllowedUrls policy." source="images/pinreset/allowlist.png" lightbox="images/pinreset/allowlist-expanded.png":::
|
||||
1. Select **Save** > **Next**.
|
||||
1. In **Assignments**, select the security groups that will receive the policy.
|
||||
1. Select **Next**.
|
||||
1. In **Applicability Rules**, select **Next**.
|
||||
1. In **Review + create**, review your settings and select **Create**.
|
||||
|
||||
1. Select **Save** > **Next**
|
||||
1. In **Assignments**, select the security groups that will receive the policy
|
||||
1. Select **Next**
|
||||
1. In **Applicability Rules**, select **Next**
|
||||
1. In **Review + create**, review your settings and select **Create**
|
||||
|
||||
> [!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.
|
||||
|
||||
@ -253,3 +253,7 @@ Windows Hello for Business cloud trust requires line of sight to a domain contro
|
||||
### Can I use RDP/VDI with Windows Hello for Business cloud trust?
|
||||
|
||||
Windows Hello for Business cloud trust cannot be used as a supplied credential with RDP/VDI. Similar to key trust, cloud trust can be used for RDP with [remote credential guard](/windows/security/identity-protection/remote-credential-guard) or if a [certificate is enrolled into Windows Hello for Business](hello-deployment-rdp-certs.md) for this purpose.
|
||||
|
||||
### Do all my domain controllers need to be fully patched as per the prerequisites for me to use Windows Hello for Business cloud trust?
|
||||
|
||||
No, only the number necessary to handle the load from all cloud trust devices.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 48 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 46 KiB |
@ -21,6 +21,8 @@
|
||||
href: hello-how-it-works-provisioning.md
|
||||
- name: Authentication
|
||||
href: hello-how-it-works-authentication.md
|
||||
- name: WebAuthn APIs
|
||||
href: webauthn-apis.md
|
||||
- name: How-to Guides
|
||||
items:
|
||||
- name: Windows Hello for Business Deployment Overview
|
||||
|
||||
@ -0,0 +1,122 @@
|
||||
---
|
||||
title: WebAuthn APIs
|
||||
description: Learn how to use WebAuthn APIs to enable passwordless authentication for your sites and apps.
|
||||
ms.prod: m365-security
|
||||
author: paolomatarazzo
|
||||
ms.author: paoloma
|
||||
manager: aaroncz
|
||||
ms.reviewer: prsriva
|
||||
ms.collection: M365-identity-device-management
|
||||
ms.topic: article
|
||||
localizationpriority: medium
|
||||
ms.date: 08/30/2022
|
||||
appliesto:
|
||||
- ✅ <b>Windows 10</b>
|
||||
- ✅ <b>Windows 11</b>
|
||||
---
|
||||
# WebAuthn APIs for passwordless authentication on Windows
|
||||
|
||||
Passwords can leave your customers vulnerable to data breaches and security attacks by malicious users.
|
||||
|
||||
Microsoft has long been a proponent of passwordless authentication, and introduced the W3C/Fast IDentity Online 2 (FIDO2) Win32 WebAuthn platform APIs in Windows 10 (version 1903).
|
||||
|
||||
## What does this mean?
|
||||
|
||||
By using WebAuthn APIs, developer partners and the developer community can use [Windows Hello](./index.yml) or [FIDO2 Security Keys](./microsoft-compatible-security-key.md) to implement passwordless multi-factor authentication for their applications on Windows devices.
|
||||
|
||||
Users of these apps or sites can use any browser that supports WebAuthn APIs for passwordless authentication. Users will have a familiar and consistent experience on Windows, no matter which browser they use.
|
||||
|
||||
Developers should use the WebAuthn APIs to support FIDO2 authentication keys in a consistent way for users. Additionally, developers can use all the transports that are available per FIDO2 specifications (USB, NFC, and BLE) while avoiding the interaction and management overhead.
|
||||
|
||||
> [!NOTE]
|
||||
> When these APIs are in use, Windows 10 browsers or apps don't have direct access to the FIDO2 transports for FIDO-related messaging.
|
||||
|
||||
## The big picture
|
||||
|
||||
Client to Authenticator Protocol 2 (CTAP2) and WebAuthn define an abstraction layer that creates an ecosystem for strongly authenticated credentials. In this ecosystem, any interoperable client (such as a native app or browser) that runs on a given client device uses a standardized method to interact with any interoperable authenticator. Interoperable authenticators include authenticators that are built into the client device (platform authenticators) and authenticators that connect to the client device by using USB, BLE, or NFC connections (roaming authenticators).
|
||||
|
||||
The authentication process starts when the user makes a specific user gesture that indicates consent for the operation. At the request of the client, the authenticator securely creates strong cryptographic keys and stores them locally.
|
||||
|
||||
After these client-specific keys are created, clients can request attestations for registration and authentication. The type of signature that the private key uses reflects the user gesture that was made.
|
||||
|
||||
The following diagram shows how CTAP and WebAuthn interact. The light blue dotted arrows represent interactions that depend on the specific implementation of the platform APIs.
|
||||
|
||||
:::image type="content" source="images/webauthn-apis/webauthn-apis-fido2-overview.png" alt-text="The diagram shows how the WebAuthn API interacts with the relying parties and the CTAPI2 API.":::
|
||||
|
||||
*Relationships of the components that participate in passwordless authentication*
|
||||
|
||||
A combined WebAuthn/CTAP2 dance includes the following cast of characters:
|
||||
|
||||
- **Client device**. The *client device* is the hardware that hosts a given strong authentication. Laptops and phones are examples of client devices.
|
||||
|
||||
- **Relying parties and clients**. *Relying parties* are web or native applications that consume strong credentials. The relying parties run on client devices.
|
||||
|
||||
- As a relying party, a native application can also act as a WebAuthn client to make direct WebAuthn calls.
|
||||
|
||||
- As a relying party, a web application can't directly interact with the WebAuthn API. The relying party must broker the deal through the browser.
|
||||
|
||||
> [!NOTE]
|
||||
> The preceding diagram doesn't depict single sign-on authentication. Be careful not to confuse FIDO relying parties with federated relying parties.
|
||||
|
||||
- **WebAuthn API**. The *WebAuthn API* enables clients to make requests to authenticators. The client can request that the authenticator create a key, provide an assertion about a key, report capabilities, manage a PIN, and so on.
|
||||
|
||||
- **CTAP2 platform/host**. The *platform* (also called the host in the CTAP2 spec) is the part of the client device that negotiates with authenticators. The platform is responsible for securely reporting the origin of the request and for calling the CTAP2 Concise Binary Object Representation (CBOR) APIs. If the platform isn't CTAP2-aware, the clients themselves take on more of the burden. In this case, the components and interactions of the preceding diagram may differ.
|
||||
|
||||
- **Platform authenticator**. A *platform authenticator* usually resides on a client device. Examples of platform authenticators include fingerprint recognition technology that uses a built-in laptop fingerprint reader and facial recognition technology that uses a built-in smartphone camera. Cross-platform transport protocols such as USB, NFC or BLE can't access platform authenticators.
|
||||
|
||||
- **Roaming authenticator**. A *roaming authenticator* can connect to multiple client devices. Client devices must use a supported transport protocol to negotiate interactions. Examples of roaming authenticators include USB security keys, BLE-enabled smartphone applications, and NFC-enabled proximity cards. Roaming authenticators can support CTAP1, CTAP2, or both protocols.
|
||||
|
||||
Many relying parties and clients can interact with many authenticators on a single client device. A user can install multiple browsers that support WebAuthn, and might simultaneously have access to a built-in fingerprint reader, a plugged-in security key, and a BLE-enabled mobile app.
|
||||
|
||||
## Interoperability
|
||||
|
||||
Before there was WebAuthn and CTAP2, there was U2F and CTAP1. U2F is the FIDO Alliance universal second-factor specification. There are many authenticators that speak CTAP1 and manage U2F credentials. WebAuthn was designed to be interoperable with CTAP1 Authenticators. A relying party that uses WebAuthn can still use U2F credentials if the relying party doesn't require FIDO2-only functionality.
|
||||
|
||||
FIDO2 authenticators have already implemented and WebAuthn relying parties might require the following optional features:
|
||||
|
||||
- Keys for multiple accounts (keys can be stored per relying party)
|
||||
- Client PIN
|
||||
- Location (the authenticator returns a location)
|
||||
- [Hash-based Message Authentication Code (HMAC)-secret](/dotnet/api/system.security.cryptography.hmac) (enables offline scenarios)
|
||||
|
||||
The following options and might be useful in the future, but haven't been observed in the wild yet:
|
||||
|
||||
- Transactional approval
|
||||
- User verification index (servers can determine whether biometric data that's stored locally has changed over time)
|
||||
- User verification method (the authenticator returns the exact method)
|
||||
- Biometric performance bounds (the relying party can specify acceptable false acceptance and false rejection rates)
|
||||
|
||||
## Microsoft implementation
|
||||
|
||||
The Microsoft FIDO2 implementation has been years in the making. Software and services are implemented independently as standards-compliant entities. As of the Windows 10, version 1809 (October 2018) release, all Microsoft components use the latest WebAuthn Candidate Release. It's a stable release that's not expected to normatively change before the specification is finally ratified. Because Microsoft is among the first in the world to deploy FIDO2, some combinations of popular non-Microsoft components won't be interoperable yet.
|
||||
|
||||
Here's an approximate layout of where the Microsoft bits go:
|
||||
|
||||
:::image type="content" source="images/webauthn-apis/webauthn-apis-fido2-overview-microsoft-version.png" alt-text="The diagram shows how the WebAuthn API interacts with the Microsoft relying parties and the CTAPI2 API.":::
|
||||
|
||||
*Microsoft's implementation of WebAuthn and CATP2 APIs*
|
||||
|
||||
- **WebAuthn relying party: Microsoft Account**. If you aren't familiar with Microsoft Account, it's the sign-in service for Xbox, Outlook, and many other sites. The sign-in experience uses client-side JavaScript to trigger Microsoft Edge to talk to the WebAuthn APIs. Microsoft Account requires that authenticators have the following characteristics:
|
||||
|
||||
- Keys are stored locally on the authenticator and not on a remote server
|
||||
- Offline scenarios work (enabled by using HMAC)
|
||||
- Users can put keys for multiple user accounts on the same authenticator
|
||||
- If it's necessary, authenticators can use a client PIN to unlock a TPM
|
||||
> [!IMPORTANT]
|
||||
> Because Microsoft Account requires features and extensions that are unique to FIDO2 CTAP2 authenticators, it doesn't accept CTAP1 (U2F) credentials.
|
||||
|
||||
- **WebAuthn client: Microsoft Edge**. Microsoft Edge can handle the user interface for the WebAuthn and CTAP2 features that this article describes. It also supports the AppID extension. Microsoft Edge can interact with both CTAP1 and CTAP2 authenticators. This means that it can create and use both U2F and FIDO2 credentials. However, Microsoft Edge doesn't speak the U2F protocol. Therefore, relying parties must use only the WebAuthn specification. Microsoft Edge on Android doesn't support WebAuthn.
|
||||
|
||||
> [!NOTE]
|
||||
> For authoritative information about Microsoft Edge support for WebAuthn and CTAP, see [Legacy Microsoft Edge developer documentation](/microsoft-edge/dev-guide/windows-integration/web-authentication).
|
||||
|
||||
- **Platform: Windows 10, Windows 11**. Windows 10 and Windows 11 host the Win32 Platform WebAuthn APIs.
|
||||
|
||||
- **Roaming Authenticators**. You might notice that there's no *Microsoft* roaming authenticator. That's because there's already a strong ecosystem of products that specialize in strong authentication, and every one of our customers (whether corporations or individuals) has different requirements for security, ease of use, distribution, and account recovery. To see the ever-growing list of FIDO2 certified authenticators, see [FIDO Certified Products](https://fidoalliance.org/certification/fido-certified-products/). The list includes built-in authenticators, roaming authenticators, and even chip manufacturers who have certified designs.
|
||||
|
||||
## Developer references
|
||||
|
||||
The WebAuthn APIs are documented in the [Microsoft/webauthn](https://github.com/Microsoft/webauthn) GitHub repo. To understand how FIDO2 authenticators work, review the following two specifications:
|
||||
|
||||
- [Web Authentication: An API for accessing Public Key Credentials](https://www.w3.org/TR/webauthn/) (available on the W3C site). This document is known as the WebAuthn spec.
|
||||
- [Client to Authenticator Protocol (CTAP)](https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id-20180227.html). This is available at the [FIDO Alliance](http://fidoalliance.org/) site, on which hardware and platform teams are working together to solve the problem of FIDO authentication.
|
||||
@ -133,13 +133,13 @@ landingContent:
|
||||
- linkListType: concept
|
||||
links:
|
||||
- text: Mobile device management
|
||||
url: https://docs.microsoft.com/windows/client-management/mdm/
|
||||
url: /windows/client-management/mdm/
|
||||
- text: Azure Active Directory
|
||||
url: https://www.microsoft.com/security/business/identity-access-management/azure-active-directory
|
||||
- text: Your Microsoft Account
|
||||
url: identity-protection/access-control/microsoft-accounts.md
|
||||
- text: OneDrive
|
||||
url: https://docs.microsoft.com/onedrive/onedrive
|
||||
url: /onedrive/onedrive
|
||||
- text: Family safety
|
||||
url: threat-protection/windows-defender-security-center/wdsc-family-options.md
|
||||
# Cards and links should be based on top customer tasks or top subjects
|
||||
@ -170,4 +170,3 @@ landingContent:
|
||||
links:
|
||||
- text: Windows and Privacy Compliance
|
||||
url: /windows/privacy/windows-10-and-privacy-compliance
|
||||
|
||||
|
||||
@ -31,7 +31,7 @@ Application Guard uses both network isolation and application-specific settings.
|
||||
These settings, located at `Computer Configuration\Administrative Templates\Network\Network Isolation`, help you define and manage your organization's network boundaries. Application Guard uses this information to automatically transfer any requests to access the non-corporate resources into the Application Guard container.
|
||||
|
||||
> [!NOTE]
|
||||
> For Windows 10, if you have KB5014666 installed, and for Windows 11, if you have KB5014668 installed, you don't need to configure network isolation policy to enable Application Guard for Microsoft Edge.
|
||||
> For Windows 10, if you have KB5014666 installed, and for Windows 11, if you have KB5014668 installed, you don't need to configure network isolation policy to enable Application Guard for Microsoft Edge in managed mode.
|
||||
|
||||
> [!NOTE]
|
||||
> You must configure either the Enterprise resource domains hosted in the cloud or Private network ranges for apps settings on your employee devices to successfully turn on Application Guard using enterprise mode. Proxy servers must be a neutral resource listed in the **Domains categorized as both work and personal** policy.
|
||||
@ -56,15 +56,15 @@ These settings, located at `Computer Configuration\Administrative Templates\Wind
|
||||
|
||||
|Name|Supported versions|Description|Options|
|
||||
|-----------|------------------|-----------|-------|
|
||||
|Configure Microsoft Defender Application Guard clipboard settings|Windows 10 Enterprise, 1709 or higher<p>Windows 10 Pro, 1803 or higher<p>Windows 11|Determines whether Application Guard can use the clipboard functionality.|**Enabled.** Turns On the clipboard functionality and lets you choose whether to additionally:<br/>- Disable the clipboard functionality completely when Virtualization Security is enabled.<br/>- Enable copying of certain content from Application Guard into Microsoft Edge.<br/>- Enable copying of certain content from Microsoft Edge into Application Guard. **Important:** Allowing copied content to go from Microsoft Edge into Application Guard can cause potential security risks and isn't recommended.<p>**Disabled or not configured.** Completely turns Off the clipboard functionality for Application Guard.|
|
||||
|Configure Microsoft Defender Application Guard print settings|Windows 10 Enterprise, 1709 or higher<p>Windows 10 Pro, 1803 or higher<p>Windows 11|Determines whether Application Guard can use the print functionality.|**Enabled.** Turns On the print functionality and lets you choose whether to additionally:<br/>- Enable Application Guard to print into the XPS format.<br/>- Enable Application Guard to print into the PDF format.<br/>- Enable Application Guard to print to locally attached printers.<br/>- Enable Application Guard to print from previously connected network printers. Employees can't search for other printers.<br/><br/>**Disabled or not configured.** Completely turns Off the print functionality for Application Guard.|
|
||||
|Allow Persistence|Windows 10 Enterprise, 1709 or higher<br><br>Windows 10 Pro, 1803 or higher<p>Windows 11|Determines whether data persists across different sessions in Microsoft Defender Application Guard.|**Enabled.** Application Guard saves user-downloaded files and other items (such as, cookies, Favorites, and so on) for use in future Application Guard sessions.<p>**Disabled or not configured.** All user data within Application Guard is reset between sessions.<p>**NOTE**: If you later decide to stop supporting data persistence for your employees, you can use our Windows-provided utility to reset the container and to discard any personal data.<p>**To reset the container:**<br/>1. Open a command-line program and navigate to `Windows/System32`.<br/>2. Type `wdagtool.exe cleanup`. The container environment is reset, retaining only the employee-generated data.<br/>3. Type `wdagtool.exe cleanup RESET_PERSISTENCE_LAYER`. The container environment is reset, including discarding all employee-generated data.|
|
||||
|Configure Microsoft Defender Application Guard clipboard settings|Windows 10 Enterprise, 1709 or higher<p>Windows 10 Pro, 1803 or higher<p>Windows 11|Determines whether Application Guard can use the clipboard functionality.|**Enabled.** This is effective only in managed mode. Turns On the clipboard functionality and lets you choose whether to additionally:<br/>- Disable the clipboard functionality completely when Virtualization Security is enabled.<br/>- Enable copying of certain content from Application Guard into Microsoft Edge.<br/>- Enable copying of certain content from Microsoft Edge into Application Guard. **Important:** Allowing copied content to go from Microsoft Edge into Application Guard can cause potential security risks and isn't recommended.<p>**Disabled or not configured.** Completely turns Off the clipboard functionality for Application Guard.|
|
||||
|Configure Microsoft Defender Application Guard print settings|Windows 10 Enterprise, 1709 or higher<p>Windows 10 Pro, 1803 or higher<p>Windows 11|Determines whether Application Guard can use the print functionality.|**Enabled.** This is effective only in managed mode. Turns On the print functionality and lets you choose whether to additionally:<br/>- Enable Application Guard to print into the XPS format.<br/>- Enable Application Guard to print into the PDF format.<br/>- Enable Application Guard to print to locally attached printers.<br/>- Enable Application Guard to print from previously connected network printers. Employees can't search for other printers.<br/><br/>**Disabled or not configured.** Completely turns Off the print functionality for Application Guard.|
|
||||
|Allow Persistence|Windows 10 Enterprise, 1709 or higher<br><br>Windows 10 Pro, 1803 or higher<p>Windows 11|Determines whether data persists across different sessions in Microsoft Defender Application Guard.|**Enabled.** This is effective only in managed mode. Application Guard saves user-downloaded files and other items (such as, cookies, Favorites, and so on) for use in future Application Guard sessions.<p>**Disabled or not configured.** All user data within Application Guard is reset between sessions.<p>**NOTE**: If you later decide to stop supporting data persistence for your employees, you can use our Windows-provided utility to reset the container and to discard any personal data.<p>**To reset the container:**<br/>1. Open a command-line program and navigate to `Windows/System32`.<br/>2. Type `wdagtool.exe cleanup`. The container environment is reset, retaining only the employee-generated data.<br/>3. Type `wdagtool.exe cleanup RESET_PERSISTENCE_LAYER`. The container environment is reset, including discarding all employee-generated data.|
|
||||
|Turn on Microsoft Defender Application Guard in Managed Mode|Windows 10 Enterprise, 1809 or higher<p>Windows 11|Determines whether to turn on Application Guard for Microsoft Edge and Microsoft Office.|**Enabled.** Turns on Application Guard for Microsoft Edge and/or Microsoft Office, honoring the network isolation settings, rendering untrusted content in the Application Guard container. Application Guard won't actually be turned on unless the required prerequisites and network isolation settings are already set on the device. Available options:<br/>- Enable Microsoft Defender Application Guard only for Microsoft Edge<br/>- Enable Microsoft Defender Application Guard only for Microsoft Office<br/>- Enable Microsoft Defender Application Guard for both Microsoft Edge and Microsoft Office<br/><br/>**Disabled.** Turns off Application Guard, allowing all apps to run in Microsoft Edge and Microsoft Office. <br/><br/>**Note:** For Windows 10, if you have KB5014666 installed, and for Windows 11, if you have KB5014668 installed, you are no longer required to configure network isolation policy to enable Application Guard for Edge.|
|
||||
|Allow files to download to host operating system|Windows 10 Enterprise, 1803 or higher<p>Windows 11|Determines whether to save downloaded files to the host operating system from the Microsoft Defender Application Guard container.|**Enabled.** Allows users to save downloaded files from the Microsoft Defender Application Guard container to the host operating system. This action creates a share between the host and container that also allows for uploads from the host to the Application Guard container.<p>**Disabled or not configured.** Users aren't able to save downloaded files from Application Guard to the host operating system.|
|
||||
|Allow hardware-accelerated rendering for Microsoft Defender Application Guard|Windows 10 Enterprise, 1803 or higher<br><br>Windows 10 Pro, 1803 or higher<p>Windows 11|Determines whether Microsoft Defender Application Guard renders graphics using hardware or software acceleration.|**Enabled.** Microsoft Defender Application Guard uses Hyper-V to access supported, high-security rendering graphics hardware (GPUs). These GPUs improve rendering performance and battery life while using Microsoft Defender Application Guard, particularly for video playback and other graphics-intensive use cases. If this setting is enabled without connecting any high-security rendering graphics hardware, Microsoft Defender Application Guard will automatically revert to software-based (CPU) rendering. **Important:** Enabling this setting with potentially compromised graphics devices or drivers might pose a risk to the host device.<br><br>**Disabled or not configured.** Microsoft Defender Application Guard uses software-based (CPU) rendering and won’t load any third-party graphics drivers or interact with any connected graphics hardware.|
|
||||
|Allow camera and microphone access in Microsoft Defender Application Guard|Windows 10 Enterprise, 1809 or higher<br><br>Windows 10 Pro, 1809 or higher<p>Windows 11|Determines whether to allow camera and microphone access inside Microsoft Defender Application Guard.|**Enabled.** Applications inside Microsoft Defender Application Guard are able to access the camera and microphone on the user's device. **Important:** Enabling this policy with a potentially compromised container could bypass camera and microphone permissions and access the camera and microphone without the user's knowledge.<p>**Disabled or not configured.** Applications inside Microsoft Defender Application Guard are unable to access the camera and microphone on the user's device.|
|
||||
|Allow files to download to host operating system|Windows 10 Enterprise, 1803 or higher<p>Windows 11|Determines whether to save downloaded files to the host operating system from the Microsoft Defender Application Guard container.|**Enabled.** This is effective only in managed mode. Allows users to save downloaded files from the Microsoft Defender Application Guard container to the host operating system. This action creates a share between the host and container that also allows for uploads from the host to the Application Guard container.<p>**Disabled or not configured.** Users aren't able to save downloaded files from Application Guard to the host operating system.|
|
||||
|Allow hardware-accelerated rendering for Microsoft Defender Application Guard|Windows 10 Enterprise, 1803 or higher<br><br>Windows 10 Pro, 1803 or higher<p>Windows 11|Determines whether Microsoft Defender Application Guard renders graphics using hardware or software acceleration.|**Enabled.** This is effective only in managed mode. Microsoft Defender Application Guard uses Hyper-V to access supported, high-security rendering graphics hardware (GPUs). These GPUs improve rendering performance and battery life while using Microsoft Defender Application Guard, particularly for video playback and other graphics-intensive use cases. If this setting is enabled without connecting any high-security rendering graphics hardware, Microsoft Defender Application Guard will automatically revert to software-based (CPU) rendering. **Important:** Enabling this setting with potentially compromised graphics devices or drivers might pose a risk to the host device.<br><br>**Disabled or not configured.** Microsoft Defender Application Guard uses software-based (CPU) rendering and won’t load any third-party graphics drivers or interact with any connected graphics hardware.|
|
||||
|Allow camera and microphone access in Microsoft Defender Application Guard|Windows 10 Enterprise, 1809 or higher<br><br>Windows 10 Pro, 1809 or higher<p>Windows 11|Determines whether to allow camera and microphone access inside Microsoft Defender Application Guard.|**Enabled.** This is effective only in managed mode. Applications inside Microsoft Defender Application Guard are able to access the camera and microphone on the user's device. **Important:** Enabling this policy with a potentially compromised container could bypass camera and microphone permissions and access the camera and microphone without the user's knowledge.<p>**Disabled or not configured.** Applications inside Microsoft Defender Application Guard are unable to access the camera and microphone on the user's device.|
|
||||
|Allow Microsoft Defender Application Guard to use Root Certificate Authorities from a user's device|Windows 10 Enterprise, 1809 or higher<br><br>Windows 10 Pro, 1809 or higher<p>Windows 11|Determines whether Root Certificates are shared with Microsoft Defender Application Guard.|**Enabled.** Certificates matching the specified thumbprint are transferred into the container. Use a comma to separate multiple certificates.<p>**Disabled or not configured.** Certificates aren't shared with Microsoft Defender Application Guard.|
|
||||
|Allow auditing events in Microsoft Defender Application Guard|Windows 10 Enterprise, 1809 or higher<br><br>Windows 10 Pro, 1809 or higher<p>Windows 11|This policy setting allows you to decide whether auditing events can be collected from Microsoft Defender Application Guard.|**Enabled.** Application Guard inherits auditing policies from your device and logs system events from the Application Guard container to your host.<p>**Disabled or not configured.** event logs aren't collected from your Application Guard container.|
|
||||
|Allow auditing events in Microsoft Defender Application Guard|Windows 10 Enterprise, 1809 or higher<br><br>Windows 10 Pro, 1809 or higher<p>Windows 11|This policy setting allows you to decide whether auditing events can be collected from Microsoft Defender Application Guard.|**Enabled.** This is effective only in managed mode. Application Guard inherits auditing policies from your device and logs system events from the Application Guard container to your host.<p>**Disabled or not configured.** Event logs aren't collected from your Application Guard container.|
|
||||
|
||||
## Application Guard support dialog settings
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ ms.pagetype: security
|
||||
ms.localizationpriority: medium
|
||||
author: denisebmsft
|
||||
ms.author: deniseb
|
||||
ms.date: 10/20/2021
|
||||
ms.date: 08/25/2022
|
||||
ms.reviewer:
|
||||
manager: dansimp
|
||||
ms.custom: asr
|
||||
@ -31,6 +31,9 @@ The threat landscape is continually evolving. While hackers are busy developing
|
||||
|
||||
Your environment must have the following hardware to run Microsoft Defender Application Guard.
|
||||
|
||||
> [!NOTE]
|
||||
> Application Guard currently isn't supported on Windows 11 ARM64 devices.
|
||||
|
||||
| Hardware | Description |
|
||||
|--------|-----------|
|
||||
| 64-bit CPU|A 64-bit computer with minimum four cores (logical processors) is required for hypervisor and virtualization-based security (VBS). For more info about Hyper-V, see [Hyper-V on Windows Server 2016](/windows-server/virtualization/hyper-v/hyper-v-on-windows-server) or [Introduction to Hyper-V on Windows 10](/virtualization/hyper-v-on-windows/about/). For more info about hypervisor, see [Hypervisor Specifications](/virtualization/hyper-v-on-windows/reference/tlfs).|
|
||||
|
||||
@ -14,7 +14,7 @@ author: jsuther1974
|
||||
ms.reviewer: jogeurte
|
||||
ms.author: dansimp
|
||||
manager: dansimp
|
||||
ms.date: 05/12/2022
|
||||
ms.date: 08/26/2022
|
||||
ms.technology: windows-sec
|
||||
---
|
||||
|
||||
@ -29,21 +29,21 @@ ms.technology: windows-sec
|
||||
> [!NOTE]
|
||||
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
|
||||
|
||||
Windows 10 (version 1703) introduced a new option for Windows Defender Application Control (WDAC), called _managed installer_, that helps balance security and manageability when enforcing application control policies. This option lets you automatically allow applications installed by a designated software distribution solution such as Microsoft Endpoint Configuration Manager.
|
||||
Windows Defender Application Control (WDAC) includes an option called **managed installer** that helps balance security and manageability when enforcing application control policies. This option lets you automatically allow applications installed by a designated software distribution solution, such as Microsoft Endpoint Configuration Manager (MEMCM) or Microsoft Intune.
|
||||
|
||||
## How does a managed installer work?
|
||||
|
||||
Managed installer uses a special rule collection in **AppLocker** to designate binaries that are trusted by your organization as an authorized source for application installation. When one of these trusted binaries runs, Windows monitors the binary's process (and processes it launches) and watches for files being written to disk. As files are written, they're tagged as originating from a managed installer.
|
||||
Managed installer uses a special rule collection in **AppLocker** to designate binaries that are trusted by your organization as an authorized source for application installation. When one of these trusted binaries runs, Windows monitors the binary's process (and any child processes it launches) and watches for files being written to disk. As files are written, they're tagged as originating from a managed installer.
|
||||
|
||||
You can then configure WDAC to trust files that are installed by a managed installer by adding the "Enabled:Managed Installer" option to your WDAC policy. When that option is set, WDAC will check for managed installer origin information when determining whether or not to allow a binary to run. As long as there are no deny rules for the binary, WDAC will allow it to run based purely on its managed installer origin.
|
||||
|
||||
## Security considerations with managed installer
|
||||
|
||||
Since managed installer is a heuristic-based mechanism, it doesn't provide the same security guarantees that explicit allow or deny rules do. The managed installer is best suited for use where each user operates as a standard user and where all software is deployed and installed by a software distribution solution, such as Microsoft Endpoint Configuration Manager.
|
||||
Since managed installer is a heuristic-based mechanism, it doesn't provide the same security guarantees as explicit allow or deny rules do. Managed installer is best suited where users operate as standard user, and where all software is deployed and installed by a software distribution solution such as MEMCM.
|
||||
|
||||
Users with administrator privileges, or malware running as an administrator user on the system, may be able to circumvent the intent of Windows Defender Application Control when the managed installer option is allowed.
|
||||
Users with administrator privileges, or malware running as an administrator user on the system, may be able to circumvent the intent of your WDAC policies when the managed installer option is allowed.
|
||||
|
||||
If a managed installer process runs in the context of a user with standard privileges, then it's possible that standard users or malware running as standard user may be able to circumvent the intent of Windows Defender Application Control.
|
||||
If a managed installer process runs in the context of a user with standard privileges, then it's possible that standard users or malware running as standard user may be able to circumvent the intent of your WDAC policies.
|
||||
|
||||
Some application installers may automatically run the application at the end of the installation process. If the application runs automatically, and the installer was run by a managed installer, then the managed installer's heuristic tracking and authorization will extend to all files that are created during the first run of the application. This extension could result in unintentional authorization of an executable. To avoid that, ensure that the method of application deployment that is used as a managed installer limits running applications as part of installation.
|
||||
|
||||
@ -62,9 +62,13 @@ To turn on managed installer tracking, you must:
|
||||
- Create and deploy an AppLocker policy that defines your managed installer rules and enables services enforcement for executables and DLLs.
|
||||
- Enable AppLocker's Application Identity and AppLockerFltr services.
|
||||
|
||||
> [!NOTE]
|
||||
> MEMCM will automatically configure itself as a managed installer, and enable the required AppLocker components, if you deploy one of its inbox WDAC policies. If you are configuring MEMCM as a managed installer using any other method, additional setup is required. Use the [**ManagedInstaller** cmdline switch in your ccmsetup.exe setup](/mem/configmgr/core/clients/deploy/about-client-installation-properties#managedinstaller). Or you can deploy one of the MEMCM inbox audit mode policies alongside your custom policy.
|
||||
|
||||
### Create and deploy an AppLocker policy that defines your managed installer rules and enables services enforcement for executables and DLLs
|
||||
|
||||
Currently, both the AppLocker policy creation UI in GPO Editor and the PowerShell cmdlets allow for directly specifying rules for the Managed Installer rule collection. However, you can use an XML or text editor to convert an EXE rule collection policy into a ManagedInstaller rule collection.
|
||||
The AppLocker policy creation UI in GPO Editor and the AppLocker PowerShell cmdlets can't be directly used to create rules for the Managed Installer rule collection. However, you can use an XML or text editor to convert an EXE rule collection policy into a ManagedInstaller rule collection.
|
||||
|
||||
> [!NOTE]
|
||||
> Only EXE file types can be designated as managed installers.
|
||||
|
||||
|
||||
@ -45,7 +45,7 @@ To create effective Windows Defender Application Control deny policies, it's cru
|
||||
5. If no rule exists for the file and it's not allowed based on ISG or MI, then the file is blocked implicitly.
|
||||
|
||||
> [!NOTE]
|
||||
> If your Windows Defender Application Control policy does not have an explicit rule to allow or deny a binary to run, then WDAC will make a call to the cloud to determine whether the binary is familiar and safe. However, if your policy already authorizes or denies the binary, then WDAC will not make a call to the cloud. For more details, see [How does the integration between WDAC and the Intelligent Security Graph work?](use-windows-defender-application-control-with-intelligent-security-graph.md#how-does-the-integration-between-wdac-and-the-intelligent-security-graph-work).
|
||||
> If your Windows Defender Application Control policy does not have an explicit rule to allow or deny a binary to run, then WDAC will make a call to the cloud to determine whether the binary is familiar and safe. However, if your policy already authorizes or denies the binary, then WDAC will not make a call to the cloud. For more details, see [How does the integration between WDAC and the Intelligent Security Graph work?](/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph#how-does-wdac-work-with-the-isg).
|
||||
|
||||
## Interaction with Existing Policies
|
||||
|
||||
|
||||
@ -30,14 +30,14 @@ ms.technology: windows-sec
|
||||
>[!NOTE]
|
||||
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
|
||||
|
||||
This section outlines the process to create a Windows Defender Application Control (WDAC) policy for **lightly managed devices** within an organization. Typically, organizations that are new to application control will be most successful if they start with a permissive policy like the one described in this topic. Organizations can choose to harden the policy over time to achieve a stronger overall security posture on their WDAC-managed devices as described in later topics.
|
||||
This section outlines the process to create a Windows Defender Application Control (WDAC) policy for **lightly managed devices** within an organization. Typically, organizations that are new to application control will be most successful if they start with a permissive policy like the one described in this article. Organizations can choose to harden the policy over time to achieve a stronger overall security posture on their WDAC-managed devices as described in later articles.
|
||||
|
||||
> [!NOTE]
|
||||
> Some of the Windows Defender Application Control options described in this topic are only available on Windows 10 version 1903 and above, or Windows 11. When using this topic to plan your own organization's WDAC policies, consider whether your managed clients can use all or some of these features and assess the impact for any features that may be unavailable on your clients. You may need to adapt this guidance to meet your specific organization's needs.
|
||||
|
||||
As in the [previous topic](types-of-devices.md), we'll use the example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to prevent unwanted or unauthorized applications from running on their managed devices.
|
||||
As in the [previous article](types-of-devices.md), we'll use the example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to prevent unwanted or unauthorized applications from running on their managed devices.
|
||||
|
||||
**Alice Pena** is the IT team lead tasked with the rollout of WDAC. Recognizing where Lamna is starting from, with loose application usage policies and a culture of maximum app flexibility for users, Alice knows that she'll need to take an incremental approach to application control and use different policies for different workloads.
|
||||
**Alice Pena** is the IT team lead tasked with the rollout of WDAC. Recognizing that Lamna currently has loose application usage policies and a culture of maximum app flexibility for users, Alice knows she'll need to take an incremental approach to application control and use different policies for different workloads.
|
||||
|
||||
For most users and devices, Alice wants to create an initial policy that is as relaxed as possible in order to minimize user productivity impact, while still providing security value.
|
||||
|
||||
@ -112,7 +112,7 @@ Alice follows these steps to complete this task:
|
||||
Set-RuleOption -FilePath $LamnaPolicy -Option 19 # Dynamic Code Security
|
||||
```
|
||||
|
||||
6. Add rules to allow windir and Program Files directories:
|
||||
6. Add rules to allow the Windows and Program Files directories:
|
||||
|
||||
```powershell
|
||||
$PathRules += New-CIPolicyRule -FilePathRule "%windir%\*"
|
||||
@ -133,7 +133,7 @@ Alice follows these steps to complete this task:
|
||||
ConvertFrom-CIPolicy $LamnaPolicy $WDACPolicyBin
|
||||
```
|
||||
|
||||
9. Upload your base policy XML and the associated binary to a source control solution such as [GitHub](https://github.com/) or a document management solution such as [Office 365 SharePoint](https://products.office.com/sharepoint/collaboration).
|
||||
9. Upload your base policy XML and the associated binary to a source control solution such as [GitHub](https://github.com/), or a document management solution such as [Office 365 SharePoint](https://products.office.com/sharepoint/collaboration).
|
||||
|
||||
At this point, Alice now has an initial policy that is ready to deploy in audit mode to the managed clients within Lamna.
|
||||
|
||||
@ -142,7 +142,7 @@ At this point, Alice now has an initial policy that is ready to deploy in audit
|
||||
In order to minimize user productivity impact, Alice has defined a policy that makes several trade-offs between security and user app flexibility. Some of the trade-offs include:
|
||||
|
||||
- **Users with administrative access**<br>
|
||||
By far the most impactful security trade-off, this trade-off allows the device user (or malware running with the user's privileges) to modify or remove altogether the WDAC policy applied on the device. Additionally, administrators can configure any app they wish to operate as a managed installer that would allow them to gain persistent app authorization for whatever apps or binaries they wish.
|
||||
This is by far the most impactful security trade-off and allows the device user, or malware running with the user's privileges, to modify or remove the WDAC policy on the device. Additionally, administrators can configure any app to act as a managed installer, which would allow them to gain persistent app authorization for whatever apps or binaries they wish.
|
||||
|
||||
Possible mitigations:
|
||||
- Use signed WDAC policies and UEFI BIOS access protection to prevent tampering of WDAC policies.
|
||||
@ -161,10 +161,10 @@ In order to minimize user productivity impact, Alice has defined a policy that m
|
||||
- Create and deploy signed catalog files as part of the app deployment process in order to remove the requirement for managed installer.
|
||||
- Limit who can elevate to administrator on the device.
|
||||
- **Intelligent Security Graph (ISG)**<br>
|
||||
See [security considerations with the Intelligent Security Graph](use-windows-defender-application-control-with-intelligent-security-graph.md#security-considerations-with-the-intelligent-security-graph)
|
||||
See [security considerations with the Intelligent Security Graph](/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph#security-considerations-with-the-isg-option)
|
||||
|
||||
Possible mitigations:
|
||||
- Implement policies requiring apps are managed by IT; audit existing app usage and deploy authorized apps using a software distribution solution such as Microsoft Endpoint Manager; move from ISG to managed installer or signature-based rules.
|
||||
- Implement policies requiring that apps are managed by IT; audit existing app usage and deploy authorized apps using a software distribution solution such as Microsoft Endpoint Manager; move from ISG to managed installer or signature-based rules.
|
||||
- Use a restrictive audit mode policy to audit app usage and augment vulnerability detection.
|
||||
- **Supplemental policies**<br>
|
||||
Supplemental policies are designed to relax the associated base policy. Additionally allowing unsigned policies allows any administrator process to expand the "circle-of-trust" defined by the base policy without restriction.
|
||||
|
||||
@ -10,11 +10,11 @@ ms.pagetype: security
|
||||
ms.localizationpriority: medium
|
||||
audience: ITPro
|
||||
ms.collection: M365-security-compliance
|
||||
author: dansimp
|
||||
ms.reviewer: isbrahm
|
||||
author: jgeurten
|
||||
ms.reviewer: jsuther1974
|
||||
ms.author: dansimp
|
||||
manager: dansimp
|
||||
ms.date: 06/28/2022
|
||||
ms.date: 08/29/2022
|
||||
ms.technology: windows-sec
|
||||
---
|
||||
|
||||
@ -120,6 +120,9 @@ As part of normal operations, they'll eventually install software updates, or pe
|
||||
|
||||
Windows Defender Application Control has a built-in file rule conflict logic that translates to precedence order. It will first process all explicit deny rules it finds. Then, it will process all explicit allow rules. If no deny or allow rule exists, WDAC will check for [Managed Installer EA](deployment/deploy-wdac-policies-with-memcm.md). Lastly, if none of these sets exist, WDAC will fall back on [ISG](use-windows-defender-application-control-with-intelligent-security-graph.md).
|
||||
|
||||
> [!NOTE]
|
||||
> For others to better understand the WDAC policies that have been deployed, we recommend maintaining separate ALLOW and DENY policies on Windows 10, version 1903 and later.
|
||||
|
||||
## More information about filepath rules
|
||||
|
||||
Filepath rules don't provide the same security guarantees that explicit signer rules do, since they're based on mutable access permissions. Filepath rules are best suited for environments where most users are running as standard rather than admin. Path rules are best suited to allow paths that you expect will remain admin-writeable only. You may want to avoid path rules for directories where standard users can modify ACLs on the folder.
|
||||
@ -139,7 +142,7 @@ Wildcards can be used at the beginning or end of a path rule; only one wildcard
|
||||
You can also use the following macros when the exact volume may vary: `%OSDRIVE%`, `%WINDIR%`, `%SYSTEM32%`.
|
||||
|
||||
> [!NOTE]
|
||||
> For others to better understand the WDAC policies that has been deployed, we recommend maintaining separate ALLOW and DENY policies on Windows 10, version 1903 and later.
|
||||
> When authoring WDAC policies with Microsoft Endpoint Configuration Manager (MEMCM), you can instruct MEMCM to create rules for specified files and folders. These rules **aren't** WDAC filepath rules. Rather, MEMCM performs a one-time scan of the specified files and folders and builds rules for any binaries found in those locations at the time of that scan. File changes to those specified files and folders after that scan won't be allowed unless the MEMCM policy is reapplied.
|
||||
|
||||
> [!NOTE]
|
||||
> There is currently a bug where MSIs cannot be allow listed in file path rules. MSIs must be allow listed using other rule types, for example, publisher rules or file attribute rules.
|
||||
|
||||
@ -30,31 +30,33 @@ ms.technology: windows-sec
|
||||
|
||||
Application control can be difficult to implement in organizations that don't deploy and manage applications through an IT-managed system. In such environments, users can acquire the applications they want to use for work, making it hard to build an effective application control policy.
|
||||
|
||||
Beginning with Windows 10, version 1709, you can set an option to automatically allow applications that the Microsoft Intelligent Security Graph recognizes as having known good reputation. The ISG option helps organizations begin to implement application control even when the organization has limited control over their app ecosystem. To learn more about the Microsoft Intelligent Security Graph, see the Security section in [Major services and features in Microsoft Graph](/graph/overview-major-services).
|
||||
To reduce end-user friction and helpdesk calls, you can set Windows Defender Application Control (WDAC) to automatically allow applications that Microsoft's Intelligent Security Graph (ISG) recognizes as having known good reputation. The ISG option helps organizations begin to implement application control even when the organization has limited control over their app ecosystem. To learn more about the ISG, see the Security section in [Major services and features in Microsoft Graph](/graph/overview-major-services).
|
||||
|
||||
## How does the integration between WDAC and the Intelligent Security Graph work?
|
||||
> [!WARNING]
|
||||
> Binaries that are critical to boot the system must be allowed using explicit rules in your WDAC policy. Do not rely on the ISG to authorize these files.
|
||||
>
|
||||
> The ISG option is not the recommended way to allow apps that are business critical. You should always authorize business critical apps using explicit allow rules or by installing them with a [managed installer](/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer).
|
||||
|
||||
The ISG uses the same vast security intelligence and machine learning analytics that power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having "known good," "known bad," or "unknown" reputation. When a binary runs on a system, with Windows Defender Application Control (WDAC) enabled with the ISG option, WDAC checks the file's reputation, by sending its hash and signing information to the cloud. If the ISG reports that the file has a "known good" reputation, the $KERNEL.SMARTLOCKER.ORIGINCLAIM kernel Extended Attribute (EA) is written to the file.
|
||||
## How does WDAC work with the ISG?
|
||||
|
||||
If your WDAC policy doesn't have an explicit rule to allow or deny a binary to run, then WDAC will make a call to the cloud to determine whether the binary is familiar and safe. However, if your policy already authorizes or denies the binary, then WDAC won't make a call to the cloud.
|
||||
The ISG isn't a "list" of apps. Rather, it uses the same vast security intelligence and machine learning analytics that power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having "known good", "known bad", or "unknown" reputation. This cloud-based AI is based on trillions of signals collected from Windows endpoints and other data sources, and processed every 24 hours. As a result, the decision from the cloud can change.
|
||||
|
||||
If the file with good reputation is an application installer, its reputation will pass along to any files that it writes to disk. This way, all the files needed to install and run an app inherit the positive reputation data from the installer.
|
||||
WDAC only checks the ISG for binaries that aren't explicitly allowed or denied by your policy, and that weren't installed by a managed installer. When such a binary runs on a system with WDAC enabled with the ISG option, WDAC will check the file's reputation by sending its hash and signing information to the cloud. If the ISG reports that the file has a "known good" reputation, then the file will be allowed to run. Otherwise, it will be blocked by WDAC.
|
||||
|
||||
WDAC periodically re-queries the reputation data on a file. Additionally, enterprises can specify that any cached reputation results are flushed on reboot by using the **Enabled:Invalidate EAs on Reboot** option.
|
||||
If the file with good reputation is an application installer, the installer's reputation will pass along to any files that it writes to disk. This way, all the files needed to install and run an app inherit the positive reputation data from the installer. Files authorized based on the installer's reputation will have the $KERNEL.SMARTLOCKER.ORIGINCLAIM kernel Extended Attribute (EA) written to the file.
|
||||
|
||||
>[!NOTE]
|
||||
>Admins should make sure there is a Windows Defender Application Control policy in place to allow the system to boot and run any other authorized applications that may not be classified as being known good by the Intelligent Security Graph, such as custom line-of-business (LOB) apps. Since the Intelligent Security Graph is powered by global prevalence data, internal LOB apps may not be recognized as being known good. Other mechanisms like managed installer and explicit rules will help cover internal applications. Both Microsoft Endpoint Configuration Manager and Microsoft Endpoint Manager Intune can be used to create and push a WDAC policy to your client machines.
|
||||
WDAC periodically requeries the reputation data on a file. Additionally, enterprises can specify that any cached reputation results are flushed on reboot by using the **Enabled:Invalidate EAs on Reboot** option.
|
||||
|
||||
## Configuring Intelligent Security Graph authorization for Windows Defender Application Control
|
||||
## Configuring ISG authorization for your WDAC policy
|
||||
|
||||
Setting up the ISG is easy using any management solution you wish. Configuring the Microsoft Intelligent Security Graph option involves these basic steps:
|
||||
Setting up the ISG is easy using any management solution you wish. Configuring the ISG option involves these basic steps:
|
||||
|
||||
- [Ensure that the Microsoft Intelligent Security Graph option is enabled in the WDAC policy XML](#ensure-that-the-intelligent-security-graph-option-is-enabled-in-the-wdac-policy-xml)
|
||||
- [Enable the necessary services to allow WDAC to use the Microsoft Intelligent Security Graph correctly on the client](#enable-the-necessary-services-to-allow-wdac-to-use-the-isg-correctly-on-the-client)
|
||||
- [Ensure that the **Enabled:Intelligent Security Graph authorization** option is set in the WDAC policy XML](#ensure-that-the-isg-option-is-set-in-the-wdac-policy-xml)
|
||||
- [Enable the necessary services to allow WDAC to use the ISG correctly on the client](#enable-the-necessary-services-to-allow-wdac-to-use-the-isg-correctly-on-the-client)
|
||||
|
||||
### Ensure that the Intelligent Security Graph option is enabled in the WDAC policy XML
|
||||
### Ensure that the ISG option is set in the WDAC policy XML
|
||||
|
||||
To allow apps and binaries based on the Microsoft Intelligent Security Graph, the **Enabled:Intelligent Security Graph authorization** option must be specified in the Windows Defender Application Control policy. This step can be done with the Set-RuleOption cmdlet. You should also enable the **Enabled:Invalidate EAs on Reboot** option so that ISG results are verified again after each reboot. The ISG option isn't recommended for devices that don't have regular access to the internet. The following example shows both options being set.
|
||||
To allow apps and binaries based on the Microsoft Intelligent Security Graph, the **Enabled:Intelligent Security Graph authorization** option must be specified in the WDAC policy. This step can be done with the Set-RuleOption cmdlet. You should also set the **Enabled:Invalidate EAs on Reboot** option so that ISG results are verified again after each reboot. The ISG option isn't recommended for devices that don't have regular access to the internet. The following example shows both options set.
|
||||
|
||||
```xml
|
||||
<Rules>
|
||||
@ -84,50 +86,29 @@ To allow apps and binaries based on the Microsoft Intelligent Security Graph, th
|
||||
|
||||
### Enable the necessary services to allow WDAC to use the ISG correctly on the client
|
||||
|
||||
In order for the heuristics used by the ISG to function properly, many components in Windows must be enabled. You can configure these components by running the appidtel executable in `c:\windows\system32`.
|
||||
In order for the heuristics used by the ISG to function properly, other components in Windows must be enabled. You can configure these components by running the appidtel executable in `c:\windows\system32`.
|
||||
|
||||
```console
|
||||
appidtel start
|
||||
```
|
||||
|
||||
This step isn't required for Windows Defender Application Control policies deployed over MDM, as the CSP will enable the necessary components. This step is also not required when the ISG is configured using Configuration Manager's WDAC integration.
|
||||
This step isn't required for WDAC policies deployed over MDM, as the CSP will enable the necessary components. This step is also not required when the ISG is configured using Configuration Manager's WDAC integration.
|
||||
|
||||
## Security considerations with the Intelligent Security Graph
|
||||
## Security considerations with the ISG option
|
||||
|
||||
Since the Microsoft Intelligent Security Graph is a heuristic-based mechanism, it doesn't provide the same security guarantees that explicit allow or deny rules do. It's best suited where users operate with standard user rights and where a security monitoring solution like Microsoft Defender for Endpoint is used.
|
||||
Since the ISG is a heuristic-based mechanism, it doesn't provide the same security guarantees as explicit allow or deny rules. It's best suited where users operate with standard user rights and where a security monitoring solution like Microsoft Defender for Endpoint is used.
|
||||
|
||||
Processes running with kernel privileges can circumvent WDAC by setting the ISG extended file attribute to make a binary appear to have known good reputation. Also, since the ISG option passes along reputation from application installers to the binaries they write to disk, it can over-authorize files in some cases where the installer launches the application upon completion.
|
||||
Processes running with kernel privileges can circumvent WDAC by setting the ISG extended file attribute to make a binary appear to have known good reputation.
|
||||
|
||||
## Using fsutil to query SmartLocker EA
|
||||
Customers using Windows Defender Application Control (WDAC) with Managed Installer (MI) or Intelligent Security Graph enabled can use fsutil to determine whether a file was allowed to run by one of these features. This verification can be done by querying the EAs on a file using fsutil and looking for the KERNEL.SMARTLOCKER.ORIGINCLAIM EA. The presence of this EA indicates that either MI or ISG allowed the file to run. This EA's presence can be used in conjunction with enabling the MI and ISG logging events.
|
||||
Also, since the ISG option passes along reputation from app installers to the binaries they write to disk, it can over-authorize files in some cases. For example, if the installer launches the app upon completion, any files the app writes during that first run will also be allowed.
|
||||
|
||||
#### Example
|
||||
## Known limitations with using the ISG
|
||||
|
||||
```console
|
||||
fsutil file queryEA C:\Users\Temp\Downloads\application.exe
|
||||
Since the ISG only allows binaries that are "known good", there are cases where the ISG may be unable to predict whether legitimate software is safe to run. If that happens, the software will be blocked by WDAC. In this case, you need to allow the software with a rule in your WDAC policy, deploy a catalog signed by a certificate trusted in the WDAC policy, or install the software from a WDAC managed installer. Installers or applications that dynamically create binaries at runtime, and self-updating applications, may exhibit this symptom.
|
||||
|
||||
Extended Attributes (EA) information for file C:\Users\Temp\Downloads\application.exe:
|
||||
|
||||
Ea Buffer Offset: 410
|
||||
Ea Name: $KERNEL.SMARTLOCKER.ORIGINCLAIM
|
||||
Ea Value Length: 7e
|
||||
0000: 01 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 ................
|
||||
0010: b2 ff 10 66 bc a8 47 c7 00 d9 56 9d 3d d4 20 2a ...f..G...V.=. *
|
||||
0020: 63 a3 80 e2 d8 33 8e 77 e9 5c 8d b0 d5 a7 a3 11 c....3.w.\......
|
||||
0030: 83 00 00 00 00 00 00 00 5c 00 00 00 43 00 3a 00 ........\...C.:.
|
||||
0040: 5c 00 55 00 73 00 65 00 72 00 73 00 5c 00 6a 00 \.U.s.e.r.s.\.T.
|
||||
0050: 6f 00 67 00 65 00 75 00 72 00 74 00 65 00 2e 00 e.m.p..\D.o.w.n...
|
||||
0060: 52 00 45 00 44 00 4d 00 4f 00 4e 00 44 00 5c 00 l.o.a.d.\a.p.p.l.
|
||||
0070: 44 00 6f 00 77 00 6e 00 6c 00 6f 00 61 00 64 i.c.a.t.i.o.n..e.x.e
|
||||
```
|
||||
|
||||
## Known limitations with using the Intelligent Security Graph
|
||||
|
||||
Since the ISG only allows binaries that are known good, there are cases where legitimate software may be unknown to the ISG and will be blocked by Windows Defender Application Control (WDAC). In this case, you need to allow the software with a rule in your WDAC policy, deploy a catalog signed by a certificate trusted in the WDAC policy, or install the software from a WDAC managed installer. Installers or applications that dynamically create binaries at runtime, and self-updating applications, may exhibit this symptom.
|
||||
|
||||
Packaged apps aren't supported with the Microsoft Intelligent Security Graph heuristics and will need to be separately authorized in your WDAC policy. Since packaged apps have a strong app identity and must be signed, it's straightforward to authorize these apps with your WDAC policy.
|
||||
Packaged apps aren't supported with the ISG and will need to be separately authorized in your WDAC policy. Since packaged apps have a strong app identity and must be signed, it's straightforward to [authorize packaged apps](/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control) with your WDAC policy.
|
||||
|
||||
The ISG doesn't authorize kernel mode drivers. The WDAC policy must have rules that allow the necessary drivers to run.
|
||||
|
||||
> [!NOTE]
|
||||
> A rule that explicitly denies or allows a file will take precedence over that file's reputation data. Microsoft Endpoint Manager Intune's built-in Windows Defender Application Control support includes the option to trust apps with good reputation via the Microsoft Intelligent Security Graph, but it has no option to add explicit allow or deny rules. In most circumstances, customers enforcing application control need to deploy a custom WDAC policy (which can include the Microsoft Intelligent Security Graph option if desired) using [Intune's OMA-URI functionality](deployment/deploy-windows-defender-application-control-policies-using-intune.md#deploy-wdac-policies-with-custom-oma-uri).
|
||||
> A rule that explicitly denies or allows a file will take precedence over that file's reputation data. Microsoft Endpoint Manager Intune's built-in WDAC support includes the option to trust apps with good reputation via the ISG, but it has no option to add explicit allow or deny rules. In most cases, customers using application control will need to deploy a custom WDAC policy (which can include the ISG option if desired) using [Intune's OMA-URI functionality](deployment/deploy-windows-defender-application-control-policies-using-intune.md#deploy-wdac-policies-with-custom-oma-uri).
|
||||
|
||||
@ -21,6 +21,7 @@
|
||||
"files": [
|
||||
"**/**/*.png",
|
||||
"**/**/*.jpg",
|
||||
"**/*.svg",
|
||||
"**/**/*.gif"
|
||||
],
|
||||
"exclude": [
|
||||
|
||||
@ -103,29 +103,31 @@ If you use Microsoft Endpoint Manager and have onboarded devices to Endpoint ana
|
||||
|
||||
## Prepare a pilot deployment
|
||||
|
||||
A pilot deployment is a proof of concept that rolls out an upgrade to a select number of devices in production, before deploying it broadly across the organization.
|
||||
A pilot deployment is a proof of concept that rolls out an upgrade to a select number of devices in production, before deploying it broadly across the organization.
|
||||
|
||||
At a high level, the tasks involved are:
|
||||
At a high level, the tasks involved are:
|
||||
|
||||
1. Assign a group of users or devices to receive the upgrade.
|
||||
2. Implement baseline updates.
|
||||
3. Implement operational updates.
|
||||
4. Validate the deployment process.
|
||||
5. Deploy the upgrade to devices.
|
||||
6. Test and support the pilot devices.
|
||||
7. Determine broad deployment readiness based on the results of the pilot.
|
||||
1. Assign a group of users or devices to receive the upgrade.
|
||||
2. Implement baseline updates.
|
||||
3. Implement operational updates.
|
||||
4. Validate the deployment process.
|
||||
5. Deploy the upgrade to devices.
|
||||
6. Test and support the pilot devices.
|
||||
7. Determine broad deployment readiness based on the results of the pilot.
|
||||
|
||||
## User readiness
|
||||
|
||||
Don't overlook the importance of user readiness to deliver an effective, enterprise-wide deployment of Windows 11. Windows 11 has a familiar design, but your users will see several enhancements to the overall user interface. They'll also need to adapt to changes in menus and settings pages. Therefore, consider the following tasks to prepare users and your IT support staff Windows 11:
|
||||
- Create a communications schedule to ensure that you provide the right message at the right time to the right groups of users, based on when they'll see the changes.
|
||||
- Draft concise emails that inform users of what changes they can expect to see. Offer tips on how to use or customize their experience. Include information about support and help desk options.
|
||||
- Update help desk manuals with screenshots of the new user interface, the out-of-box experience for new devices, and the upgrade experience for existing devices.
|
||||
Don't overlook the importance of user readiness to deliver an effective, enterprise-wide deployment of Windows 11. Windows 11 has a familiar design, but your users will see several enhancements to the overall user interface. They'll also need to adapt to changes in menus and settings pages. Therefore, consider the following tasks to prepare users and your IT support staff Windows 11:
|
||||
|
||||
- Create a communications schedule to ensure that you provide the right message at the right time to the right groups of users, based on when they'll see the changes.
|
||||
- Draft concise emails that inform users of what changes they can expect to see. Offer tips on how to use or customize their experience. Include information about support and help desk options.
|
||||
- Update help desk manuals with screenshots of the new user interface, the out-of-box experience for new devices, and the upgrade experience for existing devices.
|
||||
|
||||
## Learn more
|
||||
|
||||
See the [Stay current with Windows 10 and Microsoft 365 Apps](/learn/paths/m365-stay-current/) learning path on Microsoft Learn.
|
||||
- The learning path was created for Windows 10, but the basic principles and tasks outlined for the plan, prepare, and deploy phases also apply to your deployment of Windows 11.
|
||||
See the [Stay current with Windows 10 and Microsoft 365 Apps](/learn/paths/m365-stay-current/) learning path.
|
||||
|
||||
- The learning path was created for Windows 10, but the basic principles and tasks outlined for the plan, prepare, and deploy phases also apply to your deployment of Windows 11.
|
||||
|
||||
## See also
|
||||
|
||||
|
||||
Reference in New Issue
Block a user