Calamiteitenherstel SharePoint Server 2013 in Microsoft Azure

Met Behulp van Azure kunt u een omgeving voor herstel na noodgevallen maken voor uw on-premises SharePoint-farm. In dit artikel wordt beschreven hoe u deze oplossing ontwerpt en implementeert.

Bekijk de video overzicht van herstel na noodgevallen in SharePoint Server 2013

Wanneer zich een noodgeval voordoet in uw on-premises SharePoint-omgeving, is het uw hoogste prioriteit om het systeem snel weer te laten werken. Herstel na noodgevallen met SharePoint gaat sneller en gemakkelijker wanneer u al een back-upomgeving hebt die al wordt uitgevoerd in Microsoft Azure. In deze video worden de belangrijkste concepten van een warme SharePoint-failoveromgeving uitgelegd en wordt een aanvulling geboden op de volledige details die beschikbaar zijn in dit artikel.

Gebruik dit artikel met het volgende oplossingsmodel: Herstel na noodgevallen van SharePoint in Microsoft Azure.

PDF | Visio

Azure Infrastructure Services gebruiken voor herstel na noodgevallen

Veel organisaties hebben geen omgeving voor herstel na noodgevallen voor SharePoint, wat duur kan zijn om on-premises te bouwen en te onderhouden. Azure Infrastructure Services biedt aantrekkelijke opties voor omgevingen voor herstel na noodgevallen die flexibeler en goedkoper zijn dan de on-premises alternatieven.

De voordelen van het gebruik van Azure Infrastructure Services zijn:

• Minder kostbare resources Onderhoud en betaal voor minder resources dan on-premises omgevingen voor herstel na noodgevallen. Het aantal resources is afhankelijk van de omgeving voor herstel na noodgevallen die u kiest: koude stand-by, warme stand-by of hot standby.

• Betere resourceflexybiliteit In het geval van een noodgeval kunt u uw SharePoint-herstelfarm eenvoudig uitschalen om te voldoen aan de belastingsvereisten. Schaal in wanneer u de resources niet meer nodig hebt.

• Lagere datacenter commitment Gebruik Azure Infrastructure Services in plaats van te investeren in een secundair datacenter in een andere regio.

Er zijn minder complexe opties voor organisaties die net aan de slag gaan met herstel na noodgevallen en geavanceerde opties voor organisaties met vereisten voor hoge tolerantie. De definities voor koude, warme en warme stand-byomgevingen verschillen enigszins wanneer de omgeving wordt gehost op een cloudplatform. In de volgende tabel worden deze omgevingen beschreven voor het bouwen van een SharePoint-herstelfarm in Azure.

Tabel: Herstelomgevingen

Type herstelomgeving	Omschrijving
Hot	Een farm van volledige grootte wordt ingericht, bijgewerkt en uitgevoerd op stand-by.
Warme	De farm is gebouwd en virtuele machines worden uitgevoerd en bijgewerkt. Herstel omvat het koppelen van inhoudsdatabases, het inrichten van servicetoepassingen en het verkennen van inhoud. De farm kan een kleinere versie van de productiefarm zijn en vervolgens worden uitgeschaald om het volledige gebruikersbestand te bedienen.
Koude	De farm is volledig gebouwd, maar de virtuele machines worden gestopt. Het onderhouden van de omgeving omvat het van tijd tot tijd starten van de virtuele machines, patchen, bijwerken en controleren van de omgeving. Start de volledige omgeving in het geval van een noodgeval.

Het is belangrijk om de RPO's (Recovery Time Objectives) en Recovery Point Objectives (RPO's) van uw organisatie te evalueren. Deze vereisten bepalen welke omgeving de meest geschikte investering is voor uw organisatie.

In de richtlijnen in dit artikel wordt beschreven hoe u een warme stand-byomgeving implementeert. U kunt deze ook aanpassen aan een koude stand-by-omgeving, hoewel u aanvullende procedures moet volgen om dit soort omgevingen te ondersteunen. In dit artikel wordt niet beschreven hoe u een dynamische stand-byomgeving implementeert.

Zie Concepten voor hoge beschikbaarheid en herstel na noodgevallen in SharePoint 2013 en Een strategie voor herstel na noodgevallen kiezen voor SharePoint 2013 voor meer informatie over oplossingen voor herstel na noodgevallen.

Beschrijving van de oplossing

Voor de warme stand-by-oplossing voor herstel na noodgevallen is de volgende omgeving vereist:

• Een on-premises SharePoint-productiefarm

• Een SharePoint-farm voor herstel in Azure

• Een site-naar-site-VPN-verbinding tussen de twee omgevingen

In de volgende afbeelding ziet u deze drie elementen.

Afbeelding: Elementen van een warme stand-by-oplossing in Azure

SQL Server logboekverzending met DFSR (Distributed File System Replication) wordt gebruikt om databaseback-ups en transactielogboeken te kopiëren naar de herstelfarm in Azure:

• DFSR brengt logboeken over van de productieomgeving naar de herstelomgeving. In een WAN-scenario is DFSR efficiënter dan de logboeken rechtstreeks naar de secundaire server in Azure te verzenden.

• Logboeken worden opnieuw afgespeeld op de SQL Server in de herstelomgeving in Azure.

• U voegt pas in de herstelomgeving verzonden SharePoint-inhoudsdatabases bij in het logboek totdat er een hersteloefening is uitgevoerd.

Voer de volgende stappen uit om de farm te herstellen:

1. Logboekverzending stoppen.

2. Stop met het accepteren van verkeer naar de primaire farm.

3. De uiteindelijke transactielogboeken opnieuw afspelen.

4. Koppel de inhoudsdatabases aan de farm.

5. Servicetoepassingen herstellen vanuit de gerepliceerde servicesdatabases.

6. Werk DNS-records (Domain Name System) bij zodat deze verwijzen naar de herstelfarm.

7. Start een volledige verkenning.

We raden u aan deze stappen regelmatig te oefenen en te documenteren om ervoor te zorgen dat uw live herstel soepel verloopt. Het koppelen van inhoudsdatabases en het herstellen van servicetoepassingen kan enige tijd duren en omvat meestal een handmatige configuratie.

Nadat een herstel is uitgevoerd, biedt deze oplossing de items in de volgende tabel.

Tabel: Doelstellingen voor oplossingsherstel

Item	Beschrijving
Sites en inhoud	Sites en inhoud zijn beschikbaar in de herstelomgeving.
Een nieuw exemplaar van zoeken	In deze warme stand-byoplossing wordt zoeken niet hersteld vanuit zoekdatabases. Zoekonderdelen in de herstelfarm zijn zo geconfigureerd mogelijk op dezelfde manier als de productiefarm. Nadat de sites en inhoud zijn hersteld, wordt een volledige verkenning gestart om de zoekindex opnieuw te bouwen. U hoeft niet te wachten tot de verkenning is voltooid om de sites en inhoud beschikbaar te maken.
Services	Services die gegevens in databases opslaan, worden hersteld vanuit de logboekdatabases. Services die geen gegevens in databases opslaan, worden gewoon gestart. Niet alle services met databases hoeven te worden hersteld. De volgende services hoeven niet te worden hersteld vanuit databases en kunnen eenvoudig worden gestart na een failover: Gebruiks- en statusgegevens verzamelen Statusservice Word automation Elke andere service die geen database gebruikt

U kunt samenwerken met Microsoft Consulting Services (MCS) of een partner om complexere hersteldoelstellingen te realiseren. Deze worden samengevat in de volgende tabel.

Tabel: Andere items die kunnen worden aangepakt door MCS of een partner

Item	Beschrijving
Aangepaste farmoplossingen synchroniseren	Idealiter is de configuratie van de herstelfarm identiek aan de productiefarm. U kunt samenwerken met een consultant of partner om te evalueren of aangepaste farmoplossingen worden gerepliceerd en of het proces aanwezig is om de twee omgevingen gesynchroniseerd te houden.
Verbindingen met on-premises gegevensbronnen	Het is mogelijk niet praktisch om verbindingen met back-endgegevenssystemen te repliceren, zoals BDC-verbindingen (back-updomeincontroller) en zoekinhoudsbronnen.
Herstelscenario's zoeken	Omdat zoekimplementaties voor ondernemingen meestal vrij uniek en complex zijn, vereist het herstellen van zoekopdrachten vanuit databases een grotere investering. U kunt samenwerken met een consultant of partner om zoekherstelscenario's te identificeren en te implementeren die uw organisatie mogelijk nodig heeft.

In de richtlijnen in dit artikel wordt ervan uitgegaan dat de on-premises farm al is ontworpen en geïmplementeerd.

Gedetailleerde architectuur

Idealiter is de configuratie van de herstelfarm in Azure identiek aan de on-premises productiefarm, waaronder de volgende:

• Dezelfde weergave van serverfuncties

• Dezelfde configuratie van aanpassingen

• Dezelfde configuratie van zoekonderdelen

De omgeving in Azure kan een kleinere versie van de productiefarm zijn. Als u van plan bent om de herstelfarm na een failover uit te schalen, is het belangrijk dat elk type serverfunctie in eerste instantie wordt weergegeven.

Sommige configuraties zijn mogelijk niet praktisch om te repliceren in de failoveromgeving. Zorg ervoor dat u de failoverprocedures en -omgeving test om ervoor te zorgen dat de failoverfarm het verwachte serviceniveau biedt.

Deze oplossing schrijft geen specifieke topologie voor een SharePoint-farm voor. De focus van deze oplossing is het gebruik van Azure voor de failoverfarm en het implementeren van logboekverzending en DFSR tussen de twee omgevingen.

Warme stand-byomgevingen

In een warme stand-byomgeving worden alle virtuele machines in de Azure-omgeving uitgevoerd. De omgeving is gereed voor een failover-oefening of gebeurtenis.

In de volgende afbeelding ziet u een oplossing voor herstel na noodgevallen van een on-premises SharePoint-farm naar een SharePoint-farm op basis van Azure die is geconfigureerd als een warme stand-byomgeving.

Afbeelding: Topologie en belangrijke elementen van een productiefarm en een warm stand-by-herstelfarm

In dit diagram:

• Er worden twee omgevingen naast elkaar weergegeven: de on-premises SharePoint-farm en de warme stand-byfarm in Azure.

• Elke omgeving bevat een bestandsshare.

• Elke farm bevat vier lagen. Om hoge beschikbaarheid te bereiken, bevat elke laag twee servers of virtuele machines die identiek zijn geconfigureerd voor een specifieke rol, zoals front-endservices, gedistribueerde cache, back-endservices en databases. Het is in deze afbeelding niet belangrijk om specifieke onderdelen aan te roepen. De twee farms zijn identiek geconfigureerd.

• De vierde laag is de databaselaag. Logboekverzending wordt gebruikt om logboeken van de secundaire databaseserver in de on-premises omgeving te kopiëren naar de bestandsshare in dezelfde omgeving.

• DFSR kopieert bestanden van de bestandsshare in de on-premises omgeving naar de bestandsshare in de Azure-omgeving.

• Logboekverzending herhaalt de logboeken van de bestandsshare in de Azure-omgeving naar de primaire replica in de SQL Server AlwaysOn-beschikbaarheidsgroep in de herstelomgeving.

Koude stand-byomgevingen

In een koude stand-byomgeving kunnen de meeste virtuele machines van de SharePoint-farm worden afgesloten. (We raden u aan de virtuele machines af en toe te starten, bijvoorbeeld om de twee weken of eenmaal per maand, zodat elke virtuele machine kan worden gesynchroniseerd met het domein.) De volgende virtuele machines in de Azure-herstelomgeving moeten actief blijven om continue bewerkingen van logboekverzending en DFSR te garanderen:

• De bestandsshare

• De primaire databaseserver

• Ten minste één virtuele machine waarop Windows Server Active Directory Domain Services en DNS wordt uitgevoerd

In de volgende afbeelding ziet u een Azure-failoveromgeving waarin de virtuele machine van de bestandsshare en de primaire virtuele machine van de SharePoint-database worden uitgevoerd. Alle andere virtuele SharePoint-machines worden gestopt. De virtuele machine waarop Windows Server Active Directory en DNS wordt uitgevoerd, wordt niet weergegeven.

Afbeelding: Koude stand-by-herstelfarm met actieve virtuele machines

Na een failover naar een koude stand-by-omgeving worden alle virtuele machines gestart en moet de methode voor het bereiken van hoge beschikbaarheid van de databaseservers worden geconfigureerd, zoals SQL Server AlwaysOn-beschikbaarheidsgroepen.

Als er meerdere opslaggroepen worden geïmplementeerd (databases zijn verdeeld over meer dan één SQL Server set met hoge beschikbaarheid), moet de primaire database voor elke opslaggroep worden uitgevoerd om de logboeken te accepteren die zijn gekoppeld aan de opslaggroep.

Vaardigheden en ervaring

Er worden meerdere technologieën gebruikt in deze oplossing voor herstel na noodgevallen. Om ervoor te zorgen dat deze technologieën werken zoals verwacht, moet elk onderdeel in de on-premises en Azure-omgeving correct worden geïnstalleerd en geconfigureerd. We raden aan dat de persoon of het team die deze oplossing instelt, beschikt over een sterke werkkennis en praktische vaardigheden met de technologieën die in de volgende artikelen worden beschreven:

• Distributed File System (DFS) Replication Services

• Windows Server Failover Clustering (WSFC) met SQL Server

• AlwaysOn-beschikbaarheidsgroepen (SQL Server)

• Back-ups maken en terugzetten van SQL Server-databases

• Installatie en farmimplementatie van SharePoint Server 2013

• Microsoft Azure

Ten slotte raden we scriptvaardigheden aan die u kunt gebruiken om taken te automatiseren die aan deze technologieën zijn gekoppeld. Het is mogelijk om de beschikbare gebruikersinterfaces te gebruiken om alle taken uit te voeren die in deze oplossing worden beschreven. Een handmatige aanpak kan echter tijdrovend en foutgevoelig zijn en inconsistente resultaten opleveren.

Naast Windows PowerShell zijn er ook Windows PowerShell bibliotheken voor SQL Server, SharePoint Server en Azure. Vergeet T-SQL niet, wat ook kan helpen bij het verkorten van de tijd voor het configureren en onderhouden van uw omgeving voor herstel na noodgevallen.

Roadmap voor herstel na noodgevallen

In deze roadmap wordt ervan uitgegaan dat u al een SharePoint Server 2013-farm in productie hebt geïmplementeerd.

Tabel: Roadmap voor herstel na noodgevallen

Fase	Omschrijving
Fase 1	Ontwerp de omgeving voor herstel na noodgevallen.
Fase 2	Maak het virtuele Azure-netwerk en de VPN-verbinding.
Fase 3	Implementeer Windows Active Directory en Domain Name Services in het virtuele Azure-netwerk.
Fase 4	Implementeer de SharePoint-herstelfarm in Azure.
Fase 5	DFSR tussen de farms instellen.
Fase 6	Logboekverzending naar de herstelfarm instellen.
Fase 7	Failover- en hersteloplossingen valideren. Dit omvat de volgende procedures en technologieën: Logboekverzending stoppen. Herstel de back-ups. Inhoud verkennen. Services herstellen. DNS-records beheren.

Fase 1: de omgeving voor herstel na noodgevallen ontwerpen

Gebruik de richtlijnen in Microsoft Azure Architectures voor SharePoint 2013 om de omgeving voor herstel na noodgevallen te ontwerpen, inclusief de SharePoint-herstelfarm. U kunt de afbeeldingen in de SharePoint-oplossing voor herstel na noodgevallen in Het Azure Visio-bestand gebruiken om het ontwerpproces te starten. U wordt aangeraden de hele omgeving te ontwerpen voordat u begint met werken in de Azure-omgeving.

Naast de richtlijnen in Microsoft Azure Architectures voor SharePoint 2013 voor het ontwerpen van het virtuele netwerk, vpn-verbinding, Active Directory en SharePoint-farm, moet u een bestandssharerol toevoegen aan de Azure-omgeving.

Ter ondersteuning van logboekverzending in een oplossing voor herstel na noodgeval wordt een virtuele machine voor bestandsshares toegevoegd aan het subnet waarin de databaserollen zich bevinden. De bestandsshare fungeert ook als het derde knooppunt van een Node Majority voor de SQL Server AlwaysOn-beschikbaarheidsgroep. Dit is de aanbevolen configuratie voor een standaard SharePoint-farm die gebruikmaakt van SQL Server AlwaysOn-beschikbaarheidsgroepen.

Opmerking

Het is belangrijk om de vereisten voor een database te controleren om deel te nemen aan een SQL Server AlwaysOn-beschikbaarheidsgroep. Zie Vereisten, beperkingen en aanbevelingen voor AlwaysOn-beschikbaarheidsgroepen voor meer informatie.

Afbeelding: Plaatsing van een bestandsserver die wordt gebruikt voor een oplossing voor herstel na noodgevallen

In dit diagram wordt een virtuele machine met bestandsshares toegevoegd aan hetzelfde subnet in Azure dat de databaseserverfuncties bevat. Voeg de virtuele machine van de bestandsshare niet toe aan een beschikbaarheidsset met andere serverfuncties, zoals de SQL Server-rollen.

Als u zich zorgen maakt over de hoge beschikbaarheid van de logboeken, kunt u een andere benadering kiezen door SQL Server back-up en herstel te gebruiken met Azure Blob Storage Service. Dit is een nieuwe functie in Azure waarmee logboeken rechtstreeks in een blobopslag-URL worden opgeslagen. Deze oplossing bevat geen richtlijnen voor het gebruik van deze functie.

Wanneer u de herstelfarm ontwerpt, moet u er rekening mee houden dat een geslaagde herstelomgeving na noodgeval nauwkeurig de productiefarm weergeeft die u wilt herstellen. De grootte van de herstelfarm is niet het belangrijkste in het ontwerp, de implementatie en het testen van de herstelfarm. De schaal van de farm verschilt per organisatie op basis van bedrijfsvereisten. Het is mogelijk om een uitgeschaalde farm te gebruiken voor een korte storing of totdat u de farm moet schalen.

Configureer de herstelfarm zo identiek mogelijk aan de productiefarm, zodat deze voldoet aan uw SLA-vereisten (Service Level Agreement) en de functionaliteit biedt die u nodig hebt om uw bedrijf te ondersteunen. Wanneer u de omgeving voor herstel na noodgevallen ontwerpt, kijkt u ook naar het wijzigingsbeheerproces voor uw productieomgeving. U wordt aangeraden het wijzigingsbeheerproces uit te breiden naar de herstelomgeving door de herstelomgeving met hetzelfde interval als de productieomgeving bij te werken. Als onderdeel van het wijzigingsbeheerproces raden we u aan een gedetailleerde inventarisatie van uw farmconfiguratie, toepassingen en gebruikers bij te houden.

Fase 2: Het virtuele Azure-netwerk en de VPN-verbinding maken

Een on-premises netwerk verbinden met een virtueel Microsoft Azure-netwerk laat zien hoe u het virtuele netwerk in Azure kunt plannen en implementeren en hoe u de VPN-verbinding maakt. Volg de richtlijnen in het onderwerp om de volgende procedures te voltooien:

• Plan de privé-IP-adresruimte van de Virtual Network.

• Plan de wijzigingen in de routeringsinfrastructuur voor de Virtual Network.

• Plan firewallregels voor verkeer van en naar het on-premises VPN-apparaat.

• Maak het cross-premises virtuele netwerk in Azure.

• Configureer routering tussen uw on-premises netwerk en de Virtual Network.

Fase 3: Active Directory en Domain Name Services implementeren in het virtuele Azure-netwerk

Deze fase omvat het implementeren van zowel Windows Server Active Directory als DNS in de Virtual Network in een hybride scenario, zoals beschreven in Microsoft Azure Architectures voor SharePoint 2013 en zoals geïllustreerd in de volgende afbeelding.

Afbeelding: Configuratie van hybride Active Directory-domein

In de afbeelding worden twee virtuele machines geïmplementeerd in hetzelfde subnet. Deze virtuele machines hosten elk twee rollen: Active Directory en DNS.

Lees Richtlijnen voor het implementeren van Windows Server Active Directory in Azure Virtual Machines voordat u Active Directory implementeert in Azure. Aan de hand van deze richtlijnen kunt u bepalen of u een andere architectuur of andere configuratie-instellingen voor uw oplossing nodig hebt.

Zie Install a Replica Active Directory-domein Controller in Azure Virtual Networks (Een replica-Active Directory-domein-controller installeren in Azure Virtual Networks) voor gedetailleerde richtlijnen voor het instellen van een domeincontroller in Azure.

Vóór deze fase hebt u geen virtuele machines geïmplementeerd op de Virtual Network. De virtuele machines voor het hosten van Active Directory en DNS zijn waarschijnlijk niet de grootste virtuele machines die u nodig hebt voor de oplossing. Voordat u deze virtuele machines implementeert, moet u eerst de grootste virtuele machine maken die u wilt gebruiken in uw Virtual Network. Dit zorgt ervoor dat uw oplossing op een tag in Azure terechtkomt die de grootste grootte biedt die u nodig hebt. U hoeft deze virtuele machine op dit moment niet te configureren. Maak het gewoon en zet het apart. Als u dit niet doet, kan er een beperking optreden wanneer u later grotere virtuele machines probeert te maken. Dit was een probleem op het moment dat dit artikel werd geschreven.

Fase 4: De SharePoint-herstelfarm implementeren in Azure

Implementeer de SharePoint-farm in uw Virtual Network volgens uw ontwerpplannen. Het kan handig zijn om Planning voor SharePoint 2013 op Azure Infrastructure Services te bekijken voordat u SharePoint-rollen in Azure implementeert.

Overweeg de volgende procedures die we hebben geleerd door onze proof-of-conceptomgeving te bouwen:

• Maak virtuele machines met behulp van de Azure Portal of PowerShell.

• Azure en Hyper-V bieden geen ondersteuning voor dynamisch geheugen. Zorg ervoor dat dit wordt meegenomen in uw prestatie- en capaciteitsplannen.

• Start virtuele machines opnieuw op via de Azure-interface, niet vanaf de aanmelding van de virtuele machine zelf. Het gebruik van de Azure-interface werkt beter en is voorspelbaarder.

• Als u een virtuele machine wilt afsluiten om kosten te besparen, gebruikt u de Azure-interface. Als u de aanmelding van de virtuele machine afsluit, blijven de kosten toenemen.

• Gebruik een naamconventie voor de virtuele machines.

• Let op welke datacenterlocatie de virtuele machines worden geïmplementeerd.

• De functie voor automatisch schalen in Azure wordt niet ondersteund voor SharePoint-rollen.

• Configureer geen items in de farm die worden hersteld, zoals siteverzamelingen.

Fase 5: DFSR tussen de farms instellen

Als u bestandsreplicatie wilt instellen met behulp van DFSR, gebruikt u de module DNS-beheer. Meld u echter vóór de installatie van DFSR aan bij uw on-premises bestandsserver en Azure-bestandsserver en schakel de service in Windows in.

Voer vanuit het Serverbeheer Dashboard de volgende stappen uit:

• Configureer de lokale server.

• Start de wizard Rollen en functies toevoegen.

• Open het knooppunt Bestands- en opslagservices .

• Selecteer DFS-naamruimten en DFS-replicatie.

• Klik op Volgende om de stappen van de wizard te voltooien.

De volgende tabel bevat koppelingen naar DFSR-referentieartikelen en blogberichten.

Tabel: Referentieartikelen voor DFSR

Titel	Omschrijving
Replicatie	Dfs Management TechNet-onderwerp met koppelingen voor replicatie
DFS-replicatie: overlevingshandleiding	Wiki met koppelingen naar DFS-informatie
DFS-replicatie: veelgestelde vragen	TechNet-onderwerp dfs-replicatie
Blog van Jose Barreto	Blog geschreven door een Principal Program Manager op het bestandsserverteam van Microsoft
The Storage Team at Microsoft - File Cabinet Blog	Blog over bestandsservices en opslagfuncties in Windows Server

Fase 6: Logboekverzending naar de herstelfarm instellen

Logboekverzending is het kritieke onderdeel voor het instellen van herstel na noodgevallen in deze omgeving. U kunt logboekverzending gebruiken om automatisch transactielogboekbestanden voor databases te verzenden van een primaire databaseserverexemplaren naar een secundaire databaseserverexemplaren. Zie Logboekverzending configureren in SharePoint 2013 om logboekverzending in te stellen.

Belangrijk

Ondersteuning voor logboekverzending in SharePoint Server is beperkt tot bepaalde databases. Zie Ondersteunde opties voor hoge beschikbaarheid en herstel na noodgevallen voor SharePoint-databases (SharePoint 2013) voor meer informatie.

Fase 7: Failover en herstel valideren

Het doel van deze laatste fase is om te controleren of de oplossing voor herstel na noodgevallen werkt zoals gepland. Hiervoor maakt u een failovergebeurtenis waarmee de productiefarm wordt afgesloten en de herstelfarm wordt gestart als vervanging. U kunt een failoverscenario handmatig of met behulp van scripts starten.

De eerste stap is het stoppen van binnenkomende gebruikersaanvragen voor farmservices of inhoud. U kunt dit doen door DNS-vermeldingen uit te schakelen of door de front-endwebservers af te sluiten. Nadat de farm 'offline' is, kunt u een failover uitvoeren naar de herstelfarm.

Verzending van logboeken stoppen

U moet de verzending van logboeken stoppen voordat de farm wordt hersteld. Stop eerst de verzending van logboeken op de secundaire server in Azure en stop deze vervolgens op de primaire server on-premises. Gebruik het volgende script om de verzending van logboeken op de secundaire server eerst en vervolgens op de primaire server te stoppen. De databasenamen in het script kunnen verschillen, afhankelijk van uw omgeving.

-- This script removes log shipping from the server.
-- Commands must be executed on the secondary server first and then on the primary server.

SET NOCOUNT ON
DECLARE  @PriDB nvarchar(max)
,@SecDB nvarchar(250)
,@PriSrv nvarchar(250)
,@SecSrv nvarchar(250)

Set @PriDB= ''
SET @PriDB = UPPER(@PriDB)
SET @PriDB = REPLACE(@PriDB, ' ', '')
SET @PriDB = '''' + REPLACE(@PriDB, ',', ''', ''') + ''''

Set @SecDB = @PriDB

Exec ( 'Select  ''exec master..sp_delete_log_shipping_secondary_database '' + '''''''' + prm.primary_database +  ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec  ON  prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')

Exec ( 'Select  ''exec master..sp_delete_log_shipping_primary_secondary '' + '''''''' + prm.Primary_Database + '''''', '''''' + sec.Secondary_Server + '''''', '''''' + sec.Secondary_database + ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec  ON  prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')

Exec ( 'Select  ''exec master..sp_delete_log_shipping_primary_database '' + '''''''' + prm.primary_database +  ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec  ON  prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')

Exec ( 'Select  ''exec master..sp_delete_log_shipping_secondary_primary '' + '''''''' + prm.primary_server + '''''', '''''' + prm.primary_database +  ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec  ON  prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')

De back-ups herstellen

Back-ups moeten worden hersteld in de volgorde waarin ze zijn gemaakt. Voordat u een back-up van een bepaald transactielogboek kunt herstellen, moet u eerst de volgende vorige back-ups herstellen zonder niet-verzonden transacties terug te draaien (met behulp van WITH NORECOVERY):

• De volledige back-up van de database en de laatste differentiële back-up: herstel deze back-ups, indien aanwezig, die vóór de back-up van het specifieke transactielogboek zijn gemaakt. Voordat de meest recente volledige of differentiële databaseback-up werd gemaakt, gebruikte de database het volledige herstelmodel of het herstelmodel dat bulksgewijs is geregistreerd.

• Alle back-ups van transactielogboeken: herstel alle back-ups van transactielogboeken die zijn gemaakt na de volledige databaseback-up of de differentiële back-up (als u er een herstelt) en vóór de back-up van het transactielogboek. Logboekback-ups moeten worden toegepast in de volgorde waarin ze zijn gemaakt, zonder hiaten in de logboekketen.

Als u de inhoudsdatabase op de secundaire server wilt herstellen, zodat de sites worden weergegeven, verwijdert u alle databaseverbindingen vóór het herstel. Voer de volgende SQL-instructie uit om de database te herstellen.

restore database WSS_Content with recovery

Belangrijk

Wanneer u T-SQL expliciet gebruikt, geeft u WITH NORECOVERY of WITH RECOVERY op in elke RESTORE-instructie om dubbelzinnigheid te elimineren. Dit is erg belangrijk bij het schrijven van scripts. Nadat de volledige en differentiële back-ups zijn hersteld, kunnen de transactielogboeken worden hersteld in SQL Server Management Studio. Omdat het verzenden van logboeken al is gestopt, bevindt de inhoudsdatabase zich ook in een stand-bystatus, dus moet u de status wijzigen in volledige toegang.

Klik in SQL Server Management Studio met de rechtermuisknop op de WSS_Content database, wijs Taken>herstellen aan en klik vervolgens op Transactielogboek (als u de volledige back-up niet hebt hersteld, is deze niet beschikbaar). ZieBack-up van een transactielogboek (SQL Server) herstellen voor meer informatie.

De inhoudsbron verkennen

U moet een volledige verkenning starten voor elke inhoudsbron om de zoekservice te herstellen. Houd er rekening mee dat u bepaalde analysegegevens van de on-premises farm kwijtraakt, zoals zoekaanbeveling. Voordat u de volledige verkenningen start, gebruikt u de Windows PowerShell cmdlet Restore-SPEnterpriseSearchServiceApplication en geeft u de in het logboek verzonden en gerepliceerde zoekbeheerdatabase op, Search_Service__DB_<GUID>. Deze cmdlet geeft de zoekconfiguratie, het schema, beheerde eigenschappen, regels en bronnen en maakt een standaardset van de andere onderdelen.

Voer de volgende stappen uit om een volledige verkenning te starten:

1. Ga in centraal beheer van SharePoint 2013 naar Toepassingsbeheerservicetoepassingen>Servicetoepassingen>beheren en klik vervolgens op de zoekservicetoepassing die u wilt verkennen.

2. Klik op de pagina Zoekbeheer op Inhoudsbronnen, wijs de gewenste inhoudsbron aan, klik op de pijl en klik vervolgens op Volledige verkenning starten.

Farmservices herstellen

In de volgende tabel ziet u hoe u services kunt herstellen die logboekdatabases hebben, de services die databases hebben, maar niet worden aanbevolen om te herstellen met logboekverzending en de services die geen databases hebben.

Belangrijk

Als u een on-premises SharePoint-database herstelt in de Azure-omgeving, worden geen SharePoint-services hersteld die u nog niet handmatig in Azure hebt geïnstalleerd.

Tabel: Naslaginformatie over servicetoepassingsdatabase

Deze services herstellen vanuit logboekdatabases	Deze services hebben databases, maar we raden u aan deze services te starten zonder hun databases te herstellen	Deze services slaan geen gegevens op in databases; deze services starten na failover
Service voor automatische vertaling Beheerde metagegevensservice Secure Store-service Gebruikersprofiel. (Alleen de databases Profiel en Sociaal taggen worden ondersteund. De synchronisatiedatabase wordt niet ondersteund.) Service voor abonnementsinstellingen van Microsoft SharePoint Foundation	Gebruiks- en statusgegevens verzamelen Statusservice Word automation	Excel Services PerformancePoint Services PowerPoint-conversie Visio Graphics Service Werkbeheer

In het volgende voorbeeld ziet u hoe u de service voor beheerde metagegevens herstelt vanuit een database.

Hierbij wordt de bestaande Managed_Metadata_DB-database gebruikt. Deze database wordt verzonden in het logboek, maar er is geen actieve servicetoepassing op de secundaire farm, dus deze moet worden verbonden nadat de servicetoepassing is geïnstalleerd.

Gebruik New-SPMetadataServiceApplicationeerst en geef de DatabaseName switch op met de naam van de herstelde database.

Configureer vervolgens de nieuwe Managed Metadata Service Application op de secundaire server als volgt:

• Naam: Beheerde metagegevensservice

• Databaseserver: de databasenaam uit het verzonden transactielogboek

• Databasenaam: Managed_Metadata_DB

• Groep van toepassingen: SharePoint-servicetoepassingen

DNS-records beheren

U moet handmatig DNS-records maken om te verwijzen naar uw SharePoint-farm.

In de meeste gevallen waarin u meerdere front-endwebservers hebt, is het zinvol om te profiteren van de functie Netwerktaakverdeling in Windows Server 2012 of een hardware load balancer om aanvragen te verdelen over de web-front-endservers in uw farm. Netwerktaakverdeling kan ook helpen het risico te verminderen door aanvragen te distribueren naar de andere servers als een van uw web-front-endservers uitvalt.

Wanneer u netwerktaakverdeling instelt, krijgt uw cluster doorgaans één IP-adres toegewezen. Vervolgens maakt u een DNS-hostrecord in de DNS-provider voor uw netwerk die naar het cluster verwijst. (Voor dit project hebben we een DNS-server in Azure geplaatst voor tolerantie in het geval van een storing in een on-premises datacenter.) U kunt bijvoorbeeld een DNS-record maken, bijvoorbeeld in DNS-beheer in Active Directory, met de naam https://sharepoint.contoso.com, dat verwijst naar het IP-adres voor uw cluster met gelijke taakverdeling.

Voor externe toegang tot uw SharePoint-farm kunt u een hostrecord maken op een externe DNS-server met dezelfde URL die clients op uw intranet gebruiken (bijvoorbeeld https://sharepoint.contoso.com) die verwijst naar een extern IP-adres in uw firewall. (Een best practice in dit voorbeeld is om gesplitste DNS in te stellen, zodat de interne DNS-server gezaghebbend is voor contoso.com en aanvragen rechtstreeks naar het SharePoint-farmcluster stuurt, in plaats van DNS-aanvragen door te routeren naar uw externe DNS-server.) Vervolgens kunt u het externe IP-adres toewijzen aan het interne IP-adres van uw on-premises cluster, zodat clients de resources vinden waarnaar ze op zoek zijn.

Vanaf hier kunt u te maken hebben met een aantal verschillende scenario's voor herstel na noodgevallen:

Voorbeeldscenario: De on-premises SharePoint-farm is niet beschikbaar vanwege hardwarefouten in de on-premises SharePoint-farm. In dit geval kunt u, nadat u de stappen voor failover naar de Azure SharePoint-farm hebt voltooid, netwerktaakverdeling configureren op de web-front-endservers van de SharePoint-farm herstellen, op dezelfde manier als met de on-premises farm. Vervolgens kunt u de hostrecord in uw interne DNS-provider omleiden om te verwijzen naar het IP-adres van het cluster van de herstelfarm. Houd er rekening mee dat het enige tijd kan duren voordat dns-records in de cache op clients worden vernieuwd en naar de herstelfarm verwijzen.

Voorbeeldscenario: Het on-premises datacenter gaat volledig verloren. Dit scenario kan optreden als gevolg van een natuurramp, zoals een brand of overstroming. In dit geval hebt u voor een onderneming waarschijnlijk een secundair datacenter dat wordt gehost in een andere regio, evenals uw Azure-subnet met eigen adreslijstservices en DNS. Net als in het vorige noodscenario kunt u uw interne en externe DNS-records omleiden om te verwijzen naar de Azure SharePoint-farm. Nogmaals, houd er rekening mee dat het doorgeven van DNS-records enige tijd kan duren.

Als u siteverzamelingen met hostnamen gebruikt, zoals wordt aanbevolen in de architectuur en implementatie van siteverzamelingen met hostnamen (SharePoint 2013), hebt u mogelijk verschillende siteverzamelingen die worden gehost door dezelfde webtoepassing in uw SharePoint-farm, met unieke DNS-namen (bijvoorbeeld https://sales.contoso.com en https://marketing.contoso.com). In dit geval kunt u DNS-records maken voor elke siteverzameling die verwijzen naar het IP-adres van uw cluster. Nadat een aanvraag uw SharePoint-web-front-endservers heeft bereikt, verwerken ze het routeren van elke aanvraag naar de juiste siteverzameling.

Microsoft proof-of-concept-omgeving

Voor deze oplossing hebben we een proof-of-conceptomgeving ontworpen en getest. Het ontwerpdoel voor onze testomgeving was het implementeren en herstellen van een SharePoint-farm die we mogelijk in een klantomgeving vinden. We hebben verschillende veronderstellingen gemaakt, maar we wisten dat de farm alle kant-en-klare functionaliteit moest bieden zonder aanpassingen. De topologie is ontworpen voor hoge beschikbaarheid met behulp van best practice-richtlijnen van het veld en de productgroep.

In de volgende tabel worden de virtuele Hyper-V-machines beschreven die we hebben gemaakt en geconfigureerd voor de on-premises testomgeving.

Tabel: Virtuele machines voor on-premises tests

Servernaam	Rol	Configuratie
DC1	Domeincontroller met Active Directory.	Twee processors Van 512 MB tot 4 GB RAM 1 x 127 GB harde schijf
RRAS	Server geconfigureerd met de RRAS-rol (Routing and Remote Access Service).	Twee processors 2-8 GB RAM-geheugen 1 x 127 GB harde schijf
FS1	Bestandsserver met shares voor back-ups en een eindpunt voor DFSR.	Vier processors 2-12 GB RAM-geheugen 1 x 127 GB harde schijf 1 x 1 TB harde schijf (SAN) 1 x 750 GB harde schijf
SP-WFE1, SP-WFE2	Front-end webservers.	Vier processors 16 GB RAM-geheugen
SP-APP1, SP-APP2, SP-APP3	Toepassingsservers.	Vier processors 2-16 GB RAM-geheugen
SP-SQL-HA1, SP-SQL-HA2	Databaseservers, geconfigureerd met SQL Server 2012 AlwaysOn-beschikbaarheidsgroepen om hoge beschikbaarheid te bieden. Deze configuratie maakt gebruik van SP-SQL-HA1 en SP-SQL-HA2 als de primaire en secundaire replica's.	Vier processors 2-16 GB RAM-geheugen

In de volgende tabel worden stationsconfiguraties beschreven voor de virtuele Hyper-V-machines die we hebben gemaakt en geconfigureerd voor de front-endweb- en toepassingsservers voor de on-premises testomgeving.

Tabel: Vereisten voor virtuele-machinestations voor de front-endweb- en toepassingsservers voor de on-premises test

Stationsletter	Grootte	Mapnaam	Pad
C	80	Systeemstation	<DriveLetter>:\Program Files\Microsoft SQL Server\
E	80	Logboekstation (40 GB)	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
F	80	Pagina (36 GB)	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL\DATA

In de volgende tabel worden stationsconfiguraties beschreven voor de virtuele Hyper-V-machines die zijn gemaakt en geconfigureerd om te fungeren als de on-premises databaseservers. Ga op de pagina Configuratie van database-engine naar het tabblad Gegevensmappen om de instellingen in de volgende tabel in te stellen en te bevestigen.

Tabel: Vereisten voor virtuele-machinestations voor de databaseserver voor de on-premises test

Stationsletter	Grootte	Mapnaam	Pad
C	80	Hoofdmap van gegevens	<DriveLetter>:\Program Files\Microsoft SQL Server\
E	500	Gebruikersdatabasemap	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
F	500	Logboekmap van gebruikersdatabase	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
G	500	Tijdelijke db-map	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
H	500	Temp DB-logboekmap	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA

De testomgeving instellen

Tijdens de verschillende implementatiefasen werkte het testteam doorgaans eerst aan de on-premises architectuur en vervolgens aan de bijbehorende Azure-omgeving. Dit weerspiegelt de algemene praktijkvoorbeelden waarin in-house productiebedrijven al actief zijn. Wat nog belangrijker is, is dat u de huidige productieworkload, capaciteit en typische prestaties kent. Naast het bouwen van een model voor herstel na noodgevallen dat kan voldoen aan de bedrijfsvereisten, moet u de grootte van de herstelfarmservers aanpassen om een minimaal serviceniveau te leveren. In een koude of warme stand-byomgeving is een herstelfarm doorgaans kleiner dan een productiefarm. Nadat de herstelfarm stabiel en in productie is, kan de farm worden opgeschaald en uitgeschaald om te voldoen aan de workloadvereisten.

We hebben onze testomgeving in de volgende drie fasen geïmplementeerd:

• De hybride infrastructuur instellen

• De servers inrichten

• De SharePoint-farms implementeren

De hybride infrastructuur instellen

In deze fase werd een domeinomgeving ingesteld voor de on-premises farm en voor de herstelfarm in Azure. Naast de normale taken die zijn gekoppeld aan het configureren van Active Directory, heeft het testteam een routeringsoplossing en een VPN-verbinding tussen de twee omgevingen geïmplementeerd.

De servers inrichten

Naast de farmservers was het nodig om servers in te richten voor de domeincontrollers en een server te configureren voor het verwerken van RRAS en het site-naar-site-VPN. Er zijn twee bestandsservers ingericht voor de DFSR-service en verschillende clientcomputers zijn ingericht voor testers.

De SharePoint-farms implementeren

De SharePoint-farms zijn in twee fasen geïmplementeerd om de stabilisatie en probleemoplossing van de omgeving te vereenvoudigen, indien nodig. Tijdens de eerste fase werd elke farm geïmplementeerd op het minimale aantal servers voor elke laag van de topologie om de vereiste functionaliteit te ondersteunen.

We hebben de databaseservers gemaakt met SQL Server geïnstalleerd voordat we de SharePoint 2013-servers maakten. Omdat dit een nieuwe implementatie was, hebben we de beschikbaarheidsgroepen gemaakt voordat SharePoint werd geïmplementeerd. We hebben drie groepen gemaakt op basis van mcs best practice-richtlijnen.

Opmerking

Tijdelijke databases maken, zodat u beschikbaarheidsgroepen kunt maken vóór de installatie van SharePoint. Zie SQL Server 2012 AlwaysOn-beschikbaarheidsgroepen configureren voor SharePoint 2013 voor meer informatie

We hebben de farm gemaakt en extra servers toegevoegd in de volgende volgorde:

• Richt SP-SQL-HA1 en SP-SQL-HA2 in.

• Configureer AlwaysOn en maak de drie beschikbaarheidsgroepen voor de farm.

• SP-APP1 inrichten voor het hosten van centraal beheer.

• Richt SP-WFE1 en SP-WFE2 in om de gedistribueerde cache te hosten.

We hebben de parameter skipRegisterAsDistributedCachehost gebruikt toen we psconfig.exe op de opdrachtregel uitvoerden. Zie Feeds plannen en de service gedistribueerde cache in SharePoint Server 2013 voor meer informatie.

We hebben de volgende stappen herhaald in de herstelomgeving:

• Richt AZ-SQL-HA1 en AZ-SQL-HA2 in.

• Configureer AlwaysOn en maak de drie beschikbaarheidsgroepen voor de farm.

• Richt AZ-APP1 in om centraal beheer te hosten.

• Richt AZ-WFE1 en AZ-WFE2 in om de gedistribueerde cache te hosten.

Nadat we de gedistribueerde cache hebben geconfigureerd en testgebruikers en testinhoud hebben toegevoegd, zijn we fase twee van de implementatie gestart. Hiervoor moesten de lagen worden uitgeschaald en moesten de farmservers worden geconfigureerd ter ondersteuning van de topologie met hoge beschikbaarheid die wordt beschreven in de farmarchitectuur.

In de volgende tabel worden de virtuele machines, subnetten en beschikbaarheidssets beschreven die we hebben ingesteld voor onze herstelfarm.

Tabel: Infrastructuur van herstelfarm

Servernaam	Rol	Configuratie	Subnet	Beschikbaarheidsset
spDRAD	Domeincontroller met Active Directory	Twee processors Van 512 MB tot 4 GB RAM 1 x 127 GB harde schijf	sp-ADservers
AZ-SP-FS	Bestandsserver met shares voor back-ups en een eindpunt voor DFSR	A5-configuratie: Twee processors 14 GB RAM-geheugen 1 x 127 GB harde schijf 1 x 135 GB harde schijf 1 x 127 GB harde schijf 1 x 150 GB harde schijf	sp-databaseservers	DATA_SET
AZ-WFE1, AZ -WFE2	Front-end webservers	A5-configuratie: Twee processors 14 GB RAM-geheugen 1 x 127 GB harde schijf	sp-webservers	WFE_SET
AZ -APP1, AZ -APP2, AZ -APP3	Toepassingsservers	A5-configuratie: Twee processors 14 GB RAM-geheugen 1 x 127 GB harde schijf	sp-applicationservers	APP_SET
AZ -SQL-HA1, AZ -SQL-HA2	Databaseservers en primaire en secundaire replica's voor AlwaysOn-beschikbaarheidsgroepen	A5-configuratie: Twee processors 14 GB RAM-geheugen	sp-databaseservers	DATA_SET

Bewerkingen

Nadat het testteam de farmomgevingen had gestabiliseerd en de functionele tests had voltooid, zijn de volgende bewerkingen gestart die nodig zijn om de on-premises herstelomgeving te configureren:

• Configureer volledige en differentiële back-ups.

• Configureer DFSR op de bestandsservers die transactielogboeken overdragen tussen de on-premises omgeving en de Azure-omgeving.

• Logboekverzending configureren op de primaire databaseserver.

• Stabiliseer, valideer en los problemen op met logboekverzending, indien nodig. Dit omvat het identificeren en documenteren van gedrag dat problemen kan veroorzaken, zoals netwerklatentie, die zou leiden tot logboekverzending of fouten bij het synchroniseren van DFSR-bestanden.

Databases

Bij onze failovertests zijn de volgende databases betrokken:

• WSS_Content

• ManagedMetadata

• Profieldatabase

• Database synchroniseren

• Sociale database

• Hub voor inhoudstype (een database voor een toegewezen hub voor inhoudstypesyndicatie)

Tips voor probleemoplossing

In de sectie worden de problemen beschreven die we hebben ondervonden tijdens het testen en de bijbehorende oplossingen.

Het gebruik van het hulpprogramma voor termenarchiefbeheer heeft de fout 'Het beheerde metagegevensarchief of de verbinding is momenteel niet beschikbaar' veroorzaakt.

Zorg ervoor dat het account van de groep van toepassingen dat door de webtoepassing wordt gebruikt, de machtiging Leestoegang tot termenarchief heeft.

Aangepaste termensets zijn niet beschikbaar in de siteverzameling

Controleer op een ontbrekende servicetoepassingskoppeling tussen uw inhoudssiteverzameling en uw hub voor inhoudstypen. Controleer bovendien onder het scherm Beheerde metagegevens - <naam> van siteverzameling Verbindingseigenschappen of deze optie is ingeschakeld: Deze servicetoepassing is de standaardopslaglocatie voor kolomspecifieke termensets.

De opdracht Get-ADForest Windows PowerShell genereert de fout 'De term 'Get-ADForest' wordt niet herkend als de naam van een cmdlet, functie, scriptbestand of bewerkbaar programma.'

Bij het instellen van gebruikersprofielen hebt u de naam van het Active Directory-forest nodig. Controleer in de wizard Functies en onderdelen toevoegen of u de Active Directory-module voor Windows PowerShell hebt ingeschakeld (in de sectie Hulpprogramma's>voor het beheer van externe servers AD DS- en AD LDS-hulpprogramma's>). Voer bovendien de volgende opdrachten uit voordat u Get-ADForest gebruikt om ervoor te zorgen dat uw softwareafhankelijkheden worden geladen.

Import-Module ServerManager
Import-Module ActiveDirectory

Het maken van de beschikbaarheidsgroep mislukt bij het starten van de XEvent-sessie 'AlwaysOn_health' op '<servernaam>'

Zorg ervoor dat beide knooppunten van uw failovercluster de status 'Up' hebben en niet 'Onderbroken' of 'Gestopt'.

SQL Server taak voor het verzenden van logboeken mislukt met de fout toegang geweigerd bij het maken van verbinding met de bestandsshare

Zorg ervoor dat uw SQL Server Agent wordt uitgevoerd onder netwerkreferenties, in plaats van de standaardreferenties.

SQL Server taak voor logboekverzending geeft aan dat het is gelukt, maar er worden geen bestanden gekopieerd

Dit gebeurt omdat de standaardvoorkeur voor back-ups voor een beschikbaarheidsgroep Voorkeur secundair is. Zorg ervoor dat u de taak voor logboekverzending uitvoert vanaf de secundaire server voor de beschikbaarheidsgroep in plaats van de primaire; Anders mislukt de taak op de achtergrond.

Beheerde metagegevensservice (of een andere SharePoint-service) kan niet automatisch worden gestart na de installatie

Het starten van services kan enkele minuten duren, afhankelijk van de prestaties en de huidige belasting van uw SharePoint Server. Klik handmatig op Start voor de service en geef voldoende tijd voor het opstarten terwijl u af en toe het scherm Services op server vernieuwt om de status ervan te controleren. Als de service gestopt blijft, schakelt u diagnostische logboekregistratie van SharePoint in, probeert u de service opnieuw te starten en controleert u het logboek op fouten. Zie Diagnostische logboekregistratie configureren in SharePoint 2013 voor meer informatie

Nadat u DNS hebt gewijzigd in de Azure-failoveromgeving, blijven clientbrowsers het oude IP-adres voor de SharePoint-site gebruiken

Uw DNS-wijziging is mogelijk niet onmiddellijk zichtbaar voor alle clients. Voer op een testclient de volgende opdracht uit vanaf een opdrachtprompt met verhoogde bevoegdheid en probeer opnieuw toegang te krijgen tot de site.

Ipconfig /flushdns

Aanvullende bronnen

Ondersteunde opties voor hoge beschikbaarheid en herstel na noodgevallen voor SharePoint-databases

AlwaysOn-beschikbaarheidsgroepen voor SQL Server 2012 configureren voor SharePoint 2013

Zie ook

Microsoft 365-oplossings- en -architectuurcentrum