Paul's Down-Home Page

InfoWorld just posted a fairly comprehensive review of Exchange 2007 beta 2, and they liked what they saw.

Exchange 2007 requires the RC0 build of Monad. The currently available build of PowerShell (née Monad) is RC1. Although the Exchange 2007 release notes tell you to install the latest build of PowerShell, they don’t really mean it; beta 2 requires RC0. Nothing more, nothing less. You can get the RC0 build of Monad using the link on the Exchange 2007 setup splash page (which I couldn’t use because my VMs don’t have Internet access), or here, and install it. Don’t forget that the extension for scripts changes: it’s .msh in RC0 and .ps1 in RC1 and later.

Another error from the Exchange 2007 beta setup parade: after you remove a server, when you reinstall, you may get an error that says that “Default VoiceMessageOriginator contact already exists”. The trick to fix this is to launch ADU&C, turn on advanced mode, and open the Microsoft Exchange System Objects container. In that container, you’ll see an object called Exchange UM<GUID>. This object is used to represent the system as the sender of UM messages. You’ll need to remove it. (Microsoft is planning to change the way the sender object is created in future builds, so this is a beta-2-only bug.)

Exchange 2007’s setup program includes the ability to reinstall the Exchange binaries on a failed server. I had to use this today to replace a server VM that was mangled by a problem with our SAN controller; through no fault of anyone except a certain large SAN company, the VM was corrupt and couldn’t be restored. I rebuilt the base OS image, gave it the same machine name, and fired up setup /m:recoverserver. That seemed to work OK, reinstalling the hub transport and mailbox roles. Then I got an unexpected error:

Client Access Role ……………………. FAILED

The AD Object for virtual directory ‘IIS://EXCHANGE/W3SVC/1/ROOT/Microsoft-Server-ActiveSync’ on ‘EXCHANGE’ could not be created. This may be happening because it already exists in Active Directory. Remove the object from Active Directory, then re-create it.

I couldn’t find any documentation on how to fix this. That’s an awfully generic error message. However, I eventually found the suspect object living in the configuration NC of my AD: cn=services, cn=Microsoft Exchange, cn=orgName, cn=Administrative Groups, cn=Servers, cn=serverName, cn=Protocols, cn=HTTP. So, I removed it. All done? Not quite.

See, once you run with /m:recoverserver, the setup code writes a flag in each role (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\v8.0\roleName) that says “I’m in disaster recovery mode”. As long as that flag is present, you can’t install or remove server roles, so I couldn’t just run exsetup /m:install /r:clientaccess like you’d think. First, I removed the Action value under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\v8.0\ClientAccessRole. Next, I uninstalled the CAS role (which wasn’t really there anyway!), then I re-installed the CAS role. However, Exchange setup still thought the CAS role was installed, so it wouldn’t install it. I tried adjusting MSExchCurrentServerRoles for the server object, but I don’t think Exchange likes a value of “0”. Subsequent reinstalls complained that the Exchange Servers USG was missing. Rather than continue to tinker, I ended up removing the AD org object and reinstalling from scratch. I think the original virtual directory error is a bug, and I’m going to report it as such.

Update: this is now logged as bug 176356.

Exchange 2007 setup asks you whether you have any client computers running Outlook 2003 or earlier. It does this so it can determine whether you’ll need the legacy Schedule+ Free/Busy and offline address book folders– but that got me to wondering: what about Office Communicator? Does it count as a pre-Outlook 2007 client? After all, Communicator uses MAPI to connect to the Exchange server and get free/busy data for your mailbox and the mailboxes of those on your contact list. I’m trying to find the answer and will update this post once I do.

(Interesting side note: Communicator will use an open MAPI session if one already exists; if not it will create its own.)

Update: turns out, the answer is “no, it’s not a legacy client”. Communicator makes MAPI requests to get your free/busy data, which it then publishes to LCS. The free/busy data you see for other contacts in your contact list comes from the LCS server, not your local copy of Communicator’s interrogation of their mailboxes. So, this should work fine… but I’m still going to test it!

The hits just keep coming! Microsoft yesterday announced the release of the first version of the Exchange Troubleshooting Assistant (ExTA), an automated tool that analyzes several different kinds of log files and tracing data to help you pinpoint problems. This is a great idea, and next time I face a misbehaving server I’ll give it a try (not that I’m in a hurry, mind you!)

