Introduction

So, the task is fairly simple: an IIS web application needs to store user files and later serve them over HTTP or HTTPS. For example, it may save PDF documents and then open them later through a browser link. The simplest path is to store those files on the server’s local disk, for example in C:\Files. That does work, and for some systems it is enough. But as a durable solution, it is weak. A virtual machine’s local disk is not the kind of place you want to rely on as long-term file storage. On the other hand, when people think about file storage in Azure, Blob Storage is usually the first thing that comes to mind. That makes sense, but it is not always convenient, especially in lift-and-shift migrations. Often, both the application and IIS expect a regular Windows file system, and Azure Files fits that model perfectly. We are still working with folders and paths, but the files themselves are no longer tied to a specific host.

Defining the task

At first glance, everything seems straightforward: create an Azure Storage Account and a File Share, connect the share to Windows Server, and then tell IIS to serve files from that folder. In practice, though, it tends to break almost immediately in several places. First, Azure Files over SMB requires port 445 to be reachable. If it is blocked by network policy or a firewall, the connection will fail right at the very first step. Second, even if an administrator successfully mounts the share as drive Z:, that does not mean IIS will be able to read it. This is a very common issue. What is visible to a user is not necessarily visible to the IIS process. Third, IIS runs by default under ApplicationPoolIdentity or another service account. For that identity, a network resource mounted manually in an administrator’s session often simply does not exist. It is better to keep the right model in mind from the start: a mapped drive is convenient for testing, but IIS generally works with a UNC path and explicit credentials. That is exactly the setup we will walk through next.

Overall solution idea

In general terms, the working setup looks like this:

• Create an Azure Storage Account and a File Share.
• Verify that Windows Server can actually reach Azure Files over SMB.
• Mount the File Share on the server or at least verify access to it through a UNC path.
• Create a virtual directory in IIS that points to the UNC path of the Azure File Share.
• Configure the credentials IIS will use to read that network folder.
• Verify that files are actually accessible by URL.

Practical configuration

Let’s walk through all of this in practice. First, it makes sense to verify that the server can actually see Azure Files over SMB. Then we will mount the share, configure the UNC path in IIS, and finally address the most painful part separately: which account the site will use to access the network folder.

Step 1. Check Azure Files availability over SMB

A convenient way to do this is to use the command that Azure Portal typically suggests when you connect a File Share:

$connectTestResult = Test-NetConnection -ComputerName mystorageaccount.file.core.windows.net -Port 445 if ($connectTestResult.TcpTestSucceeded) { Write-Host "Port 445 is reachable." } else { Write-Error "Unable to reach the Azure storage account via port 445." }

If this test fails, the problem is with network connectivity. Usually it is a firewall, NSG, proxy, corporate policy, or an ISP restriction on port 445.

Step 2. Connect the Azure File Share to Windows Server

If the Storage Account and File Share are already created, the quickest way to get the connection command is to open the File Share in Azure Portal and select Connect. The portal will show you a ready-made PowerShell script. It usually looks something like this:

$connectTestResult = Test-NetConnection -ComputerName mystorageaccount.file.core.windows.net -Port 445 if ($connectTestResult.TcpTestSucceeded) { cmd.exe /C "cmdkey /add:`"mystorageaccount.file.core.windows.net`" /user:`"localhost\mystorageaccount`" /pass:`"storage-account-key`"" New-PSDrive -Name Z -PSProvider FileSystem -Root "\\mystorageaccount.file.core.windows.net\myfileshare" -Persist } else { Write-Error -Message "Unable to reach the Azure storage account via port 445." }

After that, a network drive such as Z:\ will appear on the server. It is useful for initial validation: you can open it in Explorer, create a test folder, or drop in a test PDF. But there is one important practical note here. For IIS, I would not build the solution around a drive letter. A mounted Z:\ drive is useful for validation, but in the IIS configuration itself it is better to target the UNC path right away:

\\mystorageaccount.file.core.windows.net\myfileshare

That usually eliminates half of the confusion where the administrator can see the share but IIS cannot.

Now we need to tell IIS exactly where to serve files from. To do that, create a virtual directory under the target site. For example:

• alias: files
• physical path: \\mystorageaccount.file.core.windows.net\myfileshare\documents

After that, the URL to a file will look something like this:

https://example.com/files/test.pdf

From a technical perspective, this is already almost the entire solution. But in practice, this is usually the stage where the main issue appears: IIS cannot read the network path.

Why a mapped drive is not enough

This is the key point of the whole article. When you connect an Azure File Share via New-PSDrive -Persist or through Explorer, you do it in the context of a specific user. Typically, that is the administrator who is currently logged into the server. IIS does not run under that user. By default, the application typically runs under ApplicationPoolIdentity, meaning a separate service identity such as:

IIS AppPool\MyApplicationPool

That leads to the classic situation: everything is visible in Explorer, but through the site you get a 401, a 500, or an error accessing the physical path of the virtual directory. That is why, for network resources in IIS, two approaches usually work:

• Specify a UNC path and configure Connect as... with a specific user.
• Or run the application pool under a separate account in whose context the Azure Files credentials are stored.

Here I will follow the first option. For migrating an existing application, it is usually the most practical one: the file model barely changes, and the main pain is reduced to the UNC path, permissions, and the account IIS actually uses to access the share.

Step 4. Configure a user for access to the Azure File Share

One workable option is to create a separate local user on the virtual machine that IIS will use to access the network folder. For example:

iis-files-user

You can create it through Computer Management, or via PowerShell:

New-LocalUser -Name "iis-files-user" -Password (Read-Host -AsSecureString "Enter password") -FullName "IIS Files User" -Description "User for IIS access to Azure File Share"

After that, the user must have credentials for access to the Azure File Share. If you are using the storage account key, those credentials are usually stored with cmdkey: cmdkey /add:mystorageaccount.file.core.windows.net /user:localhost\mystorageaccount /pass:storage-account-key

Step 5. Specify the user in the IIS virtual directory

Now go back to IIS Manager:

• Open the virtual directory you created, for example files.
• Select Basic Settings...
• Click Connect as...
• Choose Specific user.
• Enter the user, for example .\iis-files-user or SERVERNAME\iis-files-user.
• Enter the password.

After that, it is useful to click Test Settings... If everything is configured correctly, IIS will report successful access validation for the physical path. It is important not to confuse the purpose of this user. It is not for authenticating the site’s end users. It is only there so IIS itself can read files from the network folder.

Step 6. Verify that files actually open

After the configuration is complete, you can place a test file in the share, for example:

\\mystorageaccount.file.core.windows.net\myfileshare\documents\test.pdf

If the virtual directory points to the documents folder, the file should open via a URL like this:

https://example.com/files/test.pdf

At this stage, I would test several scenarios right away:

• https://example.com/files/test.pdf
• https://example.com/files/image.png
• https://example.com/files/some-folder/document.pdf

If the files open, that means IIS has indeed gained access to the Azure File Share and can serve its contents to users over HTTP or HTTPS. Goal achieved.

Summary

You can store user files on the local disk of a virtual machine running IIS, but as soon as the server starts getting recreated, moved, or simply maintained, that solution quickly reveals its weak points. Azure Files allows you to move the files outside the VM itself without breaking the familiar working model of a Windows application: check port 445, connect the File Share, create a virtual directory, specify the UNC path, configure Connect as..., and voilà — the files become available through HTTP requests.

Useful links

• Mount SMB Azure file share on Windows
• Azure Files identity-based authentication overview
• IIS Application Pool Identities