本文へジャンプ

ソフトウェア > Lotus > Lotus Developer Domain > 製品別技術情報 > Lotus Notes/Domino > 

LDD Today

AdminPのすべて Part1


 Lotus Software
by ティモシー・スピード、ポール・レイモンド
レベル：中級者
対象: Notes/Domino
原文の掲載：2003年6月2日

LDD Todayの原文（US）

インデックス
AdminPのコンポーネント
アクション
システム管理要求データベース
まとめ

月曜日、午前10時。IT部門の状況報告会議の時間です。会議が始まり、新任の部長に対して各人が先週の活動状況を順に報告し、いよいよあなたの番です。「先週の活動内容は、ユーザー名変更が1,000件、Web証明書発行が800件、レプリカ作成が200件、新規サーバーへのユーザーの移動が650件です。これには、1人のアドミニストレーターと1人のオペレーターが作業に当たりました」と報告します。すると、部長がまったく信じられないといった面持ちで尋ねます。「たった2人ですべてやったのですか。」あなたはうなずき、答えます。「実際には、オペレーターがほとんどの作業をしたのですが。」挙げ句の果てに、当惑を隠せない様子の部長が問い直します。「いったいどんな魔法を使ったのですか。」あなたは笑みを浮かべながら一言、答えます。「AdminPです。」

上記のシナリオは、決して空想の出来事ではありません。AdminP（システム管理プロセスともいいます）は、本当にこのように強力なものなのです。AdminPは、Domino環境のさまざまな日常のシステム管理タスクを自動化するプログラムです。これらのタスクの管理対象としては、次のようなものがあります（ほんの一部の例です）。
  • メール・ファイル（メール・ファイルの移動／削除、［管理者］アクセス権の付与なしでのカレンダーの代理、管理の委任、［設計者］アクセス権なしでの不在通知エージェントの有効化）
  • レプリカ（レプリカの作成、移動、および削除）
  • ユーザー名（ユーザー名／グループ名の変更、サーバーの削除、内部証明書管理、組織レベルの証明書間でのユーザーの移動、ID復旧情報の自動更新）
本稿では、AdminPのすべてのコンポーネントについて説明する全2回の連載の第1回として、各コンポーネントの仕組みとこれらの機能を使って仕事をもっと楽にこなす方法（そして、ボスを唸らせる方法）について説明します。本稿の対象読者は、NotesおよびDomino用語に精通している熟練したDominoアドミニストレーターです。


AdminPのコンポーネント
本稿では、AdminPを単一のエレメントではなく、一連のコンポーネントとして定義します。これらのコンポーネントには次のものがあります。
  • AdminPサーバー・タスク
  • Administratorクライアント（Domino/Web）
  • Notesクライアント
  • Domino Directory（names.nsf）
  • 認証ログ・データベース（certlog.nsf）
  • システム管理要求データベース（admin4.nsf）
  • システム管理サーバー（ドメイン内の各データベースに割り当てられる）
以下のセクションでは、上記のコンポーネントについて簡単に説明します。

AdminPサーバー・タスク
AdminPサーバー・タスクは、すべてのDominoサーバー上で実行されます。このタスクは、Dominoサーバーを最初に起動したときにロードされ、Notes.ini変数「ServerTasks」によって制御されます。AdminPサーバー・タスクは、定期的に（サーバー文書のシステム管理プロセス・セクションに指定された間隔で）起動され、システム管理要求データベース内の待ち状態のコマンドを実行します。システム管理要求データベースに置かれたコマンドにはそれぞれ、アクションが割り当てられます。これらのアクションは、基本的にはシステム管理プロセスを実行する命令コードです。

システム管理要求データベースに置かれたコマンドはそれぞれ、文書によって表されます。各文書には、［アクション］などのさまざまなフィールドがあります。各アクションがサーバー上で完了すると、その要求の状況を示す返答文書が作成されます。

