Hebikuzure's Tech Memo

2018年10月6日

「配信の最適化」の「ローカル ネットワーク」

Filed under: Windows Tips — タグ: , , — hebikuzure @ 4:34 PM

Windows 10 の Windows Update では「配信の最適化」が利用でき、更新プログラムを Microsoft Update サーバーから直接ダウンロードするだけでなく、他の PC (Windows 10) から P2P でダウンロードすることも可能になっています。

この機能は [設定] – [更新とセキュリティ] – [配信の最適化] で構成することができますが、無効にしたければ [他の PC からのダウンロードを許可する] をオフにします。
※「ダウンロードを許可する」の文言ですが、オフにすることで他の PC へのアップロードも行われなくなります。

キャプチャ

ローカル ネットワーク上の PC

[他の PC からのダウンロードを許可する] を有効にした場合、P2P で更新プログラムを融通する範囲を構成できます。選択肢は

  • ローカル ネットワーク上の PC
  • ローカル ネットワーク上の PC とインターネット上の PC

の二つです。

ここで注意が必要なのは、ここで使われている「ローカル ネットワーク」という言葉です。通常「ローカル ネットワーク」というと同じサブネット マスクを持つブロードキャスト ドメインの範囲を差すことが多いのですが、ここでの意味は違います。

この「ローカル ネットワーク」の説明は「Windows 10 更新プログラムの配信の最適化の構成」に書かれているのですが、この資料はグループ ポリシーで配信の最適化を構成する場合の資料なので、通常のユーザー インターフェースから設定を行っている場合には気付きにくいかもしれません。ユーザ インターフェースでの設定はポリシーでの「ダウンロード モード」に相当しますが、ポリシーの方がより細かな制御ができるので余計に分かりにくいでしょう。

ユーザー インターフェースでの「ローカル ネットワーク上の PC」はポリシーのダウンロード モードでは「LAN (1 – 既定)」に相当し、「ローカル ネットワーク上の PC とインターネット上の PC」は「インターネット (3)」に相当します。そして「LAN (1 – 既定)」はこの資料では以下のように説明されています。

この既定の配信の最適化の動作モードでは、同じネットワーク上のピアとの共有が有効になります。 配信の最適化のクラウド サービスでは、ターゲット クライアントとして同じパブリック IP アドレスを使用してインターネットに接続するその他のクライアントを検索します。 これらのクライアントは、プライベート サブネット IP を使用して、同じネットワーク上の他のピアに接続しようとします。

つまり PC 自身のサブネットに関わらず、同じパブリック IP アドレス(グローバル IP アドレス)を利用している範囲が「ローカル ネットワーク」になります。そのため、自分の管理していない PC との接続を行わない意図で「ローカル ネットワーク上の PC」を設定していても、以下のようなケースでは、ネットワークのオペレーターが適切なフィルタリングを行っていない限り、意図しない PC と P2P 接続する動作になります。

  • 賃貸住宅や共同住宅に備え付けのネットワークで、1つのグローバルアドレスからインターネットに接続している
  • 公衆無線 LAN に接続している
  • キャリア グレード NAT の WLAN やプロバイダーに接続している

このようなネットワークを常に利用される場合で自分の管理していない PC との P2P 接続を行いたくない場合は、「ローカル ネットワーク上の PC」を選択するのではなく「配信の最適化」を無効にする必要があります。「ローカル ネットワーク上の PC」の選択は、インターネットへのゲートウェイ(ブロードバンド ルーターなど)にグローバル IP アドレスが割り当てられている場合に有効でしょう。

企業環境での留意点

複数の場所を拠点間 VPN で結んでインターネットへのゲートウェイを1か所に集約している企業/組織の場合、すべての拠点のすべての PC が同じグローバル IP アドレスを利用しますから、企業内全体が「ローカル ネットワーク」と認識されます。

そのため配信の最適化の P2P トラフィックが VPN に流れる可能性があります。これを避けるには配信の最適化自体を無効にするか、ポリシーで「HTTP のみ (0)」「インターネット (3)」「簡易 (99)」「バイパス (100)」などを選択するか、「グループ (2)」を選択して拠点ごとにグループを構成するか、を行いましょう。

