- By default, after you install the App-V 5.0 client, the client information is stored in the registry in the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\APPV\CLIENT - When you deploy a virtualized package to a computer that is running the App-V client, the associated package data is stored in the following location:
C:\ProgramData\App-VHowever, you can reconfigure this location with the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\SOFTWARE\MICROSOFT\APPV\CLIENT\STREAMING\PACKAGEINSTALLATIONROOT
- By default, after you install the App-V 5.0 client, the client information is stored in the registry in the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\APPV\CLIENT - When you deploy a virtualized package to a computer that is running the App-V client, the associated package data is stored in the following location:
C:\ProgramData\App-VHowever, you can reconfigure this location with the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\SOFTWARE\MICROSOFT\APPV\CLIENT\STREAMING\PACKAGEINSTALLATIONROOT
- For log file information that is associated with the App-V 5.0 Client, search in the following log:
Event logs/Applications and Services Logs/Microsoft/AppV - In App-V 5.0 SP3, some logs have been consolidated and moved to the following location:
Event logs/Applications and Services Logs/Microsoft/AppV/ServiceLogFor a list of the moved logs, see [About App-V 5.0 SP3](about-app-v-50-sp3.md#bkmk-event-logs-moved).
- Packages that are currently stored on computers that run the App-V 5.0 Client are saved to the following location:
C:\ProgramData\App-V\<package id>\<version id>
- For log file information that is associated with the App-V 5.0 Client, search in the following log:
Event logs/Applications and Services Logs/Microsoft/AppV - In App-V 5.0 SP3, some logs have been consolidated and moved to the following location:
Event logs/Applications and Services Logs/Microsoft/AppV/ServiceLogFor a list of the moved logs, see [About App-V 5.0 SP3](about-app-v-50-sp3.md#bkmk-event-logs-moved).
- Packages that are currently stored on computers that run the App-V 5.0 Client are saved to the following location:
C:\ProgramData\App-V\<package id>\<version id>
Choose from the following client types:
@@ -83,7 +83,7 @@ Use the following procedure to install the Microsoft Application Virtualization
>After the installation, only the .exe file can be uninstalled.
-**To install the App-V 5.0 client using a script**
+## To install the App-V 5.0 client using a script
1. Install all of the required prerequisite software on the target computers. See [What to do before you start](#bkmk-clt-install-prereqs). If you install the client by using an .msi file, the installation will fail if any prerequisites are missing.
@@ -127,7 +127,7 @@ Use the following procedure to install the Microsoft Application Virtualization
---
-**To install the App-V 5.0 client by using the Windows Installer (.msi) file**
+## To install the App-V 5.0 client by using the Windows Installer (.msi) file
1. Install the required prerequisites on the target computers. See [What to do before you start](#bkmk-clt-install-prereqs). If any prerequisites are not met, the installation will fail.
diff --git a/mdop/dart-v10/how-to-recover-remote-computers-by-using-the-dart-recovery-image-dart-10.md b/mdop/dart-v10/how-to-recover-remote-computers-by-using-the-dart-recovery-image-dart-10.md
index 1b7f39a897..2a8e35021d 100644
--- a/mdop/dart-v10/how-to-recover-remote-computers-by-using-the-dart-recovery-image-dart-10.md
+++ b/mdop/dart-v10/how-to-recover-remote-computers-by-using-the-dart-recovery-image-dart-10.md
@@ -138,7 +138,7 @@ A file is provided that is named inv32.xml and contains remote connection inform
2. The following is an example of a winpeshl.ini file that is customized to open the **Remote Connection** tool as soon as an attempt is made to boot into DaRT:
- ``` syntax
+ ```ini
[LaunchApps]
"%windir%\system32\netstart.exe -network -remount"
"cmd /C start %windir%\system32\RemoteRecovery.exe -nomessage"
diff --git a/mdop/dart-v7/how-to-recover-remote-computers-using-the-dart-recovery-image-dart-7.md b/mdop/dart-v7/how-to-recover-remote-computers-using-the-dart-recovery-image-dart-7.md
index 2fac900255..d8cdbc0ab0 100644
--- a/mdop/dart-v7/how-to-recover-remote-computers-using-the-dart-recovery-image-dart-7.md
+++ b/mdop/dart-v7/how-to-recover-remote-computers-using-the-dart-recovery-image-dart-7.md
@@ -131,7 +131,7 @@ A file is provided that is named inv32.xml and contains remote connection inform
2. The following is an example of a winpeshl.ini file that is customized to open the **Remote Connection** tool as soon as an attempt is made to boot into DaRT:
- ``` syntax
+ ```ini
[LaunchApps]
"%windir%\system32\netstart.exe -network -remount"
"cmd /C start %windir%\system32\RemoteRecovery.exe -nomessage"
diff --git a/mdop/dart-v8/how-to-recover-remote-computers-by-using-the-dart-recovery-image-dart-8.md b/mdop/dart-v8/how-to-recover-remote-computers-by-using-the-dart-recovery-image-dart-8.md
index ea9f968420..5cf1247cb4 100644
--- a/mdop/dart-v8/how-to-recover-remote-computers-by-using-the-dart-recovery-image-dart-8.md
+++ b/mdop/dart-v8/how-to-recover-remote-computers-by-using-the-dart-recovery-image-dart-8.md
@@ -138,7 +138,7 @@ A file is provided that is named inv32.xml and contains remote connection inform
2. The following is an example of a winpeshl.ini file that is customized to open the **Remote Connection** tool as soon as an attempt is made to boot into DaRT:
- ``` syntax
+ ```ini
[LaunchApps]
"%windir%\system32\netstart.exe -network -remount"
"cmd /C start %windir%\system32\RemoteRecovery.exe -nomessage"
diff --git a/mdop/mbam-v2/release-notes-for-mbam-20-mbam-2.md b/mdop/mbam-v2/release-notes-for-mbam-20-mbam-2.md
index c67aa2acee..7cb8d1004c 100644
--- a/mdop/mbam-v2/release-notes-for-mbam-20-mbam-2.md
+++ b/mdop/mbam-v2/release-notes-for-mbam-20-mbam-2.md
@@ -38,7 +38,7 @@ If you are using the MBAM Stand-alone topology, and you upgrade the server infra
WORKAROUND: After the upgrade, run the following script on the Compliance and Audit Database:
-``` syntax
+```sql
-- =============================================
-- Script Template
-- =============================================
diff --git a/mdop/mbam-v25/mbam-25-security-considerations.md b/mdop/mbam-v25/mbam-25-security-considerations.md
index f87672362a..05695a6beb 100644
--- a/mdop/mbam-v25/mbam-25-security-considerations.md
+++ b/mdop/mbam-v25/mbam-25-security-considerations.md
@@ -134,7 +134,7 @@ You can configure the MBAM Recovery and Hardware Service with the name of this s
- Configure the group after the MBAM Recovery and Hardware Service has been installed by editing the web.config file in the <inetpub>\\Microsoft Bitlocker Management Solution\\Recovery and Hardware Service\\ folder.
- ``` syntax
+ ```xml
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).
-``` syntax +```xmlThis SyncML example shows how to publish a package globally on an MDM enrolled device for all device users.
-``` syntax +```xmlThis SyncML example shows how to publish a package globally, with a policy that adds two shortcuts for the package, on an MDM enrolled device.
-``` syntax +```xmlThis SyncML example shows how to publish a package for a specific MDM user.
-``` syntax +```xmlThis SyncML example shows how to unpublish all global packages on the device by sending an empty package and connection group list in the SyncML.
-``` syntax +```xmlThese SyncML examples return all global, and user-published packages on the device.
-``` syntax +```xml-
+
- + DeviceHealthMonitoring/AllowDeviceHealthMonitoring + +
- + DeviceHealthMonitoring/ConfigDeviceHealthMonitoringScope + +
- + DeviceHealthMonitoring/ConfigDeviceHealthMonitoringUploadDestination + +
+ + +**DeviceHealthMonitoring/AllowDeviceHealthMonitoring** + + +
| Home | +Pro | +Business | +Enterprise | +Education | +Mobile | +Mobile Enterprise | +
|---|---|---|---|---|---|---|
 |
+ |
+  6 |
+ 6 |
+ 6 |
+ + | + |
+ + + +DeviceHealthMonitoring is an opt-in health monitoring connection between the device and Microsoft. You should enable this policy only if your organization is using a Microsoft device monitoring service which requires it. + + + +The following list shows the supported values: + +- 1 — The DeviceHealthMonitoring connection is enabled. +- 0 (default) — The DeviceHealthMonitoring connection is disabled. + + + + + + + + + + +
+ + +**DeviceHealthMonitoring/ConfigDeviceHealthMonitoringScope** + + +
| Home | +Pro | +Business | +Enterprise | +Education | +Mobile | +Mobile Enterprise | +
|---|---|---|---|---|---|---|
|
+ |
+ 6 |
+ 6 |
+ 6 |
+ + | + |
+ + + +This policy is applicable only if the [AllowDeviceHealthMonitoring](#devicehealthmonitoring-allowdevicehealthmonitoring) policy has been set to 1 (Enabled) on the device. +This policy modifies which health events are sent to Microsoft on the DeviceHealthMonitoring connection. +IT Pros do not need to set this policy. Instead, Microsoft Intune is expected to dynamically manage this value in coordination with the Microsoft device health monitoring service. + + + + + + + + + + + + + + +
+ + +**DeviceHealthMonitoring/ConfigDeviceHealthMonitoringUploadDestination** + + +
| Home | +Pro | +Business | +Enterprise | +Education | +Mobile | +Mobile Enterprise | +
|---|---|---|---|---|---|---|
|
+ |
+ 6 |
+ 6 |
+ 6 |
+ + | + |
+ + + +This policy is applicable only if the [AllowDeviceHealthMonitoring](#devicehealthmonitoring-allowdevicehealthmonitoring) policy has been set to 1 (Enabled) on the device. +The value of this policy constrains the DeviceHealthMonitoring connection to certain destinations in order to support regional and sovereign cloud scenarios. +In most cases, an IT Pro does not need to define this policy. Instead, it is expected that this value is dynamically managed by Microsoft Intune to align with the region or cloud to which the device's tenant is already linked. Only configure this policy manually if explicitly instructed to do so by a Microsoft device monitoring service. + + + + + + + + + + + + + +
+ + + + + +## DeviceHealthMonitoring policies supported by IoT Core + +- [DeviceHealthMonitoring/AllowDeviceHealthMonitoring](#devicehealthmonitoring-allowdevicehealthmonitoring) +- [DeviceHealthMonitoring/ConfigDeviceHealthMonitoringScope](#devicehealthmonitoring-configdevicehealthmonitoringscope) +- [DeviceHealthMonitoring/ConfigDeviceHealthMonitoringUploadDestination](#devicehealthmonitoring-configdevicehealthmonitoringuploaddestination) + + + +## DeviceHealthMonitoring policies supported by IoT Enterprise + +- [DeviceHealthMonitoring/AllowDeviceHealthMonitoring](#devicehealthmonitoring-allowdevicehealthmonitoring) +- [DeviceHealthMonitoring/ConfigDeviceHealthMonitoringScope](#devicehealthmonitoring-configdevicehealthmonitoringscope) +- [DeviceHealthMonitoring/ConfigDeviceHealthMonitoringUploadDestination](#devicehealthmonitoring-configdevicehealthmonitoringuploaddestination) + + +
+Footnotes: + +- 1 - Added in Windows 10, version 1607. +- 2 - Added in Windows 10, version 1703. +- 3 - Added in Windows 10, version 1709. +- 4 - Added in Windows 10, version 1803. +- 5 - Added in Windows 10, version 1809. +- 6 - Added in Windows 10, version 1903. \ No newline at end of file diff --git a/windows/client-management/mdm/wifi-csp.md b/windows/client-management/mdm/wifi-csp.md index a9b74522ef..8b233ba1e3 100644 --- a/windows/client-management/mdm/wifi-csp.md +++ b/windows/client-management/mdm/wifi-csp.md @@ -9,7 +9,7 @@ ms.topic: article ms.prod: w10 ms.technology: windows author: manikadhiman -ms.date: 10/24/2018 +ms.date: 06/18/2019 --- # WiFi CSP @@ -79,7 +79,10 @@ If it is an IPvFuture address, then it must be specified as an IP literal as "\[ Supported operations are Get, Add, Delete, and Replace. **DisableInternetConnectivityChecks** -Added in Windows 10, version 1511.Optional. Disable the internet connectivity check for the profile. +> [!Note] +> This node has been deprecated since Windows 10, version 1607. + +Added in Windows 10, version 1511. Optional. Disable the internet connectivity check for the profile. Value type is chr. diff --git a/windows/configuration/kiosk-shelllauncher.md b/windows/configuration/kiosk-shelllauncher.md index 6fd35e9786..5d0f225bd4 100644 --- a/windows/configuration/kiosk-shelllauncher.md +++ b/windows/configuration/kiosk-shelllauncher.md @@ -110,7 +110,7 @@ The following XML sample works for **Shell Launcher v1**: ``` -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. ``` @@ -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 +
-[Upgrade Readiness requirements](upgrade-readiness-requirements.md)
-[Upgrade Readiness release notes](upgrade-readiness-requirements.md#important-information-about-this-release)
-[Get started with Upgrade Readiness](upgrade-readiness-get-started.md)
-[Use Upgrade Readiness to manage Windows upgrades](use-upgrade-readiness-to-manage-windows-upgrades.md)
-[Troubleshoot Upgrade Readiness](troubleshoot-upgrade-readiness.md)
+[Upgrade Readiness architecture](upgrade-readiness-architecture.md)
+[Upgrade Readiness requirements](upgrade-readiness-requirements.md)
+[Upgrade Readiness release notes](upgrade-readiness-requirements.md#important-information-about-this-release)
+[Get started with Upgrade Readiness](upgrade-readiness-get-started.md)
+[Use Upgrade Readiness to manage Windows upgrades](use-upgrade-readiness-to-manage-windows-upgrades.md) \ No newline at end of file diff --git a/windows/deployment/upgrade/troubleshoot-upgrade-readiness.md b/windows/deployment/upgrade/troubleshoot-upgrade-readiness.md deleted file mode 100644 index e020be4aad..0000000000 --- a/windows/deployment/upgrade/troubleshoot-upgrade-readiness.md +++ /dev/null @@ -1,3 +0,0 @@ ---- -redirect_url: /windows/deployment/update/windows-analytics-FAQ-troubleshooting ---- \ No newline at end of file diff --git a/windows/deployment/upgrade/upgrade-readiness-additional-insights.md b/windows/deployment/upgrade/upgrade-readiness-additional-insights.md index e7672a7634..09a0e88f33 100644 --- a/windows/deployment/upgrade/upgrade-readiness-additional-insights.md +++ b/windows/deployment/upgrade/upgrade-readiness-additional-insights.md @@ -93,4 +93,4 @@ Office add-ins provides a list of the Microsoft Office add-ins in your environme ## Related topics -[Upgrade Readiness release notes](upgrade-readiness-release-notes.md) +[Manage Windows upgrades with Upgrade Readiness](manage-windows-upgrades-with-upgrade-readiness.md) diff --git a/windows/deployment/upgrade/upgrade-readiness-release-notes.md b/windows/deployment/upgrade/upgrade-readiness-release-notes.md deleted file mode 100644 index 1dbfd97e48..0000000000 --- a/windows/deployment/upgrade/upgrade-readiness-release-notes.md +++ /dev/null @@ -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 ---- diff --git a/windows/deployment/vda-subscription-activation.md b/windows/deployment/vda-subscription-activation.md index 56bd3fae25..11795953dd 100644 --- a/windows/deployment/vda-subscription-activation.md +++ b/windows/deployment/vda-subscription-activation.md @@ -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. diff --git a/windows/deployment/windows-autopilot/autopilot-faq.md b/windows/deployment/windows-autopilot/autopilot-faq.md index 9df667a4bc..59296c932d 100644 --- a/windows/deployment/windows-autopilot/autopilot-faq.md +++ b/windows/deployment/windows-autopilot/autopilot-faq.md @@ -93,15 +93,15 @@ A [glossary](#glossary) of abbreviations used in this topic is provided at the e ## The end user experience -| Question | Answer | -|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| How do I know that I received Autopilot? | You can tell that you received Windows Autopilot (as in the device received a configuration but has not yet applied it) when you skip the selection page (as seen below), and are immediately taken to a generic or customized sign-in page. | -| Windows Autopilot didn’t work, what do I do now? | Questions and actions to assist in troubleshooting: Did a screen not get skipped? Did a user end up as an admin when configured not to? Remember that AAD Admins will be local admins regardless of whether Windows Autopilot is configured to disable local admin Collection information – run licensingdiag.exe and send the .cab (Cabinet file) file that is generated to AutopilotHelp@microsoft.com. If possible, collect an ETL from WPR. Often in these cases, users are not signing into the right AAD tenant, or are creating local user accounts. For a complete list of support options, refer to [Windows Autopilot support](autopilot-support.md). | -| If an Administrator makes changes to an existing profile, will the changes take effect on devices that have that profile assigned to them that have already been deployed? | No. Windows Autopilot profiles are not resident on the device. They are downloaded during OOBE, the settings defined at the time are applied. Then, the profile is discarded on the device. If the device is re-imaged or reset, the new profile settings will take effect the next time the device goes through OOBE. | -| What is the experience if a device isn’t registered or if an IT Admin doesn’t configure Windows Autopilot prior to an end user attempting to self-deploy? | If the device isn’t registered, it will not receive the Windows Autopilot experience and the end user will go through normal OOBE. The Windows Autopilot configurations will NOT be applied until the user runs through OOBE again, after registration. If a device is started before an MDM profile is created, the device will go through standard OOBE experience. The IT Admin would then have to manually enrol that device into the MDM, after which—the next time that device is “reset”—it will go through the Windows Autopilot OOBE experience. | -| What may be a reason why I did not receive a customized sign-in screen during Autopilot? | Tenant branding must be configured in portal.azure.com to receive a customized sign-in experience. | -| What happens if a device is registered with Azure AD but does not have an Windows Autopilot profile assigned? | The regular AAD OOBE will occur since no Windows Autopilot profile was assigned to the device. | -| How can I collect logs on Autopilot? | The best way to collect logs on Windows Autopilot performance is to collect a Windows Performance Recorder (WPR) trace during OOBE. The XML file (WPRP extension) for this trace may be provided upon request. | +|Question|Answer| +|----|-----| +|How do I know that I received Autopilot?|You can tell that you received Windows Autopilot (as in the device received a configuration but has not yet applied it) when you skip the selection page (as seen below), and are immediately taken to a generic or customized sign-in page.| +|Windows Autopilot didn’t work, what do I do now?| Questions and actions to assist in troubleshooting: Did a screen not get skipped? Did a user end up as an admin when configured not to? Remember that AAD Admins will be local admins regardless of whether Windows Autopilot is configured to disable local admin Collection information – run licensingdiag.exe and send the .cab (Cabinet file) file that is generated to AutopilotHelp@microsoft.com. If possible, collect an ETL from WPR. Often in these cases, users are not signing into the right AAD tenant, or are creating local user accounts. For a complete list of support options, refer to [Windows Autopilot support](autopilot-support.md). | +| If an Administrator makes changes to an existing profile, will the changes take effect on devices that have that profile assigned to them that have already been deployed? |No. Windows Autopilot profiles are not resident on the device. They are downloaded during OOBE, the settings defined at the time are applied. Then, the profile is discarded on the device. If the device is re-imaged or reset, the new profile settings will take effect the next time the device goes through OOBE.| +|What is the experience if a device isn’t registered or if an IT Admin doesn’t configure Windows Autopilot prior to an end user attempting to self-deploy? |If the device isn’t registered, it will not receive the Windows Autopilot experience and the end user will go through normal OOBE. The Windows Autopilot configurations will NOT be applied until the user runs through OOBE again, after registration. If a device is started before an MDM profile is created, the device will go through standard OOBE experience. The IT Admin would then have to manually enrol that device into the MDM, after which—the next time that device is “reset”—it will go through the Windows Autopilot OOBE experience.| +|What may be a reason why I did not receive a customized sign-in screen during Autopilot? |Tenant branding must be configured in portal.azure.com to receive a customized sign-in experience.| +|What happens if a device is registered with Azure AD but does not have an Windows Autopilot profile assigned? |The regular AAD OOBE will occur since no Windows Autopilot profile was assigned to the device.| +|How can I collect logs on Autopilot?|The best way to collect logs on Windows Autopilot performance is to collect a Windows Performance Recorder (WPR) trace during OOBE. The XML file (WPRP extension) for this trace may be provided upon request.| ## MDM @@ -127,21 +127,22 @@ A [glossary](#glossary) of abbreviations used in this topic is provided at the e ## General -| Question | Answer | -|------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| If I wipe the machine and restart, will I still receive Windows Autopilot? | Yes, if the device is still registered for Windows Autopilot and is running Windows 10, version 1703 7B and above releases, it will receive the Windows Autopilot experience. | -| Can I harvest the device fingerprint on existing machines? | Yes, if the device is running Windows 10, version 1703 and above, you can harvest device fingerprints for registration. There are no plans to backport the functionality to previous releases and no way to harvest them on pre-Windows 10 Windows 10, version 1703 devices that have not been updated to Windows 10, version 1703. | -| What is Windows 10, version 1703 7B and why does it matter? | Windows 10, version 1703 7B is a Windows 10, version 1703 image bundled with cumulative updates. To receive Autopilot, clients **must** run Windows 10, version 1703 7B or later. These cumulative updates contain a critical fix for Autopilot. Consider the following:
Windows Autopilot will not apply its profiles to the machine unless AAD credentials match the expected AAD tenant. For the Windows 10, version 1703 release, it was assumed that would be determined by the domain name, so the domain name used to register (for example contoso.com) should match the domain name used to sign in (for example user@contoso.com). But what happens if your tenant has multiple domains (for example us.contoso.com, or fr.contoso.com)? Since these domain names do not match, the device will not be configured for Autopilot. However, both domains are part of the same AAD tenant, and as such it was determined the matching scheme was not useful. This was improved upon by making use of the tenant ID. By using the tenant ID, we can determine that if the user signs into a domain with a tenant matching the one they registered with, we can safely consider this to be a match. The fix for this problem already exists in Windows 10, version 1709 and was backported into the Windows 10, version 1703 7B release.
**Key Take-Aways**: When using pre-Windows 10, version 1703 7B clients the user’s domain **must** match the domain they registered with. This functionality is found in Windows 10 version 1709 clients using build >= 16215, and Windows 10, version 1703 clients >= 7B. | -| What is the impact of not updating to 7B? | See the detailed scenario described directly above. | -| Is Windows Autopilot supported on other SKUs, e.g. Surface Hub, HoloLens, Windows Mobile. | No, Windows Autopilot isn’t supported on other SKUs. | -| Does Windows Autopilot work after MBR or image re-installation? | Yes. | -| Can machines that have reimaged a few times go through Autopilot? What does the error message "This user is not authorized to enroll" mean? Error code 801c0003. | There are limits to the number of devices a particular AAD user can enroll in AAD, as well as the number of devices that are supported per user in Intune. (These are somewhat configurable but not “infinite.”) You’ll run into this frequently if you reuse the devices, or even if you roll back to previous virtual machine snapshots. | -| What happens if a device is registered to a malicious agent? | By design, Windows Autopilot does not apply a profile until the user signs in with the matching tenant for the configured profile via the AAD sign-in process. What occurs is illustrated below. If badguys.com registers a device owned by contoso.com, at worst, the user would be directed to sign into badguys.com. When the user enters their email/password, the sign-in information is redirected through AAD to the proper AAD authentication and the user is prompted to then sign into contoso.com. Since contoso.com does not match badguys.com as the tenant, the Windows Autopilot profile will not be applied and the regular AAD OOBE will occur. | -| Where is the Windows Autopilot data stored? | Windows Autopilot data is stored in the United States (US), not in a sovereign cloud, even when the AAD tenant is registered in a sovereign cloud. This is applicable to all Windows Autopilot data, regardless of the portal leveraged to deploy Autopilot. | -| Why is Windows Autopilot data stored in the US and not in a sovereign cloud? | It is not customer data that we store, but business data which enables Microsoft to provide a service, therefore it is okay for the data to reside in the US. Customers can stop subscribing to the service any time, and, in that event, the business data is removed by Microsoft. | -| How many ways are there to register a device for Windows Autopilot | There are six ways to register a device, depending on who is doing the registering:
1. OEM Direct API (only available to TVOs)
2. MPC via the MPC API (must be a CSP)
3. MPC via manual upload of CSV file in the UI (must be a CSP)
4. MSfB via CSV file upload
5. Intune via CSV file upload
6. Microsoft 365 Business portal via CSV file upload | -| How many ways are there to create an Windows Autopilot profile? | There are four ways to create & assign an Windows Autopilot profile:
1. Through MPC (must be a CSP)
2. Through MSfB
3. Through Intune (or another MDM)
4. Microsoft 365 Business portal
Microsoft recommends creation and assignment of profiles through Intune. | -| What are some common causes of registration failures? |
1. Bad or missing Hardware hash entries can lead to faulty registration attempts
2. Hidden special characters in CSV files.
To avoid this issue, after creating your CSV file, open it in Notepad to look for hidden characters or trailing spaces or other corruptions. | +|Question|Answer +|------------------|-----------------| +|If I wipe the machine and restart, will I still receive Windows Autopilot?|Yes, if the device is still registered for Windows Autopilot and is running Windows 10, version 1703 7B and above releases, it will receive the Windows Autopilot experience.| +|Can I harvest the device fingerprint on existing machines?|Yes, if the device is running Windows 10, version 1703 and above, you can harvest device fingerprints for registration. There are no plans to backport the functionality to previous releases and no way to harvest them on pre-Windows 10 Windows 10, version 1703 devices that have not been updated to Windows 10, version 1703.| +|What is Windows 10, version 1703 7B and why does it matter?| Windows 10, version 1703 7B is a Windows 10, version 1703 image bundled with cumulative updates. To receive Autopilot, clients **must** run Windows 10, version 1703 7B or later. These cumulative updates contain a critical fix for Autopilot. Consider the following:
Windows Autopilot will not apply its profiles to the machine unless AAD credentials match the expected AAD tenant. For the Windows 10, version 1703 release, it was assumed that would be determined by the domain name, so the domain name used to register (for example contoso.com) should match the domain name used to sign in (for example user@contoso.com). But what happens if your tenant has multiple domains (for example us.contoso.com, or fr.contoso.com)? Since these domain names do not match, the device will not be configured for Autopilot. However, both domains are part of the same AAD tenant, and as such it was determined the matching scheme was not useful. This was improved upon by making use of the tenant ID. By using the tenant ID, we can determine that if the user signs into a domain with a tenant matching the one they registered with, we can safely consider this to be a match. The fix for this problem already exists in Windows 10, version 1709 and was backported into the Windows 10, version 1703 7B release.
**Key Take-Aways**: When using pre-Windows 10, version 1703 7B clients the user’s domain **must** match the domain they registered with. This functionality is found in Windows 10 version 1709 clients using build >= 16215, and Windows 10, version 1703 clients >= 7B. | +|What is the impact of not updating to 7B?|See the detailed scenario described directly above.| +|Is Windows Autopilot supported on other SKUs, e.g. Surface Hub, HoloLens, Windows Mobile.|No, Windows Autopilot isn’t supported on other SKUs.| +|Does Windows Autopilot work after MBR or image re-installation?|Yes.| +| Can machines that have reimaged a few times go through Autopilot? What does the error message "This user is not authorized to enroll" mean? Error code 801c0003. |There are limits to the number of devices a particular AAD user can enroll in AAD, as well as the number of devices that are supported per user in Intune. (These are somewhat configurable but not “infinite.”) You’ll run into this frequently if you reuse the devices, or even if you roll back to previous virtual machine snapshots.| +|What happens if a device is registered to a malicious agent? |By design, Windows Autopilot does not apply a profile until the user signs in with the matching tenant for the configured profile via the AAD sign-in process. What occurs is illustrated below. If badguys.com registers a device owned by contoso.com, at worst, the user would be directed to sign into badguys.com. When the user enters their email/password, the sign-in information is redirected through AAD to the proper AAD authentication and the user is prompted to then sign into contoso.com. Since contoso.com does not match badguys.com as the tenant, the Windows Autopilot profile will not be applied and the regular AAD OOBE will occur.| +|Where is the Windows Autopilot data stored? |Windows Autopilot data is stored in the United States (US), not in a sovereign cloud, even when the AAD tenant is registered in a sovereign cloud. This is applicable to all Windows Autopilot data, regardless of the portal leveraged to deploy Autopilot.| +|Why is Windows Autopilot data stored in the US and not in a sovereign cloud?|It is not customer data that we store, but business data which enables Microsoft to provide a service, therefore it is okay for the data to reside in the US. Customers can stop subscribing to the service any time, and, in that event, the business data is removed by Microsoft.| +|How many ways are there to register a device for Windows Autopilot|There are six ways to register a device, depending on who is doing the registering:
1. OEM Direct API (only available to TVOs)
2. MPC via the MPC API (must be a CSP)
3. MPC via manual upload of CSV file in the UI (must be a CSP)
4. MSfB via CSV file upload
5. Intune via CSV file upload
6. Microsoft 365 Business portal via CSV file upload| +|How many ways are there to create an Windows Autopilot profile?|There are four ways to create & assign an Windows Autopilot profile:
1. Through MPC (must be a CSP)
2. Through MSfB
3. Through Intune (or another MDM)
4. Microsoft 365 Business portal
Microsoft recommends creation and assignment of profiles through Intune. | +| What are some common causes of registration failures? |
1. Bad or missing Hardware hash entries can lead to faulty registration attempts
2. Hidden special characters in CSV files.
To avoid this issue, after creating your CSV file, open it in Notepad to look for hidden characters or trailing spaces or other corruptions.| +| Is Autopilot supported in all regions/countries? |
Autopilot only supports customers using public Azure. Public Azure does not include the three entities listed below:
- Azure Germany
- Azure China
- Azure Government
So, if a customer is set up in global Azure, there are no region restrictions. For example, if Contoso uses global Azure but has employees working in China, the Contoso employees working in China would be able to use Autopilot to deploy devices. If Contoso uses Azure China, the Contoso employees would not be able to use Autopilot.| ## Glossary diff --git a/windows/deployment/windows-autopilot/existing-devices.md b/windows/deployment/windows-autopilot/existing-devices.md index fb3a5b3593..c177340864 100644 --- a/windows/deployment/windows-autopilot/existing-devices.md +++ b/windows/deployment/windows-autopilot/existing-devices.md @@ -19,12 +19,12 @@ ms.topic: article **Applies to: Windows 10** -Modern desktop management with Windows Autopilot enables you to easily deploy the latest version of Windows 10 to your existing devices. The apps you need for work can be automatically installed. Your work profile is synchronized, so you can resume working right away. +Modern desktop deployment with Windows Autopilot enables you to easily deploy the latest version of Windows 10 to your existing devices. The apps you need for work can be automatically installed. Your work profile is synchronized, so you can resume working right away. -This topic describes how to convert Windows 7 or Windows 8.1 domain-joined computers to Azure Active Directory-joined computers running Windows 10 by using Windows Autopilot. +This topic describes how to convert Windows 7 or Windows 8.1 domain-joined computers to Windows 10 devices joined to either Azure Active Directory or Active Directory (Hybrid Azure AD Join) by using Windows Autopilot. >[!NOTE] ->Windows Autopilot for existing devices only supports user-driven Azure Active Directory profiles. Hybrid AAD joined devices and self-deploying profiles are not supported. +>Windows Autopilot for existing devices only supports user-driven Azure Active Directory and Hybrid Azure AD profiles. Self-deploying profiles are not supported. ## Prerequisites @@ -91,7 +91,7 @@ See the following examples. Get-AutopilotProfile | ConvertTo-AutopilotConfigurationJSON ``` - See the following sample output: + See the following sample output: (use the horizontal scroll bar at the bottom to view long lines)
PS C:\> Get-AutopilotProfile | ConvertTo-AutopilotConfigurationJSON
{
@@ -117,14 +117,14 @@ See the following examples.
| CloudAssignedTenantId (guid, required) | The Azure Active Directory tenant ID that should be used. This is the GUID for the tenant, and can be found in properties of the tenant. The value should not include braces. |
| CloudAssignedTenantDomain (string, required) | The Azure Active Directory tenant name that should be used, e.g. tenant.onmicrosoft.com. |
| CloudAssignedOobeConfig (number, required) | This is a bitmap that shows which Autopilot settings were configured. Values include: SkipCortanaOptIn = 1, OobeUserNotLocalAdmin = 2, SkipExpressSettings = 4, SkipOemRegistration = 8, SkipEula = 16 |
- | CloudAssignedDomainJoinMethod (number, required) | This property should be set to 0 and specifies that the device should join Azure AD. |
+ | CloudAssignedDomainJoinMethod (number, required) | This property specifies whether the device should join Azure Active Directory or Active Directory (Hybrid Azure AD Join). Values include: Active AD Join = 0, Hybrid Azure AD Join = 1 |
| CloudAssignedForcedEnrollment (number, required) | Specifies that the device should require AAD Join and MDM enrollment.
0 = not required, 1 = required. |
| ZtdCorrelationId (guid, required) | A unique GUID (without braces) that will be provided to Intune as part of the registration process. ZtdCorrelationId will be included in enrollment message as “OfflineAutoPilotEnrollmentCorrelator”. This attribute will be present only if the enrollment is taking place on a device registered with Zero Touch Provisioning via offline registration. |
| CloudAssignedAadServerData (encoded JSON string, required) | An embedded JSON string used for branding. It requires AAD corp branding enabled.
Example value: "CloudAssignedAadServerData": "{\"ZeroTouchConfig\":{\"CloudAssignedTenantUpn\":\"\",\"CloudAssignedTenantDomain\":\"tenant.onmicrosoft.com\"}}" |
| CloudAssignedDeviceName (string, optional) | The name automatically assigned to the computer. This follows the naming pattern convention that can be configured in Intune as part of the Autopilot profile, or can specify an explicit name to use. |
-5. The Autopilot profile must be saved as a JSON file in ASCII or ANSI format. Windows PowerShell defaults to Unicode format, so if you attempt to redirect output of the commands to a file, you must also specify the file format. For example, to save the file in ASCII format using Windows PowerShell, you can create a directory (ex: c:\Autopilot) and save the profile as shown below:
+5. The Autopilot profile must be saved as a JSON file in ASCII or ANSI format. Windows PowerShell defaults to Unicode format, so if you attempt to redirect output of the commands to a file, you must also specify the file format. For example, to save the file in ASCII format using Windows PowerShell, you can create a directory (ex: c:\Autopilot) and save the profile as shown below: (use the horizontal scroll bar at the bottom if needed to view the entire command string)
```
Get-AutopilotProfile | ConvertTo-AutopilotConfigurationJSON | Out-File c:\Autopilot\AutopilotConfigurationFile.json -Encoding ASCII
@@ -301,6 +301,9 @@ The Task Sequence will download content, reboot, format the drives and install W
+>[!NOTE]
+>If joining devices to Active Directory (Hybrid Azure AD Join), it is necessary to create a Domain Join device configuration profile that is targeted to "All Devices" (since there is no Azure Active Directory device object for the computer to do group-based targeting). See [User-driven mode for hybrid Azure Active Directory join](https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/user-driven#user-driven-mode-for-hybrid-azure-active-directory-join) for more information.
+
### Register the device for Windows Autopilot
Devices provisioned through Autopilot will only receive the guided OOBE Autopilot experience on first boot. Once updated to Windows 10, the device should be registered to ensure a continued Autopilot experience in the event of PC reset. You can enable automatic registration for an assigned group using the **Convert all targeted devices to Autopilot** setting. For more information, see [Create an Autopilot deployment profile](https://docs.microsoft.com/intune/enrollment-autopilot#create-an-autopilot-deployment-profile).
diff --git a/windows/deployment/windows-autopilot/self-deploying.md b/windows/deployment/windows-autopilot/self-deploying.md
index bcddf84201..48841e967b 100644
--- a/windows/deployment/windows-autopilot/self-deploying.md
+++ b/windows/deployment/windows-autopilot/self-deploying.md
@@ -1,5 +1,5 @@
---
-title: Windows Autopilot Self-Deploying mode (Preview)
+title: Windows Autopilot Self-Deploying mode
description: Windows Autopilot deployment
keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune
ms.reviewer: mniehaus
@@ -15,10 +15,9 @@ ms.collection: M365-modern-desktop
ms.topic: article
---
-
# Windows Autopilot Self-Deploying mode
-**Applies to: Windows 10, version 1809 or later**
+**Applies to: Windows 10, version 1903 or later**
Windows Autopilot self-deploying mode enables a device to be deployed with little to no user interaction. For devices with an Ethernet connection, no user interaction is required; for devices connected via Wi-fi, no interaction is required after making the Wi-fi connection (choosing the language, locale, and keyboard, then making a network connection).
@@ -39,7 +38,7 @@ Self-deploying mode is designed to deploy Windows 10 as a kiosk, digital signage
Because self-deploying mode uses a device’s TPM 2.0 hardware to authenticate the device into an organization’s Azure AD tenant, devices without TPM 2.0 cannot be used with this mode. The devices must also support TPM device attestation. (All newly-manufactured Windows devices should meet these requirements.)
>[!NOTE]
->If you attempt a self-deploying mode deployment on a device that does not have support TPM 2.0 or on a virtual machine, the process will fail when verifying the device with an 0x800705B4 timeout error. (Hyper-V virtual TPMs are not supported.)
+>If you attempt a self-deploying mode deployment on a device that does not have support TPM 2.0 or on a virtual machine, the process will fail when verifying the device with an 0x800705B4 timeout error (Hyper-V virtual TPMs are not supported).. Also note that Window 10, version 1903 or later is required to use self-deploying mode due to issues with TPM device attestation in Windows 10, version 1809.
In order to display an organization-specific logo and organization name during the Autopilot process, Azure Active Directory Company Branding needs to be configured with the images and text that should be displayed. See [Quickstart: Add company branding to your sign-in page in Azure AD](https://docs.microsoft.com/azure/active-directory/fundamentals/customize-branding) for more details.
@@ -68,4 +67,7 @@ When performing a self-deploying mode deployment using Windows Autopilot, the fo
- Remain at the logon screen, where any member of the organization can log on by specifying their Azure AD credentials.
- Automatically sign in as a local account, for devices configured as a kiosk or digital signage.
+>[!NOTE]
+>Deploying EAS policies using self-deploying mode for kiosk deployments will cause auto-logon functionality to fail.
+
In case the observed results do not match these expectations, consult the [Windows Autopilot Troubleshooting](troubleshooting.md) documentation.
diff --git a/windows/deployment/windows-autopilot/windows-autopilot-whats-new.md b/windows/deployment/windows-autopilot/windows-autopilot-whats-new.md
index 9f414b3464..57c91a67e4 100644
--- a/windows/deployment/windows-autopilot/windows-autopilot-whats-new.md
+++ b/windows/deployment/windows-autopilot/windows-autopilot-whats-new.md
@@ -42,6 +42,9 @@ Windows Autopilot [self-deploying mode](self-deploying.md) enables a zero touch
You can utilize Windows Autopilot self-deploying mode to register the device to an AAD tenant, enroll in your organization’s MDM provider, and provision policies and applications, all with no user authentication or user interaction required.
+>[!NOTE]
+>Window 10, version 1903 or later is required to use self-deploying mode due to issues with TPM device attestation in Windows 10, version 1809.
+
## Related topics
[What's new in Microsoft Intune](https://docs.microsoft.com/intune/whats-new)
diff --git a/windows/privacy/manage-windows-1809-endpoints.md b/windows/privacy/manage-windows-1809-endpoints.md
index d148047f46..3fad7e54b2 100644
--- a/windows/privacy/manage-windows-1809-endpoints.md
+++ b/windows/privacy/manage-windows-1809-endpoints.md
@@ -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.
diff --git a/windows/security/identity-protection/credential-guard/additional-mitigations.md b/windows/security/identity-protection/credential-guard/additional-mitigations.md
index 93d0011f35..c67ea0ab51 100644
--- a/windows/security/identity-protection/credential-guard/additional-mitigations.md
+++ b/windows/security/identity-protection/credential-guard/additional-mitigations.md
@@ -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 ##
diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md
index 0492d0e9fc..a3ff61d617 100644
--- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md
@@ -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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The on-premises STS server issues a enterprise token on successful MFA. The application sends the token to Azure Active Directory.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.|
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md
index 4dc8b49caf..8a74c77ed5 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md
@@ -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)
-
## Follow the Windows Hello for Business hybrid certificate trust deployment guide
diff --git a/windows/security/information-protection/bitlocker/bitlocker-management-for-enterprises.md b/windows/security/information-protection/bitlocker/bitlocker-management-for-enterprises.md
index fb326e7977..b89ced627d 100644
--- a/windows/security/information-protection/bitlocker/bitlocker-management-for-enterprises.md
+++ b/windows/security/information-protection/bitlocker/bitlocker-management-for-enterprises.md
@@ -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
+
+
-**Powershell**
+# **PowerShell**
[BitLocker cmdlets for Windows PowerShell](bitlocker-use-bitlocker-drive-encryption-tools-to-manage-bitlocker.md#bitlocker-cmdlets-for-windows-powershell)
diff --git a/windows/security/threat-protection/microsoft-defender-atp/threat-and-vuln-mgt-scenarios.md b/windows/security/threat-protection/microsoft-defender-atp/threat-and-vuln-mgt-scenarios.md
index 504baecd76..5d53cdeabf 100644
--- a/windows/security/threat-protection/microsoft-defender-atp/threat-and-vuln-mgt-scenarios.md
+++ b/windows/security/threat-protection/microsoft-defender-atp/threat-and-vuln-mgt-scenarios.md
@@ -61,7 +61,7 @@ To lower down your threat and vulnerability exposure:
> There are two types of recommendations:
> - Security update which refers to recommendations that require a package installation
> - Configuration 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. 
diff --git a/windows/security/threat-protection/windows-defender-antivirus/configure-extension-file-exclusions-windows-defender-antivirus.md b/windows/security/threat-protection/windows-defender-antivirus/configure-extension-file-exclusions-windows-defender-antivirus.md
index f18faca295..a780487207 100644
--- a/windows/security/threat-protection/windows-defender-antivirus/configure-extension-file-exclusions-windows-defender-antivirus.md
+++ b/windows/security/threat-protection/windows-defender-antivirus/configure-extension-file-exclusions-windows-defender-antivirus.md
@@ -185,34 +185,34 @@ The following table describes how the wildcards can be used and provides some ex
| Wildcard | -Use in file and file extension exclusions | +Use in file name and file extension exclusions | Use in folder exclusions | Example use | -Example matches> | +Example matches | |||
|---|---|---|---|---|---|---|---|---|---|
| (asterisk) | +* (asterisk) | Replaces any number of characters. Only applies to files in the last folder defined in the argument. |
- Replaces a single folder. Use multiple with folder slashes \ to indicate multiple, nested folders. After matching to the number of wilcarded and named folders, all subfolders will also be included. |
+ Replaces a single folder. Use multiple * with folder slashes \ to indicate multiple, nested folders. After matching the number of wilcarded and named folders, all subfolders will also be included. |
|
|
@@ -227,7 +227,7 @@ The following table describes how the wildcards can be used and provides some ex
Replaces a single character in a folder name. - 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. |
|
|
|
diff --git a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md
index 18aaf0b398..960a7fb0ca 100644
--- a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md
+++ b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md
@@ -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
diff --git a/windows/security/threat-protection/windows-firewall/create-windows-firewall-rules-in-intune.md b/windows/security/threat-protection/windows-firewall/create-windows-firewall-rules-in-intune.md
index 9dc6366064..8de4021830 100644
--- a/windows/security/threat-protection/windows-firewall/create-windows-firewall-rules-in-intune.md
+++ b/windows/security/threat-protection/windows-firewall/create-windows-firewall-rules-in-intune.md
@@ -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]
diff --git a/windows/threat-protection/index.md b/windows/threat-protection/index.md
deleted file mode 100644
index 1417ec0534..0000000000
--- a/windows/threat-protection/index.md
+++ /dev/null
@@ -1,3 +0,0 @@
----
-redirect_url: https://docs.microsoft.com/windows/security/threat-protection/
----