LDD Today: Domino 6でポリシー・ベースのシステム管理を行う

ページオプション JavaScript を要するドキュメントオプションは表示されません 原文はこちら

レベル: 中級

Bob Balfe, Senior Software Engineer, Lotus
Dick McCarrick, Content Developer, IBM

2002年 07月 01日

Domino 6でポリシー・ベースのシステム管理を行う

過去のDomino/Notesリリースでは、全ユーザーの標準環境を作成、管理するには、コーポレート・ポリシーを文書化しておく必要がありました（例：最短のパスワード長や証明書の失効日など、すべてのNotesユーザーに遵守してもらう具体的なセキュリティー設定）。その後、サイト全体を通じてこれらポリシーに従いながらユーザーの設定を入力していきました。 各設定の仕方を100%熟知してなければ、遅かれ早かれ小さいながらも重大なデータ入力ミスをおかし、それを修正するために数時間、場合によっては数日を要することになります。管理者がインターネット・アドレスのフォーマットを誤ったまま1,000人のユーザーを登録したのであれば、誤った情報を含んでいる各個人文書を編集するのに何時間もかかってしまいます。 LotusScriptに詳しいとか、誰か詳しい人を知っているならエージェントを作り、このポリシー情報の少なくとも一部を全社的に配信することも可能でしょう。しかし、Dominoにはこうした標準を正確かつ簡単に、自動的に施行する機能があらかじめ用意されているのです。

Domino 6は、「ポリシー・ベースのシステム管理」という新技術を採用することで、標準のコーポレート・ポリシーを適用、管理する問題を解決してくれます。この機能を使えば、組織全体にわたり、ユーザー設定を一元的に定義、編成、管理することができます。 ポリシー・ベースのシステム管理に必要な全情報は皆さんのDomino Directoryに格納されており、ユーザー設定からメールのアーカイブにいたるまで、管理作業を一ヶ所で行えます。

本稿では、ポリシー・ベースのシステム管理について紹介します。主な機能やコンポーネント、仕組み、このシステム管理で何ができるかなど、詳しく説明していきます。また、ポリシー・ベースのシステム管理によりDomino管理者の仕事がいかに楽になるかについても、具体例を挙げます。
ポリシー・ベースのシステム管理と、Domino 6のその他の管理機能については、詳しくはドキュメンテーション・ライブラリー（US）を参照してください。

ポリシー・ベースのシステム管理とは？

ポリシー・ベースのシステム管理とは、その名のとおり、Domino管理者である皆さんが従業員にコーポレート・ポリシーを適用、管理するための1つの方法です。Dominoがユーザー設定にどういう制約を設け、それにより全社的な標準とビジネス・プラクティスが社内テクノロジーをどうコントロールするかは、これらコーポレート・ポリシーで決まります。

Domino 6では、Domino Directory内の個々のポリシー文書と設定文書を通してコーポレート・ポリシーを施行することになります。ポリシーを作成するには、ポリシー文書を使い、どの設定文書を含めるか指定します。

ポリシー文書（下の画面はそのサンプル）は、ユーザーに適用する企業情報を定義します。これは、どの設定文書をポリシーに含めるかを指定することで定義されます。各設定文書には、アーカイブやセキュリティーなど、Domino管理の特定分野に該当する詳細情報が収められています。この情報は、その分野に対するユーザー設定を定義することになります。

ポリシー・ベースのシステム管理は、ユーザー・コミュニティー内にルールを作成、適用するための手段と考えればいいでしょう。ルールを格納するのが設定文書、そしてこれらルールを系統化するのがポリシー文書というわけです。ですから、ポリシー文書を作成するときは、これらルールを一ヶ所にリストしておけます。その後、組織全体にルールを配信することでそれらを適用し、管理基準を確立、施行できるようになります。既存のポリシーを変更するには、ポリシー文書、または1個以上の設定文書、もしくはその両方を変更するだけですみます。1人ひとりのユーザーのコンピューターまで出向いて何度も同じ変更を加えなくても、すべて一元的に行えるのです。

ポリシー・ベースのシステム管理を使えば、Domino管理の5大分野、アーカイブ、デスクトップ、セットアップ、登録、セキュリティーを管理できます。

