Executive Summary

The Exchange Messaging team within Microsoft Information Technology (Microsoft IT) started the production rollout of Microsoft® Exchange Server 2007 at full scale in July 2006 using the beta 2 version of the product. For more than a year prior to this event, the Exchange Messaging team had deployed Exchange Server 2007 in the pre-release production environment to help the Exchange Server product group evaluate enterprise readiness.

The first server installation took place in the pre-release production environment in February 2005, more than 22 months before the product shipped. To put this time frame into perspective, Microsoft Exchange 2000 Server pre-release verification started three weeks before the release to manufacturing (RTM) date and the Microsoft Exchange Server 2003 pre-release verification period was only six months. This shows how strong the relationship between the Exchange Server Product group and the Exchange Messaging team has grown over recent years. In fact, the Exchange Server Product group does not ship product versions or service packs now until the Exchange Messaging team signs off on the enterprise readiness. To demonstrate the enterprise readiness of the new Exchange Server version to customers, the Exchange Messaging team committed to perform the transition of the entire corporate production mailbox environment prior to the official RTM date. The team only had five months to finish the deployment in a large enterprise messaging environment with demanding power users.

The Exchange Messaging team deployed 61 Mailbox servers, 6 Edge Transport servers, 14 Hub Transport servers, 11 Unified Messaging (UM) servers with supporting Voice over Internet Protocol (VoIP) gateways, and 30 Client Access servers. The Mailbox servers correspond to 122 server computers because all Mailbox servers are clustered systems based on Cluster Continuous Replication (CCR) to ensure high availability. There are 130,000 mailboxes in the corporate production environment, which means that during the production rollout, the Exchange Messaging team moved between 1,000 and 1,500 mailboxes per server from Exchange Server 2003 to Exchange Server 2007 every day, including weekends. In this fast-paced project, checklists represented an essential deployment tool.

A deployment checklist is a catalog or a structured document with detailed instructions outlining individual installation and configuration tasks to ensure deployment success. The guiding principle is part of every Exchange Server 2007 deployment because the Setup program includes readiness checks to guide administrators through a number of assessment steps prior to the actual server installation. These readiness checks proactively cover the most typical issues to help customers deploy Exchange Server 2007 successfully. In addition, IT organizations can benefit from explicit checklists to coordinate and account for all deployment steps and to apply them consistently.

This technical white paper discusses the deployment checklists that the Exchange Messaging team created based on the Exchange Server 2007 architecture and design specifications for the corporate production environment.

The first two sections briefly reiterate the reasons why the Exchange Messaging team uses checklists, and the sections explain the Microsoft IT server life-cycle management process. These sections also discuss the usefulness of checklists from a decision maker's point of view and highlight the responsibilities of the Exchange Messaging team within the overall Microsoft IT organization.

The third section, "Pre-Installation Deployment Checklists," covers the tasks the Exchange Messaging team performs to prepare servers for later installation of a specific server role. In some cases, a server role requires additional configuration. These tasks are role-specific and are listed in checklist form.

The next sections provide detailed discussions of the various checklists that the Exchange Messaging team created for the individual server roles.

This technical white paper also includes an appendix titled "Deployment Worksheets," which contains a set of worksheet templates that are derived from the Exchange Messaging team checklists. These worksheet templates can serve as a starting point to create custom checklists based on the specific needs of an IT organization.

This technical white paper contains information for technical decision makers and IT implementers who are planning to deploy Exchange Server 2007. This paper assumes that the audience is already familiar with the concepts of Windows Server® 2003 operating system, the Active Directory® directory service, and previous versions of Exchange Server. A high-level understanding of the new features and technologies that are included in Exchange Server 2007 is also helpful. Detailed product information is available in the Microsoft Exchange Server 2007 Technical Library at http://www.microsoft.com/technet/prodtechnol/exchange/2007/library/default.mspx.

Introduction

The Exchange Messaging team uses checklists for three important reasons:

• They help the team to verify the architecture and design specifications
• They outline the deployment steps in detail
• They serve reporting purposes

The Systems Engineering group within the Exchange Messaging team creates the architecture and design specifications for the messaging environment, which the systems engineers validate in an engineering lab that closely mirrors the server configurations in the production environment, yet without production users. After the systems engineers finalize the specifications, the Systems Management group within the Exchange Messaging team takes over to produce build documents and deployment checklists based on the chosen architectures and designs.

Especially during the first server installations in the corporate production environment, the Systems Engineering group and the Systems Management group collaborate very closely. The Systems Management group reviews the design specifications for acceptance and implementation, performs representative server installations with the help of the Systems Engineering group, and creates the checklists that precisely outline the installation process.

The checklists also enable the Systems Management group to manage individual assignments within the deployment project and to track progress. The Exchange Messaging team not only uses the checklists to carry out installation and configuration tasks, it also uses the checklists to document the work that is performed. In this way, the checklists are an important project management tool.

The deployment checklists provide the Exchange Messaging team with the following benefits:

• Strong project management. The Exchange Messaging team manages projects based on the Microsoft Solutions Framework (MSF). To meet the goal of completing the deployment within project constraints, the project manager uses checklists to track progress, coordinate resources, and manage the overall budget.
• Clear communication processes. According to the MSF team model, individual team members communicate with the project manager. The project manager then communicates progress to the project sponsor and other stakeholders. Checklists facilitate these communication processes because they are a tool to report progress.
• Improved IT staff productivity. Deploying Exchange Server 2007 is a team effort, and checklists help to coordinate the team's activities. Checklists also help to ensure reliable and consistent task completion.
• Reduced deployment risks. Checklists are a means to identify potential issues during the first server deployments and to avoid these issues in all subsequent installations. When operators deploy servers in the corporate production environment based on the checklists, they get it right the first time because all installation steps are tested and proven.
• Accelerated deployment progress. Less deployment risk directly translates into accelerated deployment progress because the team spends less time troubleshooting installation issues. In the event of an installation problem, such as a hardware configuration issue, the checklists provide the necessary guidelines and contact information to resolve issues.

Exchange Server Deployment Process

Across the entire IT organization, Microsoft IT provisions approximately 200 servers each month. Accordingly, Microsoft prefers to purchase hardware in bulk, requesting bids from multiple vendors for the entire order volume to get the best price. This process can take from 30 through 60 days to install an ordered server in a data center. Only in urgent cases does Microsoft order directly from a supplier, accepting additional expenses of from 6 through 8 percent to shorten the procurement process.

The Exchange Messaging team has implemented the following process to design and deploy computers for Exchange Server 2007 in the data centers:

1. Server design. The Exchange Systems Engineering group creates the architectures and designs for all Exchange Server–related components and technologies. This work includes the server designs, which the systems engineers define based on a list of approved hardware components that the Hardware Engineering team maintains. For each individual server type, the systems engineers create stock keeping unit (SKU) documents that precisely outline the hardware and storage configuration.
   
   The SKU document is a Microsoft Office Excel® workbook. On separate worksheets, the SKU document lists the hardware parts, memory configuration, physical disk arrangement, and logical storage configuration. By default, SKU documents expire after six months, yet systems engineers can extend this time or update the designs to keep pace with evolving hardware technologies. The Exchange Messaging team maintains the SKU documents in a document library based on Microsoft Office SharePoint® Server 2007.

   Note: The typical Microsoft IT server procurement process makes use of a standard server configuration, which for most servers is a dual-core x64 system with 4 gigabytes (GB) of memory and two 146 GB disks. This is a utility server, designed to be integrated into a storage area network (SAN). Microsoft teams that need a file server or database server can order this system without having to specify a custom design. Minor modifications are possible, such as additional processors or memory, yet substantial engineering exceptions, such as those required for Exchange Server 2007, go beyond the scope of the standard configuration.

