+| Model | Description | Performance notes | Landmarks |

+|-|-|-|--|

+|**detection_01** | Default choice for all face detection operations. | Not optimized for small, side-view, or blurry faces. | Returns face landmarks if they're specified in the detect call. |

+|**detection_02** | Released in May 2019 and available optionally in all face detection operations. | Improved accuracy on small, side-view, and blurry faces. | Doesn't return face landmarks. |

+|**detection_03** | Released in February 2021 and available optionally in all face detection operations. | Further improved accuracy, including on smaller faces (64x64 pixels) and rotated face orientations. | Returns face landmarks if they're specified in the detect call. |

+Attributes are a set of features that can optionally be detected if they're specified in the detect call:

+| Model | accessories | blur | exposure | glasses | headPose | mask | noise | occlusion | qualityForRecognition |

+|-|:--:|:-:|:--:|:-:|:--:|:-:|:--:|::|::|

+|**detection_01** | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | | ✔️ | ✔️ | ✔️ (for recognition_03 or 04) |

+|**detection_02** | | | | | | | | | |

+|**detection_03** | | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | | ✔️ | ✔️ (for recognition_03 or 04) |

+## August 2024

+### New detectable Face attributes

+The glasses, occlusion, blur, and exposure attributes are available with the latest Detection 03 model. See [Specify a face detection model](./how-to/specify-detection-model.md) for more details.

+## May 2024

+### New Face SDK 1.0.0-beta.1 (breaking changes)

+The Face SDK was rewritten in version 1.0.0-beta.1 to better meet the guidelines and design principles of Azure SDKs. C#, Python, Java, and JavaScript are the supported languages. Follow the [QuickStart](./quickstarts-sdk/identity-client-library.md) to get started.

+|USNat West |✅ |✅ |❌ |

+|USNat East |✅ |✅ |❌ |

+|USSec West |✅ |✅ |❌ |

+|USSec East |✅ |✅ |❌ |

+ - Compute resources for interactive development, fine-tuning, open source, and serverless model deployments.

+ Title: GenAI gateway capabilities in Azure API Management

+description: Learn about Azure API Management's policies and features to manage generative AI APIs, such as token rate limiting, load balancing, and semantic caching.

+# Overview of generative AI gateway capabilities in Azure API Management

+This article introduces capabilities in Azure API Management to help you manage generative AI APIs, such as those provided by [Azure OpenAI Service](../ai-services/openai/overview.md). Azure API Management provides a range of policies, metrics, and other features to enhance security, performance, and reliability for the APIs serving your intelligent apps. Collectively, these features are called *generative AI (GenAI) gateway capabilities* for your generative AI APIs.

+> [!NOTE]

+> * This article focuses on capabilities to manage APIs exposed by Azure OpenAI Service. Many of the GenAI gateway capabilities apply to other large language model (LLM) APIs, including those available through [Azure AI Model Inference API](../ai-studio/reference/reference-model-inference-api.md).

+> * Generative AI gateway capabilities are features of API Management's existing API gateway, not a separate API gateway. For more information on API Management, see [Azure API Management overview](api-management-key-concepts.md).

+## Challenges in managing generative AI APIs

+One of the main resources you have in generative AI services is *tokens*. Azure OpenAI Service assigns quota for your model deployments expressed in tokens-per-minute (TPM) which is then distributed across your model consumers - for example, different applications, developer teams, departments within the company, etc.

+Azure makes it easy to connect a single app to Azure OpenAI Service: you can connect directly using an API key with a TPM limit configured directly on the model deployment level. However, when you start growing your application portfolio, you're presented with multiple apps calling single or even multiple Azure OpenAI Service endpoints deployed as pay-as-you-go or [Provisioned Throughput Units](../ai-services/openai/concepts/provisioned-throughput.md) (PTU) instances. That comes with certain challenges:

+* How is token usage tracked across multiple applications? Can cross-charges be calculated for multiple applications/teams that use Azure OpenAI Service models?

+* How do you ensure that a single app doesn't consume the whole TPM quota, leaving other apps with no option to use Azure OpenAI Service models?

+* How is the API key securely distributed across multiple applications?

+* How is load distributed across multiple Azure OpenAI endpoints? Can you ensure that the committed capacity in PTUs is exhausted before falling back to pay-as-you-go instances?

+The rest of this article describes how Azure API Management can help you address these challenges.

+## Import Azure OpenAI Service resource as an API

