H1 and H2 fix

Author: asergaz

articles/iot/iot-overview-device-management.md

@@ -6,7 +6,7 @@ services: iot
 author: asergaz
 ms.author: sergaz
 ms.topic: overview
-ms.date: 03/20/2025
+ms.date: 03/24/2025
 # Customer intent: As a solution builder or device developer I want a high-level overview of the issues around asset and device management and control so that I can easily find relevant content.
 ---
 
@@ -36,7 +36,7 @@ In an edge-based IoT solution, *command and control* refers to the processes tha
 - To save energy, turn off the lights of a building.
 - Use MQTT topics to let assets communicate with each other through the broker.
 
-## Components
+### Components
 
 An edge-based IoT solution can use the following components for asset management and control:
 
@@ -53,47 +53,6 @@ An edge-based IoT solution can use the following components for asset management
 
 For more information, see [What is asset management in Azure IoT Operations](../iot-operations/discover-manage-assets/overview-manage-assets.md).
 
-## Asset endpoint creation
-
-Azure IoT Operations uses Azure resources called assets and asset endpoints to connect and manage components of your industrial edge environment. Before you can create an asset, you need to define an asset endpoint profile. An *asset endpoint* is a profile that describes southbound edge connectivity information for one or more assets.
-
-Currently, the southbound connectors available in Azure IoT Operations are the connector for OPC UA, the media connector (preview), and the connector for ONVIF (preview). Asset endpoints are configurations for a connector that enable it to connect to an asset. For example:
-
-- An asset endpoint for OPC UA stores the information you need to connect to an OPC UA server.
-- An asset endpoint for the media connector stores the information you need to connect to a media source.
-
-For more information, see [What is the connector for OPC UA?](../iot-operations/discover-manage-assets/overview-opcua-broker.md).
-
-## Asset, tags, and events creation
-
-An *asset* is a logical entity that represents a device or component in the cloud as an Azure Resource Manager resource and at the edge as a Kubernetes custom resource. When you create an asset, you can define its metadata and the datapoints (also called tags) and events that it emits.
-
-Currently, an asset in Azure IoT Operations can be:
-
-- Something connected to an OPC UA server such as a robotic arm.
-- A media source such as a camera.
-
-When you define an asset using either the operations experience web UI or Azure IoT Operations CLI, you can configure *tags* and *events* for each asset:
-
-- A *tag* is a description of a data point that can be collected from an asset. OPC UA tags provide real-time or historical data about an asset.
-- An *event* is a notification from an OPC UA server that can inform you about state changes to your asset.
-
- For more information, see [Define assets and asset endpoints](../iot-operations/discover-manage-assets/concept-assets-asset-endpoints.md).
-
-## Asset endpoints secrets management
-
-On an Azure IoT Operations instance deployed with secure settings, you can add secrets to Azure Key Vault, and sync them to the edge to be used in asset endpoints using the operations experience web UI. Secrets are used in asset endpoints for authentication.
-
-For more information, see [Manage secrets for your Azure IoT Operations deployment](../iot-operations/secure-iot-ops/howto-manage-secrets.md).
-
-## Command and control
-
-Azure IoT Operations includes an enterprise grade, standards compliant MQTT broker. The broker enables bidirectional communication between the edge and the cloud, and powers [event-driven applications](/azure/architecture/guide/architecture-styles/event-driven) at the edge.
-
-Use the MQTT broker to implement command and control solutions that enable you to send commands to your assets either from the cloud or from other edge-based components. Connectors, such as the ONVIF connector, can use MQTT topics to listen for and respond to commands. For example, you can publish a message to a topic in the MQTT broker that's an instruction to a camera to pan left by 20 degrees. The camera can use another topic to publish a message that acknowledges the operation is complete. The [Azure IoT Operations SDKs](https://github.com/Azure/iot-operations-sdks) includes samples that show how to implement these types of command and control scenarios.
-
-For more information, see [Azure IoT Operations built-in local MQTT broker](../iot-operations/manage-mqtt-broker/overview-broker.md).
-
 ### [Cloud-based solution](#tab/cloud)
 
 The following diagram shows a high-level view of the components in a typical cloud-based IoT solution. This article focuses on the device management and control components of a cloud-based IoT solution:
@@ -119,7 +78,7 @@ In a cloud-based IoT solution, *command and control* refers to the processes tha
 - Request maximum and minimum temperature values for the last two hours.
 - Set the sensor data interval to 10 seconds.
 
-## Primitives
+### Primitives
 
 A cloud-based IoT solution can use the following primitives for both device management and command and control:
 
