-Azure AD also supports provisioning users into applications hosted on-premises or in a virtual machine, without having to open up any firewalls. If your application supports [SCIM](https://aka.ms/scimoverview), or you've built a SCIM gateway to connect to your legacy application, you can use the Azure AD Provisioning agent to [directly connect](./on-premises-scim-provisioning.md) with your application and automate provisioning and deprovisioning. If you have legacy applications that don't support SCIM and rely on an [LDAP](./on-premises-ldap-connector-configure.md) user store or a [SQL](./tutorial-ecma-sql-connector.md) database, Azure AD can support those as well.

-In the future, support for the assignment of a single token to multiple users will stop to prevent a security risk.

-When web apps authenticate with the Microsoft Identity platform using the response mode "form_post", the login server responds to the application using an HTTP POST to send the tokens or auth code. Because this request is a cross-domain request (from `login.microsoftonline.com` to your domain - for instance `https://contoso.com/auth`), cookies that were set by your app now fall under the new rules in Chrome. The cookies that need to be used in cross-site scenarios are cookies that hold the *state* and *nonce* values, that are also sent in the login request. There are other cookies dropped by Azure AD to hold the session.

-This approach is demonstrated in our code samples below.

-The table below presents the pull requests that worked around the SameSite changes in our ASP.NET and ASP.NET Core samples.

-| Sample | Pull request |

-| | |

-| [ASP.NET Core web app incremental tutorial](https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2) | [Same site cookie fix #261](https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/pull/261) |

-| [ASP.NET MVC web app sample](https://github.com/Azure-Samples/ms-identity-aspnet-webapp-openidconnect) | [Same site cookie fix #35](https://github.com/Azure-Samples/ms-identity-aspnet-webapp-openidconnect/pull/35) |

-| [active-directory-dotnet-admin-restricted-scopes-v2](https://github.com/azure-samples/active-directory-dotnet-admin-restricted-scopes-v2) | [Same site cookie fix #28](https://github.com/Azure-Samples/active-directory-dotnet-admin-restricted-scopes-v2/pull/28) |

-| Sample |

-| |

-| [ms-identity-python-webapp](https://github.com/Azure-Samples/ms-identity-python-webapp) |

-| Sample | Pull request |

-| | |

-| [ms-identity-java-webapp](https://github.com/Azure-Samples/ms-identity-java-webapp) | [Same site cookie fix #24](https://github.com/Azure-Samples/ms-identity-java-webapp/pull/24)

-| [ms-identity-java-webapi](https://github.com/Azure-Samples/ms-identity-java-webapi) | [Same site cookie fix #4](https://github.com/Azure-Samples/ms-identity-java-webapi/pull/4)

-> Ony users can remove OS accounts, whereas apps themselves cannot. If an OS account is passed into `RemoveAsync`, and then `GetAccounts` is called with `ListWindowsWorkAndSchoolAccounts` enabled, the same OS accounts will still be returned.

-> Most Azure web APIs provide an SDK that simplifies calling the API as is the case for Microsoft Graph. See, for instance, [Create a web application that authorizes access to Blob storage with Azure AD](../../storage/common/storage-auth-aad-app.md?tabs=dotnet&toc=%2fazure%2fstorage%2fblobs%2ftoc.json) for an example of a web app using Microsoft.Identity.Web and using the Azure Storage SDK.

-You can use the OAuth 2.0 client credentials grant specified in [RFC 6749](https://tools.ietf.org/html/rfc6749#section-4.4), sometimes called *two-legged OAuth*, to access web-hosted resources by using the identity of an application. This type of grant is commonly used for server-to-server interactions that must run in the background, without immediate interaction with a user. These types of applications are often referred to as *daemons* or *service accounts*.

-This article describes how to program directly against the protocol in your application. When possible, we recommend you use the supported Microsoft Authentication Libraries (MSAL) instead to [acquire tokens and call secured web APIs](authentication-flows-app-scenarios.md#scenarios-and-supported-authentication-flows). Also take a look at the [sample apps that use MSAL](sample-v2-code.md). As a side note, refresh tokens will never be granted with this flow as `client_id` and `client_secret` (which would be required to obtain a refresh token) can be used to obtain an access token instead.

-The OAuth 2.0 client credentials grant flow permits a web service (confidential client) to use its own credentials, instead of impersonating a user, to authenticate when calling another web service. For a higher level of assurance, the Microsoft identity platform also allows the calling service to authenticate using a [certificate](#second-case-access-token-request-with-a-certificate) or federated credential instead of a shared secret. Because the application's own credentials are being used, these credentials must be kept safe - _never_ publish that credential in your source code, embed it in web pages, or use it in a widely distributed native application.

-In the client credentials flow, permissions are granted directly to the application itself by an administrator. When the app presents a token to a resource, the resource enforces that the app itself has authorization to perform an action since there is no user involved in the authentication. This article covers both the steps needed to [authorize an application to call an API](#application-permissions), as well as [how to get the tokens needed to call that API](#get-a-token).

-A common use case is to use an ACL to run tests for a web application or for a web API. The web API might grant only a subset of full permissions to a specific client. To run end-to-end tests on the API, create a test client that acquires tokens from the Microsoft identity platform and then sends them to the API. The API then checks the ACL for the test client's application ID for full access to the API's entire functionality. If you use this kind of ACL, be sure to validate not only the caller's `appid` value but also validate that the `iss` value of the token is trusted.

-Instead of using ACLs, you can use APIs to expose a set of **application permissions**. An application permission is granted to an application by an organization's administrator, and can be used only to access data owned by that organization and its employees. For example, Microsoft Graph exposes several application permissions to do the following:

-Typically, when you build an application that uses application permissions, the app requires a page or view on which the admin approves the app's permissions. This page can be part of the app's sign-in flow, part of the app's settings, or it can be a dedicated "connect" flow. In many cases, it makes sense for the app to show this "connect" view only after a user has signed in with a work or school Microsoft account.

-| Parameter | Condition | Description |

-| | | |

-| `tenant` | Required | The directory tenant that you want to request permission from. This can be in GUID or friendly name format. If you don't know which tenant the user belongs to and you want to let them sign in with any tenant, use `common`. |

-| `client_id` | Required | The **Application (client) ID** that the [Azure portal ΓÇô App registrations](https://go.microsoft.com/fwlink/?linkid=2083908) experience assigned to your app. |

-| `redirect_uri` | Required | The redirect URI where you want the response to be sent for your app to handle. It must exactly match one of the redirect URIs that you registered in the portal, except that it must be URL-encoded, and it can have additional path segments. |

-| `state` | Recommended | A value that's included in the request that's also returned in the token response. It can be a string of any content that you want. The state is used to encode information about the user's state in the app before the authentication request occurred, such as the page or view they were on. |

-At this point, Azure AD enforces that only a tenant administrator can sign into complete the request. The administrator will be asked to approve all the direct application permissions that you have requested for your app in the app registration portal.

-| Parameter | Description |

-| | |

-| `tenant` | The directory tenant that granted your application the permissions that it requested, in GUID format. |

-| `state` | A value that is included in the request that also is returned in the token response. It can be a string of any content that you want. The state is used to encode information about the user's state in the app before the authentication request occurred, such as the page or view they were on. |

-| Parameter | Description |

-| | |

-| `error` | An error code string that you can use to classify types of errors, and which you can use to react to errors. |

-After you've acquired the necessary authorization for your application, proceed with acquiring access tokens for APIs. To get a token by using the client credentials grant, send a POST request to the `/token` Microsoft identity platform:

-```Bash

-| Parameter | Condition | Description |

-| | | |

-| `tenant` | Required | The directory tenant the application plans to operate against, in GUID or domain-name format. |

-| `client_id` | Required | The application ID that's assigned to your app. You can find this information in the portal where you registered your app. |

-| `scope` | Required | The value passed for the `scope` parameter in this request should be the resource identifier (application ID URI) of the resource you want, affixed with the `.default` suffix. For the Microsoft Graph example, the value is `https://graph.microsoft.com/.default`. <br/>This value tells the Microsoft identity platform that of all the direct application permissions you have configured for your app, the endpoint should issue a token for the ones associated with the resource you want to use. To learn more about the `/.default` scope, see the [consent documentation](v2-permissions-and-consent.md#the-default-scope). |

-| `client_secret` | Required | The client secret that you generated for your app in the app registration portal. The client secret must be URL-encoded before being sent. The Basic auth pattern of instead providing credentials in the Authorization header, per [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749#section-2.3.1) is also supported. |

-| `grant_type` | Required | Must be set to `client_credentials`. |

-| Parameter | Condition | Description |

-| | | |

-| `tenant` | Required | The directory tenant the application plans to operate against, in GUID or domain-name format. |

-| `client_id` | Required |The application (client) ID that's assigned to your app. |

-| `scope` | Required | The value passed for the `scope` parameter in this request should be the resource identifier (application ID URI) of the resource you want, affixed with the `.default` suffix. For the Microsoft Graph example, the value is `https://graph.microsoft.com/.default`. <br/>This value informs the Microsoft identity platform that of all the direct application permissions you have configured for your app, it should issue a token for the ones associated with the resource you want to use. To learn more about the `/.default` scope, see the [consent documentation](v2-permissions-and-consent.md#the-default-scope). |

-| `client_assertion_type` | Required | The value must be set to `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`. |

-| `client_assertion` | Required | An assertion (a JSON web token) that you need to create and sign with the certificate you registered as credentials for your application. Read about [certificate credentials](active-directory-certificate-credentials.md) to learn how to register your certificate and the format of the assertion.|

-| `grant_type` | Required | Must be set to `client_credentials`. |

-| Parameter | Condition | Description |

-| | | |

-| `client_assertion` | Required | An assertion (a JWT, or JSON web token) that your application gets from another identity provider outside of Microsoft identity platform, like Kubernetes. The specifics of this JWT must be registered on your application as a [federated identity credential](workload-identity-federation-create-trust.md). Read about [workload identity federation](workload-identity-federation.md) to learn how to setup and use assertions generated from other identity providers.|

-Everything in the request is the same as the certificate-based flow above, with one crucial exception - the source of the `client_assertion`. In this flow, your application does not create the JWT assertion itself. Instead, your app uses a JWT created by another identity provider. This is called "[workload identity federation](workload-identity-federation.md)", where your apps identity in another identity platform is used to acquire tokens inside the Microsoft identity platform. This is best suited for cross-cloud scenarios, such as hosting your compute outside Azure but accessing APIs protected by Microsoft identity platform. For information about the required format of JWTs created by other identity providers, read about the [assertion format](active-directory-certificate-credentials.md#assertion-format).

-| Parameter | Description |

-| | |

-| `token_type` | Indicates the token type value. The only type that the Microsoft identity platform supports is `bearer`. |

-| `expires_in` | The amount of time that an access token is valid (in seconds). |

- "timestamp": "2016-01-09 02:02:12Z",

-| Parameter | Description |

-| | |

-| `error` | An error code string that you can use to classify types of errors that occur, and to react to errors. |

-| `error_codes` | A list of STS-specific error codes that might help with diagnostics. |

-| `timestamp` | The time when the error occurred. |

-| `trace_id` | A unique identifier for the request to help with diagnostics. |

-| `correlation_id` | A unique identifier for the request to help with diagnostics across components. |

-# Pro tip: Try the following command! (Replace the token with your own.)

-|[active-directory-dotnetcore-daemon-v2](https://github.com/Azure-Samples/active-directory-dotnetcore-daemon-v2) | .NET Core 2.1 Console | A simple .NET Core application that displays the users of a tenant querying the Microsoft Graph using the identity of the application, instead of on behalf of a user. The sample also illustrates the variation using certificates for authentication. |

-|[ms-identity-javascript-nodejs-console](https://github.com/Azure-Samples/ms-identity-javascript-nodejs-console)| Node.js Console | A simple Node.js application that displays the users of a tenant by querying the Microsoft Graph using the identity of the application |

-In the B2B collaboration flows, we add users to the directory and dynamically update them during invitation redemption, app assignment, and so on. The updates and writes ordinarily happen in one directory instance and must be replicated across all instances. Replication is completed once all instances are updated. Sometimes when the object is written or updated in one instance and the call to retrieve this object is to another instance, replication latencies can occur. If that happens, refresh or retry to help. If you are writing an app using our API, then retries with some back-off is a good, defensive practice to alleviate this issue.

-There is also **Merge** and **MergeCaseInsensitive**. These options allow you to merge values from different sources. For example, it can be used to merge the member or proxyAddresses attribute from several different forests. When you use this option, all sync rules in scope for an object must use the same merge type. You cannot define **Update** from one Connector and **Merge** from another. If you try, you receive an error.

-The function ImportedValue is different than all other functions since the attribute name must be enclosed in quotes rather than square brackets:

-Usually during synchronization an attribute uses the expected value, even if it hasnΓÇÖt been exported yet or an error was received during export (ΓÇ£top of the towerΓÇ¥). An inbound synchronization assumes that an attribute that hasnΓÇÖt yet reached a connected directory eventually reaches it. In some cases, it is important to only synchronize a value that has been confirmed by the connected directory (ΓÇ£hologram and delta import towerΓÇ¥).

-An example of this function can be found in the out-of-box Synchronization Rule *In from AD ΓÇô User Common from Exchange*. In Hybrid Exchange, the value added by Exchange online should only be synchronized when it has been confirmed that the value was exported successfully:

-If you have several objects in the same connector space joined to the same metaverse object, precedence must be adjusted. If several objects are in scope of the same sync rule, then the sync engine is not able to determine precedence. It is ambiguous which source object should contribute the value to the metaverse. This configuration is reported as ambiguous even if the attributes in the source have the same value.

-

-For this scenario, you need to change the scope of the sync rules so the source objects have different sync rules in scope. That allows you to define different precedence.

-

- If you have a nested group like this, you'll see an export error in Azure AD Connect with the message "A universal group cannot have a local group as a member." The resolution is to remove the member with the **Domain local** scope from the Azure AD group, or update the nested group member scope in Active Directory to **Global** or **Universal**.

-description: This Azure AD Connect Health article describes agent installation for Active Directory Federation Services (AD FS) and for Sync.

-# Azure AD Connect Health agent installation

-In this article, you'll learn how to install and configure the Azure Active Directory (Azure AD) Connect Health agents. To download the agents, see [these instructions](how-to-connect-install-roadmap.md#download-and-install-azure-ad-connect-health-agent).

-> Azure AD Connect Health is not available in the China sovereign cloud

-The following table lists requirements for using Azure AD Connect Health.

-| There is an Azure AD Premium (P1 or P2) Subsciption. |Azure AD Connect Health is a feature of Azure AD Premium (P1 or P2). For more information, see [Sign up for Azure AD Premium](../fundamentals/active-directory-get-started-premium.md). <br /><br />To start a free 30-day trial, see [Start a trial](https://azure.microsoft.com/trial/get-started-active-directory/). |

-| You're a Hybrid Identity Administrator in Azure AD. |By default, only Hybrid Identity Administrators or global administrators can install and configure the health agents, access the portal, and do any operations within Azure AD Connect Health. For more information, see [Administering your Azure AD directory](../fundamentals/active-directory-whatis.md). <br /><br /> By using Azure role-based access control (Azure RBAC), you can allow other users in your organization to access Azure AD Connect Health. For more information, see [Azure RBAC for Azure AD Connect Health](how-to-connect-health-operations.md#manage-access-with-azure-rbac). <br /><br />**Important**: Use a work or school account to install the agents. You can't use a Microsoft account. For more information, see [Sign up for Azure as an organization](../fundamentals/sign-up-organization.md). |

-| The Azure AD Connect Health agent is installed on each targeted server. | Health agents must be installed and configured on targeted servers so that they can receive data and provide monitoring and analytics capabilities. <br /><br />For example, to get data from your Active Directory Federation Services (AD FS) infrastructure, you must install the agent on the AD FS server and the Web Application Proxy server. Similarly, to get data from your on-premises Azure AD Domain Services (Azure AD DS) infrastructure, you must install the agent on the domain controllers. |

-| The Azure service endpoints have outbound connectivity. | During installation and runtime, the agent requires connectivity to Azure AD Connect Health service endpoints. If firewalls block outbound connectivity, add the [outbound connectivity endpoints](how-to-connect-health-agent-install.md#outbound-connectivity-to-the-azure-service-endpoints) to the allow list. |

-| Firewall ports on the server are running the agent. |The agent requires the following firewall ports to be open so that it can communicate with the Azure AD Connect Health service endpoints: <br /><li>TCP port 443</li><li>TCP port 5671</li> <br />The latest version of the agent doesn't require port 5671. Upgrade to the latest version so that only port 443 is required. For more information, see [Hybrid identity required ports and protocols](./reference-connect-ports.md). |

-| If Internet Explorer enhanced security is enabled, allow specified websites. |If Internet Explorer enhanced security is enabled, then allow the following websites on the server where you install the agent:<br /><li>https:\//login.microsoftonline.com</li><li>https:\//secure.aadcdn.microsoftonline-p.com</li><li>https:\//login.windows.net</li><li>https:\//aadcdn.msftauth.net</li><li>The federation server for your organization that's trusted by Azure AD (for example, https:\//sts.contoso.com)</li> <br />For more information, see [How to configure Internet Explorer](https://support.microsoft.com/help/815141/internet-explorer-enhanced-security-configuration-changes-the-browsing). If you have a proxy in your network, then see the note that appears at the end of this table.|

-| PowerShell version 5.0 or newer is installed. | Windows Server 2016 includes PowerShell version 5.0.

-> If you have a highly locked-down and restricted environment, you need to add more URLs than the ones the table lists for Internet Explorer enhanced security. Also add URLs that are listed in the table in the next section.

-### New versions of the agent and Auto upgrade

-If a new version of the Health agent is released, any existing installed agents are automatically updated.

-### Outbound connectivity to the Azure service endpoints

-During installation and runtime, the agent needs connectivity to Azure AD Connect Health service endpoints. If firewalls block outbound connectivity, make sure that the URLs in the following table aren't blocked by default.

-Don't disable security monitoring or inspection of these URLs. Instead, allow them as you would allow other internet traffic.

-These URLs allow communication with Azure AD Connect Health service endpoints. Later in this article, you'll learn how to [check outbound connectivity](#test-connectivity-to-azure-ad-connect-health-service) by using `Test-AzureADConnectHealthConnectivity`.

-| General public | <li>&#42;.blob.core.windows.net </li><li>&#42;.aadconnecthealth.azure.com </li><li>&#42;*.servicebus.windows.net - Port: 5671 (If 5671 is blocked, the agent falls back to 443, but using 5671 is recommended. This endpoint isn't required in the latest version of the agent.)</li><li>&#42;.adhybridhealth.azure.com/</li><li>https:\//management.azure.com </li><li>https:\//policykeyservice.dc.ad.msft.net/</li><li>https:\//login.windows.net</li><li>https:\//login.microsoftonline.com</li><li>https:\//secure.aadcdn.microsoftonline-p.com </li><li>https:\//www.office.com (This endpoint is used only for discovery purposes during registration.)</li> <li>https://aadcdn.msftauth.net</li><li>https://aadcdn.msauth.net</li> |

-| Azure Germany | <li>&#42;.blob.core.cloudapi.de </li><li>&#42;.servicebus.cloudapi.de </li> <li>&#42;.aadconnecthealth.microsoftazure.de </li><li>https:\//management.microsoftazure.de </li><li>https:\//policykeyservice.aadcdi.microsoftazure.de </li><li>https:\//login.microsoftonline.de </li><li>https:\//secure.aadcdn.microsoftonline-p.de </li><li>https:\//www.office.de (This endpoint is used only for discovery purposes during registration.)</li> <li>https://aadcdn.msftauth.net</li><li>https://aadcdn.msauth.net</li> |

-| Azure Government | <li>&#42;.blob.core.usgovcloudapi.net </li> <li>&#42;.servicebus.usgovcloudapi.net </li> <li>&#42;.aadconnecthealth.microsoftazure.us </li> <li>https:\//management.usgovcloudapi.net </li><li>https:\//policykeyservice.aadcdi.azure.us </li><li>https:\//login.microsoftonline.us </li><li>https:\//secure.aadcdn.microsoftonline-p.com </li><li>https:\//www.office.com (This endpoint is used only for discovery purposes during registration.)</li> <li>https://aadcdn.msftauth.net</li><li>https://aadcdn.msauth.net</li> |

-## Install the agent

-To download and install the Azure AD Connect Health agent:

-* Make sure that you satisfy the [requirements](how-to-connect-health-agent-install.md#requirements) for Azure AD Connect Health.

-* Get started using Azure AD Connect Health for AD FS:

- * [Download the Azure AD Connect Health agent for AD FS](https://go.microsoft.com/fwlink/?LinkID=518973).

- * See the [installation instructions](#install-the-agent-for-ad-fs).

-* Get started using Azure AD Connect Health for Sync:

- * [Download and install the latest version of Azure AD Connect](https://go.microsoft.com/fwlink/?linkid=615771). The health agent for Sync is installed as part of the Azure AD Connect installation (version 1.0.9125.0 or later).

-* Get started using Azure AD Connect Health for Azure AD DS:

- * [Download the Azure AD Connect Health agent for Azure AD DS](https://go.microsoft.com/fwlink/?LinkID=820540).

- * See the [installation instructions](#install-the-agent-for-azure-ad-ds).

-> Your AD FS server should be different from your Sync server. Don't install the AD FS agent on your Sync server.

-To start the agent installation, double-click the *.exe* file that you downloaded. In the first window, select **Install**.

-

-

-

-After you sign in, PowerShell continues. When it finishes, you can close PowerShell. The configuration is complete.

-At this point, the agent services should start automatically to allow the agent to securely upload the required data to the cloud service.

-If you haven't met all of the prerequisites, warnings appear in the PowerShell window. Be sure to complete the [requirements](how-to-connect-health-agent-install.md#requirements) before you install the agent. The following screenshot shows an example of these warnings.

-

-* Azure AD Connect Health AD FS Diagnostics Service

-* Azure AD Connect Health AD FS Insights Service

-* Azure AD Connect Health AD FS Monitoring Service

-

-> This section applies only to AD FS servers. You don't have to follow these steps on the Web Application Proxy servers.

-The Usage Analytics feature needs to gather and analyze data. So the Azure AD Connect Health agent needs the information in the AD FS audit logs. These logs aren't enabled by default. Use the following procedures to enable AD FS auditing and to locate the AD FS audit logs on your AD FS servers.

-1. On the Start screen, open **Server Manager**, and then open **Local Security Policy**. Or on the taskbar, open **Server Manager**, and then select **Tools/Local Security Policy**.

-2. Go to the *Security Settings\Local Policies\User Rights Assignment* folder. Then double-click **Generate security audits**.

-3. On the **Local Security Setting** tab, verify that the AD FS service account is listed. If it's not listed, then select **Add User or Group**, and add it to the list. Then select **OK**.

-4. To enable auditing, open a Command Prompt window with elevated privileges. Then run the following command:

-

- >[!Important]

- >The following steps are required only for primary AD FS servers.

-1. In the **Federation Service Properties** dialog box, select the **Events** tab.

-1. Select the **Success audits and Failure audits** check boxes, and then select **OK**.

-1. To enable verbose logging through PowerShell, use the following command:

-1. On the Start screen, open **Server Manager**, and then open **Local Security Policy**. Or on the taskbar, open **Server Manager**, and then select **Tools/Local Security Policy**.

-2. Go to the *Security Settings\Local Policies\User Rights Assignment* folder, and then double-click **Generate security audits**.

-3. On the **Local Security Setting** tab, verify that the AD FS service account is listed. If it's not listed, then select **Add User or Group**, and add the AD FS service account to the list. Then select **OK**.

-4. To enable auditing, open a Command Prompt window with elevated privileges. Then run the following command:

- >[!Important]

- >The following steps are required only for primary AD FS servers.

-1. In the **Federation Service Properties** dialog box, select the **Events** tab.

-1. Select the **Success audits and Failure audits** check boxes, and then select **OK**. Success audits and failure audits should be enabled by default.

-1. Open a PowerShell window and run the following command:

-3. On the right, select **Filter Current Logs**.

- 

-## Install the agent for Sync

-The Azure AD Connect Health agent for Sync is installed automatically in the latest version of Azure AD Connect. To use Azure AD Connect for Sync, [download the latest version of Azure AD Connect](https://www.microsoft.com/download/details.aspx?id=47594) and install it.

-To verify the agent has been installed, look for the following services on the server. If you completed the configuration, the services should already be running. Otherwise, the services are stopped until the configuration is complete.

-* Azure AD Connect Health Sync Insights Service

-* Azure AD Connect Health Sync Monitoring Service

-

->

->

-## Manually register Azure AD Connect Health for Sync

-If the Azure AD Connect Health for Sync agent registration fails after you successfully install Azure AD Connect, then you can use a PowerShell command to manually register the agent.

->

->

-Manually register the Azure AD Connect Health agent for Sync by using the following PowerShell command. The Azure AD Connect Health services will start after the agent has been successfully registered.

-* **AttributeFiltering**: `$true` (default) if Azure AD Connect isn't syncing the default attribute set and has been customized to use a filtered attribute set. Otherwise, use `$false`.

-* **StagingMode**: `$false` (default) if the Azure AD Connect server is *not* in staging mode. If the server is configured to be in staging mode, use `$true`.

-When you're prompted for authentication, use the same Global Administrator account (such as admin@domain.onmicrosoft.com) that you used to configure Azure AD Connect.

-

-

-

-At this point, the services should be started automatically, allowing the agent to monitor and gather data. If you haven't met all of the prerequisites outlined in the previous sections, then warnings appear in the PowerShell window. Be sure to complete the [requirements](how-to-connect-health-agent-install.md#requirements) before you install the agent. The following screenshot shows an example of these warnings.

-

-* Azure AD Connect Health AD DS Insights Service

-* Azure AD Connect Health AD DS Monitoring Service

-

-1. Create a user account in Azure AD. Secure it by using a password.

-2. Assign the **Owner** role for this local Azure AD account in Azure AD Connect Health by using the portal. Follow [these steps](how-to-connect-health-operations.md#manage-access-with-azure-rbac). Assign the role to all service instances.

-3. Download the *.exe* MSI file in the local domain controller for the installation.

-4. Run the following script. Replace the parameters with your new user account and its password.

-When you finish, you can remove access for the local account by doing one or more of the following tasks:

-* Remove the role assignment for the local account for Azure AD Connect Health.

-* Rotate the password for the local account.

-* Disable the Azure AD local account.

-* Delete the Azure AD local account.

-After you install the appropriate agent *setup.exe* file, you can register the agent by using the following PowerShell commands, depending on the role. Open a PowerShell window and run the appropriate command:

-These commands accept `Credential` as a parameter to complete the registration noninteractively or to complete the registration on a machine that runs Server Core. Keep in mind that:

-* You can capture `Credential` in a PowerShell variable that's passed as a parameter.

-* You can provide any Azure AD identity that has permissions to register the agents and that does *not* have multifactor authentication enabled.

-* By default, global admins have permissions to register the agents. You can also allow less-privileged identities to do this step. For more information, see [Azure RBAC](how-to-connect-health-operations.md#manage-access-with-azure-rbac).

-> * `Netsh WinHttp set ProxyServerAddress` is not supported. The agent uses System.Net instead of Windows HTTP Services to make web requests.

-> * The configured HTTP proxy address is used to pass-through encrypted HTTPS messages.

-> * Authenticated proxies (using HTTPBasic) are not supported.

->

-* Import existing proxy settings.

-* Specify proxy addresses manually.

-* Clear the existing proxy configuration.

-> To update the proxy settings, you must restart all Azure AD Connect Health agent services. Run the following command:

-You can import Internet Explorer HTTP proxy settings so that the Azure AD Connect Health agents can use the settings. On each of the servers that run the health agent, run the following PowerShell command:

-Here's an example:

-* The `address` setting can be a DNS-resolvable server name or an IPv4 address.

-* You can omit `port`. If you do, then 443 is the default port.

-## Test connectivity to Azure AD Connect Health service

-Occasionally, the Azure AD Connect Health agent can lose connectivity with the Azure AD Connect Health service. Causes of this connectivity loss can include network problems, permission problems, and various other problems.

-If the agent can't send data to the Azure AD Connect Health service for longer than two hours, the following alert appears in the portal: "Health Service data is not up to date."

-The role parameter currently takes the following values:

-* ADFS

-* Sync

-* ADDS

-> To use the connectivity tool, you must first register the agent. If you can't complete the agent registration, make sure that you have met all of the [requirements](how-to-connect-health-agent-install.md#requirements) for Azure AD Connect Health. Connectivity is tested by default during agent registration.

->

->

-* [Azure AD Connect Health](./whatis-azure-ad-connect.md)

-* [Azure AD Connect Health operations](how-to-connect-health-operations.md)

-* [Using Azure AD Connect Health with AD FS](how-to-connect-health-adfs.md)

-* [Using Azure AD Connect Health for Sync](how-to-connect-health-sync.md)

-* [Using Azure AD Connect Health with Azure AD DS](how-to-connect-health-adds.md)

-* [Azure AD Connect Health FAQ](reference-connect-health-faq.yml)

-* [Azure AD Connect Health version history](reference-connect-health-version-history.md)

-description: This article describes how Azure Active Directory (Azure AD) Pass-through Authentication protects your on-premises accounts

-keywords: Azure AD Connect Pass-through Authentication, install Active Directory, required components for Azure AD, SSO, Single Sign-on

-# Azure Active Directory Pass-through Authentication security deep dive

-This article provides a more detailed description of how Azure Active Directory (Azure AD) Pass-through Authentication works. It focuses on the security aspects of the feature. This article is for security and IT administrators, chief compliance and security officers, and other IT professionals who are responsible for IT security and compliance at small-to-medium sized organizations or large enterprises.

-## Key security capabilities

-These are the key security aspects of this feature:

- - Port 80 is used only for downloading the Certificate Revocation Lists (CRLs) to ensure that none of the certificates used by this feature have been revoked.

- - For the complete list of the network requirements, see [Azure Active Directory Pass-through Authentication: Quickstart](how-to-connect-pta-quick-start.md#step-1-check-the-prerequisites).

-## Components involved

-For general details about Azure AD operational, service, and data security, see the [Trust Center](https://azure.microsoft.com/support/trust-center/). The following components are involved when you use Pass-through Authentication for user sign-in:

-## Installation and registration of the Authentication Agents

-Authentication Agents are installed and registered with Azure AD when you either:

- - [Enable Pass-through Authentication through Azure AD Connect](./how-to-connect-pta-quick-start.md#step-2-enable-the-feature)

- - [Add more Authentication Agents to ensure the high availability of sign-in requests](./how-to-connect-pta-quick-start.md#step-4-ensure-high-availability)

-

-Getting an Authentication Agent working involves three main phases:

-1. Authentication Agent installation

-2. Authentication Agent registration

-3. Authentication Agent initialization

-### Authentication Agent installation

-Only Hybrid Identity Administrators can install an Authentication Agent (by using Azure AD Connect or standalone) on an on-premises server. Installation adds two new entries to the **Control Panel** > **Programs** > **Programs and Features** list:

->[!IMPORTANT]

->From a security standpoint, administrators should treat the server running the PTA agent as if it were a domain controller. The PTA agent servers should be hardened along the same lines as outlined in [Securing Domain Controllers Against Attack](/windows-server/identity/ad-ds/plan/security-best-practices/securing-domain-controllers-against-attack)

-### Authentication Agent registration

-After you install the Authentication Agent, it needs to register itself with Azure AD. Azure AD assigns each Authentication Agent a unique, digital-identity certificate that it can use for secure communication with Azure AD.

-The registration procedure also binds the Authentication Agent with your tenant. This ensures that Azure AD knows that this specific Authentication Agent is the only one authorized to handle password validation requests for your tenant. This procedure is repeated for each new Authentication Agent that you register.

-The Authentication Agents use the following steps to register themselves with Azure AD:

-

-1. Azure AD first requests that a Hybrid Identity Administrator sign in to Azure AD with their credentials. During sign-in, the Authentication Agent acquires an access token that it can use on behalf of the

-2. The Authentication Agent then generates a key pair: a public key and a private key.

- - The key pair is generated through standard RSA 2048-bit encryption.

- - The private key stays on the on-premises server where the Authentication Agent resides.

-3. The Authentication Agent makes a ΓÇ£registrationΓÇ¥ request to Azure AD over HTTPS, with the following components included in the request:

- - The access token acquired in step 1.

- - The public key generated in step 2.

- - A Certificate Signing Request (CSR or Certificate Request). This request applies for a digital identity certificate, with Azure AD as its certificate authority (CA).

-4. Azure AD validates the access token in the registration request and verifies that the request came from a Hybrid Identity Administrator.

-5. Azure AD then signs and sends a digital identity certificate back to the Authentication Agent.

- - The root CA in Azure AD is used to sign the certificate.

- > This CA is _not_ in the Windows Trusted Root Certificate Authorities store.

- - The CA is used only by the Pass-through Authentication feature. The CA is used only to sign CSRs during the Authentication Agent registration.

- - None of the other Azure AD services use this CA.

- - The certificateΓÇÖs subject (Distinguished Name or DN) is set to your tenant ID. This DN is a GUID that uniquely identifies your tenant. This DN scopes the certificate for use only with your tenant.

-6. Azure AD stores the public key of the Authentication Agent in a database in Azure SQL Database, which only Azure AD has access to.

-7. The certificate (issued in step 5) is stored on the on-premises server in the Windows certificate store (specifically in the [CERT_SYSTEM_STORE_LOCAL_MACHINE](/windows/win32/seccrypto/system-store-locations#CERT_SYSTEM_STORE_LOCAL_MACHINE) location). It is used by both the Authentication Agent and the Updater applications.

-### Authentication Agent initialization

-When the Authentication Agent starts, either for the first time after registration or after a server restart, it needs a way to communicate securely with the Azure AD service and start accepting password validation requests.

-

-Here is how Authentication Agents are initialized:

-1. The Authentication Agent makes an outbound bootstrap request to Azure AD.

- - This request is made over port 443 and is over a mutually authenticated HTTPS channel. The request uses the same certificate that was issued during the Authentication Agent registration.

-2. Azure AD responds to the request by providing an access key to an Azure Service Bus queue that's unique to your tenant and that's identified by your tenant ID.

-3. The Authentication Agent makes a persistent outbound HTTPS connection (over port 443) to the queue.

- - The Authentication Agent is now ready to retrieve and handle password-validation requests.

-If you have multiple Authentication Agents registered on your tenant, then the initialization procedure ensures that each one connects to the same Service Bus queue.

-## Process sign-in requests

-The following diagram shows how Pass-through Authentication processes user sign-in requests.

-

-Pass-through Authentication handles a user sign-in request as follows:

-2. If the user is not already signed in, the application redirects the browser to the Azure AD sign-in page.

-3. The Azure AD STS service responds back with the **User sign-in** page.

-4. The user enters their username into the **User sign-in** page, and then selects the **Next** button.

-5. The user enters their password into the **User sign-in** page, and then selects the **Sign-in** button.

-6. The username and password are submitted to Azure AD STS in an HTTPS POST request.

-7. Azure AD STS retrieves public keys for all the Authentication Agents registered on your tenant from Azure SQL Database and encrypts the password by using them.

- - It produces "N" encrypted password values for "N" Authentication Agents registered on your tenant.

-8. Azure AD STS places the password validation request, which consists of the username and the encrypted password values, onto the Service Bus queue specific to your tenant.

-9. Because the initialized Authentication Agents are persistently connected to the Service Bus queue, one of the available Authentication Agents retrieves the password validation request.

-10. The Authentication Agent locates the encrypted password value that's specific to its public key, by using an identifier, and decrypts it by using its private key.

-11. The Authentication Agent attempts to validate the username and the password against on-premises Active Directory by using the [Win32 LogonUser API](/windows/win32/api/winbase/nf-winbase-logonusera) with the **dwLogonType** parameter set to **LOGON32_LOGON_NETWORK**.

- - This API is the same API that is used by Active Directory Federation Services (AD FS) to sign in users in a federated sign-in scenario.

-12. The Authentication Agent receives the result from Active Directory, such as success, username or password incorrect, or password expired.

- > If the Authentication Agent fails during the sign-in process, the whole sign-in request is dropped. There is no hand-off of sign-in requests from one Authentication Agent to another Authentication Agent on-premises. These agents only communicate with the cloud, and not with each other.

-

-13. The Authentication Agent forwards the result back to Azure AD STS over an outbound mutually authenticated HTTPS channel over port 443. Mutual authentication uses the certificate previously issued to the Authentication Agent during registration.

-14. Azure AD STS verifies that this result correlates with the specific sign-in request on your tenant.

-15. Azure AD STS continues with the sign-in procedure as configured. For example, if the password validation was successful, the user might be challenged for Multi-Factor Authentication or redirected back to the application.

-## Operational security of the Authentication Agents

-To ensure that Pass-through Authentication remains operationally secure, Azure AD periodically renews Authentication Agents' certificates. Azure AD triggers the renewals. The renewals are not governed by the Authentication Agents themselves.

-

-To renew an Authentication Agent's trust with Azure AD:

-1. The Authentication Agent periodically pings Azure AD every few hours to check if it's time to renew its certificate. The certificate is renewed 30 days prior to its expiration.

- - This check is done over a mutually authenticated HTTPS channel and uses the same certificate that was issued during registration.

-2. If the service indicates that it's time to renew, the Authentication Agent generates a new key pair: a public key and a private key.

- - These keys are generated through standard RSA 2048-bit encryption.

-3. The Authentication Agent then makes a ΓÇ£certificate renewalΓÇ¥ request to Azure AD over HTTPS, with the following components included in the request:

- - The existing certificate that's retrieved from the CERT_SYSTEM_STORE_LOCAL_MACHINE location on the Windows certificate store. There is no global administrator involved in this procedure, so there is no access token needed on behalf of the global administrator.

- - A Certificate Signing Request (CSR or Certificate Request). This request applies for a new digital identity certificate, with Azure AD as its certificate authority.

-4. Azure AD validates the existing certificate in the certificate renewal request. Then it verifies that the request came from an Authentication Agent registered on your tenant.

-5. If the existing certificate is still valid, Azure AD then signs a new digital identity certificate, and issues the new certificate back to the Authentication Agent.

-6. If the existing certificate has expired, Azure AD deletes the Authentication Agent from your tenantΓÇÖs list of registered Authentication Agents. Then a global administrator or hybrid identity administrator needs to manually install and register a new Authentication Agent.

- - Set the certificateΓÇÖs subject (Distinguished Name or DN) to your tenant ID, a GUID that uniquely identifies your tenant. The DN scopes the certificate to your tenant only.

-6. Azure AD stores the new public key of the Authentication Agent in a database in Azure SQL Database that only it has access to. It also invalidates the old public key associated with the Authentication Agent.

-7. The new certificate (issued in step 5) is then stored on the server in the Windows certificate store (specifically in the [CERT_SYSTEM_STORE_CURRENT_USER](/windows/win32/seccrypto/system-store-locations#CERT_SYSTEM_STORE_CURRENT_USER) location).

- - Because the trust renewal procedure happens non-interactively (without the presence of the global administrator or hybrid identity administrator), the Authentication Agent no longer has access to update the existing certificate in the CERT_SYSTEM_STORE_LOCAL_MACHINE location.

-

-8. The new certificate is used for authentication from this point on. Every subsequent renewal of the certificate replaces the certificate in the CERT_SYSTEM_STORE_LOCAL_MACHINE location.

-## Auto-update of the Authentication Agents

-The Updater application automatically updates the Authentication Agent when a new version (with bug fixes or performance enhancements) is released. The Updater application does not handle any password validation requests for your tenant.

-Azure AD hosts the new version of the software as a signed **Windows Installer package (MSI)**. The MSI is signed by using [Microsoft Authenticode](/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms537359(v=vs.85)) with SHA256 as the digest algorithm.

-

-To auto-update an Authentication Agent:

-1. The Updater application pings Azure AD every hour to check if there is a new version of the Authentication Agent available.

- - This check is done over a mutually authenticated HTTPS channel by using the same certificate that was issued during registration. The Authentication Agent and the Updater share the certificate stored on the server.

-2. If a new version is available, Azure AD returns the signed MSI back to the Updater.

-3. The Updater verifies that the MSI is signed by Microsoft.

-4. The Updater runs the MSI. This action involves the following steps:

- - Stops the Authentication Agent service

- - Installs the new version of the Authentication Agent on the server

- - Restarts the Authentication Agent service

->[!NOTE]

->If you have multiple Authentication Agents registered on your tenant, Azure AD does not renew their certificates or update them at the same time. Instead, Azure AD does so one at a time to ensure the high availability of sign-in requests.

->

-description: This article describes how to get started with Azure Active Directory Seamless Single Sign-On

-# Azure Active Directory Seamless Single Sign-On: Quickstart

-## Deploy Seamless Single Sign-On

-Azure Active Directory (Azure AD) Seamless Single Sign-On (Seamless SSO) automatically signs in users when they are on their corporate desktops that are connected to your corporate network. Seamless SSO provides your users with easy access to your cloud-based applications without needing any additional on-premises components.

-To deploy Seamless SSO, follow these steps.

-## Step 1: Check the prerequisites

-* **Set up your Azure AD Connect server**: If you use [Pass-through Authentication](how-to-connect-pta.md) as your sign-in method, no additional prerequisite check is required. If you use [password hash synchronization](how-to-connect-password-hash-synchronization.md) as your sign-in method, and if there is a firewall between Azure AD Connect and Azure AD, ensure that:

- - You use version 1.1.644.0 or later of Azure AD Connect.

- - If your firewall or proxy allows, add the connections to the allowed list for **\*.msappproxy.net** URLs over port 443. If you require a specific URL rather than a wildcard for proxy configuration, you can configure **tenantid.registration.msappproxy.net**, where tenantid is the GUID of the tenant where you are configuring the feature. If URL-based proxy exceptions are not possible in your organization, you can instead allow access to the [Azure datacenter IP ranges](https://www.microsoft.com/download/details.aspx?id=41653), which are updated weekly. This prerequisite is applicable only when you enable the feature. It is not required for actual user sign-ins.

- >[!NOTE]

- >Azure AD Connect versions 1.1.557.0, 1.1.558.0, 1.1.561.0, and 1.1.614.0 have a problem related to password hash synchronization. If you _don't_ intend to use password hash synchronization in conjunction with Pass-through Authentication, read the [Azure AD Connect release notes](./reference-connect-version-history.md) to learn more.

-

- >[!NOTE]

- >If you have an outgoing HTTP proxy, make sure this URL, autologon.microsoftazuread-sso.com, is on the allowed list. You should specify this URL explicitly since wildcard may not be accepted.

-* **Use a supported Azure AD Connect topology**: Ensure that you are using one of Azure AD Connect's supported topologies described [here](plan-connect-topologies.md).

- >[!NOTE]

- >Seamless SSO supports multiple AD forests, whether there are AD trusts between them or not.

-* **Set up domain administrator credentials**: You need to have domain administrator credentials for each Active Directory forest that:

- * You synchronize to Azure AD through Azure AD Connect.

- * Contains users you want to enable for Seamless SSO.

-

-* **Enable modern authentication**: You need to enable [modern authentication](/office365/enterprise/modern-auth-for-office-2013-and-2016) on your tenant for this feature to work.

-* **Use the latest versions of Microsoft 365 clients**: To get a silent sign-on experience with Microsoft 365 clients (Outlook, Word, Excel, and others), your users need to use versions 16.0.8730.xxxx or above.

-## Step 2: Enable the feature

->[!NOTE]

-> You can also [enable Seamless SSO using PowerShell](tshoot-connect-sso.md#manual-reset-of-the-feature) if Azure AD Connect doesn't meet your requirements. Use this option if you have more than one domain per Active Directory forest, and you want to be more targeted about the domain you want to enable Seamless SSO for.

-If you're doing a fresh installation of Azure AD Connect, choose the [custom installation path](how-to-connect-install-custom.md). At the **User sign-in** page, select the **Enable single sign on** option.

->[!NOTE]

-> The option will be available for selection only if the Sign On method is **Password Hash Synchronization** or **Pass-through Authentication**.

-

-If you already have an installation of Azure AD Connect, select the **Change user sign-in** page in Azure AD Connect, and then select **Next**. If you are using Azure AD Connect versions 1.1.880.0 or above, the **Enable single sign on** option will be selected by default. If you are using older versions of Azure AD Connect, select the **Enable single sign on** option.

-

-Continue through the wizard until you get to the **Enable single sign on** page. Provide domain administrator credentials for each Active Directory forest that:

-* You synchronize to Azure AD through Azure AD Connect.

-* Contains users you want to enable for Seamless SSO.

-After completion of the wizard, Seamless SSO is enabled on your tenant.

->[!NOTE]

-> The domain administrator credentials are not stored in Azure AD Connect or in Azure AD. They're used only to enable the feature.

-Follow these instructions to verify that you have enabled Seamless SSO correctly:

-1. Sign in to the [Azure Active Directory administrative center](https://aad.portal.azure.com) with the Hybrid Identity Administrator or hybrid identity administrator credentials for your tenant.

-2. Select **Azure Active Directory** in the left pane.

-3. Select **Azure AD Connect**.

-4. Verify that the **Seamless single sign-on** feature appears as **Enabled**.

-

->[!IMPORTANT]

-> Seamless SSO creates a computer account named `AZUREADSSOACC` in your on-premises Active Directory (AD) in each AD forest. The `AZUREADSSOACC` computer account needs to be strongly protected for security reasons. Only Domain Admins should be able to manage the computer account. Ensure that Kerberos delegation on the computer account is disabled, and that no other account in Active Directory has delegation permissions on the `AZUREADSSOACC` computer account. Store the computer account in an Organization Unit (OU) where they are safe from accidental deletions and where only Domain Admins have access.

->[!NOTE]

-> If you are using Pass-the-Hash and Credential Theft Mitigation architectures in your on-premises environment, make appropriate changes to ensure that the `AZUREADSSOACC` computer account doesn't end up in the Quarantine container.

-## Step 3: Roll out the feature

-You can gradually roll out Seamless SSO to your users using the instructions provided below. You start by adding the following Azure AD URL to all or selected users' Intranet zone settings by using Group Policy in Active Directory:

-In addition, you need to enable an Intranet zone policy setting called **Allow updates to status bar via script** through Group Policy.

->[!NOTE]

-> The following instructions work only for Internet Explorer, Microsoft Edge, and Google Chrome on Windows (if it shares a set of trusted site URLs with Internet Explorer). Read the next section for instructions on how to set up Mozilla Firefox and Google Chrome on macOS.

-### Why do you need to modify users' Intranet zone settings?

-By default, the browser automatically calculates the correct zone, either Internet or Intranet, from a specific URL. For example, `http://contoso/` maps to the Intranet zone, whereas `http://intranet.contoso.com/` maps to the Internet zone (because the URL contains a period). Browsers will not send Kerberos tickets to a cloud endpoint, like the Azure AD URL, unless you explicitly add the URL to the browser's Intranet zone.

-There are two ways to modify users' Intranet zone settings:

-| Group policy | Admin locks down editing of Intranet zone settings | Users cannot modify their own settings |

-| Group policy preference | Admin allows editing on Intranet zone settings | Users can modify their own settings |

-### "Group policy" option - Detailed steps

-2. Edit the group policy that's applied to some or all your users. This example uses **Default Domain Policy**.

-3. Browse to **User Configuration** > **Policies** > **Administrative Templates** > **Windows Components** > **Internet Explorer** > **Internet Control Panel** > **Security Page**. Then select **Site to Zone Assignment List**.

- 

-4. Enable the policy, and then enter the following values in the dialog box:

- - **Value** (Data): **1** indicates the Intranet zone.

- The result looks like this:

- >[!NOTE]

- > If you want to disallow some users from using Seamless SSO (for instance, if these users sign in on shared kiosks), set the preceding values to **4**. This action adds the Azure AD URL to the Restricted zone, and fails Seamless SSO all the time.

-5. Select **OK**, and then select **OK** again.

- 

-6. Browse to **User Configuration** > **Policies** > **Administrative Templates** > **Windows Components** > **Internet Explorer** > **Internet Control Panel** > **Security Page** > **Intranet Zone**. Then select **Allow updates to status bar via script**.

- 

-7. Enable the policy setting, and then select **OK**.

- 

-### "Group policy preference" option - Detailed steps

-2. Edit the group policy that's applied to some or all your users. This example uses **Default Domain Policy**.

-3. Browse to **User Configuration** > **Preferences** > **Windows Settings** > **Registry** > **New** > **Registry item**.

- 

-4. Enter the following values in appropriate fields and click **OK**.

- - **Key Path**: ***Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoftazuread-sso.com\autologon***

- - **Value name**: ***https***

- - **Value type**: ***REG_DWORD***

- - **Value data**: ***00000001***

-

- 

-

- 

-If you are using the [Authentication](https://github.com/mozill#authentication) policy settings in your environment, ensure that you add Azure AD's URL (`https://autologon.microsoftazuread-sso.com`) to the **SPNEGO** section. You can also set the **PrivateBrowsing** option to true to allow seamless SSO in private browsing mode.

-Ensure that the machine running the macOS is joined to AD. Instructions for AD-joining your macOS device is outside the scope of this article.

-If you have overridden the [AuthNegotiateDelegateAllowlist](/DeployEdge/microsoft-edge-policies#authnegotiatedelegateallowlist) or the [AuthServerAllowlist](/DeployEdge/microsoft-edge-policies#authserverallowlist) policy settings in your environment, ensure that you add Azure AD's URL (`https://autologon.microsoftazuread-sso.com`) to them as well.

-For Microsoft Edge based on Chromium on macOS and other non-Windows platforms, refer to [the Microsoft Edge based on Chromium Policy List](/DeployEdge/microsoft-edge-policies#authserverallowlist) for information on how to add the Azure AD URL for integrated authentication to your allow-list.

-If you have overridden the [AuthNegotiateDelegateAllowlist](https://chromeenterprise.google/policies/#AuthNegotiateDelegateAllowlist) or the [AuthServerAllowlist](https://chromeenterprise.google/policies/#AuthServerAllowlist) policy settings in your environment, ensure that you add Azure AD's URL (`https://autologon.microsoftazuread-sso.com`) to them as well.

-The use of third-party Active Directory Group Policy extensions to roll out the Azure AD URL to Firefox and Google Chrome to macOS users is outside the scope of this article.

-Seamless SSO doesn't work on Internet Explorer if the browser is running in Enhanced Protected mode. Seamless SSO supports the next version of Microsoft Edge based on Chromium and it works in InPrivate and Guest mode by design. Microsoft Edge (legacy) is no longer supported.

- `AmbientAuthenticationInPrivateModesEnabled`may need to be configured for InPrivate and / or guest users based on the corresponding documentations:

-

- - [Microsoft Edge Chromium](/DeployEdge/microsoft-edge-policies#ambientauthenticationinprivatemodesenabled)

- - [Google Chrome](https://chromeenterprise.google/policies/?policy=AmbientAuthenticationInPrivateModesEnabled)

-## Step 4: Test the feature

- - The user signs in on a corporate device.

- - The device is joined to your Active Directory domain. The device _doesn't_ need to be [Azure AD Joined](../devices/overview.md).

- - The device has a direct connection to your domain controller (DC), either on the corporate wired or wireless network or via a remote access connection, such as a VPN connection.

- - You have [rolled out the feature](#step-3-roll-out-the-feature) to this user through Group Policy.

-To test the scenario where the user enters only the username, but not the password:

- - Sign in to https://myapps.microsoft.com/. Be sure to either clear the browser cache or use a new private browser session with any of the supported browsers in private mode.

-To test the scenario where the user doesn't have to enter the username or the password, use one of these steps:

- - Sign in to `https://myapps.microsoft.com/contoso.onmicrosoft.com` Be sure to either clear the browser cache or use a new private browser session with any of the supported browsers in private mode. Replace *contoso* with your tenant's name.

- - Sign in to `https://myapps.microsoft.com/contoso.com` in a new private browser session. Replace *contoso.com* with a verified domain (not a federated domain) on your tenant.

-## Step 5: Roll over keys

-In Step 2, Azure AD Connect creates computer accounts (representing Azure AD) in all the Active Directory forests on which you have enabled Seamless SSO. To learn more, see [Azure Active Directory Seamless Single Sign-On: Technical deep dive](how-to-connect-sso-how-it-works.md).

->[!IMPORTANT]

->The Kerberos decryption key on a computer account, if leaked, can be used to generate Kerberos tickets for any user in its AD forest. Malicious actors can then impersonate Azure AD sign-ins for compromised users. We highly recommend that you periodically roll over these Kerberos decryption keys - at least once every 30 days.

-For instructions on how to roll over keys, see [Azure Active Directory Seamless Single Sign-On: Frequently asked questions](how-to-connect-sso-faq.yml).

->[!IMPORTANT]

->You don't need to do this step _immediately_ after you have enabled the feature. Roll over the Kerberos decryption keys at least once every 30 days.

-### Disable the scheduled task

-1. Go to a PowerShell prompt.

-2. Run `Set-ADSyncScheduler -SyncCycleEnabled $False` to disable the scheduler.

-3. Make the changes that are documented in this article.

-4. Run `Set-ADSyncScheduler -SyncCycleEnabled $True` to enable the scheduler again.

-**If you use an Azure AD Connect build before 1.1.105.0**

-To disable the scheduled task that triggers a synchronization cycle every three hours, follow these steps:

-1. Start **Task Scheduler** from the **Start** menu.

-2. Directly under **Task Scheduler Library**, find the task named **Azure AD Sync Scheduler**, right-click, and select **Disable**.

- 

-3. You can now make configuration changes and run the sync engine manually from the **Synchronization Service Manager** console.

-After you've completed all your filtering changes, don't forget to come back and **Enable** the task again.

-description: Learn how to upgrade from DirSync to Azure AD Connect. This articles describes the steps for upgrading from DirSync to Azure AD Connect.

-Azure AD Connect is the successor to DirSync. You find the ways you can upgrade from DirSync in this topic. These steps do not work for upgrading from another release of Azure AD Connect or from Azure AD Sync.

-DirSync and Azure AD Sync are not supported and will no longer work. If you are still using these you MUST upgrade to AADConnect to resume your sync process.

-Before you start installing Azure AD Connect, make sure to [download Azure AD Connect](https://go.microsoft.com/fwlink/?LinkId=615771) and complete the pre-requisite steps in [Azure AD Connect: Hardware and prerequisites](how-to-connect-install-prerequisites.md). In particular, you want to read about the following, since these areas are different from DirSync:

-* The required version of .NET and PowerShell. Newer versions are required to be on the server than what DirSync needed.

-* The proxy server configuration. If you use a proxy server to reach the internet, this setting must be configured before you upgrade. DirSync always used the proxy server configured for the user installing it, but Azure AD Connect uses machine settings instead.

-* The URLs required to be open in the proxy server. For basic scenarios, those scenarios also supported by DirSync, the requirements are the same. If you want to use any of the new features included with Azure AD Connect, some new URLs must be opened.

-> [!NOTE]

-> Once you have enabled your new Azure AD Connect server to start synchronizing changes to Azure AD, you must not roll back to using DirSync or Azure AD Sync. Downgrading from Azure AD Connect to legacy clients including DirSync and Azure AD Sync is not supported and can lead to issues such as data loss in Azure AD.

-If you are not upgrading from DirSync, see related documentation for other scenarios.

-Depending on your current DirSync deployment, there are different options for the upgrade. If the expected upgrade time is less than three hours, then the recommendation is to do an in-place upgrade. If the expected upgrade time is more than three hours, then the recommendation is to do a parallel deployment on another server. It is estimated that if you have more than 50,000 objects it takes more than three hours to do the upgrade.

-| Scenario |

-| |

-| [In-place upgrade](#in-place-upgrade) |

-| [Parallel deployment](#parallel-deployment) |

-> When you plan to upgrade from DirSync to Azure AD Connect, do not uninstall DirSync yourself before the upgrade. Azure AD Connect will read and migrate the configuration from DirSync and uninstall after inspecting the server.

-**In-place upgrade**

-The expected time to complete the upgrade is displayed by the wizard. This estimate is based on the assumption that it takes three hours to complete an upgrade for a database with 50,000 objects (users, contacts, and groups). If the number of objects in your database is less than 50,000, then Azure AD Connect recommends an in-place upgrade. If you decide to continue, your current settings are automatically applied during upgrade and your server automatically resumes active synchronization.

-If you want to do a configuration migration and do a parallel deployment, then you can override the in-place upgrade recommendation. You might for example take the opportunity to refresh the hardware and operating system. For more information, see the [parallel deployment](#parallel-deployment) section.

-**Parallel deployment**

-If you have more than 50,000 objects, then a parallel deployment is recommended. This deployment avoids any operational delays experienced by your users. The Azure AD Connect installation attempts to estimate the downtime for the upgrade, but if you've upgraded DirSync in the past, your own experience is likely to be the best guide.

-### Supported DirSync configurations to be upgraded

-The following configuration changes are supported with upgraded DirSync:

-* Domain and OU filtering

-* Alternate ID (UPN)

-* Password sync and Exchange hybrid settings

-* Your forest/domain and Azure AD settings

-* Filtering based on user attributes

-The following change cannot be upgraded. If you have this configuration, the upgrade is blocked:

-* Unsupported DirSync changes, for example removed attributes and using a custom extension DLL

-

-In those cases, the recommendation is to install a new Azure AD Connect server in [staging mode](how-to-connect-sync-staging-server.md) and verify the old DirSync and new Azure AD Connect configuration. Reapply any changes using custom configuration, as described in [Azure AD Connect Sync custom configuration](how-to-connect-sync-whatis.md).

-The passwords used by DirSync for the service accounts cannot be retrieved and are not migrated. These passwords are reset during the upgrade.

-2. Analysis of current DirSync configuration

-3. Collect Azure AD Hybrid Identity Administrator password

-4. Collect credentials for an enterprise admin account (only used during the installation of Azure AD Connect)

-5. Installation of Azure AD Connect

- * Uninstall DirSync (or temporarily disable it)

- * Install Azure AD Connect

- * Optionally begin synchronization

-Additional steps are required when:

-* You're currently using Full SQL Server - local or remote

-* You have more than 50,000 objects in scope for synchronization

-1. Launch the Azure AD Connect installer (MSI).

-2. Review and agree to license terms and privacy notice.

- 

-3. Click next to begin analysis of your existing DirSync installation.

- 

-4. When the analysis completes, you see the recommendations on how to proceed.

- * If you use SQL Server Express and have less than 50,000 objects, the following screen is shown:

- 

- * If you use a full SQL Server for DirSync, you see this page instead:

- 

- The information regarding the existing SQL Server database server being used by DirSync is displayed. Make appropriate adjustments if needed. Click **Next** to continue the installation.

- * If you have more than 50,000 objects, you see this screen instead:

- 

- To proceed with an in-place upgrade, click the checkbox next to this message: **Continue upgrading DirSync on this computer.**

- To do a [parallel deployment](#parallel-deployment) instead, you export the DirSync configuration settings and move the configuration to the new server.

-5. Provide the password for the account you currently use to connect to Azure AD. This must be the account currently used by DirSync.

- 

- If you receive an error and have problems with connectivity, see [Troubleshoot connectivity problems](tshoot-connect-connectivity.md).

-6. Provide an enterprise admin account for Active Directory.

- 

-7. You're now ready to configure. When you click **Upgrade**, DirSync is uninstalled and Azure AD Connect is configured and begins synchronizing.

- 

-8. After the installation has completed, sign out and sign in again to Windows before you use Synchronization Service Manager, Synchronization Rule Editor, or try to make any other configuration changes.

-**Parallel deployment with more than 50,000 objects**

-If you have more than 50,000 objects, then the Azure AD Connect installation recommends a parallel deployment.

-A screen similar to the following is displayed:

-

-If you want to proceed with parallel deployment, you need to perform the following steps:

-* Click the **Export settings** button. When you install Azure AD Connect on a separate server, these settings are migrated from your current DirSync to your new Azure AD Connect installation.

-Once your settings have been successfully exported, you can exit the Azure AD Connect wizard on the DirSync server. Continue with the next step to install Azure AD Connect on a separate server

-**Parallel deployment with less than 50,000 objects**

-If you have less than 50,000 objects but still want to do a parallel deployment, then do the following:

-1. Run the Azure AD Connect installer (MSI).

-2. When you see the **Welcome to Azure AD Connect** screen, exit the installation wizard by clicking the "X" in the top right corner of the window.

-3. Open a command prompt.

-4. From the install location of Azure AD Connect (Default: C:\Program Files\Microsoft Azure Active Directory Connect) execute the following command:

- `AzureADConnect.exe /ForceExport`.

-5. Click the **Export settings** button. When you install Azure AD Connect on a separate server, these settings are migrated from your current DirSync to your new Azure AD Connect installation.

-

-Once your settings have been successfully exported, you can exit the Azure AD Connect wizard on the DirSync server. Continue with the next step to install Azure AD Connect on a separate server.

-### Install Azure AD Connect on separate server

-When you install Azure AD Connect on a new server, the assumption is that you want to perform a clean install of Azure AD Connect. Since you want to use the DirSync configuration, there are some extra steps to take:

-1. Run the Azure AD Connect installer (MSI).

-2. When you see the **Welcome to Azure AD Connect** screen, exit the installation wizard by clicking the "X" in the top right corner of the window.

-3. Open a command prompt.

-4. From the install location of Azure AD Connect (Default: C:\Program Files\Microsoft Azure Active Directory Connect) execute the following command:

- `AzureADConnect.exe /migrate`.

- The Azure AD Connect installation wizard starts and presents you with the following screen:

- 

-5. Select the settings file that exported from your DirSync installation.

-6. Configure any advanced options including:

- * A custom installation location for Azure AD Connect.

- * An existing instance of SQL Server (Default: Azure AD Connect installs SQL Server 2019 Express). Do not use the same database instance as your DirSync server.

- * A service account used to connect to SQL Server (If your SQL Server database is remote then this account must be a domain service account).

- These options can be seen on this screen:

- 

-7. Click **Next**.

-8. On the **Ready to configure** page, leave the **Start the synchronization process as soon as the configuration completes** checked. The server is now in [staging mode](how-to-connect-sync-staging-server.md) so changes are not exported to Azure AD.

-9. Click **Install**.

-10. After the installation has completed, sign out and sign in again to Windows before you use Synchronization Service Manager, Synchronization Rule Editor, or try to make any other configuration changes.

-> Synchronization between Windows Server Active Directory and Azure Active Directory begins, but no changes are exported to Azure AD. Only one synchronization tool can be actively exporting changes at a time. This state is called [staging mode](how-to-connect-sync-staging-server.md).

-### Verify that Azure AD Connect is ready to begin synchronization

-To verify that Azure AD Connect is ready to take over from DirSync, you need to open **Synchronization Service Manager** in the group **Azure AD Connect** from the start menu.

-In the application, go to the **Operations** tab. On this tab, confirm that the following operations have completed:

-* Import on the AD Connector

-* Import on the Azure AD Connector

-* Full Sync on the AD Connector

-* Full Sync on the Azure AD Connector

-

-Review the result from these operations and ensure there are no errors.

-If you want to see and inspect the changes that are about to be exported to Azure AD, then read how to verify the configuration under [staging mode](how-to-connect-sync-staging-server.md). Make required configuration changes until you do not see anything unexpected.

-You are ready to switch from DirSync to Azure AD when you have completed these steps and are happy with the result.

-* In **Programs and features** find **Windows Azure Active Directory sync tool**

-* Uninstall **Windows Azure Active Directory sync tool**

-* The uninstallation might take up to 15 minutes to complete.

-If you prefer to uninstall DirSync later, you can also temporarily shut down the server or disable the service. If something goes wrong, this method allows you to re-enable it. However, it is not expected that the next step will fail so this should not be needed.

-With DirSync uninstalled or disabled, there is no active server exporting to Azure AD. The next step to enable Azure AD Connect must be completed before any changes in your on-premises Active Directory will continue to be synchronized to Azure AD.

-### Enable Azure AD Connect (new server)

-After installation, reopening Azure AD connect will allow you to make additional configuration changes. Start **Azure AD Connect** from the start menu or from the shortcut on the desktop. Make sure you do not try to run the installation MSI again.

-You should see the following:

-

-* Select **Configure staging mode**.

-* Turn off staging by unchecking the **Enabled staging mode** checkbox.

-

-* Click the **Next** button

-* On the confirmation page, click the **install** button.

-Azure AD Connect is now your active server and you must not switch back to using your existing DirSync server.

-## Next steps

-Now that you have Azure AD Connect installed you can [verify the installation and assign licenses](how-to-connect-post-installation.md).

-Learn more about these new features, which were enabled with the installation: [Automatic upgrade](how-to-connect-install-automatic-upgrade.md), [Prevent accidental deletes](how-to-connect-sync-feature-prevent-accidental-deletes.md), and [Azure AD Connect Health](how-to-connect-health-sync.md).

-Learn more about these common topics: [scheduler and how to trigger sync](how-to-connect-sync-feature-scheduler.md).

-Learn more about [Integrating your on-premises identities with Azure Active Directory](whatis-hybrid-identity.md).

- Remove-AzureADServicePrincipal $ObjectId 'd4142c52-179b-4d31-b5b9-08940873507b'

-# What is Azure Active Directory recommendations?

-Keeping track of all the settings and resources in your tenant can be overwhelming. The Azure Active Directory (Azure AD) recommendations feature helps monitor the status of your tenant so you don't have to. Azure AD recommendations helps ensure your tenant is in a secure and healthy state while also helping you maximize the value of the features available in Azure AD.

-This article gives you an overview of how you can use Azure AD recommendations. As an administrator, you should review your tenant's recommendations, and their associated resources periodically.

-Azure AD recommendations is the Azure AD specific implementation of [Azure Advisor](../../advisor/advisor-overview.md), which is a personalized cloud consultant that helps you follow best practices to optimize your Azure deployments. Azure Advisor analyzes your resource configuration and usage data to recommend solutions that can help you improve the cost effectiveness, performance, reliability, and security of your Azure resources.

-*Azure AD recommendations* uses similar data to support you with the roll-out and management of Microsoft's best practices for Azure AD tenants to keep your tenant in a secure and healthy state. Azure AD recommendations provide a holistic view into your tenant's security, health, and usage.

-On a daily basis, Azure AD analyzes the configuration of your tenant. During this analysis, Azure AD compares the data of a recommendation with the actual configuration of your tenant. If a recommendation is flagged as applicable to your tenant, the recommendation appears in the **Recommendations** section of the Azure AD Overview area. Recommendations are listed in order of priority so you can quickly determine where to focus first.

-Recommendations contain a description, a summary of the value of addressing the recommendation, and a step-by-step action plan. If applicable, impacted resources associated with the recommendation are listed, so you can resolve each affected area. If a recommendation doesn't have any associated resources, the impacted resource type is *Tenant level*. so your step-by-step action plan impacts the entire tenant and not just a specific resource.

-The **Impacted resources** for a recommendation could be things like applications or users. This detail gives you an idea of what type of resources you'll need to address. The impacted resource could also be at the tenant level, so you may need to make a global change.

-Azure AD recommendations is automatically enabled. If you'd like to disable this feature, go to **Azure AD** > **Preview features**. Locate the **Recommendations** feature, and change the **State**.

-### Recommendations available for Workload Identities premium licenses

-The recommendations listed in the following table are available to Azure AD tenants with a Workload Identities premium license.

-| Recommendation | Impacted resources | Availability |

-|- |- |- |

-| Remove unused applications | Applications | Preview |

-| Remove unused credentials from applications | Applications | Preview |

-| Renew expiring application credentials | Applications | Preview |

-| Renew expiring service principal credentials | Applications | Preview |

-1. If applicable, right-click on a resource in a recommendation, select **Mark as**, then select a status.

-1. If you need to manually change the status of a recommendation, select **Mark as** from the top of the page and select a status.

-* AWS Single-Account Access provisioning integration can be used only to connect to AWS public cloud endpoints. AWS Single-Account Access provisioning integration can't be used to access AWS Government environments, or the AWS China regions.

- uses: Azure/login@v1.1

- "appId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",

- "displayName": "azure-cli-xxxx-xx-xx-xx-xx-xx",

- "name": "http://azure-cli-xxxx-xx-xx-xx-xx-xx",

- "password": "xXxXxXxXx",

- "tenant": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

- uses: Azure/login@v1.1

- uses: Azure/cli@v1.0.0

- uses: Azure/login@v1.1

-Suppose you want to resize an existing node pool, called `nodepool1`, from SKU size Standard_DS2_v2 to Standard_DS3_v2. To accomplish this task, you'll need to create a new node pool using Standard_DS3_v2, move workloads from `nodepool1` to the new node pool, and remove `nodepool1`. In this example, we'll call this new node pool `mynodepool`.

-[use-multiple-node-pools]: use-multiple-node-pools.md

-> Alias minor version requires Azure CLI version 2.37 or above. Use `az upgrade` to install the latest version of the CLI.

-|<a id="ref-imessagebody"></a>`IMessageBody`|`As<T>(bool preserveContent = false): Where T: string, byte[], JObject, JToken, JArray, XNode, XElement, XDocument` <br /><br /> - The `context.Request.Body.As<T>` and `context.Response.Body.As<T>` methods read a request or response message body in specified type `T`. <br/><br/> - Or - <br/><br/>`AsFormUrlEncodedContent(bool preserveContent = false)` <br/></br>- The `context.Request.Body.AsFormUrlEncodedContent()` and `context.Response.Body.AsFormUrlEncodedContent()` methods read URL-encoded form data in a request or response message body and return an `IDictionary<string, IList<string>>` object. The decoded object supports `IDictionary` operations and the following expressions: `ToQueryString()`, `JsonConvert.SerializeObject()`, `ToFormUrlEncodedContent().` <br/><br/> By default, the `As<T>` and `AsFormUrlEncodedContent()` methods:<br /><ul><li>Use the original message body stream.</li><li>Render it unavailable after it returns.</li></ul> <br />To avoid that and have the method operate on a copy of the body stream, set the `preserveContent` parameter to `true`, as shown in examples for the [set-body](set-body-policy.md#examples) policy.|

-By default, App Service assumes your custom container is listening on either port 80 or port 8080. If your container listens to a different port, set the `WEBSITES_PORT` app setting in your App Service app. You can set it via the [Cloud Shell](https://shell.azure.com). In Bash:

-| France South | | | ✅ |

-| Norway West | | | ✅ |

-| South Africa West | | | ✅ |

-| Switzerland West | | | ✅ |

- b. Check whether there's any UDR configured. If there is, search for the resource on the search bar or under **All resources**.

- c. Check whether there are any default routes (0.0.0.0/0) with the next hop not set as **Internet**. If the setting is either **Virtual Appliance** or **Virtual Network Gateway**, you must make sure that your virtual appliance, or the on-premises device, can properly route the packet back to the internet destination without modifying the packet.

-See how data, including customer information, vendor details, and line items, is extracted from invoices. You'll need the following resources:

-1. Select **Run analysis**. The Form Recognizer Sample Labeling tool will call the Analyze Prebuilt API and analyze the document.

-| &bullet; English | United States (us), Australia (-au), Canada (-ca), Great Britain (-gb), India (-in)|

-| &bullet; Spanish |Spain (es)|

-| &bullet; German | Germany (de)|

-| &bullet; French | France (fr) |

-| &bullet; Italian | Italy (it)|

-| &bullet; Portuguese | Portugal (-pt), Brazil (-br)|

-| &bullet; Dutch | Netherlands (de)|

-| SubTotal | Number | Subtotal field identified on this invoice | Integer |

-| CurrencyCode | String | The Currency Code associated with an extracted amount | |

-Keys can also exist in isolation when the model detects that a key exists, with no associated value or when processing optional fields. For example, a middle name field may be left blank on a form in some instances. key-value pairs are always spans of text contained in the document. For documents where the same value is described in different ways, for example, customer/user, the associated key will be either customer or user (based on context).

-The Invoice service will extract the text, tables, and 26 invoice fields. Following are the fields extracted from an invoice in the JSON output response (the following output uses this [sample invoice](media/sample-invoice.jpg)).

-| SubTotal | number | Subtotal field identified on this invoice | $100.00 | 100 |

-* `"documentResults"` node contains the invoice-specific values and line items that the model discovered. It's where you'll find all the fields from the invoice such as invoice ID, ship to, bill to, customer, total, line items and lots more.

-See how data, including time and date of transactions, merchant information, and amount totals, is extracted from receipts. You'll need the following resources:

-1. Select **Run analysis**. The Form Recognizer Sample Labeling tool will call the Analyze Prebuilt API and analyze the document.

-|&bullet; Dutch| Netherlands (nl)|

-|&bullet; French | France (fr) |

-|&bullet; Japanese | Japan (ja)|

-|&bullet; Portuguese| Portugal (-pt), Brazil (-br)|

-|&bullet; Spanish | Spain (es) |

-Receipt supports all English receipts and the following locales:

-|English (India|`en-in`|

-|French | `fr` |

-| Spanish | `es` |

- * English - United Arab Emirates (en-AE)

- * Dutch - Netherlands (nl-NL)

- * French - Canada (fr-CA)

- * Japanese - Japan (ja-JP)

- * Portuguese - Brazil (pt-BR)

-Automated backups can be enabled by including the `--storage-class-backups` argument when creating an Azure Arc-enabled PostgreSQL server. Restore is not supported in the current preview release.

-|**Role-based access control (RBAC)**|Use Kubernetes RBAC on Kubernetes API. Use SQL and Postgres RBAC for database instances.|You can use Azure Active Directory and Azure RBAC. **Pending availability in directly connected mode**|

-## Backup and restore

-Enable automated backups. Include the `--storage-class-backups` argument when you create an Azure Arc-enabled PostgreSQL server. Restore has been temporarily removed as we finalize designs and experiences.

-> * OCP 4.11 is not supported.

-The list of supported versions evolves over time as we progress on ensuring parity with Postgres managed services in Azure PaaS. Today, the major versions that is supported is PostgreSQL 14.

-It is recommend you look at what versions your applications have been designed for and what are the capabilities of each of the versions.

-At creation time, you have the possibility to indicate what version to create by passing the _--engine-version_ parameter.

-If you do not indicate a version information, by default, a server group of PostgreSQL version 14 will be created.

-Note that there is only one PostgreSQL Custom Resource Definition (CRD) in your Kubernetes cluster no matter what versions we support.

-It will return an output like:

-In this example, this output indicates there are one CRD related to PostgreSQL: postgresqls.arcdata.microsoft.com, shortname postgresqls. The CRD is not a PostgreSQL server. The presence of a CRD is not an indication that you have - or not - created a server. The CRD is an indication of what kind of resources can be created in the Kubernetes cluster.

-Come back and read this article. It will be updated as appropriate.

-> [!IMPORTANT]

-> While you may bring to your server an extension other than those listed above, in this Preview, it will not be persisted to your system. It means that it will not be available after a restart of the system and you would need to bring it again.

-## Create extensions

-Connect to your server with the client tool of your choice and run the standard PostgreSQL query:

-CREATE EXTENSION <extension name>;

-## Show the list of extensions created

-Connect to your server with the client tool of your choice and run the standard PostgreSQL query:

-```console

-select * from pg_extension;

-## Drop an extension

-drop extension <extension name>;

-| PowerStore T|1.23.5|1.9.0_2022-07-12|16.0.312.4243 |postgres 12.3 (Ubuntu 12.3-1)|

-|HPE Superdome Flex 280|1.20.0|1.8.0_2022-06-14|16.0.41.7339|12.3 (Ubuntu 12.3-1)

-| TKGm v1.5.3 | 1.22.8 | 1.9.0_2022-07-12 | 16.0.312.4243 | postgres 12.3 (Ubuntu 12.3-1)|

-## Compare Postgres solutions provided by Microsoft in Azure

-Microsoft offers Postgres database services in Azure in two ways:

-* Learn how to [use Azure Policy to enforce GitOps at scale](./use-azure-policy-flux-2.md).

- + The Azure [Az PowerShell module](/powershell/azure/install-az-ps) version 5.9.0 or later.

-+ The [.NET Core 3.1 SDK](https://dotnet.microsoft.com/download)

-+ Run `(Get-Module -ListAvailable Az).Version` and verify version 5.0 or later.

-| Durable Functions | [Supported](durable/durable-functions-overview.md) | [Supported](durable/durable-functions-dotnet-isolated-overview.md) |

-| Model types exposed by bindings | Simple types<br/>[JSON serializable](/dotnet/api/system.text.json.jsonserializeroptions) types<br/>Arrays/enumerations<br/>Service SDK types such as [BlobClient](/dotnet/api/azure.storage.blobs.blobclient)<br/>`IAsyncCollector` (for output bindings) | Simple types<br/>JSON serializable types<br/>Arrays/enumerations |

-Because .NET isolated projects run in a separate worker process, bindings can't take advantage of rich binding classes, such as `ICollector<T>`, `IAsyncCollector<T>`, and `CloudBlockBlob`. There's also no direct support for types inherited from underlying service SDKs, such as [DocumentClient] and [BrokeredMessage]. Instead, bindings rely on strings, arrays, and serializable types, such as plain old class objects (POCOs).

-The usage of the Blob input binding depends on the extension package version, and the C# modality used in your function app, which can be one of the following:

-The usage of the Blob output binding depends on the extension package version, and the C# modality used in your function app, which can be one of the following:

-| | Blob Storage (standard) | Blob Storage (event-based) | Queue Storage | Event Grid |

-The usage of the Blob trigger depends on the extension package version, and the C# modality used in your function app, which can be one of the following:

-> To do this, remove the `extensionBundles` section of your `host.json` as described [here](./functions-run-local.md#install-extensions) and run `func extensions install --package Microsoft.Azure.WebJobs.Extensions.DurableTask --version 2.9.1` on your terminal. This will install the Durable Functions extension for your app and will allow you to try out the new experience.

-+ [Get started command prompt](./create-first-function-cli-python.md)

-This article explains how to work with the warmup trigger in Azure Functions. A warmup trigger is invoked when an instance is added to scale a running function app. The warmup trigger lets you define a function that's run when a new instance of your function app is started. You can use a warmup trigger to pre-load custom dependencies during the pre-warming process so your functions are ready to start processing requests immediately. Some actions for a warmup trigger might include opening connections, loading dependencies, or running any other custom logic before your app begins receiving traffic. To learn more, see [pre-warmed instances](./functions-premium-plan.md#pre-warmed-instances).

- | **Version** | 3.1 | This tutorial uses .NET Core 3.1 |

- | **Version** | .NET Core 3.1 | The runtime version. |

-* [PowerShell 7](/powershell/scripting/install/installing-powershell-core-on-windows) recommended. For version information, see [PowerShell versions](functions-reference-powershell.md#powershell-versions).

-* Both [.NET Core 3.1 runtime](https://dotnet.microsoft.com/download) and [.NET Core 2.1 runtime](https://dotnet.microsoft.com/download/dotnet/2.1).

-+ The [.NET Core 3.1 SDK](https://dotnet.microsoft.com/download)

-+ The [Azure Functions Core Tools](functions-run-local.md#v2) version 3.x.

-**[Install extensions](#install-extensions)**: To manually install extensions by using Core Tools, you must have the [.NET Core 3.1 SDK](https://dotnet.microsoft.com/download) installed. The .NET Core SDK is used by Core Tools to install extensions from NuGet. You don't need to know .NET to use Azure Functions extensions.

-Choose a version tab below to learn about each specific version and for detailed installation instructions:

-Supports [version 3.x](functions-versions.md) of the Azure Functions runtime. This version supports Windows, macOS, and Linux, and uses platform-specific package managers or npm for installation.

-Supports [version 2.x](functions-versions.md) of the Azure Functions runtime. This version supports Windows, macOS, and Linux, and uses platform-specific package managers or npm for installation.

-You can only install one version of Core Tools on a given computer. Unless otherwise noted, the examples in this article are for version 3.x.

-When changing to a different version of Core Tools, you should use the same package manager as the original installation to move to a different package version. For example, if you installed Core Tools version 2.x using npm, you should use the following command to upgrade to version 3.x:

-npm install -g azure-functions-core-tools@3 --unsafe-perm true

-This example creates a Functions project in a new `MyFunctionProj` folder. You are prompted to choose a default language for your project.

-Certain languages may have additional considerations:

-+ Use the `--csx` parameter if you want to work locally with C# script (.csx) files. These are the same files you get when you create functions in the Azure portal and when using version 1.x of Core Tools. To learn more, see the [func init reference](functions-core-tools-reference.md#func-init).

-There are no additional considerations for PowerShell.

-Starting with runtime version 2.x, [Functions triggers and bindings](functions-triggers-bindings.md) are implemented as .NET extension (NuGet) packages. For compiled C# projects, you simply reference the NuGet extension packages for the specific triggers and bindings you are using. HTTP bindings and timer triggers don't require extensions.

-To improve the development experience for non-C# projects, Functions lets you reference a versioned extension bundle in your host.json project file. [Extension bundles](functions-bindings-register.md#extension-bundles) makes all extensions available to your app and removes the chance of having package compatibility issues between extensions. Extension bundles also removes the requirement of installing the .NET Core 3.1 SDK and having to deal with the extensions.csproj file.

-Extension bundles is the recommended approach for functions projects other than C# complied projects, as well as C# script. For these projects, the extension bundle setting is generated in the _host.json_ file during initialization. If bundles aren't enabled, you need to update the project's host.json file.

-By default, these settings are not migrated automatically when the project is published to Azure. Use the [`--publish-local-settings` option][func azure functionapp publish] when you publish to make sure these settings are added to the function app in Azure. Values in the `ConnectionStrings` section are never published.

-The function app settings values can also be read in your code as environment variables. For more information, see the Environment variables section of these language-specific reference topics:

-In version 3.x/2.x, when you run `func new` you are prompted to choose a template in the default language of your function app. Next, you're prompted to choose a name for your function. In version 1.x, you are also required to choose the language.

-> When you create a function app in the Azure portal, it uses version 3.x of the Function runtime by default. To make the function app use version 1.x of the runtime, follow the instructions in [Run on version 1.x](functions-versions.md#creating-1x-apps).

-If your function app uses bindings or NuGet packages that Core Tools does not recognize, you must manually install the specific extension.

-If you are using Visual Studio Code, you can integrate Rosetta with the built-in Terminal. For more information, see [Enable emulation in Visual Studio Code](./functions-develop-vs-code.md#enable-emulation-in-visual-studio-code).

-description: Learn how to develop Azure Functions apps using Python that are highly performant and scale well under load.

-After understanding the workload profile of your function app, the following are configurations that you can use to improve the throughput performance of your functions.

-When you define `async` in front of a function signature, Python marks the function as a coroutine. When calling the coroutine, it can be scheduled as a task into an event loop. When you call `await` in an async function, it registers a continuation into the event loop, which allows the event loop to process the next task during the wait time.

-I/O-bound apps may also benefit from increasing the number of worker processes beyond the number of cores available. Keep in mind that setting the number of workers too high can impact overall performance due to the increased number of required context switches.

-The `FUNCTIONS_WORKER_PROCESS_COUNT` applies to each host that Functions creates when scaling out your application to meet demand.

-For I/O-bound apps, you should see substantial gains by increasing the number of threads working on each invocation. the recommendation is to start with the Python default (the number of cores) + 4 and then tweak based on the throughput values you're seeing.

-> Although these recommendations apply to both HTTP and non-HTTP triggered functions, you might need to adjust other trigger specific configurations for non-HTTP triggered functions to get the expected performance from your function apps. For more information about this, please refer to this [article](functions-best-practices.md).

-For more processing units especially in CPU-bound operation, you might be able to get this by upgrading to premium plan with higher specifications. With higher processing units, you can adjust the number of worker processes count according to the number of cores available and achieve higher degree of parallelism.

-For more information, see [How do I create a bot that uses US Government data center](/azure/bot-service/bot-service-resources-faq-ecosystem#how-do-i-create-a-bot-that-uses-the-us-government-data-center).

-npm install @azure/maps-search

-const { MapsSearchClient } = require("@azure/maps-search");

-const client = new MapsSearchClient(credential, process.env.MAPS_CLIENT_ID);

-You need to pass the subscription key to the `AzureKeyCredential` class provided by the [Azure Maps Search client library for JavaScript/TypeScript][JS-SDK]. For security reasons, it's better to specify the key as an environment variable than to include it in your source code.

-const { MapsSearchClient, AzureKeyCredential } = require("@azure/maps-search");

-const client = new MapsSearchClient(credential);

-const { MapsSearchClient, AzureKeyCredential } = require("@azure/maps-search");

-require("dotenv").config();

-

-async function main() {

- // Authenticate with Azure Map Subscription Key

- const credential = new AzureKeyCredential(process.env.MAPS_SUBSCRIPTION_KEY);

- const client = new MapsSearchClient(credential);

-

- // Setup the fuzzy search query

- const response = await client.fuzzySearch({

- query: "Starbucks",

- coordinates: [47.61010, -122.34255],

- countryCodeFilter: ["US"],

- });

-

- // Log the result

- console.log(`Starbucks search result nearby Seattle:`);

- response.results.forEach((result) => {

- console.log(`\

- * ${result.address.streetNumber} ${result.address.streetName}

- ${result.address.municipality} ${result.address.countryCode} ${result.address.postalCode}

- Coordinate: (${result.position[0].toFixed(4)}, ${result.position[1].toFixed(4)})\

- `);

-}

-

-main().catch((err) => {

- console.error(err);

-});

-```

-In the above code snippet, you create a `MapsSearchClient` object using your Azure credentials. This is done using your Azure Maps subscription key, however you could use the [Azure AD credential](#using-an-azure-ad-credential) discussed in the previous section. You then pass the search query and options to the `fuzzySearch` method. Search for Starbucks (`query: "Starbucks"`) near Seattle (`coordinates: [47.61010, -122.34255], countryFilter: ["US"]`). For more information, see [FuzzySearchRequest][FuzzySearchRequest] in the [Azure Maps Search client library for JavaScript/TypeScript][JS-SDK].

-The method `fuzzySearch` provided by `MapsSearchClient` will forward the request to Azure Maps REST endpoints. When the results are returned, they're written to the console. For more information, see [SearchAddressResult][SearchAddressResult].

-The [searchAddress][searchAddress] method can be used to get the coordinates of an address. Modify the `search.js` from the sample as follows:

-const { MapsSearchClient, AzureKeyCredential } = require("@azure/maps-search");

- const credential = new AzureKeyCredential(process.env.MAPS_SUBSCRIPTION_KEY);

- const client = new MapsSearchClient(credential);

- const response = await client.searchAddress(

- "1912 Pike Pl, Seattle, WA 98101, US"

- console.log(`The coordinate is: ${response.results[0].position}`);}

-The results returned from `client.searchAddress` are ordered by confidence score and in this example only the first result returned with be displayed to the screen.

-Azure Maps Search also provides some batch query methods. These methods will return Long Running Operations (LRO) objects. The requests might not return all the results immediately, so you can wait until completion or query the result periodically. The example below demonstrates how to call batched reverse search method:

- const poller = await client.beginReverseSearchAddressBatch([

- { coordinates: [148.858561, 2.294911] },

- {

- coordinates: [47.61010, -122.34255],

- },

- { coordinates: [47.6155, -122.33817] },

- options: { radiusInMeters: 5000 },

-In this example, three queries are passed into the _batched reverse search_ request. The first query is invalid, see [Handing failed requests](#handing-failed-requests) for an example showing how to handle the invalid query.

-Use the `getResult` method from the poller to check the current result. You check the status using `getOperationState` to see if the poller is still running. If it is, you can keep calling `poll` until the operation is finished:

-```JavaScript

- while (poller.getOperationState().status === "running") {

- const partialResponse = poller.getResult();

- logResponse(partialResponse)

- await poller.poll();

- }

-```

-Alternatively, you can wait until the operation has completed, by using `pollUntilDone()`:

-const response = await poller.pollUntilDone();

-logResponse(response)

-A common scenario for LRO is to resume a previous operation later. Do that by serializing the pollerΓÇÖs state with the `toString` method, and rehydrating the state with a new poller using `resumeReverseSearchAddressBatch`:

- const rehydratedPoller = await client.resumeReverseSearchAddressBatch(

- serializedState

- );

- const response = await rehydratedPoller.pollUntilDone();

- logResponse(response);

-function logResponse(response) {

- console.log(

- `${response.totalSuccessfulRequests}/${response.totalRequests} succeed.`

- );

- response.batchItems.forEach((item, idx) => {

- console.log(`The result for ${idx + 1}th request:`);

- // Check if the request is failed

- if (item.response.error) {

- console.error(item.response.error);

- item.response.results.forEach((result) => {

- console.log(result.address.freeformAddress);

-}

-Handle failed requests by checking for the `error` property in the response batch item. See the `logResponse` function in the completed batch reverse search example below.

-const { MapsSearchClient, AzureKeyCredential } = require("@azure/maps-search");

- const client = new MapsSearchClient(credential);

- const poller = await client.beginReverseSearchAddressBatch([

- { coordinates: [148.858561, 2.294911] },

- coordinates: [47.61010, -122.34255],

- { coordinates: [47.6155, -122.33817] },

- options: { radiusInMeters: 5000 },

- // Get the partial result and keep polling

- while (poller.getOperationState().status === "running") {

- const partialResponse = poller.getResult();

- logResponse(partialResponse);

- await poller.poll();

- }

- // You can simply wait for the operation is done

- // const response = await poller.pollUntilDone();

- // logResponse(response)

- // Resume the poller

- const rehydratedPoller = await client.resumeReverseSearchAddressBatch(

- serializedState

- );

- const response = await rehydratedPoller.pollUntilDone();

- logResponse(response);

-function logResponse(response) {

- console.log(

- `${response.totalSuccessfulRequests}/${response.totalRequests} succeed.`

- );

- response.batchItems.forEach((item, idx) => {

- console.log(`The result for ${idx + 1}th request:`);

- if (item.response.error) {

- console.error(item.response.error);

- item.response.results.forEach((result) => {

- console.log(result.address.freeformAddress);

-main().catch((err) => {

- console.error(err);

-});

-[JS-SDK]: /javascript/api/overview/azure/maps-search-readme?view=azure-node-preview

-[searchAddress]: /javascript/api/@azure/maps-search/mapssearchclient?view=azure-node-preview#@azure-maps-search-mapssearchclient-searchaddress

-[FuzzySearchRequest]: /javascript/api/@azure/maps-search/fuzzysearchrequest?view=azure-node-preview

-[SearchAddressResult]: /javascript/api/@azure/maps-search/searchaddressresult?view=azure-node-preview

- 1. Enter values for the **Alert rule name** and the **Alert rule description**.

- 1. (Optional) In the **Advanced options** section, select **Enable upon creation** for the alert rule to start running as soon as you're done creating it.

-The telemetry is available in the `customEvents` table on the [Application Insights Logs tab](../logs/log-query-overview.md) or [usage experience](usage-overview.md). Events might come from `trackEvent(..)` or the [Click Analytics Auto-collection plug-in](javascript-click-analytics-plugin.md).

- * [React](./javascript-react-plugin.md)

- * [React Native](./javascript-react-native-plugin.md)

- * [Angular](./javascript-angular-plugin.md)

-Your classic resource data will persist and be subject to the retention settings on your classic Application Insights resource. All new data ingested post migration will be subject to the [retention settings](../logs/data-retention-archive.md) of the associated Log Analytics workspace, which also supports [different retention settings by data type](../logs/data-retention-archive.md#set-retention-and-archive-policy-by-table).

-If you query directly from the Log Analytics workspace, you'll only see data that's ingested post migration. To see both your classic Application Insights data and the new data ingested after migration in a unified query experience, use the **Logs** tab from within your migrated Application Insights resource.

-If you don't run the `az extension add` command, you'll see an error message that states `az : ERROR: az monitor: 'app-insights' is not in the 'az monitor' command group. See 'az monitor --help'.`

-### Will there be any gap in data collected during migration?

-### Will my old log queries continue to work?

-Yes, they'll continue to work.

-Yes, they'll continue to work.

-### Will migration affect AppInsights API accessing data?

-No. Migration won't affect existing API access to data. After migration, you can access data directly from a workspace by using a [slightly different schema](#workspace-based-resource-changes).

-### Will there be any impact on Live Metrics or other monitoring experiences?

- - After you select **Disable**, you can go back to the migration UI. If the **Edit continuous export** page prompts you that your settings won't be saved, select **OK**. This prompt doesn't pertain to disabling or enabling continuous export.

-description: Learn how to install and use the Angular plug-in for the Application Insights JavaScript SDK.

-# Angular plug-in for the Application Insights JavaScript SDK

-The Angular plug-in for the Application Insights JavaScript SDK enables:

-> [!WARNING]

-> The Angular plug-in *isn't* ECMAScript 3 (ES3) compatible.

-When we add support for a new Angular version, our npm package becomes incompatible with down-level Angular versions. Continue to use older npm packages until you're ready to upgrade your Angular version.

-## Get started

-Install an npm package:

-```bash

-npm install @microsoft/applicationinsights-angularplugin-js @microsoft/applicationinsights-web --save

-```

-## Basic usage

-Set up an instance of Application Insights in the entry component in your app:

-```js

-import { Component } from '@angular/core';

-import { ApplicationInsights } from '@microsoft/applicationinsights-web';

-import { AngularPlugin } from '@microsoft/applicationinsights-angularplugin-js';

-import { Router } from '@angular/router';

-@Component({

- selector: 'app-root',

- templateUrl: './app.component.html',

- styleUrls: ['./app.component.css']

-})

-export class AppComponent {

- constructor(

- private router: Router

- ){

- var angularPlugin = new AngularPlugin();

- const appInsights = new ApplicationInsights({ config: {

- connectionString: 'YOUR_CONNECTION_STRING_GOES_HERE',

- extensions: [angularPlugin],

- extensionConfig: {

- [angularPlugin.identifier]: { router: this.router }

- }

- } });

- appInsights.loadAppInsights();

- }

-}

-```

-To track uncaught exceptions, set up `ApplicationinsightsAngularpluginErrorService` in `app.module.ts`:

-```js

-import { ApplicationinsightsAngularpluginErrorService } from '@microsoft/applicationinsights-angularplugin-js';

-@NgModule({

- ...

- providers: [

- {

- provide: ErrorHandler,

- useClass: ApplicationinsightsAngularpluginErrorService

- }

- ]

- ...

-})

-export class AppModule { }

-```

-## Enable correlation

-Correlation generates and sends data that enables distributed tracing and powers [Application Map](../app/app-map.md), the [end-to-end transaction view](../app/app-map.md#go-to-details), and other diagnostic tools.

-In JavaScript, correlation is turned off by default to minimize the telemetry we send by default. To enable correlation, see the [JavaScript client-side correlation documentation](./javascript.md#enable-distributed-tracing).

-### Route tracking

-The Angular plug-in automatically tracks route changes and collects other Angular-specific telemetry.

-> [!NOTE]

-> Set `enableAutoRouteTracking` to `false`. If it's set to `true`, when the route changes, duplicate `PageViews` might be sent.

-### PageView

-If a custom `PageView` duration isn't provided, the `PageView` duration defaults to a value of `0`.

-## Next steps

-description: How to install and use the React Native plugin for Application Insights JavaScript SDK.

-# React Native plugin for Application Insights JavaScript SDK

-The React Native plugin for Application Insights JavaScript SDK collects device information, by default this plugin automatically collects:

-## Requirements

-You must be using a version >= 2.0.0 of `@microsoft/applicationinsights-web`. This plugin will only work in react-native apps. It will not work with [apps using the Expo framework](https://docs.expo.io/), therefore it will not work with Create React Native App.

-## Getting started

-Install and link the [react-native-device-info](https://www.npmjs.com/package/react-native-device-info) package. Keep the `react-native-device-info` package up to date to collect the latest device names using your app.

-```zsh

-npm install --save @microsoft/applicationinsights-react-native @microsoft/applicationinsights-web

-npm install --save react-native-device-info

-react-native link react-native-device-info

-```

-## Initializing the plugin

-To use this plugin, you need to construct the plugin and add it as an `extension` to your existing Application Insights instance.

-```typescript

-import { ApplicationInsights } from '@microsoft/applicationinsights-web';

-import { ReactNativePlugin } from '@microsoft/applicationinsights-react-native';

-var RNPlugin = new ReactNativePlugin();

-var appInsights = new ApplicationInsights({

- config: {

- connectionString: 'YOUR_CONNECTION_STRING_GOES_HERE',

- extensions: [RNPlugin]

- }

-});

-appInsights.loadAppInsights();

-```

-## Enable Correlation

-Correlation generates and sends data that enables distributed tracing and powers the [application map](../app/app-map.md), [end-to-end transaction view](../app/app-map.md#go-to-details), and other diagnostic tools.

-In JavaScript correlation is turned off by default in order to minimize the telemetry we send by default. To enable correlation please reference [JavaScript client-side correlation documentation](./javascript.md#enable-distributed-tracing).

-### PageView

-If a custom `PageView` duration is not provided, `PageView` duration defaults to a value of 0.

-## Next steps

-| [React](javascript-react-plugin.md#enable-correlation)|

-| [React Native](javascript-react-native-plugin.md#enable-correlation)|

-| [Angular](javascript-angular-plugin.md#enable-correlation)|

-| [Click Analytics Auto-collection](javascript-click-analytics-plugin.md#enable-correlation)|

-| [React](javascript-react-plugin.md)|

-| [React Native](javascript-react-native-plugin.md)|

-| [Angular](javascript-angular-plugin.md)|

-| [Click Analytics Auto-collection](javascript-click-analytics-plugin.md)|

-*Use the [Click Analytics Auto collection plugin](javascript-click-analytics-plugin.md) via npm to emit these attributes.

-> To understand how to effectively use the Click Analytics plugin, please refer to [this section](javascript-click-analytics-plugin.md#how-to-effectively-use-the-plugin).

->A user who does an intentional action such as clicking a button or typing an input is counted as an active user. For this reason, Engagement metrics require the [Click Analytics plugin for Application Insights](javascript-click-analytics-plugin.md) implemented in the application.

->Since active users must have at least one telemetry event with an actionType, Retention metrics require the [Click Analytics plugin for Application Insights](javascript-click-analytics-plugin.md) implemented in the application.

->Task success metrics require the [Click Analytics plugin for Application Insights](javascript-click-analytics-plugin.md) implemented in the application.

-You can also use the [Click Analytics Auto-collection plug-in](javascript-click-analytics-plugin.md) to collect custom events.

-### Changes in Azure App Services Function and Web Apps (in-guest changes)

-The Logs Ingestion API can send data to the following built-in tables. Other tables may be added to this list as support for them is implemented. Columns extended on top of built-in tables must have the suffix `_CF`. Columns in a custom table don't need this suffix. Column names can consist of alphanumeric characters and the characters `_` and `-`, and they must start with a letter.

-AV36P and AV52 node sizes available in Azure VMware Solution. The new node sizes increase memory and storage options to optimize your workloads. The gains in performance enable you to do more per server, break storage bottlenecks, and lower transaction costs of latency-sensitive workloads. The availability of the new nodes allows for large latency-sensitive services to be hosted efficiently on the Azure VMware Solution infrastructure.

-HCX with public IP is especially useful in cases where On-premises sites are not connected to Azure via Express Route or VPN. HCX service mesh appliances can be configured with public IPs to avoid lower tunnel MTUs due to double encapsulation if a VPN is used for on-premises to cloud connections. For more information, please see [Enable HCX over the internet](./enable-hcx-access-over-internet.md)

-All new Azure VMware Solution private clouds are now deployed with VMware vCenter Server version 7.0 Update 3c and ESXi version 7.0 Update 3c.

-Any existing private clouds will be upgraded to those versions. For more information, please see [VMware ESXi 7.0 Update 3c Release Notes](https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-70u3c-release-notes.html) and [VMware vCenter Server 7.0 Update 3c Release Notes](https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-vcenter-server-70u3c-release-notes.html).

- You'll receive a notification through Azure Service Health that includes the timeline of the upgrade. You can reschedule an upgrade as needed. This notification also provides details on the upgraded component, its effect on workloads, private cloud access, and other Azure services.

-Any existing private clouds in the previously mentioned regions will be upgraded to those versions. For more information, please see [VMware ESXi 7.0 Update 3c Release Notes](https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-70u3c-release-notes.html) and [VMware vCenter Server 7.0 Update 3c Release Notes](https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-vcenter-server-70u3c-release-notes.html). You'll receive a notification through Azure Service Health that includes the timeline of the upgrade. You can reschedule an upgrade as needed. This notification also provides details on the upgraded component, its effect on workloads, private cloud access, and other Azure services.

- We also recommend customers to review the security advisory and apply the fixes for other affected VMware products or workloads.

- If you need any assistance or have questions, please [contact us](https://portal.azure.com/#home).

-VMware has announced a security advisory [VMSA-2021-0028](https://www.vmware.com/security/advisories/VMSA-2021-0028.html), addressing a critical vulnerability in Apache Log4j identified by CVE-2021-44228. Azure VMware Solution is actively monitoring this issue. We are addressing this issue by applying VMware recommended workarounds or patches for AVS managed VMware components as they become available. Please note that you may experience intermittent connectivity to these components when we apply a fix. We strongly recommend that you read the advisory and patch or apply the recommended workarounds for any additional VMware products that you may have deployed in Azure VMware Solution. If you need any assistance or have questions, please [contact us](https://portal.azure.com).

-All new Azure VMware Solution private clouds are now deployed with NSX-T Data Center version [!INCLUDE [nsxt-version](includes/nsxt-version.md)]. NSX-T Data Center version in existing private clouds will be upgraded through September, 2021 to NSX-T Data Center [!INCLUDE [nsxt-version](includes/nsxt-version.md)] release.

-Azure VMware Solution service will do maintenance work through May 23, 2021, to apply important updates to the vCenter Server in your private cloud. You'll receive a notification through Azure Service Health that includes the timeline of the maintenance for your private cloud. During this time, VMware vCenter Server will be unavailable and you won't be able to manage VMs (stop, start, create, or delete). It's recommended that, during this time, you don't plan any other activities like scaling up private cloud, creating new networks, and so on, in your private cloud. There is no impact to workloads running in your private cloud.

-In this how-to, you'll:

- - One or more active stretched network segment

-1. Enter the Azure VMware Solution HCX Cloud Manager URL or IP address that you noted earlier `https://x.x.x.9` and the credentials for a user which holds the CloudAdmin role in your private cloud. Then select **Connect**.

-VMware HCX Connector deploys a subset of virtual appliances (automated) that require multiple IP segments. When you create your network profiles, you use the IP segments you identified during the [planning phase](plan-private-cloud-deployment.md#define-vmware-hcx-network-segments). You'll create four network profiles:

-In this article, you'll learn how to install and activate the VMware HCX Cloud Manager and VMware HCX Connector components.

-In this how-to, you'll:

- :::image type="content" source="media/tutorial-vmware-hcx/deployed-hcx-migration-get-started.png" alt-text="Screenshot showing the Get started button for HCX Workload Mobility.":::

- Once installed, you'll see the HCX Cloud Manager URL and the HCX keys required for the HCX on-premises connector site pairing on the **Migration using HCX** tab.

- :::image type="content" source="media/tutorial-vmware-hcx/deployed-hcx-migration-using-hcx-tab.png" alt-text="Screenshot showing the Migration using HCX tab under Connectivity.":::

-HCX offers various [services](https://docs.vmware.com/en/VMware-HCX/4.5/hcx-user-guide/GUID-32AF32BD-DE0B-4441-95B3-DF6A27733EED.html#GUID-32AF32BD-DE0B-4441-95B3-DF6A27733EED) based on the type of license installed with the system. Advanced delivers basic connectivity and mobility services to enable hybrid interconnect and migration services. HCX Enterprise offers more services than what standard licenses provide, such as Mobility Groups, Replication assisted vMotion (RAV), Mobility Optimized Networking, Network Extension High availability, OS assisted Migration, etc.

-In this step, you'll download the VMware HCX Connector OVA file, and then you'll deploy the VMware HCX Connector to your on-premises vCenter Server.

-

-

-

-After deploying the VMware HCX Connector OVA on-premises and starting the appliance, you're ready to activate it. First, you'll need to get a license key from the Azure VMware Solution portal, and then you'll activate it in VMware HCX Manager. Finally, youΓÇÖll need a key for each on-premises HCX connector deployed.

- >You defined the **admin** user password during the VMware HCX Manager OVA file deployment.

- >You'll experience a delay after restarting before being prompted for the next step.

->- You can cancel the restore job till the data transfer phase. Once it enters VM creation phase, you can't cancel the restore job.

->Cross-region restore jobs can't be canceled.

-The following request body defines a backup policy for Azure VM backups.

-Yes, you can use Azure Bastion for Virtual WAN deployments. However, deploying Azure Bastion within a Virtual WAN hub isn't supported. You can deploy Azure Bastion in a spoke VNet and use the [IP-based connection](connect-ip-address.md) feature to connect to virtual machines deployed across a different VNet via the Virtual WAN hub. If the Azure Virtual WAN hub will be integrated with Azure Firewall as a [Secured Virtual Hub](https://learn.microsoft.com/azure/firewall-manager/secured-virtual-hub), default 0.0.0.0/0 route must not be overwritten.

-Azure Bastion currently doesn't support timezone redirection and isn't timezone configurable.

-The [WebVTT](https://www.w3.org/TR/webvtt1/#introduction) (Web Video Text Tracks) timespan output format is `hh:mm:ss,fff`.

-The transcriptions for all WAV files are contained in a single plain-text file. Each line of the transcription file contains the name of one of the audio files, followed by the corresponding transcription. The file name and transcription are separated by a tab (`\t`).

-```tsv

-| [C#/.NET → v5.2.0](https://www.nuget.org/packages/Azure.AI.TextAnalytics/5.2.0) | [C# documentation](/dotnet/api/azure.ai.textanalytics?view=azure-dotnet-preview&preserve-view=true) | [C# samples](https://github.com/Azure/azure-sdk-for-net/tree/master/sdk/textanalytics/Azure.AI.TextAnalytics/samples) |

-| [Java → v5.2.0](https://mvnrepository.com/artifact/com.azure/azure-ai-textanalytics/5.2.0) | [Java documentation](/java/api/overview/azure/ai-textanalytics-readme?view=azure-java-preview&preserve-view=true) | [Java Samples](https://github.com/Azure/azure-sdk-for-java/tree/main/sdk/textanalytics/azure-ai-textanalytics/src/samples) |

-| [JavaScript → v5.1.0](https://www.npmjs.com/package/@azure/ai-text-analytics/v/5.1.0) | [JavaScript documentation](/javascript/api/overview/azure/ai-text-analytics-readme?view=azure-node-preview&preserve-view=true) | [JavaScript samples](https://github.com/Azure/azure-sdk-for-js/tree/main/sdk/textanalytics/ai-text-analytics/samples/v5) |

-| Advanced call routing | Does start a call and add user operations honor forwarding rules | ✔️ |

-| | Does start a call and add user operations honor simultaneous ringing | ✔️ |

-This article shows how to access an MQ server that's either on premises or in Azure from a workflow in Azure Logic Apps with the MQ connector. You can then create automated workflows that receive and send messages stored in your MQ server. For example, your workflow can browse for a single message in a queue and then run other actions. The MQ connector includes a Microsoft MQ client that communicates with a remote MQ server across a TCP/IP network.

-| **Consumption** | Multi-tenant Azure Logic Apps | Managed connector, which appears in the designer under the **Enterprise** label. This connector provides only actions, not triggers. For more information, review the following documentation: <br><br>- [MQ managed connector reference](/connectors/mq) <br>- [Managed connectors in Azure Logic Apps](managed.md) |

-| **Consumption** | Integration service environment (ISE) | Managed connector, which appears in the designer under the **Enterprise** label. For more information, review the following documentation: <br><br>- [MQ managed connector reference](/connectors/mq) <br>- [Managed connectors in Azure Logic Apps](managed.md) |

-| **Standard** | Single-tenant Azure Logic Apps and App Service Environment v3 (Windows plans only) | Managed connector, which appears in the designer under the **Azure** label, and built-in connector, which appears in the designer under the **Built-in** label and is service provider based. The built-in version differs in the following ways: <br><br>- The built-in version includes actions *and* triggers. <br><br>- The built-in version can connect directly to an MQ server and access Azure virtual networks. You don't need an on-premises data gateway. <br><br>- The built-in version supports Transport Layer Security (TLS) encryption for data in transit, message encoding for both the send and receive operations, and Azure virtual network integration when your logic app uses the Azure Functions Premium plan <br><br>For more information, review the following documentation: <br><br>- [MQ managed connector reference](/connectors/mq) <br>- [MQ built-in connector reference](/azure/logic-apps/connectors/built-in/reference/mq/) <br>- [Built-in connectors in Azure Logic Apps](built-in.md) |

-* The MQ connector doesn't support segmented messages.

-* The MQ connector doesn't use the message's **Format** field and doesn't make any character set conversions. The connector only puts whatever data appears in the message field into a JSON message and sends the message along.

-* If you're using an on-premises MQ server, [install the on-premises data gateway](../logic-apps/logic-apps-gateway-install.md) on a server within your network. For the MQ connector to work, the server with the on-premises data gateway also must have .NET Framework 4.6 installed.

-* The logic app workflow where you want to access your MQ server.

- * If you're using the MQ managed connector, which doesn't provide any triggers, make sure that your workflow already starts with a trigger or that you first add a trigger to your workflow. For example, you can use the [Recurrence trigger](../connectors/connectors-native-recurrence.md).

- * If you're using a trigger from the MQ built-in connector, make sure that you start with a blank workflow.

- * If you're using the on-premises data gateway, your logic app resource must use the same location as your gateway resource in Azure.

-1. On the designer, select **Choose an operation**, if not already selected.

-To check that your workflow returns the results that you expect, run your workflow and then review the outputs from your workflow's run history.

-When your workflow tries connecting to your on-premises MQ server, you might get the following error:

-* If you're using the MQ connector directly in Azure, the MQ server needs to use a certificate that's issued by a trusted [certificate authority](https://www.ssl.com/faqs/what-is-a-certificate-authority/).

- When you try to connect, the MQ server logs an event message that the connection attempt failed because the MQ server chose the incorrect cipher specification. The event message contains the cipher specification that the MQ server chose from the list. In the channel configuration, update the cipher specification to match the cipher specification in the event message.

- >

- username: myregistrye

-## Set up

-1. Log in to the Azure CLI.

-1. Add a reference to the storage volumes to the `template` definition.

- Is any scalar expression

-Returns a numeric expression.

-```

-COUNT can take any scalar expression as input. The below query will produce an equivalent results:

-SELECT COUNT(2)

-* EastUS2

-* WestUS2

-* GermanyWestCentral

-* AustraliaEast

-1. Register an application entity in Azure Active Directory (Azure AD) by following [Register your application with an Azure AD tenant](../storage/common/storage-auth-aad-app.md#register-your-application-with-an-azure-ad-tenant). Make note of these values, which you use to define the linked service:

-1. Register an application entity in Azure Active Directory (Azure AD) by following the steps in [Register your application with an Azure AD tenant](../storage/common/storage-auth-aad-app.md#register-your-application-with-an-azure-ad-tenant). Make note of the following values, which you use to define the linked service:

-1. Register an application entity in Azure Active Directory by following the steps in [Register your application with an Azure AD tenant](../storage/common/storage-auth-aad-app.md#register-your-application-with-an-azure-ad-tenant). Make note of the following values, which you use to define the linked service:

-1. Register an application entity in Azure Active Directory (Azure AD) by following the steps in [Register your application with an Azure AD tenant](../storage/common/storage-auth-aad-app.md#register-your-application-with-an-azure-ad-tenant). Make note of the following values, which you use to define the linked service:

-1. Register an application entity in Azure Active Directory (Azure AD) by following [Register your application with an Azure AD tenant](../storage/common/storage-auth-aad-app.md#register-your-application-with-an-azure-ad-tenant). Make note of the following values, which you use to define the linked service:

-1. Register an application entity in Azure Active Directory (Azure AD) by following [Register your application with an Azure AD tenant](../storage/common/storage-auth-aad-app.md#register-your-application-with-an-azure-ad-tenant). Make note of the following values, which you use to define the linked service:

- # Enter the appropriate subscription and name for the source factory.

-> The generated artifacts already contain pre and post deployment scripts for the triggers so it isn't necessary to add these manually.

-For more information, see [Update your sensors](update-ot-software.md#update-your-sensors).

-|**Cloud-connected sensors** | Cloud-connected sensors remain activated for as long as your Azure subscription with your Defender for IoT plan is active. <br><br>However, you'll also need to apply a new activation file when [updating your sensor software](update-ot-software.md#download-and-apply-a-new-activation-file) from a legacy version to version 22.2.x. |

-|**Cloud-connected sensors** | Cloud-connected sensors remain activated for as long as your Azure subscription with your Defender for IoT plan is active. <br><br>However, you'll also need to apply a new activation file when [updating your sensor software](update-ot-software.md#download-and-apply-a-new-activation-file) from a legacy version to version 22.2.x. |

-## Update threat intelligence packages

-The data package for threat intelligence is provided with each new Defender for IoT version, or if needed between releases. The package contains signatures (including malware signatures), CVEs, and other security content.

-You can manually upload this file in the Azure portal and automatically update it to sensors.

-**To update the threat intelligence data:**

-1. Go to the Defender for IoT **Updates** page.

-1. Download and save the file.

-1. Sign in to the management console.

-1. On the side menu, select **System Settings**.

-1. Select the sensors that should receive the update in the **Sensor Engine Configuration** section.

-1. In the **Select Threat Intelligence Data** section, select the plus sign (**+**).

-1. Upload the package that you downloaded from the Defender for IoT **Updates** page.

-|**Threat Intelligence mode**| Displays whether the Threat Intelligence update mode is manual or automatic. If it's manual that means that you can [push newly released packages directly to sensors](how-to-work-with-threat-intelligence-packages.md) as needed. Otherwise, the new packages will be automatically installed on all OT, cloud-connected sensors. |

-|:::image type="icon" source="medi). |

-|:::image type="icon" source="medi#download-and-apply-a-new-activation-file) |

-|<a name="endpoint"></a> **Download endpoint details** (Public preview) | Available from the **Sites and sensors** toolbar **More actions** menu, for OT sensor versions 22.x only. <br><br>Download the list of endpoints that must be enabled as secure endpoints from OT network sensors. Make sure that HTTPS traffic is enabled over port 443 to the listed endpoints for your sensor to connect to Azure. Outbound allow rules are defined once for all OT sensors onboarded to the same subscription.<br><br>To enable this option, select a sensor with a supported software version, or a site with one or more sensors with supported versions. |

-| **Define OT network sensor settings** (Preview) | Define selected sensor settings for one or more cloud-connected OT network sensors. For more information, see [Define and view OT sensor settings from the Azure portal (Public preview)](configure-sensor-settings-portal.md). <br><br>Other settings are also available directly from the [OT sensor console](how-to-manage-individual-sensors.md), or the [on-premises management console](how-to-manage-sensors-from-the-on-premises-management-console.md).|

-Use Azure Monitor workbooks on an OT network sensor to retrieve forensic data from that sensorΓÇÖs storage. The following types of forensic data is stored locally on OT sensors, for devices detected by that sensor:

-Each type of data has a different retention period and maximum capacity. For more information see [Visualize Microsoft Defender for IoT data with Azure Monitor workbooks](workbooks.md) and [Data retention across Microsoft Defender for IoT](references-data-retention.md).

- - A [remote sensor upgrade from the Azure portal](update-ot-software.md#update-your-sensors) fails

-You onboard the on-premises management console from the Azure portal.

-You may need to download software for your on-premises management console if you're installing Defender for IoT software on your own appliances, or updating software versions.

-**To download on-premises management console software**:

-1. In the Azure portal, go to **Defender for IoT** > **Getting started** > **On-premises management console** or **Updates**.

-1. Select **Download** for your on-premises management console software update. Save your `management-secured-patcher-<version>.tar` file locally. For example:

- :::image type="content" source="media/update-ot-software/on-premises-download.png" alt-text="Screenshot of the Download option for the on-premises management console." lightbox="media/update-ot-software/on-premises-download.png":::

-description: The threat intelligence data package is provided with each new Defender for IoT version, or if needed between releases.

-# Threat intelligence research and packages

-## Overview

-Security teams at Microsoft carry out proprietary ICS threat intelligence and vulnerability research. These teams include MSTIC (Microsoft Threat Intelligence Center), DART (Microsoft Detection and Response Team), DCU (Digital Crimes Unit), and Section 52 (IoT/OT/ICS domain experts that track ICS-specific zero-days, reverse-engineering malware, campaigns, and adversaries)

-The teams provide security detection, analytics, and response to Microsoft's:

-Security teams gain the benefit of:

-This intelligence provides contextual information to enrich Microsoft platform analytics and supports the company's managed services for incident response and breach investigation. Threat intelligence packages contain signatures (including malware signatures), CVEs, and other security content.

-## When are packages delivered

-Threat intelligence packages are provided approximately once a month, or if needed more frequently. Announcements about new packages are available from: https://techcommunity.microsoft.com/t5/azure-defender-for-iot/bd-p/AzureDefenderIoT.

-You can also see the most current package delivered from the **Threat intelligence update** section of the **Updates** page on Defender for IoT in the Azure portal.

-## Update threat intelligence packages to your sensors

-Three options are available for updating threat intelligence packages to your sensors:

-Users with Defender for IoT Security Reader permissions can automatically and manually push packages to sensors.

-### Automatically push threat intelligence updates to sensors

-Threat intelligence packages can be automatically updated to *cloud connected* sensors as they're released by Defender for IoT. Ensure automatic package update by onboarding your cloud connected sensor with the **Automatic Threat Intelligence Updates** option enabled. For more information, see [Onboard a sensor](tutorial-onboarding.md#onboard-and-activate-the-virtual-sensor).

-### Manually push threat intelligence updates to sensors

-Your *cloud connected* sensors can be automatically updated with threat intelligence packages. However, if you would like to take a more conservative approach, you can push packages from Defender for IoT to sensors only when you feel it's required. This gives you the ability to control when a package is installed, without the need to download and then upload it to your sensors.

-**To manually push packages:**

-1. Go to the Microsoft Defender for IoT **Sites and Sensors** page.

-1. Select the ellipsis (...) for a sensor and then select **Push Threat Intelligence update**. The **Threat Intelligence update status** field displays the update progress.

-#### Change the threat intelligence update mode

-You can change the sensor threat intelligence update mode after initial onboarding.

-**To change the update mode:**

-1. Select the ellipsis (...) for a sensor and then select **Edit**.

-1. Enable or disable the **Automatic Threat Intelligence Updates** toggle.

-### Download packages and upload to sensors

-Packages can be downloaded the Azure portal and manually uploaded to individual sensors. If the on-premises management console manages your sensors, you can download threat intelligence packages to the management console and push them to multiple sensors simultaneously.

-This option is available for both *cloud connected* and *locally managed* sensors.

-**To upload to a single sensor:**

-1. In Defender for IoT on the Azure portal, go to the **Get started** > **Updates** tab.

-1. In the **Sensor threat intelligence update** box, select **Download file** to download the latest threat intelligence package.

-1. Sign in to the sensor console, and then select **System settings** > **Threat intelligence**.

-**To upload to multiple sensors simultaneously:**

-1. In Defender for IoT on the Azure portal, go to the **Get started** > **Updates** tab.

-1. In the **Sensor threat intelligence update** box, select **Download file** to download the latest threat intelligence package.

-1. Sign in to the management console and select **System settings**.

-## Review package update status on the sensor

-The package update status and version information are displayed in the sensor **System Settings**, **Threat Intelligence** section.

-## Review package information for cloud connected sensors

-Review the following information about threat intelligence packages for your cloud connected sensors:

-**To review threat intelligence information**:

-1. Go to the Microsoft Defender for IoT **Sites and Sensors** page.

-1. Review the **Threat Intelligence version** installed on each sensor. Version naming is based on the day the package was built by Defender for IoT.

-1. Review the **Threat Intelligence mode** . *Automatic* indicates that newly available packages will be automatically installed on sensors as they're released by Defender for IoT.

- *Manual* indicates that you can push newly available packages directly to sensors as needed.

-1. Review the **Threat Intelligence update status**. The following statuses may be displayed:

- - Failed

- - In Progress

- - Update Available

- - Ok

-If cloud connected threat intelligence updates fail, review connection information in the **Sensor status** and **Last connected UTC** columns in the **Sites and Sensors** page.

- 1. In the **Site** section, select the **Resource name** and enter the **Display name** for your site. Add any tags as needed to help you identify your sensor.

-On the Defender for IoT > **Getting started** page, select the **On-premises management console** or **Updates** tab and locate the software you need.

-If you're updating from a previous version, check the options carefully to ensure that you have the correct update path for your situation.

-On the Defender for IoT > **Getting started** page, select the **Sensor** or **Updates** tab and locate the software you need.

-If you're updating from a previous version, check the options carefully to ensure that you have the correct update path for your situation.

-| **Grant permissions to others**<br>Apply per subscription or site | - | - | - | Γ£ö |

-| **Onboard OT or Enterprise IoT sensors** [*](#enterprise-iot-security) <br>Apply per subscription only | - | Γ£ö | Γ£ö | Γ£ö |

-| **Download OT sensor and on-premises management console software**<br>Apply per subscription only | Γ£ö | Γ£ö | Γ£ö | Γ£ö |

-| **Download sensor endpoint details** <br>Apply per subscription only | Γ£ö | Γ£ö | Γ£ö | Γ£ö |

-| **Download sensor activation files** <br>Apply per subscription only| - | Γ£ö | Γ£ö | Γ£ö |

-| **View values on the Plans and pricing page** [*](#enterprise-iot-security) <br>Apply per subscription only| Γ£ö | Γ£ö | Γ£ö | Γ£ö |

-| **Modify values on the Plans and pricing page** [*](#enterprise-iot-security) <br>Apply per subscription only| - | Γ£ö | Γ£ö | Γ£ö |

-| **View values on the Sites and sensors page** [*](#enterprise-iot-security)<br>Apply per subscription only | Γ£ö | Γ£ö | Γ£ö | Γ£ö|

-| **Modify values on the Sites and sensors page** [*](#enterprise-iot-security)<br>Apply per subscription only | - | Γ£ö | Γ£ö | Γ£ö|

-| **Recover on-premises management console passwords** <br>Apply per subscription only | - | Γ£ö | Γ£ö | Γ£ö |

-| **Download OT threat intelligence packages** <br>Apply per subscription only | Γ£ö | Γ£ö | Γ£ö | Γ£ö |

-| **Push OT threat intelligence updates** <br>Apply per subscription only | - | Γ£ö | Γ£ö | Γ£ö |

-| **Onboard an Enterprise IoT plan from Microsoft 365 Defender** [*](#enterprise-iot-security)<br>Apply per subscription only | - | Γ£ö | - | - |

-| **View Azure alerts** <br>Apply per subscription or site | Γ£ö | Γ£ö |Γ£ö | Γ£ö|

-| **Modify Azure alerts (write access - change status, learn, download PCAP)** <br>Apply per subscription or site| - | Γ£ö |Γ£ö | Γ£ö |

-| **View Azure device inventory** <br>Apply per subscription or site | Γ£ö | Γ£ö |Γ£ö | Γ£ö|

-| **Manage Azure device inventory (write access)** <br>Apply per subscription or site | - | Γ£ö |Γ£ö | Γ£ö |

-| **View Azure workbooks**<br>Apply per subscription or site | Γ£ö | Γ£ö |Γ£ö | Γ£ö |

-| **Manage Azure workbooks (write access)** <br>Apply per subscription or site | - | Γ£ö |Γ£ö | Γ£ö |

-You can purchase preconfigured appliances for your sensors and on-premises management consoles, or install software on your own hardware machines. In either case, you'll need to update software versions to use new features for OT sensors and on-premises management consoles.

-## Legacy version updates vs. recent version updates

-When downloading your update files from the Azure portal, youΓÇÖll see the option to download different files for different types of updates. Update files differ depending on the version youΓÇÖre updating from and updating to.

-Make sure to select the file that matches your upgrade scenario.

-Updates from legacy versions may require a series of software updates: If you still have a sensor version 3.1.1 installed, you'll need to first upgrade to version 10.5.5, and then to a 22.x version. For example:

-## Verify network requirements

- For more information, see [OT sensor cloud connection methods](architecture-connections.md) and [Connect your OT sensors to the cloud](connect-sensors.md).

- For more information, see [Networking requirements](how-to-set-up-your-network.md#networking-requirements) and [Sensor management options from the Azure portal](how-to-manage-sensors-on-the-cloud.md#sensor-management-options-from-the-azure-portal).

-## Update an on-premises management console

-This procedure describes how to update Defender for IoT software on an on-premises management console, and is only relevant if your organization is using an on-premises management console to manage multiple sensors simultaneously.

-In such cases, make sure to update your on-premises management consoles *before* you update software on your sensors. This process takes about 30 minutes.

-> [!IMPORTANT]

-> The software version on your on-premises management console must be equal to that of your most up-to-date sensor version. Each on-premises management console version is backwards compatible to older, supported sensor versions, but cannot connect to newer sensor versions.

->

-**To update on-premises management console software**:

-1. In the Azure portal, go to **Defender for IoT** > **Getting started** > **Updates**.

-1. Scroll down to the **On-premises management console** section, and select **Download** for the software update. Save your `management-secured-patcher-<version>.tar` file locally. For example:

- :::image type="content" source="media/update-ot-software/on-premises-download.png" alt-text="Screenshot of the Download option for the on-premises management console." lightbox="media/update-ot-software/on-premises-download.png":::

- Make sure to select the version for the update you're performing. For more information, see [Legacy version updates vs. recent version updates](#legacy-version-updates-vs-recent-version-updates).

- [!INCLUDE [root-of-trust](includes/root-of-trust.md)]

-1. On your on-premises management console, select **System Settings** > **Version Update**.

-1. In the **Upload File** dialog, select **BROWSE FILE** and then browse to and select the update file you'd downloaded from the Azure portal.

- The update process starts, and may take about 30 minutes. During your upgrade, the system is rebooted twice.

- Sign in when prompted and check the version number listed in the bottom-left corner to confirm that the new version is listed.

-## Update your sensors

-You can update software on your sensors individually, directly from each sensor console, or in bulk from the on-premises management console. Select one of the following tabs for the steps required in each method.

-> [!NOTE]

-> If you are updating from software versions earlier than [22.1.x](whats-new.md#update-to-version-221x), note that [version 22.1.x](release-notes.md#2223) has a large update with more complicated background processes. Expect this update to take more time than earlier updates have required.

->

-### Prerequisites

-If you're using an on-premises management console to manage your sensors, make sure to update your on-premises management console software *before* you update your sensor software.

-For more information, see [Update an on-premises management console](#update-an-on-premises-management-console).

-### Select an update method

-Select one of the following tabs, depending on how you've chosen to update your OT sensor software.

-# [From the Azure portal (Public preview)](#tab/portal)

-> [!TIP]

-> Sending your version update and running the update process are two separate steps, which can be done one right after the other or at different times.

-> For example, you might want to first send the update to your sensor and then an administrator to run the installation during a planned maintenance window.

-**Prerequisites**: A cloud-connected sensor with a software version equal to or higher than [22.2.3](release-notes.md#2223), but not yet the latest version available.

-**To send the software update to your OT sensor**:

-1. In the Azure portal, go to **Defender for IoT** > **Sites and sensors** and identify the sensors that have legacy versions installed.

-1. Select one or more sensors to update, and then select **Update (Preview)** > **Send package**. For a specific sensor, you can also access the **Send package** option from the **...** options menu to the right of the sensor row. For example:

- :::image type="content" source="media/update-ot-software/send-package.png" alt-text="Screenshot of the Send package option." lightbox="media/update-ot-software/send-package.png":::

-1. In the **Send package** pane that appears on the right, check to make sure that you're sending the correct software to the sensor you want to update. For more information, see [Legacy version updates vs. recent version updates](#legacy-version-updates-vs-recent-version-updates).

- To jump to the release notes for the new version, select **Learn more** at the top of the pane.

-**To run your sensor update from the Azure portal**:

-When the **Sensor version** column for your sensors reads :::image type="icon" source="media/update-ot-software/ready-to-update.png" border="false"::: **Ready to update**, you're ready to run your update.

-1. As in the previous step, either select multiple sensors that are ready to update, or select one sensor at a time.

-1. Select either **Update (Preview)** > **Update sensor** from the toolbar, or for an individual sensor, select the **...** options menu > **Update sensor**. For example:

- :::image type="content" source="media/update-ot-software/update-sensor.png" alt-text="Screenshot of the Update sensor option." lightbox="media/update-ot-software/update-sensor.png":::

-# [From an OT sensor UI](#tab/sensor)

-**To update sensor software directly from the sensor UI**:

-1. In the Azure portal, go to **Defender for IoT** > **Getting started** > **Updates**.

-1. From the **Sensors** section, select **Download** for the sensor update, and save your `<legacy/upstream>-sensor-secured-patcher-<version number>.tar` file locally. For example:

- :::image type="content" source="media/how-to-manage-individual-sensors/updates-page.png" alt-text="Screenshot of the Updates page of Defender for IoT." lightbox="media/how-to-manage-individual-sensors/updates-page.png":::

- Make sure you're downloading the correct file for the update you're performing. For more information, see [Legacy version updates vs. recent version updates](#legacy-version-updates-vs-recent-version-updates).

-1. On your sensor console, select **System Settings** > **Sensor management** > **Software Update**.

-1. On the **Software Update** pane on the right, select **Upload file**, and then navigate to and select your downloaded `legacy-sensor-secured-patcher-<Version number>.tar` file. For example:

- :::image type="content" source="media/how-to-manage-individual-sensors/upgrade-pane-v2.png" alt-text="Screenshot of the Software Update pane on the sensor." lightbox="media/how-to-manage-individual-sensors/upgrade-pane-v2.png":::

- The update process starts, and may take about 30 minutes. During your upgrade, the system is rebooted twice.

- Sign in when prompted, and then return to the **System Settings** > **Sensor management** > **Software Update** pane to confirm that the new version is listed. For example:

- :::image type="content" source="media/how-to-manage-individual-sensors/defender-for-iot-version.png" alt-text="Screenshot of the upgrade version that appears after you sign in." lightbox="media/how-to-manage-individual-sensors/defender-for-iot-version.png":::

-# [From an on-premises management console](#tab/onprem)

-This procedure describes how to update several sensors simultaneously from an on-premises management console.

-**Prerequisites**:

-If you're upgrading an on-premises management console and managed sensors, [first update the management console](#update-an-on-premises-management-console), and then update the sensors.

-The sensor update process won't succeed if you don't update the on-premises management console first.

-**To update several sensors**:

-1. On the Azure portal, go to **Defender for IoT** > **Updates**. Under **Sensors**, select **Download** and save the file. For example:

- :::image type="content" source="media/how-to-manage-individual-sensors/updates-page.png" alt-text="Screenshot of the Updates page of Defender for IoT." lightbox="media/how-to-manage-individual-sensors/updates-page.png":::

- Make sure you're downloading the correct file for the update you're performing. For more information, see [Legacy version updates vs. recent version updates](#legacy-version-updates-vs-recent-version-updates).

- [!INCLUDE [root-of-trust](includes/root-of-trust.md)]

-1. On your on-premises management console, select **System Settings**, and identify the sensors that you want to update.

- > If your **Automatic Version Updates** option is red, you have a update conflict. For example, an update conflict might occur if you have multiple sensors marked for automatic updates but the sensors currently have different software versions installed. Select the option to resolve the conflict.

-# [From an OT sensor via CLI](#tab/cli)

-**To update sensor software directly from the sensor via CLI**:

-1. Use SFTP or SCP to copy the update file to the sensor machine.

-> [!NOTE]

-> After upgrading to version 22.1.x or higher, the new upgrade log is accessible by the *cyberx_host* user on the sensor at the following path: `/opt/sensor/logs/legacy-upgrade.log`. To access the update log, sign into the sensor via SSH with the *cyberx_host* user.

->

-> For more information, see [Default privileged on-premises users](roles-on-premises.md#default-privileged-on-premises-users).

-## Download and apply a new activation file

-**Relevant only when updating from a legacy version to version 22.x or higher**

-This procedure is relevant only if you're updating sensors from software versions earlier than 22.1.x. Such updates require a new activation file for each sensor, which you'll use to activate the sensor before you [update the software](#update-your-sensors).

-**To prepare your sensor for update**:

-1. In Defender for IoT on the Azure portal, select **Sites and sensors** on the left.

-1. Select the site where you want to update your sensor, and then browse to the sensor you want to update.

-1. Expand the row for your sensor, select the options **...** menu on the right of the row, and then select **Prepare to update to 22.x**. For example:

- :::image type="content" source="media/how-to-manage-sensors-on-the-cloud/prepare-to-update.png" alt-text="Screenshot of the Prepare to update option." lightbox="media/how-to-manage-sensors-on-the-cloud/prepare-to-update.png":::

-1. <a name="activation-file"></a>In the **Prepare to update sensor to version 22.X** message, select **Let's go**.

- A new row in the grid is added for sensor you're upgrading. In that added row, select to download the activation file.

-1. Verify that the status showing in the new sensor row has switched to **Pending activation**.

-> [!NOTE]

-> The previous sensor is not automatically deleted after your update. After you've updated the sensor software, make sure to [remove the previous sensor from Defender for IoT](#remove-your-previous-sensor).

-**To apply your activation file**:

-If you're upgrading from a legacy version to version 22.x or higher, make sure to apply the new activation file to your sensor.

-1. On your sensor, select **System settings > Sensor management > Subscription & Mode Activation**.

-1. In the **Subscription & Mode Activation** pane that appears on the right, select **Select file**, and then browse to and select the activation file you'd downloaded [earlier](#activation-file).

-1. In Defender for IoT on the Azure portal, monitor your sensor's activation status. When the sensor is fully activated:

- - The sensor's **Overview** page shows an activation status of **Valid**.

- - In the Azure portal, on the **Sites and sensors** page, the sensor is listed as **OT cloud connected** and with the updated sensor version.

-## Remove your previous sensor

-Your previous sensors continue to appear in the **Sites and sensors** page until you delete them. After you've applied your new activation file and updated sensor software, make sure to delete any remaining, previous sensors from Defender for IoT.

-Delete a sensor from the **Sites and sensors** page in the Azure portal. For more information, see [Sensor management options from the Azure portal](how-to-manage-sensors-on-the-cloud.md#sensor-management-options-from-the-azure-portal).

-## Remove private IoT Hubs

-If you've updated from a version earlier than 22.1.x, you may no longer need the private IoT Hubs you'd previously used to connect sensors to Defender for IoT.

-In such cases:

-1. Review your IoT hubs to ensure that it's not being used by other services.

-1. Verify that your sensors are connected successfully.

-1. Delete any private IoT Hubs that are no longer needed. For more information, see the [IoT Hub documentation](../../iot-hub/iot-hub-create-through-portal.md).

-| **OT networks** | **Cloud features**: [Alerts page GA in the Azure portal](#alerts-ga-in-the-azure-portal) <br><br> **Sensor version 22.2.3**: [Configure OT sensor settings from the Azure portal (Public preview)](#configure-ot-sensor-settings-from-the-azure-portal-public-preview) |

-For more information, see [Update your sensors from the Azure portal](update-ot-software.md#update-your-sensors).

-|Mode |Indicates if the signature is active or not, and whether firewall will drop or alert upon matched traffic. The below signature mode can override IDPS mode<br>- **Disabled**: The signature isn't enabled on your firewall.<br>- **Alert**: You'll receive alerts when suspicious traffic is detected.<br>- **Alert and Deny**: You'll receive alerts and suspicious traffic will be blocked. Few signature categories are defined as ΓÇ£Alert OnlyΓÇ¥, therefore by default, traffic matching their signatures won't be blocked even though IDPS mode is set to ΓÇ£Alert and DenyΓÇ¥. Customers may override this by customizing these specific signatures to ΓÇ£Alert and DenyΓÇ¥ mode. <br><br> Note: IDPS alerts are available in the portal via network rule log query.|

-|Description |Structured from the following three parts:<br>- **Category name**: The category name that the signature belongs to as described in [Azure Firewall IDPS signature rule categories](idps-signature-categories.md).<br>- High level description of the signature<br>- **CVE-ID** (optional) in the case where the signature is associated with a specific CVE. The ID is listed here.|

-Web categories lets administrators allow or deny user access to web site categories such as gambling websites, social media websites, and others. Web categories will also be included in Azure Firewall Standard, but it will be more fine-tuned in Azure Firewall Premium. As opposed to the Web categories capability in the Standard SKU that matches the category based on an FQDN, the Premium SKU matches the category according to the entire URL for both HTTP and HTTPS traffic.

- Once you submit a category change report, you'll be given a token in the notifications that indicate that we've received the request for processing. You can check whether the request is in progress, denied, or approved by entering the token in the search bar. Be sure to save your token ID to do so.

-> For Windows 10 and later versions, we recommend enabling one or both of the ECDHE cipher suites for better security. CBC ciphers are enabled to support Windows 8.1, 8, and 7 operating systems. The DHE cipher suites are disabled. Hence connections coming from clients supporting only DHE ciphers will result in SSL Handshake failure. Workaround is to enable TLS 1.0 for the Hosts/Domains where clients connect with DHE ciphers.

-In the HDInsight ID Broker setup, custom apps and clients that connect to the gateway can be updated to acquire the required OAuth token first. Follow the steps in [this document](../../storage/common/storage-auth-aad-app.md) to acquire the token with the following information:

-* OAuth resource uri: `https://hib.azurehdinsight.net`

-* AppId: 7865c1d2-f040-46cc-875f-831a1ef6a28a

-* Permission: (name: Cluster.ReadWrite, id: 8f89faa0-ffef-4007-974d-4989b39ad77d)

-* When an event or message meets the trigger criteria, many triggers immediately try to read any other waiting events or messages that meet the criteria. This behavior means that even when you select a longer polling interval, the trigger fires based on the number of waiting events or messages that qualify for starting workflows. Triggers that follow this behavior include Azure Service Bus and Azure Event Hub.

-When you create or deploy logic apps with the **Logic App (Standard)** resource type, you can use the Workflow Standard hosting plan in all Azure regions. You also have the option to select an existing **App Service Environment v3** resource as your deployment location, but you can only use the App Service plan with this option. If you choose this option, you're charged for the instances used by the App Service plan and for running your logic app workflows. No other charges apply.

-To control who can access your Azure Machine Learning workspace, use Azure Active Directory [Conditional Access](../active-directory/conditional-access/overview.md).

-> [!IMPORTANT]

-> Azure Machine Learning studio cannot be added in cloud apps in Azure AD Conditional Access, as the studio UI is a client application.

-Azure AD Conditional Access can be used to further control or restrict access to the workspace for each authentication workflow. For example, an admin can allow workspace access from managed devices only.

-As an administrator, you can enforce [Azure AD Conditional Access policies](../active-directory/conditional-access/overview.md) for users signing in to the workspace. For example, you

-can require two-factor authentication, or allow sign in only from managed devices. To use Conditional Access for Azure Machine Learning workspaces specifically, [assign the Conditional Access policy](../active-directory/conditional-access/concept-conditional-access-cloud-apps.md) to Machine Learning Cloud app.

-> [!IMPORTANT]

-> Azure Machine Learning studio cannot be added in cloud apps in Azure AD Conditional Access, as the studio UI is a client application.

- # Here we create a unique name with current datetime

- # Here we create a unique name with current datetime

-| `$schema` | string | The YAML schema. If you use the Azure Machine Learning VS Code extension to author the YAML file, including `$schema` at the top of your file enables you to invoke schema and resource completions. | | |

-| `name` | string | **Required.** Name of the data asset. | | |

-| `version` | string | Version of the dataset. If omitted, Azure ML will autogenerate a version. | | |

-| `description` | string | Description of the data asset. | | |

-| `tags` | object | Dictionary of tags for the data asset. | | |

-| `path` | string | Either a local path to the data source file or folder, or the URI of a cloud path to the data source file or folder. Please ensure that the source provided here is compatible with the `type` specified. <br><br> Supported URI types are `azureml`, `https`, `wasbs`, `abfss`, and `adl`. See [Core yaml syntax](reference-yaml-core-syntax.md) for more information on how to use the `azureml://` URI format. | | |

-Examples are available in the [examples GitHub repository](https://github.com/Azure/azureml-examples/tree/main/cli/assets/data). Several are shown below.

-The source JSON schema can be found at https://azuremlschemas.azureedge.net/latest/azureBlob.schema.json.

-| `$schema` | string | The YAML schema. If you use the Azure Machine Learning VS Code extension to author the YAML file, including `$schema` at the top of your file enables you to invoke schema and resource completions. | | |

-| `type` | string | **Required.** The type of datastore. | `azure_blob` | |

-| `name` | string | **Required.** Name of the datastore. | | |

-| `description` | string | Description of the datastore. | | |

-| `tags` | object | Dictionary of tags for the datastore. | | |

-| `account_name` | string | **Required.** Name of the Azure storage account. | | |

-| `container_name` | string | **Required.** Name of the container. | | |

-| `endpoint` | string | Endpoint suffix of the storage service, which is used for creating the storage account endpoint URL by combining the storage account name and `endpoint`. Example storage account URL: `https://<storage-account-name>.blob.core.windows.net`. | | `core.windows.net` |

-| `protocol` | string | Protocol to use to connect to the container. | `https`, `wasbs` | `https` |

-| `credentials` | object | Credential-based authentication credentials for connecting to the Azure storage account. You can provide either an account key or a shared access signature (SAS) token. Credential secrets are stored in the workspace key vault. | | |

-| `credentials.account_key` | string | The account key for accessing the storage account. **One of `credentials.account_key` or `credentials.sas_token` is required if `credentials` is specified.** | | |

-The `az ml datastore` command can be used for managing Azure Machine Learning datastores.

-Examples are available in the [examples GitHub repository](https://github.com/Azure/azureml-examples/tree/main/cli/resources/datastore). Several are shown below.

-The source JSON schema can be found at https://azuremlschemas.azureedge.net/latest/azureDataLakeGen1.schema.json.

-| `$schema` | string | The YAML schema. If you use the Azure Machine Learning VS Code extension to author the YAML file, including `$schema` at the top of your file enables you to invoke schema and resource completions. | | |

-| `type` | string | **Required.** The type of datastore. | `azure_data_lake_gen1` | |

-| `name` | string | **Required.** Name of the datastore. | | |

-| `description` | string | Description of the datastore. | | |

-| `tags` | object | Dictionary of tags for the datastore. | | |

-| `store_name` | string | **Required.** Name of the Azure Data Lake Storage Gen1 account. | | |

-| `credentials` | object | Service principal credentials for connecting to the Azure storage account. Credential secrets are stored in the workspace key vault. | | |

-| `credentials.tenant_id` | string | The tenant ID of the service principal. **Required if `credentials` is specified.** | | |

-| `credentials.client_id` | string | The client ID of the service principal. **Required if `credentials` is specified.** | | |

-| `credentials.client_secret` | string | The client secret of the service principal. **Required if `credentials` is specified.** | | |

-| `credentials.resource_url` | string | The resource URL that determines what operations will be performed on the Azure Data Lake Storage Gen1 account. | | `https://datalake.azure.net/` |

-| `credentials.authority_url` | string | The authority URL used to authenticate the user. | | `https://login.microsoftonline.com` |

-The `az ml datastore` command can be used for managing Azure Machine Learning datastores.

-Examples are available in the [examples GitHub repository](https://github.com/Azure/azureml-examples/tree/main/cli/resources/datastore). Several are shown below.

-| `$schema` | string | The YAML schema. If you use the Azure Machine Learning VS Code extension to author the YAML file, including `$schema` at the top of your file enables you to invoke schema and resource completions. | | |

-| `type` | string | **Required.** The type of datastore. | `azure_data_lake_gen2` | |

-| `name` | string | **Required.** Name of the datastore. | | |

-| `description` | string | Description of the datastore. | | |

-| `tags` | object | Dictionary of tags for the datastore. | | |

-| `account_name` | string | **Required.** Name of the Azure storage account. | | |

-| `filesystem` | string | **Required.** Name of the file system. The parent directory that contains the files and folders. This is equivalent to a container in Azure Blob storage. | | |

-| `endpoint` | string | Endpoint suffix of the storage service, which is used for creating the storage account endpoint URL by combining the storage account name and `endpoint`. Example storage account URL: `https://<storage-account-name>.dfs.core.windows.net`. | | `core.windows.net` |

-| `protocol` | string | Protocol to use to connect to the file system. | `https`, `abfss` | `https` |

-| `credentials.tenant_id` | string | The tenant ID of the service principal. **Required if `credentials` is specified.** | | |

-| `credentials.client_id` | string | The client ID of the service principal. **Required if `credentials` is specified.** | | |

-| `credentials.client_secret` | string | The client secret of the service principal. **Required if `credentials` is specified.** | | |

-| `credentials.resource_url` | string | The resource URL that determines what operations will be performed on the Azure Data Lake Storage Gen2 account. | | `https://storage.azure.com/` |

-| `credentials.authority_url` | string | The authority URL used to authenticate the user. | | `https://login.microsoftonline.com` |

-Examples are available in the [examples GitHub repository](https://github.com/Azure/azureml-examples/tree/main/cli/resources/datastore). Several are shown below.

-Azure AD Conditional Access can be used to further control or restrict access to the workspace for each authentication workflow. For example, an admin can allow workspace access from managed devices only.

-As an administrator, you can enforce [Azure AD Conditional Access policies](../../active-directory/conditional-access/overview.md) for users signing in to the workspace. For example, you

-can require two-factor authentication, or allow sign in only from managed devices. To use Conditional Access for Azure Machine Learning workspaces specifically, [assign the Conditional Access policy](../../active-directory/conditional-access/concept-conditional-access-cloud-apps.md) to Machine Learning Cloud app.

-> [!IMPORTANT]

-> Azure Machine Learning studio cannot be added in cloud apps in Azure AD Conditional Access, as the studio UI is a client application.

-* Email notifications are currently not supported.

-# Introduction to flow logging for network security groups

-## Introduction

-[Network security group](../virtual-network/network-security-groups-overview.md#security-rules) (NSG) flow logs is a feature of Azure Network Watcher that allows you to log information about IP traffic flowing through an NSG. Flow data is sent to Azure Storage accounts from where you can access it as well as export it to any visualization tool, SIEM, or IDS of your choice.

-

-## Why use Flow Logs?

-It is vital to monitor, manage, and know your own network for uncompromised security, compliance, and performance. Knowing your own environment is of paramount importance to protect and optimize it. You often need to know the current state of the network, who is connecting, where they're connecting from, which ports are open to the internet, expected network behavior, irregular network behavior, and sudden rises in traffic.

-Flow logs are the source of truth for all network activity in your cloud environment. Whether you're an upcoming startup trying to optimize resources or large enterprise trying to detect intrusion, Flow logs are your best bet. You can use it for optimizing network flows, monitoring throughput, verifying compliance, detecting intrusions and more.

-**Network Monitoring**: Identify unknown or undesired traffic. Monitor traffic levels and bandwidth consumption. Filter flow logs by IP and port to understand application behavior. Export Flow Logs to analytics and visualization tools of your choice to set up monitoring dashboards.

-**Usage monitoring and optimization:** Identify top talkers in your network. Combine with GeoIP data to identify cross-region traffic. Understand traffic growth for capacity forecasting. Use data to remove overtly restrictive traffic rules.

-**Compliance**: Use flow data to verify network isolation and compliance with enterprise access rules

-**Network forensics & Security analysis**: Analyze network flows from compromised IPs and network interfaces. Export flow logs to any SIEM or IDS tool of your choice.

-## How logging works

-**Key Properties**

-> Retention is available only if you use [General purpose v2 Storage accounts (GPv2)](../storage/common/storage-account-overview.md#types-of-storage-accounts).

-**Core concepts**

- - NSG Deny rules are terminating. The NSG denying the traffic will log it in Flow logs and processing in this case would stop after any NSG denies traffic.

- - NSG Allow rules are non-terminating, which means even if one NSG allows it, processing will continue to the next NSG. The last NSG allowing traffic will log the traffic to Flow logs.

-* **time** - Time when the event was logged

-* **systemId** - Network Security Group system ID.

-* **category** - The category of the event. The category is always **NetworkSecurityGroupFlowEvent**

-* **resourceid** - The resource ID of the NSG

-* **operationName** - Always NetworkSecurityGroupFlowEvents

-* **properties** - A collection of properties of the flow

- * **Version** - Version number of the Flow Log event schema

- * **flows** - A collection of flows. This property has multiple entries for different rules

- * **rule** - Rule for which the flows are listed

- * **flows** - a collection of flows

- * **mac** - The MAC address of the NIC for the VM where the flow was collected

- * **flowTuples** - A string that contains multiple properties for the flow tuple in comma-separated format

- * **Time Stamp** - This value is the time stamp of when the flow occurred in UNIX epoch format

- * **Source IP** - The source IP

- * **Destination IP** - The destination IP

- * **Source Port** - The source port

- * **Destination Port** - The destination Port

- * **Protocol** - The protocol of the flow. Valid values are **T** for TCP and **U** for UDP

- * **Traffic Flow** - The direction of the traffic flow. Valid values are **I** for inbound and **O** for outbound.

- * **Traffic Decision** - Whether traffic was allowed or denied. Valid values are **A** for allowed and **D** for denied.

- * **Flow State - Version 2 Only** - Captures the state of the flow. Possible states are **B**: Begin, when a flow is created. Statistics aren't provided. **C**: Continuing for an ongoing flow. Statistics are provided at 5-minute intervals. **E**: End, when a flow is terminated. Statistics are provided.

- * **Packets - Source to destination - Version 2 Only** The total number of TCP packets sent from source to destination since last update.

- * **Bytes sent - Source to destination - Version 2 Only** The total number of TCP packet bytes sent from source to destination since last update. Packet bytes include the packet header and payload.

- * **Packets - Destination to source - Version 2 Only** The total number of TCP packets sent from destination to source since last update.

- * **Bytes sent - Destination to source - Version 2 Only** The total number of TCP packet bytes sent from destination to source since last update. Packet bytes include packet header and payload.

-**NSG flow logs Version 2 (vs Version 1)**

-Version 2 of the logs introduces the concept of flow state. You can configure which version of flow logs you receive.

-Flow state _B_ is recorded when a flow is initiated. Flow state _C_ and flow state _E_ are states that mark the continuation of a flow and flow termination, respectively. Both _C_ and _E_ states contain traffic bandwidth information.

-The text that follows is an example of a flow log. As you can see, there are multiple records that follow the property list described in the preceding section.

-> Values in the *flowTuples* property are a comma-separated list.

-

-**Version 1 NSG flow log format sample**

-**Version 2 NSG flow log format sample**

-**Log tuple explained**

-

-**Sample bandwidth calculation**

-Flow tuples from a TCP conversation between 185.170.185.105:35370 and 10.2.0.4:23:

-"1493763938,185.170.185.105,10.2.0.4,35370,23,T,I,A,B,,,,"

-"1493695838,185.170.185.105,10.2.0.4,35370,23,T,I,A,C,1021,588096,8005,4610880"

-"1493696138,185.170.185.105,10.2.0.4,35370,23,T,I,A,E,52,29952,47,27072"

-For continuation _C_ and end _E_ flow states, byte and packet counts are aggregate counts from the time of the previous flow tuple record. Referencing the previous example conversation, the total number of packets transferred is 1021+52+8005+47 = 9125. The total number of bytes transferred is 588096+29952+4610880+27072 = 5256000.

-## Enabling NSG Flow Logs

-Use the relevant link from below for guides on enabling flow logs.

-**Azure portal**

-On the Azure portal, navigate to the NSG Flow Logs section in Network Watcher. Then click the name of the NSG. This will bring up the settings pane for the Flow log. Change the parameters you want and hit **Save** to deploy the changes.

-**PS/CLI/REST/ARM**

-To update parameters via command-line tools, use the same command used to enable Flow Logs (from above) but with updated parameters that you want to change.

-## Working with Flow logs

-*Read and Export flow logs*

-While flow logs target NSGs, they are not displayed the same as the other logs. Flow logs are stored only within a storage account and follow the logging path shown in the following example:

-*Visualize flow logs*

-*Disable flow logs*

-When the flow log is disabled, the flow logging for associated NSG is stopped. But the flow log as a resource continues to exist with all its settings and associations. It can be enabled anytime to begin flow logging on the configured NSG. Steps to disable/enable a flow logs can be found in [this how to guide](./network-watcher-nsg-flow-logging-powershell.md).

-*Delete flow logs*

-When the flow log is deleted, not only the flow logging for the associated NSG is stopped but also the flow log resource is deleted with its settings and associations. To begin flow logging again, a new flow log resource must be created for that NSG. A flow log can be deleted using [PowerShell](/powershell/module/az.network/remove-aznetworkwatcherflowlog), [CLI](/cli/azure/network/watcher/flow-log#az-network-watcher-flow-log-delete) or [REST API](/rest/api/network-watcher/flowlogs/delete). The support for deleting flow logs from Azure portal is in pipeline.

-Also, when a NSG is deleted, by default the associated flow log resource is deleted.

-> To move a NSG to a different resource group or subscription, the associated flow logs must be deleted, just disabling the flow logs won't work. After migration of NSG, the flow logs must be recreated to enable flow logging on it.

-## NSG flow logging considerations

-**Storage account considerations**:

-**Flow Logging Costs**: NSG flow logging is billed on the volume of logs produced. High traffic volume can result in large flow log volume and the associated costs. NSG Flow log pricing does not include the underlying costs of storage. Using the retention policy feature with NSG Flow Logging means incurring separate storage costs for extended periods of time. If you want to retain data forever and do not want to apply any retention policy, set retention (days) to 0. For more information, see [Network Watcher Pricing](https://azure.microsoft.com/pricing/details/network-watcher/) and [Azure Storage Pricing](https://azure.microsoft.com/pricing/details/storage/) for additional details.

-**Issues with User-defined Inbound TCP rules**: [Network Security Groups (NSGs)](../virtual-network/network-security-groups-overview.md) are implemented as a [Stateful firewall](https://en.wikipedia.org/wiki/Stateful_firewall?oldformat=true). However, due to current platform limitations, user-defined rules that affect inbound TCP flows are implemented in a stateless fashion. Due to this, flows affected by user-defined inbound rules become non-terminating. Additionally byte and packet counts are not recorded for these flows. Consequently the number of bytes and packets reported in NSG Flow Logs (and Traffic Analytics) could be different from actual numbers. This can be resolved by setting the [FlowTimeoutInMinutes](/powershell/module/az.network/set-azvirtualnetwork) property on the associated virtual networks to a non-null value. Default stateful behavior can be achieved by setting FlowTimeoutInMinutes to 4 minutes. For long running connections, where you do not want flows disconnecting from a service or destination, FlowTimeoutInMinutes can be set to a value upto 30 minutes.

-**Inbound flows logged from internet IPs to VMs without public IPs**: VMs that don't have a public IP address assigned via a public IP address associated with the NIC as an instance-level public IP, or that are part of a basic load balancer back-end pool, use [default SNAT](../load-balancer/load-balancer-outbound-connections.md) and have an IP address assigned by Azure to facilitate outbound connectivity. As a result, you might see flow log entries for flows from internet IP addresses, if the flow is destined to a port in the range of ports assigned for SNAT. While Azure won't allow these flows to the VM, the attempt is logged and appears in Network Watcher's NSG flow log by design. We recommend that unwanted inbound internet traffic be explicitly blocked with NSG.

-**NSG on ExpressRoute gateway subnet** ΓÇô It is not recommended to log flows on ExpressRoute gateway subnet because traffic can bypass the express route gateway (example: [FastPath](../expressroute/about-fastpath.md)). Thus, if an NSG is linked to an ExpressRoute Gateway subnet and NSG flow logs are enabled, then outbound flows to virtual machines may not get captured. Such flows must be captured at the subnet or NIC of the VM.

-**Traffic across private link** - To log traffic while accessing PaaS resources via private link, enable NSG flow logs on a subnet NSG containing the private link. Due to platform limitations, the traffic at all the source VMs only can be captured whereas that at the destination PaaS resource cannot be captured.

-**Issue with Application Gateway V2 Subnet NSG**: Flow logging on the application gateway V2 subnet NSG is [not supported](../application-gateway/application-gateway-faq.yml#are-nsg-flow-logs-supported-on-nsgs-associated-to-application-gateway-v2-subnet) currently. This issue does not affect Application Gateway V1.

-**Incompatible Services**: Due to current platform limitations, a small set of Azure services are not supported by NSG Flow Logs. The current list of incompatible services is

-> App services deployed under the App Service Plan do not support NSG Flow Logs. [Learn more](../app-service/overview-vnet-integration.md#how-regional-virtual-network-integration-works).

-**Enable on critical subnets**: Flow Logs should be enabled on all critical subnets in your subscription as an auditability and security best practice.

-**Enable NSG Flow Logging on all NSGs attached to a resource**: Flow logging in Azure is configured on the NSG resource. A flow will only be associated to one NSG Rule. In scenarios where multiple NSGs are utilized, we recommend enabling NSG flow logs on all NSGs applied at the resource's subnet or network interface to ensure that all traffic is recorded. For more information, see [how traffic is evaluated](../virtual-network/network-security-group-how-it-works.md) in Network Security Groups.

-Few common scenarios:

-1. **Multiple NICs at a VM**: In case multiple NICs are attached to a virtual machine, flow logging must be enabled on all of them

-1. **Having NSG at both NIC and Subnet Level**: In case NSG is configured at the NIC as well as the subnet level, then flow logging must be enabled at both the NSGs since the exact sequence of rule processing by NSGs at NIC and subnet level is platform dependent and varies from case to case. Traffic flows will be logged against the NSG which is processed last. The processing order is changed by the platform state. You have to check both of the flow logs.

-1. **AKS Cluster Subnet**: AKS adds a default NSG at the cluster subnet. As explained in the above point, flow logging must be enabled on this default NSG.

-**Storage provisioning**: Storage should be provisioned in tune with expected Flow Log volume.

-**Naming**: The NSG name must be upto 80 chars and the NSG rule names upto 65 chars. If the names exceed their character limit, it may get truncated while logging.

-## Troubleshooting common issues

-**I could not enable NSG Flow Logs**

-If you received an _AuthorizationFailed_ or a _GatewayAuthenticationFailed_ error, you might have not enabled the Microsoft Insights resource provider on your subscription. [Follow the instructions](./network-watcher-nsg-flow-logging-portal.md#register-insights-provider) to enable the Microsoft Insights provider.

-**I have enabled NSG Flow Logs but do not see data in my storage account**

-NSG Flow Logs may take up to 5 minutes to appear in your storage account (if configured correctly). A PT1H.json will appear which can be accessed [as described here](./network-watcher-nsg-flow-logging-portal.md#download-flow-log).

-Sometimes you will not see logs because your VMs are not active or there are upstream filters at an App Gateway or other devices that are blocking traffic to your NSGs.

-**I want to automate NSG Flow Logs**

-Support for automation via ARM templates is now available for NSG Flow Logs. Read the [feature announcement](https://azure.microsoft.com/updates/arm-template-support-for-nsg-flow-logs/) & the [Quick Start from ARM template document](quickstart-configure-network-security-group-flow-logs-from-arm-template.md) for more information.

-**What does NSG Flow Logs do?**

-Azure network resources can be combined and managed through [Network Security Groups (NSGs)](../virtual-network/network-security-groups-overview.md). NSG Flow Logs enable you to log 5-tuple flow information about all traffic through your NSGs. The raw flow logs are written to an Azure Storage account from where they can be further processed, analyzed, queried, or exported as needed.

-**Does using Flow Logs impact my network latency or performance?**

-Flow logs data is collected outside of the path of your network traffic, and therefore does not affect network throughput or latency. You can create or delete flow logs without any risk of impact to network performance.

-**How do I use NSG Flow Logs with a Storage account behind a firewall?**

-To use a Storage account behind a firewall, you have to provide an exception for Trusted Microsoft Services to access your storage account:

- ☑️ **Enabled from selected virtual networks and IP addresses**

- ☑️ **Add your Client IP Address**

- > [!Note]

- > A client IP Address is provided here by default, verify this IP matches the machine you are using to access Storage Account using `ipconfig`. If the Client IP Address does not match your machine, you may receive Unauthorized when attempting to access the storage account to read NSG Flow Logs.

- ☑️ **Allow Azure service on the trusted services list to access this storage account.**

-You can check the storage logs after a few minutes, you should see an updated TimeStamp or a new JSON file created.

-**How do I use NSG Flow Logs with a Storage account behind a Service Endpoint?**

-NSG Flow Logs are compatible with Service Endpoints without requiring any extra configuration. See the [tutorial on enabling Service Endpoints](../virtual-network/tutorial-restrict-network-access-to-resources.md#enable-a-service-endpoint) in your virtual network.

-**What is the difference between flow logs versions 1 & 2?**

-Flow Logs version 2 introduces the concept of _Flow State_ & stores information about bytes and packets transmitted. [Read more](#log-format)

-NSG Flow Logs are charged per GB of logs collected and come with a free tier of 5 GB/month per subscription. For the current pricing in your region, see the [Network Watcher pricing page](https://azure.microsoft.com/pricing/details/network-watcher/).

-Storage of logs is charged separately, see [Azure Storage Block blob pricing page](https://azure.microsoft.com/pricing/details/storage/blobs/) for relevant prices.