Lotus Notes/Domino (R) をこよなく愛して。。。。

ようこそ、Notes/Domino ファン & ブロガーのみなさん !


【ご注意】 このブログはビジネスに活用いただくためのものですので、以下の点を守ってご利用願います。


1. 他社あるいは他人への誹謗中傷のコメントはご遠慮ください。

2. コメントはビジネスとして問題のない言葉、表現を使ってください。

3. Webで一般公開されていない、具体的な個人や法人を特定するコメントはご遠慮ください。

4. 個人情報の記載は行わないでください。


上記を守られないコメントは、こちらの判断で削除させていただきますのでご了承願います。


尚、このサイトの掲載内容は私自身の見解であり、メーカーとは全く関係はありません。

また、メーカーのビジネスに利害を及ぼすために記載している訳ではありません。


ここに記載されている内容は、私自身の経験からの記載であり、内容が正確でない場合もあることをご理解の上、ご利用願います。


ご利用に際しては、左側のフレームに記載しております【注】をご一読の上、利用条件を守ってご利用ください。

1 | 2 | 3 | 4 | 5 | 最初次のページへ >>
March 20, 2019

ND V10で実装された送信Mail制限機能を試してみよう! -1-

テーマ:Notes/Domino 10.x

Notes/Domino 10.0から送信Mailの制限機能が搭載されました。

 

従来はNotes Clientでは特に制限はなく、カスタマイズでDocument SizeやAttachment Sizeなどを判断して制限するようにしているユーザーも多いのではないかと思います。

iNotesでは、Configuration Documentで添付ファイルの最大サイズの指定や、HTTP Request Sizeの制限を掛けるなどを行っていることでしょう。

ただ、iNotesでの添付ファイル制限は1ファイルの容量制限であり、複数にして添付すれば容量制限を超えることが出来ますので、全体の送信Mailサイズを制限するには、結局HTTPのRequestサイズで制限するしかないのが現状かと思います。

 

なた、DominoのSMTP/MTAではDefaultでは特に制限はありませんが、DMZに配置するRelay Server(SMTP/MTA)やInternetの世界では制限が掛かっていることが多く、大きな添付ファイルを送信することはマナー違反とされています。

 

内部でのメールにしても、爆弾メールのように相手に膨大な容量の添付ファイルを送り付けることはマナー違反とされるだけでなく、Mail DBの容量を圧迫するなど、様々な問題を起こします。

 

添付ファイルに限っては、DAOSが導入されている企業では、別領域に添付ファイルが保存されるため、トータルのDisk容量は削減できますが、ユーザーにとっては自分のMail DBに添付ファイルがあるのと同じで、Mail DBの制限値の警告を受けるなど、使い勝手が良くないということで、Mail DBの制限サイズをかなり拡張して利用するユーザーも増えていると思います。

 

IBMが提供するSCN(Smart Cloud Notes:Cloud版のNotes)でも50GBという容量を提供している訳です。

 

ユーザーの便宜を考え、Mail DBのサイズを大きくするのはユーザーにとっては嬉しいことかも知れませんが、運用する立場に立つと、DBが壊れやすくなったり、修復に時間がかかったり、日々のBackupに時間が掛かったりと余り良いことはありません。

やはり、メールでの大量データ送信は控えるようにしていきたいというのが、安定運用を行う上で重要なことではないでしょうか?

しかしながら、メール以外のファイル交換の手段を提供してもユーザーが使ってくれるとは限りません。

Cloudで運用されているGMailのように添付ファイルの制限容量を超えると、自動的にCloudのStorageに保存して、そのURLを相手に知らせるような機能があると一番便利だとは思いますが、社内で稼働させているNotes/DominoではDAOSで添付ファイルを共有化するくらいが限界です。

 

このような状況を打破するためには、やはり送信メールの制限を行い、ユーザーが制限を超えたメールを送れない状況を作ることも仕方ないのではないかと思います。

 

