Office 365管理者のためのディレクトリ同期ツール入門 AADSync編

皆さん、こんにちは。国井です。

Office 365管理者のためのディレクトリ同期ツール入門シリーズの最後は
Azure Active Directory Sync(AADSync)ツールについてです。

2015年1月時点では、Office 365管理ポータルからダウンロード可能な
ディレクトリ同期ツールはDirSyncツールですが、将来的にAADSyncツールに
置き換わるものと思われます。

AADSyncツールを使うと嬉しいことは、なんと言っても
マルチフォレストでのディレクトリ同期に対応していること!

ということで、今回はAADSyncツールを確認してみましょう。

■ ■ ■

まず、AADSyncツールはマイクロソフトのダウンロードサイトよりダウンロードできます。
ダウンロードサイトを見ると、英語版のみがダウンロード可能であるかのように書いてありますが、
実際にはマルチランゲージ対応なので、日本語OSにインストールすれば、
セットアップウィザードは日本語になります。

AADSyncのインストールは至って簡単で、セットアッププログラムを起動して
インストールパスを指定するだけ。

AAD001

インストールが終わると、ディレクトリ同期に関する情報を設定します。
なお、ここから先の設定はデスクトップに作成されるショートカットから
改めて実行することも可能です。

image

AAD004

ここで、複数のフォレスト(ドメイン)を指定すれば、待望のマルチフォレスト対応が実現します!
ですが、今回はシングルフォレストで先を急ぎます。

AAD005

ディレクトリ同期を行う際、どの属性を使ってADユーザーとAzure ADユーザーを
マッピングするか?についての設定です。
Alternate Login IDの機能を利用する場合はここでカスタマイズします。

AAD006

パスワード同期を行うか?パスワードライトバック機能を使うか?などを
選択できます。ちなみにパスワードライトバックとは、Azure AD Premiumに含まれる
セルフサービスのパスワードリセット機能でパスワードをリセットしたときに、リセットしたパスワードを
オンプレミスのActive Directoryに同期させる機能です。
(「クラウドからActive Directoryのパスワードを変更する方法」で紹介したEnable-OnlinePasswordWriteBackに相当する操作です)
それから、Azure ADアプリと属性フィルターについては話が長くなるので場を改めて紹介します。

AAD008

残りはすべて次へ進めていくとウィザードが完了します。

AAD011

AAD012

AADSyncもDirSyncと同様にmiisclient.exeツールは用意されています。
ただしパスはc:\Program Files\Microsoft Azure AD Sync\UIShellに変更になりました。

AAD013

画面構成はDirSyncツールと基本的には同じですが、[Joiner]メニューはなくなりました。

image

Connectorsメニューを見ると、MAの名前がドメイン名になっています。
カンの良い人なら、もうお気づきですね。
マルチフォレストの場合はフォレストごとにMAが作られます。

image

先ほど、オブジェクトのマッピングを担当するJoinerメニューはなくなったといいましたが、
正確には別ツールで用意されるようになった、というのが正しい表現です。
miisclientツールと同じフォルダーにSyncRulesEditor.exeという名前で用意されています。

image

Synchronization Rules Editorツールでは、マッピングに関する設定ができます。
マッピングだけでなく、同期に関するフィルター設定などもすべてここで行うことになります。
このあたりはMVPふじえさんの[AAD/Office365]AAD Sync Betaを試すでも
紹介しているので、ぜひご一読ください。

image

Synchronization Rules EditorツールにあるInboundとOutboundというのは
Forefront Identity Managerで登場する着信同期規則(ISR)と発信同期規則(OSR)のことです。FIMだとFIM専用のポータルサイトから規則を作成しますが、Synchronization Rules Editorツールではすべてこの画面から作成します。

こうやって見ると、AADSyncツールを使いこなすにはFIMの知識が必要になってきていることがわかりますね。FIMを学習するリソースは世の中に多くないので、ちょっと苦労しそうです。

 

Office 365管理者のためのディレクトリ同期ツール入門(3)

みなさん、こんにちは。国井です。

今回はOffice 365管理者のためのディレクトリ同期ツール入門の第3回目として
ディレクトリ同期ツールを使ってディレクトリの同期が一部のユーザーだけで行われるように構成する方法について紹介します。

まずは前回も紹介したスライドから。

image10[1]

前回も、その前も、Active Directory Connector MA(ADMA)とWindows Azure Active Directory MA(AzureMA)がディレクトリ同期ツール内に作られ、メタバースを経由して同期が行われることを紹介しました。
そして今回、ADMAでフィルターを設定し、同期しないオブジェクトがメタバースに書き込まれないように構成することで、一部のユーザーだけがOffice 365(Microsoft Azure Active Directory)へ同期される方法を
いくつか見たいと思います。

 

■その1:同期されるドメインのフィルター

同期を行うActive Directoryドメインが複数ドメイン(シングルフォレスト–マルチドメイン)構成の場合、一部のドメインユーザーだけが同期されるように構成することができます。その場合、ADMAのプロパティを開いて、[Configure Directory Partitions]から該当するドメインにチェックをつけます。
これだけで同期対象となるドメインを絞り込むことができます。

MIIS023

 

■その2:同期されるOUのフィルター

同期を行うActive Directoryドメインの中から一部のOUだけを対象に同期させたい場合には該当するOUだけを選んで同期させることができます。その場合、ADMAのプロパティを開いて、[Configure Directory Partitions]から[Containers]をクリックして、該当するOUにチェックをつけます。

MIIS026

 

■その3:同期されるユーザーのフィルター

同期を行うActive Directoryドメインの中から特定の属性を持つユーザーだけを対象に同期させたい場合、同期対象となる属性とその値を設定することができます。
その場合、ADMAのプロパティを開いて、[Configure Connector Filter]から[Data Source Object Type]の[User]をクリックして、Filterを設定します。Filterには同期させたくない属性とその値を設定します。

MIIS027

ディレクトリ同期を使っていて、Administratorユーザーがなんで同期されないの?ディレクトリ同期ツールをインストールすると作られるMSOL_の名前で始まるユーザーがなんで同期されないの?という疑問を持った方も多いと思いますが、それはこのフィルターが設定されているからです。

たとえば、Administratorの場合、isCriticalSystemObject属性がTrueと設定されています。そのため、フィルターの設定により同期されません。また、MSOL_の名前で始まるユーザーもsAMAccountName属性がMSOLで始まる場合には同期されないようにフィルター設定が施されています。そのため、同期されないのです。このように、デフォルトでは15個のフィルターが設定されていますが、管理者がフィルター設定を増やせば、もっと様々な条件をもとに同期するユーザーを絞り込むことができます。

他にもフィルターする方法はいろいろ考えられますが、大きなところとしては以上の3つが使われる可能性の高いフィルターといえます。みなさんの会社のニーズに合わせてぜひ活用してみてください。

2014年の投稿もこれで終了です。
それでは、よいお年をお過ごしください。
Hoping you enjoy a happy new year!

 

■参考サイト
Office 365 Directory Synchronization In-Depth
http://www.messageops.com/documentation/office-365-documentation/office-365-directory-synchronization-in-depth

Active Directory Filtering for Office 365 Directory Synchronisation (Dirsync)
http://netwovenblogs.com/2014/12/02/moving-from-on-premise-to-office-365windows-azure-part-4/

FIM2010 Terminology and Glossary
http://technet.microsoft.com/en-us/library/ee534910(v=WS.10).aspx

Office 365管理者のためのディレクトリ同期ツール入門(2)

みなさん、こんにちは。国井です。

前回、Office 365管理者のためのディレクトリ同期ツール入門の第1回目としてディレクトリ同期ツールのUIツールであるmiisclient.exeの起動方法と簡単な見方を紹介しました。

