+> Installing Azure Arc extensions on [AKS hybrid clusters provisioned from Azure](extensions.md#aks-hybrid-clusters-provisioned-from-azure-preview) is currently in preview, with support for the Azure Arc-enabled Open Service Mesh, Azure Key Vault Secrets Provider, Flux (GitOps) and Microsoft Defender for Cloud extensions.

+> [!NOTE]

+> You can choose to automatically upgrade your extension instance to the latest minor and patch versions by setting `auto-upgrade-minor-version` to `true`, or you can instead set the version of the extension instance manually using the `--version` parameter. We recommend enabling automatic upgrades for minor and patch versions so that you always have the latest security patches and capabilities.

+>

+> Because major version upgrades may include breaking changes, automatic upgrades for new major versions of an extension instance aren't supported. You can choose when to [manually upgrade extension instances](#upgrade-extension-instance) to a new major version.

+| `--release-train` | Extension authors can publish versions in different release trains such as `Stable`, `Preview`, etc. If this parameter isn't set explicitly, `Stable` is used as default. |

+## Update extension instance

+> [!NOTE]

+> Refer to documentation for the specific extension type to understand the specific settings in `--configuration-settings` and `--configuration-protected-settings` that are able to be updated. For `--configuration-protected-settings`, all settings are expected to be provided, even if only one setting is being updated. If any of these settings are omitted, those settings will be considered obsolete and deleted.

+To update an existing extension instance, use `k8s-extension update`, passing in values for the mandatory and optional parameters. The mandatory and optional parameters are slightly different than those used to create an extension instance.

+This example updates the `auto-upgrade-minor-version` setting for an Azure Machine Learning extension instance to `true`:

+```azurecli

+az k8s-extension update --name azureml --extension-type Microsoft.AzureML.Kubernetes --scope cluster --cluster-name <clusterName> --resource-group <resourceGroupName> --auto-upgrade-minor-version true --cluster-type managedClusters

+```

+### Required parameters for update

+| Parameter name | Description |

+|-||

+| `--name` | Name of the extension instance |

+| `--cluster-name` | Name of the cluster on which the extension instance has to be created |

+| `--resource-group` | The resource group containing the cluster |

+| `--cluster-type` | The cluster type on which the extension instance has to be created. For Azure Arc-enabled Kubernetes clusters, use `connectedClusters`. For AKS clusters, use `managedClusters`.|

+### Optional parameters for update

+| Parameter name | Description |

+|--||

+| `--auto-upgrade-minor-version` | Boolean property that specifies whether the extension minor version is automatically upgraded. The default setting is `true`. If this parameter is set to true, you can't set the `version` parameter, as the version will be dynamically updated. If set to `false`, the extension won't be automatically upgraded, even for patch versions. |

+| `--version` | Version of the extension to be installed (specific version to pin the extension instance to). Must not be supplied if auto-upgrade-minor-version is set to `true`. |

+| `--configuration-settings` | Settings that can be passed into the extension to control its functionality.These are passed in as space-separated `key=value` pairs after the parameter name. If this parameter is used in the command, then `--configuration-settings-file` can't be used in the same command. Only the settings that require an update need to be provided. The provided settings will be replaced with the specified values. |

+| `--configuration-settings-file` | Path to the JSON file with `key=value` pairs to be used for passing in configuration settings to the extension. If this parameter is used in the command, then `--configuration-settings` can't be used in the same command. |

+| `--configuration-protected-settings` | Settings that aren't retrievable using `GET` API calls or `az k8s-extension show` commands. Typically used to pass in sensitive settings. These are passed in as space-separated `key=value` pairs after the parameter name. If this parameter is used in the command, then `--configuration-protected-settings-file` can't be used in the same command. When you update a protected setting, all of the protected settings are expected to be specified. If any of these settings are omitted, those settings will be considered obsolete and deleted. |

+| `--configuration-protected-settings-file` | Path to a JSON file with `key=value` pairs to be used for passing in sensitive settings to the extension. If this parameter is used in the command, then `--configuration-protected-settings` can't be used in the same command. |

+| `--scope` | Scope of installation for the extension - `cluster` or `namespace`. |

+| `--release-train` | Extension authors can publish versions in different release trains such as `Stable`, `Preview`, etc. If this parameter isn't set explicitly, `Stable` is used as default. |

+## Upgrade extension instance

+As noted earlier, if you set `auto-upgrade-minor-version` to true, the extension will automatically be upgraded when a new minor version is released. For most scenarios, we recommend enabling automatic upgrades. If you set `auto-upgrade-minor-version` to false, you'll have to upgrade the extension manually if you want a newer version.

+Manual upgrades are also required to get a new major instance of an extension. You can choose when to upgrade in order to avoid any unexpected breaking changes with major version upgrades.

+To manually upgrade an extension instance, use `k8s-extension update` and set the `version` parameter to specify a version.

+This example updates an Azure Machine Learning extension instance to version x.y.z:

+```azurecli

+az k8s-extension update --cluster-name <clusterName> --resource-group <resourceGroupName> --cluster-type connectedClusters --name azureml --version x.y.z

+```

+To delete an extension instance on a cluster, use `k8s-extension delete`, passing in values for the mandatory parameters:

+ Title: Use predictive autoscale to scale out before load demands in virtual machine scale sets

+| AddonAzureBackupAlerts | |

+| AddonAzureBackupJobs | |

+| AddonAzureBackupPolicy | |

+| AddonAzureBackupProtectedInstance | |

+| AddonAzureBackupStorage | |

+| ADFAirflowSchedulerLogs | |

+| ADFAirflowWebLogs | |

+| ADFSandboxActivityRun | |

+| ADFSandboxPipelineRun | |

+| ADFSSISIntegrationRuntimeLogs | |

+| ADFSSISPackageEventMessageContext | |

+| ADFSSISPackageEventMessages | |

+| ADFSSISPackageExecutableStatistics | |

+| ADFSSISPackageExecutionComponentPhases | |

+| ADFSSISPackageExecutionDataStatistics | |

+| ADXJournal | |

+| ADXTableDetails | |

+| ADXTableUsageStatistics | |

+| AirflowDagProcessingLogs | |

+| AKSAudit | |

+| AKSAuditAdmin | |

+| AKSControlPlane | |

+| Anomalies | |

+| ChaosStudioExperimentEventLogs | |

+| Event | Partial support. Data arriving from the Log Analytics agent or Azure Monitor Agent is fully supported in export. Data arriving via the Diagnostics extension agent is collected through storage. This path isn't supported in export. |

+| IdentityInfo | |

+| KubePVInventory | |

+| NetworkMonitoring | |

+| Perf | |

+| StorageBlobLogs | |

+| StorageFileLogs | |

+| StorageQueueLogs | |

+| StorageTableLogs | |

+| UCClientReadinessStatus | |

+| UCClientUpdateStatus | |

+| UCDeviceAlert | |

+| UCServiceUpdateStatus | |

+| W3CIISLog | Partial support. Data arriving from the Log Analytics agent or Azure Monitor Agent is fully supported in export. Data arriving via the Diagnostics extension agent is collected through storage. This path isn't supported in export. |

+### Protecting privacy with IoT and smart-building solutions

+Many countries have strict privacy laws about gathering and using data on peopleΓÇÖs presence and movements inside buildings. This may include data that is directly personally identifiable data from CCTV or security badge swipes. Or, indirectly identifiable where different sets of sensor data could be considered personally identifiable when grouped together.

+Privacy needs to be balanced with cost & environmental needs where organizations are keen to understand occupancy/movement in-order to provide the most efficient use of energy to heat and light a building.

+Determining which areas of corporate real-estate are under or over-occupied by staff from individual departments typically requires processing some personally identifiable data alongside less individual data like temperature and light sensors.

+In this use-case the primary goal is allowing analysis of occupancy data and temperature sensors to be processed alongside CCTV motion tracing sensors and badge-swipe data to understand usage without exposing the raw aggregate data to anyone.

+Confidential compute is used here by placing the analysis application (in this example running on Confidential Container Instances) inside a trusted execution environment where the in-use data is protected by encryption.

+The aggregate data-sets from many types of sensor and data feed are managed in an Azure SQL Always Encrypted with Enclaves database, this protects in-use queries by encrypting them in-memory. This prevents a server administrator from being able to access the aggregate data set while it is being queried and analyzed.

+In Government and public agencies, Azure confidential computing is a solution to raise the degree of trust towards the ability to protect data sovereignty in the public cloud. Moreover, thanks to the increasingly adoption of confidential computing capabilities into PaaS services in Azure, a higher degree of trust can be achieved with a reduced impact to the innovation ability provided by public cloud services. This combination of protecting data sovereignty with a reduced impact to the innovation ability makes Azure confidential computing a very effective response to the needs of sovereignty and digital transformation of Government services.

+sudo mount -t cifs -o vers=2.1 10.126.76.138:/utsac1_BlockBlob /home/databoxubuntuhost/databox

+> When you enable automatic deployment, Defender for Endpoint for Linux installation will abort on machines with pre-existing running services using [fanotify](/microsoft-365/security/defender-endpoint/microsoft-defender-endpoint-linux#system-requirements) and other services that can also cause MDE to malfunction or may be affected by MDE, such as security services.

+|Azure Files|Γ£ö|Γ£ö|-|

+- [Manage and respond to security alerts in Defender for Cloud](managing-and-responding-alerts.md)

+As an example, the **policy violation detection engine** models industrial control systems (ICS) networks in order to detect deviations from the expected "baseline" behavior-by utilizing Behavioral Anomaly Detection (BAD) as outlined in NISTIR 8219. This baseline is developed by understanding the regular activities that take place on the network, such as normal traffic patterns, user actions, and accesses to the ICS network. The BAD system then monitors the network for any deviation from the expected behavior and flags any policy violations. Examples of baseline deviations include the unauthorized use of function codes, access to specific objects, or changes to the configuration of a device.

+ - To learn about the device mapping, see [Overview of the MedTech service device mapping](overview-of-device-mapping.md).

+ - To learn about the FHIR destination mapping, see [Overview of the MedTech service FHIR destination mapping](overview-of-fhir-destination-mapping.md).

+- To learn about the device mapping, see [Overview of the device mapping](overview-of-device-mapping.md).

+- To learn about the FHIR destination mapping, see [Overview of the FHIR destination mapping](overview-of-fhir-destination-mapping.md).

+In order to configure the **Destination** tab, you can use the [Mapping debugger](how-to-use-mapping-debugger.md) tool to create, edit, and test the FHIR destination mapping. You need to configure FHIR destination mapping so that your instance of MedTech service can send transformed device data to the FHIR service.

+To begin configuring FHIR destination mapping, go to the **Create** MedTech service page and select the **Destination mapping** tab. There are two parts of the tab you must fill out:

+For Azure docs information about the FHIR destination mapping, see [Overview of the FHIR destination mapping](overview-of-fhir-destination-mapping.md).

+1. Go to the [Mapping debugger](how-to-use-mapping-debugger.md) and get the JSON template for your FHIR destination.

+In this quickstart, you'll learn how to use Azure PowerShell or the Azure CLI to deploy an instance of the MedTech service using an Azure Resource Manager template (ARM template).

+ - To learn about the device mapping, see [Overview of the MedTech service device mapping](overview-of-device-mapping.md).

+ - To learn about the FHIR destination mapping, see [Overview of the FHIR destination mapping](overview-of-fhir-destination-mapping.md).

+|Device mapping hasn't been configured.|Configure and save a conforming and valid [device mapping](overview-of-device-mapping.md).|

+|FHIR destination mapping hasn't been configured.|Configure and save a conforming and valid [FHIR destination mapping](overview-of-fhir-destination-mapping.md).|

+|The device message doesn't contain an expected expression defined in the device mapping.|Verify the [JsonPath](https://goessner.net/articles/JsonPath/) or [JMESPath](https://jmespath.org/specification.html) expressions defined in the [device mapping](overview-of-device-mapping.md) match tokens defined in the device message.|

+> [Understand the MedTech service device data processing stages](overview-of-device-data-processing-stages.md)

+You can verify that the device data was processed correctly by checking to see if there's now a new Observation resource in the FHIR service. If the device data isn't mapped or if the mapping isn't authored properly, the device data will be skipped. If there are any problems, check the [device mapping](overview-of-device-mapping.md) or the [FHIR destination mapping](overview-of-fhir-destination-mapping.md).

+|`Values[].ValueName`|The name to associate with the value that the next expression extracts. Used to bind the wanted value or component in the FHIR destination mapping.|`hr`|

+A set of custom functions for the MedTech service is also available. The MedTech service custom functions are outside the functions provided as part of the JMESPath specification. For more information on the MedTech service custom functions, see [How to use custom functions](how-to-use-custom-functions.md).

+> [Overview of the FHIR destination mapping](overview-of-fhir-destination-mapping.md)

+Many functions are available when using **JMESPath** as the expression language. Besides the functions available as part of the JMESPath specification, many more custom functions may also be used. This article describes the MedTech service-specific custom functions for use with the MedTech service [device mapping](overview-of-device-mapping.md) during the device message [normalization](overview-of-device-data-processing-stages.md#normalize) process.

+> [Overview of the MedTech service device mapping](overview-of-device-mapping.md)

+This article describes how to use IoTJsonPathContent mappings with the MedTech service [device mapping](overview-of-device-mapping.md).

+> `patientIdExpression` is only required for MedTech services in the **Create** mode, however, if **Lookup** is being used, a Device resource with a matching Device Identifier must exist in the FHIR service. These examples assume your MedTech service is in a **Create** mode. For more information on the **Create** and **Lookup** **Destination properties**, see [Configure Destination properties](deploy-new-config.md#destination-properties).

+> `patientIdExpression` is only required for MedTech services in the **Create** mode, however, if **Lookup** is being used, a Device resource with a matching Device Identifier must exist in the FHIR service. These examples assume your MedTech service is in a **Create** mode. For more information on the **Create** and **Lookup** **Destination properties**, see [Configure Destination properties](deploy-new-config.md#destination-properties).

+> [Overview of the FHIR destination mapping](overview-of-fhir-destination-mapping.md)

+The MedTech service can be customized and configured by using [device](overview-of-device-mapping.md) and [FHIR destination](overview-of-fhir-destination-mapping.md) mappings to define the filtering and transformation of your data into FHIR Observations.

+> If you're not able to fix your MedTech service issue using this troubleshooting guide, you can open an [Azure Technical Support](https://azure.microsoft.com/support/create-ticket/) ticket attaching copies of your device message and [device and FHIR destination mappings](how-to-use-mapping-debugger.md#overview-of-the-mapping-debugger) to your request to better help with issue determination.

+> If you're not able to fix your MedTech service issue using this troubleshooting guide, you can open an [Azure Technical Support](https://azure.microsoft.com/support/create-ticket/) ticket attaching copies of your device message and [device and FHIR destination mappings](how-to-use-mapping-debugger.md#overview-of-the-mapping-debugger) to your request to better help with issue determination.

+Each IoT hub has an identity registry you can use to create per-device resources in the service. The identity registry also enables you to control access to the device-facing endpoints. This article describes how to import and export device identities in bulk to and from an identity registry. To see a working sample in C# and learn how you can use this capability when migrating an IoT hub to a different region, see [How to migrate an IoT Hub using Azure Resource Manager templates](migrate-hub-arm.md).

+In this article, you learned how to perform bulk operations against the identity registry in an IoT hub. Many of these operations, including how to move devices from one hub to another, are used in the **Manage devices registered to the IoT hub** section of [How to migrate an IoT hub using Azure Resource Manager templates](migrate-hub-arm.md#manage-the-devices-registered-to-the-iot-hub).

+The migration article has a working sample associated with it, which is located in the IoT C# samples on this page: [Azure IoT hub service samples for C#](https://github.com/Azure/azure-iot-sdk-csharp/tree/main/iothub/service/samples/how%20to%20guides), with the project being ImportExportDevicesSample.

+You can only disable disaster recovery to avoid data replication outside of the paired region in Brazil South or Southeast Asia when you create an IoT hub. If you want to configure your existing IoT hub to disable disaster recovery, you need to create a new IoT hub with disaster recovery disabled and manually migrate your existing IoT hub. For guidance, see [How to migrate an IoT hub](migrate-hub-state-cli.md).

+ > You cannot upgrade from a Free Hub to a Paid Hub through our upgrade function. You must create a Paid hub and migrate the configurations and devices from the Free hub to the Paid hub. This process is documented at [How to migrate an IoT hub](./migrate-hub-state-cli.md).

+ Title: How to manually migrate an IoT hub

+description: Use the Azure portal, ARM templates, and service SDKs to manually migrate an Azure IoT hub to a new region or new SKU

+# How to manually migrate an Azure IoT hub using an Azure Resource Manager template

+Use the Azure portal, Azure Resource Manager templates, and Azure IoT Hub service SDKs to migrate an IoT hub to a new region, a new tier, or a new configuration.

+The steps in this article are useful if you want to:

+* Upgrade from the free tier to a basic or standard tier IoT hub.

+* Move an IoT hub to a new region.

+* Export IoT hub state information to have as a backup.

+* Increase the number of [partitions](iot-hub-scaling.md#partitions) for an IoT hub.

+* Set up a hub for a development, rather than production, environment.

+* Enable a custom implementation of multi-hub high availability. For more information, see the [How to achieve cross region HA section of IoT Hub high availability and disaster recovery](iot-hub-ha-dr.md#achieve-cross-region-ha).

+To migrate a hub, you need a subscription with administrative access to the original hub. You can put the new hub in a new resource group and region, in the same subscription as the original hub, or even in a new subscription. You just can't use the same name because the hub name has to be globally unique.

+## Compare automatic and manual migration steps

+The outcome of this article is similar to [How to automatically migrate an IoT hub using the Azure CLI](./migrate-hub-state-cli.md), but with a different process. Before you begin, decide which process is right for your scenario.

+* The manual process (this article):

+ * Migrates your device registry and your routing and endpoint information. You have to manually recreate other configuration details in the new IoT hub.

+ * Is faster for migrating large numbers of devices (for example, more than 100,000).

+ * Uses an Azure Storage account to transfer the device registry.

+ * Scrubs connection strings for routing and file upload endpoints from the ARM template output, and you need to manually add them back in.

+* The Azure CLI process:

+ * Migrates your device registry, your routing and endpoint information, and other configuration details like IoT Edge deployments or automatic device management configurations.

+ * Is easier for migrating small numbers of devices (for example, up to 10,000).

+ * Doesn't require an Azure Storage account.

+ * Collects connection strings for routing and file upload endpoints and includes them in the ARM template output.

+## Things to consider

+There are several things to consider before migrating an IoT hub.

+* Make sure that all of the features available in the original location are also available in the new location. Some services are in preview, and not all features are available everywhere.

+* Don't remove the original resources before creating and verifying the migrated version. Once you remove a hub, it's gone forever, and there's no way to recover it to check the settings or data to make sure the hub is replicated correctly.

+* Data for the original IoT hub isn't migrated. This data includes device messages, cloud-to-device (C2D) commands, and job-related information such as schedules and history. Metrics and logging results are also not migrated.

+* You need to schedule downtime for the migration. Cloning the devices to the new hub takes time. If you use the Import/Export method, benchmark testing has revealed that it could take around two hours to move 500,000 devices, and four hours to move a million devices.

+* You can copy devices to the new hub without shutting down or changing the devices.

+ * If the devices were originally provisioned using DPS, update their enrollments to point to the new IoT hub. Then, reprovision the devices to update the connection information stored in each device.

+ * Otherwise, you have to use the import/export method to move the devices, and then the devices have to be modified to use the new hub. For example, you can set up your device to consume the IoT Hub host name from the twin desired properties. The device takes that IoT Hub host name, disconnect the device from the old hub, and reconnect it to the new one.

+* You need to update any certificates so you can use them with the new resources. Also, you probably have the hub defined in a DNS table somewhere and need to update that DNS information.

+## Methodology

+This is the general method we recommend for migrating an IoT hub.

+1. Export the hub and its settings to a Resource Manager template.

+1. Make the necessary changes to the template, such as updating all occurrences of the name and the location for the migrated hub. For any resources in the template used for message routing endpoints, update the key in the template for that resource.

+1. Import the template into a new resource group in the new location. This step creates the new IoT hub.

+1. Debug as needed.

+1. Add anything that wasn't exported to the template.

+ For example, consumer groups aren't exported to the template. You need to add the consumer groups to the template manually or use the [Azure portal](https://portal.azure.com) after the hub is created.

+1. Copy the devices from the original hub to the new hub. This process is covered in the section [Manage the devices registered to the IoT hub](#manage-the-devices-registered-to-the-iot-hub).

+## How to handle message routing

+If your hub uses [message routing](iot-hub-devguide-messages-d2c.md), exporting the template for the hub includes the routing configuration, but it doesn't include the resources themselves. If you're migrating the IoT hub to a new region, you must choose whether to move the routing resources to the new location as well or to leave them in place and continue to use them "as is". There may be a small performance hit from routing messages to endpoint resources in a different region.

+If the hub uses message routing, you have two choices.

+* Move the resources used for the routing endpoints to the new location.

+ 1. Create the new resources yourself either manually in the [Azure portal](https://portal.azure.com) or by using Resource Manager templates.

+ 1. Rename all of the resources when you create them in the new location, as they require globally unique names.

+ 1. Update the resource names and the resource keys in the new hub's template before creating the new hub. The resources should be present when the new hub is created.

+* Don't move the resources used for the routing endpoints. Use them "in place".

+ 1. In the step where you edit the template, you need to retrieve the keys for each routing resource and put them in the template before you create the new hub.

+ 1. The hub still references the original routing resources and routes messages to them as configured. You'll have a small performance hit because the hub and the routing endpoint resources aren't in the same location.

+## Prepare to migrate the hub to another region

+This section provides specific instructions for migrating the hub.

+### Export the original hub to a resource template

+1. Sign into the [Azure portal](https://portal.azure.com).

+1. Navigate to the IoT hub that you want to move.

+1. Select **Export template** from the list of properties and settings for the hub.

+ :::image type="content" source="./media/migrate-hub-arm/iot-hub-export-template.png" alt-text="Screenshot showing the command for exporting the template for the IoT Hub." border="true":::

+1. Select **Download** to download the template. Save the file somewhere you can find it again.

+ :::image type="content" source="./media/migrate-hub-arm/iot-hub-download-template.png" alt-text="Screenshot showing the command for downloading the template for the IoT Hub." border="true":::

+### View the template

+Go to the downloaded template, which is contained in a zip file. Extract the zip file and find the file called `template.json`.

+The following example is for a generic hub with no routing configuration. It's an S1 tier hub (with 1 unit) called **ContosoHub** in region **westus**:

+``` json

+{

+ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",

+ "contentVersion": "1.0.0.0",

+ "parameters": {

+ "IotHubs_ContosoHub_connectionString": {

+ "type": "SecureString"

+ },

+ "IotHubs_ContosoHub_containerName": {

+ "type": "SecureString"

+ },

+ "IotHubs_ContosoHub_name": {

+ "defaultValue": "ContosoHub",

+ "type": "String"

+ }

+ },

+ "variables": {},

+ "resources": [

+ {

+ "type": "Microsoft.Devices/IotHubs",

+ "apiVersion": "2021-07-01",

+ "name": "[parameters('IotHubs_ContosoHub_name')]",

+ "location": "westus",

+ "sku": {

+ "name": "S1",

+ "tier": "Standard",

+ "capacity": 1

+ },

+ "identity": {

+ "type": "None"

+ },

+ "properties": {

+ "ipFilterRules": [],

+ "eventHubEndpoints": {

+ "events": {

+ "retentionTimeInDays": 1,

+ "partitionCount": 4

+ }

+ },

+ "routing": {

+ "endpoints": {

+ "serviceBusQueues": [],

+ "serviceBusTopics": [],

+ "eventHubs": [],

+ "storageContainers": []

+ },

+ "routes": [],

+ "fallbackRoute": {

+ "name": "$fallback",

+ "source": "DeviceMessages",

+ "condition": "true",

+ "endpointNames": [

+ "events"

+ ],

+ "isEnabled": true

+ }

+ },

+ "storageEndpoints": {

+ "$default": {

+ "sasTtlAsIso8601": "PT1H",

+ "connectionString": "[parameters('IotHubs_ContosoHub_connectionString')]",

+ "containerName": "[parameters('IotHubs_ContosoHub_containerName')]"

+ }

+ },

+ "messagingEndpoints": {

+ "fileNotifications": {

+ "lockDurationAsIso8601": "PT1M",

+ "ttlAsIso8601": "PT1H",

+ "maxDeliveryCount": 10

+ }

+ },

+ "enableFileUploadNotifications": false,

+ "cloudToDevice": {

+ "maxDeliveryCount": 10,

+ "defaultTtlAsIso8601": "PT1H",

+ "feedback": {

+ "lockDurationAsIso8601": "PT1M",

+ "ttlAsIso8601": "PT1H",

+ "maxDeliveryCount": 10

+ }

+ },

+ "features": "None",

+ "disableLocalAuth": false,

+ "allowedFqdnList": []

+ }

+ }

+ ]

+}

+```

+### Edit the template

+You have to make some changes before you can use the template to create the new hub in the new region. Use [Visual Studio Code](https://code.visualstudio.com) or a text editor to edit the template.

+#### Edit the hub name and location

+1. Remove the container name parameter section at the top. **ContosoHub** doesn't have an associated container.

+ ``` json

+ "parameters": {

+ ...

+ "IotHubs_ContosoHub_containerName": {

+ "type": "SecureString"

+ },

+ ...

+ },

+ ```

+1. Remove the **storageEndpoints** property.

+ ```json

+ "properties": {

+ ...

+ "storageEndpoints": {

+ "$default": {

+ "sasTtlAsIso8601": "PT1H",

+ "connectionString": "[parameters('IotHubs_ContosoHub_connectionString')]",

+ "containerName": "[parameters('IotHubs_ContosoHub_containerName')]"

+ }

+ },

+ ...

+

+ ```

+1. If you're moving the hub to a new region, change the **location** property under **resources**.

+ ``` json

+ "location": "westus",

+ ```

+#### Update the routing endpoint resources

+When you export the Resource Manager template for a hub that has routing configured, you see that the keys for those resources aren't provided in the exported template. Their placement is denoted by asterisks. You must fill them in by going to those resources in the portal and retrieving the keys **before** you import the new hub's template and create the hub.

+If you moved the routing resources as well, update the name, ID, and resource group of each endpoint as well.

+1. Retrieve the keys required for any of the routing resources and put them in the template. You can retrieve the key(s) from the resource in the [Azure portal](https://portal.azure.com).

+ * For example, if you're routing messages to a storage container, find the storage account in the portal. Under the Settings section, select **Access keys**, then copy one of the keys. Here's what the key looks like when you first export the template:

+ ```json

+ "connectionString": "DefaultEndpointsProtocol=https;

+ AccountName=fabrikamstorage1234;AccountKey=****",

+ "containerName": "fabrikamresults",

+ ```

+ After you retrieve the account key for the storage account, put it in the template in the `AccountKey=****` clause in the place of the asterisks.

+ * For service bus queues, get the Shared Access Key matching the SharedAccessKeyName. Here's the key and the `SharedAccessKeyName` in the json:

+ ```json

+ "connectionString": "Endpoint=sb://fabrikamsbnamespace1234.servicebus.windows.net:5671/;

+ SharedAccessKeyName=iothubroutes_FabrikamResources;

+ SharedAccessKey=****;

+ EntityPath=fabrikamsbqueue1234",

+ ```

+ * The same applies for the Service Bus Topics and Event Hubs connections.

+## Create the new hub by loading the template

+Create the new hub using the edited template. If you have routing resources that are going to move, the resources should be set up in the new location and the references in the template updated to match. If you aren't moving the routing resources, they should be in the template with the updated keys.

+1. Sign into the [Azure portal](https://portal.azure.com).

+1. Select **Create a resource**.

+1. In the search box, search for and select **template deployment (deploy using custom templates)**. On the screen for the template deployment, select **Create**.

+1. On the **Custom deployment** page, select **Build your own template in the editor**, which enables you to upload your template from a file.

+ :::image type="content" source="./media/migrate-hub-arm/iot-hub-custom-deployment.png" alt-text="Screenshot showing the command for building your own template.":::

+1. Select **Load file**.

+ :::image type="content" source="./media/migrate-hub-arm/iot-hub-upload-file.png" alt-text="Screenshot showing the command for uploading a template file.":::

+1. Browse for the new template you edited and select it, then select **Open**. It loads your template in the edit window. Select **Save**.

+ :::image type="content" source="./media/migrate-hub-arm/iot-hub-uploaded-file.png" alt-text="Screenshot showing loading the template.":::

+1. Fill in the following fields on the custom deployment page.

+ **Subscription**: Select the subscription to use.

+ **Resource group**: Select an existing resource group or create a new one.

+ **Region**: If you selected an existing resource group, the region is filled in for you to match the location of the resource group. If you created a new resource group, this is its location.

+ **Connection string**: Fill in the connection string for your hub.

+ **Hub name**: Give the new hub a name.

+ :::image type="content" source="./media/migrate-hub-arm/iot-hub-custom-deployment-create.png" alt-text="Screenshot showing the custom deployment page":::

+1. Select the **Review + create** button.

+1. Select the **Create** button. The portal validates your template and deploys your new hub. If you have routing configuration data, it is included in the new hub, but points at the resources in the prior location.

+ :::image type="content" source="./media/migrate-hub-arm/iot-hub-custom-deployment-final.png" alt-text="Screenshot showing the final custom deployment page":::

+## Manage the devices registered to the IoT hub

+Now that you have your new hub up and running, you need to copy all of the devices from the original hub to the new one.

+There are multiple ways to copy the devices. You either originally used [Device Provisioning Service (DPS)](../iot-dps/about-iot-dps.md) to provision the devices, or you didn't. If you did, this process isn't difficult. If you didn't, this process can be complicated.

+If you didn't use DPS to provision your devices, you can skip the next section and start with [Use Import/Export to move the devices to the new hub](#use-import-export-to-move-the-devices-to-the-new-hub).

+## Use DPS to reprovision the devices in the new hub

+To use DPS to move the devices to the new location, see [How to reprovision devices](../iot-dps/how-to-reprovision.md). When you're finished, you can view the devices in the [Azure portal](https://portal.azure.com) and verify they are in the new location.

+Go to the new hub using the [Azure portal](https://portal.azure.com). Select your hub, then select **IoT Devices**. You see the devices that were reprovisioned to the new hub. You can also view the properties for the new hub.

+If you have implemented routing, test and make sure your messages are routed to the resources correctly.

+### Roll back the changes after using DPS

+If you want to roll back the changes, reprovision the devices from the new hub to the old one.

+You're now finished migrating your hub and its devices. You can skip to [Clean-up](#clean-up).

+## Use import-export to move the devices to the new hub

+The application targets .NET Core, so you can run it on either Windows or Linux. You can download the sample, retrieve your connection strings, set the flags for which bits you want to run, and run it. You can do this without ever opening the code.

+### Download the sample

+1. Use the IoT C# samples here: [Azure IoT SDK for C#](https://github.com/Azure/azure-iot-sdk-csharp/archive/main.zip). Download the zip file and unzip it on your computer.

+1. The pertinent code is in ./iothub/service/samples/how to guides/ImportExportDevicesSample. You don't need to view or edit the code in order to run the application.

+1. To run the application, specify three connection strings and five options. You pass this data in as command-line arguments or use environment variables, or use a combination of the two. We're going to pass the options in as command line arguments, and the connection strings as environment variables.

+ The reason for this is because the connection strings are long and ungainly, and unlikely to change, but you might want to change the options and run the application more than once. To change the value of an environment variable, you have to close the command window and Visual Studio or Visual Studio Code, whichever you're using.

+### Options

+Here are the five options you specify when you run the application:

+* **addDevices** (argument 1) - set this option to `True` if you want to add virtual devices that are generated for you. These devices are added to the source hub. Also, set **numToAdd** (argument 2) to specify how many devices you want to add. The maximum number of devices you can register to a hub is one million. The purpose of this option is for testing. You can generate a specific number of devices, and then copy them to another hub.

+* **copyDevices** (argument 3) - set this option to `True` to copy the devices from one hub to another.

+* **deleteSourceDevices** (argument 4) - set this option to `True` to delete all of the devices registered to the source hub. We recommend waiting until you are certain all of the devices have been transferred before you run this. Once you delete the devices, you can't get them back.

+* **deleteDestDevices** (argument 5) - set this option to `True` to delete all of the devices registered to the destination hub. You might want to do this if you want to copy the devices more than once.

+The basic command is *dotnet run*, which tells .NET to build the local csproj file and then run it. You add your command-line arguments to the end before you run it.

+Your command-line will look like these examples:

+``` console

+ // Format: dotnet run add-devices num-to-add copy-devices delete-source-devices delete-destination-devices

+ // Add 1000 devices, don't copy them to the other hub, or delete them.

+ // The first argument is true, numToAdd is 50, and the other arguments are false.

+ dotnet run true 1000 false false false

+ // Copy the devices you just added to the other hub; don't delete anything.

+ // The first argument is false, numToAdd is 0, copy-devices is true, and the delete arguments are both false

+ dotnet run false 0 true false false

+```

+### Use environment variables for the connection strings

+1. To run the sample, you need the connection strings to the old and new IoT hubs, and to a storage account you can use for temporary work files. We will store the values for these in environment variables.

+1. To get the connection string values, sign in to the [Azure portal](https://portal.azure.com).

+1. Put the connection strings somewhere you can retrieve them, such as NotePad. If you copy the following, you can paste the connection strings in directly where they go. Don't add spaces around the equal sign, or it changes the variable name. Also, you don't need double-quotes around the connection strings. If you put quotes around the storage account connection string, the script fails.

+ Set the environment variables in Windows:

+ ``` console

+ SET IOTHUB_CONN_STRING=<put connection string to original IoT hub here>

+ SET DEST_IOTHUB_CONN_STRING=<put connection string to destination IoT hub here>

+ SET STORAGE_ACCT_CONN_STRING=<put connection string to the storage account here>

+ ```

+ Set the environment variables in Linux:

+ ``` console

+ export IOTHUB_CONN_STRING="<put connection string to original IoT hub here>"

+ export DEST_IOTHUB_CONN_STRING="<put connection string to destination IoT hub here>"

+ export STORAGE_ACCT_CONN_STRING="<put connection string to the storage account here>"

+ ```

+1. For the IoT hub connection strings, go to each hub in the portal. You can search in **Resources** for the hub. If you know the Resource Group, you can go to **Resource groups**, select your resource group, and then select the hub from the list of assets in that resource group.

+1. Select **Shared access policies** from the Settings for the hub, then select **iothubowner** and copy one of the connection strings. Do the same for the destination hub. Add them to the appropriate SET commands.

+1. For the storage account connection string, find the storage account in **Resources** or under its **Resource group** and open it.

+1. Under the Settings section, select **Access keys** and copy one of the connection strings. Put the connection string in your text file for the appropriate SET command.

+Now you have the environment variables in a file with the SET commands, and you know what your command-line arguments are. Let's run the sample.

+### Run the sample application and using command-line arguments

+1. Open a command prompt window. Select Windows and type in `command prompt` to get the command prompt window.

+1. Copy the commands that set the environment variables, one at a time, and paste them into the command prompt window and select Enter. When you're finished, type `SET` in the command prompt window to see your environment variables and their values. Once you've copied these into the command prompt window, you don't have to copy them again, unless you open a new command prompt window.

+1. In the command prompt window, change directories until you are in ./ImportExportDevicesSample (where the ImportExportDevicesSample.csproj file exists). Then type the following, and include your command-line arguments.

+ ``` console

+ // Format: dotnet run add-devices num-to-add copy-devices delete-source-devices delete-destination-devices

+ dotnet run arg1 arg2 arg3 arg4 arg5

+ ```

+ The dotnet command builds and runs the application. Because you're passing in the options when you run the application, you can change the values of them each time you run the application. For example, you may want to run it once and create new devices, then run it again and copy those devices to a new hub, and so on. You can also perform all the steps in the same run, although we recommend not deleting any devices until you're certain you're finished with the migration. Here's an example that creates 1000 devices and then copies them to the other hub.

+ ``` console

+ // Format: dotnet run add-devices num-to-add copy-devices delete-source-devices delete-destination-devices

+ // Add 1000 devices, don't copy them to the other hub or delete them.

+ dotnet run true 1000 false false false

+ // Do not add any devices. Copy the ones you just created to the other hub; don't delete anything.

+ dotnet run false 0 true false false

+ ```

+ After you verify that the devices were copied successfully, you can remove the devices from the source hub like this:

+ ``` console

+ // Format: dotnet run add-devices num-to-add copy-devices delete-source-devices delete-destination-devices

+ // Delete the devices from the source hub.

+ dotnet run false 0 false true false

+ ```

+### Run the sample application using Visual Studio

+1. If you want to run the application in Visual Studio, change your current directory to the folder where the azureiot.sln file resides. Then run this command in the command prompt window to open the solution in Visual Studio. You must do this in the same command window where you set the environment variables, so those variables are known.

+ ``` console

+ azureiot.sln

+ ```

+1. Right-click on the project *ImportExportDevicesSample* and select **Set as startup project**.

+1. Set the variables at the top of Program.cs in the ImportExportDevicesSample folder for the five options.

+ ``` csharp

+ // Add randomly created devices to the source hub.

+ private static bool addDevices = true;

+ //If you ask to add devices, this will be the number added.

+ private static int numToAdd = 0;

+ // Copy the devices from the source hub to the destination hub.

+ private static bool copyDevices = false;

+ // Delete all of the devices from the source hub. (It uses the IoTHubConnectionString).

+ private static bool deleteSourceDevices = false;

+ // Delete all of the devices from the destination hub. (Uses the DestIotHubConnectionString).

+ private static bool deleteDestDevices = false;

+ ```

+1. Select F5 to run the application. After it finishes running, you can view the results.

+### View the results

+You can view the devices in the [Azure portal](https://portal.azure.com) and verify they are in the new location.

+1. Go to the new hub using the [Azure portal](https://portal.azure.com). Select your hub, then select **IoT Devices**. You see the devices you copied from the old hub to the new hub. You can also view the properties for the new hub.

+1. Check for import/export errors by going to the Azure storage account in the [Azure portal](https://portal.azure.com) and looking in the `devicefiles` container for the `ImportErrors.log`. If this file is empty (the size is 0), there were no errors. If you try to import the same device more than once, it rejects the device the second time and adds an error message to the log file.

+### Commit the changes

+At this point, you have copied your hub to the new location and migrated the devices to the new hub. Now you need to make changes so the devices work with the new hub.

+To commit the changes, here are the steps you need to perform:

+* Update each device to change the IoT Hub host name to point the IoT Hub host name to the new hub. You should do this using the same method you used when you first provisioned the device.

+* Change any applications you have that refer to the old hub to point to the new hub.

+* After you're finished, the new hub should be up and running. The old hub should have no active devices and be in a disconnected state.

+### Roll back the changes

+If you decide to roll back the changes, here are the steps to perform:

+* Update each device to change the IoT Hub Hostname to point the IoT Hub Hostname for the old hub. You should do this using the same method you used when you first provisioned the device.

+* Change any applications you have that refer to the new hub to point to the old hub. For example, if you're using Azure Analytics, you may need to reconfigure your [Azure Stream Analytics input](../stream-analytics/stream-analytics-define-inputs.md#stream-data-from-iot-hub).

+* Delete the new hub.

+* If you have routing resources, the configuration on the old hub should still point to the correct routing configuration, and should work with those resources after the hub is restarted.

+### Check the results

+To check the results, change your IoT solution to point to your hub in the new location and run it. In other words, perform the same actions with the new hub that you performed with the previous hub and make sure they work correctly.

+If you have implemented routing, test and make sure your messages are routed to the resources correctly.

+## Clean up

+Don't clean up until you're certain the new hub is up and running and the devices are working correctly. Also be sure to test the routing if you're using that feature. When you're ready, clean up the old resources by performing these steps:

+* If you haven't already, delete the old hub. This removes all of the active devices from the hub.

+* If you have routing resources that you moved to the new location, you can delete the old routing resources.

+## Next steps

+You have migrated an IoT hub into a new hub in a new region, complete with the devices. For more information about performing bulk operations against the identity registry in an IoT Hub, see [Import and export IoT Hub device identities in bulk](iot-hub-bulk-identity-mgmt.md).

+ Title: How to migrate an IoT hub

+description: Use the Azure CLI iot hub state command group to migrate an IoT hub to a new region, a new tier, or a new configuration

+# How to automatically migrate an IoT hub using the Azure CLI

+Use the Azure CLI to migrate an IoT hub to a new region, a new tier, or a new configuration.

+The steps in this article are useful if you want to:

+* Upgrade from the free tier to a basic or standard tier IoT hub.

+* Move an IoT hub to a new region.

+* Export IoT hub state information to have as a backup.

+* Increase the number of [partitions](iot-hub-scaling.md#partitions) for an IoT hub.

+* Set up a hub for a development, rather than production, environment.

+## Compare automatic and manual migration steps

+The outcome of this article is similar to [How to migrate an Azure IoT hub using Azure Resource Manager templates](iot-hub-how-to-clone.md), but with a different process. Before you begin, decide which process is right for your scenario.

+* The Azure CLI process (this article):

+ * Migrates your device registry, your routing and endpoint information, and other configuration details like IoT Edge deployments or automatic device management configurations.

+ * Is easier for migrating small numbers of devices (for example, up to 10,000).

+ * Doesn't require an Azure Storage account.

+ * Collects connection strings for routing and file upload endpoints and includes them in the ARM template output.

+* The manual process:

+ * Migrates your device registry and your routing and endpoint information. You have to manually recreate other configuration details in the new IoT hub.

+ * Is faster for migrating large numbers of devices (for example, more than 100,000).

+ * Uses an Azure Storage account to transfer the device registry.

+ * Scrubs connection strings for routing and file upload endpoints from the ARM template output, and you need to manually add them back in.

+## Prerequisites

+* Azure CLI

+ The features described in this article require version 0.20.0 or newer of the **azure-iot** extension. To check your extension version, run `az --version`. To update your extension, run `az extension update --name azure-iot`.

+ If you still have the legacy **azure-cli-iot-ext** extension installed, remove that extension before adding the **azure-iot** extension.

+## IoT hub state

+When we talk about migrating the state of an IoT hub, we're referring to a combination of three aspects:

+* **Azure Resource Manager (ARM) resources.** This aspect is everything that can be defined in a resource template, and is the same information you'd get if you exported the resource template from your IoT hub in the Azure portal. Information captured as part of the Azure Resource Manager aspect includes:

+ * Built-in event hub's retention time

+ * Certificates

+ * Cloud-to-device properties

+ * Disable device SAS

+ * Disable local auth

+ * Enable file upload notifications

+ * File upload storage endpoint

+ * Identities

+ * User-assigned identities

+ * System-assigned identities (enabled or disabled)

+ * Network rule sets

+ * Routing

+ * Custom endpoints

+ * Fallback route

+ * Routes

+ * Tags

+* **Configurations.** This aspect is for aspects of an IoT hub that aren't represented in an ARM template. Specifically, this aspect covers automatic device management configurations and IoT Edge deployments.

+* **Devices.** This aspect represents the information in your device registry, which includes:

+ * Device identities and twins

+ * Module identities and twins

+Any IoT Hub property or configuration not listed here may not be exported or imported correctly.

+## Export the state of an IoT hub

+Use the [az iot hub state export](/cli/azure/iot/hub/state#az-iot-hub-state-export) command to export the state of an IoT hub to a JSON file.

+If you want to run both the export and import steps in one command, refer to the section later in this article to [Migrate an IoT hub](#migrate-an-iot-hub).

+When you export the state of an IoT hub, you can choose which aspects to export.

+| Parameter | Details |

+| | - |

+| `--aspects` | The state aspects to export. Specify one or more of the accepted values: **arm**, **configurations**, or **devices**. If this parameter is left out, then all three aspects are exported. |

+| `--state-file -f` | The path to the file where the state information is written. |

+| `--replace -r` | If this parameter is included, then the export command overwrites the contents of the state file. |

+| `--hub-name -n`<br>**or**<br>`--login -l` | The name of the origin IoT hub (`-n`) or the connection string for the origin IoT hub (`-l`). If both are provided, then the connection string takes priority. |

+| `--resource-group -g` | The name of the resource group for the origin IoT hub. |

+The following example exports all aspects of an IoT hub's state to a file named **myHub-state**:

+```azurecli

+az iot hub state export --hub-name myHub --state-file ./myHub-state.json

+```

+The following example exports only the devices and Azure Resource Manager aspects of an IoT hub's state, and overwrites the content of the existing file:

+```azurecli

+az iot hub state export --hub-name myHub --state-file ./myHub-state.json --aspects arm devices --replace

+```

+### Export endpoints

+If you choose to export the Azure Resource Manager aspect of an IoT hub, the export command retrieves the connection strings for any endpoints that have key-based authentication and include them in the output ARM template.

+The export command also checks all endpoints to verify that the resource it connects to still exists. If not, then that endpoint and any routes using that endpoint aren't exported.

+## Import the state of an IoT hub

+Use the [az iot hub state import](/cli/azure/iot/hub/state#az-iot-hub-state-import) command to import state information from an exported file to a new or existing IoT hub.

+If you want to run both the export and import steps in one command, refer to the section later in this article to [Migrate an IoT hub](#migrate-an-iot-hub).

+| Parameter | Details |

+| | - |

+| `--aspects` | The state aspects to import. Specify one or more of the accepted values: **arm**, **configurations**, or **devices**. If this parameter is left out, then all three aspects are imported. |

+| `--state-file -f` | The path to the exported state file. |

+| `--replace -r` | If this parameter is included, then the import command deletes the current state of the destination hub. |

+| `--hub-name -n`<br>**or**<br>`--login -l` | The name of the destination IoT hub (`-n`) or the connection string for the destination IoT hub (`-l`). If both are provided, then the connection string takes priority. |

+| `--resource-group -g` | The name of the resource group for the destination IoT hub. |

+The following example imports all aspects to a new IoT hub, which is created if it doesn't already exist:

+```azurecli

+az iot hub state import --hub-name myNewHub --state-file ./myHub-state.json

+```

+The following example imports only the devices and configurations aspects to a new IoT hub, which must exist already, and overwrites any existing devices and configurations:

+```azurecli

+az iot hub state import --hub-name myNewHub --state-file ./myHub-state.json --aspects devices configurations --replace

+```

+### Create a new IoT hub with state import

+You can use the `az iot hub state import` command to create a new IoT hub or to write to an existing IoT hub.

+If you want to create a new IoT Hub, then you must include the `arm` aspect in the import command. If `arm` isn't included in the command, and the destination hub doesn't exist, then the import command fails.

+If the destination hub doesn't exist, then the `--resource-group` parameter is also required for the import command.

+### Update an existing IoT hub with state import

+If the destination IoT hub already exists, then the `arm` aspect isn't required for the `az iot hub state import` command. If you do include the `arm` aspect, all the resource properties will be overwritten except for the following properties that can't be changed after hub creation:

+* Location

+* SKU

+* Built-in Event Hubs partition count

+* Data residency

+* Features

+If the `--resource-group` is specified in the import command and is different than IoT hub's current resource group, then the command fails because it attempts to create a new hub with the same name as the one that already exists.

+If you include the `--replace` flag in the import command, then the following IoT hub aspects are removed from the destination hub before the hub state is uploaded:

+* **ARM**: Any uploaded certificates on the destination hub are deleted. If a certificate is present, it needs an etag to be updated.

+* **Devices**: All devices and modules, edge and non-edge, are deleted.

+* **Configurations**: All ADM configurations and IoT Edge deployments are deleted.

+## Migrate an IoT hub

+Use the [az iot hub state migrate](/cli/azure/iot/hub/state#az-iot-hub-state-migrate) command to migrate the state of one IoT hub to a new or existing IoT hub.

+This command wraps the export and import steps into a single command, but has no output files. All of the guidance and limitations described in the [Export the state of an IoT hub](#export-the-state-of-an-iot-hub) and [Import the state of an IoT hub](#import-the-state-of-an-iot-hub) sections apply to the `state migrate` command as well.

+If you're migrating a device registry with many devices (for example, a few hundred or a few thousand) you may find it easier and faster to run the export and import commands separately rather than running the migrate command.

+| Parameter | Details |

+| | - |

+| `--aspects` | The state aspects to migrate. Specify one or more of the accepted values: **arm**, **configurations**, or **devices**. If this parameter is left out, then all three aspects are migrated. |

+| `--replace -r` | If this parameter is included, then the migrate command deletes the current state of the destination hub. |

+| `--destination-hub --dh`<br>**or**<br>`--destination-hub-login --dl` | The name of the destination IoT hub (`--dh`) or the connection string for the destination IoT hub (`--dl`). If both are provided, then the connection string takes priority. |

+| `--destination-resource-group --dg` | Name of the resource group for the destination IoT hub. The destination resource group is required if the destination hub doesn't exist. |

+| `--origin-hub --oh`<br>**or**<br>`--origin-hub-login --ol` | The name of the origin IoT hub (`--oh`) or the connection string for the origin IoT hub (`--ol`). If both are provided, then the connection string takes priority. Use the connection string to avoid having to sign in to the Azure CLI session. |

+| `--origin-resource-group --og` | The name of the resource group for the origin IoT hub. |

+The following example migrates all aspects of the origin hub to the destination hub, which is created if it doesn't exist:

+```azurecli

+az iot hub state migrate --origin-hub myHub --origin-resource-group myGroup --destination-hub myNewHub --destination-resource-group myNewGroup

+```

+## Troubleshoot a migration

+If you can't export or import devices or configurations, check that you have access to those properties. One way to verify your access is by running the `az iot hub device-identity list` or `az iot hub configuration list` commands.

+If the `az iot hub state migrate` command fails, try running the export and import commands separately. The two commands result in the same functionality as the migrate command alone, but by running them separately you can review the state files that are created from the export command.

+## Next steps

+For more information about performing bulk operations against the identity registry in an IoT hub, see [Import and export IoT Hub device identities](./iot-hub-bulk-identity-mgmt.md).

+## Access data from a datastore URI, like a filesystem

+You can pip install the `azureml-fsspec`package and its dependency `azureml-dataprep` package. And then you can use the Azure Machine Learning Datastore implementation of `fsspec`.

+fs.upload(lpath='data/upload_files/crime-spring.csv', rpath='data/fsspec', recursive=False, **{'overwrite': 'MERGE_WITH_OVERWRITE'})

+fs.upload(lpath='data/upload_folder/', rpath='data/fsspec_folder', recursive=True, **{'overwrite': 'MERGE_WITH_OVERWRITE'})

+# How to view the output of an `az networkcloud baremetalmachine run-read-command` in the Cluster Manager Storage account

+ --commands '[{"command":"<command1>"},{"command":"<command2>","arguments":["<arg1>","<arg2>"]}]' \

+ --resource-group "<resourceGroupName>" \

+ --subscription "<subscription>"

+These commands don't require `arguments`:

+All other inputs are required.

+Multiple commands can be provided in json format to `--commands` option.

+For a command with multiple arguments, provide as a list to `arguments` parameter. See [Azure CLI Shorthand](https://github.com/Azure/azure-cli/blob/dev/doc/shorthand_syntax.md) for instructions on constructing the `--commands` structure.

+These commands can be long running so the recommendation is to set `--limit-time-seconds` to at least 600 seconds (10 minutes). Running multiple extracts might take longer that 10 minutes.

+This command runs synchronously. If you wish to skip waiting for the command to complete, specify the `--no-wait --debug` options. For more information, see [how to track asynchronous operations](howto-track-async-operations-cli.md).

+/home/priya/azure-docs-pr-pshet/articles/import-export

+When an optional argument `--output-directory` is provided, the output result is downloaded and extracted to the local directory.

+ --commands '[{"command":"hostname"],"arguments":["198.51.102.1","-c","3"]},{"command":"ping"}]' \

+ --subscription "<subscription>"

+Sample output looks something as below. It prints the top 4K characters of the result to the screen for convenience and provides a short-lived link to the storage blob containing the command execution result. You can use the link to download the zipped output file (tar.gz).

+ ====Action Command Output====

+ + hostname

+ rack1compute01

+ + ping 198.51.102.1 -c 3

+ PING 198.51.102.1 (198.51.102.1) 56(84) bytes of data.

+ 198.51.102.1 ping statistics

+ 3 packets transmitted, 0 received, 100% packet loss, time 2049ms

+ ================================

+ Script execution result can be found in storage account:

+ https://<storage_account_name>.blob.core.windows.net/bmm-run-command-output/a8e0a5fe-3279-46a8-b995-51f2f98a18dd-action-bmmrunreadcmd.tar.gz?se=2023-04-14T06%3A37%3A00Z&sig=XXX&sp=r&spr=https&sr=b&st=2023-04-14T02%3A37%3A00Z&sv=2019-12-12

+See [How To BareMetal Review Output Run-Read](howto-baremetal-review-read-output.md) for instructions on locating the output file in the Storage Account. You can also use the link to directly access the output zip file.

+Use the `az networkcloud clustermanager create` command to create a Cluster Manager. This command creates a new Cluster Manager or updates the properties of the Cluster Manager if it exists. If you have multiple Azure subscriptions, select the appropriate subscription ID using the [az account set](/cli/azure/account#az-account-set) command.

+Users can't control the behavior (enable or disable) for collection of these included standard metrics. Though, users can control the collection of some optional metrics that aren't part of the link to the list. To enable this experience, users have to create and update a MetricsConfiguration resource for a cluster. By default, creation of this MetricsConfiguration resource doesn't change the collection of metrics. User has to update the resource to enable or disable these optional metrics collection.

+> * Deletion of the MetricsConfiguration resource results in the standard set of metrics being restored.

+To support the lifecycle of cluster metrics configurations, the following interactions allow for the creation and management of a cluster's metrics configurations.

+Use the `az network cluster metricsconfiguration create` command to create metrics configuration for cluster. If you have multiple Azure subscriptions, select the appropriate subscription ID using the [az account set](/cli/azure/account#az-account-set) command.

+```azurecli

+az networkcloud cluster metricsconfiguration create \

+ --cluster-name "<CLUSTER>" \

+ --extended-location name="<CLUSTER_EXTENDED_LOCATION_ID>" type="CustomLocation" \

+ --location "<LOCATION>" \

+ --collection-interval <COLLECTION_INTERVAL (1-1440)> \

+ --enabled-metrics "<METRIC_TO_ENABLE_1>" "<METRIC_TO_ENABLE_2>" \

+ --tags <TAG_KEY1>="<TAG_VALUE1>" <TAG_KEY2>="<TAG_VALUE2>" \

+ --resource-group "<RESOURCE_GROUP>"

+```

+> * There can be only one set of metrics configuration defined per cluster. The resource is created with the name `default`.

+Specifying `--no-wait --debug` options in az cli command results in the execution of this command asynchronously. For more information, see [how to track asynchronous operations](howto-track-async-operations-cli.md).

+### Metrics configuration elements

+| Parameter name | Description |

+| --| -- |

+| CLUSTER | Resource Name of Cluster |

+| LOCATION | The Azure Region where the Cluster is deployed |

+| CLUSTER_EXTENDED_LOCATION_ID | The Cluster extended Location from Azure portal |

+| COLLECTION_INTERVAL | The collection frequency for default standard metrics |

+| RESOURCE_GROUP | The Cluster resource group name |

+| TAG_KEY1 | Optional tag1 to pass to Cluster create |

+| TAG_VALUE1 | Optional tag1 value to pass to Cluster Create |

+| TAG_KEY2 | Optional tag2 to pass to Cluster create |

+| TAG_VALUE2 | Optional tag2 value to pass to Cluster create |

+| METRIC_TO_ENABLE_1 | Optional metric1 that is enabled in addition to the default metrics |

+| METRIC_TO_ENABLE_2 | Optional metric2 that is enabled in addition to the default metrics |

+Specifying `--no-wait --debug` options in az cli command results in the execution of this command asynchronously. For more information, see [how to track asynchronous operations](howto-track-async-operations-cli.md).

+```azurecli

+az networkcloud cluster metricsconfiguration show \

+ --cluster-name "<CLUSTER>" \

+ --resource-group "<RESOURCE_GROUP>"

+This command returns a JSON representation of the metrics configuration.

+Much like the creation of a metrics configuration, an update can be performed to change the configuration or update the tags assigned to the metrics configuration.

+```azurecli

+az networkcloud cluster metricsconfiguration update \

+ --cluster-name "<CLUSTER>" \

+ --collection-interval <COLLECTION_INTERVAL (1-1440)> \

+ --enabled-metrics "<METRIC_TO_ENABLE_1>" "<METRIC_TO_ENABLE_2>" \

+ --tags <TAG_KEY1>="<TAG_VALUE1>" <TAG_KEY2>="<TAG_VALUE2>" \

+ --resource-group "<RESOURCE_GROUP>"

+The `collection-interval` can be updated independently of `enabled-metrics` list. Omit fields that aren't being changed.

+Specifying `--no-wait --debug` options in az cli command results in the execution of this command asynchronously. For more information, see [how to track asynchronous operations](howto-track-async-operations-cli.md).

+Deletion of the metrics configuration returns the cluster to an unaltered configuration. To delete a metrics configuration, use the below command:

+```azurecli

+az networkcloud cluster metricsconfiguration delete \

+ --cluster-name "<CLUSTER>" \

+ --resource-group "<RESOURCE_GROUP>"

+Specifying `--no-wait --debug` options in az cli command results in the execution of this command asynchronously. For more information, see [how to track asynchronous operations](howto-track-async-operations-cli.md).

+| LOCATION | The Azure Region where the Cluster is deployed |

+A successful Operator Nexus Cluster creation results in the creation of an AKS cluster

+The Cluster creation is complete when the `provisioningState` of the resource

+Once a Cluster has been created, the deploy cluster action can be triggered.

+The deploy Cluster action creates the bootstrap image and deploys the Cluster.

+Deploy Cluster initiates a sequence of events to occur in the Cluster Manager

+ --subscription "$SUBSCRIPTION_ID" \

+ --no-wait --debug

+This command runs synchronously. If you wish to skip waiting for the command to complete, specify the `--no-wait --debug` options. For more information, see [how to track asynchronous operations](howto-track-async-operations-cli.md).

+az networkcloud cluster show --resource-group "$CLUSTER_RG" \

+The Cluster deployment is complete when detailedStatus is set to `Running` and detailedStatusMessage shows message `Cluster is up and running`.

+export myHybridAksPluginType='****'

+Note: hybrid-aks-plugin-type: valid values are `OSDevice`, `SR-IOV`, `DPDK`. Default: `SR-IOV`

+--hybrid-aks-plugin-type "$myHybridAksPluginType" \

+--hybrid-aks-plugin-type "$myHybridAksPluginType" \

+--hybrid-aks-plugin-type "$myHybridAksPluginType" \

+--hybrid-aks-plugin-type "$myHybridAksPluginType" \

+> | PowerShell Gallery | 'onegetcdn.azureedge.net', 'psg-prod-centralus.azureedge.net', 'psg-prod-eastus.azureedge.net' | Setup of Windows based systems | See [PowerShell Gallery](/powershell/gallery/gallery/getting-started#network-access-to-the-powershell-gallery) |

+- One or more deployment virtual machines, which perform the infrastructure deployments using Terraform and performs the system configuration and SAP installation using Ansible playbooks.

+```terraform

+# The environment value is a mandatory field, it is used for partitioning the environments, for example (PROD and NP)

+environment = "MGMT"

+# The location/region value is a mandatory field, it is used to control where the resources are deployed

+location = "westeurope"

+# management_network_address_space is the address space for management virtual network

+management_network_address_space = "10.10.20.0/25"

+# management_subnet_address_prefix is the address prefix for the management subnet

+management_subnet_address_prefix = "10.10.20.64/28"

+# management_firewall_subnet_address_prefix is the address prefix for the firewall subnet

+management_firewall_subnet_address_prefix = "10.10.20.0/26"

+# management_bastion_subnet_address_prefix is a mandatory parameter if bastion is deployed and if the subnets are not defined in the workload or if existing subnets are not used

+management_bastion_subnet_address_prefix = "10.10.20.128/26"

+deployer_enable_public_ip = false

+firewall_deployment = true

+bastion_deployment = true

+If you system does not have the `Sources_by_SourceType` watchlist deployed, deploy the watchlist to your Microsoft Sentinel workspace from the Microsoft Sentinel [GitHub](https://aka.ms/DeployASimWatchlists) repository.

+If the Azure File Sync agent installation fails, locate the installation log file which is located in the agent installation directory. If the Azure File Sync agent is installed on the C: volume, the installation log file is located under C:\Program Files\Azure\StorageSyncAgent\InstallerLog.

+> [!Note]

+> If the Azure File Sync agent is installed from the command line and the /l\*v switch is used, the log file will be located in the path where the agent installation was executed.

+The log file name for agent installations using the MSI package is AfsAgentInstall. The log file name for agent installations using the MSP package (update package) is AfsUpdater.

+Once you have located the agent installation log file, open the file and search for the failure code at the end of the log. If you search for **error code 1603** or **sandbox**, you should be able to locate the error code.

+Here is a snippet from an agent installation that failed:

+CAQuietExec64: + CategoryInfo : SecurityError: (:) , PSSecurityException

+CAQuietExec64: + FullyQualifiedErrorId : UnauthorizedAccess

+CAQuietExec64: Error 0x80070001: Command line returned an error.

+CAQuietExec64: Error 0x80070001: QuietExec64 Failed

+CAQuietExec64: Error 0x80070001: Failed in ExecCommon64 method

+CustomAction SetRegPIIAclSettings returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

+Action ended 12:23:40: InstallExecute. Return value 3.

+MSI (s) (0C:C8) [12:23:40:994]: Note: 1: 2265 2: 3: -2147287035

+For this example, the agent installation failed with error code -2147287035 (ERROR_ACCESS_DENIED).

+CAQuietExec64: + CategoryInfo : SecurityError: (:) , PSSecurityException

+CAQuietExec64: + FullyQualifiedErrorId : UnauthorizedAccess

+CAQuietExec64: Error 0x80070001: Command line returned an error.

+CAQuietExec64: Error 0x80070001: QuietExec64 Failed

+CAQuietExec64: Error 0x80070001: Failed in ExecCommon64 method

+CustomAction SetRegPIIAclSettings returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

+Action ended 12:23:40: InstallExecute. Return value 3.

+MSI (s) (0C:C8) [12:23:40:994]: Note: 1: 2265 2: 3: -2147287035

+In the agent installation log, the following error is logged:

+```

+CAQuietExec64: Error 0x80070001: Command line returned an error.

+CAQuietExec64: Error 0x80070001: CAQuietExec64 Failed

+CustomAction InstallHFSRequiredWindowsFeatures returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

+Action ended 8:51:12: InstallExecute. Return value 3.

+MSI (s) (EC:B4) [08:51:12:439]: Note: 1: 2265 2: 3: -2147287035

+```

+This issue occurs if you try to install the sync agent on an Active Directory domain controller where the PDC role owner is on a Windows Server 2008 R2 or below OS version.

+This issue is expected if you create a cloud endpoint and use an Azure file share that contains data. The cloud change enumeration job that scans for changes in the Azure file share must complete before files can sync between the cloud and server endpoints. The time to complete the job is dependent on the size of the namespace in the Azure file share. The server endpoint health should update once the change enumeration job completes.

+To check the status of the cloud change enumeration job, go the Cloud Endpoint properties in the portal and the status is provided in the Change Enumeration section.

+This provisioning error protects you from deleting all content that might be available in an Azure file share. Server authoritative upload is a special mode to catch up a cloud location that was already seeded, with the updates from the server location. Review this [migration guide](../files/storage-files-migration-server-hybrid-databox.md) to understand the scenario for which this mode has been built.

+ File conflicts are created when the file in the Azure file share doesn't match the file in the server endpoint location (size and/or last modified time is different).

+

+ The following scenarios can cause file conflicts:

+ - A file is created or modified in an endpoint (for example, Server A). If the same file is modified on a different endpoint before the change on Server A is synced to that endpoint, a conflict file is created.

+ - The file existed in the Azure file share and server endpoint location prior to the server endpoint creation. If the file size and/or last modified time is different between the file on the server and Azure file share when the server endpoint is created, a conflict file is created.

+ - Sync database was recreated due to corruption or knowledge limit reached. Once the database is recreated, sync enters a mode called reconciliation. If the file size and/or last modified time is different between the file on the server and Azure file share when reconciliation occurs, a conflict file is created.

+

+The following table indicates which targets are soft, representing the Microsoft tested boundary, and hard, indicating an enforced maximum:

+## Azure File Sync performance metrics

+## Internal test results

+To help you plan your deployment for each of the stages (initial one-time provisioning and ongoing sync), below are the results observed during the internal testing on a system with the following configuration:

+### Initial one-time provisioning

+### Ongoing sync

+> [!NOTE]

+> After an OS disk is replaced through reimage or upgrade, the attached data disks may have their drive letters reassigned. To retain the same drive letters for attached disks, it is suggested to use a custom boot script.

+Once enrolled into the feature, scale set instances don't need to wait for specified timeout to expire before the instance is deleted. After receiving a Terminate notification, the instance can choose to be deleted at any time before the terminate timeout expires. Terminate notifications cannot be enabled on Spot instances. For more information on Spot instances, see [Azure Spot Virtual Machines for Virtual Machine Scale Sets](use-spot.md)