Mit Hyper-V ist es möglich einer Virtual Machine mehrere Prozessoren zuzuweisen. Dies wird auch als “Symmetric Multiprocessing” oder kurz “SMP” bezeichnet. Vom Hypervisor werden in der Version 2008 R2 Konfigurationen mit 1, 2, 3 und 4 Virtuellen Prozessoren unterstützt. Je nach Betriebssystem unterscheidet sich allerdings die Anzahl der Prozessoren, welche durch Microsoft supported wird:

• Windows Server 2008 (R2): 1, 2, oder 4 Virtuelle Prozessoren
• Windows Server 2003 mit Service Pack 2: 1, oder 2 Virtuelle Prozessoren
• Windows 2000 Server mit Service Pack 4: 1 Virtueller Prozessor

Technisch gesehen können natürlich auch Virtual Machines mit mehr als 1, oder 2 Virtuellen Prozessoren konfiguriert werden. Das Betriebssystem wird dies auch entsprechend identifizieren, allerdings wurde diese Konfiguration, zum Beispiel für Windows Server 2003, nicht durch Microsoft getestet und ist daher auch nicht supported. Bei einer Störung muss das Problem zunächst bei einer Virtual Machine mit 2 Prozessoren reproduziert werden können.

(weiterlesen…)

Mit Windows Virtual PC (VPC) und dem neuen Tool Disk2VHD von Sysinternals wurde ein kleiner Hype entfacht, wobei viele Administratoren versucht haben, ihren persönlichen Computer in eine Virtual Machine zu konvertieren. In Zeiten von Hard Disks im Terrabyte Bereich wurde die Euphorie schnell von einer Limitation in Virtual PC gebremts. Denn VPC kann mit Virtual Hard Disks (VHDs) grosser als 127.5 GB nicht umgehen. Der Vorgang eine solches VHD Image in hinzuzufügen wird mit folgender Fehlermeldung abgebrochen:

The virtual hard disk image ‘.\My Virtual Machines\WS2008.vhd’ is too large for the IDE bus. Make sure that all virtual hard disk images connected to the IDE bus are not greater than 127.5 GB.

Für ein Resize eines solchen VHD Image, kann nicht nur die Virtual Hard Disk verkleinert werden. Auch die darauf angelegten Volumes müssen vorgängig auf die neue Grösse angepasst, sprich verkleinert werden.

Resize Volume

Das Volume kann auf einem Host System wie Windows 7, oder Server 2008 R2 sehr einfach verkleinert werden. Dazu muss lediglich ein Command Prompt als Administrator geöffnet und Diskpart ausgeführt werden. Nachdem eine Virtual Hard Disk geladen / attached wurde kann bereits das gewünschte Volume verkleinert werden. Sinnvoll ist es das Volume vor der Konvertierung zu defragmentieren, da ansonsten zu viel verteilter Speicherplatz belegt wird. Im nachfolgenden Beispiel wird ein Volume vom VHD Image “TestW7.vhd” auf 100 GB verkleinert:

DISKPART> list vdisk
DISKPART> select vdisk file=D:\TestW7.vhd
DISKPART> list volume
DISKPART> select volume 4
DISKPART> shrink desired=102400
DISKPART> detach vdisk
DISKPART> exit

Wird bei “shrink” kein spezifischer Wert angegeben (desire=), so wird automatisch der maximal mögliche Wert genommen.

Resize VHD Image

Im nächsten Schritt muss auf das Tool VHD Resizer zurückgegriffen werden. Der VHD Resizer kopiert den Inhalt eines VHD Image blockweise in eine neue Datei. Der Vorteil hierbei ist, dass das Original Image erhalten bleibt und somit keine Daten verloren gehen (sollten). Damit die “Volume ID” nicht verändert wird, muss zwingend eine Kopie auf Blocklevel durchgeführt werden.

Die Handhabung von VHD Resizer ist einfach, nach der Installation muss lediglich das Source und Target VHD Image, sowie die neue Grösse (maximal 127 GB) angegeben werden, damit der Kopiervorgang gestartet werden kann. Ist die Datei allerdings zu diesem Zeitpunkt noch im Zugriff durch eine andere Applikation wie VPC, oder Disk Management, so wird die Meldung “Invalid Disk, please select another” ausgegeben.

Die Konvertierung in das neue VHD Image wird mit “Resize complete, resize another” abgeschlossen. Das Tool schliess sich übrigens automatisch, wenn “no” angewählt wird… Danach kann das neu angelegte Image der entsprechenden Virtual Machine hinzugefügt werden.

Source

Die Source für VHD Resizer kann direkt bei vmToolkit heruntergeladen werden, zum Download… Wichtig! Natürlich gibt es andere Lokationen welche weitere Downloads anbieten, es sollte allerdings nur offizielle Builds und Download Centers aufgesucht werden. Zitat Forrest Gump: “Man weiss nie, was man kriegt.”

• Version: 1.0.42
• Date Published: 2007-01-18
• Language: Englisch
• Format: *.msi
• Publisher: vmToolkit
• License: Freeware

Weitere Informationen

• Server Talk: Sysinternals “Disk2vhd”
• Server Talk: How-To: Resize von VHD Files

Die Installation von Windows mittels USB-Drive ist gerade in der aktuellen Zeit sehr beliebt, da Windows 7 und Windows Server 2008 R2 released wurden. Wie ein solches Device erstellt werden kann, wird im Artikel “How-To: Install Windows Server 2008 R2 von USB-Drive” beschrieben.

Wird nun aber der Bootvorgang mit einem Fehler abgebrochen muss ein USB-Drive / -Stick unter Umständen bootbar gemacht werden. Beim Lenovo Thinkpad X301 oder T500 wird beispielsweise folgende Meldung angezeigt:

Invalid or damaged bootable partition

Für diesen Vorgang wird das Tool “bootsec.exe” aus dem Windows Installationsmedium benötigt. Mit Bootsect.exe wird der Master Boot Code von Festplattenpartitionen für den Wechsel zwischen BOOTMGR und NTLDR aktualisiert. Mithilfe dieses Tools kann der Bootsektor auf einem Computer wiederhergestellt werden. Damit werden die Tools FixFAT und FixNTFS ersetzt.

Um nun diesen Master Boot Code zu schreiben muss mit einem Command Prompt (als Administrator ausführen) in das Verzeichnis \boot gewechselt werden. Mit dem Befehl bootsect /nt60 e: /mbr wird dann der Bootcode geschrieben. In dem gezeigten Beispiel repräsentiert E: das USB-Drive welches bootbar gemacht werden soll. Die Version des Installationsmediums, respektive die Version von bootsec.exe, muss der Architektur des Host Betriebssystem entsprechen. Ansonsten wird folgende Fehlermeldung ausgegeben:

This version of E:\boot\bootsect.exe is not compatible with the version of Windows you’re running. Check your computer’s system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher.

In anderen Worten: Wird dieser Vorgang auf einem Windows 7 64-Bit Edition ausgeführt, muss auch .\boot\bootsec.exe von einem 64-Bit Medium ausgeführt werden. 

Nach erfolgreichem Update wird eine entsprechende Meldung ausgegeben:

D:\ISO\en_windows_7_enterprise_x64\boot>bootsect /nt60 e: /mbr
Target volumes will be updated with BOOTMGR compatible bootcode.

E: (\\?\Volume{df4627d5-2a5c-11de-bcde-806e6f6e6963})
    Successfully updated FAT32 filesystem bootcode.

\??\PhysicalDrive1
    Successfully updated disk bootcode.

Bootcode was successfully updated on all targeted volumes.

Nicht vergessen, vor einer Installation immer fleissig die Daten sichern. Ein dafür geeignetes Tool mit entsprechendem Online Storage ist MozyHome (2.2GB for free). Happy staging…!

Weitere Informationen

• Microsoft TechNet: Bootsect Command-Line Options

Es kann durchaus mal vorkommen, dass sich eine Virtual Machine so aufgehängt hat, dass sich diese nicht mehr mittels Management Console nicht mehr stoppen lässt. In einem solchen Fall kann der einzelne Virtual Machine Worker Prozess (vmwp.exe) abgeschossen werden, damit nicht der ganze Server neu gestartet werden muss.

Als Hilfsmittel dient der Windows Task Manager, oder die erweiterte Form der Sysinternals Process Explorer, ebenfalls aus dem Hause Microsoft.

1. Utility Process Explorer mit “Run as Administrator” starten und die EULA akzeptieren, zuvor natürlich auch lesen.
2. Die Ansicht in der Menu Bar mit “View | Select Columns…” anpassen damit die Spalte “Command line” im Hauptfenster angezeigt wird.
3. Aus der hinzugefügten Spalte kann nun die eindeutige Kennung einer Virtual Machine ausgelesen werden. Der Inhalt wird wie folgt dargestellt: "C:\Windows\System32\vmwp.exe" E314B8Fe-FB75-48B8-914F-E9B2362D9E0B
4. Die Zahlenfolge “E314B8Fe-FB75-48B8-914F-E9B2362D9E0B” definiert in diesem Beispiel die GUID der Virtual Machine namens “MyCrashedVM”.
5. Um den Prozess einer Virtual Machine zuweisen zu können, muss die GUID einer Virtual Machine bekannt sein. Dieser kann beim entsprechenden Verzeichnis ausgelesen werden, der Default Path lautet: C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\
6. Im Sub-Folder “Virtual Machines” existiert jeweils ein XML-Document welches die eindeutige Kennung repräsentiert. In diesem Beispiel mit Cluster Shared Volume (CSV) sieht der Path wie folgt aus: C:\ClusterStorage\Volume1\MyCrashedVM\Virtual Machines\E314B8Fe-FB75-48B8-914F-E9B2362D9E0B.xml
7. Wenn die Virtual Machine GUID dem entsprechende Virtual Machine Worker Prozess zugewiesen werden konnte, kann mit einem Rechtsklick auf den entsprechenden Prozess die Funktion ”Kill process” aufgerufen und der Prozess “abgeschossen” werden.
8. Die Meldung “Are you sure you want to kill vmwp.exe” muss noch mit “Yes” bestätigt werden. Dies beendet die problematische Virtual Machine ohne die anderen Instanzen zu beeinträchtigen.
9. Nun kann die Virtual Machine mit der Hyper-V Management Console wieder gestartet werden.

Der beschriebene Vorgang kann praktisch 1: 1 auch mit dem Windows Task Manager durchgeführt werden. Mit dem Process Explorer werden die Informationen nur besser dargestellt. Wichtig, beide Tools müssen bei aktivem User Account Control (UAC) explizit als Administrator ausgeführt werden.

Ach ja, für alle Hyper-V Kritiker, einen vergleichbaren Artikel gab es auch schon für VMware ESX: How-To: Eine VMware ESX Virtual Machine “abschiessen”…

Wenn man wissen will, was auf einem Windows System läuft, ist man mit “Process Explorer” auf der richtigen Spur. Die Freeware aus dem Hause Microsoft zeigt alle Details der laufenden Prozesse minutiös an. Das Utility liefert zudem eine genaue Aufstellung darüber, welche Files aktuell geladen sind, welche Priorität diese besitzen und welche DLLs mit ausgeführt werden. Eine nettes Troubleshooting-Hilfsmittels um den Plagegeistern auf die Schliche zu kommen.

Das Utility kann zudem alles was der in Windows integrierte Task Manager auch kann. Der Process Explorer ist also sozusagen der grosse Bruder des Windows Task Managers.

About Process Explorer

Ever wondered which program has a particular file or directory open? Now you can find out. Process Explorer shows you information about which handles and DLLs processes have opened or loaded.

The Process Explorer display consists of two sub-windows. The top window always shows a list of the currently active processes, including the names of their owning accounts, whereas the information displayed in the bottom window depends on the mode that Process Explorer is in: if it is in handle mode you’ll see the handles that the process selected in the top window has opened; if Process Explorer is in DLL mode you’ll see the DLLs and memory-mapped files that the process has loaded. Process Explorer also has a powerful search capability that will quickly show you which processes have particular handles opened or DLLs loaded.

The unique capabilities of Process Explorer make it useful for tracking down DLL-version problems or handle leaks, and provide insight into the way Windows and applications work.

Support

Tools von Sysinternals kommen zwar inzwischen von Microsoft, werden allerdings als „as is“ bereitgestellt. Ein Auszug aus den Sysinternals Software License Terms:

5. SUPPORT SERVICES: Because this software is “as is,” we may not provide support services for it.

9. DISCLAIMER OF WARRANTY: The Software is licensed “as is”. You bear the risk of using it. Sysinternals gives no express warranties, guarantees or conditions. You may have additional consumer rights under your local laws which this agreement cannot change. To the extent permitted under your local laws, Sysinternals excluded the implied warranties of merchantability, fitness for a particular purpose and non-infringement.

10. LIMITATION ON AND EXCLUSION OF REMEDIES AND DAMAGES: You can recover from Sysinternals and its suppliers only direct damages up to U.S: $5.00. You cannot recover any other damages, including consequential, lost profits, special, indirect or incidental damages.

Source

Die Source für Process Explorer kann direkt bei Microsoft TechNet heruntergeladen werden, zum Download… Wichtig! Natürlich gibt es andere Lokationen welche weitere Downloads anbieten, es sollte allerdings nur offizielle Builds und Download Centers aufgesucht werden. Zitat Forrest Gump: “Man weiss nie, was man kriegt.”

• Version: 11.33
• Date Published: 2009-02-04
• Language: English
• Format: *.zip
• Publisher: Microsoft (Sysinternals)
• License: Freeware

Das Utility Process Explorer kann übrigens auch direkt via “Live.Sysinternals.com” gestartet werden.

Es gibt einige Möglichkeiten wie Resource Mailboxen konfiguriert werden können. Mit der Delegate Einstellung können Meeting Requests direkt zur Genehmigung an eine Verwaltung, Sekretärin, oder eine andere Stelle weitergeleitet werden. Dabei gilt es allerdings zu beachten, dass in bestimmten Konstellationen diese E-Mails “nicht ankommen”…

Für die Fehlerbehebung sollte zunächst in die Exchange Management Shell gewechselt werden. Mit dem Befehl “Get-MailboxCalendarsetting” kann die aktuelle Konfiguration ausgelesen werden. Nachfolgend ein Auszug einer solchen “Problem Resource”:

ResourceDelegates : {Michel}
RequestOutOfPolicy :
AllRequestOutOfPolicy : True
BookInPolicy :
AllBookInPolicy : False
RequestInPolicy :
AllRequestInPolicy : True

Da die Optionen “AllRequestInPolicy” und “AllRequestOutOfPolicy” auf $true gesetzt sind, wird der Exchange Server dies nicht entsprechend an die Delegates weiterleiten. Wird “AllRequestOutOfPolicy” zurück auf $false gesetzt, werden die Anfragen an die Delegates weitergeleitet, that’s it…

 In Migration wünschen Kunden oftmals, eigentlich meistens die Server- und Domain-Namen 1:1 zu übernehmen. In einen koexistenten Betrieb zwischen Exchange Server 2003 und 2007 kann dies in speziellen Konstellationen zu unangenehmen Effekten führen.

Was passiert, wenn zum Beispiel ein Exchange Edge Transport Server in Betrieb genommen werden soll, welcher mit den Namen MX1.domain.com installiert wurde. Der Namen lässt schnell darauf schliessen, dass dieser Name auch im externen DNS eingetragen wurde. Wenn nun dieser Name auch im Internet Connector des Exchange 2003 Front End Server eingetragen ist, fangen die Probleme an…

Sobald die Edge Transport ihren Betrieb aufnehmen und somit E-Mails auch in die Exchange Server 2003 Umgebung zustellen sollen wird im Exchange Server 2007 Queue Viewer folgende Meldung angezeigt:

554 5.4.4 SMTPSEND.DNS.MxLoopback; DNS records for this domain are configured in a loop

Auch der Sender der E-Mail erhält eine Fehlermeldung. Der Unzustellbar-Bericht vom Postmaster enthält folgende Nachricht:

Für den Empfängerserver wurde keine Route gefunden. Wenden Sie sich an Ihren Systemadministrator.

<domain.com #5.4.4 smtp; 554 5.4.4 SMTPSEND.DNS.MxLoopback; DNS records for this domain are configured in a loop>

Dieses Routing Problem hat den Ursprung bei SMTP Internet Connector des “alten” Front End Servers. Dort wurde im im “Delivery tab | Advanced | Fully-qualified domain name” denselben Domain Name wie beim Edge Transport, MX1.domain.com, eingetragen. Wenn man nun paar Schritte zurückgeht und ein Health Check Report des “Exchange Best Practice Analyzer”  prüft, wird der Administrator unter Umständenen schon früher auf diesen Fehler hingewiesen:

Missing FQDN in service principal name

Weitere Informationen zu dieser Konfiguration findet man im Microsoft KB 914137 . Zurück zum ursprünglichen Problem. Die Lösung des Problems ist relativ einfach. Der Domain Name im Front End Connector muss zwingend angepasst werden. Eine noch bessere Lösung wäre allerdings, wenn dieser entfernt und das Routing vollständig über die Exchange Server 2007 Infrastruktur abgehandelt würde. Dazu wird lediglich der Routing Group Connector benötigt.

Weitere Informationen

• Microsoft Technet: How to Create RGC from Exchange 2007 to Exchange 2003
• Microsoft Technet: Service Principal Name Missing
• Microsoft Exchange Team Blog: SMTP Virtual Server Myths Exposed
• Exchangepedia Blog: Masquerading SMTP Virtual Servers: Changing the fqdn and masquerade domain

Seit Windows Server 2008 wird bei der Installation des Failover Cluster die Hardware und Operating System Konfiguration mit dem “Cluster Validator” auf die Kompatibilität geprüft. Diese Validierung muss erfolgreich durchlaufen, damit die Konfiguration funktioniert und durch Microsoft unterstützt wird:

For the Windows Server 2008 Failover Clustering solution to be considered an officially supported solution by Microsoft Customer Support Services (CSS), the solution must meet the following criteria:

• All hardware and software components must meet the qualifications to receive a “Certified for Windows Server 2008″ logo.
• The fully configured solution must pass the Validate test in the Failover Clusters Management snap-in.

Weitere Informationen dazu erhält man auch im Microsoft KB 943984. Nun kann es aber vorkommen, dass im Cluster Validation Report folgende Fehlermeldung angezeigt wird:

Found duplicate IP address fe80::100:7f:fffe%12 on node ClusterNode1.company.com adapter Local Area Connection* 9 and node ClusterNode2.company.com adapter Local Area Connection

Diese Meldung bezieht sich auf das Teredo Network Interface, in diesem Beispiel „Local Area Connection 9“, wo ein Konflikt mit einer doppelten IP-Adresse besteht. Das Teredo Tunneling Protocol ist eine Methode für den Zugriff auf ein IPv6 Netzwerk, welches sich hinter einem NAT-Device befindet. Mit Teredo werden IPv6-Pakete mit UDP über IPv4 gekapselt werden. Diese Technologie wurde mit Windows Server 2008 / Windows Vista eingeführt…

Nun aber wieder zurück zum Windows Failover Cluster. Ein Problem mit doppelter IP Adresse kann entstehen, wenn die Server von gleichen Images installiert und automatisch der Cluster NetFT Adapter mit derselben MAC Adresse erstellt wurde. Im Validator Report wird dies als Fehler hervorgehoben, da ein Failover Cluster  immer eindeutige IP-Adressen erfordert. Damit die Validation erfolgreich abgeschlossen werden kann, gibt es zwei Möglichkeiten. Zunächst sollte das Feature Failover Cluster entfernt und wieder neu installiert werden. Bringt dies keine Abhilfe besteht die Möglichkeiten den Teredo Adapter zu deaktivieren.

