9
Gleicher Username, andere SID
Guten Morgen,
wir hatten bei uns in der Firma vor einigen Monaten einen Mitarbeiter mit dem Benutzernamen M.Mustermann. Als dieser das Unternehmen verlassen hatte, wurde sein Benutzerkonto gelöscht. Jetzt hat ein neuer Mitarbeiter angefangen, dessen Benutzername ebenfalls M.Mustermann ist. Für ihn wurde ein komplett neues Benutzerkonto erstellt, welches jetzt denselben Alias, aber eine andere SID hat.
Bei vielen Anwendern ist jetzt im Outlookcache noch der Alias mit der alten SID drin bzw. Verteilergruppen, welche den Alias mit der alten SID enthalten. Bequem wie Anwender sind, greifen sie natürlich auf den Cache zurück, wenn nach 1-2 Buchstaben schon ein passender Empfänger vorgegeben wird.
Leider kommen diese Emails nicht an und die Anwender scheinen auch keine Zustellfehler zu bekommen.
Gibt es eine Möglichkeit dieses Problem zentral zu lösen?
wir hatten bei uns in der Firma vor einigen Monaten einen Mitarbeiter mit dem Benutzernamen M.Mustermann. Als dieser das Unternehmen verlassen hatte, wurde sein Benutzerkonto gelöscht. Jetzt hat ein neuer Mitarbeiter angefangen, dessen Benutzername ebenfalls M.Mustermann ist. Für ihn wurde ein komplett neues Benutzerkonto erstellt, welches jetzt denselben Alias, aber eine andere SID hat.
Bei vielen Anwendern ist jetzt im Outlookcache noch der Alias mit der alten SID drin bzw. Verteilergruppen, welche den Alias mit der alten SID enthalten. Bequem wie Anwender sind, greifen sie natürlich auf den Cache zurück, wenn nach 1-2 Buchstaben schon ein passender Empfänger vorgegeben wird.
Leider kommen diese Emails nicht an und die Anwender scheinen auch keine Zustellfehler zu bekommen.
Gibt es eine Möglichkeit dieses Problem zentral zu lösen?
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: 510106
Url: https://administrator.de/contentid/510106
Ausgedruckt am: 22.11.2024 um 07:11 Uhr
9 Kommentare
Neuester Kommentar
Moin,
blöd gesagt würde ich ausscheidende MAs auch nicht einfach im AD löschen.
Der neue MA hätte in diesem Fall mit einem abgewandelten Namenskürzel im AD angelegt werden müssen.
Jetzt wäre es ratsam zur Behebung den Cache bei den Usern zu leeren.
blöd gesagt würde ich ausscheidende MAs auch nicht einfach im AD löschen.
Der neue MA hätte in diesem Fall mit einem abgewandelten Namenskürzel im AD angelegt werden müssen.
Jetzt wäre es ratsam zur Behebung den Cache bei den Usern zu leeren.
1
Moin ,
deswegen löscht man sie nicht. Ich deaktiviere sie immer und packe sie in eine extra OU dafür.
Ansonsten bekommst du das zentral nur hin , indem du dir per Script was bastelst.Je nachdem welche Outlookversionen du einsetzt.
Wie viele Clients hast du denn ?
Gruss
deswegen löscht man sie nicht. Ich deaktiviere sie immer und packe sie in eine extra OU dafür.
Ansonsten bekommst du das zentral nur hin , indem du dir per Script was bastelst.Je nachdem welche Outlookversionen du einsetzt.
Wie viele Clients hast du denn ?
Gruss
Wir haben ca. 300 Clients. und nutzen Outlook 2016 mit Exchange 2010.
Bis 2007 war die AutoVervollständigen-Liste noch in der NK2-Datei gespeichert, da hätte ich mir per Skript etwas vorstellen können. Seit 2010 liegt die Liste in einer verborgenen Nachricht im Nachrichtenspeicher. Da dürfte es schwierig werden zentral etwas zu basteln. Zumindest hätte ich spontan keine Idee. Die Liste bei allen Anwendern zu löschen/leeren ist die letzte Option.
Für die Zukunft werden wir ausscheidende Mitarbeiter auch nicht mehr löschen.
Leider ist das Kind jetzt schon in den Brunnen gefallen, weshalb ich für alle Vorschläge dankbar bin.
Bis 2007 war die AutoVervollständigen-Liste noch in der NK2-Datei gespeichert, da hätte ich mir per Skript etwas vorstellen können. Seit 2010 liegt die Liste in einer verborgenen Nachricht im Nachrichtenspeicher. Da dürfte es schwierig werden zentral etwas zu basteln. Zumindest hätte ich spontan keine Idee. Die Liste bei allen Anwendern zu löschen/leeren ist die letzte Option.
Für die Zukunft werden wir ausscheidende Mitarbeiter auch nicht mehr löschen.
Leider ist das Kind jetzt schon in den Brunnen gefallen, weshalb ich für alle Vorschläge dankbar bin.
Zitat von @Falaffel:
Wir haben ca. 300 Clients. und nutzen Outlook 2016 mit Exchange 2010.
Bis 2007 war die AutoVervollständigen-Liste noch in der NK2-Datei gespeichert, da hätte ich mir per Skript etwas vorstellen können. Seit 2010 liegt die Liste in einer verborgenen Nachricht im Nachrichtenspeicher. Da dürfte es schwierig werden zentral etwas zu basteln. Zumindest hätte ich spontan keine Idee. Die Liste bei allen Anwendern zu löschen/leeren ist die letzte Option.
Für die Zukunft werden wir ausscheidende Mitarbeiter auch nicht mehr löschen.
Leider ist das Kind jetzt schon in den Brunnen gefallen, weshalb ich für alle Vorschläge dankbar bin.
Wir haben ca. 300 Clients. und nutzen Outlook 2016 mit Exchange 2010.
Bis 2007 war die AutoVervollständigen-Liste noch in der NK2-Datei gespeichert, da hätte ich mir per Skript etwas vorstellen können. Seit 2010 liegt die Liste in einer verborgenen Nachricht im Nachrichtenspeicher. Da dürfte es schwierig werden zentral etwas zu basteln. Zumindest hätte ich spontan keine Idee. Die Liste bei allen Anwendern zu löschen/leeren ist die letzte Option.
Für die Zukunft werden wir ausscheidende Mitarbeiter auch nicht mehr löschen.
Leider ist das Kind jetzt schon in den Brunnen gefallen, weshalb ich für alle Vorschläge dankbar bin.
Habs zwar nicht ausprobiert. Aber würde es nicht gehen den Cache-Modus von Outllook per GPO zu deaktiviere. Im Anschluss per Script im Userordner "C:\Users\%username%\AppData\Local\Microsoft\Outlook die Daten umbennen oder löschen. Und dann per GPO den Cahemodus wieder einschalten, sofern überhaupt benötigt.
Das gepaart mit Logging und kleinen Gruppen , könnte das klappen.
Gruss
Der Outlook Cache Mode hat nichts mit diesem Szenario zu tun. Beim Cache Mode geht es um das lokale Zwischenspeichern der Exchange Postfachs.
Im beschriebenen Szenario geht es aber um den Cache der in den Empfänger-Feldern eingetragenen Adressaten. Oft auch "Nickname Cache" genannt.
Im beschriebenen Szenario geht es aber um den Cache der in den Empfänger-Feldern eingetragenen Adressaten. Oft auch "Nickname Cache" genannt.
Zitat von @itisnapanto:
deswegen löscht man sie nicht. Ich deaktiviere sie immer und packe sie in eine extra OU dafür.
Ach deswegen!?deswegen löscht man sie nicht. Ich deaktiviere sie immer und packe sie in eine extra OU dafür.
Eine sehr steile These!
Wir bei uns löschen Konten deshalb nicht sofort, weil es immer wieder mal vorkommt, dass Benutzerkonten irrtümlich von den Verwaltungen der Kunden abgemeldet werden (zur Löschung gemeldet). Aber wir löschen Sie definitiv nach x Wochen, wenn es bis dahin kein "Kommando zurück!" gab. Die zugehörigen Daten werden je nach Kundenanforderung behandelt. Gesichert, exportiert, bereitgestellt und/oder gelöscht. Je, nach dem.
Und das Problem mit diesem Nickname Cache hat man dann so oder so.
Andere werden andere Gründe dafür oder dagegen haben. Und Ihr eigenes Verfahren dafür.
Wie schaut es hiermit aus?
Clearing AutoComplete and other Recipient Caches
Bringt dich das der Lösung deines Problems etwas näher?
Clearing AutoComplete and other Recipient Caches
Bringt dich das der Lösung deines Problems etwas näher?
Hallo,
Beim Name Auto Complete Cache handelt es sich um einen Bytestream der direkt im Benutzerpostfach gespeichert wird.
Das vorgeschlage Script von Groot würde seinen Zweck erfüllen, allerdings löscht es den vollständigen Cache des übergebenen Postfaches und nicht nur einzelne Elemente daraus. Einzelne Elemente sind derzeit IMHO nur mit Outlook möglich.
Weil Benutzer den Cache aber gerne als Adressbuchersatz nutzen, folgende zwei alternative Varianten.
Der User den es betrifft und welcher ohne seinen Cache nicht seiner Tätigkeit nachgehen kann, hat die Möglichkeit den Eintrag selbst zu korrigieren.
Beim Addressvorschlag dann das Schwarze X neben den Namen klicken und den Empfänger anschließend aus der GAL auswählen. Sollte eigentlich auch reichen den Empfänger einfach erneut aus der GAL zu wählen aber ich kommuniziere meist das es besser ist den Eintrag vorab zu löschen.
Variante zwei ist Serverseitig und erfordert Exchange Administrativen Zugriff. Tatsächlich eigentlich nur Schreibrecht auf das proxyAdresses Atribute des neuen SamAccountNames.
Es ist möglich aus dem ehemaligen LegacyExchangeDN (die IMCEAEX Adresse aus der Unzustellbarkeitsnachricht) eine X500 Proxy Adresse für den neuen SamAccountName zu machen. Dann funktioniert die Zustellung auch ohne Userseitiges zutun. Natürlich darf dafür das Original Objekt (wie geschrieben) nicht mehr existieren.
Zum konvertieren des LegacyExchangeDN nach X500 hilft dieses Script.
https://gallery.technet.microsoft.com/office/IMCEAEX-to-X500-Converter-4 ...
Ob sich der Aufwand lohnt sollte von Fall zu Fall entschieden werden.
Ich teile den Usern immer mit das es sich beim Name Auto Complete Cache um einen flüchtigen Speicher handelt, wo der Hersteller die Aktualität nicht gewährleistet und Einträge eben von Zeit zu Zeit korrumpieren können. Daher ist es Ratsam diesen im Anlassfall neu aufzubauen. Und genau ihr aktuelles Problem wäre ein solcher Anlassfall.
Wirkt tatsächlich in den meisen Fällen.
Lg
Beim Name Auto Complete Cache handelt es sich um einen Bytestream der direkt im Benutzerpostfach gespeichert wird.
Das vorgeschlage Script von Groot würde seinen Zweck erfüllen, allerdings löscht es den vollständigen Cache des übergebenen Postfaches und nicht nur einzelne Elemente daraus. Einzelne Elemente sind derzeit IMHO nur mit Outlook möglich.
Weil Benutzer den Cache aber gerne als Adressbuchersatz nutzen, folgende zwei alternative Varianten.
Der User den es betrifft und welcher ohne seinen Cache nicht seiner Tätigkeit nachgehen kann, hat die Möglichkeit den Eintrag selbst zu korrigieren.
Beim Addressvorschlag dann das Schwarze X neben den Namen klicken und den Empfänger anschließend aus der GAL auswählen. Sollte eigentlich auch reichen den Empfänger einfach erneut aus der GAL zu wählen aber ich kommuniziere meist das es besser ist den Eintrag vorab zu löschen.
Variante zwei ist Serverseitig und erfordert Exchange Administrativen Zugriff. Tatsächlich eigentlich nur Schreibrecht auf das proxyAdresses Atribute des neuen SamAccountNames.
Es ist möglich aus dem ehemaligen LegacyExchangeDN (die IMCEAEX Adresse aus der Unzustellbarkeitsnachricht) eine X500 Proxy Adresse für den neuen SamAccountName zu machen. Dann funktioniert die Zustellung auch ohne Userseitiges zutun. Natürlich darf dafür das Original Objekt (wie geschrieben) nicht mehr existieren.
Zum konvertieren des LegacyExchangeDN nach X500 hilft dieses Script.
https://gallery.technet.microsoft.com/office/IMCEAEX-to-X500-Converter-4 ...
Ob sich der Aufwand lohnt sollte von Fall zu Fall entschieden werden.
Ich teile den Usern immer mit das es sich beim Name Auto Complete Cache um einen flüchtigen Speicher handelt, wo der Hersteller die Aktualität nicht gewährleistet und Einträge eben von Zeit zu Zeit korrumpieren können. Daher ist es Ratsam diesen im Anlassfall neu aufzubauen. Und genau ihr aktuelles Problem wäre ein solcher Anlassfall.
Wirkt tatsächlich in den meisen Fällen.
Lg
Super, danke. Wir haben mittlerweile die User angeschrieben, dass sie das Objekt aus dem Cache löschen sollen, wenn es dort enthalten ist. Ich habe mir aber deinen zweiten Vorschlag notiert und werde das mal durchspielen. Das klingt sehr interessant. Danke dir.
