cj_berlin

So ist es. Aber wenn Du "einfach" AD-User und Exchange-Mailbox entkoppeln willst, hilft die Installation von Exchange im separaten Resource Forest und Arbeiten mit Linked Mailboxen. Oder gleich nach M365

Nein, wie @mikro schon sagte. Man kann höchstens per Cmdlet Extension Agent erreichen, dass die alte Adresse wieder in das mail-Attribut reingeschrieben wird. Allerdings kann es alle möglichen Arten von Weirdness in Exchange verursachen, und unsupported ist es allemal. Besser man wandelt einen MailboxUser in einen MailUser. Dann bleibt er ein valider Exchange-Empfänger, hat aber dann kein Postfach.

Moin, AADDS ist ein Offering, das ein bestimmtes Nutzungsszenario hat: User Forest: Du hast eine Application in der Cloud, die nichts besseres als einen LDAP Bind zur Authentifizierung (oder zum Nachschlagen von Benutzer-Infos) beherrscht. Du hast entweder gar kein On-Prem-AD oder möchtest vermeiden, dass aus der Wolke per LDAP ins On-Prem-AD kommuniziert wird. Resource Forest: Du hast eine Web Application in der Cloud, gegen welche sich on-Prem-User gern per NTLM oder Kerberos authentifizieren würden. Du hast ein On-Prem-AD und ein VPN, durch das AADDS eine einseitige Vertrauensstellung zum On-Prem-AD unterhalten könnte. Wenn Du exakt diese Use Cases hast, kann es passieren, dass AADDS gut auf Deine Anforderungen passt. Geht Dein Use Case über die oben beschriebenen Varianten hinaus, wirst Du es mit AADDS vermutlich nicht abdecken können.

Dann Big Bang mit allem, nicht nur Exchange. Ist ein langes Wochenende, aber dann hast Du es hinter Dir. Brauchst keinen Cross-Forest-Zugriff, keine Koexistenz usw.

Forest Trust Linked Mailboxes Autodiscover SCP in die alte Domain übertragen Mailflow umstellen Veröffentlichung für externe Clients (z.B. ActiveSync-Smartphones) umstellen, falls vorhanden Wenn nur einer der Begriffe bei Dir die geringste Unsicherheit auslöst, ist das Thema für ein freies offenes Internet-Forum zu komplex.

Ja, so etwas ist möglich. Das ist eine Cross-Forest-Migration, die Du vorhast, und beinhaltet einige Schritte: Vertrauensstellung zwischen den beiden Forests, damit a. Inhaltsumzug mit Bordmitteln möglich ist und b. die User mit Accounts aus "alt" auf ihre Postfächer und andere Ressourcen in "neu" zugreifen können. Mailflow --> Mails, die nach "alt" eingeliefert werden, müssen bis zur Umstellung aller Benutzer entweder in alt oder in neu ankommen, und nicht-migrierte Benutzer müssen an die Migrierten Mails schicken können und vice versa. [entfällt, falls Big Bang-Umstellung] Organisationsvertrauen, damit migrierte und nicht migrierte User gemeinsam Free-Busy haben und Termine planen können [entfällt, falls Big Bang-Umstellung] Autodiscover in "alt"-AD in Richtung "neu"-Exchange. Je nachdem, ob Big Bang, ist es einfach oder weniger einfach Fazit: Wenn Du so etwas noch nie gemacht hast, hol Dir Hilfe.

Moin, läuft Mailstore denn mit auf dem Exchange Server?

Moin, laut Dokumentation nutzt MailStore für den EWS-Zugriff den Namen, den Du da eingegeben hast: https://help.mailstore.com/de/server/E-Mail-Archivierung_von_Microsoft_Exchange_2016#Schritt_2:_Die_Archivierung_einrichten

Moin, dann bestimmen die Clients ihren Standort falsch. Vermutlich sind nicht alle Client-Netze in Sites&Services eingepflegt. Das würdest Du ja auch im GPRESULT sehen, da steht der aktuell verwendete Standort ebenfalls im Report.

Die, die noch online sind --> migrieren. Die, die verwaist sind --> im AD löschen und in Exchange 2016 neu erstellen.

Das musst Du lösen, denn das ist nicht "by design", sondern konkret bei Dir so.

Dass Anwendungen, die Kerberos verwenden und den UPN intern bereits vermerkt haben, dann verwirrt sind. Dass User, die sich bereits mit UPN anmelden (weil ihnen jemand gesagt hat, dass man das heutzutage so macht), dann erfahren müssen, dass deren UPN jetzt ein anderer ist. Ich glaube allerdings nicht, dass mit der Anpassung der UPN plötzlich NEGO überall funktioniert. Aber probieren kann man's, gerade wenn man eh vorhat, in die Cloud zu gehen.

Cross-Post: https://social.technet.microsoft.com/Forums/de-DE/41528b37-0547-438b-8dbe-f3c6c592b6a7/exchange-online-mailbox-migration-nicht-mglich-da-ews-virtual-directory-im-frontend-nur-mit-ntlm?forum=exchange_serverde

Hashtable oder Custom Object.

...das beruht aber auf der Annahme, dass die Datei mit dem höchsten Datum auch die zuletzt geschriebene ist. Wenn niemand die Dateien anfasst, wird es vermutlich auch so sein, aber halt nur dann. Ist das Datum aber so formatiert wie oben, genügt bereits die alphabetische Sortierung nach Namen. In VBS sind Deine Stichpunkte "FileSystemObject", "GetFolder" und die "Files"-Eigenschaft eines Folder-Objektes.

...unter Berücksichtigung von https://it-pro-berlin.de/2021/01/powershell-quirks-happy-new-iso8601-year/

Yep.

Das stand sogar in der Supportability Matrix. Jetzt nicht mehr...

Klar, bei Citrix ist der orchestrierte Reboot der Worker seit Äonen ein Produkt-Feature.

Moin, soeben erschienen: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-2022-h1-cumulative-updates-for-exchange-server/ba-p/3285026 Betrieb von Exchange ab 2013 im AD mit 2022er DCs, Installation von Exchange 2019 auf Server 2022, Recipient Management in EXO ohne on-prem-Exchange-Server, Hybridlizenz für Exchange 2019 und mehr

Moin, Mark Minasi sagte in 2008, "Of course, the days of WINS are numbered. Unfortunately, that number is pretty high." So ist es auch mit EWS. Und der TO sagte, "Exchange ist über die Telekom gemietet oder so". Daher vermutlich nix Graph.

Moin, sowas ist meistens mit SSL verbunden, kann aber schlicht am Load Balancer des Exchange-Providers liegen. Dagegen bist Du machtlos, Du musst halt Fehler in Skripten behandeln und die Anfrage bzw. den gesamten Verbindungsaufbau wiederholen, falls welche auftreten.

Da dies den Reboot des Hosts erfordert, hättest Du da ein kleines Problem - es sei denn, die Domäne wird nicht neu erzeugt, sondern es gibt bereits DCs davon außerhalb dieses Hosts.

Moin, ohne das jetzt bis ins letzte Detail durchdacht zu haben, ist das, was Du möchtest, mit Einschränkungen realisierbar: Du musst Deine SMTP-Domain Deinem O365-Tenant zuordnen. Das bedeutet natürlich nicht, dass der MX dorthin zeigen muss. Den Proof of Ownership kannst Du auch mit einem TXT-Record erbringen. Du wirst die User nicht per AAD Connect synchronisieren können, bis irgendeine Art Hybrid besteht, denn bei einem synchronisierten User müssen die Exchange-Attribute aus dem on-prem-AD kommen. Die User können also zwar ihren UPN gleich der eMail-Adresse haben, das Kennwort verwalten sie dann aber unabhängig vom AD. Mail-Versand (Einladungen usw.) an die User Deines Unternehmens kann über einen Partner-Connector realisiert werden. Im Unterschied zum Centralized Mail Transport (für den in der Tat Exchange erforderlich ist) ist der Partner Connector vergleichsweise dumm. Das Stichwort dafür ist "Condition Based Routing". Darauf basiert auch der Ansatz mit GMail im Link von @testperson. Was nicht funktionieren wird: Anzeige der User-Kalender in Teams (Teams-Termine werden angezeigt, echte Termine vom lokalen Mailsystem nicht) --> das wird der Punkt sein, bei dem die User irgendwann auf die Barrikaden gehen. Out-of-the-Box: Verarbeitung der Terminbestätigungen (Teams versendet Einladung, Antworten kommen ins Mail-Postfach). Falls es Deinem Mailsystem möglich ist, Antworten auf Einladungen separat zu routen, kannst Du das heilen, indem Du sie nach EXO routest.

Genau. Was Du gelesen hast, waren Hyper-V *Cluster*, die unter 2008R2 und teilweise unter 2012 nicht ohne AD hochgefahren sind. Das ist schon lange Geschichte.