Hebikuzure's Tech Memo

2015年3月28日

WinSxS フォルダーのクリーンアップ

Filed under: Windows Tips — hebikuzure @ 12:28 PM

WinSxS フォルダーのクリーンアップ
https://technet.microsoft.com/ja-jp/library/dn251565.aspx


Windows Vista / Windows Server 2008 以降の Windows では、Windows のコンポーネントや更新プログラムのインストールの際に WinSxS フォルダーが「ステージング」領域として利用され、必要なファイルがいったん WinSxS フォルダーにコピーされた後で実際のファイルの置き換えや配置がハードリンクの作成によって行われる動作になっています。この動作についてはサポート技術情報「Windows Vista および Windows Server 2008 で、Service Pack および修正プログラムの適用後にブート パーティションの使用領域が増加する」で解説されており、またこのブログでも以前に「Windows Vista では %windir%¥WinSxS フォルダーが肥大する」という記事で紹介しています。この記事はかなり古い物ですが今でもよくアクセスしされているので、ディスクの空き容量が不足している場合に WinSxS のサイズが大きくなっていることに気づかれる方が多いのでしょう。しかし WinSxS フォルダーにコピーされたファイルはコンポーネントや更新プログラムをアンインストールする際やファイルの破損を修復する際に必要となる場合があり、手動で削除してしまうと Windows の動作に支障が出る可能性があります。

残念ながら Windows Vista 以降の Windows では WinSxS を縮小する手段は用意されておらず、WinSxS のサイズが大きくディスクの空き容量が不足する場合、根本的に解決するには Windows を再インストールする必要がありました。

こうした問題を改善するため、Windows 8.1 / Windows Server 2012 R2 では WinSxS をクリーンアップするツールが用意されました。以下の記事に詳しい情報が掲載されています。

具体的な方法を簡単に解説していきましょう。

縮小可能なサイズを調べる

まず以前の記事でも触れていますが、WinSxS フォルダー内には実際にインストールされているコンポーネントや更新プログラムにハードリンクされている使用中のファイルと、ロールバック (コンポーネントや更新の削除) に備えたあるいバージョンのファイル (未使用のファイル)、一時的なキャッシュ ファイルなどが含まれています。WinSxS をクリーンアップする場合、使用中のファイルは削除できませんが未使用のファイルやキャッシュを削除して容量を削減することは可能です。そこでまず実際のクリーンアップを行う前に、WinSxS がどの程度縮小可能なのかを調べることができます。

現在の WinSxS を調査するには、管理者権限のコマンド プロンプトで以下のコマンドを実行します。

Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore

コマンドの完了まで少し時間がかかりますが、以下のように使用中のサイズと縮小可能なサイズが表示されます。

dism

表示される項目はそれぞれ以下のような意味を持っています

エクスプローラーによって検出された
コンポーネント ストアのサイズ
Windows エクスプローラーなどで表示した場合の WinSxS の見かけ上のサイズ
コンポーネント ストアの実際のサイズ ハードリンクを考慮に入れた実際の WinSxS のサイズ
Windows と共有 Windows のよって現に利用されているファイルのサイズ
バックアップおよび無効な機能 Windows によって現に利用されていないファイルのサイズ
キャッシュおよび一時的なデータ 一時ファイル
前回のクリーンアップ日 直前の WinSxS のクリーンアップ実行日
再利用できるパッケージの数 削除可能なパッケージ (コンポーネントや更新) の数
コンポーネント ストアのクリーンアップを推奨 クリーンアップを実行した方がよいかどうかの目安

「バックアップおよび無効な機能」と「キャッシュおよび一時的なデータ」が WinSxS で縮小可能なサイズです。

WinSxS のクリーンアップ

Windows 8 以降の Windwos では、WinSxS のクリーンアップを自動的に行うタスクがタスクスケジューラに登録されています。このタスクは Windows の自動メンテナンスの一部として定期的に実行されるように設定されています(Task Scheduler Library\Microsoft\Windows\Servicing\StartComponentCleanup)。

このタスクが実行されると、削除可能なファイルにマークが付けられ、30日後以降に自動的に削除されます。またタスクの実行時間は 1 時間に設定されているため、多数の削除可能なファイルがあると一度のタスク実行ではすべてのファイルが削除されない場合があります。

手動でクリーンアップを行う場合は、管理者権限のコマンド プロンプトで以下のコマンドを実行します。

Dism.exe /online /Cleanup-Image /StartComponentCleanup

このコマンドを手動で実行した場合、ファイルの削除はただちに行われます。また削除可能なすべてのファイルが削除されます。

すべての古いバージョンの削除

WinSxS をより縮小するには、すべての古いバージョンのファイルを削除します。ただしこれを行うと、インストール済みのサービス パックと更新プログラムをアンインストール (ロールバック) することができなくなります。ロールバックする必要がないことを十分に確認してから実行してください。

すべての古いバージョンを削除するには、管理者権限のコマンド プロンプトで以下のコマンドを実行します。

Dism.exe /online /Cleanup-Image /StartComponentCleanup /ResetBase

実行すると、ただちに古いバージョンのファイルを含むすべての削除可能なファイルが削除されます。

またサービスパックで利用されている領域が、次のコマンドでさらに縮小できます。管理者コマンド プロンプトで実行してください。

Dism.exe /online /Cleanup-Image /SPSuperseded

このコマンドを実行すると、サービス パックのアンインストールはできなくなります。

広告

2014年9月28日

Android 版の Microsoft Remote Desktop で Microsoft Azure の仮想マシンに接続する

Filed under: Windows Tips — hebikuzure @ 8:23 PM

Microsoft では Android 用のリモート デスクトップ クライアントをリリースしています。

流石にスマートフォンで利用するには画面が小さすぎるのでしょうが、Android タブレットであればそこそこ使えるので、ちょっとだけ何か設定を確認したいとか、PC でのみ送受信しているアカウントのメールチェックをしたいというような時に、LAN 内の PC に接続して利用しています。このように同一の LAN 内の PC に直接 RDP 接続する場合はその PC のホスト名 (ちゃんと名前解決できる場合) か IP アドレスを設定するだけで、Windows に含まれているリモート デスクトップ クライアントと同じようにサーバーに接続できます。

そこで Microsoft Azure 上の仮想マシンにもリモート デスクトップ接続してみたいと思い、設定してみた所うまく利用できましたので、その設定方法をメモ代わりに書き留めておきたいと思います。

  1. まず PC で Azure 管理コンソールで接続したい仮想マシンを起動しておき、[接続] をクリックます。これで仮想マシンに接続するための .rdp ファイルがダウンロードされるので、開かないでどこか分かりやすい所にダウンロードしておきます。
  2. ダウンロードした .rdp ファイルをエディターなどで開くと
    full address:s:hogehoge.cloudapp.net:64050
    のような行があります (hogehoge は仮想マシンのホスト名で、hogehoge.cloudapp.net が FQDN になります)。この情報を控えておきます。
  3. Android デバイスで Microsoft Remote Desktop を起動して、右側の項目から "Remote Desktops" を選択し、右上の「+」印をクリックして新規の接続設定を開始します
  4. 次のような画面が表示されるので、順に設定していきます
    01
  5. "Connection Name" は表示名です。分かりやすい名前を付けておくと良いでしょう。
  6. "PC Name" には接続する仮想マシンのホスト名とポート番号を指定します。
    具体的には、「2.」で確認した接続したい仮想マシンの FQDN とポート番号を「FQDN:ポート番号」の形式で入力します。
    先ほどの例であれば
    hogehoge.cloudapp.net:64050
    となります。
  7. "Gateway" には RD Gateway を指定します。
    Azure 上の仮想マシンに RD Gateway 経由での接続が必要な場合は、入力欄をタップして指定を開始します。
    指定する Gateway の選択が表示されたら、"Add gateway" を選択します。Gateway の設定は後ほど説明します。
    RD Gateway 経由が必要かどうか不明な場合は、指定せず接続できるか試してみましょう。接続できないようであれば、下記の方法で RD Gateway を構成してください。
  8. "CREDENTIALS" には仮想マシンにログオンするための資格情報 (ユーザー名とパスワード) を入力しておきます。
    省略すると、接続時に資格情報を求められます。
  9. "Done" をタップすれば設定は完了です。

RD Gateway の設定は以下のように行います。

  1. "Gateway" で "Add gateway" を選択すると、次のような画面が表示されます。
    02
  2. "Gateway name" は表示名です。分かりやすい名前を付けておくと良いでしょう。
  3. "Server" に RD Gateway の URL を入力します。
    RD Gateway の URL は
    https://(上の手順の「2.」で確認した仮想マシンの FQDN):(ポート番号)になります。
    先ほどの例であれば
    https://hogehoge.cloudapp.net:64050/
    となります。
  4. "CREDENTIALS" には「8.」で指定したのと同じ資格情報を指定しておきます。
  5. "Done" をタップすれば設定は完了です。

作成した接続をタップすれば、リモート デスクトップ接続が開始されます。PC のリモート デスクトップ クライアントでの接続と同様にサーバーの証明書に関する警告が表示される場合がありますが、[Trust Once」(今回だけ信頼) か「Trust Always」(今後常に信頼) を選択すれば、接続が進行します。

Remote Desktop Client の利用方法については以下を参照してください。

※ (2014/9/29 追記) RD Gateway の設定は必須でないことが確認できましたので、その部分を訂正しています。

2014年7月18日

Windows へのスマートフォンの接続を禁止する

Filed under: Windows Tips — hebikuzure @ 3:06 PM

ベネッセの個人情報漏洩事件が世間を騒がせていますが、個人情報を持ち出すきっかけになったのは「スマートフォンを充電するためパソコンに専用ケーブルを通じて接続したら、偶然パソコンがスマートフォンを認識したためデータをコピーすることを思いついた」と報道されています。おそらく通常の USB メモリの接続は許可しない設定になっていたのでしょうが、残念ながら Windows Vista 以降の Windows とここ数年のスマート フォンの組み合わせでは、その設定では接続を禁止できません。

キャプチャ
※上掲図版はNHK ホームページ (http://www3.nhk.or.jp/news/html/20140718/k10013103401000.html) から引用

USB メモリの場合、サポート技術情報の「USB 記憶装置を使用できないようにする方法」やこちらの記事の「グループポリシーを利用したUSBメモリを制限する方法」などで使用を制限できるのですが、これらの方法は接続される USB フラッシュ メモリがマス ストレージ (大容量記憶域) として認識され、リムーバブル メディアとして利用できる場合にのみ有効です。古い携帯電話などでは内蔵のメモリや SD カードが Windows からはリムーバブル メディアとして認識されるので、接続を禁止するのにこの方法が利用できました。

しかし Windows Vista 以降の Windows とここ数年のスマート フォンの組み合わせの場合、スマートフォンは デジタルカメラ (PTP デバイス) やオーディオプレーヤー (MTP デバイス) として認識される場合があります。これらのデバイスは Windows 上では一括して「Windows Portable Devices (WPD)」として扱われます。スマートフォンを Windows PC に接続するのを禁止するには、この Windows Portable Devices の利用を禁止する必要があります。今回のベネッセのケースの場合、これが行われていなかったという事のようです。

Windows Portable Devices の接続を禁止する方法は、TaechNet ブログ「Ask CORE」の「グループ ポリシーを用いたデバイスのアクセス制御について」という記事に紹介されていました。具体的には Windows Portable Devices を示すデバイス セットアップ クラス {eec5ad98-8080-425f-922a-dabf3de3f69a} を利用して、グループ ポリシーでデバイスのインストールを禁止する方法です。

設定するグループ ポリシーは
コンピュータの構成 – 管理用テンプレート – システム – デバイスのインストール – デバイスのインストールの制限
です。この中の「これらのデバイス セットアップ クラス と一致するデバイスのインストールを禁止する」で上記のセットアップ クラス {eec5ad98-8080-425f-922a-dabf3de3f69a} を設定し、「既にインストール済みの一致するデバイスにも適用されます。」にチェックを入れます。このポリシーが適用されたクライアントでは、以降 Windows Portable Devices として認識されるデバイスが利用できなくなります。

01

02

なお、USB を含む様々なデバイスの制限方法やその際の注意事項については「グループポリシーを利用したUSBメモリを制限する方法」の記事中に解説がありますので、そちらも参照してください。

7/22 追記 : 設定するポリシーの名称が間違っていたので、訂正しています。スクリーンショットも差し替えました。

2014年5月29日

JScript.NET の環境を作成する

Filed under: Windows Tips — hebikuzure @ 5:27 PM


たぶんもう二度とやらないだろうけど、JScript.NET のコンパイル環境を作ったのでその手順のメモです。

JSオジサン 「俺の話を聞け、5分だけでもいい」 #2 (http://atnd.org/events/50606) のライトニング トーク「君よ知るや JScript.NET」のデモのために環境を作りました

  1. Windows 7 SP1 環境を用意します
    今回は Microsoft Azure の仮想マシンを A1 インスタンスで作成して利用しました
    仮想マシンを作成したら、Windows Update を実行して最新の状態にしておきましょう
  2. MSDN サブスクリプションから Visual Studio Professional 2005 DVD をダウンロードします
  3. ダウンロードしたファイルは ISO イメージなので、マウントするために Virtual CloneDrive をダウンロード / インストールします
  4. Virtual CloneDrive がインストールできたら、ダウンロードした ISO イメージをマウントします
  5. 自動実行でインストールを開始するか、ISO の vs フォルダー内の autorun.exe を実行してインストールを開始します
  6. 後は「Windows Vista に Visual Studio 2005 をインストールする方法」(http://support.microsoft.com/kb/936453/ja) の手順に従って、インストールを進めます
    Visual Studio 2005 –> Visual Studio 2005 SP1 –> Visual Studio 2005 Service Pack 1 Update for Windows Vista の順にダウンロードとインストールを繰り返します
  7. Visual Studio 2005 Service Pack 1 Update for Windows Vista のインストールが完了したら、環境の作成は完了です

JScript.NET のコンパイルと実行の手順も簡単にまとめます。

  1. JScript のソースコードを作成します。作成は Visual Studio IDE のコード エディタでも、メモ帳などのテキスト エディタでも何でも構いません。
  2. 作成したソースを .js の拡張子で保存します。
  3. [スタート] – [すべてのプログラム] – [Microsoft Visual Studio 2005] – [Visual Studio Tools] – [Visual Studio 2005 コマンド プロンプト] を開きます
  4. ソースを保存したディレクトリにカレントを移動します
  5. 以下のコマンドでソースをコンパイルします
    jsc (ソース ファイル名).js
  6. カレント ディレクトリに実行ファイルが作成されます。

流石にいまさら JScript.NET で何かやろうという事は無いので、デモが終わったら環境ごと仮想マシンを削除してしまうと思いますが、もしたしたら役立つことがあるかもしれないのでメモとして手順を残しておきます。

2014年5月1日

Adobe Reader XI で PDF をブラウザー内に表示しないための設定

Filed under: Windows Tips — hebikuzure @ 9:37 PM


Acrobat ヘルプ / PDF をブラウザーで表示 | Acrobat、Reader XI
http://helpx.adobe.com/jp/acrobat/using/display-pdf-browser-acrobat-xi.html


IE の脆弱性騒動で拡張保護モードを有効にしていると、Adobe PDF Reader ActiveX が実行できないので PDF ファイルへの直リンクをクリックすると拡張保護モードを無効にして ActiveX を利用するかどうか確認されるようになりました。ここで無効のままにすると PDF がダウンロードも表示もできないので、PDF ファイルをブラウザー内で開く設定自体を無効にしようと思い、Adobe Reader の設定を開いたのですが、以前のバージョンにはあった「PDF文書をWebブラウザーに表示」という設定がありません。

どうしたものかと思い、Adobe のヘルプを検索すると、この設定は Adobe Reader XI および Acrobat XI から廃止されたとの事。そしてその代わりに (IE では) Adobe PDF Reader ActiveX を無効にする方法が紹介されていました。Chrome や Firefox でも同様にプラグインを無効にする必要があります。

面倒だなあと思ってさらに調べると、こちらで大変有益な情報を見つけました。試してみると、確かに以下の手順で PDF をブラウザーで開く設定を無効にできます。

  1. Adobe Reader を起動します
  2. [編集] メニューから [アクセシビリティ] – [設定アシスタント] を選択します
  3. [アクセシビリティ設定アシスタント] が開くので、[次へ] をクリックしていきます
  4. 「画面 5/5」に [PDF文書をWebブラウザーに表示] があるので、チェックを外します
    無題
  5. [完了] をクリックして [アクセシビリティ設定アシスタント] を閉じます
  6. Adobe Reader を終了します

なんでこんな面倒な方法に変えてしまったんでしょうね。確かにブラウザーごとに PDF をインライン表示するかどうか選択できた方が良いかも、という気はしなくなくもありませんが…

2013年11月18日

Windows 8.1 でユーザー プロファイルを再構築する

Filed under: Windows Tips — hebikuzure @ 8:51 PM


ユーザー プロファイルが破損すると、最悪の場合そのユーザーでログオンできなくなったり、ログオンできる場合でもさまざまな障害が発生します。また「破損」とはいえないまでも、ユーザー プロファイル内に記録されるアプリケーションの設定などが不正になり、特定のアプリケーションが正しく動作できなくなる場合もあります。

こうした場合、一番確実な改善方法はプロファイル内のユーザー データをバックアップし、ユーザー プロファイルをいったん削除して再構築する事です。プロファイルの構築で問題が改善していることが確認できたら、バックアップしておいたユーザー データを復元できます。

Windows 8.1 でユーザー プロファイルの削除を安全に行う方法を検証したところ、以下の手順で削除すればプロファイルが正しく再構築されて、同じユーザーで問題なくログオンできる事が確認できました。

  1. プロファイルに問題が生じているユーザー以外のユーザーでログオンします
    ※他にユーザーがいない場合は、管理者権限を持ったユーザーを一つ (ローカル アカウントで良いので) 作成してそのユーザーでログオンします。このユーザーは作業完了後に削除できます
  2. Windows キー + X を押してメニューを表示し、[システム] をクリックします
    ※ または検索チャームで [すべての場所] から「システム」を検索し、見つかった [システム] をクリック (タップ) します
  3. [システム] が表示されたら、[システムの詳細設定] をクリックします
    システム
    ※ UAC が表示されたら、(必要であれば管理者のパスワードを入力して) [はい] をクリックします
  4. [システムのプロパティ] が表示されたら、[ユーザー プロファイル] セクションの [詳細設定] をクリックします
    システムのプロパティ
  5. [ユーザー プロファイル] が表示されたら、[このコンピューターに格納されているプロファイル] の一覧から削除したいプロファイルをクリックして選択します
    ユーザー プロファイル
    ※ Microsoft アカウントの場合、[名前] 欄に Microsoft ID の名前ではなく、Microsoft ID の名前の一部 + “_000” のような名前で表示されるので注意してください
  6. [削除] ボタンをクリックします。確認メッセージが表示されるので、[OK] をクリックします

以上の手順で、ローカル アカウントの場合も Microsoft アカウントの場合も安全にユーザー プロファイルを削除できることを手元環境での検証で確認しました。ユーザー プロファイルに起因するトラブルで、最終手段としてプロファイルの再構築を行いたい場合の参考にしてください。

なお Microsoft アカウントの場合は、ユーザー プロファイル削除後にログオンした後 Microsoft アカウントに紐づいたサービスを利用する際に、本人確認 (確認コードの再送信と再入力) が必要になります。またアカウントで同期している設定は初回ログオンの際に反映されます。
そのため同期されている設定に問題がある場合は、プロファイルの削除前にいったん同期を無効にしておくと良いでしょう。

なお、Windows エクスプローラーなどから直接プロファイル フォルダーを削除するなどの方法でプロファイルを削除すると、そのプロファイルを利用していたユーザーで正しくログオンできなくなる (一時プロファイルを使用してしまう)、Windows ストアが利用できなくなるなどの問題が発生する場合がありました。上記の手順ではこうした問題は起きなかったので、このような方法は避けた方が良いでしょう。

検証環境
Windows 8.1 Pro with Medai Center 32ビット版、ワークグループ

参考
"ユーザー プロファイル サービスによるログオンの処理に失敗しました" エラー メッセージが表示される
http://support.microsoft.com/kb/947215/ja

2013年6月9日

Windows 7 の「スタートアップ修復」を無効にする

Filed under: Windows Tips — hebikuzure @ 8:04 PM


スタートアップ修復の無効化について
http://blogs.technet.com/b/askcorejp/archive/2013/06/07/3577292.aspx


Windows 7 では、Windows の通常起動の失敗が検知されると「Windows エラー回復処理」が表示されます。これは以前のバージョンの Windows で表示されていた「拡張オプション メニュー」と似ていますが、大きな違いは既定のオプションとして「スタートアップ修復」が用意されている点です。

スタートアップ修復では検知された起動エラーに応じてシステムの破損や不整合の自動修復を試行します。これで修復が行われると通常起動に遷移し、正しく起動できるか試されます。一方修復ができない場合は「システムの復元」を行うかどうか、確認メッセージが表示されます。

スタートアップ修復は検知されたエラーを1回につき1つだけ修復します。そのため複数の問題があって通常起動できない場合、スタートアップ修復が繰り返し実行される場合があります。そのため、こうした動作になったら1回の実行で「修復できてない」と判断せず、ある程度の回数「スタートアップ修復」を繰り返した方が良いでしょう。逆にスタートアップ修復で問題が修復できない場合は「システムの復元」に進むので、スタートアップ修復が繰り返されるのはむしろ良い兆候です。

起動エラーを修復する機能として非常に有効なのですが、修復に失敗すると「システムの復元」に進む点が問題になる場合もあります。例えば「システムの復元」を無効にして運用している場合、Windows をインストールした直後の復元ポイントしか存在しておらず、「スタートアップ修復」から「システムの復元」に進んでしまうと、必要なアプリケーションなどがインストールされていない「素」の Windows 環境に戻ってしまうことがあり得ます。

「スタートアップ修復」やそれに続く「システムの復元」は通常の Windows インストールとは別にインストール済みとなっている「Windows 回復環境 (Windows RE)」から実行されます。そのため Windows で「システムの復元」を無効にしている場合でも、Windows 回復環境では「システムの復元」が実行可能です。

こうした事態を避けるため、「スタートアップ修復」自体を無効にしたい場合があるでしょう。上記で紹介した TechNet ブログ記事「スタートアップ修復の無効化について」ではこの方法を解説しています。具体的な手順は記事を参照してください。

Windows のブートマネージャーではそれぞれの起動エントリにいくつかの設定が書き込まれていますが、「スタートアップ修復」を実行するかどうかは “recoveryenabled” 属性で設定されます。この属性が “yes” の場合「スタートアップ修復」は有効、”no” の場合は無効になります。また「スタートアップ修復」の実行内容は “recoverysequence” で指定されています。

bcdedit

管理者コマンド プロンプトの bcdedit コマンドでこれらの属性を編集することで、「スタートアップ修復」を無効にできるのです。

2013年5月12日

Windows ストア アプリをループバック(localhost)に接続する

Filed under: Windows Tips — hebikuzure @ 9:51 PM

Windows 8 の Windows ストア スタイルのアプリケーションは、従来のデスクトップ アプリケーションと異なる色々な制限がありますが、開発やテスト、デバッグを行ったり、ネットワーク接続関係のさまざまなトラブルシュートを行う上で大きな制約は、ループバック アダプタ (localhost や 127.0.0.1) に接続できないというものです。これは悪意のあるプログラムがホストするローカル プロキシやローカル サーバーに接続することで情報の盗み取りや改竄が行われる事が無いようにするなど、セキュリティ的な意味があるのですが、反面、ローカルの HTTP サーバーでテストするとか、Fiddler のようなローカル プロキシを使ってデバッグするといったテクニックが使えないことも意味します。

さて、一つ前の記事に載せた Community Open Day のセッション「Windows 8 で魅力的なWeb サイトを作る」では、Windows ストア スタイルの Internet Explorer から http://localhost/… でサンプル ページを開き、タイルとしてスタート画面にピン留めするなどのデモをやっていました。この点について時間の関係でセッションでは触れられなかったので、同じことを試される方のために解説しておきたいと思います。

Windows ストア アプリがループバックに接続できない制限は、一定の手続きで解除できます。具体的な方法は MSDN の「ループバックを有効にする方法とネットワーク分離のトラブルシューティングを行う方法 (Windows ストア アプリ)」で解説されています。この解除には CheckNetIsolation.exe を利用します。

CheckNetIsolation.exe LoopbackExempt –a –p=(パッケージのアプリ ID)

CheckNetIsolation.exe LoopbackExempt –a –n=(アプリ コンテナー名)

これらのコマンドの実行は管理者への昇格が必要なので、コマンドプロンプトを「管理者として実行」で起動して、コマンドを実行します。

ただしこの方法では個々のアプリケーションの ID やアプリ コンテナー名を事前に調べておく必要があり、またアプリ一つ一つについて指定する必要もあるので多少手間がかかります。こうした手間を省くツールとして、”Windows 8 AppContainer Loopback Utility”(EnableLoopback Utility)があります。これは元々 Fillder のアドオンとして作成されたツールですが、単独でも利用できます。

”Windows 8 AppContainer Loopback Utility”(EnableLoopback Utility)は以下のページからダウンロードできます。

http://fiddler2.com/add-ons

このツールを使う場合も管理者への昇格が必要なので、管理者として実行します。

img01

この画面で、先頭のチェックボックスにチェックを入れ、[Save Shanges] をクリックすると、そのアプリのループバック接続が有効になります。ストアからインストールしたアプリではDispalyName には以下のように実際の表示名が表示されますので、アプリの識別も容易です。

img02

同じツールでループバックへの接続を無効にする(既定に戻す)こともできます。チェックを外し、、[Save Shanges] をクリックするだけです。

1台の PC で Windows ストア アプリの開発環境を完結するためアプリをローカル サーバーに接続させたい場合や、トラブル対応などでアプリの挙動を Fiddler のようなツールでデバッグしたい場合、”Windows 8 AppContainer Loopback Utility”(EnableLoopback Utility) を利用してみてください。

2013年2月2日

Windows 8 で推奨されるプロキシ設定方法

Filed under: Windows Tips — hebikuzure @ 10:33 PM

How to configure proxy server settings in Windows 8
http://support.microsoft.com/kb/2777643/en-us


プロキシ サーバーの利用は企業内ネットワークや公共の場所の共用ネットワークなどで一般的ですが、Windows 8 でプロキシ構成を行う場合についての技術情報が公開されていましたので、紹介します。

この技術情報では、Windows 8 でプロキシを構成する方法と注意事項について次のように解説しています。

WPAD
Web Proxy Auto-Discovery Protocol (WPAD) を利用してプロキシを構成する方法が、Windows 8 のコンピューター、特にモバイル コンピューターのように接続するネットワークが頻繁に変更される場合には、最もお勧めです。
インターネット オプションやグループ ポリシー
接続するネットワークが固定されているのであれば、インターネット オプションやグループ ポリシーを利用して直接プロキシ サーバーを利用するよう構成することも可能です。ただしアプリケーションによってはこの設定を無視し、独自にプロキシ設定が必要な物もあります。
Proxy Auto Configuration (PAC)ファイルによる自動構成スクリプト
インターネット オプションやグループ ポリシーを利用して PAC ファイルを指定し、自動構成スクリプトによってプロキシを構成する方法も可能です。Windows ストア アプリは PAC ファイルで構成されたプロキシを利用します。
プロキシ/ファイアウォール クライアント
Microsoft Forefront Threat Management Gateway (TMG)のようなプロキシ/ファイアウォール クライアントを利用することも可能です。ただし Windows ストア アプリでは LSP (Windows Sockets layered service providers) ドライバーとして動作するクライアントは利用できません (デスクトップ アプリケーションでは利用できます)。Windows ストア アプリでは WFP (Windows Filtering Platform) ドライバーとして動作するクライアントが必要です。
コマンド ライン
netsh winhttp set proxy コマンドを利用してプロキシを構成することも可能です。ただし管理者としてコマンドプロンプトを起動してコマンドを実行する必要があるため、多数のコンピュータに構成を展開するのには不向きです。

注意
WPAD を利用した構成はお勧めですが、DNS を使って WPAD を提供する場合は注意が必要です。DNS の設定が適切でない場合、意図しない形で悪意のある WPAD を取得してしまい、悪意のある (情報の剽窃や改竄を行うような) プロキシ サーバーを利用してしまう可能性があります。これについては「Microsoft WindowsにおけるWebプロキシ自動発見(WPAD)の脆弱性に関する 注意喚起 」(http://jprs.jp/tech/notice/2007-12-21-Web-Proxy-Auto-Discovery-alert.html) を参照してください。また Chuki さんのブログのこちらの記事にも詳しい解説があります。

またプロキシ サーバーの認証について、次の技術情報も公開さています。

Using authenticated proxy servers together with Windows 8
http://support.microsoft.com/kb/2778122/en-us

この技術情報によると、認証プロキシを通じてインターネットに接続している場合、Windows 8 コンピューターでは以下のような問題が発生する可能性があるとの事です。

  • Windows ストアからアプリの更新がインストールできない (エラー 0x8024401c)
  • 新しいアプリ (Windows ストア アプリ) をインストールできない (エラー 0x8024401c)
  • ストア アプリを起動するとプロキシに関するエラーメッセージが表示される
  • Windows 8 に含まれているアプリ (メールや People など) で、サイン インやインターネット接続に関するエラーが表示される
  • ライブ タイルが更新されない
  • Windows Update が行われない (エラー 0x8024401c)

これらの問題についてはより詳しい情報と解決方法の調査が行われているとの事ですが、現時点では以下の回避策が示されています。

  • プロキシ認証を行わない
  • Windows ストア アプリなどの動作に必要な URL をプロキシでバイパスする

ストア アプリや microsoft のアプリ、Windows Update を利用できるようにするには、以下の URL をバイパスすればよい事が示されています。

  • login.live.com
  • account.live.com
  • clientconfig.passport.net
  • wustat.windows.com
  • *.windowsupdate.com
  • *.wns.windows.com
  • *.hotmail.com
  • *.outlook.com
  • *.microsoft.com
  • *.msftncsi.com/ncsi.txt

またそれ以外の Windows ストア アプリについては、それぞれのアプリ ベンダーの情報に従ってバイパスする URL を指定する必要があります。

認証プロキシを利用している場合、Windows 8 の動作、特にモダンUI の Windows ストア アプリの動作で問題が起きた場合は、上記の情報を確認すると良いでしょう。

2013年1月8日

Windows 8 では BIOS で日付と時刻を変更しても反映されない

Filed under: Windows Tips — hebikuzure @ 10:48 PM


Changes to calendar date in BIOS is not reflected in Windows 8
http://support.microsoft.com/kb/2792897


Windows 8 がインストールされているコンピューターでは、BIOS でコンピュータのリアルタイム クロックの日付と時刻を変更しても、Windows での日付と時刻にはその変更が反映されない場合があります。これは Windows 8 の仕様です。Windows 8 で日付と時刻を変更するには、Windows のユーザー インターフェイスから変更する必要があります。

上記のサポート技術情報にはこのような仕様となった理由が書かれているので要約すると、実際の時刻は遡る (過去に戻る) ことはないので、Windows で認識している時刻より以前の時刻を BIOS が報告しても、Windows はそうした過去の時刻に戻すことはせず、現在の時刻を保持し続ける動作にしたという事です。そのため時刻を進めるような BIOS での日時変更は、Windows にも反映されます。

この仕様は Windows 8 のみで、Windows 7 以前のバージョンでは BIOS での変更通りに Windows の時刻も変更されます。

ちょっとした事ですが、知らないとトラブルの元になるかもしれない Windows 8 での仕様変更の一つです。

« Newer PostsOlder Posts »

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

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