-# Execute employee offboarding tasks in real-time on their last day of work with Azure portal (preview)

-This off-boarding scenario will run a workflow on-demand and accomplish the following tasks:

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

- 7. Next, you'll configure the basic information about the workflow. Select **Next:Review tasks** when you're done with this step.

- 11. A panel with the list of available users will pop up on the right side of the screen. Select **Select** when you're done with your selection.

-Now that the workflow is created, it will automatically run the workflow every 3 hours. Lifecycle workflows will check every 3 hours for users in the associated execution condition and execute the configured tasks for those users. However, for the tutorial, we would like to run it immediately. To run a workflow immediately, we can use the on-demand feature.

-At any time, you may monitor the status of the workflows and the tasks. As a reminder, there are three different data pivots, users runs, and tasks that are currently available in public preview. You may learn more in the how-to guide [Check the status of a workflow (preview)](check-status-workflow.md). In the course of this tutorial, we'll look at the status using the user focused reports.

- 1. To begin, select the **Workflow history (Preview)** tab on the left to view the user summary and associated workflow tasks and statuses.

-1. Once the **Workflow history (Preview)** tab has been selected, you'll land on the workflow history page as shown.

-The prehire scenario can be broken down into the following:

-## Create a workflow using pre-hire template

-Use the following steps to create a prehire workflow that will generate a TAP and send it via email to the user's manager using the Azure portal.

- 7. Next, you'll configure the basic information about the workflow. This information includes when the workflow triggers, known as **Days from event**. So in this case, the workflow triggers two days before the employee's hire date. On the onboard prehire employee screen, add the following settings and then select **Next: Configure Scope**.

- 8. Next, you'll configure the scope. The scope determines which users this workflow runs against. In this case, it is on all users in the Sales department. On the configure scope screen, under **Rule** add the following settings and then select **Next: Review tasks**. For a full list of supported user properties, 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).

-At any time, you may monitor the status of the workflows and the tasks. As a reminder, there are three different data pivots, users runs, and tasks that are currently available in public preview. You may learn more in the how-to guide [Check the status of a workflow (preview)](check-status-workflow.md). In the course of this tutorial, we'll look at the status using the user focused reports.

- 1. To begin, select the **Workflow history (Preview)** tab on the left to view the user summary and associated workflow tasks and statuses.

-1. Once the **Workflow history (Preview)** tab has been selected, you'll land on the workflow history page as shown.

-For the on-boarding and off-boarding tutorials you'll need accounts for which the workflows will be executed, the following section will help you prepare these accounts, if you already have test accounts that meet the following requirements you can proceed directly to the on-boarding and off-boarding tutorials. Two accounts are required for the on-boarding tutorials, one account for the new hire and another account that acts as the manager of the new hire. The new hire account must have the following attributes set:

-In most cases, users are going to be provisioned to Azure AD either from an on-premises solution (Azure AD Connect, Cloud sync, etc.) or with an HR solution. These users will have the attributes and values populated at the time of creation. Setting up the infrastructure to provision users is outside the scope of this tutorial. For information, see [Tutorial: Basic Active Directory environment](../cloud-sync/tutorial-basic-ad-azure.md) and [Tutorial: Integrate a single forest with a single Azure AD tenant](../cloud-sync/tutorial-single-forest.md)

-We'll use the Graph Explorer to quickly create two users needed to execute the Lifecycle Workflows in the tutorials. One user will represent our new employee and the second will represent the new employee's manager.

-You'll need to edit the POST and replace the <your tenant name here> portion with the name of your tenant. For example: $UPN_manager = "bsimon@<your tenant name here>" to $UPN_manager = "bsimon@contoso.onmicrosoft.com".

-First we'll create our employee, Melva Prince.

- 4. Copy the code below in to the **Request body**

- 5. Replace `<your tenant here>` in the code below with the value of your Azure AD tenant.

- 7. Copy the ID that is returned in the results. This will be used later to assign a manager.

-Next, we'll create Britta Simon. This is the account that will be used as our manager.

- 3. Copy the code below in to the **Request body**

- 4. Replace `<your tenant here>` in the code below with the value of your Azure AD tenant.

- 6. Copy the ID that is returned in the results. This will be used later to assign a manager.

-As an alternative, the following PowerShell script may also be used to quickly create two users needed execute a lifecycle workflow. One user will represent our new employee and the second will represent the new employee's manager.

-In order to create this step, save the PowerShell script below to a location on a machine that has access to Azure.

-After editing the script, save it and follow the steps below.

-For the tutorial, the **mail** attribute only needs to be set on the manager account and the **manager** attribute set on the employee account. Use the following steps below.

- 8. At the top, change **GET** to **PATCH** and add `https://graph.microsoft.com/v1.0/users/<id>` to the box. Replace `<id>` with the value we copied above.

- 4. Replace `<managerid>` in the code below with the value of Britta Simons ID.

-In this scenario, we'll use this feature of Azure AD to generate a temporary access pass for our new employee. It will then be mailed to the employee's manager.

-While you can route egress traffic through an Azure Load Balancer, there are limitations on the amount of outbound flows of traffic you can have. Azure NAT Gateway allows up to 64,512 outbound UDP and TCP traffic flows per IP address with a maximum of 16 IP addresses.

-To create an AKS cluster with a new Managed NAT Gateway, use `--outbound-type managedNATGateway`, `--nat-gateway-managed-outbound-ip-count`, and `--nat-gateway-idle-timeout` when running `az aks create`. The following example creates a *myResourceGroup* resource group, then creates a *natCluster* AKS cluster in *myResourceGroup* with a Managed NAT Gateway, two outbound IPs, and an idle timeout of 30 seconds.

-| metadata | Adds a custom property to the Application Insights [Trace](../azure-monitor/app/data-model-trace-telemetry.md) telemetry. | No |

-If using a proxy, Azure Arc resource bridge must be configured for proxy so that it can connect to the Azure services. To configure the Arc resource bridge with proxy, provide the proxy certificate file path during creation of the configuration files. Only pass the single proxy certificate. If a certificate bundle is passed then the deployment will fail. Proxy configuration of the management machine isn't configured by the Azure Arc resource bridge.

-In addition to collecting [Metrics](standard-metrics.md) and application [Telemetry](data-model.md) data, which describe application activities and health, Application Insights can also be used to collect and store application [trace logging data](asp-net-trace-logs.md).

-Failed dependency calls will have the `success` field set to False. The module `DependencyTrackingTelemetryModule` doesn't report `ExceptionTelemetry`. The full data model for dependency is described [Dependency telemetry: Application Insights data model](data-model-dependency-telemetry.md).

-* See [data model](./data-model.md) for Application Insights types and data model.

-Auto-instrumentation quickly and easily enables [Application Insights](app-insights-overview.md) to make [telemetry](data-model.md) like metrics, requests, and dependencies available in your [Application Insights resource](create-workspace-resource.md).

-Application Insights defines a [data model](../../azure-monitor/app/data-model.md) for distributed telemetry correlation. To associate telemetry with a logical operation, every telemetry item has a context field called `operation_Id`. This identifier is shared by every telemetry item in the distributed trace. So even if you lose telemetry from a single layer, you can still associate telemetry reported by other components.

-A distributed logical operation typically consists of a set of smaller operations that are requests processed by one of the components. These operations are defined by [request telemetry](../../azure-monitor/app/data-model-request-telemetry.md). Every request telemetry item has its own `id` that identifies it uniquely and globally. And all telemetry items (such as traces and exceptions) that are associated with the request should set the `operation_parentId` to the value of the request `id`.

-Every outgoing operation, such as an HTTP call to another component, is represented by [dependency telemetry](../../azure-monitor/app/data-model-dependency-telemetry.md). Dependency telemetry also defines its own `id` that's globally unique. Request telemetry, initiated by this dependency call, uses this `id` as its `operation_parentId`.

-For more information, see [Application Insights telemetry data model](../../azure-monitor/app/data-model.md).

