13
Kann man OU oder DN des PCs ohne Umweg auslesen?
Hallo zusammen,
ich benötige für ein ein Powershell Logonscript eine Möglichkeit, die Active Directory OU des PCs auf dem das Skript läuft zu ermitteln. Dazu gibt es reichlich Möglichkeiten, zum Beispiel hier beschrieben: Computer OU auslesen bzw. abfragen
Ich finde es aber sehr seltsam, dass das ganze nur mittels Verrenkungen geht.
Der PC muss doch eigentlich wissen, welcher OU er zugehört und welchen DN er besitzt. Geht das nicht direkter? Wie gesagt, es geht um den PC, auf dem das Skript läuft, nicht um andere PCs.
Grüße
lcer
ich benötige für ein ein Powershell Logonscript eine Möglichkeit, die Active Directory OU des PCs auf dem das Skript läuft zu ermitteln. Dazu gibt es reichlich Möglichkeiten, zum Beispiel hier beschrieben: Computer OU auslesen bzw. abfragen
Ich finde es aber sehr seltsam, dass das ganze nur mittels Verrenkungen geht.
- Get-ADComputer setzt das ActiveDirectory Powershellmodul voraus, und startet eine Abfrage an das AD
- adsisearcher benötigt zwar kein spezielles Powershellmodul, aber startet auch eine Abfrage an das AD
- die WMI Variante sieht ebenfalls nach einer Menge Overhead aus.
Der PC muss doch eigentlich wissen, welcher OU er zugehört und welchen DN er besitzt. Geht das nicht direkter? Wie gesagt, es geht um den PC, auf dem das Skript läuft, nicht um andere PCs.
Grüße
lcer
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1223243155
Url: https://administrator.de/forum/kann-man-ou-oder-dn-des-pcs-ohne-umweg-auslesen-1223243155.html
Ausgedruckt am: 12.04.2025 um 19:04 Uhr
13 Kommentare
Neuester Kommentar
Zitat von @lcer00:
Der PC muss doch eigentlich wissen, welcher OU er zugehört und welchen DN er besitzt.
Nö, wieso? Nenn mir einen Grund warum.Der PC muss doch eigentlich wissen, welcher OU er zugehört und welchen DN er besitzt.
Es reicht wenn das AD das weiß. Denn Mitgliedschaft in einer OU ist dynamisch und kann sich ändern.
Hallo,
Danke
Grüße
lcer
Danke
$SysInfo = New-Object -ComObject "ADSystemInfo"
$SysInfo.GetType().InvokeMember("Computername", "GetProperty", $Null, $SysInfo, $Null) Grüße
lcer
Das ist der gleiche Link wie vom TO oben 
Hallo,
Grüße
lcer
Zitat von @149062:
Es reicht wenn das AD das weiß. Denn Mitgliedschaft in einer OU ist dynamisch und kann sich ändern.
Für dynamisch Änderungen im AD gibt es Gruppenrichtlinienupdates. Schau Dir mal Die Ausgabe von GPResult an.Zitat von @lcer00:
Der PC muss doch eigentlich wissen, welcher OU er zugehört und welchen DN er besitzt.
Nö, wieso? Nenn mir einen Grund warum.Der PC muss doch eigentlich wissen, welcher OU er zugehört und welchen DN er besitzt.
Es reicht wenn das AD das weiß. Denn Mitgliedschaft in einer OU ist dynamisch und kann sich ändern.
Grüße
lcer
Zitat von @lcer00:
Für dynamisch Änderungen im AD gibt es Gruppenrichtlinienupdates. Schau Dir mal Die Ausgabe von GPResult an.
Schon klar, aber wenn er keine Verbindung zum AD hätte hat er die letzten anzuwendenden GPs im Cache... Im Cache der GPOs steht es z.B. auch drin ... Für dynamisch Änderungen im AD gibt es Gruppenrichtlinienupdates. Schau Dir mal Die Ausgabe von GPResult an.
{{HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\DataStore\Machine\0}}
=> DNName(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\DataStore\Machine\0' -Name DNName).DNName
Zitat von @149062:
Das ist der gleiche Link wie vom TO oben
Tja, ähm ... Hä?Das ist der gleiche Link wie vom TO oben
Zu meiner Entschuldigung: Ich hatte noch keinen Kaffee heute.
Zitat von @lcer00:
Hallo,
Danke
Hallo,
Danke
$SysInfo = New-Object -ComObject "ADSystemInfo"
> $SysInfo.GetType().InvokeMember("Computername", "GetProperty", $Null, $SysInfo, $Null) Das geht übrigens auch nicht wenn der Computer temp. keinen Kontakt zur Domäne hätte ... Das fragt das ebenfalls vom DC ab. Also auch kein wesentlicher Unterschied zu der anderen PS Methode im Link.
Für lokale Abfrage aus dem GPO-Cache der registry s.o.
Hallo zusammen,
ich hatte wohl auch noch nicht genug Kaffe.
Die GPO Datastore Variante geht bei mir nicht - Die Eigenschaft exisitiert nicht.
Den von mir zitierten Beitrag hatte ich wohl nicht richtig durchgelesen. Mir genügt es, wenn es nur bei Domänenkonnektivität funktioniert.
Die Doku zu dem verwendeten Interface des ADSystemInfo-Objects findet sich hier: https://docs.microsoft.com/en-us/windows/win32/adsi/iadsadsysteminfo-pro ...
Grüße
lcer
ich hatte wohl auch noch nicht genug Kaffe.
Die GPO Datastore Variante geht bei mir nicht - Die Eigenschaft exisitiert nicht.
Den von mir zitierten Beitrag hatte ich wohl nicht richtig durchgelesen. Mir genügt es, wenn es nur bei Domänenkonnektivität funktioniert.
Die Doku zu dem verwendeten Interface des ADSystemInfo-Objects findet sich hier: https://docs.microsoft.com/en-us/windows/win32/adsi/iadsadsysteminfo-pro ...
Grüße
lcer
Dann ist es bei evt ein anderer SubkeyName bei der 0, lässt sich mit rekursiver Abfrage anpassen.
Ansonsten ist wohl GroupPolicy caching bei euch disabled?
https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policie ...
Den den Key gibt es bei unseren Maschinen überall wenn caching aktiviert ist
(ls 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\DataStore\Machine' -Recurse | Get-ItemProperty -Name DNName -EA 0).DNName https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policie ...
Den den Key gibt es bei unseren Maschinen überall wenn caching aktiviert ist
Hallo,
Ansonsten ist wohl GroupPolicy caching bei euch disabled?
nicht aktiv disabled. unter Software\Policies\Microsoft\Windows\System gibt es keine entsprechenden Felder.
Naja, vielleicht ist es ja doch sinnvoll, den aktuellen Status der OU-Zugehörigkeit immer vom DC abzufragen.
Grüße
lcer
Zitat von @149062:
Dann ist es bei evt ein anderer SubkeyName bei der 0, lässt sich mit rekursiver Abfrage anpassen.
nee, es gibt unter Machine nur die 0 und dort sind nur szName und szTargetName enthalten. Bevor die Frage kommt, der PC ist (funktionierendes) Domänenmitglied. Es gibt den key aber in den Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History\{xxxx} Schlüsseln.Dann ist es bei evt ein anderer SubkeyName bei der 0, lässt sich mit rekursiver Abfrage anpassen.
> (ls 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\DataStore\Machine' -Recurse | Get-ItemProperty -Name DNName -EA 0).DNName
> https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policie ...
Den den Key gibt es bei unseren Maschinen überall wenn caching aktiviert ist
Den den Key gibt es bei unseren Maschinen überall wenn caching aktiviert ist
Naja, vielleicht ist es ja doch sinnvoll, den aktuellen Status der OU-Zugehörigkeit immer vom DC abzufragen.
Grüße
lcer
Zitat von @lcer00:
Naja, vielleicht ist es ja doch sinnvoll, den aktuellen Status der OU-Zugehörigkeit immer vom DC abzufragen.
Ich würde es im Powershell Code eher so absichern falls du die OU auch benötigst wenn kein Kontakt zur Domain besteht:Naja, vielleicht ist es ja doch sinnvoll, den aktuellen Status der OU-Zugehörigkeit immer vom DC abzufragen.
Abfrage vom AD, wenn dabei ein Fehler geworfen wird alternative lokale Abfrage aus der Registry.
Man könnte auch per GPO einen Scheduled Task ausrollen, welcher z.B. alle 5 min den aktuellen DN ausliest und in der Registry unter HKLM speichert. Dann hat man immer den letzten bekannten DN.
