SBS 2003は複数の内部メールサーバーとSMTPアドレススペースを共有します

現在、電子メールを処理する11ユーザーのSBS 2003サーバーがありますが、Zimbraへのテスト移行をセットアップしようとしています。このテスト移行では、一部の電子メールアドレスをZimbraに移動しますが、残りはすべて同じドメインの下にあるSBS 2003に残ります。

Microsoftの用語では、これが共有名前空間/アドレススペースと呼ばれることを発見しました。さまざまな記事を調べてきましたが、これまでに見つけた最高のガイドはこちらですhttp://support.microsoft.com/kb/321721

新しいZimbraサーバーを新しいプライマリとして設定することを計画していたので、Zimbraサーバーのポート25はファイアウォールを介してインターネットに開かれています。特定の電子メールアドレスが古いSBSサーバーに渡されるようにZimbraでルーティングを構成するのは簡単だからです。既にZimbra内でルーティングを設定しており、完全に機能するため、ZimbraアカウントからoldSBSuser@ourdomain.comに送信すると、古いSBS Exchange Serverに直接送信されます。ただし、ファイアウォールのポートフォワーディングをまだ切り替えていないため、SBS 2003マシンが技術的にはまだプライマリです。

問題は、SBS 2003でアドレススペース共有を機能させることができないことです。そのため、SBSサーバー上のユーザーが、SBSに存在しないアカウントに送信しようとすると、新しいメールサーバーに渡されます。 。
私はそのMS KBの記事をほとんど言葉でフォローしましたが、現在Zimbraに住んでいるユーザーに送信しようとすると、Exchangeからバウンスメッセージが表示されます。

だからここに私がやったこと、デフォルトの受信者ポリシーを編集し、@ example.localを新しいSMTPアドレスとして
追加し、@ ourdomain.com を削除しました。新しいSMTPアドレスが@ ourdomain.comであるSplit Namespaceという新しい受信者ポリシーを追加しました[このExchange組織はこのアドレスへのすべてのメール配信を担当する]チェックボックスをオフにしました。これは、Exchangeがそのドメインに対して権限を持たないことを意味するはずです。
System Managerに3つの受信者ポリシーがリストされています
。1）ユーザーメールボックスから600日以上経過したメッセージを削除する優先度1のメールボックスマネージャーポリシー
2）優先度が最低のデフォルトポリシー
3）優先度2の名前空間ポリシーの分割

次に、既定のSMTP仮想サーバーのプロパティに移動し、[メッセージ]タブで[未解決の受信者を含むすべてのメールをホストに転送する]テキストボックスがクリアされていることを確認しました。すでに明らかでした。

次のステップは、名前空間SMTPコネクターを分割するという追加のSMTPコネクターを作成し、角括弧内の新しいZimbraマシンのLAN IPアドレスとして「このコネクターを介してすべてのメールを次のスマートホストに転送」... [192.168。 1.5]。サーバーのローカルブリッジヘッド_デフォルトSMTP仮想サーバー
が[アドレススペース]タブに追加され、コストが1に設定されたourdomain.comの新しいSMTPアドレスが追加されました。[これらのドメインへのメッセージの中継を許可]ボックスも選択しました。配信オプションを確認し、「常に実行」に設定されています

既存のSmallBusiness SMTPコネクタを編集して、*アスタリスクアドレススペースのコストを20に変更したため、理論上、新しいSMTPコネクタはこの前に処理する必要があります。

次に、MS Exchange Routing ServiceとSMTPサービスを再起動しました

ただし、SBSサーバーを介してZimbraサーバーにメールを送信しようとすると、次のバウンスメッセージが表示されます。「このメールの送信先の組織にメールアカウントが存在しません。受信者に直接連絡して正しいアドレスを見つけてください。」

だからそれは機能していないか、どこかで何かを台無しにしました。誰でも私がチェック/試用できることを知っていますか？
これはSBS 2003でもサポートされていますか？私がこれを行うのを妨げる何らかの狂った制限があったとしても驚かないでしょう。

テストインストールを行う場合は、Zimbraサーバーをサブドメイン（me@zimbra.mydomain.com）またはテスト期間中に配置します。

11ユーザー展開の場合、それらを少しずつ移行しようとするのは不必要に苦労していると思います。サブドメインで新しいシステムを試し、使用するかどうかを決定してから、11人のユーザー全員を1回のヒットで新しいシステムにカットします。

しかし、組織がSBSに基づいている場合、統合Exchangeサーバーを使用しないのは絶対に夢中だと思います。シングルサインオン、リモートWebワークプレースとの統合、オフラインでの作業（インターネット接続なし）、Sharepointの統合などを放棄します。

正しい方法で解決しました。私たちのサーバー上でアドレス空間共有を機能させることができませんでした。

しかし、Zimbraボックス（zimbra.domain.com）に追加のサブドメインを追加し、最初にZimbra（username@zimbra.domain.com）で移行したい各メールアカウントのエイリアスを設定し
、その後、スマートホストの設定を変更しましたExchangeで新しいZimbraボックスを指すように（Zimbraボックスは外部プライベートリレーを指す）
次に、username @ zimbra.domain.comのSMTP電子メールアドレスを使用してExchangeで連絡先を作成し、
次にメールボックスの配信オプションを変更しましたメールボックスではなく、作成した連絡先に配信するExchange

完璧に機能しているようです。
これが誰かを助けることを願っています

SBSから移行しない理由について：
共有ファイルシステムはSamba / Netatalk / WebDav / SFTPであり、イントラネットDBはApache / PHP / MySQLです。これらのサービスとZimbra LDAPサーバーの間にLDAP認証を実装しました。試行錯誤の末、Apache LDAP AuthをExchangeサーバーで動作させることができませんでした。そのため、シングルサインオンが行われます。今日、私はZimbra AJAX UIのいくつかのアドオンを書いて、イントラネットデータベースとホストされたVoIPプラットフォームに結び付けましたが、うまく機能しているようです。Sharepoint、共有ファイルシステム（5TB NAS）を既に持っているため、使用したことがありません。ドキュメントなどを共有したい人は、Zimbraのブリーフケースを使用できます。リモート作業にはいくつかの大きな利点があります。基本的なWebメールインターフェイスやリモートデスクトップがこれ以上ないため、以前と同様にOutlookを使用してZimbraにオフラインMAPIでアクセスできます。IMAPユーザーは共有/パブリックフォルダーにもアクセスできるようになりました。IMAP経由でパブリックフォルダーの書き込みアクセスを機能させることができませんでした。また、1〜3か月ごとに頻繁に更新が行われ、メジャーバージョンが12〜18ごとに更新されます。ユーザーあたりのコストは、Exchange CALに費やした費用の約半分です