Die neuen Windows Versionen (er)kennen inzwischen sehr viele in einem Client oder Server System eingesetzten Hardware Komponenten. Es kann dennoch zur Situation kommen, wo ein Treiber manuell aktualisiert werden muss. In der Regel ist dies keine grosse Sache, doch bei Server Core ist von remote nur ein Read-Only Zugriff auf den Device Manager möglich.

Zurück auf die Command Line verschafft man sich am besten mal einen Überblick der bereits installierten Treiber. Dies kann mit sc query type= driver oder mit driverquery durchgeführt werden. Stellt sich heraus, dass ein Update der Treiber erforderlich ist, sollte die Installationsdateien auf den Server kopiert werden. Mit pnputil lassen sich dann die Treiber (im *.inf Format) installieren: C:\>pnputil -i -a "C:\ Drivers\IntelChipset\InfInst\ibexide.inf"

Die Ausgabe dieses Commands sieht dann wie folgt aus: 

C:\>pnputil -i -a “C:\ Drivers\IntelChipset\InfInst\ibexide.inf”
Microsoft PnP Utility

Processing inf :            ibexide.inf
Successfully installed the driver on a device on the system.
Driver package added successfully.
Published name :            oem0.inf

Total attempted:              1
Number successfully imported: 1

Da viele Treiber mit einem eigenen Installer kommen, sollten diese zuvor auf einem anderen System extrahiert werden. Beim genannten Beispiel des Intel Chipset Driver konnte der Installer mit einem zusätzlichen Parameter (Extract driver files that match the system hardware) aufgerufen werden, um nur die vom System benötigten Treiber zu extrahieren: C:\> infinst911autol.exe –aonly

Weitere Informationen

• Microsoft TechNet: Driverquery

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)

Server, welche keine grafische Benutzeroberfläche benötigen, können als Core installiert werden. Dabei wird nur ein Minimalsystem installiert, welches out-of-the-box durch eine Command Line Oberfläche administrierbar ist. Da nur die benötigten Features eingebunden werden, ist der Footprint kleiner als bei einer Full Installation des Windows Servers. Weniger Bits & Bytes heisst auch, eine kleinere Angriffsfläche und somit auch weniger Patches.

Da für eine Server Core Installation nicht die gewohnte Windows Benutzeroberfläche verwendet wird, kann für den Abschluss der Serverkonfiguration keine Standardvorgehensweise (“Out-of-Box Experience”) angegeben werden. Stattdessen muss die Initial Konfiguration manuell mit Command Prompt Tools ausgeführt werden, daher hält sich die Beliebtheit des Server Core bei den Administratoren leider noch ziemlich in Grenzen…

Um einfachere Möglichkeiten aufzuzeigen wie ein Server schneller und einfacher in Betrieb genommen werden kann, nachfolgend eine kurze Übersicht über die Server Core Management Tools.

(weiterlesen…)

Service Pack 2 für Windows Vista und Server 2008 hat den Status Release to Manufacturing (RTM) erreicht. Komfortabel ist, dass das SP für beide Operating Systems (Client sowie Server), sämtliche Architekturen und mehreren Sprachen eingesetzt werden kann:

Auf diesem Medium sind folgende Files enthalten

• Windows6.0-KB948465-IA64.exe (472’267’144 KB)
• Windows6.0-KB948465-X64.exe (605’410’472 KB)
• Windows6.0-KB948465-X86.exe (365’230’920 KB)

Anforderungen

Ein Upgrade auf Service Pack 2 kann mittels Software Verteilung (SCCM), Patch Management (WSUS), oder auch manuell als Stand-alone vorgenommen werden. Für die Installation wird je nach Version / Sprache entsprechend viel freier Disk Space vorausgesetzt:

• Stand-alone Installation
  • X86: : 1.8 GB bis 2.9 GB
  • X64: 3.2 GB bis 4.9 GB
  • IA64: 2.9 GB bis 3.2 GB
• Windows Update
  • X86: : 350 MB
  • X64: 600 MB
  • IA64: 2.25 GB

Installation

Bei einem Server Core, dem Server ohne GUI, erfolgt die manuelle Installation auf der Command Line Ebene. Für eine Installation des Service Packs müssen folgende Schritte vorgenommen werden:

1. ISO mounten, DVD einlegen, oder Binaries auf den Server kopieren
2. Entsprechendes EXE (IA64, X64, X86) mit dem Parameter /unattend aufrufen, zum Beispiel: Windows6.0-KB948465-X64.exe /unattend
3. Nach einem Reboot ist die Installation abgeschlossen. Es wird die Meldung „Windows Server Service Pack 2 is now installed“ ausgegeben.

Der Setup dauert einige Minuten. Der Vorgang sollte daher zwingen in einem Wartungsfenster vorgenommen werden. Wichtig, Pre-RTM Build können nicht aktualisiert werden. Diese Releases müssen vor dem Upgrade entfernt werden.

Damit eine Installation über Windows Update verhindert werden könnte, gibt es das Windows Service Pack Blocker Tool Kit. Wichtig, eine Installation des Service Pack erfolgt sowieso erst nach Akzeptieren der EULA. Zum Download…

Weitere Informationen

• Microsoft KB 262841: Command-line switches for Windows software update packages
• Microsoft TechNet: Windows Server 2008 SP2 Deployment Guide
• Microsoft TechNet: Windows Server 2008 Service Pack 2 und Windows Vista Service Pack 2

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

Nach der Installation von Windows Server 2008 erscheinen als erstes die “Initial Configuration Tasks” (ICT). Dieser Wizard unterstützt den Administrator bei der Grundkonfiguration der Server. Werden die Server mittels Softwareverteilung oder einem vergleichbaren Mechanismus bereits entsprechend konfiguriert, kann n einem Active Directory Environment mittels Group Policy deaktiviert werden indem unter “Computer Configuration ⇒ Administrative Templates ⇒ System ⇒ Server Manager” die Policy “Do not display Initial Configuration Tasks window automatically at logon” und bei Bedarf zusätzlich auch “Do not display Server Manager automatically at logon” enabled wird.

Wenn nun dennoch einem die Initial Configuration Tasks eingesetzt werden sollten, währe es hilfreich zu wissen wie der ICT Wizard gestartet werden kann. Nichts Einfacheres als dies… Dazu muss lediglich in Run Promt “oobe“, was für ”Out of Box Experience” steht, ausgeführt werden. Das war’s bereits…

Im vorhergehenden Artikel wurde beschrieben, wie Volume Activation 2.0 von Microsoft funktioniert. Von der Theorie geht es nun zur Praxis. Im nachfolgenden Artikel wird beschrieben, wie ein Key Management Service (KMS) in Betrieb genommen werden kann. Damit diese Form der Aktivierung eingesetzt werden kann, sind im Minimum 25x Windows Vista, oder 5x Windows Server 2008 im Netzwerk erforderlich. Die Aktivierung mittels KMS ist so konzipiert, dass der Eingriff durch ein Administrator auf ein Minimum beschränkt ist.

DNS Server

KMS-Hosts erstellen automatisch einen “Service Record” (SRV) auf dem DNS-Server. Wird “Dynamic DNS” (DDNS) unterstützt, ist keine weitere Konfiguration erforderlich. Wenn allerdings mehrere KMS-Hosts eingesetzt werden, kann jeweils nur der erste Host den DNS-Record erstellen. Die nachfolgenden KMS-Hosts können den Record nur ändern, wenn die Berechtigungen auf dem DNS-Server entsprechend angepasst wurden:

1. In Active Directory eine Global Security Group für die KMS-Hosts anlegen.
2. In die Security Group sämtliche KMS-Host (Computer Accounts) hinzufügen.
3. Die Berechtigung auf dem DNS-Server anpassen, damit Mitglieder der Security Group Host Updates durchführen können.
4. Der SRV_Record kann nun durch den KMS-Host angelegt werden.

Per Default ist DDNS auf einem Windows DNS-Server aktiviert (Dynamic Updates: Secure only). Wenn diese Funktion in einem Netzwerk nicht zur Verfügung steht, kann der SRV-Record auch ohne weiteres manuell angelegt werden:

1. Im DNS Manager den DNS-Server auswählen und die “Forward Lookup Zones” erweitern.
2. Auf der entsprechenden Domain mittels Rechtsklick “Other New Records… ⇒ Service Location (SRV)” anwählen und mit “Create New Record…” bestätigen.
3. Folgende Werte müssen nun eingetragen werden
   • Service: _VLMCS
   • Protocol: _TCP
   • Port number: 1688
   • Host offering this service: <FQDN des KMS-Host>
4. Mit “OK” wird der SRV-Record angelegt.

Die automatische Veröffentlichung durch den KMS-Host kann zudem mit dem Befehl “slmgr.vbs /cdns” deaktiviert werden. Das Script legt folgenden Key in der Registry an:

Key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL
Entry: DisableDnsPublishing
Type: DWORD Value: 1

Wird der Eintrag von 1 (Disabled) auf 0 (Enabled) gesetzt, ist DNS-Publishing wieder aktiviert. Ob nun der DNS-Record vorhanden ist und entsprechend funktioniert, kann mit nslookup getestet werden: nslookup -type=srv _vlmcs._tcp.intra.server-talk.eu. Als Output sollte etwas in dieser Form geliefert werden

_vlmcs._tcp.intra.server-talk.eu SRV service location:
    priority = 0
    weight = 0
    port = 1688
    svr hostname = DC01.intra.server-talk.eu
DC01.intra.server-talk.eu internet address = 192.168.1.101

KMS-Host

Nachdem die Vorbereitung auf dem DNS-Server abgeschlossen sind, kann die “Installation” des KMS-Host vorgenommen werden:

1. Auf dem zukünftigen KMS-Host einen Command Prompt als Administrator ausführen.
2. Die Installation des KMS-Key erfolgt mit dem Befehl “cscript C:\windows\system32\slmgr.vbs /ipk 12345-12345-12345-12345-12345“
3. Die Aktivierung des KMS-Key bei Microsoft stehen folgende Methoden zur Verfügung:
   • Internet: “cscript C:\windows\system32\slmgr.vbs /ato“
   • Phone: “slui.exe 4“
4. Nach erfolgreichem Abschlus der Aktivierung muss der “Software Licensing” Service neu gestartet werden “net stop slsvc && net start slsvc“

Mit slmgr stehen noch viele weitere Möglichkeiten zur Verfügung, wie nachfolgende Tabelle zeigt:

Ist es geplant den KMS Host auf Windows Server 2003 zu betreiben, so muss das Update 948003 installiert werden. Damit wird die Funktionalität des Key Management Service 1.1 hinzugefügt.

Firewall

Per Default verbinden die Clients mittels “Remote Procedure Calls over TCP”. Die Verbindung über TCP-Port 1688 muss bei der Firewall entsprechend zugelassen werden. Bei Bedarf kann diese Port Nummer auch angepasst werden. Bei einem Windows Server 2008 muss in der “Windows Firewall” der Zugriff auf ”Windows-Verwaltungsinstrumentation (WMI)” und den “Key Management Service” aktiviert werden. Dies kann sehr einfach mit dem Befehl “netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=yes” und netsh advfirewall firewall set rule group="Key Management Service" new enable=yes” konfiguriert werden.

VAMT

Für die Verwaltung der Lizenzen stellt Microsoft das Tool “Volume Activation Management Tool” (VAMT) zum Download bereit. Mit dem Tool lassen sich die Computer Accounts zum Beispiel aus dem Active Directory auslesen und den Lizenzierungs-Stand anzeigen und bei Bedarf notwendige Schritte einleiten. Da die Informationen nicht in einer Database gespeichert werden, ist es zu empfehlen am Ende die aktuellen Daten mit “File ⇒ Save As…” in ein CIL-File zu exportieren. Zu einem späteren Zeitpunkt lässt sich dieses über “File ⇒ Open” wieder einlesen.

Weitere Informationen

• Microsoft Download Center: Windows Vista Volume Activation 2.0
• Microsoft Download Center: Volume Activation 2.0 Technical Guidance
• Ralf Schnell’s TechNet Blog: Windows Aktivierung: Redundanz für Key Management Services-Hosts
• MCS Ireland TechNet Blog: Using Key Management Services (KMS) Across Domains

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

Für die Installation von Exchange Server 2007 ist eine Schema Erweiterung erforderlich. Diese kann automatisch im grafischen Setup (GUI) durchgeführt werden, oder man führt diese step-by-step in einem Command Prompt (CMD) durch. Dies hat den Vorteil, dass sämtliche Änderungen vollständig im Forest repliziert und unangenehme Fehler dadurch vermieden werden können. Optimaler weise wird die Erweiterung des Schemas direkt auf dem Domain Controller mit der FSMO-Role “Schema Master” durchgeführt. Der Vorgang kann aber auch von dem zukünftigen Exchange Server gestartet werden… Da in den meisten Fällen die Domain Controller basierend auf einem 32-Bit Windows installiert wurden (was auch völlig in Ordnung ist), kann hier nicht die gleiche Source wie für die produktive Exchange Server 2007 Installation verwendet werden. Die 32-Bit Version stellt Microsoft als Trial zum Download bereit. Auf dem System wo die Schema Extentsion durchgeführt werden soll, müssen folgende Voraussetzungen geschaffen werden:

• Windows Server 2003
  • Microsoft Windows PowerShell
  • Microsoft .NET Framework 2.0
  • Microsoft .NET Framework 2.0 Update
  • Microsoft Management Console (MMC) 3.0
• Windows Server 2008
  • Microsoft Windows PowerShell: ServerManagerCmd -i PowerShell
  • Microsoft AD Management Tools: ServerManagerCmd -i RSAT-ADDS

Die Source (Exchange Server 2007 32-Bit) sollte in ein Temporäres Directory entpackt werden, zum Beispiel “C:\Temp\EXCSource”. Die Befehle für die Schema Extension werden in einem “Command Prompt” durchgeführt. Diese muss bei Windows Server 2008 als Administrator ausgeführt werden

Schritt 1

Dieser Vorgang bereitet die Exchange Server 200x Umgebung für Exchange Server 2007 vor. Wird eine neue Exchange Server 2007 Organization installiert, ist dieser Befehl nicht notwendig.

• Permissions
  • Mitglied der Gruppe “Domain Admins”
  • Mitglied der Gruppe “Enterprise Admins”
• Befehl
  • Normal: setup /PrepareLegacyExchangePermissions
  • Kurzform: setup /pl
• Weitere Informationen
  • Microsoft Technet: Preparing Legacy Exchange Permissions

Schritt 2

In diesem Vorgang wird das Active Directory Schema für Exchange Server 2007 erweitert. Dieser Vorgang darf/muss nur einmal pro Active Directory ausgeführt werden. Übrigens, wurde “setup /pl” nicht separat ausgeführt, ist dies nicht weiter schlimm. In diesem Fall wird der fehlende Vorgang automatisch zusammen mit “setup /ps” ausgeführt.

• Permissions
  • Mitglied der Gruppe “Enterprise Admins”
  • Mitglied der Gruppe “Schema Admins “
  • Mitglied der Gruppe “Exchange Full Administrator”
• Befehl
  • Normal: setup /PrepareSchema
  • Kurzform: setup /ps
• Weitere Informationen
  • Microsoft Technet: Active Directory Schema Changes

Schritt 3

Dieser Parameter bereitet das Active Directory für die Exchange Installation vor. Existiert noch keine Exchange Organization, muss diese mit “/OrganizationName” (gemäss Konzept) definiert und angelegt werde. Bei einem Upgrade kann dieser Switch weggelassen werden. Für diesen Vorgang müssen sämtliche Domains im Forest auf Port 389 ansprechbar sein.

• Permissions
  • Mitglied der Gruppe “Enterprise Admins”
• Befehl
  • Normal: setup /PrepareAD /OrganizationName:ExchangeTalk
  • Kurzform: setup /p /on:ExchangeTalk
• Prüfung
  • Mit ADSIEdit kann die “objectVersion” in Active Directory geprüft werden. Dazu müssen die “Properties” von “DC=MyDomain,CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=MyOrganization” geöffnet werden. Die Version von Exchange Server 2007 SP1 lautet 11221, Exchange Server 2007 RTM 10666.
• Weitere Informationen
  • Microsoft Technet: Exchange 2007 Server Setup Permissions Reference
  • Microsoft Technet: Insufficient Permissions to Prepare Active Directory

Schritt 4

In jeder zusätzlichen Domain des Forest, wo Exchange Server 2007 installiert werden soll oder E-Mail-aktivierte User enthalten soll, muss die Domain vorbereitet werden. Dazu wird entweder der FQDN der Domain explizit angegeben, oder der Vorgang direkt für sämtliche Domains ausgeführt. Die lokale Domain wurde bereits in Schritt 3, mit /prepareAD, entsprechend vorbereitet.

• Permissions
  • Mitglied der Gruppe “Enterprise Admins”
• Befehl
  • Normal (specific Domain): setup /PrepareDomain:fqdn.mydomain.com
  • Kurzform (specific Domain): setup /pd:fqdn.mydomain.com
  • Normal (alle Domains): setup /PrepareAllDomains
  • Kurzform (alle Domains): : setup /pad
• Weitere Informationen
  • Microsoft Technet: Exchange 2007 Server Setup Permissions Reference

Überprüfung

Die Version des Schema kann mittels ADSIEdit ermittelt und kontrolliert werden. ADSI Edit (“adsiedit.msc”) oder ein anderes Tool starten und folgenden Path öffnen: CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC=intra,DC=server-talk,DC=eu. Das Attribute “Range Upper” zeigt die aktuelle Version an, für welche der Active Directory Forest vorbereitet wurde. Mögliche Werte wären:

• Exchange Server 2000 = 4397
• Exchange Server 2000 SP3 = 4406
• Exchange Server 2003 = 6870
• Exchange Server 2003 SP3 = 6936
• Exchange Server 2007 = 10628
• Exchange Server 2007 SP1 = 11116

Der Status der Active Directory Replikation kann mit dem Support Tool “replmon.exe” verfolgt werden. Diesem Thema hat Yusuf in seinem Blog einen kompletten Artikel gewidmet.

Weitere Informationen

• Microsoft Technet: Preparing Active Directory for Exchange 2007 White Paper
• Microsoft Technet: How to Prepare Active Directory and Domains
• Microsoft Technet: Active Directory Schema Changes (SP1)
• Microsoft Technet: Description of the Parameters Used With the Exchange 2007 Setup.com Tool White Paper
• Microsoft KB 556086: How to find the current Schema Version
• Active Directory Team Blog: Troubleshooting ADPREP Errors

Das Patch Management für Microsoft Produkte stellt seit “Microsoft Update” kein grosses Problem mehr dar. Die Microsoft Family wird in grossen Umfang unterstützt. Mit “Windows Server Update Services” (WSUS) ist es für grössere Infrastrukturen auch möglich, Patches gemäss einem Approval-Plan automatisch zu installieren. Die Freeware von Microsoft liegt aktuell in der Version 3.0 SP1 vor. Nachfolgend wird beschrieben, wie WSUS auf einem Windows Server 2008 System implementiert werden kann:

1. Den “Server Manager” auf eine der nachfolgend beschriebene Methoden starten
   • … das Startmenu öffnen und mit einem Rechtsklick auf “Computer” “Manage” anwählen
   • … im Startmenu, unterhalb “Administrative Tools” den “Server Manager” öffnen
   • … in der Quick Launch das “Server Manager” Icon anwählen
2. Damit die WSUS Role im Server Manager als Role angezeigt wird, muss zunächst das Windows Update “Update for Windows Server 2008 Server Manager (KB940518)” installiert sein. Dazu kann im Server Manager im Bereich “Security Information” die Option “Check for New Roles” anwählen und mittels Windows Update das erforderliche Update installieren. Natürlich kann die Installation auch manuell vorgenommen werden. Zum Download…
3. Der Server muss nach dem Update neu gestartet werden, bevor eine neue Role installiert werden kann.
4. Sind die Vorbereitungen getroffen kann nun im Server Manager mit “Add Roles” die neue Role “Windows Server Update Service” installiert werden. Die benötigten Komponenten, die Web Server (Role), werden automatisch installiert. Ebenso werden zusätzlich erforderliche Binaries vom Windows Update Server heruntergeladen. Dazu ist der Zugang ins Internet erforderlich…
5. Nach der Installation der Web Server Role wird automatisch der Installation Wizard für WSUS 3.0 SP1 gestartet. Dieser unterscheidet sich nicht von der bisherigen Version.

Microsoft hat einen sehr umfangreichen “Deploying Microsoft Windows Server Update Services 3.0 SP1″ Guide veröffentlicht, welcher Design, Installation und Konfiguration genau beschreibt. Zum Download… Laufend interessante News werden auch auf dem WSUS Blog von Arnd Rößner veröffentlicht.

Weitere Informationen

• Microsoft KB 948014: Description of the Windows Server Update Services 3.0 Service Pack 1 package
• WSUS Team Blog: New categories appearing on WSUS
• Microsoft Download Center: Windows Server Update Services 3.0 SP1
• Microsoft Download Center: Release Notes for Windows Server Update Services 3.0 SP1