It has been announced that the final code for Exchange Server 2010 has been signed off as complete so it should be with us soon as this is a big milestone towards RTM. By the looks of things Microsoft may launch Exchange Server 2010 at TechED Europe.
The announcement can be found on the Exchange Team Blog Here
Exchange Server clustering has been with us since Exchange Server 5.5 but left Exchange Administrators having to know the complexities of Microsoft Clustering and Microsoft Exchange in order to support it. With the advent of Exchange Server 2007 Microsoft introduced new clustering options to the Exchange server product line that gave messaging architects increased flexibility in deploying highly available systems, but there were still limitations such as:
Microsoft are acknowledging with Exchange Server 2010 that the configuration and support of the Windows Cluster required additional skill sets and added complexity to the server build and ongoing support. With Exchange Server 2010 Exchange clustering as we know it and replaced it with the Database Availability Group (DAG) which combines and improves on the best parts of the CCR and SCR technologies from Exchange Server 2007. The benefits of a DAG are as follows:
To assist with the creation of the Database Availability Group there has been another fundamental change to Exchange Server 2010 which is that the MAPI end point for Outlook access has now been moved onto the CAS role, this provides users with a single access point for client requests no matter which server their mailbox is active on. For multiple CAS server deployments a CAS array needs to be configured which I have talked about in a previous post.
As previously mentioned the DAG is configured after initial install and still uses components from Windows failover-clustering however the difference now is that Exchange Server will configure the clustering options that it needs for you as part of the DAG creation so the Exchange engineer only needs to know how to configure the DAG.
Database availability groups can consist of up to 16 servers and within each DAG there can be up to 16 copies of any given mailbox database. The DAG uses the log shipping technology introduced with Exchange server 2007 to maintain copies of the database on multiple servers for which differing log replay times can be configured (up to 1 week lag).
Each copy of the database is given a “Preferred List Sequence Number”, this is essentially tells the CAS server in which priority it should try and connect to the database and also the order in which the DAG will try to fail over to the next copy of the database, so if the database with Sequence Number 1 fails, the DAG will bring the database with Sequence Number 2 online and so on. The CAS server will then route requests for that database to server with the online copy of the database.
So in the diagram above if the database DB1 on Server 1 goes offline then the Database Availability Group will automatically bring the DB1 database copy on Server 2 online and so on with Server 4 should the database on Server 2 not be available. A time of around 30 seconds is being mentioned for a database copy to be brought online by the DAG.
The diagram above shows a four server DAG with copies of the database distributed across the servers. The general advice currently from Microsoft is to have fewer large DAG’s rather than a large number of smaller DAG’s. The database does not have to be replicated to all or any servers depending on requirements. In distributed environments the placement of database copies could be quite important.
As the client is now connecting in via the CAS server, they should not experience any disconnection from the server but there will be a short outage will the database copy is brought online.
With respect to Public Folder databases, these are not replicated between servers by the Database Availability Group. Public Folder high availability still relies on Public Folder Replication between servers.
With regard to the Hub Transport Dumpster this has also been optimized for the new failover model and messages are only retained in the dumpster until it is recorded that the message has been replicated to all database copies, this assists with bringing the database copies online as only messages that have not been replicated need to be requested from the Dumpster.
When I first started to seriously look at the Beta version of Exchange 2010 that has been released by Microsoft I saw the term CAS Array mentioned in various articles on the internet but not a clear definition of what an CAS Array is or how to configure it so I had a look into it in our Exchange 2010 lab.
In simple terms a CAS Array is a set of Exchange 2010 CAS servers that are load balanced using either Windows Network Load Balancing, Microsoft ISA Server or a third party load balancing appliance. For the vast majority of the CAS functions this is very similar to load balancing the CAS role in an Exchange 2007 Organization.
However with the advent of Exchange Server 2010 the MAPI endpoint has also now been moved onto the CAS role and is no longer on the Mailbox role as was the case with all previous versions of Exchange Server. Without configuring a CAS Array the Outlook client will connect to a single CAS server within the Active Directory Site and the connection would fail should that CAS server go offline.
So the array configuration takes two steps which are:
1. Configure the CAS servers in a Windows Network Load Balancing cluster.
2. Configure the CAS Array in Exchange.
It is also worth mentioning now that with Exchange 2010 that what we have known in the past for Exchange clustering has now been replaced by Database Availability Groups (DAG) and that CAS and HUB roles can now be collocated with the Mailbox role when a DAG is configured. However DAGs still utilize components of Windows failover-clustering and as such should not be mixed with the Network Load Balancing that comes with Windows Server. In these instances Microsoft ISA server or a 3rd party appliance would have to be used to provide the load balancing functionality and the CAS Array configured to point to these devices.
Step 1 – Configuring the NLB
I am not going to re-invent the wheel here as Henrik Walther already has a very good article on creating an NLB for CAS servers here. I created an NLB with two Exchange 2010 CAS servers using the FQDN internalarray2.2k10.dom as the NLB cluster address.
The only difference that I made over what Henrik Walther describes for the NLB setup is that in order to accommodate MAPI connectivity on the CAS role through the NLB I added in a port range for TCP port 135 to expose the RPC endpoints and for the port range TCP 1024-65535 as I did not know which port the MAPI endpoint was being published or if the port used by the Exchange 2010 CAS server for MAPI can be fixed.
Step 2 – Configuring the CAS Array
Configuring the CAS Array is quite straight forward and can be done with few Powershell commands.
1. Open up Exchange 2010 Powershell
2.Type in this command to create the CAS Array in the Exchange organization
syntax : new-clientaccessarray –name <name of array> –fqdn <DNS FQDN of the Array>
Example : new-clientaccessarray –name “InternalArray1” –fqdn internalarray1.2k10.dom
It is worth noting here that there can be only one CAS array configured per Active Directory Site. Also while creating a new Mailbox database in the AD site, the value for the CAS Array was automatically picked up.
3. The next Powershell command to run sets an attribute on the mailbox database its self. This attribute is used to tell connecting clients which FQDN they should connect to in order to access this database.
This example sets the value on all mailbox databases…
syntax : get-mailboxdatabase | set-mailboxdatabase –rpcclientaccessserver <DNS FQDN of the Array>
Example : get-mailboxdatabase | set-mailboxdatabase –rpcclientaccessserver internalarray1.2k10.dom
4. Finally the setting can be checked using Powershell as can be seen in the above example
Example : get-mailboxdatabase | select name,rpcclientaccessserver | fl
Checking client Access
The last step is to verify that client access is using the new URL so I created a new Microsoft Outlook profile using the CAS Array FQDN as the server name and typed in the details of a test user. As can be seen in the screen shot below, the profile creation was successful.
This article was written based on Microsoft Exchange Server 2010 Beta 1 and as such is subject to possible change as software features may be added or removed.
In my previous post on this topic I discussed at a high level how the Inter-Organizational Replication tool works to synchronize Free/Busy information between Exchange Organizations and then discussed some of the problems that could occur at a later date if a migration was then attempted to consolidate the Exchange Organizations.
In this post I will discus how to resolve this problem so that a tool such as Quest Migration Manager for Exchange (QMM-EX) can be implemented and continue to synchronize Free/Busy information as it is not supported to run the two tools in parallel.
The first problem that we have to do is remove any Free/Busy messages from the Exchange Organization in Domain A for objects from the Exchange Organization in Domain B and vice-versa.
One way of doing this is to use the utility MFCMAPI to open up the relevant section of the Schedule+ Free/Busy Public Folder and simply delete the Free/Busy messages. This is fairly straight forward and quick to do but does lead to an unavailability of Free/Busy information within the Exchange Organization.
If we were now to enable the calendaring agents within QMM-EX again now we would hit upon another problem that can badly effect Exchange migrations if it is not carefully considered not just within Calendar Migration but also within Public Folder migrations. Within the log files we would see SYNC_E_OBJECT_DELETED errors.
Basically what is happening here is that QMM-EX is trying to re-create the Free/Busy message in the target Public Folder Database but it can’t as the PR_SOURCE_KEY already exists. But did we not delete it?
The problem here is that when objects are deleted in the Public Folder database they are not actually deleted. Similar to other components of Microsoft systems the objects in the Public Folder tree are actually tombstoned to be permanently removed after the tombstone expiration interval. As such QMM-EX is unable to create another object with the same PR_SOURCE_KEY.
So what are the options? We could reduce the tombstone expiration interval to 1 day which would may be fine in a small environment, but there is another consideration here in that only 500 tombstoned objects are removed per day. So if there are thousands of Free/Busy messages there would be a waiting game while the objects clear out of the database, all the time remember though users are being impacted as Free/Busy information has been removed.
The only way of speeding this up is to change the PR_SOURCE_KEY of the Free/Busy messages in their relevant source Exchange environments but we can’t just go and change the value of the PR_SOURCE_KEY.
The solution is in the use of a utility that is only available from Microsoft Support. The GUI version is called UpdateFB.exe and there is a command line version called CPPCDO.exe. These utilities can be used to rebuild Free/Busy information based on the content of mailbox calendars but before running through this process we have to delete the remaining Free/Busy messages for users using MFCMAPI as we did earlier in each Exchange Organization for the users from the source Exchange Organizations.
Figure 1 – GUI Version of UpdateFB.exe
We now have in the example described in Part 1 of this article two Exchange Organizations with no Free/Busy information. The first task when using UpdateFB.Exe is to generate an import file for the mailboxes we want the utility to process, the import file needs to contain the alias of each mailbox and the NetBIOS name of the Exchange server where the mailbox is homed. When we run the UpdateFB.Exe utility with a suitable service account it will go through all of the mailboxes specified in it’s import file and rebuild the Free/Busy information based on mailbox calendars and the Free/Busy messages will be recreated with a new PR_SOURCE_KEY which means that when QMM tries to synchronize these messages it will be successful.
Figure2 – Sample UpdateFB,exe import file.
Once UpdateFB.exe has completed it would then be possible to start the calendar synchronization jobs within QMM as all of the Free/Busy messages would have new PR_SOURCE_KEY values that can be synchronized and correctly associated with the migrating users in the target domain.
This process needs to be carefully considered with other QMM associated processes and the sequence of events carefully worked out and tested to ensure that the disruption to users is reduced to the minimum possible time.
I would like to stress at this point that this is a disruptive process that must be tested and have valid backups of the Exchange environment before you try to implement this in a live environment. When you get to a live environment with this type of process you need to know that there is a good chance that everything will be ok with the process and the use of consultancy is advised.
Some organizations that are going through a merger or looking to consolidate Exchange organizations may choose to quickly install the Inter-Organizational replication tool so that Free/busy and Public Folder replication can be provided between the Exchange Organizations and then look to migrate one organization into the other at a later date using a product such as Quest Migration Manager for Exchange (QMM-EX).
The inter-organizational replication tool may be set up as shown in the following diagram where contacts are created to create a GAL in the opposing Exchange organizations and then the inter-organizational replication tool associates Free/Busy information with the contacts.
In order to understand the problem when it comes to QMM we also need to understand a bit further about how Free/Busy information is stored in Exchange Server and also how the inter-organizational replication tool synchronizes these messages.
Free/Busy information in all current versions of Exchange is stored in a System Public Folder called the Schedule+ Free/Busy. I am assuming here that Exchange 2007 is in a mixed environment with a Public Folder store and that it is appropriately configured.
If you use a utility such as MFCMAPI to open up the Schedule+ Free/Busy once the inter-organizational replication tool is in place you would see something similar to this.
If you went on to open one of the EX: folders under the Schedule+ FREE BUSY folder with MFCMAPI you would see a list of all of the Free/Busy messages related to that Exchange Organization/Administrative Group.
Without going into an in depth technical discussion over Free/Busy all we need to know at this point is that each Free/Busy message is associated with an Mail Enabled object using the LegacyExchangeDN attribute which is an internal and unique identifier which is used internally by Exchange Server. We also need to understand that objects stored within the Exchange Server databases have a property called PR_SOURCE_KEY. The PR_SOURCE_KEY is a Globally Unique IDentifier within the Exchange Organization.
The inter-organizational replication tool uses the LegacyExchangeDN attribute to associate Free/Busy messages with the contacts that are created in the opposing environments and then uses the PR_SOURCE_KEY attribute to find and synchronize the actual Free/Busy data.
A period of time can now go by where the inter-organizational replication tool quite happily synchronizes Free/Busy information before a migration project starts in order to consolidate Exchange Organizations.
I am now going to talk about the impact that this has on QMM-EX although it probably applies to similar tools from other vendors as well.
QMM-EX had has Calendar and Free/Busy synchronization built in but I need to take a small step back first at this point and actually talk about Quest Migration Manager for AD (QMM-AD). In this sort of scenario, if we say we wish to merge mailboxes from Domain B into Domain A we would use QMM-AD to migrate the user object from Domain B to Domain A. During this process QMM-AD would detect that there is an existing contact for the user from Domain B in Domain A and as such QMM-AD would create the new user account and then merge the relevant details from the contact onto the user account in Domain A before deleting the contact. The LegacyExchangeDN from the contact is turned into an X500 address and added to the new Domain A users email addresses to allow Exchange users to continue to reply-to this user. I am not going to touch any further on the email routing technicalities here as it is outside the scope of this article.
As Quest do not support synchronization products that provide similar functionality running alongside QMM we are also having to replace the contacts and Free/Busy information that is currently synchronized into Domain B and the graphic below shows how the domains look after the accounts have been migrated with QMM-AD and the contacts deleted.
The problem we have now though as we mentioned earlier is that Free/Busy messages held within Public Folders are associated with a LegacyExchangeDN, and what we have done with the QMM-AD migration is deleted the contact and its LegacyExchangeDN attribute from the Exchange organization and effectively orphaned the Free/Busy objects from any mail enabled objects in Exchange.
If were now to proceed down the route of implementing the calendaring agents within QMM-EX, they would quite happily synchronize the Free/Busy information as they work in a similar way to the inter-organizational replication tool by using the PR_SOURCE_KEY attribute to identify objects in the Exchange Stores. In this scenario the only problem is that the Free/Busy messages are still not associated with any mail enabled objects and as such users would not see any Free/Busy information.
So how do we fix this problem?
In the next part we will discuss how to resolve this problem with Free/Busy messages that have been generated by the inter-organizational replication tool but where we now wish to implement QMM.
I installed the beta1 release of Exchange 2010 into a lab today and I thought that I would share screen shots of the installation process. The installation process is almost identical to Exchange 2007.
First important point is that Exchange 2010 only installs on to Windows Server 2008. There are a number of Windows Server features that need to be installed as well as additional components downloaded from Microsoft. The requirements vary by role, but to install the Hub, Cas and Mailbox roles onto a single server the following patches had to be applied:
KB950099, KB950888, KB951725, KB958178, Powershell v2 CTP, Office 2007 Filterpack, ASPAJAXExtSetup, .Net Framework v3.5
As can be seen the install process is very similar to Exchange 2007. On my VMWare Server v2 Lab with (AMD X2 2.4GHz, 1.5Gb RAM) allocated to the virtual machine the install process for all roles took a shade under two hours with the hub role seeming to take the most amount of time to install.
Below is the Exchange 2010 Management console, which again is pretty similar to Exchange 2007.
I will be looking at Exchange 2010 some more in future articles.
The public beta of Exchange 2010 (referred to as Exchange 14 or E14) has been made available on the Microsoft Downloads site. Of course as this is beta software it should not be used in a production environment.
The public beta can be downloaded from here
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=1898ed2c-2f88-48ac-824e-d3d20fad77d7
For those who have not heard, Microsoft have just released to everywhere outside of the US their new Business Productivity Online Suite (BPOS). So I hear you cry, what is it?
Well in a nutshell, Microsoft have made available to subscribers some of it’s enterprise level applications for a low cost per month that can be resold through Microsoft Partners. The key features are as follows:
The services that are currently available through BPOS are as follows:
BPOS is offered to subscribers in two tiers. The standard service is a multi-tenancy solution where users from multiple companies share the same hardware resources. For obvious reasons this places some restrictions on what capabilities are available to users and does not allow for any customization. Microsoft also offer a dedicated version of the service that is targeted at enterprises with around 5000 mailboxes and over. In general unless otherwise specified I usually talk about the standard service. Each service can be subscribed to as separate items but is offered as a suite with a discounted rate.
All that is required to sign up to any BPOS Standard service is a subscription for 5 accounts that can be arranged with the assistance of a Microsoft Partner and Microsoft even offer a 30 day trial of the service with 20 licenses available.
Microsoft Exchange Server 2007 Online
Offers users the vast majority of the features that users see from an on-premise installation of Exchange Server 2007. Most of what could be classed as missing features are admin managed features such as managed folders and transport rules. Administrators of the BPOS service can manage licenses, quotas, users, contacts and groups, and there is some capability to manage safe and blocked senders.
From a user perspective each Microsoft Exchange 2007 Online subscription allocates 5Gb of available space although it is up to the administrator to allocate a quota to users ranging in increments from 256Mb though to 10Gb. Although a Public Folder tree is visible, it is not accessible to users or administrators.
Microsoft SharePoint Server 2007 Online
Offers users basic SharePoint functionality as a managed service. Each subscription is allocated 250Mb of storage and up to 100 site collections are allowed. The BPOS Standard service does not offer features such as the Business Data Catalogue, Excel Services, Enterprise data Search and My Sites.
The standard service will allow the following features as an introduction into collaborative working:
Microsoft Office Live Meeting
Offers users the use of the existing Microsoft Live Meeting services for multi party web conferencing and collaboration. The BPOS version of this service allows a maximum of 15 attendees but does allow attendees from external parties to attend. The service offers document sharing, application sharing, integrated VOIP and PST and video with webcam’s and Microsoft Roundtable devices.
Getting onto BPOS
Most companies that are interested in BPOS will already have some form of messaging system in place whether it be Microsoft Exchange, Novell GroupWise, IBM Notes, or other. There is a migration path for moving existing data into BPOS as users are migrated. With Microsoft Exchange systems this is a relatively rich experience in that there is a shared Global Address list but not without it’s coexistence problems and for POP3 and IMAP4 users the migration process is just a lift and shift operation.
The first of those problems is that BPOS will only talk to one forest, so come companies with complex or mixed Active Directory and messaging environments may have to complete some consolidation first or implement a more far reaching coexistence strategy. I plan to cover the migration process from Exchange in a later blog.
User Access Options
Users can access all of the applications over the internet, by using specific hyperlinks to the services. Microsoft also provide a Single-Sign-on (SSO) tool that when configure in a users profile will allow access to the applications without having to sign-on individually. It should be noted however that the SSO utility will only install onto business editions of Microsoft’s operating systems and Microsoft expect that the application will be updated as new versions are released.
One the email side of things users can access the exchange services via Outlook Anywhere, Outlook Web Access and Microsoft ActiveSync.
Client software is required for Microsoft Live Meeting online and is downloadable from the BPOS portals.
Amendment…..
11/May/2009 – Since I originally wrote this post which was based on information provided to Microsoft Partners during a training event I have since noticed that on the Microsoft download page for the SSO tool, the home editions of the Windows operating system are listed as supported.
Links
We have some interesting ideas for this blog in 2009 from the areas of inter forest migration for Active Directory and Exchange in addition to articles for other technology areas such as BPOS which really has us excited at the moment. However we would also like to blog about things that you would like to read more about! We invite you to comment on this article to suggest topics that you would like for us to cover in future articles….
Our bloggers are:
Lloyd Carnie:
Specialises in: AD & Exchange Migration, IBM Notes to Exchange Migration, Exchange Design, SharePoint, BPOS
Tim Eichmann:
Specialises in: AD Migration, AD Design, Compliance, Virtualization, Data Migration, Compliance
Joe DiCarlo:
Specialises in: AD Migration, AD Design, Virtualization, Data Migration, Novell NDS Migration
Gary Wilkins:
Specialises in: AD & Exchange Migration, Exchange Design, Archiving, Windows Server 2008, BPOS
Zulfikar Ali:
Specialises in: AD Migration, Compliance, Sharepoint, Windows Server 2008, Data Migration
