mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-21 13:23:36 +00:00
Merge https://github.com/MicrosoftDocs/windows-itpro-docs into public
This commit is contained in:
Dani Halfin
@ -1,3 +0,0 @@
|
||||
---
|
||||
redirect_url: https://docs.microsoft.com/windows/security/identity-protection/
|
||||
---
|
||||
@ -80,7 +80,7 @@ Boolean value indicating whether AllJoyn router service (AJRouter.dll) is enable
|
||||
|
||||
Set adapter configuration
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
SyncML xmlns="SYNCML:SYNCML1.2">
|
||||
<SyncBody>
|
||||
@ -104,7 +104,7 @@ You should replace \_ALLJOYN\_DEVICE\_ID\_ with an actual device ID. Note that t
|
||||
|
||||
Get PIN data
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<SyncML xmlns="SYNCML:SYNCML1.2">
|
||||
<SyncBody>
|
||||
@ -123,7 +123,7 @@ Get PIN data
|
||||
|
||||
Get the firewall PrivateProfile
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<SyncML xmlns="SYNCML:SYNCML1.2">
|
||||
<SyncBody>
|
||||
<Get>
|
||||
|
||||
@ -19,7 +19,7 @@ This topic shows the OMA DM device description framework (DDF) for the **AppLock
|
||||
|
||||
Looking for the DDF XML files? See [CSP DDF files download](configuration-service-provider-reference.md#csp-ddf-files-download).
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE MgmtTree PUBLIC " -//OMA//DTD-DM-DDF 1.2//EN"
|
||||
"http://www.openmobilealliance.org/tech/DTD/DM_DDF-V1_2.dtd"
|
||||
|
||||
@ -17,7 +17,7 @@ ms.date: 06/26/2017
|
||||
|
||||
Here's the XSD for the AppLocker CSP.
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<?xml version="1.0"?>
|
||||
|
||||
<xs:schema attributeFormDefault="unqualified"
|
||||
|
||||
@ -97,7 +97,7 @@ manager: dansimp
|
||||
|
||||
<p>This example shows how to enable App-V on the device.</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<Replace>
|
||||
<CmdID>$CmdID$</CmdID>
|
||||
<Item>
|
||||
@ -117,7 +117,7 @@ manager: dansimp
|
||||
|
||||
<p>This example shows how to allow package scripts to run during package operations (publish, run, and unpublish). Allowing package scripts assists in package deployments (add and publish of App-V apps).</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<Replace>
|
||||
<CmdID>$CmdID$</CmdID>
|
||||
<Item>
|
||||
@ -141,7 +141,7 @@ manager: dansimp
|
||||
|
||||
<p>This SyncML example shows how to publish a package globally on an MDM enrolled device for all device users.</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<Replace>
|
||||
<CmdID>$CmdID$</CmdID>
|
||||
<Item>
|
||||
@ -183,7 +183,7 @@ manager: dansimp
|
||||
|
||||
<p>This SyncML example shows how to publish a package globally, with a policy that adds two shortcuts for the package, on an MDM enrolled device.</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<Replace>
|
||||
<CmdID>$CmdID$</CmdID>
|
||||
<Item>
|
||||
@ -277,7 +277,7 @@ manager: dansimp
|
||||
|
||||
<p>This SyncML example shows how to publish a package for a specific MDM user.</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<Replace>
|
||||
<CmdID>$CmdID$</CmdID>
|
||||
<Item>
|
||||
@ -320,7 +320,7 @@ manager: dansimp
|
||||
> [!NOTE]
|
||||
> The user connection group has the user-only package as optional in this example, which implies users without the optional package can continue to launch the global package within the same connection group.
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<Replace>
|
||||
<CmdID>$CmdID$</CmdID>
|
||||
<Item>
|
||||
@ -397,7 +397,7 @@ manager: dansimp
|
||||
|
||||
<p>This SyncML example shows how to unpublish all global packages on the device by sending an empty package and connection group list in the SyncML.</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<Replace>
|
||||
<CmdID>$CmdID$</CmdID>
|
||||
<Item>
|
||||
@ -433,7 +433,7 @@ manager: dansimp
|
||||
|
||||
<p>These SyncML examples return all global, and user-published packages on the device.</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<Get>
|
||||
<CmdID>$CmdID$</CmdID>
|
||||
<Item>
|
||||
@ -444,7 +444,7 @@ manager: dansimp
|
||||
</Get>
|
||||
```
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<Get>
|
||||
<CmdID>$CmdID$</CmdID>
|
||||
<Item>
|
||||
|
||||
@ -166,7 +166,7 @@ This MDM alert header is defined as follows:
|
||||
|
||||
KioskModeApp Add
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<SyncML xmlns='SYNCML:SYNCML1.2'>
|
||||
<SyncBody>
|
||||
<Add>
|
||||
@ -188,7 +188,7 @@ KioskModeApp Add
|
||||
|
||||
KioskModeApp Delete
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<SyncML xmlns='SYNCML:SYNCML1.2'>
|
||||
<SyncBody>
|
||||
<Delete>
|
||||
@ -206,7 +206,7 @@ KioskModeApp Delete
|
||||
|
||||
KioskModeApp Get
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<SyncML xmlns='SYNCML:SYNCML1.2'>
|
||||
<SyncBody>
|
||||
<Get>
|
||||
@ -224,7 +224,7 @@ KioskModeApp Get
|
||||
|
||||
KioskModeApp Replace
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<SyncML xmlns='SYNCML:SYNCML1.2'>
|
||||
<SyncBody>
|
||||
<Replace>
|
||||
@ -246,7 +246,7 @@ KioskModeApp Replace
|
||||
|
||||
## AssignedAccessConfiguration XSD
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<xs:schema
|
||||
elementFormDefault="qualified"
|
||||
@ -390,7 +390,7 @@ KioskModeApp Replace
|
||||
|
||||
## Example AssignedAccessConfiguration XML
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<?xml version="1.0" encoding="utf-8" ?>
|
||||
<AssignedAccessConfiguration xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config">
|
||||
<Profiles>
|
||||
@ -698,7 +698,7 @@ Example of the Delete command.
|
||||
|
||||
## StatusConfiguration XSD
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<xs:schema
|
||||
elementFormDefault="qualified"
|
||||
@ -731,7 +731,7 @@ Example of the Delete command.
|
||||
|
||||
StatusConfiguration Add OnWithAlerts
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<SyncML xmlns='SYNCML:SYNCML1.2'>
|
||||
<SyncBody>
|
||||
<Add>
|
||||
@ -760,7 +760,7 @@ StatusConfiguration Add OnWithAlerts
|
||||
|
||||
|
||||
StatusConfiguration Delete
|
||||
``` syntax
|
||||
```xml
|
||||
<SyncML xmlns='SYNCML:SYNCML1.2'>
|
||||
<SyncBody>
|
||||
<Delete>
|
||||
@ -778,7 +778,7 @@ StatusConfiguration Delete
|
||||
|
||||
StatusConfiguration Get
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<SyncML xmlns='SYNCML:SYNCML1.2'>
|
||||
<SyncBody>
|
||||
<Get>
|
||||
@ -826,7 +826,7 @@ StatusConfiguration Replace On
|
||||
## Status example
|
||||
|
||||
Status Get
|
||||
``` syntax
|
||||
```xml
|
||||
<SyncML xmlns='SYNCML:SYNCML1.2'>
|
||||
<SyncBody>
|
||||
<Get>
|
||||
@ -844,7 +844,7 @@ Status Get
|
||||
|
||||
## ShellLauncherConfiguration XSD
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<xs:schema
|
||||
elementFormDefault="qualified"
|
||||
@ -1195,7 +1195,7 @@ ShellLauncherConfiguration Get
|
||||
|
||||
This example configures the following apps: Skype, Learning, Feedback Hub, and Calibration, for first line workers. Use this XML in a provisioning package using Windows Configuration Designer. For instructions, see [Configure HoloLens using a provisioning package](https://docs.microsoft.com/hololens/hololens-provisioning).
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<?xml version="1.0" encoding="utf-8" ?>
|
||||
<!--
|
||||
This is a sample Assigned Access XML file. The Profile specifies which apps are allowed
|
||||
|
||||
@ -24,7 +24,7 @@ You can download the DDF files from the links below:
|
||||
|
||||
The XML below is for Windows 10, version 1803.
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE MgmtTree PUBLIC " -//OMA//DTD-DM-DDF 1.2//EN"
|
||||
"http://www.openmobilealliance.org/tech/DTD/DM_DDF-V1_2.dtd"
|
||||
|
||||
@ -66,7 +66,7 @@ The following diagram shows the BitLocker configuration service provider in tree
|
||||
|
||||
<p style="margin-left: 20px">If you want to disable this policy use the following SyncML:</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<SyncML>
|
||||
<SyncBody>
|
||||
<Replace>
|
||||
@ -116,7 +116,7 @@ The following diagram shows the BitLocker configuration service provider in tree
|
||||
|
||||
<p style="margin-left: 20px">If you want to disable this policy use the following SyncML:</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<SyncML>
|
||||
<SyncBody>
|
||||
<Replace>
|
||||
@ -178,7 +178,7 @@ The following diagram shows the BitLocker configuration service provider in tree
|
||||
|
||||
<p style="margin-left: 20px"> Sample value for this node to enable this policy and set the encryption methods is:</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<enabled/><data id="EncryptionMethodWithXtsOsDropDown_Name" value="xx"/><data id="EncryptionMethodWithXtsFdvDropDown_Name" value="xx"/><data id="EncryptionMethodWithXtsRdvDropDown_Name" value="xx"/>
|
||||
```
|
||||
|
||||
@ -198,7 +198,7 @@ The following diagram shows the BitLocker configuration service provider in tree
|
||||
|
||||
<p style="margin-left: 20px"> If you want to disable this policy use the following SyncML:</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<Replace>
|
||||
<CmdID>$CmdID$</CmdID>
|
||||
<Item>
|
||||
@ -269,7 +269,7 @@ The following diagram shows the BitLocker configuration service provider in tree
|
||||
|
||||
<p style="margin-left: 20px">Sample value for this node to enable this policy is:</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<enabled/><data id="ConfigureNonTPMStartupKeyUsage_Name" value="xx"/><data id="ConfigureTPMStartupKeyUsageDropDown_Name" value="yy"/><data id="ConfigurePINUsageDropDown_Name" value="yy"/><data id="ConfigureTPMPINKeyUsageDropDown_Name" value="yy"/><data id="ConfigureTPMUsageDropDown_Name" value="yy"/>
|
||||
```
|
||||
<p style="margin-left: 20px">Data id:</p>
|
||||
@ -296,7 +296,7 @@ The following diagram shows the BitLocker configuration service provider in tree
|
||||
|
||||
<p style="margin-left: 20px">Disabling the policy will let the system choose the default behaviors. If you want to disable this policy use the following SyncML:</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<Replace>
|
||||
<CmdID>$CmdID$</CmdID>
|
||||
<Item>
|
||||
@ -358,13 +358,13 @@ The following diagram shows the BitLocker configuration service provider in tree
|
||||
|
||||
<p style="margin-left: 20px">Sample value for this node to enable this policy is:</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<enabled/><data id="MinPINLength" value="xx"/>
|
||||
```
|
||||
|
||||
<p style="margin-left: 20px">Disabling the policy will let the system choose the default behaviors. If you want to disable this policy use the following SyncML:</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<Replace>
|
||||
<CmdID>$CmdID$</CmdID>
|
||||
<Item>
|
||||
@ -425,7 +425,7 @@ The following diagram shows the BitLocker configuration service provider in tree
|
||||
|
||||
<p style="margin-left: 20px">Sample value for this node to enable this policy is:</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<enabled/><data id="PrebootRecoveryInfoDropDown_Name" value="xx"/><data id="RecoveryMessage_Input" value="yy"/><data id="RecoveryUrl_Input" value="zz"/>
|
||||
```
|
||||
<p style="margin-left: 20px">The possible values for 'xx' are:</p>
|
||||
@ -442,7 +442,7 @@ The following diagram shows the BitLocker configuration service provider in tree
|
||||
|
||||
<p style="margin-left: 20px">Disabling the policy will let the system choose the default behaviors. If you want to disable this policy use the following SyncML:</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<Replace>
|
||||
<CmdID>$CmdID$</CmdID>
|
||||
<Item>
|
||||
@ -515,7 +515,7 @@ The following diagram shows the BitLocker configuration service provider in tree
|
||||
|
||||
<p style="margin-left: 20px">Sample value for this node to enable this policy is:</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<enabled/><data id="OSAllowDRA_Name" value="xx"/><data id="OSRecoveryPasswordUsageDropDown_Name" value="yy"/><data id="OSRecoveryKeyUsageDropDown_Name" value="yy"/><data id="OSHideRecoveryPage_Name" value="xx"/><data id="OSActiveDirectoryBackup_Name" value="xx"/><data id="OSActiveDirectoryBackupDropDown_Name" value="zz"/><data id="OSRequireActiveDirectoryBackup_Name" value="xx"/>
|
||||
```
|
||||
|
||||
@ -542,7 +542,7 @@ The following diagram shows the BitLocker configuration service provider in tree
|
||||
|
||||
<p style="margin-left: 20px">Disabling the policy will let the system choose the default behaviors. If you want to disable this policy use the following SyncML:</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<Replace>
|
||||
<CmdID>$CmdID$</CmdID>
|
||||
<Item>
|
||||
@ -614,7 +614,7 @@ The following diagram shows the BitLocker configuration service provider in tree
|
||||
|
||||
<p style="margin-left: 20px">Sample value for this node to enable this policy is:</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<enabled/><data id="FDVAllowDRA_Name" value="xx"/><data id="FDVRecoveryPasswordUsageDropDown_Name" value="yy"/><data id="FDVRecoveryKeyUsageDropDown_Name" value="yy"/><data id="FDVHideRecoveryPage_Name" value="xx"/><data id="FDVActiveDirectoryBackup_Name" value="xx"/><data id="FDVActiveDirectoryBackupDropDown_Name" value="zz"/><data id="FDVRequireActiveDirectoryBackup_Name" value="xx"/>
|
||||
```
|
||||
|
||||
@ -640,7 +640,7 @@ The following diagram shows the BitLocker configuration service provider in tree
|
||||
|
||||
<p style="margin-left: 20px">Disabling the policy will let the system choose the default behaviors. If you want to disable this policy use the following SyncML:</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<Replace>
|
||||
<CmdID>$CmdID$</CmdID>
|
||||
<Item>
|
||||
@ -696,13 +696,13 @@ The following diagram shows the BitLocker configuration service provider in tree
|
||||
|
||||
<p style="margin-left: 20px">Sample value for this node to enable this policy is:</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<enabled/>
|
||||
```
|
||||
|
||||
<p style="margin-left: 20px">If you disable or do not configure this setting, all fixed data drives on the computer will be mounted with read and write access. If you want to disable this policy use the following SyncML:</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<Replace>
|
||||
<CmdID>$CmdID$</CmdID>
|
||||
<Item>
|
||||
@ -764,7 +764,7 @@ The following diagram shows the BitLocker configuration service provider in tree
|
||||
|
||||
<p style="margin-left: 20px">Sample value for this node to enable this policy is:</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<enabled/><data id="RDVCrossOrg" value="xx"/>
|
||||
```
|
||||
|
||||
@ -776,7 +776,7 @@ The following diagram shows the BitLocker configuration service provider in tree
|
||||
|
||||
<p style="margin-left: 20px">Disabling the policy will let the system choose the default behaviors. If you want to disable this policy use the following SyncML:</p>
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<Replace>
|
||||
<CmdID>$CmdID$</CmdID>
|
||||
<Item>
|
||||
@ -827,7 +827,7 @@ The following diagram shows the BitLocker configuration service provider in tree
|
||||
- 0 – Disables the warning prompt. Starting in Windows 10, version 1803, the value 0 can only be set for Azure Active Directory joined devices. Windows will attempt to silently enable BitLocker for value 0.
|
||||
- 1 (default) – Warning prompt allowed.
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<Replace>
|
||||
<CmdID>110</CmdID>
|
||||
<Item>
|
||||
@ -869,7 +869,7 @@ The expected values for this policy are:
|
||||
|
||||
If you want to disable this policy use the following SyncML:
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<Replace>
|
||||
<CmdID>111</CmdID>
|
||||
<Item>
|
||||
@ -887,7 +887,7 @@ If you want to disable this policy use the following SyncML:
|
||||
|
||||
The following example is provided to show proper format and should not be taken as a recommendation.
|
||||
|
||||
``` syntax
|
||||
```xml
|
||||
<SyncML xmlns="SYNCML:SYNCML1.2">
|
||||
<SyncBody>
|
||||
|
||||
|
||||
@ -110,7 +110,7 @@ The following XML sample works for **Shell Launcher v1**:
|
||||
</ShellLauncherConfiguration>
|
||||
```
|
||||
|
||||
For **Shell Launcher v2**, you will use a different schema reference and a different app type for `Shell`, as shown in the following example.
|
||||
For **Shell Launcher v2**, you can use UWP app type for `Shell` by specifying the v2 namespace, and use `v2:AppType` to specify the type, as shown in the following example. If `v2:AppType` is not specified, it implies the shell is Win32 app.
|
||||
|
||||
```
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
@ -138,7 +138,7 @@ In your MDM service, you can create a [custom OMA-URI setting](https://docs.micr
|
||||
|
||||
The OMA-URI path is `./Device/Vendor/MSFT/AssignedAccess/ShellLauncher`.
|
||||
|
||||
For the value, you can select data type `String` and paste the desired configuration file content into the value box. If you wish to upload the xml instead of pasting the content, choose data type `String (XML file)` instead.
|
||||
For the value, you can select data type `String` and paste the desired configuration file content into the value box. If you wish to upload the xml instead of pasting the content, choose data type `String (XML file)`.
|
||||
|
||||
|
||||
|
||||
@ -282,3 +282,27 @@ $IsShellLauncherEnabled = $ShellLauncherClass.IsEnabled()
|
||||
|
||||
"`nEnabled is set to " + $IsShellLauncherEnabled.Enabled
|
||||
```
|
||||
|
||||
## default action, custom action, exit code
|
||||
Shell launcher defines 4 actions to handle app exits, you can customize shell launcher and use these actions based on different exit code.
|
||||
|
||||
Value|Description
|
||||
--- | ---
|
||||
0|Restart the shell
|
||||
1|Restart the device
|
||||
2|Shut down the device
|
||||
3|Do nothing
|
||||
|
||||
These action can be used as default action, or can be mapped to a specific exit code. Refer to [Shell Launcher](https://docs.microsoft.com/en-us/windows-hardware/customize/enterprise/wesl-usersettingsetcustomshell) to see how these codes with Shell Launcher WMI.
|
||||
|
||||
To configure these action with Shell Launcher CSP, use below syntax in the shell launcher configuration xml. You can specify at most 4 custom actions mapping to 4 exit codes, and one default action for all other exit codes. When app exits and if the exit code is not found in the custom action mapping, or there is no default action defined, it will be no-op, i.e. nothing happens. So it's recommeded to at least define DefaultAction. [Get XML examples for different Shell Launcher v2 configurations.](https://github.com/Microsoft/Windows-iotcore-samples/tree/develop/Samples/ShellLauncherV2)
|
||||
``` xml
|
||||
<ReturnCodeActions>
|
||||
<ReturnCodeAction ReturnCode="0" Action="RestartShell"/>
|
||||
<ReturnCodeAction ReturnCode="-1" Action="RestartDevice"/>
|
||||
<ReturnCodeAction ReturnCode="255" Action="ShutdownDevice"/>
|
||||
<ReturnCodeAction ReturnCode="1" Action="DoNothing"/>
|
||||
</ReturnCodeActions>
|
||||
<DefaultAction Action="RestartDevice"/>
|
||||
|
||||
```
|
||||
|
||||
@ -6,7 +6,7 @@ ms.prod: w10
|
||||
ms.mktglfcycl: plan
|
||||
ms.localizationpriority: medium
|
||||
ms.sitesec: library
|
||||
author:
|
||||
author: greg-lindsay
|
||||
ms.date: 08/18/2017
|
||||
ms.reviewer:
|
||||
manager: laurawi
|
||||
|
||||
@ -1,3 +0,0 @@
|
||||
---
|
||||
redirect_url: /windows/deployment/update/windows-analytics-FAQ-troubleshooting
|
||||
---
|
||||
@ -1,9 +0,0 @@
|
||||
---
|
||||
title: Upgrade Readiness release notes (Windows 10)
|
||||
ms.reviewer:
|
||||
manager: laurawi
|
||||
ms.author: greglin
|
||||
author: greg-lindsay
|
||||
description: Provides tips and limitations about Upgrade Readiness.
|
||||
redirect_url: https://docs.microsoft.com/windows/deployment/upgrade/upgrade-readiness-requirements#important-information-about-this-release
|
||||
---
|
||||
@ -42,7 +42,7 @@ Deployment instructions are provided for the following scenarios:
|
||||
### Scenario 2
|
||||
- The Hyper-V host and the VM are both running Windows 10, version 1803 or later.
|
||||
|
||||
[Inherited Activation](https://docs.microsoft.com/windows/deployment/windows-10-subscription-activation#inherited-activation) is enabled. All VMs created by a user with a Windows 10 E3 or E5 license are automatically activated independent of whether a user signs in iwth a local account or using an Azure Active Directory account.
|
||||
[Inherited Activation](https://docs.microsoft.com/windows/deployment/windows-10-subscription-activation#inherited-activation) is enabled. All VMs created by a user with a Windows 10 E3 or E5 license are automatically activated independent of whether a user signs in with a local account or using an Azure Active Directory account.
|
||||
|
||||
### Scenario 3
|
||||
- The VM is running Windows 10, version 1703 or 1709, or the hoster is not an authorized [QMTH](https://www.microsoft.com/en-us/CloudandHosting/licensing_sca.aspx) partner.
|
||||
|
||||
@ -457,6 +457,10 @@ If you [turn off traffic for these endpoints](manage-connections-from-windows-op
|
||||
| svchost | HTTPS | *.update.microsoft.com |
|
||||
| svchost | HTTPS | *.delivery.mp.microsoft.com |
|
||||
|
||||
These are dependent on enabling:
|
||||
- [Device authentication](manage-windows-1809-endpoints.md#device-authentication)
|
||||
- [Microsoft account](manage-windows-1809-endpoints.md#microsoft-account)
|
||||
|
||||
The following endpoint is used for content regulation.
|
||||
If you [turn off traffic for this endpoint](manage-connections-from-windows-operating-system-components-to-microsoft-services.md#bkmk-wu), the Windows Update Agent will be unable to contact the endpoint and fallback behavior will be used. This may result in content being either incorrectly downloaded or not downloaded at all.
|
||||
|
||||
|
||||
@ -334,7 +334,7 @@ write-host "There are no issuance policies which are not mapped to groups"
|
||||
|
||||
Save the script file as set-IssuancePolicyToGroupLink.ps1.
|
||||
|
||||
``` syntax
|
||||
```powershell
|
||||
#######################################
|
||||
## Parameters to be defined ##
|
||||
## by the user ##
|
||||
|
||||
@ -85,7 +85,7 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
|
||||
| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. Azure MFA services provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
|
||||
| B | After receiving a ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
|
||||
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID to the application, which represents the end of user key registration. |
|
||||
| D | The certificate request portion of provisioning begins after the application receives a successful response from key registration. The application creates a PKCS#10 certificate request. The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br> After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentailsLink for a list of registered public keys. |
|
||||
| D | The certificate request portion of provisioning begins after the application receives a successful response from key registration. The application creates a PKCS#10 certificate request. The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br> After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentialsLink for a list of registered public keys. |
|
||||
| E | The registration authority validates the public key in the certificate request matches a registered key for the user.<br> If the public key in the certificate is not found in the list of registered public keys, certificate enrollment is deferred until Phase F completes. The application is informed of the deferment and exits to the user's desktop. The automatic certificate enrollment client triggers the Azure AD Web Account Manager plug-in to retry the certificate enrollment at 24, 85, 145, 205, 265, and 480 minutes after phase C successfully completes. The user must remain signed in for automatic certificate enrollment to trigger certificate enrollment. If the user signs out, automatic certificate enrollment is triggered approximately 30 minutes after the user's next sign in.<br> After validating the public key, the registration authority signs the certificate request using its enrollment agent certificate. |
|
||||
| G | The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application. |
|
||||
| H | The application receives the newly issued certificate and installs the it into the Personal store of the user. This signals the end of provisioning. |
|
||||
@ -105,7 +105,7 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
|
||||
| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. Azure MFA services provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
|
||||
| B | After receiving a ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
|
||||
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID and a key receipt to the application, which represents the end of user key registration. |
|
||||
| D | The certificate request portion of provisioning begins after the application receives a successful response from key registration. The application creates a PKCS#10 certificate request. The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the key receipt and certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br> After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentailsLink for a list of registered public keys. |
|
||||
| D | The certificate request portion of provisioning begins after the application receives a successful response from key registration. The application creates a PKCS#10 certificate request. The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the key receipt and certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br> After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentialsLink for a list of registered public keys. |
|
||||
| E | The registration authority validates the public key in the certificate request matches a registered key for the user.<br> If the public key in the certificate is not found in the list of registered public keys, it then validates the key receipt to confirm the key was securely registered with Azure.<br>After validating the key receipt or public key, the registration authority signs the certificate request using its enrollment agent certificate. |
|
||||
| F | The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application. |
|
||||
| G | The application receives the newly issued certificate and installs the it into the Personal store of the user. This signals the end of provisioning. |
|
||||
@ -124,7 +124,7 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
|
||||
| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br> In a federated environment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. Azure MFA services (or a third party MFA service) provides the second factor of authentication.<br> The on-premises STS server issues a enterprise token on successful MFA. The application sends the token to Azure Active Directory.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
|
||||
| B | After receiving a ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
|
||||
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID and a key receipt to the application, which represents the end of user key registration. |
|
||||
| D | The certificate request portion of provisioning begins after the application receives a successful response from key registration. The application creates a PKCS#10 certificate request. The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the key receipt and certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br> After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentailsLink for a list of registered public keys. |
|
||||
| D | The certificate request portion of provisioning begins after the application receives a successful response from key registration. The application creates a PKCS#10 certificate request. The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the key receipt and certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br> After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentialsLink for a list of registered public keys. |
|
||||
| E | The registration authority validates the public key in the certificate request matches a registered key for the user.<br> If the public key in the certificate is not found in the list of registered public keys, it then validates the key receipt to confirm the key was securely registered with Azure.<br>After validating the key receipt or public key, the registration authority signs the certificate request using its enrollment agent certificate. |
|
||||
| F | The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application. |
|
||||
| G | The application receives the newly issued certificate and installs the it into the Personal store of the user. This signals the end of provisioning. |
|
||||
@ -152,7 +152,7 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
|
||||
|A| The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Enterprise Device Registration Service (EDRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br> In an on-premises deployment, the plug-in sends the token request to the on-premises STS, such as Active Directory Federation Services. The on-premises STS authenticates the user and determines if the user should perform another factor of authentication.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. Azure MFA server (or a third party MFA service) provides the second factor of authentication.<br> The on-premises STS server issues a enterprise DRS token on successful MFA.|
|
||||
| B| After receiving a EDRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv).|
|
||||
|C | The application sends the EDRS token, ukpub, attestation data, and device information to the Enterprise DRS for user key registration. Enterprise DRS validates the MFA claim remains current. On successful validation, the Enterprise DRS locates the user's object in Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. The Enterprise DRS returns a key ID to the application, which represents the end of user key registration.|
|
||||
|D | The certificate request portion of provisioning begins after the application receives a successful response from key registration. The application creates a PKCS#10 certificate request. The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br> After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentailsLink for a list of registered public keys.|
|
||||
|D | The certificate request portion of provisioning begins after the application receives a successful response from key registration. The application creates a PKCS#10 certificate request. The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br> After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentialsLink for a list of registered public keys.|
|
||||
|E | The registration authority validates the public key in the certificate request matches a registered key for the user.<br> After validating the public key, the registration authority signs the certificate request using its enrollment agent certificate.|
|
||||
|F |The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application.|
|
||||
|G | The application receives the newly issued certificate and installs it into the Personal store of the user. This signals the end of provisioning.|
|
||||
|
||||
@ -29,6 +29,9 @@ Your environment is federated and you are ready to configure device registration
|
||||
> [!IMPORTANT]
|
||||
> If your environment is not federated, review the [New Installation baseline](hello-hybrid-cert-new-install.md) section of this deployment document to learn how to federate your environment for your Windows Hello for Business deployment.
|
||||
|
||||
>[!TIP]
|
||||
>Refer to the [Tutorial: Configure hybrid Azure Active Directory join for federated domains](https://docs.microsoft.com/azure/active-directory/devices/hybrid-azuread-join-federated-domains) to learn more about setting up Azure Active Directory Connect for a simplified join flow for Azure AD device registration.
|
||||
|
||||
Use this three-phased approach for configuring device registration.
|
||||
1. [Configure devices to register in Azure](#configure-azure-for-device-registration)
|
||||
2. [Synchronize devices to on-premises Active Directory](#configure-active-directory-to-support-azure-device-synchronization)
|
||||
@ -42,6 +45,9 @@ Use this three-phased approach for configuring device registration.
|
||||
>
|
||||
> You can learn about this and more by reading [Introduction to Device Management in Azure Active Directory.](https://docs.microsoft.com/azure/active-directory/device-management-introduction)
|
||||
|
||||
>[!IMPORTANT]
|
||||
> To use hybrid identity with Azure Active Directory and device WriteBack features, you must use the built-in GUI with the [latest updates for ADConnect](https://www.microsoft.com/download/details.aspx?id=47594).
|
||||
|
||||
## Configure Azure for Device Registration
|
||||
Begin configuring device registration to support Hybrid Windows Hello for Business by configuring device registration capabilities in Azure AD.
|
||||
|
||||
@ -66,7 +72,7 @@ To locate the schema master role holder, open and command prompt and type:
|
||||
|
||||
|
||||
|
||||
The command should return the name of the domain controller where you need to adprep.exe. Update the schema locally on the domain controller hosting the Schema master role.
|
||||
The command should return the name of the domain controller where you need to run adprep.exe. Update the schema locally on the domain controller hosting the Schema master role.
|
||||
|
||||
#### Updating the Schema
|
||||
|
||||
@ -130,7 +136,6 @@ If your AD FS farm is not already configured for Device Authentication (you can
|
||||
|
||||
The above PSH creates the following objects:
|
||||
|
||||
|
||||
- RegisteredDevices container under the AD domain partition
|
||||
- Device Registration Service container and object under Configuration --> Services --> Device Registration Configuration
|
||||
- Device Registration Service DKM container and object under Configuration --> Services --> Device Registration Configuration
|
||||
@ -278,7 +283,8 @@ The definition helps you to verify whether the values are present or if you need
|
||||
|
||||
**`http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid`** - This claim must contain the Uniform Resource Identifier (URI) of any of the verified domain names that connect with the on-premises federation service (AD FS or 3rd party) issuing the token. In AD FS, you can add issuance transform rules that look like the ones below in that specific order after the ones above. Please note that one rule to explicitly issue the rule for users is necessary. In the rules below, a first rule identifying user vs. computer authentication is added.
|
||||
|
||||
@RuleName = "Issue account type with the value User when its not a computer"
|
||||
@RuleName = "Issue account type with the value User when it is not a computer"
|
||||
|
||||
NOT EXISTS(
|
||||
[
|
||||
Type == "http://schemas.microsoft.com/ws/2012/01/accounttype",
|
||||
@ -473,6 +479,7 @@ The following script helps you with the creation of the issuance transform rules
|
||||
|
||||
Set-AdfsRelyingPartyTrust -TargetIdentifier urn:federation:MicrosoftOnline -IssuanceTransformRules $crSet.ClaimRulesString
|
||||
|
||||
|
||||
#### Remarks
|
||||
|
||||
- This script appends the rules to the existing rules. Do not run the script twice because the set of rules would be added twice. Make sure that no corresponding rules exist for these claims (under the corresponding conditions) before running the script again.
|
||||
@ -512,7 +519,6 @@ For your reference, below is a comprehensive list of the AD DS devices, containe
|
||||
> [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md)
|
||||
|
||||
<br>
|
||||
|
||||
<hr>
|
||||
|
||||
## Follow the Windows Hello for Business hybrid certificate trust deployment guide
|
||||
|
||||
@ -22,6 +22,10 @@ The ideal for BitLocker management is to eliminate the need for IT admins to set
|
||||
|
||||
Though much Windows BitLocker [documentation](bitlocker-overview.md) has been published, customers frequently ask for recommendations and pointers to specific, task-oriented documentation that is both easy to digest and focused on how to deploy and manage BitLocker. This article links to relevant documentation, products, and services to help answer this and other related frequently-asked questions, and also provides BitLocker recommendations for different types of computers.
|
||||
|
||||
|
||||
>[!IMPORTANT]
|
||||
> Microsoft BitLocker Administration and Monitoring (MBAM) capabilities will be offered from [SCCM in on-prem scenarios](https://docs.microsoft.com/microsoft-desktop-optimization-pack/mbam-v25/viewing-mbam-25-reports-for-the-configuration-manager-integration-topology) in the future.
|
||||
|
||||
## Managing domain-joined computers and moving to cloud
|
||||
|
||||
Companies that image their own computers using Microsoft System Center 2012 Configuration Manager SP1 (SCCM) or later can use an existing task sequence to [pre-provision BitLocker](https://technet.microsoft.com/library/hh846237.aspx#BKMK_PreProvisionBitLocker) encryption while in Windows Preinstallation Environment (WinPE) and can then [enable protection](https://technet.microsoft.com/library/hh846237.aspx#BKMK_EnableBitLocker). This can help ensure that computers are encrypted from the start, even before users receive them. As part of the imaging process, a company could also decide to use SCCM to pre-set any desired [BitLocker Group Policy](https://technet.microsoft.com/library/ee706521(v=ws.10).aspx).
|
||||
@ -132,8 +136,10 @@ PS C:\> Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 -UsedSpace
|
||||
|
||||
<br />
|
||||
|
||||
|
||||
|
||||
<a id="powershell"></a>
|
||||
**Powershell**
|
||||
# **PowerShell**
|
||||
|
||||
[BitLocker cmdlets for Windows PowerShell](bitlocker-use-bitlocker-drive-encryption-tools-to-manage-bitlocker.md#bitlocker-cmdlets-for-windows-powershell)
|
||||
|
||||
|
||||
@ -61,7 +61,7 @@ To lower down your threat and vulnerability exposure:
|
||||
> There are two types of recommendations:
|
||||
> - <i>Security update</i> which refers to recommendations that require a package installation
|
||||
> - <i>Configuration</i> change which refers to recommendations that require a registry or GPO modification
|
||||
> Always prioritize recommendations that are associated with ongoing threats. These recommendations are marked with the threat insight  icon.
|
||||
> Always prioritize recommendations that are associated with ongoing threats. These recommendations are marked with the threat insight  icon or the possible alert activity [possible alert activity](images/tvm_alert_icon.png) icon.
|
||||
|
||||
2. In the **Security recommendations** page, you will see the description of what needs to be done and why. It shows the vulnerability details, such as the associated exploits affecting what machines and its business impact. Click **Open software page** option from the flyout menu. 
|
||||
|
||||
|
||||
@ -185,34 +185,34 @@ The following table describes how the wildcards can be used and provides some ex
|
||||
<table>
|
||||
<tr>
|
||||
<th>Wildcard</th>
|
||||
<th>Use in file and file extension exclusions</th>
|
||||
<th>Use in file name and file extension exclusions</th>
|
||||
<th>Use in folder exclusions</th>
|
||||
<th>Example use</th>
|
||||
<th>Example matches></th>
|
||||
<th>Example matches</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b><em></b> (asterisk)</td>
|
||||
<td><b>*</b> (asterisk)</td>
|
||||
<td>Replaces any number of characters. <br />Only applies to files in the last folder defined in the argument. </td>
|
||||
<td>Replaces a single folder. <br />Use multiple <b></em></b> with folder slashes <b>\</b> to indicate multiple, nested folders. </br>After matching to the number of wilcarded and named folders, all subfolders will also be included.</td>
|
||||
<td>Replaces a single folder. <br />Use multiple <b>*</b> with folder slashes <b>\</b> to indicate multiple, nested folders. </br>After matching the number of wilcarded and named folders, all subfolders will also be included.</td>
|
||||
<td>
|
||||
<ol>
|
||||
<li>C:\MyData\<b><em></b>.txt</li>
|
||||
<li>C:\somepath\<b></em></b>\Data</li>
|
||||
<li>C:\Serv\<b><em></b>\<b></em></b>\Backup
|
||||
<li>C:\MyData\<b>*</b>.txt</li>
|
||||
<li>C:\somepath\<b>*</b>\Data</li>
|
||||
<li>C:\Serv\<b>*</b>\<b>*</b>\Backup
|
||||
</ol>
|
||||
</td>
|
||||
<td>
|
||||
<ol>
|
||||
<li><i>C:\MyData\<b>notes</b>.txt</i></li>
|
||||
<li>C:\MyData\<b>notes</b>.txt</li>
|
||||
<li>Any file in:
|
||||
<ul>
|
||||
<li><i>C:\somepath\<b>Archives</b>\Data</i> and its subfolders</li>
|
||||
<li><i>C:\somepath\<b>Authorized</b>\Data</i> and its subfolders</li>
|
||||
<li>C:\somepath\<b>Archives</b>\Data and its subfolders</li>
|
||||
<li>C:\somepath\<b>Authorized</b>\Data and its subfolders</li>
|
||||
</ul>
|
||||
<li>Any file in:
|
||||
<ul>
|
||||
<li><i>C:\Serv\<b>Primary</b>\<b>Denied</b>\Backup</i> and its subfolders</li>
|
||||
<li><i>C:\Serv\<b>Secondary</b>\<b>Allowed</b>\Backup</i> and its subfolders</li>
|
||||
<li>C:\Serv\<b>Primary</b>\<b>Denied</b>\Backup and its subfolders</li>
|
||||
<li>C:\Serv\<b>Secondary</b>\<b>Allowed</b>\Backup and its subfolders</li>
|
||||
</ul>
|
||||
</ol>
|
||||
</td>
|
||||
@ -227,7 +227,7 @@ The following table describes how the wildcards can be used and provides some ex
|
||||
</td>
|
||||
<td>
|
||||
Replaces a single character in a folder name. </br>
|
||||
After matching to the number of wilcarded and named folders, all subfolders will also be included.
|
||||
After matching the number of wilcarded and named folders, all subfolders will also be included.
|
||||
</td>
|
||||
<td>
|
||||
<ol>
|
||||
@ -238,9 +238,9 @@ The following table describes how the wildcards can be used and provides some ex
|
||||
</td>
|
||||
<td>
|
||||
<ol>
|
||||
<li><i>C:\MyData\my<b>1</b>.zip</i></li>
|
||||
<li>Any file in <i>C:\somepath\<b>P</b>\Data</i> and its subfolders</li>
|
||||
<li>Any file in <i>C:\somepath\test0<b>1</b>\Data</i> and its subfolders</li>
|
||||
<li>C:\MyData\my<b>1</b>.zip</li>
|
||||
<li>Any file in C:\somepath\<b>P</b>\Data and its subfolders</li>
|
||||
<li>Any file in C:\somepath\test0<b>1</b>\Data and its subfolders</li>
|
||||
</ol>
|
||||
</td>
|
||||
</tr>
|
||||
@ -255,7 +255,7 @@ The following table describes how the wildcards can be used and provides some ex
|
||||
</td>
|
||||
<td>
|
||||
<ol>
|
||||
<li><i><b>C:\ProgramData</b>\CustomLogFiles\Folder1\file1.txt</i></li>
|
||||
<li><b>C:\ProgramData</b>\CustomLogFiles\Folder1\file1.txt</li>
|
||||
</ol>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
@ -70,6 +70,7 @@ You can set several rule options within a WDAC policy. Table 2 describes each ru
|
||||
| **14 Enabled:Intelligent Security Graph Authorization** | Use this option to automatically allow applications with "known good" reputation as defined by Microsoft’s Intelligent Security Graph (ISG). |
|
||||
| **15 Enabled:Invalidate EAs on Reboot** | When the Intelligent Security Graph option (14) is used, WDAC sets an extended file attribute that indicates that the file was authorized to run. This option will cause WDAC to periodically re-validate the reputation for files that were authorized by the ISG.|
|
||||
| **16 Enabled:Update Policy No Reboot** | Use this option to allow future WDAC policy updates to apply without requiring a system reboot. |
|
||||
| **17 Enabled:Dynamic Code Security** | Enables policy enforcement for .NET applications and dynamically-loaded libraries. |
|
||||
|
||||
## Windows Defender Application Control file rule levels
|
||||
|
||||
|
||||
@ -27,9 +27,7 @@ ms.date: 04/11/2019
|
||||
|
||||
To get started, open Device Configuration in Intune, then create a new profile.
|
||||
Choose Windows 10 as the platform, and Endpoint Protection as the profile type.
|
||||
Select Windows Defender Firewall.
|
||||
Add a firewall rule to this new Endpoint Protection profile using the Add button at the bottom of the blade.
|
||||
|
||||
Select Windows Defender Firewall.
|
||||
|
||||
|
||||
>[!IMPORTANT]
|
||||
|
||||
@ -1,3 +0,0 @@
|
||||
---
|
||||
redirect_url: https://docs.microsoft.com/windows/security/threat-protection/
|
||||
---
|
||||
Reference in New Issue
Block a user