発信同期の設定もひととおり完了しましたので、実際に実行してみましょう。
着信同期のときには、ERLを事前にメタバースへレプリケートさせておく、
というルールがありましたが、発信同期はその必要はありません。
その代わりに、
Active Directory用管理エージェントのコネクタスペースに適当なユーザーを
インポートしておく必要があります。
事前にユーザーをコネクタスペースにインポートしておくことにより、コネクタスペースに
ユーザーのスキーマ(テーブル？)が作られます(と思います。推測ですみません..)
この操作を行っておかないと、メタバースからActive Directory用管理エージェントのコネクタスペースに
同期させようとしたときに失敗します。
以上の準備ができたら、発信同期を始めます。
まず、MSILMポータルサイトでユーザーを作成します。
ここでは、Keita Suzuki という名前のユーザーを作成しました。
作成後、プロパティを開くと、プロビジョニングタブで_Outbound-ADDS OSRが
マッピングされていることが確認できました。これは次の同期を行うタイミングで
OSRが実行されるように構成されていることを意味します。
Identity Management管理ツールを開き、MSILMデータベース用管理エージェントから
インポートを実行します。すると、2つのオブジェクトがインポートされた事が確認できます。
Add欄をダブルクリックして、表示されたオブジェクトをさらにダブルクリックすると、
インポートされたオブジェクトの詳細が確認できます。
ひとつはMSILMポータルサイトで作成したユーザーの情報です。
もうひとつは、Expected Rules Entryというオブジェクトです。
Expected Rules Entry(ERE)とは、ERLの中に格納されているオブジェクトで
インポートされたユーザーに対して実行するべき、OSRの情報が格納されています。
つまり、EREとは、先ほどMSILMポータルサイトでユーザーのプロパティを開いたときに
表示されたERLの情報をそのものなのです。
下の図を見ると、MSILMポータルサイトで見えていたプロビジョニングタブの情報と全く同じですね。
続いて、MSILMデータベース用管理エージェントのコネクタスペースにインポートされた
情報をメタバースへ同期させます。MSILMデータベース用管理エージェントでSynchronizationを
実行すると、次のような結果がIdentity Management管理ツールで確認できました。
赤枠で囲っていますが、コネクタスペース(MSILM DB) → メタバースの同期を実行したのに、
メタバース → コネクタスペース(AD) の同期を実行するOSRまで実行されます。
このように、OSRの場合、
・コネクタスペース(MSILM DB) → メタバースの同期
・メタバース → コネクタスペース(AD) の同期
を別々に行う必要が無いのです。
結果、コネクタスペース(MSILM DB) → メタバースの同期によって、
ポータルサイトで作成したユーザーがメタバースへ移動できたことが確認できました。
Provisioning Adds欄をダブルクリックすると、メタバースへ同期されたユーザーの情報の詳細を参照することができます。
Active Directory用管理エージェントのコネクタスペースを参照すると、
ポータルサイトで作成したユーザーの情報が格納されていることがわかります。
コネクタスペースに格納されたオブジェクトの情報は管理エージェントを右クリックして、
Search Connector Spaceをクリックすると確認できます。
最後に、ADへのエクスポートを実行すれば完了です。
ここまで、発信同期の一連の流れを紹介しました。
このような流れを知っておけば、これもまたトラブルシューティングに役立てることができますよね。
ちなみに私は、事前にAD用のコネクタスペースにユーザーを作っておくことを忘れていたために
OSRが実行されず、ハマりました。。
