Exchange Queue & A

[patris1]

Installing Exchange 2003/2007 in an Exchange 2010 Environment

Henrik Walther

Question: Is it possible to install Exchange 2003 or 2007 in a pure Exchange 2010 organization?
Answer: If this is an Exchange 2010 greenfield environment (an Exchange organization that consists only of Exchange 2010 servers and never had previous versions of Exchange deployed), the answer is no. If you have transitioned from Exchange 2007 to Exchange 2010 and the last Exchange 2007 server has already been decommissioned, the answer is again no. You will not be able to install Exchange 2007 at a later time in this organization because it’s now considered a pure Exchange 2010 organization.
If you plan to transition from Exchange 2003 to Exchange 2010 and you have already prepared the Active Directory forest using Exchange 2010 setup, again you can’t install an Exchange 2007 server in the organization. You will, by the way, get a warning that mentions this when installing the first Exchange 2010 in a pure Exchange 2003 organization (see Figure 1).


Figure 1 Setup warns that you can’t install Exchange 2007 in the organization after preparing it using Exchange 2010 Setup.
So if you think you’ll need an Exchange 2007 server at some point, you should keep an Exchange 2007 server in the organization after transitioning from Exchange 2007 to Exchange 2010. Or, if you are transitioning from Exchange 2003 to Exchange 2010, you should deploy an Exchange 2007 server in the organization before you prepare the AD forest using Exchange 2010 setup.

Question: We currently use Exchange 2007 as the messaging system in our enterprise environment. We have just upgraded all our client machines from Windows XP to Windows 7, and we’re having problems installing the Exchange 2007 (SP2) Management tools on the new Windows 7 clients. Anything special we need to be aware of when installing the Exchange 2007 Management tools on Windows 7?


Answer: Because Exchange Server 2007 was developed before Windows 7, the Exchange 2007 Management tools are not supported on Windows 7. The Exchange product group chose to focus their efforts on Exchange 2010, which of course does support Windows 7.
Unfortunately, software development is always subject to budget and resource constraints, and these imposed some restrictions when the Exchange product group had to decide about providing support for installing the Exchange Management tools on Windows 7. An important consideration was the fact that approximately 65% of all customers who use Exchange are still on Exchange 2003, and now that Exchange 2010 has been released to manufacturing, most customers will skip Exchange 2007 and go directly to Exchange 2010.

The solution is to install Exchange 2007 Service Pack 3 on the Windows 7 clients. Yes, you heard that right. Based on customer feedback, the Exchange Product group has decided to release Exchange 2007 SP3 in the second half of 2010, which will add support for installing Exchange 2007 Management tools on Windows 7 clients and Exchange 2007 on Windows Server 2008 R2 servers. You can read more about the plans to release Exchange 2007 SP3 here: You Had Me At EHLO... : Updates to the Exchange Supportability Matrix.

Question: As preparation for a planned Exchange 2007 to Exchange 2010 migration, I’ve set up a lab environment with two separate Active Directory forests. The source AD forest contains an Exchange 2007 organization and the target AD forest contains an Exchange 2010 organization.
I seem to recall that when I performed an Exchange 2003 to Exchange 2007 cross-forest migration, the target organization didn’t necessarily require that the Active Directory user accounts had already been migrated to the target AD forest.
After trying to move some Exchange 2007 mailboxes cross-forest to an Exchange 2010 organization, it seems that the cross-forest mailbox moves with Exchange 2010 behave differently from the Exchange 2007 equivalent.
Can you explain how to move mailboxes cross-forest when the target is an Exchange 2010 organization?


Answer: You’re correct that cross-forest mailbox moves in Exchange 2010 don’t work as they did with Exchange 2007.
As you indicate, the Exchange 2007 Move-Mailbox cmdlet didn’t necessarily require the AD accounts to be migrated to the target AD forest prior to moving the associated mailbox. The Exchange 2007 Move-Mailbox cmdlet would check for any AD accounts in the target AD forest that matched any of the proxy addresses (SMTP addresses), source ObjectSID (masterAccountSID, objectSID and sidHistory), or legacyExchangeDN (x500 address stamped on user object). If a match was found, the matched AD account in the target AD forest would be mail-enabled. If a match was not found, the Move-Mailbox cmdlet would create a disabled mailbox-enabled AD user account.
With Exchange 2010, things have changed. First, the Move-Mailbox cmdlet is no longer used. This cmdlet has been replaced with the brand-new New-Move Request cmdlet, which, by the way, brings several nice improvements with it. Furthermore, when doing cross-forest mailbox moves using the New-Move Request cmdlet, Exchange 2010 expects to find a valid mailuser and tries to match the source account to a target account using the msExchMailboxGUID. Unlike Exchange 2007, it will not try to match a target account using the abovementioned attributes. This means that before you can do cross-forest moves with Exchange 2010, you need to provision the target AD forest with mail users.
By the way, unlike with Exchange 2007, you can now do cross-forest mailbox moves using the Exchange 2010 Exchange Manage Console (see Figure 2). You just need to add the Exchange organization from the target forest AD to the EMC first.


Figure 2 The Exchange 2010 New Remote Move Request Window

