If you read Microsoft’s documentation and guidance regarding DAG design, you will note guidance that the greater number of DAG members that you have, the better.  This is because, with more DAG members, you can increase your resiliency in the event of member failures.

For example, with two, three-node DAGs, each DAG can sustain only a single member failure and still remain online.  Since a three-node DAG requires two voting members for quorum, two simultaneous voting member failures would result in a loss of quorum and the DAG going offline.  However, a single, six-node DAG (stretched across sites if desired) can sustain three simultaneous voting member failures before going offline.  Since a six-node DAG would require four online voting members, you could have three Mailbox server members online plus your Witness Server and sustain simultaneous failures in the three other Mailbox server members without losing quorum.

The caveat to this guidance occurs if you need an active/active data center model.  Consider, for example, that you had two data centers (West and East) and wanted half of your users to be primarily hosted in one data center and the other half to be primarily hosted in the other.   User allocation could be based on the quality of WAN link to the data center, the assignment of users to other Exchange integrated applications in those data centers (BlackBerry, document management, etc.), etc.

Under normal operations, if you placed three DAG members in one data center and three DAG members in the other, it would work fine and you would have the added resiliency benefits of a larger DAG.  However, if the WAN between your two data centers were to fail, all of your mailbox databases would failover to whichever data center contained your configured File Share Witness (if a valid mailbox database copy existed in that data center).  This is because, in the data center without connectivity to other DAG members or the FSW, you would no longer have enough voting members for quorum and the DAG would take itself offline.

While having Exchange services failover to one data center or another in the event of a WAN failure may not be an issue, it is technically a site resiliency operation that may not be desirable for end user access, integrated applications, or administrator management.  For these reasons, if you wanted each data center to remain active in the event of a WAN failure, you would need to deploy two DAGs stretched across both data centers.  One DAG would have its FSW hosted in one data center and the other would have its FSW hosted in the other data center to ensure that Exchange services remain hosted in their designated data centers, even during a WAN failure.

For more in my series on Exchange 2010 Notes from the Field, please click here.

This has been frequently blogged about by a number of people but this, in my opinion, can be one of the single biggest causes of issues when deploying a new Exchange 2010 environment. Unlike previous versions of Exchange, Exchange 2010 requires RPC encryption between clients and the server, by default. This is not an issue for Outlook 2007 or Outlook 2010 clients since both enable this encryption by default (and fail back to unencrypted communications if the server does not support it). However, legacy Outlook 2003 clients and potentially some third party applications do not enable this by default.

To enable Outlook 2003 to communicate properly, you can simply check the “encrypt data between Microsoft Office Outlook and Microsoft Exchange Server” in the MAPI profile properties (see below). You can also leverage Group Policies to enforce this setting or automate the deployment firm-wide.

Alternatively, if you need to disable RPC encryption to support other applications, you can disable RPC encryption requirement via the following cmdlet:

Set-RPCClientAccess -Server SERVER-NAME -EncryptionRequired $false

If you have multiple servers or have broken out your CAS and Mailbox roles onto separate servers, be sure to disable encryption for both your CAS servers and your Mailbox servers. While Exchange 2010 moved the RPC endpoint for mailbox access to the CAS role, the RPC endpoint for public folder access is still the Mailbox role. If you don’t disable RPC encryption on the Mailbox role as well, you won’t be able to connect to public folders from a client that doesn’t support RPC encryption.

If RPC encryption is disabled, you should make a note to re-enable it when your application set allows you so that you can further secure your environment.

For more in my series on Exchange 2010 Notes from the Field, please click here.

As I’ve discussed in a few previous blog posts, there are numerous reasons that make Exchange 2010 a compelling upgrade for firms running Exchange 2003 or even Exchange 2007.  Specifically, most of my clients have determined the general storage efficiency enhancements and high availability and site resiliency improvements of the Database Availability Group (DAG) to be so compelling as to warrant aggressive timelines for an upgrade.  As a result, since the beginning of 2010, I’ve been involved in over 12 separate Exchange 2010 projects through August 2010, from architecture consulting and design through deployment and transition.  While Exchange 2010 is a stable and robust platform, there are a few quirks or subtleties that I wanted to share for those that are planning or beginning an upgrade.

A list of topics that I plan to cover can be found below and links will be created to each post as it is released.  In addition, as I uncover additional topics to discuss, I’ll add to this list going forward.  Please check back often!

