Résoudre les problèmes et reprendre la mise à niveau (Office SharePoint Server)

  • Article

Mise à jour : 2009-03-05

Dans cet article :

  • Informations d’ordre général sur le dépannage et le redémarrage de la mise à niveau

  • Problèmes connus d’analyse de pré-mise à niveau

  • Problèmes connus de mise à niveau sur place

  • Problèmes connus de mise à niveau progressive

  • Problèmes connus de migration de base de données

  • Problèmes connus de sites personnalisés

Informations d’ordre général sur le dépannage et le redémarrage de la mise à niveau

Si la mise à niveau s’arrête, vous pouvez utiliser les méthodes suivantes pour résoudre les problèmes :

  • Consultez les fichiers journaux de mise à niveau et recherchez le terme « error». Les fichiers journaux de mise à niveau se trouvent dans le dossier %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\LOGS. Pour plus d’informations sur l’affichage du fichier journal de mise à niveau, voir Vérifier la mise à niveau (Office SharePoint Server).

    TipConseil :

    Utilisez le composant fonctionnel Rechercher dans des fichiers et dossiers de Windows pour rechercher des itérations de « erreur » rapidement dans ces fichiers journaux.

  • Examinez les événements dans l’Observateur d’événements et recherchez d’éventuelles erreurs d’application.

  • Consultez le fichier Lisez-moi pour en apprendre plus sur les problèmes connus et leurs solutions. Les erreurs sont souvent des problèmes que vous pouvez contourner.

  • Si vous exécutez une mise à niveau progressive, vérifiez si les collections de sites qui étaient en cours d’exécution apparaissent dans la nouvelle version. Si tel est le cas, vous pouvez exécuter la solution de contournement ou remplacer le site de la nouvelle version par celui de l’ancienne et réessayer de mettre à niveau le site. Pour plus d’informations sur le rétablissement des sites, voir Rétablir la version précédente d’un site (Office SharePoint Server).

  • Une mise à niveau sur place peut être redémarrée à l’aide de la commande stsadm –o upgrade. La mise à niveau ignore les tâches déjà terminées et continue à partir du point d’interruption. Pour plus d’informations sur l’opération de mise à niveau, voir Mettre à niveau des sites (Office SharePoint Server).

Problèmes connus d’analyse de pré-mise à niveau

La mise à niveau est bloquée si vous utilisez Localhost en tant que nom de serveur

L’utilisation de « localhost » comme nom de serveur peut provoquer de nombreux problèmes dans votre environnement et n’est pas recommandée. Si vous utilisez « localhost » comme nom de serveur, lorsque vous exécutez l’outil d’analyse de pré-mise à niveau, ce problème est enregistré et la mise à niveau ne peut pas continuer. Vous devez renommer le serveur, puis exécuter une opération dans prescan avant de poursuivre avec la mise à niveau. Suivez les étapes ci-dessous pour renommer votre serveur et corriger le problème pour l’outil d’analyse de pré-mise à niveau.

  1. Sauvegardez la base de données de configuration.

  2. À partir de la ligne de commande, spécifiez le chemin d’accès suivant : %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\60\bin et exécutez la commande suivante pour modifier le nom du serveur dans la base de données de configuration :

    Stsadm.exe -o setconfigdb -databaseserver <nom serveur> -connect

  3. À partir de la ligne de commande, spécifiez le chemin d’accès suivant : %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\bin et exécutez la commande suivante pour effacer le problème lié à l’outil d’analyse préalable à la mise à niveau :

    Prescan /fixlocalhost

  4. Sur la ligne de commande, exécutez la commande suivante pour réexécuter le processus d’analyse de pré-mise à niveau :

    Prescan /all

    • Si elle réussit, poursuivez la mise à niveau.

    • Si elle échoue toujours, un service utilise encore le nom de serveur localhost. À ce stade, la mise à niveau n’est pas bloquée, mais certains services ne sont pas mis à niveau.

Problèmes connus de mise à niveau sur place

Vous devez utiliser un compte de domaine, et non pas Service réseau, pour les mises à niveau de batteries de serveurs

