Utiliser une mise à niveau d'évaluation vers SharePoint 2013 pour rechercher les problèmes éventuels

S’APPLIQUE À :2013 2016 2019 Édition d’abonnement SharePoint dans Microsoft 365

Avant de commencer une mise à niveau entre les Produits SharePoint 2010 et SharePoint 2013, vous devez la tester pour vous assurer que vous savez exactement ce qu'il faut à une mise à niveau réussie. Une mise à niveau d'essai vous permet de déterminer les points suivants :

• le caractère opérationnel d’un plan de mise à niveau ou la nécessité d’effectuer des ajustements ;

• les personnalisations présentes dans votre environnement afin de pouvoir planifier leur prise en compte au cours de la mise à niveau ;

• l’opportunité de mettre à niveau votre matériel afin de faciliter et d’accélérer une mise à niveau ;

• le moment le plus opportun pour la mise à niveau, ou la durée que prendra la mise à niveau compte tenu de votre environnement ;

• les éléments que vous devez planifier, par exemple les ressources requises.

Par ailleurs, vous pouvez utiliser cette mise à niveau d'essai pour vous familiariser avec les outils de mise à niveau et le processus lui-même, afin que vous sachiez à quoi vous attendre quand vous effectuez la véritable mise à niveau. Ce test vous permet de déterminer :

• À quoi ressemble l’interface utilisateur de mise à niveau ? Comment savoir quand vous avez terminé une phase et que vous passez par une autre ?

• Où se trouvent les fichiers journaux et comment les lire ? Quelles informations fournissent-ils ?

• si vous devez ajuster des scripts ou des commandes utilisés pendant le processus de mise à niveau, notamment si vous vous appuyez sur des scripts qui ont été utilisés lors de la mise à niveau vers les Produits SharePoint 2010 ;

• si vous possédez le plan adéquat pour faire face aux arrêts.

Cet article décrit les étapes de base du test de la mise à niveau, ainsi que des recommandations pour interpréter les résultats et ajuster un plan de mise à niveau en fonction de ces résultats.

En outre, les ressources suivantes peuvent être utiles quand vous testez le processus de mise à niveau :

• SharePoint 2013 : testez votre modèle de processus de mise à niveau

  Téléchargez l'affiche relative au modèle de test du processus de mise à niveau pour les produits SharePoint 2013 pour obtenir une présentation visuelle des informations relatives au test du processus de mise à niveau.

• Consultez les meilleures pratiques relatives au test du processus de mise à niveau dans Meilleures pratiques pour la mise à niveau de SharePoint 2010 vers SharePoint 2013.

Configurer un environnement de test

Vous pouvez tester le processus de mise à niveau sur un matériel virtuel ou physique. Chaque environnement est particulier. Ainsi, il est difficile de se prononcer sur la durée de la mise à niveau ou la difficulté que posera une personnalisation particulière. La meilleure manière d'évaluer le processus de mise à niveau consiste à effectuer une série d'essais.

Voici certains points à prendre en considération quand vous créez votre environnement de test :

• Créez une batterie de test aussi proche que possible de votre batterie réelle, en termes de matériel, de logiciel et d'espace disponible.

• Utilisez dans votre batterie de test les URL de votre batterie réelle. Sinon, vous allez perdre du temps à diagnostiquer des problèmes d'URL qui ne se poseront pas au cours de la véritable mise à niveau. Vous pouvez effectuer cette opération en utilisant les mêmes URL et en n'effectuant les tests qu'à partir des ordinateurs dont le fichier hôte a été modifié.

• Utilisez les différents noms d’ordinateur pour vos serveurs web et d’applications.

  Cela empêche les conflits liés aux services de domaine Active Directory (AD DS).

• Utilisez des serveurs distincts qui exécutent SQL Server pour votre batterie de serveurs de test.

  Si vous utilisez les mêmes serveurs qui exécutent SQL Server pour votre batterie de serveurs de test et pour votre batterie de serveurs de production, vous risquez d'affecter les performances de votre batterie de serveurs de production quand vous exécutez les tests. Nous vous recommandons d'utiliser différents ordinateurs SQL Server (pas simplement des instances) pour vos batteries de serveurs de production et de test.

• Utilisez les mêmes noms de base de données dans votre environnement de test.

  Cela vous permet de valider les scripts que vous utilisez pour gérer votre environnement. Là encore, veillez à utiliser des serveurs distincts qui exécutent SQL Server afin de ne pas affecter votre environnement de production.

• Veillez à transférer tous les paramètres et toutes les personnalisations à l'environnement de test. La section Identifier et installer les personnalisations fournit des informations sur la collecte de ces informations.

Assurez-vous que les actions que vous effectuez dans l'environnement de test sont sans incidence sur l'environnement réel. Attachez une attention particulière aux points suivants :

• Connexions de données externes

  Même si vous utilisez une copie de l'environnement, le lien vers la source de données est réel. Les modifications que vous apportez aux données dans l'environnement de test ont un impact sur l'environnement de production.

• Exécution de commandes sur une base de données réelle toujours en production

  Veillez à utiliser des copies de vos bases de données pour les tests, non une version réelle se trouvant dans votre environnement de production. Par exemple, si vous exécutez Test-SPContentDatabase sur une base de données réelle, et non sur une copie, vous risquez d'affecter les performances de votre environnement de production.

Utilisation d’un environnement de test virtuel

Lorsque vous testez à l’aide d’un environnement virtualisé, vous n’avez pas besoin d’avoir beaucoup de matériel. Vous pouvez répliquer votre environnement en utilisant deux serveurs qui exécutent Hyper-V. Un serveur a des images pour les serveurs web frontaux et les serveurs d’applications, et l’autre serveur a des images pour les serveurs de base de données.

Toutefois, les environnements virtuels n'affichent pas nécessairement les mêmes mesures de performances que les environnements physiques. Si votre environnement de production est un environnement physique, vous devez tenir compte de cette différence quand vous calculez la durée nécessaire pour mettre à niveau votre environnement de production. En règle générale, vous pouvez obtenir de meilleures estimations de performances si vous utilisez un serveur physique pour SQL Server. Assurez-vous qu'il présente des spécifications de performances similaires à celles de votre serveur qui exécute SQL Server dans votre environnement de production.

Répartition des serveurs dans un environnement de test virtuel

Utilisation d’un environnement de test physique

Quand vous effectuez les tests sur un environnement physique, vous devez répliquer aussi fidèlement que possible votre environnement de batterie de serveurs de production proposé. Si vous simplifiez trop le nombre de serveurs web frontaux, de serveurs d'applications ou de serveurs de bases de données, vous ne serez pas en mesure d'anticiper avec précision le temps nécessaire au processus de mise à niveau. Vous ne vous donnerez pas la possibilité de découvrir des complications liées aux interactions entre des serveurs du même rôle (telles que les transactions SQL Server). Si vous avez plusieurs serveurs appartenant au même rôle dans votre batterie de production proposée, utilisez au moins deux serveurs pour ce rôle afin de tester les problèmes susceptibles de se produire.

Répartition des serveurs dans un environnement de test physique

Identifier et installer les personnalisations

Pour un processus de test précis, vous devez identifier toutes les personnalisations au sein de votre environnement actuel et les copier dans l’environnement de test. Pour plus d’informations sur les types de personnalisations que vous devez identifier, voir Créer un plan pour les personnalisations actuelles pendant la mise à niveau vers SharePoint 2013.

• Utilisez l'opération Stsadm -o enumallwebs sur toutes les bases de données de contenu dans votre environnement des Produits SharePoint 2010 pour identifier des personnalisations spécifiques dans des sous-sites. Cette opération répertorie un ID pour chaque collection de sites et sous-site dans votre environnement et les modèles sur lesquels repose le site. Pour plus d'informations, voir Enumallwebs : opération Stsadm.

• Utilisez un outil tel que WinDiff (fourni avec la plupart des systèmes d'exploitation Microsoft) pour comparer les serveurs de votre environnement de production avec les serveurs de votre batterie de test. Vous pouvez utiliser cet outil pour vérifier quels fichiers existent sur vos serveurs et quelles différences existent entre ces fichiers.

• Vérifiez si les fichiers web.config comportent des modifications, puis déterminez si l’élément SafeControls contient des contrôles personnalisés.

• Créez la liste de toutes les personnalisations que vous trouvez. Identifiez si possible la source des personnalisations. Déterminez par exemple si des compléments logiciels ou des modèles tiers ont été personnalisés en interne. Après en avoir identifié la source, vous pouvez rechercher des versions mises à jour ou à niveau des personnalisations.

Quand vous avez identifié toutes les personnalisations, copiez-les sur les serveurs appropriés au sein de votre batterie de test. Assurez-vous que les personnalisations suivantes sont déployées:

• Solutions : par défaut, les solutions héritées sont déployées dans les répertoires /14. Utilisez le paramètre CompatibilityLevel quand vous installez les solutions pour les déployer dans les répertoires /15. Pour plus d'informations, reportez-vous à Install-SPSolution.

• Pages maîtres personnalisées.

• JavaScript personnalisé.

• Fichiers CSS personnalisés (notamment ceux liés aux thèmes).

• Actions de flux de travail personnalisées (celles-ci doivent être incluses dans des fichiers d’actions).

• Vérifiez les paramètres de limitation de requête de grande liste pour vous assurer que les grandes listes s’affichent normalement.

Quand vous testez les personnalisations, appuyez-vous sur les conseils suivants :

• Vérifiez si l’aspect visuel présente des modifications.

• Vérifiez si le comportement présente des modifications.

• Effectuez des tests dans des collections de sites en mode 2010 et 2013.

• Recherchez tout problème lié au chargement des éléments linguistiques ou des ressources.

  Ce type de problème peut se produire quand des personnalisations existent en mode 2010 et que de nouvelles personnalisations les replacent en mode 2013. Le chargement du fichier adéquat peut s'avérer problématique, car il n'existe qu'un seul répertoire global pour les ressources linguistiques. Assurez-vous que les personnalisations de remplacement en mode 2013 comprennent les ressources 2010 afin que les personnalisations demeurent opérationnelles dans les deux modes.

• Vérifiez que la mise à niveau n'a pas affecté les personnalisations. Assurez-vous que les personnalisations ne bloquent pas la mise à niveau des collections de sites.

Vous pouvez utiliser l’applet de commande Microsoft PowerShell Test-SPContentDatabase avant d’attacher une base de données à SharePoint 2013 pour déterminer si des personnalisations sont manquantes dans l’environnement. Exécutez cette commande pour chaque base de données quand vous avez restauré les bases de données sur votre serveur de base de données, mais avant de procéder à la mise à niveau. Notez que cette applet de commande s'exécute automatiquement, et qu'elle ne génère pas de message tant qu'aucun problème n'est détecté.

Copier les données réelles dans l’environnement de test et mettre à niveau les bases de données

Vous n'atteindrez pas vos objectifs de test si vous n'utilisez pas vos données réelles. Utilisez les outils de sauvegarde et de restauration Microsoft SQL Server pour créer une copie de vos bases de données de contenu et de services.

Il n'existe pas de meilleur moyen d'anticiper ce qui se produira au cours d'une mise à niveau que d'effectuer le test sur une copie de toutes les données. Toutefois, cette option peut s'avérer irréaliste pour un test initial. Vous pouvez effectuer le test par phases, en testant une base de données à la fois par exemple (si les bases de données sont volumineuses) afin de passer en revue toutes les particularités de vos données. Si vous préférez, vous pouvez assembler un sous-ensemble de données provenant de sites représentatifs de votre environnement. Si vous souhaitez commencer par tester un sous-ensemble de vos données, veillez à ce que le sous-ensemble présente les caractéristiques suivantes :

• Le sous-ensemble des données contient des sites qui sont typiques de ceux que vous entretenez dans votre environnement.

• La taille et la complexité des sous-ensembles de données sont très proches de la taille et de la complexité réelles de votre environnement.

Après avoir copié les données, démarrez un premier processus de mise à niveau pour voir ce qui se produit. Il ne s'agit que d'une étape préliminaire. Suivez les étapes décrites dans Mettre à niveau des bases de données de contenu de SharePoint 2010 vers SharePoint 2013 pour essayer le processus de mise à niveau de l’attachement de base de données.

Quand vous testez le processus de mise à niveau, veillez à tester les services qui sont partagés entre les batteries de serveurs. Prenez en considération tous les états, tels que les suivants :

• Batterie SharePoint Server 2010 connectée à une batterie de services SharePoint 2013.

• Batterie SharePoint 2013 connectée à une batterie de services SharePoint 2013.

• Batteries de serveurs de versions différentes pour différents services.

Utilisez l’environnement de test pour rechercher tous les problèmes de sécurité, de configuration, de compatibilité et de performance susceptibles d’affecter les applications de service.

Passer en revue les résultats après la mise à niveau des bases de données

Quand la mise à niveau de test est terminée, vous pouvez passer en revue les résultats et revisiter vos plans. Consultez les fichiers journaux, observez les sites mis à niveau et passez en revue vos personnalisations. Comment la mise à niveau a-t-elle fonctionné dans votre environnement ? Qu'avez-vous découvert ? Que devez-vous repenser à propos du plan de mise à niveau ?

Passer en revue les fichiers journaux

Passez en revue le fichier journal de mise à niveau et le fichier journal des erreurs de mise à niveau (générés lors de l’exécution de la mise à niveau). Le fichier journal de mise à niveau (.log) et le fichier journal des erreurs de mise à niveau (.err) sont disponibles à l'emplacement %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LOGS. Les fichiers journaux sont nommés au format suivant : Upgrade- AAAAMMDD-HHMMSS-SSS.log, où AAAAMMJJ est la date et HHMMSS-SSS est l’heure (heures au format d’horloge de 24 heures, minutes, secondes et millisecondes).

Le format des fichiers journaux respecte les conventions du service de journalisation unifiée (ULS, Unified Logging Service). Pour passer en revue les fichiers journaux afin d'identifier et de corriger les problèmes, démarrez en haut des fichiers. Les erreurs ou les avertissements peuvent être répétés s'ils se produisent dans plusieurs collections de sites au sein de l'environnement, ou s'ils bloquent complètement le processus de mise à niveau. Par exemple, si vous ne pouvez pas vous connecter à la base de données de configuration, le processus de mise à niveau essaiera (et échouera) plusieurs fois et ces tentatives seront listées dans le fichier journal.

Passer en revue les sites en mode 2010

Vérifiez que les collections de sites qui n'ont pas été mises à niveau fonctionnent correctement en mode 2010. Les sites doivent présenter les mêmes apparence et comportement que dans l'environnement des Produits SharePoint 2010. Certains changements sont attendus. Par exemple, Office Online et les fonctionnalités d’analytique web ont changé dans SharePoint 2013 et les sites qui utilisaient ces fonctionnalités seront affectés. Pour plus d’informations sur les éléments spécifiques à rechercher, voir Vue d’ensemble du processus de mise à niveau de SharePoint 2010 vers SharePoint 2013.

Réexécuter la mise à niveau le cas échéant

Si vous le souhaitez, vous pouvez redémarrer le processus de mise à niveau d’une base de données à l’aide de l’applet de commande Microsoft PowerShell Upgrade-SPContentDatabase . Pour plus d’informations sur cette applet de commande, voir Upgrade-SPContentDatabase. Pour plus d'informations, voir Redémarrer une mise à niveau avec liaison des bases de données ou une mise à niveau de collection de sites vers SharePoint 2013.

Mettre à niveau les collections de sites et Mes sites

Après avoir testé et validé la mise à niveau des bases de données de contenu et de services, vous pouvez tester le processus de mise à niveau pour les collections de sites. Suivez les étapes décrites dans Mettre à niveau une collection de sites vers SharePoint 2013 pour tester le processus de mise à niveau de la collection de sites. Si vous avez Mes sites dans votre environnement, voir Vue d’ensemble du processus de mise à niveau de SharePoint 2010 vers SharePoint 2013 pour plus d’informations sur le processus de mise à niveau.

Passer en revue les résultats après la mise à niveau des collections de sites

Examinez visuellement les sites mis à niveau pour identifier les problèmes à résoudre avant d’exécuter le processus de mise à niveau sur votre environnement de production. Pour plus d’informations sur les éléments spécifiques à rechercher, voir Vue d’ensemble du processus de mise à niveau de SharePoint 2010 vers SharePoint 2013.

Examinez du début à la fin les fichiers journaux de mise à niveau de la collection de sites pour déterminer s'ils comportent des problèmes. Vérifiez la section de résumé vers la fin du fichier journal pour connaître le nombre de problèmes et l'état réel de la mise à niveau (l'absence d'état signifie que le processus de mise à niveau a échoué et que la mise à niveau du site doit être renouvelée). Les fichiers journaux de la collection de sites sont stockés dans la collection de sites proprement dite (dans la bibliothèque de documents _catalogs/Upgrade) et sur le système de fichiers. Le fichier journal du système de fichiers contient des informations détaillées sur les problèmes rencontrés. La version de système de fichiers du fichier journal de mise à niveau du site se trouve à l'emplacement %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LOGS. Les fichiers journaux sont nommés au format suivant : SiteUpgrade- AAAAMMJJ-HHMMSS-SSS.log, où AAAAMMJJ est la date et HHMMSS-SSS est l’heure (heures au format d’horloge de 24 heures, minutes, secondes et millisecondes).

Ajuster les planifications et tester à nouveau

Répétez le processus de test tant que vous n’êtes pas certain d’avoir détecté tous les problèmes auxquels vous risquez d’être confronté et de savoir comment les résoudre. Votre objectif est de définir votre plan alors qu’il est 16 h 00 un dimanche, que vous devez rétablir la connexion le lundi matin et que cela ne fonctionne pas encore. Y a-t-il un point de non-retour ? Testez votre plan de secours et assurez-vous qu’il fonctionne avant de vous lancer dans la mise à niveau réelle.

Voir aussi

Autres ressources

Meilleures pratiques pour la mise à niveau de SharePoint 2010 vers SharePoint 2013

Planifier les performances pendant la mise à niveau vers SharePoint 2013

Mettre à niveau les bases de données de SharePoint 2010 vers SharePoint 2013

Upgrade a site collection to SharePoint 2013

Tester et résoudre les problèmes d'une mise à niveau vers SharePoint 2013