Questions fréquentes (FAQ) sur Azure Files

  • Article

Azure Files offre des partages de fichiers pleinement managés dans le cloud qui sont accessibles via le protocole SMB (Server Message Block) standard et le protocole NFS (Network File System) Vous pouvez monter des partages de fichiers Azure simultanément sur des déploiements cloud ou locaux de Windows, Linux et macOS. Vous pouvez également mettre en cache des partages de fichiers Azure sur des ordinateurs Windows Server à l’aide d’Azure File Sync pour bénéficier d’un accès rapide proche de l’endroit où les données sont utilisées.

Azure File Sync

  • Un même groupe de synchronisation peut-il contenir des serveurs joints à un domaine et des serveurs non joints à un domaine ?
    Oui. Un groupe de synchronisation peut contenir des points de terminaison de serveur qui ont des appartenances Active Directory différentes, même s’ils ne sont pas joints à un domaine. Bien que cette configuration fonctionne sur le plan technique, nous la déconseillons comme configuration standard, car les listes de contrôle d’accès (ACL, Access Control Lists) définies pour les fichiers et dossiers sur un serveur peuvent ne pas pouvoir être appliquées par d’autres serveurs dans le groupe de synchronisation. Pour de meilleurs résultats, nous vous recommandons d’effectuer une synchronisation entre les serveurs qui sont dans la même forêt Active Directory, entre les serveurs qui sont dans des forêts Active Directory différentes mais qui ont des relations d’approbation établies, ou entre les serveurs qui ne sont pas dans un domaine. Nous vous déconseillons d’utiliser une combinaison de ces configurations.

  • Après avoir créé un fichier directement dans mon partage de fichiers Azure via SMB ou dans le portail. Combien de temps faut-il pour synchroniser le fichier sur les serveurs du groupe de synchronisation ?

    Les modifications apportées au partage de fichiers Azure avec le portail Azure ou SMB ne sont pas immédiatement détectées et répliquées comme le sont des modifications apportées au point de terminaison de serveur. Azure Files n’a pas encore de notifications ou journalisation des modifications. Il n’existe donc aucun moyen de lancer automatiquement une session de synchronisation lorsque des fichiers sont modifiés. Sur Windows Server, Azure File Sync utilise la journalisation du nombre de séquences de mise à jour de Windows pour lancer automatiquement une session de synchronisation quand des fichiers changent.

    Pour détecter les modifications apportées au partage de fichiers Azure, Azure File Sync a une tâche planifiée appelée tâche de détection des modifications. Une tâche de détection des modifications énumère tous les fichiers inclus dans le partage de fichiers, puis les compare à la version de synchronisation de ces fichiers. Lorsque la tâche de détection des modifications détermine que des fichiers ont changé, Azure File Sync lance une session de synchronisation. La tâche de détection des modifications est lancée toutes les 24 heures. Étant donné que la tâche de détection des modifications fonctionne en énumérant chaque fichier dans le partage de fichiers Azure, elle prend plus de temps dans les espaces de noms de grande taille que dans les plus petits. Pour des espaces de noms de grande taille, plus de 24 heures peuvent être nécessaires pour déterminer les fichiers qui ont été modifiés.

    Pour synchroniser immédiatement les fichiers qui ont été modifiés dans le partage de fichiers Azure, le cmdlet PowerShell Invoke-AzStorageSyncChangeDetection permet de lancer manuellement la détection des modifications apportées au partage de fichiers Azure. Cette cmdlet est destinée aux scénarios dans lesquels un certain type de processus automatisé apporte des modifications au partage de fichiers Azure ou dans lesquels les modifications sont apportées par un administrateur (comme le déplacement de fichiers et de répertoires dans le partage). Pour les changements d’utilisateurs finaux, il est recommandé d’installer l’agent Azure File Sync dans une machine virtuelle IaaS et de demander aux utilisateurs finaux d’accéder au partage de fichiers via la machine virtuelle IaaS. Ainsi, toutes les modifications sont rapidement synchronisées avec d’autres agents, sans qu’il soit nécessaire d’utiliser la cmdlet Invoke-AzStorageSyncChangeDetection. Pour plus d’informations, consultez la documentation Invoke-AzStorageSyncChangeDetection.

    Nous étudions la possibilité d’ajouter la détection des modifications pour un partage de fichiers Azure de la même façon que le nombre de séquences de mise à jour (USN) pour les volumes sur Windows Server. Aidez-nous à faire passer le développement de cette fonctionnalité en priorité en votant pour celle-ci via la page Commentaires de la communauté Azure.

  • Si le même fichier est modifié sur deux serveurs à peu près au même moment, que se passe-t-il ?
    Des conflits de fichiers se produisent quand le fichier dans le partage de fichiers Azure ne correspond pas au fichier à l’emplacement du point de terminaison du serveur (la taille et/ou l’heure de dernière modification sont différentes).

    Les scénarios suivants peuvent entraîner des conflits de fichiers :

    • Un fichier est créé ou modifié dans un point de terminaison (par exemple, Serveur A). Si le même fichier est modifié sur un autre point de terminaison avant que la modification sur le serveur A ne soit synchronisée avec ce point de terminaison, un fichier de conflit est créé.
    • Le fichier existait dans le partage de fichiers Azure et à l’emplacement du point de terminaison du serveur avant la création du point de terminaison du serveur. Si la taille et/ou l’heure de dernière modification du fichier sont différentes entre le fichier sur le serveur et sur le partage de fichiers Azure quand le point de terminaison du serveur est créé, un fichier de conflit est créé.
    • La base de données de synchronisation a été recréée en raison d’une altération ou d’une limite de connaissances atteinte. Une fois la base de données recréée, la synchronisation passe en mode de rapprochement. Si la taille et/ou l’heure de dernière modification du fichier sont différentes entre le fichier sur le serveur et sur le partage de fichiers Azure lors du rapprochement, un fichier de conflit est créé.

    Azure File Sync utilise une stratégie de résolution de conflit simple : nous conservons les modifications apportées aux fichiers modifiés dans deux points de terminaison en même temps. Le fichier le plus récemment écrit conserve son nom d’origine. L’ancien fichier (déterminé par LastWriteTime) a le nom du point de terminaison et le numéro de conflit ajoutés au nom de fichier. Pour les points de terminaison de serveur, le nom du point de terminaison est le nom du serveur. Pour les points de terminaison cloud, le nom du point de terminaison est Cloud. La taxonomie du nom est la suivante :

    <FileNameWithoutExtension>-<endpointName>[-#].<ext>

    Par exemple, le premier conflit de CompanyReport.docx deviendra CompanyReport-CentralServer.docx si CentralServer est l’endroit où l’écriture la plus ancienne s’est produite. Le deuxième conflit sera nommé CompanyReport-CentralServer-1.docx. Azure File Sync prend en charge 100 fichiers conflictuels par fichier. Une fois le nombre maximal de fichiers conflictuels atteint, la synchronisation du fichier échoue. Pour qu’elle aboutisse, le nombre de fichiers conflictuels doit être inférieur à 100.

  • La hiérarchisation cloud est désactivée. Pourquoi y a-t-il des fichiers hiérarchisés à l’emplacement du point de terminaison de serveur ?
    Il existe deux raisons pour lesquelles des fichiers hiérarchisés peuvent se trouver à l’emplacement du point de terminaison de serveur :

    • Lorsque vous ajoutez un nouveau point de terminaison de serveur à un groupe de synchronisation existant, si vous choisissez l’option rappeler l’espace de noms ou rappeler l’espace de noms uniquement pour le mode de téléchargement initial, les fichiers s’affichent comme étant hiérarchisés jusqu’à ce qu’ils soient téléchargés localement. Pour éviter cela, sélectionnez l’option Éviter les fichiers hiérarchisés pour le mode de téléchargement initial. Pour rappeler manuellement des fichiers, utilisez la cmdlet Invoke-StorageSyncFileRecall.

    • Si la hiérarchisation cloud a été activée sur le point de terminaison de serveur, puis désactivée, les fichiers restent hiérarchisés jusqu’à ce qu’ils soient accessibles.

  • Pourquoi mes fichiers hiérarchisés n’affichent-ils pas de miniatures ou d’aperçus dans l’Explorateur de fichiers Windows ?
    Pour les fichiers hiérarchisés, les miniatures et aperçus ne sont pas visibles au niveau de votre point de terminaison de serveur. Ce comportement est attendu car la fonctionnalité de cache des miniatures dans Windows ignore intentionnellement la lecture des fichiers avec l’attribut Hors connexion. En cas d'activation de la hiérarchisation cloud, la lecture des fichiers hiérarchisés entraînerait leur téléchargement (rappel).

    Ce comportement n’est pas propre à Azure File Sync. L’Explorateur de fichiers Windows affiche une « croix grise » pour tous les fichiers dont l’attribut Hors connexion est activé. L’icône X s’affiche lors de l’accès aux fichiers sur SMB. Pour obtenir une explication détaillée de ce comportement, reportez-vous à Pourquoi je n’obtiens pas de miniatures pour les fichiers qui sont marqués hors connexion ?

    Pour plus d’informations sur la gestion des fichiers hiérarchisés, consultez Comment gérer des fichiers hiérarchisés.

  • Pourquoi des fichiers hiérarchisés existent-ils en dehors de l’espace de noms du point de terminaison de serveur ?
    Avant la version 3 de l’agent Azure File Sync, Azure File Sync bloquait le déplacement des fichiers hiérarchisés à l’extérieur du point de terminaison du serveur, mais sur le même volume que le point de terminaison du serveur. Les opérations de copie, les déplacements de fichiers non hiérarchisés et les déplacements de fichiers hiérarchisés vers d’autres volumes n’étaient pas concernés. Ce comportement était dû au fait que l’Explorateur de fichiers et les autres API Windows supposent de manière implicite que les opérations de déplacement sur un même volume sont des opérations de changement de nom (presque) instantanées. Cela signifie que les déplacements donneront l’impression que l’Explorateur de fichiers ou d’autres méthodes de déplacement (par exemple, la ligne de commande ou PowerShell) ne répondent plus pendant qu’Azure File Sync rappelle les données à partir du cloud. À partir de la version 3.0.12.0 de l’agent Azure File Sync, Azure File Sync vous permettra de déplacer un fichier hiérarchisé en dehors du point de terminaison du serveur. Nous évitons ainsi les effets négatifs mentionnés précédemment en autorisant l’existence du fichier hiérarchisé sous la forme d’un fichier hiérarchisé en dehors du point de terminaison du serveur, puis en rappelant le fichier en arrière-plan. Cela signifie que les déplacements sur un même volume sont instantanés, et que nous faisons tout le travail visant à rappeler le fichier sur le disque une fois le déplacement terminé.

  • Je rencontre un problème avec Azure File Sync sur mon serveur (synchronisation, hiérarchisation, etc.). Dois-je supprimer et recréer mon point de terminaison de serveur ?

    Non, supprimer un point de terminaison de serveur et redémarrer un serveur ne reviennent pas au même ! Le fait de supprimer et de recréer le point de terminaison de serveur n’est presque jamais une solution appropriée pour résoudre les problèmes de synchronisation, de hiérarchisation cloud ou d’autres aspects d’Azure File Sync. La suppression d’un point de terminaison de serveur est une opération destructrice. Cela peut entraîner une perte de données dans le cas où des fichiers hiérarchisés existent en dehors de l’espace de noms du point de terminaison de serveur. Pour obtenir davantage d’informations, consultez Pourquoi les fichiers hiérarchisés existent-ils en dehors de l’espace de noms du point de terminaison du serveur ?. Cela peut également provoquer des fichiers inaccessibles pour les fichiers hiérarchisés existant dans l’espace de noms du point de terminaison de serveur. Ces problèmes ne sont pas résolus par la recréation du point de terminaison. Des fichiers hiérarchisés peuvent exister dans l’espace de noms du point de terminaison de votre serveur même si la hiérarchisation cloud n’a jamais été activée. C’est pourquoi nous vous recommandons de ne pas supprimer le point de terminaison du serveur, sauf si vous souhaitez cesser d’utiliser Azure File Sync avec ce dossier particulier ou si un ingénieur Microsoft vous a expressément demandé de le faire. Pour plus d’informations sur la suppression de points de terminaison de serveur, consultez Supprimer un point de terminaison de serveur.

  • Puis-je déplacer le service de synchronisation de stockage et/ou le compte de stockage vers un groupe de ressources, un abonnement ou un locataire Microsoft Entra différents ?
    Oui, vous pouvez déplacer le service de synchronisation de stockage et/ou le compte de stockage vers un groupe de ressources, un abonnement ou un locataire Microsoft Entra différent. Après avoir déplacé le service de synchronisation de stockage ou le compte de stockage, vous devez donner à l’application Microsoft.StorageSync l’accès au compte de stockage. Procédez comme suit :

    1. Connectez-vous au portail Azure et sélectionnez Contrôle d’accès (IAM) dans le volet de navigation de gauche.

    2. Sélectionnez l’onglet Attributions de rôle pour dresser la liste des utilisateurs et des applications (principaux de service) ayant accès à votre compte de stockage.

    3. Vérifiez que Microsoft.StorageSync ou Hybrid File Sync Service (ancien nom de l’application) apparaît dans la liste avec le rôle Lecteur et accès aux données.

      Si Microsoft.StorageSync ou Hybrid File Sync Service n’apparaît pas dans la liste, effectuez les étapes suivantes :

      • Sélectionnez Ajouter.
      • Dans le champ Rôle, sélectionnez Lecteur et accès aux données.
      • Dans le champ Sélectionner, tapez Microsoft.StorageSync, sélectionnez le rôle, puis Enregistrer.

      Remarque

      Lors de la création du point de terminaison cloud, le service de synchronisation du stockage et le compte de stockage doivent se trouver dans le même locataire Microsoft Entra. Une fois le point de terminaison cloud créé, le service de synchronisation du stockage et le compte de stockage peuvent être déplacés vers des locataires Microsoft Entra différents.

  • Azure File Sync conserve-t-il les listes de contrôle d’accès NTFS de niveau répertoire/fichier en plus des données stockées dans Azure Files ?

    À compter du 24 février 2020, les listes de contrôle d’accès (ACL, access-control list) nouvelles et existantes hiérarchisées par Azure File Sync sont conservées au format NTFS, et les modifications apportées aux ACL directement dans le partage de fichiers Azure sont synchronisées avec tous les serveurs du groupe de synchronisation. Toutes les modifications apportées aux ACL dans partages de fichiers Azure sont synchronisées via Azure File Sync. Lorsque vous copiez des données vers Azure Files, veillez à utiliser un outil de copie qui offre la « fidélité » nécessaire pour copier des attributs, des timestamps et des listes de contrôle d’accès dans un partage de fichiers Azure via le protocole SMB ou REST. Quand vous utilisez des outils de copie Azure tels qu’AzCopy, il est important d’utiliser la version la plus récente. Pour une vue d’ensemble des outils de copie Azure qui vous garantissent de pouvoir copier toutes les métadonnées importantes d’un fichier, consultez le tableau des outils de copie de fichiers.

    Si vous avez activé Sauvegarde Azure sur vos partages de fichiers gérés par synchronisation de fichiers Azure, les ACL peuvent continuer à être restaurées dans le cadre du workflow de restauration de la sauvegarde. Cela fonctionne pour l’ensemble du partage de fichiers ou pour des fichiers/répertoires individuels.

    Si vous utilisez des captures instantanées dans le cadre de la solution de sauvegarde autogérée pour les partages de fichiers gérés par Azure File Sync, vos ACL peuvent ne pas être restaurées correctement en ACL NTFS si les captures instantanées ont été effectuées avant le 24 février 2020. Si cela se produit, pensez à contacter le support Azure.

  • Est-ce qu’Azure File Sync synchronise LastWriteTime pour les répertoires ? Pourquoi est-ce que le timestamp de la date de modification d’un répertoire n’est pas mis à jour lorsque les fichiers qu'il contient sont modifiés ?
    Non, Azure File Sync ne synchronise pas le LastWriteTime pour les annuaires. En outre, Azure Files ne met pas à jour lle timestamp de la date de modification (LastWriteTime) pour les répertoires lorsque les fichiers du répertoire sont modifiés. Ce comportement est normal.

Sécurité, authentification et contrôle d’accès

  • Comment puis-je auditer la consultation et les modifications de fichiers dans Azure Files ?

    Deux options fournissent la fonctionnalité d’audit pour Azure Files :

    • Si les utilisateurs accèdent directement au partage de fichiers Azure, les journaux de Stockage Azure permettent de suivre les modifications apportées aux fichiers et les accès utilisateur à des fins de résolution des problèmes. Les demandes sont enregistrées sur la base du meilleur effort.
    • Si des utilisateurs accèdent au partage de fichiers Azure via un serveur Windows Server sur lequel l’agent Azure File Sync est installé, utilisez une stratégie d’audit ou un produit tiers pour suivre les modifications de fichiers et les accès utilisateur sur le serveur Windows Server.

  • Azure Files prend-il en charge l’utilisation de l’énumération basée sur l’accès (ABE) pour contrôler la visibilité des fichiers et dossiers dans les partages de fichiers Azure SMB ?

    L’utilisation d’ABE avec Azure Files n’est pas prise en charge, mais vous pouvez utiliser DFS-N avec des partages de fichiers Azure SMB.

Authentification basée sur l’identité

  • Microsoft Entra Domain Services prend-il en charge l’accès SMB à l’aide d’informations d’identification Microsoft Entra à partir d’appareils joints ou inscrits auprès de Microsoft Entra ID ?

    Non, ce scénario n’est pas pris en charge.

  • Puis-je utiliser le nom canonique (CNAME) pour monter un partage de fichiers Azure lors de l’utilisation de l’authentification basée sur l’identité ?

    Oui, ce scénario est désormais pris en charge dans les environnements à forêt unique et à forêts multiples pour les partages de fichiers Azure SMB. Toutefois, Azure Files prend uniquement en charge la configuration d’enregistrements CNAME en utilisant le nom du compte de stockage en tant que préfixe de domaine. Si vous ne souhaitez pas utiliser le nom du compte de stockage comme préfixe, envisagez plutôt d’utiliser des espaces de noms DFS.

  • Puis-je accéder aux partages de fichiers Azure avec des informations d’identification Microsoft Entra à partir d’une machine virtuelle sous un autre abonnement ?

    Si l’abonnement sous lequel est déployé le partage de fichiers est associé au même locataire Microsoft Entra que le déploiement Microsoft Entra Domain Services auquel la machine virtuelle est jointe, vous pouvez alors accéder aux partages de fichier Azure avec les mêmes informations d’identification Microsoft Entra. La limitation est imposée non pas sur l’abonnement, mais sur le locataire Microsoft Entra associé.

  • Puis-je activer l’authentification Microsoft Entra Domain Services ou AD DS locale pour les partages de fichiers Azure en utilisant un locataire Microsoft Entra différent du locataire principal du partage de fichiers Azure ?

    Nombre Non, Azure Files prend uniquement en charge l’intégration de Microsoft Entra Domaine Services ou d’AD DS en local à un locataire Microsoft Entra qui se trouve dans le même abonnement que le partage de fichiers. Un abonnement peut être associé seulement à un locataire Microsoft Entra. Lorsque vous utilisez AD DS en local pour l’authentification, les informations d’identification AD DS doivent être synchronisées avec le compte Microsoft Entra ID auquel le compte de stockage est associé.

  • L’authentification AD DS locale pour les partages de fichiers Azure prend-elle en charge l’intégration à un environnement AD DS utilisant plusieurs forêts ?

    L’authentification AD DS en local d’Azure Files s’intègre uniquement à la forêt du service de domaine sur lequel le compte de stockage est inscrit. Pour prendre en charge l’authentification à partir d’une autre forêt, votre environnement doit disposer d’une approbation de forêt correctement configurée. Pour obtenir des instructions détaillées, consultez Utiliser Azure Files avec plusieurs forêts Active Directory.

    Remarque

    Dans une configuration à plusieurs forêts, n’utilisez pas l’Explorateur de fichiers pour configurer les listes ACL Windows/les autorisations NTFS au niveau de la racine, du répertoire ou du fichier. Utilisez icacls à la place.

  • Y a-t-il une différence dans la création d’un compte d’ordinateur ou d’un compte de connexion au service pour représenter mon compte de stockage dans Active Directory ?

    La création d’un compte d’ordinateur (par défaut) ou d’un compte de connexion au service ne présente aucune différence quant à la façon dont l’authentification fonctionne avec Azure Files. Vous pouvez librement choisir votre méthode de représentation d’un compte de stockage en tant qu’identité dans votre environnement AD. Le DomainAccountType par défaut défini dans la cmdlet Join-AzStorageAccountForAuth est le compte d’ordinateur. Toutefois, la durée de vie du mot de passe configurée dans votre environnement AD peut être différente pour les comptes d’ordinateur ou de connexion au service, et vous devez prendre cela en considération pour mettre à jour le mot de passe de l’identité de votre compte de stockage dans AD.

  • Comment supprimer les informations d’identification mises en cache avec une clé de compte de stockage et supprimer les connexions SMB existantes avant d’initialiser une nouvelle connexion avec des informations d’identification Microsoft Entra ID ou AD ?

    Suivez le processus en deux étapes ci-dessous pour supprimer les informations d’identification enregistrées associées à la clé de compte de stockage et supprimer la connexion SMB :

    1. Exécutez la commande suivante à partir d’une invite de commandes Windows pour supprimer les informations d’identification. Si vous n’en trouvez pas, cela signifie que vous n’avez pas conservé les informations d’identification et que vous pouvez ignorer cette étape.

      cmdkey /delete:Domain:target=storage-account-name.file.core.windows.net

    2. Supprimez la connexion existante au partage de fichiers. Vous pouvez spécifier le chemin de montage en tant que lettre de lecteur ou le chemin storage-account-name.file.core.windows.net.

      net use <drive-letter/share-path> /delete

  • Est-il possible d’afficher le paramètre userPrincipalName (UPN) du propriétaire d’un fichier/répertoire dans l’Explorateur de fichiers à la place de son ID de sécurité (SID) ?

    L’Explorateur de fichiers appelle directement une API RPC vers le serveur (Azure Files) pour traduire le SID en UPN. Azure Files ne prend pas en charge cette API. Ainsi, dans l’Explorateur de fichiers, le SID du propriétaire d’un fichier/répertoire s’affiche à la place de l’UPN pour les fichiers et les répertoires hébergés sur Azure Files. Toutefois, à partir d’un client joint à un domaine, vous pouvez utiliser la commande PowerShell suivante pour afficher tous les éléments d’un répertoire et de son propriétaire, y compris l’UPN :

    Get-ChildItem <Path> | Get-ACL | Select Path, Owner

NFS (Network File System) v4.1

Instantanés de partage

Créer des instantanés de partage

  • Mes instantanés de partage sont-ils géoredondants ?
    Les instantanés de partage ont la même redondance que le partage de fichiers Azure auquel ils sont destinés. Si vous avez sélectionné un stockage géoredondant pour votre compte, votre instantané de partage est également stocké de façon redondante dans la région associée.

Nettoyer des instantanés de partage

  • Puis-je supprimer mon partage sans supprimer mes instantanés de partage ?
    Si vous avez des instantanés de partage actifs sur votre partage, vous ne pouvez pas le supprimer. Vous pouvez utiliser une API pour supprimer des instantanés de partage, ainsi que le partage. Vous pouvez également supprimer les instantanés de partage et le partage dans le portail Azure.

Facturation et tarification

  • Que sont les transactions dans Azure Files et comment sont-elles facturées ? Les transactions de protocole se produisent chaque fois qu’un utilisateur, une application, un script ou un service interagit avec des partages de fichiers Azure (écriture, lecture, référencement, suppression de fichiers, etc.). Il est important de se rappeler que certaines actions que vous pouvez percevoir comme une opération unique peuvent en fait impliquer plusieurs transactions. Pour les partages de fichiers Azure standard facturés selon un modèle de paiement à l’utilisation, les différents types de transactions ont des prix différents en fonction de leur impact sur le partage de fichiers. Les transactions n’affectent pas la facturation des partages de fichiers Premium, qui sont facturés d’après un modèle provisionné. Pour plus d’informations, consultez Présentation de la facturation.

  • Quel est le coût des instantanés de partage ?
    Les instantanés de partage sont incrémentiels par nature. L’instantané de partage de base est le partage lui-même. Tous les instantanés de partage suivants sont incrémentiels et ne stockent que la différence par rapport à l’instantané de partage précédent. Vous n’êtes facturé que pour le contenu changé. Si vous disposez d’un partage de 100 Go de données, mais que seulement 5 Go ont changé depuis le dernier instantané de partage, l’instantané de partage consomme seulement 5 Go supplémentaires ; ainsi, 105 Go vous sont facturés. Pour plus d’informations sur les frais de sortie standard et de transaction, consultez la page de tarification.

Interopérabilité avec d’autres services

  • Puis-je utiliser mon partage de fichiers Azure en tant que témoin de partage de fichiers pour mon cluster de basculement Windows Server ?
    Cette configuration n’est actuellement pas prise en charge pour Azure Files. Pour plus d’informations sur la façon d’obtenir cette configuration pour le stockage Blob Azure, consultez Déployer un témoin cloud pour un cluster de basculement.

Voir aussi