Archiv der Kategorie: Windows Server 2008 R2

70-659 Windows Server 2008 R2 Server Virtualization

Da ich, aufgrund der freundlichen Unterstützung von ppedv, noch einen Gutschein für die Serverprüfung 70-659 hatte, habe ich diesen heute eingelöst.

Wenn man ein wenig Erfahrung im Bereich Hyper-V und der Verwaltung von Hyper-V mit dem SCVMM 2008 R2 hat, dann ist diese für viele sicherlich kein Hindernis.

Allerdings passten die Fragen zum Remotedesktop Service nicht so recht zu dieser Prüfung. Davon waren einige vorhanden die sich auf die Themen Verbindung, Lizenzierung und Broker bezogen.

Ansonsten bin ich ganz froh, dass ich den Gutschein erfolgreich nutzen konnte und die Prüfung bestanden habe. Wer noch weitere gehende Informationen sucht, sollte sich den folgenden Beitrag anschauen, besser hätte ich es nicht zusammenfassen können: Virtualboy Blog

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.

IIS 7 / 7.5 Hosting mehrere SSL-Seiten auf einer IP

Mit dem Webservern kann man auf Port 80 mehrere Domänen auf einer IP-Adresse, anhand des Hostnamen, hosten. Dies ist allerdings bei HTTPS-Verbindungen schwierig, da der Hostname ja durch das Zertifikat bereits ausgestellt wird und mehrere Hostnamen nicht zusammen mit einem Port und einer IP laufen können.
Es gibt allerdings einen Weg, wie man mehrere SSL-Verbindungen mit einem Webserver und einer IP realisieren kann.

Vorraussetzungen:

  • Ein Wildcard-Zertifikat (*.domain.de)
  • IP-Adresse für das Hosting mehrere Webseiten
  • Min. 2 Webseiten auf Port 80 mit Hostnamen (SSL-Hostname wird nachgetragen)

Um das ganze nun zu realisieren:

  • Eine Commando-Zeile mit administrativen Rechten aufrufen
  • Ins Verzeichnis C:WindowsSystem32inetsrv wechseln
  • Folgendes Kommando eingeben (ersetzen von {Sitename}, {IP} und {Hostheader} mit den gewünschten Werten)
    • appcmd set site /site.name:{SITENAME} /+bindings [protocol='https',bindingInformation='{IP}:443:{HOSTHEADER}']
    • appcmd set site /site.name:IIS Seitenname /+bindings.[protocol=’https‘,bindingInformation=’*:80:www.domain.de‘]
  • Zertifikat im IIS Manager prüfen, kann geändert werden, allerdings kann der Hostheader nicht angepasst werden

Mit diesem wenigen Handgriffen könnt ihr nun mehrere Webseiten, über HTTPS, auf einem Webserver zugänglich machen.

Um eine bestehende SSL-Verbindung zu ändern:

  • appcmd set site /site.name:{SITENAME} /bindings.[protocol='https',bindingInformation='{IP}:443:{HOSTHEADER}'].bindingInformation:{NEWIP}:443:{NEWHOSTHEADER}
  • appcmd set site /site.name:“Default Web Site“ /bindings.[protocol=’https‘,bindingInformation=’10.0.1.100:443:web1.f1nalbyte.de‘].bindingInformation:*:443:web1.f1nalbyte.de

siehe auch: http://www.sslshopper.com/article-ssl-host-headers-in-iis-7.html oder http://toastergremlin.com/?p=308

Installation von Galleryserverpro

Nach einiger Recherche für ein Galleryalternative zu Tinywebgallery bin ich auf Galleryserverpro gestossen. Im Gegensatz zu Tinyweb basiert Galleryserverpro allerdings auf .Net und MS SQLLite / MS SQL Server und benötigt den IIS 6.0/7.0 oder höher als Webserver.

Nach dem ich mir die Demo angeschaut habe, hat mir das ganze einfach besser gefallen, als die bisherige Tinywebgallery. Ausserdem hatte ich mit den bisherigen Bildern von unserem Urlaub immer wieder Probleme. So habe ich mich entschieden heut Galleryserverpro zu installieren. Leider machte der IIS 7.5 ein wenig ärger und lies mich nur mit ein wenig Aufwand ein seperate Serviceaccount für den Application Pool angeben. So musste ich letztendlich den ehemaligen SPS Farmadmin Account verwenden, dieser scheint im System mehr Rechte zu haben. Das werde ichaber noch ändern, habe mir bereits mit „icacls“ ein Auszug der Filesystemrechte gezogen und werde diese in den nächsten Tagen abgleichen.

Nachdem dieses Problem gelöst war, lief die Installation Problemlos. Bei der Insallation bin ich nach der sehr guten Dokumentation vorgegangen und hatte so auch keine Probleme. Nun haben wir eine, meiner Meinung nach, sehr professionelle Gallerie auf unseren Webspace die auch für viele Anwendungen verwendet werden kann.

Noch ein kleines Bild:

www.perupagos.de/mediathek

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.