今回、Notes/Domino 10.0から送信メールを制限する機能が初めて搭載されました。

 

Administrator Helpには以下のように記述されています(日本語は私が適当に翻訳して書いています)。

 

・ 最大文書サイズ(Maximum document size)
・ 添付ファイル数(Maximum number of attachments)
・ 添付ファイルの総容量(Maximum combined size of attachments)
・ 受信者の総数(Maximum number of individual recipients) ※To/CC/BCCの総数
・ 送信先内部ドメイン(Internal domains, used to specify the domains to allow messages to be sent to)

 

Administrator Helpを見ると、この機能はNotes Clientのみということなので、少し残念です。

 

夫々の制限機能について、私の感想を以下に述べておきます。

この感想が本当に実現できているのか?が興味があるところです。

 

・ 最大文書サイズ(Maximum document size)

Inline Imageなどがどのように扱われるのかによって変わると思いますが、iNotesの場合はHTTPのPOST Size制限があるので、それで代用できると思います。

Notesの場合は、特に制限がないので、Inline Imageも含めTotalの文書サイズが制限できるのであれば、便利だと思われます。

 

・ 添付ファイル数(Maximum number of attachments)

複数ファイルを圧縮すれば解決してしまうので、余り需要はないかも知れませんが、大量に添付ファイルを付けることを制限することで、複数ファイルの圧縮が促進できるかも知れません。


・ 添付ファイルの総容量(Maximum combined size of attachments)

一般のユーザーを考えると、この制限が一番需要が高いのではないでしょうか?

iNotesでも個別のFileの最大容量の制限は出来ますが、添付ファイルの総容量の制限は出来ないので期待できます。

 

・ 受信者の総数(Maximum number of individual recipients) ※To/CC/BCCの総数

これはやたら宛先を指定してMailを送る防止策になると思いますが、Groupを展開して数を計算するのか?とか処理方法に非常に興味がありましたが、Administrator Helpの注意書きにGroupは1個の受信者として計算すると書かれていたのが残念です。

ユーザーによっては、やたら宛先を指定して送付する場合があり、本当に仕事上必要な人だけにメールを送るという習慣付けも必要かも知れませんので、私はこの機能は必要だと考えています。

Notes Clientなら、Mail TemplateのCustomizeでTo/CC/BCCのFieldをJoinして、Elementsの数を数えて制限することは可能ですが、個人/公開 Groupまで展開して数を数えるとなると、結構面倒な処理になります。

iNotesに関しては、FormsファイルのCustomizeでTo/CC/BCCの総数をCountして制限を掛けることは可能ですが、Groupを展開するのは困難ですし、Mail送信時だけでなく、Draft保存時やAuto Saveでの保存時にも制限Checkが動いてしまうという副作用が発生します。

 

・ 送信先内部ドメイン(Internal domains, used to specify the domains to allow messages to be sent to.)

これは意味が直ぐに理解できませんが、内部Domainと外部Domainを区別して外部Domainへの送信を制限するということでしょうか?

お客様によっては、Mail TemplateをCustomizeして、外部のInternet Addressにメールする場合に警告を出すような機能を搭載されている場合も見受けますので、どのような機能なのか大変興味があります。

また、Notesの隣接Domainなどへの配信制限も出来るのか興味があります。

 

この機能に関し、私が興味を抱いた点だけでもかなりある訳です。

多分、皆さんも多くの期待と疑問を持っておられると思います。

 

このシリーズでは、これらの疑問を可能な限り検証してみたいと思います。

 

今回は、Notes/Domino 10.0から搭載された送信Mailの制限機能について考察してみました。

次回からは、具体的に夫々の制限機能について検証していきたいと思います。

 

<続く>

 

 

March 18, 2019

ND V10で実装されたDocument deletion loggingを試してみよう!

テーマ:Notes/Domino 10.x

Notes/Domino 10.0から文書の削除ログ機能が搭載されました。

 

