Solutions provider takeaway: From Edge Transport to Unified Messaging, this chapter excerpt will provide you with information on Exchange Server 2010 server roles and why they're important to your customer's environment. You will also learn Exchange Server 2010's prerequisites, including the implementation of Windows PowerShell V2, and high availability in Exchange Server 2010. Installing an Exchange Server is like taking a hike through the woods. If you have a map and can accurately follow the directions, you can quickly and safely arrive at your destination. If you get lost in the process (or try to "wing it") you may or may NOT reach your destination, but even if you do, it is likely that you will take a lot longer and travel over more challenging roads.
To those who have worked with Exchange Server 2007 in the past, the Exchange Server 2010 Installation Wizard will seem very familiar. The Wizard walks the administrator through the installation of several of the prerequisites and allows for the selection of specific server roles for deployment. However, the installation wizard does not cover all twists and turns. There are steps that must be taken to prepare the Active Directory environment and steps that must be taken to prepare the underlying operating system on the server you are installing on.
This chapter will focus on the installation process for a new Microsoft Exchange Server 2010 server in a typical configuration. In addition, this chapter assumes that the supporting infrastructure and server operating system do not exist and includes step-by-step instructions on how to install Windows Server 2008, Active Directory, supporting configuration settings, and the Exchange Server 2010 prerequisites from scratch.
Understanding the Exchange Server 2010 Server Roles
As with Exchange Server 2007, Exchange Server 2010 has various roles that can be installed on the server to perform specific functions. There are five major server roles, most of which are modular and can reside on a single server (for small environments) or be distributed to multiple servers throughout an organization.
The roles are as follows:
- Edge Transport server role
- Client Access server role
- Hub Transport server role
- Mailbox server role
- Unified Messaging server role
Edge Transport Server Role -- Establishing Perimeter Security
The Edge Transport server role provides antivirus and antispam message protection for the Exchange Server infrastructure. Edge Transport servers act as message hygiene gateways and are designed to reside in a perimeter network or demilitarized zone (DMZ). This allows them to block harmful traffic before it reaches the corporate network.
Edge Transport servers are often utilized as the SMTP gateway for sending and receiving mail to and from the Internet.
For more information on the Edge Transport server role and details on how to install and configure the role, review Chapter 8, "Implementing Edge Services for an Exchange Server 2010 Environment."
Client Access Server Role -- Providing User Connectivity
As its name suggests, a client access server is responsible for providing connectivity between the user community and their data. Like the front-end servers found in Exchange Server 2003, client access servers manage connectivity via Outlook Web Access and ActiveSync, and like the client access servers in Exchange Server 2007, they also manage connectivity from POP and IMAP users.
In Exchange Server 2010, however, the client access servers also manage MAPI (such as Outlook) client connectivity. In a pure Exchange Server 2010 environment, clients never have to connect directly to their mailbox servers -- all connectivity is to the client access server.
By taking responsibility for managing these additional connections, client access servers allow Mailbox servers to focus on their primary role -- processing messaging requests.
For more information on the Client Access server role and details on how to install and configure the role, review Chapter 17, "Implementing Client Access and Hub Transport Servers."
Hub Transport Servers -- Routing the Mail
The Hub Transport server role is responsible for moving mail between Exchange Mailbox servers, similar to how bridgehead servers worked in the past. This role can be configured on a dedicated server or it can be deployed on an existing mailbox server.
A Hub Transport server must be deployed in each Active Directory site that contains an Exchange Server 2010 Mailbox server, as all message routing in other sites goes through one or more Hub Transport servers.
Even if the sender and recipient are on the same Mailbox server, the message will route through a local Hub Transport server. This ensures that all messages are subject to any transport rules that may be configured for the environment.
For more information on the Hub Transport server role and details on how to install and configure the role, review Chapter 17.
Unified Messaging Servers -- Combining All the Data
The Unified Messaging server role was introduced with Exchange Server 2007. It acts as a gateway for combining email, voice, and fax data into a single mailbox. All this data can be accessed via the mailbox or a telephone.
For more information on the Unified Messaging server and detailed steps on installing and configuring the role, refer to Chapter 24, "Designing and Configuring Unified Messaging in Exchange Server 2010."
Mailbox Servers -- What It's All About
The Mailbox server role is the core role within Exchange Server 2010. Without mailbox servers to store the user data, all of the other server roles would be without purpose.
The Mailbox servers host mailboxes and mail enabled objects such as contacts and distribution lists.
Understanding the Prerequisites for Exchange Server 2010
Before installing Exchange Server 2010, the administrator should become familiar with the prerequisites for each of the server roles. This section covers the prerequisites for the implementation of Exchange Server 2010 in a Windows networking environment.
Active Directory Infrastructure
Exchange Server 2010 relies on an Active Directory infrastructure to do its job. AD Sites and Services, DNS, Global Catalog Servers, Domain Controllers -- all must be in place and configured properly for Exchange Server to function well.
The importance of each of these services, and the steps to deploy them, will be explained in greater detail later in the chapter.
Windows Server 2008 -- 64-Bit All the Way
From inception through Exchange Server 2003, Exchange Server was always a 32-bit application. While this technology was able to handle the needs of organizations in the past, organizations today have more demanding messaging requirements.
In a world with ever-increasing message traffic, the need for highly available systems that allow access from multiple client technologies, through the Internet, and through continuous synchronization with wireless devices resulted in the desire for increased productivity through increased performance.
To address these growing needs, Microsoft released a 64-bit version of their Exchange Server 2007 server for production environments. While they still produced a 32-bit version of the product, it was intended primarily for non-production environments.
With Exchange Server 2010, 32-bit support has gone away, and the product is only being released in a 64-bit version.
By utilizing 64-bit architecture, Exchange Server has significantly enhanced processor and memory utilization. This ensures higher performance gains, the ability to handle an ever-increasing volume of messages, the capability of supporting more users per server, and more simultaneously connected mail clients. This last item is critical as more and more organizations take advantage of the capabilities of Outlook Web App (OWA) and ActiveSync.
The Exchange Server 2010 application can only be installed on a 64-bit edition of the Windows Server 2008 Service Pack 2 (or later) operating system. Either the standard or enterprise edition of Windows Server can be utilized; however, if you plan on taking advantage of some of the more advanced features of Exchange Server 2010 (such as database availability groups and mailbox database copies) you must use the Enterprise edition.
Note:
The Exchange Server 2010 management tools can be installed on a 64-bit edition of the Windows Server 2008 Service Pack 2 (or later) operating system, or on the Windows Vista Service Pack 2 (or later) operating system.
Microsoft .NET Framework 3.5
The Microsoft .NET Framework is a Microsoft Windows component that allows the ability to build, deploy, and run Web Services and other applications. The .NET framework is a key offering from Microsoft, and most new applications created for the Windows platform rely on it in one way or another.
.Net Framework 3.5 builds on the features added in previous releases and includes service packs for both .NET Framework 2.0 and .NET Framework 3.0. Additionally, there are a number of new features which have been added.
Windows Server 2008 ships with .NET Framework 3.0 already installed. However, Exchange Server 2010 requires .NET Framework 3.5 or above. When applying updates to the Windows Server 2008 server, if you elect to apply all updates the latest version of .NET Framework will be installed. If you elect to selectively install updates, make sure you install this update.
Windows Remote Management 2.0
The Exchange Management Shell is a command line interface that enables you to manage your Microsoft Exchange organization without having to rely on a GUI interface.
The Windows Remote Management (WinRM) 2.0 is the transport mechanism that enables your local version of Windows PowerShell to connect to remote Exchange servers, whether that server is in the next rack or across the country. Utilizing WinRM 2.0, administrators can manage servers, devices, and applications throughout their organization from a single management server.
Windows Remote Management 2.0 can be downloaded and installed from the Internet, and instructions on how to do so are included later in this chapter.
Windows PowerShell V2
Administrators who are familiar with Exchange Server 2007 have most likely had some experience with Windows PowerShell. For many, the implementation of PowerShell addressed one of the most glaring shortcomings of older Windows installations -- the lack of a usable command line interface for performing administrative tasks.
PowerShell is an extensible command-line shell and scripting language from Microsoft that integrates with the .NET Framework to allow administrators to perform just about any task in an Exchange environment from a command line. From simple to complex, scripts can be written using the PowerShell scripting language to save administrators from time consuming and repetitive tasks.
While some have found the PowerShell scripting language to be difficult to learn and challenging to implement, few who have seen the results of this product being put into action can complain about the results.
Windows PowerShell V2 introduces several new features to PowerShell 1.0 that extend its capabilities including:
- PowerShell Remoting -- Allows scripts and cmdlets to be executed on a remote machine, or several remote machines
- Windows PowerShell Integrated Scripting Environment (ISE) -- GUI-based PowerShell host that provides an integrated debugger, syntax highlighting, tab completion, and up to eight PowerShell consoles.
- Script Debugging -- Allows breakpoints to be set in a PowerShell script or function.
- Eventing -- Allows listening, forwarding, and acting on management and system events.
Windows PowerShell V2 can be downloaded and installed from the Internet, and instructions on how to do so are included later in this chapter.
Microsoft Management Console 3.0
The Microsoft Management Console (MMC) was originally released back in 1996 with the Windows NT 4.0 Option Pack. This was the first time Microsoft released a consistent and integrated management tool that aimed at standardizing the way administrators conducted administrative and operational tasks on Microsoft software. Since 1996, Microsoft has been updating and improving its management console and releasing new versions.
The Exchange Server 2010 Management Console utilizes MMC 3.0, but as Windows Server 2008 ships with the product already installed, it is not listed as a prerequisite and you do not have to install it separately.
Internet Information Services (IIS) 7.0
Internet Information Services (IIS) remains a critical component that allows users to connect to Exchange services over the Internet using Outlook Web App (OWA), Outlook Mobile Access (OMA) and ActiveSync.
As with the MMC above, IIS 7.0 is installed by default with Windows Server 2008.
Understanding High Availability and Site Resilience in Exchange Server 2010
In Exchange Server 2007, Microsoft introduced new technologies that allowed organizations to deploy their Exchange environments with improved availability. Known as "Continuous Replication," this technology was offered in three flavors -- Local Continuous Replication (LCR), Cluster Continuous Replication (CCR), and Standby Continuous Replication (SCR).
Although these options were a significant improvement over previous technologies, organizations found that the technologies were challenging to implement, as they required a significant amount of time and experience to deploy. This was largely due to the fact that some parts of the technology were owned by the Windows operating system, and some parts were owned by Exchange Server.
Exchange Server 2010 has built on these technologies and combined the on-site data replication features of CCR with the off-site data replication features of SCR. This combination of technologies is known as a database availability group (DAG). This architecture is designed to provide recovery from disk-level, server-level and site-level failures.
A few characteristics of Mailbox Database copies follow:
- Designed for mailbox databases only. Public folder replication is still the preferred method of redundancy and high availability for public folders.
- Up to 16 copies of a mailbox database can be created on multiple servers.
- Mailbox servers in a DAG can host other Exchange Server roles (Client Access, Hub Transport, and Unified Messaging).
- Exchange Server 2010 mailbox databases can only be replicated to other Exchange Server 2010 servers within a DAG. You cannot replicate a database outside of the DAG, or to an Exchange Server 2007 server.
Installing Exchange Server 2010
Exchange Server 2010 server roles, prerequisites, high availability
Exchange Server 2010 requirements: Hardware, Active Directory
Exchange Server 2010 role-based access control
Printed with permission from Sams Publishing. Copyright 2009. Exchange Server 2010 Unleashed by Rand Morimoto, Michael Noel, Chris Amaris, Andrew Abbate and Mark Weinhardt. For more information about this title and other similar books, please visit Sams Publishing.
:- State-wise Jobs or Qualification-wise Jobs 