You can create mail users in the target Exchange 2010 organization using the PrepareMoveRequest.ps1 script described in this section on Microsoft TechNet or by using either Identity Lifecycle Management (ILM) 2007 FP1 (with latest hotfix that will enable Exchange 2010 provisioning for ILM 2007 FP1) or using Forefront Identity Management (FIM 2010), which is currently available in a release candidate 1 and will RTM later in Q1 2010.
Question: Our organization currently has Exchange 2007 deployed. We have a high availability solution consisting of 4 Exchange 2007 servers—two servers that have the Hub Transport and Client Access server roles installed and two servers that are acting as mailbox server cluster nodes in a continuous replication cluster (CCR) cluster. The Exchange 2007 servers on which the HT and CAS server roles are installed have been configured in a Windows NLB in order to load balance and provide automatic failover for incoming client and SMTP connections. This solution works very well, but now that Exchange 2010 has been released, we want to move to this latest Exchange server version. Not only are there several new features we want to utilize, but we have also heard that we can reduce the number of Exchange servers to two without losing the HA functionality we have now.
Are there special considerations we need to be aware of before moving to an Exchange 2010 HA solution consisting of just two servers?
Answer: Yes, in order to build a highly available Exchange 2007 messaging solution with automatic failover and without any single points of failure at either the hardware or storage level, you needed a total of four machines: two servers with the Exchange 2007 Client Access and Hub Transport server roles installed and two acting as cluster nodes in a cluster continuous replication-based cluster (CCR).
The Hub Transport has built-in load balancing and fail-over for intra-site communication, and you could make it redundant using DNS round-robin mechanisms. But since the CAS role doesn’t include any load-balancing functionality, you typically also had to configure these two machines as nodes in a Windows network load balancing (WNLB) cluster in order to provide load balancing and automatic fail-over for incoming connections from clients and servers on the Internet and other external networks.
The two machines acting as cluster nodes in the CCR cluster would have the active and passive Mailbox server roles installed respectively, so that the clustered mailbox server (CMS) could switchover or failover to either node. Finally, you would dedicate one of the front-end servers as the file-share witness (third vote) in the CCR cluster.
As you probably know CCR (and SCC, LCR and SCR for that matter) has been cut from Exchange 2010. Instead, Exchange 2010 introduces a new feature called Database Availability Groups (DAGs). This feature uses the same synchronization technology as CCR and SCR combined, but it has so many new features and so much more functionality that it is significantly better than CCR and SCR. An interesting aspect of Exchange 2010 is that it’s supported to have other Exchange 2010 roles (Hub Transport, Client Access and even Unified Messaging) installed on the same server on which you have a Mailbox server role that has been added to a DAG. This means you no longer need to dedicate two machines as front-end servers for the Hub Transport and Client Access Server roles. You simply install all required Exchange 2010 roles on the two machines and voilà, you have a fully redundant Exchange 2010-based messaging solution. Well, almost. Yes, it did sound too good to be true, didn’t it?
You see, since DAGs make use of the Windows Failover Clustering (WFC) component to an extent (primarily heartbeat and the cluster database), you can’t configure the two servers as nodes in a Windows NLB since it’s unsupported to use both WFC and WNLB on the same server. This has been unsupported since Windows NT 4.0 and is due to potential hardware sharing conflicts between the Cluster service and WNLB. Read more in KB article: Interoperability between MSCS and NLB.
This means that you must use an external load balancing/fail-over device such as a hardware-based load balancer. Also note this balancer should be redundant, so you need a minimum of two devices.

Though you still make use of WFC and though DAG is an Enterprise Edition feature, you don’t actually need the Exchange 2010 Enterprise Edition to utilize DAG. Unlike with Exchange 2007 CCR, DAG is also included with the standard edition of Exchange 2010. But bear in mind that you are limited to a total of five databases (including active and passive database copies) in this scenario.
Since you install the CAS and HT roles on the same machine that has the Mailbox server role and is a DAG member server, you can spare two machines and two Windows 2008 and Exchange 2010 standard edition licenses. If you don’t already have an external load balancer in your environment, you can either use a virtual load balancer appliance or buy a hardware-based load balancer. Of course, you need a server that acts as the witness server as well, but although it’s a best-practice recommendation, this doesn’t necessarily need to be an Exchange server. It could be any Windows 2003/2008 file server in your environment.


Henrik Walther is a Microsoft Certified Master: Exchange 2007 and Exchange MVP with more than 15 years of experience in the IT business. He works as a technology architect for Trifork Infrastructure Consulting (a Microsoft Gold Certified Partner based in Denmark) and as a technical writer for Biblioso Corp. (a U.S.-based company that specializes in managed documentation and localization services).

---

موضوعات مشابه:

• کمک: آوردن اكانتهاي pppop در داخل queue و بتونم با queue تورنت رو ببندم
• queue
• عمل نکردن queue

---

[patris1]

Exchange Queue & A
Recovering a Clustered Mailbox Server, Offline Address Book Issues, and More

Henrik Walther


QOur messaging infrastructure is based on Exchange 2007 SP1. All Exchange 2007 SP1 servers have been installed on Windows Server 2008. We have two datacenters—the primary datacenter and a backup where we can failover should a disaster strike the primary. In our primary datacenter, all Mailbox servers are based on cluster continuous replication (CCR) in order to provide a local high availability solution. For Mailbox server failovers from the primary datacenter to the backup datacenter, we use standby continuous replication (SCR). This means all the CCR-based clustered Mailbox servers (CMSs) in the primary datacenters also act as SCR sources. Each SCR source has corresponding SCR targets in the backup datacenter in the form of standby clusters on which only the passive Mailbox server role has been installed
Recently we did a site failover test between the two datacenters and, unfortunately, we ran into an issue when we tried to recover the CMSs to the standby clusters. When running Setup.com with the /RecoverCMS switch, we got the error message shown in Figure 1.
Figure 1 Setup error when recovering CMS to a standby cluster