2. Server ordering. The Exchange Program Management team is responsible for managing the server deployments. For each server role, an individual program manager works with stakeholders to determine business and technical requirements, organize the necessary resources, and guide the project to completion. It is the task of the Exchange Program Management team to order new server hardware for deployment in the data centers. To order a new server, the Exchange Program Management team informs a release manager in the Infrastructure Management team, who then places a server order. The server order includes a link to the corresponding SKU document with the hardware configuration details.
3. Lifecycle management. Within Microsoft IT, the Infrastructure Management team is responsible for managing the entire server life cycle. This team coordinates the server provisioning processes and maintains an internal line-of-business (LOB) application, called the Microsoft Service Enterprise Change Tracking tool, to keep track of the servers as they are purchased, moved between data centers, or decommissioned. For new server orders, the release manager creates an ordering ticket in the change-tracking tool. The ordering ticket includes among other information an internal order number to track expenses against budgets, the name of the approving manager, and a link to the SKU document.
4. Functional approval and right-sizing processes. Before the order reaches the hardware-purchasing desk, the ordering ticket goes through functional approval and right-sizing processes in the Data Center Operations group to ensure that the server hardware is properly designed for the intended purposes. The Data Center Operations group maintains all production servers worldwide, including physical hardware and operating systems. A data center manager verifies the order ticket to ensure that the purchase is justified and that rack space is available in the data center to accommodate the new server.
5. Hardware purchasing. Upon approval through the Data Center Operations group, the order reaches the hardware purchasing desk, which generates a purchasing order within an internal LOB application, called MS Market. MS Market notifies a group manager in the Exchange Messaging team for final approval.
6. Order and delivery confirmation. Approved purchase orders reach the vendor, who informs the Microsoft release manager through e-mail about the exact costs of the ordered server and the shipping date. MS Market only provides estimated information regarding the costs. To help the Exchange Program Management team track exact expenses, the release manager updates the cost information on the order ticket with the actual amount that the vendor communicated. The release manager also handles data center–related configurations, such as registering the new server in the IT configuration (IT config) database. IT config is an internal configuration management solution to track details about each server in the data centers, including server name, SKU, and other configuration information.
7. Hardware and operating system installation. The Data Center Operations group uses the IT configuration and SKU information to verify that the delivered hardware is correct. The group mounts the hardware in the data center; configures the disks and partitions the storage as outlined in the SKU document; connects the new server to the network; installs the operating system, including all relevant updates; adds the new server to the appropriate domain; and deploys any required management software. The Exchange Messaging team uses the Standard Server Platform, which is a standard server configuration that includes required service updates for applications and operating systems, plus other Microsoft and third-party services or tools that are necessary to manage servers in an enterprise environment. Following the installation of the operating system and relevant updates through the Standard Server Platform, a second engineer from the Data Center Operations group verifies the system configuration, and then informs the backup team to start configuring the backup solution.
8. Exchange Server 2007 installation. Up to this point, the Exchange Messaging team has not yet modified the server configuration. When the Data Center Operations group marks the server installation as completed, the release manager informs the program manager, who originally ordered the hardware, that the new server is ready for the Exchange Messaging team to continue the server installation process. The program manager, in turn, informs the Exchange Systems Management team to perform the installation of Exchange Server 2007 and the latest security updates. All Exchange Server administrators are located in Redmond, Washington. The Exchange Systems Management team performs the Exchange Server 2007 deployment remotely, by using a remote desktop connection.

Pre-Installation Deployment Checklist

Prior to performing the configuration tasks that are unique to each server role, the Exchange Messaging team prepares servers by installing prerequisite components, making initial configuration changes, and generally ensuring that servers are ready for installation of a specific server role. For each server, the Exchange Messaging team follows a pre- installation checklist that includes the following items:

