cj_berlin

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.

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.