【第1回】Azureで社内webシステムを再現｜AzureFiles ✖︎ IIS

## はじめに

本記事は、「Azure で社内システムを再現する」シリーズの第１回です。  
Azure の IaaS を用いて、オンプレミス環境を模した構成を段階的に構築していきます。

構成図と処理フローの詳細は、以下の記事をご参照ください👇  
▶ [【第0回】Azureで社内webシステムを再現｜構成図と動作の流れ](https://qiita.com/saba_infra/items/a5e58ded68973e4551ee)

---

## システム構成（今回の対象範囲）

以下は、最終的に構築を目指す全体構成図です。

![azure_onpre_joutai (2).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4037248/eb016275-dad7-41ae-911d-dcbe40c750a5.png)

この記事では、赤枠で囲っている部分が対象です。
IISからAzure Filesに配置したアプリケーションのファイルを参照して表示する構成を作成します。

IISではこの共有フォルダをマウントして参照しており、Webページとしてそのまま配信できる構成です。  
これにより、アプリの更新時はAzure Files上のファイルを差し替えるだけで反映されるようにします。

---

## Azure Filesの作成とファイルの配置

Azure Portalから、ストレージアカウントを作成し、その中にファイル共有（Azure Files）を作成します。

![スクリーンショット 2025-04-11 22.02.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4037248/5da3468c-443c-4d98-adec-5b2e86b17a30.png)



作成したファイル共有には、Webアプリケーションで使用する静的ファイルをアップロードしておきます。  
これらのファイルは、後ほどIISサーバーからマウントして参照することになります。

---

## AzureFilesのマウント

作成したAzure Filesは、IISをインストールした仮想マシン上にネットワークドライブとしてマウントします。  
今回は、**Yドライブ**として割り当てました。

![スクリーンショット 2025-04-11 22.03.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4037248/13e59073-8b85-47a3-a5c5-d490d88ee1d2.png)


エクスプローラ上でも、正常にマウントされていることが確認できます。  


![スクリーンショット 2025-04-11 22.04.49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4037248/7db5cd2f-75c6-46d0-8b53-9f4c22134f13.png)

---

## IISでの仮想ディレクトリ設定

IISでは、マウントしたYドライブを仮想ディレクトリとして設定し、Web上に公開します。

![　.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4037248/e3790795-2037-40df-affe-bd6b64277942.png)


仮想ディレクトリ名は `employee-app` とし、物理パスには Azure Files の UNC パス（`\\<ストレージアカウント名>.file.core.windows.net\<ファイル共有名>`）を指定しました。

> ※注意  
> `Y:\` のようなネットワークドライブ経由のパスを指定すると、IISの実行ユーザーからアクセスできないことがあります。  
> そのため、**仮想ディレクトリには UNC パスを直接指定することが推奨されます**。


---

## アクセス時のエラーと対処

仮想ディレクトリの設定を終え、ブラウザからアクセスを試みたところ、**403エラー**が発生しました。

![スクリーンショット 2025-04-11 22.24.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4037248/5a9f697b-e7fb-495e-96c7-8361dbdafae9.png)


403エラーは、アクセス権限が不足している場合によく発生します。  
そのため、IISがAzure Filesに対してアクセスできていない可能性があると考えました。

調査を進める中で、以下の参考サイトを発見しました。

[Azure FilesをWindowsでユーザー指定マウントする方法（jpaztech.github.io）](https://jpaztech.github.io/blog/vm/azure-files-user-mount/)

このページでは、PowerShellの `New-SmbGlobalMapping` コマンドを使って、  
**Azure Filesを“すべてのユーザーからも利用できる状態で”マウントする方法**が紹介されています。

通常の `net use` コマンドによるマウントでは、コマンドを実行したユーザーにしかマウントが見えません。



そのため、IISのアカウント（たとえば `IUSR` やアプリケーションプールの実行アカウント）からは、Azure Filesにアクセスできず、403エラーになったんじゃないかなと考えました。

---

## `New-SmbGlobalMapping` コマンドの実行

以下のコマンドを使用して、Azure Files を **Yドライブにマウント**しました。

```powershell
# ストレージアカウント名をユーザー名として指定
$User = "localhost\<ストレージアカウント名>"

# アクセスキーをパスワードとして指定
$PWord = ConvertTo-SecureString -String "<ストレージアカウントアクセスキー>" -AsPlainText -Force

# 認証情報（Credential）を作成
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User, $PWord

# Azure Files を Y ドライブにマウント（他のユーザーからも参照できるように）
New-SmbGlobalMapping -RemotePath "\\<ストレージアカウント名>.file.core.windows.net\<ファイル共有名>" -Credential $Credential -LocalPath Y: -Persistent $true

```

## アクセス確認

グローバルマウントを行った後、ブラウザから再度アクセスを試みたところ、  
**Webページが正常に表示されるようになりました。**

![スクリーンショット 2025-04-11 22.37.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4037248/328c06ea-28e6-47ad-8783-5efc2141adf2.png)


これで、Azure Files 上に保存されたファイルを、  
IIS を通じて Web ページとして配信できることが確認できました。