Merge pull request #307752 from MicrosoftDocs/main

Auto Publish – main to live - 2025-11-04 18:00 UTC

Author: learn-build-service-prod[bot]

articles/app-service/app-service-hybrid-connections.md

@@ -138,7 +138,7 @@ In addition to there being an App Service plan SKU requirement, there's an extra
 
 The Hybrid Connections feature requires a relay agent in the network that hosts your Hybrid Connection endpoint. That relay agent is called the Hybrid Connection Manager (HCM). To download the Hybrid Connection Manager, follow the instructions for your client.
 
-This tool runs on both Windows and Linux. On Windows, the Hybrid Connection Manager requires Windows Server 2012 and later. The Hybrid Connection Manager runs as a service and connects outbound to Azure Relay on port 443.
+This tool runs on both Windows and Linux. The Hybrid Connection Manager runs as a service and connects outbound to Azure Relay on port 443. On Windows, the current version requires Windows Server 2012 or later, but only supports the CLI interface on Windows Server 2012 (the GUI requires Windows Server 2016 or later). A legacy version that supports the GUI on Windows Server 2012 is available but not recommended - see the note in the troubleshooting section for details.
 
 > [!NOTE]
 > As of October 20, 2025, [Azure Service Bus no longer supports TLS 1.0 and TLS 1.1][ServiceBus]. The minimum TLS version is now 1.2 for all Service Bus deployments. Hybrid Connections use Service Bus for connectivity. App Service Hybrid Connection Manager version 0.7.7 and later supports TLS 1.2. If you are on a previous version, **you must update to the new version of the Hybrid Connection Manager as soon as possible to prevent service disruption.**

articles/azure-resource-manager/management/azure-services-resource-providers.md

@@ -197,12 +197,13 @@ The resource providers for IoT services are:
 
 | Resource provider namespace | Azure service |
 | --------------------------- | ------------- |
