-## Enable group writeback using Azure AD Connect

-## Enabling group writeback using PowerShell

- 2. In the left browser, navigate to **subscriptions** > **_\<subscription\_name_** > **resourceGroups** > **_\<resource\_group\_name>_** > **providers** > **Microsoft.Web** > **sites** > **_\<app\_name>_** > **config** > **authsettingsV2**.

-# Tutorial: Enable Application Gateway Ingress Controller add-on for an existing AKS cluster with an existing Application Gateway

-You can use Azure CLI or Portal to enable the [Application Gateway Ingress Controller (AGIC)](ingress-controller-overview.md) add-on for an existing [Azure Kubernetes Services (AKS)](https://azure.microsoft.com/services/kubernetes-service/) cluster. In this tutorial, you'll learn how to use AGIC add-on to expose your Kubernetes application in an existing AKS cluster through an existing Application Gateway deployed in separate virtual networks. You'll start by creating an AKS cluster in one virtual network and an Application Gateway in a separate virtual network to simulate existing resources. You'll then enable the AGIC add-on, peer the two virtual networks together, and deploy a sample application that will be exposed through the Application Gateway using the AGIC add-on. If you're enabling the AGIC add-on for an existing Application Gateway and existing AKS cluster in the same virtual network, then you can skip the peering step below. The add-on provides a much faster way of deploying AGIC for your AKS cluster than [previously through Helm](ingress-controller-overview.md#difference-between-helm-deployment-and-aks-add-on) and also offers a fully managed experience.

-> * Create a new Application Gateway

-> * Enable the AGIC add-on in the existing AKS cluster through Portal

-> * Peer the Application Gateway virtual network with the AKS cluster virtual network

-> * Deploy a sample application using AGIC for Ingress on the AKS cluster

-> * Check that the application is reachable through Application Gateway

-In Azure, you allocate related resources to a resource group. Create a resource group by using [az group create](/cli/azure/group#az-group-create). The following example creates a resource group named *myResourceGroup* in the *canadacentral* location (region).

-In the following example, you'll be deploying a new AKS cluster named *myCluster* using [Azure CNI](../aks/concepts-network.md#azure-cni-advanced-networking) and [Managed Identities](../aks/use-managed-identity.md) in the resource group you created, *myResourceGroup*.

-To configure additional parameters for the `az aks create` command, visit references [here](/cli/azure/aks#az-aks-create).

-## Deploy a new Application Gateway

-You'll now deploy a new Application Gateway, to simulate having an existing Application Gateway that you want to use to load balance traffic to your AKS cluster, *myCluster*. The name of the Application Gateway will be *myApplicationGateway*, but you will need to first create a public IP resource, named *myPublicIp*, and a new virtual network called *myVnet* with address space 11.0.0.0/8, and a subnet with address space 11.1.0.0/16 called *mySubnet*, and deploy your Application Gateway in *mySubnet* using *myPublicIp*.

-When using an AKS cluster and Application Gateway in separate virtual networks, the address spaces of the two virtual networks must not overlap. The default address space that an AKS cluster deploys in is 10.0.0.0/8, so we set the Application Gateway virtual network address prefix to 11.0.0.0/8.

-> Application Gateway Ingress Controller (AGIC) add-on **only** supports Application Gateway v2 SKUs (Standard and WAF), and **not** the Application Gateway v1 SKUs.

-If you'd like to continue using Azure CLI, you can continue to enable the AGIC add-on in the AKS cluster you created, *myCluster*, and specify the AGIC add-on to use the existing Application Gateway you created, *myApplicationGateway*.

-## Enable the AGIC add-on in existing AKS cluster through Portal

-If you'd like to use Azure portal to enable AGIC add-on, go to [(https://aka.ms/azure/portal/aks/agic)](https://aka.ms/azure/portal/aks/agic) and navigate to your AKS cluster through the Portal link. From there, go to the Networking tab within your AKS cluster. You'll see an Application Gateway ingress controller section, which allows you to enable/disable the ingress controller add-on using the Portal UI. Check the box next to "Enable ingress controller", and select the Application Gateway you created, *myApplicationGateway* from the dropdown menu.

-

-Since we deployed the AKS cluster in its own virtual network and the Application Gateway in another virtual network, you'll need to peer the two virtual networks together in order for traffic to flow from the Application Gateway to the pods in the cluster. Peering the two virtual networks requires running the Azure CLI command two separate times, to ensure that the connection is bi-directional. The first command will create a peering connection from the Application Gateway virtual network to the AKS virtual network; the second command will create a peering connection in the other direction.

-You'll now deploy a sample application to the AKS cluster you created that will use the AGIC add-on for Ingress and connect the Application Gateway to the AKS cluster. First, you'll get credentials to the AKS cluster you deployed by running the `az aks get-credentials` command.

-Once you have the credentials to the cluster you created, run the following command to set up a sample application that uses AGIC for Ingress to the cluster. AGIC will update the Application Gateway you set up earlier with corresponding routing rules to the new sample application you deployed.

-Now that the Application Gateway is set up to serve traffic to the AKS cluster, let's verify that your application is reachable. You'll first get the IP address of the Ingress.

-Check that the sample application you created is up and running by either visiting the IP address of the Application Gateway that you got from running the above command or check with `curl`. It may take Application Gateway a minute to get the update, so if the Application Gateway is still in an "Updating" state on Portal, then let it finish before trying to reach the IP address.

-When no longer needed, remove the resource group, application gateway, and all related resources.

-If you don't have an Azure subscription, create a [free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

-> This tutorial uses the `us.atlas.microsoft.com` geographical URL. If your Creator service wasn't created in the United States, you must use a different geographical URL. For more information, see [Access to Creator Services](how-to-manage-creator.md#access-to-creator-services).

-3. Enter the following URL to the [Stateset API](/rest/api/maps/v2/feature-state/create-stateset). The request should look like the following URL (replace `{Azure-Maps-Primary-Subscription-key}` with your primary subscription key, and `{datasetId`} with the `datasetId` obtained in the [Check the dataset creation status](tutorial-creator-indoor-maps.md#check-the-dataset-creation-status) section of the *Use Creator to create indoor maps* tutorial):

-3. Enter the following URL to the [Feature Statesets API](/rest/api/maps/v2/feature-state/create-stateset). The request should look like the following URL (replace `{Azure-Maps-Primary-Subscription-key}` with your primary subscription key, and `{statesetId`} with the `statesetId` obtained in [Create a feature stateset](#create-a-feature-stateset)):

-In the next tutorials in the Creator series you will learn to:

-> This tutorial uses the `us.atlas.microsoft.com` geographical URL. If your Creator service wasn't created in the United States, you must use a different geographical URL. For more information, see [Access to Creator Services](how-to-manage-creator.md#access-to-creator-services).

-5. Enter the following URL to the [Data Upload API](/rest/api/maps/data-v2/upload) The request should look like the following URL (replace `{Azure-Maps-Primary-Subscription-key}` with your primary subscription key)::

-10. In the dropdown list, select **binary**.

-5. Enter the `status URL` you copied as the last step in the previous section of this article. You will need to append your subscription key to the end of the URL `&subscription-key={Your-Azure-Maps-Primary-Subscription-key}` (replace `{Azure-Maps-Primary-Subscription-key}` with your Azure Maps primary subscription key). The request should look like the following URL:

-5. Enter the `resource Location URL` you copied as the last step in the previous section of this article. You will need to append your subscription key to the end of the URL `&subscription-key={Your-Azure-Maps-Primary-Subscription-key}` (replace `{Azure-Maps-Primary-Subscription-key}` with your Azure Maps primary subscription key). The request should look like the following URL:

-5. Enter the `status URL` you copied in [Convert a Drawing package](#convert-a-drawing-package). The request should look like the following URL (replace `{Azure-Maps-Primary-Subscription-key}` with your primary subscription key):

-5. Enter the following URL to the [Dataset API](/rest/api/maps/v2/dataset). The request should look like the following URL (replace `{Azure-Maps-Primary-Subscription-key}` with your primary subscription key, and `{conversionId`} with the `conversionId` obtained in [Check Drawing package conversion status](#check-the-drawing-package-conversion-status)):

-5. Enter the `status URL` you copied in [Create a dataset](#create-a-dataset). The request should look like the following URL (replace `{Azure-Maps-Primary-Subscription-key}` with your primary subscription key):

-5. Enter the following URL to the [Tileset API](/rest/api/maps/v2/tileset). The request should look like the following URL (replace `{Azure-Maps-Primary-Subscription-key}` with your primary subscription key), and `{datasetId`} with the `datasetId` obtained in the [Check the dataset creation status](#check-the-dataset-creation-status) section above:

-5. Enter the `status URL` you copied in [Create a tileset](#create-a-tileset). The request should look like the following URL (replace `{Azure-Maps-Primary-Subscription-key}` with your primary subscription key):

-> This tutorial uses the `us.atlas.microsoft.com` geographical URL. If your Creator service wasn't created in the United States, you must use a different geographical URL. For more information, see [Access to Creator Services](how-to-manage-creator.md#access-to-creator-services).

-3. Enter the following URL to [WFS API](/rest/api/maps/v2/wfs). The request should look like the following URL (replace `{Azure-Maps-Primary-Subscription-key}` with your primary subscription key), and `{datasetId`} with the `datasetId` obtained in the [Check the dataset creation status](tutorial-creator-indoor-maps.md#check-the-dataset-creation-status) section of the *Use Creator to create indoor maps* tutorial:

-3. Enter the following URL (replace `{Azure-Maps-Primary-Subscription-key}` with your primary subscription key, and `{datasetId`} with the `datasetId` obtained in [Check dataset creation status](tutorial-creator-indoor-maps.md#check-the-dataset-creation-status)):

- span.addEvent("eventName");

- import io.opentelemetry.api.common.Attributes;

- Attributes attributes = Attributes.of(AttributeKey.stringKey("mycustomdimension"), "myvalue1");

- span.setAllAttributes(attributes);

- span.addEvent("eventName", attributes);

- String traceId = Span.current().getSpanContext().getTraceId();

- String spanId = Span.current().getSpanContext().getSpanId();

-* [Learn more about classic Application Insights resources](../app/create-new-resource.md).

-This section describes legacy methods for collecting the activity log that were used prior to diagnostic settings. If you're using these methods, consider transitioning to diagnostic settings that provide better functionality and consistency with resource logs.

-### Log profiles

-Log profiles are the legacy method for sending the activity log to storage or event hubs. Use the following procedure to continue working with a log profile or to disable it in preparation for migrating to a diagnostic setting.

-1. From the **Azure Monitor** menu in the Azure portal, select **Activity log**.

-1. Select **Export Activity Logs**.

- 

-1. Select the purple banner for the legacy experience.

- 

-### Configure a log profile by using PowerShell

-### Example script

-The following sample PowerShell script is used to create a log profile that writes the activity log to both a storage account and an event hub.

-### Configure a log profile by using the Azure CLI

-### Log Analytics workspace

-The legacy method for sending the activity log into a Log Analytics workspace is connecting the sign-in for the workspace configuration.

-1. From the **Log Analytics workspaces** menu in the Azure portal, select the workspace to collect the activity log.

-1. In the **Workspace Data Sources** section of the workspace's menu, select **Azure Activity log**.

-1. Select the subscription that you want to connect to.

- 

-1. Select **Connect** to connect the activity sign-in subscription to the selected workspace. If the subscription is already connected to another workspace, select **Disconnect** first to disconnect it.

- 

-To disable the setting, do the same procedure and select **Disconnect** to remove the subscription from the workspace.

-See [Regions and Availability Zones in Azure](https://azure.microsoft.com/global-infrastructure/geographies/#geographies) for the Azure regions that have availability zones. Azure Monitor currently supports the following regions.

-> For more information see aliases and configuring aliases later in this section.

-However, you can simplify your Bicep file by [creating an alias](bicep-config-modules.md) for the resource group that contains your template specs. When using an alias, the syntax becomes:

-description: Describes the concept of creating custom role definitions for managed applications.

-|roleName|Yes|The name of the built-in role.|

-description: Describes the concept of creating view definition for Azure Managed Applications.

-In this view you can extend existing Azure resources based on the `targetResourceType`. When a resource is selected, it will create an onboarding request to the **public** custom provider, which can apply a side effect to the resource.

-Learn more about [Azure Custom Providers](../custom-providers/overview.md).

-T-SQL streaming works in exactly the same manner as [Azure Stream Analytics](../stream-analytics/stream-analytics-introduction.md#how-does-stream-analytics-work). For example, it uses the concept of streaming *jobs* for processing of real-time data streaming.

-This article will explain how to run Self-Hosted Integration Runtime in Windows container.

-Azure Data Factory are delivering the official windows container support of Self-Hosted Integration Runtime. You can download the docker build source code and combine the building and running process in your own continuous delivery pipeline.

-1. Install Docker and enable Windows Container

-2. Download the source code from https://github.com/Azure/Azure-Data-Factory-Integration-Runtime-in-Windows-Container

-3. Download the latest version SHIR in ΓÇÿSHIRΓÇÖ folder

-4. Open your folder in the shell:

-```console

-cdΓÇ»"yourFolderPath"

-```

-5. Build the windows docker image:

-```console

-docker build . -t "yourDockerImageName" 

-```

-6. Run docker container:

-```console

-docker run -d -e NODE_NAME="irNodeName" -e AUTH_KEY="IR_AUTHENTICATION_KEY" -e ENABLE_HA=true -e HA_PORT=8060 "yourDockerImageName"   

-```

-> [!NOTE]

-> AUTH_KEY is mandatory for this command. NODE_NAME, ENABLE_HA and HA_PORT are optional. If you don't set the value, the command will use default values. The default value of ENABLE_HA is false and HA_PORT is 8060.

-## Container health check

-After 120 seconds startup period, the health checker will run periodically every 30 seconds. It will provide the IR health status to container engine.

-Currently we don't support below features when running Self-Hosted Integration Runtime in Windows container:

- |-|-|

- |MFA should be enabled on accounts with owner permissions on your subscription|94290b00-4d0c-d7b4-7cea-064a9554e681|

- |MFA should be enabled on accounts with read permissions on your subscription|151e82c5-5341-a74b-1eb0-bc38d2c84bb5|

- |MFA should be enabled on accounts with write permissions on your subscription|57e98606-6b1e-6193-0e3d-fe621387c16b|

- |External accounts with owner permissions should be removed from your subscription|c3b6ae71-f1f0-31b4-e6c1-d5951285d03d|

- |External accounts with read permissions should be removed from your subscription|a8c6a4ad-d51e-88fe-2979-d3ee3c864f8b|

- |External accounts with write permissions should be removed from your subscription|04e7147b-0deb-9796-2e5c-0336343ceb3d|

-#### Recommendations rename

-This update, will rename two recommendations, and revise their descriptions. The assessment keys will remain unchanged.

- | Property | Current value | New update's change |

- |-|-|-|

- |**First recommendation**| - | - |

- |Assessment key | e52064aa-6853-e252-a11e-dffc675689c2 | No change|

- | Name | [Deprecated accounts with owner permissions should be removed from your subscription](https://ms.portal.azure.com/#blade/Microsoft_Azure_Security/RecommendationsBlade/assessmentKey/e52064aa-6853-e252-a11e-dffc675689c2) |Subscriptions should be purged of accounts that are blocked in Active Directory and have owner permissions.|

- |Description| User accounts that have been blocked from signing in, should be removed from your subscriptions.|These accounts can be targets for attackers looking to find ways to access your data without being noticed. <br> Learn more about securing the identity perimeter in [Azure Identity Management and access control security best practices](../security/fundamentals/identity-management-best-practices.md).|

- |Related policy|[Deprecated accounts with owner permissions should be removed from your subscription](https://ms.portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2fproviders%2fMicrosoft.Authorization%2fpolicyDefinitions%2febb62a0c-3560-49e1-89ed-27e074e9f8ad) | Subscriptions should be purged of accounts that are blocked in Active Directory and have owner permissions.|

- |**Second recommendation**| - | - |

- | Assessment key | 00c6d40b-e990-6acf-d4f3-471e747a27c4 | No change |

- | Name | [Deprecated accounts should be removed from your subscription](https://ms.portal.azure.com/#blade/Microsoft_Azure_Security/RecommendationsBlade/assessmentKey/00c6d40b-e990-6acf-d4f3-471e747a27c4)|Subscriptions should be purged of accounts that are blocked in Active Directory and have read and write permissions.|

-|Description|User accounts that have been blocked from signing in, should be removed from your subscriptions. <br> These accounts can be targets for attackers looking to find ways to access your data without being noticed.|User accounts that have been blocked from signing into Active Directory, should be removed from your subscriptions.<br> Learn more about securing the identity perimeter in [Azure Identity Management and access control security best practices](../security/fundamentals/identity-management-best-practices.md).|

- | Related policy | [Deprecated accounts should be removed from your subscription](https://ms.portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2fproviders%2fMicrosoft.Authorization%2fpolicyDefinitions%2f6b1cbf55-e8b6-442f-ba4c-7246b6381474) | Subscriptions should be purged of accounts that are blocked in Active Directory and have read and write permissions. |

-<!-- 1.2 -->

-<!--end 1.2-->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-If your proxy has a firewall that requires you to allow-list all FQDNs for internet connectivity, review the list from [Allow connections from IoT Edge devices](production-checklist.md#allow-connections-from-iot-edge-devices) to determine which FQDNs to add.

-<!-- 1.2 -->

-<!-- end 1.2 -->

-01. Verify your IoT Edge device uses the correct version of the IoT Edge agent when it starts. Find the **Default Edge Agent** section and set the image value for IoT Edge to version 1.2. For example:

- image: "mcr.microsoft.com/azureiotedge-agent:1.2"

- edgeAgent running Up 17 seconds mcr.microsoft.com/azureiotedge-agent:1.2

- edgeHub running Up 6 seconds mcr.microsoft.com/azureiotedge-hub:1.2

-01. Verify your IoT Edge device uses the correct version of the IoT Edge agent when it starts. Find the **Default Edge Agent** section and set the image value for IoT Edge to version 1.2. For example:

- image: "mcr.microsoft.com/azureiotedge-agent:1.2"

- "image": "mcr.microsoft.com/azureiotedge-agent:1.2",

- "image": "mcr.microsoft.com/azureiotedge-hub:1.2",

-image: "{Parent FQDN or IP}:443/azureiotedge-agent:1.2"

-<!--1.2-->

->The following table reflects the supported scenarios for IoT Edge version 1.2. To see content about Windows containers, switch to the [IoT Edge 1.1](?view=iotedge-2018-06&preserve-view=true) version of this article.

-<!--1.2-->

-IoT Edge version 1.2 doesn't support Windows containers. Windows containers won't be supported beyond version 1.1. To learn more about IoT Edge with Windows containers, see the [IoT Edge 1.1](?view=iotedge-2018-06&preserve-view=true) version of this article.

-<!--1.2-->

-<!-- 1.2.0 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!--1.2 -->

-<!-- end 1.2 -->

-This article lists the steps to deploy an Ubuntu 20.04 LTS virtual machine with the Azure IoT Edge runtime installed and configured using a pre-supplied device connection string. The deployment is accomplished using a [cloud-init](../virtual-machines/linux/using-cloud-init.md) based [Azure Resource Manager template](../azure-resource-manager/templates/overview.md) maintained in the [iotedge-vm-deploy](https://github.com/Azure/iotedge-vm-deploy/tree/1.2) project repository.

- [](https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2Fazure%2Fiotedge-vm-deploy%2F1.2%2FedgeDeploy.json)

- --template-uri "https://raw.githubusercontent.com/Azure/iotedge-vm-deploy/1.2/edgeDeploy.json" \

- --template-uri "https://raw.githubusercontent.com/Azure/iotedge-vm-deploy/1.2/edgeDeploy.json" \

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-Provision-EflowVm -provisioningType DpsSymmetricKey -ΓÇïscopeId PASTE_YOUR_ID_SCOPE_HERE -registrationId PASTE_YOUR_REGISTRATION_ID_HERE -symmKey PASTE_YOUR_PRIMARY_KEY_OR_DERIVED_KEY_HERE

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- 1.2 -->

-Use the steps in this section if you want to install a specific version of the Azure IoT Edge runtime that isn't available through `apt-get install`. The Microsoft package list only contains a limited set of recent versions and their sub-versions, so these steps are for anyone who wants to install an older version or a release candidate version.

- curl -L libiothsm-std_link_here -o libiothsm-std.deb && sudo apt-get install ./libiothsm-std.deb

-<!-- 1.2 -->

->If your device is currently running IoT Edge version 1.1 or older, uninstall the **iotedge** and **libiothsm-std** packages before following the steps in this section. For more information, see [Update from 1.0 or 1.1 to 1.2](how-to-update-iot-edge.md#special-case-update-from-10-or-11-to-12).

-<!-- end 1.2 -->

-<!-- 1.2 -->

-sudo apt-get remove --purge aziot-edge

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- 1.2 -->

-Use the steps in this section if you want to install a specific version of the Azure IoT Edge runtime that isn't available through `apt-get install`. The Microsoft package list only contains a limited set of recent versions and their sub-versions, so these steps are for anyone who wants to install an older version or a release candidate version.

-<!-- 1.2 -->

->If your device is currently running IoT Edge version 1.1 or older, uninstall the **iotedge** and **libiothsm-std** packages before following the steps in this section. For more information, see [Update from 1.0 or 1.1 to 1.2](how-to-update-iot-edge.md#special-case-update-from-10-or-11-to-12).

-<!-- end 1.2 -->

-<!-- 1.2 -->

-description: Use IoT Edge MQTT broker to publish and subscribe messages

-keywords:

-monikerRange: ">=iotedge-2020-11"

-# Publish and subscribe with Azure IoT Edge (preview)

-You can use Azure IoT Edge MQTT broker to publish and subscribe to messages. This article shows you how to connect to this broker, publish and subscribe to messages over user-defined topics, and use IoT Hub messaging primitives. The IoT Edge MQTT broker is built in the IoT Edge hub. For more information, see [the brokering capabilities of the IoT Edge hub](iot-edge-runtime.md).

-> [!NOTE]

-> IoT Edge MQTT broker (currently in preview) will not move to general availability and will be removed from the future version of IoT Edge Hub. We appreciate the feedback we received on the preview, and we are continuing to refine our plans for an MQTT broker. In the meantime, if you need a standards-compliant MQTT broker on IoT Edge, consider deploying an open-source broker like [Mosquitto](https://mosquitto.org/) as an IoT Edge module.

-## Prerequisites

- To quickly create an IoT Edge deployment that meets these criteria along with an open authorization policy on the `test_topic`, you can use the [sample deployment manifest](#appendixsample-deployment-manifest) at the end of this article and follow these steps:

- 1. Save the deployment file to your working folder.

- 2. Apply this deployment to your IoT Edge device using the following Azure CLI command:

- ```azurecli

- az iot edge set-modules --device-id <device_id> --hub-name <hub_name> --content <deployment_file_path>

- ```

- For more information about this command, see [Deploy Azure IoT Edge modules with Azure CLI](how-to-deploy-modules-cli.md).

- ```cmd

- sudo apt-get update && sudo apt-get install mosquitto-clients

- ```

- > [!WARNING]

- > Don't install the Mosquitto server since it may block the MQTT ports (8883 and 1883) and conflict with the IoT Edge hub.

-## Connect to IoT Edge hub

-Connecting to IoT Edge hub follows the same steps as described in [Connecting to IoT Hub](../iot-hub/iot-hub-mqtt-support.md#connecting-to-iot-hub) or in [Connecting to the IoT Edge hub](../iot-edge/iot-edge-runtime.md#connecting-to-the-iot-edge-hub). These steps are:

-1. Optionally, the MQTT client establishes a *secure connection* with the IoT Edge hub using Transport Layer Security (TLS).

-2. The MQTT client *authenticates* itself to IoT Edge hub.

-3. The IoT Edge hub *authorizes* the MQTT client per its authorization policy.

-### Secure connection (TLS)

-TLS is used to establish encrypted communication between the client and the IoT Edge hub.

-### Authentication

-To authenticate itself, the MQTT client first needs to send a CONNECT packet to the MQTT broker to start a connection in its name. This packet provides three pieces of authentication information: a `client identifier`, a `username`, and a `password`:

- - For a device: `<device_name>`

- - For a module: `<device_name>/<module_name>`

- To connect to the MQTT broker, a device or a module must be registered in IoT Hub.

- The broker won't allow connections from multiple clients using the same credentials. The broker will disconnect the client that's already connected if a second client connects using the same credentials.

- - For a device: `<iot_hub_name>.azure-devices.net/<device_name>/?api-version=2018-06-30`

- - For a module: `<iot_hub_name>.azure-devices.net/<device_name>/<module_name>/?api-version=2018-06-30`

- - When using [symmetric keys authentication](how-to-authenticate-downstream-device.md#symmetric-key-authentication), the `password` field is a SAS token.

- - When using [X.509 self-signed authentication](how-to-authenticate-downstream-device.md#x509-self-signed-authentication), the `password` field isn't present. In this authentication mode, a TLS channel is required. The client needs to connect to port 8883 to establish a TLS connection. During the TLS handshake, the MQTT broker requests a client certificate. This certificate is used to verify the identity of the client and so the `password` field isn't needed later when the CONNECT packet is sent. Sending both a client certificate and the password field will lead to an error and the connection will be closed. MQTT libraries and TLS client libraries usually have a way to send a client certificate when starting a connection. You can see a step-by-step example in the [X.509 self-signed authentication](how-to-authenticate-downstream-device.md#x509-self-signed-authentication) section of *How-to: Authenticate a downstream device to Azure IoT Hub*.

-Modules deployed by IoT Edge use [symmetric keys authentication](how-to-authenticate-downstream-device.md#symmetric-key-authentication) and can call the local [IoT Edge workload API](https://github.com/Azure/iotedge/blob/40f10950dc65dd955e20f51f35d69dd4882e1618/edgelet/workload/README.md) to programmatically get a SAS token even when offline.

-### Authorization

-Once an MQTT client is authenticated to an IoT Edge hub, it needs to be authorized to connect. Once connected, it needs to be authorized to publish or subscribe to specific topics. These authorizations are granted by the IoT Edge hub based on its authorization policy. The authorization policy is a set of statements expressed as a JSON structure that is sent to the IoT Edge hub via its twin. Edit an IoT Edge hub twin to configure its authorization policy.

-> [!NOTE]

-> For the public preview, only the Azure CLI supports deployments containing MQTT broker authorization policies. The Azure portal currently doesn't support editing the IoT Edge hub twin and its authorization policy.

-Each authorization policy statement consists of the combination of `identities`, `allow` or `deny` effects, `operations`, and `resources`:

-The following JSON snippet is an example of an authorization policy that explicitly doesn't allow the client "rogue_client" to connect, allows any Azure IoT clients to connect, and allows "sensor_1" to publish to topic `events/alerts`:

-```json

-{

- "$edgeHub":{

- "properties.desired":{

- "schemaVersion":"1.2",

- "routes":{

- "Route1":"FROM /messages/* INTO $upstream"

- },

- "storeAndForwardConfiguration":{

- "timeToLiveSecs":7200

- },

- "mqttBroker":{

- "authorizations":[

- {

- "identities":[

- "<iot_hub_name>.azure-devices.net/rogue_client"

- ],

- "deny":[

- {

- "operations":[

- "mqtt:connect"

- ]

- }

- ]

- },

- {

- "identities":[

- "{{iot:identity}}"

- ],

- "allow":[

- {

- "operations":[

- "mqtt:connect"

- ]

- }

- ]

- },

- {

- "identities":[

- "<iot_hub_name>.azure-devices.net/sensor_1"

- ],

- "allow":[

- {

- "operations":[

- "mqtt:publish"

- ],

- "resources":[

- "events/alerts"

- ]

- }

- ]

- }

- ]

- }

- }

- }

-}

-```

-When writing your authorization policy, keep in mind:

- > [!IMPORTANT]

- > Once your IoT Edge device is deployed, it currently won't display correctly in the Azure portal with schema version 1.2 (version 1.1 will be fine). This is a known bug and will be fixed soon. However, this won't affect your device, as it's still connected in IoT Hub and can be communicated with at any time using the Azure CLI.

- :::image type="content" source="./media/how-to-publish-subscribe/unsupported-1.2-schema.png" alt-text="Screenshot of Azure portal error on the IoT Edge device page.":::

- - `{{iot:identity}}` represents the identity of the currently connected client. For example, a device identity like `<iot_hub_name>.azure-devices.net/myDevice` or a module identity like `<iot_hub_name>.azure-devices.net/myEdgeDevice/SampleModule`.

- - `{{iot:device_id}}` represents the identity of the currently connected device. For example, a device identity like `myDevice` or the device identity where a module is running like `myEdgeDevice`.

- - `{{iot:module_id}}` represents the identity of the currently connected module. This variable is blank for connected devices, or a module identity like `SampleModule`.

- - `{{iot:this_device_id}}` represents the identity of the IoT Edge device running the authorization policy. For example, `myIoTEdgeDevice`.

-Authorizations for IoT hub topics are handled slightly differently than user-defined topics. Here are the key points to keep in mind:

-The following JSON snippet is an example of a default authorization policy that can be used to enable all Azure IoT devices or modules to **connect** to the broker:

-```json

-{

- "$edgeHub":{

- "properties.desired":{

- "schemaVersion":"1.2",

- "mqttBroker":{

- "authorizations":[

- {

- "identities": [

- "{{iot:identity}}"

- ],

- "allow":[

- {

- "operations":[

- "mqtt:connect"

- ]

- }

- ]

- }

- ]

- }

- }

- }

-}

-```

-Now that you understand how to connect to the IoT Edge MQTT broker, let's see how it can be used to publish and subscribe to messages first on user-defined topics, then on IoT Hub topics, and finally to another MQTT broker.

-## Publish and subscribe on user-defined topics

-In this section, you'll use one client named **sub_client** that subscribes to a topic and another client named **pub_client** that publishes to a topic. We'll use [symmetric key authentication](how-to-authenticate-downstream-device.md#symmetric-key-authentication), but the same can be done with [X.509 self-signed authentication](how-to-authenticate-downstream-device.md#x509-self-signed-authentication) or [X.509 CA-signed authentication](./how-to-authenticate-downstream-device.md#x509-ca-signed-authentication).

-### Create publisher and subscriber clients

-Open a terminal and use the Azure CLI commands described in this section to create two IoT devices in IoT Hub and get their passwords.

-1. Run the following commands to create two IoT devices in IoT Hub:

- ```azurecli-interactive

- az iot hub device-identity create --device-id sub_client --hub-name <iot_hub_name>

- az iot hub device-identity create --device-id pub_client --hub-name <iot_hub_name>

- ```

-2. Run the following commands to set the IoT devices' parent to be your IoT Edge device:

- ```azurecli-interactive

- az iot hub device-identity parent set --device-id sub_client --hub-name <iot_hub_name> --pd <edge_device_id>

- az iot hub device-identity parent set --device-id pub_client --hub-name <iot_hub_name> --pd <edge_device_id>

- ```

-3. Run the following command for each IoT device or module to get their passwords by generating a SAS token:

- - For a device:

- ```azurecli-interactive

- az iot hub generate-sas-token -n <iot_hub_name> -d <device_name> --key-type primary --du 3600

- ```

- - For a module:

- ```azurecli-interactive

- az iot hub generate-sas-token -n <iot_hub_name> -d <device_name> -m <module_name> --key-type primary --du 3600

- ```

- > [!NOTE]

- > The value 3600 assigned to the `du` parameter in these commands corresponds to the duration of the SAS token in seconds. Assigning 3600 to the parameter would result in the token lasting 1 hour.

-4. Copy the SAS token, which is the value corresponding to the `sas` key from the output. Here's an example output from the Azure CLI command that you ran in step 3:

- ```json

- {

- "sas": "SharedAccessSignature sr=example.azure-devices.net%2Fdevices%2Fdevice_1%2Fmodules%2Fmodule_a&sig=H5iMq8ZPJBkH3aBWCs0khoTPdFytHXk8VAxrthqIQS0%3D&se=1596249190"

- }

- ```

-### Authorize publisher and subscriber clients

-To authorize the publisher and subscriber, edit the IoT Edge hub twin in an IoT Edge deployment that includes the following authorization policy:

-```json

-{

- "$edgeHub":{

- "properties.desired":{

- "schemaVersion":"1.2",

- "mqttBroker":{

- "authorizations":[

- {

- "identities": [

- "{{iot:identity}}"

- ],

- "allow":[

- {

- "operations":[

- "mqtt:connect"

- ]

- }

- ]

- },

- {

- "identities": [

- "<iot_hub_name>.azure-devices.net/sub_client"

- ],

- "allow":[

- {

- "operations":[

- "mqtt:subscribe"

- ],

- "resources":[

- "test_topic"

- ]

- }

- ],

- },

- {

- "identities": [

- "<iot_hub_name>.azure-devices.net/pub_client"

- ],

- "allow":[

- {

- "operations":[

- "mqtt:publish"

- ],

- "resources":[

- "test_topic"

- ]

- }

- ]

- }

- ]

- }

- }

- }

-}

-```

-> [!NOTE]

-> Currently, deployments that contain the MQTT authorization properties can only be applied to IoT Edge devices using the Azure CLI.

-### Symmetric keys authentication without TLS

-#### Subscribe

-Connect your **sub_client** MQTT client to the MQTT broker and subscribe to the `test_topic` by running the following command on your IoT Edge device:

-```bash

-mosquitto_sub \

- -t "test_topic" \

- -i "sub_client" \

- -u "<iot_hub_name>.azure-devices.net/sub_client/?api-version=2018-06-30" \

- -P "<sas_token>" \

- -h "<edge_device_address>" \

- -V mqttv311 \

- -p 1883

-```

-In this code snippet, `<edge_device_address>` would be `localhost` since the client is running on the same device as IoT Edge.

-> [!NOTE]

-> TLS isn't enabled in this first example, so port 1883 (MQTT) is used. For this example to work, edgeHub port 1883 needs to be bound to the host via its create options. An example is given in the [prerequisite section](#prerequisites). Another example with TLS enabled using port 8883 (MQTTS) is shown in the [Symmetric keys authentication with TLS section](#symmetric-keys-authentication-with-tls) further down in this article.

-The **sub_client** MQTT client is now started and is waiting for incoming messages on `test_topic`.

-#### Publish

-Connect your **pub_client** MQTT client to the MQTT broker and publish a message on the same `test_topic` as above by running the following command on your IoT Edge device from another terminal:

-```bash

-mosquitto_pub \

- -t "test_topic" \

- -i "pub_client" \

- -u "<iot_hub_name>.azure-devices.net/pub_client/?api-version=2018-06-30" \

- -P "<sas_token>" \

- -h "<edge_device_address>" \

- -V mqttv311 \

- -p 1883 \

- -m "hello"

-```

-In this code snippet, `<edge_device_address>` would be `localhost` since the client is running on the same device as IoT Edge.

-Executing the command, the **sub_client** MQTT client receives the "hello" message.

-### Symmetric keys authentication with TLS

-To enable TLS, the port must be changed from 1883 (MQTT) to 8883 (MQTTS) and clients must have the root certificate of the MQTT broker to be able to validate the certificate chain sent by the MQTT broker. You can do so by following the steps provided in the [Secure connection (TLS) section](#secure-connection-tls).

-Because the clients are running on the same device as the MQTT broker in the example above, the same steps apply to enable TLS by:

-## Publish and subscribe on IoT Hub topics

-The [Azure IoT Device SDKs](https://github.com/Azure/azure-iot-sdks) already let clients perform IoT Hub operations, but they don't allow publishing or subscribing to user-defined topics. IoT Hub operations can be performed using any MQTT clients using publish and subscribe semantics as long as IoT Hub primitive protocols are respected. The next sections of this guide go through the specifics to illustrate how these protocols work.

-### Send messages

-Sending telemetry data to IoT Hub, other devices, or other modules is similar to publishing on a user-defined topic, but using a specific IoT Hub topic:

-Additionally, route the message to its destination.

-As with all IoT Edge messages, you can create a route such as `FROM /messages/* INTO $upstream` to send telemetry from the IoT Edge MQTT broker to the IoT hub. For more information about routing, see [Declare routes](module-composition.md#declare-routes).

-Depending on the routing settings, the routing may define an input name, which will be attached to the topic when a message is getting forwarded. Also, Edge Hub (and the original sender) adds parameters to the message which is encoded in the topic structure. The following example shows a message routed with input name "TestInput". This message was sent by a module called "SenderModule", which name is also encoded in the topic:

-`devices/TestEdgeDevice/modules/TestModule/inputs/TestInput/%24.cdid=TestEdgeDevice&%24.cmid=SenderModule`

-Modules can also send messages on a specific output name. Output names help when messages from a module need to be routed to different destinations. When a module wants to send a message on a specific output, it sends the message as a regular telemetry message, except that it adds an additional system property to it. This system property is '$.on'. The '$' sign needs to be url encoded and it becomes %24 in the topic name. The following example shows a telemetry message sent with the output name 'alert':

-`devices/TestEdgeDevice/modules/TestModule/messages/events/%24.on=alert/`

-### Receive messages

-A telemetry message sent by a device or module can be routed to another module. If a module wants to receive M2M messages, first it needs to subscribe to the topic which delivers them. The format of the subscription is:

-`devices/{device_id}/modules/{module_id}/#`

-### Get twin

-Getting the device or module twin isn't a typical MQTT pattern. The client needs to issue a request for the twin that IoT Hub is going to serve.

-To receive twins, the client needs to subscribe to the following topic specific to IoT Hub: `$iothub/twin/res/#`. This topic name is inherited from IoT Hub, and all clients need to subscribe to the same topic. It doesn't mean that devices or modules receive the twin of each other. IoT Hub and IoT Edge hub know which twin should be delivered where, even if all devices listen to the same topic name.

-Once the subscription is made, the client needs to ask for the twin by publishing a message to the following topic specific to IoT Hub: `$iothub/twin/GET/?$rid=<request_id>/#`. The `<request_id>` in this code snippet is an arbitrary identifier. IoT Hub will then send its response with the requested data on the `$iothub/twin/res/200/?$rid=<request_id>` topic, which the client subscribes to. This process is how a client can pair its requests with the responses.

-### Receive twin patches

-To receive twin patches, a client needs to subscribe to the following special IoT Hub topic: `$iothub/twin/PATCH/properties/desired/#`. Once the subscription is made, the client receives the twin patches sent by IoT Hub on this topic.

-### Receive direct methods

-Receiving a direct method is similar to receiving full twins with the addition that the client needs to confirm back that it has received the call. First the client subscribes to the following special IoT Hub topic: `$iothub/methods/POST/#`. Once a direct method is received on this topic, the client needs to extract the request identifier `$rid` from the subtopic on which the direct method is received, and finally publish a confirmation message on the following special IoT Hub topic: `$iothub/methods/res/200/<request_id>`.

-### Send direct methods

-Sending a direct method is an HTTP call and so doesn't go through the MQTT broker. For more information on sending a direct method to IoT Hub, see [Understand and invoke direct methods](../iot-hub/iot-hub-devguide-direct-methods.md). For more information on sending a direct method locally to another module, see this [Azure IoT C# SDK direct method invocation example](https://github.com/Azure/azure-iot-sdk-csharp/blob/main/iothub/device/src/ModuleClient.cs#L597).

-## Publish and subscribe between MQTT brokers

-To connect two MQTT brokers, the IoT Edge hub includes an MQTT bridge. An MQTT bridge is commonly used to connect a running MQTT broker to another MQTT broker. Only a subset of the local traffic is typically pushed to another broker.

-> [!NOTE]

-> The IoT Edge hub bridge can currently only be used between nested IoT Edge devices. It can't be used to send data to IoT Hub since IoT Hub isn't a full-featured MQTT broker. To learn more about IoT Hub MQTT broker features support, see [Communicate with your IoT hub using the MQTT protocol](../iot-hub/iot-hub-mqtt-support.md). To learn more about nesting IoT Edge devices, see [Connect a downstream IoT Edge device to an Azure IoT Edge gateway](how-to-connect-downstream-iot-edge-device.md).

-In a nested configuration, the IoT Edge hub MQTT bridge acts as a client of the parent MQTT broker, so authorization rules must be set on the parent EdgeHub to allow the child EdgeHub to publish and subscribe to specific user-defined topics that the bridge is configured for.

-The IoT Edge MQTT bridge is configured via a JSON structure that's sent to the IoT Edge hub via its twin. Edit an IoT Edge hub twin to configure its MQTT bridge.

-> [!NOTE]

-> For the public preview, only the Azure CLI supports deployments containing MQTT bridge configurations. The Azure portal currently doesn't support editing the IoT Edge hub twin and its MQTT bridge configuration.

-The MQTT bridge can be configured to connect an IoT Edge hub MQTT broker to multiple external brokers. For each external broker, the following settings are required:

- - `direction` is either `in` to subscribe to the remote broker's topics or `out` to publish to the remote broker's topics.

- - `topic` is the core topic pattern to be matched. [MQTT wildcards](https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718107) can be used to define this pattern. Different prefixes can be applied to this topic pattern on the local broker and remote broker.

- - `outPrefix` is the prefix that's applied to the `topic` pattern on the remote broker.

- - `inPrefix` is the prefix that's applied to the `topic` pattern on the local broker.

-The following JSON snippet is an example of an IoT Edge MQTT bridge configuration that republishes all messages received on topics `alerts/#` of a parent IoT Edge device to a child IoT Edge device on the same topics, and republishes all messages sent on topics `/local/telemetry/#` of a child IoT Edge device to a parent IoT Edge device on topics `/remote/messages/#`:

-```json

-{

- "schemaVersion": "1.2",

- "mqttBroker": {

- "bridges": [{

- "endpoint": "$upstream",

- "settings": [{

- "direction": "in",

- "topic": "alerts/#"

- },

- {

- "direction": "out",

- "topic": "#",

- "inPrefix": "/local/telemetry/",

- "outPrefix": "/remote/messages/"

- }

- ]

- }]

- }

-}

-```

-> [!NOTE]

-> The MQTT protocol will automatically be used as upstream protocol when the MQTT broker is used and IoT Edge is in a nested configuration, for example, with a `parent_hostname` specified. To learn more about upstream protocols, see [Cloud communication](iot-edge-runtime.md#cloud-communication). To learn more about nested configurations, see [Connect a downstream IoT Edge device to an Azure IoT Edge gateway](how-to-connect-downstream-iot-edge-device.md).

-## Next steps

-To learn more about IoT Edge hub, see [Understand the IoT Edge hub](iot-edge-runtime.md#iot-edge-hub).

-## Appendix - Sample deployment manifest

-Below is the complete deployment manifest that you can use to enable the MQTT Broker in IoT Edge. It deploys IoT Edge version 1.2 with the MQTT broker feature enabled, edgeHub port 1883 enabled, and an open authorization policy on the `test_topic`.

-```json

-{

- "modulesContent":{

- "$edgeAgent":{

- "properties.desired":{

- "schemaVersion":"1.1",

- "runtime":{

- "type":"docker",

- "settings":{

- "minDockerVersion":"v1.25",

- "loggingOptions":"",

- "registryCredentials":{

-

- }

- }

- },

- "systemModules":{

- "edgeAgent":{

- "type":"docker",

- "settings":{

- "image":"mcr.microsoft.com/azureiotedge-agent:1.2",

- "createOptions":"{}"

- }

- },

- "edgeHub":{

- "type":"docker",

- "status":"running",

- "restartPolicy":"always",

- "settings":{

- "image":"mcr.microsoft.com/azureiotedge-hub:1.2",

- "createOptions":"{\"HostConfig\":{\"PortBindings\":{\"5671/tcp\":[{\"HostPort\":\"5671\"}],\"8883/tcp\":[{\"HostPort\":\"8883\"}],\"443/tcp\":[{\"HostPort\":\"443\"}],\"1883/tcp\":[{\"HostPort\":\"1883\"}]}}}"

- },

- "env":{

- "experimentalFeatures__mqttBrokerEnabled":{

- "value":"true"

- },

- "experimentalFeatures__enabled":{

- "value":"true"

- },

- "RuntimeLogLevel":{

- "value":"debug"

- }

- }

- }

- },

- "modules":{

-

- }

- }

- },

- "$edgeHub":{

- "properties.desired":{

- "schemaVersion":"1.2",

- "routes":{

- "Upstream":"FROM /messages/* INTO $upstream"

- },

- "storeAndForwardConfiguration":{

- "timeToLiveSecs":7200

- },

- "mqttBroker":{

- "authorizations":[

- {

- "identities":[

- "{{iot:identity}}"

- ],

- "allow":[

- {

- "operations":[

- "mqtt:connect"

- ]

- }

- ]

- },

- {

- "identities":[

- "{{iot:identity}}"

- ],

- "allow":[

- {

- "operations":[

- "mqtt:publish",

- "mqtt:subscribe"

- ],

- "resources":[

- "test_topic"

- ]

- }

- ]

- }

- ]

- }

- }

- }

- }

-}

-```

-<!-- 1.2.0 -->

-<!-- 1.2.0 -->

-# [Linux](#tab/linux)

->If you are updating a device from version 1.0 or 1.1 to version 1.2, there are differences in the installation and configuration processes that require extra steps. For more information, refer to the steps later in this article: [Special case: Update from 1.0 or 1.1 to 1.2](#special-case-update-from-10-or-11-to-12).

-<!-- 1.2 -->

- ```bash

- apt list -a aziot-edge

- ```

- ```bash

- sudo apt-get install aziot-edge defender-iot-micro-agent-edge

- ```

-It's recommended to install the micro agent with the Edge agent to enable security monitoring and hardening of your Edge devices. To learn more about Microsoft Defender for IoT, see [What is Microsoft Defender for IoT for device builders](../defender-for-iot/device-builders/overview.md).

-<!-- end 1.2 -->

-<!-- 1.2 -->

->Currently, there's no support for IoT Edge version 1.2 running on Windows devices.

-<!-- end 1.2 -->

-## Special case: Update from 1.0 or 1.1 to 1.2

->[!NOTE]

->If you're using Windows containers or IoT Edge for Linux on Windows, this special case section does not apply.

-Starting with version 1.2, the IoT Edge service uses a new package name and has some differences in the installation and configuration processes. If you have an IoT Edge device running version 1.0 or 1.1, use these instructions to learn how to update to 1.2.

->[!NOTE]

->Currently, there is no support for IoT Edge version 1.2 running on Windows devices.

-Some of the key differences between 1.2 and earlier versions include:

-* The workload API in version 1.2 saves encrypted secrets in a new format. If you upgrade from an older version to version 1.2, the existing master encryption key is imported. The workload API can read secrets saved in the prior format using the imported encryption key. However, the workload API can't write encrypted secrets in the old format. Once a secret is re-encrypted by a module, it is saved in the new format. Secrets encrypted in version 1.2 are unreadable by the same module in version 1.1. If you persist encrypted data to a host-mounted folder or volume, always create a backup copy of the data *before* upgrading to retain the ability to downgrade if necessary.

-## Special case: Update to a release candidate version

->[!NOTE]

->If you're using Windows containers or IoT Edge for Linux on Windows, this special case section does not apply.

-Azure IoT Edge regularly releases new versions of the IoT Edge service. Before each stable release, there is one or more release candidate (RC) versions. RC versions include all the planned features for the release, but are still going through testing and validation. If you want to test a new feature early, you can install an RC version and provide feedback through GitHub.

-Release candidate versions follow the same numbering convention of releases, but have **-rc** plus an incremental number appended to the end. You can see the release candidates in the same list of [Azure IoT Edge releases](https://github.com/Azure/azure-iotedge/releases) as the stable versions. For example, find **1.2.0-rc4**, one of the release candidates released before **1.2.0**. You can also see that RC versions are marked with **pre-release** labels.

-The IoT Edge agent and hub modules have RC versions that are tagged with the same convention. For example, **mcr.microsoft.com/azureiotedge-hub:1.2.0-rc4**.

-As previews, release candidate versions aren't included as the latest version that the regular installers target. Instead, you need to manually target the assets for the RC version that you want to test. For the most part, installing or updating to an RC version is the same as targeting any other specific version of IoT Edge.

-Use the sections in this article to learn how to update an IoT Edge device to a specific version of the security subsystem or runtime modules.

-If you're installing IoT Edge, rather than upgrading an existing installation, use the steps in [Offline or specific version installation](how-to-provision-single-device-linux-symmetric.md#offline-or-specific-version-installation-optional).

-<!-- 1.2 -->

-<!-- 1.2.0 -->

-<!-- 1.2.0 -->

-<!-- 1.2.0 -->

-<!-- 1.2.0 -->

-The identity translation gateway pattern builds on protocol translation, but the IoT Edge gateway also provides an IoT Hub device identity on behalf of the downstream devices. The translation module is responsible for understanding the protocol used by the downstream devices, providing them identity, and translate their messages into IoT Hub primitives. Downstream devices appear in IoT Hub as first-class devices with twins and methods. A user can interact with the devices in IoT Hub and is unaware of the intermediate gateway device.

-The IoT Edge runtime does not include protocol or identity translation capabilities. These patterns requires custom or third-party modules that are often specific to the hardware and protocol used. [Azure Marketplace](https://azuremarketplace.microsoft.com/marketplace/apps/category/internet-of-things?page=1&subcategories=iot-edge-modules) contains several protocol translation modules to choose from. For a sample that uses the identity translation pattern, see [Azure IoT Edge LoRaWAN Starter Kit](https://github.com/Azure/iotedge-lorawan-starterkit).

-<!--1.2-->

-## Changes in version 1.2

-<!--1.2-->

-<!--1.2-->

-<!--1.2-->

-<!--1.2-->

-<!--1.2-->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-With IoT Edge for Linux on Windows, IoT Edge runs in a Linux virtual machine hosted on a Windows device. This virtual machine is pre-installed with IoT Edge, and has no package manager, so you canΓÇÖt manually update or change any of the VM components. Instead, the virtual machine is managed with Microsoft Update to keep the components up to date automatically.

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-When using Node.js to send device to cloud messages with the AMQP protocol to an IoT Edge runtime, messages stop sending after 2047 messages. No error is thrown and the messages eventually start sending again, then cycle repeats. If the client connects directly to Azure IoT Hub, there's no issue with sending messages. This issue has been fixed in IoT Edge 1.2.

-<!-- 1.2.0 -->

-The responsibilities of the IoT Edge runtime fall into two categories: communication and module management. These two roles are performed by two components that are part of the IoT Edge runtime. The *IoT Edge agent* deploys and monitors the modules, while the *IoT Edge hub* is responsible for communication.

-The IoT Edge agent is one of two modules that make up the Azure IoT Edge runtime. It is responsible for instantiating modules, ensuring that they continue to run, and reporting the status of the modules back to IoT Hub. This configuration data is written as a property of the IoT Edge agent module twin.

-The IoT Edge agent sends runtime response to IoT Hub. Here is a list of possible responses:

-To reduce the bandwidth that your IoT Edge solution uses, the IoT Edge hub optimizes how many actual connections are made to the cloud. IoT Edge hub takes logical connections from modules or downstream devices and combines them for a single physical connection to the cloud. The details of this process are transparent to the rest of the solution. Clients think they have their own connection to the cloud even though they are all being sent over the same connection. The IoT Edge hub can either use the AMQP or the MQTT protocol to communicate upstream with the cloud, independently from protocols used by downstream devices. However, the IoT Edge hub currently only supports combining logical connections into a single physical connection by using AMQP as the upstream protocol and its multiplexing capabilities. AMQP is the default upstream protocol.

-IoT Edge hub can determine whether it's connected to IoT Hub. If the connection is lost, IoT Edge hub saves messages or twin updates locally. Once a connection is reestablished, it syncs all the data. The location used for this temporary cache is determined by a property of the IoT Edge hub's module twin. The size of the cache is not capped and will grow as long as the device has storage capacity. For more information, see [Offline capabilities](offline-capabilities.md).

-<!-- <1.2> -->

-IoT Edge hub facilitates local communication. It enables device-to-module, module-to-module, device-to-device communications by brokering messages to keep devices and modules independent from each other.

->[!NOTE]

-> The MQTT broker feature is in public preview with IoT Edge version 1.2. It must be explicitly enabled.

-The IoT Edge hub supports two brokering mechanisms:

-1. The [message routing features supported by IoT Hub](../iot-hub/iot-hub-devguide-messages-d2c.md) and,

-2. A general-purpose MQTT broker that meets the [MQTT standard v3.1.1](https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html)

-The first brokering mechanism leverages the same routing features as IoT Hub to specify how messages are passed between devices or modules. First devices or modules specify the inputs on which they accept messages and the outputs to which they write messages. Then a solution developer can route messages between a source, e.g. outputs, and a destination, e.g. inputs, with potential filters.

-Routing can be used by devices or modules built with the Azure IoT Device SDKs either via the AMQP or the MQTT protocol. All messaging IoT Hub primitives, e.g. telemetry, direct methods, C2D, twins, are supported but communication over user-defined topics is not supported.

-For more information about routes, see [Learn how to deploy modules and establish routes in IoT Edge](module-composition.md)

-#### Using the MQTT broker

-The second brokering mechanism is based on a standard MQTT broker. MQTT is a lightweight message transfer protocol that guarantees optimal performances on resource constrained devices and is a popular publish and subscribe standard. Devices or modules subscribe to topics to receive messages published by other devices or modules. IoT Edge hub implements its own MQTT broker that follows [the specifications of MQTT version 3.1.1](https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html).

-The MQTT broker enables two additional communication patterns compared to routing: local broadcasting and point-to-point communication. Local broadcasting is useful when one device or module needs to locally alert multiple other devices or modules. Point-to-point communication enables two IoT Edge devices or two IoT devices to communicate locally without round-trip to the cloud.

-

-The MQTT broker can be used by devices or modules built with either the Azure IoT Device SDKs that communicate via the MQTT protocol or any general-purpose MQTT clients. With the exception of C2D all messaging IoT Hub primitives, e.g. telemetry, direct methods, twins are supported. IoT Hub special topics used by IoT Hub primitives are supported and so are user-defined topics.

-This topic could be an IoT Hub special topic or a user-defined topic.

-Unlike with the routing mechanism, ordering of messages is only best-effort and not guaranteed and filtering of messages is not supported by the broker. The lack of these features however enable the MQTT broker to be faster than routing.

-For more information about the MQTT broker, see [Publish and subscribe with IoT Edge](how-to-publish-subscribe.md)

-#### Comparison between brokering mechanisms

-Here are the features available with each brokering mechanism:

-|Features | Routing | MQTT broker |

-||||

-|D2C telemetry | &#10004; | |

-|Local telemetry | &#10004; | &#10004; |

-|DirectMethods | &#10004; | &#10004; |

-|Twin | &#10004; | &#10004; |

-|C2D for devices | &#10004; | |

-|Ordering | &#10004; | |

-|Filtering | &#10004; | |

-|User-defined topics | | &#10004; |

-|Device-to-Device | | &#10004; |

-|Local broadcasting | | &#10004; |

-|Performance | | &#10004; |

-By default, the IoT Edge hub only accepts connections secured with Transport Layer Security (TLS), e.g. encrypted connections that a third party cannot decrypt.

-If a client connects on port 8883 (MQTTS) or 5671 (AMQPS) to the IoT Edge hub, a TLS channel must be built. During the TLS handshake, the IoT Edge hub sends its certificate chain that the client needs to validate. In order to validate the certificate chain, the root certificate of the IoT Edge hub must be installed as a trusted certificate on the client. If the root certificate is not trusted, the client library will be rejected by the IoT Edge hub with a certificate verification error.

-The steps to follow to install this root certificate of the broker on device clients are described in the [transparent gateway](how-to-create-transparent-gateway.md) and in the [prepare a downstream device](how-to-connect-downstream-device.md#prepare-a-downstream-device) documentation. Modules can use the same root certificate as the IoT Edge hub by leveraging the IoT Edge daemon API.

-The IoT Edge Hub only accepts connections from devices or modules that have an IoT Hub identity, e.g. that have been registered in IoT Hub and have one of the three client authentication methods supported by IoT hub to provide prove their identity: [Symmetric keys authentication](how-to-authenticate-downstream-device.md#symmetric-key-authentication), [X.509 self-signed authentication](how-to-authenticate-downstream-device.md#x509-self-signed-authentication), [X.509 CA signed authentication](how-to-authenticate-downstream-device.md#x509-ca-signed-authentication). These IoT Hub identities can be verified locally by the IoT Edge hub so connections can still be made while offline.

-Notes:

-* IoT Edge modules currently only support symmetric key authentication.

-* MQTT clients with only local username and passwords are not accepted by the IoT Edge hub MQTT broker, they must use IoT Hub identities.

-Once authenticated, the IoT Edge hub has two ways to authorize client connections:

-* By verifying that a client belongs to its set of trusted clients defined in IoT Hub. The set of trusted clients is specified by setting up parent/child or device/module relationships in IoT Hub. When a module is created in IoT Edge, a trust relationship is automatically established between this module and its IoT Edge device. This is the only authorization model supported by the routing brokering mechanism.

-* By setting up an authorization policy. This authorization policy is a document listing all the authorized client identities that can access resources on the IoT Edge hub. This is the primary authorization model used by the IoT Edge hub MQTT broker, though parent/child and device/module relationships can also be understood by the MQTT broker for IoT Hub topics.

-The IoT Edge hub is entirely controlled by the cloud. It gets its configuration from IoT Hub via its [module twin](iot-edge-modules.md#module-twins). It includes:

-* Routes configuration

-* Authorization policies

-* MQTT bridge configuration

-Additionally, several configuration can be done by setting up [environment variables on the IoT Edge hub](https://github.com/Azure/iotedge/blob/master/doc/EnvironmentVariables.md).

-<!-- </1.2> -->

-IoT Edge collects anonymous telemetry from the host runtime and system modules to improve product quality. This information is called runtime quality telemetry. The collected telemetry is periodically sent as device-to-cloud messages to IoT Hub from the IoT Edge agent. These messages do not appear in customer's regular telemetry and do not consume any message quota.

-<!-- 1.2 -->

-<!--1.2-->

-<!--1.2-->

-<!--1.2-->

-## Changes in version 1.2

-<!--1.2-->

-The IoT Edge module runtime delegates trust from the [Azure IoT Identity Service](https://azure.github.io/iot-identity-service/) security subsystem to protect the IoT Edge container runtime environment. The module runtime is responsible for the logical security operations of the security manager. It represents a significant portion of the trusted computing base of the IoT Edge device. The module runtime uses security services from the IoT Identity Service, which is in turn hardened by the device manufacturer's choice of hardware security module (HSM). We strongly recommend the use of HSMs for device hardening.

-<!--1.2-->

-<!--1.2-->

-<!--1.2-->

-<!--1.2-->

-<!--1.2-->

-<!--1.2-->

-<!--1.2-->

-<!--1.2-->

-<!--1.2-->

-Modules can also use any MQTT client to connect to the local IoT Edge hub MQTT broker.

-To use IoT Edge routing over AMQP or MQTT, you can use the ModuleClient from the Azure IoT SDK. Create a ModuleClient instance to connect your module to the IoT Edge hub running on the device, similar to how DeviceClient instances connect IoT devices to IoT Hub. For more information about the ModuleClient class and its communication methods, see the API reference for your preferred SDK language: [C#](/dotnet/api/microsoft.azure.devices.client.moduleclient), [C](/azure/iot-hub/iot-c-sdk-ref/iothub-module-client-h), [Python](/python/api/azure-iot-device/azure.iot.device.iothubmoduleclient), [Java](/java/api/com.microsoft.azure.sdk.iot.device.moduleclient), or [Node.js](/javascript/api/azure-iot-device/moduleclient).

-<!-- <1.2> -->

-To use IoT Edge MQTT broker, you need to bring your own MQTT client and initiate the connection yourself with information that you retrieve from the IoT Edge daemon workload API. <!--Need to add details here-->

-For more information about choosing between routing or publishing/subscribing with the MQTT broker, see [Local communication](iot-edge-runtime.md#local-communication).

-### MQTT broker primitives

-#### Send a message on a user-defined topic

-With the IoT Edge MQTT broker, you can publish messages on any user-defined topics. To do so, authorize your module to publish on specific topics then get a token from the workload API to use as a password when connecting to the MQTT broker, and finally publish messages on the authorized topics with the MQTT client of your choice.

-#### Receive messages on a user-defined topic

-With the IoT Edge MQTT broker, receiving messages is similar. First make sure that your module is authorized to subscribe to specific topics, then get a token from the workload API to use as a password when connecting to the MQTT broker, and finally subscribe to messages on the authorized topics with the MQTT client of your choice.

-> [!NOTE]

-> IoT Edge MQTT broker (currently in preview) will not move to general availability and will be removed from the future version of IoT Edge Hub. We appreciate the feedback we received on the preview, and we are continuing to refine our plans for an MQTT broker. In the meantime, if you need a standards-compliant MQTT broker on IoT Edge, consider deploying an open-source broker like [Mosquitto](https://mosquitto.org/) as an IoT Edge module.

-To send device-to-cloud telemetry messages using routing, use the ModuleClient of the Azure IoT SDK. With the Azure IoT SDK, each module has the concept of module *input* and *output* endpoints, which map to special MQTT topics. Use the `ModuleClient.sendMessageAsync` method and it will send messages on the output endpoint of your module. Then configure a route in edgeHub to send this output endpoint to IoT Hub.

-<!-- <1.2> -->

-Sending device-to-cloud telemetry messages with the MQTT broker is similar to publishing messages on user-defined topics, but using the following IoT Hub special topic for your module: `devices/<device_name>/modules/<module_name>/messages/events`. Authorizations must be set up appropriately. The MQTT bridge must also be configured to forward the messages on this topic to the cloud.

-<!-- <1.2> -->

-Processing messages using the MQTT broker is similar to subscribing to messages on user-defined topics, but using the IoT Edge special topics of your module's output queue: `devices/<device_name>/modules/<module_name>/messages/events`. Authorizations must be set up appropriately. Optionally you can send new messages on the topics of your choice.

-<!-- <1.2> -->

-To get a module twin with any MQTT client, slightly more work is involved since getting a twin is not a typical MQTT pattern. The module must first subscribe to IoT Hub special topic `$iothub/twin/res/#`. This topic name is inherited from IoT Hub, and all devices/modules need to subscribe to the same topic. It does not mean that devices receive the twin of each other. IoT Hub and edgeHub know which twin should be delivered where, even if all devices listen to the same topic name. Once the subscription is made, the module needs to ask for the twin by publishing a message to the following IoT Hub special topic with a request ID `$iothub/twin/GET/?$rid=1234`. This request ID is an arbitrary ID (that is, a GUID), which will be sent back by IoT Hub along with the requested data. This is how a client can pair its requests with the responses. The result code is a HTTP-like status code, where successful is encoded as 200.

-<!-- <1.2> -->

-To receive a module twin patch with any MQTT client, the process is similar to receiving full twins: a client needs to subscribe to special IoT Hub topic `$iothub/twin/PATCH/properties/desired/#`. After the subscription is made, when IoT Hub sends a change of the desired section of the twin, the client receives it.

-<!-- <1.2> -->

-To receive a direct method with any MQTT client, the process is very similar to receiving twin patches. The client needs to confirm back that it has received the call and can send back some information at the same time. Special IoT Hub topic to subscribe to is `$iothub/methods/POST/#`.

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!--1.2-->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-Use the following CLI command to create your IoT Edge device based on the prebuilt [iotedge-vm-deploy](https://github.com/Azure/iotedge-vm-deploy/tree/1.2) template.

- --template-uri "https://raw.githubusercontent.com/Azure/iotedge-vm-deploy/1.2/edgeDeploy.json" \

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-Update the **Image** field for both the edgeHub and edgeAgent modules to use the version tag 1.2. For example:

-* `mcr.microsoft.com/azureiotedge-hub:1.2`

-* `mcr.microsoft.com/azureiotedge-agent:1.2`

-<!--end 1.2-->

-<!-- 1.2 -->

- <!-- 1.2 -->

- <!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-Azure IoT Edge version 1.2 only supports modules built as Linux containers. [IoT Edge for Linux on Windows](iot-edge-for-linux-on-windows.md) is the recommended way to run IoT Edge on Windows devices.

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- end 1.2 -->

-<!-- <1.2> -->

-<!-- </1.2> -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

-<!-- 1.2 -->

-<!-- end 1.2 -->

- --template-uri "https://raw.githubusercontent.com/Azure/iotedge-vm-deploy/1.2.0/edgeDeploy.json" \

- IoT Edge version 1.2 is preinstalled with this ARM template, saving the need to manually install the assets on the virtual machines. If you are installing IoT Edge on your own devices, see [Install Azure IoT Edge for Linux (version 1.2)](how-to-provision-single-device-linux-symmetric.md) or [Update IoT Edge to version 1.2](how-to-update-iot-edge.md#special-case-update-from-10-or-11-to-12).

-* **IoT Edge 1.2** contains content for new features and capabilities that are in the latest stable release. This version of the documentation also contains content for the IoT Edge for Linux on Windows (EFLOW) continuous release version, which is based on IoT Edge 1.2 and contains the latest features and capabilities. IoT Edge 1.2 is now bundled with the [Microsoft Defender for IoT micro-agent for Edge](../defender-for-iot/device-builders/overview.md).

-* **EFLOW Continuous Release (CR)** based on Azure IoT Edge 1.2 version, it contains new features and capabilities that are in the latest stable release.

-| [1.2](https://github.com/Azure/azure-iotedge/releases/tag/1.2.0) | Stable | April 2021 | [IoT Edge devices behind gateways](how-to-connect-downstream-iot-edge-device.md?view=iotedge-2020-11&preserve-view=true)<br>[IoT Edge MQTT broker (preview)](how-to-publish-subscribe.md?view=iotedge-2020-11&preserve-view=true)<br>New IoT Edge packages introduced, with new installation and configuration steps. For more information, see [Update from 1.0 or 1.1 to 1.2](how-to-update-iot-edge.md#special-case-update-from-10-or-11-to-12).<br>Includes [Microsoft Defender for IoT micro-agent for Edge](../defender-for-iot/device-builders/overview.md).<br> Integration with Device Update. For more information, see [Update IoT Edge](how-to-update-iot-edge.md).

-You can repeat the onboarding process for multiple customers. When a user with the appropriate permissions signs in to your managing tenant, that user can be authorized across customer tenancy scopes to perform management operations, without having to sign in to every individual customer tenant.

-To onboard a customer's tenant, it must have an active Azure subscription. You'll need to know the following:

-As a service provider, you may want to perform multiple tasks for a single customer, requiring different access for different scopes. You can define as many authorizations as you need in order to assign the appropriate [Azure built-in roles](../../role-based-access-control/built-in-roles.md). Each authorization includes a **principalId** which refers to an Azure AD user, group, or service principal in the managing tenant.

-To define authorizations, you'll need to know the ID values for each user, user group, or service principal in the managing tenant to which you want to grant access. You can [retrieve these IDs by using the Azure portal, Azure PowerShell, or Azure CLI](../../role-based-access-control/role-assignments-template.md#get-object-ids) from within the managing tenant. You'll also need the role definition ID for each [built-in role](../../role-based-access-control/built-in-roles.md) you want to assign.

-We recommend using Azure AD user groups for each role whenever possible, rather than to individual users. This gives you the flexibility to add or remove individual users to the group that has access, so that you don't have to repeat the onboarding process to make user changes. You can also assign roles to a service principal, which can be useful for automation scenarios.

-To onboard your customer, you'll need to create an [Azure Resource Manager](../../azure-resource-manager/index.yml) template for your offer with the following information. The **mspOfferName** and **mspOfferDescription** values will be visible to the customer in the [Service providers page](view-manage-service-providers.md) of the Azure portal once the template is deployed in the customer's tenant.

-|**mspOfferName** |A name describing this definition. This value is displayed to the customer as the title of the offer and must be a unique value. |

-|**mspOfferDescription** |A brief description of your offer (for example, "Contoso VM management offer"). This field is optional, but recommended so that customers have a clear understanding of your offer. |

-|**managedByTenantId** |Your tenant ID. |

-|**authorizations** |The **principalId** values for the users/groups/SPNs from your tenant, each with a **principalIdDisplayName** to help your customer understand the purpose of the authorization, and mapped to a built-in **roleDefinitionId** value to specify the level of access. |

-You can create this template in the Azure portal, or by manually modifying the templates provided in our [samples repo](https://github.com/Azure/Azure-Lighthouse-samples/).

-> Separate deployments are also required for multiple offers being applied to the same subscription (or resource groups within a subscription). Each offer applied must use a different **mspOfferName**.

-On the **Create ARM Template offer** Page, provide your **Name** and an optional **Description**. These values will be used for the **mspOfferName** and **mspOfferDescription** in your template. The **managedByTenantId** value will be provided automatically, based on the Azure AD tenant to which you are logged in.

-Next, select either **Subscription** or **Resource group**, depending on the customer scope you want to onboard. If you select **Resource group**, you'll need to provide the name of the resource group to onboard. You can select the **+** icon to add additional resource groups as needed. (All of the resource groups must be in the same customer subscription.)

-When you've added all of your authorizations, select **View template**. On this screen, you'll see a .json file that corresponds to the values you entered. Select **Download** to save a copy of this .json file. This template can then be [deployed in the customer's tenant](#deploy-the-azure-resource-manager-template). You can also edit it manually if you need to make any changes. Note that the file is not stored in the Azure portal.

-The following example shows a modified **subscription.parameters.json** file that can be used to onboard a subscription. The resource group parameter files (located in the [rg-delegated-resource-management](https://github.com/Azure/Azure-Lighthouse-samples/tree/master/templates/delegated-resource-management/rg) folder) are similar, but also include an **rgName** parameter to identify the specific resource group(s) to be onboarded.

-The last authorization in the example above adds a **principalId** with the User Access Administrator role (18d7d88d-d35e-4fb5-a5c3-7773c20a72d9). When assigning this role, you must include the **delegatedRoleDefinitionIds** property and one or more supported Azure built-in roles. The user created in this authorization will be able to assign these roles to [managed identities](../../active-directory/managed-identities-azure-resources/overview.md) in the customer tenant, which is required in order to [deploy policies that can be remediated](deploy-policy-remediation.md). The user is also able to create support incidents. No other permissions normally associated with the User Access Administrator role will apply to this **principalId**.

-### PowerShell

-### Azure CLI

-### Azure portal

-With this option, you can modify your template directly in the Azure portal and then deploy it. This must be done by a user in the customer tenant.

-1. In our [GitHub repo](https://github.com/Azure/Azure-Lighthouse-samples/), select the **Deploy to Azure** button shown next to the template you want to use. The template will open in the Azure portal.

-1. Enter your values for **Msp Offer Name**, **Msp Offer Description**, **Managed by Tenant Id**, and **Authorizations**. If you prefer, you can select **Edit parameters** to enter values for `mspOfferName`, `mspOfferDescription`, `managedbyTenantId`, and `authorizations` directly in the parameter file. Be sure to update these values rather than using the default values from the template.

-### Azure portal

-### PowerShell

-### Azure CLI

-To access the **My customers** page in the Azure portal, select **All services**, then search for **My customers** and select it. You can also find it by entering ΓÇ£My customersΓÇ¥ in the search box near the top of the Azure portal.

-Keep in mind that the top **Customers** section of the **My customers** page only shows info about customers who have delegated subscriptions or resource groups to your Azure Active Directory (Azure AD) tenant through Azure Lighthouse. If you work with other customers (such as through the [Cloud Solution Provider (CSP) program](/partner-center/csp-overview)), you wonΓÇÖt see info about those customers in the **Customers** section unless you have [onboarded their resources to Azure Lighthouse](onboard-customer.md) (though you may see details about certain CSP customers in the [Cloud Solution Provider (Preview) section](#cloud-solution-provider-preview) lower on the page).

-You can also access functionality related to delegated subscriptions or resource groups from within services that support cross-tenant management experiences by selecting the subscription or resource group from within an individual service.

-Such CSP customers will appear in this section whether or not you have also onboarded them to Azure Lighthouse. Similarly, a CSP customer does not have to appear in the **Cloud Solution Provider (Preview)** section of **My customers** in order for you to onboard them to Azure Lighthouse.

-To view this page in the Azure portal, select **All services**, then search for **Service providers** and select it. You can also find this page by entering "Service providers" or "Azure Lighthouse" in the search box near the top of the Azure portal.

-To add a new service provider offer from the **Service provider offers** page, select **Add offer**. Select **Private offers** to view offers that a service provider has published for this customer. You can then select an offer, then select **Set up + subscribe**.

-After reviewing the changes, the customer can choose to update to the new version. The authorizations and other settings specified in the new version will then apply to any subscriptions and/or resource groups that have been delegated for that offer.

-Azure Stream Analytics is a real-time analytics and complex event-processing engine that is designed to analyze and process high volumes of fast streaming data from multiple sources simultaneously. Patterns and relationships can be identified in information extracted from a number of input sources including devices, sensors, clickstreams, social media feeds, and applications. These patterns can be used to trigger actions and initiate workflows such as creating alerts, feeding information to a reporting tool, or storing transformed data for later use. Also, Stream Analytics is available on Azure IoT Edge runtime, enabling to process data on IoT devices.

-* Analyze real-time telemetry streams from IoT devices

-* Web logs/clickstream analytics

-* Real-time analytics on Point of Sale data for inventory control and anomaly detection

-## How does Stream Analytics work?

-An Azure Stream Analytics job consists of an input, query, and an output. Stream Analytics ingests data from Azure Event Hubs (including Azure Event Hubs from Apache Kafka), Azure IoT Hub, or Azure Blob Storage. The query, which is based on SQL query language, can be used to easily filter, sort, aggregate, and join streaming data over a period of time. You can also extend this SQL language with JavaScript and C# user-defined functions (UDFs). You can easily adjust the event ordering options and duration of time windows when performing aggregation operations through simple language constructs and/or configurations.

-Each job has one or several outputs for the transformed data, and you can control what happens in response to the information you've analyzed. For example, you can:

-* Send data to services such as Azure Functions, Service Bus Topics or Queues to trigger communications or custom workflows downstream.

-* Send data to a Power BI dashboard for real-time dashboarding.

-* Store data in other Azure storage services (for example, Azure Data Lake, Azure Synapse Analytics, etc.) to train a machine learning model based on historical data or perform batch analytics.

-The following image shows how data is sent to Stream Analytics, analyzed, and sent for other actions like storage or presentation:

-Azure Stream Analytics is designed to be easy to use, flexible, reliable, and scalable to any job size. It is available across multiple Azure regions, and runs on IoT Edge or Azure Stack.

-## Ease of getting started

-Stream Analytics can route job output to many storage systems such as Azure Blob storage, Azure SQL Database, Azure Data Lake Store, and Azure CosmosDB. You can also run batch analytics on stream outputs with Azure Synapse Analytics or HDInsight, or you can send the output to another service, like Event Hubs for consumption or Power BI for real-time visualization.

-The Stream Analytics query language allows to perform CEP (Complex Event Processing) by offering a wide array of functions for analyzing streaming data. This query language supports simple data manipulation, aggregation and analytics functions, geospatial functions, pattern matching and anomaly detection. You can edit queries in the portal or using our development tools, and test them using sample data that is extracted from a live stream.