You cannot afford for it to fail. It needs to be available constantly and you have to make sure that all emails held on the server do not get lost through hardware failure. It is very common to run Exchange Server across more than one physical server. This is not just for capacity issues, but as a safety guard against failure and maintenance downtime.
A standard set up for Exchange Server uses at least two nodes. This configuration enables two servers to be live simultaneously. You can have up to eight nodes is an Exchange Server cluster. There are four failover services available with Exchange Server. The options available to you will depend on your version of the email server system. If you have Exchange Server , you will also have installed Service Pack 1.
These are:. As a general rule of thumb, if you are able to run your cluster nodes on separate sites for protection against environmental damage, then opt for SCR. If you have a simple, single site implementation, then SCC will be good enough. As far as clustering services are concerned, the DAG is state-of-the-art. It will replicate your mailbox databases and manage failover automatically.
The client and server software elements of a corporate email system are not sold as a single system. This configuration enables a degree of flexibility when choosing interface software to serve the users of the email system. Over the years of its operation, the functionality of Exchange Server has expanded to enable interoperability with a wider range of clients.
This enables you to use:. This group of client options includes:. An email protocol designed for mobile users, called Outlook Mobile Access, gives access to both mobile apps and web-based clients, including:. This gives you many other options when shopping around for email clients, including the addition of open email protocols which has expanded the client options open to businesses that use Microsoft Exchange.
This is the universal email system and all email servers connected to the internet can communicate through its messaging standards. Exchange Server is only available for the Microsoft Server platform. Although that limits your choice of server operating system, this restriction does have advantages. Many of the tools needed to support Exchange Server are built into Windows Server, so installing the Exchange Server software is a very straightforward task.
If you buy the very latest version, which currently is Exchange Server , your operating system options are restricted even further because this version of Exchange Server will only install on Windows Server Apart from the tasks of downloading the installation file and running it, you have a few things to sort out when you create an Exchange Server implementation.
If you have multiple mailbox databases on one disk, you need to have some spare space for processing. Microsoft recommends that you add one to the number of databases that you want to house on the disk.
So, if you want to fit two databases on your disk, divide the spare capacity by three. If you have multiple site resilient datacenter pairs in your environment, you'll need to decide if you want to have a single worldwide namespace, or if you want to control the traffic to each specific datacenter by using regional namespaces. Your decision depends on your network topology and the associated cost with using an unbound model; for example, if you have datacenters located in North America and South Africa, the network link between these regions might not only be costly, but it might also have high latency, which can introduce user pain and operational issues.
In that case, it makes sense to deploy a bound model with a separate namespace for each region. However, options like geographical DNS offer you the ability to deploy a single unified namespace, even when you have costly network links; geo-DNS allows you to have your users directed to the closest datacenter based on their client's IP address. To achieve a highly available and site resilient architecture, you must have two or more datacenters that are well connected ideally, you want a low round-trip network latency, otherwise replication and the client experience are adversely affected.
In addition, the datacenters should be connected via redundant network paths supplied by different operating carriers. While we support stretching an Active Directory site across multiple datacenters, for the PA we recommend that each datacenter be its own Active Directory site.
There are two reasons:. Active Directory has published guidance that states that subnets should be placed in different Active Directory sites when the round-trip latency is greater than 10 ms between the subnets.
In the PA, all servers are physical servers and use locally attached storage. Physical hardware is deployed rather than virtualized hardware for two reasons:.
Virtualization comes with a slight performance penalty and adding an additional layer of management and complexity, which introduces additional recovery modes that do not add value, particularly since Exchange Server natively provides the same functionality.
Its important to note even though we've increased the allowed processor and memory capacity in Exchange Server the Exchange Server PG's recommendation remains to scale out rather than up.
Scaling out vs up means we would much rather see you deploy a larger number of servers with slightly less resources per server rather than a smaller number of dense servers using maximum resources and populated with large numbers of mailboxes. By locating a reasonable number of mailboxes within a server, you lessen the impact of any planned or unplanned outage and reduce the risk of discovering other system bottlenecks.
An increase in system resources shouldn't result in the assumption you'll see linear performance gains in Exchange Server using the maximum allowed resources when comparing it to Exchange 's maximum allowed resources. Each new version of Exchange brings new processes and updates that in turn make it difficult to compare a current version to prior version. Follow any and all sizing guidance from Microsoft when determining your server design. Additional drive bays may be directly attached per-server depending on the number of mailboxes, mailbox size, and the server's resource scalability.
Be aware some hardware storage controllers may require each disk to each be configured as a single-disk RAID0 group for write caching to be utilized.
Consult with your hardware manufacturer to confirm the proper configuration for your system that guarantees write-cache will be used. New to the Exchange Server PA is the recommendation of having two classes of storage for everything not already located on the RAID1 disk pair previously mentioned. This storage class contains Exchange Server database files and Exchange Server transaction log files.
These disks are large capacity 7. To ensure the capacity and IO of each disk is used as efficiently as possible, up to four database copies are deployed per-disk. The normal run-time copy layout ensures that there's no more than a single active database copy per disk. At least one disk in the traditional storage disk pool is reserved as a hot spare.
AutoReseed is enabled and quickly restores database redundancy after a disk failure by activating the hot spare and initiating database copy reseeds. These solid-state drives may come in different form factors such as but not limited to traditional 2.
For example, if a single server was expected to hold 28 TB of mailbox database files on traditional storage, then an additional 1. Traditional and solid-state disks should be deployed in a ratio where possible. For every three traditional disks within the server a single solid-state disk will be deployed and hold the MCDBs for all DBs within the three associated traditional disks. This recommendation limits the failure domain a solid-state drive failure can impose on a system.
Limiting the number of database failovers reduce the chance of impacting users if many more databases were sharing a smaller number of solid-state drives. If there is a solid-state drive failure Exchange High Availability service, will attempt to mount the affected databases on different DAG nodes where a healthy MCDB for each affected database still exists. If for some reason no healthy MCDBs exist for one of the affected databases, then Exchange High Availability services will leave the local affected database copy running without the performance benefits of the MCDB.
For example, if a customer were to deploy a system capable of holding 20 drives it may have a layout like the following. In the example above, we have TB of Exchange database storage and 7. BitLocker is used to encrypt each disk, thereby providing data encryption at rest and mitigating concerns around data theft or disk replacement.
Within each site resilient datacenter pair, you'll have one or more DAGs. Releases of. NET Framework that aren't listed in the table below aren't supported on any release of Exchange This includes minor and patch-level releases of. NET Framework. The complete prerequisite list for Exchange is available here.
Otherwise, Outlook and will not work on Windows 7. If you're integrating Lync presence and instant messaging with Exchange Server, Lync Server Cumulative Update 10 or later is required. The following table lists the scenarios in which coexistence between Exchange and earlier versions of Exchange is supported. For more information about specific hybrid deployments, see Hybrid Deployment Prerequisites.
The following table lists the requirements for the network and the directory servers in your Exchange organization. If Exchange is deployed in this configuration, and the network supports IPv4 and IPv6, all Exchange servers can send data to and receive data from devices, servers, and clients that use IPv6 addresses.
Directory server architecture for Exchange The use of bit Active Directory domain controllers increases directory service performance for Exchange In multi-domain environments, on Windows Server domain controllers that have the Active Directory language locale set to Japanese ja-jp , your servers may not receive some attributes that are stored on an object during inbound replication.
For more information, see KB For security and performance reasons, we recommend that you install Exchange only on member servers and not on Active Directory directory servers. To learn about the issues you can face when installing Exchange on a directory server, see Installing Exchange on a domain controller is not recommended [WarningInstallExchangeRolesOnDomainController]. After Exchange is installed, changing its role from a member server to a directory server, or vice versa, isn't supported.
Note : Intel Itanium IA64 processors are not supported. For more information, see Sizing Exchange Deployments. Edge Transport : 4 GB minimum. At least MB of free space on the System drive. Content indexing files. The Windows Server Desktop Experience feature needs to be installed. To install Exchange , you need to do one of the following steps to install the Desktop Experience on Windows Server prior to starting Exchange Setup:.
If a computer is running Windows Server Core mode and you want to install Exchange on it, you'll need to reinstall the operating system and choose the Desktop Experience installation option. Exchange only supports the version of Windows Management Framework that's built in to the release of Windows that you're installing Exchange on. Don't install versions of Windows Management Framework that are made available as stand-alone downloads on servers running Exchange. Software that you want to install on an Exchange server needs to be designed to run on the same computer as Exchange Server.
We strongly recommend that you use the latest version of. NET Framework that aren't listed in the table below are not supported on any release of Exchange For older versions, see Exchange Server supportability matrix.
Exchange Server offers several well-known protocols, and publishes APIs that third-party vendors often write clients for. Microsoft makes no warranties, expressed or implied, as to the overall suitability, fitness, compatibility, or security of clients that are created by third-party developers.
If you want to use a third-party client that uses our protocols or APIs, we recommend that you thoroughly review and test all considerations functionality, security, maintenance, management, and so on before you deploy the client in the enterprise workspace. We also recommend that you make sure that the third-party vendor offers an appropriate Enterprise Support Agreement ESA.
0コメント