@@ -130,7 +89,48 @@ A cloud-based IoT solution can use the following primitives for both device mana
 
 To learn more, see [Cloud-to-device communications guidance](../iot-hub/iot-hub-devguide-c2d-guidance.md).
 
-## Device registration
+---
+
+## Asset and device management
+
+### [Edge-based solution](#tab/edge)
+
+### Asset endpoint creation
+
+Azure IoT Operations uses Azure resources called assets and asset endpoints to connect and manage components of your industrial edge environment. Before you can create an asset, you need to define an asset endpoint profile. An *asset endpoint* is a profile that describes southbound edge connectivity information for one or more assets.
+
+Currently, the southbound connectors available in Azure IoT Operations are the connector for OPC UA, the media connector (preview), and the connector for ONVIF (preview). Asset endpoints are configurations for a connector that enable it to connect to an asset. For example:
+
+- An asset endpoint for OPC UA stores the information you need to connect to an OPC UA server.
+- An asset endpoint for the media connector stores the information you need to connect to a media source.
+
+For more information, see [What is the connector for OPC UA?](../iot-operations/discover-manage-assets/overview-opcua-broker.md).
+
+### Asset, tags, and events creation
+
+An *asset* is a logical entity that represents a device or component in the cloud as an Azure Resource Manager resource and at the edge as a Kubernetes custom resource. When you create an asset, you can define its metadata and the datapoints (also called tags) and events that it emits.
+
+Currently, an asset in Azure IoT Operations can be:
+
+- Something connected to an OPC UA server such as a robotic arm.
+- A media source such as a camera.
+
+When you define an asset using either the operations experience web UI or Azure IoT Operations CLI, you can configure *tags* and *events* for each asset:
+
+- A *tag* is a description of a data point that can be collected from an asset. OPC UA tags provide real-time or historical data about an asset.
+- An *event* is a notification from an OPC UA server that can inform you about state changes to your asset.
+
+ For more information, see [Define assets and asset endpoints](../iot-operations/discover-manage-assets/concept-assets-asset-endpoints.md).
+
+### Asset endpoints secrets management
+
+On an Azure IoT Operations instance deployed with secure settings, you can add secrets to Azure Key Vault, and sync them to the edge to be used in asset endpoints using the operations experience web UI. Secrets are used in asset endpoints for authentication.
+
+For more information, see [Manage secrets for your Azure IoT Operations deployment](../iot-operations/secure-iot-ops/howto-manage-secrets.md).
+
+### [Cloud-based solution](#tab/cloud)
+
+### Device registration
 
 Before a device can connect to an IoT hub, it must be registered. Device registration is the process of creating a device identity in the cloud. Each IoT hub has its own internal device registry. The device identity is used to authenticate the device when it connects to IoT Hub. A device registration entry includes the following properties:
 
