こんにちは、日本マイクロソフトの Windows サポートチームです。

Windows Server 2016 Essentials の Anywhere Access のセットアップ時に、以下のエラーが発生し、完了できない場合の対処策についてご案内します。(Windows Server 2012 Essentials でも同様の症状である場合には本対処策が有効である可能性があります。)

この現象は、当インストールウィザードの処理過程でインストールされる Go Daddy 社の証明書ファイルが、何らかの要因でご利用のサーバーにルート証明機関 (および中間証明書機関) の証明書として登録されていない場合に、発生することが報告されています。

このため、本現象が発生した場合には、以下の手順で証明書ファイルのインストールを実施してください。

1. Internet Explorer で https://www.godaddy.com にアクセスします。
2. ブラウザ上部のアドレスバーの右側のカギのマークをクリックし、”証明書の表示” をクリックします。
3. [証明のパス] タブに切り替え、証明書のパスの 2 段目の “Go Daddy Secure Certificate Authority – G2” を選択して、[証明書の表示] をクリックします。
4. [証明書のインストール] ボタンをクリックします。
5. 証明書のインポート ウィザードが表示されますので、”ローカル コンピューター” を選択して [次へ] をクリックします。
6. “証明書の種類に基づいて…” が選択されている状態で、[次へ] をクリックして [完了] ボタンを押します。
7. 上記操作を実行後、スタートボタンを右クリックし、[ファイル名を指定して実行] をクリックします。
8. “mmc.exe” と入力して “OK” ボタンをクリックします。
9. コンソール1 画面の [ファイル] – [スナップインの追加と削除] をクリックします。
10. 左側の “利用できるスナップイン” の中から “証明書” をダブルクリックします。
11. “このスナップインで管理する証明書” では “サービス アカウント” を選択して “次へ” をクリックします。
12. ローカルコンピュータのまま “次へ” をクリックします。
13. サービスアカウントの一覧にある “Windows Server Essentials Management Service” を選択して “完了” ボタンをクリックします。
14. スナップインの追加と削除画面で “OK” ボタンをクリックします。
15. 証明書スナップインより、[中間証明機関] および [WseMgmtSvc\中間証明機関] の証明書に “Go Daddy Secure Certificate Authority – G2” がインストールされていることを確認します。※1
16. Anywhere Access セットアップを再度実行します。

※1 中間証明書は必須ではありません。
以下の証明書ファイルの [詳細] タブにて確認できる “機関情報アクセス” にて表示される URL へのアクセスが可能である場合には、中間証明書は不要となります。

こんにちは。Windows サポートの神田です。
今回は、Windows 10、Windows Server 2016 で確認されている、フォルダー列挙の動作の問題について記載します。

Windows 10、Windows Server 2016 で、フォルダー列挙の動作に今までのオペレーティング システムと違いがあり、フォルダーを開いている間にデスクトップやフォルダの更新が行われ意図しないダイアログが表示される場合があります。表示されるダイアログは、以下のいずれかです。

• ローカル フォルダーの場合
  

• ネットワーク フォルダーの場合
  

これらのダイアログは、以下のアクセス許可設定を行っているフォルダーを開いた場合に表示されます。

• フォルダーを階層で作成している。
• パスを指定して開けば操作できるよう、下位の層のフォルダーには明示的にアクセス許可を設定している。
• 上位の階層のフォルダーにはアクセスできないよう、アクセス許可を付与していない。

例えば、以下の様なフォルダーのアクセス許可設定を行っている場合に、本事象は発生します。

1. 最上位層と 4 層目に Administrators と Everyone のフル コントロールを設定する。
2. 2、3 階層目から Everyone を削除して Administrators のみにアクセス許可を設定する。
3. 一般ユーザーで 4 階層目にパス指定でアクセスする。

// アクセス許可設定の例
1 階層目: Administrators と Everyone  にNTFS アクセス権限あり
2 階層目: Everyone に NTFS アクセス権限なし
3 階層目: Everyone に NTFS アクセス権限なし
4 階層目: Administrators と Everyone  にNTFS アクセス権限あり

上記は、あくまで一例であり、条件に合致する場合は同様の事象となります。共有フォルダーでもローカル フォルダーでも、ダイアログが異なりますが同様の事象となります。
なお、ダイアログが表示された場合でも、[X] または [キャンセル]、[閉じる] ボタンでダイアログを閉じていただければ、現在開いているフォルダーの操作には影響はありません。
また、この動作は以前のオペレーティング システム (Windows 8.1、Windows Server 2012 R2 以前) では発生しません。

Windows 10、Windows Server 2016 で、新しくファイルを作成したり、削除したり、ファイル名を変更したり、といった操作でデスクトップの表示を更新する処理が走る際に、アクセス権の無い途中の階層のフォルダーについても更新しようとする動作が行われ、アクセス許可が無いフォルダーに対する警告ダイアログが表示されるようになりました。
なお、前述の操作を行っても必ずしもダイアログが表示するわけではなく、一方でフォルダーを表示したまま一定時間放置することでも、表示の更新処理が走るため、このダイアログ表示は不定期に行われます。

本事象は、Windows 10、Windows Server 2016 の想定しない動作であり、次期バージョン (Fall Creators Update) で動作を改修する予定です。また現行の製品に関しても、修正を行うよう現在内部にて修正を進めている状況です。
お客様には、弊社製品の想定しない動作にてご迷惑をおかけしております。今後、修正について情報のアップデートがあれば、引き続き本ブログ内にてお知らせいたしますので、恐れ入りますがお待ちいただきますようお願いいたします。

• 暫定対策について

抜本的な対策にはなりませんが、ターゲットとするフォルダーを、エクスプローラーのコマンド オプションを使用して開くことで、列挙の処理を抑止することができ、警告ダイアログの表示を抑制することが可能です。以下は Explorer.exe に /root オプションを付与してターゲット フォルダーを開く方法となります。

コマンド例)  Share04 のみアクセス許可がある場合
%windir%\explorer.exe /root,”\\ServerName\Share01\Share02\Share03\Share04″

日常的に開くフォルダーが決まっている場合は、ターゲット フォルダーに対するショートカットを上記の方法で作成することで事象の発生を抑止できますので、こちらの暫定策をご検討いただけますと幸いです。

以上です。
よろしくお願いいたします。

神田 友樹

こんにちは、Windows Platform サポートチームです。

本稿では UWF (Unified Write Filter) とエクスプローラー (Explorer) の機能の動作の兼合いによって生じる現象についてご報告致します。
以下現象は Windows 8/Windows 8.1/Windows 10 で発生する可能性がございます。

– 現象

UWF を有効にしてから 6 ヶ月が経過すると、エクスプローラーの一部の通知アイコンが表示されないことがあります。

