Lees de veelgestelde vragen (FAQ) over Azure Files

  • Artikel

Azure Files biedt volledig beheerde bestandsshares in de cloud die toegankelijk zijn via het SMB-protocol (Server Message Block) van de industriestandaard en het NFS-protocol (Network File System). U kunt Azure-bestandsshares gelijktijdig koppelen aan cloud- of on-premises implementaties van Windows, Linux en macOS. U kunt ook Azure-bestandsshares in de cache opslaan op Windows Server-computers met behulp van Azure File Sync voor snelle toegang dicht bij waar de gegevens worden gebruikt.

Azure File Sync

  • Kan ik aan een domein gekoppelde en niet-domein gekoppelde servers in dezelfde synchronisatiegroep hebben?
    Ja. Een synchronisatiegroep kan servereindpunten bevatten met verschillende Active Directory-lidmaatschappen, zelfs als ze niet lid zijn van een domein. Hoewel deze configuratie technisch werkt, raden we dit niet aan als een typische configuratie, omdat toegangsbeheerlijsten (ACL's) die zijn gedefinieerd voor bestanden en mappen op de ene server mogelijk niet kunnen worden afgedwongen door andere servers in de synchronisatiegroep. Voor de beste resultaten raden we u aan om te synchroniseren tussen servers die zich in hetzelfde Active Directory-forest bevinden, tussen servers die zich in verschillende Active Directory-forests bevinden, maar vertrouwensrelaties hebben ingesteld of tussen servers die zich niet in een domein bevinden. Het is raadzaam om te voorkomen dat u een combinatie van deze configuraties gebruikt.

  • Ik heb een bestand rechtstreeks in mijn Azure-bestandsshare gemaakt met behulp van SMB of in de portal. Hoe lang duurt het voordat het bestand is gesynchroniseerd met de servers in de synchronisatiegroep?

    Wijzigingen die zijn aangebracht in de Azure-bestandsshare met de Azure Portal of SMB, worden niet onmiddellijk gedetecteerd en gerepliceerd, zoals wijzigingen in het servereindpunt. Azure Files heeft nog geen wijzigingsmeldingen of logboeken. Daarom is er geen manier om automatisch een synchronisatiesessie te starten wanneer bestanden worden gewijzigd. Op Windows Server gebruikt Azure File Sync Windows USN-logboeken om automatisch een synchronisatiesessie te starten wanneer bestanden worden gewijzigd.

    Als u wijzigingen in de Azure-bestandsshare wilt detecteren, kent Azure File Sync een geplande taak die een wijzigingsdetectietaak wordt genoemd. Een wijzigingsdetectietaak inventariseert elk bestand in de bestandsshare en vergelijkt dit vervolgens met de synchronisatieversie voor dat bestand. Wanneer de wijzigingsdetectietaak bepaalt dat bestanden zijn gewijzigd, start Azure File Sync een synchronisatiesessie. De wijzigingsdetectietaak wordt elke 24 uur gestart. Omdat de wijzigingsdetectietaak werkt door elk bestand in de Azure-bestandsshare op te sommen, duurt wijzigingsdetectie langer in grotere naamruimten dan in kleinere naamruimten. Voor grote naamruimten kan het langer dan één keer per 24 uur duren om te bepalen welke bestanden zijn gewijzigd.

    Als u bestanden die zijn gewijzigd in de Azure-bestandsshare onmiddellijk wilt synchroniseren, kan de PowerShell-cmdlet Invoke-AzStorageSyncChangeDetection worden gebruikt om de detectie van wijzigingen in de Azure-bestandsshare handmatig te starten. Deze cmdlet is bedoeld voor scenario's waarbij een bepaald type geautomatiseerd proces wijzigingen aanbrengt in de Azure-bestandsshare of de wijzigingen worden uitgevoerd door een beheerder (zoals het verplaatsen van bestanden en mappen naar de share). Voor wijzigingen van eindgebruikers wordt aangeraden de Azure File Sync-agent te installeren op een IaaS-VM en eindgebruikers toegang te geven tot de bestandsshare via de IaaS-VM. Op deze manier worden alle wijzigingen snel gesynchroniseerd met andere agents zonder de cmdlet Invoke-AzStorageSyncChangeDetection te hoeven gebruiken. Zie de documentatie Invoke-AzStorageSyncChangeDetection voor meer informatie.

    We verkennen het toevoegen van wijzigingsdetectie voor een Azure-bestandsshare die vergelijkbaar is met USN voor volumes op Windows Server. Help ons prioriteit te geven aan deze functie voor toekomstige ontwikkeling door te stemmen op Feedback van de Azure-community.

  • Als hetzelfde bestand ongeveer gelijktijdig wordt gewijzigd op twee server, wat gebeurt er dan?
    Bestandsconflicten treden op wanneer het bestand in de Azure-bestandsshare niet overeenkomt met het bestand op de locatie van het servereindpunt (grootte en/of tijdstip van laatste wijziging is anders).

    De volgende scenario's kunnen bestandsconflicten veroorzaken:

    • Een bestand wordt gemaakt of gewijzigd in een eindpunt (bijvoorbeeld Server A). Als hetzelfde bestand op een ander eindpunt wordt gewijzigd vóórdat de wijziging op Server A wordt gesynchroniseerd met dat eindpunt, treedt een conflictbestand op.
    • Het bestand bestond in de Azure-bestandsshare en de locatie van het servereindpunt voordat het servereindpunt werd gemaakt. Als de bestandsgrootte en/of het tijdstip van laatste wijziging verschillen tussen het bestand op de server en de Azure-bestandsshare wanneer het servereindpunt wordt gemaakt, treedt een conflictbestand op.
    • De synchronisatiedatabase is opnieuw gemaakt vanwege beschadiging of bereikt kennislimiet. Zodra de database opnieuw is gemaakt, wordt de synchronisatiemodus afstemming bereikt. Als de bestandsgrootte en/of de laatste wijzigingstijd verschilt tussen het bestand op de server en de Azure-bestandsshare wanneer afstemming plaatsvindt, wordt er een conflictbestand gemaakt.

    Azure File Sync maakt gebruik van een eenvoudige conflictoplossingsstrategie: we bewaren beide wijzigingen in bestanden die op twee eindpunten tegelijk zijn gewijzigd. De laatst geschreven wijziging behoudt de oorspronkelijke bestandsnaam. Het oudere bestand (bepaald door LastWriteTime) heeft de eindpuntnaam en het conflictnummer dat is toegevoegd aan de bestandsnaam. Voor servereindpunten is de naam van het eindpunt de naam van de server. Voor cloudeindpunten is de naam van het eindpunt Cloud. De naam volgt deze taxonomie:

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

    Het eerste conflict van CompanyReport.docx wordt bijvoorbeeld CompanyReport-CentralServer.docx als CentralServer de plaats is waar de oudere schrijfbewerking heeft plaatsgevonden. Het tweede conflict krijgt de naam CompanyReport-CentralServer-1.docx. Azure File Sync ondersteunt 100 conflicterende bestanden per bestand. Zodra het maximum aantal conflictbestanden is bereikt, kan het bestand niet worden gesynchroniseerd totdat het aantal conflictbestanden kleiner is dan 100.

  • Ik heb cloudlagen uitgeschakeld, waarom zijn er gelaagde bestanden op de locatie van het servereindpunt?
    Er zijn twee redenen waarom gelaagde bestanden kunnen bestaan op de locatie van het servereindpunt:

    • Wanneer u een nieuw servereindpunt toevoegt aan een bestaande synchronisatiegroep, wordt bestanden weergegeven als gelaagd totdat ze lokaal worden gedownload als u de eerste optie voor de relevante naamruimte kiest of alleen de naamruimte voor de initiële downloadmodus terugroept. Als u dit wilt voorkomen, selecteert u de optie gelaagde bestanden voor de initiële downloadmodus. Als u bestanden handmatig wilt intrekken, gebruikt u de Invoke-StorageSyncFileRecall cmdlet.

    • Als cloudlagen zijn ingeschakeld op het servereindpunt en vervolgens zijn uitgeschakeld, blijven bestanden gelaagd totdat ze worden geopend.

  • Waarom worden mijn gelaagde bestanden geen miniaturen of previews weergegeven in Windows Bestandenverkenner?
    Voor gelaagde bestanden zijn miniaturen en voorbeeldweergaven niet zichtbaar op uw servereindpunt. Dit is verwacht gedrag omdat de functie miniaturencache in Windows het lezen van bestanden met het offlinekenmerk opzettelijk overslaat. Als cloudlagen zijn ingeschakeld, zou het lezen via gelaagde bestanden ervoor zorgen dat ze worden gedownload (teruggehaald).

    Dit gedrag is niet specifiek voor Azure File Sync. In Windows Bestandenverkenner wordt een 'grijze X' weergegeven voor alle bestanden waarop het offlinekenmerk is ingesteld. U ziet het X-pictogram bij het openen van bestanden via SMB. Zie Waarom krijg ik geen miniaturen voor bestanden die offline zijn gemarkeerd voor een gedetailleerde uitleg van dit gedrag?

    Zie Gelaagde bestanden beheren voor vragen over het beheren van gelaagde bestanden.

  • Waarom bestaan gelaagde bestanden buiten de naamruimte van het servereindpunt?
    Vóór versie 3 van de Azure File Sync-agent heeft Azure File Sync het verplaatsen van gelaagde bestanden buiten het servereindpunt geblokkeerd, maar op hetzelfde volume als het servereindpunt. Kopieerbewerkingen, verplaatsingen van niet-gelaagde bestanden en verplaatsingen van gelaagde bestanden naar andere volumes zijn niet beïnvloed. De reden voor dit gedrag was de impliciete veronderstelling dat Bestandenverkenner en andere Windows-API's hebben dat verplaatsingsbewerkingen op hetzelfde volume (bijna) onmiddellijke naambewerkingen zijn. Dit betekent dat verplaatsingen Bestandenverkenner of andere verplaatsingsmethoden (zoals opdrachtregel of PowerShell) niet reageren terwijl Azure File Sync de gegevens uit de cloud terugroept. Vanaf Azure File Sync-agent versie 3.0.12.0 kunt u met Azure File Sync een gelaagd bestand buiten het servereindpunt verplaatsen. We vermijden de negatieve effecten die eerder zijn genoemd door toe te staan dat het gelaagde bestand als een gelaagd bestand buiten het servereindpunt bestaat en vervolgens het bestand op de achtergrond terugroept. Dit betekent dat verplaatsingen op hetzelfde volume onmiddellijk zijn en dat we al het werk doen om het bestand terug te halen naar de schijf nadat de verplaatsing is voltooid.

  • Ik ondervind een probleem met Azure File Sync op mijn server (synchronisatie, cloudlagen, enzovoort). Moet ik mijn servereindpunt verwijderen en opnieuw maken?

    Nee: het verwijderen van een servereindpunt is niet zoals het opnieuw opstarten van een server. Het verwijderen en opnieuw maken van het servereindpunt is bijna nooit een geschikte oplossing voor het oplossen van problemen met synchronisatie, cloudlagen of andere aspecten van Azure File Sync. Het verwijderen van een servereindpunt is een destructieve bewerking. Dit kan leiden tot gegevensverlies in het geval dat gelaagde bestanden bestaan buiten de naamruimte van het servereindpunt. Zie voor meer informatie waarom gelaagde bestanden bestaan buiten de naamruimte van het servereindpunt voor meer informatie. Het kan ook leiden tot ontoegankelijke bestanden voor gelaagde bestanden die aanwezig zijn in de naamruimte van het servereindpunt. Deze problemen worden niet opgelost wanneer het servereindpunt opnieuw wordt gemaakt. Gelaagde bestanden kunnen aanwezig zijn in de naamruimte van uw servereindpunt, zelfs als u geen cloudopslaglagen hebt ingeschakeld. Daarom raden we u aan het servereindpunt niet te verwijderen, tenzij u wilt stoppen met het gebruik van Azure File Sync met deze specifieke map of expliciet bent geïnstrueerd om dit te doen door een Microsoft-technicus. Zie Een servereindpunt verwijderen voor meer informatie over het verwijderen van servereindpunten.

  • Kan ik de opslagsynchronisatieservice en/of het opslagaccount verplaatsen naar een andere resourcegroep, abonnement of Microsoft Entra-tenant?
    Ja, u kunt de opslagsynchronisatieservice en/of het opslagaccount verplaatsen naar een andere resourcegroep, abonnement of Microsoft Entra-tenant. Nadat u de opslagsynchronisatieservice of het opslagaccount hebt verplaatst, moet u de Microsoft.StorageSync-toepassing toegang geven tot het opslagaccount. Volg vervolgens deze stappen:

    1. Meld u aan bij Azure Portal en selecteer Toegangsbeheer (IAM) in de linkernavigatiebalk.

    2. Selecteer het tabblad Roltoewijzingen om de gebruikers en toepassingen (service-principals) weer te geven die toegang hebben tot uw opslagaccount.

    3. Controleer of Microsoft.StorageSync of Hybride File Sync-service (oude toepassingsnaam) wordt weergegeven in de lijst met de rol Lezer- en gegevenstoegang.

      Als Microsoft.StorageSync of Hybrid File Sync Service niet wordt weergegeven in de lijst, voert u de volgende stappen uit:

      • Selecteer Toevoegen.
      • Selecteer in het veld Rol de optie Lezers- en gegevenstoegang.
      • Typ Microsoft.StorageSync in het veld Selecteren, selecteer de rol en selecteer Vervolgens Opslaan.

      Notitie

      Wanneer u het cloudeindpunt maakt, moeten de opslagsynchronisatieservice en het opslagaccount zich in dezelfde Microsoft Entra-tenant bevinden. Zodra het cloudeindpunt is gemaakt, kunnen de opslagsynchronisatieservice en het opslagaccount worden verplaatst naar verschillende Microsoft Entra-tenants.

  • Behoudt Azure File Sync NTFS-ACL's op map-/bestandsniveau, samen met gegevens die zijn opgeslagen in Azure Files?

    Vanaf 24 februari 2020 worden nieuwe en bestaande ACL's die zijn gelaagd door Azure-bestandssynchronisatie behouden in NTFS-indeling en worden ACL-wijzigingen die rechtstreeks in de Azure-bestandsshare zijn aangebracht, gesynchroniseerd met alle servers in de synchronisatiegroep. Wijzigingen in ACL's in Azure-bestandsshares worden gesynchroniseerd via Azure File Sync. Wanneer u gegevens kopieert naar Azure Files, moet u een hulpprogramma voor kopiëren gebruiken dat ondersteuning biedt voor de benodigde 'betrouwbaarheid' om kenmerken, tijdstempels en ACL's te kopiëren naar een Azure-bestandsshare, via SMB of REST. Wanneer u Hulpprogramma's voor kopiëren van Azure gebruikt, zoals AzCopy, is het belangrijk om de nieuwste versie te gebruiken. Controleer de tabel met hulpprogramma's voor het kopiëren van bestanden om een overzicht te krijgen van azure-hulpprogramma's om ervoor te zorgen dat u alle belangrijke metagegevens van een bestand kunt kopiëren.

    Als u Azure Backup hebt ingeschakeld op uw door Azure File Sync beheerde bestandsshares, kunnen bestands-ACL's nog steeds worden hersteld als onderdeel van de werkstroom voor back-upherstel. Dit werkt voor de hele share of afzonderlijke bestanden/mappen.

    Als u momentopnamen gebruikt als onderdeel van de zelfbeheerde back-upoplossing voor bestandsshares die worden beheerd door Azure File Sync, worden uw ACL's mogelijk niet correct hersteld naar NTFS-ACL's als de momentopnamen vóór 24 februari 2020 zijn gemaakt. Als dit het geval is, kunt u contact opnemen met De ondersteuning van Azure.

  • Synchroniseert Azure File Sync de LastWriteTime voor directory's? Waarom wordt de datum waarop de gewijzigde tijdstempel voor een map niet is bijgewerkt wanneer bestanden erin worden gewijzigd?
    Nee, Azure File Sync synchroniseert de LastWriteTime niet voor directory's. Bovendien werkt Azure Files de datum waarop de gewijzigde tijdstempel (LastWriteTime) niet wordt bijgewerkt voor mappen wanneer bestanden in de map worden gewijzigd. Dit is normaal.

Beveiliging, verificatie en toegangsbeheer

  • Hoe kan ik bestandstoegang en -wijzigingen controleren in Azure Files?

    Er zijn twee opties die controlefunctionaliteit bieden voor Azure Files:

    • Als gebruikers rechtstreeks toegang hebben tot de Azure-bestandsshare, kunt u Azure Storage-logboeken gebruiken om bestandswijzigingen en gebruikerstoegang bij te houden voor probleemoplossingsdoeleinden. Aanvragen worden vastgelegd op basis van best effort.
    • Als gebruikers toegang hebben tot de Azure-bestandsshare via een Windows Server waarop de Azure File Sync-agent is geïnstalleerd, gebruikt u een controlebeleid of een product van derden om bestandswijzigingen en gebruikerstoegang op de Windows Server bij te houden.

  • Biedt Azure Files ondersteuning voor het gebruik van ABE (Access-Based Enumeration) om de zichtbaarheid van de bestanden en mappen in SMB Azure-bestandsshares te beheren?

    Het gebruik van ABE met Azure Files wordt momenteel niet ondersteund, maar u kunt DFS-N gebruiken met SMB Azure-bestandsshares.

Verificatie op basis van identiteit

  • Biedt Microsoft Entra Domain Services ondersteuning voor SMB-toegang met behulp van Microsoft Entra-referenties van apparaten die zijn gekoppeld aan of zijn geregistreerd bij Microsoft Entra ID?

    Nee, dit scenario wordt niet ondersteund.

  • Kan ik de canonieke naam (CNAME) gebruiken om een Azure-bestandsshare te koppelen tijdens het gebruik van verificatie op basis van identiteiten?

    Ja, dit scenario wordt nu ondersteund in omgevingen met één forest en meerdere forests voor SMB Azure-bestandsshares. Azure Files biedt echter alleen ondersteuning voor het configureren van CNAMEs met behulp van de naam van het opslagaccount als een domeinvoorvoegsel. Als u de naam van het opslagaccount niet als voorvoegsel wilt gebruiken, kunt u in plaats daarvan DFS-naamruimten gebruiken.

  • Heb ik toegang tot Azure-bestandsshares met Microsoft Entra-referenties vanaf een virtuele machine onder een ander abonnement?

    Als het abonnement waaronder de bestandsshare is geïmplementeerd, is gekoppeld aan dezelfde Microsoft Entra-tenant als de Implementatie van Microsoft Entra Domain Services waaraan de VIRTUELE machine lid is, kunt u vervolgens toegang krijgen tot Azure-bestandsshares met dezelfde Microsoft Entra-referenties. De beperking wordt niet opgelegd aan het abonnement, maar op de bijbehorende Microsoft Entra-tenant.

  • Kan ik Microsoft Entra Domain Services of on-premises AD DS-verificatie inschakelen voor Azure-bestandsshares met behulp van een Microsoft Entra-tenant die verschilt van de primaire tenant van de Azure-bestandsshare?

    Nee Azure Files biedt alleen ondersteuning voor Microsoft Entra Domain Services of on-premises AD DS-integratie met een Microsoft Entra-tenant die zich in hetzelfde abonnement bevindt als de bestandsshare. Een abonnement kan slechts worden gekoppeld aan één Microsoft Entra-tenant. Wanneer u on-premises AD DS gebruikt voor verificatie, moet de AD DS-referentie worden gesynchroniseerd met de Microsoft Entra-id waaraan het opslagaccount is gekoppeld.

  • Ondersteunt on-premises AD DS-verificatie voor Azure-bestandsshares integratie met een AD DS-omgeving met behulp van meerdere forests?

    Azure Files on-premises AD DS-verificatie kan alleen worden geïntegreerd met het forest van de domeinservice waarvoor het opslagaccount is geregistreerd. Als u verificatie van een ander forest wilt ondersteunen, moet uw omgeving een forestvertrouwensrelatie correct hebben geconfigureerd. Zie Azure Files gebruiken met meerdere Active Directory-forests voor gedetailleerde instructies.

    Notitie

    Gebruik in een installatie met meerdere forests geen Bestandenverkenner om Windows ACL's/NTFS-machtigingen te configureren op het niveau van de hoofdmap, map of bestand. Gebruik in plaats daarvan icacls .

  • Is er een verschil in het maken van een computeraccount of serviceaanmeldingsaccount dat mijn opslagaccount in AD vertegenwoordigt?

    Het maken van een computeraccount (standaard) of een serviceaanmeldingsaccount heeft geen verschil in hoe verificatie werkt met Azure Files. U kunt uw eigen keuze maken over het weergeven van een opslagaccount als een identiteit in uw AD-omgeving. De standaard DomainAccountType-set in Join-AzStorageAccountForAuth cmdlet is computeraccount. De wachtwoordverlooptijd die in uw AD-omgeving is geconfigureerd, kan echter verschillen voor aanmeldingsaccounts voor computers of services. Houd daar rekening mee om het wachtwoord van uw opslagaccount-id in AD bij te werken.

  • Hoe verwijdert u referenties in de cache met de sleutel van het opslagaccount en verwijdert u bestaande SMB-verbindingen voordat u een nieuwe verbinding met Microsoft Entra-id of AD-referenties initialiseert?

    Volg de onderstaande twee stappen om de opgeslagen referentie te verwijderen die is gekoppeld aan de sleutel van het opslagaccount en de SMB-verbinding te verwijderen:

    1. Voer de volgende opdracht uit vanaf een Windows-opdrachtprompt om de referentie te verwijderen. Als u er geen kunt vinden, betekent dit dat u de referentie niet hebt behouden en deze stap kunt overslaan.

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

    2. Verwijder de bestaande verbinding met de bestandsshare. U kunt het koppelpad opgeven als de gekoppelde stationsletter of het storage-account-name.file.core.windows.net pad.

      net use <stationsletter/share-path> /delete

  • Is het mogelijk om de userPrincipalName (UPN) van een bestands-/mapeigenaar in Bestandenverkenner weer te geven in plaats van de beveiligings-id (SID)?

    Bestandenverkenner roept een RPC-API rechtstreeks aan op de server (Azure Files) om de SID te vertalen naar een UPN. Azure Files biedt geen ondersteuning voor deze API. In Bestandenverkenner wordt de SID van een eigenaar van een bestand/map weergegeven in plaats van de UPN voor bestanden en mappen die worden gehost in Azure Files. Vanaf een client die lid is van een domein, kunt u echter de volgende PowerShell-opdracht gebruiken om alle items in een directory en hun eigenaar weer te geven, inclusief UPN:

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

Network File System (NFS v4.1)

Momentopnamen van shares

Momentopnamen van shares maken

  • Zijn mijn momentopnamen van shares geografisch redundant?
    Momentopnamen van shares hebben dezelfde redundantie als de Azure-bestandsshare waarvoor ze zijn gemaakt. Als u geografisch redundante opslag voor uw account hebt geselecteerd, wordt uw momentopname van de share ook redundant opgeslagen in de gekoppelde regio.

Momentopnamen van shares opschonen

  • Kan ik mijn share verwijderen, maar mijn momentopnamen van mijn share niet verwijderen?
    Als u actieve momentopnamen van shares op uw share hebt, kunt u uw share niet verwijderen. U kunt een API gebruiken om momentopnamen van shares te verwijderen, samen met de share. U kunt ook zowel de momentopnamen van de share als de share verwijderen in Azure Portal.

Facturering en prijzen

  • Wat zijn transacties in Azure Files en hoe worden ze gefactureerd? Protocoltransacties vinden plaats wanneer een gebruiker, toepassing, script of service communiceert met Azure-bestandsshares (schrijven, lezen, vermelden, verwijderen van bestanden, enzovoort). Het is belangrijk te onthouden dat sommige acties die u als één bewerking beschouwt, mogelijk meerdere transacties omvatten. Voor standaard Azure-bestandsshares die worden gefactureerd op basis van een model voor betalen per gebruik, hebben verschillende typen transacties verschillende prijzen op basis van hun invloed op de bestandsshare. Transacties zijn niet van invloed op facturering voor Premium-bestandsshares, die worden gefactureerd met behulp van een ingericht model. Zie Facturering begrijpen voor meer informatie.

  • Hoeveel kost het delen van momentopnamen?
    Momentopnamen van shares zijn incrementeel van aard. De momentopname van de basisshare is de share zelf. Alle volgende momentopnamen van shares zijn incrementeel en slaan alleen het verschil op van de voorgaande momentopname van de share. U wordt alleen gefactureerd voor de gewijzigde inhoud. Als u een share hebt met 100 GiB met gegevens, maar slechts 5 GiB is gewijzigd sinds uw laatste momentopname van de share, verbruikt de momentopname van de share slechts 5 extra GiB en wordt u gefactureerd voor 105 GiB. Zie de pagina Prijzen voor meer informatie over transactie- en standaardkosten voor uitgaand verkeer.

Interoperabiliteit met andere services

  • Kan ik mijn Azure-bestandsshare gebruiken als bestandssharewitness voor mijn Windows Server-failovercluster?
    Deze configuratie wordt momenteel niet ondersteund voor Azure Files. Zie Een cloudwitness implementeren voor een failovercluster voor meer informatie over het instellen hiervan met behulp van Azure Blob Storage.

Zie ook