Meilleures pratiques en matière de récupération d'urgence pour SharePoint Server et Access Services

S’APPLIQUE À :  yes-img-13 2013  yes-img-16 2016  yes-img-19 2019  yes-img-se Subscription Edition  no-img-sop SharePoint in Microsoft 365

Cet article explique comment implémenter avec succès une stratégie de récupération d’urgence pour Access Services applications de service pour SharePoint Server.

Nous remercions Neil Hodgkinson, gestionnaire senior des programmes Microsoft, qui a testé cette stratégie de récupération d’urgence et fourni le contenu de cet article.

Vue d’ensemble d’Access Services et de la récupération d’urgence

SharePoint 2010 a introduit le concept d'Access Services en tant qu'application de service intégrée dans Introduction à Access Services . Les données étaient contenues dans des listes SharePoint et étaient accessibles via un navigateur ou le client Microsoft Access 2010. Dans SharePoint 2013, l'architecture d'Access Services a été modifiée et le concept de bases de données à relation contenant-contenu a été introduit, déplaçant ainsi les données des listes SharePoint vers une base de données d'application SQL Server 2012. Cette architecture reste en place pour la version SharePoint Server 2016.

Il existe plusieurs façons de configurer votre batterie de serveurs SharePoint Server pour la récupération d'urgence. La méthode choisie dépend entièrement des exigences en matière de perte de données autorisée et de temps d'arrêt minimal dans votre organisation. Microsoft a documenté différentes approches dans Choisir une stratégie de récupération d'urgence pour SharePoint Server.

Il existe quelques exigences et bonnes pratiques pour la configuration d'une batterie de récupération d'urgence pour prendre en charge Access Services, quel que soit votre choix de technologies. Celles-ci sont détaillées ci-dessous.

Important

Avant d'utiliser les cmdlets Microsoft PowerShell présentées par la suite, vérifiez que vous remplissez toutes les conditions requises dans la rubrique Autorisations.

Étape 1 : Configuration de la récupération d'urgence dans SharePoint Server

L'objectif de cette étape consiste à créer une expérience de récupération d'urgence plus fluide en supprimant les points de défaillance potentiels. En mettant en correspondance les domaines d'authentification et les ID de référence de serveur de base de données afin qu'ils soient identiques dans la batterie de récupération d'urgence et dans la batterie principale, vous serez prêt pour la récupération. De même, il est essentiel de savoir quelles bases de données doivent être gérées pour effectuer correctement la récupération.

Nous entrerons dans les détails par la suite.

a. Utiliser le même domaine d'authentification

Définir un nouveau domaine d'authentification bloque l'accès à toutes les applications SharePoint qui utilisent des jetons d'accès. Les applications Access Services reposent sur l'infrastructure d'application. Dans ce sens, il est logique qu'une batterie de récupération d'urgence utilise le même domaine d'authentification que la batterie principale. La définition du domaine d'authentification doit être l'une des premières étapes de configuration lors du déploiement de la batterie de récupération d'urgence.

Pour obtenir le domaine d'authentification de la batterie principale, utilisez la commande PowerShell suivante :

 Get-SPAuthenticationRealm

Exemple : un domaine d'authentification est, par exemple, un GUID. La valeur renvoyée est donc semblable à ce qui suit : 4a2cc8f8-51ab-4367-8a76-ab629c882a68.

En prenant ce GUID pour exemple, définissez-le dans la batterie secondaire à l'aide des commandes PowerShell suivantes :

Set-SPAuthenticationRealm -Realm 4a2cc8f8-51ab-4367-8a76-ab629c882a68
Restart-Service sptimerv4
Restart-Service spadminv4

Important

Nous vous recommandons de redémarrer le service de minuteur SharePoint et le service d'administration SharePoint après avoir modifié le domaine d'authentification. Vous serez peut-être amené à planifier la durée pendant laquelle vous pouvez exécuter une commande IISReset (les sites SharePoint seront indisponibles jusqu'à la fin d'une opération IISReset).

b. Utiliser le même ID de référence de serveur de base de données

Access Services dans SharePoint Server 2013 et SharePoint Server 2016 utilisent un SQL Server pour héberger les bases de données qui prennent en charge les applications basées sur Access. En interne, ces serveurs de base de données ne sont pas référencés par leur nom, mais par un ReferenceID.

Important

Pour que votre stratégie de récupération d'urgence soit réussie, il faut que les serveurs de base de données dans le centre de données secondaire soient enregistrés en tant qu'hôtes de serveur d'application en utilisant exactement le même ReferenceID que leur partenaire principal. > Cette opération peut être effectuée uniquement en enregistrant les serveurs de base de données à l'aide de PowerShell.

Enregistrer le serveur de base de données Access Services de la batterie principale

$serverGroupName = 'DEFAULT'
$ASapp = Get-SPAccessServicesApplication
$app = $Null
if ($ASapp.length -ne $Null) { $app = $ASapp[0] } else { $app = $ASapp }
$context = [Microsoft.SharePoint.SPServiceContext]::GetContext($app.ServiceApplicationProxyGroup, [Microsoft.SharePoint.SPSiteSubscriptionIdentifier]::Default)
$ServerRefID = [System.Guid]::NewGuid().toString()
$newdbserver = New-SPAccessServicesDatabaseServer -ServiceContext $context -DatabaseServerName "<PrimaryDatabaseServerName>" -DatabaseServerGroup $serverGroupName -ServerReferenceId $ServerRefID -AvailableForCreate $true

Tapez l'ID de référence de serveur à l'écran pour l'utiliser lors de l'enregistrement du serveur de base de données Access Services de la batterie secondaire.

 $ServerRefID

Enregistrer le serveur de base de données Access Services de la batterie secondaire

$serverGroupName = 'DEFAULT'
$DatabaseServerName = "<Secondary Access Database Server>"
$PrimaryServerRefID = "<Primary Server Reference ID>"
$ASapp = Get-SPAccessServicesApplication
$app = $Null
if ($ASapp.length -ne $Null) { $app = $ASapp[0] } else { $app = $ASapp }
$context = [Microsoft.SharePoint.SPServiceContext]::GetContext($app.ServiceApplicationProxyGroup, [Microsoft.SharePoint.SPSiteSubscriptionIdentifier]::Default)
$newdbserver = New-SPAccessServicesDatabaseServer -ServiceContext $context -DatabaseServerName $DatabaseServerName  -DatabaseServerGroup $serverGroupName -ServerReferenceId $PrimaryServerRefID -AvailableForCreate $true

Vous pouvez référencer autant de serveurs de base de données d'application Access Services que nécessaire. Ce scénario simple n'en inclut qu'un. Si vous en avez plusieurs, assurez le suivi des enregistrements et vérifiez que, dans ce mode, les bases de données sont récupérées correctement sur le serveur correspondant dans le site de récupération d'urgence.

c. Connaître les bases de données qui prennent en charge l'application de service Access Services

Au lieu d’avoir leurs propres bases de données d’application de service, Access Services dans SharePoint Server ont des dépendances étroites sur plusieurs bases de données dans une batterie SharePoint de serveurs.

Ces bases de données doivent être gérées dans le cadre de votre stratégie de récupération d'urgence.

Base de données Description
Base de données de gestion des applications
Contient les inscriptions d'application Access et les principaux d'application.
Base de données de paramètres d'abonnement
Gère les identités uniques fournies aux applications Access pour créer l'URL de l'application Access.
Base de données Banque d'informations sécurisée
Le Service Banque d'informations sécurisé peut fournir d'autres méthodes d'authentification pour les applications Access. Le guide mentionné précédemment ne couvre pas ce sujet, mais nous ajouterons la base de données Banque d'informations sécurisée à notre stratégie pour la compléter.
Base de données de contenu SharePoint
Ces bases de données contiennent les collections de sites dans lesquelles des applications Access ont été déployées.
Bases de données d'application Access Services
Bases de données contenant les données réelles à conserver pour que l'application Access Services fonctionne correctement.

L'approche de récupération d'urgence choisie dépend de votre objectif de temps de récupération (RTO) et de votre objectif de point de récupération (RPO), de la durée où vous pouvez être en mode hors connexion et de la quantité de données que vous pouvez vous permettre de perdre en cas d'incident. Quel que soit votre choix, le processus de récupération pour Access Services reste le même.

Étape 2 : Récupération après basculement

Après avoir basculé vers le centre de données secondaire, vous devez utiliser les cinq bases de données différentes répertoriées dans l'étape 1 pour régénérer l'infrastructure de l'application Access Services dans la batterie de récupération d'urgence.

Notes

[!REMARQUE] Cet article concerne uniquement les types de base de cinq données répertoriées dans le tableau ci-dessus. Pour récupérer correctement une batterie de serveurs SharePoint Server complète après le basculement d'un centre de données, des étapes supplémentaires sont nécessaires et le lecteur est redirigé pour consulter les étapes de la rubrique Planifier la haute disponibilité et la récupération d'urgence pour SharePoint Server.

Pour l'environnement de test abordé dans cet article, cela signifie que les bases de données suivantes sont récupérées à partir du serveur SQL Server principal SQL01 vers le serveur SQL Server secondaire SQL02 dans le site de récupération d'urgence.

  • Base de données de gestion des applications

  • Base de données de paramètres d'abonnement

  • Base de données de banque d'informations sécurisée

  • Base de données de contenu SharePoint

  • Bases de données d'application Access Services

Nous pouvons utiliser les techniques décrites ici pour récupérer ces applications de service et attacher la base de données de contenu.

a. Recréer les applications de service à partir des bases de données restaurées/récupérées

Utilisez les commandes PowerShell suivantes :

  1. Proxy et base de données de gestion des applications :
$AppPool = Get-SPServiceApplicationPool -Identity "<Services Application Pool Name> "
$AppDatabasename = "<restored App Management database name>"
$appman = New-SPAppManagementServiceApplication -Name "App Management" -DatabaseServer "<SecondaryDatabaseServerName>" -DatabaseName $AppDatabaseName -ApplicationPool $AppPool 
$appmanproxy = New-SPAppManagementServiceApplicationProxy -Name "App Management Proxy" -ServiceApplication $appman
  1. Proxy et base de données de paramètres d'abonnement :
 $SubDatabasename = "<restored Subscription Settings database name>"
$subset = New-SPSubscriptionSettingsServiceApplication -Name "Subscription Settings" -DatabaseServer "<SecondaryDatabaseServerName>" -DatabaseName $SubDatabaseName -ApplicationPool $AppPool
$subsetproxy = New-SPSubscriptionSettingsServiceApplicationProxy -Name "Sub Settings Proxy" -ServiceApplication $subset
  1. Proxy et base de données de banque d'informations sécurisée :
$SecDatabasename = "<restored Secure Store database name>"
$secstore = New-SPSecureStoreServiceApplication -DatabaseServer "<SecondaryDatabaseServerName>" -DatabaseName $SecDatabaseName -ApplicationPool $AppPool
$secstoreproxy = New-SPSecureStoreServiceApplicationProxy -Name "Secure Store Proxy" -ServiceApplication $secstore

Notez également que si vous utilisez la banque d'informations sécurisée dans la batterie secondaire, vous devrez générer une nouvelle clé de chiffrement de la banque d'informations sécurisée avant d'exploiter les applications qui y sont inscrites.

b. Attacher les bases de données de contenu

Montez les bases de données de contenu de basculement sur l'application web appropriée dans la batterie de récupération d'urgence à l'aide de PowerShell comme suit :

Pour pouvoir utiliser les cmdlets Microsoft PowerShell, vérifiez que vous remplissez toutes les conditions requises dans la rubrique Autorisations.

 Mount-SPContentDatabase -WebApplication "<http://DRWebApp>"  -Name "<Database name>" -DatabaseServer "<SecondaryDatabaseServerName>"

c. Récupérer les bases de données d'application Access Services

Tout comme pour les autres bases de données, la technique de votre choix dépend de vos RTO et RPO. Toutefois, pour effectuer la récupération, il vous suffit de restaurer, ou de récupérer, les bases de données sur le serveur secondaire qui a été correctement inscrit dans Access Services à l'aide du ServerReferenceID du serveur de base de données principal. Cette information est détaillée dans La configuration de l’OneDrive.

Étape 3 : Configuration des actions consécutives au basculement

À ce stade, nous disposons presque de tous les éléments nécessaires à la prise en charge d'Access Services dans les conditions de récupération d'urgence. Les deux dernières tâches à effectuer sont les suivantes :

  • Configurer les URL de domaine d'application.

  • Vérifier que les connexions de base de données d'application Access Services ont été transmises du site principal au site secondaire.

a. Configurer les domaines d'applications dans le site secondaire

Les principaux éléments à prendre en compte sont les domaines que vous avez spécifiés dans le site principal et ceux que vous avez l'intention d'utiliser dans le site de récupération d'urgence secondaire. Si vous prévoyez d'utiliser les mêmes domaines, repointez l'enregistrement CNAME pour le domaine des applications SP vers le serveur SharePoint secondaire. Par exemple, repointez *.contosoapps.com vers le serveur SharePoint secondaire.

Vérifiez que vous configurez les URL d'application dans l'Administration centrale sur le site de récupération d'urgence.

  1. Ouvrez l'Administration centrale, sélectionnez Applications.

  2. Sélectionnez Configurer les URL d'application.

La récupération de la base de données de gestion des applications ne conserve pas le domaine d'application, même si elle permet de conserver le préfixe de l'application.

Important

L'impossibilité de configurer le domaine d'application entraîne l'échec des recherches DNS et une erreur indiquant que le site est introuvable dans le navigateur.

b. Configurer les connexions de base de données Access pour le site secondaire

Access Services nécessite la fonctionnalité de bases de données à relation contenant-contenu de SQL Server, prenant en charge les connexions de base de données à relation contenant-contenu. Toutefois, Access Services dans SharePoint 2013 et 2016 n'exploite que partiellement cette fonctionnalité. Par conséquent, les connexions de base de données sont stockées dans la base de données maître, comme toute autre connexion. L'inconvénient est que lors du basculement, nous devons régénérer les connexions manquantes et vérifier que nous avons configuré le même mot de passe pour le compte.

Heureusement, Microsoft a créé une manière d'y procéder facilement présentée dans cette rubrique (et nous utilisons cet article à l'étape 1, ci-dessous) Comment faire pour transférer des noms d'accès et des mots de passe entre instances de SQL Server.

Le processus comporte trois étapes clés :

  1. Utilisez le script indiqué dans la rubrique Comment faire pour transférer des noms d'accès et des mots de passe entre instances de SQL Server pour générer deux nouvelles procédures stockées dans la base de données maître du serveur de base de données Access Services principal.

  2. Exécutez la procédure stockée pour générer un script TSQL qui peut être copié sur le serveur secondaire cible, par exemple :

Login: db_ _dbo
CREATE LOGIN [db_63eb8501_29b0_401a_becd_9931ae72ea3d _dbo] WITH PASSWORD = *********** HASHED, SID = 0x0C3431F92F162D4EA913E07E1DAB3979 , DEFAULT_DATABASE = [master], CHECK_POLICY = OFF, CHECK_EXPIRATION = OFF — Login: db_63eb8501_29b0_401a_becd_9931ae72ea3d_custom
CREATE LOGIN [db_63eb8501_29b0_401a_becd_9931ae72ea3d_custom] WITH PASSWORD = ***********  HASHED, SID = 0x8B68A3A203D6D14E88F13B504420BD7E, DEFAULT_DATABASE = [master], CHECK_POLICY = OFF, CHECK_EXPIRATION = OFF
  1. Exécutez le TSQL sur le serveur de base de données secondaire cible pour générer les connexions.

Après avoir effectué ces actions, la batterie de récupération d'urgence secondaire peut afficher les applications Access Services à partir de la batterie principale après le basculement.

Résumé

SharePoint Server 2013 a été testé dans un scénario de récupération d'urgence en utilisant SQL Server 2012 et en tant que plateformes de serveur de base de données d'application Access.

SharePoint Server 2016 2016 a été testé dans un scénario de récupération d'urgence en utilisant SQL Server en tant que plateformes de serveur de base de données d'application Access.

Dans tous les scénarios, nous avons pu récupérer les applications Access sur la batterie de serveurs SharePoint secondaire et effectuer toutes les opérations CRUD après le basculement, tout en ayant appliqué les instructions de ce document.

Les éléments clés sont les suivants : vérifier que les deux batteries de serveurs sont configurées avec des domaines d'authentification correspondants ; vérifier que les serveurs de base de données Access Services sont référencés par le même ServerReferenceID; transférer les connexions SQL du serveur de production aux serveurs SQL de récupération d'urgence.

Voir aussi