NorbertFe

Ich meinte Exchange ps (oranges Icon) oder Windows ps (blaues Icon). Was auch immer mir deine Logs jetzt sagen sollen, denn ich kann ja nur raten bisher.

Danke für die Info. Offenbar ja wie schon befürchtet nur auch Windows 2019, den es noch nicht zum Download gibt. ;) oder hab ich den übersehen? edit: ach ist denen ja auch aufgefallen. Toll. :|

Kommt drauf an, welche Powershell. ;) dann schau halt nach, was das trackinglog sagt. Vielleicht kommst du damit weiter. Wirklich ausführlicher war deine Beschreibung nämlich nicht.

Häh? Na klar kann man einen Kontakt emailaktivieren. Das muss man sogar, damit Exchange damit irgendwas anfangen kann. Wenn du den Kontakt natürlich direkt angelegt hast, dann ist das automatisch der Fall. Aus dem Rest deiner Erklärung werd zumindest ich nicht schlau. Vielleicht nochmal verständlicher erklären?

Frank Müller XYZ ist ja auch ein Kontakt. Wohin wird der denn geleitet? Und wurde der Kontakt auch wieder emailaktiviert?

Wo soll die Mail denn ankommen?

Ein Kontakt hat keine SID.

Die Empfehlung kann ich ja nachvollziehen, aber wie Nils schon schrieb, müssen ja beide (oder drei) CAs ihre CRL publishen und dann ists im Endeffekt egal, ob man das an einem Ort oder an mehreren tut. Planen muss man es so oder so. Erfahrungsgemäß ist Schritt 1 und Schritt 5 aus Nils Aufzählung am zeitaufwändigsten, wenn man nicht nur Windows Systeme hat. Sobald aber Hardwarekomponenten (DELL, Cisco, HP) oder Linux und diverse Appliances dazukommen, die man alle händisch mit neuen Zertifikaten betanken muß, wird das leicht eine Laufzeit von über 12 Monaten, selbst in Umgebungen von nur 100 Usern. Bye Norbert

Das gibt dir der migrationsweg sogar als Eckdaten mit. ;) einfach mal „nicht“ oberflächlich durchlesen.

Ich sag nichts... :p

15 Laufwerke? wozu braucht man denn 15 Laufwerke? Oder sind das je ein Laufwerk für 15 verschiedene nutzergruppen? ;)

Das wäre auch nicht selfsigned. ;)

Nein. wieviele Exchangeserver hast du, wie sind dort die URLs konfiguriert?

Immer diese Wildcardzertifikate ;)

Nein das macht keine Probleme. Der CN lautet dann halt exchange.firma.de und der Name steht zusammen mit autodiscover.firma.de dann auch als SAN drin. Der interne Name kann sowieso nicht in ein öffentliches Zertifikat aufgenommen werden. Abgesehen davon mußt du das Zertifikat ja nicht an den SMTP Service binden. ;)

So bisschen selber suchen ist gar nicht dein Ding, oder? Wie wärs denn mit new-emailaddresspolicy?

Ich kann mich ja nochmal wiederholen: https://www.mcseboard.de/topic/214091-änderung-der-neue-primary-e-mail-adresse-hinterlegen-und-bestehende-als-alias-behalten/?do=findComment&comment=1364685

Ich kann nicht auf deinen Bildschirm gucken. Du müßtest also ggf. etwas ausführlicher oder mit Screenshot usw. arbeiten, damit man das nachvollziehen kann.

Kann ich hier am Exchange 2016 mit CU11 nicht nachvollziehen. Entweder patchst du mal auf aktuellen Stand (CU21 afair) und testest dann nochmal, oder du versuchst es über die Powershell.

Und welche Berechtigungen hast du auf Quell- und Zielordner? Unabhängig davon ist "verschieben" innerhalb des selben Volumes eben mit genau diesem Phänomen verbunden.

Wo genau erhältst du diese Fehlermeldung? Welchen Patchstand hat dein Server?

Schreib ich irgendwie unverständlich?

Ja. Vielleicht schaust du dir deinen Exchange ja einfach mal an. :)

Ja und? Nennt sich "localpart", was ich oben geschrieben habe, oder?

Warum so umständlich? Bau ne neue Emailadressrichtlinie und vergib die neue Emailadresse (domain oder localpart) und definiere sie als Antwortadresse. Bestehende Adressen werden _NICHT_ gelöscht.