Merge pull request #227981 from w-azure/winona-images

Updating image links to modern markdown

Author: prmerger-automator[bot]

articles/iot-edge/deploy-confidential-applications.md

@@ -27,7 +27,7 @@ Confidential applications are encrypted in transit and at rest, and only decrypt
 
 The developer creates the confidential application and packages it as an IoT Edge module. The application is encrypted before being pushed to the container registry. The application remains encrypted throughout the IoT Edge deployment process until the module is started on the IoT Edge device. Once the confidential application is within the device's TEE, it is decrypted and can begin executing.
 
-![Diagram - Confidential applications are encrypted within IoT Edge modules until deployed into the secure enclave](./media/deploy-confidential-applications/confidential-applications-encrypted.png)
+:::image type="content" source="./media/deploy-confidential-applications/confidential-applications-encrypted.png" alt-text="Diagram that show confidential applications are encrypted within IoT Edge modules until deployed into the secure enclave.":::
 
 Confidential applications on IoT Edge are a logical extension of [Azure confidential computing](../confidential-computing/overview.md). Workloads that run within secure enclaves in the cloud can also be deployed to run within secure enclaves at the edge.
 

articles/iot-edge/deploy-modbus-gateway.md

@@ -16,7 +16,7 @@ ms.author: patricka
 
 If you want to connect IoT devices that use Modbus TCP or RTU protocols to an Azure IoT hub, you can use an IoT Edge device as a gateway. The gateway device reads data from your Modbus devices, then communicates that data to the cloud using a supported protocol.
 
-![Modbus devices connect to IoT Hub through IoT Edge gateway](./media/deploy-modbus-gateway/diagram.png)
+:::image type="content" source="./media/deploy-modbus-gateway/diagram.png" alt-text="Screenshot of Modbus devices that connect to IoT Hub through IoT Edge gateway.":::
 
 This article covers how to create your own container image for a Modbus module (or you can use a prebuilt sample) and then deploy it to the IoT Edge device that will act as your gateway.
 

articles/iot-edge/how-to-access-dtpm.md

@@ -55,7 +55,7 @@ The following steps show you how to create a sample executable to access a TPM i
 
 1. Choose the **Microsoft.TSS** package from the list then select **Install**.
 
