Hebikuzure's Tech Memo

2018年12月18日

Windows 10 の Azure AD Registered と Azure AD Join (1)

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

※この投稿は Office 365 Advent Calendar 2018 の第18日目の記事です
※特に断りが無い限り、すべて Windows Pro 1803 での動作を説明/スクリーンショット掲載していますが、Windows 10 1809 でも大きな変更はありません

アカウントの種類

Windows にログオン(サインイン)するためのアカウントの種類としては、Windows Vista 以前では

  • ローカル アカウント
  • ドメイン アカウント(Active Directory ドメイン アカウント)

の2種類が利用できましたが、Windows 8 以降ではこれに加えて

  • Microsoft アカウント

が利用できるようになりました。これは Microsoft の個人向けオンライン アカウントをそのまま Windows のサインインに利用できるようにするものです。

Windows 10 ではさらに、Microsoft の企業向けオンライン アカウントを利用して Windows にサインインできる

  • Azure Active Directory アカウント(Azure AD アカウント)

も利用可能になりました。Azure Active Directory は Office 265 / Dynamics / PowerBI / Azure などの Microsoft の企業向けクラウド サービスの認証基盤として利用されているので、例えば企業向け Office 365 のユーザーであれば、Azure AD アカウントを持っている、ということになります。

アカウントの種類 アカウントの所有者 デバイス(PC)の管理
ローカル アカウント 個人 No
ドメイン アカウント 組織 Yes(グループ ポリシーなど)
Microsoft アカウント 個人 No
Azure AD アカウント 組織 Yes(MDM など)

Microsoft アカウントと AzureAD アカウントでサインインした場合、それぞれのアカウントを利用する Microsoft のオンライン サービス(OneDrive や OneDrive for Business、Outlook.com や Office 365)へのシングル サイン オン(SSO、その都度ユーザー名/パスワードを入力しなくてもアクセスできる)が可能になります。またドメイン アカウントでサインインした場合は、そのドメイン ネットワーク内のリソース(共有フォルダー、共有プリンター、オンプレミスの SharePoint など)へのシングル サイン オンが可能になります。

ただしドメイン アカウントと Azure AD アカウントでサインインするには、サインインするデバイス(PC)を、組織の Active Directory ドメインや Azure AD に「参加させる」という必要があります。そして組織の Active Directory ドメインや Azure AD に参加したデバイスは、参加したドメインや Azure AD のアカウントを持っていれば、だれでもそのデバイスにサインインできるようになります。デバイス(PC)自体も組織の所有(要するに会社で支給されている PC)であればそれは問題ないでしょうが、BYOD(Bring Your Own Device)で個人所有の PC を会社の仕事に利用する場合など、それでは困るという場合も考えられます(同じ会社の社員であれば、誰でも自分の持ち込んだ個人所有の PC にサインインできる….というのは普通イヤですね)。

Azure AD への「登録」(または Azure AD Registered)

そのようなケースに対応するため、Windows 10 では Azure AD への登録、Azure AD Registered という機能があります。Azure AD Registered では。特定のデバイスでのローカル アカウントまたは Microsoft アカウントでのサインインに、Azure AD アカウント(の資格情報)を記憶させます。これにより、Windows へのサインインはローカル アカウントまたは Microsoft アカウントを使って行っていても、Office 365 のような Azure AD アカウントが必要なクラウド サービスにシングル サイン オン(またはパスワード入力を省略したサイン オン)が行えます。また Azure Active Directory には「Azure AD アカウント + Azure AD アカウントを記憶させたデバイス情報」のセットが登録され、シングル サイン オンを可能にします。

Microsoft アカウントで Windows にサインインして Azure AD Registered すれば、Microsoft の個人向けのクラウドサービス(Outlook.com など)と企業向けのクラウド サービスの両方に SSO できます。Microsoft アカウント / Azure AD アカウントの両方が利用できるサービスの場合は、どちらでサインインするか選択する画面が表示されます(どちらを選んでもパスワードの入力は求められません)。

この機能によって、BYOD した個人所有のデバイスでも Office 365 などの Azure AD 認証のクラウドサービスの使い勝手が向上し、また結果として複雑なパスワードが使いやすくなるのでセキュリティを向上させることも可能になります。

Azure AD Registered を構成する

それでは実際に Azure AD への登録を行ってみましょう。まず管理者権限のあるローカル アカウントで操作してみます。

clip_image001[4]

[設定] – [アカウント] – [職場または学校にアクセスする] に進んで、[接続] をクリックします。

clip_image001[6]

[職場または学校アカウントのセット アップ] が表示されます。

「このデバイスをローカルの Active Directory ドメインに参加させる」を選択すると以下のようなローカルのドメイン名を指定する画面が表示され、ここから(ローカルの Active Directory ドメイン ユーザーの資格情報を使って)デバイスをドメインに参加させることができます。

clip_image001[10]

また「このデバイスを Azure Active Directory に参加させる」を選択すると次の画面に切り替わります。ここで Azure AD アカウントでサインインすると、「登録」ではなく「参加」で Azure AD と接続できます(詳細は明日の記事にて)。

clip_image002

「職場または学校アカウントのセットアップ」で電子メールアドレス(AAD ユーザー アカウント)を入力して [次へ] をクリックすると、パスワードが求められます。

clip_image001[14]

パスワードを正しく入力すると、登録中の画面がしばらく表示され、

clip_image001[16]

登録が完了します。

clip_image001[18]

[職場または学校にアクセスする] に登録した Azure AD アカウントが表示されていることを確認できます。

clip_image001[20]

先にも書いたように Azure AD Registered は今のサインイン アカウントに Azure AD アカウント情報を追加するだけですので、Azure AD アカウントを使った Windows へのサインインができるようになるわけではありません。実際に一度サインアウトして Windows のサインイン画面を確認しても、登録前と変化がありません。

clip_image001[22]

今までと同じローカル アカウントでサインインして、Edge を使って Office 365(OWA)を開いてみると、ユーザー名やパスワードの入力無しに、アプリケーションが表示されます。

clip_image001[24]

また OneNote アプリを起動すると、Azure AD アカウント(の OneDrive)にサインインして開始できるよう構成されていることが分かります。

clip_image001[26]

Azure Active Directory 管理センター(https://aad.portal.azure.com/)にアクセスすると、[名前] 欄に登録したデバイス(PC)名、[所有者] 欄に登録された Azure AD ユーザー名が表示され、[結合の種類] が Azure AD registered になっていることを確認できます。

image

Azure AD registered したアカウントで別の Azure AD アカウントを利用する

このように Azure AD registered することで特定の Azure AD アカウントでの SSO が可能になるのですが、何らかの理由で Azure AD registered したアカウントとは異なる Azure AD アカウントで Office 365 などのサービスを利用したい場合も考えられます。例えば学校の Office 365 アカウントを普段利用していて、アルバイトやインターンシップで働く企業からも Office 365 アカウントを提供され、そちらを利用したい場合などです。

そのようなときは、SSO で表示されたサービスのページからいったんサインアウトします。

clip_image001[28]

しばらくすると、サインアウトが完了したというメッセージが表示されます。

clip_image001[30]

その状態でサインアウトしたサービスに再度アクセスすると(ここでは OWA を開きなおしています)

clip_image001[32]

アカウントの選択画面が表示されます。登録したアカウントは「Windows に接続済み」と表示されています。

clip_image001[34]

「別のアカウントを使用する」を選択すると、通常のサインイン画面が表示されますので、利用したい Office 365(Azure AD)アカウントでサインインします。

clip_image002[4]

別のアカウントでサインインすれば、ちゃんとそのアカウントで O365 が利用できるようになっています。

image

同じデバイスで別のアカウントを登録する

Azure AD アカウントの登録は、1つのサインインアカウントに対して1つしかできません。すでに Azure AD アカウントが登録されているサインイン アカウントで別の Azure AD アカウントを登録しようとすると、次のようなエラーになります。

image

同じデバイスで、別の Azure AD アカウントを登録して利用したい場合は、Windows へのサインイン アカウントを別のものにします。別のサインイン アカウントで同じデバイスにサインインします。今度は管理者権限のある Microsoft アカウントです(区別しやすくするために表示言語を英語にしています)。

clip_image001

このユーザーではまだ Azure AD アカウントの登録(Azure AD registered)はされていません。

clip_image001[5]

このユーザー アカウントで、先に登録済みのアカウントとは別の Azure AD アカウントを登録してみます。

clip_image001[7]

問題なく登録ができ、Azure AD registered の状態になりました。

clip_image002[1]

Office 365(OWA)にシングル サイン オンできます。

image

Azure Active Directory 管理センター(https://aad.portal.azure.com/)で確認すると、先ほどと同じデバイス名ですが、異なる Azure AD に別の所有者で登録されたことが分かります。

clip_image004

管理者権限のないユーザーの場合

管理者権限のないユーザーでも Azure AD アカウントを登録できます。

clip_image001[9]

登録の手順は今までと同じです。

clip_image002[3]

Azure Active Directory 管理センター(https://aad.portal.azure.com/)で確認すると、「所有者」が異なるデバイスとして、同じ名前のデバイスが登録されていることがわかります。

image

このように、Azure AD アカウントの登録(Azure AD registered)はユーザー単位の設定で、管理者現減の有無にかかわらず可能であることが確認できました。

注意事項

Azure AD アカウントを登録して Azure AD registered にすると、

clip_image00116

このスクリーンショットの画面で表示されているように、Azure AD の管理者が構成しているポリシーが適用されます。これは会社アカウントで保護されているデーターやサービスへのアクセスが不正に利用されないよう、管理者が適切なセキュリティを保てるようにするためです。どのようなポリシーが適用されるかは登録するアカウントが所属する Azure AD によって異なりますので、事前に確認が必要であれば会社(学校)の管理者に相談されると良いでしょう。

また Microsoft アカウントで Windows にサインインしている場合は [設定] – [アカウント] – [設定の同期] で Windows の設定や記憶させているパスワードなどの情報を同じ Microsoft アカウントでサインインする別のデバイスと同期できますが、Azure AD registered にするとこの同期機能が無効化されます。

image

これは上記と同様、会社アカウントで保護されているデーターなどが意図せず(Azure AD registered されていない)別のデバイスに同期されることを防ぐためです。

この現象については「Windows 10「お使いのアカウントでは同期できません」 「Windows 10「お使いのアカウントでは同期できません」のその後 」でも解説しています。


Windows 10 で Azure AD アカウントを利用するもう一つの方法である「Azure AD への参加」(Azure AD join)については、この次の記事で解説していきます。

広告

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 値を引数にして実行します。

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

Older Posts »

WordPress.com Blog.

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