1. Verify general server configuration. In a large-scale deployment with different teams acquiring and installing the server hardware, it is important to check that the general server configuration matches the Exchange Server 2007 requirements prior to installing a server role. For example, the Exchange Messaging team checks CPU, memory, network adapters, disk configuration, and drive letter assignments, as documented in SKUs. The Exchange Messaging team runs a custom script to verify that the server configuration matches SKU specifications.

   Note: The Microsoft IT Showcase Note on IT "Going 64-bit with Microsoft Exchange Server 2007" (http://www.microsoft.com/technet/itshowcase/exchange.mspx) provides detailed information about the hardware configuration that the Exchange Messaging team selected for each server type.

2. Configure the page file size. According to product recommendations, the page file size on the C drive must be set to "total" amount of physical memory, plus 10 megabytes (MB). For example, for servers with 8 GB of memory, the Exchange Messaging team sets the size of the page file to 8,192 MB (8 GB + 10 MB).
3. Verify installation of current service pack. In addition to installing Windows Server 2003 or Windows Server 2003 R2, the Exchange Messaging team installs the latest service pack for Windows Server as a best practice. To verify the service pack version, the Exchange Messaging team engineers log on to the server, click Start, click Run, and then type Winver.

   Note: The Exchange Messaging team uses the srvinfo tool from the Windows Server 2003 Resource Kit to collect information about the service pack level.

4. Configure a static IP address. According to product documentation, Exchange servers must be configured with a static IP address, subnet mask, and default gateway. In addition, because Exchange Server 2007 is heavily dependent on Domain Name System (DNS) functioning correctly, at least one valid DNS address and valid DNS suffix must be specified. When configuring these network settings, the Exchange Messaging team also verifies that both the network interface card (NIC) and the switch are enabled for full duplex communication.
5. Verify domain and site. The Exchange Messaging team checks each server to verify that the server is in the proper domain and site by entering the following commands in a Command Prompt window: NLTEST /parentdomain and NLTEST /dsgetsite. This step is critical to ensure proper Hub Transport routing.

   Note: The NLTEST tool is included in the Windows Server 2003 Support tools package on the Windows Server 2003 media.

6. Verify security and organizational unit (OU) membership. After obtaining the proper security groups that are developed during the permissions and administration model design for the environment, the Exchange Messaging team adds security groups as members of the local administrators group on the Exchange Server. Additionally, the Exchange Messaging team verifies that the server is in the correct OU within the Messaging path by checking the path in Active Directory Users and Computers.
7. Verify installation of .NET Framework version 2.0. According to the Exchange Server 2007 requirements, Microsoft .NET Framework version 2.0 must be installed on the server. Microsoft .NET Framework version 2.0 Redistributable Package can be downloaded at the following URL: http://www.microsoft.com/downloads/details.aspx?familyid=B44A0000-ACF8-4FA1-AFFB-40E78D788B00&displaylang=en. When .NET Framework version 2.0 is installed, the hotfix that is mentioned in Microsoft Knowledge Base (KB) article 924895 must also be applied.

   Note: When using Windows Server 2003 R2, Microsoft .NET Framework version 2.0 can be installed via Add/Remove Windows Components.

8. Verify installation of Microsoft Management Console (MMC) 3.0. Because the Exchange Server 2007 Management Console relies on features that are specific to MMC 3.0, MMC 3.0 must be installed on the server. To verify the installation of MMC 3.0, Exchange Messaging team engineers click Start, click Run, and then type MMC.exe. In the MMC window, they click Help, and then click About. If MMC 3.0 has not been installed, you can download the required update at the following URL: http://support.microsoft.com/kb/907265.

   Note: When using Windows Server 2003 R2, MMC 3.0 is installed by default.

9. Install Windows PowerShell 1.0. Both the Exchange Server 2007 Management Console and the Exchange Management Shell make extensive use of Windows PowerShell, therefore Windows PowerShell must be installed on the server. You can download Windows PowerShell from the following URL: http://www.microsoft.com/downloads/details.aspx?familyid=22E607F4-F854-497F-9548-770477E4B71D&displaylang=en.
10. Configure antivirus. To help protect the operating system, the Exchange Messaging team uses an operating system antivirus solution that is configured through a script to ensure that the antivirus program does not scan the Exchange extensions and directories. After installing Exchange Server 2007, the Exchange Messaging team installs, configures, and optimizes Microsoft Forefront Security for Exchange Server on Edge Transport and Hub Transport servers to ensure messaging-level antivirus protection.
11. Verify installation of regional code pages.  The Exchange Messaging team verifies the installation of all regional code pages in Windows in order to eliminate any potential language issues with non-U.S. clients. Team members accomplish this verification by clicking Start, clicking Control Panel, clicking Regional and Language Options, and then verifying that all code page check boxes have been selected under the Advanced and Language tabs.
12. Install Internet Information Services (IIS) snap-in. In order for the Exchange Management Console to work properly, the IIS snap-in should be installed on the Mailbox, Client Access, Hub, and UM servers. For Mailbox and Client Access servers, the Exchange Messaging team installs IIS with the World Wide Web Publishing Service, whereas for Hub and UM servers the Exchange Messaging team installs IIS without the World Wide Web Service.
13. Verify installation of mandatory security updates. The Exchange Messaging team verifies that no mandatory post-SP2 security updates are still needed by using Microsoft Windows Update or Windows Server Update Services (WSUS). For more information about the required hotfixes per role, see the Exchange Server TechNet Library at http://technet.microsoft.com/en-us/library/aa996719.aspx.
14. Enable monitoring. The Exchange Messaging team uses Microsoft Operations Manager to monitor Exchange servers. Correspondingly, all Exchange servers are enabled for Microsoft Operations Manager monitoring. To avoid false alerts, the Exchange Messaging Team enables monitoring after placing each server in the production environment.

Hub Transport Server Checklist

The installation checklist that the Exchange Messaging team developed for Hub Transport server deployment includes the following items:

1. Verify that the Network News Transport Protocol (NNTP) and Simple Mail Transfer Protocol (SMTP) services are not installed. According to product requirements, the NNTP and SMTP services must not be installed on the server. The NNTP service has been discontinued with Exchange Server 2007 and the product now includes its own SMTP transport stack. This means Exchange Server 2007 is no longer dependent on the Windows SMTP component.
2. Install the Hub Transport role by using Unattended Setup. Although the new Exchange Server 2007 Installation wizard substantially simplifies the steps necessary to install Exchange Server 2007, the Exchange Messaging team installed each of the 12 Hub Transport servers that are deployed at Microsoft by using Unattended Setup through the following command:

   Setup.com /m:install /r:h /targetdir:<drive\installation path> /DoNotStartTransport

   According to Exchange partitioning best practices, the Exchange Messaging team installs the operating system and Exchange Server 2007 binaries on separate partitions. This setup increases performance and reduces the data that have to be recovered, for example, during a disk failure.

   Note: The /DoNotStartTransport parameter ensures that the Microsoft Exchange Transport Service is not started after the Hub Transport server role has been installed. This makes sure the server does not accept e-mail messages, so any additional configuration settings can be performed.

   Delete the default Receive connectors. The Exchange Messaging team deletes the two default Receive connectors that are created during the installation of the Exchange 2007 Hub Transport server role. To delete the default Receive connectors, the Exchange Messaging team opens the Exchange Management Shell by clicking Start, clicking All Programs, clicking Microsoft Exchange, clicking Exchange Management Shell, and then runs the Get-ReceiveConnector -server <server name> cmdlet to obtain the list of connectors. This procedure produces an output similar to the following.
   
   Identity                Bindings       Enabled
   --------                --------    -------
   <server name>\Default <server name> {0.0.0.0:25} True
   <server name>\Client <server name> {0.0.0.0:587} True
   
   To delete the two Receive connectors, Exchange Messaging team members run the following command. It should be noted that if this command is improperly formed, the command can remove all Receive connectors in the Exchange organization. Exercise extreme care when executing this command.

   Get-ReceiveConnector -server <server name> | Remove-ReceiveConnector

3. Create new Receive connector by using custom Windows PowerShell script. With the two default Receive connectors deleted, the Exchange Messaging team runs a custom Windows PowerShell script, which creates a new Receive connector with values similar to those in Table 1, and configures the server settings of the Hub Transport server with the values that are listed in Table 2.

   Table 1. Receive Connector Configuration

   Object property name	Value
   AuthMechanism	ExchangeServer
   Bindings	0.0.0.0:25
   FQDN	Server FQDN
   MaxInboundConnection	5000
   MaxMessagesPerConnection	50
   MaxRecipientsPerMessage	10000
   MaxHopCount	30
   PermissionGroups	ExchangeServers, ExchangeLegacyServers
   RemoteIPRanges	{0.0.0.0-255.255.255.255}
   ProtocolLoggingLevel	Verbose

    

   Table 2. Hub Transport Server Configuration

   Object property name	Value
   MessageTrackingLogEnabled	$true
   MessageTracjingLogSubjectLoggingEnabled	$true
   MaxOutboundConnections	1000
   MessageTrackingLogMaxAge	10:00:00:00
   MessageTrackingLogMaxDirectorySize	150 GB
   MessageTrackingLogMaxFileSize	100 MB
   MaxPerDomainOutboundConnections	50
   ReceiveProtocolLogMaxAge	30:00:00:00 (Default)
   ReceiveProtocolLogMaxDirectorySize	15 GB
   ReceiveProtocolLogMaxFileSize	100 MB
   SendProtocolLogMaxAge	30:00:00:00 (Default)
   SendProtocolLogMaxDirectorySize	15 GB
   SendProtocolLogMaxFileSize	100 MB
   ExternalDsnReportingAuthority	domain.com
   ExternalPostmasterAddress	postmaster@domain.com
   InternalPostmasterAddress	postmaster@domain.com
   OutboundProtocolLoggingLevel	Verbose
   TotalQueuedMessagesEnableDehydration	Default
   PickupDirectoryMaxRecipientsPerMessage	10000

4. Change the location for the transaction logs. The Hub Transport servers deployed across Microsoft handle approximately 2.5 million messages per day. To achieve optimal performance on the Hub Transport servers, the Exchange Messaging team moved the queue database transaction log files to a separate partition. The Exchange Messaging team accomplished moving the transaction logs in conjunction with using the /DonotstartTransport flag. Because the transport services do not start, the services do not create the log files or database.

   In case the logs need to be moved later, the Exchange Messaging team first stops the MSExchangeTransport service by running Stop MSExchangeTransport in the Exchange Management Shell. Then, the team copies the trnxxxx.log and *jrs files from C:\Program Files\Exchange Server\TransportRoles\data\queue to the new location on the other partition, and then opens the EdgeTransport.exe.config file located in C:\Program Files\Exchange Server\bin. In EdgeTransport.exe.config, Exchange Messaging team members change the following key under <appSettings> so that the key refers to the new path:
   
   <add key="QueueDatabaseLoggingPath" value = "C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue" />
   
   After changing the path, the Exchange Messaging team saves the file, and then starts the MSExchangeTransport service again by running the Start MSExchangeTransport command in the Exchange Management Shell. Additionally, the Exchange Messaging team grants the BuiltIn\Network Service account read and write permissions to the new transaction log directory because the permissions are not granted by default.

5. Verify mail flow. When a Mailbox server has been deployed in the same Active Directory site as the respective Hub Transport server, the Exchange Messaging team tests the mail flow by running the Test-MailFlow command. The team also completes the following tests:

   A.     Create a new test mailbox on the Mailbox server.

   B.     Send a few sample messages from a couple of test mailboxes to a few recipients located on other Mailbox servers in the corporate production environment.

   C.    Verify successful delivery of the e-mail messages.

   D.    Send a few sample e-mail messages from test mailboxes to Internet e-mail addresses and verify successful delivery.

Edge Transport Server Checklist

In the perimeter network, the Extranet Services team manages the underlying network and related configuration, whereas the Exchange Messaging team manages the Edge Transport servers. The Exchange Messaging team developed an installation checklist to ensure the completion of all required steps. The installation checklist that the Exchange Messaging team developed for Edge Transport server deployment includes the following items:

1. Verify the Edge Transport servers are deployed in the perimeter network and are not part of an internal Active Directory domain. The Exchange Server 2007 Edge Transport server is the only server role that must be deployed in the perimeter network, not on the internal network like the rest of the Exchange 2007 server roles. The Exchange Messaging team installs the Edge Transport role in the external Active Directory domain to facilitate administration and monitoring.
2. Configure DNS suffix. The DNS suffix must be created on the server before the Edge Transport server role is installed. To create the DNS suffix, the Exchange Messaging team engineers click Start, click Control Panel, and then double-click System to open the System Properties. Then, they click the Computer Name tab, and then Change. On the Computer Name Changes page, the engineers click More. In the Primary DNS suffix of this computer field, they type a DNS domain name and suffix for the server, and then click OK three times.
3. Install the Edge Transport server role using Unattended Setup. The Exchange Messaging team installed each of the six Edge Transport servers by using Unattended Setup. To install the Edge Transport server role by using Unattended Setup, open a Command Prompt window, navigate to the share or media that contains your Exchange Server 2007 Setup files, and then run the following command:

   Setup.com /m:install /r:e /targetdir:<drive\installation <path>/DoNotStartTransport

   The Exchange Messaging team uses the /DoNotStartTransport flag while installing the Edge Transport server role in order to stop the Edge Transport server after the server is installed. This procedure prevents the server from accepting e-mail messages in the Active Directory site before the Exchange Messaging team completes configuring the server.

4. Subscribe the Edge Transport server. The Exchange Messaging team subscribes an Edge Transport server by creating an Edge subscription XML file on the Edge Transport server through the following command:

   New-EdgeSubscription -Filename <path to XML File> -CreateInternetSendConnector $false -CreateInboundSendConnector $false

   Next, the Exchange Messaging team transfers the XML file to a Hub Transport server in the organization and imports the XML file by running the following command:
   
   

   New-EdgeSubscription -FileName <Path to local XML file> -CreateInternetSendConnector $false -CreateInboundSendConnector $false -Site <local AD Site>

5. Deleting the default Receive connector. The Exchange Messaging team deletes the default Receive connectors that are created during the installation of the Exchange 2007 Edge Transport server role by first retrieving the current Receive connectors, and then deleting them.
6. Create a new Receive connector by using a custom PowerShell script. With the two default Receive connectors deleted, the Exchange Messaging team runs a custom PowerShell script, which creates new Receive connectors with values similar to those in Table 3, and configures the server settings of the Edge Transport server with the values listed in Table 4.

Table 3. Receive Connector Configuration

Table 4. Edge Transport Server Configuration

Mailbox Server Checklist

The Exchange Messaging team deployed Cluster Continuous Replication (CCR)-based Mailbox servers in the production environment, which included installing and configuring Exchange Server 2007 on both active and passive nodes. The installation checklist that the Exchange Messaging team developed for Mailbox server deployment includes the following items:

1. Gather prerequisites. Before installing clustered Mailbox servers, the Exchange Messaging team gathers prerequisite details, such as the location of the share where the Exchange Server 2007 installation file is located, as well as the name and IP address of the clustered Mailbox server on which to install the CCR Mailbox server.
2. Install clustering services. Next, the Exchange Messaging team installs Windows Clustering.
3. Set specific cluster settings. The Exchange Messaging team configures two settings on the clustered servers, one for the cluster log size and one to disable event log replication, as follows. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment] "ClusterLogSize"="32" C:\Documents and Settings\cluster /cluster: /prop EnableEventLogReplication=0
4. Enable and configure Majority Node Set (MNS) quorum with file share witness. After deploying Cluster Service, the Exchange Messaging team changes the quorum to a MNS and sets a private property on the majority node set to access a file share. This procedure is accomplished through the cluster res “Majority Node Set” /priv MNSFileShare=\\Servername\Directory command.
5. Install the Mailbox server role on the active node. To install the Mailbox server role first on the active node, the Exchange Messaging team uses the Exchange 2007 graphical user interface (GUI) setup, selects Custom Exchange Server Installation on the Installation Type screen, and checks Active Clustered Mailbox Role on the Server Role Selection screen. The setup requests the server name and IP address, which the team retrieved in Step 1.
6. Install the Mailbox server role on the passive node. The passive node installation is similar to the active server node installation. The Exchange Messaging team uses the Exchange 2007 setup GUI, selects Custom Exchange Server Installation on the Installation Type screen, and selects Passive Clustered Mailbox Role on the Server Role Selection screen. The setup requests the server name and IP address, which the team retrieved in Step 1.
7. Delete the first storage group and mailbox database. When the Mailbox server role is installed, the Exchange Messaging team deletes the first storage group and mailbox database, in preparation for creating multiple storage groups and mailbox databases by using a custom PowerShell script. To delete the Mailbox database, open the Exchange Management Shell and run the following command:

   Remove-MailboxDatabase -Identity "Mailbox Database"

   To delete the Storage group, run the following command:

   Remove-storagegroup -Identity "First Storage group"

8. Create storage groups and mailbox databases. The Exchange Messaging team uses a custom PowerShell script to create storage groups and mailbox databases. The Exchange Messaging team has three different types of Mailbox servers, each with its own hardware specifications. The number of mailboxes that are to be stored on a particular Mailbox server depends on the Mailbox server type. The Exchange Messaging team creates either 28 or 42 storage groups (with 1 Mailbox database per storage group) on a Mailbox server. The storage groups point to a Public Folder database on a dedicated Public Folder server. The settings for a Mailbox server and the Mailbox databases created on a Mailbox server type two, are listed in Table 5 and Table 6.

   Note: For more information about the three different Mailbox server types that the Exchange Messaging team uses, see the Microsoft IT Showcase Note on IT "Going 64-bit with Microsoft Exchange Server 2007" at http://www.microsoft.com/technet/itshowcase/exchange.mspx.

   Table 5. Mailbox Database Settings on Mailbox Server Type Two

   Object property name	Value
   IssueWarningQuota	1700 MB
   ProhibitSendReceiveQuota	2090 MB
   ProhibitSendQuota	1900 MB
   DeletedItemRetention	14.00:00:00
   MailboxRetention	30.00:00:00

    

   Table 6. Mailbox Server Settings on Mailbox Server Type Two

   Object property name	Value
   ManagedFolderAssistantSchedule	"Sun.6:00 PM-Sun.8:00 PM," "Mon.6:00 PM-Mon.8:00 PM," "Tue.6:00 PM-Tue.8:00 PM," "Wed.6:00 PM-Wed.8:00 PM," "Thu.6:00 PM-Thu.8:00 PM," "Fri.6:00 PM-Fri.8:00 PM," "Sat.6:00 PM-Sat.8:00 PM."
   MessageTrackingLogEnabled	True
   MessageTrackingLogMaxAge	10.00:00:00
   MessageTrackingLogMaxDirectorySize	3 GB
   MessageTrackingLogMaxFileSize	10 MB
   MessageTrackingLogSubjectLoggingEnabled	True
   RetentionLogForManagedFoldersEnabled	True
   JournalingLogForManagedFoldersEnabled	True
   FolderLogForManagedFoldersEnabled	True
   SubjectLogForManagedFoldersEnabled	True
   LogFileAgeLimitForManagedFolders	7.00:00:00
   LogDirectorySizeLimitForManagedFolders	1 GB
   LogFileSizeLimitForManagedFolders	10 MB
   AutoDatabaseMountDial	BestAvailability

9. Create test mailboxes and verify mailbox functionality. The Exchange Messaging team creates test mailboxes and verifies that the mailbox can be accessed by using the different mail clients, such as Microsoft Office Outlook®, Microsoft Office Outlook Web Access, and Exchange ActiveSync®.
10. Verify mail flow. The Exchange Messaging team also verifies that the test mailboxes can send e-mail messages to other users on the Mailbox server in the same Active Directory site, in other Active Directory sites in the Active Directory forest, and to and from Internet hosts, and that the process works as expected.
11. Configure backup and Microsoft Operations Manager. As a last step, Microsoft configures the server for backups and enables Microsoft Operations Manager clients to monitor the server.

Client Access Server Checklist

The installation checklists that the Exchange Messaging team developed for Client Access server deployments include the following items:

1. Install RPC over HTTP Proxy component. Microsoft users have the option of connecting to their mailboxes using Outlook Anywhere directly over the Internet, without the need to establish a secure virtual private network (VPN) connection. Outlook Anywhere relies on the Windows Server 2003 RPC