Merge pull request #277351 from PatAltimore/patricka-freshness

Freshness

Author: prmerger-automator[bot]

articles/iot-edge/about-iot-edge.md

@@ -1,11 +1,11 @@
 ---
-title: What is Azure IoT Edge | Microsoft Docs
-description: Overview of the Azure IoT Edge service
+title: What is Azure IoT Edge
+description: Overview of the Azure IoT Edge service and its components. Learn how to deploy, run, and monitor containerized Linux workloads at the edge.
 author: PatAltimore
 ms.service: iot-edge
 services: iot-edge
 ms.topic: overview
-ms.date: 1/31/2023
+ms.date: 06/05/2024
 ms.author: patricka
 ms.custom: mvc
 ---

articles/iot-edge/iot-edge-runtime.md

@@ -1,10 +1,10 @@
 ---
-title: Learn how the runtime manages devices - Azure IoT Edge | Microsoft Docs 
+title: Learn how the Azure IoT Edge runtime manages devices
 description: Learn how the IoT Edge runtime manages modules, security, communication, and reporting on your devices
 author: PatAltimore
 
 ms.author: patricka
-ms.date: 06/30/2022
+ms.date: 06/05/2024
 ms.topic: conceptual
 ms.service: iot-edge
 services: iot-edge
@@ -76,7 +76,7 @@ To reduce the bandwidth that your IoT Edge solution uses, the IoT Edge hub optim
 
 :::image type="content" source="./media/iot-edge-runtime/gateway-communication.png" alt-text="Screenshot showing relationships to  I o T Edge hub as a gateway between physical devices and I o T Hub." lightbox="./media/iot-edge-runtime/gateway-communication.png":::
 
-IoT Edge hub can determine whether it's connected to IoT Hub. If the connection is lost, IoT Edge hub saves messages or twin updates locally. Once a connection is reestablished, it syncs all the data. The location used for this temporary cache is determined by a property of the IoT Edge hub's module twin. The size of the cache isn't capped and will grow as long as the device has storage capacity. For more information, see [Offline capabilities](offline-capabilities.md).
+IoT Edge hub can determine whether it's connected to IoT Hub. If the connection is lost, IoT Edge hub saves messages or twin updates locally. Once a connection is reestablished, it syncs all the data. The location used for this temporary cache is determined by a property of the IoT Edge hub's module twin. The size of the cache isn't capped and grows as long as the device has storage capacity. For more information, see [Offline capabilities](offline-capabilities.md).
 
 ### Local communication
 
@@ -124,13 +124,13 @@ When a client connects to the IoT Edge hub, the following happens:
 
 By default, the IoT Edge hub only accepts connections secured with Transport Layer Security (TLS), for example, encrypted connections that a third party can't decrypt.
 
