Acro-updates

windows/client-management/azure-active-directory-integration-with-mdm.md

@@ -48,7 +48,7 @@ Azure AD MDM enrollment is a two-step process:
 
 To support Azure AD enrollment, MDM vendors must host and expose a **Terms of Use endpoint** and an **MDM enrollment endpoint**.
 
-- **Terms of Use endpoint**: Use this endpoint to inform users of the ways in which their device can be controlled by their organization. The Terms of Use page is responsible for collecting user's consent before the actual enrollment phase begins.
+- **Terms of Use endpoint**: Use this endpoint to inform users of the ways in which their organization can control their device. The **Terms of Use** page is responsible for collecting user's consent before the actual enrollment phase begins.
 
     It's important to understand the Terms of Use flow is an "opaque box" to Windows and Azure AD. The whole web view is redirected to the Terms of Use URL. The user should be redirected back after approving or rejecting the Terms. This design allows the MDM vendor to customize their Terms of Use for different scenarios. For example, different levels of control are applied on BYOD vs. organization-owned devices. Or, implement user/group based targeting, like users in certain geographies may have stricter device management policies.
 
@@ -73,7 +73,7 @@ A cloud-based MDM is a SaaS application that provides device management capabili
 The MDM vendor must first register the application in their home tenant and mark it as a multi-tenant application. For more information about how to add multi-tenant applications to Azure AD, see the [Integrate an app that authenticates users and calls Microsoft Graph using the multi-tenant integration pattern (SaaS)](https://go.microsoft.com/fwlink/p/?LinkId=613661) code sample on GitHub.
 
 > [!NOTE]
-> For the MDM provider, if you don't have an existing Azure AD tenant with an Azure AD subscription that you manage, follow the step-by-step guides below:
+> For the MDM provider, if you don't have an existing Azure AD tenant with an Azure AD subscription that you manage, follow these step-by-step guides:
 >
 > - [Quickstart: Create a new tenant in Azure Active Directory](/azure/active-directory/fundamentals/active-directory-access-create-new-tenant) to set up a tenant.
 > - [Associate or add an Azure subscription to your Azure Active Directory tenant](/azure/active-directory/fundamentals/active-directory-how-subscriptions-associated-directory) to add a subscription, and manage it via the Azure Portal.
@@ -97,11 +97,11 @@ For more information about registering applications with Azure AD, see [Basics o
 
 The application keys used by your MDM service are a sensitive resource. They should be protected and rolled over periodically for greater security. Access tokens obtained by your MDM service to call the Microsoft Graph API are bearer tokens and should be protected to avoid unauthorized disclosure.
 
-For security best practices, see [Windows Azure Security Essentials](/dotnet/api/system.identitymodel.tokens.jwt.jwtsecuritytokenhandler).
+For security best practices, see [Microsoft Azure Security Essentials](/dotnet/api/system.identitymodel.tokens.jwt.jwtsecuritytokenhandler).
 
-For cloud-based MDM, you can roll over the application keys without requiring a customer interaction. There's a single set of keys across all customer tenants that are managed by the MDM vendor in their Azure AD tenant.
+For cloud-based MDM, you can roll over the application keys without requiring a customer interaction. There's a single set of keys across all customer tenants managed by the MDM vendor in their Azure AD tenant.
 
-For the on-premises MDM, the Azure AD authentication keys are within the customer tenant and must be rolled over by the customer's administrator. To improve security, provide guidance to customers about rolling over and protecting the keys.
+For the on-premises MDM, the Azure AD authentication keys are within the customer tenant and the customer's administrator must roll over the keys. To improve security, provide guidance to customers about rolling over and protecting the keys.
 
 ## Publish your MDM app to Azure AD app gallery
 
@@ -117,7 +117,7 @@ To publish your application, [submit a request to publish your application in Az
 The following table shows the required information to create an entry in the Azure AD app gallery.
 
 | Item                | Description                                                                                                                                                                                                    |
-|--- |--- |
+|---------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | **Application ID**  | The client ID of your MDM app that is configured within your tenant. This ID is the unique identifier for your multi-tenant app.                                                                               |
 | **Publisher**       | A string that identifies the publisher of the app.                                                                                                                                                             |
 | **Application URL** | A URL to the landing page of your app where your administrators can get more information about the MDM app and contains a link to the landing page of your app. This URL isn't used for the actual enrollment. |
@@ -128,11 +128,11 @@ The following table shows the required information to create an entry in the Azu
 
 There are no special requirements for adding on-premises MDM to the app gallery. There's a generic entry for administrators to add an app to their tenant.
 
-However, key management is different for on-premises MDM. You must obtain the client ID (app ID) and key assigned to the MDM app within the customer's tenant. The ID and key obtain authorization to access the Microsoft Graph API and for reporting device compliance.
+However, key management is different for on-premises MDM. You must obtain the client ID (app ID) and key assigned to the MDM app within the customer's tenant. The ID and key obtain authorization to access the Microsoft Graph API and  report device compliance.
 
 ## Themes
 
-The pages rendered by the MDM in the integrated enrollment process must use Windows templates ([Download the Windows templates and CSS files (1.1.4)](https://download.microsoft.com/download/0/7/0/0702afe3-dc1e-48f6-943e-886a4876f6ca/MDM-ISV_1.1.4.zip)). These templates are important for enrollment during the Azure AD Join experience in OOBE where all of the pages are edge-to-edge HTML pages. Don't try to copy the templates because you'll never get the button placement right.
+The pages rendered by the MDM in the integrated enrollment process must use Windows templates ([Download the Windows templates and CSS files (1.1.4)](https://download.microsoft.com/download/0/7/0/0702afe3-dc1e-48f6-943e-886a4876f6ca/MDM-ISV_1.1.4.zip)). These templates are important for enrollment during the Azure AD Join experience in OOBE where all of the pages are edge-to-edge HTML pages. Avoid copying the templates because it is difficult to get the button placement right.
 
 There are three distinct scenarios:
 
@@ -158,7 +158,7 @@ An MDM page must adhere to a predefined theme depending on the scenario that is
 
 ## Terms of Use protocol semantics
 
-The Terms of Use endpoint is hosted by the MDM server. During the Azure AD Join protocol flow, Windows does a full-page redirect to this endpoint. This redirect enables the MDM to display the terms and conditions that apply. It allows the user to accept or reject the terms associated with enrollment. After the user accepts the terms, the MDM redirects back to Windows for the enrollment process to continue.
+The MDM server hosts the **Terms of Use** endpoint. During the Azure AD Join protocol flow, Windows does a full-page redirect to this endpoint. This redirect enables the MDM to display the terms and conditions that apply. It allows the user to accept or reject the terms associated with enrollment. After the user accepts the terms, the MDM redirects back to Windows for the enrollment process to continue.
 
 ### Redirect to the Terms of Use endpoint
 
@@ -167,7 +167,7 @@ This redirect is a full page redirect to the Terms of User endpoint hosted by th
 The following parameters are passed in the query string:
 
 | Item              | Description                                                                                                                                                                                  |
-|--- |--- |
+|-------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | redirect_uri      | After the user accepts or rejects the Terms of Use, the user is redirected to this URL.                                                                                                      |
 | client-request-id | A GUID that is used to correlate logs for diagnostic and debugging purposes. Use this parameter to log or trace the state of the enrollment request to help find the root cause of failures. |
 | api-version       | Specifies the version of the protocol requested by the client. This value provides a mechanism to support version revisions of the protocol.                                                 |
@@ -182,7 +182,7 @@ Azure AD issues a bearer access token. The token is passed in the authorization
 The following claims are expected in the access token passed by Windows to the Terms of Use endpoint:
 
 | Item      | Description                                                                                  |
-|--- |--- |
+|-----------|----------------------------------------------------------------------------------------------|
 | Object ID | Identifier of the user object corresponding to the authenticated user.                       |
 | UPN       | A claim containing the user principal name (UPN) of the authenticated user.                  |
 | TID       | A claim representing the tenant ID of the tenant. In the example above, it's Fabrikam.       |
@@ -200,7 +200,7 @@ https://fabrikam.contosomdm.com/TermsOfUse?redirect_uri=ms-appx-web://ContosoMdm
 Authorization: Bearer eyJ0eXAiOi
 ```
 
-The MDM is expected to validate the signature of the access token to ensure it was issued by Azure AD and ensure that recipient is appropriate.
+The MDM is expected to validate the signature of the access token to ensure it is issued by Azure AD and that the recipient is appropriate.
 
 ### Terms of Use content
 
@@ -225,7 +225,7 @@ At this point, the user is on the Terms of Use page shown during the OOBE or fro
   - **IsAccepted** - This Boolean value is required, and must be set to false. This option also applies if the user skipped the Terms of Use.
   - **OpaqueBlob** - This parameter isn't expected to be used. The enrollment is stopped with an error message shown to the user.
 
-Users skip the Terms of Use when they're adding a Microsoft work account to their device. However, they can't skip it during the Azure AD Join process. Don't show the decline button in the Azure AD Join process. MDM enrollment can't be declined by the user if configured by the administrator for the Azure AD Join.
+Users skip the Terms of Use when they're adding a Microsoft work account to their device. However, they can't skip it during the Azure AD Join process. Don't show the decline button in the Azure AD Join process. The user can't decline the MDM enrollment if configured by the administrator for the Azure AD Join.
 
 We recommend that you send the client-request-id parameters in the query string as part of this redirect response.
 
@@ -282,7 +282,7 @@ There are two different MDM enrollment types that integrate with Azure AD, and u
 
 - **Multiple user management for Azure AD-joined devices**
 
-  In this scenario the MDM enrollment applies to every Azure AD user who signs in to the Azure AD joined device - call this enrollment type a device enrollment or a multi-user enrollment. The management server can determine the user identity, determine what policies are targeted for this user, and send corresponding policies to the device. To allow management server to identify current user that is logged on to the device, the OMA DM client uses the Azure AD user tokens. Each management session contains an extra HTTP header that contains an Azure AD user token. This information is provided in the DM package sent to the management server. However, in some circumstances Azure AD user token isn't sent over to the management server. One such scenario happens immediately after MDM enrollments completes during Azure AD join process. Until Azure AD join process is finished and Azure AD user signs on to the machine, Azure AD user token isn't available to OMA-DM process. Typically, MDM enrollment completes before Azure AD user sign in to machine and the initial management session doesn't contain an Azure AD user token. The management server should check if the token is missing and only send device policies in such case. Another possible reason for a missing Azure AD token in the OMA-DM payload is when a guest user is logged on to the device.
+  In this scenario, the MDM enrollment applies to every Azure AD user who signs in to the Azure AD joined device - call this enrollment type a device enrollment or a multi-user enrollment. The management server can determine the user identity, determine what policies are targeted for this user, and send corresponding policies to the device. To allow management server to identify current user that is logged on to the device, the OMA DM client uses the Azure AD user tokens. Each management session contains an extra HTTP header that contains an Azure AD user token. This information is provided in the DM package sent to the management server. However, in some circumstances Azure AD user token isn't sent over to the management server. One such scenario happens immediately after MDM enrollments completes during Azure AD join process. Until Azure AD join process is finished and Azure AD user signs on to the machine, Azure AD user token isn't available to OMA-DM process. Typically, MDM enrollment completes before Azure AD user sign in to machine and the initial management session doesn't contain an Azure AD user token. The management server should check if the token is missing and only send device policies in such case. Another possible reason for a missing Azure AD token in the OMA-DM payload is when a guest is logged on to the device.
 
 - **Adding a work account and MDM enrollment to a device**:
 
@@ -303,7 +303,7 @@ There are two different MDM enrollment types that integrate with Azure AD, and u
   - Device ID - identifies the device that is checking in
   - Tenant ID
 
-  Access tokens issued by Azure AD are JSON web tokens (JWTs). A valid JWT token is presented by Windows at the MDM enrollment endpoint to start the enrollment process. There are a couple of options to evaluate the tokens:
+  Access tokens issued by Azure AD are JSON web tokens (JWTs). Windows presents a valid JWT token to the MDM enrollment endpoint to start the enrollment process. There are a couple of options to evaluate the tokens:
 
   - Use the JWT Token Handler extension for WIF to validate the contents of the access token and extract claims required for use. For more information, see [JwtSecurityTokenHandler Class](/dotnet/api/system.identitymodel.tokens.jwt.jwtsecuritytokenhandler).
   - Refer to the Azure AD authentication code samples to get a sample for working with access tokens. For an example, see [NativeClient-DotNet](https://go.microsoft.com/fwlink/p/?LinkId=613667).
@@ -335,8 +335,8 @@ Alert sample:
 
 An alert is sent to the MDM server in DM package \#1.
 
-- Alert type - com.microsoft/MDM/LoginStatus
+- Alert type - `com.microsoft/MDM/LoginStatus`
-- Alert format - chr
+- Alert format - `chr`
 - Alert data - provide sign-in status information for the current active logged in user.
   - Signed-in user who has an Azure AD account - predefined text: user.
   - Signed-in user without an Azure AD account- predefined text: others.
@@ -362,7 +362,7 @@ Here's an example.
 
 ## Report device compliance to Azure AD
 
-Once a device is enrolled with the MDM for management, organization policies configured by the IT administrator are enforced on the device. The device compliance with configured policies is evaluated by the MDM and then reported to Azure AD. This section covers the Graph API call you can use to report a device compliance status to Azure AD.
+Once a device is enrolled with the MDM for management, organization policies configured by the IT administrator are enforced on the device. MDM evaluates the device compliance with configured policies and then reports it to Azure AD. This section covers the Graph API call you can use to report a device compliance status to Azure AD.
 
 For a sample that illustrates how an MDM can obtain an access token using OAuth 2.0 client\_credentials grant type, see [Daemon\_CertificateCredential-DotNet](https://go.microsoft.com/fwlink/p/?LinkId=613822).
 
@@ -371,7 +371,7 @@ For a sample that illustrates how an MDM can obtain an access token using OAuth
 
 ### Use Microsoft Graph API
 
-The following sample REST API call illustrates how an MDM can use the Microsoft Graph API to report compliance status of a device being managed by it.
+The following sample REST API call illustrates how an MDM can use the Microsoft Graph API to report compliance status of a managed device.
 
 > [!NOTE]
 > This API is only applicable for approved MDM apps on Windows devices.

windows/client-management/azure-ad-and-microsoft-intune-automatic-mdm-enrollment-in-the-new-portal.md

@@ -7,14 +7,12 @@ ms.date: 08/10/2023
 
 # Automatic MDM enrollment in the Intune admin center
 
-Windows devices can be enrolled in to Intune automatically when they join or register with Azure Active Directory. Automatic enrollment can be configured in Azure Portal.
+Windows devices can be enrolled in to Intune automatically when they join or register with Azure Active Directory. Automatic enrollment can be configured in Azure portal.
-
-1. Go to your Azure AD Blade.
 
+1. Go to your Azure AD portal.
 1. Select **Mobility (MDM and MAM)**, and find the Microsoft Intune app.
-
+1. Select **Microsoft Intune** and configure the enrollment options. You can specify settings to allow **All** users to enroll a device, or choose to allow **Some** users (and specify a group).
-1. Select **Microsoft Intune** and configure the blade. You can specify settings to allow **All** users to enroll a device, or choose to allow **Some** users (and specify a group).
 
    ![Configure the Blade.](images/azure-intune-configure-scope.png)
 
-1. Select **Save** to configure MDM auto-enrollment for Azure AD joined devices and bring-your-own-device scenarios.
+1. Select **Save** to configure MDM autoenrollment for Azure AD joined devices and bring-your-own-device scenarios.

windows/client-management/bulk-enrollment-using-windows-provisioning-tool.md

@@ -1,17 +1,17 @@
 ---
 title: Bulk enrollment
-description: Bulk enrollment is an efficient way to set up a large number of devices to be managed by an MDM server without the need to re-image the devices.
+description: Bulk enrollment is an efficient way to set up a large number of devices to be managed by an MDM server without the need to reimage the devices.
 ms.topic: article
 ms.date: 08/10/2023
 ---
 
 # Bulk enrollment using Windows Configuration Designer
 
-Bulk enrollment is an efficient way to set up a large number of devices to be managed by an MDM server without the need to re-image the devices. You can use the [Provisioning CSP](mdm/provisioning-csp.md) for bulk enrollment, except for the Azure Active Directory Join enrollment scenario.
+Bulk enrollment is an efficient way to set up a large number of devices to be managed by an MDM server without the need to reimage the devices. You can use the [Provisioning CSP](mdm/provisioning-csp.md) for bulk enrollment, except for the Azure Active Directory Join enrollment scenario.
 
 ## Typical use cases
 
-- Set up devices in bulk for large organizations to be managed by MDM.
+- Set up devices in bulk for large organizations for MDM management.
 - Set up kiosks, such as ATMs or point-of-sale (POS) terminals.
 - Set up school computers.
 - Set up industrial machinery.
@@ -121,7 +121,7 @@ Using the WCD, create a provisioning package using the enrollment information re
 
 1. Configure the other settings, such as the Wi-Fi connection so that the device can join a network before joining MDM (for example, **Runtime settings** > **ConnectivityProfiles** > **WLANSetting**).
 1. When you're done adding all the settings, on the **File** menu, select **Save**.
-1. Export and build the package (steps 10-13 in the procedure above).
+1. Export and build the package (steps 10-13 in previous section).
 1. Apply the package to some test devices and verify that they work. For more information, see [Apply a provisioning package](#apply-a-provisioning-package).
 1. Apply the package to your devices.
 
@@ -139,9 +139,9 @@ Using the WCD, create a provisioning package using the enrollment information re
 
 ## Retry logic if there's a failure
 
-- If the provisioning engine receives a failure from a CSP, it will retry to provision three times in a row.
+- If the provisioning engine receives a failure from a CSP, it retries provisioning three times in a row.
-- If all immediate attempts fail, a delayed task is launched to try provisioning again later. It will retry four times at a decaying rate of 15 minutes -> 1 hr -> 4 hr -> "Next System Start". These attempts will be run from the SYSTEM context.
+- If all immediate attempts fail, a delayed task is launched to try provisioning again later. It will retry four times at a decaying rate of 15 minutes -> 1 hr -> 4 hr -> "Next System Start". These attempts are run from the SYSTEM context.
-- It will also retry to apply the provisioning each time it's launched, if started from somewhere else as well.
+- It also retries the provisioning each time it's launched, if started from somewhere else as well.
 - In addition, provisioning will be restarted in the SYSTEM context after a sign in and the [system has been idle](/windows/win32/taskschd/task-idle-conditions).
 
 ## Related articles

windows/client-management/certificate-renewal-windows-mdm.md

@@ -23,11 +23,11 @@ Auto certificate renewal is the only supported MDM client certificate renewal me
 
 For Windows devices, during the MDM client certificate enrollment phase or during MDM management section, the enrollment server or MDM server could configure the device to support automatic MDM client certificate renewal using [CertificateStore CSP's](mdm/certificatestore-csp.md) ROBOSupport node under `CertificateStore/My/WSTEP/Renew` URL.
 
-With automatic renewal, the PKCS#7 message content isn't base64 encoded separately. With manual certificate renewal, there's an additional base64 encoding for PKCS#7 message content.
+With automatic renewal, the PKCS#7 message content isn't base64 encoded separately. With manual certificate renewal, base64 encoding for PKCS#7 message content is required.
 
-During the automatic certificate renewal process, if the root certificate isn't trusted by the device, the authentication will fail. Use one of device pre-installed root certificates, or configure the root cert over a DM session using the [CertificateStore CSP](mdm/certificatestore-csp.md).
+During the automatic certificate renewal process, if the device doesn't trust the root certificate, the authentication fails. Use one of device preinstalled root certificates, or configure the root cert over a DM session using the [CertificateStore CSP](mdm/certificatestore-csp.md).
 
-During the automatic certificate renew process, the device will deny HTTP redirect request from the server. It won't deny the request if the same redirect URL that the user accepted during the initial MDM enrollment process is used.
+During the automatic certificate renewal process, the device denies HTTP redirect request from the server. It doesn't deny the request if the same redirect URL that the user accepted during the initial MDM enrollment process is used.
 
 The following example shows the details of an automatic renewal request.
 
@@ -89,15 +89,15 @@ In Windows, the renewal period can only be set during the MDM enrollment phase.
 
 For more information about the parameters, see the [CertificateStore configuration service provider](mdm/certificatestore-csp.md).
 
-Unlike manual certificate renewal, the device will not do an automatic MDM client certificate renewal if the certificate is already expired. To make sure the device has enough time to automatically renew, we recommend you set a renewal period a couple months (40-60 days) before the certificate expires. And, set the renewal retry interval to every few days, like every 4-5 days instead of every 7 days (weekly). This change increases the chance that the device will try to connect at different days of the week.
+Unlike manual certificate renewal, the device doesn't perform an automatic MDM client certificate renewal if the certificate is already expired. To make sure the device has enough time to automatically renew, we recommend you set a renewal period a couple months (40-60 days) before the certificate expires. And, set the renewal retry interval to every few days, like every 4-5 days instead of every seven days (weekly). This change increases the chance that the device will try to connect at different days of the week.
 
 ## Certificate renewal response
 
-When RequestType is set to Renew, the web service verifies the following (in additional to initial enrollment):
+When RequestType is set to Renew, the web service verifies the following (in addition to the initial enrollment):
 
 - The signature of the PKCS#7 BinarySecurityToken is correct
 - The client's certificate is in the renewal period
-- The certificate was issued by the enrollment service
+- The certificate is issued by the enrollment service
 - The requester is the same as the requester for initial enrollment
 - For standard client's request, the client hasn't been blocked
 

windows/client-management/client-tools/administrative-tools-in-windows.md

@@ -62,6 +62,6 @@ These tools were included in previous versions of Windows. The associated docume
 > [!TIP]
 > If the linked content in this list doesn't provide the information you need to use that tool, send feedback with the **This page** link in the **Feedback** section at the bottom of this article.
 
-## Related topics
+## Related articles
 
 [Diagnostic data viewer](/windows/privacy/diagnostic-data-viewer-overview)

windows/client-management/client-tools/change-default-removal-policy-external-storage-media.md

@@ -16,7 +16,7 @@ You can change the policy setting for each external device, and the policy that
 
 You can use the storage device policy setting to change the manner in which Windows manages storage devices to better meet your needs. The policy settings have the following effects:
 
-- **Quick removal**: This policy manages storage operations in a manner that keeps the device ready to remove at any time. You can remove the device without using the Safely Remove Hardware process. However, to do this, Windows cannot cache disk write operations. This may degrade system performance.
+- **Quick removal**: This policy manages storage operations in a manner that keeps the device ready to remove at any time. You can remove the device without using the Safely Remove Hardware process. However, to do this, Windows can't cache disk write operations. This may degrade system performance.
 - **Better performance**: This policy manages storage operations in a manner that improves system performance. When this policy is in effect, Windows can cache write operations to the external device. However, you must use the Safely Remove Hardware process to remove the external drive. The Safely Remove Hardware process protects the integrity of data on the device by making sure that all cached operations finish.
 
 > [!IMPORTANT]

windows/client-management/client-tools/manage-device-installation-with-group-policy.md

@@ -56,9 +56,9 @@ The scenarios presented in this guide illustrate how you can control device inst
 |--|--|
 | Scenario #1: Prevent installation of all printers | In this scenario, the administrator wants to prevent users from installing any printers. Thus is a basic scenario to introduce you to the 'prevent/allow' functionality of Device Installation policies in Group Policy. |
 | Scenario #2: Prevent installation of a specific printer | In this scenario, the administrator allows standard users to install all printers while but preventing them from installing a specific one. |
-| Scenario #3: Prevent installation of all printers while allowing a specific printer to be installed | In this scenario, you'll combine what you learned from both scenario #1 and scenario #2. The administrator wants to allow standard users to install only a specific printer while preventing the installation of all other printers. This scenario is a more realistic one and brings you a step farther in understanding of the Device Installation Restrictions policies. |
+| Scenario #3: Prevent installation of all printers while allowing a specific printer to be installed | In this scenario, you combine what you learned from both scenario #1 and scenario #2. The administrator wants to allow standard users to install only a specific printer while preventing the installation of all other printers. This scenario is a more realistic one and brings you a step farther in understanding of the Device Installation Restrictions policies. |
 | Scenario #4: Prevent installation of a specific USB device | This scenario, although similar to scenario #2, brings another layer of complexity-how does device connectivity work in the PnP tree. The administrator wants to prevent standard users from installing a specific USB device. By the end of the scenario, you should understand the way devices are nested in layers under the PnP device connectivity tree. |
-| Scenario #5: Prevent installation of all USB devices while allowing an installation of only an authorized USB thumb drive | In this scenario, combining all previous four scenarios, you'll learn how to protect a machine from all unauthorized USB devices. The administrator wants to allow users to install only a small set of authorized USB devices while preventing any other USB device from being installed. In addition, this scenario includes an explanation of how to apply the 'prevent' functionality to existing USB devices that have already been installed on the machine, and the administrator likes to prevent any farther interaction with them (blocking them all together). This scenario builds on the policies and structure we introduced in the first four scenarios and therefore it's preferred to go over them first before attempting this scenario. |
+| Scenario #5: Prevent installation of all USB devices while allowing an installation of only an authorized USB thumb drive | In this scenario, combining all previous four scenarios, you learn how to protect a machine from all unauthorized USB devices. The administrator wants to allow users to install only a small set of authorized USB devices while preventing any other USB device from being installed. In addition, this scenario includes an explanation of how to apply the 'prevent' functionality to existing USB devices that have already been installed on the machine, and the administrator likes to prevent any farther interaction with them (blocking them all together). This scenario builds on the policies and structure we introduced in the first four scenarios and therefore it's preferred to go over them first before attempting this scenario. |
 
 ## Technology Review
 
@@ -95,7 +95,7 @@ Hardware IDs are the identifiers that provide the exact match between a device a
 
 Windows uses these identifiers to select a driver if the operating system can't find a match with the device ID or any of the other hardware IDs. Compatible IDs are listed in the order of decreasing suitability. These strings are optional, and, when provided, they're generic, such as Disk. When a match is made using a compatible ID, you can typically use only the most basic functions of the device.
 
-When you install a device, such as a printer, a USB storage device, or a keyboard, Windows searches for driver packages that match the device you are attempting to install. During this search, Windows assigns a "rank" to each driver package it discovers with at least one match to a hardware or compatible ID. The rank indicates how well the driver matches the device. Lower rank numbers indicate better matches between the driver and the device. A rank of zero represents the best possible match. A match with the device ID to one in the driver package results in a lower (better) rank than a match to one of the other hardware IDs. Similarly, a match to a hardware ID results in a better rank than a match to any of the compatible IDs. After Windows ranks all of the driver packages, it installs the one with the lowest overall rank. For more information about the process of ranking and selecting driver packages, see [How Windows selects a driver package for a device](/windows-hardware/drivers/install/how-windows-selects-a-driver-for-a-device).
+When you install a device, such as a printer, a USB storage device, or a keyboard, Windows searches for driver packages that match the device you're attempting to install. During this search, Windows assigns a "rank" to each driver package it discovers with at least one match to a hardware or compatible ID. The rank indicates how well the driver matches the device. Lower rank numbers indicate better matches between the driver and the device. A rank of zero represents the best possible match. A match with the device ID to one in the driver package results in a lower (better) rank than a match to one of the other hardware IDs. Similarly, a match to a hardware ID results in a better rank than a match to any of the compatible IDs. After Windows ranks all of the driver packages, it installs the one with the lowest overall rank. For more information about the process of ranking and selecting driver packages, see [How Windows selects a driver package for a device](/windows-hardware/drivers/install/how-windows-selects-a-driver-for-a-device).
 
 > [!NOTE]
 > For more information about the driver installation process, see the "Technology review" section of the Step-by-Step Guide to Driver Signing and Staging.
@@ -168,7 +168,7 @@ Note: This policy setting takes precedence over any other policy settings that a
 
 ### Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria
 
-This policy setting will change the evaluation order in which Allow and Prevent policy settings are applied when more than one install policy setting is applicable for a given device. Enable this policy setting to ensure that overlapping device match criteria is applied based on an established hierarchy where more specific match criteria supersedes less specific match criteria. The hierarchical order of evaluation for policy settings that specify device match criteria is as follows:
+This policy setting changes the evaluation order in which Allow and Prevent policy settings are applied when more than one install policy setting is applicable for a given device. Enable this policy setting to ensure that overlapping device match criteria is applied based on an established hierarchy where more specific match criteria supersedes less specific match criteria. The hierarchical order of evaluation for policy settings that specify device match criteria is as follows:
 
 > **Device instance IDs** > **Device IDs** > **Device setup class** > **Removable devices**
 
@@ -177,7 +177,7 @@ This policy setting will change the evaluation order in which Allow and Prevent
 >
 > If you disable or don't configure this policy setting, the default evaluation is used. By default, all "Prevent installation..." policy settings have precedence over any other policy setting that allows Windows to install a device.
 
-Some of these policies take precedence over other policies. The flowchart shown below illustrates how Windows processes them to determine whether a user can install a device or not, as shown in Figure below.
+Some of these policies take precedence over other policies. The following flowchart illustrates how Windows processes them to determine whether a user can install a device or not.
 
 ![Device Installation policies flow chart.](images/device-installation-flowchart.png)<br/>_Device Installation policies flow chart_
 
@@ -216,7 +216,7 @@ To find device identification strings using Device Manager
 
 1. Make sure your printer is plugged in and installed.
 
-1. To open Device Manager, click the Start button, type mmc devmgmt.msc in the Start Search box, and then press ENTER; or search for Device Manager as application.
+1. To open Device Manager, select the Start button, type mmc devmgmt.msc in the Start Search box, and then press ENTER; or search for Device Manager as application.
 
 1. Device Manager starts and displays a tree representing all of the devices detected on your computer. At the top of the tree is a node with your computers name next to it. Lower nodes represent the various categories of hardware into which your computers devices are grouped.
 
@@ -317,9 +317,9 @@ Creating the policy to prevent all printers from being installed:
 
 1. Open **Prevent installation of devices using drivers that match these device setup classes** policy and select the 'Enable' radio button.
 
-1. In the lower left side, in the 'Options' window, click the 'Show...' box. This option will take you to a table where you can enter the class identifier to block.
+1. In the lower left side, in the 'Options' window, click the 'Show...' box. This option takes you to a table where you can enter the class identifier to block.
 
-1. Enter the printer class GUID you found above with the curly braces: `{4d36e979-e325-11ce-bfc1-08002be10318}`.
+1. Enter the printer class GUID you found with the curly braces: `{4d36e979-e325-11ce-bfc1-08002be10318}`.
 
     ![List of prevent Class GUIDs](images/device-installation-gpo-prevent-class-list.png)<br/>_List of prevent Class GUIDs_
 

windows/client-management/client-tools/mandatory-user-profile.md

@@ -10,17 +10,17 @@ ms.collection:
 
 # Create mandatory user profiles
 
-A mandatory user profile is a roaming user profile that has been pre-configured by an administrator to specify settings for users. Settings commonly defined in a mandatory profile include (but are not limited to) icons that appear on the desktop, desktop backgrounds, user preferences in Control Panel, printer selections, and more. Configuration changes made during a user's session that are normally saved to a roaming user profile are not saved when a mandatory user profile is assigned.
+A mandatory user profile is a roaming user profile that has been pre-configured by an administrator to specify settings for users. Settings commonly defined in a mandatory profile include (but aren't limited to) icons that appear on the desktop, desktop backgrounds, user preferences in Control Panel, printer selections, and more. Configuration changes made during a user's session that are normally saved to a roaming user profile aren't saved when a mandatory user profile is assigned.
 
 Mandatory user profiles are useful when standardization is important, such as on a kiosk device or in educational settings. Only system administrators can make changes to mandatory user profiles.
 
-When the server that stores the mandatory profile is unavailable, such as when the user is not connected to the corporate network, users with mandatory profiles can sign in with the locally cached copy of the mandatory profile, if one exists. Otherwise, the user will be signed in with a temporary profile.
+When the server that stores the mandatory profile is unavailable, such as when the user isn't connected to the corporate network, users with mandatory profiles can sign in with the locally cached copy of the mandatory profile, if one exists. Otherwise, the user is signed in with a temporary profile.
 
 User profiles become mandatory profiles when the administrator renames the `NTuser.dat` file (the registry hive) of each user's profile in the file system of the profile server from `NTuser.dat` to `NTuser.man`. The `.man` extension causes the user profile to be a read-only profile.
 
 ## Profile extension for each Windows version
 
-The name of the folder in which you store the mandatory profile must use the correct extension for the operating system it will be applied to. The following table lists the correct extension for each operating system version.
+The name of the folder in which you store the mandatory profile must use the correct extension for the operating system it applies to. The following table lists the correct extension for each operating system version.
 
 | Client operating system version     | Server operating system version                 | Profile extension |
 |-------------------------------------|-------------------------------------------------|-------------------|
@@ -39,7 +39,7 @@ First, you create a default user profile with the customizations that you want,
 
 ### How to create a default user profile
 
-1. Sign in to a computer running Windows as a member of the local Administrator group. Do not use a domain account.
+1. Sign in to a computer running Windows as a member of the local Administrator group. Don't use a domain account.
 
    > [!NOTE]
    > Use a lab or extra computer running a clean installation of Windows to create a default user profile. Do not use a computer that is required for business (that is, a production computer). This process removes all domain accounts from the computer, including user profile folders.
@@ -51,7 +51,7 @@ First, you create a default user profile with the customizations that you want,
 
 1. [Create an answer file (Unattend.xml)](/windows-hardware/customize/desktop/wsim/create-or-open-an-answer-file) that sets the [CopyProfile](/windows-hardware/customize/desktop/unattend/microsoft-windows-shell-setup-copyprofile) parameter to **True**. The CopyProfile parameter causes Sysprep to copy the currently signed-on user's profile folder to the default user profile. You can use [Windows System Image Manager](/windows-hardware/customize/desktop/wsim/windows-system-image-manager-technical-reference), which is part of the Windows Assessment and Deployment Kit (ADK) to create the Unattend.xml file.
 
-1. Uninstall any application you do not need or want from the PC. For examples on how to uninstall Windows Application see [Remove-AppxProvisionedPackage](/powershell/module/dism/remove-appxprovisionedpackage?view=win10-ps&preserve-view=true). For a list of uninstallable applications, see [Understand the different apps included in Windows](/windows/application-management/apps-in-windows-10).
+1. Uninstall any application you don't need or want from the PC. For examples on how to uninstall Windows Application see [Remove-AppxProvisionedPackage](/powershell/module/dism/remove-appxprovisionedpackage?view=win10-ps&preserve-view=true). For a list of uninstallable applications, see [Understand the different apps included in Windows](/windows/application-management/apps-in-windows-10).
 
    > [!NOTE]
    > It is highly recommended to uninstall unwanted or unneeded apps as it will speed up user sign-in times.
@@ -73,27 +73,27 @@ First, you create a default user profile with the customizations that you want,
 
 1. The sysprep process reboots the PC and starts at the first-run experience screen. Complete the setup, and then sign in to the computer using an account that has local administrator privileges.
 
-1. Right-click Start, go to **Control Panel** (view by large or small icons) > **System** > **Advanced system settings**, and click **Settings** in the **User Profiles** section.
+1. Right-click Start, go to **Control Panel** (view by large or small icons) > **System** > **Advanced system settings**, and select **Settings** in the **User Profiles** section.
 
-1. In **User Profiles**, click **Default Profile**, and then click **Copy To**.
+1. In **User Profiles**, select **Default Profile**, and then select **Copy To**.
 
    ![Example of User Profiles UI.](images/copy-to.png)
 
-1. In **Copy To**, under **Permitted to use**, click **Change**.
+1. In **Copy To**, under **Permitted to use**, select **Change**.
 
    ![Example of Copy To UI.](images/copy-to-change.png)
 
-1. In **Select User or Group**, in the **Enter the object name to select** field, type `everyone`, click **Check Names**, and then click **OK**.
+1. In **Select User or Group**, in the **Enter the object name to select** field, type `everyone`, select **Check Names**, and then select **OK**.
 
 1. In **Copy To**, in the **Copy profile to** field, enter the path and folder name where you want to store the mandatory profile. The folder name must use the correct [extension](#profile-extension-for-each-windows-version) for the operating system version. For example, the folder name must end with `.v6` to identify it as a user profile folder for Windows 10, version 1607 or later.
 
-   - If the device is joined to the domain and you are signed in with an account that has permissions to write to a shared folder on the network, you can enter the shared folder path.
+   - If the device is joined to the domain and you're signed in with an account that has permissions to write to a shared folder on the network, you can enter the shared folder path.
 
      ![Example of Copy profile to.](images/copy-to-path.png)
 
-   - If the device is not joined to the domain, you can save the profile locally and then copy it to the shared folder location.
+   - If the device isn't joined to the domain, you can save the profile locally, and then copy it to the shared folder location.
 
-1. Click **OK** to copy the default user profile.
+1. Select **OK** to copy the default user profile.
 
 ### How to make the user profile mandatory
 
@@ -109,7 +109,7 @@ First, you create a default user profile with the customizations that you want,
 1. Open the properties of the "profile.v6" folder.
 1. Select the **Security** tab and then select **Advanced**.
 1. Verify the **Owner** of the folder. It must be the builtin **Administrators** group. To change the owner, you must be a member of the Administrators group on the file server, or have "Set owner" privilege on the server.
-1. When you set the owner, select **Replace owner on subcontainers and objects** before you click OK.
+1. When you set the owner, select **Replace owner on subcontainers and objects** before you select OK.
 
 ## Apply a mandatory user profile to users
 
@@ -118,10 +118,10 @@ In a domain, you modify properties for the user account to point to the mandator
 ### How to apply a mandatory user profile to users
 
 1. Open **Active Directory Users and Computers** (dsa.msc).
-1. Navigate to the user account that you will assign the mandatory profile to.
+1. Navigate to the user account that you'll assign the mandatory profile to.
 1. Right-click the user name and open **Properties**.
 1. On the **Profile** tab, in the **Profile path** field, enter the path to the shared folder without the extension. For example, if the folder name is `\\server\share\profile.v6`, you would enter `\\server\share\profile`.
-1. Click **OK**.
+1. Select **OK**.
 
 It may take some time for this change to replicate to all domain controllers.
 
@@ -136,9 +136,9 @@ When a user is configured with a mandatory profile, Windows starts as though it
 | Computer Configuration > Administrative Templates > Windows Components > Cloud Content > **Turn off Microsoft consumer experience** = Enabled | ✅         | ❌                 |
 
 > [!NOTE]
-> The Group Policy settings above can be applied in Windows Professional edition.
+> These Group Policy settings can be applied in Windows Professional edition.
 
-## Related topics
+## Related articles
 
 - [Manage Windows 10 Start layout and taskbar options](/windows/configuration/windows-10-start-layout-options-and-policies)
 - [Lock down Windows 10 to specific apps](/windows/configuration/lock-down-windows-10-to-specific-apps)

windows/client-management/client-tools/windows-libraries.md

@@ -11,7 +11,7 @@ Libraries are virtual containers for users' content. A library can contain files
 
 ## Features for Users
 
-Windows libraries are backed by full content search and rich metadata. Libraries offer the following advantages to users:
+Windows libraries provide full content search and rich metadata. Libraries offer the following advantages to users:
 
 - Aggregate content from multiple storage locations into a single, unified presentation.
 - Enable users to stack and group library contents based on metadata.
@@ -51,7 +51,7 @@ Libraries are built upon the legacy known folders (such as My Documents, My Pict
 
 ### Hiding Default Libraries
 
-Users or administrators can hide or delete the default libraries, though the libraries node in the Navigation pane can't be hidden or deleted. Hiding a default library is preferable to deleting it, as applications like Windows Media Player rely on the default libraries and will re-create them if they don't exist on the computer. See [How to Hide Default Libraries](/previous-versions/windows/it-pro/windows-7/ee461108(v=ws.10)#BKMK_HideDefaultLibraries) for instructions.
+Users or administrators can hide or delete the default libraries, though the libraries node in the Navigation pane can't be hidden or deleted. Hiding a default library is preferable to deleting it, as applications like Windows Media Player rely on the default libraries and re-create them if they don't exist on the computer. See [How to Hide Default Libraries](/previous-versions/windows/it-pro/windows-7/ee461108(v=ws.10)#BKMK_HideDefaultLibraries) for instructions.
 
 ### Default Save Locations for Libraries
 
@@ -105,9 +105,7 @@ The following library attributes can be modified within Windows Explorer, the Li
 - Order of library locations
 - Default save location
 
-The library icon can be modified by the administrator or user by directly editing the Library Description schema file.
+The library icon can be modified by the administrator or user by directly editing the Library Description schema file. See [Library Description Schema](/windows/win32/shell/library-schema-entry) for information on creating Library Description files.
-
-See [Library Description Schema](/windows/win32/shell/library-schema-entry) for information on creating Library Description files.
 
 ## See also
 

windows/client-management/client-tools/windows-version-search.md

@@ -11,11 +11,11 @@ The [Long-Term Servicing Channel](/windows/deployment/update/waas-overview#servi
 
 In the [General Availability Channel](/windows/deployment/update/waas-overview#servicing-channels), you can set feature updates as soon as Microsoft releases them. This servicing modal is ideal for pilot deployments and to test Windows feature updates and for users like developers who need to work with the latest features immediately. Once you've tested the latest release, you can choose when to roll it out broadly in your deployment.
 
-To determine if your device is enrolled in the Long-Term Servicing Channel or the General Availability Channel, you'll need to know what version of Windows you're running. There are a few ways to figure this out. Each method provides a different set of details, so it's useful to learn about all of them.
+To determine if your device is enrolled in the Long-Term Servicing Channel or the General Availability Channel, you need to know what version of Windows you're running. There are a few ways to figure this out. Each method provides a different set of details, so it's useful to learn about all of them.
 
 ## System Properties
 
-Select **Start** > **Settings** > **System**, then select **About**. You'll then see **Edition**, **Version**, and **OS Build** information.
+Select **Start** > **Settings** > **System**, then select **About**. You then see **Edition**, **Version**, and **OS Build** information.
 
 :::image type="content" source="images/systemcollage.png" alt-text="screenshot of the system properties window for a device running Windows 10.":::
 
@@ -40,6 +40,6 @@ You can type the following in the search bar and press **ENTER** to see version
 
     :::image type="content" source="images/refcmd.png" alt-text="screenshot of system information display text.":::
 
-- At the PowerShell or Command Prompt, type `slmgr /dlv`, and then press ENTER. The /dlv command displays the detailed licensing information. Notice the output displays "EnterpriseS" as seen in the image below:
+- At the PowerShell or Command Prompt, type `slmgr /dlv`, and then press ENTER. The /dlv command displays the detailed licensing information. Notice the output displays "EnterpriseS" as seen in the following image:
 
     :::image type="content" source="images/slmgr-dlv.png" alt-text="screenshot of software licensing manager.":::

windows/client-management/config-lock.md

@@ -9,7 +9,7 @@ appliesto:
 
 # Secured-core PC configuration lock
 
-In an enterprise organization, IT administrators enforce policies on their corporate devices to keep the devices in a compliant state and protect the OS by preventing users from changing configurations and creating config drift. Config drift occurs when users with local admin rights change settings and put the device out of sync with security policies. Devices in a non-compliant state can be vulnerable until the next sync and configuration reset with the MDM. Windows 11 with config lock enables IT administrators to prevent config drift and keep the OS configuration in the desired state. With config lock, the OS monitors the registry keys that configure each feature and when it detects a drift, reverts to the IT-desired state in seconds.
+In an enterprise organization, IT administrators enforce policies on their corporate devices to keep the devices in a compliant state and protect the OS by preventing users from changing configurations and creating config drift. Config drift occurs when users with local admin rights change settings and put the device out of sync with security policies. Devices in a noncompliant state can be vulnerable until the next sync and configuration reset with the MDM. Windows 11 with config lock enables IT administrators to prevent config drift and keep the OS configuration in the desired state. With config lock, the OS monitors the registry keys that configure each feature and when it detects a drift, reverts to the IT-desired state in seconds.
 
 Secured-core configuration lock (config lock) is a new [secured-core PC (SCPC)](/windows-hardware/design/device-experiences/oem-highly-secure) feature that prevents configuration drift from secured-core PC features caused by unintentional misconfiguration. In short, it ensures a device intended to be a secured-core PC remains a secured-core PC.
 
@@ -23,7 +23,7 @@ To summarize, config lock:
 
 ## Configuration Flow
 
-After a [secured-core PCs](/windows-hardware/design/device-experiences/oem-highly-secure) reaches the desktop, config lock will prevent configuration drift by detecting if the device is a secured-core PC or not. When the device isn't a secured-core PC, the lock won't apply. If the device is a secured-core PC, config lock will lock the policies listed under [List of locked policies](#list-of-locked-policies).
+After a [secured-core PCs](/windows-hardware/design/device-experiences/oem-highly-secure) reaches the desktop, config lock will prevent configuration drift by detecting if the device is a secured-core PC or not. When the device isn't a secured-core PC, the lock doesn't apply. If the device is a secured-core PC, config lock locks the policies listed under [List of locked policies](#list-of-locked-policies).
 
 ## Enabling config lock using Microsoft Intune
 
@@ -34,23 +34,24 @@ The steps to turn on config lock using Microsoft Intune are as follows:
 1. Ensure that the device to turn on config lock is enrolled in Microsoft Intune.
 1. In the [Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431), select **Devices** > **Configuration Profiles** > **Create a profile**.
 1. Select the following and press **Create**:
-    - **Platform**: Windows 10 and later
+    - **Platform**: `Windows 10 and later`
-    - **Profile type**: Templates
+    - **Profile type**: `Templates`
     - **Template name**: Custom
 
     :::image type="content" source="images/configlock-mem-createprofile.png" alt-text="In Configuration profiles, the Create a profile page is showing, with the Platform set to Windows 10 and later, and a Profile Type of Templates.":::
 
 1. Name your profile.
 1. When you reach the Configuration Settings step, select "Add" and add the following information:
-    - **OMA-URI**: ./Vendor/MSFT/DMClient/Provider/MS%20DM%20Server/ConfigLock/Lock
+    - **OMA-URI**: `./Vendor/MSFT/DMClient/Provider/MS%20DM%20Server/ConfigLock/Lock`
-    - **Data type**: Integer
+    - **Data type**: `Integer`
-    - **Value**: 1 </br>
+    - **Value**: `1`
+
     To turn off config lock, change the value to 0.
 
-    :::image type="content" source="images/configlock-mem-editrow.png" alt-text="In the Configuration settings step, the Edit Row page is shown with a Name of config lock, a Description of Turn on config lock and the OMA-URI set as above, along with a Data type of Integer set to a Value of 1.":::
+    :::image type="content" source="images/configlock-mem-editrow.png" alt-text="In the Configuration settings step, the Edit Row page is shown with a Name of config lock, a Description of Turn-on config lock and the OMA-URI set, along with a Data type of Integer set to a Value of 1.":::
 
 1. Select the devices to turn on config lock. If you're using a test tenant, you can select "+ Add all devices".
-1. You'll not need to set any applicability rules for test purposes.
+1. You don't need to set any applicability rules for test purposes.
 1. Review the Configuration and select "Create" if everything is correct.
 1. After the device syncs with the Microsoft Intune server, you can confirm if the config lock was successfully enabled.
 

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

@@ -50,8 +50,8 @@ This section describes this setup. The following diagram shows the server-server
 
 MSDN provides much information about the Server-Server sync protocol. In particular:
 
-- It's a SOAP-based protocol, and you can get the WSDL in [Server Sync Web Service](/openspecs/windows_protocols/ms-wsusss/8a3b2470-928a-4bd1-bdcc-8c2bf6b8e863). The WSDL can be used to generate calling proxies for many programming environments, which will simplify your development.
+- It's a SOAP-based protocol, and you can get the WSDL in [Server Sync Web Service](/openspecs/windows_protocols/ms-wsusss/8a3b2470-928a-4bd1-bdcc-8c2bf6b8e863). The WSDL can be used to generate calling proxies for many programming environments, to simplify development.
-- You can find code samples in [Protocol Examples](/openspecs/windows_protocols/ms-wsusss/2dedbd00-fbb7-46ee-8ee0-aec9bd1ecd2a). The sample code shows raw SOAP commands, which can be used. Although it's even simpler to make the call from a programming language like .NET (calling the WSDL-generated proxies). The stub generated by the Server Sync WSDL from the MSDN link above generates an incorrect binding URL. The binding URL should be set to `https://fe2.update.microsoft.com/v6/ServerSyncWebService/serversyncwebservice.asmx`.
+- You can find code samples in [Protocol Examples](/openspecs/windows_protocols/ms-wsusss/2dedbd00-fbb7-46ee-8ee0-aec9bd1ecd2a). The sample code shows raw SOAP commands, which can be used. Although it's even simpler to make the call from a programming language like .NET (calling the WSDL-generated proxies). The stub generated by the Server Sync WSDL generates an incorrect binding URL. The binding URL should be set to `https://fe2.update.microsoft.com/v6/ServerSyncWebService/serversyncwebservice.asmx`.
 
 Some important highlights:
 
@@ -64,7 +64,7 @@ Some important highlights:
 
 ### Examples of update metadata XML structure and element descriptions
 
-The response of the GetUpdateData call returns an array of ServerSyncUpdateData that contains the update metadata in the XmlUpdateBlob element. The schema of the update xml is available at [Protocol Examples](/openspecs/windows_protocols/ms-wsusss/2dedbd00-fbb7-46ee-8ee0-aec9bd1ecd2a). Some of the key elements are described below:
+The response of the GetUpdateData call returns an array of ServerSyncUpdateData that contains the update metadata in the XmlUpdateBlob element. The schema of the update xml is available at [Protocol Examples](/openspecs/windows_protocols/ms-wsusss/2dedbd00-fbb7-46ee-8ee0-aec9bd1ecd2a). Some of the key elements are described here:
 
 - **UpdateID** - The unique identifier for an update
 - **RevisionNumber** - Revision number for the update in case the update was modified.
@@ -94,9 +94,9 @@ First some background:
 
 The following procedure describes a basic algorithm for a metadata sync service:
 
-1. Create an empty list of "needed update IDs to fault in". This list will get updated by the MDM service component that uses OMA DM. We recommend not adding definition updates to this list, since they're temporary. For example, Defender can release new definition updates many times per day, each of which is cumulative.
+1. Create an empty list of "needed update IDs to fault in". This list gets updated by the MDM service component that uses OMA DM. We recommend not adding definition updates to this list, since they're temporary. For example, Defender can release new definition updates many times per day, each of which is cumulative.
 1. Sync periodically (we recommend once every 2 hours - no more than once/hour).
-   1. Implement the authorization phase of the protocol to get a cookie if you don't already have a non-expired cookie. See **Sample 1: Authorization** in [Protocol Examples](/openspecs/windows_protocols/ms-wsusss/2dedbd00-fbb7-46ee-8ee0-aec9bd1ecd2a).
+   1. Implement the authorization phase of the protocol to get a cookie if you don't already have a nonexpired cookie. See **Sample 1: Authorization** in [Protocol Examples](/openspecs/windows_protocols/ms-wsusss/2dedbd00-fbb7-46ee-8ee0-aec9bd1ecd2a).
    1. Implement the metadata portion of the protocol. See **Sample 2: Metadata and Deployments Synchronization** in [Protocol Examples](/openspecs/windows_protocols/ms-wsusss/2dedbd00-fbb7-46ee-8ee0-aec9bd1ecd2a)), and call GetUpdateData for all updates in the "needed update IDs to fault in" list if the update metadata hasn't already been pulled into the DB.
         - If the update is a newer revision of an existing update (same UpdateID, higher revision number), replace the previous update metadata with the new one.
         - Remove updates from the "needed update IDs to fault in" list once they've been brought in.
@@ -122,7 +122,7 @@ Updates are configured using the [Update Policy CSP](mdm/policy-csp-update.md).
 
 ### Update management user experience screenshot
 
-The following screenshots of the administrator console show the list of update titles, approval status, and additional metadata fields.
+The following screenshots of the administrator console show the list of update titles, approval status, and other metadata fields.
 
 :::image type="content" source="images/deviceupdatescreenshot1.png" alt-text="mdm update management screenshot.":::
 

windows/client-management/disconnecting-from-mdm-unenrollment.md

@@ -8,7 +8,7 @@ ms.date: 08/10/2023
 # Disconnecting from the management infrastructure (unenrollment)
 
 The Disconnecting process is done either locally by the user who uses a phone or remotely by the IT administrator using management server. The user-initiated disconnection process is similar to the initial connection, wherein its initiation is from the same location in the Setting Control Panel as creating the workplace account.
-The users choose to disconnect for any number of reasons, such as the ones described below: leaving the company or getting a new device or not needing access to their LOB apps on the old device, anymore. When an IT administrator initiates a disconnection, the enrollment client performs the disconnection during the next regular maintenance session. Administrators choose to disconnect users' device after they've left the company or because the device is regularly failing to comply with the organization's security settings policy.
+The users choose to disconnect for any number of reasons, such as leaving the company or getting a new device or not needing access to their LOB apps on the old device anymore. When an IT administrator initiates a disconnection, the enrollment client performs the disconnection during the next regular maintenance session. Administrators choose to disconnect users' device after they've left the company or because the device is regularly failing to comply with the organization's security settings policy.
 
 During disconnection, the client executes the following tasks:
 
@@ -20,7 +20,7 @@ During disconnection, the client executes the following tasks:
 
 ## User-initiated disconnection
 
-In Windows, after the user confirms the account deletion command and before the account is deleted, the MDM client will notify to the MDM server that the account will be removed. This notification is a best-effort action as no retry is built-in to ensure the notification is successfully sent to the device.
+In Windows, after the user confirms the account deletion command and before the account is deleted, the MDM client will notify to the MDM server that the account will be removed. This notification is a best-effort action as no retry is built in to ensure the notification is successfully sent to the device.
 
 This action utilizes the OMA DM generic alert 1226 function to send a user an MDM unenrollment user alert to the MDM server after the device accepts the user unenrollment request, but before it deletes any enterprise data. The server should set the expectation that unenrollment may succeed or fail, and the server can check whether the device is unenrolled by either checking whether the device calls back at scheduled time or by sending a push notification to the device to see whether it responds back. If the server plans to send a push notification, it should allow for some delay to give the device the time to complete the unenrollment work.
 
@@ -31,7 +31,7 @@ The vendor uses the Type attribute to specify what type of generic alert it is.
 
 After the user elects to unenroll, any active MDM OMA DM sessions are terminated. After that, the DM client starts a DM session, including a user unenroll generic alert in the first package that it sends to the server.
 
-The following sample shows an OMA DM first package that contains a generic alert message. For more information on WP OMA DM support, see the [OMA DM protocol support](oma-dm-protocol-support.md) topic.
+The following sample shows an OMA DM first package that contains a generic alert message. For more information on WP OMA DM support, see the [OMA DM protocol support](oma-dm-protocol-support.md) article.
 
 ```xml
 <SyncML xmlns=&#39;SYNCML:SYNCML1.2&#39;>
@@ -82,7 +82,7 @@ After the previous package is sent, the unenrollment process begins.
 
 ## Server-initiated disconnection
 
-When the server initiates disconnection, all undergoing sessions for the enrollment ID are aborted immediately to avoid deadlocks. The server will not get a response for the unenrollment, instead a generic alert notification is sent with `messageid=1`.
+When the server initiates disconnection, all undergoing sessions for the enrollment ID are aborted immediately to avoid deadlocks. The server doesn't get a response for the unenrollment, instead a generic alert notification is sent with `messageid=1`.
 
 ```xml
 <Alert>
@@ -100,7 +100,7 @@ When the server initiates disconnection, all undergoing sessions for the enrollm
 
 ## Unenrollment from Work Access settings page
 
-If the user is enrolled into MDM using an Azure Active Directory (AAD Join or by adding a Microsoft work account), the MDM account will show up under the Work Access page. However, the **Disconnect** button is greyed out and not accessible. Users can remove that MDM account by removing the Azure AD association to the device.
+If the user is enrolled into MDM using an Azure Active Directory (Azure AD Join or by adding a Microsoft work account), the MDM account shows up under the Work Access page. However, the **Disconnect** button is greyed out and not accessible. Users can remove that MDM account by removing the Azure AD association to the device.
 
 You can only use the Work Access page to unenroll under the following conditions:
 
@@ -109,18 +109,18 @@ You can only use the Work Access page to unenroll under the following conditions
 
 ## Unenrollment from Azure Active Directory Join
 
-When a user is enrolled into MDM through Azure Active Directory Join and later, the enrollment disconnects, there is no warning that the user will lose Windows Information Protection (WIP) data. The disconnection message does not indicate the loss of WIP data.
+When a user is enrolled into MDM through Azure Active Directory Join and later, the enrollment disconnects, there's no warning that the user will lose Windows Information Protection (WIP) data. The disconnection message doesn't indicate the loss of WIP data.
 
 ![aadj unenerollment.](images/azure-ad-unenrollment.png)
 
-During the process in which a device is enrolled into MDM through Azure Active Directory Join and then remotely unenrolled, the device may get into a state where it must be re-imaged. When devices are remotely unenrolled from MDM, the Azure Active Directory association is also removed. This safeguard is in place to avoid leaving the corporate devices in un-managed state.
+During the process in which a device is enrolled into MDM through Azure Active Directory Join and then remotely unenrolled, the device may get into a state where it must be reimaged. When devices are remotely unenrolled from MDM, the Azure Active Directory association is also removed. This safeguard is in place to avoid leaving the corporate devices in unmanaged state.
 
-Before remotely un-enrolling corporate devices, you must ensure that there is at least one admin user on the device that is not part of the Azure tenant, otherwise the device will not have any admin user after the operation.
+Before remotely unenrolling corporate devices, you must ensure that there is at least one admin user on the device that isn't part of Azure AD, otherwise the device won't have any admin user after the operation.
 
-In mobile devices, remote unenrollment for Azure Active Directory Joined devices will fail. To remove corporate content from these devices, we recommend you remotely wipe the device.
+In mobile devices, remote unenrollment for Azure Active Directory Joined devices fails. To remove corporate content from these devices, we recommend you remotely wipe the device.
 
 ## IT admin-requested disconnection
 
-The server requests an enterprise management disconnection by issuing an Exec OMA DM SyncML XML command to the device, using the DMClient configuration service provider's Unenroll node during the next client-initiated DM session. The Data tag inside the Exec command should be the value of the provisioned DM server ProviderID. For more information, see the Enterprise-specific DMClient configuration topic.
+The server requests an enterprise management disconnection by issuing an Exec OMA DM SyncML XML command to the device, using the DMClient configuration service provider's Unenroll node during the next client-initiated DM session. The Data tag inside the Exec command should be the value of the provisioned DM server ProviderID. For more information, see the Enterprise-specific DMClient configuration article.
 
 When the disconnection is completed, the user is notified that the device has been disconnected from enterprise management.

windows/client-management/enable-admx-backed-policies-in-mdm.md

@@ -32,9 +32,9 @@ See [Support Tip: Ingesting Office ADMX policies using Microsoft Intune](https:/
 
 1. Use the Group Policy Editor to determine whether you need additional information to enable the policy. Run GPEdit.msc
 
-    1. Click **Start**, then in the text box type **gpedit**.
+    1. Select **Start**, then in the text box type **gpedit**.
 
-    2. Under **Best match**, click **Edit group policy** to launch it.
+    2. Under **Best match**, select **Edit group policy** to launch it.
 
        ![GPEdit search.](images/admx-gpedit-search.png)
 
@@ -100,7 +100,7 @@ See [Support Tip: Ingesting Office ADMX policies using Microsoft Intune](https:/
 
    1. Search for GP name **Publishing_Server2_policy**.
 
-   1. Under **policy name="Publishing_Server2_Policy"** you can see the \<elements> listed. The *text id* and *enum id* represent the *data id* you need to include in the SyncML data payload. They correspond to the fields you see in the Group Policy Editor.
+   1. Under **policy name="Publishing_Server2_Policy"** you can see the `<elements>` listed. The `text id` and `enum id` represent the `data id` you need to include in the SyncML data payload. They correspond to the fields you see in the Group Policy Editor.
 
       Here's the snippet from appv.admx:
 
@@ -192,7 +192,7 @@ See [Support Tip: Ingesting Office ADMX policies using Microsoft Intune](https:/
       </policy>
       ```
 
-   1. From the **\<elements>**  tag, copy all of the *text id* and *enum id* and create an XML with *data id* and *value* fields. The *value* field contains the configuration settings that you would enter in the Group Policy Editor.
+   1. From the `<elements>`  tag, copy all of the `text id` and `enum id` and create an XML with `data id` and `value` fields. The *value* field contains the configuration settings that you would enter in the Group Policy Editor.
 
       Here's the example XML for Publishing_Server2_Policy:
 
@@ -251,7 +251,7 @@ See [Support Tip: Ingesting Office ADMX policies using Microsoft Intune](https:/
 
 ## Disable a policy
 
-The \<Data> payload is \<disabled/>. Here is an example to disable AppVirtualization/PublishingAllowServer2.
+The \<Data> payload is \<disabled/>. Here's an example to disable AppVirtualization/PublishingAllowServer2.
 
 ```xml
 <SyncML xmlns="SYNCML:SYNCML1.2">

windows/client-management/enroll-a-windows-10-device-automatically-using-group-policy.md

@@ -1,6 +1,6 @@
 ---
 title: Enroll a Windows device automatically using Group Policy
-description: Learn how to use a Group Policy to trigger auto-enrollment to MDM for Active Directory (AD) domain-joined devices.
+description: Learn how to use a Group Policy to trigger autoenrollment to MDM for Active Directory (AD) domain-joined devices.
 ms.topic: article
 ms.date: 08/10/2023
 ms.collection:
@@ -10,7 +10,7 @@ ms.collection:
 
 # Enroll a Windows device automatically using Group Policy
 
-You can use a Group Policy to trigger auto-enrollment to Mobile Device Management (MDM) for Active Directory (AD) domain-joined devices.
+You can use a Group Policy to trigger autoenrollment to Mobile Device Management (MDM) for Active Directory (AD) domain-joined devices.
 
 The enrollment into Intune is triggered by a group policy created on your local AD and happens without any user interaction. This cause-and-effect mechanism means you can automatically mass-enroll a large number of domain-joined corporate devices into Microsoft Intune. The enrollment process starts in the background once you sign in to the device with your Azure AD account.
 
@@ -19,7 +19,7 @@ The enrollment into Intune is triggered by a group policy created on your local
 - The Active Directory joined device must be running a [supported version of Windows](/windows/release-health/supported-versions-windows-client).
 - The enterprise has configured a Mobile Device Management (MDM) service.
 - The on-premises Active Directory must be [integrated with Azure AD (via Azure AD Connect)](/azure/architecture/reference-architectures/identity/azure-ad).
-- The device shouldn't already be enrolled in Intune using the classic agents (devices managed using agents will fail enrollment with `error 0x80180026`).
+- The device shouldn't already be enrolled in Intune using the classic agents (devices managed using agents fail enrollment with `error 0x80180026`).
 - The minimum Windows Server version requirement is based on the Hybrid Azure AD join requirement. For more information, see [How to plan your hybrid Azure Active Directory join implementation](/azure/active-directory/devices/hybrid-azuread-join-plan).
 
 > [!TIP]
@@ -29,28 +29,28 @@ The enrollment into Intune is triggered by a group policy created on your local
 > - [How to plan your hybrid Azure Active Directory join implementation](/azure/active-directory/devices/hybrid-azuread-join-plan)
 > - [Azure Active Directory integration with MDM](./azure-active-directory-integration-with-mdm.md)
 
-The auto-enrollment relies on the presence of an MDM service and the Azure Active Directory registration for the PC. Once the enterprise has registered its AD with Azure AD, a Windows PC that is domain joined is automatically Azure AD-registered.
+The autoenrollment relies on the presence of an MDM service and the Azure Active Directory registration for the PC. Once the enterprise has registered its AD with Azure AD, a Windows PC that is domain joined is automatically Azure AD-registered.
 
 > [!NOTE]
 > In Windows 10, version 1709, the enrollment protocol was updated to check whether the device is domain-joined. For details, see [\[MS-MDE2\]: Mobile Device Enrollment Protocol Version 2](/openspecs/windows_protocols/ms-mde2/4d7eadd5-3951-4f1c-8159-c39e07cbe692). For examples, see section 4.3.1 RequestSecurityToken of the MS-MDE2 protocol documentation.
 
-When the auto-enrollment Group Policy is enabled, a task is created in the background that initiates the MDM enrollment. The task will use the existing MDM service configuration from the Azure Active Directory information of the user. If multi-factor authentication is required, the user will get a prompt to complete the authentication. Once the enrollment is configured, the user can check the status in the Settings page.
+When the autoenrollment Group Policy is enabled, a task is created in the background that initiates the MDM enrollment. The task uses the existing MDM service configuration from the Azure Active Directory information of the user. If multi-factor authentication is required, the user gets prompted to complete the authentication. Once the enrollment is configured, the user can check the status in the Settings page.
 
 - Starting in Windows 10, version 1709, when the same policy is configured in Group Policy and MDM, Group Policy policy takes precedence over MDM.
 - Starting in Windows 10, version 1803, a new setting allows you to change precedence to MDM. For more information, see [Windows Group Policy vs. Intune MDM Policy who wins?](/archive/blogs/cbernier/windows-10-group-policy-vs-intune-mdm-policy-who-wins).
 
 For this policy to work, you must verify that the MDM service provider allows Group Policy initiated MDM enrollment for domain-joined devices.
 
-## Configure the auto-enrollment for a group of devices
+## Configure the autoenrollment for a group of devices
 
-To configure auto-enrollment using a group policy, use the following steps:
+To configure autoenrollment using a group policy, use the following steps:
 
 1. Create a Group Policy Object (GPO) and enable the Group Policy **Computer Configuration** > **Administrative Templates** > **Windows Components** > **MDM** > **Enable automatic MDM enrollment using default Azure AD credentials**.
 1. Create a Security Group for the PCs.
 1. Link the GPO.
 1. Filter using Security Groups.
 
-If you don't see the policy, it may be because you don't have the ADMX for Windows 10, version 1803 or later installed. To fix the issue, use the following procedures. Note that the latest MDM.admx is backwards compatible.
+If you don't see the policy, it may be because you don't have the ADMX for Windows 10, version 1803 or later installed. To fix the issue, use the following procedures. The latest MDM.admx is backwards compatible.
 
 1. Download the administrative templates for the desired version:
 
@@ -67,17 +67,17 @@ If you don't see the policy, it may be because you don't have the ADMX for Windo
 
 1. Install the package on the Domain Controller.
 
-1. Navigate to `C:\Program Files (x86)\Microsoft Group Policy`, and locate the appropriate sub-directory depending on the installed version.
+1. Navigate to `C:\Program Files (x86)\Microsoft Group Policy`, and locate the appropriate subdirectory depending on the installed version.
 
 1. Copy the PolicyDefinitions folder to `\\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions`.
 
-   If this folder doesn't exist, then you'll be switching to a [central policy store](/troubleshoot/windows-client/group-policy/create-and-manage-central-store) for your entire domain.
+   If this folder doesn't exist, then copy the files to the [central policy store](/troubleshoot/windows-client/group-policy/create-and-manage-central-store) for your domain.
 
 1. Wait for the SYSVOL DFSR replication to be completed for the policy to be available.
 
-## Configure the auto-enrollment Group Policy for a single PC
+## Configure the autoenrollment Group Policy for a single PC
 
-This procedure is only for illustration purposes to show how the new auto-enrollment policy works. It's not recommended for the production environment in the enterprise.
+This procedure is only for illustration purposes to show how the new autoenrollment policy works. It's not recommended for the production environment in the enterprise.
 
 1. Run `GPEdit.msc`. Choose **Start**, then in the text box type `gpedit`.
 
@@ -96,7 +96,7 @@ This procedure is only for illustration purposes to show how the new auto-enroll
 
 When a group policy refresh occurs on the client, a task is created and scheduled to run every 5 minutes for the duration of one day. The task is called **Schedule created by enrollment client for automatically enrolling in MDM from Azure Active Directory**. To see the scheduled task, launch the [Task Scheduler app](#task-scheduler-app).
 
-If two-factor authentication is required, you'll be prompted to complete the process. Here's an example screenshot.
+If two-factor authentication is required, you are prompted to complete the process. Here's an example screenshot.
 
 :::image type="content" source="images/autoenrollment-2-factor-auth.png" alt-text="Screenshot of Two-factor authentication notification.":::
 
@@ -118,16 +118,16 @@ Select **Start**, then in the text box type `task scheduler`. Under **Best match
 
 In **Task Scheduler Library**, open **Microsoft > Windows** , then select **EnterpriseMgmt**.
 
-:::image type="content" alt-text="Auto-enrollment scheduled task." source="images/autoenrollment-scheduled-task.png" lightbox="images/autoenrollment-scheduled-task.png":::
+:::image type="content" alt-text="Autoenrollment scheduled task." source="images/autoenrollment-scheduled-task.png" lightbox="images/autoenrollment-scheduled-task.png":::
 
-To see the result of the task, move the scroll bar to the right to see the **Last Run Result**. You can see the logs in the **History** tab.
+To see the result of the task, move the scroll bar to see the **Last Run Result**. You can see the logs in the **History** tab.
 
 The message **0x80180026** is a failure message (`MENROLL_E_DEVICE_MANAGEMENT_BLOCKED`). If the device enrollment is blocked, your IT admin might have enabled the **Disable MDM Enrollment** policy.
 
 > [!NOTE]
 > The GPEdit console doesn't reflect the status of policies set by your IT admin on your device. It's only used by the user to set policies.
 
-## Related topics
+## Related articles
 
 - [Group Policy Management Console](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753298(v=ws.11))
 - [Create and Edit a Group Policy Object](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc754740(v=ws.11))

windows/client-management/enterprise-app-management.md

@@ -7,7 +7,7 @@ ms.date: 08/10/2023
 
 # Enterprise app management
 
-This article will discuss one of the key features of Windows' Mobile Device Management (MDM) capabilities: the ability to manage apps' lifecycle on all Windows devices. This includes both Store and non-Store apps, which can be managed natively through MDM.
+This article discusses one of the key features of Windows' Mobile Device Management (MDM) capabilities: the ability to manage apps' lifecycle on all Windows devices. This includes both Store and non-Store apps, which can be managed natively through MDM.
 
 By using Windows MDM to manage app lifecycles, administrators can deploy and manage updates, remove outdated or unused apps, and ensure that all devices have the necessary apps installed to meet the organization's needs. This feature streamlines the app management process and saves time and effort for IT professionals.
 
@@ -29,18 +29,18 @@ Windows offers the ability for management servers to:
 Windows lets you inventory all apps deployed to a user, and inventory all apps for all users of a Windows device. The [EnterpriseModernAppManagement](mdm/enterprisemodernappmanagement-csp.md) configuration service provider (CSP) inventories packaged apps and doesn't include traditional Win32 apps installed via MSI or executables. When the apps are inventoried, they're separated based on the following app classifications:
 
 - **Store**: Apps that have been acquired from the Microsoft Store, either directly or delivered with the enterprise from the Store for Business.
-- **nonStore**: Apps that were not acquired from the Microsoft Store.
+- **nonStore**: Apps that weren't acquired from the Microsoft Store.
-- **System**: Apps that are part of the operating system and cannot be uninstalled. This classification is read-only and can only be inventoried.
+- **System**: Apps that are part of the operating system and can't be uninstalled. This classification is read-only and can only be inventoried.
 
 Each app is identified by one package family name and one or more package full names, and the apps are grouped based on their origin. The EnterpriseModernAppManagement CSP displays these classifications as nodes.
 
 Inventory can be run recursively at any level from the AppManagement node through the package full name. You can also choose to inventory specific attributes only. The inventory is specific to the package full name and lists bundled and resource packs as applicable under the package family name.
 
-For more information on each node, refer to the detailed descriptions provided in the [EnterpriseModernAppManagement CSP](mdm/enterprisemodernappmanagement-csp.md).
+For more information on each node, see the detailed descriptions provided in the [EnterpriseModernAppManagement CSP](mdm/enterprisemodernappmanagement-csp.md).
 
 ### App inventory
 
-You can use the EnterpriseModernAppManagement CSP to query for all apps installed for a user or device. The query returns all apps, even if they were installed using MDM or other methods. Inventory can run at the user or device level. Inventory at the device level will return information for all users on the device.
+You can use the EnterpriseModernAppManagement CSP to query for all apps installed for a user or device. The query returns all apps, even if they were installed using MDM or other methods. Inventory can run at the user or device level. Inventory at the device level returns information for all users on the device.
 
 Doing a full inventory of a device can be resource-intensive based on the hardware and number of apps that are installed. The data returned can also be large. You may want to chunk these requests to reduce the impact to clients and network traffic.
 
@@ -74,7 +74,7 @@ Doing a full inventory of a device can be resource-intensive based on the hardwa
 
 ### Store license inventory
 
-You can use the EnterpriseModernAppManagement CSP to query for all app licenses installed for a user or device. The query returns all app licenses, event if they were installed via MDM or other methods. Inventory can run at the user or device level. Inventory at the device level will return information for all users on the device.
+You can use the EnterpriseModernAppManagement CSP to query for all app licenses installed for a user or device. The query returns all app licenses, event if they were installed via MDM or other methods. Inventory can run at the user or device level. Inventory at the device level returns information for all users on the device.
 
 For detailed descriptions of each node, see [EnterpriseModernAppManagement CSP](mdm/enterprisemodernappmanagement-csp.md).
 
@@ -228,8 +228,8 @@ Here are the changes from the previous release:
 
 1. The `{CatID}` reference should be updated to `{ProductID}`. This value is acquired as a part of the Store for Business management tool.
 1. The value for flags can be 0 or 1.
-   - When using "0", the management tool calls back to the Store for Business sync to assign a user a seat of an application.
+   - **0**: The management tool calls back to the Store for Business sync to assign a user a seat of an application.
-   - When using "1", the management tool doesn't call back in to the Store for Business sync to assign a user a seat of an application. The CSP will claim a seat if one is available.
+   - **1**: The management tool doesn't call back in to the Store for Business sync to assign a user a seat of an application. The CSP claims a seat if one is available.
 1. The `skuid` is a new parameter that is required. This value is acquired as a part of the Store for Business to management tool sync.
 
 ### Deploy an offline license to a user
@@ -377,7 +377,7 @@ The Add command for the package family name is required to ensure proper removal
 
 ### Provision apps for all users of a device
 
-Provisioning allows you to stage the app to the device and all users of the device can have the app registered on their next login. This feature is only supported for app purchased from the Store for Business, and the app is specified for an offline license or the app is a non-Store app. The app must be offered from a hosted location. The app is installed as a local system. To install to a local file share, the 'local system' of the device must have access to the share.
+Provisioning allows you to stage the app to the device and all users of the device can have the app registered on their next sign in. This feature is only supported for app purchased from the Store for Business, and the app is specified for an offline license or the app is a non-Store app. The app must be offered from a hosted location. The app is installed as a local system. To install to a local file share, the 'local system' of the device must have access to the share.
 
 Here are the requirements for this scenario:
 
@@ -423,7 +423,7 @@ To provision app for all users of a device from a hosted location, the managemen
   The HostedInstall Exec command contains a Data node that requires an embedded XML. Here are the requirements for the data XML:
 
   - Application node has a required parameter, PackageURI, which can be a local file location, UNC, or HTTPS location.
-  - Dependencies can be specified if required to be installed with the package. This is optional.
+  - Dependencies can be specified if necessary to be installed with the package. This is optional.
 
   The DeploymentOptions parameter is only available in the user context.
 
@@ -574,7 +574,7 @@ To uninstall an app, you delete it under the origin node, package family name, a
 
 ### Removed provisioned apps from a device
 
-You can remove provisioned apps from a device for a specific version, or for all versions of a package family. When a provisioned app is removed, it isn't available to future users for the device. Logged in users who have the app registered to them will continue to have access to the app. If you want to remove the app for those users, you must explicitly uninstall the app for those users.
+You can remove provisioned apps from a device for a specific version, or for all versions of a package family. When a provisioned app is removed, it isn't available to future users for the device. Logged in users who have the app registered to them continue to have access to the app. If you want to remove the app for those users, you must explicitly uninstall the app for those users.
 
 > [!NOTE]
 > You can only remove an app that has an inventory value IsProvisioned = 1.
@@ -746,7 +746,7 @@ The Universal Windows app can share application data between the users of the de
 
 The [ApplicationManagement/AllowSharedUserAppData](mdm/policy-csp-applicationmanagement.md) policy enables or disables app packages to share data between app packages when there are multiple users. If you enable this policy, applications can share data between packages in their package family. Data can be shared through ShareLocal folder for that package family and local machine. This folder is available through the Windows.Storage API.
 
-If you disable this policy, applications can't share user application data among multiple users. However, pre-written shared data will persist. The clean pre-written shared data, use DISM ((`/Get-ProvisionedAppxPackage` to detect if there's any shared data, and `/Remove-SharedAppxData` to remove it).
+If you disable this policy, applications can't share user application data among multiple users. However, prewritten shared data persists. To clean prewritten shared data, use DISM (`/Get-ProvisionedAppxPackage` to detect if there's any shared data, and `/Remove-SharedAppxData` to remove it).
 
 The valid values are 0 (off, default value) and 1 (on).
 

windows/client-management/esim-enterprise-management.md

@@ -10,7 +10,7 @@ ms.date: 08/10/2023
 
 The eSIM Profile Management Solution places the Mobile Device Management (MDM) Provider in the front and center. The whole idea is to use an already-existing solution that customers are familiar with and use to manage devices.
 
-The expectations from an MDM are that it will use the same sync mechanism that it uses for device policies to push any policy to the eSIM profile, and use Groups and Users the same way. This way, the eSIM profile download and the installation happen in the background without impacting the end user. Similarly, the IT admin would use the same method of managing the eSIM profiles (Assignment/un-assignment, etc.) the same way as they currently do device management.
+The expectations from an MDM are that it uses the same sync mechanism that it uses for device policies to push any policy to the eSIM profile, and use Groups and Users the same way. This way, the eSIM profile download and the installation happen in the background without impacting the end user. Similarly, the IT admin would use the same method of managing the eSIM profiles (Assignment/un-assignment, etc.) the same way as they currently do device management.
 
 If you're a Mobile Device Management (MDM) Provider and want to support eSIM Management on Windows, perform the following steps:
 

windows/client-management/federated-authentication-device-enrollment.md

@@ -63,10 +63,10 @@ After the device gets a response from the server, the device sends a POST reques
 
 The following logic is applied:
 
-1. The device first tries HTTPS. If the server cert isn't trusted by the device, the HTTPS fails.
+1. The device first tries HTTPS. If the device doesn't trust the server cert, the HTTPS attempt fails.
 1. If that fails, the device tries HTTP to see whether it's redirected:
-   - If the device isn't redirected, it prompts the user for the server address.
+   - If the device isn't redirected, the user is prompted for the server address.
-   - If the device is redirected, it prompts the user to allow the redirect.
+   - If the device is redirected, the user is prompted to allow the redirect.
 
 The following example shows a request via an HTTP POST command to the discovery web service given `user@contoso.com` as the email address
 
@@ -116,13 +116,13 @@ The following example shows the discovery service request.
 The discovery response is in the XML format and includes the following fields:
 
 - Enrollment service URL (EnrollmentServiceUrl) - Specifies the URL of the enrollment endpoint that is exposed by the management service. The device should call this URL after the user has been authenticated. This field is mandatory.
-- Authentication policy (AuthPolicy) - Indicates what type of authentication is required. For the MDM server, OnPremise is the supported value, which means that the user will be authenticated when calling the management service URL. This field is mandatory.
+- Authentication policy (AuthPolicy) - Indicates what type of authentication is required. For the MDM server, OnPremise is the supported value, which means that the user is authenticated when calling the management service URL. This field is mandatory.
 - In Windows, Federated is added as another supported value. This addition allows the server to use the Web Authentication Broker to perform customized user authentication, and term of usage acceptance.
 
 > [!NOTE]
 > The HTTP server response must not set Transfer-Encoding to Chunked; it must be sent as one message.
 
-When authentication policy is set to be Federated, Web Authentication Broker (WAB) will be used by the enrollment client to get a security token. The WAB start page URL is provided by the discovery service in the response message. The enrollment client will call the WAB API within the response message to start the WAB process. WAB pages are server hosted web pages. The server should build those pages to fit the device screen nicely and be as consistent as possible to other builds in the MDM enrollment UI. The opaque security token that is returned from WAB as an endpage will be used by the enrollment client as the device security secret during the client certificate enrollment request call.
+When authentication policy is set to be Federated, Web Authentication Broker (WAB) is used by the enrollment client to get a security token. The WAB start page URL is provided by the discovery service in the response message. The enrollment client calls the WAB API within the response message to start the WAB process. WAB pages are server hosted web pages. The server should build those pages to fit the device screen nicely and be as consistent as possible to other builds in the MDM enrollment UI. The opaque security token that is returned from WAB as an endpage is used by the enrollment client as the device security secret during the client certificate enrollment request call.
 
 > [!NOTE]
 > Instead of relying on the user agent string that is passed during authentication to get information, such as the OS version, use the following guidance:
@@ -139,7 +139,7 @@ A new XML tag, **AuthenticationServiceUrl**, is introduced in the DiscoveryRespo
 The following are the explicit requirements for the server.
 
 - The `<DiscoveryResponse>``<AuthenticationServiceUrl>` element must support HTTPS.
-- The authentication server must use a device trusted root certificate. Otherwise, the WAP call will fail.
+- The authentication server must use a device trusted root certificate. Otherwise, the WAP call fails.
 - WP doesn't support Windows Integrated Authentication (WIA) for ADFS during WAB authentication. ADFS 2012 R2 if used needs to be configured to not attempt WIA for Windows device.
 
 The enrollment client issues an HTTPS request as follows:
@@ -148,8 +148,8 @@ The enrollment client issues an HTTPS request as follows:
 AuthenticationServiceUrl?appru=<appid>&amp;login_hint=<User Principal Name>
 ```
 
-- `<appid>` is of the form ms-app://string
+- `<appid>` is of the form `ms-app://string`
-- `<User Principal Name>` is the name of the enrolling user, for example, user@constoso.com as input by the user in an enrollment sign-in page. The value of this attribute serves as a hint that can be used by the authentication server as part of the authentication.
+- `<User Principal Name>` is the name of the enrolling user, for example, user@constoso.com as input by the user in an enrollment sign-in page. The value of this attribute serves as a hint that is used by the authentication server as part of the authentication.
 
 After authentication is complete, the auth server should return an HTML form document with a POST method action of appid identified in the query string parameter.
 
@@ -183,7 +183,7 @@ Content-Length: 556
 </html>
 ```
 
-The server has to send a POST to a redirect URL of the form ms-app://string (the URL scheme is ms-app) as indicated in the POST method action. The security token value is the base64-encoded string `http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary` contained in the `<wsse:BinarySecurityToken>` EncodingType attribute. Windows does the binary encode when it sends it back to enrollment server, in the form it's just HTML encoded. This string is opaque to the enrollment client; the client doesn't interpret the string.
+The server has to send a POST to a redirect URL of the form `ms-app://string` (the URL scheme is ms-app) as indicated in the POST method action. The security token value is the base64-encoded string `http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary` contained in the `<wsse:BinarySecurityToken>` EncodingType attribute. Windows does the binary encode when it sends it back to enrollment server, in the form its just HTML encoded. This string is opaque to the enrollment client; the client doesn't interpret the string.
 
 The following example shows a response received from the discovery web service that requires authentication via WAB.
 
@@ -371,7 +371,7 @@ This web service implements the MS-WSTEP protocol. It processes the RequestSecur
 
 The RequestSecurityToken (RST) must have the user credential and a certificate request. The user credential in an RST SOAP envelope is the same as in GetPolicies, and can vary depending on whether the authentication policy is OnPremise or Federated. The BinarySecurityToken in an RST SOAP body contains a Base64-encoded PKCS\#10 certificate request, which is generated by the client based on the enrollment policy. The client could have requested an enrollment policy by using MS-XCEP before requesting a certificate using MS-WSTEP. If the PKCS\#10 certificate request is accepted by the certification authority (CA) (the key length, hashing algorithm, and so on, match the certificate template), the client can enroll successfully.
 
-The RequestSecurityToken will use a custom TokenType (`http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken`), because our enrollment token is more than an X.509 v3 certificate. For more information, see the Response section.
+The RequestSecurityToken uses a custom TokenType (`http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken`), because our enrollment token is more than an X.509 v3 certificate. For more information, see the Response section.
 
 The RST may also specify many AdditionalContext items, such as DeviceType and Version. Based on these values, for example, the web service can return device-specific and version-specific DM configuration.
 
@@ -466,14 +466,14 @@ After validating the request, the web service looks up the assigned certificate
 > [!NOTE]
 > The HTTP server response must not set Transfer-Encoding to Chunked; it must be sent as one message.
 
-Similar to the TokenType in the RST, the RSTR will use a custom ValueType in the BinarySecurityToken (`http://schemas.microsoft.com/ConfigurationManager/Enrollment/DeviceEnrollmentProvisionDoc`), because the token is more than an X.509 v3 certificate.
+Similar to the TokenType in the RST, the RSTR uses a custom ValueType in the BinarySecurityToken (`http://schemas.microsoft.com/ConfigurationManager/Enrollment/DeviceEnrollmentProvisionDoc`), because the token is more than an X.509 v3 certificate.
 
 The provisioning XML contains:
 
 - The requested certificates (required)
 - The DM client configuration (required)
 
-The client will install the client certificate, the enterprise root certificate, and intermediate CA certificate if there's one. The DM configuration includes the name and address of the DM server, which client certificate to use, and schedules when the DM client calls back to the server.
+The client installs the client certificate, the enterprise root certificate, and intermediate CA certificate if there's one. The DM configuration includes the name and address of the DM server, which client certificate to use, and schedules when the DM client calls back to the server.
 
 Enrollment provisioning XML should contain a maximum of one root certificate and one intermediate CA certificate that is needed to chain up the MDM client certificate. More root and intermediate CA certificates could be provisioned during an OMA DM session.
 

windows/client-management/implement-server-side-mobile-application-management.md

@@ -15,11 +15,11 @@ The Windows version of mobile application management (MAM) is a lightweight solu
 
 MAM on Windows is integrated with Azure Active Directory (Azure AD) identity service. The MAM service supports Azure AD-integrated authentication for the user and the device during enrollment and the downloading of MAM policies. MAM integration with Azure AD is similar to mobile device management (MDM) integration. See [Azure Active Directory integration with MDM](azure-active-directory-integration-with-mdm.md).
 
-MAM enrollment is integrated with adding a work account flow to a personal device. If both MAM and Azure AD-integrated MDM services are provided in an organization, a user's personal devices will be enrolled to MAM or MDM, depending on the user's actions. If a user adds their work or school Azure AD account as a secondary account to the machine, their device will be enrolled to MAM. If a user joins their device to Azure AD, it will be enrolled to MDM. In general, a device that has a personal account as its primary account is considered a personal device and should be enrolled to MAM. An Azure AD join, and enrollment to MDM, should be used to manage corporate devices.
+MAM enrollment is integrated with adding a work account flow to a personal device. If both MAM and Azure AD-integrated MDM services are provided in an organization, a user's personal devices are enrolled to MAM or MDM, depending on the user's actions. If a user adds their work or school Azure AD account as a secondary account to the machine, their device is enrolled to MAM. If a user joins their device to Azure AD, it's enrolled to MDM. In general, a device that has a personal account as its primary account is considered a personal device and should be enrolled to MAM. An Azure AD join, and enrollment to MDM, should be used to manage corporate devices.
 
 On personal devices, users can add an Azure AD account as a secondary account to the device while keeping their personal account as primary. Users can add an Azure AD account to the device from a supported Azure AD-integrated application, such as the next update of Microsoft 365 apps. Alternatively, users can add an Azure AD account from **Settings > Accounts > Access work or school**.
 
-Regular non-admin users can enroll to MAM.
+Regular non administrator users can enroll to MAM.
 
 ## Integration with Windows Information Protection
 
@@ -37,11 +37,11 @@ MICROSOFTEDPAUTOPROTECTIONALLOWEDAPPINFO EDPAUTOPROTECTIONALLOWEDAPPINFOID
 
 ## Configuring an Azure AD tenant for MAM enrollment
 
-MAM enrollment requires integration with Azure AD. The MAM service provider needs to publish the Management MDM app to the Azure AD app gallery. The same cloud-based Management MDM app in Azure AD will support both MDM and MAM enrollments. If you've already published your MDM app, it needs to be updated to include MAM Enrollment and Terms of use URLs. The screenshot below illustrates the management app for an IT admin configuration.
+MAM enrollment requires integration with Azure AD. The MAM service provider needs to publish the Management MDM app to the Azure AD app gallery. The same cloud-based Management MDM app in Azure AD supports both MDM and MAM enrollments. If you've already published your MDM app, it needs to be updated to include MAM Enrollment and Terms of use URLs. This screenshot illustrates the management app for an IT admin configuration.
 
 :::image type="content" alt-text="Mobile application management app." source="images/implement-server-side-mobile-application-management.png":::
 
-MAM and MDM services in an organization could be provided by different vendors. Depending on the company configuration, IT admin typically needs to add one or two Azure AD Management apps to configure MAM and MDM policies. For example, if both MAM and MDM are provided by the same vendor, then an IT Admin needs to add one Management app from this vendor that will contain both MAM and MDM policies for the organization. Alternatively, if the MAM and MDM services in an organization are provided by two different vendors, then two Management apps from the two vendors need to be configured for the company in Azure AD: one for MAM and one for MDM.
+MAM and MDM services in an organization could be provided by different vendors. Depending on the company configuration, IT admin typically needs to add one or two Azure AD Management apps to configure MAM and MDM policies. For example, if both MAM and MDM are provided by the same vendor, then an IT Admin needs to add one Management app from this vendor that contains both MAM and MDM policies for the organization. Alternatively, if the MAM and MDM services in an organization are provided by two different vendors, then two Management apps from the two vendors need to be configured for the company in Azure AD: one for MAM and one for MDM.
 
 > [!NOTE]
 > If the MDM service in an organization isn't integrated with Azure AD and uses auto-discovery, only one Management app for MAM needs to be configured.
@@ -50,11 +50,11 @@ MAM and MDM services in an organization could be provided by different vendors.
 
 MAM enrollment is based on the MAM extension of [[MS-MDE2] protocol](/openspecs/windows_protocols/ms-mde2/4d7eadd5-3951-4f1c-8159-c39e07cbe692). MAM enrollment supports Azure AD [federated authentication](federated-authentication-device-enrollment.md) as the only authentication method.
 
-Below are protocol changes for MAM enrollment:
+These are the protocol changes for MAM enrollment:
 
 - MDM discovery isn't supported.
 - APPAUTH node in [DMAcc CSP](mdm/dmacc-csp.md) is optional.
-- MAM enrollment variation of [MS-MDE2] protocol doesn't support the client authentication certificate, and therefore doesn't support the [MS-XCEP] protocol. Servers must use an Azure AD token for client authentication during policy syncs. Policy sync sessions must be performed over one-way SSL using server certificate authentication.
+- MAM enrollment variation of [MS-MDE2] protocol doesn't support the client authentication certificate, and therefore doesn't support the [MS-XCEP] protocol. Servers must use an Azure AD token for client authentication during policy syncs. Policy sync sessions must be performed over one-way TLS/SSL using server certificate authentication.
 
 Here's an example provisioning XML for MAM enrollment.
 
@@ -70,11 +70,11 @@ Here's an example provisioning XML for MAM enrollment.
 </wap-provisioningdoc>
 ```
 
-Since the [Poll](mdm/dmclient-csp.md#deviceproviderprovideridpoll) node isn't provided above, the device would default to once every 24 hours.
+Since the [Poll](mdm/dmclient-csp.md#deviceproviderprovideridpoll) node isn't provided in this example, the device would default to once every 24 hours.
 
 ## Supported CSPs
 
-MAM on Windows supports the following configuration service providers (CSPs). All other CSPs will be blocked. Note the list may change later based on customer feedback:
+MAM on Windows supports the following configuration service providers (CSPs). All other CSPs are blocked. Note the list may change later based on customer feedback:
 
 - [AppLocker CSP](mdm/applocker-csp.md) for configuration of Windows Information Protection enterprise allowed apps.
 - [ClientCertificateInstall CSP](mdm/clientcertificateinstall-csp.md) for installing VPN and Wi-Fi certs.
@@ -95,12 +95,12 @@ MAM on Windows supports the following configuration service providers (CSPs). Al
 
 MAM supports device lock policies similar to MDM. The policies are configured by DeviceLock area of Policy CSP and PassportForWork CSP.
 
-We don't recommend configuring both Exchange ActiveSync (EAS) and MAM policies for the same device. However, if both are configured, the client will behave as follows:
+We don't recommend configuring both Exchange ActiveSync (EAS) and MAM policies for the same device. However, if both are configured, the client behaves as follows:
 
 - When EAS policies are sent to a device that already has MAM policies, Windows evaluates whether the existing MAM policies are compliant with the configured EAS policies, and reports compliance with EAS.
-- If the device is found to be compliant, EAS will report compliance with the server to allow mail to sync. MAM supports mandatory EAS policies only. Checking EAS compliance doesn't require device admin rights.
+- If the device is found to be compliant, EAS reports compliance with the server to allow mail to sync. MAM supports mandatory EAS policies only. Checking EAS compliance doesn't require device admin rights.
-- If the device is found to be non-compliant, EAS will enforce its own policies to the device and the resultant set of policies will be a superset of both. Applying EAS policies to the device requires admin rights.
+- If the device is found to be noncompliant, EAS enforces its own policies to the device and the resultant set of policies are a superset of both. Applying EAS policies to the device requires admin rights.
-- If a device that already has EAS policies is enrolled to MAM, the device will have both sets of policies: MAM and EAS, and the resultant set of policies will be a superset of both.
+- If a device that already has EAS policies is enrolled to MAM, the device has both sets of policies: MAM and EAS, and the resultant set of policies are a superset of both.
 
 ## Policy sync
 
@@ -113,7 +113,7 @@ Windows doesn't support applying both MAM and MDM policies to the same devices.
 > [!NOTE]
 > When users upgrade from MAM to MDM on Windows Home edition, they lose access to Windows Information Protection. On Windows Home edition, we don't recommend pushing MDM policies to enable users to upgrade.
 
-To configure MAM device for MDM enrollment, the admin needs to configure the MDM Discovery URL in the DMClient CSP. This URL will be used for MDM enrollment.
+To configure MAM device for MDM enrollment, the admin needs to configure the MDM Discovery URL in the DMClient CSP. This URL is used for MDM enrollment.
 
 In the process of changing MAM enrollment to MDM, MAM policies will be removed from the device after MDM policies have been successfully applied. Normally when Windows Information Protection policies are removed from the device, the user's access to WIP-protected documents is revoked (selective wipe) unless EDP CSP RevokeOnUnenroll is set to false. To prevent selective wipe on enrollment change from MAM to MDM, the admin needs to ensure that:
 
@@ -121,4 +121,4 @@ In the process of changing MAM enrollment to MDM, MAM policies will be removed f
 - EDP CSP Enterprise ID is the same for both MAM and MDM.
 - EDP CSP RevokeOnMDMHandoff is set to false.
 
-If the MAM device is properly configured for MDM enrollment, then the Enroll only to device management link will be displayed in **Settings > Accounts > Access work or school**. The user can select this link, provide their credentials, and the enrollment will be changed to MDM. Their Azure AD account won't be affected.
+If the MAM device is properly configured for MDM enrollment, then the *Enroll only to device management* link is displayed in **Settings > Accounts > Access work or school**. The user can select this link, provide their credentials, and the enrollment will be changed to MDM. Their Azure AD account won't be affected.

windows/client-management/manage-windows-10-in-your-organization-modern-management.md

@@ -38,7 +38,7 @@ As indicated in the diagram, Microsoft continues to provide support for deep man
 
 With Windows, you can continue to use traditional OS deployment, but you can also "manage out of the box". To transform new devices into fully configured, fully managed devices, you can:
 
-- Avoid re-imaging by using dynamic provisioning, enabled by a cloud-based device management service such as [Windows Autopilot](/mem/autopilot/windows-autopilot) or [Microsoft Intune](/mem/intune/fundamentals/).
+- Avoid reimaging by using dynamic provisioning, enabled by a cloud-based device management service such as [Windows Autopilot](/mem/autopilot/windows-autopilot) or [Microsoft Intune](/mem/intune/fundamentals/).
 
 - Create self-contained provisioning packages built with the Windows Configuration Designer. For more information, see [Provisioning packages for Windows](/windows/configuration/provisioning-packages/provisioning-packages).
 
@@ -100,7 +100,7 @@ There are various steps you can take to begin the process of modernizing device
 
 **Assess current management practices, and look for investments you might make today.** Which of your current practices need to stay the same, and which can you change? Specifically, what elements of traditional management do you need to retain and where can you modernize? Whether you take steps to minimize custom imaging, reevaluate settings management, or reassesses authentication and compliance, the benefits can be immediate. You can use [Group policy analytics in Microsoft Intune](/mem/intune/configuration/group-policy-analytics) to help determine which group policies supported by cloud-based MDM providers, including Microsoft Intune.
 
-**Assess the different use cases and management needs in your environment.** Are there groups of devices that could benefit from lighter, simplified management? BYOD devices, for example, are natural candidates for cloud-based management. Users or devices handling more highly regulated data might require an on-premises Active Directory domain for authentication. Configuration Manager and EMS provide you the flexibility to stage implementation of modern management scenarios while targeting different devices the way that best suits your business needs.
+**Assess the different use cases and management needs in your environment.** Are there groups of devices that could benefit from lighter, simplified management? BYOD devices, for example, are natural candidates for cloud-based management. Users or devices handling more highly regulated data might require an on-premises Active Directory domain for authentication. Configuration Manager and EMS provide you with the flexibility to stage implementation of modern management scenarios while targeting different devices the way that best suits your business needs.
 
 **Review the decision trees in this article.** With the different options in Windows, plus Configuration Manager and Enterprise Mobility + Security, you have the flexibility to handle imaging, authentication, settings, and management tools for any scenario.
 

windows/client-management/mdm-collect-logs.md

@@ -15,14 +15,14 @@ To help diagnose enrollment or device management issues in Windows devices manag
 ## Download the MDM Diagnostic Information log from Windows devices
 
 1. On your managed device, go to **Settings** > **Accounts** > **Access work or school**.
-1. Click your work or school account, then click **Info**.
+1. Select your work or school account, then select **Info**.
 
    ![Access work or school page in Settings.](images/diagnose-mdm-failures15.png)
 
-1. At the bottom of the **Settings** page, click **Create report**.
+1. At the bottom of the **Settings** page, select **Create report**.
 
    ![Access work or school page and then Create report.](images/diagnose-mdm-failures16.png)
-1. A window opens that shows the path to the log files. Click **Export**.
+1. A window opens that shows the path to the log files. Select **Export**.
 
    ![Access work or school log files.](images/diagnose-mdm-failures17.png)
 
@@ -40,12 +40,12 @@ mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zi
 
 ### Understanding zip structure
 
-The zip file will have logs according to the areas that were used in the command. This explanation is based on DeviceEnrollment, DeviceProvisioning and Autopilot areas. It applies to the zip files collected via command line or Feedback Hub
+The zip file has logs according to the areas that were used in the command. This explanation is based on DeviceEnrollment, DeviceProvisioning and Autopilot areas. It applies to the zip files collected via command line or Feedback Hub
 
 - DiagnosticLogCSP_Collector_Autopilot_*: Autopilot etls
 - DiagnosticLogCSP_Collector_DeviceProvisioning_*: Provisioning etls (Microsoft-Windows-Provisioning-Diagnostics-Provider)
 - MDMDiagHtmlReport.html: Summary snapshot of MDM configurations and policies. Includes, management url, MDM server device ID, certificates, policies.
-- MdmDiagLogMetadata, json: mdmdiagnosticstool metadata file, contains command-line arguments used to run the tool
+- MdmDiagLogMetadata.json: mdmdiagnosticstool metadata file that contains command-line arguments used to run the tool.
 - MDMDiagReport.xml: contains a more detailed view into the MDM configurations, such as enrollment variables, provisioning packages, multivariant conditions, and others. For more information about diagnosing provisioning packages, see [Diagnose provisioning packages](/windows/configuration/provisioning-packages/diagnose-provisioning-packages).
 - MdmDiagReport_RegistryDump.reg: contains dumps from common MDM registry locations
 - MdmLogCollectorFootPrint.txt: mdmdiagnosticslog tool logs from running the command
@@ -65,23 +65,23 @@ In this location, the **Admin** channel logs events by default. However, if you
 
 ### Collect admin logs
 
-1. Right click on the **Admin** node.
+1. Right-click the **Admin** node.
 1. Select **Save all events as**.
 1. Choose a location and enter a filename.
-1. Click **Save**.
+1. Select **Save**.
 1. Choose **Display information for these languages** and then select **English**.
-1. Click **Ok**.
+1. Select **Ok**.
 
-For more detailed logging, you can enable **Debug** logs. Right click on the **Debug** node and then click **Enable Log**.
+For more detailed logging, you can enable **Debug** logs. Right-click on the **Debug** node and then select **Enable Log**.
 
 ### Collect debug logs
 
-1. Right click on the **Debug** node.
+1. Right-click on the **Debug** node.
 1. Select **Save all events as**.
 1. Choose a location and enter a filename.
-1. Click **Save**.
+1. Select **Save**.
 1. Choose **Display information for these languages** and then select **English**.
-1. Click **Ok**.
+1. Select **Ok**.
 
 You can open the log files (.evtx files) in the Event Viewer on a Windows device.
 
@@ -241,17 +241,17 @@ For best results, ensure that the PC or VM on which you're viewing logs matches
     ![event viewer screenshot.](images/diagnose-mdm-failures9.png)
 
 1. Navigate to the etl file that you got from the device and then open the file.
-1. Click **Yes** when prompted to save it to the new log format.
+1. Select **Yes** when prompted to save it to the new log format.
 
     ![event viewer prompt.](images/diagnose-mdm-failures10.png)
 
     ![diagnose mdm failures.](images/diagnose-mdm-failures11.png)
 
-1. The new view contains traces from the channel. Click on **Filter Current Log** from the **Actions** menu.
+1. The new view contains traces from the channel. Select **Filter Current Log** from the **Actions** menu.
 
     ![event viewer actions.](images/diagnose-mdm-failures12.png)
 
-1. Add a filter to Event sources by selecting **DeviceManagement-EnterpriseDiagnostics-Provider** and click **OK**.
+1. Add a filter to Event sources by selecting **DeviceManagement-EnterpriseDiagnostics-Provider** and select **OK**.
 
     ![event filter for Device Management.](images/diagnose-mdm-failures13.png)
 

windows/client-management/mdm-diagnose-enrollment.md

@@ -9,15 +9,15 @@ ms.date: 08/10/2023
 
 This article provides suggestions for troubleshooting device enrollment issues for MDM.
 
-## Verify auto-enrollment requirements and settings
+## Verify autoenrollment requirements and settings
 
-To ensure that the auto-enrollment feature is working as expected, you must verify that various requirements and settings are configured correctly. The following steps demonstrate required settings using the Intune service:
+To ensure that the autoenrollment feature is working as expected, you must verify that various requirements and settings are configured correctly. The following steps demonstrate required settings using the Intune service:
 
 1. Verify that the user who is going to enroll the device has a valid [Intune license](/mem/intune/fundamentals/licenses).
 
    :::image type="content" alt-text="Screenshot of Intune license verification." source="images/auto-enrollment-intune-license-verification.png" lightbox="images/auto-enrollment-intune-license-verification.png":::
 
-1. Verify that auto-enrollment is activated for those users who are going to enroll the devices into Mobile Device Management (MDM) with Intune. For more information, see [Azure AD and Microsoft Intune: Automatic MDM enrollment in the new Portal](./azure-ad-and-microsoft-intune-automatic-mdm-enrollment-in-the-new-portal.md).
+1. Verify that autoenrollment is activated for those users who are going to enroll the devices into Mobile Device Management (MDM) with Intune. For more information, see [Azure AD and Microsoft Intune: Automatic MDM enrollment in the new Portal](./azure-ad-and-microsoft-intune-automatic-mdm-enrollment-in-the-new-portal.md).
 
     ![Auto-enrollment activation verification.](images/auto-enrollment-activation-verification.png)
 
@@ -28,7 +28,7 @@ To ensure that the auto-enrollment feature is working as expected, you must veri
 
 1. Verify that the device is running a [supported version of Windows](/windows/release-health/supported-versions-windows-client).
 
-1. Auto-enrollment into Intune via Group Policy is valid only for devices that are hybrid Azure AD joined. This condition means that the device must be joined into both local Active Directory and Azure Active Directory. To verify that the device is hybrid Azure AD joined, run `dsregcmd /status` from the command line.
+1. Autoenrollment into Intune via Group Policy is valid only for devices that are hybrid Azure AD joined. This condition means that the device must be joined into both local Active Directory and Azure Active Directory. To verify that the device is hybrid Azure AD joined, run `dsregcmd /status` from the command line.
 
     You can confirm that the device is properly hybrid-joined if both **AzureAdJoined** and **DomainJoined** are set to **YES**.
 
@@ -40,13 +40,13 @@ To ensure that the auto-enrollment feature is working as expected, you must veri
 
     This information can also be found on the Azure AD device list.
 
-1. Verify that the MDM discovery URL during auto-enrollment is `https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc`.
+1. Verify that the MDM discovery URL during autoenrollment is `https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc`.
 
     ![MDM discovery URL.](images/auto-enrollment-mdm-discovery-url.png)
 
-1. Some tenants might have both **Microsoft Intune** and **Microsoft Intune Enrollment** under **Mobility**. Make sure that your auto-enrollment settings are configured under **Microsoft Intune** instead of **Microsoft Intune Enrollment**.
+1. Some tenants might have both **Microsoft Intune** and **Microsoft Intune Enrollment** under **Mobility**. Make sure that your autoenrollment settings are configured under **Microsoft Intune** instead of **Microsoft Intune Enrollment**.
 
-   :::image type="content" alt-text="Screenshot of Mobility setting MDM intune." source="images/auto-enrollment-microsoft-intune-setting.png" lightbox="images/auto-enrollment-microsoft-intune-setting.png":::
+   :::image type="content" alt-text="Screenshot of Mobility setting MDM Intune." source="images/auto-enrollment-microsoft-intune-setting.png" lightbox="images/auto-enrollment-microsoft-intune-setting.png":::
 
 1. When using group policy for enrollment, verify that the *Enable Automatic MDM enrollment using default Azure AD credentials* group policy (**Local Group Policy Editor > Computer Configuration > Policies > Administrative Templates > Windows Components > MDM**) is properly deployed to all devices that should be enrolled into Intune. You may contact your domain administrators to verify if the group policy has been deployed successfully.
 
@@ -56,7 +56,7 @@ To ensure that the auto-enrollment feature is working as expected, you must veri
 
 ## Troubleshoot group policy enrollment
 
-Investigate the logs if you have issues even after performing all the verification steps. The first log file to investigate is the event log on the target Windows device. To collect Event Viewer logs:
+Investigate the logs if you have issues even after performing all the verification steps. The first log file to investigate is the event log, on the target Windows device. To collect Event Viewer logs:
 
 1. Open Event Viewer.
 
@@ -65,21 +65,21 @@ Investigate the logs if you have issues even after performing all the verificati
     > [!TIP]
     > For guidance on how to collect event logs for Intune, see [Collect MDM Event Viewer Log YouTube video](https://www.youtube.com/watch?v=U_oCe2RmQEc).
 
-1. Search for event ID 75, which represents a successful auto-enrollment. Here's an example screenshot that shows the auto-enrollment completed successfully:
+1. Search for event ID 75, which represents a successful autoenrollment. Here's an example screenshot that shows the autoenrollment completed successfully:
 
    :::image type="content" alt-text="Screenshot of Event ID 75." source="images/auto-enrollment-troubleshooting-event-id-75.png"  lightbox="images/auto-enrollment-troubleshooting-event-id-75.png":::
 
-If you can't find event ID 75 in the logs, it indicates that the auto-enrollment failed. This failure can happen because of the following reasons:
+If you can't find event ID 75 in the logs, it indicates that the autoenrollment failed. This failure can happen because of the following reasons:
 
-- The enrollment failed with error. In this case, search for event ID 76, which represents failed auto-enrollment. Here's an example screenshot that shows that the auto-enrollment failed:
+- The enrollment failed with error. In this case, search for event ID 76, which represents failed autoenrollment. Here's an example screenshot that shows that the autoenrollment failed:
 
    :::image type="content" alt-text="Screenshot of Event ID 76." source="images/auto-enrollment-troubleshooting-event-id-76.png" lightbox="images/auto-enrollment-troubleshooting-event-id-76.png":::
 
    To troubleshoot, check the error code that appears in the event. For more information, see [Troubleshooting Windows device enrollment problems in Microsoft Intune](/troubleshoot/mem/intune/troubleshoot-windows-enrollment-errors).
 
-- The auto-enrollment didn't trigger at all. In this case, you'll not find either event ID 75 or event ID 76. To know the reason, you must understand the internal mechanisms happening on the device as described below:
+- The autoenrollment didn't trigger at all. In this case, you won't find either event ID 75 or event ID 76. To know the reason, you must understand the internal mechanisms happening on the device as described here:
 
-   The auto-enrollment process is triggered by a task (**Microsoft** > **Windows** > **EnterpriseMgmt**) within the task-scheduler. This task appears if the *Enable automatic MDM enrollment using default Azure AD credentials* group policy (**Computer Configuration** > **Policies** > **Administrative Templates** > **Windows Components** > **MDM**) is successfully deployed to the target machine as shown in the following screenshot:
+   The autoenrollment process is triggered by a task (**Microsoft** > **Windows** > **EnterpriseMgmt**) within the task-scheduler. This task appears if the *Enable automatic MDM enrollment using default Azure AD credentials* group policy (**Computer Configuration** > **Policies** > **Administrative Templates** > **Windows Components** > **MDM**) is successfully deployed to the target machine as shown in the following screenshot:
 
    :::image type="content" alt-text="Screenshot of Task scheduler." source="images/auto-enrollment-task-scheduler.png" lightbox="images/auto-enrollment-task-scheduler.png":::
 
@@ -94,16 +94,16 @@ If you can't find event ID 75 in the logs, it indicates that the auto-enrollment
 
    :::image type="content" alt-text="Screenshot of Event ID 102." source="images/auto-enrollment-event-id-102.png" lightbox="images/auto-enrollment-event-id-102.png":::
 
-   The task scheduler log displays event ID 102 (task completed) regardless of the auto-enrollment success or failure. This status-display means that the task scheduler log is only useful to confirm if the auto-enrollment task is triggered or not. It doesn't indicate the success or failure of auto-enrollment.
+   The task scheduler log displays event ID 102 (task completed) regardless of the autoenrollment success or failure. This status-display means that the task scheduler log is only useful to confirm if the autoenrollment task is triggered or not. It doesn't indicate the success or failure of autoenrollment.
 
    If you can't see from the log that task Schedule created by enrollment client for automatically enrolling in MDM from Azure AD is initiated, there's possibly an issue with the group policy. Immediately run the command `gpupdate /force` in a command prompt to get the group policy object applied. If this step still doesn't help, further troubleshooting on Active Directory is required.
    One frequently seen error is related to some outdated enrollment entries in the registry on the target client device (**HKLM > Software > Microsoft > Enrollments**). If a device has been enrolled (can be any MDM solution and not only Intune), some enrollment information added into the registry is seen:
 
    :::image type="content" alt-text="Screenshot of Outdated enrollment entries." source="images/auto-enrollment-outdated-enrollment-entries.png" lightbox="images/auto-enrollment-outdated-enrollment-entries.png":::
 
-   By default, these entries are removed when the device is un-enrolled, but occasionally the registry key remains even after un-enrollment. In this case, `gpupdate /force` fails to initiate the auto-enrollment task and error code 2149056522 is displayed in the **Applications and Services Logs** > **Microsoft** > **Windows** > **Task Scheduler** > **Operational** event log file under event ID 7016.
+   By default, these entries are removed when the device is unenrolled, but occasionally the registry key remains even after unenrollment. In this case, `gpupdate /force` fails to initiate the autoenrollment task and error code 2149056522 is displayed in the **Applications and Services Logs** > **Microsoft** > **Windows** > **Task Scheduler** > **Operational** event log file under event ID 7016.
 
-   A resolution to this issue is to remove the registry key manually. If you don't know which registry key to remove, go for the key that displays most entries as the screenshot above. All other keys will display fewer entries as shown in the following screenshot:
+   A resolution to this issue is to remove the registry key manually. If you don't know which registry key to remove, go for the key that displays most entries as the previous screenshot shows. All other keys display fewer entries as shown in the following screenshot:
 
    :::image type="content" alt-text="Screenshot showing manually deleted entries." source="images/auto-enrollment-activation-verification-less-entries.png" lightbox="images/auto-enrollment-activation-verification-less-entries.png":::
 

windows/client-management/mdm-enrollment-of-windows-devices.md

@@ -42,11 +42,11 @@ To join a domain:
 
 1. Type in your Azure AD username. This username is the email address you use to log into Microsoft Office 365 and similar services.
 
-    If the tenant is a cloud-only, password hash sync, or pass-through authentication tenant, this page will change to show the organization's custom branding, and you'll be able to enter your password directly on this page. If the tenant is part of a federated domain, you'll be redirected to the organization's on-premises federation server, such as Active Directory Federation Services (AD FS) for authentication.
+    If the tenant is a cloud-only, password hash sync, or pass-through authentication tenant, this page changes to show the organization's custom branding, and you're able to enter your password directly on this page. If the tenant is part of a federated domain, you're redirected to the organization's on-premises federation server, such as Active Directory Federation Services (AD FS) for authentication.
 
     Based on IT policy, you may also be prompted to provide a second factor of authentication at this point.
 
-    If your Azure AD tenant has auto-enrollment configured, your device will also be enrolled into MDM during this flow. For more information, see [these steps](azure-ad-and-microsoft-intune-automatic-mdm-enrollment-in-the-new-portal.md). If your tenant isn't configured for auto-enrollment, you'll have to go through the enrollment flow a second time to [connect your device to MDM](#enroll-in-device-management-only). After you complete the flow, your device will be connected to your organization's Azure AD domain.
+    If your Azure AD tenant has autoenrollment configured, your device also gets enrolled into MDM during this flow. For more information, see [these steps](azure-ad-and-microsoft-intune-automatic-mdm-enrollment-in-the-new-portal.md). If your tenant isn't configured for autoenrollment, you must go through the enrollment flow a second time to [connect your device to MDM](#enroll-in-device-management-only). After you complete the flow, your device will be connected to your organization's Azure AD domain.
 
     ![azure ad signin.](images/unifiedenrollment-rs1-13.png)
 
@@ -82,7 +82,7 @@ To create a local account and connect the device:
 
     Based on IT policy, you may also be prompted to provide a second factor of authentication at this point.
 
-    If your Azure AD tenant has auto-enrollment configured, your device will also be enrolled into MDM during this flow. For more information, see [this blog post](https://blogs.technet.microsoft.com/enterprisemobility/2015/08/14/windows-10-azure-ad-and-microsoft-intune-automatic-mdm-enrollment-powered-by-the-cloud/). If your tenant isn't configured for auto-enrollment, you'll have to go through the enrollment flow a second time to connect your device to MDM.
+    If your Azure AD tenant has autoenrollment configured, your device also gets enrolled into MDM during this flow. For more information, see [this blog post](https://blogs.technet.microsoft.com/enterprisemobility/2015/08/14/windows-10-azure-ad-and-microsoft-intune-automatic-mdm-enrollment-powered-by-the-cloud/). If your tenant isn't configured for autoenrollment, you must go through the enrollment flow a second time to connect your device to MDM.
 
     After you reach the end of the flow, your device should be connected to your organization's Azure AD domain. You may now sign out of your current account and sign in using your Azure AD username.
 
@@ -97,9 +97,9 @@ There are a few instances where your device can't be connected to an Azure AD do
 | Your device is connected to an Azure AD domain. | Your device can only be connected to a single Azure AD domain at a time. |
 | Your device is already connected to an Active Directory domain. | Your device can either be connected to an Azure AD domain or an Active Directory domain. You can't connect to both simultaneously. |
 | Your device already has a user connected to a work account. | You can either connect to an Azure AD domain or connect to a work or school account. You can't connect to both simultaneously. |
-| You're logged in as a standard user. | Your device can only be connected to an Azure AD domain if you're logged in as an administrative user. You'll need to switch to an administrator account to continue. |
+| You're logged in as a standard user. | Your device can only be connected to an Azure AD domain if you're logged in as an administrative user. You must switch to an administrator account to continue. |
-| Your device is already managed by MDM. | The connect to Azure AD flow will attempt to enroll your device into MDM if your Azure AD tenant has a preconfigured MDM endpoint. Your device must be unenrolled from MDM to be able to connect to Azure AD in this case. |
+| Your device is already managed by MDM. | The connect to Azure AD flow attempts to enroll your device into MDM if your Azure AD tenant has a preconfigured MDM endpoint. Your device must be unenrolled from MDM to be able to connect to Azure AD in this case. |
-| Your device is running Home edition. | This feature isn't available on Windows Home edition, so you'll be unable to connect to an Azure AD domain. You'll need to upgrade to Pro, Enterprise, or Education edition to continue. |
+| Your device is running Home edition. | This feature isn't available on Windows Home edition, so you can't connect to an Azure AD domain. You must upgrade to Pro, Enterprise, or Education edition to continue. |
 
 ## Connect personally owned devices
 
@@ -107,7 +107,7 @@ Personally owned devices, also known as bring your own device (BYOD), can be con
 
 All Windows devices can be connected to a work or school account. You can connect to a work or school account either through the Settings app or through any of the numerous Universal Windows Platform (UWP) apps, such as the universal Office apps.
 
-### Register device in AAD and enroll in MDM
+### Register device in Azure AD and enroll in MDM
 
 To create a local account and connect the device:
 
@@ -131,9 +131,9 @@ To create a local account and connect the device:
 
     Based on IT policy, you may also be prompted to provide a second factor of authentication at this point.
 
-    If your Azure AD tenant has auto-enrollment configured, your device will also be enrolled into MDM during this flow. For more information, see [this blog post](https://blogs.technet.microsoft.com/enterprisemobility/2015/08/14/windows-10-azure-ad-and-microsoft-intune-automatic-mdm-enrollment-powered-by-the-cloud/). If your tenant isn't configured for auto-enrollment, you'll have to go through the enrollment flow a second time to [connect your device to MDM](#enroll-in-device-management-only).
+    If your Azure AD tenant has autoenrollment configured, your device also gets enrolled into MDM during this flow. For more information, see [this blog post](https://blogs.technet.microsoft.com/enterprisemobility/2015/08/14/windows-10-azure-ad-and-microsoft-intune-automatic-mdm-enrollment-powered-by-the-cloud/). If your tenant isn't configured for autoenrollment, you must go through the enrollment flow a second time to [connect your device to MDM](#enroll-in-device-management-only).
 
-    You'll see the status page that shows the progress of your device being set up.
+    You can see the status page that shows the progress of your device being set up.
 
     ![corporate sign in - screen and option](images/unifiedenrollment-rs1-26.png)
 
@@ -151,7 +151,7 @@ There are a few instances where your device may not be able to connect to work.
 | We couldn't find your identity in your organization's cloud. | The username you entered wasn't found on your Azure AD tenant. |
 | Your device is already being managed by an organization. | Your device is either already managed by MDM or Microsoft Configuration Manager. |
 | You don't have the right privileges to perform this operation. Talk to your admin. | You can't enroll your device into MDM as a standard user. You must be on an administrator account. |
-| We couldn't auto-discover a management endpoint matching the username entered. Check your username and try again. If you know the URL to your management endpoint, enter it. | You need to provide the server URL for your MDM or check the spelling of the username you entered. |
+| We couldn't autodiscover a management endpoint matching the username entered. Check your username and try again. If you know the URL to your management endpoint, enter it. | You need to provide the server URL for your MDM or check the spelling of the username you entered. |
 
 ## Enroll in device management only
 
@@ -177,27 +177,27 @@ All Windows devices can be connected to MDM. You can connect to an MDM through t
 
    ![set up work or school account screen](images/unifiedenrollment-rs1-32.png)
 
-1. If the device finds an endpoint that only supports on-premises authentication, this page will change and ask you for your password. If the device finds an MDM endpoint that supports federated authentication, you'll be presented with a new window that will ask you for more authentication information.
+1. If the device finds an endpoint that only supports on-premises authentication, this page changes and ask you for your password. If the device finds an MDM endpoint that supports federated authentication, you're presented with a new window that asks you for more authentication information.
 
-   Based on IT policy, you may also be prompted to provide a second factor of authentication at this point. You'll see the enrollment progress on screen.
+   Based on IT policy, you may also be prompted to provide a second factor of authentication at this point. You can see the enrollment progress on screen.
 
    ![screen to set up your device](images/unifiedenrollment-rs1-33-b.png)
 
-   After you complete the flow, your device will be connected to your organization's MDM.
+   After you complete the flow, your device is connected to your organization's MDM.
 
 ## Connect your Windows device to work using a deep link
 
-Windows devices may be connected to work using a deep link. Users will be able to select or open a link in a particular format from anywhere in Windows, and be directed to the new enrollment experience.
+Windows devices may be connected to work using a deep link. Users can select or open a link in a particular format from anywhere in Windows, and be directed to the new enrollment experience.
 
-The deep link used for connecting your device to work will always use the following format.
+The deep link used for connecting your device to work uses the following format.
 
 **ms-device-enrollment:?mode={mode\_name}**:
 
 | Parameter | Description | Supported Value for Windows |
 |--|--|--|
-| mode | Describes which mode will be executed in the enrollment app. | Mobile Device Management (MDM), Adding Work Account (AWA), and Azure Active Directory-joined. |
+| mode | Describes which mode is executed in the enrollment app. | Mobile Device Management (MDM), Adding Work Account (AWA), and Azure Active Directory-joined. |
 | username | Specifies the email address or UPN of the user who should be enrolled into MDM. | string |
-| servername | Specifies the MDM server URL that will be used to enroll the device. | string |
+| servername | Specifies the MDM server URL that is used to enroll the device. | string |
 | accesstoken | Custom parameter for MDM servers to use as they see fit. Typically, this parameter's value can be used as a token to validate the enrollment request. | string |
 | deviceidentifier | Custom parameter for MDM servers to use as they see fit. Typically, this parameter's value can be used to pass in a unique device identifier. | GUID |
 | tenantidentifier | Custom parameter for MDM servers to use as they see fit. Typically, this parameter's value can be used to identify which tenant the device or user belongs to. | GUID or string |
@@ -215,7 +215,7 @@ To connect your devices to MDM using deep links:
 
 1. Create a link to launch the built-in enrollment app using the URI **ms-device-enrollment:?mode=mdm**, and user-friendly display text, such as **Click here to connect Windows to work**:
 
-    (This link will launch the flow equivalent to the Enroll into the device management option.)
+    This link launches the flow equivalent to the Enroll into the device management option.
 
     - IT admins can add this link to a welcome email that users can select to enroll into MDM.
 
@@ -232,7 +232,7 @@ To connect your devices to MDM using deep links:
 
     ![set up a work or school account screen](images/deeplinkenrollment3.png)
 
-1. If the device finds an endpoint that only supports on-premises authentication, this page will change and ask you for your password. If the device finds an MDM endpoint that supports federated authentication, you'll be presented with a new window that will ask you for more authentication information. Based on IT policy, you may also be prompted to provide a second factor of authentication at this point.
+1. If the device finds an endpoint that only supports on-premises authentication, this page changes and asks you for your password. If the device finds an MDM endpoint that supports federated authentication, you're presented with a new window that asks for more authentication information. Based on IT policy, you may also be prompted to provide a second factor of authentication at this point.
 
     After you complete the flow, your device will be connected to your organization's MDM.
 
@@ -240,7 +240,7 @@ To connect your devices to MDM using deep links:
 
 ## Manage connections
 
-To manage your work or school connections, select **Settings** > **Accounts** > **Access work or school**. Your connections will show on this page and selecting one will expand options for that connection.
+To manage your work or school connections, select **Settings** > **Accounts** > **Access work or school**. Your connections are displayed on this page and selecting one expands options for that connection.
 
 ![managing work or school account.](images/unifiedenrollment-rs1-34-b.png)
 
@@ -248,21 +248,21 @@ To manage your work or school connections, select **Settings** > **Accounts** >
 
 The **Info** button can be found on work or school connections involving MDM. This button is included in the following scenarios:
 
-- Connecting your device to an Azure AD domain that has auto-enroll into MDM configured.
+- Connecting your device to an Azure AD domain that has autoenroll into MDM configured.
-- Connecting your device to a work or school account that has auto-enroll into MDM configured.
+- Connecting your device to a work or school account that has autoenroll into MDM configured.
 - Connecting your device to MDM.
 
-Selecting the **Info** button will open a new page in the Settings app that provides details about your MDM connection. You'll be able to view your organization's support information (if configured) on this page. You'll also be able to start a sync session that forces your device to communicate to the MDM server and fetch any updates to policies if needed.
+Selecting the **Info** button opens a new page in the Settings app that provides details about your MDM connection. You're able to view your organization's support information (if configured) on this page. You can also start a sync session that forces your device to communicate to the MDM server and fetch any updates to policies if needed.
 
-Selecting the **Info** button will show a list of policies and line-of-business apps installed by your organization. Here's an example screenshot.
+Selecting the **Info** button shows a list of policies and line-of-business apps installed by your organization. Here's an example screenshot.
 
 ![work or school info.](images/unifiedenrollment-rs1-35-b.png)
 
 ### Disconnect
 
-The **Disconnect** button can be found on all work connections. Generally, selecting the **Disconnect** button will remove the connection from the device. There are a few exceptions to this functionality:
+The **Disconnect** button can be found on all work connections. Generally, selecting the **Disconnect** button removes the connection from the device. There are a few exceptions to this functionality:
 
-- Devices that enforce the AllowManualMDMUnenrollment policy won't allow users to remove MDM enrollments. These connections must be removed by a server-initiated unenroll command.
+- Devices that enforce the AllowManualMDMUnenrollment policy don't allow users to remove MDM enrollments. These connections must be removed by a server-initiated unenroll command.
 - On mobile devices, you can't disconnect from Azure AD. These connections can only be removed by wiping the device.
 
 > [!WARNING]
@@ -272,6 +272,6 @@ The **Disconnect** button can be found on all work connections. Generally, selec
 
 You can collect diagnostic logs around your work connections by going to **Settings** > **Accounts** > **Access work or school**, and then selecting the **Export your management logs** link under **Related Settings**. Next, select **Export**, and follow the path displayed to retrieve your management log files.
 
-You can get the advanced diagnostic report by going to **Settings** > **Accounts** > **Access work or school**, and selecting the **Info** button. At the bottom of the Settings page, you'll see the button to create a report.
+You can get the advanced diagnostic report by going to **Settings** > **Accounts** > **Access work or school**, and selecting the **Info** button. At the bottom of the Settings page, you see the button to create a report.
 
 For more information, see [Collect MDM logs](mdm-collect-logs.md).

windows/client-management/mdm-known-issues.md

@@ -27,7 +27,7 @@ The certificate setting under "SSL Settings" in the IIS server for SCEP must be
 
 ## MDM enrollment fails on the Windows device when traffic is going through proxy
 
-When the Windows device is configured to use a proxy that requires authentication, the enrollment will fail. To work around this issue, the user can use a proxy that doesn't require authentication or remove the proxy setting from the connected network.
+When the Windows device is configured to use a proxy that requires authentication, the enrollment fails. To work around this issue, the user can use a proxy that doesn't require authentication or remove the proxy setting from the connected network.
 
 ## Server-initiated unenrollment failure
 
@@ -37,7 +37,7 @@ Remote server unenrollment is disabled for mobile devices enrolled via Azure Act
 
 ## Certificates causing issues with Wi-Fi and VPN
 
-When using the ClientCertificateInstall to install certificates to the device store and the user store and both certificates are sent to the device in the same MDM payload, the certificate intended for the device store will also get installed in the user store. This dual installation may cause issues with Wi-Fi or VPN when choosing the correct certificate to establish a connection. We're working to fix this issue.
+When using the ClientCertificateInstall to install certificates to the device store and the user store and both certificates are sent to the device in the same MDM payload, the certificate intended for the device store also gets installed in the user store. This dual installation may cause issues with Wi-Fi or VPN when choosing the correct certificate to establish a connection. We're working to fix this issue.
 
 ## Version information for Windows 11
 
@@ -56,7 +56,7 @@ A production ready deployment must have the appropriate certificate details as p
 
 EAP XML must be updated with relevant information for your environment. This task can be done either manually by editing the XML sample below, or by using the step by step UI guide. After the EAP XML is updated, refer to instructions from your MDM to deploy the updated configuration as follows:
 
-- For Wi-Fi, look for the <EAPConfig> section of your current WLAN Profile XML (This detail is what you specify for the WLanXml node in the Wi-Fi CSP). Within these tags, you'll find the complete EAP configuration. Replace the section under <EAPConfig> with your updated XML and update your Wi-Fi profile. You might need to refer to your MDM's guidance on how to deploy a new Wi-Fi profile.
+- For Wi-Fi, look for the <EAPConfig> section of your current WLAN Profile XML (This detail is what you specify for the WLanXml node in the Wi-Fi CSP). Within these tags, you can find the complete EAP configuration. Replace the section under <EAPConfig> with your updated XML and update your Wi-Fi profile. You might need to refer to your MDM's guidance on how to deploy a new Wi-Fi profile.
 - For VPN, EAP Configuration is a separate field in the MDM Configuration. Work with your MDM provider to identify and update the appropriate Field.
 
 For information about EAP Settings, see [Extensible Authentication Protocol (EAP) for network access](/windows-server/networking/technologies/extensible-authentication-protocol/network-access).
@@ -199,7 +199,7 @@ Alternatively you can use the following procedure to create an EAP Configuration
     > [!NOTE]
     > For PEAP or TTLS, select the appropriate method and continue following this procedure.
 
-1. Click the **Properties** button underneath the drop-down menu.
+1. Select the **Properties** button underneath the drop-down menu.
 
 1. In the **Smart Card or other Certificate Properties** menu, select the **Advanced** button.
 
@@ -209,7 +209,7 @@ Alternatively you can use the following procedure to create an EAP Configuration
 
     :::image type="content" alt-text="configure certificate selection window." source="images/certfiltering3.png":::
 
-1. Click **OK** to close the windows to get back to the main `rasphone.exe` dialog box.
+1. Select **OK** to close the windows to get back to the main `rasphone.exe` dialog box.
 
 1. Close the rasphone dialog box.
 

windows/client-management/mdm-overview.md

@@ -18,7 +18,7 @@ There are two parts to the Windows management component:
 - The enrollment client, which enrolls and configures the device to communicate with the enterprise management server. For more information, see [Enrollment overview](mobile-device-enrollment.md).
 - The management client, which periodically synchronizes with the management server to check for updates and apply the latest policies set by IT.
 
-Third-party MDM servers can manage Windows devices using the MDM protocol. The built-in management client is able to communicate with a third-party server proxy that supports the protocols outlined in this document to perform enterprise management tasks. The third-party server will have the same consistent first-party user experience for enrollment, which also provides simplicity for Windows users. MDM servers don't need to create or download a client to manage Windows.
+Third-party MDM servers can manage Windows devices using the MDM protocol. The built-in management client is able to communicate with a third-party server proxy that supports the protocols outlined in this document to perform enterprise management tasks. The third-party server has the same consistent first-party user experience for enrollment, which also provides simplicity for Windows users. MDM servers don't need to create or download a client to manage Windows.
 
 For details about the MDM protocols, see
 
@@ -59,7 +59,7 @@ No. Only one MDM is allowed.
 ### How do I set the maximum number of Azure Active Directory-joined devices per user?
 
 1. Sign in to the portal as tenant admin: <https://portal.azure.com>.
-1. Navigate to **Azure AD**, then **Devices**, and then click **Device Settings**.
+1. Navigate to **Azure AD**, then **Devices**, and then select **Device Settings**.
 1. Change the number under **Maximum number of devices per user**.
 
 ### What is dmwappushsvc?
@@ -68,4 +68,4 @@ No. Only one MDM is allowed.
 | --------------- | -------------------- |
 | What is dmwappushsvc? | It's a Windows service that ships in Windows operating system as a part of the windows management platform. It's used internally by the operating system as a queue for categorizing and processing all Wireless Application Protocol (WAP) messages, which include Windows management messages, and Service Indication/Service Loading (SI/SL). The service also initiates and orchestrates management sync sessions with the MDM server. |
 | What data is handled by dmwappushsvc? | It's a component handling the internal workings of the management platform and involved in processing messages that have been received by the device remotely for management. The messages in the queue are serviced by another component that is also part of the Windows management stack to process messages. The service also routes and authenticates WAP messages received by the device to internal OS components that process them further. This service doesn't send telemetry. |
-| How do I turn if off? | The service can be stopped from the "Services" console on the device (Start > Run > services.msc) and locating *Device Management Wireless Application Protocol (WAP) Push message Routing Service*. However, since this service is a component part of the OS and  required for the proper functioning of the device, we strongly recommend not to disable the service. Disabling this service will cause your management to fail. |
+| How do I turn if off? | The service can be stopped from the "Services" console on the device (Start > Run > services.msc) and locating *Device Management Wireless Application Protocol (WAP) Push message Routing Service*. However, since this service is a component part of the OS and  required for the proper functioning of the device, we strongly recommend not to disable the service. Disabling this service causes your management to fail. |

windows/client-management/mobile-device-enrollment.md

@@ -1,6 +1,6 @@
 ---
 title: Mobile device enrollment
-description: Learn how mobile device enrollment verifies that only authenticated and authorized devices can be managed by their enterprise.
+description: Learn how mobile device enrollment verifies that only authenticated and authorized devices are managed by the enterprise.
 ms.topic: article
 ms.date: 08/10/2023
 ms.collection:
@@ -10,12 +10,12 @@ ms.collection:
 
 # Mobile device enrollment
 
-Mobile device enrollment is the first phase of enterprise management. The device is configured to communicate with the MDM server using security precautions during the enrollment process. The enrollment service verifies that only authenticated and authorized devices can be managed by their enterprise.
+Mobile device enrollment is the first phase of enterprise management. The device is configured to communicate with the MDM server using security precautions during the enrollment process. The enrollment service verifies that only authenticated and authorized devices are managed by the enterprise.
 
 The enrollment process includes the following steps:
 
 1. **Discovery of the enrollment endpoint**: This step provides the enrollment endpoint configuration settings.
-1. **Certificate installation**: This step handles user authentication, certificate generation, and certificate installation. The installed certificates will be used in the future to manage client/server Secure Sockets Layer (SSL) mutual authentication.
+1. **Certificate installation**: This step handles user authentication, certificate generation, and certificate installation. The installed certificates will be used in the future to manage client/server (TLS/SSL) mutual authentication.
 1. **DM Client provisioning**: This step configures the Device Management (DM) client to connect to a Mobile Device Management (MDM) server after enrollment via DM SyncML over HTTPS (also known as Open Mobile Alliance Device Management (OMA DM) XML).
 
 ## Enrollment protocol
@@ -43,9 +43,9 @@ The certificate enrollment is an implementation of the MS-WSTEP protocol.
 
 ### Management configuration
 
-The server sends provisioning XML that contains a server certificate (for SSL server authentication), a client certificate issued by enterprise CA, DM client bootstrap information (for the client to communicate with the management server), an enterprise application token (for the user to install enterprise applications), and the link to download the Company Hub application.
+The server sends provisioning XML that contains a server certificate (for TLS/SSL server authentication), a client certificate issued by enterprise CA, DM client bootstrap information (for the client to communicate with the management server), an enterprise application token (for the user to install enterprise applications), and the link to download the Company Hub application.
 
-The following topics describe the end-to-end enrollment process using various authentication methods:
+The following articles describe the end-to-end enrollment process using various authentication methods:
 
 - [Federated authentication device enrollment](federated-authentication-device-enrollment.md)
 - [Certificate authentication device enrollment](certificate-authentication-device-enrollment.md)
@@ -60,7 +60,7 @@ The following topics describe the end-to-end enrollment process using various au
 
 ## Enrollment support for domain-joined devices
 
-Devices that are joined to an on-premises Active Directory can enroll into MDM via **Settings** > **Access work or school**. However, the enrollment can only target the user enrolled with user-specific policies. Device targeted policies will continue to impact all users of the device.
+Devices that are joined to an on-premises Active Directory can enroll into MDM via **Settings** > **Access work or school**. However, the enrollment can only target the user enrolled with user-specific policies. Device targeted policies continue to target all users of the device.
 
 ## Enrollment scenarios not supported
 
@@ -115,7 +115,7 @@ The enrollment server can decline enrollment messages using the SOAP Fault forma
 | s:        | CertificateRequest   | MENROLL_E_DEVICE_CERTIFICATEREQUEST_ERROR | The user has no permission for the certificate template or the certificate authority is unreachable. Try again or contact your system administrator. | 80180004 |
 | s:        | EnrollmentServer     | MENROLL_E_DEVICE_CONFIGMGRSERVER_ERROR    | The Mobile Device Management (MDM) server encountered an error. Try again or contact your system administrator.                                      | 80180005 |
 | a:        | InternalServiceFault | MENROLL_E_DEVICE_INTERNALSERVICE_ERROR    | There was an unhandled exception on the Mobile Device Management (MDM) server. Try again or contact your system administrator.                       | 80180006 |
-| a:        | InvalidSecurity      | MENROLL_E_DEVICE_INVALIDSECURITY_ERROR    | The Mobile Device Management (MDM) server was not able to validate your account. Try again or contact your system administrator.                     | 80180007 |
+| a:        | InvalidSecurity      | MENROLL_E_DEVICE_INVALIDSECURITY_ERROR    | The Mobile Device Management (MDM) server wasn't able to validate your account. Try again or contact your system administrator.                     | 80180007 |
 
 SOAP format also includes `deviceenrollmentserviceerror` element. Here's an example:
 
@@ -163,7 +163,7 @@ SOAP format also includes `deviceenrollmentserviceerror` element. Here's an exam
 
 TraceID is a freeform text node that is logged. It should identify the server side state for this enrollment attempt. This information may be used by support to look up why the server declined the enrollment.
 
-## Related topics
+## Related articles
 
 - [MDM enrollment of Windows-based devices](mdm-enrollment-of-windows-devices.md)
 - [Federated authentication device enrollment](federated-authentication-device-enrollment.md)

windows/client-management/new-in-windows-mdm-enrollment-management.md

@@ -74,7 +74,7 @@ For details about Microsoft mobile device management protocols for Windows, see
 | [BitLocker CSP](mdm/bitlocker-csp.md) | Added a new node AllowStandardUserEncryption.<br><li>Added support for Pro edition. |
 | [Defender CSP](mdm/defender-csp.md) | Added a new node Health/ProductStatus. |
 | [DevDetail CSP](mdm/devdetail-csp.md) | Added a new node SMBIOSSerialNumber. |
-| [EnterpriseModernAppManagement CSP](mdm/enterprisemodernappmanagement-csp.md) | Added NonRemovable setting under AppManagement node. |
+| [EnterpriseModernAppManagement CSP](mdm/enterprisemodernappmanagement-csp.md) | Added Non-Removable setting under AppManagement node. |
 | [Office CSP](mdm/office-csp.md) | Added FinalStatus setting. |
 | [PassportForWork CSP](mdm/passportforwork-csp.md) | Added new settings. |
 | [RemoteWipe CSP](mdm/remotewipe-csp.md) | Added new settings. |

windows/client-management/oma-dm-protocol-support.md

@@ -7,7 +7,7 @@ ms.date: 08/10/2023
 
 # OMA DM protocol support
 
-The OMA DM client communicates with the server over HTTPS and uses DM Sync (OMA DM v1.2) as the message payload. This topic describes the OMA DM functionality that the DM client supports in general. The full description of the OMA DM protocol v1.2 can be found at the [OMA website](https://www.openmobilealliance.org/release/DM/V1_2-20070209-A/OMA-TS-DM_Protocol-V1_2-20070209-A.pdf).
+The OMA DM client communicates with the server over HTTPS and uses DM Sync (OMA DM v1.2) as the message payload. This article describes the OMA DM functionality that the DM client supports in general. The full description of the OMA DM protocol v1.2 can be found at the [OMA website](https://www.openmobilealliance.org/release/DM/V1_2-20070209-A/OMA-TS-DM_Protocol-V1_2-20070209-A.pdf).
 
 ## OMA DM standards
 
@@ -15,11 +15,11 @@ The following table shows the OMA DM standards that Windows uses.
 
 |General area|OMA DM standard that is supported|
 |--- |--- |
-|Data transport and session|<li>Client-initiated remote HTTPS DM session over SSL.<li>Remote HTTPS DM session over SSL.<li>Remote DM server initiation notification using WAP Push over Short Message Service (SMS). Not used by enterprise management.<li>Remote bootstrap by using WAP Push over SMS. Not used by enterprise management.|
+|Data transport and session|<li>Client-initiated remote HTTPS DM session over TLS/SSL.<li>Remote HTTPS DM session over TLS/SSL.<li>Remote DM server initiation notification using WAP Push over Short Message Service (SMS). Not used by enterprise management.<li>Remote bootstrap by using WAP Push over SMS. Not used by enterprise management.|
 |Bootstrap XML|OMA Client Provisioning XML.|
-|DM protocol commands|The following list shows the commands that are used by the device. For more information about the OMA DM command elements, see "[OMA website](https://www.openmobilealliance.org/release/DM/V1_1_2-20031209-A/)" available from the OMA website.<br/><li>Add (Implicit Add supported)<li>Alert (DM alert): Generic alert (1226) is used by enterprise management client when the user triggers an MDM unenrollment action from the device or when a CSP finishes some asynchronous actions. Device alert (1224) is used to notify the server some device triggered event.<li>Atomic: Performing an Add command followed by Replace on the same node within an atomic element isn't supported. Nested Atomic and Get commands aren't allowed and will generate error code 500.<li>Delete: Removes a node from the DM tree, and the entire subtree beneath that node if one exists<li>Exec: Invokes an executable on the client device<li>Get: Retrieves data from the client device; for interior nodes, the child node names in the Data element are returned in URI-encoded format<li>Replace: Overwrites data on the client device<li>Result: Returns the data results of a Get command to the DM server<li>Sequence: Specifies the order in which a group of commands must be processed<li>Status: Indicates the completion status (success or failure) of an operation<br/><br/>If an XML element that isn't a valid OMA DM command is under one of the following elements, the status code 400 is returned for that element:<br/><li>SyncBody<li>Atomic<li>Sequence<br><br/>If no CmdID is provided in the DM command, the client returns blank in the status element and the status code 400.<br/><br/>If Atomic elements are nested, the following status codes are returned:<br/><li>The nested Atomic command returns 500.<li>The parent Atomic command returns 507.<br/><br/>For more information about the Atomic command, see OMA DM protocol common elements.<br>Performing an Add command followed by Replace on the same node within an Atomic element isn't supported.<br><br/>LocURI can't start with `/`.<br/><br/>Meta XML tag in SyncHdr is ignored by the device.|
+|DM protocol commands|The following list shows the commands that are used by the device. For more information about the OMA DM command elements, see "[OMA website](https://www.openmobilealliance.org/release/DM/V1_1_2-20031209-A/)" available from the OMA website.<br/><li>Add (Implicit Add supported)<li>Alert (DM alert): Generic alert (1226) is used by enterprise management client when the user triggers an MDM unenrollment action from the device or when a CSP finishes some asynchronous actions. Device alert (1224) is used to notify the server some device triggered event.<li>Atomic: Performing an Add command followed by Replace on the same node within an atomic element isn't supported. Nested Atomic and Get commands aren't allowed and generate error code 500.<li>Delete: Removes a node from the DM tree, and the entire subtree beneath that node if one exists<li>Exec: Invokes an executable on the client device<li>Get: Retrieves data from the client device; for interior nodes, the child node names in the Data element are returned in URI-encoded format<li>Replace: Overwrites data on the client device<li>Result: Returns the data results of a Get command to the DM server<li>Sequence: Specifies the order in which a group of commands must be processed<li>Status: Indicates the completion status (success or failure) of an operation<br/><br/>If an XML element that isn't a valid OMA DM command is under one of the following elements, the status code 400 is returned for that element:<br/><li>SyncBody<li>Atomic<li>Sequence<br><br/>If no CmdID is provided in the DM command, the client returns blank in the status element and the status code 400.<br/><br/>If Atomic elements are nested, the following status codes are returned:<br/><li>The nested Atomic command returns 500.<li>The parent Atomic command returns 507.<br/><br/>For more information about the Atomic command, see OMA DM protocol common elements.<br>Performing an Add command followed by Replace on the same node within an Atomic element isn't supported.<br><br/>LocURI can't start with `/`.<br/><br/>Meta XML tag in SyncHdr is ignored by the device.|
 |OMA DM standard objects|DevInfo<li>DevDetail<li>OMA DM DMS account objects (OMA DM version 1.2)|
-|Security|<li>Authenticate DM server initiation notification SMS message (not used by enterprise management)<li>Application layer Basic and MD5 client authentication<li>Authenticate server with MD5 credential at application level<li>Data integrity and authentication with HMAC at application level<li>SSL level certificate-based client/server authentication, encryption, and data integrity check|
+|Security|<li>Authenticate DM server initiation notification SMS message (not used by enterprise management)<li>Application layer Basic and MD5 client authentication<li>Authenticate server with MD5 credential at application level<li>Data integrity and authentication with HMAC at application level<li>TLS/SSL level certificate-based client/server authentication, encryption, and data integrity check|
 |Nodes|In the OMA DM tree, the following rules apply for the node name:<br/><li>"." can be part of the node name.<li>The node name can't be empty.<li>The node name can't be only the asterisk (`*`) character.|
 |Provisioning Files|Provisioning XML must be well formed and follow the definition in [SyncML Representation Protocol](https://www.openmobilealliance.org/release/Common/V1_2_2-20090724-A/OMA-TS-SyncML-RepPro-V1_2_2-20090724-A.pdf).<br/><br/>If an XML element that isn't a valid OMA DM command is under SyncBody, the status code 400 is returned for that element.<div class="alert">**Note**<br>To represent a Unicode string as a URI, first encode the string as UTF-8. Then encode each of the UTF-8 bytes using URI encoding.</div>|
 |WBXML support|Windows supports sending and receiving SyncML in both XML format and encoded WBXML format. This dual-format support is configurable by using the DEFAULTENCODING node under the w7 APPLICATION characteristic during enrollment. For more information about WBXML encoding, see section 8 of the [SyncML Representation Protocol](https://www.openmobilealliance.org/release/Common/V1_2_2-20090724-A/OMA-TS-SyncML-RepPro-V1_2_2-20090724-A.pdf) specification.|
@@ -45,7 +45,7 @@ Common elements are used by other OMA DM element types. The following table list
 | SessionID | Specifies the identifier of the OMA DM session associated with the containing message. If the server doesn't notify the device that it supports a new version (through SyncApplicationVersion node in the DMClient CSP), the client returns the SessionID in integer in decimal format. If the server supports DM session sync version 2.0, which is used in Windows, the device client returns 2 bytes. |
 | Source    | Specifies the message source address. |
 | SourceRef | Specifies the source of the corresponding request message. This element takes the value of the request message Source element and is returned in the Status or Results element. |
-| Target    | Specifies the address of the node, in the DM Tree, that is the target of the OMA DM command. |
+| Target    | Specifies the address of the node in the DM Tree that is the target of the OMA DM command. |
 | TargetRef | Specifies the target address in the corresponding request message. This element takes the value of the request message Target element and is returned in the Status or Results element. |
 | VerDTD    | Specifies the major and minor version identifier of the OMA DM representation protocol specification used to represent the message. |
 | VerProto  | Specifies the major and minor version identifier of the OMA DM protocol specification used with the message. |
@@ -60,8 +60,8 @@ A server sends a Get command to a client device to retrieve the contents of one
 
 A DM session can be divided into two phases:
 
-1. **Setup phase**: In response to a trigger event, a client device sends an initiating message to a DM server. The device and server exchange needed authentication and device information. This phase is represented by steps 1, 2, and 3 in the following table.
+1. **Setup phase**: In response to a trigger event, a client device sends an initiating message to a DM server. The device and server exchange needed authentication and device information. This phase is represented by steps 1, 2, and 3.
-1. **Management phase**: The DM server is in control. It sends management commands to the device and the device responds. Phase 2 ends when the DM server stops sending commands and terminates the session. This phase is represented by steps 3, 4, and 5 in the following table.
+1. **Management phase**: The DM server is in control. It sends management commands to the device and the device responds. Phase 2 ends when the DM server stops sending commands and terminates the session. This phase is represented by steps 3, 4, and 5.
 
 The following information shows the sequence of events during a typical DM session.
 
@@ -73,7 +73,7 @@ The following information shows the sequence of events during a typical DM sessi
 
 1. The device sends a message, over an IP connection, to initiate the session.
 
-    This message includes device information and credentials. The client and server do mutual authentication over an SSL channel or at the DM application level.
+    This message includes device information and credentials. The client and server do mutual authentication over a TLS/SSL channel or at the DM application level.
 
 1. The DM server responds, over an IP connection (HTTPS). The server sends initial device management commands, if any.
 
@@ -83,9 +83,9 @@ The following information shows the sequence of events during a typical DM sessi
 
 The step numbers don't represent message identification numbers (MsgID). All messages from the server must have a MsgID that is unique within the session, starting at 1 for the first message, and increasing by an increment of 1 for each extra message. For more information about MsgID and OMA SyncML protocol, see [OMA Device Management Representation Protocol (DM_RepPro-V1_2-20070209-A)](https://www.openmobilealliance.org/release/DM/V1_2-20070209-A/).
 
-During OMA DM application level mutual authentication, if the device response code to Cred element in the server request is 212, no further authentication is needed for the remainder of the DM session. If the MD5 authentication occurs, the Chal element can be returned. Then the next nonce in Chal must be used for the MD5 digest when the next DM session is started.
+During OMA DM application level mutual authentication, if the device response code to Cred element in the server request is 212, no further authentication is needed for the remainder of the DM session. If the MD5 authentication occurs, the `Chal` element can be returned. Then the next nonce in `Chal` must be used for the MD5 digest when the next DM session is started.
 
-If a request includes credentials and the response code to the request is 200, the same credential must be sent within the next request. If the Chal element is included and the MD5 authentication is required, a new digest is created by using the next nonce via the Chal element for next request.
+If a request includes credentials and the response code to the request is 200, the same credential must be sent within the next request. If the `Chal` element is included and the MD5 authentication is required, a new digest is created by using the next nonce via the `Chal` element for next request.
 
 For more information about Basic or MD5 client authentication, MD5 server authentication, MD5 hash, and MD5 nonce, see the OMA Device Management Security specification (OMA-TS-DM_Security-V1_2_1-20080617-A), authentication response code handling and step-by-step samples in OMA Device Management Protocol specification (OMA-TS-DM_Protocol-V1_2_1-20080617-A), available from the [OMA website](https://www.openmobilealliance.org/release/DM/V1_2_1-20080617-A/).
 
@@ -99,7 +99,7 @@ The data part of this alert could be one of following strings:
 - Others: another user sign in but that user doesn't have an MDM account. The server can only apply device-wide configuration, for example, configuration applies to all users in the device.
 - None: no active user sign in. The server can only apply device-wide configuration and available configuration is restricted to the device environment (no active user sign in).
 
-Below is an alert example:
+Here's an alert example:
 
 ```xml
 <Alert>
@@ -129,23 +129,23 @@ When using SyncML in OMA DM, there are standard response status codes that are r
 |---|----|
 | 200         | The SyncML command completed successfully.  |
 | 202         | Accepted for processing. This code denotes an asynchronous operation, such as a request to run a remote execution of an application.  |
-| 212         | Authentication accepted. Normally you'll only see this code in response to the SyncHdr element (used for authentication in the OMA-DM standard). You may see this code if you look at OMA DM logs, but CSPs don't typically generate this code. |
+| 212         | Authentication accepted. Normally you only see this code in response to the SyncHdr element (used for authentication in the OMA-DM standard). You may see this code if you look at OMA DM logs, but CSPs don't typically generate this code. |
-| 214         | Operation canceled. The SyncML command completed successfully, but no more commands will be processed within the session. |
+| 214         | Operation canceled. The SyncML command completed successfully, but no more commands are processed within the session. |
 | 215         | Not executed. A command wasn't executed as a result of user interaction to cancel the command.  |
 | 216         | `Atomic` roll back OK. A command was inside an `Atomic` element and `Atomic` failed. This command was rolled back successfully.  |
 | 400         | Bad request. The requested command couldn't be performed because of malformed syntax. CSPs don't usually generate this error, however you might see it if your SyncML is malformed.  |
 | 401         | Invalid credentials. The requested command failed because the requestor must provide proper authentication. CSPs don't usually generate this error.  |
 | 403         | Forbidden. The requested command failed, but the recipient understood the requested command.  |
-| 404         | Not found. The requested target wasn't found. This code will be generated if you query a node that doesn't exist.   |
+| 404         | Not found. The requested target wasn't found. This code is generated if you query a node that doesn't exist.   |
-| 405         | Command not allowed. This respond code will be generated if you try to write to a read-only node.  |
+| 405         | Command not allowed. This respond code is generated if you try to write to a read-only node.  |
-| 406         | Optional feature not supported. This response code will be generated if you try to access a property that the CSP doesn't support.  |
+| 406         | Optional feature not supported. This response code is generated if you try to access a property that the CSP doesn't support.  |
 | 415         | Unsupported type or format. This response code can result from XML parsing or formatting errors.  |
 | 418         | Already exists. This response code occurs if you attempt to add a node that already exists.  |
 | 425         | Permission Denied. The requested command failed because the sender doesn't have adequate access control permissions (ACL) on the recipient. "Access denied" errors usually get translated to this response code.  |
-| 500         | Command failed. Generic failure. The recipient encountered an unexpected condition, which prevented it from fulfilling the request. This response code will occur when the SyncML DPU can't map the originating error code.       |
+| 500         | Command failed. Generic failure. The recipient encountered an unexpected condition, which prevented it from fulfilling the request. This response code occurs when the SyncML DPU can't map the originating error code.       |
 | 507         | `Atomic` failed. One of the operations in an `Atomic` block failed.  |
 | 516         | `Atomic` roll back failed. An `Atomic` operation failed and the command wasn't rolled back successfully.  |
 
-## Related topics
+## Related articles
 
 [Configuration service provider reference](mdm/index.yml)

windows/client-management/on-premise-authentication-device-enrollment.md

@@ -59,10 +59,10 @@ After the device gets a response from the server, the device sends a POST reques
 
 The following logic is applied:
 
-1. The device first tries HTTPS. If the server cert is not trusted by the device, the HTTPS fails.
+1. The device first tries HTTPS. If the device doesn't trust the server certificate, the HTTPS attempt fails.
-1. If that fails, the device tries HTTP to see whether it is redirected:
+1. If that fails, the device tries HTTP to see whether it's redirected:
-   - If the device is not redirected, it prompts the user for the server address.
+   - If the device isn't redirected, the user is prompted for the server address.
-   - If the device is redirected, it prompts the user to allow the redirect.
+   - If the device is redirected, the user is prompted to allow the redirect.
 
 The following example shows a request via an HTTP POST command to the discovery web service given user@contoso.com as the email address:
 
@@ -112,8 +112,8 @@ If a domain and user name are provided by the user instead of an email address,
 The discovery response is in the XML format and includes the following fields:
 
 - Enrollment service URL (EnrollmentServiceUrl) - Specifies the URL of the enrollment endpoint that is exposed by the management service. The device should call this URL after the user has been authenticated. This field is mandatory.
-- Authentication policy (AuthPolicy) - Indicates what type of authentication is required. For the MDM server, OnPremise is the supported value, which means that the user will be authenticated when calling the management service URL. This field is mandatory.
+- Authentication policy (AuthPolicy) - Indicates what type of authentication is required. For the MDM server, OnPremise is the supported value, which means that the user is authenticated when calling the management service URL. This field is mandatory.
-- Federated is added as another supported value. This allows the server to leverage the Web Authentication Broker to perform customized user authentication, and term of usage acceptance.
+- Federated is added as another supported value. It allows the server to use the Web Authentication Broker to perform customized user authentication, and term of usage acceptance.
 
 > [!NOTE]
 > The HTTP server response must not be chunked; it must be sent as one message.
@@ -153,9 +153,7 @@ The following example shows a response received from the discovery web service f
 
 ## Enrollment policy web service
 
-For the OnPremise authentication policy, the UsernameToken in GetPolicies contains the user credential, whose value is based on the authentication policy in discovery. A sample of the request can be found on the MSDN website; the following is another sample, with "user@contoso.com" as the user name and "mypassword" as the password.
+For the OnPremise authentication policy, the UsernameToken in GetPolicies contains the user credential, whose value is based on the authentication policy in discovery. The following sample shows the policy web service request and uses `user@contoso.com` as the user name and `mypassword` as the password.
-
-The following example shows the policy web service request.
 
 ```xml
    <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
@@ -198,7 +196,7 @@ The following example shows the policy web service request.
 
 After the user is authenticated, the web service retrieves the certificate template that the user should enroll with and creates enrollment policies based on the certificate template properties. A sample of the response can be found on MSDN.
 
-MS-XCEP supports very flexible enrollment policies using various Complex Types and Attributes. We will first support the minimalKeyLength, the hashAlgorithmOIDReference policies, and the CryptoProviders. The hashAlgorithmOIDReference has related OID and OIDReferenceID and policySchema in the GetPolicesResponse. The policySchema refers to the certificate template version. Version 3 of MS-XCEP supports hashing algorithms.
+MS-XCEP supports flexible enrollment policies using various Complex Types and Attributes that include the minimalKeyLength, the hashAlgorithmOIDReference policies, and the CryptoProviders. The hashAlgorithmOIDReference has related OID and OIDReferenceID and policySchema in the GetPolicesResponse. The policySchema refers to the certificate template version. Version 3 of MS-XCEP supports hashing algorithms.
 
 > [!NOTE]
 > The HTTP server response must not be chunked; it must be sent as one message.
@@ -286,9 +284,9 @@ The following snippet shows the policy web service response.
 
 This web service implements the MS-WSTEP protocol. It processes the RequestSecurityToken (RST) message from the client, authenticates the client, requests the certificate from the CA, and returns it in the RequestSecurityTokenResponse (RSTR) to the client. Besides the issued certificate, the response also contains configurations needed to provision the DM client.
 
-The RequestSecurityToken (RST) must have the user credential and a certificate request. The user credential in an RST SOAP envelope is the same as in GetPolicies, and can vary depending on whether the authentication policy is OnPremise or Federated. The BinarySecurityToken in an RST SOAP body contains a Base64-encoded PKCS\#10 certificate request, which is generated by the client based on the enrollment policy. The client could have requested an enrollment policy by using MS-XCEP before requesting a certificate using MS-WSTEP. If the PKCS\#10 certificate request is accepted by the certification authority (CA) (the key length, hashing algorithm, and so on match the certificate template), the client can enroll successfully.
+The RequestSecurityToken (RST) must have the user credential and a certificate request. The user credential in an RST SOAP envelope is the same as in GetPolicies, and can vary depending on whether the authentication policy is OnPremise or Federated. The BinarySecurityToken in an RST SOAP body contains a Base64-encoded PKCS\#10 certificate request, which is generated by the client based on the enrollment policy. The client could have requested an enrollment policy by using MS-XCEP before requesting a certificate using MS-WSTEP. If the PKCS\#10 certificate request is accepted by the certification authority (CA) (the key length, hashing algorithm, and so on, match the certificate template), the client can enroll successfully.
 
-The RequestSecurityToken will use a custom TokenType (`http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken`), because our enrollment token is more than an X.509 v3 certificate. For more details, see the Response section.
+The RequestSecurityToken uses a custom TokenType (`http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken`), because our enrollment token is more than an X.509 v3 certificate. For more information, see the Response section.
 
 The RST may also specify a number of AdditionalContext items, such as DeviceType and Version. Based on these values, for example, the web service can return device-specific and version-specific DM configuration.
 

windows/client-management/push-notification-windows-mdm.md

@@ -7,7 +7,7 @@ ms.date: 08/10/2023
 
 # Push notification support for device management
 
-The [DMClient CSP](mdm/dmclient-csp.md) supports the ability to configure push-initiated device management sessions. Using the [Windows Notification Services (WNS)](/windows/apps/design/shell/tiles-and-notifications/windows-push-notification-services--wns--overview), a management server can request a device to establish a management session with the server through a push notification. A device is provided with a PFN for an application. This provision results in the device getting configured, to support a push to it by the management server. Once the device is configured, it registers a persistent connection with the WNS cloud (Battery Sense and Data Sense conditions permitting).
+The [DMClient CSP](mdm/dmclient-csp.md) supports the ability to configure push-initiated device management sessions. With [Windows Notification Services (WNS)](/windows/apps/design/shell/tiles-and-notifications/windows-push-notification-services--wns--overview), a management server can request a device to establish a management session with the server through a push notification. A device is provided with a PFN for an application. This provision results in the device getting configured, to support a push to it by the management server. Once the device is configured, it registers a persistent connection with the WNS cloud (Battery Sense and Data Sense conditions permitting).
 
 To initiate a device management session, the management server must first authenticate with WNS using its SID and client secret. Once authenticated, the server receives a token to initiate a raw push notification for any ChannelURI. When the management server wants to initiate a management session with a device, it can utilize the token and the device ChannelURI, and begin communicating with the device.
 
@@ -18,10 +18,10 @@ Because a device may not always be connected to the internet, WNS supports cachi
 The following restrictions are related to push notifications and WNS:
 
 - Push for device management uses raw push notifications. This restriction means that these raw push notifications don't support or utilize push notification payloads.
-- Receipt of push notifications is sensitive to the Battery Saver and Data Sense settings on the device. For example, if the battery drops below certain thresholds, the persistent connection of the device with WNS will be terminated. Additionally, if the user is utilizing Data Sense and has exceeded their monthly allotment of data, the persistent connection of the device with WNS will also be terminated.
+- Receipt of push notifications is sensitive to the Battery Saver and Data Sense settings on the device. For example, if the battery drops below certain thresholds, the persistent connection of the device with WNS is terminated. Additionally, if the user is utilizing Data Sense and has exceeded their monthly allotment of data, the persistent connection of the device with WNS is also terminated.
-- A ChannelURI provided to the management server by the device is only valid for 30 days. The device automatically renews the ChannelURI after 15 days and triggers a management session on successful renewal of the ChannelURI. It's strongly recommended that, during every management session, the management server queries the ChannelURI value to ensure that it has received the latest value. This will ensure that the management server won't attempt to use a ChannelURI that has expired.
+- A ChannelURI provided to the management server by the device is only valid for 30 days. The device automatically renews the ChannelURI after 15 days and triggers a management session on successful renewal of the ChannelURI. It's recommended that, during every management session, the management server queries the ChannelURI value to ensure that it has received the latest value. This query ensures that the management server doesn't attempt to use a ChannelURI that has expired.
 - Push isn't a replacement for having a polling schedule.
-- WNS reserves the right to block push notifications to your PFN if improper use of notifications is detected. Any devices being managed using this PFN will cease to have push initiated device management support.
+- WNS reserves the right to block push notifications to your PFN if improper use of notifications is detected. Any devices being managed using this PFN cease to have push initiated device management support.
 
 - In Windows 10, version 1511, we use the following retry logic for the DMClient:
 
@@ -29,7 +29,7 @@ The following restrictions are related to push notifications and WNS:
   - If ExpiryTime is between now and 15 days, a schedule set for 4 +/- 1 hours from now.
   - If ExpiryTime has passed, a schedule is set for 1 day +/- 4 hours from now.
 
-- In Windows 10, version 1607 and later, we check for network connectivity before retrying. We don't check for internet connectivity. If network connectivity isn't available, we'll skip the retry and set schedule for 4+/-1 hours to try again.
+- In Windows 10, version 1607 and later, we check for network connectivity before retrying. We don't check for internet connectivity. If network connectivity isn't available, the retry is skipped and a schedule is set for 4+/-1 hours to try again.
 
 ## Get WNS credentials and PFN for MDM push notification
 
@@ -40,10 +40,10 @@ To get a PFN and WNS credentials, you must create a Microsoft Store app.
 1. Reserve an app name.
 1. Select **Product Identity** under Product Management to view the **Package Family Name (PFN)** of your app.
 1. Select **WNS/MPNS** under Product Management.
-   1. Click the **App Registration portal** link. A new window opens showing your app in the Azure Portal.
+   1. Select the **App Registration portal** link. A new window opens showing your app in the Azure portal.
-   1. In the Application Registration Portal page, you'll see the properties for the app that you created, such as:
+   1. In the Application Registration Portal page, you see the properties for the app that you created, such as:
       - Application ID
       - Application Secrets
       - Redirect URIs
 
-For more information see, [Tutorial: Send notifications to Universal Windows Platform apps using Azure Notification Hubs](/azure/notification-hubs/notification-hubs-windows-store-dotnet-get-started-wns-push-notification).
+For more information, see [Tutorial: Send notifications to Universal Windows Platform apps using Azure Notification Hubs](/azure/notification-hubs/notification-hubs-windows-store-dotnet-get-started-wns-push-notification).

windows/client-management/server-requirements-windows-mdm.md

@@ -11,7 +11,7 @@ The following list shows the general server requirements for using OMA DM to man
 
 - The OMA DM server must support the OMA DM v1.1.2 or later protocol.
 
-- Secure Sockets Layer (SSL) must be on the OMA DM server, and it must provide server certificate-based authentication, data integrity check, and data encryption. If the certificate isn't issued by a commercial Certification Authority whose root certificate is pre-installed in the device, you must provision the enterprise root certificate in the device's Root store.
+- Secure Sockets Layer (TLS/SSL) must be on the OMA DM server, and it must provide server certificate-based authentication, data integrity check, and data encryption. If the certificate isn't issued by a commercial Certification Authority whose root certificate is preinstalled in the device, you must provision the enterprise root certificate in the device's Root store.
 
 - To authenticate the client at the application level, you must use either Basic or MD5 client authentication.
 

windows/client-management/structure-of-oma-dm-provisioning-files.md

@@ -22,7 +22,7 @@ The following table shows the OMA DM versions that are supported.
 
 ## File format
 
-The following example shows the general structure of the XML document sent by the server using OMA DM version 1.2.1 for demonstration purposes only. The initial XML packages exchanged between client and server could contain additional XML tags. For a detailed description and samples for those packages, see the [OMA Device Management Protocol 1.2.1](https://www.openmobilealliance.org/release/DM/V1_2_1-20080617-A/OMA-TS-DM_Protocol-V1_2_1-20080617-A.pdf) specification.
+The following example shows the general structure of the XML document sent by the server using OMA DM version 1.2.1 for demonstration purposes only. The initial XML packages exchanged between client and server could contain more XML tags. For a detailed description and samples for those packages, see the [OMA Device Management Protocol 1.2.1](https://www.openmobilealliance.org/release/DM/V1_2_1-20080617-A/OMA-TS-DM_Protocol-V1_2_1-20080617-A.pdf) specification.
 
 ```xml
 <SyncML xmlns='SYNCML:SYNCML1.2'>
@@ -97,7 +97,7 @@ SyncBody contains one or more DM commands. The SyncBody can contain multiple DM
 
 **Code example**
 
-The following example shows the body component of a DM message. In this example, SyncBody contains only one command, Get. This command is indicated by the &lt;Final /&gt; tag that occurs immediately after the terminating tag for the Get command.
+The following example shows the body component of a DM message. In this example, SyncBody contains only one command, Get. This command is indicated by the `<Final />` tag that occurs immediately after the terminating tag for the Get command.
 
 ```xml
 <SyncBody>

windows/client-management/understanding-admx-backed-policies.md

@@ -23,9 +23,9 @@ Depending on the specific category of the settings that they control (OS or appl
 
 In a domain controller/Group Policy ecosystem, Group Policies are automatically added to the registry of the client computer or user profile by the Administrative Templates Client Side Extension (CSE) whenever the client computer processes a Group Policy. Conversely, in an MDM-managed client, ADMX files are applied to define policies independent of Group Policies. Therefore, in an MDM-managed client, a Group Policy infrastructure, including the Group Policy Service (gpsvc.exe), isn't required.
 
-An ADMX file can either be shipped with Windows (located at `%SystemRoot%\policydefinitions`) or it can be ingested to a device through the Policy CSP URI (`./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall`). Inbox ADMX files are processed into MDM policies at OS-build time. ADMX files that are ingested are processed into MDM policies post-OS shipment through the Policy CSP. Because the Policy CSP doesn't rely upon any aspect of the Group Policy client stack, including the PC's Group Policy Service (GPSvc), the policy handlers that are ingested to the device are able to react to policies that are set by the MDM.
+An ADMX file can either be shipped with Windows (located at `%SystemRoot%\policydefinitions`) or it can be ingested to a device through the Policy CSP URI (`./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall`). Inbox ADMX files are processed into MDM policies at OS-build time. ADMX files that are ingested are processed into MDM policies post-OS shipment through the Policy CSP. Because the Policy CSP doesn't rely upon any aspect of the Group Policy client stack, including the PC's Group Policy Service (GPSvc), the policy handlers that are ingested to the device are able to react to policies set by the MDM.
 
-Windows maps the name and category path of a Group Policy to an MDM policy area and policy name by parsing the associated ADMX file, finding the specified Group Policy, and storing the definition (metadata) in the MDM Policy CSP client store. When the MDM policy is referenced by a SyncML command and the Policy CSP URI, `.\[device|user]\vendor\msft\policy\[config|result]\<area>\<policy>`, this metadata is referenced and determines which registry keys are set or removed. For a list of ADMX policies supported by MDM, see [Policy CSP - ADMX policies](mdm/policy-configuration-service-provider.md).
+Windows maps the name and category path of a Group Policy to an MDM policy area and policy name by parsing the associated ADMX file, finding the specified Group Policy, and storing the definition (metadata) in the MDM Policy CSP client store. When the MDM policy contains a SyncML command and the Policy CSP URI, `.\[device|user]\vendor\msft\policy\[config|result]\<area>\<policy>`, this metadata is referenced and determines which registry keys are set or removed. For a list of ADMX policies supported by MDM, see [Policy CSP - ADMX policies](mdm/policy-configuration-service-provider.md).
 
 <!-- [!TIP] -->
 <!-- Intune has added a number of ADMX administrative templates in public preview. Check if the policy settings you need are available in a template before using the SyncML method described below. [Learn more about Intune's administrative templates.](/intune/administrative-templates-windows) -->
@@ -38,15 +38,15 @@ The ADMX file that the MDM ISV uses to determine what UI to display to the IT ad
 
 Group Policy option button setting:
 
-- If **Enabled** is selected, the necessary data entry controls are displayed for the user in the UI. When IT administrator enters the data and clicks **Apply**, the following events occur:
+- If **Enabled** is selected, the necessary data entry controls are displayed for the user in the UI. When IT administrator enters the data and select **Apply**, the following events occur:
   - The MDM ISV server sets up a Replace SyncML command with a payload that contains the user-entered data.
   - The MDM client stack receives this data, which causes the Policy CSP to update the device's registry per the ADMX policy definition.
 
-- If **Disabled** is selected and you click **Apply**, the following events occur:
+- If **Disabled** is selected and you select **Apply**, the following events occur:
   - The MDM ISV server sets up a Replace SyncML command with a payload set to `<disabled\>`.
   - The MDM client stack receives this command, which causes the Policy CSP to either delete the device's registry settings, set the registry keys, or both, per the state change directed by the ADMX policy definition.
 
-- If **Not Configured** is selected and you click **Apply**, the following events occur:
+- If **Not Configured** is selected and you select **Apply**, the following events occur:
   - MDM ISV server sets up a Delete SyncML command.
   - The MDM client stack receives this command, which causes the Policy CSP to delete the device's registry settings per the ADMX policy definition.
 
@@ -236,7 +236,7 @@ This section describes sample SyncML for the various ADMX elements like Text, Mu
 
 ### How a Group Policy policy category path and name are mapped to an MDM area and policy name
 
-Below is the internal OS mapping of a Group Policy to an MDM area and name. This mapping is part of a set of Windows manifest that when compiled parses out the associated ADMX file, finds the specified Group Policy policy and stores that definition (metadata) in the MDM Policy CSP client store.  ADMX backed policies are organized hierarchically. Their scope can be **machine**, **user**, or have a scope of **both**. When the MDM policy is referred to through a SyncML command and the Policy CSP URI, as shown below, this metadata is referenced and determines what registry keys are set or removed. Machine-scope policies are referenced via .\Device and the user scope policies via .\User.
+Here's the internal OS mapping of a Group Policy to an MDM area and name. This mapping is part of a set of Windows manifest that when compiled parses out the associated ADMX file, finds the specified Group Policy policy and stores that definition (metadata) in the MDM Policy CSP client store.  ADMX backed policies are organized hierarchically. Their scope can be **machine**, **user**, or have a scope of **both**. When the MDM policy is referred to through a SyncML command and the Policy CSP URI, as shown, this metadata is referenced and determines what registry keys are set or removed. Machine-scope policies are referenced via .\Device and the user scope policies via .\User.
 
 `./[Device|User]/Vendor/MSFT/Policy/Config/[config|result]/<area>/<policy>`
 
@@ -261,7 +261,7 @@ The **LocURI** for the above GP policy is:
 
 `./Device/Vendor/MSFT/Policy/Config/AppVirtualization/PublishingAllowServer2`
 
-To construct SyncML for your area/policy using the samples below, you need to update the **data id** and the **value** in the `<Data>` section of the SyncML. The items prefixed with an '&' character are the escape characters needed and can be retained as shown.
+To construct SyncML for your area/policy using the following samples, you need to update the **data id** and the **value** in the `<Data>` section of the SyncML. The items prefixed with an '&' character are the escape characters needed and can be retained as shown.
 
 ### Text Element
 
@@ -346,12 +346,12 @@ The `multiText` element simply corresponds to a REG_MULTISZ registry string and
 
 ### List Element (and its variations)
 
-The `list` element simply corresponds to a hive of REG_SZ registry strings and correspondingly to a grid to enter multiple strings in a policy panel display by gpedit.msc. How this element is represented in SyncML is as a string containing pairs of strings. Each pair is a REG_SZ name/value key. It's best to apply the policy through gpedit.msc (run as Administrator) and go to the registry hive location and see how the list values are stored. This location will give you an idea of the way the name/value pairs are stored to express it through SyncML.
+The `list` element simply corresponds to a hive of REG_SZ registry strings and correspondingly to a grid to enter multiple strings in a policy panel display by gpedit.msc. How this element is represented in SyncML is as a string containing pairs of strings. Each pair is a REG_SZ name/value key. It's best to apply the policy through gpedit.msc (run as Administrator) and go to the registry hive location and see how the list values are stored. This location gives you an idea of the way the name/value pairs are stored to express it through SyncML.
 
 > [!NOTE]
 > It's expected that each string in the SyncML is to be separated by the Unicode character 0xF000 (encoded version: `&#xF000;`).
 
-Variations of the `list` element are dictated by attributes. These attributes are ignored by the Policy Manager runtime. It's expected that the MDM server manages the name/value pairs. See below for a simple write-up of Group Policy List.
+Variations of the `list` element are dictated by attributes. These attributes are ignored by the Policy Manager runtime. It's expected that the MDM server manages the name/value pairs. Here are some samples for the Group Policy List.
 
 **ADMX file: inetres.admx**:
 

windows/client-management/using-powershell-scripting-with-the-wmi-bridge-provider.md

@@ -1,13 +1,13 @@
 ---
 title: Using PowerShell scripting with the WMI Bridge Provider
-description: This topic covers using PowerShell Cmdlet scripts to configure per-user and per-device policy settings, and how to invoke methods through the WMI Bridge Provider.
+description: This article covers using PowerShell Cmdlet scripts to configure per-user and per-device policy settings, and how to invoke methods through the WMI Bridge Provider.
 ms.topic: article
 ms.date: 08/10/2023
 ---
 
 # Using PowerShell scripting with the WMI Bridge Provider
 
-This topic covers using PowerShell Cmdlet scripts to configure per-user and per-device policy settings, and how to invoke methods through the [WMI Bridge Provider](/windows/win32/dmwmibridgeprov/mdm-bridge-wmi-provider-portal).
+This article covers using PowerShell Cmdlet scripts to configure per-user and per-device policy settings, and how to invoke methods through the [WMI Bridge Provider](/windows/win32/dmwmibridgeprov/mdm-bridge-wmi-provider-portal).
 
 ## Configuring per-device policy settings
 
@@ -85,7 +85,7 @@ If accessing or modifying settings for a different user, then the PowerShell scr
 > [!NOTE]
 > All commands must executed under local system.
 
-A user SID can be obtained by Windows command `wmic useraccount get name, sid`. The following script example assumes the user SID is S-1-5-21-4017247134-4237859428-3008104844-1001.
+Windows command `wmic useraccount get name, sid` can be used to obtain the user SID. The following script example assumes the user SID is` S-1-5-21-4017247134-4237859428-3008104844-1001`.
 
 ```PowerShell
 $namespaceName = "root\cimv2\mdm\dmmap"
@@ -208,6 +208,6 @@ catch [Exception]
 }
 ```
 
-## Related topics
+## Related articles
 
 [WMI Bridge Provider](/windows/win32/dmwmibridgeprov/mdm-bridge-wmi-provider-portal)

windows/client-management/win32-and-centennial-app-policy-configuration.md

@@ -18,7 +18,7 @@ Starting from the following Windows versions `Replace` command is supported:
 - Windows 10, version 1803 with KB4512509 and KB installed
 - Windows 10, version 1709 with KB4516071 and KB installed
 
-When the ADMX policies are ingested, the registry keys to which each policy is written are checked so that known system registry keys, or registry keys that are used by existing inbox policies or system components, are not overwritten. This precaution helps to avoid security concerns over opening the entire registry. Currently, the ingested policies are not allowed to write to locations within the **System**, **Software\Microsoft**, and **Software\Policies\Microsoft** keys, except for the following locations:
+When the ADMX policies are ingested, the registry keys to which each policy is written are checked so that known system registry keys, or registry keys that are used by existing inbox policies or system components, aren't overwritten. This precaution helps to avoid security concerns over opening the entire registry. Currently, the ingested policies aren't allowed to write to locations within the **System**, **Software\Microsoft**, and **Software\Policies\Microsoft** keys, except for the following locations:
 
 - Software\Policies\Microsoft\Office\
 - Software\Microsoft\Office\
@@ -190,7 +190,7 @@ The following ADMX file example shows how to ingest a Win32 or Desktop Bridge ap
 **Request Syncml**:
 
 The ADMX file is escaped and sent in SyncML format through the Policy CSP URI, `./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/{AppName}/{SettingType}/{FileUid or AdmxFileName}`.
-When the ADMX file is imported, the policy states for each new policy are the same as those in a regular MDM policy: Enabled, Disabled, or Not Configured.
+When the ADMX file is imported, the policy states for each new policy are the same as the ones in a regular MDM policy: Enabled, Disabled, or Not Configured.
 
 The following example shows an ADMX file in SyncML format:
 
@@ -356,7 +356,7 @@ The following example shows an ADMX file in SyncML format:
 
 The following example shows how to derive a Win32 or Desktop Bridge app policy name and policy area name:
 
-```XML
+```xml
 <categories>
     <category name="ParentCategoryArea"/>
     <category name="Category1">
@@ -396,9 +396,9 @@ The policy {AreaName} format is {AppName}~{SettingType}~{CategoryPathFromAdmx}.
 
 Therefore, from the example:
 
-- Class: User
+- Class: `User`
-- Policy name: L_PolicyPreventRun_1
+- Policy name: `L_PolicyPreventRun_1`
-- Policy area name: ContosoCompanyApp~Policy~ParentCategoryArea~Category2~Category3
+- Policy area name: `ContosoCompanyApp~Policy~ParentCategoryArea~Category2~Category3`
 - URI: `./user/Vendor/MSFT/Policy/Config/ContosoCompanyApp~Policy~ParentCategoryArea~Category2~Category3/L_PolicyPreventRun_1`
 
 ## ADMX-backed app policy examples

windows/client-management/windows-mdm-enterprise-settings.md

@@ -11,7 +11,7 @@ The actual management interaction between the device and server is done via the
 
 Enterprise MDM settings are exposed via various configuration service providers to the DM client. For the list of available configuration service providers, see [Configuration service provider reference](mdm/index.yml).
 
-Windows currently supports one MDM server. The DM client that is configured via the enrollment process is granted access to enterprise related settings. The DM client is configured during the enrollment process to be invoked by the task scheduler to periodically poll the MDM server.
+Windows currently supports one MDM server. The DM client that is configured via the enrollment process is granted access to enterprise related settings. During the enrollment process, the task scheduler is configured to invoke the DM client to periodically poll the MDM server.
 
 The following diagram shows the work flow between server and client.
 
@@ -21,7 +21,7 @@ The following diagram shows the work flow between server and client.
 
 This protocol defines an HTTPS-based client/server communication with DM SyncML XML as the package payload that carries management requests and execution results. The configuration request is addressed via a managed object (MO). The settings supported by the managed object are represented in a conceptual tree structure. This logical view of configurable device settings simplifies the way the server addresses the device settings by isolating the implementation details from the conceptual tree structure.
 
-To facilitate security-enhanced communication with the remote server for enterprise management, Windows supports certificate-based mutual authentication over an encrypted SSL HTTP channel between the DM client and management service. The server and client certificates are provisioned during the enrollment process.
+To facilitate security-enhanced communication with the remote server for enterprise management, Windows supports certificate-based mutual authentication over an encrypted TLS/SSL HTTP channel between the DM client and management service. The server and client certificates are provisioned during the enrollment process.
 
 The DM client configuration, company policy enforcement, business application management, and device inventory are all exposed or expressed via configuration service providers (CSPs). CSPs are the Windows term for managed objects. The DM client communicates with the server and sends configuration request to CSPs. The server only needs to know the logical local URIs defined by those CSP nodes in order to use the DM protocol XML to manage the device.
 

windows/client-management/wmi-providers-supported-in-windows.md

@@ -12,7 +12,7 @@ Windows Management Infrastructure (WMI) providers (and the classes they support)
 > [!NOTE]
 > Applications installed using WMI classes are not removed when the MDM account is removed from device.
 
-The child node names of the result from a WMI query are separated by a forward slash (/) and not URI escaped. Here is an example query.
+The child node names of the result from a WMI query are separated by a forward slash (/) and not URI escaped. Here's an example query.
 
 Get the list of network adapters from the device.
 
@@ -169,7 +169,7 @@ For links to these classes, see [**MDM Bridge WMI Provider**](/windows/win32/dmw
 | [**Win32\_VideoController**](/windows/win32/cimwin32prov/win32-videocontroller)                         |                              |
 | **Win32\_WindowsUpdateAgentVersion**                                                                    |                              |
 
-## Related topics
+## Related articles
 
 [CIM Video Controller](/windows/win32/cimwin32prov/cim-videocontroller)
 [Configuration service provider reference](mdm/index.yml)