July 04, 2016

iNotesのArchive Policyの仕組みを解明したい! -2-

テーマ:Test Lab.
<話題の履歴>

iNotesのArchive Policyの仕組みを解明したい! -1-


前回は、Groupを使ったPolicyがGroupのMemberに適用されるまでの動作を見てみました。

今回は、Policyが適用される前後で、iNotes Profileなどに変化があるのかを見てみます。


NotesのProfile文書は幾つか存在していることは皆さんもご存知の通りです。
IBMのTechnoteにも幾つかのProfile文書が紹介されています。

しかし、ここに紹介されているProfile文書が全てなのでしょうか?
Profile文書を確認するためのToolとして"A tool to manage profile documents"というものが紹介されています。

このToolであれば、Mail DBの中に設定されているProfile文書を簡単に全て確認することができそうです。

早速、Downloadして試してみることにします。
DBが入っていますので、拡張子をns6からnsfに変更し、Notes ClientのData FolderにCopyします。
DesignerでDBを開いてFormをMail DBに貼り付けます。
FormをDesigner開くと/IBMとの相互認証が求められますが、無視して、開いたFormを保存します。
これで今後相互認証が求められることはなくなります。
準備はたったこれだけで、Mail DBを開いて、「作成」>「その他」から"Profile Document List"を選ぶと、Profile一覧が含まれた文書が作成されます。

iNotes_Archive_1

これでProfile文書が全て参照できています。
iNotes関係だけで、3つのProfileが存在することが確認出来ます。
Profileの編集も用意されていますが、iNotes関係のProfileはUserに見える形のFormとして設計要素が無いために、編集することは出来ませんが、更新日が分かりますので、何が変更されたのかの判断はつきます。

では、早速試していきます。

まずは、前回の実験で設定した、Notes.ini設定を元に戻しておきます。

> set config UPDATE_NAB_SUPPRESSION_TIME=
[07EC:0004-1064] 2016/06/11 10:00:58 UPDATE_NAB_SUPPRESSION_TIME を 0 に変更しました。
[122C:0004-0D24] 2016/06/11 10:01:01 UPDATE_NAB_SUPPRESSION_TIME を 0 に変更しました。

最初に、現在AssignされているDynamic Policyで設定したArchive Policyを除外するために、Groupを編集し、"($ServerAccess)" Viewを更新してPolicyの適用の変更を反映させます。

Notes ClientからMail DBを開いてみると、Archiveは無効になっていますが、Profile文書の変更の形跡は残っていません。

iNotes_Archive_2

次に、iNotesで開いて、Preferneceを保存しなおすと以下のようになります。

iNotes_Archive_3

当然ですが、iNotesProfileが変更され、更に、CalendarProfile、DOLSOfflineConfiguration Profileが変更されていることが分かります。
CalendarProfileが更新されるのは、iNotesとNotesとで共用しているProfileがCalendarProfileにあるからです。
DOLSOfflineConfiguration Profileが更新されているのは、このUserはOfflineが有効になっている為で、Offlineを禁止すれば更新されないと思われます。

こうして見てみると、Dynamic Policyを無効にした場合は何も更新されないのでは無いかと思われます。

では今度は逆にDynamic Policyが適用されるように、Group文書を更新してみます。

Notes Clientから見るとArchiveが有効な状態になっていますが、Profile文書が更新された形跡はありません。
Notes Clientの場合は、LocalにPolicyが配布されてくるためでしょう。

iNotes_Archive_4

次に、iNotesでAccessしてみると、Archive Menuは現れていない状態になっていますので、Preferenceを保存してみます。
これでArchiveがMenuに現れますので、再度、Notes ClientからProfileの状態を確認します。

iNotes_Archive_5

無効にした際と特に変化はありませんでした。

この実験から言えることは、iNotesの場合も、PolicyはMail DBのProfileではなく、全く別の場所で管理されているのではないかということです。

