-Enable your Kubernetes cluster to pull images from your Azure Container Registry. If it's private, authentication will be required.

-To avoid having to set an imagePullSecret for every Pod, consider adding the imagePullSecret to the Service account in the `dev` and `stage` namespaces. See the [Kubernetes tutorial](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) for more information.

-Make sure to complete the following:

- * URL: https://github.com/Azure/arc-cicd-demo-src

- * Contains the example Azure Vote App that you will deploy using GitOps.

- * Import the repository with name `arc-cicd-demo-src`

- * URL: https://github.com/Azure/arc-cicd-demo-gitops

- * Works as a base for your cluster resources that house the Azure Vote App.

- * Import the repository with name `arc-cicd-demo-gitops`

-The CI/CD workflow will populate the manifest directory with extra manifests to deploy the app.

- --cluster-type managedClusters \

- * You can also check on Azure Portal page of your K8s cluster on `GitOps` tab a configuration `cluster-config` is created.

-Now that you've synced a GitOps connection, you'll need to import the CI/CD pipelines that create the manifests.

-The application repository contains a `.pipeline` folder with the pipelines you'll use for PRs, CI, and CD. Import and rename the three pipelines provided in the sample repository:

-During the CI process, you'll deploy your application containers to a registry. Start by creating an Azure service connection:

- * Name the service connection **arc-demo-acr**.

-4. Select the **Grant access permission to all pipelines**.

- * This option authorizes YAML pipeline files for service connections.

-### Configure PR Service Connection

-CD pipeline manipulates PRs in the GitOps repository. It needs a Service Connection for that:

- * Leave Username and Password blank

- * Name the service connection **azdo-pr-connection**.

-4. Select the **Grant access permission to all pipelines**.

- * This option authorizes YAML pipeline files for service connections.

-```console

- helm repo add gitops-connector https://azure.github.io/gitops-connector/

-```

-2. Install the connector to the cluster:

-```console

- helm upgrade -i gitops-connector gitops-connector/gitops-connector \

- --namespace flux-system \

- --set gitRepositoryType=AZDO \

- --set ciCdOrchestratorType=AZDO \

- --set gitOpsOperatorType=FLUX \

- --set azdoGitOpsRepoName=arc-cicd-demo-gitops \

- --set azdoOrgUrl=https://dev.azure.com/<Your organization>/<Your project> \

- --set gitOpsAppURL=https://dev.azure.com/<Your organization>/<Your project>/_git/arc-cicd-demo-gitops \

- --set orchestratorPAT=<Azure Repos PAT token>

-```

-> [!NOTE]

-> `Azure Repos PAT token` should have `Build: Read & execute` and `Code: Full` permissions.

-3. Configure Flux to send notifications to GitOps connector:

-```console

-cat <<EOF | kubectl apply -f -

-apiVersion: notification.toolkit.fluxcd.io/v1beta1

-kind: Alert

-metadata:

- name: gitops-connector

- namespace: flux-system

-spec:

- eventSeverity: info

- eventSources:

- - kind: GitRepository

- name: cluster-config

- - kind: Kustomization

- name: cluster-config-cluster-config

- providerRef:

- name: gitops-connector

-apiVersion: notification.toolkit.fluxcd.io/v1beta1

-kind: Provider

-metadata:

- name: gitops-connector

- namespace: flux-system

-spec:

- type: generic

- address: http://gitops-connector:8080/gitopsphase

-EOF

-```

-| SRC_FOLDER | `azure-vote` |

-In Azure DevOps project create `Dev` and `Stage` environments. See [Create and target an environment](/azure/devops/pipelines/process/environments) for more details.

-1. Select `Security`.

-1. Switch off `Protect access to repositories in YAML pipelines` option

- * Specific to GitOps, the pipeline also publishes the artifacts for the commit that will be deployed by the CD pipeline.

-During the initial CD pipeline run, you'll be asked to give the pipeline access to the GitOps repository. Select View when prompted that the pipeline needs permission to access a resource. Then, select Permit to grant permission to use the GitOps repository for the current and future runs of the pipeline.

-Once the template and manifest changes to the GitOps repository have been generated, the CD pipeline will create a commit, push it, and create a PR for approval.

-1. Monitor the Git Commit status on the Commit history tab. Once it is `succeeded` the CD pipeline will go ahead and start automated testing

-3. Commit the change in a new branch, push it, and create a pull request.

- * This is the typical developer flow that will start the CI/CD lifecycle.

-Errors found during linting range from:

-* Incorrectly formatted YAML files, to

-* Best practice suggestions, such as setting CPU and Memory limits for your application.

-Once the pipeline run has finished, you have assured the quality of the application code and the template that will deploy it. You can now approve and complete the PR. The CI will run again, regenerating the templates and manifests, before triggering the CD pipeline.

-> In a real environment, don't forget to set branch policies to ensure the PR passes your quality checks. For more information, see the [Set branch policies](/azure/devops/repos/git/branch-policies) article.

-1. Once the template and manifest changes to the GitOps repository have been generated, the CD pipeline will create a commit, push it, and create a PR for approval.

