faq-o-matic.net

Active-Directory-Replikation im Detail

Philipp Föckeler — Tue, 31 Aug 2010 08:19:00 +0000

Dieser Artikel soll einen etwas tieferen Einblick in die Replikation zwischen Active-Directory-Domänencontrollern geben. Diese Replikation läuft immer dann ab, wenn sich Änderungen an Verzeichnisobjekten und deren Attributen ergeben haben. Grundsätzlich lassen sich über die AD-Replikation folgende wichtige Grundaussagen treffen:

Die Replikation wird im Multimasterbetrieb durchgeführt, d.h. Änderungen können von jedem Domänencontroller ausgelöst werden, der die betreffende Replica (z.B. den Inhalt einer AD-Domäne) im Read/Write-Modus speichert. Domänen-Controller, die nur eine Read-Only-Kopie von bestimmten Replicas haben, sind entweder Global Catalogs oder RODCs.
Domänencontroller benutzen für die Replication ein Store-And-Forward Prinzip: Wenn bei einer Replikation festgestellt wurde, dass die Daten der eigenen Replicas geändert werden müssen, so werden danach diese Änderungen den anderen Replikations-Partnern mitgeteilt.
Wer mit wem synchronisiert, wird durch die Replikationstopologie bestimmt – diese ergibt sich aus der Anordnung der AD-Sites, Site-Links und Platzierung der DCs innerhalb einer Site. Welche DCs tatsächlich miteinander Kontakt aufnehmen, kann manuell gesteuert werden oder auch automatisch ermittelt werden. Dies übernehmen dann die Module ISTG (Intersite Topology Generator) und KCC (Knowledge Consistency Checker).
Die Initiierung einer Replikation wird durch den empfangenden Domänencontroller ausgelöst ("Pull Replikation")
Die Replikation wird (seit Windows 2003) auf Attribut-Ebene durchgeführt, d.h. es werden bei Änderungen an Objekten nur die Daten der betroffenen Attribute repliziert und nicht ganze Objekte. Allerdings: Es werden stets ganze Attribute übertragen, auch wenn es sich dabei um ein Multivalue-Attribut mit sehr vielen Array-Werten handelt. Eine Ausnahme bilden so genannte Linked Values, verlinkte Atribute, die auf andere Objekte verweisen. Hier können bei Änderungen tatsächlich nur einzelne Array-Werte eines Attributes repliziert werden – zum Glück, denn Gruppenmitgliedschaften sind ein Beispiel für Linked Values, und so muss beim Hinzufügen eines neuen Mitglieds zu einer Gruppe mit 2500 Mitgliedern nur der Wert für das neue Mitglied übertragen werden und nicht das gesamte member-Attribut. Diese Technik wird Linked Value Replication (LVR) genannt, aber dazu später mehr.
Bei Replikationskonflikten (ein Attribut eines bestimmten Objektes wird auf zwei verschiedenen Domänencontrollern „relativ zeitgleich“ geändert) werden Konflikte zuverlässig aufgelöst, wobei mehrere Kriterien herangezogen werden. Diese spezielle Art der Konfliktauflösung sollten wir uns noch genauer anschauen, denn hier lauert die eine oder andere Überraschung. Für die Konflikt-Auflösung benötigen die Domänencontroller z.B. seltsamerweise meist nicht einmal eine Synchronisation Ihrer Systemzeit (wobei diese Zeitsynchronisation in gewissen Grenzen aus anderen Gründen wichtig ist und auch durchgeführt wird – z.B. wegen Kerberos!).

Gerade die letzten beiden Punkte sollen in diesem Artikel etwas näher geklärt werden: Wie schaffen es die Domänencontroller zu ermitteln, dass es im Kontakt zu anderen DCs etwas zu replizieren gibt, und wie finden sie heraus, welche Werte genau repliziert werden, auch wenn sich um einen turbulenten Multimasterbetrieb handelt?

Replikations-Vektoren und Metadaten

Dafür müssen wir zuerst einmal einen genauen Blick auf die wichtigsten LDAP-Attribute werfen, die im technischen AD-Betrieb für die Replikation verwendet werden. Dies wären zuerst einmal die zwei wichtigen Werte, die ein Domänencontroller für jede Replica speichert, die er verwaltet:

Der Highwatermark Vector
Der UpTo-Date Vector (oft auch "Up-To-Dateness-Vector" genannt)

Außerdem werden für jedes einzelne Objekt folgende Daten gespeichert:

Die Update Sequence Nummer (USN) im Moment der Erzeugung des Objektes: uSNCreated
Die Update Sequence Nummer (USN) vom Moment der letzten Änderung des Objektes: uSNChanged
Diverse Metadaten für jedes Attribut, das zwischen DCs repliziert wird (das ist nicht bei allen Attributen der Fall!). Dies umfasst die Uhrzeit und USN, zu der das Attribut in der eigenen Datenbank erzeugt/geändert, und zusätzlich auch die ID und die entsprechende USN des DCs, an dem die Änderung ursprünglich ausgelöst wurde (dies ist der so genannte "Originating DC"). Außerdem wird eine Versionsnummer hochgezählt, die bei jeder Änderung des Attributes um eins erhöht wird. All dies zusammen wird oft auch als "Stamp" bezeichnet.

