silviov

Sorry, Formulierung Ob die Dienste auch bei dem Upgrade auf CU10, nach der .Net uminstallation, beendet werden sollten. Dienste Beenden - vielleicht weil das Vorgehen nicht supportet ist, so zur Vorsicht oder evtl Fehlermeldungen? - schrieb auch testperson - also das mit dem Dienste deaktivieren. Ich Danke Dir für die Unterstützung, hat alles bestens funktioniert.

Vielen Dank für eure Unterstützungen. Das werde ich dann in einer Testumgebung mal durchgehen. Nichts geht über noch mehr Erfahrung @Nobbyaushb Ich gehe mal davon aus ".NET 4.7.2 deinstalliern und blocken, dann direkt VS drauf, das .NET 4.7.1 neu installieren und direkt auf CU10 gehen." -> mit beendeten Exchange Diensten? Und wenn ja, nur bei .Net uminstallation oder auch bei nachträglichen CU10 Installation?

Hallo zusammen, wir haben einen Exchange Server 2016 CU5 Standalone (keine DAG/HA) auf einen installierten Windows Server 2012 R2 übernommen. Nur habe ich dann direkt festgestellt, das .Net 4.7.2 vor einem Monat ca. mit den Windows Updates installiert wurde. Ich würde natürlich jetzt auf CU10 mit .Net 4.7.1 updaten und dann 4.7.2 blockieren. Nun meine Frage - kann ich hier .Net 4.7.2 deinstallieren zurück auf .Net 4.6.2 (inkl alles Server neu Starts) ? Nur da 4.7.2 schon einen Monat her ist, bin ich mir nicht sicher, ob das Schwierigkeiten geben könnte? Danach würde ich natürlich das Update auf CU9 durchführen -> dann Update .Net auf .Net 4.7.1 und VS 2013 -> und zu guter letzt Update auf CU10. Oder habt Ihr einen Vorschlag für einen besseren Fahrplan Danke und VG Silvio

Es gibt so einige Mails in den Postfächern, die eine größe von über 25 MB haben (nötige Bilddaten in Bezug zu den Infos in den Mails) und die erst alle raus zu filtern wird ein deutlicher Mehraufwand - also Filtern für einen Export in eine Archiv PST Datei. Und letztlich bedeutet das auch, ich bekomme die Daten nich in den O365 Postfächern - nicht mal über einen PST Import. Klar ich kann jetzt für alle betroffene Postfächer lokale Archive erstellen, aber sexy ist anders. Danke euch für die Infos.

Nabend Nobby, danke Dir - auf die Liste war ich auch schon gestoßen. Angegeben in der List Message size limit - migration 150 MB 4 Mit Hinweis des folgenden Textes 4 The size of messages to be moved into Exchange Online are computed by Exchange Online. Versions of Exchange prior to Exchange Server 2013 may report a smaller item size. This limit applies to move based migrations using any supported Exchange Mailbox Replication Service. Other migration methods (Cutover, Staged, IMAP, PST) and other third party tools are limited by the general message size limit. Bedeutet "general Message Size" 25 MB bzw 35 MB ? Da blicke ich gerade nicht ganz durch und war auch der Anlass für meine Frage.

Hallo nochmals zusammen, werden bei einer Cutover Migration zu Office 365, Mails ab einer Größe von 25 MB bei der Migration ausgelassen? Ich habe viel Infos finden können und die Grenzen sind wohl für Nachrichtengrößen auf 150 MB ab 2015 angehoben worden, aber ich finde nichts konkretes, ob das auch bei einer Cutover Migration gilt. Hat da jemand vielleicht nähere Infos für mich? Vielen lieben Dank und schöne Grüße Silvio

SplitDNS funktioniert - das passt. Ich dachte bei Exchange 2010 auf dem SBS 2011 benötigt zu den Adressen Autodiscover.domain.de Mail.domain.de im Zertifikat die Adresse exchange.firma.local (FQDN des Exchange) Also bekommen die bestehenden eingerichteten Outlook Clients nach dem Zertifikatstausch mit nur den beiden oberen DNS Adressen und funktionierenden SplitDNS keine Verbindungsprobleme!? Richtig? Weil RPC Verbindung im Outlook zu Exchange 2010 kein SSL über Port 443 benutzt - braucht also kein Zertifikat!? Sorry meine blöde Frage - hab nur schon lange kein SBS ablösen müssen und da steht und fällt ja sehr viel mit einem falschen Zertifikat. Gruß Silvio

