edits

Author: v-thepet

articles/iot-hub-device-update/device-update-apt-manifest.md

@@ -18,7 +18,7 @@ When you deliver an apt manifest to a Device Update agent as an update, the agen
 
 Device Update supports the apt `updateType` and apt [update handler](device-update-agent-overview.md#update-handlers). This support allows the Device Update agent to evaluate the installed Debian packages and update the necessary packages.
 
-You can use an apt manifest to update the Device Update agent and its dependencies. List the device update agent name and desired version in the apt manifest like you would for any other package. You can then import this apt manifest and deploy it through the Device Update pipeline.
+You can use an apt manifest to update the Device Update agent and its dependencies. List the device update agent name and desired version in the apt manifest as you would any other package. You can then import this apt manifest and deploy it through the Device Update pipeline.
 
 ## Schema
 
@@ -58,7 +58,7 @@ For example:
 
 Each apt manifest includes the following properties:
 
-- **Name**: A name for this apt manifest that can be whatever name or ID is meaningful for your scenarios. For example, `contoso-iot-edge`.
+- **Name**: A name for this apt manifest, which can be whatever name or ID is meaningful for your scenarios. For example, `contoso-iot-edge`.
 - **Version**: A version number for this apt manifest, for example, `1.0.0.0`.
 - **Packages**: A list of objects containing package-specific properties.
   - **Name**: The package name or ID, for example `iotedge`.
@@ -88,7 +88,7 @@ You can also use an apt manifest to remove installed packages from devices. You
 
 To remove a package, add a minus sign `-` after the package name. Don't include a version number for the packages you're removing. Removing a package through an apt manifest doesn't remove its dependencies and configurations.
 
-For example, the following apt manifest removes the package `contoso1` from the device(s) it's deployed to.
+For example, the following apt manifest removes the package `contoso1` from any devices it's deployed to.
 
 
 ```json
@@ -113,9 +113,9 @@ Keep the following guidelines in mind when you create an apt manifest:
 - List the packages in the apt manifest in the order they should be installed or removed.
 - Always validate the installation of packages on a test device to ensure the desired outcome.
 - When you install a specific version of a package, for example `iotedge 1.0.9-1`, also include the explicit versions of the dependent packages to install, for example, `libiothsm 1.0.9-1`.
-- While not required, it's best to always make your apt manifest cumulative, to avoid getting your device into an unknown state. A cumulative update ensures that your devices have the desired version of every relevant package, even if the device skipped an apt update deployment because of installation failure or being offline.
+- While not required, it's best to always make your apt manifest cumulative, to avoid getting your device into an unknown state. A cumulative update ensures that your devices have the desired version of every relevant package, even if the device skipped an update because of installation failure or being offline.
 
-  For example, given the following base apt manifest:
+  For example, consider the following base apt manifest:
 
   ```JSON
   {
@@ -130,7 +130,7 @@ Keep the following guidelines in mind when you create an apt manifest:
   }
   ```
 
-  The following update includes the `contoso2` package, but not the `contoso1` package.
+  The following version 2.0 update includes the `contoso2` package, but not the `contoso1` package. Not all devices that receive the 2.0 update might have the `contoso1` package.
 
   ```JSON
   {
@@ -145,7 +145,7 @@ Keep the following guidelines in mind when you create an apt manifest:
   }
   ```
 
-  The following update is better because it includes both the `contoso1` and `contoso2` packages:
+  The following version 2.0 update is better because it includes both the `contoso1` and `contoso2` packages:
 
   ```JSON
   {

articles/iot-hub-device-update/device-update-control-access.md

@@ -1,6 +1,6 @@
 ---
-title: Azure RBAC and Azure Device Update for IoT Hub
-description: Understand how Azure Device Update for IoT Hub uses Azure role-based access control (Azure RBAC) to provide authentication and authorization for users and service APIs.
+title: Azure role-based access control (RBAC) and Azure Device Update for IoT Hub
+description: Understand how Azure Device Update for IoT Hub uses Azure role-based access control (RBAC) to provide authentication and authorization for users and service APIs.
 author: vimeht
 ms.author: vimeht
 ms.date: 01/13/2025
@@ -9,9 +9,9 @@ ms.service: azure-iot-hub
 ms.subservice: device-update
 ---
 
-# Azure Device Update for IoT Hub and Azure RBAC
+# Azure RBAC and Azure Device Update for IoT Hub
 
-For users and applications to access Azure Device Update for IoT Hub, they must be granted access to the Device Update resource. You must also configure access for the Device Update service principal to access the IoT hub to deploy updates and manage devices. This article explains how Device Update uses Azure role-based access control (Azure RBAC) to provide authentication and authorization for users and service APIs.
+For users and applications to access Azure Device Update for IoT Hub, they must be granted access to the Device Update resource. The Device Update service principal must also get access to the IoT hub to deploy updates and manage devices. This article explains how Device Update uses Azure role-based access control (Azure RBAC) to provide authentication and authorization for users and service APIs.
 
 ## Device Update access control roles
 
@@ -26,20 +26,20 @@ Device Update supports the following RBAC roles:
 |  Device Update Deployments Administrator | Can manage deployments of updates to devices|
 |  Device Update Deployments Reader| Can view deployments of updates to devices |
 
-You can assign a combination of roles to provide the right level of access. For example, the Device Update Content Administrator role can import and manage updates, but you need the Device Update Deployments Reader role to view the progress of an update. Conversely, the Device Update Reader role can view all updates, but you need the Device Update Deployments Administrator role to deploy a specific update to devices.
+You can assign a combination of roles to provide the right level of access. For example, the Device Update Content Administrator role can import and manage updates, but you need the Device Update Deployments Reader role to view the progress of an update. Conversely, the Device Update Reader role can view all updates, but you need the Device Update Deployments Administrator role to deploy an update to devices.
 
 ## Device Update service principal access to IoT Hub
 
-Device Update communicates with the IoT hub for deployments and to manage updates at scale. To enable this communication, you need to use the IoT hub access permissions to grant IoT Hub Data Contributor access to the Device Update service principal.
+Device Update communicates with the IoT hub it's associated with to deploy and manage updates at scale. To enable this communication, you need to grant the Device Update service principal IoT Hub Data Contributor access to the IoT hub.
 
-You must set these permissions to allow the following deployment, device and update management, and diagnostic actions:
+Setting this permission allows the following deployment, device and update management, and diagnostic actions:
 
 - Create deployment
 - Cancel deployment
 - Retry deployment 
 - Get device
 
-You can set this permission from the IoT hub access control (IAM) page. For more information, see [Configure IoT hub access for the Device Update service principal](configure-access-control-device-update.md#configure-access-for-azure-device-update-service-principal-in-linked-iot-hub).
+You can set this permission from the IoT hub **Access Control (IAM)** page. For more information, see [Configure IoT hub access for the Device Update service principal](configure-access-control-device-update.md#configure-access-for-azure-device-update-service-principal-in-linked-iot-hub).
 
 ## Device Update REST APIs
 
@@ -50,8 +50,8 @@ Device Update uses Microsoft Entra ID for authentication to its REST APIs. To ge
 
 To integrate an application or service with Microsoft Entra ID, first [register a client application with Microsoft Entra ID](../active-directory/develop/quickstart-register-app.md). Client application setup varies depending on the authorization flow you need: users, applications, or managed identities. For example:
 
-- To call Device Update from a mobile or desktop application, add **Mobile and desktop applications** platform with `https://login.microsoftonline.com/common/oauth2/nativeclient` for the redirect URI.
-- To call Device Update from a website with implicit sign-on, add **Web** platform and select **Access tokens (used for implicit flows)**.
+- To call Device Update from a mobile or desktop application, select **Public client/native (mobile & desktop)** in **Select a platform** and enter `https://login.microsoftonline.com/common/oauth2/nativeclient` for the **Redirect URI**.
+- To call Device Update from a website with implicit sign-on, use **Web** platform. Under **Implicit grant and hybrid flows**, select **Access tokens (used for implicit flows)**.
 
 >[!NOTE]
 >Use the most secure authentication flow available. Implicit flow authentication requires a high degree of trust in the application, and carries risks that aren't present in other flows. You should use this flow only when other more secure flows, such as managed identities, aren't viable.
@@ -77,7 +77,7 @@ az account get-access-token --resource 'https://api.adu.microsoft.com/'
 
 #### PowerShell MSAL Library
 
-[MSAL.PS](https://github.com/AzureAD/MSAL.PS) PowerShell module is a wrapper over [Microsoft Authentication Library for .NET (MSAL .NET)](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet) that supports various authentication methods.
+[`MSAL.PS`](https://github.com/AzureAD/MSAL.PS) PowerShell module is a wrapper over [Microsoft Authentication Library for .NET (MSAL .NET)](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet) that supports various authentication methods.
 
 - User credentials:
 

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

@@ -3,15 +3,15 @@ title: Azure Device Update for IoT Hub limits | Microsoft Docs
 description: Understand key limits for Azure Device Update for IoT Hub.
 author: vimeht
 ms.author: vimeht
-ms.date: 01/10/2025
+ms.date: 01/13/2025
 ms.topic: conceptual
 ms.service: azure-iot-hub
 ms.subservice: device-update
 ---
 
 # Azure Device Update for IoT Hub limits
 
-This article provides an overview of the various limits imposed on the Azure Device Update for IoT Hub resource and its associated operations. The article also indicates whether the Standard SKU limits are adjustable by contacting Microsoft Support, and the default and maximum values for adjustable limits.
+This article provides an overview of the various limits imposed on the Azure Device Update for IoT Hub resource and its associated operations. The article also indicates whether the Standard SKU limits are adjustable by contacting Microsoft Support, and the maximum values for adjustable limits.
 
 ## General availability limits
 
@@ -21,7 +21,7 @@ The following tables describe the limits for the Device Update service for the S
 
 ## Requirements for large-file downloads
 
-To deploy large-file packages with file size larger than 100 MB, it's best to use byte range requests for reliable download performance. Device Update uses Content Delivery Networks (CDNs) that work optimally with range requests of 1 MB in size. Range requests larger than 100 MB aren't supported.
+To deploy large-file packages with file sizes larger than 100 MB, it's best to use byte range requests for reliable download performance. Device Update uses Content Delivery Networks (CDNs) that work optimally with range requests of 1 MB in size. Range requests larger than 100 MB aren't supported.
 
 ## Throttling limits
 
@@ -51,9 +51,9 @@ The following table shows the enforced throttles for operations in all Device Up
 |List Versions| 510/min*|
 |List Operation Statuses| 50/min|
 
-\* The number of calls per minute is shared across all the listed operations.
+\*The number of calls per minute is shared across all the listed operations.
 
-Also, the number of concurrent asynchronous import and/or delete operations is limited to 10 total operation jobs.
+Also, the number of concurrent asynchronous import and delete operations is limited to 10 total operation jobs.
 
 ## Related content
 

articles/iot-hub-device-update/device-update-plug-and-play.md

@@ -40,7 +40,7 @@ The Device Update agent uses the following agent metadata fields to send informa
 |stepResults|map|device to cloud|The result reported by the agent, containing result code, extended result code, and result details for step updates. <br>Example: "step_1": { "resultCode": 0,"extendedResultCode": 0, "resultDetails": ""}|
 |state|integer|device to cloud| An integer that indicates the current state of the Device Update agent. See [State](#state) for details. |
 |workflow|complex|device to cloud| A set of values that indicate the deployment the agent is currently working on, the ID of the currently installed deployment, and acknowledgment of any retry request sent from service to agent. The `workflow` ID reports a `"nodeployment"` value once a deployment is cancelled. <br>Example: "workflow": {"action": 3,"ID": "11b6a7c3-6956-4b33-b5a9-87fdd79d2f01","retryTimestamp": "2022-01-26T11:33:29.9680598Z"}|
-|installedUpdateId|string|device to cloud|An ID of the currently installed Device Update deployment. This value captures the update ID JSON or `null` for a device that has never taken an update through Device Update. Example: installedUpdateID{\"provider\":\"contoso\",\"name\":\"image-update\",\"version\":\"1.0.0\"}"|
+|installedUpdateId|string|device to cloud|An ID of the currently installed Device Update deployment. This value captures the update ID JSON, or `null` for a device that never had an update through Device Update. <br>Example: "installedUpdateID" {"provider":"contoso","name":"image-update","version":"1.0.0"}"|
 
 IoT Hub device twin example:
 
@@ -73,7 +73,7 @@ IoT Hub device twin example:
                         "id": "11b6a7c3-6956-4b33-b5a9-87fdd79d2f01",
                         "retryTimestamp": "2022-01-26T11:33:29.9680598Z"
                     },
-                    "installedUpdateId": "{\"provider\":\"Contoso\",\"name\":\"Virtual-Vacuum\",\"version\":\"5.0\"}"
+                    "installedUpdateId": "{"provider":"Contoso","name":"Virtual-Vacuum","version":"5.0"}"
                 },
 ```
 
@@ -86,7 +86,7 @@ The **deviceProperties** field contains the manufacturer and model information f
 
 |Name|Schema|Direction|Description|
 |----|------|---------|-----------|
-|manufacturer|string|device to cloud|The device manufacturer of the device, reported through `deviceProperties`.<br>The `DeviceUpdateCore` interface first attempts to read the `aduc_manufacturer` value from the [configuration file](device-update-configuration-file.md). If the value isn't populated in the configuration file, the interface defaults to reporting the compile-time definition for `ADUC_DEVICEPROPERTIES_MANUFACTURER`. This property is reported only at boot time. <br> Default value: 'Contoso'.|
+|manufacturer|string|device to cloud|The device manufacturer of the device, reported through `deviceProperties`.<br>The `DeviceUpdateCore` interface first attempts to read the `aduc_manufacturer` value from the [configuration file](device-update-configuration-file.md). If the value isn't populated in the configuration file, the interface defaults to reporting the compile-time definition for `ADUC_DEVICEPROPERTIES_MANUFACTURER`. This property is reported only at boot time. <br> Default value: 'Contoso'|
 |model|string|device to cloud|The device model of the device, reported through `deviceProperties`. The `DeviceUpdateCore` interface first attempts to read the `aduc_model` value from the [configuration file](device-update-configuration-file.md).  If the value isn't populated in the configuration file, the interface defaults to reporting the compile-time definition for `ADUC_DEVICEPROPERTIES_MODEL`. This property is reported only at boot time. <br> Default value: 'Video'|
 |contractModelId|string|device to cloud|Property the service uses to identify the base model version the Device Update agent is using to manage and communicate with the agent.<br>Value: `dtmi:azure:iot:deviceUpdateContractModel;3` for devices using Device Update agent version 1.1.0. <br>**Note:** Agents using `dtmi:azure:iot:deviceUpdateModel;2` must report the `contractModelId` as `dtmi:azure:iot:deviceUpdateContractModel;3`, because `deviceUpdateModel;3` is extended from `deviceUpdateContractModel;3`.|
 |aduVer|string|device to cloud|Version of the Device Update agent running on the device. This value is read from the build only if `ENABLE_ADU_TELEMETRY_REPORTING` is set to `1` (true) during compile time. You can choose to opt out of version reporting by setting the value to `0` (false). For more information, see [How To Build the Device Update Agent](https://github.com/Azure/iot-hub-device-update/blob/main/docs/agent-reference/how-to-build-agent-code.md).|
@@ -95,7 +95,7 @@ The **deviceProperties** field contains the manufacturer and model information f
 
 #### State
 
-The **state** field is the status reported by the Device Update agent in response to an [Action](#action) for details) sent to the Device Update agent from the Device Update service. For more information about requests that flow between the Device Update service and the Device Update agent, see the [Agent workflow](understand-device-update.md#device-update-agent).
+The **state** field is the status reported by the Device Update agent in response to an [Action](#action) sent to the Device Update agent from the Device Update service. For more information about requests that flow between the Device Update service and the Device Update agent, see the [Agent workflow](understand-device-update.md#device-update-agent).
 
 |Name|Value|Description|
 |---------|-----|-----------|

includes/device-update-for-iot-hub-limits.md

@@ -1,13 +1,13 @@
 ---
 author: vimeht
 ms.author: vimeht
-ms.date: 01/10/2024
+ms.date: 01/13/2024
 ms.topic: include
 ms.service: azure-iot-hub
 ms.subservice: device-update
 ---
 
-If a given resource or operation doesn't have adjustable limits, the default and the maximum limits are the same. For adjustable limits, the following tables show both the default and maximum limits. The limits can be raised above the default limit but not above the maximum limit.
+If a given resource or operation doesn't have adjustable limits, the default and the maximum limits are the same. For adjustable limits, the limits can be raised above the default limit but not above the maximum limit.
 
 Limits can be adjusted only for the Standard SKU. Free SKU limit adjustment requests aren't accepted, and Free SKU instances can't be upgraded to Standard SKU instances.
 
@@ -26,11 +26,11 @@ The following table shows the limits associated with various Device Update opera
 
 | Operation | Standard SKU limit | Free SKU limit | Adjustable for Standard SKU? |
 | --- | --- | --- | --- |
-| Number of devices per instance | 1 Million | 10 | Yes |
+| Number of devices per instance | 1 million | 10 | Yes |
 | Number of device groups per instance | 100 | 10 | Yes |
 | Number of device classes per instance | 80 | 10 | Yes |
-| Number of active deployments per instance | 50, including one reserved deployment for cancellations | 5, including one reserved deployment for cancellations) | Yes |
-| Number of total deployments per instance, including all active, inactive, and cancelled deployments that aren't deleted) | 100 | 20 | No |
+| Number of active deployments per instance | 50, including one reserved deployment for cancellations | 5, including one reserved deployment for cancellations | Yes |
+| Number of total deployments per instance, including all active, inactive, and cancelled deployments that aren't deleted | 100 | 20 | No |
 | Number of update providers per instance | 25 | 2 | No |
 | Number of update names per provider per instance | 25 | 2 | No |
 | Number of update versions per update provider and name per instance | 100 | 5 | No |