Veelgestelde vragen (FAQ) over Azure Files en Azure File Sync

Azure Files biedt volledig beheerde bestandsdelingen in de cloud die je kunt benaderen via het industriestandaard Server Message Block (SMB)-protocol en het Network File System (NFS)-protocol. U kunt Azure-bestandsshares gelijktijdig koppelen aan cloud- of on-premises implementaties van Windows, Linux en macOS. Door Azure File Sync te gebruiken, kun je Azure-bestandsdelingen op Windows Server-machines cachen voor snelle toegang tot data dicht bij de gebruikte plek.

Azure File Sync FAQ

  • 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 aangemaakt. 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.
    • Je maakt de synchronisatiedatabase opnieuw aan vanwege corruptie of het bereiken van kennislimiet. Nadat je de database opnieuw hebt aangemaakt, gaat de synchronisatie over in een modus die 'afstemming' wordt genoemd. Als de bestandsgrootte en de laatste wijzigingstijd verschillen tussen het bestand op de server en de Azure-bestandsdeling tijdens de afstemming, wordt er een conflictbestand aangemaakt.

    Nadat de initiële upload naar de Azure-bestandsdeling is voltooid, overschrijft Azure File Sync geen bestanden meer in je synchronisatiegroep. In plaats daarvan wordt een eenvoudige strategie voor conflictoplossing gebruikt: het behoudt beide wijzigingen voor bestanden die op twee verschillende eindpunten tegelijk worden aangepast. 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\>

    Bijvoorbeeld, het eerste conflict van CompanyReport.docx wordt CompanyReport-CentralServer.docx als CentralServer de plek is waar het oudere schrijven plaatsvond. Het tweede conflict heet CompanyReport-CentralServer-1.docx. Azure File Sync ondersteunt 100 conflicterende bestanden per bestand. Zodra het maximale aantal conflictbestanden is bereikt, kan het bestand niet worden gesynchroniseerd totdat het aantal conflictbestanden onder de 100 ligt.

  • 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, worden bestanden weergegeven als gelaagd totdat ze lokaal worden gedownload, als u kiest voor de optie 'naamruimte eerst terugroepen' of 'alleen naamruimte terugroepen' voor de initiële downloadmodus. Als u dit wilt voorkomen, selecteert u de optie vermijd gelaagde bestanden voor de eerste downloadmodus. Als u bestanden handmatig wilt intrekken, gebruikt u de Invoke-StorageSyncFileRecall cmdlet.

    • Als cloud-tiering is ingeschakeld op het servereindpunt en vervolgens is uitgeschakeld, blijven bestanden getierd totdat ze worden geopend.

  • Waarom worden er geen miniaturen of previews weergegeven voor mijn gelaagde bestanden in Windows Verkenner?
    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 Cloud-tiering is ingeschakeld, zou het lezen van gelaagde bestanden ervoor zorgen dat ze worden gedownload (teruggehaald). U kunt Azure File Sync echter configureren om het offlinekenmerk over te slaan.

    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?

    Voor vragen over het beheren van gelaagde bestanden, zie Gelaagde bestanden beheren.

  • Is er een optie om het offlinekenmerk voor gelaagde bestanden over te slaan?

    Als u liever miniaturen en voorbeelden zichtbaar maakt voor gelaagde bestanden, kunt u Azure File Sync configureren om het offlinekenmerk over te slaan.

    1. Voeg de volgende registersleutel toe op de server:

      reg ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Azure\StorageSync" /v SkipOfflineAttributeOnTieredFile /t REG_DWORD /d 1 /f

    2. Start de FileSyncSvc-service opnieuw.

    Na de configuratie:

    • Nieuwe gelaagde bestanden hebben niet langer het offlinekenmerk.
    • Bestaande gelaagde bestanden worden bijgewerkt in de volgende onderhoudsuitvoering (vindt elke 24 uur plaats).

    Notitie

    Deze instelling wordt globaal toegepast op alle bestanden, niet op specifieke extensies. Zonder het offlinekenmerk wordt in Windows Bestandsverkenner een ander pictogram weergegeven. U kunt de kolom Kenmerken toevoegen in Verkenner om gelaagde bestanden (kenmerken ALM) te identificeren. Op basis van gebruikspatronen kan het overslaan van het offlineattribuut het ophalen van bestanden verhogen, daarom moet u de ophaalactiviteit controleren en ervoor zorgen dat de uitgaande dataverkeerkosten binnen een acceptabel bereik blijven. Zie Hoe u gelaagde bestanden beheert.

  • Waarom bestaan gelaagde bestanden buiten de naamruimte van het servereindpunt?
    Voor Azure File Sync agent versie 3 blokkeerde Azure File Sync het verplaatsen van gelaagde bestanden buiten het server-eindpunt maar op hetzelfde volume als het server-eindpunt. Kopieerbewerkingen, het verplaatsen van niet-gelaagde bestanden en het verplaatsen van gelaagde bestanden naar andere volumes werden 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. Deze aanname betekent dat verplaatsingen File Explorer of andere verplaatsingsmethoden (zoals de opdrachtregel of PowerShell) onresponsief laten lijken, terwijl Azure File Sync de gegevens uit de cloud oproept. Vanaf Azure File Sync agent versie 3.0.12.0 laat Azure File Sync je een gelaagd bestand buiten het server-eindpunt verplaatsen. De eerder genoemde negatieve effecten worden voorkomen door het gelaagde bestand als een gelaagd bestand buiten het servereindpunt te laten bestaan en het bestand vervolgens op de achtergrond op te roepen. Deze aanpak betekent dat verhuizingen op hetzelfde volume direct plaatsvinden, en Azure File Sync roept het bestand na voltooiing op schijf terug.

  • 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 cloud tiering nooit 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 het servicemenu.

    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 verschijnt niet in de lijst, volg deze stappen:

      • 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. Nadat het cloud-endpoint is aangemaakt, kun je de storage sync service en het opslagaccount naar verschillende Microsoft Entra-tenants verplaatsen.

  • 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 getrieerd door Azure-bestandssynchronisatie opgeslagen in NTFS-formaat, 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 bestandsshares die door Azure File Sync worden beheerd, kunnen bestand-ACL's nog steeds worden hersteld als onderdeel van de back-upherstelwerkstroom. 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 gewijzigd-tijdstempel (LastWriteTime) niet bij voor mappen wanneer bestanden in de map worden veranderd. Dit is normaal.

  • Hoe werkt volumeruimte voor Cloud Tiering als onderdeel van interoperabiliteit met Dedup?
    In sommige gevallen waarin Dedup is geïnstalleerd, kan de beschikbare volumeruimte meer toenemen dan verwacht nadat de Dedup garbage collection is geactiveerd. Laten we zeggen dat het beleid voor vrije ruimte voor cloud-tiering is ingesteld op 20%. Azure File Sync wordt geïnformeerd wanneer er weinig vrije ruimte is (bijvoorbeeld wanneer vrije ruimte 19%is). Tiering bepaalt dat er 1% extra ruimte vrijgemaakt moet worden, maar als buffer zijn er 5% extra, dus het wordt opgeschaald tot 25% (bijvoorbeeld 30 GiB). De bestanden worden in niveaus ingedeeld totdat ze 30 GiB bereiken. Voor de interoperabiliteit met Dedup start Azure File Sync aan het einde van de tiering-sessie een opschoning.

  • Waarom roept de antivirussoftware op de Azure File Sync-server gelaagde bestanden op?
    Wanneer gebruikers toegang hebben tot bestanden in gelaagde opslag, kan bepaalde antivirussoftware (AV) ertoe leiden dat bestanden onbedoeld opnieuw worden opgehaald. Dit probleem ontstaat als de antivirussoftware niet zo is ingesteld dat gelaagde bestanden (die met het RECALL_ON_DATA_ACCESS attribuut) worden genegeerd. Dit is wat er gebeurt:

    1. Een gebruiker probeert toegang te krijgen tot een gelaagd bestand.
    2. De AV-software blokkeert de leesaanwijzer.
    3. De antivirussoftware voert vervolgens zelf een lezing uit om het bestand te scannen op virussen.

    Dit proces lijkt misschien alsof de antivirussoftware de gelaagde bestanden oproept, maar het wordt eigenlijk geactiveerd door de toegangspoging van de gebruiker. Om dit probleem te voorkomen, moet u ervoor zorgen dat uw AV-leverancier de software zo configureert dat het scannen van gelaagde bestanden met het kenmerk RECALL_ON_DATA_ACCESS wordt genegeerd.

  • Kan SSL-inspectiesoftware de toegang tot Azure File Sync-servers blokkeren? Zorg ervoor dat je SSL-inspectiesoftware (zoals Zscaler of FortiGate) Azure File Sync-servereindpunten toegang geeft tot Azure. Deze SSL-inspectiehulpprogramma's kunnen firewallinstellingen overschrijven en selectief verkeer toestaan. Neem contact op met de netwerkbeheerder om dit probleem op te lossen. Gebruik het testnet commando om te bepalen of je Azure File Sync-server dit probleem ervaart.

