Added the rest of the how-to articles

Author: w-azure

articles/iot-edge/how-to-monitor-iot-edge-deployments.md

@@ -55,7 +55,7 @@ To view the details of a deployment and monitor the devices running it, use the
 
 1. Select the **Metrics** tab. If you choose a metric from the **Select Metric** drop-down, a **View** button appears for you to display the results. You can also select **Edit Metrics** to adjust the criteria for any custom metrics that you have defined. Select **Save** if you made changes.
 
-   ![View metrics for a deployment](./media/how-to-monitor-iot-edge-deployments/deployment-metrics-tab.png)
+   :::image type="content" source="./media/how-to-monitor-iot-edge-deployments/deployment-metrics-tab.png" alt-text="Screenshot showing the metrics for a deployment.":::
 
 To make changes to your deployment, see [Modify a deployment](how-to-deploy-at-scale.md#modify-a-deployment).
 

articles/iot-edge/how-to-monitor-module-twins.md

@@ -187,7 +187,7 @@ To view the JSON for the module twin:
 1. Select the **Device ID** of the IoT Edge device with the modules you want to monitor.
 1. Select the module name from the **Modules** tab and then select **Module Identity Twin** from the upper menu bar.
 
-  ![Select a module twin to view in the Azure portal](./media/how-to-monitor-module-twins/select-module-twin.png)
+   :::image type="content" source="./media/how-to-monitor-module-twins/select-module-twin.png" alt-text="Screenshot showing how to select a module twin to view in the Azure portal .":::
 
 If you see the message "A module identity doesn't exist for this module", this error indicates that the back-end solution is no longer available that originally created the identity.
 
@@ -199,11 +199,11 @@ To review and edit a module twin:
 1. In the **Explorer**, expand the **Azure IoT Hub**, and then expand the device with the module you want to monitor.
 1. Right-click the module and select **Edit Module Twin**. A temporary file of the module twin is downloaded to your computer and displayed in Visual Studio Code.
 
-  ![Get a module twin to edit in Visual Studio Code](./media/how-to-monitor-module-twins/edit-module-twin-vscode.png)
+   :::image type="content" source="./media/how-to-monitor-module-twins/edit-module-twin-vscode.png" alt-text="Screenshot showing how to get a module twin to edit in Visual Studio Code .":::
 
 If you make changes, select **Update Module Twin** above the code in the editor to save changes to your IoT hub.
 
-  ![Update a module twin in Visual Studio Code](./media/how-to-monitor-module-twins/update-module-twin-vscode.png)
+   :::image type="content" source="./media/how-to-monitor-module-twins/update-module-twin-vscode.png" alt-text="Screenshot showing how to update a module twin in Visual Studio Code.":::
 
 ### Monitor module twins in Azure CLI
 

articles/iot-edge/how-to-observability.md

@@ -28,7 +28,7 @@ In order to go beyond abstract considerations, we'll use a *real-life* scenario
 
 ### La Niña
 
-![Illustration of La Nina solution collecting surface temperature from sensors into Azure IoT Edge](media/how-to-observability/la-nina-high-level.png)
+:::image type="content" source="media/how-to-observability/la-nina-high-level.png" alt-text="Illustration of La Niña solution collecting surface temperature from sensors into Azure I o T Edge.":::
 
 The La Niña service measures surface temperature in Pacific Ocean to predict La Niña winters. There is a number of buoys in the ocean with IoT Edge devices that send the surface temperature to Azure Cloud. The telemetry data with the temperature is pre-processed by a custom module on the IoT Edge device before sending it to the cloud. In the cloud, the data is processed by backend Azure Functions and saved to Azure Blob Storage. The clients of the service (ML inference workflows, decision making systems, various UIs, etc.) can pick up messages with temperature data from the Azure Blob Storage.
 
@@ -80,7 +80,7 @@ It's a common practice to measure service level indicators, like the ones we've
 
 Let's clarify what components the La Niña service consists of:
 
-![Diagram of La Nina components including IoT Edge device and Azure Services](media/how-to-observability/la-nina-metrics.png)
+:::image type="content" source="media/how-to-observability/la-nina-metrics.png" alt-text="Diagram of La Niña components including I o T Edge device and Azure Services":::
 
 There is an IoT Edge device with `Temperature Sensor` custom module (C#) that generates some temperature value and sends it upstream with a telemetry message. This message is routed to another custom module `Filter` (C#). This module checks the received temperature against a threshold window (0-100 degrees Celsius). If the temperature is within the window, the FilterModule sends the telemetry message to the cloud.
 
@@ -95,36 +95,36 @@ In this scenario, we have a fleet of 10 buoys. One of the buoys has been intenti
 
 We're going to monitor Service Level Objectives (SLO) and corresponding Service Level Indicators (SLI) with Azure Monitor Workbooks. This scenario deployment includes the *La Nina SLO/SLI* workbook assigned to the IoT Hub. 
 
-![Screenshot of IoT Hub monitoring showing the Workbooks | Gallery in the Azure portal](media/how-to-observability/dashboard-path.png)
+:::image type="content" source="media/how-to-observability/dashboard-path.png" alt-text="Screenshot of I o T Hub monitoring showing the Workbooks. From the Gallery in the Azure portal.":::
 
 To achieve the best user experience the workbooks are designed to follow the _glance_ -> _scan_ -> _commit_ concept:
 
 #### Glance
 
 At this level, we can see the whole picture at a single glance. The data is aggregated and represented at the fleet level:
 
-![Screenshot of the monitoring summary report in the Azure portal showing an issue with device coverage and data freshness](media/how-to-observability/glance.png)
+:::image type="content" source="media/how-to-observability/glance.png" alt-text="Screenshot of the monitoring summary report in the Azure portal showing an issue with device coverage and data freshness.":::
 
 From what we can see, the service is not functioning according to the expectations. There is a violation of the *Data Freshness* SLO.
 Only 90% of the devices send the data frequently, and the service clients expect 95%.
 
 All SLO and threshold values are configurable on the workbook settings tab:
 
-![Screenshot of the workbook settings in the Azure portal](media/how-to-observability/workbook-settings.png)
+:::image type="content" source="media/how-to-observability/workbook-settings.png" alt-text="Screenshot of the workbook settings in the Azure portal.":::
 
 #### Scan
 
 By clicking on the violated SLO, we can drill down to the *scan* level and see how the devices contribute to the aggregated SLI value. 
 
-![Screenshot of message frequency by device](media/how-to-observability/scan.png)
+:::image type="content" source="media/how-to-observability/scan.png" alt-text="Screenshot of message frequency of different devices.":::
 
 There is a single device (out of 10) that sends the telemetry data to the cloud "rarely". In our SLO definition, we've stated that "frequently" means at least 10 times per minute. The frequency of this device is way below that threshold.
 
 #### Commit
 
 By clicking on the problematic device, we're drilling down to the *commit* level. This is a curated workbook *Device Details* that comes out of the box with IoT Hub monitoring offering. The *La Nina SLO/SLI* workbook reuses it to bring the details of the specific device performance. 
 
-![Screenshot of messaging telemetry for a device in the Azure portal](media/how-to-observability/commit.png)
+:::image type="content" source="media/how-to-observability/commit.png" alt-text="Screenshot of messaging telemetry for a device in the Azure portal.":::
 
 ## Troubleshooting
 
@@ -136,13 +136,13 @@ The *commit* level workbook gives a lot of detailed information about the device
 
 In this scenario, all parameters of the trouble device look normal and it's not clear why the device sends messages less frequent than expected. This fact is also confirmed by the *messaging* tab of the device-level workbook:
 
-![Screenshot of sample messages in the Azure portal](media/how-to-observability/messages.png)
+:::image type="content" source="media/how-to-observability/messages.png" alt-text="Screenshot of sample messages in the Azure portal.":::
 
 The `Temperature Sensor` (tempSensor) module produced 120 telemetry messages, but only 49 of them went upstream to the cloud.
 
 The first step we want to do is to check the logs produced by the `Filter` module. Click the **Troubleshoot live!** button and select the `Filter` module.
 
-![Screenshot of the filter module log in the Azure portal](media/how-to-observability/basic-logs.png)
+:::image type="content" source="media/how-to-observability/basic-logs.png" alt-text="Screenshot of the filter module log in the Azure portal.":::
 
 Analysis of the module logs doesn't discover the issue. The module receives messages, there are no errors. Everything looks good here.
 
@@ -152,7 +152,7 @@ There are two observability instruments serving the deep troubleshooting purpose
 
 The La Niña service uses [OpenTelemetry](https://opentelemetry.io) to produce and collect traces and logs in Azure Monitor.
 
-![Diagram illustrating an IoT Edge device sending telemetry data to Azure Monitor](media/how-to-observability/la-nina-detailed.png)
+:::image type="content" source="media/how-to-observability/la-nina-detailed.png" alt-text="Diagram illustrating an I o T Edge device sending telemetry data to Azure Monitor.":::
 
 IoT Edge modules `Temperature Sensor` and `Filter` export the logs and tracing data via OTLP (OpenTelemetry Protocol) to the [OpenTelemetryCollector](https://opentelemetry.io/docs/collector/) module, running on the same edge device. The `OpenTelemetryCollector` module, in its turn, exports logs and traces to Azure Monitor Application Insights service.
 
@@ -164,39 +164,39 @@ By default, IoT Edge modules on the devices of the La Niña service are configur
 
 We've analyzed the `Information` level logs of the `Filter` module and realized that we need to dive deeper to locate the cause of the issue. We're going to update properties in the `Temperature Sensor` and `Filter` module twins and increase the `loggingLevel` to `Debug` and change the `traceSampleRatio` from `0` to `1`:
 
-![Screenshot of module troubleshooting showing updating FilterModule twin properties](media/how-to-observability/update-twin.png)
+:::image type="content" source="media/how-to-observability/update-twin.png" alt-text="Screenshot of module troubleshooting showing how to update the FilterModule twin properties.":::
 
 With that in place, we have to restart the `Temperature Sensor` and `Filter` modules:
 
-![Screenshot of module troubleshooting showing Restart FilterModule button](media/how-to-observability/restart-module.png)
+:::image type="content" source="media/how-to-observability/restart-module.png" alt-text="Screenshot of module troubleshooting showing the Restart FilterModule button.":::
 
 In a few minutes, the traces and detailed logs will arrive to Azure Monitor from the trouble device. The entire end-to-end message flow from the sensor on the device to the storage in the cloud will be available for monitoring with *application map* in Application Insights:
 
-![Screenshot of application map in Application Insights](media/how-to-observability/application-map.png)
+:::image type="content" source="media/how-to-observability/application-map.png" alt-text="Screenshot of the application map in Application Insights.":::
 
 From this map we can drill down to the traces and we can see that some of them look normal and contain all the steps of the flow, and some of them, are very short, so nothing happens after the `Filter` module. 
 
-![ Screenshot of monitoring traces](media/how-to-observability/traces.png)
+:::image type="content" source="media/how-to-observability/traces.png" alt-text="Screenshot of monitoring traces.":::
 
 Let's analyze one of those short traces and find out what was happening in the `Filter` module, and why it didn't send the message upstream to the cloud. 
 
 Our logs are correlated with the traces, so we can query logs specifying the `TraceId` and `SpanId` to retrieve logs corresponding exactly to this execution instance of the `Filter` module:
 
-![Sample trace query filtering based on Trace ID and Span ID.](media/how-to-observability/logs.png)
+:::image type="content" source="media/how-to-observability/logs.png" alt-text="Sample trace query filtering based on Trace I D and Span I D.":::
 
 The logs show that the module received a message with 70.465-degrees temperature. But the filtering threshold configured on this device is 30 to 70. So the message simply didn't pass the threshold. Apparently, this specific device was configured wrong. This is the cause of the issue we detected while monitoring the La Niña service performance with the workbook.
 
 Let's fix the `Filter` module configuration on this device by updating properties in the module twin. We also want to reduce back the `loggingLevel` to `Information` and `traceSampleRatio` to `0`: 
 
-![Sample JSON showing the logging level and trace sample ratio values](media/how-to-observability/fix-issue.png)
+:::image type="content" source="media/how-to-observability/fix-issue.png" alt-text="Sample JSON showing the logging level and trace sample ratio values.":::
 
 Having done that, we need to restart the module. In a few minutes, the device reports new metric values to Azure Monitor. It reflects in the workbook charts:
 
-![Screenshot of Azure Monitor workbook chart](media/how-to-observability/fixed-workbook.png)
+:::image type="content" source="media/how-to-observability/fixed-workbook.png" alt-text="Screenshot of the Azure Monitor workbook chart.":::
 
 We see that the message frequency on the problematic device got back to normal. The overall SLO value will become green again, if nothing else happens, in the configured observation interval:
 
-![Screenshot of the monitoring summary report in the Azure portal](media/how-to-observability/green-workbook.png)
+:::image type="content" source="media/how-to-observability/green-workbook.png" alt-text="Screenshot of the monitoring summary report in the Azure portal.":::
 
 ## Try the sample
 

articles/iot-edge/how-to-retrieve-iot-edge-logs.md

@@ -133,7 +133,7 @@ In the Azure portal, invoke the method with the method name `GetModuleLogs` and
     }
 ```
 
-![Invoke direct method 'GetModuleLogs' in Azure portal](./media/how-to-retrieve-iot-edge-logs/invoke-get-module-logs.png)
+:::image type="content" source="./media/how-to-retrieve-iot-edge-logs/invoke-get-module-logs.png" alt-text="Screenshot of how to invoke direct method GetModuleLogs in the Azure portal.":::
 
 You can also pipe the CLI output to Linux utilities, like [gzip](https://en.wikipedia.org/wiki/Gzip), to process a compressed response. For example:
 
@@ -272,7 +272,7 @@ In the Azure portal, invoke the method with the method name `UploadModuleLogs` a
     }
 ```
 
-![Invoke direct method 'UploadModuleLogs' in Azure portal](./media/how-to-retrieve-iot-edge-logs/invoke-upload-module-logs.png)
+:::image type="content" source="./media/how-to-retrieve-iot-edge-logs/invoke-upload-module-logs.png" alt-text="Screenshot of how to invoke direct method UploadModuleLogs in the Azure portal.":::
 
 ## Upload support bundle diagnostics
 
@@ -347,7 +347,7 @@ In the Azure portal, invoke the method with the method name `UploadSupportBundle
     }
 ```
 
-![Invoke direct method 'UploadSupportBundle' in Azure portal](./media/how-to-retrieve-iot-edge-logs/invoke-upload-support-bundle.png)
+:::image type="content" source="./media/how-to-retrieve-iot-edge-logs/invoke-upload-support-bundle.png" alt-text="Screenshot showing how to invoke direct method UploadSupportBundle in the Azure portal.":::
 
 ## Get upload request status
 
@@ -399,7 +399,7 @@ In the Azure portal, invoke the method with the method name `GetTaskStatus` and
     }
 ```
 
-![Invoke direct method 'GetTaskStatus' in Azure portal](./media/how-to-retrieve-iot-edge-logs/invoke-get-task-status.png)
+:::image type="content" source="./media/how-to-retrieve-iot-edge-logs/invoke-get-task-status.png" alt-text="Screenshot showing how to invoke direct method GetTaskStatus in Azure portal .":::
 
 ## Next steps
 

articles/iot-edge/how-to-share-windows-folder-to-vm.md

@@ -32,7 +32,7 @@ If you don't have an EFLOW device ready, you should create one before continuing
 
 The Azure IoT Edge for Linux on Windows file and folder sharing mechanism is implemented using [virtiofs](https://virtio-fs.gitlab.io/) technology. *Virtiofs* is a shared file system that lets virtual machines access a directory tree on the host OS. Unlike other approaches, it's designed to offer local file system semantics and performance. *Virtiofs* isn't a network file system repurposed for virtualization. It's designed to take advantage of the locality of virtual machines and the hypervisor. It takes advantage of the virtual machine's co-location with the hypervisor to avoid overhead associated with network file systems.
 
-![Windows folder shared with the EFLOW virtual machine using Virtio-FS technology](media/how-to-share-windows-folder-to-vm/folder-sharing-virtiofs.png)
+:::image type="content" source="media/how-to-share-windows-folder-to-vm/folder-sharing-virtiofs.png" alt-text="Screenshot of a Windows folder shared with the EFLOW virtual machine using Virtio-FS technology.":::
 
 Only Windows folders can be shared to the EFLOW Linux VM and not the other way. Also, for security reasons, when setting the folder sharing mechanism, the user must provide a _root folder_ and all the shared folders must be under that _root folder_. 
 
@@ -48,15 +48,15 @@ The following steps provide example EFLOW PowerShell commands to share one or mo
 
 1. Start by creating a new root shared folder. Go to **File Explorer** and choose a location for the *root folder* and create the folder. 
 
-    For example, create a *root folder* under _C:\Shared_ named **EFLOW-Shared**.
+   For example, create a *root folder* under _C:\Shared_ named **EFLOW-Shared**.
 
-    ![Windows root folder](media/how-to-share-windows-folder-to-vm/root-folder.png)
+   :::image type="content" source="media/how-to-share-windows-folder-to-vm/root-folder.png" alt-text="Screenshot of the Windows root folder.":::
 
 1. Create one or more *shared folders* to be shared with the EFLOW virtual machine. Shared folders should be created under the *root folder* from the previous step. 
 
-    For example, create two folders one named **Read-Access** and one named **Read-Write-Access**. 
+   For example, create two folders one named **Read-Access** and one named **Read-Write-Access**. 
 
-    ![Windows shared folders](media/how-to-share-windows-folder-to-vm/shared-folders.png)
+   :::image type="content" source="media/how-to-share-windows-folder-to-vm/shared-folders.png" alt-text="Screenshot of Windows shared folders.":::
 
 1. Within the _Read-Access_ shared folder, create a sample file that we'll later read inside the EFLOW virtual machine.
 

articles/iot-edge/how-to-use-create-options.md

@@ -57,7 +57,7 @@ If you use the [Azure IoT Edge](https://marketplace.visualstudio.com/items?itemN
 
 One tip for writing create options is to use the `docker inspect` command. As part of your development process, run the module locally using `docker run <container name>`. Once you have the module working the way you want it, run `docker inspect <container name>`. This command outputs the module details in JSON format. Find the parameters that you configured, and copy the JSON. For example:
 
-[![Results of docker inspect edgeHub](./media/how-to-use-create-options/docker-inspect-edgehub-inline-and-expanded.png)](./media/how-to-use-create-options/docker-inspect-edgehub-inline-and-expanded.png#lightbox)
+:::image type="content" source="./media/how-to-use-create-options/docker-inspect-edgehub-inline-and-expanded.png" alt-text="Screenshot of the results of the command docker inspect edgeHub." lightbox="./media/how-to-use-create-options/docker-inspect-edgehub-inline-and-expanded.png":::
 
 ## Common scenarios