Veröffentlichung des Originalartikels: 29.03.2013

Ich bin Supporttechniker bei CSS. Vor kurzem meldete ein Kunde eine E-Mail-Schleife für eine bestimmte Domäne wie contoso.com. Dieser Fehler trat ausschließlich bei großen E-Mails auf. Eine ziemlich rätselhafte Situation – bis man erkennt, dass die E-Mail-Schleife von der Größenbeschränkung auf dem Sendeconnector herrührt. Ich dachte mir, diese Erkenntnis ist vielleicht auch für andere interessant.

Grundlegendes zur Konfiguration und zur Ursache des Problems:

Ich dachte anfangs, das Problem wäre darauf zurückzuführen, dass der Edgeserver für die Verwendung eines externen DNS-Servers (DNS-Server, der externe Hosts auflöst) konfiguriert wurde. Wenn der Edge-Transport-Server für die Verwendung eines externen DNS konfiguriert ist, löst er den Domänennamen in der Regel zu den öffentlichen IP-Adressen (die im Allgemeinen auf ihn selbst, auf die externe Firewall oder den Dienstanbieter verweisen) und nicht zu einem Hub-Transport-Server des Active Directory-Standorts auf, was eine E-Mail-Schleife zur Folge hat.

Beim Reproduzieren des Problems stellte ich jedoch fest, dass der Edge-Transport-Server nicht für die Verwendung eines externen DNS-Servers konfiguriert war. Meine Umgebung für die Reproduktion des Problems sah wie folgt aus:

In diesem Szenario geschieht Folgendes: Wenn der Edge-Transport-Server von einem Absender aus dem Internet eine E-Mail mit einer Größe von 20 MB erhält, wird diese E-Mail akzeptiert. Der Edge-Transport-Server verfügt über zwei Connectors, die dem Adressraum entsprechen – einer für den Adressraum contoso.com des Active Directory-Standorts und einer für den Adressraum *. Bei der Routingentscheidung auf der Grundlage der verfügbaren Connectors wird der Connector zwischen Edge und Hub aufgrund der Größenbeschränkung auf 10 MB nicht berücksichtigt. Der beste Treffer ist der *-Connector zwischen Edge und Internet (siehe Algorithmus für die Connectorauswahl unter Grundlegendes zum Nachrichtenrouting). Hier ist die Nachrichtengröße auf 30 MB begrenzt.

Ergebnis: Die Nachricht wird wieder an das Internet zurückgeleitet, was zu einer Schleife zwischen Internet und Edgeserver führt.

Abhängig davon, ob der Sendeconnector für das Internet zur Verwendung von DNS oder zur Verwendung eines Smarthosts für die Zustellung ausgehender E-Mails konfiguriert ist, erhalten wir einen der folgenden NDRs:

Bei Verwendung von DNS:

#554 5.4.4 SMTPSEND.DNS.MxLoopback; DNS records for this domain are configured in a loop ##

Bei Verwendung eines Smarthosts:

5.4.6 smtp;554 5.4.6 Hop count exceeded - possible mail loop> #SMTP#

Die Lösung

Dieses Verhalten ist Absicht und lässt sich ganz einfach beheben, indem Sie für den Connector die Größenbeschränkung für Nachrichten ändern. Folgende Optionen stehen zur Verfügung:

• Legen Sie den Parameter MaxMessageSize für den Empfangsconnector (zum Empfang eingehender E-Mails aus dem Internet) auf 10 MB fest, um die Größe von Nachrichten aus dem Internet auf 10 MB zu beschränken.
• Legen Sie den Parameter MaxMessageSize für den Sendeconnector zwischen Edge und Hub auf 30 MB fest, um Nachrichten mit einer Größe von 30 MB von externen Absendern empfangen zu können.

Problem gelöst! Danke an Arindam Thokder und Scott Landry, die mir bei der Aufbereitung für den Blog behilflich waren!

Suresh Kumar (XCON)

Dies ist ein übersetzter Blogbeitrag. Den Originalartikel finden Sie unter Mysterious mail loop on Edge Transport server: Check your size limits!

Veröffentlichung des Originalartikels: 12.03.2013

Im November 2012 haben wir den Client der MCA-Betaversion angekündigt. Seitdem haben wir eifrig an der Optimierung der verfügbaren Testoptionen im MCA-Client gearbeitet. Hier sehen Sie, was wir für die Version 1.0 implementiert haben:

Microsoft Connectivity Analyzer 1.0

Wir freuen uns, die Veröffentlichung der Version 1.0 der Microsoft-Verbindungsuntersuchung ankündigen zu können. Hierbei handelt es sich um ein Begleittool für die Webseite der Microsoft-Remoteverbindungsuntersuchung. Mit dem MCA-Tool können Administratoren und Endbenutzer Verbindungsdiagnosen für fünf allgemeine Konnektivitätssymptome direkt auf ihrem lokalen Computer ausführen. Benutzer können die eigene Konnektivität testen und die Ergebnisse in einem HTML-Format speichern, das Administratoren von den Ergebnissen der RCA-Website kennen.

Installieren Sie MCA 1.0 hier: https://testconnectivity.microsoft.com/?tabid=client

Ein Einführungsvideo finden Sie hier:

Mit dem MCA-Tool lassen sich fünf Symptome untersuchen:

• „Ich kann mich nicht bei Office Outlook anmelden.“ – Dieser Test entspricht dem Exchange-RCA-Test für Outlook Anywhere (RPC über HTTP). Es gibt eine Option zum Ausführen des SSO-Tests auf der Parameterseite.
• „Ich kann auf meinem mobilen Gerät keine E-Mails senden oder empfangen.“ – Dieser Test entspricht dem Exchange-RCA-Test für Exchange ActiveSync.
• ***Neuer MCA-Test*** „Ich kann mich über mein mobiles Gerät oder die Lync-App aus dem Windows Store nicht bei Lync anmelden.“ – Mit diesem Test werden die Einträge des Domänennamenservers (Domain Name Server, DNS) für Ihre lokale Domäne überprüft, um sicherzustellen, dass sie für die Unterstützung mobiler Lync-Clients korrekt konfiguriert sind. Zudem wird eine Verbindung mit dem AutoErmittlungswebdienst hergestellt, um sicherzustellen, dass die Authentifizierung, das Zertifikat und der Webdienst für Mobilität korrekt eingerichtet sind.
• ***Neuer MCA-Test*** „Ich kann über Outlook keine E-Mails senden oder empfangen (nur Office 365).“ – Mit diesem Test wird der Fluss eingehender/ausgehender SMTP-E-Mails überprüft. Zudem enthält er DNS-Überprüfungen für Office 365-Kunden.
• ***Neuer MCA-Test*** „Ich kann keine Frei/Gebucht-Informationen eines anderen Benutzers anzeigen.“ – Mit diesem Test wird überprüft, ob von einem Office 365-Postfach auf die Frei/Gebucht-Informationen eines lokalen Postfachs zugegriffen werden kann (und umgekehrt). Pro Testlauf wird jeweils eine Richtung überprüft.

Microsoft Lync-Verbindungsanalyse (Microsoft Lync Connectivity Analyzer, MLCA): Auf der Clientseite befindet sich auch das Lync-Verbindungsanalysetool. Wir arbeiten an einer baldigen Zusammenführung der Microsoft-Verbindungsanalyse und der Microsoft Lync-Verbindungsanalyse, wollten den Kunden aber bereits jetzt diese beiden großartigen Tools zur Verfügung stellen, um die Optionen für die Clientdiagnose zu verbessern. Weitere Informationen zu MLCA finden Sie hier

Feedback: Senden Sie Ihr Feedback bitte an das Alias MCA-Feedback. Lassen Sie uns wissen, was Sie von dem Tool halten und ob es für Sie beim Behandeln von Konnektivitätsproblemen hilfreich ist. Sie können uns auch gerne Feedback zu weiteren Tests zukommen lassen, die Sie sich für das Tool wünschen würden.

Microsoft-Remoteverbindungsuntersuchung (Remote Connectivity Analyzer 2.1)

Wir freuen uns, die Veröffentlichung von Version 2.1 der Website für die Microsoft-Remoteverbindungsuntersuchung ankündigen zu können. Mit diesem Tool können Administratoren und Endbenutzer Verbindungsdiagnosen für unsere Server ausführen, um allgemeine Probleme mit Exchange, Lync und Office 365 zu überprüfen. Wir haben neue DNS-Tests für Office 365 hinzugefügt, die vorhandenen Tests erweitert und die Website insgesamt optimiert.

Die Websiteaktualisierungen sehen Sie hier: https://testconnectivity.microsoft.com

Im Anschluss finden Sie die wichtigsten Punkte der Version 2.1 von RCA:

Version 2.1 (März 2013)

• Unterstützung für 60 Sprachen hinzugefügt
• Version des herunterladbaren Tools „Microsoft Connectivity Analyzer v1.0“ zum Behandeln von Konnektivitätsproblemen über den lokalen Computer aktualisiert
• Herunterladbares Verbindungsanalysetool für Microsoft Lync zum Behandeln von Lync-Problemen über den lokalen Computer hinzugefügt
• Allgemeiner Testabschnitt für Office 365 hinzugefügt
• DNS-Konnektivitätstest für Office 365 Exchange hinzugefügt

Viel Spaß damit!

Danke.

Brian Feck im Namen des gesamten MCA/RCA-Teams.
Folgen Sie dem Team auf Twitter: @ExRCA

Dies ist ein übersetzter Blogbeitrag. Den Originalartikel finden Sie unter Announcing Microsoft Connectivity Analyzer (MCA) 1.0 and Microsoft Remote Connectivity Analyzer (RCA) 2.1

Veröffentlichung des Originalartikels: 21.02.2013

Wir freuen uns, die oft gewünschte Hosting- und Mehrinstanzanleitung für Exchange Server 2013 ankündigen zu können. Diese können Sie hier herunterladen.

Aufmerksame Leser werden feststellen, dass dieser Anleitung stark der Anleitung für Exchange Server 2010 ähnelt. Das liegt aber nicht daran, dass wir einfach die alten Inhalte recycelt haben. Vielmehr ist die Strategie, auf die wir uns für Exchange 2010 verständigt haben, auch für Exchange 2013 gültig: Es wird empfohlen, die eigene Lösung nur unter Verwendung der integrierten Tools, Cmdlets und Schnittstellen zu konfigurieren und Objekte in AD keinesfalls direkt zu ändern, um die gewünschte Konfiguration zu erhalten.

Ebenso ist es weiterhin zutreffend, dass in einer mehrinstanzähnlichen Konfiguration nicht alle Features wie gewünscht funktionieren. E-Mail-Infos funktionieren beispielsweise wie in einer standardmäßigen lokalen Bereitstellung – was häufig dazu führt, dass Daten zwischen Instanzen unerwünschter Weise offengelegt werden. In dem Dokument werden Features hervorgehoben, die möglicherweise nicht erwartungsgemäß funktionieren, wenn Sie Exchange für mehrere Instanzen konfigurieren. Zudem enthält das Dokument Konfigurations- bzw. Deaktivierungsempfehlungen.

Herzstück des wichtigen Verzeichnissegmentierungselements Ihrer Lösung ist das Adressbuchrichtlinien-Feature. Mit dem kürzlich angekündigten Transport-Agent, der für die Nutzung von Adressbuchrichtlinien konzipiert wurde, ist Ihre 2013er Lösung noch einfach zu erstellen und zu verwalten.

Für 2013 gibt es einige bedeutende Änderungen. Daher empfiehlt es sich, die Anleitung vor dem Planen und Erstellen einer Lösung sorgfältig zu lesen und sie beim Auftreten von Problemen erneut zu konsultieren.

Genau wie bei Exchange 2010 gibt es wieder Partnerlösungen, die gemäß den Richtlinien des Dokuments erstellt wurden. Die bislang überprüften Lösungen finden Sie auch auf der Website. Diese Liste wird noch erweitert. Sollte Ihre Wunschlösung also noch nicht in der Liste enthalten sein, schauen Sie später noch einmal vorbei, oder erkundigen Sie sich beim Anbieter nach dessen Plänen für eine Überprüfung.

Wir planen die Veröffentlichung einer aktualisierten Skalierungsanleitung für Exchange 2013 mit Mehrinstanz- oder Hostingkonfiguration. Sobald dieses Dokument verfügbar ist, finden Sie entsprechende Informationen auf der Lösungsseite.

Wir hoffen, das Dokument hilft Ihnen weiter, und freuen uns auf Ihr Feedback.

Greg Taylor
Principal Program Manager Lead
Exchange Customer Experience

Dies ist ein übersetzter Blogbeitrag. Den Originalartikel finden Sie unter Hosting and Multi-Tenancy Guidance for Exchange Server 2013 Now Available

Im Artikel OAB in Exchange Server 2013 im Exchange-Teamblog wurde die neue Architektur für die Generierung und Verteilung des Offlineadressbuchs (OAB) in Exchange Server 2013 beschrieben. Bitte lesen Sie sich diesen Artikel durch, falls Sie ihn sich noch nicht angesehen haben, bzw. lesen Sie ihn erneut durch, um Ihr Gedächtnis aufzufrischen.

Die OAB-Verwaltung in Exchange 2013 weicht aufgrund von Änderungen an der Architektur von den Vorgehensweisen in früheren Versionen ab. Darüber hinaus stehen derzeit im Exchange Admin Center keine Optionen für die Verwaltung von OABs zur Verfügung. Deshalb benötigen Sie momentan die Exchange-Verwaltungsshell, um Aufgaben mit Bezug zu OABs auszuführen.

In diesem Artikel werden einige Aufgaben beschrieben, die im Rahmen der OAB-Verwaltung häufig auszuführen sind. Zum besseren Verständnis der Aufgaben finden Sie hier zudem eine Reihe von praxisnahen Beispielszenarien.

Hinweis: Wenn Sie Teil einer Gesamtstrukturumgebung mit Active Directory-Domäne sind, stellen Sie sicher, dass ViewEntireForest in der Shellsitzung aktiviert ist. Andernfalls wird bei einigen Befehlen in diesem Artikel keine Ausgabe zurückgegeben.

Befehl zum Aktivieren von „ViewEntireForest“:

Set-ADServerSettings -ViewEntireForest $true

Generieren eines neuen OAB

Beim Generieren eines neuen OAB in Exchange 2013 wird der Parameter „-Server“ nicht mehr eingesetzt. Geben Sie zur Generierung eines neuen OAB nur die erforderlichen Adresslisten an.

Mit dem folgenden Beispielbefehl wird ein OAB für die Adressliste „Global Address List FAB“ generiert:

New-OfflineAddressBook -Name OAB-FAB -AddressLists "Global Address List FAB"

Identifizieren der Server, auf denen OABs generiert werden

Den Vermittlungspostfächern in Exchange Server 2013 ist ein bestimmter unveränderlicher Funktionsumfang („Persisted Capability“) zugewiesen, der den Zweck bzw. die Funktion des jeweiligen Vermittlungspostfachs definiert.

Ein Vermittlungspostfach, bei dem der Parameter für den Funktionsumfang auf „OrganizationCapabilityOABGen“ festgelegt ist, ist für die Generierung von OABs verantwortlich. In diesem Artikel werden wir ein solches Postfach als „Organisationspostfach“ bezeichnen.

Der Exchange Server 2013-Postfachserver, auf dem das Organisationspostfach gehostet wird, generiert alle in der Umgebung definierten OABs.

Verwenden Sie in einer Nicht-DAG-Umgebung den folgenden Befehl, um die Server zu identifizieren, auf denen OABs generiert werden:

Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "*oab*"} | ft name,servername

In einer DAG-Umgebung besteht die Vorgehensweise zum Identifizieren eines oder mehrerer Server für die OAB-Generierung aus zwei Schritten.

Schritt 1: Identifizieren des Organisationspostfachs mit OAB-Generierungsfunktionalität, das die Postfachdatenbank hostet

Lassen Sie sich mithilfe des folgenden Befehls alle Vermittlungspostfächer anzeigen, deren unveränderlicher Funktionsumfang „OABGen“ ist, sowie die Datenbank, die dieses Postfach hostet:

Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "*oab*"} | ft name,database

Schritt 2: Identifizieren des Postfachservers, der die Datenbank mit dem Organisationspostfach bereitstellt

Identifizieren Sie mithilfe des folgenden Befehls die aktive Kopie der Postfachdatenbank:

Get-MailboxDatabaseCopyStatus db1

Der Server, für den der Datenbankstatus als „Bereitgestellt“ angegeben wird, ist derzeit der Server zur OAB-Generierung.

Ändern des OAB-Generierungsservers

Sie haben zwei verschiedene Möglichkeiten, einen anderen Server zur OAB-Generierung festzulegen.

Verschieben des Postfachs

Verschieben Sie das Organisationspostfach in eine Postfachdatenbank auf einem Server, den Sie zum Server für die OAB-Generierung machen möchten.

Beispiel:

„DB1“ ist eine Datenbank mit einer einzelnen Kopie auf dem Server „Exch1“, die das Organisationspostfach enthält. „DB2“ ist eine Postfachdatenbank auf dem Server „Exch2“.

Mit dem folgenden Befehl können Sie das Organisationspostfach auf „DB2“ verschieben und „Exch2“ zum Server für die OAB-Generierung machen.

Get-Mailbox -Arbitration -database db1| where {$_.PersistedCapabilities –like “*oab*”} | New-MoveRequest -TargetDatabase db2

Diese Methode eignet sich eher für Umgebungen mit einer einzelnen Kopie der Postfachdatenbank, die das Organisationspostfach hostet.

Aktivieren der Postfachdatenbank auf einem anderen Server

Diese Methode eignet sich für Umgebungen mit mehreren Kopien der Postfachdatenbank, die das Organisationspostfach hostet.

Beispiel:

„DB1“ hostet das Organisationspostfach und verfügt über Kopien auf den Servern „Exch1“ und „Exch2“. „DB1“ ist derzeit auf „Exch1“ aktiv.

Mit dem folgenden Befehl können Sie „DB1“ auf „Exch2“ aktivieren und „Exch2“ damit zum Server für die OAB-Generierung machen:

Move-ActiveMailboxDatabase DB1 -ActivateOnServer Exch2

Hinweis: Lesen Sie sich die Richtlinien unter „Speicherort des Organisationspostfachs“ unten durch, bevor Sie den Server für die OAB-Generierung ändern.

Erstellen eines neuen Organisationspostfachs

Administratoren können zusätzliche Organisationspostfächer erstellen, um Fehlertoleranz zu gewährleisten oder um Benutzer in einer geografisch verteilten Exchange-Bereitstellung zu bedienen.

Zur Erstellung eines neuen Organisationspostfachs sind zwei Schritte erforderlich:

Schritt 1: Erstellen eines neuen Organisationspostfachs

New-Mailbox -Arbitration -Name "OAB Seattle" -Database DB2Seattle -UserPrincipalName oabs@contoso.com –DisplayName “OAB-Postfach für Seattle”

Schritt 2: Aktivieren der OABGen-Funktion

Set-Mailbox -Arbitration oabs -OABGen $true

Hinweis: Lesen Sie sich die Richtlinien unter „Speicherort des Organisationspostfachs“ unten durch, bevor Sie zusätzliche Organisationspostfächer erstellen.

Ändern des OAB-Generierungszeitplans

Bis Exchange Server 2010 basierte die OAB-Generierung auf einem Zeitplan, der über die OAB-Eigenschaften festgelegt wurde. Möglicherweise sehen Sie, dass in den Eigenschaften eines OAB in Exchange 2013 ein Zeitplan definiert ist. Die OAB-Generierung in Exchange Server 2013 erfolgt jedoch nicht gemäß dem Zeitplan, der in den OAB-Eigenschaften festgelegt ist:

Stattdessen erfolgt die Generierung von OABs in Exchange Server 2013 anhand der Eigenschaften „OABGeneratorWorkCycle“ und „OABGeneratorWorkCycleCheckpoint“, die auf dem Postfachserver konfiguriert sind.

Beispiel:

Die Werte im obigen Screenshot bedeuten, dass einmal am Tag ein OAB erstellt wird.

Welcher Postfachserver hat die OAB-Downloadanforderung verarbeitet?

Die CAS-Rolle in Exchange Server 2013 übergibt die OAB-Downloadanforderung an einen entsprechenden Server mit Postfachrolle. Die CAS-Rolle zeichnet jede Anforderung, die sie verarbeitet, in den Protokolldateien im Ordner %Exchange-Installationspfad%\Logging\HttpProxy\OAB\ auf.

Mithilfe dieser Protokolldateien können Sie leicht ermitteln, an welchen Postfachserver der CAS die Anforderung weitergeleitet hat.

Informationen zu einigen wichtigen Feldern in der Protokolldatei:

Sie können die Protokolldatei in Excel importieren, um sie dort leichter auszuwerten.

Beispiel:

Erzwingen der OAB-Generierung

Sie haben zwei verschiedene Möglichkeiten, den sofortigen Start der Generierung von OABs für Exchange Server 2013 zu erzwingen.

Methode 1: „Update-OfflineAddresBook“

Mit dem unten gezeigten Befehl können Sie die Generierung eines OAB mit der Bezeichnung „Standard-Offlineadressbuch“ in allen Organisationspostfächern erzwingen.

Update-OfflineAddressBook "Standard-Offlineadressbuch"

Hinweis: Mit diesem Befehl wird RPC-Anforderung an jeden Postfachserver initiiert, der ein aktives Organisationspostfach hostet.

Methode 2: Neustarten des Postfach-Assistentendiensts

Der Microsoft Exchange-Postfach-Assistentendienst mit der Postfachrolle ist für die OAB-Generierung verantwortlich. Bei einem Neustart dieses Dienstes werden alle in der Umgebung definierten OABs auf einem bestimmten Postfachserver generiert, sofern dieser ein aktives Organisationspostfach hostet.

Speicherort des Organisationspostfachs

Die CAS-Rolle in Exchange Server 2013 übergibt die OAB-Downloadanforderung an den „nächstgelegenen“ Postfachserver, der ein aktives Organisationspostfach hostet. Die Übergabe der Anforderung kann nach dem Roundrobin-Prinzip erfolgen, wenn an einem AD-Standort mehrere aktive Organisationspostfächer gefunden werden. Dies kann dazu führen, dass häufig ein vollständiger OAB-Download durchgeführt wird.

Daher empfehlen wir derzeit, den Speicherort des Organisationspostfachs so zu planen, dass an einem AD-Standort jeweils ein Organisationspostfach aktiv ist. Dies gilt sowohl für die Erstellung eines neuen Organisationspostfachs als auch für die Erstellung von Kopien der Postfachdatenbank, die ein Organisationspostfach hostet.

Szenarien

In den folgenden Szenarien werden die neuen Methoden zur OAB-Verwaltung anhand einer praxisnahen Situation ausführlicher erläutert.

Szenario 1: Erstellen eines neuen Organisationspostfachs

Contoso verfügt über Exchange Server 2013-Server mit der Postfachrolle und der CAS-Rolle, die in den Büros in Dallas und Seattle bereitgestellt sind. John, der Exchange-Administrator von Contoso, analysiert die HTTP-Proxy-Protokolldateien von CAS-Servern und stellt fest, dass die OAB-Downloadanforderung für Benutzer in Seattle an die Server in Dallas weitergeleitet wird. Bei eingehender Untersuchung stellt John fest, dass nur in Dallas ein Organisationspostfach existiert, sodass die OAB Downloadanforderungen aller Benutzer an den Server in Dallas übergeben werden.

Er erstellt mit den folgenden Befehlen ein neues Organisationspostfach auf dem Server in Seattle:

Schritt 1: Erstellen eines neuen Vermittlungspostfachs

New-Mailbox -Arbitration -Name "OAB Seattle" -Database DB2Seattle -UserPrincipalName oabs@contoso.com –DisplayName "OAB-Postfach für Seattle"

Schritt 2: Aktivieren des Vermittlungspostfachs mit OABGen-Funktion

Set-Mailbox -Arbitration oabs -OABGen $true

Szenario 2: Anpassen des OAB-Generierungszeitplans

Ben ist ein Administrator der Exchange 2013-Bereitstellung bei Tail Spin Toys. Der standardmäßige OAB-Generierungszeitplan ist für das Unternehmen ungeeignet. Stattdessen soll das OAB etwa alle 4 Stunden generiert werden.

Ben ändert mithilfe des folgenden Befehls die Eigenschaften des Postfachservers, der das Organisationspostfach hostet.

Set-MailboxServer Exch1 -OABGeneratorWorkCycle 01.00:00:00 -OABGeneratorWorkCycleCheckpoint 04:00:00

Einige Tage später analysiert John die Ereignis-ID 17002 im Anwendungsprotokoll und stellt sicher, dass das OAB alle vier Stunden generiert wird.

Ich hoffe, Sie finden diesen Beitrag hilfreich. Teilen Sie uns unten Ihre Meinung mit!

Bhalchandra Atre

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Managing OAB in Exchange Server 2013.

Vor Kurzem haben wir eine geführte exemplarische Vorgehensweise (Guided Walk Through, GWT) für die Problembehandlung von Fehlern bei der Replikation öffentlicher Ordner in Microsoft Exchange 2003 veröffentlicht. Sie können auf verschiedene Arten auf diese Informationen zugreifen. So können Sie etwa diesen Link für den direkten Zugriff verwenden. Darüber hinaus werden diese Informationen in verschiedenen Artikel zur Replikation öffentlicher Ordner enthalten sein. Hierzu zählt beispielsweise folgender KB-Artikel: https://support.microsoft.com/KB/842273.

Sie fragen sich nun wahrscheinlich, warum wir eine Problembehandlung für Exchange 2003 veröffentlicht haben, für das der Mainstream Support bereits abgelaufen ist. Unsere Entscheidung hierfür basiert auf einer Reihe von Gründen. Zunächst einmal arbeitet ein nicht unbeachtlicher Teil unserer Exchange-Kunden derzeit an der Umstellung von Exchange 2003 auf eine neuere Version, und wir möchten diesen Kunden so gut wie möglich bei der Umstellung auf neuere unterstützte Versionen des Produkts helfen. Dies stellt die beste Möglichkeit dar, diesen Kunden die entsprechenden Informationen zukommen zu lassen, da wir für sie keinen Telefonsupport mehr anbieten. Darüber hinaus wurden alle Probleme mit den öffentlichen Ordnern in Exchange Server 2003 bereits weitgehend identifiziert. Wenn wir daher jetzt eine Problembehandlung hierzu erstellen, werden sich diese Informationen nicht mehr grundlegend ändern. Außerdem hat sich die Replikationsmethode für öffentliche Ordner einige Zeit lang nicht tiefgreifend verändert (bis Exchange 2013), sodass es sinnvoll war, mit Exchange 2003 zu beginnen. Aufbauend auf diesem Grundgerüst können wir spätere Versionen dann relativ leicht auf den aktuellen Stand bringen.

Die Supportorganisation wird diese Problembehandlung noch um Informationen zu Exchange 2007 und Exchange 2010 ergänzen.

Bei dieser exemplarischen Vorgehensweise handelt es sich im Grunde um einen Leitfaden für die Problembehandlung der Replikation, die Bill Long in einer Reihe von Blogbeiträgen erläutert hat. Diese englischsprachigen Beiträge finden Sie hier, hier und hier. Die Problembehandlung ist nicht als Ersatz für die umfassenden Informationen zum Replikationsprozess für öffentliche Ordner gedacht. Vielmehr soll sie Ihnen schnell die Schritte vermitteln, mit denen Sie bei Problemen mit der Replikation die Ursachen ermitteln können.

Ich möchte einigen Personen danken, die die Erstellung dieses Dokuments möglich gemacht haben. Meines Wissens waren folgende Parteien an der Problembehandlung beteiligt:

Exchange-Support:

• Nick Basile
• Rob Whaley
• Bill Long
• Charlotte Raymundo
• Will Duff
• Nino Bilic

Teams für Dokumentation und Inhaltserstellung:

• Bobbie DeFault
• Geoffrey Crisp (Entirenet)
• Jerry Sitser (Entirenet)
• Jarrett Renshaw
• Star Li (Wicresoft)
• Chen Jiang
• Victor Zhang (Wicresoft)

Bis bald,

Charlotte Raymundo
Messaging Knowledge Engineer

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Public Folder replication troubleshooter.

Aufgrund des Feedbacks unserer Kunden haben wir den Empfängerzahl-Grenzwert in den Tarifen Office 365 Enterprise (E1, E2, E3, E4, K1 und K2), Professionals and Small Businesses (P1) und Government (G1, G2, G3 und G4) erhöht. Die Benutzer können nun pro Tag E-Mails an bis zu 10.000 Empfänger senden. Dieser neue Grenzwert gilt auch für eigenständige Exchange Online-Tarife (Kiosk, Plan 1 und Plan 2). Bisher lag der Empfängerzahl-Grenzwert bei diesen Tarifen für die Benutzer bei maximal 1.500 Empfängern pro Tag.

Die Grenzwerte für die Empfängerzahl sollen Benutzer davon abbringen, eine große Anzahl von unerwünschten kommerziellen E-Mail-Nachrichten zu senden. Solche Nachrichten werden auch als Spam bezeichnet. Durch diese Grenzwerte schützen wir unseren Onlinedienst davor, eine Quelle von Spamnachrichten zu werden. Diese Schutzmaßnahmen garantieren somit auch eine reibungslose Zustellung der E-Mail-Nachrichten unserer Kunden. Dank Verbesserungen in den Datencentern können wir diesen Grenzwert erhöhen, ohne dass Einbußen beim Schutz zu befürchten sind.

Die Grenzwerte betreffen sowohl die E-Mail-Nachrichten, die innerhalb einer Organisation gesendet werden, als auch Nachrichten an Benutzer in anderen Organisationen. Die beste Methode, eine Überschreitung des Empfängerzahl-Grenzwerts zu vermeiden, ist der Einsatz von Verteilergruppen, wenn Nachrichten an eine große Anzahl von Empfängern gesendet werden sollen. Verteilergruppen im freigegebenen Adressbuch werden im Hinblick auf den Empfängerzahl-Grenzwert als ein Empfänger gezählt. Weitere Informationen hierzu finden Sie unter Strategien zur Unterstützung von Massen-E-Mails. Office 365-Kunden, die rechtmäßige kommerzielle Massen-E-Mails versenden müssen, etwa Newsletter für Kunden, sollten weiterhin die Dienste von Drittanbietern in Anspruch nehmen, die sich darauf spezialisieren.

Weitere Informationen zu Empfängerzahl-Grenzwerten finden Sie unter Massen-E-Mails und Grenzwert für die Empfängerzahl. Diese Änderung wurde durch Ihr Feedback veranlasst. Wir danken Ihnen für Ihre Rückmeldung und würden uns freuen, weitere Anregungen dieser Art zu erhalten!

Steve Chew

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Recipient Rate Limit Increase to 10K for Office 365 and Exchange Online.

Haben Sie schon einmal einen Anruf von jemandem erhalten, dessen Outlook-Client sich nicht mit seinem E-Mail-Server verbinden kann? Wäre es nicht praktisch, dieser Person einfach ein Tool senden zu können, das diese Person durch einen Verbindungstest führt und ihr eine leichte Möglichkeit bietet, Ihnen die Ergebnisse zuzusenden?

Möglicherweise sind Sie auch ein Administrator, der Remote Connectivity Analyzer bereits seit Jahren zur Überprüfung der E-Mail-Konfiguration einsetzt, möchten aber dieselben Tests innerhalb Ihrer Organisation durchführen und dabei dieselben Diagnosedetails erhalten wie auf der RCA-Website.

Da wir von unseren Kunden Anfragen dieser Art erhalten haben, hat unser Team ein Tool für genau diese Szenarien erstellt: Microsoft Connectivity Analyzer (Beta). Dies ist eine portable Version der Remote Connectivity Analyzer-Website. In diesem kurzen Video (49 Sekunden, nur in englischer Sprache) erhalten Sie eine Einführung in Microsoft Connectivity Analyzer:

Dieses Tool umfasst dieselben Tests wie die Website, aber mit einer leicht vereinfachten Benutzeroberfläche. Dadurch eignet es sich ideal, um es Ihren Nutzern, Familienmitgliedern oder dem Nachbarn einige Häuser weiter zuzusenden.

Darüber hinaus haben wir die Ergebnisse in zwei Ansichten unterteilt: Eine einfache Ansicht, die ausschließlich leicht verständliche Ergebnisse enthält, und eine zweite Ansicht mit ausführlichen Ergebnissen, die nur für Administratoren von Interesse sind.

Die zusätzlichen Informationen für Administratoren werden unter „Details zu allen Tests anzeigen“ aufgeführt:

Sie können den entsprechenden Benutzer auch bitten, die ausführlichen Ergebnisse in einer Datei zu speichern und Ihnen diese zuzusenden. Die ausführlichen Ergebnisse werden in einer HTML-Datei gespeichert, sodass Sie sie in Ihrem Webbrowser anzeigen können.

Voraussetzungen für Microsoft Connectivity Analyzer

1. Das Tool unterstützt folgende Betriebssysteme: Windows 7 (64-Bit), Windows 7 und Windows Server 2008 und höher
2. Microsoft .NET Framework 4.5 ist erforderlich.
3. Browseranforderungen:

Die Installation ist in allen modernen Browsern möglich. Beachten Sie jedoch Folgendes:

• Wenn Sie Google Chrome verwenden, müssen Sie ClickOnce for Google Chrome installieren.
• Firefox-Benutzer müssen Microsoft .Net Framework Assistant für Firefox installieren.

Die vollständigen Anmerkungen zu dieser Version finden Sie hier.

Das war noch nicht alles. Wir planen, weitere Tests hinzuzufügen.

Genau wie zum Zeitpunkt der Veröffentlichung der Website ist diese erste Version von Microsoft Connectivity Analyzer noch nicht vollständig.

Das Tool wird direkt beim Endbenutzer vor Ort ausgeführt, sodass wir in der einzigartigen Lage sind, Tests für häufig mit allen Arten von Verbindungen auftretende Probleme hinzuzufügen. Diese frühe Version des Tools ist erst der Anfang.

Das ist noch nicht alles!

Zusätzlich zur Einführung des neuen Tools bieten wir jetzt in Kooperation mit Lync Remote Connectivity Analyzer beide Tools in einem Tool an. Wie Sie erkennen, haben wir das Wort „Exchange“ aus dem Namen entfernt. Auch die URL der Website hat sich geändert: https://testconnectivity.microsoft.com. Damit stehen alle leistungsstarken Tests für Lync und Exchange auf einer Website zur Verfügung.

Auswahl der verfügbaren Tests:

• Microsoft Lync Mobile Auto-Discover Web Service Remote Connectivity Test testet Ihre Remoteverbindung mit Microsoft Lync Mobile Auto-Discover Web Service Server.
• Microsoft Office Communications Server Test testet die Remoteverbindung mit Microsoft Office Communications Server. Zugriffsedge und Port für die Verbindung werden automatisch erkannt, Sie können aber auch einen bestimmten Zugriffs-Edgeserver angeben.
• Microsoft Lync Server Remote Connectivity Test testet die Remoteverbindung mit Microsoft Lync Server. Zugriffsedge und Port für die Verbindung werden automatisch erkannt, Sie können aber auch einen bestimmten Zugriffs-Edgeserver angeben.

Und wir haben noch mehr!

Haben wir erwähnt, dass wir dieses Jahr wirklich viel erreicht haben? Auf der Registerkarte „Office 365“ stehen nun zwei neue Tests zur Verfügung: Office 365 Lync-DNS und Frei/Gebucht.

Beim Office 365 Lync-DNS-Test werden die externen Domänennameneinstellungen für den Benutzer der benutzerdefinierten Domäne in Office 365 überprüft.

Dank des Office 365 Deployment Services-Teams steht der Office 365-Test „Frei/Gebucht“ jetzt auch auf der RCA-Website zur Verfügung. Bei diesem Test wird sichergestellt, dass ein Office 365-Postfach auf die Frei/Gebucht-Daten eines lokalen Postfach zugreifen kann (und umgekehrt). Zu diesem Test gehören folgende Schritte:

• Prüfung, um sicherzustellen, dass die Systemzeit des Hybridservers nicht um mehr als fünf Minuten abweicht, da dies beim Abrufen von Delegierungstoken von Microsoft Federated Gateway zu Fehlern führt.
• Prüfung, um sicherzustellen, dass für eingehende Verbindungen mit dem Hybridserver keine Firewallvorauthentifizierung erforderlich ist. Die Firewall muss also die Pass-Through-Authentifizierung unterstützen.
• Prüfung, um sicherzustellen, dass der Hybridserver die Anforderungen im Hinblick auf die Exchange Server-Mindestversion (Exchange Server 2010 SP1) erfüllt.
• Einfache Frei/Gebucht-Abfrage beim Zielverfügbarkeitsdienst.
• Links auf Seiten mit Informationen zum Hybridkonfigurations-Assistenten, der häufig die Ursache von Fehlkonfigurationen bei der Hybridbereitstellung ist.

Damit sind wir am Ende der Neuerungen angelangt. Vielen Dank, dass Sie diesen Beitrag vollständig gelesen haben! Wir hoffen, dass Ihnen die Neuerungen zusagen, und freuen uns auf Ihr Feedback.

Nicole Allen
für das RCA-Team

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter What’s new with Microsoft Remote Connectivity Analyzer? A lot!.

Seit Kurzem bietet Windows Update Windows Management Framework 3.0 als optionales Update an. Dazu zählen alle Arten der Verteilung von Updates, etwa Microsoft Update, WSUS, System Center Configuration Manager und andere Methoden. Das wichtigste Merkmal der neuen Version ist, dass PowerShell 3.0 Teil von Windows Management Framework 3.0 ist.

Windows Management Framework 3.0 wird je nach von Ihnen verwendeter Serverversion (Windows Server 2008 SP2 oder Windows Server 2008 R2 SP1) als KB2506146 oder KB2506143 verteilt.

Was bedeutet das für Sie?

Windows Management Framework 3.0 (insbesondere PowerShell 3.0) wird derzeit nur von einer Exchange-Version unterstützt: Exchange Server 2013. Für diese Exchange-Version ist das Windows Management Framework 3.0 zudem erforderlich. Wenn Sie Windows Management Framework 3.0 auf einem Server mit Exchange 2007 oder Exchange 2010 installieren, werden Probleme auftreten. So kann es etwa vorkommen, dass Exchange-Updaterollups sich nicht installieren lassen oder die Exchange-Verwaltungsshell nicht korrekt ausgeführt wird.

Bei Problemen mit der Installation von Exchange-Updaterollups haben wir folgende Symptome gesehen:

• Bei einer Rollupinstallation über Microsoft Update schlägt die Installation möglicherweise mit dem Fehlercode 80070643fehl.
• Bei der Rollupinstallation über einen Download wird die Fehlermeldung Das Setup wurde aufgrund eines Fehlers vorzeitig beendetangezeigt.
• In beiden Fällen kann die Ereignis-ID 1024 mit dem Fehlercode „1603“ im Anwendungsereignisprotokoll erfasst werden. Wenn Sie beispielsweise Updaterollup 5 für Exchange 2010 SP2 installieren möchten, wird möglicherweise folgende Beschreibung in Ereignis-ID 1024 angezeigt:

  Produkt: Microsoft Exchange Server - Update "Updaterollup 5-v2 für Exchange Server 2010 Service Pack 2 (KB2785908) 14.2.328.10" konnte nicht installiert werden. Fehlercode 1603. Windows Installer kann Protokolle erstellen, um bei der Problembehandlung betreffend der Installation von Softwarepaketen behilflich zu sein. Verwenden Sie folgenden Link, um Anweisungen zur Aktivierung der Protokollierungsunterstützung zu erhalten: https://go.microsoft.com/fwlink/?LinkId=23127.

Windows Management Framework 3.0 sollte derzeit auf Servern mit Exchange 2007 oder Exchange 2010 bzw. auf Arbeitsstationen, auf denen die Exchange-Verwaltungstools für eine der beiden Versionen installiert sind, nicht bereitgestellt werden. Falls Sie dieses Update bereits bereitgestellt haben, entfernen Sie es bitte wieder. Nach der Entfernung des Updates sollten die Funktionen wieder wie zuvor eingesetzt werden können.

Ben Winzenz

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Windows Management Framework 3.0 on Exchange 2007 and Exchange 2010.

Im Oktober haben wir die Veröffentlichung des RTM-Builds (Release to Manufacturing) von Exchange Server 2013 bekanntgegeben. Seitdem haben wir das Hauptaugenmerk darauf gelegt, die nächste Version von Exchange über mehrere Vertriebskanäle für unsere Geschäftskunden freizugeben.

Heute haben wir einen weiteren wichtigen Meilenstein erreicht: Das Exchange-Team freut sich, die allgemeine Verfügbarkeit von Exchange Server 2013 bekanntzugeben. Sie können diese Version ab sofort bei TechNet herunterladen und das Produkt 180 Tage lang evaluieren. Außerdem können Sie sich für Office 365 Preview anmelden, um in nur wenigen Minuten in den Genuss der aktuellsten Exchange-Nutzererfahrung in der Cloud zu kommen.

Diejenigen unter Ihnen, die Exchange Server 2013 in Umgebungen ohne bestehende Infrastruktur oder in Testumgebungen installieren möchten, um neue Features zu evaluieren und Tests mit LOB-Anwendungen durchzuführen, können dies sofort tun. Wenn Sie eine Exchange 2010- oder 2007-Umgebung betreiben, muss für das Upgrade ein Rollup auf Exchange Server 2010 SP3 oder 2007 ausgeführt werden. Wir wissen, dass Sie schon bald auf die neue Version umstellen möchten, und arbeiten daher hart daran, Exchange 2010 SP3 und dem Rollup den letzten Feinschliff zu geben. Für beide Releases liegen wir derzeit im Zeitplan für eine Veröffentlichung in Q1 2013 .

Falls Sie dies nicht bereits getan haben, sollten Sie sich in der TechNet-Dokumentation oder durch Teilnahme an einer Ignite-Schulungssitzung näher über Exchange Server 2013 informieren. Wir empfehlen Ihnen, sich bereits jetzt über die Voraussetzungen und Systemanforderungen zu informieren und sich mit der vereinfachten Bausteinarchitektur von Exchange vertraut zu machen, um einen Vorsprung bei der Größenanpassung, der Planung und dem Kauf von Hardware zu haben.

Das EHLO-Team hat seit der RTM-Ankündigung weitere technische Inhalte zum neuen Exchange veröffentlicht (Artikel in englischer Sprache):

• Offline Address Book in Exchange Server 2013 – Bhalchandra Atre
• Managing Federated Sharing with the EAC – Elber Ren und Robert Mazzoli
• Offline Access in Outlook Web App for the New Exchange – Sara Manning
• Public Folders in the New Office – Alfons Staerk und Nikhil Aggarwal
• Publishing Exchange Server 2013 using TMG – Greg Taylor
• Lessons from the Datacenter: Managed Availability – Ross Smith IV und Greg Thiel

Wir werden in den nächsten Monaten weitere neue Exchange-Artikel auf EHLO veröffentlichen. Vielen Dank für Ihre Unterstützung. Wir freuen uns auch weiterhin über Ihr Feedback.

Exchange-Team

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Exchange Server 2013 Reaches General Availability.