Fixing acrolinx

Author: SoniaLopezBravo

articles/iot-hub-device-update/device-update-compliance.md

@@ -11,7 +11,7 @@ ms.subservice: device-update
 
 # Device Update compliance
 
-In Device Update for IoT Hub, compliance measures how many devices are running the latest available version. A device is compliant if it has installed the highest available version update that is compatible for it.
+In Device Update for IoT Hub, compliance measures the number of devices running the latest available version. A device is compliant when it runs the highest available version update compatible with its model.
 
 For example, consider an instance of Device Update with the following updates:
 
@@ -21,7 +21,7 @@ For example, consider an instance of Device Update with the following updates:
 | Update2     | 1.0            | Model2                  |
 | Update3     | 2.0            | Model1                  |
 
-Let’s say the following deployments have been created:
+Let’s say the following deployments are created:
 
 | Deployment name | Update name | Targeted group |
 |-----------------|-------------|----------------|
@@ -40,10 +40,10 @@ Now, consider the following devices, with their group memberships and installed
 
 Device1 and Device4 aren't compliant because they have version 1.0 installed even though there’s a higher version update, Update3, compatible for their model in the Device Update instance. Device2 and Device3 are both compliant because they have the highest version updates compatible for their models installed.
 
-Compliance doesn't consider whether an update is deployed to a device’s group or not; it looks at any updates published to Device Update. So in the example above, even though Device1 has installed the update deployed to it, it's considered non-compliant. Device1 will continue being considered non-compliant until it successfully installs Update3. The compliance status can help you identify whether new deployments are needed.
+Compliance doesn't depend on whether an update has been deployed to a device’s group; it considers any updates published to Device Update. In the example, Device1 installs the update deployed to it, but it remains non-compliant. Device1 stays non-compliant until it installs Update3. The compliance status helps identify when new deployments are necessary.
 
-As shown above, there are three compliance states in Device Update for IoT Hub:
+There are three compliance states in Device Update for IoT Hub:
 
-* **On latest update** – the device has installed the highest compatible version update published to Device Update.
-* **Update in progress** – an active deployment is in the process of delivering the highest compatible version update to the device.
-* **New updates available** – a device hasn't yet installed the highest compatible version update and isn't in an active deployment for that update.
+* **On latest update** – the device runs the highest compatible version update published to Device Update.
+* **Update in progress** – an active deployment is delivering the highest compatible version update to the device.
+* **New updates available** – the device does not run the highest compatible version update and is not in an active deployment for that update.

articles/iot-hub-device-update/device-update-diagnostics.md

@@ -11,13 +11,13 @@ ms.subservice: device-update
 
 # Device Update for IoT Hub diagnostics overview
 
-Device Update for IoT Hub has several features that help you to diagnose and troubleshoot device-side errors. With the release of the v0.9.0 agent, there are three diagnostic features available:
+Device Update for IoT Hub has several features that help you to diagnose and troubleshoot device-side errors. There are three diagnostic features available:
 
-* **Deployment error codes** can be viewed directly in the Device Update user interface
+* **Deployment error codes** can be viewed directly in the Device Update user interface.
 
-* **Remote log collection** enables the creation of log operations, which instruct targeted devices to upload on-device diagnostic logs to a linked Azure Blob storage account
+* **Remote log collection** enables the creation of log operations, which instruct targeted devices to upload on-device diagnostic logs to a linked Azure Blob storage account.
 
-* **Agent Check** runs validation checks on devices registered to your Device Update instance with the goal of diagnosing devices that are registered in the connected IoT Hub, but are not showing up in Device Update
+* **Agent Check** runs validation checks on devices registered to your Device Update instance with the goal of diagnosing devices that are registered in the connected IoT Hub, but are not showing up in Device Update.
 
 ## Deployment error codes in UI
 
@@ -29,12 +29,12 @@ When a device reports a deployment failure to the Device Update service, the Dev
 
 1. Select the name of a group with an active deployment to get to the **Group details** page.
 
-1. Select any device name in the **Device list** to open the device details panel. Here you can see the result code that the device has reported.
+1. Select any device name in the **Device list** to open the device details panel. Here you can see the result code that the device reported.
 
 1. The Device Update reference agent follows standard HTTP status code convention for the result code field (for example, "200" indicates success). For more information on how to parse result codes, see [Device Update client error codes](device-update-error-codes.md).
 
     > [!NOTE]
-    > If you have modified your Device Update agent to report customized result codes, the numerical codes will still be passed through to the Device Update user interface. You may then refer to any documentation you have created to parse these numerical codes.
+    > If you have modified your Device Update agent to report customized result codes, the numerical codes are still passed through to the Device Update user interface. You may then refer to any documentation you created to parse these numerical codes.
 
 ## Remote log collection
 
@@ -44,32 +44,25 @@ Device Update's remote log collection is a service-driven, operation-based featu
 
 From a high level, the log collection feature works as follows:
 