-If a client connects on port 8883 (MQTTS) or 5671 (AMQPS) to the IoT Edge hub, a TLS channel must be built. During the TLS handshake, the IoT Edge hub sends its certificate chain that the client needs to validate. In order to validate the certificate chain, the root certificate of the IoT Edge hub must be installed as a trusted certificate on the client. If the root certificate isn't trusted, the client library will be rejected by the IoT Edge hub with a certificate verification error.
+If a client connects on port 8883 (MQTTS) or 5671 (AMQPS) to the IoT Edge hub, a TLS channel must be built. During the TLS handshake, the IoT Edge hub sends its certificate chain that the client needs to validate. In order to validate the certificate chain, the root certificate of the IoT Edge hub must be installed as a trusted certificate on the client. If the root certificate isn't trusted, the client library is rejected by the IoT Edge hub with a certificate verification error.
 
 The steps to follow to install this root certificate of the broker on device clients are described in the [transparent gateway](how-to-create-transparent-gateway.md) and in the [prepare a downstream device](how-to-connect-downstream-device.md#prerequisites) documentation. Modules can use the same root certificate as the IoT Edge hub by using the IoT Edge daemon API.
 
 #### Authentication
 
-The IoT Edge Hub only accepts connections from devices or modules that have an IoT Hub identity. For example, those that have been registered in IoT Hub and have one of the three client authentication methods supported by IoT hub to prove their identity: [Symmetric keys authentication](how-to-authenticate-downstream-device.md#symmetric-key-authentication), [X.509 self-signed authentication](how-to-authenticate-downstream-device.md#x509-self-signed-authentication), [X.509 CA signed authentication](how-to-authenticate-downstream-device.md#x509-ca-signed-authentication).  These IoT Hub identities can be verified locally by the IoT Edge hub so connections can still be made while offline.
+The IoT Edge Hub only accepts connections from devices or modules that have an IoT Hub identity. For example, those that are registered in IoT Hub and have one of the three client authentication methods supported by IoT Hub to prove their identity: [Symmetric keys authentication](how-to-authenticate-downstream-device.md#symmetric-key-authentication), [X.509 self-signed authentication](how-to-authenticate-downstream-device.md#x509-self-signed-authentication), [X.509 CA signed authentication](how-to-authenticate-downstream-device.md#x509-ca-signed-authentication).  These IoT Hub identities can be verified locally by the IoT Edge hub so connections can still be made while offline.
 
 IoT Edge modules currently only support symmetric key authentication.
 

articles/iot-edge/module-composition.md

@@ -1,10 +1,10 @@
 ---
-title: Deploy module & routes with deployment manifests - Azure IoT Edge
+title: Deploy modules establish routes - Azure IoT Edge
 description: Learn how a deployment manifest declares which modules to deploy, how to deploy them, and how to create message routes between them. 
 author: PatAltimore
 
 ms.author: patricka
-ms.date: 1/31/2023
+ms.date: 06/05/2024
 ms.topic: conceptual
 ms.service: iot-edge
 services: iot-edge
@@ -294,7 +294,7 @@ Option 2, introduced in IoT Edge version 1.0.10 with IoT Edge hub schema version
    }
    ```
 
-**Priority** values can be 0-9, inclusive, where 0 is the highest priority. Messages are queued up based on their endpoints. All priority 0 messages targeting a specific endpoint will be processed before any priority 1 messages targeting the same endpoint are processed, and down the line. If multiple routes for the same endpoint have the same priority, their messages will be processed in a first-come-first-served basis. If no priority is specified, the route is assigned to the lowest priority.
+**Priority** values can be 0-9, inclusive, where 0 is the highest priority. Messages are queued up based on their endpoints. All priority 0 messages targeting a specific endpoint are processed before any priority 1 messages targeting the same endpoint are processed, and down the line. If multiple routes for the same endpoint have the same priority, their messages are processed in a first-come-first-served basis. If no priority is specified, the route is assigned to the lowest priority.
 
 The **timeToLiveSecs** property inherits its value from IoT Edge hub's **storeAndForwardConfiguration** unless explicitly set. The value can be any positive integer.
 

articles/iot-edge/troubleshoot-common-errors.md

@@ -1,10 +1,10 @@
 ---
 title: Troubleshoot Azure IoT Edge common errors
-description: Resolve common issues encountered when using an IoT Edge solution
+description: Resolve common issues in Azure IoT Edge solutions. Learn how to troubleshoot issues with provisioning, deployment, the IoT Edge runtime, and networking.
 author: PatAltimore
 
 ms.author: patricka
-ms.date: 02/26/2024
+ms.date: 06/05/2024
 ms.topic: conceptual
 ms.service: iot-edge
 services: iot-edge
@@ -82,7 +82,7 @@ Ensure that there's a route to the internet for the IP addresses assigned to thi
 
 **Option 1: Set DNS server in container engine settings**
 
-Specify the DNS server for your environment in the container engine settings, which will apply to all container modules started by the engine. Create a file named `daemon.json`, then specify the DNS server to use. For example:
+Specify the DNS server for your environment in the container engine settings, which apply to all container modules started by the engine. Create a file named `daemon.json`, then specify the DNS server to use. For example:
 
 ```json
 {

articles/iot-edge/troubleshoot.md

@@ -1,10 +1,10 @@
 ---
-title: Troubleshoot - Azure IoT Edge | Microsoft Docs 
+title: Troubleshoot Azure IoT Edge 
 description: Use this article to learn standard diagnostic skills for Azure IoT Edge, like retrieving component status and logs
 author: PatAltimore
 
 ms.author: patricka
-ms.date: 08/25/2022
+ms.date: 06/05/2024
 ms.topic: conceptual
 ms.service: iot-edge
 services: iot-edge
@@ -50,7 +50,7 @@ For information about each of the diagnostic checks this tool runs, including wh
 
 When you need to gather logs from an IoT Edge device, the most convenient way is to use the `support-bundle` command. By default, this command collects module, IoT Edge security manager and container engine logs, `iotedge check` JSON output, and other useful debug information. It compresses them into a single file for easy sharing. The `support-bundle` command is available in [release 1.0.9](https://github.com/Azure/azure-iotedge/releases/tag/1.0.9) and later.
 
-Run the `support-bundle` command with the `--since` flag to specify how long from the past you want to get logs. For example `6h` will get logs since the last six hours, `6d` since the last six days, `6m` since the last six minutes and so on. Include the `--help` flag to see a complete list of options.
+Run the `support-bundle` command with the `--since` flag to specify how long from the past you want to get logs. For example `6h` gets logs since the last six hours, `6d` since the last six days, `6m` since the last six minutes and so on. Include the `--help` flag to see a complete list of options.
 
 ```bash
 sudo iotedge support-bundle --since 6h
@@ -91,7 +91,7 @@ To get the latest edgeAgent module twin, run the following command from [Azure C
    az iot hub module-twin show --device-id <edge_device_id> --module-id '$edgeAgent' --hub-name <iot_hub_name>
    ```
 
-This command will output all the edgeAgent [reported properties](./module-edgeagent-edgehub.md). Here are some helpful ones monitor the status of the device:
+This command outputs all the edgeAgent [reported properties](./module-edgeagent-edgehub.md). Here are some helpful ones monitor the status of the device:
 
 * runtime status
 * runtime start time
@@ -198,15 +198,15 @@ You can also restart modules remotely from the Azure portal. For more informatio
 
 ## Check your firewall and port configuration rules
 
-Azure IoT Edge allows communication from an on-premises server to Azure cloud using supported IoT Hub protocols, see [choosing a communication protocol](../iot-hub/iot-hub-devguide-protocols.md). For enhanced security, communication channels between Azure IoT Edge and Azure IoT Hub are always configured to be Outbound. This configuration is based on the [Services Assisted Communication pattern](/archive/blogs/clemensv/service-assisted-communication-for-connected-devices), which minimizes the attack surface for a malicious entity to explore. Inbound communication is only required for [specific scenarios](#anchortext) where Azure IoT Hub needs to push messages to the Azure IoT Edge device. Cloud-to-device messages are protected using secure TLS channels and can be further secured using X.509 certificates and TPM device modules. The Azure IoT Edge Security Manager governs how this communication can be established, see [IoT Edge Security Manager](../iot-edge/iot-edge-security-manager.md).
+Azure IoT Edge allows communication from an on-premises server to Azure cloud using supported IoT Hub protocols. For more information, see [choosing a communication protocol](../iot-hub/iot-hub-devguide-protocols.md). For enhanced security, communication channels between Azure IoT Edge and Azure IoT Hub are always configured to be Outbound. This configuration is based on the [Services Assisted Communication pattern](/archive/blogs/clemensv/service-assisted-communication-for-connected-devices), which minimizes the attack surface for a malicious entity to explore. Inbound communication is only required for [specific scenarios](#anchortext) where Azure IoT Hub needs to push messages to the Azure IoT Edge device. Cloud-to-device messages are protected using secure TLS channels and can be further secured using X.509 certificates and TPM device modules. The Azure IoT Edge Security Manager governs how this communication can be established, see [IoT Edge Security Manager](../iot-edge/iot-edge-security-manager.md).
 
 While IoT Edge provides enhanced configuration for securing Azure IoT Edge runtime and deployed modules, it's still dependent on the underlying machine and network configuration. Hence, it's imperative to ensure proper network and firewall rules are set up for secure edge to cloud communication. The following table can be used as a guideline when configuration firewall rules for the underlying servers where Azure IoT Edge runtime is hosted:
 
 |Protocol|Port|Incoming|Outgoing|Guidance|
 |--|--|--|--|--|
 |MQTT|8883|BLOCKED (Default)|BLOCKED (Default)|<ul> <li>Configure Outgoing (Outbound) to be Open when using MQTT as the communication protocol.<li>1883 for MQTT isn't supported by IoT Edge. <li>Incoming (Inbound) connections should be blocked.</ul>|
 |AMQP|5671|BLOCKED (Default)|OPEN (Default)|<ul> <li>Default communication protocol for IoT Edge. <li> Must be configured to be Open if Azure IoT Edge isn't configured for other supported protocols or AMQP is the desired communication protocol.<li>5672 for AMQP isn't supported by IoT Edge.<li>Block this port when Azure IoT Edge uses a different IoT Hub supported protocol.<li>Incoming (Inbound) connections should be blocked.</ul></ul>|
-|HTTPS|443|BLOCKED (Default)|OPEN (Default)|<ul> <li>Configure Outgoing (Outbound) to be Open on 443 for IoT Edge provisioning. This configuration is required when using manual scripts or Azure IoT Device Provisioning Service (DPS). <li><a id="anchortext">Incoming (Inbound) connection</a> should be Open only for specific scenarios: <ul> <li>  If you have a transparent gateway with downstream devices that may send method requests. In this case, Port 443 doesn't need to be open to external networks to connect to IoTHub or provide IoTHub services through Azure IoT Edge. Thus the incoming rule could be restricted to only open Incoming (Inbound) from the internal network. <li> For Client to Device (C2D) scenarios.</ul><li>80 for HTTP isn't supported by IoT Edge.<li>If non-HTTP protocols (for example, AMQP or MQTT) can't be configured in the enterprise; the messages can be sent over WebSockets. Port 443 will be used for WebSocket communication in that case.</ul>|
+|HTTPS|443|BLOCKED (Default)|OPEN (Default)|<ul> <li>Configure Outgoing (Outbound) to be Open on 443 for IoT Edge provisioning. This configuration is required when using manual scripts or Azure IoT Device Provisioning Service (DPS). <li><a id="anchortext">Incoming (Inbound) connection</a> should be Open only for specific scenarios: <ul> <li>  If you have a transparent gateway with downstream devices that may send method requests. In this case, Port 443 doesn't need to be open to external networks to connect to IoTHub or provide IoTHub services through Azure IoT Edge. Thus the incoming rule could be restricted to only open Incoming (Inbound) from the internal network. <li> For Client to Device (C2D) scenarios.</ul><li>80 for HTTP isn't supported by IoT Edge.<li>If non-HTTP protocols (for example, AMQP or MQTT) can't be configured in the enterprise; the messages can be sent over WebSockets. Port 443 is used for WebSocket communication in that case.</ul>|
 
 
 ## Last resort: stop and recreate all containers