Upgrading to Netscaler 9.3

It was a no brainer upgrading my 9.2 VPX 1000 Netscalers (running the “classic” code) to 9.3 by downloading the update from Citrix and following the GUI wizard.  The process took less than 20 minutes and went without error or any downtime since my Netscalers are setup in an HA pair.  It was pretty straightforward to perform a failover, upgrade, and repeat.

What is important to note is that after version 9.3 there will be no new releases of the Netscaler “classic” code in favor of the “nCore” code.  To provide some background, with the release of Netscaler 9.2 last year, Citrix made their nCore code available to the VPX appliances as it was previously only available for the physical MPX boxes.  At the same time, the existing code set was dubbed “classic” and each new revision of 9.2x was released in both classic and nCore flavors.  The change also bumped up the minimum requirements of the Netscaler VPX from 1 vCPU and 1 GB of RAM (running on classic) to a heftier 2 vCPU and 4 GB of RAM if you are running nCore.  For environments leveraging some of the advanced content caching and acceleration features, nCore might make sense, however for ones using the Netscaler for ICA/SSL proxy and application level load balancing, there is limited value in the nCore code.  (I don’t care to go into the specific improvements to the code, architecture that nCore brings over classic, but feel free to read this Citrix Whitepaper if you are interested.)  The notable here is that after version 9.3, Citrix will no longer be releasing updates to the “classic” version of the code, thus forcing you to run nCore going forward.

Integrated Citrix Web Interface on Netscaler nCore

While technically, this has been available since 9.2 version of the Netscaler running nCore, I figured I would mention this feature in this post.  The Citrix Web Interface which is required for any XenApp or XenDesktop solution can be integrated within the Netscaler.  (This Citrix Technote shows you how.)  The ability to spin up Citrix Web Interface sites on the Netscaler appliance is an attractive solution for a number of reasons.  The first is a reduction in at least two Windows 2008 R2 servers that are typically dedicated for the Citrix Web Interface.  While this might not mean much from a licensing perspective when running Windows 2008 R2 Datacenter in a virtualized environment, an argument can be made that the all-inclusive (within the Netscaler) is simpler to manage than Windows 2008 R2 boxes that require patches and anti-virus among other things.  I usually allocate 2 GB of RAM and 1 vCPU for a Windows 2008 R2 server running Citrix Web Interface, so reducing a couple of these servers also provides a nominal reduction of resources to the virtualization solution.

One thing to note about integrating the Web Interface on the Netscaler are the implications about customizing it.  Most organizations brand their Citrix Web Interface to some degree.  This might mean something simple as adding a banner, logo, disclaimer, or something more complex that includes custom fields, embedded links, etc.  Completing these customizations on a Windows/IIS server is significantly easier for Systems Administrators than completing them on the embedded web server of the Netscaler.  While Citrix does provide a GUI driven interface to customize the logo and banner, advanced customizations of the integrated Web Interface can be challenging.

Over the next week, I’ll be upgrading my environment with integrated Web Interface on my 9.3 Netscalers to replace my existing Windows 2008 R2 based Web Interface servers.  I plan to follow up this post with my thoughts, findings and successes/failures in customizing it, so stay tuned.

Think about goals. Effective information technology is: focused on strategically important activities to which computing adds high value; and, of high technical quality and cost-effective. If the discussion about Project X doesn’t look to those goals, start again.

What firm leaders should expect most of IT leaders is not technical details, or even cost details, but a hierarchy of returns: effective communications; transparency; predictability and consistency in operations and costs; economy and efficiency; and, at the top, of course, business value.

Law firm IT budgets are often a muddle of numbers. They should be organized not by system or software but by service—not what the firm is buying, but what it is getting. They should include both capital and operating expenses, again by service or function. Capex is different from opex only in timing. Every capex creates an opex—we bought it, now we need to run it. Telecoms, operating and staff costs usually exceed capex purchase costs by a long dollar.

IT budgets plotted over time tend to be roller coaster curves. They should be flattened out—unless the firm is growing in huge leaps, costs should be managed to be relatively constant from year to year. That avoids surprises and anxiety for the partners, and allows effective planning. Think about financing via loan and lease, and plan to stage work over a long period. Don’t think, “I’ll do X and Y this year, then do nothing for five years.” It’s not cheaper in the long run, and service can’t be consistent.

Think about IT projects in logical chunks. No one way to slice the apple is “correct,” and you will likely need different views for different purposes. One starting point is The Stack: infrastructure; operations; the applications platform; core applications; and practice applications.

IT Architecture Stack

Several other approaches to slicing the apple are illustrated in the attached presentation, from a talk to the most recent Canadian Bar Association Law Firm Leadership Conference. In one way or another, all the approaches are intended to elicit discussion of the firm’s business goals and how IT can serve those goals. For example, Richard Susskind’s famed Grid and more recent Spectrum of Evolution are used to organize thinking about linking IT and business strategy.

Another approach focuses on what’s broken and what’s not. In this graph, we prioritize potential projects by plotting them on two axes: importance to the firm’s business; and quality of current service.

This, like the other approaches, is not universally correct. It is simply useful, one way to guide conversation away from technical trivia to strategic impact.

So why do I think is this rumor relevant again?  Last week, Citrix released the Citrix Access Gateway VPX 5.0.  Along with this release came a significant licensing change that cuts into the CSG’s value.  The Access Gateway’s “Platform License” ($995 retail) includes unlimited connections to XenApp/XenDesktop through the Access Gateway.  The “Universal” CALs (Access Gateway licenses) still exist, but now differentiate the VPN, Smart Access other traditional AG features.

So what does this mean?  This means that organizations that only want the SSL proxy functionality of the Access Gateway can do it at it a significantly lower price point than previously.  The price point is lowered because the (expensive) “Universal” licenses are no longer required for SSL XenApp/XenDesktop connections.  If Citrix were to stop supporting or developing the CSG, there is now a viable option from a price point perspective to its existing CSG customers.

Now that we have that squared away, someone would ask the obvious “Why should I pay for the Access Gateway VPX with a platform license, if the CSG is still free?  Free is still better.” – Fair question.  The value is in the new functionality included with the 5.0 platform of the Access Gateway.  The most obvious feature is the new High Availability feature on the 5.0 platform.  AG now supports running in an active/passive configuration on all appliances running 5.0 with the platform license.  This is something the CSG currently does not do and this reason alone is enough to consider moving to an AG 5.0 based appliance.

The other reason is to be forward thinking and understand that although the CSG serves a need today, it is obvious that Citrix is moving towards the AG platform.  While this might mean more of an investment now, the expectation is that it will pay off with newer features and functionality that comes with the AG platform going forward.

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!

• 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 5 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 5000 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.

Update:  As of 10/27/10, Microsoft has confirmed that this registry value can be configured as 5000 and result in a 5 second polling frequency.  It was previously documented that anything below 10000 would have no additional effect on Outlook polling.

Update:  This specific issue, related to UDP notifications, was formally resolved in April 2011 via Update Rollup 3 v3 for Exchange 2010 SP1 (see http://support.microsoft.com/kb/2009942 for information and the steps to re-enable UDP notifications).  Unfortunately, there were some additional permutations of this type of problem discovered for all versions of Outlook when operating in Online Mode, not just Outlook 2003.  These have been resolved in Exchange 2010 SP2 (see http://support.microsoft.com/kb/2579172 for more information).

• 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.

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.

Provisioning Services allows for server consistency, easier maintenance, dynamic servers, and aids in disaster recovery.

• Consistency – As a best practice every XenApp server delivering the same applications should be 100% identical to the rest of the farm. However, obtaining this is easier said than done.  By streaming the same image to every server, each server is inherently and 100% the same as the rest.
• Maintenance – Updating and patching large farms can be a very time consuming task, and anything done to one server must be repeated for the entire farm to maintain consistency. With PVS, patches and software installations are applied once to the master image and on next reboot, each XenApp server boots the new updated image. In addition to software patching and installation, Terminal Servers need to be completely refreshed periodically to keep them clean and performing optimally; they are used by dozens of different users, reducing performance and resulting in inconsistent servers. A typical server refresh requires the server to be re-imaged and the software redeployed, a time consuming process that can be prone to error, leaving a server in an unusable or inconsistent state. Operating system streaming with PVS results in a completely fresh and optimized server on every reboot.
• Dynamic – PVS allows for a dynamic XenApp farm instead of a static one. As load rises and additional servers are needed, they can be quickly brought online in seconds instead of hours. Conversely, as load drops, un-needed servers can be powered off or repurposed as needed. A server becomes a vessel for different workloads and can be a XenApp server one day and an IIS server another if need be. Since Provisioning Services is capable of streaming to both physical and virtual servers, administrators have the ability to utilize different types of resources all from the same master image(s).
• Disaster Recovery – Creating a disaster recovery plan for the XenApp environment often requires complex processes, scripts and configurations. Assuming a PVS server has been built in the DR site, and that the master image has been replicated as well, quickly bringing an entire farm of XenApp servers online becomes a simple task.

Creating a XenApp environment that is more dynamic and easier to maintain is a goal for many XenApp administrators. The addition of Provisioning Services to a XenApp implementation can go a long way to achieving those goals. By leveraging the single-image management capabilities of PVS, administrators can dramatically reduce the costs involved with deploying and maintaining their XenApp farms. While at the same time, guaranteeing consistency between and ensuring peak performance of each server in the farm. All while being capable of quickly adapting to changes in load and disaster scenarios.

Please note that Exchange 2007 SP2 and/or Exchange 2003 SP2 are required for coexistence with Exchange 2010 in the same Active Directory site.

• Dramatically Improved Storage Footprint and Large Mailbox Support – Changes in the underlying storage architecture allow for a 70% reduction in I/O over Exchange 2007 and a 90% reduction over Exchange 2003. This allows for more efficient usage of storage and results in the ability to store Exchange databases on slower/lower-cost disk such as SATA.  This makes Exchange not only better performing for larger mailboxes but also more cost effective.
• Native E-mail Archiving – With Exchange 2010, basic archiving features are now included natively, allowing firms to reduce the footprint of production mailboxes and improve client-side Outlook performance.  While this functionality may not be as feature-rich as third-party solutions and even though it requires a to-be-released Outlook 2010 client to support it (or OWA 2010), it does present a much needed piece of functionality that many firms have desired natively for years.
• Database Availability Groups – All of the Exchange 2007 high availability and disaster recovery methods (Local Continuous Replication, Single Copy Clustering, Cluster Continuous Replication, and Standby Continuous Replication) have been deprecated and replaced with a single concept: Database Availability Groups (DAGs).  DAGs unify the concepts of high availability and disaster recovery into a single deployment and management process, thereby simplifying it dramatically over previous versions of Exchange.
• Native eDiscovery and Compliance Features – Multi-mailbox search, legal holds, and improved retention policies all combine to increase the native capabilities of Exchange to assist with compliance processes and discovery requests.
• MailTips – Exchange can now notify users if a message violates an aspect of IT or corporate policy (sending to unauthorized third-parties or exceeding a maximum allowed message size) or if the result of sending the message may be unexpected (recipient is out of the office or a distribution list contains a large number of recipients).  This can enable users to better understand the results of sending a message and potentially reduce confusion and calls to IT.

Please refer to my three-part blog post series on Exchange 2010’s specific benefits for law firms (Part 1 can be found at http://blogs.kraftkennedy.com/index.php/2009/08/19/exchange-2010-benefits-for-law-firms-part-1-of-3/).  Check back often for additional blog posts about the new features of Exchange 2010. 

Fortunately, Microsoft built upon the technologies introduced in Exchange 2007 and improved many of the drawbacks with features introduced in Exchange 2010.  SCC functionality has been completely deprecated and CCR/SCR/LCR have been combined and evolved into the concept of the Database Availability Group (DAG).  DAGs combine high availability and site resilience into a single technology and management point to dramatically improve configuration, management, and scalability.  In addition, while a DAG does leverage some basic elements of Windows Failover Clustering, these are merely done for membership management, heartbeat, and information distribution amongst DAG members.  At its core, Exchange 2010 is essentially no longer a cluster-aware application and the concept of the CMS has been removed.  Instead, as enabled by the new requirement that all clients connect through CAS role (see my blog post here), the Mailbox server on which a user’s database exists no longer matters and can be easily adjusted based on server availability.

A DAG is essentially a group of Mailbox servers between which an administrator wants the ability to replicate mailbox databases.  A DAG can contain up to 16 Mailbox servers across multiple sites (each with their own copy of replicated databases) and, once servers are a member of a DAG, the administrator can choose how many copies of a specific database is desired, where those copies should be stored, and how far behind (if at all) replication should lag between copies.  The administrator can also define an activation preference such that, if the server hosting the active copy of a database or the database itself fails, Exchange will attempt to bring other copies online in a specific order.

Please refer to the table below for a brief comparison of features between the high availability capabilities of SCC, CCR, and DAG.  A few additional key points to note are that high availability failovers can occur for individual databases (as opposed to whole servers in Exchange 2007), DAG management is facilitated entirely by Exchange tools, and other roles can now be hosted on the same server as the Mailbox role when configured as a DAG member.

High Availability Comparison between Exchange 2007 and Exchange 2010

There is much more to talk about with DAGs and I plan to post more information about them in the future.