• RPC Encryption
• Multi-Site Database Availability Group Design
• Database Availability Group Name/IP Resource Failures & Maintenance
• Named Properties Quotas
• Mailbox Move “Failed to cleanup the source mailbox” Errors
• ActiveSync and Active Directory Permissions Inheritance
• Public Folder Replication and Mail Flow Issues
• Client Throttling and Max Concurrency
• SMTP Virtual Server Changes

I hope you find this topics useful as you plan for or begin your own upgrades!

Earlier this week, I was able to upgrade my firm’s research Exchange 2010 environment to SP1.  Ironically, Microsoft released their SP1 FAQ and Known Issues MS Exchange Team Blog post mere minutes after I completed but, fortunately, I did not encounter any of the issues listed in their post.  The upgrade process was very smooth with only a few minor issues.

One very frustrating revelation that I discovered while reading the comments of Microsoft’s original announcement of SP1 was that Online Archive support in Outlook 2007 is not yet available.  Microsoft had previously indicated that this support would come at the same time as SP1 but has now provided guidance that they are planning to announce this support as part of an Outlook 2007 update to be released in the first half of 2011.  This is particularly frustrating because I have many clients that were extremely interested in seeing if Exchange 2010’s native archiving features could work for them and prevent them from having to invest in a third party solution.  These firms will not be moving to Outlook 2010 in the near term and, as a result, the delay of Outlook 2007 Online Archive support is disappointing.

If you are planning to upgrade to SP1 in the near term, I strongly recommend that you thoroughly review the SP1 FAQ post and also consider the following comments.

• There is an Active Directory schema update required to support a number of new features, including mailbox auditing.  Be sure to plan accordingly and, if necessary, you can perform these updates in advance of your SP1 upgrades by running setup /prepareSchema and setup /prepareAD.
• Be careful when upgrading a DAG to minimize any downtime to end users.  I recommend proactively moving all active databases off each node before it is to be upgraded and then disabling automatic activation of any passive copies on that node (via Get-MailboxDatabaseCopyStatus -Server SERVERNAME | Suspend-MailboxDatabaseCopy -ActivationOnly -Confirm:$False -SuspendComment “Exchange 2010 SP1″).  When you’ve finished the upgrade successfully, you can enable automatic activation again (via Get-MailboxDatabaseCopyStatus -Server SERVERNAME | Resume-MailboxDatabaseCopy) and repeat the process on remaining DAG nodes.
• It is important to keep all DAG members at the same service pack level, so plan to upgrade all DAG members during the same maintenance window.  Exchange 2010 RTM can failover databases to Exchange 2010 SP1 but the converse is not possible.
• The one issue I ran into was on one of my DAG nodes, where the Mailbox Role portion of the upgrade failed with an error message of “Couldn’t resolve the user or group “domain.local/Microsoft Exchange Security Groups/Discovery Management.” If the user or group is a foreign forest principal, you must have either a two-way trust or an outgoing trust.”  This group existed in that path and I’ve never had any issues testing discovery features before.  To resolve, I simply had to delete my Discovery Search Mailbox, re-run the SP1 upgrade, and then create a new Discovery Search Mailbox (via New-Mailbox “Discovery Search Mailbox” -Discovery -UserPrincipalName DiscoverySearchMailbox@domain.local).
• I was happy to see that all of my passive mailbox database copies automatically switched to Continuous Replication Block mode (see here for more information) after the SP1 upgrade due to having completely up-to-date replication.  You can view the status of Continuous Replication Block Mode by running the cmdlet Get-Counter -ComputerName SERVERNAME -Counter “\MSExchange Replication(*)\Continuous replication – block mode Active”.  A value of 1 for a passive mailbox database copy indicates it is operating in Continuous Replication Block Mode, where as a value of 0 indicates the copy is operating in Continuous Replication File Mode.  Please note that you need to pay attention to whether the mailbox database copy is active or passive.  An active mailbox database copy will list a value of 0 because it is not receiving replication.

All in all, it was a pretty straightforward upgrade and one that should provide a host of compelling new features for firms of all sizes.

Microsoft has just announced that Exchange 2010 Service Pack 1 has been released!  Please refer to http://msexchangeteam.com/archive/2010/08/25/455861.aspx for the official announcement and download link.  Additionally, I previously discussed some of the more notable features of SP1 in blog posts here and here.  This is a compelling upgrade for all Exchange 2010 implementations and introduces a number of key new features such as the ability to host archive mailboxes on separate mailbox databases from the primary mailbox, archive support for Outlook 2007 SP2, and Continuous Replication Block Mode.

I had the privilege of attending Microsoft TechEd North America 2010 last week in New Orleans, LA and wanted to share a few confirmed new features of Exchange 2010 SP1 (due out later this year but no firm ETA).  The overall theme of this year’s TechEd was centered around, not surprisingly, cloud computing.  Specifically, Microsoft emphasized their mature Exchange Online offering but also stressed the growth of Windows Azure (Microsoft’s hosted services platform) and hosted SQL services.  The demonstrations of what Windows Azure and hosted SQL could do were extremely interesting and solidified Microsoft’s vision of being “all in” (according to keynote speaker Bob Muglia) with cloud computing.

Regarding Exchange 2010 SP1, a few of the Exchange sessions I attended had specific focus on SP1 and most of the others mentioned how different aspects of Exchange would change with SP1.  I discuss a number of my favorite changes/additions associated with SP1 below but please note that there are many more new features.  Please refer to the MS Exchange Team blog post on SP1 for more information.

Continuous Replication Block Mode

Continuous Replication Block Mode (CRBM) is, in my opinion, the most interesting and compelling new feature of Exchange 2010 SP1.  It is so important that it required a rename of the legacy continuous replication of Exchange 2007/2010 RTM to Continuous Replication File Mode (CRFM).  Basically, in CRFM or legacy continuous replication, the unit of replication in Exchange is a single log file.  Thus, after each 1 MB log file was closed on the active server (Exchange 2007) or database copy (Exchange 2010), the passive server or database copies would pull that log file and replay into the passive copy of the database.  This resulted in a worst case recovery point objective (RPO) of 1 MB (the active log stream) when replication was healthy and up-to-date.

CRBM is a dynamic continuous replication mode that is automatically turned on or off by Exchange 2010 when it detects that replication is completely up-to-date.  When turned on, CRBM allows Exchange to ship transactions committed to the active log stream to passive database copies.  Thus, the passive copies maintain their own log stream and can significantly reduce the RPO of Exchange in the event of a failure of the active copy.  However, while CRBM could bring your RPO down to individual transactions, I wouldn’t recommend advertising an RPO of less than 1 MB to a business owner since you cannot control CRBM and it may be turned off at any time.  In my opinion, it is better to advertise 1 MB and indicate that, under healthy replication circumstances, the realized RPO will likely be much better.

CRBM is not synchronous, so Exchange will not wait for an acknowledgement from the passive database copy that the log stream write succeeded.  Additionally, since a CRBM passive database copy now maintains its own log stream, it will automatically convert a partial log stream (log fragment) into a full log file for replay in the event of a failure of the active database copy.

Other High Availability and Site Resiliency Improvements

In addition to CRBM, SP1 will bring a number of other high availability and site resiliency improvements.  First, Outlook cross-site connection behavior will be more flexible by providing the option to have, in the event of a cross-site database failover, either a direct CAS connection from the CAS Array in the primary data center to the hosting Mailbox server in the secondary data center (default in RTM) or to disable this functionality entirely.  Second, Datacenter Activation Coordination (DAC) mode now becomes available for DAGs of all types, not just those with three or more members that are stretched across two or more sites.  Finally, improvements in gracefully shutting down log writes when a database activation is initiated removes the need for Exchange to perform a recovery process when a passive copy is activated.  This can reduce a typical database activation process from 30 seconds to 15 seconds.

Scott Schnoll at Microsoft has written a great article about these and other high availability and site resiliency changes in SP1 here.

Archiving and Discovery Improvements

As alluded to by Microsoft around when Exchange 2010 RTM was announced, SP1 will allow additional deployment flexibility with the Personal Archive.  First, formal support for Outlook 2007 will exist, although it will be limited to basic access to the Personal Archive.  Manipulation of retention policies and other aspects of the archive will be limited to Outlook 2010 and OWA 2010.  Second, SP1 will now allow storage of the Personal Archive in a different mailbox database than the primary mailbox.  Supported combinations of storage are primary and archive in the same mailbox database (on-premises or hosted), primary and archive in different mailbox databases (both on-premises), or primary on-premises and archive hosted.  While many law firms may find it difficult to adopt Exchange Online in the near term due to back-end application integration requirements with Exchange, the ability to host some users completely in the cloud and perhaps the Personal Archive for other users in the cloud as well is very intriguing.

Discovery becomes more robust by offering search preview to estimate anticipated discovery searches before executing a query, optional de-duplication of results in a completed discovery, and annotations for discovered content.

Outlook Web App Performance and Personalization Improvements

OWA performance has been improved dramatically in SP1 through a number of enhancements.  OWA will now pre-fetch content to make content presentation and reading faster.  Additionally, delete, mark as read, and categorization actions will now be asynchronous operations so that their results look instantaneous to the end user.  Long running operations, like large file transfers, will no longer be blocking operations that cause OWA hanging from an end user perspective.

OWA themes will make a comeback in SP1, with some prebuilt themes included and the ability to design your own (perhaps to match a corporate color scheme branding, etc.).  Furthermore, the administrator can granularly control if/how themes can be used.

Rich Coexistence with Exchange Online

Once Exchange Online is upgraded to Exchange 2010 SP1 later this year, coexistence between an on-premises solution and Exchange Online will become much more robust.  Due to the enhanced federated sharing features of Exchange 2010 (calendaring, etc.), traditional coexistence issues associated with free/busy lookups, internal mail classification, etc. are all resolved to provide much more seamless coexistence with Exchange Online.  With the ability to easily host and manage a subset of users in the cloud, this rich coexistence model makes this approach much more appealing.

As you can see, Exchange 2010 SP1 will provide many important new features to improve resiliency, flexibility, and performance of Exchange in a number of areas.  The SP1 Beta is available now, so check it out!

At a few recent client implementations, we have seen noticeable delays synchronizing various changes in mailboxes to Exchange 2010 when running Outlook 2003 in Online Mode.  As it turns out, this is a known issue and Microsoft has documented it at http://support.microsoft.com/kb/2009942.  The following are symptoms of the issue:

• Outgoing messages stay in the Outbox for up to 1 minute
• New messages do not arrive in the mailbox for up to 1 minute
• Items that are deleted or moved between folders may take up to 1 minute for the change to be reflected

This issue does not happen with Outlook 2003 in Cached Mode or in Outlook 2007/2010 in Online or Cached Mode.  The issue arises because Outlook 2003 requests UDP notifications from Exchange to determine when to retrieve messages.  When a new message arrives in an Exchange mailbox, Exchange 2007 and earlier would send a UDP notification to Outlook, which would then trigger Outlook to retrieve the message and display to the user.  In the absence of receiving any UDP notifications from Exchange, Outlook reverts to a scheduled polling of Exchange that occurs every 60 seconds, by default.

Exchange 2010 no longer issues UDP notifications to Outlook and, as a result, Outlook is then wholly dependent on its own polling frequency to retrieve new messages.  Outlook 2003 in Cached Mode and Outlook 2007/2010 are not affected by this issue because the former uses a different synchronization algorithm to send or retrieve content and Outlook 2007/2010 use an asynchronous notification process that does not rely on UDP notifications.

There are a few solutions and a workaround for the problem, as I note below.

• Implement Cached Mode for Outlook 2003 – This solution resolves the issue, as described above, but still leaves a legacy Outlook client in use.
• Upgrade to Outlook 2007/2010- We recommend that firms strongly consider upgrading the Outlook client to 2007/2010 when deploying Exchange 2010 due to all of the new features that require a newer Outlook client (OAB web-based distribution, Autodiscover, Personal Archive, etc.).  We also recommend Outlook in Cached Mode as a best practice, provided workstation hardware is sufficient for mailbox sizes.
• Reduce Polling Frequency of Outlook to Exchange – This involves the steps as outlined below to add a registry value on the Exchange 2010 CAS role to reduce the maximum polling frequency of Outlook.  While the registry value supports anywhere from 5 seconds to 2 minutes, Outlook 2003 cannot poll any more frequently than every 10 seconds.  As a result, this represents a best case scenario for Outlook 2003 in Online Mode and something where users will still likely notice delays.
  • Install Exchange 2010 Update Rollup 1.
  • On all Exchange 2010 CAS servers, navigate to  HKLM\System\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem and create a REG_DWORD entitled “Maximum Polling Frequency” with a value from 5000 to 120000 (decimal value).
    • Note that, as mentioned above, configuring this to anything less than 10000 will have no additional effect on Outlook 2003.
  • Restart the Microsoft Exchange RPC Client Access service on your CAS servers.  You shouldn’t need to restart your Outlook clients but you may want to as well.

Microsoft has recently announced some new features that will be available with Exchange 2010 SP1 (anticipated in the summer timeframe of this year).  While a more detailed list is forthcoming from Microsoft, a few highlights can be found below:

• Archiving Enhancements – With SP1, you will be able to store a user’s primary mailbox in one mailbox database and that user’s Personal Archive mailbox in a different mailbox database.  This will allow administrators to leverage tiered storage for primary and archived data.  Additionally, new server side features will allow for easy back-end PST imports directly into a mailbox.  Finally, as alluded to by Microsoft previously, SP1 will include updates that will enable Personal Archive access from Outlook 2007.  Without SP1, the only methods of access for the Personal Archive are Outlook Web App 2010 and Outlook 2010.
• Management Enhancements – New capabilities will be added to both the Exchange Management Console (EMC) and Exchange Control Panel (ECP).  Specifically, the EMC will have new tools to configure/manage Retention Policies, Retention Policy Tags, Litigation Holds, DAG IP addresses and Alternate Witness Servers, recursive public folder settings and permissions, and more.  The ECP will have new tools to configure/manage Transport Rules, MailTips, Personal Archives, RBAC roles, and more.  In summary, many tasks that previously required the Exchange Management Shell will now be available through either the EMC or ECP.
• Discovery Enhancements – Multi-mailbox search will be improved by providing a Search Preview that will provide an estimated number of results (with keyword statistics as well) before exporting the desired content to the designated discovery mailbox.  This will help discovery users understand the impact of their queries and how much data to expect before actually exporting this data.  Additionally, a search de-duplication option will be provided that, when checked, will only export one instance of each unique message to the designated discovery mailbox.  This could dramatically reduce the amount of time it would take for a discovery user to review the data exported from a query.  Finally, support for annotation will be introduced so that discovery users can include notes while reviewing discovered data.
• Outlook Web App Enhancements- Outlook Web App (OWA) gets more efficient by pre-fetching message content to make reading faster and running some actions asynchronously (delete, mark read, etc.) to make them appear faster.  Additionally, various user interface improvements will be included to reduce clutter in OWA and prevent long running operations (such as attaching files) from blocking OWA access for the end user.  A new feature to anonymously share calendars via the web will be an option as well.  Finally, OWA themes return to allow users to customize the look and feel of OWA.
• ActiveSync Enhancements- Support for send as and conversation view, along with other new features will be provided.

You can read more about these new features of Exchange 2010 SP1 at http://msexchangeteam.com/archive/2010/04/07/454533.aspx.

As mentioned in my previous blog post about the Exchange 2010 RPC Client Access Service and the ClientAccessArray, Exchange’s dependence on the Client Access Server (CAS) role has increased dramatically in Exchange 2010.  This is because, in Exchange 2010, on-network Outlook MAPI connectivity now connects to a mailbox through the CAS role via the RPC Client Access Service.  As a result, high availability of the CAS role is crucial since any failure of CAS could affect Outlook client connectivity.  For smaller implementations or those where the limitations of native Windows Network Load Balancing (NLB) are not a major problem (please see my previous blog post for more information), NLB can work well.  The process for configuring NLB is fairly straightforward and I’ve outlined the steps below.

Preparing for NLB

Once two or more Exchange 2010 servers (each with two NICs) with the CAS role installed have been deployed, you are ready to start configuring NLB to provide high availability and load balancing.  First, you must allocate a dedicated private IP address and create an associated A record in DNS for the NLB cluster.  This IP address and name are what clients will connect to and against which the ClientAccessArray will be created.  In this blog post, I will use 10.1.240.100 and EXCHCASArray.client.local.  Please note that the IP address should be on the same subnet as the two CAS servers that will become members of the NLB cluster.

NLB can be configured either in unicast or multicast mode.  The former changes the MAC address of each NLB cluster member’s NIC to a virtual cluster MAC address, to which clients connect.  The latter allows the NICs to maintain their existing MAC addresses and adds a virtual cluster MAC address.  Unicast is the preferred method for NLB, so I will explain the process for this method in my details below.

To simplify the management of your NLB cluster members, I recommend that you name each NIC’s network connection so that it is easy to understand what function the NIC serves.  For example, as depicted below, I have named the connections “Public LAN” (used for communication with clients and servers on the network) and “NLB LAN” (used for internal NLB heartbeat).  This process should be repeated on all NLB cluster members.

The Public LAN NIC on each server should be configured normally, with an IP address, subnet mask, default gateway, DNS servers, etc.  For this example, I will use EXCHCAS01 (10.1.240.101) and EXCHCAS02 (10.1.240.103) as my two CAS servers.  The NLB LAN NIC on each server should be configured with an IP address and subnet mask only.  For this example, I will use 10.1.240.102 for EXCHCAS01 and 10.1.240.104 for EXCHCAS02.

Once the NICs have been configured, we must ensure that the binding order is configured to bind the Public LAN NIC first.  Within the Network Connections window, click Advanced, Advanced Settings and modify this if necessary.  Be sure to press the ALT key first to bring up the File menu in Windows 2008.

Configuring NLB – First Member

On each NLB cluster member, NLB must be installed.  With Windows 2008, this can be completed simply by running the command “ServerManagerCmd -i NLB” via a command prompt.  Once NLB has been installed, launch the Network Load Balancing Manager to continue the configuration process.

To create your new cluster, you can right-click Network Load Balancing Clusters or simply click Cluster, New.  In the New Cluster wizard, enter the name of the first server in the NLB cluster (for example, EXCHCAS01) and click Connect.  This will display the available NICs on the server, at which point the NLB LAN NIC should be chosen before clicking Next.

Since this is the first member of the NLB cluster, you can leave the all of the Host Parameters at their default values, as depicted below.  Please note that the Priority value should be configured as 1 for the first member.

Next we must configure the IP address and subnet mask of the NLB cluster, which is the IP address for which we created a DNS A record at the very beginning of this process.  In this example, this would be 10.1.240.100 and 255.255.255.0, respectively.

For the Cluster Parameters, we want to enter the FQDN of the DNS A record we created at the very beginning of this process (EXCHCASArray.client.local).  In addition, Unicast should be selected as the desired clustered operation mode.

The next screen allows you to configure port rules so that you can restrict what traffic is allowed across the NLB cluster IP address.  For Exchange 2010 CAS, I recommend that the default port rule of 0 – 65535 be replaced with port rules to allow only 80 (HTTP) and 443 (HTTPS).  This is especially important if servers hosting the CAS role also host other functions, such as the Hub Transport Server role.  If you require IMAP or POP3 connectivity to CAS in your environment, you will also want to add port rules for 143 and 110, respectively.  I’ve depicted the configuration of a port rule for port 80 below. 

Update: Please note that, for internally facing CAS servers front-ending MAPI traffic, you will also need to create port rules for TCP port 135 (RPC Endpoint Mapper) and TCP ports 1024-65535 (the dynamic port range for Outlook RPC access).

Once all of the desired port rules have been configured, you may click Finish to complete the configuration of the first NLB cluster member.

Let the NLB cluster converge with its first member and you should eventually see the cluster report success.

Now you can proceed with adding your second cluster member.

Configuring NLB – Second/Subsequent Member

After the configuration of the NLB cluster itself and the first NLB cluster member has been completed, you are ready to add additional members.  Provided that NLB has been installed, you can simply right-click on your NLB cluster in the Network Load Balancing Manager and click Add Host To Cluster.

Enter the name of the second NLB cluster member, for example EXCHCAS02, and click Connect.  Be sure to choose the NLB LAN NIC and click Next.

On the Host Parameters screen, ensure that the Priority is set to 2 (or as appropriate, depending on how many cluster members you have) and click Next.

Confirm that your port rules are accurate and, if they are, click Finish to add your second NLB cluster member.

Let the NLB cluster converge with the new member and, eventually, it should report success.

At this point, you have an NLB cluster with two members!

Next Steps

Before you start using your new NLB cluster for CAS functionality, you should complete two final tasks.  First, IP forwarding should be enabled on each cluster member’s NLB LAN NIC.  By default, Windows 2008 disables IP forwarding, which causes problems with NLB.  IP forwarding enabled allows, from an NLB perspective, requests sent from one NIC to be sent out the other.  IP forwarding can be enabled on your NLB LAN NIC by running netsh interface ipv4 set int “NLB LAN” forwarding=enabled from a command prompt.

Finally, you will want to configure a ClientAccessArray within Exchange 2010 to represent your new NLB cluster so that Outlook clients will not simply resolve your NLB cluster name to a participating member and store that member’s name in the MAPI profile.  Please refer to the instructions in my previous blog post for how to configure a ClientAccessArray.

Microsoft has just announced that Exchange 2010 is now globally available!  Please read more information at the MS Exchange Team blog at http://msexchangeteam.com/archive/2009/11/09/453096.aspx. 

Exchange 2010 binaries are now available for download.