１２月２日に NASA から発表があったものは、なんとなく肩すかしを食らったような内容だったという報道が多かったようですね。

宇宙人の存在を NASA が認めれば面白かったのですが。

モノ湖で発見された生命体ですが、実は重大な意味があるのです。

人間の遺伝子を構成する重要な物質に「リン」があります。

「ヒ素」はこのリンに分子構造が非常に似ていて、人間の体内に入ると、リンのような振る舞いをしてDNAの破壊へと導きます。

そのため、人間と同一系統を持つ地球上の生物にとって、ヒ素は非常に有害な物質なのです。

このDNAレベルで拒絶しなければならない物質を取り込んでも、なお生きられる生命体というものが発見されたのです。

それは一体どんな生物なのでしょう。

明らかに「今まで発見された地球上の生物とは系統が異なるもの」であり、人類とは根本的に違うのです。

つまり、地球上には２系統の生物がいるという事です。

現在の生命が誕生する以前に、別の系統の生物がいたのかもしれません。

今回の発見はその生命の生き残りなのでしょうか。

また、古代に隕石などで他の惑星から飛んできたのかもしれません。

もしくは、私たちの生命が他の惑星から来たのかもしれません。

いずれにしろ、宇宙には人間とは異なる系統が存在するという事が判明した訳です。しかもそれが地球上で発見されました。

その意味するところは、異なる系統の生物が確実に存在しているという事であり、生命が生息可能と推測できる範囲が、今までの考えよりも大幅に広がったという事なのです。

そういった意味では「地球外生命体は(ほぼ確実に)存在する」という会見でもあるのです。

ヒソで生きられるから何なのよ。

という一言では片づけられない出来事だったのです。

私が普段使っているPCを再インストールしました。

MobileMe と Exchange Outlook を同期するには x86 の Office でなければ動作せず、x64 をアンインストールしてもうまく動かなかったからです。

クリーンインストールで Windows Server 2008 R2 に Offilce Professional Plus x86 をインストールするのです。

もちろん、ソフトウエアの開発環境も。

今までの感覚として、急いでも１日半ほどかかると思っていました。

普通のエンジニアなら数日は必要でしょう。

ところが、夕方には終わってしまいました。

はて?

解せない私は、その理由を考えてみました。

結論はなんとクラウドにあったのです。

今まではすべての開発環境を１台のPCにぶち込んで、開発する毎に様々な設定を行っていたのですが、今は違うのです。

重要な業務は機械を別に設けていますし、何より Hyper-V や VMWare で業務毎に専用環境を作って開発しているのです。

結局のところ、私の機械には簡単な検証用のツールと、Visual studio 2010 と、Office 製品群と各種ブラウザがあれば足りてしまう。

メールも Exchange Server なのでデータを抜き出す必要もないし、予定表などは Apple の MobileMe でシンクさせているし。

所謂、移行がない・・・・。

すぐに必要なドキュメントは iPad に入っているし。

うーん、これは・・クラウドだ。

結局のところ、何気に私はクラウドの最先端で仕事をこなしている事に気が付きました。

しまった・・・MS と Apple と Google の術中に。。。

整数を前提とします。

1+1 を 5 にするには、何を足したら良いでしょう。

小学校低学年でもできる計算ですよね。

しかしながら、答えはいくつかあるのです。

�@ 1+1(+1+1+1)=5　

�A 1+1(+1+2)=5　

�B 1+1(+3)=5

２人しか人がいないときの成果を５人分にするには、３人足せばいいわけですから、これは �@ に該当します。

３人分の仕事をこなせる優秀な人材を１人投入すれば �B に該当します。

�A はその中間ですね。

工期が短いときは �B を選択するのが良いのですが、リスクの高い選択となります。

パワー３の人間が故障したらそれまでですものね。

�@ は様々な状況に対応できる構成ですが、それぞれに対しての情報伝達に時間がかかる分、伝言ゲームではないにしろ、意思統一が難しい局面もあるでしょう。

主に組織的な動き求められる場所では �@ が選択されており、欠点を補うため、情報の伝達に関してはことさら厳しく定められています。

�B を選択するのは、主に結果が重要な場所になります。そのため、長期的な動きよりも短期的な動きに多くみられます。

多くの組織では �@ が大枠となり、各セクションでは �A ないし �B が選択されているのではないでしょうか。

組織内でコンピュータを利用する上で、コミュニケーションを司るシステムが重要視されているのは、こういった背景があるからなのです。

SharePoint いいですよ、SharePoint。

予想外に予想外の理由で・・・

社内 Exchange Server と IIS のポータルサーバーが壊れました。

物理的にではなく論理的にです。

IIS ポータルサーバーは「ソフトンハウス」のバックアップ用サーバーで、常に稼働させているのですが、たまに開発用に利用します。

それが悪い方に作用して、１日のうちに2つのサーバーが不具合を起こし、双方ともに再インストールとなってしました。

直すよりインストールの方が早いし・・・、

もともと社内の Exchange Server は検証用という事もあり、安定性を無視しし、かなり無理な設定をトライしています。

なので今回は少々苦労しました。

最近忙しくて疲れてますしね。

認証の関係上、Exchange Server には IIS の開発環境で ASP を入れてはいけないのですが、IIS が壊れたのと同時だったため、何気に今までの癖でインストールしてしまい・・・。

Exchange の管理コンソールって、IIS の Power Shell フォルダへ接続して動くため、認証は Kerberos だけで、NTLM はいかんのです。

おかげで２度もインストールを行う事になってしまいました。

幸いな事に、Exchange Server 2010 は以前のバージョンに比べ障害に強いので、メールボックスの復旧は比較的簡単。

その点は妙に感心してしまいました。

Exchange Server のメモリは 4G 以上を推奨となっていますが、実際に動かすと、最低 6G は必要で、安定させるには 7G 以上を推奨します。

１００人単位なら 10G 以上は必要でしょう。

週末復旧させたので、今週も休みがありませんでした。

１０月末から１日も休暇をとってない・・。

法律的に良いのかって？

社長には労働基準法なんて適用されないのです。

久しぶりですね。。。

なのに自分的メモを書いたりしてごめんなさい。

今日は Exchange Server 2010 SP1 で機械を壊してしまったとき、データベースのバックアップをどのようにして新しい機械に移すかという、つまり自分的なメモです。

1.故障した機械のデータベースフォルダへ移動、ESEUTIL を実行しデータベースをコミットする。

ESEUTIL /R E01

成功しない場合は以下の修復を行う。

Eseutil /MH "XXXXXXX.edb"
Eseutil /R E01 /I /d

それでも解決しない場合は

Eseutil /p XXXXXXX.edb

何度か組み合わせを変えて実行したりすると、直ったりします。

2.新しい機械でデータベースを作成する。

例えば、SDC_MAILBOX というDBを C:\DataBase\SDC_MAILBOX フォルダに作ります。

New-MailboxDatabase -Name SDC_MAILBOX -Server SDC32 -EdbFilePath C:\DataBase\SDC_MAILBOX\SDC_MAILBOX.edb -LogFolderPath C:\DataBase\SDC_MAILBOX

3.作成した新しいデータベースをリストア可能な属性にセットする。

Set-MailboxDatabase SDC_MAILBOX -AllowFileRestore:$true

4.作成した新しいデータベースのフォルダに、edbやlog、カタログ等をすべてコピーする。

このとき、.edbファイルの名称を古いデータベースの名称から新しいデータベースの名称に変えるのを忘れずに。

5.新しいデータベースをマウントする。

Mount-Database SDC_MAILBOX

マウントに成功すれば終わったも同然です。

6.ユーザーアカウントのパスを新しいデータベースへ変更する。

古いメールボックスデータベースは "Mailbox Database" とします。

データベースが既に存在しなくともパスのみを変更しますので、元の実体DBがなくとも大丈夫です。

Get-Mailbox -Database "Mailbox Database" |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'}| Set-Mailbox -Database SDC_MAILBOX

これで完了です。

壊れたという事は、間違いなくデータベースはクリーンシャットダウンしていませんので、最初に ESEUTIL が必要になります。

ESEUTIL /R E01 などは必ず修復するターゲットの edb があるフォルダに移動して行ってください。E01 はデータベースの数に応じて、E01、E02･･･と番号が増えていますので適切に変えてください。

以上、自分的メモでした。

まあ、それにしても Exchange 2010 SP1 になって、やっとある程度安心して使えるようになった気がします。

データベースのコピーを複数の Server が持つ事もできますし、以前よりずっと信頼感が増しました。

うちの部下の信頼感もバージョンアップしてほ(ry