Planera för en Azure File Sync-distribution

Filerna lagras i molnet i Azure-filresurser. Du kan använda Azure-filresurser på följande två sätt. Vilket distributionsalternativ du väljer ändrar de aspekter som du behöver tänka på när du planerar för distributionen.

• Montera en Azure-filresurs direkt med hjälp av SMB-protokollet (Server Message Block): Eftersom Azure Files ger SMB-åtkomst kan du montera Azure-filresurser lokalt eller i molnet med hjälp av standard-SMB-klienten som är tillgänglig i Windows, macOS och Linux. Eftersom Azure-filresurser är serverlösa kräver distribution för produktionsscenarier inte hantering av en filserver eller nätverksansluten lagringsenhet (NAS). Det här valet innebär att du inte behöver tillämpa programkorrigeringar eller byta ut fysiska diskar.

• Cachelagra en Azure-filresurs lokalt med hjälp av Azure File Sync: Med Azure File Sync kan du centralisera organisationens filresurser i Azure Files samtidigt som du behåller flexibiliteten, prestandan och kompatibiliteten hos en lokal filserver. Azure File Sync omvandlar en lokal (eller molnbaserad) Windows Server-instans till en snabb cache för din Azure-filresurs.

Hanteringsbegrepp

I Azure är en resurs ett hanterbart objekt som du skapar och konfigurerar i dina Azure-prenumerationer och resursgrupper. Resurser erbjuds av resursprovidrar, som är hanteringstjänster som levererar specifika typer av resurser. Om du vill distribuera Azure File Sync arbetar du med två viktiga resurser:

• Lagringskonton som erbjuds av Microsoft.Storage resursprovidern. Lagringskonton är resurser på den översta nivån som representerar en delad pool med lagring, IOPS och dataflöde där du kan distribuera klassiska filresurser eller andra lagringsresurser, beroende på typ av lagringskonto. Alla lagringsresurser som distribueras till ett lagringskonto delar de gränser som gäller för lagringskontot. Klassiska filresurser stöder både SMB- och NFS-fildelningsprotokollen, men du kan bara använda Azure File Sync med SMB-filresurser.

  Anteckning

  Azure Files stöder också distribution av filresurser som en Azure-resurs på högsta nivå via resursprovidern Microsoft.FileShares . Men eftersom dessa filresurser för närvarande endast stöder NFS-protokollet stöds de inte av Azure File Sync.

• Storage Sync Services, som erbjuds av Microsoft.StorageSync resursprovidern. Storage Sync Services fungerar som hanteringscontainrar som gör att du kan registrera Windows-filservrar och definiera synkroniseringsrelationerna för Azure File Sync.

Begrepp för hantering av Azure-fildelningar

Klassiska filresurser eller filresurser som distribueras i lagringskonton är det traditionella sättet att distribuera filresurser för Azure Files. De stöder alla viktiga funktioner som Azure Files stöder, inklusive SMB- och NFS-, SSD- och HDD-medienivåer, varje redundanstyp och i varje region. Mer information om klassiska filresurser finns i klassiska filresurser.

Det finns två huvudsakliga typer av lagringskonton som används för klassiska filresursdistributioner:

• Etablerade lagringskonton: Etablerade lagringskonton särskiljs med lagringskontots FileStorage typ. Med etablerade lagringskonton kan du distribuera etablerade klassiska filresurser på antingen SSD- eller HDD-baserad maskinvara. Etablerade lagringskonton kan bara användas för att lagra klassiska filresurser och kan inte användas för lagring av andra lagringsresurser, till exempel blobcontainrar, köer och tabeller. Vi rekommenderar att du använder etablerade lagringskonton för alla nya klassiska filresursdistributioner.
• Betala per användning-lagringskonton: Betala per användning-lagringskonton särskiljs med lagringskontots StorageV2 typ. Med betala per användning-lagringskonton kan du distribuera betala per användning-filresurser på HDD-baserad maskinvara. Betala per användning-lagringskonton kan användas för att lagra klassiska filresurser och andra lagringsresurser, till exempel blobcontainrar, köer eller tabeller.

Hanteringskoncept för Azure File Sync

I en tjänst för synkronisering av lagring kan du distribuera:

• Registrerade servrar, som representerar en Windows-filserver med en förtroenderelation med Tjänsten för synkronisering av lagring. Registrerade servrar kan vara antingen en enskild server eller ett kluster, men en server/ett kluster kan bara registreras med en synkroniseringstjänst för lagring i taget.

• Synkroniseringsgrupper, som definierar synkroniseringsrelationen mellan en molnslutpunkt och en eller flera serverslutpunkter. Slutpunkter i en synkroniseringsgrupp synkroniseras med varandra. Om du till exempel har två distinkta uppsättningar filer som du vill hantera med Azure File Sync skapar du två synkroniseringsgrupper och lägger till olika slutpunkter i varje synkroniseringsgrupp.

  • Molnslutpunkter som representerar Azure-filresurser.
  • Serverslutpunkter, som representerar sökvägar på registrerade servrar som är synkroniserade med Azure Files. En registrerad server kan innehålla flera serverslutpunkter om deras namnområden inte överlappar varandra.

Antal nödvändiga lagringssynkroniseringstjänster

En tjänst för lagringssynkronisering är azure resource manager-rotresursen för Azure File Sync. Den hanterar synkroniseringsrelationer mellan dina Windows Server-installationer och Azure-filresurser. Varje tjänst för lagringssynkronisering kan innehålla flera synkroniseringsgrupper och flera registrerade servrar.

Varje Windows Server-instans kan bara registreras till en lagringssynkroniseringstjänst. Efter registreringen kan servern delta i flera synkroniseringsgrupper i den lagringssynkroniseringstjänsten med hjälp av ett Resource Manager-huvudnamn för att skapa serverslutpunkter på servern.

När du utformar Topologier för Azure File Sync måste du isolera data tydligt på nivån för lagringssynkroniseringstjänsten. Om ditt företag till exempel behöver separata Azure File Sync-miljöer för två olika affärsenheter och du behöver strikt dataisolering mellan dessa grupper bör du skapa en dedikerad lagringssynkroniseringstjänst för varje grupp. Undvik att placera synkroniseringsgrupper för båda företagsgrupperna i samma lagringssynkroniseringstjänst, eftersom den konfigurationen inte skulle säkerställa fullständig isolering.

Mer information om dataisolering med hjälp av separata prenumerationer eller resursgrupper i Azure finns i Azure-resursprovidrar och -typer.

Planera för balanserade synkroniseringstopologier

Innan du distribuerar några resurser är det viktigt att planera vad du ska synkronisera på en lokal server och med vilken Azure-filresurs. Genom att skapa en plan kan du avgöra hur många lagringskonton, Azure-filresurser och synkroniseringsresurser du behöver. Dessa överväganden är relevanta även om dina data för närvarande inte finns på en Windows Server-instans eller på den server som du vill använda på lång sikt. Migreringsavsnittet i den här artikeln kan hjälpa dig att fastställa lämpliga migreringsvägar för din situation.

I det här steget bestämmer du hur många Azure-filresurser du behöver. En enda Windows Server-instans (eller ett kluster) kan synkronisera upp till 30 Azure-filresurser.

Du kan ha fler mappar på dina volymer som du för närvarande delar lokalt som SMB-resurser till dina användare och appar. Det enklaste sättet att föreställa sig det här scenariot är att föreställa sig en lokal resurs som mappar 1:1 till en Azure-filresurs. Om du har ett tillräckligt litet antal resurser, under 30 för en enda Windows Server-instans, rekommenderar vi en 1:1-mappning.

Om du har fler än 30 resurser är det ofta onödigt att mappa en lokal resurs 1:1 till en Azure-filresurs. Överväg följande alternativ.

Gruppering för delning

Om personalavdelningen till exempel har 15 andelar kan du överväga att lagra all HR-avdelningens data i en enda Azure-filandel. Att lagra flera lokala resurser i en Azure-filresurs hindrar dig inte från att skapa de vanliga 15 SMB-resurserna på din lokala Windows Server-instans. Det innebär bara att du organiserar rotmapparna för dessa 15 resurser som undermappar under en gemensam mapp. Sedan synkroniserar du den här gemensamma mappen till en Azure-filresurs. På så sätt behöver du bara en enda Azure-filresurs i molnet för den här gruppen med lokala resurser.

Volymsynkronisering

Azure File Sync stöder synkronisering av roten på en volym till en Azure-filresurs. Om du synkroniserar volymroten går alla undermappar och filer till samma Azure-filresurs.

Att synkronisera volymens rot är inte alltid det bästa alternativet. Det finns fördelar med att synkronisera flera platser. Om du till exempel gör det kan du hålla antalet objekt lägre per synkroniseringsomfång. Vi testar Azure-filresurser och Azure File Sync med 100 miljoner objekt (filer och mappar) per resurs. Men bästa praxis är att försöka hålla antalet under 20 miljoner eller 30 miljoner i en enda andel.

Att konfigurera Azure File Sync med ett lägre antal objekt är inte bara fördelaktigt för filsynkronisering. Ett lägre antal objekt har också fördelar med scenarier som dessa:

• Den första genomsökningen av molninnehållet kan slutföras snabbare, vilket i sin tur minskar väntan på att namnområdet ska visas på en server som är aktiverad för Azure File Sync.
• Återställning på molnsidan från en ögonblicksbild av Azure-filresursen går snabbare.
• Haveriberedskapen för en lokal server kan påskyndas avsevärt.
• Ändringar som görs direkt i en Azure-filresurs (utanför en synkronisering) kan identifieras och synkroniseras snabbare.

Strukturerad metod för en distributionskarta

Innan du distribuerar molnlagring i ett senare steg är det viktigt att skapa en karta mellan lokala mappar och Azure-filresurser. Den här mappningen informerar hur många och vilka Azure File Sync-synkroniseringsgruppresurser du ska etablera. En synkroniseringsgrupp kopplar samman Azure-filresursen och mappen på servern och upprättar en synkroniseringsanslutning.

Om du vill optimera kartan och bestämma hur många Azure-filresurser du behöver kan du läsa följande begränsningar och metodtips:

• En server där Azure File Sync-agenten är installerad kan synkroniseras med upp till 30 Azure-filresurser.

• En Azure-filresurs distribueras i ett lagringskonto. Det här arrangemanget gör lagringskontot till ett skalningsmål för prestandanummer som IOPS och dataflöde.

  Var uppmärksam på IOPS-begränsningarna för ett lagringskonto när du distribuerar Azure-filresurser. Helst bör du kartlägga fildelningar 1:1 med lagringskonton. Den här mappningen kanske dock inte alltid är möjlig på grund av olika begränsningar, både från din organisation och från Azure. När du inte bara kan distribuera en filresurs på ett lagringskonto bör du överväga vilka resurser som är mycket aktiva och vilka resurser som ska vara mindre aktiva. Placera inte de hetaste filresurserna på samma lagringskonto.

  Om du planerar att lyfta en app till Azure som ska använda Azure-filresursen internt kan du behöva mer prestanda från din Azure-filresurs. Om den här typen av användning är en möjlighet, även i framtiden, är det bäst att skapa en enda Standard Azure-filresurs i sitt eget lagringskonto.

• Det finns en gräns på 250 lagringskonton per prenumeration per Azure-region.

Det är möjligt att en uppsättning mappar i din situation kan synkroniseras logiskt med samma Azure-filresurs (med hjälp av den common-root-metod som nämndes tidigare). Men det kan fortfarande vara bättre att omgruppera mappar så att de synkroniseras till två Azure-filresurser i stället för en. Du kan använda den här metoden för att hålla antalet filer och mappar per filresurs balanserade på servern. Du kan också dela upp dina lokala resurser och synkronisera mellan fler lokala servrar för att lägga till möjligheten att synkronisera med ytterligare 30 Azure-filresurser per extra server.

Vanliga scenarier och överväganden för filsynkronisering

Skapa en mappningstabell

Använd den tidigare informationen för att avgöra hur många Azure-filresurser du behöver och vilka delar av dina befintliga data som ska hamna i vilken Azure-filresurs.

Skapa en tabell som registrerar dina tankar så att du kan referera till den när du behöver det. Det är viktigt att hålla ordning, eftersom det är enkelt att förlora information om din mappningsplan när du etablerar många Azure-resurser samtidigt. Ladda ned följande Excel-fil som ska användas som mall för att skapa mappningen.

Ladda ned en mall för namnområdesmappning.

Överväganden för Windows-filservrar

Om du vill aktivera synkroniseringsfunktionen på Windows Server måste du installera den nedladdningsbara agenten för Azure File Sync. Azure File Sync-agenten innehåller två huvudkomponenter:

• FileSyncSvc.exe, windows-bakgrundstjänsten som ansvarar för att övervaka ändringar på serverslutpunkterna och initiera synkroniseringssessioner
• StorageSync.sys, ett filsystemfilter som möjliggör molnnivåindelning och snabb haveriberedskap

Operativsystemskrav

Azure File Sync stöds med följande versioner av Windows Server:

Vi rekommenderar att du håller alla servrar som du använder med Azure File Sync uppdaterade med de senaste uppdateringarna från Windows Update.