今回はディレクトリ同期ツールによる同期がどのような流れで行われているか見てみましょう。

まずは前回も紹介したスライドから。

image

Active Directory Connector MA(ADMA)とWindows Azure Active Directory MA(AzureMA)がディレクトリ同期ツール内に作られ、メタバースを経由して同期が行われることを紹介しましたが、具体的にどのようなルートで同期が行われるかについてもMAでは定義されています。

MAで定義されている同期の(基本)ルートは次のとおりです。

1.Active DirectoryからADMAのCSへ同期
(図の1-1に当たるImportという処理で実現しています)

2.ADMAのCSからメタバースへ同期
(図の1-2に当たるSynchronizationという処理で実現しています)

3.Azure ADからAzureMAのCSへ同期
(図の2-1に当たるImportという処理で実現しています)

4.AzureMAからメタバースへ同期
(図の2-2に当たるSynchronizationという処理で実現しています)

5.メタバース内のデータをAzure ADと同期
(図の3に当たるExportという処理で実現しています)

以上がディレクトリ同期の流れになります。
Active DirectoryとAzure ADのそれぞれからImportとSynchronizationを実行し、メタバースにデータを格納しているのはそれぞれのディレクトリに格納されている情報を把握し、差分だけをエクスポートできるようにするためです。

これらの処理は3時間に一度、自動的に行われているため、私たちは意識することがありませんが、これを手動で行いたいとなったら、どのような操作を行えばよいでしょうか?

この点について、続いて見てみましょう。

まずは前回も紹介した、miisclient.exeを起動し、Management Agentsを開き、
Active Directory Connectorを右クリックして、Runをクリックします。

image

すると、Run Profile一覧が表示され、ImportやSynchronizationなどが選択できることが確認できます。

MIIS012

ImportとSynchronizationは同時に行うプロファイルが用意されているので、これを利用すれば便利ですが、すべてのオブジェクトを対象にインポートや同期を行うFull~と前回実行時からの差分だけをインポート/同期するDelta~があることに注意してください。

このことを踏まえて、前の図の1-1~3までを順番に実行すれば、手動でディレクトリ同期を実行することができます。

【コラム】ディレクトリ同期ツール/FIMのトレーニングの現状

一般的にマイクロソフトが提供する製品やサービスに対応するトレーニングは
Microsoft Universityコースとして認定トレーニングプロバイダ(CPLS企業)から提供されます。
しかし、ディレクトリ同期ツールをつかさどるForefront Identity Manager (FIM)の
トレーニングは本稿執筆時点では日本語版も、英語版で提供する企業もありません。

一方、FIMはインストールや初期設定から苦労させられる面倒な製品ですし、
お使いになる機会がありましたら、時間やコストを削減するためにも
一度トレーニングを受けていただきたいのです。

そのため、もしトレーニングを通じてしっかりベースを学習したいということでしたら、
クリエ・イルミネート社と一緒にトレーニングをアレンジメントさせていただくことができますので、気軽に私のメールアドレス(画面右上に書いてあります)またはクリエ・イルミネート社までお問い合わせください。

同期の実行結果はmiisclient.exeのOperationsメニューから確認できます。
それぞれの項目をクリックし、左下ペインを参照すれば、ImportやSynchronizationなどの処理によって、どれだけのオブジェクトの同期が行われたかを確認できますし、リンク(下の図で言うとAdds 6と書かれた部分)をクリックすれば具体的に同期されたオブジェクトを確認することができます。

MIIS002

ただし、オブジェクト一覧は以下のように表示され、私たちの見た目にわかる名前で表示してくれるわけではないので、あてずっぽうで適当なオブジェクトをダブルクリックし、

MIIS020

お目当てのオブジェクトが同期されているか、見つけるしかありません。。

image

最後はちょっと面倒でしたが、
ここまでのことができれば、トラブルが発生したときにトラブルシューティングの一環として、自分で、手動で、同期の処理を行うことができるようになり、「ディレクトリ同期ができない→途方に暮れる」だけではない、対策が自分でとれるようになるのです。

今日はここまでにしましょう。

次回は同期のフィルター設定を確認する予定です。

Office 365管理者のためのディレクトリ同期ツール入門(1)

 

みなさん、こんにちは。国井です。
今日はOffice 365 Advent Calendarに参加しております。

今日の内容はディレクトリ同期ツールです。
Office 365でActive DirectoryとOffice 365(Azure AD)の間でID情報を同期させる際、Office365のサイトからダウンロードして利用可能なディレクトリ同期ツールと呼ばれるツールを使います。ところが、このツール、実はマイクロソフトが提供しているディレクトリ同期サーバー製品である、Forefront Identity Manager(FIM)の簡易版であることをご存知でしたでしょうか?

ディレクトリ同期ツールは3時間に1回の割合で自動的にActive DirectoryのID情報をAzure ADへ同期してくれるので、メンテナンスフリーだと思うかもしれませんが、実際にトラブルに遭遇した場合、どこに問題の原因があるのか、自分である程度は調べられるようになりたいですよね。
そのようなときには、FIMの基本的なところをおさえておくと、役立つかもしれませんので、
実際の画面を見ながら基本を確認しておきましょう。

 

■FIMの処理概要
まず、FIMには3つの代表的なコンポーネントがあります。
それは、
・Management Agent (MA)
・Connector Space (CS)
・メタバース
の3つです。

image

Active DirectoryからAzure ADへ同期する場合、2つのディレクトリどうしを直接結んで同期しているわけではなく、メタバースと呼ばれるFIMが持つデータベースにいったん格納されます。

Active DirectoryとAzure ADでは対応する同じ属性名があるとは限りません。そのため、メタバースを一度経由することで、スキーマの違いを吸収しているのですね。

それから、Active Directoryに格納されているデータをメタバースに格納するとき、
Azure ADに格納されているデータをメタバースに格納するとき、それぞれ中間データベースにいったん格納します。このテンポラリとなるデータベースのことをConnector Space (CS)と呼んでいます。

また、Active Directoryの場合で言うと、Active DirectoryからCSを経由して最終的にメタバースにデータを格納する際、どのようなデータを格納すればよいか?や、Active Directory以外では使われない、グローバルグループ、ドメインローカルグループなどのグループ属性はメタバースにどのような属性として保存すればよいか?などの同期のためのルールを定めたものをManagement Agent(MA)と呼びます。

ディレクトリ同期ツールは、このようにインストールすることにより、メタバースの作成、MAの作成、MA内のCSの定義、同期フローの定義(これについては後で説明します)、などの設定を全部自動的に行ってくれるのです。だからみなさん、「ディレクトリ同期ツールのインストールが長い!」などと文句を言うはやめてあげてください。

 

■ディレクトリ同期ツール(FIM)の起動とインターフェイスの確認
簡単ですが、仕組みが確認できたら、続いてディレクトリ同期ツールを起動します。
ツールはc:\program files\Microsoft Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exeを実行すると利用できます。

MIIS001

実行するときに注意してほしいのは、インストール後、すぐに実行しないこと。
実行直後はmiisclient.exeにアクセスする権限が割り当てられていないので、
インストールが終わったら、一度サインアウト/サインインをしましょう。

その後、起動すると以下のような画面が表示されます。(FIMでも同じ画面です)
画面上部に
Operations, Management Agents, Metaverse Designer, Metaverse Search, Joinerのボタンがあります。これが大まかにメニューだと思ってください。

まず、Operationsメニュー。
Operationsメニューでは、過去のディレクトリ同期の結果が確認できます。ログの時刻を見てもらうと、おおよそ3時間ごとに同期が実行されていることが確認できます。

MIIS002

続いて、Management Agentsメニュー。
名前のとおり、MAが登録されている箇所です。画面には、
Windows Azure Active Directory Connector(Azure MA)とActive Directory Connector(AD MA)の2つがありますが、
前の図で説明すると、Azure MAはメタバースからAzure ADまでの同期を担当し、
AD MAはActive Directoryからメタバースまでの同期を担当しています。

