Übersetzung vorschlagen
 
Andere Vorschläge:

progress indicator
Keine anderen Vorschläge
TechNet Magazine > Home > Alle Ausgaben > 2009 > TechNet Magazine September 2009 >  Exchange Fragen: Ein zweiter Blick auf Funktion...
Inhalt anzeigen:  Englisch mit deutscher ÜbersetzungInhalt anzeigen: Englisch mit deutscher Übersetzung
Dies sind maschinell übersetzte Inhalte, die von den Mitgliedern der Community bearbeitet werden können. Sie können die Übersetzung verbessern, indem Sie auf den jeweils zum Satz gehörenden Link "Bearbeiten" klicken.Mithilfe des Dropdown-Steuerelements "Inhalt anzeigen" links oben auf der Seite können Sie zudem bestimmen, ob nur der englische Originaltext, nur die deutsche Übersetzung oder beides nebeneinander angezeigt werden.
Exchange Q&A A Second Look at Exchange 2010 Features and Improvements
Henrik Walther

In this installment, I’m continuing where I left off in my last column—that is, answering even more questions related to new and exciting Exchange 2010 features. But I also have room for a couple of Exchange Server 2007 questions.
Q We are deploying a multisite Exchange 2007 SP1 cluster using Cluster Continuous Replication (CCR). The two cluster nodes will be located in separate datacenters. Exchange runs on Windows Server 2008 SP2 and we plan to have the public and private interfaces located in different subnets in each datacenter. As you know, this means we must use routing between the cluster nodes.
We have no problem configuring the public interface according to the instructions in the CCR section on Microsoft TechNet. But when we configure the default gateway on the private interface, we receive the warning message shown in Figure 1.
Figure 1 Specifying multiple default gateways on a Windows 2008 Server.
Based on this warning message, we suspect things will not work properly if we specify multiple default gateways on each node in our multisite CCR cluster. This leads us to our question: How should we configure the private network interface in this type of scenario?
A I'm glad you asked this question before proceeding, because specifying multiple default gateways on a multisite CCR cluster will cause major issues. The proper configuration requires persistent, static routes for each private interface.
To get started, make sure the public interface is listed first on the connection order list under Advanced Settings in the Network Connections control panel. Next, make sure you have specified a default gateway on the public network interface for each cluster node.
Finally, configure routes on the private interfaces so that all traffic that doesn't match the route created will use the default gateway of the public interface. Let's imagine the node 1 private interface is on subnet 192.168.100.x/24 with a network gateway at IP address 192.168.100.1. The node 2 private network interface is on subnet 192.168.200.x/24 with a network gateway at IP address 192.168.200.1. In this case you would need to create this route on node 1: ROUTE ADD 192.168.200.0 MASK 255.255.255.0 192.168.100.1 –P, and the following route on node 2: ROUTE ADD 192.168.100.0 MASK 255.255.255.0 192.168.200.1 –P.
The –P parameter specifies that the created routes are persistent and won't be cleared after a reboot.
This configuration will ensure proper networking for each interface in the cluster nodes. For even more details on how to configure the private interface when using routing between the networks, check out the blog post by my good friend Tim McMichael.
On a final note, I also recommend you configure the private network as a mixed network so that the Enable-ContinuousReplicationHostName cmdlet can be used to direct replication activity over the redundant network. For more information about this cmdlet, see How to Enable Redundant Cluster Networks for Log Shipping and Seeding on Windows Server 2003.
Q I have a question regarding the new Database Availability Group (DAG) feature in Exchange Server 2010. More specifically, my question relates to log file copying and seeding between active and passive databases. Will Exchange Server 2010 offer changes or improvements in the way log file copying and seeding occurs with Local Continuous Replication (LCR), Cluster Continuous Replication (CCR) and Standby Continuous Replication (SCR) in Exchange Server 2007?

