Tipps & Tricks

Keine Gewähr für die genannten Informationen. Haftung ausgeschlossen.
Frage:
Welche Domänen-Modi (Functional Levels) unterstützt Windows 2003 Server?
Antwort:
Unter Windows 2000 waren bislang nur die beiden Modi Mixed und Native bekannt. Unter Windows Server 2003 sind noch zusätzliche Modi mit erweiterten Funktionalitäten hinzugekommen.
 
Domänen Modus                                  Unterstützte Domain controller

Windows 2000 Mixed                            Windows NT 4.0
                                                           Windows 2000
                                                           Windows Server 2003
Windows 2000 Native                            Windows 2000
                                                           Windows Server 2003
Windows Server 2003 Interim                 Windows NT 4.0
                                                           Windows Server 2003
Windows Server 2003                            Windows Server 2003
 
Windows 2000 Mixed: 
In diesem Standardmodus werden Domain Controller unter Windows NT 4.0 und höher unterstützt. In diesem Modus kommen keine neuen Funktionalitäten hinzu.
Windows 2000 Native:
Dieser Modus unterstützt nur Domänen Controller vom Typ Windows 2000 und höher. In diesem Modus sind zusätzliche Funktionen verfügbar, so zum Beispel Gruppenverschachtelungen, Universal Groups und SID History
Windows 2003 Interim:
In diesem Modus werden nur Domain Controller unter Windows NT 4.0 und  Windows Server 2003 unterstützt. In diesem Modus kommen keine neuen Funktionalitäten hinzu. Dieser Modus wird automatisch beim Update eines Primary Domain Controller unter Windows NT 4.0 auf Windows Server 2003 eingeschaltet.
Windows 2003:
Nur für Windows Server 2003. Dieser Mosdus bietet gegenüber dem Native Mode von Windows 2000 einige Zusatzfunktionalitäten. So ist es zum Beispiel möglich, Domain Controller umzubenennen.


Frage:
Gibt es eine Möglichkeit, die Herabstufung eines Domain Controllers zu einem Standalone Server zu erzwingen?
Antwort:
Wenn Sie DCPROMO mit dem Schalter /forceremoval ausführen, ignoriert DCPROMO etwaige Fehlermeldungen, eine Herabstufung verhindern können. Dieser Schalter sollte möglichst nur angewendet werden, wenn das AD, in welchem sich der Domain Controller befand, nicht mehr existiert. Sollte das AD weiterhin existent sein, so müssen folgende Schritte unternommen werden, um den DC daraus zu entfernen:
1. Computerkonto des DC per Active Directory User and Computer Snap-In entfernen.
2. Etwaige noch vorhandene DNS-Einträge des DC entfernen.
3. Sicherstellen, dass etwaige auf dem DC vorhandene FSMO-Rollen (Operations Master, RID Master, o.ä.) von einem         anderen DC wahrgenommen werden.
 

Frage:
Ist es möglich, die Recovery Console unter Windows so zu konfigurieren, dass kein Kennwort mehr für den Administrator abgefragt wird?
Antwort:
Ja, das ist möglich. Editieren Sie hierzu den Registry-Eintrag HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows-NT\CurrentVersion\Setup\ RecoveryConsole\SecurityLevel und setzen Sie den Wert von 0 auf 1.


Frage:
Wie groß können FAT32- bzw. NTFS-Volumes unter Windows 2000 maximal sein?
Antwort:
Ein NFTS-Volume kann maximal 256 TByte groß sein, während ein FAT32-Volume maximal 2 TByte umfassen kann.


Frage:
Um eine Dll von einem System löschen zu können müssen wir unseren Windows 2000 Server stets herunterfahren, da sich die Datei im Zugriff befindet. Wie kann man einen Reboot vermeiden?
Antwort:
Windows behält DLLs, auf die einmal von Programmen zugegriffen wurde im Speicher (DLL-Cache), um den künftige Zugriffe zu beschleunigen.  Das gilt selbst dann, wenn das Programm, welches die DLL in Benutzung hatte bereits wieder geschlossen wurde. Um diese Verhalten zu beeinflussen und zu verhindern, dass Windows DLLs im Cache ablegt, kann folgende Vorgehensweise angewendet werden: Unter dem Registry-Key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Current-Version\Explorer einen neuen Value mit dem Namen AlwaysUnloadDLL vom Typ DWORD hinzufügen und auf 1 setzen. Anschließend das System neu starten, um die Änderung wirksam werden zu lassen.


Frage:
Wie lässt sich ermitteln, ob und wie sich Group-Policies unter Windows-2000 auswirken?
Antwort:
Microsoft hat für die Nachverfolgung der Auswirkungen der Group-Policies einige Hilfsmittel in Windows-2000 implementiert. Zunächst einmal gibt es einen Registry-Eintrag, der auf dem Rechner angelegt werden muss, auf dem die Auswirkung der Richtlinien betrachtet werden soll. Um das Diagnostic-Logging zu aktivieren, welches sehr ausführliche und detaillierte Informationen in das Event-Log des Windows-2000-Systems schreibt, gehen Sie so vor:

Legen Sie zunächst unter HKEY_LOCAL_MACHINE\Software\Microsoft\ WindowsNT\CurrentVersion einen Key namens Diagnostics an.

Anschließend legen Sie unter dem neuen Key einen Wert vom Typ DWORD mit dem Namen RunDiagnosticLevelGlobal an und setzen diesen auf 0x1.

Für Probleme, die eher auf der Seite der Domänen-Controller zu suchen sind, gibt es das Tool Replmon.exe. Dieses erlaubt es dem Administrator, Probleme zu diagnostizieren, die aufgrund fehlerhafter Replikation der Group-Policy-Container und der Group-Policy-Templates zurückzuführen sind. Zwei weitere Tools aus dem Windows-2000-Resource-Kit namens Gpotool und Gpresult geben Aufschluss über den Zustand von Group-Policy-Objekten auf Domain-Controllern und die Auswirkung der Group-Policy auf den angemeldeten Benutzer.


Frage:
Wo sind die Tools zu finden, um von einer Windows-2000-Professional-Workstation aus das Active Directory sowie weitere Windows-2000-Server-Dienste administrieren zu können?
Antwort:
Es gibt einen vorgefertigten Satz von Admin-Tools unter dem Verzeichnis %systemroot%\system32 eines Windows-2000-Servers. Die dort befindliche Datei ADMINPAK.MSI beinhaltet zahlreiche Snap-Ins für die Microsoft-Management-Console (MMC), die zur Administration benötigt werden. Eine Verteilung von ADMINPAK.MSI kann durch Veröffentlichung des Paketes im Rahmen der Group-Policy erfolgen.
 

Frage:
Worin besteht der Unterschied zwischen Global und Universal Groups?
Antwort:
Die Global Groups von Windows-200x ähneln denen von NT 4.0. Sie können nur Benutzerkonten der eigenen Domäne enthalten. Im Native-Modus von Windows-2000 ist es darüber hinaus auch möglich, andere Global-Groups aufzunehmen. Global-Groups sind im gesamten Active-Directory-Forest sichtbar und können zur Berechtigungsvergabe in lokale Gruppen aufgenommen werden. Universal-Groups sind neu in Windows-200x. Sie können Benutzerkonten jeder beliebigen Domäne eines Forest aufnehmen und ebenso forestweit zur Erstellung von Objektzugriffslisten herangezogen werden. Universal Groups haben zwei Nachteile. Zum einen sind sie nur im Native-Modus von Windows-200x verfügbar und zum anderen werden bei Universal-Groups sowohl die die Gruppennamen, als auch die Gruppenmitgliedschaften im Global Catalog des Active Directory aufgenommen und müssen zwischen Sites un Domains repliziert werden. Dies kann zu unerwünschten Nebeneffekten bezüglich Performance und Verfügbarkeit des Active-Directory nach sich ziehen. Bei den Global-Groups werden hingegen nur die Gruppennamen repliziert.


Frage:
Wie sehen die möglichen Gruppenmitgliedschaften unter Windows-2000 aus?
Antwort:
Die Mitgliedschaften lassen sich folgendermaßen zusammenfassen:

Local-Groups können enthalten:
  • Global- und Universal-Groups von vertrauten Windows-2000-Domänen
  • Global-Groups von vertrauten NT-4.0-Domänen
  • Domain-Local-Groups, Global- und Universal Groups der eigenen Domäne
Domain-Local-Groups können enthalten:
  • Global- und Universal-Groups aus jeder Forest-Domäne
  • Local-Groups der eigenen Domäne
  • Benutzerkonten aus jeder beliebigen Domäne in einem Forest
Global-Groups können enthalten:
  • Benutzerkonten der eigenen Domäne
  • Andere Global-Groups der eigenen Domäne
Universal-Groups können enthalten:
  • Andere Universal-Groups
  • Beliebige Global-Groups jeder Forest-Domäne
  • Benutzerkonten jeder Forest-Domäne

Frage:
Wir haben von der Möglichkeit gehört, das Active Directory Service Interface (ADSI), das für Windows 2000 verfügbar sein soll, auch schon mit NT 4.0 nutzen zu können. Wo finden wir Informationen darüber und was kann man unter NT 4.0 mit ADSI anfangen?
Antwort:
ADSI ist eine unverselle Schnittstelle, mit der Sie alle möglichen administrativen Aufgaben, vom Anlegen eines Benutzers und der Zuweisung in Gruppen bis hin zur Einrichtung von Verzeichnisfreigaben erledigen können, ohne auf die teilweise komplizierten Win32-API-Aufrufe angewiesen zu sein. Darüber hinaus stellt das ADSI eine Abstraktionsschicht dar, bei der Sie dieselben Aktionen für unterschiedliche Plattformen ausführen können. So können Sie bereits heute ein Skript für NT 4.0 schreiben, mit dem Sie Benutzer und Benutzergruppen anlegen und dasselbe Skript nahezu unverändert später für Windows 2000 weiter verwenden. ADSI ist zudem, wie bereits angedeutet skriptfähig und kann zum Beispiel in Verbindung mit VBScript oder JavaScript unter Windows-Scripting-Host, einer Kommandointerpreter für Windows NT und Windows 9x zum Einsatz kommen. Informationen zu ADSI stellt Microsoft zum Beispiel unter http://msdn.microsoft.com/ zur Verfügung. Um die ADSI-Unterstützung für Ihre Plattform herunterzuladen, verbinden Sie sich am besten mit http://www.microsoft.com/NTWorkstation/downloads/Other/ADSI25.asp.


Frage:
Wir suchen nach einer Möglichkeit, wie man per VBScript und ADSI einen User aus einer NT-Domäne entfernen kann.
Antwort:
Um einen Benutzer per ADSI aus einer Domäne zu entfernen sind nur die folgenden Zeilen auszuführen:
  • Set objDomain = GetObject("WinNT://<Name der Domäne>")
  • ObjDomain.Delete("user", <Name des Benutzers>)
  • Set objDomain = Nothing


Frage:
Wir haben mehrere NT-Rechner, bei denen wir die Inhalte bestimmter Registry-Pfade miteinander vergleichen möchten. Gibt es dafür ein Tool, das diese automatisch erledigt?
Antwort:
Auf der CD, die dem Windows-NT-Resource-Kit beigefügt ist, befindet sich ein Tool mit dem Namen COMPREG.EXE. Dieses ermöglicht einen Vergleich von Registrypfaden zwischen zwei Rechnern.
Über das Kommando COMPREG \\NT1\HKEY_LOCAL_MACHINE\Software COMPREG \\NT2\HKEY_LOCAL_MACHINE\Software werden beispielsweise die Registrypfade HKEY_LOCAL_MACHINE\Software der beiden Rechner NT1 und NT2 miteinander verglichen. COMPREG ist ein Kommandozeilenwerkzeug und nicht sonderlich komfortabel, aber es ist allemal besser, als einen manuellen Vergleich durchzuführen.
 

Frage:
Wir möchten in einem Skript die Versionsnummer eine EXE-Datei ermitteln, damit wir diese gegebenenfalls ersetzen können. Gibt es hierfür ein entsprechendes Werkzeug?
Antwort:
Um an die Versionsinformation einer ausführbaren Datei zu gelangen, kann man sich entweder des Explorers bedienen, was aber in Ihrem Fall keinen Sinn macht, oder aber auf das Tool FILEVER.EXE der Resource-Kit-CD zurückgreifen. FILEVER arbeitet auf der Kommandozeilenebene und liefert die exakte Versionsnummer einer Datei, soweit diese über die entsprechende Information verfügt. So liefert zum Beispiel das folgende Kommando:

                             filever %systemroot%\system32\ntoskrnl.exe

das folgende Ergebnis:

                             ----- W32i APP DEU      4.0.1381.4 shp    914,752 05-05-1997 ntoskrnl.exe

Dabei ist 4.0.1381.4 die Versionsnummer der Datei ntoskrnl.exe.


Frage:
Wir möchten auf unseren Servern im Performance-Monitor das Objekt Netzwerksegment mit den Datenquellen »% Netzwerkausnutzung« und »Erhaltene Rahmen/s« beobachten. Nun haben wir festgestellt, dass das genannte Objekt auf einigen Server verfügbar ist, auf anderen wiederum nicht. Woran liegt das?
Antwort:
Die Ursache dafür ist, dass Sie vermutlich auf einigen Servern den Network Monitor von Microsoft installiert haben und auf anderen nicht. Die zum Network Monitor gehörende DLL BHMON.DLL exportiert das von Ihnen gesuchte Objekt »% Netzwerkausnutzung«. Sie müßten also den Network Monitor auf allen Servern installieren, auf denen Sie die gewünschten Performance-Counter beobachten wollen.


Frage:
Wir möchten über ein Skript die Startart eines Windows-Dienstes von »Manuell« auf »Automatisch« ändern. Wo sind die entsprechenden Einstellungen gespeichert?
Antwort:
Die Einstellungen über die Startart aller Dienste und auch der Treiber ist in der Registry abgelegt. Der Registry-Pfad lautet HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. Hierunter sind die Namen aller Dienste und Treiber aufgelistet. Wenn Sie beispielsweise die Startart des Browser-Dienstes von automatisch auf manuell ändern möchten, so suchen Sie unter dem oben genannten Registry-Pfad den Key »Browser« und darunter den Eintrag »Start«. Dieser ist vom Typ REG_DWORD und hat ist für den Browser-Dienst standardmäßig auf 0x2 gesetzt, was gleichbedeutend ist mit automatisch. Um die Startart auf manuell umzustellen, ändern sie den Wert einfach auf 0x3. Die Bedeutung der einzelnen Werte können Sie auch der unten stehenden Tabelle entnehmen.

Wert  Bedeutung

0x0   Treiber wird während des Bootvorganges vom Kernel-Loader geladen

0x1   Treiber wird vom I/O Subsystem bei der Initialisierung des Kernels geladen

0x2   Treiber/Dienst wird automatisch vom Service-Control-Manager geladen und gestartet

0x3   Treiber/Dienst kann manuell geladen und gestartet werden

0x4   Treiber/Dienst ist deaktiviert


Frage:
Gibt es eine Möglichkeit, das Diskettenlaufwerk auf NT-Rechner ohne mechanische Hilfsmittel so zu sperren, daß Anwender keinen Zugriff mehr darauf haben?
Antwort:
Auf der Begleit-CD der Technischen-Referenz für Windows-NT ist eine Programm namens FLOPLOCK.EXE enthalten, mit dem Sie genau das erreichen können. FLOPLOCK arbeitet als NT-Dienst und sperrt, solange es aktive ist, den Zugriff auf das Diskettenlaufwerk für »normale« Benutzer. Administratoren hingegen, können, wenn sie sich als solche angemeldet haben, weiterhin auf das Floppylaufwerk zugreifen.
 

Frage:
Für die Installation einer Anwendung auf NT-Clients müssen wir per
Batch-Skript ermitteln, ob auf der Zielpartition noch genügend Platz ist. Wie
läßt sich das am einfachsten bewerkstelligen?
Antwort:
Für diesen Zweck gibt es auf der Begleit-CD des NT-Resource-Kits ein Tool namens FREEDISK. Dieses ist mit zwei Parametern aufzurufen. Der erste gibt das Ziellaufwerk an und der zweite die benötigte Speichergröße in Bytes. Wenn genügend Speicher vorhanden ist, liefert FREEDISK 0 als Errorlevel zurück, ansonsten 1.


Frage:
Wie lässt sich unter NT ermitteln, welche offenen TCP/IP-Verbindungen zu einem System bestehen?
Antwort:
Am einfachsten lässt sich die gewünschte Information über das Tool NETSTAT ermitteln, das standardmäßig in NT enthalten ist. Um eine Liste aller aktiven TCP/IP-Verbindungen zu erhalten, geben Sie einfach NETSTAT -a ein und Sie können auf einen Blick erkennen, welcher lokale TCP- bzw. UDP-Port eine Verbindung mit einem Remote-System hat.


Frage:
Gibt es eine Möglichkeit, per VBScript und ADSI einen User aus einer NT-Domäne zu entfernen?
Antwort:
Um einen Benutzer per ADSI aus einer Domäne zu entfernen sind nur die folgenden Zeilen auszuführen:

Set objDomain = GetObject("WinNT://<Name der Domäne>") ObjDomain.Delete("user", <Name des Benutzers>) Set objDomain = Nothing


Frage:
Wir möchten bei der Ausführung eines Batch-Progranmms auftretende Ereignisse in der NT-Ereignisanzeige protokollieren. Gibt es dafür eine Lösung?
Antwort:
Mit einem Werkzeug, das auf der Begleit-CD zur Technischen-Referenz für Windows-NT enthalten ist, können Sie beliebige Ereignisse im Anwendungsprotokoll mitschreiben lassen. Das Tool hat den Namen LOGEVENT.EXE und kann Ereignisse sowohl auf einem lokalen, als auch auf einem entfernten NT-Rechner protokollieren.

Die Syntax lautet folgendermaßen:

LOGEVENT [-m \\MaschinenName] [-s SIWEF] [-c Kategorie] "Ereignis-Text"

Dabei bedeutet der auf –s folgende Paramter:

S      Success (Überwachung erfolgreich)
I        Information
W      Warning (Warnung)
E       Error (Fehler)
F       Failure (Überwachung Fehlversuch)

Der Aufruf von LOGEVENT -s E "Dies ist eine Fehlermeldung", führt zu folgendem Eintrag im Anwendungsprotokoll:
»Die Beschreibung der Ereignis-ID ( 1 ) in Quelle ( User Event ) konnte nicht gefunden werden. Sie enthält folgende Einfügezeichenkette(n): Dies ist eine Fehlermeldung.«

   zurück

   Vorherige Seite
 
© 2009 Dipl.-Ing. Dirk Pelzer