image

次はMetaverse Designer。
Metaverse Designerはメタバースのスキーマを定義するところです。ディレクトリ同期ツールとしてFIMを使っている場合には、ほとんど設定変更することはないでしょう。

image

Metaverse Searchは名前のとおり、メタバースに登録されたID情報を検索するために使います。Scope by Object Typeからpersonと選んでいただいて検索すると、メタバースに登録されたユーザーの一覧が表示されます。検索結果はdisplayname属性で表示されますが、displayname属性を持たないユーザーがいると、画面に表示されません。だけど、空欄をダブルクリックすると、そのユーザーのプロパティが表示される不思議。

image

最後はJoinerです。JoinerはDisconnector Typeと呼ばれるID情報を表示できるところで、
「Active Directoryの国井ユーザーはAzure ADのKuniiユーザーとみなす」のような2つのIDの関連付けをFIMは行うことで同期を行うのですが、Joinerに表示されるのは関連付けがされていないIDの一覧になります。普通の管理では使うことはあまりないですね。

image

 

■メタバースとCSに登録されたオブジェクトの参照
画面は戻って、Metaverse Searchの検索結果について。
Metaverse Searchで検索したユーザーですが、検索結果のdisplaynameをダブルクリックすると、メタバースに登録されたユーザーの属性情報が確認できます。

image

さらに、Connectorsタブをクリックすると、経由したCS(MA)の名前が表示されます。このケースでは、Active Directory ConnectorとWindows Azure Active Directory Connectorをそれぞれ経由したということがわかります。

image

そして、CSの名前をダブルクリックすると、CSに登録されていた時点でのユーザーの属性情報が確認できます。メタバースと同じように見えますが、よく見ると、CSに保存されていたuserAccountControl属性はメタバースに入ると、消えてなくなっていることが確認できます。

image

このようにFIMの管理画面を見ると、ディレクトリ同期が正常に行えているか、そして同期ができていない場合には、どこに問題があるのか?ということを探るきっかけを色々と与えてくれます。

今日は長くなってしまったので、ここまでにしましょう。続きは次回の投稿で。

 

明日のOffice 365 Advent CalendarはADFS/Office365トレーニングの主催会社として、いつもお世話になっている沼口さんです。お楽しみに。

FIM 2010のバンドルバージョン

PowerPoint 2010でスライドを作成する、というのは私の普段の仕事のひとつなのですが、たまたまクリップアートを
使う機会があり、クリップアートの検索ボックスに「会議」と入力したら、こんなクリップアートが出てきました。

meeting1

なんか、すっごいお金が動きそうな会議っぽいですね。

SharePoint Server 2007のとき、データストアを指定してユーザープロファイルのインポートを行う機能というのがありました。
たとえば、Active DirectoryのユーザープロパティをSharePointのデータベースにインポートして、SharePointのユーザー
プロパティとして活用するという使い方です。

SharePoint Server 2010では、同様の機能が搭載されていますが、なんと、この機能にFIM2010が使われています。
SharePoint Server 2010をインストールすると、自動的にUser Profile Serviceという名前でFIM2010がインストールされます。

User Profile ServiceはどのようなサービスとしてWindows上で動作しているのかと思い、[サービス]管理ツールを
見てみると、Forefront Identtity Manager ServiceとForefront Identity Manager Synchronization Serviceの
2つが登録されていることがわかります(画面1)。これは、まさにFIMそのものですね。

SP-FIM1
■画面1-SharePointサーバーの[サービス]管理ツール

Synchronization Service管理ツールはあるのかな、と探してみるとこれもやっぱりありました。
%ProgramFiles%\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe
を実行すると、ご覧のように起動します(画面2)。

SP-FIM2
■画面2-SharePoint Server 2010で提供されるFIM管理ツール

デフォルトではMAとして、FIM Serviceデータベースに接続するためのMAであるILMMAと、
SharePointのプロファイルデータベースに接続するためのMAであるMOSS-xxxxの2つが登録されています。
SharePoint 2007のときと同じようにActive Directoryからユーザープロパティの情報をレプリケートさせたい場合、
[サーバーの全体管理]-[アプリケーション構成の管理]-[サービスアプリケーションの管理]-[(User Profile Serviceのサービスアプリケーション名)]の順にクリックすると表示される画面で[同期接続の構成]を使い、Active Directoryドメインを登録します。

SP-FIM3
■画面3-SharePoint Server 2010 サーバーの全体管理画面

すると、画面2のように、MOSSAD-xxxという名前のMAが作成され、同期可能な状態になります。
そこで、画面3の[プロファイルの同期の開始]をクリックすると、同期が始まります。
画面4が同期を行った後のSynchronization Service管理ツールのOperation画面です。

SP-FIM4 
■画面4-MA Operationログ

ログを見てみると、最初(画面4一番下のログ)にMOSSAD-ADDS MAのImportを実行し、
Active Directoryからオブジェクト情報をインポートします。
次(画面4一番下から2番目のログ)にMOSSAD-ADDS MAのFull Syncを実行し、メタバースとの同期を行います。
そして(画面4一番下から3番目のログ)、MOSS-xxx MAのExportを実行し、
SharePointのプロファイルデータベースにエクスポートを行います。
ここまでの一連の処理によって、Active DirectoryからSharePointへユーザープロパティの情報がレプリケートされます。
さらに、以降のログを見ると、逆にSharePointからActive Directoryへプロパティの情報がレプリケートされていることが確認できます。つまり、SharePoint Server 2010では、Active DirectoryからSharePointへのレプリケートだけでなく、SharePointからActive Directoryへのレプリケートもサポートされているのです。
これがSharePoint Server 2010の新機能だそうなのですが、
FIM2010を使っているわけだから、ある意味当たり前ですよね。

ところで、MOSSAD-ADDS MAのプロパティ(画面5)を見てみると、属性マッピングが思いっきり入っていることが確認できます。
FIMでは、よくCS→MVやMV→CSのフローはFIMのポータルサイトから、着信同期規則、発信同期規則というのを
それぞれ作成したりしますが、SharePoint Server 2010では、MAの中で同期の設定を行い、
FIM Serviceデータベースを介さずに(つまり、Active Directory → メタバース → SharePointの経路で)
レプリケーションする設定を行っているのです。
これって、MIIS2003やILM2007のときと同じレプリケーション方法ですね。

SP-FIM5
■画面5-ADDS MAのプロパティ

属性マッピングをよくよく見てみると、SPS-ClaimProviderID なんていう、面白そうな属性を見つけることができます。
きちんと調べて、メカニズムや活用方法などを見出しておきたいですね。

お仕事がたまって大変なところなので、今日はこのあたりで。

FIM2010 RTM版のインストール

 
来週は、いよいよ4月25日からLos AngelesでThe Expert Conference2010が開催されます。
私も参加する予定でおります。FIMやADFSv2でどんな話が聞けるのか、今から楽しみです。
 
今週はLas VegasでMicrosoft Management Summitが開催されており、
両方参加したかったのですが、2週間もスケジュールに穴を空けたら、
さすがに会社を追われてしまうと思ったので、
ギャンブルを諦めて、サンタモニカのビーチに遊びに
ディレクトリに集中して勉強することにしました。
 
