Windows Server, AD, Exchange und mehr.....

Was will mir der DHCP Server sagen?

Frank Röder — Thu, 19 Jan 2012 14:07:06 +0000

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.

Absichern von WDS über Linux Bootimage

Frank Röder — Wed, 18 Jan 2012 08:47:19 +0000

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:

Systemrettung leicht gemacht oder auch DaRT über WDS

Frank Röder — Sun, 15 Jan 2012 19:59:37 +0000

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.

Standortübergreifende Active Directory Replikation und Firewalls

Frank Röder — Tue, 10 Jan 2012 19:59:15 +0000

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.

Fehler in der Doku zu Lync Mobile und HTTP 500

Frank Röder — Tue, 10 Jan 2012 00:17:30 +0000

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:///Autodiscover/autodiscoverservice.svc/Root for external access
~~https:///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:

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.

Clustern des RD Connection Brokers

Frank Röder — Sun, 08 Jan 2012 13:51:48 +0000

Wenn die Anzahl der Terminalserverbenutzer in einem Netzwerk eine bestimmte Größe erreicht, macht es Sinn, über eine Terminalserverfarm nachzudenken. Dadurch kann man die Remote Desktop Session Hosts zum Einen hochverfügbar gestalten und zum Anderen auch eine Lastverteilung erreichen. Allerdings steht man dann sofort vor neuen Herausforderungen. Wenn die Terminalserversitzung eines Benutzers z.B. durch den Verlust der Internetverbindung getrennt wird, dann soll der Benutzer bei einem erneuten Verbindungsversuch mit seiner alten Sitzung verbunden werden.

Durch die Farm könnte es aber theoretisch passieren, dass ein Benutzer nicht mit dem Terminalserver verbunden wird, mit dem er ursprünglich verbunden war. Um das zu vermeiden, muss man einen Remote Desktop Session Broker einsetzen. Der Session Broker verfügt über eine Datenbank (tsesdir.edb), in der alle Benutzersitzungen innerhalb der Farm registriert sind. Wenn ein Benutzer eine Verbindung mit der Farm herzustellen versucht, dann fragt der Terminalserver, mit dem die initiale Verbindung hergestellt wird, den Session Broker ab. Der Session Broker gleicht anhand des Benutzernamens ab, ob der Benutzer auf einem Terminalserver der Farm bereits eine bestehende Sitzung hat. Wenn das der Fall ist, dann wird die Verbindungsanforderung des Benutzers an den entsprechenden Terminalserver in der Farm umgeleitet. Wenn der Session Broker ausfällt, dann funktioniert dieser Mechanismus nicht mehr und es könnte vorkommen, dass Benutzer, die sich zu ihrer getrennten Sitzung wieder verbinden wollen, einfach eine neue Sitzung auf einem völlig anderen Terminalserver innerhalb der Farm bekommen. Deshalb könnte man das Clustern des Session Broker Dienstes in Betracht ziehen. Das Clustern dieses Dienstes war bis Windows Server 2008 nicht möglich bzw. wurde durch Microsoft nicht supported. Ab Windows Server 2008 R2 kann man diesen Dienst innerhalb eines Windows Failoverclusters als Anwendung ausführen, der die notwendige Redundanz für diesen wichtigen Dienst zur Verfügung stellen kann.

Um das Clustern des Remote Desktop Session Brokers zu demonstrieren, habe ich eine kleine Testumgebung aufgebaut. Diese besteht aus den folgenden Rechnern:

Ein Domänencontroller DC1 (Windows Server 2008 R2 Enterprise)
Zwei Clusterknoten (CLU1 und CLU2) (Windows Server 2008 R2 Enterprise)
Zwei Terminalservern (TSNLB1 und TSNLB2) (Windows Server 2008 R2 Enterprise)

Aufbau der Testumgebung

Der Failovercluster verfügt über keine gesharten Datenträger. Diese sind für das Clustern des Remote Desktop Session Brokers auch nicht notwendig. Jeder der beiden Clusterknoten verfügt über seine eigene “tsesdir.edb”. Als Quorummodell habe ich in diesem Fall “Node and File Share Majority” ausgewählt. Nach dem der Cluster konfiguriert ist, kann man sich an die Installation des Remote Desktop Session Brokers auf den beiden Clusterknoten durchführen.

Nach der erfolgreichen Installation des Session Brokers, kann man diesen als Anwendung über die Failover Clusterverwaltung installieren.

Nachdem die Installation durchgeführt wurde, müssen beide Terminalserver in die lokale Benutzergruppe “Sitzungsbrokercomputer” auf BEIDEN Clusterknoten hinzugefügt werden.

Jetzt geht es an die Konfiguration der beiden Terminalserver. Der Lastenausgleich für die beiden Terminalserver wird über DNS Round Robin realisiert. Für die Terminalserverfarm gibt es einen A-Eintrag “tsfarm.spielwiese.intern”, der auf die IP Adressen 192.168.2.30 und 192.168.2.31 zeigt. Der FQDN “tsfarm.spielwiese.intern” wird von den Clients genutzt, um sich mit der Terminalserverfarm zu verbinden.

Zusätzlich müssen auf BEIDEN Terminalservern noch die Einstellungen für die Farm bzw. für den Session Broker konfiguriert werden. Wenn es sich um mehr als zwei Terminalserver handelt, dann könnte man diese Einstellungen auch über eine Gruppenrichtlinie konfigurieren.

Farmname: tsfarm
Remotedesktop-Verbindungsbroker: rdcp.spielwiese.intern
Priorität: 100 (dadurch werden die Clients auf beide Remote Desktop Session Hosts verteilt)

Wenn diese Einstellungen vorgenommen wurden, werden die Clientsitzungen ab sofort auf die beiden Terminalserver gleichmäßig verteilt. Wenn ein Benutzer seine Sitzung trennt und sich anschließend wieder verbindet, dann wird der Benutzer wieder automatisch mit seiner getrennten Sitzung verbunden.

Was passiert nun, wenn der Cluster einen Failover durchführt und dadurch der Remote Desktop Session Broker auf dem anderen Knoten ausgeführt wird? Wenn das geschieht, dann verfügt der Clusterknoten, der die Rolle des Remote Desktop Session Brokers jetzt ausführt, über keine Informationen zu den einzelnen Sitzungen auf Remote Desktop Session Hosts. Der aktuelle Remote Desktop Session Broker kontaktiert die einzelnen Server in der Farm und liest deren Sitzungsliste ein. Dadurch verfügt er über eine aktuelle Liste der Sitzungen und kann seine Arbeit aufnehmen. Dieser Vorgang dauert zwei bis drei Minuten. Während dieser Zeit kann es passieren, das getrennte Sitzungen nicht mehr korrekt verbunden werden und Benutzer, die sich wieder verbinden wollen, einfach eine neue Sitzung innerhalb der Farm bekommen. Den Ablauf der Kommunikation zwischen dem Remote Desktop Session Broker und dem Remote Desktop Session Host kann man in diesem Netzwerktrace schön sehen:

Failover des Clusters

Der Server “tsnlb1.spielwiese.intern (192.168.2.30)” versucht den Remote Desktop Connection Broker “rdcb.spielwiese.intern (192.168.2.40) zu erreichen und stellt fest, dass die TCP Sitzung nicht mehr existiert. Er versucht jetzt mehrmals einen TCP-Retransmit.

Da diese Versuche erfolglos sind, schickt der Server “tsnlb1.spielwiese.intern (192.168.2.30)” einen TCP Reset (Frame 75) und versucht dann einen erneuten TCP Threeway Handshake der von dem Server “rdcp.spielwiese.intern (192.168.2.40)” auch beantwortet wird (Frame 76 – 78).

Nachdem die TCP Sitzung eingerichtet wurde, beginnt die eigentlich RPC Kommunikation zwischen dem Remote Deskop Session Host und dem Connection Broker (Frame 79 – 111) . Ab dem Frame 115 werden zwischen den beiden Peers nur noch TCP KeepAlive Pakete ausgetauscht. Das lässt darauf schließen, dass die Kommunikation beendet ist und alle Daten zwischen den beiden Servern ausgetauscht wurden.

Wenn man sich den Netzwerktrace etwas genauer ansieht, dann stellt man fest, dass es in meiner Testumgebung etwa zwei Minuten gedauert hat, bis nach dem eingeleiteten Failover die Sitzungsdatenbank des Remote Desktop Connection Brokers aktualisiert war. Dieser Umstand ist eigentlich nicht weiter dramatisch, da bestehende Remote Desktop Sitzungen natürlich weiter bestehen bleiben. Wenn natürlich in diesem Zeitraum ein Benutzer sich mit seiner bestehenden Remote Desktop Sitzung innerhalb der Farm verbinden möchte, dann schlägt das fehl und er bekommt eine neue Sitzung auf einem beliebigen Terminalserver eingerichtet. Nach den zwei Minuten sollte alles wieder wie gewohnt ablaufen.

WinPE bzw. WinRE mit statischer IP

Frank Röder — Fri, 06 Jan 2012 21:36:24 +0000

Das Windows Recovery Environment ist für die erste Notfallbehandlung oder auch für das Ausführen einer Wiederherstellung eine feine Sache. Noch schöner ist es, dass man WinRE auch über einen WDS Server starten kann. Dadurch entfällt das lästige Suchen nach eine DVD, die man im Notfall meistens sowieso nicht zur Hand hat.
In einem Kurs, den ich vor den Feiertagen gehalten habe, kam die Frage auf, ob es möglich wäre, WinRE beizubringen, mit einer statischen IP-Adresse zu arbeiten. Der Teilnehmer hat in seinem Netzwerk mehrere Netze, die jeweils durch Firewalls getrennt sind. Das produktive Netz ist dort von dem Datensicherungsnetz durch einen Firewall getrennt. In der Firewall gibt es eine Regel, die nur bestimmten IP-Adressen den Zugriff aus dem produktiven Netz in das Datensicherungsnetz erlaubt.

Als Erstes muss man sich entweder ein WIM File mit dem Windows Recover Environment erstellen oder man “klaut” sich das WIM File von einer bestehenden Installation. Wer den langen Weg gehen möchte, der kann sich nach dieser Anleitung ein WIM File erstellen:

Dieses WIM File kopiert man an einen temporären Speicherort. In meiner Testumgebung wurde ein Ordner “WinRE” direkt auf dem Laufwerk “C:\” erstellt. In diesem Ordner wird die Datei abgelegt.

Nachdem die Datei kopiert wurde, kann man sie mit “imagex” mounten. Damit das Tool imagex verfügbar ist, muss man das WAIK installieren. Das Setup findet man hier:

Windows® Automated Installation Kit (AIK) für Windows® 7

Zusätzlich zu dem Ordner “WinRE” benötigt man noch einen leeren Ordner, in dem das WIM File gemounted wird. Dafür wurde in der Testumgebung ein Ordner “WinREMount” erstellt. Mit folgendem Kommando wird das WIM-File in diesen Ordner gemounted:

imagex /mountrw C:\WinRE\WinRE.wim 1 C:\WinREMount

Nachdem das Image erfolgreich gemounted wurde, kann man über den Windows Explorer bequem die Ordnerstruktur von WinRE durchsuchen. In diesem speziellen Fall ist das Anpassen der Datei “winpeshl.ini” im Verzeichnis “C:WinREMount\Windows\System32″ notwendig. Im Orginal hat diese Datei folgenden Inhalt:

[LaunchApp]
AppPath=X:\sources\recovery\recenv.exe

Mit der Hilfe dieser Datei kann man weitere Applikationen automatisch starten. Allerdings gibt es dort ein paar Stolperfallen zu beachten. Im gleichen Verzeichnis gibt es noch eine weitere Datei “startnet.cmd”, die für das Starten des Netzwerkes bzw. für die Hardwareerkennung von WinRE zuständig ist. Diese befindet sich ebenfalls im Ordner “System32″. Diese Datei kann man nutzen, um über “netsh” eine IP-Adresse für die erkannte Netzwerkkarte zu konfigurieren und das komplette Skript dann über einen Eintrag in der “winpeshl.ini” zu starten. Also wird als Erstes die Datei “startnet.cmd” angepasst:

wpeinit
netsh interface ipv4 set address “LAN-Verbindung” static 192.168.2.3 255.255.255.0 192.168.2.1

Wenn man jetzt dem Technet Artikel “Einschließen eines benutzerdefinierten Skripts in ein Windows PE-Abbild” folgt, dann könnte man z.B die Datei “winpeshl.ini” folgendermaßen ergänzen, um die Datei “startnet.cmd” während des Starts von WinRE mit auszuführen:

[LaunchApp]
AppPath=X:\sources\recovery\recenv.exe
[LaunchApps]
X:\Windows\System32\startnet.cmd

Allerdings funktioniert das leider nicht. Scheinbar kann man innerhalb der Datei “winpeshl.ini” entweder die Sektion “[LaunchApp]” oder “[LaunchApps]” einsetzen. Wenn man das oben angeführte Beispiel einsetzt, dann wird die Sektion “[LaunchApps]” einfach ignoriert. Deshalb hier die korrigierte Version:

[LaunchApps]
X:\Windows\System32\startnet.cmd
X:\sources\recovery\recenv.exe

Danach speichert man die Datei “winpeshl.ini” einfach wieder ab (ACHTUNG: Diese Datei ist schreibgeschützt!). Danach schließt man alle Anwendungen, die auf das Verzeichnis “C:\WinRE” zugreifen (Notepad, Windows Explorer u.s.w.). Anschließend werden mit folgendem Kommando die Änderungen in das WIM-File übernommen:

imagex /unmount C:\WinREMount /commit

Jetzt muss das WIM-File als neues Startabbild in die Windows Bereitstellungsdienste integriert werden.

Wenn das WIM-File auf den Bereitstellungsdiensten erfolgreich integriert wurde, kann jetzt über die Windows Bereitstellungsdienste darüber gestartet werden.

Nach dem Start von WinRE über WDS wird dann sofort das Netzwerk konfiguriert und die statische IP-Adresse wird genutzt.

UDP Benachrichtigungen für Outlook 2003 unter Exchange 2010

Frank Röder — Sat, 29 Jan 2011 11:55:28 +0000

Outlook 2003 wird von Exchange 2010 offiziell unterstützt. Leider gibt es aber doch ein paar Probleme, die den Spaßfaktor beim Arbeiten vermissen lassen. Den größten Ärger gab es für den Dienstleister immer, wenn neue Mails nicht sofort von Outlook 2003 Posteingang erschienen aber auf dem Pocket PC, Iphone oder BlackBerry schon da waren. Dieses Problem ist der Tatsache geschuldet, dass Microsoft unter Exchange 2010 die UDP Notifications für Outlook 2003 entfernt hat. Linderung verspricht dieser KB Artikel.

Allerdings ist das nur Kosmetik und veranlasst jeden Outlook 2003 Client wesentlich öfter den Exchange 2010 zu kontaktieren. Dadurch wird das Serversystem natürlich wesentlich mehr belastet.

Scheinbar hat die hohe Anzahl von Supportfällen Microsoft dazu veranlasst, den UDP Notification Support wieder zu Exchange 2010 hinzuzufügen. Im März 2010 soll es endlich mit RU3 so weit sein.

Artikel MS-Exchange Team

PassAlert

Frank Röder — Tue, 18 Jan 2011 18:52:50 +0000

Jeder Admin kennt das Problem. Da will man etwas für die Sicherheit seines Netzwerkes tun und legt fest, dass die Benutzerkennwörter nach xTagen ablaufen. Was erntet der arme Admin dafür………nur Ärger und Stress. Eine beliebte Ausrede für deaktivierte Konten ist dann meist, dass der User ja nicht ordentlich benachrichtigt wurde. Das kleine graue Fenster von Windows, was einen ja auf das Ablaufen des Kennwortes hinweist, wird eben zu gern ignoriert. Allerdings gibt es auch arme Benutzer, die es vielleicht wirklich nicht mitbekommen, dass ihr Kennwort bald ablaufen wird. Das sind zum Beispiel VPN Benutzer oder auch Benutzer die über POP3 oder auch IMAP auf ein Exchange Postfach zugreifen. Genau an dieser Stelle setzt das Tool PassAlert an. Dieses Tool scannt das Active Directory nach Benutzerkonten ab, deren Kennwörter recht bald ablaufen (der Zeitraum ist frei konfigurierbar). Diesen Nutzern stellt das Tool eine Mail zu, um sie darüber zu informieren. Der Inhalt der Mail kann vom Administrator frei erstellt werden. Somit kann kein Nutzer mehr sagen, er wäre nicht über den Ablauf seines Kennworts informiert worden.

Weitere Informationen findet Ihr unter der Webseite http://www.mcseboard.de/active-directory-forum-79/passalert-betaphase-145443.html

ACHTUNG: Das gute Stück ist noch Beta. Ich habe es eigentlich lang genug getestet und es läuft stabil. Trotzdem kann ich natürlich für die korrekte Funktion des Tools nicht garantieren.

PassAlert kann man hier herunterladen. Passalert (470)

Über Feedback und Bugmeldungen würde ich mich natürlich sehr freuen.

Real World Scenarios

Frank Röder — Tue, 18 Jan 2011 18:38:21 +0000

Sehr oft kommt es in den Newsgroups vor, dass Teilnehmer nach Best Practise Lösungen fragen. Da kommt zum Beispiel die Frage wie in folgendem Forenbeitrag. Diese Fragen werden meist von mehreren Teilnehmern beantwortet und der Fragende hat dann mehrere Unterschiedliche Meinungen und ist genau so klug wie zuvor.

Microsoft hat jetzt gerade für Exchange 2010 ein paar geteste Szenarios veröffentlicht, die dem einen oder anderen Forenteilnehmer die Frage nach dem Exchange Sizing beantworten.

Link zu den Beiträgen

Viel Spaß beim Lesen wünscht,

Frank