Minsta systemresurser

Azure File Sync kräver en server, antingen fysisk eller virtuell, med alla dessa attribut:

• Minst en PROCESSOR.
• Minst 2 GiB minne. Om servern körs på en virtuell dator med dynamiskt minne aktiverat konfigurerar du den virtuella datorn med minst 2 048 MiB minne.
• En lokalt ansluten volym formaterad med NTFS-filsystemet.

För de flesta produktionsarbetsbelastningar rekommenderar vi inte att du konfigurerar en synkroniseringsserver i Azure File Sync med endast minimikraven.

Rekommenderade systemresurser

Precis som alla serverfunktioner eller program avgör distributionens skala systemresurskraven för Azure File Sync. Större distributioner på en server kräver större systemresurser.

För Azure File Sync avgör antalet objekt över serverslutpunkterna och datamängdens omsättning skalning. En enskild server kan ha serverslutpunkter i flera synkroniseringsgrupper. Antalet objekt som anges i följande tabell står för det fullständiga namnområdet som en server är kopplad till.

Till exempel serverslutpunkt A med 10 miljoner objekt + serverslutpunkt B med 10 miljoner objekt = 20 miljoner objekt. I den här exempeldistributionen rekommenderar vi 8 processorer, 16 GiB minne för stabilt tillstånd och (om möjligt) 48 GiB minne för den initiala migreringen.

Namnområdesdata lagras i minnet av prestandaskäl. På grund av den konfigurationen kräver större namnområden mer minne för att upprätthålla bra prestanda. Mer omsättning kräver fler processorer att bearbeta.

Följande tabell innehåller både namnområdets storlek och en konvertering till kapacitet för vanliga allmänna filresurser, där den genomsnittliga filstorleken är 512 KiB. Om filstorlekarna är mindre kan du överväga att lägga till mer minne för samma mängd kapacitet. Basera minneskonfigurationen på namnområdets storlek.

*Vi rekommenderar inte att du synkroniserar fler än 100 miljoner filer och kataloger. Det här är en mjuk gräns som baseras på våra testade tröskelvärden. Mer information finns i Skalningsmål för Azure File Sync.

Cmdlet för utvärdering

Innan du distribuerar Azure File Sync bör du utvärdera om det är kompatibelt med systemet med hjälp av cmdleten Azure File Sync-utvärdering. Den här cmdleten söker efter potentiella problem med filsystemet och datauppsättningen, till exempel tecken som inte stöds eller en operativsystemversion som inte stöds. Dessa kontroller omfattar de flesta (men inte alla) av de funktioner som nämns i den här artikeln. Vi rekommenderar att du läser igenom resten av det här avsnittet noggrant för att säkerställa att distributionen går smidigt.

Du kan installera utvärderings-cmdleten genom att installera Az PowerShell-modulen. Anvisningar finns i Installera Azure PowerShell.

Förbrukning

Du kan anropa utvärderingsverktyget genom att utföra systemkontroller, datauppsättningskontroller eller både och. Så här utför du både system- och datauppsättningskontroller:

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

Testa bara din dataset:

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

Så här testar du endast systemkrav:

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

Så här visar du resultatet i en .csv fil:

$validation = Invoke-AzStorageSyncCompatibilityCheck C:\DATA
$validation.Results | Select-Object -Property Type, Path, Level, Description, Result | Export-Csv -Path C:\results.csv -Encoding utf8

Filsystemkompatibilitet

Azure File Sync stöds endast på direktanslutna NTFS-volymer. Direktansluten lagring (DAS) på Windows Server innebär att Windows Server-operativsystemet äger filsystemet. Du kan ange DAS genom att fysiskt koppla diskar till filservern, koppla virtuella diskar till en virtuell filserverdator (till exempel en virtuell dator som hanteras av Hyper-V) eller till och med använda iSCSI.

Endast NTFS-volymer stöds. ReFS, FAT, FAT32 och andra filsystem stöds inte.

I följande tabell visas samverkanstillståndet för NTFS-filsystemfunktioner:

Azure File Sync hoppar också över vissa temporära filer och systemmappar:

Ledigt utrymme på din lokala disk

När du planerar att använda Azure File Sync bör du fundera på hur mycket ledigt utrymme du behöver på den lokala disken för serverslutpunkten.

Med Azure File Sync måste du ta hänsyn till följande objekt som tar upp utrymme på din lokala disk:

• Med molnnivåindelning aktiverat:

  • Referenspunkter för nivåindelade filer
  • Azure File Sync-metadatadatabas
  • Azure File Sync-värmelager
  • Fullständigt nedladdade filer i din aktiva cache (om det finns några)
  • Principkrav för ledigt volymutrymme

• Med molnnivåindelning inaktiverad:

  • Fullständigt nedladdade filer
  • Azure File Sync-värmelager
  • Azure File Sync-metadatadatabas

I följande exempel visas hur du beräknar mängden ledigt utrymme som du behöver på din lokala disk. Anta att du har installerat Azure File Sync-agenten på din virtuella Azure Windows-dator och planerar att skapa en serverslutpunkt på disk F. Du har 1 miljon filer (och vill nivåindela dem alla), 100 000 kataloger och en diskklusterstorlek på 4 KiB. Diskstorleken är 1 000 GiB. Du vill aktivera molnnivåindelning och ange volymens princip för ledigt utrymme till 20%.

• NTFS allokerar en klusterstorlek för var och en av de nivåindelade filerna:

  1 miljon filer * 4 KiB-klusterstorlek = 4 000 000 KiB (4 GiB)

  För att dra full nytta av molnnivåindelning rekommenderar vi att du använder mindre NTFS-klusterstorlekar (mindre än 64 KiB) eftersom varje nivåindelad fil upptar ett kluster. Dessutom allokerar NTFS det utrymme som nivåindelade filer upptar. Det här utrymmet visas inte i något användargränssnitt.

• Synkroniseringsmetadata upptar en klusterstorlek per objekt:

  (1 miljon filer + 100 000 kataloger) * 4 KiB-klusterstorlek = 4 400 000 KiB (4,4 GiB)

• Azure File Sync-värmelager upptar 1,1 KiB per fil:

  1 miljon filer * 1,1 KiB = 1 100 000 KiB (1,1 GiB)

• Principen för ledigt utrymme för volym är 20%:

  1000 GiB * 0,2 = 200 GiB

I det här fallet skulle Azure File Sync behöva cirka 209 500 000 KiB (209,5 GiB) utrymme för det här namnområdet. Lägg till den här mängden till allt ledigt utrymme som du tror att du kan behöva för den här disken.

Felöverklustring

Azure File Sync har stöd för Redundanskluster för Windows Server för distributionsalternativet Filserver för allmänt bruk . Mer information om hur du konfigurerar filservern för allmän användning i ett redundanskluster finns i Distribuera en klustrad filserver med två noder.

Det enda scenario som Azure File Sync stöder är ett Windows Server-redundanskluster med klustrade diskar. Redundansklustring stöds inte på Scale-Out filserver, klusterdelade volymer (CSV:er) eller lokala diskar.

För att synkroniseringen ska fungera korrekt måste Azure File Sync-agenten installeras på varje nod i ett redundanskluster.

Datadeduplicering

Windows Server 2025, Windows Server 2022, Windows Server 2019 och Windows Server 2016

Datadeduplicering stöds oavsett om molnnivåindelning är aktiverat eller inaktiverat på en eller flera serverslutpunkter på volymen för Windows Server 2025, Windows Server 2022, Windows Server 2019 och Windows Server 2016. Om du aktiverar Datadeduplicering på en volym med molnnivåindelning aktiverat kan du cachelagra fler filer lokalt utan att etablera mer lagring.

När du aktiverar Datadeduplicering på en volym med molnnivåindelning aktiverat, nivåindelade dedupliceringsoptimerade filer på serverslutpunktens plats på samma sätt som en normal fil, baserat på principinställningarna för molnnivåindelning. När du har nivåindelat dedupliceringsoptimerade filer körs skräpinsamlingsjobbet datadeduplicering automatiskt. Det frigör diskutrymme genom att ta bort onödiga segment som andra filer på volymen inte längre refererar till.

I vissa fall där Datadeduplicering är installerat kan det tillgängliga volymutrymmet öka mer än förväntat när skräpinsamlingen för deduplicering har utlösts. I följande exempel beskrivs hur volymutrymme fungerar:

1. Principen för ledigt utrymme för molnnivåindelning är inställd på 20%.
2. Azure File Sync meddelas när ledigt utrymme är lågt (låt oss säga 19%).
3. Nivåindelning avgör att 1% mer utrymme måste frigöras, men du vill ha 5% extra, så du nivåindelar upp till 25% (till exempel 30 GiB).
4. Filerna är nivåindelade tills du når 30 GiB.
5. Som en del av samverkan med Datadeduplicering initierar Azure File Sync skräpinsamling i slutet av nivåindelningssessionen.

Volymbesparingarna gäller endast för servern. Dina data i Azure-filresursen dedupliceras inte.

Windows Server 2012 R2

Azure File Sync stöder inte datadeduplicering och molnnivåindelning på samma volym på Windows Server 2012 R2. Om du aktiverar Datadeduplicering på en volym måste du inaktivera molnnivåindelning.

Anteckningar

• Om du installerar Datadeduplicering innan du installerar Azure File Sync-agenten krävs en omstart för att stödja datadeduplicering och molnnivåindelning på samma volym.

• Om du aktiverar Datadeduplicering på en volym när du har aktiverat molnnivåindelning optimerar det första dedupliceringsoptimeringsjobbet filer på volymen som inte redan har nivåindelats. Det här jobbet har följande inverkan på molnnivåindelning:

  • Principen för ledigt utrymme fortsätter att nivåindela filer enligt det lediga utrymmet på volymen med hjälp av värmekartan.
  • Datumprincipen hoppar över nivåindelning av filer som annars kan vara berättigade till nivåindelning eftersom optimeringsjobbet för deduplicering har åtkomst till filerna.

• För pågående dedupliceringsoptimeringsjobb fördröjer inställningen För datadeduplicering MinimumFileAgeDays molnnivåindelning med dataprincipen, om filen inte redan är nivåindelad.

  • Om MinimumFileAgeDays inställningen till exempel är 7 dagar och dataprincipen för molnnivåindelning är 30 dagar, nivåindelar datumprincipen filer efter 37 dagar.
  • När Azure File Sync har nivåindelat en fil hoppar dedupliceringsoptimeringsjobbet över filen.

• Om en server som kör Windows Server 2012 R2 med Azure File Sync-agenten installerad uppgraderas till Windows Server 2025, Windows Server 2022, Windows Server 2019 eller Windows Server 2016 måste du utföra följande steg för att stödja datadeduplicering och molnnivåindelning på samma volym:

  1. Avinstallera Azure File Sync-agenten för Windows Server 2012 R2 och starta om servern.
  2. Ladda ned Azure File Sync-agenten för den nya versionen av serveroperativsystemet (Windows Server 2025, Windows Server 2022, Windows Server 2019 eller Windows Server 2016).
  3. Installera Azure File Sync-agenten och starta om servern.

  Servern behåller sina konfigurationsinställningar för Azure File Sync när agenten avinstalleras och installeras om.

Distribuerat filsystem

Azure File Sync stöder samverkan med DFS-namnområden (DFS-N) och DFS Replication (DFS-R).

DFS-N

Azure File Sync stöds fullt ut med implementeringen av DFS-N. Du kan installera Azure File Sync-agenten på en eller flera filservrar för att synkronisera data mellan serverslutpunkterna och molnslutpunkten och sedan använda DFS-N för att tillhandahålla namnområdestjänsten. Mer information finns i översikten över DFS-namnområden och DFS-namnområden med Azure Files.

DFS-R

Eftersom DFS-R och Azure File Sync båda är replikeringslösningar rekommenderar vi att du i de flesta fall ersätter DFS-R med Azure File Sync. Men du bör använda DFS-R och Azure File Sync tillsammans i följande scenarier:

• Du migrerar från en DFS-R-distribution till en Azure File Sync-distribution. Mer information finns i Migrera en DFS-R distribution till Azure File Sync.
• Alla lokala servrar som behöver en kopia av dina fildata kan inte anslutas direkt till Internet.
• Grenservrar konsoliderar data till en enda hubbserver som du vill använda Azure File Sync för.

Så här fungerar Azure File Sync och DFS-R sida vid sida:

• Azure File Sync-molnnivåindelning måste inaktiveras på volymer med DFS-R-replikerade mappar.
• Serverslutpunkter bör inte konfigureras på skrivskyddade DFS-R-replikeringsmappar.
• Endast en enskild serverslutpunkt kan överlappa med en DFS-R-plats. Flera serverslutpunkter som överlappar andra aktiva DFS-R-platser kan leda till konflikter.

Mer information finns i Översikt över DFS-namnområden och DFS-replikering.

Sysprep

Användning av Sysprep på en server som har Azure File Sync-agenten installerad stöds inte och kan leda till oväntade resultat. Agentinstallation och serverregistrering bör ske när du har distribuerat serverbilden och slutfört minikonfigurationen av Sysprep.

Windows-sök

Om molnnivåindelning är aktiverat på en serverslutpunkt hoppar Windows Search över filer som är nivåindelade och inte indexerar dem. Windows Search indexerar filer som inte är nivåindelade korrekt.

Windows-klienter orsakar återkallanden när de söker i filresursen om inställningen Sök alltid efter filnamn och innehåll är aktiverad på klientdatorn. Den här inställningen är inaktiverad som standard.

Andra HSM-lösningar

Du bör inte använda andra HSM-lösningar (hierarkisk lagringshantering) med Azure File Sync.

Prestanda och skalbarhet   

Eftersom Azure File Sync-agenten körs på en Windows Server-dator som ansluter till Azure-filresurserna beror den effektiva synkroniseringsprestandan på dessa faktorer i infrastrukturen:

• Windows Server och den underliggande diskkonfigurationen
• Nätverksbandbredd mellan servern och Azure Storage
• Filstorlek
• Total datamängdsstorlek
• Aktivitet i datauppsättningen

Azure File Sync fungerar på filnivå. Prestandaegenskaperna för en lösning som baseras på Azure File Sync mäts bättre i antalet objekt (filer och kataloger) som bearbetas per sekund.

Mer information finns i Prestandamått för Azure File Sync och Azure File Sync-skalningsmål

Identitet

Administratören som registrerar servern och skapar molnslutpunkten måste vara medlem i hanteringsrollen Azure File Sync Administrator, Owner eller Contributor för lagringssynkroniseringstjänsten. Du kan konfigurera den här rollen under Åtkomstkontroll (IAM) på Azure Portal-sidan för tjänsten för lagringssynkronisering.

När du tilldelar rollen Administratör för Azure File Sync följer du de här stegen för att säkerställa minsta möjliga behörighet.

1. Under fliken Villkor väljer du Tillåt användare att tilldela valda roller till endast valda huvudnamn (färre privilegier).

2. Klicka på Välj roller och huvudnamn och välj sedan Lägg till åtgärd under Villkor nr 1.

3. Välj Skapa rolltilldelning och klicka sedan på Välj.

4. Välj Lägg till uttryck och välj sedan Begär.

5. Under Attributkälla väljer du Rolldefinitions-ID under Attribut och sedan ForAnyOfAnyValues:GuidEquals under Operator.

6. Välj Lägg till roller. Lägg till Läsare och dataåtkomst, Privilegierad lagringsfildeltagare och Lagringskontobidragande deltagare, och välj sedan Spara.

Azure File Sync fungerar med din Active Directory-baserade standardidentitet utan någon särskild konfiguration utöver att konfigurera synkronisering. När du använder Azure File Sync är den allmänna förväntningen att de flesta åtkomster går via Azure File Sync-cachelagringsservrarna i stället för via Azure-filresursen. Eftersom serverslutpunkterna finns på Windows Server och Windows Server stöder Active Directory- och Windows-ACL:er behöver du inget annat än att se till att Windows-filservrarna som registrerats med synkroniseringstjänsten för lagring är domänanslutna. Azure File Sync lagrar ACL:er på filerna i Azure-filresursen och replikerar dessa ACL:er till alla serverslutpunkter.

Även om ändringar som görs direkt i Azure-filresursen tar längre tid att synkronisera till serverslutpunkterna i synkroniseringsgruppen, kanske du också vill se till att du kan framtvinga dina Active Directory-behörigheter på filresursen direkt i molnet. Om du vill göra den här konfigurationen måste du domänansluta ditt lagringskonto till din lokala Active Directory-instans, precis som dina Windows-filservrar är domänanslutna. Mer information om domänanslutning till ditt lagringskonto till en kundägd Active Directory-instans finns i Översikt över Identitetsbaserad autentisering i Azure Files för SMB-åtkomst.

Nätverk

Azure File Sync-agenten kommunicerar med din lagringssynkroniseringstjänst och Azure-filresurs med hjälp av REST-protokollet för Azure File Sync och FileREST-protokollet. Båda dessa protokoll använder alltid HTTPS via port 443. SMB används aldrig för att ladda upp eller ladda ned data mellan din Windows Server-instans och Azure-filresursen. Eftersom de flesta organisationer tillåter HTTPS-trafik via port 443 som ett krav för att besöka de flesta webbplatser, krävs vanligtvis ingen särskild nätverkskonfiguration för att distribuera Azure File Sync.

Baserat på organisationens policy eller unika regelkrav kan du kräva mer restriktiv kommunikation med Azure. Azure File Sync innehåller flera mekanismer för att konfigurera nätverk. Baserat på dina krav kan du:

• Tunnelsynkronisering och filuppladdning/nedladdning av trafik via Azure ExpressRoute eller ett virtuellt privat Azure-nätverk (VPN).
• Använd Azure Files- och Azure-nätverksfunktioner, till exempel tjänstslutpunkter och privata slutpunkter.
• Konfigurera Azure File Sync för att stödja proxyn i din miljö.
• Begränsa nätverksaktiviteten från Azure File Sync.

Om du vill kommunicera med din Azure-filresurs via SMB men port 445 blockeras kan du överväga att använda SMB via QUIC. Den här metoden erbjuder ett VPN med nollkonfiguration för SMB-åtkomst till dina Azure-filresurser via QUIC-transportprotokollet via port 443. Även om Azure Files inte har direkt stöd för SMB via QUIC kan du skapa en enkel cache med dina Azure-filresurser på en virtuell Windows Server 2022 Azure Edition-dator med hjälp av Azure File Sync. Mer information om det här alternativet finns i SMB over QUIC (SMB over QUIC).

Mer information om Azure File Sync och nätverk finns i Nätverksöverväganden för Azure File Sync.

Kryptering

Azure File Sync erbjuder tre krypteringslager: kryptering på den vilande lagringen av Windows Server, kryptering under överföring mellan Azure File Sync-agenten och Azure och kryptering i vila för dina data i Azure-filresursen.

Windows Server-kryptering i vila

Två strategier för att kryptera data på Windows Server fungerar vanligtvis med Azure File Sync:

• Kryptering under filsystemet, så att filsystemet och alla data som skrivs till det krypteras
• Kryptering i själva filformatet

Dessa metoder utesluter inte varandra. Du kan välja att använda dem tillsammans eftersom syftet med kryptering är annorlunda.

Windows Server tillhandahåller en BitLocker-inkorg för att tillhandahålla kryptering under filsystemet. BitLocker är helt transparent för Azure File Sync. De främsta orsakerna till att använda en krypteringsmekanism som BitLocker är:

• Förhindra fysisk exfiltrering av data från ditt lokala datacenter genom att någon stjäl diskarna
• Förhindra separat inläsning av ett obehörigt operativsystem för att utföra obehöriga läsningar och skrivningar till dina data

Mer information finns i Översikt över BitLocker.

Partnerprodukter som fungerar på samma sätt som BitLocker, eftersom de ligger under NTFS-volymen, bör fungera fullständigt och transparent med Azure File Sync.

Den andra huvudmetoden för att kryptera data är att kryptera filens dataström när programmet sparar filen. Vissa program kan göra den här uppgiften internt, men de brukar inte göra det.

Exempelmetoder för att kryptera filens dataström är Azure Information Protection, Azure Rights Management (Azure RMS) och Active Directory Rights Management Services. Den främsta orsaken till att använda en krypteringsmekanism som Azure Information Protection eller Azure RMS är att förhindra exfiltrering av data från filresursen av personer som kopierar dem till alternativa platser (till exempel ett flashminne) eller skickar dem till en obehörig person. När en fils dataström krypteras som en del av filformatet fortsätter den här filen att krypteras på Azure-filresursen.

Azure File Sync samverkar inte med NTFS Encrypted File System eller partnerkrypteringslösningar som ligger ovanför filsystemet men under filens dataström.

Kryptering vid överföring

Azure File Sync-agenten kommunicerar med din lagringssynkroniseringstjänst och Azure-filresurs med hjälp av REST-protokollet för Azure File Sync och FileREST-protokollet. Båda dessa protokoll använder alltid HTTPS via port 443. Azure File Sync skickar inte okrypterade begäranden via HTTP.

Azure Storage-konton innehåller en växel för att kräva kryptering under överföring. Den här växeln är aktiverad som standard. Även om växeln på lagringskontonivå är inaktiverad och okrypterade anslutningar till dina Azure-filresurser är möjliga, använder Azure File Sync fortfarande endast krypterade kanaler för att komma åt din filresurs.

Den främsta orsaken till att inaktivera kryptering under överföring för lagringskontot är att stödja ett äldre program som kommunicerar direkt med Azure-filresursen. Ett sådant program måste köras på ett äldre operativsystem, till exempel Windows Server 2008 R2 eller en äldre Linux-distribution. Om det äldre programmet ansluter till Windows Server-cachen för filresursen har det ingen effekt att ändra den här inställningen.

Vi rekommenderar starkt att du aktiverar kryptering av data under överföring. Mer information om kryptering under överföring finns i Kräv säker överföring för att säkerställa säkra anslutningar.

Azure-filresursdelningskryptering i vila

Alla data som lagras i Azure Files krypteras i vila via Azure Storage-kryptering på tjänstsidan (SSE). SSE fungerar på samma sätt som BitLocker i Windows: data krypteras under filsystemnivån.

Eftersom data krypteras under Azure-filresursens filsystem, eftersom de är kodade till disk, behöver du inte åtkomst till den underliggande nyckeln på klienten för att läsa eller skriva till Azure-filresursen. Kryptering i vila gäller för både SMB- och NFS-protokollen.

Som standard krypteras data som lagras i Azure Files med Microsoft-hanterade nycklar. Med Microsoft-hanterade nycklar innehåller Microsoft nycklarna för att kryptera och dekryptera data. Microsoft ansvarar för att rotera dessa nycklar regelbundet.

Du kan också välja att hantera dina egna nycklar, vilket ger dig kontroll över rotationsprocessen. Om du väljer att kryptera dina filresurser med kundhanterade nycklar har Azure Files behörighet att komma åt dina nycklar för att uppfylla läs- och skrivbegäranden från dina klienter. Med kundhanterade nycklar kan du återkalla den här auktoriseringen när som helst. Men utan den här auktoriseringen är din Azure-filresurs inte längre tillgänglig via SMB eller FileREST-API:et.

Azure Files använder samma krypteringsschema som de andra Azure Storage-tjänsterna, till exempel Azure Blob Storage. Mer information om Azure Storage SSE finns i Azure Storage-kryptering för vilande data.

Lagringsnivåer

Azure Files erbjuder två medienivåer för lagring: solid state-disk (SSD) och hårddisk (HDD). Med de här nivåerna kan du anpassa dina resurser efter prestanda- och priskraven i ditt scenario:

• SSD (premium): SSD-filresurser ger konsekvent hög prestanda och låg svarstid inom ensiffriga millisekunder för de flesta I/O-åtgärder för I/O-intensiva arbetsbelastningar. SSD-filresurser är lämpliga för en mängd olika arbetsbelastningar, till exempel databaser, webbplatsvärdar och utvecklingsmiljöer.

  Du kan använda SSD-filresurser med både SMB- och NFS-protokollen. SSD-filresurser är tillgängliga i de etablerade v2 - och etablerade v1-faktureringsmodellerna . SSD-filresurser erbjuder ett serviceavtal med högre tillgänglighet än HDD-filresurser.

• HDD (standard): HDD-filresurser ger ett kostnadseffektivt lagringsalternativ för allmänna filresurser. HDD-filresurser är tillgängliga med de etablerade v2- och betala per användning-faktureringsmodellerna, även om vi rekommenderar den etablerade v2-modellen för nya distributioner av filresurser. Mer information om serviceavtalet finns på azure-SLA-sidan för onlinetjänster.

När du väljer en medienivå för din arbetsbelastning bör du överväga dina prestanda- och användningskrav. Om din arbetsbelastning kräver ensiffrig svarstid, eller om du använder SSD-lagringsmedia lokalt, passar SSD-filresurser förmodligen bäst. Om låg svarstid inte är lika mycket ett problem kan HDD-filresurser passa bättre ur ett kostnadsperspektiv. Till exempel kan korta svarstider vara mindre problem med teamresurser som monterats lokalt från Azure eller cachelagrats lokalt via Azure File Sync.

När du har skapat en filresurs i ett lagringskonto kan du inte flytta den direkt till en annan medienivå. Om du till exempel vill flytta en HDD-filresurs till SSD-medienivån måste du skapa en ny SSD-filresurs och kopiera data från den ursprungliga resursen till den nya filresursen.

Du hittar mer information om SSD- och HDD-medienivåerna i Förstå Azure Files-faktureringsmodeller och Förstå och optimera Prestanda för Azure-filresurser.

Tillgänglighet för Azure File Sync-regionen

Regional tillgänglighet finns i Produkttillgänglighet per region och sök efter lagringskonton.

Följande regioner kräver att du begär åtkomst till Azure Storage innan du kan använda Azure File Sync:

• Södra Frankrike
• Sydafrika, västra
• Centrala UAE

Om du vill begära åtkomst för dessa regioner följer du processen i den här artikeln.

Redundans

För att skydda data i dina Azure-filresurser mot dataförlust eller skada lagrar Azure Files flera kopior av varje fil när de skrivs. Beroende på dina krav kan du välja redundansgrader. Azure Files stöder för närvarande följande alternativ för dataredundans:

• Lokalt redundant lagring (LRS): Med lokal redundans lagras varje fil tre gånger i ett Azure-lagringskluster. Den här metoden hjälper till att skydda mot dataförlust på grund av maskinvarufel, till exempel en felaktig diskenhet. Men om en katastrof, till exempel brand eller översvämning inträffar i datacentret, kan alla repliker av ett lagringskonto som använder LRS gå förlorade eller oåterkalleliga.

• Zonredundant lagring (ZRS): Med zonredundans lagras tre kopior av varje fil. Dessa kopior är dock fysiskt isolerade i tre olika lagringskluster i Azure-tillgänglighetszoner. Tillgänglighetszoner är unika fysiska platser i en Azure-region. Varje zon består av ett eller flera datacenter som är utrustade med oberoende ström, kylning och nätverk. En skrivoperation till lagring accepteras inte förrän den har skrivits till lagringskluster i alla tre tillgänglighetszoner.

• Geo-redundant lagring (GRS): Med geo-redundans har du en primär region och en sekundär region. Filer lagras tre gånger i ett Azure-lagringskluster i den primära regionen. Skrivningar replikeras asynkront till en Microsoft-definierad sekundär region.

  Geo-redundans ger sex kopior av din dataspridning mellan de två Azure-regionerna. Om en större katastrof inträffar, till exempel permanent förlust av en Azure-region på grund av en naturkatastrof eller någon annan liknande händelse, utför Microsoft en redundansväxling. I det här fallet blir den sekundära den primära och hanterar alla åtgärder.

  Eftersom replikeringen mellan de primära och sekundära regionerna är asynkron går data som inte replikerats till den sekundära regionen förlorade om ett större haveri inträffar. Du kan också utföra en manuell övertagning av ett geografiskt redundant lagringskonto.

• Geo-zonredundant lagring (GZRS): Med geo-zonredundans lagras filer tre gånger över tre distinkta lagringskluster i den primära regionen. Alla skrivningar replikeras sedan asynkront till en Microsoft-definierad sekundär region. Redundansväxlingsprocessen för geo-zonredundans fungerar på samma sätt som för geo-redundans.

HDD-filresurser stöder alla fyra redundanstyper. SSD-filresurser stöder endast LRS och ZRS.

Betala per användning-lagringskonton ger två andra redundansalternativ som Azure Files inte stöder: geo-redundant lagring med läsåtkomst (RA-GRS) och geo-zonredundant lagring med läsåtkomst (RA-GZRS). Du kan etablera Azure-filresurser i lagringskonton med dessa alternativ inställda, men Azure Files stöder inte läsning från den sekundära regionen. Azure-filresurser som distribueras till RA-GRS eller RA-GZRS lagringskonton faktureras som geo-redundanta respektive geo-zonredundanta.

Migrering

Om du har en befintlig filserver i Windows Server 2012 R2 eller senare kan du installera Azure File Sync direkt. Du behöver inte flytta data till en ny server.

Om du planerar att migrera till en ny Windows-filserver som en del av införandet av Azure File Sync, eller om dina data för närvarande finns på NAS, finns det flera möjliga migreringsmetoder för att använda Azure File Sync med dessa data. Vilken migreringsmetod du ska välja beror på var dina data finns för närvarande.

Detaljerad vägledning finns i Migrera till SMB Azure-filresurser.

Antivirus

Eftersom antivirusprogram fungerar genom att söka igenom filer efter känd skadlig kod kan ett antivirusprogram orsaka återkallande av nivåindelade filer och höga avgifter för utgående trafik. Nivåindelade filer har den säkra Windows-attributuppsättningen FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS . Vi rekommenderar att du konsulterar programvaruleverantören för att lära dig hur du konfigurerar dess lösning för att hoppa över att läsa filer som har den här attributuppsättningen. Många gör det automatiskt.

Vid genomsökningar på begäran hoppar antiviruslösningarna Microsoft Defender och System Center Endpoint Protection automatiskt över att läsa filer som har den här attributuppsättningen. Vi har testat dem och identifierat ett mindre problem: när du lägger till en server i en befintlig synkroniseringsgrupp återkallas filer som är mindre än 800 byte (laddas ned) på den nya servern. Filerna finns kvar på den nya servern och är inte nivåindelade eftersom de inte uppfyller kravet på nivåindelningsstorlek (mer än 64 KiB).

Antivirusleverantörer kan kontrollera kompatibiliteten mellan sina produkter och Azure File Sync med hjälp av Azure File Sync Antivirus Compatibility Test Suite i Microsoft Download Center.

Säkerhetskopia

Om du aktiverar molnnivåindelning ska du inte använda lösningar som direkt säkerhetskopierar serverslutpunkten eller en virtuell dator som innehåller serverslutpunkten.

Molnnivåindelning gör att endast en delmängd av dina data lagras på serverslutpunkten. Den fullständiga datamängden finns i din Azure-filresurs. Beroende på vilken säkerhetskopieringslösning du använder är nivåindelade filer antingen:

• Hoppades över och säkerhetskopierades inte eftersom de har FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS attributet inställt
• Återkallas till disk, vilket resulterar i höga utgående avgifter

Vi rekommenderar att du använder en lösning för molnsäkerhetskopiering för att säkerhetskopiera Azure-filresursen direkt. Mer information finns i Om Säkerhetskopiering av Azure Files. Eller fråga din säkerhetskopieringsprovider om den stöder säkerhetskopiering av Azure-filresurser.

Om du föredrar att använda en lokal säkerhetskopieringslösning utför du säkerhetskopiorna på en server i synkroniseringsgruppen som har molnnivåinaktivering inaktiverad. Kontrollera att det inte finns några nivåindelade filer.

När du utför en återställning använder du återställningsalternativet på volymnivå eller filnivå. Filer som återställs via återställningsalternativet på filnivå synkroniseras till alla slutpunkter i synkroniseringsgruppen. Befintliga filer ersätts med den version som återställs från säkerhetskopian. Återställningar på volymnivå ersätter inte nyare filversioner i Azure-filresursen eller andra serverslutpunkter.

Dataklassificering

Om du har installerat programvara för dataklassificering ökar kostnaderna för molnnivåindelning av två orsaker:

• När molnnivåindelningen är aktiverad cachelagras de hetaste filerna lokalt. De coolaste filerna är nivåindelade till Azure-filresursen i molnet. Om din dataklassificering regelbundet söker igenom alla filer i filresursen måste de filer som är nivåindelade i molnet återkallas när de genomsöks.
• Om dataklassificeringsprogramvaran använder metadata i dataströmmen för en fil måste filen återkallas helt för att programvaran ska kunna identifiera klassificeringen.

