本文へジャンプ

ソフトウェア > Lotus > Lotus Developer Domain > 

Iris Today Archives

Web ユーザーを管理する


 Lotus Software
by Dwight Morse
レベル：中級者
対　象：Domino 5.0
原文の掲載：2001年2月1日

Iris Today Archivesの原文

インデックス
基本的なポイント
ブラウザーのユーザーを登録する
メールへのブラウザーからのアクセスについて理解する
データベースにブラウザーからアクセスできるようにする
個人ビューやフォルダーはどうするのか
カレンダー&スケジュール機能
代理人機能を使う
最後に…そして最も重要な点：セキュリティー
まとめ

ノーツなどの多くの機能を持った大掛かりなクライアントの代わりに、ブラウザーをクライアントとして使おう、という企業が増えてきています。ブラウザーはあまり容量を必要とせず、インストールするのも楽ですし、セットアップの際にも複雑な設定が不要なほか、エンド・ユーザーはすでにブラウザーのユーザー・インターフェースをある程度知っているので、トレーニングの費用も削減できます。機能面で不足しているのが欠点でしたが、iNotes Web Access や、ドミノ・オフライン・サービス (DOLS) といったテクノロジーのおかげで、改善されてきています。

では、ノーツ/ドミノの管理者だったとしたらどうでしょうか。大勢のユーザーがブラウザーをクライアントとして使うようになると、考慮しなければならない点がでてきます。

この記事では、従来の方法を使った、ドミノのサービスへのブラウザーを通してのアクセスや、ノーツ/ドミノで見られた新しいブラウザー対応の機能などを紹介していきます。登録、メール、セキュリティーに関するポイントを、ドミノ管理者の視点からお話していきます。

この記事は、ノーツ・クライアントやドミノ サーバーについての基本的な知識を持っている方を対象としています。具体的には、ノーツ・ユーザーを登録して、メールを設定したことがあり、ノーツ・セキュリティーについてもある程度理解している必要があります。


基本的なポイント
複雑な用語が多くでてくるので、まずはみなさんの多くが知っていると思われる、基本的な部分から説明していきましょう。これで、後から話が複雑になっても理解しやすいと思います。なお、基本をご存知の方は飛ばしていただいても構いません。

ブラウザーは、ドミノと通信する際に、いくつかのインターネット・プロトコルを使います。しかし、デフォルトではドミノはこれらの「言語」をすべて話すわけではありません。これらのプロトコルを使ってドミノが通信するためには、ドミノ サーバーがそのサービスを行う必要があります。この中でもっとも多く使われるのが、HTTP (Hypertext Transfer Protocol) で、リリース5では、ドミノの HTTP スタックか、マイクロソフトの IIS (Internet Information Server) スタックのどちらかを選択して使うことができます。そして、HTTP を、サーバーの NOTES.INI ファイルの ServerTasks= の行に追加することで、ドミノ サーバーが起動するたびに HTTP サービスを使うことができるようになります。例えば、次のようになります。

ServerTasks=Replica,Router,Update,,AMgr,Adminp,Sched,CalConn,Event,HTTP

HTTP サービスを追加することによって、ブラウザーでノーツ・データベースを開けるようになり、HTTP タスクはノーツ・ビューや文書を HTML (Hypertext Markup Language) に変換してブラウザーで表示できるようにします。しかし、すべてのフォームやビューが一様に HTML にうまく変換されるというわけではありません。アイリスでは、フォームの見た目と、機能性 (読み込みが早い点) で、バランスがもっとも良いのはどの点なのかを見極めるための取り組みを行ってきました。そして、得られた結果を、現在の Webmail テンプレートや、最新の iNotes Web Access クライアント (ブラウザーを通してメールにアクセスするのに適しています) に生かしています。
 
上に戻る
 
ブラウザーのユーザーを登録する
何も新しくインストールしなくてもブラウザーはドミノと組み合わせて使うことができますが、認証アクセスを行うには、アカウントを作成する必要があります。ここで「アカウントを作成する」というのは、おなじみの、ドミノ・ディレクトリーにユーザー文書を作成してそれぞれのユーザー用のメール・ファイルを作成する、ということです。

ドミノ管理クライアントについている登録ツールでは、ノーツ ID しか作成することができないと思われがちですが、そうではありません。このツールを使えばドミノのドメインで使われるすべてのユーザーを登録することができ、ブラウザー・ユーザーの登録も可能です。

ブラウザー・ユーザー用のユーザー文書をひとつずつ作成していくよりも、登録ツールを使ったほうがはるかに便利です。まず、登録ツールを使えば、ディレクトリーやテキスト・ファイルから、既に登録されているユーザーをインポートできます (NT、cc:Mail、Netscape など)。これで、何千ものユーザー文書を作成するためにアルバイトを雇わなくてもすみます。また、登録ツールは、ユーザーのメール・ファイルも作成してくれるほか、パスワードのクオリティーや、インターネット・アドレスのフォーマット、メール・テンプレート、メール・ファイルの割り当て、グループの登録といった多くのオプションを、複数のユーザーに対して同時に設定することができます。

ドミノ管理クライアントを使ってブラウザー・ユーザーを登録する際には、ID ファイルを作る必要はないので、ユーザーの ID を保管するかどうかを決めるチェック・ボックスをはずしてください。そして、メールのシステムが、IMAP なのか POP3 なのか、それともロータス ノーツなのか (Webmail や iNotes Web Access クライアントの場合) を指定します。管理クライアントから Web ユーザーを登録する際に知っておきたい点として、ロータス ノーツをメール・システムに指定した場合は、管理クライアントはノーツ ID を作成する、ということがあります。これを避けるには、ノーツ ID をとりあえず作成させておいて、後から削除するか、無視するしかありません。

ブラウザー・ユーザーの登録を管理クライアントの登録ツールを使って行うと、ユーザー用にインターネット・パスワードを作成することができ、ノーツ・クライアントで使われているパブリック・キーを使うモデルとは全く違った、チャレンジ/レスポンスのセキュリティー・モデルを採用することができます。ノーツ、ドミノのセキュリティー・モデルに近づけたければ、ただユーザーを登録するだけでなく、ドミノ サーバーに SSL をセットアップする必要があります。ノーツ・ユーザーを登録すると、パブリック・キーとプライベート・キーを作成することになるため、ここで SSL が必要になることを頭に入れておいてください。SSL については、後からもう一度セキュリティーのセクションで触れます。
上に戻る
 
メールへのブラウザーからのアクセスについて理解する
拡張メール・テンプレート (mail50ex.ntf) を使うと、ブラウザーを使ってノーツのようにメールにアクセスすることができます。メール・ファイルは、ノーツ・クライアントと同じようなユーザー・インターフェースをブラウザーで実現し、いつもと同じメール機能を提供する NSF です。ブラウザー・ユーザーは NSF を通してメールを送受信でき、管理者にとっても、ノーツ・クライアントの時と同じツールを使ってメールの管理、モニタリング、トラッキングができることになります。しかし、相違点もいくつかあります。

例えば、メールのサイズ割り当てはノーツ・クライアントと同じように設定できますが、サーバー上のサイズ割り当ては管理することしかできません。また、ユーザーは、ドミノ・オフライン・サービスを使ってメール NSF を ローカルに落して、オフラインの状態でブラウザーからアクセスする場合のみ、ローカルにメール・ファイルを持つことになります。ノーツ・クライアントと違って、ブラウザーにはメール・ファイルのローカル版レプリカを縮小する機能がないので、レプリカされるファイルのサイズを限定したり、古いメッセージを削除して NSF 内に新しいメールが入るだけのスペースを空ける、といった方法でしかディスク・スペースの管理を行なうことができません。サーバーのレプリカに関しては、圧縮を実行して、スペースを確保することができます。

また、メールがブラウザーから送信される方法もノーツ・クライアントとやや異なっています。ユーザーはブラウザーでメッセージを作成し、送信されるとサーバーの HTTP プロトコルを使ってサーバーの MAIL.BOX に保存されます。そして、ドミノ・ルーターが SMTP、あるいはネイティブ・ノーツのルーティング機能を使ってそのメッセージを宛先に送ります。これ以降は、ノーツ・クライアントから送信された場合と同じになります。

ログ・ファイルや統計を使えば、サーバー上のメールの使用やスループットをモニタリングできるほか、メッセージのトラッキングも可能です。ブラウザーから送信されたメッセージをすべてトラッキングするには、メッセージ・トラッキング・コレクターを使用します。つまり、ブラウザーはノーツ・クライアントのように自らのメッセージをトラッキングする機能を備えていません。ここでもサーバーの機能に頼ることになります。

