Introduction

La tâche est donc assez simple : une application web hébergée sur IIS doit stocker des fichiers utilisateurs, puis les servir ensuite en HTTP ou HTTPS. Par exemple, elle peut enregistrer des documents PDF, puis les ouvrir plus tard via un lien dans le navigateur.

Le moyen le plus simple consiste à stocker ces fichiers sur le disque local du serveur, par exemple dans C:\Files. Cela fonctionne effectivement, et pour certains systèmes cela peut suffire. Mais comme solution pérenne, cela reste fragile. Le disque local d'une machine virtuelle n'est pas l'endroit idéal sur lequel on souhaite s'appuyer pour un stockage de fichiers à long terme.

À l'inverse, lorsqu'on parle de stockage de fichiers dans Azure, on pense le plus souvent à Blob Storage. C'est logique, mais ce n'est pas toujours pratique, en particulier dans les migrations lift-and-shift. Très souvent, l'application et IIS s'attendent à retrouver un système de fichiers Windows classique, et Azure Files répond justement très bien à ce besoin. On continue à travailler avec des dossiers et des chemins, mais les fichiers eux-mêmes ne dépendent plus d'un hôte particulier.

Définition du besoin

À première vue, tout semble simple : on crée un Azure Storage Account et un File Share, on connecte le partage à Windows Server, puis on demande à IIS de servir les fichiers depuis ce dossier.

En pratique, la solution casse presque immédiatement à plusieurs endroits.

1. Azure Files en SMB exige que le port 445 soit accessible. S'il est bloqué par une politique réseau ou par un firewall, la connexion échouera dès la première étape.
2. Même si l'administrateur a réussi à monter le partage sous forme de disque Z:, cela ne signifie pas qu'IIS pourra le lire. Ce qui est visible pour un utilisateur ne l'est pas forcément pour le processus IIS.
3. IIS fonctionne par défaut sous ApplicationPoolIdentity ou sous un autre compte de service. Pour cette identité, une ressource réseau montée manuellement dans la session de l'administrateur n'existe souvent tout simplement pas.

Idée générale de la solution

Dans sa forme générale, le schéma fonctionnel ressemble à ceci :

• Créer un Azure Storage Account et un File Share.
• Vérifier que Windows Server peut réellement joindre Azure Files en SMB.
• Monter le File Share sur le serveur ou, au minimum, vérifier qu'il est accessible via son chemin UNC.
• Créer dans IIS un répertoire virtuel pointant vers le chemin UNC de l'Azure File Share.
• Configurer les identifiants avec lesquels IIS lira ce dossier réseau.
• Vérifier que les fichiers sont effectivement accessibles via une URL.

Mise en place pratique

Voyons maintenant cela dans la pratique. Il est d'abord utile de vérifier que le serveur voit bien Azure Files en SMB. Ensuite, nous monterons le partage, nous configurerons le chemin UNC dans IIS et nous traiterons séparément la question la plus sensible : sous quel compte le site accédera-t-il au dossier réseau ?

Étape 1. Vérifier l'accessibilité d'Azure Files en SMB

Pour cela, il est pratique d'utiliser la commande que le portail Azure propose généralement lui-même lors de la connexion à un File Share :

Dans sa forme générale, le schéma fonctionnel ressemble à ceci :

• Créer un Azure Storage Account et un File Share.
• Vérifier que Windows Server peut réellement joindre Azure Files en SMB.
• Monter le File Share sur le serveur ou, au minimum, vérifier qu’il est accessible via son chemin UNC.
• Créer dans IIS un répertoire virtuel pointant vers le chemin UNC de l’Azure File Share.
• Configurer les identifiants avec lesquels IIS lira ce dossier réseau.
• Vérifier que les fichiers sont effectivement accessibles via une URL.

Mise en place pratique

Voyons maintenant cela dans la pratique. Il est d’abord utile de vérifier que le serveur voit bien Azure Files en SMB. Ensuite, nous monterons le partage, nous configurerons le chemin UNC dans IIS et nous traiterons séparément la question la plus sensible : sous quel compte le site accédera-t-il au dossier réseau ?

Étape 1. Vérifier l’accessibilité d’Azure Files en SMB

Pour cela, il est pratique d’utiliser la commande que le portail Azure propose généralement lui-même lors de la connexion à un 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." }

Si ce test échoue, le problème vient de l’accès réseau. Il s’agit généralement d’un firewall, d’un NSG, d’un proxy, d’une politique d’entreprise ou d’une restriction du fournisseur d’accès sur le port 445.

Étape 2. Connecter l’Azure File Share à Windows Server

Si le Storage Account et le File Share sont déjà créés, le moyen le plus rapide d’obtenir la commande de connexion consiste à ouvrir le File Share dans le portail Azure et à sélectionner Connect. Le portail affiche alors un script PowerShell prêt à l’emploi. Il ressemble généralement à ceci :

$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." }

