11
PowerShell - Get-ADObject
Hi,
mit ist gerade aufgefallen, dass man mit
offenbar nicht alle Objekte aller Klassen zurückgeliefert bekommt.
Diese Abfrage
liefert nur u.g. Objektklassen, nicht aber z.B. "msExchActiveSyncDevice"
Wie kann ich solche Objekte abfragen?
E.
mit ist gerade aufgefallen, dass man mit
Get-ADObjectDiese Abfrage
(Get-ADObject -server server1 -LDAPfilter "(objectClass=*)" -SearchScope Subtree -properties *).objectClass | sort-object -unique Wie kann ich solche Objekte abfragen?
E.
builtinDomain
classStore
computer
contact
container
dfsConfiguration
domainDNS
domainPolicy
fileLinkTracking
foreignSecurityPrincipal
group
groupPolicyContainer
infrastructureUpdate
intellimirrorSCP
linkTrackObjectMoveTable
lostAndFound
msDFS-NamespaceAnchor
msDFS-Namespacev2
msDFSR-Content
msDFSR-ContentSet
msDFSR-GlobalSettings
msDFSR-LocalSettings
msDFSR-Member
msDFSR-ReplicationGroup
msDFSR-Subscriber
msDFSR-Subscription
msDFSR-Topology
msExchDynamicDistributionList
msExchSystemObjectsContainer
msImaging-PSPs
msWMI-Som
nTFRSSettings
organizationalUnit
packageRegistration
rIDManager
rIDSet
rpcContainer
samServer
trustedDomain
user
classStore
computer
contact
container
dfsConfiguration
domainDNS
domainPolicy
fileLinkTracking
foreignSecurityPrincipal
group
groupPolicyContainer
infrastructureUpdate
intellimirrorSCP
linkTrackObjectMoveTable
lostAndFound
msDFS-NamespaceAnchor
msDFS-Namespacev2
msDFSR-Content
msDFSR-ContentSet
msDFSR-GlobalSettings
msDFSR-LocalSettings
msDFSR-Member
msDFSR-ReplicationGroup
msDFSR-Subscriber
msDFSR-Subscription
msDFSR-Topology
msExchDynamicDistributionList
msExchSystemObjectsContainer
msImaging-PSPs
msWMI-Som
nTFRSSettings
organizationalUnit
packageRegistration
rIDManager
rIDSet
rpcContainer
samServer
trustedDomain
user
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 363061
Url: https://administrator.de/contentid/363061
Printed on: April 18, 2024 at 08:04 o'clock
11 Comments
Latest comment
Gib mal den GlobalCatalogServer an -Server server1:3268
Gruß snap
Gruß snap
Gib mal den GlobalCatalogServer an -Server server1:3268
Das ändert nichts. Auch hier ist "msExchActiveSyncDevice" nicht dabei. Sehr wohl aber (s.u.)Muss man das verstehen?
msExchClientAccessArray
msExchConfigurationContainer
msExchContainer
msExchDynamicDistributionList
msExchExchangeServer
msExchMessageClassification
msExchOmaConfigurationContainer
msExchOrganizationContainer
msExchPrivateMDB
msExchPublicMDB
msExchSystemObjectsContainer
msExchConfigurationContainer
msExchContainer
msExchDynamicDistributionList
msExchExchangeServer
msExchMessageClassification
msExchOmaConfigurationContainer
msExchOrganizationContainer
msExchPrivateMDB
msExchPublicMDB
msExchSystemObjectsContainer
Ich suche jetzt über (s.u.)
Das ist zwar umständlicher, aber ich komme weiter.
Das ist zwar umständlicher, aber ich komme weiter.
$DE = New-Object System.DirectoryServices.DirectoryEntry("LDAP://DC=domain,DC=tld")
$DS = New-Object System.DirectoryServices.DirectorySearcher($DE)
$DS.Filter = "(objectClass=msExchActiveSyncDevice)"
$DS.SearchScope = [System.DirectoryServices.SearchScope]::Subtree
$DS.PageSize = 1000
$SRs = $DS.FindAll()
Hm, hier aber schon. Welche Umgebung? EX und AD?
Hinweis: Ich frage das nicht in der Exchange Powershell ab.
DC 2016 - Domain Level 2016 - Forest Level 2008 R2 (muss vorerst so bleiben)
Exchange 2010
DC 2016 - Domain Level 2016 - Forest Level 2008 R2 (muss vorerst so bleiben)
Exchange 2010
Das tue ich auch nicht.
http://microlinc.homeip.net/index.php?lev1=7&lev2=15&id=298
DC 2016 - Domain Level 2016 - Forest Level 2008 R2 (muss vorerst so bleiben)
Exchange 2010
Dann muss das bei dir an Berechtigungen liegen, siehe auch hier das es gehen mussExchange 2010
http://microlinc.homeip.net/index.php?lev1=7&lev2=15&id=298
Dann muss das bei dir an Berechtigungen liegen, siehe auch hier das es gehen muss
Das ist aber unwahrscheinlich.- Ich habe es mit einem Enterprise Admin versucht
- in der selben PowerShell geht es über Get-ADObject nicht, sehr wohl aber über System.DirectoryServices.DirectorySearcher
Ich habe das jetzt mit dem selben Benutzerkonto auf einem anderen Rechner versucht: Dort geht es.
Beide Rechner sind Win 2008 R2 mit PowerShell 4.0
Der Unterschied ist .... Tada!
Die PowerShell muss voll eleviert sein. So ein Blödsinn ....
Die PowerShell muss voll eleviert sein. So ein Blödsinn ....
Och nö, echt jetzt?! 
Ich schick dir einen Latthammer zum Nagel ziehen 
Ich schick dir einen Latthammer zum Nagel ziehen
Nicht so schnell!Das muss ein Bug sein. Denn sonst lässt sich nicht erklären, dass es in einer nicht elevierten Shell direkt über .Net trotzdem funktioniert.
Hast mir aber trotzdem geholgen, auf die Spur zu kommen. Danke.
Vermutlich beschränkt die Shell bei dem CMDLet bei dir auf 1000 Objects, setze mal -ResultSetSize $null.
Hier geht es auf jeden Fall auch damit egal ob elevated oder nicht.
Hier geht es auf jeden Fall auch damit egal ob elevated oder nicht.
Vermutlich beschränkt die Shell bei dem CMDLet bei dir auf 1000 Objects, setze mal -ResultSetSize $null.
Nö, das hat damit nichts zu tun. Aber der Hammer kommt erst noch:Ich habe es leider eben erst bemerkt und es ist viel dämlicher als Du glauben wirst. Ich hatte im Laufe das Tages eine Shell mit einem anderern Konto gestartet. Und in dieser hatte ich es versucht. Dieses Konto darf aber diese Objekte nicht lesen. Au weia ...
Es ist immer gut, ne Nacht drüber zu schlafen.
