Merge pull request #299959 from DENKEN02MSFT/Top50_patricka_Row43

Top50 - row 43

Author: prmerger-automator[bot]

articles/iot-edge/module-deployment-monitoring.md

@@ -4,7 +4,7 @@ description: Use automatic deployments in Azure IoT Edge to manage groups of dev
 author: PatAltimore
 
 ms.author: patricka
-ms.date: 06/10/2024
+ms.date: 05/16/2025
 ms.topic: concept-article
 ms.service: azure-iot-edge
 services: iot-edge
@@ -29,7 +29,7 @@ The basic deployment steps are as follows:
 3. The IoT Hub service retrieves status from the IoT Edge devices and makes them available to the operator. For example, an operator can see when an Edge device isn't configured successfully or if a module fails during runtime.
 4. At any time, when newly targeted IoT Edge devices come online and connect with IoT Hub, they're configured for the deployment.
 
-This article describes each component involved in configuring and monitoring a deployment. For a walkthrough of creating and updating a deployment, see [Deploy and monitor IoT Edge modules at scale](how-to-deploy-at-scale.md).
+This article describes each component involved in configuring and monitoring a deployment. For a walkthrough of creating and updating a deployment, see [Deploy IoT Edge modules at scale using the Azure portal](how-to-deploy-at-scale.md).
 
 ## Deployment
 
@@ -64,7 +64,7 @@ For example, you have a deployment with a target condition `tags.environment = '
 
 If a deployment has no target condition, then it's applied to no devices.
 
-Use any Boolean condition on device twin tags, device twin reported properties, or deviceId to select the target devices. If you want to use a condition with tags, you need to add a `"tags":{}` section in the device twin under the same level as properties. For more information about tags in a device twin, see [Understand and use device twins in IoT Hub](../iot-hub/iot-hub-devguide-device-twins.md). For more information about query operations, see [IoT Hub query language operators and IS_DEFINED function](../iot-hub/iot-hub-devguide-query-language.md#operators).
+Use any Boolean condition on device twin tags, device twin reported properties, or deviceId to select the target devices. If you want to use a condition with tags, you need to add a `"tags":{}` section in the device twin under the same level as properties. For more information about tags in a device twin, see [Understand and use device twins in IoT Hub](../iot-hub/iot-hub-devguide-device-twins.md). For more information about query operations, see the [IoT Hub query language operators and IS_DEFINED function](../iot-hub/iot-hub-devguide-query-language.md#operators).
 
 Examples of target conditions:
 
@@ -89,11 +89,11 @@ Consider these constraints when you construct a target condition:
 
 ### Priority
 
-A priority defines whether a deployment should be applied to a targeted device relative to other deployments. A deployment priority is a positive integer within the range from 0 through 2,147,483,647. Larger numbers denote a higher priority. If an IoT Edge device is targeted by more than one deployment, the deployment with the highest priority applies. Deployments with lower priorities aren't applied, nor are they merged. If a device is targeted with two or more deployments with equal priority, the most recently created deployment (determined by the creation timestamp) applies.
+A priority defines whether a deployment should be applied to a targeted device relative to other deployments. A deployment priority is a positive integer within the range from 0 through 2,147,483,647. Larger numbers denote a higher priority. If more than one deployment targets an IoT Edge device, the deployment with the highest priority applies. Deployments with lower priorities aren't applied, nor are they merged. If a device is targeted with two or more deployments with equal priority, the most recently created deployment (determined by the creation timestamp) applies.
 
 ### Labels
 
-Labels are string key/value pairs that you can use to filter and group deployments. A deployment may have multiple labels. Labels are optional and don't impact the configuration of IoT Edge devices.
+Labels are string key/value pairs that you can use to filter and group deployments. A deployment might have multiple labels. Labels are optional and don't affect the configuration of IoT Edge devices.
 
 ### Metrics
 
@@ -106,7 +106,7 @@ By default, all deployments report on four metrics:
 
 Additionally, you can define your own custom metrics to help monitor and manage the deployment.
 
-Metrics provide summary counts of the various states that devices may report back as a result of applying a deployment configuration. Metrics can query [edgeHub module twin reported properties](module-edgeagent-edgehub.md#edgehub-reported-properties), like *lastDesiredStatus* or *lastConnectTime*. 
+Metrics provide summary counts of the various states that devices might report back as a result of applying a deployment configuration. Metrics can query [edgeHub module twin reported properties](module-edgeagent-edgehub.md#edgehub-reported-properties), like *lastDesiredStatus* or *lastConnectTime*. 
 
 For example:
 
@@ -115,15 +115,15 @@ SELECT deviceId FROM devices
   WHERE properties.reported.lastDesiredStatus.code = 200
 ```
 