A That is a great question. Although the asynchronous replication technology used in Exchange 2007 works quite well, that doesn't mean it can't be improved, right? I'm glad to inform you that the Exchange Product Group has made several interesting changes and improvements to the asynchronous replication technology with Exchange 2010.
In Exchange 2007, the Microsoft Exchange Replication Service copies log files to the passive database copy (LCR), passive cluster node (CCR) or SCR target over Server Message Block (SMB), which means you need to open port 445 in any firewalls between the CCR cluster nodes (typically when deploying multisite CCR clusters) and/or SCR source and targets. Those of you who work for or with a large enterprise organization know that convincing network administrators to open port 445/TCP between two datacenters a far from a trivial exercise. With the Exchange 2010 DAG feature, the asynchronous replication technology no longer relies on SMB. Exchange 2010 uses TCP/IP for log file copying and seeding and, even better, it provides the option of specifying which port you want to use for log file replication. By default, DAG uses port 64327, but you can specify another port if required. For this, use the following command:
Set-DatabaseAvailabilityGroup -identity <DAG name> -ReplicationPort <port number>
In addition, the Exchange 2010 DAG feature supports the use of encryption whereas log files in Exchange 2007 are copied over an unencrypted channel unless IPsec has been configured. More specifically, DAG leverages the encryption capabilities of Windows Server 2008—that is, DAG uses Kerberos authentication between each Mailbox server member of the respective DAG. Network encryption is a property of the DAG itself, not the DAG network. Settings for a DAG's network encryption property are: Disabled (network encryption not in use), Enabled (network encryption enabled for seeding and replication on all networks existing in a DAG), InterSubnetOnly (the default setting meaning network encryption in use on DAG networks on the same subnet), and SeedOnly (network encryption in use for seeding on all networks in a DAG). You can enable network encryption using the Set-DatabaseAvailabilityGroupcmdlet. For instance, if you wanted to enable encryption for log copying and seeding, you would execute the command:
Set-DatabaseAvailabilityGroup -identity <DAG name> -NetworkEncryption Enabled.
Finally, with Exchange 2010 DAGs you can enable compression for seeding and replication over one or more networks in a DAG. This is a property of the DAG itself, not a DAG network. The default setting is InterSubnetOnly and has the same settings available as those of the network encryption property. To enable network compression for log file copying and seeding on all networks in a DAG, use the command: Set-DatabaseAvailabilityGroup –Identity <DAG name> -NetworkCompression Enabled. To find the status of the port, encryption and compression settings for a DAG, use the Get-DatabaseAvailabilityGroup –status command as shown in Figure 2.
Figure 2 Database Availability Group network encryption, compression and replication port settings.
Q In your previous Exchange Queue & A column, you talked about a significant I/O reduction in Exchange 2010 compared to Exchange 2003 and 2007. Can you explain the specific changes and improvements the Exchange Product Group made to achieve such optimization for storage performance in Exchange 2010?
A As you mentioned, we saw a significant reduction in I/Os per second in the move from Exchange 2003 to Exchange 2007. Reductions of up to 70 percent were not uncommon. We can attribute this primarily to the use of a 64-bit architecture for Exchange 2007. As such, Exchange 2007 can access more memory and thereby use larger memory caches than its predecessor. The more data Exchange can retrieve directly from the virtual memory address space, the fewerI/Os needed against the disks in the underlying storage subsystem.
This provides much more efficient use of the existing storage system (typically an expensive Storage Area Network) or a great excuse to move to less expensive direct-attached storage. The reduced I/O requirements enable hosting of many more mailboxes (5,000-plus) per Exchange 2007 Mailbox server than was possible with Exchange 2003. In order to avoid virtual memory fragmentation, Exchange 2003 was typically limited to 4,000 mailboxes per Mailbox server. (Yes, I know this depended on type of servers, storage user profiles and Exchange infrastructure.)
The Extensible Storage Engine (ESE) has been the underlying database technology in Exchange since the first version—Exchange 4.0, released in June 1996. Until Exchange 2007 SP1, the Exchange Product Group made great efforts in tweaking and optimizing the ESE for better performance.For storage in Exchange 2010, the Exchange Product Group focused on delivering large (+10GB), fast mailboxes while taking advantage of cheap storage. Because of the ESE changes made in this version, you now have the option of using such low-performance disks as the desktop-like SATA disks (aka SATA or Tier 2 disks). Yes, I am talking about 7200 SATA disks, just like the ones in your workstation! If you use the Database Availability Group feature for high availability (three or more database copies), you can even use, say, a single 7200RPM disk storing both a database and the transaction logs instead of expensive RAID configurations.
Achieving such improvements meant changing the store schema significantly. Essentially, the Exchange Product Group wanted to move away from many, random, small I/Os to fewer, sequential, large I/Os. Moving from random to sequential I/Os required dramatic changes to the store table architecture.
In Exchange 2007 and earlier, each database had a mailbox table (stored all mailboxes in the database), folders table (stored mailbox folders for all mailboxes in the database), message table (stored messages), attachment table (stored attachments for all mailboxes in the database), and message/folder table (stored folder views for all mailboxes in the database).In this architecture, which has not changed much since Exchange 4.0, a lot of random I/Os had to perform against the database. One of the benefits with this architecture was single-instance storage (SIS) in which only one copy of a message was kept—a big advantage back when relatively small disks were par for the course. But today, with 500GB SAS and 2TB SATA disks at our disposal, this architecture no longer makes sense.
In Exchange 2010, the store schema has changed so that all data in a mailbox is stored in tables close to each other in the database. Actually, each mailbox has its own folder, message header, body and view table. So, SIS no longer exists in Exchange databases. As a side effect of removing SIS from Exchange, a database might bloat by approximately 20 percent. To solve this problem, the Exchange Product Group compressed the databases (more specifically, the message headers and text or HTML bodies). By giving each mailbox its own set of tables, I/Os performed against a database are mostly sequential.
Other interesting changes include: the database space is allocated in a contiguous manner; database contiguity is maintained over time; the database page size has been increased from 8KBto 32KB; and asynchronous read capability has been improved. The Exchange Product Groupis also working on increasing the cache effectiveness by changing the checkpoint depth to 100MB for high availability configurations, using cache compression, and database cache priority.
As a result of all the changes in Exchange 2010, you can expect up to 70 percent reduction in I/O compared to Exchange 2007.
I've only scratched the surface when it comes to storage optimizations in Exchange 2010. If you want some great insight along with all the gory details on storage improvements in Exchange 2010, I highly recommend you grab a fresh cup of coffee and watch the recording of the Tech·Ed 2009 session on Exchange 2010 Storage presented by Matt Gossage, the Exchange Product Group team member responsible for ESE database. He does a great job of explaining this complex Level 300 topic in plain English. Watch it at online (you don't need to have attended Tech·Ed to watch it).
Q We have several Exchange 2007 Cluster Continuous Replication (CCR)-based Mailbox servers deployed within our organization. The private network on all nodes has File and Printer Sharing for Microsoft Networks disabled (see Figure 3). We're sure this was recommended back when we deployed Exchange 2007.
Figure 3 File and Printer Sharing for Microsoft Networks disabled.
But this differs from the guidance provided with Exchange 2007 SP1 documentation. Now the recommendation is to enable File and Printer Sharing for Microsoft Networks on the private network interface just like it is on the public network interface. Can you explain why this guidance changed after Exchange 2007 SP1 released?
A You're correct. Prior to the release of Exchange Server 2007 SP1, disabling File and Printer Sharing for Microsoft Networks on the private network interface was recommended. But in Exchange 2007 SP1, a new feature allows you to replicate log files over multiple network interfaces, thereby making the networks redundant, plus reducing the amount of data traveling over the public network interface. In the release to manufacturing (RTM) version of Exchange 2007, all log file copying and seeding occurred over the public network interface.
On a related note, if you use Windows Server 2008-based machines, make sure to enable NetBIOS on all network interfaces that you plan to use for log file copying and seeding. If NetBIOS is disabled, the Enable-ContinuousReplicationHostNames command will fail.
The Enable-ContinuousReplicationHostNames cmdlet lets you specify which network interfaces should be used for log file copying and seeding. But bear in mind that you must change the private network to a mixed network within the Windows Failover Cluster console in order to utilize it for log file copying and seeding.
See the Exchange 2007 SP1 documentation for more information.
Q In Exchange 2007, does Microsoft have a recommendation on how to stop mailflow to and from an Exchange 2007 Mailbox server, as in the case of a virus or similar outbreak? We would like users to be able to connect to their mailboxes but not be able to send and receive e-mail messages in such circumstances.

A You can do this by stopping the Microsoft Exchange Transport service on the Exchange 2007 Hub Transport servers.
If you want to have all queued e-mail messages delivered without allowing new messages into the queue, simply pause the Microsoft Exchange Transport service.
Note that doing this at the Mailbox server level requires that you stop the Microsoft Exchange Mail Submission service on the involved Exchange 2007 Mailbox servers.
Q I have taken a close look at the new archive mailbox feature in Exchange Server 2010 and have a couple of questions. I noticed that once you enable the archiving mailbox feature for a user mailbox, it's accessible and works as expected via Outlook Web Access 2010 and Outlook 2010, but not via Outlook 2003 or 2007. Will we not be able to make use of the new archive mailbox feature before we upgrade to Outlook 2010?
Also, we want to move the archive mailbox for a respective user to another mailbox database. But as far as I can see, this is not possible. If you can't move the archive mailbox to another mailbox database, what's the benefit of the archive mailbox?

A In regard to your first question, what you see is expected behavior (even when we reach Exchange 2010 RTM). You will only be able to access an archive (aka alternate) mailbox via Outlook Web Access 2010 or Outlook 2010. Accessing this mailbox via legacy Outlook 2003 or 2007 clients is neither supported nor possible..
To address your second question, you can store the archive mailbox only in the same mailbox database as the one in which you've stored your primary mailbox. But because you can use Tier 2 disks (aka SATA desktop-like disks) for your mailbox databases and logs in Exchange 2010, moving the archive mailbox to another storage subsystem doesn't really make sense. With that said, here are some benefits of the archive mailbox feature:
You can provide larger mailboxes to the end users without impacting performance of critical path folders in the primary mailbox (primary mailbox = hot data, archive mailbox = cold data) even though the mailbox databases are stored on SATA/Tier 2 disks. You can provide large mailboxes (+10GB) without synching all that data to the user's .OST file when running in cached mode (an archive mailbox is accessible only in online mode).
The archive mailbox is a replacement for .PST files. As you already know, the archive mailbox is not only accessible via Outlook 2010, but also Outlook Web Access 2010. This means you no longer need to worry about backing up your .PST files and so on.