Ed Brill is making hay with Microsoft’s system recommendations for Exchange 2007 beta 2. (Don’t miss the comments, especially the ones pointing out that IBM doesn’t even publish per-user resource guidelines for their own products– good thing, because if they did Workplace wouldn’t look too spiffy!)

Anyway, Ed’s article misses the point: the recommendations are for servers with “many users with large, frequently used mailboxes”. If you don’t have many users, or they don’t have very large (>1GB) mailboxes, or the mailboxes aren’t frequently accessed, you can get by with much less RAM.

Remember, the point of adding RAM is to reduce the number of I/O operations per second (IOPS) that you need to handle a given user load. Large mailboxes and frequent accesses mean more IOPS. More IOPS means more disk spindles, which means lots more money. Gigabytes of RAM are cheap compared to SAN disks; right now, Exchange 2003 servers scale out by adding more spindles to get more IOPS. With Exchange 2007, you have a choice: add IOPS by adding disks or reduce the number of required IOPS for the same user load by adding RAM for caching. You get to choose according to your needs– part of Microsoft’s promise to provide more administrator choice and control in Exchange 2007. (Take a look at this post for more detail on disk I/O tradeoffs in Exchange 2007.)

Ed’s pricing example is a little disingenuous too, because he doesn’t specify how many Notes users his hypothetical 6200-user Dell configuration could host, and he ignores storage costs altogether. I’ll be happy to put together a reasonable configuration for N Exchange users and cost it out if you’ll do the same for Domino. (I’ve made this offer before, and Ed’s ignored it– wonder why?)

Microsoft has taken a step that I’ve long hoped for: they’ve renamed the former “Exchange Ranger” program to better reflect its serious nature, and they’ve opened it to people outside the company (as long as they’re associated with MS gold-certified partners). The entrance prerequisites are very stiff, there’s a $25,000 tuition charge, and the training is extremely demanding: six days a week for five weeks, with extensive hands-on and lab-based testing each week. The curriculum looks really tantalizing. However, I don’t think I’d like being away from my family for that length of time– a six-week immersion is a bit much.

Interestingly, as far as I can tell none of Microsoft’s competitors have such a highly structured or rigorous program for their messaging architects. The closest equivalent I can think of is Cisco’s series of programs, and even then they don’t take six weeks.

Scalix announced yesterday that they’re going to provide open source licenses for major components of their product. This aligns them nicely with Zimbra, which has already done the same thing. Zimbra has a better web interface (IMHO) than Scalix does, and better admin tools to boot; however, Scalix has a mature and proven back-end system. If they really wanted to give IBM and Microsoft headaches, the two of them should team up somehow and combine forces. I can’t take credit for the idea; fellow MVP William Lefkovics suggested it to me a few months ago.

From Ed’s blog, news that IBM is moving toward a slightly different licensing strategy for its products.

Why does IBM even use per-processor licensing? Customers hate it. Microsoft has been making hay in the database world by showing the license cost differential between SQL Server 2005 and DB2 on equivalent hardware– it can be up to an order of magnitude difference! That gets CxOs’ attention PDQ.

Doesn’t it make more sense to price software according to the number of actual clients or users and not the capacity of the machine? As I understand it, if I buy a 2-CPU dual-core Opteron server, I have to buy 4 Domino CPU licenses (or the equivalent number of “processor value units”), no matter how many actual users connect to the box or what else it’s used for. Compare this with the pricing model for Exchange, GroupWise, or even OCS: you pay for the number of users you’re supporting, not for what your hardware is potentially capable of.

“Processor value units” seem like an IBM attempt to extract money that they wouldn’t otherwise be entitled to from customers who are moving to multi-core CPUs. When Ed asks:

…what would you like to see happen as far as sub-capacity or multi-core licensing and pricing for Domino? ..t. If the answer is “we just want to pay less for Domino”, that dog doesn’t really hunt — unless you have an idea how that translates into IBM growing and maintaining the Domino business.

one translation of the question might be “customers, we know you think our license model doesn’t reflect reality, but we don’t care if you want to pay less.” The right thing to do for growing the business is to adopt the MS model for virtualization licensing: license per active instance and virtual CPU, not for physical instances of anything.

(and before the flames start: yes, I know MS has per-CPU licenses for some products, like SQL Server. However, AFAIK they don’t do per-CPU licenses for their messaging and collab products; I don’t know offhand if they’re doing per-CPU or CAL for Office SharePoint Server or not.)

Update: yep, customers hate IBM’s licensing model, all right.

Devin has a good summary of some of the things you should expect (or may not expect!) in Exchange 2007 beta 2.