Hebikuzure's Tech Memo

2010年8月30日

「Internet Explorer 9 の誕生を祝う会 (ベータ版)」開催決定

Filed under: Internet Explorer — hebikuzure @ 8:02 AM

一昨日の記事でご案内した「Internet Explorer 9 の誕生を祝う会 (ベータ版)」の開催が決定し、参加募集を開始しました。

参加希望の方は http://welcomeie9.org/ から申し込み手続きを行ってください。会場の都合であまり多くの方にご参加いただけないので、ぜひ、という方はお早めにお願いします。

2010年8月28日

IE9 Beta 9/15 (日本時間9/16) リリース

Filed under: Internet Explorer — hebikuzure @ 4:45 AM

表題のように IE9 のベータ版がリリースされる事が報じられています

さて、IE と言えば IE6 のお葬式が行われたことも記憶に新しいと思います。お葬式があるのだから誕生を祝ってもいいじゃないか、という事で、只今 IE9 のリリース (誕生) を祝福するイベントを企画中です。そしてベータ版のリリースに合わせて、誕生祝福イベントもベータ版を開催するべく準備しています。

8/30 には詳細が発表できる予定で、このブログでもご案内をいたします。ぜひご注目ください。(会場の都合であまり定員が多くできないと思われます。参加希望の方はお早めに…)

2010年8月25日

Tech Ed Japan 2010

Filed under: Windows Info — hebikuzure @ 1:42 PM

こちらにも書きましたが、Microsoft Tech Ed Japan 2010 でライトニング トークをさせていただきました。
お世話になった皆さん、励ましや感想の声をおかけいただいた皆さん、ありがとうございました。

2010年8月13日

Active Directory 環境でアンチウイルス ソフトに起因するトラブルを回避する

Filed under: Windows トラブル — hebikuzure @ 7:15 AM

Virus scanning recommendations for Enterprise computers that are running currently supported versions of Windows
http://support.microsoft.com/kb/822158/en-us


Active Directory は Windows Server と Windows クライアントで構成されたネットワークで、各コンピュータとそれにログオンするユーザーを管理運用する優れたソリューションですが、その機能の実現のために特定のファイルやレジストリが利用されています。そのためそうしたファイルやレジストリへのアクセスに支障が出ると、コンピュータやユーザーの設定が正しく構成されなかったり、安定性に問題が生じる場合があります。
一方、アンチウイルス ソフトウェアは今日のコンピュータ セキュリティーの重要な要素であり、実運用環境にあるコンピュータのすべてにインストールし動作させる事が望ましいのですが、多くのアンチウイルス ソフトウェアでは「リアルタイム監視」などの機能で、他のプログラム (プロセス) がファイルを開く動作をフックして、他のプログラム (プロセス) より先にファイルの内容が安全であるかスキャンする動作をしています。こうした動作の結果として、Active Directory の機能でファイルへのアクセス (レジストリ アクセスのためのレジストリ ファイルのアクセスも含む) が行われる際、アンチウイルス ソフトウェアが同じファイルにアクセスする動作が発生し、アンチウイルス ソフトウェアの動作速度やタイミングによっては Active Directory の機能でファイルへのアクセスが失敗してしまう場合が考えられます。
実際にこうした問題が生じる場合があるため、一時的な回避策として、また Active Directory の動作上の問題の原因がアンチウイルス ソフトウェアにあるのかどうかを切り分けるためのガイドラインとして、サポート技術情報が公開されています。

Virus scanning recommendations for Enterprise computers that are running currently supported versions of Windows
http://support.microsoft.com/kb/822158/en-us
現在サポートされているバージョンの Windows を実行しているエンタープライズ コンピューターでウイルス スキャンを行う場合の推奨事項
http://support.microsoft.com/kb/822158/ja

特定のフォルダやファイルをアンチウイルス ソフトウェアのスキャンから除外する事で現象が回避できるなら、原因はアンチウイルス ソフトウェアの動作にあると考えられる。技術情報にも書かれているが、スキャンから除外する事はセキュリティー レベルを低下させる事につながる。そのため回避策としては一時的な採用に留め、アンチウイルス ソフトウェアのベンダーに相談する (サポートを求める) 事が技術情報でも推奨されている。

技術情報の日本語版が機械翻訳なので、以下に簡単に概要を記す。あくまでも「概要」なので、実環境に適用する場合は原文とそこからリンクされている関連情報を熟読した上で、利用者自身の判断とリスクで行う事。

注意事項
ファイルをスキャンから除外する場合、拡張子のみで除外をしていしない事。同じ拡張子のファイルは他の用途にも利用されており、それらすべてを除外する事は危険である。可能な限りフォルダ名 (パス) とファイル名で除外するファイルを限定すること。

Windows クライアントと Windows サーバーの場合

以下のフォルダ/ファイルを除外する

  • Windpws Update と自動更新のファイル
    • %windir%\SoftwareDistribution\Datastore フォルダの Datastore.edb
    • %windir%\SoftwareDistribution\Datastore\Logs フォルダ、特に Res*.log、Res*.jrs、Edb.chk、Tmp.edb
  • Windows のセキュリティー ファイル
    • %windir%\Security\Database フォルダの *.edb、*.sdb、*.log、*.chk、*.jrs
  • グループ ポリシーの関連ファイル
    • %allusersprofile% フォルダの NTUser.pol
    • %Systemroot%\System32\GroupPolicy フォルダの Registry.pol

Windows Server 2008 R2, Windows Server 2008, Windows Server 2003, Windows 2000 ドメイン コントローラーの場合

以下のフォルダ/ファイルを除外する

  • ACtive Directory とそれに関連したファイル
    • HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\DSA Database File で示されているフォルダ (既定は %windir%\Ntds) の Ntds.dit と Ntds.pat
    • HKEY_LOCAL_MACHINE\System\CurrentControl\SetServices\NTDS\Parameters\Database Log Files Path で示されているフォルダ (既定は%windir%\Ntds) の EDB*.log、Res*.log、Res*.jrs、Ntds.pat
    • HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\DSA Working Directory で示されているフォルダの Temp.edb、Edb.chk
  • SYSVOL のファイル
    • HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Working Directory で示されているフォルダ (既定は %windir%\Ntfrs) の edb.chk、Ntfrs.jdb、*.log
    • HKEY_LOCAL_MACHINE\System\Currentcontrolset\Services\Ntfrs\Parameters\DB Log File Directory で示されているフォルダ (既定は %windir%\Ntfrs) の Eedb*.log、Edb*.jrs (Windows Server 2008 および Windows Server 2008 R2 の場合) と JetLogEdb*.jrs (Windows Server 2008 および Windows Server 2008 R2 の場合)
    • HKEY_LOCAL_MACHINE\System\Currentcontrolset\Services\NtFrs\Parameters\Replica Sets\GUID\Replica Set Stage で示されているフォルダ (既定は %systemroot%\Sysvol\Staging areas) の Nntfrs_cmp*.*
    • %systemroot%\SysvolSysvol フォルダの以下のファイル
      • *.adm
      • *.admx
      • *.adml
      • Registry.pol
      • *.aas
      • *.inf
      • Fdeploy.inf
      • Scripts.ini
      • *.ins
      • Oscfilter.ini
  • FSR プレインストール フォルダ (Replica_root\DO_NOT_REMOVE_NtFrs_PreInstall_Directory) とそのサブ フォルダ内のの Ntfrs*.*
  • HKEY_LOCAL_MACHINE\System\Currentcontrolset\Services\DFSR\Parameters\Replication Groups\GUID\Replica Set Configuration File=Path > で示されている場所 (既定は %systemdrive%\System Volume Information\DFSR) にある以下の DFSR データベースと作業ファイル
    • $db_normal$
    • FileIDTable_2
    • SimilarityTable_2
    • *.xml
    • $db_dirty$
    • Dfsr.db
    • Fsr.chk
    • *.frx
    • *.log
    • Fsr*.jrs
    • Tmp.edb
  • FRS または DFSR で複製されるSYSVOL のファイル
  • DHCP のファイル
    • %systemroot%\System32\DHCP フォルダの以下のファイル
      • *.mdb
      • *.pat
      • *.log
      • *.chk
      • *.edb

Windows Server 2008, Windows Server 2003, and Windows 2000ドメイン コントローラーの場合

  • DNS のファイル
    • %systemroot%\System32\Dns フォルダの *.log、*.dns、BOOT
  • WINS のファイル
    • %systemroot%\System32\Wins フォルダの *.chk、*.log、*.mdb

Hyper-V を利用している場合

以下のサポート技術情報を参照の事

Virtual machines are missing in the Hyper-V Manager Console or when you create or start a virtual machine, you receive one of the following error codes: “0x800704C8”, “0x80070037” or “0x800703E3”
http://support.microsoft.com/kb/961804/

繰り返しになるが、実環境に適用する場合は原文とそこからリンクされている関連情報を熟読した上で、利用者自身の判断とリスクで適用して欲しい。

2011/12/16 追記 KB822158 が日本語化されているのに気付いたのでその部分を修正しました。

2010年8月2日

バグのトリアージ – それってどういう事?

Filed under: Microsoft Office — hebikuzure @ 10:08 AM

Triaging bugs – what’s that all about?
http://blogs.technet.com/b/office_sustained_engineering/archive/2009/02/12/triaging-bugs-what-s-that-all-about.aspx


この記事は、この Blog の 5/31 の「バグはなぜ無くならないのか – Microsoft Office チームの Blog から」の続きとなる、Office Sustained Engineering Blog の記事「Triaging bugs – what’s that all about?」の私訳です。この続きの記事「What does it mean to be a world class servicing organization?」も時間を見つけて訳して掲載する予定です。Microsoft のバグ修正のプロセスに興味がある方は、ぜひ前の記事と併せてご一読ください。

以下の文章は Office Sustained Engineering の 2009 年 2 月 12 日 の記事 「Triaging bugs – what’s that all about?」 を hebikuzure が私的に試訳したものです。翻訳については Microsoft Corporation およびマイクロソフト株式会社とは無関係に hebikuzure が公開情報に基づき独自に行ったものであり、この文書の内容についての文責は公開者である hebikuzure にあります。翻訳の内容および技術的内容については正確を期すよう十分な注意を払っておりますが、誤りや不正確な部分が含まれている可能性がありますので、本文書を利用される際には原文も併せてご確認ください。


バグのトリアージ – それってどういう事?

Dave B [msft] 12 Feb 2009 1:58 PM

困難な決定を下すということは (覚悟してください) … 困難な作業です。当たり前でしょう! 下す判断のすべてが容易なものであってほしいのですが、私は困難な判断を下すのなら「三人寄れば文殊の知恵」だと信じている人間です。もちろんあまりに多くの人が関わっているのなら、数だけが問題ではありませんから返ってくる声を減らす可能性はあります。これは実に考え方の問題です。より独創的な考え方ができれば、より良い判断ができるようになります。私は悪い判断ではなく良い判断をしたいのです。私の父は常に私には明確なことに対する驚異的な理解力があると言っていました – それは私にとって素敵なことだと思っていました。

以前の投稿で、次期バージョンの Office を出荷する際に行わなければならない困難な決断の性質について述べました。それではそうした決断はどのように行われているのかとお思いなら、この記事が役立つでしょう。私の書き出しでご想像のように、私たちは幅広い視点を含むグループによって行うのが最善だと信じています。

個人的には、トリアージという用語はテレビ番組の “M*A*S*H” で初めて知りました。誰かが見ていた訳ではないですが、正直に言うとこの番組から人生についてより多くの事を学びました。皆さんがご存じのように、トリアージという言葉は典型的には医学の用語で、「多数の患者の診療の順番を決めるため、病人や怪我人に緊急度を割り当てる事」です (私ではなく辞書がそう言っています)。「私たちはいったい何をしたらいいんだ?」という疑問への答えがそれだと私は考えました。

トリアージの考え方にグループ ディスカッションは必然的には含まれませんが、私たちにとってはそれが全てです。繰り返しになりますが、それは単なる数の問題ではありません。洞察力への情熱をもたらすような経験を有する人々が一堂に会するという点が問題なのです。ここに誰をグループに加えるかを考える視点があります。

第一に、機能を開発したチーム – デザイナー、開発者、テスターです。このグループは、その機能に最も努力を注いだ人々です。機能は彼らの言わば子供です。この人たちは機能が完璧である事を願っています。誰も自分の子供が厄介者だとは言われたくないですから。このグループは特に客観的になる事が難しいかもしれませんが、コードと、そのコードの変更に伴う潜在的なトレード オフについて最も広範な知識を持っているグループでもあります。彼らはトリアージで最も上位のメンバーである必要はありませんが、Office の文化において、私たちが新鮮さを失わないようにするためには新人の際立った声が重要です。言うならばこのプロセスにおけるチップクリップ (ポテトチップの袋の口を閉じるクリップ) のようなものです。

次に、カスタマー サポートの専門家 – 私たちの顧客と直に接した仕事をしており、顧客が私たちの製品から何を望んでいるのかしっかりと把握している人たちです。彼らは業界の中で誰よりエンタープライズ ソフトウェアについて理解しており、私たちが顧客のニーズをリストの最上位に保つように気遣っています。その他の専門家も、国際的マーケット、コンテンツ、セキュリティー、アクセシビリティー、その他のいつくかの分野についての特定の問題に対応して、グループに召集されます。