Hey Norbert. Danke Dir für die schnelle Info. Das Thema Cutover Migration hatte ich zuerst auf dem Plan. Für die Cutover Migration benötige ich laut MS ein offizielles Zertifikat und kein selbst signiertes - nur bekomme ich kein UCC Zertifikat mehr mit der Angabe des internen FQDN des Servers, zusätzlich der externen Subdomain inkl Autodiscover. In den Verzeichnissen des Exchange ist die Externe Adresse hinterlegt (für Extern und Intern) und Split DNS in Benutzung - nur der FQDN als Server Adresse ist hinterlegt und Outlook zeigt bei dem Verbindungstest den internen FQDN als verbundenen Server an. Ich müsste die Outlook Profile der Clients anpassen und da ich mir nicht sicher war und auch nicht testen konnte, ob das ohne Probleme funktioniert, war ich der Annahme, bei den wenigen Konten, wäre das der sicherste Weg. Und eine Kleinigkeit hatte ich noch, bei der Cutover Migration werden E-Mail Anhänge größer 25 MB aussortiert, bzw es kommt zu Fehlern bei der Migration und das ist leider hier der Fall - MS hat wohl vor 2 Jahren die Größen angehoben, nur leider wohl nicht für die Cutover Migration via MAPI- oder bin ich da Falsch informiert? Möchte ich nicht ausschließen! Bye Silvio

Hallo zusammen, wir planen eine manuelle Migration von einem SBS 2011 Exchange 2010 nach Office 365. Da es nur 20 Postfächer sind und diese auch recht schmal, würden wir das via PST Transport (Export/Import) lösen. Der MX, Autodiscover etc. wird direkt beim Provider angepasst (neue Mails sollen direkt nach Office 365) und an den Outlook Clients soll das neue Profil schon erstellen werden. Damit sich die Outlook Clients mit einem neuen Profil mit dem Office 365 Accounts verbinden können, setze ich am Exchange 2010 den Befehl: "Set-ClientAccessServer AutodiscoverInternalConnectionURI to Null." Und nun die Frage, da ich die Clients ja nach und nach abarbeite, weiß jemand ob bestehende Outlook Profile weiter funktionieren? Outlook Profil 1 - lokaler Exchange Outlook Profil 2 - Office 365 Wäre das theoretisch Möglich oder bekomme ich nach dem Absetzen des Befehls keine Verbindung mehr zu dem lokalen Server?! VG und vielen Dank

So nach weiteren Stunden der Lösungssuche, habe ich das Problem im Griff bekommen. Kleine Ursache, Große Wirkung! Ich habe ja geschrieben, das ich in einer Testumgebung arbeite und damit auch keine Internetverbindung habe. Am DHCP Server war natürlich noch die Gateway Adresse des Routers der vorherigen SBS 2011 Umgebung eingetragen. Nur das der Router in der Testumgebung gar nicht existiert und die Gateway Adresse gar nicht erreichbar ist. Und genau das ist wohl das Problem. Wenn das Gateway am Client leer ist, kenne ich den Fehler, dass Outlook mit der Meldung aussteigt "kein Gateway an der Netzwerkkarte eingetragen" - aber das war mir neu. Gut normal habe ich in einer Testumgebung ja auch Internet geschaltet bzw eine funktionierendes Gateway. Hier musste ich nur sicher gehen, das die Anlage nicht Online geht! Kurzer Hand habe ich die Gateway Adresse auf die IP des AD Server eingestellt, habe natürlich immer noch kein Internet, aber jetzt läuft Outlook sauber durch und bekomme die Fehlermeldung nicht mehr. Danke für eure Unterstützung und Hilfestellungen. Viele Grüße Silvio

Mapi over Http habe ich nochmals komplett auseinander genommen, aber Outlook möchte einfach nicht. Ich verstehe langsam die Welt nicht mehr. Adressen stimmen, alle sind erreichbar, das Zertifikat passt (keine Fehler), Mapi deaktiviert und dann wieder aktiviert, aber mit Outlook bekomme ich immer die gleiche Fehler Meldung. Die einzige Auffälligkeit ist noch das im Ordner "C:\Program Files\Microsoft\Exchange Server\V15\Logging" der Ordner "Mapi over Http" nicht vorhanden ist - da hätte ich jedoch nur als Erklärung, das evtl ja noch kein Outlook richtig verbunden war und somit noch kein Log geschrieben wurde. Kann das so sein? Oder müsste der Ordner auf jeden Fall da sein - jedoch alle Mapi Tests (via Webseite mapi/healthcheck.htm und Powershell) sind ohne Fehler?!?

Hi Nooby ob die Funktion aktiviert ist? Ja ist sie, habe das mehrfach geprüft und auch schon deaktiviert und dann wieder aktiviert. Status sagt im Moment "True". Oder meintest Du etwas anderes? Hi TC Ja wie Nobby schon sagte, das geht nicht mehr mit OL2016.

