diff --git a/windows/client-management/mdm/device-update-management.md b/windows/client-management/mdm/device-update-management.md index 00d784cb32..e2a6fc0027 100644 --- a/windows/client-management/mdm/device-update-management.md +++ b/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 `./Vendor/MSFT/Update/InstallableUpdates?list=StructData`. 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). ## Examples of update metadata XML structure and element descriptions diff --git a/windows/client-management/mdm/networkqospolicy-csp.md b/windows/client-management/mdm/networkqospolicy-csp.md index 3c523ba304..f0fadc3fe5 100644 --- a/windows/client-management/mdm/networkqospolicy-csp.md +++ b/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. ``` diff --git a/windows/deployment/update/waas-manage-updates-wsus.md b/windows/deployment/update/waas-manage-updates-wsus.md index ce105012f6..c41a64b71e 100644 --- a/windows/deployment/update/waas-manage-updates-wsus.md +++ b/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. + ## 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) \ No newline at end of file +- [Manage device restarts after updates](waas-restart.md) diff --git a/windows/security/identity-protection/smart-cards/smart-card-debugging-information.md b/windows/security/identity-protection/smart-cards/smart-card-debugging-information.md index 1135c404d0..a084d3c132 100644 --- a/windows/security/identity-protection/smart-cards/smart-card-debugging-information.md +++ b/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) \ No newline at end of file +[Smart Card Technical Reference](smart-card-windows-smart-card-technical-reference.md) diff --git a/windows/security/threat-protection/windows-defender-application-control/deploy-windows-defender-application-control-policies-using-intune.md b/windows/security/threat-protection/windows-defender-application-control/deploy-windows-defender-application-control-policies-using-intune.md index e9fddbd043..7bbc0ca8ab 100644 --- a/windows/security/threat-protection/windows-defender-application-control/deploy-windows-defender-application-control-policies-using-intune.md +++ b/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.