Acrolinx score

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

@@ -41,12 +41,12 @@ 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 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.
 
 > [!NOTE]
-> The user unenrollment is an OMA DM standard. For more information about the 1226 generic alert, refer to the 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_1_2-20031209-A/).
+> The user unenrollment is an OMA DM standard. For more information about the 1226 generic alert, see the 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_1_2-20031209-A/).
 
  
 The vendor uses the Type attribute to specify what type of generic alert it is. For device initiated MDM unenrollment, the alert type is **com.microsoft:mdm.unenrollment.userrequest**.
@@ -127,7 +127,7 @@ When the server initiates disconnection, all undergoing sessions for the enrollm
 
 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 AAD association to the device.
 
-You can only use the Work Access page to un-enroll under the following conditions:
+You can only use the Work Access page to unenroll under the following conditions:
 
 -   Enrollment was done using bulk enrollment.
 -   Enrollment was created using the Work Access page.
@@ -140,7 +140,7 @@ When a user is enrolled into MDM through Azure Active Directory Join and later,
 
 ![aadj unenerollment.](images/azure-ad-unenrollment.png)
 
-At the time 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 corporated devices in unmanaged 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 corporated devices in unmanaged state.
 
 Before remotely unenrolling 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.
 

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

@@ -1,6 +1,6 @@
 ---
 title: EnrollmentStatusTracking CSP
-description: Learn how to perform a hybrid certificate trust deployment of Windows Hello for Business, for systems with no previous installations.
+description: Learn how to execute a hybrid certificate trust deployment of Windows Hello for Business, for systems with no previous installations.
 ms.author: dansimp
 ms.topic: article
 ms.prod: w10
@@ -11,14 +11,14 @@ ms.date: 05/21/2019
 
 # EnrollmentStatusTracking CSP
 
-During Autopilot deployment, you can configure the Enrollment Status Page (ESP) to block the device use until the required apps are installed. You can select the apps that must be installed before using the device. The EnrollmentStatusTracking configuration service provider (CSP) is used by Intune's agents, such as SideCar to configure ESP for blocking the device use until the required Win32 apps are installed. It tracks the installation status of the required policy providers and the apps they install and sends it to ESP, which displays the installation progress message to the user. For more information on ESP, see [Windows Autopilot Enrollment Status page](/windows/deployment/windows-autopilot/enrollment-status).
+During Autopilot deployment, you can configure the Enrollment Status Page (ESP) to block the device usage until the required apps are installed. You can select the apps that must be installed before using the device. The EnrollmentStatusTracking configuration service provider (CSP) is used by Intune's agents, such as SideCar, to configure ESP for blocking the device usage until the required Win32 apps are installed. It tracks the installation status of the required policy providers and the apps they install and sends it to ESP, which displays the installation progress message to the user. For more information on ESP, see [Windows Autopilot Enrollment Status page](/windows/deployment/windows-autopilot/enrollment-status).
 
-ESP uses the EnrollmentStatusTracking CSP along with the DMClient CSP to track the installation of different apps. The EnrollmentStatusTracking CSP tracks Win32 apps installations and DMClient CSP tracks MSI and Universal Windows Platform apps installations. In DMClient CSP, the **FirstSyncStatus/ExpectedMSIAppPackages** and **FirstSyncStatus/ExpectedModernAppPackages** nodes list the apps to track their installation. See [DMClient CSP](dmclient-csp.md) for more information.
+ESP uses the EnrollmentStatusTracking CSP along with the DMClient CSP to track the installation of different apps. The EnrollmentStatusTracking CSP tracks Win32 apps installations and DMClient CSP tracks MSI and Universal Windows Platform apps installations. In DMClient CSP, the **FirstSyncStatus/ExpectedMSIAppPackages** and **FirstSyncStatus/ExpectedModernAppPackages** nodes list the apps to track their installation. For more information, see [DMClient CSP](dmclient-csp.md).
 
 The EnrollmentStatusTracking CSP was added in Windows 10, version 1903.
 
 