ブラウザーからメールを使った場合の相違点として、ユーザー情報が個別の個人アドレス帳ではなく、メール・ファイルに保存されるということがあります。これによって、個人アドレス帳にあるユーザーの数によっては、メール・ファイルのサイズがやや大きくなってしまいます。当然、ファイルのサイズを小さくするのには古い文書を削除したりアーカイブとして保存する、という方針をとるのがいいでしょう。ユーザー情報が入ったデータベースを間違って消してしまいそうですが、文書の $NoPurge フィールド、そして PROTECTFROMARCHIVE フィールドを設定することによって、データベース内に保持しておくことができます。

メール・ファイルは NSF なので、R 5.0 で管理要求を実行すれば、移動させることができます。この要求はドミノ管理クライアントの Mail Users ビューから行ない、ユーザーのメールを別のサーバーに移すために必要な処理を、メールを失うことなく行なってくれます。システム管理プロセス (AdminP) はこの処理で実行される手順の1つ1つにそれぞれ要求を出し、すべてが正常に行なわれたことを報告します。通常、次のような手順が踏まれます。
  • メール・ファイルを移す先のサーバーに複製します。
  • ユーザー文書を変更して、新しいメール・ファイルの場所を反映させます。
  • ユーザーのロケーション文書に変更点を加えます。
  • 前のメール・ファイルを新しいメール・ファイルで複製します。
  • 古いメール・ファイルを削除します。
しかし、この手順のすべてがブラウザー・クライアントでも行なわれるというわけではありません。ブラウザーの場合でも、複製してユーザー文書を変更することはできますが、ロケーション文書を持たないため、当然変更することもできません。これにより、小さな問題が生じます。メール・ファイルの移動は命令を出されて実行されるプロセスなので、1つの手順が成功して初めて次の手順に進みます。ブラウザーではロケーション文書の変更は行なわれないため、最後の2つの手順に関しては、自分で行なう必要があります。まずドメイン内でユーザー文書に加えられた変更点が複製されたら、古いメール・ファイルを新しいものに複製します。完了したら、古いメール・ファイルを削除します。

メール・ファイルを削除する以外にも方法があります。Create Push Change Request Agent（US） のロータス スクリプトを Notes.net の Iris Sandbox からダウンロードしてください。このロータス スクリプトを使えば、管理要求データベースに、移動したメール・ファイルを持つユーザーにメールを送って、2つのメール・ファイルを複製して、次の指令で古いほうを削除するという一連のタスクを行なってくれるエージェントが作成されます。このエージェントの使い方については、ダウンロード・ページを参照して下さい。
 
上に戻る
 
データベースにブラウザーからアクセスできるようにする
ドミノ サーバーは、HTTP サービスを通してデータベースをブラウザーにロードすることができます。ビューやフォームは非常に便利ですが、普通ブラウザーを使うときとはやや異なった印象になってしまいます。ドミノ・デザイナーを使えば、データベースを修正してフレームや JavaScriptといった機能をサポートしたことで、より Web に近い見た目や感触を与えることができるほか、ノーツ・データベースにそのような機能を追加することができます。ブラウザーとノーツ・クライアントの両方からデータベースにアクセスする、という混在した環境なら、どちらのクライアントからアクセスするかに応じて、異なった見た目や感触を指定することができます。例えば、ノーツ・クライアント用、ブラウザー用にフィールドを作って フィールド・プロパティーの [非表示] タブの段落非表示で、ノーツ か Webブラウザー を選択することで、各クライアントにそれぞれ正しく表示されるように設定することが可能です。

ドミノ サーバーをブラウザーからのアクセスに対応させる第一歩として、ブラウザー・ユーザーに何を見せるのかを考えることが必要です。このとき、ブラウザーを使ってのアクセスは、ノーツ・ユーザーにとっては自分が慣れているものとは違うということを頭に入れておいてください。

例えば、ノーツ・ユーザーは [ファイル] - [データベース] - [開く] を選択して、サーバーやデータベースの一覧にいくことができますが、ブラウザー・クライアントを使っている場合は、URL を指定する必要があります。これは操作を限定してしまう、と思うかもしれませんが、逆にこれを使うことによってユーザーがどのようにブラウザーからアクセスするかを決めることができます。ユーザーが使うすべてのデータベースへのリンクを持ったポータル Web ページにすれば、中心となる Web ページを管理するだけでデータベースにアクセスするユーザーすべてに有効なので、管理にかかる費用を削減できます。ノーツ・クライアントを使っている場合は、データベースを他のサーバーに移すたびに「古いブックマークを削除してここにリンクしてください」という主旨のメールを送信する必要がありますが、Web ページではリンクを変更するだけでいいのです。

この方法は、ユーザー固有のデータベース、特にメール・データベースには使うことができません。各ユーザーのメール・ファイルにそれぞれ固有の URL が必要になるので、ユーザー1人1人にポータルが1つ必要になると思うかもしれません。しかし、これはあくまでソフトウェアだということを思い出してください。ソフトウェアである以上は、何でも可能なのです。ユーザーをユーザー名とパスワードを使って自分のメール・ファイルに移動するようにすればよいのです。Notes.net の Iris Sandbox にある MailJump（US） というサンプル・アプリケーションをチェックしてみてください。

これらの機能を備えていると、ブラウザー・ユーザーが使うすべてのデータベースへのリンクを貼ったページを管理するのは大変なことです。別の方法として、サーバーにアクセスしたときにそのサーバー上で見ることができるデータベースの一覧を表示させるのもいいでしょう。しかし、デフォルトではサーバーの IP アドレスをブラウザーで入力したときにこのような一覧は表示されません。

ブラウザーがドミノ サーバーにアクセスする時のデフォルト・ページは、ヘルプ、リリース・ノート、ロータス、IBM、そして Notes.net サイトへのリンクを持っています。これは便利といえば便利ですが、アクセスできるデータベースの一覧もドメイン内のサーバーの一覧もなく、ノーツとは全然違った印象です。しかし、これにはセキュリティー上の理由があります。すべてのデータベースの ACL を見て、デフォルト・アクセスが正しく設定されているかどうかチェックしたとは限らないのです。もし ACL をすべてチェックして、それでもサーバーのデータベース名の一覧を自動的に表示してもいいというのであれば、サーバー文書を変更してそのようにできます。インターネット・プロトコル・タブの HTTP を変更し、ホーム URL を ?OpenServer にします。

Home URL settings

ブラウザーとノーツ・クライアントのアクセスは容量計画の際に違うということも認識しておくべきです。ドミノ サーバーがサポートしているブラウザー・ユーザーの同時アクセス数は、ノーツ・ユーザーの同時アクセス数よりも低くなっています。また、この数字はデータベースによって異なりますが、概してノーツ・ユーザーの方がブラウザー・ユーザーよりも3倍ほど多くなっており、このことを頭に入れた上で容量計画を練る必要があります。この比率はこれからより向上させていき、iNotes Web Access クライアントの次期リリースでは大幅に改善される予定です。
 
上に戻る
 
個人ビューやフォルダーはどうするのか
テンプレートを作成したり修正する際には、ブラウザー・ユーザーは、データベースの個人ビューを作成することはできないということを考慮に入れておく必要があります。ノーツ・クライアント環境の場合よりも、多くのビューをブラウザー・クライアントのために作成する必要があるかもしれませんし、標準のテンプレートではないビューがユーザーの好みに合って、テンプレートとして追加したほうがいいのかを調べることになるかもしれません。

しかし、ブラウザー・ユーザーは自分のフォルダーを作成できるので、メールを分類するという点については心配する必要はありません。
 
上に戻る
 
カレンダー&スケジュール機能
ブラウザー・クライアントでもノーツのカレンダーとスケジュール機能を利用することができます。アポイントメントを取ったり、会議を予約するといった機能のほかに、他のブラウザー・クライアントで自分の空き時間を公開することもできます。ドミノ・オフライン・サービスを利用するのなら、ノーツ同様、インターネットに接続していない時でもアポイントメントをとって、空き時間をサーバーに複製するといったことも可能です。また、ノーツと同じように、リソース (会議室や備品) を設定して、ブラウザー・クライアントが予約できるようにすることもできます。
 
上に戻る
 
代理人機能を使う
ブラウザー・ユーザーも、他の人に自分のメールやカレンダーにアクセスして欲しい場合はメール・ファイルの代理人機能を利用できますが、ACL を修正することはできません (これは必ずしも悪いことではありません。ブラウザーでアサインしたデフォルト ACL を変更できないということは、エージェントやアーカイブ、レプリカの作成、そしてメール・ルーティングの際に生じる問題点を減らしてくれるということです。しかし、やったことがある人なら分かると思いますが、ブラウザー・ユーザーが間違ってメール・ファイルを削除してしまう、ということを防げます)。
 