ポリシー文書の作成
ポリシー文書を作成するには、少なくともDomino Directoryへの管理者権限を持っていること、Policy Creatorの役割を割り当てられていることが条件です。この条件を満たしていれば、Domino Administratorから以下のことを行えます。

1. ユーザーとグループタブをクリックし、Policiesビューを開く。
2. Add Policyをクリックする。
3. Basicsセクションにポリシー名を入力する。明示的ポリシーを作成する場合、他にない名前を入力する。組織ポリシーを作成する場合は以下のいずれかのフォーマットで入力する。

   •	組織：*/＜組織＞
   •	組織の部門：*/＜組織の部門＞/＜組織＞
   •	ホスティングされている組織：*/＜ホスティングされている組織＞
   •	ホスティングされている組織について、Domino Directory内のすべてのホスティングされている組織を表す場合：*

4. ポリシー・タイプとしてExplicitもしくはOrganizationalを選ぶ。特定のユーザーやグループに割り当てるポリシーを作成するときはExplicitを選ぶ。組織もしくは組織の部門（OU：Organizational Unit）内の全ユーザーに割り当てるポリシーを作成するには、Organizationalを選ぶ（詳しくは「組織と明示的ポリシー」のセクションを参照）。
5. そのポリシーの簡単な説明を入力する（オプション）。
6. ここで子ポリシー文書を作成するには、Create Childをクリックする。これにより親ポリシーの名前を含む新規のポリシー文書が作られる。この新しい子ポリシー文書を保存すれば、あとで戻って作業することもできる。文書を閉じたら、親ポリシー文書に戻る。
7. Settings Typeセクションで、このポリシーに適用する設定文書（登録、セットアップ、アーカイブ、デスクトップ、セキュリティー）を選択する。これはすでに作成済の設定文書でもいいし、Newをクリックして設定文書・フォームに記入することでその場で新規の設定文書を作成しても良い。
8. 新規のポリシー文書を保存して閉じる。

設定文書の作成
設定文書を作成するには、少なくともDomino DirectoryへのEditorアクセスを持ち、Policy Creatorの役割を割り当てられていることが条件です。設定文書はポリシー文書を作成するときに作ることも、またDomino Administratorを開いて以下のステップに従うことでも作成できます。

1. ユーザーとグループタブを選択し、Settingsビューを開く。
2. 新規をクリックする。
3. 作成する設定文書のタイプを選択する（登録、セットアップ、アーカイブ、デスクトップ、セキュリティー）。
4. 該当する欄に記入し、文書を保存して閉じる。

上に戻る

組織と明示的ポリシー

社内の人々にポリシーを割り当てるには、組織ポリシーと明示的ポリシーの2通りの方法があります。

組織ポリシーは、組織の構造に基づいてユーザーもしくはグループに設定を割り当てます。組織ポリシーは名前階層（*/Acme、*/Sales/Acmeなど）にいる全ユーザーに影響を与え、組織もしくは組織の部門（OU）に適用することができます。組織ポリシーは、設定が組織のラインに従っている場合、それら設定を最も幅広いユーザー・グループに流します。例えば、Sales/Acme内の全ユーザーに設定を適用するには、*/Sales/Acmeという組織ポリシーを作成することになります。Sales/Acme認証者を使って登録されたユーザーは、自動的にこの組織ポリシー内の設定を受け取ります。組織ポリシーはワイルドカードと考えることができ、一般に特定の組織もしくは組織部門内の全ユーザーに設定を配信、管理するための最も効率的な方法です。

明示的ポリシーは、異なる組織の人々とグループに設定を割り当てます。明示的ポリシーはユーザー文書に割り当てられ、ユーザー・グループを定義するための組織もOUも存在しないとき、そのグループに適用されます。明示的ポリシーは組織階層のない環境や、複数の組織にまたがるグループに共通の設定を割り当てたいときに適しています。例えば、社内のたくさんのOUでアルバイトや派遣社員などの臨時雇用者が働いている場合、それら臨時雇用者に*/Sales/Acmeのように、該当する組織ポリシーから一部の設定を継承させれば便利です。しかし、特定の設定を臨時雇用者だけに適用したいこともあるでしょう。例えば、証明書を6ヵ月後に失効するよう設定することもできます。これを行うには、/Contractorsという、彼らだけに適用される明示的ポリシーを作成すれば良いことになります（明示的ポリシーはポリシーの割り当てツールを使って割り当てられます）。

