Benutzer mit den meisten Antworten
AD System Discovery und AD System Group Discovery funktioniert nicht richtig

Frage
-
Wir haben SCCM 2007 R2 SP2 ICP1 im Einsatz. Eigentlich ist unsere AD-Infrastruktur recht einfach. Aufgrund unserer Abteilungsstruktur haben wir 4 übergeordnete OUs: ABC, ABC01, ABC02, ABC03. In diesen OUs haben wir unsere Benutzer- und Computerkonten in wiederum OUs angelegt. Soweit so gut. Wenn ich in SCCM der AD System (Group) Discovery diese Container
LDAP://OU=ABC,DC=DOMAIN,DC=LOCAL
LDAP://OU=ABC01,DC=DOMAIN,DC=LOCAL
LDAP://OU=ABC02,DC=DOMAIN,DC=LOCAL
LDAP://OU=ABC03,DC=DOMAIN,DC=LOCAL
hinzufüge, wird mir in der Log-Datei folgendes angezeigt:
!!!!Valid AD container 0: LDAP://OU=ABC,DC=DOMAIN,DC=LOCAL
... und aus. In der Status Message steht folgendes:
SMS Active Directory System Discovery Agent failed to bind to container . Error: The parameter is incorrect.
Possible cause: The AD container specified earlier might be invalid now. The Domain Controller is inaccessible.
Solution: Please verify that the AD container paths specified are valid. Confirm accessibility of the site server to the Domain Controller to be queried.
Wenn ich den Container LDAP://OU=ABC,DC=DOMAIN,DC=LOCAL in den Discovery Methoden rausnehme, steht im Log folgendes:
!!!!Valid AD container 0: LDAP://OU=ABC01,DC=DOMAIN,DC=LOCAL
!!!!Valid AD container 1: LDAP://OU=ABC02,DC=DOMAIN,DC=LOCAL
!!!!Valid AD container 2: LDAP://OU=ABC03,DC=DOMAIN,DC=LOCAL
In der Status Message steht folgendes:
SMS Active Directory System Discovery Agent read the AD Containers and found 3 valid AD Container entries in the site control file.
Es gibt immer nur Fehler, wenn ABC und ABC01,... gleichzeitig durchsucht werden sollen. Dann wird ABC durchsucht, nicht aber die anderen 3 Container. Wenn ich ABC raus lösche, werden die anderen drei Container auch durchsucht. An Leseberechtigungen in AD kann's also nicht liegen. In SMS 2003 hat das immer funktioniert. Im Moment gebe ich manuell am Morgen ABC hinzu und wenn ich am Abend nach Hause fahre, lösche ich ABC wieder raus, damit die anderen OUs auch durchsucht werden. Das kann aber keine Lösung sein?!
Kennt das Problem jemand oder hat sogar wer eine Lösung für das Problem? Die Abfrage mit LDAP://domaincontroller:port/OU=... habe ich schon probiert, das hilft nicht.
Vielen Dank im Voraus. Das Problem ist dringend.
Dietmar
Antworten
-
Vielen Dank im Voraus. Das Problem ist dringend.
Das ist ein Fehlverhalten in SP2 für ConfigMgr (bei RTM und SP1 trat dies nicht auf) und kommt genau dann vor, wenn die zu ermittelnden OU-Namen ähnlich sind. Das Problem ist bei MS bekannt. Lösung: warten auf einen Hotfix. Es kann auch nicht schaden, bei MS einen Call zu eröffnen (kostenfrei, da Bug).- Als Antwort markiert Dietmar H. _ Mittwoch, 3. März 2010 16:19
-
- Als Antwort markiert Dietmar H. _ Donnerstag, 11. März 2010 09:02
Alle Antworten
-
Vielen Dank im Voraus. Das Problem ist dringend.
Das ist ein Fehlverhalten in SP2 für ConfigMgr (bei RTM und SP1 trat dies nicht auf) und kommt genau dann vor, wenn die zu ermittelnden OU-Namen ähnlich sind. Das Problem ist bei MS bekannt. Lösung: warten auf einen Hotfix. Es kann auch nicht schaden, bei MS einen Call zu eröffnen (kostenfrei, da Bug).- Als Antwort markiert Dietmar H. _ Mittwoch, 3. März 2010 16:19
-
Sowas hab' ich mir schon gedacht, wollte es nur nicht unbedingt glauben. Gehört sicher auch dazu, dass bei den Attributen der System Discovery 'domain' dabei ist, was im Schema nicht beim Computerobjekt der Fall ist. Verursacht im Log bei uns 6500 unnötige WARNING-Zeilen. Ist das bei MS auch bekannt? Man kann das Attribut beim Discovery nämlich nicht einmal wegnehmen.
Danke für die Bestätigung! Dann werde ich morgen mal einen Case bei MS eröffnen.
Dietmar -
- Als Antwort markiert Dietmar H. _ Donnerstag, 11. März 2010 09:02