AdminP要求は、特定のNotesドメイン内に限定されません。外部ドメインネットワーク情報 (EDNI) 文書を設定すれば、一部のコマンドをドメイン間で共有できるようになっています。

Administratorクライアント
Administratorクライアントは、AdminPコマンドを実行するのに必要なすべてのツールを備えています。これには、ユーザー名の変更、ユーザーの削除、レプリカの削除、データベースの移動、階層間でのユーザーの移動などが含まれます。

Notesクライアント
Notes/Domino 6では、Notesクライアントもシステム管理プロセスに積極的に関与するようになり、さまざまなシステム管理プロセスを実行できるようになりました。たとえば、Notesクライアントで、ユーザー名の変更やx509v3証明書をNotes.idファイルに受け入れたり、カレンダーACLの代理を依頼したりすることができます。Notesクライアントは、ユーザーを別のサーバーに移行するプロセスに関与し、ユーザーのパスワード変更要求やNotes.idとWebパスワードの同期要求を発行することができます。また、ユーザーに対してプロンプトを表示することなく、自動的にID復旧情報を受け入れるようになりました。

Domino Directory
Domino Directoryは、AdminPで使用する命令の一部を提供します。たとえば、ユーザー名を変更すると、証明書情報が変更され、Domino Directory内のユーザー文書に保存されます。これは、名前変更プロセスの実行中、ユーザー文書の［変更要求］フィールドに表示されます。各ユーザーの名前は、ユーザー文書のさまざまなフィールドに保存されます。ユーザー名を変更すると、古い名前と新しい名前の両方が保存されます。

また、すべてのサーバーにはサーバー文書があり、それによってサーバーの管理方法が制御されます。すべてのサーバー文書には、AdminPのパラメーターに関するセクションがあります。

AdminPコマンドは、次に示すようなDomino Directory情報に影響します。
  • リソース名
  • クラスター
  • クライアント情報を含むユーザー文書
  • HTTPパスワードの同期
  • グループの更新／削除
  • サーバー情報（プロトコルおよびバージョン）
  • ポリシー
  • 認証機関（CA）設定
  • ライセンス・トラッキング
認証ログ
ドメインの最初のサーバーをインストールすると、認証ログ・データベース（certlog.nsf）が作成されます。認証ログには、新規ユーザー／新サーバーの登録、ユーザーの再認証、ユーザー名の変更、組織認証者間でのユーザーの移動をはじめとする、Dominoによる認証関連のアクティビティーが記録されます。各ログ・エントリーは、次図に示すデータを追跡します。



AdminPは、システム管理要求の実行に使用される各サーバー上に認証ログを必要とします。そのためには、すべてのシステム管理サーバーおよびユーザー管理に使用されるすべてのサーバー上に認証ログのレプリカを作成します。

システム管理要求データベース
システム管理要求データベース（admin4.nsf）には、1つのドメイン内のすべてのシステム管理要求が格納されます。（アクションによって）システム管理要求データベースに置かれた要求はすべて、ドメイン内のすべてのサーバーに複製されます。このデータベースについては、後ほど詳しく説明します。

システム管理サーバー
すべてのデータベースには、データベースのACLで指定することによって、システム管理サーバーを割り当てなければなりません。これはDomino Directoryも同様です。システム管理サーバー設定によって、AdminPが各データベースを処理する場所が指示されます。システム管理サーバーは、名前の横にキー・アイコンが付いた状態でACLに表示されます。各ドメイン内には、1つのプライマリー・システム管理サーバーがあります。プライマリー・システム管理サーバーは、Domino Directory（names.nsf）のACL内の値によって決まります。データベースに対してシステム管理サーバー（プライマリー・システム管理サーバーを含む）を設定するには、データベースを強調表示し、［ファイル］ ‐ ［データベース］ ‐ ［アクセス制御］の順に選択し、［詳細］をクリックします。



例として、1,000ユーザーの名前を変更する必要があるとします。各ユーザーは、1つのデータベース内の10万件の文書の［作成者］、［読者］、および［名前］フィールドにエントリーを持っている可能性があります。つまり、それらすべての文書を変更する必要があるかもしれないということです。次図について考えてみましょう。



この例では、4つのサーバーと2つのアプリケーションがあります。Server Aは、Domino Directoryのシステム管理サーバーです。そのため、Server Aがこのドメインのプライマリー・システム管理サーバーとなっています。Server Bには、App 1とApp 2の2つのアプリケーションがあります。App 1のシステム管理サーバーがServer Bであり、App 2のシステム管理サーバーがServer Dです。Server Cには、各アプリケーションのレプリカがあります。［名前］フィールドの値を変更するコマンドは、プライマリー・システム管理サーバー（Server A）に対して発行された後、処理のために他のサーバーに送信されます。各サーバーは、コマンドを受け取ると、受信時間とサーバー文書の設定に基づいてコマンドを処理します。

App 1データベースがServer BとServer Cの両方に存在することに注目してください。名前変更コマンドを両サーバーで実行した場合、両レプリカに対して10万件の変更が行われ、たくさんの複製競合が発生することになります。AdminPは、各サーバー上の各データベースACLを調べることによって、そうした状態が発生しないように設計されています。データベースACLの［システム管理サーバー］エントリーがそのサーバー名と一致する場合、コマンドは処理され、そのサーバー名と一致しない場合にはコマンドは無視されます。Server Bの場合、App 1のACLエントリーによってシステム管理サーバーとして指定されています。したがって、Server Bが受信したコマンドはApp 1に対して実行されます。システム管理コマンドは、Server Cにも送信されます。しかし、このサーバーには、このサーバーをシステム管理サーバーとして指定しているアプリケーションはないため、Server Cではコマンドは処理されません。一方、Server Dは、App 2のACLにシステム管理サーバーとして指定されているため、Server Dが受信したコマンドはすべて、App 2に対して実行されます。

おわかりのように、このアーキテクチャーによって、1つのサーバーでのみ特定のアプリケーションを更新することが可能になります（レプリカIDによって）。ここで問題となるのは、「Domino環境内のすべてのデータベースに対して、［システム管理サーバー］エントリーを追加する必要があるのか」ということです。そのとおりです。しかし、慌てる必要はありません。この作業は、いくつかの方法によって行うことができます。
  • 手動で
    ［アクセス制御リスト］ダイアログボックスの［詳細］セクションを開き、［システム管理サーバー］フィールドを編集します。この方法は、データベースが1つか2つの場合には問題ありませんが、大規模な環境では明らかに非常に時間がかかることになります。
  • Administratorクライアント（DominoまたはWeb）によって
    Administratorクライアントでは、個々のデータベースまたは大規模なデータベース・グループの設定を1つの操作で行うことができます。Administratorクライアントを起動し、更新する必要があるデータベースを選択します。そして、右クリックし、［アクセス制御］ ‐ ［管理］の順に選択すると、標準の［アクセス制御リスト］ダイアログボックスが開きます。必要に応じてACLを編集し、エントリーを保存します。そうすると、選択したすべてのデータベースのシステム管理サーバー設定が更新されます。
  • LotusScriptによって
    NotesACLEntryクラスにはRead/Writeプロパティーがあり、LotusScriptエージェントで使用することができます。ISAdminServerプロパティーを使用すると、ACLの［システム管理サーバー］エントリーの読み取り／設定を行う単純なエージェントを作成することができます。
  • Lotus Notes APIによって
    Lotus Notes APIを使用すると、データベースのシステム管理サーバー名の編集・管理のための独自のカスタム・ツールを作成することができます。この目的で一般に使用される関数は、ACLGetAdminServerとACLSetAdminServerの2つです。
  • 外部ベンダー・ツールによって
    ベンダー・ツールにも、システム管理サーバー管理機能を備えたものが数多くあります。詳細については、各ベンダーにお問い合わせください。
 
上に戻る
 
アクション
次に、AdminPコマンドについて見ていきましょう。各コマンドは、システム管理要求データベースに置かれた個々の文書によって制御されます。すべての文書には［アクション］フィールドがあります。これらのアクションは、2つの場所（システム管理要求データベース内の文書のフィールド・プロパティーまたはシステム管理要求文書フォーム）に表示されます。後者の場合、［アクション］共有フィールドを開くと、次のような選択リストが表示されます。



各アクションには番号が付いています。R5には82種類のアクションが用意されていましたが、Domino 6では165種類に増えています。アクション番号は後方互換です。たとえば、アクション1（アクセス制御リストのユーザー名の変更）はR5とDomino 6に共通ですが、アクション119（アクセス制御リストのWebユーザー名の変更）は、Domino 6で新しく用意されたものです。完全なリストについては、「Proxy actions in R5 and Domino 6 sidebar」をご覧ください。

AdminP要求ごとに、プロセス・ログという返答文書を作成することができます。返答文書には、AdminP要求が正常に完了したかどうかが表示され、失敗した場合にはエラー・メッセージが表示されます。ほとんどのアクションは、プライマリー・システム管理サーバー上に作成されますが、スポーク・システム管理サーバー上で実行できるものもあります。たとえば、ユーザー名を変更する場合、1次要求はプライマリー・システム管理サーバーでAdminPによって発行されます。この例では、アクション6（階層付きユーザーの移動）は、プライマリー・システム管理サーバー上に作成されます。名前の変更を承認すると、プライマリー・システム管理サーバーはアクション8（Dominoディレクトリの変更）を作成します。AdminPによってパブリック・キーが更新されると同時に、ユーザー文書の［変更要求］フィールドも更新されます。

ユーザー文書の［システム管理］タブには、［変更要求］というフィールドがあります。このフィールドの内部名は「DisplaychangeRequest」であり、式は以下のとおりです。

@If((ChangeRequest != "" | $AdminpOldWebNameExpires != ""); "Pending";"None")

［変更要求］フィールドに値がある場合、［処理待ち］と表示されます。

アクションのタイプ
AdminPアクションには、3種類の基本タイプがあります。
  • プライマリー・システム管理サーバー上で実行される操作
  • すべてのスポーク・システム管理サーバー上で実行される操作
  • 目的のサーバー上で実行される操作
以下のセクションでは、これらのアクションのタイプについて説明します。

＜プライマリー・システム管理サーバー上で実行される操作＞
ほとんどのAdminPプロセスは、プライマリー・システム管理サーバーで開始されますが、実際のコマンド（アクションを伴う文書）は、ほぼすべてのサーバー上に作成することができます。ここで、ユーザーの組織レベルの変更について考えてみましょう。これはアクション6（階層付きユーザーの移動）です。Domino Directoryからこのプロセスを開始すると、システム管理要求データベースに文書が作成されますが、この文書には管理者の承認が必要です。この文書を承認すると、もう1つの文書が作成されます。これはアクション8（Dominoディレクトリの変更）です。このアクションを実行できるのは、プライマリー・システム管理サーバーのみです。

アクション8が正常に実行されると、ユーザーの情報によってDomino Directoryが更新され、スポーク・サーバーに複製されます。ユーザーがこのスポーク・サーバー上でデータベースを開くと、アクション5（ユーザー名の変更）が作成されます。次に、プライマリー・システム管理サーバーを相手にシステム管理要求データベースが複製され、このアクションが実行されます。この例では、アクション6、8、および5はすべて、プライマリー・システム管理サーバー上で実行されます。アクション5はスポーク・サーバー上に作成されますが、このアクションは、そのユーザーに関してDomino Directoryが更新されるときに実行されます。いずれの場合も、アクションの実際の実行場所はスポーク・サーバーではなく、プライマリー・システム管理サーバーです。

以下の表は、プライマリー・システム管理サーバー上でのみ実行されるAdminPアクションのリストです（完全なリストではありません）。

Dominoディレクトリからの削除 レプリカ作成の加速
サーバー文書へNotesビルド番号を追加 サーバーレコードにディレクトリタイプの保存
Dominoディレクトリのサーバー名の変更 ユーザーレコードのローミングサーバーフィールドの置換
Dominoディレクトリのユーザー名の変更 Dominoディレクトリのユーザー情報を変更
階層付きユーザーの移動（実際には任意のサーバー上で承認可能） DominoディレクトリのCA設定の変更
Dominoディレクトリから統計モニターの削除 Dominoディレクトリのライセンストラッキング情報の更新
Dominoディレクトリの変更 Dominoディレクトリの再変更
Dominoディレクトリのサーバー再認証 Dominoディレクトリのポリシーレコードの削除
Dominoディレクトリのユーザー再認証 DominoディレクトリのWebユーザー名の変更
ユーザー文書からの削除 DominoディレクトリのWebユーザー名の変更
Dominoディレクトリのユーザーパスワードの変更 ユーザー文書のWebユーザー名の変更
ユーザー文書へインターネットの認証を追加 DominoディレクトリからWebユーザーの削除
Dominoディレクトリからユーザーの削除 DominoディレクトリのHTTPパスワードの変更
Dominoディレクトリからサーバーの削除 ユーザーレコードのローミングユーザー状態の更新
Dominoディレクトリからグループの削除 ユーザーレコードのローミングユーザー情報の更新
Dominoディレクトリ内でのユーザー削除の承認 Dominoディレクトリの相互認証の再認証
Dominoディレクトリ内でのサーバー削除の承認 Dominoディレクトリの認証機関の再認証
Dominoディレクトリ内でのユーザー名変更の承認 Dominoディレクトリ内でのグループの追加または削除
Dominoディレクトリ内でのサーバー名変更の承認 DominoディレクトリのID復旧情報の変更
Dominoディレクトリの会議室やリソースの変更


では、どのタイプのコマンドがどのサーバーに対して実行されるかを知るにはどうすればよいでしょうか。システム管理要求データベースを開き、システム管理プロセス要求文書を見ると、［アクション対象サーバー］というフィールドがあることがわかります。この例では、このフィールドは［Dominoディレクトリの管理サーバー］に設定されています。

＜すべてのスポーク・システム管理サーバー上で実行される操作＞
先ほどの例を続けましょう。ユーザーが新しい名前を承認し、アクション8（Dominoディレクトリの変更）がいずれかのスポーク・サーバーに作成されました。このアクションは、直ちにドメインのプライマリー・システム管理サーバーに複製されます。このアクションの実行後、AdminPによってさらにいくつかの要求が作成されます。そのうちの1つは、ドメイン内のすべてのサーバー上の各データベースのACLを更新するアクションです。これはアクション1ですが、この場合も先と同様に、システム管理要求データベースの要求文書を見ればすぐにわかります。

要求文書には、［アクション対象サーバー］フィールドがあります（下図参照）。このフィールドにアスタリスク（*）が表示されている場合、そのコマンドはドメイン内のすべてのサーバーで実行が試みられます。以下に、「アスタリスク」コマンドの例をいくつか示します。
  • アクセス制御リストからユーザーの削除
  • アクセス制御リストの変更
  • 階層付きユーザーの移動
  • 読者／作成者フィールドからの削除
  • 未読リストのユーザー名の変更
＜目的のサーバー上で実行される操作＞
AdminPは、実に洗練されており、目的のサーバー・コマンドもここから提供されるようになっています。先ほどと同様に、ユーザー名変更の例を進めましょう。これまでのところ、名前変更プロセスを実行し、ユーザーによって新しい名前が承認され、AdminPによってACLのユーザー名を変更するコマンドが発行されました。次に、AdminPによってこのユーザーのユーザー文書が分析され、目的のコマンドを作成する必要があるかどうかが決定されます。ユーザー文書にメール・ファイルのリストがある場合、AdminPは次の2つのコマンドを作成します。