どのタイプのポリシーを使うか決めるときは、以下の点を考慮してください。

• 既存の名前階層に従ってグループに設定を適用するには、組織ポリシーを使います。
• 設定を適用するグループが組織もしくはOUの構造に一致しないときは明示的ポリシーを使います。
• 社内では両方のタイプのポリシーを自由に使ってください。現実にはそうするのが普通かと思われます。

組織ポリシーは、一度作成すれば認証子に基づいてユーザーに自動的に割り当てられます。一方、明示的ポリシーは手作業で割り当てなくてはなりません。明示的ポリシーはユーザー登録中、ユーザー文書内、もしくはポリシーの割り当てツールを使うことで割り当てられます。組織ポリシーはユーザー登録の前に作成することをお勧めします。また、明示的ポリシーはユーザー登録中に割り当てるのが最善です。ユーザーを登録する前にポリシーを作成しないと、登録ポリシーの設定を割り当てることができません。登録時にポリシーを割り当てれば、登録済のユーザーがNotesクライアントのセットアップを行うとき、セットアップ・ポリシーの設定を使えるというメリットもあります。

組織ポリシーと明示的ポリシーは階層構造ですので、継承と施行は自動的に親子関係に収まります。このモデルでは、組織部門により継承された全社的標準を定義しながら、場合により例外を設けることも可能になります。例えば、アーカイブ・ポリシーを作り、エンドユーザーのメール・ファイルをどこにどうやって保管（アーカイブ）するか、ユーザー自身がまったくコントロールできない、一部コントロールできる、もしくは完全にコントロールできるよう設定しておけるのです。

上に戻る

ポリシーの構成要素は？

NotesやDominoの管理についてある程度知っている方なら、ポリシーの管理も比較的楽に行えるはずです。すべてのポリシー情報はサーバーの公開されているDomino Directoryに格納されます。こう聞くと、「ポリシーが公開されているDomino Directoryにあるなら、ユーザーが接続してないときどうやって施行するのか？」と疑問に思うかもしれません。その答えは、ユーザーが自宅のメール・サーバーで認証されると、ダイナミック・コンフィギュレーションというプロセスがローカルに実行され、そのユーザーに対するあらゆるポリシー情報をキャッシングするのです。こうすることで、ユーザーが回線を切ってもすべてのポリシーはそのまま施行されます。裏を返せば、長時間接続してないユーザーは再度接続してホーム・サーバーで認証されるまで、ポリシーの変更を受け取らないことにもなります。

前述したとおり、ポリシーは一連の設定文書からなり、これら文書は所定の設定で埋められたフィールド・セットを含む1つのハイレベルなポリシー文書内にまとめられています。では、単純な図を通して見ていきましょう。

この図では、トップレベルのポリシー文書は組織に施行したいポリシーを表しています。その下位にある設定文書（アーカイブ、登録、デスクトップ、セットアップ）には、このポリシーに適用する設定情報が収められています。これら設定文書は、過去のリリースでDominoおよびNotesユーザー・インタフェース内のたくさんの異なる場所に入力しなければならなかった、情報のバケツと考えればいいでしょう。ポリシー文書は所定のユーザーやグループに適用する必要のある設定を取り出すため、これらバケツの中を覗くというわけです。

ポリシー文書と設定文書の関係を知ることは、ポリシー・ベースの管理における2つの重要な特長、ポリシー階層と有効ポリシーを理解するうえで不可欠です。

上に戻る

ポリシー階層

ここではしばらくDomino 6とポリシー・ベースのシステム管理については忘れ、代表的な大企業を考えてみます。この会社は全従業員に適用するルールと、一部の部門だけに適用するルールを持っています。これら部門内のいくつかのワークグループは独自のルールを持ち、数人のメンバーはルールを免除されています。さらに、請負業者やマネジャーなど、特定の従業員のためのルールもあります。一見複雑そうに見えますが、ポリシー・ベースのシステム管理ならポリシー階層を通してすっきりさせられます。