Henrik Walther is a Microsoft Certified Master: Exchange 2007 and Exchange MVP with more than 15 years of experience in the IT business. He works as a technology architect for Trifork Infrastructure Consulting (a Microsoft Gold Certified Partner based in Denmark) and as a technical writer for Biblioso Corp. (a U.S.-based company that specializes in managed documentation and localization services).

Fragen und Antworten zu Exchange Ein zweiter Blick auf Funktionen und Verbesserungen von Exchange 2010
Henrik Walther

In dieser Ausgabe ich fortgesetzt, wo ich in meinem letzten Artikel unterbrochen – sogar noch mehr Fragen beantworten, neue und aufregende Exchange 2010 Features bezüglich. Aber auch Platz für eine Reihe von Exchange Server 2007-Fragen.
F Wir einen Mehrfachstandort Exchange 2007 SP1-Cluster mit Cluster Continuous Replication (CCR) bereitstellen. Die zwei Clusterknoten befinden sich in separaten Datencentern. Exchange wird auf Windows Server 2008 SP2 ausgeführt, und wir die öffentlichen und privaten Schnittstellen befindet sich in verschiedenen Subnetzen in einzelnen Datencenter haben möchten. Wie Sie wissen, bedeutet dies wir routing zwischen den Clusterknoten verwenden müssen.
Wir haben kein Problem, das Konfigurieren der öffentlichen Schnittstelle nach den Anweisungen im Microsoft TechNet CCR Abschnitt. Abbildung 1 Wenn wir das Standardgateway auf der privaten Schnittstelle konfigurieren, erhalten wir die Warnmeldung angezeigt aber.
Abbildung 1 Mehrere Standardgateways auf einem Windows 2008-Server angeben.
Basierend auf dieser Warnmeldung, vermuten wir Dinge, nicht ordnungsgemäß funktioniert, wenn wir in unserer Mehrfachstandort CCR-Cluster auf jedem Knoten mehrere Standardgateways angeben. Dies führt uns zu unserem Frage: Wie sollten wir die private Netzwerkschnittstelle in diesem Szenario konfigurieren?
A Ich bin froh, dass Sie aufgefordert, diese Frage, bevor Sie fortfahren, da mehrere Standardgateways angeben, auf einem Mehrfachstandort CCR-Cluster größere Probleme verursachen. Die ordnungsgemäße Konfiguration erfordert ständige, statische Routen für jede private Schnittstelle.
Beginnen, stellen Sie sicher die öffentliche Schnittstelle ist in der Liste Reihenfolge Verbindung unter Erweiterte Einstellungen in der Systemsteuerung unter Netzwerkverbindungen zuerst aufgeführt. Im nächsten Schritt stellen Sie sicher, dass Sie ein Standardgateway auf die öffentliche Netzwerkschnittstelle für jeden Clusterknoten angegeben ist.
Konfigurieren Sie schließlich Routen auf den privaten Schnittstellen, sodass alle Datenverkehr, der die Route erstellt entspricht das Standardgateway der öffentlichen Schnittstelle verwendet wird. Angenommen, wir die Knoten 1 private Schnittstelle im Subnetz 192.168.100.x/24 mit einem Netzwerkgateway an IP-Adresse 192.168.100.1 ist. Die private Netzwerkschnittstelle Knoten 2 ist auf Subnetz-192.168.200.x/24 mit einem Netzwerkgateway an IP-Adresse 192.168.200.1. In diesem Fall müssen Sie diese Route auf Knoten 1 zu erstellen: ROUTE ADD 192.168.200.0 MASK 255.255.255.0 192.168.100.1 – p und die folgenden Routen auf Knoten 2: ROUTE ADD 192.168.100.0 MASKE 255.255.255.0 192.168.200.1 – P.
Der Parameter – p gibt, die erstellten Routen permanent sind und wird nicht nach einem Neustart deaktiviert werden.
Diese Konfiguration gewährleistet richtige Netzwerk für jede Schnittstelle in den Clusterknoten. Checken Sie den Blogbeitrag durch mein guter Freund Tim McMichael noch weitere detaillierte Informationen zum Konfigurieren der privaten Schnittstelle beim routing zwischen den Netzwerken verwenden.
Auf eine letzte Anmerkung empfehle ich auch Sie das private Netzwerk als gemischtes Netzwerk konfigurieren, sodass das Cmdlet aktivieren ContinuousReplicationHostName zum Replikationsaktivitäten über redundante Netzwerk direkt verwendet werden kann. Weitere Informationen über dieses Cmdlet finden Sie unter So aktivieren Sie auf Windows Server 2003 Redundant Cluster Netzwerke für Protokollversand und Ausgangswert.
F Habe eine Frage im Hinblick auf neue Datenbank Verfügbarkeit von (DAG) Funktion in Exchange Server 2010. Genauer gesagt, bezieht sich meine Frage auf Protokolldatei kopieren und seeding zwischen aktiven und passiven Datenbanken. Werden Exchange Server 2010 wird angeboten, Änderungen oder Verbesserungen bei der die Art der Protokolldatei kopieren und seeding mit fortlaufende lokale Replikation (Local Continuous Replication, LCR), Cluster Continuous Replication (CCR) und Standby Continuous Replication (SCR) in Exchange Server 2007 erfolgt?

A Ist eine gute Frage. Obwohl die asynchrone Replikationstechnologie in Exchange 2007 funktioniert recht gut verwendet, bedeutet nicht, es, rechts verbessert werden kann nicht? Ich bin so froh, dass Sie darüber informiert, dass der Exchange-Produktgruppe mehrere interessante Änderungen und Verbesserungen für die asynchrone Replikationstechnologie mit Exchange 2010 vorgenommen hat.
In Exchange 2007, Microsoft Exchange-Replikationsdienst Protokolldateien passiven Datenbankkopie (LCR), passiven Clusterknoten (CCR) oder SCR-Ziel über SMB (Server Message Block), d. h., müssen Sie Port 445 in allen Firewalls zwischen den CCR-Clusterknoten öffnen kopiert (i. d. r. beim Bereitstellen von Mehrfachstandort CCR Cluster) bzw. SCR-Quelle und Ziel. Diejenigen, die Arbeit für oder mit einem großen Unternehmen wissen, dass er dazu verleitet Netzwerkadministratoren zum Öffnen von Port 445/TCP zwischen zwei Rechenzentren ein weit über eine einfache Übung. Mit dem Feature Exchange 2010 DAG beruht die asynchrone Replikationstechnologie nicht mehr auf SMB. Exchange 2010 verwendet TCP/IP für die Protokolldatei kopieren und seeding, und sogar bietet die Möglichkeit, Angabe der Anschlusses für die Dateireplikation Protokoll verwendet werden soll. Standardmäßig DAG verwendet Port 64327, aber Sie können einen anderen Port angeben, wenn erforderlich. Verwenden Sie dazu den folgenden Befehl:
Set-DatabaseAvailabilityGroup -identity <DAG name> -ReplicationPort <port number>
Darüber hinaus unterstützt das Feature Exchange 2010 DAG die Verwendung der Verschlüsselung, während Protokolldateien in Exchange 2007 über einen unverschlüsselten Kanal kopiert werden, wenn IPsec für konfiguriert wurde. Genauer gesagt, nutzt DAG Verschlüsselungsfunktionen von Windows Server 2008 – DAG verwendet, Kerberos-Authentifizierung zwischen jedes Postfach-Server Mitglied der jeweiligen DAG. Netzwerk-Verschlüsselung ist eine Eigenschaft von der DAG selbst, nicht das DAG-Netzwerk. Einstellungen für eine DAG Netzwerk Verschlüsselung-Eigenschaft sind: Deaktiviert (Netzwerk Verschlüsselung nicht in Verwendung) aktiviert (Netzwerk-Verschlüsselung für seeding und Replikation auf alle Netzwerke in einem DAG aktiviert), (die Standardeinstellung Bedeutung Netzwerk Verschlüsselung verwendet auf DAG Netzwerke in demselben Subnetz) InterSubnetOnly und SeedOnly (Netzwerk Verschlüsselung für auf alle Netzwerke in einem DAG seeding verwendet). Sie können die Netzwerk-Verschlüsselung mithilfe der Set-DatabaseAvailabilityGroupcmdlet aktivieren. Wenn Sie die Verschlüsselung für Protokolldatei kopieren und seeding aktivieren möchten, würden Sie beispielsweise den Befehl ausführen:
Set-DatabaseAvailabilityGroup -identity <DAG name> -NetworkEncryption Enabled.
Schließlich können Sie mit Exchange 2010 DAGs Komprimierung für seeding und Replikation über eine oder mehrere Netzwerke in einem DAG aktivieren. Dies ist eine Eigenschaft der DAG selbst nicht in einem Netzwerk DAG. Die Standardeinstellung ist InterSubnetOnly und hat die gleichen Einstellungen wie die Verschlüsselungseigenschaft Netzwerk verfügbar. Um Netzwerk-Komprimierung für Protokolldatei kopieren und auf alle Netzwerke in einem DAG seeding zu aktivieren, verwenden Sie den Befehl: Set-DatabaseAvailabilityGroup –Identity < DAG Name >-NetworkCompression aktiviert. Um den Status des Ports suchen, verwenden Einstellungen für eine DAG Verschlüsselung und Komprimierung den Get-DatabaseAvailabilityGroup –status-Befehl, wie dargestellt im Abbildung 2.
Abbildung 2 Datenbank Verfügbarkeit Gruppe Netzwerk Verschlüsselung, Komprimierung und Replikation Anschlusseinstellungen.
F In Ihrer vorherigen Exchange Queue &Eine Spalte erläutert Sie zu einer bedeutenden Verringerung e/A in Exchange im Vergleich zu Exchange 2003 und 2007 2010. Können Sie bestimmte Änderungen und Verbesserungen der Exchange-Produktgruppe Optimierung für Speicher-Leistung in Exchange 2010 erreichen Erklären?
A Wie Sie bereits erwähnt, eine bedeutende Verringerung e/As pro Sekunde in das Verschieben von Exchange 2003 zu Exchange 2007 gesehen. Reduzierung von bis zu 70 Prozent wurden nicht ungewöhnlich. Wir können dies in erster Linie für die Verwendung einer 64-Bit-Architektur für Exchange 2007 Attribut. Als solche können Exchange 2007 mehr Speicher zugreifen und somit größerer Cachespeicher als sein Vorgänger. Je mehr Daten kann direkt aus virtueller Speicher-Adressraum, der gegen die Datenträger in das zugrunde liegende Speichersubsystem benötigt FewerI/OS Exchange abrufen.
Dies bietet viel eine effizientere Nutzung des vorhandenen Storage Systems (in der Regel eine teure Storage Area Network) oder eine hervorragende Entschuldigung um kostengünstiger Direct-attached Storage nach. Die reduzierten e/A-Anforderungen aktivieren hosting viele weitere Postfächer (5,000-plus) pro Exchange 2007-Postfachserver als mit Exchange 2003 möglich war. Um die Fragmentierung des virtuellen Speichers zu vermeiden, war Exchange 2003 in der Regel auf 4.000 Postfächer pro Postfachserver beschränkt. (Ja, weiß ich diese depended auf Art der Server, Speicherung von Benutzerprofilen und Exchange-Infrastruktur.)
ESE (Extensible Storage Engine) ist seit der ersten Version aus der zugrunde liegenden Datenbanktechnologie in Exchange – Exchange 4.0, im Juni 1996 veröffentlicht. Bis Exchange 2007 SP1 der Exchange-Produktgruppe große Anstrengungen in optimieren und Optimieren der ESE für bessere performance.For Speicher in Exchange 2010 vorgenommen, der Exchange-Produktgruppe konzentriert sich auf große (+ 10 GB) übermitteln, schnelle Postfächer beim durch Nutzung billig Speicher. Wegen der ESE-Änderungen in dieser Version vorgenommen wurden haben Sie jetzt die Möglichkeit der Verwendung solcher Datenträger geringer Leistung als die Desktop-ähnliche SATA-Datenträger (auch SATA oder Ebene 2 Datenträger). Ja, bin ich über 7200 SATA-Datenträgern, wie in Ihrer Arbeitsstation Gespräch! Wenn Sie die Datenbank Verfügbarkeit Features für hohe Verfügbarkeit (Datenbankkopien drei oder mehr) verwenden, können Sie auch, sagen, einen einzelnen 7200RPM Datenträger speichern einer Datenbank und die Transaktionsprotokolle anstatt teure RAID-Konfigurationen verwenden.
Solche Verbesserungen erreichen bedeutete Informationsspeicher Schema erheblich ändern. Im Wesentlichen sollte der Exchange-Produktgruppe viele, zufällige, kleine e/A zu weniger sequenziell, große ein-und Ausgaben verlassen. Verschieben von zufälligen zu sequenziellen e/A erforderliche Dramatische Änderungen an der Architektur des Informationsspeichers Tabelle.
In Exchange 2007 und früher, jede Datenbank eine Postfach-Tabelle (alle Postfächer in der Datenbank gespeichert wurde), Ordner Tabelle (Postfachordner für alle Postfächer in der Datenbank gespeicherten), Nachrichtentabelle (gespeicherte Nachrichten), Anlagentabelle (für alle Postfächer in der Datenbank gespeicherte Anlagen) und Nachricht-Ordner (gespeicherte Ordneransichten für alle Postfächer in der Datenbank) Tabelle .In dieser Architektur nicht viel seit Exchange 4.0, zufällige e/A viel geändert hat verfügten gegen die Datenbank durchführen. Einer der Vorteile bei dieser Architektur war Single Instance Storage (SIS), in denen nur eine Kopie der Nachricht gespeichert wurde, ein großer Vorteil zurück wenn relativ kleinen Datenträger Nennwert für den Kurs wurden. Jedoch heute mit 500 GB SAS und 2 TB SATA-Festplatten bei unserer Veräußerung dieser Architektur nicht mehr sinnvoll.
2010, Wurde in Exchange Informationsspeicher Schema geändert, so dass alle Daten in einem Postfach in Tabellen nebeneinander in der Datenbank gespeichert ist. Tatsächlich hat jedes Postfach einen eigenen Ordner, Nachrichtenkopf, Textkörper und die Ansicht. Daher ist von SIS nicht mehr im Exchange-Datenbanken vorhanden. Als Nebeneffekt SIS von Exchange zu entfernen kann eine Datenbank ca. 20 Prozent Vergrößerung. Um dieses Problem zu lösen, komprimiert der Exchange-Produktgruppe die Datenbanken (genauer gesagt, die Kopfzeilen und Text oder HTML-Nachrichtentext). Bezeichneter jedes Postfach einen eigenen Satz von Tabellen, werden e/A anhand einer Datenbank durchgeführt größtenteils sequenziell.
Weitere interessanten Änderungen sind beispielsweise: der Datenbank-Speicherplatz ist in einer zusammenhängenden Weise; reserviert.Datenbank Contiguity wird über einen Zeitraum; beibehalten.die Seitengröße der Datenbank wurde von 8KBto erhöht 32 KB;und asynchrones Lesen Funktion verbessert. Exchange-Produkt Groupis cache Komprimierung arbeiten auch erhöhen die Effektivität Cache indem Sie die Prüfpunkt-Tiefe auf 100 MB für hohe Verfügbarkeit Konfigurationen verwenden, und Datenbank Zwischenspeichern Priorität.
Als Ergebnis der alle Änderungen in Exchange 2010 können Sie bis zu 70 Prozent Verringerung e/A im Vergleich zu Exchange 2007 erwarten.
Ich habe nur oberflächlich behandelt bei der Speicherung Optimierungen im Exchange-2010. Wenn Sie einige großartige Einblicke zusammen mit den komplizierten Details auf Speicherverbesserungen in Exchange 2010 möchten, empfehle ich Sie nehmen eine frische Tasse Kaffee, und beobachten Sie die Aufzeichnung der TechEd 2009 Sitzung auf dem Exchange 2010 Speicher präsentiert von Matt Gossage, das Exchange-Produktgruppe Teammitglied für ESE-Datenbank verantwortlich. Er führt eine hervorragende Auftrag von diesem komplexe Thema Level 300 in einfachem Englisch erläutert. Überwachen Sie es online (müssen Sie nicht TechEd es überwacht teilgenommen haben).
F Wir haben verschiedene Exchange 2007 Cluster Continuous Replication, CCR-basierten Postfachservern innerhalb unserer Organisation bereitgestellt. Das private Netzwerk auf allen Knoten Datei- und Druckerfreigabe für Microsoft-Netzwerke deaktiviert (siehe Abbildung 3). Wir sind sicher, dass dies empfohlen wurde, zurück, wenn wir Exchange 2007 bereitgestellt.
Abbildung 3 Datei und Druckerfreigabe für Microsoft-Netzwerke deaktiviert.
Aber dies unterscheidet sich von der Anleitungen mit Exchange 2007 SP1-Dokumentation. Jetzt wird empfohlen, aktivieren die Datei und Druckerfreigabe für Microsoft-Netzwerke auf der privaten Netzwerkschnittstelle genauso wie auf die öffentliche Netzwerkschnittstelle. Können Sie erklären, warum dieser Anleitung geändert, nachdem Exchange 2007 SP1 veröffentlicht?
A Können Sie richtig. Der Exchange Server 2007 SP1 Version wurde Deaktivieren von Datei- und Druckerfreigabe für Microsoft-Netzwerke auf der privaten Netzwerkschnittstelle empfohlen vor. Aber in Exchange 2007 SP1 ein neues Feature ermöglicht Ihnen Protokolldateien über mehrere Netzwerkschnittstellen und somit die Netzwerke redundant machen, plus Verringern der Menge von Daten über die öffentliche Netzwerkschnittstelle unterwegs zu replizieren. In der Release to manufacturing Version (RTM) von Exchange 2007 aufgetreten alle Protokolldatei kopieren und seeding über die öffentliche Netzwerkschnittstelle.
Ein zugehöriger Hinweis Wenn Sie Windows Server 2008-basierten Computern verwenden, stellen Sie sicher auf, NetBIOS auf allen Netzwerkschnittstellen zu aktivieren, die Sie für die Protokolldatei kopieren und seeding verwenden möchten. Wenn NetBIOS deaktiviert ist, wird der Befehl aktivieren ContinuousReplicationHostNames fehlschlagen.
Das Cmdlet aktivieren-ContinuousReplicationHostNames ermöglicht die Angabe die Netzwerkschnittstellen für die Protokolldatei kopieren und seeding verwendet werden soll. Aber Bären Denken Sie daran, dass Sie mit einem gemischten Netzwerk innerhalb der Windows-Failovercluster-Verwaltungskonsole im private Netzwerk ändern müssen, um es für Protokolldatei verwenden kopieren und seeding.
Exchange 2007 SP1-Dokumentation für Weitere Informationen angezeigt.
Verfügt In Exchange 2007, Microsoft eine Empfehlung zum Beenden der Mailflow in und aus einer Exchange 2007-Postfachserver, wie im Fall eines Virus oder ähnliche Ausbruch? Wir möchten Benutzer eine Verbindung zu ihren Postfächern herstellen, aber nicht senden und empfangen e-Mail-Nachrichten in solchen Fällen werden können.

