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  Operating Systems 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

Das Exchange Server Development Team hat mit “testexchangeconnectivity.com” eine Webpage online gestellt, worüber Exchange Verantwortliche ihren Server vom Internet aus testen können. Mit dem “Remote Connectivity Analyzer” stehen aktuell folgende Tests zur Verfügung:

• Microsoft Office Outlook 2007 Autodiscover Connectivity Test
  This test will walk through the steps Microsoft Office Outlook 2007 uses to connect to Autodiscover
• Microsoft Office Outlook 2003 RPC/HTTP Connectivity Test
  This test will walk through the steps Microsoft Office Outlook 2003 uses to connect via RPC/HTTP
• Microsoft Exchange ActiveSync Autodiscover Test
  This test will walk through the steps a Windows Mobile 6.1 device (or another AirSync licensed device) uses to connect to the Autodiscover Service
• Microsoft Exchange ActiveSync Test
  This test will simulate the steps a mobile device uses to connect to an Exchange Server using Exchange ActiveSync.
• Inbound SMTP Email Test
  This test will walk through the steps an Internet e-mail server uses to send inbound SMTP email to your domain

Der Link ist sehr zu empfehlen. Die Verwendung ist gratis, aber…

This tool can be used for testing purposes or entertainment value and is not supported by Microsoft Product Support in any way.

Wenn ein System keine E-Mails mehr empfängt, ist ein ganzer Betrieb gefährdet. Ein Hilfreiches Tool zum Erstellen einer Diagnose sind die “Mail flow tools”, speziell der “Mail Flow troubleshooter” von Exchange Server 2007. Altbewährt ist auch die Variante mittels Telnet. Bei Windows Vista, oder Server 2008 muss dazu allerdings zuerst das Tool nachinstalliert werden, dazu in diesem Artikel mehr.

Damit überhaupt eine Telnet Session mit dem Mail-Server aufgebaut werden kann, muss dessen Namen bekannt sein. Mit “nslookup -type=MX MyDomain.ch” können die eingetragenen Mail-Server der jeweiligen Domain herausgefunden werden. Ein E-Mail wird mit folgenden Befehlen versendet:

1. Eine Verbindung mit dem Mail-Server wird mit dem Befehl “telnet Server.MyDomain.ch 25” aufgebaut. Ist der Verbindungsaufbau erfolgreich, meldet sich ein Exchange Server 2007 wie folgt: 220 Server.MyDomain.ch Microsoft ESMTP MAIL Service ready at Mon, 8 Sep 2008 20:56:10 +0200
2. Die Anmeldung des Client wird mit “HELO MyDomain.ch” vorgenommen. Der Server antwortet in diesem Fall mit “Hello [172.25.1.104]“.
3. Um eine E-Mail zu versenden müssen die Parameter From, To und Data eingegeben werden.
   • “MAIL FROM: test@TestDomain.ch“. Bei korrekter Eingabe wird dies mit “250 2.1.0 Sender OK” bestätigt.
   • RCPT TO: MyAccount@MyDomain.ch“. Bei korrekter Eingabe wird dies mit ”250 2.1.5 Recipient OK” bestätigt.
   • Um eine Nachricht zu verfassen muss “DATA“, gefolgt von dem eigentlichen Text eingegeben werden.
   • Mit “.” wird die Nachricht zur Übermittlung freigegeben. Dies wird mit “250 2.6.0 <76e59330-2b45-405e-aa41-0e2b9d553cf9@Server.MyDomain.ch> Queued mail for delivery” bestätigt.
4. Mit “quit” wird die Verbindung beendet. Der Server verabschiedet sich mit “221 2.0.0 Service closing transmission channel“.

Wem dies zu kompliziert ist, kann auch auf das Tool SMTP Diagnostics zurückgreifen.

Weitere Informationen

• Microsoft KB 153119: Telnet to Port 25 to Test SMTP Communication

Wer eine Lotus Domino 8 Infrastruktur mit Backup Exec sichern will, muss die aktuelle Version 12 einsetzen. Bei einigen Installation konnte festgestellt werden, dass nach wenigen Minuten der Backup Job in einem Error endet:

Final error: 0xe000fe30 – A communications failure has occurred.

Im Event Viewer werden zudem folgende Meldungen geloggt:

Event Type: Error
Event Source: Application Error
Event Category: (100)
Event ID: 1000
Description: Faulting application beremote.exe, version 12.0.1364.122, faulting module bedsnote.dll, version 12.0.1364.122, fault address 0×00022040

Event Type: Error
Event Source: Backup Exec
Event Category: None
Event ID: 65215
Description: The connectio to the Lotus Domino server has been lost. The following error was reported: Notes Agent:CLNFileSystem::AtachToDLE – Access Violation Exception Caught. The job that was running on this server has been stopped.

Der Fehler bezieht sich auf ein Timeout Problem. Um dies zu lösen muss der “Wait Before Timeout” Wert erhöht werden, um der Domino Database mehr Zeit für die Bearbeitung der offenen Requests geben.

Eine Migration auf Microsoft Exchange Server lässt sich nicht überall so schnell realisieren, weswegen die Erhöhung des Timeout einfacher ist. Diese Einstellung betrifft einen Registry Key auf dem Backup Exec Remote System:

Key: HKLM\ SOFTWARE\Symantec\Backup Exec For Windows\Backup Exec\Engine\Domino\
Value name: Wait Before Timeout
Default Value: 10000

Der Default Wert ist 10’000, dies entspricht 10 Sekunden. Dieser sollte in Tausender Schritte erhöht werden, bis der Fehler nicht mehr auftritt.

Der OS Streaming Solution von Citrix, der Provisioning Server (PVS), hält immer grösseren Einzug in den Datacentern. Immer mehr Kunden setzen dabei auch auf VMware ESX als Hardware für die PVS Target Devices. Besonders im Zusammenhang mit XenDesktop kann dies ein sehr interessantes Konstrukt sein. Der Erfolg von virtualisierten XenApp Server lassen wir in diesem Fall mal im Raum stehen…

Mit VMware ESX 3.5 Update 1 und Provisioning Server 4.5 SP1 gibt es allerdings ein Problem, wenn die Target Devices keine lokalen Festplatten haben. Wohlbemerkt, dies ist DER Vorteil von OS Streaming. Eine solche Virtual Machine ohne Hard Disk endet nach dem Boot-Screen mit einem Blue Screen, “STOP: 0x0000007B”. Aus irgendwelchen Gründen wird bei einer VM ohne Hard Disk der SCSI Driver(VMware Tools) entfernt welcher das PVS Target Device benötigt…

Citrix fühlt sich in diesem Fall nicht verantwortlich, da es sich um einen Defekt der VMware Tools handelt. Anyway – als Workaround muss “nur” eine Hard Disk in der Grösse von 1 MB erstellt / attched werden. Ev. wird das Problem im ESX 3.5 Update 2 adressiert…

Wenn bei der Exchange Server Source die Updates integriert wurden, erfolgt die Installation wahrscheinlich von einer lokalen Disk, wie zum Beispiel “E:\Microsoft\Exchange Server\Source\”. Bei der Vorbereitung des Active Directory kann es beim Ausführen des Command “setup.com /PrepareAD /OrganizationName: ServerTalkMail“ zu einem Fehler kommen:

Performing Microsoft Exchange Server Prerequisite Check
Organization Checks              ……………………. COMPLETED

Configuring Microsoft Exchange Server
Organization Preparation         ……………………. FAILED
You do not have permissions to read the security descriptor on CN=Deleted
Objects,CN=Configuration,DC=intra,DC=server-talk,DC=ch.

Wird allerdings die Installation respektive “setup.com“ von “D:\Microsoft\Exchange Server\Source\” gestartet, funktioniert der Command “/PrepareAD” ohne Probleme:

Performing Microsoft Exchange Server Prerequisite Check
Organization Checks              ……………………. COMPLETED

Configuring Microsoft Exchange Server
Organization Preparation         ……………………. COMPLETED

The Microsoft Exchange Server setup operation completed successfully.

Weitere Informationen

• Microsoft Technet: White Paper: Preparing Active Directory for Exchange 2007
• Microsoft KB 556086: How to find the current Schema Version
• Microsoft KB 274737: How to Verify That ForestPrep and DomainPrep Completed Successfully

Unter Windows kann es vorkommen, dass ein Laufwerk sich nicht verbinden lässt und der Fehler “device name is already in use” angezeigt wird:

System error 85 has occurred. The local device name is already in use.

Systemfehler 85 ist aufgetreten. Der lokale Gerätename wird bereits verwandt.

In Wirklichkeit besteht gar keine Verbindung und der Mapping Point wäre verfügbar… Zuerst sollte sichergestellt werden, dass wirklich keine “net use” Verbindung, oder allenfalls eine Zuordnung mit der “subst”-Funktion angelegt wurde. Mit folgendem Registy-Eintrag lässt sich das Problem beheben:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\mup
Entry: EnableDeviceNameCreateRetry
Type: DWORD
Value: 1

Im Microsoft KB 308337 kann dies ebenfalls nachgelesen werden.

Das Update Procedure von Backup Exec verläuft inzwischen sehr stabil. Wenn der Environment Check gemacht, und die Hinweise befolgt werden steht dem Erfolg nichts im Wege. Allerdings hat es leider doch einige Fälle gegeben, wo die Backup Devices nach einem Update von 11d nach 12 “offline” waren und sich nicht mehr “online” nehmen liessen. Wenn die Aktualisierung der Software und Device Driver keine Besserung erbringt, hat bei der bisherigen Versionen folgender Workaround geholfen:

1. Im Device Wizard alle Tape Device Drivers entfernen
2. Den Backup Exec Media Server und die Robotic Library, oder das Tape Drive herunterfahren
3. (Nur) die Robotic Library, oder das Tape Drive starten und auf die vollständige Initialisierung warten. Es dürfen am Device keine Fehler reported werden!
4. Den Backup Exec Media Server starten. Es dürfen beim SCSI Controller keine Fehler reported werden.
5. Die neuste Version der Backup Exec Device Drivers installieren und das System nochmals neu starten.

Bei Backup Exec in der Version 12 hilft dies leider nicht immer weiter, es scheint sich in diesen Fällen um ein Fehler/Bug in der Application zu handeln. Auszug aus einem Support-Case:

Our liaison to development is working on a hotfix for this issue. It is currently unclear if this is related to specific hardware or if it’s a conflict with software applications loaded on the server. They are diligently working on this and hope to resolve it soon.

Als Workaround ist aktuell nur der Einsatz von Backup Exec 11d bekannt. The story has to continue…

Weitere Informationen

• Symantec Document 255501: How to troubleshoot issues with a Robotic Library or Tape Drive in Backup Exec for Windows Servers.
• Symantec Document 256134: Troubleshooting devices that are not displayed in the Devices tab or whose status appears “offline”
• Symantec Document 252078: A tape device is reported “Offline” in Backup Exec