親ポリシーと子ポリシー
ポリシー階層は、ポリシー間に親子関係を確立することで構築します。ポリシー文書を作成するときは、1個以上の子文書も作成しておけます。元のポリシーはその子ポリシーの親とみなされます。親子関係を通して、全社的に適用するポリシーの階層を作ることになります。このような階層では、ポリシー文書は関係を構築し、設定文書は階層内のポジションに基づいてフィールドの値を決めます。フィールド・レベルで継承や施行を使うことで、各組織部門の要件に合うよう設定を微調整しながら、全社に施行しなければならない特定の標準をコントロールし続けることができます。

例えば、すべてのユーザーに同じインターネット・メール名のフォーマットを使わせたければ、トップレベルの親ポリシーに対して登録設定文書にその値を設定すればいいのです。これを行えば、あとで子ポリシーに変更を加えたり入力しなおしたりする必要はありません。その代わり、子ポリシーに親ポリシーからこの値を継承するよう指示するだけです。ただし、組織内にこの設定が問題となる海外ユーザーのグループも含まれている場合、このグループだけに適用する明示的ポリシーを作成できます。明示的ポリシーと組織ポリシーを併用することで、柔軟にシステムを管理できるはずです。

継承／施行されたポリシー設定
階層型ポリシー構造の大きな特長は、設定を継承、施行できることです。継承した設定は別の設定文書から導出されます。施行した設定は親設定文書に設定されており、すべての子文書により自動的に継承されます。この設定を子文書で上書きすることはできません。これにより、一ヶ所に設定を入力して企業構造全体に流しながら、それまでどおり各組織部門内に他の設定値を設定することも可能になります。ここで、例外ポリシーが施行した設定をオーバライドすることに注意してください。例外ポリシーをあまり使わないようにするのは、こういう理由もあるのです。

ポリシーはすべての設定をフィールド・レベルで継承、施行します。継承もしくは施行できる各フィールドには2個のチェックボックスがあります。下の画面は、Archive 設定文書の各フィールドがどのようにしてその親から値を継承したり、すべての子に設定を施行したりするかを示しています。

有効ポリシー
階層型ポリシー構造では、特定のグループまたはユーザーに適用する設定は1個のポリシー文書から取られるとは限りません。この場合、ポリシー情報は継承および施行した設定（例外ポリシーを使っている場合はこのポリシー）をもとに、複数のドキュメントから導出されます。こうして導出した情報がユーザーの有効ポリシーとなるのです。有効ポリシーは実行時に動的に計算したポリシー設定から成り立っています。有効ポリシーにおけるフィールド値は多くの異なる設定文書をもとにしています。各階層レベルはそれに関連するポリシーを持つことができますので、ユーザーはOUレベルで設定されている値を含むポリシー設定と、親ポリシーから継承された設定を両方持っていることもあります。組織階層を段階的に上がりながらこれら設定を解決することで、各ユーザーに対する有効ポリシーを作成するのです。

結局、どの設定が適用されるかは、ユーザーの有効ポリシーで決まります。したがって、有効ポリシーはポリシー文書と違って実際に存在するものではありませんが、ポリシー・ベースの管理の仕組みを完全に理解するうえで非常に重要なコンセプトなのです。

有効ポリシーの設定は実行時に導出されますので、ポリシーの設定値を変更したらどういう影響が及ぶか、常に明確なわけではありません。各有効設定値の導出元となるポリシーは、ポリシーの一覧レポートに示されています。このレポートを見れば、個々のポリシーの設定値、設定文書、有効ポリシー、およびそれぞれの関係とお互いにどう影響を与えるかが理解できるはずです。

上に戻る

ポリシー・ベースのシステム管理に使うツール

新しいテクノロジーが生まれると、利便性が高まる反面、そのぶん複雑さも増してしまうものです。ポリシーは極めて柔軟な性質を持ってはいますが、初めて利用する方にとってはやはり未知の領域です。現実には、グローバルな大企業の組織構造（国内、海外、ローカル、リモート、IT、人事等）を考えると、しっかり定義されたポリシー構造の作成、管理はかなり複雑な作業となってしまいます。この作業をできるだけ分かりやすくするため、Domino 6はポリシーの割り当て、View Policy、ポリシーの一覧という3種類の便利なツールを用意することで、ポリシー・ベースのシステム管理を効果的に行えるようにしています。

例えば、貴社のDomino DirectoryにExecutivesというグループがあるとします。このグループには、社内の異なる組織および組織ユニットの管理職と取締役が含まれていると考えてください。コーポレート・ポリシーでは、すべての経営幹部は厳しいメール・アーカイブ・ポリシーに従わなくてはならないことになっています。Executivesグループ内には、例えば以下の人たちがいます。    Sandy Beech/Sales/Acme
   Lee Smith/Acme
   Fran Jones/Development/Acme
この例では、各人はメールのアーカイブにそれぞれ異なる組織ポリシーを持っています。

このため、/Executivesという新しい明示的ポリシーを作成、これを例外ポリシーとします。さらにAssign Policyツールを使い、Executivesグループ内の各メンバーにこのポリシーを割り当てます。

1. Domino Administratorからユーザーとグループタブをクリックする。
2. ユーザー・ビューを開き、ポリシーを割り当てるユーザーを選択するか、グループ・ビューを開き、ポリシーを割り当てるグループを選択する。
3. ツール・ペーンから、ステップ2での選択に応じてユーザーもしくはグループを選び、「ポリシーの割り当て」を選択する。
4. ポリシー・オプションの割り当てダイアログ・ボックスに記入する。
   Assign Policy Options dialog box
   
   
   
5. このポリシーを割り当てているグループもしくはユーザーの新しい有効ポリシーを確認したい場合は、ポリシーオプションの参照ボタンをクリックする。
6. 組織ポリシーの選択ダイアログ・ボックスで、新規の有効ポリシーを作成するため明示的ポリシーと組み合わせる組織ポリシーを選択する。

ポリシーの割り当てツールがDomino Directory内の各ユーザー文書の明示的ポリシー・フィールドに情報を流し込むと、上記ユーザーに対する継承ツリーは下記のようになります。

View Policy
View Policyツールを使えば、ポリシーの階層や、ポリシーとポリシー設定文書の関係を表示することができます。選択したユーザーもしくはグループの有効ポリシーを見ることも可能です。

View Policyツールには、Domino Administratorの設定タブからアクセスする、2個のビューがあります。By Hierarchyビューはポリシーの階層と、その階層内の各ポリシーに関連する設定値を表示します。すべてのポリシーを見る、特定のポリシーの詳細を見る、あるいは特定のユーザーもしくはグループに割り当てられているポリシーを見るには、このビューを使います。以下に、By Hierarchyビューの例を示します。

By Settingsビューには、各管理分野に対するポリシー設定文書と、各設定文書を使うポリシー文書が表示されます。このビューは、各設定値がどこで使われているかや、設定値の変更が他のポリシーにどんな影響を与えるかを知りたいときに使います。以下はBy Settingsビューの例です。

ポリシー一覧
これまで、継承設定と施行設定を伴う有効ポリシーについて説明してきました。ここで、「ユーザーやグループが適切な設定値を受け取れるよう、設定情報がどこからくるのか追跡するにはどうすればいいのか？」という疑問を抱くかもしれません。この点については心配いりません。Domino 6にはポリシーの一覧というツールがあり、どの設定フィールドが階層内のどのレベルかくるか、すぐわかるようになっているからです。

ポリシーの一覧ツールは選択した個人を統括する有効ポリシーを決定し、そのユーザーに適用するポリシーと設定値をリストしたレポートを作成します。レポートはポリシー一覧 データベース（polcysyn.nsf）というデータベースに格納されます。2種類のレポート、要約のみと詳細を作成できます。要約レポートはポリシー階層を表示し、指定したユーザーに対する有効ポリシーの設定を導出するために使う組織および明示的ポリシー文書をリストします。また、詳細レポートは要約の情報に加え、有効ポリシーにおける実際の設定値も表示します。

ポリシーの一覧ツールを使うには、以下のステップに従います。

1. Domino Administratorからユーザーとグループタブをクリックする。
2. Peopleビューを選択する。
3. Toolsペーンからポリシーの一覧を選択する。
4. ポリシーの一覧ダイアログボックスに記入する。
5. 結果データベースをクリックし、ポリシー一覧 Resultsデータベースのサーバー・ロケーションとファイル名を定義する。
6. OKをクリックする。Resultsデータベースが開いたら、そのレポートをダブルクリックして読む。

以下は、あるユーザーに対するポリシーの一覧の例です。

   Policy Synopsis - Generated at 11:17:33 AM on 01/19/2002
   Effective Policy for: Sandy Beech/Sales/Acme
   Derived from the following policies:
   *
   */Acme
   */Sales
   Archive Settings:

   NoArc = 0 from Company Wide assigned in policy *
   NoPrivArc = 0 from Company Wide assigned in policy *
   ArcLoc = 2 from Acme Org assigned in policy */Acme
   ArcSrcChcs = 2 from Acme Org assigned in policy */Acme
   ArcLocChcs = 2 from Acme Org assigned in policy */Acme
   ArchSrcServer does not have a value set
   ServerName = bbalfe4/DNA from Sales Archive Settings assigned in policy */Sales/Acme

上位階層内の異なるポリシーから継承したさまざまな値の影響を示すため、このシノプシスは明示的ポリシーを割り当てる前に作成しました。

上に戻る

ポリシーの使用例

以下に、過去のリリースでは難しかった、もしくは反復作業のため退屈だったポリシー・ベースのシステム管理タスクの単純な例をいくつか紹介します。これらの例はポリシー・ベースのシステム管理で行えることを全部網羅しているわけではなく、あくまでDomino 6の改善点を一部紹介するにすぎません。

コーポレート・ポリシーの作成
自分はAcme CorporationのDomino管理者だと想像してください。ポリシー・ベースのシステム管理では、各ユーザーに正確なオプションや適切なプリファレンスを選択させなくても、全従業員を正しくセットアップできるため、これまでの頭痛の種はかなり解消されます。ですから、まず最初にすることは、*/Acmeという組織的ポリシー文書を作成することです。この組織的ポリシーは、別途指定のない限り、社内の全ユーザーに適用されます。*/Acme ポリシー文書は登録、セットアップ、アーカイブ、ユーザー・デスクトップ、セキュリティーをコントロールする設定文書のコンテナとしての役割を果たします。

登録設定
Acme Corporationはたくさんのコーポレート・ポリシーを持っています。顧客が従業員に簡単にeメールを送信できるよう、すべてのユーザーのインターネット・メール・アドレスのフォーマットを同じにする必要があります。従業員はデフォルトのメール・システムとしてLotus Notesを使う予定です。また、全社的に標準のパスワード・クオリティーと証明書失効日を施行したいと考えてもいます。そのためには、登録設定文書（ここではAcme_Default_Registrationと呼ぶことにする）を作成し、この文書に情報を入れます。使用するメール・テンプレートを選択し、証明書が24ヶ月後に失効するよう指定します。これで、*/Acmeに対する登録設定文書としてAcme_Default_Registrationを選べるようになります。つまり、デフォルトの場場、Acme_Default_Registration内の情報が登録時にAcmeの全従業員に適用されるということです。

しかし、ほとんどの企業と同様、Acmeでもすべてのルールに例外があります。例えば、さまざまな国籍からなる営業部門は独自のメール・テンプレートを必要とします。また、営業担当者はローミング・ユーザーであり、別のインターネット・メール・アドレス・フォーマットを必要とします。そんなときも、Domino 6なら問題ありません。*/Sales/AcmeというSales OU用の組織的ポリシーを作成すればいいだけです。その後、例えばSales_Registrationという登録設定文書を作成し、Salesグループに適切な登録情報を入力するのです。これで、Sales/Acme承認者を持つユーザーを登録するときは、必ずこれらの設定値が適用されます。

ここまでは簡単ですが、もう少しひねりを加えてみましょう。Acmeのコーポレート・ポリシーは、あらゆる臨時雇用者に対する証明書を24ヶ月でなく6ヵ月後に失効することを義務付けています。しかし、これら臨時雇用者はOU全体に分散されています。すべての臨時雇用者を網羅する組織ポリシーを作成することはできません。その代わり、/Contractorsという明示的ポリシーを作成するのです。

次に、例えばContractor_Settingsという/Contractorsポリシーに対して、新規の登録設定文書を作成します。6ヶ月の証明書失効期限と、請負業者に適用するその他の情報を入力します。

登録時にこれら設定値を請負業者に適用させるには、その業者のユーザー文書を開き、Assigned ポリシー・フィールドに/Contractorsと入力します。