-The following shows the EnrollmentStatusTracking CSP in tree format.
+The following example shows the EnrollmentStatusTracking CSP in tree format.
 ```
 ./User/Vendor/MSFT
 EnrollmentStatusTracking

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

@@ -12,12 +12,12 @@ ms.topic: conceptual
 ---
 
 # How Mobile Device Management Providers support eSIM Management on Windows
-The eSIM Profile Management Solution puts 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 that they 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 be able to 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/de-assignment, etc.) the same way as they currently do device management.
+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 be able to 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/de-assignment, etc.) the same way as they currently do device management.
  If you are a Mobile Device Management (MDM) Provider and want to support eSIM Management on Windows, perform the following steps:
 - Onboard to Azure Active Directory
-- Contact mobile operators directly or contact orchestrator providers. Windows provides the capability for eSIM profiles to be managed by MDM providers in the case of enterprise use cases. However, Windows does not limit how ecosystem partners might want to offer this to their own partners and/or customers. As such, the eSIM profile management capability is something that can be supported by integrating with the Windows OMA-DM. This makes it possible to remotely manage the eSIM profiles according to the company policies. Contact mobile operators directly or contact orchestrator providers. Windows provides the capability for eSIM profiles to be managed by MDM providers in the case of enterprise use cases. However, Windows does not limit how ecosystem partners might want to offer this to their own partners and/or customers. As such, the eSIM profile management capability is something that can be supported by integrating with the Windows OMA-DM. This makes it possible to remotely manage the eSIM profiles according to the company policies. As an MDM provider, if you are looking to integrate/onboard to a mobile operator on a 1:1 basis, contact them and learn more about their onboarding. If you would like to integrate and work with only one MDM provider, contact that provider directly. If you would like to offer eSIM management to customers using different MDM providers, contact an orchestrator provider. Orchestrator providers act as proxy handling MDM onboarding as well as mobile operator onboarding. Their role is to make the process as painless and scalable as possible for all parties. Potential orchestrator providers you could contact include:
+- Contact mobile operators directly or contact orchestrator providers. Windows provides the capability for eSIM profiles to be managed by MDM providers in the case of enterprise use cases. However, Windows does not limit how ecosystem partners might want to offer this to their own partners and/or customers. As such, the eSIM profile management capability is something that can be supported by integrating with the Windows OMA-DM. This makes it possible to remotely manage the eSIM profiles according to the company policies. Contact mobile operators directly or contact orchestrator providers. Windows provides the capability for eSIM profiles to be managed by MDM providers in the case of enterprise use cases. However, Windows does not limit how ecosystem partners might want to offer this capability to their own partners and/or customers. As such, the eSIM profile management capability is something that can be supported by integrating with the Windows OMA-DM. This characteristic makes it possible to remotely manage the eSIM profiles according to the company policies. As an MDM provider, if you are looking to integrate/onboard to a mobile operator on a 1:1 basis, contact them and learn more about their onboarding. If you would like to integrate and work with only one MDM provider, contact that provider directly. If you would like to offer eSIM management to customers using different MDM providers, contact an orchestrator provider. Orchestrator providers act as proxy handling MDM onboarding and as a mobile operator onboarding. Their role is to make the process as painless and scalable as possible for all parties. Potential orchestrator providers you could contact include:
-    - [HPE’s Device Entitlement Gateway](https://www.hpe.com/emea_europe/en/solutions/digital-communications-services.html)
+    - [HPE Device Entitlement Gateway](https://www.hpe.com/emea_europe/en/solutions/digital-communications-services.html)
-    - [IDEMIA’s The Smart Connect - Hub](https://www.idemia.com/smart-connect-hub)
+    - [IDEMIA The Smart Connect - Hub](https://www.idemia.com/smart-connect-hub)
 - Assess solution type that you would like to provide your customers
 - Batch/offline solution
 - IT Admin can manually import a flat file containing list of eSIM activation codes, and provision eSIM on LTE enabled devices.

windows/client-management/mdm/policy-csp-admx-sdiageng.md

@@ -66,7 +66,7 @@ manager: dansimp
 
 <!--/Scope-->
 <!--Description-->
-This policy setting allows users who are connected to the Internet to access and search troubleshooting content that is hosted on Microsoft content servers. Users can access online troubleshooting content from within the Troubleshooting Control Panel UI by clicking "Yes" when they are prompted by a message that states, "Do you want the most up-to-date troubleshooting content?"
+This policy setting allows Internet-connected users to access and search troubleshooting content that is hosted on Microsoft content servers. Users can access online troubleshooting content from within the Troubleshooting Control Panel UI by clicking "Yes" when they are prompted by a message that states, "Do you want the most up-to-date troubleshooting content?"
 
 If you enable or do not configure this policy setting, users who are connected to the Internet can access and search troubleshooting content that is hosted on Microsoft content servers from within the Troubleshooting Control Panel user interface.
 
@@ -116,7 +116,7 @@ This policy setting allows users to access and run the troubleshooting tools tha
 
 If you enable or do not configure this policy setting, users can access and run the troubleshooting tools from the Troubleshooting Control Panel.
 
-If you disable this policy setting, users cannot access or run the troubleshooting tools from the Control Panel.
+If this policy setting is disabled, the users cannot access or run the troubleshooting tools from the Control Panel.
 
 >[!Note]
 >This setting also controls a user's ability to launch standalone troubleshooting packs such as those found in .diagcab files.

windows/client-management/mdm/policy-csp-servicecontrolmanager.md

@@ -58,7 +58,7 @@ This policy setting enables process mitigation options on svchost.exe processes.
 
 If you enable this policy setting, built-in system services hosted in svchost.exe processes will have stricter security policies enabled on them.
 
-This includes a policy requiring all binaries loaded in these processes to be signed by Microsoft, and a policy disallowing dynamically generated code.  
+These stricter security policies include a policy requiring all binaries loaded in these processes to be signed by Microsoft, and a policy disallowing dynamically generated code.  
 
 > [!IMPORTANT]
 > Enabling this policy could cause compatibility issues with third-party software that uses svchost.exe processes (for example, third-party antivirus software).

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

@@ -18,17 +18,17 @@ ms.date: 09/22/2017
 
 # Push notification support for device management
 
-The [DMClient CSP](dmclient-csp.md) supports the ability to configure push-initiated device management sessions. Using the [Windows Notification Services (WNS)](/previous-versions/windows/apps/hh913756(v=win.10)), a management server can request a device to establish a management session with the server through a push notification. A device is configured to support push by the management server by providing the device with a PFN for an application. Once the device is configured, it registers a persistent connection with the WNS cloud (Battery Sense and Data Sense conditions permitting).
+The [DMClient CSP](dmclient-csp.md) supports the ability to configure push-initiated device management sessions. Using the [Windows Notification Services (WNS)](/previous-versions/windows/apps/hh913756(v=win.10)), 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 that it can use to initiate a raw push notification for any ChannelURI. When the management server wants to initiate a device management session with a device, it can utilize its token and the device ChannelURI and begin communicating with the device.
+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.
 
 For more information about how to get push credentials (SID and client secret) and PFN to use in WNS, see [Get WNS credentials and PFN for MDM push notification](#get-wns-credentials-and-pfn-for-mdm-push-notification).
 
 Because a device may not always be connected to the internet, WNS supports caching notifications for delivery to the device once it reconnects. To ensure your notification is cached for delivery, set the X-WNS-Cache-Policy header to Cache. Additionally, if the server wants to send a time-bound raw push notification, the server can use the X-WNS-TTL header that will provide WNS with a time-to-live binding so that the notification will expire after the time has passed. For more information, see [Raw notification overview (Windows Runtime apps)](/previous-versions/windows/apps/jj676791(v=win.10)).
 
-Note the following restrictions related to push notifications and WNS:
+The following restrictions are related to push notifications and WNS:
 
--   Push for device management uses raw push notifications. This means that these raw push notifications do not support or utilize push notification payloads.
+-   Push for device management uses raw push notifications. This restriction means that these raw push notifications do not support or utilize push notification payloads.
 -   Receipt of push notifications are 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.
 -   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 is 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 will not attempt to use a ChannelURI that has expired.
 -   Push is not a replacement for having a polling schedule.

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

@@ -16,12 +16,12 @@ manager: dansimp
 > [!WARNING]
 > Some information relates to prereleased product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here. This CSP was added in Windows 10, version 1809.
 
-The TenantLockdown configuration service provider is used by the IT admin to lock a device to a tenant, which ensures that the device remains bound to the tenant in case of accidental or intentional resets or wipes.
+The TenantLockdown configuration service provider is used by the IT admin to lock a device to a tenant, which ensures that the device remains bound to the tenant if accidental or intentional resets or wipes occur.
 
 > [!NOTE]
 > The forced network connection is only applicable to devices after reset (not new).
 
-The following shows the TenantLockdown configuration service provider in tree format.
+The following example shows the TenantLockdown configuration service provider in tree format.
 ```
 ./Vendor/MSFT
 TenantLockdown
