Merge pull request #5147 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)

windows/client-management/mdm/device-update-management.md

@@ -69,7 +69,8 @@ Some important highlights:
 -   The protocol allows the MDM to sync update metadata for a particular update by calling GetUpdateData. For more information, see [GetUpdateData](/openspecs/windows_protocols/ms-wsusss/c28ad30c-fa3f-4bc6-a747-788391d2d964) in MSDN. The LocURI to get the applicable updates with their revision Numbers is `<LocURI>./Vendor/MSFT/Update/InstallableUpdates?list=StructData</LocURI>`. Because not all updates are available via S2S sync, make sure you handle SOAP errors.
 -   For mobile devices, you can either sync metadata for a particular update by calling GetUpdateData, or for a local on-premises solution, you can use WSUS and manually import the mobile updates from the Microsoft Update Catalog site. For more information, see [Process flow diagram and screenshots of server sync process](#process-flow-diagram-and-screenshots-of-server-sync-process).
 
-> **Note**  On Microsoft Update, metadata for a given update gets modified over time (updating descriptive information, fixing bugs in applicability rules, localization changes, etc). Each time such a change is made that doesn’t affect the update itself, a new update revision is created. The identity of an update revision is a compound key containing both an UpdateID (GUID) and a RevisionNumber (int). The MDM should not expose the notion of an update revision to IT. Instead, for each UpdateID (GUID) the MDM should just keep the metadata for the later revision of that update (the one with the highest revision number).
+> [!NOTE]
+> On Microsoft Update, metadata for a given update gets modified over time (updating descriptive information, fixing bugs in applicability rules, localization changes, etc). Each time such a change is made that doesn’t affect the update itself, a new update revision is created. The identity of an update revision is a compound key containing both an UpdateID (GUID) and a RevisionNumber (int). The MDM should not expose the notion of an update revision to IT. Instead, for each UpdateID (GUID) the MDM should just keep the metadata for the later revision of that update (the one with the highest revision number).
 
 
 ## <a href="" id="examplesofupdatestructure"></a>Examples of update metadata XML structure and element descriptions

windows/client-management/mdm/networkqospolicy-csp.md

@@ -6,7 +6,7 @@ ms.topic: article
 ms.prod: w10
 ms.technology: windows
 author: manikadhiman
-ms.date: 06/26/2017
+ms.date: 04/22/2021
 ms.reviewer: 
 manager: dansimp
 ---
@@ -25,7 +25,11 @@ The following actions are supported:
 - Layer 3 tagging using a differentiated services code point (DSCP) value
 
 > [!NOTE]
-> The NetworkQoSPolicy configuration service provider is officially supported for devices that are Intune managed and Azure AD joined. Currently, this CSP is not supported on Azure AD Hybrid joined devices and for devices using GPO and CSP at the same time. The minimum operating system requirement for this CSP is Windows 10, version 2004. This CSP is supported only in Microsoft Surface Hub prior to Window 10, version 2004.
+> The NetworkQoSPolicy configuration service provider is officially supported for devices that are Intune managed and Azure AD joined. Currently, this CSP is not supported on the following devices:
+> - Azure AD Hybrid joined devices.
+> - Devices that use both GPO and CSP at the same time.
+> 
+> The minimum operating system requirement for this CSP is Windows 10, version 2004. This CSP is supported only in Microsoft Surface Hub prior to Window 10, version 2004.
 
 The following shows the NetworkQoSPolicy configuration service provider in tree format.
 ```

windows/deployment/update/waas-manage-updates-wsus.md

@@ -172,6 +172,7 @@ You can now see these computers in the **Ring 3 Broad IT** computer group.
 
 
 <span id="wsus-gp"/>
+
 ## Use Group Policy to populate deployment rings
 
 The WSUS Administration Console provides a friendly interface from which you can manage Windows 10 quality and feature updates. When you need to add many computers to their correct WSUS deployment ring, however, it can be time-consuming to do so manually in the WSUS Administration Console. For these cases, consider using Group Policy to target the correct computers, automatically adding them to the correct WSUS deployment ring based on an Active Directory security group. This process is called *client-side targeting*. Before enabling client-side targeting in Group Policy, you must configure WSUS to accept Group Policy computer assignment.
@@ -357,4 +358,4 @@ Now that you have the **All Windows 10 Upgrades** view, complete the following s
 - [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)
 - [Deploy Windows 10 updates using Microsoft Endpoint Configuration Manager](/mem/configmgr/osd/deploy-use/manage-windows-as-a-service)
-- [Manage device restarts after updates](waas-restart.md)
+- [Manage device restarts after updates](waas-restart.md)

windows/security/identity-protection/smart-cards/smart-card-debugging-information.md

@@ -57,7 +57,7 @@ To delete a container, type **certutil -delkey -csp "Microsoft Base Smart Card C
 
 ## Debugging and tracing using WPP
 
-WPP simplifies tracing the operation of the trace provider. It provides a mechanism for the trace provider to log real-time binary messages. Logged messages can be converted to a human-readable trace of the operation. For more information, see [Diagnostics with WPP - The NDIS blog](https://blogs.msdn.com/b/ndis/archive/2011/04/06/diagnostics-with-wpp.aspx).
+WPP simplifies tracing the operation of the trace provider. It provides a mechanism for the trace provider to log real-time binary messages. Logged messages can be converted to a human-readable trace of the operation. For more information, see [Diagnostics with WPP - The NDIS blog](/archive/blogs/ndis/diagnostics-with-wpp).
 
 ### Enable the trace
 
@@ -247,4 +247,4 @@ For more information about CryptoAPI 2.0 Diagnostics, see [Troubleshooting an En
 
 ## See also
 
-[Smart Card Technical Reference](smart-card-windows-smart-card-technical-reference.md)
+[Smart Card Technical Reference](smart-card-windows-smart-card-technical-reference.md)

windows/security/threat-protection/windows-defender-application-control/deploy-windows-defender-application-control-policies-using-intune.md

@@ -68,6 +68,9 @@ The steps to use Intune's custom OMA-URI functionality are:
     > [!div class="mx-imgBorder"]
     > ![Configure custom WDAC](images/wdac-intune-custom-oma-uri.png)
 
+> [!NOTE]
+> For the _Policy GUID_ value do not include the curly brackets. 
+
 ### Remove WDAC policies on Windows 10 1903+
 
 Upon deletion, policies deployed through Intune via the ApplicationControl CSP are removed from the system but stay in effect until the next reboot. In order to disable WDAC enforcement, first replace the existing policy with a new version of the policy that will "Allow *", like the rules in the example  policy at %windir%\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml. Once the updated policy is deployed, you can then delete the policy from the Intune portal. This will prevent anything from being blocked and fully remove the WDAC policy on the next reboot.