-## June 2024

-### Updated articles

-* [AI hub gateway landing zone accelerator](https://github.com/Azure-Samples/ai-hub-gateway-solution-accelerator)

- <key>Base64 encoded signing key | certificate-id="mycertificate"</key>

-| decryption-keys | A list of Base64-encoded keys, in [`key`](#key-attributes) subelements, used to decrypt the tokens. If multiple security keys are present, then each key is tried until either all keys are exhausted (in which case validation fails) or a key succeeds.<br/><br/>To decrypt a token encrypted with an asymmetric key, optionally specify the public key using a `certificate-id` attribute with value set to the identifier of a certificate uploaded to API Management. | No |

-| certificate-id | Identifier of a certificate entity [uploaded](/rest/api/apimanagement/apimanagementrest/azure-api-management-rest-api-certificate-entity#Add) to API Management, used to specify the public key to verify a token signed with an asymmetric key. | No | N/A |

- <key>Base64 encoded signing key | certificate-id="mycertificate" | n="modulus" e="exponent"</key>

- <key>Base64 encoded signing key | certificate-id="mycertificate" | n="modulus" e="exponent" </key>

-| decryption-keys | A list of Base64-encoded keys, in [`key`](#key-attributes) subelements, used to decrypt the tokens. If multiple security keys are present, then each key is tried until either all keys are exhausted (in which case validation fails) or a key succeeds.<br/><br/>Optionally specify a key by using the `id` attribute to match a `kid` claim. To decrypt a token encrypted with an asymmetric key, optionally specify the public key using a `certificate-id` attribute with value set to the identifier of a certificate uploaded to API Management, or the RSA modulus `n` and exponent `e` pair of the key in Base64url-encoded format. | No |

-| id | String. Identifier used to match `kid` claim presented in JWT. | No | N/A |

-| n | Modulus of the public key used to verify the issuer of a token signed with an asymmetric key. Must be specified with the value of the exponent `e`. Policy expressions aren't allowed. | No | N/A|

-| e | Exponent of the public key used to verify the issuer of a token signed with an asymmetric key. Must be specified with the value of the modulus `n`. Policy expressions aren't allowed. | No | N/A|

-The authenticated session expires after 8 hours. After an authenticated session expires, there is a 72-hour grace period by default. Within this grace period, you're allowed to refresh the session token with App Service without reauthenticating the user. You can just call `/.auth/refresh` when your session token becomes invalid, and you don't need to track token expiration yourself. Once the 72-hour grace period is lapses, the user must sign in again to get a valid session token.

- # [Windows](#tab/windows)

- ```azurecli

- az webapp config appsettings set -n <webapp-name> -g <resource-group> --settings "APPINSIGHTS_INSTRUMENTATIONKEY=<instrumentationKey>" "APPLICATIONINSIGHTS_CONNECTION_STRING=<connectionString>" "ApplicationInsightsAgent_EXTENSION_VERSION=~3" "XDT_MicrosoftApplicationInsights_Mode=default" "XDT_MicrosoftApplicationInsights_Java=1"

- ```

-# [Windows](#tab/windows)

-# [Linux](#tab/linux)

-# [Windows](#tab/windows)

-3. Use the [Kudu console](https://github.com/projectkudu/kudu/wiki/Kudu-console) to create a new directory */home/site/wwwroot/apm*.

-

-# [Linux](#tab/linux)

-3. [SSH into your App Service instance](configure-linux-open-ssh-session.md) and create a new directory */home/site/wwwroot/apm*.

-# [Windows](#tab/windows)

-# [Linux](#tab/linux)

-# [Windows](#tab/windows)

-# [Linux](#tab/linux)

-# [Linux](#tab/linux)

-Adding a shared, server-level data source requires you to edit Tomcat's server.xml. The most reliable way to do this is as follows:

-1. Upload a [startup script](./faq-app-service-linux.yml) and set the path to the script in **Configuration** > **Startup Command**. You can upload the startup script using [FTP](deploy-ftp.md).

-Your startup script makes an [xsl transform](https://www.w3schools.com/xml/xsl_intro.asp) to the server.xml file and output the resulting xml file to `/usr/local/tomcat/conf/server.xml`. The startup script should install libxslt via apk. Your xsl file and startup script can be uploaded via FTP. Below is an example startup script.

-```sh

-# Install libxslt. Also copy the transform file to /home/tomcat/conf/

-apk add --update libxslt

-# Usage: xsltproc --output output.xml style.xsl input.xml

-xsltproc --output /home/tomcat/conf/server.xml /home/tomcat/conf/transform.xsl /usr/local/tomcat/conf/server.xml

-```

-The following example XSL file adds a new connector node to the Tomcat server.xml.

-```xml

-<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

- <xsl:output method="xml" indent="yes"/>

- <xsl:template match="@* | node()" name="Copy">

- <xsl:copy>

- <xsl:apply-templates select="@* | node()"/>

- </xsl:copy>

- </xsl:template>

- <xsl:template match="@* | node()" mode="insertConnector">

- <xsl:call-template name="Copy" />

- </xsl:template>

- <xsl:template match="comment()[not(../Connector[@scheme = 'https']) and

- contains(., '&lt;Connector') and

- (contains(., 'scheme=&quot;https&quot;') or

- contains(., &quot;scheme='https'&quot;))]">

- <xsl:value-of select="." disable-output-escaping="yes" />

- </xsl:template>

- <xsl:template match="Service[not(Connector[@scheme = 'https'] or

- comment()[contains(., '&lt;Connector') and

- (contains(., 'scheme=&quot;https&quot;') or

- contains(., &quot;scheme='https'&quot;))]

- )]

- ">

- <xsl:copy>

- <xsl:apply-templates select="@* | node()" mode="insertConnector" />

- </xsl:copy>

- </xsl:template>

- <!-- Add the new connector after the last existing Connnector if there's one -->

- <xsl:template match="Connector[last()]" mode="insertConnector">

- <xsl:call-template name="Copy" />

- <xsl:call-template name="AddConnector" />

- </xsl:template>

- <!-- ... or before the first Engine if there's no existing Connector -->

- <xsl:template match="Engine[1][not(preceding-sibling::Connector)]"

- mode="insertConnector">

- <xsl:call-template name="AddConnector" />

- <xsl:call-template name="Copy" />

- </xsl:template>

- <xsl:template name="AddConnector">

- <!-- Add new line -->

- <xsl:text>&#xa;</xsl:text>

- <!-- This is the new connector -->

- <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"

- maxThreads="150" scheme="https" secure="true"

- keystoreFile="${{user.home}}/.keystore" keystorePass="changeit"

- clientAuth="false" sslProtocol="TLS" />

- </xsl:template>

-

-</xsl:stylesheet>

-```

-#### Finalize configuration

-Finally, place the driver JARs in the Tomcat classpath and restart your App Service.

-1. Ensure that the JDBC driver files are available to the Tomcat classloader by placing them in the */home/site/lib* directory. In the [Cloud Shell](https://shell.azure.com), run `az webapp deploy --type=lib` for each driver JAR:

-```azurecli-interactive

-az webapp deploy --resource-group <group-name> --name <app-name> --src-path <jar-name>.jar --type=lib --path <jar-name>.jar

-```

-If you created a server-level data source, restart the App Service Linux application. Tomcat resets `CATALINA_BASE` to `/home/tomcat` and uses the updated configuration.

-# [Windows](#tab/windows)

-az webapp config show --name <app-name> --resource-group <resource-group-name> --query "[javaVersion, javaContainer, javaContainerVersion]"

-az webapp list-runtimes --os windows | grep java

-# [Linux](#tab/linux)

-az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

-az webapp list-runtimes --os linux | grep "JAVA\|TOMCAT\|JBOSSEAP"

-# [Windows](#tab/windows)

-# [Windows](#tab/windows)

-#### Timed Recording

-To take a timed recording, you need the PID (Process ID) of the Java application. To find the PID, open a browser to your web app's SCM site at `https://<your-site-name>.scm.azurewebsites.net/ProcessExplorer/`. This page shows the running processes in your web app. Find the process named "java" in the table and copy the corresponding PID (Process ID).

-Next, open the **Debug Console** in the top toolbar of the SCM site and run the following command. Replace `<pid>` with the process ID you copied earlier. This command starts a 30-second profiler recording of your Java application and generates a file named `timed_recording_example.jfr` in the `C:\home` directory.

-```

-jcmd <pid> JFR.start name=TimedRecording settings=profile duration=30s filename="C:\home\timed_recording_example.JFR"

-```

-# [Windows](#tab/windows)

-Enable [application logging](troubleshoot-diagnostic-logs.md#enable-application-logging-windows) through the Azure portal or [Azure CLI](/cli/azure/webapp/log#az-webapp-log-config) to configure App Service to write your application's standard console output and standard console error streams to the local filesystem or Azure Blob Storage. Logging to the local App Service filesystem instance is disabled 12 hours after you enable it. If you need longer retention, configure the application to write output to a Blob storage container.

-# [Linux](#tab/linux)

-Enable [application logging](troubleshoot-diagnostic-logs.md#enable-application-logging-linuxcontainer) through the Azure portal or [Azure CLI](/cli/azure/webapp/log#az-webapp-log-config) to configure App Service to write your application's standard console output and standard console error streams to the local filesystem or Azure Blob Storage. If you need longer retention, configure the application to write output to a Blob storage container.

-Azure Blob Storage logging for Linux based apps can only be configured using [Azure Monitor](./troubleshoot-diagnostic-logs.md#send-logs-to-azure-monitor).

-> The AzureRM PowerShell module has been officially deprecated as of **February 29, 2024**. We recommend that you migrate from AzureRM module to the Az PowerShell module to ensure continued support and updates. While the AzureRM module may still work, it is no longer maintained or supported and continued use of AzureRM is at the user's own risk. For more information, see [migration resources](https://aka.ms/azpsmigrate) for guidance on transitioning to the Az module.

-To upgrade the Snowflake linked service, create a new Snowflake linked service and configure it by referring to [Linked service properties](#linked-service-properties).

-1. Select **Download script**. For example:

-1. Copy the script to a local drive and unzip it. The following files appear:

- - `start.bat`

- - `settings.json`

- - `data.bin`

- - `run.bat`

-1. Run the `run.bat` file.

- After the script runs to probe the registry, a CX-snapshot file appears with the registry information. The filename indicates the machine name and the current date and time of the snapshot with the following syntax: `cx_snapshot_[machinename]_[current date time]`.

-Files generated by the script include:

-### Create alert exclusion rules on an on-premises management console

-We recommend creating alert exclusion rules on an on-premises management console only for locally managed sensors. For cloud-connected sensors, any suppression rules created on the Azure portal will override exclusion rules created on the on-premises management console for that sensor.

-**To create an alert exclusion rule**:

-1. Sign into your on-premises management console and select **Alert Exclusion** on the left-hand menu.

-1. On the **Alert Exclusion** page, select the **+** button at the top-right to add a new rule.

-1. In the **Create Exclusion Rule** dialog, enter the following details:

- |Name |Description |

- |||

- |**Name** | Enter a meaningful name for your rule. The name can't contain quotes (`"`). |

- |**By Time Period** | Select a time zone and the specific time period you want the exclusion rule to be active, and then select **ADD**. <br><br>Use this option to create separate rules for different time zones. For example, you might need to apply an exclusion rule between 8:00 AM and 10:00 AM in three different time zones. In this case, create three separate exclusion rules that use the same time period and the relevant time zone. |

- |**By Device Address** | Select and enter the following values, and then select **ADD**: <br><br>- Select whether the designated device is a source, destination, or both a source and destination device. <br>- Select whether the address is an IP address, MAC address, or subnet <br>- Enter the value of the IP address, MAC address, or subnet. |

- |**By Alert Title** | Select one or more alerts to add to the exclusion rule and then select **ADD**. To find alert titles, enter all, or part of an alert title and select the one you want from the dropdown list. |

- |**By Sensor Name** | Select one or more sensors to add to the exclusion rule and then select **ADD**. To find sensor names, enter all or part of the sensor name and select the one you want from the dropdown list. |

- > [!IMPORTANT]

- > Alert exclusion rules are `AND` based, which means that alerts are only excluded when all rule conditions are met.

- > If a rule condition is not defined, all options are included. For example, if you don't include the name of a sensor in the rule, the rule is applied to all sensors.

- A summary of the rule parameters is shown at the bottom of the dialog.

-1. Check the rule summary shown at the bottom of the **Create Exclusion Rule** dialog and then select **SAVE**

-**To create alert exclusion rules via API**:

-Use the [Defender for IoT API](references-work-with-defender-for-iot-apis.md) to create on-premises management console alert exclusion rules from an external ticketing system or other system that manage network maintenance processes.

-Use the [maintenanceWindow (Create alert exclusions)](api/management-alert-apis.md#maintenancewindow-create-alert-exclusions) API to define the sensors, analytics engines, start time, and end time to apply the rule. Exclusion rules created via API are shown in the on-premises management console as read-only.

-For more information, see [Defender for IoT API reference](references-work-with-defender-for-iot-apis.md).

-1. Select **Submit** to save your changes.

-For more information, see

-[Defender for IoT API reference](references-work-with-defender-for-iot-apis.md).

-1. In the **Validation of on-premises management console certificate** area, select **Mandatory** to validate an on-premises management console's certificate against a certificate revocation list (CRL), as [configured in your certificate](../best-practices/certificate-requirements.md#crt-file-requirements).

- The `Package configuration` Linux configuration wizard opens. In this wizard, use the up or down arrows to navigate, and the **SPACE** bar to select an option. Press **ENTER** to advance to the next screen.

-1. In the wizard's `Select monitor interfaces` screen, select any of the interfaces you want to monitor with this sensor.

- The system selects the first interface it finds as the management interface, and we recommend that you leave the default selection. If you decide to use a different port as the management interface, the change is implemented only after the sensor restarts. In such cases, make sure that the sensor is connected as needed.

- For example:

- :::image type="content" source="../media/install-software-ot-sensor/select-monitor-interfaces.png" alt-text="Screenshot of the Select monitor interfaces screen.":::

- > [!IMPORTANT]

- > Make sure that you select only interfaces that are connected.

- >

- > If you select interfaces that are enabled but not connected, the sensor will show a *No traffic monitored* health notification in the Azure portal. If you connect more traffic sources after installation and want to monitor them with Defender for IoT, you can add them later via the [CLI](../references-work-with-defender-for-iot-cli-commands.md).

-1. In the `Select management interface` screen, select the interface you want to use to connect to the Azure portal or an on-premises management console.

- For example:

- :::image type="content" source="../media/install-software-ot-sensor/select-management-interface.png" alt-text="Screenshot of the Select management interface screen.":::

-1. In the `Enter sensor IP address` screen, enter the IP address you want to use for this sensor. Use this IP address to connect to the sensor via CLI or the browser. For example:

- :::image type="content" source="../media/install-software-ot-sensor/enter-sensor-ip-address.png" alt-text="Screenshot of the Enter sensor IP address screen.":::

-1. In the `Enter path to the mounted backups folder` screen, enter the path to the sensor's mounted backups. We recommend using the default path of `/opt/sensor/persist/backups`. For example:

- :::image type="content" source="../media/install-software-ot-sensor/mounted-backups.png" alt-text="Screenshot of the mounted backups folder configuration.":::

-1. In the `Enter Subnet Mask` screen, enter the IP address for the sensor's subnet mask. For example:

- :::image type="content" source="../media/install-software-ot-sensor/subnet-mask.png" alt-text="Screenshot of the Enter Subnet Mask screen.":::

-1. In the `Enter Gateway` screen, enter the sensor's default gateway IP address. For example:

- :::image type="content" source="../media/install-software-ot-sensor/enter-gateway.png" alt-text="Screenshot of the Enter Gateway screen.":::

-1. In the `Enter DNS server` screen, enter the sensor's DNS server IP address. For example:

- :::image type="content" source="../media/install-software-ot-sensor/enter-dns-server.png" alt-text="Screenshot of the Enter DNS server screen.":::

-1. In the `Enter hostname` screen, enter a name you want to use as the sensor hostname. Make sure that you use the same hostname as is defined in the DNS server. For example:

- :::image type="content" source="../media/install-software-ot-sensor/enter-hostname.png" alt-text="Screenshot of the Enter hostname screen.":::

-1. In the `Run this sensor as a proxy server (Preview)` screen, select `<Yes>` only if you want to configure a proxy, and then enter the proxy credentials as prompted. For more information, see [Configure proxy settings on an OT sensor](../connect-sensors.md).

- The default configuration is without a proxy.

-1. The configuration process starts running, reboots, and then prompts you to sign in again. For example:

- :::image type="content" source="../media/install-software-ot-sensor/final-cli-sign-in.png" alt-text="Screenshot of the final sign-in prompt at the end of the initial CLI configuration.":::

-At this point, open a browser to the IP address you'd defined for your sensor and continue the setup in the browser. For more information, see [Activate your OT sensor](#activate-your-ot-sensor).

-| **OT networks** | - [Security update](#security-update) |

-Azure DevTest Labs makes it easy to create VMs in a lab with [built-in networking](devtest-lab-configure-vnet.md). It has a great deal of flexibility with the ability to [create multi-VM environments](devtest-lab-test-env.md). This article shows you how to connect VMs in an environment to the lab virtual network. One scenario where you use this feature is setting up an N-tier app with a SQL Server data tier that is connected to the lab VNet allowing test VMs in the lab to access it.

-description: Learn how DevTest Labs makes it easy to create, manage, and monitor Azure virtual machines and environments.

-[Azure DevTest Labs](https://azure.microsoft.com/services/devtest-lab) is a service for easily creating, using, and managing infrastructure-as-a-service (IaaS) virtual machines (VMs) and platform-as-a-service (PaaS) environments in labs. Labs offer preconfigured bases and artifacts for creating VMs, and Azure Resource Manager (ARM) templates for creating environments like Azure Web Apps or SharePoint farms.

-Lab owners can create preconfigured VMs that have tools and software lab users need. Lab users can claim preconfigured VMs, or create and configure their own VMs and environments. Lab policies and other methods track and control lab usage and costs.

-Common [DevTest Labs scenarios](devtest-lab-guidance-get-started.md) include development VMs, test environments, and classroom or training labs. DevTest Labs promotes efficiency, consistency, and cost control by keeping all resource usage within the lab context.

-DevTest Labs can use custom images, formulas, artifacts, and templates to create and manage labs, VMs, and environments. The [DevTest Labs public GitHub repository](https://github.com/Azure/azure-devtestlab) has many ready-to-use VM artifacts and ARM templates for creating labs, environments, or sandbox resource groups. Lab owners can also create [custom images](devtest-lab-create-custom-image-from-vm-using-portal.md), [formulas](devtest-lab-manage-formulas.md), and ARM templates to use for creating and managing labs, [VMs](devtest-lab-use-resource-manager-template.md#view-edit-and-save-arm-templates-for-vms), and [environments](devtest-lab-create-environment-from-arm.md).

-DevTest Labs users can quickly and easily create [IaaS VMs](devtest-lab-add-vm.md) and [PaaS environments](devtest-lab-create-environment-from-arm.md) from preconfigured bases, artifacts, and templates. Developers, testers, and trainers can:

-As a lab owner, you can use a managed identity to deploy environments in a lab. This feature helps in scenarios where the environment contains or has references to Azure resources that are outside the environmentΓÇÖs resource group. These resources include key vaults, shared image galleries, and networks. Managed identities enable creation of sandbox environments that aren't limited to the resource group of that environment.

-By default, when you create an environment, the lab creates a system-assigned identity while deploying the Azure Resource Manager template (ARM template). The system-assigned identity accesses Azure resources and services on a lab userΓÇÖs behalf. DevTest Labs creates a system-assigned identity by default the first time it creates the lab environment. Learn more about [why a lab creates a system-assigned identity](configure-lab-identity.md#scenarios-for-using-labs-system-assigned-identity).

-As a lab owner, you can choose to grant the labΓÇÖs system-assigned identity permissions to access Azure resources outside the lab. You can also use your user-assigned identity for the scenario. The labΓÇÖs system-assigned identity is valid only for the life of the lab. The system-assigned identify is deleted when you delete the lab. When you have environments in multiple labs that need to use an identity, consider using a user-assigned identity.

-> [!NOTE]

-The private access endpoint uses an IP address from your Azure VNet address space. Network traffic between a client on your private network and the Azure Digital Twins instance traverses over the VNet and a Private Link on the Microsoft backbone network, eliminating exposure to the public internet. Here's a visual representation of this system:

-plugin.path={KAFKA.DIRECTORY}/libs # path to the libs directory within the Kafka release

-zone_pivot_groups: expressroute-experience

->

->

-1. Sign in to the Azure portal with this [Preview link](https://aka.ms/expressrouteguidedportal). This link is required to access the new preview connection create experience to an ExpressRoute circuit.

- :::image type="content" source="./media/expressroute-howto-linkvnet-portal-resource-manager/create-connection-basic-new.png" alt-text="Screenshot of create a connection basic page.":::

-4. Enter a name for the connection and then select **Next: Settings >**.

- :::image type="content" source="./media/expressroute-howto-linkvnet-portal-resource-manager/create-connection-basic.png" alt-text="Create connection basic page":::

-5. Select the gateway that belongs to the virtual network that you want to link to the circuit and select **Review + create**. Then select **Create** after validation completes.

- :::image type="content" source="./media/expressroute-howto-linkvnet-portal-resource-manager/create-connection-settings.png" alt-text="Create connection settings page":::

-6. After your connection has been successfully configured, your connection object will show the information for the connection.

- :::image type="content" source="./media/expressroute-howto-linkvnet-portal-resource-manager/connection-object.png" alt-text="Connection object screenshot":::

-1. Make sure the *Connection type* is set to **ExpressRoute**. Select the *Resource group* and *Location*, then select **OK** in the Basics page.

- > [!NOTE]

- > The location *must* match the virtual network gateway location you're creating the connection for.

-1. In the **Settings** page, Select the *Virtual network gateway* and check the **Redeem authorization** check box. Enter the *Authorization key* and the *Peer circuit URI* and give the connection a name. Select **OK**.

- > The *Peer Circuit URI* is the Resource ID of the ExpressRoute circuit (which you can find under the Properties Setting pane of the ExpressRoute Circuit).

-1. Review the information in the **Summary** page and select **OK**.

-You can enable [ExpressRoute FastPath](expressroute-about-virtual-network-gateways.md) if your virtual network gateway is Ultra Performance or ErGw3AZ. FastPath improves data path performance such as packets per second and connections per second between your on-premises network and your virtual network.

-**Configure FastPath on a new connection**

->

-**Configure FastPath on an existing connection**

->

-## Next steps

-|Azure private DNS zone isn't supported with Azure Firewall|Azure private DNS zone doesn't work with Azure Firewall regardless of Azure Firewall DNS settings.|To achieve the desire state of using a private DNS server, use Azure Firewall DNS proxy instead of an Azure private DNS zone.|

-Deploy the Azure voting app application by copying the following yaml to a file named `example.yaml`.

-```yaml

-# voting-storage-deployment.yaml

-apiVersion: apps/v1

-kind: Deployment

-metadata:

- name: voting-storage

-spec:

- replicas: 1

- selector:

- matchLabels:

- app: voting-storage

- template:

- metadata:

- labels:

- app: voting-storage

- spec:

- containers:

- - name: voting-storage

- image: mcr.microsoft.com/azuredocs/voting/storage:2.0

- args: ["--ignore-db-dir=lost+found"]

- resources:

- requests:

- cpu: 100m

- memory: 128Mi

- limits:

- cpu: 250m

- memory: 256Mi

- ports:

- - containerPort: 3306

- name: mysql

- volumeMounts:

- - name: mysql-persistent-storage

- mountPath: /var/lib/mysql

- env:

- - name: MYSQL_ROOT_PASSWORD

- valueFrom:

- secretKeyRef:

- name: voting-storage-secret

- key: MYSQL_ROOT_PASSWORD

- - name: MYSQL_USER

- valueFrom:

- secretKeyRef:

- name: voting-storage-secret

- key: MYSQL_USER

- - name: MYSQL_PASSWORD

- valueFrom:

- secretKeyRef:

- name: voting-storage-secret

- key: MYSQL_PASSWORD

- - name: MYSQL_DATABASE

- valueFrom:

- secretKeyRef:

- name: voting-storage-secret

- key: MYSQL_DATABASE

- volumes:

- - name: mysql-persistent-storage

- persistentVolumeClaim:

- claimName: mysql-pv-claim

-# voting-storage-secret.yaml

-apiVersion: v1

-kind: Secret

-metadata:

- name: voting-storage-secret

-type: Opaque

-data:

- MYSQL_USER: ZGJ1c2Vy

- MYSQL_PASSWORD: UGFzc3dvcmQxMg==

- MYSQL_DATABASE: YXp1cmV2b3Rl

- MYSQL_ROOT_PASSWORD: UGFzc3dvcmQxMg==

-# voting-storage-pv-claim.yaml

-apiVersion: v1

-kind: PersistentVolumeClaim

-metadata:

- name: mysql-pv-claim

-spec:

- accessModes:

- - ReadWriteOnce

- resources:

- requests:

- storage: 1Gi

-# voting-storage-service.yaml

-apiVersion: v1

-kind: Service

-metadata:

- name: voting-storage

- labels:

- app: voting-storage

-spec:

- ports:

- - port: 3306

- name: mysql

- selector:

- app: voting-storage

-# voting-app-deployment.yaml

-apiVersion: apps/v1

-kind: Deployment

-metadata:

- name: voting-app

-spec:

- replicas: 1

- selector:

- matchLabels:

- app: voting-app

- template:

- metadata:

- labels:

- app: voting-app

- spec:

- containers:

- - name: voting-app

- image: mcr.microsoft.com/azuredocs/voting/app:2.0

- imagePullPolicy: Always

- ports:

- - containerPort: 8080

- name: http

- env:

- - name: MYSQL_HOST

- value: "voting-storage"

- - name: MYSQL_USER

- valueFrom:

- secretKeyRef:

- name: voting-storage-secret

- key: MYSQL_USER

- - name: MYSQL_PASSWORD

- valueFrom:

- secretKeyRef:

- name: voting-storage-secret

- key: MYSQL_PASSWORD

- - name: MYSQL_DATABASE

- valueFrom:

- secretKeyRef:

- name: voting-storage-secret

- key: MYSQL_DATABASE

- - name: ANALYTICS_HOST

- value: "voting-analytics"

-# voting-app-service.yaml

-apiVersion: v1

-kind: Service

-metadata:

- name: voting-app

- labels:

- app: voting-app

-spec:

- type: LoadBalancer

- ports:

- - port: 80

- targetPort: 8080

- name: http

- selector:

- app: voting-app

-# voting-analytics-deployment.yaml

-apiVersion: apps/v1

-kind: Deployment

-metadata:

- name: voting-analytics

-spec:

- replicas: 1

- selector:

- matchLabels:

- app: voting-analytics

- version: "2.0"

- template:

- metadata:

- labels:

- app: voting-analytics

- version: "2.0"

- spec:

- containers:

- - name: voting-analytics

- image: mcr.microsoft.com/azuredocs/voting/analytics:2.0

- imagePullPolicy: Always

- ports:

- - containerPort: 8080

- name: http

- env:

- - name: MYSQL_HOST

- value: "voting-storage"

- - name: MYSQL_USER

- valueFrom:

- secretKeyRef:

- name: voting-storage-secret

- key: MYSQL_USER

- - name: MYSQL_PASSWORD

- valueFrom:

- secretKeyRef:

- name: voting-storage-secret

- key: MYSQL_PASSWORD

- - name: MYSQL_DATABASE

- valueFrom:

- secretKeyRef:

- name: voting-storage-secret

- key: MYSQL_DATABASE

-# voting-analytics-service.yaml

-apiVersion: v1

-kind: Service

-metadata:

- name: voting-analytics

- labels:

- app: voting-analytics

-spec:

- ports:

- - port: 8080

- name: http

- selector:

- app: voting-analytics

-```

-Deploy the service by running:

-```bash

-kubectl apply -f example.yaml

-```

-NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

-kubernetes ClusterIP 10.41.0.1 <none> 443/TCP 10h

-voting-analytics ClusterIP 10.41.88.129 <none> 8080/TCP 9m

-voting-app LoadBalancer 10.41.185.82 20.39.18.6 80:32718/TCP 9m

-voting-storage ClusterIP 10.41.221.201 <none> 3306/TCP 9m

-SERVICE_IP=$(kubectl get svc voting-app -o jsonpath='{.status.loadBalancer.ingress[*].ip}')

-You should see the AKS voting app. In this example, the Firewall public IP was `203.0.113.32`.

-This section focuses on how Front Door matches to a routing rule. The basic concept is that Front Door always matches to the **most-specific request** looking only at the "left-hand side". Front Door first match based on protocol, then domain, and last the path.

-_Audit_ and _deny_ must provide **details** properties

- replicasets and pods. When a user executes `kubectl describe deployment $MY_DEPLOYMENT`, it doesn't return a rejection message as part of events. However,

-Introducing expansion, a shift left feature that lets you know up front whether your workload resources (Deployments, ReplicaSets, Jobs, etc.) will produce admissible pods. Expansion shouldn't change the behavior of your policies; rather, it just shifts Gatekeeper's evaluation of pod-scoped policies to occur at workload admission time rather than pod admission time. However, to perform this evaluation it must generate and evaluate a what-if pod that is based on the pod spec defined in the workload, which may have incomplete metadata. For instance, the what-if pod will not contain the proper owner references. Because of this small risk of policy behavior changing, we're introducing expansion as disabled by default. To enable expansion for a given policy definition, set `.policyRule.then.details.source` to `All`. Built-ins will be updated soon to enable parameterization of this field. If you test your policy definition and find that the what-if pod being generated for evaluation purposes is incomplete, you can also use a mutation with source `Generated` to mutate the what-if pods. For more information on this option, view the [Gatekeeper documentation](https://open-policy-agent.github.io/gatekeeper/website/docs/expansion#mutating-example).

- "addons": [{

- }]

-Changing the Gatekeeper config is unsupported, as it contains critical security settings. Edits to the config will be reconciled.

-Currently, several built-in policies make use of [data replication](https://open-policy-agent.github.io/gatekeeper/website/docs/sync), which enables users to sync existing on-cluster resources to the OPA cache and reference them during evaluation of an AdmissionReview request. Data replication policies can be differentiated by the presence of `data.inventory` in the Rego, as well as the presence of the `metadata.gatekeeper.sh/requires-sync-data` annotation, which informs the Azure Policy addon what resources need to be cached for policy evaluation to work properly. (Note that this differs from standalone Gatekeeper, where this annotation is descriptive, not prescriptive.)

-Data replication is currently blocked for use in custom policy definitions, because replicating resources with high instance counts can dramatically increase the Gatekeeper pods\' resource usage if not used carefully. You will see a `ConstraintTemplateInstallFailed` error when attempting to create a custom policy definition containing a constraint template with this annotation.

-> Removing the annotation may appear to mitigate the error you see, but then the policy addon will not sync any required resources for that constraint template into the cache. Thus, your policies will be evaluated against an empty `data.inventory` (assuming that no built-in is assigned that replicates the requisite resources). This will lead to misleading compliance results. As noted [previously](#configuring-the-gatekeeper-config), manually editing the config to cache the required resources is also not permitted.

- - For fewer than 500 pods in a single cluster with a max of 20 constraints: two vCPUs and 350 MB of memory per component.

- - For more than 500 pods in a single cluster with a max of 40 constraints: three vCPUs and 600 MB of memory per component.

- - If the cluster has `aad-pod-identity` enabled, Node Managed Identity (NMI) pods modify the nodes' iptables to intercept calls to the Azure Instance Metadata endpoint. This configuration means any request made to the Metadata endpoint is intercepted by NMI even if the pod doesn't use `aad-pod-identity`.

- - AzurePodIdentityException CRD can be configured to inform `aad-pod-identity` that any requests to the Metadata endpoint originating from a pod that matches labels defined in CRD should be proxied without any processing in NMI. The system pods with kubernetes.azure.com/managedby: aks label in kube-system namespace should be excluded in `aad-pod-identity` by configuring the AzurePodIdentityException CRD. For more information, see [Disable aad-pod-identity for a specific pod or application](https://azure.github.io/aad-pod-identity/docs/configure/application_exception). To configure an exception, install the [mic-exception YAML](https://github.com/Azure/aad-pod-identity/blob/master/deploy/infra/mic-exception.yaml).

-One of the largest benefits of Azure Policy is the insight and controls it provides over resources

-in a subscription or [management group](../../management-groups/overview.md) of subscriptions. This

-control can be used to prevent resources from being created in the

-wrong location, enforce common and consistent tag usage, or audit existing resources for

-appropriate configurations and settings. In all cases, data is generated by Azure Policy to enable

-you to understand the compliance state of your environment.

-Before reviewing compliance data, it is important to [understand compliance states](../concepts/compliance-states.md) in Azure Policy.

-There are several ways to access the compliance information generated by your policy and initiative

-assignments:

-Before looking at the methods to report on compliance, let's look at when compliance information is

-updated and the frequency and events that trigger an evaluation cycle.

-The results of a completed evaluation cycle are available in the `Microsoft.PolicyInsights` Resource

-Provider through `PolicyStates` and `PolicyEvents` operations. For more information about the

-operations of the Azure Policy Insights REST API, see

-[Azure Policy Insights](/rest/api/policy/).

- to be applied to the defined scope, then the evaluation cycle begins for applicable resources against the newly assigned policy or initiative. Depending on the effects

- used, resources are marked as compliant, non-compliant, exempt, or unknown. A

- large policy or initiative evaluated against a large scope of resources can take time, so

- there's no pre-defined expectation of when the evaluation cycle completes. Once it completes,

- updated compliance results are available in the portal and SDKs.

- this scenario is the same as for a new assignment to a scope.

- REST API, or a supported SDK. In this scenario, the effect event (append, audit, deny, deploy) and

- compliant status information for the individual resource becomes available in the portal and SDKs

- around 15 minutes later. This event doesn't cause an evaluation of other resources.

- [management group hierarchy](../../management-groups/overview.md) with an assigned policy

- definition targeting the subscription resource type. Evaluation of the subscription supported

- effects (audit, auditIfNotExist, deployIfNotExists, modify), logging, and any remediation actions

- takes around 30 minutes.

- scenario, the corresponding assignment is evaluated for the defined exemption scope.

- reevaluated. A large policy or initiative of many resources can take time, so there's no

- pre-defined expectation of when the evaluation cycle completes. Once it completes, updated

- compliance results are available in the portal and SDKs.

- compliance details by a managed resource.

-> By design, Azure Policy exempts all resources under the `Microsoft.Resources` resource provider (RP) from

-policy evaluation with the exception of subscriptions and resource groups, which can be evaluated.

-An evaluation scan for a subscription or a resource group can be started with Azure CLI, Azure

-PowerShell, a call to the REST API, or by using the

-[Azure Policy Compliance Scan GitHub Action](https://github.com/marketplace/actions/azure-policy-compliance-scan).

-This scan is an asynchronous process.

-Use the

-[Azure Policy Compliance Scan action](https://github.com/marketplace/actions/azure-policy-compliance-scan)

-to trigger an on-demand evaluation scan from your

-[GitHub workflow](https://docs.github.com/actions/writing-workflows/about-workflows)

-on one or multiple resources, resource groups, or subscriptions, and gate the workflow based on the

-compliance state of resources. You can also configure the workflow to run at a scheduled time so

-that you get the latest compliance status at a convenient time. Optionally, GitHub Actions can

-generate a report on the compliance state of scanned resources for further analysis or for

-archiving.

-For more information and workflow samples, see the

-[GitHub Actions for Azure Policy Compliance Scan repo](https://github.com/Azure/policy-compliance-scan).

-The compliance scan is started with the

-[az policy state trigger-scan](/cli/azure/policy/state#az-policy-state-trigger-scan) command.

-By default, `az policy state trigger-scan` starts an evaluation for all resources in the current

-subscription. To start an evaluation on a specific resource group, use the **resource-group**

-parameter. The following example starts a compliance scan in the current subscription for the _MyRG_

-resource group:

-You can choose not to wait for the asynchronous process to complete before continuing with the

-**no-wait** parameter.

-The compliance scan is started with the

-[Start-AzPolicyComplianceScan](/powershell/module/az.policyinsights/start-azpolicycompliancescan)

-cmdlet.

-By default, `Start-AzPolicyComplianceScan` starts an evaluation for all resources in the current

-subscription. To start an evaluation on a specific resource group, use the **ResourceGroupName**

-parameter. The following example starts a compliance scan in the current subscription for the _MyRG_

-resource group:

-You can have PowerShell wait for the asynchronous call to complete before providing the results

-output or have it run in the background as a

-[job](/powershell/module/microsoft.powershell.core/about/about_jobs). To use a PowerShell job to run

-the compliance scan in the background, use the **AsJob** parameter and set the value to an object,

-such as `$job` in this example:

-You can check on the status of the job by checking on the `$job` object. The job is of the type

-`Microsoft.Azure.Commands.Common.AzureLongRunningJob`. Use `Get-Member` on the `$job` object to see

-available properties and methods.

-When the compliance scan completes, the **State** property changes to _Completed_.

-As an asynchronous process, the REST endpoint to start the scan doesn't wait until the scan is

-complete to respond. Instead, it provides a URI to query the status of the requested evaluation.

-In each REST API URI, there are variables that are used that you need to replace with your own

-values:

-The scan supports evaluation of resources in a subscription or in a resource group. Start a scan by

-scope with a REST API **POST** command using the following URI structures:

-The call returns a **202 Accepted** status. Included in the response header is a **Location**

-`{ResourceContainerGUID}` is statically generated for the scope requested. If a scope is already

-running an on-demand scan, a new scan isn't started. Instead, the new request is provided the same

-`{ResourceContainerGUID}` **location** URI for status. A REST API **GET** command to the

-**Location** URI returns a **202 Accepted** while the evaluation is ongoing. When the evaluation

-scan has completed, it returns a **200 OK** status. The body of a completed scan is a JSON response

-with the status:

- "status": "Succeeded"

-The Azure Policy extension for Visual Studio Code is capable of running an evaluation scan for a

-specific resource. This scan is a synchronous process, unlike the Azure PowerShell and REST methods.

-For details and steps, see

-[On-demand evaluation with the VS Code extension](./extension-for-vscode.md#on-demand-evaluation-scan).

-The Azure portal showcases a graphical experience of visualizing and understanding the state of

-compliance in your environment. On the **Policy** page, the **Overview** option provides details for

-available scopes on the compliance of both policies and initiatives. Along with the compliance state

-and count per assignment, it contains a chart showing compliance over the last seven days. The

-**Compliance** page contains much of this same information (except the chart), but provide

-additional filtering and sorting options.

-Since a policy or initiative can be assigned to different scopes, the table includes the scope for

-each assignment and the type of definition that was assigned. The number of non-compliant resources

-and non-compliant policies for each assignment are also provided. Selecting on a policy or

-initiative in the table provides a deeper look at the compliance for that particular assignment.

-The list of resources on the **Resource compliance** tab shows the evaluation status of existing

-resources for the current assignment. The tab defaults to **Non-compliant**, but can be filtered.

-Events (append, audit, deny, deploy, modify) triggered by the request to create a resource are shown

-under the **Events** tab.

-For [Resource Provider mode](../concepts/definition-structure.md#resource-provider-modes) resources,

-on the **Resource compliance** tab, selecting the resource or right-clicking on the row and

-selecting **View compliance details** opens the component compliance details. This page also offers

-tabs to see the policies that are assigned to this resource, events, component events, and change

-history.

-Back on the resource compliance page, select and hold (or right-click) on the row of the event you

-would like to gather more details on and select **Show activity logs**. The activity log page opens

-and is pre-filtered to the search showing details for the assignment and the events. The activity

-log provides more context and information about those events.

-The same information available in the portal can be retrieved with the REST API (including with

-[ARMClient](https://github.com/projectkudu/ARMClient)), Azure PowerShell, and Azure CLI. For full

-details on the REST API, see the [Azure Policy](/rest/api/policy/) reference. The REST API reference

-pages have a green 'Try It' button on each operation that allows you to try it right in the browser.

-With the REST API, summarization can be performed by container, definition, or assignment. Here's

-an example of summarization at the subscription level using Azure Policy Insight's [Summarize For

-Subscription](/rest/api/policy/policy-states/summarize-for-subscription):

-The output summarizes the subscription. In the example output below, the summarized compliance are

-under **value.results.nonCompliantResources** and **value.results.nonCompliantPolicies**. This

-request provides further details, including each assignment that made up the non-compliant numbers

-and the definition information for each assignment. Each policy object in the hierarchy provides a

-**queryResultsUri** that can be used to get more detail at that level.

- "@odata.context": "https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policyStates/$metadata#summary",

- "@odata.count": 1,

- "value": [{

- "@odata.id": null,

- "@odata.context": "https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policyStates/$metadata#summary/$entity",

- "results": {

- "queryResultsUri": "https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policyStates/latest/queryResults?api-version=2019-10-01&$from=2018-05-18 04:28:22Z&$to=2018-05-19 04:28:22Z&$filter=ComplianceState eq 'NonCompliant'",

- },

- "policyAssignments": [{

- "policyAssignmentId": "/subscriptions/{subscriptionId}/resourcegroups/rg-tags/providers/microsoft.authorization/policyassignments/37ce239ae4304622914f0c77",

- "policySetDefinitionId": "",

- "results": {

- "queryResultsUri": "https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policyStates/latest/queryResults?api-version=2019-10-01&$from=2018-05-18 04:28:22Z&$to=2018-05-19 04:28:22Z&$filter=ComplianceState eq 'NonCompliant' and PolicyAssignmentId eq '/subscriptions/{subscriptionId}/resourcegroups/rg-tags/providers/microsoft.authorization/policyassignments/37ce239ae4304622914f0c77'",

- "nonCompliantResources": 15,

- "nonCompliantPolicies": 1

- },

- "policyDefinitions": [{

- "policyDefinitionReferenceId": "",

- "policyDefinitionId": "/providers/microsoft.authorization/policydefinitions/1e30110a-5ceb-460c-a204-c1c3969c6d62",

- "effect": "deny",

- "results": {

- "queryResultsUri": "https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policyStates/latest/queryResults?api-version=2019-10-01&$from=2018-05-18 04:28:22Z&$to=2018-05-19 04:28:22Z&$filter=ComplianceState eq 'NonCompliant' and PolicyAssignmentId eq '/subscriptions/{subscriptionId}/resourcegroups/rg-tags/providers/microsoft.authorization/policyassignments/37ce239ae4304622914f0c77' and PolicyDefinitionId eq '/providers/microsoft.authorization/policydefinitions/1e30110a-5ceb-460c-a204-c1c3969c6d62'",

- "nonCompliantResources": 15

- }

- }]

- }]

- }]

-In the example above, **value.policyAssignments.policyDefinitions.results.queryResultsUri** provides

-a sample URI for all non-compliant resources for a specific policy definition. In the

-**$filter** value, ComplianceState is equal (eq) to 'NonCompliant', PolicyAssignmentId is specified

-for the policy definition, and then the PolicyDefinitionId itself. The reason for including the

-PolicyAssignmentId in the filter is because the PolicyDefinitionId could exist in several policy or

-initiative assignments with different scopes. By specifying both the PolicyAssignmentId and the

-PolicyDefinitionId, we can be explicit in the results we're looking for. Previously, for

-PolicyStates we used **latest**, which automatically sets a **from** and **to** time window of the

-last 24-hours.

-The example response below has been trimmed to a single non-compliant resource for brevity. The

-detailed response has several pieces of data about the resource, the policy or initiative, and the

-assignment. Notice that you can also see what assignment parameters were passed to the policy

-definition.

- "@odata.context": "https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policyStates/$metadata#latest",

- "@odata.count": 15,

- "value": [{

- "@odata.id": null,

- "@odata.context": "https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policyStates/$metadata#latest/$entity",

- "timestamp": "2018-05-19T04:41:09Z",

- "resourceId": "/subscriptions/{subscriptionId}/resourceGroups/rg-tags/providers/Microsoft.Compute/virtualMachines/linux",

- "policyAssignmentId": "/subscriptions/{subscriptionId}/resourceGroups/rg-tags/providers/Microsoft.Authorization/policyAssignments/37ce239ae4304622914f0c77",

- "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/1e30110a-5ceb-460c-a204-c1c3969c6d62",

- "effectiveParameters": "",

- "ComplianceState": "NonCompliant",

- "subscriptionId": "{subscriptionId}",

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

- "resourceLocation": "westus2",

- "resourceGroup": "RG-Tags",

- "resourceTags": "tbd",

- "policyAssignmentName": "37ce239ae4304622914f0c77",

- "policyAssignmentOwner": "tbd",

- "policyAssignmentParameters": "{\"tagName\":{\"value\":\"costCenter\"},\"tagValue\":{\"value\":\"Contoso-Test\"}}",

- "policyAssignmentScope": "/subscriptions/{subscriptionId}/resourceGroups/RG-Tags",

- "policyDefinitionName": "1e30110a-5ceb-460c-a204-c1c3969c6d62",

- "policyDefinitionAction": "deny",

- "policyDefinitionCategory": "tbd",

- "policySetDefinitionId": "",

- "policySetDefinitionName": "",

- "policySetDefinitionOwner": "",

- "policySetDefinitionCategory": "",

- "policySetDefinitionParameters": "",

- "managementGroupIds": "",

- "policyDefinitionReferenceId": ""

- }]

-When a resource is created or updated, a policy evaluation result is generated. Results are called

-_policy events_. Use the following URI to view recent policy events associated with the

-subscription.

- "@odata.context": "https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policyEvents/$metadata#default",

- "@odata.count": 1,

- "value": [{

- "@odata.id": null,

- "@odata.context": "https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policyEvents/$metadata#default/$entity",

- "NumAuditEvents": 16

- }]

-For more information about querying policy events, see the

-[Azure Policy Events](/rest/api/policy/policy-events) reference article.

-The [Azure CLI](/cli/azure/what-is-azure-cli) command group for Azure Policy covers most operations

-that are available in REST or Azure PowerShell. For the full list of available commands, see

-[Azure CLI - Azure Policy Overview](/cli/azure/policy).

-Example: Getting the state summary for the topmost assigned policy with the highest number of

-non-compliant resources.

- "odatacontext": "https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policyStates/$metadata#summary/$entity",

- "odataid": null,

- "policyAssignments": [{

- "policyAssignmentId": "/subscriptions/{subscriptionId}/providers/microsoft.authorization/policyassignments/e0704696df5e4c3c81c873e8",

- "policyDefinitions": [{

- "effect": "audit",

- "policyDefinitionGroupNames": [

- ""

- ],

- "policyDefinitionId": "/subscriptions/{subscriptionId}/providers/microsoft.authorization/policydefinitions/2e3197b6-1f5b-4b01-920c-b2f0a7e9b18a",

- "policyDefinitionReferenceId": "",

- "results": {

- "nonCompliantPolicies": null,

- "nonCompliantResources": 398,

- "policyDetails": [{

- "complianceState": "noncompliant",

- "count": 1

- }],

- "policyGroupDetails": [{

- "complianceState": "noncompliant",

- "count": 1

- }],

- "queryResultsUri": "https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policyStates/latest/queryResults?api-version=2019-10-01&$from=2020-07-14 14:01:22Z&$to=2020-07-15 14:01:22Z and PolicyAssignmentId eq '/subscriptions/{subscriptionId}/providers/microsoft.authorization/policyassignments/e0704696df5e4c3c81c873e8' and PolicyDefinitionId eq '/subscriptions/{subscriptionId}/providers/microsoft.authorization/policydefinitions/2e3197b6-1f5b-4b01-920c-b2f0a7e9b18a'",

- "resourceDetails": [{

- "complianceState": "noncompliant",

- "count": 398

- },

- {

- "complianceState": "compliant",

- "count": 4

- }

- ]

- }

- }],

- ...

-Example: Getting the state record for the most recently evaluated resource (default is by timestamp

-in descending order).

-Example: Getting events related to non-compliant virtual network resources that occurred after a

-specific date.

-The Azure PowerShell module for Azure Policy is available on the PowerShell Gallery as

-[Az.PolicyInsights](https://www.powershellgallery.com/packages/Az.PolicyInsights). Using

-PowerShellGet, you can install the module using `Install-Module -Name Az.PolicyInsights` (make sure

-you have the latest [Azure PowerShell](/powershell/azure/install-azure-powershell) installed):

-Example: Getting the state summary for the topmost assigned policy with the highest number of

-non-compliant resources.

-Example: Getting the state record for the most recently evaluated resource (default is by timestamp

-in descending order).

-Example: Getting events related to non-compliant virtual network resources that occurred after a

-specific date, converting to a CSV object, and exporting to a file.

-The **PrincipalOid** field can be used to get a specific user with the Azure PowerShell cmdlet

-`Get-AzADUser`. Replace **{principalOid}** with the response you get from the previous

-example.

-If you have a [Log Analytics workspace](/azure/azure-monitor/logs/log-query-overview) with

-`AzureActivity` from the

-[Activity Log Analytics solution](/azure/azure-monitor/essentials/activity-log) tied to your

-subscription, you can also view non-compliance results from the evaluation of new and updated

-resources using simple Kusto queries and the `AzureActivity` table. With details in Azure Monitor

-logs, alerts can be configured to watch for non-compliance.

-Resources that are non-compliant to policies with **deployIfNotExists** or **modify** effects can be put into a

-compliant state through **Remediation**. Remediation is accomplished through **remediation tasks** that deploy the **deployIfNotExists** template or the **modify** operations of the assigned policy on your existing resources and subscriptions, whether that assignment is on a management group,

-subscription, resource group, or individual resource. This article shows the steps needed to

-understand and accomplish remediation with Azure Policy.

-When Azure Policy starts a template deployment when evaluating **deployIfNotExists** policies or modifies a resource when evaluating **modify** policies, it does so using

-a [managed identity](../../../active-directory/managed-identities-azure-resources/overview.md) that is associated with the policy assignment.

-Policy assignments use [managed identities](../../../active-directory/managed-identities-azure-resources/overview.md) for Azure resource authorization. You can use either a system-assigned managed identity that is created by the policy service or a user-assigned identity provided by the user. The managed identity needs to be assigned the minimum role-based access control (RBAC) role(s) required to remediate resources.

-If the managed identity is missing roles, an error is displayed in the portal

-during the assignment of the policy or an initiative. When using the portal, Azure Policy

-automatically grants the managed identity the listed roles once assignment starts. When using an Azure software development kit (SDK),

-the roles must manually be granted to the managed identity. The _location_ of the managed identity

-doesn't impact its operation with Azure Policy.

- > [!NOTE]

- > Changing a policy definition does not automatically update the assignment or the associated managed identity.

-As a prerequisite, the policy definition must define the roles that **deployIfNotExists** and **modify** need to successfully deploy the content of the included template. No action is required for a built-in policy definition because these roles are prepopulated. For a custom policy definition, under the **details**

-property, add a **roleDefinitionIds** property. This property is an array of strings that match

-roles in your environment. For a full example, see the [deployIfNotExists

-example](../concepts/effects.md#deployifnotexists-example) or the

-[modify examples](../concepts/effects.md#modify-examples).

- "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/{roleGUID}",

- "/providers/Microsoft.Authorization/roleDefinitions/{builtinroleGUID}"

- ]

-The **roleDefinitionIds** property uses the full resource identifier and doesn't take the short

-**roleName** of the role. To get the ID for the 'Contributor' role in your environment, use the

-following Azure CLI code:

-> Permissions should be restricted to the smallest possible set when defining **roleDefinitionIds**

-> [managed identity best practice recommendations](../../../active-directory/managed-identities-azure-resources/managed-identity-best-practice-recommendations.md)

- > When creating a managed identity through the portal, roles will be granted automatically to the managed identity. If **roleDefinitionIds** are later edited in the policy definition, the new permissions must be manually granted, even in the portal.

-When creating an assignment using the portal, Azure Policy can generate a system-assigned managed identity and grant it the roles defined in the policy definition's **roleDefinitionIds**. Alternatively, you can specify a user-assigned managed identity that receives the same role assignment.

-1. Don't assign a scope for system-assigned managed identity because the scope will be inherited from the assignment scope.

-1. Specify the scope where the managed identity is hosted. The scope of the managed identity does not have to equate to the scope of the assignment, but it must be in the same tenant.

-To create an identity during the assignment of the policy, use [az policy assignment create](/cli/azure/policy/assignment?view=azure-cli-latest#az-policy-assignment-create&preserve-view=true) commands with the parameters **--location**, **--mi-system-assigned**, **--mi-user-assigned**, and **--identity-scope** depending on whether the managed identity should be system-assigned or user-assigned.

-To add a system-assigned identity or a user-assigned identity to a policy assignment, follow example [az policy assignment identity assign](/cli/azure/policy/assignment/identity?view=azure-cli-latest#az-policy-assignment-identity-assign&preserve-view=true) commands.

-> If the managed identity does not have the permissions needed to execute the required remediation task, it will be granted permissions *automatically* only through the portal. You may skip this step if creating a managed identity through the portal.

-> - If a resource modified by **deployIfNotExists** or **modify** is outside the scope of the policy

-There are two ways to grant an assignment's managed identity the defined roles using the portal: by

-using **Access control (IAM)** or by editing the policy or initiative assignment and selecting

-**Save**.

-1. Launch the Azure Policy service in the Azure portal by selecting **All services**, then searching

- for and selecting **Policy**.

-1. Find the **Assignment ID** property on the edit page. The assignment ID will be something like:

- /subscriptions/{subscriptionId}/resourceGroups/PolicyTarget/providers/Microsoft.Authorization/policyAssignments/2802056bfc094dfb95d4d7a5

- The name of the managed identity is the last portion of the assignment resource ID, which is

- `2802056bfc094dfb95d4d7a5` in this example. Copy this portion of the assignment resource ID.

-1. Navigate to the resource or the resources parent container (resource group, subscription,

- management group) that needs the role definition manually added.

-1. Select the **Access control (IAM)** link in the resources page and then select **+ Add role

- assignment** at the top of the access control page.

-1. Select the appropriate role that matches a **roleDefinitionId** from the policy definition.

- Leave **Assign access to** set to the default of 'Azure AD user, group, or application'. In the

- **Select** box, paste or type the portion of the assignment resource ID located earlier. Once the

- search completes, select the object with the same name to select ID and select **Save**.

-The new managed identity must complete replication through Azure Active Directory before it can be

-granted the needed roles. Once replication is complete, the following examples iterate the policy

-definition in `$policyDef` for the **roleDefinitionIds** and uses

-[New-AzRoleAssignment](/powershell/module/az.resources/new-azroleassignment) to

-grant the new managed identity the roles.

-Specifically, the first example shows you how to grant roles at the policy scope. The second

-example demonstrates how to grant roles at the initiative (policy set) scope.

-The new managed identity must complete replication through Azure Active Directory before it can be granted the needed roles. Once replication is complete, the roles specified in the policy definition's **roleDefinitionIds** should be granted to the managed identity.

-Access the roles specified in the policy definition using the [az policy definition show](/cli/azure/policy/definition?view=azure-cli-latest#az-policy-definition-show&preserve-view=true) command, then iterate over each **roleDefinitionId** to create the role assignment using the [az role assignment create](/cli/azure/role/assignment?view=azure-cli-latest#az-role-assignment-create&preserve-view=true) command.

-1. All **deployIfNotExists** and **modify** policy assignments are

- shown on the **Policies to remediate** tab. Select one with resources

- that are non-compliant to open the **New remediation task** page.

-1. Select a non-compliant policy or initiative assignment containing **deployIfNotExists** or **modify** effects.

-If the policy or initiative definition to assign has a **deployIfNotExists** or a **Modify** effect,

-the **Remediation** tab of the wizard offers a _Create a remediation task_ option, which creates a remediation task at the same time as the policy assignment.

- > [!NOTE]

- > This is the most streamlined approach for creating a remediation task and is supported for policies assigned on a _subscription_. For policies assigned on a _management group_, remediation tasks should be created using [Option 1](#option-1-create-a-remediation-task-from-the-remediation-page) or [Option 2](#option-2-create-a-remediation-task-from-a-non-compliant-policy-assignment) after evaluation has determined resource compliance.

-1. Configure the [managed identity](#configure-the-managed-identity) and fill out the rest of the wizard. The remediation task will be created when the assignment is created.

-1. If the remediation task is initiated from an initiative assignment, select the policy to remediate from the drop-down. One **deployIfNotExists** or **modify** policy can be remediated through a single Remediation task at a time.

-1. On the same page, filter the resources to remediate by using the **Scope**

- ellipses to pick child resources from where the policy is assigned (including down to the

- individual resource objects). Additionally, use the **Locations** dropdown list to further filter

- the resources.

-1. Begin the remediation task once the resources have been filtered by selecting **Remediate**. The

- policy compliance page opens to the **Remediation tasks** tab to show the state of the tasks

- progress. Deployments created by the remediation task begin right away.

-1. Navigate to the **Remediation tasks** tab on the **Remediation** page. Click on a remediation task to view details about the filtering used, the current status, and a list of resources being remediated.

-1. From the **Remediation task** details page, right-click on a resource to view either the remediation

- task's deployment or the resource. At the end of the row, select **Related events** to see

- details such as an error message.

-To create a **remediation task** with Azure PowerShell, use the `Start-AzPolicyRemediation`

-commands. Replace `{subscriptionId}` with your subscription ID and `{myAssignmentId}` with your

-**deployIfNotExists** or **modify** policy assignment ID.

-You may also choose to adjust remediation settings through these optional parameters:

-For more remediation cmdlets and examples, see the [Az.PolicyInsights](/powershell/module/az.policyinsights/#policy_insights)

-module.

-To create a **remediation task** with Azure CLI, use the `az policy remediation` commands. Replace

-`{subscriptionId}` with your subscription ID and `{myAssignmentId}` with your **deployIfNotExists**

-or **modify** policy assignment ID.

-For more remediation commands and examples, see the [az policy

-remediation](/cli/azure/policy/remediation) commands.

-A custom policy definition allows customers to define their own rules for using Azure. These rules

-often enforce:

-Whatever the business driver for creating a custom policy, the steps are the same for defining the

-new custom policy.

-Before creating a custom policy, check the [policy samples](../samples/index.md) to see whether a

-policy that matches your needs already exists.

-If you don't have an Azure subscription, create a [free account](https://azure.microsoft.com/free/)

-before you begin.

-Before creating the policy definition, it's important to understand the intent of the policy. For

-this tutorial, we'll use a common enterprise security requirement as the goal to illustrate the

-steps involved:

-While we've defined the expected state of the resource, we've not yet defined what we want done with

-non-compliant resources. Azure Policy supports many [effects](../concepts/effects.md). For this

-tutorial, we'll define the business requirement as preventing the creation of resources if they

-aren't compliant with the business rules. To meet this goal, we'll use the

-[Deny](../concepts/effects.md#deny) effect. We also want the option to suspend the policy for

-specific assignments. As such, we'll use the [Disabled](../concepts/effects.md#disabled) effect and

-make the effect a [parameter](../concepts/definition-structure.md#parameters) in the policy

-definition.

-Based on the business requirement, the Azure resource to audit with Azure Policy is a storage

-account. However, we don't know the properties to use in the policy definition. Azure Policy

-evaluates against the JSON representation of the resource, so we'll need to understand the

-properties available on that resource.

-There are many ways to determine the properties for an Azure resource. We'll look at each for

-this tutorial:

- - Export existing resource

- - Creation experience

- - Quickstart templates (GitHub)

- - Template reference docs

-The [VS Code extension](../how-to/extension-for-vscode.md#search-for-and-view-resources) can be used

-to browse resources in your environment and see the Resource Manager properties on each resource.

-[ARM template](../../../azure-resource-manager/templates/template-tutorial-use-template-reference.md) that

-includes the property you're looking to manage.

-The simplest way to find properties is to look at an existing resource of the same type. Resources

-already configured with the setting you want to enforce also provide the value to compare against.

-Look at the **Export template** page (under **Settings**) in the Azure portal for that specific

-resource.

-> for an ARM template in a [deployIfNotExists](../concepts/effects.md#deployifnotexists) policy

-...

-"resources": [{

- "name": "Standard_LRS",

- "tier": "Standard"

- "ms-resource-usage": "azure-cloud-shell"

- "networkAcls": {

- "bypass": "AzureServices",

- "virtualNetworkRules": [],

- "ipRules": [],

- "defaultAction": "Allow"

- "supportsHttpsTrafficOnly": false,

- "encryption": {

- "services": {

- "file": {

- "enabled": true

- },

- "blob": {

- "enabled": true

- }

- },

- "keySource": "Microsoft.Storage"

- }

-}]

-...

-Under **properties** is a value named **supportsHttpsTrafficOnly** set to **false**. This property

-looks like it may be the property we're looking for. Also, the **type** of the resource is

-**Microsoft.Storage/storageAccounts**. The type lets us limit the policy to only resources of this

-type.

-Another way through the portal is the resource creation experience. While creating a storage account

-through the portal, an option under the **Advanced** tab is **Security transfer required**. This

-property has _Disabled_ and _Enabled_ options. The info icon has additional text that confirms this

-option is likely the property we want. However, the portal doesn't tell us the property name on this

-screen.

-On the **Review + create** tab, a link is at the bottom of the page to **Download a template for

-automation**. Selecting the link opens the template that creates the resource we configured. In this

-case, we see two key pieces of information:

- "type": "bool"

- "accessTier": "[parameters('accessTier')]",

- "supportsHttpsTrafficOnly": "[parameters('supportsHttpsTrafficOnly')]"

-This information tells us the property type and also confirms **supportsHttpsTrafficOnly** is the

-property we're looking for.

-The [Azure quickstart templates](https://github.com/Azure/azure-quickstart-templates) on GitHub has

-hundreds of ARM templates built for different resources. These templates can be a great way to find

-the resource property you're looking for. Some properties may appear to be what you're looking for,

-but control something else.

-To validate **supportsHttpsTrafficOnly** is correct property, check the ARM template reference for

-the [storage account resource](/azure/templates/microsoft.storage/storageaccounts) on the

-storage provider. The properties object has a list of valid parameters. Selecting the StorageAccountPropertiesCreateParameters-object

-link shows a table of acceptable properties. **supportsHttpsTrafficOnly** is present and the

-description matches what we are looking for to meet the business requirements.

-Another way to explore your Azure resources is through the [Azure Resource

-Explorer](https://resources.azure.com) (Preview). This tool uses the context of your subscription,

-so you need to authenticate to the website with your Azure credentials. Once authenticated, you can

-browse by providers, subscriptions, resource groups, and resources.

-Locate a storage account resource and look at the properties. We see the

-**supportsHttpsTrafficOnly** property here as well. Selecting the **Documentation** tab, we see that

-the property description matches what we found in the reference docs earlier.

-We've identified the resource property, but we need to map that property to an

-[alias](../concepts/definition-structure.md#aliases).

-There are a few ways to determine the aliases for an Azure resource. We'll look at each for this

-tutorial:

-The Azure Policy extension for VS Code extension makes it easy to browse your resources and

-[discover aliases](../how-to/extension-for-vscode.md#discover-aliases-for-resource-properties).

-> [Resource Provider mode](../concepts/definition-structure.md#mode) properties.

-In Azure CLI, the `az provider` command group is used to search for resource aliases. We'll filter

-for the **Microsoft.Storage** namespace based on the details we got about the Azure resource

-earlier.

-In the results, we see an alias supported by the storage accounts named

-**supportsHttpsTrafficOnly**. This existence of this alias means we can write the policy to enforce

-our business requirements!

-In Azure PowerShell, the `Get-AzPolicyAlias` cmdlet is used to search for resource aliases. We'll

-filter for the **Microsoft.Storage** namespace based on the details we got about the Azure resource

-earlier.

-Like Azure CLI, the results show an alias supported by the storage accounts named

-**supportsHttpsTrafficOnly**.

-Deciding what to do with your non-compliant resources is nearly as important as deciding what to

-evaluate in the first place. Each possible response to a non-compliant resource is called an

-[effect](../concepts/effects.md). The effect controls if the non-compliant resource is logged,

-blocked, has data appended, or has a deployment associated to it for putting the resource back into

-a compliant state.

-For our example, Deny is the effect we want as we don't want non-compliant resources created in our

-Azure environment. Audit is a good first choice for a policy effect to determine what the impact of

-a policy is before setting it to Deny. One way to make changing the effect per assignment easier is

-to parameterize the effect. See [parameters](#parameters) below for the details on how.

-We now have the property details and alias for what we plan to manage. Next, we'll compose the

-policy rule itself. If you aren't yet familiar with the policy language, reference [policy

-definition structure](../concepts/definition-structure.md) for how to structure the policy

-definition. Here is an empty template of what a policy definition looks like:

- "properties": {

- "displayName": "<displayName>",

- "description": "<description>",

- "mode": "<mode>",

- "parameters": {

- <parameters>

- },

- "policyRule": {

- "if": {

- <rule>

- },

- "then": {

- "effect": "<effect>"

- }

- }

-The first three components are policy metadata. These components are easy to provide values for

-since we know what we are creating the rule for. [Mode](../concepts/definition-structure.md#mode) is

-primarily about tags and resource location. Since we don't need to limit evaluation to resources

-that support tags, we'll use the _all_ value for **mode**.

-While we didn't use a parameter for changing the evaluation, we do want to use a parameter to allow

-changing the **effect** for troubleshooting. We'll define an **effectType** parameter and limit it

-to only **Deny** and **Disabled**. These two options match our business requirements. The finished

-parameters block looks like this example:

- "effectType": {

- "type": "string",

- "defaultValue": "Deny",

- "allowedValues": [

- "Deny",

- "Disabled"

- ],

- "metadata": {

- "displayName": "Effect",

- "description": "Enable or disable the execution of the policy"

- }

-Composing the [policy rule](../concepts/definition-structure.md#policy-rule) is the final step in

-building our custom policy definition. We've identified two statements to test for:

-Since we need both of these statements to be true, we'll use the **allOf** [logical

-operator](../concepts/definition-structure.md#logical-operators). We'll pass the **effectType**

-parameter to the effect instead of making a static declaration. Our finished rule looks like this

-example:

- "allOf": [

- {

- "field": "type",

- "equals": "Microsoft.Storage/storageAccounts"

- },

- {

- "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",

- "notEquals": "true"

- }

- ]

- "effect": "[parameters('effectType')]"

- "properties": {

- "displayName": "Deny storage accounts not using only HTTPS",

- "description": "Deny storage accounts not using only HTTPS. Checks the supportsHttpsTrafficOnly property on StorageAccounts.",

- "mode": "all",

- "parameters": {

- "effectType": {

- "type": "string",

- "defaultValue": "Deny",

- "allowedValues": [

- "Deny",

- "Disabled"

- ],

- "metadata": {

- "displayName": "Effect",

- "description": "Enable or disable the execution of the policy"

- }

- }

- },

- "policyRule": {

- "if": {

- "allOf": [

- {

- "field": "type",

- "equals": "Microsoft.Storage/storageAccounts"

- },

- {

- "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",

- "notEquals": "true"

- }

- ]

- },

- "then": {

- "effect": "[parameters('effectType')]"

- }

-The completed definition can be used to create a new policy. Portal and each SDK (Azure CLI, Azure

-PowerShell, and REST API) accept the definition in different ways, so review the commands for each

-to validate correct usage. Then assign it, using the parameterized effect, to appropriate resources

-to manage the security of your storage accounts.

-If you're done working with resources from this tutorial, use the following steps to delete any of

-the assignments or definitions created above:

-1. Select **Definitions** (or **Assignments** if you're trying to delete an assignment) under

- **Authoring** in the left side of the Azure Policy page.

-1. Right-click the row or select the ellipses at the end of the definition (or assignment), and

- select **Delete definition** (or **Delete assignment**).

-description: In this tutorial, you use the Modify effect of Azure Policy to create and enforce a tag governance model on new and existing resources.

-[Tags](../../../azure-resource-manager/management/tag-resources.md) are a crucial part of organizing

-your Azure resources into a taxonomy. When following

-[best practices for tag management](/azure/cloud-adoption-framework/ready/azure-best-practices/naming-and-tagging#naming-and-tagging-resources),

-tags can be the basis for applying your business policies with Azure Policy or

-[tracking costs with Cost Management](../../../cost-management-billing/costs/cost-mgt-best-practices.md#tag-shared-resources).

-No matter how or why you use tags, it's important that you can quickly add, change, and remove those

-tags on your Azure resources. To see whether your Azure resource supports tagging, see

-[Tag support](../../../azure-resource-manager/management/tag-support.md).

-Azure Policy's [Modify](../concepts/effects.md#modify) effect is designed to aid in the governance

-of tags no matter what stage of resource governance you are in. **Modify** helps when:

-In this tutorial, you'll complete the following tasks:

-To complete this tutorial, you need an Azure subscription. If you don't have one, create a

-[free account](https://azure.microsoft.com/free/) before you begin.

-Like any good implementation of governance controls, the requirements should come from your business

-needs and be well understood before creating technical controls. For this scenario tutorial, the

-following items are our business requirements:

- - Resources inherit from the container they're in, but may be individually overridden

- - Resources determine environment by container naming scheme and may not be overridden

- - All resources in a container are part of the same environment

-Since the _CostCenter_ for a resource group can't be determined by the name of the resource group,

-it must have the tag defined on the request to create the resource group. The following policy rule

-with the [Deny](../concepts/effects.md#deny) effect prevents the creation or updating of resource

-groups that don't have the _CostCenter_ tag:

- "allOf": [{

- "field": "type",

- "equals": "Microsoft.Resources/subscriptions/resourceGroups"

- },

- {

- "field": "tags['CostCenter']",

- "exists": false

- }

- ]

- "effect": "deny"

-> As this policy rule targets a resource group, the _mode_ on the policy definition must be 'All'

-> instead of 'Indexed'.

-[Modify](../concepts/effects.md#modify):

- "if": {

- "field": "tags['CostCenter']",

- "exists": "false"

- },

- "then": {

- "effect": "modify",

- "details": {

- "roleDefinitionIds": [

- "/providers/microsoft.authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"

- ],

- "operations": [{

- "operation": "add",

- "field": "tags['CostCenter']",

- "value": "[resourcegroup().tags['CostCenter']]"

- }]

-This policy rule uses the **add** operation instead of **addOrReplace** as we don't want to alter

-In terms specific to an Azure environment managed by Azure Policy, the _Env_ tag requirements call

-A [Modify](../concepts/effects.md#modify) policy is required for each environment that exists in

-your Azure environment. The Modify policy for each looks something like this policy definition:

- "if": {

- "allOf": [{

- "field": "type",

- "equals": "Microsoft.Resources/subscriptions/resourceGroups"

- },

- {

- "field": "name",

- "like": "prd-*"

- },

- {

- "field": "tags['Env']",

- "notEquals": "Production"

- }

- },

- "then": {

- "effect": "modify",

- "details": {

- "roleDefinitionIds": [

- "/providers/microsoft.authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"

- ],

- "operations": [{

- "operation": "addOrReplace",

- "field": "tags['Env']",

- "value": "Production"

- }]

-> As this policy rule targets a resource group, the _mode_ on the policy definition must be 'All'

-> instead of 'Indexed'.

-of `prd-`. More complex naming scheme's can be achieved with several **match** conditions instead of

-the single **like** in this example.

-The business requirement calls for all resources to have the _Env_ tag that their parent resource

-group does. This tag can't be overridden, so we'll use the **addOrReplace** operation with the

-[Modify](../concepts/effects.md#modify) effect. The sample Modify policy looks like the following

- "if": {

- "anyOf": [{

- "field": "tags['Env']",

- "notEquals": "[resourcegroup().tags['Env']]"

- },

- {

- "field": "tags['Env']",

- "exists": false

- }

- },

- "then": {

- "effect": "modify",

- "details": {

- "roleDefinitionIds": [

- "/providers/microsoft.authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"

- ],

- "operations": [{

- "operation": "addOrReplace",

- "field": "tags['Env']",

- "value": "[resourcegroup().tags['Env']]"

- }]

-> As this policy rule targets resources that support tags, the _mode_ on the policy definition must

-> be 'Indexed'. This configuration also ensures this policy skips resource groups.

-_Env_ tag or is missing the _Env_ tag. Matching resources have their _Env_ tag set to the parent

-Once the tag policies above are created, join them into a single initiative for tag governance and

-match the **if** property in the policy rule. However, the policy doesn't automatically update

-Like [deployIfNotExists](../concepts/effects.md#deployifnotexists) policies, the **Modify** policy

-**Modify** resources and correct the tags to your defined taxonomy.

-the assignments or definitions created above:

-1. Right-click the row or select the ellipses at the end of the definition (or assignment), and

- select **Delete definition** (or **Delete assignment**).

-> [Azure Policy definition structure](../concepts/definition-structure.md)

-In this article, you learn how to set up Azure Policy event subscriptions to send policy state

-change events to a web endpoint. Azure Policy users can subscribe to events emitted when policy

-state changes occur on resources. These events can trigger web hooks,

-[Azure Functions](../../../azure-functions/index.yml),

-[Azure Storage Queues](../../../storage/queues/index.yml), or any other event handler that is

-supported by [Azure Event Grid](../../../event-grid/index.yml). Typically, you send events to an

-endpoint that processes the event data and takes actions. However, to simplify this tutorial, you

-send the events to a web app that collects and displays the messages.

- account before you begin.

- `az --version`. If you need to install or upgrade, see

- [Install Azure CLI](/cli/azure/install-azure-cli).

-Event Grid topics are Azure resources, and must be placed in an Azure resource group. The resource

-group is a logical collection into which Azure resources are deployed and managed.

-The following example creates a resource group named `<resource_group_name>` in the _westus_

-location. Replace `<resource_group_name>` with a unique name for your resource group.

-Now that we have a resource group, we create a

-[system topic](../../../event-grid/system-topics.md). A system topic in Event Grid represents one or

-more events published by Azure services such as Azure Policy and Azure Event Hubs. This system topic

-uses the `Microsoft.PolicyInsights.PolicyStates` topic type for Azure Policy state changes.

-First, you'll need to register the `PolicyInsights` and `EventGrid` resource providers (RPs) at the appropriate management scope. Whereas the Azure portal auto-registers any RPs you invoke for the first time, Azure CLI does not.

-Next, replace `<subscriptionId>` in the **scope** parameter with the ID of your subscription and

-`<resource_group_name>` in **resource-group** parameter with the previously created resource group.

-If your Event Grid system topic will be applied to the management group scope, then the Azure CLI `--source` parameter syntax is a bit different. Here's an example:

-Before subscribing to the topic, let's create the endpoint for the event message. Typically, the

-endpoint takes actions based on the event data. To simplify this quickstart, you deploy a

-[pre-built web app](https://github.com/Azure-Samples/azure-event-grid-viewer) that displays the

-event messages. The deployed solution includes an App Service plan, an App Service web app, and

-source code from GitHub.

-Replace `<your-site-name>` with a unique name for your web app. The web app name must be unique

-because it's part of the DNS entry.

-The deployment may take a few minutes to complete. After the deployment has succeeded, view your web

-app to make sure it's running. In a web browser, navigate to:

-`https://<your-site-name>.azurewebsites.net`

-You subscribe to a topic to tell Event Grid which events you want to track and where to send those

-events. The following example subscribes to the system topic you created, and passes the URL from

-your web app as the endpoint to receive event notifications. Replace `<event_subscription_name>`

-with a name for your event subscription. For `<resource_group_name>` and `<your-site-name>`, use the

-values you created earlier.

-View your web app again, and notice that a subscription validation event has been sent to it. Select

-the eye icon to expand the event data. Event Grid sends the validation event so the endpoint can

-verify that it wants to receive event data. The web app includes code to validate the subscription.

-In this quickstart, you create a policy assignment and assign the **Require a tag on resource

-groups** definition. This policy definition identifies resource groups that are missing the tag

-configured during policy assignment.

-Run the following command to create a policy assignment scoped to the resource group you created to

-hold the Event Grid topic:

- on RG_.

- enforced on. It could range from a subscription to resource groups. Be sure to replace

- &lt;scope&gt; with the name of your resource group. The format for a resource group scope is

- this case, it's the ID of policy definition _Require a tag on resource groups_. To get the policy

- definition ID, run this command:

- `az policy definition list --query "[?displayName=='Require a tag on resource groups']"`

-After creating the policy assignment, wait for a **Microsoft.PolicyInsights.PolicyStateCreated**

-event notification to appear in the web app. The resource group we created show a

-`data.complianceState` value of _NonCompliant_ to start.

-To make the resource group compliant, a tag with the name **EventTest** is required. Add the tag to

-the resource group with the following command replacing `<subscriptionId>` with your subscription ID

-and `<resourceGroup>` with the name of the resource group:

-After adding the required tag to the resource group, wait for a

-**Microsoft.PolicyInsights.PolicyStateChanged** event notification to appear in the web app. Expand

-the event and the `data.complianceState` value now shows _Compliant_.

-If you see an error similar to one of the following, please make sure that you've registered both resource providers at the scope to which you're subscribing (management group or subscription):

-If you plan to continue working with this web app and Azure Policy event subscription, don't clean

-up the resources created in this article. If you don't plan to continue, use the following command

-to delete the resources you created in this article.

-Replace `<resource_group_name>` with the resource group you created above.

-Now that you know how to create topics and event subscriptions for Azure Policy, learn more about

-policy state change events and what Event Grid can help you do:

-1. Navigate to **Settings** > **Rules** > **Application rule collection** > **+ Add application rule collection**.

-1. On the **Add application rule collection** screen, provide the following information:

- | Rule_4 | * | https:443 | storage_account_name.blob.core.windows.net | Replace `storage_account_name` with your actual storage account name. Make sure ["secure transfer required"](../storage/common/storage-require-secure-transfer.md) is enabled on the storage account. If you are using Private endpoint to access storage accounts, this step is not needed and storage traffic is not forwarded to the firewall.|

- | Rule_6 | TCP | * | SQL | 1433, 11000-11999 | If you are using the default sql servers provided by HDInsight, configure a network rule in the Service Tags section for SQL that will allow you to log and audit SQL traffic. Unless you configured Service Endpoints for SQL Server on the HDInsight subnet, which will bypass the firewall. If you are using custom SQL server for Ambari, Oozie, Ranger and Hive metastore then you only need to allow the traffic to your own custom SQL Servers. Refer to [Azure SQL Database and Azure Synapse Analytics connectivity architecture](/azure/azure-sql/database/connectivity-architecture) to see why 11000-11999 port range is also needed in addition to 1433. |

-* All IP addresses from [Health and management services](../hdinsight/hdinsight-management-ip-addresses.md#health-and-management-services-all-regions) with a next hop type of **Internet**. It should include 4 IPs of the generic regions as well as 2 IPs for your specific region. This rule is only needed if the ResourceProviderConnection is set to *Inbound*. If the ResourceProviderConnection is set to *Outbound* then these IPs are not needed in the UDR.

-Integrating Azure Firewall with Azure Monitor logs is useful when first getting an application working. Especially when you aren't aware of all of the application dependencies. You can learn more about Azure Monitor logs from [Analyze log data in Azure Monitor](/azure/azure-monitor/logs/log-query-overview)

-You have several configuration options to choose from when you're setting up the Azure API for FHIR or the FHIR Server for Azure (OSS). For open source, you'll need to create your own resource application registration. For Azure API for FHIR, this resource application is created automatically.

-In order for an application to interact with Microsoft Entra ID, it needs to be registered. In the context of the FHIR server, there are two kinds of application registrations to discuss:

-**Resource applications** are representations in Microsoft Entra ID of an API or resource that is secured with Microsoft Entra ID, specifically it would be the Azure API for FHIR. A resource application for Azure API for FHIR will be created automatically when you provision the service, but if you're using the open-source server, you'll need to [register a resource application](register-resource-azure-ad-client-app.md) in Microsoft Entra ID. This resource application will have an identifier URI. It's recommended that this URI be the same as the URI of the FHIR server. This URI should be used as the `Audience` for the FHIR server. A client application can request access to this FHIR server when it requests a token.

-*Client applications* are registrations of the clients that will be requesting tokens. Often in OAuth 2.0, we distinguish between at least three different types of applications:

-1. **Confidential clients**, also known as web apps in Microsoft Entra ID. Confidential clients are applications that use [authorization code flow](../../active-directory/develop/v2-oauth2-auth-code-flow.md) to obtain a token on behalf of a signed in user presenting valid credentials. They're called confidential clients because they're able to hold a secret and will present this secret to Microsoft Entra ID when exchanging the authentication code for a token. Since confidential clients are able to authenticate themselves using the client secret, they're trusted more than public clients and can have longer lived tokens and be granted a refresh token. Read the details on how to [register a confidential client](register-confidential-azure-ad-client-app.md). Note it's important to register the reply URL at which the client will be receiving the authorization code.

-1. **Public clients**. These are clients that canΓÇÖt keep a secret. Typically this would be a mobile device application or a single page JavaScript application, where a secret in the client could be discovered by a user. Public clients also use authorization code flow, but they aren't allowed to present a secret when obtaining a token and they may have shorter lived tokens and no refresh token. Read the details on how to [register a public client](register-public-azure-ad-client-app.md).

-1. Service clients. These clients obtain tokens on behalf of themselves (not on behalf of a user) using the [client credentials flow](../../active-directory/develop/v2-oauth2-client-creds-grant-flow.md). They typically represent applications that access the FHIR server in a non-interactive way. An example would be an ingestion process. When using a service client, it isn't necessary to start the process of getting a token with a call to the `/authorize` endpoint. A service client can go straight to the `/token` endpoint and present client ID and client secret to obtain a token. Read the details on how to [register a service client](register-service-azure-ad-client-app.md)

-In this overview, you've gone through the types of application registrations you may need in order to work with a FHIR API.

-FHIR&#174; is a registered trademark of [HL7](https://hl7.org/fhir/) and is used with the permission of HL7.

-Azure API for FHIR provides a fully managed deployment of the Microsoft FHIR Server for Azure. The server is an implementation of the [FHIR](https://hl7.org/fhir) standard. This document lists the main features of the FHIR Server.

-Below is a summary of the supported RESTful capabilities. For more information on the implementation of these capabilities, see [FHIR REST API capabilities](fhir-rest-api-capabilities.md).

-| update with optimistic locking | Yes | Yes |

-| update (conditional) | Yes | Yes |

-| history | Yes | Yes |

-| chained search | Yes | Yes | See Note below. |

-| reverse chained search | Yes | Yes | See Note below. |

-| batch | Yes | Yes |

-| transaction | No | Yes |

-| intermediaries | No | No |

-> In the Azure API for FHIR and the open-source FHIR server backed by Azure Cosmos DB, the chained search and reverse chained search is an MVP implementation. To accomplish chained search on Azure Cosmos DB, the implementation walks down the search expression and issues sub-queries to resolve the matched resources. This is done for each level of the expression. If any query returns more than 1000 results, an error will be thrown.

-The FHIR Server uses [Microsoft Entra ID](https://azure.microsoft.com/services/active-directory/) for access control. Specifically, role-based access control (RBAC) is enforced, if the `FhirServer:Security:Enabled` configuration parameter is set to `true`, and all requests (except `/metadata`) to the FHIR Server must have `Authorization` request header set to `Bearer <TOKEN>`. The token must contain one or more roles as defined in the `roles` claim. A request will be allowed if the token contains a role that allows the specified action on the specified resource.

-* [**Request Units (RUs)**](/azure/cosmos-db/concepts-limits) - You can configure up to 100,000 RUs in the portal for Azure API for FHIR. You'll need a minimum of 400 RUs or 40 RUs/GB, whichever is larger. If you need more than 100,000 RUs, you can put in a support ticket to have the RUs increased. The maximum available is 1,000,000. In addition, we support [autoscaling of RUs](autoscale-azure-api-fhir.md).

-* **Data size** - Data/Documents must each be slightly less than 2 MB.

-* **Resource size** - Individual resource size including history should not exceed 20GB.

-In this article, you've read about the supported FHIR features in Azure API for FHIR. For information about deploying Azure API for FHIR, see

-FHIR&#174; is a registered trademark of [HL7](https://hl7.org/fhir/) and is used with the permission of HL7.

-We have many open-source projects on GitHub that provide you the source code and instructions to deploy services for various uses. You're always welcome to visit our GitHub repositories to learn and experiment with our features and products.

-## FHIR Server

-* [microsoft/fhir-server](https://github.com/microsoft/fhir-server/): open-source FHIR Server, which is the basis for Azure API for FHIR

-* To see the latest releases, refer to the [Release Notes](https://github.com/microsoft/fhir-server/releases)

-* [microsoft/FHIR-Converter](https://github.com/microsoft/FHIR-Converter): a data conversion project that uses CLI tool and $convert-data FHIR endpoint to translate healthcare legacy data formats into FHIR

-* Integrated with the FHIR service and FHIR server for Azure in the form of $convert-data operation

-* [microsoft/vscode-azurehealthcareapis-tools](https://github.com/microsoft/vscode-azurehealthcareapis-tools): a VS Code extension that contains a collection of tools to work with FHIR Converter

-* Released to Visual Studio Marketplace, you can install it here: [FHIR Converter VS Code extension](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-health-fhir-converter)

-* [microsoft/Tools-for-Health-Data-Anonymization](https://github.com/microsoft/Tools-for-Health-Data-Anonymization): a data anonymization project that provides tools for de-identifying FHIR data and DICOM data

-* For FHIR data, it can also be used with Azure Data Factory (ADF) pipeline by reading FHIR data from Azure blob storage and writing back the anonymized data

-* [Tools to help build the conversation map](https://github.com/microsoft/iomt-fhir/tree/master/tools/data-mapper): visualize the mapping configuration for normalizing the device input data and transform it to the FHIR resources. Developers can use this tool to edit and test the mappings, device mapping and FHIR mapping, and export them for uploading to the MedTech service in the Azure portal.

-* [microsoft/healthkit-on-fhir](https://github.com/microsoft/healthkit-on-fhir): a Swift library that automates the export of Apple HealthKit Data to a FHIR Server

-In this article, you've learned about the related GitHub Projects for Azure API for FHIR that provide source code and instructions to let you experiment and deploy services for various uses. For more information about Azure API for FHIR, see

-FHIR&#174; is a registered trademark of [HL7](https://hl7.org/fhir/) and is used with the permission of HL7.

-description: In this quickstart, you'll learn how to deploy Azure API for FHIR in Azure using the Azure CLI.

-In this quickstart, you'll learn how to deploy Azure API for FHIR in Azure using the Azure CLI.

-Get a list of commands for HealthcareAPIs:

-Pick a name for the resource group that will contain the Azure API for FHIR and create it:

-Obtain a capability statement from the FHIR API with:

-If you're not going to continue to use this application, delete the resource group with the following steps:

-In this quickstart guide, you've deployed the Azure API for FHIR into your subscription. For information about how to register applications and the Azure API for FHIR configuration settings, see

-FHIR&#174; is a registered trademark of [HL7](https://hl7.org/fhir/) and is used with the permission of HL7.

-description: In this quickstart, you'll learn how to deploy Azure API for FHIR and configure settings using the Azure portal.

-In this quickstart, you'll learn how to deploy Azure API for FHIR using the Azure portal.

-Select an existing resource group or create a new one, choose a name for the account, and finally select **Review + create**:

-You can also select **Next: Additional settings** to view the authentication settings. The default configuration for the Azure API for FHIR is to [use Azure RBAC for assigning data plane roles](configure-azure-rbac.md). When configured in this mode, the "Authority" for the FHIR service will be set to the Microsoft Entra tenant of the subscription:

-If you wish to configure the FHIR service to use an external or secondary Microsoft Entra tenant, you can change the Authority and enter object IDs for user and groups that should be allowed access to the server. For more information, see the [local RBAC configuration](configure-local-rbac.md) guide.

-In this quickstart guide, you've deployed the Azure API for FHIR into your subscription. For information about how to register applications and the Azure API for FHIR configuration settings, see

-FHIR&#174; is a registered trademark of [HL7](https://hl7.org/fhir/) and is used with the permission of HL7.

-description: In this quickstart, you'll learn how to deploy Azure API for FHIR using PowerShell.

-In this quickstart, you'll learn how to deploy Azure API for FHIR using PowerShell.

-If the `Microsoft.HealthcareApis` resource provider isn't already registered for your subscription, you can register it with:

-> Depending on the version of the `Az` PowerShell module you have installed, the provisioned FHIR server may be configured to use [local RBAC](configure-local-rbac.md) and have the currently signed in PowerShell user set in the list of allowed identity object IDs for the deployed FHIR service. Going forward, we recommend that you [use Azure RBAC](configure-azure-rbac.md) for assigning data plane roles and you may need to delete this users object ID after deployment to enable Azure RBAC mode.

-You'll be able to validate that the Azure API for FHIR account is running by fetching a FHIR capability statement:

-If you're not going to continue to use this application, delete the resource group with the following steps:

-In this quickstart guide, you've deployed the Azure API for FHIR into your subscription. For more information about the settings in Azure API for FHIR and to start using Azure API for FHIR, see

-FHIR&#174; is a registered trademark of [HL7](https://hl7.org/fhir/) and is used with the permission of HL7.

-Azure API for FHIR supports create, conditional create, update, and conditional update as defined by the FHIR specification. One useful header in these scenarios is the [If-Match](https://www.hl7.org/fhir/http.html#concurrency) header. The `If-Match` header is used and will validate the version being updated before making the update. If the `ETag` doesnΓÇÖt match the expected `ETag`, it will produce the error message *412 Precondition Failed*.

-**Delete can be performed for individual resource id or in bulk. To learn more on deleting resources in bulk, visit [$bulk-delete operation](bulk-delete-operation.md).**

-Delete defined by the FHIR specification requires that after deleting a resource, subsequent nonversion specific reads of a resource returns a 410 HTTP status code. Therefore, the resource is no longer found through searching. Additionally, Azure API for FHIR enables you to fully delete (including all history) the resource. To fully delete the resource, you can pass a parameter settings `hardDelete` to true `(DELETE {{FHIR_URL}}/{resource}/{id}?hardDelete=true)`. If you don't pass this parameter or set `hardDelete` to false, the historic versions of the resource will still be available.

- Conditional Delete allows you to pass search criteria to delete a resource. By default, the Conditional Delete allows you to delete one item at a time. You can also specify the `_count` parameter to delete up to 100 items at a time. Below are some examples of using Conditional Delete.

-To delete multiple resources, include `_count=100` parameter. This parameter deletes up to 100 resources that match the search criteria.

-`<FHIR_URL>/<resource-type>/<resource-id>/_history`

-For example: `https://myworkspace-myfhirserver.fhir.azurehealthcareapis.com/Patient/123456789/_history`

-`<FHIR_URL>/<resource-type>/_history`

-After you've found the record you want to restore, use the `PUT` operation to recreate the resource with the same ID, or use the `POST` operation to make a new resource with the same information.

-In FHIR, bundles can be considered as a container that holds multiple resources. Batch bundles enable users to submit a set of actions to be performed on a server in single HTTP request/response.

-A batch bundle interaction with FHIR service is performed with HTTP POST command at base URL.

-To use the capability of parallel batch bundle processing-

-Patch is a valuable RESTful operation when you need to update only a portion of the FHIR resource. Using patch allows you to specify the element(s) that you want to update in the resource without having to update the entire record. FHIR defines three ways to Patch resources: JSON Patch, XML Patch, and FHIRPath Patch. The FHIR Service support both JSON Patch and FHIRPath Patch along with Conditional JSON Patch and Conditional FHIRPath Patch (which allows you to Patch a resource based on a search criteria instead of a resource ID). To walk through some examples, refer to the sample [FHIRPath Patch REST file](https://github.com/microsoft/fhir-server/blob/main/docs/rest/FhirPatchRequests.http) and the [JSON Patch REST file](https://github.com/microsoft/fhir-server/blob/main/docs/rest/JsonPatchRequests.http) for each approach. For additional details, read the [HL7 documentation for patch operations with FHIR](https://www.hl7.org/fhir/http.html#patch).

-This method of patch is the most powerful as it leverages [FHIRPath](https://hl7.org/fhirpath/) for selecting which element to target. One common scenario is using FHIRPath Patch to update an element in a list without knowing the order of the list. For example, if you want to delete a patientΓÇÖs home telecom information without knowing the index, you can use the example below.

-JSON Patch in the FHIR Service conforms to the well-used [specification defined by the Internet Engineering Task Force](https://datatracker.ietf.org/doc/html/rfc6902). The payload format does not use FHIR resources and instead uses a JSON document leveraging JSON-Pointers for element selection. JSON Patch is more compact and has a test operation that allows you to validate that a condition is true before doing the patch. For example, if you want to set a patient as deceased only if they're not already marked as deceased, you can use the example below.

-By default, JSON Patch isn't supported in Bundle resources. This is because a Bundle only supports with FHIR resources and the JSON Patch payload isn't a FHIR resource. To work around this, we'll use Binary resources with a Content-Type of `"application/json-patch+json"` and the base64 encoding of the JSON payload inside of a Bundle. For information about this workaround, view this topic on the [FHIR Chat Zulip](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Transaction.20with.20PATCH.20request).

-In the example below, we want to change the gender on the patient to female. We've taken the JSON patch `[{"op":"replace","path":"/gender","value":"female"}]` and encoded it to base64.

-2. **x-ms-query-latency-over-efficiency** header value when set to "true", all queries are executed using maximum supported parallelism, which forces the scan of physical partitions to be executed concurrently. This feature was designed for accounts with a high number of physical partitions which queries can take longer due to the number of physical segments that need to be scanned.

-If you have a user with user name `myuser@contoso.com`, you can locate the user's `ObjectId` by using a Microsoft Graph PowerShell command or the Azure Command-Line Interface (CLI).

-Suppose you registered a [service client app](register-service-azure-ad-client-app.md) and you want to allow this service client to access the Azure API for FHIR. Find the object ID for the client service principal with a Microsoft Graph PowerShell command or the Azure CLI.

-If you would like to locate the object ID of a security group, you can use a Microsoft Graph PowerShell command or the Azure CLI.

- using RegistryManager srcRegistryManager = RegistryManager.CreateFromConnectionString(hubConnectionString);

-

- using RegistryManager destRegistryManager = RegistryManager.CreateFromConnectionString(hubConnectionString);

-

-iothub_job_manager = IoTHubJobManager("<IoT Hub connection string>")

-2. Similar to what you did in the previous section, create a directory for your device code and use NPM to initialize it and install the device SDK (**npm install -S azure-iot-device-amqp\@modules-preview**).

-Each organization or school will configure their own network in a way that best fits their needs. Sometimes that includes setting firewall rules that block Remote Desktop Protocol (RDP) or Secure Shell (SSH) connections to machines outside their own network. Because Azure Lab Services runs in the public cloud, some extra configuration maybe needed to allow students to access their VM when connecting from the campus network.

-Each lab uses single public IP address and multiple ports. All VMs, both the template VM and student VMs, will use this public IP address. The public IP address won't change for the life of lab. Each VM will have a different port number. The port numbers range is 49152 - 65535. The combination of public IP address and port number is used to connect educators and students to the correct VM. This article will cover how to find the specific public IP address used by a lab. That information can be used to update inbound and outbound firewall rules so students can access their VMs.

->Each lab will have a different public IP address.

-> If your school needs to perform content filtering, such as for compliance with the [Children's Internet Protection Act (CIPA)](https://www.fcc.gov/consumers/guides/childrens-internet-protection-act), you will need to use 3rd party software. For more information, read guidance on [content filtering with Lab Services](./administrator-guide.md#content-filtering).

-The public IP addresses for each lab are listed in the **All labs** page of the Lab Services lab account. For directions how to find the **All labs** page, see [View labs in a lab account](manage-labs-1.md#view-labs-in-a-lab-account).

-Now we know the public IP address for the lab. Inbound and outbound rules can be created for the organization's firewall for the public IP address and the port range 49152 - 65535. Once the rules are updated, students can access their VMs without the network firewall blocking access.

- > By default, the language worker runtime value for your Standard logic app is **`dotnet`**.

- > Previously, **`node`** was the default value. However, **`dotnet`** is now the default value

- > for all new and existing deployed Standard logic apps, even for apps that had a different value.

- > This change shouldn't affect your workflow's runtime, and everything should work the same way

- > as before. For more information, see the [**FUNCTIONS_WORKER_RUNTIME** app setting](edit-app-settings-host-settings.md#reference-local-settings-json).

- >

- > The **APP_KIND** app setting for your Standard logic app is set to **workflowApp**, but in some

- > scenarios, this app setting is missing, for example, due to automation using Azure Resource Manager

- > templates or other scenarios where the setting isn't included. If certain actions don't work,

- > such as the **Execute JavaScript Code** action or the workflow stops working, check that the

- > **APP_KIND** app setting exists and is set to to **workflowApp**. For more information, see the

- > [**APP_KIND** app setting](edit-app-settings-host-settings.md#reference-local-settings-json).

- > By default, in your **local.settings.json** file, the language worker runtime value for your

- > Standard logic app is **`dotnet`**. Previously, **`node`** was the default value. However,

- > **`dotnet`** is now the default value for all new and existing deployed Standard logic apps,

- > even for apps that had a different value. This change shouldn't affect your workflow's runtime,

- > and everything should work the same way as before. For more information, see the

- >

- > The **APP_KIND** app setting for your Standard logic app is set to **workflowApp**, but in some

- > scenarios, this app setting is missing, for example, due to automation using Azure Resource Manager

- > templates or other scenarios where the setting isn't included. If certain actions don't work,

- > such as the **Execute JavaScript Code** action or the workflow stops working, check that the

- > **APP_KIND** app setting exists and is set to to **workflowApp**. For more information, see the

- > [**APP_KIND** app setting](edit-app-settings-host-settings.md#reference-local-settings-json).

-For your workflow to run properly, some app settings are marked as "required".

-| Setting | Required | Default value | Description |

-||-||-|

-| `APP_KIND` | Yes | `workflowApp` | Required to set the app type for the Standard logic app resource. |

-| `FUNCTIONS_WORKER_RUNTIME` | Yes | `dotnet` | Required to set the language worker runtime for your logic app resource and workflows. <br><br>**Note**: Previously, this setting's default value was **`node`**. Now, **`dotnet`** is the default value for all new and existing deployed Standard logic apps, even for apps that had a different different value. This change shouldn't affect your workflow's runtime, and everything should work the same way as before.<br><br>For more information, see [FUNCTIONS_WORKER_RUNTIME](../azure-functions/functions-app-settings.md#functions_worker_runtime). |

-description: Describes how to work with the previous version of Azure Migrate.

-# Work with the previous version of Azure Migrate

-This article provides information about working with the previous version of Azure Migrate.

-There are two versions of the Azure Migrate service:

- - You can no longer create migration projects.

- - We recommend that you don't perform new discoveries.

- - You can still access existing projects.

- - You can still run assessments.

-

-## Upgrade between versions

-You can't upgrade projects or components in the previous version to the new version. You need to [create a new Azure Migrate project](create-manage-projects.md), and [add assessment and migration tools](./create-manage-projects.md#next-steps) to it. Use the tutorials to understand how to use the assessment and migration tools available. If you had a Log Analytics workspace attached to a Classic project, you can attach it to a project of current version after you delete the Classic project.

-## Find projects from previous version

-Find projects from the previous version as follows:

-1. In the Azure portal > **All services**, search for and select **Azure Migrate**.

-2. On the Azure Migrate dashboard, there's a notification and a link to access old Azure Migrate projects.

-3. Click the link to open Classic projects.

-## Delete projects from previous version

-Find and delete projects from the previous version as follows:

-1. In the Azure portal > **All services**, search for and select **Azure Migrate**.

-2. On the Azure Migrate dashboard, there's a notification and a link to access old Azure Migrate projects.

-3. Click the link to open Classic projects.

-4. Select the project you would like to delete and delete it.

-## Create an assessment

-After VMs are discovered in the portal, you group them and create assessments.

-Create an assessment as follows:

-1. In the project **Overview** page, click **+Create assessment**.

-2. Click **View all** to review the assessment properties.

-3. Create the group, and specify a group name.

-4. Select the machines that you want to add to the group.

-5. Click **Create Assessment**, to create the group and the assessment.

-6. After the assessment is created, view it in **Overview** > **Dashboard**.

-7. Click **Export assessment**, to download it as an Excel file.

-If you would like to update an existing assessment with the latest performance data, you can use the **Recalculate** command on the assessment to update it.

-## Review an assessment

-An assessment has three stages:

-A machine only moves along to a later stage if it passes the previous one. For example, if a machine fails the suitability check, itΓÇÖs marked as unsuitable for Azure, and sizing and costing isn't done.

-### Review Azure readiness

-The Azure readiness view in the assessment shows the readiness status of each VM.

-**Readiness** | **State** | **Details**

- | |

-Ready for Azure | No compatibility issues. The machine can be migrated as-is to Azure, and it will boot in Azure with full Azure support. | For VMs that are ready, Azure Migrate recommends a VM size in Azure.

-Conditionally ready for Azure | The machine might boot in Azure, but might not have full Azure support. For example, a machine with an older version of Windows Server that isn't supported in Azure. | Azure Migrate explains the readiness issues, and provides remediation steps.

-Not ready for Azure | The VM won't boot in Azure. For example, if a VM has a disk that's more than 4 TB, it can't be hosted on Azure. | Azure Migrate explains the readiness issues and provides remediation steps.

-Readiness unknown | Azure Migrate can't identify Azure readiness, usually because data isn't available. |

-#### Azure VM properties

-Readiness takes into account a number of VM properties, to identify whether the VM can run in Azure.

-**Property** | **Details** | **Readiness**

- | |

-**Boot type** | BIOS supported. UEFI not supported. | Conditionally ready if boot type is UEFI.

-**Cores** | Machines core <= the maximum number of cores (128) supported for an Azure VM.<br/><br/> If performance history is available, Azure Migrate considers the utilized cores.<br/>If a comfort factor is specified in the assessment settings, the number of utilized cores is multiplied by the comfort factor.<br/><br/> If there's no performance history, Azure Migrate uses the allocated cores, without applying the comfort factor. | Ready if less than or equal to limits.

-**Memory** | The machine memory size <= the maximum memory (3892 GB on Azure M series Standard_M128m&nbsp;²) for an Azure VM. [Learn more](/azure/virtual-machines/sizes).<br/><br/> If performance history is available, Azure Migrate considers the utilized memory.<br/><br/>If a comfort factor is specified, the utilized memory is multiplied by the comfort factor.<br/><br/> If there's no history, the allocated memory is used, without applying the comfort factor.<br/><br/> | Ready if within limits.

-**Storage disk** | Allocated size of a disk must be 4 TB (4096 GB) or less.<br/><br/> The number of disks attached to the machine must be 65 or less, including the OS disk. | Ready if within limits.

-**Networking** | A machine must have 32 or less NICs attached to it. | Ready if within limits.

-#### Guest operating system

-Along with VM properties, Azure Migrate also looks at the guest OS of the on-premises VM to identify if the VM can run in Azure.

-The following logic is used.

-**Operating System** | **Details** | **Readiness**

- | |

-Windows Server 2016 and all SPs | Azure provides full support. | Ready for Azure

-Windows Server 2012 R2 and all SPs | Azure provides full support. | Ready for Azure

-Windows Server 2012 and all SPs | Azure provides full support. | Ready for Azure

-Windows Server 2008 R2 and all SPs | Azure provides full support.| Ready for Azure

-Windows Server 2008 (32-bit and 64-bit) | Azure provides full support. | Ready for Azure

-Windows Server 2003, 2003 R2 | Out-of-support and need a [Custom Support Agreement (CSA)](/troubleshoot/azure/virtual-machines/server-software-support) for support in Azure. | Conditionally ready for Azure. Consider upgrading the OS before migrating to Azure.

-Windows 2000, 98, 95, NT, 3.1, MS-DOS | Out-of-support. The machine might boot in Azure, but no OS support is provided by Azure. | Conditionally ready for Azure. It is recommended to upgrade the OS before migrating to Azure.

-Windows Client 7, 8 and 10 | Azure provides support with [Visual Studio subscription only.](/azure/virtual-machines/windows/client-images) | Conditionally ready for Azure.

-Windows 10 Pro Desktop | Azure provides support with [Multitenant Hosting Rights](/azure/virtual-machines/windows/windows-desktop-multitenant-hosting-deployment). | Conditionally ready for Azure.

-Windows Vista, XP Professional | Out-of-support. The machine might boot in Azure, but no OS support is provided by Azure. | Conditionally ready for Azure. It is recommended to upgrade the OS before migrating to Azure.

-Linux | Azure endorses these [Linux operating systems](/azure/virtual-machines/linux/endorsed-distros). Other Linux operating systems might boot in Azure, but we recommend upgrading the OS to an endorsed version, before migrating to Azure. | Ready for Azure if the version is endorsed.<br/><br/>Conditionally ready if the version is not endorsed.

-Other operating systems<br/><br/> For example, Oracle Solaris, Apple macOS etc., FreeBSD, etc. | Azure doesn't endorse these operating systems. The machine may boot in Azure, but no OS support is provided by Azure. | Conditionally ready for Azure. It is recommended to install a supported OS before migrating to Azure.

-OS specified as **Other** in vCenter Server | Azure Migrate cannot identify the OS in this case. | Unknown readiness. Ensure that the OS running inside the VM is supported in Azure.

-32-bit operating systems | The machine may boot in Azure, but Azure may not provide full support. | Conditionally ready for Azure, consider upgrading the OS of the machine from 32-bit OS to 64-bit OS before migrating to Azure.

-### Review sizing

- The Azure Migrate size recommendation depends on the sizing criterion specified in the assessment properties.

-### Review cost estimates

-Cost estimates show the total compute and storage cost of running the VMs in Azure, along with the details for each machine.

-### Review confidence rating (performance-based assessment)

-Each performance-based assessment is associated with a confidence rating.

-For performance-based sizing, Azure Migrate needs the following:

-Depending on the percentage of data points available, the possible confidence ratings are summarized in the table.

-**Availability of data points** | **Confidence rating**

- |

-0%-20% | 1 Star

-21%-40% | 2 Star

-41%-60% | 3 Star

-61%-80% | 4 Star

-81%-100% | 5 Star

-#### Assessment issues affecting confidence ratings

-An assessment might not have all the data points available due to a number of reasons:

-> [!NOTE]

-> If the confidence rating of any assessment is below five-stars, wait for at least a day for the appliance to profile the environment, and then recalculate the assessment. If you don't performance-based sizing might not be reliable. If you don't want to recalculate, we recommended switching to as on-premises sizing, by changing the assessment properties.

-## Create groups using dependency visualization

-In addition to creating groups manually, you can create groups using dependency visualization.

-> [!NOTE]

-> Dependency visualization is not available in Azure Government.

-To set up dependency visualization, you associate a Log Analytics workspace with an Azure Migrate project, install agents on machines for which you want to visualize dependencies, and then create groups using dependency information.

-### Associate a Log Analytics workspace

-To use dependency visualization, you associate a Log Analytics workspace with a migration project. You can only create or attach a workspace in the same subscription where the migration project is created.

-1. To attach a Log Analytics workspace to a project, in **Overview** > **Essentials**, click **Requires configuration**.

-2. You can create a new workspace, or attach an existing one:

- - To create a new workspace, specify a name. The workspace is created in a region in the same [Azure geography](https://azure.microsoft.com/global-infrastructure/geographies/) as the migration project.

- - When you attach an existing workspace, you can pick from all the available workspaces in the same subscription as the migration project. Only those workspaces are listed which were created in a [supported Service Map region](https://azure.microsoft.com/global-infrastructure/services/?products=monitor&regions=all). You can monitor Azure VMs in any region. The VMs themselves aren't limited to the regions supported by the Log Analytics workspace. To attach a workspace, ensure that you have 'Reader' access to the workspace.

-> [!NOTE]

-> You can't change the workspace associated with a migration project.

-### Download and install VM agents

-After you configure a workspace, you download and install agents on each on-premises machine that you want to evaluate. In addition, if you have machines with no internet connectivity, you need to download and install [Log Analytics gateway](/azure/azure-monitor/agents/gateway) on them.

-1. In **Overview**, click **Manage** > **Machines**, and select the required machine.

-2. In the **Dependencies** column, click **Install agents**.

-3. On the **Dependencies** page, download and install the Microsoft Monitoring Agent (MMA), and the Dependency agent on each VM you want to assess.

-4. Copy the workspace ID and key. You need these when you install the MMA on the on-premises machine.

-> [!NOTE]

-> To automate the installation of agents you can use a deployment tool such as Configuration Manager or a partner tool such as Intigua, that provides an agent deployment solution for Azure Migrate.

-#### Install the MMA agent on a Windows machine

-To install the agent on a Windows machine:

-1. Double-click the downloaded agent.

-2. On the **Welcome** page, click **Next**. On the **License Terms** page, click **I Agree** to accept the license.

-3. In **Destination Folder**, keep or modify the default installation folder > **Next**.

-4. In **Agent Setup Options**, select **Azure Log Analytics** > **Next**.

-5. Click **Add** to add a new Log Analytics workspace. Paste in the workspace ID and key that you copied from the portal. Click **Next**.

-You can install the agent from the command line or using an automated method such as Configuration Manager. [Learn more](/azure/azure-monitor/agents/log-analytics-agent#installation-options) about using these methods to install the MMA agent.

-#### Install the MMA agent on a Linux machine

-To install the agent on a Linux machine:

-1. Transfer the appropriate bundle (x86 or x64) to your Linux computer using scp/sftp.

-2. Install the bundle by using the --install argument.

- `sudo sh ./omsagent-<version>.universal.x64.sh --install -w <workspace id> -s <workspace key>`

-[Learn more](/azure/azure-monitor/agents/agents-overview#supported-operating-systems) about the list of Linux operating systems support by MMA.

-### Install the MMA agent on a machine monitored by Operations Manager

-For machines monitored by System Center Operations Manager 2012 R2 or later, there is no need to install the MMA agent. Service Map integrates with the Operations Manager MMA to gather the necessary dependency data. [Learn more](/previous-versions/azure/azure-monitor/vm/service-map-scom#prerequisites). The Dependency agent needs to be installed.

-### Install the Dependency agent

-1. To install the Dependency agent on a Windows machine, double-click the setup file and follow the wizard.

-2. To install the Dependency agent on a Linux machine, install as root using the following command:

- `sh InstallDependencyAgent-Linux64.bin`

- - Learn more about the [Dependency agent support](/azure/azure-monitor/vm/vminsights-enable-overview#supported-operating-systems) for the Windows and Linux operating systems.

- - [Learn more](/azure/azure-monitor/vm/vminsights-dependency-agent-maintenance#install-or-upgrade-dependency-agent) about how you can use scripts to install the Dependency agent.

->[!NOTE]

-> The Azure Monitor for VMs article referenced to provide an overview of the system prerequisites and methods to deploy the Dependency agent are also applicable to the Service Map solution.

-### Create a group with dependency mapping

-1. After you install the agents, go to the portal, and click **Manage** > **Machines**.

-2. Search for the machine where you installed the agents.

-3. The **Dependencies** column for the machine should now show as **View Dependencies**. Click the column to view the dependencies of the machine.

-4. The dependency map for the machine shows the following details:

- - Inbound (Clients) and outbound (Servers) TCP connections to/from the machine

- - The dependent machines that do not have the MMA and dependency agent installed are grouped by port numbers.

- - The dependent machines that have the MMA and the dependency agent installed are shown as separate boxes.

- - Processes running inside the machine, you can expand each machine box to view the processes

- - Machine properties, including the FQDN, operating System, MAC address are shown. You can click on each machine box to view the details.

-4. You can view dependencies for different time durations by clicking on the time duration in the time range label. By default the range is an hour. You can modify the time range, or specify start and end dates, and the duration.

- > [!NOTE]

- > A time range of up to an hour is supported. Use Azure Monitor logs to [query dependency data](./how-to-create-group-machine-dependencies.md) over a longer duration.

-5. After you've identified dependent machines that you want to group together, use Ctrl+Click to select multiple machines on the map, and click **Group machines**.

-6. Specify a group name. Verify that the dependent machines are discovered by Azure Migrate.

- > [!NOTE]

- > If a dependent machine is not discovered by Azure Migrate, you can't add it to the group. To add such machines to the group, you need to run the discovery process again with the right scope in vCenter Server and ensure that the machine is discovered by Azure Migrate.

-7. If you want to create an assessment for this group, select the checkbox to create a new assessment for the group.

-8. Click **OK** to save the group.

-Once the group is created, it is recommended to install agents on all the machines of the group and refine the group by visualizing the dependency of the entire group.

-## Query dependency data from Azure Monitor logs

-Dependency data captured by Service Map is available for querying in the Log Analytics workspace associated with your Azure Migrate project. [Learn more](/previous-versions/azure/azure-monitor/vm/service-map#log-analytics-records) about the Service Map data tables to query in Azure Monitor logs.

-To run the Kusto queries:

-1. After you install the agents, go to the portal and click **Overview**.

-2. In **Overview**, go to **Essentials** section of the project and click on workspace name provided next to **OMS Workspace**.

-3. On the Log Analytics workspace page, click **General** > **Logs**.

-4. Write your query to gather dependency data using Azure Monitor logs. Find sample queries in the next section.

-5. Run your query by clicking on Run.

-[Learn more](/azure/azure-monitor/logs/log-analytics-tutorial) about how to write Kusto queries.

-### Sample Azure Monitor logs queries

-Following are sample queries you can use to extract dependency data. You can modify the queries to extract your preferred data points. An exhaustive list of the fields in dependency data records is available [here](/previous-versions/azure/azure-monitor/vm/service-map#log-analytics-records). Find more sample queries [here](/previous-versions/azure/azure-monitor/vm/service-map#sample-log-searches).

-#### Summarize inbound connections on a set of machines

-The records in the table for connection metrics, VMConnection, do not represent individual physical network connections. Multiple physical network connections are grouped into a logical connection. [Learn more](/previous-versions/azure/azure-monitor/vm/service-map#connections) about how physical network connection data is aggregated into a single logical record in VMConnection.

-```

-// the machines of interest

-let ips=materialize(ServiceMapComputer_CL

-| summarize ips=makeset(todynamic(Ipv4Addresses_s)) by MonitoredMachine=ResourceName_s

-| mvexpand ips to typeof(string));

-let StartDateTime = datetime(2019-03-25T00:00:00Z);

-let EndDateTime = datetime(2019-03-30T01:00:00Z);

-VMConnection

-| where Direction == 'inbound'

-| where TimeGenerated > StartDateTime and TimeGenerated < EndDateTime

-| join kind=inner (ips) on $left.DestinationIp == $right.ips

-| summarize sum(LinksEstablished) by Computer, Direction, SourceIp, DestinationIp, DestinationPort

-```

-#### Summarize volume of data sent and received on inbound connections between a set of machines

-```

-// the machines of interest

-let ips=materialize(ServiceMapComputer_CL

-| summarize ips=makeset(todynamic(Ipv4Addresses_s)) by MonitoredMachine=ResourceName_s

-| mvexpand ips to typeof(string));

-let StartDateTime = datetime(2019-03-25T00:00:00Z);

-let EndDateTime = datetime(2019-03-30T01:00:00Z);

-VMConnection

-| where Direction == 'inbound'

-| where TimeGenerated > StartDateTime and TimeGenerated < EndDateTime

-| join kind=inner (ips) on $left.DestinationIp == $right.ips

-| summarize sum(BytesSent), sum(BytesReceived) by Computer, Direction, SourceIp, DestinationIp, DestinationPort

-```

-## Next steps

-[Learn about](migrate-services-overview.md) the latest version of Azure Migrate.

-description: Learn how to troubleshoot issues with an Azure Modeling and Simulation Workbench.

-## Next steps

-In this quickstart, you created a VM and diagnosed inbound and outbound network traffic filters. You learned that network security group rules allow or deny traffic to and from a VM. Learn more about [security rules](../virtual-network/network-security-groups-overview.md?toc=%2fazure%2fnetwork-watcher%2ftoc.json) and how to [create security rules](../virtual-network/manage-network-security-group.md?toc=%2fazure%2fnetwork-watcher%2ftoc.json#create-a-security-rule).

-Even with the proper network traffic filters in place, communication to a virtual machine can still fail, due to routing configuration. To learn how to diagnose virtual machine routing problems, see [Diagnose a virtual machine network routing problem](diagnose-vm-network-routing-problem-powershell.md). To diagnose outbound routing, latency, and traffic filtering problems with one tool, see [Troubleshoot connections with Azure Network Watcher](network-watcher-connectivity-powershell.md).

-## Next steps

-In this quickstart, you created a VM and diagnosed inbound and outbound network traffic filters. You learned that network security group rules allow or deny traffic to and from a VM. Learn more about [security rules](../virtual-network/network-security-groups-overview.md?toc=%2fazure%2fnetwork-watcher%2ftoc.json) and how to [create security rules](../virtual-network/manage-network-security-group.md?toc=%2fazure%2fnetwork-watcher%2ftoc.json#create-a-security-rule).

-Even with the proper network traffic filters in place, communication to a virtual machine can still fail, due to routing configuration. To learn how to diagnose virtual machine routing problems, see [Diagnose a virtual machine network routing problem](diagnose-vm-network-routing-problem-powershell.md). To diagnose outbound routing, latency, and traffic filtering problems with one tool, see [Troubleshoot connections with Azure Network Watcher](network-watcher-connectivity-powershell.md).

-| COMPX_SVRY_BMC_PASS | CompX Rack ServerY BMC password; repeat for each rack in compute-rack-definitions and for each server in rack |

-| COMPX_SVRY_BOOT_MAC | CompX Rack ServerY boot NIC MAC address; repeat for each rack in compute-rack-definitions and for each server in rack |

-| COMPX_SVRY_SERVER_NAME | CompX Rack ServerY name, repeat for each rack in compute-rack-definitions and for each server in rack |

-| CLUSTER_TYPE | Type of cluster, Single, or MultiRack |

-| CLUSTER_VERSION | NC Version of cluster |

-1. In a web browser, go to the [Azure portal](https://portal.azure.com/) and sign in.

-1. From the Azure portal search bar, search for 'Deploy a custom template' and then select it from the available services.

-1. Search for the Resource group to see if it already exists. If not, create a new Resource group.

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

-After creating the cluster, the deploy cluster action can be triggered.

-1. Validation of the cluster/rack properties

-3. Interaction with the IPMI interface of the targeted bootstrap machine.

-4. Perform hardware validation checks

-### Cluster Deploy with hardware validation

-#### Cluster Deploy Action with skipping specific bare-metal-machine

-A parameter can be passed in to the deploy command that represents the names of

-Some examples of deployment progress shown in detailedStatusMessage are `Hardware validation is in progress.` (if cluster is deployed with hardware validation) ,`Cluster is bootstrapping.`, `KCP initialization in progress.`, `Management plane deployment in progress.`, `Cluster extension deployment in progress.`, `waiting for "<rack-ids>" to be ready`, etc.

-When deleting a cluster, it deletes the resources in Azure and the cluster that resides in the on-premises environment.

- ```json

- ```json

- ```json

- ```json

- ```json

- ```json

- ```json

- ```json

-* Disk Check Failure

- ```json

- ```json

- ```json

- ```json

- ```json

- ```json

- ```json

- ```json

- ```json

- ```json

- ```json

- ```json

- ```json

- ```json

- ```json

- ```json

- * Dell server health checks fail for recent Critical LC Log Alarms. The hardware validation plugin logs the alarm ID, name, and timestamp. Recent LC Log critical alarms indicate need for further investigation. The following example shows a failure for a critical backplane voltage alarm.

- ```json

- ```json

-* Health Check Server Power Action Failures

- ```json

- ```json

- ```json

- ```json

- ```json

-* PXE Device Check Considerations

- ```json

- ```json

- ```json

-### Special considerations

-* Servers Failing Multiple Health and Network Checks

- * Raid deletion is performed during cluster deploy and cluster delete actions for all releases inclusive of 3.12.

- * If we observe servers getting powered off during hardware validation with multiple failed health and network checks, we need to reattempt cluster deployment.

- * If issues persist, raid deletion needs to be performed manually on `control` nodes in the cluster.

- * To clear raid in BMC webui:

- `BMC` -> `Storage` -> `Virtual Disks` -> `Action` -> `Delete` -> `Apply Now`

- * To clear raid with racadm:

- ```bash

- racadm --nocertwarn -r $IP -u $BMC_USR -p $BMC_PWD raid deletevd:Disk.Virtual.239:RAID.SL.3-1

- racadm --nocertwarn -r $IP -u $BMC_USR -p $BMC_PWD jobqueue create RAID.SL.3-1 --realtime

- ```

-[sles-hae-guides]:https://www.suse.com/documentation/sle-ha-12/

-[sles-for-sap-bp]:https://www.suse.com/documentation/sles-for-sap-12/

-[suse-ha-12sp3-relnotes]:https://www.suse.com/releasenotes/x86_64/SLE-HA/12-SP3/

-* [SUSE Linux Enterprise High Availability Extension 12 SP3 best practices guides][sles-hae-guides]

- * Highly Available NFS Storage with DRBD and Pacemaker

-* [SUSE Linux Enterprise Server for SAP Applications 12 SP3 best practices guides][sles-for-sap-bp]

-* [SUSE High Availability Extension 12 SP3 Release Notes][suse-ha-12sp3-relnotes]

-|[Virtual machines and cloud services](/azure/azure-monitor/vm/monitor-virtual-machine)|Windows Event Log service and Linux Syslog| Captures system data and logging data on the virtual machines and transfers that data into a storage account of your choice.| Windows (using [Azure Diagnostics](/azure/azure-monitor/agents/diagnostics-extension-overview)] storage) and Linux in Azure Monitor|

-There are 4 components required to build the CCP data connector.

-3) The example `instructionsSteps` include a button of type `ConnectionToggleButton`. This button helps trigger the deployment of data connector rules based on the connection parameters specified.

-This portion defines the connection rules including:

-For more information on building this section, see the [Data connector connection rules reference](data-connector-connection-rules-reference.md).

-To learn from an example, see the [Data connector connection rules reference example](data-connector-connection-rules-reference.md#example-ccp-data-connector).

-Manually package an Azure Resource Management (ARM) template using the [example template code samples](#example-arm-template) as your guide. These code samples are divided by ARM template sections for you to splice together.

-In addition to the example template, published solutions available in the Microsoft Sentinel content hub use the CCP for their data connector. Review the following solutions as more examples of how to stitch the components together into an ARM template.

-## Next steps

-Microsoft Sentinel provides a wide range of [built-in connectors for Azure services and external solutions](connect-data-sources.md), and also supports ingesting data from some sources without a dedicated connector.

-# Data connector reference for the Codeless Connector Platform

-To create a data connector with the Codeless Connector Platform (CCP), use this document as a supplement to the [Microsoft Sentinel REST API for Data Connectors](/rest/api/securityinsights/data-connectors) reference docs. Specifically this reference document expands on the following details:

-The request body for the CCP data connector has the following structure:

-**RestApiPoller** represents the codeless API Poller connector.

-> CCP OAuth2 implementation does not support certificate credentials.

-OAuth2 auth code grant

- "ClientId": "[parameters('appId')]",

- "ClientSecret": "[parameters('appSecret')]",

- "ClientId": "[parameters('appId')]",

- "ClientSecret": "[parameters('appSecret')]",

- "password": "[parameters('username')]",

- "userName": "[parameters('password')]"

-Microsoft Sentinel provides Security Orchestration, Automation, and Response (SOAR) capabilities with [automation rules](automate-incident-handling-with-automation-rules.md) and [playbooks](tutorial-respond-threats-playbook.md). Automation rules automate incident handling and response, and playbooks run predetermined sequences of actions to response and remediate threats. This article discusses how to identify SOAR use cases, and how to migrate your Splunk SOAR automation to Microsoft Sentinel.

-Automation rules simplify complex workflows for your incident orchestration processes, and allow you to centrally manage your incident handling automation.

-With automation rules, you can:

-HereΓÇÖs what you need to think about when migrating SOAR use cases from Splunk.

-This article describes how to identify, compare, and migrate your Splunk detection rules to Microsoft Sentinel built-in rules.

-## Identify and migrate rules

-Microsoft Sentinel uses machine learning analytics to create high-fidelity and actionable incidents, and some of your existing detections may be redundant in Microsoft Sentinel. Therefore, don't migrate all of your detection and analytics rules blindly. Review these considerations as you identify your existing detection rules.

-Learn more about [best practices for migrating detection rules](https://techcommunity.microsoft.com/t5/microsoft-sentinel-blog/best-practices-for-migrating-detection-rules-from-arcsight/ba-p/2216417).

-**To migrate your analytics rules to Microsoft Sentinel**:

- 1. **Confirm that you have any required data sources connected,** and review your data connection methods.

-1. Verify whether your detections are available as built-in templates in Microsoft Sentinel:

- - **Use the SIEM migration experience** to automate translation and migration.

- - **If the built-in rules are sufficient**, use built-in rule templates to create rules for your own workspace.

- In Microsoft Sentinel, go to the **Configuration > Analytics > Rule templates** tab, and create and update each relevant analytics rule.

- For more information, see [Detect threats out-of-the-box](detect-threats-built-in.md).

- - **If you have detections that aren't covered by Microsoft Sentinel's built-in rules**, try an online query converter, such as [Uncoder.io](https://uncoder.io/) or [SPL2KQL](https://azure.github.io/spl2kql) to convert your queries to KQL.

- Identify the trigger condition and rule action, and then construct and review your KQL query.

- - **If neither the built-in rules nor an online rule converter is sufficient**, you'll need to create the rule manually. In such cases, use the following steps to start creating your rule:

- 1. **Identify the data sources you want to use in your rule**. You'll want to create a mapping table between data sources and data tables in Microsoft Sentinel to identify the tables you want to query.

- 1. **Identify your rule criteria and logic**. At this stage, you may want to use rule templates as samples for how to construct your KQL queries.

-1. Test the rule with each of your relevant use cases. If it doesn't provide expected results, you may want to review the KQL and test it again.

-1. When you're satisfied, you can consider the rule migrated. Create a playbook for your rule action as needed. For more information, see [Automate threat response with playbooks in Microsoft Sentinel](automate-responses-with-playbooks.md).

-This table helps you to clarify the concept of a rule in Microsoft Sentinel compared to Splunk.

-|`eval` |Calculates an expression. Learn about [common eval commands](https://github.com/Azure/Azure-Sentinel/blob/master/Tools/RuleMigration/SPL%20to%20KQL.md#common-eval-commands). |[extend](/azure/data-explorer/kusto/query/extendoperator) |`T | extend duration = endTime - startTime` |

-#### lookup command: KQL example

-#### stats command: KQL example

-#### mstats command: KQL example

-#### transaction command: SPL example

-#### transaction command: KQL example

-Use `row_window_session()` to the calculate session start values for a column in a serialized row set.

-#### eventstats command: SPL example

-#### eventstats command: KQL example

-#### anomalydetection command: SPL example

-#### anomalydetection command: KQL example

-### Common eval commands

-|`abs(X)` |Returns the absolute value of X. |`abs(number)` |[abs()](/azure/data-explorer/kusto/query/abs-function) |`abs(X)` |

-|`case(X,"Y",…)` |Takes pairs of `X` and `Y` arguments, where the `X` arguments are boolean expressions. When evaluated to `TRUE`, the arguments return the corresponding `Y` argument. |[SPL example](#casexy-spl-example) |[case](/azure/data-explorer/kusto/query/casefunction) |[KQL example](#casexy-kql-example) |

-|`ceil(X)` |Ceiling of a number X. |`ceil(1.9)` |[ceiling()](/azure/data-explorer/kusto/query/ceilingfunction) |`ceiling(1.9)` |

-|`cidrmatch("X",Y)` |Identifies IP addresses that belong to a particular subnet. |`cidrmatch`<br>`("123.132.32.0/25",ip)` |ΓÇó [ipv4_is_match()](/azure/data-explorer/kusto/query/ipv4-is-matchfunction)<br>ΓÇó [ipv6_is_match()](/azure/data-explorer/kusto/query/ipv6-is-matchfunction) |`ipv4_is_match('192.168.1.1', '192.168.1.255')`<br>`== false` |

-|`coalesce(X,…)` |Returns the first value that isn't null. |`coalesce(null(), "Returned val", null())` |[coalesce()](/azure/data-explorer/kusto/query/coalescefunction) |`coalesce(tolong("not a number"),`<br> `tolong("42"), 33) == 42` |

-|`exact(X)` |Evaluates an expression X using double precision floating point arithmetic. |`exact(3.14*num)` |[todecimal()](/azure/data-explorer/kusto/query/todecimalfunction) |`todecimal(3.14*2)` |

-|`if(X,Y,Z)` |If `X` evaluates to `TRUE`, the result is the second argument `Y`. If `X` evaluates to `FALSE`, the result evaluates to the third argument `Z`. |`if(error==200,`<br> `"OK", "Error")` |[iif()](/azure/data-explorer/kusto/query/iiffunction) |[KQL example](#ifxyz-kql-example) |

-|`isbool(X)` |Returns `TRUE` if `X` is boolean. |`isbool(field)` |ΓÇó [iif()](/azure/data-explorer/kusto/query/iiffunction)<br>ΓÇó [gettype](/azure/data-explorer/kusto/query/gettypefunction) |`iif(gettype(X) =="bool","TRUE","FALSE")` |

-|`isint(X)` |Returns `TRUE` if `X` is an integer. |`isint(field)` |ΓÇó [iif()](/azure/data-explorer/kusto/query/iiffunction)<br>ΓÇó [gettype](/azure/data-explorer/kusto/query/gettypefunction) |[KQL example](#isintx-kql-example) |

-|`isnull(X)` |Returns `TRUE` if `X` is null. |`isnull(field)` |[isnull()](/azure/data-explorer/kusto/query/isnullfunction) |`isnull(field)` |

-|`isstr(X)` |Returns `TRUE` if `X` is a string. |`isstr(field)` |ΓÇó [iif()](/azure/data-explorer/kusto/query/iiffunction)<br>ΓÇó [gettype](/azure/data-explorer/kusto/query/gettypefunction) |[KQL example](#isstrx-kql-example) |

-|`len(X)` |This function returns the character length of a string `X`. |`len(field)` |[strlen()](/azure/data-explorer/kusto/query/strlenfunction) |`strlen(field)` |

-|`like(X,"y")` |Returns `TRUE` if and only if `X` is like the SQLite pattern in `Y`. |`like(field, "addr%")` |ΓÇó [has](/azure/data-explorer/kusto/query/has-anyoperator)<br>ΓÇó [contains](/azure/data-explorer/kusto/query/datatypes-string-operators)<br>ΓÇó [startswith](/azure/data-explorer/kusto/query/datatypes-string-operators)<br>ΓÇó [matches regex](/azure/data-explorer/kusto/query/re2) |[KQL example](#likexy-example) |

-|`log(X,Y)` |Returns the log of the first argument `X` using the second argument `Y` as the base. The default value of `Y` is `10`. |`log(number,2)` |ΓÇó [log](/azure/data-explorer/kusto/query/log-function)<br>ΓÇó [log2](/azure/data-explorer/kusto/query/log2-function)<br>ΓÇó [log10](/azure/data-explorer/kusto/query/log10-function) |`log(X)`<br><br>`log2(X)`<br><br>`log10(X)` |

-|`ltrim(X,Y)` |Returns `X` with the characters in parameter `Y` trimmed from the left side. The default output of `Y` is spaces and tabs. |`ltrim(" ZZZabcZZ ", " Z")` |[trim_start()](/azure/data-explorer/kusto/query/trimstartfunction) |`trim_start(ΓÇ£ ZZZabcZZΓÇ¥,ΓÇ¥ ZZZΓÇ¥)` |

-|`match(X,Y)` |Returns if X matches the regex pattern Y. |`match(field, "^\d{1,3}.\d$")` |[matches regex](/azure/data-explorer/kusto/query/re2) |`… | where field matches regex @"^\d{1,3}.\d$")` |

-|`max(X,…)` |Returns the maximum value in a column. |`max(delay, mydelay)` |• [max()](/azure/data-explorer/kusto/query/max-aggfunction)<br>• [arg_max()](/azure/data-explorer/kusto/query/arg-max-aggfunction) |`… | summarize max(field)` |

-|`md5(X)` |Returns the MD5 hash of a string value `X`. |`md5(field)` |[hash_md5](/azure/data-explorer/kusto/query/md5hashfunction) |`hash_md5("X")` |

-|`min(X,…)` |Returns the minimum value in a column. |`min(delay, mydelay)` |• [min_of()](/azure/data-explorer/kusto/query/min-offunction)<br>• [min()](/azure/data-explorer/kusto/query/min-aggfunction)<br>• [arg_min](/azure/data-explorer/kusto/query/arg-min-aggfunction) |[KQL example](#minx-kql-example) |

-|`mvcount(X)` |Returns the number (total) of `X` values. |`mvcount(multifield)` |[dcount](/azure/data-explorer/kusto/query/dcount-aggfunction) |`…| summarize dcount(X) by Y` |

-|`mvfilter(X)` |Filters a multi-valued field based on the boolean `X` expression. |`mvfilter(match(email, "net$"))` |[mv-apply](/azure/data-explorer/kusto/query/mv-applyoperator) |[KQL example](#mvfilterx-kql-example) |

-|`mvindex(X,Y,Z)` |Returns a subset of the multi-valued `X` argument from a start position (zero-based) `Y` to `Z` (optional). |`mvindex( multifield, 2)` |[array_slice](/azure/data-explorer/kusto/query/arrayslicefunction) |`array_slice(arr, 1, 2)` |

-|`mvjoin(X,Y)` |Given a multi-valued field `X` and string delimiter `Y`, and joins the individual values of `X` using `Y`. |`mvjoin(address, ";")` |[strcat_array](/azure/data-explorer/kusto/query/strcat-arrayfunction) |[KQL example](#mvjoinxy-kql-example) |

-|`now()` |Returns the current time, represented in Unix time. |`now()` |[now()](/azure/data-explorer/kusto/query/nowfunction) |`now()`<br><br>`now(-2d)` |

-|`nullif(X,Y)` |Includes two arguments, `X` and `Y`, and returns `X` if the arguments are different. Otherwise, returns `NULL`. |`nullif(fieldA, fieldB)` |[iif](/azure/data-explorer/kusto/query/iiffunction) |`iif(fieldA==fieldB, null, fieldA)` |

-|`random()` |Returns a pseudo-random number between `0` to `2147483647`. |`random()` |[rand()](/azure/data-explorer/kusto/query/randfunction) |`rand()` |

-|`replace(X,Y,Z)` |Returns a string formed by substituting string `Z` for every occurrence of regular expression string `Y` in string `X`. |Returns date with the month and day numbers switched.<br>For example, for the `4/30/2015` input, the output is `30/4/2009`:<br><br>`replace(date, "^(\d{1,2})/ (\d{1,2})/", "\2/\1/")` |[replace()](/azure/data-explorer/kusto/query/replacefunction) |[KQL example](#replacexyz-kql-example) |

-|`round(X,Y)` |Returns `X` rounded to the number of decimal places specified by `Y`. The default is to round to an integer. |`round(3.5)` |[round](/azure/data-explorer/kusto/query/roundfunction) |`round(3.5)` |

-|`rtrim(X,Y)` |Returns `X` with the characters of `Y` trimmed from the right side. If `Y` isn't specified, spaces and tabs are trimmed. |`rtrim(" ZZZZabcZZ ", " Z")` |[trim_end()](/azure/data-explorer/kusto/query/trimendfunction) |`trim_end(@"[ Z]+",A)` |

-| `split(X,"Y")` |Returns `X` as a multi-valued field, split by delimiter `Y`. |`split(address, ";")` |[split()](/azure/data-explorer/kusto/query/splitfunction) |`split(address, ";")` |

-|`sqrt(X)` |Returns the square root of `X`. |`sqrt(9)` |[sqrt()](/azure/data-explorer/kusto/query/sqrtfunction) |`sqrt(9)` |

-|`strftime(X,Y)` |Returns the epoch time value `X` rendered using the format specified by `Y`. |`strftime(_time, "%H:%M")` |[format_datetime()](/azure/data-explorer/kusto/query/format-datetimefunction) |`format_datetime(time,'HH:mm')` |

-|`substr(X,Y,Z)` |Returns a substring field `X` from start position (one-based) `Y` for `Z` (optional) characters. |`substr("string", 1, 3)` |[substring()](/azure/data-explorer/kusto/query/substringfunction) |`substring("string", 0, 3)` |

-|`time()` |Returns the wall-clock time with microsecond resolution. |`time()` |[format_datetime()](/azure/data-explorer/kusto/query/format-datetimefunction) |[KQL example](#time-kql-example) |

-|`tonumber(X,Y)` |Converts input string `X` to a number, where `Y` (optional, default value is `10`) defines the base of the number to convert to. |`tonumber("0A4",16)` |[toint()](/azure/data-explorer/kusto/query/tointfunction) |`toint("123")` |

-|`tostring(X,Y)` |[Description](#tostringxy) |[SPL example](#tostringxy-spl-example) |[tostring()](/azure/data-explorer/kusto/query/tostringfunction) |`tostring(123)` |

-|`typeof(X)` |Returns a string representation of the field type. |`typeof(12)` |[gettype()](/azure/data-explorer/kusto/query/gettypefunction) |`gettype(12)` |

-|`urldecode(X)` |Returns the URL `X` decoded. |[SPL example](#urldecodex-spl-example) |[url_decode](/azure/data-explorer/kusto/query/urldecodefunction) |[KQL example](#urldecodex-spl-example) |

-#### case(X,"Y",…) SPL example

-#### case(X,"Y",…) KQL example

-#### if(X,Y,Z) KQL example

-#### isint(X) KQL example

-#### isstr(X) KQL example

-#### like(X,"y") example

-#### min(X,…) KQL example

-#### mvfilter(X) KQL example

-#### mvjoin(X,Y) KQL example

-#### relative time(X,Y) KQL example

-#### replace(X,Y,Z) KQL example

-#### strptime(X,Y) KQL example

-#### time() KQL example

-#### tostring(X,Y)

-##### tostring(X,Y) SPL example

-#### urldecode(X) SPL example

-### Common stats commands KQL example

-|Migrate from Splunk |ΓÇó [Migrate detection rules](migration-splunk-detection-rules.md)<br>ΓÇó [Migrate SOAR automation](migration-splunk-automation.md)<br>ΓÇó [Export historical data](migration-splunk-historical-data.md)<br><br>If you want to migrate your Splunk Observability deployment, learn more about how to [migrate from Splunk to Azure Monitor Logs](/azure/azure-monitor/logs/migrate-splunk-to-azure-monitor-logs). |

-## Next steps

- - If the data connectors aren't installed yet, find the relevant solutions in **Content hub**.

- - If no data connector exists, create a custom ingestion pipeline.<br>For more information, see [Discover and manage Microsoft Sentinel out-of-the-box content](sentinel-solutions-deploy.md) or [Custom data ingestion and transformation](data-transformation.md).

-At the core of Splunk detection rules is the Search Processing Language (SPL). The SIEM migration experience systematically translates SPL to Kusto query language (KQL) for each Splunk rule. Carefully review translations and make adjustments to ensure migrated rules function as intended in your Microsoft Sentinel workspace. For more information on the concepts important in translating detection rules, see [migrate Splunk detection rules](migration-splunk-detection-rules.md).

-Here are some of the priorities that are important to us as we continue to develop the translation technology:

-1. Navigate to Microsoft Sentinel in the [Azure portal](https://portal.azure.com), under **Content management**, select **Content hub**.

- `| rest splunk_server=local count=0 /services/saved/searches | search disabled=0 | table title,search ,*`

- - **Translation State** has the following values:

- - **Fully Translated** queries in this rule were fully translated to KQL

- - **Partially Translated** queries in this rule weren't fully translated to KQL

- - **Not Translated** indicates an error in translation

- - **Manually Translated** when any rule is reviewed and saved

- > [!NOTE]

- > Check the schema of the data types and fields used in the rule logic. Microsoft Sentinel Analytics require that the data type be present in the Log Analytics Workspace before the rule is enabled. It's also important the fields used in the query are accurate for the defined data type schema.

-1. Highlight a rule to resolve translation and select **Edit**. When you are satisfied with the results, select **Save Changes**.

-1. Switch on the **Ready to deploy** toggle for Analytics rules you want to deploy.

-1. (Optional) Choose Analytics rules and select **Export Templates** to download them as ARM templates for use in your CI/CD or custom deployment processes.

-## Next step

-> [!div class="nextstepaction"]

-> [Migrate Splunk detection rules](migration-splunk-detection-rules.md)

-SAS authentication support for Service Bus is included in the Azure .NET SDK versions 2.0 and later. SAS includes support for a shared access authorization rule. All APIs that accept a connection string as a parameter include support for SAS connection strings.

-Obtaining count of messages in the dead-letter queue at the topic level isn't applicable because messages don't sit at the topic level. Instead, when a sender sends a message to a topic, the message is forwarded to subscriptions for the topic within milliseconds and thus no longer resides at the topic level. So, you can see messages in the DLQ associated with the subscription for the topic. In the following example, **Service Bus Explorer** shows that there are 62 messages currently in the DLQ for the subscription "test1".

- > After you enable replication, two more fully qualified domain names are created on the private

- > endpoints in both regions. Ensure that you add the DNS records for these newly created

- > fully qualified domain names as well.

-## Query samples

-You can learn more about querying various types of data using the sample queries.

-### Tools

-The tools you need to issue queries:

- - Azure Synapse Studio

- - Azure Data Studio

- - SQL Server Management Studio

-### Demo setup

-Your first step is to **create a database** where you'll execute the queries. Then you'll initialize the objects by executing [setup script](https://github.com/Azure-Samples/Synapse/blob/master/SQL/Samples/LdwSample/SampleDB.sql) on that database.

-This setup script will create the data sources, database scoped credentials, and external file formats that are used to read data in these samples.

-> [!NOTE]

-> Databases are only used for viewing metadata, not for actual data. Write down the database name that you use, you will need it later on.

-```sql

-CREATE DATABASE mydbname;

-```

-### Provided demo data

-Demo data contains the following data sets:

-| Folder path | Description |

-| | |

-| /csv/ | Parent folder for data in CSV format |

-| /csv/population/<br />/csv/population-unix/<br />/csv/population-unix-hdr/<br />/csv/population-unix-hdr-escape<br />/csv/population-unix-hdr-quoted | Folders with Population data files in different CSV formats. |

-| /csv/taxi/ | Folder with NYC public data files in CSV format |

-| /parquet/ | Parent folder for data in Parquet format |

-| /parquet/taxi | NYC public data files in Parquet format, partitioned by year, and month using Hive/Hadoop partitioning scheme. |

-| /parquet/nested/ | Sample Parquet files with nested columns |

-| /json/ | Parent folder for data in JSON format |

-| /json/books/ | JSON files with books data |

-description: Identify common issues using the Troubleshooter in Azure Update Manager.

-# Troubleshoot issues in Azure Update Manager

-This article describes how to use the Troubleshooter in Azure Update Manager to identify common issues and how to resolve them.

-The Troubleshooter option is enabled when checking for history of only **Failed** operations in Azure Update Manager.

-The Troubleshooter can also be seen when checking history of **Failed** operations in the machineΓÇÖs updates history tab.

-## Prerequisites

- - Microsoft.Compute/virtualMachines/runCommand/write permission (for Azure) - The [Virtual Machine Contributor](/azure/role-based-access-control/built-in-roles#virtual-machine-contributor) role and higher levels have this permission.

- - Microsoft.HybridCompute/machines/runCommands/write permission (for Arc) - The [Azure Connected Machine Resource Administrator](/azure/role-based-access-control/built-in-roles) role and higher levels have this permission.

-## What does the Troubleshooter do?

-The troubleshooter performs two types of checks for both Azure and Arc machines.

-You can find the [scripts](https://github.com/Azure/AzureUpdateManager/tree/main/Troubleshooter) here.

-Post performing the checks, the troubleshooter suggests possible mitigations to test for checks that failed. Follow the mitigation links and take appropriate actions.

-## What are Managed RUN Commands?

-## Next steps

-* To learn more about Update Manager, see the [Overview](overview.md).

-* To view logged results from all your machines, see [Querying logs and results from Update Manager](query-logs.md).

-

-> - Autoscale isn't supported on Azure Virtual Desktop for Azure Stack HCI.

-> Azure Virtual Desktop on Azure Stack HCI is currently in preview for Azure Government and Azure China. See the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

- | **Select which directory you would like to join** | **Active Directory** is the only available option. |

-> For Azure Stack HCI, you can only join session hosts to an Active Directory Domain Services domain.