@@ -31,13 +31,13 @@ TenantLockdown
 The root node.
 
 <a href="" id="requirenetworkinoobe"></a>**RequireNetworkInOOBE**  
-Specifies whether to require a network connection during the out-of-box experience (OOBE) at first logon.
+Specifies whether to require a network connection during the out-of-box experience (OOBE) at first sign in.
 
-When RequireNetworkInOOBE is true, when the device goes through OOBE at first logon or after a reset, the user is required to choose a network before proceeding. There is no "skip for now" option.
+When RequireNetworkInOOBE is true, when the device goes through OOBE at first sign in or after a reset, the user is required to choose a network before proceeding. There is no "skip for now" option.
 
 Value type is bool. Supported operations are Get and Replace.
 
--  true - Require network in OOBE  
+-  True - Require network in OOBE  
--  false - No network connection requirement in OOBE
+-  False - No network connection requirement in OOBE
 
 Example scenario:  Henry is the IT admin at Contoso. He deploys 1000 devices successfully with RequireNetworkInOOBE set to true. When users accidentally or intentionally reset their device, they are required to connect to a network before they can proceed. Upon successful connection, users see the Contoso branded sign-in experience where they must use their Azure AD credentials. There is no option to skip the network connection and create a local account.

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

@@ -1,6 +1,6 @@
 ---
 title: TPMPolicy CSP
