Schlagwort-Archive: 2008R2

Servermigration 2003SBS zu 2008 R2 Standard

Heute steht die Migration für einen Kunden, vom Small Business Server 2003 zum Windows Server 2008 R2 Standard an. Nach einiger Recherche haben wir uns entschieden, die Serverhardware weiterhin zu nutzen und den Server um RAM zu erweitern.

Die Migration werde ich in mehreren Schritten aufteilen. Zunächst werde ich den jetzigen Small Business Server zu einer Virtuellen Maschine migrieren, um die Hardware für die Neuinstallation freizubekommen und gleichzeitig eine Fallback Lösung zu haben, falls die Migration nicht über das Wochenende abgeschlossen wird.

Die Migration der Domäne stellt dabei kein zeitliches Problem dar, aber es gibt so einige Kundenprogramme, die auf dem Server laufen und diese müssen Montagfrüh wieder zur Verfügung stehen. Wie z.B. Charly Solutio und DBSWin.

P2V Migration

Der erste Schritt war eine Physical 2 Virtual Migration. Dazu habe ich mir auf einem Client Server 2008 R2 mit Hyper-V installiert und darauf einen weiteren Server 2008 R2 als DC und mit SCVMM 2008 R2. Um die P2V zu beschleunigen, habe ich im Vorfeld alle nicht benötigten Dateien und Verzeichnisse vom vorhandenen SBS kopiert und gelöscht. Anschließend wurde über den SCVMM 2008 eine P2V angestossen, welche aufgrund der geringen Kapazität, innerhalb von 60 Minuten abgeschlossen war. Nun steht mir der Server virtuell unter der gleichen IP-Adresse zur Verfügung und als Notfall habe ich noch immer ein Backup.

Nachdem Server 2008 R2 auf der vorhandenen Hardware installiert wurde, war zunächst einmal zu erkennen, dass die Allseits beliebte 3Com 905B nicht mehr supported wird. Alle weiteren Geräte wurden einwandfrei vom Server 2008 R2 erkannt.

Domänenaufnahme

Nun geht es an die Domänenaufnahme. Der neue Server wird als weiterer DC der Domäne hinzugefügt. Um dies zu gewährleisten, ist zunächst eine Vorbereitung der vorhandenen Domäne notwendig. Dazu ist von der Server 2008 R2 CD das Verzeichnis adprep auf den vorhandenen SBS zu kopieren. Anschließend über die Kommandozeile in das kopierte Verzeichnis wechseln und nacheinander adprep32.exe /forestprep und adprep32.exe /domainprep ausführen. Da es sich bei dem SBS 2003 um einen einzelnen Server handelt, wurde auch noch der empfohlene Befehl adprep32.exe /domainprep /gpprep zur Anpassung der Gruppenrichtlinien angehangen. Nach den Updates der Domäneninformationen sollte ein Blick in die EReignisanzeige pflicht sein um zu schauen, ob wirklich alles geklappt hat.

WSUS-Migration

Nächster Schritt war die WSUS Migration, die sich aber sehr schnell erledigen lässt. WSUS über Rollen hinzufügen und für die Erstsynchronisation als Replikatserver einrichten. Danach wurde der Server wieder als Eigenständiger Updateserver eingerichtet und als Updatequelle der MS Server angegeben. Anschließend noch eine abschließende Konfigurationsprüfung und Start der Erstsychnronisation. Natürlich sollte die Anpassung der Gruppenrichtlinien nicht vergessen werden, damit die Clients zukünftig Kontakt mit dem neuen Server aufnehmen.

FSMO Rollen verschieben

Die FSMO-Rollen wurden von mir über die grafische Oberfläche verschoben. Dies geht schnell und führt an der Kommandozeile vorbei 😉 Wer dazu eine Anleitung sucht, findet eine sehr ausführliche bei Yusufs Blog FSMO-Rollen.

Druckerrolle

Auf dem Server wurde die Druckerrolle von Server 2008 R2 aktiviert. Bei den Clients handelt es sich um XP Clients, daher sind sowohl die x64 als auch die x86-Treiber zu implementieren. Dazu sind die Windows 7 Treiber in der 32Bit Variante zu wählen, in denen, im Normalfall auch abwärts die Treiber für XP und 2000 enthalten sind.

