SharePoint Portal migreren - Serversoftware en clouddiensten

vrijdag 28 april 2006 08:23

Acties:

Topicstarter

Ik heb de uitdaging aangenomen om SharePoint Portal server 2003 te migreren naar een andere server. De nieuwe server betreft andere (virtuele) hardware met een andere naam en ip, bovendien in een ander Windows 2003 domein. Er ligt een trust tussen het oude en het nieuwe domein.
Het server OS is in beide gevallen 2003 server.

Deze concept procedure heb ik opgesteld:
1. SQL 2000 installeren op nieuwe server met zelfde SP
2. Installatie Sharepoint Portal en Sharepoint services op nieuwe server met zelfde SP
3. Antivirus instellen (exclusions)
4. SharePoint backup maken met spsbackup op oude server
5. Sharepoint stoppen op oude server.
6. SQL Databases migreren (SPS01_Config_db niet migeren) via detach/copy/attach methode
7. Portal Site restoren volgens procedure “Restoring a Portal Site” uit de Administrators Guide
8. Security/logins nakijken/opnieuw instellen (ivm nieuwe domein)
9. Backup instellen
10. Nieuwe url’s communiceren of omleiden naar nieuwe server.
11. MOM monitoring instellen

Heeft iemand dit eerder uitgevoerd en is dit een goede procedure?

|=|=|=||=|=|=||=|=|=| http://www.vanwijck.com |=|=|=||=|=|=||=|=|=||=|=|=||=|=|=||=|=|=||=|=|=|

vrijdag 28 april 2006 08:37

Acties:

Glorix Jim

Ja zo te zien heb je alles goed voor elkaar, behalve dat je niet de databases hoeft te migreren. De backup die je maakt met spsbackup is al een extractie van de database namelijk (als het bv niet lukt via de restore methode binnenin sharepoint dan kan je de uitgespuugde files van spsbackup ook gebruiken om ze als databases te restoren in sql server)

Inderdaad niet de configDB mee migreren (wat ook niet gebeurt als je een backup doet via spsbackup) Daarnaast wordt WSS (Sharepoint services) automatisch geinstalleerd als je SPS (Portal) installeert.

Zorg ervoor dat je op je nieuwe server een lege IIS virtual directory hebt zodat je daar op kan restoren.
Zorg ervoor dat de service accounts die je gebruikt (application pool / account voor contentdb / account voor config db) ook local admin zijn op de server.

Ik zou die antivirus ook pas instellen als je helemaal klaar bent met de migratie. Als het goed is, is het enige wat dat ding tegenhoudt de mailtjes die worden verstuurd vanuit OWSTIMER (de alerts dus).

Als je nog vragen hebt dan check mn msn maar glorix_jim at hotmail.com

vrijdag 28 april 2006 08:58

Acties:

paulhekje

Topicstarter

Dat ik de sql db's niet hoef te migreren was ik ondertussen zelf ook achter; het originele plan was namelijk eerst de databases te migreren naar een andere server dan de Sharepoint server.
Voor die actie is een prima whitepaper beschikbaar. (Technet: Moving Windows SharePoint Services Databases). Maar helaas moet alles weer naar de zelfde server, dan kunnen we over een half jaar weer een migratieactie uitvoeren.

Nog een vraag over de logins:
Welke locaties moeten allemaal gecontroleerd worden qua user/group permisies?

[ Voor 33% gewijzigd door paulhekje op 28-04-2006 09:09 ]

|=|=|=||=|=|=||=|=|=| http://www.vanwijck.com |=|=|=||=|=|=||=|=|=||=|=|=||=|=|=||=|=|=||=|=|=|

vrijdag 28 april 2006 09:41

Acties:

Glorix Jim

Waar je de SQL databases neerzet maakt niet uit hoor. Al is het een andere server, zolang je maar alle bestanden hebt van de spsbackup backup dan maakt het niet uit, je kan namelijk tijdens de restore aangeven wat de SQL database wordt/moet zijn.

Wat bedoel je precies met locaties?

vrijdag 28 april 2006 09:50

Acties:

paulhekje

Topicstarter

met die locaties bedoel ik o.a.:

http://localhost:3533/ntadmingroup.aspx "Set SharePoint Administration Group"

"Manage Users" direct onder de portal site

We gaan naar een ander domein, dus hier moet het 1 en ander aangepast worden. Tegelijk kunnen we userpermissies schrappen en er groepen voor in de plaats zetten.

[ Voor 39% gewijzigd door paulhekje op 28-04-2006 09:51 ]

|=|=|=||=|=|=||=|=|=| http://www.vanwijck.com |=|=|=||=|=|=||=|=|=||=|=|=||=|=|=||=|=|=||=|=|=|

vrijdag 28 april 2006 09:52

Acties:

Glorix Jim

Nou als je in hetzelfde domein blijft (of als er een trust is met het 'oude' domein) dan blijven al die usersettings gewoon gewaarborgd.

