2006年 01月 08日
GroupWise のデータベース最大サイズは２Gバイト
Is there a limit for a size of GroupWise databases ? - TID10099147
http://support.novell.com/cgi-bin/search/searchtid.cgi?10099147.htm
MSGxx.DB や USRxx.DB は過去との互換性のため最大２Gバイトに
制限されています。もっともそのサイズにまで達することがまれなんですが。
もっとも、大量に同じタイトルのメールを受信してしまうとその限りでは
ありません。たとえば、Love you ウィルスだとか、メールのループ
なんかもありえます。
こうして膨れ上がったメールによってDBのサイズが２Gバイトに達して
しまうことがあるようです。そうなるとDBの書き込みができないので
Facility Error がボコボコに出てしまいます。
こう言ったメールでデータベースが膨れ上がったときの対策は次の文書を
参考にして対処します。
Removing messages from the message and user database with GWCheck. - TID10052747
http://support.novell.com/cgi-bin/search/searchtid.cgi?10052747.htm
ただし、この SUBJECTLIST っていうオプションは困ったことに日本語には正確に
対応していません。早くなんとかしてほしいものです。
なお、DBの Reduce Only を実行するPCは Windows XP を使います。
Windows 2000 ではしっかりアプリケーションエラーになります。
Dr. Watson error occurs when performing a GWCheck expire and reduce operation on - TID10074200
http://support.novell.com/cgi-bin/search/searchtid.cgi?10074200.htm
非番のエンジニア
#
by islandcenter
| 2006-01-08 15:23
| GroupWise
|
Comments(0)
2006年 01月 08日
16,777,216 という数字
はい２４ビットの倍数です。数学の答えなら、それでオッケーでしょう。
この数字は NetWare の Traditional Volume で最大作れる
Directory Entory の数です。
Directory entries summary - TID10059084
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10059084.htm
エクスプローラから、ボリュームを選んでプロパティを開くと Directory Entry の
数値をチェックできます。
この数値はずばり、トラディショナルボリュームで作成できる、最大のファイル/
ディレクトリ数です。
ただし、この数字をＭＡＸ利用できると思うと大間違えで、実際には、ディレクトリを
作るとエントリを作成し、ディレクトリにファイルが書き込まれるとエントリが利用
されるという具合にこの数字は変化します。
実際にはファイルが削除されることもあるので、ディレクトリエントリ数というのは
常に増大します。
原則として減ることはありません。最近の巨大なディスクシステムを使った
ファイルサーバの場合、簡単にこの数字に達することがあります。
ディレクトリエントリは、初期状態では 512 程度の少ない数値を示します。
問題はこの数字１６００万に達した状態の時にどうなるかということです。
ディレクトリの作成要求に対して、システムは空きエントリを探すことから
始めるため、急にレスポンスが悪くなります。当然パージできるファイルが
あれば、パージもしなければならないのでその負荷も大変なことになります。
ちょうど、 Cim City のようなゲームを思い出してみてください。
このゲームで作れる最大の区画（ブロック数）は１６００万です。
マップが大きくても小さくてもこの数字は変わりません。
ゲームが進んでくると、全ての土地を開発し尽くしてしまいます。
例えブルドーザで住んでいないブロックを壊しても、住民がそれ以上
増えないのと同じです。
また、ひとつの３×３のブロックに家が一軒しかできない場合もあります。
マップが小さければゲームは軽いし、マップが大きいとゲームは重い
と感じるでしょう。
言ってみれば、トラディショナルボリュームもそんな問題が含まれています。
日本語ではこちらが理解しやすいかも
http://support-j.novell.co.jp/tid/us/1001000_/1001448.htm
対策としては、マメに purge を行うか、思い切ってボリュームを消して
作り直すのが一番効果があります。
また、ゲームの盤面のように大きなボリュームに小さなファイルを
沢山置くようなシステムの場合、ボリュームは小さめに作っておく
必要があります。
NSS の場合、そのような制限はないようです。もっとも試したことは
ありませんが。
非番のエンジニア
2006年 01月 08日
NetWare 6.5 のメモリリークの問題
NetWare 6.5 でＮＳＳを使うとmemory leak を起こします。
というよりNetWare 6.5 ではＮＳＳがデフォルトですから、必ず現象は出て
しまいます。
実際には、サーバが全く反応しなくなったり、memory allocation error が
出たりします。
>http://support.novell.com/cgi-bin/search/searchtid.cgi?/10091980.htm
この状態はリモートマネージャでチェックします。
ConsoleOne や iManager からリモートマネージャを起動してください。
左にある View Memory Config というメニューからメモリの状態を
チェックします。JAVA のランタイム版がないと、グラフが開けないのでインストールして
おきます。
文書の中では Pie Chart と書いてありますが、バージョンによってはグラフの形が
違うようです。
Fragmented Kernel Space
という項目をチェックしておきます。
起動直後はこの数値は限りなく０に近い値ですが、運用を始めるとこの数字が
少しずつ上がっていきます。一定の値で安定している場合は問題ないのですが、
数字が安定しない場合は次の対策を施します。
まず、NW65sp3/sp4 以降全てのパッチを適用します。
sp2 あたりはこの問題はきちんと解決していないようです。
NSS 関連のパッチも全部必要ですね。
1) TSAFS /CacheMemoryThreshold=1
これ、SMSSTART.NCF あたりに記述します。
2) set file cache maximum size = 107341824
これは autoexec.ncf に記述します。
3) C:\nwserver\nssstart.cfg
普通、このファイルはありません。名前を確認して次の記述をしてください。
/noncachebalance
/minbuffercachesize=153600
※ 102400 は 400Mb,153600 は 600Mb 確保する場合、
204000 は 800Mb 確保する場合
400Mb .. 800Mb までの値にセットしておくように書いてあります。
これで再起動すると安定するようです。
非番のエンジニア
2005年 08月 27日
ケーススタディ：全世界で８万人が使う GroupWise
Ａ社は全世界数百拠点、８万人の従業員を抱える巨大な多国籍製薬会社です。
-製薬業界-
ボクは子供の頃は体が弱かったのですが、大人になってからは、正露丸とバファリンと萬金胆さえあればいいほど元気になりました。だけど痔だの水虫だのの薬を買いにドラッグストアに行き、薬売り場で気が付いたことがあります。
製薬会社の多くが、食品、衛生、果ては化学、とんでもないところでは爆薬作っている会社が薬を作ったりしているわけなんですね。
逆に製薬会社の子会社に食品会社や衛生用品の会社があったりします。
つまり薬ってのはとんでもない所から薬ができたり、薬として開発しようとしたらそれが厚生省の申請を通らず、健康食品として販売しなければならないなどということもあります。
だから医薬品メーカーというのは巨大なメーカーから中小のメーカーまでさまざまなのです。
薬というのは病院では売っていません。これも二日酔いでバファリンくらいしか飲まなかったボクには知らなかったことです。
医者が処方箋を書く。その処方箋をもって、病院の周りにごっちょりある薬局で薬を買う。したがって、医薬のセールスマンというのは通常、営業とは言わずＭＲ（Medical Researcher）とか言われています。
一昔前であれば、ＭＲさんのお仕事ってのは医者にヨイショしてどうやって自社製品を処方箋に書かせるかがミッションのようにいわれていましたが、今や、病気、医療、医薬に通じた専門家として扱われており、正社員ではなく、専門業種として扱われています。
現代のＭＲは専門職であり、ほとんどどこの製薬会社でもオフィスに出勤するという業務形態をしないそうです。特に外資系医薬会社は、例えばアメリカのひとつの州に一人という場合もあり、オフィスで仕事をするという習慣はまずありえないそうです。
医薬の開発は、生物学、化学、医学、統計学など様々な知識を必要としており、日本で販売するためには分厚い資料を厚生省に提出して医薬品として認可が必要ですから、文章力も必要な大変な仕事なのです。まさに莫大な知識が必要であり中小の医薬会社は、自社製品開発の偶然の産物だったこれらの医薬品を大メーカーにブランドごと売却したり、医薬専門メーカーが偶然の産物としてできた家庭用品、ペット用医薬品、衛生用品、食品をブランドごと他のメーカーに売却したりすることが行われます。
選択と集中の結果です。
Ａ社の日本法人もそのような過程を経て、今や立派な「外資系医薬会社」となっています。
-GroupWise-
Ａ社は巨大な複合企業ですが、奇跡的にもひとつの運用ポリシーでシステムが運用されています。当然、国が異なれば、それぞれ方針が違い、企業としての現地法人が設立されるわけです。しかし関連する衛生用品や家庭用品も含めた総合企業として一つのディレクトリで運用されています。その８万人の従業員全てが GroupWisee を使っています。
一時、 GroupWise をはじめ Lotus Notes などのいわば「ファットなグループウェア」が流行した時期があります。今からちょうど１０年ほど前でしょうか。私は両方使ったことがあります。 GroupWise も Lotus Notes も非常によくできたソフトウェアでした。完成度では GroupWise は圧倒的です。しかし Lotus Notes の半完成品的なカスタマイズできる機能も魅力でした。
しかしこれらのグループウェアの流行はわずか数年で終わります。理由としては
- たかが会議室予約のために頻繁なバージョンアップと大きな労力を必要とすること
つまり、グループウェアの本質を「たかが会議室予約のシステム」としてしか理解できなかったＩＴ部門がその有効性を理解できなかった所は相次いでこれらの「ファットな」ソフトウェアをウェブベースの製品に置き換えています。
しかし、ウェブベースの製品のメリットとは単に
- ＩＴ部門が楽できる
という一言しかありません。ＩＴ部門の担当者は毎日オフィスで仕事をします。モバイルユーザではありません、だから全てがウェブで仕事できれば、セキュリティのリスクもないし業務はできるじゃないかと主張します。そもそも、そういうＩＴ部門では、ウィンドウズもオフィスソフトウェアもプリインストールが完了したＰＣを配布しているだけなのですけどね。
しかし、Ａ社のＭＲのような業種は必要な情報を簡単にラップトップコンピュータから取り出して幾つもの情報を医師に提供しなければならないのです。これは私のようなサービスエンジニアにとっても重要な要件です。
サーバールームのコンピュータとの通信時間はできるだけ短ければよい。答えを全てサーバールームから得るのではなく、手元にあって必要な加工が即座にできるということは重要なことなのです。電車での僅かな移動時間、飛行機の待ち合わせ時間、車を降りて目的地に歩いていく僅かな時間であっても、コンピュータを操作して必要な情報を引き出すことは、オフィス外で仕事をするビジネスパーソンにとっては貴重な時間なのです。
したがって、単にＩＴ部門が楽できるからという理由だけで、全ての電子メールシステムやグループミーティングをウェブベースにするというのは非常に馬鹿げた話なのです。モバイルオフィスのユーザにとっては常時ウェブシステムにアクセスできる条件で仕事をしているわけではありません。
私が以前いたオフィスもそうでした。顧客とミーティングしている最中に「オフィスにもどってからスケジュールを確認します」では笑って済まされない話にも関わらず、そうせざるを得ない不思議なセキュリティポリシーと運用があまりにも多すぎるのは、業務を全く知らないＩＴ部門の馬鹿馬鹿しいポリシーのせいです。
また、大抵のこれらのグループウェアは専用の暗号化されたデータベースを持つため、紛失、盗難による情報漏えいはまず聞いたことがありません。むしろ POP や HTML のSSL化されないテキストベースの通信の方がよほど危険性が高いと言えそうです。
これらのモバイルユーザにとっては移動しながら使えるグループウェアというのは「情報世界」そのものでライブラリなのです。Ａ社に限らず、 GroupWise を使っている顧客のエンドユーザは、ありとあらゆる重要情報を GroupWise に保存しています。多分 Notes を使っているところも似たようなものではないでしょうか。
-eDirectory と AD, Ldap-
eDirectory の最大の利点は分散型の Ldap サービスを構築できる点です。この点は Ldap を使った認証サービスの中では最高の性能と機能を提供します。本社と工場、数箇所の営業拠点といった数百人程度の規模では OpenLdap を使ったサービスは確かに安価に提供できる機能です。
しかし、数千人以上の規模と沢山の関連会社を抱えたＡ社のような複合的多国籍企業では OpenLdap での管理は不可能でしょう。通信の障害、サーバの性能、規模、耐障害性、どれをとっても eDirectory は必要な選択でした。
また、部門や商品ブランドの売却、買収を繰り返してきた巨大な医療用製薬産業では AD のような柔軟性のないディレクトリを構築する限り、スムーズな業務の継続性を維持できなかったはずです。部門の売却、買収というのは、付加価値のない単なるネーミングの売却、買収であり、付属する従業員や巨大なファイルライブラリを分割することはできません。
残念ながらＡ社でも製品ブランドを日本のある企業に売却したことがありましたが、相手がディレクトリサービスの効用を認めず、文字通り「ブランドの買収」に終わって、従業員もろともライブラリも破棄されたことがあります。後ろ向きな仕事でしたが、長いお付き合いがあったＩＴ担当者もレイオフされました。
Ａ社ではないのですが、私は一度、会社の分割に関わったことがありますが、この会社は eDirectory を使っていました。金曜の夜の会社の分割と共に、オフィスが移動したのですが、次の月曜日には移動したオフィスでエンドユーザが以前と全く変わりなく仕事ができたことは幸いでした。おそらく、ドメインを使っていた場合は、ユーザの削除と再構成、アクセス権の設定、ユーザの初期パスワードの設定とトレーニングのため、引越しに数ヶ月の準備を必要としたでしょう。
-伊勢丹と三越、住友と三井が合併するなんて数世代前の経営者には思いつかなかった発想なのです。しかし同じ程度のショッキングな出来事が当たり前のように国境を越えて行われるのが現代の医薬業界です。
また増え続ける情報リソースにユーザがスムーズにアクセスするにはシングルサインオンは必須の機能です。実際にユーザが使うＩＤとパスワードはひとつで十分です。
実際、ある日本の代表的なとある有名企業グループでは、ユーザ管理ポリシーが企業グループで統一されておらず、関連会社が必要な情報を得るため、本社のシステムにアクセスするＩＤとパスワードが関連会社ごとに統一されてませんでした。そのため社内のシステムだけではなく、子会社のシステムを使うにも６０日に一度変更されるパスワードポリシーが更に適用されていたため、全くエンドユーザが使わない（まぁず絶対使えない）システムを多額の費用を掛けて開発していました。当たり前のことですが、どうしても必要だというエンドユーザはＩＤとパスワードを大抵は付箋で管理しています。もっとも引き出しの中なのですが。
Ａ社では eDirectory と SAP の連動を行っているということで、各国、各子会社でユーザを作成すると、全自動で人事、グループウェア、必要なファイルアクセス、個人のポータルサイトが一瞬で出来上がります。まるで魔法のようなシステムでした。
しかも ZENworks が必要なアプリケーションテンプレートを自動配布します。また本社と研究所を移動するスタッフは大抵ＰＣを持ち運ばず、現場で余ったＰＣを使います。それでも GroupWise と eDirectory は必要な情報に容易にアクセスできる仕掛けを提供します。
しかし、欠点もあります。それは各システムのパスワード同期に時間がかかったりタイミング的にうまく行かないケースがあるということです。この点が現在のＩＴ部門の悩みです。
またあまりに eDirectory に頼りすぎているため、eDirectory の障害が発生すると、全世界的なトラブルに見舞われることがあります。特に日本は日付変更線のすぐ西側なので、私が真っ先にトラブルにやられるという経験をしました。たどたどしい英語でヘルプデスクに問い合わせると「それは今世界中で発生しているトラブルだから、まず、日本から対策してくれ」と手順を説明されました。
私が経験したトラブルはそれくらいです。
特に米国で××記念日で３連休があった翌日、つまり火曜日あたりは大体何かのトラブルを出していました。スキーマの変更がどこかでスタックすると eDirectory の同期が不完全な場合が発生します。何しろ世界中で数百台のシステムが分散稼動しているわけです。
Ａ社では、全世界的に Microsoft の AD の導入を実施しています。しかしその担当者の名前を聞いて、まず笑って安心しました。何しろ彼はＥＵとＡＰに eDirectory を導入した担当者だからです。おそらく、なんらかのアプリケーションを導入するためＡＤを必要としているのでしょう。あるいは、売却する部門の買収先がＡＤを必要としているからなのかも知れません。
２０００年問題の時はＡ社には Novell Inc. のエンジニアが常駐していたそうです。「オレのところで何かあったら、それは世界中で起こる事だからね」と担当者は笑っていましたが、海外にはＡ社の数倍の規模のディレクトリがある企業もあるそうです。当然、皆さんが良く知っている企業です。
Ａ社は製薬会社としては中位です。（それでも日本の大製薬会社の３倍以上の規模ですが）この規模はさらに大きな企業に買収される危険に晒されています。経営者がＩＴそのものと従業員が資産だと考えるのならばＡ社は簡単には買収されないでしょう。逆に同規模の企業との合併が過去にありましたが常に先進的なＡ社のディレクトリに飲み込まれています。
非番のエンジニア
-製薬業界-
ボクは子供の頃は体が弱かったのですが、大人になってからは、正露丸とバファリンと萬金胆さえあればいいほど元気になりました。だけど痔だの水虫だのの薬を買いにドラッグストアに行き、薬売り場で気が付いたことがあります。
製薬会社の多くが、食品、衛生、果ては化学、とんでもないところでは爆薬作っている会社が薬を作ったりしているわけなんですね。
逆に製薬会社の子会社に食品会社や衛生用品の会社があったりします。
つまり薬ってのはとんでもない所から薬ができたり、薬として開発しようとしたらそれが厚生省の申請を通らず、健康食品として販売しなければならないなどということもあります。
だから医薬品メーカーというのは巨大なメーカーから中小のメーカーまでさまざまなのです。
薬というのは病院では売っていません。これも二日酔いでバファリンくらいしか飲まなかったボクには知らなかったことです。
医者が処方箋を書く。その処方箋をもって、病院の周りにごっちょりある薬局で薬を買う。したがって、医薬のセールスマンというのは通常、営業とは言わずＭＲ（Medical Researcher）とか言われています。
一昔前であれば、ＭＲさんのお仕事ってのは医者にヨイショしてどうやって自社製品を処方箋に書かせるかがミッションのようにいわれていましたが、今や、病気、医療、医薬に通じた専門家として扱われており、正社員ではなく、専門業種として扱われています。
現代のＭＲは専門職であり、ほとんどどこの製薬会社でもオフィスに出勤するという業務形態をしないそうです。特に外資系医薬会社は、例えばアメリカのひとつの州に一人という場合もあり、オフィスで仕事をするという習慣はまずありえないそうです。
医薬の開発は、生物学、化学、医学、統計学など様々な知識を必要としており、日本で販売するためには分厚い資料を厚生省に提出して医薬品として認可が必要ですから、文章力も必要な大変な仕事なのです。まさに莫大な知識が必要であり中小の医薬会社は、自社製品開発の偶然の産物だったこれらの医薬品を大メーカーにブランドごと売却したり、医薬専門メーカーが偶然の産物としてできた家庭用品、ペット用医薬品、衛生用品、食品をブランドごと他のメーカーに売却したりすることが行われます。
選択と集中の結果です。
Ａ社の日本法人もそのような過程を経て、今や立派な「外資系医薬会社」となっています。
-GroupWise-
Ａ社は巨大な複合企業ですが、奇跡的にもひとつの運用ポリシーでシステムが運用されています。当然、国が異なれば、それぞれ方針が違い、企業としての現地法人が設立されるわけです。しかし関連する衛生用品や家庭用品も含めた総合企業として一つのディレクトリで運用されています。その８万人の従業員全てが GroupWisee を使っています。
一時、 GroupWise をはじめ Lotus Notes などのいわば「ファットなグループウェア」が流行した時期があります。今からちょうど１０年ほど前でしょうか。私は両方使ったことがあります。 GroupWise も Lotus Notes も非常によくできたソフトウェアでした。完成度では GroupWise は圧倒的です。しかし Lotus Notes の半完成品的なカスタマイズできる機能も魅力でした。
しかしこれらのグループウェアの流行はわずか数年で終わります。理由としては
- たかが会議室予約のために頻繁なバージョンアップと大きな労力を必要とすること
つまり、グループウェアの本質を「たかが会議室予約のシステム」としてしか理解できなかったＩＴ部門がその有効性を理解できなかった所は相次いでこれらの「ファットな」ソフトウェアをウェブベースの製品に置き換えています。
しかし、ウェブベースの製品のメリットとは単に
- ＩＴ部門が楽できる
という一言しかありません。ＩＴ部門の担当者は毎日オフィスで仕事をします。モバイルユーザではありません、だから全てがウェブで仕事できれば、セキュリティのリスクもないし業務はできるじゃないかと主張します。そもそも、そういうＩＴ部門では、ウィンドウズもオフィスソフトウェアもプリインストールが完了したＰＣを配布しているだけなのですけどね。
しかし、Ａ社のＭＲのような業種は必要な情報を簡単にラップトップコンピュータから取り出して幾つもの情報を医師に提供しなければならないのです。これは私のようなサービスエンジニアにとっても重要な要件です。
サーバールームのコンピュータとの通信時間はできるだけ短ければよい。答えを全てサーバールームから得るのではなく、手元にあって必要な加工が即座にできるということは重要なことなのです。電車での僅かな移動時間、飛行機の待ち合わせ時間、車を降りて目的地に歩いていく僅かな時間であっても、コンピュータを操作して必要な情報を引き出すことは、オフィス外で仕事をするビジネスパーソンにとっては貴重な時間なのです。
したがって、単にＩＴ部門が楽できるからという理由だけで、全ての電子メールシステムやグループミーティングをウェブベースにするというのは非常に馬鹿げた話なのです。モバイルオフィスのユーザにとっては常時ウェブシステムにアクセスできる条件で仕事をしているわけではありません。
私が以前いたオフィスもそうでした。顧客とミーティングしている最中に「オフィスにもどってからスケジュールを確認します」では笑って済まされない話にも関わらず、そうせざるを得ない不思議なセキュリティポリシーと運用があまりにも多すぎるのは、業務を全く知らないＩＴ部門の馬鹿馬鹿しいポリシーのせいです。
また、大抵のこれらのグループウェアは専用の暗号化されたデータベースを持つため、紛失、盗難による情報漏えいはまず聞いたことがありません。むしろ POP や HTML のSSL化されないテキストベースの通信の方がよほど危険性が高いと言えそうです。
これらのモバイルユーザにとっては移動しながら使えるグループウェアというのは「情報世界」そのものでライブラリなのです。Ａ社に限らず、 GroupWise を使っている顧客のエンドユーザは、ありとあらゆる重要情報を GroupWise に保存しています。多分 Notes を使っているところも似たようなものではないでしょうか。
-eDirectory と AD, Ldap-
eDirectory の最大の利点は分散型の Ldap サービスを構築できる点です。この点は Ldap を使った認証サービスの中では最高の性能と機能を提供します。本社と工場、数箇所の営業拠点といった数百人程度の規模では OpenLdap を使ったサービスは確かに安価に提供できる機能です。
しかし、数千人以上の規模と沢山の関連会社を抱えたＡ社のような複合的多国籍企業では OpenLdap での管理は不可能でしょう。通信の障害、サーバの性能、規模、耐障害性、どれをとっても eDirectory は必要な選択でした。
また、部門や商品ブランドの売却、買収を繰り返してきた巨大な医療用製薬産業では AD のような柔軟性のないディレクトリを構築する限り、スムーズな業務の継続性を維持できなかったはずです。部門の売却、買収というのは、付加価値のない単なるネーミングの売却、買収であり、付属する従業員や巨大なファイルライブラリを分割することはできません。
残念ながらＡ社でも製品ブランドを日本のある企業に売却したことがありましたが、相手がディレクトリサービスの効用を認めず、文字通り「ブランドの買収」に終わって、従業員もろともライブラリも破棄されたことがあります。後ろ向きな仕事でしたが、長いお付き合いがあったＩＴ担当者もレイオフされました。
Ａ社ではないのですが、私は一度、会社の分割に関わったことがありますが、この会社は eDirectory を使っていました。金曜の夜の会社の分割と共に、オフィスが移動したのですが、次の月曜日には移動したオフィスでエンドユーザが以前と全く変わりなく仕事ができたことは幸いでした。おそらく、ドメインを使っていた場合は、ユーザの削除と再構成、アクセス権の設定、ユーザの初期パスワードの設定とトレーニングのため、引越しに数ヶ月の準備を必要としたでしょう。
-伊勢丹と三越、住友と三井が合併するなんて数世代前の経営者には思いつかなかった発想なのです。しかし同じ程度のショッキングな出来事が当たり前のように国境を越えて行われるのが現代の医薬業界です。
また増え続ける情報リソースにユーザがスムーズにアクセスするにはシングルサインオンは必須の機能です。実際にユーザが使うＩＤとパスワードはひとつで十分です。
実際、ある日本の代表的なとある有名企業グループでは、ユーザ管理ポリシーが企業グループで統一されておらず、関連会社が必要な情報を得るため、本社のシステムにアクセスするＩＤとパスワードが関連会社ごとに統一されてませんでした。そのため社内のシステムだけではなく、子会社のシステムを使うにも６０日に一度変更されるパスワードポリシーが更に適用されていたため、全くエンドユーザが使わない（まぁず絶対使えない）システムを多額の費用を掛けて開発していました。当たり前のことですが、どうしても必要だというエンドユーザはＩＤとパスワードを大抵は付箋で管理しています。もっとも引き出しの中なのですが。
Ａ社では eDirectory と SAP の連動を行っているということで、各国、各子会社でユーザを作成すると、全自動で人事、グループウェア、必要なファイルアクセス、個人のポータルサイトが一瞬で出来上がります。まるで魔法のようなシステムでした。
しかも ZENworks が必要なアプリケーションテンプレートを自動配布します。また本社と研究所を移動するスタッフは大抵ＰＣを持ち運ばず、現場で余ったＰＣを使います。それでも GroupWise と eDirectory は必要な情報に容易にアクセスできる仕掛けを提供します。
しかし、欠点もあります。それは各システムのパスワード同期に時間がかかったりタイミング的にうまく行かないケースがあるということです。この点が現在のＩＴ部門の悩みです。
またあまりに eDirectory に頼りすぎているため、eDirectory の障害が発生すると、全世界的なトラブルに見舞われることがあります。特に日本は日付変更線のすぐ西側なので、私が真っ先にトラブルにやられるという経験をしました。たどたどしい英語でヘルプデスクに問い合わせると「それは今世界中で発生しているトラブルだから、まず、日本から対策してくれ」と手順を説明されました。
私が経験したトラブルはそれくらいです。
特に米国で××記念日で３連休があった翌日、つまり火曜日あたりは大体何かのトラブルを出していました。スキーマの変更がどこかでスタックすると eDirectory の同期が不完全な場合が発生します。何しろ世界中で数百台のシステムが分散稼動しているわけです。
Ａ社では、全世界的に Microsoft の AD の導入を実施しています。しかしその担当者の名前を聞いて、まず笑って安心しました。何しろ彼はＥＵとＡＰに eDirectory を導入した担当者だからです。おそらく、なんらかのアプリケーションを導入するためＡＤを必要としているのでしょう。あるいは、売却する部門の買収先がＡＤを必要としているからなのかも知れません。
２０００年問題の時はＡ社には Novell Inc. のエンジニアが常駐していたそうです。「オレのところで何かあったら、それは世界中で起こる事だからね」と担当者は笑っていましたが、海外にはＡ社の数倍の規模のディレクトリがある企業もあるそうです。当然、皆さんが良く知っている企業です。
Ａ社は製薬会社としては中位です。（それでも日本の大製薬会社の３倍以上の規模ですが）この規模はさらに大きな企業に買収される危険に晒されています。経営者がＩＴそのものと従業員が資産だと考えるのならばＡ社は簡単には買収されないでしょう。逆に同規模の企業との合併が過去にありましたが常に先進的なＡ社のディレクトリに飲み込まれています。
非番のエンジニア
#
by islandcenter
| 2005-08-27 21:11
| GroupWise
|
Comments(0)
