企業向け Office 365 はサブスクリプション モデルなので Office デスクトップ アプリケーションもインストール後に定期的な機能更新プログラムが提供されます。この機能更新は Windows 10 の更新と同様、提供のタイミングでいくつかのチャネルが用意されています。チャネルとそれが既定で提供される製品は「Office 365 ProPlus 更新プログラムのチャネルの概要」に掲載されていますが、

• Office 365 Pro Plus は半期チャネル
• Office 365 Business で提供される Office は月次チャネル

となります。

どのチャネルでもセキュリティ更新プログラムは毎月提供されます。

現在の更新チャネルは Office アプリケーションの [ファイル] – [アカウント]（Outlook では [Office アカウント]）- [バージョン情報] に表示されます。

更新チャネルの変更

どの更新チャネルを利用するかは、管理者が Officev365 のインストール時に構成できます。方法としては

• Office 展開ツールを利用する
• グループポリシー（Office 2016 管理用テンプレート）を利用する
• System Center Configuration Manager を利用する
• Microsoft 365 admin center の組織のプロファイルで構成する（「半期チャネル「」と「半期チャネル（対象指定）」の切り替えのみ）

などがあります。

Office 展開ツールや System Center Configuration Manager、Microsoft 365 admin center でインストール時にチャネルを構成した場合や、特に構成変更をせず既定の設定のままインストールした場合で、後からチャネルを変更したい場合はレジストリを構成します。チャネル変更のためのレジストリ設定は以下の通りです。
※ HKLM なので変更には管理者権限が必要です。

• キー：HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration
• 名前：CDNBaseUrl
• 種類：REG_SZ
• データ：
  • 月次チャネル  http://officecdn.microsoft.com/pr/492350f6-3a01-4f97-b9c0-c7c6ddf67d60
  • 半期チャネル  http://officecdn.microsoft.com/pr/7ffbc6bf-bc32-4f92-8982-f9dd17fd3114
  • 月次チャネル (対象指定)  http://officecdn.microsoft.com/pr/64256afe-f5d9-4f86-8936-8840a6a4f5be
  • 半期チャネル (対象指定)  http://officecdn.microsoft.com/pr/b8f9b850-328d-4355-9145-c59439a0c4cf

レジストリ値を変更後、Windows の サインアウト/サインインを行うと変更が反映されます。

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.com や http://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 ネットワーク接続状態インジケーターのアクティブなテストを無効にする

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

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

参考資料

• The Network Connection Status Icon
• インターネット接続性チェックが失敗する環境で Outlook 2013/2016 による先進認証が失敗する
• Windows 10 の接続エンドポイントの管理
• サインイン＆Microsoftストア利用不可：インターネットに接続しているのに「インターネットなし、セキュリティ保護あり」となる

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)」を選択して拠点ごとにグループを構成するか、を行いましょう。

参考資料

• Windows 10 での配信の最適化
• Windows 10 の更新プログラムの配信の最適化
• Windows 10 更新プログラムの配信の最適化の構成
• Windows Update の配信の最適化とプライバシー

現在一般消費者向けに提供されている Microsoft Office 製品はすべてクイック実行（C2R）形式になっていて、更新プログラムは自動的にダウンロード /インストールされるようになっています。また企業向け製品でも Office 2016 のボリュームライセンス版を最後に MSI インストール形式での提供は終了し、Office 365 / ボリュームライセンス版 Office 2019 共にクイック実行形式になったので、更新プログラムは同様に自動的なダウンロードとインストールが行われます。

個人の場合、利用しているインターネット接続が従量課金制であったり、利用データー量に上限があったりして、更新プログラムのダウンロード サイズが気になる場合があるでしょう。また企業内でもネットワーク トラフィックの管理上、同様にダウンロード サイズを気にしている管理者の方もいらっしゃるでしょう。

ダウンロード サイズの確認

そのような場合、提供されている Office の更新プログラムのサイズは以下のページで確認することができます。

