Beiträge von filippg

Hallo Robert,

danke für die Antwort - auch wenn ich das "bewusst" in "bewusst unabhängig von einander konzipiert" anzweifel

Schade, dann können wir die Idee eher vergessen...

Gruß

Filipp

Hallo,

wir planen bei einem Kunden Litigation Hold einzusetzen. Gleichzeitig sollen zur Entlastung (Größenreduzierung) der primären Mailboxen die Archivmailboxen verwendet werden.
Frage ist nun, wie weit diese Funktionen zusammenarbeiten.

Beim Verschieben von Primäre Mailbox in Archivmailbox werden die Mails aus ersterer gelöscht. Litigation Hold bedeutet aber eigentlich "Keine Löschungen, nur verschieben in Deletions/Purges." Damit würde das primäre Postfach ja niemals kleiner, somit kann man sich die Archivmailbox auch sparen. Oder ist Exchange intelligent genug, bei Verschiebungen in die Archivmailbox das Original tatsächlicha aus der primären Mailbox zu entfernen?

Gruß & Danke

Filipp

Hallo,

ich bräuchte da mal Hilfe bei Autodiscover bzw. den zugehörigen Service Connection Points.

Folgendes Szenario:
In einem Forest steht ein voll funktioinerender Exchange 2007 SP3 inkl. CAS.
In einem anderen, völlig unabhängigem AD-Forest ohne Trusts und alles sind die Clients (Outlook 2010) untergebracht. In diesem Forest gibt es keinen Exchange (!). Der Zugriff erfolgt über Outlook-Anywhere, beim Outlook-Start wird das Kennwort abgefragt. Funktioniert alles. Auch Autodiscover funktioniert, aber nicht so richtig schön. Da wir mit Zertifikaten und IP-Adressen "knapp" sind, und viele SMTP-Domains eingesetzt werden, gibt es keinen Host "autodiscover.smtpdomain.de" sondern nur einen "cas.generischedomain.de". Die Clients haben eine lokale XML-Datei hinterlegt (und einen Regkey, der für die SMTP-Domain auf sie verweist), die auf den cas.generischedomain.de verweist. Damit funktioniert Autodiscover. Allerdings wird die lokale XML-Datei erst ausgewertet, wenn alle anderen Methoden fehlgeschlagen sind.
Daher bin ich hier auf der Suche nach einer Verbesserung. Die erste Methode, die Outlook versucht, um einen Autodiscover-Service zu finden, ist das Auslesen von SCPs aus dem AD. Ich würde also gerne im AD manuell einen SCP anlegen, der auf den CAS im anderen AD zeigt. Auf http://www.msxfaq.de/e2007/autodiscover.html klingt das ganz einfach, und Exchange unterstützt sogar den Export von SCPs (Export-AutoDiscoverConfig) in andere Forests - vorausgesetzt, diese sind getrustet und scheinbar auch nur, wenn sie selber einen Exchange beinhalten.

Frage also: Hat das schonmal jemand von euch gemacht, kennt sich jemand damit aus?
Mir ist nicht klar, wo ich den SCP überhaupt hinlegen müsste. Soweit ich das Verstehe, wird eine LDAP-Suche über die gesamte Domain durchgeführt, aber sicher bin ich mir nicht. Die Pfade, wo er eigentlich hingehört gibt es in der Domäne ohne Exchange gar nicht.
Außerdem bin ich mir bezügl. der Auswirkungen nur zu 98% sicher. Soweit ich das verstehe, sucht Outlook einfach nach diesem Eintrag und verwendet den entsprechenden Hostname. Nebeneffekte auf Outlook oder gar andere Services sollte es nicht haben. Aber so 100% sicher bin ich mir mit SCPs halt nicht....

Wäre super, wenn mir jemand weiterhelfen könnte.

Danke

Filipp

PS: Ja, bei Clients im Internet wird mir das nichts bringen, braucht es aber nicht. Und die Methode mit SRV-Records wäre mein Fallback, möchte ich aus anderen Gründen aber vermeiden wenn möglich.

Hallo,

> für das Problem ist sie vollkommen irrelevant.
ist das nicht eigentlich der Zentrale Punkt? Exchange verwendet den alternativen MX nicht, sollte aber?

> Nirgendwo steht eine Pflicht, den zweiten MX zu nehmen,
> wenn der erste Greylisted.
Jein. Die RFCs besagen zumindest, dass der MTA in der Lage sein muss, alle MX-Records durchzuprobieren, wenn es beim ersten nicht "funktioniert"

> Wenn der Empfänger mehrere Mailserver betreibt,
> dann muss er dafür sorgen, dass die Greylisting-Datenbank
> untereinander synchronisiert wird.
Den Eröffnungspost habe ich so verstanden, dass der Empfänger das auch einwandfrei tut. Und zwar dahingehend, dass der 1. MX gar keine Mails annimmt, und der zweite genau dann, wenn schon ein Versuch beim 1. gemacht wurde.

> Tut mir leid hatte einige wichtige details vergessen!
Das waren allerdings wirklich wichtige Details. Dem zufolge hat das ganze mit Exchange überhaupt nichts zu tun, sondern nur mit dem "Hexmail"
> In den Logs kann man sehen das der Hexamail-Server immer
> versucht auf den selben Server zu schicken den mit der
> höchsten Priorität halt. Das scheint ja auch normal zu
> sein oder?!
Nee, wie gerade schon geschrieben sollten alle MXe probiert werden. Wende dich an den Hersteller.

Gruß

Filipp

Hallo,

mir wäre nicht bekannt, dass Exchange mit alternativen MX-Einträgen Probleme hat.
Aber ich möchte deine Frage erweitern, und hoffe, jemand anderes kann kompetente Auskunft geben:

Wann macht Exchange ein "fallback" auf einen anderen MX?
- Wenn der ursprünglich gewählte Netztechnisch nicht erreichbar ist
- Wenn ein temporärer Fehler erzeugt wird (Soft-Bounce, SMTP 4xx)
- Wenn ein endgültiger Fehler erzeugt wird (Hard-Bounce, SMTP 5xx)

Bei der englischen Wikipedia gibt es eine interessante Abhandlung darüber, die drauf hinausläuft, dass die RFCs hier nicht eindeutig sind (http://en.wikipedia.org/wiki/MX_record). Wie also ist die "Exchange-Interpretation" dieses Themas?

Gruß

Filipp

Hallo,

auf dem Connector lassen sich afaik keine solchen Einschränkungen machen. Lösen liese sich das aber wohl über Transport-Rules. Hier kannst du auf Werte in Headern prüfen. Im Header steht ja immer drin, welcher Server die Mail von welchem empfangen hat. Du kannst also eine Regel bauen: taucht im Received-Header die IP/der Name des Testsystems auf & soll die Mail nach extern gehen, dann verwerfen.
Noch einfacher ist es natürlich, wenn das Testsystem unter einer anderen EMail-Adresse als das Live-System schickt.

Nichts desto trotz würde ich dir ein eigenes Mailsystem für die Testsysteme empfehlen. Muss ja kein Exchange sein, je nachdem, was mit den Mails, die das Testsystem generiert, geschehen soll reicht ein Hamster o.ä.

Gruß

Filipp

Hallo,

RPC-over-HTTPS ist deutlich anfälliger bezüglich der Leitungsqualität als OWA. Das könnte schon ein Grund sein. Es gibt ein Tool von MS zum Testen von Latenzen bei rpc-over-http: rpcping. Das kannst du mal ausprobieren.

Wenn OWA aus Indien läuft, dann kann es nicht an der dortigen Firewall liegen, da OWA und Outlook Anywhere beide eine HTTPS-Verbindung zum CAS aufbauen.

Gruß

Filipp

Hallo,

danke für die Antwort - aber das hilft leider nicht weiter. KCD funktioniert bei uns. In den Technet-Artikeln ist nur von OWA die Rede. Und Tom Shinder schreibt im zweiten Teil des Artikels: "We have to make changes to the Web listener and RPC/HTTP Web Publishing Rule configuration because the Outlook RPC/HTTP client does not support User Certificate authentication." und trägt ein Fallback auf Basic-Auth ein - genau das, was wir nicht wollen.
Also hat MS die Authentifizierung mittels Client-Zertifikaten bei Outlook entweder vergessen oder so gut versteckt, dass sie noch niemand gefunden hat. In beiden Fällen kann ich absolut nicht nachvollziehen warum. Der "Anywhere"-Gedanke ist gut und schön, aber dafür keinen geeigneten Sicherheitsmechanismus anzubieten ist total Banane.

Gruß

Filipp

Hallo,

wir möchten gerne Outlook Anywhere auch anywhere einsetzen. Sprich: Zugriff mit Outlook 2007 auf ein Exchange 2007 per rpc-over-https, wobei letzteres über ISA 2006 publiziert werden soll. Nur die Sicherheit stellt uns vor eine echte Herausforderung. Eine Authentifizierung lediglich mit Nutzername + Kennwort kommt aus Sicherheitsgründen nicht in Frage. Wir wollten nun X.509-Clientzertifikate verwenden (sprich: Client authentifiziert sich bei Aufbau der SSL-Verbindung gegenüber dem Server, so wie dieser sich auch gegenüber dem Client authentifiziert). Mit IEx + OWA funktioniert das auch einwandfrei. Aber Outlook scheint ganz einfach nicht in der Lage zu sein, Clientzertifikate zu verwenden. Kann das sein? Wie kann man den Zugriff aus dem Internet dann absichern?

Danke für eure Tips

Filipp

Hallo Majo,

danke für die Antwort - auch wenn sie nicht wirklich erfreulich ist

Zurück aber nochmal zu meiner ersten Frage: Funktioniert OOF, wenn der am Client angmeldete User ein anderer ist, als der am Outlook/Exchange angemeldete? Sonst kann ich mir nämlich auch Autodiscover sparen.

Gruß

Filipp