Hebikuzure's Tech Memo

2010年10月30日

基本認証の HTTP サーバーから Office ドキュメントを開けない

Filed under: Microsoft Office — hebikuzure @ 11:03 午後

MSKB 212563
You cannot open Office file types directly from a server that supports only Basic authentication over a non-SSL connection
http://support.microsoft.com/kb/2123563/en-us


Web サーバーに Office ドキュメントを置いてクライアントの Office アプリケーションで開く、というシステムはイントラネットでよく見られる。またドキュメントを閲覧したり編集したりできるユーザーを限定するため、HTTP サーバーに基本認証をかけている場合もあるだろう。
ところがこうしたシステムで今まで使っていた Office 2003 (またはそれ以前のバージョン) をOffice 2007 または Office 2010 にアップグレードすると、Web サーバー上の Office ドキュメントを開くのに失敗してしまうようになる場合がある。Office ドキュメントへのリンクをクリックしても何も起こらなかったり、あるいはドキュメントを開くアプリケーションは起動するのにドキュメントが表示されない、などの現象が起きる。
この現象はいくつかの原因が重なっているのだが、根本的にはセキュリティーの強化によって発生している。これについて解説しているのが上記のサポート技術情報 212563 だ。

まず Office アプリケーションが Web サーバーから直接ドキュメントを開く場合の挙動が Office 2003 以前と Office 2007 以降では変わっている。Office 2003 まででは Web サーバー上のドキュメントを開く際、Office のコンポーネント (MSDAIPP : Microsoft Data Access Internet Publishing Provider) のみを使って Web サーバーにアクセスしていたが、Office 2007 以降ではこれに加えて Windows のコンポーネント (WebCleint サービス) も利用するように仕様が変更されている。

さて現在サポートされているバージョンの Windows の WebClient サービスでは、セキュリティー上の理由で HTTP 接続での基本認証 (Basic 認証) が無効になっている。これは基本認証では資格情報 (ユーザー名とパスワード) が平文で送信されるので、通信自体も暗号化されない HTTP 接続では資格情報が容易に盗聴されるからだ。(関連情報 : マイクロソフト サポート技術情報 841215)
そのため Office 2003 以前のバージョンから Office 2007 以降のバージョンにアップグレードすると、基本認証のかかった HTTP サーバーからドキュメントを開くことができなくなる。
また Office 2010 では Office のコンポーネントでも同様の理由で HTTP 接続での基本認証が無効になっている。そのため Office 2010 では Windows の WebClient サービスだけでなく、Office コンポーネントについても HTTP 接続での基本認証を有効にしなければならない。

つまり Office のバージョンによって以下の作業が必要になる。

  • Office 2007 の場合 : Windows の WebClient サービスで HTTP 接続の基本認証を有効にする
  • Office 2010 の場合 : Windows の WebClient サービスで HTTP 接続の基本認証を有効にする + Office の HTTP 接続の基本認証を有効にする

技術情報に記載されているように、Windows の WebClient で HTTP 接続の基本認証を有効にする方法、Office 2010 で HTTP 接続の基本認証を有効にする方法はそれぞれ以下の通りだ。

WebClient サービスで HTTP 接続の基本認証を有効にする

以下のレジストリ値を作成し、Windows を再起動する。

  • Windows XP / Windows Server 2003

キー : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
名前 : UseBasicAuth
種類 : REG_DWORD
データ : 1 (0 にすると HTTP 接続の基本認証は無効)

  • Windows Vista / Windows 7

キー : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
名前 : BasicAuthLevel
種類 : REG_DWORD
データ : 2 (0 にすると HTTP/HTTPS 共に基本認証無効、1 にすると HTTPS で基本認証有効、2 にすると HTTP/HTTPS 共に基本認証有効)

Office 2010 で HTTP 接続の基本認証を有効にする

以下のレジストリ値を作成し、Windows を再起動する。

キー : HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Internet
名前 : BasicAuthLevel
種類 : REG_DWORD
データ : 2 (0 にすると HTTP/HTTPS 共に基本認証無効、1 にすると HTTPS で基本認証有効、2 にすると HTTP/HTTPS 共に基本認証有効)

いずれもレジストリを編集する事になるので、レジストリのバックアップの作成を行った上で、慎重に作業する必要があるのを忘れずに。

2010年8月2日

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

Filed under: Microsoft Office — hebikuzure @ 10:08 午前

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 歳の息子ももっとこの疑問を持つと良いのですが….

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

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

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

2010年5月31日

バグはなぜ無くならないのか – Microsoft Office チームの Blog から

Filed under: Microsoft Office — hebikuzure @ 8:04 午前

Why doesn’t Office just fix all of the bugs before they ship it
http://blogs.technet.com/b/office_sustained_engineering/archive/2008/12/12/why-doesn-t-office-just-fix-all-of-the-bugs-before-they-ship-it.aspx


以前にもどこかで紹介したような気がするが、Office Sustained Engineering という Office 開発チームのブログで (ずいぶん以前の記事なのだけど) どうして Office 製品のバグが出荷前に無くせないのかについて論じたとても興味深い記事がある。この記事「Why doesn’t Office just fix all of the bugs before they ship it」を訳してみた。

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


なぜ Office は出荷前にすべてのバグが修正されないのか

この記事は、我々が次期バージョンの Office をどのように開発し公開するのかに関する良く寄せられる質問について説明する、関連した 3 つのブログ記事の最初のものです。特に、以下の話題について説明する予定です。

  1. なぜ Office は出荷前にすべてのバグが修正されないのか ?
  2. ‘トリアージ’ の プロセス (どのバグを修正するのかを決定するために行われます) はどのように機能しているのか ?
  3. Office を製品として維持するために今のようなやり方が選択されているのは何故か ?

パート1: なぜ Office は出荷前にすべてのバグが修正されないのか ?

まず明確な事から始めましょう。我々は全てのバグを見つけてはいません。私は周囲に比べて最も聡明ではありませんがそう認識していますし、皆さんにとってもそれは大きな驚きではないでしょう。しかしそれは何故でしょうか。我々の努力が足りないからでない事は保証できます。またバグを見つけるためのプロセスに問題があるからでない事も確かです。我々の開発プロセスではその初日に開発者とテスターが組み合わされ、バグの発見と修正はプロセス全体を通じて他の何よりも優先されます。

実際、根性のあるバグ潰し屋の誰にたずねても、バグを見つけるのは困難だと言うでしょう。幸い我々のテスターはことのほか聡明です。彼らは “簡単な” バグのほとんどすべてを見つけ、さらに “難しい” バグの大部分も見つけ出します。開発チームが予期しないような機能の使い方が必要であるようなバグでさえ白日の下に晒します。しかし何百万人もの利用者が自分の仕事を達成するため想像もつかないような幅広いオプションを設定して Office を利用しています。その結果、我々の製品は、我々が想像もつかないような使い方をされるのです。たとえば我々は新しいスマートなハンマーを作ったつもりだとしても、利用者は結局それを配膳道具のように使い、我々にどうしてこんなフォークを設計したのかと尋ねるのです。シナリオは無限にあり、それを一つずつすべて予測するのはまったく不可能です。これはどんなに優れたテスターがいても同じです。

これに関連して、ソフトウェアのバグは世の中のその他の物に比べて確認しにくいという問題もあります。あるユーザーにとって欠陥のある動作と思える動作が、別のユーザーにとっては完璧で期待通りの動作になります。そのため実際の動作が “意図されたもの” であるかどうかについて開発チームのメンバー間で数えきれないような議論が戦わされることになります。それぞれに観点が異なるための意見の相違もよくあります。我々は、以前のバージョンやベータ バージョン、数多くのユーザー訪問から得られるデータを使い、私たちの見解が最も一般的な利用者の見方となるよう最善を尽くしています。結局の所、そうした視点の表明は気まぐれなもので (心理的に誰かにとっての至宝が別の人にはゴミであるように)、我々の結論も常に正しいとは限りません。

最終的に、すべてのバグは生き残るための巧妙な手口を持っているというのが真実でしょう。バグを潰しても、復活する方法を見つけ出すのです。さらに悪いことに、彼らは異なった、より面倒なバグに変化するのです。ソフトウェアの開発チームでは、これをリグレッションと呼んでいます。バグを修正するにはコードの変更が必須です (私はこの点について明確に理解しています)。コードの変更は別のシナリオでの新しいバグの潜在的な原因になります。リグレッションによっては修正した元のバグより性質が悪い場合もあります。これは ‘アリが良いか、シロアリが良いか’ という問題に似ています。一方は不愉快な邪魔者ですが、もう一方は災厄の原因です。一般的に言えば、災厄を避ける方が良いでしょう。

災厄を避けるようにするということが、我々の製品がバグのある状態で出荷されるもう一つ理由です。これは直感に反するように思えますが、ありていに言って、リグレッションの現実の結果、もし我々がすべてのバグを修正しようとすれば、永久に出荷できないでしょう。これは災厄と言えるでしょう。このように我々は常にこの現実に直面しており、我々が高い品質の製品を期日通りに出荷しようとすると、非常に困難な決断が必要となるのです。

例えば、仮に (実際にはそうではありませんが) 我々がすべてのバグを修正できるとして、それは我々が行うべき最も重要なことでしょうか? またそれは利用者にとって、新機能のメリットを享受できるのが 20 年に一度になるのより重要でしょうか? OEM や ISV やその他の関係者が我々の出荷予定日を計算できるのより重要でしょうか? 競争力のある機能に適切なタイミングで対応することより重要でしょうか? 常に考慮が必要な多数のトレードオフが存在しているのです。

いくつかのトレードオフは明確で、例えば全体的な品質は出荷予定日より重要です。品質に問題があれば、出荷日を引き延ばすでしょう。これは以前にあったことです (覚えていらっしゃるでしょう)。しかし決定しなければならないことの大部分はそれほど明白ではありません。一見明確ではないバグの修正と予定通りの出荷のトレードオフは、告知済みの出荷日が近づくにつれて決断が難しくなります。

こうしたプロセスの実例はこの問題を示すのに役立つでしょう。Office 2007 のリリース後、あるユーザーが多数の問題 (“ゴミ” であり、“お宝” ではありません) を見つけました。特に、Excel ファイルへの複数のリンクを含む PowerPoint プレゼンテーションを開く際、それぞれのリンクを更新する新しい方式 (より多くのメタデータを追跡しています) が原因で、非常に長い時間が掛かることが分かりました。一般的に言えば、これは多数の人に影響を与えるものではありませんが、このユーザーのプレゼンテーションの特性上、これは大きな問題でした。彼らはこのバグを hotfix として修正するようリクエストしました。我々はその修正をしたのですが、少し後になって、そのバグを修正すると外部リンクを含むプレゼンテーションで VBA コードを実行する際にクラッシュしてしまうという新しいバグが発生することが分かりました。このバグは非常に性質が悪く、一つの修正により他のより多くのシナリオが危険にさらされるため、我々は元の修正を破棄し、ユーザーにはパフォーマンスの問題で適切な回避策を取れるよう協力しました。

我々の目標は個々のどの問題についても、可変的な要素に留意しつつ最良の決断を行うことです。こうした目標を達成するため、すべてのバグについて修正をするのとしないのとどちらが最善かを決める ‘トリアージ’ を行っています。この決定を、一貫性をもってうまく行っていくのはいかにも複雑なプロセスです。これにはどのような変更についても賛成または反対の立場から議論を重ねている、多数の経験豊富な開発チーム メンバーの洞察力が必要とされます。多くのの場合、私たちは正しい選択をしています。しかし時に間違いを犯し、一つのバグを修正することでより悪い – 検知できないかもしれない – バグを招いてしまうこともあります。場合により我々はバグの本質を真に捉えているユーザーのシナリオを正しく理解できず、本来修正すべきバグを修正しないと決めてしまうこともあります。このように確かに完全とは言えませんが、トリアージのプロセスは優れたものであり、このブログのシリーズのパート 2 のトピックになるでしょう。

まとめると以下のようになります。我々は品質に問題があれば出荷日を変更しますが、告知済みの出荷日に間に合うようにできる限りの努力をします。また我々はどの Office のリリースでも顕著なユーザーへの影響があるバグはないことを期待しています。しかし残念ながら我々はユーザーが見つけられるバグのすべてを見つけることができず、また一部のバグについて実際にはユーザーに多大な問題を引き起こすものであるのに軽視するという、誤ったトリアージをしてしまうこともあります。これら二つの現実の結果、我々は世界規模の ‘アフター サービス’ 組織となり、過去にリリースした製品に必要なアップデートを提供するため懸命に働いています。こうした努力により、ユーザーに最良の価値ある提案が提供できることを望んでいます。この続きをお待ちください…

投稿: Friday, December 12, 2008 11:09 PM by Dave B [msft]

2010年5月9日

Excel の計算範囲に結合セルが含まれている場合に意図しない結果になる

Filed under: Microsoft Office — hebikuzure @ 11:12 午前

The result of a calculation that uses the data in a merged cell does not match the result that is expected based on the visible data in the merged cell in Excel 2000, in Excel 2002, in Excel 2003, in Office Excel 2007, or in Excel 2010
http://support.microsoft.com/kb/983435/en-us


Excel では複数のセルを結合して複数行/複数列にまたがるセルを作成する事ができる。
Excel 2007 以降の場合は結合したいセルを選択して [ホーム] タブにある [セルを結合して中央揃え] ボタンをクリックすれば作成できるし、また [セルの書式設定] – [配置] タブの [セルを結合する] にチェックを入れても良い。


図1: A2、B2、C2 の3セルが結合されている

結合されているセルが合計などの計算の範囲に含まれている場合、結合セルへのデータの入力方法によっては意図しない結果になってしまうう場合がある。
下の図では、A3 と A4 にはその隣に表示されている数式が入力されており、その結果としてどちらも「10」が表示されている。


図2: 意図通りの計算結果

ところが以下のように同じ見かけ、同じ数式なのに計算結果が「20」になってしまう場合がある。


図3: 意図しない計算結果

これは以下の手順で再現できる。

  1. A1D55 を入力しておく
  2. A3=SUM(A2,B2,C2,D2)A4=A2+B2+C2+D2の数式を入力する
  3. A2B2C2 を選択して [セルを結合して中央揃え] ボタンをクリックする
  4. A1 を右クリックして [コピー] を選択する
  5. 結合したセルを右クリックして [形式を選択して結合] を選択する
  6. ダイアログで [数式] を選択して [OK] をクリックする


図4: [形式を選択して貼り付け] で [数式] を選択する

なぜこうなるのか、その理由は以下の通りだ。

  • セルを結合するとセルが全体で一つになったように見えるが、実際には個々のセルは Excel の内部には保持されていて、書式として隣のセルと結合した状態であるという情報を持っている。結合セルに表示されるのは結合した元の範囲の左上隅のセルに入っていたデータだけだが、実際にはそれ以外の元のセルもデータを持つ事ができる。
  • ただしこれでは分かりにくいので、セルを結合する際に結合範囲の左上隅以外のセルの値はクリアされる動作になっている。また他のセルをコピーして結合セルに貼り付ける場合も、値は左上隅のセルにだけコピーされる動作になっている。
  • ところが上記の操作のように [形式を選択して貼り付け] で [数式] を貼り付けると、左上隅のセル (上記の例では A2) だけでなく他のセル (上記の例では B2 と C2) にも数式がコピーされる。上記の例では数式として A1 に入っている値 5 が A2、B2、C2 の 3 つのセルにコピーされる。
  • そのために、A3 や A4 の数式での計算結果は表示されている数値の合計 10 ではなく、表示されていない B2 と C2 の値も含む 20 になる。

この動作についてはサポート技術情報で Excel の不具合とされているが、修正プログラムなどは無い。もし結合セルを含む集計を行っているシートがあるなら、念のため計算結果が不正になっていないか確認した方が良いだろう。

2009年12月9日

Excel 2007 でセルをクリックすると複数セルが選択されてしまう

Filed under: Microsoft Office — hebikuzure @ 8:38 午前

Excel 2007 の ページ レイアウト ビューでシートを特定の位置に表示させた場合に、任意の 1 つのセルをクリックすると複数のセルが選択される
http://support.microsoft.com/kb/978386


Excel 2007 でページ レイアウト ビューを使って表示している際、上下のページ境界が表示されており、かつ下側のページのヘッダー欄が表示されていない状態だと、セルをクリックした際にクリックしたセルの下にある複数のセルが意図せず同時に選択されてしまう、という不具合がある。 なんともバカバカしいバグで、サポート技術情報に書かれている通りの手順で簡単に再現する。ページ レイアウト ビューは Excel 2007 での新機能なのだから、このモードでのテストが不足していたとしか言いようがない。

回避策はページ レイアウト モードから別のモードに切り替えるか、スクロールして表示位置を変えること。下側のページのヘッダーが表示されるまで少しスクロールすれば回避するので、ページ レイアウト モードを使う場合はこれで回避するのが良さそうだ。

2009年8月13日

Office 2007 のアンインストール失敗を予防する

Filed under: Microsoft Office — hebikuzure @ 2:40 午後

MSKB 973005
Windows Vista Service Pack 2 をインストールしたコンピューターで 2007 Microsoft Office system 製品のアンインストールを実行する時、メモ帳および特定の常駐プログラムが起動しているとアンインストールが中断する
http://support.microsoft.com/kb/973005


Windows Vista SP2 のコンピューターにインストールされている Office 2007 をアンインストールしようとすると、「Microsoft SetUp Boot Strapper は動作を停止しました」というエラー メッセージが表示され、インストールに失敗する場合がある。この問題が起きると、それ移行 Office の修復やアンインストールができなくなってしまう。
問題の原因はサポート技術情報に書かれているように、メモ帳などのアプリケーションや常駐プログラムによって Office IME 2007 が読み込まれていて、そのモジュールが使用中と判断された場合のエラー処理が正しく行えないためである。
この現象が発生した場合の回復方法は技術情報に記載されているように Office 2007 をインストール メディアから再インストールしてもう一度アンインストールする、または手動でアンインストールされずに残っているファイルとレジストリを削除する必要がある。

どちらの回復方法にせよ面倒なので、そもそもこの現象が発生しないようにする事が望ましい。その方法は技術情報にも触れられているが、システム構成 (msconfig) を使って Windows をクリーン ブートした状態でアンインストールを開始するのが良い。

MSKB 929135
Windows Vista でクリーン ブートを実行して問題のトラブルシューティングを行う方法
http://support.microsoft.com/kb/929135/ja/

2009年7月18日

Excel 2007 でシート保護のパスワードが 16 文字以上設定できない

Filed under: Microsoft Office — hebikuzure @ 10:24 午前

MSKB 958081
Excel 2007 でシートの保護のパスワードを 16 文字以上設定すると、パスワードの再入力で 15 文字までしか入力できない場合がある
http://support.microsoft.com/kb/958081/ja


Excel 2007 で Excel 97-2003 形式のブックを編集し、シート保護のパスワードを設定しようとすると、パスワードの再入力 (確認のための入力) で 16 文字以上の入力ができず、結果として 16 文字以上の長さのパスワードを設定する事ができない。

Excel 97-2003 形式のブックを開いている状態で無ければ (Excel 2007 形式のブックを編集しているか、新規ブックをまだ保存していない場合) 長いパスワードでも問題無く設定できる。Excel 2003 以前ではこの問題は起きない。また Excel 2003 以前のバージョンで既に 16 文字以上のシート保護パスワードが設定されているブックを Excel 2007 で開いたり、パスワードを入力して保護を解除する事は問題無くできる。

何だかなあ….という感じの不具合だが、機能が全く使えない訳でもなく、「シート保護のパスワード」という機能の重要性も極端に大きくなく、回避策もあり….という事だから、すぐに修正される事も無いのだろう。

長いパスの Word ファイルを保存できない

Filed under: Microsoft Office — hebikuzure @ 9:46 午前

MSKB 953157
長い名前のフォルダなどパスの長い場所に保存した Word 2007 ファイルを開いた場合、保存ダイアログ ボックスが表示されず、保存できない
http://support.microsoft.com/kb/953157/ja


Word 2007 で保存先のフォルダのパスやファイル名が長い文書を開いて編集すると、上書き保存も別名保存もできなくなってしまう場合がある。この現象が発生すると、上書き保存を行っても実際には保存の動作が行われず、また [名前を付けて保存] を選択してもファイル保存のダイアログが表示されない。そのため編集中の文書を保存する事ができなくなってしまう。
エラー メッセージはいずれの場合も表示されないため、保存されていないと気付かないで編集した結果を失ってしまう事になる、非常に困った不具合だ。

技術情報にも書かれているように、以下の修正プログラムで不具合が修正されている。

MSKB 969960
Description of the 2007 Office system hotfix package (Vbe6.msp): April 30, 2009
http://support.microsoft.com/kb/969960/en-us