Office 365 ProPlus の更新プログラムのダウンロード サイズ(https://docs.microsoft.com/ja-jp/officeupdates/download-sizes-office365-proplus-updates)

このページでは更新プログラムの提供が行われる概ね1週間前を目途にそのダウンロード サイズが提供されます（必ずしも1週間前までとは限らないようですが）。例えば下の図のように、2018 年 11 月 27 日に提供された更新プログラムのダウンロード サイズは、2018 年 11 月 13 日 提供のバージョン 1811 (ビルド 11001.20108) から更新する場合で 167MB であることが分かります。

ただし、このページの「注意」でも書かれているようにいくつかの留意事項があります。

• 提供されるサイズは英語版の Office 365 ProPlus のものです。他の言語版や他の（Office 365 Solo などの）エディションではこれとはいくらか異なるでしょう。ただし言語リソースや含まれるアプリケーションの違いを除けば共通する部分も大きいので、概ねの目安にはなるでしょう
• 提供されるダウンロード サイズ自体「概算」で、実際とは 50MB 程度の差が出る場合があります
• 提供される更新は累積的であるため、このページで示されているサイズは一つ前の更新適用状態から新しい更新を適用する場合のサイズです。何らかの理由で以前の更新をスキップしている場合、サイズが大きくなる場合があります。

また企業向け Office 365 の場合は更新チャネル（更新のタイミングの指定）を切り替えできますが、「月次チャネル」から「半期チャネル」・「半期チャネル (対象指定)」 から「半期チャネル」など、チャネルを切り替える場合には、 Office 全体を再度ダウンロードしてインストールしなおすすることになるので、少なくとも 1 GB になります。

※この投稿は 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 アカウントを持っている、ということになります。

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 への登録を行ってみましょう。まず管理者権限のあるローカル アカウントで操作してみます。

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

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

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

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

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

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

登録が完了します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注意事項

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

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

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

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

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

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

仕事で Microsoft Azure 上に作成された仮想マシンを複製する方法について調べたので、その記録として記事を投稿します。なおこの記事では ARM（Azure Resource Manager）の仮想マシンを対象としています。クラシックモデルの仮想マシンの場合はこれと異なりますので、ご注意ください。

またこの記事は執筆時点（2019/8/3）の Microsoft Azure の機能と動作に基づいて記述しています。今後機能や動作、画面の変更が行われる可能性がありますので、実際に記事を参考にした操作を行われる場合は最新の情報をご確認ください。

操作手順で示したほとんどの作業は PowerShell でも行えます。またPowerShell での作業は Azure ポータルの Cloud Shell で実行できます。PowerShell での操作については参考資料を参照してください。

複製を作る４つの方法

Azure 上で仮想マシンの複製を作ための機能として公式にサポートされるものとしては、以下の4つが考えられます

1. 仮想マシンの「キャプチャ」
2. 仮想ディスクの「スナップショット」
3. Azure Backup
4. Virtual Machine Scale Set

それぞれ一長一短なのですが、この記事では汎用性の高い「1.」と「2.」の方法についてまとめています。

実際に複製を行うために、まず実験用の仮想マシンを用意しました。複製対象となるデータ量を小さくするため、CentOS の仮想マシンを作成し、Apache と PHP をインストールしました。

仮想マシンのキャプチャから複製する

仮想マシンのキャプチャを行うと「イメージ」リソースが作成されます。イメージには作成元の仮想マシンに接続されていた OS ディスクと（存在すれば）データディスクが含まれています。そのため作成されたイメージから仮想マシンを作成すると、データディスクも含めて元の仮想マシンと同じディスク構成とすることができます。

ただしイメージから新規の仮想マシンを作成するには、キャプチャした仮想マシンの OS が「一般化」されている必要があります。「一般化」とは、Windows でいえば sysprep.exe /generalize を実行することで、デバイスにインストールされたオペレーティングシステムの固有情報（Windows で言えば SID やホスト名などの情報）を消去し、インストール初期でこれらの固有情報が設定される前の状態に戻すことです。これにより、イメージから仮想マシンを作成する際に固有情報の設定の処理が行われ、作成された仮想マシンのオペレーティングシステムはキャプチャ元の仮想マシンのオペレーティングシステムとは別の固有情報を持った別の環境となります。

※上記のように複製を目的としたキャプチャを行うためには一般化が必要となるため、キャプチャ後の（元の）仮想マシンを起動してもキャプチャ前と同様に動作させることができません。そのためキャプチャの操作ではキャプチャ後に元の仮想マシンを自動的に削除することも可能です。また元の仮想マシンをキャプチャ後も稼働させたい場合は、次に示すスナップショットから複製する方法で一般化前の仮想マシンのすべてのディスクのスナップショットを作成しておき、元の仮想マシンの一般化とそれに伴うシャットダウンが完了した後で、スナップショットから仮想マシンを復元することができます。

キャプチャを利用した仮想マシンの複製の手順は以下の通りです。

1. 複製する仮想マシンの OS を一般化します。
   Windows の場合はリモートデスクトップ接続し、以下のコマンドを管理者権限で実行します。実行後、仮想マシンがシャットダウンされるまで待ちます。
   sysprep.exe /generalize /shutdown /oobe
   Linux の場合は SSH 接続したコンソールで以下のコマンドを実行します。
   sudo waagent -deprovision+user
   確認メッセージが表示されるので注意事項を確認のうえ、「y」 と入力して続行します。
2. Azure ポータルで複製する仮想マシンを停止（割り当て解除）します。
3. Azure ポータルで複製する仮想マシンのブレードの[概要] タブの [キャプチャ] をクリックします。
   
4. 「イメージの作成」が表示されます。
   必要であれば [名前] [リソースグループ] を変更します。またキャプチャのために一般化した仮想マシンは起動して利用できないので、再度キャプチャすることがなければ [イメージの作成後、この仮想マシンを自動的に削除します] のチェックを付けます。
   最後に確認のため仮想マシン名を入力し、[作成] をクリックします。
   
5. 作成が完了したら、イメージを作成したリソースグループを開いてイメージが表示されることを確認します。
   
6. イメージ名をクリックしてブレードを開きます。
   
7. [＋VM の作成] をクリックして、イメージから新しい仮想マシンを作成します。
   [イメージ] の欄に作成したイメージ名がが設定されています。
   
8. Market Place から仮想マシンを作成するのと同様に、仮想マシン名、仮想マシンのサイズ、管理者アカウント、受信ポート規則を指定します。
   
9. 通常通り仮想マシンの作成を進め、デプロイが完了するのを待ちます。
   
10. デプロイが完了したら、[リソースに移動] をクリックして新しく作成した仮想マシンのブレードを開きます。
    オペレーティングシステムは複製元の仮想マシンと同じですが、コンピューター名は新しい仮想マシンの作成時に指定した名前になっています。
    管理者アカウントも同様に新しいものになっています。
    
    
11. 複製した仮想マシンで Apache と PHP が稼働していることを確認できます。
    

仮想ディスクのスナップショットから複製する

仮想ディスクのスナップショットを行うと「スナップショット」リソースが作成されます。スナップショットは採取元の仮想ディスクの内容の読み取り専用の完全なコピーです。スナップショットから（読み書き可能な）仮想ディスクを作成することができ、その仮想ディスクから仮想マシンを作成することができます。ただしスナップショットには採取元の単一のディスクの情報しか含まれていないので、データディスクが接続されていた仮想マシンの場合、複製を行うにはすべてのディスクについて個別にスナップショットの作成と仮想ディスクの作成を行い、OS ディスクから仮想マシンを作成する際にデータディスクを元通りに接続する必要があります。

※スナップショットはディスクが仮想マシンに接続されており、かつ仮想マシンが起動している状態でも採取することは可能です。しかし上に述べた理由から、データディスクが接続されている仮想マシンをスナップショットを使って複製する場合は、仮想マシンを停止した状態でスナップショットを採取する必要があります。そうしないと、OS ディスクを含む複数のディスク間で整合性が取れなくなり、複製した仮想マシン（のオペレーティングシステムやアプリケーション）が正常に動作しなくなる可能性があります。

またスナップショットから仮想マシンを複製する場合は、複製元の仮想マシンのオペレーティングシステムの一般化は必要ありません。ただし一般化を行わず複製した場合は元の仮想マシンの完全なクローンとなるため、同一のネットワーク上で同時に起動した場合、予期せぬ問題が発生する場合があります。一般化後に OS ディスクのスナップショットを採取し複製した場合は、複製後の仮想マシンのオペレーティングシステムはキャプチャ元の仮想マシンのオペレーティングシステムとは別の固有情報を持った別の環境となります。一般化するかどうかは複製後の利用目的に合わせて判断してください。

スナップショットを使った仮想マシンの複製の手順は以下の通りです。

1. 仮想マシンをシャットダウンします。シャットダウンしていなくてもスナップショットを採取することは可能ですが、仮想マシンの複製に利用する場合はシャットダウン状態の方が無難でしょう。
2. Azure Portal 複製をで作成したい仮想マシンのブレードを開き、[ディスク] をクリックします
   
3. スナップショットを採取するディスクをクリックします
4. [+スナップショットの作成] をクリックします
   
5. スナップショットに名前を付けて、[作成] をクリックします。
   
6. スナップショットを作成したリソース グループを開くと、スナップショットが作成されています。
   
7. クリックしてブレードを開くと、[エクスポート] という項目があります。これをクリックすると、スナップショットを VHD としてローカルにダウンロードできます。
   ダウンロードした VHD はローカルの Hyper-V で利用する、別サブスクリプションの Azure にアップロードして利用するなどが可能です（OS ディスクであれば VHD を元に仮想マシンを作成することも可能です）。
   
8. スナップショットから管理ディスクを作成します。Azure ポータルで [+リソースの作成] をクリックし、検索ボックスに “Managed Disks” と入力して管理ディスクの作成画面を呼び出します。
   
9. [作成] をクリックし、管理ディスクを作成します。「リソース グループ」と「地域」をスナップショットを作成したときと同じにしてください。
   [ソースの種類] で「スナップショット」を選択し、採取したスナップショットを選択します。
   ※[サイズ] でディスクのサイズが変更できます。元のディスクより小さいサイズに変更できますが、実際のデータ サイズよりディスクのサイズが小さいとディスクの作成に失敗しますので、注意してください。元のディスクと同じサイズを選択するのが無難でしょう。
   
10. [確認および作成] をクリックし、[作成] をクリックするとデプロイが開始されます。
    
11. デプロイが完了したら、[リソースに移動] をクリックして新しく作成した管理ディスクのブレードを開きます。
    
12. [+仮想マシンの作成] をクリックして、管理ディスクから仮想マシンを作成します。
    [イメージ] の欄に作成元の管理ディスクが設定されています。
    
    管理ディスクから直接仮想マシンを作成しているので、Market Place やイメージから仮想ディスクを作成する場合と異なり管理者アカウントを指定する欄がありません。
    
13. [確認および作成] をクリックし、[作成] をクリックするとデプロイが開始されます。
    
14. デプロイが完了したら、[リソースに移動] をクリックして新しく作成した仮想マシンのブレードを開きます。
    コンピューター名や OS の種類が複製元の仮想マシンと同一になっています。管理者アカウントも元の仮想マシンと同じです。
    
15. 複製した仮想マシンで Apache と PHP が稼働していることを確認できます。
    
    

まとめ

Azure の仮想マシンを複製する方法として、以下の２つについて手順を検証・紹介しました。

• 仮想マシン一般化した上でキャプチャしてイメージを作成し、イメージから新しい仮想マシンを作成する
• 仮想ディスクのスナップショットを作成し、スナップショットから管理ディスクを作成し、管理ディスクから新しい仮想マシンを作成する

それぞれ次のような特徴があります。

キャプチャを使う

• オペレーティングシステムが一般化されるので、元の仮想マシンとは別の環境となる
• Market Place から仮想マシンを作成する場合と同様に新しいコンピューター名や管理者アカウントを構成できる
• 一般化が必要なので元の仮想マシンは利用できなくなる

スナップショットを使う

• オペレーティングシステムの一般化が必要ないので、元の仮想マシンの完全なクローンが作成できる（一般化しても良い）
• クローンなので新しい仮想マシンのコンピューター名や管理者は元の仮想マシンと同じになる
• 一般化しなければ元の仮想マシンも利用可能だが、同時利用には注意が必要

参考資料

• Azure Resource Manager (ARM) 仮想マシンの複製方法のご紹介 (Part.1)
  <https://blogs.technet.microsoft.com/jpaztech/2018/09/21/arm-vm-replication-part-1/>
• Azure Resource Manager (ARM) 仮想マシンの複製方法のご紹介 (Part.2)
  <https://blogs.technet.microsoft.com/jpaztech/2018/09/25/arm-vm-replication-part-2/>
• スナップショットの作成
  <https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/snapshot-copy-managed-disk>
• 管理ディスク (Managed Disks) スナップショットより VM をデプロイする
  <https://blogs.technet.microsoft.com/jpaztech/2017/05/02/deployvmfromsnapshot/>
• PowerShell でスナップショットから仮想マシンを作成する
  <https://docs.microsoft.com/ja-jp/azure/virtual-machines/scripts/virtual-machines-windows-powershell-sample-create-vm-from-snapshot>
• Azure で一般化された VM の管理対象イメージを作成する
  <https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/capture-image-resource>
• 管理ディスク (Managed Disks) の “イメージ” リソースを使用し、仮想マシンを複数台展開する
  <https://blogs.technet.microsoft.com/jpaztech/2017/05/10/deployvmsfrommanagedimage/>
• 管理イメージから VM を作成する
  <https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/create-vm-generalized-managed>
• Export an Azure Managed Snapshot to Storage Account – PowerShell
  <https://arlanblogs.alvarnet.com/export-an-azure-managed-snapshot-to-storage-account-powershell/>
• Export/Copy managed snapshots as VHD to a storage account in different region with PowerShell
  <https://docs.microsoft.com/en-us/azure/virtual-machines/scripts/virtual-machines-windows-powershell-sample-copy-snapshot-to-storage-account>
• 汎用化した VHD をアップロードして Azure で新しい VM を作成する
  <https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/upload-generalized-managed?toc=%2fazure%2fvirtual-machines%2fwindows%2ftoc.json>
• Create a managed disk from a VHD file in a storage account in same or different subscription with PowerShell
  <https://docs.microsoft.com/en-us/azure/virtual-machines/scripts/virtual-machines-windows-powershell-sample-create-managed-disk-from-vhd?toc=%2fpowershell%2fmodule%2ftoc.json>
• Azure から Windows VHD をダウンロードする
  <https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/download-vhd>
• Azure 対応 VHD の Azure へのアップロードおよび Azure イメージの作成
  <https://www.ibm.com/support/knowledgecenter/ja/SSPREK_9.0.3/com.ibm.isam.doc/admin/task/tsk_upload_vhd_azure.html>

今回も仕事で調べた話の記録です。

ファイルサーバーの冗長化

LAN を利用する目的の一つにファイルやフォルダーの共有があります。多くの会社では専用のファイル サーバーを構築して社内で共有するファイルやフォルダーをホストしているでしょう。こうした共有されているデーターは会社の資産であり、重要なものとして保護する価値があります。この保護は一般的な情報セキュリティの CIA＝「機密性」（Confidentiality）、「完全性」（Integrity）、「可用性」（Availability）を確保するということです。

Windows Server で構築されたファイル サーバーでは、機密性については ACL によるアクセスコントロールやファイルの暗号化（EFS)・ディスクの暗号化（BitLocker）、Windows 情報保護（WIP）などの多くの機能が提供されていますし、サードパーティー製のソリューションもよく利用されています。完全性と可用性の確保で一番ポピュラーなのはデータのバックアップでしょう。これも標準機能・サードパーティー製ソリューションともに幅広く利用されています。またストレージの冗長化も完全性や可用性の確保に RAID などが多く利用されている方法です。

とりわけ可用性の確保では、ストレージを冗長化することが（ディスクが HDD であれ SSD であれ寿命のそう長くないパーツである以上）非常に有効ですが、物理的にデータを保持するストレージではなく、そのストレージを接続し論理的に共有リソースとしてホストするファイル サーバーの冗長化はどのように行うことができるでしょうか。

ファイル サーバーを冗長化する場合、以下のような機能が必要になります。

• クライアントからは冗長化されたどのサーバーに対しても同一の方法（パス）でアクセスできる
• 冗長化されたすべてのサーバーは常に同一内容のデータを共有ファイルとしてホストする
• 冗長化されたサーバーの一部が停止しても、データーの完全性と可用性は損なわれない

こうした条件を Windows Server のファイル サーバーで満たすことができる機能として、以下のような方法が考えられます。

• Windows Server フェイルオーバー クラスタ（WSFC）を構成する
• DFSR を利用する
• 記憶域レプリカを利用する

それぞれの特徴を簡単にまとめて見ました。

Windows Server フェイルオーバー クラスタ

Windows Server フェイルオーバー クラスタは Windows Server の標準機能です。複数のサーバーをクラスタ化し、共有のストレージ（SAS / Fiber Channel / iSCSI）を利用してファイル共有を提供します。動作的には参加しているすべてのサーバーは常時 Active になります。
共有リソースを保持するストレージは共有されますので、ストレージ自体の冗長性確保は別に考える必要があります（基本的に冗長構成が必須）。

図：https://docs.microsoft.com/ja-jp/windows-server/failover-clustering/deploy-two-node-clustered-file-server より引用

Pros

• 多数のサーバーをクラスタリングすることで堅牢な冗長性を確保できます
• Active Directory に依存しない機能なのでワークグループ クラスターを作成できます（ただしファイルサーバーとしての利用は非推奨）

Cons

• 共有ストレージの要件（SAS / Fiber Channel / iSCSI）のハードルがやや高くなります
• クラスタに参加するサーバーは同一または類似している必要があります
• 構成の難易度が相対的に高くなります

参考情報

• Windows Server のフェールオーバー クラスタリング
  https://docs.microsoft.com/ja-jp/windows-server/failover-clustering/failover-clustering-overview
• フェールオーバー クラスタ リングのハードウェア要件と記憶域オプション
  https://docs.microsoft.com/ja-jp/windows-server/failover-clustering/clustering-requirements
• 2 つのノードのクラスター化されたファイル サーバーを展開します。
  https://docs.microsoft.com/ja-jp/windows-server/failover-clustering/deploy-two-node-clustered-file-server
• Workgroup Cluster の構築手順
  https://blogs.technet.microsoft.com/askcorejp/2018/08/27/workgroup-cluster-construct/

DFSR

Windows Server の標準機能である DFS 名前空間で作成されたターゲット フォルダー間を自動的にレプリケートする機能です。DFS 名前空間とは複数のサーバー上に配置されている共有フォルダーを、論理的に構造化された 1 つ以上の名前空間にグループ化できる機能で、ユーザーに対して共有フォルダーを仮想化し、複数のサーバー上にあるファイルに 1 つのパスアクセスできるものです。
動作的には DFS を構成するすべてのサーバーは Active に動作します。共有リソースを保持するストレージはサーバーごとに個別に接続されるので、サーバー単位で冗長構成を取らなくとも全体としてはデーターの冗長化が行えています。サーバー間の同期はフォルダー単位でファイル ベースで行われます。

図：https://docs.microsoft.com/ja-jp/windows-server/storage/dfs-namespaces/dfs-overview より引用

Pros

• 構成が容易です
• 特別なハードウエアやネットワークを必要としません
• サーバーやディスクのスペックはまちまちでも問題ありません
• クライアントからは単一の記憶域として扱えます
• 障害時の対処が単純（フェールオーバーの操作が必要なく、障害サーバーを復旧させるだけ）です
• Windows Server Standard 以上のエディションで利用可能です

Cons

• Active Directory が必須です
• DFS 名前空間の動作原理上、クライアントがどの物理サーバーにアクセスするか明示的に制御できません（Active Directory サイトの構成によりある程度は制御可能）
• フォルダー間のレプリケートはクライアントからのアクセス（書き込み）とは非同期に行われるため、複製フォルダー間の常時整合性は保証されません（変更が検知されたファイルはいったんステージング領域にコピーされ、その後ネットワーク経由で他のサーバーに同期されます）。そのため同一のファイルが複数のサーバーで頻繁に更新される場合、競合によるデーターの損失や破損が生じる場合があります。

DFSRの参考情報

• DFS レプリケーションの概要
  https://docs.microsoft.com/ja-jp/windows-server/storage/dfs-replication/dfsr-overview
• 紹介とクライアント フェールバックを有効または無効にする
  https://docs.microsoft.com/ja-jp/windows-server/storage/dfs-namespaces/enable-or-disable-referrals-and-client-failback

記憶域レプリカ

記憶域レプリカは障害復旧用にサーバーまたはクラスター間でボリュームのレプリケーションを行う Windows Server の機能です。レプリケーションは同期レプリケーションと非同期レプリケーションが選択できます。機時間の短いネットワーク内でデータをミラーリングし整合性の維持を図るには同期レプリケーションを、遠隔地間など待機時間の長いネットワークを通じてデータをミラーリングする場合は（整合性は保証されませんが）非同期レプリケーションを選択できます。サーバーは Active / Standby の構成（レプリケートされる側を待機系にする）も可能です。サーバー間の同期はボリューム単位でブロック ベースで行われます。
※記憶域レプリカはサーバー間でのレプリケーション以外に、クラスターのノード（群）間、クラスター間でのレプリケーションが可能です。（下図はサーバー間構成例）

図：https://docs.microsoft.com/ja-jp/windows-server/storage/storage-replica/storage-replica-overview より引用

Pros

• 構成が比較的容易です
• 特別なハードウエアやネットワークを必要としません
• サーバーやディスクのスペックはまちまちでも問題ありません
• レプリケートを同期実行できるので、複製間の整合性が高く障害時のファイル システム レベルでのデータ損失もゼロになります

Cons

• Active Directory が必須です
• 障害時のフェールオーバーを手動で行うか、自動化する仕組みを作る必要があります（レプリケートするサーバー上のフォルダーをターゲットにする DFS 名前空間を構成して、DFSR ではなく記憶域レプリカで同期する構成にすることは可能です）
• Windows Server 2016 以前では Standard エディションでは利用できません（Data Center エディションが必要。Windows Server 2019 では Standard エディションでも一部制限付きですが利用可能）

記憶域レプリカの参考情報

• 記憶域レプリカの概要
  https://docs.microsoft.com/ja-jp/windows-server/storage/storage-replica/storage-replica-overview
• 記憶域レプリカでのサーバー間の記憶域レプリケーション
  https://docs.microsoft.com/ja-jp/windows-server/storage/storage-replica/server-to-server-storage-replication

まとめ

ミッションクリティカルで堅牢生・高可用性を必要とする場合は WSFC を利用するのが望ましいでしょう。ただし構築に必要なハードウエア費用や技術的コストは相対的に高くなります。

DFSR の良い点は、遠隔地のサーバー間など帯域や遅延に制限のある環境でもクライアントからのアクセスのパフォーマンスに影響を与えることなく同期が行えることです。また同期するグループに何台でもサーバーを追加できる点や構成が用意である点もメリットでしょう。参照が中心のデーターをホストするファイル サーバーを（場所的にも）広範囲で冗長化するのに向いていると思います。

記憶域レプリカは1対1のレプリケーションとなる点が制約です。DFSR のように3台以上のサーバーを同期させることはできません。その代わり同期レプリケーションが可能なので、DFSR のようなデーターの破損や競合の発生は生じません。複数のクライアントから頻繁に更新されるデーターを多数持つファイルサーバーの冗長化に向いていると思います。