皆さんも、ユーザーがMailが配信されていないなど調査を依頼されたこともあるのではないでしょうか?

メールの配信状態やユーザーによる削除かどうかを調査し判断するのは運用を行う担当者にとって非常に面倒な作業です。

特に外部からのメールの場合は送信者や大まかな日時などを聞いて、MTAから内部Mail Serverまでの配信状態をLogから調査したり、最終的にユーザーのMail DBを分析して文書のUNIDから削除の痕跡を探すなどの作業が必要になってしまいます。

 

今回の新機能がこのような悩みを解決してくれるのか?検証してみたいと思います。

 

このこの機能もTransaction Loggingが前提となっています。

構築しているNotes/Domino 10.0.1 Trial Versionの評価環境ではTransaction Loggingは有効になっていますので、現在の環境のまま評価していきます。

 

まず、この機能を有効化するためには、Compactを行う必要があります。

 

load compact <database path> -dl on "<comma separated list of items>"

 

というFormatでCompactを行うことになっています。

では、早速、Mail DBに対してCompactを流してみます。

 

load compact mail\siwama.nsf -dl on "Posteddate,From,Subject"
[0CA8:0055-106C] 2019/01/29 17:00:39   Remote console command issued by Administrator/Lotus: load compact mail\siwama.nsf -dl on "Posteddate,From,Subject"
[0ED8:0004-1234] 2019/01/29 17:00:42   Informational, Deletion Logging has been enabled for database mail\siwama.nsf.
[0ED8:0002-050C] 2019/01/29 17:00:43   Database compactor process shutdown

 

Notes ClientからMail文書を2文書削除してみます。

削除すると、IBM_TECHNICAL_SUPPORT フォルダーにDelete.logという名前でログファイルが作成されます。

Delete.logファイルは、Windowsのメモ帳で開くと改行がされないので、Sakuraで開くと以下のようになっています。

 

delete_Domino10Srv_2019_01_29@14_13_38.log
"20190129T170301,31+09","mail\siwama.nsf","4925838E:0074794E","nserver","CN=Administrator/O=Lotus","SOFT","0001","EAB15402:38334A4549258390:0010CFA8","Posteddate","19","2019/01/28 12:15:03","From","24","CN=Administrator/O=Lotus","Subject","4","test"
"20190129T170547,47+09","mail\siwama.nsf","4925838E:0074794E","nserver","CN=Administrator/O=Lotus","SOFT","0001","FC53A7B1:EB6782FE4925838F:007A471E","Posteddate","19","2019/01/28 07:30:02","From","24","CN=Administrator/O=Lotus","Subject","26","Scheduled Message by Appl."

 

指定したPosteddate,From,Subjectがリストされています。

リストする項目にはText, Text_List, RFC822_Text, Timeが指定できますので、To/CC/BCCやRecipientなども追加することが可能です。

今回は、Mail DBで通常の削除を行っていますので、Deletion Typeが"SOFT"となっていますが、ゴミ箱から完全に削除すると以下のように表示されます。

 

"20190129T172410,15+09","mail\siwama.nsf","4925838E:0074794E","nserver","CN=Administrator/O=Lotus","HARD","0001","EAB15402:38334A4549258390:0010CFA8","Posteddate","19","2019/01/28 12:15:03","From","24","CN=Administrator/O=Lotus","Subject","4","test"

 

非常に単純な機能ですが、この機能を有効にしておくと、Mailの削除調査には役立つのではないでしょうか?

 

但し、実際の環境ではユーザーも多いので、文書削除Logの容量見積もりを行い、十分なDisk Spaceが確保できるように計画する必要があります。

この文書削除LogはConsole.logと同様にServer Restart時に日時を付けて古い物が残されていきますので、Console.logと同様に保持期間を決めて自動的にFileを削除するようなBatchを準備しておけば問題はないと思います。

 

これまでの調査方法に比べると、文書削除ログを検索するだけである程度の調査が可能になりますので、有効活用できるのではないかと思います。

 

March 14, 2019

ND V9 FP9で実装されたInline Indexerを試してみよう! -3-

テーマ:Notes/Domino 10.x

<話題の履歴>

ND V9 FP9で実装されたInline Indexerを試してみよう! -2-

ND V9 FP9で実装されたInline Indexerを試してみよう! -1-

 

前回は、Inline Indexの動作を確認してみました。

今回は、NIFNSFが有効な場合の動作を確認してみたいと思います。

 

このシリーズの最初にTransaction Loggingを無効化したのですが、再度有効化します。

更に、前回利用したテスト用DBのGroup文書は全て削除して、ServerをRestartします。

 

また、前回利用したテスト用DBの両方をNIFNSFを有効にします。

 

load compact -c -nifnsf on InlineIndex\names_inlineindex_on.nsf
[0CA8:0055-0670] 2019/01/29 14:18:23   Remote console command issued by Administrator/Lotus: load compact -c -nifnsf on InlineIndex\names_inlineindex_on.nsf
[1010:0004-09CC] 2019/01/29 14:18:25   Informational, NIFNSF has been enabled for database InlineIndex\names_inlineindex_on.nsf.
[1010:0004-09CC] 2019/01/29 14:18:25   Recovery Manager: Assigning new DBIID for C:\IBM\Domino\Data\InlineIndex\names_inlineindex_on_nsf.ndx (need new backup for media recovery).
[1010:0004-09CC] 2019/01/29 14:18:25   Compacting InlineIndex\names_inlineindex_on.nsf (Inline Index on Lotus's Directory),  -c -nifnsf on InlineIndex\names_inlineindex_on.nsf
[1010:0004-09CC] 2019/01/29 14:18:27   Recovery Manager: Assigning new DBIID for C:\IBM\Domino\Data\InlineIndex\names_inlineindex_on.nsf (need new backup for media recovery).
[1010:0004-09CC] Clearing DBIID 16CCA86A for DB C:\IBM\Domino\Data\InlineIndex\names_inlineindex_on.ORIG
[1010:0004-09CC] 2019/01/29 14:18:29   Compacted  InlineIndex\names_inlineindex_on.nsf, 2048K bytes recovered (12%),  -c -nifnsf on InlineIndex\names_inlineindex_on.nsf
[1010:0002-06F4] 2019/01/29 14:18:29   Database compactor process shutdown
load compact -c -nifnsf on InlineIndex\names_inlineindex_off.nsf
[0CA8:0055-0A28] 2019/01/29 14:18:30   Remote console command issued by Administrator/Lotus: load compact -c -nifnsf on InlineIndex\names_inlineindex_off.nsf
[0ECC:0004-0F08] 2019/01/29 14:18:32   Informational, NIFNSF has been enabled for database InlineIndex\names_inlineindex_off.nsf.
[0ECC:0004-0F08] 2019/01/29 14:18:32   Recovery Manager: Assigning new DBIID for C:\IBM\Domino\Data\InlineIndex\names_inlineindex_off_nsf.ndx (need new backup for media recovery).
[0ECC:0004-0F08] 2019/01/29 14:18:32   Compacting InlineIndex\names_inlineindex_off.nsf (Inline Index off Lotus's Directory), -c -nifnsf on InlineIndex\names_inlineindex_off.nsf
[0ECC:0004-0F08] 2019/01/29 14:18:34   Recovery Manager: Assigning new DBIID for C:\IBM\Domino\Data\InlineIndex\names_inlineindex_off.nsf (need new backup for media recovery).
[0ECC:0004-0F08] Clearing DBIID 3211DBD5 for DB C:\IBM\Domino\Data\InlineIndex\names_inlineindex_off.ORIG
[0ECC:0004-0F08] 2019/01/29 14:18:35   Compacted  InlineIndex\names_inlineindex_off.nsf, 2048K bytes recovered (12%),  -c -nifnsf on InlineIndex\names_inlineindex_off.nsf
[0ECC:0002-0DB8] 2019/01/29 14:18:36   Database compactor process shutdown

 

これで、NIFNSFが有効になり、NDXファイルが生成されました。

 

 


では、この状態でView Indexの状態を確認しておきます。

どちらのDBもGroups View Indexはほぼ最低限の容量まで小さくなっていることが確認できます。

 

 

では、前回と同様にAgentからGroup文書を生成します。

しかし、残念ながら、Administratorから見たView Indexの容量は増えることもなく、NDXの容量も増えませんでした。

 

 

つまり、NIFNSFとInline Indexの機能は併用できないということだと思います。

私は、FP8で実装されたNIFNSFが予定通りのPerformanceが出ないため、それを補うためにもInline Indexの機能が搭載されたのかと思っていましたが、期待外れだったようです。

 

今回、Indexer TaskのIntervalを30分に設定していますので、NDXファイルを更新するのがIndex Taskのみなのかどうかを確認するため、最大の30分間待ってみることにします。

30分経過して確認したところ、NIFNSFが無効なDBのIndexに関しては更新が行われ、View Index容量も増えていました。

以下のExplorerでの更新日時は他のTaskがDBを更新したためだと思われますが、全て同じになっていますが、見ていた限りでは、NIFNSFが無効なDBは約20分経過の時点でView Indexの更新が確認できています。

 

 

AdministratorからView Indexの状態を確認すると以下のようになっています。

 

 

更に放置して待っていると、Group文書作成のAgentを流してから、1時間経過した時点でようやくNIFNSFを有効化したDBのIndexの更新が行われました。
 
 
View Indexが更新された時間には、Console Logに以下が記録されていました。
 
[0990:0007-0144] Successfully refreshed Inline Index for C:\IBM\Domino\Data\InlineIndex\names_inlineindex_on.nsf, All Views
[0990:0007-0144] Successfully refreshed Inline Index for C:\IBM\Domino\Data\InlineIndex\names_inlineindex_on.nsf, All Views
 
今回のテストは非常に残念な結果に終わりました。
しかし、内部的にどのような動作でIndex更新が行われ、Inline Indexが有効化されたDBのIndex更新が遅れたのかは分かっていません。
Inline Indexが有効化されたDBはInline Indexerのみが更新を行い、Indexerからの更新が行われないと言うのであれば、Indexは永遠に更新されない訳で、今回の結果はそうではないからです。
これ以上の深追いは時間の無駄ですし、内部の動きを把握するためにDebugパラメーターなどを探さなくてはならなくなるため、これ以上の究明はやめることにします。
 
このシリーズではNotes/Domino 9.0.1 FP9で実装されたInline Indexの機能の検証を行ってきましたが、NIFNSFが有効にされたDBではInline Indexは逆効果であることが分かりました。
今回の評価では、Indexer TaskのIntervalを30分としたため、このように顕著に現象が現れたのかも知れませんが、Defaultの5秒であっても、今回の検証と同じように最大10秒を要するかも知れません。
通常のApplicationからの利用であればProgramからViewを開く要求が出されるため、その時点でView更新が行われ、それ程大きな問題は発生しないと思いますが、NIFNSFを有効にしたDBに対し更にInline Indexを有効にすることは避けた方が良さそうです。
NIFNSFを有効化しないDBであれば通常のIndexerに比べ高速にView Indexが更新されるため、Application Performanceには貢献すると思われます(但し、多くのDBを対象にした場合はServer Resourceを考慮する必要があるでしょう)。
 
IBM/HCLには、これらの二つの機能が両立してかつ、Performance良く動くように改善されることを期待したいと思います。

 

<終わり>

 

 

1 | 2 | 3 | 4 | 5 | 最初次のページへ >>

Ameba人気のブログ