-description: Learn about the Application Insights telemetry context data model.

-# Telemetry context: Application Insights data model

-Every telemetry item might have a strongly typed context field. Every field enables a specific monitoring scenario. Use the custom properties collection to store custom or application-specific contextual information.

-## Application version

-Information in the application context fields is always about the application that's sending the telemetry. The application version is used to analyze trend changes in the application behavior and its correlation to the deployments.

-**Maximum length:** 1,024

-## Client IP address

-This field is the IP address of the client device. IPv4 and IPv6 are supported. When telemetry is sent from a service, the location context is about the user who initiated the operation in the service. Application Insights extract the geo-location information from the client IP and then truncate it. The client IP by itself can't be used as user identifiable information.

-**Maximum length:** 46

-## Device type

-Originally, this field was used to indicate the type of the device the user of the application is using. Today it's used primarily to distinguish JavaScript telemetry with the device type `Browser` from server-side telemetry with the device type `PC`.

-**Maximum length:** 64

-## Operation ID

-This field is the unique identifier of the root operation. This identifier allows grouping telemetry across multiple components. For more information, see [Telemetry correlation](./correlation.md). The operation ID is created by either a request or a page view. All other telemetry sets this field to the value for the containing request or page view.

-**Maximum length:** 128

-## Parent operation ID

-This field is the unique identifier of the telemetry item's immediate parent. For more information, see [Telemetry correlation](./correlation.md).

-**Maximum length:** 128

-## Operation name

-This field is the name (group) of the operation. The operation name is created by either a request or a page view. All other telemetry items set this field to the value for the containing request or page view. The operation name is used for finding all the telemetry items for a group of operations (for example, `GET Home/Index`). This context property is used to answer questions like What are the typical exceptions thrown on this page?

-**Maximum length:** 1,024

-## Synthetic source of the operation

-This field is the name of the synthetic source. Some telemetry from the application might represent synthetic traffic. It might be the web crawler indexing the website, site availability tests, or traces from diagnostic libraries like the Application Insights SDK itself.

-**Maximum length:** 1,024

-## Session ID

-Session ID is the instance of the user's interaction with the app. Information in the session context fields is always about the user. When telemetry is sent from a service, the session context is about the user who initiated the operation in the service.

-**Maximum length:** 64

-## Anonymous user ID

-The anonymous user ID (User.Id) represents the user of the application. When telemetry is sent from a service, the user context is about the user who initiated the operation in the service.

-[Sampling](./sampling.md) is one of the techniques to minimize the amount of collected telemetry. A sampling algorithm attempts to either sample in or out all the correlated telemetry. An anonymous user ID is used for sampling score generation, so an anonymous user ID should be a random enough value.

-> [!NOTE]

-> The count of anonymous user IDs isn't the same as the number of unique application users. The count of anonymous user IDs is typically higher because each time the user opens your app on a different device or browser, or cleans up browser cookies, a new unique anonymous user ID is allocated. This calculation might result in counting the same physical users multiple times.

-User IDs can be cross referenced with session IDs to provide unique telemetry dimensions and establish user activity over a session duration.

-Using an anonymous user ID to store a username is a misuse of the field. Use an authenticated user ID.

-**Maximum length:** 128

-## Authenticated user ID

-An authenticated user ID is the opposite of an anonymous user ID. This field represents the user with a friendly name. This ID is only collected by default with the ASP.NET Framework SDK's [`AuthenticatedUserIdTelemetryInitializer`](https://github.com/microsoft/ApplicationInsights-dotnet/blob/develop/WEB/Src/Web/Web/AuthenticatedUserIdTelemetryInitializer.cs).

-Use the Application Insights SDK to initialize the authenticated user ID with a value that identifies the user persistently across browsers and devices. In this way, all telemetry items are attributed to that unique ID. This ID enables querying for all telemetry collected for a specific user (subject to [sampling configurations](./sampling.md) and [telemetry filtering](./api-filtering-sampling.md)).

-User IDs can be cross referenced with session IDs to provide unique telemetry dimensions and establish user activity over a session duration.

-**Maximum length:** 1,024

-## Account ID

-The account ID, in multi-tenant applications, is the tenant account ID or name that the user is acting with. It's used for more user segmentation when a user ID and an authenticated user ID aren't sufficient. Examples might be a subscription ID for the Azure portal or the blog name for a blogging platform.

-**Maximum length:** 1,024

-## Cloud role

-This field is the name of the role of which the application is a part. It maps directly to the role name in Azure. It can also be used to distinguish micro services, which are part of a single application.

-**Maximum length:** 256

-## Cloud role instance

-This field is the name of the instance where the application is running. For example, it's the computer name for on-premises or the instance name for Azure.

-**Maximum length:** 256

-## Internal: SDK version