Resourceproviders en klassieke bestandsshares

  • Wat is het verschil tussen Microsoft.Storage en Microsoft.FileShares-resourceproviders? Wat is een Azure file share versus een Azure classic file share?

    Resource providers zijn beheersdiensten die specifieke soorten resources leveren in Azure. U implementeert klassieke Azure-bestandsshares binnen een opslagaccount, een resource op het hoogste niveau die gebruikmaakt van de resourceprovider Microsoft.Storage. Alle opslagbronnen in een opslagaccount delen de limieten die voor dat opslagaccount gelden. Bestandsshares die worden aangeboden door de Microsoft.FileShares-resourceprovider, zijn een nieuwe resource op het hoogste niveau die de implementatie van bestandsshares vereenvoudigt doordat er geen opslagaccount meer nodig is. Momenteel ondersteunt Microsoft.FileShares alleen het NFS-bestandsdelingsprotocol. Klassieke bestandsshares ondersteunen zowel SMB als NFS.

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 een best-effort basis.
    • 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?

    Azure Files ondersteunt ABE niet, maar je kunt DFS-N wel gebruiken met SMB- Azure bestandsdelingen.

  • Kan ik opslaan in een Azure-bestandsshare met een printer of scanner?

    Azure Files ondersteunt alleen Windows, Linux en macOS. Het rechtstreeks openen van een Azure-bestandsshare vanaf een printer of scanner wordt niet ondersteund. Als u echter al gebruikmaakt van Azure File Sync, kunt u afdrukken of scannen op uw Windows-bestandsserver en het bestand vervolgens synchroniseren met een Azure-bestandsshare.

  • Biedt Azure Files ondersteuning voor alternatieve gegevensstromen?