Hallo zusammen! Ich hoffe Ihr könnt mir weiter helfen, da ich den Wald anscheint nicht mehr vor lauter Bäumen sehe. Ich führe gerade eine Test Migration von einem Exchange 2010 (betrieb auf SBS 2011) auf die Version 2016 durch. Die neue Konstellation ist wie folgt 1 Windows Server 2012 R2 für AD etc 1 Windows Server 2012 R2 für Exchange 2016 CU5 Die Installation inkl der Übernahme AD und Exchange lief ohne Komplikationen. Die Exchange Migration auf dem 2016 lief auch ohne Fehlermeldungen. Die Postfächer, OAB. PF konnten komplett migriert werden. Split DNS wurde eingerichtet und der DNS Server (Forward und Reverse) entsprechend konfiguriert. Die Adresse für Split DNS sind "mail.firma.de" (lautet natürlich anders) und dazu "autodiscover.firma.de" Da ich in einer Testumgebung arbeite und der Exchange 2010 vorher mit einem selbst signierten Zertifikat gearbeitet hat, habe ich solange auf dem AD Server einen Zertifikatsserver eingerichtet und dort ein SAN Zertifikat (inkludiert die oben angegebenen Adressen) für den Exchange 2016 eingerichtet. Ich kann mit der Anlage noch nicht Online gehen. (Es folgt dann natürlich noch ein gekauftes Zertifikat) - Für die Testumgebung sollte das funktionieren. Die virtuellen Verzeichnisse sind komplett angepasst und die internen und externen Adressen verweisen auf die Split DNS Adresse. Nun das Problem: Ich habe einen Client unter Windows 10 neu installiert inkl Outlook 2016, nur bekomme ich bei der Einrichtung eines bestehenden Kontos die Meldung Die Aktion kann nicht abgeschlossen werden, es besteht keine Verbindung mit Microsoft Exchange zur Verfügung. Outlook muss im Onlinemodus oder verbunden sein Darauf habe ich noch ein neues Konto erstellt, da ich von einem Fehler bei der Migration aus gegangen bin, ergibt nur leider die gleiche Meldung. Da ich die Testumgebung nicht Online testen kann, kann ich leider die TestConnectivity Webseite von MS nicht benutzen. Das alles habe ich bereits geprüft bzw hier noch ein paar Infos für euch - ich weiss, das ist immer die Nadel im Heuhaufen. - via OWA funktioniert jedes Postfach inkl der PF. - es werden keine Zertifikatsfehler angezeigt (OWA/ECP/Outlook bei der Verbindungseinrichtung - bis auf Schritt 3 mit der Fehlermeldung die ich oben bekomme) - für Exchange 2016 CU5 wurde/musste net.Framework 4.6.2 installiert werden - der Exchange 2010 konnte komplett sauber deinstalliert werden. - Autodiscover habe ich via Outlook Verbindungstest erfolgreich getestet, die Werte sehen alles gut aus und bekomme auch hier keine Fehlermeldung. - Mapi Healthcheck ergibt auch kein Fehler - 200 OK und die Adresse stimmt. - Get-MapiVirtualDirectory gibt die richtige Adresse aus "mail.firma.de" bei Internal und ExternalURL - also auch hier kein Schreibfehler - DNS Auflösung Intern, arbeitet korrekt, Adressen können alle aufgelöst werden mail. und autodiscover. - Test-OutlookConnectivitiy gibt bei dem Ergebnis auch "Succeeded" aus. - MAPIoverHTTP ist aktiviert. Habe ich mit Get-OrganizationConfig getestet. - Proxy Adresse für die Internet Verbindung sind bzw wurden via GPO nicht verteilt. Nun bin ich etwas Ratlos und hoffe Ihr habt noch einen Tip oder Anhaltspunkte für mich. Ich habe schon so einige Migration (vorrangig bei KMU's) hinter mir, nur finde ich hier die Lösung des Problems nicht. Vielen Dank schon mal für eure Mühen. Viele Grüße Silvio

Hallo zusammen, ich habe die folgende Situation und bräuchte dazu einen kleinen Rat. Ich hoffe Ihr könnt mir helfen. Habe eine Domäne mit 2 Controllern. DC1 Windows 2003 R2 Server, DCDiag alles gut, Sysvol Ordner + NetShare inkl Inhalt alles gut, DNS alles in Ordnung - ABER mit ID 13508 DC2 Windows 2008 R2 Server, DCDiag alles gut, Sysvol Ordner + NetShare inkl dem Inhalt alles gut, DNS alles in Ordnung, hier liegen die FSMOs - ABER mit ID 13568 Aufgefallen ist das Problem als ich auf DC2 ein Script geändert habe, das nicht auf DC1 repliziert wurde und festgestellt habe das die Scripte weiterhin von DC1 benutzt werden. DC1 sollte aufgrund des Alters nun dauerhaft Offline gehen und sollte/möchte das Problem natürlich vorher aus der Welt schaffen, bevor ich noch Probleme mit der Domäne bekomme. Die bis auf dieses Problem eigentlich sehr sauber gearbeitet hat. Der Replikationsfehler ist anscheint seid ca 3 Monaten vorhanden. Nun zur angehenden Problem Lösung: Ich würde nun auf dem DC1 mit der ID 13508 den Burflag auf D4 setzen, da dieser ja die richtigen/ bzw aktuelleren Inhalte des Sysvol Ordner trägt. Und auf DC2 setze ich den Burflag auf D2. Die Frage ist in welchem Key trage ich das ein: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\GUID\ oder HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup Wo liegt der Unterschied? Wäre das der Richtige Weg?! Vielen Dank und schönen Gruß Silvio

Danke Robert, werde ich direkt testen und so weiter geben. Tja das ganze via Outlook Anywhere wäre mir lieber gewesen, aber der gute will ja nicht. Dann muss er halt den Link immer wieder aufrufen. Wird schon gehen. Danke für die prompte Antwort.