セットアップとデスクトップの設定
これで登録設定は整いましたので、今度は全ユーザーに標準のデスクトップを施行するといったユーザー・セットアップに移ります。例えば、ユーザーとロケーションのプリファレンスを制御する必要があります。従来、この作業は各ユーザーの手に任されていたため、ときとして予想外の結果を招くことがありました。また、各ユーザーに同じWelcomeページを表示させるとともに、最初のデータベースとブックマークも同じ設定にしておかなければなりません。おそらく一番重要なのは、セキュリティーのため各ユーザーの初期ECL設定値を同じに割り当てることでしょう。

以上で、ポリシーを使えば過去のリリースと比べていかに簡単にすむかご理解いただけたことと思います。もうユーザーがすべてのプリファレンスを正しく選択したか不安を感じることはなくなります。何日もかけて一人ひとりのユーザーの場所まで足を運び、すべて正しくセットアップされていることを確認しなくてすむのです。これからは*/Acmeポリシーに対してセットアップおよびデスクトップの設定文書を作成し、この情報を入れるだけでOKです。入力した設定値は社内の全ユーザーに適用されます。また、前述したとおり、組織ポリシーや明示的ポリシーの文書を使ってこれらルールに例外を設けることも可能です。

メール・ファイル・アーカイブの一元管理
メール・アーカイブは、ポリシー・ベースのシステム管理を開発する発端となった問題です。皆さんはAcmeの管理者として、今までメール・ファイル・アーカイブの問題と格闘してきました。

• メール・サーバーの容量不足
• 中央アーカイブ・サーバーの必要性
• アーカイブを就業時間外に実行しなければならない。
• ユーザーが独自のアーカイブ設定にできない。
• Notes環境に異なるリリースのクライアントが混在している。

これらの問題は、*Acmeポリシーに対してArchive 設定文書を作成することで簡単に解決します。これにより以下のことが可能となります。

• アーカイブ設定を一元的に管理し、ユーザーが自分の設定を変えるのを禁じる。
• メール・サーバーから指定のアーカイブ・サーバーにサーバー・ベースでアーカイブできるようにする。
• 混在する環境でポリシーを施行するため、Domino 6をアーカイブ・サーバーとして指定する。
• 全員の就業時間外にアーカイブを実行するようスケジュールする。

上の例はあえてシンプルにしてあります。例えば、親子ポリシー、例外ポリシー、継承／施行については触れていません。とはいえ、たとえ特定のグループが社内ルールに対する例外を必要とする場合でさえ、ポリシーを使えばユーザーのセットアップをいかに簡単に行えるかは理解できたことと思います。

上に戻る

ポリシー・ベースのシステム管理：管理者の仕事を楽に

ポリシー・ベースのシステム管理は、全社的なポリシーを一元的に短時間で効率良く設定、施行することで、総所有コスト（TCO）を削減することを目的としています。これにより貴社の環境をよりしっかりコントロールできるだけでなく、ユーザーをフィールド・レベルまで柔軟に管理できるようにもなります。将来のリリースでは、Domino管理の他の分野にもポリシー・ベースのシステム管理を拡張していくため、今後もさまざまな方法を模索していくつもりです。

参考文献

• developerWorks Japan: Lotus: Lotusの日本の技術情報サイトです
  
  
• developerWorks: Lotus(US) : Lotusの英語の技術情報サイトです

著者について

		Bob BalfeはIBMの上級ソフトウェア・エンジニアであり、DNA（Domino and Notes Automation）という社内向け自動テスト・ツールのプロジェクト・リーダーでもあります。彼はポリシー・ベースのシステム管理エンジンの自動化を担当する開発主任を務めていました。このテストは数多くの順列を網羅し、数百人時の節約を達成しました。

		Dick McCarrick is a content developer for developerWorks: Lotus. Previously he was a member of the Domino/Notes Documentation team for over 11 years, playing a variety of roles in documenting many major components of Domino and Notes. He also wrote the occasional article for Iris Today (including Ask Professor INI) before joining the Notes.net/Lotus Developer Domain team permanently in 2002. In his spare time, Dick's leisure activities include running, fishing, woodworking, and reading about the natural sciences. An avid astronomer, he's former director of the Bridgewater (Mass.) State College Observatory. Dick lives in Vermont.

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る