A Sie dies tun können, durch Beenden von Microsoft Exchange-Transportdienst auf Exchange 2007-Hub-Transport-Servern.
Bei alle in der Warteschlange e-Mail-Nachrichten ohne neue Nachrichten in die Warteschlange übermittelt werden soll, unterbrechen Sie einfach den Microsoft Exchange-Transportdienst.
Beachten Sie, dass dies auf der Serverebene Postfach erfordert, dass Sie den Dienst Microsoft Exchange e-Mail-Übertragung auf die beteiligten Exchange 2007-Postfachservern beenden.
F Ich eine Close ergriffen haben das neue Archiv Postfach-Feature in Exchange Server 2010 betrachten und eine Reihe von Fragen haben. Ich bemerkt, nachdem Sie die Archivierung Postfach-Funktion für ein Benutzerpostfach aktiviert haben, es zugegriffen werden kann und funktioniert wie erwartet über Outlook Web Access 2010 und Outlook 2010, aber nicht über Outlook 2003 oder 2007. Wir werden keine damit das neue Archiv Postfach Feature verwenden, bevor wir auf Outlook 2010 aktualisieren?
Darüber hinaus möchten wir das Archiv Postfach für einen entsprechenden Benutzer zu einer anderen Postfachdatenbank verschieben. Soweit ich sehen können, dies ist jedoch nicht möglich. Wenn Sie im Archivpostfach in eine andere Postfachdatenbank verschieben nicht möglich, was ist die Vorteile der Archivpostfach?