Installation von Solutio Charly

Nun stand der schwierigere Teil auf der Agenda. Die Installation der Anwendungssoftware. Derzeit nutzt Charly als Datenbank Primebase, doch diese Version und der Support wird zum Ende des Jahres eingestellt und zukünftig wird als Grundlage Postgre verwendet. Im Zuge der Servermigration wurde gleichzeitig noch eine Migration der Datenbank vorgenommen. Wie so häufig, ist auch hier anzumerken, dass eine Datensicherung unumgänglich ist. Durch den neuen Server wurde eine Neuinstallation von Charly vorgenommen und die Datenbank aus den bestehenden Daten wieder aufgebaut. Mit ein paar Anpassungen, war dieser Teil weitgehend unproplematisch. An dieser Stelle möchte ich mich für die Unterstützung bedanken, die mir Solutio am Freitag noch gewährt hat.

Anpassung DBSWin

Eine weitere Hürde stellte DBSWin dar. Hier ist, neben der Neuinstallation auf dem Server, eine Anpassung der ini-Dateien auf den jeweiligen Clients notwendig. Zum einen muss der Servername dem neuen entsprechen (eine DNS-Umleitung reicht leider nicht aus) ebenso musste der Druckerpfad angepasst werden. Nachdem DBSWin wieder erneut installiert wurde, ist eine erneute Freischaltung des Version notwendig. Dies lässt sich nur in Zusammenarbeit mit der Hotline erledigen.

 

 

Installation einer Offline Root CA

Aufgrund eines Fehlers und wahrscheinlich, weil ich nicht aufgepasst habe, habe ich bei der Migration von ESXi auf Hyper-V eine VM gelöscht, auf der meine Offline CA gespeichert war. Natürlich hatte ich ausgerechnet von diesem Zertifikat keine Datensicherung des privaten Schlüssels. Da in der Root CA auch noch ein Designfehler vorhanden war bzgl. der CRL, habe ich mich dazu entschieden, ein neues Root Zertifikat zu erstellen und die vorhandenen Designfehler zu korrigieren.

Da sieht man mal wieder, wie wichtig eine vernünftige Planung, auch in einer Testumgebung ist und das man natürlich die Datensicherung, gerade von kritischen Geräten nicht vergessen sollte 😉

Die Grundkonfiguration lässt sich mit folgenden Schritten schnell erledigen:

  1. 1. Standard-Installation von Windows Server 2008 R2 Enterprise Edition (Aktivierung auch gleich erledigen)
  2. Primären DNS-Suffix eintragen
  3. Unter C: ein Verzeichnis ADCS mit zwei Unterverzeichnissen „Database“ und „Logs“ anlegen
  4. Serverrolle Active Directory Zertifikatsdienste (Active Directory Certificate Services) installieren
  5. Bei Rollendiesten „Zertifizierungsstelle“ auswählen
  6. Installationstyp „Eigenständig
  7. Zertifizierungsstellentyp „Stammzertifizierungsstelle
  8. Privater Schlüssel „Neuen privaten Schlüssel erstellen
  9. Kryptografiediensteanbieter: „RSA#Microsoft Key Storage Provider
    1. Schlüsselzeichenlänge „4096“ (meine Empfehlung)
    2. Hashalgorithmus „SHA1
  10. Allgemeiner Name dieser Zertifizierungsstelle „F1NaLByte Root Authority“ (denkt euch euren eigenen aus 😉 )
  11. Gültigkeitsdauer, da es sich um eine Offline Root CA handelt, kann diese zwischen 20 und 30 Jahren liegen. Wenn dieses Zertifikat kompromitiert werden sollte, verliert es ohnehin seine Gültigkeit.
  12. Zertifikatdatenbank, auswählen des im Vorfeld angelegenten Database-Verzeichnis für die Datenbank und Logs-Verzeichnis für die Logs.

Restliche Abfragen mit Standardwerten bestätigen. Daraufhin ist die Rolle installiert.

Konfiguration Sperrlistenverteilungspunkt