-For more information, see this [SDK version article](https://github.com/MohanGsk/ApplicationInsights-Home/blob/master/EndpointSpecs/SDK-VERSIONS.md).

-**Maximum length:** 64

-## Internal: Node name

-This field represents the node name used for billing purposes. Use it to override the standard detection of nodes.

-**Maximum length:** 256

-## Next steps

-description: Application Insights data model for dependency telemetry

-# Dependency telemetry: Application Insights data model

-Dependency Telemetry (in [Application Insights](./app-insights-overview.md)) represents an interaction of the monitored component with a remote component such as SQL or an HTTP endpoint.

-## Name

-Name of the command initiated with this dependency call. Low cardinality value. Examples are stored procedure name and URL path template.

-## ID

-Identifier of a dependency call instance. Used for correlation with the request telemetry item corresponding to this dependency call. For more information, see [correlation](./correlation.md) page.

-## Data

-Command initiated by this dependency call. Examples are SQL statement and HTTP URL with all query parameters.

-## Type

-Dependency type name. Low cardinality value for logical grouping of dependencies and interpretation of other fields like commandName and resultCode. Examples are SQL, Azure table, and HTTP.

-## Target

-Target site of a dependency call. Examples are server name, host address. For more information, see [correlation](./correlation.md) page.

-## Duration

-Request duration in format: `DD.HH:MM:SS.MMMMMM`. Must be less than `1000` days.

-## Result code

-Result code of a dependency call. Examples are SQL error code and HTTP status code.

-## Success

-Indication of successful or unsuccessful call.

-## Custom properties

-## Custom measurements

-## Next steps

-description: Learn about the Application Insights data model for event telemetry.

-# Event telemetry: Application Insights data model

-You can create event telemetry items (in [Application Insights](./app-insights-overview.md)) to represent an event that occurred in your application. Typically, it's a user interaction such as a button click or order checkout. It can also be an application lifecycle event like initialization or a configuration update.

-Semantically, events may or may not be correlated to requests. However, if used properly, event telemetry is more important than requests or traces. Events represent business telemetry and should be subject to separate, less aggressive [sampling](./api-filtering-sampling.md).

-## Name

-Event name: To allow proper grouping and useful metrics, restrict your application so that it generates a few separate event names. For example, don't use a separate name for each generated instance of an event.

-**Maximum length:** 512 characters

-## Custom properties

-## Custom measurements

-## Next steps

-description: Application Insights data model for exception telemetry

-# Exception telemetry: Application Insights data model

-In [Application Insights](./app-insights-overview.md), an instance of Exception represents a handled or unhandled exception that occurred during execution of the monitored application.

-## Problem Id

-Identifier of where the exception was thrown in code. Used for exceptions grouping. Typically a combination of exception type and a function from the call stack.

-Max length: 1024 characters

-## Severity level

-Trace severity level. Value can be `Verbose`, `Information`, `Warning`, `Error`, `Critical`.

-## Exception details

-(To be extended)

-## Custom properties

-## Custom measurements

-## Next steps

-description: Application Insights data model for metric telemetry

-# Metric telemetry: Application Insights data model

-There are two types of metric telemetry supported by [Application Insights](./app-insights-overview.md): single measurement and pre-aggregated metric. Single measurement is just a name and value. Pre-aggregated metric specifies minimum and maximum value of the metric in the aggregation interval and standard deviation of it.

-Pre-aggregated metric telemetry assumes that aggregation period was one minute.

-There are several well-known metric names supported by Application Insights. These metrics placed into performanceCounters table.

-Metric representing system and process counters:

-| **.NET name** | **Platform agnostic name** | **Description**

-| - | -- | -

-| `\Processor(_Total)\% Processor Time` | Work in progress... | total machine CPU

-| `\Memory\Available Bytes` | Work in progress... | Shows the amount of physical memory, in bytes, available to processes running on the computer. It is calculated by summing the amount of space on the zeroed, free, and standby memory lists. Free memory is ready for use; zeroed memory consists of pages of memory filled with zeros to prevent later processes from seeing data used by a previous process; standby memory is memory that has been removed from a process's working set (its physical memory) en route to disk but is still available to be recalled. See [Memory Object](/previous-versions/ms804008(v=msdn.10))

-| `\Process(??APP_WIN32_PROC??)\% Processor Time` | Work in progress... | CPU of the process hosting the application

-| `\Process(??APP_WIN32_PROC??)\Private Bytes` | Work in progress... | memory used by the process hosting the application

-| `\Process(??APP_WIN32_PROC??)\IO Data Bytes/sec` | Work in progress... | rate of I/O operations runs by process hosting the application

-| `\ASP.NET Applications(??APP_W3SVC_PROC??)\Requests/Sec` | Work in progress... | rate of requests processed by application

-| `\.NET CLR Exceptions(??APP_CLR_PROC??)\# of Exceps Thrown / sec` | Work in progress... | rate of exceptions thrown by application

-| `\ASP.NET Applications(??APP_W3SVC_PROC??)\Request Execution Time` | Work in progress... | average requests execution time

-| `\ASP.NET Applications(??APP_W3SVC_PROC??)\Requests In Application Queue` | Work in progress... | number of requests waiting for the processing in a queue

-See [Metrics - Get](/rest/api/application-insights/metrics/get) for more information on the Metrics REST API.

-## Name

-Name of the metric you'd like to see in Application Insights portal and UI.

-## Value

-Single value for measurement. Sum of individual measurements for the aggregation.

-## Count

-Metric weight of the aggregated metric. Should not be set for a measurement.

-## Min

-Minimum value of the aggregated metric. Should not be set for a measurement.

-## Max

-Maximum value of the aggregated metric. Should not be set for a measurement.

-## Standard deviation

-Standard deviation of the aggregated metric. Should not be set for a measurement.

-## Custom properties

-Metric with the custom property `CustomPerfCounter` set to `true` indicate that the metric represents the Windows performance counter. These metrics placed in performanceCounters table. Not in customMetrics. Also the name of this metric is parsed to extract category, counter, and instance names.

-## Next steps

-description: Application Insights data model for page view telemetry

-# PageView telemetry: Application Insights data model

-PageView telemetry (in [Application Insights](./app-insights-overview.md)) is logged when an application user opens a new page of a monitored application. The `Page` in this context is a logical unit that is defined by the developer to be an application tab or a screen and isn't necessarily correlated to a browser webpage load or refresh action. This distinction can be further understood in the context of single-page applications (SPA) where the switch between pages isn't tied to browser page actions. [`pageViews.duration`](/azure/azure-monitor/reference/tables/pageviews) is the time it takes for the application to present the page to the user.

-> [!NOTE]

-> * By default, Application Insights SDKs log single PageView events on each browser webpage load action, with [`pageViews.duration`](/azure/azure-monitor/reference/tables/pageviews) populated by [browser timing](#measuring-browsertiming-in-application-insights). Developers can extend additional tracking of PageView events by using the [trackPageView API call](./api-custom-events-metrics.md#page-views).

-> * The default logs retention is 30 days and needs to be adjusted if you want to view page view statistics over a longer period of time.

-## Measuring browserTiming in Application Insights

-Modern browsers expose measurements for page load actions with the [Performance API](https://developer.mozilla.org/en-US/docs/Web/API/Performance_API). Application Insights simplifies these measurements by consolidating related timings into [standard browser metrics](../essentials/metrics-supported.md#microsoftinsightscomponents) as defined by these processing time definitions:

-1. Client <--> DNS: Client reaches out to DNS to resolve website hostname, DNS responds with IP address.

-1. Client <--> Web Server: Client creates TCP then TLS handshakes with web server.

-1. Client <--> Web Server: Client sends request payload, waits for server to execute request, and receives first response packet.

-1. Client <--Web Server: Client receives the rest of the response payload bytes from the web server.

-1. Client: Client now has full response payload and has to render contents into browser and load the DOM.

-

-* `browserTimings/networkDuration` = #1 + #2

-* `browserTimings/sendDuration` = #3

-* `browserTimings/receiveDuration` = #4

-* `browserTimings/processingDuration` = #5

-* `browsertimings/totalDuration` = #1 + #2 + #3 + #4 + #5

-* `pageViews/duration`

- * The PageView duration is from the browserΓÇÖs performance timing interface, [`PerformanceNavigationTiming.duration`](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceEntry/duration).

- * If `PerformanceNavigationTiming` is available that duration is used.

- * If itΓÇÖs not, then the *deprecated* [`PerformanceTiming`](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceTiming) interface is used and the delta between [`NavigationStart`](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceTiming/navigationStart) and [`LoadEventEnd`](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceTiming/loadEventEnd) is calculated.

- * The developer specifies a duration value when logging custom PageView events using the [trackPageView API call](./api-custom-events-metrics.md#page-views).

-

-description: This article describes the Application Insights data model for request telemetry.

-# Request telemetry: Application Insights data model

-A request telemetry item in [Application Insights](./app-insights-overview.md) represents the logical sequence of execution triggered by an external request to your application. Every request execution is identified by a unique `id` and `url` that contain all the execution parameters.

-You can group requests by logical `name` and define the `source` of this request. Code execution can result in `success` or `fail` and has a certain `duration`. Both success and failure executions can be grouped further by `resultCode`. Start time for the request telemetry is defined on the envelope level.

-Request telemetry supports the standard extensibility model by using custom `properties` and `measurements`.

-## Name

-The name of the request represents the code path taken to process the request. A low cardinality value allows for better grouping of requests. For HTTP requests, it represents the HTTP method and URL path template like `GET /values/{id}` without the actual `id` value.

-The Application Insights web SDK sends a request name "as is" about letter case. Grouping on the UI is case sensitive, so `GET /Home/Index` is counted separately from `GET /home/INDEX` even though often they result in the same controller and action execution. The reason for that is that URLs in general are [case sensitive](https://www.w3.org/TR/WD-html40-970708/htmlweb.html). You might want to see if all `404` errors happened for URLs typed in uppercase. You can read more about request name collection by the ASP.NET web SDK in the [blog post](https://apmtips.com/posts/2015-02-23-request-name-and-url/).

-**Maximum length**: 1,024 characters

-## ID

-ID is the identifier of a request call instance. It's used for correlation between the request and other telemetry items. The ID should be globally unique. For more information, see [Telemetry correlation in Application Insights](./correlation.md).

-**Maximum length**: 128 characters

-## URL

-URL is the request URL with all query string parameters.

-**Maximum length**: 2,048 characters

-## Source

-Source is the source of the request. Examples are the instrumentation key of the caller or the IP address of the caller. For more information, see [Telemetry correlation in Application Insights](./correlation.md).

-**Maximum length**: 1,024 characters

-## Duration

-The request duration is formatted as `DD.HH:MM:SS.MMMMMM`. It must be positive and less than `1000` days. This field is required because request telemetry represents the operation with the beginning and the end.

-## Response code

-The response code is the result of a request execution. It's the HTTP status code for HTTP requests. It might be an `HRESULT` value or an exception type for other request types.

-**Maximum length**: 1,024 characters

-## Success

-Success indicates whether a call was successful or unsuccessful. This field is required. When a request isn't set explicitly to `false`, it's considered to be successful. Set this value to `false` if the operation was interrupted by an exception or a returned error result code.

-For web applications, Application Insights defines a request as successful when the response code is less than `400` or equal to `401`. However, there are cases when this default mapping doesn't match the semantics of the application.

-Response code `404` might indicate "no records," which can be part of regular flow. It also might indicate a broken link. For broken links, you can implement more advanced logic. You can mark broken links as failures only when those links are located on the same site by analyzing the URL referrer. Or you can mark them as failures when they're accessed from the company's mobile application. Similarly, `301` and `302` indicate failure when they're accessed from the client that doesn't support redirect.

-Partially accepted content `206` might indicate a failure of an overall request. For instance, an Application Insights endpoint might receive a batch of telemetry items as a single request. It returns `206` when some items in the batch weren't processed successfully. An increasing rate of `206` indicates a problem that needs to be investigated. Similar logic applies to `207` Multi-Status where the success might be the worst of separate response codes.

-You can read more about the request result code and status code in the [blog post](https://apmtips.com/posts/2016-12-03-request-success-and-response-code/).

-## Custom properties

-## Custom measurements

-## Next steps

-description: Application Insights data model for trace telemetry.

-# Trace telemetry: Application Insights data model

-Trace telemetry in [Application Insights](./app-insights-overview.md) represents `printf`-style trace statements that are text searched. `Log4Net`, `NLog`, and other text-based log file entries are translated into instances of this type. The trace doesn't have measurements as an extensibility.

-## Message

-Trace message.

-**Maximum length**: 32,768 characters

-## Severity level

-Trace severity level.

-**Values**: `Verbose`, `Information`, `Warning`, `Error`, and `Critical`

-## Custom properties

-## Next steps

-description: This article presents an overview of the Application Insights telemetry data model.

-# Application Insights telemetry data model

-[Application Insights](./app-insights-overview.md) sends telemetry from your web application to the Azure portal so that you can analyze the performance and usage of your application. The telemetry model is standardized, so it's possible to create platform and language-independent monitoring.

-Data collected by Application Insights models this typical application execution pattern.

-

-The following types of telemetry are used to monitor the execution of your app. Three types are automatically collected by the Application Insights SDK from the web application framework:

-* [Request](data-model-request-telemetry.md): Generated to log a request received by your app. For example, the Application Insights web SDK automatically generates a Request telemetry item for each HTTP request that your web app receives.

- An *operation* is made up of the threads of execution that process a request. You can also [write code](./api-custom-events-metrics.md#trackrequest) to monitor other types of operation, such as a "wake up" in a web job or function that periodically processes data. Each operation has an ID. The ID can be used to [group](./correlation.md) all telemetry generated while your app is processing the request. Each operation either succeeds or fails and has a duration of time.

-* [Exception](data-model-exception-telemetry.md): Typically represents an exception that causes an operation to fail.

-* [Dependency](data-model-dependency-telemetry.md): Represents a call from your app to an external service or storage, such as a REST API or SQL. In ASP.NET, dependency calls to SQL are defined by `System.Data`. Calls to HTTP endpoints are defined by `System.Net`.

-Application Insights provides three data types for custom telemetry:

-* [Trace](data-model-trace-telemetry.md): Used either directly or through an adapter to implement diagnostics logging by using an instrumentation framework that's familiar to you, such as `Log4Net` or `System.Diagnostics`.

-* [Event](data-model-event-telemetry.md): Typically used to capture user interaction with your service to analyze usage patterns.

-* [Metric](data-model-metric-telemetry.md): Used to report periodic scalar measurements.

-Every telemetry item can define the [context information](data-model-context.md) like application version or user session ID. Context is a set of strongly typed fields that unblocks certain scenarios. When application version is properly initialized, Application Insights can detect new patterns in application behavior correlated with redeployment.

-You can use session ID to calculate an outage or an issue impact on users. Calculating the distinct count of session ID values for a specific failed dependency, error trace, or critical exception gives you a good understanding of an impact.

-The Application Insights telemetry model defines a way to [correlate](./correlation.md) telemetry to the operation of which it's a part. For example, a request can make a SQL Database call and record diagnostics information. You can set the correlation context for those telemetry items that tie it back to the request telemetry.

-## Schema improvements

-The Application Insights data model is a basic yet powerful way to model your application telemetry. We strive to keep the model simple and slim to support essential scenarios and allow the schema to be extended for advanced use.

-To report data model or schema problems and suggestions, use our [GitHub repository](https://github.com/microsoft/ApplicationInsights-dotnet/issues/new/choose).

-## Next steps

- A semi-colon delimited list of types that you don't want to be subject to sampling. Recognized types are: [`Dependency`](data-model-dependency-telemetry.md), [`Event`](data-model-event-telemetry.md), [`Exception`](data-model-exception-telemetry.md), [`PageView`](data-model-pageview-telemetry.md), [`Request`](data-model-request-telemetry.md), [`Trace`](data-model-trace-telemetry.md). All telemetry of the specified types is transmitted; the types that aren't specified will be sampled.

- A semi-colon delimited list of types that you do want to subject to sampling. Recognized types are: [`Dependency`](data-model-dependency-telemetry.md), [`Event`](data-model-event-telemetry.md), [`Exception`](data-model-exception-telemetry.md), [`PageView`](data-model-pageview-telemetry.md), [`Request`](data-model-request-telemetry.md), [`Trace`](data-model-trace-telemetry.md). The specified types will be sampled; all telemetry of the other types will always be transmitted.

-The transaction diagnostics experience shows all telemetry in a [single operation](correlation.md#data-model-for-telemetry-correlation) that shares an [Operation ID](data-model-context.md#operation-id). By default, the Application Insights SDK for JavaScript creates a new operation for each unique page view. In a single-page application (SPA), only one page view event will be generated and a single Operation ID will be used for all telemetry generated. As a result, many events might be correlated to the same operation.

-> For information on an alternatives to using [anonymous IDs](./data-model-context.md#anonymous-user-id) and ensuring an accurate count, see the documentation for [authenticated IDs](./data-model-context.md#authenticated-user-id).

-Assign policies to enable resource logs and to send them to destinations according to your needs. Send logs to Event Hubs for third-party SIEM systems, enabling continuous security operations. Send logs to storage accounts for longer term storage or the fulfillment of regulatory compliance.

-A set of built-in policies and initiatives exists to direct resource logs to Log Analytics Workspaces, Event Hubs, and Storage Accounts. The policies enable audit logging, sending logs belonging to the **audit** log category group to an Event Hub, Log Analytics workspace or Storage Account. The policies' `effect` is `DeployIfNotExists`, which deploys the policy as a default if there aren't other settings defined.

- :::image type="content" source="./media/diagnostics-settings-policies-deployifnotexists/policy-definitions.png" alt-text="A screenshot of the policy definitions page.":::

-This policy deploys a diagnostic setting using a category group to route logs to an Event Hub.

-|eventHubAuthorizationRuleId|Event Hub Authorization Rule ID. The authorization rule is at event hub namespace level. For example, /subscriptions/{subscription ID}/resourceGroups/{resource group}/providers/Microsoft.EventHub/namespaces/{Event Hub namespace}/authorizationrules/{authorization rule}|||

-|eventHubName|Event Hub Name||Monitoring|

-To set up Azure Active Directory authentication, follow the steps bellow:

-| [Event](/azure/azure-monitor/reference/tables/event) | Partial support ΓÇô data arriving from Log Analytics agent (MMA) or Azure Monitor Agent (AMA) is fully supported. Data arriving via Diagnostics Extension agent is collected though storage while this path isnΓÇÖt supported. |

-description: Describes how to add a custom transformation to data flowing through Azure Monitor Logs using resource manager templates.

-# Tutorial: Add transformation in workspace data collection rule to Azure Monitor using resource manager templates

-This tutorial walks you through configuration of a sample [transformation in a workspace data collection rule](../essentials/data-collection-transformations.md) using resource manager templates. [Transformations](../essentials/data-collection-transformations.md) in Azure Monitor allow you to filter or modify incoming data before it's sent to its destination. Workspace transformations provide support for [ingestion-time transformations](../essentials/data-collection-transformations.md) for workflows that don't yet use the [Azure Monitor data ingestion pipeline](../essentials/data-collection.md).

-Workspace transformations are stored together in a single [data collection rule (DCR)](../essentials/data-collection-rule-overview.md) for the workspace, called the workspace DCR. Each transformation is associated with a particular table. The transformation will be applied to all data sent to this table from any workflow not using a DCR.

-> This tutorial uses resource manager templates and REST API to configure a workspace transformation. See [Tutorial: Add transformation in workspace data collection rule to Azure Monitor using the Azure portal](tutorial-workspace-transformations-portal.md) for the same tutorial using the Azure portal.

-> This tutorial uses PowerShell from Azure Cloud Shell to make REST API calls using the Azure Monitor **Tables** API and the Azure portal to install resource manager templates. You can use any other method to make these calls.

- :::image type="content" source="media/tutorial-workspace-transformations-api/open-cloud-shell.png" lightbox="media/tutorial-workspace-transformations-api/open-cloud-shell.png" alt-text="Screenshot of opening cloud shell.":::

-3. Paste the code into the cloud shell prompt to run it.

- :::image type="content" source="media/tutorial-workspace-transformations-api/cloud-shell-script.png" lightbox="media/tutorial-workspace-transformations-api/cloud-shell-script.png" alt-text="Screenshot of script in cloud shell.":::

-3. Paste the resource manager template below into the editor and then click **Save**. This template defines the DCR and contains the transformation query. You don't need to modify this template since it will collect values for its parameters.

- :::image type="content" source="media/tutorial-workspace-transformations-api/edit-template.png" lightbox="media/tutorial-workspace-transformations-api/edit-template.png" alt-text="Screenshot to edit resource manager template.":::

-1. Click the **Cloud shell** button to open cloud shell again. Copy the following PowerShell code and replace the parameters with values for your workspace and DCR.

-2. Paste the code into the cloud shell prompt to run it.

-Snapshot-Debugger|[ Troubleshoot problems enabling Application Insights Snapshot Debugger or viewing snapshots](/troubleshoot/azure/azure-monitor/app-insights/snapshot-debugger-troubleshoot.md)|Removing the TSG from the AzMon TOC and adding to the support TOC|

-Application-Insights|[Application Insights for Java 2.x](/previous-versions/azure/azure-monitor/app/deprecated-java-2x)|The Java 2.x retirement notice is available at https://azure.microsoft.com/updates/application-insights-java-2x-retirement.|

-| [Azure Application Insights Telemetry Data Model - Telemetry Context](app/data-model-context.md) | Clarified that Anonymous User ID is simply User.Id for easy selection in Intellisense.|

- * You cannot convert regular Azure NetApp Files volumes to large volumes.

- * You can only resize a large volume up to 30% of lowest provisioned size.

-* Large volumes aren't currently supported with Azure NetApp Files backup.

-* Large volumes aren't currently supported with cross-region replication.

-1. **Resource Region**. Choose **Global** unless your business or application requires a specific region. If you're planning on using the Document Translation feature with managed identity authentication, choose a non-global region.

-* Change the resource key for global regions. If you're using a regional specific resource, you can't change your resource key.

-Managed identities for Azure resources are service principals that create an Azure Active Directory (Azure AD) identity and specific permissions for Azure managed resources:

-* You can use managed identities to grant access to any resource that supports Azure AD authentication, including your own applications. Managed identities eliminate the need for you to include shared access signature tokens (SAS) with your HTTP requests.

-> * When using managed identities, don't include a SAS token URL with your HTTP requestsΓÇöyour requests will fail.

-> * Currently, Document Translation doesn't support managed identity in the global region. If you intend to use managed identities for Document Translation operations, [create your Translator resource](https://portal.azure.com/#create/Microsoft.CognitiveServicesTextTranslation) in a non-global Azure region.

-> * Managed identities are a safer way to grant access to data without having SAS tokens included with your HTTP requests.

-* A [**single-service Translator**](https://portal.azure.com/#create/Microsoft.CognitiveServicesTextTranslation) (not a multi-service Cognitive Services) resource assigned to a **non-global** region. For detailed steps, _see_ [Create a Cognitive Services resource using the Azure portal](../../../cognitive-services-apis-create-account.md?tabs=multiservice%2cwindows).

-> If a file with the same name already exists in the destination, the job will fail.

- Document Translation is a cloud-based feature of the [Azure Translator](../../translator-overview.md) service. You can use the Document Translation API to asynchronously translate whole documents in [supported languages](../../language-support.md) and various [file formats](../overview.md#supported-document-formats) while preserving source document structure and text formatting. In this how-to guide, you'll learn to use Document Translation APIs with a programming language of your choice and the HTTP REST API.

-To get started, you'll need:

-* An [**Azure blob storage account**](https://portal.azure.com/#create/Microsoft.StorageAccount-ARM). You'll create containers to store and organize your blob data within your storage account.

- 1. **Resource Region**. Choose **Global** unless your business or application requires a specific region. If you're planning on using a [system-assigned managed identity](create-use-managed-identities.md) for authentication, choose a **non-global** region.

-1. You'll paste it into the code ample to authenticate your request to the Document Translation service.

-You'll need to [**create containers**](../../../../storage/blobs/storage-quickstart-blobs-portal.md#create-a-container) in your [**Azure blob storage account**](https://portal.azure.com/#create/Microsoft.StorageAccount-ARM) for source and target files.

-* **Target container**. This container is where your translated files will be stored (required).

-A batch Document Translation request is submitted to your Translator service endpoint via a POST request. If successful, the POST method returns a `202 Accepted` response code and the batch request is created by the service. The translated documents will be listed in your target container.

-* Update the `build.gradle.kts` file. Keep in mind that you'll need to update your `mainClassName` depending on the sample:

-* You'll find the job `id` in the POST method response Header `Operation-Location` URL value. The last parameter of the URL is the operation's job **`id`**:

-Cancel currently processing or queued job. Only documents for which translation hasn't started will be canceled.

- Document Translation in [**Azure Cognitive Services Language Studio**](https://language.cognitive.azure.com/home) is a no-code user interface that lets you interactively translate documents from local or Azure blob storage .

- * **Resource Region**. For this project, choose a **non-global** region. For Document Translation, [system-assigned managed identity](how-to-guides/create-use-managed-identities.md) isn't supported in the global region.

-At least one **source document** is required. You can download our [document translation sample document](https://raw.githubusercontent.com/Azure-Samples/cognitive-services-REST-api-samples/master/curl/Translator/document-translation-sample.docx).

- Document Translation is a cloud-based feature of the [Azure Translator](../../translator-overview.md) service that asynchronously translates whole documents in [supported languages](../../language-support.md) and various [file formats](../overview.md#supported-document-formats). In this quickstart, learn to use Document Translation with a programming language of your choice to translate a source document into a target language while preserving structure and text formatting.

- 1. **Resource Region**. Choose **Global** unless your business or application requires a specific region. If you're planning on using a [system-assigned managed identity](../how-to-guides/create-use-managed-identities.md) for authentication, choose a **non-global** region.

- > [!div class="nextstepaction"]

- > [I ran into an issue with the prerequisites.](https://microsoft.qualtrics.com/jfe/form/SV_0Cl5zkG3CnDjq6O?Pillar=Language&Product=Document-translation&Page=quickstart&Section=Prerequisites)

- > [!div class="nextstepaction"]

- > [I ran into an issue retrieving my key and endpoint.](https://microsoft.qualtrics.com/jfe/form/SV_0Cl5zkG3CnDjq6O?Pillar=Language&Product=Document-translation&Page=quickstart&Section=Retrieve-your-keys-and-endpoint)

-You need to [**create containers**](../../../../storage/blobs/storage-quickstart-blobs-portal.md#create-a-container) in your [**Azure blob storage account**](https://portal.azure.com/#create/Microsoft.StorageAccount-ARM) for source and target files.

- > [!div class="nextstepaction"]

- > [I ran into an issue creating blob storage containers with authentication.](https://microsoft.qualtrics.com/jfe/form/SV_0Cl5zkG3CnDjq6O?Pillar=Language&Product=Document-translation&Page=quickstart&Section=Create-blob-storage-containers)

-For this project, you need a **source document** uploaded to your **source container**. You can download our [document translation sample document](https://raw.githubusercontent.com/Azure-Samples/cognitive-services-REST-api-samples/master/curl/Translator/document-translation-sample.docx) for this quickstart.

-Try the latest version of Azure Translator. In this quickstart, you'll get started using the Translator service to [translate text](reference/v3-0-translate.md) using a programming language of your choice or the REST API. For this project, we recommend using the free pricing tier (F0), while you're learning the technology, and later upgrading to a paid tier for production.

-To get started, you'll need an active Azure subscription. If you don't have an Azure subscription, you can [create one for free](https://azure.microsoft.com/free/cognitive-services/)

- * You need the key and endpoint from the resource to connect your application to the Translator service. You'll paste your key and endpoint into the code later in the quickstart. You can find these values on the Azure portal **Keys and Endpoint** page:

-To call the Translator service via the [REST API](reference/rest-api-guide.md), you'll need to include the following headers with each request. Don't worry, we'll include the headers for you in the sample code for each programming language.

-|**Ocp-Apim-Subscription-Region**|The region where your resource was created. |&bullet; ***Required*** when using a multi-service Cognitive Services or regional (non-global) resource.</br>&bullet; ***Optional*** when using a single-service global Translator Resource.

-The core operation of the Translator service is translating text. In this quickstart, you'll build a request using a programming language of your choice that takes a single source (`from`) and provides two outputs (`to`). Then we'll review some parameters that can be used to adjust both the request and the response.

-1. Run the `gradle init` command from the translator-text-app directory. This command will create essential build files for Gradle, including _build.gradle.kts_, which is used at runtime to create and configure your application.

- You'll create the following directory structure:

-|**Ocp-Apim-Subscription-Region**|The region where your resource was created. |<ul><li>***Required*** when using a multi-service Cognitive Services or regional (non-global) resource.</li><li> ***Optional*** when using a single-service Translator Resource.</li></ul>|

-For example, you can record 1:1 or 1:N scenarios for audio and video calls enabled by [Calling Client SDK](https://learn.microsoft.com/azure/communication-services/concepts/voice-video-calling/calling-sdk-features).

-But also, you can use Call Recording to record complex PSTN or VoIP inbound and outbound calling workflows managed by [Call Automation](https://learn.microsoft.com/azure/communication-services/concepts/voice-video-calling/call-automation).

-Regardless of how you establish the call, Call Recording allows you to produce mixed or unmixed media files that are stored for 48 hours on a built-in temporary storage. You can retrieve the files and take them to the long-term storage solution of your choice. Call Recording supports all Azure Communication Services data regions.

-Call Recording uses [Azure Event Grid](https://learn.microsoft.com/azure/event-grid/event-schema-communication-services) to provide you with notifications related to media and metadata.

-It's possible that when a call is created using Call Automation, you don't get a value in the `serverCallId`. If that's the case, get the `serverCallId` from the `CallConnected` event method described in [Get serverCallId](https://learn.microsoft.com/azure/communication-services/quickstarts/voice-video-calling/callflows-for-customer-interactions?pivots=programming-language-csharp#configure-programcs-to-answer-the-call).

-This quickstart gets you started with Call Recording for voice and video calls. To start using the Call Recording APIs, you must have a call in place. Make sure you're familiar with [Calling client SDK](get-started-with-video-calling.md) and/or [Call Automation](https://learn.microsoft.com/azure/communication-services/quickstarts/voice-video-calling/callflows-for-customer-interactions?pivots=programming-language-csharp#configure-programcs-to-answer-the-call) to build the end-user calling experience.

-# Tutorial: Create an Azure Files storage mount in Azure Container Apps

-Learn to write to permanent storage in a container app using an Azure Files storage mount.

-> [!NOTE]

-> The volume mounting features in Azure Container Apps are in preview.

-zone_pivot_groups: container-apps-config-types

-| [Temporary storage](#temporary-storage) | Temporary storage scoped to an individual replica | Sharing files between containers in a replica. For instance, the main app container can write log files that are processed by a sidecar container. |

-> [!NOTE]

-> The volume mounting features in Azure Container Apps are in preview.

-## Temporary storage

-You can mount an ephemeral volume that is equivalent to [emptyDir](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir) in Kubernetes. Temporary storage is scoped to a single replica.

-Temporary storage has the following characteristics:

-* A container can mount multiple temporary volumes.

-* There are no capacity guarantees. The available storage depends on the amount of disk space available in the replica.

-To configure temporary storage, first define an `EmptyDir` volume in the revision. Then define a volume mount in one or more containers in the revision.

-When using temporary storage, you must use the Azure CLI with a YAML definition to create or update your container app.

-1. To update an existing container app to use temporary storage, export your app's specification to a YAML file named *app.yaml*.

- - Add a `volumes` array to the `template` section of your container app definition and define a volume.

- - For each container in the template that you want to mount temporary storage, add a `volumeMounts` array to the container definition and define a volume mount.

-To create a temporary volume and mount it in a container, make the following changes to the container apps resource in an ARM template:

-## Azure Files

-You can mount a file share from [Azure Files](../storage/files/index.yml) as a volume inside a container.

-For a step-by-step tutorial, refer to [Create an Azure Files storage mount in Azure Container Apps](storage-mounts-azure-files.md).

-* Create a storage definition of type `AzureFile` in the Container Apps environment.

-* Define a storage volume in a revision.

-When using Azure Files, you must use the Azure CLI with a YAML definition to create or update your container app.

-1. Add a storage definition of type `AzureFile` to your Container Apps environment.

- - Add a `volumes` array to the `template` section of your container app definition and define a volume.

- - For each container in the template that you want to mount Azure Files storage, add a `volumeMounts` array to the container definition and define a volume mount.

- - Add a `volumes` array to the `template` section of your container app definition and define a volume.

- - For each container in the template that you want to mount Azure Files storage, add a `volumeMounts` array to the container definition and define a volume mount.

-### RntbdRequestStats

-* `ChannelAcquisitionStarted`: The time to get or create a new connection. You can create new connections for numerous different regions. For example, let's say that a connection was unexpectedly closed, or too many requests were getting sent through the existing connections. You create a new connection.

-* *Pipelined time is large* might be caused by a large request.

-* *Transit time is large*, which leads to a networking problem. Compare this number to the `BELatencyInMs`. If `BELatencyInMs` is small, then the time was spent on the network, and not on the Azure Cosmos DB service.

-* *Received time is large* might be caused by a thread starvation problem. This is the time between having the response and returning the result.

-After you reset the device, you'll need to reactivate the device as a new resource. After placing a new order, you'll need to reconfigure and then reactivate the new resource.

-To reactivate your existing device, follow these steps:

-1. Create a new order for the existing device by following the steps in [Create a new resource](azure-stack-edge-gpu-deploy-prep.md?tabs=azure-portal#create-a-new-resource). On the **Shipping address** tab, select **I already have a device**.

- 

- - Ignore any machines that are running other fanotify-based solutions (see details of the `fanotify` kernel option required in [Linux system requirements](/microsoft-365/security/defender-endpoint/microsoft-defender-endpoint-linux#system-requirements))

- - Ignore any Linux machines that are running other fanotify-based solutions (see details of the `fanotify` kernel option required in [Linux system requirements](/microsoft-365/security/defender-endpoint/microsoft-defender-endpoint-linux#system-requirements))

-> * Check MicrosoftΓÇÖs compliance offerings for Azure, Dynamics 365 and Power Platform products

-## Investigate your regulatory compliance issues

-Transparency provided by the compliance offerings, allows you to view the certification status for each of the services provided by Microsoft prior to adding your product to the Azure platform.

-This quickstart describes how to configure the Microsoft Dev Box Preview service by using the Azure portal to enable development teams to self-serve dev boxes.

- - To learn how to join devices directly to Azure AD, see [Plan your Azure Active Directory join deployment](../active-directory/devices/azureadjoin-plan.md).

- - To learn how to join your AD DS domain-joined computers to Azure AD from an on-premises Azure Active Directory Domain Services (AD DS) environment, see [Plan your hybrid Azure Active Directory join deployment](../active-directory/devices/hybrid-azuread-join-plan.md).

-### Create the connection

-You now need a network connection to associate the virtual network and subnet with the dev center. To create the connection, complete the steps on the relevant tab.

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

-1. Select **+ Add**.

-## Assign the Project Admin role

-The Microsoft Dev Box Preview service makes it possible for you to delegate administration of projects to a member of the project team. Project administrators can assist with the day-to-day management of projects for their teams, like creating and managing dev box pools. To give users permissions to manage projects, assign the DevCenter Project Admin role to them.

-You can assign the DevCenter Project Admin role by using the steps described earlier in [Provide access to a dev box project](#provide-access-to-a-dev-box-project), but select the Project Admin role instead of the Dev Box User role. For more information, see [Provide access to projects for project admins](how-to-project-admin.md).

-> * Create a random pet name for the Azure resource group name using [random_pet](https://registry.terraform.io/providers/hashicorp/random/latest/docs/resources/pet)

-> * Create a random string using [random_string](https://registry.terraform.io/providers/hashicorp/random/latest/docs/resources/string)

-* All authenticated REST API requests, including failed requests as a result of access permissions, system errors, or bad requests.

-* Unauthenticated requests that result in a 401 response. Examples are requests that don't have a bearer token, that are malformed or expired, or that have an invalid token.

-Azure Database for PostgreSQL - Flexible Server offers high availability configurations with automatic failover capabilities. The high availability solution is designed to ensure that committed data is never lost because of failures and that the database won't be a single point of failure in your software architecture. When high availability is configured, flexible server automatically provisions and manages a standby replica. Write-ahead-logs (WAL) is streamed to the replica in **synchronous** mode using PostgreSQL streaming replication. There are two high availability architectural models:

-* **Zone-redundant HA**: This option provides a complete isolation and redundancy of infrastructure across multiple availability zones within a region. It provides the highest level of availability, but it requires you to configure application redundancy across zones. Zone-redundant HA is preferred when you want protection from availability zone level failures and when latency across the availability zone is acceptable. Zone-redundant HA is available in a [subset of Azure regions](./overview.md#azure-regions) where the region supports multiple [availability zones](../../availability-zones/az-overview.md). Uptime [SLA of 99.99%](https://azure.microsoft.com/support/legal/sla/postgresql) is offered in this configuration.

-* **Same-zone HA**: This option is preferred for infrastructure redundancy with lower network latency because the primary and standby servers will be in the same availability zone. It provides high availability without the need to configure application redundancy across zones. Same-zone HA is preferred when you want to achieve the highest level of availability within a single availability zone with the lowest network latency. Same-zone HA is available in all [Azure regions](./overview.md#azure-regions) where you can deploy Flexible Server. Uptime [SLA of 99.95%](https://azure.microsoft.com/support/legal/sla/postgresql) offered in this configuration.

-High availability configuration enables automatic failover capability with zero data loss during planned events such as user-initiated scale compute operation, and also during unplanned events such as underlying hardware and software faults, network failures, and availability zone failures.

-Azure Database for PostgreSQL Flexible server supports two high availability deployment models. One is zone-redundant HA and the other is same-zone HA. In both deployment models, when the application performs writes or commits, using PostgreSQL streaming replication, transaction logs (write-ahead logs a.k.a WAL) are written to the local disk and also replicated in *synchronous* mode to the standby replica. Once the logs are persisted on the standby replica, the application is acknowledged of the writes or commits. The standby server will be in recovery mode which keeps applying the logs, but the primary server doesn't wait for the apply to complete at the standby server.

-This model of high availability deployment enables Flexible server to be highly available within the same availability zone. This is supported in all regions, including regions that don't support availability zones. You can choose the region and the availability zone to deploy your primary database server. A standby replica server is **automatically** provisioned and managed in the **same** availability zone in the same region with similar compute, storage, and network configuration as the primary server. Data files and transaction log files (write-ahead logs a.k.a WAL) are stored on locally redundant storage, which automatically stores as **three** data copies each for primary and standby. This provides physical isolation of the entire stack between primary and standby servers within the same availability zone.

- 1. With [**planned failovers**](#failover-processplanned-downtimes) (example: During maintenance window) where the failover is triggered with a known state in which the primary connections are drained, a clean shutdown is performed before the replication is severed. You can also use this to bring the primary server back to your preferred AZ.

-Unplanned outages include software bugs or infrastructure component failures that impact the availability of the database. If the primary server becomes unavailable, it is detected by the monitoring system and initiates a failover process. The process includes a few seconds of wait time to make sure it is not a false positive. The replication to the standby replica is severed and the standby replica is activated to be the primary database server. That includes the standby to recover any residual WAL files. Once it is fully recovered, DNS for the same end point is updated with the standby server's IP address. Clients can then retry connecting to the database server using the same connection string and resume their operations.

->[!NOTE]

-> Flexible servers configured with zone-redundant high availability provide a recovery point objective (RPO) of **Zero** (no data loss). The recovery time objective (RTO) is expected to be **less than 120s** in typical cases. However, depending on the activity in the primary database server at the time of the failover, the failover may take longer.

- 1. You can use the restored server for production usage and can optionally enable zone-redundant high availability.

- No. HA is configured within a region, but across availability zones. In future, we are planning to offer read replicas that can be configured across regions for disaster recovery (DR) purposes. We will provide more details when the feature is enabled.

- You can configure logical replication with HA. However, after a failover, the logical slot details are not copied over to the standby. Hence, there is currently limited support for this configuration.

-

-> | Parameter | Description | Default Value | Type |

-> | - | -- | - | - |

-> | `sapadm_uid` | The UID for the sapadm account. | 2100 | Required |

-> | `sidadm_uid` | The UID for the sidadm account. | 2003 | Required |

-> | `hdbadm_uid` | The UID for the hdbadm account. | 2200 | Required |

-> | `sapinst_gid` | The GID for the sapinst group. | 2001 | Required |

-> | `sapsys_gid` | The GID for the sapsys group. | 2000 | Required |

-> | `hdbshm_gid` | The GID for the hdbshm group. | 2002 | Required |

-> | | | | |

-> | `db2sidadm_uid` | The UID for the db2sidadm account. | 3004 | Required |

-> | `db2sapsid_uid` | The UID for the db2sapsid account. | 3005 | Required |

-> | `db2sysadm_gid` | The UID for the db2sysadm group. | 3000 | Required |

-> | `db2sysctrl_gid` | The UID for the db2sysctrl group. | 3001 | Required |

-> | `db2sysmaint_gid` | The UID for the db2sysmaint group. | 3002 | Required |

-> | `db2sysmon_gid` | The UID for the db2sysmon group. | 2003 | Required |

-> | | | | |

-> | `orasid_uid` | The UID for the orasid account. | 3100 | Required |

-> | `oracle_uid` | The UID for the oracle account. | 3101 | Required |

-> | `observer_uid` | The UID for the observer account. | 4000 | Required |

-> | `dba_gid` | The GID for the dba group. | 3100 | Required |

-> | `oper_gid` | The GID for the oper group. | 3101 | Required |

-> | `asmoper_gid` | The GID for the asmoper group. | 3102 | Required |

-> | `asmadmin_gid` | The GID for the asmadmin group. | 3103 | Required |

-> | `asmdba_gid` | The GID for the asmdba group. | 3104 | Required |

-> | `oinstall_gid` | The GID for the oinstall group. | 3105 | Required |

-> | `backupdba_gid` | The GID for the backupdba group. | 3106 | Required |

-> | `dgdba_gid` | The GID for the dgdba group. | 3107 | Required |

-> | `kmdba_gid` | The GID for the kmdba group. | 3108 | Required |

-> | `racdba_gid` | The GID for the racdba group. | 3108 | Required |

-### Shared Home support

-As a Java developer, if you are new to Azure Service Bus, please consider reading the below articles.

-To simplify connecting with Azure Service Bus, these interfaces are implemented through `ServiceBusJmsConnectionFactory`, `ServiceBusJmsQueueConnectionFactory` and `ServiceBusJmsTopicConnectionFactory` respectively. The Connection factory can be instantiated with the below parameters -

- * ServiceBusJmsConnectionFactorySettings property bag which contains

-The factory can be created as below. The connection string is a required parameter, but the additional properties are optional.

-> [!IMPORTANT]

-> Java applications leveraging JMS 2.0 API must connect to Azure Service Bus using the connection string only. Currently, authentication for JMS clients is only supported using the Connection string.

->

-> Azure active directory (AAD) backed authentication is not currently supported.

->

-A connection encapsulates a virtual connection with a JMS provider. With Azure Service Bus,this represents a stateful connection between the application and Azure Service Bus over AMQP.

-When the session mode is not specified, the **Session.AUTO_ACKNOWLEDGE** is picked by default.

-When the mode is not specified, the **JMSContext.AUTO_ACKNOWLEDGE** is picked by default.

-It can be created either as a stand alone object as below -

-Azure role-based access control (Azure RBAC), backed by Azure Active Directory, is the preferred authentication mechanism for Service Bus. Because Azure RBAC, or claim-based authentication, isn't currently supported by Apache QPID JMS, however, you should use SAS keys for authentication.

-This article demonstrates how to scale any Spring application using the Azure Spring Apps dashboard in the Azure portal.

-Scale your application up and down by modifying its number of virtual CPUs (vCPUs) and amount of memory. Scale your application in and out by modifying the number of application instances.

-After you finish, you'll know how to make quick manual changes to each application in your service. Scaling takes effect in seconds and doesn't require any code changes or redeployment.

-To follow these procedures, you need:

-* A deployed Azure Spring Apps service instance. Follow the [quickstart on deploying an app via the Azure CLI](./quickstart.md) to get started.

-1. Go to your Azure Spring Apps **Overview** page.

-1. Select the resource group that contains your service.

-1. Select the **Apps** tab under **Settings** in the menu on the left side of the page.

-1. Select the application you want to scale. In this example, select the application named **account-service**. You should then see the application's **Overview** page.

-1. Go to the **Scale** tab under **Settings** in the menu on the left side of the page. You should see options for the scaling the attributes shown in the following section.

-If you modify the scaling attributes, keep the following notes in mind:

-* **CPUs**: The maximum number of CPUs per application instance is four. The total number of CPUs for an application is the value set here multiplied by the number of application instances.

-* **Memory/GB**: The maximum amount of memory per application instance is 8 GB. The total amount of memory for an application is the value set here multiplied by the number of application instances.

-* **App instance count**: In the Standard tier, you can scale out to a maximum of 20 instances. This value changes the number of separate running instances of the Spring application.

-

-After a few seconds, the changes you made are displayed on the **Overview** page, with more details available in the **Application instances** tab. Scaling doesn't require any code changes or redeployment.

-If you are on the Basic tier and constrained by one or more of these [limits](./quotas.md), you can upgrade to the Standard tier. To do this go to the Pricing tier menu by first selecting the **Standard tier** column and then selecting the **Upgrade** button.

-All Azure services set default limits and quotas for resources and features. Azure Spring Apps offers two pricing tiers: Basic and Standard. We will detail limits for both tiers in this article.

-| Resource | Scope | Basic | Standard/Enterprise |

-|--|--|--|-|

-| vCPU | per app instance | 1 | 4 |

-| Memory | per app instance | 2 GB | 8 GB |

-| Azure Spring Apps service instances | per region per subscription | 10 | 10 |

-| Total app instances | per Azure Spring Apps service instance | 25 | 500 |

-| Custom Domains | per Azure Spring Apps service instance | 0 | 25 |

-| Persistent volumes | per Azure Spring Apps service instance | 1 GB/app x 10 apps | 50 GB/app x 10 apps |

-| Inbound Public Endpoints | per Azure Spring Apps service instance | 10 ¹ | 10 ¹ |

-| Outbound Public IPs | per Azure Spring Apps service instance | 1 ² | 2 ² <br> 1 if using VNet² |

-| User-assigned managed identities | per app instance | 20 | 20 |

-> Limits listed for Total app instances per service instance apply for apps and deployments in any state, including stopped state. Be sure to delete apps or deployments that aren't in use.

-Some default limits can be increased. If your setup requires an increase, [create a support request](../azure-portal/supportability/how-to-create-azure-support-request.md).

-## Migrations required by 31 March 2023

-All hardware has a finite lifespan, including the underlying hardware for Azure Dedicated Host. As we continue to modernize Azure datacenters, hardware is decommissioned and eventually retired. The hardware that runs the following Dedicated Host SKUs will be reaching end of life:

-As a result we'll retire these Dedicated Host SKUs on 31 March 2023.

-Note: If you're running a Dsv3-Type3, Dsv3-Type4, an Esv3-Type3, or an Esv3-Type4 Dedicated Host, you won't be impacted.

-For manually placed VMs, you'll need to create a Dedicated Host of a newer SKU, stop the VMs on your existing Dedicated Host, reassign them to the new host, start the VMs, and delete the old host. For automatically placed VMs or for virtual machine scale sets, you'll need to create a Dedicated Host of a newer SKU, stop the VMs or virtual machine scale set, delete the old host, and then start the VMs or virtual machine scale set.

-A: Yes, you'll need to stop/deallocate your VMs or virtual machine scale sets before moving them to the target host.

-| 31 March 2023 | Dsv3-Type1, Dsv3-Type2, Esv3-Type1, Esv3-Type2 retirement |

-### Q: What will happen to my Azure Reservation?

-A: You'll need to [exchange your reservation](../cost-management-billing/reservations/exchange-and-refund-azure-reservations.md#how-to-exchange-or-refund-an-existing-reservation) through the Azure portal to match the new Dedicated Host SKU.

-### Q: What would happen to my host if I do not migrate by March 31, 2023?

-A: After March 31, 2023 any dedicated host running on the SKUs that are marked for retirement will be set to 'Host Pending Deallocate' state before eventually deallocating the host. For additional assistance please reach out to Azure support.

-## Network intent policies and security admin rules

-A network intent policy is applied to some network services to ensure the network traffic is working as needed for these services. By default, a security admin configuration will not apply security admin rules to virtual networks with services that use network intent policies such as SQL managed instance service. With this default option, if you deploy a service using network intent policies in a virtual network with existing security admin rules applied, those security admin rules will be removed from those virtual networks. You can also elect for your security admin configuration to handle virtual networks with services that use network intent policies differently to instead apply security admin rules to those virtual networks unless the security admin rule is of a "deny" action type. With either option, your security admin rules will not block traffic to or from virtual networks with services that use network intent policies, ensuring that these services continue to function as expected.

-If you need to apply security admin rules on virtual networks with services that use network intent policies, contact AVNMFeatureRegister@microsoft.com to enable this functionality. Overriding the default behavior described above could break the network intent policies created for those services. For example, creating a deny admin rule can block some traffic allowed by the SQL managed instance service, which is defined by their network intent policies. Make sure to review your environment before applying a security admin configuration. For an example of how to allow the traffic of services that use network intent policies, see [How can I explicitly allow SQLMI traffic before having deny rules](faq.md#how-can-i-explicitly-allow-azure-sql-managed-instance-traffic-before-having-deny-rules)