メールファイルのカレンダーエントリとプロフィールのユーザー名の変更
空き時間データベースのユーザー名の変更

上記のコマンドは目的のサーバーに複製され、そこで実行されます。要求文書を開き、［アクション対象サーバー］フィールドを見れば、どのコマンドが目的のサーバーに対するものかを確認することができます。この場合の値は［NTMain］です。つまり、コマンドはそのサーバーのみで実行されるということです。

ここで、注意しなければならないことがあります。それは、選択複製式を作成しない限り、目的のサーバー・コマンドを含む、システム管理要求データベース内のすべてのコマンドがすべてのサーバーに複製されるということです。これを回避するための選択複製式の例を以下に示します。

ASDDList := "0":"2":"3":"4":"5":"7":"8":"9":"10":"11":"12":"16":"19":"26":"28":"29":
"30":"34":"35":"36":"37":"40":"41":"44":"46":"47":"50":"52":"54":"55":
"56":"63":"64":"67":"70":"71":"73":"76":"77":"80":"83":"85":"86":"89":
"95":"96":"97":"98":"99":"103":"107":"109":"110":"113":"118":"120":
"121":"127":"133":"134":"136":"141":"144":"146":"157":"159";

SELECT @IsMember (@LowerCase
(@Name ([CN] ; ProxyServer));"*":@LowerCase(@Name([CN]; @UserName)))
& Type != "AdminLog" & !@IsMember (ProxyAction;ASDDList)

注意：これはサンプル・コードにすぎません。このコードに関するサポートは提供されませんので、自己責任において使用してください。この式はスポーク・サーバーのみに適用し、ハブ・サーバーやプライマリー・システム管理サーバーには適用しないでください。また、Dominoのリリースによっては、書き換えが必要になる可能性があります。

アクションの実行タイミング
アクションは、種類に応じてさまざまなタイミングで実行されます。タイミングには次の4種類があります。
  • 即時
    これらの要求は通常、1分以内に実行されます。例としては、［メールサーバーへのアクセス権チェック］、［新規メールサーバーのアクセス権を上げる］、［新規メールファイルレプリカの作成］、［新規メールファイルフィールドを追加］、［メールファイルフィールドの置換］、［新規メールサーバーへ変更を反映］などがあります。
  • 毎日
    これらの要求は、サーバー文書の設定に従って1日1回処理されます。例としては、［すべての新規要求と編集された定期要求によるDominoディレクトリのユーザー文書の更新］、［未読リストのユーザー名の変更］、［古い変更要求の削除］などがあります。
  • 時間指定
    これらの要求は、推奨リソース・バランシング・プランで使用されます。このプロセスは、Tivoli Analyzer（US）によって生成されます。時間指定要求は通常、データベースの移動またはレプリカの作成のアクションに適用されます。時間指定の実行要求では、システム管理プロセス要求の実行時刻を指定することができます。時間指定要求には、［新規レプリカ作成のアクセス権チェック（時間指定実行）］、［レプリカ移動のアクセス権チェック（時間指定実行）］、［メールサーバーへのアクセス権チェック（時間指定実行）］、［クラスタなしレプリカ移動のアクセス権チェック（時間指定実行）］があります。
  • 遅延
    遅延要求は、サーバー文書に設定されたタイミングで実行されます。［読者／作成者フィールドの変更］は遅延要求です。
 
上に戻る
 
システム管理要求データベース
「すべての道はローマに通ず」といいますが、ここではさしずめ「すべてのシステム管理プロセス・アクションはシステム管理要求データベースに帰する」といえます。このデータベースには、1つのドメインに関するすべての要求が格納されます（ドメイン間の機能については、次回取り上げます）。（アクションによって）システム管理要求データベースに置かれた要求はすべて、ドメイン内のすべてのサーバーに複製されます。



ドメイン内の各システム管理要求データベースは同じレプリカIDを持ち、ドメイン内のサーバーのうち、AdminPを実行する他のすべてのサーバーに複製しなければなりません。それによって、あるサーバーが要求をポストし、他のサーバーがそれに応答することが可能になります。ドメインに追加のサーバーをセットアップする際、システム管理要求データベースは登録サーバーから新規サーバーにコピーされます。

例として、ユーザーを再認証したいとします。Dominoディレクトリのユーザー再認証コマンド（アクション10）は、ドメイン内の任意のサーバーに対して発行することができます。このコマンドは、プライマリー・システム管理サーバー（先の図のServer A）に複製され、そこで実行されます。ユーザーの再認証を要求すると、Administratorクライアントでプロセスが開始され、システム管理要求データベースにアクションが作成されます。
要求がデータベースに置かれると、プライマリー・システム管理サーバー上のAdminPによってコマンドが処理されます。このコマンドは、以下の操作を実行します。
  • このユーザーのDomino Directoryのユーザー文書を更新する。ユーザーのパブリック・キーは、システム管理要求文書の値に置き換えられます。
  • ステータス情報を含むAdminLog返答文書を作成する。
ユーザー認証の際、IDは新しいパブリック・キーによって更新され、場合によっては新しい有効期限が設定されます。

システム管理要求データベースには、数多くのビューが用意されています。各ビューでは、報告情報を表示したり、特定のアクションの承認を行ったりすることができます（多くのアクションは管理者による承認を必要とします）。下図に、Domino 6のシステム管理要求データベースの基本ビューを示します。



以下のセクションでは、上記のビューについて説明します。

要求された管理プロセス
エラーが検出された場合、ErrorFlagは「2」となります。エラーの一例として、AdminPが［読者］フィールドの更新を試み、失敗した場合が挙げられます。この場合、エラー文書が作成され、このビューに表示されます。AdminPによって、更新できなかった各文書への文書リンクが作成されます。

管理者承認保留中／承認要求
このビューは、次のいずれかの要求を発行する文書のうち、［ApprovalFlag］フィールドがないものを表示します。
  • ［Dominoディレクトリ内でのユーザー削除の承認］、［Dominoディレクトリ内でのサーバー削除の承認］、［Dominoディレクトリ内でのユーザー名変更の承認］、［Dominoディレクトリ内でのサーバー名変更の承認］などのドメイン間要求
  • 移動したレプリカの削除の承認
  • 拒否された名前変更の承認
  • ホステッドオーガニゼーションの削除の承認
管理者承認保留中／期間別保留、管理者承認保留中／サーバー別保留
このビューは、次のいずれかの要求を発行する文書のうち、［ApprovalFlag］フィールドがないものを表示します（期間またはサーバー名でソートされます）。
  • ［Dominoディレクトリ内でのユーザー削除の承認］、［Dominoディレクトリ内でのサーバー削除の承認］、［Dominoディレクトリ内でのユーザー名変更の承認］、［Dominoディレクトリ内でのサーバー名変更の承認］などのドメイン間要求
  • リソース削除の承認
  • プライベート設計要素削除の承認
  • レプリカ削除の承認
  • ユーザー名復元の承認
  • 認証要求の承認
  • ユーザー名変更要求の承認
  • 新しいパブリックキー要求の承認
サーバー別動作
このビューは、［システム管理要求ログ］文書をもとに、ユーザー、グループ、またはサーバーに対して実行されたシステム管理要求の種類を表示します。

エラー／日付別エラー、エラー／サーバー別エラー
［日付別エラー］ビューは、［システム管理要求ログ］文書をもとに、システム管理要求の処理中に発生したすべてのエラーを日付別に表示します。［サーバー別エラー］ビューは、［システム管理要求ログ］文書をもとに、システム管理要求の処理中に発生したすべてのエラーをサーバー別に表示します。

