Merge pull request #5436 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to master to sync with https://github.com/MicrosoftDocs/windows-itpro-docs (branch public)
This commit is contained in:
Diana Hanson
2021-07-23 12:55:33 -06:00
committed by GitHub
6 changed files with 22 additions and 19 deletions

View File

@ -10,7 +10,7 @@ ms.prod: w10
ms.technology: windows
author: dansimp
ms.localizationpriority: medium
ms.date: 06/23/2021
ms.date: 07/23/2021
---
# Defender CSP
@ -61,7 +61,7 @@ Defender
--------SupportLogLocation (Added in the next major release of Windows 10)
--------PlatformUpdatesChannel (Added with the 4.18.2106.5 Defender platform release)
--------EngineUpdatesChannel (Added with the 4.18.2106.5 Defender platform release)
--------SignaturesUpdatesChannel (Added with the 4.18.2106.5 Defender platform release)
--------DefinitionUpdatesChannel (Added with the 4.18.2106.5 Defender platform release)
--------DisableGradualRelease (Added with the 4.18.2106.5 Defender platform release)
----Scan
----UpdateSignature

View File

@ -22,9 +22,9 @@ ms.topic: article
This article is specifically targeted at configuring devices enrolled to [Microsoft Endpoint Manager](/mem/endpoint-manager-overview) for Update Compliance, within MEM itself. Configuring devices for Update Compliance in MEM breaks down to the following steps:
1. [Create a configuration profile](#create-a-configuration-profile) for devices you want to enroll, that contains settings for all the MDM policies that must be configured.
2. [Deploy the configuration script](#deploy-the-configuration-script) as a Win32 app to those same devices, so additional checks can be performed to ensure devices are correctly configured.
3. Wait for data to populate. The length of this process depends on the computer being on, connected to the internet, and correctly configured. Some data types take longer to appear than others. You can learn more about this in the broad section on [enrolling devices to Update Compliance](update-compliance-get-started.md#enroll-devices-in-update-compliance).
1. [Create a configuration profile](#create-a-configuration-profile) for devices you want to enroll, that contains settings for all the MDM policies that must be configured.
2. [Deploy the configuration script](#deploy-the-configuration-script) as a Win32 app to those same devices, so additional checks can be performed to ensure devices are correctly configured.
3. Wait for data to populate. The length of this process depends on the computer being on, connected to the internet, and correctly configured. Some data types take longer to appear than others. You can learn more about this in the broad section on [enrolling devices to Update Compliance](update-compliance-get-started.md#enroll-devices-in-update-compliance).
## Create a configuration profile
@ -37,7 +37,7 @@ Take the following steps to create a configuration profile that will set require
5. You are now on the Configuration profile creation screen. On the **Basics** tab, give a **Name** and **Description**.
6. On the **Configuration settings** page, you will be adding multiple OMA-URI Settings that correspond to the policies described in [Manually configuring devices for Update Compliance](update-compliance-configuration-manual.md).
1. If you don't already have it, get your Commercial ID. For steps, see [Get your CommmercialID](update-compliance-get-started.md#get-your-commercialid).
2. Add a setting for **Commercial ID** ) with the following values:
2. Add a setting for **Commercial ID** with the following values:
- **Name**: Commercial ID
- **Description**: Sets the Commercial ID that corresponds to the Update Compliance Log Analytics workspace.
- **OMA-URI**: `./Vendor/MSFT/DMClient/Provider/ProviderID/CommercialID`
@ -61,17 +61,17 @@ Take the following steps to create a configuration profile that will set require
- **OMA-URI**: `./Vendor/MSFT/Policy/Config/System/AllowDeviceNameInDiagnosticData`
- **Data type**: Integer
- **Value**: 1
5. Add a setting to **Allow Update Compliance processing**; this policy is required for Update Compliance:
5. Add a setting to **Allow Update Compliance processing**; this policy is required for Update Compliance:
- **Name**: Allow Update Compliance Processing
- **Description**: Opts device data into Update Compliance processing. Required to see data.
- **Description**: Opts device data into Update Compliance processing. Required to see data.
- **OMA-URI**: `./Vendor/MSFT/Policy/Config/System/AllowUpdateComplianceProcessing`
- **Data type**: Integer
- **Value**: 16
7. Proceed through the next set of tabs **Scope tags**, **Assignments**, and **Applicability Rules** to assign the configuration profile to devices you wish to enroll.
8. Review and select **Create**.
7. Proceed through the next set of tabs **Scope tags**, **Assignments**, and **Applicability Rules** to assign the configuration profile to devices you wish to enroll.
8. Review and select **Create**.
## Deploy the configuration script
The [Update Compliance Configuration Script](update-compliance-configuration-script.md) is an important component of properly enrolling devices in Update Compliance, though it isn't strictly necessary. It checks to ensure that devices have the required services running and checks connectivity to the endpoints detailed in the section on [Manually configuring devices for Update Compliance](update-compliance-configuration-manual.md). You can deploy the script as a Win32 app. For more information, see [Win32 app management in Microsoft Intune](/mem/intune/apps/apps-win32-app-management).
The [Update Compliance Configuration Script](update-compliance-configuration-script.md) is an important component of properly enrolling devices in Update Compliance, though it isn't strictly necessary. It checks to ensure that devices have the required services running and checks connectivity to the endpoints detailed in the section on [Manually configuring devices for Update Compliance](update-compliance-configuration-manual.md). You can deploy the script as a Win32 app. For more information, see [Win32 app management in Microsoft Intune](/mem/intune/apps/apps-win32-app-management).
When you deploy the configuration script as a Win32 app, you won't be able to retrieve the results of logs on the device without having access to the device, or saving results of the logs to a shared filesystem. We recommend deploying the script in Pilot mode to a set of devices that you do have access to, or have a way to access the resultant log output the script provides, with as similar of a configuration profile as other devices which will be enrolled to Update Compliance, and analyzing the logs for any potential issues. Following this, you can deploy the configuration script in Deployment mode as a Win32 app to all Update Compliance devices.
When you deploy the configuration script as a Win32 app, you won't be able to retrieve the results of logs on the device without having access to the device, or saving results of the logs to a shared filesystem. We recommend deploying the script in Pilot mode to a set of devices that you do have access to, or have a way to access the resultant log output the script provides, with as similar of a configuration profile as other devices which will be enrolled to Update Compliance, and analyzing the logs for any potential issues. Following this, you can deploy the configuration script in Deployment mode as a Win32 app to all Update Compliance devices.

View File

@ -5,7 +5,7 @@ keywords: updates, servicing, current, deployment, semi-annual channel, feature,
ms.prod: w10
ms.mktglfcycl: manage
author: jaimeo
ms.localizationpriority: medium
ms.localizationpriority: high
ms.author: jaimeo
ms.reviewer:
manager: laurawi
@ -74,4 +74,4 @@ See [Build deployment rings for Windows 10 updates](waas-deployment-rings-window
- [Integrate Windows Update for Business with management solutions](waas-integrate-wufb.md)
- [Walkthrough: use Group Policy to configure Windows Update for Business](waas-wufb-group-policy.md)
- [Walkthrough: use Intune to configure Windows Update for Business](/intune/windows-update-for-business-configure)
- [Manage device restarts after updates](waas-restart.md)
- [Manage device restarts after updates](waas-restart.md)

View File

@ -105,7 +105,7 @@ Three approaches are documented here:
1. Update the certificate template by executing the following command:
certutil - dsaddtemplate \<TemplateName\>.txt
certutil -dsaddtemplate \<TemplateName\>.txt
1. In the Certificate Authority console, right-click **Certificate Templates**, select **New**, and select **Certificate Template to Issue**
@ -206,4 +206,4 @@ After adding the certificate using an approach from any of the previous sections
1. Open the Remote Desktop Client (%windir%\system32\mstsc.exe) on the Hybrid AAD-Joined client where the authentication certificate has been deployed.
1. Attempt an RDP session to a target server.
1. Use the certificate credential protected by your Windows Hello for Business gesture.
1. Use the certificate credential protected by your Windows Hello for Business gesture.

View File

@ -282,6 +282,7 @@ The most common values:
| 2 | PA-ENC-TIMESTAMP | This is a normal type for standard password authentication. |
| 11 | PA-ETYPE-INFO | The ETYPE-INFO pre-authentication type is sent by the KDC in a KRB-ERROR indicating a requirement for additional pre-authentication. It is usually used to notify a client of which key to use for the encryption of an encrypted timestamp for the purposes of sending a PA-ENC-TIMESTAMP pre-authentication value.<br>Never saw this Pre-Authentication Type in Microsoft Active Directory environment. |
| 15 | PA-PK-AS-REP\_OLD | Used for Smart Card logon authentication. |
| 16 | PA-PK-AS-REQ | Request sent to KDC in Smart Card authentication scenarios. |
| 17 | PA-PK-AS-REP | This type should also be used for Smart Card authentication, but in certain Active Directory environments, it is never seen. |
| 19 | PA-ETYPE-INFO2 | The ETYPE-INFO2 pre-authentication type is sent by the KDC in a KRB-ERROR indicating a requirement for additional pre-authentication. It is usually used to notify a client of which key to use for the encryption of an encrypted timestamp for the purposes of sending a PA-ENC-TIMESTAMP pre-authentication value.<br>Never saw this Pre-Authentication Type in Microsoft Active Directory environment. |
| 20 | PA-SVR-REFERRAL-INFO | Used in KDC Referrals tickets. |
@ -343,4 +344,4 @@ For 4768(S, F): A Kerberos authentication ticket (TGT) was requested.
| **Result Code** | **0x29** (Message stream modified and checksum didn't match). The authentication data was encrypted with the wrong key for the intended server. The authentication data was modified in transit by a hardware or software error, or by an attacker. Monitor for these events because this should not happen in a standard Active Directory environment. |
| **Result Code** | **0x3C** (Generic error). This error can help you more quickly identify problems with Kerberos authentication. |
| **Result Code** | **0x3E** (The client trust failed or is not implemented). This error helps you identify logon attempts with revoked certificates and the situations when the root Certification Authority that issued the smart card certificate (through a chain) is not trusted by a domain controller. |
| **Result Code** | **0x3F**, **0x40**, **0x41** errors. These errors can help you more quickly identify smart-card related problems with Kerberos authentication. |
| **Result Code** | **0x3F**, **0x40**, **0x41** errors. These errors can help you more quickly identify smart-card related problems with Kerberos authentication. |

View File

@ -119,7 +119,7 @@ In either of the scenarios above, once these rules are added they must be delete
When designing a set of firewall policies for your network, it is a best practice to configure allow rules for any networked applications deployed on the host. Having these rules in place before the user first launches the application will help ensure a seamless experience.
The absence of these staged rules does not necessarily mean that in the end an application will be unable to communicate on the network. However, the behaviors involved in the automatic creation of application rules at runtime requires user interaction.
The absence of these staged rules does not necessarily mean that in the end an application will be unable to communicate on the network. However, the behaviors involved in the automatic creation of application rules at runtime require user interaction and administrative privilege. If the device is expected to be used by non-administrative users, you should follow best practices and provide these rules before the application's first launch to avoid unexpected networking issues.
To determine why some applications are blocked from communicating in the network, check for the following:
@ -129,6 +129,8 @@ To determine why some applications are blocked from communicating in the network
3. Local Policy Merge is disabled, preventing the application or network service from creating local rules.
Creation of application rules at runtime can also be prohibited by administrators using the Settings app or Group Policy.
![Windows Firewall prompt](images/fw04-userquery.png)
*Figure 4: Dialog box to allow access*
@ -207,4 +209,4 @@ For tasks related to creating outbound rules, see [Checklist: Creating Outbound
## Document your changes
When creating an inbound or outbound rule, you should specify details about the app itself, the port range used, and important notes like creation date. Rules must be well-documented for ease of review both by you and other admins. We highly encourage taking the time to make the work of reviewing your firewall rules at a later date easier. And *never* create unnecessary holes in your firewall.
When creating an inbound or outbound rule, you should specify details about the app itself, the port range used, and important notes like creation date. Rules must be well-documented for ease of review both by you and other admins. We highly encourage taking the time to make the work of reviewing your firewall rules at a later date easier. And *never* create unnecessary holes in your firewall.