Methode 1) Re-Install Failover Cluster

Wie Roles und Features im Server Manager installiert werden können, sollte soweit jedem klar sein. Ein unter Umständen schnellerer Weg ist über die Command Prompt und ServerManagerCMD. Damit lässt sich ebenfalls der Failover Cluster entfernen und neu installieren:

• Uninstall: ServerManagerCmd -remove Failover-Clustering
• Install: ServerManagerCmd -install Failover-Clustering

Wichtig, Sysprep ist nicht supported, wenn das Failover Cluster Feature bereits installiert wurde. In einem solchen Fall hat der Virtuelle Cluster Adapter (NetFT) bei sämtlichen Nodes die gleiche MAC Adresse. Die NetFT Konfiguration wird bei der Installation des Failover Cluster Feature aufgrund der MAC einer der physikalischen NICs erstellt.

Methode 2) Disable Feature via Command line

Zunächst mit “Run as Administrator” (Windows UAC) einen “Command Prompt” öffnen. Mit den einzelnen Befehlen “netsh interface teredo set state disabled” kann das Teredo Interface deaktiviert werden. Dies sieht dann wie folgt aus:

C:\Windows\System32\ netsh
netsh> interface
netsh interface> teredo
netsh interface teredo> set state disabled
Ok.

Methode 3) Disable Feature via Registry

Mit “Run as Administrator” einen Registry Editor öffnen. Dies kann auch durch einen bereits als Administrator geöffneten Command Prompt und “regedit” gemacht werden.

Key: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
Entry: DisabledComponents
Type: DWORD
Value: 8 (Hexadecimal)

Nach einem Neustart des Servers ist Teredo nicht mehr aktiv.

Methode 4) Disable Device im Device Manager

Wurde das Feature deaktiviert und die Validation schlägt noch immer fehl, kann das Interface auch noch im Device Manager deaktiviert werden. Dazu muss der Device Manager (Server Manager | Diagnostics | Device Manager) geöffnet werden. Mittels “View | Show hidden devices” wird das “Teredo Tunneling Pseudo-Interface” bei den Network Adapters angezeigt. Dieses Interface kann nun deaktiviert werden. Allerdings, deaktiviert diese Vorgehensweise nicht die dazugehörige Logik und kann daher zu einem späteren Zeitpunkt zu Problemen führen. Die Variante mittels Command Line oder Registry sollte daher zuvor ausgeführt werden.

Methode 5) Disable IPv6

Last but not least eine weitere Lösung… Da das Problem den Ursprung bei IPv6 hat, kann IPv6 mittels Registry Key auch komplett sauber deaktiviert werden.

Key: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
Entry: DisabledComponents
Type: DWORD
Value: 0xffffffff (Hexadecimal) / 4294967295 (Decimal)

Diese Einstellung deaktiviert sämtliche IPv6 Komponenten, ausgenommen das “IPv6 Loopback Interface”. Im HOST File sollte die Zeile “::1 localhost” ausgeklammert, oder entfernt werden. Optional kann nun auch noch das “Internet Protocol Version 6 (TCP/IPv6)” in den Connection Properties des Network and Sharing Center abgewählt werden.

Allerdings ist dies kein von Microsoft empfohlener Weg. IPv6 sollte nur im „Notfall“ deaktiviert werden. Bei sämtlichen Anpassung kann / muss “Validate a Configuration” nach einem Server Reboot erneut ausgeführt werden. Der Fehler “Found duplicate IP address” sollte nun allerdings nicht mehr auftreten und der Failover Cluster kann installiert werden. 

Weitere Informationen

• Microsoft TechNet: Internet Protocol Version 6, Teredo, and Related Technologies in Windows Vista
• Microsoft Windows Server Core Blog: What is a Microsoft Failover Cluster Virtual Adapter anyway?
• Server Talk: Exchange Server 2007 Installations Fehler

Disclaimer

Bevor die Registry bearbeitet wird, sollte ein Backup erstellt und vergewissert werden, dass bei einem Problem ein Restore der Registry durchgeführt werden kann. Die unkorrekte Verwendung eines Registry-Editor kann schwerwiegende Probleme verursachen, die eine Neuinstallation des Betriebssystems erforderlich macht. Die Anpassung erfolgt auf eigene Verantwortung.

• Microsoft KB 141377: Differences between Regedit.exe and Regedt32.exe
• Microsoft KB 322756: How to back up and restore the registry in Windows

Wer mit Exchange Server 2007 bereits einen Cluster Mailbox Server (CMS) installiert hat, ist sicherlich schon über folgende Fehlermeldung gestossen:

Warning:
The server administrator ‘intra.server-talk.eu/ST/Computers/Servers/EXCCMS12′ is not a member of the Exchange View-Only Administrators.

Dieser Fehler erscheint jeweils beim passiven Node. Die Fehlermeldung erscheint, wenn in der Exchange Management Console die Organization Configuration geöffnet wird, oder wenn mit PowerShell eine Abfrage “Get-ExchangeAdministrator” ausgeführt wird.

Gemäss Microsoft ist dieser Effekt ”by Design” und kann auch ohne weiteres ignoriert werden, da der passive Node die Berechtigung “Exchange View-Only Administrator” zu diesem Zeitpunkt nicht benötigt. Wenn die Fehlermeldung aber zukünftig nicht mehr erscheinen soll, schliesslich sind Fehler da um sie zu beheben, müssen die Computer Accounts der Nodes des Clustered Mailbox Server nur in die Active Directory Gruppe “Exchange View-Only Administrators” aufgenommen werden.

Weitere Informationen

• Microsoft Technet: Configuring Permissions

Bei Windows Server 2008 ist IPv6 per Default auf sämtlichen Network Interface Cards (NICs) aktiviert. Wird jedoch “Internet Protocol Version 6 (TCP/IPv6)” im “Network and Sharing Center” deaktiviert, endet die Installation von Exchange Server 2007 mit folgendem Fehler:

Service ‘MSExchangeAntispamUpdate’ failed to reach status ‘Running’ on this server.

Im Event Viewer wird zudem folgende Meldung geloggt:

Log Name: Application
Source: MSExchangeSetup
Event ID: 1002
Task Category: Microsoft Exchange Setup
Level: Error
Description: Exchange Server component Hub Transport Role failed.
Error: Service ‘MSExchangeAntispamUpdate’ failed to reach  status ‘Running’ on this server. Cannot start service MSExchangeAntispamUpdate on computer ‘.’. The service did not respond to the start or control request in a timely fashion

Viele Exchange Komponenten erfordern IPv6. Der Fehler bei der Exchange Server 2007 Installation kommt daher, da das IPv6 Protokoll auf dem Local Area Connection Adapter entfernt wurde. Die von Microsoft empfohlene Variante ist das neue Protokoll aktiviert zu lassen.

Sollte dies nicht gehen, kann die Deaktivierung von IPv6 nur mittel Registry Key vorgenommen werden:

Key: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
Entry: DisabledComponents
Type: DWORD
Value: 0xffffffff (Hexadecimal) / 4294967295 (Decimal)

Diese Einstellung deaktiviert sämtliche IPv6 Komponenten, ausgenommen das “IPv6 Loopback Interface”. Nach einem Neustart des Servers kann die Installation nochmals vorgenommen werden, in diesem Fall wird der Status “The Microsoft Exchange Server setup operation completed successfully” ausgegeben.

Optional kann nun auch noch das “Internet Protocol Version 6 (TCP/IPv6) in den Connection Properties des Network and Sharing Center abgewählt und im HOST File den Wert “::1 localhost” entfernt werden. Wie zuvor erwähnt, IPv6 sollte nur im “Notfall” deaktiviert werden.

Weitere Informationen

• Microsoft KB 952842:  The installation of the Exchange Server 2007 HT role may be unsuccessful
• Microsoft TechNet: IPv6 for Microsoft Windows FAQ
• Microsoft TechNet: IPv6 Support in Exchange 2007 SP1
• MSExchangeFAQ: IPv6