Azure Files biedt geen ondersteuning voor alternatieve gegevensstromen. Bij het overdragen van gegevens via SMB wordt een bestand bestaat al melding weergegeven als er een alternatieve gegevensstroom wordt gevonden. U kunt alternatieve streams controleren met behulp van de volgende PowerShell-opdracht:

get-item <file path+name> -Stream *

Als er meer dan één stream wordt weergegeven, kunt u deze verwijderen met behulp van de volgende PowerShell-opdracht:

remove-Item <file path+name> -Stream *

Alternatieve gegevensstromen blijven on-premises behouden wanneer Azure File Sync wordt gebruikt.

Verificatie op basis van identiteit

  • Biedt Microsoft Entra Domeinservices 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 bestandsdeling is geïmplementeerd, is gekoppeld aan dezelfde Microsoft Entra-tenant als de Azure Active Directory Domain Services-implementatie waaraan de virtuele machine is gekoppeld, kunt u vervolgens toegang krijgen tot Azure-bestandsdelings met dezelfde Microsoft Entra-referenties. De beperking wordt niet opgelegd aan het abonnement, maar op de bijbehorende Microsoft Entra-tenant.

  • Kan ik Microsoft Entra Domeinservices 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 Domeinservices 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-bestandsdeling integratie met een AD DS-omgeving met 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 authenticatie van een ander forest wilt ondersteunen, moet uw omgeving een forest trust 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 icacls in plaats daarvan.

  • Is er een verschil in het maken van een computeraccount of serviceaanmeldingsaccount voor mijn opslagaccount in Active Directory?

    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 instelling voor DomainAccountType in Join-AzStorageAccountForAuth cmdlet is computeraccount. De wachtwoordverlooptijd die in uw AD-omgeving is geconfigureerd, kan echter verschillen voor aanmeldingsaccounts voor computers of services. U dient hiermee rekening te houden om de identiteit van uw opslagaccount in AD bij te werken.

  • Hoe verwijder ik gecachte inloggegevens door de opslagaccountsleutel te gebruiken en verwijder ik bestaande SMB-verbindingen voordat ik een nieuwe verbinding met Microsoft Entra ID of AD-gegevens initialiseer?

    Volg het tweestapsproces om het opgeslagen inloggegevens dat aan de opslagaccountsleutel is gekoppeld te verwijderen 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 inloggegevens niet hebt opgeslagen 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 aankoppelingspad opgeven als de aangekoppelde 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

Netwerkbestandssysteem (NFS v4.1)

Veelgestelde vragen over gedeelde snapshots

Maak momentopnamen van gedeelde items

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

Momentopnamen van aandelen opschonen

  • Kan ik mijn share verwijderen, maar mijn momentopnamen van mijn share niet verwijderen?
    Nee De workflow voor het verwijderen van bestanden verwijdert automatisch de snapshots wanneer je de share verwijdert.

Facturering en prijzen voor Azure Files

  • 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 bestandsshares met 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 geprovisioneerde bestandsshares. Zie Facturering begrijpen voor meer informatie.

Azure Files-interoperabiliteit met andere services

  • Wat is het verschil tussen Azure Files en Azure NetApp Files?
    Azure Files en Azure NetApp Files zijn verschillende bestandsopslagservices in Azure en zijn ontworpen voor verschillende workloads en prestatievereisten. Azure Files biedt serverloze SMB- en NFS-bestandsshares en biedt Azure File Sync als optie voor het opslaan van SMB-bestandsshares in de cache op Windows Server. Azure NetApp Files is een krachtige bare-metal bestandsopslagservice die wordt aangedreven door NetApp-technologie die ondersteuning biedt voor NFS-, SMB- en dual-protocol bestandsshares. Zie Compare Azure Files en Azure NetApp Files voor meer informatie.

  • Kan ik mijn Azure-bestandsshare gebruiken als een File Share Witness voor mijn Windows Server-failovercluster?
    Deze configuratie wordt niet ondersteund voor Azure Files. Om te leren hoe je deze configuratie opstelt met Azure Blob storage, zie Deploy a Cloud Witness for a Failover Cluster.

Zie ook

  • Last updated on