これは、エクスプローラーがアイコンをロードした最終日時と現在の日時を比較し、6 ヶ月以上差異がある場合、通知アイコンを無効なものとみなして表示しないために発生します。
UWF が有効な場合、アイコンをロードした日時が UWF によって破棄されるために更新されず、UWF を有効化してから 6 ヶ月経過すると本現象が発生します。
UWF には除外設定がありますが、アイコンの最終ロード日時はレジストリ ハイブ ファイル (C:\Users\<User Name>\NTUSER.DAT) に含まれ、このファイル (NTUSER.DAT) は UWF のシステム整合性の制限のために除外することはできません。

– 回避策

以下のレジストリを設定することで、既定の 6 ヶ月の閾値を変更することが可能です。

キー：HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\TrayNotify
名前 : Icon Cleanup Time
タイプ : DWORD
値 : <設定したい閾値を月単位で指定します>
※ 例えば、120 (10進数) を指定した場合、10 年 (=120ヶ月÷12) が閾値となります。

既に UWF が有効な環境の場合、一度 UWF を無効化した後に、上記レジストリを設定して再度 UWF を有効化する必要があります。
これから展開する場合には、既定のユーザー プロファイルに反映する必要があります。

– 参考情報

Unified Write Filter (UWF) feature
https://docs.microsoft.com/en-us/windows-hardware/customize/enterprise/unified-write-filter

※抜粋※
File and folder exclusions
You cannot add exclusions for the following items:
・\Users\<User Name>\NTUSER.DAT

CopyProfile による既定のユーザー プロファイルのカスタマイズ
https://msdn.microsoft.com/ja-jp/library/hh825135.aspx?f=255&MSPPError=-2147217396

本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

こんにちは。 Windows サポートの水上です。

最近、 Windows サポート チームに、次のようなお問合せがありました。

お問合せ例 1:

Processor Queue Length パフォーマンス カウンターでのボトルネック判断基準を確認したい。

お問合せ例 2:

パフォーマンス カウンターを監視していたところ、 Disk Queue Length の上昇がみられた。どのように判断すればよいか、確認したい。

今回は、このような疑問に “Queue Length” の意味合いにも触れながらお答えします。
 

そもそも Queue Length とはなんなのか?

 
Queue Length とは、待ち行列の長さのことです。
Processor Queue Length であれば、 CPU コアの割り当てを待つスレッドの行列の長さを、 Disk Queue Length であれば、ディスクの読み書きを待つリクエストの行列の長さを指します。

CPU もディスク ドライブも、一度に 1 つの処理しか実行できません。
そのため、ある処理が CPU やディスク ドライブを使用している間、他の CPU やディスク ドライブを必要とする処理は実行中の処理が終わるのを待つ必要があります。
待ち行列の長さとは、この他の処理が終わるのを待っている処理の数のことです。

Windows では、 Processor Queue Length を監視するパフォーマンス カウンターとして、以下のカウンターが提供されています。

• \System\Processor Queue Length
  CPU の処理を待つスレッドの数。カウンター採取時の瞬時値。

同様に、 Disk Queue Length を監視するパフォーマンス カウンターとして、以下のカウンターが提供されています。

• \LogicalDisk\Current Disk Queue Length
  ディスクの読み書きを待つリクエストの数。パーティションごと。値はカウンター採取時の瞬時値。
• \LogicalDisk\Avg. Disk Queue Length
  ディスクの読み書きを待つリクエストの数。パーティションごと。値はカウンター採取間隔の平均値。
• \LogicalDisk\Avg. Disk Read Queue Length
  ディスクの読み込みを待つリクエストの数。パーティションごと。値はカウンター採取間隔の平均値。
• \LogicalDisk\Avg. Disk Write Queue Length
  ディスクの書き込みを待つリクエストの数。パーティションごと。値はカウンター採取間隔の平均値。
• \PhysicalDisk\Current Disk Queue Length
  ディスクの読み書きを待つリクエストの数。物理ドライブごと。値はカウンター採取時の瞬時値。
• \PhysicalDisk\Avg. Disk Queue Length
  ディスクの読み書きを待つリクエストの数。物理ドライブごと。値はカウンター採取間隔の平均値。
• \PhysicalDisk\Avg. Disk Read Queue Length
  ディスクの読み込みを待つリクエストの数。物理ドライブごと。値はカウンター採取間隔の平均値。
• \PhysicalDisk\Avg. Disk Write Queue Length
  ディスクの書き込みを待つリクエストの数。物理ドライブごと。値はカウンター採取間隔の平均値。

ところで、待ち行列は、コンビニで 1 台のレジに並ぶお客さんの行列にたとえることができます。
1 台のレジ ( CPU コアやディスク ドライブ) は一度に 1 人のお客さん (処理) しか対応できないため、お会計を待つお客さんは行列を作ることになります。
お客さんの行列の長さ (Queue Length) は、コンビニの混雑状況を把握する重要な指標です。

また、コンビニでレジの台数を増やすと、同時に対応できるお客さんの数が増えお客さんの待ち時間を短縮できるように、 CPU のコアや物理ディスクの数を増やすと、同時に処理できるスレッドやリクエストの数が増え、システムの処理遅延を小さくすることができます。
 

Queue Length にはどのような意味があるのか?

 
待ち行列には、長期間観測した待ち行列の長さの平均が、システムの負荷量と処理遅延の積として得られる、という重要な性質があります。
この性質は、リトルの法則と呼ばれ、次の等式で説明されます:

<平均系内客数>  =  <平均到着率>  X  <平均サービス時間>

ここで、 <系内客数> は平均の待ち行列長、 <平均到着率> は単位時間あたりの処理要求数の平均 (つまりシステムの負荷量)、 <平均サービス時間> は 1 つの処理を行うのにかかった時間の平均 (つまり処理遅延) に相当します。

リトルの法則を読み解くと、 Queue Length を長期的に観測することによって、システムの負荷の状況やシステムの処理遅延の状況も把握できることがわかります。
 

どのように Queue Length の値を読むか?

 
Queue Length の判断基準に関するお問合せに対して、私たちは次のようにご案内しています:

まずは、 Queue Length が瞬間的に上下しているのか、常に高い状態にあるのかをご確認いただければと存じます。
Queue Length が急上昇後すぐに降下し、グラフがスパイク状になる場合、実行待ちは短期間で解消されていると判断できます。
一方で、 Queue Length の値が常時高い傾向にある場合や、上昇傾向にある場合は、調査が必要です。

先ほどのコンビニのレジの話でたとえてみましょう。

レジの待ち行列長がスパイク状に変動するとき、コンビニでは、時より複数のお客さんが同時に訪れ、すぐに立ち去る、という様子が観察できます。
確かに一時的に待ち行列の長さが長くなりますが、お客さんのお買い物は比較的短時間に終わります。

