Azure ファイル共有（Azure Files）を IIS の「共有構成」ストアとして使おうとすると、OS レベルでは SMB 経由で普通に読めるのに、なぜか IIS だけ「構成を共有できない」とエラーになるケースがあります。特に Windows Server 2025 + IIS で冗長構成を組む検証中にハマりやすいポイントです。本記事では、実際に発生した事例をベースに、原因と対処手順、そして運用上の注意点まで詳しく整理します。
Azure Files を IIS 共有構成に使ったときの典型的な現象
まず、今回のケースの前提と「どんな症状が出るのか」を整理します。
前提環境の例
| 項目 | 内容 |
|---|---|
| OS | Windows Server 2025 × 2 台（IIS 構成共有クラスター用） |
| Web サーバー | IIS（共有構成機能を使用） |
| 構成ストア | Azure Storage のファイル共有（Azure Files / SMB） |
| 共有パス | \\<storageaccount>.file.core.windows.net\<share>\IISConfig |
| 検証結果 | Ubuntu + Samba 共有では IIS 共有構成が問題なく動作 |
発生していた症状
- Windows Server からはエクスプローラーや
net useコマンドで Azure Files に読み書き可能。 - しかし IIS マネージャーの「共有構成」で同じ UNC パスを指定してもエラーになり、有効化できない。
- Microsoft の公式ドキュメントやナレッジの手順どおりに設定しているつもりでも、接続テストが失敗する。
- 同じ IIS サーバーから Linux + Samba 共有を指定した場合は問題なく共有構成が有効化できる。
つまり、ネットワークや SMB 全体が壊れているわけではなく、Azure Files を共有構成ストアとして使うときにだけ失敗している状態です。
結論：原因は「IIS 共有構成の資格情報設定ミス」
最終的に明らかになった原因は、とてもシンプルです。
- OS から Azure Files につなぐときに使っている資格情報（アカウント / アクセスキー）と、
- IIS マネージャーの「共有構成」に登録した資格情報
が 一致していなかった ことが原因でした。
Azure Files 側やネットワーク側の問題ではなく、IIS の共有構成ダイアログに入力した認証情報だけが間違っていた、という非常にヒューマンエラー寄りのトラブルです。
逆に言うと、正しい資格情報を再設定し、［テスト接続］で成功する状態にしてから暗号化キーを出力・インポートし直すことで、問題は解消されました。
なぜ OS からは見えるのに IIS 共有構成だけ失敗するのか
「同じサーバーから Azure Files にアクセスできているのに、なぜ IIS だけダメなの？」という疑問は当然です。ここを理解しておくと、今後のトラブルシュートがぐっと楽になります。
IIS 共有構成の仕組みをざっくりおさらい
IIS の「共有構成」は、複数サーバーで同じ applicationHost.config 等を参照するための仕組みです。共有構成を有効にすると、各サーバーの IIS は次のような動きをします。
- ローカルではなく、指定した UNC パス上の構成ファイルを参照する。
- その UNC パスへのアクセスには、「共有構成」で指定した資格情報 が使われる。
- ローカルで誰がログオンしているか（管理者がどんなアカウントで操作しているか）は基本的に関係ない。
つまり、OS レベルでマウント済みの資格情報と、IIS が内部的に使う資格情報は別物です。
Azure Files 側の認証方式
Azure ファイル共有（Azure Files）には、複数の認証パターンがあります。共有構成で使うときに主に関係するのは次の 2 つです。
| 方式 | 概要 | IIS 共有構成での指定例 |
|---|---|---|
| ストレージ アカウント キー方式 | Azure Storage アカウントに対して、アカウント名＋アクセスキーで認証する最もシンプルな方式。 | ユーザー名：Azure\<ストレージアカウント名> パスワード：アクセスキー（キー1 or キー2） |
| AD DS / Azure AD DS 統合（Kerberos） | オンプレ AD や Azure AD DS と連携し、ドメインアカウントで SMB にアクセスする方式。 | ユーザー名：<ドメイン>\<ユーザー> パスワード：ドメインユーザーのパスワード |
OS レベルでは net use でどちらの方式でも接続できますが、IIS の共有構成ダイアログにも、まったく同じ認証方式／資格情報を指定する必要があります。
よくあるミスマッチのパターン
- OS からは
net use \\account.file.core.windows.net\share /user:Azure\account <アクセスキー>で接続しているのに、- IIS の共有構成では、別のアカウント名や誤ったキーを入力している。
- ユーザー名を
Azure/<account>とスラッシュで書いてしまうなど、表記ミスをしている。
- Azure Files を AD 連携済みなのに、依然としてストレージアカウントキー方式で接続しようとしている。
- アクセスキーをローテーションしたあと、OS 側の
net useは更新したが、IIS 共有構成の資格情報を更新し忘れている。
このように、OS と IIS で違う資格情報が使われていると、「OS からは見えるのに IIS は失敗する」という現象が簡単に起きます。
Azure Files を IIS 共有構成ストアとして正しく構成する手順
ここからは、Azure ファイル共有を IIS の共有構成ストアとして使うための具体的な手順を整理します。ポイントだけを追えば、難しい操作ではありません。
1. UNC パスを FQDN で指定する
まずは共有構成ストアのパスの指定です。IIS の共有構成では、必ず UNC（FQDN）パスを指定します。
- 正：
\\<storageaccount>.file.core.windows.net\<share>\IISConfig - 誤：
Z:\IISConfig（ドライブ文字指定）
Azure Files のストレージアカウント名は小文字である必要があるため、大文字・小文字の打ち間違いにも注意しましょう。
また、末尾のバックスラッシュをうっかり入れてしまうと別のパスと認識されることがあるため、
\\account.file.core.windows.net\share\IISConfig
のように、最後はフォルダ名で終わる形にしておくのが安全です。
2. IIS マネージャーから正しい資格情報を登録する
次に、IIS 共有構成で使用する資格情報を設定します。ここが今回のトラブルの本丸です。
手順の流れ
- IIS マネージャーを起動する。
- 左ペインでサーバー名を選択する。
- 中央の機能ビューから「共有構成」をダブルクリックする。
- 「共有構成を有効にする」にチェックを付ける。
- 「共通構成ファイルの場所」に、先ほどの UNC パスを入力する。
- [資格情報…] ボタンをクリックし、Azure Files にアクセス可能なアカウントを入力する。
- [テスト接続] をクリックし、成功することを確認する。
ストレージ アカウント キー方式の設定例
Azure Files に対して最もよく使われる方式です。
| 項目 | 入力例 |
|---|---|
| ユーザー名 | Azure\mystorageaccount |
| パスワード | ストレージアカウントのアクセスキー（キー1 or キー2） |
OS レベルでの動作確認として、以下のようなコマンドが成功するかをチェックすると安心です。
net use \\mystorageaccount.file.core.windows.net\myshare /user:Azure\mystorageaccount <アクセスキー>
この net use で成功したときと同じユーザー名・同じキーを、「共有構成」の［資格情報…］に入力してください。
AD / Kerberos 方式を採用している場合
Azure Files を AD DS や Azure AD DS と統合している場合は、ドメインアカウントで接続できます。このときは、IIS 共有構成にも同じドメインアカウントを指定します。
| 項目 | 入力例 |
|---|---|
| ユーザー名 | CONTOSO\iisconfigsvc |
| パスワード | サービスアカウント iisconfigsvc のパスワード |
この場合も、事前に OS レベルで次のようなコマンドが成功することを確認しておきましょう。
net use \\mystorageaccount.file.core.windows.net\myshare /user:CONTOSO\iisconfigsvc <パスワード>
ポイントは「OS から成功する net use と、IIS 共有構成の資格情報が 1 文字も違わないこと」です。
3. 暗号化キーをエクスポート／インポートする
IIS の共有構成では、構成ファイル内に暗号化されているセクション（接続文字列など）を扱うために、暗号化キー（マシンキー）を共通化する必要があります。
手順の全体像は次のとおりです。
1 台目（マスター）サーバーでの作業
- 前述の手順で共有構成を有効化する。
- 「暗号化キーのエクスポート」ボタンをクリックする。
- Azure Files 上の共有フォルダ（例：
\\account.file.core.windows.net\share\IISConfig）にキーを保存する。 - パスフレーズを設定し、忘れないよう安全な場所に保管しておく。
このとき保存されるのは、IIS 構成の暗号化に使われるキー情報であり、他の Web サーバーも同じキーを使うことで、暗号化セクションを正しく復号できるようになります。
2 台目以降のサーバーでの作業
- IIS マネージャーを開き、「共有構成」を開く。
- 「共有構成を有効にする」にチェックを入れ、1 台目と同じ UNC パスを指定する。
- [資格情報…] で、1 台目と同じ Azure Files の資格情報を入力し、[テスト接続] を実行して成功を確認する。
- 「暗号化キーのインポート」ボタンをクリックする。
- 1 台目が保存したキーのファイルを指定し、同じパスフレーズを入力する。
- OK を押し、共有構成を有効化する。
ここでパスフレーズを間違えると暗号化セクションの復号に失敗し、アプリケーションによっては動作不良の原因になるので注意しましょう。
4. 全ノードで設定を統一し、IIS サービスを再起動する
最後に、全ての Web サーバーで次の点を揃えたうえで、IIS を再起動します。
- 共有構成の UNC パスが全ノードで完全一致している。
- 共有構成の資格情報が全ノードで完全一致している。
- 暗号化キーが同じファイルからインポートされている（同じパスフレーズを使っている）。
設定反映のために、次のコマンドで IIS を再起動しておきましょう。
iisreset
これで、Azure Files 上の構成ストアを複数の IIS サーバーから共有できる状態になります。
構成時にハマりやすいポイントとチェックリスト
今回のようなトラブルを防ぐために、よくあるハマりどころをチェックリスト形式でまとめます。
ネットワークまわりのチェック
| 項目 | 確認内容 |
|---|---|
| TCP 445 の開放 | オンプレミス側のファイアウォールで、Azure Files への送信 TCP 445（SMB）が許可されているか。 |
| ストレージアカウントのネットワーク制限 | Azure Storage アカウントのネットワーク設定で、対象サーバーからのアクセスが許可されているか（パブリックアクセス制御、仮想ネットワーク統合など）。 |
| DNS 解決 | ping <storageaccount>.file.core.windows.net などで名前解決ができるか。 |
権限設定のチェック
- Azure Files の共有レベル権限
- IIS 共有構成で使用するアカウントに、少なくとも「読み取り＋書き込み」権限があるか。
- 構成ファイルの書き戻しや暗号化キーの保存に書き込みが必要になるため、読み取り専用だと不具合の原因になる。
- NTFS 権限（ディレクトリレベル）
IISConfig配下に対しても同様に「読み取り＋書き込み」を付与する。- 最初の検証段階では、問題切り分けのためにフルコントロールで試してもよい。
認証方式と資格情報の整合性
もっとも重要なポイントがここです。以下の 3 つを必ず揃えましょう。
| 項目 | OS（net use） | IIS 共有構成 |
|---|---|---|
| ユーザー名 | Azure\mystorageaccount など | 同じ表記で入力されているか（大文字小文字、バックスラッシュの有無も含めて完全一致） |
| パスワード | アクセスキー、またはドメインアカウントのパスワード | 同じキー／パスワードが入力されているか |
| 認証方式 | アカウントキー方式 or AD 方式 | OS と同じ方式になっているか |
「OS ではドメインアカウントでマウントしているのに、IIS 共有構成ではストレージアカウント名＋アクセスキーでアクセスしようとしている」といった混在は避けてください。
パス表記とタイプミス
単純ですが、意外と多いのがパスのタイプミスです。
- ストレージアカウント名は小文字で指定する。
file.core.windows.netのスペルを間違えていないか。- 共有名、サブフォルダ名の綴りが正しいか。
- 末尾に余分なバックスラッシュを入れていないか。
パスは一度メモ帳などで書いてからコピーペーストすると、タイプミスを減らせます。
アクセスキーのローテーションと IIS 設定の更新
セキュリティの観点から、Azure Storage のアクセスキーは定期的なローテーションが推奨されています。ただし、キーを回転させたあとは次の点を忘れないでください。
- OS レベルでの
net useに使っているキーを更新する。 - IIS 共有構成の［資格情報…］に設定しているパスワードも必ず新しいキーに更新する。
- 可能であれば、キー1 / キー2 を交互に使うローリング方式で、ダウンタイムなく更新する。
片方だけキーを更新すると、「OS は新キーで、IIS は旧キーのまま」という状態になり、今回と同じような現象が再発します。
ログによるトラブルシュート
もし共有構成の有効化がうまくいかない場合は、イベントログを確認すると原因特定の手がかりが得られます。
- Microsoft-Web-Administration ログ
- IIS の管理操作や構成読み込みに関するイベントが出力される。
- 共有構成ストアにアクセスできない場合は、その旨のエラーが出力されることが多い。
- SMBClient ログ
- SMB プロトコルレベルでの通信状況を確認するのに役立つ。
- 認証エラーやアクセス拒否など、Azure Files 側からの応答が分かる場合がある。
エラーコードが分かれば、Azure 側のログやドキュメントと突き合わせて、ネットワーク／認証／権限のどこで失敗しているかを絞り込むことができます。
運用とセキュリティのベストプラクティス
最後に、Azure Files を IIS 共有構成ストアとして運用するときに、意識しておきたいポイントをまとめます。
専用のサービスアカウントを用意する
AD 方式で接続する場合は、次のような方針を取ると運用が整理しやすくなります。
- IIS 共有構成専用のサービスアカウント（例：
CONTOSO\svc_iisconfig）を作成する。 - Azure Files 側では、そのアカウントに最小限の権限（共有構成ストアへのフルコントロール）だけを付与する。
- 他の用途とは切り離し、「このアカウントを変えたら IIS の共有構成に影響が出る」と分かるようにしておく。
アクセス許可は最小権限の原則で
検証フェーズでは問題切り分けのためにフルコントロールを付けるのは有効ですが、本番運用では次のように絞り込みましょう。
- 共有構成ストア用の Azure Files 共有には、IIS 構成に必要なアカウントのみアクセス可能にする。
- 他のアプリケーションやユーザーのアクセスを分離したい場合は、共有自体を分ける。
- Azure RBAC（ロールベースアクセス制御）とも組み合わせて、ストレージアカウント全体の管理権限を最小限にする。
変更手順をドキュメント化しておく
共同運用の現場では、「誰かがストレージキーをローテーションした」「誰かが Azure Files の権限を変えた」ことをきっかけに、IIS の共有構成が突然おかしくなることがあります。
- アクセスキーや権限に変更を加えるときの手順書を用意する。
- 「変更後は必ず IIS 共有構成の接続テストを行う」などのチェックポイントを明記する。
- 共有構成ストアの UNC パスと資格情報を、セキュアな場所に控えておく。
こうした小さな工夫が、将来的な障害対応コストを大きく下げてくれます。
まとめ：IIS 共有構成と Azure Files のポイント整理
本記事では、Azure ファイル共有（Azure Files）を IIS の共有構成ストアとして利用した際に、OS からはアクセスできるのに IIS だけ失敗するという問題と、その解決方法を整理しました。
- 問題の本質は、IIS 共有構成で指定している資格情報が誤っていたこと。
- OS から Azure Files へは正常にアクセスできていても、IIS は「共有構成」で設定した資格情報だけを使って接続するため、そこが間違っていると失敗する。
- 対処のポイントは次の通り。
- UNC パスを FQDN（
\\<account>.file.core.windows.net\<share>\IISConfig）で指定する。 - OS で成功している
net useと同じ資格情報を、IIS の［資格情報…］にも正確に設定する。 - 暗号化キーを 1 台目でエクスポートし、他ノードでインポートして暗号化セクションを共通化する。
- 全ノードで設定をそろえたうえで IIS を再起動する。
- UNC パスを FQDN（
- あわせて、TCP 445 の開放、ストレージアカウントのネットワーク制限、Azure Files の共有／NTFS 権限、アクセスキーのローテーションなどもチェックしておくと安心。
Azure Files は、IaaS / PaaS を問わず Windows ワークロードの構成共有に非常に便利なストレージサービスです。今回のような資格情報のミスさえ避ければ、Windows Server 2025 + IIS 環境でも安定した共有構成ストアとして活用できます。構成のポイントを押さえたうえで、本番環境に適用してみてください。
コメント