Windows Server, AD, Exchange und mehr…..

Gerade in der DHCP MMC kann es vorkommen, dass an einem Bereich oder auch am Server selbst verschiedene Symbole auftauchen. Das Nervige daran ist, dass man nur sehr schwer die Bedeutung der Icons ermitteln kann und dann das Orakel befragt werden muss um zu wissen, was diese Icons bedeuten. Microsoft hat die Icons in der Technet allerdings dokumentiert.

Für Windows 2003 kann die Doku unter folgender URL aufgerufen werden:
http://technet.microsoft.com/en-us/library/cc784812(WS.10).aspx

Für Windows Server 2008 R2 findet man die Doku unter folgender URL:
http://technet.microsoft.com/en-us/library/gg722802(WS.10).aspx

Warum Microsoft nicht einfach an die Icons einen Tooltip angehangen hat, bleibt mir ein Rätsel.

 

Die Windows Deployment Services sind eigentlich eine feine Sache. Leider kann man den Zugriff auf das Boot-Image nicht einschränken. Dadurch könnte es passieren, dass ein normaler Benutzer über PXE booten könnte. Wenn man jetzt z.B. als Administrator ein WinPE in WDS integriert hat, mit dem man verschiedene Notfall bzw. Wiederherstellungstools ausführen kann, dann hätte der Benutzer darauf auch Zugriff (siehe “Systemrettung leicht gemacht oder auch DaRT über WDS”). Mit WDS Boardmitteln kann man leider das Booten über WDS nicht mit einem Kennwort absichern. Allerdings hat man die Möglichkeit, ein Linux Bootmenü einzubinden, was mit einem Kennwort geschützt werden kann. Als Erstes muss man sich dafür auf dieser Seite seine Linux-Bootumgebung herunterladen:

http://www.kernel.org/pub/linux/utils/boot/syslinux/

Die aktuelle Version ist momentan “syslinux-4.05.zip”. Dieses ZIP File extrahiert man am Besten gleich in einen temporären Ordner auf dem WDS Server. Danach hält man sich an die folgende Anleitung:

http://www.syslinux.org/wiki/index.php/WDSLINUX

Die Datei “default” im Ordner “pxelinux.cfg” muss allerdings jetzt noch angepasst werden, damit für das Booten über WDS ein Kennwort angefordert  wird. Folgender Part ist zu verändern:

Von:

#—
LABEL wds
MENU LABEL Windows Deployment Services
KERNEL pxeboot.0
#—

Nach:

#— LABEL wds
MENU PASSWD StrengGeheim!!
MENU LABEL Windows Deployment Services
KERNEL pxeboot.0
#—

Nachdem die Datei angepasst wurde, kann man den ersten Test mit WDS durchführen. Der Start sollte dann so aussehen:

 

 

 

 

 

 

 

Nach der Eingabe des hoffentlich korrekten Kennworts kann die entsprechende Windows PE Umgebung gestartet werden:

 

 

 

 

 

 

 

 

Microsoft stellt den Volumenlizenzkunden schon seit einer geraumen Zeit das Microsoft Desktop Optimization Pack – kurz MDOP – kostenlos zur Verfügung. Technet und MSDN Abonnenten können es auch für Evaluierungszwecke bei Microsoft herunterladen und einsetzen. Mich persönlich verwundert es immer wieder, wie unbekannt das MDOP bei den Administratoren ist. Wenn ich MDOP in Projekten oder auch in Schulungen erwähne, dann endet das auf der Gegenseite meistens in Achselzucken. Auch wenn man auf der deutschen Technet Seite danach sucht, braucht man schon eine Weile, um auf Informationen zu stoßen.

Normalerweise sollte aber jeder Administrator die einzelnen Tools, die im MDOP enthalten sind, kennen. Das wahrscheinlich wichtigste Werkzeug für den Administrator ist das “Diagnostics and Recovery Toolset” - kurz DaRT genannt. DaRT ist der direkte Nachfolger des ERD Commanders, der bis 2006 von Winternals vertrieben wurde. Mit dem Wechsel von Mark Russinovich zu Microsoft ist auch der ERD Commander mit zu Microsoft gegangen. Innerhalb von DaRT sind echte Lebensretter enthalten, die es einem Administrator ermöglichen, ein abgestürztes System wiederzubeleben. Bevor man dieses Tool allerdings einsetzen kann, steht aber als Erstes eine Menge Arbeit an. Im ersten Schritt muss man das ISO “en_microsoft_desktop_optimization_pack_2011_r2_x86_x64_dvd_715181.iso” auf der Microsoft Seite herunterladen. Das kann ein Weilchen dauern, da es sich hier um einen 2,2GB Download handelt. Zusätzlich benötigt man noch die Windows Debugging Tools, die man unter folgendem Link herunterladen kann:

Windows Debugging Tools

Leider handelt es sich bei dem Downloadlink um keinen kompletten Installer, sondern die Installationsdateien werden während des Setups aus dem Internet heruntergeladen. Nachdem die Installation fertig ist, kann man auf dem Rechner die Setup Dateien für die Debugging Tools extrahieren. Man findet die Installationsdateien unter “%ProgramFiles\Microsoft SDKs\Windows\v7.1\Redist\Debugging Tools for Windows”. Die Warnung wegen des fehlenden .Net 4.0 Frameworks kann ignoriert werden.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Nachdem die Windows Debugging Tools installiert wurden, kann man DaRT installieren. Das Setup ist unkompliziert und schnell durchgeführt.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Wenn die Voraussetzungen alle installiert wurden, kann jetzt mit der Erstellung des DaRT Recovery Images begonnen werden. Dazu startet man aus dem Startmenü den DaRT Recovery Image Wizard. Um mit diesem Assistenten ein Image zu erstellen, benötigt man zusätzlich ein Windows 7 oder auch Windows Server 2008 R2 Installationsmedium.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Wer möchte, kann im nächsten Schritt die Remoteverbindungen erlauben. Wenn es zu einem Problem auf einen Arbeitsplatz kommt, dann könnte man den Benutzer über PXE booten lassen und sich dann remote mit dem Arbeitsplatz verbinden.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Nachdem das ISO erstellt wurde, kann es mit auf eine DVD gebrannt werden. Aus dem erstellten ISO-File oder auch direkt von der gebrannten DVD kann man sich die “boot.wim” extrahieren. Diese Datei lässt sich ohne weitere Anpassungen auch in einen WDS Server integrieren. Dadurch kann man seinen “Lebensretter” auch sehr bequem über WDS auf einem PXE fähigen Client starten und das lästige Suchen nach der CD / DVD entfällt.

Die Datei “boot.wim” befindet sich im Ordner “sources” auf der erstellten DaRT-DVD. Dieses WIM-File wird einfach als Startabbild über die WDS-MMC eingebunden:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Jetzt können Clients über PXE starten und DaRT kann genutzt werden.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Wer die Klickorgie umgehen möchte, um DaRT direkt beim Booten zu starten, der muss das WIM File noch etwas tunen. Eigentlich ist dabei genau so vorzugehen, wie ich es in diesem Artikel dargestellt habe. Als Erstes muss man das WIM File mit imagex mounten:

imagex /mountrw C:\winre\boot.wim 1 c:\winremount

Nachdem das WIM File im Ordner “winremount” bereitgestellt wurde, navigiert man zu der Datei “C:\winremount\windows\system32\winpeshl.ini”. Diese Datei sollte folgenden Inhalt haben:

[LaunchApps]
%windir%\system32\netstart.exe,-prompt
%SYSTEMDRIVE%\sources\recovery\recenv.exe

Diese Datei muss angepasst werden, um DaRT automatisch zu starten:

[LaunchApps] 
%windir%\system32\netstart.exe,-prompt
%SYSTEMDRIVE%\sources\recovery\tools/msdarttools.exe

Danach muss die Datei gespeichert werden und mit imagex müssen die Änderungen in das WIM File übertragen werden:

imagex /unmount C:\winremount /commit

Danach kann man einfach das alte WIM File mit dem neuen in der WDS Konsole ersetzen:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Wenn jetzt von diesem Image gebootet wird, dann startet DaRT automatisch und kann sofort genutzt werden.

Beim Integrieren von DaRT in WDS sollte man aber bedenken, dass unter Umständen auch ein normaler Benutzer über PXE booten könnte und somit auch Zugriff auf die DaRT-Tools hätte. Um dies zu verhindern, gibt es zwei Möglichkeiten. Die erste Möglichkeit wäre, das Startabbild von DaRT einfach im WDS zu deaktivieren und nur bei Bedarf aktiv zu schalten. Die zweite Möglichkeit ist mit etwas Aufwand verbunden, aber meiner Meinung nach die bessere Variante, da hierbei gleich die komplette WDS Umgebung etwas besser geschützt ist. Um das zu erreichen, muss man auf ein Linux-Bootimage zurückgreifen. Wie das funktioniert, beschreibe ich im nächsten Artikel.

Ab und zu lese ich in den Microsoft Newsgroups Technet Foren, dass Forenteilnehmer Probleme mit der AD-Replikation haben, wenn das Firmennetzwerk nicht vollständig gerouted ist, die einzelnen Standorte voneinander durch Firewalls getrennt sind und die DCs der Zweigstellen ausschließlich mit den DCs der Zentrale replizieren können. Dieses Konstrukt wird auch als “Hub-and-Spoke” Topologie bezeichnet.

 

 

 

 

 

 

 

 

Wie man in der Darstellung sehen kann, verfügt das Netzwerk über vier Standorte. Damit die einzelnen Domänencontroller bei dieser Topologie die Repliaktionsverbindungen korrekt erstellen können, muss man als Erstes die Standorte mit den entsprechenden Subnetzobjekten erstellen.

 

 

 

 

 

Nachdem die Standorte erstellt wurden, müssen die Standortverknüpfungen konfiguriert werden. Durch die vorgegebene Topologie machen sich drei Standortverknüpfungen erforderlich.