-1. The user creates a new log operation using the Device Update user interface or APIs, targeting up to 100 devices that have implemented the Diagnostics interface.
-
-2. The Device Update service sends a log collection start message to the targeted devices using the Diagnostics interface. This start message includes the log operation ID and a SAS token for uploading to the associated Azure Storage account.
-
-3. Upon receiving the start message, the Device Update agent of the targeted device attempts to collect and upload the files in the pre-defined filepath(s) specified in the on-device agent configuration file. The Device Update reference agent is configured to upload the Device Update agent diagnostic log (`aduc.log`), and the DO Agent diagnostic log ("do-agent.log") by default.
-
-4. The Device Update agent then reports the state of the operation (either **Succeeded** or **Failed**) back to the service, including the log operation ID, a ResultCode, and an ExtendedResultCode. If the Device Update agent fails a log operation, it will automatically attempt to retry three times, reporting only the final state back to the service.
-
-5. Once all targeted devices have reported their terminal state back to the Device Update service, the Device Update service marks the log operation as either **Succeeded** or **Failed**. A successful log operation indicates that all targeted devices successfully completed the log operation. A failed log operation indicates that at least one targeted device failed the log operation.
+1. You create a new log operation using the Device Update user interface or APIs, targeting up to 100 devices that have implemented the Diagnostics interface.
+1. The Device Update service sends a log collection start message to the targeted devices using the Diagnostics interface. This start message includes the log operation ID and a SAS token for uploading to the associated Azure Storage account.
+1. Upon receiving the start message, the Device Update agent of the targeted device attempts to collect and upload the files in one or more pre-defined filepaths specified in the on-device agent configuration file. The Device Update reference agent is configured to upload the Device Update agent diagnostic log (`aduc.log`), and the DO Agent diagnostic log ("do-agent.log") by default.
+1. The Device Update agent then reports the state of the operation (either **Succeeded** or **Failed**) back to the service, including the log operation ID, a ResultCode, and an ExtendedResultCode. If the Device Update agent fails a log operation, it automatically attempts to retry three times, reporting only the final state back to the service.
+1. Once all targeted devices have reported their terminal state back to the Device Update service, the Device Update service marks the log operation as either **Succeeded** or **Failed**. A successful log operation indicates that all targeted devices successfully completed the log operation. A failed log operation indicates that at least one targeted device failed the log operation.
 
    > [!NOTE]
-   > Since the log operation is carried out in parallel by the targeted devices, it is possible that some targeted devices successfully uploaded logs, but the overall log operation is marked as failed. You can see which devices succeeded and which failed by viewing the log operation details through the user interface or APIs.
+   > Since the log operation is carried out in parallel by the targeted devices, it's possible that some targeted devices successfully uploaded logs, but the overall log operation is marked as failed. You can see which devices succeeded and which failed by viewing the log operation details through the user interface or APIs.
 
 ## Agent Check
 
-When your device is registered in IoT Hub but is not appearing in your Device Update instance, you can use the Agent Check feature to run pre-made validation checks to help you diagnose the underlying issue. You can start using this feature by following these [Agent Check instructions](device-update-agent-check.md).
+When your device is registered in IoT Hub but isn't appearing in your Device Update instance, you can use the Agent Check feature to run pre-made validation checks to help you diagnose the underlying issue. You can start using this feature by following these [Agent Check instructions](device-update-agent-check.md).
 
 From a high level, the agent check feature works as follows:
 
-- The user registers a device with IoT Hub. If the device reports a Model ID that matches those compatible with Device Update for IoT Hub, the user's connected Device Update instance will automatically register the device with Device Update.
-
-- In order for a device to be properly managed by Device Update, it must meet certain criteria that can be verified using Agent Check's pre-made validation checks. More information on these criteria can be found [here](device-update-agent-check.md).
-
-- If a device does not meet all of these criteria, it cannot be properly managed by Device Update and will not show up in the Device Update interface or API responses. Users can use Agent Check to find this device and attempt to identify which criteria is not being met by using Agent Check.
-
-- Once the user has identified which criteria is not being met, the user may correct the issue and the device should then properly appear in the Device Update interface.
+1. You register a device with IoT Hub. If the device reports a Model ID that matches those compatible with Device Update for IoT Hub, your connected Device Update instance automatically registers the device with Device Update.
+1. In order for a device to be properly managed by Device Update, it must meet certain criteria that can be verified using Agent Check's pre-made validation checks. More information on these criteria can be found [here](device-update-agent-check.md).
+1. If a device doesn't meet all of these criteria, it can't be properly managed by Device Update and doesn't show up in the Device Update interface or API responses. You can use Agent Check to find this device and attempt to identify which criteria isn't met by using Agent Check.
+1. Once you identified which criteria is not being met, you may correct the issue and the device should then properly appear in the Device Update interface.
 
 ## Next steps