一方で、レジの待ち行列長が 0 にならない状況が持続するとき、コンビニでは、いつでもレジに人が並んでいる、という状況が発生します。
当然、レジ待ちに不満を持つお客さんが増え、お会計を待ちきれないお客さんも出てきます。

また、レジの待ち行列長がどんどん長くなるとき、コンビニでは、買い物を済ませるお客さんよりも、コンビニにやってくるお客さんの方が多いという状態が発生します。
最終的に、コンビニはお客さんであふれかえってしまいます。

同じことが、 Processor Queue Length や Disk Queue Length にも言えます。
待ち行列長がスパイク状に変動しているうちは、比較的処理遅延は短く抑えられていると考えることができます。
しかし、待ち行列長が 0 にならない状況では、常に処理遅延が発生していると考えられ、体感上のパフォーマンス劣化がみられる場合もあります。
さらに、待ち行列長が増加し続けるようであれば、負荷が処理能力を超えてしまっており、システムは不安定な状態に陥っていると判断できます。

先ほど登場したリトルの法則でも同じことが説明できます。
リトルの法則は、 Queue Length を長期的に観測し平均化した値について等式が成り立ちます。
Queue Length を平均化すると、スパイクの影響は相対的に小さくなるため、結果として平均の待ち行列長は小さくなり、等式からシステム負荷や処理遅延も小さくなります。
ゆえに、 Queue Length の変動がスパイク状であれば、パフォーマンスに大きな影響は出ていないと判断できます。
 

Queue Length を監視するにあたって注意したいこと

 
パフォーマンスの体感は最終的に遅延で決まる。
待ち行列が長いこと自体が問題なのではない。

Processor Queue Length や Disk Queue Length を監視するにあたっては、この 2 点に注意する必要があります。
これは、コンビニのお客さんにとって不満なのは、混雑していることではなくお会計に時間がかかることである、ということと似ています。
システムのパフォーマンスを評価する際には、特定のカウンターだけにとらわれず、複数の指標をつかって多角的に評価することを心がけてください。

こんにちは、Windows プラットフォーム サポートです。
今回は Windows Server 2012 のフェールオーバー クラスター環境で、CSV を利用する場合の SMB Multichannel 設定の考慮事項を紹介いたします。

[事象]
以下のシナリオを想定します。

・Windows Server 2012 のフェールオーバー クラスターを構成します。
・CSV を構成します。
・クラスター ノードで SMB Server 側の Multichannel を無効化します。(Set-SmbServerConfiguration -EnableMultiChannel $false)

このとき、以下のような事象が発生することがあります。

・クラスターの検証で、CSV の構成確認の項目で以下のエラーが記録されます。
「ノード ‘<ノード名>’ からノード ‘<ノード名>’ 上の共有へのサーバー メッセージ ブロック (SMB) プロトコルを使用したアクセスを検証しています。
フェールオーバー クラスタリング用のフォールト トレラント ネットワーク ドライバー (NetFT) の IP アドレスによるサーバー メッセージ ブロック (SMB) 共有のアクセスを検証できませんでした。
接続は、クラスターの共有ボリュームのテスト ユーザー アカウントを使用し、ノード ‘<ノード名>’ からノード ‘<ノード名>’ の共有に対して試行されました。
コンピューターへの接続数が最大値に達しているため、これ以上このリモート コンピューターに接続できません。」

・Hyper-V クラスターを構成している場合に、仮想マシンのライブマイグレーションに失敗します。

[原因]
CSV を利用するクラスター環境で、SMB Server 側の Multichannel を無効化した場合、クラスターノード間の SMB 通信で Session Setup が失敗し続けることがあります。
これにより、CSV へのアクセスが失敗するために本事象が発生します。

[回避策]
CSV を利用するクラスターノードで SMB Multichannel 機能を無効化する場合は、SMB Client 側でのみ無効化し、SMB Server 側の MultiChannel は有効化してください。

SMB Client で Multichannel 無効化する PowerShell コマンド
> Set-SmbClientConfiguration -EnableMultiChannel $false

SMB Server で Multichannel 有効化する PowerShell コマンド
> Set-SmbServerConfiguration -EnableMultiChannel $true

補足 1 : 発生 OS について
本事象は Windows Server 2012 でのみ発生し、Windows Server 2012 R2 以降では発生しません。

補足 2 : CSV にアクセスする際に発生する SMB 通信について
クラスター共有ボリューム (CSV) へアクセスする際に CSV のコーディネーターノード (ディスクの所有ノード) と非コーディネーターノードで SMB プロトコルを使用した通信を行います。

非コーディネーターノードがストレージパスの障害で、直接 CSV にアクセスできない場合は、すべての I/O が、この SMB 通信経由でコーディネーターノードに送られ、CSV 上のファイルにアクセスします。(リダイレクトアクセス)
また、すべてのノードが CSV にアクセスできる場合は、非コーディネーターノードは直接 CSV 上のファイルに対してアクセスすることが可能ですが、一部の I/O (NTFS の管理情報 (メタデータ) の更新) においては、SMB 通信により CSV のコーディネーターノードを介して行います。
これはメタデータの操作はファイルシステムの整合性を保つために CSV のコーディネーターノードしか行えないためです。

この SMB 通信は CSV 用のネットワークを使用しますが、Windows Server 2012 以降の環境では SMB Multichannel の機能が既定で有効となるため、複数のネットワークを使用して行います。

補足 3 : Multichannel 無効化時の CSV 通信とメトリックについて
SMB Multichannel の機能を無効化した場合、クラスターはメトリック値の一番低いネットワークを CSV 用のネットワークとして使用します。

このメトリック値は、クラスター ネットワークのプロパティとして管理しているメトリックを指します。(ネットワーク インターフェースのメトリック値とは異なります)

以下に、クラスター ネットワークのメトリック値の確認方法を紹介します。

[クラスター ネットワークのメトリック値確認方法]
管理者権限の PowerShell (64bit) を起動し、以下のコマンドレットを実行します。

> Get-ClusterNetwork | ft Name, Metric

SMB Multichannel を無効化した場合は、メトリック値が一番低いクラスター ネットワークを使用してリダイレクト I/O 処理を行います。

本ブログが少しでも皆様のお役に立てば幸いです。

本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

こんにちは。Windows サポートの高橋です。皆さんは Windows に標準でサポートされている “タスク スケジューラー” はご存じでしょうか。

下記のようなアプリケーションを一度はご覧いただいたことがあるかもしれません。

タスク スケジューラーでは、”タスク” という単位で特定のアプリケーションやスクリプト等を実行することが可能であり、特定の時間に指定したユーザーで起動する等の細かい設定が可能になります。

