Beiträge von tomdehn

Hi,

ein Server sollte völlig ausreichen. Die Mails werden vom POP-Connector geholt, es braucht dann nicht noch einen Edge Server. AntiVir und AntiSpam kann man auch auf einem Hubtransport Server aktivieren, wenn man es denn will. Wenn man ein gewisses Mass an Verfügbarkeit wünscht (kommt auch darauf an wie schnell das Mailsystem wieder lauffähig sein muss), liesse sich ein Standby Server daneben stellen, der ein SCR Replika der Datenbanken bekommt. Wenn der scharfe Server abraucht, lässt sich der andere recht rassig "aktivieren". Das muss aber sauber engineert werden, weil nicht ganz trivial.
Ansonsten dient LCR nur einem lokalen Storageausfall.

Cheers, TOM

Hi,

das kommt auch ein wenig auf die Client-Config an. Im cached mode ist die GAL, wie sie der Benutzer sieht, immer das OfflineAddressBook (OAB). Wenn man alle Adressbücher aktualisieren möchte (etwa nachdem ein MailUser erstellt wurde), lässt sich das mit der Exchange ManagementShell wie folgt erledigen:

Get-AddressList | Update-AddressList
Get-GlobalAddressList | Update-GlobalAddressList
Get-OfflineAddresBook | Update-OfflineAddressBook

Nun muss auf dem cached mode Client noch das Adressbuch heruntergeladen werden. Sind dort nun immer noch nicht alle Einträge vorhanden, checken ob Sie mittels OWA sichtbar sind (das geht nicht über das OAB).
Wenn ja, ist die Lösung an anderer Stelle zu finden: Die WindowsEmailAddress muss immer mit der PrimarySMTPAddress übereinstimmen. Tut sie das nicht, hat der OABGen Probleme das OAB zu erstellen. Also sicherstellen, dass die beiden Einträge gleich sind, anschliessend die cmdlets oben erneut ausführen, auf dem Client das Adressbuch herunterladen. Dann sollte es passen...

Cheers, TOM

Hi,

generell geht das aber - wenn auch eher schlecht:
Ich hatte die Erfahrung gemacht, dass sich der OwaApplicationPool regelmässig deaktiviert hatte. Dann konnten sich über den CAS weder Entourage- noch OWA-Clients verbinden. Das ist aber eben eine Eigenheit des IIS wie er mit W2008 kommt...

Es ist auch empfehlenswert die IIS Logs auf dem CAS Server genau einzusehen. Da finden sich viele Hinweise über 'bad requests' und Probleme im Zusammenhang mit der Authentifizierung. So dass man vielleicht gezielter im Web suchen kann.

Cheers, TOM

Hallo,

es gibt da mehrere Ansätze:
- den 3. Standort
- eine "Vorbereitung" des FSW auf einem Server im anderen RZ. Beim Ausfall des RZ mit dem FSW kann man "einfach" über einen CNAME im DNS gesteuert umswitchen
- den FSW auf einen Cluster (Fileserver) zeigen lassen, der Nodes in beiden RZ hat.

Ich wähle (im einfachen Fall) stets den FSW im RZ des primären Servers. Hat den Vorteil: wenn das passive RZ wegraucht ist mein FSW für den aktiven Node noch sichtbar, die Exchange-Instanz bleibt am laufen und muss nicht tauchen weil keine Mehrheit mehr gegeben. Wenn das aktive RZ wegbricht, habe ich eh massive Sorgen und i.d.R. die Zeit das manuell zu fixen...

Aber wie Heinz bereits schreibt: Für den Ausfall eines RZ ist CCR nicht unbedingt vorgesehen - da gibt es noch SCR (Standby Continuous Replication), das sich sogar 'on top' von CCR implementieren lässt.

Cheers, TOM

Hallo rziwin,

der entscheidende Vorteil bei einem CCR Cluster ist, dass er innerhalb den Resource Groups OHNE Diskabhängigkeit auskommt. Jeder Node jat seinen eigenen, replizierten Datenstamm. Das funktioniert nur dann konsistent, wenn man kein Quorum (im Sinne von einem gemeinsamen Datentopf) einsetzt. Stattdessen setzt man den Cluster als Majority Node Set (MNS) Cluster suf. Dieser braucht den Fileshare Witness dann (und nur dann) wenn sich die beiden Nodes nicht mehr "sehen". Ein Mehrheitsbeschluss unter den Nodes, ob ein Node aktiv werden (bleiben) darf ist nur gegeben, wenn es die zeugende Instanz gibt, das Fileshare Witness (FSW). Ansonsten kommt es zu dem von Dir beschriebenen Umstand.

Das FSW legt man in der Regel auf einen HT Server. Dessen Platzierung sollte man sich bei der Implementation genau überlegen: Hängen etwa der passive Node und das FSW an nur einem Switch und der Switch raucht ab, sieht der active Node weder den einen noch den anderen - folglich muss er seine Dienste einstellen. Vorausgesetzt, die Nodes können sich auch nicht mehr über die private NICs sehen.

Es gibt hier allerlei Modelle. Sehr robust ist auch den FSW in einer dritten Site zu platzieren. Auch lässt sich das FSW auf einem anderen HT Server im anderen Gebäude vorbereiten, so dass man mittels DNS (CNAME) den Zugriff auf das FSW im Falle eines Ausfalls steuern kann.
Aber das steht ja alles in dem Artikel auf den Du referenziert hast, der übrigens sehr gut ist!

Dein angedachtes Szenario (Shared Storage, gespiegelt im SAN) widerspricht eigentlich dem CCR Gedanken. Vielleicht schaust Du Dir den Single Copy Cluster (SCC) unter Exchange 2007 an. Das ist sozusagen ein klassischer Cluster, der möglicherweise besser Deinen Bedürfnissen genügt. Aber auch hier wird es schwierig sein die Exchange Services aufrecht zu erhalten, wenn erst mal das RZ mit dem Quorum stromlos ist...

Cheers, TOM

Hallo,

standardmässig landen Objekte die gelöscht werden im Papierkorb des Users, der sie auch gelöscht hat. Auch wenn die ursprünglich in der Supportmailbox war, die der User explizit als zusätzliche Mailbox in seinem Outlookprofil geöffnet hat. Dieses Verhalten lässt sich aber steuern. In jedem Fall ist die gelöschte Mail also entweder im Papierkorb des Users, oder der Supportmailbox.
Wenn eine Mail mit SHIFT+Delete gelöscht wird, geht sie nicht zuvor in den Papierkorb, sondern wird direkt gelöscht. Bei Outlookclients bis 2003 kann man diese Mails dann auch nicht (standardmässig) recovern, wie Heinz berieit geschrieben hat. Allerdings kann man einen Registrykey setzen (DumpserAlwaysOn), der selbst nach der Löschung das gelöschte Objekt unter "Recover Deleted Items..." anzeigt! Mehr dazu findet sich hier: http://support.microsoft.com/kb/246153/en-us

Seit Outlook 2007 sieht man den Dumpster immer, egal ob die Mail zuvor im Papierkorb war oder mit SHIFT+Delete gelöscht wurde.

Cheers, TOM

Hi Markus,

wie wäre folgendes?

Zwei Reglen: Die erste wie gehabt, lediglich dass sich die Regel auf alle Sender bezieht, bis auf die vier Zentralegruppen. Die zweite Regel wie die erste, aber NUR für die vier Zentralegruppen. Diese zusätzlich mit der Aussnahme "wenn im Subject FAX steht, schick's nicht ans DMS" (oder eben irgendein griffiges Kriterium, das diese Faxnachrichten charakterisiert).

Cheers, TOM

Hi,

diese Symptomatik tritt auf, wenn der MBX Server keinen HT Server kontaktieren kann. Ich verstehe es so, dass alle Rollen auf der gleichen Box laufen?
mit Test-ServiceHealth (Management Shell) lässt sich sehen, ob alle relevanten Services laufen.

Möglich ist auch (habe das vorallem bei virtuellen Maschinen gesehen) dass das Feature namens BackPressure zuschlägt. Dann nämlich ist der Exchanger der Ansicht überlastet zu sein und fährt seine Services zurück. Teste das mal mit einem "telnet <HT-Server> 25". Wenn der meint "busy" zu sein ist alles klar... hierzu findet sich ausreichend Doku im Web.

Cheers, TOM

Jürgen, das Logfileshipping über die private NIC zu steuern wird erst mit SP1 gehen...

Cheers, TOM

Hi Steffen,

es ist mir neu, dass man in den Kontaktinformationen die Custom Attributes einsehen kann...?!

Aber ich gebe hier Nobby recht: Es scheint nicht wirklich sinnvoll, da es sich ja allenfalls um eine Replikation in eine Richtung handeln würde (GAL --> PublicFolder Contacts).

Was Du machen kannst (Olk 2007): öffne das Addressbuch wähle die Adressliste aus (etwa die GAL) markiere alle Objekte - Rechtsklick - Add to Contacts...

Nun befinden sich alle GAL-Objekte in deinem Kontakteordner. Diese lassen sich in einen PublicFolder schieben und den Usern bereitstellen. Ich würde vielleicht darauf achten, dass dein Kontakteordner zuvor leer ist, so dass Du die GAL nicht von Deinen privaten Kontakten mühsam trennen musst...

Aber wie gesagt, das ist halt ein "einmaliger Schuss", den man regelmässig aktualisieren müsste. Und von Public Foldern sollte man sich ohnehin künftig eher weg- als hinbewegen!

Cheers, TOM