-description: The TPMPolicy configuration service provider (CSP) provides a mechanism to enable zero exhaust configuration on a Windows device for TPM software components.
+description: The TPMPolicy configuration service provider (CSP) provides a mechanism to enable zero-exhaust configuration on a Windows device for TPM software components.
 ms.author: dansimp
 ms.topic: article
 ms.prod: w10
@@ -14,11 +14,11 @@ manager: dansimp
 # TPMPolicy CSP
 
 
-The TPMPolicy configuration service provider (CSP) provides a mechanism to enable zero exhaust configuration on a Windows device for TPM software components. Zero exhaust is defined as no network traffic (diagnostic data or otherwise, such as downloading background images, Windows Updates, and so on.) from Windows and inbox applications to public IP addresses unless directly intended by the user. This allows the enterprise admin to configure devices where no network communication is initiated by the system without explicit approval.
+The TPMPolicy configuration service provider (CSP) provides a mechanism to enable zero-exhaust configuration on a Windows device for TPM software components. Zero exhaust is defined as no network traffic (diagnostic data or otherwise, such as downloading background images, Windows Updates, and so on) from Windows and inbox applications to public IP addresses, unless directly intended by the user. This definition allows the enterprise admin to configure devices where no network communication is initiated by the system without explicit approval.
 
 The TPMPolicy CSP was added in Windows 10, version 1703.
 
-The following shows the TPMPolicy configuration service provider in tree format.
+The following example shows the TPMPolicy configuration service provider in tree format.
 ```
 ./Vendor/MSFT
 TPMPolicy
@@ -28,13 +28,13 @@ TPMPolicy
 <p>Defines the root node.</p>
 
 <a href="" id="isactivezeroexhaust"></a>**IsActiveZeroExhaust**  
-<p>Boolean value that indicates whether network traffic from the device to public IP addresses is not allowed unless directly intended by the user (zero exhaust). Default value is false. Some examples when zero exhaust is configured:</p>
+<p>Boolean value that indicates that network traffic from the device to public IP addresses is not allowed unless directly intended by the user (zero exhaust). The default value is false. Examples of zero-exhaust configuration and the conditions it requires are described below:</p>
 
 <ul>
 <li>There should be no traffic when machine is on idle. When the user is not interacting with the system/device, no traffic is expected. </li>
-<li>There should be no traffic during installation of Windows and first logon when local ID is used.</li>
+<li>There should be no traffic during installation of Windows and first sign in when local ID is used.</li>
-<li>Launching and using a local app (Notepad, Paint, and so on.) should not send any traffic. Similarly, performing common tasks (clicking on start menu, browsing folders, and so on.) should not send any traffic.</li>
+<li>Launching and using a local app (Notepad, Paint, and so on) should not send any traffic. Similarly, performing common tasks (clicking on start menu, browsing folders, and so on.) should not send any traffic.</li>
-<li>Launching and using Internet enabled apps should not send any unexpected traffic (for maintenance, diagnostic data, and so on.) to Microsoft.</li>
+<li>Launching and using Internet enabled apps should not send any unexpected traffic (for maintenance, diagnostic data, and so on) to Microsoft.</li>
 </ul>
 
 Here is an example: