Unser Skript “Bert” verbindet sich per WMI (Windows Management Instrumentation) mit einem Windows-System und liest die wichtigen Eckdaten der IP-Konfiguration aus. Diese zeigt er als separierte Liste auf der Kommandozeile an. Leitet man diese Ausgabe in eine zentrale Datei auf einem Server um, so entsteht eine CSV-Datei, aus der man etwa mit Excel die IP-Konfigurationen direkt verarbeiten kann. Das Skript funktioniert lokal und über das Netzwerk.

Syntax und Verwendung

Die Grundsyntax von Bert sieht folgendermaßen aus:

cscript //nologo Bert.vbs [Rechner] /header:[yes|no]

Es handelt sich um ein Konsolenskript, daher muss es mit cscript aufgerufen werden. Der Schalter “//nologo” unterdrückt die Ausgabe der WSH-Informationen, sodass nur die eigentliche Ausgabe des Skripts erscheint. Mit dem Schalter “/header” gibt man an, ob die Spaltenüberschriften in der Ausgabe erscheinen sollen. Lässt man diese nur beim ersten Rechner ausgeben und unterdrückt sie bei allen anderen, so kann man die Ausgabe in einer einzigen Datei sammeln, die dann einmalig mit den Spaltenüberschriften beginnt.

Das Skript erfasst folgende Daten:

• Computername
• Adaptername
• MAC-Adresse
• DHCP-Nutzung
• IP-Adressen
• DNS-Server

Gibt man keinen Rechnernamen an, so wertet Bert die IP-Konfiguration des lokalen Rechners aus. Wenn man einen entfernten Rechner über das Netzwerk auswerten möchte, benötigt man dort Administratorrechte (das ist bei lokaler Ausführung nicht nötig), oder man muss die WMI-Berechtigungen auf dem Remote-System bearbeiten. Außerdem darf keine Firewall die WMI-Schnittstelle blockieren.

Eine zentrale Sammlung der Konfigurationen in der Datei “IP-Daten.txt” in einer Dateifreigabe zeigt folgendes Beispiel:

cscript //nologo C:\Pfad\Bert.vbs DC01 /header:yes > \\SERVER007\IPData$\IP-Daten.txt
cscript //nologo C:\Pfad\Bert.vbs EX01 /header:no >> \\SERVER007\IPData$\IP-Daten.txt
cscript //nologo C:\Pfad\Bert.vbs SQL01 /header:no >> \\SERVER007\IPData$\IP-Daten.txt

Um die Einschränkungen bei der Remote-Auswertung zu umgehen, kann man Bert auch aus einem Start- oder Logonskript aufrufen. Da normale Anwender die WMI-Schnittstelle lokal aufrufen dürfen, sind hierzu keine besonderen Benutzerrechte nötig. In diesem Fall muss man darauf achten, dass für die Anwender (bei Logonskripts) bzw. für die Computerkonten (bei Startskripts) Schreibrechte auf die Sammel-Datei bestehen.

Um beim Einsatz per Logonskript Schreibkonflikte durch gleichzeitigen Zugriff auf die Zieldatei zu vermeiden, kann man z.B. über folgendes Batch die Daten des lokalen Rechners in jeweils eine eigene Datei schreiben:

@echo off
rem Schreibt die IP-Grundkonfiguration des Rechners in eine Textdatei

SET Target=\\SERVER\IPData$\Clients\%computername%.txt
SET Bert=\\SERVER\IPData$\Bert.vbs

COPY %Bert% "%userprofile%"

cscript //nologo "%userprofile%\Bert.vbs" /header:no > %Target%

DEL "%userprofile%\Bert.vbs"

Dieses Batch kopiert zunächst die Skriptdatei ins lokale Userprofil, damit es keine Berechtigungsfehler beim Aufruf von einem Share aus gibt. Das Ergebnis der Ausführung landet dann in einer Textdatei auf einer Dateifreigabe, die den Namen des lokalen Rechners trägt. Am ende entfernt das Batch die Skriptdatei wieder vom System.

In der Freigabe liegen dann zahlreiche Dateien – eine pro Rechner. Um sie nachträglich zu einer Datei zusammenzufassen, eignet sich dieses Kommando, das man in einem CMD-Fenster aus dem Ordner ausführt, wo die Dateien liegen:

for /F "usebackq" %i in (`dir /b`) do @type %i | find /i ";" >> "IP-Konfigs Clients.txt"

Keine verwandten Beiträge.

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:

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/

Verwandte Beiträge:

1. José 2.2: Fehlerkorrektur und kleine Ergänzung
   Soeben habe ich die Version 2.2 von José online gestellt....
2. Kleines Update für José
   Update 22. Oktober 2008: Es gibt eine neue Fassung von...
3. José 2.3: Kleine Korrektur
   Mein Dokumentationswerkzeug ”José” zur Dokumentation der logischen Active-Directory-Struktur liegt jetzt...

Carmen lets you query Active Directory using SQL-style syntax. This makes it easier for most admins to get data from AD as SQL is more common to use than LDAP. Since its very beginning, Active Directory has supported SQL queries – as only few people seem to know.

Carmen is an HTA application written in HTML and VBSript. It is “safe” for your environment as it only reads data but cannot write to AD. Simply launch the tool by double-click and fill in the three data fields SELECT, FROM, and WHERE. (In most cases you can leave the FROM clause as it is since it already contains your domain name.)

Here are some sample queries:

Verwandte Beiträge:

1. Carmen: Mit SQL das AD abfragen
   Mit Carmen kann man Daten aus dem AD mit SQL-Kommandos...
2. Whitepaper: LDAP-Filter für Active Directory
   Das umfangreiche Whitepaper von Florian Frommherz beschreibt Grundlagen, Syntax und...
3. LDAP-Grundlagen für Active Directory
   Active Directory orientiert sich an dem Standardprotokoll LDAP v3 (Lightweight...

• 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:

Verwandte Beiträge:

1. Cindy: WMI-Dokuskript für Windows-Rechner
   Das VBS-Skript Cindy liest per WMI zahlreiche Konfigurationsinformationen von einem...
2. Exchange-Dokumentation im HTML-Format
   Steve Goodman hat ein PowerShell-Skript publiziert, das bei der Dokumentation...
3. José Active-Directory-Dokumentation: Version 2.0 ist fertig
   Achtung, Update 28. Mai 2010: Version 3.0 ist aktuell! Nutzt...

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.

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.

Verwandte Beiträge:

1. Cindy.vbs 1.1: Windows-Dokumentation korrigiert
   Aufgrund einiger Rückmeldungen, dass die ursprüngliche Fassung des Dokumentationsskripts Cindy.vbs...
2. Wie kann ich abfragen, welche Rechner welches Service Pack haben?
   csvde-Methode  von Nils Kaczenski Im AD wird eine Angabe über...
3. Windows-Ereignisse erzeugen
   Windows-Ereignisse im Ereignisprotokoll lassen sich per Skript erzeugen. Das kann...

Da ich aber nun auch für die aktuellen Betriebssystemversionen ebenfalls eine automatisierte Lösung (auf Basis von Gruppenrichtlinien) brauchte, habe ich ein VBS-Skript geschrieben. Ob nun bei der Anmeldung als Administrator an einem Server in der Domäne oder ob als Benutzer an einem Terminalserver 2008 R2, um manuelle Eingriffe so gering wie möglich zu halten, benötige ich eine automatische Konfiguration für Benutzer-abhängige Einstellungen des Betriebssystems.

Lösung: Das Skript PinTaskbar.zip (Download vom Blog des Autors) löst dieses Problem unkompliziert und mit einem kleinen Trick. Für die Umsetzung und Ausführung sind allerdings ein paar kleinere Vorbereitungen nötig. (Es wird kein Domänencontroller unter Windows Server 2008 R2 benötigt, diese Variante funktioniert bereits mit Windows Server 2003!)

Der Skriptcode:

'* VBS Script zum Anheften von Verknüpfungen an die Taskleiste
'* für Windows 7 und Windows Server 2008 R2 (Deutsch und Englisch)
'* (c) 2010 by B

Dim objArgs
Dim objFolder
Dim objFolderItem, objLNKItem
Dim Itemverb

Set objArgs = WScript.Arguments
Set WSHShell = WScript.CreateObject("WScript.Shell")
Set objEnv = WshShell.Environment("Process")
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objShell = CreateObject("Shell.Application")

If Wscript.Arguments.Count > 0 Then 

	strFolder = Wscript.Arguments(0)
	strTarget = objEnv("APPDATA") & "\Microsoft\Internet Explorer\Quick Launch\"
	If Right(strFolder,1) <> "\" Then strFolder = strFolder & "\"

	Set objFolder = objFSO.GetFolder(strFolder)

	For Each File In objFolder.Files
		Set objFile = objFSO.GetFile(File)
		If Lcase(objFSO.GetExtensionName(objFile)) = "lnk" Then
			objFSO.CopyFile strFolder & File.Name, strTarget, TRUE	'Zieldatei wird überschrieben!
			Set objFolder = objShell.Namespace(strTarget)
			Set objLNKItem = objFolder.ParseName(File.Name)
			For Each Itemverb In objLNKItem.Verbs
				If Replace(Itemverb.Name, "&", "") = "An Taskleiste anheften" Then Itemverb.DoIt
				If Replace(Itemverb.Name, "&", "") = "Pin to Taskbar" Then Itemverb.DoIt
			Next
		End If
	Next

End If

Die Umsetzung

Ich werde mich in meiner folgenden Anleitung auf zwei Beispiel-Anwendungen von Windows 7 und Server 2008 R2 beschränken – Notepad und das Snipping Tool. Das Skript entpackt man beispielsweise in einen Unterordner der NETLOGON-Ressource, in meinem Fall nach:

\\FQDN\Netlogon\Skripte\

Zu Beginn erstellt man die Verknüpfungen, die später verteilt und an die Taskleiste angeheftet werden sollen:

Diese Verknüpfungen können nun in einen zentralen Ordner für die spätere Verteilung innerhalb der Domäne verschoben werden, in meinem Beispiel nach:

\\FQDN\Netlogon\Taskbar

Wer zwischen verschiedenen Benutzergruppen unterscheiden möchte, kann entweder Unterordner (wie Administratoren und Benutzer) erstellen, oder – und das ist wesentlich eleganter – die Leseberechtigungen für jede Datei für die jeweils relevanten Gruppen setzen oder entfernen. Der Vorteil dieser zentralen Stelle ist, ich muss meine Verknüpfungen nur an einem Ort pflegen und aktualisieren, die Änderungen werden bei der nächsten Anmeldung eines Benutzers neu gesetzt.

Nun muss nur noch eine (oder mehrere, abhängig von den unterschiedlichen Verknüpfung-Sets) geeignete Gruppenrichtlinie(n) auswählen und die Ausführung des Skripts PinTaskbar.vbs konfigurieren (Benutzerkonfiguration, Windows-Einstellungen, Skripts, Anmelden):

Wichtig: Als Skript-Parameter ist das Verzeichnis (\\FQDN\Netlogon\Taskbar) anzugeben, in dem sich die Verknüpfungen befinden, ohne Parameter beendet sich das Skript ohne Aktion.

Achtung: Das Skript funktioniert nur für die Betriebssysteme Windows 7 und Windows Server 2008 R2. Für die Ausführung via Gruppenrichtlinien sollte die WMI-Filterung genutzt werden, um Fehler auf Systemen mit älteren Betriebssystemversionen zu vermeiden.  Der WMI-Filter für Windows Server 2008 R2 und Windows 7 lautet:

select * from Win32_OperatingSystem where Version like “6.1%”

Funktionsweise: Das Skript selber ist relativ simpel und klein. Wie beschrieben, erwartet es einen Übergabeparameter – nämlich das Quellverzeichnis der Verknüpfungen, in meinem Beispielfall also:

\\FQDN\Netlogon\Taskbar

Aus diesem Verzeichnis kopiert das Skript nun alle LNK-Dateien (*.lnk) in das Zielverzeichnis:

%APPDATA%\Microsoft\Internet Explorer\Quick Launch\

Dabei zeigt die Umgebungsvariable %APPDATA% auf das Benutzerverzeichnis (Profil) %SystemDrive%\Users\Benutzername\AppData\Roaming. Somit werden die Verknüpfungen immer in das richtige Benutzerprofil kopiert und von dieser Stelle an die Taskleiste angeheftet. Das Skript funktioniert dabei sowohl für die Sprache Deutsch als auch für Englisch (andere Sprachen müssen in Zeile 30 oder 31 des Skripts geändert bzw. hinzugefügt werden). Damit ist die Abarbeitung auch schon beendet.

Wer mag, kann das Skript gern ändern bzw. seinen eigenen Anforderungen anpassen.

Verwandte Beiträge:

1. “Alte” Programme an die Taskleiste heften
   Windows 7 erlaubt es, Programme oder Dokumente an der Taskleiste...
2. Service Pack 1 für Windows 7 und Server 2008 R2 ist RTM!
   Ich zitiere Michael Kleef vom TechNet-Blog: Windows Server 2008 R2...
3. Webcast: “Windows 7 und Windows Server 2008 R2: Reif fürs Unternehmen?”
   Am 20. Oktober werde ich einen Webcast zu Windows 7...

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

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

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

Aufbau des Skriptes

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

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

Das VBSkript

Verwandte Beiträge:

1. Visual Basic Script Mailer
   Für Administratoren ist es oft nützlich, per EMail benachrichtigt zu...
2. Batch Command Line Mailer
   Für Administratoren ist es oft nützlich, per EMail benachrichtigt zu...
3. SMTP richtig eingerichtet unter Windows 200x
   Die zuständigen Mailserver für eine Domäne werden über den sog....

Das folgende Skript stellt eine Funktion zur verdeckten Kennworteingabe vor, die den Browser direkt aus dem Skript fernsteuert und damit ein Dialogfeld erzeugt. Nachteil dieser Methode: Ab Internet Explorer 7 gibt es keine sinnvolle Möglichkeit, einen solchen Dialog in den Vordergrund zu holen, denn die Sicherheitseinstellungen des Browsers lassen das nicht zu. Es kann also sein, dass der Benutzer den Dialog erst per Alt-Tab nach vorn holen muss.

strKennwort = GetPassword("Bitte Kennwort eingeben")
' strKennwort enthält jetzt das Kennwort oder bei Abbruch einen Leerwert

If strKennwort <> "" Then
    WScript.Echo "Kennwort: " & strKennwort
Else
    WScript.Echo "Kein Kennwort angegeben."
End If

Function GetPassword(strWindowTitle)
    Set objIE = WScript.CreateObject("InternetExplorer.Application", "IE_")
    objIE.Navigate "about:blank"
    objIE.ToolBar = 0
    objIE.StatusBar = 0
    objIE.Width = 400
    objIE.Height = 150
    objIE.Left = 300
    objIE.Top = 200
    objIE.Visible = 1
    objIE.Document.Write "<HTML>"
    objIE.Document.Write "<TITLE>" & strWindowTitle & "</TITLE>"
    objIE.Document.Write "<SCRIPT LANGUAGE=""VBScript"">" & vbNewLine
    objIE.Document.Write "Sub RunScript" & vbNewLine
    objIE.Document.Write "    OKClicked.Value = ""OK""" & vbNewLine
    objIE.Document.Write "End Sub" & vbNewLine
    objIE.Document.Write "Sub CancelScript" & vbNewLine
    objIE.Document.Write "    OKClicked.Value = ""Cancelled""" & vbNewLine
    objIE.Document.Write "End Sub" & vbNewLine
    objIE.Document.Write "</SCRIPT>" & vbNewLine
    objIE.Document.Write "<BODY><P>" & strWindowTitle & "</P>"
    objIE.Document.Write "<P>Kennwort:&nbsp;&nbsp;&nbsp;"
    objIE.Document.Write "<input type=""password"" name=""UserPassword"" size=""40"">"
    objIE.Document.Write "<input type=""hidden"" name=""OKClicked"">"
    objIE.Document.Write "<input id=""runbutton"" Class=""button"" type=""button"" value="" OK """
    objIE.Document.Write "name=""ok_button"" onClick=""RunScript"">"
    objIE.Document.Write "<input id=""runbutton"" Class=""button"" type=""button"" value=""Abbrechen"""
    objIE.Document.Write "name=""cancel_button"" onClick=""CancelScript"">"
    objIE.Document.Write "</P>"
    objIE.Document.Write "</BODY>"
    objIE.Document.Write "</HTML>"

    Do While (objIE.Document.Body.All.OKClicked.Value = "")
        WScript.Sleep 250                
    Loop

    strPassword = objIE.Document.Body.All.UserPassword.Value
    strButton = objIE.Document.Body.All.OKClicked.Value
    objIE.Quit
    WScript.Sleep 250
    If strButton = "Cancelled" Then
        GetPassword = ""
    Else
        GetPassword = strPassword
    End If

End Function

Weiterer Nachteil: Man darf den Dialog nur über die Buttons “OK” oder “Cancel” beenden, nicht über das “Schließen-X” am rechten oberen Rand. Aber immerhin besser als nix.

Verwandte Beiträge:

1. AD-Informationen schnell auslesen
   Neben eineAm klassischen ADSI-Skript gibt es eine relativ einfache Möglichkeit,...
2. Gruppe “Prä-Windows 2000 kompatibler Zugriff” per Skript leeren
   Die Gruppe “Prä-Windows 2000 kompatibler Zugriff” ist in der ersten...
3. Anmeldezeiten für AD-Benutzer per Skript ausgeben
   Seit jeher lässt Windows zu, für einen Benutzer Anmeldezeiten zu...

Diese Gruppe hat auf viele Objekte in AD Lese-Zugriffsrechte. Sie ist als Container gedacht: Unter Windows 2000 wurde in diese Gruppe die Pseudogruppe “Jeder” eingefügt, die seinerzeit auch anonyme Benutzer umfasste (also solche, die sich nicht an AD angemeldet haben). In späteren AD-Versionen wurde diese Mitgliedschaft auf die Pseudogruppe “Authentifizierte Benutzer” geändert, weil die alte Regelung erhebliche Sicherheitsprobleme nach sich zog. (Parallel wurde übrigens mit SP2 für Windows XP auch die Gruppe “Jeder” verändert: Seitdem umfasst “Jeder” nicht mehr die anonymen Benutzer – damit ist sie faktisch gleichbedeutend mit “Authentifizierte Benutzer”. Man könnte jetzt einwenden, dass die Funktion der Gruppe “Prä-Windows 2000 kompatibler Zugriff” damit verschwunden ist – und hätte Recht mit dem Einwand.)

Obwohl Microsoft empfiehlt, dass der Gruppe “Prä-Windows 2000 kompatibler Zugriff” keine Mitglieder sein sollten, definiert auch ein frisch installierter Windows Server 2008 R2 in einem neuen AD die “Authentifizierten Benutzer” als Mitglied. Diese Tatsache kann sehr hinderlich sein, wenn man das AD mit angepassten AD-Zugriffsrechten absichern möchte.

Es ist nun ein Einfaches, die Gruppe manuell zu leeren. Man kann das aber auch mit einem Skript automatisieren und so in AD-Standardinstallationen einfließen lassen. Das folgende Skript erledigt das.

Damit das Skript auch auf nicht-deutschen Systemen funktioniert, spricht es die Gruppe über ihren SID an. Dieser gehört zu den sog. “Well-known SIDs” und ist auf jedem System identisch.

[Bekannte Sicherheits-IDs in Windows-Betriebssystemen]
http://support.microsoft.com/kb/243330

Das Leeren der Gruppe erfolgt hier einfach mit dem Holzhammer: Das Skript leert das ganze “member”-Attribut der Gruppe auf einen Schlag.

[Remove All the Members of a Group]
http://gallery.technet.microsoft.com/ScriptCenter/en-us/2cb9b454-13ad-4eb5-a6b2-4ffb55e7d796

Anwendung wie immer auf eigene Gefahr. Kein Support.

Verwandte Beiträge:

1. Mitglieder einer AD-Gruppe mit Zusatzdaten ausgeben
   MItglieder einer Gruppe werden in Active Directory an zwei Stellen...
2. Wie kann ich die Mitglieder einer Gruppe in eine Datei schreiben?
   Natürlich gibt es auch hierzu mehrere (kostenlose) Möglichkeiten – hier...
3. AD: “Domänen-Benutzer” per LDAP abfragen
   Wer per LDAP (oder auch per ADSI) die Mitglieder bestimmter...

Nach mehr als einem halben Jahr Betaphase* ist jetzt die Version 3.0 von José, unserem Dokumentationswerkzeug für Active Directory, erschienen. Die neue Fassung steht hier zum Download bereit.

José erzeugt Berichte über die Objekte und den logischen Aufbau einer Active-Directory-Domäne und speichert sie im HTML-Format. Die Berichte sind in ihrem Umfang sehr weitgehend konfigurierbar und lassen sich über eine Kommandozeilen-Schnittstelle auch automatisiert erzeugen. Seit seinem ersten Erscheinen vor gut sieben Jahren wurde José weit über 60.000-mal heruntergeladen. Natürlich ist das Programm kostenlos.

* (Vielen Dank an alle Tester und insbesondere das MCSEboard.de für die Rückmeldungen und Anregungen!)

• Download
• Überblick
• Neu in dieser Version
• FAQ
• Detaillierte Beschreibung

Download

Den Download der neuen Fassung findet ihr hier:

Überblick

José ist ein skriptbasiertes Werkzeug auf Basis von Visual Basic Script (VBS). Der Quellcode ist frei einsehbar und steht zur Bearbeitung frei – bitte berücksichtigt aber das Copyright und weist bei evtl. Bearbeitungen auf die Urheber des ursprünglichen Codes hin.

José liest Daten zur AD-Domäne des angemeldeten Windows-Benutzers aus und schreibt sie in seine Berichtsdatei. Das Programm ändert nichts an der Domäne und ist daher “sicher”. Allerdings kann es in großen Umgebungen durchaus vorkommen, dass José eine erhebliche Netzwerk- und Systemlast erzeugt.

Die wesentlichen ausführbaren Dateien sind:

• Jose.hta: Ein Doppelklick auf diese Datei startet den “interaktiven Modus” des Programms. Es öffnet sich ein Konfigurationsfenster für den Bericht. Ein Klick auf “Jetzt dokumentieren” erzeugt den Bericht.
• JoseExec.vbs: Dies ist die Kommandozeilenschnittstelle für José. Diese Datei bitte nicht per Doppelklick starten, sondern aus einem CMD-Fenster mit vorangestelltem “cscript”:
  cscript JoseExec.vbs /d:<Definition> [/r:<Report>] [/t:<Titel>] [/f:<Filter>]
  Näheres siehe in der Hilfedatei bzw. weiter unten in diesem Artikel.
• Standard-Reports.bat: Dieser Batch erzeugt vollautomatisiert vier Standardberichte zur aktuellen Domäne:
  • Allgemeine technische und logische Domänen-Informationen
  • Übersicht über Gruppenrichtlinien
  • Übersicht über Exchange-Mailobjekte
  • Übersicht über Benutzer, Gruppen und Computer
• Jose-VersionCheck.vbs: Dieses kleine Skript prüft im Web, ob eine neuere Version von José vorliegt.

José benötigt keine Installation. Bitte das Zip-Archiv an eine beliebige Stelle entpacken. Vereinzelt haben wir die Rückmeldung erhalten, dass José sich nicht aus einem Ordner auf dem Desktop starten lässt; in dem Fall bitte einen anderen Ordner probieren. Die fertigen Berichte liegen im Unterverzeichnis “Reports” und lassen sich per Doppelklick öffnen. Um sie an eine andere Stelle zu kopieren, bitte entweder die “Seite speichern”-Funktion des Browsers verwenden oder den gesamten José-Ordner kopieren, weil die Reports intensiv Dateien aus dem Ordner “Dateien” einbinden.

Einige Daten, die José ausliest, lassen sich derzeit mit kaum einem anderen Werkzeug effizient dokumentieren. Dazu gehören:

• Password Setting Objects
• Security ID (Object SID und SID History)
• Kennwortrichtlinien
• Einstellungen für Tombstone und AD-Papierkorb
• Datum des letzten AD-Backup
• Erlaubte Anmeldezeiten für Benutzer (logonHours)
• AD-Schema-Version, Exchange-Schema-Version

José lässt sich leicht um weitere Attribute erweitern, die es von selbst nicht ausliest. Für die wichtigsten Attribute (Textattribute, ein- oder mehrwertig) genügt hierfür ein einfacher Eintrag in der “Definitionsdatei”, die den Bericht konfiguriert.

Neu in dieser Version

In Version 3.0 hat Ansgar Wiechers den Skriptcode von JoseExec.vbs komplett neu aufgebaut. Der Code ist nun leichter zu warten und zu erweitern. Dadurch hat sich allerdings auch die Betriebsweise des Skripts geändert, sodass es in vielen Fällen mehr Zeit benötigt. Das halten wir aber für gut vertretbar.

Folgende funktionale Änderungen gibt es im Detail (vgl. auch die Datei ChangeLog.txt):

• Trust-Attribute hinzugefügt
• Unterstützung für Password Settings Objects auf Domänenebene und bei Usern
• Datum des letzten AD-Backup hinzugefügt
• Abgefragten DC ausgeben
• Auswertung Anmeldezeiten (LogonHours) hinzugefügt
• TS-Profildaten werden mit zwei Techniken ausgelesen (aber msTS* im AD noch nicht genutzt …)
• "descriptions" jetzt optional
• Tombstone- und Papierkorb-Einstellungen
• Kennwortrichtlinien
• Datum des letzten AD-Backup
• Auswertung Anmeldezeiten (LogonHours)
• Korrektur AD-Schema 2008 R2 RTM, Ergänzung Exchange-Schema 2010 RTM; Betriebsmodus für 2008 R2 ergänzt

FAQ

Hier ein paar Antworten auf häufig gestellte Fragen.

• Lässt sich der Bericht dynamisch gestalten, sodass man z.B. OUs auf- und zuklappen kann?
  Nein, das geht derzeit nicht. Wir haben es aber auf der Roadmap für die nächste Major-Version.
• Gibt es José auch in anderen Sprachen als deutsch?
  Nein. Wir prüfen, ob wir sowas umsetzen können. Da das aber erhebliche Änderungen am Code bedeutet, können wir dazu keine näheren Schätzungen abgeben.
• Kann man spezielle Filter angeben, um nur Objekte auszugeben, die Kriterium ABC erfüllen?
  Nein. José liest immer alle Objekte bestimmter Klassen in einem ganzen Verzeichnisbaum aus. Wer bestimmte Filter benötigt (z.B. um nur Objekte zu sehen, deren Kennwort abgelaufen ist oder ähnlich), sollte Werkzeuge nutzen, die darauf ausgelegt sind. Solche Werkzeuge gestatten die Angabe von Filtern in LDAP-Syntax oder auf andere Weise. Dazu gehören etwa die ds*-Tools ab Windows Server 2003, csvde.exe seit Windows 2000, AdFind von joeware.net, der LDAP Explorer von Philipp Föckeler, Carmen von uns oder viele, viele andere.
  Josés Berichte lassen sich auf bestimmte Objektklassen (Benutzer, Gruppen, Computer usw.) sowie auf ein eigenes Set von auszuwertenden Attributen eingrenzen. Weiterhin gestattet José die Angabe eines Start-Containers (meist einer OU), von der aus es das AD liest. Mehr wird es nicht geben, weil wir keinen Sinn darin sehen, Werkzeuge nachzubauen, die es bereits gibt.
• Ich möchte einen Bericht im CSV-Format (oder in einem anderen Format) erzeugen.
  Dann ist José nicht das richtige Werkzeug. José erzeugt HTML-Reports und wird sich auch weiterhin darauf beschränken.
  Wenn du einen Bericht als CSV-Datei oder in anderen Formaten benötigst, schau dir eines der vielen anderen Werkzeuge an, z.B. csvde.exe (Bordmittel seit Windows 2000), AdFind von joeware.net, den AD Explorer von Sysinternals, den LDAP Explorer von Philipp Föckeler, Carmen oder andere.
• Kann ich Attribut “XYZ” mit José dokumentieren?
  Die Chance ist groß, dass José das von dir gewünschte Attribut bereits von selbst auswerten kann. Die grafische Oberfläche in Jose.hta enthält nur einen Teil dessen, was José beherrscht. Wenn das Attribut einen Textwert enthält, wird José es mit Sicherheit auslesen können, du musst ihn nur dazu auffordern. Sieh dazu in der Hilfedatei nach.
• José bricht seine Ausführung ab. Der Bericht ist nicht vollständig.
  Es kann immer vorkommen, dass der Code einen Fehler hat oder dass José auf Gegebenheiten stößt, mit denen er nicht umgehen kann (z.B. fehlende Berechtigungen). In solchen Fällen kannst du uns unterstützen, indem du dich mit einer konkreten Fehlerbeschreibung bei uns meldest. Meistens benötigen wir dann ein Debug-Protokoll und nähere Angaben zur Umgebung, um den Fehler feststellen zu können. Da das Debug-Protokoll Daten enthält, die schutzwürdig sind, sprechen wir das im Einzelfall mit dir ab. Bitte habe aber Verständnis, dass wir keine Korrektur versprechen können und noch weniger eine feste Bearbeitungszeit. Allgemein gibt es keinen Support für José, aber im Fall von Fehlern schauen wir gern, was wir tun können.
• Meine AD-Umgebung ist recht groß. Kann José damit umgehen?
  José ist nicht optimiert für effiziente Abfragen und auch nicht für sehr große Umgebungen. Wir haben ihn bereits erfolgreich in Domänen mit mehreren tausend Objekten ausgeführt. Es kann aber durchaus sein, dass eine Domäne zu groß für José ist. In solchen Fällen kann es helfen, dass du den Report auf bestimmte OUs eingrenzt und so evtl. mehrere Einzelberichte erzeugst.
• Wo erhalte ich Support für José?
  Wir gewähren keinen Support für José und können auch keine Verantwortung für Fehler, Probleme oder Datenverluste übernehmen, die in deiner Umgebung auftreten! (Und bitte: Wir meinen das ernst!)
  Falls du in der Community nach Unterstützung fragen oder über José diskutieren möchtest, empfehlen wir unserer Partnerforum MCSEboard.de.

Detaillierte Beschreibung

(Der folgende Text entspricht der mitgelieferten Hilfe der Version 3.0.)

José Active-Directory-Dokumentation 3.0

José grüßt!

Was das ist: José ist ein kleines, HTML- und skriptbasiertes Tool zur Dokumentation der Objekte des Active Directory. Es liest dabei das Verzeichnis aus und generiert eine HTML-Datei, die Informationen über OUs, Benutzer, Gruppen, Computer, Policies usw. anzeigt.

Was das nicht ist: Und José generiert keine dynamischen Seiten, d. h. es ist nicht möglich, die angezeigte Ordnerstruktur nachträglich auf- oder zuzuklappen oder Ähnliches.

Und: José liest das AD nur aus und ändert nichts. Daher benötigt es keine Schreibrechte im AD und kann auch mit normalen Benutzerrechten ausgeführt werden (in dem Fall können aber fehlende Berechtigungen dazu führen, dass José einiges nicht lesen kann). José ist daher "sicher" in Bezug auf Active Directory.

Vorsicht aber: José ist für überschaubare Umgebungen konzipiert. Da die Abfragen, die José verwendet, nicht besonders optimiert sind, kann es in großen Umgebungen zu langen Wartezeiten sowie u.U. zu größerer Netzwerklast kommen. Zudem sollte der erzeugte Report nicht zu groß werden, weil die Anzeige im Browser sonst problematisch werden kann. Umgebungen mit mehreren tausend Objekten sind allerdings schon erfolgreich dokumentiert worden. Wer sehr große Umgebungen verwaltet, sollte seine Reports daher immer auf eine bestimmte Ebene oder eine bestimmte Objektklasse eingrenzen und z.B. mit mehreren Teil-Reports arbeiten.

Neuer Code seit Version 3.0

In Version 3.0 hat Ansgar Wiechers den Skriptcode von JoseExec.vbs komplett neu aufgebaut. Der Code ist nun leichter zu warten und zu erweitern. Dadurch hat sich allerdings auch die Betriebsweise des Skripts geändert, sodass es in vielen Fällen mehr Zeit benötigt. Das halten wir aber für gut vertretbar.

Ab Version 3.0 gibt José die Beschreibung (description) von Objekten nur optional aus. Diese Option ist allerdings standardmäßig aktiviert. Sie findet sich in jose.hta oben links bei den allgemeinen Optionen. In der Definitionsdatei steuert die Angabe "description" im Abschnitt "[common]" das Verhalten – fehlt sie, gibt José keine Beschreibungen aus.

Benutzung

Seit Version 2.0 hat José zwei Betriebsarten:

1. Interaktiver Betrieb mit GUI
2. Skriptgesteuerter Betrieb per Kommandozeile

Aus diesem Grund besteht José nun aus zwei ausführbaren Dateien: Jose.hta und JoseExec.vbs. Wer wie bislang arbeiten will, nutzt auch weiterhin nur die Jose.hta.

Interaktiver Modus: Jose.hta

José wird gestartet durch Doppelklick auf "jose.hta". Es öffnet sich ein Formular, in dem der zu erzeugende Bericht konfiguriert werden kann. Die einzelnen Abschnitte beziehen sich auf unterschiedliche Objektklassen des Active Directory (Benutzerkonten, Gruppen usw.). Dabei gilt stets: Der oberste, fett gedruckte Eintrag einer Liste gibt an, ob die zugehörige Klasse überhaupt angezeigt wird. So lässt sich steuern, welche Objektklassen im Report erscheinen sollen. Wenn eine Klasse gar nicht angezeigt wird, werden die einzelnen Attribute automatisch ignoriert.

Die LDAP-Namen der Attribute, die ein- oder abgeschaltet werden können, werden in einem kleinen Infofenster angezeigt, wenn man mit der Maus auf das Kästchen zeigt. Beim Start von José ist ein Standard-Set von Attributen ausgewählt, die in den meisten Fällen einen interessanten Bericht ergeben. Diese Standardauswahl lässt sich durch den Button "Standardauswahl" wiederherstellen (die Buttons "alle Eigenschaften" und "keine Eigenschaften" sollten selbsterklärend sein).

Wenn man "OU-Struktur und Objekte" abschaltet, geht José die Ordner und OUs nicht durch. Das ist nützlich für Reports, die nur die Domänendaten oder nur die GPO-Liste ausgeben sollen.

Filtern

Beim Start wird ab Version 2.0 nicht mehr automatisch die Active-Directory-Struktur eingelesen. Dies hatte sich in großen Umgebungen als hinderlich herausgestellt. Einen Ebenen-Filter kann man nun ganz oben in das Feld "Ausgabe ab OU" in LDAP-Notation eintragen. Beispiel: OU=EDV, OU=Benutzer, DC=faq-o-matic, DC=net. Wer die Auswahl lieber per Maus treffen möchte, klickt auf den Button "OUs anzeigen" neben dem Eingabefeld. Daraufhin blendet José im linken Bereich die AD-Struktur mit Optionsfeldern ein (Achtung: In einer sehr komplexen Umgebung kann das einen Moment dauern!). Durch Markieren einer OU oder eines Ordners wird dessen LDAP-Name in das Filterfeld eingetragen. Dadurch kann man die Ausgabe der Objekte auf die gewählte OU bzw. den ausgewählten Ordner (und untergeordnete) beschränken. Sofern die Ausgabe auf eine bestimmte Ebene beschränkt wird, erscheint im Bericht ein Hinweis darauf.

Diverses

Achtung bei Gruppenmitgliedschaften: Die Auswahl von "Gruppenmitgliedschaften" unter "Benutzerkonten" bzw. von "Mitglieder" unter "Gruppen" führt u. U. zu einer recht langen Bearbeitungszeit.

Bei Auswahl von "Gruppenrichtlinien" werden nur die Namen der Richtlinien angezeigt, nicht aber die Einstellungen, die innerhalb der Richtlinien gesetzt sind. Diese Informationen lassen sich (derzeit) nicht per Skript auslesen. Hierfür empfehlen wir die Skripts der Group Policy Management Console (GPMC), insbesondere "GetReportsForAllGPOs.wsf".

Die Terminalserver-Einstellungen (TS-Profil und TS-Home) kann José zwar auf zwei Arten auslesen (ADSI-Zugriff auf "userParameters" und die neuen "msTS*"-LDAP-Felder seit Windows Server 2008), allerdings funktioniert tatsächlich nur die erste Variante, weil die in Windows Server 2008 neu eingeführten Felder im AD noch gar nicht implementiert sind.

Report ausführen

Im Eingabefeld "Report-Name" kann man eine Überschrift für den generierten Bericht angeben. Zusammen mit den Optionen "Legende anzeigen", "Objektname anstelle des LDAP-Namens anzeigen (bei Gruppenmitgliedschaften)" und "Eigenschaften in Umgangssprache" ist die Dokumentation auch für Nicht-Techies geeignet.

Unter "Report-Dateiname" kann man einen Dateinamen für den Report angeben – nur den Namen, keinen Pfad (die Endung ".htm" fügt José bei Bedarf selbst hinzu). Bleibt das Feld leer, so erzeugt José selbst einen Namen. Achtung: Wenn der gewählte Dateiname bereits vergeben ist, überschreibt José den vorhandenen Report.

Ein Klick auf den Button "Jetzt dokumentieren!" startet die Dokumentation. Es öffnet sich ein schwarzes CMD-Fenster, das nicht geschlossen werden darf! Es kann nun durchaus ein paar Minuten dauern, in denen das Fenster aussieht, als passiere nichts mehr. Nur Geduld! Nach dem Generieren des Reports gibt es unten unter "Status" Informationen und ggf. Fehlermeldungen. Sobald die Doku fertig ist, zeigt ein kleines Feld an "OK", und im Statusbereich steht ein Link auf die generierte HTML-Datei.

Alternativ bzw. zusätzlich kann man die vorhandenen Einstellungen auch als Definitions-Datei speichern, um einen gleichartigen Report mit JoseExec.vbs auszuführen. Hierzu drückt man den Button "Report-Definition speichern". José fragt dann nach einem Namen für die Definitions-Datei, den man frei wählen kann (Angabe ohne Pfad – nur der Dateiname!). Die Definitions-Dateien liegen in dem Unterordner /Definitions.

Automatisierter Modus: JoseExec.vbs

Wer José automatisiert oder mit einer vorhandenen Berichts-Definition ausführen möchte, kann dies über das zusätzliche Skript "JoseExec.vbs" tun. JoseExec.vbs entnimmt die Definition des Reports aus einer Definitionsdatei im Ordner /Definitions. Das Skript wird mit "cscript.exe" in einem CMD-Fenster (oder per Batch) aufgerufen und hat mehrere Kommandozeilenoptionen:

cscript JoseExec /d:<Definition> [/r:<Report>] [/t:<Titel>] [/f:<Filter>]

• /d: Name einer José-Definitionsdatei
  Die Angabe erfolgt ohne Dateipfad – nur der Dateiname mit Endung!
• /r: (optional) Name der zu erzeugenden Report-Datei (HTML)
  Die Angabe erfolgt ohne Dateipfad – nur der Dateiname. Achtung: Die Datei wird ohne Rückfrage überschrieben!
• /t: (optional) Titel des Berichts
• /f: (optional) LDAP-Objektfilter (Container/OU)

Der Parameter "/d" ist zwingend. Bei falschem Aufruf (oder bei Aufruf mit /?) zeigt JoseExec.vbs eine Syntax-Übersicht an.

Es empfiehlt sich, alle Angaben in Anführungsstriche einzufassen (zwingend, sobald Leerzeichen enthalten sind).

Beispiel:

cscript JoseExec /d:"DomainData.txt" /r:"MyDomainData.htm" /t:"Meine Domäne" /f:"OU=EDV,OU=Benutzer,DC=domain,DC=tld"

Format der Definitions-Datei

Die Definitionsdatei ist eine einfache Textdatei mit einem recht simplen Aufbau. Hier ein Beispiel:

; --------------------------------------------
; José-Definitionsdatei AD-Definition-Beispiel.txt
; Erzeugt: 10.03.2010 06:44:20
; von: FAQ-O-MATIC\Nils
; mit: José AD-Dokumentation 3.0
; Download auf http://www.faq-o-matic.net
; --------------------------------------------
[Meta]
ReportName=Active Directory
ReportFileName=AD-Doku 15.09.2008 16-27-08.htm
ObjectFilter=
ShowSymbols
ShowNaturalName
ShowFriendlyName
[Common]
fsmo
trust
folder
OU
gpo
number
Modify
[Printer]
serverName
printShareName
[Group]
[Contact]
[User]
samAccountName
userPrincipalName
profilePath
homeDirectory
homeDrive
scriptPath

Zeilen, die mit ; beginnen, sind Kommentare. Sie werden ignoriert. Achtung: Kommentare müssen in eigenen Zeilen stehen und können nicht an vorhandene Zeilen angefügt werden.

Jeder Abschnitt beginnt mit einem Label in eckigen Klammern. Derzeit kennt José die Labels [Meta], [Common], [Printer], [Group], [Contact] und [User]. Sie stehen – außer Meta und Common – für die Objektklassen, die José dokumentiert.

Im Abschnitt [Meta] hinterlegt José die Report-Optionen. Der Name des Berichts, der Report-Dateiname und der Ebenen-Filter können mit Hilfe der Kommandozeilenparameter /r, /t bzw. /f von JoseExec.vbs übersteuert werden – sobald sie also im Kommando auftauchen, wertet JoseExec die jeweilige Angabe in der Definitionsdatei nicht mehr aus.

Im Abschnitt [Common] listet José die aktiven Optionen auf, die im grafischen Fenster ganz oben links stehen.

Die weiteren Abschnitte sind simpel: Wenn ein Abschnitt zu einer Objektklasse auftaucht, wird diese Objektklasse (z.B. User) mindestens mit dem Namen im Report dokumentiert. Unter dem Label folgen dann die zu berücksichtigenden Attribute.

Reports erweitern

Die Architektur von JoseExec.vbs erlaubt es, Reports um neue Attribute zu erweitern bzw. vorhandenen Definitions-Dateien nachträglich zu bearbeiten. Dies geschieht mit einem einfachen Texteditor. Um Attribute aus einer Definition zu entfernen, löscht man einfach die Angabe des Attributs. Um neue Attribute aufzunehmen, trägt man den Attributnamen einfach bei der gewünschten Klasse ein (z.B. employeeID). Das eignet sich allerdings nur für Textattribute. Mit mehrwertigen Attributen kann José umgehen. Problematisch sind Binärattribute, weil diese nicht ohne Weiteres per Skript zugänglich sind.

Für folgende Attribute hat José eine eigene Unterstützung eingebaut – sie sind nur über die Erweiterung der Definitionsdatei zugänglich:

• logonHours (erlaubte Anmeldezeiten)
• pwdLastSet (letzte Kennwortänderung)
• lastLogonTimestamp (letztes repliziertes Anmeldedatum)
• canonicalName (OU-Pfad wie in der Erweiterten Ansicht unter "Objekt" als Kanonischer Name angezeigt)

Ein Beispiel für eine erweiterte Datei:

; --------------------------------------------
; José-Definitionsdatei AD-Definition-Beispiel.txt
; Erzeugt: 10.03.2010 06:44:20
; von: FAQ-O-MATIC\Nils
; mit: José AD-Dokumentation 3.0
; Download auf http://www.faq-o-matic.net
; --------------------------------------------
[Meta]
ReportName=Active Directory
ReportFileName=AD-Doku-Beispiel.htm
ObjectFilter=
ShowSymbols
ShowNaturalName
ShowFriendlyName
[Common]
fsmo
trust
folder
OU
gpo
number
Modify
description
[User]
samAccountName
userPrincipalName
; ab hier: manuell hinzugefügt
distinguishedName
logonHours
pwdLastSet
lastLogonTimestamp
employeeID

Der Parser für die Definitionsdatei ist recht robust. Die Reihenfolge der Abschnitte ist egal, Leerzeilen stören nicht. Attribute, die nicht existieren, werden einfach ignoriert. Groß- und Kleinschreibung ist egal.

Reports

Die generierten HTML-Dateien werden ausschließlich im Unterverzeichnis Reports gespeichert (ab und an mal leeren), das bei Bedarf erzeugt wird. Wer diese generierten Dateien weitergeben oder woanders speichern will, hat mehrere Möglichkeiten:

• die beiden Ordner "Dateien" und "Reports" gemeinsam kopieren. Sie müssen auf derselben Ebene liegen, damit die Grafiken richtig eingefügt werden.
• die HTML-Datei im Internet-Explorer öffnen und über  [Datei -> Speichern unter ... (Dateityp: "Website, komplett (.htm, .html)")] abspeichern. So werden alle benötigten "*.gif"-Bilder und das Stylesheet in ein Unterverzeichnis des gewählten Speicherortes kopiert und die Links relativ dazu angepasst.

Standard-Reports

Im José-Hauptverzeichnis gibt es eine Datei "Standard-Reports.bat". Sie führt automatisiert vier vordefinierte AD-Reports aus, die für viele Diagnosezwecke nützliche Informationen zusammenstellen. Dabei erzeugt sie die Dateinamen automatisch, indem sie den NetBIOS-Namen der Domäne sowie eine Zufallszahl einfügt. Dadurch kann man die Standard-Reports auch wiederholt ausführen, ohne die vorherigen Daten zu verlieren. Zur Ausführung reichen ein Doppelklick auf "Standard-Reports.bat" sowie etwas Geduld.

Hinweis bei Kontenattributen

Bei der Auswertung verschiedener Objekte oder Attribute kann es Berechtigungsprobleme geben. Diese führen dazu, dass Informationen zu deaktivierten, gesperrten oder ablaufenden Konten – ggf. aber auch andere Informationen – nicht richtig dargestellt werden.

Um verlässliche Informationen zu diesen Objekten und Attributen zu erhalten, führen Sie José bzw. JoseExec mit einem Konto aus, das volle Leserechte auf die relevanten Attribute hat (z.B. ein Domänen-Administratorkonto). Unter Windows Vista/Windows 7 und Windows Server 2008 bzw. R2 sollten Sie José bzw. JoseExec dazu von einer Eingabeaufforderung aus starten, die Sie ausdrücklich als Administrator gestartet haben.

(Näheres zu den Besonderheiten von Vista bis Windows Server 2008 R2 finden Sie in diesem Artikel.)

Die freie Weitergabe des Programms ist erlaubt. Ebenso ist es erlaubt, den Quelltext zu ändern. Die Autoren dieses Programms übernehmen allerdings keinerlei Gewähr oder Support!

© 2002-2010 Nils Kaczenski, Nils Weinhold und Ansgar Wiechers  – Freie Weitergabe erlaubt, keine Gewähr!

Verwandte Beiträge:

1. Jose 2.1: Schon wieder ein kleines Update
   Eigentlich sollte die Beta-Phase genau diese Situation vermeiden … aber...
2. José 2.2: Fehlerkorrektur und kleine Ergänzung
   Soeben habe ich die Version 2.2 von José online gestellt....
3. José: Version 3.1
   Mein Dokumentationswerkzeug José ist nun in Version 3.1 verfügbar. Neben...