パスワードを忘れた？ アカウント作成
Close
352006 story
マイクロソフト

8月10日公開予定のWindowsセキュリティ更新プログラムはインストールに数時間かかるかも 94

ストーリー by hylom
これを口実にサボりましょう 部門より

あるAnonymous Coward 曰く、

8月10日の公開が予定されているWindowsのセキュリティ更新プログラムは、PCのスペックによってはインストールに数時間かかる場合があるとのことだ。（ITpro、日本のセキュリティチーム）。

これによると、8月のセキュリティパッチに.NET Frameworkの更新プログラムが含まれており、.Netのパッチはコンパイルを伴うために時間がかかるとのこと。同社は更新の途中で電源を切らないよう呼びかけている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

8月10日公開予定のWindowsセキュリティ更新プログラムはインストールに数時間かかるかも More

  • Ｑ．なんで8/10か (スコア:5, おもしろおかしい)

    by gesaku (7381) on 2011年08月08日 18時13分 (#1999573)

    Ａ．
    　１．実際のインストールはお盆時期だからちょうど仕事が休みで問題ない
    　２．お盆時期ならピーク電力も少しは低いだろうとの判断
    　３．コミケに行こうとする鯖缶を妨害

    ＃カタログCD-ROMが動かなくなったら大ピンチgesaku

  • このコンパイルって (スコア:3, おもしろおかしい)

    by Anonymous Coward on 2011年08月08日 17時50分 (#1999559)

    自動インストールの場合、シャットダウン時か起動時なのかが気になります。

    「帰ろうとしたら、PCが落ちないんだけど」
    「朝来たら、いつまでたっても起動しないんだけど」

    どっちにせよ、呼び出し喰らうんですけどね。

  • それでも電源を切っちゃった人のための・・・ (スコア:3, おもしろおかしい)

    by Anonymous Coward on 2011年08月08日 20時18分 (#1999636)
    対策プログラムが9月に配布される、に1票。

  • .NET Runtime Optimization Serviceが非常にうざい (スコア:2, 参考になる)

    by Anonymous Coward on 2011年08月08日 23時31分 (#1999746)

    .NET Frameworkがなければ動かないアプリがある、そこまではいい。
    が、.NET Runtime Optimization Serviceは停止しておいても.NETを用いるアプリケーションの起動に時間が掛かる程度で、特段の問題がない。
    それどころか自動起動にしておくと、リソースを食い潰している場合があるので意図的にOFFにしている環境も少なくないだろう。

    なので.NET Runtime Optimization Serviceなんて停止しておくわけだが、.NET Frameworkの修正が入る度に起動しやがる。
    しかも更新の頻度が高い。１つのアップデートで２つの.NET Frameworkの修正パッケージがリリースされる場合すらある。

    うざいことこの上ない。

    • msi パッケージの修正プログラム (msp) をインストールすると、その修正の対象となっているプログラムのインストール初期値が復元される仕組みだからですね。
      • Office の修正をインストールすると Office IME が既定の IME になる
      • Outlook の修正をインストールすると Outlook が既定のメール プログラムになる

      とかと同じ動作でしょう。これは Windows インストーラーの根本的な動作原理なのでほぼ未来永劫変わらないかと....

      シェア
      親コメント

  • 急ぎの用事があるとき (スコア:1)

    by Led (7726) on 2011年08月08日 17時39分 (#1999551) 日記

    納期とか、〆切とかが迫っているときに何か不幸な理由で再起動しようとすると・・・ああ恐ろしい。

    Windows Updateを避けつつ再起動する方法って何かないでしょうかね？

  • 先月末頃に Windows 7 を起動したら更新プログラムのお知らせがあったのでぽちっと再起動したところ、一部の MPEG-2 TS ファイルを Windows Media Player 再生した時に音が鳴らなくなる不具合が発生してしまって「何があった」と驚いてしまいました。ちょうど地上波停止の前後だったこともあった上に、その日からとある公共放送の地デジ番組の見た目の総ビットレートがすべて 20 Mbps とかになっていたりとか、とあるソフトの鍵期限が地上波停止日に設定されていたりとか様々な現象が重なっていて原因の追及に時間がかかってしまったのですが、なんのことはない、Windows 7 SP1 が自動更新でインストールされてしまったのが原因でした。6 月 1 日から SP1 も自動インストールされるようになっていたんですねえ。この時もそういえばインストールにやけに時間がかかっていた。

    しかし、SP1 がリリースされてから数ヶ月が経過しているのに、この再生バグは未だに修正されていないらしい。どうにかしてほしいものです。

    --
    Hiroki (REO) Kashiwazaki
  • それはそれで肝心なときにサービスがメンテ中とかありそうだけど。

    これ地味にネトブク潰しだよな、Atom搭載機とかでこんなパッチ当てるとか考えただけでゾッとするな。
    こんな事ばかりしてるとChromeOSが普及するかはともかく、ポストPC時代の到来が早まってMS困るんじゃないのかね。

  • 今更言うようなこと？ (スコア:1, 参考になる)

    by Anonymous Coward on 2011年08月08日 21時30分 (#1999681)

    ngenのことなら今までの.NETのパッチの度に実行されてたわけで。
    今回に限ってこんな発表をするのはどういう意図があるんだろうか？

    • Re:今更言うようなこと？ (スコア:1, 参考になる)

      by Anonymous Coward on 2011年08月08日 23時01分 (#1999733)

      公式のセキュリティチームブログのネタが拡散しているだけだと思う。
      .NET Framework セキュリティ更新プログラムのインストールに関する注意 - 日本のセキュリティチーム - Site Home - TechNet Blogs [technet.com]

      いちお断り書きあるんだけどね。

      ※この情報は、今月の更新プログラムに限った話ではなく、.NET Framework 更新プログラムに関する一般的な注意点です。過去、更新プログラムのインストール中に電源を切ってしまい、その後トラブルに遭遇したという報告を多く確認しているため、トラブル予防のため注意喚起をしています。

      シェア
      親コメント

      • Re:今更言うようなこと？ (スコア:2, おもしろおかしい)

        by firewheel (31280) on 2011年08月09日 0時34分 (#1999771)

        ＞過去、更新プログラムのインストール中に電源を切ってしまい、その後トラブルに遭遇したという
        ＞報告を多く確認しているため、トラブル予防のため注意喚起をしています。

        既知の問題なら、注意喚起だけで終わるのではなく、根本原因である
        修正プログラムを修正するパッチを配布してだな。。。アレ？

        ＃結論：高度に複雑化した.NETはバグと見分けが付かない。

        シェア
        親コメント

        • Re:今更言うようなこと？ (スコア:3, すばらしい洞察)

          by Hebikuzure (489) on 2011年08月09日 10時38分 (#1999879) ホームページ 日記
          Windows Update などの更新のインストール中に電源を切ってしまうと不完全な状態になってトラブルが起きるというのは .NET Framework の修正プログラムに限らずどの修正プログラムでも同じ (だし、別に Windows に限った話じゃないような気もする)。「電源を切らないでください」ってメッセージが表示されるにも関わらず電源を強制断してしまう人が少なからずいて、そのためエラーが出るとか挙動がおかしいとか最悪起動できないとかのトラブルが発生するのは以前からよくある事でした。
          で、特に .NET Framework の修正はインストールに時間がかかるので今月の修正にあわせて改めて注意しているだけなんでしょうけど、なんでこんなに大騒ぎする必要があるんでしょうね。そもそもインストール中に電源を切っちゃうというのはプログラム側の問題じゃなく明らかなオペレーション ミスで、プログラム側の修正でどうにかなる問題じゃないように思いますし、トラブルが起きてしまった後の対処もどの程度不完全になっているかまちまちなので単純な「修正プログラム」のようなもので修復するのは難しいでしょう。
          根本的な対策としては
          • .NET Framework の修正プログラムのインストール所要時間を短縮する
            -> 別のコメントにもありますが .NET Framework の動作原理に関わりそうで難しいかも。それに時間を短くしてもそれでも電源を切っちゃう短気な人は少なからず居そう。
          • インストールが完全でなかったらロールバックするような仕掛けを組み込む
            -> 既に Windows 自体のアップグレードやサービスパックでは機能している仕込みなので不可能ではなさそうだけど、ロールバック動作自体の安定性や、そのためのコスト(消費リソースや時間など)などの問題もあるかも

          でしょうかね。なかなか難しそうです。

          でも .NET Framework の不完全なインストールが起きると、その回復は結構手間のかかる作業になって、サポート コストがばかにならないですね。なんとかしたいのはマイクロソフトも同じでしょう。

          シェア
          親コメント

          • Re:今更言うようなこと？ (スコア:3, 興味深い)

            by muta_g (29083) on 2011年08月09日 12時51分 (#1999958) 日記
            "「電源を切らないでください」ってメッセージが表示されるにも関わらず電源を強制断してしまう人が少なからずいて "
            ですが、普通の間隔ですとWindowsのアップデートがかかった状態で1時間以上も電源が落ちなかったらアップデートに失敗していると
            判断してしまわないでしょうか？(少なくとも自分はそう判断しかねない)

            大事なのは、時間がかかるアップデートがある場合は"今回のアップデートは時間がかかる"旨を通知して
            さらにプログレスバーなので、きちんとアップデートが進んでいることを表示することではないでしょうか？
            シェア
            親コメント

            • Re:今更言うようなこと？ (スコア:1)

              by Stealth (5277) on 2011年08月09日 15時09分 (#2000065)

              "「電源を切らないでください」ってメッセージが表示されるにも関わらず電源を強制断してしまう人が少なからずいて "
              ですが、普通の間隔ですとWindowsのアップデートがかかった状態で1時間以上も電源が落ちなかったらアップデートに失敗していると
              判断してしまわないでしょうか？(少なくとも自分はそう判断しかねない)

              あなたのマシンがどの位の性能があるのかが分かりませんし、どのような環境であるのか分かる人はあなただけですので (エクスペリエンスインデックススコアはここでは参考になりません) 1 時間程度で十分かどうかは簡単に判断できる人はいないでしょう。
              なお、それなりに低くはない性能のマシン (Win7/x64) でも、少し前の時にアホみたいに時間がかかった時は 6 時間以上放置してたと思います。

              # この環境はβも含めていろんなものが入って(る|た)ので普通とはかけ離れた環境だと思いますが……。

              大事なのは、時間がかかるアップデートがある場合は"今回のアップデートは時間がかかる"旨を通知して
              さらにプログレスバーなので、きちんとアップデートが進んでいることを表示することではないでしょうか？

              Microsoft Update を有効にしていると降ってくる Visual Studio の SP 適用だけで平気で一時間以上かかったりしますし、SQL Server オンラインブックの更新なんかだと単体で GB over で降ってくる、なんてのも普通にあります。
              「Office を入れて SP を適用後、さらに Office を DVD から一部上書きで追加インストールした」なんて場合でも適切に更新を行うようスキャンしまくる訳で、そうした時間もバカになりません。(更新をチェックした時にやたらと時間がかかるのはこのスキャンです)
              基本的には「時間がかからない方が稀」と考える方がいいでしょうね。

              また、再起動が必要な更新適用はシステムの終了時や起動時に行いますが、Windows 7 では 3 段階のステージでそれぞれパーセンテージを出しています。(1/3、2/3、3/3 + それぞれ 0 ～ 100%)
              あなたが求めている事は既に行われている事ではありませんか?

              シェア
              親コメント
              • なるほど、1時間も待てば十分だろうと思っていた自分の認識が甘かったようですね
                Visual StudioやSQL Serverなどは自分の環境では入っていなかったので、これまでは運が良かったようです。
                あとOfficeも入っていないので…。

                >また、再起動が必要な更新適用はシステムの終了時や起動時に行いますが、Windows 7 では 3 段階のステージでそれぞれパーセンテージを出しています。 > (1/3、2/3、3/3 + それぞれ 0 ～ 100%)
                上記はすみません。自分が良く見ていなかったのにいちゃもんをつけていたみたいです。
                思い込みで書いては駄目ですね。
                シェア
                親コメント

              • Re:今更言うようなこと？ (スコア:1)

                by Stealth (5277) on 2011年08月09日 15時54分 (#2000084)

                普通は六時間とかは「これ絶対おかしいだろ」のレベルだとは私も思います。しかし一時間くらいだと意外に環境次第では普通にありうるよ、下手すると数時間コースとかもたまにはあるよ、という世界もある事を認識いただけたら、「あー、じゃあ更新適用は(寝る|出かける)前かな」という戦術を考える、という形で付き合えるようになるのではないでしょうか。

                # 手元の開発用デスクトップ環境はβ含めて MS 製品がどっぷり入っているので、大量に更新が来ると絨毯爆撃にしか見えないのです……。

                シェア
                親コメント
              • 専門家向けの OS ではないのだから、
                『表示されるメッセージは素直に信じてその通りに従う』
                というだけで無用なトラブルは避けられるのですがねえ。

                再起動後しばらくしてからゆっくりとバックグラウンドで動作させる

                バックグラウンド実行中にユーザーが何をやるかわからないので、それはそれで別のトラブルを招く可能性も。そしたら今度は「重要なシステムファイルの更新なんだからバックグラウンドじゃなく再起動時に安全に処理できるようにすべきだ」って言われるだけのような気もします。
                トラブルはどうしても大きな声で主張されるので目立ちますが、昔 (XP 以前とか) に比べれば、しょうもないトラブルは減っていると思いますけど。

                シェア
                親コメント

              • だからウィンドウズ向けアップデートとしては、
                ・10分程度で終わるように軽く作る。
                ・どうしても長時間かかる処理ははパッチ修正後、再起動後しばらくしてからゆっくりとバックグラウンドで動作させる
                ・長時間かかる処理は途中で中断できるか、電源OFF対策をしておく。（難しいけど）

                と、さらっと言ってますけど実現できているものは存在しないように思いますが。
                UNIX 系でも現在実行中のプロセスにパッチを当てるようなことはできませんから、利用者に一旦アプリケーションを終了させないと更新が適用された状態のプログラムに更新できません。

                ちなみにロックされているファイルに対する更新などを適用 (終了時 + 再起動時のセットで適用) 以外の部分については普通にバックグランドで適用しますし、.NET でも再起動不要で更新してしまう場合もあります。
                更新を適用する際に色々とアプリケーションを落としてロックされない状況にしておくと再起動が回避できる場合もありますね。

                今日の更新、それなりの数が来ていた割には再起動前にほとんど適用してしまっていたようで、終了 + 起動時で 10 分程度しか待たされなかったので拍子抜けしたのですが。

                シェア
                親コメント

  • 世界中の電気をそうして無駄にするというわけか……

  • 電力消費が急増しそう (スコア:0)

    by Anonymous Coward on 2011年08月08日 17時33分 (#1999549)
    PC電力がどれくらい影響あるか確認できるかも

  • の～みそ コネコネ コンパイル！(T/O) (スコア:0)

    by Anonymous Coward on 2011年08月08日 18時17分 (#1999577)
    (T/O)

  • なんで、コンパイルなの？ (スコア:0)

    by Anonymous Coward on 2011年08月08日 19時02分 (#1999601)

    なんで、コンパイルなんでしょう？

    バイナリー配布出来ない理由は

    ・バイナリー配布しちゃダメってっていうフリーソースを含んでいる？
    ・動作環境に依存する？
    ・？

    • Re:なんで、コンパイルなの？ (スコア:3, 参考になる)

      by Anonymous Coward on 2011年08月08日 22時24分 (#1999705)

      .NETのプログラムはMSIL形式を環境に合わせて最適化しつつJITコンパイルして実行する、というのが基本です。
      .NETにはJITコンパイルの結果をアセンブリとしてキャッシュする機能があり、その利便性をより高めるために、インストーラを使用するとインストール時にキャッシュを生成する補助機能が存在します。
      MSILはEXEファイルやDLLファイルなどのPEフォーマット中に格納されますが、環境ごとのアセンブリをごっちゃにして格納する仕様なんてこんな場合でもなければ無意味なだけですし、署名等の仕様にも影響するでしょう。
      アセンブリはあくまでもキャッシュであるため、アセンブリを直接配布する仕様が存在しないのだと思われます。

      じゃあOSインストール時とかどうしてんだってのは詳しくは知りませんが、そういう場合に使用する方法は常用すべき方法ではないでしょうから避けるのも判る気がします。
      # 使ってる内に再コンパイル対象が増えて遅いってだけかもしれませんが

      シェア
      親コメント

    • Re: (スコア:0)

      by Anonymous Coward
      中間コードから、ネイティブコードへの変換のことを言っているんじゃないでしょうか。内部でどの程度の事をやっているかは知りませんが、環境に応じた最適化などあるでしょうから、Microsoft側でビルドして配るというわけにも行かないんでしょう。
typodupeerror

UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア