RobertWi

Wenn man keine Änderungen an IIS-Komponenten vornimmt, ist das wirklich ein Zeitraum, der in der Praxis 95% der Fälle erschlägt. Nur beim IIS braucht man meistens (aber nicht immer) einen iisreset.

Frage steht auch hier: http://social.technet.microsoft.com/Forums/de-DE/884184fb-687b-45ae-8644-0002b542cc2b/exchange-2013-owa-geht-outlook-nicht-mehr

Moin, grundsätzlich ist "Geduld" die wichtigste Tugend, des Exchange Admins. Aber es werden nicht alle Einstellungen pauschal so gecacht. Das ist in echt viel komplizierter. Manche werden auf Zeit gecasht (es gibt 15 Minuten, 120 Minuten, 480 Minuten und fixe Zeitpunkt, z.B. 05:00 Uhr). Manche werden gecacht, bis man den entsprechenden Dienst neustartet, manche Einstellungen hängen an der AD-Replikation, manche Änderungen werden überhaupt nur wirksam, wenn man Exchange Werkzeuge nimmt, usw. usf.

Moin, wann hast Du denn das geändert. Diese Einstellungen werden bis zu zwei Stunden gecacht und Änderungen erst danach wirksam.

SBS 2003 wird seit mindestens mindesten 5 Jahren nicht mehr aktiv vertrieben. Die meisten Installationen dürften also deutlich älter als 5 Jahre sein. Und wenn ein Kaufmann es nicht schafft, über eine so lange Zeit hinweg Rücklagen für eine Neuinvestition zu bilden, dann sollte er sich wirklich die Frage gefallen lassen, ob er wirklich ein eigenes Geschäft führen sollte. IT ist heutzutage kein Selbstzweck mehr, viele - auch kleine Firmen - wären bei einem IT-Ausfall in kurzer Zeit pleite. Wie sagt man so schön: Alle Leute sind schlauer, manche vorher, manche nachher. (Ich bin übrigens gelernter Kaufmann mit eigener Firma und weiß daher, wie ordentliche Kostenrechnung funktioniert.) Zu dem, was "professionell" bedeutet, habe Dir die anderen ja schon was gesagt, das muss ich nicht wiederholen.

Würde mich wundern, wenn Du da keinen hättest. Und es wundert mich, dass Du überhaupt immer fehlerfrei senden kannst, wenn Du offensichtlich ein Problem mit dem HELO-FQDN hast. Da muss ein gültiger Wert rein, der auch einen passenden PTR-Eintrag im DNS braucht. Also: FQDN -> PTR -> IP-Adresse = IP-Adresse des Exchange nach außen

Moui, ich könnte mir gut vorstellen, dass Cipher RC4-MD5 nicht von der gegenüberliegenden Seite akzeptiert wird, da beides als geknackt gilt.

Und einen Exchange 2003 direkt am Internet zu betreiben, ist seit dem 08.04. irgendwas zwischen "mutig" und "verantwortungslos". :( http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=Exchange+Server+2003&Filter=FilterNO

Moin, Du schreibst "externe Kontakte (zuvor im AD erstellt)". Wurden diese Kontakte danach auch in Exchange E-Mail-Aktiviert?

Moin, sendet der Client die Mail im RTF-Format? Dann mal mit einem anderen Format ausprobieren. Aber wichtiger ist: Bitte bring den Exchange 2010 auf einen aktuellen Stand! Service Pack 1 ist nicht mehr supported und daher eventuell mit Outlook 2013 gar nicht mehr kompatibel. Ob das wirklich den Fehler behebt, kann man zwar nicht versprechen, aber niemand hier hat Lust, eventuell einen bereits seit langem gefixtem Bug hinterher zu rennen!

So schreibt er. Im Log sieht man aber, dass TLS gemacht wird.

Ohne TLS ist das nicht verwunderlich, aber MIT könnte es bei 2003 auch Probleme geben, weil dort neuere Standards nicht mehr eingebaut wurden.

Moin, mal davon abgesehen, dass es nützlich wäre, den genauen Fehler zu sehen, tippe ich mal auf das typische Standard-Problem, wenn Mailrouting zwischen Ex 2010 und Ex 2003 nicht klappt: Ihr habt einen Smarthost im virtuellen SMTP Server im Ex 2003 eingestellt. Der gehört da nicht rein, sondern in einen eigenen 2003 SMTP-Connector.

Moin, wie genau ist denn der Sende-Connector eingestellt? Sendet der wirklich an Port 25? Was steht im SMTP-Protokoll? Ist sichergestellt, dass sich nicht die Firewall-Konfig verändert hat?

Damit hast Du nichts gewonnden. Zuerst Automapping deaktivieren: http://www.msblog.eu/exchange-2010-sp2-automapping-deaktivieren/ Danach das Postfach als weiteres echtes Exchange-Postfach in das Haupt-Profil hinzufügen.

Dann nutzt Du Automapping. Da ist der Absender das einzige, was funktioniert. Aber Regeln und Signaturen geht nur bei echter Einbindung.

Ohne den TTL zu wissen, ist das alles nur Spekulation. Steht der auf 7 Tage, merken sich auch die großen Provider den falschen Eintrag so lange. Ist er dagegen zu niedrig, kann es auch mal sein, dass er ignoriert wird und einfach durch einen längeren ersetzt (beliebt bei T-Online).

Moin, dafür gibt es gleich mehrere Lösungen: - einen Regkey für Outlook - eine Exchange Einstellung - das zusätzliche Postfach als echtes zusätzliches Exchange-Konto in Outlook einbinden - Dritt-Anbieter-Tools Die ersten drei sind hier beschrieben: http://www.msoutlook.info/question/278 Ich persönlich bevorzuge die dritte Variante, weil ich dann nicht nur die korrekten Sent Items habe, sondern auch Regel, eigene Signaturen und auch der Absender ist automatisch korrekt gesetzt. Das führt bei meinem Verein dazu, dass die Leute sogar hauptsächlich nur in die gemeinsame Mailbox schauen und die private quasi die "zusätzliche" ist.

Moin, "550 5.2.0 No such mailbox" klingt mir nicht nach einer Meldung von Exchange. Die würde "Unkown User" oder "Unkown Recipient" lauten. Ist sichergerstellt, dass die Mail wirklich bei Exchange landet?

Moin, die Frage scheint im Augenblick mal wieder wöchentlich zu kommen (http://www.mcseboard.de/topic/197583-freigebenes-postfach-vs-%C3%B6ffentliche-ordner/). Die Antwort lautet i.d.R. "das kommt darauf an". Ich *persönlich* und mit Deiner Bescheibung oben erst recht, nutze freigegebene Postfächer deutlich lieber als ÖO. Könnte aber auch daran liegen, dass ich alle Nase lang Probleme mit ÖOs erlebt habe, die es mit PF nicht gibt.

:) Wie Dukel schon schreibt, kann eine weitere Trennung Log und DB sinnvoll sein. "Kann", weil man hier keine Pauschalaussage treffen kann. In Single-Installation wäre die Trennung sinnvoll. Bei DAG braucht man sie nicht mehr. Und wer es ganz auf die Spitze treibt, benutzt noch unterschiedliche RAID-Systeme. Zu 2003er Zeiten konnte das dann so aussehen: - C -> RAID 1 - DB -> RAID 5 - LOG -> RAID 10 Das macht dann mal locker 9 Platten - für eine DB! Bei der zweiten DB sollte das RAID 5 noch mal kommen (Logs waren damals noch pro Speichergruppe, d.h. zwei DB teilten sich die gleichen Logs). Eine Trennung aus Performance-Gründen ist aber seit 2010 nicht mehr notwendig und auch nicht grundsätzlich empfohlen. Eine Trennung aus Sicherungsgründen ist es aber schon. Und ein paar andere Argumente, wenigsten zwei Platten zu nutzen, findest Du oben. Und den für mich wichtigsten Grund habe ich noch gar niht gesagt: Es sieht einfach ordentlicher aus. :) Sizing und Storage für Exchange ist eine Wissenschaft für sich. ;)

Das ist eigentlich vollkommen unabhängig von Exchange. Es gilt grundsätzlich die Regel, dass man Daten von Programmen trennt. Gründe: - Fragmentierung - Performance - saubere Datentrennung -> wichtig bei Festplattenausfällen, denn ist entweder Exchange noch da oder die Daten, aber nicht beides weg - andere Backup-Strategie möglihch - andere RAID-Systeme möglich - läuft aus irgendeinem Grund die Exchange-Partition voll (passiert gerne mal per Viren-/Spam-Angriffen und Programmfehler gab es auch schon), ist bei Dir auch C voll -> mag Windows gar nicht - ist die Datenpartition voll, brauchst Du bei Trennung nur eine neue Platte; hier musst Du eventuell neuinstallieren, fehleranfällig klonen oder sonst irgendwie basteln checkdsk, Eventlogs, smart, Herstellertools - alles was es da so gibt. Da das C ist, bekommst Du checkdisk Reparaturen nur mit Reboot hin, weil die Systempartition im laufenden Betrieb nicht ausgehängt werden kann (addiere "bessere Reparaturoptionen" zu meiner obigen Liste).

Moin, da Du schon selbst hier im Forum den Konstrukt nicht mehr fehlerfrei beschreiben kannst (Fall1 und Fall 2 haben die gleiche Bedingung und passen nicht zu eingangs beschrieben Transportregel, die ein "außer" enthält und PublicfolderB wird außer im ersten Satz von Dir nicht mehr erwähnt), solltest Du eventuell überlegen, das ganze Gebilde umzubauen. Ich würde entweder nur Transportregel oder nur Regeln machen, aber nicht mit einer Mischung. Und ich würde das nicht mi ÖO, sondern mit Postfächern machen. Edit: keiner Fehler bei mir, weil Du einmal von XYZ und einmal von XYW sprichst - den Unterschied sieht man nur auf den Dritten Blick (XYZ und ABC wäre deutlicher gewesen). Ändert aber nichts an meinem Ergebnis NUR Transportregel oder NUR "Outlook"-Regeln.

Moin, so wie es scheint, hat sich wirklich irgendwo der Zähler für das Backup vertan. Du kannst das nun so probieren, wie hier im Forum beschrieben (Löschen oder neue DB und umziehen). Da die Datenbank eh von C wegsollte und am besten auf eine eigene Festplatte, ist ein Umzug eventuell doch der schönere und sicher Weg. Neue Platte rein, neue Datenbank rauf, Postfächer umziehen. Das geht dann alles ohne Ausfall und nur mit einer kurzen Störung für die Anwender. Unabhängig davon solltest Du unbedingt die Festplatte überprüfen um Hardwarefehler auszuschließen.

Eventuell. Aber zuerst solltest Du mit dem "korrekten Abschreiben" beginnen. Das Verständnis kommt dann später: Der Befehl, den ich geschrieben habe, lautete "Get-Mailboxdatabase | fl name" Bei Dir wurde daraus "Get-Mailboxdatabase | fl Admin" DAS wird wohl immer eine leere Anzeige bringen, da ein Mailboxdatabase-Object keine "Admin"-Eigenschaft hat (sehr wohl aber eine Eigenschaft "Name"). Na hoffentlich nicht. Ist auch nicht wirklich möglich, den Dom Admin im AD zu löschen. Und solltest Du das doch geschafft haben, hast Du nun richtig Spaß. ;) Ich auch nicht, kann aber in dem ganzen Durcheinander nicht mehr wirklich erkennen, was Du getan hast. Irgendwann wird Dir das dann wieder auf die Füsse fallen. AD und Exchange vergessen nur sehr wenig, und schon gar kein Try & Error. Hoffentlich erinnerst Du Dich dann wieder an diesen Thread.