NorbertFe

Ich weiß nicht, ob ich dir da weiterhelfen kann. Wenn der Server Dc, Nls, da, ca und was weiß ich noch alles ist, sind da soviel Abhängigkeiten, dass ich das freiwillig nie in Erwägung ziehen würde. Wenn da soviel Startkapital sinnlos rumlag, wäre wohl eine vorherige (kostenpflichtige) Beratung sinnvoll erschienen (jedenfalls mir).

Kann ich mir nicht vorstellen, dass das korrekt ist. Ein Ping auf den Namen durch den da Tunnel liefert afaik immer die ipv6 Adresse zurück die der da Server im einfachsten Fall vergibt. Ja wirst du wohl müssen. :) kleine Firma aber alles Enterprise Editionen? Naja wer sein Geld so gezielt ausgibt. ;)

Das wird nicht reichen, weil dort ja die internen Namen dann in die Zertifikate eingetragen werden. Insgesamt würde ich sagen, dass da für so kleine Unternehmen nicht die sinnvollste Lösung darstellt. Schon allein, weil du dafür afaik die Enterprise Edition vom Client os benötigst. Gib mal nen link in dem ein Ping ipv4 durch den Tunnel gezeigt wird.

Evtl. Nutzer ticken da ggf. Anders und niemand liest die eigentliche Fehlermeldung, wenn sie irgendwo im Fließtext nach einer 5.x.x Fehlermeldung steht. Das kann ich sogar noch etwas nachvollziehen. Wahrscheinlich ein Grund, warum o365 so schöne ndrs generiert. ;)

IPv4 kannst du ja auch nicht durch den DA Tunnel pingen. Einige Anwendungen werden auch nicht mit der Rückgabe von ipv6 Adressen klarkommen. DA funktioniert mit Namen und ipv6. Insofern works as designt. DA und DC auf einem Host ist keine gute Idee. Wo läuft denn der NLS? Etwa auch noch mit auf dem selben Server? Deine Revocation List hast du hoffentlich auch gleich öffentlich zugänglich konfiguriert, sonst hast du in ca. 7 Tagen ein Problem mit den DA Clients. Interne und externe Domäne unterscheiden sich namentlich, oder sind die identisch? Bye Norbert

Die Lösung steht oben bereits. Du akzeptierst entweder, dass die Absender nicht willens sind eine eindeutige Fehlermeldung zu lesen oder du vergibst die bisherigen Emailadressen einem armen Tropf der das dann kontrollieren muss. In jedem Fall ist Catch-All die falsche Lösung! Alternativ kannst du natürlich auch mit 3rd Party Tools das ganze etwas "sozialer" gestalten. https://www.exclaimer.de/auto-responder/ (Emailadresse weiterhin existent aber die Mail wird vom Autoresponder entsprechend "schön" beantwortet und danach in die Tonne geworfen). Nein ich lese keine Mails an nicht mehr existierende Mitarbeiter. Bye Norbert

Wahrscheinlich sind inzwischen 10 Geräte auf dem Konto als Partnerschaft eingetragen. Alternativ ist das evtl. ein vom AdminSDHolder geschütztes Konto, dann solltest du überhaupt kein Mobile Device damit verwenden. :) Bye Norbert

Ein Catchall ist aber nicht das, was du willst. Du willst "alte Emailadressen weiterhin verwenden" und nicht "ALLE möglichen Emailadressen annehmen". Das ist ein großer Unterschied. Ein Spamfilter hilft dir nur sehr bedingt in solchen Fällen in Zeiten von Phishing und Spearphishing. Aber jeder ist ja der Meinung ihn betreffe sowas wie https://www.bka.de/SharedDocs/Downloads/DE/IhreSicherheit/CEOFraud.html nicht, bis es ihn irgendwann erwischt. Aus meiner Sicht geht ihr das Thema falsch an, aber jeder wie er mag. Bye Norbert

Naja aber dafür hast du dann ein serverseitiges Archiv, welches entweder nur online verfügbar ist und damit langsam, oder eben andere Cachedateien lokal ablegen wird. ;)

Vielleicht hab ich’s ja überlesen, aber solche Infos gehören an den Anfang und nicht in die Lösung. ;)

Das zuweisen von alten E-Mail-Adressen an andere Postfächer würde ich 1. nur na h Absprache und 2. nur zeitlich befristet regeln (wenn überhaupt). Ich hatte mal einen Kunden, da hat die Chefsekretärin alle E-Mails der ehemaligen Nutzer bekommen. Der Blackberry war nur am vibrieren. ;) ich hab dann irgendwann mal nachgeschaut und da kam nur Müll an. Und der eine wichtige Fall hat dann eben Pech! Wenn ich umziehe und der nachsendeauftrag ist zu Ende kommt auch keine Post mehr an.

Häh loopback? Hast du die Drucker etwa im userteil konfiguriert?

Naja einwandfrei würde ich eine Fehlermeldung nicut nennen :p aber warten wir mal ab.

Warum sollen die spinnen?

Dann würde owa auch einen Fehler bringen. ;)

Na toll, dass du mit solchen Infos irgendwann mal rauskommst. Was ergibt get-clientacccessservice | fl *uri* ?

Welche outlookversion? Welcher Fehler? (Immer intern). Kannst du von außen den exchange Remote connectivity analyzer mal anwerfen?

Ja kann man ändern. Musst du aber allen da Clients dann neue Zertifikate verpassen.

Was? Neue Domäne? Wohl kaum sinnvoll. ;) funktioniert denn owa intern ohne Fehlermeldung?

Warum sollte von außen etwas per Ping antworten? Hast du das denn konfiguriert? Abgesehen davon ist eine gleiche Benennung mitnichten ein „Problem“. :) an deiner Stelle würde ich erstmal intern das Ding zum laufen bringen und danach erst den externen Teil. Wohin zeigt Remote.domain.tld und autodiscover denn intern? Wirst du wohl müssen. ;)

Eine tld hat nichts aber auch gar nichts mit dem Domain und Forest functional level zu tun. Außer, dass „Level“ drin vorkommt. ;)

Wenn nur recover geht, war vorher schon mal ein exchange in der Umgebung? Wieviele und welche versuche hast du bisher gestartet?

Und was steht im eventlog der Clients?

Müssen musst du gar nix.

Sicher nicht, aber wozu, wenns so viel einfacher funktioniert?