要求／アクション別要求、要求／動作場所別要求、要求／サーバー別要求
［アクション別要求］ビューは、［システム管理要求ログ］文書をもとに、個々のシステム管理要求とそれに対する動作処理記録を種類別に表示します。［動作場所別要求］ビューは、システム管理要求データベースの中で最も役に立つビューの1つです。このビューは、動作対象のユーザー名またはサーバー名を表示します。［サーバー別要求］ビューは、システム管理要求データベースのデフォルト・ビューです。このビューは、［システム管理要求ログ］文書をもとに、個々のシステム管理要求とそれに対する動作処理記録をサーバー別に表示します。

要求／発行者別要求
このビューは、システム管理プロセス要求の発行者を表示します。このビューを展開すると、処理対象のユーザーも表示されます。

要求／発行時間別要求
このビューは、アクションがシステム管理要求データベースに最初に入力された時間でソートして、各エントリーと返答文書を表示します。

要求／ユーザーの移動
「ユーザーの移動」ビューは、名前の階層的構造内でユーザーの移動を要求する文書を表示します。このビューで文書を選択し、［アクション］ - ［選択エントリによる階層名変更］を選択すると、AdminPによって処理され、各ユーザーごとにアクション8（Dominoディレクトリの変更）が作成されます。

ドメイン間／設定
このビューは、ドメイン間のシステム管理機能の動作を制御する設定文書を表示します。

ドメイン間／送信エラー
ドメイン間のシステム管理機能は、Notesメーラー（ルーター）を使用してドメイン間でシステム管理メッセージを送信します。このビューは、あるドメインから他のドメインへの送信と更新の試みが失敗したことを示すNDR（不達レポート）を表示します。

認証機関の要求／認証要求
このビューは、インターネット認証またはNotes認証の作成要求を表示します。このビューは、認証機関（CA）または登録機関（RA）が割り当てたユーザーによってモニターされます。

認証機関の要求／復旧情報の更新
このビューが使用されるのはCAプロセスのみです。このビューは、認証機関データベースに格納されているすべてのNotes IDのIDおよびパスワードの復旧情報がAdminPによってどのように更新されたかを表示します。
 
上に戻る
 
まとめ
本稿では、AdminPについて紹介しました。AdminPのコンポーネントをざっと眺め、アクションとシステム管理要求データベースの仕組みについて説明しました。この連載のPart 2では、AdminPについてさらに深く掘り下げ、ドメイン間のシステム管理要求、ならびにサーバー文書の設定、サーバー・コンソール・コマンド、Notes.iniファイル、データベースのパージ間隔によるAdminP機能の制御方法について解説します。



著者について
ティモシー・スピードは、IBM Software Services for Lotus（ISSL）のインフラストラクチャーおよびセキュリティー・アーキテクトです。彼は1992年以降ずっと、インターネットとメッセージングのセキュリティーに携わっています。また、長野オリンピック大会のDominoインフラストラクチャーに関与したり、シドニー・オリンピック大会のLotus Notesシステムを支援した経験もあります。認定資格として、MCSEc、VCA（VeriSign Certified Administrator）、Lotus Domino CLP Principal SA、Lotus Domino CLP Principal ADなどを持っています。また、共著者として、『The Internet Security Guidebook』（ISBN：0122374711、2001年2月）、『The Personal Internet Security Guidebook』（ISBN：0126565619、2001年10月）、『Enterprise Directory and Security Implementation Guide: Designing and Implementing Directories in Your Organization』（ISBN：0121604527）、『Internet Security: A Jumpstart for Systems Administrators and IT Managers』（ISBN：1555582982）の4冊の著作があります。連絡先は、Tim_Speed@us.ibm.comです。

ポール・レイモンドは、Product Introduction組織のデベロップメント・リレーションズ・マネージャーです。彼は、Notes/Domino 6.0のデザイン・パートナー・ベータ・プログラムの早期展開に関与し、Notes/Domino 6.5ベータ・プログラムにおいても引き続きリーダーを担当しています。彼は、1992年にLotusに入社し、新たに組織されたデベロップメント・リレーションズ・チームに参加する前は、デスクトップ・サポートやフィールド・サポート・サービスなどのさまざまな部門に携わってきました。　
 
上に戻る