ファイルサーバーの冗長化を検討される機会があれば、以上の内容を参考にしてください。

以前にこのブログでも『「更新または再起動の後にサインイン情報を使ってデバイスのセットアップを自動的に完了します」を制御する』の記事で取り上げた、更新後の自動的な再起動や手動での再起動後に、再起動前にサインインしていたユーザーでの自動的なサインインと再起動前に開いていたアプリケーションの復元が行われる Windows 10 の動作について、Windows 10 version 1903 でポリシーが変更されているので紹介します。

Windows 10 の再起動時の動作

『「更新または再起動の後にサインイン情報を使ってデバイスのセットアップを自動的に完了します」を制御する』の記事でも紹介したように、Windows 10 の既定の設定では更新後の自動的な再起動や手動での再起動後に、再起動前にサインインしていたユーザーでの自動的なサインインが行われ、その後ロックがかけられた状態になります。また自動的なサインイン後には、再起動前に開いていたアプリケーションの復元（起動）が行われ、ロック解除後に再起動前の作業がすぐに開始できるようになっています。

この機能は元々は Windows 8 から導入された Winlogon Automatic Restart Sign-On (ARSO) という機能です。Windows 8 以降ロック画面にメールや Skype、カレンダーなどアプリの通知を表示できるようになりましたが、再起動後のサインイン画面では、今までの仕組みによればユーザーはまだサインインしていないので当然アプリも起動しておらず、通知も表示できません。そこで Windows Update などの更新の適用にともなう再起動後も通知をすぐに表示できるようにする仕組みとして ARSO が導入されました。これにより自動的なサインインとアプリの起動が行われるため、再起動後に表示されるロック画面には最初からアプリの通知が表示されます。

Windows 10 ではこの仕組みが拡張されて、手動での再起動の場合やや、自動的なバックグラウンド動作が許可されているアプリ（メールや Skype、カレンダーなど）だけでなくデスクトップ アプリケーションにも適用されるようになりました。そのためこの動作に気づきやすくなり、問い合わせや Q&A サイトへの投稿でもよく取り上げられるようになりました。

自動的なサインインを制御する

ARSO の動作を制御するには、Windows 8.1 以前はポリシー（グループポリシー、ローカルポリシー）を利用する必要がありました。ポリシーは

[コンピューターの構成] > [ポリシー] > [管理用テンプレート] > [Windows コンポーネント] > [Windows ログオンのオプション] > [システムによる再起動後に自動的に前回の対話ユーザーでサインインする]

です。

Windows 10 ではユーザー インターフェイスから制御できるようになりました。

Windows 10 version 1709 以降は

[設定]  > [アカウント]  > [サインイン オプション] > [更新または再起動の後にサインイン情報を使ってデバイスのセットアップを自動的に完了してアプリを再起動します]

それ以前のバージョンは

[設定]  > [更新とセキュリティ]  > [Window Update]  > [詳細オプション] > [更新後にサインイン情報を使ってデバイスのセットアップを自動的に完了します]

で ARSO の有効無効を切り替えできます。

参考：更新または再起動の後に PC のセットアップを自動的に完了する

※ドメインに参加している場合や MDM によるポリシーが適用されている場合は、クライアントのこの項目は無効になり操作できません。

Windows 10 version 1903 の新しいポリシー

Windows 10 version 1903 では ARSO に関するポリシーが変更されています。新しいポリシーは

[コンピューターの構成] > [ポリシー] > [管理用テンプレート] > [Windows コンポーネント] > [Windows ログオンのオプション]

配下の

[再起動後に自動的に前回の対話ユーザーでサインインしてロックする]

[再起動またはコールド ブート後に前回の対話ユーザーで自動的にサインインしてロックするモードを構成する]

のの二つです。いずれも Windows 10 version 1903 以降でのみ有効なポリシーです。

[再起動後に自動的に前回の対話ユーザーでサインインしてロックする]

このポリシーはこれまでと同様の ARSO の有効/無効を制御できます。ポリシーの名前や説明が Windows 10 での動作に沿った分かりやすいものに変更されています。

ポイントは ARSO による自動的なサインインが行われる条件が明確に説明されている点でしょう。ARSO が有効の場合、再起動後の自動的なサインインが行われるのは以下の場合です。

• ユーザーが再起動開始前にサインアウトしていない
• デバイスが Active Directory または Azure Active Directory に参加している場合は、Windows Update による再起動時にのみ自動的なサインインが行われる
• デバイスがワークグループの場合は、Windows Update による再起動時とその他の理由での再起動時の両方で自動的なサインインが行われる

またこのポリシーが未構成の場合の既定値は「有効」です。

[再起動またはコールド ブート後に前回の対話ユーザーで自動的にサインインしてロックするモードを構成する]

このポリシーは [再起動後に自動的に前回の対話ユーザーでサインインしてロックする] を有効にした場合にのみ利用されるポリシーで、以下の二つのオプションを構成できます。

1: BitLocker が有効で一時停止されていない場合は有効

2: 常に有効

「1:」を構成すると、再起動中に BitLocker がアクティブで一時停止されていない場合のみ自動的なサインインが行われます。

これらのポリシーにより、ARSO の動作をより分かりやすく制御することができるようになりました。

※なお、Windows 10 version 1903 では ARSO を制御するユーザー インターフェイスの文言も「サインイン情報を利用してデバイスのセットアップを自動的に完了し、更新または再起動後にアプリを再び開くことができるようにします。」に変更されています。

先日「HTML5 5th Anniversary」というイベントで「Web に関わる人に知っておいてほしい) Web ブラウザー 最新事情」（リンク先 SlideShare) というセッションを行いました。

このセッションで紹介した Android 9 (Pie) 以降で DoT (DNS over TLS) を利用する方法について解説します。

DoT とは

DoT (DNS over TLS) とは何か、簡単に説明しておきましょう。従来の DNS の通信は通信自体の暗号化、サーバー検証、エンティティ検証といったセキュアな通信が一切行われておらず、DNS スプーフィングや中間者攻撃に対して脆弱です。また DNS クエリの内容がネットワーク経路上で簡単に傍受できるプライバシー上の問題もありました。こうした問題を改善し DNS をセキュアなものにする技術がいくつか提唱され実用化されています。DoT はその中で、DNS クライアント（スタブ リゾルバ）と DNS キャッシュ サーバー（フルサービス リゾルバ）の間の通信を TLS で保護するものです。

DNS の安全性

携帯電話キャリアの DNS であればクライアントと DNS サーバーの間の通信はキャリアの WLAN 網内で完結するので、基本的に DNS トラフィック自体を暗号化などで保護しなくとも安全と考えられます。また固定回線で ISP 経由でインターネット接続する場合も、日本国内であれば宅内装置と ISP の間は電話会社の回線を PPPoE で通過するので、同様に ISP の DNS サーバーまでのトラフィックを暗号化などで保護しなくとも安全と考えられます。

ただし DNS 問い合わせの内容はキャリア側で収集可能なので、プライバシーの問題は考慮しなければならないでしょう。一時期話題になった「海賊版コンテンツのブロッキング」もキャリアや ISP の DNS でブロックを行う手法が検討されていました。

DNS の安全性が問題になるのは、こうしたクライアントと DNS サーバーの間の経路が信頼できない場合です。具体的には公衆無線 LAN などのパブリックなネットワークを経由してインターネット接続する場合です。こうしたネットワークでは DNS の盗聴や中間者攻撃による DNS スプーフィングが可能な場合がありますし、そもそもそのネットワークが提供している DNS サーバー自体が安全に構成されていて信頼/信用できるのかどうか分からない場合もあるでしょう。DoT（やクライアント・DNS サーバー間を暗号化する別の方法である DoH – DNS over HTTPS）はこうしたネットワークを利用する場合に効果を発揮します。

DoT を利用する

Android 9 (Pie) 以降の Android OS ではシステム DNS に DoT が実装されています。そのため [設定] でネットワークに DoT を構成すれば、基本的にすべてのネットワーク通信の DNS 問い合わせをセキュアにできます。本年後半以降、各携帯電話キャリアから発売された Android スマートフォンはほぼ Android 9 を搭載しているので、最近 Android スマートフォンを買った / 機種変更した人であれば、すぐに DoT を試してみることができます。

Android 9 以降でDoT を利用するには [設定] – [ネットワークとインターネット] を開き、[詳細設定] をタップして開きます。すると [プライベート DNS] という項目が見つかるでしょう。これが DoT の設定です。[プライベート DNS] をタップすると、以下のような画面が表示されます。

この各項目はそれぞれ次のような動作を示しています。

• OFF：DoT を利用しない
• 自動：DHCP などで現在構成されている DNS サーバーに DoT での接続を試し、DoT が使えなければ従来の DNS にフォールバックする
• プライベート DNS プロバイダのホスト名：指定した DNS サーバーに DoT で接続、失敗してもフォールバックしない

既定は「自動」ですが、現時点では携帯電話キャリアの DNS サーバーで DoT に対応しているところはありませんし、Wi-Fi アクセスポイントで DHCP で提供される DNS サーバーでも DoT に対応しているところはまずないので、「自動」のままでは DoT が利用されることは無いでしょう。

[プライベート DNS プロバイダのホスト名] を選択し、DNS のホスト名を入力します。注意が必要なのは、DoT は TLS で通信を保護するので、TLS の証明書検証のためにホスト名が必要になるという点です、通常の DNS は IP アドレスで指定しますが、ここではホスト名を指定します。

※ DoT 対応 DNS サーバーのホスト名は既存の DNS 構成を利用して（保護されていない）DNS で問い合わせ可能です。仮にここで不正なレコードが返って来たとしても、その不正な IP アドレスに対して（正しいホスト名での）TLS 接続はできませんので、安全は保たれるという仕組みです。またそのために DoT 接続に失敗した場合、フォールバックしない動作になっています。

利用可能な DoT 対応のパブリック DNS の一覧は

• DNS Privacy Public Resolvers
  https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Public+Resolvers
• DNS over HTTPS
  https://github.com/curl/curl/wiki/DNS-over-HTTPS

などで公開されていますし、提供元の Web サイトなので設定方法が公開されています。

ここでは Cloudflare と Google、そして IIJ のパブリック DNS のホスト名を紹介しておきます。

• Cloudflare : 1dot1dot1dot1.cloudflare-dns.com
  https://blog.cloudflare.com/enable-private-dns-with-1-1-1-1-on-android-9-pie/
• Google : dns.google
  https://developers.google.com/speed/public-dns/docs/using#android
• IIJ : public.dns.iij.jp
  https://public.dns.iij.jp/

実際に Cloudflare のパブリック DNS (1dot1dot1dot1.cloudflare-dns.com) を設定して、Cloudflaer のテスト ページ（https://1.1.1.1/help）を表示すると、以下のように DoT が有効と表示されます。

※ Google のインストラクションに書かれているように、Android 9 ではこの [プライベート DNS] による DoT の設定は VPN では利用されません。この問題は Android 10 で修正されています。

Windows 8 以降では Windows へのサインインにオンライン アカウントである Microsoft アカウントが利用できるようになり、また個人向けの Microsoft Office のライセンスも Microsoft アカウントに紐づけて管理されるようになっています。このため以前は outlook.com (昔の Hotmail）を使う場合ぐらいしか必要なかった Microsoft アカウントを取得して利用するケースが増えてきているでしょう。

それとともに、Microsoft アカウントのパスワードを忘れた、Microsoft アカウントのメールアドレス自体を忘れた、Microsoft アカウントがロックされて回復できない、といった Microsoft アカウントがらみのトラブルも良く聞きます。Windows のサインインに使っていた Microsoft アカウントが利用できないと PC が利用できず、Office のライセンスを管理していた Microsoft アカウントにサインインできないと Office の再インストールができないといった深刻な問題になります。

こうしたトラブルを防ぐために、パスワードのリセットやアカウントの回復に役立つ機能が Microsoft アカウントには用意されているのですが、あまり利用・紹介されていないものもあります。Microsoft アカウントを取得したらまず最初にこれから紹介する設定を行い、万一に備えておきましょう。

Microsoft アカウントの Web サイトにサインインする

Microsoft アカウントを作成したら、まず Microsoft アカウントのホームページにアクセスしましょう。

• https://account.microsoft.com/

Microsoft アカウントを作成した場所や方法によっては、このページにアクセスする際に、アカウント作成時に登録した連絡先（メールアドレス、電話番号）へのコードの送信と入力を求められる場合があります。アカウント作成時にも一度同様のコードの送信と入力を行っているはずですので、その時と同様に進めてください。

サインインできたら、左上の [その他のアクション] をクリックして [プロフィールの編集] を選択します。

「あなたの情報」ページが開きますので、名前や生年月日、国/地域、表示言語などを適切に編集しましょう。生年月日は（通常他のユーザーに表示されないので）アカウントを回復する時の個人情報として利用できますので、正しい生年月日を入力されることをお勧めします。

連絡先情報の登録

次に連絡先情報を複数登録します。アカウントを作成した際に連絡先情報も登録していますが、１つだけだとそのメールアドレスや電話番号が利用できなくなった場合、連絡先として使える情報がなくなってしまいます。そのため連絡先情報は異なる種類のものを必ず複数登録しましょう。

連絡先情報を登録するには、まず https://account.microsoft.com/ 一番上の段の [セキュリティ] をクリックしてセキュリティのページに移動します。

このページの [セキュリティの連絡先] で [情報を更新する] をクリックします。クリックするとパスワードの再入力を求められますので、現在のパスワードを入力します。これで「セキュリティの設定」が開きます。

セキュリティ情報を追加するには、[セキュリティ情報の追加] をクリックします。

[認証の手段] では電話番号とメールアドレスが選べます。また電話番号を選んだ場合はテキスト（SMS）と電話（音声通話）が選択できます。

入力して [次へ] をクリックすると、選択した方法で入力した連絡先にコードが送信されます（電話の場合は電話がかかってきてコードが読み上げられます）。画面に入力欄が表示されるので、受け取ったコードを入力してください。

これで新しいセキュリティ情報が追加できます。アカウントがロックされた場合やパスワードを忘れてリセットしたい場合に必要となる情報なので、メールアドレスと電話の両方を、可能であれば複数登録しておきましょう。また機種変更やキャリア変更などで携帯電話番号を変更した場合、引っ越しで固定電話番号が変わった場合、職場や学校、プロバイダーの変更でのメールアドレスの変更があったら、このセキュリティ情報も必ず最新に更新しておきましょう。

回復コードの取得

コードを受け取りる通常の方法でアカウントが回復できない場合に、アカウントを回復するための「回復コード」が用意されています。回復コードは以下の方法で確認できます。

先ほどの [セキュリティの設定] 画面の下の方に「最新のセキュリティ情報に通じていますか。アカウントのセキュリティを保つための追加オプションをご覧ください。」と書かれています。ここの [追加オプション] をクリックします。

[追加のセキュリティ オプション] が開きますので、真ん中あたりの [回復用コード] の [回復用コードを置換] (または [回復用コードを取得]) をクリックします。

「新しい回復用コード」が表示されますので、印刷する、メモするなどして大切に保管してください（この画面からコピー＆ペーストでメモ帳などに貼り付けた上で、印刷や保存されると良いでしょう）。また併せて [追加のセキュリティ オプション] のページの一番下に表示されている「固有 ID」も同様に印刷やメモとして保存しておきましょう。最悪の場合でも固有 ID と回復コードがあれば、アカウントが回復できる可能性がぐんと高くなります（この二つだけで回復できるかどうかは未確認）。

クレジットカードの登録

最後にもう一つ、支払情報としてクレジットカードを登録しておきましょう。これも本人確認ができる情報なので、アカウントの回復に役立つ場合があります。

クレジットカードを登録するには https://account.microsoft.com/ 一番上の段の [支払いと請求] をクリックして [支払いオプション] を選択します。

[支払いオプションの追加] をクリックして、クレジットカードを登録してください。

最新情報への更新

このようにセキュリティ情報を追加し、回復コードを取得し、クレジットカードを登録しておけば万一パスワードを忘れたり、アカウントがロックされた場合でもその対処がスムーズに行えます。しかしこれらの情報が更新されず古くなっていたら、それでは役に立ちません。実際のトラブルでもセキュリティの連絡先として登録していたメールアドレスや電話番号が利用できなくなっていて、コードが受け取れずパスワードのリセットやアカウントの回復ができないというケースが少なくありません。

複数の情報を登録しておけば、そのすべてが使えなくなる可能性は低くなりますが、それでも長期間放っておけばどれも古くなってしまうリスクがあります。年に1度など定期的に情報を見直して、常に利用可能な連絡先やカード情報は登録されているようにしましょう。

先日、アメリカ・フロリダ州オーランドで開催された Microsoft のテクニカル イベント “Microsoft Ignite” の内容を凝縮して（ダイジェストして、ともいう）世界各地で開催される “Ignite the Tour” の一環、”Microsoft Ignite The Tour Tokyo” が来る 12月5日～6日、東京（会場 ザ・プリンス パークタワー東京）で開催されます。

このイベントで、以下のセッションに登壇させていただくことになりました。

• 新しいEdgeはIEの代わりとなるのか？
  (ブレイクアウト セッション）
  セッション コード: BRK30018
  Day 1 : 12:15PM – 1:00PM

• 新しい Chromium ベースの Edge について IT Administrator が知っておくべきこと
  （シアター セッション）
  セッション コード: THR30009
  Day 1 : 10:20AM – 10:35AM

またこれとは別に、ラーニングパス コンテンツでも以下のセッションを受け持ちます。

• Microsoft 365 管理センターの新機能 (ADM41)
  Day 2 : 3:15pm – 4:00PM

• Office 365 グループの導入 (ADM51)
  Day 2 : 4:30PM – 5:15PM

“Microsoft Ignite The Tour Tokyo” の参加申し込みは残念ながら現在キャンセル待ちとなっていますが、参加予定の方で新しい Chromium ベースの Edge に興味のある方は、ぜひご聴講ください。

またセッション後には Speaker Q&A も行いますので、こちらにもぜひお立ち寄りください。

“Microsoft Ignite The Tour Tokyo” 参加登録ページ
https://register.msignite-the-tour.microsoft.com/tokyo

2020年1月15日に新しい Chromium ベースの Microsoft Edge がリリースされます。

Blocker Toolkit の使い方

現行の Edge を利用している企業やユーザーで、今しばらくは新しい Edge ではなく現行の Edge を利用していたいという希望もあるでしょう。そうした場合に利用できる Blocker Toolkit がリリースされました。

• Blocker Toolkit to disable automatic delivery of Microsoft Edge
  https://docs.microsoft.com/en-us/deployedge/microsoft-edge-blocker-toolkit

利用方法は簡単で、記載されているダウンロード リンクからファイルをダウンロードして実行します。展開先を聞かれるので適当なフォルダー（デスクトップなど）を指定して進むと、4つのファイルが作成されます。このうちの EdgeChromium_Blocker.cmd を管理者として実行したコマンド プロンプトで /B オプションを付けて実行します。

> EdgeChromium_Blocker.cmd /B

これでWindows Update や自動更新で新しい Edge がインストールされるのをブロックできます。

ただしユーザーが自分でインストーラーをダウンロードして実行すれば、新しい Edge のインストールは可能です。インストールには管理者権限が必要ですので、ユーザーにローカル マシンの管理者権限を与えている場合は注意してください。

同じスクリプトを /U オプションを付けて実行すれば、今度はブロックを解除できます。

レジストリ 情報

このスクリプトでは以下のレジストリを構成します。

キー：HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EdgeUpdate
名前：DoNotUpdateToEdgeWithChromium
データ：0 [ブロックしない] / 1 [ブロックする]

グループポリシー

Tooklit を展開してできた EdgeChromium_Blocker.admx と EdgeChromium_Blocker.adml を使えば、グループポリシーで新しい Edge のブロックを構成できます。

EdgeChromium_Blocker.admx を C:\Windows\PolicyDefinitions に、EdgeChromium_Blocker.adml を C:\Windows\PolicyDefinitions\ja-JP に（Windows の表示言語が日本語の場合、それ以外の言語の場合はそれに合わせたフォルダーに）コピーします。

そうするとグループポリシー エディターの

/コンピューターの構成 /管理用テンプレート /Windows コンポーネント /Windows Update

に Microsoft Edge (Chromium-based) Blockers が表示され、”Do not allow delivery of Microsoft Edge (Chromium-Based) through Automatic Updates” という項目が現れます。このポリシーを有効にすることで、ポリシーの対象となるクライアントでの自動更新/Windows Update での新しい Edge のインストールがブロックできます。

なおこのポリシーはタトゥーイングされるので、有効にした場合にそれを取り消してインストールを許可するには、かならず無効のポリシーを適用させてください。

2020年1月15日に新しい Edge が公開されます。新しい Edge は企業向けのブラウザーという位置付けでさまざまな機能が盛り込まれています。とはいえ既に現在の Edge を既定のブラウザーとして活用している組織やユーザーも少なくないでしょうから、新しい edge にいきなり切り替えできないという場合もあるでしょう。そうした場合、新しい Edge に自動更新されたり Windows Update でインストールされたりすることは Blocker Toolkit を使ってブロックできます。

しかし今の Edge を使いつつ、新しい Edge の動作確認や検証をしたいという場合もあります。そうした場合に一番簡単なのは、Blocker Toolkit で新しい Edge の自動適用はブロックしておき、Beta 版 Edge をインストールする方法です。Beta リリースは６週間後に安定板としてリリースされる候補版ですので、基本的に新しい Edge の動作確認・検証で利用するのに問題はないでしょう。

とはいえ現在の Edge を使いつつ、安定板の Edge (Chromium 版) も利用したいというニーズがあります。そうした場合の Side by Side 実行の方法が公開されています。

• Access Microsoft Edge Legacy after installing the new version of Microsoft Edge
  https://docs.microsoft.com/en-us/deployedge/microsoft-edge-sysupdate-access-old-edge

Side by Side 実行を構成する

新旧の Edge を同時利用するには、そのためのグループポリシーを構成します。

1. まずエンタープライズ向け Edge のページからポリシー ファイルをダウンロードします。cab ファイルがダウンロードされるので、Windows エクスプローラーで開くと中に ZIP ファイルがあります。この ZIP ファイルを展開します。いろいろなファイルができますが、windows フォルダーの中に admx フォルダーがあるので、開きます。msedge.admx と msedgeupdate.admx がテンプレート ファイルなので、これを C:\Windows\PolicyDefinitions にコピーします（要管理者権限）。また言語ファイル（Windows の表示言語が日本語なら ja-jp フォルダー）も同じ場所にコピーします。
2. そうるすとグループポリシー エディターの
   /コンピューターの構成 /管理用テンプレート
   に /Microsoft edge、/Microsoft Edge – 既定の設定、/Microsoft Edge の更新、という３つの項目が追加されます。
3. 以下のポリシーを構成します
   /コンピューターの構成 /管理用テンプレート/Microsoft Edge の更新/アプリケーション/Microsoft Edge でのブラウザーの同時実行エクスペリエンスを許可する
   このポリシーを有効にすると、新しい Edge がインストールされても従来の Edge が隠されることなく、今までと同様に利用できます。
   

このポリシーは新しい Edgeがインストールされる前に構成する必要があります。ポリシーの構成前に新しい Edge のインストールが行われると、その時点で従来の Edge は置き換えられてアクセスできなくなります（スタート メニューのタイル、関連付けやピン留めしていたサイトなども全て新しい Edge で開くように変更されます）。後からポリシーの構成を行った場合、再度新しい Edge のインストーラーが実行されるまでポリシーの効果は現れません。またポリシーの効果が現れても、スタート画面や新しい Edge で開くよう変更された関連付け/ピン留めサイトは元に戻りません。

Windows 10 の「バックアップと復元」

Windows のバックアップ機能は Windows XP と Windows Server 2003 R2 までは NTBackup、それ以降の Windows ではシステム イメージ バックアップを含む「バックアップと復元」（Windows Server では「Windows Server Backup」）が標準機能として提供されていました。しかし Windows 10 ではバージョン 1709 以降、システム イメージ バックアップの継続的開発（メンテナンス）は終了し、フル ディスク バックアップはサードパーティーの製品を利用することが推奨されています（Windows 10 features we’re no longer developing に記載）。

とは言え、Windows 10 の「バックアップと復元」が直ちに利用できなくなるわけではありませんし、問題なく利用できる環境も多数あります。また Windows Server では引き続き Windows Server Backup がサポートされていますので、まだまだ現役の機能といえるでしょう。

「バックアップと復元」を利用していてちょっと困るのは、一度設定したバックアップの構成（バックアップ対象やバックアップ先、スケジュールなど）を初期化するユーザーインターフェースがなく、現在の設定の「変更」しかできない点です。通常はそう困ることもないのですが、何らかの理由でバックアップがエラーになったり失敗した際に設定情報の破損や不整合が発生すると、それを上手く修正できなくなる場合があります。

例；バックアップエラーコード0x800070015

「バックアップと復元」の設定を初期化する

何らかのトラブルで「バックアップと復元」の画面が開かなくなったり、設定を変更できなくなったり、正しいと思われる設定をしてもバックアップが行えない場合、レジストリに保存されているバックアップ設定を削除し、設定を初期化することができます。

実際に試してみましょう。まずバックアップの設定を何もしていない状態です。

この時、以下のレジストリ キーの中身は何もありません（値の無い既定があるだけ）
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsBackup\

バックアップの設定を構成して、バックアップを行います。

そうすると、先ほどのレジストリ キー配下に設定情報が書き込まれます。

ここで以下のキーを削除します。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsBackup\
（キーごと削除したので次のキー WindowsUpdate が開いている状態）

[バックアップと復元] を開くと、設定が初期化されています。

Windows 10 バージョン 1903 以降には「ダークモード」が搭載されており、Windows の標準ユーザーインターフェイスをダークモード（黒を基調とした配色）で表示することができます。

またダークモードに対応したアプリでは、Windows システムの設定に従ってダークモードに切り替わるものもあります。個人的には「白時に黒」より「黒字に白」の方がディスプレイの輝度を下げても視認性が良いので、モバイル環境では（ディスプレイの輝度を下げてバッテリーを長持ちさせるため）ダークモードにしています。

ダークモードが反映されない

ところがダークモードに設定したはずなのに、画面の一部が白っぽい表示のままになってしまうことがあります。例えば以下のように、Windows エクスプローラーの一部が正しくダークモードになりません。

※ 「ダークモードでエクスプローラーの一部が白く表示される」から引用

この現象は、ダークモードに切り替える前に適用していたテーマが Windows の配色の一部を上書きしていて、ダークモードに変更してもその設定が残っているからのようです。

そのため、この現象は以下の手順で解決できます。

1. いったんダークモードを解除する
2. [個人設定] – [テーマ] を開く
3. [テーマの変更] で [Windows] を選択して反映させる
4. ダークモードを有効にする

Windows 10 には OneDrive アプリが含まれていて、個人用 OneDrive、OneDrive for Business、SharePoint Online のドキュメント ライブラリをクライアント（Windows PC）に同期することができます。

企業で Microsoft 365 を契約して従来のファイルサーバーや NAS などの代わりに OneDrive for Business や SharePoint Online をクラウド ストレージとして利用する際、以下のような課題が出てくるでしょう。

• PC のストレージが少ないのでファイル オンデマンドを全員有効にしたい（逆にファイル オンデマンドを無効にしたい場合もあるかも）
• 会社の OneDrive for Business との同期はさせたいが、個人用 OneDrive を勝手に同期させたくない
• ネットワーク帯域が有限なので、OneDrive の同期トラフィックを制御したい

こういうニーズには通常グループポリシーを使うのですが、Windows 10 でグループポリシー エディターを開くと、管理用テンプレートに OneDrive の項目がありますが。設定項目が以下のように少ししかありません。

OneDrive だから Office だろうと思って Office 向け管理用テンプレートをダウンロード/適用しても、OneDrive の項目はありません。OneDrive はグループポリシーでは詳細に制御できないのでしょうか。

OneDrive の管理用テンプレート

実は OneDrive 用の管理用テンプレートは OneDrive のインストール フォルダーに用意されています。

OneDrive はマシングローバルまたはユーザー単位でインストールされているので、以下のいずれかがインストール フォルダーです。

%localappdata%\Microsoft\OneDrive\

C:\Program Files (x86)\Microsoft OneDrive\

このフォルダーの中にビルド番号ごとのフォルダーがあり、さらにその中に adm フォルダーがあります。この中に管理用テンプレートが保存されています。

この管理用テンプレートを適切な場所（ローカルであれば C:\Windows\PolicyDefinitions、ドメイン環境でポリシー テンプレートのセントラルストアを使っている場合はそのセントラル ストア）にコピーします。ただし上図で見えている OneDrive.adml はインターナショナル版（英語版）なので、ja フォルダーの中にある adml ファイルを （ローカルであれば C:\Windows\PolicyDefinitions\ja-jp フォルダーに）コピーします。

これで OneDrive 用の管理用テンプレートが準備できました。グループポリシー エディターを再度開くと、OneDrive の項目ができています。

OneDrive の管理用テンプレートで制御できる項目は

• OneDrive が読み取り専用で同期されたフォルダーで Windows アクセス許可の継承を無効にできるようにする
• 特定の組織にのみ OneDrive アカウントの同期を許可する
• Office ファイルの同期の競合を処理する方法をユーザーが選択できるようにする
• ユーザーのディスク領域が不足している場合にファイルのダウンロードをブロックする
• 特定の組織の OneDrive アカウントの同期をブロックする
• Office デスクトップ アプリで共同編集して共有
• チーム サイト ライブラリを自動的に同期するように構成する
• 従量制課金ネットワークのときにも同期を続ける
• デバイスのバッテリー節約機能モードがオンのときに同期を続ける
• 同期済みチーム サイトのファイルをオンライン専用ファイルに変換する
• OneDrive セットアップの最後に表示されるチュートリアルを無効にする
• OneDrive の帯域幅管理の自動アップロードを有効にする
• 同期アプリのダウンロード速度を固定速度に制限する
• 同期アプリのアップロード速度をスループットのパーセンテージまでに制限する
• 同期アプリのアップロード速度を固定速度に制限する
• ユーザーがサインインするまで同期アプリがネットワーク トラフィックを生成できないようにする
• ユーザーが OneDrive フォルダーの場所を変更できないようにする
• ユーザーがリモートからファイルを取得できないようにする
• ユーザーが Windows の既知のフォルダーから OneDrive に移動できないようにする
• ユーザーが Windows の既知のフォルダーから PC にリダイレクトできないようにする
• ユーザーが他の組織から共有されたライブラリとフォルダーを同期できないようにする
• ユーザーが個人用の OneDrive アカウントを同期できないようにする
• Windows の既知のフォルダーを OneDrive に移動するメッセージをユーザーに表示する
• ユーザーがローカル コンピューター上の複数の OneDrive ファイルを削除するときにプロンプトを表示する
• OneDrive 同期アプリの更新プログラムを Deferred リングで受け取る
• 大規模な削除操作ではユーザーの確認が必要
• OneDrive フォルダーの既定の場所を設定する
• ユーザーの OneDrive が自動的にダウンロードできる最大サイズを設定する
• 同期アプリの更新リングを設定する
• サイレント モードで Windows の既知のフォルダーを OneDrive に移動する
• Windows 資格情報を使用して OneDrive 同期アプリにユーザーをサイレント モードでサインインする
• OneDrive ファイル オンデマンドを使用する
• ディスク領域が不足しているユーザーに警告する

これだけあります（「コンピューターの構成」と「ユーザーの構成」それぞれに OneDrive がありますが、設定項目は異なります）。

先ほどあげたファイル オンデマンドの構成や個人用 OneDrive 同期の禁止、帯域制御などの設定も可能になっているのが確認できるでしょう。

参考情報：グループ ポリシーを使用し、OneDrive 同期設定を制御する | Microsoft Docs

この記事では、Windows 11 / 10 で Windows セキュリティを開くことができないトラブルについて解説しています。

現象

Windows 11 / 10 で [設定] の以下の画面から Windows セキュリティを開こうとすると、

次のようなメッセージが表示されて開けないというトラブルがあります。

原因

これは以下のいずれかの状況になっているためです。

• [Windows セキュリティ] アプリが不正な状態になっている
• 現在のユーザーに対して [Windows セキュリティ] アプリがインストールされていない（アンインストールされている）

対策

手順1

この手順は、[Windows セキュリティ] アプリが不正な状態になっている場合への対処です。
以下の手順で [Windows セキュリティ] アプリをリセットします。
[Windows セキュリティ] アプリはストア アプリなので PowerShell を使って強制的にリセットできます。

1. 現象が発生しているユーザー アカウントで Windows にサインインします
2. 画面のスタート ボタンを右クリックし、[Windows PowerShell (管理者)] をクリックします
   ※ [Windows PowerShell (管理者)] ではなく[Windows ターミナル (管理者)] が表示される場合は、それをクリックします
3. 管理者権限への昇格を求めるプロンプトが表示されるので、[はい] をクリックするか資格情報を入力して昇格します
4. 管理者権限の PowerShell コンソールが起動します
5. 以下のコマンドを実行します
   Get-AppxPackage Microsoft.SecHealthUI -AllUsers | Reset-AppxPackage
6. コマンドがエラーにならず完了したら、問題が改善しているか確認してください。

コマンドが以下のようなエラーで失敗した場合は、手順2に進みます。

手順2

この手順は現在のユーザーに対して [Windows セキュリティ] アプリがインストールされていない状況に対する対処です。
以下の手順で [Windows セキュリティ] アプリを再インストールします。

1. 現象が発生しているユーザー アカウントで Windows にサインインします
2. 「手順1」と同様の方法で管理者として起動した PowerShell コンソールで以下を実行します
   Get-AppxPackage Microsoft.SecHealthUI -AllUsers | FL
3. 実行結果の中に、以下のような行があるか確認します
4. PackageUserInformation : {S-1-5-21-406985105-1037201598-2650127460-1002 [*****]: Installed, S-1-5-18 [S-1-5-18]: Staged}
   ※ ”S-1-5-21” から始まる番号はユーザーの SID です。 [*****] の部分には、コンピューター上のユーザ名が表示されます。Installed または Staged になっている情報があれば、次に進みます
5. 起動している PowerShell コンソールで以下を実行します
   Get-AppxPackage -allusers *Microsoft.SecHealthUI* | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register “$($_.InstallLocation)\AppXManifest.xml”}
   ※コマンドが折り返されて表示されている場合がありますが、全体で1行です
6. コマンドがエラーにならず完了したら、問題が改善しているか確認してください。

「2.」のコマンド実行がエラーになる場合、「4.」で SID やユーザー名が表示されない、”PackageUserInformation” から始まる行が無いなどの場合は、以下の記事を参考に Windows の修復インストールを行ってください。

• Windows10 修復インストール方法
  Windows 10 についての記事ですが、Windows 11 の場合も同様です
  Windows 11 の場合は、ダウンロードするページが Windows 11 をダウンロードする (microsoft.com)（https://www.microsoft.com/ja-jp/software-download/windows11 ）になります

参考情報

• Windowsセキュリティが開けずPowershellからの実行でも解決しない₍（Windows11） – Microsoft コミュニティ
• windows defenderが開けない。Windowsセキュリティは再インストールの方法をお教えください。 – Microsoft コミュニティ
• windows11でwindows defenderが開けません – Microsoft コミュニティ
• Windows Security not opening. (Windows 11) – Microsoft Community

Microsoft Edge の InPrivate モードをコマンドラインで起動する方法です。

以下のいずれかで直接 InPrivate モードで起動できます。

C:\Windows\System32\cmd.exe /c start shell:AppsFolder\Microsoft.MicrosoftEdge_8wekyb3d8bbwe!MicrosoftEdge -private

“C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe” –edge-redirect=Windows.Launch -private

[ファイル名を指定して実行] からでも起動できます

この記事は Microsoft 365 Advent Calendar 2023 – Adventar の 12/23 の投稿です

感染症対応での行動制限や働き方改革、デジタルトランスフォーメーションの推進などのさまざまな要因から場所にとらわれない自由な働き方が注目されるようになり、技術的にはVDI（仮想デスクトップ インフラストラクチャー）や RDS（リモートデスクトップ サービス）の導入や導入の検討が増えています。

こうしたリモート接続環境でも今までの（物理デバイスとしての）PC と同じ作業環境を作る必要があるので、Microsoft Office などの生産性ツールの利用は必須です。しかしリモート接続環境でのソフトウェアの利用にはライセンス契約上で物理デバイスでの利用と異なる制限が付く場合があります。
この記事では Microsoft Office (Microsoft 365 Apps) をリモート接続環境で利用する際のライセンス上の注意点についてまとめています。なおリモート接続するオペレーティングシステムは Windows を想定しています。

注意
ソフトウェア製品のライセンス条項への同意とソフトウェアの使用許諾は民事上の契約です。この記事での解説は参考情報として取り扱ってください。記事に記載の内容は契約当事者の権利や行動を制約するものではありません。Office ライセンス製品・Microsoft 365 製品/サービスの契約内容に不明点・疑問がある場合は、Microsoft の営業窓口やライセンス リセラーに相談されるか、弁護士などの法律の専門家の助言を受けてください。

リモートデスクトップ サービス

Microsoft Azure

Azure でリモート接続環境を構築する場合、いくつかの選択肢があります。

Windows Server のAzure 仮想マシンによるリモートデスクトップ サービス

Azure を含む特定のクラウドにはオンプレミスの Office ボリュームライセンスを持ち込むことはできません。クラウドにオンプレミスのライセンスを持ち込むことができるのは、以下のいずれかに該当する場合です。

• ソフトウェア アシュアランスで「ライセンス モビリティ」の対象となっている場合
• 「柔軟な仮想化」の対象となる製品（ソフトウェア アシュアランス付き）を Listed Provider 以外のクラウドに持ち込む場合

Listed Provider とは以下の大手のクラウド プロバイダーです

• Alibaba
• Amazon Web Services
• Google
• Microsoft

（Listed Provider をアウトソーシングサービスの一部として利用するアウトソーサーも該当します）

Office アプリはソフトウェア アシュアランスの「ライセンス モビリティ」の対象とならず、Azure は Listed Provider に含まれ「柔軟な仮想化」を利用できないため、Office ボリュームライセンスを Azure 仮想マシンに持ち込むことはできません。

参考：

• Virtual Machine のライセンスに関する FAQ | Microsoft Azure
  https://azure.microsoft.com/ja-jp/pricing/licensing-faq
• ライセンス モビリティとソフトウェア アシュアランス | マイクロソフト ボリューム ライセンス (microsoft.com)
  https://www.microsoft.com/ja-jp/licensing/licensing-programs/software-assurance-license-mobility
• パートナー ホステッド クラウドの新しいオプション (microsoft.com)
  https://www.microsoft.com/ja-jp/licensing/news/options-for-hosted-cloud
• クラウドへのワークロードとライセンスの導入を容易にする、新たなライセンス特典 – Microsoft Cloud Partner Program Japan 公式ブログ
  https://blogs.partner.microsoft.com/partner-japan/2022-09-12-new-licensing-benefits-make-bringing-workloads-and-licenses-to-partners-clouds-easier-jp/
• Microsoft Product Terms
  https://www.microsoft.com/licensing/terms/ja-JP/product/ForallSoftware/all

そのためリモート接続環境では Microsoft 365 Apps を利用することになります。利用可能な Microsoft 365 Apps のプランについてはオンプレミスの場合と同じです。

• Microsoft 365 Apps for Enterprise または Microsoft 365 Business Premium に含まれる Microsoft 365 Apps for Business
  (Microsoft 365 Business Standard や単体の Microsoft 365 Apps for Business は対象外です）

Windows 10 / 11 の Azure Virtual Desktop

オンプレミスの Office ボリュームライセンスを持ち込むことはできませんので、Microsoft 365 Apps を利用します。ただしシングルセッションの仮想マシンであれば「共用コンピューターのライセンス認証」の必要が無いので、利用できる Microsoft 365 Apps のプランに制限はありません。

マルチセッションの仮想マシンでは「共用コンピューターのライセンス認証」が必要になりますので、オンプレミスの場合と同じでく以下のプランの Microsoft 365 Apps が必要です

• Microsoft 365 Apps for Enterprise または Microsoft 365 Business Premium に含まれる Microsoft 365 Apps for Business
  (Microsoft 365 Business Standard や単体の Microsoft 365 Apps for Business は対象外です）

Windows Server の Azure Virtual Desktop

Windows Server のAzure 仮想マシンによるリモートデスクトップ サービスと同様ですが、オンプレミスの Office ボリュームライセンスは利用できないので Microsoft 365 Apps を利用します。「共用コンピューターのライセンス認証」が必要になりますので、Microsoft 365 Enterprise または Microsoft 365 Business Premium に含まれる Microsoft 365 Apps が必要です。

Windows 365

オンプレミスの Office ボリュームライセンスを持ち込むことはできませんので、Microsoft 365 Apps を利用します。Windows 365 はすべてシングルセッションなので、利用できる Microsoft 365 Apps のプランに制限はありません。

Azure 以外のクラウド

まず大前提として、Azure 以外のクラウド サービスではデスクトップ バージョンの Windows (Windows 10 / Windows 11) を提供できません。そのためリモート接続環境は Windows Server のリモートデスクトップ サービスとなります。

ただし一部のクラウド サービス（Listed Provider、Alibaba・Amazon Web Services・Google・Microsoft) にはオンプレミスの Office ボリュームライセンスを持ち込むことはできません。これ以外のクラウド サービス プロバイダーについては、「柔軟な仮想化」を利用してオンプレミスの Office ボリュームライセンス（ソフトウェア アシュアランス付き）を持ち込むことが可能です。

以下に Azure 以外のクラウドで利用可能なライセンスを示します。

• オンプレミスの Office ボリュームライセンス（ソフトウェア アシュアランス付き）の持ち込み（Listed Provider 以外）
• SPLA (Services Provider License Agreement) による Office ライセンスの購入
• 購入済みの Microsoft 365 Apps ライセンスの持ち込み

利用可能な Microsoft 365 Apps のプランは Microsoft 365 Enterprise または Microsoft 365 Business Premium に含まれる Microsoft 365 Apps です。

SPLA とはクラウド事業者などのサービス プロバイダーが Microsoft から一括してライセンスを調達し、それをエンドユーザーに「貸し出す」形で利用させるサービスです。詳しくは以下を参照してください。

• サービス プロバイダー様向けライセンス プログラム – マイクロソフト ボリューム ライセンス (microsoft.com)
  https://www.microsoft.com/ja-jp/licensing/licensing-programs/spla-program
• SPLA プログラム ガイド (microsoft.com)
  https://download.microsoft.com/download/7/0/3/703FF38D-10AC-46A9-BF58-92473C8D936D/Services_Provider_License_Agreement_Program_Guide_JP.pdf

なお 2025年10月以降、外部で購入した SPLA ライセンスを Listed Provider のクラウド上に持ち込んで利用することができなくなります。これから Listed Provider のクラウド上で利用する SPLA ライセンスを調達する場合は、利用するクラウド ベンダーから SPLA ライセンスを購入してください。

クラウドサービスでの Office アプリケーションの利用については、ベンダーごとのサービスや規約があるので、まず利用するクラウド ベンダーによく相談されることをお勧めします。

付記：クラウドサービスの専用インスタンス

多くのクラウドサービスでは専用インスタンスによる仮想マシンの実行がサポートされています。例えば Azure の Azure Dedicated Host などです。これらのサービスでは仮想マシンはユーザー固有の専用物理ホストで実行されるので、一般的な共有インスタンス（１つの物理ホスト上で複数ユーザーの仮想マシンが実行される）とは異なる環境とみなされる場合があります。

このような専用ホスト クラウド サービスについても、Listed Provider (Alibaba・Amazon Web Services・Google・Microsoft) が提供しているものは一般的な共有インスタンスと同様のクラウド サービスとして扱われます。そのため Office の利用には上掲のクラウドでのライセンスの要件に従う必要があります。Listed Provider 以外の提供する専用インスタンスについては、オンプレミスの環境と同等とみなされます。

おなじみのパケットキャプチャ ツールである Wireshark ですが、最近のバージョンはダークモードをサポートしています。

ただ困ったことにダークモードとライトモードは常にオペレーティングシステムの設定に従って、Wireshark のユーザーインターフェースから切り替えることができません。

この制限は https://gitlab.com/wireshark/wireshark/-/issues/19328 で Issue としても取り挙げられているのですが、WireShark が利用しているユーザーインターフェースフレームワークである QT の側の制限のようで、この Issue によれば QT 側でも対応の予定があるようですが、今のところ既知の問題という状態です。

ただし起動時にオプションを指定することでオペレーティングシステムの設定と異なるモードで Wireshark を起動することができます。Windows の場合、以下のようにオプションを設定します。

• ライトモード
  “C:\Program Files\Wireshark\Wireshark.exe” -platform windows:darkmode=0
• ダークモード
  “C:\Program Files\Wireshark\Wireshark.exe” -platform windows:darkmode=1

または環境変数で

• ライトモード
  set QT_QPA_PLATFORM=windows:darkmode=0
• ダークモード
  set QT_QPA_PLATFORM=windows:darkmode=1

を作っておいて、Wireshark を起動しても同じです。

Windows はダークモードにしているが、Wireshark はライトモードで起動したい（またはその逆）という場合は、当面この方法を使うと良さそうです。

参考
Can I disable dark mode in Windows version