faq-o-matic.net » Dokumentation

Leichenzählung in Active Directory

Nils Kaczenski — Mon, 29 Aug 2011 04:35:00 +0000

Unter den Fragen, die mir oft gestellt werden, nimmt diese einen vorderen Platz ein:

Wie kann ich Benutzer- oder Computerkonten in Active Directory identifizieren, die nicht mehr benötigt werden?

Auf diese naheliegende Frage gibt es eine einfache Antwort: OldCmp.

OldCmp identifiziert:

veraltete Computerobjekte
veraltete Userobjekte (obwohl der Name anderes verheißt)

anhand wählbarer Kriterien, z.B. dem letzten Anmeldedatum, der letzten Kennwortänderung, nur in einem bestimmten Ordner oder ähnlich. Mit den gefundenen Daten kann OldCmp:

Berichte erzeugen in HTML (mit nützlichen Zusatzdaten)
Listen erzeugen als CSV
Objekte deaktivieren
Objekte in einen Ordner verschieben
Objekte löschen

Das Tool eignet sich also sowohl zur Analyse als auch für das Reporting ganz hervorragend.

[OldCmp]
http://www.joeware.net/freetools/tools/oldcmp/index.htm

Exchange-Dokumentation im HTML-Format

Nils Kaczenski — Mon, 22 Aug 2011 04:47:00 +0000

Steve Goodman hat ein PowerShell-Skript publiziert, das bei der Dokumentation einer Exchange-Umgebung (Exchange 2010 und 2007) gute Dienste leistet. Es liest die Exchange-Organisationskonfiguration sowie Details zu den Servern und Mailboxen aus und stellt diese in einem übersichtlichen HTML-Report dar.

Das kleine Werkzeug berücksichtigt auch Besonderheiten wie Database Availability Groups (DAG) sowie die Verteilung von Servern und Mailboxen über verschiedene Standorte.

[Generate Exchange Environment Reports using Powershell]
http://www.stevieg.org/2011/06/exchange-environment-report/

José: Version 3.1

Nils Kaczenski — Wed, 06 Jul 2011 04:00:00 +0000

Mein Dokumentationswerkzeug José ist nun in Version 3.1 verfügbar. Neben einigen Fehlerkorrekturen gibt es ein paar neue Funktionen.

Im Einzelnen:

Neue Funktionen:
- Exchange-Schemaversion 2010 SP1
- Anzahl Werte bei Multi-Value-Feldern (z.B. Gruppen – die Anzahl Gruppenmitglieder ist so leicht abzulesen)
- alle DCs der aktuellen Domäne in Domänen-Info angegeben
- OUs jetzt mit Angabe der Schachtelungstiefe (erleichtert die Orientierung bei langen Reports)
- Optionale Angabe von Details, falls José Objekte nicht lesen kann
Korrekturen:
- Korrektur UAC-Flags
- Korrektur der Objektzählung: Objekte im Domain-Root werden jetzt gezählt
- "memberOf" jetzt korrekt übersetzt
- OUs mit Schrägstrich im Namen erzeugen keinen Abbruch mehr

Hier ist der Download:

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

Hier allgemeine Informationen zu José:

[faq-o-matic.net » José: Version 3.0 ist da]
http://www.faq-o-matic.net/2010/05/26/jos-version-3-0-ist-da/

Cindy.vbs 1.1: Windows-Dokumentation korrigiert

Nils Kaczenski — Wed, 25 May 2011 04:54:00 +0000

Aufgrund einiger Rückmeldungen, dass die ursprüngliche Fassung des Dokumentationsskripts Cindy.vbs auf manchen Systemen zu Fehlern oder langen Verzögerungen führte, habe ich eine angepasste Version erzeugt. In der neuen Fassung werden einige lang laufende und potenziell problematische Abfragen nur noch auf Anforderung ausgeführt. Ruft man das Skript in der bisherigen Syntax auf, so lässt es die “erweiterten” Abfragen (lokale User, installierte Produkte und einige andere) weg.

Kurzer Report:
cscript //nologo cindy.vbs DC01>DC01.txt
Langer Report:
cscript //nologo cindy.vbs /mode:all DC01>DC01.txt

Hier der Original-Artikel mit der Beschreibung des Skripts:

faq-o-matic.net » Cindy: WMI-Dokuskript für Windows-Rechner]
http://www.faq-o-matic.net/2011/01/24/cindy-wmi-dokuskript-fr-windows-rechner/

Und hier der Download:

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

LUMAX: Schnelle Auswertung des Active Directory

Philipp Föckeler — Mon, 21 Feb 2011 06:03:00 +0000

Ich habe schon häufig nach einem Tool gesucht, mit dem man schnell für Active-Directory-Benutzer- und Rechnerkonten diejenigen heraussuchen kann, die bestimmte, interessante Eigenschaften haben, oder deren aktueller Status eine Besonderheit darstellt. Damit meine ich z.B. den tatsächlichen Zeitpunkt der letzten Anmeldung, den Lockout-Status, das Erzeugungsdatum, das Passwort-Ablaufdatum, den Status bzgl. Fine-Grained Password Policies und vieles mehr.

So nützlich es ist zu wissen, wann sich ein Benutzer oder ein Rechner zum letzten Mal aktiv in einer AD-Domäne betätigt hat, so aufwändig ist es, diesen Zeitpunkt auch technisch korrekt zu ermitteln. Es gibt das LDAP-Attribut lastLogonTimestamp, aber dieses ergibt nur einen sinnvollen Wert, wenn der Zeitpunkt der letzten Anmeldung ca. zwei Wochen zurück liegt. Damit kann es also genutzt werden für „Wer ist schon 6 Monate nicht mehr aktiv?“ , nutzt jedoch nichts für „Wer hat sich innerhalb der letzten 4 Stunden angemeldet?“. Das exakte Attribut lastLogon hingegen wird nicht zwischen Domänencontrollern repliziert, man muss also alle DCs der Domäne ausfindig machen, einzeln abfragen, und dann den neuesten Zeitwert nehmen. Zu allem Überfluss werden diese Werte als so genannte “Interger8 Values” abgespeichert – in einem 64-Bit-Wert werden die 100-Nanosekunden seit 1.1.1600 angegeben. Alles in allem also kein Zuckerschlecken.

Eine zweite Hürde: Die in Windows Server 2008 eingeführten Fine-Grained Password Policies erschweren eine einfache Ermittlung der Lockout-Zeiten und der Passwort-Ablaufzeiten. Die Konfiguration für Lockout- und Passwort-Richtlinien war vorher einheitlich für die gesamte Domäne, nun jedoch könnten für jeden User direkt oder über eine Gruppenmitgliedschaft abweichende Werte gelten, die dann natürlich in der Bewertung eine Rolle spielen, ob und wie lange dieser Benutzer gesperrt ist oder wann sein Passwort abläuft. Momentan gibt es noch keine bequeme Möglichkeit, durch ein mitgeliefertes Standard-GUI-Utility die Fine-Grained-Passwort-Richtlinien anzeigen zu lassen oder zu sehen, ob ein Account einer solchen Richtlinie unterliegt.

Sicher gibt es Drittanbieter-Tools, die speziell diese Eigenschaften für Benutzer- und Computer-Accounts darstellen können – und die auch die echten Sperr- und Passwort-Ablaufzeiten auf Basis der Fine-Grained Password Policies errechnen können. Zu nennen wären hier z.B. ADFind, OldCmp, SpecOps Password Policy Basic und bestimmt noch einige andere. Auch mit der Powershell kommt man natürlich mehr oder weniger bequem an alle Informationen …

Was mir gefehlt hat war ein Tool mit bequemer, kompakter Zusammenfassung dieser Informationen in einem grafischen Directory-Browser, in dem die Accounts einer Domäne in einer Liste dargestellt werden und die entsprechenden Infos dazu sofort in Spalten für jedes Konto zu sehen sind.

Kurz und gut – ich habe zu diesem Zweck das Tool LUMAX entwickelt und stelle es kostenlos zur Verfügung. Die Download-Adresse lautet

http://www.ldapexplorer.com/de/lumax.htm

Lumax ermittelt die oben genannten Infos (und noch einige mehr dazu), stellt alle Objekte in der gerade ausgewählten OU-Ebene dar (wahlweise auch für alle darunter liegenden Ebenen) und zeigt die Daten in konfigurierbaren Spalten an:

Selbstverständlich kann die Objektliste nach den Spaltenwerten jeder Spalte sortiert werden, außerdem kann die momentan angezeigte Liste als Text-Datei oder als formatiertes Excel-Sheet exportiert werden.

Zusätzlich dazu gibt es bequeme Möglichkeiten, diese Informationen für ganze Domänen markiert hervorzuheben oder auch die Anzeige nach diversen Kritereien zu filtern. LUMAX kommt mit vordefinierten Account Filtern wie z.B. diesen hier:

zeige nur deaktivierte Accounts
zeige nur Accounts, die momentan gesperrt sind
zeige nur Accounts, die sich angemeldet haben in der letzten Stunde, dem letzen Tag, der letzten Woche usw.
zeige nur Accounts, die sich NICHT angemeldet haben seit einer Stunde, einer Woche, sechs Monaten, einem Jahr usw.
zeige nur Accounts, die sich noch nie angemeldet haben
zeige nur Accounts, deren Passwort noch nie geändert wurde / seit 2 Wochen (1 Monat / 6 Monaten…) nicht geändert wurde
zeige nur Accounts, die einer Fine-Frained Password Policy unterliegen
zeige nur Accounts, deren Passwort heute ablaufen wird / in den nächsten 2 Tagen / bereits abgelaufen ist / niemals ablaufen wird

… und vieles mehr. Das Tool erlaubt es auch, sich mit LDAP/LDAP SSL zu jeder beliebigen Domäne mit expliziten Anmeldedaten zu verbinden. Der Rechner, auf dem LUMAX läuft, braucht also kein Mitglied der betreffenden Domäne oder des Forests zu sein.

LUMAX ist ein kostenloser Ableger in der Entwicklung des kommerziellen LDAP Browsers LEX The LDAP Explorer…

LUMAX hat zwei kostenlose Geschwister: LIZA (AD Objekt Permission Analysis) und LAZARUS (AD Deleted Object Recovery).

Cindy: WMI-Dokuskript für Windows-Rechner

Nils Kaczenski — Mon, 24 Jan 2011 05:43:00 +0000

Das VBS-Skript Cindy liest per WMI zahlreiche Konfigurationsinformationen von einem Windows-System und gibt sie als übersichtlichen Report aus. Das ist nützlich, um die Rahmendaten eines Servers oder Clients schnell zu Dokumentationszwecken zu erfassen.

Cindy läuft auf allen aktuellen Windows-Plattformen. Getestet wurde es u.a. mit Windows 7 (32 Bit), Windows Server 2008 R2, Windows Server 2008 (64 Bit), Windows Server 2003 (32 Bit) und Windows XP (32 Bit). Es sollte aber auch auf älteren Windows-Versionen laufen, wenn dort WMI nachinstalliert wurde.

In der vorliegenden Fassung erfasst Cindy die wichtigsten Daten zu:

Betriebssystem
CPU und Arbeitsspeicher
Festplatten, Partitionen und logischen Laufwerken
Netzwerkkarten und IP-Konfiguration
Lokalen Benutzern und Gruppen
Freigaben
Diensten, installierter Software und Hotfixes

Dabei beschränkt das Skript sich bewusst auf die relevanten Rahmendaten, um den Bericht nicht zu überfrachten. Es ist allerdings leicht, zusätzliche Informationen abzufragen; dazu weiter unten mehr.

Achtung: Wie ich just in einem Artikel von Torsten Meringer las, hat die von Cindy verwendete WMI-Klasse "Win32_Product" einen unschönen Nebeneffekt (um nicht zu sagen: einen ärgerlichen Fehler). Fragt man über sie die installierte Software ab, so führt sie für jedes einzelne Produkt eine MSI-Repatarur aus. Das sorgt nicht nur für eine unnötig lange Ausführungszeit des Skripts, sondern belastet auch das Zielsystem. Im Application-Eventlog des ausgewerteten Systems findet man dann pro Produkt ein Ereignis mit der ID 1035, das auf diesen Vorgang hinweist.

Für eine einmalige Ausführung von Cindy ist das sicher tolerabel. Wer das Skript auf einer größeren Zahl von Rechnern einsetzen oder automatisiert ausführen will, sollte aber prüfen, ob er auf die Produktinformation verzichten kann. In diesem Fall sollte man folgende Zeile löschen oder durch Voranstellen eines Apostroph auskommentieren:

dctWMI.Add "Win32_Product", "InstallDate,InstallLocation,Vendor,Version"

Der folgende KB-Artikel benennt das Problem und schlägt eine Abhilfe vor: http://support.microsoft.com/kb/974524
Leider aber ist die dort empfohlene WMI-Klasse standardmäßig nicht vorhanden, sondern setzt voraus, dass ein SCCM- oder SMS-Client auf dem System installiert ist!

Download

Cindy findet sich hier zum Download. Man entpacke es an geeigneter Stelle.

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

Anwendung

Cindy ist ein Kommandozeilen-Skript und gibt seinen Bericht auch auf der Konsole aus. Daher sollte man seine Ausgabe in eine Datei umleiten. Es ist notwendig, das Skript mit “cscript.exe” zu starten. Ein typischer Aufruf sieht so aus:

C:\Pfad>cscript //nologo cindy.vbs > report.txt

Der Schalter //nologo sorgt dafür, dass das Start-Banner des Script Host unterdrückt wird. So landet nur der Report selbst in der Ausgabedatei.

Das Skript benötigt zwischen 30 Sekunden und mehreren Minuten für seine Arbeit. Der obige Aufruf liest die Daten des lokalen Rechners aus. Um einen anderen Computer zu dokumentieren, übergibt man dem Skript einfach dessen Namen:

C:\Pfad>cscript //nologo cindy.vbs DC01 > DC01.txt

Zur lokalen Ausführung reichen Benutzerrechte aus. Für die Remote-Dokumentation können administrative Rechte auf dem Zielsystem erforderlich sein, außerdem darf WMI nicht per Berechtigung oder Firewall eingeschränkt sein.

Erweiterung

Um den Report zu erweitern, kann man sehr einfach zusätzliche WMI-Klassen oder -Eigenschaften hinzufügen. Dazu bearbeitet man im Skriptcode die folgenden Zeilen (hier nur ein Auszug):

dctWMI.Add "Win32_PhysicalMemory", "BankLabel,Capacity"
dctWMI.Add "Win32_DiskDrive", "InterfaceType,Index,Size"
dctWMI.Add "Win32_DiskPartition", "Size"
dctWMI.Add "Win32_LogicalDisk", "Size,FreeSpace"

Um etwa die “Maximum Block Size” für Platten mit aufzunehmen, ergänzt man die Eigenschaft “MaxBlockSize” in der Zeile mit “Win32_DiskDrive”:

dctWMI.Add "Win32_DiskDrive", "InterfaceType,Index,Size,MaxBlockSize"

Will man z.B. Informationen zu den Lüftern mit aufnehmen, fügt man eine komplette Zeile nach diesem Muster in den Block ein:

dctWMI.Add "Win32_Fan", "DesiredSpeed"

Umgekehrt lassen sich Informationen aus dem Bericht entfernen, indem man die zuständige Zeile löscht oder auskommentiert.

Die Eigenschaft “Caption”, die den Namen des jeweiligen Elements enthält, berücksichtigt Cindy immer von selbst. Welche WMI-Objekte und -Eigenschaften zur Verfügung stehen, erfährt man z.B. auf den MSDN-Seiten bei Microsoft oder in vielen anderen Quellen.

Hier eine Code-Erweiterung von Robert Riebisch. Sie verändert zwei vorhandene Zeilen und fügt eine neue hinzu, um ergänzende Daten auszugeben (Laufzeit, Systemtyp, Uptime).

dctWMI.Add "Win32_ComputerSystem", "AutomaticManagedPagefile,AutomaticResetBootOption,Domain,DomainRole,Manufacturer,Model,NumberOfProcessors,NumberOfLogicalProcessors,PrimaryOwnerName,SystemType,TotalPhysicalMemory"
dctWMI.Add "Win32_OperatingSystem", "BootDevice,CodeSet,CountryCode,CurrentTimeZone,InstallDate,LastBootUpTime,OSArchitecture,OSLanguage,ServicePackMajorVersion,ServicePackMinorVersion,SystemDevice,WindowsDirectory"
dctWMI.Add "Win32_BaseBoard", "Manufacturer,Model,Name,Product,SerialNumber,Version"

Code

Wer mag, kann Cindy gern an seinen Bedarf anpassen. Es wäre dann nett, wenn ein Hinweis auf das Originalskript und auf faq-o-matic.net im Code verbleibt.

Kleines Update für José

Nils Kaczenski — Thu, 08 May 2008 13:01:07 +0000

Update 22. Oktober 2008: Es gibt eine neue Fassung von José! Bitte gehe zum folgenden Artikel:

[faq-o-matic.net » José Active-Directory-Dokumentation: Version 2.0 ist fertig]
http://www.faq-o-matic.net/2008/10/29/jos-active-directory-dokumentation-version-20-ist-fertig/

Genau vor einem Jahr erschien die letzte Fassung meines Dokumentationstools "José" für Active Directory. Heute habe ich ein kleines Update bereitgestellt. Die neue Version 1.41 umfasst folgende Änderungen:

Service-Pack-Abfrage für Computer
Falls Exchange ab Version 2000 installiert ist, wird die Exchange-Schemaversion ausgegeben
Windows Server 2008 wird jetzt mit dem richtigen Namen angezeigt

Für die nächste Major-Version plane ich speicherbare Report-Definitionen sowie einen besseren Umgang mit dem Ausgabefilter. Wann das aber soweit ist, kann ich leider nicht sagen. Kann dauern …

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

Hier der Link zum José-Artikel:

[faq-o-matic.net » José: Active-Directory-Dokumentation]
http://www.faq-o-matic.net/2007/03/08/jose-active-directory-dokumentation/

Störrischer FSRM

Frank Röder — Sat, 19 Jan 2008 14:28:55 +0000

Seit der Einführung von Windows Server 2003 R2 hat der Administrator endlich ein Werkzeug in der Hand, mit dem er sehr schnell und effektiv den Speicherplatzbedarf seiner Netzwerkbenutzer auf den Dateiservern analysieren kann. Durch das Erstellen von Speicherberichten kann der Administrator auf einen Blick erkennen, wie viel Speicherplatz ein Benutzer auf einem bestimmten Laufwerk in Anspruch nimmt. Zusätzlich können die Berichte auch noch eingeschränkt werden. Das heißt, man kann beispielsweise nach Duplikaten suchen oder auch nach Dateien die schon eine längere Zeit nicht mehr benutzt wurden.

Der Ressourcen-Manager für Dateiserver ist also ein rundum nützliches Werkzeug, das in die Werkzeugsammlung eines jeden Administrators gehört. Ein weiterer Vorteil ist die sehr einfache Einrichtung und Konfiguration des Ressourcen-Manager für Dateiserver.

Neulich bei einem Kunden kam das Problem auf, dass der Platz für die Datensicherung nicht mehr ausreichte. Leider kann man bei diesem Kunden nicht mit Kontingenten auf den Laufwerken arbeiten. Die Mitarbeiter nutzen hier sehr große Videodateien und andere Binärdaten, die auch recht schnell auf ein Gigabyte und mehr anwachsen können. Die einzelnen Laufwerke der Server sind mit mehreren Terabyte an Daten gefüllt. Was liegt also näher, als einfach mal einen Speicherreport zu erstellen. Ziel des Speicherberichtes war es, Duplikate dieser Video- und Binärdateien aufzuspüren und dann entsprechend zu löschen. Nach einer kurzen Diskussion hatte ich die Freigabe des dort angestellten Administrators und konnte den Ressourcen-Manager für Dateiserver installieren. Nach der Installation und einem anschließenden Neustart machte ich mich an die Erstellung des Berichtes, und von da an nahm das Unheil seinen Lauf.

Nachdem ich das Laufwerk mit dem größten Datenvolumen identifiziert hatte, wollte ich für dieses Laufwerk einen Speicherbericht erstellen. Nach dem Einrichten und dem Klicken auf „OK“ ereilte mich diese Fehlermeldung:

Für mich kam diese Fehlermeldung genauso unerwartet wie für den Server. OK, was also tun? Der erste Blick ging also in das Ereignisprotokoll, denn das wurde mir ja in der sehr ausführlichen Fehlermeldung vorgeschlagen. Das offenbarte mir dann Folgendes:

Ereignistyp: Fehler
Ereignisquelle: FSRM
Ereigniskategorie: Keine
Ereigniskennung: 0
Datum: 19.01.2008
Zeit: 11:03:27
Benutzer: Nicht zutreffend
Computer: W2K3-SRV1
Beschreibung:
Unerwarteter Fehler beim MMC-Snap-In Ressourcen-Manager für Dateiserver
bei Microsoft.Storage.SrmMmc.ReportTask.SaveChanges(ISrmReportManager reportManager)
bei Microsoft.Storage.SrmMmc.StorageReportTaskPropertySheet.SaveChanges()
bei Microsoft.Storage.SrmMmc.PropertySheet.OnOkButtonClicked(Object sender, EventArgs eventArgs)
Ungültiges Argument: NamespaceRoots[0] = 'E:\'
bei Microsoft.Storage.SrmMmc.ISrmReport.put_NamespaceRoots(Object[] namespaceRoots)
bei Microsoft.Storage.SrmMmc.ReportTask.SaveChanges(ISrmReportManager reportManager)
Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.

Super! Das Laufwerk „E:\“ ist also ein ungültiges Argument. Warum es ein „ungültiges Argument“ ist, bleibt aber offen. Der Eintrag im Ereignisprotokoll brachte mich also auch keinen Schritt weiter.

Da ging mir kurzzeitig folgendes durch den Kopf: Da steh ich nun, ich armer Tor!
Und bin so klug als wie zuvor. (J.W.v.Goethe / Faust I)

Also hieß es wieder „selbst ist der Administrator“. Im nächsten Schritt habe ich mir gedacht, wenn das System mir nicht das Problem verraten will, dann muss ich selbst suchen. Eine andere Alternative blieb mir auch nicht übrig. Für alle Phänomene, die mit dem Dateisystem auftreten, bietet sich als Werkzeug „Filemon“ an. Mit Filemon kann man alle Zugriffe auf das Dateisystem in Echtzeit verfolgen. Also habe ich die Zugriffe des Ressourcen-Manager für Dateiserver protokolliert. Das Ergebnis sah so aus:

Aha, siehe da, ein „ACCESS DENIED“ für den Prozess „srmhost.exe“. Dieser Prozess ist der Dienst, unter dem der Ressourcen-Manager für Dateiserver läuft. Der Dienst selbst läuft unter dem Benutzerkonto „SYSTEM“. Warum kommt aber hier diese Fehlermeldung? Als Nächstes habe ich mir also die NTFS Berechtigung des Laufwerks angesehen und hier lag auch des Rätsels Lösung:

(Berechtigungen des Laufwerks)

(Standardberechtigungen eines NTFS Laufwerks nach der Formatierung)

Der Administrator vor Ort hatte die NTFS Berechtigungen des Laufwerks verändert und dem Benutzerkonto „SYSTEM“ die Zugriffsrechte auf das Laufwerk entzogen. Dadurch hat der Ressourcen-Manager für Dateiserver natürlich keinen Zugriff auf das Laufwerk.

Was mich an diesem Sachverhalt sehr ärgert, ist nicht das fehlende Benutzerkonto bzw. die fehlenden Berechtigungen, sondern die miserable Fehlerbehandlung innerhalb des Ressourcen-Manager für Dateiserver. Mit einer Fehlermeldung à la „Kein Zugriff auf das Laufwerk E:\“ hätte ich ca. vier Stunden eher im Feierabend sein können. Schade, dass an der Fehlermeldung nicht dieser Button existierte:

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

Ich hätte nur zu gern davon Gebrauch gemacht …

Keine verwandten Beiträge.

BGInfo um eigene Datenfelder erweitern

Nils Kaczenski — Wed, 05 Sep 2007 16:06:00 +0000

BGInfo von Sysinternals ist für viele Windows-Admins ein unverzichtbares Werkzeug. Es blendet Konfigurationsinformationen über den lokalen Rechner in das Hintergrundbild ein und erlaubt so eine schnelle Orientierung, mit welcher Maschine man es zu tun hat. Gerade bei der Serveradministration ist das wichtig, denn schnell geht bei der Nutzung mehrerer RDP-Fenster oder eines Monitor-Umschalters die Übersicht verloren.

Wenig bekannt ist, dass sich BGInfo um eigene Datenfelder erweitern lässt. Dazu dient der Button "Custom" unter der Feldauswahl. Hier lassen sich diverse Feldtypen einbinden – im einfachsten Fall wird der Inhalt einer Textdatei ausgegeben (interessant z.B. für die Support-Telefonnummer) oder auch ein bestimmter Registry-Wert. Viel interessanter sind WMI-Abfragen oder VB-Skripts.

WMI-Abfragen

WMI-Abfragen lassen sich mit einem kleinen integrierten Hilfstool zusammenklicken. Die folgende Anweisung zeigt z.B. an, ob die Windows-Firewall aktiv ist oder nicht:

Select Started from Win32_Service where Name="SharedAccess"

Anmerkung: Der Dienst heißt unter Windows XP und Windows Server 2003 "Shared Access". In Windows Vista heißt er "MpsSvc".

Ulf B. Simon-Weidner hat in seinem Blog darauf hingewiesen, dass BGInfo unter Vista und Windows Server 2008 versucht, die Konfiguration aller Netzwerkkarten auszugeben, auch wenn diese gar nicht konfiguriert sind. Das führt zu einer kaum brauchbaren Ausgabe. Auch hier bieten WMI-Abfragen Abilfe:

Für die tatsächlich konfigurierten IP-Adressen eignet sich die Abfrage
SELECT IPAddress FROM Win32_NetworkAdapterConfiguration WHERE IPEnabled = TRUE
Die wirklich eingestellten DNS-Server gibt diese Zeile zurück:
SELECT DNSServerSearchOrder FROM Win32_NetworkAdapterConfiguration WHERE IPEnabled = TRUE

Eine weitere Möglichkeit sind Versionsabfragen für Dateien. Das kann interessant sein, um etwa die Versionsnummer eines Netzwerktreibers mit BGInfo anzuzeigen. Dazu muss man natürlich erst mal wissen, welche Datei hier relevant sind. Im Falle des Netzwerktreibers hilft ein Blick in den Gerätemanager: Dort die Eigenschaften der Netzwerkkarte aufrufen und über die Registerkarte Treiber den Button Treiberdetails betätigen. Die Versionsnummer der gefundenen Datei kann dann über die Custom-Felder in BGInfo ausgegeben werden.

VBS-Skripte

VBS-Skripte haben innerhalb von BGInfo eine Besonderheit: Die Funktion zur Ausgabe heitßt nur "Echo" und nicht "WScript.Echo". Das folgende VBS-Skript gibt die Versionsinformation eines lokal installierten SQL Server aus:

strSQLServer = "." ' hier Servernamen angeben; "." ist lokal
strConn = "Driver={SQL Server};SERVER=" & strSQLServer
on error resume next
set objDB = CreateObject("ADODB.Connection")
objDB.Open(strConn)
if err.number <> 0 then
quitcode
else
sqlvers
end if
sub sqlVers()
strSQL = "select v=@@version"
set objRS = objDB.Execute(strSQL)
if err.number <> 0 then
quitcode
exit sub
end if
strVer = objRS.Fields("v").value
if err.number <> 0 then
quitcode
exit sub
end if
if instr(strVer, "2005 – 9") > 0 then
strSQL = "SELECT v= 'SQL Server 2005 ' + cast(SERVERPROPERTY ('productlevel')" _
& " as varchar) + ', Version ' + cast(SERVERPROPERTY('productversion')" _
& " as varchar) + ', ' + cast(SERVERPROPERTY ('edition') as varchar)"
set objRS = objDB.Execute(strSQL)
strVer = objRS.Fields("v").value
elseif instr(strVer, "2000 – 8") > 0 then
strSQL = "SELECT v= 'SQL Server 2000 ' + cast(SERVERPROPERTY ('productlevel')" _
& " as varchar) + ', Version ' + cast(SERVERPROPERTY('productversion')" _
& " as varchar) + ', ' + cast(SERVERPROPERTY ('edition') as varchar)"
set objRS = objDB.Execute(strSQL)
strVer = objRS.Fields("v").value
elseif instr(strVer, "7.00.1063") then strVer = "SQL Server 7.0 SP4"
elseif instr(strVer, "7.00.961") then strVer = "SQL Server 7.0 SP3"
elseif instr(strVer, "7.00.842") then strVer = "SQL Server 7.0 SP2"
elseif instr(strVer, "7.00.699") then strVer = "SQL Server 7.0 SP1"
elseif instr(strVer, "7.00.623") then strVer = "SQL Server 7.0 ohne SP"
end if
echo strVer
end sub
sub quitcode()
echo "(kein Wert ermittelt)"
end sub

Ein ähnliches, wenn auch viel kürzeres Skript gibt die Versionsinfo für einen lokalen Exchange Server 2003 zurück:

Set objNetwork = CreateObject("WScript.Network")
strComputer = objNetwork.ComputerName
On Error Resume Next
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\MicrosoftExchangeV2")
If Err.Number = 0 Then
Set colItems = objWMIService.ExecQuery("SELECT * FROM Exchange_Server " _
& "WHERE Name='" & strComputer & "'", "WQL")
For Each objItem In colItems
Select Case objItem.Type
Case 0 strType = "Standard Edition"
Case 1 strType = "Enterprse Edition"
Case 2 strType = "Conferencing Edition"
End Select
strMessage = strType & ", " & objItem.ExchangeVersion
if objItem.IsFrontEndServer then strMessage = strMessage & ", FrontEnd"
Next
Else
strMessage = "Exchange 2003 nicht vorhanden"
End If
Echo strMessage

Hier ein Skript, das den Namen des laufenden Betriebssystems ausgibt – interessant deshalb, weil diese Angabe auch die x64-Varianten und Windows 2003 R2 erkennbar macht:

Set objWMIService = GetObject("winmgmts:\\.\root\CIMV2")
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_OperatingSystem")
For Each objItem In colItems
Echo Left(objItem.Name, InStr(objItem.Name, "|")-1)
Next

Und schließlich ein Skript, das die Objektbeschreibung des Computerkontos aus Active Directory anzeigt:

Set objADSysInf = CreateObject("ADSystemInfo")
Set objComputer = GetObject("LDAP://" & objADSysInf.ComputerName)
Echo objComputer.description

Schema-Erweiterungen auffinden

Nils Kaczenski — Mon, 21 May 2007 15:01:00 +0000

Wer eine fremde Active-Directory-Umgebung übernimmt oder bearbeitet, steht vor der Frage, in welchem Zustand sich diese befindet. Neben der Konfiguration der Umgebung kann es auch relevant sein, ob das AD-Schema erweitert wurde. Leider ist es nicht ganz einfach, Schema-Erweiterungen nachträglich ausfindig zu machen, wenn sie nicht ordentlich dokumentiert worden sind. Mit ein wenig manuellem Aufwand lassen sich die Informationen aber relativ schnell herausfinden.

Die Vergleichs-Methode

Der Weg geht über den Vergleich der Produktionsumgebung mit einer Referenzumgebung. Im ersten Schritt installiert man also ein Active Directory in eine virtuelle Umgebung, das denselben Service-Pack- und Patchlevel hat wie die Produktionsumgebung. Falls Applikationen eingesetzt werden, von denen bekannt ist, dass sie das AD-Schema erweitern (z. B. Exchange), sollten auch die Schema-Erweiterungen dieser Applikationen installiert werden.

Der zweite Schritt besteht im Export des Schemas beider Umgebungen. Dazu führt man auf einem Domänencontroller der Produktionsumgebung folgendes Kommando in der Eingabeaufforderung durch (das ganze Kommando bildet eine zusammenhängende Zeile):

csvde -f D:\temp\schema.txt
-d "CN=Schema,CN=Configuration,DC=DOMAIN,DC=TLD"
- r "(|(objectClass=attributeSchema)(objectClass=classSchema))"
-l "name,whenCreated,whenChanged,mayContain,
mustContain,objectClass,objectCategory,governsID,
subClassOf,attributeID,isSingleValued,lDAPDisplayName"

Der Dateipfad "D:\temp\schema.txt" kann natürlich an die realen Pfade angepasst werden. Ebenso muss statt "DC=DOMAIN,DC=TLD" der LDAP-Pfad der echten Domäne angegeben werden.

Dasselbe Kommando wird nun in der Referenzumgebung ausgeführt.

Im dritten Schritt werden beide Textdateien in Excel als CSV-Dateien geöffnet (Trennzeichen: Komma). Für beide Dateien wird in Excel dieselbe Sortierung eingestellt (z. B. zuerst nach "objectClass", dann nach "name"), und dann werden beide nebeneinander angezeigt. So lassen sich die Unterschiede der Schemata (Klassen und Attribute) schnell ausfindig machen. Dazu eignen sich die Funktionen Anordnen und Nebeneinander vergleichen aus dem Fenster-Menü von Excel (unter Excel 2007 woanders zu finden) sehr gut.

Um den Vorgang zu vereinfachen, habe ich einige Schema-Exportdateien im CSV-Format vorbereitet, die als Referenz dienen können. Vor derm Vergleich sollte evtl. der Domänenname (lautet auf "DC=faq-o-matic,DC=net") geändert werden, um automatisierte Vergleiche zu vereinfachen. Die Dateien finden sich hier:

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

Update 21. 10. 2007: Um das Ganze noch einfacher zu machen, habe ich ein Skript gepostet, das den Vergleich beider Exportdateien automatisiert. Der manuelle Vergleich mit Excel kann so entfallen. Mehr dazu: Schema-Versionen vergleichen

Die dsquery-Methode

Dean Wells hat ein Skript geschrieben, das mit Hilfe von repadmin.exe aus den Support Tools und dsquery.exe von Windows Server 2003 einen Vergleich des aktuellen Schemas mit dem Installationszustand erzeugt. Damit lassen sich auch Modifikationen an Standardobjekten identifizieren. Vorsicht: Das Skript erzeugt viele Daten, insbesondere wenn Exchange oder andere große Schema-Erweiterungen installiert wurden. Der Download findet sich hier: http://www.activedir.org/Downloads/Files/SchemaDiff.zip

(Danke für den Hinweis an Norbert Fehlauer)

faq-o-matic.net » Dokumentation

Leichenzählung in Active Directory

Verwandte Beiträge:

Exchange-Dokumentation im HTML-Format

Verwandte Beiträge:

José: Version 3.1

Verwandte Beiträge:

Cindy.vbs 1.1: Windows-Dokumentation korrigiert

Verwandte Beiträge:

LUMAX: Schnelle Auswertung des Active Directory

Verwandte Beiträge:

Cindy: WMI-Dokuskript für Windows-Rechner

Download

Anwendung

Erweiterung

Code

Verwandte Beiträge:

Kleines Update für José

Verwandte Beiträge:

Störrischer FSRM

BGInfo um eigene Datenfelder erweitern

Verwandte Beiträge:

Schema-Erweiterungen auffinden

Verwandte Beiträge: