cj_berlin

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.

Moin, ich würde unter "C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines Cache" schauen und da evtl. die überschüssigen Einträge löschen.

Moin, vielleicht fängst Du damit an, Deine Anforderungen zu formulieren, statt Lösungsansätze zu beschreiben, ohne sie gegenüber stellen zu können. Denn in der IT gibt es selten ein absolutes "besser" oder "schlechter", sondern der Vergleich ist immer auf die Erfüllung von Anforderungen bezogen. Und eine der Anforderungen sollte stets sein "Know-how zur gewählten Lösung muss bei mehr als einer Person vorhanden sein". Die anderen Personen dürfen gerne Externe sein, aber es muss sie geben. Fällst Du nämlich aus, dann fehlt im Zweifel nicht nur das Wissen, um das System zu reparieren, sondern auch, um Hilfe qualifiziert zu suchen...

...und GPOs komplett nur per PowerShell verwalten? Für das Maß an Change & Adoption-Beratung, das da nötig wäre, sind Quest-Lizenzen mehrfach drin

Auf welchen Namen der PTR-Eintrag lautet, ist völlig unerheblich. Wichtig ist, dass zu diesem Namen auch ein A-Eintrag existiert, der sich zurück auf die gleiche IP-Adresse auflöst.

Wenn der Admin nicht vertrauenswürdig ist, hat die Organisation eh verloren. Wenn Du einen berechtigten Verdacht hast, muss die Geschäftsführung sich darum kümmern.

Moin, das, woran Du meinst Dich zu erinnern, ist Backpressure: https://docs.microsoft.com/en-us/Exchange/mail-flow/back-pressure?view=exchserver-2019 Da muss man immer schauen, welche Festplatten gemeint sind, denn die Transport-Queue liegt ja hoffentlich woanders als die DB und auch woanders als das Betriebssystem. Aber vielleicht nicht. Was sagt denn der Component State in dem Zustand, den Du mit dem Neustart des Transports vorübergehend heilst?

Der letzte Post von @mwiederkehr erklärt, was Du zu tun hast, wenn Du es selbst hacken möchtest.

Das würde das Problem zwar heilen, beantwortet die ursprüngliche Frage aber nicht. Daher, der Vollständigkeit halber (ich schreibe überall "Du", es sollte aber klar sein, dass der jeweilige Administrator gemeint ist - wenn "Du" nur End-User in der Umgebung bist, bist Du hier machtlos): Mailversand kannst Du in den Message Tracking Logs des Exchange verfolgen Anmeldung kannst Du (nachdem Auditing aktiviert wurde) in den Security Logs des DC verfolgen, damit weißt Du Zeitpunkt und IP-Adresse des Terminalservers. Wenn da stattdessen die Adresse des Exchange Servers als Quelle steht, wurde nicht eine Anmeldung am Terminalserver, sondern OWA, EWS oder ActiveSync verwendet. Wenn tatsächlich fest steht, dass Diejenige sich mit Deinem Account am Terminalserver angemeldet hat, kannst Du im TerminalServer-Log herausfinden, von welcher IP-Adresse die Verbindung kam. Wenn Du Pech hast, steht da der RemoteDesktop-Gateway, dann war die Verbindung vielleicht extern, und die Logs des RDG liefern Dir eine dynamische Adresse bei Vodafone. Mit dieser kannst Du dann zur Polizei gehen. Also: Lieber einfach das Kennwort ändern. Und nicht vergessen, den Post-It-Zettel auf der Unterseite der Tastatur zu aktualisieren!

Du fügst die verwalteten GPOs doch explizit hinzu. Das wären dann unterschiedliche Sätze. Aber klar, grundsätzlich ist das Produkt für eure Anforderungen nicht gut geeignet. Wenn Geld da ist, würde ich Richtung Quest schielen...