Jump to content

AD PS Abfrage auf fehlendes Attribut


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Ich würd' eher eine CSV-Datei empfehlen. Die eignet sich besser für strukturierte Daten:

Get-ADUser -Filter "enabled -eq '$true'" -Properties Mail -SearchBase 'OU=Verwaltung,OU=Anwender,DC=contoso,DC=com' | 
    Where-Object {$null -eq $_.Mail}  | 
        Select-Object -Property *Name*,Mail |
            Export-Csv -Path 'Pfad zur CSV-Datei.csv' -NoTypeInformation

Wenn Du unbedingt eine Text-Datei haben möchtest, pickst Du Dir einfach mit dem Select-Object den Namen raus, den Du exportieren möchtest und nimmst Out-File anstatt Export-CSV. (Ich habe hier das Attribut "Mail" nochmal mit in die Ausgabe eingeschlossen, um eine "visuelle Bestätigung des Fehlens" zu erhalten)

Link zu diesem Kommentar

Moin,

 

wäre es nicht schlauer, das eigentliche Filterkriterium (Mail ist leer) gleich in den Filter-Parameter des Get-ADUser-Cmdlets aufzunehmen? Dann muss der DC nicht erst alle User zurückgeben, um dann den Client die rausfiltern zu lassen, die wir gar nicht haben wollen. Man stelle sich eine große Umgebung mit fünfstelligen Userzahlen vor, bei denen vielleicht zwanzig keine Mailadresse haben ...

 

Gruß, Nils

 

Link zu diesem Kommentar
vor 18 Minuten schrieb NilsK:

wäre es nicht schlauer, das eigentliche Filterkriterium (Mail ist leer) gleich in den Filter-Parameter des Get-ADUser-Cmdlets aufzunehmen?

Wäre es. Definitiv. Da man aber dem Parameter -Filter keine komplexen Script-Blöcke, sondern nur einen "Filter-String" mitgeben kann, kenne ich keine funktionierende Syntax, wie man auf ein leeres Attribut filtern kann. Und meine LDAP-Kenntnisse sind leider auch quasi nicht vorhanden.  

bearbeitet von BOfH_666
Link zu diesem Kommentar
vor 11 Stunden schrieb BOfH_666:

Ich würd' eher eine CSV-Datei empfehlen. Die eignet sich besser für strukturierte Daten:


Get-ADUser -Filter "enabled -eq '$true'" -Properties Mail -SearchBase 'OU=Verwaltung,OU=Anwender,DC=contoso,DC=com' | 
    Where-Object {$null -eq $_.Mail}  | 
        Select-Object -Property *Name*,Mail |
            Export-Csv -Path 'Pfad zur CSV-Datei.csv' -NoTypeInformation

Wenn Du unbedingt eine Text-Datei haben möchtest, pickst Du Dir einfach mit dem Select-Object den Namen raus, den Du exportieren möchtest und nimmst Out-File anstatt Export-CSV. (Ich habe hier das Attribut "Mail" nochmal mit in die Ausgabe eingeschlossen, um eine "visuelle Bestätigung des Fehlens" zu erhalten)

Die schlechteste aller Skripting-Code Varianten - sorry... Filtern immer so weit links wie möglich, und Get-ADUser hat nen -LDAPFilter, dann filtert schon der DC und liefert nicht sinnloserweise alle User zurück...

 

get-aduser -ldapfilter "(!(proxyAddress=*))" (LDAP-Attribut müßte proxyAddress sein, da kann ich mich täuschen.)

 

Und dann noch - bei allen AD-Cmdlets - immer ein "| Select *" dahinter - warum, dazu muß ich noch nen Blogpost schreiben. Performance ist das Stichwort... (Faktor 100 etwa bei nachfolgenden Foreach-Durchläufen!)

 

PS: Der -Filter Parameter von Get-ADUser filtert auf Client-Seite, da ist das Elend schon passiert. -LDAPFilter filtert auf der Server-Seite.

 

bearbeitet von daabm
Link zu diesem Kommentar
vor 1 Minute schrieb daabm:

daß in "mail" das steht, was in proxyAddresses groß geschrieben ist

Naja seitdem es keinen RUS (recipient update service) gibt, stimmt das nur bedingt. Es wird per update-recipient dort reingeschrieben (was mit großem SMTP im ProxyAddresses steht). Man kann das aber am Exchange vorbei wieder ändern, führt aber früher oder später zu lustigen Problemchen. ;)

Link zu diesem Kommentar
vor einer Stunde schrieb daabm:

Die schlechteste aller Skripting-Code Varianten - sorry... Filtern immer so weit links wie möglich, und Get-ADUser hat nen -LDAPFilter, dann filtert schon der DC und liefert nicht sinnloserweise alle User zurück...

Nicht jeder ist in globalen verteilten AD-Strukturen mit 10.000-den von User-Objekten unterwegs oder so. Und wenn der Code nicht alle 30 Sekunden laufen soll, dann ist es meiner Meinung auch mal egal, ob das dann der effizienteste Code der Welt ist oder nicht. Für einen LDAP-Filter müsste ich "nachschlagen" - das fließt mir nicht aus den Fingern. Die Syntax von ober klimper ich einfach runter und das Ergebnis ist am Ende des Tages das gleiche.  Der Aufwand wäre für mich also deutlich höher, ohne mir einen spürbaren Mehrwert zu liefern.  ;-)  :aetsch2:

Link zu diesem Kommentar

Olaf, es gibt viel zu viel Code, der viel zu oft läuft und viel zu viele Daten abruft. AD dürfte eines der häufigsten Opfer sein, SQL kommt vermutlich kurz danach oder davor... "Egal" gibt es bei gutem Coding nicht. Get it right in the first place...

Warum ich da so hinterher bin? Weil ich schon zu viele unheimliche Begegnungen der dritten Art mit den Auswirkungen von schlechtem Skripting hatte. Und das hatte mit dem Sizing der Infrastruktur nichts zu tun, nur mit der Qualität und Logik der Skripts.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...