今回は、PolicyのAssignによってProfile文書がどのように変更されるかを試してみましたが、残念ながら解析できませんでした。

次回は、もう少し考えるところがあるので、再度実験してみたいと思います。

<続く>
いいね!した人  |  コメント(0)  |  リブログ(0)
最近の画像つき記事
 もっと見る >>
July 02, 2016

Notes/Dominoの64GBの限界値を超えてしまったDBの復活?(続)

テーマ:Technique
前回紹介した、DBの制限値である64GBを超えてしまったDBの回復方法ですが、必ずしもDBのReplicaやCopyの処理は必要ではないことが分かりました。

冷静に考えてみると当然のことなのですが、DBのReplicaやCopyが可能と言うことは、DBの内部的に持っているIndexを使って設計要素(設計要素もNotes/Dominoにとっては文書です)や文書が読めるということです。

前回も書きましたが、DBを開く際にB-Tree Invalid Errorが発生するのは、あくまでUserが利用するViewが壊れてしまっているために利用出来ない状態に見えるに過ぎないということでしょう。

回復を試みる場合、前回書いたLotusScriptでDebugしながら、db.AllDocumentsのCollectionが取得でき、Collection.CountとCollection内の文書が読めることが確認して、読めているようなら、分割処理を行っても問題はありません。

恐らく、db.AllDocumentsはDB内部で利用するIndexの中から設計要素の文書を除いた物だけを
返しているためだと思われます。

64GBのDBをReplicaしたりCopyしたりするにはかなりの時間がかかることもありますので、先ずは、db.AllDocumentsが取得できるかを試してみてください。

ただ、ここで注意点ですが、DBは壊れている可能性がある訳で、全ての文書が正常な状態で復活できることが保証されている訳ではありません。
あくまで、救える文書は救ってあげるという考え方で使ってください。
 
いいね!した人  |  コメント(0)  |  リブログ(0)
June 30, 2016

iNotesのArchive Policyの仕組みを解明したい! -1-

テーマ:Test Lab.
Archive Policyを使って、膨れ上がるMail DBをArchiveする方法の記事を書いていたのですが、iNotesだけ少し変わった振る舞いをしているようなので、このシリーズでは徹底的にTestしたいと思います。

まず、Testするにあたって、Test Senarioを考えてみます。

1) Policyを適用するGroupを変更した際の動作
  => Group変更で個人にPolicyが適用されるまでに何が行われるか?
2) Policyが適用された時点のProfile文書の状態
  => iNotes Profileなど何が変更されるか?
3) iNotes Preferneceを手動で更新した際の動作
  => 何が更新されて、Archiveが有効/無効となるのか?

これが分かれば、Policyの適用対象のGroupをLotusScriptのAgentから変更した際に、即時にUserに反映する方法が見えてくるのではないかと思います。

まず最初に、

1) Policyを適用するGroupを変更した際の動作

について試してみます。

これまで、Policyを適用するGroupを更新して、実際にPolicy一覧でPolicyのAssignが確認できるまでタイムラグがあることが確認できています。
しかし、このタイムラグは非常に短い時間ですので、試すのが難しいかも知れません。

Dominoはnames.nsfに設定された様々なな情報をCacheするように出来ています。
User情報などはName Lookup Cache(NLCACHE)にCacheされて、Address参照時など、names.nsfを参照することなく、NLCACHEを参照してAddress解決を行ったりしています。
このNLCACHEが影響して、Mailの配信がうまく行かない場合には、Server Consoleから"show nlcache reset"を発行するようにIBM Technical Supportから案内され、実行されたことがある人も多いのではないかと思います。
このCommandにより、Name Lookup Cacheの内容はResetされて、新規にName Lookup Cacheが作成されます。
Groupの情報に関しても、Group Cacheを持っていて、この情報を参照しながら、Groupに関する処理を行っているのですが、残念ながら、Name Lookup Cache(NLCACHE)のようにServer CommandでResetする方法が提供されていません。
IBMによると、Group Cacheの更新は、Groupの更新を1分間隔でMonitorしていて、更新を検知するとGroup Cacheの更新を行うようです。
このMonitorは($ServerAccess) Viewの更新タイミングとなっていて、このViewが更新されると、Group Cacheの更新を行います。
Dominoとしては、Directory Indexer Task(通常のUpdate Taskとは別に動作するDomino Directory専用のUpdate Task)によって処理されていると思いますが、Directory情報の更新が激しい環境では1分という時間が守られていないかも知れません。