参考資料

広告

2018年9月26日

Windows でインターネット接続しているのに「インターネットなし」と表示される

Filed under: Windows Tips — タグ: , , , — hebikuzure @ 7:37 PM

Windows Vista 以降の Windows ではタスクバーの通知領域に表示されるネットワーク 接続アイコンをポイントすると、

キャプチャ

このように「インターネット アクセス」など現在の接続の制限の有無が表示されます。

この接続状態の認識は単に表示されるだけでなく、Windows のシステムを含むプログラムからも利用できるようになっています。例えば Microsoft アカウントでのサインインの際にオンラインでの認証が可能かどうか判断したり、アプリでオンライン モードとオフライン モードを切り替えたりするのに使われます。

さて、ごくまれな現象ですが、実際にブラウザーなどからインターネットに接続して Web ページを閲覧できているのに、この状態の表示が「インターネットなし」になってしまう場合があります。この現象について解説します。

「インターネットなし」になる理由

この状態の表示は「ネットワーク接続インジケーター Network Connection Status Indicator」 (NCSI) と呼ばれる機能で、いくつかの接続テストを行ってインターネット接続の有無を判定しています。

具体的には以下のような接続テストを行います。

Windows 10 バージョン 1607 未満の場合

  1. http://www.msftncsi.com (ipv6.msftncsi.com for IPv6) の名前解決ができること
  2. http://www.msftncsi.com (ipv6.msftncsi.com for IPv6) に対して HTTP でアクセスし、ncsi.txt ファイルを取得できること
  3. dns.msftncsi.com の DNS 名前解決が ”131.107.255.255” と一致すること

Windows 10 バージョン 1607 以降の場合

  1. http://www.msftconnecttest.com (ipv6.msftconnecttest.com for IPv6) の名前解決ができること
  2. http://www.msftconnecttest.com (ipv6.msftconnecttest.com for IPv6) に対して HTTP でアクセスし、connecttest.txt ファイルを取得できること
  3. dns.msftncsi.com の DNS 名前解決が ”131.107.255.255” と一致すること

つまり、実際に多くのインターネット サイト / インターネット リソースに問題なく接続できていても、上記のテストにパスしなければ NCSI は「インターネットなし」になります。そのため Microsoft アカウントでのパスワードの変更が反映されない、ストアがオフラインになり利用できない、Outlook の先進認証が機能しない、Office サブスクリプションのライセンス認証ができない、などの問題が生じます。

テストにパスできない理由はプロキシやファイアウォールなどのネットワーク経路で http://www.msftncsi.comhttp://www.msftconnecttest.com へのアクセスが制限されている、dns.msftncsi.com の DNS 名前解決が正しく行えない、などとなります。企業内のネットワークなどであれば管理者に依頼してこれらの通信が正しくできるよう設定を変更すればよいのですが、公衆サービス / 施設の LAN / Wi-Fi や WLAN などの場合、こうした変更を行うことが難しい場合もあるでしょう。

回避策

クライアント側の設定に問題が無いにも関わらず、ネットワーク経路の問題で NCSI が「インターネットなし」になり Windows やアプリケーションの動作に問題が出る場合は、NSCI の検知の動作を無効にして回避することができます。

NCSI の検知動作を無効にするには、以下のいずれかの方法を取ってください。

レジストリを構成する

以下のレジストリ値を構成します。

  • キー:HKLM\ SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator
  • 名前:EnableActiveProbing
  • 種類:REG_DWORD
  • データ:0

グループポリシー

コンピューターの管理
ー 管理用テンプレート
ーー システム
ーーー インターネット通信の管理
ーーーー インタネット通信の設定
ーーーーー Windows ネットワーク接続状態インジケーターのアクティブなテストを無効にする

キャプチャ2

副作用としては、通知領域の NCSI アイコンが常に警告の表示になる場合があります。

なお企業内のネットワークで NCSI のテストのトラフィックを遮断したい場合は、イントラネット内などに http://www.msftncsi.comhttp://www.msftconnecttest.com の代替のアクセス先サーバーを立てて、NCSI のテストをパスするという方法があります。詳しくは参考資料の「The Network Connection Status Icon」をご覧ください。