タスクの登録方法としては、上記画面のタスク スケジューラーから、GUI 操作により登録する方法に加え、PoweShell のコマンドレット および “schtasks.exe“ とよばれるプログラムによりコマンドで登録する方法があります。

Schtasks コマンドでは、タスクの作成や設定の変更、削除、および実行など様々な動作を指定できるオプションが用意されており、一度だけ実行したいタスクの場合 /Z オプションを付与して実行後にタスクを削除することも可能です

先日 Windows サポート チームに Windows Server 2012 R2 の環境において schtasks コマンドに /z オプションを付与して登録したタスクの起動が失敗して、エラーのイベントに ‘エラー値: 2147942402’ が出力されたとのお問合せがありましたため、同様の状況が発生した際のご参考情報としてご案内したいと思います。

簡単に言うと  /z オプションを付与して schtasks コマンドから作成したタスクの実行に失敗する状況になります。

事象発生の前提条件について:

以下のコマンドの実行例の通り、/Z オプションを付与した場合に上記の事象が発生する状況が確認されました。

schtasks コマンド実行例:

> schtasks /Create /TN <タスク名> /TR <実行タスク> /SC ONCE /SD 2017/MM/DD /ST hh:mm /RU System /RL HIGHEST /F /V1 /Z

上記で登録されたタスクは 2017 年 MM 月 DD 日 hh 時 mm 分に System アカウントの権限で 一度のみ実行された後、登録されたタスクが削除されることを想定しております。/Z オプションはタスク実行後に当該タスクの登録を削除するために指定します。

/V1 オプションは /Z オプションを指定するために必要なオプションになり、タスクの構成をWindows Vista より以前の Windows 製品の設定とするために指定します。

事象発生時のイベント ログについて:

schtasks コマンドで /Z オプション付きで登録したタスクの実行が失敗した場合、’エラー値: 2147942402′ が以下のエラー イベントに出力されることが確認されています。

————————————————
ログの名前:         Microsoft-Windows-TaskScheduler/Operational
ソース:           Microsoft-Windows-TaskScheduler
イベント ID:       101
タスクのカテゴリ:      タスクの開始が失敗しました
レベル:           エラー
説明:
タスク スケジューラは、ユーザー “ユーザー名” の “\タスク名” タスクを開始できませんでした。追加データ: エラー値: 2147942402。
————————————————

————————————————
ログの名前:         Microsoft-Windows-TaskScheduler/Operational
ソース:           Microsoft-Windows-TaskScheduler
イベント ID:       706
タスクのカテゴリ:      互換性モジュールのタスク状態の更新に失敗しました
レベル:           エラー
説明:
タスク互換性モジュールで、タスク “タスク名.job” を必要な状態 3 に更新できませんでした。追加データ: エラー値: 2147942402。
————————————————

————————————————
ログの名前:         Microsoft-Windows-TaskScheduler/Operational
ソース:           Microsoft-Windows-TaskScheduler
イベント ID:       706
タスクのカテゴリ:      互換性モジュールのタスク状態の更新に失敗しました
レベル:           エラー
説明:
タスク互換性モジュールで、タスク “タスク名.job” を必要な状態 4 に更新できませんでした。追加データ: エラー値: 2147942402。
————————————————

想定される事象発生の状況について:

エラー値: 2147942402 は E_FILE_NOT_FOUND を意味しており、タスク実行時に参照するファイルおよびレジストリが見つからなかった状況を意味しております。

事象発生時にはタスクの実行が要求された後、タスクの開始処理が完了するよりも前にタスクの削除の処理が進んでしまうことで、タスクの開始を行うため必要なレジストリやファイルが削除されてしまった場合に、エラー値: 2147942402 がエラー イベントに出力される状況が想定されています。

事象の対処について:

エラー値: 2147942402 がエラー イベントに出力される詳細な手順および原因については特定に至っていない状況です。現時点におきまして エラー値: 2147942402 がタスク　スケジューラーのエラー イベントに出力されてタスクの実行に失敗した場合は、/Z オプションおよび /T1 オプションを指定しないで schtasks コマンドを実行することをご検討ください。

こんにちは、 Windows Platform サポート チームの松村です。
サーバーのOSをアップグレードする際、 Hyper-V 上に構成された仮想マシンも新しい OS に移行する必要がありますが、どのように移行すればよいか困ったことはありませんか？
今回はよくあるお問い合わせの一つとして、 Windows Server 2016 の Hyper-V へ仮想マシンを移行する手順についてご紹介いたします。

Windwos Server 2016 では　Hyper-V の構成バージョンとして 5.0 以降をサポートしています。
構成バージョン 5.0 以降となるホスト OS は、 Windows Server 2012 R2 以降となります。
そのため移行元の仮想マシンを作成された環境によって、移行の手順が異なります。

◆ Windows Server 2012 R2 以降の場合
Windows Server 2012 R2 以降の Hyper-V 環境で作成された仮想マシンは、少ない手順で仮想マシンを移行することができ、スナップショットやネットワーク構成の移行も可能です。
移行は次の手順で行います。

移行手順

1. 移行元サーバーで、移行したい仮想マシンをオフにします。
2. 移動する仮想マシンの仮想ハード ディスクやスナップショットを含むフォルダをコピーし、以下のように構成します。
   ※移動する仮想マシンを右クリック→「エクスポート」を選択することでも同様のフォルダが作成されます。
   blog-test12r2 （仮想マシンのフォルダ）　　　　┣- Snapshots （スナップショットを作成していない場合、必要ありません）　　　　┣- Virtual Hard Disks （仮想ハード ディスクを含むフォルダ）　　　　┗- Virtual Machines （仮想マシンの構成ファイル (XML ファイル) を含むフォルダ）
3. 仮想マシンのフォルダごとコピーし、移行先の Windows Server 2016 の任意の場所へ配置します。
4. Windows Server 2016 で Hyper-V マネージャーを起動し、仮想マシンを配置するサーバーを選択します。「操作」→「仮想マシンのインポート」を選択すると、「仮想マシンのインポート ウィザード」が開始します。
5. 「フォルダーの検索」で、手順 3. で配置した仮想マシンのフォルダを指定します。
6. 「仮想マシンの選択」では、インポートする仮想マシンを選択します。「インポートの種類の選択」では、インポート方法を選択し、[次へ] ボタンをクリックします。 例では以下のインプレースでのインポートを実施するとします。
   ※インポート方法の詳細につきましては、仮想マシンのエクスポートとインポートの概要をご確認ください。
7. 「ネットワークへの接続」で仮想スイッチのエラーが出た場合、移行元の仮想マシンの構成に沿う適切な仮想スイッチを選択してください。
8. 要約が表示され、問題がなければ完了を選択すると仮想マシンの移行が完了します。

◆ Windows Server 2012 以前の場合
Windows Server 2012 以前の Hyper-V 環境で作成された仮想マシンの構成バージョンについては、 Windows Server 2016 では動作がサポートされていません。
そこでインポートではなく、移行元仮想マシンの VHDX （または VHD ）ファイルを用いて仮想マシンを新規作成する必要があります。
※Windows Server 2012 R2 の環境がご用意できる場合、 Windows Server 2012 R2 にインポートし、上記の「 Windows Server 2012 R2 以降の場合」の手順で移行していただくことも可能です。 Windows Server 2012 以前から、 Windows Server 2012 R2 への仮想マシンの移行については、こちらをご参考ください。
既存の VHDX ファイルを用いて仮想マシンを新規作成する場合、ゲスト OS 内のネットワーク構成は保持されません。
そのため、移行前に IP アドレスなどのネットワーク構成をメモしておくことをおすすめします。
Hyper-V ホストとしては、 CPU やメモリ構成、スナップショット（ 2008 R2 以前ではチェックポイント）なども移行できません。
そのため、移行前に CPU やメモリ構成などの仮想マシンの構成をメモしておくことをおすすめします。
また、スナップショットは VHDX ファイルではなく AVHDX（ AVHD ）ファイルに書き込まれますが、以下のいずれかの方法でスナップショットを VHDX ファイルに結合することで、最新の仮想マシンのデータを移行することが可能です。
（スナップショットを作成していない環境の場合、以下の方法はスキップしていただけます。）

どちらの方法も、実行前に移行したい仮想マシンはオフにします。

方法１：スナップショットをエクスポートする方法
（ディスク容量が必要ですが、元の環境を壊さずに移行可能です）

1. 移行元サーバーで移行したい仮想マシンを選択し、移行したい時点のスナップショットを右クリック→エクスポート、保存先を指定してエクスポートします。
   ※現在の状態の仮想マシンを移行する場合、スナップショットを作成し、作成したスナップショットをエクスポートします。
2. 「（保存先のパス）¥（仮想マシン名）¥Virtual Hard Disks¥」に、仮想マシンのVHDXファイルが作成されます。

方法２：スナップショットを結合する方法（ディスク容量が気になる方は、こちらの方法をお試しください）

1. 移行元サーバーで移行したい仮想マシンを選択し、一番上のスナップショットを右クリックします。
2. 右クリックメニューから「スナップショットのサブツリーを削除」を選択します。この操作により、スナップショットが変更の古い順に結合され削除されます。
   ※結合するファイルのサイズにより、処理に時間がかかる場合がございます。
   
3. 仮想ハード ディスクの保存先を確認し、 AVHDX ファイルが削除されていれば結合は完了です。

スナップショットが結合された移行元の仮想ハード ディスクを元に、移行を行います。

移行手順

1. 移行したい仮想マシンの仮想ハード ディスク ファイル（ VHDX ファイル）をコピーし、移行先の Windows Server 2016 の任意の場所へ配置する。
2. Windows Server 2016 で Hyper-V マネージャーを起動し、仮想マシンを配置するサーバーを選択します。「操作」→「新規」→「仮想マシン」を選択すると、仮想マシンの新規作成ウィザードが開始します。
3. 「名前と場所の指定」、「世代の指定」、「メモリの割り当て」、「ネットワークの構成」は適宜適切な設定をお願いします。
4. 「仮想ハード ディスクの接続」で、「既存の仮想ハード ディスクを使用する」を選択し、手順 1. の VHDX ファイルを指定します。
   
5. 要約が表示され、問題がなければ完了を選択すると仮想マシンの移行が完了します。

※注意点
既存の VHDX ファイルを使用して作成された仮想マシンは、レジストリ キーに既存の NIC の情報が残っている場合があります。
そのため、移行先の NIC に移行前と同一の IP アドレスを設定しようとすると、以下のエラーが表示されます。

こちらのエラーは、新規作成で移行された仮想マシン上で以下の操作を行うことにより回避することができます。
♦ネットワーク アダプターに IP アドレスを設定する際のエラー メッセージ
https://support.microsoft.com/ja-jp/help/269155/error-message-when-you-try-to-set-an-ip-address-on-a-network-adapter

こんにちは、 Windows & Device チームの松村です。
私どもに寄せられるお問い合わせとして、以下のようなお問い合わせをいただくことがございます。

例 1:
KMS ホスト キーをインストールしようとしたところ、
エラーが発生し KMS ホスト キーのインストールができなかった。

例 2:
KMS ホストでキーが入力できない。

今回はこのようなお悩みにお答えし、 KMS ホスト キーを選ぶ際のポイントについてご説明いたします。

そもそも KMS ホスト キーとは？
Microsoft の製品では、製品の使用の際にライセンス認証を行う必要があります。
組織で特定の数のクライアントのライセンス認証を行う際は、Microsoftとボリューム ライセンス契約を結ぶことでプロダクト キーが使用できます。
各クライアント コンピューターが独立して Microsoft に接続でき、小規模な環境の場合、マルチ ライセンス認証キー (MAK) を使用します。
一方、クライアント コンピューターは外部ネットワークに接続できない環境や、大規模な環境の場合、キー管理サービス (KMS) を使用します。

KMS や MAK の詳しい説明は、こちらのリソースをご参照ください。
◆ボリューム ライセンス認証の概要
https://msdn.microsoft.com/ja-jp/library/hh831612(v=ws.11).aspx

KMS では、認証サーバーの役割を持つ KMS ホストがネットワーク環境内の各クライアント コンピューターのライセンス認証を承認します。
この KMS ホストを構築するために、 KMS ホスト キーが必要となります。
※各クライアント コンピューターのライセンス認証を実行するキーは、汎用ボリューム ライセンス認証キーであり KMS ホスト キーとは異なります。

KMS ライセンス認証についてやキーの役割については、こちらのリソースをご参照ください。
◆ボリューム アクティベーション 2.0 – KMS ライセンス認証について
https://blogs.technet.microsoft.com/askcorejp/2009/10/30/2-0-kms-12/
◆ボリューム ライセンス認証の計画
https://technet.microsoft.com/ja-jp/library/mt269356(v=vs.85).aspx

どの KMS ホスト キーを選べばいいの？
KMS ホスト キーは、ボリューム ライセンス サービス センター (VLSC) の専用ページから入手することが可能です。
(ボリューム ライセンスの契約を持っているお客様の専用ページになります。)
KMS ホスト キー名は、以下の構成となっています。
“ KMS ホストとなるコンピューターの OS 名” KMS “ KMS によるライセンス認証を実行するクライアント コンピューターの OS 名（上位 OS 名）”
以下は、 VLSC 専用サイト上で表示される KMS ホスト キー名の例です。

・Windows Srv 2012 R2 DataCtr/Std KMS for Windows 10
・Windows Srv 2016 DataCtr/Std KMS

したがって、 KMS ホスト キーを選ぶ際に見るポイントは、次の 2 点です。

① KMS ホストとなるコンピューターの OS
上記の例では、 KMS 以前に書かれている “Windows Srv 2012R2 DataCtr/Std” の部分が、KMS ホストとなるコンピューターの OS を表します。
KMS ホスト キーは KMS ホストとなるコンピューターの OS に依存するため、認証したいコンピューターの OS ではなく、KMS ホストとなるコンピューターの OS 名のキーを選ぶ必要があります。
例えば以下のシナリオでは、認証したいコンピューターの OS は Windows 10 ですが、 KMS ホストの OS は Windows Server 2016 のため、 必要となるKMS ホスト キーは “Windows Srv 2016 DataCtr/Std KMS” です。

また、KMS ホストは Windows Server 2016 などのサーバー製品および Windows 10 などのクライアント製品、どちらの OS を実行しているコンピューターでも構築可能です。
ただし、Windows Server 2016 などのサーバー製品を実行している KMS ホストは、ボリューム ライセンス認証をサポートするあらゆるサーバー製品およびクライアント製品のライセンス認証を実行できますが、Windows 10 などのクライアント製品を実行している KMS ホストがライセンス認証を実行できるのは、クライアント製品のライセンス認証のみです。

② KMS によるライセンス認証を実行するコンピューターの OS
KMS ホストによるライセンス認証を実行するコンピューターの OS は、 KMS ホストとなるコンピューターの OS に依存します。
基本的にホスト OS の上位 OS に対する認証機能がないため、例えば、 “Windows Srv 2012R2 DataCtr/Std KMS” のキーで構築された KMS ホストは、 Windows 10 のコンピューターを認証できません。

しかし、上記の例 “Windows Srv 2012R2 DataCtr/Std KMS for Windows 10” のように KMS 以降に書かれているバージョンの OS の認証にのみ対応した KMS ホスト キーもございます。
（この場合、 Windows Server 2012 R2 までのすべてのサーバー製品および Windows 10 までのすべてのクライアント製品のライセンス認証を実行できます。）
※ただし、 “Windows Srv 2012R2 DataCtr/Std KMS for Windows 10” をお使いいただいた場合でも、”Windows 10 LTSB 2016” は認証できません。 KMS ホスト キーによって認証可能なコンピューターの OS のバージョンが異なる場合があるため、どの KMS ホスト キーを使用すればよいかご不明な場合は、お問い合わせいただくことをおすすめします。

まとめ
実際の環境では上図のように OS が統一されているわけではなく、Windows 7 や 8.1 など古い OS が混在していることも多いです。
そのため、

クライアントとなるコンピューターに Windows 7 と Windows 10 が混在している場合、それぞれの KMS ホスト キー (Windows 7 用と Windows 10 用のもの) を入れないといけないのか？

というお問い合わせもよくいただきます。

OS 製品の KMS 認証は 1 つの KMS ホスト キーで複数の OS 製品のライセンス認証を行うイメージであり、各 KMS ホスト キーは下位互換があります。
そのため、認証対象となるコンピューターの OS 製品に合わせて複数の KMS ホスト キーを入れる必要はなく、一番上位の OS 製品となる認証対象に合わせて KMS ホスト キーを選んでいただければ問題ありません。
また、KMS ホストには OS 製品認証用の KMS ホスト キー 1 つのみインストール可能ですので、すでに KMS ホストにキーがインストールされていた場合、新しい KMS ホスト キーをインストールした時点で古い KMS ホスト キーが上書きされます。

まとめますと、 KMS ホスト キーを選ぶ際は KMS ホストとなるコンピューターの OS を基準に、認証対象となるコンピューターの OS がホスト OS に対応しているか（サーバー製品を KMSホストとして構築するための KMS ホスト キーをクライアント製品のホストに入力しようとしていないか？、ホストよりクライアントが上位 OS でないか？）をご確認ください。

以上、今回は KMS ホスト キーを選ぶ際のポイントについてご紹介させていただきました。
本記事が皆様の疑問解決のお役に立てれば幸いです。

こんにちは。Windows サポートの鈴木です。

印刷の出力先として LPD サーバーを指定いただく際のポートの設定についてご紹介いたします。

LPR プロトコルを使用した印刷は、プリント サーバーが UNIX / Linux 等の場合に使用されるほか、
サーバー側で印刷のログを取得したり、ドキュメントを蓄積、分類等を行うアプリケーションなどを
ご使用の際にも使用されることがあります。また、お使いのプリンターが対応している場合は、
LPR プロトコルを使用して直接印刷を実行できる場合もあります。

さて、ここで注意いただきたいのが、印刷の相手がサーバーなのか、プリンターなのかという点です。
Windows の既定の状態で、プリンターに対して LPR プロトコルで印刷データを送信するために
「標準 TCP/IP ポート モニター」が使用可能となっています。

同じ LPR プロトコルですから、この「標準 TCP/IP ポート モニター」 を使用して
プリンターではなく LPD サーバーへの印刷を行うことも、多くの場合は可能です。
しかしながら、サーバーとクライアント間のネットワークが切断された場合の
リトライ動作等で予期しない事象が発生するという報告をお寄せいただいております。

LPD サーバーへの印刷を行う場合のために、Windows では LPR を専門に扱う
「LPR ポート モニター」をご用意しております。
プロトコルこそ同じですが、使用する TCP ポートの範囲や、細かな制御に相違があり、
LPD サーバーへ印刷を行う際はこちらをお使いいただくことを推奨しております。

LPR ポート モニターは既定では有効となっておらず、「Windows の機能の有効化または
無効化」や「サーバー マネージャー」にて手動で有効化いただく必要がございます。

LPR ポート モニターが正常に追加されると、プリンター ポートを作成する際、
“LPR Port” が選択可能になります。
サーバー名または IP アドレスと、印刷先のキュー名を入力するとLPR ポートが作成されます。

「標準 TCP/IP ポート モニター」でも一見正しく動作しているように見えることが多いため
見過ごしがちですが、より安定した LPD サーバーへの印刷のためにも、今一度ご確認をいただけ
ますと幸いです。

念のためお伝えいたしますが、Windows 8 / Windows Server 2012 以降では、LPR ポート モニターの
使用は非推奨とされております。
しかしながら、現時点では Windows 10 を含む最新の Windows にも機能としては搭載されており、
具体的な削除の予定は決まっておりません。また、非サポートではございませんので、
我々 Windows サポート チームにてご質問をお受けすることも引き続き可能です。安心してご利用
いただけましたら幸甚です。

参考情報 : ライン プリンター リモート ポート モニターの概要

