RobertWi

Moin, auch nach mehrfachen Lesen ist mir nicht klar, was Du machst und was das Problem ist. Die Suche selbst lässt sich jedenfalls nicht weiter anpassen - nur, dass, was Du siehst (was nicht wirklich viel ist).

Moin. Ohne die Mail selbst zu sehen - kann man nur raten. Aber spontan würde ich sagen: Message Tracking zeigt Headetr-Felder (MAIL FROM und RCPT TO) an, Outlook selbst aber nur die normale Mail. Merke: In einer Mail kann alles gefälscht sein - auch Absender und Empfänger. 3+4 zeigen, das aus dem Postfach zwei Mails verschickt wurden (unterschiedliche MessageID). Allerdings ist mir nicht wirklich klar, was nun Dein Problem ist.

In Outlook hat das Abspeichern der Mails im richtigen gesendeten Objekte Ordner schon immer richtig funktioniert, wenn die Mailbox nativ als Exchange-Konto eingebunden wird und man "Senden Als" als Berechtigung hat. Die Einstellung in OWA bezieht sich zusätzlich auf "Senden im Auftrag von". Aber auch das ging eigentlich schon vorher, nur musste man dafür einen Regkey setzen (dann funktioniert es auch schon seit Ol 2003 mit "weiteren" Postfächern). EDIT: Einen Satz oben angepasst, so dass klar wird, dass man nun "zusätzlich" Send on behalf" einstellen kann.

Bei 2010 nicht mehr. Du hast bei einer Einbindung als weiteres Exchange-Konto nicht nur den korrekten Absender, sondern die gesendete Mail landet auch im richtigen Ordner, Du kannst automatisch unterschiedliche Signaturen einsetzen und kannst komfortabel Regeln und Abwesenheitsassistent pro Konto verwalten. Die Einbindung mehrere Exchange-Konten ist in Ol 2010 für mich das Killerfeature überhaupt. :)

Hast Du das Postfach nach dem Deaktiveren von Automapping als echtes Exchange-Postfach eingebunden oder als zusätzlich Postfacher unter "Erweitert beim ersten PF"? Es muss ein zusätzliches Exchange-Postfach sein, damit es richtig funktioniert.

Und ergänzend zu Nils: Hast Du passende Einträge von Exchange im Eventlog?

Ich bin zwar auch kein Freund von Ol 2013, aber die Frage, was fehlt, würde mich auch interessieren.

Moin, na ja, bei einem so komplexen Thema (Exchange ist da ein echter Datenbankserver), sind Verallgemeinerungen immer schwierig. Natürlich gibt es einen Bezug zwischen Datenbankgröße und RAM-Verbrauch. Nur nicht so direkt, wie Du ihn siehst. Aber ihr habt doch Mails bekommen, oder? Und mit jeder Änderung an der Datenbank holt sich Exchange ein wenig in den Cache rein. Die Zahlen sind wohl eher Zufall. Ich habe hier einen Kunden, der hat insgesamt 2 TB in 8 Datenbanken und Exchange benutzt von 48 GB RAM gut 42. Exchange-Seitig gibt es keinen Unterschied. Du könntest die Archiv-Datenbank auf billigere Festplatten legen oder nur einmal die Woche sichern. Aber bei einem Singleserver sind die Exchange-Vorteile eher gering. Hier liegt der größte Nutzen: Das Archiv befindet sich nicht im Cache und entlastet damit Outlook ein wenig. Ihr habt Ol 2007 im Einsatz, da kenne ich die Zahl nicht. Ol 2010 ist für 10 GB Postfachgröße optimiert (mehr geht aber), d.h. unterhalb von 10 GB halten sich die positiven Auswirkungen für Outlook dann auch in Grenzen.

Moin, Du bringst da einige Dinge durcheinander, was man in kurze Form nicht in einem Forum beantworten kann. RAM hat NICHTS mit dem Festplattenspeicher zu tun. Exchange lädt nicht die Bestandsdaten in den Speicher, sondern nur die Veränderungen. Die Menge des RAMs hat daher normalerweise nichts mit der Größe der Postfächer, sondern mit der Anzahl und Größe der Mails zu tun. Je mehr Mails, desto mehr RAM brauche ich. Ob Die Datenbank 1 GB oder 100 GB groß sind, ist unwichtig. (Bis auf wenige Ausnahmen) Wie gesagt: Daten in der DB haben nichts mir RAM zu tun. Da ist nur zufällig die gleiche Größe. Der RAM-Verbrauch hat etwas mit dem Nutzerverhalten zu tun. Starte den Rechner neu und beobachte und Du wirst sehen, dass anfangs weniger RAM benutzt wird und das in Deiner Umgebung nur langsam wächst. Ja, das ist korrekt (und auch ok so, warum sollte eingebauter Speicher unbenutzt sein.) Exchange "schmeißt" gar nichts rein oder raus, da er nur die Daten anfässt, die sich ändern. Ja, aber es wird dauern. Ist aber auch wie gesagt kein Problem. Warum sollte leerer Speicher unbenutzt bleiben, dann hättest Du ihn nicht einbauen müssen. Dann gibt dem System möglichst viel Speicher. Mail-Archivierung kann noch andere Gründe haben, z.B. gesetzliche Anforderungen. PST-Dateien sind wirklich Mist, die sollte man weglassen. Brauchen sie auch nicht. Sie berechnen die Anzahl der Benutzer, die Anzahl der Mails und die ungefähre Größe -> also die Veränderungen. Als Faustformel gilt: 5 - 10 MB pro Postfach.

