testperson

Das ist mir neu, dass es in der Outlook App für iOS / Android mittlerweile geht. Die Outlook für iOS App machte in der "vor MS" Zeit den Push nur über fremde 3rd Party Server. Das tut sie glaube ich immer noch, nur dass die 3rd Party Server jetzt aufgekauft sind: https://docs.microsoft.com/de-de/office365/enterprise/urls-and-ip-address-ranges#microsoft-365-common-and-office-online (Ab Punkt 95) Es war anscheinend nicht nur "Push": https://www.heise.de/mac-and-i/meldung/Microsofts-Outlook-App-schleust-E-Mails-ueber-Fremd-Server-2533240.html

Hi, ich habe die Erfahrung gemacht, dass nur # Server 2016 Remove-WindowsFeature Windows-Defender-Features # Server 2019 Remove-WindowsFeature Windows-Defender den Defender verlässlich ausschaltet. Sobald eine andere AV Lösung installiert ist, würde ich definitiv den Defender entfernen. Gruß Jan

Kann man so machen. Evtl. wäre eine E-Mail-Verschlüsselung hier eine Alternative. Ggfs. auch der Austausch solcher Daten über ein anderes Medium wie E-Mail. Ja, korrekt.

Freigegebene Postfächer sollten sich mit einem alternativen Client einbinden lassen. Z.B.: https://www.isec7.com/deutsch/isec7-solutions/isec7-mobile-exchange-delegate/ Ansonsten eben zwei "normale" Postfächer für die User. Warum muss es denn eigentlich eine "sensible" und eine "unsensible" E-Mail-Adresse geben?

Hi, hier geht es vermutlich wieder um die "Migration" zu Exchange Online? Freigegebene Postfächer sind "normale" Postfächer bei denen lediglich der Benutzer dahinter deaktiviert ist. Solange diese "sensiblen" Postfächer nicht auf mobile Endgeräte syncen müssen, kannst du die dafür verwenden. Zugriff hat nur der jenige / die jenigen, die Berechtigt werden. Beim "normalen" Postfach kann halt auch noch der drauf zugreifen, der das Passwort kennt. Das ist, war und bleibt Mist. Theoretisch könntest du eine Subdomain beim Anbieter einrichten und dort die "sensiblen" E-Mails (geheim@sub.domain.de) betreiben. Ich frage mich aber warum man "sensibles" mit aller Gewalt beim Provider / WebHoster betreibt, wo vermutlich schon das Backup nicht vorhanden ist. Gruß Jan

Dann solltest du doch alles relevante im SMTP Log vom SmartHost finden.

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