Dessa ökningar, både i antalet återkallelser och mängden data som återkallas, kan öka kostnaderna.

Uppdateringsprincip för Azure File Sync-agenten

Azure File Sync-agenten uppdateras regelbundet för att lägga till nya funktioner och åtgärda problem. Vi rekommenderar att du uppdaterar Azure File Sync-agenten när nya versioner är tillgängliga.

Huvudversioner jämfört med mindre agentversioner

• Större agentversioner innehåller ofta nya funktioner och har ett större nummer som den första siffran i versionsnumret. Till exempel: 18.0.0.0.
• Mindre agentversioner kallas även korrigeringar och släpps oftare än större versioner. De innehåller ofta felkorrigeringar och mindre förbättringar men inga nya funktioner. Till exempel: 18.2.0.0.

Uppdatera sökvägar

Det finns fem godkända och testade sätt att installera Azure File Sync-agentuppdateringarna:

• Använd funktionen automatisk uppdatering i Azure File Sync för att installera agentuppdateringar: Azure File Sync-agenten uppdateras automatiskt. Du kan välja att installera den senaste agentversionen när den är tillgänglig eller uppdateras när den för närvarande installerade agenten snart upphör att gälla. Mer information finns i nästa avsnitt , Automatisk hantering av agentlivscykeln.
• Konfigurera Microsoft Update för att automatiskt ladda ned och installera agentuppdateringar: Vi rekommenderar att du installerar varje Azure File Sync-uppdatering för att säkerställa att du har åtkomst till de senaste korrigeringarna för serveragenten. Microsoft Update gör den här processen sömlös genom att automatiskt ladda ned och installera uppdateringar åt dig.
• Använd AfsUpdater.exe för att ladda ned och installera agentuppdateringar: Filen AfsUpdater.exe finns i agentinstallationskatalogen. Dubbelklicka på den körbara filen för att ladda ned och installera agentuppdateringar. Beroende på versionsversionen kan du behöva starta om servern.
• Korrigera en befintlig Azure File Sync-agent med hjälp av en Microsoft Update-korrigeringsfil eller en körbar .msp-fil: Du kan ladda ned det senaste Azure File Sync-uppdateringspaketet från Microsoft Update-katalogen. Om du kör en körbar .msp-fil uppdateras din Azure File Sync-installation med samma metod som Microsoft Update använder automatiskt. Om du tillämpar en Microsoft Update-korrigering utförs en uppdatering på plats av en Azure File Sync-installation.
• Ladda ned det senaste installationsprogrammet för Azure File Sync-agenten: Du kan hämta installationsprogrammet i Microsoft Download Center. Om du vill uppdatera en befintlig Azure File Sync-agentinstallation avinstallerar du den äldre versionen och installerar sedan den senaste versionen från det nedladdade installationsprogrammet. Agentinställningar (till exempel serverregistrering och serverslutpunkter) upprätthålls när Azure File Sync-agenten avinstalleras.

Automatisk hantering av agentens livscykel

Azure File Sync-agenten uppdateras automatiskt. Du kan välja något av följande lägen och ange ett underhållsperiod där uppdateringen görs på servern. Den här funktionen är utformad för att hjälpa dig med agentens livscykelhantering genom att antingen tillhandahålla ett skyddsräcke som hindrar din agent från att upphöra att gälla eller för att möjliggöra en inställning för att hålla dig uppdaterad.

• Standardinställningen försöker förhindra att agenten upphör att gälla. Inom 21 dagar efter det publicerade förfallodatumet för en agent försöker agenten uppdatera sig själv. Det startar ett uppdateringsförsök en gång i veckan inom 21 dagar före förfallodatum och i det valda underhållsfönstret. Observera att det här alternativet inte eliminerar behovet av regelbundna Microsoft Update-korrigeringar.

• Du kan välja att agenten automatiskt ska uppdateras så snart en ny agentversion blir tillgänglig. Den här möjligheten gäller för närvarande inte för klustrade servrar.

  Den här uppdateringen sker under det valda underhållsfönstret och gör att servern kan dra nytta av nya funktioner och förbättringar så snart de blir allmänt tillgängliga. Den här rekommenderade, bekymmersfria inställningen innehåller viktiga agentversioner och vanliga uppdateringskorrigeringar till servern. Varje agent som släpps är i GA-kvalitet.

  Om du väljer det här alternativet kommer Microsoft att skicka den senaste agentversionen till dig. Kluster servrar utesluts. När flygresan är klar blir agenten också tillgänglig i Microsoft Update och Microsoft Download Center.

Ändra inställningen för automatisk uppdatering

Följande instruktioner beskriver hur du ändrar inställningarna när du har slutfört installationsprogrammet, om du behöver göra ändringar.

Öppna en PowerShell-konsol och gå till katalogen där du installerade synkroniseringsagenten och importera sedan server-cmdletarna. Som standard ser den här åtgärden ut ungefär som i följande exempel:

cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll

Du kan köra Get-StorageSyncAgentAutoUpdatePolicy för att kontrollera den aktuella principinställningen och avgöra om du vill ändra den.

Om du vill ändra den aktuella principinställningen till det fördröjda uppdateringsspåret kan du använda:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

Om du vill ändra den aktuella principinställningen till det omedelbara uppdateringsspåret kan du använda:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest -Day <day> -Hour <hour>

Garantier för agentlivscykel och ändringshantering

Azure File Sync är en molntjänst som kontinuerligt introducerar nya funktioner och förbättringar. En specifik Azure File Sync-agentversion kan endast stödjas under en begränsad tid. För att underlätta distributionen garanterar följande regler att du har tillräckligt med tid och meddelanden för att hantera agentuppdateringar i din ändringshanteringsprocess:

• Större agentversioner stöds i minst 12 månader från den första versionen.
• Det finns en överlappning på minst 3 månader mellan stöd för större agentversioner.
• Varningar utfärdas för registrerade servrar via en snartto-be utgången agent minst 3 månader innan den upphör att gälla. Du kan kontrollera om en registrerad server använder en äldre version av agenten i avsnittet om registrerade servrar i en lagringssynkroniseringstjänst.
• Livslängden för en mindre agentversion är bunden till den relaterade huvudversionen. När agentversion 18.0.0.0 till exempel är inställd på att upphöra att gälla upphör agentversionerna 18.*.*.* att gälla tillsammans.

Relaterat innehåll

• Proxy- och brandväggsinställningar för Azure File Sync
• Skapa en SMB Azure-filresurs
• Distribuera Azure File Sync
• Övervaka Azure File Sync