+| Microsoft.IoTOperations | [Azure IoT Operations](../../iot-operations/index.yml) |
+| Microsoft.DeviceRegistry | [Azure Device Registry](../../iot-operations/overview-iot-operations.md#manage-devices-and-assets) |
 | Microsoft.Devices | [Azure IoT Hub](../../iot-hub/index.yml)<br />[Azure IoT Hub Device Provisioning Service](../../iot-dps/index.yml) |
 | Microsoft.DeviceUpdate | [Device Update for IoT Hub](../../iot-hub-device-update/index.yml) |
 | Microsoft.DigitalTwins | [Azure Digital Twins](../../digital-twins/overview.md) |
-| Microsoft.IoTCentral | [Azure IoT Central](../../iot-central/index.yml) |
 | Microsoft.IoTSpaces | [Azure Digital Twins](../../digital-twins/index.yml) |
-| Microsoft.TimeSeriesInsights | [Azure Time Series Insights](../../time-series-insights/index.yml) |
+| Microsoft.IoTCentral | [Azure IoT Central](../../iot-central/index.yml) |
 | Microsoft.WindowsIoT | [Windows 10 IoT Core Services](/windows-hardware/manufacture/iot/iotcoreservicesoverview) |
 
 ## Management resource providers

articles/container-apps/scale-app.md

@@ -323,7 +323,7 @@ You can create a custom Container Apps scaling rule based on any [ScaledObject](
 | Cool down period | 300 |
 
 > [!NOTE]
-> Cool down period only takes effect when scaling from in from the final replica in to 0. The cool down period does not affect scaling as any other replicas are removed. 
+> Cool down period only takes effect when scaling in from the final replica to 0. The cool down period does not affect scaling as any other replicas are removed. 
 
 For [event-driven Container Apps jobs](jobs.md#event-driven-jobs), you can create a custom scaling rule based on any [ScaledJob](https://keda.sh/docs/latest/concepts/scaling-jobs/)-based KEDA scalers.
 

articles/iot-operations/develop-edge-apps/overview-edge-apps.md

@@ -35,7 +35,7 @@ When a subscriber application sends an acknowledgment for a QoS-1 message, it ta
 
 ## Message retention and broker behavior
 
-The broker retains messages until it receives an acknowledgment from a subscriber, ensuring zero message loss. This behavior guarantees that even if a subscriber application crashes or loses connectivity temporarily, messages won't be lost and can be processed once the application reconnects. MQTT broker messages might expire if configured by the [Message-Expiry-Interval](https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901112) and a subscriber didn't consume the message.
+The broker retains messages until it receives an acknowledgment from a subscriber, ensuring zero message loss. This behavior guarantees that even if a subscriber application crashes or loses connectivity temporarily, messages aren't lost and can be processed once the application reconnects. MQTT broker messages might expire if configured by the [Message-Expiry-Interval](https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901112) and a subscriber didn't consume the message.
 
 ## Retained messages
 
@@ -55,34 +55,23 @@ MQTT subscriptions with QoS-1 ensure eventual consistency across identical appli
 
 ## State store
 
-State store is a replicated in-memory *HashMap* for managing application processing state. Unlike *etcd*, for example, state store prioritizes high-velocity throughput, horizontal scaling, and low latency through in-memory data structures, partitioning, and chain-replication. It allows applications to use the state stores distributed nature and fault tolerance while accessing a consistent state quickly across instances. To use the built-in key-value store provided by the distributed broker:
+State store is a replicated in-memory *HashMap* for managing application processing state. Unlike *etcd*, for example, state store prioritizes high-velocity throughput, horizontal scaling, and low latency through in-memory data structures, partitioning, and chain-replication. It allows applications to use the state stores distributed nature and fault tolerance while accessing a consistent state quickly across instances. To use the built-in key-value store, provided by the distributed broker:
 
-* Implement ephemeral storage and retrieval operations using the broker's key-value store API, ensuring proper error handling and data consistency. Ephemeral state is a short-lived data storage used in stateful processing for fast access to intermediate results or metadata during real-time computations. In the context of HA application, an ephemeral state helps recover application states between crashes. It can be written to disk but remains temporary, as opposed to cold storage that's designed for long-term storage of infrequently accessed data.
+* Implement ephemeral storage and retrieval operations using the broker's key-value store API, ensuring proper error handling and data consistency. Ephemeral state is a short-lived data storage used in stateful processing for fast access to intermediate results or metadata during real-time computations. In the context of HA application, an ephemeral state helps recover application states between crashes. It can be written to disk but remains temporary, as opposed to cold storage that is designed for long-term storage of infrequently accessed data.
 
 * Use the state store for sharing state, caching, configuration, or other essential data among multiple instances of the application, allowing them to keep a consistent view of the data.
 
-## Use MQTT broker's built-in Dapr integration
-
-For simpler use cases an application might utilize [Dapr](https://dapr.io) (Distributed Application Runtime). Dapr is an open-source, portable, event-driven runtime that simplifies building microservices and distributed applications. It offers a set of building blocks, such as service-to-service invocation, state management, and publish/subscribe messaging.
-
-[Dapr is offered as part of MQTT broker](howto-develop-dapr-apps.md), abstracting away details of MQTT session management, message QoS and acknowledgment, and built-in key-value stores, making it a practical choice for developing a highly available application for simple use cases by:
-
-* Design your application using Dapr's building blocks, such as state management for handling the key-value store, and publish/subscribe messaging for interacting with the MQTT broker. If the use case requires building blocks and abstractions that aren't supported by Dapr, consider using the before mentioned MQTT broker features.
-
-* Implement the application using your preferred programming language and framework, leveraging Dapr SDKs or APIs for seamless integration with the broker and the key-value store.
-
 ## Checklist to develop a highly available application
 
 * Choose an appropriate MQTT client library for your programming language. The client should support MQTT v5. Use a C or Rust based library if your application is sensitive to latency.
 * Configure the client library to connect to MQTT broker with *clean-session* flag set to `false` and the desired QoS level (QoS-1).
 * Decide a suitable value for session expiry, message expiry, and keep-alive intervals.
-* Implement the message processing logic for the subscriber application, including sending an acknowledgment when the message has been successfully delivered or processed.
+* Implement the message processing logic for the subscriber application, including sending an acknowledgment when the message is successfully delivered or processed.
 * For multithreaded applications, configure the *max-receive* parameter to enable parallel message processing.
 * Utilize retained messages for keeping temporary application state.
 * Utilize the distributed state store to manage ephemeral application state.
-* Evaluate Dapr to develop your application if your use case is simple and doesn't require detailed control over the MQTT connection or message handling.
 * Implement shared subscriptions to distribute messages evenly among multiple instances of the application, allowing for efficient scaling.
 
 ## Related content
 
-- [Use Dapr to develop distributed application workloads](howto-develop-dapr-apps.md)
+- [Data persistence in the MQTT broker state store](overview-state-store.md)

articles/iot-operations/develop-edge-apps/overview-iot-operations-sdks.md

@@ -34,25 +34,20 @@ The SDKs are open source and available on GitHub:
 > Azure IoT Operations SDKs is currently in PREVIEW.
 > The assets in the [Azure IoT Operations SDKs GitHub repository](https://github.com/Azure/iot-operations-sdks) are available for early access and feedback purposes.
 
-## Goal of the SDKs
+## Benefits of the SDKs
 
-The goal of the SDKs is to provide an application framework to abstract the MQTT concepts, with a clean API that let you use the *Protocol Compiler (codegen)*, to generate code from [Digital Twins Definition Language (DTDL)](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/README.md) models in the supported programming languages.
+Compared to using an MQTT client directly, the SDKs provide an application framework that abstracts MQTT concepts, exposes a clean API surface, and supports the *Protocol Compiler (codegen)* to generate client and server code from [Digital Twins Definition Language (DTDL)](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/README.md) models. The SDKs can be used to build highly available applications at the edge, that interact with Azure IoT Operations to perform operations such as **asset discovery**, **protocol translation** and **data transformation**.
 
-The SDKs can be used to build highly available applications at the edge, that interact with Azure IoT Operations to perform operations such as **asset discovery**, **protocol translation** and **data transformation**.
+The key benefits of using the SDKs include:
 
-## Benefits of using the SDKs
+- **Connectivity**: Maintain a secure connection to the MQTT Broker, including rotating server certificates and authentication keys.
+- **Security**: Support SAT or X.509 certificate authentication with credential rotation.
+- **Configuration**: Configure the MQTT Broker connection through the file system, environment, or connection string.
+- **Services**: Provides client libraries to Azure IoT Operations services for simplified development.
+- **Protocol Compiler (codegen)**: Provides contract guarantees between client and servers via RPC and Telemetry.
+- **High availability**: Building blocks for building highly available apps via state store and lease lock.
+- **Payload formats**: Supports multiple serialization formats, built in when using codegen.
 
-The SDKs provide many benefits compared to using the MQTT client directly:
-
-| Feature | Benefit |
-|-|-|
-| **Connectivity** | Maintain a secure connection to the MQTT Broker, including rotating server certificates and authentication keys. |
-| **Security** | Support SAT or X.509 certificate authentication with credential rotation. |
-| **Configuration** | Configure the MQTT Broker connection through the file system, environment, or connection string. |
-| **Services** | Provides client libraries to Azure IoT Operations services for simplified development. |
-| **Protocol Compiler (codegen)** | Provides contract guarantees between client and servers via RPC and Telemetry. |
-| **High availability** | Building blocks for building highly available apps via state store, lease lock, and leader election clients. |
-| **Payload formats** | Supports multiple serialization formats, built in. |
 
 ## Components of the SDKs
 
@@ -62,7 +57,7 @@ The SDKs provide many components available for simplicity and ease of use:
 
 * A set of protocol primitives, designed to help creating applications, built on the fundamental protocol implementations: **Commands** and **Telemetry**. 
 
-* A set of clients providing integration with Azure IoT Operations services such as **state store**, **leader election**, **lease lock**, and **schema registry**.
+* A set of clients providing integration with Azure IoT Operations services such as **state store**, **lease lock**, **Azure Device Registry**, and **schema registry**.
 
 * A **Protocol Compiler (codegen)**, that allows clients and servers to communicate via a schema contract. First describe the communication (using **Telemetry** and **Commands**) with DTDL, then generate a set of client libraries and server library stubs across the supported programming languages.
 
@@ -77,10 +72,7 @@ The SDKs supports the following application types:
 | Application type | Description |
 |-|-|
 | [Edge application](https://github.com/Azure/iot-operations-sdks/blob/main/doc/edge_application/README.md) | Generic edge applications that need to interface with various Azure IoT Operations services such as the MQTT broker and state store. The SDKs provide convenient clients to simplify the development experience. </br></br>*An Edge application is a customer managed artifact, including deployment to the cluster and monitoring execution.* |
-| [Akri connector](../discover-manage-assets/overview-akri.md#connectors)</br>*(in development)*| Specialized edge applications deployed by the _Akri operator_ service and designed to interface with on-premises devices. An Akri connector is responsible for discovering assets available via the endpoint, and relaying information to and from those assets. </br></br>*An Akri connector's deployment is managed automatically by the Akri operator service.* |
-
-> [!NOTE]
-> Akri connectors are part of the [Akri services (preview)](../discover-manage-assets/overview-akri.md), which is under active development and will be available soon.
+| [Akri connector](../discover-manage-assets/overview-akri.md#connectors)| Specialized edge applications deployed by the _Akri operator_ service and designed to interface with on-premises devices. An Akri connector is responsible for securing connections to southbound devices and assets using their native protocols, sending telemetry and data to upstream Azure IoT Operations components, and optionally detecting assets for onboarding into Azure Device Registry. </br></br>*An Akri connector's deployment is managed automatically by the Akri operator service.* |
 
 ## Samples and tutorials
 
@@ -94,4 +86,4 @@ For documentation related to the implementation of the SDKs, it's fundamentals p
 
 ## Next step
 
-Try the [Quickstart: Start developing with the Azure IoT Operations SDKs (preview)](quickstart-get-started-sdks.md)
+Try the [Quickstart: Start developing with the Azure IoT Operations SDKs (preview)](quickstart-get-started-sdks.md)

articles/iot-operations/develop-edge-apps/quickstart-get-started-sdks.md

@@ -32,9 +32,6 @@ Developing with the Azure IoT Operations SDKs requires a Kubernetes cluster with
 
 ### [Codespaces](#tab/codespaces)
 
-> [!CAUTION]
-> We're currently experiencing container corruption with Azure IoT Operations deployed in a codespace, so we don't recommend this path until we resolve the issue with the GitHub team.
-
 GitHub Codespaces provides the most streamlined experience and can get the development environment up and running in a couple of minutes.
 
 1. Create a **codespace** in GitHub Codespaces from the *Azure IoT Operations SDKs* repository: