Quantcast
Channel: Japan IE Support Team Blog
Viewing all 141 articles
Browse latest View live

Internet Explorer 一時ファイルが肥大化する

$
0
0

Internet Explorer サポートチームの藤代です。

今回は、Internet Explorer (以降 IE) のキャッシュの概要と一時ファイルが肥大化した場合の解消方法についてご紹介します。

 

- 目次 –

・IEが保持するインターネット一時ファイル(キャッシュ)の概要

 - キャッシュファイルとインデックス情報

  - キャッシュの容量

・一時ファイル (Temporary Internet Files フォルダー)が肥大化した場合の解消方法

 - どのような場合にキャッシュフォルダーが肥大化するか

 - 解消方法

 

IE が保持するインターネット一時ファイル(キャッシュ)の概要

================================================

 キャッシュファイルとインデックス情報

------------------------------------------------------------

IE が保持するインターネット一時ファイルはキャッシュの実ファイルとそのキャッシュファイルを管理するインデックス情報の 2 つで構成されています。

Temporary Internet Files フォルダーでは保持されている一時ファイルを確認しやすいように表示していますが、実際の実キャッシュファイルとインデックス情報は以下のようなフォルダーに格納されています。

 

Windows XP 環境、または Windows Server 2003 環境の場合 (各 IE のバージョン共通)

実ファイルが格納されるフォルダー

 C:\Document and Settings\<ユーザー名>\Local Settings\Temporary Internet Files\Content.IE5\<ランダムな 8 桁の英数字フォルダー>

 *Content.IE5 直下の index.dat というファイルがインデックス情報のファイルです。

 

Windows Vista 環境、または Windows Server 2008 環境移行の場合 (各 IE のバージョン共通)

 保護モード有効なサイトのキャッシュ

 C:\Users\<ユーザー名\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\low\<ランダムな 8 桁の英数字フォルダー>

 *Content.IE5 直下の index.dat というファイルがインデックス情報のファイルです。

 

 保護モード無効なサイトのキャッシュ

 C:\Users\<ユーザー名\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\<ランダムな 8 桁の英数字フォルダー>

 *Content.IE5 直下の index.dat というファイルがインデックス情報のファイルです。

 

イメージとしては index.dat ファイル内に「どのサイトからどのような応答で取得したか」という情報が含まれており、この情報と合わせそれぞれの実ファイルが管理されています。

 

キャッシュの容量

------------------------------------------------------------

IE のキャッシュ全体のサイズは [インターネットオプション]  - [全般タブ] から開くダイアログの [インターネット一時ファイルと履歴の設定]  の [使用するディスク領域] で設定できます。

ただし、この値はあくまで『目安』の値であり「制限」ではありません。

 

ここで「目安」とお伝えしたのは、この設定値は「このサイズまでしかキャッシュを作成しない」という制限値ではなく、「この設定値の値に近づくように調整される」という値である為です。

 

例えば、使用するディスク領域の設定が100 MB であるとします。

普段、IE を利用しページを閲覧しており 100 MB に近いサイズのキャッシュが保持されている状況とします。ここで、Web ページの構成やダウンロードで 50 MB のサイズのファイルを取得したばあい、IE ではこのファイルを取得した場合にキャッシュを作成します。(100 MB 指定がある為「キャッシュをしない」という動作にはなりません)

 

この場合、100 MB の指定を超えるキャッシュが保持されている状況になります。

ただし、指定値を超えているとその後 IE 利用中に内部の処理ロジックで長期間参照されていない、利用頻度の低いものを判断し設定値を目安に保持しているキャッシュを削除しその容量を調整します。

 

一時ファイル (Temporary Internet Files フォルダー)が肥大化した場合の解消方法

================================================ 

どのような場合にキャッシュフォルダーが肥大化するか

------------------------------------------------------------

IE サポートチームにお問合せを頂く現象の中に、「ディスク容量が圧迫され確認すると Temporary Internet Files フォルダー」のサイズが数 GB などの大きさになっているというご質問があります。

([使用するディスクの領域] の設定は最大でも IE7 以降の場合 1024 MB までの設定しかできません)

 

キャッシュファイルはインデックス情報と関連づけて保持されていますが、この関連づけが不整合な状態となり正常な管理がされていない状態である場合にこのような現象が発生します。

このような現象/状況を私たちは「インデックスの破損」(キャッシュの実ファイルとインデックス情報が崩れた状態)と呼んでいます。

 

インデックス情報の破損の要因は様々に考えられ、残念ながら破損した状態の後からその理由を遡って確認する事ができません。

お問合せを頂くのが「現象発生後」でありログなどの記録が残らない処理になること、また、「IE のキャッシュ」とお伝えしていますが実際は「他の IE コンポーネントを利用して開発されているアプリケーション」でも同一のキャッシュが利用される為、残念ながら、この点ではご支援を差し上げることが難しくなっています。

 

例えば、要因として考えられるものとしては「実ファイルのみを直接削除してしまった」、「(ユーザー操作なども含め)キャッシュの削除を行おうとしたが、実ファイルが他のプロセスにロックされていて削除できなかった」などです。

すなわち、「正常な操作でキャッシュの削除が行われなかった場合」や「キャッシュに対する操作が何かしらの要因で妨げられてしまう」事でインデックス情報と実ファイルの整合性が崩れてしまい、結果としてキャッシュサイズの正常な管理ができなくなってしまい肥大化してしまいます。

 

解消方法

-----------------------------------------------------------

このような現象が発生した場合、「Temporary Internet Files フォルダー」を「フォルダーごと」すべて削除し、再作成する事が対処の方法となります。

ここでご注意頂きたい点としては、インデックス情報は「ユーザーがログイン時にメモリ上に読み込まれロック」されますので「ユーザーログイン中は削除できない」という点です。

 

ではどのように削除するかというと、最も簡単な方法は「ご利用の端末で新規に管理者権限のあるユーザー」を作成し、そのユーザーでログインし現象が発生しているユーザーアカウントの Temporary Internet Files フォルダーを削除してしまう方法です。この操作でフォルダーを削除後、現象の発生していたユーザーでログインすると、新しい index.dat ファイルを含む Temporary Internet Files フォルダーが再作成されます。

 

インデックスが破損している状態の場合、Temporary Internet Files フォルダーが肥大化するだけでなく、ページの表示時に一部正しく表示されない、ダウンロードが正常に行えないなどといった現象の発生も報告されています。

ご利用の端末でこれらの現象が発生する場合、上記の方法でキャッシュを完全にクリアする事で現象が改善するかもお試しください。

 

このような現象と同様の解決方法については以下のような KB でも紹介されていますのでご参考としてご参照ください。

 

Internet Explorer で Web ページを開けず、エラー メッセージ "ページを表示できません" が表示される

http://support.microsoft.com/kb/293402/

 

Internet Explorer を使用してファイルをダウンロードできない

http://support.microsoft.com/kb/306837/

 

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。


Internet Explorer のカスタマイズ ~ Internet Explorer のメンテナンスポリシー part 1 (適用処理編)~

$
0
0

Internet Explorer サポート担当の藤代です。

先日公開された Web Cast では Internet Explorer の設定のカスタマイズ方法についてご紹介しました。

 

Internet Explorer の展開計画 ~IE 9 の設定カスタマイズのコツと検討ポイント~

http://technet.microsoft.com/ja-jp/events/Video/hh580300

 

この Web Cast で IE の設定のカスタマイズの手順として以下のような流れをお話しました。

  
  
  

本 Blog では設定方法をご検討頂いている事を前提に、カスタマイズ方法のその機能や違いについてご紹介していきます。

今後、以下のようなカスタマイズ方法についてその違いや設定方法なども含め取り上げていきます。

 -  Internet Explorer のメンテナンスポリシー

 - グループポリシーの管理用テンプレート配下の Internet Explorer に関するポリシー

 - IEAK

今回は、IE のポリシーの中でもお問合せの多い、 Internet Explorer のメンテナンスポリシー の適用処理についてご紹介します。


Internet Explorer のメンテナンスポリシーとは

Internet Explorer のメンテナンスポリシーは
[ユーザーの構成] – [Windows の設定] – [Internet
Explorer のメンテナンス] です。

このポリシーを利用する上の特徴であり、注意頂きたい 3 点について以下の内容でご紹介します。

 1.Internet Explorer のメンテナンスポリシーの 2 つのモード

 2.Internet Explorer のメンテナンスポリシーの適用

 3.Internet Explorer のメンテナンスポリシーをポリシー適用処理の度に反映させる

 

この項目で今回ご紹介するポイントは以下の 2 点です。

 反映のタイミング

   基本的には管理用テンプレート配下のポリシー設定項目と適用されるタイミングは同一。

   但し、「優先モード」という『初期値を設定する為の』モードがあり、この場合にはクライアント端末/ユーザー毎に 1 度しか適用されない。

 

 ユーザーの設定変更可否

   このポリシーで行われた設定の多くはユーザーがインターネットオプションから変更可能。

 

1. Internet Explorer のメンテナンスポリシーの 2 つのモード

-----------------------------------------

この項目には、「優先モード」という設定と「通常モード」(便宜的に、優先モードを指定していない場合状態を「通常モード」と呼びます)の
2 つのモードがあります。

この 2 つのモードのもっとも大きな違いは、「設定がクライアントに適用されるタイミング」です。

 

優先モード

 このモードは適用対象の端末に「初期値」を提供する目的のものです。

 クライアントにはポリシー設定後 1回だけ適用され、以降のポリシー適用処理のタイミングやポリシーの強制適用
(gpupdate /force) でも適用されません。

 

通常モード

 
“ポリシーの適用処理”のタイミングで必要に応じ再適用されます。

 グループポリシーの”適用処理”はユーザーのログオン時やログオン後、一定時間ごとに行われます。

 通常のモードの場合の
Internet Explorer のメンテナンスポリシーの適用はこのグループポリシー全体の ”適用処理” に依存します。

 (グループポリシーは既定では ”適用処理” のたびに、毎回、実際の『設定の適用』が行われるわけではありません。例えば、適用対象となるGPO
に変更がある場合に実際の設定の適用が行われます。)

 

ご参考

優先モードで Internet
Explorer のメンテナンス ポリシーが適用されない

http://support.microsoft.com/kb/825685/ja

 

2. Internet Explorer のメンテナンスポリシーの適用

-----------------------------------------

Internet Explorer のメンテナンスポリシーで設定可能な内容の多くは、設定反映後、クライアント端末で『ユーザーが自由に変更すること』が可能です。

技術的に言うと、この理由は Internet Explorer のメンテナンスポリシーで設定される値は「ユーザーが利用するインターネットオプションの設定を保持しているレジストリと同じレジストリ」に反映されるためです。

この特徴は「ユーザーが任意に設定を変更して利用可能」な反面、『設定の強制、初期設定』のどちらを行いたいかと合わせて考慮しておかないと、以下のような問題を引き起こす場合があるのでご注意ください。

 

優先モード利用時

 設定が「初期値」を提供するものである為、「ユーザーが設定変更して利用してもポリシーは再適用されません」

 ポリシーで「設定を元に戻すこと/強制すること」を意図している場合に『再適用されない』というお問合せを頂きます。

 

通常モード利用時

 設定が「ポリシーの適用処理」に依存して反映される為、「ユーザーが変更していた設定を上書きしてしまう」可能性があります。

 

 GPO A で Internet Explorer のメンテナンスポリシーの設定を行っているとします。

 例えば、GPO A変更で設定した内容が (Internet Explorer のメンテナンスポリシー以外も含め) 変更されていない場合にはポリシーは再適用されていません。

 

 上記期間中にユーザーがIE の設定を変更し利用しています。

 ある事情により GPO A の内容を変更すると、それが Internet Explorer のメンテナンスポリシーの項目ではない場合でも、クライアント端末にはポリシーが再適用されます。

 つまり、このタイミングで Internet Explorer のメンテナンスポリシーも再適用されるため、『ユーザーが変更していた設定が失われる』というような現象が発生します。

 

3. Internet Explorer のメンテナンスポリシーをポリシー適用処理の度に反映させる

-----------------------------------------

Internet Explorer のメンテナンスポリシーを GPO 自体の変更がない場合でもクライアント端末に毎回適用させる方法があります。

その方法は、以下のグループポリシーの設定を行う方法です。

 

 [管理用テンプレート] – [Windows コンポーネント] – [システム] – [グループポリシー] – Internet Explorer のメンテナンス ポリシーの処理

 

”グループ ポリシー オブジェクトが変更されていなくても処理する” を構成することで、ポリシーの適用処理自体が行われるたびに Internet Explorer のメンテナンスポリシーの設定がクライアントに反映されるようになります。

(*優先モードの場合は、「初期値を提供する」目的ですので適用されません。通常モードを利用時のみに効果のある設定です)

 

Internet Explorer のメンテナンスポリシーで反映される設定は「ユーザーが変更可能」な為、強制力が弱めの項目です。

この項目を設定することで変更されてしまっても、それがある一定期間に留まり、例えば次のログイン時には設定がポリシーで行っていたものに戻っているという効果が期待できます。


次回は、お問合せの中でも比較的多い、「ポリシーで IE のセキュリティゾーンの登録をする」を題材に、Internet Explorer のメンテナンスポリシーと管理用テンプレートの配下の IE に関する項目の違いについてご紹介していきます。
 

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

Internet Explorer のカスタマイズ ~ Internet Explorer のメンテナンスポリシー part 2 (Internet Explorer のメンテナンスポリシーと管理用テンプレート配下のポリシー項目の違い)~

$
0
0

Internet Explorer サポート担当の藤代です。

 本日は前回の Blogで予告した、Internet Explorer のメンテナンスポリシーと管理用テンプレート項目の違いについて「ポリシーで IEのセキュリティゾーンの登録をする」を題材に紹介していきます。

 

セキュリティゾーンの登録はお問い合わせの多いもののひとつです。

Web Castでは、カスタマイズカスタマイズの流れをお話しましたが、これに沿いご紹介をしていきます。

 

1. 設定対象項目の検討

 ・既存でユーザーが利用している端末環境があります。

 ・ある Web アプリケーションを導入/利用開始する事となり、そのアプリケーションを動作させるため “信頼済みサイト” への登録が必要となりました。

 ・既存ユーザーが利用しているため、既に信頼済みサイトに登録されているアドレスが複数あり、ユーザー毎にその設定が異なります。

 

2. 設定方法検討

 ・新規で登録するゾーン登録はすべてのユーザーに強制的に反映させたいと考えています。

 ・但し、合わせて「既存でユーザーが利用している設定」はそのまま生かし利用できるようにすることとなりました。

 ・また、ある特定の
URL をゾーンに追加するだけで、他の設定などは変更しない(影響を与えない)設定をしたいと考えています。

 

3. カスタマイズ方法検討

 ・上記の方法を満たすポリシーでの設定が可能か(項目として要望を満たすものがあるか)を確認します。

   (結論としては、残念ながら 1, 2 で検討した内容を満たす(ゾーンの登録に関連する「既存のポリシー項目」は存在しないのですが、その理由、および、上記の要件に近い代替え案も含め以下に記載していきます)

 


信頼済みサイトを登録する既存のポリシー項目

信頼済みサイトを登録可能なポリシーの項目はInternet Explorer のメンテナンスポリシー/管理用テンプレート配下のどちらにも存在します。

各項目は以下の通りです。これらのポリシー項目は、それぞれ後述のように動作が異なります。

  ユーザーの構成 – 管理用テンプレート -Windows コンポーネント – Internet Explorer – インターネット コントロールパネル – セキュリティ ページ - サイトとゾーンの割り当て一覧

  ユーザーの構成 – Windows の設定 – Internet Explorer のメンテナンス – セキュリティ - セキュリティ ゾーンおよびコンテンツの規制 - 現行のセキュリティ ゾーンとプライバシーの設定をインポートする 

 

○サイトとゾーンの割り当て一覧

----------------------------------------------------------------

「管理用テンプレート」配下のポリシー項目は「設定内容を『管理者』が管理/コントロールする」目的で利用するものです。

「サイトとゾーンの割り当て一覧」のポリシーもこの『管理者がコントロールする』事が前提となっています。

このポリシーを適用すると、クライアント端末では『ポリシーで設定したゾーン登録の内容は強制されますが、ゾーン登録の内容はポリシーで登録されたもののみ』となりユーザーが設定を変更する事ができません。

 (*実際にはユーザーが設定していた内容はレジストリに保持されていますので、上書きされ失われているわけではありませんが、IEの動作上『ポリシーで設定された内容』のみが利用される動作になります)

 

○現行のセキュリティ ゾーンとプライバシーの設定をインポートする

----------------------------------------------------------------

この設定項目は、名前の通り「(ポリシーの構成を行う)端末/ユーザーの現在のセキュリティ ゾーンの設定を全て」インポートしポリシーとして反映するものです。

例えば、2008 R2の AD 端末にユーザー A がログインしこの設定を行う場合、ポリシーとして反映される設定は以下のような流れで作成されます。

 a. 対象のユーザーのインターネットオプションを表示し、そのユーザーの「現在の IEの設定」を変更する

 b. 表示されたダイアログを OK で閉じると、その時点での設定内容(a で変更/編集した設定だけではなくゾーンの設定すべて)をインポートしポリシー配布用のファイルがAD 上に作成されます。

 

つまり、“ある一つのURL を信頼済みサイトに登録したい” という目的で “その設定だけを反映させる” 事ができません。上記動作を理解し利用する限りは問題ありませんが、”特定の URL のみを登録したい”という目的のみで利用すると、他の設定も同時に変更してしまう事となり意図しない問題を引き起こす可能性があります。

まとめると、「ユーザーに設定を強制する事」、「既存でユーザーが設定している内容を生かす事」を満たし、かつ、「他の設定は変更しない」という目的を満たす既存のポリシー項目は残念ながらありません。

 

要件に近い代替え案

今回の要件の場合、取れる代替え案は “何かしらの方法である特定のURL のみをゾーン登録する” 為にレジストリを直接編集する方法です。

 ゾーン登録に関連するレジストリ情報は以下の付録に記載します。(対象としては、通常、インターネットオプションから設定を行う際に設定が保持されるレジストリを利用します)レジストリを設定する為に特にその方法は問いませんが、ポリシーを利用するという観点では以下の何れかのようなものがあります。

 ・レジストリを登録するスクリプトやバッチを作成し『ログオンスクリプト』で登録する。

 ・Windows2008 以降で強化された、グループポリシー基本設定のレジストリの設定を利用する

 ・任意のレジストリを登録するカスタムポリシーテンプレート(ADM または、ADMX/ADML) を作成し、ポリシーのカスタム項目として読み込み設定を有効にする

 

*なお、「特定のURL を登録した時に設定対象となるレジストリ」を確認するには、検証端末で一度、既存のゾーン登録を全て削除し、『追加したいURL のみをゾーン登録した場合』に反映されている設定内容を確認する方法がお勧めです。


付録

Internet Explorer のゾーン関連のレジストリについて

クライアント OS の Internet
Explorer のゾーン設定に関するレジストリはその登録方法などにより以下の
4 箇所に登録されます

 

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\InternetSettings\ZoneMapの配下

 → ある一定の条件下でゾーンの設定を行った場合にその設定が書き込まれるレジストリです。

   ポリシーで設定を行っている場合に利用されることがあります。

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\InternetSettings\ZoneMap の配下

 → 通常、インターネットオプションでユーザーが設定をした場合にその設定が書き込まれるレジストリです。

 

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CurrentVersion\InternetSettings\ZoneMap の配下

HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\InternetSettings\ZoneMap の配下

 → サイトとゾーンの割り当て一覧を利用した場合に設定が反映されるレジストリです。

  
 HKLM の設定は「コンピューターの構成」、HKCU の設定は「ユーザーの構成」配下を利用した場合にそれぞれ利用されます。

 *ゾーン判定時の優先順位はHKCU > HKLM であり、重複するような登録がある場合HKCU の設定が利用されます。

 *サイトとゾーンの割り当て一覧を利用した場合、(Policies以下の設定がある場合)、ゾーン判定ではこのレジストリのみが利用されるようになります。

以下の KB もご参考となりますので合わせてご参照ください。

上級ユーザー向けの
Internet Explorer セキュリティ ゾーン関連のレジストリ エントリ

http://support.microsoft.com/kb/182569/ja

 

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

Internet Explorer 11 関連リソースの紹介

$
0
0

こんにちは、Internet Explorer サポート担当の原です。

Windows 8.1 が一般に公開されてから早くも 1 週間が立ちました。今日は Internet Explorer 11 (IE11) に関連する公開情報をまとめて紹介します。

また、Windows XP などから移行を検討される方も多くいらっしゃると思いますので、今後 IE における過去の大きな変更点を中心に、互換性に影響する情報を掲載していく予定です。

 

それでは、まずは IE11 の互換性に関するドキュメントを紹介します。

特に既定の Edge モードでは、多くの Web サイト開発者の悩みの種になっていたブラウザー間の差異をなくし、真に Same Markup を実現するために IE 独自のレガシーな機能を削除しています。

また、ユーザー エージェント文字列も従来から大きく変更していますので、Web サイト開発、運用にかかわる皆さまは是非ご覧ください!

 

IE11 Preview における互換性の変更点

http://msdn.microsoft.com/ja-jp/library/ie/bg182625.aspx

 

IE11 の互換性の変更点

http://msdn.microsoft.com/ja-jp/library/ie/dn384049.aspx

 

Internet Explorer 11 の新しい機能を理解したい方は、以下のドキュメントを参考ください。

 

Internet Explorer 11 Preview 開発者向けガイド

http://msdn.microsoft.com/ja-jp/library/ie/bg182636.aspx

 

IT Pro の皆さまにはこちら!IE11 の展開やグループ ポリシーに関する情報がてんこ盛りです。

 

Internet Explorer 11 - IT 担当者向けの FAQ

http://technet.microsoft.com/ja-jp/library/dn268945.aspx

 

Internet Explorer 11 の新しいグループ ポリシー設定

http://technet.microsoft.com/ja-jp/library/dn321453.aspx

 

Internet Explorer 11 (IE 11) - IT 担当者向け展開ガイド

http://technet.microsoft.com/ja-jp/library/dn338135.aspx

 

おまけで…、Windows 8.1 の互換性に関するドキュメントも参考までに紹介します。

 

Windows 8.1 and Windows Server 2012 R2 client and server compatibility (英語)

http://msdn.microsoft.com/en-us/library/windows/desktop/dn323743.aspx

 

ついでに…、IE10 と Windows 8 に関連するドキュメントもまとめて紹介しちゃいます!

 

Windows 8 と Windows Server 2012 の互換性クックブック

http://www.microsoft.com/ja-jp/download/details.aspx?id=27416

 

IE10 の互換性の変更点

http://msdn.microsoft.com/ja-jp/library/hh801219.aspx

 

Internet Explorer 10 開発者向けガイド

http://msdn.microsoft.com/ja-jp/library/hh673549.aspx

 

IE10 では、メンテナンス ポリシーの廃止という大きな変更を行っています。グループ ポリシーの変更点に関する情報にもご注意ください。

 

IT 担当者向けの Internet Explorer 10 の概要

http://technet.microsoft.com/ja-jp/library/hh846774.aspx

 

IT 担当者向けの Internet Explorer 10 の FAQ

http://technet.microsoft.com/ja-jp/library/hh846773.aspx

 

Internet Explorer 10 のグループ ポリシー設定

http://technet.microsoft.com/ja-jp/library/hh846775.aspx

 

Internet Explorer のメンテナンスの代替機能

http://technet.microsoft.com/ja-jp/library/hh846772.aspx

 

今回紹介するドキュメントは以上です。

なお、IE 全般や IE の互換性に関する最新の情報は、次のマイクロソフト Web サイトで確認いただけます。

 

Internet Explorer 11 Portal (英語)

http://technet.microsoft.com/en-us/ie/dn262703.aspx

 

Internet Explorer compatibility changes by version (英語)

http://msdn.microsoft.com/en-us/library/ie/dn467846.aspx

 

それでは、次回もよろしくお願いいたします!

Internet Explorer Big Changes! (1) - LCIE 機能 (IE8 ~)

$
0
0

こんにちは、Internet Explorer サポート担当の原です。

今回から少しずつ、Internet Explorer (IE) における過去の大きな変更点を中心に、互換性に影響する情報をおさらいしていきます。

第 1 弾は、IE8 から実装している LCIE 機能の紹介です。本ブログでも以前に紹介したことがありますが、見直してまいりましょう。

 

LCIE 機能によるプロセス分離

IE8 以降では、各タブ ウィンドウをホストする UI フレーム ウィンドウとドキュメントを表示するタブ ウィンドウとが、別々のプロセスとして動作します。

この IE8 での新しいプロセス モデルは、Loosely-Coupled IE (LCIE) と呼んでいます。詳細に関しましては、弊社 IE 開発チームのブログでも紹介しています。

 

IE8 と Loosely-Coupled IE (LCIE)

http://msdn.microsoft.com/ja-jp/ie/cc787974.aspx

 

Opening a New Tab may launch a New Process with Internet Explorer 8.0 (英語)

http://blogs.msdn.com/askie/archive/2009/03/09/opening-a-new-tab-may-launch-a-new-process-with-internet-explorer-8-0.aspx

 

LCIE 機能が有効の場合 (既定では有効)、各タブ、および window.open メソッドなどで開かれたウィンドウは別々のプロセスで動作し、タブごとに保護モードの設定が適用されます。

フレームとタブ部分のプロセスが分離することにより、特定の Web ページで問題が発生した場合でも、問題が発生したタブだけを切り離し、影響を最小限に抑えることができます。

 

しかしながら、BHO や ActiveX などのアドオンによっては、LCIE 機能により複数の iexplore.exe プロセスが動作することで不都合が生じるようです (共有メモリーの使用や排他処理など)。

対策として、TabProcGrowth のレジストリやグループ ポリシーを使用することで、LCIE 機能を無効にできます。

ただし、無効にすることでクラッシュ回復やハング回復機能の恩恵を受けられなくなります。

 

- レジストリ

キー : HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main

名前 : TabProcGrowth

値 : 0 (REG_DWORD)

 

- グループ ポリシー

[ユーザーの構成] または [コンピューターの構成]

+ [管理用テンプレート]

+ [Windows コンポーネント]

+ [Internet Explorer]

  - [タブ プロセスの増加率を設定] を "有効" に設定し、増加率に 0 を指定します。

 

なお、IE10 以降においては、フレーム プロセスが 64 bit のみに変更されたことから、LCIE 機能を無効にしているシナリオで注意が必要です。

LCIE 機能を無効にするとフレーム プロセスのみで動作することになるので、64 bit の iexplore.exe 単体で動作します。

そのため、32 bit で動作する BHO や ActiveX などのアドオンは、LCIE 機能を無効にした IE10 以降では動作しません。

LCIE 機能の無効は、基本的にはデメリットしかありませんので、可能な限り LCIE 機能を無効にせずにご利用いただくことが望ましいです。

 

32-bit browser applications may not work as expected in Internet Explorer 10 (英語)

http://support.microsoft.com/kb/2716529/en-us

 

LCIE 機能によるセッションの共有

LCIE のプロセス モデルがもたらす機能のひとつとして、フレーム マージによるセッション (資格情報、Cookie) の共有があります。

 

従来の IE では、異なるプロセスとして iexplore.exe を起動すると、それぞれ異なるセッションで動作しました。

IE8 以降では、既に起動している IE が存在すると、新しく IE のプロセスを起動しても異なるセッションにはならず、既存の IE 配下にマージされ、同一のセッションで動作します。

 

セッションの共有を行わないためには、-noframemerging のオプションを指定して iexplore.exe を起動する、FrameMerging のレジストリでフレーム マージを無効にする方法があります。

 

- レジストリ

キー : HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main

名前 : FrameMerging

値 : 0 (REG_DWORD)

 

Session management within Internet Explorer 8.0 (英語)

http://blogs.msdn.com/b/askie/archive/2009/05/08/session-management-within-internet-explorer-8-0.aspx

 

Internet Explorer Command-Line Options (英語)

http://msdn.microsoft.com/en-us/library/ee330728.aspx

 

それでは、次回もよろしくお願いいたします!

Windows 7 向け Internet Explorer 11 提供開始!

$
0
0

こんにちは、Internet Explorer サポート担当の原です。

本日未明、Windows 7 向け Internet Explorer 11 を提供開始いたしました。Windows 7 ユーザーの皆さまは、以下のリンクからアップグレードできます。

 

http://windows.microsoft.com/ie

http://windows.microsoft.com/ie-for-msn (MSN/Bing 版)

 

各言語版を個別にダウンロードしたい場合は、以下のサイトをご利用ください。

 

Internet Explorer 11 のダウンロード

http://windows.microsoft.com/ja-jp/internet-explorer/ie-11-worldwide-languages

 

先月から Windows 8.1 ユーザー向けに提供している IE11 をようやく Windows 7 でもご利用いただけるようになりました。

より速くて安全で Web 標準に準拠したブラウジングを是非お試しください!

 

高速 : JavaScript エンジンの改善により、最近の他社のブラウザーよりも 30% 速くなっています (IE10 に比べても 9% 速い)。

新しい IE Test Drive Demo である EtchMarkでも体験いただけます。

 

最新の Web 標準 : プラグインなしで 3D 描画ができる WebGL 等 25 の Web 標準に新たに対応することによって、開発者は IE 向けにも最新の Web サイトが作成できるようになりました。

詳しくは IE11 Developer Guideをご覧ください。F12 開発者ツールもより使いやすくなっています。

Web 標準に準拠した Web サイトを作るためのヒントや、互換性に問題がある場合は、modern.IEをご活用ください。

 

より詳しくは、IE 開発部門のブログ記事をご覧ください。

 

IE11 for Windows 7 Globally Available for Consumers and Businesses (英語)

http://blogs.msdn.com/b/ie/archive/2013/11/07/ie11-for-windows-7-globally-available-for-consumers-and-businesses.aspx

 

なお、Windows 8.1 の IE11 と Windows 7 の IE11 の主な差異は、以下のドキュメントで紹介しています。

 

Windows 7 での IE11

http://msdn.microsoft.com/ja-jp/library/ie/dn394063.aspx

 

ところで、IT Pro の皆さまは、Windows Update による IE11 の自動アップグレードが行われるのか?を気にされていることと思います。

答えは Yes、今回も IE11 の自動配布を予定しています。詳しくは以下のマイクロソフト Web サイトをご覧ください。

 

Internet Explorer 11 Delivery Through Automatic Updates (英語)

http://technet.microsoft.com/en-us/ie/dn449235.aspx

 

Internet Explorer 11 Blocker Toolkit: Frequently Asked Questions (英語)

http://technet.microsoft.com/en-us/ie/dn449234.aspx

 

日本における自動配布の開始時期は未定ですが、既に IE11 向けの自動配布の無効化ツールキットを公開しています。

移行のスケジュールや互換性の観点から IE11 へのアップグレードを遅らせざるを得ない場合は、今すぐにでも無効化ツールキットをご利用ください。

 

Internet Explorer 11 自動配布の無効化ツールキット

http://www.microsoft.com/ja-jp/download/details.aspx?id=40722

 

[2013 年 12 月 25 日追記]

日本における自動配布の開始時期が確定しました。2014 年 1 月第 2 週目から順次開始を予定しています。

詳細は以下のブログ記事をご覧ください。

 

2014 年 1 月第 2 週目から順次、Windows 7 向けInternet Explorer 11 の自動アップグレードを開始します

http://blogs.msdn.com/b/ie_jp/archive/2013/12/25/10484470.aspx

 

そのほか IE11 関連のリソースについては、前回のブログ記事も是非ご覧ください。

 

Internet Explorer 11 関連リソースの紹介

http://blogs.technet.com/b/jpieblog/archive/2013/10/25/3605627.aspx

 

それでは、次回もよろしくお願いいたします!

Internet Explorer Big Changes! (2) - Smart WPAD 機能 (IE8 ~)

$
0
0

こんにちは、Internet Explorer サポート担当の原です。

Internet Explorer (IE) における過去の大きな変更点を中心に、互換性に影響する情報をおさらいしていきます。

第 2 弾は、Windows 7 の IE8 以降で実装している Smart WPAD 機能の紹介です。

 

Smart WPAD 機能によるプロキシ自動構成の効率化

Windows 7 の IE8 以降、Network Location Awareness (NLA) サービスによって認識された個別の論理ネットワークごとに、WPAD 情報を管理しています。

NLA サービスは、認証するドメイン コントローラー、利用するデフォルト ゲートウェイ、無線 LAN アクセス ポイントなどの情報により論理ネットワークを識別します。

 

新しい論理ネットワークに接続する際に、インターネット オプションの LAN の設定で [設定を自動的に検出する] が有効になっている場合、DHCP サーバーへ WPAD の取得を行います。

IE は、論理ネットワークごとに実際に WPAD が使用可能なネットワークかどうかの情報をキャッシュし、30 日間保持します。

そのため、一度 WPAD が使用できないネットワークと判断された場合、そのネットワークに対して 30 日間は WPAD を使用しないように動作します。

この動作は、複数ネットワークを切り替えて使用するような環境で不必要な WPAD のクエリーが発行されないように調整し、ネットワーク負荷の軽減および高速化をはかるための機能です。

例えば、モバイル PC などを持ち歩き、外出先の様々なネットワーク環境に接続するような場合に真価を発揮します。

 

なお、頻度として稀と考えられますが、ネットワークの管理者が WPAD の構成を変更した場合、新しい構成がすぐに反映されない可能性があります。

すぐに反映したい場合、WPAD 情報のキャッシュのレジストリ HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpadを削除します。

 

それでは、次回もよろしくお願いいたします!

Internet Explorer Big Changes! (3) - ネットワーク パフォーマンスの向上 (IE9 ~)

$
0
0

こんにちは、Internet Explorer サポート担当の原です。

Internet Explorer (IE) における過去の大きな変更点を中心に、互換性に影響する情報をおさらいしていきます。

第 3 弾は、IE9 以降で実装しているネットワーク パフォーマンスの向上を狙う機能の紹介です。

 

キャッシュ機能の向上

IE9 以降、キャッシュをより効率的に使用するための実装の見直しと変更を行っています。

 

Caching Improvements in Internet Explorer 9 (英語)

http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx

 

特に、"Heuristic Cache Improvements" の動作により、RFC 2616 に合わせた動作を取るよう改良しており、従来の IE と比較して IE9 以降ではできる限りキャッシュを有効活用します。

この影響により、静的なリソース (スクリプト ファイルや Flash コンテンツ) を Web サーバー側で更新しても、IE で古いコンテンツが表示されてしまうというお問い合わせが多いです。

対応策としては、一定の頻度で更新を行うリソースについて、HTTP 応答ヘッダーの "Expires" や "Cache-Control: max-age" を使用して適切な有効期限を指定します。

 

また、IE のインターネット オプションの [全般] タブ [閲覧の履歴] の [設定] から、キャッシュの設定を [Web サイトを表示するたびに確認する] に変更する方法も有効です。

ただし、キャッシュを有効活用することによる高速化のメリットを失いますので、可能であれば Web サーバー側の対応策をおすすめします。

 

ネットワーク接続の向上

IE9 以降では、ネットワーク パフォーマンスの向上を狙うため、バックグラウンド接続を行う機能が追加されています。

具体的には、同じホストに対して、バックグラウンドで TCP 接続をプールするため、ほぼ同時に 2 つの connect を行います。

つまり、TCP 接続を確立する際の遅延を回避するため、実際に TCP 接続を使用するかしないかにかかわらず、予備の TCP 接続を準備し、パフォーマンスの向上を狙うのです。

 

Internet Explorer 9 Network Performance Improvements (英語)

http://blogs.msdn.com/b/ie/archive/2011/03/17/internet-explorer-9-network-performance-improvements.aspx

※ Faster Networking through Parallelism あたりです

 

この影響により、ご利用のセキュリティ製品や中間機器の動作に不都合が生じる場合は、以下のレジストリでバックグラウンド接続を無効にできます。

 

---
キー : HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings

 

名前 : BackgroundConnections

種類 : REG_DWORD

値 : 0 (無効)
---

 

それでは、次回もよろしくお願いいたします!


IE10 & IE11 : 拡張保護モードの実態

$
0
0

こんにちは、日本 Internete Explorer サポートチームの厳 (ゲン) です。

今回のブログでは、拡張保護モードについて紹介します。

 

そもそも拡張保護モードはなぜ必要ですか? 

 

拡張保護モードの登場は、日々進化したインターネット ビジネスと日々深刻なってくるセキュリティ保護の重要性と深い関係があります。

Windows XP / 2003 以前の OS はログインしたユーザーが起動したプロセスなら、プロセス内にそのユーザーの権限をフルに使えます。Windows XP で管理者権限でログインして、インターネット サーフィンをするときどうなるかを想像してみたことがありますか?IE を立ち上げて、管理者権限で iexplore.exe が起動されて、その中で Web ページが動いています。ページ内の ActiveX コントロールなどの実行を許可してしまうと、管理者権限なのでなんでもできちゃうんです。

そこで Windows Vista 以後に、OS レベルでプロセス整合性レベルという新機能が登場しました。これでユーザーの権限を一部だけ許可するようにできるようになり、IE は危険性が高いサイトを整合性レベルが低いプロセスで動かすことで、セキュリティを保護できるようになったのは 「保護モード」です。

更に Windows 8 で Windows Store アプリケーションが登場することにより、同じく整合性レベルが低いプロセスでも、更なる厳しい権限制限やデーターアクセスの分離の必要性のために、 AppContainer というさらに低い整合性レベルが追加されました。IE はこの整合性レベルで動作するのは「拡張保護モード」です。

以下に IE10、IE11 はどう拡張保護モードを対応しているのかを詳しく紹介していきます。

 

拡張保護モードの前に、そもそも保護モードとは?

 

保護モードが最初に登場したのは Windows Vista の IE7 です。インターネット オプションで各ゾーンのセキュリティ設定で [保護モードを有効にする] とのオプションが追加されました。

 図1: 保護モードを設定する箇所

 

保護モードの既定値:

                 インターネット   ローカル イントラネット信頼済み サイト 制限付き サイト
IE7有効有効無効有効
IE8以後有効無効無効有効

 

 

 

* Windows XP/Windows Server 2003 上の IE7/IE8 には設定項目はありません。保護モード未対応です。

 

保護モードの本質:  

保護モードは OS のプロセス整合性モデル (Integrity Level 以下 IL) を利用した セキュリティを強化するための機能です。

IL とは簡単に言うと、OS 上のプロセスを [高] (High) - [中] (Medium) - [低](Low)  の三段階でレベル付けし、レベルが高ければ高いほど OS での読み込み・書き込み権限が強い、低ければ低いほど権限が弱いという仕組みです。

IE は保護モードが有効のサイトを表示する際時は IL が [低] の IE プロセスで処理します。保護モードが無効のサイトは IL が [中] のプロセストで処理します。こうして、インターネット上のサイトを権限の低いプロセスでホストして、仮にサイト内に OS への意図しない箇所への書き込み、読み込み処理が実装されていても、操作は権限制限によって失敗するので、悪意のサイトから OS のデーターを保護できます。

ちなみに、プロセスがどの IL で動作しているのか、Process Explorer ツールで確認できます。

 

 図2: Process Monitor ログからプロセス整合性レベルを確認します。

 

保護モードが効かないパターン

この IL という仕組みはユーザーアクセス制御 (UAC)が有効の OS でしか対応できませんので、以下のシナリオで起動した IE は IL=Low になりませんので、保護モードは実質無効です

  • OS の UAC 機能を無効に設定している場合 (IL=High )
  • ビルトインの管理者 (ユーザー名: Administrator) でログオンした場合(IL=High )
  • IE を右クリックして [管理者として起動] で起動する場合。(IL=High )
  • IE の LCIE プロセスモデルを無効 ( TabProcGrowth=0 ) にした場合 (IL=Medium)
  • Windows XP / Windows Server 2003 上の IE7 / IE8 (IL を対応しない)

 

拡張保護モード

Windows 8 以後 [低] よりも権限が制限された IL レベル:  AppContainerを追加しました。この AppContainer は Windows ストア アプリ (Windows 8 でタイル状のアイコンから起動するアプリケーション) が動作するセキュリティ基盤となります。Windows 8 上の IE10 ももちろんこの AppContainer で動作できるために [拡張保護モード] を登場させました。

拡張保護モードの設定箇所:

モダン UI の IE (タイル アイコンから起動する IE) は常に拡張保護モードが有効です。設定を変更する項目はありません。

デスクトップの IE は、拡張保護モードはインターネット オプションの [詳細設定] タグで一箇所で設定します。

  図3: Windows 8 の IE10 で見る拡張保護モードの設定画面

 

 図4: Windows 8.1 (64bit) の IE11 で見る設定画面

 

図面に示されるように、64bit OS の IE11 は [拡張保護モードで 64 ビット プロセッサを有効にする] という項目が追加されています。これは拡張保護モードが有効の場合、IE のコンテンツプロセスを 64 bit にするかどうかを設定する項目です。

この項目は IE10 で設けていない理由は、IE10 は拡張保護モードを有効になると、必ずコンテンツ プロセスを 32bit -> 64bit に変更しているからです。IE11 では拡張保護モード状態のプロセスビット数ををユーザーが選択できるようにするため、この項目を追加しました。

この拡張保護モードとビット数の関係は煩わしいのですが、拡張保護モードの既定値の由来を理解するのにとっても重要です。詳しくは後述の [拡張保護モードとプロセス ビット数] で説明します。

 

拡張保護モードの本質

拡張保護モードが有効の場合、保護モードが有効のサイトは、IL が [Low] よりも低い [AppContainer] のプロセスで表示されます。保護モードが無効のサイトは、引き続き IL が [Medium] のプロセスで表示されますので、影響を受けません。

 AppContainer でページをホストする際にはページ上の ActiveX コントロールもこの AppContainer 内で動作できるようにデザインされていない限り、動作できません。現行の殆どの ActiveX コントロールは対応できていない状況から、拡張保護モードが有効だとページに ActiveX コントロールが含まれますと殆ど動作できません。(ちなみに Flash は AppContainer でも動作できます) 。

このような場合、IE はサイトの下部に警告を表示して、ユーザーが [許可] を選択すると、このサイトを Low で開き直します。

  

 図5: 拡張保護モードで ActiveX コントロールが動作しない警告メッセージ

もちろんほかにも Appcontainer による Cookie の分離や、ファイル I/O の制限など、さまざまのセキュリティ上の強化効果がありますが、詳細はまた今度にして、本ブログは各 IE バージョンが拡張保護モードへの対応の実態にフォーカスします。

 

拡張保護モードとプロセス ビット数

 まずは AppContainer 対応可能な OS (Windows 8 以後) の IE のプロセスモデルを見てみましょう。

64bit OS ならこう:

図6: 64bit OS の IE10 / IE11 プロセスモデル (Windows 8 以後)

 

32bit OS なら、64bit プロセスを作れないので、 [拡張保護モードで 64 ビット プロセッサを有効にする] という項目はありません。こうなります

 


    図7: 32bit OS の IE10 / IE11 プロセスモデル (Windows 8 以後)


次に、Appcontainer を対応しない OS (Windows 7 / 2008R2) はどうなるか?「Windows XP が IL を対応できないので保護モードの項目自体がない」と同じように、「Windows 7 も Appcontainer を対応しないなら、拡張保護モードの項目も設ける必要はない」とおもいますよね?答えは、いいえ、64bit の Windows 7 / 2008R2 [拡張保護モードを有効にする]項目を設けています。その理由は、IE10 を設計当時、拡張保護モードが ON になると、IE プロセスが 32bit ->  64bit に自動的に切り替わるようにデザインしているため、 64bit の Windows 7 / 2008 R2 では AppContainer を提供できないものの、32bit ->  64 bit にプロセスを切り替えることができるからです。 

64bit の Windows 7/2008R2 で [拡張保護モードを有効にする] が ON にすると、コンテンツ プロセスのビット数は 32bit から 64bit に切り替わるだけで、IL は Low のままです。現行のほどんど古い ActiveX コントロールは 32bit で作られているので、64bit のプロセスに切り替えるだけでも、間接的に ActiveX コントロールを動作させないという効果があります。なお、この設計は Windows 7 上の IE11 にも踏襲しています。

つまり、こんな感じです。

図8: 64bit OS の IE10 / IE11 プロセスモデル (Windows 7/2008R2)

 

じゃ、32bit の Windows 7 / Windows Server 2008 R2 はどうなる?  64bit <-> 32bit の切り替えすらできないですよね。そうなんです。項目があっても ON・OFF には何も変わりようがないので、32bit の Windows 7 / Windows Server 2008 R2 では拡張保護モードの設定項目がなく、拡張保護機能を対応しません。

 

拡張保護モードの既定値

現行拡張保護モードを対応する全 OS ・全 IE バージョンの既定値、および拡張保護モードの ON/OFF の違テーブルに纏めてみました。拡張保護モードの ON・OFF により変化する部分をハイライトしています。

これだけを見ると確かに煩わしいですよね。:-) 図6,7,8と比較しながら見ていただけると分かりやすいと思います。

 

 

項目1: [拡張保護モードを有効

にする] 既定値

項目2: [拡張保護モードで 64 ビット

プロセッサを有効にする] 既定値

 拡張保護モードを無効のとき

 IE のコンテンツ プロセスはどうなる?

 拡張保護モードを有効のとき

 IE のコンテンツ プロセスはどうなる?

 IE11 on Windows 8.1(x86)  

 OFF(※補足あり)

 N/A (項目なし) 32bit Low 32bit AppContainer

 IE11 on Windows 8.1(x64) / Windows Server 2012 R2 (x64)

 OFF(※補足あり)

 OFF

項目2 が ON  : 64bit Low

項目2 が OFF: 32bit Low

項目2 が ON  : 64bit AppContainer

項目2 が OFF: 32bit AppContainer

 IE11 on Windows 7 (x86)

 N/A (項目なし) N/A (項目なし) N/A (Non-Support) N/A (Non-Support)

 IE11 on Windows 7 (x64) / Windows Server 2008 R2 (x64)

 OFF N/A (項目なし) 32bit Low 64bit Low
 IE10 on Windows 8 (x86)

 OFF

 N/A (項目なし) 32bit Low 32bit AppContainer
 IE10 on Windows 8 (x64) / Windows Server 2012 (x64)

 OFF

 N/A (項目なし) 32bitLow 64bitAppContainer
 IE10 on Windows 7 (x86)

 N/A (項目なし)

 N/A (項目なし) N/A (Non-Support) N/A (Non-Support)
 IE10 on Windows 7 (x64) / Windows Server 2008 R2 (x64)

 OFF

 N/A (項目なし) 32bit Low 64bit Low

* IE11 on Windows 8 は存在しません。IE11 は Windows 8.1/2012R2 または Windows 7/2008R2 にしか作っていません。

* Windows Server 2012 x86、Windows Server 2008 x86 は存在しません。Windows 2008 以後のサーバー OS は 64bit しか作っていません。

 

(※補足)

IE11 リリース当初は、 [拡張保護モードを有効にする] 既定値が ON の状態でリリースされていました。その後各方面からのフィードバックを受け、日本時間の 2013 年 11 月 13 日 (米国時間の 2013 年 11 月 12 日)、IE11における拡張保護モードの既定値を"オフ"にするセキュリティ更新プログラムがリリースされました。この更新プログラムを適用された後に、既定値は OFF になります。

  ◇マイクロソフト セキュリティ情報 MS13-088 - 緊急

  Internet Explorer 用の累積的なセキュリティ更新プログラム (2888505)

  http://technet.microsoft.com/ja-jp/security/bulletin/ms13-088

 

拡張保護モードが効かないパターン

保護モードが効かない時は、拡張保護モードも効きません。なので、 前述の 「保護モードが効かないパターン」をご参照ください

もちろん Windows 7/ 2008 R2 環境下の拡張保護モードは本物の「拡張保護」ではない (Bit 数が変わるだけ) のも念頭に入れてください。

  

それては、ちょっと話が長くなりましたが、最後に少し参考情報をご紹介して、終わりにします。また次回お会いしましょう。

 

   Understanding Enhanced Protected Mode

   http://blogs.msdn.com/b/ieinternals/archive/2012/03/23/understanding-ie10-enhanced-protected-mode-network-security-addons-cookies-metro-desktop.aspx

 

   拡張保護モード

 http://blogs.msdn.com/b/ie_ja/archive/2012/03/21/enhanced-protected-mode.aspx

 

   保護モードの Internet Explorer の理解と機能

   http://msdn.microsoft.com/ja-jp/library/bb250462(v=vs.85).aspx

 

 

デバッガで IE からのリクエスト内容を見てみよう

$
0
0

初めまして

日本マイクロソフト、デベロッパーサポート統括部インターネットチームの坂井と申します。

 
私はチーム内でもエスカレーションエンジニアという偉そうな立場でして、IE 自体の内部のデバッグとか開発との修正のやり取りとかそんな役割を担っています。

そんなわけで、いろんな機能とかよくあるネタは他の人にお任せして、私は何というのかちょっと特殊な調査だったり内部情報をかける範囲で書いてみたいなーと思っています。

ただし、内部の機密情報との関係もあり、すぐにネタが尽きるかもしれません。基本的に公開されているデバッグシンボルで行える範囲での内容になります。

 

今回は初めてなので、軽めに。「IE からリクエストが出て行っているのか」を Windows Debugger で調べる場合の方法です。

 

デバッガの使い方とかシンボルって何?はこちらから

      32 ビット版 Debugging Tools for Windows

      <http://msdn.microsoft.com/ja-jp/windows/hardware/gg463016>

      64 ビット版 Debugging Tools for Windows

      <http://msdn.microsoft.com/ja-jp/windows/hardware/gg463012>

 

 

やってみよう

さてデバッガを入れたら windbg.exe を起動しましょう。次に適当に IE を起動して iexplore.exe にアタッチします。windbg で [File] メニューの [Attach to Process] を選びます。

LCIE 有効な環境だと iexplore.exe が複数いますが、SCODEF:xxx といった引数がついているのがタブプロセスで通信を行うのもこのプロセスなので、これにアタッチします。

 

 

  

アタッチしたら、コマンド欄に以下を入力します。 

 .sympathSRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
 

そしてさらに以下を打ち込み g で実行します。

 bp wininet!HttpOpenRequestW

 

そして、IE の画面に戻りどこか適当なページに遷移します。以下は bing.com に移動しています。

そうするとデバッガでブレークします。

 

 

 

HttpOpenRequest はリクエストの起点になる関数で、この引数で HTTP Method や URL を確認できます。

まず kv コマンドで呼び出し履歴を見てみましょう。

 

0:003> kv2

ChildEBP RetAddr  Args to Child

02cfb62c 7549da38 00cc0008 754be2bc 0c8d1e78 WININET!HttpOpenRequestW (FPO: [Non-Fpo])

02cfbe9c 7549d80f 06617970 06617c04 06617970 urlmon!CINetHttp::INetAsyncOpenRequest+0x26d (FPO: [Non-Fpo])

 

HttpOpenRequest のヘルプを見ると、第一引数がインターネットハンドル、第二引数がメソッドの文字列、第三引数が URL なので、du コマンドでメソッドと URL を見てみます。

 

0:003> du 754be2bc

754be2bc  "GET"


0:003> du 0c8d1e78

0c8d1e78  "/?setmkt=ja-JP&setlang=match&uid"

0c8d1eb8  "=A2503EA1&FORM=NFTOJP"

 

ということで、サクサクっとメソッドと URL が確認できました。

 

ここまで来る場合は、少なくとも IE は通信モジュール WinInet.dll にリクエストを要求した、と言えます。

ここまで来ていないなら、HTMLやスクリプトなどのコンテンツを疑ったほうがよいです。

 

他にポイントとなる関数は以下あたりでしょうか

 

WININET!HttpAddRequestHeadersW

   HTTP Header を追加します

WININET!HttpSendRequestW

   実際にリクエストを行います、第二引数で HTTP Header を指定できます

 

以下は WININET!HttpSendRequestW でブレークしたところです。

Referer や Accept-Langage/User-Agent などなどが見えますね。

ここまで来る場合はリクエスト内容は基本的には出来上がっていますので、コンテンツの問題であることは考えにくくなります。

 

0:003> kv 2

ChildEBP RetAddr  Args to Child              

02cfb3e0 7549d644 00cc000c 06435d00 ffffffff WININET!HttpSendRequestW (FPO: [Non-Fpo])

02cfb64c 7549db50 00000000 06617970 00cc0008 urlmon!CINetHttp::INetAsyncSendRequest+0x6d3 (FPO: [Non-Fpo])

 

0:003> du 06435d00

06435d00  "Referer: http://www.bing.com/?se"

06435d40  "tmkt=ja-JP&setlang=match&uid=A25"

06435d80  "03EA1&FORM=NFTOJP..Accept-Langua"

06435dc0  "ge: ja-JP..User-Agent: Mozilla/5"

06435e00  ".0 (compatible; MSIE 10.0; Windo"

06435e40  "ws NT 6.2; WOW64; Trident/6.0).."

06435e80  "Accept-Encoding: gzip, deflate"

 

さて、実際にユーザーモードのプログラムからは、winsock の send 関数でリクエストが送信されていきます。

以下でブレークしてみましょう。

 

0:003> bp ws2_32!send

0:021> g

 

0:021> kv2

ChildEBP RetAddr  Args to Child             

05fefa48 75614bf1 000009cc 06528090 000003f1 WS2_32!send (FPO: [Non-Fpo])

05fefa94 756149b4 0068e110 05fefae0 0646ca98 WININET!ICSocket::Send_Start+0x21d (FPO: [Non-Fpo])

 

送るデータは第二引数にバイト配列で入っています。

文字列として da で表示してみます

 

0:021> da 06528090

06528090  "GET /?setmkt=ja-JP&setlang=match"

065280b0  "&uid=A2503EA1&FORM=NFTOJP HTTP/1"

065280d0  ".1..Accept: text/html, applicati"

065280f0  "on/xhtml+xml, */*..Referer: http"

06528110  "://www.bing.com/?setmkt=ja-JP&se"

06528130  "tlang=match&uid=A2503EA1&FORM=NF"

06528150  "TOJP..Accept-Language: ja-JP..Us"

06528170  "er-Agent: Mozilla/5.0 (compatibl"

06528190  "e; MSIE 10.0; Windows NT 6.2; WO"

065281b0  "W64; Trident/6.0)..Accept-Encodi"

065281d0  "ng: gzip, deflate, peerdist..Hos"

065281f0  "t: www.bing.com..DNT: 1..Connect"

 

ここで実際に送り出す raw データを確認することができます。send の時点で適切なデータが送り出されていれば、アプリケーション/IE としてはやれることはすべて完了しているといえます。

もしこの時点でのデータが正しくサーバーに届いているデータがおかしい、という場合は、ネットワーク自体やプロキシサーバーなどのネットワーク経路を疑っていく必要があります。

 

上記は単純な例ですが、IEでの通信処理をデバッグする場合の基本事項です。ぜひ参考ください。

また、WS2_32!send/recv/WSASend/WSARecv などは、IE に限らず Windows socket を使っているアプリケーションが必ず通信のために呼び出している関数ですので、他のアプリケーションでのデバッグ作業でも非常に有益です。

 

  * なお、IIS は通信を http.sys というカーネルモードのドライバで行っていますのでこの限りではありません。

 

最後に
上記で使った関数は、いずれも開発者が利用するために公開されている API です。

これらでブレークポイントを設定してデータを確認するだけでも、有効な情報を得られることがご理解いただけたらとてもうれしいです。

 

実際のトラブルシュートでは、さらにネットワークトレースや Fiddler などを組み合わせて効率的に調査ができます。

 

もちろんサポート部門では IE 内部のデバッグをしていくわけですが、その場合でもこういった関数を起点にして調査を開始しています。

まあこんな感じで地味にがんばっていることがわかっていただけましたでしょうか。

 

次回は、「詳細設定」 の画面と対応するレジストリのお話しでもしてみたいなと思います。

それでは

 

Internet Explorer 11 における文字列表示の変更点について

$
0
0

こんにちは、Internet Explorer サポート担当の原です。

本日は、日本のお客様から比較的お問い合わせを多くいただいている、Internet Explorer 11 における文字列表示の変更点を紹介します。

 

Internet Explorer 11 (以下、IE11) において、高 DPI 対応のためにすべてのドキュメント モードでナチュラル メトリックが有効に変更されました。

ナチュラル メトリックでは、解像度に依存せず読みやすいテキストを表示するため、ピクセルにまたがる自動的な間隔調整を行います。

そのため、フォントの表示サイズが一定とはならないことがあります。

また、フォントの表示サイズの調整が行われる結果、すべてのコントロールの表示においても、微妙なサイズの差異が生じます。

 

例えば、以下のテキスト ボックスの表示を比較すると違いがおわかりいただけるでしょう。このテキスト ボックスは、アンダースコア (_) をしきつめています。

 

- IE11

 

- IE10

 

ナチュラル メトリック対応の詳細については、以下のドキュメントでも説明していますのでご覧ください。

 

高 DPI のサポート

http://msdn.microsoft.com/ja-jp/library/ie/dn265030.aspx

 

テキスト レイアウトがナチュラル メトリックを使用する

http://msdn.microsoft.com/ja-jp/library/ff986079.aspx

 

なお、"ローカル イントラネット" および "コンピューター" ゾーンで HTML を表示している場合は、互換性の観点から、IE9 標準モード以降のドキュメント モードでのみナチュラル メトリックを使用します。 

 

対応策について

企業内の Web サイトの場合は、"ローカル イントラネット" ゾーンで表示することにより、IE9 や IE10 と同様の動作になります。

インターネットに公開している Web サイトなど、"ローカル イントラネット" ゾーンで表示することができない場合は、X-UA-TextLayoutMetricsを使用してナチュラル メトリックを無効にできます。

具体的には、HTTP 応答ヘッダー、もしくは meta タグで以下のように指定します。これらのヘッダーや meta タグを指定しても、IE10 以前の従来の動作に影響はありませんので、ご安心ください!

 

- HTTP ヘッダー

X-UA-TextLayoutMetrics: gdi

 

- meta タグ

<meta http-equiv="X-UA-TextLayoutMetrics" content="gdi">

 

[2014 年 4 月 24 日更新]

2014 年 4 月のアップデートでリリースしました IE11 の "エンタープライズ モード" と合わせて設定することで、従来のアプリケーションとの互換性の維持が期待できます。

"エンタープライズ モード" の詳細は、以下のドキュメントをご参考ください。

 

エンタープライズ モードとは

http://technet.microsoft.com/ja-jp/library/dn640687.aspx

 

ナチュラル メトリックを無効にすることでフォントのレンダリングの問題を解決する

http://technet.microsoft.com/ja-jp/library/dn640697.aspx

 

最後に IE11 と IE10 の各セキュリティ ゾーンにおける、ナチュラル メトリックの動作について表でまとめました。

 

- IE11

ドキュメント モード

インターネット

イントラネット

信頼済みサイト

制限付きサイト

コンピューター

IE9 標準以降

有効

有効

有効

有効

有効

IE8 標準以前

有効

無効

有効

有効

無効

 

- IE10

ドキュメント モード

インターネット

イントラネット

信頼済みサイト

制限付きサイト

コンピューター

IE9 標準以降

有効

有効

有効

有効

有効

IE8 標準以前

無効

無効

無効

無効

無効

 

それでは、次回もよろしくお願いいたします!

Internet Explorer サポート技術情報の紹介

$
0
0

こんにちは、Internet Explorer サポート担当の原です。

Internet Explorer サポート チームでは、日本のお客様の事情に配慮し、日本ローカルなサポート技術情報を作成することがあります。

本日は、ここ半年ほどで公開しており、ご参考いただけそうなサポート技術情報を紹介します。

弊社製品の動作でご迷惑をおかけしている内容もございますが、お役立ていただけると幸いです。

 

保護モードが無効のセキュリティゾーンで証明書ダイアログを開くと Internet Explorer の応答が無くなる

http://support.microsoft.com/kb/2939396/ja

 

Internet Explorer 9 以降、TextArea 内の縦書きの文字列をマウスで選択できない場合がある

http://support.microsoft.com/kb/2934585/ja

 

Internet Explorer 11で contenteditable を有効にした div 要素や maxlength を設定したテキスト ボックス内で日本語入力ができないことがある

http://support.microsoft.com/kb/2922126/ja

 

Internet Explorer 11 をビルトイン Administrator で使用すると、名前付きのウィンドウの名前が認識されない

http://support.microsoft.com/kb/2909974/ja

 

Internet Explorer 10 以降で 32 bit の ActiveX コントロールを削除できない場合がある

http://support.microsoft.com/kb/2915345/ja

 

Internet Explorer 9 でテーブルのセルがずれて表示されることがある

http://support.microsoft.com/kb/2904940/ja

 

Internet Explorer 10 で cursor プロパティを変更しても、マウス ポインターを操作するまで反映されない

http://support.microsoft.com/kb/2895749/ja

 

Internet Explorer 10 の input type=file において、選択したファイルのアップロードをキャンセルできない

http://support.microsoft.com/kb/2886300/ja

 

それでは、次回もよろしくお願いいたします!

Internet Explorer の脆弱性 (セキュリティ アドバイザリ 2963983) について

$
0
0

こんにちは、Internet Explorer サポート担当の原です。

4 月 28 日に公開しました Internet Explorer の脆弱性について、ご心配をおかけし申し訳ございません。

取り急ぎとなりますが、現時点で公開している回避策などの詳細について紹介します。

 

[2014 年 5 月 14 日 10:30 追記]

MS14-021 の置き換えとなる新しいセキュリティ更新プログラム MS14-029 を公開しました。

MS14-029 では、MS14-021 で対応している脆弱性の問題に加え、異なる脆弱性の問題を修正しています。

MS14-029 を適用すれば、MS14-021 の適用は必要ありません。

 

なお、MS14-029 は "累積的な" セキュリティ更新プログラムではないことに引き続きご注意ください。

後述の [注意点 2] にあるように、別途最新の累積的なセキュリティ更新プログラムを適用する必要があります。

 

  マイクロソフトセキュリティ情報 MS14-029 - 緊急

  Internet Explorer 用のセキュリティ更新プログラム (2962482)

  https://technet.microsoft.com/ja-jp/library/security/ms14-029

 

[2014 年 5 月 2 日 13:00 追記 15:30 更新]

本脆弱性につきまして、本日セキュリティ更新プログラムを公開しております。セキュリティ更新プログラムの適用をお願いいたします。

更新プログラム本体については、Windows Update で公開されていますが、以下の TechNet サイトからもダウンロードいただけます。

 

  マイクロソフトセキュリティ情報 MS14-021 - 緊急

  Internet Explorer 用のセキュリティ更新プログラム (2965111)

  https://technet.microsoft.com/ja-jp/library/security/ms14-021

 

  文書番号 : 2965111

  タイトル : MS14-021: Security update for Internet Explorer: May 1, 2014

  http://support.microsoft.com/kb/2965111/ja

 

本セキュリティ更新プログラムにつきまして、弊社セキュリティチームでも情報を案内しておりますので、合わせてご覧ください。

 

  セキュリティアドバイザリ (2963983) の脆弱性を解決する MS14-021 (Internet Explorer) を定例外で公開

  http://blogs.technet.com/b/jpsecurity/archive/2014/05/02/security-update-ms14-021-released-to-address-recent-internet-explorer-vulnerability-2963983.aspx

 

Microsoft Update カタログからもダウンロード可能ですので、直接入手される場合は以下もご参考ください。

 

  Microsoft Update カタログ (MS14-021 で検索ください)

  http://catalog.update.microsoft.com/v7/site/Home.aspx

 

[注意点]

本脆弱性への対策として、既に VGX.DLL の登録解除を実施されている場合、上記セキュリティ更新プログラムの適用では VGX.DLL の再登録は行われません。

セキュリティ更新プログラムの適用前に VGX.DLL を再登録しなくても、更新プログラムの適用には成功しますが、VML の描画は依然として行えない状態です。

必要に応じて、VGX.DLL の再登録をご検討ください。

 

[注意点 2]

本日の更新プログラム (MS14-021)のみの適用では、互換性の問題が発生する可能性があります。

そのため、最新の累積的なセキュリティ更新プログラム (MS14-018、IE11 のみ MS14-012) を合わせて適用ください。

 

MS14-018 (IE11 では MS14-012) を適用していなくても、本日の更新プログラム (MS14-021) を適用することができます。

しかしながら、MS14-021 は IE のすべての更新を含む累積的な更新プログラムではないため、合わせて MS14-018 / MS14-012 を適用することを強くお奨めいたします。

また、もしも MS14-021 のみの適用でなんらかの問題が発生する場合も、MS14-018 / MS14-012 の適用により解決する可能性が高いです。

 

---

まずは以下の記事をご覧いただき、対策をご検討くださいますと幸いです。

 

[回避策まとめ] セキュリティ アドバイザリ 2963983 – Internet Explorer の脆弱性により、リモートでコードが実行される

http://blogs.technet.com/b/jpsecurity/archive/2014/04/30/workarounds-for-security-advisory-2963983.aspx

 

セキュリティ アドバイザリ 2963983「Internet Explorer の脆弱性により、リモートでコードが実行される」を公開

http://blogs.technet.com/b/jpsecurity/archive/2014/04/28/2963983-internet-explorer.aspx

 

なお、vgx.dll の登録を解除すると、VML と呼ばれる、線や円などのベクトル図形を表現する記述が含まれる Web ページの描画が行われません。

弊社では現在、脆弱性の修正を含む根本的な対応策を検討しておりますが、この問題に対処するセキュリティ更新プログラムが利用可能になったら、vgx.dll の再登録をご検討ください。

 

[2014 年 5 月 1 日追記]

よくあるご質問をまとめて公開しましたので、以下も是非ご参考ください。

 

[FAQ まとめ] セキュリティ アドバイザリ 2963983 – Internet Explorer の脆弱性により、リモートでコードが実行される

http://blogs.technet.com/b/jpsecurity/archive/2014/05/01/faq-security-advisory-2963983.aspx

 

また、vgx.dll の登録が解除できたかどうかを確認する方法についてお問い合わせをいただいているため、以下に案内します。いずれかの方法でご確認ください。

 

1. レジストリを確認する

vgx.dll の登録が正しく解除できている場合、以下のレジストリが存在しない状態になります。

 

32 ビット環境 (2 )

 ・HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{10072CEC-8CC1-11D1-986E-00A0C955B42E}

 ・HKEY_CLASSES_ROOT\CLSID\{10072CEC-8CC1-11D1-986E-00A0C955B42E}

 

64 ビット環境 (4 )

 ・HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{10072CEC-8CC1-11D1-986E-00A0C955B42E}

 ・HKEY_CLASSES_ROOT\CLSID\{10072CEC-8CC1-11D1-986E-00A0C955B42E}

 ・HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID\{10072CEC-8CC1-11D1-986E-00A0C955B42E}

 ・HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{10072CEC-8CC1-11D1-986E-00A0C955B42E}

 

2. VML のサンプルが表示できるかどうかを確認する

以下の HTML をファイルに保存し、IE 上で表示します。通常ですと青い円が表示されますが、vgx.dllの登録を解除した場合には表示されません。


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" lang="ja">
<head>
<meta http-equiv="X-UA-Compatible" content="IE=5" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>VML TEST</title>
<style type="text/css">
 v\:line, v\:rect, v\:roundrect, v\:oval { behavior: url(#default#VML); display:inline-block; }
</style>
</head>
<body>
VML Oval TEST<BR>
<v:oval style='width:200px;height:100px' fillcolor='blue' />
</body>
</html>

 

---

より詳細な情報をお求めの場合は、以下のセキュリティ アドバイザリをご覧ください。

今後の最新情報は、わかり次第以下のサイトに追記してまいります。

 

マイクロソフトセキュリティアドバイザリ 2963983

Internet Explorer の脆弱性により、リモートでコードが実行される

https://technet.microsoft.com/ja-JP/library/security/2963983

 

どうぞよろしくお願いいたします。

IE の新しいバージョンを自動的にインストールさせない

$
0
0

こんにちは。Internet Explorer サポート担当の太田です。

今回は IE の新しいバージョンを自動的にインストールさせない方法について紹介させていただきます。

 

IE の新しいバージョンを自動的に更新させないためには 2 種類の方法がございます。

 

    1. IE の設定 [バージョン情報] から自動インストールの旨のチェックを外す。

    2. Blocker Toolkit を使用する。

 

これらは Windows Update のみに有効で、WSUS や SCCM で管理されている環境では有効ではございません。

今日はこられらの設定における、それぞれの動作についてご紹介させていただきます。

 

    0. 既定の状態

    1. IE の設定における、[バージョン情報] から自動インストールのチェックを外す

    2. Blocker Toolkit を使用する

 

それでは、実際に Windows7 の IE10 環境で IE11 に更新されないようする方法を、順に確認してみます。

 

 

0. 既定の状態

まずは既定の設定の状態です。

IE 上の設定のマークより [バージョン情報]の項目にて、「新しいバージョンを自動的にインストールする」にチェックが入っています。

 

 

 

この項目は通常の Windows Update を実施したときの動作に影響がでるものです。

(個別に IE から、IE の新しいバージョンが出ていないか定期的にチェックするものではございません。)

 

では、この状況で Windows Update を実施してみましょう。

結果として「重要」な更新として表示されます。

 

 

このため、Windows Update の設定にて「更新プログラムを自動的にインストールする(推奨)」としている場合には

自動インストールの対象となります。

 

 

1. IE の設定 [バージョン情報] から自動インストールの旨のチェックを外す

 次に、上記の [バージョン情報]から「新しいバージョンを自動的にインストールする」にチェックを外してみます。

 

 

この状況で Windows Update を実施してみましょう。

結果として「オプション」項目に入りました。

 

 

このため、基本的にはインストールは自動的にされない状態となります。

インストールしたい場合には、チェックを入れて意図的にインストールを行います。

 

 

2. Blocker Toolkit を使用する

 各バージョンでもリリースされている自動配布の無効化ツールキット IE11 の Blocker Toolkitを導入してみます。

サイトよりダウンロードを行い、手順に従い適用を行います。

コマンド プロンプトで「ie11_blocker.cmd /B」と入力し、Enter キーを押します。

  

この状況で Windows Update を実施してみましょう。

結果として「重要」にも「オプション」にも表示されない状況となりました。

 

 

これだと Windows Update からはインストールが出来ない状態となります。

 

なお、今回は Windows 7 での IE11 をブロックするご紹介でしたが、

Blocker Toolkit はブロックしたい全てのバージョンに対し、それぞれ適用する必要がございます。

例えば、IE8 環境にて、IE8 以降のバージョンをブロックしたいのであれば、

IE9, IE10, IE11 の全ての Blocker Toolkit を適用する必要があります。

 

Internet Explorer 11 自動配布の無効化ツールキット

http://www.microsoft.com/ja-jp/download/details.aspx?id=40722

 

Internet Explorer 10 自動配布の無効化ツールキット

http://www.microsoft.com/ja-jp/download/details.aspx?id=36512

 

Internet Explorer 9 自動配布の無効化ツールキット

http://www.microsoft.com/ja-jp/download/details.aspx?id=179

 

Internet Explorer 8 自動配布の無効化ツールキット

http://www.microsoft.com/ja-jp/download/details.aspx?id=3060

 

ご紹介は以上となります。

 

ご状況に応じてお使いいただければ幸いです。

どうぞよろしくお願いします。

MS14-021 や MS14-029 適用後に IE の動作に問題が発生する

$
0
0

こんにちは。Internet Explorer サポート担当の太田です。

本件お問い合わせをいただくことが多いため、改めて投稿させていただきます。

 

MS14-021MS14-029適用後に、IE の表示がおかしい、起動しなくなった。

といったお問い合わせをいただくことが多くあります。

これは、IE の最新の累積的な更新プログラムを適用することで問題が解消する可能性がございます。

 

 

このためMS14-021もしくは、それを包括しているMS14-029を適用する場合には、

合わせて、IE の最新の累積的な更新プログラムの適用も合わせてご検討いただければ幸いです。

(この記事を記載時点の IE の最新の累積的な更新プログラムはMS14-018IE11 のみ MS14-012となります。)

 

お手数をおかけし申し訳ございません。

よろしくお願いします。


今日からできる!再現サンプルを作成しよう!

$
0
0

Internet Explorer サポートの藤代です。

 

IEで発生する問題についてお問い合わせを頂きご支援を承る上で、問題の切り分けがとても重要です。

Web アプリケーションでは、IE の挙動のみではなくHTML/CSS の構成内容、JavaScript の処理内容、通信、Web サーバーの処理等多くの要素が存在します。

 

しかし、問題はイントラネット等限られた社内からのみしかアクセスできない Web アプリケーションで発生する事があります。

また、表面的には同一の事象に見えても、技術的にはポイントが異なることも多々ある為、文面や口頭でお伝え頂く内容のみでは有益な調査が行えない場合があります。

 

調査をより有益なものとし、かつ、より迅速に情報のご提供に繋げられるよう、「シリーズ : 問題の切り分け」と題し、よくあるシナリオ例をベースに私たちの調査ノウハウについてご紹介をしていきたいと思います。

 

シリーズ : 問題の切り分け part1 は『今日からできる!再現サンプルを作成しよう!』です。

~~・~~・~~・~~・~~・~~・~~・~~・~~・~~・~~・~~・~~・~~・~~・~~・~~・~~・

お問い合わせ状況例

提供している Web システムを利用するユーザーからあるコンテンツのページの表示状態が崩れるという申告があった。

以下のような理由で再現サンプルを作成できていない。

 

  1. Web サーバーはユーザー環境のイントラネットに構築されており、手元からはアクセスできない

  2. Web システムは Java/ASP.NET などで作成されており、データーベースからデータを取得し表示するような仕組みである。

    データベース等が必要であり複雑な構成であることから一部を切り出す事が難しい

 

問題の初診

このような事象では事象発生時/非発生時のスクリーンショットを比較することが状態を理解する為の First Step になります。

但し、以下のような事も理解しておかなくてはいけません。

 

・Web サーバー側でどのような技術が用いられていても、基本的には “クライアント” で受信するものは HTML/CSS/JavaScript/画像 等で構成されたコンテンツである

・ブラウザでの表示上、同じように見えるコンテンツでも HTML/CSS 等の指定方法は無数に存在する

 

つまり、画面のスクリーンショット等の表面上の状態や「サーバー側の処理の部分的な抜粋」ではクライアント上で受信する HTML の内容が把握できず、より詳細な調査を行う事は多くの場合困難です。

この為、IE 上における表示上の問題については何とかして「HTML/CSS/JavaScript 等でクライアントで動作するサンプル」を切り出す必要があります。

 

再現サンプルの作成方法

大きく分けて以下のような手法があります

  1. IE が受信し表示に利用しているデータを保存する

  2. 実際の HTTP の通信内容で受信しているデータから再現コンテンツを生成する

 

今回は、まず a について、いくつかの手法をご紹介します。

 

a. IE が受信し表示に利用しているデータを保存する

============================

a-1 : Web ページを保存する

 調査対象となるページを表示し [ファイル] – [名前を付けて保存] を選択します。

 [Web ページの保存] のダイアログで最下部の [ファイルの種類] で “Web ページ、完全 (*.htm; *.html) を選択し名前を付けて任意のディレクトリに保存します。

 

 指定したディレクトリに <名前>.htm という HTML コンテンツと <名前>.files というフォルダーが作成されます。

 フォルダー内には CSS/JavaScript/画像等のページを構成するリソースが含まれます。

 

※メニューバーが表示されていない場合は Alt キーを押下してください

 

 

※以降のより詳細な切り分けのため、必ず Web ページ、完全でコンテンツを保存します

 

a-2 : F12 開発者ツールを用いて部分的に抜粋する

 事象の発生状態に画像は直接的には関連せず、HTML/CSS で一部分を抜粋できればよいときには F12 で開発者ツールを開きます。

 開発者ツールで対象となる部分をフォーカスし、その部分のスタイル付きの要素を抽出します。

 

 バージョンにより若干操作方法が異なりますが、以下のスクリーンショットを参考にしてください。

 

IE10/IE11 の場合

※テキストエディターなどに貼り付け html 形式として保存します

 

IE8/IE9 の場合


※表示された要素付きのソースをコピーしテキストエディターなどに貼り付け html 形式として保存します

 

いかがでしょうか。

このように保存・抽出したコンテンツを直接開く、もしくは、Web サーバーに配置し、実際のコンテンツと同じセキュリティゾーンでアクセスする等の方法で事象の再現性を確認します。

 

保存・抽出したコンテンツには事象とは直接関連性のない構成要素も含まれます。

さらにサンプルを最小化する為には以下のような事を繰り返していきます。

  1. テキストエディター等で HTML を開き事象に不要と思われる箇所を削る。再度表示して事象を確認するを繰り返し、発生ポイントを絞り込む。

  2. F12 開発者ツールを駆使し、スタイルの指定を解除/一時的な編集等を行い、関連するポイントを絞り込む。

 

地道な作業ですが、構成要素をシンプル化することで事象の状況がさらに見えてきます。

また、回避策/対処方法をお手元で確認することができ、お問い合わせにかかる時間やお手間を軽減できるかと思います。

 

お問い合わせを頂く場合

描画関連の問題でお問い合わせを頂く際には、是非、上記のような切り分けの結果のシンプルなサンプルコンテンツと、保存/抽出直後のコンテンツを合わせてご提供ください。

 ※保存/抽出直後のコンテンツはより妥当で容易な回避策の検討に利用させて頂きます。

 

描画に関連する事象は多くの場合、コンテンツでの変更/修正による対応をお願いさせて頂く事が多いものですが、ここに至る切り分けや対処方法の検討は実はお手元でも実施頂くことができます。

今回は対象のコンテンツにアクセスできる前提で、サンプルの作成手法についてご紹介しましたが、ご参考となれば幸いです。

参考情報

Windows Internet Explorer 8 開発者ツールを使用してサイトを修正する

開発者ツールでの HTML および CSS のデバッグ

Internet Explorer Big Changes! (4) - アドオン管理の強化 (IE9 ~)

$
0
0

こんにちは、Internet Explorer サポート担当の原です。

Internet Explorer (IE) における過去の大きな変更点を中心に、互換性に影響する情報をおさらいしていきます。

第 4 弾は、IE9 以降のアドオン管理に関する変更点を紹介します。

 

アドオン管理の強化

IE9 以降では、アドオン管理に関する変更点として、以下の 2 つの機能があります。

 

1) 新たにインストールされたアドオンを有効にするかどうかをユーザーに通知する

2) 読み込みに時間がかかるアドオンがある場合にユーザーに通知する (アドオン パフォーマンス アドバイザー)

 

アドオン パフォーマンス アドバイザー

http://windows.microsoft.com/ja-JP/internet-explorer/products/ie-9/features/add-on-performance-advisor

 

Add-ons: Staying in control of your browsing experience (英語)

http://blogs.msdn.com/b/ie/archive/2010/09/17/add-ons-staying-in-control-of-your-browsing-experience.aspx

 

ただし、上記機能は BHO (Browser Helper Object) やツール バーなどの "ブラウザー拡張" に対してのみに働きます。

ActiveX コントロールのようなページごとに動作する "コンテンツ拡張" に対しては働きません。

 

IE9 以降では、BHO やツール バーの動作がユーザーの選択によって無効にされる可能性が高まります。

BHO やツール バー側の実装により上記機能を回避はできませんが、グループ ポリシーにより機能を制御できます。

以下の 2 つのポリシーが該当します。

 

[新しくインストールされたアドオンを自動的に有効にする]

[アドオンのパフォーマンス通知を無効にする]

 

グループ ポリシーの詳細は、以下のドキュメントをご覧ください。

 

Internet Explorer 9 のグループ ポリシー

http://technet.microsoft.com/ja-jp/library/gg699401.aspx

 

プラグイン フリー

マイクロソフトでは、Web 標準に準拠し、すべてのユーザー、あらゆるデバイスで機能する Web サイトの開発を推奨しています。

そのためには、BHO などの "ブラウザー拡張" や ActiveX などの "コンテンツ拡張"、いわゆるプラグインに依存しない必要があります。

 

上述の背景により、IE9 以降、ピン留めサイト (Pinned Site) においては、BHO やツール バーなどの "ブラウザー拡張" は動作しません。

また、Windows 8 / 8.1 の新しい Windows UI の IE においては、"ブラウザー拡張" および "コンテンツ拡張" のすべてのアドオンが動作しません。

 

なお、一時的な対応策として、新しい Windows UI の IE から、デスクトップの IE への切り替えをユーザーに促すオプションがあります。

具体的には、HTTP 応答ヘッダー、もしくは meta タグで以下のように指定します。

 

- HTTP ヘッダー

X-UA-Compatible: requiresActiveX=true

 

- meta タグ

<metahttp-equiv="X-UA-Compatible"content="requiresActiveX=true">

 

Web のプラグイン フリー化と Web サイト

http://blogs.msdn.com/b/ie_ja/archive/2012/02/02/web-web.aspx

 

Windows 8 と Windows 8.1 でのプラグインと ActiveX のサポート

http://msdn.microsoft.com/ja-jp/library/ie/hh920753.aspx

 

それでは、次回もよろしくお願いいたします!

早わかり!エンタープライズ モード

$
0
0

こんにちは、Internet Explorer サポート担当の原です。

本日は、2014 年 4 月のアップデートでリリースしました、Internet Explorer 11 の "エンタープライズ モード" の効果をおさらいしましょう。

 

まず、エンタープライズ モードの全体像については、以下のドキュメントをご覧ください。

 

  Internet Explorer 11 向けエンタープライズ モードを利用して常に最新の環境を確保

  http://blogs.msdn.com/b/ie_ja/archive/2014/04/16/stay-up-to-date-with-enterprise-mode-for-internet-explorer-11.aspx

 

  エンタープライズ モードとは

  http://technet.microsoft.com/ja-jp/library/dn640687.aspx

 

ここでは、エンタープライズ モードの主要な特徴を説明します。

 

動作モード

Internet Explorer 8 (以下、IE8) 相当になります。

最新のドキュメント モードは IE8 標準モードとなり、IE8 と同様の判断でドキュメント モードを決定します。

 

有効化の方法

[ツール] - [エンタープライズ モード] メニューから手動で行うか、グループ ポリシーで有効化できます。

なお、[エンタープライズ モード] メニューを表示するためには、レジストリかポリシーの設定が必要です。

 

  エンタープライズ モードを有効にしてサイト一覧を使う

  http://technet.microsoft.com/ja-jp/library/dn640699.aspx

 

  エンタープライズ モードのローカル制御とログを有効にする

  http://technet.microsoft.com/ja-jp/library/dn640690.aspx

 

設定できる単位

ドメイン、サブ ドメイン単位だけでなく、URL のパスまで指定して細やかに制御できます。

 

  Enterprise Mode Site List Manager を使ってエンタープライズ モードのサイト一覧にサイトを追加する

  http://technet.microsoft.com/ja-jp/library/dn640689.aspx

 

ユーザー エージェント文字列

IE8 と同等のユーザー エージェント文字列を送信します。

例えば、Windows 8.1 の IE11 では、以下のようになります。

 

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729; BRI/2; InfoPath.3; Tablet PC 2.0)

 

X-UA-Compatible の解釈

IE8 では、X-UA-Compatible に複数のドキュメント モードを指定した場合、最初のひとつが有効になります。

エンタープライズ モードでは、X-UA-Compatible の解釈が IE8 と同等になります。

例えば、以下のような meta タグがある場合、エンタープライズ モードでは IE7 標準モードになります。

 

<meta http-equiv="X-UA-Compatible" content="IE=7,IE=8">

 

一方、IE9 以降は X-UA-Compatible に複数のドキュメント モードを指定すると、その中で最新のモードが有効になります。

そのため、エンタープライズ モードが有効でなければ、上記の例では IE8 標準モードになります。

 

拡張保護モードの無効化

エンタープライズ モードでは、拡張保護モードの設定が有効でも、拡張保護モードを無効化します。

拡張保護モードが有効な場合、拡張保護モードと互換性がないすべてのアドオンが動作しない問題を救います。

拡張保護モードの詳細は、以下のブログ記事をご覧ください。

 

  IE10 & IE11 : 拡張保護モードの実態

  http://blogs.technet.com/b/jpieblog/archive/2013/11/30/3614857.aspx

 

ナビゲーションの高速化機能の無効化

IE11 では、"プリレンダリングとプリフェッチ" および "戻るナビゲーションのキャッシュ" という高速化機能を実装しています。

一部のブラウザー ヘルパー オブジェクト (BHO) やツール バーで生じる、これらの高速化機能との互換性の問題を救います。

 

  プリレンダリングとプリフェッチのサポート

  http://msdn.microsoft.com/ja-jp/library/ie/dn265039.aspx

 

  戻るナビゲーションのキャッシュ

  http://msdn.microsoft.com/ja-jp/library/ie/dn265017.aspx

 

CSS expressions (CSS 式) のサポート

IE11 以降、CSS 式はインターネット ゾーンに読み込まれた Web ページでは無効になりました。

エンタープライズ モードでは、CSS 式が有効に機能します。例えば、以下のような記述です。

 

<div style='font-size: 18pt; text-align: center;' ID='oDiv'

  style='background-color: #CFCFCF; position: absolute;

         left: expression(document.body.clientWidth / 2 - oDiv.offsetWidth / 2);

         top: expression(document.body.clientHeight / 2 - oDiv.offsetHeight / 2)">

Centered DIV

<div style='font-size: 8pt;'>via CSS expressions</div>

</div>

 

  インターネット ゾーンにおける CSS 式のサポート停止

  http://msdn.microsoft.com/ja-jp/library/ie/dn384050.aspx

 

clientCaps ビヘイビアのサポート

IE10 以降、clientCaps ビヘイビアは廃止されました。

エンタープライズ モードでは、clientCaps ビヘイビアが有効に機能します。例えば、以下のような記述です。

 

<body style='behavior: url(#default#clientCaps);'>

Browser version via clientCaps behavior is

<script>

document.write(document.body.getComponentVersion("{89820200-ECBD-11CF-8B85-00AA005B4383}", "ComponentID"));

</script>

</body>

 

  clientCaps Behavior (英語)

  http://msdn.microsoft.com/en-us/library/ms531416.aspx

 

スクリプト バージョン関数

エンタープライズ モードでは、以下のスクリプト バージョン関数が、IE8 相当の結果を返却します。

一部の Web ページは、スクリプト バージョンを厳密にチェックするため、互換性の問題を救います。

 

ScriptEngineBuildVersion

ScriptEngineMajorVersion

ScriptEngineMinorVersion

 

  JScript 関数

  http://msdn.microsoft.com/ja-jp/library/cc392026.aspx

 

以上です。

IE11 のエンタープライズ モードを活用し、最新の Web 技術と企業資産が共存できる環境を構築ください!

それでは、次回もよろしくお願いいたします!

”Internet Explorer の メンテナンス”廃止に伴う代替案の紹介 - Part1.基本設定の紹介とプロキシ設定の配布

$
0
0

 

Internet Explorer サポートの 杉谷 です。

 

既にご存知の方も多いかと存じますが、グループ ポリシーの『Internet Explorerのメンテナンス』(メンテナンス ポリシー)がIE10以降の環境で廃止されております。

 

そのため、IE10以降がインストールされている環境では、グループ ポリシー/ローカル グループ ポリシー においてメンテナンス ポリシー項目が削除され構成できません。

 

また、メンテナンス ポリシーが配布された場合も値が反映されません。

 

本ブログでは、いくつか存在するメンテナンス ポリシーの代替案の中で”グループ ポリシー”という観点から、管理が最も容易な『基本設定』についてご紹介します。

 

基本設定の種類(IE関連)

IE関連の設定を構成する主な基本設定項目は以下の3種類です。

 

インターネット設定 --- メンテナンスポリシーの代替項目(インターネットオプションと類似のGUIから構成)

レジストリ --- インターネットオプションの設定に対応するレジストリ値を配布します

ショートカット --- IEの観点では”お気に入り”を構成する項目です

 

これらの項目は、配布元 / 配布先のOSやIEのバージョンによって配布可否が異なります(以下の表をご覧ください)。

 

配布元/配布先OSとIEバージョンによる 配布可否

 

Windows Server 2003 R2

インターネット設定 非対応
レジストリ 非対応
ショートカット 非対応
メンテナンス ポリシー IE9までの環境に配布可能

 

Windows Server 2008 R2(IE10以降インストールなし)

Windows 7(IE10以降インストールなし)

インターネット設定 IE9までの環境に配布可能
レジストリ IE10以降の環境にも配布可能
ショートカット IE10以降の環境にも配布可能
メンテナンス ポリシー IE9までの環境に配布可能

 

Windows Server 2008 R2(IE10以降インストール済み)

Windows 7(IE10以降インストール済み)

インターネット設定 IE9までの環境に配布可能
レジストリ IE10以降の環境にも配布可能
ショートカット IE10以降の環境にも配布可能
メンテナンス ポリシー 非対応

 

Windows Server 2012 / Windows Server 2012 R2

Windows 8 / Windows 8.1

インターネット設定 IE10以降の環境にも配布可能
レジストリ IE10以降の環境にも配布可能
ショートカット IE10以降の環境にも配布可能
メンテナンスポリシー 非対応

※Windows VISTA / 7 / 8 / 8.1 等のクライアント OS からの GPO編集は、リモートサーバー管理ツール (RSAT) を使用することで実現可能です(後述します)

 

メンテナンス ポリシーの主な代替方法となる”インターネット設定”をIE10以降に配布する場合、表の通り Windows Server 2012 / Windows 8 以降の環境が必要です。

 

環境がご用意できない場合は、IE の全バージョンに対応した”レジストリ配布”も可能ですが、配布項目のレジストリを把握する必要があります。

また、プロキシサーバーのレジストリについては、非公開のバイナリ値が含まれており、長期的な観点からフォーマット変更の恐れもあるためレジストリでの管理はお勧めしていません。

 

上記のように基本設定の”レジストリの配布”については若干面倒な部分もあり、管理の容易さという観点から”インターネット設定”が可能な環境をご用意頂くこ とをお勧めしています(これを機に対応機種のご用意を検討頂けますと幸いです)。

 

では、実際に基本設定でのインターネット設定手順を見ていきましょう。

ここでは IE10以降のクライアントに対して プロキシ設定のアドレス / ポート / 例外設定等を構成してみます。

 

基本設定のインターネット設定の前提: 各項目の緑/赤線について

各設定項目の『緑/赤線』は、その時点での配布可否を表しており、『緑は配布可』/『赤は配布不可』となっております。

配布可否の状態は、以下のようにファンクションキーで切り替えることができます。

 

 ・画面上の全項目を有効(全て緑)にする:F5

 ・画面上の全項目を無効(全て赤)にする:F8

 ・選択中の項目を有効にする(項目のみ緑):項目選択中にF6

 ・選択中の項目を無効にする(項目のみ赤):項目選択中にF7

 

タブ操作等で開いた際に配布可(緑)で表示されている項目は、"OK"で閉じた時点で配布対象となってしまいます。

そのため、特に配布する必要のない画面を開いた場合は、『キャンセル後再度編集する』か『F8で配布不可にする』ことをお勧めします。

 

基本設定のインターネット設定の手順

1.[グループ ポリシー管理エディター]を開きます。

 

2.[ユーザーの構成] > [基本設定] > [コントロール パネルの設定] > [インターネット設定] を選択します。

 

3.[インターネット設定]を右クリックし、[新規作成] > [Internet Explorer XX] (配布先のバージョン) を選択します。

 (IE11項目がありませんが、IE10項目を構成することでIE11への配布が可能です)

 

 

4-1.最初に[全般タブ]が開かれるので、各項目にある点線を”未配布”に構成します

 

 

4-2.続けて[接続]タブを開き、”プロキシ サーバーを構成する…”を選択し”未配布”に構成します

 

 

4-3.[LANの設定]項目から、要件に応じた設定を構成します

 

※参考:例外設定を追加したい場合は[詳細設定]から登録できます。

※参考:[自動構成スクリプトを使用する]を構成する場合はアドレス欄を構成するのみで自動でチェックが入ります

 

 

4-4.必要に応じて[詳細設定]から例外設定を登録します

 

 ※参考:[すべてのプロトコルに同じプロキシ サーバーを使用する] のチェックは非対応です。

     (基本設定では[使用するプロキシのアドレス]に表示されている内容を配布します)

 

 

5.クライアント環境に"一度だけ"適用したい場合は、[共通]タブにおいて [1度だけ適用し、再適用しない] にチェックを入れます

 

 

6.[OK]で設定画面を閉じると作成した設定が追加されます(ログオン等のGPO適用のタイミングでクライアント環境に値が反映されます)

 

 

7.実際に配布される項目は、グループ ポリシー オブジェクト(GPO)を選択した際に右側に表示される画面の[設定]タブにて確認可能です

 

基本設定については以下のような参考情報もございますのでぜひご覧ください。

 

  ◇基本設定項目の設定を有効または無効にする

    http://technet.microsoft.com/ja- jp/library/cc754299.aspx

 

  ◇共通オプションを構成する

    http://technet.microsoft.com/ja- jp/library/cc772371.aspx

 

プロキシ設定の構成時における注意点

インターネット設定において『プロキシ項目の構成時に項目がグレーアウトとなり設定が反映されない』という問題が発生する場合があります。

この場合、以下の修正を適用頂くことで問題が解消されます。

 

  ◇Internet Explorer 10 プロキシを設定するグループ ポリシー オブジェクトが壊れています

    http://support.microsoft.com/kb/2928422

 

※Windows Server 2012 R2 / Windows 8.1 の場合は、以下の更新プログラムをインストールしてください。

 

  ◇Windows RT 8.1、8.1 の Windows、および Windows Server 2012 の R2 の更新プログラム: 2014 年 4 月

    http://support.microsoft.com/kb/2919355

 

サーバーOS以外からの設定(リモートサ ーバー管理ツール)

ドメインに参加しているクライアントOS からでもリモートサーバー管理ツール(RSAT)を使うことでサーバーOS上のGPOを編集することができます。

 

例えば、IE10以降へのインターネット設定配布に対応していない環境(Windows Server2008 R2等)にドメイン参加しているRSATインストール済みのWindows 8以降の環境から、

IE10以降の環境に配布可能なインターネット設定を構成するといった管理が可能です。

 

  ◇Windows Vista 用 Microsoft リモート サーバー管理ツール

    http://www.microsoft.com/ja- jp/download/details.aspx?id=21090

 

  ◇Windows 7 Service Pack 1 (SP1) 用のリモート サーバー管理ツール

    http://www.microsoft.com/ja- jp/download/details.aspx?id=7887

 

  ◇Windows 8 用のリモート サーバー管理ツール

    http://www.microsoft.com/ja- jp/download/details.aspx?id=28972

 

  ◇Windows 8.1 用のリモート サーバー管理ツール

    http://www.microsoft.com/ja- jp/download/details.aspx?id=39296

 

インストール後 [コントロールパネル] > [システムとセキュリティ]> [管理ツール]より[グループポリシー管理]を選択し、対象となるGPOを開き編集します。

 

※項目がない場合は、[コントロールパネル] > [プログラム] > [Windows の機能の有効化と無効化] より

   [リモートサーバー管理ツール] > [機能管理ツール] > [グループポリシー管理用のツール]を有効にします。

 

※GPOの編集にはドメインに対する編集権限(Domain Admins等)が必要です

 

Windows Server 2008/Windows 7 環境か らIE9 への基本設定配布について

Windows Server 2008 R2 や RSATを使用したWindows 7 から基本設定をIE9のクライアントに対して配布する場合は下記の修正プログラムを適用する必要がございます。

 

  ◇Internet Explorer Group Policy Preferences do not apply to Internet Explorer 9 in a Windows Server 2008 R2 domain environment

    http://support.microsoft.com/kb/2530309

 

※RSATで構成する場合は、Windows 7環境に適用してください

※適用後も新規作成時はIE8までしか選択できませんが、IE8項目から構成することでIE9へも配布可能となります。

 

 

いかがでしたでしょうか。

 

今回は基本設定の『対応環境』と『インターネット設定』についてご紹介しました。

 

ちなみに、各セキュリティゾーンのURLについては、インターネット設定から構成することができず、

クライアント環境にて変更可能な状態で配布する場合『レジストリ項目』を構成する必要があります…。

 

次回は基本設定での『レジストリ項目』について紹介したいと思います。

 

2530309

Internet Explorer 関連のトラブルシュート ~Fiddler 編~

$
0
0

こんにちは、Internet Explorer サポートの片岡です。

私からは、Internet Explorer サポート チームで実際に調査を行う際に使用するツールについてご紹介していきたいと思います。

 

第一弾として、今回は Fiddler というツールをご紹介します。

Fiddler とは、HTTP(S) の通信ログを取得するツールです。しかも、Fiddler HTTP の通信ログを取得するだけでなく、そのログから様々な検証が行えるため、私たちは非常に重宝しています。

 

今回のブログの目次は以下の通りです。

 

0. Fiddler をインストールする

1. Fiddler で通信ログを取得する

2. HTTP レスポンスを編集する

3. ログを使用して事象を復元する

 

スクリーン ショットなども交えつつ、具体的な使用方法をご紹介していきます。

 

0. Fiddler をインストールする

Fiddler は、以下の URL からダウンロード/インストールができます。[Free download] のボタンがありますので、クライアントにインストールされている .NET Framework に合ったバージョンをインストールしてください。

 

 Fiddler

 http://www.telerik.com/fiddler


1. Fiddler で通信ログを取得する

インストールされた Fiddlerを開くと、下記のスクリーン ショットの画面が起動します。この画面から、[File] [Capture Traffic] を選択することで、通信ログの採取が開始されます。(画面左下に “Capturing” と表示されましたら、採取中の状態です)

あとは、IE を起動して事象を再現させることで、事象発生時の通信ログを採取することが可能です。なお、事象を再現したあとは、再度 [File] [Capture Traffic] を選択し、採取を停止してください。


            

下記のスクリーン ショットは、IE11 から Bing へアクセスした際の HTTP 通信ログです。左ペインで詳細を見たい通信を選択することで、右ペインに詳細が表示されます。

スクリーン ショットは、実際の HTTP 通信の中身を表示したものであり、赤で囲った部分が HTTP リクエスト、緑で囲った部分が HTTP レスポンスです。リクエスト/レスポンスを同時に確認できるのも、Fiddler の便利なところです。


           

 

上記の方法で取得したログは、[File] [Save] から保存することができます。保存をする場合は、[All Sessions] [Selected Sessions] など、通信を指定して保存することが可能です。

なお、詳細は後述いたしますが、保存したログを使用することで、通信内容を復元することができます。

 

 
2. HTTP レスポンスを編集する

HTTP レスポンスとは、Web ブラウザからの HTTP リクエストに対する、Web サーバーからの応答です。HTTP レスポンスには、以下のような情報が含まれています。

 

HTTP 応答ヘッダー (HTTP ステータス コードや CookieContent-Type などが含まれています)

・コンテンツ ボディー (IE 内に表示される HTML ファイルです)

 

Fiddler を使用することで、HTTP 応答ヘッダーや実際の HTML コンテンツを編集することができます。では、スクリーン ショットを見ながら実際に Bing へアクセスする際の HTTP レスポンスを編集してみましょう。

 

2-0. 事前準備

メニュー バーから、[Rules] [Automatic Breakpoints] [After Responses] を選択します。この設定を行うと、画面左したに以下のようなマークが表示されます。これで準備は完了です。


           

 

2-1. HTTP 応答ヘッダーを編集する 

HTTP 応答ヘッダーを編集してみます。まずは、上記の設定がされた状態で、Web ページへアクセスしてみます。その結果、IE HTTP レスポンスを受信する前に、一旦通信がストップします。(IE の画面は白いまま止まります)

下記の画面のようになるので、あとは左ペインから HTTP 応答ヘッダーを編集したい通信を選択し、右ペインで編集を行います。



           

今回は、”Content-Type” の値を編集してみましょう。具体的な手順は以下の通りです。

 

1) 上記スクリーン ショットにて、赤枠で囲った [Inspectors] を選択し、その下のタブから [Headers] を選択します。(今回はレスポンスを編集するため、下側のウィンドウで操作をします)

2) ヘッダー一覧の中から、“Content-Type: text/html; charset=utf-8” を選択して右クリックし、[Edit Header] を選択します。

3) [Header Editor] ダイアログが表示されますので、"Value" の値を任意の値に書き換え、[Save] を押下します。

4) 上記スクリーン ショットの緑のボタン ([Run to Completion]) をクリックします。

 

同様の手順で Cache Cookie も編集できるため、この機能を使用して様々な検証を行っています。


2-2. コンテンツ ボディーを編集する 

上記と同様の手順で、HTML ファイルそのものを編集することもできます。HTML ファイルを編集する場合は、[Inspectors] を選択した後に、[Raw] のタブを選択します。[Raw] タブを選択すると、HTTP レスポンスが表示されます。その内容は直接編集することができますので、その内容を書き換えることで Web ページの内容そのものを編集できます。

例えば、Bing へアクセスした際の HTML タグの内容をすべて削除すると、白紙の Web ページが表示されます。

 

3. ログを使用して事象を復元する

レスポンスの内容を編集するだけでなく、実際の通信ログのみから、現象を再現することも可能です。

この機能のすごいところは、Web サーバーなどの環境が一切必要ないことです。HTTP の通信ログのみから現象を再現できるため、例えば再現コンテンツの作成ができない、特定の環境でしか発生しない事象でも、事象発生時の Fiddler ログがあれば、再現確認/調査が可能となります。

 

今回は、Bing へアクセスする際の動作を実際にログから再現してみましょう。事前準備として、Bing にアクセスした際の Fiddler ログを保存し、それをダブル クリックで開いてください。

Fiddler ログを開いたあとは、以下の手順で事象を再現することができます。

 

1) IE を起動し、[インターネット オプション] – [接続] タブから、以下のプロキシを設定します。なお、Fiddler を起動すると自動でプロキシの設定が行われる場合もございますので、その場合設定は不要です。また、Fiddler を終了した際は、プロキシが元の設定に戻っているかをご確認ください。

 

     アドレス:localhost

     ポート:81

 

2) 右ペインから、[AutoResponder] タブを選択します。

3) 左ペインに記録されている通信ログをすべて選択し、右ペインにドラッグ & ドロップします。

4) [File] – [Capture Traffic] を設定し、画面左下が “Capturing” となっていることを確認します。

5) 右ペインから、再現したい通信を選択して右クリックし、[Open URL] を選択します。今回は、Bing にアクセスする際の動作を再現したいので、一番上の “http://www.bing.com” を選択して、右クリックします。

6) [Open URL] を選択すると、IE が起動し、Bing のページが表示されます。


           

 

 

今回のブログは以上となります。

繰り返しとなりますが、Fiddler のすごいところは Web サーバーなどの再現環境がない場合でも事象が再現でき、かつその通信内容を編集することができる点です。

みなさまもぜひ Fiddler を使いこなして、Web ページに繋がらないなどの事象に対するトラブルシュートをしてみてください!


Viewing all 141 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>