NilsK

Moin,

so würd ich das machen:

 

dsquery user "ou=users,ou=site,ou=coutry,dc=domain,dc=com" -disabled

die deaktivierten will er ja gerade nicht.

Gruß, Nils

Moin,

um das per Skript zu realisieren, kannst du die CSV-Datei per ADO als Datenbank ansprechen. Das hat aber seine Hürden: Die Datei darf nicht Unicode sein, Felder dürfen nicht zu lang sein usw. In Grenzen geht das aber ganz gut.

Hey, Scripting Guy! How Can I Use ADO to Open a Text File That has Spaces in the File Name?

Alternativ kannst du mit dem Log Parser arbeiten, der hat auch ein Scripting-Interface und kann sehr gut mit Datenquellen jeder Art umgehen.

.: www.kaczenski.de :.

Aber in deinem Fall würde ich ggf. einfach mit Excel arbeiten:

faq-o-matic.net Excel: Admins unbekannter Liebling

Gruß, Nils

Moin,

naja ... also:

• Domänen-Admins sind per Default Administratoren auf allen Rechnern, die Domänenmitglieder sind (= die Gruppe ist Mitglied in den lokalen Administratorengruppen). Einschließlich der DCs, daher dürfen sie auch die Domäne administrieren.
  
• In der Liste sind noch die BUILTIN\Administrators zu erwähnen, also quasi die lokalen Admins der Domänencontroller: Die dürfen die DCs (alle) komplett administrieren, einschließlich des AD. Sie sind aber nicht Admins auf den anderen Rechnern der Domäne.
  
• Enterprise Admins: Dürfen einige Dinge, die den ganzen Forest betreffen, z.B. Ändern der Configuration Partition, Hinzufügen von Domänen usw. Standardmäßig dürfen sie auch innerhalb der Subdomains administrieren, aber das kann man durch Ändern der Gruppenmitgliedschaften (sowie ggf. der Berechtigungen im AD) auch einschränken.
  
• Schema Admins: Bearbeiten des AD-Schema
  

Gruß, Nils

Moin,

über solche "technischen" Werte wie lastLogonTimeStamp und so habe ich auch schon nachgedacht. Da solche Felder aber naturgemäß ziemlich dynamisch sind, ergeben sie in der Sorte Report, die José erzeugt, nur sehr begrenzt Sinn. Ich selbst würde derartige Reports dann anders machen, z.B. mit csvde oder mit Carmen.

Aus dem Grund scheue ich mich etwas, sowas wie lastLogonTimeStamp ins GUI zu nehmen, weil man es damit schnell überfrachtet. Dank der neuen Definitionsdateien ist es jetzt aber kein Problem, solche Felder einzufügen. (Wobei es mit lastLogonTimestamp in meiner Testumgebung grad nicht klappt, das muss ich mal prüfen.)

Ach so, die Sache mit der Primary Group: Dass solche Mitglieder nicht aufgelistet werden, ist normal, denn die stehen nicht in der member-Liste. Mal sehen, vielleicht bau ich da auch noch Logik ein.

Gruß, Nils

Moin,

PS: wenn ich den DC runtergestuft habe und die Bereinigung im AD vorgenommen habe, wie lange würdet ihr warten bis man den Server wieder zum DC raufstuffen kann? 1 Tag?

das hängt von deiner Replikationsstruktur ab. Es wäre sinnvoll (wenn auch je nach Situation nicht zwingend), eine Komplettreplikation abzuwarten. In den meisten Umgebungen reichen ein paar Stunden.

Gruß, Nils

Moin,

soso, woher habt ihr csvde denn bekommen? ;) (Kleiner Hinweis: Das gehört seit Windows 2000 zu jedem Server ...)

Man kann an csvde auch LDAP-Filter übergeben und darüber steuern, welche Objekte es ausgibt. Ein kleines Hilfsmittel (mit Grenzen) ist Carlos:

faq-o-matic.net Carlos: Konfigurationsmaske für csvde.exe

Allerdings ist es nicht ganz einfach, deaktivierte Konten zu finden (wohlgemerkt: Deaktivierte - also manuell. Gesperrte Konten - also vom System - lassen sich per LDAP gar nicht auffinden.). Dazu braucht man einen etwas komplexen Filter. Versuch mal diesen String:

csvde -f hurz.txt -r "(&(objectClass=user)(objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))"

Die etwas komplexe Angabe mit "userAccountControl" findet solche Objekte, bei denen das 2. Bit in dem Attribut (= ist deaktiviert) gesetzt ist. Duch das ! am Anfang wird dies negiert, findert also die Objekte, die nicht deaktiviert sind.

Was wollt ihr denn mit den Daten machen? Vielleicht gibt es bessere Methoden.

Gruß, Nils

Moin,

in deinem Fall sind Reparaturversuche m.E. nur Zeitverschwendung. dcpromo /forceremoval bringt dich schneller zum Ziel.

faq-o-matic.net Wie kann ich Active Directory von einem DC gewaltsam entfernen?

Gruß, Nils

Moin,

Norbert hat Recht: Mail ist dafür nicht geeignet.

Ein Programm, das auf Clientseite den Empfang oder das Lesen quittiert, dürfte erhebliche datenschutzrechtliche Probleme aufwerfen.

Allenfalls könntest du auf der Ebene des Mailservers die SMTP-Logs aufbewahren und damit den Nachweis zu führen versuchen, dass eine bestimmte Mail vom Mailserver auf der anderen Seite angenommen wurde. Ob dich das in einem Rechtsstreit aber weiterbringen würde, steht auf einem anderen Blatt.

Gruß, Nils

Moin,

ich weiß nicht, wie das Schweizer Datenschutzrecht aussieht. In Deutschland darf man jedenfalls nicht so ohne Weiteres andere überwachen. Auch (bzw. gerade) keine Angestellten/Kollegen. Das kann ein fristloser Kündigungsgrund sein und straf- und zivilrechtliche Folgen haben.

Bevor du also sowas einrichtest, sichere dich rechtlich ab.

Gruß, Nils

Moin,

spricht etwas dagegen, den problematischen DC neu zu machen?

Gruß, Nils

Moin,

Sortiert ist das allerdings nicht.

dann nehmen wir Carmen zu Hilfe:

faq-o-matic.net Carmen: Mit SQL das AD abfragen

SQL-Query:

SELECT name,whenCreated FROM 'LDAP://OU=Meine OU,DC=faq-o-matic,DC=net' WHERE objectClass='user' and objectCategory='person' order by whenCreated desc

Gruß, Nils

Moin,

du erkennst das Problem schon richtig - die Anmeldung kann nur insgesamt überwacht werden. Das ist aber weniger ein Problem der Auswertung als vor allem ein datenschutzrechtliches Problem.

Technisch betrachtet, würdest du die passenden Events schon mit Log Parser oder einem Tool in der Art gut ausfiltern können. Um das Datenschutzproblem zu vermeiden und eben nicht alle Logins zu loggen, fiele mir auf die Schnelle nur ein Logonskript für die Domänen-Admins ein (oder was in der Art).

Die große Einschränkung - die Dom-Admins können das in jedweder Form sehr leicht umgehen - hast du ja auch genannt.

Gruß, Nils

boah... ich würde den FF niiieee benutzen, daher kam der Hinweis von Sunny61@Winfried. ;)

Gruß, Nils

der heute Abend einen Babysitter hat und daher endlich mal wieder mit seiner Frau einen Cocktail trinken kann

Moin,

anscheinend ist die Abfrage nach gesperrten Accounts, die ich in José derzeit einsetze, nicht verlässlich. Da werde ich wohl noch mehr Logik reinfriemeln müssen.

IsAccountLocked-AD User

Ihr braucht mir also keine CSVDE-Exports mehr zu schicken.

Außerdem habe ich gerade beschlossen, die Terminalserver-Settings für 2003ff mit reinzunehmen.

Microsoft Corporation

Gruß, Nils

Moin,

das Terminaldienstprofil wird leider in einem Binärattribut gespeichert, das nicht ohne Weiteres per Abfrage auszulesen ist. Zum Zugriff gibt es eine eigene Schnittstelle in ADSI. Siehe hier:

faq-o-matic.net Wie kann ich die Terminal-Server-Einstellungen im AD verändern?

Oder hier:

Terminal Service User Accounts

Gruß, Nils

Moin,

ich habe in einem vergleichbaren Fall so gearbeitet:

faq-o-matic.net Excel: Admins unbekannter Liebling

Die Daten selbst habe ich mit robocopy übertragen und danach mit einem Batch (ebenfalls mit Excel generiert) die Berechtigungen gesetzt.

Gruß, Nils

Moin,

was genau meinst du mit den fehlenden Tools beim RSAT? Dass du die nach der Installation erst freischalten musst, ist dir bekannt?

RSAT - Remote Server Admistration Tool und die neue GPMC

Zu der webbasierten Administration: Ein Werkzeug, das ich sehr interessant finde, ist der Operations Manager von Unicat (UNICAT unified computing and technology GmbH Mannheim, EDV-Dienstleistung, Software Entwicklung, IT Infrastruktur Consulting). Kommerzielle Software, aber im Vergleich zu anderen Tools seiner Art eher preisgünstig. Und sehr leistungsfähig.

Gruß, Nils

Moin,

wow, erst mal danke für das ausführliche Feedback bis hierhin!

Die Sache mit den deaktivierten Konten muss ich mir noch mal genauer ansehen. Können diejeinigen, bei denen Konten fälschlicherweise als deaktiviert markiert sind, das eine oder andere Konto mal mit csvde exportieren und mir die Exportdatei mailen an nils at kaczenski Punkt de? Wäre hilfreich. Natürlich behandle ich die Daten vertraulich. Hier das Kommando:

csvde -u -f MyExport.txt -d "CN=Mein User,OU=Meine OU,DC=faq-o-matic,DC

=net"

Das mit der GPO-Statistik sollte machbar sein.

Yusuf, das mit dem FF/IE ist interessant, habe ich noch nie bemerkt (mangels FF ;-)). Wird wohl am HTA liegen - das läuft ja im IE, daher startet sich dann bei Links wohl auch der IE.

Hat schon mal jemand die Kommadozeile ausprobiert?

Gruß, Nils

Moin,

allerdings erkennt er etwa die Hälfte unserer Benutzerkonten als deaktiviert.

hm. Der Funktion nach setzt José das "Gesperrt"-Symbol, wenn das Konto deaktiviert ist (also manuell) oder gesperrt (vom System). Kannst du beides bei den Konten ausschließen?

Lässt sich eine Systematik erkennen, nach denen die Fehlzuordnung passiert?

Gruß, Nils

Moin,

mit dem Zeitaufwand meine ich, dass die Agenten halt eine Weile rödeln, bis sie fertig sind (haben ja auch je nach Optionen ne Menge zu tun).

Die Zielrechner müssen online sein in dem Moment, wo du den Push manuell ausführst. Vielleicht kann man das irgendwie automatisieren, das ADMT hat, glaube ich, eine Scripting-Schnittstelle. Soweit ich weiß, wird der Agent nicht richtig installiert, sondern nur gepusht und gestartet, aber da kann ich mich irren.

Und ja: Wenn alles glattläuft, ist der Zielrechner hinterher Mitglied der Zieldomäne.

Gruß, Nils

Moin,

mein Active-Directory-Dokumentationstool José (wird hier und auf anderen Sites oft empfohlen) geht in eine neue Version. Da ich in der neuen Version 2.0 ziemlich viel am Code geändert habe, möchte ich gern eine kleine Betaphase ausführen. Ich lade euch alle ein, daran teilzunehmen.

Mit Dr.Melzer habe ich abgesprochen, dass ich das offizielle Beta-Forum hier im MCSEboard abhalte. Dazu ist dieser Thread gedacht (möglichst nur dieser). Wer Fehler, Fragen, Anmerkungen hat, ist eingeladen, diese hier zu posten.

Die aktuelle Beta findet ihr zum Download an dieser Stelle:

.: www.kaczenski.de :.

Ein paar Anmerkungen dazu:

Neu in Version 2.0:

• José besteht nun aus zwei Teilen: Die bekannte grafische Oberfläche zum Konfigurieren der Dokumentation und ein Kommandozeilen-Tool zum Erzeugen des Reports. Dadurch kann man José nun endlich auch automatisiert ausführen oder einen bestimmten Report immer wieder erzeugen. Bei der grafischen Bedienung ändert sich (fast) nichts. Die Automatisierung arbeitet mit einfachen Definitions-Dateien (lassen sich grafisch erzeugen) und einer simplen Kommandozeile.
  
• Die Oberfläche ist modernisiert und poliert.
  
• Beim Aufruf der grafischen Oberfläche zeigt José nicht mehr zwingend die ganze OU-Struktur der Domäne an. In großen Umgebungen entfallen so ärgerliche Wartezeiten.
  
• Die eigentliche Reporting-Engine habe ich (noch) nicht erweitert oder verändert. Wünsche nehme ich aber gern entgegen.
  

Zur Beta selbst:

• Wie bisher startet man José im GUI-Modus durch Doppelklick auf jose.hta. José ist “sicher” für das AD, weil er nur liest, aber nichts ändert.
  
• Die Benutzerdokumentation findet sich in der Hilfedatei. Am einfachsten ruft man sie im GUI über den Button “Hilfe” am unteren Ende des Fensters auf. Die Datei ist /Dateien/hilfe.htm, man kann sie natürlich auch direkt aufrufen.
  
• In der Betaphase gibt José viele Zusatzinformationen für Debugging-Zwecke aus. Das wird im Release natürlich nicht mehr so sein.
  
• Bislang ist José nur unter Windows Vista und Windows Server 2008 getestet worden. Die getesteten Domänen liefen unter Windows Server 2003 und 2008. Ich freue mich besonders über Tests auf anderen Plattformen (ab Windows 2000 - NT könnte auch gehen, ist aber wohl eher uninteressant) und gegen diverse AD-Konstruktionen.
  
• Die Installation funktioniert wie sonst auch: Man entpacke das Zip in einen beliebigen Ordner, die Ordnerstruktur des Zip muss dabei erhalten bleiben.
  
• Der Code der Skripte ist über Jahre gewachsen und an vielen Stellen weder elegant noch effizient. Wer Anregungen dazu hat, kann diese gerne äußern. Eine vollständige Überarbeitung werde ich aber zeitlich nicht schaffen. Es handelt sich allerdings ja auch um ein kleines Reporting-Tool, da kommt es nicht auf das letzte Quäntchen Eleganz und Stabilität an.
  

Testszenarien:

• Einsatz auf verschiedenen Client-Versionen und gegen verschiedene AD-Versionen und -Aufbauten - läuft es überall?
  
• Verschiedene Reports - sehen die so aus wie gewünscht? Geht irgendwas nicht?
  
• Ausführen per Kommandozeile - läuft es wie gedacht?
  
• Ausführen mit manuell manipulierten Definitions-Dateien - stolpert José dabei?
  
• Ausführen mit ungültigen Definitions-Dateien - unerwartete Fehler?
  

Funktionalität:

Wie erwähnt, habe ich die Report-Funktionen selbst nicht angepasst. Wer neue Reporting-Möglichkeiten haben möchte, kann gern Vorschläge machen. Ob und wie ich sie umsetze, kann ich aber natürlich noch nicht sagen.

Ich freue mich auf eure Unterstützung!

Gruß, Nils

Moin,

naja, ein Dienst darf halt keine Desktop-Meldungen ausgeben. Da wirst du den Code ändern müssen.

Gruß, Nils

Moin,

du erzeugst ein GPO für die OU, in der die Computer liegen, und bindest dein Skript unter Computer/Windows/Skripts als Startskript ein.

Gruß, Nils

Moin,

die Objektmigration selbst sollte mit ADMT 3.1 gehen, erfahrungsgemäß sehr gut. Zu deinen Fragen über die Benutzermigration könnte dies interessant sein:

faq-o-matic.net » Benutzermigration mit ADMT v3: How-To

Zur Computermigration: Die funktioniert in der Tat per Push-Installation des Agenten. Wichtig ist also, dass man mit einem geeigneten Konto arbeitet (üblicherweise ein Domänen-Admin der Quelldomäne). Ich habe es lange nicht gemacht; früher hatten wir oft Misserfolgsraten von bis zu 30 Prozent, aber das soll wohl besser geworden sein.

Die Agenten laufen danach eigenständig lokal, also parallel. Der Zeitaufwand ist trotzdem beträchtlich, man kann aber keine seriösen Prognosen abgeben, weil es von vielen Faktoren abhängt. Hier ist Testen und Pilotieren angesagt.

Zur Inter-Org-Exchange-Migration kann ich leider momentan nichts sagen.

Gruß, Nils