Azure Storage Blog articles

Oracle workloads do not move to the cloud on storage promises alone. They only move when performance is predictable, operational needs are familiar, and the platform gives teams the flexibility they need to grow without disruption or the need to redesign or remigrate a database architecture as requirements evolve.

That was the foundation of the Azure Architecture Center Oracle Database with Azure NetApp Files reference architecture, which documents how Azure NetApp Files provides high-performance NFS storage for Oracle Database on Azure virtual machines. The article remains an important reference for customers who want low latency, high throughput, flexible scaling, data protection, and cloning for demanding Oracle environments.

Since then, Azure NetApp Files has grown and evolved. New capabilities now make Oracle environments easier to size, deploy, protect, replicate, migrate, and clone on Azure. This article builds on the original Azure Architecture Center guidance and highlights what has changed: flexible service level capacity pools, application volume group for Oracle, availability-zone-aware volume placement, migration assistant, short-term clones, cool access, and expanded data protection options.

This article explains how Oracle on Azure Virtual Machines can benefit from using Azure NetApp Files volumes for primary database storage and provides an additional look at how Azure NetApp Files can complement Oracle AI Database@Azure as a backup target and a source for rapid, space-efficient database clones.

Co-authors:

Arnt de Gier, Azure NetApp Files Product Manager
Jeffrey Steiner, Principal Architect, NetApp

Azure NetApp Files Advancements Overview

The most important advances are not just about faster storage. They are about making Oracle environments easier to size, deploy, protect, migrate, replicate, and reuse across the full database lifecycle.

Key advancements include:

Flexible service level capacity pools
Capacity and throughput can now be tuned independently. Some databases are heavy on IOPS, while others are bandwidth-hungry. ANF capacity pools now help you avoid overprovisioning and align storage performance more closely with actual Oracle workload demand.
Application volume group for Oracle
Deployment of Oracle data, redo, archive, and backup volumes can be automated through a workflow that applies Oracle-aware layout and placement guidance.
Availability-zone-aware volume placement
Oracle VMs and Azure NetApp Files volumes can be aligned in the same availability zone to reduce avoidable latency and support more predictable performance.
Enhanced data protection and replication
Snapshots, backup, cross-zone replication, and cross-region replication give customers more options to protect Oracle data and design for business continuity.
Migration assistant
ONTAP-based volumes can be migrated to Azure NetApp Files using efficient block-level replication, preserving file structure, permissions, and existing snapshots while enabling incremental cutover planning.
Short-term clones
Snapshots can be turned into writable, space-efficient clones for test, development, reporting, validation, or troubleshooting without creating full physical copies.
Storage with cool access
Inactive data can be tiered automatically to optimize storage cost while keeping data accessible through the same Azure NetApp Files namespace. This helps manage the cost of Azure NetApp Files volumes used as backup targets for Oracle databases.
Oracle Database@Azure backup and clone integration - Azure NetApp Files can be used as a high-performance backup target and a source for rapid, space-efficient test and development refreshes using snapshots and short-term clones.

Together, these advancements shift the conversation from simply “Can Oracle run well on Azure NetApp Files?” to “How can Oracle environments on Azure become easier to operate, easier to protect, and easier to scale?” For customers, that means more deployment confidence, better cost control, faster refresh cycles, and a more practical path to modernizing Oracle workloads on Azure.

Azure NetApp Files Advancements in Detail

Flexible service level capacity pools

To match Azure NetApp Files storage to the real needs of each Oracle workload use Flexible service level to enable sizing and scaling of capacity and throughput independently of each other instead of sizing capacity and performance together like you do with the traditional service levels (standard, premium and ultra). For an Oracle DBA, this means you can allocate the storage capacity your database requires and then tune throughput separately for the expected I/O profile. You start with a baseline throughput of 128 MiB/s and can increase performance in small increments, up to five times the Ultra service level per provisioned 1 TiB. This makes it easier to support demanding databases without over-provisioning storage, and it can reduce costs by 10–40% by paying only for the capacity and performance the workload actually needs. As database demand changes, you can adjust the balance between capacity and throughput to keep performance aligned with current requirements.

Oracle Direct NFS

Oracle Direct NFS (dNFS) with Azure NetApp Files gives Oracle workloads a faster, cleaner path to primary storage. Because dNFS is built into Oracle Database, it lets Oracle access Azure NetApp Files through a database-optimized NFS client rather than relying only on the host operating system. For customers, that means more predictable performance, simpler operations, and a practical way to modernize Oracle environments without changing proven NFS-based operating models.

This pairing is especially useful for performance-sensitive Oracle databases, where low latency, scalable throughput, and operational consistency matter. Azure NetApp Files provides enterprise-grade shared storage with flexible capacity and throughput, while dNFS helps Oracle use that storage efficiently for production, reporting, migration, consolidation, and test/dev scenarios.

The result is a storage architecture that is easy to understand, easy to scale, and easy to protect. Customers can keep familiar Oracle-on-NFS practices while gaining the elasticity, data protection, replication, backup, and cloning capabilities of Azure NetApp Files.

Predictable Oracle performance with a database-optimized NFS access path.
Greater migration confidence for customers moving from on-premises NAS to Azure.
Simpler storage operations with Azure NetApp Files snapshots, backup, replication, and cloning.
Flexible scaling of capacity and throughput as Oracle workload demand changes.

Oracle Direct NFS provides a database-optimized I/O path from Oracle Database on Azure VMs to Azure NetApp Files primary NFS storage, while Azure NetApp Files adds scalable throughput and enterprise data services such as snapshots, backup, replication, and cloning.

Application volume group for Oracle

Application volume group (AVG) for Oracle is a feature offered through Azure NetApp Files, designed to simplify the process of deploying all required volumes to install and run an Oracle database on Azure VMs (IaaS).

With just one workflow, you can provision volumes for data, redo, archive, and backup. This consolidation streamlines volume management, enforces best practices, and supports easy adjustments for size and throughput after deployment, all while keeping the flexibility of Azure NetApp Files volumes.

Application volume group for Oracle was recently enhanced with new functionality:

Availability zone volume placement: volumes should be placed in the same availability zone as the Oracle virtual machines, minimizing network latency by shortening the data path.
Data protection volume group creation: The same automated process allows you to create a data protection volume group with matching layout and naming for business continuity and disaster recovery in a secondary availability zone or region.
Standard network features: always utilize standard network features for best performance.
Enhanced performance: by deploying data and log volumes on separate storage endpoints, IOs are processed independently, preventing data read slowdowns during high-priority log writes. Application volume group will deploy multiple data volumes across different storage endpoints for large-scale workloads, using sizing inputs and affinity rules to optimize performance.

Availability zone volume placement

The efficiency of application volume group for Oracle is enhanced by aligning Azure NetApp Files volumes with the application VMs in the same availability zone. This alignment is crucial for meeting strict latency requirements, ensuring your Oracle applications run smoothly and efficiently.

Using compute in one zone and storage in another across a cross-zone data path (right side) introduces unnecessary latency and is easily avoided using availability zone aware volume placement and placing compute and storage in the same zone over a short data path (left side).

High availability

Azure availability zones are distinct locations within a region. By deploying Oracle volumes and application VMs in the same zone - and replicating data and redo logs to a secondary zone or region using cross-zone replication or cross-region replication you minimize the risk data loss during a disaster. Azure NetApp Files’ built-in replication can offload the replication of data files and volumes freeing up compute resources for transaction processing and deliver an RPO as low as 10 minutes. The replica can also be activated for a near-zero RTO. If an RPO and RTO all the way down to zero are required, you can use Oracle Data Guard to create a fully operational hot standby copy of your database.

Standard network features

The use of standard network features is recommended for all new implementations of Azure NetApp Files volumes. Basic network features is no longer supported for new deployments and will be phased out completely. Volumes using basic network features can be migrated to standard network features without interruption.

Simplified deployment

The automated application volume group deployment workflow accelerates and simplifies volume deployment, significantly reducing the risk of human error and resulting in a more reliable setup.

Optimal volume placement

Application volume group considers the underlying physical resources, applying affinity and anti-affinity rules to find the best locations for performance-critical volumes. This process ensures that your deployment achieves optimal performance; this is not possible with manual, one-by-one volume provisioning. Application volume group also splits data and log volumes across different storage endpoints to maximize performance and reduce contention.

Scalability and flexibility

Volume capacity and throughput can be easily resized before, during, or after deployment, allowing you to adapt your Oracle environment to changing needs without sacrificing availability or performance. Volume resizing and throughput adjustments can be done without interruption to the storage service and while the database is online.

Integrated data protection

Volumes deployed by application volume group are compatible with Azure NetApp Files data protection solutions, such as efficient, application-consistent snapshots and backup offloading. Data management tools like AzAcSnap, NetApp SnapCenter® software or other 3^rd-party data protection tools compatible with Azure NetApp Files are required to further ensure the consistency and safety of your Oracle data.

Using application volume group for Oracle

To use application volume groups, you need an Azure NetApp Files capacity pool that matches or exceeds the recommendations from the sizing exercise, and to be configured with Manual QoS. This setting allows application volume group to independently set volume throughput and capacity, making the most efficient use of the capacity pool since no overprovisioning will be required in this concept. The application volume group workflow calculates minimum required size and throughput based on your inputs and offers recommendations for optional backup volumes. After a successful pre-check it validates your inputs against the selected capacity pool, you simply click to deploy and after a few minutes your volumes are ready to mount onto your Oracle application VMs.

VM IO throttling

Not covered in this blog, but what may add to a more friendly TCO is the fact that network IO is not throttled by Azure VMs like managed disk is. This directly results in larger storage bandwidth when used with network connected storage like Azure NetApp Files. You may achieve the same or better performance with a smaller VM SKU, and this may have positive consequences for licensing as well.
Oracle on Azure specialists are available to help you with sizing Azure NetApp Files capacity pools, volumes and VM SKUs using your AWR reports.

Automatic Storage Management (ASM)

Oracle’s Automatic Storage Management is primarily designed to stripe data across multiple devices. This helps improve performance, plus devices can be added and removed nondisruptively, which makes capacity management easier.

Azure NetApp Files has the same capabilities, making ASM generally unnecessary. With Azure NetApp Files, IO is striped across multiple devices as the physical storage layer, and volumes can be resized on the fly and even throughput can be adjusted on the fly.

If you require ASM, for example, if you have existing procedures and scripts that depend on ASM, it is still fully supported with Azure NetApp Files and features like dynamic performance management still apply. You also get additional benefits. For example, you can create instant, space-efficient snapshots of your ASM diskgroups, and those snapshots can be offloaded to Azure NetApp Files backup for long term retention and protection against unlikely complete volume loss or corruption.

Migration assistant

Migration assistant allows for efficient migration of on-premises NetApp ONTAP® based storage volumes to Azure NetApp Files volumes.

This enables optimized volume migration to Azure NetApp Files volumes using NetApp SnapMirror® technology, providing:

Optimized volume migration with encryption and compression in transit to save network bandwidth
Complete database volumes are migrated, including the complete file structure with permissions and previously taken snapshots
Dry-run options are offered to perform intermediate testing of the migrated data volumes
Flexible cut-over planning with block-level incremental final transfer

Short-term clones

Azure NetApp Files short-term clones help reduce costs by allowing space-efficient provisioning of volume clones from snapshots for test/dev and other purposes.

The space efficiency stems from smart block manipulation in Azure NetApp Files, where the short-term clone uses the same blocks as the originating volume except for any changes made. Changed and new data blocks are written to a separate space in the short-term clone volume. Short-term clones are available almost immediately after creation and only take space in the capacity pool for any anticipated changes to be written to the clones. This saves capacity pool allocation space and cost. After 32 days short-term clones need to be either removed or converted to full independent clones.
Use short-term clones to rapidly create copies of production databases for analysis and test and development at minimal cost impact.

Storage with cool access

Leveraging Azure NetApp Files storage with cool access enables customers to optimize their storage strategies, reduce expenses, and efficiently manage their data lifecycle. Cool access automatically moves unused data to the Azure storage account without any changes required to user behavior or applications. This flexibility and efficiency make it a valuable option for a wide range of use cases, including backup and archival, data lakes, and compliance storage.

Sizing Your Volume Deployment for Oracle

Sizing tools are available to help determine the required volume configuration for Oracle. When migrating databases to Azure, generate Automatic Workload Repository (AWR) reports to analyze your current storage activity. AWR reports should be created at times when the database is at its highest load and run for a few hours. These reports allow the migration team to project suitable Azure NetApp Files volumes.
You can also upload multiple AWR reports to online sizing utilities such as the Atroposs and obtain recommendations for Azure NetApp Files capacity pool and volume layout using the Atroposs Azure NetApp Files Oracle Volumes TCO Estimator module which uses the measurements from the AWR reports provided. Since the database size is not included in the AWR reports, you need to enter the database size(s) manually. You can collect database sizes using this SQL script. Both volume capacity and throughput can be changed any time after deployment, providing flexibility and cost-efficiency. Please visit aka.ms/anftools for additional Azure NetApp Files estimator and sizing tools.

Using Azure NetApp Files as backup target and test/dev for Oracle AI Database@Azure

For Oracle AI Database@Azure deployments, Azure NetApp Files volumes can add value as high-performance backup targets that also become practical data sources for rapid test and development refreshes.

If all you need is a simple, easy-to-manage high-throughput RMAN backup target, Azure NetApp Files can be used as a simple, yet high-performance shared filesystem. You can also take snapshots of your RMAN backups for additional protection and replicate those backups to other regions.

If you really want to reduce your backup window and slash the capacity required for RMAN backups, you can combine RMAN image and incremental backups with Azure NetApp Files snapshots. The result is an incremental-forever backup strategy, but with a library of full-sized RMAN backups available within the snapshots. Backup windows shrink, and the only extra space required for each backup you retain is for the data that changed between backups.

You can also treat backups as more than just a recovery asset. Backup volumes can be used to capture recent, application-consistent copies of production data and make those copies available for temporary downstream use.

There are two options. First, you can set up a standby database (using Oracle Data Guard or as a traditional standby) to a right-sized VM and then create snapshot-based backups of that replica. That delivers backups as well as a low/zero RPO/RTO DR capability, but it can also be used for cloning. NetApp’s SnapCenter can automate the process from start-to-finish using those snapshots.

That is done through short-term clones. When a backup lands on an Azure NetApp Files volume, a snapshot of that backup set can be used to create a short-term clone. The short-term clone is writable, available quickly, and space-efficient because it references the existing snapshot data and only consumes additional capacity for changed blocks. This makes it well suited for feeding fresh production-like data to test, development, reporting, validation, or troubleshooting environments without creating full physical copies of large Oracle data sets.

Accelerates refresh cycles by making recent backup data available to non-production environments in minutes rather than through lengthy copy or restore processes.
Reduces storage consumption and cost by avoiding full-size duplicate database copies for short-lived test and development needs.
Limits production impact because clone creation is based on backup or snapshot data rather than direct activity against the active production database volumes.
Improves developer and QA productivity by providing realistic, current data sets for functional testing, upgrade validation, performance troubleshooting, and release rehearsal.

After the test/dev activity is complete, the short-term clone can be deleted before it ages out or converted to a regular volume if it needs to be retained longer. This approach turns the Oracle AI Database@Azure backup target into an active data lifecycle asset: protecting the database while also enabling faster, lower-cost access to fresh data for innovation and operational readiness.

That’s not the only route to leveraging short-term clones. If you’re using Azure NetApp Files with the incremental-forever backup strategy, each of those snapshots contains a fully consistent set of datafiles. You can also clone them and bring them up as an operational database using your own automation tools.

Summary

Consider the use of Azure NetApp Files volumes for your Oracle databases for flexibility, cost-efficiency, data protection and high-availability. You may achieve the same or better database performance even when using smaller VM SKUs in Azure. Snapshots provide extremely fast and efficient primary data protection from which complete databases can be restored very quickly. Use RMAN or other integrated backup applications to orchestrate the creation of snapshots for application consistency and easy operation.

Application volume group for Oracle provides a robust solution for deploying multiple Azure NetApp Files volumes for use with Oracle, optimizing performance, availability, and management of your Oracle databases. Leveraging availability zone placement ensures that your Oracle environment is resilient and ready for modern business challenges. Use application volume group for Oracle also for provisioning data protection volumes in an alternate zone or region and use cross-zone and cross-region replication to offload data and log volume replication from the application VMs for higher efficiency and better performance.

For efficient migration of on-premises ONTAP-based volumes to Azure NetApp Files, use migration assistant.

When using Oracle AI Database@Azure consider sending backup data to Azure NetApp Files volumes to allow space-efficient volume cloning and feeding test/dev operations with fresh data from production.

Consult Oracle on Azure specialists for sizing Azure NetApp Files volumes and VM SKUs for your Oracle deployment on IaaS in Azure.

Learn more

Announcing General Availability of Client-Side Data Integrity Protections in Azure Blob Storage

wmarkley — Mon, 29 Jun 2026 19:03:37 GMT

We are excited to announce the General Availability of client-side data integrity in Azure Blob Storage. Blob Storage has long supported integrity validation, starting with MD5 as part of the original HTTP standards and adding CRC64-NVME support in 2019. Today, CRC64-NVME is now integrated into the latest Azure Blob SDKs for .NET, C++, and JavaScript, extending Azure’s data integrity protections all the way into client applications.

Azure has had a longstanding commitment to provide the world’s most secure and reliable cloud storage platform. By extending data integrity protections into client applications, customers can end-to-end verify the data they read and write to Blob Storage is fully intact byte-for-byte from their application to Azure physical storage media using CRC64-NVME checksums – without the need to deploy and manage additional tools.

Azure’s Commitment to Data Integrity

Azure Blob Storage considers the durability and integrity of the data stored by customers as a fundamental promise of a cloud object storage provider. The Blob Storage platform was designed to prevent, detect, and repair any data integrity issues, along with making data durable and available at up to sixteen 9s with GRS. From the beginning, Blob Storage has stored checksums alongside every data fragment and continuously verifies them with background jobs, ensuring the bytes we durably store remain exactly the bytes we received —for every data replica (LRS/ZRS/GRS/GZRS).

Extending integrity to your client applications

Today, Azure Blob Storage is extending that protection into your client applications for end-to-end integrity. When enabled by customers, with CRC64-NVME transactional verification built into the latest Blob SDKs, every byte uploaded or downloaded has a CRC64-NVME checksum generated and that checksum is validated end-to-end. This protects against silent corruption that can occur within client-side code, on faulty client hardware, or in proxies and other services that sit between your application and Blob Storage. With CRC64-NVME validation enabled, the SDK computes and sends a checksum over the data and the service independently verifies it before acknowledging the write; the same happens in reverse on read. For multi-part reads/writes, individual checksums are reconciled against a whole-object checksum to catch any corruption within the client library itself. Every byte is now integrity-checked from the moment it enters the SDK, through the Blob Storage service and your storage account, and back again.

Benefits of CRC64-NVME

Microsoft has always considered 64 bit-checksums a requirement at cloud scale, with the CRC64-NVME polynomial protecting exabytes of customer data in Blob Storage from accidental data corruption. Microsoft has invested and shared high-performance implementations of our CRC64-NVME implementation that other cloud providers and industry participants have adopted as the default for data integrity use cases.

The Cyclic Redundancy Check (CRC) algorithm was originally designed for detecting bit corruption in data transit over network protocols like Ethernet, so it has relatively minimal CPU usage. The CRC64-NVME polynomial variant used for Blob Storage data integrity takes advantage of hardware acceleration present in modern x86 and ARM CPUs to further reduce CPU usage. Further performance gains are achieved by composing CRC checksums - meaning if you have the CRC of two chunks of data, you can combine them to get the CRC of the whole data, without needing to re-read the data. CRC64-NVME also provides strong reliability: a collision probability of a random bit error is 1 in 2^64, or 1 in 18 quintillion.

Performance

Performance is paramount in Azure Blob and great care was taken to implement the CRC64-NVME end to end integrity performantly. The latest version of the Blob SDK implements data integrity through the Structured Message Body REST API, which boosts our efficiency. Structured message bodies effectively allow the Blob client libraries to process the data, compute the CRC64-NVME checksum, and compose/unpack the HTTP request all in one flow, rather than processing the same data two or three times.

There are no restrictions on the size of your data for end-to-end data integrity to work. The latest version of the Blob SDKs using the structured message body implementation can handle any size of data to perform the end-to-end Data Integrity, unlike our previous MD5 version.

Throughput and CPU utilization can vary between using CRC64-NVME, MD5, and no validation. Customers can weigh the benefits of end-to-end integrity with the performance implications that might be right for their application.

Usage

Requires upgrading to the latest SDK versions.

Upload data to Blob with end-to-end data integrity (.NET):

BlobUploadOptions options = new BlobUploadOptions { TransferValidation = new UploadTransferValidationOptions { ChecksumAlgorithm = StorageChecksumAlgorithm.StorageCrc64 } }; Response<BlobContentInfo> response = blobClient.Upload(upStream, options);

Download data to Blob with end-to-end data integrity (.NET):

BlobDownloadToOptions options = new BlobDownloadToOptions { TransferValidation = new DownloadTransferValidationOptions { ChecksumAlgorithm = StorageChecksumAlgorithm.StorageCrc64 } }; Response response = blobClient.DownloadTo(downStream, options);

Upload and Download on all client operations to Blob with end-to-end data integrity (.NET):

BlobClientOptions options = new BlobClientOptions { TransferValidation = { Upload = { ChecksumAlgorithm = StorageChecksumAlgorithm.StorageCrc64 }, Download = { ChecksumAlgorithm = StorageChecksumAlgorithm.StorageCrc64 } }, }; BlobServiceClient blobServiceClient = new BlobServiceClient(serviceUri, new DefaultAzureCredential(), options);

Availability

SDK	Minimum Version
.NET	12.28.0
Java	Coming soon
Python	Coming soon
JavaScript	12.32.0
Go	Coming soon
C++	12.17.0

Comparison to MD5

MD5 is a cryptographic hashing algorithm that has historically been used for verifying integrity of data. Content-MD5 was one of the original HTTP headers for this purpose. While Blob Storage has supported HTTP headers for integrity including MD5, it’s less preferred than CRC64-NVME for data integrity due to its lower reliability in detection, high collision rate, inability for hardware acceleration, and higher computational cost. Recently, MD5 has even been disallowed by many security frameworks (e.g. FIPS) due to its lack of cryptographic security.

With MD5, Blob Storage has only been able to verify the data integrity of each partitioned HTTP request/response with MD5, not the entire blob. Additionally, for reading blobs with MD5 validation there is a 4MiB size limit on the data in HTTP responses, which can significantly increase the number of HTTP requests required to read data. In both reading and writing blobs, the SDKs require buffering or re-reading the data to compute MD5 in addition to assembling the HTTP request and unpacking the HTTP response.

With the latest implementation of CRC64-NVME, Azure Blob client libraries can verify data integrity on both the entire data and each HTTP request/response, can do so with any size of partitions on reading or writing data, and does so in only one pass over the data.

To migrate from MD5 to CRC64-NVME, simply change your ChecksumAlgorithm:

-ChecksumAlgorithm = StorageChecksumAlgorithm.MD5 +ChecksumAlgorithm = StorageChecksumAlgorithm.StorageCrc64

Next Steps

To begin using end-to-end Data Integrity with CRC64-NVME, upgrade to the latest SDK version of your preferred language and check out our developer guides and examples:

Boost performance with NFS nconnect on Azure NetApp Files datastores for Azure VMware Solution

GeertVanTeylingen — Wed, 24 Jun 2026 07:16:04 GMT

Reading the numbers: what the Azure VMware Solution datastore data shows

What this unlocks for Azure VMware Solution with Azure NetApp Files

Introduction

For the most demanding workloads, storage is rarely the limiting factor on Azure NetApp Files. More often, it is the path to storage. NFS has long used a single TCP connection per datastore per host, and while that one stream is dependable, it quietly caps how much I/O a host can drive to a datastore. The usual workaround was to spread the workload across more datastores, or more hosts, so additional connections could share the load. It worked but it meant running and managing more datastores than the workload itself ever needed.

The nconnect mount option removes that cap by letting a single NFS mount use multiple TCP connections. VMware introduced it in vSphere 8.0 Update 2, and on‑premises NetApp customers adopted it quickly to get more out of their high-speed networks and storage. Now that same option is supported on Azure VMware Solution with Azure NetApp Files. For details on the nconnect mount option, see the Azure NetApp Files Linux NFS mount options documentation.

This matters because it changes what you can expect from a single datastore with higher throughput, lower latency under concurrency, and a simpler design all without leaving the managed Azure VMware Solution platform.

Co-authors

Rich Crofford, Azure NetApp Files Product Manager
Pravinkumar Jeya Kumar, Senior Program Manager Azure Dedicated

What is nconnect

The nconnect option is a client-side NFS capability that allows a single NFS mount to use multiple TCP connections. Instead of sending all Azure VMware Solution datastore traffic through one stream, the client distributes it across several parallel connections driving more traffic at a lower overall latency.

Figure 1. With nconnect=4, each ESXi host opens four parallel TCP connections to a single Azure NetApp Files datastore.

ESXi introduced multiple TCP connections for a single NFSv3 datastore in vSphere 8.0 Update 2, where the capability became generally available. The number of connections is configurable per datastore and adjustable at runtime, and the default stays at a single connection, so turning it on is a deliberate choice the administrator makes.

On Azure VMware Solution, a setting of nconnect=4 is now supported with Azure NetApp Files. You can mount an Azure NetApp Files datastore with four parallel connections per host, bringing the same parallelism and performance that is proven on premises into the fully managed Azure VMware Solution. . The nconnect=4 capability is supported on both Azure VMware Solution Gen 1 and Gen 2 private clouds, so you get the same capability regardless of which generation you run.

Why it matters

The payoff shows up in the two dimensions workloads care about most.

Throughput. Four connections carry more data in parallel than one. By spreading I/O across multiple TCP streams, a single datastore connection attains more bandwidth from the same host and makes fuller use of the available network, and thus storage throughput. On the Azure NetApp Files side, those connections are serviced in parallel by the storage service, so the extra client streams translate into real aggregate throughput instead of queuing a single connection.

Latency under concurrency. This is the part that is easy to overlook. When an NFS mount is established, the storage service tracks a connection that supports a defined number of concurrent, in‑flight operations. When a busy workload exceeds that number on a single connection, the service applies flow control until operations complete and resources free up. Each pause is brief often only for microseconds but across millions of operations those pauses add up and surface as higher overall latency. Adding connections multiplies the number of operations that can be in flight at once, which reduces queuing and keeps response times consistent when the workload gets heavy. This is not just a theory. Azure NetApp Files testing with Linux NFS clients shows that adding parallel connections measurably lowers latency under concurrent load. The nconnect option brings that same mechanism to each Azure VMware Solution host.

For applications that generate sustained I/O, more throughput with higher concurrency and lower latency is exactly what is needed to run predictably.

How it works

With nconnect=4, each Azure VMware Solution ESXi host mounts an Azure NetApp Files datastore over four parallel TCP connections. Storage traffic is processed concurrently across those connections, raising aggregate throughput and supporting a higher level of I/O concurrency than a single connection model ever could.

Adoption is straightforward and non‑disruptive, for both new and existing datastores. New Azure NetApp Files datastores can be created with nconnect enabled from day one, and the option can also be applied to datastores you already run. Either way, no changes are required to your virtual machines or applications, they simply benefit from the added I/O parallelism. A single datastore can then support performance that previously took several, simplifying the environment while preserving the scalability demanding workloads rely on. Because nconnect is configured per datastore, each datastore’s connection count can be set independently to match its workload.

⚠️ Important

Four connections per datastore is a deliberate balance. It delivers a meaningful jump in parallelism while keeping the storage design clean and easy to operate. Azure VMware Solution supports up to 256 NFS connections per host, so with nconnect=4, each host can access up to 64 datastores per SDDC. Keep the connection count consistent across all hosts in a cluster so that performance and operations such as vMotion behave predictably.

Reading the numbers: what the Azure VMware Solution datastore data shows

Azure VMware Solution specific nconnect benchmarks are still being run, but we do not have to wait to understand the impact. The most useful context already exists in two places; the published Azure NetApp Files datastore guidance for Azure VMware Solution, and years of Azure NetApp Files nconnect experience on Azure virtual machines. The single‑host scaling data comparing one datastore to multiple datastores is especially telling, because it shows exactly what happens when a host can spread load across more network flows.

What the published Azure VMware Solution data already tells us. With a single datastore, each Azure VMware Solution host connects over a fixed number of network flows, which became a bottleneck for the most demanding workloads. Moving from one datastore to two, and then to four, scaled out performance by giving the host more parallel network flows, as the figure below shows. That gain came purely from adding datastore level connections not from any change inside the guest virtual machines.

Figure 2. Scaling from 1 to 16 datastores on a single host lifts 8K IOPS from roughly 156,000 to 389,000 driven entirely by more parallel datastore connections.

Why that matters for nconnect. In those published single host results, moving from one datastore to four improved throughput because the host had more parallel datastore connections available. nconnect=4 changes the equation it lets a single datastore mount use four parallel TCP connections from each ESXi host. In other words, the same performance principle that previously favored multiple datastores can now be applied within a single datastore mount. That is why nconnect=4 is so significant for Azure VMware Solution with Azure NetApp Files as it helps one datastore deliver much more of the performance that used to require several.

Figure 3. Averaged across read/write mixes, scaling datastores delivers up to 397% (8KB random) and 279% (64KB sequential) relative to a single datastore the same scaling nconnect=4 brings within one datastore.

Read together, the data makes the point plainly more parallel datastore connections increase performance, and nconnect=4 brings that same scaling model to a single Azure NetApp Files datastore. These figures illustrate the scaling pattern your real‑world results will vary with the specific workload running against the datastore.

What this unlocks for Azure VMware Solution with Azure NetApp Files

Azure NetApp Files has always been the storage service of choice for the most demanding enterprise workloads databases, and high‑performance computing with no application changes required. For some of those workloads on Azure VMware Solution, the limiting factor was never the storage itself. It was the single‑connection ceiling between the host and the datastore, and nconnect=4 removes that ceiling.

Customers already running Azure VMware Solution with Azure NetApp Files can easily make use of this new feature. Because nconnect is configured per datastore, you can apply it to the datastores that are already connected and see the benefit immediately with no migration and configuration changes to your virtual machines.

Two common situations where I/O previously funneled through a single TCP flow will benefit right away: maximizing throughput for single VM with VMDKs maps to one datastore and increasing throughput for many VMs on a single datastore. In both cases, nconnect=4 relieves the bottleneck and lets the existing datastore absorb far more load which also spares you from spinning up extra datastores just to chase performance.

That is what makes Azure VMware Solution and Azure NetApp Files so compelling together. You get the enterprise grade performance of Azure NetApp Files, the familiar VMware operating model of Azure VMware Solution, and now the parallel connection scaling that high-performance workloads depend on all on a managed cloud platform.

It is worth saying plainly: with Azure VMware Solution and Azure NetApp Files, you do not need dedicated infrastructure to get bare‑metal performance. That applies to virtualized Oracle and SQL Server, to large analytics estates, and to any storage heavy application that once justified a dedicated platform. The performance is right there in the Azure VMware Solution and Azure NetApp Files platform you already run.

Use cases

The nconnect=4 option is especially valuable for Azure VMware Solution workloads that need more throughput, steadier latency under concurrency, or a simpler storage design. These use cases show where parallel TCP connections to a single Azure NetApp Files datastore make the biggest difference.

Use case	How nconnect helps
Databases on Azure VMware Solution plus Azure NetApp Files	Databases live and die on throughput and latency, and they generate exactly the kind of sustained, concurrent I/O that benefits most from parallel connections. With nconnect=4, Oracle, SQL Server, and similar engines run consistently on a single high‑performing datastore without sharding data files across many datastores to chase performance.
Storage-heavy and high-performance workloads	Analytics platforms, file‑intensive applications, and large virtual desktop estates all gain from higher aggregate IOPS and steadier latency per datastore. Backup and bulk‑data windows, where I/O spikes hard for a defined period, are a natural fit for the extra parallelism.
Datacenter exits and migrations	Teams retiring physical datacenters want to move VMware estates to the cloud with minimal redesign. Azure VMware Solution lets you bring workloads over as they are, and Azure NetApp Files with nconnect=4 supplies the storage performance that once justified keeping high‑demand workloads on dedicated infrastructure. You retire the hardware and still clear the performance bar.

Across all of these, Azure VMware Solution backed by Azure NetApp Files delivers the performance that once required specialized or dedicated platforms while keeping the storage design simpler.

Conclusion

The nconnect option lets each Azure VMware Solution ESXi host open four parallel TCP connections to each Azure NetApp Files datastore, increasing throughput and lowering effective latency under load without adding datastores or hosts. The capability has been proven in VMware for some time, and the performance case is already backed by existing benchmark data, including Azure NetApp Files nconnect scaling on Azure virtual machines and the published one datastore versus four datastore scaling results for Azure VMware Solution.

For the workloads Azure NetApp Files is known to serve well; this was the missing piece. Databases, analytics, and other storage heavy applications now have the parallel connection scaling they need on a managed VMware platform. With Azure VMware Solution and Azure NetApp Files, you do not need specialized infrastructure to get bare‑metal performance; the performance is already there, and now it scales.

Next steps

Review your datastore design. Identify the workloads most likely to benefit from more parallelism, especially databases, analytics platforms, and other storage‑intensive applications that currently span multiple datastores mainly for performance.
Validate platform prerequisites. Confirm that your Azure VMware Solution environment and Azure NetApp Files datastore deployment follows the documented connectivity and performance best practices for attached datastores, including the guidance for your generation of private cloud.
Test nconnect on the right datastores first. Start with the datastores that show the clearest signs of throughput pressure or latency under concurrency, then compare performance and operational simplicity before expanding more broadly.
Standardize across the cluster. Apply a consistent configuration across hosts for any datastore that uses nconnect, so performance characteristics and mobility operations stay predictable.
Use the published guidance to plan rollout. Review the Azure VMware Solution attach guidance, performance considerations, and benchmark documentation to decide where nconnect can help you reduce datastore sprawl while preserving the performance your workloads require.

For Azure VMware Solution customers using Azure NetApp Files, nconnect is a practical way to simplify storage design while improving throughput and latency for demanding workloads. It helps you get more from the datastores you already use, with less need to spread workloads across additional datastores just to add parallelism.

Learn more

Bringing Enterprise File Data to Users with Azure NetApp Files, Microsoft Foundry, and M365 Copilot

GeertVanTeylingen — Mon, 15 Jun 2026 07:37:24 GMT

Introduction

Why the user experience layer matters in enterprise AI

Microsoft Foundry: Orchestrating enterprise AI agents

The Copilot agent as the enterprise user experience

End‑to‑end user query flow

Why this pattern works for regulated and complex environments

Extending Copilot beyond SharePoint‑centric scenarios

From storage to knowledge to action

Key takeaway

Put the architecture into practice

Learn more

Introduction

In Part 1, From Enterprise File Storage to an AI-Ready Data Foundation using Azure NetApp Files and OneLake, we established a zero‑copy data foundation that makes enterprise file data AI‑addressable using Azure NetApp Files and Microsoft OneLake, without migration, duplication, or workflow disruption.

In Part 2, From File Data to AI‑Powered Knowledge Pipelines using Azure NetApp Files object REST API, we showed how that foundation is activated through a knowledge pipeline using Azure AI Search and Azure OpenAI, transforming unstructured files into a living, queryable knowledge system grounded in Retrieval‑Augmented Generation (RAG).

In this final part, we focus on the user experience: how this architecture is safely and effectively surfaced to end users through enterprise AI agents, including Copilot, where employees already work.

Co-authors:

Thomas Willingham, Azure NetApp Files Product Manager
Sean Luce, Azure NetApp Files Product Manager

Why the user experience layer matters in enterprise AI

Enterprise AI adoption rarely fails because models are insufficient. It fails when users are asked to change how they work, learn new tools, or trust opaque answers.

For knowledge‑centric scenarios, success depends on three things:

Users interact with AI inside their existing workflows.
Answers are grounded in authorized enterprise data.
Responses are traceable, and auditable.

Microsoft 365 Copilot provides the ideal natural language experience for this layer. However, Copilot itself does not “understand files.” It relies on external knowledge sources and well‑defined grounding mechanisms to retrieve and synthesize information safely.

This is where the Copilot Agent completes the architecture, with Microsoft Foundry providing the orchestration layer behind it.

Microsoft Foundry: Orchestrating enterprise AI agents

Before enterprise knowledge is exposed to end users through enterprise AI agents such as Copilot, it must first be assembled, grounded, and governed as an AI capability. This is the role of Microsoft Foundry.

Microsoft Foundry is the control plane for building and governing enterprise AI agents. It provides the environment where enterprise AI agents are created and connected to authoritative knowledge sources. It orchestrates how Azure AI Search, Azure OpenAI models, and enterprise data sources, including Azure NetApp Files surfaced through OneLake, work together to deliver an accurate, grounded response.

Rather than embedding intelligence directly inside Copilot, Foundry acts as the control plane for enterprise AI. It defines:

Which knowledge sources an agent can access,
How retrieval and grounding are enforced,
How models are constrained to retrieved enterprise content, ensuring responses remain grounded, explainable, and auditable.

This separation ensures that Copilot remains the user experience, while Foundry governs how enterprise AI agents reason over data, securely and predictably.

Together, this user experience layer enables secure, seamless access to enterprise data for AI, unlocking real business value through governed, traceable Copilot experiences.

The Copilot agent as the enterprise user experience

The Copilot agent is built and governed within Microsoft Foundry, but users interact with it through Copilot.

At a high level, the agent performs three critical functions:

Receives natural language questions from users inside M365 experiences such as Teams or Copilot Chat,
Queries the Azure AI Search index built over enterprise file data referenced through OneLake,
Generates grounded responses using Azure OpenAI, restricted to retrieved content and enriched with source citations.

This separation of responsibilities is deliberate. Copilot does not read file storage directly, nor does it reason over raw documents. Instead, it queries a curated, indexed knowledge source designed specifically for enterprise RAG scenarios.

The result is a user experience that feels conversational but behaves predictably.

End‑to‑end user query flow

When a user asks a question in Copilot – such as:

“What is our incident escalation procedure for data breaches?”

The interaction follows a controlled, enterprise‑safe flow:

User submits a question in Copilot,
The Copilot Agent forwards the query to Azure AI Search,
Relevant document chunks are retrieved using semantic vector search,
Azure OpenAI synthesizes a response using only the retrieved content,
Source filenames are included in the response for transparency.

At no point does the model infer information from outside the enterprise dataset or hallucinate answers based on its general training.

This is not a chatbot layered on top of file storage. It is a governed retrieval and reasoning pipeline surfaced through a familiar, conversational experience.

Why this pattern works for regulated and complex environments

This user experience model is especially powerful for industries where trust, traceability, and compliance are non‑negotiable.

Because answers are always grounded in specific source files:

Legal teams can verify interpretations against contract language,
Security teams can audit responses back to official runbooks,
Compliance teams can validate that policies, not assumptions, are being cited.

Just as importantly, data never leaves its system of record:

Files remain governed and secured in Azure NetApp Files,
Access controls continue to be enforced at the storage layer,
OneLake provides virtualization, not duplication,
AI services operate on indexed representations, not copied datasets.

This preserves existing governance models while extending their reach into AI‑driven experiences.

Extending Copilot beyond SharePoint‑centric scenarios

Most Copilot examples focus on collaboration content stored in SharePoint or OneDrive. These are valid and important scenarios.

However, enterprise knowledge does not live exclusively in collaborative repositories.

Large organizations depend on:

Network file systems containing decades of operational knowledge,
Hybrid environments where SMB and NFS are the primary interfaces,
High‑performance storage platforms that cannot be re‑platformed.

By combining Azure NetApp Files, OneLake, a RAG‑based knowledge pipeline, and Copilot, this architecture extends Copilot’s reach to the realities of the enterprise data estate, without forcing that estate to change.

From storage to knowledge to action

Taken together, the three layers form a cohesive architecture:

Part 1: Data Foundation
Azure NetApp Files + OneLake make enterprise file data AI‑addressable without migration or duplication.
Part 2: Knowledge Pipeline
Azure AI Search + Azure OpenAI transform files into a living knowledge system using RAG.
Part 3: AI Orchestration & User Experience
Microsoft Foundry orchestrates enterprise AI agents, and Copilot provides a natural, trusted way for users to ask questions and receive grounded answers.

This is not a single-use solution. It is a repeatable architecture pattern for enabling secure, seamless access to enterprise data for AI, unlocking real business value safely, predictably, and at scale.

Key takeaway

The real promise of enterprise AI is not replacing systems of record but making them intelligible.

With this architecture, Azure NetApp Files becomes more than high performance storage.

It becomes the foundation of an AI‑ready data estate, delivering grounded insights inside Copilot, without compromising performance, security, or trust.

Together, these three parts form a complete architecture for extending AI to enterprise file data – bridging the gap between systems of record and AI-powered user experiences.

Put the architecture into practice

This three‑part series outlines a repeatable pattern for bringing AI to enterprise file data; without migration, duplication, workflow disruption, or governance compromise.

To go deeper:

Review the reference architecture described in this series and map it to your environment,
Identify candidate file‑based knowledge scenarios (security, compliance, operations),
Engage your data, storage, and AI teams, with us at askANF@microsoft.com to apply this pattern using Azure NetApp Files, Microsoft OneLake, and Copilot.

Enterprise AI succeeds when systems of record become systems of intelligence.

Learn more

From Enterprise File Storage to an AI-Ready Data Foundation using Azure NetApp Files and OneLake

GeertVanTeylingen — Mon, 15 Jun 2026 07:37:21 GMT

Introduction

Why the data foundation matters

Expanding beyond collaboration-centric data

The zero‑copy data foundation pattern

Why OneLake changes the model

What this enables

Key takeaway

Learn more

Introduction

Enterprise AI is advancing rapidly, but many organizations are discovering a common challenge: their most valuable data is not accessible to the systems they want to use.

While collaboration platforms and modern data services are designed for AI integration, the majority of enterprise knowledge still resides in file systems, powering critical applications, operational workflows, and long-standing systems of record. These environments were built for performance, reliability, and scale, not for AI-driven discovery or reasoning.

This creates a fundamental gap. Organizations have the data they need to power AI, but that data often remains outside the reach of modern AI platforms.

In this blog series, we explore how to close that gap without rewriting workflows, migrating data, or disrupting existing systems.

Co-authors:

Thomas Willingham, Azure NetApp Files Product Manager
Sean Luce, Azure NetApp Files Product Manager

Why the data foundation matters

As organizations accelerate their adoption of AI, a familiar challenge keeps emerging: AI is only as effective as the data it can access. While models and tools continue to advance rapidly, many enterprises are constrained by data foundations that were never designed for AI workloads.

The issue is not a lack of data. In fact, most organizations already store their most valuable institutional knowledge on enterprise file systems:

Engineering specifications and design documents
Legal contracts and compliance records
Policies and procedures
Technical runbooks
Historical reports and archives

For many enterprises, this content lives on high‑performance file storage such as Azure NetApp Files, accessed through long‑standing SMB and NFS workflows. The data is fast, reliable, and trusted, yet largely invisible to AI.

Files are rich in information, but they are fundamentally passive. Users must already know where to look, and AI systems cannot reason over data they cannot access. This disconnect between where enterprise content lives and where AI knowledge can operate is now one of the biggest blockers to scalable AI adoption.

Expanding beyond collaboration-centric data

Many AI scenarios today focus on collaboration-centric data that is:

Cloud‑native
Stored in SharePoint or OneDrive
Well suited for small to medium‑sized repositories

This is an important and valuable class of data. But it represents only part of the enterprise reality. Enterprise AI requires extending beyond collaboration data to include systems of record, where the majority of institutional knowledge resides.

Most large organizations also rely on:

Large NAS estates measured in tens or hundreds of terabytes, and often millions of files
Hybrid and on‑premises environments
Long‑standing SMB/NFS workflows that cannot be easily re‑platformed or migrated

These environments are not failures of SharePoint, they serve different needs. File systems remain the system of record for many regulated, performance‑sensitive, and document‑heavy workloads.

The challenge has been extending AI, and data platforms, to this class of enterprise file data without forcing migration, duplication, or workflow change.

This is the gap that Azure NetApp Files and Microsoft OneLake fill together.

The zero‑copy data foundation pattern

To unlock AI across enterprise file data, we need a different foundation, one that respects existing systems of record while making data accessible to modern AI services.

This solution introduces a zero‑copy, zero‑migration data foundation built on three key components:

Component	Role
Azure NetApp Files	System of record for unstructured enterprise files (SMB/NFS)
Object REST API	Provides object access (S3‑compatible) to file data
Microsoft OneLake	Unified data layer that exposes data without duplicating it

Files continue to be created, updated, and managed on Azure NetApp Files exactly as they are today.

The Azure NetApp Files object REST API provides object‑based access to that data, enabling modern analytics and AI platforms to work directly with existing file datasets without copying, moving, or restructuring them.

This same zero-copy pattern is already used to unlock advanced analytics and AI scenarios with services such as Azure Databricks and Microsoft Fabric, validating its suitability for large‑scale enterprise AI workloads.

Why OneLake changes the model

Microsoft OneLake is often described as a “single data lake for the entire organization,” but its most important capability in this architecture is what it does not do.

OneLake does not ingest Azure NetApp Files data.

Instead, it:

creates shortcuts as virtual pointers to external data,
preserves ownership, permissions, and access patterns,
avoids storage duplication and ETL pipelines,
keeps Azure NetApp Files as the authoritative system of record.

This shortcut‑based model allows OneLake to unify data across clouds, platforms, and on‑premises environments while maintaining a single logical namespace.

From an AI perspective, this is critical. It means enterprise file data can be discovered, indexed, and reasoned over by downstream AI services without breaking compliance boundaries, duplicating storage, or introducing synchronization risk.

What this enables

With Azure NetApp Files connected to OneLake through the object REST API:

enterprise file data becomes AI‑addressable,
existing SMB/NFS workflows remain unchanged,
data stays governed, secured, and owned by the original platform,
AI systems gain visibility into previously inaccessible knowledge.

This architecture does not replace SharePoint‑based scenarios. Instead, it expands AI and data analytics scenarios across a broader, more representative enterprise data estate.

Key takeaway

Azure NetApp Files is the high-performance, intelligent, and cyber-resilient foundation for enterprise file data, powering AI with enterprise application file data wherever it lives.

By combining Azure NetApp Files, the object REST API, and Microsoft OneLake, organizations establish a unified, zero‑copy foundation that brings enterprise file data into scope for modern AI systems.

With the data foundation in place, the next step is turning that data into usable knowledge.

This AI‑ready data foundation enables higher‑level AI capabilities and agents that are governed and surfaced to users in later layers of the architecture.

In Part 2, From File Data to AI‑Powered Knowledge Pipelines using Azure NetApp Files object REST API we’ll explore how this foundation enables a knowledge pipeline using Azure AI Search and Azure OpenAI to support Retrieval-Augmented Generation (RAG).

Learn more

From File Data to AI‑Powered Knowledge Pipelines using Azure NetApp Files object REST API

GeertVanTeylingen — Mon, 15 Jun 2026 07:37:13 GMT

Introduction

Why a knowledge pipeline is required

Retrieval‑augmented generation (RAG) at enterprise scale

Knowledge pipeline architecture overview

Step 1: Indexing enterprise file content without moving it

Step 2: Creating semantic meaning with embeddings

Step 3: Retrieval at query time

Step 4: Grounded answer generation

Why this architecture matters

Preparing for the Copilot experience

Key takeaway

Learn more

Introduction

In Part 1, From Enterprise File Storage to an AI-Ready Data Foundation using Azure NetApp Files and OneLake, we established the foundation: how Azure NetApp Files and Microsoft OneLake together transform enterprise file storage into an AI‑addressable data layer, without data migration, duplication, or workflow disruption.

But an AI‑ready foundation alone does not make data usable by AI.

⚠️Important

Industry research shows that many AI initiatives fail before they ever reach production. According to IDC, fewer than half (44%) of AI pilot projects advance out of experimentation, with the primary limiting factors not being model capability but the quality of business data and the timeliness of access to it.

IDC, *AI-Ready Data Storage Infrastructure: Definition, Taxonomy, Ontology, and Future Outlook*, IDC #US53709325, August 2025

To turn enterprise file data into something large language models can reason over, search, and cite, we need a knowledge pipeline, one that can understand unstructured content at scale, retrieve the right information at the right time, and ground AI responses in authoritative source data.

This is where Retrieval‑Augmented Generation (RAG) enters the architecture.

Co-authors:

Thomas Willingham, Azure NetApp Files Product Manager
Sean Luce, Azure NetApp Files Product Manager

Why a knowledge pipeline is required

Large language models are powerful, but they have a fundamental limitation in enterprise settings: they do not have inherent access to your organization’s internal data.

Even when data is accessible through a unified foundation like OneLake, these models cannot simply “read” files on demand. Enterprise AI systems require a mechanism to:

Discover relevant content across large document sets,
Understand the semantic meaning of unstructured files,
Retrieve only the most relevant excerpts for a given question,
Generate responses grounded in real documents, with traceability.

This is exactly what a knowledge pipeline provides.

Rather than pushing all enterprise data into a model, the pipeline keeps data in place, builds a continuously updated semantic index, and retrieves relevant information at query time. The AI model then generates answers based only on retrieved content, not on guesswork or generalized training data.

Retrieval‑augmented generation (RAG) at enterprise scale

At a high level, Retrieval‑Augmented Generation combines two functions:

Retrieval – finding the most relevant pieces of enterprise content
Generation – using a language model to synthesize an answer from those retrieved sources

For enterprise file data, this pattern is especially important:

File repositories are large, dynamic, and constantly changing
Content is unstructured and varies widely in format and quality
Accuracy, traceability, and compliance are mandatory, not optional

RAG ensures that AI responses are grounded in current, authorized enterprise content, not inferred, outdated, or hallucinated knowledge.

Knowledge pipeline architecture overview

In this solution, the knowledge pipeline sits on top of the OneLake data foundation and connects enterprise file data to downstream AI experiences through three core services:

Component	Role in the Knowledge Pipeline
Microsoft OneLake	Provides unified, zero‑copy access to enterprise file data
Azure AI Search	Indexes, chunks, and retrieves relevant content using keyword + vector search
Azure OpenAI	Generates semantic embeddings and synthesizes grounded responses

Together, these services transform passive file data into an actively queryable enterprise knowledge system.

Step 1: Indexing enterprise file content without moving it

The pipeline begins with Azure AI Search indexing content exposed through OneLake.

Because OneLake references Azure NetApp Files volumes via shortcuts, Azure AI Search can read files directly, without copying them into another storage system. Files remain:

Stored on Azure NetApp Files,
In-place available via existing SMB / NFS workflows,
Governed by their original security and ownership model.

Azure AI Search performs three key functions during indexing:

Content extraction – reading text from supported document formats,
Chunking – splitting large documents into semantically meaningful segments,
Metadata capture – preserving filenames and contextual information.

This process creates a searchable representation of enterprise file content while leaving the original data untouched. As files change, this index is refreshed through re-indexing processes that regenerate embeddings for updated content.

Step 2: Creating semantic meaning with embeddings

Keyword search alone is insufficient for natural language queries.

To understand meaning, not just matching words, the pipeline uses vector embeddings generated by Azure OpenAI.

During indexing:

Each document chunk is converted into a high‑dimensional vector that represents its semantic meaning,
These embeddings are stored in Azure AI Search alongside the textual index.

This enables semantic similarity search, allowing the system to retrieve relevant content even when a user’s question does not match document wording exactly.

For example:

A query about “incident response procedures” can retrieve documents titled “Security Escalation Playbook.”
Policy intent matters more than literal phrasing.

This is critical for natural language AI scenarios, where users ask questions conversationally rather than searching by filename or keyword.

Step 3: Retrieval at query time

When a user submits a question, for example through an AI agent, the knowledge pipeline activates in real time.

At query time:

The question is converted into an embedding,
Azure AI Search performs vector similarity search against the indexed content,
The most relevant document chunks are retrieved,
Source metadata (including filenames) is preserved.

Only the retrieved content is passed to the language model for response generation.

Example: How retrieval works in practice

A user asks: “What is our incident escalation procedure for data breaches?”

The system retrieves relevant sections from documents such as a “Security Escalation Playbook” stored on Azure NetApp Files, and passes only those excerpts to the language model to generate a grounded response with source citations included.

This design ensures:

AI responses are based on actual enterprise documents,
The scope of information is tightly controlled,
Results remain explainable and auditable.

Step 4: Grounded answer generation

Finally, Azure OpenAI synthesizes a natural language response using only the retrieved content.

The model does not infer beyond the supplied sources. Instead, it:

Summarizes relevant information,
Resolves ambiguities across multiple documents,
Produces an answer grounded in enterprise data.

Because filenames are preserved throughout the pipeline, downstream interfaces, such as an AI agent, require responses to include explicit source citations.

This is especially important in regulated and compliance‑driven environments, where users must be able to verify where an answer came from.

Why this architecture matters

The knowledge pipeline solves a problem that generic AI integrations cannot:

No data movement – files remain on Azure NetApp Files,
No re‑platforming – existing workflows continue unchanged,
No trust gap – every answer can be traced back to a real document.

Instead of forcing enterprises to restructure their data to fit AI tools, this architecture adapts AI to how enterprises store and manage knowledge.

The result is a living knowledge system:

Updated as content changes through re-indexing processes that refresh the semantic index,
Scalable across millions of documents,
Ready to support multiple AI experiences, not just a single user-facing scenario.

Preparing for the Copilot experience

At this point, the pipeline has done the hard work:

Enterprise file data is accessible through OneLake,
Semantically indexed and searchable,
Ready for controlled, grounded AI access.

What remains is exposing this capability to end users; safely, consistently, and within the tools they already use.

This knowledge pipeline provides the governed, retrieval‑ready foundation that enterprise AI agents can consume and orchestrate, before being surfaced to end users through downstream user experiences.

Key takeaway

Enterprise file data becomes a living, queryable knowledge system, without moving, copying, or restructuring a single file, eliminating the operational “copy-tax” associated with data duplication.

By combining Microsoft OneLake, Azure AI Search, and Azure OpenAI, the knowledge pipeline transforms the zero‑copy data foundation into an actively searchable enterprise resource. Every AI response is grounded in real documents, traceable to its source, and scoped to authorized content.

With the knowledge pipeline in place, the next step is surfacing this capability to end users in a secure and intuitive way.

In Part 3, Bringing Enterprise File Data to Users with Microsoft Foundry, M365 Copilot and Azure NetApp Files, we’ll explore how this pipeline is exposed through enterprise AI agents and user experiences, and governed by Microsoft Foundry, enabling natural language interaction with enterprise file data, complete with citations, governance, and enterprise controls.

Learn more

File share migrations simplified with Azure Copilot Migration Agent

madhurinrao — Wed, 03 Jun 2026 12:28:05 GMT

Building on our earlier announcement of discovery and assessment support for SMB and NFS file shares in Azure Migrate, we are extending the experience to support end-to-end file share migrations within the same workflow. With Azure Copilot Migration Agent, customers can move from discovery and assessment to migration through a single guided experience in Azure Migrate. By bringing planning and execution together, the agent helps organizations streamline migration activity, reduce handoffs, and maintain continuity across stages.

Overview

Since the release of file share discovery and assessment in Azure Migrate earlier this year, customers have indicated that while visibility into their file share estate improved, the transition to execution remained fragmented. In many cases, teams still had to work across separate workflows for inventory, readiness planning, and migration, increasing operational friction and the risk of losing context between stages.

Azure Copilot Migration Agent helps address this gap by bringing discovery, assessment, planning, and execution into a single guided journey. Azure Migrate provides visibility and recommendations, while Azure Storage Mover supports execution in a connected, agentic experience. The result is a more consistent migration path that reduces complexity, preserves context, and helps teams move file shares to Azure with greater operational confidence.

Invoking the Azure Migration Copilot Agent for on-premises data migration

Customer Value

This update streamlines the migration journey by connecting each stage of the process and reducing operational overhead. Natural language guidance helps teams start and manage migration activities much faster, often in hours or days instead of weeks.

The experience supports the following scenarios:

End-to-end discovery, assessment, and migration for on-premises Windows and Linux file shares (SMB) to Azure Files.
Discovery and assessment for on-premises Windows and Linux file shares (NFS).
Data transfers from one Azure Blob container to another container.

Design principles

The experience preserves continuity across inventory, readiness insights, and execution planning, enables direct movement of validated shares when heavyweight orchestration is unnecessary, maintains approval and sequencing controls, and supports the file and object movement patterns commonly required in production environments.

Getting Started with Storage Migration in Azure Copilot Migration Agent (ACMA)

Launch Azure Migrate: Sign-in to the Azure portal, open Azure Migrate.
From the Getting Started page, open Azure Copilot Migration Agent, then select or create an Azure Migrate project.
Describe the migration in natural language. The agent detects storage migration intent and assists with storage migration planning and routes execution requests seamlessly.

Examples scenarios and prompts

Migration of on-premises Windows Server data over SMB to Azure Files

setting up key vault after source is confirmed

create target if not already present

review configuration before creation of migration jobrun migration job and check status

2. Prompt: Help me transfer data from one Azure blob container to another blob container

Call to action

Storage integrated capability is launching in Limited Preview at Microsoft Build. Sign up for the Preview here.

For questions, contact storagemigrationcopilotagent@microsoft.com.

Learn More

Simpler, scalable file share management in Azure - now generally available

VincentLiu — Tue, 02 Jun 2026 19:07:28 GMT

Linux workloads in Azure are scaling faster than ever, powering everything from container platforms, analytics pipelines, SAP environments to line-of-business applications. As these workloads grow, infrastructure teams commonly run into challenges with scale, cost management, complexity and compliance. IT organizations need more granular control over management and isolation boundaries for file shares independent of storage accounts, to prevent multiple application teams sharing the same capacity pools, limits, and configuration surface across different storage services. Infrastructure administrators seek operational simplicity with managing access control, policy and networking isolation for file shares, so application teams can focus on business logic and development agility.

We are announcing the general availability of a new service management experience for premium SSD file shares (NFS) which allows each file share to be created, secured, scaled, and billed independently, without being tied to a storage account.

Key benefits include:

Familiar and intuitive file share management: Aligns user experience with on-premises NAS and file server paradigms, improving usability compared to the classic model.
Infrastructure-as-Code: Define naming, capacity, IOPS, networking, tags, and security in Bicep or ARM templates for simplified automation with your favorite DevOps tools.
Scale to match the workload: Support for up to 10,000 file shares per subscription per region, with 2.5x faster file share provisioning experience.
Share-level security and networking: Network restrictions, snapshots, and encryption scoped to the individual share, making isolation boundaries match workload boundaries.
Per-share cost visibility: Billing meters emit under the file share resource, teams can crossbill accurately, track per-workload costs, and improve chargeback without workarounds.

Independent performance, security, and billing per share

Combined with the provisioned v2 model, each file share is independently provisioned with its own storage, IOPS, and throughput. This allows organizations to align file shares directly to application or tenant boundaries, rather than grouping them under shared infrastructure constructs.

For multi-tenant SaaS platforms, this enables a natural one-to-one mapping between tenants and file shares. Each tenant operates within its own performance envelope, allowing steady workloads and bursty workloads to scale independently without contention. This reduces the need for capacity planning tradeoffs or overprovisioning to accommodate peak usage across tenants.

This isolation extends beyond performance; each file share carries its own encryption in transit settings, RBAC, policy, and network boundaries. For example, production tenants can be isolated with dedicated private endpoints, while development environments can operate under more flexible configurations. These boundaries align directly with application design, making systems easier to reason about and manage at scale.

Finally, treating each file share as its own resource simplifies cost management. Teams can tag and track usage at the workload or tenant level, enabling more accurate chargeback and better visibility into resource consumption. This makes it easier to understand how individual workloads contribute to overall spending without introducing additional tracking mechanisms.

Start easy, scale big

Cloud-native Linux applications often scale dynamically, so the underlying storage platform must provide resources quickly and support higher scale limits to keep pace with workload demand and enable teams to quickly provision infrastructure and keep pace of development. The new file share experience supports up to 10,000 file shares per subscription per region, making it practical to use a dedicated share for each application, environment, or tenant without running into platform limits. It also provides faster provisioning, with time to first share 2.5x times faster than classic file shares, so teams can spend less time waiting on infrastructure and more time building, testing, and shipping.

“Provisioning is fast and integrates seamlessly with Linux environments through NFS.” - Siam Commercial Bank

Data protection with snapshots

Linux workloads using shared file storage require robust data protection. With the new service management experience, customers can continue to leverage point-in-time incremental snapshots with up to 200 snapshots per share. You can also now edit metadata on individual snapshots, making it easier to organize and identify recovery points. Whether you need short term restore points or need to retain data for compliance requirements, snapshots provide an easy and cost-effective recovery mechanism.

Get started today

The new file share experience is available for NFS 4.1 file shares on SSD storage, using the provisioned v2 billing model with LRS and ZRS options. Whether the deployment model is ARM templates, Bicep, MCP server, or custom CI/CD pipelines, file shares are scriptable, repeatable, and automatable through the same tooling used for the rest of Azure infrastructure. Explore our documentation for step-by-step guidance.

We're continuously enhancing the new file share experience with the goal of achieving full feature parity while delivering improved scale and performance limits. We would love to hear your feedback, please fill out the survey to share your thoughts.

Learn more

For questions or feedback, contact us at azurefiles@microsoft.com.

Secure, Modern Access to Azure Files on macOS with MS Entra ID

grace_kim — Tue, 02 Jun 2026 18:55:03 GMT

Enterprises, large and small, rely on Azure Files for secure, scalable, and cost-efficient file storage. Modern workflows today span devices, platforms, and geographies; seamless, and secure access to shared data across every endpoint is critical to keeping teams productive and collaborative. With the growing demand for access across every device, Azure Files now extends secure access to macOS with Entra ID authentication, supporting design, creative, and AI teams where they work.

Today, we are announcing the Public Preview of MS Entra ID based authentication for Azure Files on macOS. Whether you are running creative production pipelines, design workflows, or AI workloads, macOS users can now access Azure file shares securely, meeting Microsoft Entra ID enterprise governance standards automatically and seamlessly, with no credential prompts, no storage account keys, and no complexity.

Key benefits

Enhanced Security posture: MacOS users can now sign in to their device and open shared files in Finder with no credential prompts and no storage account keys. Microsoft Entra ID governs access, conditional access policies, MFA requirements, and MS Entra ID governance applies automatically with AES-256 encryption.

Reduced operational overhead: IT admins no longer need to manage storage account key distribution/rotation. Provisioning and deprovisioning access is handled through standard Entra ID group membership.

No dependency on Active Directory: Organizations moving away from on-premises infrastructure, including Active Directory, can now give MacOS users full access to Azure file shares using cloud-based identities in MS Entra ID, with no domain controller required. MacOS users get full parity with the traditional Windows SMB share experience.

Identity Based Access model: User authentication is enforced with Kerberos and share-level access is enforced through Azure RBAC. File and folder permissions are controlled through NTFS ACLs, giving organizations precise, layered control.

Enabling AI-Driven Workloads: SMB shares on macOS enables AI teams to seamlessly access and share large datasets, fueling faster experimentation and streamlining developer and AI-generated workflows.

Partnership with Apple

Azure Files support for macOS is built in close collaboration with Apple macOS SMB engineering team. The integration works with Apple’s Platform SSO and the Microsoft Enterprise SSO plug-in, via MDM platforms such as Microsoft Intune. This allows macOS devices to authenticate through Microsoft Entra ID with single sign-in. We are committed to continuing this partnership to ensure Mac users in enterprise environments have a first-class experience accessing cloud services.

Powering Diverse Workloads across Design, Developer and Education Enterprises

Secure SMB access for creative workloads

Creative workflows on macOS have historically required workarounds to reach centralized cloud storage, often meaning local copies, consumer file sharing tools, or storage account keys distributed to individuals. Azure Files gives creative teams direct access to shared project libraries and production files from Finder, with no syncing or local copies needed. For IT, setup is simple: assign the right RBAC role on the share, add users to an Entra group, and access is ready. No keys to distribute and no deep storage expertise required.

"Secure access for our macOS users is a gamechanger for our creative teams. The ability to mount directly and access shared files securely — without keys, without workarounds — changes how we work. It’s how modern enterprise file access should feel." -Peter Day, Senior Engineer, The Marketing Store

SMB shares streamline developer and AI-generated build workflows

MacOS developers rely on local tools like Visual Studio Code, GitHub copilot, or fast iteration, but build artifacts, logs, and AI-generated outputs often end up fragmented across machines and pipelines.

With Azure Files, teams can use SMB shares as a centralized workspace for build outputs and shared assets. Mac build systems can write directly to a mounted share, making artifacts immediately accessible across developers, pipelines, and AI agents. DevOps teams gain a secure, identity-based storage layer using RBAC and Microsoft Entra, without managing keys or custom storage solutions.

Enable collaboration across mixed platform environments

Mac users should not be a special case. Azure Files gives MacOS users the same governed, identity-based access to shared storage that Windows users have always had. Access is provisioned through Entra ID, enforced through RBAC, and managed without a separate workflow, separate keys, or separate infrastructure. For large organizations running mixed-OS environments, this means a single, consistent access model tied to the user and not a device – the user can seamlessly access the SMB share across their Windows and Mac devices.

“By supporting Kerberos authentication for Azure Files on Mac devices, Microsoft delivers secure, consistent access for organizations operating mixed-OS environments. It addresses a long-standing enterprise gap by extending centrally governed identity controls to all users, regardless of device—helping organizations simplify access management and maintain trust at scale.” -Preetham G.K., CDL, Accenture

Modernize Infrastructure and secure access for Educational Institutions

Institutions standardizing on macOS have faced a hard tradeoff: maintain costly on-premises infrastructure at every site or accept that MacOS users fall back on personal drives and consumer file sharing. Neither is acceptable at scale. Azure Files removes the tradeoff. Students, faculty, and staff access shared repositories and course materials directly from an SMB share over Finder using their Entra ID credentials. Access management can be controlled through group membership, with no per-site infrastructure and no manual credential management.

Get started with Azure Files Entra Kerberos authentication for macOS

Start leveraging secure, identity-based file access on macOS today at no added cost. Explore our documentation for step-by-step guidance. Whether you are onboarding new Mac users or modernizing an existing deployment, this feature gives your organization a simple path to identity management for Azure Files on macOS. Make your Mac workloads ready for the future!

For any questions, please reach out to the team at azurefiles@microsoft.com.

From Scale to Breakthrough: Azure NetApp Files Sets a New Cloud Benchmark for EDA Performance

GeertVanTeylingen — Fri, 22 May 2026 15:00:00 GMT

Introduction

New benchmark proof with large volume breakthrough mode

What is Azure NetApp Files large volume breakthrough mode?

Explore the latest Azure NetApp Files SPECstorage® 2020 publications

Results that Speak for Themselves

Single large volume breakthrough mode

Large volume breakthrough mode at scale

Performance that Scales with Your Design Cycles

From large volume scale… to breakthrough mode scale

What Storage Performance Means For EDA Velocity

Learn more

Introduction

In his latest Azure NetApp Files for EDA workloads: From revolution to breakthrough at scale post Aung Oo – Vice President, Azure Storage – explored a fundamental shift in Electronic Design Automation (EDA) infrastructure: cloud storage no longer needs to tradeoff between scale and predictable performance. It unpacked the historical compromises EDA teams made to balance amongst extreme concurrently, shared datasets and the strict latency requirements and how Azure NetApp Files was architected to solve these challenges with consistent, linear scaling behavior.

Just as importantly, that post presented independently validated SPECstorage® Solution 2020 benchmarks showing that Azure NetApp Files can support real-world EDA workloads at scale while sustaining sub-millisecond latency – shifting cloud storage from a bottleneck in modern chip design pipelines to an enabler.

This blog builds on that foundation.

With the introduction of Azure NetApp Files large volume breakthrough mode, the conversation shifts from proving scalable performance to redefining its upper limits. Where earlier results established predictable scaling, breakthrough mode pushes the concurrency envelope further – allowing thousands of parallel jobs to share storage while maintaining consistent latency under sustained load.

The result is a new level of cloud performance for EDA: not just solving scale challenges, but delivering a true performance breakthrough, now validated by the latest SPECstorage® Solution 2020 benchmark publications.

In this blog, we take a closer look at two new SPECstorage® Solution 2020 EDA_BLENDED benchmark submissions that validate the impact of large volume breakthrough mode, both for a single volume configuration and at scale, and place those results in real-world context.

Co-authors:

Ron Hogue, Sr. Program Manager
Ranga Sankar, Azure NetApp Files Product Manager
Andy Chan, Azure NetApp Files HPC/EDA Principal Product Manager
George Strother, Senior Cloud Solutions Architect, NetApp
Cass Morgenstern, Director of Engineering - Office the CTO, NetApp

New benchmark proof with large volume breakthrough mode

Following the same industry‑standard SPECstorage® Solution 2020 EDA_BLENDED workload methodology used in our prior large volume submissions, the newly published results evaluate:

Azure NetApp Files large volume breakthrough mode
Azure NetApp Files large volume breakthrough mode scale

Together, these independently audited benchmark publications validate how breakthrough mode enable Azure NetApp Files large volumes to sustain higher concurrency levels while maintaining the consistent, sub‑millisecond response times that modern chip design pipelines depend on.

What is Azure NetApp Files large volume breakthrough mode?

Azure NetApp Files large volume breakthrough mode unlocks a new level of scale and performance for the most demanding EDA workloads. By combining massive concurrency with consistent sub-millisecond latency, it helps modern chip design pipelines move faster, scale further, and operate without compromise.

For a quick overview, check out the Quick Byte video:

Explore the latest Azure NetApp Files SPECstorage® 2020 publications

These two newly released benchmark publications showcase the exceptional performance and scalability of Azure NetApp Files’ large volume breakthrough mode for EDA workloads.

Azure NetApp Files large volume breakthrough mode:
https://www.spec.org/storage2020/results/res2026q2/storage2020-20260227-00147.html

Azure NetApp Files large volume breakthrough mode scale:
https://www.spec.org/storage2020/results/res2026q2/storage2020-20260227-00148.html

Results that Speak for Themselves

This chapter presents the latest benchmark results for Azure NetApp Files in full detail, highlighting the significant performance advantages enabled by large volume breakthrough mode. Through both single and scaled large volume configurations, these results demonstrate the ability to support demanding EDA workloads with exceptional throughput and consistent low latency. The findings underscore Azure NetApp Files’ capability to meet the rigorous requirements of modern chip design pipelines, ensuring reliability and efficiency at every scale.

Single large volume breakthrough mode

The architecture shown in the diagram was specifically designed to generate the load necessary for producing the benchmark results discussed in this section.

The result:

The Azure NetApp Files large volume breakthrough mode configuration reached 2,880 SPECstorage® Solution 2020 EDA_BLENDED JOBS with an overall response time of 0.51 ms.

A single Azure NetApp Files large volume breakthrough mode delivered 20,910 MB/s (19,941 MiB/s) of throughput and 1,296,040 operations per second at peak.

Throughout the iterations, sub-millisecond latency was observed with latency only breaching 1 ms at the very peak.

This level of performance demonstrates how a single large volume deployment can sustain thousands of concurrent EDA workloads – while preserving the latency profile required for simulation, synthesis, and verification tasks.

Large volume breakthrough mode at scale

The architecture shown in the diagram was specifically designed to generate the load necessary for producing the benchmark results discussed in this section. For resource availability reasons, six volumes were distributed across multiple Azure regions and availability zones, though this is not a requirement. Deployments can use any number of volumes, and regional / zonal distribution is optional – only necessary when targeting specific availability or resilience goals.

The result:

The Azure NetApp Files large volume breakthrough mode scale configuration reached 17,280 SPECstorage® Solution 2020 EDA_BLENDED JOBS with an overall response time of 0.60 ms.

At this scale, the aggregate throughput was 125,474 MB/s (119,661 MiB/s), with 7,776,147 operations per second on the benchmark.

Again, throughout the iterations, sub-millisecond latency was observed with latency only breaching 1 ms at the peak.

Even at six times the workload scale, latency remains consistently sub‑millisecond – enabling highly parallel EDA workflows to scale without introducing storage‑induced bottlenecks.

The multi-region/zone configuration was selected for resource availability reasons. This configuration is not a requirement, and deployments can use any number of volumes – by no means limited to six. A configuration can scale to any number of volumes, provided sufficient large volume capacity is available.

Performance that Scales with Your Design Cycles

Across breakthrough mode and breakthrough mode scale configurations, latency remains tightly bounded as workload concurrency increases — indicating that Azure NetApp Files large volume breakthrough mode enables linear scalability characteristics without introducing latency instability under load.

EDA_BLENDED Metric	Large volume breakthrough mode	Large volume breakthrough mode scale	Factor
Job Sets	2,880	17,280	6.00x
Throughput (MB/s)	20,910	125,474	6.00x
Operations/second	1,296,040	7,776,147	6.00x
ORT (ms)	0.51	0.60	1.18x

This predictable performance and scale behavior is critical for distributed EDA environments, where design teams increasingly rely on massively parallel simulation and verification jobs to accelerate time‑to‑tape‑out.

From large volume scale… to breakthrough mode scale

Compared to previously published (non‑breakthrough mode) large volume results from October 2025,, large volume breakthrough mode expands the achievable throughput envelope while even lowering observed overall response times as workload levels increase.

This allows Azure NetApp Files to deliver:

Higher aggregate throughput ceilings
Greater concurrency tolerance
Consistent latency behavior under scaled-out EDA job submission

– all without architectural changes to application workflows.

More Throughput + Consistent Low Latency = More Jobs!

What Storage Performance Means For EDA Velocity

Modern EDA workflows are built around rapid, iterative design loops, where architects and physical designers continuously refine Register-Transfer Level (RTL), run regressions, analyze timing, fix violations, and repeat often thousands of times before tape‑out. At scale, these workflows depend on large compute grids with hundreds or thousands of cores accessing shared storage simultaneously. In this environment, storage latency is not just a performance metric; it directly determines engineering velocity and business outcomes. Azure NetApp Files large volume breakthrough mode delivers cloud‑native storage performance that keeps every core productive, enabling higher simulation throughput, faster iteration cycles, and predictable performance even under extreme parallel load. The benchmark results independently validate how Azure NetApp Files large volume breakthrough mode empowers the most demanding modern EDA workflows.

Ultimately, this improves engineering velocity. Shorter regression cycles enable more iterations per day, higher compute utilization eliminates idle cores, and predictable performance allows teams to confidently push scale without risk. More iterations before tape‑out translate directly into better Power, Performance, and Area (PPA) outcomes and faster time‑to‑market. For semiconductor design organizations, Azure NetApp Files large volume breakthrough mode elevates storage from supporting infrastructure to a strategic enabler – delivering independently validated, cloud‑scale performance purpose‑built for the most demanding EDA workloads.

Storage Performance Impact on Engineering Velocity:

Shorter regression cycles → more design iterations per day
Higher compute utilization → no idle cores or wasted licenses
Fewer job failures → engineers focus on design, not infrastructure
Faster data movement → smoother transitions across design stages

This is why companies investing in cloud‑scale EDA infrastructure such as AMD, Microsoft, and ASML, consistently report faster time‑to‑market and stronger design outcomes.

Learn more

Action required: Kerberos RC4 hardening may affect Azure Files Active Directory Domain Services

grace_kim — Fri, 05 Jun 2026 21:50:11 GMT

A Windows security hardening change beginning in April 2026 updates default Kerberos encryption behavior and may impact customers using Azure Files with Active Directory Domain Services (AD DS) authentication over SMB. If you created Azure Files shares prior to 2023, or chose RC4 encryption for your file shares, you will need to reconfigure to use AES-256 to avoid disruption to file share access. This is in accordance with the updated security posture and recommendation from Windows CVE-2026-20833.

Background

Azure Files uses Kerberos authentication for identity-based access when integrated with on-premises Active Directory Domain Services (AD DS). AES-256 Kerberos encryption has been supported since AzFilesHybrid module v0.2.2, and it has been the default since v0.2.5. Historically, RC4 was the only supported option until AES-256 support was added. This is a Windows platform security hardening change; Azure Files service behavior is not being modified.

You may be impacted if:

You use Kerberos-based SMB access to Azure Files with AD DS authentication, and
Kerberos encryption settings are RC4-only or unset (null) for relevant AD objects, service accounts, or computer accounts associated with Azure Files authentication.

When will this happen:

April 2026 – July 2026: Install the Windows security update and validate access. Domain controllers will default to issuing AES-256 tickets when msDS-SupportedEncryptionTypes is not explicitly set.
After July 2026: Manual rollback is removed. If you have not migrated to AES-256 by then, Kerberos-based SMB access to your Azure Files shares may fail.

What you should do now:

Find out if you are impacted, run the following PowerShell command on a domain-joined machine, with read access to AD. This identifies storage accounts that use Azure Files with AD DS authentication but have not been upgraded to AES-256 or follow the detection steps in aka.ms/rc4azurefiles:

Get-ADObject ` -LDAPFilter "(&(servicePrincipalName=*.file.core.windows.net)(!(msDS-SupportedEncryptionTypes=*)))" -Properties servicePrincipalName, msDS-SupportedEncryptionTypes | Select-Object Name, ObjectClass, servicePrincipalName, msDS-SupportedEncryptionTypes

Update configurations to support and prefer AES256-based Kerberos ticket encryption.
Validate end-to-end SMB authentication and application access to Azure Files shares.
Run klist purge from an elevated command prompt to clear any cached Kerberos tickets that still use RC4.
Remount the Azure file share.

For any questions, please reach out to the team at azurefiles@microsoft.com

Resources:

Azure Files documentation on this change
Read the full Windows hardening guidance: How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833.
Learn about RC4 usage in Windows and its risks: Detect and remediate RC4 usage in Kerberos.
Learn more about the related vulnerability: CVE-2026-20833.
Windows Server Blog: Beyond RC4 for Windows authentication

Modernizing Azure Virtual Desktop with Nerdio and Azure Files

Vybava_Ramadoss — Mon, 04 May 2026 16:05:17 GMT

Coauthored with Nerdio

Organizations adopting Azure Virtual Desktop (AVD) typically begin with small pilot deployments that perform well under limited load. As these environments scale to hundreds or thousands of users, a consistent set of challenges emerges. At the center of that shift is the user profile layer. FSLogix profile containers—stored on file shares—sit directly on the critical path of the user experience. During peak periods such as login storms, profile attach latency becomes a primary determinant of sign-in performance. At the same time, identity dependencies, storage configuration complexity, and cost management introduce variability across environments. What worked in a pilot often becomes more difficult to manage consistently at scale.

Common challenges include:

Performance variability during peak concurrency
Complex identity configurations for SMB access
Configuration drift across environments
Cost inefficiencies from peak-based provisioning

At enterprise scale, these issues converge at the storage and identity layers—making them central to both user experience and operational efficiency.

Nerdio: simplifying how AVD is deployed and operated

Nerdio Manager (available as Nerdio Manager for Enterprise and Nerdio Manager for MSP) is a deployment, management, and auto-scaling platform for Azure Virtual Desktop (AVD) with capabilities such as desktop image management, performance monitoring, and user session control to eliminate the need for complex scripting and speed up responses to end-users. Nerdio Manager helps organizations deploy and operate AVD environments in a more consistent, repeatable way. Rather than treating compute, storage, and identity as separate workflows, Nerdio integrates these components into a single operational model. Storage provisioning, permissions, and FSLogix configuration are handled as part of host pool deployment and scaling. This reduces coordination overhead, minimizes configuration drift, and keeps storage aligned with how environments grow.

This view shows how Nerdio brings users, host pools, and storage into a single control plane—ensuring storage is configured as part of deployment, not after.

Azure Files: enabling performance and identity at scale

Azure Files provides the foundational storage layer for FSLogix profile containers in many AVD environments. Because profiles attach at sign-in, storage performance directly impacts user experience.

Provisioned v2: performance without over-provisioning

Azure Files Provisioned v2 decouples performance (IOPS and throughput) from capacity. Previously, higher performance required over-provisioning storage. With Provisioned v2, organizations can align performance directly to workload needs. This is especially important for FSLogix, where login storms create short bursts of high IOPS demand even when data volumes are modest. The result: better cost efficiency and more predictable performance.

“We’ve been early adopters of Nerdio and consistently see meaningful Azure cost optimization… With Azure Files Provisioned v2, the decoupling of quota and IOPS… gives us precise control over performance and cost.” — David Wasserman, Chief Value Officer, FlexibleIT.com

Entra ID authentication: simplifying identity architecture

Azure Files supports Microsoft Entra ID authentication for SMB, enabling a cloud-native identity model.

This eliminates the need for domain infrastructure used only for storage access, resulting in:

Reduced infrastructure overhead
Simpler networking
Lower operational burden
Alignment with Zero Trust

These capabilities are already in use in Nerdio Manager for MSP environments managing multi-tenant deployments, and are being extended to Nerdio Manager for Enterprise in Q3 CY26 to enable the same cloud-native model within enterprise environments

This highlights how provisioning, monitoring, scaling, and identity are handled as part of a unified system instead of fragmented tasks.

Operationalizing storage at scale, why this matters for enterprises

Enterprise AVD environments operate under fundamentally different constraints. User populations are larger and more concentrated, compliance requirements are stricter, and tolerance for performance variability is significantly lower.

In practice, these pressures converge at the storage layer.

For enterprise customers, the goal is not automation itself—it is better user experience, lower cost, and predictable operations.

Faster, more consistent deployments. Storage is configured alongside compute, reducing dependency on separate teams and minimizing drift.
Lower cost without sacrificing peak performance. Capacity and performance align with actual demand instead of peak assumptions.
More predictable sign-ins during login storms. Standardized configuration reduces bottlenecks during high concurrency.
Audit-ready governance by default. RBAC, snapshots, backup, and data protection policies are applied consistently across environments.

Get started

At scale, Azure Virtual Desktop is as much about storage and identity as it is about compute. Azure Files plays a central role in determining sign-in performance, user experience, and cost efficiency. With Provisioned v2 and Entra ID authentication, organizations can move toward a more predictable and cloud-native model. Nerdio builds on this foundation by integrating storage and identity into a unified AVD deployment and operations workflow. Get started with Nerdio today.

AHEAD helps us launch the Strategic Azure Storage Services Partner Program

karautenMSFT — Fri, 01 May 2026 00:49:28 GMT

Authors:

Aung Oo, Vice President Azure Storage Product Management

Parker Leavitt, Partner Account Manager, AHEAD

Special thanks to:

Michael Johnson, Vice President, Cloud, AHEAD

AHEAD background

AHEAD was formed in 2007 and possesses deep expertise in Infrastructure, Cloud Platforms, AI, Analytics, Networking, Storage, Security and many more technical disciplines. 80% of AHEAD’s employees are engineers who help customers with the assessment of their needs to design optimal solutions and through implementation of complex application and infrastructure deployments. Headquartered in Chicago, IL, AHEAD has locations worldwide and is ready to assist with your most complex Azure projects. They hold over 1,000 Microsoft certifications and 4 Advanced Specializations.

Valued collaboration

AHEAD has been a key advisor to Azure Storage throughout the design and build of our Channel strategy. As a premier Microsoft Cloud and AI Partner, and with decades of Storage expertise, AHEAD helped us to create the Learning Path channel partners will need to complete to qualify as a Strategic Azure Storage Services Partner (SASS). SASS Partners have been validated by us to possess the skills to offer consulting, design, implementation, and migration services to Azure and ISV Storage services.

What can you expect?

AHEAD brings their history of infrastructure expertise to Azure Storage customers through a catalog of services that make it possible to select the optimal solution to ensure the ideal blend of price, performance, and resiliency.

Assessment

What are you doing to prepare for the industry wide memory shortage? How well do you understand your datasets? What are your performance requirements? Are there features you are paying for and not using? When was the last time that directory hosting the “Super Important Project” files was accessed? Is there mission critical data hiding that you should be leveraging to fuel Enterprise AI Agents? Is an Azure Storage Service the best fit for your data, or is it better to migrate it to one of our Storage ISV services?

AHEAD provides Microsoft-funded assessments that deliver data-driven guidance to help you align your application and data set needs with the ideal storage service(s) on Azure. We have long advocated that the best solution is the one that meets your requirements both today and in the future. AHEAD can help you get there.

Migration

After gaining insight into your data estate, AHEAD has the experience to help you migrate safely with best-of-breed solutions. Whether offline migration with Data Box or online over the network with Storage Mover or one of our validated ISVs like Komprise, Cirrus Data, or Cirata, AHEAD can help you move your data to an Azure Storage service like Blob Storage, Files, Elastic SAN, or NetApp Files – or one of our ISV Partners like Nasuni and Pure Storage. You can find our full list of validated partners on Microsoft Learn.

Azure Storage ISV Strength

An important reason we chose to onboard AHEAD as our first Strategic Channel Partner was the large crossover in mutual ISV relationships they possess, and their proven skills with each. You can view AHEAD’s full list of partners, including Nasuni, NetApp, Everpure, Commvault, Veeam, Rubrik, and Dell on their website. Our recent engagements with AHEAD and Nasuni are a great example of AHEAD’s depth. They were able to quickly determine Nasuni as the best fit for a customer who required a single centralized Azure-based repository for their data that could then be accessed within Azure and multiple remote locations simultaneously.

AHEAD has shown us that across their portfolio of ISVs, they can help you implement best-of-breed ISV services that include solutions in:

Air Gap Business Continuity
VMware Modernization
Storage Modernization
Cloud Scale Analytics
AI Dataset Curation

How can you move forward?

Do you need help understanding your data estate? Could you use expertise selecting the ideal service in Azure to host your data? Reach out to the AHEAD Azure team at info@ahead.com or via their Rapid Assess offer on Microsoft Marketplace and get started today!

Strategic Azure Storage Services Partner

In coming months, you will see our list of SASS Channel Partners expand, but we could not be more grateful to AHEAD for being a not only a pioneer, but a trusted advisor. Their commitment to Azure and Azure customers has made an impact that will benefit our customers worldwide.

Prefix-scoped access for User Delegation SAS is now generally available for Azure Blob Storage

despindola — Wed, 06 May 2026 20:01:06 GMT

We would like to share that prefix-scoped access for User Delegation SAS for Azure Blob Storage is generally available in all Azure regions.

SAS tokens for Blob Storage have historically supported two levels of scope: container and individual blob. With this release, you can now scope access to a prefix or virtual directory within a container, granting access to all blobs beneath the path.

This is especially valuable for applications that organize data by tenant, workspace, project, or department within a shared container. Instead of granting access to an entire container or generating many blob-level tokens, you can now issue a single SAS token scoped to a set of blobs through a prefix.

For example, if a container has these blobs:

contoso/sales/Q1-report.csv

contoso/sales/Q2-report.csv

contoso/invoice.pdf

A SAS token scoped to the prefix contoso/sales would grant access only to the two sales reports. This simplifies manageability by not having to generate multiple blob scoped tokens which significantly reduces overhead to manage permissions for large scale data storage estates. In addition, it helps customers provide more scoped permissions to a certain set of blobs rather than broader permissions at a container level.

Prefix-scoped access is supported for both Blob and Data Lake storage accounts.

As a best practice, we recommend using Entra ID with RBAC or ABAC for least privilege access. If you need to use SAS for your use cases, we recommend using user delegation SAS and prefix-based scoping is a good option to consider for more scoped permissions for a certain set of blobs.

Pricing and Availability

There is no additional cost for prefix-scoped access for user delegation SAS. Pricing is based on standard transaction costs for your storage account type. To learn more, see Azure Storage Pricing. 

Prefix-scoped access for user delegation SAS is available in all Azure regions.

How to generate a prefix-scoped SAS

To generate and use a prefix-scoped SAS:

Identify the prefix (or virtual directory) you want to authorize.
Follow the steps in the documentation to create a prefix-scoped SAS for user delegation SAS.
Use the SAS token with your application.

Notes

Support for prefix-scoped access parameters is available with authorization version 2020-02-10 or later via REST API and .NET Blob SDKs starting with version 12.29.0-beta.1 and newer.
The semantics for prefix scope (sr=d) are similar to container scope (sr=c), except that access is restricted to a prefix. When creating a prefix-scoped SAS, you must specify the signedDirectoryDepth (sdd) to indicate how many directory levels from the container root to the specified directory. For example, to grant access to dir2 on path container1/dir1/dir2, set the directory depth (sdd) = 2 to indicate the SAS is scoped to dir2 and everything beneath it.
Below are .NET SDK and REST API examples for reference.

.NET SDK Sample Definition

BlobSasBuilder blobSasBuilder = new BlobSasBuilder( permissions: BlobContainerSasPermissions.All, expiresOn: Recording.UtcNow.AddDays(1)) { BlobContainerName = test.Container.Name, BlobName = blobName, IsDirectory = true, }; // Test using same name as SAS BlobUriBuilder blobUriBuilder1 = new BlobUriBuilder(test.Container.Uri) { BlobName = blobName, Sas = blobSasBuilder.ToSasQueryParameters(Tenants.GetNewSharedKeyCredentials()) }; AppendBlobClient appendBlobClient1 = new AppendBlobClient(blobUriBuilder1.ToUri(), GetOptions()); await appendBlobClient1.CreateAsync(); // Test using SAS name + suffix BlobUriBuilder blobUriBuilder2 = new BlobUriBuilder(test.Container.Uri) { BlobName = blobName + "/test", Sas = blobSasBuilder.ToSasQueryParameters(Tenants.GetNewSharedKeyCredentials()) }; AppendBlobClient appendBlobClient2 = new AppendBlobClient(blobUriBuilder2.ToUri(), GetOptions()); await appendBlobClient2.CreateAsync();

REST API Sample Request

GET https://myaccount.blob.core.windows.net/mycontainer

?restype=container

&comp=list

&prefix=dir1/dir2/

&sr=d

&sdd=2

&sp=rl

&sv=2024-11-04

&se=2026-04-22T06:00:00Z

&skoid=<signed-oid>

&sktid=<signed-tid>

&skt=2026-04-22T00:00:00Z

&ske=2026-04-22T08:00:00Z

&sks=b

&skv=2024-11-04

&sig=<signature>

Next Steps

For a deeper dive, explore these resources:

Help and Support

If you have questions, get answers from community experts in Microsoft Q&A. If you have a support plan and you need technical help, create a support request:  

For Issue type, select Technical.  
For Subscription, select your subscription.  
For Service, select My services.  
For Service type, select Blob Storage.  
For Resource, select the Azure resource you are creating a support request for.  
For Summary, type a description of your issue.  
For Problem type, select Authentication and Authorization .
For Problem subtype, select Issues using Shared Access Signature (SAS Token).

Secure, Keyless Application Access with Managed Identities - Now GA in Azure Files SMB

Priyanka-Gangal — Mon, 20 Apr 2026 17:57:56 GMT

As enterprises modernize applications and strengthen their security posture, identity is central to how applications access shared storage. Traditional identity models relying on account keys, stored credentials, or domain‑joined infrastructure add operational overhead and introduce security risks such as credential leakage, lack of identity attribution, and excessive privilege if shared keys are compromised. Today, we are excited to announce the General Availability (GA) of Managed Identity support for Azure Files over SMB, enabling applications and virtual machines to securely access Azure Files without secrets, passwords, or key distribution.

Managed Identity support enables customers to meet modern enterprise security standards without reliance on storage account keys, streamlining how organizations securely enable file‑based application access and reducing the operational overhead of filing internal exceptions. New storage accounts can support secure, identity‑based SMB access out of the box, while existing deployments can get secure by enabling Managed Identity authentication.

From web application workloads such as WordPress, to databases on Azure Kubernetes Service (AKS), to CI/CD pipelines, applications require secure access. In a world where security is foundational, continued reliance on key-based access conflicts with Zero Trust principles and least privilege access.

What’s New In GA

AKS Workload Identity Support

AKS Workload Identity (preview) extends the traditional managed identity model for Kubernetes by shifting the identity from the node to pods. Instead of inheriting the identity of the underlying cluster, each Kubernetes pod can use its own federated identity, mapped directly to a Microsoft Entra ID principal.

This feature enables:

Pod-level identity isolation, rather than cluster-level
Least-privilege access with secure RBAC
Seamless scaling and redeployment, without identity reconfiguration
No secrets, no key rotation, no credential injection

When combined with Azure Files over SMB, Workload Identity allows AKS workloads to access shared file storage securely and natively per pod, using the same identity-driven model as cluster level managed identities. Now available with AKS 1.35, for customers specifically in the financial services industries, AKS Workload Identity enables per‑application, least‑privilege access to Azure Files without credentials, improving isolation and auditability. This allows regulated, stateful workloads to run securely on AKS while meeting strict compliance and regulatory requirements.

Co-existence of Application Identities and end-user identity access

Azure Files now enables both Managed Identity and end‑user access on the same storage account, with users and applications independently authenticated via Entra ID and authorized through a shared permissions model.
This unified access model eliminates the need for duplicate storage or credentials, enabling secure collaboration, troubleshooting, and automation on shared data without compromising governance or compliance.

This supports scenarios such as:

Developers accessing the same file share as an application for debugging
Admins managing content used by automated workflows
Hybrid environments with user-driven and app-driven access

Simplified Storage Account enablement via the Azure portal

We have now added a dedicated Managed Identity property that makes enabling identity‑based SMB access simple and transparent via the Azure portal for new as well as existing storage accounts. With a single configuration at the storage account level, customers can allow applications to authenticate to Azure Files using Managed Identities. This portal experience supports incremental adoption, making it easy to modernize authentication while maintaining compatibility with existing user access and governance models.

Get Started with Managed Identities with SMB Azure Files

Start using Managed Identities with Azure Files today at no additional cost. This feature is supported on HDD and SSD SMB shares across all billing models. Refer to our documentation for complete set-up guidance.

Whether provisioning new storage or enhancing existing deployments, this capability provides secure, enterprise‑grade access with a streamlined configuration experience.

For any questions, reach out to the team at azurefiles@microsoft.com.

Simplify On-prem File share Migration to Azure: Discover & assess suitability using Azure Migrate

bapic — Fri, 22 May 2026 10:24:28 GMT

UPDATE as of 20th May 2026: We are happy to announce that this capability is now GA worldwide.

Migrating on‑premises file servers to the cloud is a complex infrastructure transformation—not just a data move. Many organizations lack the visibility needed to decide whether to rehost or modernize file shares spread across Windows and Linux servers. Azure Migrate now extends its discovery and assessment capabilities to SMB and NFS file shares, enabling a data‑driven approach to modernizing on‑premises file workloads with Azure Files, or alternatively rehosting to deployment within an Azure VM.

We are pleased to introduce the public preview of Azure Migrate’s new comprehensive discovery and assessment of on-premises SMB and NFS file shares for migration to Azure Files. This enhancement simplifies the migration process by integrating discovery and evaluation tools for SMB and NFS shares across both Windows and Linux platforms. Users can efficiently identify file shares, analyze their compatibility, and compare cost benefits for transitioning to Azure Files, all within an intuitive and streamlined interface.

Why does this matter

File shares remain a foundational service for most workloads - supporting applications, analytics, user home directories, and shared content. Planning such a vast amount of data for migration can be slow, manual, and fragmented. This new Azure Migrate capability is designed to help with:

Reduce migration planning from months to weeks through automated discovery and assessment of SMB and NFS file shares.
Perform holistic migration planning of your data and storage alongside servers, applications and data bases from within Azure Migrate experience.
Modernize confidently to Azure Files with tailored SKU recommendations, readiness assessments, and comprehensive cost insights, enabling you to build a clear business case by comparing ongoing on-premises and Azure Files costs.

What’s available in public preview

Discover and view details of all on-premises SMB, NFS shares hosted on Windows and Linux servers
Group, tag, filter shares by Production, non-production, project, business group for better planning.
Create and review assessment for each share, its target Azure Files SKU based on region, redundancy, pricing options and media type.
Generate a business case for selected group of shares running on Azure Files against on-premises cost.

How do you get this feature? Install the latest Azure Migrate appliance, or enable the auto update feature for the appliance will receive this new capability. All existing SMB, NFS file shares will be reported in the Azure Migrate portal along with their Windows and Linux hosts. You do not need to perform any additional steps to discover the shares.

End-to-end experience

The experience is fully integrated into Azure Migrate and follows a familiar, guided workflow as below.

1. Discover on‑premises file servers and file shares

You can start by creating an Azure Migrate project in the Azure portal and enabling discovery using the Azure Migrate appliance. The appliance can be deployed in connected or disconnected mode and runs on VMware, Hyper‑V, or physical servers. Once deployed, the appliance automatically discovers file servers and the file shares they host, including:

Operating system (Windows or Linux)
File share protocol (SMB or NFS)
Associated volumes
Estimated capacity
Basic performance metrics such as IOPS and throughput (when performance collection is enabled)

Discovered file shares appear directly in Azure Migrate inventory views, where they are surfaced as inventory items under respective Windows or Linux systems. This makes it easy to filter, tag, and review all shares at scale.

2. Build a business case

The next step is to create a business case. This offers a clear comparison of on-premises costs versus Azure, highlights long-term savings and operational benefits, and justifies modernizing to Azure Files rather than rehosting file servers on virtual machines. This allows IT leaders to make data-driven decisions confidently.

3. Create and review an Azure Files assessment

Once you have finalised your business case and decided to move to Azure Files, you can initiate an Azure Files assessment right from the Azure Migrate platform. The assessments are adaptable, allowing you to focus solely on file shares, include their parent servers, or even expand to scenarios that cover VMs, databases, and file shares—reflecting real-world planning needs. Each assessment reviews readiness and provides recommendations based on inventory and performance metrics gathered. Furthermore, you can tailor assessment settings, including selecting a target Azure region, pricing and savings preferences, media type, redundancy options, and choosing either performance-based or as-is sizing. The assessment offers a detailed overview of migration readiness and economic factors, supporting well-informed decisions for subsequent actions.

Key insights include:

Readiness states for each file share (Ready, Ready with conditions, or Not ready)
Recommended Azure Files SKU based on performance and suitability. For example, Azure Files provisioned v2 premium SSD for a NFS 4.1 share as target.
Monthly cost estimates for the recommended SKU.
On‑premises vs Azure TCO comparison, helping customers understand long‑term cost implications

Azure Migrate also identifies potential warnings and provides necessary remediation guidance. For example, when a redundancy type is not available in an Azure region, it is flagged as ready with conditions and recommend choosing an alternative redundancy type and fallback to next available option.

Prepare for migration with appropriate tools

Once you are ready to migrate, Azure Migrate also highlights recommended migration tools as part of the assessment. Azure Storage Mover is the default recommended path for file share migrations—providing a first party, managed service to move data efficiently to Azure Files. To learn more about Microsoft’s recommendations to unstructured data migration using other tools, please visit: https://aka.ms/migratemydata.

Learn more about creation of assessment and review assessment to get started with understanding your on-premises file shares estate today. Write to us at migratemydata@microsoft.com for any questions or feedback - we look forward to hearing from you!

Unlocking AI-Ready Unstructured Data at Scale with Komprise and Azure

dmalbrough — Thu, 02 Apr 2026 09:53:30 GMT

Why Move Unstructured Data to Azure

On-premises storage environments are often over-provisioned to accommodate future growth, driving costs and operational complexity. Azure’s cloud-based storage platform enables organizations to right-size their environments through elastic scaling and Microsoft’s global economies of scale. This flexibility is especially critical for regulated industries managing sensitive data at massive scale.

Azure also delivers enterprise-grade security capabilities, including immutability and object locking, which protect data against ransomware and malicious deletion. By moving unstructured data to Azure, organizations gain not only cost efficiency, but also a more resilient and secure data foundation.

A strong example of this approach is the Florida Department of Environmental Protection. With support from Komprise and funding through Microsoft’s Azure Migrate program, the department successfully migrated large volumes of data to Azure, enabling the phase-out of on-premises data centers while maintaining access to data for analysis across regions. This demonstrates how organizations can modernize data infrastructure without disrupting business operations.

Hybrid Cloud and Intelligent Tiering

Most enterprises operate in hybrid environments, balancing on-premises systems with cloud storage. Komprise and Microsoft address this reality by enabling intelligent tiering of unstructured data across environments.

Using Azure Blob Storage, organizations can transparently move cold and infrequently accessed data to lower-cost cloud tiers while keeping frequently accessed data close to applications and users. This approach reduces pressure on expensive on-premises storage infrastructure without sacrificing accessibility. For example, a major healthcare organization achieved approximately $2.5 million in storage cost savings by tiering cold data to Azure while maintaining seamless access for clinicians and applications.

AI Depends on Data Curation

AI's efficacy is reliant on data quality. The need for high-quality and curated data cannot be enough emphasized so AI can generate meaningful and accurate results. In partnership with Komprise, organizations can efficiently cleanse and enhance their data by identifying and eliminating redundancies. By curating data before AI processes, organizations have achieved impressive accuracy improvements—as demonstrated by a financial services firm that increased their AI output accuracy by 135%.

Making Data AI-Ready on Azure

Azure provides a powerful execution platform for AI and Komprise enhances this by bringing structure to unstructured data through its data classification, metadata extraction capabilities and with search, curation and intelligent ingestion via its data workflow and governance capabilities. These ensure only high-quality, relevant and compliant data feeds AI workflows.

This approach enables smoother integration with AI services and applications such as Microsoft Foundry and Copilot, while preserving flexibility. By treating data readiness as a foundational step, organizations can accelerate time to value from AI while reducing risk.

Security, Governance, and Responsible AI

As cyber threats and regulatory requirements continue to intensify, security and governance are no longer optional. Organizations must manage data flows carefully, maintain auditability, and protect sensitive information—especially when using data for AI.

Azure’s built-in security capabilities, including immutability, versioning, and backup, provide a strong foundation for protecting unstructured data. Komprise complements these capabilities by automating data governance policies, enforcing compliance, and helping organizations maintain visibility and control across hybrid environments. Together, they enable organizations to use data safely and responsibly, supporting both regulatory compliance and responsible AI practices.

Conclusion

As AI adoption accelerates, success increasingly depends on data readiness rather than algorithms alone. Clean, well-governed, and properly placed data is the foundation for meaningful AI outcomes.

By combining Azure’s scalable and secure cloud platform with Komprise’s intelligent data management, organizations can reduce costs, strengthen security, and unlock real value from unstructured data at scale.

To learn more, watch the Microsoft–Komprise fireside chat, where we discuss customer examples, architectural best practices, and proven approaches for managing unstructured data across hybrid environments. We also invite you to explore our joint Azure and Komprise solutions to see how you can move from data sprawl to AI value while maintaining control, security, and flexibility.

In a recent fireside chat now available on YouTube, Azure Storage VP Aung Oo joined Komprise COO Krishna Subramanian to explore how Azure and Komprise are empowering customers to mobilize, curate, and optimize unstructured data to make it AI-ready.

To leverage the Storage Migration Program with Komprise to migrate your data to Azure find more information at Microsoft Marketplace. To take advantage of the full Komprise suite including automated tiering and smart workflows – additional details are available here.

Enterprise Identity Meets Secure File Transfer: Entra ID Public Preview on Azure Blob Storage SFTP

JeevanManoj — Tue, 23 Jun 2026 12:50:37 GMT

Updated on June 23 2026: Microsoft Entra ID-based access for Azure Blob Storage SFTP is now Generally Available. GA enhancements: Improved ABAC by resolving inconsistencies with the Storage Blob Data Owner role (eliminating timeout issues) while adding support for sub-operations to enable more granular access control. Learn more here.

We are excited to announce the public preview of Entra ID-based access for Azure Blob Storage SFTP. This new capability enables you to use Microsoft Entra ID (formerly Azure Active Directory) identities (including guest users via Entra External Identities) to securely connect to Azure Blob Storage via SFTP without needing local users. This feature eliminates the operational overhead of managing local SFTP users and passwords by introducing enterprise-grade identity management powered by Microsoft Entra ID.

For IT administrators and security teams, this means no more creating, tracking, rotating, or decommissioning local SFTP credentials. For developers and architects, it means seamless integration with your existing identity infrastructure. For business users, it means faster, more secure access to the data they need, all while maintaining compliance with enterprise security policies.

Azure Blob Storage SFTP

Azure Blob Storage SFTP natively enables secure file access and management without third-party solutions. This simplifies operations for customers and removes the need for complex, custom SFTP solutions. Until this Public Preview, Azure Blob Storage SFTP utilized a form of identity management called local users as the only authorization mechanism. Local users must use either a password or a Secure Shell (SSH) private key credential for authentication. Learn more about local users here.

The Challenge: SFTP Local User Management

Organizations currently face challenges when managing SFTP access at scale with Azure Storage SFTP Local Users. Local User based SFTP access require IT teams to:

Manually create and provision local user accounts for each SFTP user
Generate, distribute, and securely store SSH keys or passwords
Implement custom workflows for lifecycle management
Manage offboarding processes to ensure departed users lose access immediately
Audit and track access across disconnected identity silos
Handle external partner and vendor access through ad-hoc, often insecure methods

The Solution: Enterprise Identity Meets Secure File Transfer

With Entra ID-based access for Azure Blob Storage SFTP, you can now leverage your organization's centralized identity platform to authenticate and authorize SFTP users. This integration brings the full power of Microsoft Entra ID to your file transfer workflows, delivering the following benefits:

1. Eliminate Local User Management

Simplify SFTP management by assigning access with Entra ID—no separate SFTP accounts needed.

No local credential generation or distribution—users authenticate with their existing corporate credentials
No orphaned accounts when users change roles or leave the organization
Reduced attack surface by eliminating static, long-lived local credentials
Centralized user lifecycle management through your existing identity platform

2. Enterprise-Grade Identity and Security

Leverage the full security capabilities of Microsoft Entra ID for your SFTP infrastructure:

Multi-Factor Authentication (MFA): Require additional verification factors beyond passwords, significantly reducing the risk of account compromise
Conditional Access: Define policies that grant or block access based on user location, device compliance, sign-in risk, and other conditions
Identity Protection: Benefit from Microsoft threat intelligence and risk detection to identify and respond to compromised accounts
Privileged Identity Management (PIM): Provide just-in-time elevated access for administrative operations

3. Native Azure RBAC, ABAC, and ACL Integration

Your SFTP access control seamlessly integrates with Azure comprehensive authorization framework:

Role-Based Access Control (RBAC): Assign built-in or custom roles at the storage account, container, or even blob level
Attribute-Based Access Control (ABAC): Create sophisticated access policies based on resource tags, user attributes, and environmental conditions
Access Control Lists (ACLs): Apply fine-grained permissions at the directory and file level for hierarchical namespace-enabled accounts
Unified Permission Model: SFTP access respects the same permissions as REST API, Azure CLI, and other access methods—no separate permission system to manage

4. Faster SFTP Onboarding and Time-to-Value

Onboard new SFTP users or partners in minutes instead of hours or days, saving significant time and boosting business agility.

5. Secure External Collaboration with Entra External Identities

Seamlessly enable secure external SFTP access by allowing partners to authenticate with their own credentials using Entra External Identities (Azure AD B2B).

External users authenticate with credentials they already manage
Full audit trail of external user activity
Ability to apply Conditional Access policies to external users
Automatic access revocation when B2B relationships end

Real World Scenarios

Financial Services: A bank receives daily transaction files from merchants via SFTP. Merchants authenticate with their own Entra ID credentials (B2B collaboration), MFA is enforced, and access is restricted to assigned directories. Access is instantly revoked when a merchant is removed from the B2B directory.
Healthcare: A hospital exchanges patient data with insurers and labs. Entra ID authentication ensures only authorized staff access sensitive PII, with full audit logs for HIPAA compliance. Conditional Access restricts connections to approved locations and devices.
Media & Entertainment: A production company enables freelance editors and agencies to transfer large media files. Entra External Identities provide time-limited access and automatic revocation when projects end—no need for local SFTP accounts.
Manufacturing: A manufacturer receives CAD files and orders from suppliers using SFTP. With Entra ID, suppliers use unified credentials and access policies across all systems, streamlining supply chain management.

How It Works

Entra ID simplifies SFTP access to Azure Blob Storage by authenticating users with their corporate credentials. After authentication, users receive a short-lived Open SSH certificate to connect. The service verifies certificate validity and user permissions, enabling secure file operations and automatic access revocation in line with current identity policies. Learn more here.

Getting started with the Public Preview

We encourage you to try Entra ID-based access for Azure Blob Storage SFTP in your non-production environments today. Learn more about how to register for the preview and get started with the detailed ms docs learn guide here. This preview gives you an opportunity to shape the feature development by providing feedback on what works well and what could be improved.

Note: Local user accounts for SFTP access are still supported, but we strongly recommend switching to Entra ID-based access for greater security, simpler management, and automatic access control.

Questions or feedback? We would love to hear from you! Reach out to our team at blobsftp@microsoft.com

We are excited to bring enterprise-grade identity management to Azure Blob Storage SFTP, and we cannot wait to see how you use this capability to simplify operations, enhance security, and enable new collaboration scenarios.

Happy transferring!

Understanding the Standard HDD I/O unit size update and what it means for your workloads

austin-ma — Wed, 22 Apr 2026 15:18:03 GMT

As Azure continues to evolve to support modern workload patterns, we are refining how transactions are measured for Standard HDD Managed Disks. This update helps align billing more closely with actual I/O behavior while maintaining predictable cost controls for customers.

In this post, we’ll walk through what’s changing, how transaction billing is calculated, and what this may mean for your workloads.

With this update, the number of billable transactions for select Standard HDD disk sizes (S4, S6) will be measured using 16 KiB I/O units.

I/O operations ≤ 16 KiB count as one billable transaction
I/O operations > 16 KiB are counted as multiple billable transactions

Example

A 64 KiB read/write on an S4 disk = 4 billable transactions
A 4 KiB read/write on an S4 disk = 1 billable transaction

This update provides more consistent alignment between workload behavior and transaction billing. For latest information on regional availability, please refer to the Standard HDD Managed Disks documentation.

Built-in transaction caps to help manage costs

To maintain predictable cost boundaries, Azure will implement hourly caps on billable transactions for the Standard HDD disk sizes with an I/O unit size.

If a disk exceeds its hourly cap, additional transactions in that hour are not billed. The transaction caps are listed below and on the Azure Disks Pricing Page.

Disk Size	Disk GiB	Hourly Billable Transaction Cap
S4	32 GiB	450,000
S6	64 GiB	858,000

These caps help provide cost predictability, particularly for bursty workloads.

Understanding potential cost impact

Workloads with larger I/O sizes and sustained IOPS may see changes in the number of billed transactions on their invoice. Workloads with small or infrequent I/O operations may see little to no impact.

Determining your workload’s cost

The following table lists three different examples to illustrate how transaction billing* compares for different IO load intensities on an S4 Standard HDD disk vs. an E4 Standard SSD disk. Assume the disks are in Central US region.

Workload Average

Billable Transactions / hour on Standard HDD

Billable Transactions / hour on Standard SSD

Total Cost on Standard HDD

Total Cost on Standard SSD

Low

4 KiB workload, 10 IOPS

36,000

(10 billable transactions * 60 seconds * 60 minutes)

36,000

(10 billable transactions * 60 seconds * 60 minutes)

$2.85/mo

(36,000 * 730 hours * $0.0005 / 10,000 transactions) = $1.31 Transaction cost

$1.31 + $1.54 capacity/mo cost = $2.85/mo

$7.66/mo

(36,000 * 730 hours * $0.002 / 10,000 transactions) = $5.26 Transaction cost

$5.26 + $2.40 capacity/mo cost = $7.66/mo

Medium

32 KiB workload, 20 IOPS

144,000

(40 billable transactions with the IO Unit Size * 60 * 60)

43,400

(after Standard SSD transaction cap)

$6.80/mo

$8.73/mo

High

64 KiB workload, 40 IOPS

450,000

(after Standard HDD transaction cap)

43,400

(after Standard SSD transaction cap)

$17.97/mo

$8.73/mo

*Any operation against the storage is counted as a transaction, including reads, writes, and deletes. Host caching being enabled might affect the number of transactions against the storage that are counted.

Choosing the right disk for your workload

Running workloads on SSD-based disk types may also unlock higher availability, higher reliability, more consistent performance, and lower latency.

For OS disks running on Standard HDD, consider migrating to Standard SSD or Premium SSD Managed Disks. Standard HDD OS disks will be retired in September 2028.
For non-OS disk workloads, consider high performance and flexible provisioning benefits of Premium SSD v2 Managed Disks, or benefits of Standard SSD or Premium SSD Managed Disks. Learn more here about the different disk types and their benefits.
To learn more about switching your disk types, view our documentation page.

To learn more about the billing changes, view the Pricing Page and documentation for Standard HDD Managed Disks.

Public Preview: Restrict usage of user delegation SAS to an Entra ID identity

ellievail — Tue, 03 Mar 2026 22:43:07 GMT

Shared access signatures (SAS) grant time-bound, scoped access to Azure Storage resources without sharing account keys. Over time, Azure Storage has continued to strengthen SAS security, moving from account keys to user delegation (UD) SAS secured by Microsoft Entra ID.

Today, we’re taking the next step forward by announcing public preview for user-bound user delegation SAS, an extension of UD SAS that ensures a SAS token can only be used by a specific Entra ID identity. This new capability helps customers significantly reduce the risk of unintended access while preserving the flexibility of SAS.

UD SAS is an existing feature which utilizes Entra ID and Azure role-based access control (RBAC). Users retrieve a user delegation key tied to their Entra ID account and then use it to create SAS tokens granting a subset of their own access rights. The resulting token can be traced to the delegator and can only be valid for up to 7 days. User-bound UD SAS is an extension of user delegation (UD) SAS which allows users to create a more secure SAS token by restricting the usage of the SAS token to an end user identity. The delegator specifies the Entra identity (security principal) of the end user in the SAS token and the end user needs to authenticate to Entra ID to use the token. The end user can either be in the same tenant or a different tenant as the delegator.

Pricing and availability

There is no additional cost for user-bound user delegation SAS. Pricing is based on the standard read/write transaction costs for your storage account type. To learn more, please see Azure Storage Pricing.

User-bound user delegation SAS is in preview in all public regions. This preview will be available via REST APIs, SDKs, PowerShell, and CLI experiences.

Getting started

Getting started is simple:

User-bound user delegation SAS is available on all GPv2 storage accounts in public regions.

If the end user of the SAS token is in a different tenant, the allowCrossTenantDelegationSas setting must be enabled on the storage account. If you are not planning on using this feature cross-tenant, the account setting can remain disabled.

Perform the following steps in the create a user delegation SAS documentation to generate and use a user-bound UD SAS token:

Ensure you have the correct RBAC roles assigned to the delegator to create a user delegation key. These roles will include the Storage <Service> Data Contributor and Storage <Service> Delegator (replace Service with the respective service you are using). Here are all of the applicable roles for each service:

Azure Blob	Azure Table	Azure Files	Azure Queue
Storage Blob Data Contributor	Storage Table Data Contributor	Storage Files Data Contributor	Storage Queue Data Contributor
Storage Blob Delegator	Storage Table Delegator	Storage Files Delegator	Storage Queue Delegator

Get a user delegation key (instructions here)
Get the OAuth object ID and tenant ID from your end user. They will have to get these IDs (instructions here) and provide them to you.
Create the user-bound user delegation SAS token (instructions here. Note that the steps are the same as for a normal UD SAS token; you will just have to specify the end user and tenant if applicable).
Share the SAS token to the application/user intended to access Azure Storage.
Tokens should be passed within applications automatically or shared via key vault for best practice.

Feedback

If you have questions or feedback, please fill out this feedback form. If you need help, create a support request.

Azure Storage Blog articles

Optimize Oracle workloads on Azure with Azure NetApp Files

Table of Contents

Introduction

Azure NetApp Files Advancements Overview

Azure NetApp Files Advancements in Detail

Flexible service level capacity pools

Oracle Direct NFS

Application volume group for Oracle

Availability zone volume placement

High availability

Standard network features

Simplified deployment

Optimal volume placement

Scalability and flexibility

Integrated data protection

Using application volume group for Oracle

VM IO throttling

Automatic Storage Management (ASM)

Migration assistant

Short-term clones

Storage with cool access

Sizing Your Volume Deployment for Oracle

Using Azure NetApp Files as backup target and test/dev for Oracle AI Database@Azure

Summary

Learn more

Announcing General Availability of Client-Side Data Integrity Protections in Azure Blob Storage

Azure’s Commitment to Data Integrity

Extending integrity to your client applications

Benefits of CRC64-NVME

Performance

Usage

Availability

Comparison to MD5

Next Steps

Boost performance with NFS nconnect on Azure NetApp Files datastores for Azure VMware Solution

Table of contents

Introduction

What is nconnect

Why it matters

How it works

Reading the numbers: what the Azure VMware Solution datastore data shows

What this unlocks for Azure VMware Solution with Azure NetApp Files

Use cases

Conclusion

Next steps

Learn more

Bringing Enterprise File Data to Users with Azure NetApp Files, Microsoft Foundry, and M365 Copilot

Table of Contents

Introduction

Why the user experience layer matters in enterprise AI

Microsoft Foundry: Orchestrating enterprise AI agents

The Copilot agent as the enterprise user experience

End‑to‑end user query flow

Why this pattern works for regulated and complex environments

Extending Copilot beyond SharePoint‑centric scenarios

From storage to knowledge to action

Key takeaway

Put the architecture into practice

Learn more

From Enterprise File Storage to an AI-Ready Data Foundation using Azure NetApp Files and OneLake

Table of Contents

Introduction

Why the data foundation matters

Expanding beyond collaboration-centric data

The zero‑copy data foundation pattern

Why OneLake changes the model

What this enables

Key takeaway

Learn more

From File Data to AI‑Powered Knowledge Pipelines using Azure NetApp Files object REST API

Table of Contents

Introduction

Why a knowledge pipeline is required

Retrieval‑augmented generation (RAG) at enterprise scale

Knowledge pipeline architecture overview

Step 1: Indexing enterprise file content without moving it

Step 2: Creating semantic meaning with embeddings

Step 3: Retrieval at query time

Step 4: Grounded answer generation