さて 969960 の修正プログラムの内容を見ると、Word 自体の更新ではなく Vbe6.dll の更新、つまり Visual Basic for Application の更新になっている。と言う事はこの現象の直接の原因は既定で読み込まれるアドインにあるのかもしれない。手元環境の Word 2007 で調べると、既定でインストールされ新規文書でも最初から有効なアドインは「原稿用紙アドイン」だけなので、これが怪しい???
この現象に遭遇して、修正プログラムのインストールがすぐにできない場合は「原稿用紙アドイン」を無効にしてみると良いかもしれない。もしそれでうまく回避できたらぜひ教えてほしい。

2009年6月28日

Office で使用するカスタム ActiveX コントロールが更新できない

Filed under: Microsoft Office — hebikuzure @ 6:44 午前

MSKB 185473
PRB: Changes to Custom ActiveX Control Are Not Used
http://support.microsoft.com/kb/185473/en-us


Word、Excel や Access などの Office アプリケーションで VBAやフォームを組み合わせたカスタム アプリケーションを作成する場合、Office のネイティブな機能だけでは実現できない動作を実装するためにカスタム ActiveX を作成して利用する事がある。こうしたカスタム ActiveX をバージョンアップしてクライアントに再配布しても、Office アプリケーション内で使用される ActiveX が更新されない場合がある。
この技術情報ではこうしたカスタム ActiveX が更新されない現象について解説している。

この現象が発生する理由は、Office がカスタム ActiveX を利用する方法にある。カスタム ActiveX コントロールが Office ドキュメントに挿入される場合、コントロールのオブジェクト タイプ ライブラリと拡張オブジェクト メンバーについての情報を保存する二つのファイル ( .twd と .exd ) が作成される。ActiveX の本体が更新されても、これらのファイルが既に存在する場合自動的に更新されないため、Office から見ると更新された ActiveX のメソッドやプロパティが反映されず、意図どおりに機能しない。

そのため、カスタム ActiveX コントロールを更新した場合は Temp フォルダにある .twd ファイルと .exd ファイルを手動で削除し、再作成させる必要がある。この手順についてはサポート技術情報に記載があるので、その通りに実行すればよい。

2009年6月7日

特定の 2007 Microsoft Office system アプリケーションを起動するたびに “Microsoft Office Live を開始する” アドイン ウィンドウが表示される

Filed under: Microsoft Office — hebikuzure @ 12:03 午後

MSKB 969144
特定の 2007 Microsoft Office system アプリケーションを起動するたびに “Microsoft Office Live を開始する” アドイン ウィンドウが表示される
http://support.microsoft.com/kb/969144/ja


Microsoft Office Live アドインをインストールすると、次に Office アプリケーションを起動した時に「Microsoft Office Live を開始する」が表示され、Windows Live ID との関連付けなどの設定が促される。このダイアログでは「次回からこのメッセージを表示しない」チェックボックスが既定で有効になっていて、[続行] で設定を完了した場合も [閉じる] で閉じてしまった場合も次回からダイアログが表示されないのが正しい動作となる。ところがこのチェックボックスの設定を記憶するレジストリ キーが正しく作られない場合があって、「次回からこのメッセージを表示しない」を有効にしているのに Office アプリケーションの起動時に毎回ダイアログが表示される場合がある。この問題とその修正方法を解説しているのがサポート技術情報 969144 である。

修正方法としては技術情報の中ほどにある [Fix it] ボタンから修正用プログラムをダウンロードして実行すれば良い。技術情報は英語版 (日本語版は例によって訳のわからない機械翻訳) だが、Fix it プログラムは日本語版でも正常に機能する。
または以下のレジストリ キーを手動で作成してから Office アプリケーションを起動し、「次回からこのメッセージを表示しない」を有効にしてダイアログを閉じ、アプリケーションも終了する。

HKEY_CURRENT_USER\Software\Microsoft\OfficeLive

かなり数も増えてきて日本語化も徐々に進んでいる Fix it ツールだが、英語版サイトではさらに進んだ Microsoft Automated Troubleshooting Services が提供開始されている。こちらでは Fix it のように決められた問題の修正をするだけでなく、問題の診断とそれに応じた修正が行えるようになっている (診断だけ行い修正をするかどうかはユーザーが選択できるオプションもある)。また Fix it が MIS ベースの実行プログラムであるのに対して、こちらは ActiveX コントロールとして実行される。

mats

(追記 : 2009/10/13 技術情報 969144 が日本語化されていたので、一部修正)

« Newer PostsOlder Posts »

WordPress.com Blog.

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