+[Import an API from an Azure OpenAI Service endpoint](azure-openai-api-from-specification.md) to Azure API management using a single-click experience. API Management streamlines the onboarding process by automatically importing the OpenAPI schema for the Azure OpenAI API and sets up authentication to the Azure OpenAI endpoint using managed identity, removing the need for manual configuration. Within the same user-friendly experience, you can preconfigure policies for [token limits](#token-limit-policy) and [emitting token metrics](#emit-token-metric-policy).

+## Token limit policy

+Configure the [Azure OpenAI token limit policy](azure-openai-token-limit-policy.md) to manage and enforce limits per API consumer based on the usage of Azure OpenAI Service tokens. With this policy you can set limits, expressed in tokens-per-minute (TPM).

+This policy provides flexibility to assign token-based limits on any counter key, such as subscription key, originating IP address, or an arbitrary key defined through a policy expression. The policy also enables precalculation of prompt tokens on the Azure API Management side, minimizing unnecessary requests to the Azure OpenAI Service backend if the prompt already exceeds the limit.

+The following basic example demonstrates how to set a TPM limit of 500 per subscription key:

+```xml

+<azure-openai-token-limit counter-key="@(context.Subscription.Id)"

+ tokens-per-minute="500" estimate-prompt-tokens="false" remaining-tokens-variable-name="remainingTokens">

+</azure-openai-token-limit>

+```

+> [!TIP]

+> To manage and enforce token limits for LLM APIs available through the Azure AI Model Inference API, API Management provides the equivalent [llm-token-limit](llm-token-limit-policy.md) policy.

+## Emit token metric policy

+The [Azure OpenAI emit token metric](azure-openai-emit-token-metric-policy.md) policy sends metrics to Application Insights about consumption of LLM tokens through Azure OpenAI Service APIs. The policy helps provide an overview of the utilization of Azure OpenAI Service models across multiple applications or API consumers. This policy could be useful for chargeback scenarios, monitoring, and capacity planning.

+This policy captures prompt, completions, and total token usage metrics and sends them to an Application Insights namespace of your choice. Moreover, you can configure or select from predefined dimensions to split token usage metrics, so you can analyze metrics by subscription ID, IP address, or a custom dimension of your choice.

+For example, the following policy sends metrics to Application Insights split by client IP address, API, and user:

+```xml

+<azure-openai-emit-token-metric namespace="openai">

+ <dimension name="Client IP" value="@(context.Request.IpAddress)" />

+ <dimension name="API ID" value="@(context.Api.Id)" />

+ <dimension name="User ID" value="@(context.Request.Headers.GetValueOrDefault("x-user-id", "N/A"))" />

+</azure-openai-emit-token-metric>

+```

+> [!TIP]

+> To send metrics for LLM APIs available through the Azure AI Model Inference API, API Management provides the equivalent [llm-emit-token-metric](llm-emit-token-metric-policy.md) policy.

+## Backend load balancer and circuit breaker

+One of the challenges when building intelligent applications is to ensure that the applications are resilient to backend failures and can handle high loads. By configuring your Azure OpenAI Service endpoints using [backends](backends.md) in Azure API Management, you can balance the load across them. You can also define circuit breaker rules to stop forwarding requests to the Azure OpenAI Service backends if they're not responsive.

+The backend [load balancer](backends.md#backends-in-api-management) supports round-robin, weighted, and priority-based load balancing, giving you flexibility to define a load distribution strategy that meets your specific requirements. For example, define priorities within the load balancer configuration to ensure optimal utilization of specific Azure OpenAI endpoints, particularly those purchased as PTUs.

+The backend [circuit breaker](backends.md#circuit-breaker) features dynamic trip duration, applying values from the Retry-After header provided by the backend. This ensures precise and timely recovery of the backends, maximizing the utilization of your priority backends.

+## Semantic caching policy

+Configure [Azure OpenAI semantic caching](azure-openai-enable-semantic-caching.md) policies to optimize token consumption by using semantic caching, which stores completions for prompts with similar meaning.

+In API Management, enable semantic caching by using Azure Redis Enterprise or another [external cache](api-management-howto-cache-external.md) compatible with RediSearch and onboarded to Azure API Management. By using the Azure OpenAI Service Embeddings API, the [azure-openai-semantic-cache-store](azure-openai-semantic-cache-store-policy.md) and [azure-openai-semantic-cache-lookup](azure-openai-semantic-cache-lookup-policy.md) policies store and retrieve semantically similar prompt completions from the cache. This approach ensures completions reuse, resulting in reduced token consumption and improved response performance.

+> [!TIP]

+> To enable semantic caching for LLM APIs available through the Azure AI Model Inference API, API Management provides the equivalent [llm-semantic-cache-store-policy](llm-semantic-cache-store-policy.md) and [llm-semantic-cache-lookup-policy](llm-semantic-cache-lookup-policy.md) policies.

+## Labs and samples

+* [Labs for the GenAI gateway capabilities of Azure API Management](https://github.com/Azure-Samples/AI-Gateway)

+* [Azure API Management (APIM) - Azure OpenAI Sample (Node.js)](https://github.com/Azure-Samples/genai-gateway-apim)

+* [Python sample code for using Azure OpenAI with API Management](https://github.com/Azure-Samples/openai-apim-lb/blob/main/docs/sample-code.md)

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

+## Architecture and design considerations

+* [GenAI gateway reference architecture using API Management](/ai/playbook/technology-guidance/generative-ai/dev-starters/genai-gateway/reference-architectures/apim-based)

+* [Designing and implementing a gateway solution with Azure OpenAI resources](/ai/playbook/technology-guidance/generative-ai/dev-starters/genai-gateway/)

+* [Use a gateway in front of multiple Azure OpenAI deployments or instances](/azure/architecture/ai-ml/guide/azure-openai-gateway-multi-backend)

+## Related content

+* [Blog: Introducing GenAI capabilities in Azure API Management](https://techcommunity.microsoft.com/t5/azure-integration-services-blog/introducing-genai-gateway-capabilities-in-azure-api-management/ba-p/4146525)

+* [Blog: Integrating Azure Content Safety with API Management for Azure OpenAI Endpoints](https://techcommunity.microsoft.com/t5/fasttrack-for-azure/integrating-azure-content-safety-with-api-management-for-azure/ba-p/4202505)

+* [Smart load balancing for OpenAI endpoints and Azure API Management](https://techcommunity.microsoft.com/t5/fasttrack-for-azure/smart-load-balancing-for-openai-endpoints-and-azure-api/ba-p/3991616)

+* [Authenticate and authorize access to Azure OpenAI APIs using Azure API Management](api-management-authenticate-authorize-azure-openai.md)

+- **ResourceGroupName**: Original resource group for the deleted app, you can get it from Get-AzDeletedWebApp -Name <your_deleted_app> -Location <your_deleted_app_location>

+JBoss EAP is available in the following pricing tiers: **F1**,

+**P0v3**, **P1mv3**, **P2mv3**, **P3mv3**, **P4mv3**, and **P5mv3**.

+ kubectl exec -it dnsutil-win -- powershell

+Some connections in Azure Functions can be configured to use an identity instead of a secret. Support depends on the runtime version and the extension using the connection. In some cases, a connection string may still be required in Functions even though the service to which you're connecting supports identity-based connections. For a tutorial on configuring your function apps with managed identities, see the [creating a function app with identity-based connections tutorial](./functions-identity-based-connections-tutorial.md).

+Identity-based connections are only supported on Functions 4.x, If you are using version 1.x, you must first [migrate to version 4.x](./migrate-version-1-version-4.md).

+##### Azure SDK Environment Variables

+> [!CAUTION]

+> Use of the Azure SDK's [`EnvironmentCredential`][environment-credential] environment variables is not recommended due to the potentially unintentional impact on other connections. They also are not fully supported when deployed to Azure Functions.

+The environment variables associated with the Azure SDK's [`EnvironmentCredential`][environment-credential] can also be set, but these are not processed by the Functions service for scaling in Consumption plans. These environment variables are not specific to any one connection and will apply as a default unless a corresponding property is not set for a given connection. For example, if `AZURE_CLIENT_ID` is set, this would be used as if `<CONNECTION_NAME_PREFIX>__clientId` had been configured. Explicitly setting `<CONNECTION_NAME_PREFIX>__clientId` would override this default.

+[environment-credential]: /dotnet/api/azure.identity.environmentcredential

+> The recommendation is to enable [Automatic Extension Upgrade](../../virtual-machines/automatic-extension-upgrade.md) to update installed extensions to the released (latest) version across all regions. Upgrades are issued in batches, so you may see some of your virtual machines, scale-sets or Arc-enabled servers get upgraded before others. If you need to upgrade an extension immediately, you may use the manual instructions below.

+ $serverGroups = @()

+ .\MMAUnistallUtilityScript.ps1 UninstallExtension

+> [!div class="checklist"]

+> - Set up and deploy an ASP.NET Core web application hosted on Linux.

+> - Add Application Insights Profiler to the ASP.NET Core web application.

+ Title: Enable Profiler for Azure Functions apps

+# Enable Profiler for Azure Functions apps

+Meanwhile, when you "bring your own storage" (BYOS), artifacts are uploaded into a storage account that only you control and cover the cost for:

+- Verify you created your storage account in the same location as your Application Insights resource.

+- If you enabled [Private Link](../logs/private-link-security.md), allow connection to our Trusted Microsoft Service from your virtual network.

+ :::image type="content" source="media/profiler-bring-your-own-storage/add-role-assignment-page.png" alt-text="Screenshot that shows the role assignment page in the Azure portal.":::

+Troubleshoot common issues in configuring BYOS.

+You received an error similar to the following example:

+You received an error similar to the following example:

+You received an error similar to the following example:

+### If I enabled Profiler/Snapshot Debugger and BYOS, is my data migrated into my storage account?

+### If I enabled BYOS, can I go back to using Diagnostic Services storage accounts to store my collected data?

+ Title: Enable Profiler for Azure Cloud Services

+> [!div class="checklist"]

+> - Install the NuGet package in the project.

+> - Set the environment variable via the orchestrator (like Kubernetes).

+> - Learn security considerations around production deployment, like protecting your Application Insights instrumentation key.

+In this guide, you learn how to:

+> [!div class="checklist"]

+> - Add the Application Insights Profiler property to your ARM template.

+> - Deploy your Service Fabric cluster with the Application Insights Profiler instrumentation key.

+> - Enable Application Insights on your Service Fabric application.

+> - Redeploy your Service Fabric cluster to enable Profiler.

+1. Early in the application lifetime, add the following code:

+ ```csharp

+ using Microsoft.ApplicationInsights.Extensibility;

+ ...

+ // Replace with your own Application Insights instrumentation key.

+ TelemetryConfiguration.Active.InstrumentationKey = "00000000-0000-0000-0000-000000000000";

+ ```

+ For more information about this global instrumentation key configuration, see [Use Service Fabric with Application Insights](https://github.com/Azure-Samples/service-fabric-dotnet-getting-started/blob/dev/appinsights/ApplicationInsights.md).

+1. For any piece of code that you want to instrument, add a `StartOperation<RequestTelemetry>` **using** statement around it, as shown in the following example:

+ ```csharp

+ using Microsoft.ApplicationInsights;

+ using Microsoft.ApplicationInsights.DataContracts;

+ ...

+ var client = new TelemetryClient();

+ ...

+ using (var operation = client.StartOperation<RequestTelemetry>("Insert_Your_Custom_Event_Unique_Name"))

+ {

+ // ... Code I want to profile.

+ }

+ ```

+1. Calling `StartOperation<RequestTelemetry>` within another `StartOperation<RequestTelemetry>` scope isn't supported. You can use `StartOperation<DependencyTelemetry>` in the nested scope instead. For example:

+ ```csharp

+ using (var getDetailsOperation = client.Operation<RequestTelemetry>("GetProductDetails"))

+ {

+ try

+ {

+ ProductDetail details = new ProductDetail() { Id = productId };

+ getDetailsOperation.Telemetry.Properties["ProductId"] = productId.ToString();

+

+ // By using DependencyTelemetry, 'GetProductPrice' is correctly linked as part of the 'GetProductDetails' request.

+ using (var getPriceOperation = client.StartOperation<DependencyTelemetry>("GetProductPrice"))

+ {

+ double price = await _priceDataBase.GetAsync(productId);

+ if (IsTooCheap(price))

+ {

+ throw new PriceTooLowException(productId);

+ }

+ details.Price = price;

+ }

+

+ // Similarly, note how 'GetProductReviews' doesn't establish another RequestTelemetry.

+ using (var getReviewsOperation = client.StartOperation<DependencyTelemetry>("GetProductReviews"))

+ {

+ details.Reviews = await _reviewDataBase.GetAsync(productId);

+ }

+

+ getDetailsOperation.Telemetry.Success = true;

+ return details;

+ }

+ catch(Exception ex)

+ {

+ getDetailsOperation.Telemetry.Success = false;

+

+ // This exception gets linked to the 'GetProductDetails' request telemetry.

+ client.TrackException(ex);

+ throw;

+ }

+ }

+ ```

+Select your preferred method tab to:

+In this guide, you learn how to:

+> [!div class="checklist"]

+> - Configure the Azure Diagnostics extension to run Profiler.

+> - Install the Application Insights SDK on a VM.

+> - Deploy your application.

+> - View Profiler traces via the Application Insights instance in the Azure portal.

+[Application Insights Profiler](./profiler-overview.md) is preinstalled as part of the Azure App Service runtime. You can run Profiler on ASP.NET and ASP.NET Core apps running on App Service by using the Basic service tier or higher.

+You can enable Profiler either when:

+- [Your Application Insights resource and App Service resource are in the same subscription](#for-application-insights-and-app-service-in-the-same-subscription), or

+- [Your Application Insights resource and App Service resource are in separate subscriptions.](#for-application-insights-and-app-service-in-different-subscriptions)

+This graph represents a 64 kibibyte (KiB) sequential workload and a 1 TiB working set. It shows that a single Azure NetApp Files volume can handle between ~1,600 MiB/s pure sequential writes and ~4,500 MiB/s pure sequential reads.

+The following graph represents a 4-KiB random workload and a 1 TiB working set. The graph shows that an Azure NetApp Files volume can handle between ~130,000 pure random writes and ~460,000 pure random reads.

+The graphs compare the advantages of `nconnect` to a non-`connected` mounted volume. In the graphs, FIO generated the workload from a single D32s_v4 instance in the us-west2 Azure region using a 64-KiB sequential workload ΓÇô the largest I/O size supported by Azure NetApp Files at the time of the testing represented here. Azure NetApp Files now supports larger I/O sizes. For more information, see [`rsize` and `wsize` section of Linux mount options](performance-linux-mount-options.md#rsize-and-wsize).

+The following graphs show sequential writes. They indicate that `nconnect` has no noticeable benefit for sequential writes. The sequential write volume upper limit is approximately 1,500 MiB/s; the D32s_v4 instance egress limit is also approximately 1,500 MiB/s.

+ The most common parameter used in storage performance benchmarking is direct I/O. It's supported by FIO and Vdbench. DISKSPD offers support for the similar construct of memory-mapped I/O. With direct I/O, the filesystem cache is bypassed, operations for direct memory access copy are avoided, and storage tests are made fast and simple.

+Using the direct I/O parameter makes storage testing easy. No data is read from the filesystem cache on the client. As such, the test is truly stressing the storage protocol and service itself, rather than memory access speeds. Without the DMA memory copies, read and write operations are efficient from a processing perspective.

+Take the Linux `dd` command as an example workload. Without the optional `odirect` flag, all I/O generated by `dd` is served from the Linux buffer cache. Reads with the blocks already in memory aren't retrieved from storage. Reads resulting in a buffer cache miss end up being read from storage using NFS read-ahead with varying results, depending on factors as mount `rsize` and client read-ahead tunables. When writes are sent through the buffer cache, they use a write-behind mechanism, which is untuned and uses a significant amount of parallelism to send the data to the storage device. You might attempt to run two independent streams of I/O, one `dd` for reads and one `dd` for writes. But in fact, the operating system, untuned, favors writes over reads and uses more parallelism of it.

+Aside from database, few applications use direct I/O. Instead, they leverage the advantages of a large memory cache for repeated reads and a write behind cache for asynchronous writes. In short, using direct I/O turns the test into a micro benchmark *if* the application being synthesized uses the filesystem cache.

+Testing with `directio` is an excellent way to understand the limits of the storage service and client. To better understand how the application behaves (if the application doesn't use `directio`), you should also run tests through the filesystem cache.

+This article helps you understand filesystem cache best practices for Azure NetApp Files.

+* Flushing a dirty buffer leaves the data in a clean state usable for future reads until memory pressure leads to eviction.

+These factors are controlled by four tunables. Each tunable can be tuned dynamically and persistently using `tuned` or `sysctl` in the `/etc/sysctl.conf` file. Tuning these variables improves performance for applications.

+> Information discussed in this article was uncovered during SAS GRID and SAS Viya validation exercises. As such, the tunables are based on lessons learned from the validation exercises. Many applications similarly benefit from tuning these parameters.

+These two tunables define the amount of RAM made usable for data modified but not yet written to stable storage. Whichever tunable is set automatically sets the other tunable to zero; RedHat advises against manually setting either of the two tunables to zero. The option `vm.dirty_ratio` (the default of the two) is set by Redhat to either 20% or 30% of physical memory depending on the OS, which is a significant amount considering the memory footprint of modern systems. Consideration should be given to setting `vm.dirty_bytes` instead of `vm.dirty_ratio` for a more consistent experience regardless of memory size. For example, ongoing work with SAS GRID determined 30 MiB an appropriate setting for best overall mixed workload performance.

+These tunables define the starting point where the Linux write-back mechanism begins flushing dirty blocks to stable storage. Redhat defaults to 10% of physical memory, which, on a large memory system, is a significant amount of data to start flushing. Taking SAS GRID for example, historically the recommendation was to set `vm.dirty_background` to 1/5 size of `vm.dirty_ratio` or `vm.dirty_bytes`. Considering how aggressively the `vm.dirty_bytes` setting is set for SAS GRID, no specific value is being set here.

+This tunable defines how old a dirty buffer can be before it must be tagged for asynchronously writing out. Take SAS ViyaΓÇÖs CAS workload for example. An ephemeral write-dominant workload found that setting this value to 300 centiseconds (3 seconds) was optimal, with 3000 centiseconds (30 seconds) being the default.

+SAS Viya shares CAS data into multiple small chunks of a few megabytes each. Rather than closing these file handles after writing data to each shard, the handles are left open and the buffers within are memory-mapped by the application. Without a close, there's no flush until either memory pressure or 30 seconds has passed. Waiting for memory pressure proved suboptimal as did waiting for a long timer to expire. Unlike SAS GRID, which looked for the best overall throughput, SAS Viya looked to optimize write bandwidth.

+The kernel flusher thread is responsible for asynchronously flushing dirty buffers between each flush thread sleeps. This tunable defines the amount spent sleeping between flushes. Considering the 3-second `vm.dirty_expire_centisecs` value used by SAS Viya, SAS set this tunable to 100 centiseconds (1 second) rather than the 500 centiseconds (5 seconds) default to find the best overall performance.

+Considering the default virtual memory tunables and the amount of RAM in modern systems, write-back potentially slows down other storage-bound operations from the perspective of the specific client driving this mixed workload. The following symptoms may be expected from an untuned, write-heavy, cache-laden Linux machine.

+You might experience this behavior only by *the Linux machine* performing the mixed write-heavy workload. Further, the experience is degraded against all NFS volumes mounted against a single storage endpoint. If the mounts come from two or more endpoints, only the volumes sharing an endpoint exhibit this behavior.

+To understand what is going with virtual memory and the write-back, consider the following code snippet and output. *Dirty* represents the amount dirty memory in the system, and *writeback* represents the amount of memory actively being written to storage.

+The following output comes from an experiment where the `vm.dirty_ratio` and the `vm.dirty_background` ratio were set to 2% and 1% of physical memory respectively. In this case, flushing began at 3.8 GiB, 1% of the 384-GiB memory system. Writeback closely resembled the write throughput to NFS.

+Using the `nconnect` mount option allows you to specify the number of connections (network flows) that should be established between the NFS client and NFS endpoint up to a limit of 16. Traditionally, an NFS client uses a single connection between itself and the endpoint. Increasing the number of network flows increases the upper limits of I/O and throughput significantly. Testing has found `nconnect=8` to be the most performant.

+ > SLES15SP2 is the minimum SUSE release in which `nconnect` is supported by Azure NetApp Files for NFSv4.1. All other releases as specified are the first releases that introduced the `nconnect` feature.

+* All mounts from a single endpoint inherit the `nconnect` setting of the first export mounted, as shown in the following scenarios:

+ Scenario 2: `nconnect` isn't used by the first mount. Therefore, no mounts against the same endpoint use `nconnect` even though `nconnect` may be specified thereon.

+ Scenario 3: `nconnect` settings aren't propagated across separate storage endpoints. `nconnect` is used by the mount coming from `10.10.10.10` but not by the mount coming from `10.12.12.12`.

+The `rsize` and `wsize` flags set the maximum transfer size of an NFS operation. If `rsize` or `wsize` aren't specified on mount, the client and server negotiate the largest size supported by the two. Currently, both Azure NetApp Files and modern Linux distributions support read and write sizes as large as 1,048,576 Bytes (1 MiB). However, for best overall throughput and latency, Azure NetApp Files recommends setting both `rsize` and `wsize` no larger than 262,144 Bytes (256 K). You might observe that both increased latency and decreased throughput when using `rsize` and `wsize` larger than 256 KiB.

+* Random I/O operation sizes are often smaller than the `rsize` and `wsize` mount options. As such, they aren't constraints.

+* Operations bypassing the filesystem cache, although still constrained by the `rsize` and `wsize` mount options, aren't as large as the maximum specified by `rsize` or `wsize`. This consideration is important when you use workload generators that have the `directio` option.

+NFS uses a loose consistency model. The consistency is loose because the application doesn't have to go to shared storage and fetch data every time to use it, a scenario that would have a tremendous impact to application performance. There are two mechanisms that manage this process: cache attribute timers and close-to-open consistency.

+*If the client has complete ownership of data, that is, it's not shared between multiple nodes or systems, there is guaranteed consistency.* In that case, you can reduce the `getattr` access operations to storage and speed up the application by turning off close-to-open (`cto`) consistency (`nocto` as a mount option) and by turning up the timeouts for the attribute cache management (`actimeo=600` as a mount option changes the timer to 10m versus the defaults `acregmin=3,acregmax=30,acdirmin=30,acdirmax=60`). In some testing, `nocto` reduces approximately 65-70% of the `getattr` access calls, and adjusting `actimeo` reduces these calls another 20-25%.

+The attributes `acregmin`, `acregmax`, `acdirmin`, and `acdirmax` control the coherency of the cache. The former two attributes control how long the attributes of files are trusted. The latter two attributes control how long the attributes of the directory file itself are trusted (directory size, directory ownership, directory permissions). The `min` and `max` attributes define minimum and maximum duration over which attributes of a directory, attributes of a file, and cache content of a file are deemed trustworthy, respectively. Between `min` and `max`, an algorithm is used to define the amount of time over which a cached entry is trusted.

+For example, consider the default `acregmin` and `acregmax` values, 3 and 30 seconds, respectively. For instance, the attributes are repeatedly evaluated for the files in a directory. After 3 seconds, the NFS service is queried for freshness. If the attributes are deemed valid, the client doubles the trusted time to 6 seconds, 12 seconds, 24 seconds, then as the maximum is set to 30, 30 seconds. From that point on, until the cached attributes are deemed out of date (at which point the cycle starts over), trustworthiness is defined as 30 seconds being the value specified by `acregmax`.

+There are other cases that can benefit from a similar set of mount options, even when there's no complete ownership by the clients, for example, if the clients use the data as read only and data update is managed through another path. For applications that use grids of clients like EDA, web hosting and movie rendering and have relatively static data sets (EDA tools or libraries, web content, texture data), the typical behavior is that the data set is largely cached on the clients. There are few reads and no writes. There are many `getattr`/access calls coming back to storage. These data sets are typically updated through another client mounting the file systems and periodically pushing content updates.

+In these cases, there's a known lag in picking up new content and the application still works with potentially out-of-date data. In these cases, `nocto` and `actimeo` can be used to control the period where out-of-data date can be managed. For example, in EDA tools and libraries, `actimeo=600` works well because this data is typically updated infrequently. For small web hosting where clients need to see their data updates timely as they're editing their sites, `actimeo=10` might be acceptable. For large-scale web sites where there's content pushed to multiple file systems, `actimeo=60` might be acceptable.

+Close-to-open consistency (the `cto` mount option) ensures that no matter the state of the cache, on open the most recent data for a file is always presented to the application.

+* When a directory is crawled (`ls`, `ls -l` for example) a certain set of RPCs (remote procedure calls) are issued.

+ The NFS server shares its view of the filesystem. As long as `cto` is used by all NFS clients accessing a given NFS export, all clients see the same list of files and directories therein. The freshness of the attributes of the files in the directory is controlled by the [attribute cache timers](#how-attribute-cache-timers-work). In other words, as long as `cto` is used, files appear to remote clients as soon as the file is created and the file lands on the storage.

+* When a file is opened, the content of the file is guaranteed fresh from the perspective of the NFS server.

+ If there's a race condition where the content hasn't finished flushing from Machine 1 when a file is opened on Machine 2, Machine 2 only receives the data present on the server at the time of the open. In this case, Machine 2 doesn't retrieve more data from the file until the `acreg` timer is reached, and Machine 2 checks its cache coherency from the server again. This scenario can be observed using a tail `-f` from Machine 2 when the file is still being written to from Machine 1.

+When no close-to-open consistency (`nocto`) is used, the client trusts the freshness of its current view of the file and directory until the cache attribute timers have been breached.

+* When a directory is crawled (`ls`, `ls -l` for example) a certain set of RPCs (remote procedure calls) are issued.

+ The client only issues a call to the server for a current listing of files when the `acdir` cache timer value has been breached. In this case, recently created files and directories don't appear. Recently removed files and directories do appear.

+NFS read-ahead predictively requests blocks from a file in advance of I/O requests by the application. It's designed to improve client sequential read throughput. Until recently, all modern Linux distributions set the read-ahead value to be equivalent of 15 times the mounted filesystems `rsize`.

+| 1,024 KiB | 15,360 KiB |

+RHEL 8.3 and Ubuntu 18.04 introduced changes that might negatively impact client sequential read performance. Unlike earlier releases, these distributions set read-ahead to a default of 128 KiB regardless of the `rsize` mount option used. Upgrading from releases with the larger read-ahead value to releases with the 128-KiB default experienced decreases in sequential read performance. However, read-ahead values may be tuned upward both dynamically and persistently. For example, testing with SAS GRID found the 15,360 KiB read value optimal compared to 3,840 KiB, 960 KiB, and 128 KiB. Not enough tests have been run beyond 15,360 KiB to determine positive or negative impact.

+NFS read-ahead is defined at the mount point for an NFS filesystem. The default setting can be viewed and set both dynamically and persistently. For convenience, the following bash script written by Red Hat is provided for viewing or dynamically setting read-ahead for amounted NFS filesystem.

+Read-ahead can be defined either dynamically per NFS mount using the following script or persistently using `udev` rules as shown in this section. To display or set read-ahead for a mounted NFS filesystem, you can save the following script as a bash file, modify the fileΓÇÖs permissions to make it an executable (`chmod 544 readahead.sh`), and run as shown.

+description: Describes performance test results of an Azure NetApp Files single volume on Oracle database.

+If you don't want to [restore the entire snapshot to a new volume](snapshots-restore-new-volume.md) or [copy large files across the network](snapshots-restore-file-client.md), you can use the single-file snapshot restore feature to recover individual files directly within a volume from a snapshot. This option doesn't require an external client data copy.

+The restore operation doesn't create directories in the process. If the specified destination path is invalid (doesn't exist in Active file system), the restore operation will fail.

+* If you donΓÇÖt specify a destination path, the files restore to the original file location. If the files already exist in the original location, they are overwritten by the files restored from the snapshot.

+2. Select **Snapshots** to display the list of volume snapshots.

+3. Right-click the snapshot that you want to use for restoring files, then select **Restore Files** from the menu.

+ * If you donΓÇÖt specify a destination path, the files are restored to their original location. If files with the same names already exist in the original location, they're overwritten by the files restored from the snapshot.

+ 3. Select **Restore** to initiate the restore operation.

+1. Select **Snapshots**. Right-click the snapshot `daily-10-min-past-12am.2021-09-08_0010`.

+2. Select **Restore Files**.

+1. Select **Snapshots**. Select the snapshot `daily-10-min-past-12am.2021-09-08_0010`.

+2. Select **Restore Files**.

+The [snapshot](snapshots-introduction.md) revert functionality enables you to quickly revert a volume to the state it was in when a particular snapshot was taken. In most cases, reverting a volume is faster than restoring individual files from a snapshot to the active file system. It's also more space efficient compared to restoring a snapshot to a new volume.

+* Reverting a volume using snapshot revert isn't supported on [Azure NetApp Files volumes that have backups](backup-requirements-considerations.md).

+2. In the Revert Volume to Snapshot window, enter the name of the volume then select **Revert**.

+## August 2024

+All new Azure VMware Solution private clouds are being deployed with VMware vSphere 8.0 version. [Learn more](/azure/azure-vmware/architecture-private-clouds)

+Before you start protection of Active Directory, check the following best practices:

+## Back up Azure VM domain controllers

+## Back up on-premises domain controllers

+## Restore Active Directory

+### Restore Azure VM domain controllers

+### Restore on-premises domain controllers

+## Track jobs

+## Next step

+If you created one voice route with a pattern `^\+1(425|206)(\d{7})$` and added `sbc1.contoso.biz` and `sbc2.contoso.biz` to it, and then created a second route with the same pattern with `sbc3.contoso.biz` and `sbc4.contoso.biz`, and created a third route with `^\+1(\d{10})$` with `sbc5.contoso.biz`. In this case, when the user makes a call to `+1 425 XXX XX XX` or `+1 206 XXX XX XX`, the call is first routed to SBC `sbc1.contoso.biz` or `sbc2.contoso.biz`. If both sbc1 nor sbc2 are unavailable, the route with lower priority is tried (`sbc3.contoso.biz` and `sbc4.contoso.biz`). If none of the SBCs of a second route are available, the third route is tried. If sbc5 is also not available, the call is dropped. Also, if a user dials `+1 321 XXX XX XX`, the call goes to `sbc5.contoso.biz`, and it isn't available, the call is dropped.

+To update a customer-managed key version manually, you have three options:

+- Rotate the key and use a client ID of a managed identity.

+If you're using the key from a different key vault, verify the `identity` has the `get`, `wrap`, and `unwrap` permissions on that key vault.

+ --identity <client ID of a managed identity>

+- Rotate the key and use a user-assigned identity.

+Before you use the user-assigned identity, verify that the `get`, `wrap`, and `unwrap` permissions are assigned to it.

+ ```azurecli

+ az acr encryption rotate-key \

+ --name <registry-name> \

+ --key-encryption-key <new-key-id> \

+ --identity <id of user assigned identity>

+ ```

+

+Before you use the system-assigned identity, verify that the `get`, `wrap`, and `unwrap` permissions are assigned to it.

+ Title: Access a dev box with Task view

+description: Learn how to connect to your dev box using Task view in Windows for enhanced multitasking and organization.

+#customer intent: As a dev box user, I want to connect to my dev box with Task view, so that I can swap between my local machine and my dev box quickly.

+# Connect to a dev box by using task view

+This article shows you how to connect to your dev box by using Task view.

+## Prerequisites

+To complete the steps in this article, you must have:

+- Access to a dev box through the developer portal.

+- Windows App installed.

+ - If you don't have Windows App installed, see [Get started with Windows App to connect to devices and apps](/windows-app/get-started-connect-devices-desktops-apps?context=/azure/dev-box/context/context&pivots=dev-box)

+## Use Task view

+Task view is a feature in Windows 11 (and Windows 10) that enhances multitasking and organization. Task view lets you quickly switch between your local machine and your dev boxes. You access it by selecting the Task view button in the taskbar or using the Windows key + Tab keyboard shortcut. In Task view, you see a list of your dev boxes, and you can easily switch to a different one.

+### Add a dev box to Task view

+1. Open Windows App.

+1. For the dev box you want to configure, select **(...)** > **Add to Task view**.

+ :::image type="content" source="media/how-to-access-dev-box-task-view/windows-app-options-add-task-view.png" alt-text="Screenshot of the dev box tile options menu with Add to task view highlighted." lightbox="media/how-to-access-dev-box-task-view/windows-app-options-add-task-view.png":::

+

+1. On the taskbar, select Task view.

+ :::image type="content" source="media/how-to-access-dev-box-task-view/taskbar-task-view.png" alt-text="Screenshot of the task bar with Task view highlighted." lightbox="media/how-to-access-dev-box-task-view/taskbar-task-view.png":::

+1. To connect, select your dev box.

+ :::image type="content" source="media/how-to-access-dev-box-task-view/task-view-local.png" alt-text="Screenshot of Task view showing the available desktops with the dev box highlighted." lightbox="media/how-to-access-dev-box-task-view/task-view-local.png":::

+### Switch between machines

+1. To switch between your dev box and your local machine, on the taskbar, select Task view, and then select **local desktops**.

+ :::image type="content" source="media/how-to-access-dev-box-task-view/task-view-dev-box.png" alt-text="Screenshot of Task view showing the available desktops with Local desktops highlighted." lightbox="media/how-to-access-dev-box-task-view/task-view-dev-box.png":::

+

+### Remove dev box from Task view

+1. Open Windows App.

+1. For the dev box you want to configure, select **(...)** > **Remove from Task view**.

+

+ :::image type="content" source="media/how-to-access-dev-box-task-view/windows-app-options-remove-task-view.png" alt-text="Screenshot of Windows App devices page, with Remove from Task view highlighted." lightbox="media/how-to-access-dev-box-task-view/windows-app-options-remove-task-view.png":::

+

+The dev box is removed from Task view.

+### Troubleshooting Task view

+If you added a dev box to Task view but no longer have access to it, you might want to remove it from the Task view. Attempting to remove the stale dev box by selecting the [**Remove from Task view**](#remove-dev-box-from-task-view) option in Windows App might fail.

+There are two troubleshooting options for removing a stale dev box from Task view: first, uninstall, and reinstall Windows App.

+

+If the unwanted dev box still shows in Task view after reinstalling Windows App, you can remove it by deleting the registry entry for the stale dev box.

+To remove the registry entry:

+1. Open the Registry Editor app.

+1. Navigate to `Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RemoteSystemProviders\`

+1. Open the subfolder that has a title containing "Windows365".

+1. Delete the registry key that is titled as your stale dev box.

+1. Restart your local machine.

+## Related content

+- Learn how to [configure multiple monitors in Windows App](/windows-app/device-actions?branch=main&tabs=windows)

+- [Manage a dev box by using the developer portal](how-to-create-dev-boxes-developer-portal.md)

+# Add students to a lab in the Azure Education Hub with REST APIs

+# Create a lab in the Azure Education Hub with REST APIs

+# Delete a lab in the Azure Education Hub with REST APIs

+1. Enable Azure Monitor Agent Integration with Log Analytics and select your workspace (existing workspace when you're migrating from your previous image to newer image).

+1. Select Save once precondition steps are complete.

+### Enable Azure Monitor Agent logging for Spark cluster

+Azure HDInsight Spark clusters control AMA integration using a Spark configuration `spark.hdi.ama.enabled`, by default the value is set to false. This configuration controls whether the Spark specific logs will come up in the Log Analytics workspace. If you want to enable AMA in your Spark clusters and retrieve the Spark event logs in their LA workspaces, you need to perform an additional step to enable AMA for spark specific logs.

+The following steps describe how customers can enable the new Azure Monitor Agent logging for their spark workloads.

+1. Go to Ambari -> Spark Configs.

+1. Navigate to **Custom Spark defaults** and search for config `spark.hdi.ama.enabled`, the default value of this config will be false. Set this value as **true**.

+ :::image type="content" source="./media/azure-monitor-agent/enable-spark.png" alt-text="Screenshot showing how to enable Azure Monitor Agent logging for Spark cluster." border="true" lightbox="./media/azure-monitor-agent/enable-spark.png":::

+1. Click **save** and restart Spark services on all nodes.

+1. Access the tables in LA workspace.

+- [Create and manage an Azure IoT Central application from the Microsoft Cloud Solution Provider portal](https://partner.microsoft.com/cloud-solution-provider).

+- The subnet shouldn't have IPv6 enabled. Azure Load Testing doesn't support IPv6 enabled subnets. Learn more about [IPv6 for Azure Virtual Network].(/azure/virtual-network/ip-services/ipv6-overview)

+## Troubleshooting

+To troubleshoot issues in creating and running load tests against private endpoints, see [how to troubleshoot private endpoint tests](./troubleshoot-private-endpoint-tests.md).

+- Learn how to [troubleshoot private endpoint tests](./troubleshoot-private-endpoint-tests.md).

+description: Learn how create registries with the CLI, REST API, Azure portal, and Azure Machine Learning studio

+* Resources such as __compute__, __job__, and __endpoints__ are _transient entities that are workspace specific_. For example, an online endpoint has a scoring URI that is unique to a specific instance in a specific workspace. Similarly, a job runs for a known duration and generates logs and metrics each run.

+* Registries are meant to facilitate sharing of ML assets across teams within your organization across all workspaces. Choose a name that is reflective of the sharing scope. The name should help identify your group, division, or organization.

+* Registry name is unique with your organization (Microsoft Entra tenant). For example, you might prefix your team or organization name and avoid generic names.

+* Registry names can't be changed once created because they're used in IDs of models, environments, and components that are referenced in code.

+Registries enable sharing of assets across workspaces. To do so, a registry replicates content across multiple Azure regions. You need to define the list of regions that a registry supports when creating the registry. Create a list of all regions in which you have workspaces today and plan to add in near future. This list is a good set of regions to start with. When creating a registry, you define a primary region and a set of other regions. The primary region can't be changed after registry creation, but the other regions can be updated at a later point.

+1. Review the information you provided, and then select __Create__. You can track the progress of the operation in the Azure portal. Once the registry is successfully created, you can find it listed in the __Manage Registries__ tab.

+1. Select __Create__, and then select __Azure Machine Learning registry__. Enter the registry name, select the subscription, resource group, and primary region, then select __Next__.

+1. Select the more regions the registry must support, then select __Next__ until you arrive at the __Review + Create__ tab.

+curl -X PUT https://management.azure.com/subscriptions/<your-subscription-id>/resourceGroups/<your-resource-group>/providers/Microsoft.MachineLearningServices/registries/reg-from-rest?api-version=2024-04-01 -H "Authorization:Bearer <YOUR-ACCESS-TOKEN>" -H 'Content-Type: application/json' -d '

+Decide if you want to allow users to only use assets (models, environments, and components) from the registry or both use and create assets in the registry. Review [steps to assign a role](../role-based-access-control/role-assignments-steps.md) if you aren't familiar how to manage permissions using [Azure role-based access control](../role-based-access-control/overview.md).

+To let the user both read and create or delete assets, grant the following write permission in addition to the previous read permissions.

+To let users create, update, and delete registries, grant them the built-in __Contributor__ or __Owner__ role. If you don't want to use built-in roles, create a custom role with the following permissions, in addition to all the above permissions to read, create, and delete assets in registry.

+* [Learn how to share models, components, and environments across workspaces with registries](./how-to-share-models-pipelines-across-workspaces-with-registries.md)

+In this article, you learn about the available options for building a data ingestion pipeline with [Azure Data Factory](../../data-factory/introduction.md). This Azure Data Factory pipeline is used to ingest data for use with [Azure Machine Learning](../overview-what-is-azure-machine-learning.md). Data Factory allows you to easily extract, transform, and load (ETL) data. Once the data is transformed and loaded into storage, it can be used to train your machine learning models in Azure Machine Learning.

+ * Data Factory pipeline can invoke a [Durable Azure Function](../../azure-functions/durable/durable-functions-overview.md) that can implement a sophisticated data transformation flow

+1. To pass the location to Azure Machine Learning, the Data Factory pipeline calls an [Azure Machine Learning pipeline](../concept-ml-pipelines.md). When the Data Factory pipeline calls the Azure Machine Learning pipeline, the data location and job ID are sent as parameters.

+Next, create a dataset to reference the files you want to use in your machine learning task.

+The following table provides information for different debug options for pipelines. It isn't an exhaustive list, as other options exist besides just the Azure Machine Learning and Python ones shown here.

+>

+> You should rotate secrets such as the service principal password on a regular basis.

+Ensure you have the following information:

+- **Network Fabric Controller ID** - Network Fabric Controller and Cluster Manager have a 1:1 association. You need the resource ID of the Network Fabric Controller to be associated with the Cluster Manager.

+## Cluster Manager properties

+| Property Name | Description |

+| fabricControllerId | The reference to the Network Fabric Controller that is 1:1 with this Cluster Manager |

+| analyticsWorkspaceId | The Log Analytics workspace where logs that are relevant to the customer will be relayed. |

+| clusterVersions[] | The list of Cluster versions that the Cluster Manager supports. It is used as an input in the cluster clusterVersion property. |

+| provisioningState | The provisioning status of the latest operation on the Cluster Manager. One of: Succeeded, Failed, Canceled, Provisioning, Accepted, Updating |

+| detailedStatus | The detailed statuses that provide additional information about the status of the Cluster Manager. |

+| detailedStatusMessage | The descriptive message about the current detailed status. |

+## Cluster Manager Identity

+Starting with the 2024-06-01-preview API version, a customer can assign managed identity to a Cluster Manager. Both System-assigned and User-Assigned managed identities are supported.

+If a Cluster Manager is created with the User-assigned managed identity, a customer is required to provision access to that identity for the Nexus platform.

+Specifically, `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action` permission needs to be added to the User-assigned identity for `AFOI-NC-MGMT-PME-PROD` Microsoft Entra ID. It is a known limitation of the platform that will be addressed in the future.

+The role assignment can be done via the Azure portal:

+- Open Azure portal and locate User-assigned identity in question.

+ - If you expect multiple managed identities provisioned, the role can be added instead at the resource group or subscription level.

+- Under `Access control (IAM)`, click Add new role assignment

+- Select Role: `Managed Identity Operator`. See the [permissions](../role-based-access-control/built-in-roles/identity.md#managed-identity-operator) that the role provides.

+- Assign access to: User, group, or service principal

+- Select Member: `AFOI-NC-MGMT-PME-PROD` application

+- Review and assign

+### Create the Cluster Manager using Azure CLI:

+ - **--mi-system-assigned** - Enable System-assigned managed identity. Once added, the Identity can only be removed via the API call at this time.

+ - **--mi-user-assigned** - Space-separated resource IDs of the User-assigned managed identities to be added. Once added, the Identity can only be removed via the API call at this time.

+In order to create the cluster this way, you need to provide a template file (clusterManager.jsonc) and a parameter file (clusterManager.parameters.jsonc).

+ - **--mi-system-assigned** - Enable System-assigned managed identity. Once added, the Identity can only be removed via the API call at this time.

+ - **--mi-user-assigned** - Space-separated resource IDs of the User-assigned managed identities to be added. Once added, the Identity can only be removed via the API call at this time.

+### Update Cluster Manager Identities via APIs

+Cluster Manager managed identities can be assigned via CLI. The un-assignment of the identities can be done via API calls.

+Note, `<APIVersion>` is the API version 2024-06-01-preview or newer.

+- To remove all managed identities, execute:

+ ```azurecli

+ az rest --method PATCH --url /subscriptions/$SUB_ID/resourceGroups/$CLUSTER_MANAGER_RG/providers/Microsoft.NetworkCloud/clusterManagers/$CLUSTER_MANAGER_NAME?api-version=<APIVersion> --body "{\"identity\":{\"type\":\"None\"}}"

+ ```

+- If both User-assigned and System-assigned managed identities were added, the User-assigned can be removed by updating the `type` to `SystemAssigned`:

+ ```azurecli

+ az rest --method PATCH --url /subscriptions/$SUB_ID/resourceGroups/$CLUSTER_MANAGER_RG/providers/Microsoft.NetworkCloud/clusterManagers/$CLUSTER_MANAGER_NAME?api-version=<APIVersion> --body @~/uai-body.json

+ ```

+ The request body (uai-body.json) example:

+

+ ```azurecli

+ {

+ "identity": {

+ "type": "SystemAssigned"

+ }

+ }

+ ```

+- If both User-assigned and System-assigned managed identities were added, the System-assigned can be removed by updating the `type` to `UserAssigned`:

+ ```azurecli

+ az rest --method PATCH --url /subscriptions/$SUB_ID/resourceGroups/$CLUSTER_MANAGER_RG/providers/Microsoft.NetworkCloud/clusterManagers/$CLUSTER_MANAGER_NAME?api-version=<APIVersion> --body @~/uai-body.json

+ ```

+ The request body (uai-body.json) example:

+

+ ```azurecli

+ {

+ "identity": {

+ "type": "UserAssigned",

+ "userAssignedIdentities": {

+ "/subscriptions/$SUB_ID/resourceGroups/$UAI_RESOURCE_GROUP/providers/Microsoft.ManagedIdentity/userAssignedIdentities/$UAI_NAME": {}

+ }

+ }

+ }

+ ```

+- If multiple User-assigned managed identities were added, one of them can be removed by executing:

+ ```azurecli

+ az rest --method PATCH --url /subscriptions/$SUB_ID/resourceGroups/$CLUSTER_MANAGER_RG/providers/Microsoft.NetworkCloud/clusterManagers/$CLUSTER_MANAGER_NAME?api-version=<APIVersion> --body @~/uai-body.json

+ ```

+

+ The request body (uai-body.json) example:

+

+ ```azurecli

+ {

+ "identity": {

+ "type": "UserAssigned",

+ "userAssignedIdentities": {

+ "/subscriptions/$SUB_ID/resourceGroups/$UAI_RESOURCE_GROUP/providers/Microsoft.ManagedIdentity/userAssignedIdentities/$UAI_NAME": null

+ }

+ }

+ }

+ ```

+After you successfully created the Network Fabric Controller and the Cluster Manager, the next step is to create a [Network Fabric](./howto-configure-network-fabric.md).

+* Release Notes for Version 2.0.2777-132

+## Release 2.0.2777-132

+Document Revision 1.1

+### Release Summary

+Azure Operator Service Manager is a cloud orchestration service that enables automation of operator network-intensive workloads, and mission critical applications hosted on Azure Operator Nexus. Azure Operator Service Manager unifies infrastructure, software, and configuration management with a common model into a single interface, both based on trusted Azure industry standards. This August 7, 2024 Azure Operator Service Manager release includes updating the NFO version to 2.0.2777-132, the details of which are further outlined in the remainder of this document.

+### Release Details

+* Release Version: 2.0.2777-132

+* Release Date: August 7, 2024

+* Is NFO update required: YES

+### Release Installation

+This release can be installed with as an update on top of release 2.0.2763-119.

+### Issues Resolved in This Release

+#### Bugfix Related Updates

+The following bug fixes, or other defect resolutions, are delivered with this release, for either Network Function Operator (NFO) or resource provider (RP) components.

+* NFO - Adding taint tolerations to all NFO pods and scheduling them on system nodes. Daemonset pods will continue to run on all nodes of cluster).

+#### Security Related Updates

+* CVE - A total of five CVEs are addressed in this release.

+

+`Microsoft-ASR_UA_version_Windows_GA_date_release.exe` | Windows Server 2016 </br> Windows Server 2012 R2 </br> Windows Server 2012 </br> Windows Server 2008 R2 SP1 <br> Windows Server 2019 <br> Windows Server 2022

+1. Navigate to your storage account in the [Azure portal](https://portal.azure.com).

+1. In the service menu, under **Monitoring**, select **Metrics**.

+1. Under **Metric namespace**, select **File**.

+Now you can select a metric depending on what you want to monitor.

+1. Navigate to your storage account in the Azure portal.

+1. In the service menu, under **Data storage**, select **File shares**.

+1. Select **Create a resource** in the upper left-hand corner of the Azure portal.

+1. Under **Popular services**, select **Virtual machine**.

+1. Navigate to your storage account in the Azure portal.

+1. In the service menu, under **Monitoring**, select **Metrics**.

+1. Select **Scope** as your storage account name, **Metric Namespace** as "File", **Metric** as "Transactions", and **Aggregation** as "Sum".

+1. Select **Apply Splitting**.

+1. Select **Values** as "API Name". Select your desired **Limit** and **Sort**.

+1. Select your desired time period.