• Standort-A <-> Standort-B
• Standort-A <-> Standort-C
• Standort-A <-> Standort-D

Da die Standortverknüpfung “Default-IP-Site-Link” bereits existiert, müssen nur noch zwei weitere Verknüpfungen angelegt werden.

 

 

 

 

 

Die Eigenschaften der einzelnen Verknüpfungen sehen dann so aus:

    

 

 

 

 

 

Durch diese Konfiguration wird dem Active Directory der Pfad vorgegeben, auf denen die Replikation erfolgen kann. Dadurch sollte es eigentlich so sein, dass die Bridgeheadserver der Zweigstellen nur noch Verbindungsobjekte mit dem Bridgeheadserver der Zentrale erstellen und auch nur mit diesem replizieren. Leider wird es bei dieser Konfiguration immer noch zu Fehlern kommen. Nehmen wir einmal an, dass der bzw. die Domänencontroller am Standort-A zu Wartungszwecken heruntergefahren werden. Der ISTG (Intersite Topology Generator) / KCC (Konsistency Knowledge Checker) würde diesen “Ausfall” spätestens nach 15 Minuten erkennen und sofort versuchen, neue Replikationsverbindungen zu anderen Standorten zu erstellen. Wenn am Standort-A keine Domänencontroller mehr verfügbar sind, dann würde z.B. ein ISTG/KCC im Standort-B versuchen, eine Replikationsverbindung mit einem Domänencontroller am Standort-C zu erstellen. Das würde an der Firewall scheitern, da ja eine direkte Kommunikation zwischen den einzelnen Standorten nicht erlaubt ist. Die Ereignisprotokolle der Domänencontroller und auch der Firewalls würden sich jetzt mit roten Einträgen füllen.

Dieser Teilnehmer in den Technet Foren hat offensichtlich genau dieses Problem.

Verantwortlich für diesen Effekt ist ein kleiner Haken in dem Snapin “Standorte und Dienste”, der sehr oft vergessen oder ignoriert wird.

 

 

 

 

 

 

 

Die Einstellung “Brücke zwischen allen Standortverknüpfungen herstellen” hat zur Folge, dass der ISTG/KCC zumindest versucht, zwischen den Standorten Standort-B und Standort-C ein Verbindungsobjekt zwischen zwei Domänencontrollern zu erstellen. Die eigentliche Replikation würde dann an der Firewall scheitern.

Deshalb muss in einer Hub-and-Spoke Topologie dieser Haken zwingend deaktiviert werden! Wenn der Haken deaktiviert ist, dann werden wirklich nur noch die durch die Standortverknüpfungen vorgegebenen Replikationspfade für das Erstellen der Verbindungsobjekte genutzt.

 

Kurz vor Weihnachten hat Microsoft den mobilen Client für Lync veröffentlicht. Der Client kann auf Windows Phone 7, Android und dem Iphone installiert werden. Die Installation der Mobility und Autodiscover Services setzt die Installation von CU4 für Lync voraus.

Lync CU4

Wichtig bei der Installation ist, dass man sich an die Installationsanleitung unter:

LS_Mobility.doc

hält. Wer hier allerdings zu genau ist, wird unter Umständen einen Schiffbruch erleiden. Wenn man Autodiscover nicht einsetzt, wie gerade in meinem Fall, ist man gezwungen die URLs manuell einzutragen. Leider sind die URLs nicht unbedingt benutzerfreundlich. Microsoft empfiehlt auch Autodiscover zu nutzen und das manuelle Konfigurieren nur zu Debuggingzwecken einzusetzen. Zu allem Übel hat sich hier auch noch der Fehlerteufel in der Doku eingeschlichen. Auf der Seite 9 in dem oben verlinkten Dokument steht folgendes:

If you use manual settings instead of automatic discovery, mobile users need to manually enter the following URLs in their mobile device:

• https://<ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root for external access
• https://<IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root for internal access

We strongly recommend using automatic discovery. The primary use of manual settings is for troubleshooting.

Korrekt müssten die URLs so aussehen:

• https://<ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root
• https://<IntPoolFQDN>/AutoDiscover/AutoDiscoverservice.svc/Root

Wer sich bei den URLs vertippt, bekommt leider im HTTP Statusprotokoll keinen Hinweis darauf, das die Ressource nicht gefunden wurde, sondern kassiert einen relativ häßlichen HTTP 500 Fehler.

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
2012-01-09 21:54:24 192.168.2.1 GET /autodiscover/autodiscover.svc/root sipuri=sip:max.mustermann@sipdomain.com&format=xml 4443 – 192.168.2.254 Lync%202010/1.0+CFNetwork/485.13.9+Darwin/11.0.0 500 0 0 6240

Wenn die URLs korrekt in den Lync Client eingetragen wurden, sollte die Verbindung klappen. Wenn Microsoft es jetzt noch schafft, die Unterstützung für VoIP in der nächsten Version zu implementieren, dann bin ich glücklich.