Summer fruits

As we move into autumn, perhaps now is the time to look back at what Exchange managers can reap from what Exchange 2007 has sown – such as support for iPhone2 and more affordable fault tolerance.

Exchange (or perhaps I should generalise and say e-mail), is a hot subject and it is constantly moving. Consider this: a mere 20 years ago I would expect to be writing letters to friends, business acquaintances and, of course, the bank (to plead for an overdraft or complain about exorbitant charges – does that ring a bell?).

Today in our e-mail-, web site-, InterWeb-dominated society, the norm of point-to-point communication is e-mail (even if it is spawned out of a web site). When was the last time you wrote (and I do mean write, as in pen, paper, envelopes and stamps) a letter? I think I last wrote a letter – to my solicitor incidentally – some five years ago. Even that business (a bastion of traditionalism) now has the ubiquitous e-mail address.

Heart of the matter
So we are agreed, e-mail is essential and Exchange is at the heart of the majority of the world's corporate e-mail systems. Keeping my eyes and ears close to Exchange gossip, I have been interested to see a curious marriage of convenience between Apple and Microsoft. I'm talking about ActiveSync support for the iPhone2 in Exchange 2007. This alliance is to the cost of BlackBerry, which (rightfully in my view) holds the premier ground in mailbox-to-mobile links.

The dominant position of BlackBerry is even more under threat with pressure growing from phones running Windows Mobile. The addition of a new kid on the block in the form of iPhone2 will only dilute BlackBerry's position even further. This may prove to be one mobile too many for BlackBerry, but, who knows, the Crackberry – oops, I mean BlackBerry – is a hard habit to kick, even if you want to.

It is also interesting to see that the hosting service providers are offering iPhone2 and an Exchange-hosted mailbox as a complete service.

More to manage
From the Exchange administrator's viewpoint, this support means an additional phone on the list. So how do you manage it? From the Recipient Management window in System Manager you can fire up the Manage Mobile Device wizard and select the Apple iPhone for a particular mailbox. Similarly, from Outlook Web Access a user can manage their own mobile devices to change passwords, do a remote wipe or even remove the device from the list. Finally, an administrator can export the ActiveSync log file to find out how many iPhones are being used and by whom.

I notice that the Exchange team have taken on board the need (or should I say "requirement") for ludicrously large mailboxes. I regularly come across companies that claim to have special requirements for huge mailboxes. A 15GB (and above) mailbox is becoming more common.

I hope we all know that the size of the mail message is of less importance than the number of items in the folder. I hope we all know that the key folders (Inbox, Calendar, Sent Items, Outbox etc) are indexed and the indexing process becomes onerous when the item count gets over 5,000. I hope we all know that running cached mode puts less strain on the server than running a server-based mailbox.

The white paper entitled "Planning for large mailboxes with Exchange 2007" (google it) is well worth a read, even though the author's view of large is only 1–2GB (which is a somewhat conservative view of "large", in my experience). In reality there is no magic panacea here. There are some useful tips and a strategy to follow but no step change in technology or process.

Changing times
As I recall, when Exchange first hit the streets some 12 years ago the maximum size of the database was 16GB. (My new Sony Ericsson phone has 8GB of storage – the times they are a changin'!) The database conformed to the ACID (Atomicity, Consistency, Isolation and Durability) test via the use of a log file (5MB). The log files are retained (unless you run circular logging) and are cleared down via the backup process. Each log file has an NTFS filename based on a sequence number preceded by the storage group number (E00, E01, E02 etc).
I had never really considered the issue of running out of numbers. Unlike GUIDS or SIDS, the sequence has a very definitive scope. For Exchange 2000 or 2003, the range is only 1,048,560 and now, five years down the road, we are getting situations where the numbers simply run out.

There is a fix but it is a little messy. It basically involves resetting the counter back to zero for each of the storage groups and hence the log files. The downside is that your precious backups will no longer restore because they depend on the log file number. The error message you do not want to see in the event log is -519 JET_errLogSequenceEnd on the Information Store. By the way, the store will also stop. No doubt that will elicit some feedback from your users. The good news is that a warning is given before this situation arises:

Event Type: Warning
Event Source: ESE
Event Category: Logging/Recovery
Event ID: 514
Description: Information Store (2748) SG2: Log sequence numbers for this instance have almost been completely consumed. To begin renumbering from generation 1, the instance must be shutdown cleanly and all log files must be deleted. Backups will be invalidated.

The second bit of good news is that the log file sequence has been increased for Exchange Server 2007 by a factor of around 400 – that should fix it!

Affordable tolerance
The last thing of note this summer is a really interesting white paper on the Exchange Server 2007 Continuous Replication technology. This technology has to be one of the most compelling reasons to upgrade to Exchange Server 2007.
One of the fundamentals of Exchange has always been that the mailbox is only hosted on a single store and therefore has a single point of failure. Various backup and restore procedures and technologies have been developed, but they all suffer from a significant loss of service while data is restored.
 
With the concept of log file shipping being introduced in Exchange Server 2007, the opportunity to build a fully fault-tolerant solution within a reasonable budget becomes a reality.
The three flavours of Continuous Replication vary in capability and cost, but all of them use the same basic principle of operation. The database log files produced on the live storage group are copied to a remote location and then committed to a "copy" of the database. For Local Continuous Replication this is on a local drive and will require resources from the server's CPU. For Cluster Continuous Replication this is to a remote storage point and is processed by a second node in the cluster. And finally, for Standby Continuous Replication this is also to a remote store but on a completely separate server.

The white paper describes in detail the process of copying the log files across and the failsafe technologies used – not that dissimilar to the File Replication Service used by Windows. In general terms the process relies on a series of services, from LogCopier, LogInspector and LogReplayer to Seeder and ReplyManager. The names of the services give away what they are about. The white paper also describes the process of setting up the replication. This is termed "seeding" the store. In other words, if the store is already running and has data then a copy has to be created in the destination before the newly created log files may be replayed.

The seeding process may be executed by replaying all the log files from the creation time of the store, running an update commandlet or by doing an offline copy of the live store. The disadvantage of a remote copy is that the store has to be closed for the duration of the copy. The best option is to use the Exchange commandlet Update-StorageGroupCopy. This allows the store to continue operating while the replica is seeded.
One thing I found interesting and had not considered before is that in the event of an offline defrag or repair the replica will require reseeding using one of the above methods because the internal structure of the store has been altered.

The white paper is very comprehensive and if you are considering setting up a continuous replication then it must be regarded as essential reading. To get the paper just google "Continuous Replication Deep Dive" and that will point you to the TechNet page.

Autumn goodness
I expect this autumn will produce a welter of new and interesting updates, issues and fixes. I will be glued to the Exchange enthusiasts' blogs and web sites to find out all that's going on.
I don't think the list of desires and improvements to Exchange will diminish and watching the development of Exchange is still a fascinating business, so hold on to your hats for another year of the Exchange story.