Pour une mise à niveau sur place ou progressive dans un environnement de batterie de serveurs, vous devez utiliser les mêmes informations d’identification que celles de l’environnement de la version précédente dans l’environnement de votre nouvelle version. Toutefois, si vous utilisiez le compte Service réseau pour votre ancien environnement, vous devez plutôt utiliser un compte de domaine dans la nouvelle version. L’environnement de votre ancienne version peut poursuivre l’utilisation du Service réseau, mais lorsque vous installez la nouvelle version et créez la nouvelle batterie de serveurs, vous devez fournir un compte de domaine à la place. N’oubliez pas d’octroyer au compte de domaine que vous utilisez les droits appropriés dans les bases de données SQL Server (vous devez être membre des créateurs de base de données, des administrateurs de processus et du groupe Propriétaires de base de données pour toutes les bases de données de la version précédente).

Certains paramètres ne sont pas préservés dans l’application Web lorsque vous effectuez une mise à niveau sur place.

Si vous utilisez le protocole SSL et que vous effectuez une mise à niveau sur place, vous devez utiliser l’outil de mappage des accès de substitution pour modifier l’URL au sein de Microsoft Office SharePoint Server, car certains paramètres ne sont pas préservés dans l’application Web.

Avant d’effectuer la mise à niveau, si vous disposez d’une entrée AAM utilisant le protocole HTTPS, telle que ci-dessous :

URL entrante : https://<nom du serveur>

URL sortante : https://<nom du serveur>

Après une mise à niveau sur place d’Office SharePoint Server 2007, cette entrée sera définie incorrectement :

URL entrante : https://<nom du serveur>

URL sortante : http://<nom du serveur>

Pour corriger l’URL, sur le site Web de l’Administration centrale de SharePoint, dans la page Opérations, cliquez sur Mappages des accès de substitution, puis sur Modifier les URL publiques pour redéfinir l’URL ainsi :

URL entrante : https://<nom du serveur>

URL sortante : https://<nom du serveur>

Pour plus d’informations sur les mappages des accès de substitution, voir Planifier les mappages des accès de substitution (Office SharePoint Server).

La mise à niveau s’achève sur le premier serveur Web frontal, mais avec des échecs

Dans une batterie de serveurs qui utilise plusieurs serveurs Web frontaux, si la mise à niveau s’achève sur le premier serveur Web frontal mais avec des échecs, il est recommandé de résoudre le problème et de réexécuter la mise à niveau avant d’entreprendre de mettre à niveau d’autres serveurs Web frontaux.

Si, pour une raison quelconque, vous voulez ignorer l’erreur (parce que, par exemple, cet incident concerne une collection de sites très peu utilisée), vous pouvez passer à la mise à niveau du deuxième serveur Web frontal en utilisant l’outil en ligne de commande Psconfig. Utilisez l’opération en ligne de commande suivante :

Psconfig -cmd upgrade -inplace b2b -wait -force

NoteRemarque :

Vous ne pouvez pas utiliser l’Assistant Configuration des produits et technologies SharePoint pour mettre à niveau des serveurs Web frontaux supplémentaires si vous utilisez l’outil en ligne de commande Psconfig.

Erreur de séquence SPConfigurationDatabase2 dans le journal de mise à niveau

Si vous effectuez une mise à niveau sur place qui échoue, vérifiez le fichier journal Upgrade.log qui se trouve dans le dossier COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\LOGS. Si le message d’erreur suivant s’affiche sur votre écran : « [SPConfigurationDatabaseSequence2] [ERROR] [date] : Le rôle ’WSS_Content_Application_Pools' existe déjà dans la base de données en cours », vous pouvez utiliser les solutions de contournement suivantes pour résoudre le problème :

  • Exécutez les requêtes SQL suivantes dans la base de données de configuration.

    delete from dependencies

    delete from objects

    delete from classes

    delete from sitemap

    exec sp_droprole N'WSS_Content_Application_Pools'

    NoteRemarque :

    Si le rôle supprimé comporte des membres au moment où l’action échoue, l’appel sp_droprole renvoie le nom de ces membres. Vous devez ensuite exécuter la commande suivante pour chaque membre.

    exec sp_droprolemember N'WSS_Content_Application_Pools',

    N'usernameReturnedFromSP_DropRole'

    Ensuite, vous devez réexécuter la requête suivante.

    exec sp_droprole N'WSS_Content_Application_Pools'

  • Créez une batterie de serveurs V3, puis attachez la base de données de contenu existante. Cette option conserve toutes les données d’utilisateur, mais pas les informations de configuration qui étaient stockées dans la base de données de configuration V2, notamment les packages WebPart et les paramètres des serveurs virtuels.

  • Si l’erreur d’origine est résolue (par exemple, si elle était due à la perte de la connectivité réseau ou à l’insuffisance d’espace disque de l’ordinateur SQL Server et que le problème a été réglé), vous pouvez restaurer la batterie de serveurs V2 et reprendre la mise à niveau.

NoteRemarque :

N’oubliez pas de redémarrer la mise à niveau après avoir appliqué les solutions de contournement.

Vous ne pouvez pas utiliser les définitions de sites de Microsoft Office SharePoint Portal Server 2003 pour les sites Web Office SharePoint Server 2007

Si vous utilisez les mêmes modèles de définition de site personnalisés à la fois pour SharePoint Portal Server 2003 et Office SharePoint Server 2007, vous rencontrerez des erreurs de page en accédant à votre site Web. Vous ne pouvez pas utiliser les modèles de définition de site personnalisés que vous avez créés pour SharePoint Portal Server 2003. Vous devez créer de nouveaux modèles de définition de site personnalisés pour Office SharePoint Server 2007.  Vous devez également créer un fichier de mise à niveau de définition de site qui mappe les éléments personnalisés de votre ancienne définition de site personnalisée vers la nouvelle définition de site personnalisée, afin que chaque élément de votre site (par exemple, une page personnalisée) puisse être mise à niveau vers le nouvel élément approprié. Pour plus d’informations sur la création de nouvelles définitions de site pour Office SharePoint Server 2007, voir Développer de nouvelles définitions de site personnalisées et créer les fichiers de définition de mise à niveau (Office SharePoint Server) et Déployer des fichiers de définition de mise à niveau et de nouvelles définitions de site (Office SharePoint Server). Pour plus d’informations sur les scénarios pris en charge et non pris en charge pour l’utilisation des définitions de site personnalisées, consultez l’article 898631, Prises en charge et non prises en charge des scénarios d’utilisation des définitions de site personnalisé et des définitions de zone personnalisé dans Windows SharePoint Services, dans SharePoint Portal Server 2003 et dans Office SharePoint Server 2007 dans la Base de connaissances Microsoft (https://go.microsoft.com/fwlink/?linkid=140380&clcid=0x40C).

Lien rompu vers le fichier d’aide lorsque vous attachez une base de données de contenu existante à une nouvelle batterie de serveurs

Quand vous créez une nouvelle batterie de serveurs puis que vous attachez une base de données de contenu existante, le composant WebPart Listes d’origine contient une URL qui pointe vers le fichier d’aide de la version précédente du produit. Le fichier d’aide de la version précédente du produit n’est pas disponible sur le serveur. De ce fait, le lien Ressources d’aide des produits et technologies Microsoft SharePoint, qui désigne l’URL suivante :
http://< serveur:numéro_port>/_vti_bin/help/1033/sps/html/HelpResources.htm
affiche un message d’erreur qui indique que la page est introuvable (HTTP Error 404). Supprimez le lien pour résoudre le problème.

La mise à niveau sur place peut échouer pour les batteries moyennes ou grandes contenant des serveurs Web non principaux lorsque vous utilisez le site Web par défaut dans IIS

Si votre batterie de serveurs moyenne ou grande contient un ou plusieurs serveurs qui ne sont pas des serveurs Web principaux et si vous avez utilisé le site Web par défaut dans les services Internet (IIS) pour héberger un site SharePoint, la mise à niveau peut échouer avec un message indiquant que le site Web par défaut ne peut pas être mis à niveau. Pour contourner ce problème, avant d’exécuter la mise à niveau, sur tous les serveurs Web non principaux (tels que le serveur d’index), donnez un autre nom au site Web par défaut dans les services Internet (IIS), exécutez la mise à niveau, puis restaurez le nom Site Web par défaut. Il est inutile de renommer le site Web sur les serveurs Web principaux de la batterie.

Si vous ne renommez le site Web par défaut dans IIS avant d’exécuter la mise à niveau, cette dernière échoue. Si cela se produit, vous pouvez renommer le site Web par défaut sur les serveurs Web non principaux, puis reprendre la mise à niveau. Vous pouvez utiliser l’opération de ligne de commande suivante pour reprendre la mise à niveau :

psconfig -cmd upgrade -inplace previous versionv -wait -force

La mise à niveau sur place peut échouer s’il existe plusieurs sites portail portant la même URL dans votre environnement

Si votre environnement contient plusieurs sites portail à la même adresse, l’assistant Configuration des produits et technologies SharePoint échoue avec l’erreur suivante dans le fichier journal : Un élément avec la même clé a déjà été ajouté. Cette erreur se produit si certains sites portail sont orphelins (ils existent dans les services Internet (IIS) ou dans le système de fichiers, mais pas dans la base de données de configuration). Votre environnement peut avoir atteint cet état de l’une des manières suivantes :

  • Vous avez supprimé par inadvertance, puis recréé le site Web IIS qui héberge un site portail.

  • Vous avez supprimé l’extension d’un serveur virtuel existant, puis réétendu le même serveur virtuel pour héberger un nouveau site portail.

  • Plusieurs sites Web IIS partagent le même numéro de port.

Pour déterminer si des sites portent des URL en double, dans votre environnement SharePoint Portal Server 2003, accédez à la page Répertorier et gérer les sites portail dans l’Administration centrale de SharePoint et recherchez les sites portail portant la même URL. Déterminez le site en cours d’utilisation et le site orphelin, puis supprimez le site orphelin avant d’exécuter la mise à niveau.

La mise à niveau sur place peut afficher les URL incorrectes pour les sites dans l’Administration centrale si vous créez le site Administration centrale sur un serveur Web non principal

Si vous effectuez une mise à niveau sur place sur une grande batterie de serveurs et avez exécuté la mise à niveau sur un serveur d’index avant de l’exécuter sur un serveur Web principal, alors l’Administration centrale est créée sur le serveur d’index au lieu du serveur Web principal. Dans ce scénario, il se peut que l’Administration centrale affiche des noms d’hôte incorrects pour les URL vers les sites Web en cours de mise à niveau sur la page État de la mise à niveau du contenu du site. Pour contourner ce problème, vous pouvez ajouter un autre mappage d’accès pour que le site de l’Administration centrale pointe vers l’URL correcte du serveur Web principal.

  1. Dans le Gestionnaire des services Internet (IIS) sur le serveur Web principal, vérifiez le nom d’hôte et le numéro de port de l’Administration centrale.

  2. Ouvrez l’Administration centrale sur le serveur d’index et, sous l’onglet Opérations, sous Configuration globale, cliquez sur Mappages des accès de substitution.

  3. Dans la page Mappages des accès de substitution, cliquez sur Modifier les URL publiques.

  4. Dans la page Modifier les URL des zones publiques, cliquez sur la flèche vers le bas Collection de mappages des accès de substitution, puis sélectionnez Modifier la collection de mappages des accès de substitution.

  5. Dans la zone Sélectionnez une collection de mappages des accès de substitution, cliquez sur Administration centrale.

  6. Dans la section URL publiques, dans la zone Intranet, tapez l’URL correcte pour l’Administration centrale sur le serveur Web principal, puis cliquez sur Enregistrer.

  7. Sur le serveur Web principal, ouvrez l’Administration centrale et, dans l’onglet Opérations, sous Mise à niveau et migration, cliquez sur État de la mise à niveau du contenu du site.

    Les URL doivent s’afficher correctement.

La mise à niveau de l’adresse de démarrage de la recherche et des types de fichier peut échouer si une adresse de départ inhabituelle est configurée dans Microsoft Office SharePoint Portal Server 2003

Si votre adresse de démarrage pour l’indexation est inhabituelle, par exemple http://nom_serveur/nom_serveur.com, la mise à niveau de la recherche peut ne pas parvenir à mettre à niveau les adresses de début et les types de fichier, et vous devez entrer manuellement ces paramètres de configuration dans votre environnement Office SharePoint Server 2007.

Problèmes connus de mise à niveau progressive

Vous devez utiliser un compte de domaine, et non pas Service réseau, pour les mises à niveau de batteries de serveurs

Pour une mise à niveau sur place ou progressive dans un environnement de batterie de serveurs, vous devez utiliser les mêmes informations d’identification que celles de l’environnement de la version précédente dans l’environnement de votre nouvelle version. Toutefois, si vous utilisez le compte Service réseau pour votre ancien environnement, vous devez plutôt utiliser un compte de domaine dans la nouvelle version. L’environnement de votre ancienne version peut poursuivre l’utilisation du Service réseau, mais lorsque vous installez la nouvelle version et créez la nouvelle batterie de serveurs, vous devez fournir un compte de domaine à la place. N’oubliez pas d’octroyer au compte de domaine utilisé les droits appropriés dans les bases de données SQL Server (vous devez être membre des créateurs de base de données, des administrateurs de processus et du groupe Propriétaires de base de données pour toutes les bases de données de la version précédente).

Étapes supplémentaires requises pour une mise à niveau progressive de serveurs SSL

La mise à niveau progressive utilise un ensemble de paires de sites Web IIS pour héberger le site d’origine (non mis à niveau) et le nouveau site (mis à niveau). Par défaut, le nouveau site qui est créé n’utilise pas le protocole SSL. Si ce site Web doit utiliser le protocole SSL, vous devez effectuer des étapes supplémentaires au cours de la mise à niveau progressive pour définir les paramètres IIS et le numéro de port corrects pour SSL.

Procédez comme suit après que vous avez créé l’application Web cible pour vos sites, mais avant de mettre à niveau les sites.

Pour plus d’informations sur la création de l’application Web cible, voir la section Créer une application Web pour héberger les sites mis à niveau dans Mettre à niveau des sites (Office SharePoint Server).

Modifier les numéros de port et les paramètres SSL dans le Gestionnaire IIS

  1. Dans le Gestionnaire IIS, cliquez sur le signe plus (+) à côté du nom du serveur qui contient l’application Web que vous souhaitez modifier.

  2. Cliquez sur le signe plus (+) en regard de Sites Web.

  3. Cliquez avec le bouton droit sur Site Web par défaut, puis cliquez sur Propriétés.

  4. Dans l’onglet Site Web, dans la zone Port SSL, tapez 444, puis cliquez sur OK.

  5. Cliquez avec le bouton droit sur Site Web par défaut, puis cliquez sur Propriétés.

  6. Dans l’onglet Site Web, dans la zone Port SSL, tapez 443, puis cliquez sur OK.

  7. Dans l’onglet Sécurité de répertoire , dans la section Communications sécurisées, cliquez sur Certificat de serveur.

    Suivez les étapes de l’Assistant pour attribuer un nouveau certificat.

  8. Dans l’onglet Sécurité de répertoire , dans la section Communications sécurisées, cliquez sur Certificat de serveur.

  9. Dans la boîte de dialogue Communications sécurisées , sélectionnez la case à cocher Requérir un canal sécurisé, puis cliquez sur OK.

  10. Cliquez sur OK pour fermer la boîte de dialogue Propriétés de Site Web par défaut.

Mettre à jour les paramètres de mappage des accès de substitution et réinitialiser IIS

  1. Ouvrez une fenêtre d’invite de commandes et spécifiez le répertoire suivant : %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\bin.

  2. Exécutez la commande suivante pour modifier le mappage des accès de substitution pour que le site Web par défaut d’origine pointe vers le port 444 :

    Stsadm -o addzoneurl -url https://server_name:port -urlzone default -zonemappedurl https://server_name:444

    Où server_name:port est l’emplacement du site Web par défaut.

  3. Accédez au répertoire suivant : %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\60\bin.

  4. Exécutez la commande suivante pour modifier le mappage des accès de substitution pour le site Web redirigé :

    Stsadm -o addzoneurl -url http://server_name:port -urlzone default -zonemappedurl https://server_name:443

    Où server_name:port est l’emplacement du site qui a été créé lors de la création de l’application Web cible.

  5. Exécutez la commande suivante pour réinitialiser IIS :

    iisreset /noforce

J’ai finalisé la mise à niveau, mais certains sites n’ont pas été mis à niveau. Que puis-je faire ?

Si vous avez finalisé le processus de mise à niveau, vous ne pouvez plus utiliser la méthode de mise à niveau progressive pour mettre à niveau les sites restants. Vous pouvez, toutefois, utiliser l’approche de migration de base de données pour mettre à niveau les sites. Pour plus d’informations sur l’utilisation de la migration de base de données pour mettre à niveau des sites après avoir finalisé une mise à niveau progressive, voir l’article 926718 dans la Base de connaissances Microsoft (https://support.microsoft.com/kb/926718).

Il se peut que la recherche à partir d’un portail enfant ne trouve pas les nouveaux documents après une mise à niveau progressive avec les services partagés

Si vous avez mis à niveau un portail enfant qui consommait les services partagés d’une batterie parent, vous devez mettre à jour les mappages d’URL de substitution du site portail pour qu’ils pointent vers l’URL mise à niveau. Dans le cas contraire, lorsque les utilisateurs effectuent une recherche à partir du portail enfant, il se peut que le contenu ajouté au portail enfant ne soit pas visible.

ImportantImportant :

Les étapes suivantes doivent être effectuées dans l’environnement SharePoint Portal Server 2003.

Mettre à jour les mappages d’URL de substitution du site portail

  1. Cliquez sur Démarrer, pointez sur Tous les programmes, sur SharePoint Portal Server, puis cliquez sur Administration centrale de SharePoint.

  2. Sous Configuration du serveur virtuel et du site portail, cliquez sur Configurer d’autres URL de site portail pour l’accès intranet, extranet et personnalisé.

  3. Dans le menu déroulant du site mis à niveau sur le portail enfant, cliquez sur Modifier.

  4. Dans la page Modifier les autres paramètres d’accès, dans la zone URL de l’intranet, entrez l’URL du site d’origine, puis cliquez sur OK.

    L’URL par défaut doit désormais pointer vers le site mis à niveau et l’URL intranet vers le site d’origine.

  5. Effectuez une analyse pour l’environnement SharePoint Portal Server 2003.

    Pour plus d’informations sur l’exécution d’une analyse, voir la page relative à la gestion des mises à jour des index de contenu (en anglais) (https://office.microsoft.com/en-us/sharepointserver/CH011715081033.aspx) (en anglais) du guide de l’administrateur SharePoint Portal Server 2003 .

La mise à niveau de l’adresse de démarrage de la recherche et des types de fichier peut échouer si une adresse de départ inhabituelle est configurée dans SharePoint Portal Server 2003

Si votre adresse de démarrage pour l’indexation est inhabituelle, par exemple http://nom_serveur/nom_serveur.com, la mise à niveau de la recherche peut ne pas parvenir à mettre à niveau les adresses de démarrage et les types de fichier, et vous devez entrer manuellement ces paramètres de configuration dans votre environnement Office SharePoint Server 2007.

Mon site portail parent n’a pas été analysé après la mise à niveau.

Aucune analyse n’est effectuée sur un portail parent si les conditions suivantes sont remplies :

  • Vous utilisez les services partagés.

  • Votre batterie de serveurs est grande et contient plusieurs serveurs d’index.

  • Il existe une règle d’exclusion pour le portail parent sur l’un de ces serveurs d’index.

  • Pour générer les index, vous pouvez supprimer la règle ou la faire passer d’une règle d’exclusion à une règle d’inclusion, puis réeffectuer l’analyse.

Ma requête a échoué sur le portail parent après la mise à niveau avec des serveurs de requête distincts

Si vous utilisez la propagation d’index de requête entre batteries, il faut un certain temps pour initialiser les serveurs de requête. Sur chacun d’entre eux, exécutez l’opération suivante sur la ligne de commande pour être certain qu’ils sont initialisés :

stsadm.exe -o osearch -propagationlocation <applications directory>

Où <applications directory> représente l’emplacement des données d’index pour tous les fournisseurs de services partagés, tels que :

applications
   SSP1 (as a GUID)
   SSP2 (as a GUID)
   SSP3 (as a GUID)

Mon portail mis à niveau parent ne possède pas les adresses de démarrage converties, uniquement les adresses de démarrage d’origine, pour le contenu toujours présent dans les sites SharePoint Portal Server 2003

Après une mise à niveau progressive, il se peut que le site portail ne possède pas les URL temporaires correctes répertoriées comme adresses de démarrage, mais seulement les adresses de démarrage d’origine. Pour contourner ce problème, procédez comme suit :

  1. Dans SharePoint Portal Server 2003, dans les pages d’administration de la recherche, ajoutez une règle d’exclusion pour supprimer tout le contenu désormais stocké dans l’environnement Office SharePoint Server 2007.

  2. Ajoutez une nouvelle source de contenu pour analyser la nouvelle URL des sites toujours dans l’environnement SharePoint Portal Server 2003.

  3. Effectuez une analyse dans l’environnement SharePoint Portal Server 2003.

Si le service Office SharePoint Server Search ne démarre pas automatiquement pendant la mise à jour, le message suivant s’affiche dans l’Assistant Configuration des produits et technologies SharePoint :

Échec du démarrage du service SearchServiceInstance sur ce serveur après la mise à niveau. Démarrez-le manuellement.

L’Assistant Configuration des produits et technologies SharePoint se termine correctement, mais le service Office SharePoint Server Search demeure arrêté. Pour démarrer le service Office SharePoint Server Search :

  1. Ouvrez une fenêtre d’invite de commandes et spécifiez le dossier suivant :

    %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\BIN

  2. Exécutez la commande suivante :

    stsadm –o osearch –action start

J’ai sélectionné l’option « Ne pas mettre à niveau » dans l’écran d’installation, mais entretemps j’ai changé d’avis et je souhaite maintenant effectuer une mise à niveau.

Si vous avez sélectionné l’option Ne pas mettre à niveau au cours de l’installation, puis changé d’avis après avoir exécuté l’Assistant Configuration des produits et technologies SharePoint, vous devez réexécuter cet assistant pour passer à une mise à niveau progressive.

Utiliser l’Assistant Configuration des produits et technologies SharePoint pour passer de l’option « Ne pas mettre à jour » à une mise à niveau progressive

  1. Exécutez l’Assistant Configuration des produits et technologies SharePoint pour vous déconnecter de la batterie de serveurs.

  2. Accédez à %COMMOMPROGRAMFILES%\Microsoft shared\Web Server Extensions\12.0\WSS\ et remplacez la clé de Registre par V2V_GRADUAL_UPGRADE pour SetupType et SetupTypeBackup.

  3. Réexécutez l’Assistant Configuration des produits et technologies SharePoint pour effectuer la mise à niveau.

Échec de la mise à niveau des produits et technologies SharePoint

Si vous ajoutez un nouveau serveur Web à une batterie de serveurs existante qui n’a pas d’applications Web, et si vous mettez à jour le serveur Web, puis que vous exécutez l’Assistant Configuration des produits et technologies SharePoint, vous pouvez obtenir le message d’erreur suivant :

Une exception de type Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException s’est produite. Informations complémentaires sur l’exception : Échec de mise à jour des produits et technologies SharePoint.

Cette erreur se produit lorsque l’Assistant Configuration des produits et technologies SharePoint ne peut pas localiser ou modifier le fichier Web.config. Pour résoudre le problème, vous devez copier manuellement le fichier Web.config de %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\Config vers %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\Template\Layouts. Lorsque le fichier Web.config se trouve dans le dossier Layouts, vous pouvez réexécuter l’Assistant Configuration des produits et technologies SharePoint.

La mise à niveau échoue et, dans le journal de mise à niveau, un message d’erreur signale l’absence du Web

Si vous effectuez une mise à niveau progressive et que la mise à niveau échoue, vous devez consulter le journal de mise à niveau, qui se trouve dans le dossier %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\LOGS. Si le message d’erreur dans le journal de mise à jour indique l’absence du Web, le site Web a été supprimé. Le résultat est qu’aucun site Web ne se trouve à l’emplacement en question. Pour résoudre ce problème, arrêtez puis relancez le service du minuteur Windows SharePoint Services, puis réexécutez la mise à niveau.

Problèmes connus de migration de base de données

Vous ne pouvez pas ajouter la même base de données de contenu plusieurs fois à une batterie de serveurs, même sur différentes applications Web

Chaque collection de sites dans une base de données de contenu (y compris chaque site portail) possède un identificateur global unique (GUID), enregistré dans la base de données de configuration. Par conséquent, ajouter la même collection de sites (ou portail) à deux reprises sur la batterie de serveurs, même dans des applications Web distinctes, n’est pas possible. Bien que l’attachement de base de données réussisse dans ce cas, la collection de sites ne peut pas être démarrée. Si vous avez besoin d’une copie identique d’une collection de sites (ou portail) dans la même batterie de serveurs, attachez tout d’abord la base de données qui contient la collection de sites à une batterie de serveurs séparée, puis utilisez les opérations de sauvegarde et restauration de Stsadm.exe pour copier la collection de sites vers l’autre batterie de serveurs. Le processus de sauvegarde et de restauration crée un nouveau GUID pour la collection de sites.

Pour les environnements de services partagés, vous devez exécuter une commande supplémentaire avant de détacher une base de données

Lorsque vous effectuez une migration de base de données dans un environnement de services partagés, avant de détacher (ou sauvegarder) les bases de données, vous devez exécuter l’opération suivante sur la ligne de commande :

Stsadm.exe -o preparetomove -contentDB <database_server:database_name>

Cette opération garantit que la base de données de contenu sera incluse dans la synchronisation d’appartenance et de profil une fois que vous la rattachez. Si vous n’exécutez pas cette opération avant de détacher la base de données de contenu, alors les informations d’appartenance et de profil de la base de données de contenu sont statiques et ne seront pas synchronisées après la mise à niveau.

Si vous n’avez pas effectué cette opération avant de détacher la base de données, vous pouvez exécuter l’opération suivante après l’attachement au lieu de résoudre le problème de synchronisation :

Stsadm.exe -o preparetomove -oldcontentDB <GUID> -newcontentDB <Database_name>

Notez que vous devrez déterminer le GUID de la base de données avant de pouvoir exécuter l’opération preparetomove pour une base de données déjà détachée. Pour trouver le GUID, utilisez l’opération suivante :

stsadm -o sync -listolddatabases <days>

Pour plus d’informations sur la façon de détacher une base de données, voir Attachement et détachement des bases de données.

N’attachez pas la base de données des paramètres de composants (_SERV) ni la base de données des profils utilisateur (_PROF) au cours d’une migration de base de données

Lorsque vous effectuez la migration d’une base de données, il est inutile de migrer et d’attacher la base de données des paramètres des composants SharePoint Portal Server 2003 (la base de données de recherche, généralement nommée « ID _SERV » où ID représente un ID tel que le nom du serveur) ou la base de données des profils utilisateur (_PROF). À la place, vous devez recréer la base de données de recherche et reconfigurer vos paramètres de recherche lorsque vous effectuez une migration de base de données. Cela est dû au fait que les paramètres de recherche de SharePoint Portal Server 2003 étaient stockés dans le Registre sur le serveur et dans la base de données, et une migration de base de données ne contient pas tous les paramètres.

Si vous attachez la base de données (de recherche) des paramètres de composants pendant la migration de base de données, le processus de mise à niveau échoue lors de la mise à niveau des services partagés et le message suivant peut s’afficher : Procédure stockée 'dbo.proc_MSS_PropagationGetQueryServers' introuvable.

Recommencez la migration de base de données et n’attachez pas la base de données des paramètres de composants (_SERV) ou la base de données des profils utilisateur (_PROF) .

Ma page de site Web mise à niveau ne contient pas le lien Mon Site après avoir attaché la base de données de contenu

Dans des environnements de services partagés qui incluent des sites Mes Sites, après une mise à niveau de la migration de base de données, les pages de site Web mises à niveau n’incluent pas le lien Mes Sites. Lorsque vous effectuez une migration de base de données, vous effectuez une mise à niveau sur place des bases de données, mais vous ne procédez pas à la mise à niveau des données de configuration de votre batterie de serveurs. Par conséquent, l’URL de votre hôte Mon Site n’est pas configurée dans votre batterie de serveurs mise à niveau.

Après la migration de la base de données de contenu qui contient les sites personnels vers la nouvelle batterie de serveurs, définissez l’URL à utiliser comme emplacement d’hébergement Mon Site. Sur la page d’accueil d’administration des services partagés, dans la section Profils utilisateur et Mes sites, cliquez sur Paramètres du site Mon site. Dans la section Services de sites personnels, tapez /MySite comme URL de l’application Web pour l’emplacement d’hébergement Mon Site sur votre batterie de serveurs mise à niveau. /MySite est le chemin d’accès créé par défaut dans l’application Web pour le site SharePoint. Pour plus d’informations, voir Configurer les paramètres de Mes sites.

Problèmes connus de sites personnalisés

Une erreur d’application peut se produire lorsque des personnalisations non autorisées sont apportées aux fichiers Web.config

Certaines personnalisations ne sont pas autorisées dans les fichiers Web.config des sous-dossiers contenus dans un serveur virtuel. Par exemple, les nœuds AUTHENTICATION et SESSIONSTATE ne sont pas autorisés dans le fichier Web.config à ce niveau. La modification du fichier Web.config à l’aide de méthodes qui ne sont pas recommandées peut entraîner des résultats inattendus pour la mise à niveau. N’oubliez pas de suivre les pratiques recommandées pour les personnalisations, y compris celles du fichier Web.config. Pour plus d’informations, voir Meilleures pratiques pour garantir la réutilisation et la mise à niveau des applications dans Windows SharePoint Services (en anglais) sur le site Web MSDN (https://msdn2.microsoft.com/fr-fr/library/ms916859.aspx) .

Télécharger ce livre

Cette rubrique est incluse dans le livre à télécharger suivant pour une lecture et une impression plus faciles :

Vous trouverez la liste complète des livres disponibles sur Livres à télécharger pour Office SharePoint Server 2007.