Beiträge von BitFlip

moin,
um es noch einmal gaaaanz deutlich zu schreiben ;-):
Eine Dateisystemdefragmentierung des DB-Laufwerks ist im Exchange-Onlinebetrieb unbedingt zu vermeiden!!
Ein Dateisystemdefragmentierer würde versuchen, auch die Exchange-Logs und -DBs zu defragmentieren. Das könnte im schlimmsten Fall zur Dateikorruption führen.

Das ist schon ein echt unglückliches Konstrukt mit den zusätzlichen Dateifreigaben auf dem Exchange-DB-Laufwerk. Wenn möglich, solltest du versuchen, die Freigaben auf ein anderes Laufwerk zu verschieben, damit das DB-Laufwerk dediziert für die Exchange-Daten verwendet wird.

Falls das nicht geht, wäre die vermutlich sicherste Methode, den Exchange-Informationsspeicher zu beenden, dann die Logfile- und DB-Verzeichnisse auf ein anderes Laufwerk zu verschieben, und anschliessend das Laufwerk mit dem Dateisystemdefragmentierer zu bearbeiten. Parallel könntest du die Exchange-Offlinedefragmentierung der Daten auf dem anderen Laufwerk durchführen, und die frischen Exchangedaten abschliessend wieder zurückverschieben.
Meinen ersten Vorschlag finde ich aber besser, da er eine dauerhafte Lösung des Problems darstellt. Zumal das Verschieben der Exchange-Daten seeeehr lange dauern kann.

Hey,
wenn ich die Fehlermeldung ansehe, meldet OWA einen 500. Als ich den FBA-Fehler bei einem Kunden hatte, meldete OMA die Fehler, wie im KB-artikel beschrieben. Können in dem Fehlerszenario auch OWA-Fehler auftauchen??

Hey,

wichtig ist nur hervorzuheben, dass die Domäne der gefälschten Absendeadresse nicht unbedingt auf Blacklists landet. Korrigiert mich, wenn ich falsch liege, aber wenn ein Mailsystem ein NDR an eine offensichtlich gefälschte Absendeadresse schickt, scheint auf besagtem System auch keine Anti-SPAM-Technologie verwendet zu werden. Anderenfalls hätte das SPAM-Filter wohl einen Reverse-Lookup durchgeführt und direkt erkannt, dass der Absender gefaket ist. Oderr??
Weiss das jemand genauer?

hi frozenlife,
neben den links zur info schau dir mal den exchange 2007 sizer von hp an. einfach die vorgefertigten szenarien ansehen. dann könntest du auch eine expresskonfiguration probieren, um mal zu schauen, wie das so geht und welche parameter welche auswirkungen haben.
ich denke, die preconfigured solution für 500 user wäre schon richtig. bei hochverfügbarkeitsbedarf könnte die lcr-variante interessant sein.

hi damian,

erstmal vorweg: dein post gehört ins exchange 2003 forum.

zu deiner frage habe ich gegenfragen:
1. warum willst du überhaupt relayberechtigungen erteilen?
2. müssen deine clients tatsächlich per smtp senden?

sofern die clients über outlook und mapi angebunden sind, benötigt weder ein benutzer noch ein client relayberechtigungen auf exchange! es genügen übermittlungsberechtigungen, die per defaulteinstellung auf dem smtp-server aktiviert sind. will heissen: die standardeinstellung erlaubt mailversand und -empfang für mapiclients.

zur klärung:
1. relayberechtigungen auf dem virtuellen smtp-server musst du nur in folgenden fällen einrichten:
a. clients verwenden kein mapi, sondern pop3 oder imap4 und müssen demnachper smtp versenden.
b. du hast nicht exchange-server, die per smtp nachrichten an den admin senden. typischerweise tun dies usv-clients oder managementclients.

2. natürlich können nun mittels outlook express mails versendet werden. du hast allen authentifizierten computern relayberechtigungen erteilt! willst du dies nicht erlauben, deaktiviere die option "jedem authentifizierten computer, unabhängig von der obigen liste...". das ist der globale "relay-an/aus-schalter" für domänenmitglieder!!

3. in der einstellung "übermittlung - relay" entziehe der benutzergruppe die berechtigung "relay" [falls vorhanden] und belasse die berechtigung "übermitteln".

hi ralph,

exchange 2003 ist nicht für postfachgrössen jenseits der 2gb konzipiert worden. bei der entwicklung wurde eine durchschnittliche postfachgrösse von 200mb angenommen. das war 2001! in der zwischenzeit hat die e-mailnutzung dramatisch zugenommen, sodass diese begrenzung nicht mehr zeitgemäss ist.
bei der entwicklung von exchange 2007 wurde demnach konsequenterweise eine durschnittliche postfachgrösse von 2 gb angenommen. durch die verwendung der 64bit-architektur skaliert ex2k7 im gegensatz zu ex2k3 auch viel besser bei grösseren postfächern.
ausschlaggebend dafür ist u.a. auch die überwiegende verlagerung der iops [i/o-operationen pro sekunde] vom storage-subsystem ins ram. somit fällt der typische flaschenhals in form des storage-subsystems bei exchange bis zur version 2003 weg.

sofern du für deine power-user quotas jenseits der 2gb definieren willst, musst du, wie igfas gepostet hat, mit adsi arbeiten. ansonsten lässt du die quotas bei den betreffenden usern einfach weg.

es hat auch gründe, warum es eine standard und eine enterprise edition gibt, die im fall von ex2k3 auch mit datenbankgrössenbeschränkungen verbunden sind. ->s.o. flaschenhals storage!
bei grösserem datenbankbedarf als 75gb wird die enterpriseversion fällig. hierbei wird ein enterprise-backend mit einem leistungsfähigen storage wie einem san für exchange vorausgesetzt.

bei ex2k7 existiert kein db-grössenlimit, da es eben aufgrund der architektur keinen storage-flaschenhals mehr hat und nur noch rund 1/4 der festplatten benötigt, um eine vergleichbare performance wie ein ex2k3-system zu erzielen.
mit der ex2k7 standard edition kannst du bis zu 5 db/sg betreiben [empfehlung: 1db pro sg], die enterprise edition kann bis zu 50 db/sg hosten.
insofern solltest du eher einen übergang zu ex2k7 in betracht ziehen, als anzufangen, ex2k3 zu "hacken".
ich habe schon solche kundensysteme gesehen, die völlig jenseits der spezifikationen betrieben wurden und für die anwender eine katastrophale performance und verfügbarkeit brachten. ich kann nur davon abraten, solche massnahmen ernsthaft zu erwägen.

hi majo.
ich kenne die aussage bezüglich vss. ich möchte ja kein standard-onlinebackup inklusive logfiles per ntbackup im vss-mode durchführen, sondern lediglich einen snapshot einer konsistenten datenbank durchführen.
ich meine, eine konsistente lcr-db per vss-snapshot zu sichern sei ausreichend, um im crashfall diese db zu restoren. schliesslich weist sie doch einen clean shutdown-status auf, oder? so habe ich es jedenfalls verstanden.
vertrittst du lediglich die offizielle aussage von microsft oder meinst du, meine aussage sei technisch falsch?
wenn ich dich richtig verstehe meinst du, exchange sehe sich bei dem genannten verfahren als nicht gesichert an?

moin majo,
stimmt ja, das habe ich nicht richtig erinnert.

es gibt einen viel schwerwiegenderen nachteil von ntbackup: im vss-modus [also unter verwendung des volume shadow copy-api], die unter w2k3 die standardeinstellung ist, führt es keine konsistenzprüfung der datenbanken durch und kommittet die logfiles nicht in die datenbank. das heisst, du hast niemals die gewähr eines konsistenten backups. shadow copy backups mit ntbackup. daher wird empfohlen, onlinebackups im streaming-modus auszuführen, wo die konsistenz gewährleistet wird.

unter ex2k7 hast du mit ntbackup im vss-modus konsistente backups unter folgender voraussetzung: du replizierst die produktivdatenbank[en] mittels local continuous replication [lcr] und sicherst die replikatsdatenbank[en]. bei den continuous replicationverfahren von ex2k7 werden die logfiles der produktivdatenbanken direkt in die replikatsdatenbanken committet. daher sind die replikate konsistent und können einfach per snapshot gesichert werden.

im desasterfall einer korrupten datenbank startest du den store einfach neu, indem du die replikatsdatenbank mountest. da die logfiles in ex2k7 nicht mehr 5mb, sondern nur noch 1mb gross sind, ist der maximale datenverlust bei diesem verfahren sehr gering. sofern die mailboxen/datenbanken auf einem ccr-cluster liegen, kann sich der ex2k7-server fehlende logfiles aus dem transport dumpster holen.

ich meine mich zu erinnern, dass der userbezogene leserstatus in einem e-mailaktivierten pf beim einrichten aktiviert werden kann, zumindest unter ex2k3 ging das. unter ex2k7 hab ich es noch nicht getestet [ich will nicht wirklich neue pf in ex2k7 anlegen ].