Bereits kurz nachdem Service Pack 1 für Windows Server 2008 R2 veröffentlicht und bei diversen Kunden installiert wurde, hat sich ein Problem bei der Storage Validierung herauskristallisiert. Philipp Witschi von der itnetx gmbh hat mich auf ein Problem aufmerksam gemacht, dass bei einem Windows Server 2008 R2 Failover Cluster mit Service Pack 1 die Cluster Validation einen Fehler mit dem Storage meldet, konkret den Cluster Disks:

Im Validation Report werden unter “Storage” folgende Fehlermeldungen ausgegeben, sobald drei (3) oder mehr Nodes im gleichen Failover Cluster mit Windows Server 2008 R2 Service Pack 1 betrieben werden:

Failed to get SCSI page 83h VPD descriptors for cluster disk <number> from <node name> status 2

Disk with identifier <value> has a Persistent Reservation on it. The disk might be part of some other cluster. Removing the disk from validation set.

(weiterlesen…)

Eine der Stärken von System Center Virtual Machine Manager ist die Migration von VMware Virtual Machines nach Hyper-V. Eine Virtual-2-Virtual (V2V) Migration kann zwar von einem ESX Host initiiert werden, allerdings sprechen einige Punkte dagegen:

Damit eine V2V-Migration überhaupt gestartet werden kann, muss VMware vCenter in Virtual Machine Manager integriert werden. Das heisst, eine Virtual Machine kann nur von einem durch VMM verwalteten ESX Host migriert werden. Für den File-Transfer zwischen Host und VMM Library müssen seit VMware vSphere 4 die “root” Credentials verwendet werden. Last but not least – VMM verwenden unterschiedliche Protokolle für der File Transfer bei VMware Host mit/ohne Service Console:

• embedded ESX Hosts (ESXi): HTTPS, Port 443
• non-embedded ESX Hosts (ESX): SFTP, Port 22

Beide Transfer Varianten sind leider nicht gerade berauschend was die Performance angeht. Für eine V2V-Migration kann aber auch die VMM Library eingesetzt werden. Die erforderlichen Files (*.vmx, *.vmdk) müssen dann manuell vom VMware Host exportiert und in die VMM Library transferiert werden – mit dem bei VMware Administratoren sehr beliebten Tool Veeam FastSCP geht dies nun allerdings wesentlich schneller.

(weiterlesen…)

Der Core Installation Mode (Server Core) ist sehr häufig mit Hyper-V und natürlich bei Hyper-V Server anzutreffen. Durch die geringe Angriffsfläche, Wartungs- und Verwaltungsaufwand ist dies die ideale Konfiguration. Ein sicheres System ist nicht immer die einfachste Variante – gerade die Installation von NIC Treiber und/oder Teaming Software ist bei Server Core aufwändiger als bei einer Installation im Full Installation Mode, aber durchaus machbar.

In gewissen Konstellationen kann es vorkommen / angebracht sein – nicht verendete Network Adapter zu deaktivieren. Bei Server Core wird dies mit dem Netsh Command-Line Utility durchgeführt: “netsh interface set interface "Local Area Connection 4" DISABLED. Der Status der Network Adapter kann mittels “netsh interface show interface” überprüft werden.

Es kann allerdings nachträglich zu Problemen kommen, diesen Adapter wieder zu aktivieren. Zum Beispiel nach einem Update der Treiber (zum Beispiel bei Broadcom in HP Server…). Der Status bleibt dann auch nach der Anwendung von Netsh “Disabled”. Ein simples WMI-Script kann hier Abhilfe leisten:

Function EnablePreviouslyDisabledNics()
    strComputer = "."
    Set objWMIService = GetObject("winmgmts:\\" & _
    strComputer & "\root\cimv2")
    Set colAdapters = objWMIService.Execquery("Select * from Win32_NetworkAdapter Where NetEnabled=False")
    For Each Adapter in colAdapters
        Adapter.Enable()
    Next
    Set objWMIService = Nothing
End Function

EnablePreviouslyDisabledNics

Einfach als enableNIC.vbs speichern und auf dem Server aufrufen, “cscript enableNIC.vbs“. Sämtlich deaktivierten Network Adapter werden nun wieder aktiviert und der können wieder verwendet werden. Mit “netsh interface show interface” kann wieder der Status überprüft werden.

Weitere Informationen

• Microsoft TechNet: Netsh Commands for Interface (IPv4 and IPv6)

Die Installation von Windows mittels USB-Stick 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 C:\ 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  Operating System 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.

Weitere Informationen

• Microsoft TechNet: Bootsect Command-Line Options

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  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.