Nach Kontakte Import via CSV Datei: Nach Mailversand, unzustellbar Nachricht

[vonAbisZ 2]

HI all

 

In unserem Exchange Adressbuch (globale Adressliste) sind auch Partnerkontakte von unserer Partnerfirma vorhanden, welche wir 1x pro Monat per LDAP Import importieren.

Dieser Import geschieht via Skript (Powershell) und importiert eine CSV Datei (Text Datei), welche alle Kontakte unserer Partnerfirma enthält.

Nachdem dieser Import vollbracht ist, kann Niemand von unserer Firma an diese Mailadressen eine Mail senden: Unsere Mitarbeitenden erhalten ziemlich rasch eine entsprechende NDR Nachricht.

 

Auszug NDR Nachricht:

-------------------------

Generierender Server: unserE-MailServer.InterneDomain.local

 

MCEAEX-_o=Testfirma+20Kanton+20Testkanton_ou=Exchange+20Administrative+30Group+20+28FYDIBOHF23SPXYZ+29_cn=Recipients_cn=d9bf696a2c2c4b8ba15133870fd1cc@unsereFirma.ch
Remote Server returned '550 5.1.11 RESOLVER.ADR.ExRecipNotFound; Recipient not found by Exchange Legacy encapsulated email address lookup'

-------------------------

 

Meine Analyse hat ergeben, dass immer, wenn via LDAP die Kontakte der Partnerfirma in unsere GAL (gloable Adressliste) importiert wird, sich für jeden zu importierenden Kontakt im Hintegrund sich irgend eine ID (SID?) wohl ändert?!

Mails, welche an E-Mailempfänger erfolgreich versendet werden konnten, werde per Default Einstellung von Outlook lokal zwischengespeichert.

 

Wählt natürlich nun eine Benutzerin von uns entweder via Autovorschlag im Outlook Oder: via Outlook Adressbuch (globale Adressliste) einen bekannten Kontakt aus, versendet das Mail, schlägt der Mailversand fehl, weil der alte, noch zwischengespeicherte Kontakt zwar von der Mailadresse usw. identisch ist, jedoch hat sich seine ID (im Hintergrund) geändert. Das erklärt dann auch schlüssig, so finde ich - warum wir aktuell mit diesem Problem zu kämpfen haben.

 

Meine Lösungsversuche/ Ansätze sind:

- die Adressbuch Dateien im lokalen Cache löschen => via Befehl: rd /s/q "%LocalAppData%\Microsoft\Outlook\Offline Address Books"
- Die "Autovervollständigungsliste" löschen => via Befehl: rd /s/q "%LocalAppData%\Microsoft\Outlook\RoamCache"

  Bemerkung dazu: Leider musste ich jedoch feststellen, dass die Autovervollständigung (Vorschläge) bzw. dessen Cache anscheinend durch diese Befehl (RoamCache löschen) doch nicht gelöscht wird bzw. Auswirkungen hat.

  Den Autovervollständigen Vorschlag konnte ich erst sauber auf folgende Weise löschen outlook.exe /cleanautocompletecache

 

Testresultate haben ergeben:

- Versende ich eine Mail an unsere Partnerfirma, an welche ich noch NIE eine Mail versendet hatte, so scheint diese Mail beim Empfänger anzukommen, da ich keine NDR Nachricht erhalte.

- Mailversand an unsere Partnerfirma scheint "nur" nicht zu funktionieren, wenn man an eine Person eine Mail versendet, an welche man bereits in der Vergangenheit erfolgreich Mails versenden konnte.

- Das Problem scheint sich automatisch nach einer Zeitdauer x Tage selbst zu lösen?! Hier gleich die Frage, warum nach x Tage und warum löst es sich dann von alleine, durch welchen Mechanismus auf dem Exchange oder im Outlook?

- zwei Benutzer als Test verwendet.

   > Meinen AD Benutzer, welcher KEIN servergespeichertes Profil hat => Bei meinem Benutzer bringt es nichts, wenn ich die Lösungsversuche/ Ansätze umsetze (den Autovervollständigen Vorschlag habe ich via Kreuz im Outlook gelöscht)
   > Hingegen hat mein AD Benutzer eine Ordnerumleitung auch für den %AppData*\Roaming Ordner

   > einen Testbenutzer im AD erstellt, welcher ein servergespeichertes Profil hat (wie alle anderen User im Haus) => Hier hat mein Lösungsversuch/ Ansatz bei der gleichen Person der Partnerfirma funktioniert, sprich, Mail kam an.

   > welcher auch eine Ordnerumleitung hat (wie alle anderen User im Haus), ausser dass hierbei z.B. der Ordner %AppData%\Romaing Ordner lokal auf dem Gerät verbleibt, also nicht umgeleitet wird.

 

 

Frage in die Runde:

- Liegt es am Importvorgang via LDAP, dass wir eine CSV Datei via PowerShell importieren Und: Anscheinend dadurch die importierten Kontakte dann eine neue "ID" erhalten und es darum aus meiner Sicht zu Problemen kommt (beim Mailversand)?

- Alternativen zu diesem Import Vorgang?

- Wer bietet besserer Lösungsvorschläge, als ich bereits umgesetzt habe?

- Warum gibt es Unterschiede im Verhalten beim Mailversand an Kontakte (Mailadressen) der Partnerfirma von meinem AD Benutzer im Gegensatz zu meinem erstellten Test AD Benutzer?
  Bemerkung dazu: Aus meiner Sicht könnte, wenn überhaupt etwas Einfluss hätte, aus meiner Sicht nur der eine Teil bei der Ordnerumleitung, welche ich speziell nur für meinen AD Benutzer eingerichtet hatte für AppData\Roaming einen Einfluss haben?! Jedoch bin ich der Meinung, dass die Ordner, von Microsoft, welche nun bei mir auf einen Share umgeleitet werden nur Ordner betreffen sollten, welche für die Signatur und oder die Autokorrektur im Office/ Outlook Einfluss haben?

- Auch ein unschöner Nebeneffekt meiner vielen Tests hat nun, dass in meinem Outlook das Adressbuch leer ist, kein globalen Adresslisten sind mehr verfügbar usw. Dies nur so am Rande erwähnt, das Hauptproblem und der Hauptfokus soll wirklich auf der Problemlösung sein, dass wenn wir die Kontakte der Partnerkontakte importieren, die Benutzerinnen und Benutzer nach wie vor wie gewohnt an diese Kontakte Mailen können

 

 

cheers

André

 

 

[mikro 67]

Hallo vonAbisZ.

 

Ich denke euer Import löscht jedes Mal die Kontakte und legt sie erneut an um kein update besteneder Kontakte zu machen.

Damit ändert sich die LegacyExchangeDN welche Outlook anstatt der Emailadresse nutzt. 

Ergo bekommen alle User diee schon mal Kontakt zu den angelegten KOntakten hatten, diese IMCEAEX Adressen..

Du kannst nun natürlich alle Autocomplete Caches der User löschen die dich danach sicherlich hassen werden, du kannst auch mit NK2Edit nur die einzelnen Kontakte verändern, was mühselig ist.

Ich denke aber Du solltest Deinem Kontakt Import ein Update der Kontakte zu machen beibringen und kein Löschen und erneut anlegen. Das ist das einzig richtige  Verhalten solcher "Tools"

Im Internet gibt es einige Scripte dazu und es gibt ebenso Kaufversionen davon

 

Viele Grüße

mikro

[Sunny61 806]

Werden beim Import, wie auch immer der automatisch erfolgt, die bestehenden Adressen gelöscht? Falls ja, dann ist das wohl ein korrektes Fehlerbild. Wenn der Import umgestellt wird, und dabei nur die Adressen importiert werden, die auch neu sind, sollte der Effekt nicht mehr auftreten.

[vonAbisZ 2]

Denke, es liegt wie Ihr auch der Meinung seit, am Skript. Es löscht die Kontakte und erstellt Sie neu. 
Dieser Skript hat eine externe Firma für uns gemacht und ich bin mir nicht sicher, ob es ggf. für den externen einfacher war bzw. er sehr viel weniger Aufwand hatte und  er sich darum vielleicht eben für diese Lösung entschied, anstatt ein Skript zu bauen, welches eigentlich das macht, was es machen sollte, nämlich nur die Änderungen zu importieren?!

 

Wenn wir schon beim Thema sind  kennt Ihr eine Seite, wo ich ein solches Beispiel Skript finde?

 

 

 

bearbeitet 22. Mai 2020 von vonAbisZ

[mikro 67]

Hallo,

 

klar was das für den externen einfacher, es ist immer leichter von Null anzufangen als bestehendes zu verändern, das ist mit Kontakten nicht anders...

Schau Dir mal ein paar Beispiele von Frank dazu an.

https://www.msxfaq.de/exchange/tools/privat/csvsync.htm

 

Gruß mikro

 

 

[NilsK 2.934]

Moin,

 

das Skript bzw. der Baukasten von Frank Carius verzichtet allerdings auch bewusst auf einen echten Abgleich - man achte also auf die Einschränkungen. Ein Abgleich hat auch seine Tücken, denn man muss in dem Fall schon eindeutig erkennen können, ob ein Objekt schon existiert oder nicht und was sich genau geändert hat.

 

Gruß, Nils

 

bearbeitet 22. Mai 2020 von NilsK

[mikro 67]

Schau sonst nochmal nach GALSync oder ähnlichem.

 

Gruß mikro

 

[vonAbisZ 2]

Erst einmal vielen Dank für die guten Vorschläge.
Nun bringe ich einen neuen Input, von welchem hier noch Niemand gesprochen hat Und: Ich könnte mir vorstellen, dass dieser "einfacher" ist?

Was hält Ihr davon? Den LegacyExchangeDN als X.500 Adresse den importierten Kontakten am Schluss des bestehenden PowerShell Skriptes zuweisen?

 

Also irgendwie ein Skript bauen (oder ein bestehendes abändern, wenn es irgendwo eines gibt), welches den Paramter LegacyExchangeDN von allen betroffenen Mailkontakten (keine Postfächer) ausliest und jeweils dann diesen durch eine X500 Mailadresse ersetzt bzw. jedem einzelnen Mailkontakt entsprechend hinterlegt?

 

Bis jetzt habe ich nur Lösungen gefunden, wo man ein einzelnes Skript laufen lassen kann und dann nach dem IMCEAEX gefragt wird, diesen von Hand als Eingabe eingeben muss und dann wird die Sache ausgeführt.

 

Ich dachte, ok, ich könnte ja testhalber für für einen bereits erstellten E-Mail Kontakt in der Exchange Verwaltungskonsole (in der grafischen) eine X500 Mailadresse hinzufügen, jedoch kann ich bei den importierten Kontakten gar nicht wie ich es bei einem Postfach könnte (unter E-Mailadresse), einen solchen angeben, da mir die Möglichkeit gar nicht geboten wird.

Jetzt frage ich mich natürlich zwei Dinge

1. Kann man überhaupt einem E-Mail Contact via PowerShell einen X500 Adresse hinzufügen?

2. Wenn Punkt 1 ja, dann: Kann man ein Skript bauen, welches wie oben geschildert für jeden Mail Contact den LegacyExchangeDN ausliest und für jeden Mail Contact in eine X500 Adresse umwandelt? 

 

So wie ich gelesen habe (testen konnte ich es ja noch nicht), könnte ich dann anscheinend einem bereits importierten E-Mail Contact nun eine Mail versenden, ohne dass ich eine NDR erhalte?

Den LegacyExchangeDN könnte ich z.B. für einen einzelnen Benutzer so auslesen: Get-MailContact -identity hans.muster@domain.ch | fl LegacyExchangeDN

 

Jedoch bringt mir dies nicht so viel, denn ich müsste ja ein Skript haben, welches dies gleich für alle Mailkontakte macht

[NilsK 2.934]

Moin,

 

Je nachdem, was da genau passiert und um welche Mengen es geht, wäre es auch durchaus machbar, ein Skript zu schreiben, das den Abgleich einfach ordentlich macht. Wichtig ist eigentlich nur, dass man anhand eines Feldes einen vorhandenen Kontakt eindeutig erkennt. Anhand dessen entscheidet man, was zu tun ist: aktualisieren oder neu erzeugen.

 

Bevor ich jetzt in einem Skript irgendwie bastele, würde ich die Energie eher in eine direkte Lösung stecken.

 

Gruß, Nils