testperson

Wie ist denn überhaupt der Mailflow nach extern? Der Exchange sendet direkt an den ersten Zielserver? Der Exchange sendet an SmartHost unter deiner Kontrolle (Firewall / Mailgateway / ...)? Der Exchange sendet an Provider SmartHost nicht unter deiner Kontrolle?

Es ist immer förderlich, wenn man nicht weiß was man (selber) oder auch der Assistent tut... Autodiscover. Bei dir wird aber vermutlich der noch vorhandene lokale Exchange bzw. der SCP im AD / die noch vorhandenen Exchange Attribute deiner User "stören". Normalerweise sollten solche Fragen geklärt werden / gestellt werden bevor man anfängt...

Nein. Du hast doch jetzt scheinbar alles entsprechend eingerichtet. Wie wäre es einfach mit dem ein und anderen Test?

Also wenn du es schon für "Fragwürdig" hälst, solltest du evtl. nochmals mit dem Entscheider sprechen und deien Bedenken äußern. Evtl. kann man von Außen noch etwas unterstützen, wenn du den eigentlich Plan bzw. die Anforderung etwas genauer beschreibst. (Und nicht das Problem.)

Hi, an welcher Stelle brauchst du die SIDs? Spontan: # Als angemeldeter User whoami /user /FO List # Aus dem AD Get-ADUser Test.User | Select-Object SID Da es scheinbar um Profile und deren Migration geht: https://helgeklein.com/blog/2010/08/free-script-user-profile-domain-migration-with-setacl/ bzw. halt SetACL: https://helgeklein.com/setacl/feature-set/ Gruß Jan

Vielen Dank für die Rückmeldung und schön das es läuft. Das müsste man sich vermutlich nur mal konkret ansehen. Viele Wege führen zu passenden Programmeinstellungen. ;) Das "Hauptproblem" bei Roaming Profiles ist häufig, dass die Benutzer Ihre PCs eigentlich selten bis nie wechseln und somit sind die RPs halt überflüssig. Sollte bei euch täglich / öfters der PC gewechselt werden, würde ich mir die "Programmeinstellungen" ansehen. RPs sind halt immer eine potenzielle Fehler- / Problemquelle.

Hi, wenn der MX Record passt und Mails ankommen dann kann Exchange Online "automagisch" auch Mails versenden. I.d.R. sendet der Sendekonnektor an einen SmartHost, den man selber unter Kontrolle hat, welcher die Mails dann an den Zielserver bzw. den nächsten Server zustellt ggfs. stellt auch der Exchange die Mails direkt (an den nächsten Server) zu. Gruß Jan

Hi, AFAIK musst du nur den Pfad ab "AppData\Roaming" angeben. Leider ist die Hilfe da auch nicht so konkret (https://gpsearch.azurewebsites.net/#2573)... In deinem Fall also nur "Test;Ordner1;Ordner2;Ordner3". Generell wäre die Frage, ob Ihr übehaupt Roaming Profiles braucht. I.d.R. braucht man die halt nicht. ;) Gruß Jan

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