(参考)You changed group membership, now when will dynamic policies reflect that?

When you add/remove a member of a group, the Indexer thread will update the internal directory view which is then used to update the group cache. The Indexer thread will run every minute by default or you can specify the server INI variable UPDATE_NAB_SUPPRESSION_TIME with a value in minutes. Once the group cache is updated, dynamic policies will now correctly reflect a users group membership.

Policyを適用するGroupを更新して、Policy一覧を直ぐに書き出して、適用Policyが変更されていない状態で、load updall names.nsf -t "($ServerAccess)"を発行すると、即時にPolicyが適用された状態になることが分かります。

つまり、Groupを使った明示的Policyは、Group Cacheの更新が行われると、直ぐに適用されるということだと思われます。

手作業でやっていたのでは、時間などがかかり、確実なTestにはならないと思いますので、LotusScriptのProgramから行って確認出来るか考えてみます。

実行すべきことは、

1) 明示的Policy適用対象のGroup文書を更新する
2) Server Command(load updall names.nsf -t "($ServerAccess)")を発行する
3) UserへのPolicyの適用状態を確認する

ということです。

1)は通常のLotusScriptで可能ですし、2)もLotusScriptからServer Console Commandを発行することで可能です。
3)はPolicy Synopsisしか無いのでしょうか?
これだとUIからの実施になり、1分以内に確認することができませんので、逆にUPDATE_NAB_SUPPRESSION_TIMEを使って、更新間隔を伸ばして確認した方が良さそうです。
これであれば、手作業での確認も可能です。

まず、Domino Consoleから以下を発行して、Update間隔を5分に伸ばします。

> set config UPDATE_NAB_SUPPRESSION_TIME=5
> show config Update*
[0D04:0009-0B90] UPDATE_NAB_SUPPRESSION_TIME=5

この後、Groupを編集して、Memberを入れ替えます。
入れ替えた後に、Policy一覧でPolicyの状態を確認してから、Server Consoleから
以下のCommandを発行します。

> load updall names.nsf -t "($ServerAccess)"
[05B4:0002-0ACC] 2016/06/11 07:17:56 Index update process started: names.nsf -t ($ServerAccess)
[05B4:0002-0ACC] 2016/06/11 07:17:56 Updating C:\IBM\Domino\data\names.nsf view '($ServerAccess)'
[05B4:0002-0ACC] 2016/06/11 07:17:56 Index update process shutdown

この後に、Policy一覧でPolicyの状態を確認すると、適用状態が変更されていることが分かります。

つまり、(参考)で紹介した英文のFAQにも書かれているように、Groupを使ったDynamic PolicyはGroup Cacheが変更された時点で有効になり、Group Cacheは1分ごとにUpdateされるということです。

今回は、Groupを使ったPolicyがGroupのMemberに適用されるまでの動作を見てみました。

次回は、Policyが適用される前後で、iNotes Profileなどに変化があるのかを見てみます。

<続く>
いいね!した人  |  コメント(0)  |  リブログ(0)

AD

ブログをはじめる

たくさんの芸能人・有名人が
書いているAmebaブログを
無料で簡単にはじめることができます。

公式トップブロガーへ応募

多くの方にご紹介したいブログを
執筆する方を「公式トップブロガー」
として認定しております。

芸能人・有名人ブログを開設

Amebaブログでは、芸能人・有名人ブログを
ご希望される著名人の方/事務所様を
随時募集しております。