Après cela, un disque réseau apparaît sur le serveur, par exemple Z:\. Il est pratique pour une première validation : ouvrir le partage dans l’Explorateur, créer un dossier de test ou y déposer un PDF de test. Mais il y a ici une précision pratique importante. Pour IIS, je ne construirais pas la solution autour d’une lettre de lecteur. Le disque monté Z:\ est utile pour la validation, mais dans la configuration IIS elle-même, il vaut mieux viser directement le chemin UNC :

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

C’est généralement ce qui évite une bonne partie de la confusion où l’administrateur voit le partage, mais pas IIS.

Nous devons maintenant indiquer à IIS d’où il doit servir les fichiers. Pour cela, on crée un répertoire virtuel sur le site concerné. Par exemple :

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

Ensuite, l’URL d’un fichier ressemblera à ceci :

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

D’un point de vue technique, cela représente déjà presque tout le schéma. Mais en pratique, c’est généralement à cette étape que surgit le principal problème : IIS ne parvient pas à lire le chemin réseau.

Pourquoi un disque mappé ne suffit pas

C’est le point clé de tout l’article. Lorsque vous connectez un Azure File Share via New-PSDrive -Persist ou via l’Explorateur, vous le faites dans le contexte d’un utilisateur donné. En général, il s’agit de l’administrateur actuellement connecté au serveur. IIS, lui, ne s’exécute pas sous cet utilisateur. Par défaut, l’application fonctionne généralement sous ApplicationPoolIdentity, c’est-à-dire sous une identité de service distincte, par exemple :

IIS AppPool\MyApplicationPool

On se retrouve alors dans la situation classique : tout est visible dans l’Explorateur, mais via le site on obtient une erreur 401, 500 ou une erreur d’accès au chemin physique du répertoire virtuel. C’est pour cela que, pour les ressources réseau dans IIS, deux approches fonctionnent généralement :

• Indiquer un chemin UNC et configurer Connect as... avec un utilisateur spécifique.
• Ou exécuter l’application pool sous un compte distinct dans le contexte duquel les identifiants d’accès à Azure Files sont enregistrés.

Ici, je vais suivre la première option. Pour la migration d’une application existante, c’est généralement la plus efficace : le modèle de gestion des fichiers change très peu, et l’essentiel des difficultés se résume au chemin UNC, aux droits et au compte sous lequel IIS accède réellement au partage.

Étape 4. Configurer un utilisateur pour accéder à l’Azure File Share

Une option pratique consiste à créer sur la machine virtuelle un utilisateur local distinct que IIS utilisera pour accéder au dossier réseau. Par exemple :

iis-files-user

On peut le créer via Computer Management, ou avec 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"

Ensuite, cet utilisateur doit disposer des identifiants nécessaires pour accéder à l’Azure File Share. Si vous utilisez la clé du Storage Account, ces identifiants sont généralement enregistrés avec cmdkey : cmdkey /add:mystorageaccount.file.core.windows.net /user:localhost\mystorageaccount /pass:storage-account-key

Étape 5. Indiquer l’utilisateur dans le répertoire virtuel IIS

Revenons maintenant à IIS Manager :

• Ouvrez le répertoire virtuel créé, par exemple files.
• Sélectionnez Basic Settings...
• Cliquez sur Connect as...
• Choisissez Specific user.
• Indiquez l’utilisateur, par exemple .\iis-files-user ou SERVERNAME\iis-files-user.
• Saisissez le mot de passe.

Ensuite, il est utile de cliquer sur Test Settings.... Si tout est correctement configuré, IIS indiquera que l’accès au chemin physique a été validé avec succès. Il est important de ne pas se tromper sur le rôle de cet utilisateur. Il ne sert pas à authentifier les utilisateurs finaux du site, mais uniquement à permettre à IIS lui-même de lire les fichiers du dossier réseau.

Étape 6. Vérifier que les fichiers s’ouvrent réellement

Une fois la configuration terminée, vous pouvez déposer un fichier de test dans le partage, par exemple :

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

Si le répertoire virtuel pointe vers le dossier documents, le fichier devrait être accessible via une URL de ce type :

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

À ce stade, je vérifierais immédiatement plusieurs scénarios :

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

Si les fichiers s’ouvrent, cela signifie qu’IIS a bien obtenu l’accès à l’Azure File Share et qu’il peut servir son contenu aux utilisateurs via HTTP ou HTTPS. Objectif atteint.

Conclusion

Il est possible de stocker les fichiers utilisateurs sur le disque local d’une machine virtuelle exécutant IIS, mais dès que le serveur commence à être recréé, déplacé ou simplement maintenu, cette solution montre rapidement ses limites. Azure Files permet de sortir les fichiers de la VM elle-même sans casser le modèle de fonctionnement habituel d’une application Windows : vérifier le port 445, connecter le File Share, créer un répertoire virtuel, indiquer le chemin UNC, configurer Connect as..., et voilà — les fichiers deviennent accessibles via des requêtes HTTP.

Liens utiles

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