Ich bin seit Jahren ein großer Backtrack Linux Fan. Dieses Live Linux bietet einfach alles was man braucht um Systeme und Netze auf ihre Sicherheit zu prüfen. Bis jetzt war es recht umständlich eine Installation auf einen USB Stick vorzunehmen (siehe mein alter Beitrag dazu) insbesondere wenn man seine Änderungen am System beibehalten wollte. Mit der aktuellen Version 5 kann man jedoch auch UNetbootin verwenden um die Installation mit wenigen Klicks durchzuführen. Für einzelne Distributionen kann man sogar den Download direkt über das Tool vornehmen.

Nachdem ich auf meinem Testlab SBS 2011 nun auch mal etwas mit Sharepoint spielen wollte habe ich festgestellt, dass dieser dort nicht wirklich online ist. Beim Aufruf der Companyweb-Seite wurde ich dort nur von einer 503er Meldung begrüßt. Das Fehlerbild (insbesondere auch das Logfile) gab dabei keine so richtigen Hinweise darauf was das Problem ist. Der Microsoft Windows Server Solutions Best Practices Analyzer sagte mir auch, dass alles in Ordnung sei und der SharePoint 2010 Products Configuration Manager lief auch ohne jeden Fehler durch.

Nach etwas suchen bin ich dann auch mal in den Internet Information Services (IIS) Manager gegangen. In der Anzeige des Application Pools ist mir dabei aufgefallen, dass sowohl der “SharePoint Central Administration v4” Eintrag wie auch der “SharePoint Web Services Root” auf “Stop” steht. Ein kurzer Klick auf “Start” führte dazu, dass das gesamte Fehlerbild verschwand und alles so funktioniert wie es das soll.

Ich habe ehrlich gesagt keine Ahnung warum diese beiden Applications ausgeschaltet waren – ich kann mir nur vorstellen, dass das auch im Rahmen der Installation des SP1 des SharePoints geschehen ist.

Um die Remotewebseite des SBS 2011 und insbesondere den Outlook Web Access (OWA) bzw. den Remote Zugang via TS-Web-Gateway richtig nutzen zu können braucht man ein vertrauenswürdiges Zertifikat.  Um dieses zu erhalten kann man sich natürlich der Dienste einer bekannten öffentlichen CA bedienen. Abhängig von den Zertifikaten die man braucht kann das aber recht teuer werden. Insbesondere bei Zertifikaten mit mehreren Domains (subject alternate domains) kostet das gleich mehrere hundert Euro. Für Testsysteme aber auch für Unternehmen die sicherstellen können, dass alle zugreifenden Systeme dem eigenen Zertifikat vertrauen kann man sich ein Zertifikat mit mehreren Domains auch selbst erstellen.

Manche fragen sich nun vielleicht warum ich ständig diese Zertifikate mit mehreren Domains erwähne. Die Begründung ist recht simpel – weil es viele brauchen (ohne es zu wissen). Nahezu jedes Exchange System das ich kenne ist autoritär für mehr als eine Domain und oft werden auch mehrere (unterschiedliche) als Sendeadressen verwendet. Damit ist es notwendig, dass der Exchange Server auch ein gültiges Zertifikat für die alternativen Domains besitzt. Essentiell wird es wenn man z. B. ein Active Sync Gerät verwendet um die Mails eines Kontos abzurufen welches nicht durch die primäre Domain abgedeckt ist.

So nun aber zu den notwendigen Schritten am Beispiel eines SBS 2011 (Enterprise CA):

Zuerst erstellt man sich eine Textdatei mit folgendem Inhalt – wobei das Subject und die DNS Namen unter SAN natürlich anzupassen sind – weitere Details zu Folgeoptionen findet man ggf. auch hier: http://support.microsoft.com/kb/931351

Die soeben erstellte Datei wird in meinem Fall in request.inf (das .inf ist wichtig!) umbenannt.

certreq -new request.inf certnew.req

certreq -submit certnew.req certnew.cer

certreq -accept certnew.cer

Nachdem das Zertifikat erstellt wurde muss es noch installiert werden: