gelöscht

"Maximum Allowed Sessions Per User" geht auch für Exchange 2016. Beantwortet aber nicht die Frage warum für einen User so viele Sessions offen sind. Evtl. den TCP session timeout nicht angepasst? ASR

Hallo, wie möchtest Du denn migrieren? Cutover, Hybrid? ASR

Ja, jeder Server hat seine eigenen Logs. Was möchtest Du zu welchem Zweck sammeln? ASR

Hallo, ja, warum sollte das etwas Ändern wenn Du das Hybrid Setup abbaust? Das hat auf den oben beschriebenen Ablauf keinen Einfluss. Du kannst aber, wenn alle Mailboxen in Exchange Online sind, die internalautodiscoveruri auf "$Null" stellen, dann macht Outlook direkt einen DNS Autodiscover. ASR

BTW: ein Bekannter hat eine 2010->2016 Migration mit 11000Mailboxen an einem Tag gemacht, vorher alle mit SuspendWhenReadyToComplete nach 2016 synchronisiert, dann in wenigen Stunden alle umgestellt. ASR PS: ich würde den Fehler hier eher auf 2010 vermuten

Get-Transportrule <name> | fl > C:\temp\rule.txt ASR

auf dem DC1, welche Provider hast Du unter IIS > owa vDir > authentication > Windows Authentication > Providers ASR PS: ist der DC1 wirklich ein DC?

Was hast Du für ein TCP/IP Keep Alive Timeout auf dem Exchange Server? ASR

Richtig, wenn Du es deaktivierst geht es nicht mehr. Mach bei denen, bei denen es nicht klappt einen Autodiscover Test und schau ob das Postfach dort mit auftaucht. Wenn ja mach von dem Client, bei dem es nicht geht einen Autodiscover Test mit der Mail-Adresse der Shared Mailbox und schau Dir das an. ASR

Nein, wenn die Mailbox voll ist passt nichts mehr rein, egal ob per PST Import oder sonst wie. ASR

Das ist "normal" dass der on-Premises Server zuerst angefragt wird, nur der hat ja einen SCP in deinem lokalen AD. Wenn Du die Mailboxen aber richtig per MRS nach Exchange Online verschoben hast, hat Dein AD User Objekt jetzt aber eine Target SMTP Adresse in Office 365. Dahin wird der Autodiscover Request weitergeleitet. Ist das der Fall wenn Du den User im AD anschaust? ASR

Mach doch mal einen Dump per Shell von Deiner Transport Regel und poste den hier. ASR

Siehts Du den 500 Code auch im OWA Proxy log? Nur OWA betroffen oder auch /ECP? Proxy log findest Du hier: "C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Owa" Direkt auf den 2010er per OWA geht nehme ich an? ASR

Im Application Log ein/mehrere 9646 event? ASR

Nein, das Log wird fast in Real-Time geschrieben. Woher sollen wir wissen wie auf Deinem Server Logging Pfad konfiguriert ist? Get-TransportService hilft. ASR

Woran lag es denn dann? Ich habe schon Umgebungen gesehen bei denen 250Leute über eine 1Mbit MPLS Leitung problemlos gearbeitet haben. ASR

Vergessen die leg DNs in X.500 Adressen zu übernehmen? ASR

Inwiefern "den Exchange dann zuvor nochmal ganz umstellen"? Willst Du jetzt ein Hybrid oder nicht? Ist Situation: -Mailboxen in Exchange -Mailboxen beim Provider die über POP3 geleert warden -Mailrouting über Provider Zielsituation -Mailboxen in Office 365 Weg zum Ziel -Hybrid kofigurieren mit Centralized Mailflow über Office 365 (rein und raus) -MX Records auf Office 365 umstellen -Mailboxen verschieben von Exchange nach Office 365 -ggf. Hybrid zurückbauen ASR

Wenn er die Mails per SMTP zustimmt sollten die korrekt nach Exchange Online groutet werden. Aber warum stellst Du nicht einfach das eingehende Mailrouting auf O365 um wenn Du schon ein Hybrid bauen möchtest? Dann kannst Du den POP-Connector dorthin befördern wo er hingehört. ASR

Outlook unbedingt aktuell patchen. ASR

Nobbyaushb​ hat Recht: .Net auf 4.6.2 aktualisieren und anschließend das aktulle CU installieren ist der richtige Weg. Nicht nach alten CUs kramen und diese installieren. Zwar gibt es bekannte Probleme mit CU11 und .Net 4.6.2, aber wenn direkt danach ein CU Update erfolgt ist das kein Problem. ASR

Ich würde den mir vermerkten Link nochmal anschauen. Diese Situation kann an sich nur entstehen wenn das vDir aus der AD Configuration Partition gelöscht wurde oder aus einem anderen Grund nicht für Exchange lesbar ist. Da Du ja ohnehin auf eine supportete Exchange Version oder Exchange Online gehst, lohnt es sich eher nicht das im Detail zu analysieren. ASR

Hm, kannst Du das vDir im IIS löschen?

https://technet.microsoft.com/en-us/library/jj898581(v=exchg.150).aspx ASR

Nein, der Autodiscover AppPool hat einen Cache von 60min. In der Zeit kann noch der "alte" URL an den Client gehen. ASR