Each version of Exchange Server includes a build number so that you can easily identify which version of the software you are running.
Open the Exchange System Manager, expand Servers, right-click your server, click Properties, select the General tab (if it isn’t already selected) and you should see something similar to this:
Exchange 2000
4417.5 – Exchange 2000 RTM
4629.1 – SBS 2000 Exchange 2000
4712.7 – Exchange 2000 SP1
5762.4 – Exchange 2000 SP2
6249.4 – Exchange 2000 SP3
Exchange 2003
6944.4 – Exchange 2003 RTM (including SBS2003)
7226.6 – Exchange 2003 SP1
7638.2 – Exchange 2003 SP2
Although this is a rather old subject, I was recently approached by someone experiencing difficulties with Exchange 2003 SP2 and IMF (Intelligent Message Filter) so I thought I would quickly let you all in on a little tip, for those of you who haven’t as yet installed Exchange 2003 SP2, which I can’t imagine would be too many of you.
Before you start installing SP2, you need to uninstall the Intelligent Message Filter (IMF). By doing this, the settings from the SMTP virtual server where you allowed filtering are also removed.
After the SP2 installation, go to Intelligent Message Filtering settings (Global Settings -> Message Delivery -> Properties -> Intelligent Message Filtering tab) and setup IMF with the same settings as earlier. However, that alone does not reactivate IMF.
You still need to enable IMF from the SMTP virtual server properties -> General tab -> Advanced Edit and check “Apply Intelligent Message Filter” – just as you need to check the relevant options for recipient filter, connection filter, sender filter, and the new option of applying SenderID filter.
Hopefully someone finds this information in some way useful.
Whereas Exchange 2003 really offers only one type of clustering support (local, with multiple servers sharing a SAN), Exchange 2007 supports log shipping both remotely and locally, which opens up new modes of clustering:
- Local Continuous Replication (LCR ), a single-server solution in which the system uses the logs to create a second copy of a storage group (SG) on a different set of disks. This method gives you a second copy of the data. More information here.
- Cluster Continuous Replication (CCR), a two-server solution in which the system ships the logs to a second server to maintain a second copy of the SG. This second server can be local or remote. More information here.
- Single Copy Clusters (SCC), the same idea as Exchange 2003 clusters, in which one set of data is connected to multiple servers. More information here.
Exchange Server 2003 had a basic set of server roles: a back-end server that hosts information stores and performs the bulk of processing and front-end servers that accept client requests and proxies them to the appropriate back-end server. Exchange 2007 has a more granular set of server roles to give flexibility to larger Exchange deployments, while still allowing small to medium deployments to host all the required roles on one server if appropriate. The server roles are:
- Mailbox – Hosts mailbox and public folder data. This role provides Messaging API (MAPI) access for Microsoft Outlook clients. Additionally a variation exists called the Clustered Mailbox role when hosting as part of a clustered environment; it requires no other Exchange roles running on the cluster instance
- Client Access – Similar to the old front-end server role. Provides all other client protocol access, apart from MAPI (i.e., Outlook Web Access–OWA, POP3, IMAP, and ActiveSync)
- Unified Messaging – Provides client access to mailbox, address box, and calendar via telephone and voice. Require Special IP-PBX or VoIP gateway software.
- Hub Transport – Mail routing server that forwards mail to another hub transport server, edge server, or mailbox server. Unlike Exchange 2003, which uses Exchange routing groups, Exchange 2007 uses Active Directory (AD) sites.
- Edge Transport – Gateway from the Exchange organization to the outside world. This is the last hop for outbound mail and the first hop for incoming mail. This is the server that provides mail quarantine. This role doesn’t require AD access, making it ideal for perimeter deployment without opening up ports for AD access. This role must always be deployed on a server with no other Exchange roles.
The Mailbox, Client Access, Unified Messaging, and Hub Transport roles can be distributed across multiple servers or in combination with each other on potentially one server. Any AD site with a Mailbox role also requires a server in the same AD site running the Hub Transport and Client Access roles (or they can be installed on the Mailbox role server).