-Adding your own metrics is optional, and doesn't impact the actual configuration of IoT Edge devices.
+Adding your own metrics is optional, and doesn't affect the actual configuration of IoT Edge devices.
 
 ## Layered deployment
 
 Layered deployments are automatic deployments that can be combined together to reduce the number of unique deployments that need to be created. Layered deployments are useful in scenarios where the same modules are reused in different combinations in many automatic deployments.
 
-Layered deployments have the same basic components as any automatic deployment. They target devices based on tags in the device twins and provide the same functionality around labels, metrics, and status reporting. Layered deployments also have priorities assigned to them. Instead of using the priority to determine which deployment is applied to a device, the priority determines how multiple deployments are ranked on a device. For example, if two layered deployments have a module or a route with the same name, the layered deployment with the higher priority will be applied while the lower priority is overwritten.
+Layered deployments have the same basic components as any automatic deployment. They target devices based on tags in the device twins and provide the same functionality around labels, metrics, and status reporting. Layered deployments also have priorities assigned to them. Instead of using the priority to determine which deployment is applied to a device, the priority determines how multiple deployments are ranked on a device. For example, if two layered deployments have a module or a route with the same name, the layered deployment with the higher priority is applied while the lower priority is overwritten.
 
-The system runtime modules, known as edgeAgent and edgeHub, are not configured as part of a layered deployment. Any IoT Edge device targeted by a layered deployment, first needs a standard automatic deployment applied to it. The automatic deployment provides the base upon which layered deployments can be added.
+The system runtime modules, known as edgeAgent and edgeHub, aren't configured as part of a layered deployment. Any IoT Edge device targeted by a layered deployment, first needs a standard automatic deployment applied to it. The automatic deployment provides the base upon which layered deployments can be added.
 
 An IoT Edge device can apply one and only one standard automatic deployment, but it can apply multiple layered automatic deployments. Any layered deployments targeting a device must have a higher priority than the automatic deployment for that device.
 
@@ -137,7 +137,7 @@ However, once the company switches to layered automatic deployments, they can cr
 
 ### Module twin configuration
 
-When you work with layered deployments, you may, intentionally or otherwise, have two deployments with the same module targeting a device. In those cases, you can decide whether the higher priority deployment should overwrite the module twin or append to it. For example, you may have a deployment that applies the same module to 100 different devices. However, 10 of those devices are in secure facilities and need additional configuration in order to communicate through proxy servers. You can use a layered deployment to add module twin properties that enable those 10 devices to communicate securely without overwriting the existing module twin information from the base deployment.
+When you work with layered deployments, you might, intentionally or otherwise, have two deployments with the same module targeting a device. In those cases, you can decide whether the higher priority deployment should overwrite the module twin or append to it. For example, you might have a deployment that applies the same module to 100 different devices. However, 10 of those devices are in secure facilities and need extra configuration in order to communicate through proxy servers. You can use a layered deployment to add module twin properties that enable those 10 devices to communicate securely without overwriting the existing module twin information from the base deployment.
 
 You can append module twin desired properties in the deployment manifest. In a standard deployment, you would add properties in the **properties.desired** section of the module twin. But in a layered deployment, you can declare a new subset of desired properties.
 
