Highlight recommendations

Author: SoniaLopezBravo

articles/iot-hub/iot-hub-devguide-no-sdk.md

@@ -2,7 +2,6 @@
 title: Develop without an Azure IoT SDK
 description: This article provides information about and links to topics that you can use to build device apps and back-end apps without using an Azure IoT SDK.
 author: SoniaLopezBravo
-
 ms.author: sonialopez
 ms.service: azure-iot-hub
 ms.topic: concept-article
@@ -16,7 +15,8 @@ This topic provides helpful information and links for developers who want to dev
 
 Microsoft strongly advises using an Azure IoT SDK. The Azure IoT device and service SDKs are published on many popular platforms. The SDKs provide a convenience layer that handles much of the complexity of the underlying communication protocol, including device connection and reconnection, and retry policy. The SDKs are regularly updated to provide the latest features exposed by IoT Hub as well as security updates. Using the SDKs can help you reduce development time and time devoted to code maintenance. To learn more about the Azure IoT SDKs, see [Azure IoT Device and Service SDKs](iot-hub-devguide-sdks.md). For more detail about the advantages of using an Azure IoT SDK, see the [Benefits of using the Azure IoT SDKs and pitfalls to avoid if you don’t](https://azure.microsoft.com/blog/benefits-of-using-the-azure-iot-sdks-in-your-azure-iot-solution/) blog post.
 
-Although IoT Hub supports AMQP, AMQP over WebSockets, HTTPS, MQTT, and MQTT over WebSockets for communication with devices, we recommend using MQTT if your device supports it.
+> [!NOTE]
+> Although IoT Hub supports AMQP, AMQP over WebSockets, HTTPS, MQTT, and MQTT over WebSockets for communication with devices, we recommend using MQTT if your device supports it.
 
 ## Development prerequisites
 

articles/iot-hub/iot-hub-devguide-routing-query-syntax.md

@@ -20,7 +20,10 @@ Message routing allows you to query on the message properties and message body a
 
 ## Query based on message properties
 
-IoT Hub defines a [common format](iot-hub-devguide-messages-construct.md) for all device-to-cloud messaging for interoperability across protocols. IoT Hub assumes the following JSON representation of the message. System properties are added for all users and identify content of the message. Users can selectively add application properties to the message. We recommend using unique property names because IoT Hub device-to-cloud messaging isn't case-sensitive. For example, if you have multiple properties with the same name, IoT Hub only sends one of the properties.  
+IoT Hub defines a [common format](iot-hub-devguide-messages-construct.md) for all device-to-cloud messaging for interoperability across protocols. IoT Hub assumes the following JSON representation of the message. System properties are added for all users and identify content of the message. Users can selectively add application properties to the message. 
+
+> [!NOTE]
+> We recommend using unique property names because IoT Hub device-to-cloud messaging isn't case-sensitive. For example, if you have multiple properties with the same name, IoT Hub only sends one of the properties.  
 
 ```json
 { 
@@ -217,7 +220,7 @@ Message routing enables you to query on [device twin](iot-hub-devguide-device-tw
 
 ### Twin query expressions
 
-A query on a device twin or module twin needs to be prefixed with `$twin`. Your query expression can also combine a twin tag or property reference with a body reference, a message system properties reference, or a message application properties reference. We recommend using unique names in tags and properties because the query isn't case-sensitive. This recommendation applies to both device twins and module twins. We also recommend that you avoid using `twin`, `$twin`, `body`, or `$body` as property names. For example, the following examples are all valid query expressions: 
+A query on a device twin or module twin needs to be prefixed with `$twin`. Your query expression can also combine a twin tag or property reference with a body reference, a message system properties reference, or a message application properties reference. For example, the following examples are all valid query expressions: 
 
 ```sql
 $twin.properties.desired.telemetryConfig.sendFrequency = '5m'
@@ -231,6 +234,9 @@ $body.Weather.Temperature = 50 AND $twin.properties.desired.telemetryConfig.send
 $twin.tags.deploymentLocation.floor = 1 
 ```
 
+> [!NOTE]
+> We recommend using unique names in tags and properties because the query isn't case-sensitive. This recommendation applies to both device twins and module twins. You should also avoid using `twin`, `$twin`, `body`, or `$body` as property names.
+
 ## Limitations
 
 Routing queries don't support using whitespace or any of the following characters in property names, the message body path, or the device/module twin path: `()<>@,;:\"/?={}`.

articles/iot-hub/iot-hub-troubleshoot-connectivity.md

@@ -42,7 +42,10 @@ Consider the following issues when deciding whether to use Event Grid or Azure M
 
 ## Event Grid: Monitor connect and disconnect events
 
-To monitor device connect and disconnect events in production, we recommend subscribing to the [**DeviceConnected** and **DeviceDisconnected** events](iot-hub-event-grid.md#event-types) in Event Grid to trigger alerts and monitor device connection state. Event Grid provides lower event latency than Azure Monitor, and you can monitor on a per-device basis. These factors make Event Grid the preferred method for monitoring critical devices and infrastructure.
+Event Grid provides lower event latency than Azure Monitor, and you can monitor on a per-device basis. These factors make Event Grid the preferred method for monitoring critical devices and infrastructure.
+
+> [!NOTE]
+> To monitor device connect and disconnect events in production, we recommend subscribing to the [**DeviceConnected** and **DeviceDisconnected** events](iot-hub-event-grid.md#event-types) in Event Grid to trigger alerts and monitor device connection state.
 
 When you use Event Grid to monitor or trigger alerts on device disconnects, make sure you build in a way of filtering out the periodic disconnects due to SAS token renewal on devices that use the Azure IoT SDKs. To learn more, see [MQTT device disconnect behavior with Azure IoT SDKs](#mqtt-device-disconnect-behavior-with-azure-iot-sdks).
 

articles/iot-hub/migrate-hub-arm.md

@@ -411,7 +411,7 @@ Now you have the environment variables in a file with the SET commands, and you
     dotnet run arg1 arg2 arg3 arg4 arg5
     ```
 
-    The dotnet command builds and runs the application. Because you're passing in the options when you run the application, you can change the values of them each time you run the application. For example, you may want to run it once and create new devices, then run it again and copy those devices to a new hub, and so on. You can also perform all the steps in the same run, although we recommend not deleting any devices until you're certain you're finished with the migration. Here's an example that creates 1,000 devices and then copies them to the other hub.
+    The dotnet command builds and runs the application. Because you're passing in the options when you run the application, you can change the values of them each time you run the application. For example, you may want to run it once and create new devices, then run it again and copy those devices to a new hub, and so on. You can also perform all the steps in the same run, although we recommend **not deleting** any devices until you're certain you're finished with the migration. Here's an example that creates 1,000 devices and then copies them to the other hub.
 
     ``` console
     // Format: dotnet run add-devices num-to-add copy-devices delete-source-devices delete-destination-devices

articles/iot-hub/monitor-device-connection-state.md

@@ -17,30 +17,29 @@ The following table introduces three ways to monitor your device connection stat
 
 | Method | Status frequency | Cost | Effort to build |
 | --- | --- | --- | --- |
-| Device twin connectionState property | Intermittent | Low | Low |
-| Event Grid | 60 seconds | Low | Low |
-| Custom device heartbeat pattern | Custom | High | High |
+| [Device twin connectionState property](#device-twin-connectionstate) | Intermittent | Low | Low |
+| [Event Grid](#event-grid) | 60 seconds | Low | Low |
+| [Custom device heartbeat pattern](#device-heartbeat-pattern) | Custom | High | High |
 
-Because of its reliability, low cost, and ease of use we recommend Event Grid as the preferred monitoring solution for most customers.
+Because of its reliability, low cost, and ease of use, we recommend Event Grid as the preferred monitoring solution for most customers.
 
 However, there are certain limitations to monitoring with Event Grid that may disqualify it for some IoT solutions. Use this article to understand the benefits and limitations of each option.
 
 ## Device twin connectionState
 
-Every IoT Hub device identity contains a property called **connectionState** that reports either **connected** or **disconnected**. This property represents IoT Hub's understanding of a device's connection status.
+Every IoT Hub device identity contains a property called `connectionState` that reports either `connected` or `disconnected`. This property represents IoT Hub's understanding of a device's connection status.
 
-The connection state property has several limitations:
+The `connectionState` property has several limitations:
 
-* The connection state is updated only for devices that use MQTT or AMQP.
+* This property is updated only for devices that use MQTT or AMQP.
 * Updates to this property rely on protocol-level pings and may be delayed as much as five minutes.
 
-For these reasons, we recommend that you only use the **connectionState** field during development and debugging. IoT solutions shouldn't query the field at run time. For example, don't query the **connectionState** field to check if a device is connected before you send a cloud-to-device message or an SMS.
+> [!IMPORTANT]
+> We recommend that you only use the `connectionState` field during development and debugging, not in production. IoT solutions shouldn't query the field at run time. For example, don't query the `connectionState` field to check if a device is connected before you send a cloud-to-device message or an SMS.
 
 ## Event Grid
 
-We recommend Event Grid as the preferred monitoring solution for most customers.
-
-Subscribe to the **deviceConnected** and **deviceDisconnected** events on Event Grid to get alerts and monitor the device connection state.
+We recommend Event Grid as the preferred monitoring solution for most customers. Subscribe to the **deviceConnected** and **deviceDisconnected** events on Event Grid to get alerts and monitor the device connection state.
 
 Use the following articles to learn how to integrate device connected and disconnected events in your IoT solution:
 

articles/iot-hub/monitor-iot-hub-reference.md

@@ -463,7 +463,8 @@ IoT Hub records this log when a message containing valid trace properties arrive
 }
 ```
 
-Here, `durationMs` isn't calculated as IoT Hub's clock might not be in sync with the device clock, and thus a duration calculation can be misleading. We recommend writing logic using the timestamps in the `properties` section to capture spikes in device-to-cloud latency.
+> [!NOTE]
+> Here, `durationMs` isn't calculated as IoT Hub's clock might not be in sync with the device clock, and thus a duration calculation can be misleading. We recommend writing logic using the timestamps in the `properties` section to capture spikes in device-to-cloud latency.
 
 | Property | Type | Description |
 |--------------------|-----------------------------------------------|------------------------------------------------------------------------------------------------|

articles/iot-hub/monitor-iot-hub.md

@@ -72,7 +72,8 @@ The IoT Hub [resource logs connections category](monitor-iot-hub-reference.md#co
 
 :::image type="content" source="media/iot-hub-troubleshoot-connectivity/create-diagnostic-setting.png" alt-text="Recommended setting to send connectivity logs to Log Analytics workspace.":::
 
-We recommend creating a diagnostic setting as early as possible after you create your IoT hub, because, although IoT Hub always emits resource logs, Azure Monitor doesn't collect them until you route them to a destination.
+> [!NOTE]
+> We recommend creating a diagnostic setting as early as possible after you create your IoT hub, because, although IoT Hub always emits resource logs, Azure Monitor doesn't collect them until you route them to a destination.
 
 To learn more about routing logs to a destination, see the [Collect and route monitoring data](#collect-and-route-monitoring-data) section. For detailed instructions to create a diagnostic setting, see [Tutorial: Set up and use metrics and logs with an IoT hub](tutorial-use-metrics-and-diags.md).
 

articles/iot-hub/query-twins.md

@@ -193,10 +193,10 @@ Query expressions can have a maximum length of 8192 characters.
 
 Currently, comparisons are supported only between primitive types (no objects), for instance `... WHERE properties.desired.config = properties.reported.config` is supported only if those properties have primitive values.
 
-We recommend to not take a dependency on lastActivityTime found in Device Identity Properties for Twin Queries for any scenario. This field does not guarantee an accurate gauge of device status. Instead, please use IoT Device Lifecycle events to manage device state and activities.  More information on how to use IoT Hub Lifecycle events in your solution, please visit [React to IoT Hub events by using Event Grid to trigger actions](./iot-hub-event-grid.md).
+We recommend to not take a dependency on `lastActivityTime` found in Device Identity Properties for Twin Queries for any scenario. This field does not guarantee an accurate gauge of device status. Instead, please use IoT Device Lifecycle events to manage device state and activities.  More information on how to use IoT Hub Lifecycle events in your solution, please visit [React to IoT Hub events by using Event Grid to trigger actions](./iot-hub-event-grid.md).
 
 
-> [!Note]
+> [!NOTE]
 > Avoid making any assumptions about the maximum latency of this operation.  Please refer to [Latency Solutions](./iot-hub-devguide-quotas-throttling.md) for more information on how to build your solution taking latency into account.
 
 ## Next steps

articles/iot-hub/reference-x509-certificates.md

@@ -116,8 +116,8 @@ Certificates can be saved in various formats. Azure IoT Hub authentication typic
 
 You can authenticate a device to your IoT hub for testing purposes by using two self-signed certificates. This type of authentication is sometimes called *thumbprint authentication* because the certificates are identified by calculated hash values called *fingerprints* or *thumbprints*. These calculated hash values are used by IoT Hub to authenticate your devices.
 
->[!IMPORTANT]
->We recommend that you use certificates signed by an issuing Certificate Authority (CA), even for testing purposes. Never use self-signed certificates in production.
+> [!IMPORTANT]
+> We recommend that you use certificates signed by an issuing Certificate Authority (CA), even for testing purposes. Never use self-signed certificates in production.
 
 ### Create a self-signed certificate
 

articles/iot-hub/troubleshoot-error-codes.md

@@ -141,7 +141,8 @@ To resolve this error:
 * Use the latest versions of the [Azure IoT Hub SDKs](iot-hub-devguide-sdks.md).
 * See the guidance for [500xxx Internal errors](#500xxx-internal-errors).
 
-We recommend using Azure IoT device SDKs to manage connections reliably. To learn more, see [Manage device reconnections to create resilient applications](../iot/concepts-manage-device-reconnections.md)
+> [!NOTE]
+> We recommend using Azure IoT device SDKs to manage connections reliably. To learn more, see [Manage device reconnections to create resilient applications](../iot/concepts-manage-device-reconnections.md)
 
 ## 409001 Device already exists