Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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 oldSBSuser@ourdomain.com 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.

share|improve this question

2 Answers 2

If you are looking to do a test installation, then I would just put the Zimbra server on a sub-domain (me@zimbra.mydomain.com) 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.

share|improve this answer
    
I wanted to avoid messing about with a sub-domain really and run a couple of live mailboxes with actual usage patterns. I've already done test migrations of 10GB mailboxes using a sub-domain and that worked perfectly. Now I'd like to get myself and the other admin/dev in our office migrated so we can start hammering the system. I'm at a loss as to why I can't get this split address space running? –  benbradley Feb 21 '10 at 13:08
up vote 0 down vote accepted

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 (username@zimbra.domain.com)
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 username@zimbra.domain.com
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

share|improve this answer
    
SBS is really designed to be an infrastructure-in-a-box solution that you just drop in and use for everything. In that situation it works well for most businesses and the components all integrate nicely. It looks like your organization already has a lot of other infrastructure so I agree that SBS may not be the best fit for you, it seems like you've already come to that conclusion. –  Tim Long Mar 2 '10 at 4:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.