RobertWi

Moin, mist, den Thread lese ich erst jetzt. Es ist möglich, eine Weiterleitung an eine externe SMTP-Adresse ohne einen Kontakt zu machen, das geht aber nur über die Shell: set-mailbox ALIAS -ForwardingSmtpAddress STMPADRESSE@DOMAIN.TLD Wenn man dazu den Schalter "-DeliverToMailboxAndForward" auf $true setzt, wird die Mail auch im Orginal-Postfach abgelegt, sonst nur weitergeleitet. Aber wichtig: In beiden Fällen (mit Kontakt oder über die Shell) muss unter RemoteDomänen bei der entsprechenden Remote Domäne (oder bei *) noch der Haken "Automatische Weiterleitung zulassen" gesetzt sein. Sonst geht keine Mail nach draußen, egal ob via Kontakt oder Shell-ForwardingSmtpAddress.

Und wie sieht der Authentifizierungsreiter aus? Ist da "Exchange Server-Authentifizierung" aktiv?

Jein. Der Ablauf sieht wie folgt aus: - Änderung passiert - Seite aus der Datenbank in den Arbeitsspeicher laden - Änderung als SQL-Befehle in die Log-Dateien eintragen - Änderungen im Arbeitsspeicher machen - JETZT: Anwender sieht die Änderung (darum ist es auch für die Performance wichtig, dass Log-Dateien schnell geschrieben werden können) - (bei DAG nach dem Seeding: Änderung als SQL-Befehle an die passiven Knoten schicken) - wenn Zeit ist oder die Datenbankbereitstellung aufgehoben wird oder nach einem Crash bei Neustart oder ESEUTIL: Log-Dateien in die Datenbank übernehmen - bei einem Backup werden alle Log-Dateien, die bereits in der DB sind und (dessen Informationen bei DAG auf die passiven repliziert worden sind), abgeschnitten Seit 2010 wird auch abgewartet, bis eine gewisse Änderungsmenge vorhanden ist, bevor überhaupt die Datenbank angefasst wird. Bei einer "idle" DB kann es daher sein, dass diverse Log-Dateien entstehen, die nie eingearbeitet werden und bei einem Backup keine Log-Dateien abgeschnitten werden. Ja, zu 99%. Die Anzahl der Log-Dateien hat im Normalbetrieb überhaupt keine Auswirkungen auf die Performance, da die nur geschrieben, alle Änderungen aber im Arbeitsspeicher gemacht werden und von dort in die DB gehen. Log-Dateien, die bereits eingearbeitet sind, liegen nur noch aus Redundanzgründen auf der Platte. Die anderen, nicht eingearbeiteten, sind erst dann wichtig, wenn z.B. nach einem Crash der Arbeitsspeicher verloren gegangen ist oder die Bereitstellung aufgehoben wird. Dann dauert das etwas länger. Zu dem Zeitpunkt sind aber eh bereits alle Benutzer getrennt. Problematisch ist also nicht die Zahl der Log-Dateien, sondern die Zahl der *nicht eingearbeiteten* Log-Dateien. Da man die im laufenden Betrieb aber nicht einfach feststellen kann, ist die Diskussion darüber höchsten Philosophisch und sobald es ernsthafte Probleme gibt, wird sich Exchange schon beschweren. @Dukel: Kleine Begriffskorrektur. Bei einer Point-in-Time-Recovery werden keine Log-Dateien benutzt, da die Datenbank auf den Stand der Sicherung zurückgesetzt wird. Du meinst die Roll-Forward Recovery, dafür braucht man die Log-Dateien.

Moin, Ist auf dem Empfangs-Connector "Exchange Server" angehakt? Sonst aktiviere mal die SMTP-Protokollierung im 2003 virt. SMTP und dem 2010 Empfangsconnector und schau dann in die Log-Dateien.

Weil das von 2003 und 2007 benutzte Berechtigungskonzept nicht mehr von 2010 verwendet wird. Korrekt. Und das liegt einfach daran, dass der User gar nicht mehr für den Zugriff verwendet wird. Du kannst in den Berechtigungen eintragen, was Du willst, sobald ein Benutzer auf die GAL zugreift, wird gar nicht sein Konto verwendet, sonder eine der während des Setup angelegte universelle Sicherheitsgruppe benutzt - und die ist für alle Benutzer gleich. Das Konzept ist dem neuen Berechtigungskonzept in Ex2010 geschuldet, dem sog. RBAC. Wie gesagt: Der Hund liegt darin begraben, dass 2010 anders funktioniert, als 2003 oder 2007. Das ist ok, aber falls es irgendwann Probleme gibt, erinnerst Du Dich hoffentlich an die "Spielereien". ;) In diesem Fall gibt es leider noch nicht mal inoffizielle Vorschläge oder unsupportete Workarounds. Das alte System der GAL Segmentation funktioniert nicht mehr, das neue kommt erst mit SP2. Die einzige, heute schon mögliche Trennung, ist der sog. "Hosting Mode" seit dem SP1. Der ist aber eine komplette Trennung des Exchange in mehrere Umgebungen, hat keine EMC, keine öffentlichen Ordner, geht nur mit Outlook 2010, und noch einem weiteren Dutzend Einschränkungen. Das ist aber weit über dem, was Du suchst.

Nachtrag: Ich hab zumindest die öffentliche zugängliche Variante des Charts gefunden: Microsoft Exchange Server 2010: High Availability Deep Dive (including changes introduced by SP1) :: 2010 :: Europe :: Microsoft Tech·Ed -> PPT Slides -> Folien 7+8

Moin, ups.... Da ist kräftig was schiefgegangen. Worüber Du redest, nennt sich "GAL Segmentation". 1. Exchange 2010 funktioniert in dem Punkt grundlegend anders als 2007. 2. das Prinzip von 2007 auf 2010 angewendet, wird früher oder später zu Fehlern bis zum möglichen Totalausfall führen 3. das Prinzip von 2007 auf 2010 angewendet, ist komplett unsupported, auch der unter 2. beschriebene Ausfall 4. GAL Segmentation kommt mit dem Service Pack 2 im laufe des Jahres: You Had Me At EHLO... : GAL Segmentation, Exchange Server 2010 and Address Book Policies Du musst nun also schnellstens alle Änderungen rückgängig machen - und danach abwarten, bis das SP2 erscheint.

Moin, bei Site Resilience ist wirklich noch einiges anders, da würdest Du aber auch zwei FSW konfigurieren (zu dem normalen den Alternate FSW). Falls noch nicht bekannt: Managing High Availability and Site Resilience: Exchange 2010 SP1 Help und http://technet.microsoft.com/en-us/library/dd638129.aspx

Off-Topic: Mist.... Da bin ich wohl zu sehr auf den neuen Leasing-Wagen fixiert, der nächste Woche kommt. Wobei der gar keine Xeon-Scheinwerfer haben wird... :)

@Dukel: Wenn nicht mindestens die internen URL angepasst werden, dann wird es nicht funktionieren. @Landschaftsgest: Bitte tu uns den Gefallen, Crosspostings in anderen Foren zu kennzeichen: Crossposting - msxforum Kurze Frage zu SAN-Cert´s und Ex2010/TMG [Forum - Exchange 2010] - msxforum

Moin, Du kannst den Ex2010-Server nicht mit dem ESM verwalten und die Anzeigen dort funktionieren auch nicht fehlerfrei. Dafür hat sich zu viel geändert. 1. Kontrolliere mal den den Routinggruppen-Connector in der RG Dresden, der zum Ex2010 sendet, ob dort der richtige Zielserver eingetragen wurde. 2. Zum einem Fehler des ExBPA wird schon hier diskutiert: http://www.mcseboard.de/ms-exchange-forum-80/smtp-dienstprinzipalnahmen-fehlt-fqdn-175194.html Lies Dir das da auch nochmal durch, bzw. verfolge es dort mit. Solange der Mailtransport auf den neuen Server nicht klappt, brauchen wir die ÖO-Replikation nicht zu durchleuchten, die funktioniert nämlich mit Hilfe von E-Mails. Ansonsten kannst Du noch die SMTP-Protokollierung auf alt und neu checken.

Moin, diese Fehlermeldung kommt nicht von Exchange (zumindest habe ich den Text dort noch nicht gehört). Schau mal in die SMTP-Logs beim Empfangen und Weiterleiten. Kann es sein, dass der Fehler vom ERP-System kommt?

Moin, ESEUTIL ist ein Offline-Tool, nichts für den Online-Betrieb. Eine offizielle Lösung, die Log-Dateien online einzuarbeiten, ist nicht dokumentiert (darum sichern Backup-Programme ja auch noch die letzten Log-Dateien mit, sonst müssten sie das nicht). Die simpelste Methode, die Log-Dateien einzuarbeiten, ist einfach die Bereitstellung der DB aufzuheben. Dabei werden die Log-Dateien eingearbeitet. ESEUTIL ist dann gar nicht mehr notwendig.

Moin, 1. FSW wird nur bei einer geraden Anzahl von Knoten benutze, bei einer ungeraden nicht. 2. Fällt mehr als die Hälfte aus, gehen die DB der DAG offline Genau den Fall erlebst Du hier. Die einzige "Lösung" ist, die Anzahl der DAG-Server zu erhöhen. Aus diesem Grund erlebst Du meist auch eine gerade Zahl von DAG-Servern. Irgendwo, finde ich gerade nicht, gab es mal ein Chart von MSFT, in dem die verschiedenen Szenarien je nach Anzahl der DAG-Knoten beschrieben sind.

Moin, 0. Exchange komplett gepatcht SP3, RU3)? 1. was wurde geändert (nichts ist die falsche Antwort, dann würde noch alles gehen ;)). 2. was sagen: - ExBPA - Event-Log - SMPT-Logs Irgendwelche Fehlermeldungen darin, Auffälligkeiten oder sonstige Besonderheiten.

Moin, wichtig für den RAM ist übrigens nicht die Größe der Datenbank, sondern der tägliche Durchsatz an E-Mail. Folgende, ganze einfache Kalkulation lässt Dich garantiert auf der sicheren Seite: - 2 GB RAM für's BS - 2 GB RAM für jede Exchange-Rolle - 5 MB RAM pro Benutzer (das wäre ein Outlook 100-Profil, also 100 Mails von durchschnittlich 75 KB pro Tag) Bei Dir also 8 GB für's System und 500 MB für die Benutzer. Als Prozessor reicht ein normaler Dual- oder Quad-Core-Xenon problemlos. Auch um das Speichersystem brauchst Du Dir keine Gedanken machen, eine normale Sata-Platte reicht von der Performance (was nicht heißt, dass Du kein RAID einsetzen solltest wegen der Sicherheit, es geht hier nur um die Mindestanforderung). Und hier nochmal alles ganz ausführlich zum Nachlesen: Exchange 2010 ? Systemanforderungen: Hilfe zu Exchange 2010 (den weiterführenden Links folgen).

Moin, Die E-Mail stellt aber mit der Anlage eine Einheit dar. Entweder ist die ganze Mail "unwichtig", dann kann die ganze Exchange-DB auf billigen Store. Oder die Mail ist wichtig, dann gehört alles auf's SAN. Wobei man einschränken muss, dass sich diese ganze Philosophie seit Exchange 2010 deutlich verändert hat und dank DAG-Technik die Verwendung billigem Storage deutlich einfacher ist. 4. Größere Begrenzungen. Deine Lösung 3 widerspricht Deinem Punkt 1. Denn billiger Store neigt zu höheren Ausfällen und damit zu Verlust. Oder Du machst den billigen Store aufwendig ausfallsicher, dass wiederum kostet Geld. Das Problem dabei ist, und das erlebe ich jeden Tag in Diskussionen mit Kunden, dass sich Firmen nicht klar darüber sind, was sie wollen und wie wichtig die Verfügbarkeit für sie ist. Im Endeffekt gibt es nur zwei Lösungen: - wenn ich billigen Store nehme und Verlust in Kauf nehme, dann kann der Inhalt nicht so wichtig sein. Warum lösche ich den dann nicht gleich? - wenn aber die Aufbewahrung wichtig ist (womöglich für 30 Jahre), bleibt mir nichts anderes, als ein professionelles System übrig; das kann ein Archivsystem sein oder DAG mit mind. drei Knoten, oder, oder. Alles anders ist nur gebastelt und führt früher oder später zu mehr Problemen, als Lösungen. Als Alternative: Hast Du schon mal die Exchange-Archivierung ins Auge gefasst? Ein zwei Knoten DAG nur für den Archiv-Teil mit "billigen" Storage ist auch nicht so schlecht.

Danke für die Information. Abgesehen von einem durchgängigen Archiv-System, wo die ganze Mail archiviert wird (und natürlich auch normale Dateien vom Fileserver, Daten von Sharepoint, usw.), sehe ich aber immer noch wenig Sinn darin, nur einen Teil aus der Mail herauszureißen.

Moin, es gibt so Fragen, da habe ich mir in mehr als 10 Jahren Exchange noch nie Gedanke drüber gemacht - Mails inhaltlich auseinander reißen gehört dazu. :) Im Ernst: Was bringt es Dir, wenn Du die Anlagen von einer Datenbank (Exchange), in eine andere Datenbank (Sharepoint) verschiebst, außer doppelte Arbeit, Mehraufwand bei Backup und Recovery, User-Verwirrung (wo ist meine Anlage?), usw.

Moin, hier ein wenig zum Lesen: MSXFAQ.DE - WinRM You Had Me At EHLO... : Resolving WinRM errors and Exchange 2010 Management tools startup failures

Moin, setze hinter die Befehle "Move-ActiveMailboxDatabase" den Schalter -confirm $false

Das subjektive Empfinden von "es geschieht" etwas, zeigt hier deutliche Differenzen zwischen der PowerShell und dem Programmierer. :-)

Moin, und wenn "nicht geschieht", muss das nicht schlimm sein. Die meisten CMDLETs geben Rückmeldung nur im Fehlerfall oder bei Warnungen.

Moin, könnte es nicht eher sein, dass bei dem 2003 noch veraltete Einträge im Connector oder im DNS-Server sind?

Moin, wie genau ist denn der SMTP-Connector konfiguriert?