14
Exchange 2019 CU13 SU2V2 - Fehler beim Postbox editieren über EAC bei Benutzern mit Leerzeichen
Hallo erstmal, ich weiß gar nicht, ob ich der einzige bin mit dem Problem, aber ich sag mal so - es nervt langsam :D
Also, Exchange 2019 auf Server 2019 installiert, AD Server ist ebenfalls ein 2019er mit aktuellen Updates und Schema.
Es gibt sehr viele Benutzeraccounts welche Leerzeichen haben beim Anmeldenamen, so wie ein Mitarbeiter eben auch seinen vor- und Zuname in einen Brief schreiben würde., auch haben manche Umlaute im Namen. E-Mail Adressen sind natürlich ohne umlaute oder Leerzeichen.
Seit dem neusten Update vom Exchange gibts jetzt aber das Problem, wenn wir einen Benutzer in der EAC editieren , man das ganze nicht Speichern kann, weil der "Benutzeranmeldename" ungültig sei. Das Problem gab es all die Jahre zuvor mit Exchange 2013 und auch mit Exchange 2019bis zu diesem update noch nie. Abhilfe verschaff ich mir da nur, indem ich die Benutzer kurzzeitig umbenenne, Postboxeinstellungen speichere und über das AD wieder so wie es vorher war benenne.
Ist da irgendwas bekannt warum das auf einmal nicht mehr geht? Beim Günter Born gibt es scheinbar auch ein paar Blog Leser mit dem selben Problem: https://www.borncity.com/blog/2023/08/15/exchange-server-august-2023-upd ...
aber auch keine wirkliche Lösung.
Kommt jetzt bitte nicht mit - Leerzeichen/Umlaute im Anmeldename? DAU !!!einseinseinself!
es ist seit Jahren Zulässig, es gibt kein offizielles MS Schreiben was das verbietet, auch keine Technische "Hürde" die das anlegen von Benutzern nach dem Schema verhindert. Ist euch da was bekannt ob das Problem auf der ToDo Liste bei MS steht?
Also, Exchange 2019 auf Server 2019 installiert, AD Server ist ebenfalls ein 2019er mit aktuellen Updates und Schema.
Es gibt sehr viele Benutzeraccounts welche Leerzeichen haben beim Anmeldenamen, so wie ein Mitarbeiter eben auch seinen vor- und Zuname in einen Brief schreiben würde., auch haben manche Umlaute im Namen. E-Mail Adressen sind natürlich ohne umlaute oder Leerzeichen.
Seit dem neusten Update vom Exchange gibts jetzt aber das Problem, wenn wir einen Benutzer in der EAC editieren , man das ganze nicht Speichern kann, weil der "Benutzeranmeldename" ungültig sei. Das Problem gab es all die Jahre zuvor mit Exchange 2013 und auch mit Exchange 2019bis zu diesem update noch nie. Abhilfe verschaff ich mir da nur, indem ich die Benutzer kurzzeitig umbenenne, Postboxeinstellungen speichere und über das AD wieder so wie es vorher war benenne.
Ist da irgendwas bekannt warum das auf einmal nicht mehr geht? Beim Günter Born gibt es scheinbar auch ein paar Blog Leser mit dem selben Problem: https://www.borncity.com/blog/2023/08/15/exchange-server-august-2023-upd ...
aber auch keine wirkliche Lösung.
Kommt jetzt bitte nicht mit - Leerzeichen/Umlaute im Anmeldename? DAU !!!einseinseinself!
es ist seit Jahren Zulässig, es gibt kein offizielles MS Schreiben was das verbietet, auch keine Technische "Hürde" die das anlegen von Benutzern nach dem Schema verhindert. Ist euch da was bekannt ob das Problem auf der ToDo Liste bei MS steht?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3197918420
Url: https://administrator.de/forum/exchange-2019-cu13-su2v2-fehler-beim-postbox-editieren-ueber-eac-bei-benutzern-mit-leerzeichen-3197918420.html
Ausgedruckt am: 27.12.2024 um 03:12 Uhr
14 Kommentare
Neuester Kommentar
Moin,
Gruß,
Dani
Hallo erstmal, ich weiß gar nicht, ob ich der einzige bin mit dem Problem, aber ich sag mal so - es nervt langsam :D
wenn es so nervt erstelle noch einen Support Case. Wenn es ein Bug ist, wird dir dieser nicht berechnet.Ist euch da was bekannt ob das Problem auf der ToDo Liste bei MS steht?
Es wird vermutlich maximal eine handvoll Leute hier geben, welche direkten Zugriff zur Produktgruppe haben. Und ob diese ihre Vitamine für sowas hernehmen, glaube ich kaum.es ist seit Jahren Zulässig, es gibt kein offizielles MS Schreiben was das verbietet, auch keine Technische "Hürde" die das anlegen von Benutzern nach dem Schema verhindert
nur weil es nicht verboten ist, heißt es nicht automatisch dass es gut ist. Eine Single Label Domain ist technisch auch nicht verboten, aber man macht es trotzdem nicht mehr. Anderenfalls muss man mit den Folgen leben. Es zeigt mir einmal mehr, woher unsere Verbotsmentalität kommt...Gruß,
Dani
Ich finde es nur seltsam, das scheinbar nur extrem wenige Leute davon betroffen sind, oder hat wirklich niemand Domänenbenutzer MIT Leerzeichen?
Ich versuche aktuell noch herauszufinden ob das Problem wirklich vom Exchange her kommt, oder am ende doch vom AD - dieser wurde im gleichen Atemzug ebenfalls auf das neuste CU aktualisiert...
Ich versuche aktuell noch herauszufinden ob das Problem wirklich vom Exchange her kommt, oder am ende doch vom AD - dieser wurde im gleichen Atemzug ebenfalls auf das neuste CU aktualisiert...
Username ist immer ohne Leerzeichen. Das haben wir schon bei Windows 2000 gelernt.
Ich leider genau andersherum auf den Schulungen, es hieß immer Leerzeichen sind möglich, aber manche ältere Programme/Prozesse könnten damit Probleme haben...Das waren Server 2012R2, 2016 und 2019 Schulungen (bei den letzten zwein hatte ich nur mal nachgefragt, waren auch nur "Basic" Schulungen, also keine offiziellen von MS)
Lief ja auch gut 10 Jahre lang so, aber jetzt auf einmal eben nicht mehr - ohne das irgendwo etwas in den Changelogs steht dass da was geändert wurde...
Ich suche auch schon seit Stunden bei Microsoft, wo das klipp und klar steht, dass Leerzeichen nicht zulässig sind, sei es bei AD Benutzern, Gruppennamen oder OU-Namen. Das gegenteil ist eher der fall: früher hatte Microsoft noch mit erwähnt dass wenn OUs Leerzeichen enthalten, solle man bitte "" nutzen bei den Commands damit das gefunden wird, in heutigen Anleitungen steht bei den commands immer schon die Anführunsgszeichen mit dabei
https://learn.microsoft.com/en-us/exchange/prepare-active-directory-and- ...
https://learn.microsoft.com/en-us/exchange/plan-and-deploy/prepare-ad-an ...
Lt. Hersteller ist es also zulässig mit Leerzeichen zu arbeiten. Außer bei Azure oder MS365 Cloud gedöhns - da darf kein Leeerzeichen sein :D Das riecht für mich aber eher nach fauler/schlechter Programmierarbeit wenn irgendwo das Leerzeichen oder Sonderzeichen nicht gehen...Bei den ganzen Privaten PCs zuhause finde ich bei den allermeisten Leuten auch als Benutzername den vollen namen mit leerzeichen - genauso ist dann auch der Ordner unter C.\Users\... angelegt, also mit Leerzeichen. Ich denke mal, das ohne Leerzeichen oder auf 16 Zeichen beschränken war eine sache vor Windows 2000, nur hat sich das ganze ja weiter entwickelt...wozu gibts SIDs ?
Lief ja auch gut 10 Jahre lang so, aber jetzt auf einmal eben nicht mehr - ohne das irgendwo etwas in den Changelogs steht dass da was geändert wurde...
Ich suche auch schon seit Stunden bei Microsoft, wo das klipp und klar steht, dass Leerzeichen nicht zulässig sind, sei es bei AD Benutzern, Gruppennamen oder OU-Namen. Das gegenteil ist eher der fall: früher hatte Microsoft noch mit erwähnt dass wenn OUs Leerzeichen enthalten, solle man bitte "" nutzen bei den Commands damit das gefunden wird, in heutigen Anleitungen steht bei den commands immer schon die Anführunsgszeichen mit dabei
https://learn.microsoft.com/en-us/exchange/prepare-active-directory-and- ...
https://learn.microsoft.com/en-us/exchange/plan-and-deploy/prepare-ad-an ...
Lt. Hersteller ist es also zulässig mit Leerzeichen zu arbeiten. Außer bei Azure oder MS365 Cloud gedöhns - da darf kein Leeerzeichen sein :D Das riecht für mich aber eher nach fauler/schlechter Programmierarbeit wenn irgendwo das Leerzeichen oder Sonderzeichen nicht gehen...Bei den ganzen Privaten PCs zuhause finde ich bei den allermeisten Leuten auch als Benutzername den vollen namen mit leerzeichen - genauso ist dann auch der Ordner unter C.\Users\... angelegt, also mit Leerzeichen. Ich denke mal, das ohne Leerzeichen oder auf 16 Zeichen beschränken war eine sache vor Windows 2000, nur hat sich das ganze ja weiter entwickelt...wozu gibts SIDs ?
Moin Moin zusammen,
auch bei uns ist mir aktuell diese Problem aufgefallen. Jedoch nicht bei allen Server. Updates wurde auch nicht installiert.
Gibt es schon etwas neues?
Gruß HeinrichM
auch bei uns ist mir aktuell diese Problem aufgefallen. Jedoch nicht bei allen Server. Updates wurde auch nicht installiert.
Gibt es schon etwas neues?
Gruß HeinrichM
1
Und ich dachte schon, ich wäre der einzige mit dem Problem.
@HeinrichM - Meinst du nicht bei allen Servern verschiedene Kunden-Server? Oder explizit bei euch? Wo fällt es euch da auf?
@a. Posch - scheinbar nicht ;) du hattest doch auch beim Günter Born in den Blog mit geschrieben, oder?
@a. Posch - scheinbar nicht ;) du hattest doch auch beim Günter Born in den Blog mit geschrieben, oder?
Bei einem Kunden-Server ist es mir aufgefallen, dann habe ich bei uns nachgeschaut und da ist alles iO. Werde mir das gleich mal etwas genauer ansehen...
Habt ihr auch Benutzer mit Leerzeichen im Anmeldenamen, oder euer Kunde?
Wir haben über all welche mit Leerzeichen - sollte auch kein Problem sein, da schon seit....mehr als 10 Jahren dies so Praxis ist.
Moin moin,
ich komme dem Problem etwas näher. Bei den Betroffenen Servern handelt es sich um Exchange Server 2019 CU13 alle haben das Security Updates for Exchange Server 2019 Cumulative Update 13 (KB5030524) installiert. Einen Exchange Server 2019 habe ich, wo das Security Updates for Exchange Server 2019 Cumulative Update 13 (KB5026261) installiert ist und hier gibt es keine Probleme.
Scheint also am KB5030254 zu liegen.
Kann das von jemandem bestätigt werden?
Gruß HeinrichM
ich komme dem Problem etwas näher. Bei den Betroffenen Servern handelt es sich um Exchange Server 2019 CU13 alle haben das Security Updates for Exchange Server 2019 Cumulative Update 13 (KB5030524) installiert. Einen Exchange Server 2019 habe ich, wo das Security Updates for Exchange Server 2019 Cumulative Update 13 (KB5026261) installiert ist und hier gibt es keine Probleme.
Scheint also am KB5030254 zu liegen.
Kann das von jemandem bestätigt werden?
Gruß HeinrichM
Kann ich bestätigen! Hab eben in einer Sandboxumgebung mal das KB5030524 Update deinstalliert - schon kann ich wieder Speichern auch mit Leerzeichen im Benutzeranmeldename. Ich kann da alle möglichen Zeichen eingeben, also auch "" oder mehrere Punkte hintereinander - das geht nach dem Update ebenfalls nicht bzw sind da nicht alle Zeichen zulässig, da kommt der Fehler wie oben im Screenshot wo alle zulässigen Zeichen aufgeführt sind. Diesen Fehler scheint es vor dem Update garnicht zu geben, ich kann da eingeben was ich will - er akzeptiert das als Anmeldename.
Es handelt sich ja um den UPN Anmeldename, so wie es im AD hinterlegt ist. Im AD kann man als UPN Name wählen was man will, egal ob mehrere Anführungszeichen, Punkte, oder Leerzeichen. der Prä Win2000 Anmeldename, was genauer gesagt der sAMAccountName ist, ändert sich entsprechend ab wenn er zeichen nicht kann.
Am AD Client PC meldet man sich standardmäßig wenn man nur den Benutzernamen angibt ja mit genau den sAMAccountName an (also einfach nur wie in dem Screenshot hier Test_1) - dieser darf auch Leerzeichen enthalten - verbietet das AD ja nicht bei der Benutzererstellung. Würde man versuchen sich mit Test"" ... anzumelden (ohne den Domänensuffix dahinter zu schreiben, würde Windows meckern dass er den Benutzer nicht gefunden hat. Meldet man sich aber mit dem UPN name an, also Test"" ...@domäne.local - würde die Windows Anmeldung auch genau so funktionieren (unter C:\Users\ legt er den Benutzerordner dennoch mit dem sAMAccountName an).
Mich wundert es halt echt, warum nach dem Exchange Update über Exchange-benutzerpostfach einstelungen keine Sonderzeichen mehr im UPN möglich sind - im AD hingegen aber nach wie vor schon...was hat MS da gebaut, warum ist da nichts dergleichen dokumentiert??
Es handelt sich ja um den UPN Anmeldename, so wie es im AD hinterlegt ist. Im AD kann man als UPN Name wählen was man will, egal ob mehrere Anführungszeichen, Punkte, oder Leerzeichen. der Prä Win2000 Anmeldename, was genauer gesagt der sAMAccountName ist, ändert sich entsprechend ab wenn er zeichen nicht kann.
Am AD Client PC meldet man sich standardmäßig wenn man nur den Benutzernamen angibt ja mit genau den sAMAccountName an (also einfach nur wie in dem Screenshot hier Test_1) - dieser darf auch Leerzeichen enthalten - verbietet das AD ja nicht bei der Benutzererstellung. Würde man versuchen sich mit Test"" ... anzumelden (ohne den Domänensuffix dahinter zu schreiben, würde Windows meckern dass er den Benutzer nicht gefunden hat. Meldet man sich aber mit dem UPN name an, also Test"" ...@domäne.local - würde die Windows Anmeldung auch genau so funktionieren (unter C:\Users\ legt er den Benutzerordner dennoch mit dem sAMAccountName an).
Mich wundert es halt echt, warum nach dem Exchange Update über Exchange-benutzerpostfach einstelungen keine Sonderzeichen mehr im UPN möglich sind - im AD hingegen aber nach wie vor schon...was hat MS da gebaut, warum ist da nichts dergleichen dokumentiert??
Ja ich bin da voll bei Dir! Ich habe dringend Einstellungen an einem Postfach machen müssen, bin dann einfach hergegangen und haben den Namen im Postfach (da wo er meckert) abgeändert (Leerzeichenraus), Einstellungen gemacht und gespeichert. Danach ins AD Namen wieder geändert und gut.
Ist keine Lösung aber so funktioniert es. Ich hoffe auf einen Wachen Moment bei MS, so dass auch das Problem mit dem nächsten Updates behoben wir. (so wie noch vieeeele andere).
Gruß HeinrichM
Ist keine Lösung aber so funktioniert es. Ich hoffe auf einen Wachen Moment bei MS, so dass auch das Problem mit dem nächsten Updates behoben wir. (so wie noch vieeeele andere).
Gruß HeinrichM
ich glaube eher, das wird nicht passieren (also das MS das fixt) in der Azure AD Cloud oder wie das da heißt darf man ja auch keine Leerzeichen verwenden....was über 20 Jahre aber bei den OnPremise Lösungen ging xD
Das was Exchange da anmeckert ist wie gesagt "nur" der UPN Name - damit melden sich die User zum glück nicht am Windows an, sondern eben nur mit dem Prä Windows 2000 logon name (=sAMAccountName) - dieser wird nicht geändert. Für die User scheint so erstmal kein Nachteil zu entstehen, wenn wir den UPN Name entsprechend anpassen wie es der Exchange da will, anmelden können die sich nach wie vor mit Vorname und Nachname mit Leerzeichen getrennt
Das was Exchange da anmeckert ist wie gesagt "nur" der UPN Name - damit melden sich die User zum glück nicht am Windows an, sondern eben nur mit dem Prä Windows 2000 logon name (=sAMAccountName) - dieser wird nicht geändert. Für die User scheint so erstmal kein Nachteil zu entstehen, wenn wir den UPN Name entsprechend anpassen wie es der Exchange da will, anmelden können die sich nach wie vor mit Vorname und Nachname mit Leerzeichen getrennt