I was wondering if you have seen this error while recovering a CMS to a standby cluster and, more importantly, whether you have a resolution for it.
AYes, I had the misfortune of encountering this issue while trying to recover a CMS to a standby cluster. Luckily, this was also during a site level failover test. (Do I need to explain why testing your failover solutions is important?)
One thing that got me thinking was that I had tested the same setup many times before without issues. However, all the previous recovery tests were with Exchange 2007 SP1 installed on Windows Server 2003 and not Windows Server 2008 as was the case when I hit this issue.
This led me to discover how Windows Server 2008 failover clusters work compared to Windows Server 2003-based clusters. In Windows Server 2003, you created and dedicated a cluster service account to the cluster. In Windows Server 2008, you no longer do this; instead, the failover cluster runs under the "Local System." After examining the application and system logs on the standby cluster on which I tried to recover the CMS, I found the error shown in Figure 2.
Figure 2 Recovery error due to inadequate permissions

This event id error explains that the Windows Failover cluster doesn't have the permissions necessary to update the CMS computer account in Active Directory. It also lists three possible reasons. Since we're recovering an existing CMS on a standby cluster, we can ignore the first one. Since we haven't reached any quotas for the number of computer objects, we can ignore number two as well. The last item, however, is quite interesting. It tells us to verify that the Windows Failover cluster on which we recover the CMS has "Full Control" permissions to the CMS computer account object.
A look under the Security tab on the property page of the CMS computer object in the Active Directory Users and Computers reveals that the standby cluster does not have "Full Control" permissions (Figure 3).
Figure 3 The standby cluster does not have “Full Control” permissions

Adding the standby cluster with "Full Control" permissions to the CMS computer object resolved the issue for me and it should do the same in your environment.
At the time of this writing (the end of February), there's no information about this issue at public places like TechNet or in any KnowledgeBase articles. However, my good friend Tim McMichael from Microsoft Customer Support Services has written a blog post on this topic that goes into far more detail than I'm able to do here. So please go check out Tim's blog for more information ("Permissions recommended for the CNO (Cluster Name Object) in Windows 2008 for Exchange 2007 SP1 setup operations.").
QWe're currently in the process of crafting a site-level failover solution. For our Exchange 2007 SP1-based messaging infrastructure, we're going to use standby continuous replication (SCR) as the disaster recovery solution between our primary and backup datacenter. Since only some of our end-users have been upgraded to Office Outlook 2007 with the rest still on Outlook 2003, we've got a question. When a failover of the Exchange 2007 SP1 servers occurs from the primary datacenter to the backup datacenter, will both Outlook versions simply pickup the changes after performing the required SCR site failover steps?
AVery good question and, actually, the answer depends on whether you're using RecoverCMS or Database portability to failover your mailbox servers to the backup datacenter. If you have standalone Mailbox servers in the primary datacenter and replicate these to standalone Mailbox servers in the backup datacenter using SCR, then you would use database portability in order to failover the Mailbo x databases. If you have single copy cluster (SCC) or CCR Mailbox servers in your primary backup datacenter and standby clusters in your backup datacenter, you would use the RecoverCMS switch to recover the whole CMS to the backup datacenter. When using RecoverCMS as the failover mechanism, you typically don't need to worry about Outlook client connectivity after the failover. Do bear in mind that the IP address of the CMS will change. But if you have configured the DNS Time to Live (TTL) value to five minutes according to best practice recommendations, note that there will be a slight delay before the Outlook clients will be able to reconnect to the CMS.
If you're using database portability as the recovery mechanism, the situation is a bit different, depending on the Outlook client version. Outlook 2007 clients will reflect the changes automatically via the Autodiscover service that runs on the Client Access servers. This means you don't have to do any manual changes for this Outlook version. However, that's not necessarily the case with Outlook 2003 clients. When a mailbox has been recovered on another server, the name of the server storing the Mailbox database(s) will obviously be different.
You might wonder, does this matter when you use the Move-Mailbox cmdlet with the –ConfigurationOnly switch after the failover? Yes, it still matters because Outlook 2003 doesn't support the Autodiscover service. This means that the original server where the Mailboxes were stored before the failover must be online so that the server name in the Outlook MAPI profile can be updated. If the original server is offline, the server name can't be updated automatically.
So, if you're facing a disaster where all servers in your primary datacenter are offline, you must reconfigure the Outlook 2003 MAPI profiles using a tool such as the Microsoft Exchange Server Profile Redirector (ExProfre) in combination with a login script to reflect the changes. It's worth noting that if all your clients were located in the primary datacenter, you would need to rebuild them anyway.
QIn our Exchange 2007 SP1-based messaging infrastructure, all our Mailbox servers are cluster continuous replication (CCR)-enabled. We have installed four network interface cards (NICs) in each cluster node. Two NICs have been teamed and are connected to the public network, which accepts Outlook client requests and so forth. The third NIC is used for the heartbeat network between the two cluster nodes in the CCR. The fourth NIC is there specifically for log shipping purposes. Using the Enable-ContinuousReplicationHostName cmdlet introduced in Exchange 2007 SP1, we have (in order to achieve log shipping redundancy) specified that both the heartbeat and the dedicated log shipping network can be used to ship logfiles from the active to the passive node. This works great and really reduces the traffic on the public network, especially in situations where a reseed of one or more Mailbox databases are required (though this should be pretty rare).
We also have SCR enabled between these CCR-based Mailbox servers and multiple SCR targets in our backup datacenter. This leads to our question. Is it possible to use the Enable-ContinuousReplicationHostName cmdlet with SCR?
AI'm glad that the EnableContinuousReplicationName cmdlet has been helpful to you. However, since this cmdlet was specifically created for CCR solutions, the answer to your question is, unfortunately, no, currently this is not supported in an SCR solution.
QWe have just transitioned from Exchange 2003 to Exchange 2007 SP1. All Exchange 2007 SP1 server roles are running on Window Server 2008 and our Exchange 2007 Mailbox servers are based on CCR.
Things work very well so far but we have observed an issue with the Offline Address Book (OAB). When it's updated with new mail objects, the updates aren't reflected in Outlook 2007 at the end users. We have been troubleshooting the issue and have found Event ID 1021 in the Application log on the Client Access Servers with the following description:

