-### Claims transformations example

-## Optimize virtual machine (VM) or virtual machine scale set (VMSS) spend by resizing or shutting down underutilized instances

-Although certain application scenarios can result in low utilization by design, you can often save money by managing the size and number of your virtual machines or virtual machine scale sets.

-Advisor identifies resources that haven't been used at all over the last 7 days and makes a recommendation to shut them down.

- - P95th of the maximum value of CPU utilization summed across all cores is less than 3%.

- - P100 of average CPU in last 3 days (sum over all cores) <= 2%

- - Outbound Network utilization is less than 2% over a seven-day period.

- - Performance of the workloads on the new SKU shouldn't be impacted.

- - Target for user-facing workloads:

- - P95 of CPU and Outbound Network utilization at 40% or lower on the recommended SKU

- - P100 of Memory utilization at 60% or lower on the recommended SKU

- - Target for non user-facing workloads:

- - P95 of the CPU and Outbound Network utilization at 80% or lower on the new SKU

- - P100 of Memory utilization at 80% or lower on the new SKU

- - The new SKU, if applicable, has the same Accelerated Networking and Premium Storage capabilities

- - The new SKU, if applicable, is supported in the current region of the Virtual Machine with the recommendation

- - The new SKU, if applicable, is less expensive

- - Instance count recommendations also take into account if the virtual machine scale set is being managed by Service Fabric or AKS. For service fabric managed resources, recommendations take into account reliability and durability tiers.

- - If the P95 of CPU is less than two times the burstable SKUs' baseline performance

- - If the current SKU doesn't have accelerated networking enabled, since burstable SKUs don't support accelerated networking yet

- - If we determine that the Burstable SKU credits are sufficient to support the average CPU utilization over 7 days. Note that you can change your lookback period in the configurations.

-

-To be more selective about the actioning on underutilized virtual machines or virtual machine scale sets, you can adjust the CPU utilization rule on a per-subscription basis.

-In some cases recommendations can't be adopted or might not be applicable, such as some of these common scenarios (there may be other cases):

-In such cases, simply use the Dismiss/Postpone options associated with the recommendation.

-* **VM/VMSS right sizing**: You can adjust the average CPU utilization rule and the look back period on a per-subscription basis. Doing virtual machine (VM) right sizing requires specialized knowledge.

- 1. Select the subscriptions youΓÇÖd like to adjust the average CPU utilization rule for, and then click **Edit**. Not all subscriptions can be edited for VM/VMSS right sizing and certain privileges are required; for more information on permissions, see [Permissions in Azure Advisor](permissions.md).

-> AKS 1.28 includes certain changes to memory reservations. These changes are detailed in the following section.

-**AKS 1.28 and later**

-**AKS versions prior to 1.28**

-description: Learn how to integrate the Azure Key Vault provider for Secrets Store CSI Driver with your Azure key vault.

-# Provide an identity to access the Azure Key Vault provider for Secrets Store CSI Driver in Azure Kubernetes Service (AKS)

-The Secrets Store CSI Driver on Azure Kubernetes Service (AKS) provides various methods of identity-based access to your Azure Key Vault. This article outlines these methods and how to use them to access your key vault and its contents from your AKS cluster.

-## Prerequisites

-A [Microsoft Entra Workload ID][workload-identity] is an identity that an application running on a pod uses that authenticates itself against other Azure services that support it, such as Storage or SQL. It integrates with the native Kubernetes capabilities to federate with external identity providers. In this security model, the AKS cluster acts as token issuer. Microsoft Entra ID then uses OpenID Connect (OIDC) to discover public signing keys and verify the authenticity of the service account token before exchanging it for a Microsoft Entra token. Your workload can exchange a service account token projected to its volume for a Microsoft Entra token using the Azure Identity client library using the Azure SDK or the Microsoft Authentication Library (MSAL).

-> - Microsoft Entra Workload ID is supported on both Windows and Linux clusters.

-5. Establish a federated identity credential between the Microsoft Entra application and the service account issuer and subject. Get the object ID of the Microsoft Entra application using the following commands. Make sure to update the values for `serviceAccountName` and `serviceAccountNamespace` with the Kubernetes service account name and its namespace.

- > If you use `objectAlias` instead of `objectName`, make sure to update the YAML script.

-## Access with a user-assigned managed identity

