SharePoint : Suite de la migration WSS V2 -> WSS V3 - Comment détecter les listes non migrées correctement
Dans série de mes turpitudes de migration, après l'attaque au corps à corps avec la base de contenu, voila un problème qu'il faut absolument traquer après la migration et avant les appels des utilisateurs en détresse.
En effet, comme je l'ai expliqué dans un précédent article, lors de la migration avec un modèle de site défini, on se doit de faire un fichier de Mapping.
Malgré toutes les attentions prises lors de la création de ce fichier et dans le cas de modèle de liste défini dans la version 2 de WSS, peut entrainer des erreurs après la migration :
- Exception occurred. (Exception from HRESULT: 0x80020009 (DISP_E_EXCEPTION)): Ce cas se produit quand le mapping est effectué mais que les pages d'exécution ne supportent pas la liste en question
- Erreur 404: cette erreur apparaît sur le mapping n'est pas effectué
- ...
Ces erreurs proviennent des pages ASPX de listing (AllItems.aspx) de formulaire, d'édition, ..., bref toutes les pages ASPX techniques de WSS concernant une liste. Ceux n'existent pas réellement sur l'environnement mais font appel à des pages d'exécution internes (que l'on trouve dans le sous-répertoire TEMPLATE) :
- pages\viewpage.aspx
- pages\form.aspx
- ...
Premier cas :
Dans le cas de la première erreur, la modification des pages d'exécution a bien été faite par la migration mais celles-ci ne fonctionnent pas avec votre liste. Je n'ai pas trouvé d'autre solution que de recréer la liste et de copier les Item de la ferme source vers la destination.
Second cas :
Le fait est que dans le cas d'une ferme importante (plus de 100 collections et plusieurs 10aines de Go), on ne peut plus se permettre de tester tous les sites/sous-sites/listes, ...
La méthode que j'ai trouvée est plus brutale mais terriblement efficace, on attaque la base de contenu (classique avec moi vous direz) avec une requête qui va chercher les documents ASPX qui sont restés dans l'ancien chemin d'exécution :
Ainsi, j'utilise les requêtes suivantes :
USE [CONTENTDB]
-- POUR AVOIR TOUS LES FICHIER (1033 est le LCID)
SELECT * FROM dbo.AllDocs
WHERE SetupPath LIKE '%1033%' AND LeafName LIKE '%aspx%'
-- POUR AVOIR LES SITES A CORRIGER
SELECT DISTINCT DirName FROM dbo.AllDocs
WHERE SetupPath LIKE '%1033%' AND LeafName LIKE '%aspx%'
Ensuite, une fois ces listes recréées et chargées, vous pouvez supprimer les anciennes ne fonctionnant pas grace à SharePoint Designer (pour une fois je le trouve utile ;))
Romelard Fabrice [MVP]
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
