memphis1 12 Geschrieben 20. März 2015 Melden Teilen Geschrieben 20. März 2015 (bearbeitet) Guten Morgen zusammen, habe ein Problem mir die Eigenschaften eines Users in Exchange anzuschauen. Habe am Anfang der Woche den User im AD von einer OU in eine andere OU verschoben. Nun wollte ich gestern im Exchange Admin Center den User editieren, und da kommt folgende Fehlermeldung: "Die angegebene Organisationseinheit wurde nicht gefunden.Stellen sie sicher, dass die Identität der Organisationseinheiten korrekt eingegeben haben." Die Berechtigungen habe ich auf den OU's überprüft, Vererbung ist aktiviert und die Gruppe "Exchange Trusted Subsystem" hat Lese Berechtigungen Es handelt sich um einen Exchange 2013 CU7. Hat jemand eine Idee wie ich das wieder beheben kann, außer den User wieder in seine alte OU zu verschieben? Problem ist, das ich diese gelöscht habe als der User verschoben wurde, :( Gruß bearbeitet 20. März 2015 von memphis1 Zitieren Link zu diesem Kommentar
tesso 375 Geschrieben 20. März 2015 Melden Teilen Geschrieben 20. März 2015 Schau mal in die Releasenotes zu CU8. Ich meine da gelesen zu haben, daß solch ein Fehler dort beseitigt wurde. Zitieren Link zu diesem Kommentar
memphis1 12 Geschrieben 20. März 2015 Autor Melden Teilen Geschrieben 20. März 2015 Hi, das ist ein guter Tipp. Lade gerade das CU8 herunter und werde das mal installieren. Werde berichten ob es geklappt hat. Gruß Zitieren Link zu diesem Kommentar
Kampfmade 10 Geschrieben 22. April 2015 Melden Teilen Geschrieben 22. April 2015 (bearbeitet) Servus! Habe hier einen frisch installierten 2013er Exchange CU8 auf einem 2012R2 aktuell Windows Server. Ich habe das Problem auch. Das hier (https://support.microsoft.com/de-de/kb/2909303/en) habe ich schon probiert, kein Erfolg. Kann jemand helfen? Vielen Dank! :) Edit: Habe mal noch ein wenig rumgeschaut und getestet, bei dem Administrator den er standardmäßig hat tritt das Problem nicht auf. Es gibt eine OU 'Firmenname' nächste OU 'User / Gruppen' darin sind die User. Berechtigungen sind vererbt und 'Exchange Trusted Subsystems' hat lesenden Zugriff. bearbeitet 22. April 2015 von Kampfmade Zitieren Link zu diesem Kommentar
Kampfmade 10 Geschrieben 23. April 2015 Melden Teilen Geschrieben 23. April 2015 Tada! Problem gelöst: Habe noch ein wenig rumgeschaut. Habe den Testuser in die vorgegebene OU 'Users' verschoben funktionierte. Wieder in die OU 'User / Gruppen' funktionierte nicht. Neue OU erstellt funktionierte. OU 'User / Gruppen' umbenannt in 'User_Gruppen' funktioniert. Also anscheinend hat es da ein Problem mit dem Namen oder irgendein Objekt hintendran hat sich gerade beim Namen ändern angepasst was vorher nicht funktioniert hat. Fakt ist, es läuft :) Zitieren Link zu diesem Kommentar
Bowdy79 0 Geschrieben 19. Februar 2016 Melden Teilen Geschrieben 19. Februar 2016 Hi, wir hatten gerade das gleiche Problem mit Exchange 2013. Wir haben herausgefunden, dass es bei uns am Schrägstrich "/" im Namen der OU gelegen hat. Wenn man die OU umbenennt ist der Fehler sofort behoben. Schöne Grüße Bowdy79 Zitieren Link zu diesem Kommentar
NorbertFe 2.037 Geschrieben 19. Februar 2016 Melden Teilen Geschrieben 19. Februar 2016 Wer immer noch mit solchen Sonderzeichen agiert, bloß weil es halt funktioniert... dürfte sich doch inzwischen nicht mehr wundern. ;) Zitieren Link zu diesem Kommentar
massaraksch 41 Geschrieben 19. Februar 2016 Melden Teilen Geschrieben 19. Februar 2016 Naja, dann sollte Microsoft auch dokumentieren, daß bestimmte Zeichen nicht genutzt werden dürfen. Laut MS-Definition ist im OU-Namen jedes Zeichen erlaubt (wegen LDAP-Namenskonvention). Beim Ansprechen des Objekts über den CN muß das entsprechende System den Slash halt escapen. Und da steckt wohl der Bug im Exchange (2013). OK, ich würde auch keinen Schrägstrich verwenden. Aber so ungewöhnlich scheint mir das auch wieder nicht. Zitieren Link zu diesem Kommentar
NorbertFe 2.037 Geschrieben 19. Februar 2016 Melden Teilen Geschrieben 19. Februar 2016 Ich hab ja gesagt, wer solche Sonderzeichen wider besseren Wissens, dass es eben ldap erlaubt aber diverse Anwendungen damit Probleme haben werden (!), verwendet ist selbst Schuld. Ja das ist ein Fehler im Exchange. Na und? In meinen Augen ein vermeidbarer, denn als nächstes kommt dann wieder einer der im Skript vergißt zu escapen oder irgendeine andere LDAP-abfragende Anwendung hat den nächsten Fehler. Warum also eine vermeidbare Fehlerquelle einbauen? Wir reden hier schließlich von einem Backend-System und nicht von Word Dokumenten die im Titel die ersten 23 Zeilen des Dokuments speichern. ;) Zitieren Link zu diesem Kommentar
massaraksch 41 Geschrieben 19. Februar 2016 Melden Teilen Geschrieben 19. Februar 2016 Wieso "wider besseren Wissens"? Niemand weiß vorher, daß "irgendeine" Anwendung mal ein Problem damit haben könnte. Und es geht ja hier um ein MS-eigenes Produkt und nicht um irgendein selbstentwickeltes Script oder ein Wald-und-Wiesen-LDAP-Tool. Ja das ist ein Fehler im Exchange. Na und? In meinen Augen ein vermeidbarer, ... In diesem Fall vermeidbar eindeutig durch Microsoft. Schließlich sagt ihre eigene AD-Spezifikation, daß auch Sonderzeichen (z.B. Schrägstrich) erlaubt sind! Und Exchange hatte vor Ex2013 auch kein Problem damit, nur das EAC spinnt. Also hat es MS sozusagen im EAC "versaut". Sie sollten in einem ihrer Hauptprodukte schon etwas sorgfältiger (mit den eigenen Vorgaben!) umgehen. Davon abgesehen hat das EAC von Ex2013 sowieso einige Macken. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.