So sieht es in einiger Zeit aus wenn wir versuchen eine Mail zu senden. Wir sehen die Nasen der Empfänger und Mailtipps machen uns darauf aufmerksam ob es überhaupt Sinn macht auf “Senden” zu drücken.

Die Speicherung der Thumbnails im AD hat Ilse hier beschrieben:
http://blogs.technet.com/ilvancri/archive/2009/11/17/upload-picture-in-outlook-2010-using-the-exchange-management-shell-exchange-2010.aspx

Ein guter Bekannter hat sein erstes Video gedreht. Ranhalten musste die neue “File Classification” Funktion des Windows Server 2008 R2. Am Besten sieht mans in Fullscreen hier.

Nachdem der Eintrag http://wolfgang-on-the-road.spaces.live.com/blog/cns!F135E7D1136D4C5A!1097.entry so kräftig kommentiert wird (was mich sehr freut) habe ich ein Skript in Rohform gemacht, das den Ablauf komplett automatisiert. Im Skriptablauf wird eine Mailbox Datenbank gesichert, es werden die letzten drei Generationen aufbewahrt und durchrotiert.

Step 1: diskshadow Skript erstellen [ex-backup.txt] und darin Pfad zu “ex-backup.bat” anpassen.

set context persistent
begin backup
add volume L: alias FirstStorageGroup
create
expose %FirstStorageGroup% Q:
exec ex-backup.bat
end backup
delete shadows exposed Q:
exit

Step 2: Batch Job erstellen, der aus dem diskshadow Makro aufgerufen wird [ex-backup.bat]

@echo off
set BACKUPSHARE=c:\backup
echo Rotate
rd /s /q %BACKUPSHARE%\3
ren %BACKUPSHARE%\2 3
ren %BACKUPSHARE%\1 2
md %BACKUPSHARE%\1
attrib -s -h %BACKUPSHARE%\1

echo running eseutil
eseutil /k "Q:\SG1DB\Mailbox Database.edb"

echo running robocopy
robocopy q:\sg1db %BACKUPSHARE%\1\sg1db /E /XD catalogdata*
robocopy q:\sg1log %BACKUPSHARE%\1\sg1log /E

echo ok

Step 3: diskshadow mit Kommandozeilenoptionen aufrufen und wenn es funktioniert als Task einplanen (Pfade u.U. anpassen)

diskshadow /s ex-backup.txt /l ex-backup.log

Weitere Ergänzungen sollten noch sein:

• falls eseutil einen Fehler meldet sollte das Skript abbrechen
• Entsorgen der .cab Dateien die durch den Snapshot erzeugt werden
• Robocopy Logs mitschreiben lassen
• …

In der bisher noch spärlichen Dokumentation zur Exchange 2010 Beta fiel mir das hier auf:

http://technet.microsoft.com/en-us/library/dd335144(EXCHG.140).aspx.

Es ist jetzt möglich alle (oder auch nur Teile der) administrativen Tätigkeiten in Form einer Email protokollieren zu lassen. Es ist dabei unerheblich ob die Änderung per Exchange Management Shell, Konsole oder Web Management durchgeführt wird.

Aktiviert wird die Funktion organisationsweit mit der Management Shell (s. Doku für Details). Der Einfachheit halber habe ich alle “cmdlets” und alle Parameter protokollieren lassen.

• Mailbox “AuditLog” anlegen
• “Full Access Permission” für den Administrator definiert (der will ja das ganze Zeug nicht in seiner eigenen Mailbox haben)
• Audit aktivieren (einen Tag Vorhaltezeit einstellen, default ist ein Jahr)
  Set-AdminAuditLogConfig -AdminAuditLogCmdlets *
  Set-AdminAuditLogConfig -AdminAuditLogParameters *
  Set-AdminAuditLogConfig -AdminAuditLogMailbox AuditLog@exchdev.addon.de
  Set-AdminAuditLogConfig –AdminAuditLogAgeLimit 01.00:00:00
  Set-AdminAuditLogConfig –AdminAuditLogEnabled $true
• Die Einstellung wird aktiv wenn die Shell oder die Konsole neu aufgerufen wird oder automatisch nach Ablauf einer Stunde.
• Mit “Get-AdminAuditLogConfig” können die Einstellungen angezeigt werden.

Jede Änderung (aber kein get-*) wird nun in das “AuditLog” Postfach zugestellt. Hier kann man sehen, dass per OWA auch andere Postfächer geöffnet werden können.

In der Email selber ist das “cmdlet” plus aller Parameter und natürlich der administrative Benutzer der die Änderung durchgeführt hat, dokumentiert. In diesem Beispiel ist das die Verschiebung einer Mailbox Datenbank auf einen anderen Exchange Server in einer “Database Availability Group”.

Eine der neuen SCCM 2007 R2 Funktionen ist die Unterstützung für unbekannte Computer während der Betriebssysteminstallation. Ziel soll hier sein auf die manuelle Registrierung von MAC Adressen oder GUIDs in der SCCM Datenbank zu verzichten und sofort mit der OSD Task Sequence (TS) zu starten. Folgende Voraussetzungen sind dazu nötig:

• Installation der R2 Erweiterung. Falls die Funktion in einer sekundären Site verwendet werden soll dann muss die R2 Erweiterung auch dort installiert werden. Das denkt man erstmal nicht wenn man die sekundäre Site von der primären Site (wo R2 schon installiert ist) aus installiert hat.
• Aktivieren des “unknown computer supports” in den Eigenschaften des PXE Service Points
   
• Erzeugen einer Collection für unbekannte Computer. Alternativ kann man natürlich auch die durch das R2 Setup erzeugten Collections verwenden.
  
  
• Erstellen der geeigneten Task Sequence und Ankündigung an die Collection.

Alle Computer die nicht in der SCCM Datenbank registriert sind empfangen nun diese Task Sequence. Ein Problem gibt es aber nun. Wie soll der Computername festgelegt werden? Ohne die Festlegung eines Computernamens würde der Rechner mit dem temporären Namen des Windows PE enden, also MININT-……

Bisher hatte ich nur eine Scriptvariante gesehen die den Computernamen zu Begin der Task Sequence, über einen “Pre Execution Hook” abfrägt, und die TS Variable “OSDComputername” setzt.

Es gibt allerdings noch eine viel einfachere Variante die ratz fatz und ohne Änderung des Boot Images implementiert ist. Hierbei helfen die Collection Variablen. Die OSD Komponente im Windows PE ist so gebaut, dass sie definierte aber nicht belegte Variablenwerte zur Laufzeit abfrägt.

Also:

• Erstellen einer Collection Variable mit dem Namen “OSDComputerName” ohne einen Wert zu definieren.
  
  
  
• Beim PXE Boot eines unbekannten Computers sieht man jetzt im Logfile “smspxe.log” des PXE Service Points den unbekannten Computer und alle TS die ihm zugewiesen sind. In diesem Falle sind das zwei optionale TS.
  
   
  
• Nachdem die TS am Computer gestartet wurde werden alle nicht definierten Variablen abgefragt. Hier könnten außer dem Computernamen weitere Variablen sinnvoll sein. Man könnte z.B. das Kennwort abfragen lassen mit dem der Computer später in die Domäne aufgenommen wird.
  
   
  
  Schon in der ersten Phase der TS kann man sich in “e:\sysprep\sysprep.inf” davon überzeugen, dass der Computername dort angekommen ist. Falls man eine unbeaufsichtigte Installation durchführt landet der Computername in der “unattend.txt”.
  

Kleines Manko ist, man muss die Variable nicht eingeben und kann auch so auf “Next” klicken. Dann wird eben der Computername zufällig MININT-… mäßig festgelegt. Es findet natürlich auch keine Prüfung des Variableninhalts auf z.B. ungültige Zeichen statt. Falls man solche Features einbauen will bleibt nur der Weg über Skripte.

Mein damals aufgebauter virtueller Hyper-V Cluster (http://wolfgang-on-the-road.spaces.live.com/blog/cns!F135E7D1136D4C5A!1233.entry) wurde in den letzten Tagen ein wenig aufgemotzt.

Die im Moment vorliegenden Informationen stammen hauptsächlich von der TechEd EMEA auf der eine PreBeta Version vom Windows 7 Server (aka Server 2008 R2) vorgestellt wurde. Die nächste Windows Server 2008 Version wird ja die "Cluster Shared Volumes (CSV)" unterstützen. Im ersten Schritt sind die CSV nur für den Hyper-V verwendbar. Mit dieser Technik wird die Grundlage für die "Live Migration" von virtuellen Maschinen im Cluster geschaffen. Zum einen können dann mehrere virtuelle Maschinen auf dieselbe LUN gelegt werden (und unabhängig zwischen den Knoten umgeschalten werden) und das relativ aufwendige Umschalten der LUN von einem Knoten auf den anderen entfällt.

Ausgangssituation war folgende

Zwei virtuelle Windows Server 2008 Servercore Maschinen, Hyper-V Rolle installiert, Failover Cluster Feature installiert, eine hochverfügbare VM auf einer iSCSI LUN.

Update

Nun wurde der erste Knoten auf Windows 7 Server aktualisiert. Alle Einstellungen haben überlebt, auch die Integrations Services liefen danach ohne Probleme, ebenfalls der iSCSI Initiator. Der Server zeigt nun die Version " 6.1.6801" an. Nach der Aktualisierung konnte der Clusterdienst nicht mehr starten und damit den bestehenden Cluster nicht joinen (mir ist noch nicht bekannt ob das später unterstützt wird, hoffe es aber).

OK, jetzt war es eh zu spät wieder zurückzurudern, deswegen habe ich den zweiten Knoten auch aktualisiert. Das war genauso problemlos. Danach konnte auch auf beiden Knoten der Clusterdienst wieder starten und alles funktionierte wie vorher.

Jetzt brauchte ich noch eine Maschine auf der ich die neue Failover Cluster MMC installieren konnte. Zu diesem Zweck wurde ein normaler (mit GUI) Windows 7 Server installiert und die RSAT Tools aktiviert.

Installation und Clustervorbereitung

Die Aktivierung der CSV muss im Moment noch mit der Powershell durchgeführt werden. Später gibt es anscheinend auch eine Möglichkeit in der MMC.

• Powershell Installation auf jedem Knoten
  "start /w ocsetup MicrosoftWindowsPowerShell"
  
• Aktivieren der CSV
  cd \windows\system32\WindowsPowershell\v1.0
  powershell.exe
  PS> Add-Module FailoverClusters
  PS> Get-FailoverCluster | %{$_.EnableSharedVolumes=1}
  PS> exit

Einrichten eines CSV

Die bestehende LUN konnte nicht in ein CSV umgwandelt werden weil sie als Diskressource ein der Clustergruppen für die schon eingerichtete VM war. Dieses musste ich löschen, damit wurde die Disk frei und konnte mit der Cluster MMC als CSV definiert werden.

Man sieht im rechten Bild die als CSV konfigurierte LUN (Cluster Disk 2). Auch so ein CSV hat pro LUN  einen Owner im Cluster. Dieser tritt als sogenannter "Coordinator Node" auf und kann den anderen Clusterknoten den Direktzugriff auf die LUN freigeben. So können mehrere Knoten gleichzeitig auf dieselbe LUN zugreifen auf der ja die virtuellen Disks (VHD Dateien) der VMs liegen.

Hier sieht man auch, dass das Filesystem auf dem CSV ein ganz normales NTFS ist.

Das CSV wird auf jedem Knoten im Verzeichnis "C:\Clusterstorage" bereitgestellt.

Der Knoten der "Coordinator Node" ist besitzt einen Link (in diesem Fall ein Junction) zum CSV.

Der andere Knoten sieht ebenfalls einen Link (in diesem Fall einen symbolic Link) zum CSV.

Wenn die Disk mit der Clustergruppen auf einen anderen Knoten schwenkt werden die Links entsprechend angepasst bzw. in meinem Fall umgekehrt. Mit dem Windows Explorer oder per Kommandozeile kann auf den symbolic Link nicht zugegriffen werden. D.h. das ist wirklich nur dem Hyper-V zugänglich.

Einrichten der virtuellen Maschine

Wenn ich jetzt physikalische Hardware hätte wäre sogar eine "Live Migration" drin. Aber leider kann ich ja im virtuellen Hyper-V keine VM starten :-(

Ich wollte heute schnell mal mit meiner SCCM OS Deployment Infrastruktur ein Notebook neu installieren, aber Pustekuchen. Schon in der Windows PE Phase kommt:

Error: The certificate associated with this media has expired. New media with a valid certificate will need to be created.

Im "smspxe.log" des PXE Points taucht auf:

Certificate issued to '2f0e3c7e-c442-4143-b894-5af230c65668' has expired.

Certificate not valid.. A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file. (Error: 800B0101; Source: Windows)

Huch, was ist das denn? Ich hatte von einem PXE Service Point (=Windows Deployment Service) gebootet. SCCM 2007 erzeugt während der Erstellung des PXE Points ein selbstsigniertes Zertifikat mit einem relativ kurzen Ablaufdatum.

Es reicht aus, in den Eigenschaften des PXE Points das Zertifikatsablaufdatum zu ändern, um das Problem zu beheben.

SCCM erstellt dabei ein neues Zertifikat (Ablauf 21.12.2008), das alte Zertifikat (Ablauf 30.7.2008) wird geblockt.

Brandaktuell kam gerade ein neues Hotfix Rollup (http://support.microsoft.com/?id=954641). Neben einigen Fehlerkorrekturen ist auch ein neues Feature eingebaut:

• Fix für Abstürze des DPM Agenten (DPMRA service)
• Fix für falsche Berechnung der Datenmenge wenn man Ordner aus der Sicherung ausschließt
• Fix für die "secondary protection", d.h. ein DPM sichert einen anderen DPM
• Und das neue Feature ist: Jetzt können auch Datenquellen gesichert werden die sich auf lokalen Festplatten des DPM Servers selber befinden (nur Dateien und die DPM Datenbank muss aufs Band). Das muss allerdings erst aktiviert werden.

Aktivieren der Sicherungsmöglichkeit für lokale Dateien:

Set-DPMGlobalProperty
   -DPMServerName dpmserver
   -AllowLocalDataProtection:$true

Ein Beispiel:

Marc: möchte eine Besprechung einberufen.
Norbert: soll als Teilnehmer eingeladen werden.
Conf1: ist das Ressourcenpostfach des Besprechungszimmers.
Wolfgang: soll im Auftrag des Besprechungszimmers den Termin zusagen und damit das Besprechungszimmer endgültig reservieren.

Was ist zu tun:

• Besprechungszimmer als Ressourcepostfach anlegen (Typ: Raum)
• Wolfgang erhält Berechtigungen für dieses Postfach
  Add-MailboxPermission conf1 -User wsauer -AccessRights fullaccess
• Das Ressourcenpostfach wird konfiguriert
  set-MailboxCalendarSettings conf1 -ResourceDelegates wsauer -AllBookInPolicy:$true
• Wolfgang öffnet per OWA sein eigenes Postfach und wechselt über "Anderes Postfach öffnen" das Postfach des Ressourcenpostfachs. Er wechselt auf die "Optionen" Seite und wählt links den Bereich "Ressourceneinstellungen" aus.
• Dort aktiviert er "Automatisch Besprechungsanfragen und Absagen verarbeiten"
• Folgende weitere Einstellungen aktiviert er:

Folgender Ablauf ergibt sich bei der Terminplanung

• Marc öffnet OWA oder Outlook und plant einen Termin mit Norbert als Teilnehmer und Conf1 als Bsprechungszimmer
• Marc erhält eine vorläufige Zusage

• Wolfgang erhält eine Mail in der er aufgefordert wird der Reservierung des Raums zuzustimmen

• Er klickt oben rechts auf "Kalender" und öffnet damit den Kalender des Raumpostfachs. Diese Aktion kann nicht in OWA stattfinden sondern muss mit Outlook gemacht werden.
• Er klickt mit der rechten Maustaste auf den Termin und wählt "Zusagen"

• Der Kalendereintrag im Raumpostfach wechselt von "Vorgemerkt" nach "Gebucht"
• Marc erhält die genehmigte Buchung
• Auf die Zusage von Norbert wartet er immer noch :-)

Ergebnis

Die Eigenschaften des Ressourcenpostfachs sehen in der Exchange Management Shell dann folgendermaßen aus:

Get-MailboxCalendarSettings conf1 | fl

AutomateProcessing                  : AutoAccept
AllowConflicts                      : False
BookingWindowInDays                 : 180
MaximumDurationInMinutes            : 1440
AllowRecurringMeetings              : False
EnforceSchedulingHorizon            : True
ScheduleOnlyDuringWorkHours         : False
ConflictPercentageAllowed           : 0
MaximumConflictInstances            : 0
ForwardRequestsToDelegates          : True
DeleteAttachments                   : True
DeleteComments                      : True
RemovePrivateProperty               : True
DeleteSubject                       : True
DisableReminders                    : True
AddOrganizerToSubject               : True
DeleteNonCalendarItems              : True
TentativePendingApproval            : True
EnableResponseDetails               : True
OrganizerInfo                       : True
ResourceDelegates                   : {Wolfgang Sauer}
RequestOutOfPolicy                  :
AllRequestOutOfPolicy               : False
BookInPolicy                        :
AllBookInPolicy                     : False
RequestInPolicy                     :
AllRequestInPolicy                  : True
AddAdditionalResponse               : True
AdditionalResponse                  : <DIV><FONT face=Tahoma size=2>jo jo, dann
                                       wünsch ich angenehmes Meeting!</FONT></D
                                      IV>
RemoveOldMeetingMessages            : True
AddNewRequestsTentatively           : True
ProcessExternalMeetingMessages      : False
DefaultReminderTime                 : 15
RemoveForwardedMeetingNotifications : False
Identity                            : domain.tld/BENUTZER/conf1

Alle DPM Freunde warten schon eine Weile händeringend auf dieses Update. Es sind die bisher erscheinenen Hotfixe eingearbeitet worden. Weiterhin können jetzt endlich mehrere Protection Groups dieselben Bänder verwenden, Tapelibraries können zwischen mehreren DPM geshared werden und zu guter Letzt können wir jetzt auch den Systemstate beim Server 2008 sichern.

x64:
http://www.microsoft.com/downloads/details.aspx?familyid=ad5cd1a2-9b87-4a2c-90a2-9dbaf1024310&displaylang=en&tm

Nach dem Update des Servers können die Agenten aktualisiert werden.

Die Nutzung eines Tapes für mehrere Protection Groups wird pro DPM Server aktiviert:

Set-DPMGlobalProperty -DPMServerName dpmserver -OptimizeTapeUsage:$true

Voraussetzung für die Sicherung des Systemstate auf Windows Server 2008 ist die Installation des Windows Backup Features. DPM verwendet, wie schon bei Server 2003, das Builtin Backup Tool des Betriebssystems für diesen Zweck. Auf der Betriebssystempartition erzeugt Windows Backup die Systemstate Sicherung, DPM sammelt die Dateien ein.
Im Gegensatz zum Windows Server 2003 wird beim 2008er das lokal erzeugte Backupfile nach dem Transport zum DPM Server gelöscht.

Lokal erzeugtes Backupfile während dem Backup:

Replikationbereich auf dem DPM Server:

Schon seit Jahren leistet das "printmig" Tool gute Dienste. Mit dem Windows Server 2008 ist diese Funktionalität in die Print Management Console (PMC) aufgenommen worden. Wenn man die PMC als eigenständige MMC aufruft hat man die Möglichkeit sich mit einem anderen Server zu verbinden, dort die Drucker zu exportieren und z.B. am lokalen System wieder zu importieren. Der Quellserver kann dabei ruhig ein 2003er sein.

Ein Feature mehr als bei "printmig" sieht man beim Import der Drucker. Die Veröffentlichung der Drucker im AD kann jetzt übernommen werden.

Auch geskriptete Aktionen, wie z.B. ein regelmäßiges Backup der Drucker per Taskplaner, sind möglich. Im Systemverzeichnis "%windir%\system32\spool\tools" findet man dazu das Tool "printbrm.exe".

Ein Backup wird z.B. mit "PrintBrm.exe -B -S \\server -F c:\prtbackup" durchgeführt.

Weitere Infos hier:

http://technet2.microsoft.com/windowsserver2008/en/library/19e4636d-478d-4d68-ba56-548ea31b90911033.mspx?mfr=true

Über einen Fileshare im Internet sind die Sysinternals Tools jetzt direkt aufrufbar. Einfach \\live.sysinternals.com\Tools eingeben und schon kann man alle Werkzeuge direkt starten oder kopieren.

Der erste SCCM 2007 Site Server ist erfolgreich auf SP1 aktualisiert. Wie schon aus den Betas gewohnt lief die Installation schnurstracks durch. Einige Hotfixe, die noch nicht offiziell downloadbar sind, werden durch den "Prerequisite Checker" angemahnt.

SCCM 2007 SP1:
http://www.microsoft.com/downloads/details.aspx?familyid=5aae62e8-4b7f-4af7-be01-aefaa4bf059a&displaylang=en&tm

SCCM 2007 inkl. SP1 Testversion:
http://www.microsoft.com/downloads/details.aspx?familyid=06d54615-8f0a-49ab-b195-5cd4fd76abdf&displaylang=en&tm

Die Versionshistorie meines SCCM sieht bisher so aus:

Versionsnummer   Release
--------------   -------
4.0.5135.0000    SMS V4 Beta1
4.0.5831.0000    SCCM 2007 RC
4.0.5931.0000    SCCM 2007 RTM
4.0.6086.1000    SCCM 2007 SP1 Beta1
4.0.6181.1000    SCCM 2007 SP1 RC
4.0.6221.1000    SCCM 2007 SP1 RTM

Essentials Business Server nennt sich das Teil und ist im RC Status angekommen. Bestehend aus 3 Server, x64 (bzw. 4 Server bei der Premium Edition) ist das Produkt tauglich für bis zu 300 Benutzer/Computer. EBS kann in eine bestehende AD Struktur eingebaut werden oder auch total neu aufgezogen werden. Die drei Server in meiner Testumgebung konnten recht einfach mit einem Assistenten eingerichtet werden.

Alle Schritte sind sehr schön beschrieben, man kann nicht viel falsch machen. Vier bis fünf Stündchen gehen schon ins Land bis die Sache steht. Danach hat man allerdings einige Produkte fertig konfiguriert am Start. In der Premium Edition wird der SQL Server als vierter Server noch dazukommen.

Die Installation erfolgte in virtuellen Maschinen auf einem Server 2008, Hyper-V. Einzige Besonderheit ist dabei, dass man die interne Netzwerkkarte des Security Server als "Legacy" konfigurieren muss weil sonst das Setup abschmiert. Alle anderen Netzwerkkarten der Server sind vom Typ "VMBus".

Die drei Server im Einzelnen:

EBS Security Server

• Windows Server 2008 Standard x64, zwei Netzwerkkarten (min. 2 GB RAM, meiner 800MB)
• Forefront TMG (Regelwerk komplett konfiguriert)
• Exchange 2007 Edge Transport (mit Attachement Filter :-) und Edgesync vom Messaging Server)

EBS Messaging Server

• Windows Server 2008 Standard, x64, Domain Controller (min. 4GB RAM, meiner 1GB)
• Exchange 2007 SP1 Standard
• Forefront Security for Exchange

EBS Management Server

Die Schaltzentrale ist der Management Server, dort läuft die zentrale EBS Konsole mit der man einen Gesamtüberblick über das System erhält.

• Windows Server 2008 Standard, x64, Domain Controller (min. 4 GB RAM, meiner 1GB)
• File/Print Server
• System Center Essentials 2007 (Windows Update, Softwareverteilung, Monitoring, Reporting)
• EBS Management Konsole (Benutzer/Mailboxen, Überblick, Lizenzierung)
• Forefront TMG Konsole

Kleiner Wermutstropfen an der Sache ist, dass es keine eingebaute Möglichkeit gibt die Server gemeinsam zu sichern. Empfehlung ist hier den Data Protection Manager 2007 auf einem weiteren Server in die Umgebung zu installieren.

Ich denke, letztendlich wird der Komplettpreis entscheiden ob das Produkt zum Einsatz kommt.
http://www.microsoft.com/windowsserver/essential/ebs/pricing.mspx

Quelle: MCT Exchange Newsgroup (Scott)

Folks,
Wanted to give you a heads up about a logic bug we've discovered in the SCR target truncation process.  Currently SCR target truncation will not happen if the TruncationLagTime > ReplayLagTime (even after the TruncationLagTime has passed).

This will affect capacity allocation on the log drives of the SCR target machines.

There are only two workarounds here:

• Delete the unneeded log files (this is somehat complex as you have to ensure they are beyond ReplayLagTime and TruncationLagTime).
• Ensure TruncationLagTime is less than ReplayLagTime (or disable it); note, to change the values for either parameter you need to disable SCR and then re-enable it using the new values.

This issue is expected to be fixed in a future rollup update.

• Autodiscover und Outlook Anywhere
• RPC/HTTPS
• ActiveSync
• SMTP

Nachdem wir letzte Woche im Windows Server 2008 Migrationsworkshop unseren letzten 2003 DC deinstalliert hatten, konnten wir auf den 2008 "Domain functional level" umschalten.

"Schnipp Schnipp, Trainer Trainer" kam danach von hinten, was bringt das denn? Ähm, kurz überlegt, klar, jetzt können die "fine grained password policies" eingerichtet werden und das SYSVOL kann auf DFS-R Replikation umgestellt werden. Mr. Superfix alias Hans D., den ich als Seminarteilnehmer begrüßen durfte, musste natürlich nochmal nachschauen und entdeckte hier noch ein weiteres interessantes Feature.

Im AD DS können nun die letzte erfolgreiche interaktive Anmeldung und erfolglose interaktive Anmeldungen protokolliert und gespeichert werden. Dazu ist folgende GPO notwendig, die auf die Domänen Controller angewendet werden muss:

Danach wird bei jeder interaktiven Anmeldung der aktuelle Zeitstempel im AD DS gespeichert. Erfolglose Anmeldungen werden gezählt und der Zeitstempel der letzten fehlgeschlagenen Anmeldung gespeichert. Alle Attribute werden repliziert, so dass die Information domänenweit zur Verfügung steht.

Zu guter Letzt kann diese Information nach einer erfolgreichen Anmeldung dem Benutzer angezeigt werden. Die obige GPO muss dazu für Vista Clients bzw. 2008 Server aktiviert werden.

Ich wollte sehen wie eine virtuelle Maschine mit dem Windows Server 2008 Hyper-V im Zusammenspiel mit dem Failover Cluster Feature hochverfügbar ausgelegt werden kann.

Leider ist mein Hardwarepark sehr eingeschränkt, so dass dieser Versuch ebenfalls virtuell ablaufen muss. Also sieht meine Zielumgebung folgendermaßen aus:

• 1 Server 2008 Enterprise (aus Blech) mit Hyper-V Rolle installiert
• 2 Server 2008 Servercore (VM1, VM2) mit Hyper-V und Failover Cluster Feature installiert
• 1 Server 2003 (VM3) mit iSCSI Target von Rocketdivision
• 1 Server 2008 (VM4) mit den Hyper-V und Cluster Admintools

Installation der Management Maschine (VM4)

Der Rechner wird nur verwendet um per Hyper-V MMC und später mit dem Failover Cluster Administrator die beiden Servervores remote zu administrieren.

• Installation der Remoteadmin Tools über "Add Features" (Failover Clustering Tools und Hyper-V Tools)

Installation der beiden Servercore VMs (VM1, VM2)

Nach der OS Installation wurden die Konfiguration mit der Servercore Configurator durchgeführt. Man tut sich damit wesentlich einfacher als rein mit der Kommandozeile. Die Schritte waren:

• Rechner benennen und in die Domäne joinen
• 2 Netzwerkkarten konfigurieren
• Hyper-V Rolle nachinstallieren (der Servercore lässt die Installation, im Gegensatz zum vollständigen Server, in einer VM zu)
• Hyper-V Netzwerke, von VM4 aus, auf den beiden Servercores identisch erzeugen

• Failover Cluster Feature installieren und Cluster vom VM4 aus erzeugen.

Vorbereiten des iSCSI Targets auf VM3

• Installation des Starwind iSCSI Targets auf VM3
• Erzeugen von zwei Diskimages die später von den Servercores als Quorum und als Platte für weitere VMs dienen sollen. Wichtig hier, dass man die Platten als "clustered" einrichtet, sonst kann später nur ein Server eine Verbindung zum Target aufbauen.

Servercores mit den Platten verbinden

Das war die eigentliche Herausforderung bei der Aktion. Im Vergleich zur GUI Konfiguration der iSCSI Verbindung ist das auf der Kommandozeile relativ schwierig. Es hilft das iSCSI Handbuch das hier heruntergeladen werden kann.

iSCSI Dienst starten (VM1, VM2)

• sc config msiscsi start= auto
• sc start msiscsi

iSCSI Target Portal verbinden (erst VM1, dann VM2)

• iscsicli qaddtargetportal 192.168.1.200
  
• Targets auflisten
  
  iscsicli listtargets
  
• Targets verbinden
  
  iscsicli qaddtarget <targetname> 192.168.1.200
  
• Anmelden an den Targets (der Einfachheit halber ohne Authentifizierung)
  
  iscsicli qlogintarget <targetname>
   
• Persistente Verbindung zum Target einrichten (damit auch nach einem Reboot die Verbindung wieder hergestellt wird)
  
  iscsicli PersistentLoginTarget <targetname> T * * * * * * * * * * * * * * * 0
   
  (15 x *, Details siehe iSCSI Users Guide)
• Die Ansicht auf dem Target sieht nun folgendermaßen aus
  

Platten Partitionieren und Formatieren (nur VM1)

Einige Sekunden nach dem Login ans Target sind die Festplatten verfügbar und können vorbereitet werden. Auf den Servercore tauchen die beiden Platten als disk1 und disk2 auf.

diskpart

select disk 1
online disk
attribute disk clear readonly
create partition primary
assign letter=q
format quick

select disk 2
online disk
attribute disk clear readonly
create partition primary
assign letter=r
format quick

Jetzt sind zwei Platten für den Cluster verfügbar. Q: soll als Quorum dienen und R: als Ablage für VMs (vhd und vmc Dateien).

Platten in den Cluster aufnehmen (von VM4 aus)

Mit dem Punkt "Storage - Add Disk" werden die beiden Platten dem Cluster zugeordnet.

Das Betriebssystem sieht die beiden Platten dann so:

Die Quorumdisk wird über "Configure Cluster Quorum Settings" definiert.

Virtuelle Maschine erzeugen und clustern (von VM4 aus)

Vom Management Server aus kann jetzt eine virtuelle Maschine erzeugt werden. Als Ablage für die virtuelle Festplatte und die Konfigurationsdatei wird Laufwerk R:\VM gewählt. Dazu muss die Hyper-V Adminkonsole mit dem Servercore verbunden werden auf dem gerade die R:\ Platte online ist.

Jetzt kann diese VM mit dem Cluster hochverfügbar eingerichtet werden. Dazu wird eine neue Clustergruppe vom Typ "Virtual Machine" angelegt.

Danach sieht die Clustergruppe für die VM so aus:

In diesem Zustand kann die VM jetzt hin und her geschalten werden bzw. geht das automatisch wenn ein Clusterknoten ausfällt. Man kann auch aus dem Failover Cluster Manager über die Funktion "Manage Virtual Machine" direkt die Hyper-V Admin Konsole aufrufen und wird dabei direkt zum aktiven Knoten verbunden.

Zum Schluss kommt der Wermutstropfen. Diese virtuelle Maschine kann leider nicht eingeschaltet werden :-( Sie läuft ja als virtuelle Maschine in einer anderen virtuellen Maschine. Aber als Demonstrations- und Lernobjekt ist diese Konstruktion sehr gut geeignet.

Nach der Migration der Domain Controller auf Windows Server 2008 kann die SYSVOL Replikation dem DFS-R Dienst übertragen werden. Der "File Replication Service, FRS" der dies seither durchgeführt hat kann danach abgeschaltet werden.

Die Vorgehensweise ist in einem fünfteiligen Artikel hier, hier, hier, hier und hier sehr genau und mit vielen weiteren Details beschrieben. Nach dem Lesen der Artikelfolge schien mir die Vorgehensweise recht aufwendig. Wenn man den Vorgang aber rein auf die dazu notwendigen Schritte reduziert, ist die Migration vom "FRS" zum "DFS-R" relativ übersichtlich.

Insgesamt sind drei Schritte notwendig, "PREPARE", "REDIRECT" und "ELIMINATE". Alle Aktionen werden mit dem Kommandozeilenwerkzeug "dfsrmig.exe" durchgeführt.

Bevor man loslegt muss geprüft werden ob die AD und Sysvol Replikation fehlerfrei funktioniert. Ebenfalls muss vorher die Domäne in den "Windows Server 2008 Domain Functional Level" hochgestuft werden. Alle Aktionen werden auf dem PDC Emulator durchgeführt.

PREPARE

In der "Prepare" Phase wird das SYSVOL Verzeichnis nach "SYSVOL_DFSR" dupliziert. D.h. ab jetzt wird für die Übergangsdauer der doppelte Speicherplatz für den Inhalt des SYSVOL Verzeichnis beansprucht. Eine ständige Synchronisation der beiden SYSVOLs erfolgt nicht.

dfsrmig /setglobalstate 1

Nachdem die "prepare" Phase eingeleitet wurde, wird das SYSVOL Verzeichnis auf dem PDC Emulator nach SYSVOL_DFRS kopiert, und von dort per DFS-R zu den anderen DC repliziert. Bis das geschieht kann bis zu einer Stunde vergehen, DFS-R liest ja alle Stunde seine Konfiguration aus dem AD. Der Vorgang kann jeweils pro DC mit "dfsrdiag pollad" beschleunigt werden.

Ob alle DC den "prepare" mitbekommen haben kann man folgendermaßen prüfen.

dfsrmig /getglobalstate

Hier das original (grün) und das duplizierte SYSVOL Verzeichnis (rot).

Die SYSVOL Freigabe zeigt weiterhin auf das alte SYSVOL Verzeichnis. "FRS" repliziert das alte und "DFS-R" das neue SYSVOL Verzeichnis. Nicht wundern, laufende Änderungen am alten und jetzt noch produktiven SYSVOL Verzeichnis werden nicht zum neuen SYSVOL Verzeichnis übertragen.

Der Abschluss der "prepare" Phase kann folgendermaßen geprüft werden.

dfsrmig /getmigrationstate

REDIRECT

In der "redirect" Phase wird der Inhalt des alten SYSVOL Verzeichnis mit dem neuen SYSVOL Verzeichnis synchronisiert und danach die SYSVOL Freigabe auf das SYSVOL_DFSR Verzeichnis übertragen.

dfsrmig /setglobalstate 2

Der Umzug der SYSVOL Freigabe kann mit "net share" geprüft werden.

Ab jetzt sind das neue SYSVOL Verzeichnis und Freigabe produktiv.

ELIMINATE

Im letzten Schritt werden die alten SYSVOL Daten entfernt und der Vorgang abgeschlossen. Eine Rückkehr zum "FRS" ist dann nicht mehr möglich.

dfsrmig /setglobalstate 3

Wieder kann der Abschluss dieser Phase geprüft werden.

dfsrmig /getmigrationstate

Das alte SYSVOL Verzeichnis wird von der Festplatte gelöscht. Man sollte deswegen nicht vor lauter Neugier einen Windows Explorer in dem Verzeichnis offen haben, sonst schlägt dieser Schritt fehl.

Ebenfalls protokolliert jeder DC den Abschluss mit dem Event "8019" im Eventlog der "DFS-R Replication"

Die SYSVOL Migration zum DFS-R ist damit abgeschlossen. Alles in Allem ist der Vorgang nicht sonderlich kompliziert. Man sollte sich, und vor allem den DC, genügend Zeit lassen und vor, zwischen und nach den einzelnen Schritten den Zustand genau prüfen.

Ab jetzt replizieren die SYSVOL Daten innerhalb einer Site fast in Echtzeit :-)

In einigen "spezielleren" Umgebungen möchte man nur bekannten MAC Adressen ein IP Adresse zuteilen. Normalerweise kommt man sofort auf die Idee mit Reservierungen zu arbeiten. Nur muss man dort jeder MAC Adresse eine feste IP zuteilen. Schön wäre doch, wenn man einen Pool von MAC Adressen definieren könnte der dann vom DHCP Server mit dynamischen Adressen versorgt wird.

Und das geht sogar. Man braucht dazu eine "Callout" DLL die eine Textdatei mit erlaubten oder verweigerten MAC Adressen gefüllt wird. Die DLL (s. u.) arbeitet entweder mit einer Positivliste (ALLOW) oder einer Negativliste (DENY), nicht beides.

Die Konfiguration läuft folgendermaßen ab:

• Download der DLL inkl. Doku von: http://blogs.technet.com/teamdhcp/archive/2007/10/03/dhcp-server-callout-dll-for-mac-address-based-filtering.aspx
• Nach der Installation liegt die Doku in \windows\system32\SetupDHCPMacFilter.rtf und ebenfalls die DLL "MacFilterCallout.dll".
• Jetzt erzeugt man einige Registryschlüssel in HKLM\System\CCS\Services\DHCP\Parameters. Hier meine:
  
   
  
• Dann erzeugt und füllt man die Konfigdatei mit den MAC Adressen. Bei mir die "calloutmaclist.txt". In diesem Beispiel bekommen nur 2 MAC Adressen eine IP Adresse.
  
   
  
• Jetzt muss man den DHCP Service neu starten.
  

Der DHCP Server protokolliert, in den per Registry konfigurierten Logfiles, mit. Im Folgenden zwei Beispiele:

• Ein DHCP Client möchte eine IP Adresse und bekommt keine, weil die MAC Adresse nicht in der Konfigurationsdatei auftaucht.
  
  
  
• Die MAC Adresse wurde jetzt in die Konfigurationsdatei aufgenommen und die IP Adressvergabe ist erfolgreich.
  
   

Nach jeder Änderung der Konfigurationsdatei muss der DHCP Service neu gestartet werden.