-Your deployment is now complete. This ends the CI/CD workflow. Refer to the [Azure DevOps GitOps Flow diagram](https://github.com/Azure/arc-cicd-demo-src/blob/master/docs/azdo-gitops.md) in the application repository that explains in details the steps and techniques implemented in the CI/CD pipelines used in this tutorial.

- * URL: https://github.com/Azure/arc-cicd-demo-src

- * Contains the example Azure Vote App that you will deploy using GitOps.

- * URL: https://github.com/Azure/arc-cicd-demo-gitops

- * Works as a base for your cluster resources that house the Azure Vote App.

-The CI/CD workflow will populate the manifest directory with extra manifests to deploy the app.

- --cluster-type managedClusters \

-```console

- helm repo add gitops-connector https://azure.github.io/gitops-connector/

-```

-2. Install the connector to the cluster:

-```console

- helm upgrade -i gitops-connector gitops-connector/gitops-connector \

- --namespace flux-system \

- --set gitRepositoryType=GITHUB \

- --set ciCdOrchestratorType=GITHUB \

- --set gitOpsOperatorType=FLUX \

- --set gitHubGitOpsRepoName=arc-cicd-demo-src \

- --set gitHubGitOpsManifestsRepoName=arc-cicd-demo-gitops \

- --set gitHubOrgUrl=https://api.github.com/repos/<Your organization> \

- --set gitOpsAppURL=https://github.com/<Your organization>/arc-cicd-demo-gitops/commit \

- --set orchestratorPAT=<GitHub PAT token>

-```

-3. Configure Flux to send notifications to GitOps connector:

-```console

-cat <<EOF | kubectl apply -f -

-apiVersion: notification.toolkit.fluxcd.io/v1beta1

-kind: Alert

-metadata:

- name: gitops-connector

- namespace: flux-system

-spec:

- eventSeverity: info

- eventSources:

- - kind: GitRepository

- name: cluster-config

- - kind: Kustomization

- name: cluster-config-cluster-config

- providerRef:

- name: gitops-connector

-apiVersion: notification.toolkit.fluxcd.io/v1beta1

-kind: Provider

-metadata:

- name: gitops-connector

- namespace: flux-system

-spec:

- type: generic

- address: http://gitops-connector:8080/gitopsphase

-EOF

-```

-2. Create `az-vote-app-stage` environment with the following secrets:

-To start the CI/CD Dev workflow change the source code. In the application repository, update values in `.azure-vote/src/azure-vote-front/config_file.cfg` file and push the changes to the repository.

- * Generates manifests to the GitOps repository

- * Creates a PR to the GitOps repository for approval

-

-1. Monitor the Git Commit status on the Commit history tab. Once it is `succeeded` the `CD Stage` workflow will start

- * Generates manifests to the GitOps repository

- * Creates a PR to the GitOps repository for approval

-Once the manifests PR to the Stage environment is merged and Flux successfully applied all the changes, it updates Git commit status in the GitOps repository.

-Your deployment is now complete. This ends the CI/CD workflow. Refer to the [GitHub GitOps Flow diagram](https://github.com/Azure/arc-cicd-demo-src/blob/master/docs/azdo-gitops-githubfluxv2.md) in the application repository that explains in details the steps and techniques implemented in the CI/CD workflows used in this tutorial.

- -t managedClusters --yes

-2. Delete GitOps Connector:

- The **Available signal types** for your selected resources are at the bottom right of the pane.

-1. Select **Include all future resources** to include any future resources added to the selected scope.

-1. Select **Done**.

-1. On the **Select a signal** pane, filter the list of signals by using the signal type and monitor service:

- - **Monitor service**: The service sending the signal. This list is pre-populated based on the type of alert rule you selected.

- |Signal type |Monitor service |Description |

-1. Select the **Signal name**, and follow the steps in the following tab that corresponds to the type of alert you're creating.

- If you select more than one dimension value, each time series that results from the combination will trigger its own alert and be charged separately. For example, the transactions metric of a storage account can have an API name dimension that contains the name of the API called by each transaction (for example, GetBlob, DeleteBlob, and PutPage). You can choose to have an alert fired when there's a high number of transactions in a specific API (the aggregated data). Or you can use dimensions to alert only when the number of transactions is high for specific APIs.

- |Operator|Select the operator for comparing the metric value against the threshold. <br>If you are using dynamic thresholds, alert rules can use tailored thresholds based on metric behavior for both upper and lower bounds in the same alert rule. Select one of these operators: <br> - Greater than the upper threshold or lower than the lower threshold (default) <br> - Greater than the upper threshold <br> - Lower than the lower threshold|

- |Lookback period|Select how far back to look each time the data is checked. For example, every 1 minute youΓÇÖll be looking at the past 5 minutes.|

- 1. (Optional) In the **Advanced options** section, you can specify how many failures within a specific time period will trigger the alert. For example, you can specify that you only want to trigger an alert if there were three failures in the last hour. This setting is defined by your application business policy.

- 1. On the **Logs** pane, write a query that will return the log events for which you want to create an alert.

- 1. (Optional) In the **Advanced options** section, you can specify the number of failures and the alert evaluation period required to trigger an alert. For example, if you set **Aggregation granularity** to 5 minutes, you can specify that you only want to trigger an alert if there were three failures (15 minutes) in the last hour. This setting is defined by your application business policy.

-1. On the **Review + create** tab, a validation will run and inform you of any issues.

-| Sev 4 | Verbose | Detailed information that isn't useful.

-description: Send guest OS metrics to the Azure Monitor metric database store by using a Resource Manager template for a Windows virtual machine

-# Send guest OS metrics to the Azure Monitor metric store by using an Azure Resource Manager template for a Windows virtual machine

-Performance data from the guest OS of Azure virtual machines is not collected automatically like other [platform metrics](./monitor-azure-resource.md#monitoring-data). Install the Azure Monitor [diagnostics extension](../agents/diagnostics-extension-overview.md) to collect guest OS metrics into the metrics database so it can be used with all features of Azure Monitor Metrics, including near-real time alerting, charting, routing, and access from a REST API. This article describes the process for sending Guest OS performance metrics for a Windows virtual machine to the metrics database using a Resource Manager template.

-> [!NOTE]

-> For details on configuring the diagnostics extension to collect guest OS metrics using the Azure portal, see [Install and configure Windows Azure diagnostics extension (WAD)](../agents/diagnostics-extension-windows-install.md).

-If you're new to Resource Manager templates, learn about [template deployments](../../azure-resource-manager/management/overview.md) and their structure and syntax.

-The Azure Diagnostics extension uses a feature called "data sinks" to route metrics and logs to different locations. The following steps show how to use a Resource Manager template and PowerShell to deploy a VM by using the new "Azure Monitor" data sink.

-## Author Resource Manager template

-For this example, you can use a publicly available sample template. The starting templates are at

-https://github.com/Azure/azure-quickstart-templates/tree/master/quickstarts/microsoft.compute/vm-simple-windows.

-Open the *azuredeploy.parameters.json* file

-1. Enter values for **adminUsername** and **adminPassword** for the VM. These parameters are used for remote access to the VM. To avoid having your VM hijacked, DO NOT use the values in this template. Bots scan the internet for user names and passwords in public GitHub repositories. They are likely to be testing VMs with these defaults.

-1. Create a unique dnsname for the VM.

-Open the *azuredeploy.json* file

-Add a storage account ID to the **variables** section of the template after the entry for **storageAccountName.**

-```json

-// Find these lines.

-"variables": {

- "storageAccountName": "[concat(uniquestring(resourceGroup().id), 'sawinvm')]",

-// Add this line directly below.

- "accountid": "[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))]",

-```

-Add this Managed Service Identity (MSI) extension to the template at the top of the **resources** section. The extension ensures that Azure Monitor accepts the metrics that are being emitted.

-```json

-//Find this code.

-"resources": [

-// Add this code directly below.

- "type": "Microsoft.Compute/virtualMachines/extensions",

- "name": "[concat(variables('vmName'), '/', 'WADExtensionSetup')]",

- "apiVersion": "2017-12-01",

- "[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]" ],

- "publisher": "Microsoft.ManagedIdentity",

- "type": "ManagedIdentityExtensionForWindows",

- "typeHandlerVersion": "1.0",

- "autoUpgradeMinorVersion": true,

- "settings": {

- "port": 50342

- }

- }

- },

-```

-Add the **identity** configuration to the VM resource to ensure that Azure assigns a system identity to the MSI extension. This step ensures that the VM can emit guest metrics about itself to Azure Monitor.

-```json

-// Find this section

- "subnet": {

- "id": "[variables('subnetRef')]"

- }

- }

- ]

-},

-{

- "apiVersion": "2017-03-30",

- "type": "Microsoft.Compute/virtualMachines",

- "name": "[variables('vmName')]",

- "location": "[resourceGroup().location]",

- // add these 3 lines below

- "identity": {

- "type": "SystemAssigned"

- //end of added lines

- "dependsOn": [

- "[resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]",

- "[resourceId('Microsoft.Network/networkInterfaces/', variables('nicName'))]"

- ],

- "properties": {

- "hardwareProfile": {

- ...

-```

-Add the following configuration to enable the Diagnostics extension on a Windows virtual machine. For a simple Resource Manager-based virtual machine, we can add the extension configuration to the resources array for the virtual machine. The line "sinks"&mdash; "AzMonSink" and the corresponding "SinksConfig" later in the section&mdash;enable the extension to emit metrics directly to Azure Monitor. Feel free to add or remove performance counters as needed.

-```json

- "networkProfile": {

- "networkInterfaces": [

- {

- "id": "[resourceId('Microsoft.Network/networkInterfaces',variables('nicName'))]"

- }

- ]

- },

-"diagnosticsProfile": {

- "bootDiagnostics": {

- "enabled": true,

- "storageUri": "[reference(resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))).primaryEndpoints.blob]"

- }

-}

-},

-//Start of section to add

-"resources": [

-{

- "type": "Microsoft.Compute/virtualMachines/extensions",

- "name": "[concat(variables('vmName'), '/', 'Microsoft.Insights.VMDiagnosticsSettings')]",

- "apiVersion": "2017-12-01",

- "location": "[resourceGroup().location]",

- "dependsOn": [

- "[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"

- ],

- "properties": {

- "publisher": "Microsoft.Azure.Diagnostics",

- "type": "IaaSDiagnostics",

- "typeHandlerVersion": "1.12",

- "autoUpgradeMinorVersion": true,

- "settings": {

- "WadCfg": {

- "DiagnosticMonitorConfiguration": {

- "overallQuotaInMB": 4096,

- "DiagnosticInfrastructureLogs": {

- "scheduledTransferLogLevelFilter": "Error"

- },

- "Directories": {

- "scheduledTransferPeriod": "PT1M",

- "IISLogs": {

- "containerName": "wad-iis-logfiles"

- },

- "FailedRequestLogs": {

- "containerName": "wad-failedrequestlogs"

- }

- },

- "PerformanceCounters": {

- "scheduledTransferPeriod": "PT1M",

- "sinks": "AzMonSink",

- "PerformanceCounterConfiguration": [

- {

- "counterSpecifier": "\\Memory\\Available Bytes",

- "sampleRate": "PT15S"

- {

- "counterSpecifier": "\\Memory\\% Committed Bytes In Use",

- "sampleRate": "PT15S"

- {

- "counterSpecifier": "\\Memory\\Committed Bytes",

- "sampleRate": "PT15S"

- ]

- "WindowsEventLog": {

- "scheduledTransferPeriod": "PT1M",

- "DataSource": [

- "name": "Application!*"

- ]

- },

- "Logs": {

- "scheduledTransferPeriod": "PT1M",

- "scheduledTransferLogLevelFilter": "Error"

- "SinksConfig": {

- "Sink": [

- {

- "name" : "AzMonSink",

- "AzureMonitor" : {}

- }

- ]

- },

- "StorageAccount": "[variables('storageAccountName')]"

- },

- "protectedSettings": {

- "storageAccountName": "[variables('storageAccountName')]",

- "storageAccountKey": "[listKeys(variables('accountid'),'2015-06-15').key1]",

- "storageAccountEndPoint": "https://core.windows.net/"

- }

- }

- ]

-//End of section to add

-```

-Save and close both files.

-## Deploy the Resource Manager template

-> You must be running the Azure Diagnostics extension version 1.5 or higher AND have the **autoUpgradeMinorVersion**: property set to ΓÇÿtrueΓÇÖ in your Resource Manager template. Azure then loads the proper extension when it starts the VM. If you don't have these settings in your template, change them and redeploy the template.

-To deploy the Resource Manager template, we leverage Azure PowerShell.

-1. Launch PowerShell.

-1. Log in to Azure using `Login-AzAccount`.

-1. Set the subscription that you're using to create/update the virtual machine in:

- > [!NOTE]

- > Remember to [use an Azure region that is enabled for custom metrics](./metrics-custom-overview.md).

-1. Run the following commands to deploy the VM using the Resource Manager template.

- > If you wish to update an existing VM, simply add *-Mode Incremental* to the end of the following command.

- > You might run into errors around the selected vmSkuSize. If this happens, go back to your azuredeploy.json file, and update the default value of the vmSkuSize parameter. In this case, we recommend trying "Standard_DS1_v2").

-1. Log in to the Azure portal.

-2. On the left menu, select **Monitor**.

-3. On the Monitor page, select **Metrics**.

- 

-4. Change the aggregation period to **Last 30 minutes**.

-5. In the resource drop-down menu, select the VM that you created. If you didn't change the name in the template, it should be *SimpleWinVM2*.

-6. In the namespaces drop-down menu, select **azure.vm.windows.guest**

-7. In the metrics drop down menu, select **Memory\%Committed Bytes in Use**.

-[Data Collection Rules (DCRs)](data-collection-rule-overview.md) determine how to collect and process telemetry sent to Azure. Some data collection rules will be created and managed by Azure Monitor, while you may create others to customize data collection for your particular requirements. This article describes the structure of DCRs for creating and editing data collection rules in those cases where you need to work with them directly.

-A DCR for [custom logs](../logs/logs-ingestion-api-overview.md) contains the sections below. For a sample, see [Sample data collection rule - custom logs](../logs/data-collection-rule-sample-custom-logs.md).

-This section contains the declaration of all the different types of data that will be sent via the HTTP endpoint directly into Log Analytics. Each stream is an object whose key represents the stream name (Must begin with *Custom-*) and whose value is the full list of top-level properties that the JSON data that will be sent will contain. Note that the shape of the data you send to the endpoint doesn't need to match that of the destination table. Rather, the output of the transform that is applied on top of the input data needs to match the destination shape. The possible data types that can be assigned to the properties are `string`, `int`, `long`, `real`, `boolean`, `dynamic`, and `datetime`.

-This section contains a declaration of all the destinations where the data will be sent. Only Log Analytics is currently supported as a destination. Each Log Analytics destination will require the full Workspace Resource ID, as well as a friendly name that will be used elsewhere in the DCR to refer to this workspace.

-This section ties the other sections together. Defines the following for each stream declared in the `streamDeclarations` section:

-## Azure Monitor agent

- A DCR for [Azure Monitor agent](../agents/data-collection-rule-azure-monitor-agent.md) contains the sections below. For a sample, see [Sample data collection rule - agent](../agents/data-collection-rule-sample-agent.md).

-Unique source of monitoring data with its own format and method of exposing its data. Examples of a data source include Windows event log, performance counters, and syslog. Each data source matches a particular data source type as described below.

-Each data source has a data source type. Each type defines a unique set of properties that must be specified for each data source. The data source types currently available are shown in the following table.

-### Streams

-Unique handle that describes a set of data sources that will be transformed and schematized as one type. Each data source requires one or more streams, and one stream may be used by multiple data sources. All data sources in a stream share a common schema. Use multiple streams for example, when you want to send a particular data source to multiple tables in the same Log Analytics workspace.

-Set of destinations where the data should be sent. Examples include Log Analytics workspace and Azure Monitor Metrics. Multiple destinations are allowed for multi-homing scenario.

-### dataFlows

-Definition of which streams should be sent to which destinations.

-Transformations in Azure Monitor allow you to filter or modify incoming data before it's sent to a Log Analytics workspace. This article provides a basic description of transformations and how they are implemented. It provides links to other content for actually creating a transformation.

-The following table describes the different goals that transformations can be used to achieve.

-| Remove sensitive data | You may have a data source that sends information you don't want stored for privacy or compliancy reasons.<br><br>**Filter sensitive information.** Filter out entire rows or just particular columns that contain sensitive information.<br><br>**Obfuscate sensitive information**. Replace information such as digits in an IP address or telephone number with a common character.<br><br>**Send to alternate table.** Send sensitive records to an alternate table with different RBAC configuration. |

-| Enrich data with additional or calculated information | Use a transformation to add information to data that provides business context or simplifies querying the data later.<br><br>**Add a column with additional information.** For example, you might add a column identifying whether an IP address in another column is internal or external.<br><br>**Add business specific information.** For example, you might add a column indicating a company division based on location information in other columns. |

-| Reduce data costs | Since you're charged ingestion cost for any data sent to a Log Analytics workspace, you want to filter out any data that you don't require to reduce your costs.<br><br>**Remove entire rows.** For example, you might have a diagnostic setting to collect resource logs from a particular resource but not require all of the log entries that it generates. Create a transformation that filters out records that match a certain criteria.<br><br>**Remove a column from each row.** For example, your data may include columns with data that's redundant or has minimal value. Create a transformation that filters out columns that aren't required.<br><br>**Parse important data from a column.** You may have a table with valuable data buried in a particular column. Use a transformation to parse the valuable data into a new column and remove the original.<br><br>**Send certain rows to basic logs.** Send rows in your data that require on basic query capabilities to basic logs tables for a lower ingestion cost. |

-Transformations may be applied to the following tables in a Log Analytics workspace.

-Transformations are performed in Azure Monitor in the [data ingestion pipeline](../essentials/data-collection.md) after the data source delivers the data and before it's sent to the destination. The data source may perform its own filtering before sending data but then rely on the transformation for further manipulation for it's sent to the destination.

-Transformations are defined in a [data collection rule (DCR)](data-collection-rule-overview.md) and use a [Kusto Query Language (KQL) statement](data-collection-transformations-structure.md) that is applied individually to each entry in the incoming data. It must understand the format of the incoming data and create output in the structure expected by the destination.

-For example, a DCR that collects data from a virtual machine using Azure Monitor agent would specify particular data to collect from the client operating system. It could also include a transformation that would get applied to that data after it's sent to the data ingestion pipeline that further filters the data or adds a calculated column. This workflow is shown in the following diagram.

-Another example is data sent from a custom application using the [logs ingestion API](../logs/logs-ingestion-api-overview.md). In this case, the application sends the data to a [data collection endpoint](data-collection-endpoint-overview.md) and specifies a data collection rule in the REST API call. The DCR includes the transformation and the destination workspace and table.

-The workspace transformation DCR is a special DCR that's applied directly to a Log Analytics workspace. It includes default transformations for one more [supported tables](../logs/tables-feature-support.md). These transformations are applied to any data sent to these tables unless that data came from another DCR.

-For example, if you create a transformation in the workspace transformation DCR for the `Event` table, it would be applied to events collected by virtual machines running the [Log Analytics agent](../agents/log-analytics-agent.md) since this agent doesn't use a DCR. The transformation would be ignored by any data sent from the [Azure Monitor agent](../agents/azure-monitor-agent-overview.md) though since it uses a DCR and would be expected to provide its own transformation.

-A common use of the workspace transformation DCR is collection of [resource logs](resource-logs.md) which are configured with a [diagnostic setting](diagnostic-settings.md). This is shown in the example below.

-Transformations allow you to send data to multiple destinations in a Log Analytics workspace using a single DCR. You provide a KQL query for each destination, and the results of each query are sent to their corresponding location. You can send different sets of data to different tables, or use multiple queries to send different sets of data to the same table.

-For example, you may send event data into Azure Monitor using the Logs ingestion API. Most of the events should be sent an analytics table where it could be queried regularly, while audit events should be sent to a custom table configured for [basic logs](../logs/basic-logs-configure.md) to reduce your cost.

-To use multiple destinations, you must currently either manually create a new DCR or [edit an existing one](data-collection-rule-edit.md). See the [Samples](#samples) section for examples of DCRs using multiple destinations.

-## Creating a transformation

-There are multiple methods to create transformations depending on the data collection method. The following table lists guidance for different methods for creating transformations.

-| Logs ingestion API with transformation | [Send data to Azure Monitor Logs using REST API (Azure portal)](../logs/tutorial-logs-ingestion-portal.md)<br>[Send data to Azure Monitor Logs using REST API (Resource Manager templates)](../logs/tutorial-logs-ingestion-api.md) |

-| Transformation in workspace DCR | [Add workspace transformation to Azure Monitor Logs using the Azure portal](../logs/tutorial-workspace-transformations-portal.md)<br>[Add workspace transformation to Azure Monitor Logs using Resource Manager templates](../logs/tutorial-workspace-transformations-api.md)

-There is no direct cost for transformations, but you may incur charges for the following:

-The formula to determine the filter ingestion charge from transformations is `[GB filtered out by transformations] - ( [Total GB ingested] / 2 )`. For example, suppose that you ingest 100 GB on a particular day, and transformations remove 70 GB. You would be charged for 70 GB - (100 GB / 2) or 20 GB. To avoid this charge, you should use other methods to filter incoming data before the transformation is applied.

-> If Azure Sentinel is enabled for the Log Analytics workspace, then there is no filtering ingestion charge regardless of how much data the transformation filters.

-Following are Resource Manager templates of sample DCRs with different patterns. You can use these templates as a starting point to creating DCRs with transformations for your own scenarios.

-The following example is a DCR for Azure Monitor agent that sends data to the `Syslog` table. In this example, the transformation filters the data for records with *error* in the message.

-The following example is a DCR for data from Logs Ingestion API that sends data to both the `Syslog` and `SecurityEvent` table. This requires a separate `dataFlow` for each with a different `transformKql` and `OutputStream` for each. In this example, all incoming data is sent to the `Syslog` table while malicious data is also sent to the `SecurityEvent` table. If you didn't want to replicate the malicious data in both tables, you could add a `where` statement to first query to remove those records.

-The following example is a DCR for data from Logs Ingestion API that sends data to both the `Syslog` table and a custom table with the data in a different format. This requires a separate `dataFlow` for each with a different `transformKql` and `OutputStream` for each.

-description: Send custom metrics for an Azure resource to the Azure Monitor metric store by using a REST API

-# Send custom metrics for an Azure resource to the Azure Monitor metric store by using a REST API

-This article shows you how to send custom metrics for Azure resources to the Azure Monitor metrics store via a REST API. When the metrics are in Azure Monitor, you can do all the things with them that you do with standard metrics. For example, charting, alerting, and routing them to other external tools.

->[!NOTE]

->The REST API only permits sending custom metrics for Azure resources.

-To send metrics for resources in other environments or on-premises, use [Application Insights](../app/api-custom-events-metrics.md).

-## Create and authorize a service principal to emit metrics

-A service principal is an application whose tokens can be used to authenticate and grant access to specific Azure resources using Azure Active Directory. This includes user-apps, services or automation tools.

-1. Save the tenant ID, new client ID, and client secret value for your app to use when requesting a token.

-1. Give the app created as part of the previous step **Monitoring Metrics Publisher** permissions to the resource you wish to emit metrics against. If you plan to use the app to emit custom metrics against many resources, you can grant these permissions at the resource group or subscription level.

-

- On your resource's overview page, select **Access Control (IAM)**

-1. Select **Add**, then **Add role assignment** from the dropdown.

- :::image type="content" source="./media/metrics-store-custom-rest-api/access-contol-add-role-assignment.png" alt-text="A screenshot showing the Access control(IAM) page for a virtual machine.":::

-1. Search for *Monitoring Metrics* in the search field.

- :::image type="content" source="./media/metrics-store-custom-rest-api/add-role-assignment.png" alt-text="A screenshot showing the add role assignment page.":::

-1. Search for your app in the **Select** field.

- :::image type="content" source="./media/metrics-store-custom-rest-api/select-members.png" alt-text="A screenshot showing the members tab of the role assignment page.":::

-Send the following request in the command prompt or using a client like Postman.

-The response body appears as follows:

-1. Paste the following JSON into a file, and save it asΓÇ»**custommetric.json** on your local computer. Update the time parameter so that it is within the last 20 minutes. You can't put a metric into the store that's over 20 minutes old. The metric store is optimized for alerting and real-time charting.

-1. Submit the following HTTP POST request using the following variables:

- - **resourceId**: Resource ID of the Azure resource you're tracking the metric against.

- - **accessToken**: The authorization token acquired from the previous step.

-1. Change the timestamp and values in the JSON file.

-1. Repeat the previous two steps a number of times, to create data for several minutes.

-1. In the left-hand menu, select **Monitor**.

- 

-1. Change the aggregation period to **Last hour**.

-1. In the **Scope** drop-down menu, select the resource you send the metric for.

-1. In the **Metric namespace** drop-down menu, select **QueueProcessing**.

-1. In the **Metric** drop-down menu, select **QueueDepth**.

-description: Learn how to configure diagnostic settings to send resource logs from an Azure resource io a Log Analytics workspace where they can be analyzed with a log query.

-> * Create a Log Analytics workspace in Azure Monitor

-> * Create a diagnostic setting to collect resource logs

-> * Create a simple log query to analyze logs

-To complete the steps in this tutorial, you need the following:

-> This procedure does not apply to Azure virtual machines since their **Diagnostic settings** menu is used to configure the diagnostic extension.

-[Diagnostic settings](../essentials/diagnostic-settings.md) define where resource logs should be sent for a particular resource. A single diagnostic setting can have multiple [destinations](../essentials/diagnostic-settings.md#destinations), but we'll only use a Log Analytics workspace in this tutorial.

-Under the **Monitoring** section of your resource's menu, select **Diagnostic settings** and click **Add diagnostic setting**.

-> Some resource may require additional selections. For example, a storage account requires you to select a resource before the **Add diagnostic setting** option is displayed. You may also notice a **Preview** label for some resources as their diagnostic settings are currently in public preview.

-

- - **Name**: This has no significant effect and should simply be descriptive to you.

- - **Categories**: Categories of logs to send to each of the destinations. The set of categories will vary for each Azure service.

- - **Destinations**: One or more destinations to send the logs. All Azure services share the same set of possible destinations. Each diagnostic setting can define one or more destinations but no more than one destination of a particular type.

-Enter a name for the diagnostic setting and select the categories that you want to collect. See the documentation for each service for a definition of its available categories. **AllMetrics** will send that same platform metrics available in Azure Monitor Metrics for the resource to the workspace. This allows you to analyze this data with log queries along with other monitoring data. Select **Send to Log Analytics workspace** and then select the workspace that you created.

-Click **Save** to save the diagnostic settings.

-

-

-Data is retrieved from a Log Analytics workspace using a log query written in Kusto Query Language (KQL). A set of precreated queries is available for many Azure services so that you don't require knowledge of KQL to get started.

-Select **Logs** from your resource's menu. Log Analytics opens with the **Queries** window that includes prebuilt queries for your **Resource type**.

-> If the **Queries** window doesn't open, click **Queries** in the top right.

-Browse through the available queries. Identify one to run and click **Run**. The query is added to the query window and the results returned.

- | Firewalls | [AZFWNetworkRule](/azure/azure-monitor/reference/tables/AZFWNetworkRule) |

- | Storage Mover | [StorageMoverJobRunLogs](/azure/azure-monitor/reference/tables/StorageMoverJobRunLogs) |

-1. **The Activity Log**: The [Azure Activity Log](../azure-monitor/essentials/activity-log.md) has a record of all create, update, and delete operations in a subscription, including Chaos Studio operations like enabling a target and/or capabilities, installing the agent, and creating or running an experiment. Failures in the Activity Log indicate that a user action essential to using Chaos Studio may have failed to complete. Most service-direct faults also inject faults by executing an Azure Resource Manager operation, so the Activity Log will also have the record of faults being injected during an experiment for some service-direct faults.

-2. **Experiment Details**: Experiment execution details show the status and errors of an individual experiment run. Opening a specific fault in experiment details will show the resources that failed and the error messages for a failure. [Learn more about how to access experiment details](chaos-studio-run-experiment.md#view-experiment-history-and-details).

- * **Chaos Windows agent**: Agent logs are located in the Windows Event Log in the Application category with the source AzureChaosAgent. The agent adds fault activity and regular health check (ability to authenticate to and communicate with the Chaos Studio agent service) events to this log.

-4. **VM extension status**: If using an agent-based fault, you may also need to verify that the VM extension is installed and healthy. In the Azure portal, navigate to your virtual machine and go to **Extensions** or **Extensions + applications**. Click on the ChaosAgent extension and look for the following fields:

- * **Status** should show "Provisioning succeeded." Any other status indicates that the agent failed to install. Verify that all [system requirements](chaos-studio-limitations.md#limitations) are met and try re-installing the agent.

- * **Handler status** should show "Ready." Any other status indicates that the agent installed but cannot connect to the Chaos Studio service. Verify that all [network requirements](chaos-studio-limitations.md#limitations) are met and that the user-assigned managed identity has been added to the virtual machine and try rebooting.

-### Resources do not show up in the targets list in the Azure portal

-If you do not see the resources you would like to enable in the Chaos Studio targets list, it may be due to any of the following issues:

-* The resources are not in [a supported region for Chaos Studio](https://azure.microsoft.com/global-infrastructure/services/?products=chaos-studio).

-* The resources are not of [a supported resource type in Chaos Studio](chaos-studio-fault-providers.md).

-* The resources are in a subscription or resource group that are filtered out in the filters for the target list. Change the subscription and resource group filters to see your resources.

-1. Verify that you have appropriate permissions to the resources you are onboarding. Enabling a target and/or capabilities requires Microsoft.Chaos/\* permission at the scope of the resource. Built-in roles such as Contributor have wildcard Read and Write permission, which includes permission to all Microsoft.Chaos operations.

- 1. Click the **Manage actions** button on the resource in the targets list. Check any capabilities that were not checked, and click **Save**.

-Agent-based faults may fail for a variety of reasons related to missing prerequisites:

-* On either Linux or Windows VMs, the system-assigned managed identity for the experiment must be granted Reader role on the VM (seemingly elevated roles like Virtual Machine Contributor do not include the \*/Read operation that is necessary for the Chaos Studio agent service to read the microsoft-agent target proxy resource on the virtual machine).

-AKS Chaos Mesh faults may fail for a variety of reasons related to missing prerequisites:

-* Chaos Mesh must be installed with the namespace `chaos-testing`. Other namespace names for Chaos Mesh are not supported.

-### When adding a fault, my resource does not show in the Target Resources list

-When adding a fault, if you do not see the resource you want to target with a fault in the Target Resources list, it may be due to any of the following issues:

-* The resource doesn't have the capability for that fault enabled yet. Consult the [fault library](chaos-studio-fault-library.md) to see the capability name for the fault, then visit the **Targets** view and click **Manage actions** on the target resource. Check the box for the capability that corresponds to the fault you are trying to run and click **Save**. After this completes, you need to close the Add Fault pane and reopen it to see an updated target list.

-### When creating an experiment, I get the error `The microsoft:agent provider requires a managed identity`

-This error happens when the agent has not been deployed to your virtual machine. For installation instructions, see [Create and run an experiment that uses agent-based faults](chaos-studio-tutorial-agent-based-portal.md).

-You may encounter this error if you are creating your experiment using an ARM template or the Chaos Studio REST API. The error indicates that there is malformed JSON in your experiment definition. Check to see if you have any syntax errors, such as mismatched braces or brackets ({} and \[\]), using a JSON linter like Visual Studio Code.

-This may happen if you onboarded the agent using the Azure portal, which has a known issue: Enabling an agent-based target does not assign the user-assigned managed identity to the virtual machine or virtual machine scale set.

-To resolve this, navigate to the virtual machine or virtual machine scale set in the Azure portal, go to **Identity**, open the **User assigned** tab, and **Add** your user-assigned identity to the virtual machine. Once complete, you may need to reboot the virtual machine for the agent to connect.

-* Speech SDK 1.25.0 was released in January 2023.

-description: Overview about connectors in Azure Logic Apps.

-# About connectors in Azure Logic Apps

-When you build workflows using Azure Logic Apps, you can use *connectors* to help you quickly and easily access data, events, and resources in other apps, services, systems, protocols, and platforms - often without writing any code. A connector provides prebuilt operations that you can use as steps in your workflows. Azure Logic Apps provides hundreds of connectors that you can use. If no connector is available for the resource that you want to access, you can use the generic HTTP operation to communicate with the service, or you can [create a custom connector](#custom-connectors-and-apis).

-This overview provides a high-level introduction to connectors and how they generally work.

-## What are connectors?

-Technically, many connectors provide a proxy or a wrapper around an API that the underlying service uses to communicate with Azure Logic Apps. This connector provides operations that you use in your workflows to perform tasks. An operation is available either as a *trigger* or *action* with properties you can configure. Some triggers and actions also require that you first [create and configure a connection](#connection-configuration) to the underlying service or system, for example, so that you can authenticate access to a user account. For more overview information, review [Connectors overview for Azure Logic Apps, Microsoft Power Automate, and Microsoft Power Apps](/connectors).

- For information about the more popular and commonly used connectors in Azure Logic Apps, review the following documentation:

-* [Connectors reference for Azure Logic Apps](/connectors/connector-reference/connector-reference-logicapps-connectors)

-* [Built-in connectors for Azure Logic Apps](built-in.md)

-* [Managed connectors in Azure Logic Apps](managed.md)

-* [Pricing and billing models in Azure Logic Apps](../logic-apps/logic-apps-pricing.md)

-* [Azure Logic Apps pricing details](https://azure.microsoft.com/pricing/details/logic-apps/)

-### Triggers

-A *trigger* specifies the event that starts the workflow and is always the first step in any workflow. Each trigger also follows a specific firing pattern that controls how the trigger monitors and responds to events. Usually, a trigger follows the *polling* pattern or *push* pattern, but sometimes, a trigger is available in both versions.

-For example, you might want to build a workflow that does something when a file is uploaded to your FTP server. As the first step in your workflow, you can use the FTP trigger named **When a file is added or modified**, which follows the polling pattern. You can then specify a schedule to regularly check for upload events.

-A trigger also passes along any inputs and other required data into your workflow where later actions can reference and use that data throughout the workflow. For example, suppose you want to use Office 365 Outlook trigger named **When a new email arrives** to start a workflow when you get a new email. You can configure this trigger to pass along the content from each new email, such as the sender, subject line, body, attachments, and so on. Your workflow can then process that information by using other actions.

-### Actions

-An *action* is an operation that follows the trigger and performs some kind of task in your workflow. You can use multiple actions in your workflow. For example, you might start the workflow with a SQL trigger that detects new customer data in an SQL database. Following the trigger, your workflow can have a SQL action that gets the customer data. Following the SQL action, your workflow can have a different action that processes the data.

-## Connector categories

-In Azure Logic Apps, most triggers and actions are available in either a *built-in* version or *managed connector* version. A few triggers and actions are available in both versions. The versions available depend on whether you create a *Consumption* logic app that runs in multi-tenant Azure Logic Apps, or a *Standard* logic app that runs in single-tenant Azure Logic Apps.

-* [Built-in connectors](built-in.md) run natively on the Azure Logic Apps runtime.

-* [Managed connectors](managed.md) are deployed, hosted, and managed by Microsoft. These connectors provide triggers and actions for cloud services, on-premises systems, or both.

- In a *Standard* logic app, all managed connectors are organized as **Azure** connectors. However, in a *Consumption* logic app, managed connectors are organized as **Standard** or **Enterprise**, based on pricing level.

-For more information about logic app types, review [Resource types and host environment differences](../logic-apps/logic-apps-overview.md#resource-environment-differences).

-## Connection configuration

-In Consumption logic apps, before you can create or manage logic apps and their connections, you need specific permissions. For more information about these permissions, review [Secure operations - Secure access and data in Azure Logic Apps](../logic-apps/logic-apps-securing-a-logic-app.md#secure-operations).

-Before you can use a managed connector's triggers or actions in your workflow, many connectors require that you first create a *connection* to the target service or system. To create a connection from within the logic app workflow designer, you have to authenticate your identity with account credentials and sometimes other connection information. For example, before your workflow can access and work with your Office 365 Outlook email account, you must authorize a connection to that account. For some built-in connectors and managed connectors, you can [set up and use a managed identity for authentication](../logic-apps/create-managed-service-identity.md#triggers-actions-managed-identity), rather than provide your credentials.

-Although you create connections within a workflow, these connections are actually separate Azure resources with their own resource definitions. To review these connection resource definitions, follow these steps based on whether you have a Consumption or Standard logic app:

-* Consumption: To view these connections in the Azure portal, review [View connections for Consumption logic apps in the Azure portal](../logic-apps/manage-logic-apps-with-azure-portal.md#view-connections).

- To view and manage these connections in Visual Studio, review [Manage Consumption logic apps with Visual Studio](../logic-apps/manage-logic-apps-with-visual-studio.md), and download your logic app from Azure into Visual Studio. For more information about connection resource definitions for Consumption logic apps, review [Connection resource definitions](../logic-apps/logic-apps-azure-resource-manager-templates-overview.md#connection-resource-definitions).

-* Standard: To view these connections in the Azure portal, review [View connections for Standard logic apps in the Azure portal](../logic-apps/create-single-tenant-workflows-azure-portal.md#view-connections).

- To view and manage these connections in Visual Studio Code, review [View your logic app in Visual Studio Code](../logic-apps/create-single-tenant-workflows-visual-studio-code.md#manage-deployed-apps-vs-code). The **connections.json** file contains the required configuration for the connections created by connectors.

-> [!TIP]

-For more information about securing logic apps and connections, review [Secure access and data in Azure Logic Apps](../logic-apps/logic-apps-securing-a-logic-app.md).

-If you use a firewall that limits traffic, and your logic app workflows need to communicate through that firewall, you have to set up your firewall to allow access for both the [inbound](../logic-apps/logic-apps-limits-and-config.md#inbound) and [outbound](../logic-apps/logic-apps-limits-and-config.md#outbound) IP addresses used by the Azure Logic Apps platform or runtime in the Azure region where your logic app workflows exist. If your workflows also use managed connectors, such as the Office 365 Outlook connector or SQL connector, or use custom connectors, your firewall also needs to allow access for *all* the [managed connector outbound IP addresses](/connectors/common/outbound-ip-addresses#azure-logic-apps) in your logic app's Azure region. For more information, review [Firewall configuration](../logic-apps/logic-apps-limits-and-config.md#firewall-configuration-ip-addresses-and-service-tags).

-In Consumption logic apps that run in multi-tenant Azure Logic Apps, you can call Swagger-based or SOAP-based APIs that aren't available as out-of-the-box connectors. You can also run custom code by creating custom API Apps. For more information, review the following documentation:

-* [Swagger-based or SOAP-based custom connectors for Consumption logic apps](../logic-apps/custom-connector-overview.md#custom-connector-consumption)

-* Create a [Swagger-based](/connectors/custom-connectors/define-openapi-definition) or [SOAP-based](/connectors/custom-connectors/create-register-logic-apps-soap-connector) custom connector, which makes these APIs available to any Consumption logic app in your Azure subscription. To make your custom connector public for anyone to use in Azure, [submit your connector for Microsoft certification](/connectors/custom-connectors/submit-certification).

-In Standard logic apps that run in single-tenant Azure Logic Apps, you can create natively running service provider-based custom built-in connectors that are available to any Standard logic app. For more information, review the following documentation:

-* [Service provider-based custom built-in connectors for Standard logic apps](../logic-apps/custom-connector-overview.md#custom-connector-standard)

-* [Create service provider-based custom built-in connectors for Standard logic apps](../logic-apps/create-custom-built-in-connector-standard.md)

-For workflows that need direct access to resources in an Azure virtual network, you can create a dedicated [integration service environment (ISE)](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md) where you can build, deploy, and run your workflows on dedicated resources. For more information about creating ISEs, review [Connect to Azure virtual networks from Azure Logic Apps](../logic-apps/connect-virtual-network-vnet-isolated-environment.md).

-Custom connectors created within an ISE don't work with the on-premises data gateway. However, these connectors can directly access on-premises data sources that are connected to an Azure virtual network hosting the ISE. So, logic apps in an ISE most likely don't need the data gateway when communicating with those resources. If you have custom connectors that you created outside an ISE that require the on-premises data gateway, logic apps in an ISE can use those connectors.

-In the workflow designer, when you browse the built-in connectors or managed connectors that you want to use for logic apps in an ISE, the **CORE** label appears on built-in connectors, while the **ISE** label appears on managed connectors that are designed to work with an ISE.

- Built-in connectors with this label run in the same ISE as your logic apps.

- Managed connectors with this label run in the same ISE as your logic apps.

-The following table includes known issues for Logic Apps connectors.

-| `Error: BadGateway. Client request id: '{GUID}'` | This error results from updating the tags on a logic app where one or more connections don't support Azure Active Directory (Azure AD) OAuth authentication, such as SFTP ad SQL, breaking those connections. | To prevent this behavior, avoid updating those tags. |

-||||

-> [Create custom APIs you can call from Logic Apps](../logic-apps/logic-apps-create-api-app.md)

-> Azure Cosmos DB also supports a Lazy indexing mode. Lazy indexing performs updates to the index at a much lower priority level when the engine is not doing any other work. This can result in **inconsistent or incomplete** query results. If you plan to query an Azure Cosmos DB container, you should not select lazy indexing. New containers cannot select lazy indexing. You can request an exemption by contacting cosmoslazyindexing@microsoft.com (except if you are using an Azure Cosmos DB account in [serverless](serverless.md) mode which doesn't support lazy indexing).

-description: Learn how to define stored procedures, triggers, and user-defined functions in Azure Cosmos DB

-Azure Cosmos DB provides language-integrated, transactional execution of JavaScript that lets you write **stored procedures**, **triggers**, and **user-defined functions (UDFs)**. When using the API for NoSQL in Azure Cosmos DB, you can define the stored procedures, triggers, and UDFs in JavaScript language. You can write your logic in JavaScript and execute it inside the database engine. You can create and execute triggers, stored procedures, and UDFs by using [Azure portal](https://portal.azure.com/), the [JavaScript language integrated query API in Azure Cosmos DB](javascript-query-api.md) and the [Azure Cosmos DB for NoSQL client SDKs](samples-dotnet.md).

-To call a stored procedure, trigger, and user-defined function, you need to register it. For more information, see [How to work with stored procedures, triggers, user-defined functions in Azure Cosmos DB](how-to-use-stored-procedures-triggers-udfs.md).

-> For partitioned containers, when executing a stored procedure, a partition key value must be provided in the request options. Stored procedures are always scoped to a partition key. Items that have a different partition key value will not be visible to the stored procedure. This also applied to triggers as well.

-> Server-side JavaScript features including stored procedures, triggers, and user-defined functions do not support importing modules.

-> Azure Cosmos DB supports deploying containers with stored procedures, triggers and user-defined functions. For more information see [Create an Azure Cosmos DB container with server-side functionality.](./manage-with-templates.md#create-sproc)

-Stored procedures are written using JavaScript, they can create, update, read, query, and delete items inside an Azure Cosmos DB container. Stored procedures are registered per collection, and can operate on any document or an attachment present in that collection.

-> [Note]

-> When it comes to stored procedure, Cosmos DB has different charging policy. Since, stored can essentially execute code and consume any number of RUs, we do upfront charging for each stored procedure execution. This is a defense mechanism in backend to ensure stored procedure scripts do not impact out backend services. The amount which is charged upfront is the average charge consumed by the script in previous invocations. If the stored procedure has varied RUs per invocation i.e., lot of variance around the mean then the client may not be able to fully utilize the budget as we always reserve the average RU per operations before we start the execution. As an alternative we would suggest the client to use batch or bulk requests instead of stored procedures to avoid the variance around the RU charging.

->

-Here is a simple stored procedure that returns a "Hello World" response.

-Once written, the stored procedure must be registered with a collection. To learn more, see [How to use stored procedures in Azure Cosmos DB](how-to-use-stored-procedures-triggers-udfs.md#how-to-run-stored-procedures) article.

-### <a id="create-an-item"></a>Create an item using stored procedure

-When you create an item by using stored procedure, the item is inserted into the Azure Cosmos DB container and an ID for the newly created item is returned. Creating an item is an asynchronous operation and depends on the JavaScript callback functions. The callback function has two parameters - one for the error object in case the operation fails and another for a return value; in this case, the created object. Inside the callback, you can either handle the exception or throw an error. In case a callback is not provided and there is an error, the Azure Cosmos DB runtime will throw an error.

-The stored procedure also includes a parameter to set the description, it's a boolean value. When the parameter is set to true and the description is missing, the stored procedure will throw an exception. Otherwise, the rest of the stored procedure continues to run.

-The following example stored procedure takes an array of new Azure Cosmos DB items as input, inserts it into the Azure Cosmos DB container and returns the count of the items inserted. In this example, we are leveraging the ToDoList sample from the [Quickstart .NET API for NoSQL](quickstart-dotnet.md)

-When defining a stored procedure in Azure portal, input parameters are always sent as a string to the stored procedure. Even if you pass an array of strings as an input, the array is converted to string and sent to the stored procedure. To work around this, you can define a function within your stored procedure to parse the string as an array. The following code shows how to parse a string input parameter as an array:

-You can implement transactions on items within a container by using a stored procedure. The following example uses transactions within a fantasy football gaming app to trade players between two teams in a single operation. The stored procedure attempts to read the two Azure Cosmos DB items each corresponding to the player IDs passed in as an argument. If both players are found, then the stored procedure updates the items by swapping their teams. If any errors are encountered along the way, the stored procedure throws a JavaScript exception that implicitly aborts the transaction.

-### <a id="async-promises"></a>Async await with stored procedures

-The following is an example of a stored procedure that uses async-await with Promises using a helper function. The stored procedure queries for an item and replaces it.

-Azure Cosmos DB supports pre-triggers and post-triggers. Pre-triggers are executed before modifying a database item and post-triggers are executed after modifying a database item. Triggers are not automatically executed, they must be specified for each database operation where you want them to execute. After you define a trigger, you should [register and call a pre-trigger](how-to-use-stored-procedures-triggers-udfs.md#how-to-run-pre-triggers) by using the Azure Cosmos DB SDKs.

-The following example shows how a pre-trigger is used to validate the properties of an Azure Cosmos DB item that is being created. In this example, we are leveraging the ToDoList sample from the [Quickstart .NET API for NoSQL](quickstart-dotnet.md), to add a timestamp property to a newly added item if it doesn't contain one.

-Pre-triggers cannot have any input parameters. The request object in the trigger is used to manipulate the request message associated with the operation. In the previous example, the pre-trigger is run when creating an Azure Cosmos DB item, and the request message body contains the item to be created in JSON format.

-When triggers are registered, you can specify the operations that it can run with. This trigger should be created with a `TriggerOperation` value of `TriggerOperation.Create`, which means using the trigger in a replace operation as shown in the following code is not permitted.

-For examples of how to register and call a pre-trigger, see [pre-triggers](how-to-use-stored-procedures-triggers-udfs.md#how-to-run-pre-triggers) and [post-triggers](how-to-use-stored-procedures-triggers-udfs.md#how-to-run-post-triggers) articles.

-One thing that is important to note is the transactional execution of triggers in Azure Cosmos DB. The post-trigger runs as part of the same transaction for the underlying item itself. An exception during the post-trigger execution will fail the whole transaction. Anything committed will be rolled back and an exception returned.

-For examples of how to register and call a pre-trigger, see [pre-triggers](how-to-use-stored-procedures-triggers-udfs.md#how-to-run-pre-triggers) and [post-triggers](how-to-use-stored-procedures-triggers-udfs.md#how-to-run-post-triggers) articles.

-The following sample creates a UDF to calculate income tax for various income brackets. This user-defined function would then be used inside a query. For the purposes of this example assume there is a container called "Incomes" with properties as follows:

- "name": "Satya Nadella",

-The following is a function definition to calculate income tax for various income brackets:

-For examples of how to register and use a user-defined function, see [How to use user-defined functions in Azure Cosmos DB](how-to-use-stored-procedures-triggers-udfs.md#how-to-work-with-user-defined-functions) article.

-When using stored procedure, triggers or user-defined functions, you can log the steps by enabling the script logging. A string for debugging is generated when `EnableScriptLogging` is set to true as shown in the following examples:

-Learn more concepts and how-to write or use stored procedures, triggers, and user-defined functions in Azure Cosmos DB:

-* [How to register and use stored procedures, triggers, and user-defined functions in Azure Cosmos DB](how-to-use-stored-procedures-triggers-udfs.md)

-* [Working with Azure Cosmos DB stored procedures, triggers, and user-defined functions in Azure Cosmos DB](stored-procedures-triggers-udfs.md)

-EASM collects data for publicly exposed assets (ΓÇ£outside-inΓÇ¥). That data can be used by MDC CSPM (ΓÇ£inside-outΓÇ¥) to assist with internet-exposure validation and discovery capabilities to provide better visibility to customers.

-| [Code pipeline insights](defender-for-devops-introduction.md) | Empowers security teams with the ability to protect applications and resources from code to cloud across multi-pipeline environments, including GitHub and Azure DevOps. Findings from Defender for DevOps, such as IaaC misconfigurations and exposed secrets, can then be correlated with other contextual cloud security insights to prioritize remediation in code. | Connect [Azure DevOps](quickstart-onboard-devops.md) and [GitHub](quickstart-onboard-github.md) repositories to Defender for Cloud | [Defender for DevOps](https://azure.microsoft.com/pricing/details/defender-for-cloud/) |

-> [New AWS Connector in Microsoft Defender for Cloud](episode-one.md)

- - If you have an environment where the Log Analytics agent is installed on client workstations and reporting to an existing Log Analytics workspace, review the list of [operating systems supported by Microsoft Defender for Cloud](security-center-os-coverage.md) to make sure your operating system is supported. For more information, see [Existing log analytics customers](./faq-azure-monitor-logs.yml).

-For more information, see [View detected devices on-premises](how-to-investigate-sensor-detections-in-a-device-inventory.md).

-| Device map | View the network devices, device connections, Purdue levels, and device properties in a map. Various zoom, highlight, and filter options are available to help you gain the insight you need. For more information, see [Investigate sensor detections in the Device Map](how-to-work-with-the-sensor-device-map.md#investigate-sensor-detections-in-the-device-map). |

-Port names are shown in Defender for IoT when [viewing device groups from the OT sensor's device map](how-to-work-with-the-sensor-device-map.md#group-highlight-and-filters-tools), or when you create OT sensor reports that include port information.

-For more information, see [Device inventory column reference](#device-inventory-column-reference).

-## Device inventory column reference

-The following table describes the device properties shown in the **Device inventory** page on an on-premises management console.

-| Name | Description |

-|--|--|

-| **Unacknowledged Alerts** | The number of unhandled alerts associated with this device. |

-| **Business Unit** | The business unit that contains this device. |

-| **Region** | The region that contains this device. |

-| **Site** | The site that contains this device. |

-| **Zone** | The zone that contains this device. |

-| **Appliance** | The Microsoft Defender for IoT sensor that protects this device. |

-| **Name** | The name of this device as Defender for IoT discovered it. |

-| **Type** | The type of device, such as PLC or HMI. |

-| **Vendor** | The name of the device's vendor, as defined in the MAC address. |

-| **Operating System** | The OS of the device. |

-| **Firmware** | The device's firmware. |

-| **IP Address** | The IP address of the device. |

-| **VLAN** | The VLAN of the device. |

-| **MAC Address** | The MAC address of the device. |

-| **Protocols** | The protocols that the device uses. |

-| **Unacknowledged Alerts** | The number of unhandled alerts associated with this device. |

-| **Is Authorized** | The authorization status of the device:<br />- **True**: The device has been authorized.<br />- **False**: The device hasn't been authorized. |

-| **Is Known as Scanner** | Whether this device performs scanning-like activities in the network. |

-| **Is Programming Device** | Whether the device is a programming device:<br />- **True**: The device performs programming activities for PLCs, RTUs, and controllers, which are relevant to engineering stations.<br />- **False**: The device isn't a programming device. |

-| **Groups** | Groups in which this device participates. |

-| **Last Activity** | The last activity that the device performed. |

-| **Discovered** | When this device was first seen in the network. |

-| **PLC mode (preview)** | The PLC operating mode includes the Key state (physical) and run state (logical). Possible **Key** states include, Run, Program, Remote, Stop, Invalid, Programming Disabled.Possible Run. The possible **Run** states are Run, Program, Stop, Paused, Exception, Halted, Trapped, Idle, Offline. if both states are the same, only one state is presented. |

-For more information, see [Device inventory column reference](#device-inventory-column-reference).

-1. Select one or more devices in the grid, and then select **View full details** in the pane on the right.

-For more information, see [Device inventory column reference](#device-inventory-column-reference).

-1. Use the SHIFT key to select two devices from the inventory, and then right-click one of them.

-1. Select **Merge** to merge the devices. This can take up to 2 minutes to complete.

-1. When the **Set merge device attributes** dialog appears, enter a meaningful name for your merged device, and then select **Save**.

-**To delete a single device**:

-You can delete a single device when theyΓÇÖve been inactive for more than 10 minutes.

-1. In the **Device inventory** page, select the device you want to delete, and then select **Delete** :::image type="icon" source="media/how-to-manage-device-inventory-on-the-cloud/delete-device.png" border="false"::: in the toolbar at the top of the page.

-1. At the prompt, select **Yes** to confirm that you want to delete the device from Defender for IoT.

-**To delete all inactive devices**

-## Export device inventory information

-You can export device inventory information to a .csv file.

-**To export:**

-## Device inventory column reference

-The following table describes the device properties shown in the **Device inventory** page on a sensor console.

-| Name | Description |

-|--|--|

-| **Description** | A description of the device |

-| **Discovered** | When this device was first seen in the network. |

-| **Firmware version** | The device's firmware, if detected. |

-| **FQDN** | The device's FQDN value |

-| **FQDN lookup time** | The device's FQDN lookup time |

-| **Groups** | The groups that this device participates in. |

-| **IP Address** | The IP address of the device. |

-| **Is Authorized** | The authorization status defined by the user:<br />- **True**: The device has been authorized.<br />- **False**: The device hasn't been |

-| **Is Known as Scanner** | Defined as a network scanning device by the user. |

-| **Is Programming device** | Defined as an authorized programming device by the user. <br />- **True**: The device performs programming activities for PLCs, RTUs, and controllers, which are relevant to engineering stations. <br />- **False**: The device isn't a programming device. |

-| **Last Activity** | The last activity that the device performed. |

-| **MAC Address** | The MAC address of the device. |

-| **Name** | The name of the device as the sensor discovered it, or as entered by the user. |

-| **Operating System** | The OS of the device, if detected. |

-| **PLC mode** (preview) | The PLC operating mode that includes the Key state (physical, or logical), and the Run state (logical). Possible Key states include, `Run`, `Program`, `Remote`, `Stop`, `Invalid`, and `Programming Disabled`. Possible Run states are `Run`, `Program`, `Stop`, `Paused`, `Exception`, `Halted`, `Trapped`, `Idle`, or `Offline`. If both states are the same, then only one state is presented. |

-| **Protocols** | The protocols that the device uses. |

-| **Type** | The type of device as determined by the sensor, or as entered by the user. |

-| **Unacknowledged Alerts** | The number of unacknowledged alerts associated with this device. |

-| **Vendor** | The name of the device's vendor, as defined in the MAC address. |

-| **VLAN** | The VLAN of the device. For more information, see [Define VLAN names](how-to-manage-the-on-premises-management-console.md#define-vlan-names). |

-For more information, see [Device inventory column reference](#device-inventory-column-reference).

-For more information, see [Device inventory column reference](#device-inventory-column-reference).

-For more information, see [Device inventory column reference](#device-inventory-column-reference).

-## Device inventory column reference

-The following table describes the device properties shown in the **Device inventory** page on the Azure portal.

-| Parameter | Description |

-|--|--|

-| **Application** | The application that exists on the device. |

-|**Authorization** |Editable. Determines whether or not the device is *authorized*. This value may change as device security changes. |

-|**Business Function** | Editable. Describes the device's business function. |

-| **Class** | Editable. The class of the device. <br>Default: `IoT`|

-| **Data source** | The source of the data, such as a micro agent, OT sensor, or Microsoft Defender for Endpoint. <br>Default: `MicroAgent`|

-| **Description** | Editable. The description of the device. |

-| **Firmware vendor** | Editable. The vendor of the device's firmware. |

-| **Firmware version** |Editable. The version of the firmware. |

-| **First seen** | The date, and time the device was first seen. Presented in format MM/DD/YYYY HH:MM:SS AM/PM. |

-|**Hardware Model** | Editable. Determines the device's hardware model. |

-|**Hardware Vendor** |Editable. Determines the device's hardware vendor. |

-| **Importance** | Editable. The level of importance of the device. |

-| **IPv4 Address** | The IPv4 address of the device. |

-| **IPv6 Address** | The IPv6 address of the device. |

-| **Last activity** | The date, and time the device last sent an event to the cloud. Presented in format MM/DD/YYYY HH:MM:SS AM/PM. |

-| **Location** | Editable. The physical location of the device. |

-| **MAC Address** | The MAC address of the device. |

-| **Model** | The device's model. |

-| **Name** | Mandatory, and editable. The name of the device as the sensor discovered it, or as entered by the user. |

-| **OS architecture** | Editable. The architecture of the operating system. |

-| **OS distribution** | Editable. The distribution of the operating system, such as Android, Linux, and Haiku. |

-| **OS platform** | Editable. The OS of the device, if detected. |

-| **OS version** | Editable. The version of the operating system, such as Windows 10 and Ubuntu 20.04.1. |

-| **PLC mode** | The PLC operating mode that includes the Key state (physical, or logical), and the Run state (logical). Possible Key states include, `Run`, `Program`, `Remote`, `Stop`, `Invalid`, and `Programming Disabled`. Possible Run states are `Run`, `Program`, `Stop`, `Paused`, `Exception`, `Halted`, `Trapped`, `Idle`, or `Offline`. If both states are the same, then only one state is presented. |

-| **PLC secured** | Determines if the PLC mode is in a secure state. A possible secure state is `Run`. A possible unsecured state can be either `Program`, or `Remote`. |

-|**Programming device** | Editable. Determines whether the device is a *Programming Device*. |

-| **Programming time** | The last time the device was programmed. |

-| **Protocols** | The protocols that the device uses. |

-| **Purdue level** | Editable. The Purdue level in which the device exists. |

-| **Scanner device** | Whether the device performs scanning-like activities in the network. |

-| **Sensor** | The sensor the device is connected to. |

-| **Site** | The site that contains this device. <br><br>All Enterprise IoT sensors are automatically added to the **Enterprise network** site.|

-| **Slots** | The number of slots the device has. |

-| **Subtype** | Editable. The subtype of the device, such as speaker and smart tv. <br>**Default**: `Managed Device` |

-| **Tags** | Editable. Tagging data for each device. |

-| **Type** | Editable. The type of device, such as communication, and industrial. <br>**Default**: `Miscellaneous` |

-| **Underlying devices** | Any relevant underlying devices for the device |

-| **Underlying device region** | The region for an underlying device |

-| **Vendor** | The name of the device's vendor, as defined in the MAC address. |

-| **VLAN** | The VLAN of the device. |

-| **Zone** | The zone that contains this device. |

-description: Use the on-premises management console to get a comprehensive view information per specific zone

-# View information per zone

-## View a device map for a zone

-View a Device map for a selected zone on a sensor. This view displays all network elements related to the selected zone, including the sensors, the devices connected to them, and other information.

- :::image type="content" source="media/how-to-work-with-asset-inventory-information/default-region-to-default-business-unit-v2.png" alt-text="Default region to default business unit.":::

-The **Device Map** window appears.

-The following tools are available for viewing devices and device information from the map. For details about each of these features, see the *Defender for IoT platform user guide*.

- :::image type="icon" source="media/how-to-work-with-asset-inventory-information/zoom-icon.png" border="false":::

- :::image type="content" source="media/how-to-work-with-asset-inventory-information/search-and-layout-tools.png" alt-text="Screenshot of the Search and Layout Tools view.":::

- :::image type="content" source="media/how-to-work-with-asset-inventory-information/labels-and-indicators.png" alt-text="Screenshot of labels and indicators.":::

- :::image type="content" source="media/how-to-work-with-asset-inventory-information/asset-properties-v2.png" alt-text="Screenshot of the Device Properties view.":::

- :::image type="content" source="media/how-to-work-with-asset-inventory-information/show-alerts.png" alt-text="Screenshot of the Show Alerts view.":::

-## View alerts associated with a zone

-To view alerts associated with a specific zone:

- :::image type="content" source="media/how-to-work-with-asset-inventory-information/business-unit-view-v2.png" alt-text="The default Business Unit view with examples.":::

-For more information, see [Overview: Working with alerts](how-to-work-with-alerts-on-premises-management-console.md).

-### View the device inventory of a zone

-To view the device inventory associated with a specific zone:

- :::image type="content" source="media/how-to-work-with-asset-inventory-information/default-business-unit.png" alt-text="The device inventory screen will appear.":::

-For more information, see:

-## View additional zone information

-The following additional zone information is available:

-## Next steps

-[Gain insight into global, regional, and local threats](how-to-gain-insight-into-global-regional-and-local-threats.md)

-description: Notifications provide information and recommendations about network activity.

-# Work with device notifications

-Discovery notifications provide information about network activity that might require your attention, along with recommendations for handling this activity. For example, you might receive a notification about an inactive device that should be reconnected, or removed if it's no longer part of the network. Notifications aren't the same as alerts. Alerts provide information about changes that might present a threat to your network.

-## Notification types

-The following table describes the notification event types you might receive, along with the options for handling them. When you dismiss a notification, the device information is not updated with the recommended action. If traffic is detected again, the notification is resent.

-| Type | Description | Responses |

-|--|--|--|

-| New IP detected | A new IP address is associated with the device. Five scenarios might be detected: <br /><br /> An additional IP address was associated with a device. This device is also associated with an existing MAC address.<br /><br /> A new IP address was detected for a device that's using an existing MAC address. Currently the device does not communicate by using an IP address.<br /> <br /> A new IP address was detected for a device that's using a NetBIOS name. <br /><br /> An IP address was detected as the management interface for a device associated with a MAC address. <br /><br /> A new IP address was detected for a device that's using a virtual IP address. | **Set Additional IP to Device** (merge devices) <br /> <br />**Replace Existing IP** <br /> <br /> **Dismiss**<br /> Remove the notification. |

-| Inactive devices | Traffic wasn't detected on a device for more than 60 days. For more information, see [What is a Defender for IoT committed device?](architecture.md#what-is-a-defender-for-iot-committed-device) | **Delete** <br /> If this device isn't part of your network, remove it. <br /><br />**Dismiss** <br /> Remove the notification if the device is part of your network. If the device is inactive (for example, because it's mistakenly disconnected from the network), dismiss the notification and reconnect the device. |

-| New OT devices | A subnet includes an OT device that's not defined in an ICS subnet. <br /><br /> Each subnet that contains at least one OT device can be defined as an ICS subnet. This helps differentiate between OT and IT devices on the map. | **Set as ICS Subnet** <br /> <br /> **Dismiss** <br />Remove the notification if the device isn't part of the subnet. |

-| No subnets configured | No subnets are currently configured in your network. <br /><br /> Configure subnets for better representation in the map and the ability to differentiate between OT and IT devices. | **Open Subnets Configuration** and configure subnets. <br /><br />**Dismiss** <br /> Remove the notification. |

-| Operating system changes | One or more new operating systems have been associated with the device. | Select the name of the new OS that you want to associate with the device.<br /><br /> **Dismiss** <br /> Remove the notification. |

-| New subnets | New subnets were discovered. | **Learn**<br />Automatically add the subnet.<br />**Open Subnet Configuration**<br />Add all missing subnet information.<br />**Dismiss**<br />Remove the notification. |

-| Device type changes | A new device type has been associated with the device. | **Set as {…}**<br />Associate the new type with the device.<br />**Dismiss**<br />Remove the notification. |

-## View notifications

-1. In Defender for IoT, select **Device Map**.

-1. Select **Notifications** icon.

-1. In **Discovery Notifications**, review all notifications.

-1. For each notification, either accept the recommendation, or dismiss it.

-1. By default, all notifications are shown.

- - To filter for specific dates and times, select **Time range ==** and specify a days, weeks, or month filter.

- - Select **Add filter** to filter on other device, subnet, and operating system values.

-## Respond to multiple notifications

-You might need to handle several notifications simultaneously. For example:

-Respond as follows:

-1. In **Discovery Notifications**, choose **Select All**, and then clear the notifications you don't need. When you choose **Select All**, Defender for IoT displays information about which notifications can be handled or dismissed simultaneously, and which need your input.

-1. You can accept all recommendations, dismiss all recommendations, or handled notifications one at a time.

-1. For notifications that indicate manual changes are required, such as **New IPs** and **No Subnets**, make the manual modifications as needed.

-## Next steps

-For more information, see [View alerts](how-to-view-alerts.md).

-description: The Device map provides a graphical representation of network devices detected. Use the map to analyze, and manage device information, network slices and generate reports.

-# Investigate sensor detections in the Device map

-The Device map provides a graphical representation of network devices detected, and the connections between them. Use the map to:

- - Retrieve, analyze, and manage device information.

- - Analyze network slices, for example-specific groups of interest or Purdue layers.

- - Generate reports, for example export device details and summaries.

-**To access the map:**

-## Map search and layout tools

-A variety of map tools help you gain insight into devices and connections of interest to you.

-Your user role determines which tools are available in the Device Map window. For more information, see [On-premises users and roles for OT monitoring with Defender for IoT](roles-on-premises.md) and [Create and manage users on an OT network sensor](manage-users-sensor.md).

-### Basic search tools

-The following basic search tools are available:

- :::image type="icon" source="media/how-to-work-with-maps/search-bar-icon-v2.png" border="false":::

-When you search by IP or MAC address, the map displays the device that you searched for with the devices connected to it.

-### Group highlight and filters tools

-Filter or highlight the map based on default and custom device groups.

- :::image type="content" source="media/how-to-work-with-maps/group-highlight-and-filters-v2.png" alt-text="Screenshot of the group highlights and filters.":::

-**To highlight or filter devices:**

-1. Select **Device map** on the side menu.

-1. From the Groups pane, select the group you want to highlight or filter.

-1. Toggle the **Highlight** or **Filter** option.

-The following predefined groups are available:

-| Group name | Description |

-|--|--|

-| **Known applications** | Devices that use reserved ports, such as TCP. |

-| **non-standard ports (default)** | Devices that use non-standard ports or ports that haven't been assigned an alias. |

-| **OT protocols (default)** | Devices that handle known OT traffic. |

-| **Authorization (default)** | Devices that were discovered in the network during the learning process or were officially authorized on the network. |

-| **Device inventory filters** | Devices grouped according to the filters saved in the Device Inventory table. |

-| **Polling intervals** | Devices grouped by polling intervals. The polling intervals are generated automatically according to cyclic channels or periods. For example, 15.0 seconds, 3.0 seconds, 1.5 seconds, or any other interval. Reviewing this information helps you learn if systems are polling too quickly or slowly. |

-| **Programming** | Engineering stations, and programming machines. |

-| **Subnets** | Devices that belong to a specific subnet. |

-| **VLAN** | Devices associated with a specific VLAN ID. |

-| **Cross subnet connections** | Devices that communicate from one subnet to another subnet. |

-| **Attack vector simulations** | Vulnerable devices detected in attack vector reports. To view these devices on the map, select the **Display on Device Map** checkbox when generating the Attack Vector. :::image type="content" source="media/how-to-work-with-maps/add-attack-v3.png" alt-text="Screenshot of the Add Attack Vector Simulations":::|

-| **Last activity** | Devices grouped by the time frame they were last active, for example: One hour, six hours, one day, or seven days. |

-| **Not In Active Directory** | All non-PLC devices that aren't communicating with the Active Directory. |

-For information about creating custom groups, see [Define custom groups](#define-custom-groups).

-### View filtered information as a map group

-You can display devices from saved filters in the Device map. For more information, see [View the device inventory](how-to-investigate-sensor-detections-in-a-device-inventory.md#view-the-device-inventory).

-**To view devices in the map:**

-1. After creating and saving an Inventory filter, navigate to the Device map.

-1. In the map page, open the Groups pane on the left.

-1. Scroll down to the **Asset Inventory Filters** group. The groups you saved from the Inventory appear.

-### Map display tools

-| Icon | Description |

-|--|--|

-| :::image type="icon" source="media/how-to-work-with-maps/fit-to-screen-icon.png" border="false"::: | Fit to screen. |

-| :::image type="icon" source="media/how-to-work-with-maps/fit-to-selection-icon.png" border="false"::: | Fits a group of selected devices to the center of the screen. |

-| :::image type="icon" source="media/how-to-work-with-maps/collapse-view-icon.png" border="false"::: | IT/OT Presentation Options. Select **Disable Display IT Networks Groups** to prevent the ability to collapse IT networks in the map. This option is turned on by default. |

-|:::image type="icon" source="media/how-to-work-with-maps/layouts-icon-v2.png" border="false"::: | Layout options, including: <br />**Pin layout**. Drag devices on the map to a new location. Use the Pin option to save those locations when you leave the map to use another option. <br />**Layout by connection**. View connections between devices. <br />**Layout by Purdue**. View the devices in the map according to Enterprise, supervisory and process control layers. <br /> |

-| :::image type="icon" source="media/how-to-work-with-maps/zoom-in-icon-v2.png" border="false"::: :::image type="icon" source="media/how-to-work-with-maps/zoom-out-icon-v2.png" border="false"::: | Zoom in or out of the map. |

-### Map zoom views

-Working with map views helps expedite forensics when analyzing large networks. Map views include the following options:

- - [BirdΓÇÖs-eye view](#birds-eye-view)

- - [Device type and connection view](#device-type-and-connection-view)

-### BirdΓÇÖs-eye view

-This view provides an at-a-glance view of devices represented as follows:

- - Red dots indicate devices with alert(s)

- - Starred dots indicate devices marked as important

- - Black dots indicate devices with no alerts

- :::image type="content" source="media/how-to-work-with-maps/colored-dots-v2.png" alt-text="Screenshot of a bird eye view of the map." lightbox="media/how-to-work-with-maps/colored-dots-v2.png":::

-### Device type and connection view

-This view presents devices represented as icons on the map.

- - Devices with alerts are displayed with a red ring

- - Devices without alerts are displayed with a grey ring

- - Devices displayed as a star were marked as important

-Overall connections are displayed.

-**To view specific connections:**

-1. Select a device in the map.

-1. Specific connections between devices are displayed in blue. In addition, you'll see connections that cross various Purdue levels.

- :::image type="content" source="media/how-to-work-with-maps/connections-purdue-level.png" alt-text="Screenshot of the detailed map view." lightbox="media/how-to-work-with-maps/connections-purdue-level.png" :::

-### View IT subnets

-By default, IT devices are automatically aggregated by subnet, so that the map view is focused on OT and ICS networks. The presentation of the IT network elements is collapsed to a minimum which reduces the total number of the devices presented on the map, and provides a clear picture of the OT and ICS network elements.

-Each subnet is presented as a single entity on the Device map. Options are available to expand subnets to see details, collapse subnets or hide them.

-**To expand an IT subnet:**

-1. Right-click the icon on the map that represents the IT network and select **Expand Network**.

-1. A confirmation box appears, notifying you that the layout change can't be redone.

-1. Select **OK**. The IT subnet elements appear on the map.

-1. From the left pane, select **Devices**.

-2. Select the expanded subnet. The number in red indicates how many expanded IT subnets currently appear on the map.

-3. Select the subnet(s) that you want to collapse or select **Collapse All**. The selected subnet appears collapsed on the map.

-The collapse icon is updated with the updated number of collapsed IT subnets.

-**To disable the option to collapse and expand IT subnets:**

-1. Select the **Disable Display IT Network Groups**.

-1. Select Confirm the dialog box that opens.

-This option is available to Administrator users.

-> [!NOTE]

- > For information on updating default OT IT networks, see [Configure subnets](how-to-control-what-traffic-is-monitored.md#configure-subnets).

-## Define custom groups

-In addition to viewing predefined groups, you can define custom groups. The groups appear in the Device map, Device inventory, and Data Mining Reports.

-> [!NOTE]

-> You can also create groups from the Device Inventory.

-**To create a group:**

-1. Select **Create Custom Group** from the Device map.

-1. In the Add custom group dialog box, add the name of the group. Use up to 30 characters.

-1. Select an existing group(s) or choose specific device(s).

-1. Select **Submit**.

-**To add devices to a custom group**:

-1. Right-click a device(s) on the map.

-1. Select **Add to custom group**.

-1. Select an existing group(s) or choose specific device(s).

-1. Select **Submit**.

-## Learn more about devices

-An extensive range of tools are available to learn more about devices from the Device map, including:

-### Device labels and indicators

-The following labels and indicators may appear on devices on the map:

-| Device label | Description |

-|--|--|

-| :::image type="content" source="media/how-to-work-with-maps/host-v2.png" alt-text="Screenshot of the I P host name."::: | IP address host name and IP address, or subnet addresses |

-| :::image type="content" source="media/how-to-work-with-maps/amount-alerts-v2.png" alt-text="Screenshot of the number of alerts"::: | Number of alerts associated with the device |

-| :::image type="icon" source="media/how-to-work-with-maps/type-v2.png" border="false"::: | Device type icon, for example storage, PLC or historian. |

-| :::image type="content" source="media/how-to-work-with-maps/grouped-v2.png" alt-text="Screenshot of devices grouped together."::: | Number of devices grouped in a subnet in an IT network. In this example 8. |

-| :::image type="content" source="media/how-to-work-with-maps/not-authorized-v2.png" alt-text="Screenshot of the device learning period"::: | A device that was detected after the Learning period and wasn't authorized as a network device. |

-| Solid line | Logical connection between devices |

-| :::image type="content" source="media/how-to-work-with-maps/new-v2.png" alt-text="Screenshot of a new device discovered after learning is complete."::: | New device discovered after Learning is complete. |

-### Device details and contextual information

-You can access detailed and contextual information about a device from the map, for example:

-**To view details:**

-1. Right-click a device on the map.

-1. Select **View properties**.

-1. Navigate to the information you need.

- :::image type="content" source="media/how-to-work-with-maps/device-details-from-map.png" alt-text="Screenshot of the device details shown for the device selected in map.":::

-#### Device details

-This section describes device details.

-| Item | Description |

-|--|--|

-| Name | The device name. <br /> By default, the sensor discovers the device name as it's defined in the network. For example, a name defined in the DNS server. <br /> If no such names were defined, the device IP address appears in this field. <br /> You can change a device name manually. Give your devices meaningful names that reflect their functionality. |

-| Authorized status | Indicates if the device is authorized or not. During the Learning period, all the devices discovered in the network are identified as Authorized. When a device is discovered after the Learning period, it appears as Unauthorized by default. You can change this definition manually. For information on this status and manually authorizing and unauthorizing, see [Authorize and unauthorize devices](#authorize-and-unauthorize-devices). |

-| Last activity | The last time the device was detected. |

-| Alert | The number of open alerts associated with the device. |

-| Type | The device type as detected by the sensor. |

-| Vendor | The device vendor. This is determined by the leading characters of the device MAC address. This field is read-only. |

-| Operating System | The device OS detected by the sensor. |

-| Location | The Purdue layer identified by the sensor for this device, including: <br /> - Automatic <br /> - Process Control <br /> - Supervisory <br /> - Enterprise |

-| Description | A free text field. <br /> Add more information about the device. |

-| Attributes | Additional information was discovered on the device. For example, view the PLC Run and Key state, the secure status of the PLC, or information on when the state changed. <br /> The information is read only and can't be updated from the Attributes section. |

-| Scanner or Programming device | **Scanner**: Enable this option if you know that this device is known as a scanner and there's no need to alert you about it. <br /> **Programming Device**: Enable this option if you know that this device is known as a programming device and is used to make programming changes. Identifying it as a programming device will prevent alerts for programming changes originating from this asset. |

-| Network Interfaces | The device interfaces. A RO field. |

-| Protocols | The protocols used by the device. A RO field. |

-| Firmware | If Backplane information is available, firmware information won't be displayed. |

-| Address | The device IP address. |

-| Serial | The device serial number. |

-| Module Address | The device model and slot number or ID. |

-| Model | The device model number. |

-| Firmware Version | The firmware version number. |

-#### Contextual information

- View contextual information about the device.

-**To view:**

-1. Select **Map View** to see device connections to other devices.

-1. Select **Alerts** to see details about alerts associated with the device.

-1. Select **Event Timeline** to review events that occurred around the time of the detection.

-#### Backplane properties

-If a PLC contains multiple modules separated into racks and slots, the characteristics might vary between the module cards. For example, if the IP address and the MAC address are the same, the firmware might be different.

-You can use the Backplane option to review multiple controllers/cards and their nested devices as one entity with various definitions. Each slot in the Backplane view represents the underlying devices ΓÇô the devices that were discovered behind it.

-A Backplane can contain up to 30 controller cards and up to 30 rack units. The total number of devices included in the multiple levels can be up to 200 devices.

-The Backplane pane is shown in the Device Properties window when Backplane details are detected.

-Each slot appears with the number of underlying devices and the icon that shows the module type.

-| Icon | Module Type |

-|--|--|

-| :::image type="content" source="media/how-to-work-with-maps/power.png" alt-text="Screenshot of the Power Supply icon."::: | Power Supply |

-| :::image type="content" source="media/how-to-work-with-maps/analog.png" alt-text="Screenshot the Analog I/O icon."::: | Analog I/O |

-| :::image type="content" source="media/how-to-work-with-maps/comms.png" alt-text="Screenshot of the Communication Adapter icon."::: | Communication Adapter |

-| :::image type="content" source="media/how-to-work-with-maps/digital.png" alt-text="Screenshot of the Digital I/O icon."::: | Digital I/O |

-| :::image type="content" source="media/how-to-work-with-maps/computer-processor.png" alt-text="Screenshot of the CPU icon."::: | CPU |

-| :::image type="content" source="media/how-to-work-with-maps/HMI-icon.png" alt-text="Screenshot of the HMI icon."::: | HMI |

-| :::image type="content" source="media/how-to-work-with-maps/average.png" alt-text="Screenshot of the Generic icon."::: | Generic |

-When you select a slot, the slot details appear:

-To view the underlying devices behind the slot, select **VIEW ON MAP**. The slot is presented in the device map with all the underlying modules and devices connected to it.

-## Manage device information from the map

-Under certain circumstances, you may need to update device information provided by Defender for IoT. The following options are available:

-### Update device properties

-Certain device properties can be updated manually. Information manually entered will override information discovered by Defender for IoT.

-**To update properties:**

-1. Right-click a device from the map.

-1. Select **View properties**.

-1. Select **Edit properties.**

- :::image type="content" source="media/how-to-work-with-maps/edit-config.png" alt-text="Screenshot of the Edit device property pane.":::

-1. Update any of the following:

- - Authorized status

- - Device name

- - Device type. For a list of types, see [Device types](#device-types).

- - OS

- - Purdue layer

- - Description

-

-#### Device types

-This table lists device types you can manually assign to a device.

-| Category | Device Type |

-| ICS | Engineering Station <br /> PLC <br />Historian <br />HMI <br />IED <br />DCS Controller <br />RTU <br />Industrial Packaging System <br />Industrial Scale <br />Industrial Robot <br />Slot <br />Meter <br />Variable Frequency Drive <br />Robot Controller <br />Servo Drive <br />Pneumatic Device <br />Marquee |

-| IT | Domain Controller <br />DB Server <br />Workstation <br />Server <br />Terminal Station <br />Storage <br />Smart Phone <br />Tablet <br />Backup Server |

-| IoT | IP Camera <br />Printer <br />Punch Clock <br />ATM <br />Smart TV <br />Game console <br />DVR <br />Door Control Panel <br />HVAC <br />Thermostat <br />Fire Alarm <br />Smart Light <br />Smart Switch <br />Fire Detector <br />IP Telephone <br />Alarm System <br />Alarm Siren <br />Motion Detector <br />Elevator <br />Humidity Sensor <br />Barcode Scanner <br />Uninterruptible Power Supply <br />People Counter System <br />Intercom <br />Turnstile |

-| Network | Wireless Access Point <br />Router <br />Switch <br />Firewall <br />VPN Gateway <br />NTP Server <br />Wifi Pineapple <br />Physical Location <br />I/O Adapter <br /> Protocol Converter |

-### Delete devices

-You may want to delete a device if the information learned isn't relevant. For example,

- - A partner contractor at an engineering workstation connects temporarily to perform configuration updates. After the task is completed, the device is removed.

- - Due to changes in the network, some devices are no longer connected.

-If you don't delete the device, the sensor will continue monitoring it. After 60 days, a notification will appear, recommending that you delete.

-You may receive an alert indicating that the device is unresponsive if another device tries to access it. In this case, your network may be misconfigured.

-The device will be removed from the Device Map, Device Inventory, and Data Mining reports. Other information, for example: information stored in Widgets will be maintained.

-The device must be inactive for at least 10 minutes to delete it.

-**To delete a device from the device map:**

-1. Right-click a device on the map and select **Delete**.

-### Merge devices

-Under certain circumstances you may need to merge devices. This may be required if the sensor discovered separate network entities that are associated with one unique device. For example,

- - A PLC with four network cards.

- - A Laptop with WIFI and physical card.

-

- - A Workstation with two, or more network cards.

-When merging, you instruct the sensor to combine the device properties of two devices into one. When you do this, the Device Properties window and sensor reports will be updated with the new device property details.

-For example, if you merge two devices, each with an IP address, both IP addresses will appear as separate interfaces in the Device Properties window. You can only merge authorized devices.

-The event timeline presents the merge event.

-You can't undo a device merge. If you mistakenly merged two devices, delete the device and wait for the sensor to rediscover both.

-**To merge devices:**

-1. Select two devices (shift-click), and then right-click one of them.

-2. Select **Merge** to merge the devices. It can take up to 2 minutes complete the merge.

-3. In the set merge device attributes dialog box, choose a device name.

- :::image type="content" source="media/how-to-work-with-maps/name-the-device-v2.png" alt-text="Screenshot of the attributes dialog box.":::

-4. Select **Save**.

-### Authorize and unauthorize devices

-During the Learning period, all the devices discovered in the network are identified as authorized devices. The **Authorized** label doesn't appear on these devices in the Device map.

-When a device is discovered after the Learning period, it appears as an unauthorized device. In addition to seeing unauthorized devices in the map, you can also see them in the Device Inventory.

-**New device vs unauthorized**

-New devices detected after the Learning period will appear with a `New` and `Unauthorized` label.

-If you move a device on the map or manually change the device properties, the `New` label is removed from the device icon.

-#### Unauthorized devices - Attack Vectors and Risk Assessment reports

-Unauthorized devices are included in Risk Assessment reports and Attack Vectors reports.

- :::image type="content" source="media/how-to-work-with-maps/attack-vector-reports.png" alt-text="Screenshot of the attack vector reports.":::

- :::image type="content" source="media/how-to-work-with-maps/unauthorized-risk-assessment-report.png" alt-text="Screenshot of a Risk Assessment report showing an unauthorized device.":::

-**To authorize or unauthorize devices manually:**

-1. Right-click the device on the map and select **Authorize** or **Unauthorize**.

-### Mark devices as important

-You can mark significant network devices as important, for example, business critical servers. These devices are marked with a star on the map. The star varies according to the map's zoom level.

-**To mark a device as Important:**

-1. Right-click the device on the map and select **Mark as important**

-#### Important devices - Attack Vectors and Risk Assessment reports

-Important devices are calculated when generating Risk Assessment reports and Attack Vectors reports.

- - Attack Vector reports devices marked as important are resolved in the Attack Vector as Attack Targets.

- - Risk Assessment Reports: Devices marked as important are calculated when providing the security score in the Risk Assessment report.

-

-#### Important devices - Defender for IoT on the Azure portal

-Devices you mark as important on your sensor are also marked as important in the Device inventory on the Defender for IoT portal on Azure.

-| **OT network sensor** | The retention of device inventory data isn't limited by time. <br><br> For more information, see [Manage your OT device inventory from a sensor console](how-to-investigate-sensor-detections-in-a-device-inventory.md). |

-| **On-premises management console** | The retention of device inventory data isn't limited by time. <br><br> For more information, see [Manage your OT device inventory from an on-premises management console](how-to-investigate-all-enterprise-sensor-detections-in-a-device-inventory.md). |

-To use the Azure Data Manager for Energys Preview platform endpoint, you must register your app using the [Azure app registration portal](https://go.microsoft.com/fwlink/?linkid=2083908). You can use either a Microsoft account or a work or school account to register an app.

-The Azure Data Manager for Energy Preview DDMS service enables energy companies to access their data in a manner that is fast, portable, testable and extendible. As a result, they'll achieve unparalleled streaming performance and use the standards and output from OSDU&trade;. The Azure DDMS service will onboard the OSDU&trade; DDMS and SLB proprietary DMS. Microsoft also continues to contribute to the OSDU&trade; community DDMS to ensure compatibility and architectural alignment.

-Customers can deploy applications on top of Azure Data Manager for Energy Preview that have been developed as per the OSDU&trade; standard. They're able to connect applications to Core Services and DDMS without spending extensive cycles on deployment. Customers can also easily connect DELFI to Azure Data Manager for Energy Preview, eliminating the cycles associated with Petrel deployments and connection to data management systems. By connecting applications to DDMS service, Geoscientists can execute integrated E&P workflows with unparalleled performance on Azure and use OSDU&trade; core services. For example, a geophysicist can pick well ties on a seismic volume in Petrel and stream data from the seismic DMS.

-Below are the OSDU&trade; DMS the service supports -

-## OSDU&trade; - Wellbore DMS

-Well Logs are measurements taken while drilling, which tells energy companies information about the subsurface. Ultimately, they reveal whether hydrocarbons are present (or if the well is dry). Logs contain many attributes that inform geoscientists about the type of rock, its quality, and whether it contains oil, water, gas, or a mix. Energy companies use these attributes to determine the quality of a reservoir ΓÇô how much oil or gas is present, its quality, and ultimately, economic viability. Maintaining Well Log data and ensuring easy access to historical logs is critical to energy companies. The Wellbore DMS facilitates access to this data in any OSDU&trade; compliant application. The Wellbore DMS was contributed by SLB to OSDU&trade;.

-Well Log data can come in different formats. It's most often indexed by depth or time and the increment of these measurements can vary. Well Logs typically contain multiple attributes for each vertical measurement. Well Logs can therefore be small or for more modern Well Logs that use high frequency data, greater than 1 Gb. Well Log data is smaller than seismic; however, users will want to look at upwards of hundreds of wells at a time. This scenario is common in mature areas that have been heavily drilled such as the Permian Basin in West Texas.

-Geoscientists therefore want to access numerous well logs in a single session. They often are looking at all historical drilling programs in an area. As a result, they'll look at Well Log data that was collected using a wide variety of instruments and technology. This data will vary widely in format, quality, and sampling. The Wellbore DMS resolves this data through the OSDU&trade; schemas to deliver the data to the consuming applications.

-## OSDU&trade; - Well Delivery DMS

-Learn more about DDMS concepts below.

-description: This topic provides release notes of Azure Data Manager for Energy Preview releases, improvements, bug fixes, and known issues. #Required; article description that is displayed in search results.

-### Product Access Update

-Beginning on February 15, 2023, customers of Microsoft Energy Data Services can search for and provision their instances of the product without a request for access. Customers can go directly to the Azure Marketplace to create an instance under their selected subscription.

-### Product Billing Update

-Microsoft Energy Data Services will begin billing February 15, 2023. Prices will be based on a fixed per-hour consumption rate at a 50 percent discount during preview.

-### OSDUΓäó Milestone Upgrade

-Azure Data Manager for Energy Preview is now compliant with the M14 OSDUΓäó milestone release. With this release you can take advantage of the latest features and capabilities available in the [OSDUΓäó M14](https://community.opengroup.org/osdu/governance/project-management-committee/-/wikis/M14-Release-Notes).

-CORS provides a secure way to allow one origin (the origin domain) to call APIs in another origin. With this feature you can set CORS rules for each Azure Data Manager for Energy instance. When you set CORS rules for the instance it gets applied automatically across all the services and storage accounts linked with Microsoft Energy Data services.[Learn more.]( ../energy-data-services/how-to-enable-CORS.md)

-You can use a managed identity to authenticate to any [service that supports Azure AD (Active Directory) authentication](../active-directory/managed-identities-azure-resources/services-azure-active-directory-support.md) with Azure Data Manager for Energy Preview. For example, you can write a script in Azure Function to ingest data in Azure Data Manager for Energy Preview. Now, you can use managed identity to connect to Azure Data Manager for Energy Preview using system or user assigned managed identity from other Azure services. [Learn more.]( ../energy-data-services/how-to-use-managed-identity.md)

-Availability Zones are physically separate locations within an Azure region made up of one or more datacenters equipped with independent power, cooling, and networking. Availability Zones provide in-region High Availability and protection against local disasters. Azure Data Manager for Energy Preview supports zone-redundant instance by default and there's no setup required by the Customer. [Learn more.](https://azure.microsoft.com/explore/global-infrastructure/products-by-region/?products=energy-data-services&regions=all)

-### Lockbox

-Most operations, support, and troubleshooting performed by Microsoft personnel do not require access to customer data. In those rare circumstances where such access is required, Customer Lockbox for Azure Data Manager for Energy Preview provides you an interface to review and approve or reject data access requests. Azure Data Manager for Energy Preview now supports Lockbox. [Learn more](../security/fundamentals/customer-lockbox-overview.md).

-Azure Private Link on Azure Data Manager for Energy Preview provides private access to the service. This means traffic between your private network and Azure Data Manager for Energy Preview travels over the Microsoft backbone network therefore limiting any exposure over the internet. By using Azure Private Link, you can connect to an Azure Data Manager for Energy Preview instance from your virtual network via a private endpoint, which is a set of private IP addresses in a subnet within the virtual network. You can then limit access to your Azure Data Manager for Energy Preview instance over these private IP addresses. [Create a private endpoint for Azure Data Manager for Energy Preview](how-to-set-up-private-links.md).

-Azure Data Manager for Energy Preview is now available in public preview. Information on latest releases, bug fixes, & deprecated functionality for Azure Data Manager for Energy Preview will be updated monthly. Keep tracking this page.

-Azure Data Manager for Energy Preview is developed in alignment with the emerging requirements of the OSDUΓäó Technical Standard, Version 1.0. and is currently aligned with Mercury Release(R3), [Milestone-12](https://community.opengroup.org/osdu/governance/project-management-committee/-/wikis/M12-Release-Notes).

- - User identity is preserved and passed on to all ingestion workflow related services using the newly introduced _x-on-behalf-of_ header. A user needs to have appropriate service level entitlements on all dependent services involved in the ingestion workflow and only users with appropriate data level entitlements can modify data.

-In this article, you'll learn how to use the MedTech service Mapping debugger in the Azure portal. The Mapping debugger is a tool used for creating, updating, and troubleshooting the MedTech service device and FHIR destination mappings. The Mapping debugger can also be used for uploading test device messages to see how they'll look after being processed into normalized messages and transformed into FHIR Observations for persistence in the FHIR service. This new self-service tool allows you to easily view and make inline adjustments in real-time, without ever having to leave the Azure portal.

-**IP Filter**: Specify a range of IP addresses that will be accepted or rejected by the IoT hub.

-The device data that a given IoT solution stores depends on the specific requirements of that solution. But, as a minimum, a solution must store device identities and authentication keys. Azure IoT Hub includes an identity registry that can store values for each device such as IDs, authentication keys, and status codes. A solution can use other Azure services such as Table storage, Blob storage, or Azure Cosmos DB to store any additional device data.

-IoT Hub can notify your IoT solution when a device identity is created or deleted by sending lifecycle notifications. To do so, your IoT solution needs to create a route and set the data source equal to *DeviceLifecycleEvents*. By default, no lifecycle notifications are sent, that is, no such routes pre-exist. By creating a route with Data Source equal to *DeviceLifecycleEvents*, lifecycle events will be sent for both device identities and module identities; however, the message contents will differ depending on whether the events are generated for module identities or device identities. It should be noted that for IoT Edge modules, the module identity creation flow is different than for other modules, as a result for IoT Edge modules the create notification is only sent if the corresponding IoT Edge Device for the updated IoT Edge module identity is running. For all other modules, lifecycle notifications are sent whenever the module identity is updated on the IoT Hub side. To learn more about the properties and body returned in the notification message, see [Non-telemetry event schemas](iot-hub-non-telemetry-event-schema.md).

-| connectionState |read-only |A field indicating connection status: either **Connected** or **Disconnected**. This field represents the IoT Hub view of the device connection status. **Important**: This field should be used only for development/debugging purposes. The connection state is updated only for devices using MQTT or AMQP. Also, it's based on protocol-level pings (MQTT pings, or AMQP pings), and it can have a maximum delay of only 5 minutes. For these reasons, there can be false positives, such as devices reported as connected but that are disconnected. |

-| connectionState |read-only |A field indicating connection status: either **Connected** or **Disconnected**. This field represents the IoT Hub view of the device connection status. **Important**: This field should be used only for development/debugging purposes. The connection state is updated only for devices using MQTT or AMQP. Also, it's based on protocol-level pings (MQTT pings, or AMQP pings), and it can have a maximum delay of only 5 minutes. For these reasons, there can be false positives, such as devices reported as connected but that are disconnected. |

-To try out some of the concepts described in this article, see the following IoT Hub tutorial:

-* [Get started with Azure IoT Hub](../iot-develop/quickstart-send-telemetry-iot-hub.md?pivots=programming-language-csharp)

-To explore using the IoT Hub Device Provisioning Service to enable zero-touch, just-in-time provisioning, see:

-The X.509 CA feature enables device authentication to IoT Hub using a certificate authority (CA). It simplifies the initial device enrollment process as well as supply chain logistics during device manufacturing. If you aren't familiar with X.509 CA certificates, see [Understand how X.509 CA certificates are used in the IoT industry](iot-hub-x509ca-concept.md) for more information.

-For production environments, we recommend that you purchase an X.509 CA certificate from a public root certificate authority. Purchasing a CA certificate has the benefit of the root CA acting as a trusted third party to vouch for the legitimacy of your devices. Consider this option if your devices are part of an open IoT network where they will interact with third-party products or services.

-Regardless of how you obtain your X.509 CA certificate, make sure to keep its corresponding private key secret and protected at all times. This is necessary for building trust in the X.509 CA authentication.

-

-Register your X.509 CA certificate to IoT Hub where it will be used to authenticate your devices during registration and connection. Registering the X.509 CA certificate is a two-step process that includes uploading the certificate file and then establishing proof of possession.

-The proof of possession step involves a cryptographic challenge and response process between you and IoT Hub. Given that digital certificate contents are public and therefore susceptible to eavesdropping, IoT Hub has to verify that you really own the CA certificate. It does so by generating a random challenge that you sign with the CA certificate's corresponding private key. If you kept the private key secret and protected as recommended, then only you will possess the knowledge to complete this step. Secrecy of private keys is the source of trust in this method. After signing the challenge, you complete this step by uploading a file containing the results.

-To prevent device impersonation, IoT Hub requires that you let it know what devices to expect. You do this by creating a device entry in the IoT hub's device registry. This process is automated when using [IoT Hub Device Provisioning Service](../iot-dps/about-iot-dps.md).

-1. Ensure that the target bare metal machine (server) must be `powered-on` and have its `readyState` set to True

-The cordon command supports an `evacuate` parameter with the default `false` value.

-On executing the `cordon` command, with the value `true` for the `evacuate`

-The `evacuate "True"` removes workloads from that node while `evacuate "FALSE"` only prevents the scheduling of new workloads.

-command, with `evacuate "TRUE"`, prior to executing the `reimage` command.

-# Install Azure CLI extensions

-Install the following CLI extensions:

-<!-- LINKS - Internal -->

-[howto-configure-network fabric]: ./howto-configure-network fabric.md

-[quickstarts-tenant-workload-deployment]: ./quickstarts-tenant-workload-deployment.md

-**Business continuity** in Azure Database for PostgreSQL - Flexible Server refers to the mechanisms, policies, and procedures that enable your business to continue operating in the face of disruption, particularly to its computing infrastructure. In most of the cases, flexible server will handle the disruptive events happens that might happen in the cloud environment and keep your applications and business processes running. However, there are some events that cannot be handled automatically such as:

-Flexible server provides features that protect data and mitigates downtime for your mission critical databases in the event of planned and unplanned downtime events. Built on top of the Azure infrastructure that already offers robust resiliency and availability, flexible server has business continuity features that provide additional fault-protection, address recovery time requirements, and reduce data loss exposure. As you architect your applications, you should consider the downtime tolerance - which is the recovery time objective (RTO) and data loss exposure - which is the recovery point objective (RPO). For example, your business-critical database requires much stricter uptime requirements compared to a test database.

-| **Automatic backups** | Flexible server automatically performs daily backups of your database files and continuously backs up transaction logs. Backups can be retained from 7 days up to 35 days. You will be able to restore your database server to any point in time within your backup retention period. RTO is dependent on the size of the data to restore + the time to perform log recovery. It can be from few minutes up to 12 hours. For more details, see [Concepts - Backup and Restore](./concepts-backup-restore.md). |Backup data remains within the region. |

-| **Zone redundant backup** | Flexible server backups are automatically and securely stored in a zone redundant storage within a region if the region supports AZs. During a zone-level failure where your server is provisioned, and if your server is not configured with zone redundancy, you can still restore your database using the latest restore point in a different zone. For more information, see [Concepts - Backup and Restore](./concepts-backup-restore.md).| Only applicable in regions where multiple zones are available.|

-| <b>Scaling up storage (User-initiated) | When a scaling up storage operation is initiated, active checkpoints are allowed to complete, client connections are drained, any uncommitted transactions are canceled, and then it is shut down. The storage is scaled to the desired size and then attached to the new server. A recovery is performed if needed before accepting client connections. Note that scaling down of the storage size is not supported. |

-

-### Unplanned downtime: failure scenarios and service recovery

-# Concepts for Microsoft Purview DevOps policies

-This article discusses concepts related to managing access to data sources in your data estate from within the Microsoft Purview governance portal. In particular, it focuses on DevOps policies.

-> This capability is different from access control for Microsoft Purview itself, which is described in [Access control in Microsoft Purview](./catalog-permissions.md).

-Access to system metadata is crucial for IT operations and other DevOps personnel to perform their job. That access can be granted and revoked efficiently and at-scale through Microsoft Purview DevOps policies.

-Microsoft Purview access policies enable customers to manage access to different data systems across their entire data estate, all from a central location in the cloud. These policies are access grants that can be created through Microsoft Purview Studio, avoiding the need for code. They dictate whether a set of Azure AD principals (users, groups, etc.) should be allowed or denied a specific type of access to a data source or asset within it. These policies get communicated to the data sources where they get natively enforced.

-DevOps policies are a special type of Microsoft Purview access policies. They grant access to database system metadata instead of user data. They simplify access provisioning for IT operations and security auditing functions. DevOps policies only grant access, that is, they don't deny access.

-A DevOps policy is defined by three elements: The *data resource path*, the *role* and the *subject*. In essence, the DevOps policy assigns the *subject* to the *role* for the scope of the *data resource path*.

-Is a set of Azure AD users, groups or service principals.

-#### The role

-The role maps to a set of actions that the policy permits on the data resource. DevOps policies support a couple of roles: *SQL Performance Monitor* and *SQL Security Auditor*. The DevOps policy how-to docs detail the role definition for each data source, that is, the mapping between the role in Microsoft Purview and the actions that get permitted in the data source. For example, the role definition for SQL Performance Monitor and SQL Security Auditor includes Connect actions at server and database level on the data source side.

-Microsoft Purview DevOps policies currently support SQL-type data sources and can be configured on individual data sources, resource groups and subscriptions. DevOps policies can only be created if the data source is first registered in Microsoft Purview with the option *Data use management enabled*. The data resource path is the composition of subscription > resource group > data source.

-#### Hierarchical enforcement of policies

-Bob and Alice are DevOps users at their company. Given their role, they need to log in to dozens of Azure SQL logical servers to monitor their performance so that critical DevOps processes donΓÇÖt break. Their manager, Mateo, creates an Azure AD group and includes Alice and Bob. He then uses Microsoft Purview DevOps policies (Policy 1 in the diagram below) to grant this Azure AD group access at resource group level, to Resource Group 1, which hosts the Azure SQL servers.

-| **Microsoft Purview policy action** | **Data source specific actions** |

-|[Data Estate Insights](#data-estate-insights-app) | Gives you an overview of your data estate to help you discover what kinds of data you have and where. |

- - Path to support SaaS, on-premises, and multicloud data sources

- - Path to leverage all associated metadata for policies

-* [DevOps policies](concept-policies-devops.md): Provision access for IT operations and other DevOps users from Microsoft Purview Studio, enabling them to monitor SQL database system health and security, while limiting insider threat.

-Lastly, Microsoft Purview Data Policy app applies the metadata in the Data Map, providing a superior solution to keep your data secure.

-* Structure and simplify the process of granting/revoking access.

-* Reduce the effort of access provisioning.

-* Access decision in Microsoft data systems has negligible latency penalty.

-* Enhanced security:

- - Easier to review access/revoke it in a central vs. distributed access provisioning model.

- - Reduced need for privileged accounts to configure access.

- - Support Principle of Least Privilege (give people the appropriate level of access, limiting to the minimum permissions and the least data objects).

-> | `use_custom_dns_a_registration` | Use an existing Private DNS zone | Optional |

-> | `dns_label` | DNS name of the private DNS zone | Optional |