testperson

Das kommt drauf an wie und von wo / was du "migrierst": https://docs.microsoft.com/en-us/exchange/mailbox-migration/mailbox-migration Ja. Was soll denn sonst passieren? Und nein, ein Catch-All ist mist! https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/remote-domains/remote-domains P.S.: Es gibt nichts, was ähnlich gut bei MS dokumentiert ist. Evtl. schaust du dort einfach mal vorbei und prüfst dein Vorhaben.

An dieser Stelle würde ich dir nochmal einen Reverse Proxy ans Herz legen. Da kannst du, vermutlich, deinen IIS und das RDGateway / RDWeb beides über Port 443 tcp veröffentlichen und musst nicht mit sowas rumwerkeln. Des Weiteren wird es genug Netzwerke geben, wo du über 4430 tcp nicht raus kommst.

Hyper-V bzw. eine Virtualisierungslösung wäre wohl ein guter Ansatz gewesen. Da müsste AFAIK alles übereinstimmen. Dan müsste dein DC allerdings auf "ping autodiscover.<domain>.<tld> antworten und die URLs wären nicht auf <wasauchimmer>.local konfiguriert. Jein. Macht einem das Leben aber in vielen Punkten leichter. Ist das erste Outlook, wo zwingend Autodiscover funktionieren muss. ;)

SCNR Passt ja dann, da der Dienstleister auch nicht wirklich weiß was er da tut. :P

Nein. Die A-Records sowohl im Provider DNS wie auch im lokalen DNS sind korrekt. (Theoretisch hätten auch CNames für Autodiscover genügt bzw. führen viele Wege zum Autodiscover.) Macht ja nichts. ;) Vermutlich hast du das schon. ;) Zertifikat ändern dürfte einfacher sein und schneller gehen sowie die sauberste Lösung sein. Alternativ wäre SNI ein Stichwort, Eine weitere Möglichkeit wäre sich Autodiscover im Detail anzusehen und zu verstehen. ;)

Kann denn da etwas internes oder was externes nicht erreicht werden? https://domain.local ist das da ganz sicher so konfiguriert oder fehlt da noch der Host vor der Domain? Dann wäre der Exchange ja Domain Controller. Ansonsten sieht das aber so aus, als hättest du das falsche Whitepaper gelesen. Welches denn überhaupt? Kurz: Konfiguriere SplitDNS, passe die URLs der virtuellen Verzeichnisse an und kaufe ein vertrauenswürdiges Zertifikat.

Hi, die bleiben so wie sie sind. Autodiscover sollte auch auf mailhost.<Domain>.<tld> zeigen. Das passt dann. Wenn kein Konto die zweite Domain als primäre SMTP Adresse hat, dann kannst du dir das o.g. auch sparen. ;) Generell solltest du, falls noch nicht geschehen, in "domain.msc" die beiden Domains als UPN Suffix hinterlegen und die UPNs der User entsprechend der primären SMTP Adresse setzen. Gruß Jan

Hi, was passiert denn bei einem "ping autodiscover.<primäre SMTP Domain(s)>.<tld>"? Lässt sich am Client "https://autodiscover.<primäre SMTP Domain(s)>.<tld>" ohne Fehler aufrufen? Wie sind die internen / externen URLs konfiguriert und wie sieht die "AutodiscoverServiceInternalUri" (Get-ClientAccessService | select-object AutodiscoverServiceInternalUri) aus? Gruß Jan P.S.: Und wie immer: POPConnector entsorgen und es richtig machen auch wenn es nie Probleme gab und alles total super läuft. ;)

Ich zitiere an dieser Stelle mal die Hersteller-Beschreibung der Kontenoperatoren (https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc756898(v=ws.10)):

Das ist normal. Nimm in den Weiterleitungen des Windows DNS mal den Router raus und führe den Test erneut durch. Dann solltest du dort auch die DNS-Root-Server finden. An der Stelle würde ich, wie Norbert schon anmerkte, einen neuen Exchange aufsetzen. Damit würdest du auch das ungünstige Konstrukt Exchange auf DC ablösen. (Wäre der Exchange jetzt kein DC könntest du das ganze vermutlich auch zügig mittels RecoverServer lösen. Naja, wäre, wäre Fahradkette... ;))