そこで、カンファレンスに参加する前に、自分の疑問点などをまとめておこうと思い、
FIMのイメージを起動したら、スナップショットもろとも全部壊れていたことが発覚!
いちから作り直すことになりました。。
 
 
せっかくなので、FIM2010のインストールについて、
RTM版のインストール方法をステップバイステップ形式で、もう一度まとめておこうと思います。
正直、RC版からあまり変わっていないです。
(日本語Language Packを別途インストールするっていう実装は変わってて欲しかったなあ)
前提条件等については、「FIMのインストール(1)」をご覧ください。
 
 
■Synchronization Serviceのインストール
Forefront Indettiy Manager Synchronization Service(FIM SS)とも呼ばれる、
Synchronization Serviceは、メタバースDBと各種ディレクトリサービスとの間で
同期を行うためのサービスです。
FIMのインストールでは、最初にこのサービスのインストールを行います。
 
Synchronization Serviceのセットアッププログラムを起動し、
WelcomeダイアログでNextをクリックします。
 
 
 
使用許諾契約で同意して、Nextをクリックします。 
 
 
 
Custom Setupで、Nextをクリックします。
 
 
 
SQL Serverの場所とインスタンスをそれぞれ指定します。
今回はFIMのサーバーと同一のサーバーにインストールしている場合は、
デフォルトの状態でNextをクリックします。
 
FIM SSのサービスアカウントを指定します。
本来だと専用のアカウントを用意しますが、今回はAdministratorをそのまま使います。
このときに注意しなければならないのが、ドメイン名をNetBIOS名で入力しておく点です。

 
FIM SSを使用するための権限を持ったグループを指定します。
ここで指定するグループの名前はデフォルトのまま使っても問題ありませんが、
事前にこれらのグループがActive Directory Domain Servicesで作成されていることが前提です。
 
 
RPCを通じて、FIM SSが通信できるように、
Windowsファイアウォールのポートをオープンする設定を行います。
 
 
ここまでが完了したら、Startをクリックしてインストールを開始します。
 
 
ここまででFIM SSのインストールは完了です。
インストール後の作業としては、ウィザード内で作成したグループの
FIMSyncAdminsグループにFIM SSの管理を行うユーザーを追加してください。
また、私の環境では、サーバーの再起動後にFIMSyncAdminsグループのメンバによる
Synchronization Service管理ツールの利用が可能になりました。
 

■Identity Manager and Portalのインストール
Identity Manager and Portalとは、FIMのポータルサイトなどを担当するサービスで、

これもFIMの利用には欠かせないサービスです。
 
Identity Manager and Portalのセットアッププログラムを起動し、
WelcomeダイアログでNextをクリックします。
 
 
使用許諾契約に同意して、Nextをクリックします。
 
 
 
Customer Experience Improvement Programは参加・不参加を選択します。
 
 
 
Custom Setupで、インストールするコンポーネントを選択します。
ここではすべてのコンポーネントを同一のサーバーで使いますので、
デフォルトの状態で、Nextをクリックします。
 
 
FIM Serviceで使用するデータベースサーバーとデータベース名を指定します。
データベース名はFIMServiceというDB名を使うということを覚えておいてください。
FIMを利用する上で重要になります。
 
 
FIM Serviceで使うメールサーバーを指定します。
Exchange Server 2007だとクライアントアクセスサーバーとの通信になります。
 
FIM Serviceで使用する証明書を発行する場所を指定します。
あらかじめ、証明書が実装されていれば証明書を選択し、
無ければ、自己署名の証明書を使うように指定します。
画面では、自己署名の証明書を使うように指定しています。
ちなみに、ここで指定する証明書はIIS7の[サーバー証明書]に実装されます。
 
 
FIM Serviceで使用するアカウント(サービスアカウント)を指定します。
今回はAdministratorを使ってしまいます。
メールアドレスを指定しますから、メールボックスがあらかじめ作られている
アカウントを指定してください。
 
 
FIM SSを提供するサーバー名とFIM MAのアカウント名を指定します。
ここでは、FIM MAのアカウント名にFIMAdminというFIMSyncAdminsのグループのメンバーに
なっているアカウントを指定しました。
 
 
 
FIM Service and Portalサービス(FIM Service)を提供するサーバーのアドレスを指定します。
通常はこのウィザードを実行しているコンピュータになると思います。
 
 
FIM Service and Portalサービス(FIM Service)を提供するSharePointサイトのURLを指定します。  
 
 
FIM Service and Portalで使用するポートおよびアクセス許可(SharePoint)を許可する場合、
チェックをつけます。この設定を行わない場合はセットアップ終了後に手動で設定しなければ
ならないので、ここで設定しておくことをお勧めします。
 
 
ここまでの設定ができたら、インストールを開始します。
 
 
完了したら、Finishをクリックして終了します。
 
 
■Language Packのインストール
Identity Manager and Portalのインストールが完了して、
FIMのポータルサイトが表示されます。しかし、英語なので、
ポータルサイトを日本語化するプログラム(Language Pack)を別途インストールしなければなりません。
 
セットアッププログラムを起動し、WelcomeダイアログでNextをクリックします。
 
 
使用許諾契約で同意して、Nextをクリックします。 
 
 
 
Custom Setupで対応する言語を選択します。 
 
 
Installボタンをクリックして、インストール開始です。
 
 
ここまでの作業が完了すると、ポータルサイトは日本語化され、
下図のようなサイトが表示されます。
 
ポータルサイトが日本語化されても、サイトの設定など、SharePoint自体の管理画面等は英語のままですから、
必要に応じてSharePoint自体のLanguage Packをインストールしていただければと思います。
 
 

Forefront Identity Manager 2010 RC1 登場

 
ふぁらおさんのブログでも紹介されていましたが、
気がついたら、Forefront Identity Manager 2010(FIM2010)のRC1が登場していましたね。
インストール面での変更点がいくつかありましたので、ひっそりと過去の投稿を書き換えておきました。
その他では、
・ポータル用データベースの名前がMSILMからFIMServiceに変更されたこと
・ポータル用データベースへのアクセスがポート5725からできるようになったこと
 (http://localhost:5725のようにアクセスするそうです)
・ILMの名前はすべてFIMに置き換えられていること
 (証明書管理のCLMもFIM Certificate Managementに変わっています)
・PowerShell対応になったこと
などがあります。
 
今日はこの中から、PowerShellコマンドレットを使ってみたいと思います。
利用可能なコマンドを調べてみたら、次のとおりでした。
 
 
Add-PSSnampin FIMAutomationを一度実行すると、FIMのコマンドレットが利用できるようになるのですが…
たった6個かよ!
製品リリースまでに、もっと増えていることを期待しましょう。
 
ここにあるコマンドレットは、いずれもFIMポータルの設定を移行するために利用できるもので、
テスト環境などでFIMポータルから色々と行った設定を、本番環境にに移行したいというときに使うようです。
 
実際に使ってみましょう。
Export-FIMConfigというコマンドレットが設定をエクスポートするコマンドレットで、
ポート5725に接続するように指定し、実行すれば、FIMポータルで持っている設定をエクスポートします。
そして、CovertFrom-FIMResourceコマンドレットがExport-FIMConfigコマンドレットでエクスポートした設定を
XMLファイルに変換してくれるコマンドレットになります。
 

PS C:\> Add-PSSnampin FIMAutomation #FIM用コマンドレットのためのスナップイン追加

PS C:\> $expData = Export-FIMConfig -uri http://localhost:5725/ResourceManagementService -policyConfig -portalConfig  #FIMポータル設定のエクスポート

PS C:\> $expData | ConvertFrom-FIMResource -File c:\Users\FimAdmin\Documents\expData.xml #FIMポータル設定のXML化

PS C:\> $expData | Import-FIMConfig -uri http://localhost:5725/ResourceManagementService
     → これは失敗

 
 
ちなみに、これがXML化したポータル設定のファイルの中身。
FIMポータルにあらかじめ用意されている、Approvals Approve Reject Viewable Setというセットが確認できますね。
 
 
ここまではうまくいくのですが、エクスポートしたデータをインポートしようとすると失敗してしまうのです。
うーむ… またひとつ、宿題が増えた..