Datasheet
EXCHANGE SERVER ARCHITECTURE 13
Customers are often reluctant to deploy unified messaging solutions due to the complexity,
administrative overhead, schema changes, client-side deployment requirements, and cost.
Microsoft is determined to make their unified messaging implementation less expensive than
competing products and much better integrated w ith Active Directory.
When the Exchange 2010 Unified Messaging role is integrated with an IP-based phone
system or a PBX with an IP/PBX gateway, the following additional functions may be
possible:
◆ Inbound voicemail is delivered directly to the user’s mailbox.
◆ Users can call in to the phone system to have their email read to them, to listen to t heir
schedule, or to move appointments around on their schedule and notify attendees.
◆ Users can call in to the phone system to look up users from the Global Address List.
Unified Messaging Message Sizes
A typical voicemail uses the default MP3 between 2 KB and 3 KB per second of message time,
but this amount can be changed. The Exchange Server 2010 Unified Messaging server supports
the MP3, WMA, G.711 PCM, and GSM codecs. However, with higher-quality recordings come
larger message sizes.
Improved High-Availability Features
One of the biggest enemies of h igh availability is slow restoration times. As mailbox databases
get larger and larger, restore times get longer and longer. Often this is used as a rationale for
limiting user’s mailbox sizes to less than what they need to do their jobs effectively.
As mentioned earlier, when Microsoft released Exchange Server 2007, they introduced a
new technology called continuous replication. This technology allowed Microsoft to introduce
three new features to improve high availability: the Local Continuous Replication (LCR), Clus-
ter Continuous Replication (CCR), and Standby Continuous Replication (SCR) features. These
features allowed a database to be initially seeded with another copy and then the log files to
be replicated in near real time and replayed to the copy of the database. The database copy
could then be restored quickly (in the case of LCR) or brought online in the event of a server
failure.
Exchange 2007 CCR leveraged Windows Failover Clustering so that in the event of a
server failure the server could automatically be recovered. SCR was used so that even a single
database failure could be recovered by being brought online (manually) on a remote Exchange
server. CCR was designed as a high-availability solution, whereas SCR was designed to
provide resiliency.
Exchange Server 2010 has taken the continuous replication and clustering technologies even
further so that the lines between high availability and resiliency have been blurred. Windows
Failover Clustering is now used much differently than it was in the past and the complexities
of clustering are better hidden from the Exchange Server administrator. The Exchange 2010
high-availability technology is easy to incorporate with existing Exchange 2010 Mailbox servers.
Individual databases can now be replicated to multiple servers, and failover can automatically
occur, not at the server level but at the database level.
Exchange 2010 makes building a failover cluster so much simpler than with past versions
that the technology will be easy to implement even for small organizations with no clustering
expertise.