Meilleur auteur de réponses
Migration WSS 3.0 d'un environnement 32 a 64 bits

Question
-
Bonjour,
Je me pose la question suivante
J'ai 2 serveurs WSS 3.0 en 32 bits.
- WSS 3.0 Database service
- WSS 3.0 Web Application
Je souhaiterais migrer vers une nouveau serveur WSS 3.0 en 64 bits à l'aide d'un serveur SQL externe (aussi en x64).
J'ai donc prévu les actions suivantes:
- Sauvegarde de toutes les bases de données
- Restauration sur la base SQL externe
- Créé un nouveau serveur WSS 3.0 en mode "batterie de serveurs" et en le faisant pointer vers la base SQL externe.
- Ajouter la base de contenu sur une nouvelle application Web.
Est-ce que cela pourrait fonctionner ?
Merci de votre aide.
Jérémy Breuillardmardi 26 juillet 2011 08:56
Réponses
-
Bonjour Jeremy,
Voici quelques remarques :
- Inutile de sauvegarder la base de données de configuration, vous ne pourrez pas la recréer. Il vous faudra en recréer une à l'aide de l'assistant de configuration SharePoint. Je vous conseille de faire de même pour celle d'administration et d'en recréer une sur votre nouvel environnement (depuis SharePoint).
- Pas de problème ici.
- Pas de problème ici.
- Pas de problème ici.
Puisque vous changez d'environnement, profitez en pour laisser le premier disponible durant la migration, mais en lecture seule uniquement.
Je vous recommande de lire (ou relire) cette page du technet avant de commencer : http://technet.microsoft.com/fr-fr/library/cc263299(office.12).aspx
Sébastien PICAMELOT - http://blogs.developpeur.org/gribouillon/
- Proposé comme réponse Sébastien PICAMELOT mardi 26 juillet 2011 09:57
- Marqué comme réponse jrmyB mardi 26 juillet 2011 14:30
mardi 26 juillet 2011 09:57 -
Oui, le risque à déplacer du contenu SharePoint sur une autre URL c'est d'avoir à repasser sur tous les sites pour rectifier les url saisies par les utilisateurs.
L'avantage à procéder de la sorte, c'est que vous pouvez proposer à vos utilisateur leur contenus à leur emplacement d'origine.
Une utilisatrice qui avait saisit dans son content editor webpart, ou même dans un fichier excel un lien http://old:81/madoclib/mondoc.docx se plaindra que son lien ne fonctionne plus, sauf si vous avez un dispositif de redirection qui répond sous l'url http://old:81 qui est capable de rediriger la requète vers le nouveau serveur.
Nicolas Cambot - Blog Nelite- Marqué comme réponse jrmyB mercredi 27 juillet 2011 08:09
mardi 26 juillet 2011 20:08
Toutes les réponses
-
Bonjour Jeremy,
Voici quelques remarques :
- Inutile de sauvegarder la base de données de configuration, vous ne pourrez pas la recréer. Il vous faudra en recréer une à l'aide de l'assistant de configuration SharePoint. Je vous conseille de faire de même pour celle d'administration et d'en recréer une sur votre nouvel environnement (depuis SharePoint).
- Pas de problème ici.
- Pas de problème ici.
- Pas de problème ici.
Puisque vous changez d'environnement, profitez en pour laisser le premier disponible durant la migration, mais en lecture seule uniquement.
Je vous recommande de lire (ou relire) cette page du technet avant de commencer : http://technet.microsoft.com/fr-fr/library/cc263299(office.12).aspx
Sébastien PICAMELOT - http://blogs.developpeur.org/gribouillon/
- Proposé comme réponse Sébastien PICAMELOT mardi 26 juillet 2011 09:57
- Marqué comme réponse jrmyB mardi 26 juillet 2011 14:30
mardi 26 juillet 2011 09:57 -
Merci de votre réponse,
Je prend note de votre remarque sur le fait de laisser la base de données en lecture seule. Cependant, pour l'instant je rétablis les bases de données dans un environnement de developpement. Cela ne devrait donc pas avoir de conséquences sur l'environnement d'origine.
En fait, j'ai essayé de restaurer la base de contenu du serveur WSS 3.0 32 bits sur un serveur WSS 3.0 64bits. J'ai obtenu un message d'erreur me disant que les versions de SharePoint installées étaient différentes...
Je me suis donc dit qu'il était impossible de migrer une application Web d'un serveur 32bits sur un autre serveur 64bits (WSS3.0 ou foundation) par attachement de base de contenu.
C'est pourquoi je souhaite d'abord migrer vers un environnement x64.
Jusqu'a maintenant ma logique est-elle bonne ?
Jérémy Breuillardmardi 26 juillet 2011 10:05 -
Pour plus d'explications,
le problème:
J'ai un backup d'une application web SharePoint dont la topologie est :
- WSS 3.0 32bits sans ServicePack - Database Service;
- WSS 3.0 32bits sans ServicePack - WebApp/Search/E-mail.
Je souhaite migrer vers la topologie suivante:
- SharePoint Foundation (64bits);
- SQL Server (64bits).
Je souhaitais utiliser un serveur WSS 3.0 64bits à ma disposition pour restaurer le backup, installer le service Pack necessaire afin que l'application puisse être mise à niveau vers Foundation.
Ma question:
Peut-on faire un backup sur une version 32bits vers Foundation ou faut-il migrer vers un environnement WSS 3.0 64bits dans un premier temps?
Jérémy Breuillardmardi 26 juillet 2011 12:47 -
Bonjour,
Dans votre cas, il n'est pas nécessaire de passer par une étape intermédiaire WSS X64, si vous migrez bien vos données comme vous l'avez indiqué par détachement / attachement de base aux applications web.
Attention, ce type de migration ne prends en charge que le contenu, et si vous avez du code SharePoint Designer, ou des webparts (CEWP, par exemple), ou des fichiers comportant des liens vers le contenu SharePoint ces derniers ne fonctionneront plus, sauf si vous avez prévu un mécanisme de redirection.
Nicolas Cambot - Blog Nelitemardi 26 juillet 2011 14:43 -
Merci,
Oui j'utilise bien un détachement / attachement de base de contenu.
L'unique personnalisation est une master page sous SharePoint Designer, je devrais uniquement avoir à la redéfinir comme master page par défaut non ?Aussi, lors de la création de nouvelle application web qui accueillera l'ancienne, est-il possible de modifier l'url, par exemple:
ancienne: http://old:81
nouvelle: http://namenewserver(:80)
Jérémy Breuillardmardi 26 juillet 2011 14:52 -
Oui, le risque à déplacer du contenu SharePoint sur une autre URL c'est d'avoir à repasser sur tous les sites pour rectifier les url saisies par les utilisateurs.
L'avantage à procéder de la sorte, c'est que vous pouvez proposer à vos utilisateur leur contenus à leur emplacement d'origine.
Une utilisatrice qui avait saisit dans son content editor webpart, ou même dans un fichier excel un lien http://old:81/madoclib/mondoc.docx se plaindra que son lien ne fonctionne plus, sauf si vous avez un dispositif de redirection qui répond sous l'url http://old:81 qui est capable de rediriger la requète vers le nouveau serveur.
Nicolas Cambot - Blog Nelite- Marqué comme réponse jrmyB mercredi 27 juillet 2011 08:09
mardi 26 juillet 2011 20:08 -
J'essaye maintenant d'attacher la base de contenu à l'application Web.
L'administration centrale me dit d'utiliser la commande stsadm car l'opération va necessité du temps.
Je tape donc la commande suivante :
"Stsadm -o addcontentdb -url http://newnameserver -databasename dbname"
--> Mise à niveau effectuée sans erreur
Je redémarre "IISreset /noforce"
Je vais dans Admin Central / Application Management / Content Database / select Application Web
et la il n'y a pas de base de contenu associée.
Et lorsque j'essaye d'accéder à l'application Web : "The page cannot be found"
Svp
Jérémy Breuillardmercredi 27 juillet 2011 14:53 -
Quand je rajoute : "-clearchangelog"
J'obtiens:
"Access to table dbo.EventCache is blocked because the signature is not valid
Access to table dbo.TimerLock is blocked because the signature is not valid"
Jérémy Breuillardmercredi 27 juillet 2011 15:35 -
Bien, je tiens à ajouter :
Je me connecte à SQL Management Studio Express avec : \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query;
Je n'arrive pas à me connecter autrement. Je restaure donc la base avec un compte local.
Je pense que c'est pour ca que j'ai le message: "is blocked because the signature is not valid".
Comment je pourrais ajouter un compte de domaine pour faire les opérations?
Merci de suivre mon problème.
Jérémy Breuillardjeudi 28 juillet 2011 07:48