A In Bezug auf die erste Frage, was Sie sehen eine ist erwartete Verhalten (selbst wenn wir Exchange 2010 RTM erreicht). Nur werden ein Archiv (auch alternative) Postfach über Outlook Web Access 2010 oder Outlook 2010 zugreifen. Der Zugriff auf dieses Postfach über ältere Outlook 2003 oder 2007-Clients ist weder unterstützt noch möglich
Um Ihre zweite Frage zu beheben, können Sie die Archivpostfach nur in der gleichen Postfachdatenbank wie das Speichern in denen Sie Ihr primäre Postfach gespeichert haben. Aber da Sie Ebene 2 Platten (auch SATA Desktop wie Festplatten) für die Postfach-Datenbanken und Protokolle in Exchange 2010 verwenden können, verschieben das Archivpostfach auf einem anderen Speicher-Subsystem nicht wirklich sinnvoll. Mit dem bezeichnet sind hier einige Vorteile der Funktion Postfach archivieren:
Sie können die Endbenutzer größere Postfächer bereitstellen, ohne Auswirkungen auf die Leistung des kritischen Weges Ordner in das primäre Postfach (primäre Postfach = hot Daten, Archivpostfach = cold Daten), obwohl die Postfachdatenbanken auf SATA-Ebene 2 Festplatten gespeichert werden. Sie können große Postfächer (+ 10 GB) bereitstellen, ohne alle Daten des Benutzers OST-Datei synchronisieren, bei Ausführung im zwischengespeicherten Modus (ein Archivpostfach ist nur im Onlinemodus zugänglich).
Das Archivpostfach ist ein Ersatz für PST-Dateien. Wie Sie bereits wissen, ist das Archivpostfach nicht nur über Outlook 2010, sondern auch Outlook Web Access 2010. Dies bedeutet, Sie nicht mehr Gedanken Sichern Ihrer PST-Dateien usw. müssen.

Henrik Walther ist eine Microsoft Certified Master: Exchange 2007 und Exchange-MVP mit mehr als 15 Jahren Erfahrung im IT-Bereich. Er arbeitet als eine Technologie Architekt für Trifork Infrastruktur Consulting (ein Microsoft Gold Certified Partner Sitz in Dänemark) und als Autor technischer für Biblioso Corp. (ein US-Unternehmen spezialisiert hat verwaltete Dokumentations-und Lokalisierungsdienste).

Page view tracker