+ "developerMessage" : `The provided code ${req.body.accessCode} does not match the expected code for user.`,

+ "developerMessage": "The provided code 54321 does not match the expected code for user.",

+* Source system - The repository of users that the Azure AD provisions from. Azure AD is the source system for most preintegrated provisioning connectors. However, there are some exceptions for cloud applications such as SAP, Workday, and AWS. For example, see [User provisioning from Workday to AD](../saas-apps/workday-inbound-tutorial.md).

+The actual steps required to enable and configure automatic provisioning vary depending on the application. If the application you wish to automatically provision is listed in the [Azure AD SaaS app gallery](../saas-apps/tutorial-list.md), then you should select the [app-specific integration tutorial](../saas-apps/tutorial-list.md) to configure its preintegrated user provisioning connector.

+1. [Create a request](../manage-apps/v2-howto-app-gallery-listing.md) for a preintegrated user provisioning connector. Our team works with you and the application developer to onboard your application to our platform if it supports SCIM.

+1. Use the [BYOA SCIM](../app-provisioning/use-scim-to-provision-users-and-groups.md) generic user provisioning support for the app. Using SCIM is a requirement for Azure AD to provision users to the app without a preintegrated provisioning connector.

+To implement automatic user provisioning, you need to define the user and group attributes that are needed for the application. There's a preconfigured set of attributes and [attribute-mappings](../app-provisioning/configure-automatic-user-provisioning-portal.md) between Azure AD user objects, and each SaaS applicationΓÇÖs user objects. Not all SaaS apps enable group attributes.

+| User is added to a group assigned to the target system. | User object is provisioned in target system. <br>User can sign-in to target system and perform the desired actions. |

+| User is removed from a group that is assigned to target system. | User object is deprovisioned in the target system.<br>User can't sign-in to target system. |

+| User information updates in Azure AD by any method. | Updated user attributes reflect in the target system after an incremental cycle. |

+| User is out of scope. | User object is disabled or deleted. <br>Note: This behavior is overridden for [Workday provisioning](skip-out-of-scope-deletions.md). |