-    ![Visual Studio add NuGet packages](./media/how-to-access-dtpm/vs-nuget-microsoft-tss.png)
+   :::image type="content" source="./media/how-to-access-dtpm/vs-nuget-microsoft-tss.png" alt-text="Screenshot that shows Visual Studio add NuGet packages .":::
 
 1. Edit the *Program.cs* file and replace the contents with the [EFLOW TPM sample code - Program.cs](https://raw.githubusercontent.com/Azure/iotedge-eflow/main/samples/tpm-read-nv/Program.cs).
 
@@ -69,7 +69,7 @@ The following steps show you how to create a sample executable to access a TPM i
     - Target Runtime:  **linux-x64**.
     - Deployment mode: **Self-contained**.
 
-    ![Publish options](./media/how-to-access-dtpm/sample-publish-options.png)
+   :::image type="content" source="./media/how-to-access-dtpm/sample-publish-options.png" alt-text="Screenshot that shows publish options .":::
 
 1. Select **Publish** then wait for the executable to be created. 
 
@@ -132,7 +132,7 @@ Once the executable file and dependency files are created, you need to copy the
     ```
     You should see an output similar to the following.
 
-    ![EFLOW dTPM output](./media/how-to-access-dtpm/tpm-read-output.png)
+   :::image type="content" source="./media/how-to-access-dtpm/tpm-read-output.png" alt-text="Screenshot that shows EFLOW dTPM output.":::
 
 ## Next steps
 

articles/iot-edge/how-to-access-host-storage-from-module.md

@@ -28,7 +28,7 @@ To set up system modules to use persistent storage:
 1. For both IoT Edge hub and IoT Edge agent, add an environment variable called **storageFolder** that points to a directory in the module.
 1. For both IoT Edge hub and IoT Edge agent, add binds to connect a local directory on the host machine to a directory in the module. For example:
 
-   ![Screenshot that shows the add create options and environment variables for local storage](./media/how-to-access-host-storage-from-module/offline-storage-1-4.png)
+   :::image type="content" source="./media/how-to-access-host-storage-from-module/offline-storage-1-4.png" alt-text="Screenshot that shows how to add create options and environment variables for local storage.":::
 
 Or, you can configure the local storage directly in the deployment manifest. For example:
 

articles/iot-edge/how-to-authenticate-downstream-device.md

@@ -67,7 +67,7 @@ When you create the new device identity, provide the following information:
 
 * Select **Set a parent device** and select the IoT Edge gateway device that this downstream device will connect through. You can always change the parent later.
 
-   ![Create device ID with symmetric key auth in portal](./media/how-to-authenticate-downstream-device/symmetric-key-portal.png)
+   :::image type="content" source="./media/how-to-authenticate-downstream-device/symmetric-key-portal.png" alt-text="Screenshot of how to create a device ID with symmetric key authorization in the Azure portal.":::
 
    >[!NOTE]
    >Setting the parent device used to be an optional step for downstream devices that use symmetric key authentication. However, starting with IoT Edge version 1.1.0 every downstream device must be assigned to a parent device.
@@ -118,7 +118,7 @@ For X.509 self-signed authentication, sometimes referred to as thumbprint authen
    * Paste the hexadecimal strings that you copied from your device's primary and secondary certificates.
    * Select **Set a parent device** and choose the IoT Edge gateway device that this downstream device will connect through. You can always change the parent later.
 
-   ![Create device ID with X.509 self-signed auth in portal](./media/how-to-authenticate-downstream-device/x509-self-signed-portal.png)
+   :::image type="content" source="./media/how-to-authenticate-downstream-device/x509-self-signed-portal.png" alt-text="Screenshot that shows how to create a device ID with an X.509 self-signed authorization in the Azure portal.":::
 
 4. Copy both the primary and secondary device certificates and their keys to any location on the downstream device. Also move a copy of the shared root CA certificate that generated both the gateway device certificate and the downstream device certificates.
 

articles/iot-edge/how-to-collect-and-transport-metrics.md

@@ -27,7 +27,7 @@ To configure monitoring on your IoT Edge device, follow the [Tutorial: Monitor I
 
 # [IoT Hub](#tab/iothub)
 
-[![Metrics monitoring architecture with IoT Hub](./media/how-to-collect-and-transport-metrics/arch.png)](./media/how-to-collect-and-transport-metrics/arch.png#lightbox)
+:::image type="content" source="./media/how-to-collect-and-transport-metrics/arch.png" alt-text="Screenshot of the metrics monitoring architecture with IoT Hub." lightbox="./media/how-to-collect-and-transport-metrics/arch.png":::
 
 | Note | Description |
 |-|-|
@@ -42,7 +42,7 @@ To configure monitoring on your IoT Edge device, follow the [Tutorial: Monitor I
 
 # [IoT Central](#tab/iotcentral)
 
-[![Metrics monitoring architecture with IoT Central](./media/how-to-collect-and-transport-metrics/arch-iot-central.png)](./media/how-to-collect-and-transport-metrics/arch-iot-central.png#lightbox)
+:::image type="content" source="./media/how-to-collect-and-transport-metrics/arch-iot-central.png" alt-text="Screenshot of metrics monitoring architecture with IoT Central." lightbox="./media/how-to-collect-and-transport-metrics/arch-iot-central.png":::
 
 | Note | Description |
 |-|-|

articles/iot-edge/how-to-configure-api-proxy-module.md

@@ -264,7 +264,7 @@ To update the proxy configuration dynamically, use the following steps:
 1. Copy the text of the configuration file and convert it to base64.
 1. Paste the encoded configuration file as the value of the `proxy_config` desired property in the module twin.
 
-   ![Paste encoded config file as value of proxy_config property](./media/how-to-configure-api-proxy-module/change-config.png)
+   :::image type="content" source="./media/how-to-configure-api-proxy-module/change-config.png" alt-text="Screenshot that shows how to paste encoded config file as value of proxy_config property.":::
 
 ## Next steps
 

articles/iot-edge/how-to-configure-iot-edge-for-linux-on-windows-iiot-dmz.md

@@ -33,7 +33,7 @@ Since the EFLOW host device and the PLC or OPC UA devices are physically connect
 
 For the other network, the EFLOW host device is physically connected to the DMZ (online network) with internet and Azure connectivity. Using an *internal or external switch*, you can connect the EFLOW VM to Azure IoT Hub using IoT Edge modules and upload the information sent by the offline devices through the offline NIC.
 
-![EFLOW Industrial IoT scenario showing a EFLOW VM connected to offline and online network.](./media/how-to-configure-iot-edge-for-linux-on-windows-iiot-dmz/iiot-multiple-nic.png)
+:::image type="content" source="./media/how-to-configure-iot-edge-for-linux-on-windows-iiot-dmz/iiot-multiple-nic.png" alt-text="Screenshot of an EFLOW Industrial IoT scenario showing an EFLOW virtual machine connected to an offline and online network.":::
 
 ### Scenario summary
 
@@ -76,11 +76,11 @@ For the custom new *external virtual switch* you created, use the following Powe
 
 1. `Add-EflowNetwork -vswitchName "OnlineOPCUA" -vswitchType "External"`
 
-    ![Screenshot of showing successful creation of the external network named OnlineOPCUA.](./media/how-to-configure-iot-edge-for-linux-on-windows-iiot-dmz/add-eflow-network.png)
+   :::image type="content" source="./media/how-to-configure-iot-edge-for-linux-on-windows-iiot-dmz/add-eflow-network.png" alt-text="Screenshot of a successful creation of the external network named OnlineOPCUA.":::
 
 2. `Add-EflowVmEndpoint -vswitchName "OnlineOPCUA" -vEndpointName "OnlineEndpoint" -ip4Address 192.168.0.103 -ip4PrefixLength 24 -ip4GatewayAddress 192.168.0.1`
 
-    ![Screenshot showing the successful configuration of the OnlineOPCUA switch.](./media/how-to-configure-iot-edge-for-linux-on-windows-iiot-dmz/add-eflow-vm-endpoint.png)
+   :::image type="content" source="./media/how-to-configure-iot-edge-for-linux-on-windows-iiot-dmz/add-eflow-vm-endpoint.png" alt-text="Screenshot of a successful configuration of the OnlineOPCUA switch..":::
 
 Once complete, you'll have the *OnlineOPCUA* switch assigned to the EFLOW VM. To check the multiple NIC attachment, use the following steps:
 
@@ -98,7 +98,7 @@ Once complete, you'll have the *OnlineOPCUA* switch assigned to the EFLOW VM. To
 
 1. Review the IP configuration and verify you see the *eth0* interface (connected to the secure network) and the *eth1* interface (connected to the DMZ network).
 
-    ![Screenshot showing IP configuration of multiple NICs connected to two different networks.](./media/how-to-configure-iot-edge-for-linux-on-windows-iiot-dmz/ifconfig-multiple-nic.png)
+   :::image type="content" source="./media/how-to-configure-iot-edge-for-linux-on-windows-iiot-dmz/ifconfig-multiple-nic.png" alt-text="Screenshot showing the IP configuration of multiple NICs connected to two different networks.":::
 
 ## Configure VM network routing 
 
@@ -120,7 +120,7 @@ EFLOW uses the [route](https://man7.org/linux/man-pages/man8/route.8.html) servi
     sudo route
     ```
 
-    ![Screenshot listing routing table for the EFLOW VM.](./media/how-to-configure-iot-edge-for-linux-on-windows-iiot-dmz/route-output.png)
+   :::image type="content" source="./media/how-to-configure-iot-edge-for-linux-on-windows-iiot-dmz/route-output.png" alt-text="Screenshot showing the routing table for the EFLOW virtual machine.":::
 
     >[!TIP]
     >The previous image shows the route command output with the two NIC's assigned (*eth0* and *eth1*). The virtual machine creates two different *default* destinations rules with different metrics. A lower metric value has a higher priority. This routing table will vary depending on the networking scenario configured in the previous steps.