Exchange Queue & A: Exchange sich ständig.
Ob Sie Standard Kalendertage, Datacenter Endpunkte ändern oder Umleiten von Servern, haben Sie immer bereit, um Exchange zu ändern.
Henrik Walther
Montag Blues
F: Wir einem großen europäischen Unternehmen, und nur von IBM Lotus Domino zu Microsoft Exchange 2010 migriert haben. Die meisten unserer Benutzer verwenden Outlook Web App 2010 als ihren standardmäßigen e-Mail-Client. Mehrere Benutzer haben festgestellt, dass "Sonntag" standardmäßig ersten Tag der Woche unter den Einstellungen | Kalender in der Exchange-Systemsteuerung (siehe Abbildung 1).
.jpg)
Abbildung 1 standardmäßig ersten Tag der Woche für ein Exchange 2010-Postfach.
Da Montag der erste Tag der Arbeitswoche in unserer Region angesehen wird, möchten wir diese Einstellung für alle Benutzer von Exchange 2010 in der Organisation ändern. Können wir Exchange-Verwaltungskonsole (EMC) oder Exchange Management Shell (EMS) Sie zentral für alle unsere Benutzer dazu? Wir haben sah auf der Eigenschaftenseite für Postfächer in der Exchange-Verwaltungskonsole und sogar über EMS mithilfe des Cmdlets Get-Mailbox, aber keine Attribute, die sich auf erster Wochentag der Woche zu sehen. Können Sie weiterhelfen?
**A.**Montag ist der erste Tag der Arbeitswoche in den meisten europäischen Ländern, so verstehe ich Ihre Frustration. Glücklicherweise ist es relativ einfach, diese Einstellung für alle Benutzer ändern. Nicht mithilfe der Exchange-Verwaltungskonsole, aber Sie können sicherlich tun es mit dem Exchange Management Shell (EMS). Die meisten glauben, Sie müssten das Set-Mailbox-Cmdlet verwenden, um diese Einstellung zu ändern. Tatsächlich müssen Sie das Cmdlet Set-MailboxCalendarConfiguration verwenden.
Führen Sie den folgenden Befehl ein, und sehen Sie alle Kalender-spezifischen Einstellungen können Sie für ein Postfach bearbeiten (siehe Abbildung 2):
Get-MailboxCalendarConfiguration –Identity <user> | fl
.jpg)
Abbildung 2 Ändern Sie die standardmäßigen erster Wochentag über die Exchange Management Shell.
Wenn Sie "WeekStartDay" auf Montag für alle Benutzer in der Exchange 2010-Organisation, die "Contoso" in der Company-Attribut (zum Beispiel), ändern möchten, verwenden Sie den folgenden Befehl:
Get-User –Filter "Company –eq 'Contoso'" | Set-MaiboxCalendarConfiguration –WeekStartDay “Monday”
Zurück zur Mitte
F: Wir haben Exchange 2010 ca. jetzt ein Jahr lang ausgeführt wurde. Wir sind eine große Organisation, und bisher hatten wir eines einzigen Datencenters Hosten unserer Exchange 2010-messaging-Lösung. Wir haben ein zusätzliches Datacenter eingeführt, so dass wir Postfach Stabilität auf der Siteebene erreichen können. Es werden aktive Benutzer mit beiden Rechenzentren, so dass wir einen Clientzugriffsserver-Array (Array CAS) in das andere Datencenter erstellt haben.
Wir sind umgezogen bereits, dass die ersten 100 Benutzer in das neue Rechenzentrum Dinge überprüfen erwartungsgemäß funktionieren. Wir sind nicht ganz da. Wir sehen Probleme mit der Outlook MAPI-Client-Endpoint von "Outlook-1.contoso.com" (CAS Arrayobjekt FQDN im ersten Datencenter) in "Outlook-2.contoso.com" (neue CAS Arrayobjekt FQDN in das neue Rechenzentrum) geändert haben.
Die Outlook-MAPI-Clients weiterhin einfach den alten Endpunkt zu verwenden, die bedeutet, dass Outlook-Clients RPC-Sitzungen auf den CAS-Array im ersten Datencenter erstellen und das CAS-Array spricht dann RPC mit den Postfachservern in das neue Rechenzentrum. Keine Ahnung, ob dies beabsichtigt ist? Wenn dies nicht der Fall ist, haben Sie keine Ahnung, wie wir das beheben können?
**A.**Einige Exchange Queue & Ein Leser werden sich erinnern, habe ich berührt, diesem Thema vor. Beim Verschieben von Postfächern von einem Datencenter mit einer CAS-Array zu einem anderen Datacenter mit einem anderen CAS-Array möchten nicht Sie nicht die alte Endpunkt Regional/verfügbar machen. Dies wirkt sich alle Benutzer, die im ersten Datencenter aktiv sind.
Hier die Problemumgehung – Obwohl es nicht schön ist – besteht darin, das Outlook-MAPI-Profil für den Benutzer zu aktualisieren, ihr Postfach verschoben, um das neue Rechenzentrum hatte (mit die Option "Profile reparieren" in Outlook. zum Beispiel).
Einige von Ihnen vielleicht Fragen, warum Exchange 2010 auf diese Weise verhält. Es funktioniert nur mit früheren Versionen von Exchange. Outlook MAPI-Clients verbinden nun auf dem Clientzugriffsserver RPC Dienst (RPC-CA) für die ClientAccess-Serverfunktion nicht direkt an den Informationsspeicher für die Mailbox-Serverfunktion.
In Exchange 2007 und früheren Versionen, wenn Sie ein Postfach von einer Postfachdatenbank in eine andere verschoben haben, würde es in der Quelldatenbank Postfach senden ein "EcWrongServer"wird an den Outlook-Client führen. Die gezwungen, damit das Postfach in der Datenbank zu suchen, in dem jetzt das Postfach gespeichert ist.
Der RPC-CA-Dienst kann nicht antworten, mit einem "EcWrongServer"wird bei einer * über (Datenbank-Switch oder Failover) erfolgt zwischen zwei Rechenzentren (und der RPC-CA-Dienst verfügbar ist). Ebenso kann nicht Antworten einer Postfachdatenbank in eine andere, ein Postfach aus einer Postfachdatenbank in einem Datencenter verschieben, in dem das RpcClientAccessServer-Attribut der Zieldatenbank enthält einen anderen voll gekennzeichnete Domänenname (FQDN).
Während der Entwicklung von Exchange 2010 SP1 gab es Pläne, eine so genannte "Ermöglichen Cross-Site RPC Client Access" Option einzuführen, die Sie für eine Datenbank Verfügbarkeit von (DAG) konfigurieren würden. Diese Option wurde übermäßig komplexe erachtet, so dass es Recht geschnitten wurde, bevor Exchange 2010 SP1 geliefert.
Können wir koexistieren?
F: Wir haben in unserer Exchange 2003-Organisation Exchange 2010 bereitgestellt. Wir planen derzeit den Namespace zu verweisen, den wir verwenden, um ein Postfach in Exchange 2003 auf das Exchange 2010-CAS-Array zuzugreifen. Wir haben bereits einen älteren FQDN (legacy.contoso.com) zum SAN/UC-Zertifikat hinzugefügt, und wir haben die legacy-URL für das virtuelle Verzeichnis von OWA 2010 konfiguriert.
Wir haben aktivieren SSL-Verschiebung auf die Load-Balancer-Lösung, die Client-Verkehr über die Zertifizierungsstellen verteilt. Wir haben auch die Schritte in diesem folgen TechNet Wiki-Artikel SSL-Verschiebung auf Exchange 2010-CA-Server konfigurieren. SSL-Verschiebung ist nicht auf Server mit Exchange 2003 Front-End (FE) aktiviert.
Wir sind ein wenig unsicher, ob SSL-Verschiebung in einem Koexistenzszenario verwendet werden, in denen Clients auf Exchange 2010-CA-Server herstellen und an die FE für Exchange 2003-Server weitergeleitet werden. Wissen Sie, ob dieses Szenario funktioniert?
**A.**Ja, greifen OWA 2003 Benutzer ihre Postfächer durch Authentifizierung gegen Exchange 2010-CA-Server, die die Sitzung an Exchange 2003 FE-Server umzuleiten. Dies funktioniert auch mit SSL auf die Load-Balancer-Lösung und Exchange 2010-CA-Server aktiviert.
Einige von Ihnen möglicherweise eine andere Antwort erwartet haben. Exchange 2003-URL auf das virtuelle Verzeichnis von OWA 2010 konfiguriert muss in Form von "https://legacy.contoso.com/exchange" und nicht "http://legacy.contoso.com/exchange". Andernfalls erhalten Sie eine Ereignis-ID 91 im Anwendungsprotokoll (siehe Abbildung 3).
.jpg)
Abbildung 3 Fehler im Anwendungsprotokoll, wenn legacy-URL mit HTTP, anstelle von HTTPS konfiguriert ist
Das Vermächtnis muss mit HTTPS und nicht HTTP URL starten. Da Exchange 2010-CA-Server die Client-Sitzung mit einem Exchange 2003-FE-Server umgeleitet werden, wird es bei Verwendung von HTTPS für die OWA-legacy-URL einwandfrei funktionieren.
Kopierwarteschlange
F: Wenn ich verschiedene Exchange 2010-DAG-Szenarien (in der Regel in Testumgebungen) arbeiten, sehe ich manchmal eine extrem hohe Länge der Kopiewarteschlange (siehe Abbildung 4).
.jpg)
Abbildung 4 eine extrem hohe Kopierwarteschlange ist immer eine Möglichkeit.
Das erste Mal es bemerkt ich dachte, "Was das?" Bei der weiteren Untersuchung kann ich sehen, dass es genau dieselbe Nummer jedes Mal, wenn es passiert. Wissen Sie, ob dies einen Fehler oder etwas?
**A.**Die Zahl Sie sehen ist der höchste Wert für die Länge der Kopiewarteschlange festlegen können. Log copying ist nicht passiert, und die Cluster-Datenbank-Updates sind nicht passiert. Ein Verlust der Netzwerkverbindung zwischen DAG-Knoten in der Regel bewirkt, dass etwas davon.
In einer Testumgebung langsam kann dies gelegentlich auftreten. Sie sollten nicht in einer Produktionsumgebung jedoch angezeigt. Wenn Sie dies tun, empfehle ich herausfinden, ob die Ursache für die Netzwerkverbindung zwischen den Knoten DAG verlieren.
.jpg)
**Henrik Walther**ist Microsoft Certified Master: Exchange 2007 und Exchange-MVP mit mehr als 16 Jahre Erfahrung im IT-Bereich. Er arbeitet als Technologiearchitekt für Microsoft Gold Certified Partner in Dänemark und als Autor technischer Artikel für Biblioso Corp. (ein US-amerikanischen Unternehmen, das spezialisiert verwaltete Dokumentations-und Lokalisierungsdienste). Er ist auch eine vertraglich vereinbarten Hersteller arbeiten auf verschiedenen Produktteams (einschließlich Exchange und Lync-Teams) bei Microsoft.