Namensauflösung

Windows NT Magazine
Juli 2000
NT
Administrator
www.ntmagazin.de
Zu den problematischsten Bereichen der Windows-Vernetzung gehört zweifelsohne die Namensauflösung. In einer Einführung zu diesem Thema
zeigt Sean Daily die Grundlagen der Umsetzung
von Computernamen in IP-Adressen, wie sie in der
Windows-Welt üblich sind.
Administratoren können in ihrer Handlungsfreiheit zwar nicht eingeschränkt werden, jedoch lässt
sich ihre Tätigkeit zumindest überwachen. Dazu
kann unter Windows NT das Sicherheitsprotokoll
herangezogen werden. R. Franklin Smith zeigt,
welche Elemente des Sicherheitsprotokolls sich
dazu eignen.
Im Rahmen der Umstellung auf Windows 2000
spielt das Design von Standorten eine wesentliche
Rolle. Im Zusammenhang mit der Planung des
Active Directory lässt sich damit die Verwaltung
des Replikationsverkehrs erreichen. Sean Deuby
demonstriert diese Eigenschaften an einem konkreten Beispiel.
Die unbeaufsichtigte Installationen von Windows
2000 Professional lässt sich wesentlich einfacher
erreichen, als dies bei der Vorgängerversion Windows NT 4.0 möglich war. Mark Minasi arbeitet die
Unterschiede heraus und zeigt effiziente Wege für
die Installation von Microsofts neuesten Betriebssystemsproß.
In dieser Ausgabe:
1
Namensauflösung in
Windows-Netzwerken, Teil 1
5
Überwachen von
Administrator-Privilegien
8
Verwaltung des Replikationsverkehrs bei Windows 2000
12
15
Exchanges Zauberlehrlinge
Unbeaufsichtigte
Installation von W2K Prof
DM 24,90 · ÖS 173,50,- · SFR 24,90
B 49066
Namensauflösung
in Windows-Netzwerken, Teil 1
Versteckte Probleme der Namensauflösung
bedrohen die Stabilität von Netzwerken
Wenn der Autor in seiner Eigenschaft als
Netzwerkberater gefragt wird, welches der
problematischste Bereich der Windows-Vernetzung ist, lautet seine postwendende Antwort: die Namensauflösung. Schwierigkeiten mit schwerfälliger Ausführung oder gar
mit Server-Verbindungen, die von ClientComputern oder Anwendungen nicht hergestellt werden können, mit unvollständigen
Netzwerksuchlisten und rätselhaften Fehlermeldungen lassen sich häufig direkt auf Probleme bei der Auflösung von Computernamen in ihre entsprechenden IP-Adressen
zurückführen. Der erste Teil dieses zweiteiligen Artikels enthält eine Einführung in die
Namensauflösung, eine Beschreibung einiger weniger bekannter Ursachen, die sich
hinter Problemen der Namensauflösung verbergen, und die Aufklärung eines gängigen
Missverständnisses im Hinblick auf die
Namensauflösung.
Im DNS-gestützten Namensbereich des
Internets ist die Namensauflösung eindeutig
geregelt. Zur Auflösung von Namen fragen
die Clients den oder die DNS-Server ab, die
entweder die IP-Adresse des angefragten
Hosts zurückliefern oder den Client darüber
informieren, dass der gesuchte Name nicht
vorhanden ist. Dies ist ein allgemein transparenter Prozess.
Nicht so mit dem Prozess zur Namensauflösung in Windows-basierten Netzwerken, der mit zusätzlichen Schichten und
Diensten arbeitet wie zum Beispiel WINSServer und -Clients, Broadcasts und Dateien
zur statischen Zuordnung von Namen und
IP-Adressen (das heißt HOSTS- und
LMHOSTS-Dateien). Diese zusätzlichen
Methoden zur Namensauflösung verkomplizieren den Prozess und machen die Diagnose
und Behebung von Problemen wesentlich
kniffliger. Bevor nun die komplizierten Sachverhalte geschildert werden, sollen kurz die
Grundlagen der Namensauflösung in einer
TCP/IP-Umgebung erläutert werden.
die Grundlagen der Namensauflösung in
einer TCP/IP-Umgebung erläutert werden.
Im Unterschied zu Protokollen, die zur Auflösung von Namen ausschließlich mit Broadcast-Methoden (zum Beispiel IPX/SPX, NetBEUI) arbeiten, kann TCP/IP in einer Windows-Umgebung zusätzlich auf Punkt-zuPunkt-Abfragen von Namens-Servern zurückgreifen. Diese Art von Abfragen ist vorzuziehen, weil sie zuverlässiger ist, leicht Router passieren kann und weniger Netzwerkbandbreite
beansprucht als Broadcast-Abfragen. Eine
Punkt-zu-Punkt-Abfrage ähnelt einem Bekannten, der telefonisch anruft, um eine Frage zu
stellen, während die Broadcast-Methode eher
einem Bekannten entspricht, der vor dem Haus
steht und seine Frage durch ein Megaphon
brüllt. Im ersten Fall sind an der Kommunikation nur ein Anrufer und ein Empfänger beteiligt, während im letzteren Fall auch alle Nachbarn des Empfängers in die Kommunikation
einbezogen werden.
Clients aller Windows-Betriebssysteme mit
Ausnahme von Windows 2000 verlangen das
Vorhandensein der NetBIOS-Sitzungsschicht
zusammen mit einem Netzwerktransportprotokoll. Windows 2000 greift dagegen nicht auf
NetBIOS zurück, um Netzwerkaktivitäten zu
unterstützen: Die TCP/IP-Implementierung von
Windows 2000 kann mit DNS arbeiten, um
Netzwerk-Server und Netzwerkdienste ausfindig zu machen. Das heißt, die TCP/IP-Protokoll-Stacks der Betriebssysteme unterstützen
eine modifizierte Form von TCP/IP, die als
“NetBIOS over TCP/IP” (NetBT) bezeichnet
wird. Windows-Clients, die NetBT (also
WINS-Clients) verwenden, können versuchen,
Namen mit Hilfe eines von vier NetBT-Knotentypen aufzulösen: B-Knoten (b-node), P-Knoten (p-node), M-Knoten (m-node) und H-Knoten (h-node).
1
Abbildung 1: Anzeigen der Standard-Gateway-Metric-Daten
B-Knoten: Die B-Knoten-Clients verwenden Broadcasts, um ihre Namen zu registrieren und die Namen anderer Maschinen
im Netzwerk aufzulösen. Der Typ B-Knoten
ist für die meisten Netzwerke nicht wünschenswert, da IP-Router in der Regel Broadcasts nicht weiterleiten, sodass der B-Knotentyp den Auflösungsbereich eines Clients auf
ein IP-Subnetz (das heißt auf ein Netzwerksegment) eingrenzt. Und da der B-Knotentyp
mit netzwerksättigenden Broadcasts arbeitet,
benötigt er mehr Bandbreite als Punkt-zuPunkt-Methoden. B-Knoten ist der Standardtyp für Windows-Clients, die keinen konfigurierten NetBIOS-Namens-Server besitzen
(NetBIOS Name Server, kurz NBNS, ist der
generische Name für einen WINS-Server, der
in der Regel ein Windows-2000- oder Windows-NT-Server ist). NT unterstützt ferner
eine leicht abgewandelte Form des B-Knotens, der als modifizierter B-Knoten bezeichnet wird. Ein Client des modifizierten B-Knotentyps überprüft zuerst seinen lokalen
Namens-Cache auf eine Zuordnung des
Namens zu einer Adresse. Kann der Client die
Adresse im Speicher nicht finden, greift er auf
die Broadcast-Methode zurück. Wenn keine
dieser Methoden ein Ergebnis liefert, überprüft der Client die lokale Datei LMHOSTS
(falls vorhanden) im Ordner \%system
root%\system32\drivers\etc auf Windows
2000- oder NT-Systemen beziehungsweise
im Ordner Windows auf Windows-9x-Systemen.
P-Knoten: Die P-Knoten-Clients registrieren ihre Namen bei einem WINS-Server
und nutzen diesen Server zur Auflösung von
Namen. Der P-Knotentyp besitzt jedoch
einen großen Nachteil: Falls der Server den
Namen nicht auflösen kann oder wenn der
Client mit falschen Zuordnungen von
Namen zu Server-Adressen konfiguriert
wurde, kann sich der Client nicht am Netzwerk anmelden, weil er den Namen eines
2
Domänencontrollers zur Verarbeitung der
Anmeldeanforderung nicht ermitteln kann.
M-Knoten: Die M-Knoten-Auflösung
ist eine von zwei Hybridknotentypen. Beim
Versuch, Namen aufzulösen, verwenden MKnoten-Clients Broadcasts des B-Knotentyps und Punkt-zu-Punkt-WINS-ServerAbfragen (das heißt P-Knoten-Abfragen),
und zwar in dieser Reihenfolge. Die M-Knoten-Auflösung ist für WAN-Subnets optimal, die über keinen lokalen Namens-Server
verfügen und die Verbindung zum WAN
über Leitungen geringer Bandbreite herstellen. In diesem Fall hilft die Verwendung von
Broadcasts zur Auflösung von Namen bei
der Minimierung des Netzwerkverkehrs
über die WAN-Verbindungen.
H-Knoten: Die H-Knoten-Auflösung ist
der Standardtyp für Windows-Clients, die
(entweder manuell oder mit Hilfe von Informationen aus einem DHCP-Server) so konfiguriert sind, dass sie sich bei einem oder
mehreren WINS-Servern registrieren. Der
H-Knotentyp ist im Grunde gerade die
Umkehrung des M-Knotentyps: Clients
registrieren ihre Namen direkt bei WINSServern und nutzen diese Server zuerst,
wenn sie versuchen, Namen aufzulösen.
Falls die Namens-Server-Abfragen fehlschlagen, greift der Client auf Broadcasts
des B-Knotentyps zurück.
Wie lässt sich der Knotentyp eines
WINS-Clients nun feststellen? Standardmäßig arbeitet ein Client mit dem B-Knotentyp, sofern er nicht dazu konfiguriert
wird, seinen Namen bei mindestens einem
WINS-Server zu registrieren. In diesem Fall
verwendet der Client die H-Knoten-Auflösung. Diese Standardfunktionsweise kann
jedoch außer Kraft gesetzt werden. Zum
Beispiel können Clients mit Hilfe einer
DHCP-Bereichsoption (das heißt eines Konfigurationsparameters, der an einen DHCPClient übergeben wird) so konfiguriert wer-
den, dass sie einen bestimmten Knotentyp
verwenden. Auf den meisten Windows-Versionen kann auch ein Registrierungseintrag
zur manuellen Konfiguration der Einstellung für den WINS-Knotentyp verwendet
werden. Allerdings ist dies nicht unbedingt
zu empfehlen, da eine manuelle Registrierungskonfiguration sogar einen dynamisch
über DHCP zugewiesenen Knotentyp außer
Kraft setzt, wodurch diese Methode Flexibilität einbüßt.
Da die Mehrheit von NT-Netzwerken mit
WINS-Servern arbeitet, verwendet eine
Mehrheit von Windows-basierten LAN-Clients in diesen Netzwerken die H-KnotenAuflösung. Falls weder die Punkt-zu-PunktMethode noch die Broadcast-Methode
erfolgreich sind, greifen WINS-Clients mit
dem H-Knotentyp auf andere Methoden
zurück. Der H-Knoten-Typ geht bei dem
Versuch, Namen aufzulösen, nach folgender
Reihenfolge vor:
1. Überprüfen, ob der gesuchte Name zur
lokalen Maschine gehört.
2. Überprüfen des lokalen Namens-Cache,
der aufgelöste Namen standardmäßig für
zehn Minuten zwischenspeichert.
3. Senden einer Punkt-zu-Punkt-Abfrage an
den konfigurierten WINS-Server (beziehungsweise die Server).
4. Senden einer Broadcast-Abfrage.
5. Lesen einer lokalen Datei LMHOSTS,
falls eine vorhanden ist.
6. Lesen einer lokalen Datei HOSTS, falls
eine vorhanden ist. Eine Datei HOSTS
befindet sich im Ordner \%system
root%\system32\drivers\etc auf Windows 2000- oder NT-Systemen beziehungsweise auf Win9x-Systemen im
Ordner Windows.
7. Absetzen einer Punkt-zu-Punkt-Abfrage
an alle konfigurierten DNS-Server. Unter
NT versuchen H-Knoten-WINS-Clients
diesen Schritt nur, wenn das
Kontrollkästchen “DNS für WindowsAuflösung aktivieren” im Dialogfeld zur
TCP/IP-Konfiguration ausgewählt ist.
Diese Einstellung wird in NT dem
Schlüssel EnableDNS des Typs
REG_DWORD unter dem Registrierungsschlüssel HKEY_LOCAL_MA
CHINE\SYSTEM\CurrentControlSet\Ser
vices\NetBT\Parameters beziehungsweise in Win9x dem Registrierungsschlüssel HKEY_LOCAL_MACHINE\
SYSTEM\CurrentControlSet\Services\V
XD\MSTCP zugeordnet. Trotz seines
Namens steuert der Teilschlüssel EnableDNS nur, ob ein Client einen DNS-Server während der NetBT-Namensauflösung verwendet, und hat keinen Einfluss
auf die Verwendung von DNS zu anderen
Zwecken (zum Beispiel zur Auflösung
von Website-Namen in einem Browser).
Standardmäßig ist diese Einstellung
unter NT deaktiviert (das heißt, sie
besitzt den Wert 0), während unter Win9x
diese Einstellung aktiviert ist (das heißt
den Wert 1 besitzt).
Das DNS spielt bei der Namensauflösung eine wesentlich größere Rolle als es
die oben erwähnte Reihenfolge der Methoden offenbart. H-Knoten-WINS-Clients
fragen DNS-Server erst ab, wenn alle anderen Versuche zur Namensauflösung
gescheitert sind, und auch nur dann, wenn
die Verwendung von DNS zur WindowsNamensauflösung auf dem Client aktiviert
wurde. Jedoch versuchen H-KnotenWINS-Clients, einen DNS-Server so zu
verwenden, als wäre er ein WINS-Server:
Der Client arbeitet mit einer NetBIOSNamensabfrage im WINS-Stil und nicht
mit einer DNS-Client-Namensabfrage, um
eine Anforderung für eine Namensauflösung an den DNS-Server zu senden. Wenn
der DNS-Server nicht zufällig auch der
WINS-Server ist und in seiner Datenbank
eine registrierte Adresse für den abgefragten Namen hat, schlägt diese H-KnotenAbfrage mit hoher Wahrscheinlichkeit fehl.
Der Auflösungsprozess des H-KnotenTyps von NetBT ist nicht das einzige Mal,
dass Clients DNS-Server im Rahmen der
Namensauflösung abfragen. Wenn DNS
auf einem Client aktiviert ist und der Client zur Verwendung eines oder mehrerer
DNS-Server konfiguriert wurde, nutzt der
Client die DNS-Client-Abfragen (auch als
“Domain Name Resolver”-Abfragen,
DNR-Abfragen, bezeichnet) über den
UDP-Standard-Port 53, um Namensabfragen an DNS-Server zu senden. Der Client
sendet diese DNS-Abfragen, nachdem er
nach einer lokalen Datei HOSTS gesucht
hat und bevor er irgendwelche Versuche
zur NetBT-Namensauflösung unternimmt.
Zur Erstellung eines vollständig qualifizierten Domänennamens (Fully Qualified
Domain Name – FQDN, zum Beispiel
meinserver.meinbiz.com) für die Abfrage
hängt der Client alle Standardnamen, die
im DNS-Teil des Dialogfelds zur TCP/IPKonfiguration konfiguriert wurden, an den
abgefragten Namen an. Der Autor hat diese
Funktionsweise mit einem Netzwerküberwachungs-Tool beobachtet. Informationen
darüber, wie die Client-Namensauflösung
und anderer Netzwerkverkehr sichtbar
gemacht werden kann, enthält der Kasten
“Ein Blick hinter die Kulissen mit einem
Netzwerkmonitor” auf dieser Seite.) Die
folgende Liste zeigt die komplette und
exakte Reihenfolge des Verfahrens auf, mit
dem Windows-Clients im LAN versuchen,
Namen aufzulösen:
1. Überprüfen, ob der abgefragte Name zur
lokalen Maschinen gehört.
2. Verwenden einer lokalen Datei HOSTS,
falls eine vorhanden ist.
3. Abfragen konfigurierter DNS-Server
mit DNR-Abfragen über UDP-Port 53.
4. Nutzen der Auflösungsmethode des
NetBT-Knoten-Typs, die dem NetBTKnoten-Typ (wie bereits beschrieben)
des Clients entspricht.
Diese Liste zeichnet gegenüber der
vorigen ein stark verändertes Bild. Die
meisten Administratoren, mit denen der
Autor spricht, zeigen sich überrascht,
wenn sie erfahren, dass LAN-Clients unter
Windows konsequent DNS-Server abfragen, bevor sie WINS-Server abfragen. Dieses Missverständnis ist weit verbreitet,
weil die Dokumentation und die Schulungsunterlagen von Microsoft, in denen
die NetBT-Auflösungsreihenfolge behandelt wird, mehrheitlich vergessen, auf
diese einleitenden DNS-Abfragen einzugehen. Für WINS konfigurierte LAN-Cli-
Ein Blick hinter die Kulissen mit einem Netzwerkmonitor
Zur Beobachtung des Verfahrens zur Namensauflösung in einem
Windows-Netzwerk empfiehlt der Autor den Einsatz eines Netzwerküberwachungsprodukts wie zum Beispiel des Microsoft-Netzwerkmonitors für Windows NT, des Netzwerkmonitors für Microsoft Systems
Management Server (SMS) oder eines Drittherstellerprodukts wie
Sniffer Pro LAN von Network Associates (ehemals NetXRay). In
Anzeige A ist eine Beispielsitzung einer Netzwerküberwachung zu
sehen, in der die Ergebnisse eines WINS-Clients anzeigt werden, der
zur Namensabfrage den Befehl Ping verwendet. Die Frames 1 bis 8
zeigen, dass der Netzwerkverkehr vom Client mit einer Serie von
DNS-Abfragen an jeden der konfigurierten DNS-Server des Clients
beginnt, die sämtlich fehlschlagen. Frame 9 zeigt, dass der Client die
Abfrage daraufhin an den ersten konfigurierten WINS-Server sendet,
der mit der Rückgabe der aufgelösten IP-Adresse für den abgefragten
Namen reagiert, wie in Frame 10 zu sehen ist. Die Frames 11 bis 13
zeigen den ICMP-Verkehr (Internet Control Message Protocol), der
vom Befehl Ping zwischen den beiden Hosts generiert wird.
(Sean Daily)
Produkte zur
Netzwerküberwachung
Sniffer Pro LAN
Network Associates
http://www.sniffer.com
EtherPeek 4 for Windows
AG Group
http://www.aggroup.com
Abbildung 2: Beobachten der Namensauflösungsfunktion mit
einem Netzwerküberwachungs-Tool
3
ents führen wahrscheinlich regelmäßig
eine gigantische Anzahl fehlschlagender
DNS-Namensauflösungsabfragen durch.
Ein DNS-Server, der die Informationen
nicht besitzt, reagiert einfach mit der Antwort, dass er den abgefragten Namen nicht
auflösen kann. Diese Bestätigung benötigt
nicht viel Zeit, sodass Benutzern die Verzögerung nur selten auffällt. Wenn der Client jedoch den DNS-Server beziehungsweise die Server aus irgendeinem Grund
nicht erreichen kann (zum Beispiel, weil
die Server-Adressen falsch konfiguriert
sind oder weil die Server von der IPAdresse des Clients aus nicht erreichbar
sind oder aber die Server gar außer Betrieb
sind) muss der Client darauf warten, dass
nachfolgende DNS-Server-Abfragen
infolge Zeitlimitüberschreitung beendet
werden, bevor er den Versuch einer NetBTMethode starten kann. Abhängig vom
Betriebssystem des Clients und der installierten Service-Pack-Stufe kann diese Wartezeit von fünf Sekunden bis zu “endlos
langen” zwei Minuten dauern.
Diese Funktionsweise – erst mal DNS
versuchen – erweist sich in verschiedenen
Situationen durchaus als problematisch.
Zum Beispiel kann es bei Remote-Clients
auf Laptops mit Ethernet-Verbindungen
und konfigurierten DNS-Server-Adressen
zu langen Verzögerungen kommen, wenn
sie probieren, eine Verbindung zu DNSServer-Adressen herzustellen, die in der
Registrierung zwischengespeichert sind
und durch die primäre Verbindung konfiguriert werden (zum Beispiel EthernetVerbindung, einleitende RAS-ModemVerbindung). Diese Situation kann auftreten, wenn die Clients über eine Wählverbindung auf ein Firmen-LAN zugreifen,
jedoch die Konfiguration des Firmen-LAN
den Zugriff auf die DNS-Server, die bei der
primären Verbindung konfiguriert werden,
nicht zulässt. Infolgedessen muss der Client warten, bis jede DNS-Server-Abfrage
durch eine Zeitlimitüberschreitung abgebrochen wird. Diese Wartezeiten sind länger als mit WINS verbundene Zeitlimits,
weil sie berücksichtigen, dass der Client
die Verbindung eventuell über das Internet
herstellt, das im Vergleich zum privaten
LAN oder WAN, in dem sich ein WINSServer befindet, ein unberechenbares
Netzwerk ist. Dieses Problem tritt sogar
bei einem RAS-Client auf, der erreichbare
DNS-Server von einem RAS-Server übernimmt, weil der RAS-Client diese zusätzlichen Namen an das Ende seiner DNSServer-Liste anhängt und sie erst versucht,
nachdem die ursprünglichen (also die nicht
4
erreichbaren) DNS-Server probiert wurden.
RAS-Clients, die sich über PPTP in ein
Firmen-VPN einwählen, sind von dem
DNS-Verzögerungsproblem ebenfalls
betroffen. Standardmäßig arbeitet RAS mit
der letzten Verbindung als Standard-Gateway des Clients. RAS macht den RouteMetric-Wert für den Standard-Gateway der
letzten Verbindung kleiner als den MetricWert für die frühere Verbindung wie in
Anzeige 1 zu sehen ist. Aber PPTP-Verbindungen sind per Definition sekundäre Verbindungen. Infolgedessen stellt die PPTPVerbindung die primäre Verbindung (das
heißt RAS) ins Abseits, weil der gesamte
nicht lokale Verkehr standardmäßig über
die sekundäre (das heißt PPTP) Verbindung läuft. Sofern die PPTP-Verbindung
nicht ein Netzwerk bedient, das dem Client
erlaubt, eine Verbindung zu den DNS-Servern herzustellen, die durch die primäre
Verbindung konfiguriert wurden, kann der
Client nicht auf diese Server zugreifen.
Jedoch kennt der Client diese Einschränkung nicht, woraus eine bedeutende Verlangsamung auf dem Client-System resultiert, wenn der Client jeden einzelnen
DNS-Server abfragt und die Zeitlimits
abwarten muss. Die meisten Clients, auf
denen DNS aktiviert wurde, versuchen
jeden konfigurierten DNS-Server viermal
zu erreichen, bevor sie die Versuche einstellen. Im Extremfall kann dieses Zeitlimit zu einer Verzögerung von zwei Minuten führen.
Eine Möglichkeit, dieses Problem zu
umgehen, besteht darin, das Kontrollkästchen “Standard-Gateway auf dem RemoteNetzwerk verwenden” für die PPTP-Verbindung im Telefonbucheintrag des DFÜNetzwerk-Clients abzuwählen. Nur der
Verkehr, der an das von PPTP bediente
Netzwerk gerichtet ist, läuft über die
PPTP-DFÜ-Verbindung, während der
übrige Verkehr wie zum Beispiel DNSAbfragen an DNS-Server im Internet,
erfolgreich über die primäre Verbindung
abgewickelt wird. Diese Lösung funktioniert gut, wenn der Client nur zu einem
einzigen LAN-Netzwerk eine Verbindung
herstellt. Wenn der Client hingegen eine
PPTP-Verbindung zu einem WAN herstellt und eine Maschine kontaktieren
muss, die sich vom RAS-Server aus gesehen jenseits eines Routers befindet, funktioniert diese Methode nicht, weil der Client das Standard-Gateway über seine
primäre Verbindung anstatt des StandardGateways über seine PPTP-Verbindung
verwendet.
Bei der Erforschung des DNS-Verzögerungsproblems stellte der Autor fest,
dass die Verzögerungen nicht beständig
auf allen Windows-Clients auftreten. Zur
Ermittlung der Ursache führte der Autor
eine umfangreiche Testreihe mit allen
Versionen von Windows (von Windows
95 bis Windows 2000) durch. Es stellte
sich heraus, dass die langen DNS-Zeitlimits bei allen Windows-Versionen mit
Ausnahme von Windows 2000, NT 4.0
Service-Pack 4 (SP4) und späteren Versionen sowie Windows 98 Second Edition (Win98SE) ein Problem darstellten.
Es zeigte sich, dass Microsoft wesentliche
Änderungen in diesen Versionen an der
Art und Weise vorgenommen hat, wie Clients die DNS-Abfragen in den TCP/IPStacks durchführen. Insbesondere hat
Microsoft den Algorithmus überarbeitet,
der von DNR zur Abfrage von DNS-Servern verwendet wird, und damit die maximale Wartezeit in Extremfallszenarien
effektiv verkürzt. Diese Änderungen verringern die Namensauflösungszeiten von
120 Sekunden auf 19 Sekunden bei einem
Durchschnittswert von fünf Sekunden für
die Mehrzahl der Fälle (die genaue Sekundenzahl ist von der Anzahl der konfigurierten DNS-Server und verschiedenen
anderen Faktoren abhängig). Obwohl der
Client weiterhin DNS-Server zuerst
abfragt, wird das Problem durch die
Änderungen in den meisten Fällen zu
einer eher akademischen Frage.
Ein Verständnis der Methoden zur
Namensauflösung und der Art und Weise,
wie DNS-Abfragen zu Problemen für die
Clients werden können, ist der erste Schritt
auf dem Weg zur Lösung von Problemen
der Namensauflösung. Wenn jedoch in
einer Umgebung keine der bisher beschriebenen Maßnahmen weiterhilft, sind andere
Optionen in Betracht zu ziehen. Teil 2
erläutert, wie die Namensauflösung
gesteuert sowie die Stabilität und Leistung
eines Netzwerks verbessert werden können.
(Sean Daily)
ÜBER DEN AUTOR
Sean Daily veröffentlicht Beiträge im Windows 2000 Magazine und ist Präsident von
iNTellinet Solutions, einem Unternehmen
für Netzwerk-Consulting und -Integration
im Gebiet der Bucht von San Francisco.
Sein zuletzt veröffentlichtes Buch trägt den
Titel “Optimizing Windows NT” (IDG
Books). Er ist unter sdaily@win2000mag.
com zu erreichen.
Überwachen von Privilegien und Administratoren
im NT-Sicherheitsprotokoll
Administratoren können in ihrer Handlungsfreiheit zwar nicht eingeschränkt werden, jedoch lässt sich ihre Tätigkeit zumindest überwachen.
Im Artikel “Interpretieren des NT-Sicherheitsprotokolls” (in der diesjährigen MaiAusgabe des NT Administrator) hat der
Autor erläutert, wie die drei zusammengehörigen Überwachungskategorien Anund Abmelden, Datei- und Objektzugriffe
und Prozessverfolgung zur Überwachung
von Benutzeraktivitäten verwendet werden
können. In diesem Beitrag werden die Kategorien “Privilegierte Benutzung” und “Kontenverwaltung” behandelt. Die letztere
Kategorie ist besonders nützlich zur Überwachung der Aktivitäten von Benutzern, die
Administratoraktivitäten mit höchster Berechtigungsstufe durchführen. Dabei ist
allerdings zu beachten, dass die Terminologie von Windows NT für die Überwachungskategorien nicht konsequent ist. Die
NT-Ereignisanzeige verwendet etwas
andere Namen für die Überwachungskategorien als der Benutzermanager. Tabelle 1
auf Seite 7 hilft bei der Klärung dieser
Bezeichnungen.
Die Kategorie “privilegierte Benutzung”
ermöglicht die Verfolgung von Rechten wie
sie von Benutzern ausgeübt werden. NT
verwendet hier die Ausdrücke “Privileg” und
“Recht” nicht konsequent. Benutzerrechte
werden im Dialogfeld “Richtlinien für
Benutzerrechte” (siehe Abbildung 1) verwaltet, das über das Menü “Start” und die Optionen “Programme”, “Verwaltung”, “Benutzer-Manager”, “Richtlinien” und “Benutzerrechte” aufgerufen wird.
Wenn ein Benutzer ein Recht erfolgreich
ausübt wie zum Beispiel “Ändern der
Systemzeit” protokolliert NT eine EreignisID 577 wie sie in Abbildung 2 gezeigt wird.
Das Feld “Privilegien” gibt dabei an, welche
Rechte der Benutzer verwendet hat (in diesem Beispiel: SeSystemtimePrivilege). Wie
der Leser leicht bemerkt, unterscheiden sich
die Beschreibungen im Feld “Privilegien”
von denen, die der Benutzermanager im Dialogfeld “Richtlinien für Benutzerrechte”
anzeigt, jedoch sind die beiden Beschreibungen meist leicht zuzuordnen. Die Felder
“Primärer Benutzer Benutzername” und
“Client-Benutzername” identifizieren den
Benutzer, der das Recht ausgeübt hat. Die
“Client”-Informationen spielen nur dann
eine Rolle, wenn ein Benutzer Aktionen von
Abbildung 1: Einstellung der Richtlinien für Benutzerrechte
einem Remote-System über das Netzwerk
ausführt. Wenn ein Benutzer die lokale
Systemzeit ändert, ist die Angabe des
primären Benutzers die einzig relevante
Information. Wenn ein Benutzer jedoch eine
Verbindung zu einem NT-System herstellt
und die Systemzeit über das Netzwerk ändert,
gibt das Feld des primären Benutzers das
Benutzerkonto der Server-Anwendung (in
diesem Fall des Server-Diensts) an, während
die Informationen des Client-Benutzers den
Benutzer zeigt, der auf das System zugriff.
Zu beachten ist, dass die Ereignisinformationen auch die “Primäre Anmelde-ID” enthalten, an der zu erkennen ist, in welcher
Anmeldesitzung das Ereignis stattfand. Weitere Details sind der Beschreibung der Kategorie “Anmeldung/Abmeldung” dem Artikel “Interpretieren des NT-Sicherheitsprotokolls” zu entnehmen.
Einige Privilegien beziehen sich nur auf
Objekte. Eine Operation für privilegierte
Objekte ist zum Beispiel SeSecurityPrivilege. Sie ist erforderlich, wenn ein Benutzer
das Sicherheitsprotokoll über die Ereignisanzeige öffnet. Die Ereignis-ID 578 gibt an,
wann Benutzer Objektprivilegien ausüben
und welche Privilegien der Benutzer verwendet hat. Immer wenn ein Benutzer eine
privilegierte Aktion oder ein privilegiertes
Objekt verwendet, informiert die EreignisID 577 oder 578 darüber, dass ein Benutzer
versuchte, ein Recht auszuüben. Beide
Ereignisse sind erfolgreich oder schlagen
fehl, abhängig davon, ob der Benutzer das
Recht besaß, das er auszuüben versuchte.
Einige wenige Rechte werden so häufig
genutzt, dass das Ereignisprotokoll mit nutzlosen Informationen überfüllt würde, wenn
NT diese jedes Mal protokollierte. Zwei
Rechte in dieser Kategorie, die für Benutzer
und Administratoren Bedeutung haben, sind
die Rechte SeBackupPrivilege und SeRestorePrivilege, die von Benutzern ausgeübt
werden, wenn sie versuchen, ein Objekt zu
sichern oder wiederherzustellen. Zur Über-
5
Aufruf privilegierter Dienst:
Server:
Security
Dienst:
–
Primärer Benutzername:
Administrator
Primäre Domäne:
KRAMER
Primäre Anmelde-ID:
(0x0, 0xE5A6)
Client-Benutzername:
–
Client-Domäne:
–
Anmelde-ID des Clients:
–
Privilegien:
SeSystemtimePrivilege
Abbildung 2: Ereignis-ID 577
Besondere Privilegien bei neuer Anmeldung:
Benutzername:
Administrator
Domäne:
KRAMER
Anmelde-ID:
(0x0, 0xE5A6)
Zugewiesen:
SeChangeNotifyPrivilege
SeBackupPrivilege
SeRestorePrivilege
SeDebugPrivilege
Abbildung 3: Ereignis-ID 576
Benutzerkonto erzeugt:
Neuer Kontenname:
Bob
Neue Domäne:
KRAMER
Neue Konto-ID:
S-1-5-21-991500030-1883011820-28194
Benutzername des Aufrufers:
Administrator
Domäne des Aufrufers:
KRAMER
Anmelde-ID des Aufrufers:
(0x0,0xE5A6)
Privilegien:
–
Abbildung 4: Ereignis-ID 624
Benutzerrechte zugeteilt:
Benutzerrecht:
SeSystemtimePrivilege
Zugeteilt zu:
S-1-5-32-544
Zugeteilt von:
Benutzername:
Administrator
Domäne:
KRAMER
Anmelde-ID:
(0x0,0xA399)
Abbildung 5: Ereignis-ID 608
6
wachung dieser Rechte zeichnet NT einfach
die Rechte von Benutzern bei ihrer Anmeldung auf. Nach der Ereignis-ID 528 (erfolgreiches Anmelden) findet sich oft eine Ereignis-ID 576 (besondere Privilegien bei neuer
Anmeldung), die in Abbildung 3 dargestellt
ist. Dieses Ereignis gibt den Namen und die
Domäne des Benutzers sowie die AnmeldeID des Benutzers an, anhand deren dieses
Ereignis mit der entsprechenden Anmeldesitzung in Verbindung gebracht werden
kann. Die Ereignis-ID 576 führt die Rechte,
die dem Benutzer erteilt wurden, im Feld
“Zugewiesen” auf. Andere Rechte, die im
Sicherheitsprotokoll unter der Ereignis-ID
576 aufgeführt werden, sind SeAuditPrivilege, SeCreateTokenPrivilege, SeAssignPrimaryTokenPrivilege und SeDebugPrivilege.
Die Kategorie “Kontenverwaltung”
ermöglicht eine Verfolgung der Aktivitäten
von Benutzern, die über Administrator- und
Konten-Operatorprivilegien verfügen, da
diese Benutzer Gruppen und Benutzer verwalten. Leider gibt diese Kategorie in der
Regel keine Auskunft darüber, welche
Benutzer- oder Gruppeneigenschaften der
Administrator oder Konten-Operator aktualisiert hat, sondern zeichnet lediglich auf,
welches Konto der Administrator aktualisiert hat, welcher Administrator das Konto
auf den aktuellen Stand brachte und ob der
Administrator das Konto erstellt, geändert
oder gelöscht hat. In wenigen Fällen, die hier
behandelt werden, stellt NT genauere Informationen bereit. Zu beachten ist dabei, dass
NT diese Ereignisse auf dem System aufzeichnet, auf dem sich das Konto befindet.
Wenn ein neues Benutzerkonto in der lokalen SAM-Datenbank eines Mitglieds-Servers erstellt wird, zeichnet NT die zugehörigen Ereignisse im Protokoll dieses Servers
auf. Wenn ein Domänenbenutzerkonto geändert wird, protokolliert NT das Ereignis im
Protokoll des primären Domänencontrollers
(PDC).
Erstellt ein Benutzer ein neues Benutzerkonto, wird im Sicherheitsprotokoll die
Ereignis-ID 624 aufgezeichnet, die in Abbildung 4 dargestellt ist. Dieses Ereignis identifiziert den Konten-Operator oder den
Administrator durch den Benutzernamen
und die Domäne des Aufrufers. Darüber hinaus gibt das Ereignis die Anmelde-ID des
Aufrufers an, über die dieses Ereignis mit
der entsprechenden Anmeldesitzung assoziiert werden kann. NT identifiziert das neue
Konto in den Feldern “Neuer Kontenname”,
“Neue Domäne” und “Neue Konto-ID”. Die
Ereignisse der Kontenverwaltung verstehen
unter der Bezeichnung Konto-ID die SID
eines Kontos.
Bezeichnungen für Überwachungskategorien
Ereignisanzeige
Benutzermanager
Anmeldung/Abmeldung
An- und Abmelden
Zugriff auf Objekt
Datei- und Objektzugriffe
Privilegierte Benutzung
Verwendung von Benutzerrechten
Kontenverwaltung
Benutzer- und Gruppenverwaltung
Richtlinienänderung
Sicherheitsrichtlinienänderung
Systemereignis
Neustarten, Herunterfahren und System
Detaillierte Verfolgung
Prozessverfolgung
Wird ein Benutzer gelöscht, protokolliert
NT die Ereignis-ID 630, in der die gleichen
Informationen wie in Ereignis-ID 624 zur
Identifizierung des Benutzers angegeben
werden, der das Konto gelöscht hat. Die
Ereignis-ID 630 identifiziert das gelöschte
Konto durch den Zielkontenname, die Zieldomäne und die Zielkonto-ID. Wenn ein
Benutzerkonto geändert wird, protokolliert
NT die Ereignis-ID 642. Dieses Ereignis
gibt keine Auskunft darüber, welche Eigenschaften (zum Beispiel Beschreibung,
Anmeldezeiten) geändert wurden oder welche Werte für die Eigenschaften verwendet
wurden. Das Ereignis identifiziert nur den
Benutzer, der die Änderung durchgeführt
hat, und das Konto, das von dem Benutzer
aktualisiert wurde.
NT protokolliert bestimmte Ereignisse
für eine kleine Anzahl von Aktionen, die an
Benutzerkonten durchgeführt werden. Die
Ereignis-IDs 626 und 629 geben darüber
Aufschluss, dass jemand ein Benutzerkonto
aktiviert beziehungsweise deaktiviert hat.
Wenn Benutzer versuchen, ihr Kennwort zu
ändern, protokolliert NT die Ereignis-ID
627 und weist das Gelingen oder Fehlschlagen der Aktion aus, je nachdem, ob der
Benutzer die Berechtigung besaß, das Kennwort zu ändern oder ob das Kennwort der
Kennwortrichtlinie der Domäne entsprach.
Wenn ein Konten-Operator oder ein Administrator das Kennwort eines Benutzers
ändert, quittiert NT dies mit der Ereignis-ID
628.
Die Überwachungskategorie “Kontenverwaltung” verfolgt außerdem Aktionen
der Gruppenverwaltung. NT schreibt alle
Operationen mit, die an Gruppen durchgeführt werden können und verwendet spezifische Ereignis-IDs, je nachdem, ob die
Gruppe lokal oder global ist. Die Erstellung
einer globalen Gruppe generiert die Ereignis-ID 631, während durch das Löschen
einer lokalen Gruppe die Ereignis-ID 634
protokolliert wird. Wenn eine andere Eigenschaft einer globalen Gruppe als die Liste
von Mitgliedern der Gruppe geändert wird,
meldet NT das Ereignis 641. Die Ereigniskategorie “Kontenverwaltung” gibt etwas
differenziertere Informationen über Änderungen der Gruppenzugehörigkeit, indem
getrennte Ereignisse protokolliert werden,
wenn ein Mitglied einer globalen Gruppe
hinzugefügt wird (Ereignis-ID 632) oder ein
Mitglied aus einer globalen Gruppe gelöscht
wird (Ereignis-ID 633). Leider verwenden
diese Einträge nur die SID zur Angabe des
Mitgliedsbenutzers oder der Gruppe. Die
Kategorie “Kontenverwaltung” verwendet
ferner jeweils die gleichen Ereignisse, wenn
es sich um lokale Gruppen handelt: Ereignis-ID 635 für die Erstellung einer Gruppe,
Ereignis-ID 638 für das Löschen einer
Gruppe, Ereignis- ID 639 für die Änderung
einer Gruppe, Ereignis-ID 636 für das Hinzufügen eines Mitglieds und Ereignis-ID
637 für das Löschen eines Mitglieds.
Erteilt ein Administrator einem Benutzer
über den Benutzermanager ein Recht, protokolliert NT die Ereignis-ID 608, die in Abbildung 5 dargestellt ist. Dieses Ereignis gibt
sowohl das Recht an, das der Administrator
erteilt hat, als auch den Benutzer, dem der
Administrator das Recht zugewiesen hat. Im
Feld “Zugeteilt von” zeigt die Ereignis-ID
den Benutzernamen, die Domäne und die
Anmelde-ID des Administrators, der das
Recht erteilt hat. Die Anmelde-ID ermöglicht
es, dieses Ereignis mit der entsprechenden
Anmeldesitzung des Administrators in Verbindung zu bringen. Wenn ein Administrator
ein Benutzerrecht widerruft, protokolliert NT
die Ereignis-ID 609. Sie stellt die gleichen
Informationen über das Benutzerrecht bereit
wie die Ereignis-ID 608 und identifiziert den
Administrator, der das Recht entfernt hat. Die
Ereignis-IDs 608 und 609 dürfen nicht mit
den Ereignissen in der Kategorie “Privilegierte Benutzung” verwechselt werden. Die
Ereignis-IDs 608 und 609 geben an, wann
Administratoren Rechte erteilen oder entziehen. Die Ereignis-IDs 576, 577 und 578
geben darüber Auskunft, wann Benutzer
(nicht Administratoren oder Konten-Operatoren) versuchen, Rechte zu nutzen.
Die Kategorie der Kontenverwaltung enthält noch zwei weitere interessante Ereignisse. Wenn ein Domänenbenutzerkonto nach
wiederholten, nicht erfolgreichen Anmeldeversuchen gesperrt wird, schreibt der PDC die
Ereignis-ID 644 in das Protokoll. Wann
immer ein Administrator die Kennwortanforderungen der Domäne oder die Richtlinie
zum Sperren von Konten ändert, vergibt NT
die Ereignis-ID 643. Wenngleich dieses
Ereignis nicht anzeigt, welche Werte geändert
wurden, sind Kennwort- und Sperr-Richtlinien “halbdauerhafte” Einstellungen, sodass
es bereits wichtig ist, nur zu wissen, dass sie
geändert wurden. NT protokolliert die Ereignis-ID 643 ebenso auf Servern und Workstations, wenn die lokalen Systemrichtlinien
geändert werden.
Die Kategorie der Kontenverwaltung ist
besonders nützlich zur Verfolgung der Aktivitäten von Benutzern, die Administratoroder Konten-Operator-Berechtigungen
besitzen. Wenn auch nicht gesteuert werden
kann, was diese Personen tun, so können
doch wenigstens ihre Aktivitäten überwacht
werden. Aber was ist, wenn diese Benutzer
versuchen, ihre Spuren zu verwischen,
indem sie das Sicherheitsprotokoll manipulieren? Im nächsten Artikel dieser Serie werden die restlichen Überwachungskategorien
behandelt und gezeigt, wie diese zur Erkennung solcher Aktionen eingesetzt werden
können. (R. Franklin Smith)
R. Franklin Smith ist Präsident der Monterey
Technology Group und bietet Beratung zur
Windows-2000- und Windows NT-Sicherheit
an. Er ist Hauptdozent und Kursplaner für das
Windows-2000-Sicherheitsprogramm des
MIS Training Institute. Er ist unter rsmith@
montereytechgroup.com zu erreichen.
7
Verwalten des Windows-2000Verkehrs durch AD-Standorte
Die Grundzüge des Standortdesigns im Rahmen des Active Directory zeigen,
wie die AD-Standorte eine Verwaltung des Replikationsverkehrs von Windows2000-Servern ermöglichen.
Das Active Directory (AD) von Windows
2000 hat von allen neuen Eigenschaften die
meiste Aufmerksamkeit auf sich gezogen.
Trotz dieses Interesses widmen Benutzer der
Einrichtung der AD-Standorte vergleichsweise nicht so viel Aufmerksamkeit wie
anderen Windows-2000-Funktionalitäten,
zum Beispiel Domänen und dem globalen
Katalog (GC – Global Catalog). Obwohl
mancher Administrator mit seinen “Windows-2000-Aufgaben” bereits voll ausgelastet sein mag, empfiehlt es sich dennoch,
(zum Beispiel die WAN-Leitungen, die
Inseln verbinden) umgeben sind. Im Vergleich dazu ist NT 4.0 nicht in der Lage, die
physische Netzwerktopologie zu erkennen,
die dem Netzwerk zugrunde liegt, um die
WAN-Nutzung zu beeinflussen.
Windows NT Server 4.0 arbeitet nur mit
Domänen und Domänencontrollern, um die
Replikation über ein Netzwerk zu steuern,
sodass der Client mit NT Workstation 4.0
mit Unterstützung von WINS auswählt, auf
welchem Domänencontroller der Client,
Abbildung 1: Netzwerk- und WAN-Topologie einer Firma in Texas
sich mit AD-Standorten (Sites) zu befassen,
weil sie einen großen Unterschied hinsichtlich der Art und Weise bedeuten können, wie
Windows 2000 das Firmennetzwerk beeinflusst. Mit dem Wissen, wie AD-Standorte
zur Verwaltung der Replikation über ein
Windows-2000-Netzwerk genutzt werden,
ist leicht einzusehen, dass AD-Standorte
diese Aufmerksamkeit verdienen.
Microsoft hat die Einrichtung der ADStandorte in Windows 2000 eingeführt, um
ein Problem von Windows NT 4.0 zu lösen.
Die physische Netzwerktopologie für große
Firmennetzwerke ähnelt Inselgruppen mit
kürzeren Verbindungswegen (etwa das LAN
in einem Bürokomplex), die von einem
Ozean mit weiteren Verbindungswegen
8
abhängig von seiner Domäne, authentifiziert
wird. Wenn sich eine Domäne über mehrere
WAN-Leitungen erstreckt, kann es Clients
geben, die von fernen Domänencontrollern
sozusagen remote authentifiziert werden:
eine Situation, die zu langsamen oder fehlschlagenden Zugriffen beziehungsweise zu
langsamen oder fehlschlagenden Netzwerkanmeldungen führt. Dienstprogramme wie
Setprfdc können solche Probleme beheben,
jedoch gerät das logische Konzept von NTDomänen häufig mit dem physischen Aufbau der Netzwerktopologie in Konflikt.
Microsoft hat daher das Konzept der ADStandorte entwickelt, um dem Betriebssystem eine Möglichkeit zur Erfassung des physischen Netzwerks zu geben, sodass Win-
dows 2000 die Inseln mit kurzen Verbindungswegen definieren und den Verkehr
intelligenter verwalten kann.
Microsoft definiert einen Standort (Site)
als eine Gruppe von IP-Subnetzen (Teilnetzen), die in der Regel über Verbindungen mit
“guter Bandbreite” verfügen. Standorte enthalten gewöhnlich “gut verbundene” Computer, wenngleich “gut verbundene” Computer keine Voraussetzung sind. Verschiedene Faktoren (das heißt die WAN-Bandbreite oder Leitungslatenzzeiten) beeinflussen die Konnektivität (Verbindungsgüte),
und die Definition “gut verbundener” Computer kann zwischen verschiedenen Unternehmen unterschiedlich ausfallen. Daher ist
es sehr schwierig, hier eine standardisierte
Definition für Standortgrenzen anzugeben,
die auf sämtliche Bedingungen im Netzwerk
eines Unternehmens zutrifft. Außerdem
werden hier die Begriffe Computer und Server für Windows-2000-Systeme gebraucht.
NT-4.0-Server sind nicht in der Lage (und
werden es nie sein), Standorte zu erkennen.
Hingegen ist es möglich, mit Hilfe des Verzeichnisdienst-Clients (DS – Directory Service) auf den Windows-2000-CDs die Windows 9x-Clients zur Erkennung von Standorten zu befähigen.
Manchem Leser ist der Unterschied zwischen Standorten und Domänen vielleicht
nicht gleich klar. Der Unterschied zwischen
den beiden besteht darin, dass Standorte die
physische Struktur eines Netzwerks darstellen, während Domänen die logische Struktur
einer Region oder einer Organisation repräsentieren. So können mehrere Domänen in
einem Standort vorhanden sein, was jedoch
für die Verwaltung wahrscheinlich ein recht
kompliziertes Szenario wäre, oder eine
Domäne kann mehrere Standorte enthalten.
Die Standorte dienen drei Funktionen.
Erstens ermöglichen sie eine präzisere
Steuerung der AD-Replikation als Domänen
dies können. Zweiten spielen Standorte eine
wichtige Rolle für die Art und Weise wie
AD-sensitive Clients einen Domänencon-
Anzeige 1: Erstellen der Standortverknüpfung Dallas-FortWorth
troller zur Netzwerkauthentifizierung finden. Und schließlich ermöglichen Standorte
eine lokale Client-/Server-Ressourcenauswahl für AD-sensitive Anwendungen (zum
Beispiel das Distributed Filesystem, kurz
DFS, von Windows 2000).
Eine gute AD-Standortstruktur verwaltet
die Replikation differenzierter als dies mit
Domänen allein bewerkstelligt werden
könnte. Die Replikation zwischen Domänencontrollern innerhalb eines Standorts (zum
Beispiel das gesamte Netzwerk, wenn keine
weiteren Standorte über den “Standardnamen-des-ersten-Standorts” hinaus erstellt
werden) erfolgt alle fünf Minuten, und die
Replikation verläuft, ohne die Daten zu komprimieren. Auch können Administratoren die
Replikation zwischen Domänencontrollern
innerhalb eines Standorts nicht zeitlich terminieren. AD nimmt an, dass es gute und
zuverlässige Verbindungswege innerhalb
eines Standorts gibt, sodass niedrige Latenzwerte ein höhere Priorität besitzen als das
Einschränken der Netzwerkauslastung.
Bei der Erstellung von AD-Standorten
lässt sich die Replikation auf verschiedene
Weisen steuern und konfiguriern. Es kann
definiert werden, wie oft die Replikation zwischen Standorten (das Mindestintervall für
die Replikation sind 15 Minuten) stattfinden
und wann die Replikation stattfinden soll.
Zwischen Standorten ist es möglich, spezielle
Verbindungen zu erstellen, um die Replikation zu veranlassen, virtuelle Pfade zu verwenden, und Standortrouten können verschiedene Kostenwerte zugeordnet werden,
um zu beeinflussen, welche Routen der
Replikationsverkehr bevorzugen soll. Innerhalb eines Standorts komprimiert AD den
Replikationsverkehr zwar nicht, jedoch wird
der Replikationsverkehr zwischen Standorten
von AD automatisch komprimiert. Das daraus resultierende Verkehrsvolumen erreicht
nur 10 bis 40 Prozent seiner Originalgröße.
Abbildung 1 veranschaulicht, wie Standlogfeld “Neues Objekt – Subnetz” aufzuruorte die Replikation steuern. In der Abbilfen. Hier ist der Name des Standorts einzudung besitzt eine fiktive Firma in Texas
geben, wobei keine Leerzeichen verwendet
Zweigstellen in Dallas, Fort Worth und Auswerden dürfen. (Das Dialogfeld “Neues
tin. Dallas ist die WAN-Zentrale der Firma
Objekt - Subnetz” lässt die Verwendung von
für die anderen beiden Firmenstandorte. In
Leerzeichen nicht zu. Es ist sinnvoll, sich an
diesem Beispiel wird jeder Ort einer Zweigdie DNS-Namenskonventionen zu halten, da
stelle zusammen mit seinen Computern als
Standortnamen in DNS-SRV-Datensätzen
Standort bezeichnet. Jeder Standort verfügt
gespeichert werden. Nun muss erst das
über mehrere IP-Subnetze in einer EthernetStandortverknüpfungsobjekt, das der StandLAN-Topologie, sodass die Standorte gut
ort verwenden soll (das heißt der Pfad, über
verbundene IP-Subnetze besitzen. Die
den dieser Standort mit anderen Standorten
Firma hat nur eine Domäne, und jeder
verbunden werden soll), und dann OK ausStandort besitzt mehrere Windows-2000gewählt werden. Daraufhin wird eine NachDomänencontroller.
richt angezeigt, die den Benutzer über weiZur Erstellung von Standorten gehören
tere Aktionen informiert:
mehrere Schritte. Es muss ein Standortob– zur Beendigung der Standortdefinition
jekt erstellt werden, diesem Standortobjekt
sind Standortverknüpfungen zur Verbindung
sind Subnetze hinzufügen, bereits vorhandes neuen Standorts mit anderen Standorten
dene Server müssen in den Standort verzu verwenden,
schoben werden, der Standort ist über Standortverknüpfungen mit anderen
Standorten zu verbinden, und die
Replikation muss zwischen den
Standorten angepasst werden.
Bevor Subnetze dem Standort hinzugefügt werden können, müssen
die Subnetze dem AD im Container “Subnetze” hinzugefügt werden. Dazu wird das Snap-in
“Active Directory-Standorte und
-Dienste” über die Liste “Verwaltung” im Menü “Start” gestartet,
der Container “Subnetze” mit der
rechten Maustaste angeklickt und
die Option “Neues Subnetz” ausgewählt. Für jedes Subnetz, das
eingerichtet werden soll, muss
eine Subnetzadresse und eine Subnetzmaske eingegeben werden,
die die Größe des Subnetzes definiert. Diese Parameter müssen
dann einem Standort zugewiesen Anzeige 2: Anpassen des Replikationsintervalls
und OK angeklickt werden.
Wenn ein feiner Differenzierungsgrad der Steuerung zwischen
Standorten nicht erforderlich ist,
können bei der Erstellung von
Standorten bestimmte Schritte
übergangen werden (etwa das
Erstellen von Standortverknüpfungen oder das Anpassen der Replikation). In der Firma in Texas werden nur die Standorte erstellt. Zur
Erstellung des Standortobjekts
muss der Container “Standorte”
im Snap-in-Fenster “Active Directory-Standorte und -Dienste” mit
der rechten Maustaste angeklickt
und die Option “Neuer Standort” Anzeige 3: Anpassen des Replikationsintervalls und des
ausgewählt werden, um das Dia- Zeitplans einer Verknüpfung
9
Abbildung 2: Standortverknüpfungen und Replikationssteuerung zwischen Standorten
– dem neuen Standortcontainer sind Subnetze hinzuzufügen,
– Domänencontroller sind zu installieren
oder in den Standort zu verschieben
– und der Lizenzierungscomputer für den
Standort ist auszuwählen.
Im nächsten Schritt werden Server in die
entsprechenden Standorte versetzt. Dazu
werden die Server mit der rechten Maustaste
angeklickt und die Option “Verschieben” im
Kontextmenü ausgewählt. Im Dialogfeld
“Server verschieben” wird der Zielstandort
ausgewählt. Die Server brauchen nach dem
Verschieben nicht erneut gestartet zu werden.
Falls nach dem Verschieben der ersten Server
neue Server erstellt werden und die neuen
Server IP-Adressen besitzen, die mit Standortsubnetzen übereinstimmen, werden die
neuen Server automatisch im Standort registriert, wenn sie der Domäne beitreten.
Besitzen die neuen Server keine IP-Adressen, die mit Standortsubnetzen übereinstimmen, werden sie in den Standort “Standardname-des-ersten-Standorts” eingegliedert.
Eine Definition unterschiedlicher Standorte, anstatt die Computer im Standort “Standardname-des-ersten-Standorts” zu belassen, bildet den ersten Schritt zur Verwaltung
der Replikation. Dadurch wird sichergestellt,
dass AD-sensitive Clients bevorzugt einen
Domänencontroller an ihrem lokalen Zweigstellenstandort auswählen, wenn einer verfügbar ist. Dies sorgt dafür, dass der Datenverkehr zur Anmeldeauthentifizierung für
jeden Standort nach Möglichkeit lokal bleibt.
Außerdem können das Replikationsintervall
zwischen diesen Zweigstellen von fünf
Minuten auf das Standardintervall von drei
Stunden ausgeweitet und die zwischen den
Zweigstellen replizierten Daten komprimiert
werden.
Die Beispielfirma in Texas hat mit Problemen der Netzwerkbandbreite zu kämpfen,
die eine differenziertere Standortkonfiguration erfordern. Das Verkehrsaufkommen der
AD-Replikation im Netzwerk zwischen Dal-
10
las und Fort Worth ist immer hoch, sodass es
sich empfiehlt, die Auswirkungen dieses Verkehrs auf die begrenzte WAN-Bandbreite
zwischen diesen beiden Standorten zu minimieren. Auch das AD-Replikationsverkehrsaufkommen zwischen Dallas und Austin ist
tagsüber sehr hoch, nachts jedoch nicht, da
die Zweigstelle um 19:00 Uhr schließt. Zur
Minimierung des Windows-2000-Replikationsverkehrs stehen verschiedene Einrichtungen zur Standortdefinition zur Verfügung,
und es können außerdem Standortfunktionen
zur Lösung des Verkehrsproblems eingesetzt
werden. Bevor nun diese Einrichtungen
näher beleuchtet werden, muss zunächst das
Konzept der Standortverknüpfungen (Site
links) erläutert werden.
Unter Standortverknüpfungen versteht
man virtuelle Leitungen (die VC, “Virtual Circuits”), die zwischen Standorten für den Windows-2000-Replikationsverkehr vorhanden
sind. In der Regel dienen Standortverknüpfungen zur Steuerung der Replikation zwischen zwei Mitgliedsstandorten. Zur Erstellung von Standortverknüpfungen stehen zwei
Transportmöglichkeiten zur Verfügung:
SMTP und RPC (Remote Procedure Call)
über TCP/IP (die Option erscheint als “IP” im
Snap-in). Die Standortverknüpfungen werden
in 95 Prozent aller Fälle mit dem IP-Transport
arbeiten. Den SMTP-Transport nutzen Standortverknüpfungen für Fälle wie beispielsweise den Verkehr über hoch unzuverlässige
Verbindungen zu einem fernen Standort oder
den Verkehr über eine Firewall, die RPC-Verkehr durch die Ports 137 und 139 nicht passieren lässt. Im Unterschied zur einer echten
Telekommunikationsleitung kann eine Standortverknüpfung jedoch mehr als zwei Standorte miteinander verbinden. Daher sind Standortverknüpfungen nützlich, wenn alle Standorte, die die Verknüpfung nutzen, dieselben
standortübergreifenden Replikationsmerkmale haben sollen. DEFAULTIPSITELINK,
die Standardstandortverknüpfung für Verbindungen des IP-Typs, fungiert als gemeinsam
genutzte Verknüpfung, da alle Standorte diese
Verknüpfung verwenden, wenn keine expliziten Verknüpfungen hinzugefügt werden.
Zur Konfiguration von Standortverknüpfungen im Snap-in “Active Directory-Standorte und -Dienste” muss das Pluszeichen
neben dem Container “Standortübergreifende
Transporte” angeklickt werden, um die Container für IP und SMTP anzuzeigen. Nun wird
der IP-Container mit der rechten Maustaste
angeklickt und die Option “Neue Standortverknüpfung” ausgewählt. Anzeige 1 enthält das
daraufhin angezeigte Dialogfeld “Neues
Objekt – Standortverknüpfung”. Im nächsten
Schritt wird die Standortverknüpfung DallasFortWorth in einer Punkt-zu-Punkt-Konfiguration erstellt. Außerdem kann Austin und der
“Standardname-des-ersten-Standorts” der
Liste von Standorten hinzugefügt werden, die
mit dieser Standortverknüpfung arbeiten.
Allerdings ist das Hinzufügen von “Standardname-des-ersten-Standorts” redundant zu
DEFAULTIPSITELINK, weil jeder neue
Standort standardmäßig DEFAULTIPSITELINK verwendet. Wenn alle Standorte der
erstellten Verknüpfung hinzugefügt werden,
ohne Kostenparameter oder den Zeitplan zu
ändern, funktioniert die Verknüpfung wie
DEFAULTIPSITELINK. Es ist sinnvoll, eine
Standortverknüpfung so zu benennen, dass sie
die verknüpften Standorte identifiziert (wobei
der Ausgangsstandort zuerst genannt werden
sollte, im beschriebenen Beispiel also DallasFortWorth), um sicherzustellen, dass die
Standortverknüpfungen in lesbarer Weise im
Verwaltungs-Snap-in aufgelistet werden.
Nach dem Hinzufügen der Standortverknüpfungen kann die Replikation zwischen
den Standorten angepasst werden, um die
Replikation auf die Geschäftsanforderungen
der einzelnen Zweigstellen zuzuschneiden.
Zur Anpassung der Replikation zwischen den
Standorten für die Firma in Texas muss das
Standortverknüpfungsobjekt Dallas-FortWorth unter dem IP-Container des Containers
“Standortübergreifende Transporte” mit der
rechten Maustaste angeklickt werden, um die
Eigenschaften der Standortverknüpfung Dallas-FortWorth zu bearbeiten. Das Dialogfeld
für die Eigenschaften einer Standortverknüpfung sieht dem ähnlich, das bei der ursprünglichen Erstellung der Verknüpfung angezeigt
wurde, jedoch sind jetzt drei zusätzliche
Steuerelemente für Kosten, Replikationsintervall und Replikationszeitplan enthalten.
Mit Hilfe der Replikationssteuerung im
Dialogfeld der Eigenschaften für Dallas-FortWorth, das in Anzeige 2 zu sehen ist, wird das
Replikationsintervall für Dallas-FortWorth
vom Standardwert 3 Stunden auf den Wert 1
Stunde verringert. Die Replikation wird nun
häufiger, jedoch in kleinerem Umfang stattfinden, und die Zeitdauer zur Verbreitung über
das Unternehmen zwischen den Standorten
wird verkürzt. Zur Vermeidung eines hohen
Verkehrsaufkommens für die Windows-2000Replikation zwischen Dallas und Austin
während der täglichen Arbeitszeit kann die
Standortverknüpfung Dallas-Austin zur Aussetzung der Replikationstätigkeit zwischen
7:00 und 19:00 Uhr konfiguriert werden wie
in Anzeige 3 zu sehen ist. Außerdem lässt sich
das Replikationsintervall von 180 Minuten
auf 30 Minuten reduzieren, sodass Änderungen, die an den anderen Standorten vor 7:00
Uhr auftreten, unverzüglich nach Austin repliziert werden. Abbildung 2 stellt den Standortaufbau mit den Standortverknüpfungen dar,
die für das Beispiel der Firma in Texas erstellt
wurden.
Der Standortaufbau beeinflusst die Auswahl von Windows-2000-Domänencontrollern zur Netzwerkauthentifizierung durch
standortsensitive Clients. Unter standortsensitiven Clients versteht man Clients unter Windows 2000 Professional (Windows 2000 Pro)
beziehungsweise unter Windows 9x mit DS.
In NT 4.0 wählt ein Client einen Domänencontroller aus der Domäne aus, zu der das
Konto des Clients gehört. Die Liste von
Domänencontrollern, die von WINS zurückgeliefert wird, beeinflusst die Domänencontrollerauswahl, jedoch ist nicht gewährleistet,
dass der Client den im Netzwerk am nächsten
liegenden Domänencontroller erreicht.
Umfasst zum Beispiel eine Domäne die Ostküste der USA und Europa, könnte ein Server
in Frankfurt die Domänenauthentifizierung
für Clients in New York durchführen. Bis zu
einer Änderung des sicheren Kanals der NewYork-Clients müssen Client-Anforderungen
zweimal den Atlantik überqueren, um Zugriff
auf eine Ressource in New York zu erhalten.
Zwar kann mit Hilfe verschiedener Dienstprogramme (zum Beispiel Setprfdc) eine Auswahl manuell erzwungen werden, ein guter
Windows-2000-Standortaufbau hingegen
kann den Einsatz eines Dienstprogramms zur
permanenten Überwachung und Beseitigung
des Problems gänzlich überflüssig machen.
Unter Windows 2000 versuchen standortsensitive Clients, die mit einem DNS-Server arbeiten, der SRV-Datensätze (nach den
Vorgaben der Internet Engineering Task Force
(IETF) Request for Comments (RFC) 2052)
und die dynamische Aktualisierung (also den
RFC 2136) unterstützt, eine Sitzung mit
einem verfügbaren Domänencontroller am
Standort des jeweiligen Clients einzurichten,
bevor sie nach anderen Domänencontrollern
suchen. Falls ein Client am eigenen Standort
keinen Domänencontroller findet und an
anderen Standorten keine Domänencontroller
vorhanden sind, die als für den Standort verfügbar definiert wurden, durchsucht der Client
die gesamte Domäne wie unter NT 4.0.
Für die Firma in Texas bedeutet dies, dass
Benutzer in ihren lokalen Netzwerken authentifiziert werden, und zwar unabhängig
von Netzwerkverkehrsbedingungen oder
Domänencontrollergeschwindigkeiten. Ein
Client in Dallas wählt immer einen Domänencontroller in Dallas zur Netzwerkauthentifizierung aus, und Benutzer in Austin werden zu
keiner Zeit in die hoch ausgelastete Leitung
zwischen Dallas und Austin geraten. Der Prozess zur Domänencontrollerauswahl eines
Windows-2000-Clients ist kompliziert, so
dass sich der Autor die Einzelheiten für einen
zukünftigen Artikel aufspart. Weitere Informationen zur Domänencontrollerauswahl enthalten die Microsoft-Hilfedateien zu Windows 2000 (deutsche Version der Windows
2000 Advanced Server Help Files) unter
http://www.microsoft.com/win dows 2000/
downloads/otherdownloads/help files/adserver.asp?lang=de.
Der Aufbau von Standorten beeinflusst
auch die lokale Ressourcenauswahl AD-fähiger Client-/Server-Anwendungen. DFS kann
gut zur Demonstration dieser Stand-
Abbildung 3: Lokale Client-/Server-Ressourcenauswahl
ortfunktion herangezogen werden, weil DFS
Standorte erkennt. DFS ermöglicht Administratoren die Erstellung einer logischen Ordnerhierarchie leicht einprägsamer Namen, die
physischen UNC-Namen (Uniform Naming
Convention, das heißt Namen der Form \\server\freigabe) im gesamten Netzwerk zugeordnet werden. Die Einrichtung der DFS-Replikationsgruppen ermöglicht die Zuordnung
eines logischen Ordners zu mehreren UNCNamen im Netzwerk, wobei jeder UNCName identische Daten enthält. Wenn die Server, auf denen sich die UNC-Namen befinden
(das heißt Replikations-Server) Windows2000-Server sind, die am gleichen Standort
wie der standortsensitive Client registriert
sind, bevorzugt der Client einen ReplikationsServer am eigenen Standort.
Zum Beispiel möchte ein Benutzer in Austin in der fiktiven Firma in Texas Software
vom Server \\bigtex\software herunterladen.
Die Freigabe \software dieses Servers ist eine
DFS-Replikationsgruppe mit Replikaten in
Fort Worth, Dallas und Austin. Der Windows2000-Pro-Benutzer in Austin, der eine Verbindung zu \\bigtex\software herstellt, richtet eine
Sitzung mit \\aus01\software ein wie in Abbildung 3 dargestellt ist. Dieses Beispiel zeigt,
dass ein standortsensitiver Client AD-Standorte in den Aufbau einer Client-/ServerAnwendung integrieren kann, um eine Verbindung zu einem generischen UNC-Namen
herzustellen, und dass Windows 2000 den
Client dann an einen Anwendungs-Server seines eigenen Standorts vermittelt.
Eine Windows-2000-Installation kann
unmittelbaren Nutzen aus einem gut geplanten Standortdesign ziehen, insbesondere,
wenn das Netzwerk hoch ausgelastet ist. Bei
der Planung des Standortaufbaus empfiehlt
sich eine enge Zusammenarbeit mit der WANTechnikergruppe, um die Auswirkungen von
Windows 2000 auf das Netzwerk möglichst
gering zu halten. Der Standortaufbau setzt
eine Reihe von Kompromissen und Entscheidungen voraus, sodass es erforderlich ist, sich
vor Beginn der Standorterstellung tiefer in
dieses Thema einzuarbeiten. Im nächsten
Monat werden an dieser Stelle einige fortgeschrittene Themen zur Standorttopologie und
zum Standortaufbau behandelt. Es lohnt sich
also, dranzubleiben.
(Sean Deuby)
Sean Deuby ist leitender Windows-2000- und
Windows-NT-Systemingenieur bei Intel,
wobei sein Spezialgebiet das Windows-2000Design für Unternehmen ist. Er ist Verfasser
der Publikation “Windows 2000 Server:
Planning and Migration” (Macmillan). Er
ist unter [email protected] zu erreichen.
11
Exchanges findige
Zauberlehrlinge
Bei richtiger Anwendung vollbringen Isinteg und Eseutil diagnostische Magie.
Daher sollten sich Exchange-Administratoren mit diesen Diagnose- und
Reparaturwerkzeugen befassen.
Dieser Artikel erläutert die richtige Verwendungsweise der Diagnose- und Reparaturwerkzeuge Isinteg und Eseutil von
Exchange Server.
Eines der am häufigsten angesprochenen
Themen in Mailing-Listen und Newsgroups
zu Exchange Server bezieht sich auf die beiden Diagnose- und Reparatur-Tools, die mit
Exchange Server 5.5 geliefert werden: Isinteg und Eseutil.
Missverständnisse über den Zweck und
die Funktionsweise dieser Tools sowie über
ihren geeigneten Einsatz auf Servern sind
keine Seltenheit. Da diese Tools zur Fehlerbehebung und Wiederherstellung für
Exchange Server gehören, empfiehlt es sich,
etwas über sie zu lernen, bevor sie tatsächlich benötigt werden. Und ebenso wie Feuerwaffen, rezeptpflichtige Medikamente
oder Bauwerkzeuge bergen Wiederherstellungs-Tools aber auch Risiken, wenn ihre
Funktionsweise und ihr Zweck nicht klar
sind.
Bevor nun jedoch der Zweck und die
Handhabung dieser Tools erläutert werden
können, sind gute Kenntnisse über die
Datenbanken des Informationsspeichers (IS,
der Information Store) und ihrer Funktionsweise erforderlich.
Die logischen
Strukturen
Vor einer näheren Betrachtung der beiden Tools sollen zunächst die private und
öffentliche Datenbank des Informationsspeichers (IS) priv.edb und pub.edb kurz
beleuchtet werden. Mancher hält die
Datenbankdateien des Informationsspeichers vielleicht für nichts anderes als
große Stücke von Plattenspeicherplatz. In
gewisser Weise ist dies gar nicht falsch,
nämlich insofern, als dass für die BefehlsShell oder ein Tool wie Windows Explorer
die Dateien priv.edb und pub.edb wie jeder
andere Dateityp aussehen, nur eben
größer.
12
In Wirklichkeit jedoch sind die IS-Datenbankstrukturen recht komplex. In jeder
EDB-Datei befindet sich eine komplizierte
Anordnung voneinander abhängiger Daten,
die vom IS und dem Client in die Gestalt
gebracht werden, die als Postfach oder
Nachricht angezeigt werden.
Die Exchange Server Extensible Storage
Engine (ESE) speichert alle Daten in den ISDatenbanken in speziellen Strukturen, die
als B-Baumstrukturen (B-Trees) bezeichnet
werden. Diese Strukturen ermöglichen ein
effizientes und schnelles Indizieren und
Abrufen des Inhalts der Datenbanken.
Gerade solche Merkmale sind für eine
Anwendung wie Exchange Server 5.5 unerlässlich. Eine ESE-Tabelle ist eine Sammlung von B-Baumstrukturen. Wie auch
andere Datenbanktabellen setzt sich jede
ESE-Tabelle aus Zeilen und Spalten zusammen.
Wenn eine Spalte Daten enthält, die
weniger als 1 KByte Platz beanspruchen,
speichert ESE die Daten in der Tabelle
selbst. Sind die Daten länger als 1 KByte,
speichert ESE die Daten in getrennten BBaumstrukturen für lange Werte (long
value) und fügt einen Zeiger auf diese Daten
in die ursprüngliche Tabelle ein. Dieses Verfahren macht die Größe von Tabellen für
nicht lange Werte vorhersagbar und bietet
einen Leistungsvorteil, weil ESE immer
bekannt ist, wie viele Daten zu lesen oder zu
schreiben sind, sodass eine effizientere Leistung erzielt werden kann als wenn diese
Informationen nicht bekannt wären.
Dass Speichern nur einer Instanz (Singleinstance Storage) ist die Schlüsselfunktion
von Exchange Server, die von diesem Verfahren abhängig ist.
Wenn beim Speichern nur einer Instanz die
gleiche Nachricht an 25 Empfänger auf einem
einzigen Server gesendet wird, speichert der
IS nur eine Kopie der Nachricht in der Datenbank, während die Postfächer der anderen 24
Empfänger Zeiger auf die entsprechende BBaumstruktur erhalten. Ein logischer Fehler in
einer B-Baumstruktur (zum Beispiel ein
Baumstruktureintrag, der auf nicht vorhandene Daten zeigt) kann sich auf mehrere Postfächer und öffentliche Ordner auswirken.
Die physischen
Strukturen
Eine ESE-Datenbank ist eine Sammlung von 4-KByte-Seiten. Eine Datenbankseite lässt sich mit einer Magazinseite
vergleichen: Jede Seite kann die gleiche
Höchstmenge an Daten enthalten, und der
Besitzer der Seite entscheidet, in welchem
Umfang diese Kapazität genutzt werden
soll. Abhängig von der Größe kann sich ein
Abschnitt von Informationen (zum Beispiel dieser Artikel oder die ESE-Tabelle,
die Nachrichtenanhänge verfolgt) über
eine beliebige Anzahl von Seiten
erstrecken. Ein 1 MByte großer Powerpoint-Anhang nimmt etwas mehr als 250
Seiten (einschließlich des Platzes für
Systemaufwand) ein. ESE nutzt Seiten, um
relativ kleine Datenabschnitte auf Anforderung effizient zu lesen und zu schreiben.
Seiten und die effiziente Indizierung, die
das B-Baumstruktursystem ermöglicht,
bieten selbst unter großer Belastung eine
gute Leistung.
Eine Seite kann Daten und Zeiger auf
andere Seiten enthalten. Zum Beispiel
erstreckt sich eine 8 KByte große Nachricht mindestens über zwei Seiten: Die
erste Seite enthält beinahe 4 KByte Daten
sowie einen Zeiger auf die zweite Seite.
Seiten besitzen außerdem einen Kopfbereich (Header), der verschiedene Elemente
enthält wie zum Beispiel einen Fehlerprüfcode, der als Prüfsumme (Checksum)
bezeichnet wird. Mit Hilfe der Prüfsumme
in den Kopfdaten können Seiten bei Sicherungs- und Wiederherstellungsoperationen
überprüft werden.
Falls die Prüfsumme des Kopfbereichs
nicht mit der Prüfsumme übereinstimmt,
die von ESE beim Lesen oder Schreiben
der Seite berechnet wird, protokolliert ESE
einen Fehler (Ereignis 1018) im Ereignisprotokoll, um den Benutzer zu warnen,
dass die physische Datenstruktur eventuell
beschädigt sein könnte.
Prüfung auf der
höheren Ebene
Das Tool Isinteg prüft die logische Integrität des IS, was nichts anderes heißt, als
dass Isinteg die Postfächer, öffentlichen
Ordner und andere Teile des IS nach fehlenden Elementen absucht. Das Tool arbeitet wie ein Lektor: Isinteg liest und prüft
Tabellen und B-Baumstrukturen, mit denen
ESE-Seiten in ihrer logischen Struktur
organisiert werden.
Darüber hinaus schaut das Tool nach
“verwaisten“ Objekten, das heißt nach
Objekten, die falsche Werte oder unmögliche Verweise (Referenzen) enthalten. Isinteg kann 33 Tests durchführen, von denen
einige nur für eine bestimmte Datenbank
funktionieren (zum Beispiel ist Isinteg in
der Lage, den Test Newsfeed nur am öffentlichen Informationsspeicher ausführen).
Isinteg besitzt zwei Modi. Im Standardmodus führt das Tool die Tests aus, die
vom Benutzer angegeben werden, und
meldet die Befunde.
Im Reparaturmodus (der mit dem optionalen Schalter -fix gesteuert wird) führt
Isinteg die angegebenen Tests aus und versucht, alle Fehler zu beheben, die das Tool
beheben kann. Der Reparaturprozess lässt
sich mit einem Schiebe-Puzzle vergleichen: Isinteg bewegt Informationen von
einer Stelle zu einer anderen, wirft jedoch
niemals etwas über Bord.
Isinteg ist nicht so unverhohlen zerstörerisch wie das Tool Eseutil es sein kann.
Jedoch besteht bei jeder Ausführung von
isinteg -fix das (zwar kleine) Risiko, dass
einige Daten verloren gehen.
Abgesehen von dieser Verwendung als
Prüf- und Reparatur-Tool besitzt Isinteg
eine weitere wahrscheinlich bekanntere
Anwendung: Nach der Wiederherstellung
einer Offline-Sicherung kann das Tool eingesetzt werden, um die global eindeutigen
IDs (GUIDs – Globally unique IDs) für
Elemente im IS zu korrigieren.
Wenn die GUIDs nicht korrigiert werden, kann der IS nicht starten, und im
Ereignisprotokoll wird das Ereignis 1011
protokolliert. Bei der Wiederherstellung
einer Online-Sicherung ist die Verwendung von Isinteg nicht erforderlich, weil
Exchange-sensitive Sicherungs-Software
die GUIDs bei der Ausführung korrigiert.
Handwerker
auf der unteren Ebene
Wenn Isinteg ein Lektor ist, dann ist
Eseutil ein Klempner. Eseutil durchsucht
die physischen Strukturen in den Datenbanken nach physischen Fehlern wie zum
Beispiel falsche Seitenprüfsummen und
fehlerhafte Zeiger von einer Seite auf die
nächste und korrigiert sie. Darüber hinaus
bietet dieses Werkzeug weitere nützliche
Funktionen. Alles in allem verfügt das Tool
über sechs Arbeitsmodi. Eseutil kann die
Kopfdaten jeder Seite überprüfen, um
sicherzustellen, dass sie mit den Daten der
Seite in Einklang stehen.
Dieser Integritätsprüfmodus kopiert
den Prozess, der bei der Ausführung einer
Online-Sicherung stattfindet. Zudem ist
Eseutil in der Lage, ein Abbild der physischen Strukturen in einer Form zu erstellen, die für Menschen lesbar ist (DumpModus). Das Tool verdichtet die Daten im
so genannten Defragmentierungsmodus,
indem es teilweise gefüllte Seiten zu einer
kleineren Zahl vollständig gefüllter Seiten
zusammenfasst. Und Eseutil kann eine
Datenbank, die von einer früheren Version
von ESE generiert wurde, auf ESE97
aktualisieren, welches die Version ist, die
mit Exchange Server 5.5 geliefert wird
(Aktualisierungsmodus).
Des Weiteren verfügt Eseutil über zwei
voneinander getrennte Korrekturmodi. Im
Wiederherstellungsmodus (Recovery
mode) versucht Eseutil alles zu korrigieren
was möglich ist, ohne die Daten der Seiten
zu berühren.
In diesem Modus kann das Tool Tabellenverknüpfungen oder B-Baumstruktureinträge ändern, aber es schneidet keine
fehlerhaften Seiten ab und löscht sie auch
nicht. Im Reparaturmodus (Repair mode)
ändert oder löscht Eseutil alles was notwendig ist, um so als praktisch allerletzte
Notmaßnahme noch zu retten was zu retten
ist.
Verwendung von Isinteg
Zur Ausführung der kompletten IsintegTestreihe in der optimalen Reihenfolge zur
Erkennung und Behebung der maximalen
Anzahl von Problemen dient der folgende
Befehl:
isinteg -pri -test alltests
Dieser Befehl weist Isinteg an, alle Tests
am privaten IS durchzuführen. Der öffentliche IS kann durch Angabe des Schalterspub
anstelle von (bzw. zusätzlich zu) -pri in der
Befehlszeile überprüft werden. Außerdem
besteht die Möglichkeit, auch einen einzelnen Test anzugeben. Zur Anzeige einer
kompletten Liste der verfügbaren Tests wird
in die Befehlszeile nur folgender Befehl eingegeben:
isinteg
Wenn das Tool Isinteg die erkannten Probleme zudem korrigieren soll, muss der
Schalter -fix hinzugefügt werden. Die beste
Einsatzmethode ist eine zweifache Ausführung von Isinteg: einmal, um nach Fehlern zu suchen, und ein zweites Mal, um
diese Fehler zu beheben.
Da einige Probleme schwerwiegender als
andere sind, sollte sich der Administrator
erst einen Eindruck von der Situation verschaffen, bevor er einen Versuch zur Wiederherstellung der IS-Datenbanken in ihrem
ursprünglichen, tadellosen Zustand unternimmt.
Bei einer Wiederherstellung einer OfflineSicherung in Exchange Server 5.5 muss
sichergestellt werden, dass der Verzeichnisspeicher und die Systemaufsicht (SA– System
Attendant) aktiv sind. Dann muss der Befehl
isinteg -patch -pub (oder -pri) ausgeführt werden, bevor der IS starten kann.
Verwendung von Eseutil
Eseutil ist nicht ganz so übersichtlich wie
Isinteg, da dieses Tool mehr Funktionen
besitzt. In diesem Artikel werden die Modi
für Speicherabbild (Dump) und Aktualisierung (Update) nicht weiter berücksichtigt,
da sie keine für Reparaturen relevante Funktionen und nur unter ganz bestimmten und
seltenen Umständen von Nutzen sind. Vielmehr rücken hier die anderen vier Modi in
den Mittelpunkt des Interesses. Die ersten
beiden Modi, die hier behandelt werden,
sind recht harmlos. Die zweiten beiden sind
indes gefährlicher.
◆ Defragmentierungsmodus (eseutil /d).
Eseutil erstellt eine Kopie der Zieldatenbank, liest jede Seite und versucht, die
Kopie so weit wie möglich zu verdichten.
Nach Abschluss dieses Prozesses ersetzt
Eseutil die Originaldatenbank durch die
Kopie. Dieser Modus benötigt rund 110
Prozent des Plattenspeicherplatzes, der
für die Zieldatenbank erforderlich ist.
◆ Integritätsprüfmodus (eseutil /g). Eseutil
durchsucht die Datenbankseiten nach
Fehlern oder Diskrepanzen zwischen den
Kopfdaten und dem Inhalt der Seiten.
Eine Korrektur der erkannten Fehler wird
13
vom Tool jedoch nicht durchgeführt.
◆ Wiederherstellungsmodus (eseutil /r).
Eseutil versucht, die Datenbank zu bereinigen, ohne Daten aus Seiten zu entfernen. In diesem Modus arbeitet das Tool in
ähnlicher Weise wie Scandisk oder
Chkdsk, indem es versucht, Verbindungen zwischen Datenbankelementen zu
berichtigen, ohne die Elemente selbst
anzutasten.
◆ Reparaturmodus (eseutil /p). Dieser
Modus sollte R-I-S-I-K-O-Modus
heißen. Im Reparaturmodus hat Eseutil
die Lizenz zum Löschen so vieler Daten
wie nötig sind, um die Datenbank in
einen fehlerfreien und konsistenten
Zustand zurückzuversetzen. Manchmal
ist dieser Modus die einzige Möglichkeit,
einen widerspenstigen Speicher wieder
flott zu machen, allerdings ist das Risiko
eines Datenverlusts real.
Zweck der Tools
Zu wissen, welches Tool zu verwenden
ist, um ein gewünschtes Ergebnis zu erzielen, ist eine entscheidende Fertigkeit, die
Exchange Server-Administratoren besitzen müssen.
Die folgenden vergleichsweise einfachen Leitlinien können bei der Bestimmung behilflich sein, welches Tool zu verwenden ist und in welchen Fällen, je nachdem, welche Fehler im privaten oder
öffentlichen Speicher vorliegen (beziehnungsweise vom Administrator vermutet
werden).
Den Anfang soll das etwas weniger gefährliche Tool Isinteg machen. Da Isinteg
nur die logische (im Gegensatz zur physischen) Struktur der Datenbank untersucht
und da dieses Tool in seinem Standardmodus die Datenbank nur untersucht (und
nicht korrigiert), ist die Verwendung des
Tools relativ gefahrlos. Dem Autor ist kein
Fall bekannt, bei dem die Ausführung von
Isinteg an einer einwandfreien Datenbank
zu einem Problem geführt hätte, jedoch
sollte das Tool trotzdem mit Vorsicht
genutzt werden.
Die meisten Administratoren führen
Isinteg zum ersten Mal nach der Wiederherstellung einer Offline-Sicherung aus,
wobei das Tool mit dem Schalter -patch
aufgerufen werden muss. Jedoch lässt sich
Isinteg auch in verschiedenen anderen Fällen sinnvoll nutzen:
◆ Wenn eine Elementanzahl nicht konsistent ist. Zum Beispiel, wenn ein Postfach,
das 100 Nachrichten enthält, seine Größe
mit einer anderen Zahl als 100 angibt, kön-
14
nen einige der Zähler und Zeiger im privaten IS fehlerhaft sein.
◆ Wenn der Befehl “Postfach verschieben“ des Menüs “Extras“ für ein
bestimmtes Postfach fehlschlägt. In diesem Fall kann die logische Struktur des
Postfachs (oder einer Nachricht in diesem Postfach) fehlerhaft sein.
◆ Wenn der IS oder der Mail-Client wiederholt abstürzt, wenn ein Benutzer versucht, auf eine bestimmte Nachricht
oder ein bestimmtes Postfach zuzugreifen. In den meisten Fällen führt ein Seitenfehler (zu dessen Behebung Eseutil
erforderlich ist) zu dem Absturz, jedoch
können mit Hilfe von Isinteg andere
Klassen von Fehlern ermittelt werden.
Für Administratoren, die regelmäßige
Wiederherstellungstests durchführen, um
die Wiederherstellbarkeit der Sicherungen
zu gewährleisten, ist eine Ausführung von
Isinteg für die Datenbanken nach der Wiederherstellung ein sinnvolles Verfahren.
Administratoren, die keine regelmäßigen
Wiederherstellungstests durchführen, sollten damit anfangen, sobald sie diesen Artikel zu Ende gelesen haben!
Falls Isinteg Fehler meldet, kann das
Tool auf dem Produktions-Server ausgeführt werden.
Wie steht es nun mit Eseutil? Die Ausführung von Eseutil im Integritätsprüfmodus ist in jedem Fall gefahrlos, wenn auch
zeitaufwendig. Administratoren, die ihren
Mitarbeitern ein gutes Beispiel geben
möchten, sollten
isinteg -test alltests
und
eseutil /g
für den IS jedes Mal dann ausführen, wenn
sie eine Sicherung auf ihrem Test-Server
wiederherstellen. Der Defragmentierungsmodus ist ebenfalls sicher, allerdings in der
Regel auch nicht erforderlich. Exchange
Server 5.5 führt eine Online-Defragmentierung im Rahmen der täglichen IS-Wartung durch.
Defragmentieren ist notwendig
Durch die Online-Defragmentierung werden alle leeren Seiten an das Ende der
Datei versetzt, ohne dass die Datenbankdatei geschrumpft wird, wie das bei Eseutil
der Fall ist. Administratoren, die eine Operation durchführen, bei der viele Daten aus
dem Speicher wegversetzt werden (zum
Beispiel durch Verschieben zahlreicher
Postfächer auf einen anderen Server oder
Umsetzen einer Reihe von Replikaten
öffentlicher Ordner), hilft eine OfflineDefragmentierung, den früher genutzten
Speicherplatz wieder nutzbar zu machen.
Die beiden Reparaturmodi sind mit
größerer Vorsicht zu genießen. Der Autor
empfiehlt, diese Modi nicht auszuführen,
sofern nicht eine von zwei Bedingungen
eintritt: Der um Hilfe gebetene ProduktSupport von Microsoft (Microsoft Product
Support Services – PSS) gibt eine entsprechende Anweisung, oder die Notwendigkeit, Daten wiederherzustellen, ist so groß,
dass keine andere Möglichkeit zu bestehen
scheint (falls es keine Möglichkeit gibt,
muss der Kundendienst ohnehin zu Hilfe
gerufen werden).
Nur mit Backup sicher genug
Dieser Standpunkt lässt sich etwas
lockern, wenn eine gute Sicherung vorhanden ist, die auf einem Test-Server wiederhergestellt werden kann. In diesem Fall
kann die Sicherung auf der Testmaschine
wiederhergestellt werden, Eseutil ausgeführt und ermittelt werden, ob der
anschließend vorhandene Speicher weiterhin verwendbar ist, bevor diese Operation
auf einem Produktions-Server ausgeführt
wird.
Isinteg und Eseutil sind nicht an sich
gefährlich, jedenfalls nicht mehr als eine
Kettensäge oder ein Kanister Benzin. Ein
Einsatz dieser Tools ohne vorherige Kenntnis ihrer Funktionen und potenziellen Wirkungen ist jedoch tollkühn.
Insbesondere ist zu beachten, dass für
die Ausführung dieser Tools die ExchangeDienste heruntergefahren werden müssen,
was nicht einfach unbedacht geschehen
kann, sodass bei ihrer Ausführung auf Produktions-Servern eine Ausfallzeit einkalkuliert werden muss. Der Einsatz dieser
Produkte sollte also sorgfältig geplant werden, denn das Postfach, das gerettet wird,
könnte ja auch das eigene sein.
(Paul Robichaux)
Paul Robichaux ist MCSE, ein Geschäftsführer von Robichaux & Associates und
Berater für die Migration auf Windows NT
und Microsoft Exchange Server. Er ist Verfasser verschiedener Veröffentlichungen,
zu denen auch “Managing Microsoft
Exchange Server” (O’Reilly) zählt, und
Urheber der Wegsite http://www.exchangefaq.org. Er ist unter getting-started@
robichaux.net zu erreichen.
Unbeaufsichtigte Installationen mit Windows 2000
Antwortdateien für unbeaufsichtigte Installationen sind wesentlich leistungsstärker und auch einfacher zu erstellen als bei Windows NT 4.0
Die RIS-Dienste bieten eine angenehme
Möglichkeit, Windows-2000-ProfessionalDatenträgerbilddateien (Disk Images) über
das Netzwerk zu verteilen. Allerdings setzt
RIS ein eingerichtetes Active Directory (AD)
voraus. Hiermit drängt sich die Frage auf:
Welche Möglichkeiten zur Vereinfachung
von Installationen gibt es, wenn kein AD
zum Einsatz kommt? Hier bieten sich eine
Datei namens winnt.sif sowie der neue Setup
Manager und WinINSTALL LE von Windows 2000 Professional an, die Installationen
vereinfachen können. Ebenso wie NT 4.0
ermöglicht Windows 2000 Professional die
Erstellung einer ASCII-Textdatei, die als
Antwortdatei bezeichnet wird und die Antworten auf Fragen enthält, die vom SetupProgramm gestellt werden.
Eine neue Einrichtung ist die Datei
winnt.sif. Diese Datei winnt.sif ist nicht mit
der Datei winnt.sif von NT zu verwechseln,
die eine andere Funktion hat. Jeder, der
bereits eine unbeaufsichtigte Installation
unter NT 4.0 durchgeführt hat, wird wissen,
dass zur Übergabe eines Skripts zur unbeaufsichtigten Installation an das Setup-Programm von NT das Betriebssystem so eingerichtet werden muss, dass es entweder das
Winnt- oder das Winnt32-Programm verwendet. Beide Programme verwenden viel
Zeit darauf, Dateien hin- und herzukopieren,
wobei die Dauer der unbeaufsichtigten
Installation beträchtlich verlängert wird.
Demgegenüber ermöglicht Win2K die Ausführung eines Installationsskripts durch einfaches Booten von der Windows-2000-Professional-CD-ROM. Wenn das Betriebssystem von der CD-ROM gestartet wird, sucht
das Setup-Programm von Windows 2000 im
Laufwerk A nach einer 3,5-Zoll-Diskette, die
von Setup als Antwortdatei verwendet wird.
Dazu muss vor der Ausführung von Setup
eine Datei Winnt.sif erstellt und auf einer
3,5-Zoll-Diskette gespeichert werden. Die
Antwortdatei muss nicht kompliziert sein:
Das Listing zeigt eine Datei, die im Test des
Autors funktionierte. Da viele der Zeilen
manchem Leser, der bereits mit einem NT4.0-Installationsskript gearbeitet hat, vertraut
vorkommen werden, konzentriert sich dieser
Artikel auf die Erläuterung der neuen Zeilen.
Nach den Erfahrungen des Autors spielt
in den Skriptdateien für die unbeaufsichtigte
Installation die Groß-/Kleinschreibung
keine Rolle. Eine Ausnahme bilden Kennwörter, bei deren Angabe in der Skriptdatei
natürlich auf die korrekte Groß-/Kleinschreibung zu achten ist. Der erste Abschnitt
[Data] enthält einen einleitenden Code, der
im Grunde nur bedeutet, dass Setup dem
Benutzer keine Fragen stellen soll, weil es
sich um eine unbeaufsichtigte Installation
handelt.
Viele Befehle des Abschnitts [Unattended] sind nicht neu, abgesehen von dem
Befehl UnattendMode, der neu ist und ebenfalls besagt, dass Setup dem Benutzer keine
Fragen stellen soll. Repartition=Yes weist
das Setup-Programm von Windows 2000
Professional an, die Installation damit zu
beginnen, alle Partitionen von der Festplatte
des Computers zu löschen. Anschließend
erstellt Setup automatisch eine einzige große
NTFS-Partition mit dem gesamten Speicherplatz der Festplatte und installiert Windows 2000 Professional auf dieser Partition.
Diese Funktion ist sehr praktisch und erspart
einige Schritte, die für unbeaufsichtigte
Installationen unter NT 4.0 häufig erforderlich waren.
Im Abschnitt [GuiUnattended] kann die
Angabe AdminPassword=* gemacht werden,
wenn ein leeres Administratorkennwort
erwünscht ist . Falls kein leeres Administratorkennwort verwendet werden soll, kann in
dieser Zeile das Kennwort angegeben werden, zum Beispiel AdminPassword=sword.
Der Befehl OEMSkipRegional=1 weist
Setup an, den Benutzer nicht zur Eingabe
regionaler Einstellungen aufzufordern.
Der Abschnitt [UserData] hat sich gegenüber NT 4.0 nicht verändert, obwohl jetzt leider keine Produkt-ID mehr verwendet werden
kann, die nur aus den Ziffern 1 bestand. [FavoritesEx], [Branding], [URL] und [Proxy] sind
vier neue und nützliche Abschnitte, in denen
die Konfiguration von Internet Explorer (IE)
5.0 definiert werden kann.
[Data]
AutoPartition=1
MsDosInitiated=”0”
UnattendedInstall=”Yes”
[Unattended]
UnattendMode=FullUnattended
OEMSkipEula=Yes
OEMPreinstall=No
TargetPath=\WINNT
Repartition=Yes
[GuiUnattended]
AdminPassword=*
OEMSkipRegional=1
TimeZone=35
OemSkipWelcome=1
[UserData]
FullName=”Mark Minasi”
OrgName=MR&D
ComputerName=CA
ProductID=”AAAAA-BBBBBCCCCC-DDDDD-EEEEE”
[FavoritesEx]
Title1=”Mi H-Page.url”
URL1=”http://www.minasi.com”
[Branding]
BrandIEUsingUnattended=Yes
[URL]
Home_Page=about:blank
[Proxy]
Proxy_Enable=0
Use_Same_Proxy=1
[Identification]
JoinDomain=acme.com
DomainAdmin=adminguy
DomainAdminPassword=sword
[Networking]
InstallDefaultComponents=Yes
Beispiel für die Antwortdatei Winnt.sif
Der Abschnitt [Identification] ist der gleiche wie in NT 4.0. Im Listing weist dieser
Abschnitt Setup an, ein Maschinenkonto für
einen neuen Computer in der Windows2000-Domäne acme.com zu erstellen, ein
Vorgang, für den ein Administratorname und
ein Kennwort erforderlich ist. Dieser Abschnitt funktioniert ebenso gut zur Erstel-
15
16
[UserData] an. Auch eine Angabe für die
Zeile Repartion=Yes im Abschnitt [Unattended] wird nicht angeboten, sodass diese
Zeile auch manuell hinzugefügt werden
muss, wenn eine neue Partition angelegt
werden soll. Darüber hinaus kann es sinnvoll
sein, einen Abschnitt namens [Components]
hinzuzufügen, der es ermöglicht, Setup an
der Installation bestimmter Anwendungen
zu hindern. Zum Beispiel könnten folgende
Zeilen hinzugefügt werden:
[Components]
solitaire=Off
minesweeper=Off
mplay=Off
Diese Angaben bewirken, dass ein
System ohne Solitär, Minesweeper und
Medienwiedergabe installiert wird. In der
Datei Unattend.doc, die sich in deploy.cab
befindet, sind alle Komponentennamen aufgelistet.
Unter NT 4.0 kann eine Basisinstallation
mit Hilfe von Sysdiff-Dateien um Anwendungen oder Einstellungen erweitert werden.
Sysdiff ist ein Programm, mit dem Änderungen in einem System erfasst und reproduziert
werden können. Dazu wird ein Basissystem
eingerichtet und mit Sysdiff eine Momentaufnahme der Vorher-Konfiguration erstellt.
Anschließend können Änderungen am
System durchgeführt werden, das heißt, es
können zum Beispiel Anwendungen hinzugefügt werden. Wenn das System in der
gewünschten Konfiguration eingerichtet ist,
wird ein Nachher-Bild mit Sysdiff erstellt,
wodurch eine Datei entsteht, die jede durchgeführte Änderung enthält. Sysdiff kann mit
Hilfe dieser Datei die Änderungen auf einer
beliebigen anderen Maschine reproduzieren.
Das Programm Sysdiff ist allerdings aus
Windows 2000 Professional verschwunden.
An seine Stelle tritt ein besseres Tool namens
WinINSTALL LE. Das Programm WinINSTALL LE befindet sich auf der Windows2000-Professional-CD-ROM im Ordner
\valueadd\mgmt\3rdparty\winstle. Zur
Installation des Programms WinINSTALL
LE, das Windows Installer-Dateien (früher
als Microsoft Installer-Dateien – .msi
bezeichnet) erstellen kann, muss auf die
Datei swiadmle.msi doppelt geklickt werden. Anschließend kann die Antwortdatei
dazu verwendet werden, Setup anzuweisen,
die .msi-Dateien nach der Installation von
Windows 2000 Professional anzuwenden.
Microsoft hat generell noch viel Raum
für Verbesserungen in den Verteilungs- und
Installations-Tools von Windows 2000
gelassen.
( Mark Minasi)
Windows NT Magazine
lung von Konten in NT-4.0-Domänen.
Und schließlich werden es viele sehr zu
schätzen wissen, wie im Abschnitt [Networking] eine unbeaufsichtigte Installation von
Netzwerkcode eingerichtet werden kann.
Die Experten für unbeaufsichtigte NT-4.0Installationen können sich sicher daran erinnern, welche Mühen es kostet, Netzwerkfunktionen über Skripte einzurichten. Mit
der Plug-und-Play-Funktionalität (PnP) von
Windows 2000 wird die unbeaufsichtigte
Einrichtung enorm vereinfacht.
Zur Erstellung der Antwortdatei musste
der Autor den größten Teil noch nicht einmal
selbst erledigen. Windows 2000 Professional wird mit einem rundum verbesserten
Setup-Manager geliefert, der den überwiegenden Teil der Schwerarbeit übernimmt.
Dieser Artikel soll den Leser auf einige
Fragen dieses Programms hinweisen, deren
Antworten vielleicht nicht ganz so offensichtlich sind. In einem Schritt bietet der
Setup-Manager fünf Ebenen der Benutzerinteraktion an. Hier ist die voll automatisierte
Ebene (Fully Automated Level) anzugeben.
Später gibt der Setup-Manager die Möglichkeit, die Computer zu benennen. Hier kann
entweder ein Name angegeben oder dem
Skript mitgeteilt werden, dass Setup die
Namen automatisch generieren soll. Das
Interessante an dieser Einrichtung ist, dass
mehr als ein Computer angegeben werden
kann. Dadurch wird der Setup Manager veranlasst, eine Eindeutigkeitsdatenbankdatei
(UDF – Uniqueness Database File) zu erstellen, was eine weitere Verbesserung gegenüber NT 4.0 darstellt. Denn NT 4.0 verlangt,
eine UDF-Datei ganz neu und nur mit Hilfe
der spärlichen und etwas rätselhaften Dokumentation zu erstellen. Schließlich fragt der
Setup-Manager, ob ein Verteilungsordner
(Distribution Folder) erstellt oder geändert
werden soll. Ein Verteilungsordner enthält
die Dateien des Verzeichnisses i386 sowie
alle vorhandenen $OEM$-Ordner. Das
bedeutet, dass dieser Ordner als Netzwerkfreigabe zum Start einer unbeaufsichtigten
Installation verwendet werden kann, ohne
dazu die NT-CD-ROM zum Ziel-PC tragen
zu müssen. Wenn eine Skriptdatei erstellt
werden soll, ohne den Prozess zur Erstellung
eines Verteilungsordners zu durchlaufen,
muss “No” (Nein) ausgewählt werden. In
diesem Fall wird die Antwortdatei zur Installation von einer CD verwendet. Bei dieser
Auswahl erstellt der Setup Manager nur die
Antwortdatei.
Dennoch muss die Datei ein wenig bearbeitet werden. Aus irgendeinem Grund fordert der Setup Manager keine Eingabe zur
Erstellung der ProductID-Zeile im Abschnitt
NT
Administrator
www.ntmagazin.de
Impressum NT-Administrator
Herausgeber: Eduard Heilmayr
Chefredaktion: Frank-Martin Binder (fbi), verantwortlich
für den redaktionellen Inhalt (-112)
Redaktion: Otto Klusch (kl) (-220)
Übersetzungen: Keven Sarlo
So erreichen Sie die Redaktion: Bretonischer Ring 13,
85630 Grasbrunn, Tel. (089) 45616-220, Telefax
(089) 45616-300
DTP-Produktion: Martina Zeitler, Edmund Krause (Leitung)
Anzeigenleitung: Corinna Weiss,
Tel. (0 89) 4 56 16-113 – verantwortlich für Anzeigen
Anzeigenverwaltung: Gabi Fischböck,
Tel. (0 89) 4 56 16-262
Anzeigendisposition: Sandra Pablitschko,
Tel. (0 89) 4 56 16-108
Erscheinungsweise: monatlich (zwölf Ausgaben im Jahr)
Zahlungsmöglichkeiten für Abonnenten: Bayerische Vereinsbank München, BLZ 700 202 70, Konto: 32 248 594;
Postgiro München, BLZ 70010080, Konto: 537040-801
Vertrieb: Abonnementbestellungen und Adreßänderungen richten Sie bitte an:Edith Winklmaier, Herzog-OttoStraße 42, 83308 Trostberg, Tel. 0 86 21/64 58 41, Fax
0 86 21/6 27 86
Jahresabonnement NT-Administrator: deutsch 298,englisch 198,Druck: Druckhaus Alois Erdl KG, Gabelsberger Str. 4-6,
83308 Trostberg
Urheberrecht: Alle in NT-Administrator erschienenen
Beiträge sind urheberrechtlich geschützt. Alle Rechte, auch
Übersetzungen, vorbehalten. Reproduktionen, gleich
welcher Art, ob Fotokopie, Mikrofilm oder Erfassung in
Datenverarbeitungsanlagen, nur mit schriftlicher Genehmigung des Verlages. Aus der Veröffentlichung kann nicht
geschlossen werden, daß die beschriebene Lösung oder
verwendete Bezeichnung frei von gewerblichen Schutzrechten sind.
Haftung: Für den Fall, daß in NT-Administrator unzutreffende Informationen oder in veröffentlichten Programmen
oder Schaltungen Fehler enthalten sein sollten, kommt eine
Haftung nur bei grober Fahrlässigkeit des Verlages oder
seiner Mitarbeiter in Betracht.
© 2000 AWi NT Magazin Verlagsgesellschaft mbH
Ein Unternehmen der AWi Aktuelles Wissen Verlagsgesellschaft GmbH
Verlagsleitung NT-Magazin: Frank-Martin Binder
Anzeigenverkaufsleitung AWi Verlag: Cornelia Jacobi,
Tel. 089/71940003
Geschäftsführer: Eduard Heilmayr
Anschrift des Verlages: AWi NT Magazin Verlagsgesellschaft mbH, Postfach 1101, 83302 Trostberg
www.ntmagazin.de
Diese Zeitschrift wird mit chlorfreiem Papier hergestellt.