Hi, eine Option wäre wohl ein Ticket bei MS. Schneller dürfte es gehen einen neuen Exchange aufzusetzen und alles auf den neuen Server zu schieben. Alternativ eben noch: https://docs.microsoft.com/en-us/exchange/high-availability/disaster-recovery/recover-exchange-servers?view=exchserver-2019 Das Anpassen der clientspezifischen Nachrichtengrößen beschreibt MS zumindest entweder im IIS oder Notepad: https://docs.microsoft.com/en-us/exchange/architecture/client-access/client-message-size-limits?view=exchserver-2019 Gruß Jan

Hi, da würde sich ggfs. Let's Encrypt anbieten. Die haben auch Wildcard. :P In deinem Fall würde vermutlich ein Zertifikat mit einem passenden Host reichen. Die gibt es bei PSW ab ~30€. Des Weiteren müsstest du den RDClientAccessName anpassen: https://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80 Ansonsten wäre natürlich auch noch ein Citrix ADC Freemium / Free Loadmaster von Kemp / HA Proxy / ein sonstiger Reverse Proxy eine Option. Gruß Jan

Windows Server Backup und eine bis eine handvoll USB Platten / etwas Speicher auf einem NAS?

Dann würde ich mal fragen, wie der Rest des Backup- (bzw. Restore-) Konzeptes aussieht. Oder wäre das potenzielle Backup zu OneDrive das einzige Backup?

Hi, muss das Sicherungsziel zwingend OneDrive sein? Ansonsten https://azure.microsoft.com/de-de/services/backup/ Gruß Jan

Schau mal bei der PSW Group. Z.B.: https://www.psw-group.de/ssl-zertifikate/detail/c166-certum-commercial-ssl-multidomain/ Ansonsten kann man sich auch mit Let's Encrypt befassen. Da kostet es "nur" die Zeit bis es läuft. ;)

Hi, solange *.local im Zertifikat ist, wird Autodiscover bzw. die Einrichtung von OA / EAS eher nicht problemlos funktionieren. Aus der ferne würde ich sagen, erwebe ein Zertifikat einer trusted CA und richte Split-DNS korrekt ein. Dann benötigst du nur "mail.mutterfirma.de", "autodiscover.mutterfirma.de" und "autodiscover.tochterfirma.de" im Zertifikat. Zusätzlich würde ich den UPN der User identisch zu deren primären SMTP Adresse setzen. Gruß Jan

Hi, das solltest du wohl mit den Anbietern klären. Das wird dir niemand sonst beantworten können. Generell würde ich die Finger davon lassen. Wenn ein Kunde solche Lizenzen kaufen möchte, dann soll er das tun. Im Zweifelsfall ist der Kunde eh für seine korrekte Lizenzierung verantwortlich. Gruß Jan

Ja, das sollten sie. Du solltest mal ins Eventlog (Verzeichnisdienst / Dateireplikationsdienst / DFS-Replikation) schauen.

So fangen häufig Dinge an, die am Ende dann mehr Geld kosten / gekostet haben wie mit externen Hilfe. Manchmal muss man "einfach nur" miteinander reden und darstellen, dass es mehr Zeit und/oder externe Unterstützung braucht, da man nicht (guten Gewissens) weiterkommt oder damit "überfordert" ist.

Das hängt primär von den Absendern bzw. deren DNS ab. Das könnte man beeinflussen / beschleunigen indem man vorab die TTL der eigenen MX Records aufs Minimum runtersetzt. Das kommt auf den Provider an. In der Regel sollten die aber erreichbar bleiben.

Wo liegt denn der DNS der Domain, die du bei MS hinzufügen möchtest? Man könnte halt auch in die Dokumentationen / FAQs der Anbieter gucken: https://docs.microsoft.com/en-us/office365/admin/get-help-with-domains/create-dns-records-at-any-dns-hosting-provider?view=o365-worldwide https://www.strato.de/faq/office/welche-dns-einstellungen-muss-ich-fuer-office-365-im-strato-kunden-login-vornehmen/

Hi, einfach die DNS Einstellungen vornehmen, die beim hinzufügen / einrichten der Domain im O365 Portal verlangt werden. Hätte man es damals™ schon richtig gemacht, wüsste man jetzt wie so eine E-Mail-Zustellung funktioniert. ;) Gruß Jan

Auf den Systemen wo ich das so machen musste, hat es geklappt.

Hi, was gibt es denn für einen Mailserver? Generell sollte das per SRV Records im DNS gehen. Bei IMAP würde ich allerdings auf einen anderen Client wie Outlook setzen. Gruß Jan