We currently have an 11 user SBS 2003 server which handles our e-mail, however I'm trying to setup a test migration to Zimbra. For this test migration I'd like to have some e-mail addresses moved over to Zimbra but the rest remaining on SBS 2003, all under the same domain.
In Microsoft terminology I've discovered that this is called a shared namespace/address space. I've looked through various articles and the best guide I've found so far is this http://support.microsoft.com/kb/321721
I was planning to set the new Zimbra server as the new primary, so port 25 of the Zimbra server is open to the internet through our firewall. This way round because it's easy to configure the routing in Zimbra so that specific e-mail addresses get passed on to the old SBS server. I've already got the routing set up within Zimbra and it works perfectly, so sending to [email protected] from a Zimbra account goes straight to the old SBS Exchange Server. I've not yet switched the port forwarding on our firewall though, so the SBS 2003 machine is still technically the primary.
The problem is I can't get the address space sharing to work in SBS 2003... so that if a user on the SBS server tries to send to an account that no longer exists in SBS, it gets passed to the new mail server.
I've pretty much followed that MS KB article by the word but I'm still getting bounce messages from Exchange when I try and send to a user who now lives on Zimbra.
So here's what I did, I edited our Default Recipient Policy and added @example.local as a new SMTP address, and removed @ourdomain.com
I added a new Recipient Policy called Split Namespace with a new SMTP address of @ourdomain.com and unticked the "This Exchange Organization is responsible for all mail delivery to this address" tick box, which I believe should mean that Exchange is now not-authoritative for that domain.
So I have 3 Recipient Policies listed in System Manager:
1) a mailbox manager policy with priority 1 which deletes messages older than 600 days from user mailboxes
2) Default Policy with priority lowest
3) Split Namespace policy with priority 2
Then I went into the properties of our Default SMTP Virtual Server and checked to make sure the "Forward all mail with unresolved recipients to host" text box was clear under the Messages tab. It was already clear.
Next step was to create an additional SMTP Connector, called it split namespace SMTP connector and set "Forward all mail through this connector to the following smart host" as the LAN IP address of our new Zimbra machine in square brackets... [192.168.1.5]. Added a Local Bridgehead of SERVER _ Default SMTP Virtual Server
Went to the "Address Space" tab and added a new SMTP address of ourdomain.com with Cost set to 1. I also ticked the "Allow messages to be relayed to these domains" box. Checked the delivery options and it's set to "Always Run"
Edited the our existing SmallBusiness SMTP connector to change the cost of the * asterisk Address Space down to 20 so in theory the new SMTP Connector should processed before this one.
Then restarted the MS Exchange Routing Service and the SMTP services
However when I try to send an email through our SBS server to our Zimbra server, I get the following bounce message: "The e-mail account does not exist at the organization this message was sent to. Check the e-mail address, or contact the recipient directly to find out the correct address."
So it's not working or I've messed something up somewhere. Anyone know anything else I can check/try?
Is this even supported in SBS 2003? Wouldn't be suprised if there was some sort of crazy restriction stopping me from doing this.
If you are looking to do a test installation, then I would just put the Zimbra server on a sub-domain ([email protected]) or something for the duration of the test.
For an 11-user deployment, I think you're giving yourself an unnecessarily hard time trying to migrate them piecemeal. Try the new system on a sub-domain and take the decision on whether you are going to use it, then just cut all 11 users over to the new system in one hit.
But, if your organization is based on SBS, I think you're absolutely crazy not to use the integrated exchange server. You'll be giving up things like single sign-on, integration with Remote Web Workplace, working offline (no internet connection), Sharepoint integration, the list goes on.
Right I've solved it by doing it a bit of a round-about way. I didn't manage to get the address space sharing working on our server.
But I added an additional sub-domain to the Zimbra box (zimbra.domain.com) and set up aliases for each email account I wanted to migrate initially in Zimbra ([email protected])
Then I changed the smart host setting in Exchange to point to our new Zimbra box (the Zimbra box points to our external private relay anyway)
Then created a contact in Exchange, with an SMTP email address of [email protected]
Then changed the delivery options for my mailbox in Exchange to deliver to the contact I created instead of to my mailbox
Seems to be working perfectly.
Hope this helps someone out
As to why I shouldn't migrate from SBS:
Our shared files system is Samba/Netatalk/WebDav/SFTP and our intranet DB is Apache/PHP/MySQL. I have now implemented LDAP auth between those services and our Zimbra LDAP server. I never managed to get Apache LDAP Auth to work with our Exchange server after much trying. So single sign-on is nailed. Today I wrote some addons for the Zimbra AJAX UI to tie in with our intranet database and our hosted VoIP platform and they seem to work well. Sharepoint, we've never used because we already have a shared files system (5TB NAS). People who want to share documents etc can now use the Briefcases in Zimbra. There's some big benefits for remote working: no more aweful basic webmail interface or remote desktops, we still have offline MAPI access to Zimbra using Outlook as we did before. Now our IMAP users can access shared/public folders as well, I never managed to get write-access working for our public folders over IMAP. Also there's frequent updates every 1-3 months and major versions every 12-18 and it's almost half the cost per user per year vs what we spent on Exchange CALs