RobertWi

Für OWA, ECP, etc. ist im Server (durch den Assistenten) remote.also-test.de eingetragen. Also, weiteren CNAME, damit das funktioniert

Ja.

und das Zertifikat vom Server exportieren und am Client importieren, richtig?

Diese Lösuing ist unspported und sollte nur für das Testen benutzt werden

Welches "Replikationstool"?

Nein, diese Änderung sind eh wirkungslos, weil die Exchange gar nicht auswertet.

Wenn Deine IT die Adresse so ändert, geht Autodiscover von alleine.

Und Outlook Anywhere dürfte dann auch nicht gehen, dass muss wie auch die URLS für OAB und EWS noch angepasst werden. Und dann sollten noch die URLs von OWA, ECP und EAS korrigiert werden, die braucht aber Outlook nicht.

Allerdings wirst Du dann wahrscheinlich Zertifikatsfehler haben....

Das ganze ist zu kompliziert, um es in einem Forum zu erklären, da es immer mehrere Lösungen gibt.

Du kannst DNS anpassen (in gewissen Grenzen) und musst Exchange anpassen.

Wie Norbert schreibt: Technisch ist eine feste Adresse nicht erforderlich.

Moin,

ich habe jetzt drei Testmails gesendet (von meinem Exchange, GMX und outlook.com).

Dabei musste ich feststellen, dass da ja noch ein POP-Connector zwischen hängt. Diese Info wäre schon eingangs wichtig gewesen, denn sie ändert so ziemlich alles.

Mal abgesehen davon, dass POP-Connectoren grundsätzlich Müll sind und mehr Probleme schaffen, als sie lösen, erklärt das gleichzeitig auch das beobachte Verhalten.

Wenn einen POP-Connector einsetzen willst, musst Du die einzelnen E-Mail-Adresse bei Deinem Provider pflegen und jedes einzelne Postfach 1:1 abholen. Auch die Filterung muss beim Provider passieren. Beim Exchange darfst Du dann keine Filterung mehr vornehmen und vorallem nichts mehr ablehnen, da Du sonst wegen NDR-Spam (auch Backscatter genannt) Deinen Provider auf eine Blacklist schieben kannst - was der vermutlich nicht besonders mag.

Die deutliche bessere Alternative wäre es, auf direkte SMTP-Zustellung umzustellen.

Moin,

ja, das würde man mit einem CNAME lösen.

Der von der IT eingerichtet nützt Dir nichts, weil Exchange den nicht nutzt. Du musst jetzt noch einen SRV-Eintrag für Autodiscover setzen lassen und die externen URLs auf den verschiedenen virtuellen Verzeichnissen ändern.

Was ich jetzt machen würde:

 - Komplette Wiederherstellung in einer Testumgebung und dann das Postfach ganz normal in Outlook öffnen (zeitaufwendig)

 - Wiederherstellung der gesamten Datenbank mit "Database Mobility" und via OWA nachschauen (Nachteil: Fehlerträchtig, wenn man nicht weiß, was man tut)

 - die Datenbankdatei mit einem Dritt-Anbieter-Tool öffnen (z.B. PowerControls, gab es früher auch mal als Testversion nur zum Nachschauen)

Wenn Du dann die Ordner nicht findest, waren sie nicht im Postfach (oder sind vor der Sicherung gelöscht worden)

Moin,

ich kann mir eigentlich nur noch vorstellen, dass der Anwender die Ordner in einer PST-Datei angelegt hat. Das ist optisch auch "unter" dem Posteingang - einige Zeilen drunter allerdings.

Moin,

ich habe zwar keine Erfahrung mit Multi Tenancy, aber im wesentlichen funktionieren AD und Exchange da nicht anders, als bei "on-premises". Und die Konfig ist da auch sehr ähnlich.

Moin,

natürlich musst Du Senden-Als für alle Konten freigeben, die der Benutzer verwenden soll.

Alls "Send-As"  Änderungen werden gecacht und es kann bis zu 2 Stunden dauern, bis die wirksam werden.

Außerdem sollte ein Outlook-Problem ausgeschlossen werden: Den Vorschlag von Outlook löschen und danach noch mal richtig aus der GAL raussuchen.

Moin,

nur Browser sind in der Lage, eine HTTP oder Header-Weiterleitung auszuwerten. Kein anderer Client (Outlook, EAS, etc.) kann das.

Die IP-Adresse MUSS auf Deinen Host zeigen. as einzige, was geht, ist ein CNAME. Andere Spielereien funktionieren.

Das Zertifikat kommt dann erst danach, zuerst die Namensauflösung richtig machen.

Was wieder mal meine These belegt: Manchmal unterscheidet die Profis von den Erfahrenen nur die bessere Benutzung von Google... :)

Die betreffenden Suchbegriff waren: exchange 2013 multi tenancy - das fehlte Dir wahrscheinlich.

Moin,

da Du sagt "ob" - wäre es nicht einfach, mit der EMS nachzuschauen:

Get-ActiveSyncDevice -Mailbox ALIAS

Das Log braucht man höchsten für "wann", "wie lange", " wir oft", usw.

Moin,

ich meine vorhin einen anderen Fehler gesehen zu haben.

Der jetzige ist:

Keine Verbindung auf https://also-test.de ist möglich. Kann ich nachvollziehen, geht mit meinem Browser nicht. Auch OWA geht darüber nicht.

Und eine "Weiterleitung" (was soll das genau sein?) finde ich im DNS auch nicht. also-test.de zeigt auf den A-Eintrag "62.116.130.8" (InterNetX GmbH). Der MX Eintrag dagegen zeigt wirklich auf einen "no-ip"-Eintrag.

Also ein Problem im DNS oder in der Firewall.

Moin,

da ist scheinbar ein Fehler im DNS. Da Du die Domänen-Namen verschleierst, können wir leider nicht selbst nachschauen.

Moin,

muss wohl an der Suche gelegen haben. Bei mir fand Google bei den ersten vier Treffe die folgenden Links:

http://www.ronnyrenner.ch/?p=1142

http://technet.microsoft.com/en-us/exchange/jj720331.aspx

http://blogs.technet.com/b/exchange/archive/2013/02/20/hosting-and-multi-tenancy-guidance-for-exchange-server-2013-now-available.aspx

Besonders wichtig ist es, den "Exchange Server 2013 Hosting Guidance" zu lesen. Da steht nämlich drin, was NICHT geht, und was man NICHT machen darf.

Und die wichtigste Info: Es gibt KEIN Werkzeug für die Mandanten. Wenn die Selbstverwaltung machen sollen, musst Du da was bauen oder kaufen.

SP 3 kannst Du direkt installiert, nur RU 1 muss getrennt danach erfolgen (Slipstream geht nur bei Neuinstallationen).

Na dann: Transportregel.

Moin,

für die Erzeugung eines NDR ist der sendende Server zuständig. Und hier gibt es IMHO keinen verbindlichen Standard, wobei die meisten die Fehlermeldung des empfangenden Servers schon annehmen, Exchange auch.

Ich denk daher, dass bei Dir alles richtig ist und eher beim Kunden der Fehler zu suchen ist. Wenn Du mir per PN die domäne schickst, kann ich Dir gerne mal eine ungültige Mail schicken und sehen, was passiert.

Aktualisieren ist immer angesagt.

Werden denn andere Ordner bei Restore angelegt oder fehlen alle?

Moin,

Du kannst via Transport-Regel eine BCC-Kopie an einen beliebigen Empfänger schicken - allerdings nicht in einen Ordner in einem Postfach.

Da öffentliche Ordner keine Unterordner "Gesendete Nachrichten" kennen, gehe ich davon aus, dass Du hier einen eigenen ÖO für angelegt hast. In den kannst Du dann auch per BCC senden.

Moin,

1. was Norbert sagt, ist korrekt. Bekannte Adressen werden nicht weitergeleitet, warum auch.

2. es sollte eine "interne Relaydomäne" eingestellt werden, die externe braucht einen Edge Transport Server

Also interne PKI. Wenn die AD-integriert installiert wurde, sollte sich das Stammstellenzertifikat eigentlich von alleine verteilen.

Wenn nicht, dann muss für über die ADCS-Console das Dinge exportieren (ohne privaten Schlüssel) und selbst in eine Gruppenrichtlinie packen. Das kann dann auch die Default Domain Policy sein, soll ja für alle gelten.

Moin

ist das ein echtes "Self-Signed" -> die sind nicht supported. Sie funktionieren zwar, aber das kann sich bei jedem Update ändern.

Wenn das eine interne PKI war, dann muss das Stammstellenzertifikat in die "vertrauenswürdigen Stammzertifizierungsstellen" importiert werden. In einem AD geht das am einfachsten via Gruppenrichtlinie.

EWS hast Du geschrieben, nur nanntest Du es "OOF". OOF kommt seit 2007 über die EWS. ;)

ECP fehlte, das stimmt.