We recently released a downloadable Exchange System Manager (ESM) for Exchange 2003 which can be installed on Vista machines. Part of what made this possible was the changes we did recently to allow Exchange's implementation of the MAPI client binaries to run on Vista.
Some interesting tidbits from the Release Notes:
Does this imply that the MAPI/CDO web download, apparently for Exchange 2007, is fully and officially supported for use with Exchange 2003 in other versions of Windows?
That is, there is no reason now to install the Exchange 2003 ESM and its updates on a (server) machine if all that is needed is MAPI/CDO?
I'm not aware that we've ever said the download isn't supported connecting to Exchange 2003. Of course, you can't install the download on an Exchange 2003 box - but that's simply because MAPI's already on the box. Do you have any references indicating the download shouldn't be used to connect to Exchange 2003?
No, not a explicit "shouldn't". But neither is there an explicit "should" ;)
For example, the MAPI/CDO web download page does not explicitly state that this version fully supports Exchange 2003 or earlier.
Every Exchange server comes with its own flavor of MAPI/CDO and the practice I am aware of has always been to match the versions of MAPI/CDO and Exchange.
There have been enough differences, such as the no public folder flag issue, and the vista change, where the Exchange version of MAPI/CDO did matter.
So, the question is, for functionality and MS support calls, is the web MAPI/CDO download equivalent to the latest Exchange 2003 MAPI/CDO version?
The MAPI download is built out of an Exchange 2003 branch. So it *is* Exchange 2003's MAPI, with an installer wrapped around it.
I was able to trick the installer into installing the ESM along with Outlook.
<Steve here> I've excised the rest of this comment. It doesn't matter if you *can* force the ESM to install alongside Outlook. What matters is that if you do it, there *are* conflicts and there *will* be problems. I've debugged too many issues that turned out to be caused by this to condone helping people shoot themselves in the foot.
I'd never heard of problems running ESM along with outlook on an XP box, and never had any myself, though some tasks with public folders didn't work that well.
Is there any work around for those of us using a Vista station to manage a 2003 Exchange system more directly than remote desktop?
So you've never heard of problems - except the problems you actually experienced. Interesting. :)
We've never supported ESM on a machine with Outlook, so no, there are no Vista specific workarounds to offer.
The issues we had were minor. Nothing to indicate the "shoot yourself in the foot" kind of issues inferred above.
As to my question, it was less of "how to make esm work with outlook", but more is there any alternative. Point being, many of us admins are reluctantly switching over to Vista, and losing access to things we use regularly from our desktops.
You can put the ESM on another machine and remote to it, or put the ESM in a virtual machine and use the VM to manage Exchange.
Will there be a version of this that can be installed on Windows 2008 server?
I would like to be able to manage the Exchange 2003 that is running in a virtual machine without having to fire up the Hyper-V console every time.
So I guess that would be Server 2008 x64 to be specific.
What is the point, most admins want to run ESM on there Vista workstaion the very reason for this is they are running exchange and therfore Outlook.it seem kind of pointless to create a VM without outlook so you can run Vista ESM.
may aswell logon to the exchange server via RDP.
I understand that there are issues with installing ESM along side Outlook, but what are the options available to software developers?
Specifically, I my team is writing a .Net application that needs to create email accounts and Mailboxes. This task requires the CDOEXM.dll, which is a part of ESM. I am at a crossroads, because I can't ask the development team to uninstall their Outlook (nor do I want to ask them to do any hacks that could potentially screw up their workstations).
I personally keep my Outlook/tools machine seperate from my development machine.