@@ -152,7 +152,7 @@ For example, in a standard deployment you might add the simulated temperature se
 }
 ```
 
-In a layered deployment that targets some or all of these same devices, you could add a property that tells the simulated sensor to send 1000 messages and then stop. You don't want to overwrite the existing properties, so you create a new section within the desired properties called `layeredProperties`, which contains the new property:
+In a layered deployment that targets some or all of these same devices, you could add a property that tells the simulated sensor to send 1,000 messages and then stop. You don't want to overwrite the existing properties, so you create a new section within the desired properties called `layeredProperties`, which contains the new property:
 
 ```json
 "SimulatedTemperatureSensor": {
@@ -162,7 +162,7 @@ In a layered deployment that targets some or all of these same devices, you coul
 }
 ```
 
-A device that has both deployments applied will reflect the following properties in the module twin for the simulated temperature sensor:
+A device that has both deployments applied reflects the following properties in the module twin for the simulated temperature sensor:
 
 ```json
 "properties": {
@@ -176,15 +176,15 @@ A device that has both deployments applied will reflect the following properties
 }
 ```
 
-If you set the `properties.desired` field of the module twin in a layered deployment, `properties.desired` will overwrite the desired properties for that module in any lower priority deployments.
+If you set the `properties.desired` field of the module twin in a layered deployment, `properties.desired` overwrites the desired properties for that module in any lower priority deployments.
 
 ## Phased rollout
 
 A phased rollout is an overall process whereby an operator deploys changes to a broadening set of IoT Edge devices. The goal is to make changes gradually to reduce the risk of making wide-scale breaking changes. Automatic deployments help manage phased rollouts across a fleet of IoT Edge devices.
 
 A phased rollout is executed in the following phases and steps:
 
-1. Establish a test environment of IoT Edge devices by provisioning them and setting a device twin tag like `tag.environment='test'`. The test environment should mirror the production environment that the deployment will eventually target.
+1. Establish a test environment of IoT Edge devices by provisioning them and setting a device twin tag like `tag.environment='test'`. The test environment should mirror the production environment that the deployment eventually targets.
 2. Create a deployment including the desired modules and configurations. The targeting condition should target the test IoT Edge device environment.
 3. Validate the new module configuration in the test environment.
 4. Update the deployment to include a subset of production IoT Edge devices by adding a new tag to the targeting condition. Also, ensure that the priority for the deployment is higher than other deployments currently targeted to those devices.
@@ -193,23 +193,23 @@ A phased rollout is executed in the following phases and steps:
 
 ## Rollback
 
-Deployments can be rolled back if you receive errors or misconfigurations. Because a deployment defines the absolute module configuration for an IoT Edge device, an additional deployment must also be targeted to the same device at a lower priority even if the goal is to remove all modules.
+Deployments can be rolled back if you receive errors or misconfigurations. Because a deployment defines the absolute module configuration for an IoT Edge device, an extra deployment must also be targeted to the same device at a lower priority even if the goal is to remove all modules.
 
 Deleting a deployment doesn't remove the modules from targeted devices. There must be another deployment that defines a new configuration for the devices, even if it's an empty deployment.
 
-However, deleting a deployment may remove modules from the targeted device if it was a layered deployment. A layered deployment updates the underlying deployment, potentially adding modules. Removing a layered deployment removes its update to the underlying deployment, potentially removing modules.
+However, deleting a deployment might remove modules from the targeted device if it was a layered deployment. A layered deployment updates the underlying deployment, potentially adding modules. Removing a layered deployment removes its update to the underlying deployment, potentially removing modules.
 
 For example, a device has base deployment A and layered deployments O and M applied onto it (so that the A, O, and M deployments are deployed onto the device). If layered deployment M is then deleted, A and O are applied onto the device, and the modules unique to deployment M are removed.
 
 Perform rollbacks in the following sequence:
 
-1. Confirm that a second deployment is also targeted at the same device set. If the goal of the rollback is to remove all modules, the second deployment should not include any modules.
+1. Confirm that a second deployment is also targeted at the same device set. If the goal of the rollback is to remove all modules, the second deployment shouldn't include any modules.
 2. Modify or remove the target condition expression of the deployment you wish to roll back so that the devices no longer meet the targeting condition.
 3. Verify that the rollback succeeded by viewing the deployment status.
    * The rolled-back deployment should no longer show status for the devices that were rolled back.
    * The second deployment should now include deployment status for the devices that were rolled back.
 
 ## Next steps
 
-* Walk through the steps to create, update, or delete a deployment in [Deploy and monitor IoT Edge modules at scale](how-to-deploy-at-scale.md).
+* Walk through the steps to create, update, or delete a deployment in [Deploy IoT Edge modules at scale using the Azure portal](how-to-deploy-at-scale.md).
 * Learn more about other IoT Edge concepts like the [IoT Edge runtime](iot-edge-runtime.md) and [IoT Edge modules](iot-edge-modules.md).