上に戻る
 
最後に…そして最も重要な点：セキュリティー
セキュリティーはドミノ管理者が、ノーツ・クライアントをブラウザー・クライアントに移行する際に最も考慮しなくてはならないポイントです。ブラウザー・ユーザーにユーザー文書を設定する際、インターネット・パスワードを与えることができます。このパスワードはチャレンジ/レスポンスのセキュリティー・モデルで使われるもので、ブラウザーがデータベース (メールなど) アクセスする際に、ドミノがユーザー名とパスワードを聞いてきます。そしてドミノ・ディレクトリーでユーザー名をチェックし、入力された名前とユーザー文書の名前を照らし合わせます。ドミノ イントラネットを構築する際には、この方法が顧客の間では定着しています。ドミノでは、データベースへのアクセスのセキュリティーに関していくつかの方法が用意されています。ですから、このチャレンジ/レスポンスのモデルよりもセキュリティーを強力にしたり、軽くしたりと調整できます。

セキュアーなコネクションが必須というわけではない場合は、データベースの ACL のユーザーを匿名に設定して、匿名のアクセスを許可します。この機能を使う際に考慮する点が2つあります。まず、ドミノ サーバーに匿名アクセスを許可させる、ということです。これは、サーバー文書の [セキュリティ] タブで行ないます。

Setting anonymous access

2つ目は、ドミノ サーバーにとってはどの匿名ユーザーも同じものとして扱われ、匿名ユーザー同士は見分けられない、ということです。データベースの使用状況をトラッキングする際には、すべての匿名ユーザーが「匿名」として1まとめにされます。ですから、誰がそのデータベースを使ったのかを具体的に知ることはできなくなり、ユーザーが自分から最も近い場所にあるデータベースのレプリカを見ているのかどうかを知る手立てはないということになります。パフォーマンスの点で、ユーザーにとって使いやすい環境をめざす管理者にとってはこれは問題です。LAN 接続のほうがデータベースは早く閲覧できるので、例えば、ニューヨーク支店のユーザーにはニューヨークにあるレプリカ、ロンドンにいるユーザーにはロンドンにあるレプリカにアクセスして欲しいものです。これが行なわれているかどうかをモニタリングするには、サーバーのログでデータベースの使用状況をトラッキングします。しかし、ユーザーが ACME 社のニューヨーク支店の誰々、ではなくただ「匿名」となっているのでは、トラッキングするのは不可能です。つまり、チャレンジ/レスポンスのモデルを使ったユーザー認証では、この問題がまったく無視されてしまっているということになります。

インターネット・パスワードを使ったモデルは匿名アクセスよりもセキュアーですが、ノーツ・クライアントで使われているパブリック、プライベート・キーの組み合わせには劣ります。プライベート・キーをローカルのクライアントで持つという方法は、サーバーにアクセスしているユーザーが本当に本人であることを確認するという点で秀でています。ただユーザー名とパスワードを確認するのと違い、プライベート・キーはサーバーのユーザー文書にあるパブリック・キーと合致したキーを本人が持っている、ということが必要になります。ノーツ・クライアントでは、このキーはユーザーの ID ファイルにあります。X.509 認証を使えば、同様のセキュリティーをブラウザーでも利用することができます。X.509 認証は、言わばブラウザーの ID ファイルとなるわけです。

ノーツ ID は、ドメインで最初のサーバーをセットアップしたときに作られる認証者 ID を使って作成されます。これによって、認証機関が確立されるわけです。X.509 認証では、ベリサイン社などの、外部の認証機関を使うことができます。もしユーザーがイントラネット内にしかいない、あるいはそのように想定しているのであれば、わざわざ外部の認証機関を使用する必要はありません。ノーツの ID モデルに似せたいのであれば、自らが認証機関となります。認証機関は、ノーツの認証者と同じようなものです。ユーザーとサーバーの両方が同じ認証機関で発行された X.509 認証を持っていれば、プライベート・キー認証を行なうことができます。

X.509 認証がどのように働くかを、ノーツでの用語を使って説明してみましょう。認証機関とは、ノーツの認証者と同様で、キーリングはノーツ ID、そして X.509 認証はノーツ ID 内に含まれている証明書に例えられます。R5 システム管理 ヘルプで認証機関のセットアップ、SSL を有効にしたドミノ サーバーでの X.509 認証の作成について参照してみてください。これが終わると、X.509 認証をブラウザー・クライアントに発行して、プライベート・キーを使ってドミノ サーバーへのアクセス認証を行なえるようになります。

X.509 を発行するには、ドミノ サーバーについている認証機関機能を使います。サーバー文書の [インターネットポート] タブで SSL ポートの状態を有効にし、ドミノ サーバーで SSL を使うように設定します。

SSI port status settings


ノーツでの認証モデルに例えましたが、実際にはブラウザー・クライアントで X.509 認証を発行するというのは、ノーツ ID を作成するのとはやや異なっています。どちらかというと「ノーツ ID を再認証する」プロセスに似ています。ノーツ・ユーザーが ID を再認証する必要がある場合、証明書を要求するという形になります。その要求は認証機関に送られ、認証機関は証明書を作成し、メールでユーザーに送り返します。そしてユーザーはこの証明書を受け取り、処理が終了します。ブラウザー・クライアントが X.509 を使って認証を行なう場合にも、まずドミノ サーバー上の認証機関のデータベースに行き、クライアントの証明書を要求します。要求が認証機関に認められると、ユーザーは認証機関データベースで証明書を受け取ることができます。

ブラウザー・ユーザーへの証明書発行とノーツとの主な違いは、クライアントと証明書の組み合わせ方でしょう。ノーツ・クライアントを使っている場合には、「ID を持っていて、その ID はそのドメイン内のサーバーでユーザーを確認できる証明書を持っている」ということが条件になります。しかし、ブラウザーでは少し異なっています。ブラウザーはドミノ認証機関からクライアント認証要求が送られるずっと前にインストールされたケースがほとんどです。ノーツ・クライアントでの証明書の発行は、クライアント・ソフトウェアと同時に行なわれるのに対し、すでにブラウザーを使っているユーザーにどのように証明書を配布すればいいか、ということを考える必要があります。前述したように、メールで証明書の URL を送ることもできますが、ドミノ サーバーにメールが保管してあって X.509 認証を使ってアクセスしている場合にはよい方法とはいえません。すると、2つの選択肢が残ります。
  • ユーザーがブラウザーで認証機関データベースにアクセスして自分の証明書を要求し、要求が受け入れられたときにはサイトに来て証明書を受け取れるようにメール以外の方法でユーザーに知らせることができます。
  • 自分で証明書を要求して受け取り (この2つは同じブラウザーで行なう必要があります)、メール以外の方法でクライアントに対して発行することができます。キーをエクスポートしますが、このときにユーザーがどのようにキーをインポートできるのかを指示する必要があります。
2つ目のやり方でよいのは、どのように証明書を要求して受け取るのかという指示をユーザーにする必要がないということくらいしかないので (バッチを作るという方法は取れません)、ドミノの認証機関機能を使う方法をお薦めします (ユーザーがこの処理を自分で行なえない、となれば話は別です)。1つ目の方法は、証明書を要求したユーザーしかその証明書を手にすることができないという点で、よりセキュリティーの面で優れています。

認証のやり方を紹介したところで、維持、管理について話しましょう。まず、パスワード・チェックとインターネット・パスワードの期限切れといったものはドミノに存在しません。また、インターネット・パスワードはノーツ・パスワードでできるように、NT のパスワードとシンクロさせることもできません。とはいえ、NT を信用しても結局、1つのパスワードで確認することになります。ブラウザー・ユーザーは自分のユーザー文書にあるインターネット・パスワード・フィールドを編集することでパスワードを変更できるので、ユーザーにはそのフィールドを編集できるアクセス権を与えておく必要があります。パスワードはドミノ・ディレクトリーに保管されているので、サーバー上で有効になるためにはまず複製する必要があるということを忘れないでください。
 
上に戻る
 
まとめ
この記事を読む前にノーツ・クライアント・ユーザーの作成や管理といった知識をお持ちの方なら、これらのタスクをブラウザー・クライアントの世界でどのように行なうのかを理解されたことでしょうし、サーバーやデータベースに対するブラウザー・アクセスのセットアップ、メールやカレンダーでできること、そしてブラウザー・アクセスでのセキュリティー・モデルの違いなどについての理解も深めていただけたと思います。この記事を読んだあなたなら、iNotes Web Access や DOLS の試用版を実際に使ってみることができるはずです。
 
上に戻る