Und im deutschen heißt die Gruppe:; "Organisations Administratoren". Und nicht persönlich nehmen, aber Exchange ist hochgradig mit AD verbunden und Probleme im AD führen früher oder später auch zu Problemen bei Exchange. Man kann nicht alles wissen, aber wenn Dir die absoluten Grundlagen zu AD fehlen (=welche administrativen Gruppen gibt es), solltest Du Dich zuerst mit den Grundlagen von AD beschäftigen. Du wirst sonst mehr Probleme als erwartet haben und Spaß wird Dir das auch nicht machen.

Jo, für die AD-Updates muss man Enterprise Admin sein. Und da auch das Schema aktualisiert wird, muss man auch Schema-Admin sein. Wenn das getrennte Konten sind, muss das setup via CMD ausgeführt werden: http://technet.microsoft.com/en-us/library/bb125224.aspx Und wenn es schon an so etwas einfachem, wie Berechtigungen, scheitert empfehle ich einen dringenden Blick in die Vorbereitungsaufgaben.

Wie muss man das verstehen? Du weißt, dass Exchange 2013 nur noch RPC-over-HTTPS macht und kein reines RPC mehr? Eventuell liegt das Problem also an dieser Konfig, Autodiscover, usw.?

Beide hatte ich selbst schon im Einsatz und fand, dass hMailServer ein wenig mehr bietet, aber dafür auch ein wenig aufwendiger in der Konfig ist. Trotzdem würde ich hMailServer vorziehen, weil es ein professionelleres Produkt ist, mir regelmäßigen Updates und einer guten Community.

Ist keine Kritik an Euch und keine Problem mit Prio. Sieht nur einfach .... aus. :)

Ja, nur das der Hersteller englisch spricht und in englischen Überschriften bis auf wenige Ausnahmen (Präpositionen) die Anfangsbuchstaben groß geschrieben werden. Im deutschen ist das aber nicht der Fall und damit sieht es einfach nur mistig aus. Für die wenigen Shouter (die könnte ein Mod korrigieren), sehen alle Überschriften bescheiden aus. ;)

Sorry, unglücklich ausgedrückt, der Satz bezieht sich auf "er IST in einer Super-Gruppe", nicht auf er WAR. Wenn er da mal war, musst Du manuell eingreifen und die Berechtigungen wieder gerade ziehen. Dann wird es auch wieder funktionieren: http://www.msxfaq.net/konzepte/adminsdholder.htm

Wenn jetzt noch der Adressraum auf "*" steht, würde ich den CBL-Eintrag erstmal ignorieren.

Moin, im Normalfall sollte dieser Untercontainer bei der ersten Sync automatisch angelegt werden. Handelt es sich bei dem Problemuser um einen Admin oder User, der sonstwie in einer Super-Gruppe ist oder war? Wenn ja, dann wird EAS mit dem nie richtig funktionieren (Stichwort: adminSDHolder) und es ist auch nicht vorgesehen, mit administrativen Konten zu arbeiten. Wenn nein, dann prüfe bitte, ob bei dem AD-Objekt des User die Vererbung der übergeordneten Sicherheitsberechtigungen aktiv ist.

Moin, ich vermute, CBL fragt einfach irgendwelche Server ab und klassifiziert die dann nach irgendwelchen Kritierien (und RFCs, die sich noch im Entwurf befinden). Wenn ihr wirklich via Smarthost sendet, ist der Eintrag egal, dann geht die Mail über 1&1 raus.

Prima, danke für das Feedback!

Kein Problem. Hätte ich auch nicht aus dem Ärmel schütteln können und daher erst am WE in meine Testumgebung basteln können.

Sorry, mein Fehler - gepaart mit offensichtlich vollkommener Erfahrungslosigkeit Deinerseits. :P Enable-ExchangeCertificate 1567055FCC751840DJ32355664267518JAK456AN -services UM

Ok, wenn man offiziell nicht supported AD-Berechtigungen setzt, kann man bei Anwendern ähnliches Verhalten erzeugen, wie beim Vollzugriff. Das Problem neben dem "unsupported" ist aber: Wenn man das nicht genau dokumentiert hat, findet man das nie wieder. Also eigentlich das, was Du gerade erlebst. Und jedes größere Update könnte dazuführen, dass es nicht mehr funktioniert. Weitermachen?

Anstelle von THUMBPRINT wird natürlich der Thumbprint eingesetzt und das Wort fällt raus... Get-ExchangeCertificate 1567055FCC751840DJ32355664267518JAK456AN -services UM

War das mal eine Migration von Exchange 2003 und ist eventuell ein übrig gebliebener Rest?