Microsoft has reached the next step in the delivery of its next-generation messaging platform with the release of Exchange 12 into its first widespread beta trial.
The Exchange 12 Community Technical Preview will go out to 200,000 technical enthusiasts who are TechNet subscribers or have a Microsoft Developer Network subscription, said Megan Kidd, senior product manager of Exchange marketing at Microsoft.
Exchange 12 is due to ship either in late 2006 or early 2007. Its first trial occurred in December but was limited to only 1,400 testers. The version released this week has fixed a few bugs but, essentially, the technology in this release and the one in December is the same, Kidd said.
The next beta, scheduled for mid-year, will be offered to the public.
Exchange 12 will be the first of Microsoft's platforms to require 64-bit hardware. The company told users earlier that some of its newer server software, due out in 2006, 2007 and beyond -- Exchange 12, Longhorn R2 and Centro -- will run on 64-bit machines.
Functionally, customers can expect the upgrade from Exchange Server 2003 to be a natural upgrade compared with the transition from Exchange 5.5 to Exchange Server 2000, said Matt Cain, an analyst at Gartner Inc., a Stamford, Conn., consulting firm.
The current beta is not feature complete. Cain said he will look for signs of the recent merger of Microsoft's Real-Time Collaboration unit and its Exchange team in the public beta. The RTC group oversees products like Office Live Communications Server.
Some of the touted features in Exchange 12 are improved filtering features, the ability for administrators to install only the components of Exchange they need, a scriptable command-line shell based on Windows Monad, and automatic client detection and configuration.
Exchange 12 will also have a feature called continuous replication for both local and clustered configurations. Local replication is aimed at small and midmarket customers. It creates a replica of the production database and as changes are happening to the production database, a log file is created and shipped to the second database not currently in production. In a clustered scenario, the production database creates logs and ships them to a passive system.