参考資料

2018年8月29日

非管理者ユーザーにセーフモードでサインインさせない


Windows 10 を含めて Windows 7 以降のバージョンでは、Windows をセーフモードやセーフモードとネットワークで起動した場合、管理者権限の有無を問わずどのユーザーでもサインイン(ログオン)が可能です。しかしセーフモードでは通常起動の際には自動的に動作するサービスやプログラムが起動していない状態になるため、挿入しているセキュリティ ソリューションが無効になってしまう場合があります。またセーフモードでは通常アクセスできない機能などにアクセスできる場合もあります。

こうしたことを考えると、管理者権限を持たない通常のユーザーがセーフモードでサインインできなくすることは、コンピューターのセキュリティ強化に繋がるといえます。

非管理者にセーフモードでサインインさせない設定

管理者権限を持たないユーザーをセーフモードでサインインできなくするには、以下のレジストリを構成します。
※Windows 7 / Windows Server 2008 R2 の場合は SP1 の適用が必要です

キー:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
名前:SafeModeBlockNonAdmins
種類:REG_DWORD
データ:1

ドメイン環境であれば、このレジストリ構成をグループポリシーで配布できます。

コンピューターの構成 > 基本設定 > Windows の設定 > レジストリ
image

参考情報

2018年8月26日

BitLocker の回復パスワードを確認する

Filed under: Windows Tips — タグ: , , , — hebikuzure @ 2:15 PM

Windows のセキュリティー機能にディスクを暗号化する BitLocker があります。

BitLocker と「回復パスワード」

BitLocker 暗号化では復号のために必要となるキーを TPM チップに格納して、暗号化したディスクが同じデバイスに接続されている限りは透過的に復号が行われるようになってるため、ユーザーは普段は復号のための操作をする必要はありません。

追加の構成で TPM チップではなく USB ドライブを使用したり、起動時にパスワードや PIN を求めるようにすこことも可能です。
BitLocker についての詳細は Microsoft Docs の「BitLocker」を参照してください。

ただしデバイスのブート構成が変更された場合や、PC が起動できなくなってドライブを別のデバイスで読み取る必要がある場合、また上記の追加の構成で USB ドライブを紛失したり PIN を忘れたりした場合、「回復パスワード」を使うことで暗号化されたディスクにアクセスすることが可能になります。回復パスワードは 48桁の数字からなるパスワードです。

回復パスワードだ求められる場合については「BitLocker 回復ガイド」の「BitLocker 回復が実行される原因」を参照してください。

BitLocker を有効にする場合、次のようなメッセージが表示されて「回復キー」の保存を求められますが、ここで保存できるのが「回復パスワード」です(資料や UI、実際のデータで用語が混乱していますが、ここで「回復パスワード」が自動生成され、指定した方法で保存できます)。

image

この他に Active Directory ドメインに参加している PC の場合は、ドメイン内のサーバーに自動的に保存されるよう構成できます。
AzureAD に参加している PC では AzureAD に保存することもできます。

回復パスワードが不明になったら

さて、何らかの理由でここで保存した回復パスワードの情報が利用できなくなった場合、例えば利用していた Microsoft アカウントが利用できなくなったり、保存したファイルや印刷物を紛失した場合、設定済みの回復キーを調べなければならなくなります。

回復パスワードを求めれれる状況にならなければ通常の使用には問題ないのですが、ひとたび回復パスワードを求められると、それを入力しない限りそのディスクを読み取ることはできなくなります。

参考:BitLocker 回復キーを探す

参考資料に書かれているように、起動ディスクが暗号化されていて回復パスワードが分からない場合、PC を初期化しなければ利用できなくなります。当然ディスクに保存していたデーターもすべて失われます。

回復パスワードを調べる

設定済みの回復パスワードを調べるには管理者コマンドプロンプトで以下のコマンドを実行します。

manage-bde.exe –protectors –get C:
(C ドライブを暗号化した場合)

これで最初に保存した時と同じ ID とパスワードを表示することができます。改めてファイルに保存したり印刷したりして、大切に保管しておきましょう。

2018年4月4日

2018年2月11日

「更新または再起動の後にサインイン情報を使ってデバイスのセットアップを自動的に完了します」を制御する