-1. Access your key vault using the [`az aks show`][az-aks-show] command and the user-assigned managed identity created by the add-on when you [enabled the Azure Key Vault provider for Secrets Store CSI Driver on your AKS Cluster](./csi-secrets-store-driver.md#create-an-aks-cluster-with-azure-key-vault-provider-for-secrets-store-csi-driver-support).

-2. Create a role assignment that grants the identity permission to access the key vault secrets, access keys, and certificates using the [`az role assignment create`][az-role-assignment-create] command.

-## Validate the secrets

-After the pod starts, the mounted content at the volume path that you specified in your deployment YAML is available. Use the following commands to validate your secrets and print a test secret.

-The Azure Key Vault design makes sharp distinctions between keys, secrets, and certificates. The certificate features of the Key Vault service were designed to make use of key and secret capabilities. When you create a key vault certificate, it creates an addressable key and secret with the same name. The key allows key operations, and the secret allows the retrieval of the certificate value as a secret.

-## Disable the Azure Key Vault provider for Secrets Store CSI Driver on an existing AKS cluster

-1. Prepare the RSA Encryption/Decryption key by [downloading][download-setup-key-script] the Bash script for the workload from GitHub. Save the file as `setup-key.sh`.

- {context.GraphQL.Arguments.["id"]}

- {context.GraphQL.Arguments.["id"]}

- {context.GraphQL.Arguments.["id"]}

- {context.GraphQL.Arguments.["name"]}

-Because patching is a planned failover, the replica node quickly promotes itself to become a primary. Then, the node begins servicing requests and new connections. Basic caches don't have a replica node and are unavailable until the update is complete. Each shard of a clustered cache is patched separately and won't close connections to another shard.

-Most client libraries attempt to reconnect to the cache if they're configured to do so. However, unforeseen bugs can occasionally place the library objects into an unrecoverable state. If errors persist for longer than a pre-configured amount of time, the connection object should be recreated. In Microsoft.NET and other object-oriented languages, recreating the connection without restarting the application can be accomplished by using a [ForceReconnect pattern](cache-best-practices-connection.md#using-forcereconnect-with-stackexchangeredis).

-Azure Cache for Redis publishes runtime maintenance notifications on a publish/subscribe (pub/sub) channel called `AzureRedisEvents`. Many popular Redis client libraries support subscribing to pub/sub channels. Receiving notifications from the `AzureRedisEvents` channel is usually a simple addition to your client application. For more information about maintenance events, please see [AzureRedisEvents](https://github.com/Azure/AzureCacheForRedis/blob/main/AzureRedisEvents.md).

-> The `AzureRedisEvents` channel isn't a mechanism that can notify you days or hours in advance. The channel can notify clients of any upcoming planned server maintenance events that might affect server availability.

-Configure a storage account to use with to store your metrics. The storage account must be in the same region as the caches. Once you've created a storage account, configure a storage account for your cache metrics:

-1. Check **Archive to a storage account**. YouΓÇÖll be charged normal data rates for storage and transactions when you send diagnostics to a storage account.

-For non-clustered caches, we recommend using the metrics without the suffix `Instance Based`. For example, to check server load for your cache instance, use the metric `Server Load`.

-In contrast, for clustered caches, we recommend using the metrics with the suffix `Instance Based`. Then, add a split or filter on `ShardId`. For example, to check the server load of shard 1, use the metric "Server Load (Instance Based)", then apply filter `ShardId = 1`.

- - Depicts the worst-case (99th percentile) latency of server-side commands. Measured by issuing `PING` commands from the load balancer to the Redis server and tracking the time to respond.

- - Useful for tracking the health of your Redis instance. Latency will increase if the cache is under heavy load or if there are long running commands that delay the execution of the `PING` command.

- - The number of failed key lookups during the specified reporting interval. This number maps to `keyspace_misses` from the Redis INFO command. Cache misses don't necessarily mean there's an issue with the cache. For example, when using the cache-aside programming pattern, an application looks first in the cache for an item. If the item isn't there (cache miss), the item is retrieved from the database and added to the cache for next time. Cache misses are normal behavior for the cache-aside programming pattern. If the number of cache misses is higher than expected, examine the application logic that populates and reads from the cache. If items are being evicted from the cache because of memory pressure, then there may be some cache misses, but a better metric to monitor for memory pressure would be `Used Memory` or `Evicted Keys`.

- - The number of client connections to the cache during the specified reporting interval. This number maps to `connected_clients` from the Redis INFO command. Once the [connection limit](cache-configure.md#default-redis-server-configuration) is reached, later attempts to connect to the cache fail. Even if there are no active client applications, there may still be a few instances of connected clients because of internal processes and connections.

- - The number of client connections to the cache authenticated using Microsoft Entra token during the specified reporting interval.

- - Specific failures and performance issues that the cache could be experiencing during a specified reporting interval. This metric has eight dimensions representing different error types, but could have more added in the future. The error types represented now are as follows:

- - **AADTokenExpired** (preview) - when a Microsoft Entra access token used for authentication is not renewed and it expires.

- - Depicts the approximate amount of data, in bytes, that has yet to be synchronized to geo-secondary cache.

- - The metric reports zero most of the time because geo-replication uses partial resynchronizations for any new data added after the initial full synchronization.

- - This metric is only emitted _from the geo-secondary_ cache instance. On the geo-primary instance, this metric has no value.

- - This metric is only available in the Premium tier for caches with geo-replication enabled.

- - In caches on the Premium tier, this metric is only emitted *from the geo-secondary* cache instance. On the geo-primary instance, this metric has no value.

- - This metric may indicate a disconnected/unhealthy replication status for several reasons, including: monthly patching, host OS updates, network misconfiguration, or failed geo-replication link provisioning.

- - A value of 0 doesn't mean that data on the geo-replica is lost. It just means that the link between geo-primary and geo-secondary is unhealthy.

- - The percentage of cycles in which the Redis server is busy processing and not waiting idle for messages. If this counter reaches 100, the Redis server has hit a performance ceiling, and the CPU can't process work any faster. If you're seeing high Redis Server Load, then you see timeout exceptions in the client. In this case, you should consider scaling up or partitioning your data into multiple caches.

-> The Server Load metric can present incorrect data for Enterprise and Enterprise Flash tier caches. Sometimes Server Load is represented as being over 100. We are investigating this issue. We recommend using the CPU metric instead in the meantime.

- - The total number of commands processed by the cache server during the specified reporting interval. This value maps to `total_commands_processed` from the Redis INFO command. When Azure Cache for Redis is used purely for pub/sub there will be no metrics for `Cache Hits`, `Cache Misses`, `Gets`, or `Sets`, but there will be `Total Operations` metrics that reflect the cache usage for pub/sub operations.

- - On the Enterprise and Enterprise Flash tier, the Used Memory value includes the memory in both the primary and replica nodes. This can make the metric appear twice as large as expected.

-Once you've defined a metric, you can send it to a workbook. Workbooks provide a way to organize your metrics into groups that provide the information in coherent way. Azure Cache for Redis provides two workbooks by default in the **Azure Cache for Redis Insights** section:

-The two workbooks provided are:

-## Next steps

-Monitor how your `ThreadPool` statistics change over time using [an example `ThreadPoolLogger`](https://github.com/JonCole/SampleCode/blob/master/ThreadPoolMonitor/ThreadPoolLogger.cs). You can use `TimeoutException` messages from StackExchange.Redis like below to further investigate:

- - More bandwidth on your client or server VM may reduce data transfer times for larger responses.

- - Compare your current network usage on both machines to the limits of your current VM size. More bandwidth on only the server or only on the client may not be enough.

-High client CPU usage indicates the system can't keep up with the work it's been asked to do. Even though the cache sent the response quickly, the client may fail to process the response in a timely fashion. Our recommendation is to keep client CPU below 80%. Check the metric "Errors" (Type: `UnresponsiveClients`) to determine if your client hosts can process responses from Redis server in time.

-Monitor the client's system-wide CPU usage using metrics available in the Azure portal or through performance counters on the machine. Be careful not to monitor *process* CPU because a single process can have low CPU usage but the system-wide CPU can be high. Watch for spikes in CPU usage that correspond with timeouts. High CPU may also cause high `in: XXX` values in `TimeoutException` error messages as described in the [[Traffic burst](#traffic-burst-and-thread-pool-configuration)] section.

-Depending on the architecture of client machines, they may have limitations on how much network bandwidth they have available. If the client exceeds the available bandwidth by overloading network capacity, then data isn't processed on the client side as quickly as the server is sending it. This situation can lead to timeouts.

-Monitor how your Bandwidth usage change over time using [an example `BandwidthLogger`](https://github.com/JonCole/SampleCode/blob/master/BandWidthMonitor/BandwidthLogger.cs). This code may not run successfully in some environments with restricted permissions (like Azure web sites).

-If you're using `RedisSessionStateProvider`, ensure you have set the retry timeout correctly. The `retryTimeoutInMilliseconds` value should be higher than the `operationTimeoutInMilliseconds` value. Otherwise, no retries occur. In the following example, `retryTimeoutInMilliseconds` is set to 3000. For more information, see [ASP.NET Session State Provider for Azure Cache for Redis](cache-aspnet-session-state-provider.md) and [How to use the configuration parameters of Session State Provider and Output Cache Provider](https://github.com/Azure/aspnet-redis-providers/wiki/Configuration).

-Planned or unplanned maintenance can cause disruptions with client connections. The number and type of exceptions depends on the location of the request in the code path, and when the cache closes its connections. For instance, an operation that sends a request but hasn't received a response when the failover occurs might get a time-out exception. New requests on the closed connection object receive connection exceptions until the reconnection happens successfully.

-To check whether your Azure Cache for Redis had a failover during when timeouts occurred, check the metric **Errors**. On the Resource menu of the Azure portal, select **Metrics**. Then create a new chart measuring the `Errors` metric, split by `ErrorType`. Once you have created this chart, you see a count for **Failover**.

-The Redis Slow Log is a system to log queries that exceeded a specified execution time. The execution time does not include I/O operations like talking with the client, sending the reply, and so forth, but just the time needed to actually execute the command. Using the SLOWLOG command, Customers can measure/log expensive commands being executed against their Redis server.

-Different cache sizes have different network bandwidth capacities. If the server exceeds the available bandwidth, then data won't be sent to the client as quickly. Client requests could time out because the server can't push data to the client fast enough.

- "firedDateTime":"2021-11-17T05:34:48.0623172",

-This feature works for any web app, hosted in the cloud or on your own servers, that generate application request or dependency data. For example, if you have a worker role that calls [TrackRequest()](../app/api-custom-events-metrics.md#trackrequest) or [TrackDependency()](../app/api-custom-events-metrics.md#trackdependency).

-Smart Detection monitors the data received from your app, and in particular the failure rates. This rule counts the number of requests for which the `Successful request` property is false, and the number of dependency calls for which the `Successful call` property is false. For requests, by default, `Successful request == (resultCode < 400)` (unless you have written custom code to [filter](../app/api-filtering-sampling.md#filtering) or generate your own [TrackRequest](../app/api-custom-events-metrics.md#trackrequest) calls).

-As data comes into Application Insights from your web app, Smart Detection compares the current behavior with the patterns seen over the past few days. If an abnormal rise in failure rate is observed by comparison with previous performance, an analysis is triggered.

-In the previous example, the analysis has discovered that most failures are about a specific result code, request name, Server URL host, and role instance.

-When your service is instrumented with these calls, the analyzer looks for an exception and a dependency failure that are associated with requests in the cluster it has identified, together with an example of any trace logs associated with those requests.

-The resulting analysis is sent to you as alert, unless you have configured it not to.

-Like the [alerts you set manually](./alerts-log.md), you can inspect the state of the fired alert, which can be resolved if the issue is fixed. Configure the alert rules in the Alerts page of your Application Insights resource. But unlike other alerts, you don't need to set up or configure Smart Detection. If you want, you can disable it or change its target email addresses.

-Our proprietary machine learning algorithm triggers the alerts, so we can't share the exact implementation details. With that said, we understand that you sometimes need to know more about how the underlying logic works. The primary factors that are evaluated to determine if an alert should be triggered are:

-* A comparison of the failure percentage of the last 20 minutes to the rate in the last 40 minutes and the past seven days, and looking for significant deviations that exceed X-times that standard deviation.

-* Using an adaptive limit for the minimum failure percentage, which varies based on the appΓÇÖs volume of requests/dependencies.

-* There's logic that can automatically resolve the fired alert monitor condition, if the issue is no longer detected for 8-24 hours.

- Note: in the current design. a notification or action will not be sent when a Smart Detection alert is resolved. You can check if a Smart Detection alert was resolved in the Azure portal.

-## Configure alerts

-You can disable Smart Detection alert rule from the portal or using Azure Resource Manager ([see template example](./proactive-arm-config.md)).

-This alert rule is created with an associated [Action Group](./action-groups.md) named "Application Insights Smart Detection" that contains email and webhook actions, and can be extended to trigger more actions when the alert fires.

-> [!NOTE]

-> Email notifications sent from this alert rule are now sent by default to users associated with the subscription's Monitoring Reader and Monitoring Contributor roles. More information on this is available [here](./proactive-email-notification.md).

-> Notifications sent from this alert rule follow the [common alert schema](./alerts-common-schema.md).

->

-Open the Alerts page. Failure Anomalies alert rules are included along with any alerts that you have set manually, and you can see whether it's currently in the alert state.

-Click the alert to configure it.

-You can disable or delete a Failure Anomalies alert rule.

-Clicking on 'Diagnose failures' helps you get more details and resolve the issue.

-From the percentage of requests and number of users affected, you can decide how urgent the issue is. In the previous example, the failure rate of 78.5% compares with a normal rate of 2.2%, indicates that something bad is going on. On the other hand, only 46 users were affected. If it was your app, you'd be able to assess how serious that is.

-In many cases, you will be able to diagnose the problem quickly from the request name, exception, dependency failure, and trace data provided.

-## What's the difference ...

-Smart Detection of Failure Anomalies complements other similar but distinct features of Application Insights.

-* [metric alerts](./alerts-log.md) are set by you and can monitor a wide range of metrics such as CPU occupancy, request rates, page load times, and so on. You can use them to warn you, for example, if you need to add more resources. By contrast, Smart Detection of Failure Anomalies covers a small range of critical metrics (currently only failed request rate), designed to notify you in near real-time manner once your web app's failed request rate increases compared to web app's normal behavior. Unlike metric alerts, Smart Detection automatically sets and updates thresholds in response changes in the behavior. Smart Detection also starts the diagnostic work for you, saving you time in resolving issues.

-* [Smart Detection of performance anomalies](smart-detection-performance.md) also uses machine intelligence to discover unusual patterns in your metrics, and no configuration by you is required. But unlike Smart Detection of Failure Anomalies, the purpose of Smart Detection of performance anomalies is to find segments of your usage manifold that might be badly served - for example, by specific pages on a specific type of browser. The analysis is performed daily, and if any result is found, it's likely to be much less urgent than an alert. By contrast, the analysis for Failure Anomalies is performed continuously on incoming application data, and you will be notified within minutes if server failure rates are greater than expected.

-*Why have I received this alert?*

-* In the Activity logs. In Azure, open the Application Insights resource for your app, then select Activity logs.

-*Some of the alerts are about known issues and I do not want to receive them.*

- "userId (?<redactedUserId>[\\da-zA-Z]+)"

-description: The app expression is used in an Azure Monitor log query to retrieve data from a specific Application Insights app in the same resource group, another resource group, or another subscription.

-# app() expression in Azure Monitor query

-The `app` expression is used in an Azure Monitor query to retrieve data from a specific Application Insights app in the same resource group, another resource group, or another subscription. This is useful to include application data in an Azure Monitor log query and to query data across multiple applications in an Application Insights query.

-> [!IMPORTANT]

-> The app() expression is not used if you're using a [workspace-based Application Insights resource](../app/create-workspace-resource.md) since log data is stored in a Log Analytics workspace. Use the workspace() expression to write a query that includes application in multiple workspaces. For multiple applications in the same workspace, you don't need a cross workspace query.

-## Syntax

-`app(`*Identifier*`)`

-## Arguments

-| Identifier | Description | Example

-|:|:|:|

-| ID | GUID of the app | app("00000000-0000-0000-0000-000000000000") |

-| Azure Resource ID | Identifier for the Azure resource |app("/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/Fabrikam/providers/microsoft.insights/components/fabrikamapp") |

-## Notes

-* You must have read access to the application.

-* Identifying an application by its ID or Azure Resource ID is strongly recommended since unique, removes ambiguity, and more performant.

-* Use the related expression [workspace](../logs/workspace-expression.md) to query across Log Analytics workspaces.

-## Examples

-```Kusto

-app("00000000-0000-0000-0000-000000000000").requests | count

-```

-```Kusto

-app("/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/Fabrikam/providers/microsoft.insights/components/fabrikamapp").requests | count

-```

-```Kusto

-union

-(workspace("00000000-0000-0000-0000-000000000000").Heartbeat | where Computer == "myComputer"),

-(app("00000000-0000-0000-0000-000000000000").requests | where cloud_RoleInstance == "myColumnInstance")

-| count

-```

-```Kusto

-union

-(workspace("00000000-0000-0000-0000-000000000000").Heartbeat), (app("00000000-0000-0000-0000-000000000000").requests)

-| where TimeGenerated between(todatetime("2023-03-08 15:00:00") .. todatetime("2023-04-08 15:05:00"))

-```

-## Next steps

-| Active Directory | [AADDomainServicesDNSAuditsGeneral](/azure/azure-monitor/reference/tables/AADDomainServicesDNSAuditsGeneral)<br> [AADDomainServicesDNSAuditsDynamicUpdates](/azure/azure-monitor/reference/tables/AADDomainServicesDNSAuditsDynamicUpdates) |

-description: This article describes how you can query against resources from multiple workspaces and an Application Insights app in your subscription.

-# Create a log query across multiple workspaces and apps in Azure Monitor

-Azure Monitor Logs support querying across multiple Log Analytics workspaces and Application Insights apps in the same resource group, another resource group, or another subscription. This capability provides you with a systemwide view of your data.

-If you manage subscriptions in other Microsoft Entra tenants through [Azure Lighthouse](../../lighthouse/overview.md), you can include [Log Analytics workspaces created in those customer tenants](../../lighthouse/how-to/monitor-at-scale.md) in your queries.

-There are two methods to query data that's stored in multiple workspaces and apps:

-* Explicitly by specifying the workspace and app information. This technique is used in this article.

-* Implicitly by using [resource-context queries](manage-access.md#access-mode). When you query in the context of a specific resource, resource group, or a subscription, the relevant data will be fetched from all workspaces that contain data for these resources. Application Insights data that's stored in apps won't be fetched.

-> If you're using a [workspace-based Application Insights resource](../app/create-workspace-resource.md), telemetry is stored in a Log Analytics workspace with all other log data. Use the `workspace()` expression to write a query that includes applications in multiple workspaces. For multiple applications in the same workspace, you don't need a cross-workspace query.

-## Cross-resource query limits

-* The number of Application Insights components and Log Analytics workspaces that you can include in a single query is limited to 100.

-* References to a cross resource, such as another workspace, should be explicit and can't be parameterized. See [Gather identifiers for Log Analytics workspaces](?tabs=workspace-identifier#gather-identifiers-for-log-analytics-workspaces-and-application-insights-resources) for examples.

-## Gather identifiers for Log Analytics workspaces and Application Insights resources

-To reference another workspace in your query, use the [workspace](../logs/workspace-expression.md) identifier. For an app from Application Insights, use the [app](./app-expression.md) identifier.

-### [Workspace identifier](#tab/workspace-identifier)

-You can identify a workspace using one of these IDs:

-* **Workspace ID**: A workspace ID is the unique, immutable, identifier assigned to each workspace represented as a globally unique identifier (GUID).

- `workspace("00000000-0000-0000-0000-000000000000").Update | count`

-* **Azure Resource ID**: This ID is the Azure-defined unique identity of the workspace. For workspaces, the format is */subscriptions/subscriptionId/resourcegroups/resourceGroup/providers/microsoft.OperationalInsights/workspaces/workspaceName*.

- For example:

- ```

- workspace("/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/ContosoAzureHQ/providers/Microsoft.OperationalInsights/workspaces/contosoretail-it").Update | count

- ```

-### [App identifier](#tab/app-identifier)

-The following examples return a summarized count of requests made against an app named *fabrikamapp* in Application Insights.

-You can identify an app using one of these IDs:

-* **ID**: This ID is the app GUID of the application.

- `app("00000000-0000-0000-0000-000000000000").requests | count`

-* **Azure Resource ID**: This ID is the Azure-defined unique identity of the app. The format is */subscriptions/subscriptionId/resourcegroups/resourceGroup/providers/microsoft.OperationalInsights/components/componentName*.

- For example:

- ```

- app("/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/Fabrikam/providers/microsoft.insights/components/fabrikamapp").requests | count

- ```

-## Query across Log Analytics workspaces and from Application Insights

-Follow the instructions in this section to query without using a function or by using a function.

-```

-Data in Azure Monitor is encrypted with Microsoft-managed keys. You can use your own encryption key to protect the data and saved queries in your workspaces. Customer-managed keys in Azure Monitor give you greater flexibility to manage access controls to logs. Once configure, new data for linked workspaces is encrypted with your key stored in [Azure Key Vault](../../key-vault/general/overview.md), or [Azure Key Vault Managed "HSM"](../../key-vault/managed-hsm/overview.md).

-We recommend you review [Limitations and constraints](#limitationsandconstraints) below before configuration.

-Azure Monitor ensures that all data and saved queries are encrypted at rest using Microsoft-managed keys (MMK). You also have the option to encrypt data with your own key in [Azure Key Vault](../../key-vault/general/overview.md), with control over key lifecycle and ability to revoke access to your data at any time. Azure Monitor use of encryption is identical to the way [Azure Storage encryption](../../storage/common/storage-service-encryption.md#about-azure-storage-service-side-encryption) operates.

-Customer-managed key is delivered on [dedicated clusters](./logs-dedicated-clusters.md) providing higher protection level and control. Data to dedicated clusters is encrypted twice, once at the service level using Microsoft-managed keys or Customer-managed keys, and once at the infrastructure level, using two different encryption algorithms and two different keys. [double encryption](../../storage/common/storage-service-encryption.md#doubly-encrypt-data-with-infrastructure-encryption) protects against a scenario where one of the encryption algorithms or keys may be compromised. In this case, the additional layer of encryption continues to protect your data. Dedicated cluster also allows you to protect your data with [Lockbox](#customer-lockbox) control.

-Log Analytics Dedicated Clusters [pricing model](./logs-dedicated-clusters.md#cluster-pricing-model) requires commitment Tier starting at 500 GB per day and can have values of 500, 1000, 2000 or 5000 GB per day.

-Azure Monitor uses managed identity to grant access to your Azure Key Vault. The identity of the Log Analytics cluster is supported at the cluster level. To allow Customer-managed key on multiple workspaces, a Log Analytics Cluster resource performs as an intermediate identity connection between your Key Vault and your Log Analytics workspaces. The cluster's storage uses the managed identity that\'s associated with the Cluster resource to authenticate to your Azure Key Vault via Microsoft Entra ID.

-You can apply Customer-managed key configuration to a new cluster, or existing cluster that has linked workspaces with data ingested to them. New data ingested to linked workspaces gets encrypted with your key, and older data ingested before the configuration, remains encrypted with Microsoft key. Your queries aren't affected by Customer-managed key configuration and query is performed across old and new data seamlessly. You can unlink workspaces from your cluster at any time, and new data ingested after the unlink gets encrypted with Microsoft key, and query is performed across old and new data seamlessly.

-Create or use an existing Azure Key Vault in the region that the cluster is planed, and generate or import a key to be used for logs encryption. The Azure Key Vault must be configured as recoverable, to protect your key and the access to your data in Azure Monitor. You can verify this configuration under properties in your Key Vault, both **Soft delete** and **Purge protection** should be enabled.

-```azurecli

-az account set ΓÇösubscription "cluster-subscription-id"

-az monitor log-analytics cluster update ΓÇöno-wait ΓÇöname "cluster-name" ΓÇöresource-group "resource-group-name" ΓÇökey-name "key-name" ΓÇökey-vault-uri "key-uri" ΓÇökey-version "key-version"

-# Wait for job completion when `ΓÇöno-wait` was used

-$clusterResourceId = az monitor log-analytics cluster list ΓÇöresource-group "resource-group-name" ΓÇöquery "[?contains(name, "cluster-name")].[id]" ΓÇöoutput tsv

-az resource wait ΓÇöcreated ΓÇöids $clusterResourceId ΓÇöinclude-response-body true

-The cluster storage will always respect changes in key permissions within an hour or sooner and storage will become unavailable. New data ingested to linked workspaces is dropped and non-recoverable. Data is inaccessible on these workspaces and queries fail. Previously ingested data remains in storage as long as your cluster and your workspaces aren't deleted. Inaccessible data is governed by the data-retention policy and will be purged when retention is reached. Data ingested in the last 14 days and data recently used in queries is also kept in hot-cache (SSD-backed) for query efficiency. The data on SSD gets deleted on key revocation operation and becomes inaccessible. The cluster storage attempts reach your Key Vault to unwrap encryption periodically, and when key is enabled, unwrap succeeds, SSD data is reloaded from storage, data ingestion and query are resumed within 30 minutes.

-* Fired log alerts will not contain search results or alert query. You can use [alert dimensions](../alerts/alerts-unified-log.md#split-by-alert-dimensions) to get context in the fired alerts.

-az account set ΓÇösubscription "storage-account-subscription-id"

-az account set ΓÇösubscription "workspace-subscription-id"

-az monitor log-analytics workspace linked-storage create ΓÇötype Query ΓÇöresource-group "resource-group-name" ΓÇöworkspace-name "workspace-name" ΓÇöstorage-accounts $storageAccountId

-az account set ΓÇösubscription "storage-account-subscription-id"

-az account set ΓÇösubscription "workspace-subscription-id"

-az monitor log-analytics workspace linked-storage create ΓÇötype ALerts ΓÇöresource-group "resource-group-name" ΓÇöworkspace-name "workspace-name" ΓÇöstorage-accounts $storageAccountId

-In Azure Monitor, you have this control on data in workspaces linked to your dedicated cluster. The Lockbox control applies to data stored in a dedicated cluster where itΓÇÖs kept isolated in the cluster storage under your Lockbox protected subscription.

- - Double encryption settings cannot be changed after the cluster has been created.

- - Key Vault connection errorsΓÇöstorage handles transient errors (timeouts, connection failures, "DNS" issues), by allowing keys to stay in cache for the duration of the availability issue, and it overcomes blips and availability issues. The query and ingestion capabilities continue without interruption.

-> Starting September 18, 2023, the Log Analytics Daily Cap all billable data types will

-> be capped if the daily cap is met, and there is no special behavior for any data types when [Microsoft Defender for Servers](../../defender-for-cloud/plan-defender-for-servers-select-plan.md) is enabled on your workspace.

-> If you have a Daily Cap set on your workspace which has Microsoft Defender for Servers,

-> Also, be sure to set an alert (see below) so that you are notified as soon as your Daily Cap is met.

-* [app()](../logs/app-expression.md)

-* [resource()](./resource-expression.md)

-* [workspace()](../logs/workspace-expression.md)

-> - Cross workspace queries having an explicit identifier: workspace ID, or workspace Azure Resource ID, consume less resources and are more performant. See [Gather identifiers for Log Analytics workspaces](./cross-workspace-query.md?tabs=workspace-identifier#gather-identifiers-for-log-analytics-workspaces-and-application-insights-resources)

-description: The resource expression is used in a resource-centric Azure Monitor log query to retrieve data from multiple resources.

-# resource() expression in Azure Monitor log query

-The `resource` expression is used in a Azure Monitor query [scoped to a resource](scope.md#query-scope) to retrieve data from other resources.

-## Syntax

-`resource(`*Identifier*`)`

-## Arguments

-| Identifier | Description | Example

-|:|:|:|

-| Resource | Includes data for the resource. | resource("/subscriptions/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcesgroups/myresourcegroup/providers/microsoft.compute/virtualmachines/myvm") |

-| Resource Group or Subscription | Includes data for the resource and all resources that it contains. | resource("/subscriptions/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcesgroups/myresourcegroup) |

-## Notes

-* You must have read access to the resource.

-## Examples

-```Kusto

-union (Heartbeat),(resource("/subscriptions/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcesgroups/myresourcegroup/providers/microsoft.compute/virtualmachines/myvm").Heartbeat) | summarize count() by _ResourceId, TenantId

-```

-```Kusto

-union (Heartbeat),(resource("/subscriptions/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcesgroups/myresourcegroup).Heartbeat) | summarize count() by _ResourceId, TenantId

-```

-## Next steps

-description: The workspace expression is used in an Azure Monitor log query to retrieve data from a specific workspace in the same resource group, another resource group, or another subscription.

-# Using the workspace() expression in Azure Monitor log query

-Use the `workspace` expression in an Azure Monitor query to retrieve data from a specific workspace in the same resource group, another resource group, or another subscription. You can use this expression to include log data in an Application Insights query and to query data across multiple workspaces in a log query.

-## Syntax

-`workspace(`*Identifier*`)`

-### Arguments

-The `workspace` expression takes the following arguments.

-#### Identifier

-Identifies the workspace by using one of the formats in the following table.

-| Identifier | Description | Example

-|:|:|:|

-| ID | GUID of the workspace | workspace("00000000-0000-0000-0000-000000000000") |

-| Azure Resource ID | Identifier for the Azure resource | workspace("/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/Contoso/providers/Microsoft.OperationalInsights/workspaces/contosoretail") |

-> [!NOTE]

-> We strongly recommend identifying a workspace by its unique ID or Azure Resource ID because they remove ambiguity and are more performant.

-## Examples

-```Kusto

-workspace("00000000-0000-0000-0000-000000000000").Update | count

-```

-```Kusto

-workspace("/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/Contoso/providers/Microsoft.OperationalInsights/workspaces/contosoretail").Event | count

-```

-```Kusto

-union

-( workspace("00000000-0000-0000-0000-000000000000").Heartbeat | where Computer == "myComputer"),

-(app("00000000-0000-0000-0000-000000000000").requests | where cloud_RoleInstance == "myRoleInstance")

-| count

-```

-```Kusto

-union

-(workspace("00000000-0000-0000-0000-000000000000").Heartbeat), (app("00000000-0000-0000-0000-000000000000").requests) | where TimeGenerated between(todatetime("2023-03-08 15:00:00") .. todatetime("2023-04-08 15:05:00"))

-```

-## Next steps

-Container Apps captures the `stdout` and `stderr` output streams from your application containers and displays them as console logs. When you implement logging in your application, you can troubleshoot problems and monitor the health of your app.

-> [!IMPORTANT]

-> Defender for APIs is currently in PREVIEW.

-> See the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

-Defender for APIs is currently in preview.

-Review the requirements on this page before setting up [Microsoft Defender for APIs](defender-for-apis-introduction.md). Defender for APIs is currently in preview.

-Microsoft Defender for Cloud is a cloud-native application protection platform (CNAPP) with a set of security measures and practices designed to protect cloud-based applications from various cyber threats and vulnerabilities. Defender for Cloud combines the capabilities of:

-When you [enable Defender for Cloud on your](connect-azure-subscription.md), you'll automatically gain access to Microsoft 365 Defender.

-The Microsoft 365 Defender portal provides richer context to investigations that span cloud resources, devices, and identities. In addition, security teams are able to get the complete picture of an attack, including suspicious and malicious events that happen in their cloud environment, through the immediate correlation of all alerts and incidents, including cloud alerts and incidents.

-Agentless secret scanning utilizes cloud APIs to capture snapshots of your disks, conducting out-of-band analysis that ensures that there is no effect on your VM's performance. Agentless secret scanning broadens the coverage offered by Defender for Cloud over cloud assets across Azure, AWS, and GCP environments to enhance your cloud security.

-With this release, Defender for Cloud's detection capabilities now support additional database types, data store signed URLs, access tokens, and more.

-The attack path's Azure Resource Graph (ARG) table scheme is updated. The `attackPathType` property is removed and other properties are added. Read more about the [updated Azure Resource Graph table scheme]().

-[Defender for APIs](defender-for-apis-introduction.md). [Review support preview regions](defender-for-apis-prepare.md#cloud-and-region-support). | Preview | NA | NA

-Microsoft Defender for Storage is an Azure-native solution offering an advanced layer of intelligence for threat detection and mitigation in storage accounts, powered by [Microsoft Threat Intelligence](https://go.microsoft.com/fwlink/?linkid=2128684), Microsoft Defender Antimalware technologies, and Sensitive Data Discovery. With protection for Azure Blob Storage, Azure Files, and Azure Data Lake Storage services, it provides a comprehensive alert suite, near real-time Malware Scanning (add-on), and sensitive data threat detection (no extra cost), allowing quick detection, triage, and response to potential security threats with contextual information. It helps prevent the three major impacts on your data and workload: malicious file uploads, sensitive data exfiltration, and data corruption.

-| Feature availability: |- Activity monitoring (security alerts) ΓÇô General Availability (GA)<br>- Malware Scanning ΓÇô General Availability (GA)<br>- Sensitive data threat detection (Sensitive Data Discovery) ΓÇô Preview<br><br>Visit the [pricing page](https://azure.microsoft.com/pricing/details/defender-for-cloud) to learn more. |

-|Required roles and permissions: | For Malware Scanning and sensitive data threat detection at subscription and storage account levels, you need Owner roles (subscription owner/storage account owner) or specific roles with corresponding data actions. To enable Activity Monitoring, you need 'Security Admin' permissions. Read more about the required permissions. |

-*Azure DNS Zone is not supported for Malware Scanning and sensitive data threat detection.

-## Prerequisites for Malware scanning

-To enable and configure Malware Scanning, you must have Owner roles (such as Subscription Owner or Storage Account Owner) or specific roles with the necessary data actions. Learn more about the [required permissions](support-matrix-defender-for-storage.md).

-> [!IMPORTANT]

-> Public internet access must **not** be blocked from the storage accounts being used to backup or restore resources.

-#### time for 500 minutes later for SAS token expiry

-```

-## Restore HSM

-```

-# Register and authorize spacecraft

-## Sign in to Azure

-Sign in to the [Azure portal](https://aka.ms/orbital/portal).

-1. In the Azure portal search box, enter **Spacecraft**. Select **Spacecraft** in the search results.

-2. In the **Spacecraft** page, select Create.

-3. In **Create spacecraft resource**, enter or select this information in the Basics tab:

- > TLE stands for Two-Line Element.

- > Be sure to update this TLE value before you schedule a contact. A TLE that is more than two weeks old might result in an unsuccessful downlink.

-4. Select the **Links** tab, or select the **Next: Links** button at the bottom of the page.

-5. In the **Links** page, enter or select this information:

-6. Select the **Review + create** tab, or select the **Review + create** button.

-7. Select **Create**

-Submit a spacecraft authorization request in order to schedule [contacts](concepts-contact.md) with your new spacecraft resource at applicable ground station sites.

-1. Navigate to the newly created spacecraft resource's overview page.

-2. Select **New support request** in the Support + troubleshooting section of the left-hand blade.

-3. In the **New support request** page, enter or select this information in the Basics tab:

-4. Select the Details tab at the top of the page

-5. In the Details tab, enter this information in the Problem details section:

-7. Select the **Review + create** tab, or select the **Review + create** button.

-8. Select **Create**.

-After the spacecraft authorization request is submitted, the Azure Orbital Ground Station team will review the request and authorize the spacecraft resource at relevant ground stations according to the licenses. Authorization requests for public satellites will be quickly approved.

-1. In the Azure portal search box, enter **Spacecraft**. Select **Spacecraft** in the search results.

-2. In the **Spacecraft** page, select the newly registered spacecraft.

-Schedule a contact with your satellite for data retrieval and delivery on Azure Orbital Ground Station. At the scheduled time, the selected ground station will contact the satellite and start data retrieval/delivery using the designated contact profile.

-## Sign in to Azure

-Sign in to the [Azure portal - Orbital](https://aka.ms/orbital/portal).

-## Select an available contact

-1. In the Azure portal search box, enter **Spacecraft**. Select **Spacecraft** in the search results.

-2. In the **Spacecraft** page, select the spacecraft for the contact.

-3. Select **Schedule contact** on the top bar of the spacecraftΓÇÖs overview.

-4. In the **Schedule contact** page, specify this information from the top of the page:

-5. Select **Search** to view available contact times.

-6. Select one or more contact windows and select **Schedule**.

-7. View scheduled contacts by selecting the spacecraft page, and navigating to **Contacts**.

-## Cancel a contact

-To cancel a scheduled contact, you must delete the contact resource. Learn more at [contact resource](concepts-contact.md).

-## Spacecraft details

-### Ephemeris

-The spacecraft ephemeris is captured in Azure Orbital Ground Station using the Two-Line Element, or TLE.

-A TLE is associated with the spacecraft to determine contact opportunities at the time of scheduling. The TLE is also used to determine the path the antenna must follow during the contact as the spacecraft passes over the ground station during contact execution.

-As TLEs are prone to expiration, the user must keep the TLE up-to-date using the [TLE update](update-tle.md) procedure. A TLE that is more than two weeks old might result in an unsuccessful contact.

-### Licensing

-For more information, see the [spacecraft authorization and ground station licensing](register-spacecraft.md) documentation.

-## Create spacecraft resource

-For more information on how to create a spacecraft resource, see the details listed in the [register a spacecraft](register-spacecraft.md) article.

-## Managing spacecraft resources

-Spacecraft resources can be created and deleted via the Portal and Azure Orbital Ground Station APIs. Once the resource is created, modification to the resource is dependent on the authorization status.

-When the spacecraft is unauthorized, then the spacecraft resource can be modified. The API is the best way to make changes to the spacecraft resource as the Portal only allows TLE updates.

-Once the spacecraft is authorized, TLE updates are the only modifications possible. Other fields, such as links, become immutable. The TLE updates are possible via the Portal and Orbital API.

-## Delete spacecraft resource

-You can delete the spacecraft resource via the Azure portal or the Azure Orbital Ground Station API. You must first delete all scheduled contacts associated with that spacecraft resource. See [contact resource](concepts-contact.md) for more information.

-Azure Database for PostgreSQL = Flexible Server supports both vertical and horizontal scaling options.

-You scale vertically by adding more resources to the Flexible server instance, such as increasing the instance-assigned number of CPUs and memory. Network throughput of your instance depends on the values you choose for CPU and memory. Once a Flexible server instance is created, you can independently change the CPU (vCores), the amount of storage, and the backup retention period. The number of vCores can be scaled up or down. The storage size however can only be increased. In addition, uou can scale the backup retention period up or down from 7 to 35 days. The resources can be scaled using multiple tools for instance [Azure portal](./quickstart-create-server-portal.md) or the [Azure CLI](./quickstart-create-server-cli.md).

-You scale horizontally by creating [read replicas](./concepts-read-replicas.md). Read replicas let you scale your read workloads onto separate flexible server instance without affecting the performance and availability of the primary instance.

-When you change the number of vCores or the compute tier, the instance is restarted for the new server type to take effect. During this time the system switches over to the new server type, no new connections can be established, and all uncommitted transactions will be rolled back. The overall time it takes to restart your server depends on the crash recovery process and database activity at the time of the restart. Restarts typically takes a minute or less but it can be higher and can take several minutes, depending on transactional activity at the time of the restart. Scaling the storage does not require a server restart in most cases. Similarly, backup retention period changes is an online operation. To improve the restart time, we recommend that you perform scale operations during off-peak hours. That approach reduces the time needed to restart the database server.

-Near-zero Downtime Scaling is a feature designed to minimize downtime when modifying storage and compute tiers. If you modify the number of vCores or change the compute tier, the server undergoes a restart to apply the new configuration. During this transition to the new server, no new connections can be established. Typically, this process with regular scaling could take anywhere between 2 to 10 minutes. However, with the new 'Near-zero downtime' Scaling feature this duration has been reduced to less than 30 seconds. This significant reduction in downtime during scaling resources, that greatly improves the overall availability of your database instance.

-When updating your Flexible server in scaling scenarios, we create a new copy of your server (VM) with the updated configuration, synchronize it with your current one, briefly switch to the new copy with a 30-second interruption, and retire the old server, all at no extra cost to you. This process allows for seamless updates while minimizing downtime and ensuring cost-efficiency. This scaling process is triggered when changes are made to the storage and compute tiers, and the experience remains consistent for both (HA) and non-HA servers. This feature is enabled in all Azure regions and there is **no customer action required** to use this capability.

-#### Pre-requisites

-To configure Azure DevOps for SAP Deployment Automation Framework, see [Configure Azure DevOps for SAP Deployment Automation Framework](configure-devops.md).

-description: "Learn how to install the connector Cyberpion Security Logs to connect your data source to Microsoft Sentinel."

-# Cyberpion Security Logs connector for Microsoft Sentinel

-The Cyberpion Security Logs data connector, ingests logs from the Cyberpion system directly into Sentinel. The connector allows users to visualize their data, create alerts and incidents and improve security investigations.

-## Connector attributes

-| Connector attribute | Description |

-| | |

-| **Log Analytics table(s)** | CyberpionActionItems_CL<br/> |

-| **Data collection rules support** | Not currently supported |

-| **Supported by** | [Cyberpion](https://www.cyberpion.com/contact/) |

-## Query samples

-**Fetch latest Action Items that are currently open**

- ```kusto

-let lookbackTime = 14d;

-let maxTimeGeneratedBucket = toscalar(

- CyberpionActionItems_CL

-

- | where TimeGenerated > ago(lookbackTime)

-

- | summarize max(bin(TimeGenerated, 1h))

- );

-CyberpionActionItems_CL

-

- | where TimeGenerated > ago(lookbackTime) and is_open_b == true

-

- | where bin(TimeGenerated, 1h) == maxTimeGeneratedBucket

-

- ```

-## Prerequisites

-To integrate with Cyberpion Security Logs make sure you have:

-## Vendor installation instructions

-Follow the [instructions](https://www.cyberpion.com/resource-center/integrations/azure-sentinel/) to integrate Cyberpion Security Alerts into Sentinel.

-## Next steps

-For more information, go to the [related solution](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/cyberpion1597832716616.cyberpion_mss?tab=Overview) in the Azure Marketplace.

-## Configure API portal

-The following sections describe configuration in API portal.

-### Configure single sign-on (SSO)

-| issuerUri | Yes | The URI that the app asserts as its Issuer Identifier. For example, if the issuer-uri provided is "https://example.com", then an OpenID Provider Configuration Request will be made to "https://example.com/.well-known/openid-configuration". The result is expected to be an OpenID Provider Configuration Response. |

-### Configure the instance count

-Configuration of the instance count for API portal is supported, unless you're using SSO. If you're using the SSO feature, only one instance count is supported.

-To access API portal, use the following steps to assign a public endpoint:

-1. Select **Yes** next to *Assign endpoint* to assign a public endpoint. A URL will be generated within a few minutes.

-You can also use the Azure CLI to assign a public endpoint with the following command:

-1. Create an app in Azure Spring Apps that the gateway will route traffic to.

-Select the `endpoint URL` to go to API portal. You'll see all the routes configured in Spring Cloud Gateway for Tanzu.

-1. Select **EXECUTE**, and the response will be shown.

-description: How to configure a point-to-site (P2S) VPN on Windows for use with Azure Files

-Before setting up the point-to-site VPN, you need to collect some information about your environment. Replace `<resource-group>`, `<vnet-name>`, `<subnet-name>`, and `<storage-account-name>` with the appropriate values for your environment.

-In order for VPN connections from your on-premises Windows machines to be authenticated to access your virtual network, you must create two certificates: a root certificate, which will be provided to the virtual machine gateway, and a client certificate, which will be signed with the root certificate. The following PowerShell creates the root certificate; you'll create the client certificate after deploying the Azure virtual network gateway.

-The Azure virtual network gateway is the service that your on-premises Windows machines will connect to. Before deploying the virtual network gateway, you must create a [gateway subnet](../../vpn-gateway/vpn-gateway-about-vpn-gateway-settings.md#gwsub) on the virtual network.

-2. The root certificate you created earlier, which will be used to authenticate your clients

-Remember to replace `<desired-vpn-name-here>`, `<desired-region-here>`, and `<gateway-subnet-name-here>` in the following script with the proper values for these variables.

-> [!NOTE]

-> Deploying the Azure virtual network gateway can take up to 45 minutes. While this resource is being deployed, this PowerShell script will block the deployment from being completed. This is expected.

-$vpnName = "<desired-vpn-name-here>"

-$region = "<desired-region-here>"

-$gatewaySubnet = "<gateway-subnet-name-here>"

- -GatewaySku VpnGw1 `

-The following script creates the client certificate with the URI of the virtual network gateway. This certificate is signed with the root certificate you created earlier.

-The Azure virtual network gateway will create a downloadable package with configuration files required to initialize the VPN connection on your on-premises Windows machine. You'll configure the VPN connection using the [Always On VPN](/windows-server/remote/remote-access/vpn/always-on-vpn/) feature introduced in Windows 10/Windows Server 2016. This package also contains executables that will configure the legacy Windows VPN client, if desired. This guide uses Always On VPN rather than the legacy Windows VPN client because the Always On VPN client allows you to connect/disconnect from the Azure VPN without having administrator permissions to the machine.

-The following script will install the client certificate required for authentication against the virtual network gateway, and then download and install the VPN package. Remember to replace `<computer1>` and `<computer2>` with the desired computers. You can run this script on as many machines as you desire by adding more PowerShell sessions to the `$sessions` array. Your user account must be an administrator on each of these machines. If one of these machines is the local machine you're running the script from, you must run the script from an elevated PowerShell session.

-Now that you've set up your point-to-Site VPN, you can use it to mount the Azure file share to an on-premises machine. The following example will mount the share, list the root directory of the share to prove the share is actually mounted, and then unmount the share.

-In this quickstart, you deploy three virtual networks and use Azure Virtual Network Manager to create a mesh network topology. Then, you verify that the connectivity configuration was applied.

-1. Create a file named `providers.tf` and insert the following code:

-1. Create a file named `main.tf` and insert the following code:

-1. Create a file named `variables.tf` and insert the following code:

-1. Create a file named `outputs.tf` and insert the following code:

-