Sharepoint VMWare Server Clone

Henning Eiben Als Antwort am 26 Apr. 2010 11:28

Hmm, nicht so ganz einfach. Also, du kannst die Datenbanken einer bestehenden MOSS Instanz "verschieben" (aus sicht deiner ge-clonten Testumgebung handelt es sich ja um ein verschieben) ... http://technet.microsoft.com/en-us/library/cc512725.aspx.

Aber du musst dabei natürlich aufpassen, dass du nicht die Live-Datenbank beeinflusst. Problematisch sehe ich ggf. auch, dass der Clone ja genauso heißt wie das Originial. Also ein entfernen des Clones aus der Config-DB der Produktiven Umgebung wäre nicht gut für die Produktive MOSS-Maschine.

Ich würde ggf. überlegen das komplett installierte Produktiv-System nicht zu clonen - so attraktiv das zu sein scheint. Wenn du aber mehrere Tage damit verbringst das an einen Test DB-Server zu hängen, dann kannst du dein Testsystem fast besser installieren.

lewing Als Antwort am 26 Apr. 2010 11:40

Genau bei der Beeinflussung sehe ich das Problem, kann den Testserver leider nicht nur auf den Test-Datenbankserver zugreiffen lassen. Und das ganze im Live-Betrieb zu machen, ist mir irgendwie das Risiko doch zu hoch.

Der Sinn von dem Image ist eigentlich Probleme des Produktivsystems in Ruhe nachvollziehen zu können und ich befürchte wenn ich das Testsystem neu aufsetze, gar nicht die selben Probleme bekommen werde.

Henning Eiben Als Antwort am 27 Apr. 2010 17:14

OK - wenn du natürlich Probleme des Produktivsystems analysieren willst, dann ist ein neuaufsetzen nicht unbedingt hilfreich. Aber wie schon gesagt, wenn du den Server clonest und ebenfalls auf den produktiven DB-Server zeigen lässt, dann musst du auf jeden Fall ein paar kleine Anpassungen machen.

IMHO kannst du nur einen Server haben, auf dem die Zentraldadministration läuft, nach dem clonen hast du aber zwei (angenommen du clonst den Server mit der Zentraladminisration). Jetzt ist die Frage, wie du die dort runter (bzw. deaktiviert) bekommst :)

Ebenfalls negativ kann sich natürlich auswirken, wenn du eine Problemlösung auf dem Clone durchführst, damit aber Inhalte in der Content-DB oder der Config-DB machst. Das wirkt sich dann natürlich auch sofort auf das Produktivsystem aus! Also mal eben ein WebPart entfernen ist dann nicht so gut. Das wird erst dann zum Problem, wenn die vermeintliche Fehlerbehebung mehr neue Fehler birgt als dass sie alte Fehler behebt.

lewing Als Antwort am 27 Apr. 2010 17:59

Eigentlich will ich alle Content & Config DB auf einen Test-DB-Server kopieren, damit der Server eigenständig laufen kann.

Ich seh derzeit nur die Möglichkeit, den Server vom Netz her von der Produktiv-DB zu trennen und anschließend die Test-DB usw. zu verbinden. Leider ist das organisatorisch nicht unbedingt einfach.

C.Kaiser Als Antwort am 27 Apr. 2010 20:46

Moin,

VMware bietet zum clonen ein Tool an, welches die wichtigsten Informationen zurücksetzt (wie beispielsweise den Rechnernamen und ich glaube auch IP Adresse), damit es nicht zu Problemen mit mit dem "Host" kommt. Ich meine das Tool heißt "sysprep" o.ä..
Ich würde mich da aber mal richtig schlau machen und mit Leuten reden die das schon öfters mit Live Servern gemacht haben.

Zum Thema Verbindung mit DB-Server:
Wenn die IP Adresse durch das Tool zurückgesetzt wird, sollte es kein Problem sein, da du den neuen Server erstmal nicht im Netz hast. Ansonsten würde ich halt für kurze Zeit den DB-Server offline nehmen, den neuen SharePoint hochfahren und entsprechende Änderungen vornehmen (IP Adresse ändern) damit er sich nicht auf den DB Server verbinden kann.

Henning Eiben Als Antwort am 28 Apr. 2010 09:21

Der Name bzw. die IP-Adresse des ge-clonten Servers sehe ich nicht direkt als Problem. Das kannst du mit den Tools von VMWare gut abhandeln.

Wenn du allerdings nur den Web-Server clonst, und dem keine Netzwerkverbindung gibst, dann kann er sich nicht mit der Config-DB verbinden. SharePoint geht aber noch immer davon aus, dass es mit der Config-DB auf dem Produktiven DB-Server verbunden ist. SharePoint selbst wirst du ohne Config-DB und Content-DB nicht verwenden können - wie auch, es gibt ja keinerlei Inhalte. Also musst du deinen ge-clonten SharePoint auf eine andere Datenbank zeigen lassen. Das bedeutet, dass du aus sicht des ge-clonten SharePoint Servers die Datenbanken "verschieben" musst (ist ja eher ein kopieren, aber für SharePoint ist wichtig, dass seine Config-DB und Content-DB wo anders liegen).

Das verschieben der Config-DB geht am einfachsten, indem du den Server von der aktuellen Config-DB trennst, dann die Config-DB auf den neuen DB-Server kopierst (nicht verschieben, wir wollen die ja in Produktion weiter verwenden) und dann den SharePoint wieder mit der Config-DB auf dem neuen DB-Server verbindest.

Ich fürchte nur, dass wenn der SharePoint einen anderen Namen hat, dass er sich dann nicht mehr von der Config-DB trennen lassen wird - und verbinden mit einer anderen Config-DB geht auch nicht, weil man sich immer nur mit einer Config-DB verbinden kann (und SharePoint hat ja noch Config-DB Verbindungsdaten). Wenn du den Namen nicht änderst, und du trennst deinen ge-clonten SharePoint von der Config-DB, dann könnte das auch Auswirkungen auf den original SharePoint haben (z.B. wird nicht mehr richtig erkannt auf welchem Server die Zentraladministration ausgeführt wird).

lewing Als Antwort am 28 Apr. 2010 16:05

Sehe ich ähnlich, vorallem muß ich zuerst am Produktion Server die Datenbanken trennen, dann ein Image erstellen und anschließend die Datenbanken richtig verbinden und hoffen, dass keine alten Verbindungen bleiben.

Ich denke jetzt ernsthaft darüber nach das Produktionssystem auf ein neues System zu migrieren. Kennt dafür jemand ein gutes Tool oder Anleitung?

Ich sehe 3 Möglichkeiten:
- Neu-Konfiguration am neuem Server, Export am alten server, Import am neuen (Fehlende Features usw suchen)
- Neu-Konfiguration am neuem Server, Content-DB kopieren und an den neuen Server hängen
- Mittels Tool die Site-Collections übernehmen (falls es da etwas gibt)

Danke für eure Unterstützung, bzw. Ideen!

C.Kaiser Als Antwort am 28 Apr. 2010 22:06

Wieviel habt ihr denn in der ConfigDB / Zentraladministration eingestellt? Ich persönlich würde fast nie die ConfigDB migrieren.

Du kannst den Server clonen und mittels Konfigurationswizard / psconfig eine neue ConfigDB auf einem neuen SQL Server anlegen. Mittels Datenbank Migration (bzw kopieren) kannst du den Inhalt wieder auf den geclonten Server bringen.

Oder aber du installierst die Büchse komplett neu und migrierst / kopierst nur die ContentDBs.

Henning Eiben Als Antwort am 29 Apr. 2010 10:05

Naja, wenn du die ConfigDB nicht kopierst, dann musst du auf jeden Fall alle Solutions neu deployen. Die sind zwar noch auf dem Web Front End Server drauf, aber der SharePoint weiß nichts von seinem Glück :)

Ansonsten müsstes du noch ggf. auf AAM-Einstellungen achten, die also mal eben "aufpinnen" und neu einstellen.

... Wo ich das gerade so schreibe: was ist denn mit Timer-Jobs? Die sind doch bestimmt auch in der Config-DB hinterlegt. Wenn du also laufende Workflows hast, was passiert dann mit denen? Oder sind die Jobs in der Content-DB?

lewing Als Antwort am 29 Apr. 2010 14:17

Und zuvor auch wissen welche Solutions alle oben waren, bzw. welche davon verwendet werden. *seufz*
Bezüglich Timer-Jobs, ich hoffe doch, dass die in der Content-DB stehen.

Hast du schon eins dieser Tools zur Migration eingesetzt?

Henning Eiben Als Antwort am 29 Apr. 2010 16:56

Leider nein. Habe auf dem letzetn Usergroup Treffen Jan Tietze von AvePoint kennengelernt, der die Produkte von AvePoint gezeigt hat.

Ansonsten für die reine Inhaltsmigration haben wir in einem Kundenprojekt schon mal den SharePoint Content Deployment Wizard verwendet.

Henning Eiben Als Antwort am 29 Apr. 2010 10:09

Also sowohl Quest als auch AvePoint haben sehr mächtige Tools für SharePoint. Ich denke, dass du damit auf jeden Fall dein System migrieren kannst - kommt auf die Größe deiner Farm an, ob sich die Investition in ein solches Tool lohnt.