https://technet.microsoft.com/ja-jp/library/cc732063(v=ws.11).aspx

参考情報 : Windows Server 2012 で削除された機能または推奨されなくなった機能

https://msdn.microsoft.com/ja-jp/library/hh831568(v=ws.11).aspx

こんにちは、 Windows & Device グループの松村です。
今回は VMware 環境で確認されている、VMware 環境で作成された仮想マシンのドライブにアクセスできなくなる事象について、グループ ポリシーに触れながらご説明いたします。

グループ ポリシーとは？
グループ ポリシーとは、その名の通りグループに適用されるポリシー（方針・規範）のことです。
各ポリシー項目は様々であり、一例として以下が挙げられます。

・コントロール パネルと PC 設定へのアクセスを禁止する・プリンターを追加できないようにする・ユーザーのログオン時に実行するプログラムを指定する		など

グループ ポリシーは個別に設定されるのではなく、多岐にわたるカテゴリーのポリシーの設定をまとめたものをグループ ポリシー オブジェクト (GPO) として作成し適用するのが基本動作となります。
このポリシーの割り当ては Active Directory ドメイン サービス (AD DS) で管理された複数のコンピューターに一括で割り当てることが可能です。
また、AD DS に参加していないローカル コンピューターでもローカル グループ ポリシーを利用することで実現が可能です。
GPO は階層順に優先度があり、次のように子組織単位 (OU) に適用される GPO が最も優先されます。

1. 子 OU
2. 親 OU
3. ドメイン
4. サイト
5. ローカル コンピューター

複数の階層で GPO で設定した場合、各ポリシー項目ごとに最上位の階層の GPO で設定されたポリシーの設定が適用されます。
(例えば、子 OU とドメインそれぞれに GPO が設定されているが、ドメインの GPO はポリシー項目 A について設定されており、子 OU の GPO はポリシー項目 A について設定されていない場合、ポリシー項目 A にはドメインのポリシー設定が適用されます。)

昨今のセキュリティ事情により情報漏えい対策の一環として重要な「リムーバブル ディスクの制御」も、このグループ ポリシーを使用して制御することが可能です。
実際の方法については以下のリソースで詳しく説明されていますので、本記事と併せてご参照ください。

◆ グループ ポリシーを使用してリムーバブル デバイスのアクセスを制御する方法
https://blogs.technet.microsoft.com/askcorejp/2016/02/01/1245/

VMware 環境で発生する事象と原因
「リムーバブル ディスクの制御」に対するポリシーを有効にした影響として、VMware 環境の仮想マシンをご使用のお客様から次のようなお問い合わせをいただくことがございます。

例 1:
リムーバブル記憶域に対する監査ログが、ローカル ディスク (D: ドライブ) に対しても出力されてしまう

例 2:
仮想マシンのローカル ディスク (D: ドライブ) に対して書き込みができなくなった

これらの現象の発生原因は、VMware によって作成された仮想マシンの SCSI デバイスが Windows において構成によってはリムーバブル ディスクとして識別されるためです。
VMware によって作成される仮想マシンの SCSI コントローラーは、コンピューターが稼働したまま着脱可能なホット プラグに対応しております。
ホット プラグ可能なデバイスは Windows においてリムーバブル デバイスとして識別され、リムーバブル ディスクに対するグループ ポリシーが適応されます。
下図のように、ホット プラグ可能なデバイスとして認識されている状況が確認できます。
(Hyper-V の仮想マシンはホット プラグ不可のため、本事象は発生いたしません。)

なお、現在までにお問い合わせいただいている状況では、C ドライブに書き込みができなくなった報告はございません。
C ドライブは Windows の動作に必要なファイル群が保存されており、動作に必須なドライブですので、このポリシーの影響を受けません。

対応策
Windows としては、VMware から取得するハードウェアの情報を元にホット プラグと判断するため、対応策として、リムーバブル ディスクのアクセス制御を無効にしていただく以外の方法がございません。
お問い合わせでは、グループ ポリシーの「リムーバブル ディスク : 書き込みアクセス権の拒否」が有効であるために事象が発生している事例が多く寄せられています。
グループ ポリシー エディタ上の「コンピューターの構成 – 管理用テンプレート – システム – リムーバブル記憶域へのアクセス」から、「リムーバブル ディスク : 書き込みアクセス権の拒否」の設定状況をご確認ください。

また、VMware の仮想マシンにおいて、ホットプラグの機能を無効化する方法が VMware 社様から公開されています。
弊社検証環境で実施したところ、お問い合わせいただいた事象が改善したことが確認できておりますので、VMware の仮想マシンにおいてもリムーバブル ディスクのアクセス制御をされたい場合は、お客様環境にて以下をお試しいただければと思います。
お客様の仮想マシンの運用方法に合わせて、適切な方法をご採用ください。

ホット プラグを無効化する

VMware 環境の仮想マシンにおいて、以下のリソースを参考にホット プラグを無効化してください。
◆ ESXi 6.x、5.x および ESXi/ESX 4.x 仮想マシンで HotAdd/HotPlug 機能を無効にする (2079111)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2079111

※ VMware 社様におかれましても、本事象について以下のリソースに公開情報を掲載されておりますのでよろしければ併せてご確認ください。

◆ Windows のグループポリシーを構成すると、データドライブにアクセスできなくなる (2100405)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2100405

こんにちは Windows サポートの林です。

今回は Windows Server 2012 R2 におけるタスクスケジューラの「停止するまでの時間」設定の問題についてご案内致します。

問題概要

タスクスケジューラのタスク設定における “停止するまでの時間” 設定は [トリガー] タブおよび [設定] タブの 2 箇所設定する場所があります。しかし、トリガー設定にて “繰り返し間隔” (繰り返し実行設定) が設定されており、更に [設定] タブのみ “停止するまでの時間” が設定されている場合、この停止時間設定が期待通りに動作せず設定した時間を経過してもタスクが終了されない問題があります。この問題は Windows Server 2012 R2 で発生し、Windows Server 2016 以降では発生致しません。

原因

Windows Server 2012 R2 では UBPM(Unified Background Process Manager) とタスクエンジン(taskeng.exe) の 2 つのタスクスケジュールエンジンがございます(詳しくはこちらを参照)。本問題は誤って本来 UBPM から実行されるべきではないタスクが誤って実行されてしまうために発生します。具体的には繰り返し実行が設定されているタスクにて [設定] タブのみ “停止するまでの時間” 設定がされていると本事象は発生しますが Windows Server 2012 R2 では UBPM は繰り返し実行が設定されているタスクはサポートされておらず、本来は従来のタスクエンジン(taskeng.exe) からタスクが実行される必要がございます。しかし、内部ロジックの問題で誤って UBPM からタスクが実行されてしまい、UBPM は繰り返し実行設定をサポートしていないために設定通りに停止しない問題が発生致します。

対処方法

上記のように本件は [設定] および [トリガー] の 2 箇所の設定のうち、[設定] タブのみ “停止するまでの時間” が設定されている場合に発生します。対処は下記のように [トリガー] タブの “停止するまでの時間” を設定することでタスクエンジンからタスクが起動されるようになり、停止時間設定も期待通り動作するようになります。

こんにちは、日本マイクロソフトの Windows サポートチームです。

Windows Server 2016 Essentials の Anywhere Access のセットアップ時に、以下のエラーが発生し、完了できない場合の対処策についてご案内します。(Windows Server 2012 Essentials でも同様の症状である場合には本対処策が有効である可能性があります。)

この現象は、当インストールウィザードの処理過程でインストールされる Go Daddy 社の証明書ファイルが、何らかの要因でご利用のサーバーにルート証明機関 (および中間証明書機関) の証明書として登録されていない場合に、発生することが報告されています。

このため、本現象が発生した場合には、以下の手順で証明書ファイルのインストールを実施してください。

1. Internet Explorer で https://www.godaddy.com にアクセスします。
2. ブラウザ上部のアドレスバーの右側のカギのマークをクリックし、”証明書の表示” をクリックします。
3. [証明のパス] タブに切り替え、証明書のパスの 2 段目の “Go Daddy Secure Certificate Authority – G2” を選択して、[証明書の表示] をクリックします。
4. [証明書のインストール] ボタンをクリックします。
5. 証明書のインポート ウィザードが表示されますので、”ローカル コンピューター” を選択して [次へ] をクリックします。
6. “証明書の種類に基づいて…” が選択されている状態で、[次へ] をクリックして [完了] ボタンを押します。
7. 上記操作を実行後、スタートボタンを右クリックし、[ファイル名を指定して実行] をクリックします。
8. “mmc.exe” と入力して “OK” ボタンをクリックします。
9. コンソール1 画面の [ファイル] – [スナップインの追加と削除] をクリックします。
10. 左側の “利用できるスナップイン” の中から “証明書” をダブルクリックします。
11. “このスナップインで管理する証明書” では “サービス アカウント” を選択して “次へ” をクリックします。
12. ローカルコンピュータのまま “次へ” をクリックします。
13. サービスアカウントの一覧にある “Windows Server Essentials Management Service” を選択して “完了” ボタンをクリックします。
14. スナップインの追加と削除画面で “OK” ボタンをクリックします。
15. 証明書スナップインより、[中間証明機関] および [WseMgmtSvc\中間証明機関] の証明書に “Go Daddy Secure Certificate Authority – G2” がインストールされていることを確認します。※1
16. Anywhere Access セットアップを再度実行します。

※1 中間証明書は必須ではありません。
以下の証明書ファイルの [詳細] タブにて確認できる “機関情報アクセス” にて表示される URL へのアクセスが可能である場合には、中間証明書は不要となります。

こんにちは Windows サポートの林です。

今回は Windows Server 2012 R2 におけるタスクスケジューラの「停止するまでの時間」設定の問題についてご案内致します。

問題概要

タスクスケジューラのタスク設定における “停止するまでの時間” 設定は [トリガー] タブおよび [設定] タブの 2 箇所設定する場所があります。しかし、トリガー設定にて “繰り返し間隔” (繰り返し実行設定) が設定されており、更に [設定] タブのみ “停止するまでの時間” が設定されている場合、この停止時間設定が期待通りに動作せず設定した時間を経過してもタスクが終了されない問題があります。この問題は Windows Server 2012 R2 で発生し、Windows Server 2016 以降では発生致しません。

原因

Windows Server 2012 R2 では UBPM(Unified Background Process Manager) とタスクエンジン(taskeng.exe) の 2 つのタスクスケジュールエンジンがございます(詳しくはこちらを参照)。本問題は誤って本来 UBPM から実行されるべきではないタスクが誤って実行されてしまうために発生します。具体的には繰り返し実行が設定されているタスクにて [設定] タブのみ “停止するまでの時間” 設定がされていると本事象は発生しますが Windows Server 2012 R2 では UBPM は繰り返し実行が設定されているタスクはサポートされておらず、本来は従来のタスクエンジン(taskeng.exe) からタスクが実行される必要がございます。しかし、内部ロジックの問題で誤って UBPM からタスクが実行されてしまい、UBPM は繰り返し実行設定をサポートしていないために設定通りに停止しない問題が発生致します。

対処方法

上記のように本件は [設定] および [トリガー] の 2 箇所の設定のうち、[設定] タブのみ “停止するまでの時間” が設定されている場合に発生します。対処は下記のように [トリガー] タブの “停止するまでの時間” を設定することでタスクエンジンからタスクが起動されるようになり、停止時間設定も期待通り動作するようになります。

こんにちは、日本マイクロソフトの Windows サポートチームです。
今回は、Windows 10においてグループ ポリシーで高速スタートアップを無効にした場合の留意点をご紹介します。

<設定方法>
Windows 10 において高速スタートアップを無効にする方法は以下の 3 通りあります。

1. グループ ポリシー

以下のグループ ポリシーを「無効」に設定します。

———————–
[コンピューターの構成]
– [管理用テンプレート]
– [システム]
– [シャットダウン]
–  [高速スタートアップの使用を要求する]
———————–

2. レジストリ

以下のレジストリを 0 (無効) に設定します。

キー : HKLM\System\CurrentControlSet\Control\Session Manager\Power
名前 : HiberbootEnabled
種類 : REG_DWORD
値   : 0 = 無効、1 = 有効

3. 設定アプリ

UI上で以下の設定のチェックを外します。

[設定] – [システム] – [電源とスリープ] – [電源の追加設定] – [電源ボタンの動作の選択]
[シャットダウン設定] 内の [高速スタートアップを有効にする (推奨) ]

<留意点>
上記のうち、グループ ポリシーを設定した場合、管理者権限をもつユーザーは [現在利用可能でない設定を変更します] で権限昇格を行うと [高速スタートアップを有効にする (推奨) ] のUI画面がグレーアウトしなくなり、チェックボックスの変更が行えるようになります。

しかし、グループ ポリシーを [無効] に設定している場合、UI またはレジストリ値 (HiberbootEnabled) での設定状態に関わらず、グループ ポリシーの設定が最優先されますので高速スタートアップは無効となります。

実際の操作は以下の通りです。

[現在利用可能でない設定を変更します] で権限昇格を行う

[高速スタートアップを有効にする (推奨) ] のチェックボックスがグレーアウトしなくなる

なお、管理者権限を持たない一般ユーザーの場合は、 [高速スタートアップを有効にする (推奨) ] は

グレーアウトしたままとなります。