Dukel

Ich habe schon in #2 gesagt, dass du einen DC virtuell betreiben kannst, wenn du weißt was du machst. Ich würde unabhängig von der Frage DC virtuell oder Physisch immer (außer in non-Produktiven Umgebungen) min 2 DC's einsetzen.

Was hat einfach mit Ausfallsicherheit zu tun? Du kannst einen DC nutzen wenn du dir klar bist, dass in einem Ausfall (geplant oder ungeplant) unter Umständen nichts mehr geht.

Vor allem verlierst du bei bei deinem Plan ggf. Objekte, die zwischen dem Disasterfall und dem Restore angelegt worden sind, wenn du beide DC's zurückspielst.

Deswegen administriert man nicht direkt von der Maschine sondern per Webinterface vom Client oder per Powershell und psremoting. Bei einer Migration in eine neue Domäne musst du die Berechtigungen auch neu setzen.

Welche User sollen denn von extern zugreifen? Ersetzt die "Sharepoint Server Internet Site" Lizenz nicht die "Sharepoint Server"? Ach ja. Hier findest du noch ein paar Informationen: http://sharepoint.microsoft.com/de-de/buy/Seiten/Licensing-Details.aspx

Mir wäre ein "müsste" zu viel Risiko und würde das nicht so machen. Bei Server 2012 kannst du Snapshots machen.

Localhost? Wer hat das denn verbockt?

Hast du einen DC mit Windows Server 2012? Wenn nein, dann darfst du keine Snapshots von DC's zurückspielen!

Gib mal in der cmd. start /? ein. D.h. du startest im Task Scheduler "start" und als Parameter die gewünschten Einstellungen und dein Programm. Wenn das nicht so gehen sollte startest du als Programm eine cmd, in der start mit den entsprechenden Parametern aufgerufen wird.

Du schreibst von 2007. de/attach kann man auch bei migrationen von 2010 nach 2010 nutzen. Der TO möchte wohl nur den Sharepointserver wechsen.

Du willst das ganze in Powershell umsetzen.

Das sehe ich anders. Es gibt mehr gründe als nur ein Update für ein Contentdb de/attach. Wieso sollte man 2 Schritte mehr machen, wenn man wirklich die kompletten Inhalte 1:1 übernehmen möchte? Wenn man umstrukturieren möchte kann man das gern mit Import / Export machen aber das ist ja nicht jedes mal der Fall, wenn man SP irgendwo anders hin migriert.

Bei einem Hyper-V Server ist das kein Problem, bei einem Cluster schon (der Cluster bedingt AD, welcher virtuell läuft -> Ohne AD kein Cluster, ohne Cluster kein AD).

So wie ich den TO verstanden habe möchte er die Inhalte (Content DB) behalten und alles andere neu machen. Ich habe vor kurzem mit diesem System eine Testumgebung aus der Produktiven Umgebung hergestellt. Content DB kopiert, neuen Sharepoint aufgesetzt, DB angehängt und in Sharepoint bekannt gemacht. Danach habe ich nur noch Kleinigkeiten angepasst (z.B. Verknüpfungen zu Produktiven Diensten (BCS) geändert, dass diese auch auf die Testdatenbanken verweisen). Bevor ich jede einzelne Seite Ex- und Importiere geht das viel einfacher und Problemloser.

Man kann, wenn man es richtig macht, auch alle DC's virtualisieren. Wenn er sicher gehen will kann er auch auf den Server 2012 warten. Dort kann man Snapshots nutzen und DC's clonen.

Ich würde (solange die Versionsstände die selben sind) und man den kompletten Inhalt benötigt die Datenbanken einfach umhängen. @TO: habt ihr noch anderes im Sharepoint außer diese Teamseite?

Als Ansatz: (Get-Item .\filename.txt).CreationTime -eq (Get-Item .\filename.txt).LastWriteTime

Ich wüsste nicht, dass man außer SQL Querys etwas anderes mit dem SQL Management Studio machen kann. Ich würde lieber klären, dass euch der Hoster RDP freischaltet.

RDP Gateway brauchst du nur, wenn du z.B. den TS über das Internet verfügbar machen willst. Du brauchst den RDS Session Host (wenn ich den Namen so richtig noch im Kopf habe).

Alte Datenbank abhängen (oder offline nehmen und kopieren), auf neuen SQL Server kopieren, in SQL Server einbinden (attach), in Sharepoint bekannt machen. Achtung! Die Datenbankversionen / Sharepoint Versionen müssen die selben sein. Sonst geht es nur per Export / Import oder Backup / Restore.

Soll gehen: Hyper-V over SMB: Remote File Storage Support in Windows Server 2012 Hyper-V | TechEd Europe 2012 | Channel 9

Welche Maschinen willst du mit der Backupsoftware sichern? Wenn du die Virtuelle Umgebung sichern willst würde ich diesen nicht virtualisieren.

Dann musst du einen anderen Ansprechpartner findet, der dir das benötigte freischaltet.

Backup2Disk2Tape hat den Vorteil, dass man Deduplizierung machen kann. Wir haben vor ca. 200 Clients (+ die Server, Netapp und ESX Farmen) ins Backup aufzunehmen. Mit Tapes only wird das nicht gehen.

Migration von einer Standalone VM oder einem Hyper-V Cluster in ein anderes Hyper-V Cluster. Wobei dann fehlt auch das HA Feature, welches eher wichtiger ist als Storage Life Migration. Wann zieht man schon VM's von einer Storage auf die andere um? Life Migration und HA wird deutlich öfter passieren. Vor allem kann man mit Hyper-V 3.0 und SMB 3.0 Hyper-V auf einem SMB Fileserver liegen lassen (also die VM's). Da braucht man dann keine Shared Storage (außer man möchte den File Server clustern).