Exchange Team Broadens Beta 1, Releases a CTP
Exchange Team Broadens Beta 1, Releases a CTP
Microsoft has broadened the group of testers for the first beta of its upcoming Exchange 12 e-mail, calendaring and unified messaging server product, announcing March 1 that it had released a community technology preview build to its 200,000 global TechNet and MSDN subscribers.
"The CTP is a beta one release, which is still a private beta, which means that testers are bound by a Non Disclosure Agreement and cannot share the build with anyone else. However, while they can talk about those features we have announced and made public, they are not allowed to talk about their experience with working with the code and which features do and do not work.
"This is very early code and not at the point where it should be reviewed," Megan Kidd, a senior product manager for Exchange, in Redmond, Wash., told eWEEK.
However, the second beta for Exchange 12, due this summer, will be publicly available and anyone can then review and talk about the code, she said, adding that are no current plans for another CTP release.
The Exchange team has received a good deal of feedback since it released the first beta for the product last December, particularly around two features: local continuous replication and cluster continuous replication.
Ray Mohrman, a technical product planner for Exchange, said these features are essentially high availability solutions and are designed to meet the IT demand for increasing availability of their systems.
Messaging solutions like exchange are becoming increasingly core to the way companies conduct business, and they are always looking at ways to make sure that system is always available, he said.
"In Exchange 12 we took an approach of being able to provide a scalable solution that could fit a number of customer requirements.
"So, looking at local continuous replication first, this is really bringing affordable, enterprise ready continuity for our small and mid-market customers, those rich failover solutions that larger companies have implemented," he said.
"This is a way that we can do some log file shipping, create a replica database of a real production environment so if there is any disk failures or possible corruptions or hardware problems, it will be able to fail over to a copy really quickly," Mohrman said.
This is far easier and quicker than having to restore from a backup, where users have to find their tapes, mount them and restore them.
"With this system, users can just flop right over to the second copy," he said.
This solution is also integrated into the Exchange System Manager, which is the console used to manage everything in Exchange.
Next Page: Integrated solutions.
Using this, IT managers can choose the database they want to have this replication availability and then launch a wizard that takes them through where they want those files to be located.
Then, the Exchange System manager will automatically set up a copy of the database, seed that with the data that is already in production, and replay the system log files.
"In the case of failover here, the system administrator gets an alert of the failure and goes into the Exchange System Manager and points it to the replica system rather then the production one, which then gets dismounted, turned off and the new system gets mounted in its place and turned on," he said.
The information worker would see that the system had gone down, but would be back up and running as soon as the system had been swapped over.
They would also not have to reconfigure anything in outlook, he said.
The second solution, cluster continuous replication, works in a cluster environment and allows large enterprise customers to scale up to very high levels of availability and allows failover between geographically dispersed sites.
"These solutions are integrated into Exchange 12, and we did this work at the underlying Jet database level in Exchange.
"Some of the benefits there is that overall backup costs are reduced and the frequency of backups for archiving purposes or for a really catastrophic disaster can be really closely looked at.
"Also, those backups can now be taken off that copy, so the production database is not actually impacted," Mohrman said.
This is also an affordable solution in that it is not tied to any hardware or storage solution or hardware configuration, and customers, based on their availability needs, can choose how they set up this continuous replication and use direct attached storage or SANs, multiple or single servers, he said.
This solution can also be set up to do automatic failover, so if the active node of the cluster fails, the system automatically folds over to the copy, he said.
As Exchange 12 runs on the built-in Jet database, both of these solutions will not work with SQL Server or other databases like those from Oracle.
"This was done by design as it is an environment that they are familiar with in the Exchange area," he said.
Microsoft has received a lot of feedback from beta one testers on the cluster continuous replication and the new topologies it enables for customers and being able to failover between geographically dispersed sites and the fact that they can relook at their storage solutions and still have high availability, he said.
The current Exchange product has "dial-tone" databases that allow administrators to failover to a partial while they are restoring the system.
While that gives continuity, they do not have full access to the data for a period of time.
Microsoft also has the hosted Frontbridge availability services.
Asked by eWEEK if the decision to just have a 64-bit version of Exchange 12 impacted these high availability solutions at all, Mohrman said it is "remotely related to this in that we are able to have an increased number of databases in the environment from a memory standpoint, and that allows us to have a more granular level of availability."
But some open competitors like Julie Hanna Farris, the founder and chief strategy officer of Scalix Corp., a messaging infrastructure company based in San Mateo, Calif., have criticized the underlying architecture of Exchange.
They say it "suffers from more than its fair share of reliability and security problems, the fundamental causes of which have not been addressed in Exchange 12."
The Exchange message store, based on the Jet database, is prone to corruptions and is difficult to manage and maintain, she said.
"This is a long-standing, known problem, and plans to replace the Exchange message store have been iteratively postponed."
At the same time, Exchange upgrades have come to mean a perpetual rearchitecture of customers e-mail environments, she said.
For example, with Exchange 12, the requirement for 64-bit hardware means that customers will once again have to upgrade their hardware to use Exchange 12, she said.
But Mohrman said the ability to reduce the impact of customer disk systems in the environment and the capital cost reductions in their disk networks far outweighs any cost they incur in adding new 64-bit hardware.
Also, while Microsoft does see advantages of having a unified store with SQL Server, and this was evaluated for Exchange 12, the improvements made to the underlying Jet database benefit high availability and the standardized interface into the Exchange system.
"We have made improvements to those areas that customers wanted, and the Jet database is very highly tuned for messaging and for doing e-mail, and we have given this feedback to the SQL Server team who have been making changes to that system. We will continue to look at a unified store going forward," he said.
Editors Note: This story was updated to correct information about the privacy of the beta.
Check out eWEEK.coms for Microsoft and Windows news, views and analysis.