Die Vektoren sind im Prinzip ebenfalls Long-Integer-Zähler, die hochgezählt werden und eine fortlaufende Nummerierung des AD-Datenbank-Zustandes darstellen. Diese Zähler werden dann bei Erzeugung oder Änderung von Objekten in deren USN-Nummern gespeichert. Im folgenden Video wird der Gebrauch dieser Werte genau sichtbar:

Video 1: http://www.youtube.com/watch?v=SDPJVMPAcDw

Deutlich wird: Jeder DC führt seine eigene Nummerierung der Vektoren und dementsprechend auch eigene USN-Werte für alle Objekte und Attribute in seiner Datenbank. Nicht deutlich wird hingegen, wie denn diese Werte nun verwendet werden, um diejenigen Attribute zu ermitteln, die tatsächlich zu replizieren sind. Dafür schauen wir uns den letzten Replikationsvorgang des Videos nochmals im Detail an: Auf DC2 wurden gerade die Attribute für Passwort und EMail-Adressierung geändert. DC1 löst nun die Replikation aus:

Video 2: http://www.youtube.com/watch?v=NVOdnVBAC00

Um das interne Entscheidungsverfahren für die inkrementelle Replikation noch mehr zu verdeutlichen, soll dem Szenario ein weiteres Detail hinzugefügt werden: Es wurde noch nicht zwischen DC1 und DC2 repliziert, auf DC2 wurden gerade die Attribute für Passwort und EMail-Adressierung geändert. Zusätzlich dazu wird nun ein Attribut auf einem anderen DC geändert. Die Änderung ist unseren beiden DCs bekannt. Wie merkt DC2 nun, dass genau diese Änderung in der nächsten Replikation NICHT zu DC1 gesendet werden muss? Schauen wir uns dafür wieder ein Video an.

Video 3: http://www.youtube.com/watch?v=bDFNoW2U03c

Eigentlich ganz simpel: Anhand der Tabellen mit den Up-To-Date-Vektoren aller DCs – und anhand der Metadaten für jedes Objekt. Diese werden im Attribut " msDS-ReplAttributeMetaData" gespeichert. Mit einem entsprechenden LDAP Browser (hier im Beispiel wird LEX – The LDAP Explorer verwendet) kann man sich diese Attribute anzeigen lassen, es handelt sich um einen Multivalue mit XML-Textinhalt:

Wie man in der Detailansicht des Stamps für das Attribut "displayName" sehen kann, sind alle Metadaten aufgeführt: Die Version, der Zeitstempel der letzten Änderung, der Name und die GUID des DCs, der die letzte Änderung ausgelöst hat (der DC heißt in diesem Beispiel "KAILASH") , die USNs der letzten Änderung, sowohl lokal als auch vom ändernden DC. Alles ein bisschen unübersichtlich, aber im Prinzip gut erkennbar. Wenn man genau hinschaut, sieht man etwa, dass die Metadaten nur für diejenigen Attribute vorhanden sind, die auch wirklich zwischen Domänencontrollern repliziert werden. Man wird z.B. keine Metadaten für das berühmte "lastLogon"-Attribut finden, das ja bekanntlich (? ) nicht zwischen DCs repliziert wird. Bei der genauen Durchsicht der Metadaten für das Attribut "unicodePwd" könnte man feststellen, wie oft bisher das Passwort des betreffenden Benutzers geändert wurde …

Wie schon vorher erwähnt, gibt es für Linked Values wie z.B. "member/memberOf" eine Besonderheit, bei der alle Metadaten nicht nur für ganze Attribute, sondern für jeden einzelnen Wert im Attribut gespeichert werden. So braucht bei einer Änderung einer Gruppenmitgliedschaft nicht das gesamte "member"-Attribut mit evtl. hunderten oder tausenden Mitgliedern repliziert zu werden. Man sieht für solche Linked Values im LDAP-Browser ein eigenes Metadata-Attribut "msDS-ReplValueMetaData", bei dem der Stamp noch etwas komplexer aufgebaut ist:

Auflösung von Replikationskonflikten

Replikationskonflikte können in folgenden Szenarien auftreten – wir schauen uns am besten auch gleich an, wie dann der entstehende Konflikt von der Active-Directory-Replikation gelöst wird:

1. Auf einem Domänencontroller wird ein Container (z.B. eine OU) gelöscht, während auf einem anderen Domänencontroller genau in diesem Container ein neues Objekt erstellt oder ein bestehendes dorthin verschoben wird.

In diesem Fall geht das neue Objekt in dem gelöschten Container nicht verloren, sondern wird im System-Container "LostAndFound" gespeichert. Diesen Container sieht man beispielsweise, wenn man im "AD Users and Computers" Tool die „Advanced View Option“ aktiviert.

Wenn Sie einen solchen Replikationskonflikt einmal selbst beobachten wollen, dann brauchen Sie zwei Domänencontroller in der gleichen Domäne und eine leere Test-OU. Dann können sie folgendes VBScript ausführen:

' hier die eigenen DCs eintragen:
dc1 = "192.168.0.66"
dc2 = "192.168.0.67"

'hier den Pfad zu einer vorhandenen leeren Test-OU eintragen:
ouPath = "ou=reptest,dc=ldapexplorer,dc=com" 

Set ou1 = GetObject("LDAP://" & dc1 & "/" & ouPath)
Set ou2 = GetObject("LDAP://" & dc2 & "/" & ouPath)

ou1.DeleteObject(0) 'OU wird auf DC1 gelöscht !

Set user = ou2.Create("user", "cn=repUser") 'User wird auf DC2 erstellt
user.sAMAccountName = "repUser"
user.SetInfo

Das Ergebnis: Der neu erstellte repUser erscheint im SystemContainer "LostandFound", anhand seiner "lastKnownParent"-Eigenschaft sieht man sogar, dass er ursprünglich in einem Container namens "repTest" erstellt werden sollte:

By the way: Der verwendete LDAP Browser ist auch hier LEX – The LDAP Explorer.

2. Auf zwei Domänencontrollern wird quasi gleichzeitig dasselbe Attribut eines Objektes in zwei verschiedene Werte geändert.

In diesem Fall müssen die Domänencontroller entscheiden, welche der beiden Änderungen "gewinnt". Normalerweise würde man denken, dass die zeitlich zuletzt ausgelöste Attribut-Änderung sich durchsetzt, dies ist jedoch nicht immer der Fall. Die beiden DCs vergleichen nämlich die Attribut-Versionen im Metadaten-Stamp (diese Versionsnummer wird als Zähler bei jeder Änderung um eins erhöht). Bei einem vorliegenden Konflikt für ein bestimmtes Attribut setzt sich der DC durch, bei dem die höchste Attribut-Version vorhanden ist. Erst wenn die Attributversion auf beiden Seiten gleich ist, dann gewinnt der DC, der das Attribut zuletzt geändert hat. Sollte der Zeitstempel der Änderung ebenfalls bis auf die Sekunde gleich sein, dann gewinnt der DC, dessen GUID-String alphabetisch gesehen "kleiner" ist (also bestimmt dann quasi der Zufall die Replikation).

Mit diesen Kenntnissen können wir einen seltsamen Fall konstruieren: Wir ändern auf DC1 sehr schnell hintereinander mehrmals ein Attribut eines Users. Dadurch erhöhen wir die Metadaten-Version für dieses Attribut um mehrere Schritte. Dann ändern wir das gleiche Attribut auf DC2, jedoch nur ein einziges Mal. Danach führen die beiden DCs eine normale AD-Replikation aus. Das Ergebnis: Obwohl die Änderung auf DC2 zeitlich die letzte Änderung war, besitzt danach das Attribut den Wert, der zuletzt auf DC1 geschrieben wurde!

Wenn Sie diesen Effekt selbst beobachten wollen, dann brauchen Sie zwei Domänencontroller in der gleichen Domäne und einen Test-User. Dann können sie folgendes VBScript ausführen:

' hier die eigenen DCs eintragen:
dc1 = "192.168.0.66"
dc2 = "192.168.0.67"
'hier den Pfad zu einem vorhandenen Test-User eintragen
testUser = "cn=repUser,dc=ldapexplorer,dc=com" 

Set user1 = GetObject("LDAP://" & dc1 & "/" & testUser)
Set user2 = GetObject("LDAP://" & dc2 & "/" & testUser)

value1 = "DC1 - " & now 'Attribut schreiben auf DC1 und etwas warten
user1.displayName = value1
user1.SetInfo
WScript.Sleep 1000

value2 = "DC1 - " & Now 'Attribut nochmal ändern auf DC1 und etwas warten
user1.displayName = value2
user1.SetInfo
WScript.Sleep 1000

value3 = "DC2 - " & now 'Attribut auf DC2 ändern
user2.displayName = value3
user2.SetInfo

WScript.Echo value1 'nochmals alle drei Werte anzeigen
WScript.Echo value2
WScript.Echo value3

Wenn Sie nun nach einer Weile das Attribut wieder überprüfen (nach einer erfolgten Replikation; sind beide DCs innerhalb einer Site, geschieht die Replikation sehr schnell, zwischen Sites anhand der konfigurierten Intervalle), werden sie feststellen, dass nicht der dritte Wert gewonnen hat, sondern der zweite! Durch die zweimalige Änderung haben wir auf dem ersten DC die Metadatenversion künstlich erhöht…. Dieser seltsame Effekt sollte jedoch in der Praxis selten eine Rolle spielen.

3. Auf zwei Domänencontrollern werden quasi gleichzeitig zwei Objekte mit gleichem Namen erzeugt, oder es werden zwei verschiedene Objekte in den gleichen Namen/LDAP-Pfad umbenannt – oder eine Mischung aus beiden.

Hier entscheiden die beteiligten DCs zuerst einmal, welche Seite sich durchsetzt. Es gelten hier einfach die gleichen Regeln wie bei einem Attribut-Konflikt, und das entscheidende Attribut für den Check ist das namensgebende, also bei Organizational Unit-Objekten ist es das "ou"-Attribut, bei den meisten anderen das "cn"-Attribut.

Wenn also zwei verschiedene Objekte auf den DCs entstehen, die jedoch den gleichen Distinguished Name haben, dann wird geprüft, welche Seite im "ou"/"cn" Attribut eine höhere Versionsnummer hat, sind die Versionen gleich, entscheidet der Timestamp, danach das Los. Das Objekt, das bei diesem Wettkampf verloren hat, wird trotzdem erstellt, jedoch mit dem Zusatz "\0ACNF:<GUID>" im Objektnamen (das \0A steht für ein Zeilenumbruchszeichen und kann meist nicht korrekt dargestellt werden …). Es gibt dann zwei Objekte, und man kann im Nachhinein noch entscheiden, welches Objekt tatsächlich das richtige war und weiterverwendet werden soll.

' hier die eigenen DCs eintragen:
dc1 = "192.168.0.66"
dc2 = "192.168.0.67"
'hier den Pfad zu einer vorhandenen leeren Test-OU eintragen
ouPath = "ou=reptest,dc=ldapexplorer,dc=com" 

Set ou1 = GetObject("LDAP://" & dc1 & "/" & ouPath)
Set ou2 = GetObject("LDAP://" & dc2 & "/" & ouPath)

Set user1 = ou1.Create("user", "cn=repUser") 'User wird auf DC1 erstellt
user1.sAMAccountName = "repUser"
user1.description = "Erstellt auf DC1"
user1.SetInfo

Set user2 = ou2.Create("user", "cn=repUser") 'User wird auf DC2 erstellt
user2.sAMAccountName = "repUser"
user1.description = "Erstellt auf DC2"
user2.SetInfo

Das Ergebnis (warten Sie die nächste Replikation ab): Der neu erstellte repUser erscheint zweimal, eine Version ist mit dem "CNF"-Zusatz gekennzeichnet:

Windows 2008 R2 SP1-Beta: USV entkoppeln

Nils Kaczenski — Wed, 25 Aug 2010 08:18:35 +0000

Ein Hinweis in den Installationshinweisen zum Service Pack 1 (Beta) für Windows Server 2008 R2 geht etwas unter – das könnte ein Problem verursachen. Daher weisen wir hier noch einmal darauf hin:

Vor der Installation des SP1 sollte man eine evtl. am Server angeschlossene USV (Unterbrechungsfreie Stromversorgung) vom Server abstöpseln. Der Grund: Das SP1 versucht bei der Installation alle angeschlossenen Geräte zu erkennen. Im Falle von seriell angeschlossenen USVs schlägt dies bisweilen fehl und führt zu Abstürzen.

Ob diese Einschränkung in der endgültigen Fassung des SP1 noch gelten wird, ist derzeit unklar.

Die Ultra Lite Touch Installation

Igwemo Pielczyk — Fri, 20 Aug 2010 07:33:11 +0000

Wie im letzten Artikel erwähnt, können wir uns mit dem Wissen, das wir bis dato gesammelt haben, eine "Ultra Lite Touch Installation" zusammenstellen, bei der nur noch ganz wenige Eingriffe durch den User oder Supportmitarbeiter erfolgen müssen. Dazu passen wir uns die bootstrap.ini und die customsettings.ini soweit an, dass wir nur mit Hilfe des MDT2010 ohne Microsoft System Center Configuration Manager (SCCM) eine quasi Zero Touch Installation bauen können. Dieses Szenario eignet sich für den Small-Business-Bereich bei ca. 30-500 PCs, weil wir so die Kosten von ca. 1200€ pro Lizenz für den Microsoft System Center Configuration Manager plus die benötigten CALs gespart haben.

Es spielt keine Rolle, ob wir ein Thin, Thick oder Hybrid Image verteilen wollen, wichtig ist nur dass wir ein Image pro Unternehmen haben, um den administrativen Aufwand so gering wie möglich zu halten. In diesem konkreten Beispiel erstellen wir eine bootfähige Deployment DVD die bereits das fertige Image enthält.

Diese Einstellung funktionieren natürlich auch wenn man von einem Deployment Share aus bootet, nur dann bitte nicht vergessen die bootstrap.ini mit den Netzwerk Anmeldedaten zu bestücken

Die customsettings.ini für die Ultra Lite Touch Installation

[Settings]
Priority=Default
Properties=MyCustomProperty

[Default]
OSInstall=Y
_SMSTSOrgName=IPCtec Windows 7 Deployment
SkipAppsOnUpgrade=YES
SkipCapture=YES
SkipAdminPassword=YES
AdminPassword=kennwort
SkipProductKey=YES
SkipDeploymentType=YES
SkipDomainMembership=YES
SkipUserData=Yes
UserDataLocation=NONE
SkipTaskSequence=YES
TaskSequenceID=win7 (hier die ID eurer Task Sequence eintragen)
SkipComputerName=NO
SkipPackageDisplay=YES
SkipLocaleSelection=YES
UILanguage=de-DE
UserLocale=de-DE
KeyboardLocale=0407:00000407
SkipTimeZone=YES
TimeZone=110
TimeZoneName=W. Europe Standard Time
SkipApplications=YES
Applications001={5e6d9ca1-9d29-490c-b3a9-efb642d949eb}
Applications002={783d6cb7-802e-4ed6-ac7d-6df9db7fc71d}
SkipBitLocker=YES
SkipSummary=YES

Die bootstrap.ini für die Ultra Lite Touch Installation

[Settings]
Priority=Default

[Default]
SkipBDDWelcome=YES

Mit diesen Einstellungen braucht man lediglich die den Computernamen zu von Hand einzutragen, der Rest läuft automatisch wie von Geisterhand

Noch eine kleine Anmerkung:

Applications001={5e6d9ca1-9d29-490c-b3a9-efb642d949eb}
Applications002={783d6cb7-802e-4ed6-ac7d-6df9db7fc71d}

Hier müssen natürlich die GUIDs der Software eingetragen werde,n die man mit verteilen möchte. Alternativ dazu kann man auch ein Software Package erstellen und dies in der Task Sequence verteilen lassen.

Diese Konfiguration funktioniert auch bei einer Installation aus einem einem Deployment Share über das Netzwerk und nicht nur von DVD.

Noch mehr Tips und Tricks zum Thema Windows 7 Deployment unter http://www.eyeonwin.de, dem MDT 2010 und Windows 7 Deployment Blog

Seminar: Hyper-V sicher und sauber

Nils Kaczenski — Wed, 18 Aug 2010 16:59:00 +0000

Im September und Oktober 2010 werde ich für heise Events an drei Terminen einen Workshop zu Hyper-V halten. Titel: “Hyper-V sicher und sauber – Microsofts Virtualisierung professionell einsetzen”. Im Mittelpunkt stehen Sicherheit und Zuverlässigkeit beim Betrieb virtueller Serverumgebungen mit Hyper-V. Aus der Ankündigung:

Microsoft hat sich mit Hyper-V 2.0 als dritter Anbieter für ernst zu nehmende Server-Virtualisierung neben VMware und Citrix XenServer etabliert. Doch obwohl außen "Windows" draufsteht, braucht die Lösung einige Sorgfalt, damit sie die Anforderungen der Anwender erfüllt und Angriffen widersteht.

Der Workshop beleuchtet Fragen der Sicherheit in der Einrichtung und dem Betrieb virtueller Umgebungen mit Windows Server 2008 R2, gibt Hinweise für das Projektdesign zur Einführung von Virtualisierung und vermittelt Praxiserfahrungen im Umgang mit Hyper-V 2.0.

Die Termine:

15. September 2010, Hamburg
29. September 2010, Köln
06. Oktober 2010, Stuttgart

Folgende Agenda plane ich für den Workshop ein:

Hyper-V und Sicherheit: Was viele übersehen
- Innen, außen und irgendwo dazwischen: VMs und Netzwerke
- Sandboxes sind keine Spielplätze: Sicherheit erfordert Disziplin
- Klone und Zombies: „Bad Guys“ selbst gemacht
Prüfen und planen: Damit das Projekt gelingt
- Warum virtualisieren wir eigentlich?
- Mythen und Irrtümer erkennen
- Der virtuelle Server: Neu oder gebraucht?
- Hinter der Fassade: Komplexe IT
Sizing und Setup: Darf’s etwas mehr sein?
- Hyper-V-Sizing: Grundlagen
- Speicher und Netzwerk passend ausbauen
- Clustering: Im Dutzend billiger
- Werkzeugkoffer: Den Betrieb im Griff

Nähere Daten und die Anmeldung finden sich bei der iX:

[iX-Konferenz: Hyper-V sicher und sauber]
http://www.ix-konferenz.de/konf.php?konferenzid=106

Exchange 2010: Probleme mit Update Rollup 4

Nils Kaczenski — Tue, 17 Aug 2010 06:12:00 +0000

Bereits bei mehreren Kunden ist es vorgekommen, dass das Update Rollup 4 für Exchange 2010 nicht korrekt installiert wurde. Bei anderen scheint es erfolgreich zu sein, aber hinterher ist Exchange nicht mehr erreichbar …

Tatsächlich scheint es so zu sein, dass das Update die Exchange-Dienste nicht nur beendet, sondern gleich deaktiviert. In manchen Situationen bricht das Update dann ab, bevor es die Dienste wieder einschaltet. Meistens hilft es hier, die Dienste manuell wieder zu aktivieren und zu starten.

Einige Kunden berichten, dass ein erneuter, manueller Installationsversuch des Update Rollup 4 erfolgreich verlief. Ein weiteres Problem: In einzelnen Fällen bietet Windows Update bzw. WSUS nach der erfolgreichen Installation des Update Rollup 4 plötzlich das Update Rollup 3 wieder zur Installation an.

Tatsächliche Problemlösungen sind hierzu bislang nicht bekannt. Allerdings bringt Exchange ein PowerShell-Skript mit, das die Konfiguration der Dienste wiederherstellt: "servicecontrol.ps1 afterpatch". Das Skript befindet sich im Ordner \scripts des Exchange-Programmverzeichnisses.*

Es gibt im Internet einige Hinweise auf Abhilfe im Detail; hier ein interessanter (aus den Kommentaren zu http://msexchangeteam.com/archive/2010/06/17/455191.aspx):

Steen Kirkby said:

In my case OWA also got broken and it left all services disabled.
Solved it with:
Change all "Microsoft Exchange…." services back to Automatic Startup
(Microsoft Exchange POP3, IMAP4, Monitoring and Server Extension for Windows Server Backup are set to manual by default – you might want to keep them that way)
Change the following (non-"Microsoft Exchange") services back to Automatic Startup:
- IIS Admin Service
- Microsoft Search (Exchange)
- Remote Registry
- Windows Management Instrumentation
- World Wide Web Publishing Service
That got me up and running with UM, mail flow and Outlook clients connected, but OWA was still broken with the following symptoms:
When simply applying the Update Rollup 4 for Exchange 2010, you might end up with a blank logon screen at your CAS servers when you want to reach OWA.
When opening up the details of the error message, the following text is shown:
Message: Syntax error
Line: 1
Char: 1
Code: 0
URI: https://localhost/owa/14.0.702.0/scripts/premium/flogon.js
How to solve it?
Stop all "Microsoft Exchange…"
(In my case also: Backup Exec and Symantec Mail Security for Exchange)
Start an Administrative Exchange Management Shell
Type ii Exchange2010-KB982639-x64-en.msp
Close the Exchange Management Shell and finish the patch.

* Danke für den Hinweis an Wolfgang Sauer!

Festplatte fast voll? Per Skript Warnung verschicken

Karsten Moldenhauer — Mon, 16 Aug 2010 07:07:00 +0000

Als Administrator weiß man doch lieber vor den Nutzern, wenn etwas nicht mehr funktioniert. Noch besser ist natürlich, wenn man aufgrund einer rechtzeitigen Information ein sich androhendes Unheil abwenden kann. Und solange man noch einen funktionierenden E-Mail-Server hat, bietet sich dieser doch als Informant an.

Ein Problem hier ist meist das Fehlen von Überwachungstools, deren Konfiguration auf das zu überwachende Objekt oder die Wahl der richtigen Informationsweitergabe. Ein Eintrag in einem Logfile nützt mir beispielsweise nichts, wenn ich immer wieder mal nicht rechtzeitig reinschaue. Außerdem nutze ich als Admin doch lieber Automatismen, die mir einiges abnehmen.

Ein wiederkehrendes Thema ist das Volllaufen von Festplatten, ganz besonders gerne auch derjenigen, die Transaktionsprotokolle von Datenbanken beherbergen. Erscheint dann die Meldung „Kein Platz mehr auf Laufwerk X:“ zusammen mit „Übrigens, die Datenbanken sind deswegen auch angehalten worden“, ist das besonders ärgerlich.

Unter Windows (ab Windows 2003) kann mit einem VBSkript eine Kontrolle und Info erfolgen. Das Skript könnte über einen Task (zum Beispiel unter Windows Server 2008 R2 über die Aufgabenplanungsbibliothek einzurichten) regelmäßig gestartet werden und beim Unterschreiten einer Grenze per E-Mail warnen.

Aufbau des Skriptes

Nach der Definition von Konstanten zur besseren Auswahl beim Zusammenstellen der CDO-Nachricht werden über Variablen die Grenze und die Daten für den E-Mail-Aufbau festgelegt. Über die Funktion „Platzkontrolle“ können dann Laufwerke auf noch freien Speicherplatz geprüft und zuletzt mit Hilfe der Prozedur „CDOmail“ eine E-Mail verschickt werden. (Möchtet ihr die Funktion oder die Prozedur in anderen Skripten verwenden, so wären die von mir zur besseren Übersicht am Skriptanfang definierten dazugehörigen Variablen und Konstanten „mitzunehmen“.)

Die Idee zur CDOmail habe ich von http://www.msxfaq.de/code/sendcdomail.htm und Infos von http://www.paulsadowski.com/wsh/cdo.htm

Das VBSkript

Option explicit
Dim strIPdesSMTP, strBetreff, strAn, strAbsender, strAnhang, strBenutzer, strPasswort
Dim intGrenze, kritisch, strText
Dim fso, oDrive, strPlatz, vglGrenze
Dim oMessage
'Wo soll die E-Mail angeliefert werden?
Const cdoSendUsingPickup = 1 '…im Pickup-Verzeichnis des auf dem skriptausführenden Server laufenden SMTP-Dienstes
Const cdoSendUsingPort = 2 '…an einen SMTP-Server im Netzwerk
'Wie soll sich am SMTP-Server authentifiziert werden?
Const cdoAnonymous = 0 'keine Authentifizierung erforderlich am SMTP-Server
Const cdoBasic = 1 'dann muss strBenutzer und strPasswort angegeben werden
Const cdoNTLM = 2 'der das Skript ausführende Benutzer wird zur Anmeldung am SMTP-Server benutzt
strIPdesSMTP = "10.10.10.10" 'IP des SMTP-Servers eintragen
strBetreff= "Hier steht der Betreff"
strAn = "empf1@dom.de;empf2@dom.de"
strAbsender = "abs@dom.de"
strAnhang = "" 'Eventuell eine Datei mit vollständigem Pfad angeben
'für den Fall der Klartext-Authentifizierung (cdoBasic)
strBenutzer = "Domäne\username"
strPasswort = "geheim" ' Achtung: Wird hier ein Passwort benutzt, sollte das VB-Skript verschlüsselt werden
'Bei Unterschreiten welcher Grenze soll eine E-Mail versandt werden?
intGrenze = 2048 'in MB
kritisch = "Nein" 'Wird bei Unterschreiten der Grenze durch die Funktion Platzkontrolle auf Ja gesetzt
strText = "Noch vorhandener Platz auf den Laufwerken:" & vbcrlf
strText = strText & Platzkontrolle("C:\",intGrenze) & vbCrLf
strText = strText & Platzkontrolle("D:\",intGrenze) & vbcrlf
'Weitere Laufwerke prüfen? => Kommentarzeichen der nächsten beiden Zeilen entfernen
'strText = strText & Platzkontrolle("E:\",intGrenze) & vbcrlf
'strText = strText & Platzkontrolle("F:\",intGrenze) & vbcrlf
If kritisch = "Ja" Then
CDOmail strBetreff, strAbsender, strAn, strText, strAnhang
End if
Function Platzkontrolle(sLW,sLW_Warngrenze)
Set fso = CreateObject("Scripting.FileSystemObject")
Set oDrive = fso.getdrive(sLW)
strPlatz = oDrive.freespace
strPlatz = FormatNumber (strPlatz/1024^2,2)
vglGrenze = FormatNumber (sLW_Warngrenze,2)
If abs(vglGrenze)>abs(strPlatz) Then
kritisch = "Ja"
Platzkontrolle = "ACHTUNG: Auf " & sLW & " wurde die " & vglGrenze & " MB Grenze unterschritten. Noch " & strPlatz & " MB frei"
Else
Platzkontrolle = sLW & "OK. Noch " & strPlatz & " MB frei"
End if
Set oDrive = nothing
Set fso = nothing
End Function
Sub CDOmail(fBetreff,fAbs,fAn,fText,fAnhang)
Set oMessage = CreateObject("CDO.Message")
'Erzeugung der Nachricht
With oMessage
.Subject = fBetreff
.From = fAbs
.To = fAn
.TextBody = fText
If fAnhang<>"" Then
oMessage.AddAttachment fAnhang
End If
'Server Verbindungsdaten
.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/sendusing") = cdoSendUsingPort
.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/smtpserver") = strIPdesSMTP
.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/smtpauthenticate") = cdoNTLM
'Wird cdoBasic benutzt, die beiden folgenden Zeilen aktivieren
'.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/sendusername") = strBenutzer
'.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/sendpassword") = strPasswort
.Configuration.Fields.Update
.send
End With
Set oMessage = nothing
End Sub

Sparkassen-Sicherheit: Eine Reaktion

Nils Kaczenski — Mon, 16 Aug 2010 05:17:00 +0000

Vor einigen Tagen berichtete ich über ein IT-Sicherheitsproblem, das mir bei der Sparkasse Hannover aufgefallen war:

[faq-o-matic.net » IT-Sicherheit, der physische Layer und warum man auch Banken nicht trauen kann]
http://www.faq-o-matic.net/2010/08/07/it-sicherheit-der-physische-layer-und-warum-man-auch-banken-nicht-trauen-kann/

Wenige Tage später bekam ich nun einen Brief dazu von der Sparkasse Hannover, der mich positiv überraschte.

Ich zitiere die wesentlichen Passagen aus dem Original:

Durch Ihren Beitrag “IT-Sicherheit, der physische Layer und warum man auch Banken nicht trauen kann” bei faq-o-matic.net haben Sie uns auf eine Sicherheitslücke bei den SB-Geräten unserer provisorischen Filiale […] aufmerksam gemacht.

[…] Unser Sicherheitskonzept sieht selbstverständlich vor, dass Netzwerkschnittstellen in den Foyers unzugänglich verbaut werden. Dies ist hier nicht geschehen. Grundsätzlich sind die von Ihnen angesprochenen Penetrationsmöglichkeiten denkbar. Diverse weiterführende Sicherheitsmaßnahmen minimieren jedoch Sicherheitsrisiken im Netzwerk der Sparkasse Hannover.

Durch Ihren Hinweis konnten wir sofort reagieren und den Bereich am Montag zunächst provisorisch umschließen. Mittlerweile sind die Anschlussdosen […] unzugänglich gemacht worden.

Sie haben uns geholfen, besser zu werden. Danke!

Das nenne ich eine positive Reaktion in mehrfacher Hinsicht!

ice:2010 AD-Delegation – die Folien und Skripts

Nils Kaczenski — Sat, 14 Aug 2010 13:57:59 +0000

Hier ist der Download der Folien (PDF-Format) und der Demo-Skripts zu meiner Session “Active-Directory-Berechtigungen oder: Die Tücken der Delegation” bei der ice:2010 in Lingen.

Note: There is a file embedded within this post, please visit this post to download the file. Note: There is a file embedded within this post, please visit this post to download the file.

Es ist ice-Zeit!

Nils Kaczenski — Sat, 14 Aug 2010 09:16:25 +0000

Vor gut zwei Stunden hat die Community-Konferenz ice:2010 in Lingen begonnen. Gut 300 Teilnehmerinnen und Teilnehmer besuchen knapp 30 Vorträge. Das Wetter in Lingen zeigt sich von seiner besten Seite – wenn auch das Publikum nichts davon hat.

Live von der ice:2010 berichten viele Blogger – und die ice:wall, eine Twitterwall (Hashtag: #icelingen).

http://www.faq-o-matic.net/icewall/

SCVMM: VM aus der Datenbank entfernen

Nils Kaczenski — Thu, 12 Aug 2010 11:41:55 +0000

In einer speziellen Situation ergab sich die Anforderung, eine virtuelle Maschine unter Hyper-V aus der Verwaltungsdatenbank des System Center Virtual Machine manager 2008 R2 (SCVMM) zu entfernen. Die Konfigurationsdaten der VM in der Datenbank waren nicht mehr aktuell, und aufgrund dieser fehlerhaften Konfiguration weigerte sich SCVMM, irgendetwas mit der VM zu machen. Die virtuelle Maschine selbst lief aber fehlerfrei.

Das Problem: Bei der VM handelte es sich um den SCVMM-Server …

Der Hintergrund war eine schlecht geplante Aktion. Ein Admin hatte versucht, genau diese VM mit der “Speichermigration” auf ein anderes Clustervolume zu verschieben. Diese Speichermigration ist aber keine Live-Migration: Die VM setzt dabei für mehrere Minuten aus. Das wiederum führte natürlich dazu, dass der SCVMM-Dienst nicht mehr erreichbar war. Im Effekt schlug der Verschiebevorgang fehl.

Der VM selbst machte das nichts: Da der Vorgang eine Transaktion darstellt, war die VM hinterher noch an ihrem alten Platz und lief anstandslos weiter. Nur innerhalb der SCVMM-Datenbank war vermerkt, dass der letzte Vorgang fehlgeschlagen war. Die Konfigurationsdaten standen nun aber falsch in der Datenbank, denn sie zeigten auf den “neuen” Speicherort, an den die VM aber gar nicht verschoben worden war.

Hier war guter Rat etwas teurer. Die VM aus dem SCVMM zu löschen, funktionierte nicht: Zum einen löscht SCVMM dabei auch die VHD-Dateien von den Platten des Hosts. Zum anderen bricht der Vorgang natürlich ab, weil SCVMM die virtuelle Maschine beendet und in diesem Fall wieder den Kontakt zu seinem eigenen Dienst verliert …

Abhilfe schaffte der folgende KB-Artikel:

[You cannot delete a missing VM in SCVMM 2008 or in SCVMM 2008 R2]
http://support.microsoft.com/kb/983839/en-us

Dort steht ein anderes Szenario im Hintergrund: In dem Artikel sollen VMs mit dem Status “Missing” aus der Datenbank entfernt werden, welcher durch andere fehlerhafte Vorgänge entstehen kann. Dazu ist ein SQL-Skript notwendig, das direkt in der VMM-Datenbank die zugehörigen Einträge löscht. Operation am offenen Herzen also …

Ein Blick auf das SQL-Skript nährte die Hoffnung, dass es auch in diesem Fall einsetzbar ist. Es löscht alle VMs aus der Datenbank, die den Status “220” haben (Missing). In meinem Fall war der Status “107”, wie ich durch einen Blick in die Tabelle “tbl_WLC_VObject” der VMM-Datenbank herausfand.

Ich stoppte also den VMM-Dienst auf dem SCVMM-Server, kopierte das Skript in den SQL-Manager und änderte in der vierten Zeile den Wert “220” in “107”. Das Skript brauchte nur wenige Sekunden. Nach Neustart des VMM-Dienstes war die fehlerhafte VM aus der Anzeige verschwunden.

Um die VM nun wieder in den VMM einzubinden, öffnete ich die Eigenschaften des Hosts, auf dem die VM lief. Unter “VMs” klickte ich auf “Durchsuchen”§ und wählte den tatsächlichen Speicherpfad der VM-Dateien aus. Danach war es erforderlich, den Host per Rechtsklick im VMM zu aktualisieren. Danach war die VM wieder korrekt eingebunden und verwaltbar.

Achtung: Dieses Verfahren ist nur auf eigene Gefahr einzusetzen! Ich übernehme keinerlei Verantwortung oder Support dafür!

Ein vergleichbares Problem mit einem ähnlichen Lösungsansatz beschreibt Michel Lüscher hier:

[Error “The cluster group could not be found” in Virtual Machine Manager | Server Talk]
http://www.server-talk.eu/2010/08/14/error-the-cluster-group-could-not-be-found-in-virtual-machine-manager/

faq-o-matic.net

Active-Directory-Replikation im Detail

Replikations-Vektoren und Metadaten

Auflösung von Replikationskonflikten

Verwandte Beiträge:

Windows 2008 R2 SP1-Beta: USV entkoppeln

Verwandte Beiträge:

Die Ultra Lite Touch Installation

Die customsettings.ini für die Ultra Lite Touch Installation

Die bootstrap.ini für die Ultra Lite Touch Installation

Noch eine kleine Anmerkung:

Verwandte Beiträge:

Seminar: Hyper-V sicher und sauber

Verwandte Beiträge:

Exchange 2010: Probleme mit Update Rollup 4

Verwandte Beiträge:

Festplatte fast voll? Per Skript Warnung verschicken

Aufbau des Skriptes

Das VBSkript

Verwandte Beiträge:

Sparkassen-Sicherheit: Eine Reaktion

Verwandte Beiträge:

ice:2010 AD-Delegation – die Folien und Skripts

Verwandte Beiträge:

Es ist ice-Zeit!

Verwandte Beiträge:

SCVMM: VM aus der Datenbank entfernen

Verwandte Beiträge: