Microsoft published a very interesting whitepaper about their use of Exchange Server 2007 and Cluster Continuous Replication (CCR). I was surprised to learn that they use DAS instead of a SAN-based solution. When you think of it, it makes sense because it eliminates some complexity and dramatically lowers the implementation costs. A big advantage of that design is that it avoids what they call hot-spot contention when another workload is using the same spindles as Exchange Server 2007.

All in all a very interesting read! You can find it here.

A while ago I did a talk at the Microsoft Techdays in Belgium about migrating from public folders and file servers to SharePoint. In that talk I mentioned the fact that public folders are not dead and that you can continue to use public folders if you really want to. I mentioned the guidance from a blog post at msexchangeteam.com and that guidance has now been updated. You can find the updated guidance here.

The guidance boils down to these main points:

1. Public Folders have full support for 10 years after the release of the next version of Exchange Server. That is longer than the initial reported date of 2016.
2. SharePoint is the better option for document sharing and custom applications (e.g. workflow) even if you currently use public folders for this.

For many users, the strength of public folders comes from the fact that there is full Outlook integration. It is easy to drag and drop e-mails as msg files in public folders or share things like calendars and contacts. Although some of these things can be done with Outlook 2007 and SharePoint, the features are not exactly the same. Outlook 2007 does not do two-way sync or allows you to drag and drop e-mails as msg files in document libraries. A tool such as Colligo Contributor is needed if you need those abilities. Colligo Contributor works really well and is worth having a look at.

Another strength of public folders is the built-in replication. SharePoint does not do replication but there are several 3rd party tools that can do it such as those from Infonic.

It would be great if the next version of SharePoint would include features such as replication and better Outlook integration because that would make it even easier to migrate without having to incur extra (potentially high) costs for these extra features.

This is the one that most of us have been waiting for because the adoption of Exchange Server 2007 is rather slow. Service Pack 1 provides a lot of features that were missing from RTM and a lot of extra features as well. The most notable new features are SCR (Standby Continuous Replication) and Windows Server 2008 support. Some other cool stuff:

• Import/Export from and to PST files with PowerShell commands
• Public folder administration with the GUI
• Support for Office 2007 formats in OWA
• More OWA features like S/MIME support, public folder support and rules
• Extra ActiveSync policies for mobile devices

Go ahead and download from here.

Remember that you can deploy Exchange 2007 from scratch directly from the SP1 download because the service pack is effectively RTM+SP1 slipstreamed!

On the Microsoft Exchange Team Blog, Scott Schnoll writes about Exchange Server 2007 in combination with Exchange Server 2008. Among other things, he writes that rolling cluster upgrades are not supported. This means that if you have existing Windows Server 2003 clusters, you need to build a new Windows Server 2008 failover cluster and move mailboxes with the Move Mailbox operation. This is not a limitation posed by Exchange. Rolling upgrades from Windows Server 2003 to 2008 are not supported in general (see this).

More details: You Had Me At EHLO... : Exchange Server and Windows Server 2008

Note: I already tried to install Exchange Server 2007 SP1 Beta 2 on Windows Server 2008 and the process failed during the configuration of the client access role when the virtual directories are created (new-owavirtualdirectory cmdlet). The other roles work fine (mailbox, hub transport).

VMware published a whitepaper about Exchange Server 2003 performance on VI3. It is an interesting read because it shows that it is perfectly feasible to run Exchange Server 2003 boxes with 1000-2000 or more users. Loadsim was used to do the testing so you have to factor in some extra headroom for antivirus and backup procedures. The whitepaper also shows that the virtualization overhead is mainly for the CPU and not for other components such as storage and networking. Because Exchange Server 2003 is effectively limited to 4GB, you can drive up utilization by using a large VMware box with 16GB of memory and lots of cores and run multiple virtual machines with Exchange. Of course, that is the technical side. Many of our customers still don't feel at ease with putting such a critical piece of their infrastructure on a virtual machine but I guess that will change over time.

Of course, it would be more interesting to see Exchange Server 2007 performance on VI3 because Exchange Server 2007 is so radically different from its predecessor. Exchange Server 2007 is a 64-bit app so it does not have the memory limitations of Exchange Server 2003. I hope they will publish a whitepaper about Exchange Server 2007 soon.

Get the whitepaper here.

To recover Exchange data with DPM, you first need to select a recovery point. The Recovery section of the management console contains a handy calendar to select such a recovery point. Every bolded date contains recovery points:

Most of the time, you will need to recover user data on the mailbox level instead of the entire database. You first select a time to go to (usually not Latest) and with a double click on the name of the database, the mailboxes in the database are shown. You can then right click on a user and select Recover... to start the wizard-driven process. The options in the wizard are simple and usually you will recover to an Exchange server database in a recovery storage group:

DPM does not create the recovery storage group for you so you need to create one using PowerShell cmdlets or the Exchange Server 2007 Troubleshooting Assistant. If you use Exchange Server 2003, you just create the recovery storage group with the Exchange System Manager. In the screenshot above, you can see I restore to a database called Mailbox Database in a recovery storage group called RSG. When you reach the end of the wizard and start the recovery, you can switch to the Monitoring section to check the recovery status.

NOTE: don't think that because you restore on the mailbox level that you can get a PST. The DPM restore is always a mailbox database (edb) and log files. You need to use Exchange tools to get a PST if you wish.

When the database is restored, the work in DPM is finished. You now need to use Exchange tools to mount the database in the recovery storage group and recover the mailbox data. A few options are available:

• You can use the Troubleshooting Assistant (Exchange 2007) to merge the content of the user's restored mailbox with his current mailbox.
• You can use the restore-mailbox cmdlet (Exchange 2007) to copy the user's restored mailbox to a subfolder of another mailbox.
• You can use ExMerge 2003 (Exchange 2003) to do the same as restore-mailbox or to export to a pst file.

The restore-mailbox cmdlet works like this:

restore-mailbox -id "Administrator" -RSGDatabase "RSG\Mailbox Database" -RSGMailbox "Geert Baeke" -TargetFolder "geba"

The above command restores the mailbox of Geert Baeke (in the Mailbox Database of RSG) to the live mailbox of Administrator in a subfolder called geba:

Conclusion

It is very easy to recover Exchange 2003/2007 data with DPM 2007. I only touched on recovery of individual mailboxes but there are other possibilities like restoring entire mailbox databases to the original location, to a network folder and so on. The keyword here is flexibility!!! Later posts will show how to recovery data from other workloads like SharePoint and SQL Server.

Microsoft released four deployment guides for several types of organizations:

• Simple organization
• Standard organization
• Large organization
• Complex organization

Naturally, there is quite some overlap in all four guides. The guides also contain an introduction to Exchange Server 2007 management with PowerShell.

All of this documentation is also available in the Exchange help files but they are more convenient to read in Word format.

At the Exchange Server 2007 TechCenter, there is an article called Exchange Server 2007 Deployment: 10 Tips When Installing. Microsoft has tried to make the Exchange Server 2007 installation experience as easy and flexible as possible. They have largely succeeded at doing so. This does not mean you can just go ahead and run setup without thinking so read up on the technology, test it and plan, plan, plan...

From the article, a couple of things are interesting:

• You always need to install the Hub Transport role. Every mail that is sent will pass through this server. It makes journaling, rules, building ethical walls etc... much easier. In most deployments, you will put the Hub Transport and Mailbox role together on one server.
• The cluster installation process is integrated in setup. You get a checkbox in the installation wizard for the active node and one for the passive. For an overview on how to setup CCR with two nodes, check out my tutorial based on beta 2. Also check out the videos on the Exchange Team's blog.
• Exchange Server 2007 setup can be delegated to another user.
• Think about routing groups in the scenario where Exchange Server 2003 and 2007 coexist. Some more information about this can also be found here.

Check out the complete article, it is well worth the read.

Microsoft has posted details about the available editions of Exchange Server 2007. You can find them here. The Exchange Server 2007 Standard Edition is interesting because Microsoft have removed some limitations when compared to Exchange Server 2003. The most notable changes are:

• Support for five mailbox databases and storage groups (only one in Exchange 2003).
• Unlimited database sizes (16GB in Exchange Server 2003 pre-SP2, 75GB with SP2)

Besides that, the Standard Edition also supports local continuous replication (LCR). With LCR, you can have a copy of your Exchange databases on separate local storage.

If you want clustering or cluster continuous replication (CCR), you will need the Enterprise Edition. That edition also supports up to 50 mailbox databases and storage groups.

There are some changes to the CALs as well. Check the web page for more info.

During an upgrade to service pack 2 of an Exchange 2003 active/passive cluster, we had the following error:

The solution was simple but difficult to find. You need to make sure that the cluster's public network interface is listed first in the network binding order. This is done from Control Panel / Network Connections / Advanced menu / Advanced Settings.

So before you start such an upgrade, check those settings and correct them. It is actually a best practice when a cluster is installed.

The past few weeks I have been busy playing with Exchange 2007 beta 2. There are many new (and dropped) features but I am especially interested in the CCR feature. CCR stands for cluster continuous replication. It is a new type of cluster that does not require any shared storage. You do need MSCS (Microsoft Cluster Server) which is a part of Windows Server 2003 Enterprise.

To be able to install a CCR cluster, you first need to install a Windows Server 2003 cluster that uses the MNS quorum type. MNS stands for majority node set. The complete process to install a CCR cluster can be found here . Note that this document does not necessarily follow best practices. It just documents the steps I followed to install such a cluster.

While I was playing around with this, the guys from the Exchange team have posted a blogcast of the whole process as well.

On the Exchange Team’s blog, an article has been posted about Exchange 2003 DirectPush. An interesting read for all those that need to implement it. They also explain why DirectPush only works over a cellular connection like GPRS and not Wi-Fi.

The thing is, a GPRS radio does not consume power when no data is being sent/received. That is not the case for a Wi-Fi connection. Having to keep the connection going for the heartbeats would drain the battery very rapidly.

Monad is a new shell that can be used in Exchange 12 for command line management. Very powerful stuff, check it out. Get the docs as well.

Check out what you can do with Monad for Exchange 12 here.

Want to know more about Exchange 12? Then check out the webcast series here. Not too technically detailed but good for having an overview.

There are many other webcasts about Exchange there, enough to fill a few empty hours.

When you build a Microsoft cluster with Windows Server 2003 SP1 nodes, mount points are fully supported. This is useful on larger clusters because you can save on drive letters.

For example, if you create an A/A/P/P cluster for Exchange 2003 where each active node has four storage groups you easily end up with >16 drive letters. One drive letter for each storage group's databases (8), one drive letter for each storage group's logs (8) and then some drive letters for quorom, SMTP queue drives, and so on. Still not a problem but you see what it leads to when you add more nodes.

To avoid using this many drive letters, you can just mount some drives in a folder of another drive. For example, if you use G:\ for Exchange databases, you could use G:\Logs for the log files. In this case, a separate volume is mounted on that folder.

This worked very well in Windows Server 2003 (without service pack) but with service pack 1, there are some issues. The issues are descibed in http://support.microsoft.com/kb/898790 and there is a patch that solves it.