最後に、ソフトウェアの出荷についての広範な経験を持つマネージャーのグループです。彼らは何度も高品質な製品をタイムリーに出荷した体験を有してして、トレードオフについて理解する際に豊富な経験をもたらしてくれます。トリアージ チームはOffice のすべての製品のマネージャーと上級エンジニアで構成されており、一部の人は 20 年以上も Office についての仕事をしています。彼らはこのプロセスに貴重な、円熟した視点をもたらします。

間違いが無いように言っておくと、異なった視点とは異なった意見を意味します。トリアージ ミーティングは、皆が元気になるクンバヤ (訳註 : Kumbaya、歌の名前) を歌うためにキャンプファイヤーの周りに集い、友達同士が抱き合うような大人数のグループとはまったく違う事を保証できます。どちらかと言えば、それは (準備はいいですか?) 自分の見方が正しいと信じている情熱的で博識な人々を魅了する、言葉による格闘試合のようなものです。あなたと違い私はそうした罠におちてしまいそうですが…。結果として、ほぼ間違いなく見解の不一致が生じます。見解の不一致は議論を生じさせ (白熱した論争とも言えますが)、時には議論が激しくなり時間もかかるため、全体のプロセスに価値があるのか疑問に思われるかもしれません。毎回毎回トリアージのプロセスにどれだけの意味があるのか、私たちは気にかけています。複数の考え方は良い決定を下すのに必要であり、よい決定は製品をより良く完成させるのに必要です。大抵の場合、このプロセスは良い議論を 1 回か 2 回 (か、100 回) 行いますが、プロセスの最後では製品の品質に帰結するそうした議論がどれだけ貴重であったか、皆が理解する事になるのです。

トリアージでの決定に魔法の公式はありません。そこには問題の深刻度や、問題の発生するシナリオがどの位出現するのかなど考慮すべき多数の事柄がありますが、これらを一つの公式に還元しようとしてもそれは機能しません。どの問題も特定の顧客のシナリオがその背後にあり、それは人手をかけて問題を評価し決定を行う事が必要な、意思決定のレベルに関係しています。公式に依るのではなく、最良の判断では常に性急な対応に飛びつく前に、優れた質問が得られるまで議論を煮詰めているのです。出荷が近づくと、トリアージ グループは全ての問題と提案されている変更について注目し、最も基本的でかつ重要な問いかけをするのです。「それには意味があるのだろうか?」 私の 9 歳の息子ももっとこの疑問を持つと良いのですが….

毎回のトリアージの議論/論争で舞い上がった埃が治まると、結論はいつも同じになっています。トリアージを行ったグループは「私たちはいったい何をしたらいいんだ?」という疑問に答える際、最終結論が最も理に叶っているものだと信じているでしょう。それは、個々のトリアージのメンバーは、他のメンバーの考え方が特定の問題に対してより有効だと信じるであろう事を意味しています。本当の話、これはなかなかに困難な事なのですが、しかしトリアージ グループは私たちが私たち自身とその考え方について見通す手助けをしてくれます。それは愉快な課題である必要はありませんが、疑い無く必要な課題なのです。

トリアージのプロセスは常に正しい決定を保証してくれるのでしょうか? いいえ、そうではありません。しかし正しい決定を行う確率を劇的に向上する事は保証できます。私たちは、どの決定の一つをとってもそれが数百万の顧客に影響を与えるという事を知っているので、どのリリースの過程においてもトリアージに多大な工数を費やすでしょう。それには間違いなくその価値がありますが、私はそれを毎回毎回そうしなくても良い事を嬉しく思っています。おや、ちょっと待ってください。

製品が出荷されると、トリアージは日常当たり前の事になります。実際、顧客が評価できるプレ リリース版への変更ではなく顧客が利用している、市場に出回っている製品への変更になりますから、意思決定にはより熱心に取り込みます。顧客の実装している手法がバグの存在を前提としており、バグが起きないとうまく動作しないため、問題を修正すると顧客の手法を失敗させてしまうという事例を見てきました。そうした事情もあるので、私たちは世界でも第一級のアフター サービス組織になる事に尽力しています。その理由と方法が私の次回のブログの題材です。引き続きご注目ください。

WordPress.com で無料サイトやブログを作成.

%d人のブロガーが「いいね」をつけました。