Nun müssen die Sperrlisteninformationen angepasst werden, dass ist wichtig! Hier sind zunächst alle Einträge mit „ldap“ und „file“ zu löschen, siehe Bild.

Das ganze sollte, nach geänderter Konfiguration, folgendermaßen aussehen:

Eintragen einer verfügbaren URL

Konfiguration Stelleninformationen

Zuletzt sollte ebenfalls der Zugriff auf die Stelleninformationen angepasst werden.

Konfiguration des Zugriffs auf die Stelleninformationen

Veröffentlichung der Sperrliste

Nächster Schritt ist die Konfiguration für das Veröffentlichungsintervall der Sperrliste. Da ich mit dieser Root CA nur meine Sub CA autorisiere, kann das Intervall ziemlich hoch eingestellt werden. Dies sollte aber im Einzelfall betrachtet werden. Bei Ausstellung von mehrere SubCA, sollte man das Intervall entsprechend der Anforderungen anpassen. In meinem Fall habe ich mich für 2 Jahre entschieden.

 

Konfiguration der Zertifikatssperrliste
Zertifikatssperrliste Konfiguration

Nun muss noch die Zertifikatssperrliste veröffentlicht werden: Veröffentlichung der Zertifikatssperrliste

Ist der „File-Pfad“ nicht verändert worden, so befindet sich die veröffentlichte Sperrliste nun an folgendem Ort: „C:WindowsSystem32CertSrvCertEnroll

Speicherort der Sperrliste

Diese beiden Dateien können nun mit dem Root- Zertifikat exportiert werden. Die beiden Dateien müssen unter der konfigurierten URL auf dem Webserver zur Verfügung gestellt werden.

Damit ist die Konfiguration der Offline Root CA abgeschlossen und alle notwendigen Dateien stehen zur Verfügung. Der nächste Schritt wäre die Erstellung einer untergeordneten Online CA (SubCA) die, beispielsweise, im Active-Directory veröffentlicht ist.

WSUS 3.0 Event ID 12052, 12042, 12032, 12022, 12012, 12002

Aus dem nichts tauchten bei mir in der Ereignisanzeige die angegebenen Fehler auf, die aussagten, dass alle Webdienste nicht funktionieren. Nach diversen Recherchen, waren unterschiedliche Lösungsvorschläge. Überprüfen der ASP. Net Berechtigung, Neuinstallation des SelfupdateonPort80 (allerdings fragte ich mich, wass das mit dem Fehler zu tun haben sollte) usw.

Letztendlich habe ich den Fehler auf fehlende Berechtigung von .NET auf das Windows Temp- Verzeichnis eingrenzen können. Dort hatte cih letzte Woche was in Zusammenhang mit Sharepoint verstellt. Nachdem ich zunächst die Gruppe „Jeder“ berechtigt habe, erzeugte der erneute aufruf von „wsusutil.exe checkhealth“ wieder Informationen und keine Fehler. Danach habe ich die Berechtigung weiter eingeschränkt auf die Gruppe „IIS_IUSRS“. Ein erneuter Aufruf blieb weiterhin ohne Fehler.

Datei-Dienste auf WDC2 installiert

Auf dem WDC2 wurde nach folgender Anleitung http://blog.fumus.de/sharepoint/2010/04/dokumente-verwalten-mit-windows-2008-r2-und-sharepoint-2010-teil-1-dokumentenklassifizierung-unter-windows-2008-r2 die Funktion Ressourcenmangeer installiert.

Der Ressourcenmanager kann bereits Dokumente klassifizieren und mit Metadaten versorgen. Somit ist eine spätere Portierung in eine Sharepoint Farm einfacher, da die Metadaten bereits vorhanden sind.

Server-Migration auf 64Bit

Aufgrund der Anforderungen von Exchange und Sharepoint 2010 nach einer homogenen Architektur wird die Serverlandschaft sukzessive auf 64Bit angehoben. Zunächst wurde der SQL-Server neu aufgesetzt, siehe vorherigen Post. Dabei wurde Server 2008 64Bit und SQL Server 2008 64Bit installiert. Bei der Konfiguration muss den SQL-Tools allerdings mitgeteilt werden, dass diese jetzt auf einer 64Bit Plattform laufen.