vrijdag 28 april 2006 09:54

Acties:

paulhekje

Topicstarter

Ja, maar niet alle oude settings zijn gewenst... Bovendien moet het oude domein op termijn verdwijnen.
Een checklist waar je allemaal moet kijken naar uitgedeelde rechten zou dus handig zijn.
...
De trust blijkt ineens maar 1 kant op te liggen, dus we moeten alle user/group rechten omzetten.

[ Voor 28% gewijzigd door paulhekje op 28-04-2006 09:58 ]

|=|=|=||=|=|=||=|=|=| http://www.vanwijck.com |=|=|=||=|=|=||=|=|=||=|=|=||=|=|=||=|=|=||=|=|=|

vrijdag 28 april 2006 10:01

Acties:

Glorix Jim

Om hoeveel portals + teamsites gaat het?
Als het er niet zoveel zijn dan is het misschien het snelst om gewoon screendumps te maken van al die pagina's.

Als het wel wel om veel portals + teamsites gaat dan zou je een applicatie kunnen bouwen die van elke site weergeeft wat de users zijn en wat hun rol is. Helaas is er geen standaard functionaliteit voor binnen Sharepoint. (als je trouwens een voorbeeld wil hebben dan kan ik dat wel posten)
Ook is er een Sharepoint Util suite (waar ik persoonlijk nog geen ervaring mee heb) die is te downloaden van http://blogs.msdn.com/krichie/archive/2006/04/26/584663.aspx

Tip als je gaat werken met groepen; gebruik cross-site groups. Hiermee kan je groepen maken die onafhankelijk werken van AD (en dus ben je niet afhankelijk van een AD beheerder).

[ Voor 19% gewijzigd door Glorix Jim op 28-04-2006 10:05 ]

vrijdag 28 april 2006 10:16

Acties:

paulhekje

Topicstarter

Het betreft maar 1 portal en 3 sites, dus de screendump methode is prima te doen.
Om niks te vergeten vroeg ik me af wat "al die pagina's" precies zijn.

Een aparte groepenstructuur bijhouden binnen Sharepoint levert m.i. alleen extra beheerwerk op. Gewoon alle rechten met groepen in AD beheren is het handigst.

|=|=|=||=|=|=||=|=|=| http://www.vanwijck.com |=|=|=||=|=|=||=|=|=||=|=|=||=|=|=||=|=|=||=|=|=|

vrijdag 28 april 2006 10:58

Acties:

Glorix Jim

Je hebt twee urls waar je de users op kan managen. Namelijk
- /_layouts/1033/user.aspx <-- op site niveau
- /_layouts/1033/siteusrs.aspx <-- op sitecollectie niveau

Maar in jouw geval is het alleen belangrijk om de user.aspx (dus de 'Manage users' link) te gebruiken

En het extra beheerwerk valt eigenlijk wel mee hoor met crossite groups.
Maar in organisaties waar het beheer van AD bijvoorbeeld niet voor handen ligt, omdat je er simpelweg geen rechten toe hebt, dan zijn die crosssite groups een uitkomst (spreekt uit ervaring)

[ Voor 3% gewijzigd door Glorix Jim op 28-04-2006 10:59 ]

donderdag 4 mei 2006 14:15

Acties:

paulhekje

Topicstarter

Ondertusen heb ik een proefmigratie uitgevoerd. Ik ben tegen de volgende punten aangelopen:

Welke service packs geïnstalleerd zijn moet je echt naar zoeken; mbv control panel/add/remove programs/support information Sharepoint portal versie gevonden: 11.0.6715.0 is gelijk aan SP1 + security fix.
Tevens staat in de sitedb in de tabel systemversion het versienummer van WSS: 6.0.2.6411
Als het versienummer van WSS niet klopt mislukt de restore met spsbackup, foutmelding: "database schema is too old"
SP1 is er zowel voor het WSS deel als het Portal gedeelte en bij deze server was alleen het WSS deel geïnstalleerd. Het Portal services versienummer moet ook kloppen met de backupfiles anders wil spsbackup de manifest xml file niet openen. workaround: met notepad versie nummer wijzigen.

Hierna was het soepel restoren en even handmatig wat rechten wijzigen.

NB: uninstall van een service pack kan niet...

[ Voor 8% gewijzigd door paulhekje op 04-05-2006 14:17 ]

|=|=|=||=|=|=||=|=|=| http://www.vanwijck.com |=|=|=||=|=|=||=|=|=||=|=|=||=|=|=||=|=|=||=|=|=|

zaterdag 6 mei 2006 12:19

Acties:

Glorix Jim

Nee dat is logisch dat die SP1 uninstall niet werkt, hij past namelijk de database aan. Wat je wel kan doen is vooraf (dus een pre SP1) backup maken van je databases. Dan pas SP1 installeren en als het dan fout gaat, dan compleet Sharepoint deinstalleren en opnieuw installeren