First of all, let me say that, as an Exchange Administrator, I'm seriously loving the Exchange Management Shell (EMS), the combination of PowerShell with .NET extensions for managing Exchange. Coming from a VMS background, I'm certainly not averse to a command line, and as I get more and more accustomed to the PowerShell syntax, I'm learning to appreciate it more and more. It is powerful, very powerful, and already, despite being early on in my learning curve, I've managed to write several useful scripts for facilitating that staging of mailboxes into groups for transitioning from Exchange 2003 to Exchange 2007. I've even started tinkering with the ability of PowerShell scripts to create their own GUI. If only PowerShell and the Exchange extensions weren't so slow to load initially. What's more, the 64-bit requirement for running Exchange 2007 was a stroke of brilliance. With 32 GB of RAM stuffed into our mailbox servers, Exchange screams. Now I just have to get our page files sized properly.
Of course, the process has not been without its pain points. Microsoft's instructions for installing SCC (Single-Copy Cluster) Clustered Mailbox Servers fails to point out that, when installing an active CMS instance, the cluster service should be stopped on any passive node where an Exchange role has not yet been installed. Otherwise, during the course of the CMS installation, a failover to the unprepared node will try to take place, which will of course fail, leaving the Exchange installation in such an inconsistent state that the only recourse is to completely uninstall Exchange and start the cluster creation from scratch. Also, in earlier versions of Exchange, it had been our standard practice to pre-create the server objects in AD for our Exchange Virtual Servers. This should not be done with 2007. The server objects for the CMS nodes should be created by the installer. We also had to disable the Windows firewall on our mailbox cluster to allow OWA to work correctly, no matter how many holes we punched into it.
We've encountered quite a few oddities with our environment. When a signed message is sent by Outlook from a 2003 mailbox to a 2007 mailbox, the message body appears blank when viewed in OWA Light, or when viewed by the IMAP client on an iPhone. Somehow, the S/MIME headers are being munged in some bizarre way, and the folks at Microsoft PSS are still scratching their heads over that one. But when the signed message is sent via OWA or Entourage, it appears just fine.
The combination of Entourage 2008 and Exchange 2007 is a godsend for our Mac customers (of which we have many in our University environment.) Previously, delegate assignments were severely broken, and the hacks that Microsoft employed to make WebDAV work with recurring meetings came to be a common source of mailbox corruption. I can't recall how many times of had to do mailbox restores to fix this. Now, with the latest version on each end and the use of the more robust Exchange Web Services (EWS) as the intermediary protocol, life is much better. Recurring meetings are handled properly, and delegation assignments work properly. Much to our chagrin, however, as we migrate to 2007, we've had to tell our Entourage users (2004 and 2007) to change their configuration. With Exchange 2003, we told our Entourage users to specify the Exchange server using the OWA URL "https://exchange_front_end_fqdn/exchange", but that doesn't work with 2007. Instead, just the fqdn of the front-end (CAS) alias must be specified, without the URL trappings. Also, while it is commendable that Entourage 2008 tries to use Autodiscover to acquire configuration settings, the results returned are incorrect. Instead of the Exchange Server setting being populated with the name of the server bearing the CAS role (which is what Entourage should talk to in order to communicate with EWS), the CMS holding the mailbox is returned, which will not work if. It is fine if the CAS and Mailbox roles both reside on the same server, but the Entourage developers do not seem to understand that, in an enterprise environment, CAS and MBX roles are segregated, largely because the CAS role cannot be installed on a cluster.
We'll miss Outlook Mobile Access (OMA), but the new version of Outlook Web Access (OWA) is magnificent, provided that you are not a Mac or Linux user (as many of our users are). Even with Exchange 2007 SP1 installed, OWA Light does not offer Deleted Item Recovery or Public Folder access. (These features were also missing from OWA Premium in the RTM version.) Furthermore, opening someone else's shared Calendar on a non-IE browser via the URL https://CAS_FQDN/owa/TARGET_SMTP_ADDRESS/?cmd=contents&f=calendar results in the error "Access to Calendar folders from Outlook Web Access Web Parts is supported only for Internet Explorer 6 and later."
*sigh* So near, yet so far...