+Use the [Azure portal](https://portal.azure.com/) to manage automatic user account provisioning and deprovisioning for applications that support it. Follow the steps in [How do I set up automatic provisioning to an application?](../app-provisioning/user-provisioning.md)

+* A new initial cycle triggers a change in attribute mappings or scoping filters.

+* The provisioning process goes into quarantine due to a high error rate and stays in quarantine for more than four weeks then it's automatically disabled.

+Azure AD can provide more insights into your organizationΓÇÖs user provisioning usage and operational health through audit logs and reports. To learn more about user insights, see [Check the status of user provisioning](application-provisioning-when-will-provisioning-finish-specific-user.md).

+* Share a secret with the Microsoft identity platform that proves the app's identity. Using a secret is relevant in the case where the app is a confidential client application. A confidential [client application](developer-glossary.md#client-application) is an application that can hold credentials securely, like a [web client](developer-glossary.md#web-client). A trusted back-end server is required to store the credentials.

+After the app is registered, it's given a unique identifier that it shares with the Microsoft identity platform when it requests tokens. If the app is a confidential client application, it will also share the secret or the public key depending on whether certificates or secrets were used.

+[*Consent*](developer-glossary.md#consent) is the process of a resource owner granting authorization for a client application to access protected resources, under specific permissions, on behalf of the resource owner. The Microsoft identity platform enables:

+In the Microsoft identity platform, an [application object](developer-glossary.md#application-object) describes an application. At deployment time, the Microsoft identity platform uses the application object as a blueprint to create a [service principal](developer-glossary.md#service-principal-object), which represents a concrete instance of an application within a directory or tenant. The service principal defines what the app can actually do in a specific target directory, who can use it, what resources it has access to, and so on. The Microsoft identity platform creates a service principal from an application object through consent.

+> ### Microsoft.Identity.Web.MicrosoftGraph

+> Microsoft Identity Web (in the [Microsoft.Identity.Web.TokenAcquisition](https://www.nuget.org/packages/Microsoft.Identity.Web.TokenAcquisition) package) is the library that's used to request tokens for accessing an API protected by the Microsoft identity platform. This quickstart requests tokens by using the application's own identity instead of delegated permissions. The authentication flow in this case is known as a [client credentials OAuth flow](v2-oauth2-client-creds-grant-flow.md). For more information on how to use MSAL.NET with a client credentials flow, see [this article](https://aka.ms/msal-net-client-credentials). Given the daemon app in this quickstart calls Microsoft Graph, you install tje [Microsoft.Identity.Web.MicrosoftGraph](https://www.nuget.org/packages/Microsoft.Identity.Web.MicrosoftGraph) package, which handles automatically authenticated requests to Microsoft Graph (and references itself Microsoft.Identity.Web.TokenAcquisition)

+> Microsoft.Identity.Web.MicrosoftGraph can be installed by running the following command in the Visual Studio Package Manager Console:

+> dotnet add package Microsoft.Identity.Web.MicrosoftGraph

+> ### Application initialization

+> Add the reference for Microsoft.Identity.Web by adding the following code:

+> using Microsoft.Extensions.Configuration;

+> using Microsoft.Extensions.DependencyInjection;

+> using Microsoft.Graph;

+> using Microsoft.Identity.Abstractions;

+> using Microsoft.Identity.Web;

+> Then, initialize the app with the following:

+> // Get the Token acquirer factory instance. By default it reads an appsettings.json

+> // file if it exists in the same folder as the app (make sure that the

+> // "Copy to Output Directory" property of the appsettings.json file is "Copy if newer").

+> TokenAcquirerFactory tokenAcquirerFactory = TokenAcquirerFactory.GetDefaultInstance();

+>

+> // Configure the application options to be read from the configuration

+> // and add the services you need (Graph, token cache)

+> IServiceCollection services = tokenAcquirerFactory.Services;

+> services.AddMicrosoftGraph();

+> // By default, you get an in-memory token cache.

+> // For more token cache serialization options, see https://aka.ms/msal-net-token-cache-serialization

+>

+> // Resolve the dependency injection.

+> var serviceProvider = tokenAcquirerFactory.Build();

+> ```

+>

+> This code uses the configuration defined in the appsettings.json file:

+>

+> ```json

+> {

+> "AzureAd": {

+> "Instance": "https://login.microsoftonline.com/",

+> "TenantId": "[Enter here the tenantID or domain name for your Azure AD tenant]",

+> "ClientId": "[Enter here the ClientId for your application]",

+> "ClientCredentials": [

+> {

+> "SourceType": "ClientSecret",

+> "ClientSecret": "[Enter here a client secret for your application]"

+> }

+> ]

+> }

+> }

+> | `ClientSecret` | The client secret created for the application in the Azure portal. |

+> | `ClientId` | The application (client) ID for the application registered in the Azure portal. This value can be found on the app's **Overview** page in the Azure portal. |

+> | `Instance` | (Optional) The security token service (STS) could instance endpoint for the app to authenticate. It's usually `https://login.microsoftonline.com/` for the public cloud.|

+> | `TenantId` | Name of the tenant or the tenant ID.|

+> For more information, see the [reference documentation for `ConfidentialClientApplication`](/dotnet/api/microsoft.identity.web.tokenacquirerfactory).

+> ### Calling Microsoft Graph

+> GraphServiceClient graphServiceClient = serviceProvider.GetRequiredService<GraphServiceClient>();

+> var users = await graphServiceClient.Users

+> .Request()

+> .WithAppOnly()

+> .GetAsync();

+| AADSTS501461 | AcceptMappedClaims is only supported for a token audience matching the application GUID or an audience within the tenant's verified domains. Either change the resource identifier, or use an application-specific signing key. |

+| AADSTS50199 | CmsiInterrupt - For security reasons, user confirmation is required for this request. Interrupt is shown for all scheme redirects in mobile browsers. <br />No action required. The user was asked to confirm that this app is the application they intended to sign into. <br />This is a security feature that helps prevent spoofing attacks. This occurs because a system webview has been used to request a token for a native application. <br />To avoid this prompt, the redirect URI should be part of the following safe list: <br />http://<br />https://<br />chrome-extension:// (desktop Chrome browser only) |

+ "endDateTime":"2018-09-13T00:00:00Z",

+ "startDateTime":"2017-09-12T00:00:00Z",

+ "displayName": "Generated by App Service",

+ "endDateTime": "2022-10-19T17:59:59.6521653Z",

+ "hint": "Nsn",

+ "secretText": null,

+ "startDateTime":"2022-10-19T17:59:59.6521653Z"

+[RBAC-CLOUD-APPS-AZUREAD]: http://www.dushyantgill.com/blog/2014/12/10/roles-based-access-control-in-cloud-applications-using-azure-ad/

+# [.NET](#tab/idweb)

+Here's an example of defining the scopes for the web API as part of the configuration in an [*appsettings.json*](https://github.com/Azure-Samples/active-directory-dotnetcore-daemon-v2/blob/master/2-Call-OwnApi/daemon-console/appsettings.json) file. This example is taken from the [.NET Core console daemon](https://github.com/Azure-Samples/active-directory-dotnetcore-daemon-v2) code sample on GitHub.

+```json

+{

+ "AzureAd": {

+ // Same AzureAd section as before.

+ },

+ "MyWebApi": {

+ "BaseUrl": "https://localhost:44372/",

+ "RelativePath": "api/TodoList",

+ "RequestAppToken": true,

+ "Scopes": [ "[Enter here the scopes for your web API]" ]

+ }

+}

+# [.NET (low level)](#tab/dotnet)

+```csharp

+ResourceId = "someAppIDURI";

+var scopes = new [] { ResourceId+"/.default"};

+```

+To acquire a token for the app, use `AcquireTokenForClient` or its equivalent, depending on the platform.

+# [.NET](#tab/idweb)

+With Microsoft.Identity.Web, you don't need to acquire a token. You can use higher level APIs, as you see in [Calling a web API from a daemon application](scenario-daemon-call-api.md). If however you're using an SDK that requires a token, the following code snippet shows how to get this token.

+using Microsoft.Extensions.DependencyInjection;

+using Microsoft.Identity.Abstractions;

+using Microsoft.Identity.Web;

+// In the Program.cs, acquire a token for your downstream API

+var tokenAcquirerFactory = TokenAcquirerFactory.GetDefaultInstance();

+ITokenAcquirer acquirer = tokenAcquirerFactory.GetTokenAcquirer();

+AcquireTokenResult tokenResult = await acquirer.GetTokenForUserAsync(new[] { https://graph.microsoft.com/.default" });

+string accessToken = tokenResult.AccessToken;

+The following code snippet illustrates token acquisition in an MSAL Node confidential client application:

+# [.NET (low level)](#tab/dotnet)

+```csharp

+using Microsoft.Identity.Client;

+// With client credentials flows, the scope is always of the shape "resource/.default" because the

+// application permissions need to be set statically (in the portal or by PowerShell), and then granted by

+// a tenant administrator.

+string[] scopes = new string[] { "https://graph.microsoft.com/.default" };

+AuthenticationResult result = null;

+try

+{

+ result = await app.AcquireTokenForClient(scopes)

+ .ExecuteAsync();

+}

+catch (MsalUiRequiredException ex)

+{

+ // The application doesn't have sufficient permissions.

+ // - Did you declare enough app permissions during app creation?

+ // - Did the tenant admin grant permissions to the application?

+}

+catch (MsalServiceException ex) when (ex.Message.Contains("AADSTS70011"))

+{

+ // Invalid scope. The scope has to be in the form "https://resourceurl/.default"

+ // Mitigation: Change the scope to be as expected.

+}

+```

+### AcquireTokenForClient uses the application token cache

+In MSAL.NET, `AcquireTokenForClient` uses the application token cache. (All the other AcquireToken*XX* methods use the user token cache.)

+Don't call `AcquireTokenSilent` before you call `AcquireTokenForClient`, because `AcquireTokenSilent` uses the *user* token cache. `AcquireTokenForClient` checks the *application* token cache itself and updates it.

+# [.NET](#tab/idweb)

+[Calling a web API](./scenario-daemon-call-api.md?tabs=idweb).

+# [.NET low level](#tab/dotnet)

+Move on to the next article in this scenario,

+[Calling a web API](./scenario-daemon-call-api.md?tabs=dotnet).

+Daemon applications use application permissions rather than delegated permissions. So their supported account type can't be an account in any organizational directory or any personal Microsoft account (for example, Skype, Xbox, Outlook.com). There's no tenant admin to grant consent to a daemon application for a Microsoft personal account. You need to choose *accounts in my organization* or *accounts in any organization*.

+Even if you want to provide a multitenant tool, you should use a tenant ID or domain name, and **not** `common` or `organizations` with this flow, because the service can't reliably infer which tenant should be used.

+# [.NET](#tab/idweb)

+Here's an example of defining the configuration in an [*appsettings.json*](https://github.com/Azure-Samples/active-directory-dotnetcore-daemon-v2/blob/master/1-Call-MSGraph/daemon-console/appsettings.json) file. This example is taken from the [.NET Core console daemon](https://github.com/Azure-Samples/active-directory-dotnetcore-daemon-v2) code sample on GitHub.

+ "AzureAd": {

+ "Instance": "https://login.microsoftonline.com/",

+ "TenantId": "[Enter here the tenantID or domain name for your Azure AD tenant]",

+ "ClientId": "[Enter here the ClientId for your application]",

+ "ClientCredentials": [

+ {

+ "SourceType": "ClientSecret",

+ "ClientSecret": "[Enter here a client secret for your application]"

+ }

+ ]

+ }

+You provide a certificate instead of the client secret, or [workload identity federation](/azure/active-directory/workload-identities/workload-identity-federation.md) credentials.

+# [.NET (low level) ](#tab/dotnet)

+Here's an example of defining the configuration in an [*appsettings.json*](https://github.com/Azure-Samples/active-directory-dotnetcore-daemon-v2/blob/master/1-Call-MSGraph/daemon-console/appsettings.json) file. This example is taken from the [.NET Core console daemon](https://github.com/Azure-Samples/active-directory-dotnetcore-daemon-v2) code sample on GitHub.

+```json

+{

+ "Instance": "https://login.microsoftonline.com/{0}",

+ "Tenant": "[Enter here the tenantID or domain name for your Azure AD tenant]",

+ "ClientId": "[Enter here the ClientId for your application]",

+ "ClientSecret": "[Enter here a client secret for your application]",

+ "CertificateName": "[Or instead of client secret: Enter here the name of a certificate (from the user cert store) as registered with your application]"

+}

+```

+You provide either a `ClientSecret` or a `CertificateName`. These settings are exclusive.

+# [.NET](#tab/idweb)

+Add the [Microsoft.Identity.Web.TokenAcquisition](https://www.nuget.org/packages/Microsoft.Identity.Web.TokenAcquisition) NuGet package to your application.

+Alternatively, if you want to call Microsoft Graph, add the [Microsoft.Identity.Web.MicrosoftGraph](https://www.nuget.org/packages/Microsoft.Identity.Web.MicrosoftGraph) package.

+Your project could be as follows. The *appsettings.json* file needs to be copied to the output directory.

+```xml

+<Project Sdk="Microsoft.NET.Sdk">

+ <PropertyGroup>

+ <OutputType>Exe</OutputType>

+ <TargetFramework>net7.0</TargetFramework>

+ <RootNamespace>daemon_console</RootNamespace>

+ </PropertyGroup>

+ <ItemGroup>

+ <PackageReference Include="Microsoft.Identity.Web.MicrosoftGraph" Version="2.6.1" />

+ </ItemGroup>

+ <ItemGroup>

+ <None Update="appsettings.json">

+ <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>

+ </None>

+ </ItemGroup>

+</Project>

+```

+In the Program.cs file, add a `using` directive in your code to reference Microsoft.Identity.Web.

+using Microsoft.Identity.Abstractions;

+using Microsoft.Identity.Web;

+Install the packages by running `npm install` in the folder where *package.json* file resides. Then, import **msal-node** package:

+# [.NET (low level)](#tab/dotnet)

+Add the [Microsoft.Identity.Client](https://www.nuget.org/packages/Microsoft.Identity.Client) NuGet package to your application, and then add a `using` directive in your code to reference it.

+In MSAL.NET, the confidential client application is represented by the `IConfidentialClientApplication` interface.

+using Microsoft.Identity.Client;

+IConfidentialClientApplication app;

+#### Instantiate the confidential client application with a client secret

+Here's the code to instantiate the confidential client application with a client secret:

+# [.NET](#tab/idweb)

+ class Program

+ static async Task Main(string[] _)

+ {

+ // Get the Token acquirer factory instance. By default it reads an appsettings.json

+ // file if it exists in the same folder as the app (make sure that the

+ // "Copy to Output Directory" property of the appsettings.json file is "Copy if newer").

+ TokenAcquirerFactory tokenAcquirerFactory = TokenAcquirerFactory.GetDefaultInstance();

+ // Configure the application options to be read from the configuration

+ // and add the services you need (Graph, token cache)

+ IServiceCollection services = tokenAcquirerFactory.Services;

+ services.AddMicrosoftGraph();

+ // By default, you get an in-memory token cache.

+ // For more token cache serialization options, see https://aka.ms/msal-net-token-cache-serialization

+ // Resolve the dependency injection.

+ var serviceProvider = tokenAcquirerFactory.Build();

+ // ...

+ }

+The configuration is read from the *appsettings.json*:

+# [.NET (low level)](#tab/dotnet)

+```csharp

+app = ConfidentialClientApplicationBuilder.Create(config.ClientId)

+ .WithClientSecret(config.ClientSecret)

+ .WithAuthority(new Uri(config.Authority))

+ .Build();

+```

+The `Authority` is a concatenation of the cloud instance and the tenant ID, for example `https://login.microsoftonline.com/contoso.onmicrosoft.com` or `https://login.microsoftonline.com/eb1ed152-0000-0000-0000-32401f3f9abd`. In the *appsettings.json* file shown in the [Configuration file](#configuration-file) section, instance and tenant are represented by the `Instance` and `Tenant` values, respectively.

+In the code sample the previous snippet was taken from, `Authority` is a property on the [AuthenticationConfig](https://github.com/Azure-Samples/active-directory-dotnetcore-daemon-v2/blob/ffc4a9f5d9bdba5303e98a1af34232b434075ac7/1-Call-MSGraph/daemon-console/AuthenticationConfig.cs#L61-L70) class, and is defined as such:

+```csharp

+/// <summary>

+/// URL of the authority

+/// </summary>

+public string Authority

+{

+ get

+ {

+ return String.Format(CultureInfo.InvariantCulture, Instance, Tenant);

+ }

+}

+```

+# [.NET](#tab/idweb)

+The code itself is exactly the same. The certificate is described in the configuration.

+There are many ways to get the certificate. For details see https://aka.ms/ms-id-web-certificates.

+Here's how you would do to get your certificate from KeyVault. Microsoft identity delegates to Azure Identity's DefaultAzureCredential, and used Managed identity when available to access the certificate from KeyVault. You can debug your application locally as it, then, uses your developer credentials.

+```json

+ "ClientCredentials": [

+ {

+ "SourceType": "KeyVault",

+ "KeyVaultUrl": "https://yourKeyVaultUrl.vault.azure.net",

+ "KeyVaultCertificateName": "NameOfYourCertificate"

+ }

+X509Certificate2 certificate = ReadCertificate(config.CertificateName);

+ .WithCertificate(certificate)

+ .WithAuthority(new Uri(config.Authority))

+ .Build();

+#### Advanced scenario: Instantiate the confidential client application with client assertions

+# [.NET](#tab/idweb)

+Instead of a client secret or a certificate, the confidential client application can also prove its identity by using client assertions. See

+[CredentialDescription](/dotnet/api/microsoft.identity.abstractions.credentialdescription?view=msal-model-dotnet-latest) for details.

+# [.NET (low level)](#tab/dotnet)

+Instead of a client secret or a certificate, the confidential client application can also prove its identity by using client assertions.

+MSAL.NET has two methods to provide signed assertions to the confidential client app:

+- `.WithClientAssertion()`

+- `.WithClientClaims()`

+When you use `WithClientAssertion`, provide a signed JWT. This advanced scenario is detailed in [Client assertions](msal-net-client-assertions.md).

+```csharp

+string signedClientAssertion = ComputeAssertion();

+app = ConfidentialClientApplicationBuilder.Create(config.ClientId)

+ .WithClientAssertion(signedClientAssertion)

+ .Build();

+```

+When you use `WithClientClaims`, MSAL.NET produces a signed assertion that contains the claims expected by Azure AD, plus additional client claims that you want to send.

+This code shows how to do that:

+```csharp

+string ipAddress = "192.168.1.2";

+var claims = new Dictionary<string, string> { { "client_ip", ipAddress } };

+X509Certificate2 certificate = ReadCertificate(config.CertificateName);

+app = ConfidentialClientApplicationBuilder.Create(config.ClientId)

+ .WithAuthority(new Uri(config.Authority))

+ .WithClientClaims(certificate, claims)

+ .Build();

+```

+Again, for details, see [Client assertions](msal-net-client-assertions.md).

+# [.NET](#tab/idweb)

+[Acquire a token for the app](./scenario-daemon-acquire-token.md?tabs=idweb).

+# [.NET (low level)](#tab/dotnet)

+Move on to the next article in this scenario,

+[Acquire a token for the app](./scenario-daemon-acquire-token.md?tabs=dotnet).

+.NET daemon apps can call a web API. .NET daemon apps can also call several preapproved web APIs.

+# [.NET](#tab/idweb)

+Microsoft.Identity.Web abstracts away the complexity of MSAL.NET. It provides you with higher-level APIs that handle the internals of MSAL.NET for you, such as processing Conditional Access errors, caching.

+Here's the Program.cs of the daemon app calling a downstream API:

+```csharp

+using Microsoft.Extensions.DependencyInjection;

+using Microsoft.Identity.Abstractions;

+using Microsoft.Identity.Web;

+// In the Program.cs, acquire a token for your downstream API

+var tokenAcquirerFactory = TokenAcquirerFactory.GetDefaultInstance();

+tokenAcquirerFactory.Services.AddDownstreamApi("MyApi",

+ tokenAcquirerFactory.Configuration.GetSection("MyWebApi"));

+var sp = tokenAcquirerFactory.Build();

+var api = sp.GetRequiredService<IDownstreamApi>();

+var result = await api.GetForAppAsync<IEnumerable<TodoItem>>("MyApi");

+Console.WriteLine($"result = {result?.Count()}");

+```

+Here's the Program.cs of a daemon app that calls Microsoft Graph:

+```csharp

+var tokenAcquirerFactory = TokenAcquirerFactory.GetDefaultInstance();

+tokenAcquirerFactory.Services.AddMicrosoftGraph();

+var serviceProvider = tokenAcquirerFactory.Build();

+try

+{

+ GraphServiceClient graphServiceClient = serviceProvider.GetRequiredService<GraphServiceClient>();

+ var users = await graphServiceClient.Users

+ .Request()

+ .WithAppOnly()

+ .GetAsync();

+ Console.WriteLine($"{users.Count} users");

+ Console.ReadKey();

+}

+catch (Exception ex) { Console.WriteLine("We could not retrieve the user's list: " + $"{ex}"); }

+```

+# [.NET low level](#tab/dotnet)

+For daemon apps, the web APIs that you call need to be preapproved. There's no incremental consent with daemon apps. (There's no user interaction.) The tenant admin needs to provide consent in advance for the application and all the API permissions. If you want to call several APIs, acquire a token for each resource, each time calling `AcquireTokenForClient`. MSAL uses the application token cache to avoid unnecessary service calls.

+# [.NET](#tab/idweb)

+[Move to production](./scenario-daemon-production.md?tabs=idweb).

+# [.NET low level](#tab/dotnet)

+Move on to the next article in this scenario,

+[Move to production](./scenario-daemon-production.md?tabs=dotnet).

+> [!div renderon="portal" id="display-on-portal" class="sxs-lookup"]

+> 1. In your terminal, locate the folder that contains the `package.json` file, then run the following command:

+> 1. Select the **Sign-in** link on the navigation bar, then follow the prompts.

+# Customer intent: As a tenant administrator, I want to bulk-invite external users to an organization from email addresses that I've stored in a .csv file.

+You can bulk-invite external users to an organization from email addresses that you've stored in a .csv file.

+1. Prepare the .csv file

+ Create a new .csv file and name it invitations.csv. In this example, the file is saved in C:\data, and contains the following information:

+The code sample illustrates how to call the invitation API and get the redemption URL. Use the redemption URL to send a custom invitation email. You can compose the email with an HTTP client, so you can customize how it looks and send it through the Microsoft Graph API.

+- [Samples for guest user self-service sign-up](code-samples-self-service-sign-up.md)

+Some features, for example entitlement management, are available with an Azure AD Premium 2 (P2) license. Microsoft 365 E5 and Office 365 E5 licenses include Azure AD Premium P2 licenses. Learn more in the following entitlement management section.

+> Licenses are for one user. Therefore users, administrators, and business owners can have delegated access control. This scenario can occur with Azure AD Premium P2 or Microsoft 365 E5, and you don't have to enable licenses for all users. The first 50,000 external users are free. If you don't enable P2 licenses for other internal users, they can't use entitlement management.

+## Govern access with Azure AD Premium P2 and Microsoft 365 or Office 365 E5

+Azure AD Premium P2, included in Microsoft 365 E5, has additional security and governance capabilities.

+## Manage access with Azure AD P1, Microsoft 365, Office 365 E3

+ * Ensures there are sufficient Azure AD Premium P2 licenses for the Microsoft 365 group owners who will review

+## Identity Governance and reporting

+Use the following list to learn about identity governance and reporting. Items in the list refer to Microsoft Entra.

+- Do regular reviews of the exception groups used in policies to limit the time users are out of the security posture. If you own Azure AD Premium P2, then you can use access reviews to automate the process

+> These recommendations are current as of the date of publishing but can change over time. Organizations should continuously evaluate their identity practices as Microsoft products and services evolve over time. Recommendations can change when organizations subscribe to a different Azure AD Premium license.

+- Azure Active Directory Premium P2

+|[System-preferred authentication methods](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-march-2023-train/ba-p/2967448)|Feature change|Sometime after GA|

+ Title: Create a lifecycle workflow (preview) - Azure AD

+description: This article guides you in creating a lifecycle workflow.

+# Create a lifecycle workflow (preview)

+Lifecycle workflows (preview) allow for tasks associated with the lifecycle process to be run automatically for users as they move through their lifecycle in your organization. Workflows consist of:

+- **Tasks**: Actions taken when a workflow is triggered.

+- **Execution conditions**: The who and when of a workflow. These conditions define which users (scope) this workflow should run against, and when (trigger) the workflow should run.

+You can create and customize workflows for common scenarios by using templates, or you can build a workflow from scratch without using a template. Currently, if you use the Azure portal, any workflow that you create must be based on a template. If you want to create a workflow without using a template, use Microsoft Graph.

+The preview of lifecycle workflows requires Azure Active Directory (Azure AD) Premium P2. For more information, see [License requirements](what-are-lifecycle-workflows.md#license-requirements).

+## Create a lifecycle workflow by using a template in the Azure portal

+If you're using the Azure portal to create a workflow, you can customize existing templates to meet your organization's needs. These templates include one for pre-hire common scenarios.

+To create a workflow based on a template:

+1. Select **Azure Active Directory** > **Identity Governance**.

+1. On the left menu, select **Lifecycle Workflows (Preview)**.

+1. Select **Workflows (Preview)**.

+1. On the **Choose a workflow** page, select the workflow template that you want to use.

+ :::image type="content" source="media/create-lifecycle-workflow/template-list.png" alt-text="Screenshot of a list of lifecycle workflow templates." lightbox="media/create-lifecycle-workflow/template-list.png":::

+1. On the **Basics** tab, enter a unique display name and description for the workflow, and then select **Next**.

+ :::image type="content" source="media/create-lifecycle-workflow/template-basics.png" alt-text="Screenshot of basic information about a workflow template.":::

+1. On the **Configure scope** tab, select the trigger type and execution conditions to be used for this workflow. For more information on what you can configure, see [Configure scope](understanding-lifecycle-workflows.md#configure-scope).

+1. Under **Rule**, enter values for **Property**, **Operator**, and **Value**. The following screenshot gives an example of a rule being set up for a sales department. For a full list of user properties that lifecycle workflows support, see [Supported user properties and query parameters](/graph/api/resources/identitygovernance-rulebasedsubjectset?view=graph-rest-beta&preserve-view=true#supported-user-properties-and-query-parameters).

+ :::image type="content" source="media/create-lifecycle-workflow/template-scope.png" alt-text="Screenshot of scope configuration options for a lifecycle workflow template.":::

+1. To view your rule syntax, select the **View rule syntax** button. You can copy and paste multiple user property rules on the panel that appears. For more information on which properties you can include, see [User properties](/graph/aad-advanced-queries?tabs=http#user-properties). When you finish adding rules, select **Next**.

+ :::image type="content" source="media/create-lifecycle-workflow/template-syntax.png" alt-text="Screenshot of workflow rule syntax.":::

+1. On the **Review tasks** tab, you can add a task to the template by selecting **Add task**. To enable an existing task on the list, select **Enable**. To disable a task, select **Disable**. To remove a task from the template, select **Remove**.

+ When you're finished with tasks for your workflow, select **Next: Review and create**.

+ :::image type="content" source="media/create-lifecycle-workflow/template-tasks.png" alt-text="Screenshot of adding tasks to templates.":::

+1. On the **Review and create** tab, review the workflow's settings. You can also choose whether or not to enable the schedule for the workflow. Select **Create** to create the workflow.

+ :::image type="content" source="media/create-lifecycle-workflow/template-review.png" alt-text="Screenshot of reviewing and creating a workflow.":::

+> By default, a newly created workflow is disabled to allow for the testing of it first on smaller audiences. For more information about testing workflows before rolling them out to many users, see [Run an on-demand workflow](on-demand-workflow.md).

+## Create a lifecycle workflow by using Microsoft Graph

+To create a lifecycle workflow by using the Microsoft Graph API, see [Create workflow](/graph/api/identitygovernance-lifecycleworkflowscontainer-post-workflows).

+- [Manage workflow versions](manage-workflow-tasks.md)

+ Title: Delete a lifecycle workflow

+description: Learn how to delete a lifecycle workflow.

+# Delete a lifecycle workflow (preview)

+You can remove workflows that you no longer need. Deleting these workflows helps keep your lifecycle strategy up to date.

+When a workflow is deleted, it enters a soft-delete state. During this period, you can still view it in the list of deleted workflows and restore it if needed. A workflow is permanently removed 30 days after it enters a soft-delete state. If you don't want to wait 30 days for a workflow to be permanently deleted, you can manually delete it.

+The preview of lifecycle workflows requires Azure Active Directory (Azure AD) Premium P2. For more information, see [License requirements](what-are-lifecycle-workflows.md#license-requirements).

+## Delete a workflow by using the Azure portal

+1. On the search bar near the top of the page, enter **Identity Governance**. Then select **Identity Governance** in the results.

+1. On the left menu, select **Lifecycle Workflows (Preview)**.

+1. Select **Workflows (Preview)**.

+1. On the **Workflows** page, select the workflow that you want to delete. Then select **Delete**.

+ :::image type="content" source="media/delete-lifecycle-workflow/delete-button.png" alt-text="Screenshot of a list of workflows with one selected, along with the Delete button.":::

+1. Confirm that you want to delete the workflow by selecting the **Delete** button.

+ :::image type="content" source="media/delete-lifecycle-workflow/delete-workflow.png" alt-text="Screenshot of confirming the deletion of a workflow.":::

+## View deleted workflows in the Azure portal

+After you delete workflows, you can view them on the **Deleted workflows** page.

+1. On the left pane, select **Deleted workflows (Preview)**.

+1. On the **Deleted workflows** page, check the list of deleted workflows. Each workflow has a description, the date of deletion, and a permanent delete date. By default, the permanent delete date for a workflow is 30 days after it was originally deleted.

+ :::image type="content" source="media/delete-lifecycle-workflow/deleted-list.png" alt-text="Screenshot of a list of deleted workflows.":::

+1. To restore a deleted workflow, select it and then select **Restore workflow**.

+ To permanently delete a workflow immediately, select it and then select **Delete permanently**.

+## Delete a workflow by using Microsoft Graph

+To delete a workflow by using an API via Microsoft Graph, see [Delete a lifecycle workflow](/graph/api/identitygovernance-workflow-delete?view=graph-rest-beta&preserve-view=true).

+## View deleted workflows by using Microsoft Graph

+To view a list of deleted workflows by using an API via Microsoft Graph, see [List deleted workflows](/graph/api/identitygovernance-lifecycleworkflowscontainer-list-deleteditems).

+## Permanently delete a workflow by using Microsoft Graph

+To permanently delete a workflow by using an API via Microsoft Graph, see [Permanently delete a deleted workflow](/graph/api/identitygovernance-deleteditemcontainer-delete).

+## Restore a deleted workflow by using Microsoft Graph

+To restore a deleted workflow by using an API via Microsoft Graph, see [Restore a deleted workflow](/graph/api/identitygovernance-workflow-restore).

+> You can't restore permanently deleted workflows.

+- [What are lifecycle workflows?](what-are-lifecycle-workflows.md)

+- [Manage lifecycle workflow versions](manage-workflow-tasks.md)

+You can have at most one automatic assignment policy in an access package, and the policy can only be created by an administrator.

+**Prerequisite role:** Global administrator or Identity Governance administrator

+Lifecycle Workflows allow you to create workflows that can be triggered based on joiner, mover, or leaver scenarios. While Lifecycle Workflows provide several built-in tasks to automate common scenarios throughout the lifecycle of users, eventually you may reach the limits of these built-in tasks. With the extensibility feature, you're able to utilize the concept of custom task extensions to call-out to external systems as part of a workflow. For example, when a user joins your organization you can have a workflow with a custom task extension that assigns a Teams number, or have a separate workflow that grants access to an email account for a manager when a user leaves. With the extensibility feature, Lifecycle Workflows currently support creating custom tasks extensions to call-out to [Azure Logic Apps](../../logic-apps/logic-apps-overview.md).

+## Logic Apps prerequisites

+To link a Azure Logic App with a custom task extension, the following prerequisites must be available:

+- An Azure subscription

+- A resource group

+- Permissions to create a new consumption-based Logic App or access to an existing consumption-based Logic App

+One of the following Azure role assignments is required either on the Logic App itself or on a higher scope such as the resource group, subscription or management group:

+> The **Logic App Operator** role is not sufficient.

+- **Launch and wait** - The Azure Logic App is started, and the following task's execution waits on the response from the Logic App. You enter a time duration for how long the custom task extension should wait for a response from the Azure Logic App. If no response is received within the defined duration window, the task is considered failed.

+> The response does not necessarily have to be provided by the Logic App, a third party system is able to respond if the Logic App only acts as an intermediary. To learn more about this, see: [taskProcessingResult: resume](/graph/api/identitygovernance-taskprocessingresult-resume).

+When you create a custom task extension that waits for a response from the Logic App, you're able to define which applications can send a response.

+The response can be authorized in one of the following ways:

+- **System-assigned managed identity (Default)** - With this choice you enable and utilize the Logic Apps system-assigned managed identity. For more information, see: [Authenticate access to Azure resources with managed identities in Azure Logic Apps](/azure/logic-apps/create-managed-service-identity)

+- **No authorization** - With this choice no authorization will be granted, and you separately have to assign an application permission (LifecycleWorkflows.ReadWrite.All), or role assignment (Lifecycle Workflows Administrator). If an application is responding we do not recommend this option, as it is not following the principle of least privilege. This option may also be used if responses are only provided on behalf of a user (LifecycleWorkflows.ReadWrite.All delegated permission AND Lifecycle Workflows Administrator role assignment)

+- **Existing application** - With this choice you're able to choose an existing application to respond. This can be a regular application as well as a system or user-assigned managed identity. For more information on managed identity types, see: [Managed identity types](../managed-identities-azure-resources/overview.md#managed-identity-types).

+> Creating a custom task extension and logic app through the Azure portal will automate most of these steps. For a guide on creating a custom task extension this way, see: [Trigger Logic Apps based on custom task extensions (Preview)](trigger-custom-task.md).

+- **Configure the Azure Logic App so its compatible with Lifecycle workflows**: Configuring the consumption-based Azure Logic App so that it can be used with the custom task extension. For more information, see: [Configure a Logic App for Lifecycle Workflow use (Preview)](configure-logic-app-lifecycle-workflows.md)

+Lifecycle Workflows come with many pre-configured tasks that are designed to automate common lifecycle management scenarios. These built-in tasks can be utilized to make customized workflows to suit your organization's needs. These tasks can be configured within seconds to create new workflows. These tasks also have categories based on the Joiner-Mover-Leaver model so that they can be easily placed into workflows based on need. In this article you get the complete list of tasks, information on common parameters each task has, and a list of unique parameters needed for each specific task.

+|isEnabled | A boolean value that denotes whether the task is set to run or not. If set to ΓÇ£true" then the task runs. Defaults to true. |

+|executionSequence | A read-only integer that states in what order the task runs in a workflow. For more information about executionSequence and workflow order, see: [Configure Scope](understanding-lifecycle-workflows.md#configure-scope). |

+- **Email language translation:** Overrides the email recipient's language settings. Custom text isn't customized, and it's recommended to set this language to the same language as the custom text.

+For Microsoft Graph, the parameters for the **Send welcome email to new hire** task are as follows:

+For Microsoft Graph, the parameters for the **Send onboarding reminder email** task are as follows:

+For Microsoft Graph, the parameters for the **Generate Temporary Access Pass and send via email to user's manager** task are as follows:

+Allows users to be added to Microsoft 365 and cloud-only security groups. Mail-enabled, distribution, dynamic and role-assignable groups aren't supported. To control access to on-premises applications and resources, you need to enable group writeback. For more information, see [Azure AD Connect group writeback](../hybrid/how-to-connect-group-writeback-v2.md).

+For Microsoft Graph, the parameters for the **Add user to groups** task are as follows:

+For Microsoft Graph, the parameters for the **Add user to teams** task are as follows:

+Allows cloud-only user accounts to be enabled. Users with Azure AD role assignments aren't supported, nor are users with membership or ownership of role-assignable groups. You can utilize Azure Active Directory's HR driven provisioning to on-premises Active Directory to disable and enable synchronized accounts with an attribute mapping to `accountDisabled` based on data from your HR source. For more information, see: [Workday Configure attribute mappings](../saas-apps/workday-inbound-tutorial.md#part-4-configure-attribute-mappings) and [SuccessFactors Configure attribute mappings](../saas-apps/sap-successfactors-inbound-provisioning-tutorial.md#part-4-configure-attribute-mappings). You're able to customize the task name and description for this task in the Azure portal.

+For Microsoft Graph, the parameters for the **Enable user account** task are as follows:

+For Microsoft Graph, the parameters for the **Run a Custom Task Extension** task are as follows:

+Allows cloud-only user accounts to be disabled. Users with Azure AD role assignments aren't supported, nor are users with membership or ownership of role-assignable groups. You can utilize Azure Active Directory's HR driven provisioning to on-premises Active Directory to disable and enable synchronized accounts with an attribute mapping to `accountDisabled` based on data from your HR source. For more information, see: [Workday Configure attribute mappings](../saas-apps/workday-inbound-tutorial.md#part-4-configure-attribute-mappings) and [SuccessFactors Configure attribute mappings](../saas-apps/sap-successfactors-inbound-provisioning-tutorial.md#part-4-configure-attribute-mappings). You're able to customize the task name and description for this task in the Azure portal.

+For Microsoft Graph, the parameters for the **Disable user account** task are as follows:

+Allows users to be removed from Microsoft 365 and cloud-only security groups. Mail-enabled, distribution, dynamic and role-assignable groups aren't supported. To control access to on-premises applications and resources, you need to enable group writeback. For more information, see [Azure AD Connect group writeback](../hybrid/how-to-connect-group-writeback-v2.md).

+For Microsoft Graph, the parameters for the **Remove user from selected groups** task are as follows:

+Allows users to be removed from every Microsoft 365 and cloud-only security group they're a member of. Mail-enabled, distribution, dynamic and role-assignable groups aren't supported. To control access to on-premises applications and resources, you need to enable group writeback. For more information, see [Azure AD Connect group writeback](../hybrid/how-to-connect-group-writeback-v2.md).

+For Microsoft Graph, the parameters for the **Remove users from all groups** task are as follows:

+For Microsoft Graph, the parameters for the **Remove User from Teams** task are as follows:

+For Microsoft Graph, the parameters for the **Remove users from all teams** task are as follows:

+For Microsoft Graph, the parameters for the **Remove all license assignment from user** task are as follows:

+Allows cloud-only user accounts to be deleted. Users with Azure AD role assignments aren't supported, nor are users with membership or ownership of role-assignable groups. You're able to customize the task name and description for this task in the Azure portal.

+For Microsoft Graph, the parameters for the **Delete User** task are as follows:

+For Microsoft Graph, the parameters for the **Send email on user last day** task are as follows:

+For Microsoft Graph, the parameters for the **Send email to users manager after their last day** task are as follows:

+ Title: Execute employee termination tasks by using lifecycle workflows (preview)

+description: Learn how to remove users from an organization in real time on their last day of work by using lifecycle workflows (preview) in the Azure portal.

+# Execute employee termination tasks by using lifecycle workflows (preview)

+This tutorial provides a step-by-step guide on how to execute a real-time employee termination by using lifecycle workflows (preview) in the Azure portal.

+This *leaver* scenario runs a workflow on demand and accomplishes the following tasks:

+- Remove the user from all groups.

+- Remove the user from all Microsoft Teams memberships.

+- Delete the user account.

+For more information, see [Run a workflow on demand](on-demand-workflow.md).

+The preview of lifecycle workflows requires Azure Active Directory (Azure AD) Premium P2. For more information, see [License requirements](what-are-lifecycle-workflows.md#license-requirements).

+## Before you begin

+As part of the prerequisites for completing this tutorial, you need an account that has group and Teams memberships and that can be deleted during the tutorial. For comprehensive instructions on how to complete these prerequisite steps, see [Prepare user accounts for lifecycle workflows](tutorial-prepare-azure-ad-user-accounts.md).

+The leaver scenario includes the following steps:

+1. Prerequisite: Create a user account that represents an employee leaving your organization.

+1. Prerequisite: Prepare the user account with group and Teams memberships.

+1. Create the lifecycle management workflow.

+1. Run the workflow on demand.

+1. Verify that the workflow was successfully executed.

+## Create a workflow by using the leaver template

+Use the following steps to create a leaver on-demand workflow that will execute a real-time employee termination by using lifecycle workflows in the Azure portal:

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

+2. On the right, select **Azure Active Directory**.

+3. Select **Identity Governance**.

+4. Select **Lifecycle workflows (Preview)**.

+5. On the **Overview** tab, select **New workflow**.

+ :::image type="content" source="media/tutorial-lifecycle-workflows/new-workflow.png" alt-text="Screenshot of the Overview tab and the button for creating a new workflow." lightbox="media/tutorial-lifecycle-workflows/new-workflow.png":::

+6. From the collection of templates, choose **Select** under **Real-time employee termination**.

+ :::image type="content" source="media/tutorial-lifecycle-workflows/select-template.png" alt-text="Screenshot of selecting a workflow template for real-time employee termination." lightbox="media/tutorial-lifecycle-workflows/select-template.png":::

+7. Configure basic information about the workflow, and then select **Next: Review tasks**.

+ :::image type="content" source="media/tutorial-lifecycle-workflows/real-time-leaver.png" alt-text="Screenshot of the tab for basic workflow information." lightbox="media/tutorial-lifecycle-workflows/real-time-leaver.png":::

+8. Inspect the tasks if you want, but no additional configuration is needed. Select **Next: Select users** when you're finished.

+ :::image type="content" source="media/tutorial-lifecycle-workflows/real-time-tasks.png" alt-text="Screenshot of the tab for reviewing template tasks." lightbox="media/tutorial-lifecycle-workflows/real-time-tasks.png":::

+9. Choose the **Select users to run now** option. It allows you to select users for which the workflow will be executed immediately after creation. Regardless of the selection, you can run the workflow on demand later at any time, as needed.

+ :::image type="content" source="media/tutorial-lifecycle-workflows/real-time-users.png" alt-text="Screenshot of the option for selecting users to run now." lightbox="media/tutorial-lifecycle-workflows/real-time-users.png":::

+10. Select **Add users** to designate the users for this workflow.

+ :::image type="content" source="media/tutorial-lifecycle-workflows/real-time-add-users.png" alt-text="Screenshot of the button for adding users." lightbox="media/tutorial-lifecycle-workflows/real-time-add-users.png":::

+11. A panel with the list of available users appears on the right side of the window. Choose **Select** when you're done with your selection.

+ :::image type="content" source="media/tutorial-lifecycle-workflows/real-time-user-list.png" alt-text="Screenshot of a list of available users." lightbox="media/tutorial-lifecycle-workflows/real-time-user-list.png":::

+12. Select **Next: Review and create** when you're satisfied with your selection of users.

+ :::image type="content" source="media/tutorial-lifecycle-workflows/real-time-review-users.png" alt-text="Screenshot of added users." lightbox="media/tutorial-lifecycle-workflows/real-time-review-users.png":::

+13. Verify that the information is correct, and then select **Create**.

+ :::image type="content" source="media/tutorial-lifecycle-workflows/real-time-create.png" alt-text="Screenshot of the tab for reviewing workflow choices, along with the button for creating the workflow." lightbox="media/tutorial-lifecycle-workflows/real-time-create.png":::

+## Run the workflow

+Now that you've created the workflow, it will automatically run every three hours. Lifecycle workflows check every three hours for users in the associated execution condition and execute the configured tasks for those users.

+To run the workflow immediately, you can use the on-demand feature.

+> [!NOTE]

+> You currently can't run a workflow on demand if it's set to **Disabled**. You need to set the workflow to **Enabled** to use the on-demand feature.

+To run a workflow on demand for users by using the Azure portal:

+1. On the workflow screen, select the specific workflow that you want to run.

+2. Select **Run on demand**.

+3. On the **Select users** tab, select **Add users**.

+4. Add users.

+5. Select **Run workflow**.

+At any time, you can monitor the status of workflows and tasks. Three data pivots, users runs, and tasks are currently available in public preview. You can learn more in the how-to guide [Check the status of a workflow (preview)](check-status-workflow.md). In this tutorial, you check the status by using the user-focused reports.

+1. On the **Overview** page for the workflow, select **Workflow history (Preview)**.

+ :::image type="content" source="media/tutorial-lifecycle-workflows/workflow-history-real-time.png" alt-text="Screenshot of the overview page for a workflow." lightbox="media/tutorial-lifecycle-workflows/workflow-history-real-time.png":::

+ The **Workflow history** page appears.

+ :::image type="content" source="media/tutorial-lifecycle-workflows/user-summary-real-time.png" alt-text="Screenshot of real-time workflow history." lightbox="media/tutorial-lifecycle-workflows/user-summary-real-time.png":::

+1. Select **Total tasks** for a user to view the total number of tasks created and their statuses.

+ :::image type="content" source="media/tutorial-lifecycle-workflows/total-tasks-real-time.png" alt-text="Screenshot of total tasks for a real-time workflow." lightbox="media/tutorial-lifecycle-workflows/total-tasks-real-time.png":::

+1. To add an extra layer of granularity, select **Failed tasks** for a user to view the total number of failed tasks assigned to that user.

+ :::image type="content" source="media/tutorial-lifecycle-workflows/failed-tasks-real-time.png" alt-text="Screenshot of failed tasks for a real-time workflow." lightbox="media/tutorial-lifecycle-workflows/failed-tasks-real-time.png":::

+1. Select **Unprocessed tasks** for a user to view the total number of unprocessed or canceled tasks assigned to that user.

+ :::image type="content" source="media/tutorial-lifecycle-workflows/canceled-tasks-real-time.png" alt-text="Screenshot of unprocessed tasks for a real-time workflow." lightbox="media/tutorial-lifecycle-workflows/canceled-tasks-real-time.png":::

+- [Prepare user accounts for lifecycle workflows (preview)](tutorial-prepare-azure-ad-user-accounts.md)

+- [Complete tasks in real time on an employee's last day of work by using lifecycle workflow APIs](/graph/tutorial-lifecycle-workflows-offboard-custom-workflow)

+ Title: What are lifecycle workflows?

+description: Get an overview of the lifecycle workflow feature of Azure AD.

+# What are lifecycle workflows (preview)?

+Lifecycle workflows (preview) are a new identity governance feature that enables organizations to manage Azure Active Directory (Azure AD) users by automating these three basic lifecycle processes:

+- **Joiner**: When an individual enters the scope of needing access. An example is a new employee joining a company or organization.

+- **Mover**: When an individual moves between boundaries within an organization. This movement might require more access or authorization. An example is a user who was in marketing and is now a member of the sales organization.

+- **Leaver**: When an individual leaves the scope of needing access. This movement might require the removal of access. Examples are an employee who's retiring or an employee who's terminated.

+Workflows contain specific processes that run automatically against users as they move through their lifecycle. Workflows consist of [tasks](lifecycle-workflow-tasks.md) and [execution conditions](understanding-lifecycle-workflows.md#understanding-lifecycle-workflows).

+Tasks are specific actions that run automatically when a workflow is triggered. An execution condition defines the scope of who's affected and the trigger of when a workflow will be performed. For example, sending a manager an email seven days before the value in the `NewEmployeeHireDate` attribute of new employees can be described as a workflow. It consists of:

+- Task: Send email.

+- Who (scope): New employees.

+- When (trigger): Seven days before the `NewEmployeeHireDate` attribute value.

+An automatic workflow schedules a [trigger](understanding-lifecycle-workflows.md#trigger-details) based on user attributes. Scoping of automatic workflows is possible through a wide range of user and extended attributes, such as the department that a user belongs to.

+Lifecycle workflows can even [integrate with the ability of logic apps tasks to extend workflows](lifecycle-workflow-extensibility.md) for more complex scenarios through your existing logic apps.

+## Why to use lifecycle workflows

+Anyone who wants to modernize an identity lifecycle management process for employees needs to ensure:

+- That when users join the organization, they're ready to go on day one. They have the correct access to information, group memberships, and applications that they need.

+- That users who are no longer tied to the company for various reasons (termination, separation, leave of absence, or retirement) have their access revoked in a timely way.

+- That the process for providing or revoking access isn't overly burdensome or time consuming for administrators.

+- That administrators and employees can easily troubleshoot problems, and that logging is sufficient to help with troubleshooting, auditing, and compliance.

+Key reasons to use lifecycle workflows include:

+- Extend your HR-driven provisioning process with other workflows that simplify and automate tasks.

+- Centralize your workflow process so you can easily create and manage workflows in one location.

+- Easily troubleshoot workflow scenarios with the workflow history and audit logs.

+- Manage user lifecycle at scale. As your organization grows, the need for other resources to manage user lifecycles decreases.

+- Reduce or remove manual tasks.

+- Apply logic apps to extend workflows for more complex scenarios with your existing logic apps.

+Those capabilities can help ensure a holistic experience by allowing you to remove other dependencies and applications to achieve the same result. You can then increase efficiency in new employee orientation and in removal of former employees from the system.

+## When to use lifecycle workflows

+You can use lifecycle workflows to address any of the following conditions:

+- **Automating and extending user orientation and HR provisioning**: Use lifecycle workflows when you want to extend your HR provisioning scenarios by automating tasks such as generating temporary passwords and emailing managers. If you currently have a manual process for orientation, use lifecycle workflows as part of an automated process.

+- **Automating group membership**: When groups in your organization are well defined, you can automate user membership in those groups. Benefits and differences from dynamic groups include:

+ - Lifecycle workflows manage static groups, where you don't need a dynamic group rule.

+ - There's no need to have one rule per group. Lifecycle workflow rules determine the scope of users to execute workflows against, not which group.

+ - Lifecycle workflows help manage users' lifecycle beyond attributes supported in dynamic groups--for example, a certain number of days before the `NewEmployeeHireDate` attribute value.

+ - Lifecycle workflows can perform actions on the group, not just the membership.

+- **Workflow history and auditing**: Use lifecycle workflows when you need to create an audit trail of user lifecycle processes. By using the Azure portal, you can view history and audits for orientation and departure scenarios.

+- **Automating user account management**: A key part of the identity lifecycle process is making sure that users who are leaving have their access to resources revoked. You can use lifecycle workflows to automate the disabling and removal of user accounts.

+- **Integrating with logic apps**: You can apply logic apps to extend workflows for more complex scenarios.

+During this preview, you can:

+- [Create a custom workflow by using the Azure portal](tutorial-onboard-custom-workflow-portal.md)

+- [Create a lifecycle workflow](create-lifecycle-workflow.md)

+- One of the following roles: Global Administrator, or owner of the service principal.

+> You can add or remove reviewers for this workflow by modifying the **Who can review admin consent requests** list. A current limitation of this feature is that a reviewer retains the ability to review requests that were made while they were designated as a reviewer and will receive expiration reminder emails for those requests after they're removed from the reviewers list. Additionally, new reviewers will not be assigned to requests that were created before they were set as a reviewer.

+ If you get an `Request_MultipleObjectsWithSameKeyValue` error, you might already have an existing configuration. For more information, see [Symptom - Request_MultipleObjectsWithSameKeyValue error](#symptomrequest_multipleobjectswithsamekeyvalue-error).

+ If you get an `Request_MultipleObjectsWithSameKeyValue` error, you might already have an existing policy. For more information, see [Symptom - Request_MultipleObjectsWithSameKeyValue error](#symptomrequest_multipleobjectswithsamekeyvalue-error).

+ If you get an `Request_MultipleObjectsWithSameKeyValue` error, you might already have an existing configuration. For more information, see [Symptom - Request_MultipleObjectsWithSameKeyValue error](#symptomrequest_multipleobjectswithsamekeyvalue-error).

+#### Symptom - Request_MultipleObjectsWithSameKeyValue error

+When you try to make a Graph API call, you receive an error message similar to the following:

+```

+code: Request_MultipleObjectsWithSameKeyValue

+message: Another object with the same value for property tenantId already exists.

+message: A conflicting object with one or more of the specified property values is present in the directory.

+```

+**Cause**

+You are likely trying to create a configuration or object that already exists, possibly from a previous configuration.

+**Solution**

+1. Verify your request syntax and that you are using the correct tenant ID.

+1. Make a `GET` request to list the existing object.

+1. If you have an existing object, instead of making a create request using `POST` or `PUT`, you might need to make an update request using `PATCH`, such as:

+ - [Update crossTenantAccessPolicyConfigurationPartner](/graph/api/crosstenantaccesspolicyconfigurationpartner-update?view=graph-rest-beta&preserve-view=true)

+ - [Update crossTenantIdentitySyncPolicyPartner](/graph/api/crosstenantidentitysyncpolicypartner-update?view=graph-rest-beta&preserve-view=true)

+#### Symptom - Directory_ObjectNotFound error

+When you try to make a Graph API call, you receive an error message similar to the following:

+```

+code: Directory_ObjectNotFound

+message: Unable to read the company information from the directory.

+```

+**Cause**

+You are likely trying to update an object that doesn't exist using `PATCH`.

+**Solution**

+1. Verify your request syntax and that you are using the correct tenant ID.

+1. Make a `GET` request to verify the object doesn't exist.

+1. If object doesn't exist, instead of making an update request using `PATCH`, you might need to make a create request using `POST` or `PUT`, such as:

+ - [Create identitySynchronization](/graph/api/crosstenantaccesspolicyconfigurationpartner-put-identitysynchronization?view=graph-rest-beta&preserve-view=true)

+Follow these steps to make a user eligible member or owner of a group. You will need permissions to manage groups. For role-assignable groups, you need to have Global Administrator, Privileged Role Administrator role, or be an Owner of the group. For non-role-assignable groups, you need to have Global Administrator, Directory Writer, Groups Administrator, Identity Governance Administrator, User Administrator role, or be an Owner of the group. Role assignments for administrators should be scoped at directory level (not administrative unit level).

+> [!NOTE]

+> Other roles with permissions to manage groups (such as Exchange Administrators for non-role-assignable M365 groups) and administrators with assignments scoped at administrative unit level can manage groups through Groups API/UX and override changes made in Azure AD PIM.

+Follow these steps to update or remove an existing role assignment. You will need permissions to manage groups. For role-assignable groups, you need to have Global Administrator, Privileged Role Administrator role, or be an Owner of the group. For non-role-assignable groups, you need to have Global Administrator, Directory Writer, Groups Administrator, Identity Governance Administrator, User Administrator role, or be an Owner of the group. Role assignments for administrators should be scoped at directory level (not administrative unit level).

+> [!NOTE]

+> Other roles with permissions to manage groups (such as Exchange Administrators for non-role-assignable M365 groups) and administrators with assignments scoped at administrative unit level can manage groups through Groups API/UX and override changes made in Azure AD PIM.

+You need appropriate permissions to bring groups in Azure AD PIM. For role-assignable groups, you need to have Global Administrator, Privileged Role Administrator role, or be an Owner of the group. For non-role-assignable groups, you need to have Global Administrator, Directory Writer, Groups Administrator, Identity Governance Administrator, User Administrator role, or be an Owner of the group. Role assignments for administrators should be scoped at directory level (not administrative unit level).

+> [!NOTE]

+> Other roles with permissions to manage groups (such as Exchange Administrators for non-role-assignable M365 groups) and administrators with assignments scoped at administrative unit level can manage groups through Groups API/UX and override changes made in Azure AD PIM.

+Only users with permissions to manage groups can extend or renew group membership or ownership time-bound assignments. The affected user or group can request to extend assignments that are about to expire and request to renew assignments that are already expired.

+Role-assignable groups can be managed by Global Administrator, Privileged Role Administrator, or Owner of the group. Non-role-assignable groups can be managed by Global Administrator, Directory Writer, Groups Administrator, Identity Governance Administrator, User Administrator, or Owner of the group. Role assignments for administrators should be scoped at directory level (not Administrative Unit level).

+> [!NOTE]

+> Other roles with permissions to manage groups (such as Exchange Administrators for non-role-assignable M365 groups) and administrators with assignments scoped at administrative unit level can manage groups through Groups API/UX and override changes made in Azure AD PIM.

+You will need group management permissions to manage settings. For role-assignable groups, you need to have Global Administrator, Privileged Role Administrator role, or be an Owner of the group. For non-role assignable groups, you need to have Global Administrator, Directory Writer, Groups Administrator, Identity Governance Administrator, User Administrator role, or be an Owner of the group. Role assignments for administrators should be scoped at directory level (not Administrative Unit level).

+> [!NOTE]

+> Other roles with permissions to manage groups (such as Exchange Administrators for non-role-assignable M365 groups) and administrators with assignments scoped at administrative unit level can manage groups through Groups API/UX and override changes made in Azure AD PIM.

+Role settings are defined per role per group: all assignments for the same role (member or owner) for the same group follow same role settings. Role settings of one group are independent from role settings of another group. Role settings for one role (member) are independent from role settings for another role (owner).

+[Cross-tenant synchronization](../multi-tenant-organizations/cross-tenant-synchronization-overview.md) | Configure cross-tenant access settings for users in another tenant. Security Administrators can't directly create and delete users, but can indirectly create and delete synchronized users from another tenant when both tenants are configured for cross-tenant synchronization, which is a privileged permission.

+* A Howspace subscription with single sign-on and SCIM features enabled.

+* A user account in Howspace with Main User Dashboard privileges.

+### Single sign-on configuration

+1. Sign in to the Howspace Main User Dashboard, then select **Settings** from the menu.

+1. In the settings list, select **single sign-on**.

+ 

+1. Click the **Add SSO configuration** button.

+ 

+1. Select either **Azure Active Directory (Multi-Tenant)** or **Azure Active Directory** based on your organization's Azure AD topology.

+ 

+ 

+1. Enter your Azure AD Tenant ID, and click **OK** to save the configuration.

+### Provisioning configuration

+1. In the settings list, select **System for Cross-domain Identity Management**.

+ 

+1. Check the **Enable user synchronization** checkbox.

+1. Copy the Tenant URL and Secret Token for later use in Azure AD.

+1. Click **Save** to save the configuration.

+### Main user dashboard access control configuration

+1. In the settings list, select **Main User Dashboard Access Control**

+ 

+1. Check the **Enable single sign-on for main users** checkbox.

+1. Select the SSO configuration you created in the previous step.

+1. Enter the object IDs of the Azure AD user groups that should have access to the Main User Dashboard to the **Limit to following user groups** field. You can specify multiple groups by separating the object IDs with a comma.

+1. Click **Save** to save the configuration.

+### Workspace default access control configuration

+1. In the settings list, select **Workspace default settings**

+ 

+1. In the Workspace default settings list, select **Login, registration and SSO**

+ 

+1. Check the **Users can login using single sign-on** checkbox.

+1. Select the SSO configuration you created in the previous step.

+1. Enter the object IDs of the Azure AD user groups that should have access to workspaces to the **Limit to following user groups** field. You can specify multiple groups by separating the object IDs with a comma.

+1. You can modify the user groups for each workspace individually after creating the workspace.

+ |phoneNumbers[type eq "mobile"].value|String||

+```azurecli-interactive

+```azurecli-interactive

+```azurecli-interactive

+```azurecli-interactive

+```azurecli-interactive

+```azurecli-interactive

+```azurecli-interactive

+```azurecli-interactive

+```azurecli-interactive

+```azurecli-interactive

+```azurecli-interactive

+```azurecli-interactive

+Don't use fixed credentials within pods or container images, as they are at risk of exposure or abuse. Instead, use *pod identities* to automatically request access using Azure AD.

+> Pod identities are intended for use with Linux pods and container images only. Pod-managed identities (preview) support for Windows containers is coming soon.

+1. Create a resource group for your IP address

+ az group create --name myNetworkResourceGroup

+2. Use the [`az network public ip create`][az-network-public-ip-create] command to create a static public IP address. The following example creates a static IP resource named *myAKSPublicIP* in the *myNetworkResourceGroup* resource group.

+ --resource-group myNetworkResourceGroup \

+ az network public-ip show --resource-group myNetworkResourceGroup --name myAKSPublicIP --query ipAddress --output tsv

+ CLIENT_ID=$(az aks show --name <cluster name> --resource-group <cluster resource group> --query identity.principalId -o tsv)

+ RG_SCOPE=$(az group show --name myNetworkResourceGroup --query id -o tsv)

+ --assignee ${CLIENT_ID} \

+ --scope ${RG_SCOPE}

+ service.beta.kubernetes.io/azure-load-balancer-resource-group: myNetworkResourceGroup

+curl -X POST -u <username:password> -T "@<zip-package-path>" https://<app-name>.scm.azurewebsites.net/api/publish?type=zip

+curl -X POST -u <username> -T @"<file-path>" https://<app-name>.scm.azurewebsites.net/api/publish?type=<package-type>

+curl -X POST -u <username> -T @"<startup-file-path>" https://<app-name>.scm.azurewebsites.net/api/publish?type=startup

+curl -X POST -u <username> -T @"<lib-file-path>" https://<app-name>.scm.azurewebsites.net/api/publish?type=lib&path="/home/site/deployments/tools/my-lib.jar"

+curl -X POST -u <username> -T @"<config-file-path>" https://<app-name>.scm.azurewebsites.net/api/publish?type=static&path="/home/site/deployments/tools/my-config.json"

+Modules were introduced in open-source Redis 4.0. The modules extend the use-cases of Redis by adding functionality like search capabilities and data structures like bloom and cuckoo filters.

+Additionally, **RediSearch** can function as a secondary index, expanding your cache beyond a key-value structure and offering more sophisticated queries.

+**RediSearch** also includes functionality to perform [vector similarity queries](https://redis.io/docs/stack/search/reference/vectors/) such as K-nearest neighbor (KNN) search. This feature allows Azure Cache for Redis to be used as a vector database, which is useful in AI use-cases like [semantic answer engines or any other application that requires the comparison of embeddings vectors](https://redis.com/blog/rediscover-redis-for-vector-similarity-search/) generated by machine learning models.

+You can use **RediSearch** is used in a wide variety of additional use-cases, including real-time inventory, enterprise search, and in indexing external databases. [For more information, see the RediSearch documentation page](https://redis.io/docs/stack/search/).

+ var logger = executionContext.GetLogger("PostToDo");

+public static IActionResult Run(HttpRequest req, ILogger log, out ToDoItem todoItem)

+public static IActionResult Run(HttpRequest req, ILogger log, out ToDoItem todoItem, out RequestLog requestLog)

+ requestLog = new RequestLog();

+ requestLog.RequestTimeStamp = DateTime.Now;

+ requestLog.ItemCount = 1;

+public class RequestLog {

+ public DateTime RequestTimeStamp { get; set; }

+ public int ItemCount { get; set; }

+}

+> The Azure SQL trigger for Functions is currently in preview and requires that a preview extension library or extension bundle is used.

+The Azure SQL trigger uses [SQL change tracking](/sql/relational-databases/track-changes/about-change-tracking-sql-server) functionality to monitor a SQL table for changes and trigger a function when a row is created, updated, or deleted. For configuration details for change tracking for use with the Azure SQL trigger, see [Set up change tracking](#set-up-change-tracking-required). For information on setup details of the Azure SQL extension for Azure Functions, see the [SQL binding overview](./functions-bindings-azure-sql.md).

+The Azure SQL trigger scaling decisions for the Consumption and Premium plans are done via target-based scaling. For more information, see [Target-based scaling](functions-target-based-scaling.md).

+The Azure SQL trigger binding uses a polling loop to check for changes, triggering the user function when changes are detected. At a high level, the loop looks like this:

+<a id="example"></a>

+# [In-process](#tab/in-process)

+More samples for the Azure SQL trigger are available in the [GitHub repository](https://github.com/Azure/azure-functions-sql-extension/tree/release/trigger/samples/samples-csharp).

+More samples for the Azure SQL trigger are available in the [GitHub repository](https://github.com/Azure/azure-functions-sql-extension/tree/release/trigger/samples/samples-outofproc).

+The example refers to a `ToDoItem` class and a corresponding database table:

+[Change tracking](#set-up-change-tracking-required) is enabled on the database and on the table:

+```sql

+ALTER DATABASE [SampleDatabase]

+SET CHANGE_TRACKING = ON

+(CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);

+ALTER TABLE [dbo].[ToDo]

+ENABLE CHANGE_TRACKING;

+```

+The SQL trigger binds to a `IReadOnlyList<SqlChange<T>>`, a list of `SqlChange` objects each with two properties:

+- **Item:** the item that was changed. The type of the item should follow the table schema as seen in the `ToDoItem` class.

+- **Operation:** a value from `SqlChangeOperation` enum. The possible values are `Insert`, `Update`, and `Delete`.

+The following example shows a [C# function](functions-dotnet-class-library.md) that is invoked when there are changes to the `ToDo` table:

+```cs

+using System;

+using System.Collections.Generic;

+using Microsoft.Azure.Functions.Worker;

+using Microsoft.Azure.Functions.Worker.Extensions.Sql;

+using Microsoft.Extensions.Logging;

+using Newtonsoft.Json;

+namespace AzureSQL.ToDo

+{

+ public static class ToDoTrigger

+ {

+ [FunctionName("ToDoTrigger")]

+ public static void Run(

+ [SqlTrigger("[dbo].[ToDo]", "SqlConnectionString")]

+ IReadOnlyList<SqlChange<ToDoItem>> changes,

+ FunctionContext context)

+ {

+ var logger = context.GetLogger("ToDoTrigger");

+ foreach (SqlChange<ToDoItem> change in changes)

+ {

+ ToDoItem toDoItem = change.Item;

+ logger.LogInformation($"Change operation: {change.Operation}");

+ logger.LogInformation($"Id: {toDoItem.Id}, Title: {toDoItem.title}, Url: {toDoItem.url}, Completed: {toDoItem.completed}");

+ }

+ }

+ }

+}

+```

+More samples for the Azure SQL trigger are available in the [GitHub repository](https://github.com/Azure/azure-functions-sql-extension/tree/release/trigger/samples/samples-csharpscript).

+The example refers to a `ToDoItem` class and a corresponding database table:

+[Change tracking](#set-up-change-tracking-required) is enabled on the database and on the table:

+```sql

+ALTER DATABASE [SampleDatabase]

+SET CHANGE_TRACKING = ON

+(CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);

+ALTER TABLE [dbo].[ToDo]

+ENABLE CHANGE_TRACKING;

+```

+The SQL trigger binds to a `IReadOnlyList<SqlChange<T>>`, a list of `SqlChange` objects each with two properties:

+- **Item:** the item that was changed. The type of the item should follow the table schema as seen in the `ToDoItem` class.

+- **Operation:** a value from `SqlChangeOperation` enum. The possible values are `Insert`, `Update`, and `Delete`.

+The following example shows a SQL trigger in a function.json file and a [C# script function](functions-reference-csharp.md) that is invoked when there are changes to the `ToDo` table:

+The following is binding data in the function.json file:

+```json

+{

+ "name": "todoChanges",

+ "type": "sqlTrigger",

+ "direction": "in",

+ "tableName": "dbo.ToDo",

+ "connectionStringSetting": "SqlConnectionString"

+}

+```

+The following is the C# script function:

+```csharp

+#r "Newtonsoft.Json"

+using System.Net;

+using Microsoft.AspNetCore.Mvc;

+using Microsoft.Extensions.Primitives;

+using Newtonsoft.Json;

+public static void Run(IReadOnlyList<SqlChange<ToDoItem>> todoChanges, ILogger log)

+{

+ log.LogInformation($"C# SQL trigger function processed a request.");

+ foreach (SqlChange<ToDoItem> change in todoChanges)

+ {

+ ToDoItem toDoItem = change.Item;

+ log.LogInformation($"Change operation: {change.Operation}");

+ log.LogInformation($"Id: {toDoItem.Id}, Title: {toDoItem.title}, Url: {toDoItem.url}, Completed: {toDoItem.completed}");

+ }

+}

+```

+## Example usage

+<a id="example"></a>

+More samples for the Azure SQL trigger are available in the [GitHub repository](https://github.com/Azure/azure-functions-sql-extension/tree/release/trigger/samples/samples-java).

+The example refers to a `ToDoItem` class, a `SqlChangeToDoItem` class, a `SqlChangeOperation` enum, and a corresponding database table:

+In a separate file `ToDoItem.java`:

+```java

+package com.function;

+import java.util.UUID;

+public class ToDoItem {

+ public UUID Id;

+ public int order;

+ public String title;

+ public String url;

+ public boolean completed;

+ public ToDoItem() {

+ }

+ public ToDoItem(UUID Id, int order, String title, String url, boolean completed) {

+ this.Id = Id;

+ this.order = order;

+ this.title = title;

+ this.url = url;

+ this.completed = completed;

+ }

+}

+```

+In a separate file `SqlChangeToDoItem.java`:

+```java

+package com.function;

+public class SqlChangeToDoItem {

+ public ToDoItem item;

+ public SqlChangeOperation operation;

+ public SqlChangeToDoItem() {

+ }

+ public SqlChangeToDoItem(ToDoItem item, SqlChangeOperation operation) {

+ this.item = item;

+ this.operation = operation;

+ }

+}

+```

+In a separate file `SqlChangeOperation.java`:

+```java

+package com.function;

+import com.google.gson.annotations.SerializedName;

+public enum SqlChangeOperation {

+ @SerializedName("0")

+ Insert,

+ @SerializedName("1")

+ Update,

+ @SerializedName("2")

+ Delete;

+}

+```

+[Change tracking](#set-up-change-tracking-required) is enabled on the database and on the table:

+```sql

+ALTER DATABASE [SampleDatabase]

+SET CHANGE_TRACKING = ON

+(CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);

+ALTER TABLE [dbo].[ToDo]

+ENABLE CHANGE_TRACKING;

+```

+The SQL trigger binds to a `SqlChangeToDoItem[]`, an array of `SqlChangeToDoItem` objects each with two properties:

+- **item:** the item that was changed. The type of the item should follow the table schema as seen in the `ToDoItem` class.

+- **operation:** a value from `SqlChangeOperation` enum. The possible values are `Insert`, `Update`, and `Delete`.

+The following example shows a Java function that is invoked when there are changes to the `ToDo` table:

+```java

+package com.function;

+import com.microsoft.azure.functions.ExecutionContext;

+import com.microsoft.azure.functions.annotation.FunctionName;

+import com.microsoft.azure.functions.sql.annotation.SQLTrigger;

+import com.function.Common.SqlChangeToDoItem;

+import com.google.gson.Gson;

+import java.util.logging.Level;

+public class ProductsTrigger {

+ @FunctionName("ToDoTrigger")

+ public void run(

+ @SQLTrigger(

+ name = "todoItems",

+ tableName = "[dbo].[ToDo]",

+ connectionStringSetting = "SqlConnectionString")

+ SqlChangeToDoItem[] todoItems,

+ ExecutionContext context) {

+ context.getLogger().log(Level.INFO, "SQL Changes: " + new Gson().toJson(changes));

+ }

+}

+```

+## Example usage

+<a id="example"></a>

+More samples for the Azure SQL trigger are available in the [GitHub repository](https://github.com/Azure/azure-functions-sql-extension/tree/release/trigger/samples/samples-powershell).

+The example refers to a `ToDoItem` database table:

+[Change tracking](#set-up-change-tracking-required) is enabled on the database and on the table:

+```sql

+ALTER DATABASE [SampleDatabase]

+SET CHANGE_TRACKING = ON

+(CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);

+ALTER TABLE [dbo].[ToDo]

+ENABLE CHANGE_TRACKING;

+```

+The SQL trigger binds to `todoChanges`, a list of objects each with two properties:

+- **item:** the item that was changed. The structure of the item will follow the table schema.

+- **operation:** the possible values are `Insert`, `Update`, and `Delete`.

+The following example shows a PowerShell function that is invoked when there are changes to the `ToDo` table.

+The following is binding data in the function.json file:

+```json

+{

+ "name": "todoChanges",

+ "type": "sqlTrigger",

+ "direction": "in",

+ "tableName": "dbo.ToDo",

+ "connectionStringSetting": "SqlConnectionString"

+}

+```

+The [configuration](#configuration) section explains these properties.

+The following is sample PowerShell code for the function in the `run.ps1` file:

+```powershell

+using namespace System.Net

+param($todoChanges)

+# The output is used to inspect the trigger binding parameter in test methods.

+# Use -Compress to remove new lines and spaces for testing purposes.

+$changesJson = $todoChanges | ConvertTo-Json -Compress

+Write-Host "SQL Changes: $changesJson"

+```

+## Example usage

+<a id="example"></a>

+More samples for the Azure SQL trigger are available in the [GitHub repository](https://github.com/Azure/azure-functions-sql-extension/tree/release/trigger/samples/samples-js).

+The example refers to a `ToDoItem` database table:

+[Change tracking](#set-up-change-tracking-required) is enabled on the database and on the table:

+```sql

+ALTER DATABASE [SampleDatabase]

+SET CHANGE_TRACKING = ON

+(CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);

+ALTER TABLE [dbo].[ToDo]

+ENABLE CHANGE_TRACKING;

+```

+The SQL trigger binds `todoChanges`, an array of objects each with two properties:

+- **item:** the item that was changed. The structure of the item will follow the table schema.

+- **operation:** the possible values are `Insert`, `Update`, and `Delete`.

+The following example shows a JavaScript function that is invoked when there are changes to the `ToDo` table.

+The following is binding data in the function.json file:

+```json

+{

+ "name": "todoChanges",

+ "type": "sqlTrigger",

+ "direction": "in",

+ "tableName": "dbo.ToDo",

+ "connectionStringSetting": "SqlConnectionString"

+}

+```

+The [configuration](#configuration) section explains these properties.

+The following is sample JavaScript code for the function in the `index.js` file:

+```javascript

+module.exports = async function (context, todoChanges) {

+ context.log(`SQL Changes: ${JSON.stringify(todoChanges)}`)

+}

+```

+## Example usage

+<a id="example"></a>

+More samples for the Azure SQL trigger are available in the [GitHub repository](https://github.com/Azure/azure-functions-sql-extension/tree/release/trigger/samples/samples-python).

+The example refers to a `ToDoItem` database table:

+[Change tracking](#set-up-change-tracking-required) is enabled on the database and on the table:

+```sql

+ALTER DATABASE [SampleDatabase]

+SET CHANGE_TRACKING = ON

+(CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);

+ALTER TABLE [dbo].[ToDo]

+ENABLE CHANGE_TRACKING;

+```

+The SQL trigger binds to a variable `todoChanges`, a list of objects each with two properties:

+- **item:** the item that was changed. The structure of the item will follow the table schema.

+- **operation:** the possible values are `Insert`, `Update`, and `Delete`.

+The following example shows a Python function that is invoked when there are changes to the `ToDo` table.

+The following is binding data in the function.json file:

+```json

+{

+ "name": "todoChanges",

+ "type": "sqlTrigger",

+ "direction": "in",

+ "tableName": "dbo.ToDo",

+ "connectionStringSetting": "SqlConnectionString"

+}

+```

+The [configuration](#configuration) section explains these properties.

+The following is sample Python code for the function in the `__init__.py` file:

+```python

+import json

+import logging

+def main(changes):

+ logging.info("SQL Changes: %s", json.loads(changes))

+```

+## Annotations

+In the [Java functions runtime library](/java/api/overview/azure/functions/runtime), use the `@SQLTrigger` annotation (`com.microsoft.azure.functions.sql.annotation.SQLTrigger`) on parameters whose value would come from Azure SQL. This annotation supports the following elements:

+| Element |Description|

+|||

+| **name** | Required. The name of the parameter that the trigger binds to. |

+| **tableName** | Required. The name of the table monitored by the trigger. |

+| **connectionStringSetting** | Required. The name of an app setting that contains the connection string for the database containing the table monitored for changes. The connection string setting name corresponds to the application setting (in `local.settings.json` for local development) that contains the [connection string](/dotnet/api/microsoft.data.sqlclient.sqlconnection.connectionstring?view=sqlclient-dotnet-core-5.&preserve-view=true#Microsoft_Data_SqlClient_SqlConnection_ConnectionString) to the Azure SQL or SQL Server instance.|

+## Configuration

+||-|

+| **name** | Required. The name of the parameter that the trigger binds to. |

+| **type** | Required. Must be set to `sqlTrigger`. |

+| **direction** | Required. Must be set to `in`. |

+| **tableName** | Required. The name of the table monitored by the trigger. |

+| **connectionStringSetting** | Required. The name of an app setting that contains the connection string for the database containing the table monitored for changes. The connection string setting name corresponds to the application setting (in `local.settings.json` for local development) that contains the [connection string](/dotnet/api/microsoft.data.sqlclient.sqlconnection.connectionstring?view=sqlclient-dotnet-core-5.&preserve-view=true#Microsoft_Data_SqlClient_SqlConnection_ConnectionString) to the Azure SQL or SQL Server instance.|

+## Optional Configuration

+ <version>2.0.0-preview</version>

+- Your function must be named `warmup` (case-insensitive) using the `Function` attribute.

+| **Connect to a SQL database** | Use [SQL bindings](./functions-bindings-azure-sql.md) to read or write data from Azure SQL |

+| Azure SQL Database | All | [Connect a function app to Azure SQL with managed identity and SQL bindings][azuresql-identity]

+[azuresql-identity]: ./functions-identity-access-azure-sql-with-managed-identity.md

+- If you don't already have an Azure account, [sign up for a free account] before you continue.

+- For picking account location, if you're unfamiliar with managed identities for Azure resources, see [managed identities for Azure resources].

+Picking a location for your Azure Maps account that aligns with other resources in your subscription, like managed identities, may help to improve the level of service for [control-plane] operations.

+As an example, the managed identity infrastructure notifies the Azure Maps management services for changes to the identity resource such as credential renewal or deletion. Sharing the same Azure location enables a consistent infrastructure provisioning for all resources.

+An Azure Maps account, regardless of location, can access any endpoint belonging to the Azure data-plane, such as `atlas.microsoft.com` and `*.atlas.microsoft.com`, when using Azure Maps REST API.

+Read more about data-plane service coverage for Azure Maps services on [geographic coverage].

+1. Sign in to the [Azure portal].

+> [Manage authentication]

+> [Manage a pricing tier]

+> [View usage metrics]

+[Azure portal]: https://portal.azure.com

+[control-plane]: ../azure-resource-manager/management/control-plane-and-data-plane.md

+[geographic coverage]: geographic-coverage.md

+[Manage a pricing tier]: how-to-manage-pricing-tier.md

+[Manage authentication]: how-to-manage-authentication.md

+[managed identities for Azure resources]: ../active-directory/managed-identities-azure-resources/overview.md

+[sign up for a free account]: https://azure.microsoft.com/free/?WT.mc_id=A261C142F

+[View usage metrics]: how-to-view-api-usage.md

+When you create an Azure Maps account, your client ID and shared keys are created automatically. These values are required for authentication when using either [Azure Active Directory (Azure AD)] or [Shared Key authentication].

+Sign in to the [Azure portal]. If you don't have an Azure subscription, create a [free account] before you begin.

+- A familiarization with [managed identities for Azure resources]. Be sure to understand the two [Managed identity types] and how they differ.

+- [An Azure Maps account].

+- A familiarization with [Azure Maps Authentication].

+1. Sign in to the [Azure portal].

+Depending on your application needs, there are specific pathways to application security. Azure AD defines specific authentication categories to support a wide range of authentication flows. To choose the best category for your application, see [application categories].

+To enable [Shared access signature (SAS) token authentication] with the Azure Maps REST API, you need to add a user-assigned managed identity to your Azure Maps account.

+You can create a user-assigned managed identity before or after creating a map account. You can add the managed identity through the portal, Azure management SDKs, or the Azure Resource Manager (ARM) template. To add a user-assigned managed identity through an ARM template, specify the resource identifier of the user-assigned managed identity.

+Removing a system-assigned identity in this way also deletes it from Azure AD. System-assigned identities are also automatically removed from Azure AD when the Azure Maps account is deleted.

+This table outlines common authentication and authorization scenarios in Azure Maps. Each scenario describes a type of app that can be used to access Azure Maps REST API. Use the links to learn detailed configuration information for each scenario.

+| Scenario | Authentication | Authorization | Development effort | Operational effort |

+| --| -- | - | | |

+| [Trusted daemon app or non-interactive client app] | Shared Key | N/A | Medium | High |

+| [Trusted daemon or non-interactive client app] | Azure AD | High | Low | Medium |

+| [Web single page app with interactive single-sign-on]| Azure AD | High | Medium | Medium |

+| [Web single page app with non-interactive sign-on] | Azure AD | High | Medium | Medium |

+| [Web app, daemon app, or non-interactive sign-on app]| SAS Token | High | Medium | Low |

+| [Web application with interactive single-sign-on] | Azure AD | High | High | Medium |

+| [IoT device or an input constrained application] | Azure AD | High | Medium | Medium |

+For more information about requesting access tokens from Azure AD for users and service principals, see [Authentication scenarios for Azure AD]. To view specific scenarios, see [the table of scenarios].

+To help keep your Azure Maps account secure, we recommend periodically rotating your subscription keys. If possible, use Azure Key Vault to manage your access keys. If you aren't using Key Vault, you need to manually rotate your keys.

+2. In the [Azure portal], navigate to your Azure Maps account.

+> [View usage metrics]

+> [Azure AD authentication samples]

+[Azure portal]: https://portal.azure.com/

+[Azure AD authentication samples]: https://github.com/Azure-Samples/Azure-Maps-AzureAD-Samples

+[View usage metrics]: how-to-view-api-usage.md

+[Authentication scenarios for Azure AD]: ../active-directory/develop/authentication-vs-authorization.md

+[the table of scenarios]: how-to-manage-authentication.md#choose-an-authentication-and-authorization-scenario

+[Trusted daemon app or non-interactive client app]: how-to-secure-daemon-app.md

+[Trusted daemon or non-interactive client app]: how-to-secure-daemon-app.md

+[Web single page app with interactive single-sign-on]: how-to-secure-spa-users.md

+[Web single page app with non-interactive sign-on]: how-to-secure-spa-app.md

+[Web app, daemon app, or non-interactive sign-on app]: how-to-secure-sas-app.md

+[Web application with interactive single-sign-on]: how-to-secure-webapp-users.md

+[IoT device or an input constrained application]: how-to-secure-device-code.md

+[Shared access signature (SAS) token authentication]: azure-maps-authentication.md#shared-access-signature-token-authentication

+[application categories]: ../active-directory/develop/authentication-flows-app-scenarios.md#application-categories

+[Azure Active Directory (Azure AD)]: ../active-directory/fundamentals/active-directory-whatis.md

+[Shared Key authentication]: azure-maps-authentication.md#shared-key-authentication

+[free account]: https://azure.microsoft.com/free/

+[managed identities for Azure resources]: ../active-directory/managed-identities-azure-resources/overview.md

+[Managed identity types]: ../active-directory/managed-identities-azure-resources/overview.md#managed-identity-types

+[An Azure Maps account]: quick-demo-map-app.md#create-an-azure-maps-account

+[Azure Maps Authentication]: azure-maps-authentication.md

+description: This article demonstrates how to manage Microsoft Azure Maps Creator.

+You can use Azure Maps Creator to create private indoor map data. Using the Azure Maps API and the Indoor Maps module, you can develop interactive and dynamic indoor map web applications. For pricing information, see the *Creator* section in [Azure Maps pricing].

+1. Sign in to the [Azure portal].

+3. You're prompted to confirm deletion by typing in the name of your Creator resource. After the resource is deleted, you see a confirmation page that looks like the following example:

+Creator usage data is incorporated in your Azure Maps usage charts and activity log. For more information, see [Manage authentication in Azure Maps].

+> * Azure Active Directory (Azure AD) in all solutions that are built with an Azure Maps account using Creator services. For more information, on Azure AD, see [Azure AD authentication].

+>* Role-based access control settings (RBAC). Using these settings, map makers can act as the Azure Maps Data Contributor role, and Creator map data users can act as the Azure Maps Data Reader role. For more information, see [Authorization with role-based access control].

+Creator services and services that use data hosted in Creator (for example, Render service), are accessible at a geographical URL. The geographical URL determines the location selected during creation. For example, if Creator is created in a region in the United States geographical location, all calls to the Conversion service must be submitted to `us.atlas.microsoft.com/conversions`. To view mappings of region to geographical location, [see Creator service geographic scope].

+> [Data upload]

+> [Data conversion]

+> [Dataset]

+> [Tileset]

+> [Feature State set]

+> [Azure Maps Creator tutorial]

+> [Indoor map dynamic styling]

+> [Use the Indoor Maps module]

+[Authorization with role-based access control]: azure-maps-authentication.md#authorization-with-role-based-access-control

+[Azure AD authentication]: azure-maps-authentication.md#azure-ad-authentication

+[Azure Maps Creator tutorial]: tutorial-creator-indoor-maps.md

+[Azure Maps pricing]: https://aka.ms/CreatorPricing

+[Azure portal]: https://portal.azure.com

+[Data conversion]: creator-indoor-maps.md#convert-a-drawing-package

+[Data upload]: creator-indoor-maps.md#upload-a-drawing-package

+[Dataset]: creator-indoor-maps.md#datasets

+[Feature State set]: creator-indoor-maps.md#feature-statesets

+[Indoor map dynamic styling]: indoor-map-dynamic-styling.md

+[Manage authentication in Azure Maps]: how-to-manage-authentication.md

+[see Creator service geographic scope]: creator-geographic-scope.md

+[Tileset]: creator-indoor-maps.md#tilesets

+[Use the Indoor Maps module]: how-to-use-indoor-module.md

+For more information on security best practices, see [Authentication and authorization best practices].

+The Azure Maps SDKs go through regular security testing along with any external dependency libraries used by the SDKs. Any known security issue is fixed in a timely manner and released to production. If your application points to the latest major version of the hosted version of the Azure Maps Web SDK, it automatically receives all minor version updates that include security related fixes.

+If self-hosting the Azure Maps Web SDK via the npm module, be sure to use the caret (^) symbol to in combination with the Azure Maps npm package version number in your `package.json` file so that it points to the latest minor version.

+ "azure-maps-control": "^2.2.6"

+> [!TIP]

+> Always use the latest version of the npm Azure Maps Control. For more information, see [azure-maps-control] in the npm documentation.

+Similarly, when the map initially loads often it's desired to load data on it as quickly as possible, so the user isn't looking at an empty map. Since the map loads resources asynchronously, you have to wait until the map is ready to be interacted with before trying to render your own data on it. There are two events you can wait for, a `load` event and a `ready` event. The load event will fire after the map has finished completely loading the initial map view and every map tile has loaded. The ready event fires when the minimal map resources needed to start interacting with the map. The ready event can often fire in half the time of the load event and thus allow you to start loading your data into the map sooner.

+If the map isn't needed right away, lazy load the Azure Maps Web SDK until it's needed. This delays the loading of the JavaScript and CSS files used by the Azure Maps Web SDK until needed. A common scenario where this occurs is when the map is loaded in a tab or flyout panel that isn't displayed on page load.

+If the map takes a while to load due to network limitations or other priorities within your application, consider adding a small background image to the map `div` as a placeholder for the map. This fills the void of the map `div` while it's loading.

+Often apps want to load the map to a specific location or style. Sometimes developers wait until the map has loaded (or wait for the `ready` event), and then use the `setCamera` or `setStyle` functions of the map. This often takes longer to get to the desired initial map view since many resources end up being loaded by default before the resources needed for the desired map view are loaded. A better approach is to pass in the desired map camera and style options into the map when initializing it.

+* **GeoJSON source**: The `DataSource` class, manages raw location data in GeoJSON format locally. Good for small to medium data sets (upwards of hundreds of thousands of features).

+* **Vector tile source**: The `VectorTileSource` class, loads data formatted as vector tiles for the current map view, based on the maps tiling system. Ideal for large to massive data sets (millions or billions of features).

+The [Azure Maps Creator platform] retrieves data in vector tile format. Other data formats can be using tools such as [Tippecanoe]. For more information on working with vector tiles, see the Mapbox [awesome-vector-tiles] readme in GitHub.

+It's also possible to create a custom service that renders datasets as raster image tiles on the server-side and load the data using the TileLayer class in the map SDK. This provides exceptional performance as the map only needs to load and manage a few dozen images at most. However, there are some limitations with using raster tiles since the raw data isn't available locally. A secondary service is often required to power any type of interaction experience, for example, find out what shape a user clicked on. Additionally, the file size of a raster tile is often larger than a compressed vector tile that contains generalized and zoom level optimized geometries.

+For more information about data sources, see [Create a data source].

+The less data sources the map has to manage, the faster it can process all features to be displayed. In particular, when it comes to tile sources, combining two vector tile sources together cuts the number of HTTP requests to retrieve the tiles in half, and the total amount of data would be slightly smaller since there's only one file header.

+Combining multiple data sets in a single vector tile source can be achieved using a tool such as [Tippecanoe]. Data sets can be combined into a single feature collection or separated into separate layers within the vector tile known as source-layers. When connecting a vector tile source to a rendering layer, you would specify the source-layer that contains the data that you want to render with the layer.

+There are several ways data in a `DataSource` class can be added or updated. The following list shows the different methods and some considerations to ensure good performance.

+* The data sources `add` function can be used to add one or more features to a data source. Each time this function is called it triggers a map canvas refresh. If adding many features, combine them into an array or feature collection and passing them into this function once, rather than looping over a data set and calling this function for each feature.

+* The data sources `setShapes` function can be used to overwrite all shapes in a data source. Under the hood, it combines the data sources `clear` and `add` functions together and does a single map canvas refresh instead of two, which is faster. Be sure to use this function when you want to update all data in a data source.

+* The data sources `importDataFromUrl` function can be used to load a GeoJSON file via a URL into a data source. Once the data has been downloaded, it's passed into the data sources `add` function. If the GeoJSON file is hosted on a different domain, be sure that the other domain supports cross domain requests (CORs). If it doesn't consider copying the data to a local file on your domain or creating a proxy service that has CORs enabled. If the file is large, consider converting it into a vector tile source.

+* If features are wrapped with the `Shape` class, the `addProperty`, `setCoordinates`, and `setProperties` functions of the shape all trigger an update in the data source and a map canvas refresh. All features returned by the data sources `getShapes` and `getShapeById` functions are automatically wrapped with the `Shape` class. If you want to update several shapes, it's faster to convert them to JSON using the data sources `toJson` function, editing the GeoJSON, then passing this data into the data sources `setShapes` function.

+This is a common scenario in applications that clear the data source, download new data, clear the data source again, then adds the new data to the data source. Depending on the desired user experience, the following alternatives would be better.

+* Clear the data before downloading the new data, then pass the new data into the data sources `add` or `setShapes` function. If this is the only data set on the map, the map is empty while the new data is downloading.

+* Download the new data, then pass it into the data sources `setShapes` function. This replaces all the data on the map.

+When features have numerous properties or content, it's much more performant to limit what gets added to the data source to just those needed for rendering and to have a separate method or service for retrieving the other property or content when needed. For example, if you have a simple map displaying locations on a map when clicked a bunch of detailed content is displayed. If you want to use data driven styling to customize how the locations are rendered on the map, only load the properties needed into the data source. When you want to display the detailed content, use the ID of the feature to retrieve the other content separately. If the content is stored on the server, you can reduce the amount of data that needs to be downloaded when the map is initially loaded by using a service to retrieve it asynchronously.

+Additionally, reducing the number of significant digits in the coordinates of features can also significantly reduce the data size. It isn't uncommon for coordinates to contain 12 or more decimal places; however, six decimal places have an accuracy of about 0.1 meter, which is often more precise than the location the coordinate represents (six decimal places is recommended when working with small location data such as indoor building layouts). Having any more than six decimal places will likely make no difference in how the data is rendered and requires the user to download more data for no added benefit.

+Here's a list of [useful tools for working with GeoJSON data].

+Sometimes there's a need to rapidly update data on the map for things such as showing live updates of streaming data or animating features. When a data source is updated, the rendering engine loops through and render all features in the data source. Improve overall performance by separating static from rapidly changing data into different data sources, reducing the number of features re-rendered during each update.

+The `DataSource` class also has a `tolerance` option that is used with the Douglas-Peucker simplification algorithm when reducing the resolution of geometries for rendering purposes. Increasing this tolerance value reduces the resolution of geometries and in turn improve performance. Tweak this option to get the right mix of geometry resolution and performance for your data set.

+The `DataSource` class converts raw location data into vector tiles local for on-the-fly rendering. By default, it does this until zoom level 18, at which point, when zoomed in closer, it samples data from the tiles generated for zoom level 18. This works well for most data sets that need to have high resolution when zoomed in at these levels. However, when working with data sets that are more likely to be viewed when zoomed out more, such as when viewing state or province polygons, setting the `minZoom` option of the data source to a smaller value such as `12` reduces the amount computation, local tile generation that occurs, and memory used by the data source and increase performance.

+It's possible to store GeoJSON objects inline inside of JavaScript, however this uses more memory as copies of it are stored across the variable you created for this object and the data source instance, which manages it within a separate web worker. Expose the GeoJSON to your app using a URL instead and the data source loads a single copy of data directly into the data sources web worker.

+The Azure Maps Web SDK is data driven. Data goes into data sources, which are then connected to rendering layers. If you want to change the data on the map, update the data in the data source or change the style options on a layer. This is often faster than removing, then recreating layers with every change.

+The bubble layer renders points as circles on the map and can easily have their radius and color styled using a data-driven expression. Since the circle is a simple shape for WebGL to draw, the rendering engine is able to render these faster than a symbol layer, which has to load and render an image. The performance difference of these two rendering layers is noticeable when rendering tens of thousands of points.

+Unlike most layers in the Azure Maps Web control that use WebGL for rendering, HTML Markers and Popups use traditional DOM elements for rendering. As such, the more HTML markers and Popups added a page, the more DOM elements there are. Performance can degrade after adding a few hundred HTML markers or popups. For larger data sets, consider either clustering your data or using a symbol or bubble layer. For popups, a common strategy is to create a single popup and reuse it by updating its content and position as shown in the following example:

+The map is capable of rendering hundreds of layers, however, the more layers there are, the more time it takes to render a scene. One strategy to reduce the number of layers is to combine layers that have similar styles or can be styled using a [data-driven styles].

+For example, consider a data set where all features have a `isHealthy` property that can have a value of `true` or `false`. If creating a bubble layer that renders different colored bubbles based on this property, there are several ways to do this as shown in the following list, from least performant to most performant.

+* Put all the data into a single data source and create two bubble layers with a hard-coded color option and a filter based on the `isHealthy` property.

+* Put all the data into a single data source, create a single bubble layer with a `case` style expression for the color option based on the `isHealthy` property. Here's a code sample that demonstrates this.

+* `allowOverlap` - specifies if the symbol is visible when it collides with other symbols.

+Both of these options are set to `false` by default. When animating a symbol, the collision detection calculations run on each frame of the animation, which can slow down the animation and make it look less fluid. To smooth out the animation, set these options to `true`.

+All layers have a `minZoom` and `maxZoom` option where the layer is rendered when between these zoom levels based on this logic `maxZoom > zoom >= minZoom`.

+By default, tile layers load tiles across the whole globe. However, if the tile service only has tiles for a certain area the map tries to load tiles when outside of this area. When this happens, a request for each tile is made and wait for a response that can block other requests being made by the map and thus slow down the rendering of other layers. Specifying the bounds of a tile layer results in the map only requesting tiles that are within that bounding box. Also, if the tile layer is only available between certain zoom levels, specify the min and max source zoom for the same reason.

+If a layer is overlaid on the map that completely covers the base map, consider setting the map style to `blank` or `blank_accessible` so that the base map isn't rendered. A common scenario for doing this is when overlaying a full globe tile at has no opacity or transparent area above the base map.

+If you want to animate through a series of image or tile layers on the map. It's often faster to create a layer for each image or tile layer and to change the opacity than to update the source of a single layer on each animation frame. Hiding a layer by setting the opacity to zero and showing a new layer by setting its opacity to a value greater than zero is faster than updating the source in the layer. Alternatively, the visibility of the layers can be toggled, but be sure to set the fade duration of the layer to zero, otherwise it animates the layer when displaying it, which causes a flicker effect since the previous layer would have been hidden before the new layer is visible.

+The symbol layer has two options that exist for both icon and text called `allowOverlap` and `ignorePlacement`. These two options specify if the icon or text of a symbol can overlap or be overlapped. When these are set to `false`, the symbol layer does calculations when rendering each point to see if it collides with any other already rendered symbol in the layer, and if it does, don't render the colliding symbol. This is good at reducing clutter on the map and reducing the number of objects rendered. By setting these options to `false`, this collision detection logic is skipped, and all symbols are rendered on the map. Tweak this option to get the best combination of performance and user experience.

+When working with large sets of data points you may find that when rendered at certain zoom levels, many of the points overlap and are only partial visible, if at all. Clustering is process of grouping points that are close together and representing them as a single clustered point. As the user zooms in the map, clusters break apart into their individual points. This can significantly reduce the amount of data that needs to be rendered, make the map feel less cluttered, and improve performance. The `DataSource` class has options for clustering data locally. Additionally, many tools that generate vector tiles also have clustering options.

+Additionally, increase the size of the cluster radius to improve performance. The larger the cluster radius, the less clustered points there's to keep track of and render.

+For more information, see [Clustering point data in the Web SDK].

+The heat map layer can render tens of thousands of data points easily. For larger data sets, consider enabling clustering on the data source and using a small cluster radius and use the clusters `point_count` property as a weight for the height map. When the cluster radius is only a few pixels in size, there's little visual difference in the rendered heat map. Using a larger cluster radius improves performance more but may reduce the resolution of the rendered heat map.

+For more information, see [Clustering and the heat maps layer].

+Images can be added to the maps image sprite for rendering icons in a symbol layer or patterns in a polygon layer. Keep these images small to minimize the amount of data that has to be downloaded and the amount of space they take up in the maps image sprite. When using a symbol layer that scales the icon using the `size` option, use an image that is the maximum size your plan to display on the map and no bigger. This ensures the icon is rendered with high resolution while minimizing the resources it uses. Additionally, SVGs can also be used as a smaller file format for simple icon images.

+[Data-driven style expressions] provide flexibility and power for filtering and styling data on the map. There are many ways in which expressions can be optimized. Here are a few tips.

+Expressions are often used to generate code to perform calculations or logical operations at render time. Just like the code in the rest of your application, be sure the calculations and logical make sense and aren't error prone. Errors in expressions cause issues in evaluating the expression, which can result in reduced performance and rendering issues.

+The above code functions fine if all features in the data source have a `myColor` property, and the value of that property is a color. This may not be an issue if you have complete control of the data in the data source and know for certain all features have a valid color in a `myColor` property. That said, to make this code safe from errors, a `case` expression can be used with the `has` expression to check that the feature has the `myColor` property. If it does, the `to-color` type expression can then be used to try to convert the value of that property to a color. If the color is invalid, a fallback color can be used. The following code demonstrates how to do this and sets the fallback color to green.

+Reduce the total number of conditional tests required when using boolean expressions that contain multiple conditional tests by ordering them from most to least specific.

+Expressions can be powerful and sometimes complex. The simpler an expression is, the faster it's evaluated. For example, if a simple comparison is needed, an expression like `['==', ['get', 'category'], 'restaurant']` would be better than using a match expression like `['match', ['get', 'category'], 'restaurant', true, false]`. In this case, if the property being checked is a boolean value, a `get` expression would be even simpler `['get','isRestaurant']`.

+Things to check:

+* Ensure that you complete your authentication options in the map. Without authentication, the map loads a blank canvas and returns a 401 error in the network tab of the browser's developer tools.

+* Ensure you're using a [supported browser].

+Coordinates, also referred to as positions, in the Azure Maps SDKs aligns with the geospatial industry standard format of `[longitude, latitude]`. This same format is also how coordinates are defined in the GeoJSON schema; the core data formatted used within the Azure Maps SDKs. If your data is appearing on the opposite side of the world, it's most likely due to the longitude and latitude values being reversed in your coordinate/position information.

+Check that the `anchor` and the `offset` options are configured correctly to align with the part of your image or text that you want to have aligned with the coordinate on the map.

+If the symbol is only out of place when the map is rotated, check the `rotationAlignment` option. By default, symbols rotate with the maps viewport, appearing upright to the user. However, depending on your scenario, it may be desirable to lock the symbol to the map's orientation by setting the `rotationAlignment` option to `map`.

+If the symbol is only out of place when the map is pitched/tilted, check the `pitchAlignment` option. By default, symbols stay upright in the maps viewport when the map is pitched or tilted. However, depending on your scenario, it may be desirable to lock the symbol to the map's pitch by setting the `pitchAlignment` option to `map`.

+* Add break points in your code and step through it. Ensure data is added to the data source and the data source and layers are added to the map.

+Report issues using the [Azure Maps feedback] site. Detailed instructions on reporting data issues are provided in the [Provide data feedback to Azure Maps] article.

+Report issues on Azure's [Help + support] page by selecting the **Create a support request** button.

+* For questions related to the Azure Maps Power BI visual, contact [Power BI support].

+* For all other Azure Maps services, contact [Azure support].

+* For question or comments on specific Azure Maps Features, use the [Azure Maps developer forums].

+> [Make your application accessible]

+> [Azure Maps glossary]

+[Authentication and authorization best practices]: authentication-best-practices.md

+[awesome-vector-tiles]: https://github.com/mapbox/awesome-vector-tiles#awesome-vector-tiles-

+[Azure Maps Creator platform]: creator-indoor-maps.md

+[Azure Maps developer forums]: /answers/topics/azure-maps.html

+[Azure Maps feedback]: https://feedback.azuremaps.com

+[Azure Maps glossary]: glossary.md

+[Azure support]: https://azure.com/support

+[azure-maps-control]: https://www.npmjs.com/package/azure-maps-control?activeTab=versions

+[bug]: https://bugs.webkit.org/show_bug.cgi?id=170075

+[Clustering and the heat maps layer]: clustering-point-data-web-sdk.md#clustering-and-the-heat-maps-layer

+[Clustering point data in the Web SDK]: clustering-point-data-web-sdk.md

+[Create a data source]: create-data-source-web-sdk.md

+[Data-driven style expressions]: data-driven-style-expressions-web-sdk.md

+[data-driven styles]: data-driven-style-expressions-web-sdk.md

+[Help + support]: https://portal.azure.com/#blade/Microsoft_Azure_Support/HelpAndSupportBlade/overview

+[Make your application accessible]: map-accessibility.md

+[Power BI support]: https://powerbi.microsoft.com/support

+[Provide data feedback to Azure Maps]: how-to-use-feedback-tool.md

+[supported browser]: supported-browsers.md

+[Tippecanoe]: https://github.com/mapbox/tippecanoe

+[useful tools for working with GeoJSON data]: https://github.com/tmcw/awesome-geojson

+|operation_ParentId|string|ParentId|string|

+|operation_ParentId|string|ParentId|string|

+|operation_ParentId|string|ParentId|string|

+|operation_ParentId|string|ParentId|string|

+|operation_ParentId|string|ParentId|string|

+|operation_ParentId|string|ParentId|string|

+|operation_ParentId|string|ParentId|string|

+|operation_ParentId|string|ParentId|string|

+|operation_ParentId|string|ParentId|string|

+Set the key in an initialization method, such as `global.asax.cs`, in an ASP.NET service:

+1. Select **Access configuration**.

+ :::image type="content" source="./media/key-vault-access/select-access-configuration.png" alt-text="Screenshot of the key vault setting to select access configuration.":::

+1. Select **Azure Resource Manager for template deployment**. Then, select **Apply**.

+ :::image type="content" source="./media/key-vault-access/enable-template.png" alt-text="Screenshot of the key vault's access configuration that enables Azure Resource Manager for template deployment.":::

+Assign the **Contributor** role to the **Appliance Resource Provider** user at the key vault scope. For detailed steps, go to [Assign Azure roles using the Azure portal](../../role-based-access-control/role-assignments-portal.md).

+The **Appliance Resource Provider** is a service principal in your Azure Active Directory's tenant. From the Azure portal, you can verify if it's registered by going to **Azure Active Directory** > **Enterprise applications** and change the search filter to **Microsoft Applications**. Search for _Appliance Resource Provider_. If it's not found, [register](../troubleshooting/error-register-resource-provider.md) the `Microsoft.Solutions` resource provider.

+ "apiVersion": "2022-09-01",

+ "apiVersion": "2022-05-01-preview",

+- For information about passing a value from a Key Vault as a template parameter, go to [Use Azure Key Vault to pass secure parameter value during deployment](../templates/key-vault-parameter.md).

+- To learn more about key vault security, go to [Azure Key Vault security](../../key-vault/general/security-features.md) and [Authentication in Azure Key Vault](../../key-vault/general/authentication.md).

+- For managed application examples, go to [Sample projects for Azure managed applications](sample-projects.md).

+- To learn how to create a UI definition file for a managed application, go to [Get started with CreateUiDefinition](create-uidefinition-overview.md).

+ Title: Monitoring Azure Video Indexer data reference

+ Title: Monitoring Azure Video Indexer

+description: Start here to learn how to monitor Azure Video Indexer

+## April 2023

+Introducing run commands for HCX on Azure VMware solutions. You can use these run commands to restart HCX cloud manager in your Azure VMware solution private cloud. Additionally, you can also scale HCX cloud manager using run commands. To learn how to use run commands for HCX, see [Use HCX Run commands](use-hcx-run-commands.md).

+- [Use HCX Run commands](use-hcx-run-commands.md)

+# Connect to a VM via specified private IP address

+## Connect to VM - Azure portal

+## Connect to VM - native client

+You can connect to VMs using a specified IP address with native client via SSH, RDP, or tunnelling. Note that this feature does not support Azure Active Directory authentication or custom port and protocol at the moment. To learn more about configuring native client support, see [Connect to a VM - native client](connect-native-client-windows.md). Use the following commands as examples:

+ **RDP:**

+

+ ```azurecli

+ az network bastion rdp --name "<BastionName>" --resource-group "<ResourceGroupName>" --target-ip-address "<VMIPAddress>

+ ```

+

+ **SSH:**

+

+ ```azurecli

+ az network bastion ssh --name "<BastionName>" --resource-group "<ResourceGroupName>" --target-ip-addres "<VMIPAddress>" --auth-type "ssh-key" --username "<Username>" --ssh-key "<Filepath>"

+ ```

+

+ **Tunnel:**

+

+ ```azurecli

+ az network bastion tunnel --name "<BastionName>" --resource-group "<ResourceGroupName>" --target-ip-address "<VMIPAddress>" --resource-port "<TargetVMPort>" --port "<LocalMachinePort>"

+ ```

+Read the [Bastion FAQ](bastion-faq.md) for additional information.

+## <a name="connect-IP"></a>Connect to VM - IP Address

+This section helps you connect to your on-premises, non-Azure, and Azure virtual machines via Azure Bastion using a specified private IP address from native client. You can replace `--target-resource-id` with `--target-ip-address` in any of the above commands with the specified IP address to connect to your VM.

+> [!Note]

+> This feature does not support support Azure AD authentication or custom port and protocol at the moment. For more information on IP-based connection, see [Connect to a VM - IP address](connect-ip-address.md).

+Use the following commands as examples:

+ **RDP:**

+

+ ```azurecli

+ az network bastion rdp --name "<BastionName>" --resource-group "<ResourceGroupName>" --target-ip-address "<VMIPAddress>

+ ```

+

+ **SSH:**

+

+ ```azurecli

+ az network bastion ssh --name "<BastionName>" --resource-group "<ResourceGroupName>" --target-ip-addres "<VMIPAddress>" --auth-type "ssh-key" --username "<Username>" --ssh-key "<Filepath>"

+ ```

+

+ **Tunnel:**

+

+ ```azurecli

+ az network bastion tunnel --name "<BastionName>" --resource-group "<ResourceGroupName>" --target-ip-address "<VMIPAddress>" --resource-port "<TargetVMPort>" --port "<LocalMachinePort>"

+ ```

+ Title: Autoscale compute nodes in an Azure Batch pool

+description: Enable automatic scaling on an Azure Batch cloud pool to dynamically adjust the number of compute nodes in the pool.

+# Create a formula to automatically scale compute nodes in a Batch pool

+To enable automatic scaling on a pool of compute nodes, you associate the pool with an *autoscale formula* that you define. The Batch service uses the autoscale formula to determine how many nodes are needed to execute your workload. These nodes can be dedicated nodes or [Azure Spot nodes](batch-spot-vms.md). Batch periodically reviews service metrics data and uses it to adjust the number of nodes in the pool based on your formula and at an interval that you define.

+You can enable automatic scaling when you create a pool, or apply it to an existing pool. Batch lets you evaluate your formulas before assigning them to pools and to monitor the status of automatic scaling runs. Once you configure a pool with automatic scaling, you can make changes to the formula later.

+> When you create a Batch account, you can specify the [pool allocation mode](accounts.md), which determines whether pools are allocated in a Batch service subscription (the default) or in your user subscription. If you created your Batch account with the default Batch service configuration, then your account is limited to a maximum number of cores that can be used for processing. The Batch service scales compute nodes only up to that core limit. For this reason, the Batch service might not reach the target number of compute nodes specified by an autoscale formula. To learn how to view and increase your account quotas, see [Quotas and limits for the Azure Batch service](batch-quota-limit.md).

+You can think of automatic scaling formulas as a Batch autoscale "language." Formula statements are free-formed expressions that can include both *service-defined variables*, which are defined by the Batch service, and *user-defined variables*. Formulas can perform various operations on these values by using built-in types, operators, and functions. For example, a statement might take the following form:

+Formulas generally contain multiple statements that perform operations on values that are obtained in previous statements. For example, first you obtain a value for `variable1`, then pass it to a function to populate `variable2`:

+The target number of nodes might be higher, lower, or the same as the current number of nodes of that type in the pool. Batch evaluates a pool's autoscale formula at specific [automatic scaling intervals](#automatic-scaling-interval). Batch adjusts the target number of each type of node in the pool to the number that your autoscale formula specifies at the time of evaluation.

+The following examples show two autoscale formulas, which can be adjusted to work for most scenarios. The variables `startingNumberOfVMs` and `maxNumberofVMs` in the example formulas can be adjusted to your needs.

+This example creates a pool that starts with 25 Spot nodes. Every time a Spot node is preempted, it's replaced with a dedicated node. As with the first example, the `maxNumberofVMs` variable prevents the pool from exceeding 25 VMs. This example is useful for taking advantage of Spot VMs while also ensuring that only a fixed number of preemptions occur for the lifetime of the pool.

+You'll learn more about [how to create autoscale formulas](#write-an-autoscale-formula) and see more [example autoscale formulas](#example-autoscale-formulas) later in this article.

+You can use both *service-defined* and *user-defined* variables in your autoscale formulas.

+User-defined variables are variables that you define. In the previous example, `$TargetDedicatedNodes` and `$PendingTasks` are service-defined variables, while `startingNumberOfVMs` and `maxNumberofVMs` are user-defined variables.

+| $TargetDedicatedNodes |The target number of dedicated compute nodes for the pool. Specified as a target because a pool might not always achieve the desired number of nodes. For example, if the target number of dedicated nodes is modified by an autoscale evaluation before the pool has reached the initial target, the pool might not reach the target. <br><br> A pool in an account created in Batch service mode might not achieve its target if the target exceeds a Batch account node or core quota. A pool in an account created in user subscription mode might not achieve its target if the target exceeds the shared core quota for the subscription.|

+| $TargetLowPriorityNodes |The target number of Spot compute nodes for the pool. Specified as a target because a pool might not always achieve the desired number of nodes. For example, if the target number of Spot nodes is modified by an autoscale evaluation before the pool has reached the initial target, the pool might not reach the target. A pool might also not achieve its target if the target exceeds a Batch account node or core quota. <br><br> For more information on Spot compute nodes, see [Use Spot VMs with Batch](batch-spot-vms.md). |

+| $NodeDeallocationOption |The action that occurs when compute nodes are removed from a pool. Possible values are:<br>- **requeue**: The default value. Ends tasks immediately and puts them back on the job queue so that they're rescheduled. This action ensures the target number of nodes is reached as quickly as possible. However, it might be less efficient, because any running tasks are interrupted and then must be restarted. <br>- **terminate**: Ends tasks immediately and removes them from the job queue.<br>- **taskcompletion**: Waits for currently running tasks to finish and then removes the node from the pool. Use this option to avoid tasks being interrupted and requeued, wasting any work the task has done.<br>- **retaineddata**: Waits for all the local task-retained data on the node to be cleaned up before removing the node from the pool. |

+> The `$TargetDedicatedNodes` variable can also be specified using the alias `$TargetDedicated`. Similarly, the `$TargetLowPriorityNodes` variable can be specified using the alias `$TargetLowPriority`. If both the fully named variable and its alias are set by the formula, the value assigned to the fully named variable takes precedence.

+> Job release tasks aren't currently included in variables that provide task counts, such as `$ActiveTasks` and `$PendingTasks`. Depending on your autoscale formula, this can result in nodes being removed with no nodes available to run job release tasks.

+| $ActiveTasks |The number of tasks that are ready to execute but aren't yet executing. This includes all tasks that are in the active state and whose dependencies have been satisfied. Any tasks that are in the active state but whose dependencies haven't been satisfied are excluded from the `$ActiveTasks` count. For a multi-instance task, `$ActiveTasks` includes the number of instances set on the task.|

+| $PendingTasks |The sum of `$ActiveTasks` and `$RunningTasks`. |

+> `$PreemptedNodeCount` is currently not available and returns `0` valued data.

+You can use these predefined *functions* when defining an autoscale formula.

+You can use both resource and task metrics when you define a formula. You adjust the target number of dedicated nodes in the pool based on the metrics data that you obtain and evaluate. For more information on each metric, see the [Variables](#variables) section.

+| Metric | Description |

+|-|--|

+| Resource | Resource metrics are based on the CPU, the bandwidth, the memory usage of compute nodes, and the number of nodes.<br><br>These service-defined variables are useful for making adjustments based on node count:<br>- $TargetDedicatedNodes <br>- $TargetLowPriorityNodes <br>- $CurrentDedicatedNodes <br>- $CurrentLowPriorityNodes <br>- $PreemptedNodeCount <br>- $SampleNodeCount <br><br>These service-defined variables are useful for making adjustments based on node resource usage: <br>- $CPUPercent <br>- $WallClockSeconds <br>- $MemoryBytes <br>- $DiskBytes <br>- $DiskReadBytes <br>- $DiskWriteBytes <br>- $DiskReadOps <br>- $DiskWriteOps <br>- $NetworkInBytes <br>- $NetworkOutBytes |

+| Task | Task metrics are based on the status of tasks, such as Active, Pending, and Completed. The following service-defined variables are useful for making pool-size adjustments based on task metrics: <br>- $ActiveTasks <br>- $RunningTasks <br>- $PendingTasks <br>- $SucceededTasks <br>- $FailedTasks |

+The core operation of an autoscale formula is to obtain task and resource metrics data (samples), and then adjust pool size based on that data. As such, it's important to have a clear understanding of how autoscale formulas interact with samples.

+Autoscale formulas act on samples of metric data provided by the Batch service. A formula grows or shrinks the pool compute nodes based on the values that it obtains. Service-defined variables are objects that provide methods to access data that's associated with that object. For example, the following expression shows a request to get the last five minutes of CPU usage:

+The following methods can be used to obtain sample data about service-defined variables.

+| GetSample() |The `GetSample()` method returns a vector of data samples.<br><br>A sample is 30 seconds worth of metrics data. In other words, samples are obtained every 30 seconds. But as noted below, there's a delay between when a sample is collected and when it's available to a formula. As such, not all samples for a given time period might be available for evaluation by a formula. <br><br>- `doubleVec GetSample(double count)`: Specifies the number of samples to obtain from the most recent samples that were collected. `GetSample(1)` returns the last available sample. For metrics like `$CPUPercent`, however, `GetSample(1)` shouldn't be used, because it's impossible to know *when* the sample was collected. It could be recent, or, because of system issues, it might be much older. In such cases, it's better to use a time interval as shown below.<br><br>- `doubleVec GetSample((timestamp or timeinterval) startTime [, double samplePercent])`: Specifies a time frame for gathering sample data. Optionally, it also specifies the percentage of samples that must be available in the requested time frame. For example, `$CPUPercent.GetSample(TimeInterval_Minute * 10)` would return 20 samples if all samples for the last 10 minutes are present in the `CPUPercent` history. If the last minute of history wasn't available, only 18 samples would be returned. In this case `$CPUPercent.GetSample(TimeInterval_Minute * 10, 95)` would fail because only 90 percent of the samples are available, but `$CPUPercent.GetSample(TimeInterval_Minute * 10, 80)` would succeed.<br><br>- `doubleVec GetSample((timestamp or timeinterval) startTime, (timestamp or timeinterval) endTime [, double samplePercent])`: Specifies a time frame for gathering data, with both a start time and an end time. As mentioned above, there's a delay between when a sample is collected and when it becomes available to a formula. Consider this delay when you use the `GetSample` method. See `GetSamplePercent` below. |

+| Count() |Returns the total number of samples in the metrics history. |

+The Batch service periodically takes samples of task and resource metrics and makes them available to your autoscale formulas. These samples are recorded every 30 seconds by the Batch service. However, there's typically a delay between when those samples were recorded and when they're made available to (and read by) your autoscale formulas. Additionally, samples might not be recorded for a particular interval because of factors such as network or other infrastructure issues.

+When `samplePercent` is passed to the `GetSample()` method or the `GetSamplePercent()` method is called, *percent* refers to a comparison between the total possible number of samples recorded by the Batch service and the number of samples that are available to your autoscale formula.

+Let's look at a 10-minute time span as an example. Because samples are recorded every 30 seconds within that 10-minute time span, the maximum total number of samples recorded by Batch would be 20 samples (2 per minute). However, due to the inherent latency of the reporting mechanism and other issues within Azure, there might be only 15 samples that are available to your autoscale formula for reading. So, for example, for that 10-minute period, only 75 percent of the total number of samples recorded might be available to your formula.

+Your autoscale formulas grow and shrink your pools by adding or removing nodes. Because nodes cost you money, be sure that your formulas use an intelligent method of analysis that's based on sufficient data. It's recommended that you use a trending-type analysis in your formulas. This type grows and shrinks your pools based on a range of collected samples.

+After you collect the vector of samples, you can then use functions like `min()`, `max()`, and `avg()` to derive meaningful values from the collected range.

+Because there might be a delay in sample availability, you should always specify a time range with a look-back start time that's older than one minute. It takes approximately one minute for samples to propagate through the system, so samples in the range `(0 * TimeInterval_Second, 60 * TimeInterval_Second)` might not be available. Again, you can use the percentage parameter of `GetSample()` to force a particular sample percentage requirement.

+> We strongly recommend that you **avoid relying *only* on `GetSample(1)` in your autoscale formulas**. This is because `GetSample(1)` essentially says to the Batch service, "Give me the last sample you have, no matter how long ago you retrieved it." Since it's only a single sample, and it might be an older sample, it might not be representative of the larger picture of recent task or resource state. If you do use `GetSample(1)`, make sure that it's part of a larger statement and not the only data point that your formula relies on.

+You build an autoscale formula by forming statements that use the above components, then combine those statements into a complete formula. In this section, you create an example autoscale formula that can perform real-world scaling decisions and make adjustments.

+The first statement in the formula increases the number of nodes during high CPU usage. You define a statement that populates a user-defined variable (`$totalDedicatedNodes`) with a value that is 110 percent of the current target number of dedicated nodes, but only if the minimum average CPU usage during the last 10 minutes was above 70 percent. Otherwise, it uses the value for the current number of dedicated nodes.

+To decrease the number of dedicated nodes during low CPU usage, the next statement in the formula sets the same `$totalDedicatedNodes` variable to 90 percent of the current target number of dedicated nodes, if average CPU usage in the past 60 minutes was under 20 percent. Otherwise, it uses the current value of `$totalDedicatedNodes` populated in the statement above.

+Now, limit the target number of dedicated compute nodes to a maximum of 400.

+$TargetDedicatedNodes = min(400, $totalDedicatedNodes);

+Finally, ensure that nodes aren't removed until their tasks are finished.

+$TargetDedicatedNodes = min(400, $totalDedicatedNodes);

+> If you choose, you can include both comments and line breaks in formula strings. Also be aware that missing semicolons might result in evaluation errors.

+1. Set the [CloudPool.AutoScaleEnabled](/dotnet/api/microsoft.azure.batch.cloudpool.autoscaleenabled) property to **true**.

+> When you create an autoscale-enabled pool, don't specify the *targetDedicatedNodes* parameter or the *targetLowPriorityNodes* parameter on the call to `CreatePool`. Instead, specify the `AutoScaleEnabled` and `AutoScaleFormula` properties on the pool. The values for these properties determine the target number of each type of node.

+> [!TIP]

+> For more examples of using the .NET SDK, see the [Batch .NET Quickstart repository](https://github.com/Azure-Samples/batch-dotnet-quickstart) on GitHub.

+To create an autoscale-enabled pool with the Python SDK:

+> For more examples of using the Python SDK, see the [Batch Python Quickstart repository](https://github.com/Azure-Samples/batch-python-quickstart) on GitHub.

+> If you specified values for the *targetDedicatedNodes* or *targetLowPriorityNodes* parameters of the `CreatePool` method when you created the pool in .NET, or for the comparable parameters in another language, then those values are ignored when the autoscale formula is evaluated.

+The following [Batch .NET](/dotnet/api/microsoft.azure.batch) example evaluates an autoscale formula. If the pool doesn't already use autoscaling, enable it first.

+ // You need a valid autoscale formula to enable autoscaling on the

+ // Because you want to apply our new autoscale formula below if it

+ // evaluates successfully, and you *just* enabled autoscaling on

+ // this pool, pause here to ensure you pass that threshold.

+// You must ensure that autoscaling is enabled on the pool prior to

+It's recommended to periodically check the Batch service's evaluation of your autoscale formula. To do so, get (or refresh) a reference to the pool, then examine the properties of its last autoscale run.

+In the REST API, the [Get information about a pool request](/rest/api/batchservice/get-information-about-a-pool) returns information about the pool, which includes the latest automatic scaling run information in the [autoScaleRun](/rest/api/batchservice/get-information-about-a-pool) property.

+The following C# example uses the Batch .NET library to print information about the last autoscaling run on pool *myPool*.

+`$curTime` can be adjusted to reflect your local time zone by adding `time()` to the product of `TimeZoneInterval_Hour` and your UTC offset. For instance, use `$curTime = time() + (-6 * TimeInterval_Hour);` for Mountain Daylight Time (MDT). Keep in mind that the offset needs to be adjusted at the start and end of daylight saving time, if applicable.

+In this C# example, the pool size is adjusted based on the number of tasks in the queue. Both comments and line breaks are included in the formula strings.

+// If you have fewer than 70 percent data points, use the last sample point,

+// otherwise use the maximum of last sample point and the history average.

+This C# example adjusts the pool size based on the number of tasks. This formula also takes into account the [TaskSlotsPerNode](/dotnet/api/microsoft.azure.batch.cloudpool.taskslotspernode) value that's been set for the pool. This approach is useful in situations where [parallel task execution](batch-parallel-node-tasks.md) has been enabled on your pool.

+ - If both values are 0, indicating that no tasks were running or active in the last 60 minutes, the pool size is set to 0.

+- Learn how to [query the Azure Batch service efficiently](batch-efficient-list-queries.md).

+ Title: Data Loss Prevention

+description: Cognitive Services Data Loss Prevention capabilities allow customers to configure the list of outbound URLs their Cognitive Services resources are allowed to access. This configuration creates another level of control for customers to prevent data loss.

+ Title: What's new in Azure Communication Services

+description: All of the latest additions to Azure Communication Services

+> The above table covers stable Dapr APIs. To learn more about using alpha APIs and features, [see the Dapr FAQ][dapr-faq].

+- **Alpha APIs and components**: Azure Container Apps doesn't guarantee the availability of Dapr alpha APIs and features. For more information, refer to the [Dapr FAQ][dapr-faq].

+- [Answer common questions about the Dapr integration with Azure Container Apps][dapr-faq]

+[dapr-faq]: ./faq.yml#dapr

+Currently, you can restore an Azure Cosmos DB account (API for NoSQL or MongoDB, API for Table, API for Gremlin) contents at a specific point in time to another account. You can perform this restore operation via the [Azure portal](restore-account-continuous-backup.md#restore-account-portal), the [Azure CLI](restore-account-continuous-backup.md#restore-account-cli) (Azure CLI), [Azure PowerShell](restore-account-continuous-backup.md#restore-account-powershell), or [Azure Resource Manager templates](restore-account-continuous-backup.md#restore-arm-template).

+Azure Cosmos DB allows you to isolate and restrict the restore permissions for continuous backup account to a specific role or a principal. These permissions can be applied at the subscription scope or more granularly at the source account scope as shown in the following image:

+To perform a restore, a user or a principal need the permission to restore (that is *restore/action* permission), and permission to provision a new account (that is *write* permission). To grant these permissions, the owner of the subscription can assign the `CosmosRestoreOperator` and `Cosmos DB Operator` built in roles to a principal.

+- Assign the `CosmosRestoreOperator` built in role to the specific subscription level

+### Assign capability to restore from a specific account

+- Assign a user write action on the specific resource group. This action is required to create a new account in the resource group.

+- Assign the `CosmosRestoreOperator` built in role to the specific restorable database account that needs to be restored. In the following command, the scope for the `RestorableDatabaseAccount` is extracted from the `ID` property of result of execution of `az cosmosdb restorable-database-account list`(if using CLI) or `Get-AzCosmosDBRestorableDatabaseAccount`(if using the PowerShell)

+```azurecli-interactive

+az role assignment create --role "CosmosRestoreOperator" --assignee <email> --scope <RestorableDatabaseAccount>

+```

+For example, consider a scenario where Backup Retention is configured to **240 hrs** (or **10 days**) and Backup Interval is configured to **24 hours**. This configuration implies that there are **10** copies of the backup data. If you have **1 TB** of data in an Azure West US region, the cost for backup storage in a given month would be: `0.12 * 1000 * 8`

+- [**Azure savings plans**](./savings-plan/index.yml) save you money when you have consistent usage of Azure compute resources. A savings plan can significantly reduce your resource costs by up to 65% from pay-as-you-go prices.

+5. Select the checkboxes for every resource you want to link and then select the **Assign tags** command.

+Cost analysis is available from every management group, subscription, resource group, and billing scope in the Azure portal and the Microsoft 365 admin center. To make cost data more readily accessible for resource owners, you can now find a **View cost** link at the top-right of every resource overview screen, in **Essentials**. Select the link to open classic cost analysis with a resource filter applied.

+> Exchanges will be unavailable for all compute reservations - Azure Reserved Virtual Machine Instances, Azure Dedicated Host reservations, and Azure App Services reservations - purchased on or after **January 1, 2024**. Compute reservations purchased **prior to January 1, 2024** will reserve the right to **exchange one more time** after the policy change goes into effect. Microsoft launched Azure savings plan for compute and it's designed to help you save broadly on predictable compute usage. The savings plan provides more flexibility needed to accommodate changes such as virtual machine series and regions. With savings plan providing the flexibility automatically, we’re adjusting our reservations exchange policy. You can continue to use instance size flexibility for VM sizes, but we'll no longer support exchanging instance series or regions for Azure Reserved Virtual Machine Instances, Azure Dedicated Host reservations, and Azure App Services reservations. For more information about the exchange policy change, see [Changes to the Azure reservation exchange policy](reservation-exchange-policy-changes.md).

+You can continue to use instance size flexibility for VM sizes, but Microsoft is ending exchanges for regions and instance series for these Azure compute reservations.

+> Exchanges will be unavailable for all compute reservations - Azure Reserved Virtual Machine Instances, Azure Dedicated Host reservations, and Azure App Services reservations - purchased on or after **January 1, 2024**. Compute reservations purchased **prior to January 1, 2024** will reserve the right to **exchange one more time** after the policy change goes into effect. Azure savings plan for compute is designed to help you save broadly on predictable compute usage. The savings plan provides more flexibility needed to accommodate changes such as virtual machine series and regions. With savings plan providing the flexibility automatically, we’re adjusting our reservations exchange policy. You can continue to use instance size flexibility for VM sizes, but we'll no longer support exchanging instance series or regions for Azure Reserved Virtual Machine Instances, Azure Dedicated Host reservations, and Azure App Services reservations.

+1. When the file is ready to download, select **Download**. If you missed the notification, you can view it from **Notifications** area in top right of the Azure portal (the bell symbol).

+Similar to derived columns and aggregates, this is where you'll either modify an existing column by selecting it from the drop-down picker. Or you can type in the name of a new column here. ADF will store the parsed source data in this column. In most cases, you'll want to define a new column that parses the incoming embedded document string field.

+> [!NOTE]

+> This feature is now generally available in the ADF studio.

+> This feature is now generally available in the ADF studio.

+The default monitoring view has been simplified with fewer default columns. You can add/remove columns if youΓÇÖd like to personalize your monitoring view. Changes to the default will be cached.

+You can also now view **Pipeline run details** in a new pane in the detailed pipeline monitoring view by clicking **View run detail**.

+ Title: What is Microsoft Azure Data Manager for Agriculture?

+description: About Azure Data Manager for Agriculture

+ > [!NOTE]

+ > If your datacenter firewall is restricting or filtering traffic based on source IPs or MAC addresses, make sure that the compute IPs (Kubernetes node IPs) and MAC addresses are on the allowed list. The MAC addresses can be specified by running the `Set-HcsMacAddressPool` cmdlet on the PowerShell interface of the device.

+For more information, see:

+- [Alert data retention](references-data-retention.md#alert-data-retention)

+- [Accelerating OT alert workflows](#accelerating-ot-alert-workflows)

+- [Alert statuses and triaging options](alerts.md#alert-statuses-and-triaging-options)

+In a star network such as the one shown in the diagram below, every host is connected to a central hub. In its simplest form, one central hub acts as a conduit to transmit messages. In the following example, lower switches aren't monitored, and traffic that remains local to these switches won't be seen. Devices might be identified based on ARP messages, but connection information will be missing.

+The following diagram is a general abstraction of a multilayer, multi-tenant network, with an expansive cybersecurity ecosystem typically operated by an security operations center (SOC) and managed security service provider (MSSP). Defender for IoT sensors are typically deployed in layers 0 to 3 of the OSI model.

+For more information, see [Traffic mirroring methods for OT monitoring](traffic-mirroring-methods.md).

+ Title: Compliance - Microsoft Defender for IoT

+description: Learn about compliance resources for Microsoft Defender for IoT.

+# Microsoft Defender for IoT compliance resources

+Defender for IoT cloud services, formerly named *Azure Defender for IoT* or *Azure Security for IoT*, are based on Microsoft AzureΓÇÖs infrastructure, which meets demanding US government and international compliance requirements that produce formal authorizations.

+## Provisional authorizations

+

+Defender for IoT is in scope for the following provisional authorizations in Azure and Azure Government:

+- [FedRAMP High](/azure/compliance/offerings/offering-fedramp)

+- [DoD IL2](/azure/compliance/offerings/offering-dod-il2)

+Moreover, Defender for IoT maintains extra [DoD IL4](/azure/compliance/offerings/offering-dod-il4) and [DoD IL5](/azure/compliance/offerings/offering-dod-il5) provisional authorizations in Azure Government.

+For more information, see [Azure and other Microsoft cloud services compliance scope](/azure/azure-government/compliance/azure-services-in-fedramp-auditscope#azure-public-services-by-audit-scope).

+## Accessibility

+Defender for IoT is committed to developing technology that empowers everyone, including people with disabilities, and helps customers address global accessibility requirements.

+For more information, search for *Azure Security for IoT* in [Accessibility Conformance Reports | Microsoft Accessibility](https://www.microsoft.com/accessibility/conformance-reports?rtc=1).

+## Cloud compliance

+Defender for IoT helps customers meet their compliance obligations across regulated industries and markets worldwide.

+For more information, see [Azure and other Microsoft cloud services compliance offerings](/azure/compliance/offerings/).

+## Next steps

+> [!div class="nextstepaction"]

+> [Welcome to Microsoft Defender for IoT for organizations](overview.md)

+- [Defender for IoT device inventory](device-inventory.md)

+- [Defender for IoT device inventory](device-inventory.md)

+- [Defender for IoT device inventory](device-inventory.md)

+> [Manage OT sensors from the sensor console](how-to-manage-individual-sensors.md)

+The OT sensor's event timeline provides a chronological view and context of all network activity, to help determine the cause and effect of incidents. The timeline view makes it easy to extract information from network events, and more efficiently analyze alerts and events observed on the network. With the ability to store vast amounts of data, the event timeline view can be a valuable resource for security teams to perform investigations and gain a deeper understanding of network activity.

+For more information, see:

+Before you perform the procedures described in this article, make sure that you have access to an OT sensor as an **Admin** or **Security Analyst** role. For more information, see [On-premises users and roles for OT monitoring with Defender for IoT](roles-on-premises.md).

+For more information, see:

+- [Audit user activity](track-user-activity.md)

+- [View details and remediate a specific alert](how-to-view-alerts.md#view-details-and-remediate-a-specific-alert)

+- [Analyze programming details and changes](how-to-analyze-programming-details-changes.md)

+| **OT networks** | **Sensor version 22.3.6/22.3.7**: <br>- [Support for transient devices](#support-for-transient-devices)<br>- [Learn DNS traffic by configuring allowlists](#learn-dns-traffic-by-configuring-allowlists)<br>- [Device data retention updates](#device-data-retention-updates)<br>- [UI enhancements when uploading SSL/TLS certificates](#ui-enhancements-when-uploading-ssltls-certificates)<br>- [Activation files expiration updates](#activation-files-expiration-updates)<br>- [UI enhancements for managing the device inventory](#ui-enhancements-for-managing-the-device-inventory)<br>- [Updated severity for all Suspicion of Malicious Activity alerts](#updated-severity-for-all-suspicion-of-malicious-activity-alerts)<br>- [Automatically resolved device notifications](#automatically-resolved-device-notifications) <br><br>Version 22.3.7 includes the same features as 22.3.6. If you have version 22.3.6 installed, we strongly recommend that you update to version 22.3.7, which also includes important bug fixes.<br><br> **Cloud features**: <br>- [New Microsoft Sentinel incident experience for Defender for IoT](#new-microsoft-sentinel-incident-experience-for-defender-for-iot) |

+ Title: Microsoft Azure Data Manager for Energy Preview csv parser ingestion workflow concept

+description: Learn how to use CSV parser ingestion.

+ Title: Domain data management services concepts

+description: Learn how to use Domain Data Management Services

+ Title: Microsoft Azure Data Manager for Energy Preview entitlement concepts

+description: This article describes the various concepts regarding the entitlement services in Azure Data Manager for Energy Preview

+ Title: Microsoft Azure Data Manager for Energy Preview - index and search workflow concepts

+description: Learn how to use indexing and search workflows

+ Title: Microsoft Azure Data Manager for Energy Preview manifest ingestion concepts

+description: This article describes manifest ingestion concepts

+ Title: Microsoft Azure Data Manager for Energy Preview - How to convert a segy to ovds file

+description: This article explains how to convert a SGY file to oVDS file format

+ Title: Microsoft Azure Data Manager for Energy Preview - How to convert segy to zgy file

+description: This article describes how to convert a SEG-Y file to a ZGY file

+ Title: How to enable CORS - Azure Data Manager for Energy Preview

+description: Guide on CORS in Azure data manager for Energy and how to set up CORS

+ Title: How to generate a refresh token for Microsoft Azure Data Manager for Energy Preview

+description: This article describes how to generate a refresh token

+ Title: Data security and encryption in Microsoft Azure Data Manager for Energy Preview

+description: Guide on security in Azure Data Manager for Energy Preview and how to set up customer managed keys on Azure Data Manager for Energy Preview

+ Title: How to manage legal tags in Microsoft Azure Data Manager for Energy Preview

+description: This article describes how to manage legal tags in Azure Data Manager for Energy Preview

+ Title: How to manage users in Microsoft Azure Data Manager for Energy Preview

+description: This article describes how to manage users in Azure Data Manager for Energy Preview

+ Title: Overview of domain data management services - Microsoft Azure Data Manager for Energy Preview

+description: This article provides an overview of Domain data management services

+ Title: What is Microsoft Azure Data Manager for Energy Preview?

+description: This article provides an overview of Azure Data Manager for Energy Preview

+ Title: Create a Microsoft Azure Data Manager for Energy Preview instance

+description: Quickly create an Azure Data Manager for Energy Preview instance

+ Title: Release notes for Microsoft Azure Data Manager for Energy Preview

+description: This article provides release notes of Azure Data Manager for Energy Preview releases, improvements, bug fixes, and known issues.

+ Title: Microsoft Azure Data Manager for Energy Preview - Steps to perform a CSV parser ingestion

+description: This tutorial shows you how to perform CSV parser ingestion

+ Title: Microsoft Azure Data Manager for Energy Preview - Steps to perform a manifest-based file ingestion

+description: This tutorial shows you how to perform Manifest ingestion

+ Title: Microsoft Azure Data Manager for Energy Preview - Seismic store sdutil tutorial

+description: Information on setting up and using sdutil, a command-line interface (CLI) tool that allows users to easily interact with seismic store.

+ Title: Tutorial - Sample steps to interact with Seismic DDMS in Microsoft Azure Data Manager for Energy Preview

+description: This tutorial shows you how to interact with Seismic DDMS Azure Data Manager for Energy Preview

+export PASSWORD='PASSWORD'

+export CLUSTER_NAME=$(curl -u admin:$PASSWORD -sS -G "https://CLUSTERNAME.azurehdinsight.net/api/v1/clusters" | jq -r '.items[].Clusters.cluster_name')

+echo $CLUSTER_NAME

+ curl -u admin:$PASSWORD -G https://$CLUSTER_NAME.azurehdinsight.net/templeton/v1/status

+ curl -u admin:$PASSWORD -G https://$CLUSTER_NAME.azurehdinsight.net/templeton/v1/version/hive

+ JOB_ID=$(curl -s -u admin:$PASSWORD -d user.name=admin -d execute="DROP+TABLE+log4jLogs;CREATE+EXTERNAL+TABLE+log4jLogs(t1+string,t2+string,t3+string,t4+string,t5+string,t6+string,t7+string)+ROW+FORMAT+DELIMITED+FIELDS+TERMINATED+BY+' '+STORED+AS+TEXTFILE+LOCATION+'/example/data/';SELECT+t4+AS+sev,COUNT(*)+AS+count+FROM+log4jLogs+WHERE+t4+=+'[ERROR]'+AND+INPUT__FILE__NAME+LIKE+'%25.log'+GROUP+BY+t4;" -d statusdir="/example/rest" https://$CLUSTER_NAME.azurehdinsight.net/templeton/v1/hive | jq -r .id)

+ echo $JOB_ID

+ curl -u admin:$PASSWORD -d user.name=admin -G https://$CLUSTER_NAME.azurehdinsight.net/templeton/v1/jobs/$jobid | jq .status.state

+ export PASSWORD='PASSWORD'

+ export SQL_SERVER="MYSQLSERVER"

+ export DATABASE="MYDATABASE"

+ export SERVER_CONNECT="jdbc:sqlserver://$SQL_SERVER.database.windows.net:1433;user=sqluser;password=$PASSWORD"

+ export SERVER_DB_CONNECT="jdbc:sqlserver://$SQL_SERVER.database.windows.net:1433;user=sqluser;password=$PASSWORD;database=$DABATASE"

+ sqoop list-databases --connect $SERVER_CONNECT

+ sqoop list-tables --connect $SERVER_DB_CONNECT

+ sqoop export --connect $SERVER_DB_CONNECT \

+ sqoop eval --connect $SERVER_DB_CONNECT \

+ sqoop eval --connect $SERVER_DB_CONNECT \

+ sqoop import --connect $SERVER_DB_CONNECT \

+ sqoop import --connect $SERVER_DB_CONNECT \

+ export PASSWORD='MYPASSWORD'

+ export CLUSTER_NAME=MYCLUSTERNAME

+ curl -u admin:$PASSWORD \

+ -G https://$CLUSTER_NAME.azurehdinsight.net/hbaserest/

+ curl -u admin:$PASSWORD \

+ -X PUT "https://$CLUSTER_NAME.azurehdinsight.net/hbaserest/Contacts1/schema" \

+ curl -u admin:$PASSWORD \

+ -X PUT "https://$CLUSTER_NAME.azurehdinsight.net/hbaserest/Contacts1/false-row-key" \

+ curl -u admin:$PASSWORD \

+ GET "https://$CLUSTER_NAME.azurehdinsight.net/hbaserest/Contacts1/1000" \

+export CLUSTER_NAME="CLUSTERNAME"

+export ADMIN_PASSWORD='ADMINPASSWORD'

+export USER="NEWUSER"

+export USER_PASSWORD='USERPASSWORD'

+curl -k -u admin:$ADMIN_PASSWORD -H "X-Requested-By: ambari" -X POST \

+-d "{\"Users/user_name\":\"$USER\",\"Users/password\":\"$USER_PASSWORD\",\"Users/active\":\"true\",\"Users/admin\":\"false\"}" \

+https://$CLUSTER_NAME.azurehdinsight.net/api/v1/users

+echo "user created: $USER"

+curl -k -u admin:$ADMIN_PASSWORD -H "X-Requested-By: ambari" -X POST \

+-d '[{"PrivilegeInfo":{"permission_name":"CLUSTER.USER","principal_name":"'$USER'","principal_type":"USER"}}]' \

+https://$CLUSTER_NAME.azurehdinsight.net/api/v1/clusters/$CLUSTER_NAME/privileges

+curl -k -u $USER:$USER_PASSWORD -H "X-Requested-By: ambari" \

+-X GET "https://$CLUSTER_NAME.azurehdinsight.net/api/v1/clusters/$CLUSTER_NAME/services/ZOOKEEPER/components/ZOOKEEPER_SERVER"

+ RESOURCE_GROUP="RESOURCE_GROUP_NAME"

+ ./scripts/resources.sh $RESOURCE_GROUP LOCATION

+ SPARK_CLUSTER_NAME=$(cat resourcesoutputs_remainder.json | jq -r '.properties.outputs.sparkClusterName.value')

+ LLAP_CLUSTER_NAME=$(cat resourcesoutputs_remainder.json | jq -r '.properties.outputs.llapClusterName.value')

+ echo "Spark Cluster" $SPARK_CLUSTER_NAME

+ echo "LLAP cluster" $LLAP_CLUSTER_NAME

+ BLOB_STORAGE_NAME=$(cat resourcesoutputs_storage.json | jq -r '.properties.outputs.blobStorageName.value')

+ --account-name $BLOB_STORAGE_NAME \

+ --resource-group $RESOURCE_GROUP \

+ echo $BLOB_STORAGE_NAME

+ echo $BLOB_KEY

+ ADLSGEN2STORAGENAME=$(cat resourcesoutputs_storage.json | jq -r '.properties.outputs.adlsGen2StorageName.value')

+ ADLSKEY=$(az storage account keys list \

+ --account-name $ADLSGEN2STORAGENAME \

+ --resource-group $RESOURCE_GROUP \

+ echo $ADLSGEN2STORAGENAME

+ echo $ADLSKEY

+BLOB_STORAGE_NAME=$(cat resourcesoutputs_storage.json | jq -r '.properties.outputs.blobStorageName.value')

+ADLSGEN2STORAGENAME=$(cat resourcesoutputs_storage.json | jq -r '.properties.outputs.adlsGen2StorageName.value')

+./scripts/adf.sh $RESOURCE_GROUP $ADLSGEN2STORAGENAME $BLOB_STORAGE_NAME

+ LLAP_CLUSTER_NAME=$(cat resourcesoutputs_remainder.json | jq -r '.properties.outputs.llapClusterName.value')

+ scp scripts/query.hql sshuser@$LLAP_CLUSTER_NAME-ssh.azurehdinsight.net:/home/sshuser/

+ ssh sshuser@$LLAP_CLUSTER_NAME-ssh.azurehdinsight.net

+ az group delete -n $RESOURCE_GROUP

+ SERVICE_PRINCIPAL=$(cat serviceprincipal.json | jq -r '.name')

+ az ad sp delete --id $SERVICE_PRINCIPAL

+ export PASSWORD='PASSWORD'

+ export CLUSTER_NAME=$(curl -u admin:$PASSWORD -sS -G "http://headnodehost:8080/api/v1/clusters" | jq -r '.items[].Clusters.cluster_name')

+ export KAFKAZKHOSTS=$(curl -sS -u admin:$PASSWORD -G https://$CLUSTER_NAME.azurehdinsight.net/api/v1/clusters/$CLUSTER_NAME/services/ZOOKEEPER/components/ZOOKEEPER_SERVER | jq -r '["\(.host_components[].HostRoles.host_name):2181"] | join(",")' | cut -d',' -f1,2);

+ export KAFKABROKERS=$(curl -sS -u admin:$PASSWORD -G https://$CLUSTER_NAME.azurehdinsight.net/api/v1/clusters/$CLUSTER_NAME/services/KAFKA/components/KAFKA_BROKER | jq -r '["\(.host_components[].HostRoles.host_name):9092"] | join(",")' | cut -d',' -f1,2);

+ export CLUSTER_NAME='<clustername>'

+ export PASSWORD='<password>'

+ export KAFKABROKERS=$(curl -sS -u admin:$PASSWORD -G https://$CLUSTER_NAME.azurehdinsight.net/api/v1/clusters/$CLUSTER_NAME/services/KAFKA/components/KAFKA_BROKER | jq -r '["\(.host_components[].HostRoles.host_name):9092"] | join(",")' | cut -d',' -f1,2);

+> To learn how the MedTech service transforms and persists device message data into the FHIR service as FHIR Observations, see [Overview of the MedTech service device data processing stages](overview-of-device-data-processing-stages.md).

+No. The MedTech service currently only supports the Azure Health Data Services FHIR service for the persistence of transformed device data. The open-source version of the MedTech service supports the use of different FHIR services.

+The MedTech service requires device and FHIR destination mappings to perform normalization and transformation processes on device message data. To learn how the MedTech service transforms device data into [FHIR Observations](https://www.hl7.org/fhir/observation.html), see [Overview of the MedTech service device data processing stages](overview-of-device-data-processing-stages.md).

+### How long does it take for device data to show up in the FHIR service?

+The MedTech service buffers [FHIR Observations](https://www.hl7.org/fhir/observation.html) created during the transformation stage and provides near real-time processing. However, this buffer can potentially delay the persistence of FHIR Observations to the FHIR service up to ~five minutes. To learn how the MedTech service transforms device data into FHIR Observations, see [Overview of the MedTech service device data processing stages](overview-of-device-data-processing-stages.md).

+## Step 5: Send the device data for processing

+When the MedTech service is deployed and connected to the Event Hubs and FHIR services, it's ready to process device data and transform it into FHIR Observations. There are three parts of the sending process.

+### Device data sent to Event Hubs

+The device data is sent to an Event Hubs instance so that it can wait until the MedTech service is ready to receive it. The device data transfer needs to be asynchronous because it's sent over the Internet and delivery times can't be precisely measured. Normally the data won't sit on an event hub longer than 24 hours.

+### Device data sent from Event Hubs to the MedTech service

+MedTech requests the device data from the Event Hubs instance and the device data is sent from the event hub to the MedTech service. This procedure is called ingestion.

+### The MedTech service processes the device data

+The MedTech service processes the device data in five steps:

+For more information on the MedTech service device data transformation, see [Overview of the MedTech service device data processing stages](overview-of-device-data-processing-stages.md).

+## Step 6: Verify the processed device data

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

+You can verify that the device data is correctly persisted in the FHIR service by using the [MedTech service metrics](how-to-configure-metrics.md) in the Azure portal.

+|Latency|Average Group Stage Latency|The average latency of the group stage. The [group stage](overview-of-device-data-processing-stages.md#groupoptional) performs buffering, aggregating, and grouping on normalized messages.|

+|Latency|Average Normalize Stage Latency|The average latency of the normalized stage. The [normalized stage](overview-of-device-data-processing-stages.md#normalize) performs normalization on raw incoming messages.|

+|Traffic|Number of Fhir resources saved|The total number of FHIR resources [updated or persisted](overview-of-device-data-processing-stages.md#persist) by the MedTech service.|

+|Traffic|Number of Incoming Messages|The number of received raw [incoming messages](overview-of-device-data-processing-stages.md#ingest) (for example, the device events) from the configured source event hub.|

+|Traffic|Number of Measurements|The number of normalized value readings received by the FHIR [transformation stage](overview-of-device-data-processing-stages.md#transform) of the MedTech service.|

+> [!NOTE]

+> [Fast Healthcare Interoperability Resources (FHIR&#174;)](https://www.hl7.org/fhir/) is an open healthcare specification.

+> [!NOTE]

+> [Fast Healthcare Interoperability Resources (FHIR&#174;)](https://www.hl7.org/fhir/) is an open healthcare specification.

+ Title: How to use IotJsonPathContent mappings in the MedTech service device mappings - Azure Health Data Services

+description: This article describes how to use IotJsonPathContent mappings with the MedTech service device mappings.

+# How to use IotJsonPathContent mappings

+> [!NOTE]

+> [Fast Healthcare Interoperability Resources (FHIR&#174;)](https://www.hl7.org/fhir/) is an open healthcare specification.

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

+## IotJsonPathContent

+The IotJsonPathContent is similar to the JsonPathContent except the `DeviceIdExpression` and `TimestampExpression` aren't required.

+The assumption, when using this template, is the device messages being evaluated were sent using the [Azure IoT Hub Device SDKs](../../iot-hub/iot-hub-devguide-sdks.md#azure-iot-hub-device-sdks) or [Export Data (legacy)](../../iot-central/core/howto-export-data-legacy.md) feature of [Azure IoT Central](../../iot-central/core/overview-iot-central.md).

+When you're using these SDKs, the device identity and the timestamp of the message are known.

+> [!IMPORTANT]

+> Make sure that you're using a device identifier from Azure Iot Hub or Azure IoT Central that is registered as an identifier for a device resource on the destination FHIR service.

+If you're using Azure IoT Hub Device SDKs, you can still use the JsonPathContentTemplate, assuming that you're using custom properties in the message body for the device identity or measurement timestamp.

+> [!NOTE]

+> When using `IotJsonPathContent`, the `TypeMatchExpression` should resolve to the entire message as a JToken. For more information, see the following examples:

+### Examples

+With each of these examples, you're provided with:

+ * A valid device message.

+ * An example of what the device message will look like after IoT hub receiving and processing.

+ * Conforming and valid MedTech service device mappings for normalizing the device message after IoT hub processing.

+ * An example of what the MedTech service device message will look like after normalization.

+> [!IMPORTANT]

+> To avoid device spoofing in device-to-cloud messages, Azure IoT Hub enriches all messages with additional properties. To learn more about these properties, see [Anti-spoofing properties](../../iot-hub/iot-hub-devguide-messages-construct.md#anti-spoofing-properties).

+> [!TIP]

+> [Visual Studio Code with the Azure IoT Hub extension](https://marketplace.visualstudio.com/items?itemName=vsciot-vscode.azure-iot-toolkit) is a recommended method for sending IoT device messages to your IoT Hub for testing and troubleshooting.

+**Heart rate**

+**A valid device message to send to your IoT hub.**

+```json

+{ΓÇ£heartRateΓÇ¥ : ΓÇ£78ΓÇ¥}

+```

+**An example of what the device message will look like after being received and processed by the IoT hub.**

+> [!NOTE]

+> The IoT Hub enriches the device message before sending it to the MedTech service device event hub with all properties starting with `iothub`. For example: `iothub-creation-time-utc`.

+>

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

+```json

+{

+ "Body": {

+ "heartRate": "78"

+ },

+ "Properties": {

+ "iothub-creation-time-utc" : "2021-02-01T22:46:01.8750000Z"

+ },

+ "SystemProperties": {

+ "iothub-connection-device-id" : "device123"

+ }

+}

+```

+**Conforming and valid MedTech service device mappings for normalizing device data after IoT Hub processing.**

+```json

+{

+ "templateType": "CollectionContent",

+ "template": [

+ {

+ "templateType": "IotJsonPathContentTemplate",

+ "template": {

+ "typeName": "heartRate",

+ "typeMatchExpression": "$..[?(@Body.heartRate)]",

+ "patientIdExpression": "$.SystemProperties.iothub-connection-device-id",

+ "values": [

+ {

+ "required": "true",

+ "valueExpression": "$.Body.heartRate",

+ "valueName": "hr"

+ }

+ ]

+ }

+ }

+ ]

+}

+```

+**An example of what the MedTech service device data will look like after the normalization process.**

+```json

+{

+ "type": "heartRate",

+ "occurrenceTimeUtc": "2021-02-01T22:46:01.875Z",

+ "deviceId": "device123",

+ "properties": [

+ {

+ "name": "hr",

+ "value": "78"

+ }

+ ]

+}

+```

+**Blood pressure**

+**A valid IoT device message to send to your IoT hub.**

+```json

+{

+ "systolic": "123",

+ "diastolic": "87"

+}

+```

+**An example of what the device message will look like after being received and processed by the IoT hub.**

+> [!NOTE]

+> The IoT hyub enriches the device message before sending it to the MedTech service device event hub with all properties starting with `iothub`. For example: `iothub-creation-time-utc`.

+>

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

+```json

+{

+ "Body": {

+ "systolic": "123",

+ "diastolic" : "87"

+ },

+ "Properties": {

+ "iothub-creation-time-utc" : "2021-02-01T22:46:01.8750000Z"

+ },

+ "SystemProperties": {

+ "iothub-connection-device-id" : "device123"

+ }

+}

+```

+**Conforming and valid MedTech service device mappings for normalizing the device data after IoT hub processing.**

+```json

+{

+ "templateType": "CollectionContent",

+ "template": [

+ {

+ "templateType": "IotJsonPathContentTemplate",

+ "template": {

+ "typeName": "bloodpressure",

+ "typeMatchExpression": "$..[?(@Body.systolic && @Body.diastolic)]",

+ "patientIdExpression": "$.SystemProperties.iothub-connection-device-id",

+ "values": [

+ {

+ "required": "true",

+ "valueExpression": "$.Body.systolic",

+ "valueName": "systolic"

+ },

+ {

+ "required": "true",

+ "valueExpression": "$.Body.diastolic",

+ "valueName": "diastolic"

+ }

+ ]

+ }

+ }

+ ]

+}

+```

+**An example of what the MedTech service device data will look like after the normalization process.**

+```json

+{

+ "type": "bloodpressure",

+ "occurrenceTimeUtc": "2021-02-01T22:46:01.875Z",

+ "deviceId": "device123",

+ "properties": [

+ {

+ "name": "systolic",

+ "value": "123"

+ },

+ {

+ "name": "diastolic",

+ "value": "87"

+ }

+ ]

+}

+```

+> [!TIP]

+> The IotJsonPathContent device mapping examples provided in this article may be combined into a single MedTech service device mappings as shown.

+>

+> Additionally, the IotJasonPathContent can also be combined with with other template types such as [JsonPathContent mappings](how-to-use-jsonpath-content-mappings.md) to further expand your MedTech service device mapping.

+**Combined heart rate and blood pressure MedTech service device mapping example.**

+```json

+{

+ "templateType": "CollectionContent",

+ "template": [

+ {

+ "templateType": "IotJsonPathContent",

+ "template": {

+ "typeName": "heartRate",

+ "typeMatchExpression": "$..[?(@Body.heartRate)]",

+ "patientIdExpression": "$.SystemProperties.iothub-connection-device-id",

+ "values": [

+ {

+ "required": "true",

+ "valueExpression": "$.Body.heartRate",

+ "valueName": "hr"

+ }

+ ]

+ }

+ },

+ {

+ "templateType": "IotJsonPathContent",

+ "template": {

+ "typeName": "bloodpressure",

+ "typeMatchExpression": "$..[?(@Body.systolic && @Body.diastolic)]",

+ "patientIdExpression": "$.SystemProperties.iothub-connection-device-id",

+ "values": [

+ {

+ "required": "true",

+ "valueExpression": "$.Body.systolic",

+ "valueName": "systolic"

+ },

+ {

+ "required": "true",

+ "valueExpression": "$.Body.diastolic",

+ "valueName": "diastolic"

+ }

+ ]

+ }

+ }

+ ]

+}

+```

+> [!TIP]

+> See the MedTech service article [Troubleshoot MedTech service errors](troubleshoot-errors.md) for assistance fixing MedTech service errors.

+## Next steps

+In this article, you learned how to use IotJsonPathContent mappings with the MedTech service device mapping.

+To learn how to configure the MedTech service FHIR destination mapping, see

+> [!div class="nextstepaction"]

+> [How to configure FHIR destination mappings](how-to-configure-fhir-mappings.md)

+FHIR&#174; is a registered trademark of Health Level Seven International, registered in the U.S. Trademark Office and is used with their permission.

+> To learn about how the MedTech service transforms and persists device message data into the FHIR service see, [Overview of the MedTech service device data processing stages](overview-of-device-data-processing-stages.md).

+|Latency|**Average Group Stage Latency**|The average latency of the group stage. The [group stage](overview-of-device-data-processing-stages.md#groupoptional) performs buffering, aggregating, and grouping on normalized messages.|

+|Latency|**Average Normalize Stage Latency**|The average latency of the normalized stage. The [normalized stage](overview-of-device-data-processing-stages.md#normalize) performs normalization on raw incoming messages.|

+|Traffic|Number of Fhir resources saved|The total number of FHIR resources [updated or persisted](overview-of-device-data-processing-stages.md#persist) by the MedTech service.|

+|Traffic|**Number of Incoming Messages**|The number of received raw [incoming messages](overview-of-device-data-processing-stages.md#ingest) (for example, the device events) from the configured source event hub.|

+|Traffic|**Number of Measurements**|The number of normalized value readings received by the FHIR [transformation stage](overview-of-device-data-processing-stages.md#transform) of the MedTech service.|

+ Title: Overview of the MedTech service device data processing stages - Azure Health Data Services

+description: This article provides an overview of the MedTech service device data processing stages. The MedTech service ingests, normalizes, groups, transforms, and persists device message data in the FHIR service.

+# Overview of the MedTech service device data processing stages

+> [!NOTE]

+> [Fast Healthcare Interoperability Resources (FHIR&#174;)](https://www.hl7.org/fhir/) is an open healthcare specification.

+This article provides an overview of the device data processing stages within the [MedTech service](overview.md). The MedTech service transforms device data into [FHIR Observations](https://www.hl7.org/fhir/observation.html) for persistence in the [FHIR service](../fhir/overview.md).

+The MedTech service device data processing follows these stages and in this order:

+* Ingest

+* Normalize - Device mapping applied.

+* Group - (Optional)

+* Transform - FHIR destination mapping applied.

+* Persist

+## Ingest

+Ingest is the first stage where device messages are received from an [Azure Event Hubs](../../event-hubs/index.yml) event hub and immediately pulled into the MedTech service. The Event Hubs service supports high scale and throughput with the ability to receive and process millions of device messages per second. It also enables the MedTech service to consume device messages asynchronously, removing the need for devices to wait while device messages are processed. The MedTech service's [system-assigned managed identity](../../active-directory/managed-identities-azure-resources/overview.md#managed-identity-types) and [Azure resource-based access control (Azure RBAC)](../../role-based-access-control/overview.md) are used for secure access to the event hub.

+> [!NOTE]

+> JSON is the only supported format at this time for device message data.

+> [!IMPORTANT]

+> If you're going to allow access from multiple services to the event hub, it's required that each service has its own event hub consumer group.

+>

+> Consumer groups enable multiple consuming applications to have a separate view of the event stream, and to read the stream independently at their own pace and with their own offsets. For more information, see [Consumer groups](../../event-hubs/event-hubs-features.md#consumer-groups).

+>

+> Examples:

+>

+> - Two MedTech services accessing the same event hub.

+>

+> - A MedTech service and a storage writer application accessing the same event hub.

+## Normalize

+Normalize is the next stage where device data is processed using the user-selected/user-created conforming and valid [device mapping](overview-of-device-mapping.md). This mapping process results in transforming device data into a normalized schema. The normalization process not only simplifies device data processing at later stages, but also provides the capability to project one device message into multiple normalized messages. For instance, a device could send multiple vital signs for body temperature, pulse rate, blood pressure, and respiration rate in a single device message. This device message would create four separate FHIR Observations. Each FHIR Observation would represent a different vital sign, with the device message projected into four different normalized messages.

+## Group - (Optional)

+Group is the next *optional* stage where the normalized messages available from the MedTech service normalization stage are grouped using three different parameters:

+* Device identity

+* Measurement type

+* Time period

+Device identity and measurement type grouping are optional and enabled by the use of the [SampledData](https://www.hl7.org/fhir/datatypes.html#SampledData) measurement type. The SampledData measurement type provides a concise way to represent a time-based series of measurements from a device message into FHIR Observations. When you use the SampledData measurement type, measurements can be grouped into a single FHIR Observation that represents a 1-hour period or a 24-hour period.

+## Transform

+Transform is the next stage where normalized messages are processed using the user-selected/user-created conforming and valid [FHIR destination mapping](how-to-configure-fhir-mappings.md). Normalized messages get transformed into FHIR Observations if a matching FHIR destination mapping has been authored. At this point, the [Device](https://www.hl7.org/fhir/device.html) resource, along with its associated [Patient](https://www.hl7.org/fhir/patient.html) resource, is also retrieved from the FHIR service using the device identifier present in the device message. These resources are added as a reference to the FHIR Observation being created.

+> [!NOTE]

+> All identity look ups are cached once resolved to decrease load on the FHIR service. If you plan on reusing devices with multiple patients, it is advised you create a virtual device resource that is specific to the patient and send the virtual device identifier in the device message payload. The virtual device can be linked to the actual device resource as a parent.

+If no Device resource for a given device identifier exists in the FHIR service, the outcome depends upon the value of [**Resolution type**](deploy-new-config.md#configure-the-destination-tab) set at the time of the MedTech service deployment. When set to **Lookup**, the specific message is ignored, and the pipeline continues to process other incoming device messages. If set to **Create**, the MedTech service creates minimal Device and Patient resources in the FHIR service.

+> [!NOTE]

+> The **Resolution type** can also be adjusted post deployment of the MedTech service if a different **Resolution type** is later required.

+The MedTech service provides near real-time processing and also attempts to reduce the number of requests made to the FHIR service by grouping requests into batches of 300 [normalized messages](#normalize). If there's a low volume of data, and 300 normalized messages haven't been added to the group, then the corresponding FHIR Observations in that group are persisted to the FHIR service after approximately five minutes. When there's fewer than 300 normalized messages to be processed, there may be a delay of approximately five minutes before FHIR Observations are created or updated in the FHIR service.

+> [!NOTE]

+> When multiple device messages contain data for the same FHIR Observation, have the same timestamp, and are sent within the same device message batch (for example, within the five minute window or in groups of 300 normalized messages), only the data corresponding to the latest device message for that FHIR Observation is persisted.

+>

+> For example:

+>

+> Device message 1:

+> ```json

+> {   

+> "patientid": "testpatient1",   

+> "deviceid": "testdevice1",

+> "systolic": "129",   

+> "diastolic": "65",   

+> "measurementdatetime": "2022-02-15T04:00:00.000Z"

+> } 

+> ```

+>

+> Device message 2:

+> ```json

+> {   

+> "patientid": "testpatient1",   

+> "deviceid": "testdevice1",   

+> "systolic": "113",   

+> "diastolic": "58",   

+> "measurementdatetime": "2022-02-15T04:00:00.000Z"

+> }

+> ```

+>

+> Assuming these device messages were ingested within the same five minute window or in the same group of 300 normalized messages, and since the `measurementdatetime` is the same for both device messages (indicating these contain data for the same FHIR Observation), only device message 2 is persisted to represent the latest/most recent data.

+## Persist

+Persist is the final stage where the FHIR Observations from the transform stage are persisted in the [FHIR service](../fhir/overview.md). If the FHIR Observation is new, it's created in the FHIR service. If the FHIR Observation already existed, it gets updated in the FHIR service. The FHIR service uses the MedTech service's [system-assigned managed identity](../../active-directory/managed-identities-azure-resources/overview.md#managed-identity-types) and [Azure resource-based access control (Azure RBAC)](../../role-based-access-control/overview.md) for secure access to the FHIR service.

+## Next steps

+In this article, you learned about the MedTech service device message processing and persistence in the FHIR service.

+To get an overview of the MedTech service device and FHIR destination mappings, see

+> [!div class="nextstepaction"]

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

+> [!div class="nextstepaction"]

+> [Overview of the MedTech service FHIR destination mapping](how-to-configure-fhir-mappings.md)

+FHIR&#174; is a registered trademark of Health Level Seven International, registered in the U.S. Trademark Office and is used with their permission.

+The MedTech service requires two types of [JSON](https://www.json.org/) mappings that are added to your MedTech service through the Azure portal or Azure Resource Manager API. The device mapping is the first type and controls mapping values in the device data sent to the MedTech service to an internal, normalized data object. The device mapping contains expressions that the MedTech service uses to extract types, device identifiers, measurement date time, and measurement value(s). The [FHIR destination mapping](how-to-configure-fhir-mappings.md) is the second type and controls the mapping for [FHIR Observations](https://www.hl7.org/fhir/observation.html).

+> The device and FHIR destination mappings are re-evaluated each time a device message is processed. Any updates to either mapping will take effect immediately.

+> For more information about how the MedTech service processes device message data into FHIR Observations for persistence on the FHIR service, see [Overview of the MedTech service device data processing stages](overview-of-device-data-processing-stages.md).

+- [IotJsonPathContent](how-to-use-iotjsonpathcontent-mappings.md) for device messages being routed through [Azure IoT Hub](/azure/iot-hub/iot-concepts-and-iot-hub) to your MedTech service event hub. IotJsonPathContent supports [JSONPath](https://goessner.net/articles/JsonPath/).

+> For assistance fixing common MedTech service deployment errors, see [Troubleshoot MedTech service deployment errors](troubleshoot-errors-deployment.md).

+> For assistance fixing MedTech service errors, see [Troubleshoot errors using the MedTech service logs](troubleshoot-errors-logs.md).

+> [How to use IotJsonPathContent with the MedTech service device mapping](how-to-use-iotjsonpathcontent-mappings.md)

+ Title: Overview of the MedTech service FHIR destination mapping - Azure Health Data Services

+description: This article provides an overview of the MedTech service FHIR destination mapping.

+# Overview of the MedTech service FHIR destination mapping

+> [!NOTE]

+> [Fast Healthcare Interoperability Resources (FHIR&#174;)](https://www.hl7.org/fhir/) is an open healthcare specification.

+This article provides an overview of the MedTech service FHIR destination mapping.

+The MedTech service requires two types of [JSON](https://www.json.org/) mappings that are added to your MedTech service through the Azure portal or Azure Resource Manager API. The [device mapping](overview-of-device-mapping.md) is the first type and controls mapping values in the device data sent to the MedTech service to an internal, normalized data object. The device mapping contains expressions that the MedTech service uses to extract types, device identifiers, measurement date time, and measurement value(s). The FHIR destination mapping is the second type and controls how the normalized data is mapped to [FHIR Observations](https://www.hl7.org/fhir/observation.html).

+> [!NOTE]

+> The device and FHIR destination mappings are re-evaluated each time a device message is processed. Any updates to either mapping will take effect immediately.

+## FHIR destination mapping basics

+The FHIR destination mapping controls how the data extracted from a device message is mapped into a FHIR observation.

+- Should an observation be created for a point in time or over a period of an hour?

+- What codes should be added to the observation?

+- Should the value be represented as [SampledData](https://www.hl7.org/fhir/datatypes.html#SampledData) or a [Quantity](https://www.hl7.org/fhir/datatypes.html#Quantity)?

+These data types are all options the FHIR destination mapping configuration controls.

+Once a device message is transformed into a normalized data model, the data is collected for transformation to a [FHIR Observation](https://www.hl7.org/fhir/observation.html). If the Observation type is [SampledData](https://www.hl7.org/fhir/datatypes.html#SampledData), the data is grouped according to device identifier, measurement type, and time period (time period can be either 1 hour or 24 hours). The output of this grouping is sent for conversion into a single [FHIR Observation](https://www.hl7.org/fhir/observation.html) that represents the time period for that data type. For other Observation types ([Quantity](https://www.hl7.org/fhir/datatypes.html#Quantity), [CodeableConcept](https://www.hl7.org/fhir/datatypes.html#CodeableConcept) and [string](https://www.hl7.org/fhir/datatypes.html#string)) data is not grouped, but instead each measurement is transformed into a single Observation representing a point in time.

+> [!TIP]

+> For more information about how the MedTech service processes device message data into FHIR Observations for persistence on the FHIR service, see [Overview of the MedTech service device message processing stages](overview-of-device-message-processing-stages.md).

+This diagram provides an illustration of what happens during the transformation stage within the MedTech service.

+> [!NOTE]

+> The FHIR Observation in this diagram is not the complete resource. See [Example](#example) in this overview for the entire FHIR Observation.

+## FHIR destination mapping validations

+The validation process validates the FHIR destination mapping before allowing them to be saved for use. These elements are required in the FHIR destination mapping.

+**FHIR destination mapping**

+|Element|Required|

+|:|:-|

+|typeName|True|

+> [!NOTE]

+> The 'typeName' element is used to link a FHIR destination mapping template to one or more device mapping templates. Device mapping templates with the same 'typeName' element generate normalized data that will be evaluated with a FHIR destination mapping template that has the same 'typeName'.

+## CollectionFhir

+CollectionFhir is the root template type used by the MedTech service FHIR destination mapping. CollectionFhir is a list of all templates that are used during the transformation stage. You can define one or more templates within CollectionFhir, with each normalized message evaluated against all templates.

+### CodeValueFhir

+CodeValueFhir is currently the only template supported in FHIR destination mapping at this time. It allows you to define codes, the effective period, and the value of the observation. Multiple value types are supported: [SampledData](https://www.hl7.org/fhir/datatypes.html#SampledData), [CodeableConcept](https://www.hl7.org/fhir/datatypes.html#CodeableConcept), [Quantity](https://www.hl7.org/fhir/datatypes.html#Quantity), and [String](https://www.hl7.org/fhir/datatypes.html#primitive). Along with these configurable values, the identifier for the Observation resource and linking to the proper Device and Patient resources are handled automatically.

+> [!NOTE]

+>

+|Property|Description|

+|:-|--|

+|**typeName**| The type of measurement this template should bind to. There should be at least one Device mapping template that outputs this type.

+|**periodInterval**|The period of time the observation created should represent. Supported values are 0 (an instance), 60 (an hour), 1440 (a day). Note: `periodInterval` is required when the Observation type is "SampledData" and is ignored for any other Observation types.

+|**category**|Any number of [CodeableConcepts](http://hl7.org/fhir/datatypes-definitions.html#codeableconcept) to classify the type of observation created.

+|**codes**|One or more [Codings](http://hl7.org/fhir/datatypes-definitions.html#coding) to apply to the observation created.

+|**codes[].code**|The code for the [Coding](http://hl7.org/fhir/datatypes-definitions.html#coding).

+|**codes[].system**|The system for the [Coding](http://hl7.org/fhir/datatypes-definitions.html#coding).

+|**codes[].display**|The display for the [Coding](http://hl7.org/fhir/datatypes-definitions.html#coding).

+|**value**|The value to extract and represent in the observation. For more information, see [Value type codes](#value-type-codes).

+|**components**|*Optional:* One or more components to create on the observation.

+|**components[].codes**|One or more [Codings](http://hl7.org/fhir/datatypes-definitions.html#coding) to apply to the component.

+|**components[].value**|The value to extract and represent in the component. For more information, see [Value type codes](#value-type-codes).

+### Value type codes

+The supported value type codes for the MedTech service FHIR destination mapping:

+### SampledData

+Represents the [SampledData](http://hl7.org/fhir/datatypes.html#SampledData) FHIR data type. Observation measurements are written to a value stream starting at a point in time and incrementing forward using the period defined. If no value is present, an `E` is written into the data stream. If the period is such that two more values occupy the same position in the data stream, the latest value is used. The same logic is applied when an observation using the SampledData is updated.

+| Property | Description

+| |

+|**DefaultPeriod**|The default period in milliseconds to use.

+|**Unit**|The unit to set on the origin of the SampledData.

+### Quantity

+Represents the [Quantity](http://hl7.org/fhir/datatypes.html#Quantity) FHIR data type. This type creates a single, point in time, Observation. If a new value arrives that contains the same device identifier, measurement type, and timestamp, the previous Observation is updated to the new value.

+| Property | Description

+| |

+|**Unit**| Unit representation.

+|**Code**| Coded form of the unit.

+|**System**| System that defines the coded unit form.

+### CodeableConcept

+Represents the [CodeableConcept](http://hl7.org/fhir/datatypes.html#CodeableConcept) FHIR data type. The value in the normalized data model isn't used, and instead when this type of data is received, an Observation is created with a specific code representing that an observation was recorded at a specific point in time.

+| Property | Description

+| |

+|**Text**|Plain text representation.

+|**Codes**|One or more [Codings](http://hl7.org/fhir/datatypes-definitions.html#coding) to apply to the observation created.

+|**Codes[].Code**|The code for the [Coding](http://hl7.org/fhir/datatypes-definitions.html#coding).

+|**Codes[].System**|The system for the [Coding](http://hl7.org/fhir/datatypes-definitions.html#coding).

+|**Codes[].Display**|The display for the [Coding](http://hl7.org/fhir/datatypes-definitions.html#coding).

+### String

+Represents the [string](https://www.hl7.org/fhir/datatypes.html#string) FHIR data type. This type creates a single, point in time, Observation. If new value arrives that contains the same device identifier, measurement type, and timestamp, the previous Observation is updated to the new value.

+### Example

+> [!TIP]

+> You can use the MedTech service [Mapping debugger](how-to-use-mapping-debugger.md) for assistance creating, updating, and troubleshooting the MedTech service device and FHIR destination mappings. The Mapping debugger enables you to easily view and make inline adjustments in real-time, without ever having to leave the Azure portal. The Mapping debugger can also be used for uploading test device messages to see how they'll look after being processed into normalized messages and transformed into FHIR Observations.

+> [!NOTE]

+> This example and normalized message is a continuation from [Overview of the MedTech service device mapping](overview-of-device-mapping.md#example).

+In this example, we're using a normalized message capturing `heartRate` data:

+```json

+[

+ {

+ "type": "heartrate",

+ "occurrenceTimeUtc": "2023-03-13T22:46:01.875Z",

+ "deviceId": "device01",

+ "properties": [

+ {

+ "name": "hr",

+ "value": "78"

+ }

+ ]

+ }

+]

+```

+We're using this FHIR destination mapping for the transformation stage:

+```json

+{

+ "templateType": "CollectionFhir",

+ "template": [

+ {

+ "templateType": "CodeValueFhir",

+ "template": {

+ "codes": [

+ {

+ "code": "8867-4",

+ "system": "http://loinc.org",

+ "display": "Heart rate"

+ }

+ ],

+ "typeName": "heartrate",

+ "value": {

+ "system": "http://unitsofmeasure.org",

+ "code": "count/min",

+ "unit": "count/min",

+ "valueName": "hr",

+ "valueType": "Quantity"

+ }

+ }

+ }

+ ]

+}

+```

+The resulting FHIR Observation will look like this after the transformation stage:

+```json

+[

+ {

+ "code": {

+ "coding": [

+ {

+ "system": {

+ "value": "http://loinc.org"

+ },

+ "code": {

+ "value": "8867-4"

+ },

+ "display": {

+ "value": "Heart rate"

+ }

+ }

+ ],

+ "text": {

+ "value": "heartrate"

+ }

+ },

+ "effective": {

+ "start": {

+ "value": "2023-03-13T22:46:01.8750000Z"

+ },

+ "end": {

+ "value": "2023-03-13T22:46:01.8750000Z"

+ }

+ },

+ "issued": {

+ "value": "2023-04-05T21:02:59.1650841+00:00"

+ },

+ "value": {

+ "value": {

+ "value": 78

+ },

+ "unit": {

+ "value": "count/min"

+ },

+ "system": {

+ "value": "http://unitsofmeasure.org"

+ },

+ "code": {

+ "value": "count/min"

+ }

+ }

+ }

+]

+```

+> [!TIP]

+> For assistance fixing common MedTech service deployment errors, see [Troubleshoot MedTech service deployment errors](troubleshoot-errors-deployment.md).

+>

+> For assistance fixing MedTech service errors, see [Troubleshoot errors using the MedTech service logs](troubleshoot-errors-logs.md).

+## Next steps

+In this article, you've been provided an overview of the MedTech service FHIR destination mapping.

+To get an overview of the MedTech service device mapping, see

+> [!div class="nextstepaction"]

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

+To learn how to use CalculatedContent with the MedTech service device mapping, see

+> [!div class="nextstepaction"]

+> [How to use CalculatedContent with the MedTech service device mapping](how-to-use-calculatedcontent-mappings.md)

+To learn how to use IotJsonPathContent with the MedTech service device mapping, see

+> [!div class="nextstepaction"]

+> [How to use IotJsonPathContent with the MedTech service device mapping](how-to-use-iotjsonpathcontenttemplate-mappings.md)

+To learn how to use custom functions with the MedTech service device mapping, see

+> [!div class="nextstepaction"]

+> [How to use custom functions with the MedTech service device mapping](how-to-use-custom-functions.md)

+FHIR&#174; is a registered trademark of Health Level Seven International, registered in the U.S. Trademark Office and is used with their permission.

+5. **Persist** - After the transformation is done, the new data is sent to the FHIR service and persisted as FHIR Observations.

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

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

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

+> To learn about the MedTech service device message data transformation, see [Overview of the MedTech service device data processing stages](overview-of-device-data-processing-stages.md).

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

+description: Understand how the Microsoft Connected Cache module for Azure IoT Edge enables updating disconnected device with Device Update for Azure IoT Hub

+# Understand support for disconnected device updates (preview)

+The Microsoft Connected Cache (MCC) module for IoT Edge devices enables Device Update capabilities on disconnected devices behind gateways. In a transparent gateway scenario, one or more devices can pass their messages through a single gateway device that maintains the connection to Azure IoT Hub. In these cases, the child devices may not have internet connectivity or may not be allowed to download content from the internet. The MCC module provides Device Update for IoT Hub customers with the capability of an intelligent in-network cache. The cache enables image-based and package-based updates of Linux OS-based devices that are behind an IoT Edge gateway (also called *downstream* IoT devices). The cache also helps reduce the bandwidth used for updates.

+If you aren't familiar with IoT Edge gateways, learn more about [How an IoT Edge device can be used as a gateway](../iot-edge/iot-edge-as-gateway.md).

+## What is Microsoft Connected Cache

+Microsoft Connected Cache is an intelligent, transparent cache for content published for Device Update for IoT Hub and can be customized to cache content from other sources like package repositories as well. Microsoft Connected Cache is a cold cache that is warmed by client requests for the exact file ranges requested by the Delivery Optimization client and doesn't pre-seed content. The following diagram and step-by-step description explain how Microsoft Connected Cache works within the Device Update infrastructure.

+1. Microsoft Connected Cache is deployed as an IoT Edge module to the on-premises gateway server.

+2. Device Update for IoT Hub clients are configured to download content from Microsoft Connected Cache by using either the GatewayHostName attribute of the device connection string for IoT leaf devices **or** the parent_hostname set in the config.toml for IoT Edge child devices.

+3. Device Update for IoT Hub clients receive download commands from the Device Update service and request update content from the Microsoft Connected Cache instead of the CDN. Microsoft Connected Cache listens on HTTP port 80 by default, and the Delivery Optimization client makes the content request on port 80 so the parent must be configured to listen on this port. Only the HTTP protocol is supported at this time.

+5. Subsequent requests from other Device Update clients for the same update content now come from cache and Microsoft Connected Cache won't make requests to the CDN for the same content.

+Industrial IoT (IIoT) scenarios often involve multiple levels of IoT Edge gateways, with only the top level having internet access. In this scenario, each gateway hosts a Microsoft Connected Cache service that is configured to request update content from its parent gateway.

+When a child (or downstream) IoT Edge gateway makes a request for update content from its parent gateway, this request is repeated for as many levels as necessary before reaching the topmost IoT Edge gateway hosting a Microsoft Connected Cache server that has internet access. From the internet connected server, the content is requested from the CDN at which point the content is delivered back to the child IoT Edge gateway that originally requested the content. The content is stored on disk at every level.

+## Microsoft Connected Cache module configuration

+Microsoft Connected Cache is deployed to Azure IoT Edge gateways as an IoT Edge module. Like other IoT Edge modules, environment variables and container create options are used to configure MCC modules. This section defines the environment variables and container create options that are required to successfully deploy the MCC module for use by Device Update for IoT Hub.

+There's no naming requirement for the Microsoft Connected Cache module since no other module or service interactions rely on the name of the MCC module for communication. Additionally, the parent-child relationship of the Microsoft Connected Cache servers isn't dependent on this module name, but rather the FQDN or IP address of the IoT Edge gateway.

+### Module environment variables

+Microsoft Connected Cache module environment variables are used to pass basic module identity information and functional module settings to the container.

+| Variable name | Value format | Description |

+|--|--|--|

+| CUSTOMER_ID | Azure subscription ID GUID | Required <br><br> This value is the customer's ID, which provides secure authentication of the cache node to Delivery Optimization services. |

+| CACHE_NODE_ID | Cache node ID GUID | Required <br><br> Uniquely identifies the MCC node to Delivery Optimization services. |

+| CUSTOMER_KEY | Customer Key GUID | Required <br><br> This value is the customer's key, which provides secure authentication of the cache node to Delivery Optimization services. |

+| STORAGE_*N*_SIZE_GB (Where *N* is the cache drive) | Integer | Required <br><br> Specify up to nine drives to cache content and specify the maximum space in gigabytes to allocate for content on each cache drive. The number of the drive must match the cache drive binding values specified in the container create option MicrosoftConnectedCache*N* value.<br><br>Examples:<br>STORAGE_1_SIZE_GB = 150<br>STORAGE_2_SIZE_GB = 50<br><br>Minimum size of the cache is 10 GB. |

+| UPSTREAM_HOST | FQDN/IP | Optional <br><br> This value can specify an upstream MCC node that acts as a proxy if the Connected Cache node is disconnected from the internet. This setting is used to support the nested IoT scenario.<br><br>**Note:** MCC listens on http default port 80. |

+| UPSTREAM_PROXY | FQDN/IP:PORT | Optional <br><br> The outbound internet proxy. This value could also be the OT DMZ proxy of an ISA 95 network. |

+| CACHEABLE_CUSTOM_*N*_HOST | HOST/IP<br>FQDN | Optional <br><br> Required to support custom package repositories. Repositories could be hosted locally or on the internet. There's no limit to the number of custom hosts that can be configured.<br><br>Examples:<br>Name = CACHEABLE_CUSTOM_1_HOST Value = packages.foo.com<br> Name = CACHEABLE_CUSTOM_2_HOST Value = packages.bar.com |

+| CACHEABLE_CUSTOM_*N*_CANONICAL | Alias | Optional <br><br> Required to support custom package repositories. This value can be used as an alias and will be used by the cache server to reference different DNS names. For example, repository content hostname may be packages.foo.com, but for different regions there could be an extra prefix that is added to the hostname like westuscdn.packages.foo.com and eastuscdn.packages.foo.com. By setting the canonical alias, you ensure that content isn't duplicated for content coming from the same host, but different CDN sources. The format of the canonical value isn't important, but it must be unique to the host. It may be easiest to set the value to match the host value.<br><br>Examples based on the previous custom host examples:<br>Name = CACHEABLE_CUSTOM_1_CANONICAL Value = foopackages<br> Name = CACHEABLE_CUSTOM_2_CANONICAL Value = packages.bar.com |

+| IS_SUMMARY_PUBLIC | True or False | Optional <br><br> Enables viewing of the summary report on the local network or internet. Use of an API key (discussed later) is required to view the summary report if set to true. |

+| IS_SUMMARY_ACCESS_UNRESTRICTED | True or False | Optional <br><br> Enables viewing of summary report on the local network or internet without use of API key from any device in the network. Use if you don't want to lock down access to viewing cache server summary data via the browser. |

+### Module container create options

+Container create options provide control of the settings related to storage and ports used by the Microsoft Connected Cache module.

+Sample container create options:

+```json

+{

+ "HostConfig": {

+ "Binds": [

+ "/microsoftConnectedCache1/:/nginx/cache1/"

+ ],

+ "PortBindings": {

+ "8081/tcp": [

+ {

+ "HostPort": "80"

+ }

+ ],

+ "5000/tcp": [

+ {

+ "HostPort": "5100"

+ }

+ ]

+ }

+ }

+}

+```

+The following sections list the required container create variables used to deploy the MCC module.

+#### HostConfig

+The `HostConfig` parameters are required to map the container storage location to the storage location on the disk. Up to nine locations can be specified.

+>[!Note]

+>The number of the drive must match the cache drive binding values specified in the environment variable STORAGE_*N*_SIZE_GB value, `/MicrosoftConnectedCache*N*/:/nginx/cache*N*/`.

+#### PortBindings

+The `PortBindings` parameters map container ports to ports on the host device.

+The first port binding specifies the external machine HTTP port that MCC listens on for content requests. The default HostPort is port 80 and other ports aren't supported at this time as the ADU client makes requests on port 80 today. TCP port 8081 is the internal container port that the MCC listens on and can't be changed.

+The second port binding ensures that the container isn't listening on host port 5000. The Microsoft Connected Cache module has a .NET Core service, which is used by the caching engine for various functions. To support nested edge, the HostPort must not be set to 5000 because the registry proxy module is already listening on host port 5000.

+## Microsoft Connected Cache summary report

+The summary report is currently the only way for a customer to view caching data for the Microsoft Connected Cache instances deployed to IoT Edge gateways. The report is generated at 15-second intervals and includes averaged stats for the period and aggregated stats for the lifetime of the module. The key stats that the report provides are:

+* **hitBytes** - The sum of bytes delivered that came directly from cache.

+* **missBytes** - The sum of bytes delivered that Microsoft Connected Cache had to download from CDN to see the cache.

+* **eggressBytes** - The sum of hitBytes and missBytes and is the total bytes delivered to clients.

+* **hitRatioBytes** - The ratio of hitBytes to egressBytes. For example, if 100% of eggressBytes delivered in a period were equal to the hitBytes, this value would be 1.

+The summary report is available at `http://<IoT Edge gateway>:5001/summary` Replace \<IoT Edge Gateway\> with the IP address or hostname of the IoT Edge gateway hosting the MCC module.

+## Next steps

+Learn how to implement Microsoft Connected Cache in [single gateways](./connected-cache-single-level.md) or [nested and industrial IoT gateways](./connected-cache-nested-level.md).

+ Title: Deploy Microsoft Connected Cache on nested gateways

+description: Microsoft Connected Cache two level nested Azure IoT Edge Gateway with outbound unauthenticated proxy

+# Deploy the Microsoft Connected Cache module on nested gateways, including in IIoT scenarios (preview)

+The Microsoft Connected Cache module supports nested, or hierarchical gateways, in which one or more IoT Edge gateway devices are behind a single gateway that has access to the internet. This article describes a deployment scenario sample that has two nested Azure IoT Edge gateway devices (a *parent gateway* and a *child gateway*) with outbound unauthenticated proxy.

+The following diagram describes the scenario where one Azure IoT Edge gateway has direct access to CDN resources and is acting as the parent to another Azure IoT Edge gateway. The child IoT Edge gateway is acting as the parent to an IoT leaf device such as a Raspberry Pi. Both the IoT Edge child gateway and the IoT device are internet isolated. This example demonstrates the configuration for two levels of Azure IoT Edge gateways, but there's no limit to the depth of upstream hosts that Microsoft Connected Cache will support.

+Refer to the documentation [Connect downstream IoT Edge devices](../iot-edge/how-to-connect-downstream-iot-edge-device.md) for more details on configuring layered deployments of Azure IoT Edge gateways. Additionally note that when deploying Azure IoT Edge, Microsoft Connected Cache, and custom modules, all modules must reside in the same container registry.

+Use the following steps to configure the Microsoft Connected Cache module on the parent gateway device.

+1. Add the Microsoft Connected Cache module to your Azure IoT Edge gateway device deployment in Azure IoT Hub (see [Support for disconnected devices](connected-cache-disconnected-device-update.md) for details on how to request access to the preview module).

+2. Add the environment variables for the deployment. The following table is an example of the environment variables:

+ | Name | Value |

+ | - | -- |

+ | CACHE_NODE_ID | See [environment variable](connected-cache-disconnected-device-update.md#module-environment-variables) descriptions |

+ | CUSTOMER_ID | See [environment variable](connected-cache-disconnected-device-update.md#module-environment-variables) descriptions |

+ | CUSTOMER_KEY | See [environment variable](connected-cache-disconnected-device-update.md#module-environment-variables) descriptions |

+ | STORAGE_1_SIZE_GB | 10 |

+ | CACHEABLE_CUSTOM_1_HOST | Packagerepo.com:80 |

+ | CACHEABLE_CUSTOM_1_CANONICAL | Packagerepo.com |

+ | IS_SUMMARY_ACCESS_UNRESTRICTED | true |

+3. Add the container create options for the deployment. There's no difference in MCC container create options for single or nested gateways. The following example shows the container create options for the MCC module:

+ ```json

+ {

+ "HostConfig": {

+ "Binds": [

+ "/MicrosoftConnectedCache1/:/nginx/cache1/"

+ ],

+ "PortBindings": {

+ "8081/tcp": [

+ {

+ "HostPort": "80"

+ }

+ ],

+ "5000/tcp": [

+ {

+ "HostPort": "5100"

+ }

+ ]

+ }

+ }

+ }

+ ```

+Use the following steps to configure the Microsoft Connected Cache module on the child gateway device.

+>If you have replicated containers used in your configuration in your own private registry, then there will need to be a modification to the config.toml settings and runtime settings in your module deployment. For more information, see [Connect downstream IoT Edge devices](../iot-edge/how-to-connect-downstream-iot-edge-device.md#deploy-modules-to-lower-layer-devices).

+1. Modify the image path for the IoT Edge agent as demonstrated in the example below:

+ ```markdown

+ [agent]

+ name = "edgeAgent"

+ type = "docker"

+ env = {}

+ [agent.config]

+ image = "<parent_device_fqdn_or_ip>:8000/iotedge/azureiotedge-agent:1.2.0-rc2"

+ auth = {}

+ ```

+2. Modify the IoT Edge hub and agent runtime settings in the IoT Edge deployment as demonstrated in this example:

+ * For the IoT Edge hub image, enter `$upstream:8000/iotedge/azureiotedge-hub:1.2.0-rc2`

+ * For the IoT Edge agent image, enter `$upstream:8000/iotedge/azureiotedge-agent:1.2.0-rc2`

+ * Choose a name for your module: `ConnectedCache`

+ * Modify the image URI: `$upstream:8000/mcc/linux/iot/mcc-ubuntu-iot-amd64:latest`

+ >[!Note]

+ >The CACHE_NODE_ID should be unique. The CUSTOMER_ID and CUSTOMER_KEY values will be identical to the parent. For more information, see [Module environment variables](connected-cache-disconnected-device-update.md#module-environment-variables).

+For a validation of properly functioning Microsoft Connected Cache, execute the following command in the terminal of the IoT Edge device hosting the module or any device on the network. Replace \<Azure IoT Edge Gateway IP\> with the IP address or hostname of your IoT Edge gateway. For information on the visibility of this report, see [Microsoft Connected Cache summary report](./connected-cache-disconnected-device-update.md#microsoft-connected-cache-summary-report).

+```bash

+wget http://<CHILD Azure IoT Edge Gateway IP>/mscomtest/wuidt.gif?cacheHostOrigin=au.download.windowsupdate.com

+```

+## Industrial IoT (IIoT) configuration

+Manufacturing networks are often organized in hierarchical layers following the [Purdue network model](https://en.wikipedia.org/wiki/Purdue_Enterprise_Reference_Architecture) (included in the [ISA 95](https://en.wikipedia.org/wiki/ANSI/ISA-95) and [ISA 99](https://www.isa.org/standards-and-publications/isa-standards/isa-standards-committees/isa99) standards). In these networks, only the top layer has connectivity to the cloud and the lower layers in the hierarchy can only communicate with adjacent north and south layers.

+This GitHub sample, [Azure IoT Edge for Industrial IoT](https://github.com/Azure-Samples/iot-edge-for-iiot), deploys the following components:

+* Simulated Purdue network in Azure

+* Industrial assets

+* Hierarchy of Azure IoT Edge gateways

+

+These components will be used to acquire industrial data and securely upload it to the cloud without compromising the security of the network. Microsoft Connected Cache can be deployed to support the download of content at all levels within the ISA 95 compliant network.

+The key to configuring Microsoft Connected Cache deployments within an ISA 95 compliant network is configuring both the OT proxy *and* the upstream host at the L3 IoT Edge gateway.

+1. Configure Microsoft Connected Cache deployments at the L5 and L4 levels as described in the Two-Level Nested IoT Edge gateway sample

+2. The deployment at the L3 IoT Edge gateway must specify:

+ * UPSTREAM_HOST - The IP/FQDN of the L4 IoT Edge gateway, which the L3 Microsoft Connected Cache will request content.

+ * UPSTREAM_PROXY - The IP/FQDN:PORT of the OT proxy server.

+3. The OT proxy must add the L4 MCC FQDN/IP address to the allowlist.

+To validate that Microsoft Connected Cache is functioning properly, execute the following command in the terminal of the IoT Edge device hosting the module, or any device on the network. Replace \<Azure IoT Edge Gateway IP\> with the IP address or hostname of your IoT Edge gateway. For information on the visibility of this report, see [Microsoft Connected Cache summary report](./connected-cache-disconnected-device-update.md#microsoft-connected-cache-summary-report).

+wget http://<L3 IoT Edge Gateway IP>/mscomtest/wuidt.gif?cacheHostOrigin=au.download.windowsupdate.com

+```

+ Title: Deploy Microsoft Connected Cache on a gateway

+description: Update disconnected devices with Device Update using the Microsoft Connected Cache module on IoT Edge gateways

+# Deploy the Microsoft Connected Cache module on a single gateway (preview)

+The Microsoft Connected Cache (MCC) module for IoT Edge gateways enables Device Update for disconnected devices behind the gateway. This article introduces two different configurations for deploying the MCC module on an IoT Edge gateway.

+If you have multiple IoT Edge gateways chained together, refer to the instructions in [Deploy the Microsoft Connected Cache module on nested gateways](./connected-cache-nested-level.md).

+## Deploy to a gateway with no proxy

+The following diagram describes the scenario where an Azure IoT Edge gateway has direct access to content deliver network (CDN) resources, and has the Microsoft Connected Cache module deployed on it. Behind the gateway, there's an IoT leaf device such as a Raspberry PI that is an internet isolated child device of the IoT Edge gateway.

+The following steps are an example of configuring the MCC environment variables to connect directly to the CDN with no proxy:

+1. Add the Microsoft Connected Cache module to your Azure IoT Edge gateway device deployment in Azure IoT Hub (see [Support for Disconnected Devices](connected-cache-disconnected-device-update.md) for details on how to get the module).

+2. Add the environment variables for the deployment. The following table is an example of the environment variables:

+ | Name | Value |

+ | -- | -- |

+ | CACHE_NODE_ID | See [environment variable](connected-cache-disconnected-device-update.md#module-environment-variables) descriptions |

+ | CUSTOMER_ID | See [environment variable](connected-cache-disconnected-device-update.md#module-environment-variables) descriptions |

+ | CUSTOMER_KEY | See [environment variable](connected-cache-disconnected-device-update.md#module-environment-variables) descriptions |

+ | STORAGE_1_SIZE_GB | 10 |

+3. Add the container create options for the deployment. For example:

+ ```json

+ {

+ "HostConfig": {

+ "Binds": [

+ "/MicrosoftConnectedCache1/:/nginx/cache1/"

+ ],

+ "PortBindings": {

+ "8081/tcp": [

+ {

+ "HostPort": "80"

+ }

+ ],

+ "5000/tcp": [

+ {

+ "HostPort": "5100"

+ }

+ ]

+ }

+ }

+ }

+ ```

+For a validation of properly functioning Microsoft Connected Cache, execute the following command in the terminal of the IoT Edge device hosting the module or any device on the network. Replace \<Azure IoT Edge Gateway IP\> with the IP address or hostname of your IoT Edge gateway. For information on the visibility of this report, see [Microsoft Connected Cache summary report](./connected-cache-disconnected-device-update.md#microsoft-connected-cache-summary-report).

+wget http://<IoT Edge Gateway IP>/mscomtest/wuidt.gif?cacheHostOrigin=au.download.windowsupdate.com

+## Deploy to a gateway with outbound unauthenticated proxy

+In this scenario, an Azure IoT Edge Gateway has access to content delivery network (CDN) resources through an outbound unauthenticated proxy. Microsoft Connected Cache is configured to cache content from a custom repository and the summary report is visible to anyone on the network.

+The following steps are an example of configuring the MCC environment variables to support an outbound unauthenticated proxy:

+ | Name | Value |

+ | -- | - |

+ | CACHE_NODE_ID | See [environment variable](connected-cache-disconnected-device-update.md#module-environment-variables) descriptions |

+ | CUSTOMER_ID | See [environment variable](connected-cache-disconnected-device-update.md#module-environment-variables) descriptions |

+ | CUSTOMER_KEY | See [environment variable](connected-cache-disconnected-device-update.md#module-environment-variables) descriptions |

+ | STORAGE_1_SIZE_GB | 10 |

+ | CACHEABLE_CUSTOM_1_HOST | Packagerepo.com:80 |

+ | CACHEABLE_CUSTOM_1_CANONICAL | Packagerepo.com |

+ | IS_SUMMARY_ACCESS_UNRESTRICTED| true |

+ | UPSTREAM_PROXY | Your proxy server IP or FQDN |

+3. Add the container create options for the deployment. For example:

+ ```json

+ {

+ "HostConfig": {

+ "Binds": [

+ "/MicrosoftConnectedCache1/:/nginx/cache1/"

+ ],

+ "PortBindings": {

+ "8081/tcp": [

+ {

+ "HostPort": "80"

+ }

+ ],

+ "5000/tcp": [

+ {

+ "HostPort": "5100"

+ }

+ ]

+ }

+ }

+ }

+ ```

+For a validation of properly functioning Microsoft Connected Cache, execute the following command in the terminal of the Azure IoT Edge device hosting the module or any device on the network. Replace \<Azure IoT Edge Gateway IP\> with the IP address or hostname of your IoT Edge gateway. For information on the visibility of this report, see [Microsoft Connected Cache summary report](./connected-cache-disconnected-device-update.md#microsoft-connected-cache-summary-report).

+wget http://<Azure IoT Edge Gateway IP>/mscomtest/wuidt.gif?cacheHostOrigin=au.download.windowsupdate.com

+ Title: Azure IoT device SDKs lifecycle and support

+description: Describe the lifecycle and support for our IoT Hub and DPS device SDKs

+# Azure IoT Device SDK lifecycle and support

+The article describes the Azure IoT Device SDK lifecycle and support policy. For more information, see [Azure SDK Lifecycle and support policy](https://azure.github.io/azure-sdk/policies_support.html).

+## Package lifecycle

+The releases fall into the following categories, each with a defined support structure.

+1. **Beta** - Also known as Preview or Release Candidate. Available for early access and feedback purposes and **is not recommended** for use in production. The preview version support is limited to GitHub issues. Preview releases typically live for less than six months, after which they're either deprecated or released as active.

+1. **Active** - Generally available and fully supported, receives new feature updates, as well as bug and security fixes. We recommend that customers use the **latest version** because that version receives fixes and updates.

+1. **Deprecated** - Superseded by a more recent release. Deprecation occurs at the same time the new release becomes active. Deprecated releases address the most critical bug fixes and security fixes for another **12 months**.

+## Get support

+If you experience problems while using the Azure IoT SDKs, there are several ways to seek support:

+* **Reporting bugs** - All customers can report bugs on the issues page for the GitHub repository associated with the relevant SDK.

+* **Microsoft Customer Support team** - Users who have a [support plan](https://azure.microsoft.com/support/plans/) can engage the Microsoft Customer Support team by creating a support ticket directly from the [Azure portal](https://portal.azure.com/signin/index/?feature.settingsportalinstance=mpac).

+ Title: Analyze and visualize your IoT data

+description: An overview of the available options to analyze and visualize data in an IoT solution.

+# As a solution builder, I want a high-level overview of the options for analyzing and visualizing device data in an IoT solution.

+# Analyze and visualize your IoT data

+This overview introduces the key concepts around the options to analyze and visualize your IoT data. Each section includes links to content that provides further detail and guidance.

+The following diagram shows a high-level view of the components in a typical IoT solution. This article focuses on the areas relevant to analyzing and visualizing your IoT data.

+In A