「ソフトマッチ」と聞いても、なかなかピンとこない方も多いのでは無いかと思います。これは、
先にOffice365にメールボックスが作成されているクラウドIDのアカウントに対して、後からオンプレミスのActive Directoryの同期アカウントとして紐付ける
手法です。

非サポートの手法と言われていて、仕様がいつ変わるかも分からない物だったのですが、どうやらそろそろ正式にサポートされるかも…という話を聞いたので少し検証してみます。

まず、ディレクトリ同期について、通常のフローで言うと以下の様なデータの流れになります。

1. オンプレミスのActive Directoryのアカウント情報がディレクトリ同期によってOffice365のADに同期アカウントとして作成される。同期アカウントはOffice365側では編集不可。
2. Office365側では、独自に作成したオンプレとは非同期のアカウントも作成可能。
3. Exchange Onlineのサブスクリプションを付与することにより、メールボックスが作成される。
   ※Exchange Online側で先に作成されてOffice365に同期されるパターンも有り

この時、Office365上では同期アカウントと非同期アカウントがありますが、それぞれの区分を変更したりすることはできません。同期アカウントに対してはSourceAnchor（オンプレのオブジェクトのGUIDから生成）という値が保持され、これがあるかどうかで同期アカウントか判断されます。またこれにより、ディレクトリ同期サーバを再インストールしても連携が保持されます。

ここで、ケースによっては、ディレクトリ同期ツールでアカウントを作成するのが難しいことがあります。例えば、

• 移行に合わせてフォレスト統合を行う必要があるが、Office365の利用希望日に間に合わなく先にクラウドIDを利用して開通させたい。また、統合後はメールボックスは保持したまま移行したい。
• Office365を利用開始後、パスワード管理やアクセス制御などの問題でADFS導入を行いたい。
• ディレクトリ同期されたアカウントのメールボックスの復活を行い、再び同期アカウントに紐付けたい。（削除済みメールボックスの回復は、非同期アカウントの新規作成と合わせた紐付けとなる）
• BPOSの移行されてきたメールボックスをADFS環境で利用したい。

などです。最後の項目があるのでサポートせざるを得ないだろうという話なんでしょうね。ここで解決法として登場してくるのがソフトマッチです。（※ちなみに、上記で記載したSourceAnchorによるマッチングは「ハードマッチ」と呼ばれます。）

ディレクトリ同期ツールからしてみると、新規でアカウントを作成しようとしますが、Office365側のアカウント作成プロセスにおいて条件をチェックし、「新規作成」から「変更（SourceAnchor含む）」に勝手に変更してくれるという形になります。

つまり、先にディレクトリ同期されてOffice365側に対応する同期アカウントが出来ていて、後から属性の変更などで条件を満たすようになったとしても、このマッチングは行われません。（というか、属性の一意性エラーで同期ツールによる変更が実施されません。）

ここでの特定条件のマッチングですが、以前はUPNとメールアドレスの完全一致とか言われてましたが、どうやら今はメールアドレスだけで判定されているという話なので、いくつかパターン見て調べてみます。

1. UserPrincipalName、mail、ProxyAddresses（SMTP:で始まるプライマリ）が完全一致…OK
2. UserPrincipalName、ProxyAddresses（SMTP）が完全一致…OK
3. mail、ProxyAddresses（SMTP）が完全一致…OK
4. ProxyAddresses（SMTP）が完全一致…OK
5. ProxyAddresses（smtp）がOffice365側の追加アドレスに一致（smtp:で始まる）…OK
6. mailがOffice365側のプライマリアドレスに一致…OK
7. mailがOffice365側の追加アドレスに一致…OK
8. 一度同期されたオブジェクトを Explicit Disconnector にする手法を使ってOffice365から消して、mail属性を追加アドレスと一致させてから再同期…OK

Office365側に作成済みのアカウントのメールアドレス（mail、ProxyAddresses(SMTP:)、ProxyAddresses(smtp:)）のいずれか1つでも等しいADのオブジェクトが、ディレクトリ同期でOffice365側に同期され、アカウントの新規作成が実施されようとした際にソフトマッチが行われるようです。

ただ、1点注意事項。8番で実験しましたが、一度ソフトマッチに失敗しても、オンプレ側のADを削除することなくリカバリをすることは可能です。逆に、一度でもソフトマッチで同期オブジェクトになってしまった場合は元には戻せません。Office365側にオンプレと同じsourceAnchorが付与されて、ハードマッチの状態になってしまうからです。（まあ、SR上げて気長に1週間くらい待てば可能かもですが）

一度同期されればハードマッチ状態になりますので、気を遣わなくてはいけないのは一度だけです。また、現時点ではいつ仕様が変わるか分からないので、直前に検証（仕様が変わっていないか）は必要かと思いますが、上手く使いこなせれば展開方法の柔軟性が格段に増すかと思います。

簡単に手順を記載します。同期アカウント（contoso-jp.com）と非同期アカウント（fabrikam-jp.com）の混在環境が合ったとします。

ここで、fabrikam-jp.comのユーザがcontoso-jp.comへのフォレスト統合が完了したとして、contoso-jpのアカウントを保持したと仮定します。

ここで、ディレクトリ同期が走る前に電子メール（mail）属性をマッチングさせたいOffice365側のメールアドレスと一致させます。

手動同期を実施すると、

ソフトマッチによりfabrikam01のアカウントが同期アカウントに変更されます。

ここで注意点ですが、シングルサインオン（ADFS）として構成している場合は問題ないのですが、ディレクトリ同期のみで実装している場合、ユーザのログオンアカウント名（UserPrincipalName）についてはオンプレミスでの変更はOffice365側に同期されません。整合性を取るため、mail属性だけではなく、UPN名についても一致した状態でソフトマッチさせることを推奨いたします。

上記例の場合は、先にOffice365側でfabrikam01@fabrikam-jp.comからfabrikam01@contoso-jp.comにユーザ名を変更してからソフトマッチするということになります。。

今後のMicrosoft側の発表についても、ウォッチしたいと思います。