Filed under: Windows Tips — hebikuzure @ 2:03 PM

「更新または再起動の後にサインイン情報を使ってデバイスのセットアップを自動的に完了します」の機能を制御する方法についてまとめました。

機能の概要

Windows 10 では、更新プログラムのインストール後や手動での再起動の際に、ユーザーが意図的にサインインしなくとも、再起動後に再起動前にサインインしていたユーザーは自動的にサインイン処理が行われます。実際にはサインインが行われるとすぐにロックがおこなわれ、ユーザーにはロック画面が表示されますがそのバックグラウンドでサインイン後の処理が行われます。ここで行われる処理は以下のようなものです。

  • ユーザー権限で起動するスタートアップ プログラムの起動
  • サインイン(ログイン)がトリガーになるタスクの実行
  • Windows 10 Fall Creators Update 以降では再起動開始時に起動していたアプリケーションの復元

この機能はユーザー単位で有効/無効を切り替えできます。これを有効にしておくことでユーザーは再起動時に時間を無駄にすることなく、ロックを解除すればすぐに作業が再開できるのですが、以下のような問題もあります。

  • 再起動前に複数のユーザーがサインインしていた場合、再起動を開始したユーザー以外のユーザーのサインイン処理も同時に行われる(不要なサインインであったり、処理の負荷が高くなったりします)
  • ローカル セキュリティ ポリシーで「対話型ログオン:最後のユーザ名を表示しない」を構成しても、(表示されるのはサインイン画面ではなくロック画面なので)無意味になる

そのためこの動作を無効にしたい場合もあるでしょう。

機能の無効化

通常これを無効にするには、ヘルプ記事

に書かれているように

Windows 10 Fall Creators Update (バージョン 1709) の場合は、[スタート] [設定][アカウント][サインイン オプション] の順に選び、[更新または再起動の後にサインイン情報を使ってデバイスのセットアップを自動的に完了します] をオフにします

Windows 10 Creators Update (バージョン 1703) 以前のバージョン場合は、[スタート] – [設定] – [更新とセキュリティ] – [Window Update][詳細オプション] の順に選び、[更新後にサインイン情報を使ってデバイスのセットアップを自動的に完了します] の横にあるチェック ボックスをオフにします

それではこの機能をグループポリシーなどで一括して制御したい場合はどうすれば良いでしょうか。グループポリシー エディターなどでポリシーを探しても、これを制御できるポリシーは見つかりません。

実は上記のヘルプ記事に書かれているようにこの機能は Active Directory ドメインに参加しているコンピューターでは自動的に無効になります。そのためこの動作はグループポリシーで制御する必要がない(意味が無い)ということです。また Active Directory ドメインに参加しているコンピューターだけでなく、上記ヘルプ記事にあるように「作業やメールのポリシーが組織によってデバイスに適用されている場合」= Azure AD Join している場合や、[設定][アカウント][職場または学校にアクセスする] で Azure AD アカウント(Office 365 などの組織アカウント)に接続している場合も、この機能は無効になります。

レジストリ情報

上記のようにグループポリシーでこの機能を制御する必要はないのですが、ワークグループ環境でも何らかの理由で管理者などがこの機能の有効/無効を他のユーザーに対して設定したい場合があるでしょう。その場合、この設定は以下のレジストリ エントリに保存されているので、これを(スクリプトや reg ファイルなどで)構成します。

  • キー:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\UserARSO\<ユーザーの SID >
  • 名前:OptOut
  • 種類:REG_DWORD
  • データ:0(機能オン)/ 1(機能オフ)
    ※ オプトアウトを指定する項目なので、0 がオプトアウトしない=機能有効、1 がオプトアウト=機能無効、となります

参考:TechNet フォーラム「【サインインオプション】グループポリシーでの設定

2018年1月25日

2018年1月18日

Windows 10 スタート画面のピン留めアプリの AppID を取得する

Filed under: Windows Tips — タグ: , , — hebikuzure @ 5:35 PM

Windows 10 のスタート画面のカスタマイズについて確認していた時に調べた自分用のメモですが、公式ドキュメントだとちょっと不親切なので分かりやすくまとめてみました。

概要

Windows 10 でスタート画面のカスタマイズを展開する場合、スタート画面にピン留めされているデスクトップ アプリケーションの DesktopApplicationID を取得しなければならない場合があります。その DesktopApplicationID は PowerShell を利用して取得できます。

詳細

Windows 10 でスタート画面(スタートメニュー)のカスタマイズを他のコンピューターに展開するには、カスタマイズ内容を XML ファイルにエクスポートし、それを被カスタマイズ対象のコンピューターでインポートするという作業が必要です。この作業については

に解説されています。ただこの記事でも書かれているように、スタート画面にデスクトップ アプリケーションがピン留めされている場合、エクスポートした XML ファイルを編集して DesktopApplicationLinkPath を DesktopApplicationID に変更しなければなりません。

上のページには

重要
エクスポートするスタート画面のレイアウトに、デスクトップ (Win32) アプリのタイルや .url リンクが含まれている場合、結果ファイルでは Export-StartLayout で DesktopApplicationLinkPath が使用されます。 テキスト エディターまたは XML エディターを使用して、DesktopApplicationLinkPath を DesktopApplicationID に変更してください。

と記載されています。

この変更ですが、上記ページからリンクされている

を見ると

注意
Windows 10 バージョン 1703 のスタート画面のレイアウトでは、グループ ポリシーまたは MDM を使用してスタート画面のレイアウトを適用しており、アプリケーションがユーザーの初回サインイン以降にインストールされている場合は、DesktopApplicationLinkPath ではなく、DesktopApplicationID を使用してください。

と書かれていて、より条件が明確になっています。プロビジョニングパッケージによる展開以外の方法(グループ ポリシーまたは MDM)で XLM を展開する場合で、ユーザープロファイルが生成された以降にインストールされたデスクトップ アプリケーション(と .url リンク)については、DesktopApplicationLinkPath から DesktopApplicationID への書き換えが必要ということです。

またこの記事では DesktopApplicationID は Get-StartApps コマンドレットを使用して取得できると書かれています。この取得の操作は以下の手順で行えます。

操作

  1. スタート画面のカスタマイズを構成するマスター コンピューターで、カスタマイズを行うユーザーでサインインします
  2. PowerShell を起動します
  3. 次のコマンドを実行してスタート画面にピン留めされているアプリ名の一覧を取得します
    Get-StartApps | ft Name
  4. 前の実行結果から、DesktopApplicationID を取得したいアプリケーションの Name 属性を確認します
  5. 次のコマンドを実行して Neme のアプリケーションの DesktopApplicationID を取得します
    Get-StartApps -Name (AppName) | ft AppID

例えば

PS > Get-StartApps -Name “Microsoft Azure Storage Explorer” | ft AppID
AppID
—–
{7C5A40EF-A0FB-4BFC-874A-C0F2E0B9FA8E}\Microsoft Azure Storage Explorer\StorageExplorer.exe

のように DesktopApplicationID を取得します。

2017年9月22日

Windows に接続したモニターを再認識させる

Filed under: Windows Tips — hebikuzure @ 7:45 PM

Windows が動作している PC にモニターを接続すると、解像度などのモニターの情報が自動認識されてすぐに利用可能になります。これは便利なことではありますが、まれにこの自動認識で不適切な情報が構成されてしまい、本来設定できる解像度が設定できない、マルチ モニター構成でプライマリ モニターとセカンダリーモニターが意図通りに設定されない、などのトラブルが発生します。こうした場合に認識済みのモニターの構成情報を削除して、強制的に再認識させる方法を解説します。

一度接続したことがあるモニターの構成情報はレジストリに登録され、新しいモニターが接続されるごとに登録が追加されていきます。この情報は削除されることがなく、またモニターの組み合わせごとに作成されるので、ノート PC を色々な外部モニターに接続していると、非常に多くの情報が登録されることになります。

例えば仕事柄色々な場所で外部モニター(プロジェクターなど)に接続する私のノート PC では、

image

こんな感じで大量のエントリが記録されています。

モニターを強制的に再認識させるには、これらのレジストリ エントリを手動で削除します。実際にはエントリが登録されている以下のキー全体を削除すれば良いでしょう。

HKLM\Systems\CurrentControlSet\Control\GraphicsDrivers\Configuration
HKLM\Systems\CurrentControlSet\Control\GraphicsDrivers\Connectivity

これらのキーは(作業時点で接続している)モニターが再認識されたタイミングで自動的に再生成されます。その後、再認識させたい外部モニターなどがあれば、順に接続していきます。

個別に特定のモニター(モニターの組み合わせ)だけを削除したいという場合は、以下のような方法で該当するエントリを探すことも可能です。ただしエントリが多数ある場合はかなり面倒なので、特段の理由がなければまとめて削除した方がよいでしょう。

エントリを特定するには、いくつかの情報を総合することになります。エントリのキー名は

MEI96A20_00_07DD_11*SHP109F0_00_07DC_4F^2392D524F1666208AC7A949449A77697

のようになっており、このうち “MEI96A2” と “SHP109F” の部分はレジストリ

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY

に同録されているモニター デバイスの名前(キー名)になっています。そしてこの名前は、デバイス マネージャーで [モニター] 配下にある各モニター(現在接続されていないモニターは [非表示のデバイスの表示] を有効にしないと見えません)の [プロパティ] – [詳細] で [ハードウエア ID] で表示されます。

image

そしてこのモニターについては同じプロパティで [初回インストール日付] や [最後に接続した日] を確認することができます。これらの情報から具体的にどのモニターを示しているのかを推定することができるでしょう。
※ただし [初回インストール日付] については Windows のアップグレード(Windows 10 の機能アップグレードを含む)のような Windows 側の更新などでハードウエアの再認識が行われると、その日付に変わってしまうので、実際のその PC に最初に接続した日ではない場合があります。

image

また

HKLM\Systems\CurrentControlSet\Control\GraphicsDrivers\Configuration

配下のサブキーには Timestamp という値が格納されており、これでそのエントリが最初にいつ登録されたか(いつそのモニターの組み合わせが認識されたか)を確認できます。ただしこの値は NT タイムエポック形式で記録されているので、日時を確認するには NT エポックタイムから通常の時刻形式への変換が必要です。

image

NT エポックタイムから通常の時刻形式に変換するには、コマンドプロンプトで w32tm コマンドを利用します。上のスクリーンショットでは Timestamp 値が 1d037a7d21bbfb3 (130665583117844403) となっていますので、

C:\WINDOWS\system32>w32tm /ntte 130665583117844403
151233 07:31:51.7844403 – 2015/01/24 16:31:51

のように /ntte オプションを付けて、10進数の Timestamp 値を引数にして実行します。

以上のような情報からいつどのモニターの組み合わせを認識させたのかという情報から、対応するエントリ(サブキー)を推定することが可能でしょう。

2016年10月8日

TCP ポート 445 がブロックされていると Windows 10 に更新後共有フォルダーにアクセスできない

Filed under: Windows Tips — hebikuzure @ 6:43 PM

これも「MS16-110 適用後 NAS などの共有フォルダーに接続できない問題」の調べもの中に見つけた情報です。

Windows のファイル共有に利用される SMB ではサーバー側の待ち受けポートてして TCP 445 番ポートが利用されますが、445 番ポートが何らかの理由でブロックされている場合はレジストリの構成で 445 番の代わりに 139 番ポートを使うよう構成することができました。

構成するレジストリは以下の通りです。

キー : HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
名前 : EnableNetBTForSmb2
種類 : DWORD
設定値 : 1

参考情報 : TCP 445 番ポートが遮断されていると Windows 8、Windows Server 2012 以降の OS からファイル共有通信ができない

しかしこのレジストリ構成をして共有に接続していたクライアントを Windows 10 にアップグレードしたり、新規の Windows 10 にこのレジストリを構成しても、共有には接続できません。これは、上記の参考情報に書かれているように、このレジストリは Windows 10 では利用できず無視されるからです。

SMBv1 以前のファイル共有プロトコルはすでに非推奨となって久しく、将来的に利用できなくなると考えられるので、Windows 10 で SMB によるファイル共有を行う場合は、TCP 445 番ポートをブロックしないようにネットワークを構成しましょう。

Older Posts »

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

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