Process MSExchangeFDS.exe (PID=xxxx). Could not find directory <OAB share location> 
This is normal if the directory has never been generated. Otherwise, make sure this directory
and share has read permission for the "Exchange Servers" group.

We have tried to copy the OAB manually from the CCR-based Mailbox server where it is hosted to the Client Access Server. This results in updates in Outlook, but we would like to get the issue fixed permanently. Do you have the recipe?
AI've been down that road, too. The reason for this problem is because of the way Windows 2008 Failover Clusters behave. Windows 2008 Failover Clusters introduces a new concept called shared scoping. Basically, shared scoping means that a file share is specific to either the node name or to one of the cluster name objects that the share hosts. When a share is shared by the node name, it cannot be accessed by the Clustered Mailbox Server (CMS) name. For more geeky details about file share scoping, see this post on the Ask the Core Team blog ("File Share 'Scoping' in Windows Server 2008 Failover Clusters").
To resolve the issue, you need to install Exchange 2007 SP1 Rollup Update 5 or later, which includes the required bug fix. Also see the article "Exchange 2007 CAS cannot copy the OAB from the OAB share on Windows Server 2008-based Exchange 2007 CCR clusters." Because this Rollup Update brings some regressions with it, it's important you read the Rollup Update 5 KB article closely before using this solution.

Henrik Walther is a Microsoft Certified Master: Exchange 2007 and Exchange MVP with more than 15 years of experience in the IT business. He works as a Technology Architect for Trifork Infrastructure Consulting (a Microsoft Gold partner based in Denmark) and as a Technical writer for Biblioso Corporation (a US based company that specializes in managed documentation and localization services).

[patris1]

Exchange Q&A
A Second Look at Exchange 2010 Features and Improvements
Henrik Walther

In this installment, I’m continuing where I left off in my last column—that is, answering even more questions related to new and exciting Exchange 2010 features. But I also have room for a couple of Exchange Server 2007 questions.
Q We are deploying a multisite Exchange 2007 SP1 cluster using Cluster Continuous Replication (CCR). The two cluster nodes will be located in separate datacenters. Exchange runs on Windows Server 2008 SP2 and we plan to have the public and private interfaces located in different subnets in each datacenter. As you know, this means we must use routing between the cluster nodes.
We have no problem configuring the public interface according to the instructions in the CCR section on Microsoft TechNet. But when we configure the default gateway on the private interface, we receive the warning message shown in Figure 1.
Figure 1 Specifying multiple default gateways on a Windows 2008 Server.

Based on this warning message, we suspect things will not work properly if we specify multiple default gateways on each node in our multisite CCR cluster. This leads us to our question: How should we configure the private network interface in this type of scenario?
A I'm glad you asked this question before proceeding, because specifying multiple default gateways on a multisite CCR cluster will cause major issues. The proper configuration requires persistent, static routes for each private interface.
To get started, make sure the public interface is listed first on the connection order list under Advanced Settings in the Network Connections control panel. Next, make sure you have specified a default gateway on the public network interface for each cluster node.
Finally, configure routes on the private interfaces so that all traffic that doesn't match the route created will use the default gateway of the public interface. Let's imagine the node 1 private interface is on subnet 192.168.100.x/24 with a network gateway at IP address 192.168.100.1. The node 2 private network interface is on subnet 192.168.200.x/24 with a network gateway at IP address 192.168.200.1. In this case you would need to create this route on node 1: ROUTE ADD 192.168.200.0 MASK 255.255.255.0 192.168.100.1 –P, and the following route on node 2: ROUTE ADD 192.168.100.0 MASK 255.255.255.0 192.168.200.1 –P.
The –P parameter specifies that the created routes are persistent and won't be cleared after a reboot.
This configuration will ensure proper networking for each interface in the cluster nodes. For even more details on how to configure the private interface when using routing between the networks, check out the blog post by my good friend Tim McMichael.
On a final note, I also recommend you configure the private network as a mixed network so that the Enable-ContinuousReplicationHostName cmdlet can be used to direct replication activity over the redundant network. For more information about this cmdlet, see How to Enable Redundant Cluster Networks for Log Shipping and Seeding on Windows Server 2003.
Q I have a question regarding the new Database Availability Group (DAG) feature in Exchange Server 2010. More specifically, my question relates to log file copying and seeding between active and passive databases. Will Exchange Server 2010 offer changes or improvements in the way log file copying and seeding occurs with Local Continuous Replication (LCR), Cluster Continuous Replication (CCR) and Standby Continuous Replication (SCR) in Exchange Server 2007?

A That is a great question. Although the asynchronous replication technology used in Exchange 2007 works quite well, that doesn't mean it can't be improved, right? I'm glad to inform you that the Exchange Product Group has made several interesting changes and improvements to the asynchronous replication technology with Exchange 2010.
In Exchange 2007, the Microsoft Exchange Replication Service copies log files to the passive database copy (LCR), passive cluster node (CCR) or SCR target over Server Message Block (SMB), which means you need to open port 445 in any firewalls between the CCR cluster nodes (typically when deploying multisite CCR clusters) and/or SCR source and targets. Those of you who work for or with a large enterprise organization know that convincing network administrators to open port 445/TCP between two datacenters a far from a trivial exercise. With the Exchange 2010 DAG feature, the asynchronous replication technology no longer relies on SMB. Exchange 2010 uses TCP/IP for log file copying and seeding and, even better, it provides the option of specifying which port you want to use for log file replication. By default, DAG uses port 64327, but you can specify another port if required. For this, use the following command:

Set-DatabaseAvailabilityGroup -identity <DAG name> -ReplicationPort <port number>

In addition, the Exchange 2010 DAG feature supports the use of encryption whereas log files in Exchange 2007 are copied over an unencrypted channel unless IPsec has been configured. More specifically, DAG leverages the encryption capabilities of Windows Server 2008—that is, DAG uses Kerberos authentication between each Mailbox server member of the respective DAG. Network encryption is a property of the DAG itself, not the DAG network. Settings for a DAG's network encryption property are: Disabled (network encryption not in use), Enabled (network encryption enabled for seeding and replication on all networks existing in a DAG), InterSubnetOnly (the default setting meaning network encryption in use on DAG networks on the same subnet), and SeedOnly (network encryption in use for seeding on all networks in a DAG). You can enable network encryption using the Set-DatabaseAvailabilityGroupcmdlet. For instance, if you wanted to enable encryption for log copying and seeding, you would execute the command:

Set-DatabaseAvailabilityGroup -identity <DAG name> -NetworkEncryption Enabled.

Finally, with Exchange 2010 DAGs you can enable compression for seeding and replication over one or more networks in a DAG. This is a property of the DAG itself, not a DAG network. The default setting is InterSubnetOnly and has the same settings available as those of the network encryption property. To enable network compression for log file copying and seeding on all networks in a DAG, use the command: Set-DatabaseAvailabilityGroup –Identity <DAG name> -NetworkCompression Enabled. To find the status of the port, encryption and compression settings for a DAG, use the Get-DatabaseAvailabilityGroup –status command as shown in Figure 2.
Figure 2 Database Availability Group network encryption, compression and replication port settings.

Q In your previous Exchange Queue & A column, you talked about a significant I/O reduction in Exchange 2010 compared to Exchange 2003 and 2007. Can you explain the specific changes and improvements the Exchange Product Group made to achieve such optimization for storage performance in Exchange 2010?
A As you mentioned, we saw a significant reduction in I/Os per second in the move from Exchange 2003 to Exchange 2007. Reductions of up to 70 percent were not uncommon. We can attribute this primarily to the use of a 64-bit architecture for Exchange 2007. As such, Exchange 2007 can access more memory and thereby use larger memory caches than its predecessor. The more data Exchange can retrieve directly from the virtual memory address space, the fewerI/Os needed against the disks in the underlying storage subsystem.
This provides much more efficient use of the existing storage system (typically an expensive Storage Area Network) or a great excuse to move to less expensive direct-attached storage. The reduced I/O requirements enable hosting of many more mailboxes (5,000-plus) per Exchange 2007 Mailbox server than was possible with Exchange 2003. In order to avoid virtual memory fragmentation, Exchange 2003 was typically limited to 4,000 mailboxes per Mailbox server. (Yes, I know this depended on type of servers, storage user profiles and Exchange infrastructure.)
The Extensible Storage Engine (ESE) has been the underlying database technology in Exchange since the first version—Exchange 4.0, released in June 1996. Until Exchange 2007 SP1, the Exchange Product Group made great efforts in tweaking and optimizing the ESE for better performance.For storage in Exchange 2010, the Exchange Product Group focused on delivering large (+10GB), fast mailboxes while taking advantage of cheap storage. Because of the ESE changes made in this version, you now have the option of using such low-performance disks as the desktop-like SATA disks (aka SATA or Tier 2 disks). Yes, I am talking about 7200 SATA disks, just like the ones in your workstation! If you use the Database Availability Group feature for high availability (three or more database copies), you can even use, say, a single 7200RPM disk storing both a database and the transaction logs instead of expensive RAID configurations.
Achieving such improvements meant changing the store schema significantly. Essentially, the Exchange Product Group wanted to move away from many, random, small I/Os to fewer, sequential, large I/Os. Moving from random to sequential I/Os required dramatic changes to the store table architecture.
In Exchange 2007 and earlier, each database had a mailbox table (stored all mailboxes in the database), folders table (stored mailbox folders for all mailboxes in the database), message table (stored messages), attachment table (stored attachments for all mailboxes in the database), and message/folder table (stored folder views for all mailboxes in the database).In this architecture, which has not changed much since Exchange 4.0, a lot of random I/Os had to perform against the database. One of the benefits with this architecture was single-instance storage (SIS) in which only one copy of a message was kept—a big advantage back when relatively small disks were par for the course. But today, with 500GB SAS and 2TB SATA disks at our disposal, this architecture no longer makes sense.
In Exchange 2010, the store schema has changed so that all data in a mailbox is stored in tables close to each other in the database. Actually, each mailbox has its own folder, message header, body and view table. So, SIS no longer exists in Exchange databases. As a side effect of removing SIS from Exchange, a database might bloat by approximately 20 percent. To solve this problem, the Exchange Product Group compressed the databases (more specifically, the message headers and text or HTML bodies). By giving each mailbox its own set of tables, I/Os performed against a database are mostly sequential.
Other interesting changes include: the database space is allocated in a contiguous manner; database contiguity is maintained over time; the database page size has been increased from 8KBto 32KB; and asynchronous read capability has been improved. The Exchange Product Groupis also working on increasing the cache effectiveness by changing the checkpoint depth to 100MB for high availability configurations, using cache compression, and database cache priority.
As a result of all the changes in Exchange 2010, you can expect up to 70 percent reduction in I/O compared to Exchange 2007.
I've only scratched the surface when it comes to storage optimizations in Exchange 2010. If you want some great insight along with all the gory details on storage improvements in Exchange 2010, I highly recommend you grab a fresh cup of coffee and watch the recording of the Tech·Ed 2009 session on Exchange 2010 Storage presented by Matt Gossage, the Exchange Product Group team member responsible for ESE database. He does a great job of explaining this complex Level 300 topic in plain English. Watch it at online (you don't need to have attended Tech·Ed to watch it).
Q We have several Exchange 2007 Cluster Continuous Replication (CCR)-based Mailbox servers deployed within our organization. The private network on all nodes has File and Printer Sharing for Microsoft Networks disabled (see Figure 3). We're sure this was recommended back when we deployed Exchange 2007.
Figure 3 File and Printer Sharing for Microsoft Networks disabled.

But this differs from the guidance provided with Exchange 2007 SP1 documentation. Now the recommendation is to enable File and Printer Sharing for Microsoft Networks on the private network interface just like it is on the public network interface. Can you explain why this guidance changed after Exchange 2007 SP1 released?
A You're correct. Prior to the release of Exchange Server 2007 SP1, disabling File and Printer Sharing for Microsoft Networks on the private network interface was recommended. But in Exchange 2007 SP1, a new feature allows you to replicate log files over multiple network interfaces, thereby making the networks redundant, plus reducing the amount of data traveling over the public network interface. In the release to manufacturing (RTM) version of Exchange 2007, all log file copying and seeding occurred over the public network interface.
On a related note, if you use Windows Server 2008-based machines, make sure to enable NetBIOS on all network interfaces that you plan to use for log file copying and seeding. If NetBIOS is disabled, the Enable-ContinuousReplicationHostNames command will fail.
The Enable-ContinuousReplicationHostNames cmdlet lets you specify which network interfaces should be used for log file copying and seeding. But bear in mind that you must change the private network to a mixed network within the Windows Failover Cluster console in order to utilize it for log file copying and seeding.
See the Exchange 2007 SP1 documentation for more information.
Q In Exchange 2007, does Microsoft have a recommendation on how to stop mailflow to and from an Exchange 2007 Mailbox server, as in the case of a virus or similar outbreak? We would like users to be able to connect to their mailboxes but not be able to send and receive e-mail messages in such circumstances.

A You can do this by stopping the Microsoft Exchange Transport service on the Exchange 2007 Hub Transport servers.
If you want to have all queued e-mail messages delivered without allowing new messages into the queue, simply pause the Microsoft Exchange Transport service.
Note that doing this at the Mailbox server level requires that you stop the Microsoft Exchange Mail Submission service on the involved Exchange 2007 Mailbox servers.
Q I have taken a close look at the new archive mailbox feature in Exchange Server 2010 and have a couple of questions. I noticed that once you enable the archiving mailbox feature for a user mailbox, it's accessible and works as expected via Outlook Web Access 2010 and Outlook 2010, but not via Outlook 2003 or 2007. Will we not be able to make use of the new archive mailbox feature before we upgrade to Outlook 2010?
Also, we want to move the archive mailbox for a respective user to another mailbox database. But as far as I can see, this is not possible. If you can't move the archive mailbox to another mailbox database, what's the benefit of the archive mailbox?

A In regard to your first question, what you see is expected behavior (even when we reach Exchange 2010 RTM). You will only be able to access an archive (aka alternate) mailbox via Outlook Web Access 2010 or Outlook 2010. Accessing this mailbox via legacy Outlook 2003 or 2007 clients is neither supported nor possible..
To address your second question, you can store the archive mailbox only in the same mailbox database as the one in which you've stored your primary mailbox. But because you can use Tier 2 disks (aka SATA desktop-like disks) for your mailbox databases and logs in Exchange 2010, moving the archive mailbox to another storage subsystem doesn't really make sense. With that said, here are some benefits of the archive mailbox feature:
You can provide larger mailboxes to the end users without impacting performance of critical path folders in the primary mailbox (primary mailbox = hot data, archive mailbox = cold data) even though the mailbox databases are stored on SATA/Tier 2 disks. You can provide large mailboxes (+10GB) without synching all that data to the user's .OST file when running in cached mode (an archive mailbox is accessible only in online mode).
The archive mailbox is a replacement for .PST files. As you already know, the archive mailbox is not only accessible via Outlook 2010, but also Outlook Web Access 2010. This means you no longer need to worry about backing up your .PST files and so on.

Henrik Walther is a Microsoft Certified Master: Exchange 2007 and Exchange MVP with more than 15 years of experience in the IT business. He works as a technology architect for Trifork Infrastructure Consulting (a Microsoft Gold Certified Partner based in Denmark) and as a technical writer for Biblioso Corp. (a U.S.-based company that specializes in managed documentation and localization services).

[patris1]

Exchange Q & A
Site Resiliency with SCR, Recommended Root Volume Size, and More
Henrik Walther


Q I'm currently architecting an Exchange Server 2007-based messaging infrastructure for a large enterprise requiring that the solution include site resiliency. So I'm considering deploying cluster continuous replication (CCR)-based Mailbox servers on Windows Server 2008 failover clusters with the active node in the primary (active) datacenter and the passive node in the secondary (backup) datacenter.
The datacenters are on different subnets but belong to the same Active Directory site, which means this is a supported scenario when installing­ the CCR-based Mailbox servers on Win­dows Server 2008. Would you recommend deploying CCR-based Mailbox servers in a multi-subnet environment?
A You're correct that this scenario is supported as long as you stretch the Active Directory site between the datacenters, as Exchange 2007 doesn't support deploying the active and passive CCR nodes in different Active Directory sites. Nevertheless, it's important to bear in mind that CCR was really designed for high availability within a datacenter, not for site resiliency (which is more about disaster recovery than high availability).
For this specific reason, the Exchange Product group introduced standby continuous replication (SCR) with Exchange 2007 SP1. SCR uses the same log-shipping and replay technology used by CCR, but SCR does not rely on Windows failover clustering functionality, as does CCR. This means that you can enable replication for both clustered and non-clustered Mailbox servers to an SCR target. That target can consist of a non-clustered Mailbox server or a standby cluster on which the passive Mailbox server role has been installed.
This is illustrated in Figure 1, which is part of the Standby Continuous Replication section in the Exchange 2007 documentation.
I don't recommend implementing a geographically dispersed cluster (geo-cluster) based on CCR, but it is, as already mentioned, fully supported by Microsoft. However, you need to be aware of the disadvantages of following this approach.
Figure 1 Standby continuous replication model (Click the image for a larger view)

First, you must use a stretched Active Directory site. It seems that you already have this one settled, but it's worth mentioning for the rest of the readers out there who may not know this. Next, you should be aware that because the CCR nodes are located on different subnets, the clustered Mailbox server (CMS) will change its IP address during a failover to the other site. This change will need to be replicated to all DNS servers used by Microsoft Outlook clients and—just as important—all machines with Outlook clients connecting to the CMS must have their DNS cache flushed.
The Outlook clients will be disconnected from the respective mailboxes on the CMS during the period that this takes place. For this reason, you should change the DNS time-to-live (TTL) value for the CMS network name resource to five minutes (300 seconds) or less. For more on how this is done, refer to technet.microsoft.com/library/bb676687.aspx.
You must also take into consideration where you want to place the file share witness (FSW). The recommendation is to create the FSW on a Hub Transport server, but in which site? If you locate it on a Hub Transport server in the primary datacenter and the primary datacenter is lost, will an automatic failover happen? No, this is not possible if one of the CCR nodes and the FSW are down at the same time. On the other hand, it's likely that many would prefer the failover not to be automatic in a geo-CCR scenario. Be sure to read the guidance related to placement of the FSW in a geo-CCR scenario.
Finally, you should be aware that if a failover to the passive node in the backup datacenter occurs, any backfill from the Transport Dumpster on Hub Transport servers in the primary datacenter will not happen since these servers most likely are down. The net result is missing e-mail.
As you can see, there are many things to consider before you deploy a geo-CCR in your environment, far more than if you instead choose to use SCR for site resiliency.
Q Our organization consists of multiple physical sites spread across the U.S. as well as Europe, the Middle East, and Africa. Today all user mailboxes are hosted on Mailbox servers deployed locally at each physical site, but we want to consolidate those servers to one datacenter located in the U.S. Given this plan, can you tell us the maximum latency for Outlook 2003/2007 clients running in cached mode?
A It's good to hear all your clients are either Outlook 2003 or 2007 and run in cached mode, because cached mode is typically your lifesaver in consolidations such as the one you describe.
In the past, Microsoft recommended 1,000 ms or less end-to-end latency to the home Mailbox server for Outlook 2003 cached-mode clients. For non-cached-mode Outlook 2003 clients, the recommendation was 200 ms or less.
Based on my own personal experience, 1,000 ms is a little high even for Outlook 2007 cached-mode clients. When you get more than 500 ms, Outlook starts to hang and generally becomes sluggish. My recommendation is you should strive for latency less than 500 ms between the Outlook client and the home Mailbox server. In Figure 2, you can see the average response time for my Outlook 2007 client connected to a mailbox in Redmond.
Here's a tip: to open the Connection Status window shown in Figure 2, you can right-click the Outlook icon in the system tray while holding down the CTRL button. Alternatively, you can launch Outlook by clicking Start | Run and entering Outlook.exe /RPCDIAG.
Figure 2 Average response time in Outlook 2007

Considering that I'm located in Denmark, the average response times are acceptable. You can see the average response times from the global catalog server are drastically higher, but since these are used less frequently (for address book lookups and so forth), it doesn't matter that much.
Q We have just deployed Exchange 2007 SP1 in our organization. The Active Directory topology consists of two sites. In the first site, we have deployed a CCR-based Mailbox server and two servers each with the Hub Transport and Client Access server roles installed. In the second site, we have deployed a single copy cluster (SCC)-based Mailbox server and two servers with the Hub Transport and Client Access server roles just as in the first Active Directory site.
The majority of clients in each Active Directory site still run Outlook 2003, which means a public folder store is required for free/busy information and the offline address book (public folders will be used only for this purpose, not as a data repository). Our initial plan was to mount a public folder store on both the CCR- and the SCC-based Mailbox servers so public folder changes could be replicated between the Active Directory sites. But then we heard that Microsoft doesn't recommend having­ more than one public folder store in an Exchange organization if one is hosted on a CCR-based Mailbox server, because public folder replication and CCR replication don't behave well together.
So with all of this in mind, what would you recommend that we do? We don't want to go down a path not recommended by Microsoft. But at the same time, we don't want Outlook 2003 clients on each Active Directory site to contact the public folder store on the other Active Directory site.
A This is a very good question. You're correct that combining public folder replication and CCR replication for a public folder store should be avoided (details on why you should avoid it can be found in my January 2009 Exchange Queue & A column. Since you will use public folder functionality to enable legacy Outlook clients to perform free/busy lookups to download the offline address book (OAB), I recommend you install the Mailbox server role on one of the combined Hub Transport and Client Access servers in the Active Directory site where the CCR-based Mailbox server resides. Then move the public folder store from the CCR-based Mailbox server to this server.
Bear in mind, though, that for public folder replication to work properly, you must also have a mailbox database running on the server. Using the combined Hub Transport and Client Access server for free/busy lookups and the OAB will not put a big performance burden on the box, and it is what most Exchange architects do in such a scenario.
Q We are currently planning the storage layout for the Mailbox servers that will be part of the Exchange 2007 messaging environment we plan to transition to within the next six months. Since our enterprise consists of thousands of users, we plan to have 48 storage groups on each Mailbox server, all of which will be based on CCR technology.
Because of the number of storage groups, we will, of course, make use of mount points. Since we will create a mount point for each LUN on each of the CCR-based Mailbox servers, we are interested in hearing what the recommended minimum size is for the anchor drives where the mount points will be created.
A The Knowledge Base article "How to Configure Volume Mount Points on a Server Cluster in Windows Server 2008" describes how to configure volume mount points on a server cluster in Windows Server 2008. It states that if the root (host) volume—also known as the anchor LUN—is used extensively for mount points, it must be at least 5MB. But the recommendation for root volumes is different when it comes to Exchange.
In Exchange 2007, as well as previous versions of Exchange Server, it is a best practice to use a root volume between 100MBs and 500MBs. When running Exchange 2007 on Windows Server 2003-based servers, you can have problems creating a new database if the root volume has fewer than 20MBs of free space. See "Event 104 is logged after you create a new database in Exchange Server 2007" for more information about this specific issue.
Q Our organization's messaging infrastructure is based on Exchange 2007 SP1. All Exchange 2007 servers are located in the same datacenter and are based on CCR clustering technology, so we have local redundancy. But we have just set up a second datacenter to act as the backup in case our primary datacenter is lost during a disaster.
For Exchange, we want to deliver site resiliency by deploying one Hub Transport, one Client Access, and one Mailbox server in the backup datacenter. We then want to enable SCR from the CCR-based Mailbox servers in the primary datacenter to the Mailbox server in the backup datacenter. Before we start to build the Exchange 2007 servers in the backup datacenter, we have a question we hope you can answer. We want to know whether it's supported to enable SCR between SCR sources consisting of CCR-based Mailbox servers and an SCR target consisting of a standalone Mailbox server. And if this is the case, would you recommend that we follow this approach?
A The short answer is yes, this is fully supported. The long answer, however, is also yes, but you must remember that you can't recover the CMS located on the SCR source server(s) using the /RecoverCMS switch. You can only recover a CMS using the /RecoverCMS switch when the SCR target is a Windows Server 2003/2008 failover cluster on which only the passive Mailbox server role has been installed.
If you deploy a standalone Mailbox server as the SCR target, you'll have to recover the databases using database portability, a procedure that's more cumbersome than the RecoverCMS method. You can find the necessary step in the Exchange 2007 documentation in the article "Standby Continuous Replication: Database Portability." If you have Windows Server 2003/2008 Enterprise edition installed on the SCR target, you could also remove the Mailbox server role from it, form a failover cluster, install the passive Mailbox server role on one of the failover cluster nodes, and then recover your CMS using the RecoverCMS option.
If you have only one physical machine available right now but will have an extra machine (plus an additional license for Windows Server 2003/2008 Enterprise edition and Exchange Server 2007 Enterprise edition) in the near future, you could also start by forming a Windows Server 2003/2008 failover cluster consisting of a single node, and then install the passive Mailbox server role on this node. When you have that extra machine ready, you could install Windows Server 2003/2008 on it and configure the network settings and the like and then finally add it to the Windows failover cluster.

Henrik Walther is a Microsoft Certified Master: Exchange 2007 and Exchange MVP with more than 15 years of experience in the IT business. He works as a Technology Architect for Trifork Infrastructure Consulting (a Microsoft Gold partner based in Denmark) and as a Technical Writer for Biblioso Corporation (a U.S.-based company specializing in managed documentation and localization services).