Exchange Queue & AAligning Disk Partitions, Planning for SCR, and More
Henrik Walther
Q I'm currently planning a migration from Exchange Server 2003 to a new Exchange Server 2007 organization. To replicate public folders to the new organization, I plan to use the Microsoft® Inter-Organization Replication (IORepl) tool. But I've heard IORepl isn't supported with an Exchange 2007 target server and you instead must introduce an Exchange 2003 server into the target Exchange organization.
A Although there have been rumors that replicating free/busy data or public folders between an Exchange 2003 organization and a pure Exchange 2007 organization is not supported, this isn't true. In fact, using IORepl on a server that has the Exchange 2007 management tools installed without any other Exchange 2007 server roles is fully supported. Bear in mind, though, that you must install the Microsoft Exchange Server Messaging Application Programming Interface (MAPI) Client and Collaboration Data Objects (CDO) on the server as well, since these are no longer provided as a part of the base product installation.
Q I'm doing an Exchange Server 2007 design for a large organization that consists of 150,000 seats, and I need to calculate the number of Global Catalog servers required by the Exchange 2007 messaging infrastructure. Can you help?
A Of course! That's exactly why this column exists in the first place. First, it's important to understand that you calculate how many Global Catalog servers (or, more specifically, how many cores—and we're not talking about processors here) are required based on the total number of Exchange 2007 Mailbox server cores you plan to use. Note that you calculate the number of Global Catalog server cores based only on Mailbox servers; you don't include the other Exchange 2007 server roles—Client Access, Hub Transport, Unified Messaging, or Edge Transport. Although the other Exchange 2007 server roles influence the number of Global Catalog servers required, the number of Mailbox servers that are deployed impact the other Exchange 2007 server roles, which means you can calculate the required number of Global Catalog servers based on the number of Mailbox servers.
In addition, the number of Global Catalog cores depends on whether you're using 32-bit- or 64-bit-based domain controllers in the Active Directory® infrastructure. With 32-bit domain controllers, you use a 4:1 ratio, meaning that you should plan to have 1 Global Catalog core per 4 Mailbox server cores. With 64-bit domain controllers, the ratio is 8:1. So, for instance, if you're deploying Exchange 2007 Mailbox servers with 8 cores installed and use 64-bit domain controllers, you would need 1 Global Catalog server per Exchange 2007 Mailbox server. Finally, when using 64-bit domain controllers, make sure you install enough memory so that the entire Active Directory database (NTDS.DIT file) can be cached in memory.
Q The previous answer explains the recommendations regarding the number of Global Catalog servers per Exchange 2007 Mailbox server. How do I figure out the number of Exchange 2007 Hub Transport and Client Access server roles that should be deployed?
A As the preceding answer suggests, the number of Exchange 2007 Client Access as well as Hub Transport servers (or, more specifically, server cores) you should deploy is tied to the number of Mailbox server cores. There's no definitive rule, but the rule of thumb is 1 Client Access server core per 4 Mailbox server cores (4:1 ratio) and 1 Hub Transport server core per 7 Mailbox server cores (7:1). The latter is for Hub Transport servers without antivirus scanning installed. With an antivirus scanning product such as Forefront Security for Exchange installed, the ratio is generally closer to 1 Hub Transport server core per 5 Mailbox server cores (5:1 ratio).
Q I've heard that installing more than 8 processor cores in an Exchange 2007 server is not recommended. Is this true, and, if so, why?
A Yes, this is true. Although Exchange Server 2007 benefits significantly from installing multicore processors, the maximum number of cores you should install in an Exchange 2007 server is 8. More specifically, only 2 Exchange 2007 server roles can in fact benefit from using extra cores—up to 8—and these are the Hub Transport and Mailbox server roles. And this is only for extremely busy Exchange 2007 servers handling millions of messages per day and storing many thousands of mailboxes.
The Exchange Product group has actually done testing with 12 processor cores installed in an Exchange 2007 Mailbox server and saw negative store performance and scalability. They also observed that Remote Procedure Call (RPC) Average Latency doubled when going from 8 to 16 cores.
Unless you expect extraordinarily busy Mailbox servers, 4 processor cores are typically sufficient enough. For additional information and processor considerations for the other Exchange 2007 server roles, see technet.microsoft.com/aa998874.
Q We are currently doing a cross-forest migration from an Exchange 2000 and Exchange 2003 organization to a new Exchange 2007 organization. However, when we try to move a mailbox from the source forest to the target forest using the Move-Mailbox cmdlet with the -SourceMailboxCleanupOptions DeleteSourceMailbox parameter specified, the following error appears:
"Though the mailbox has been moved to the target Exchange server and removed from the source Exchange server, an error occurred when deleting mailbox attributes from the source mailbox user. Domain Controller 'file01' Operating System version is 5.0 (2195) Service Pack 4. The minimum version required is 5.2 (3790) Service Pack 1."
A Windows Server® 2003-based domain controller (which is also a Global Catalog server) exists in the source forest, but it doesn't seem like you can specify which domain controller in the source forest should be used, as the –DomainController parameter can only specify a domain controller or Global Catalog server in the target forest. Is this correct? If so, is there a workaround?
A That is correct. You cannot specify a domain controller or Global Catalog server from the source forest as part of the Move-Mailbox cmdlet; the domain controller (Global Catalog server) will be picked randomly. There are a couple of workarounds, but none of them are particularly pretty. The first is to decommission any Windows® 2000-based domain controllers from the source forest, but I know this often isn't an option. The second workaround might be useful in your situation. The Move-Mailbox cmdlet needs to use a domain controller that also acts as a Global Catalog server, which means you may be able to resolve the issue by removing the Global Catalog server role from any Windows 2000 servers in the source forest. I have used this method with success in a couple of migration scenarios, so it's definitely worth a try.
Q Is it possible to install an Exchange 2007 Client Access, Hub Transport, or Mailbox server in 1 Active Directory site such as the United States, and then ship the server to another Active Directory site, such as Denmark? If this is supported, would the Exchange 2007 server then discover the new Active Directory site membership automatically or would you need to intervene manually?
A Yes, this scenario is fully supported and doesn't require any manual intervention. The Net Logon (NetLogon) and the Microsoft Exchange Active Directory Topology (MSExchangeADTopology) services take care of the site membership for an Exchange 2007 server. If the server changes site membership, the MSExchangeADTopology service automatically updates the server's site attribute known as the msExchServerSite attribute. As Figure 1 shows, you can see the msExchServerSite attribute through the use of a tool such as ADSIEdit.
Figure 1 Viewing the msExchServerSite attribute (Click the image for a larger view)
If you want to dig deeper into how Exchange 2007 and Active Directory sites relate to each other, I highly recommend you take a look at the section of the Exchange 2007 documentation called "Understanding Active Directory Site-Based Routing" at technet.microsoft.com/aa998825.
Q On an Exchange 2007 Mailbox server with Local Continuous Replication (LCR) enabled for the mailbox databases, can you use Microsoft Data Protection Manager 2007 (DPM 2007) to back up the mailbox data via the passive mailbox database copy?
A Although you can use DPM 2007 to back up mailbox databases via the passive node in an Exchange 2007 Clustered Continuous Replication (CCR) environment, this is not supported when dealing with mailbox database copies in an Exchange 2007 LCR environment.
Q You can port an Exchange Server 2007 Clustered Mailbox Server (CMS) database to a standalone mailbox server, but is it possible for you to mount a non-clustered database on a CCR or Single Copy Cluster (SCC)-based Exchange 2007 CMS?
A Since an Exchange Server 2007 Information store is unaware of the type of server it lives on, mounting a non-clustered database on a CCR- or SCC-based CMS is fully supported.
Q According to the article available at technet.microsoft.com/bb508861, the Exchange Server Quota Message Service (QMS) is not supported on a clustered Exchange 2003 server. However, I was wondering whether this service will be supported in the future for Exchange 2003 or for Exchange 2007 clustered environments?
A The Exchange Server QMS tool will not be supported on Exchange 2003 CMSs in the future. Furthermore, the QMS tool isn't supported with clustered (or, for that matter, non-clustered) Exchange 2007 Mailbox servers. But if you use Exchange 2007 in your organization, there's really no reason to install the QMS tool, as the same functionality is included natively in Exchange. For more information about how you manage quota messages in Exchange 2007, see technet.microsoft.com/bb232089.
Q Are you aware of any available reference documentation that lists the attributes that are set on Active Directory users and/or group objects when these entities are, respectively, mailbox- or mail-enabled?
A The Split Permissions Model Reference in the Exchange 2007 documentation lists these attributes. You can find this article at technet.microsoft.com/bb430782.
Q Is there any way to designate an Exchange 2007 Hub Transport server as a Bridgehead server for internal mail flow in our Exchange 2007 messaging infrastructure? The idea would be, for example, that all mail sent from Active Directory site 1 to Active Directory site 2 would be routed via Hub Transport Server A (located in Active Directory site 1) to Hub Transport server B (located in Active Directory site 2) and vice versa. Will this work?
A No, it won't. For this to work, the Mailbox server at the Active Directory sites would need to know whether the recipients were located in a different Active Directory site. The Exchange 2007 Mailbox server role doesn't have such a mechanism built in.
Unless the Hub Transport server is installed locally on a Mailbox server, the Mailbox server will always load balance connections between the Hub Transport servers in the same Active Directory site. (If the Hub Transport server role is installed on the Mailbox server, the Hub Transport server on the same physical box as the Mailbox server is always preferred.)
Only after categorization will Exchange 2007 know where the recipient's mailbox is located. The closest you can get to accomplishing this goal is to use the SubmissionServerOverrideList parameter with the Set-MailboxServer cmdlet to create a static list of Hub Transport servers that a Mailbox server should use, as shown in Figure 2 (see technet.microsoft.com/bb232193).
Figure 2 Mailbox server settings (Click the image for a larger view)
This means that if you specified either Hub Transport server A or B, the Mailbox server would always use that Hub Transport server, not only for messages sent to recipients at a specific site but for all Active Directory sites as well as for local message delivery. Since this, in theory, would introduce a single point of failure, I would advise against using such an approach.
Q I'm planning to install Exchange Server 2007 SP1 Mailbox servers on Windows Server 2008, and I'm wondering about disk alignment. I know that with either Exchange Server 2003 or Exchange Server 2007 installed on servers running Windows Server 2003, the recommendation was to create partitions to hold the transaction log files and Mailbox stores using the diskpart tool in order to improve overall performance. Aligning the storage partition according to vendor recommendations was also advised. If the storage vendor didn't have any recommendations, Microsoft best practice suggested using a value of 64KB.
When installing Exchange 2007 Mailbox servers on Windows Server 2008, how should I configure disk alignments? Do the same rules apply?
A Guess what? With Windows Server 2008, you no longer need to track-align the disk partitions that will store the Exchange Server 2007 SP1 transaction log files and mailbox databases using the diskpart tool. With Windows Server 2008, the disk partition alignment issues in Windows Server 2003, where a partition would always start on the 64th sector and thereby misalign the entire partition when you used the Windows Disk Management tool, have been corrected.
More on the track-alignment issue can be found on the Exchange team blog at msexchangeteam.com/archive/2005/08/10/408950.aspx. Furthermore, Windows Server 2008 aligns a disk partition through the use of a 1024KB boundary. The Exchange Server 2007 documentation on TechNet also mentions this at technet.microsoft.com/bb738145.
Q We're currently in the planning phase of implementing standby continuous replication (SCR) in our Exchange Server 2007 SP1-based messaging environment. We're a relatively small shop, and we can't afford to deploy more than 1 physical computer with Exchange 2007 server installed acting as the SCR target in a second site.
We're a little unsure as to whether or not there's support for roles other than the Mailbox server role on the SCR target.
A Yes, both the source as well as the target SCR Exchange server can run other Exchange 2007 SP1 roles. This means that it's fully supported to, for instance, deploy Exchange 2007 SP1 servers with the Client Access, Hub Transport, and Mailbox server roles installed and use these as SCR targets.
Q Our organization, which is based on a Windows Server 2003 Active Directory forest and an Exchange 2007 messaging infrastructure, will soon need to merge with a recently acquired organization. One of the requirements when the 2 organizations merge is that the Exchange 2007 address lists be segregated so that users in each organization can only see an address list containing its own users.
I seem to remember some Microsoft Knowledge Base articles that included step-by-step instructions on how to accomplish this in an Exchange 2003 environment. What is the approach when it comes to segregating address lists in an Exchange 2007-based messaging environment?
A It would take a lot more space than I have here to provide all the necessary steps. Luckily, Microsoft recently released a technical white paper that explains how you go about configuring virtual organizations and address-list segregation in Exchange 2007. You can find the paper at technet.microsoft.com/bb936719. In addition, you should make sure to spend a few minutes reading the post that includes comments regarding this paper on Dave Goldman's blog (see go.microsoft.com/fwlink/?LinkId=115499).
Q Does Exchange Server 2007 require the Windows Internet Naming Service (WINS) in order to function properly?
A The Exchange Server 2007 product itself doesn't require WINS. But WINS may be required depending on what version of Microsoft Office Outlook® you use in your Exchange Server 2007 messaging environment. If your messaging environment consists strictly of Exchange 2007 servers and Outlook 2007 or Outlook 2003 clients, then WINS is not required.
Well, there is a rare situation where WINS is required by Outlook 2007. When migrating a mailbox to a new Exchange forest, the RTM version of Outlook 2007 will try to connect to the Exchange mailbox server using the NetBIOS name and not the fully qualified domain name (FQDN) as expected. However, this issue has been corrected with the Outlook 2007 post-SP1 hotfix package released back in January 2008 (support.microsoft.com/?id=941275).
If your end users have Outlook 2002, WINS will always be required, as this client relies on NetBIOS name resolution. I am specifically not mentioning Outlook clients prior to Outlook 2002 since they aren't supported with Exchange 2007, but the same would be the case with these.
Henrik Walther is a Microsoft Certified Architect: Messaging (apprentice) and Exchange MVP with more than 14 years of experience in the IT business. He works as a Technology Architect for Interprise Consulting and as a technical writer for Biblioso Corporation.