@@ -144,38 +144,38 @@ To learn more, see [Understand the identity registry in your IoT hub](../iot-hub
 
 IoT Central provides a UI to manage the device registry in the underlying IoT hub. To learn more, see [Add a device (IoT Central)](../iot-central/core/howto-manage-devices-individually.md#add-a-device).
 
-## Device provisioning
+### Device provisioning
 
 You must configure each device in your solution with the details of the IoT hub it should connect to. You can manually configure each device in your solution, but this approach might not be practical for a large number of devices. To get around this problem, you can use the Device Provisioning Service (DPS) to automatically register each device with an IoT hub, and then provision each device with the required connection information. If your IoT solution uses multiple IoT hubs, you can use DPS to provision devices to a hub based on criteria such as which is the closest hub to the device. You can configure your DPS with rules for registering and provisioning your devices in advance of physically deploying the device in the field.
 
 If your IoT solution uses IoT Hub, then using DPS is optional. If you're using IoT Central, then your solution automatically uses a DPS instance that IoT Central manages.
 
 To learn more, see [Device provisioning service overview](../iot-dps/about-iot-dps.md).
 
-## Device deployment
+### Device deployment
 
 In a cloud-based IoT solution, device deployment typically refers to the process of installing software on an IoT Edge device. When an IoT Edge device connects to an IoT hub, it receives a *deployment manifest* that contains details of the modules to run on the device. The deployment manifest also contains configuration information for the modules. There are many standard modules available for IoT Edge devices. You can also create your own custom modules.
 
 To learn more, see [What is Azure IoT Edge?](../iot-edge/about-iot-edge.md)
 
 If you're using IoT Central, you can [manage your deployment manifests](../iot-central/core/howto-manage-deployment-manifests.md) by using the IoT Central UI.
 
-## Device updates
+### Device updates
 
 Typically, your IoT solution must include a way to update device software. For an IoT Edge device, you can update the modules that run on the device by updating the deployment manifest.
 
 For a non-IoT Edge device, you need to have a way to update the device firmware. This update process could use a cloud-to-device message to notify the device that a firmware update is available. Then the device runs custom code to download and install the update.
 
 The [Device Update for IoT Hub](../iot-hub-device-update/understand-device-update.md) service provides a managed solution for updating devices. It enables you to upload firmware updates to the cloud and then distribute them to devices. It also lets you monitor the update process and roll back to a previous version if the update fails.
 
-## Device key management and rotation
+### Device key management and rotation
 
 During the lifecycle of your IoT solution, you might need to roll over the keys used to authenticate devices. For example, you might need to roll over your keys if you suspect that a key is compromised or if a certificate expires:
 
 - [Roll over the keys used to authenticate devices in IoT Hub and DPS](../iot-dps/how-to-roll-certificates.md)
 - [Roll over the keys used to authenticate devices in IoT Central](../iot-central/core/how-to-connect-devices-x509.md#roll-your-x509-device-certificates)
 
-## Device monitoring
+### Device monitoring
 
 As part of overall solution monitoring, you might want to monitor the health of your devices. For example, you might want to monitor the health of your devices or detect when a device is no longer connected to the cloud. Options for monitoring devices include:
 
@@ -187,12 +187,24 @@ As part of overall solution monitoring, you might want to monitor the health of
 
 To learn more, see [Monitor device connection status (IoT Hub)](../iot-hub/monitor-device-connection-state.md).
 
-## Device migration
+### Device migration
 
 If you need to migrate a device from IoT Central to IoT Hub, you can use the Device Migration tool. To learn more, see [Migrate devices from IoT Central to IoT Hub](../iot-central/core/howto-migrate-to-iot-hub.md).
 
+---
+
 ## Command and control
 
+### [Edge-based solution](#tab/edge)
+
+Azure IoT Operations includes an enterprise grade, standards compliant MQTT broker. The broker enables bidirectional communication between the edge and the cloud, and powers [event-driven applications](/azure/architecture/guide/architecture-styles/event-driven) at the edge.
+
+Use the MQTT broker to implement command and control solutions that enable you to send commands to your assets either from the cloud or from other edge-based components. Connectors, such as the ONVIF connector, can use MQTT topics to listen for and respond to commands. For example, you can publish a message to a topic in the MQTT broker that's an instruction to a camera to pan left by 20 degrees. The camera can use another topic to publish a message that acknowledges the operation is complete. The [Azure IoT Operations SDKs](https://github.com/Azure/iot-operations-sdks) includes samples that show how to implement these types of command and control scenarios.
+
+For more information, see [Azure IoT Operations built-in local MQTT broker](../iot-operations/manage-mqtt-broker/overview-broker.md).
+
+### [Cloud-based solution](#tab/cloud)
+
 To send commands to your devices to control their behavior, use:
 
 - *Direct methods* for communications that require immediate confirmation of the result. Direct methods are often used for interactive control of devices such as turning on a fan.
@@ -207,7 +219,7 @@ In some scenarios, you can automate device control based on feedback loops. For
 
 It's also possible to run this kind of automation locally. For example, if you're using IoT Edge to implement your gateway device, you can run the logic that controls the device in an IoT Edge module. Running this kind of logic at the edge can reduce latency and provide resilience if there's a network outage.
 
-## Jobs
+### Jobs
 
 You can use direct methods, desired properties, and cloud-to-device messages to send commands to individual devices. If you need to send commands to multiple devices, you can use jobs. Jobs let you schedule and send commands and desired property updates to multiple devices at the same time. You can also use jobs to monitor the progress of the commands and to roll back to a previous state if the commands fail.
 
@@ -218,9 +230,8 @@ To learn more, see:
 
 ---
 
-## Next steps
-
-Now that you've seen an overview of asset and device management and control in a typical Azure IoT solution, some suggested next steps include:
+## Related content
 
-- [Process and route messages](iot-overview-message-processing.md)
-- [Extend your IoT solution](iot-overview-solution-extensibility.md)
+- [IoT asset and device development](iot-overview-device-development.md)
+- [IoT asset and device connectivity and infrastructure](iot-overview-device-connectivity.md)
+- [What Azure technologies and services can you use to create IoT solutions?](iot-services-and-technologies.md)