こんにちは。Windows プラットフォーム サポートの加藤です。
本日は、よくお問い合わせをのある Windows Server 2012 以降の OS でイベント ログ (アプリケーション) に、エラー Microsoft-Windows-Defrag ID:257 (0x8900002D) が記録される件についてご紹介します。

＜事象＞
==============================
以下の条件を満たす環境で、OS でイベント ログ (アプリケーション) に、エラー Microsoft-Windows-Defrag ID:257 (0x8900002D) が記録される事象が報告されています。

1. Windows Server 2012 以降の OS
2. シン プロビジョニング対応ディスクを使用している。
※ 仮想ディスクもシン プロビジョニング対応ディスクとして認識される場合があります。そのため、Azure 上の仮想マシンでも発生します。

記録されるイベント ログ詳細
----------------------------
ソース:           Microsoft-Windows-Defrag
イベント ID:       257
レベル:           エラー
説明:
エラーが発生したため、ボリューム ボリューム (D:) は最適化されませんでした: スラブが 8 MB 未満の場合は、スラブの統合とスラブの解析のどちらも実行されません。 (0x8900002D)
----------------------------

Windows Server 2012 環境では既定でデフラグ タスクがスケジュールされており本イベントは当該タスクが動作した際に記録されます。

＜原因＞
==============================
本イベントは KB2964429 (または、本修正を含むロールアップ) を適用した環境で、シン プロビジョニング対応ディスクにデフラグ (スラブ統合) を実行した際に、対象ボリュームのスラブ サイズが 8 MB 未満の場合に記録されるイベントです。
本イベントのメッセージは、デフラグ対象のボリュームのスラブ サイズが8 MB未満で構成されている場合には、ストレージ デバイスによる記憶域の管理が効率的に行われるため、デフラグ コマンドによるスラブの統合は不要であると判断し実行されなかったことを示します。
そのため、イベント ログへエラーとして記録されますが、上述の通り、対象ボリュームがシン プロビジョニング対応ディスクであり、かつスラブ サイズが8 MB 未満の場合には想定された動作となるため、システムに影響はなく無視いただいて問題はございません。

文書番号: 2964429
Storage Optimizer memory use increases when it runs on thin provisioned LUNs
https://support.microsoft.com/en-us/kb/2964429
//
Neither Slab Consolidation nor Slab Analysis will run if slabs are less than 8 MB.
This is expected behavior because slab consolidation and slab analysis has been disabled on thin provisioned LUNs that have a slab size of less than 8 MB.
Thin provisioned LUNs that have a smaller slab size manage space more efficiently, and the benefits of defragmenting them are not as great.
//

スラブとは、シン プロビジョニングディスクで使用される管理単位であり、ストレージはこのスラブ単位で、ディスクの割り当て、解放を行います。
例えばスラブのサイズが 256 MB であった場合、10 MB のデータが書き込まれると 256 MB 拡張されることになります。
スラブの統合は、スラブ上のデータを最適化し、空いたスラブを解放します。
スラブサイズが 8 MB 以下である場合、ストレージは効率よくスラブを管理できるため、最適化するメリットは大きくないため、スラブの統合は実施されません。

なお、当該のディスクがシン プロビジョニング対応ディスクであるかは、以下の GUI から確認できます。

1. [ファイル名を指定して実行] もしくは [コマンド プロンプト] で dfrgui.exe を実行します。
2. デフラグの GUI が表示されますので、[メディアの種類] を確認します。
3. [メディアの種類] が "仮想プロビジョニング対応ドライブ" と表示されていれば、シン プロビジョニング対応ディスクです。

＜回避策＞
=======================
定期メンテナンス タスクによるデフラグ実行時の当イベントの記録を抑止したい場合、登録されているデフラグ コマンドのオプションを変更する方法が有効でございます。

デフォルトでは、スラブ統合およびスラブのトリムが実施されるオプション "-k" が指定されております。オプション  "-l" (エル) はスラブのトリムのみを行うオプションです。よってこのオプションを  "-l" (エル) に変更していただくことで、スラブ サイズが 8 MB未満で構成されたシン プロビジョニング ボリュームでは実行が不要な、スラブ統合を実行しなくなるため、このイベントログも記録されなくなります。

以下にオプションを変更する手順をご案内いたしますので、対応をご検討ください。

デフラグのオプションを変更する
--------------------------
1. コントロール パネル > 管理ツール > タスク スケジューラを起動します。
   タスク スケジューラ ライブラリー > Microsoft > Windows > Defrag から ScheduledDefrag を右クリックし、プロパティを開きます。

2. [操作] タブで設定されているデフラグを選択し、編集を押下します。

3. 初期値 "-c -h -k -g -$" が設定されています。
   スラブ統合が実施されるオプション "-k" を削除し、オプション "-l" (エル) を追加し、OK で閉じます。
      
※ オプションの詳細については、コマンド プロンプトより Defrag /? にて確認可能です。

＜影響について＞
=======================
前述のとおり、対象ボリュームがシン プロビジョニング対応ディスクであり、かつスラブ サイズが 8 MB 未満の場合には想定された動作となるため、無視いただいて問題はございません。

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

こんにちは。Windows プラットフォーム サポートの加藤です。
本日は、Hyper-V ホストの起動時に記録される Microsoft-Windows-FailoverClustering ID:5120 (c00000be) と ID:5142 (1460) のエラーについてご紹介します。

＜事象＞
==============================
以下の条件を満たす環境で、再起動した Hyper-V ホストのイベント ログに Microsoft-Windows-FailoverClustering ID:5120 (c00000be) と ID:5142 (1460) のエラーが記録される事象が報告されております。

1. Windows Server 2012 以降の Hyper-V フェールオーバー クラスター 環境
2. システムで IPv6 が無効になっている
3. "Microsoft Failover Cluster Virtual Adapter" 以外に APIPA (169.254.0.0/16) の IP アドレスが割り振られた NIC が存在している

記録されるイベント
---------------------------------
ソース:           Microsoft-Windows-FailoverClustering
イベント ID:       5120
タスクのカテゴリ:      クラスターの共有ボリューム
レベル:           エラー
説明:
クラスターの共有ボリューム 'Volume3' ('クラスター ディスク 1') は、'(c00000be)' が原因で一時停止状態になりました。ボリュームへのパスが再確立されるまで、すべての I/O は一時的にキューに登録されます。
---------------------------------

---------------------------------
ソース:           Microsoft-Windows-FailoverClustering
イベント ID:       5142
タスクのカテゴリ:      クラスターの共有ボリューム
レベル:           エラー
説明:
エラー '(1460)' が発生したため、クラスターの共有ボリューム 'Volume3' ('クラスター ディスク 1') にこのクラスター ノードからアクセスできなくなりました。このノードから記憶装置への接続およびネットワーク接続のトラブルシューティングを行ってください。
---------------------------------

＜原因＞
==============================
上記イベント ID:5120 に記録されたエラー コード status c00000be  (STATUS_BAD_NETWORK_PATH) は、SMB の通信が失敗した場合に記録されます。
フェールオーバー クラスターでは CSV へのアクセスのために、CSV のコーディネーター ノードと非コーディネーター ノードが SMB の通信をします。
これは、NTFS ファイルシステムの管理情報であるメタデータの操作が、コーディネーター ノードのみしか許されていないためです。
そのため非コーディネーター ノードは SMB 通信を経由してコーディネーター ノードにメタデータの操作を依頼します。

さらにこの SMB 通信では、クラスターの仮想ネットワークアダプターである "Microsoft Failover Cluster Virtual Adapter" が使用されます。
この "Microsoft Failover Cluster Virtual Adapter" に割り振られる IP アドレスは、システムで IPv6 が有効の場合には、リンク ローカルアドレス (FE80::/10) が使用され、IPv6 が無効の場合には APIPA (169.254.0.0/16) が使用されます。

※ "Microsoft Failover Cluster Virtual Adapter" とはクラスターの内部通信で使用される仮想ネットワークアダプターで、クラスターを構成すると自動で作成されます。

// Microsoft Failover Cluster Virtual Adapter
--------------------------------
Tunnel adapter ローカル エリア接続* 2:

   接続固有の DNS サフィックス . . . . .:
   説明. . . . . . . . . . . . . . . . .: Microsoft Failover Cluster Virtual Adapter
   物理アドレス. . . . . . . . . . . . .: 02-A4-56-06-2F-8B
   DHCP 有効 . . . . . . . . . . . . . .: いいえ
   自動構成有効. . . . . . . . . . . . .: はい
   IPv4 アドレス . . . . . . . . . . . .: 169.254.2.48(優先)
   サブネット マスク . . . . . . . . . .: 255.255.0.0
   デフォルト ゲートウェイ . . . . . . .:
   NetBIOS over TCP/IP . . . . . . . . .: 有効
--------------------------------

そのため、システムで IPv6 が無効の場合には、ノードの起動時に、CSV コーディネーター ノードの "Microsoft Failover Cluster Virtual Adapter" に割り振られたAPIPA の IP アドレスに接続を試みますが、"Microsoft Failover Cluster Virtual Adapter" 以外に APIPA の IP アドレスを持っている NIC があると、ルーティングテーブル上に、同じルート (169.254.0.0/16) が 2 つ存在してしまい、その結果、"Microsoft Failover Cluster Virtual Adapter" ではない別の NIC を経由して通信をするため、status c00000be  (STATUS_BAD_NETWORK_PATH) で失敗します。

// APIPA (169.254.0.0/16) のIP アドレスが割り振られた NIC
--------------------------------
イーサネット アダプター vEthernet

   接続固有の DNS サフィックス . . . . .:
   説明. . . . . . . . . . . . . . . . .: Hyper-V 仮想イーサネット アダプター #8
   物理アドレス. . . . . . . . . . . . .: 00-15-5D-21-C9-17
   DHCP 有効 . . . . . . . . . . . . . .: はい
   自動構成有効. . . . . . . . . . . . .: はい
   自動構成 IPv4 アドレス. . . . . . . .: 169.254.43.71(優先)
   サブネット マスク . . . . . . . . . .: 255.255.0.0
  デフォルト ゲートウェイ . . . . . . .:
   NetBIOS over TCP/IP . . . . . . . . .: 有効
--------------------------------

// 重複したルート (169.254.0.0/16)
--------------------------------
アクティブ ルート:
ネットワーク宛先        ネットマスク          ゲートウェイ       インターフェイス  メトリック
      169.254.0.0      255.255.0.0            リンク上     169.254.43.71    261
      169.254.0.0      255.255.0.0            リンク上     169.254.2.48    261
--------------------------------

＜回避策＞
==============================
本事象はクラスターの仮想ネットワークアダプター以外に APIPA のアドレスを持っている NIC が存在していることが原因であるため、クラスターの仮想ネットワークアダプター以外で APIPA のアドレスが割り当てられている NIC に静的に IP アドレスを付与していただくか、当該 NIC を無効にします。
なお、よく見られる誤った構成は、Hyper-V ホストとゲスト間の通信が不要であるにも関わらず、Hyper-V の仮想スイッチの種類を [内部] に設定してしまう場合です。
仮想スイッチの種類で [内部] を選択した場合、ホストとゲストが通信できるように Hyper-V の仮想 NIC が作成されます。
通常はこの Hyper-V の仮想 NIC に IP アドレスを割り当てて、ホストとゲストと通信できるように構成します。
この仮想 NIC に IP アドレスを割り当てなければ、APIPA (169.254.0.0/16) が割り当てられるため、本事象が発生します。
そのため、ホストとゲスト間の通信が不要であれば、仮想スイッチの種類を [プライベート] に変更をお願いします。
※ [プライベート] を選択した場合には、ゲスト内の通信のみとなりますため、Hyper-V の仮想 NIC は作成されません。

こんにちは、Windows Platform サポートの永岡です。

最近、Windows Server 2012 R2 の FSRM (ファイル サーバー リソース マネージャー) を
使用した環境で "オプションの構成" を利用した記憶域レポートの作成を検討しているものの、
"オプションの構成" で設定したパラメータが正しく反映されないというお問い合わせを
いただきました。

今回は、そのような場合の解決策について、一般的な記憶域レポートのお話を交えながら
ご紹介します。

 一般的に FSRM を使用した記憶域のレポートの作成方法には、大きく分けて
以下 2 種類の方法があります。

============

(1) [ファイル サーバー リソース マネージャー] の [記憶域レポートの管理]
     からスケジュール設定を行い、定期的にレポートを作成する。

 
(2) クォータ設定等 (対象フォルダやドライブの使用容量監視) を行い、閾値や
     設定値を超過した時点で記憶域レポートを作成する。

 
(※各手順の画面キャプチャにつきましては、後述します)

============

上記 (1) の場合には以下の画面キャプチャの通り、記憶域レポートのスケジュール設定を
行う事で、記憶域レポートに含めたい各パラメータを個別に設定することが可能です。

しかし、上記 (2) の場合には閾値超過時点において、どのパラメータを使用してレポートを
作成するかという選択しかできず、各パラメータのチューニングについては、別途設定を
実施する必要があります (別途設定しない場合には、各パラメータは規定値が適用されます)。

■[記憶域レポートの管理]を使用した定期的なレポート作成  (上記 (1) の場合)
========================================================================
A)  [記憶域レポートの管理] から [新しいレポートのタスク スケジュール] を選択します。

 B)  [設定] から記憶域レポートに含めたい各パラメータを選択して、[パラメータの編集] から
     各パラメータをカスタマイズします。

 C)  ここでは、[大きいサイズのファイル] パラメータの [最小ファイルのサイズ] を
    設定しています。

 もちろん、クォータ設定等を実施した際の閾値、および設定超過時に作成するレポートについても
上記のようにカスタマイズされた各パラメータを使用した記憶域レポートを作成することが可能です。
そのために設定する項目が "オプションの構成" となります。
 
この "オプションの構成" は、記憶域レポートの各パラメータにおける規定値を変更する
オプションとなっており、上記 (2) などの作成方法を選択した場合に、各パラメータを
意図した値でレポートさせるための設定となっています。(以下、"オプションの構成" 設定画面です)

■[オプションの構成]を使用した記憶域レポートのパラメータ設定 (上記 (2) の場合)
===============================================================================
A)  [ファイル サーバー リソース マネージャー] から [オプションの構成] を開きます。

 B)  [記憶域レポート] タブから記憶域レポートに含めたいパラメータを選択して、
    [パラメータの編集] から各パラメータの値を設定します。

しかし、上記 GUI から "オプションの構成" から各パラメータの変更を実施した場合
正しく設定が反映されないず、既定値に戻ってしまう事があります。(設定後、すぐに規定値に戻ってしまう)

今回は、こんな場面に遭遇した際に有効である PowerShell を用いた対応策についてご紹介します。

=============================
■ PowerShell を用いた対応策
=============================
"オプションの構成" については GUI だけではなく、PowerShell からも
設定可能となっており、この場合には上記のような設定が規定値に戻ってしまう
事象は発生しません。

"オプションの構成" にて記憶域レポートの各パラメータを構成する場合には、
以下の手順に沿って PowerShell を利用して "オプションの構成" をご設定ください。

手順
-----

1) ファイル サーバー リソース マネージャー (FSRM コンソール) を
   開いている場合は、一旦閉じます。

 
2) PowerShell を管理者権限にて開き、以下のコマンドを実行して
   現在の "オプションの構成" を確認します。
 
> Get-FsrmSetting
 
3) 今回はサンプルとして以下のコマンドを実行して、レポート時の "大きいサイズのファイル"
   の "最小ファイル サイズ" パラメータを 300 MB へ設定します。

> Set-FsrmSetting -ReportLargeFileMinimum 314572800
 
※レポートに反映させる "最小ファイル サイズ" はバイト表記となります。
  上記は 300 MB を設定しております。

4) 手順 1) のコマンドを再度実行して、設定が反映されている事を
   確認します。
 

※そのほかの設定についても PowerShell を使用して "オプションの構成" を
  設定できます。本設定以降は GUI にて各パラメータが変更されている事を
  ご確認いただけます。

-参考情報
Get-FsrmSetting
https://technet.microsoft.com/en-us/library/jj900603(v=wps.630).aspx
 
Set-FsrmSetting
https://technet.microsoft.com/en-us/library/jj900644(v=wps.630).aspx

========

もし、FSRM を使用してカスタマイズされた記憶域レポートを作成する場合には、上記の
"オプションの構成" の設定方法をお試しいただき、日々の運用にご活用いただければと
思います。

Windows Platform サポートの永野です。

この記事では、"Power Efficiency Diagnostics" タスクによって、CPU 使用率が上昇する事象についてご紹介いたします。

Windows Server 2008 R2 には、電源管理に関する Power Efficiency Diagnostics タスクがタスク スケジューラーに登録されております。このタスクは、内部的に powercfg.exe を呼び出して、電源管理の分析を行うタスクとなります。このタスクは、デフォルトで 14 日に 1 回実行されます。システムの構成によっては、このタスクの実行時に powercfg.exe が CPU 負荷を発生させるという報告が確認できております。

CPU 高負荷が発生しますと、システムのスローダウンやクラスターのフェールオーバーなどが発生する可能性がございます。もし、CPU 高負荷が発生する環境がございましたら、タスク マネージャーなどで CPU を使用しているプロセスをご確認ください。そして、powercfg.exe が負荷を発生させていることが確認できましたら、以下の手順を利用してタスクを無効化することで現象が改善するかどうかご確認ください。

1. タスク スケジューラーを起動します。
2. 左ペインから [タスク スケジューラ ライブラリ] - [Microsoft] - [Windows]  - [Power Efficiency Diagnostics] を選択します。
3. 中央ペインより [AnalyzeSystem] を右クリックし、[無効] を選択します。

上記変更を実行しても、電源管理の分析タスクが停止するのみとなりますので、
システムの動作には影響ございません。

// 参考情報
Guided Help: Get a detailed Power Efficiency Diagnostics Report for your computer in Windows 7
https://support.microsoft.com/en-us/kb/976034
https://support.microsoft.com/ja-jp/kb/976034 (日本語機械翻訳)

こんにちは。Windows プラットフォーム サポートの加藤です。

今回はクラスター グループに関する注意事項についてご紹介します。

1. クラスター グループとは

クラスター グループはクラスター コア リソースと呼ばれるクラスターの構成を管理するための重要なリソースを含むグループです。
クラスター コア リソースとは、クラスター名を表すクラスター名オブジェクト (CNO) 、クラスター情報へのアクセスするための IP アドレス、クォーラム構成用のディスク監視の 3 つのリソースを指します。

クラスター グループはクラスター自身の管理をする特別なグループのため、通常のクラスター化されたアプリケーションのグループとは役割が異なります。
そのため、Windows Server 2003 以前では、ほかのクラスター化されたアプリケーションと同じツリーの配下に配置され GUI から容易に変更が可能でしたが、Windows Server 2008 以降は、GUI のクラスターの概要のペインに移動され、操作が制限されるようになりました。
※ Windows Server 2008 / 2008 R2 では GUI からのクラスター グループの移動やリソースの追加、設定変更ができなくなりましたが、Windows Server 2012 以降では移動のみ GUI から実施可能になりました。

クラスター コア リソースを含むクラスター グループのデフォルトのグループ名は Windows Server 2008 R2 までは "Cluster Group" で Windows Server 2012 以降は "クラスター グループ" です。
以下ご紹介のコマンド (コマンドレット) でクラスター グループを構成するリソースのリストを表示できますので、クラスター コア リソースのグループ名を確認してください。

　□ Windows Server 2008 R2 以前の OS
  クラスターを構成するノードでコマンドプロンプトで以下コマンドを実行
       > cluster group
  
　□ Windows Server 2012 以降の OS
  クラスターを構成するノードでPowerShell で以下のコマンドレットを実行
       > Get-ClusterGroup

2. クラスター グループの設定変更について

このクラスター グループに他のアプリケーションを追加したり、クラスター グループやクラスター コア リソースの設定値 (依存関係や優先所有者など) を既定の設定から変更することは推奨されておりません。

クラスター グループについては、以下のような文書が公開されております。

  文書番号: 168948
  [タイトル] クラスタ グループについての情報
  https://support.microsoft.com/ja-jp/kb/168948

  --- 抜粋 ---
  Cluster Group は、クラスタ管理のみに関連し、コア リソースと見なされるリソースのみを含みます。他のリソースをグループに追加すると、そのクラスタの管理能力が低下することがあります。
  ------------

上記の技術情報 (KB) は対象が Windows Server 2003 とありますが、Windows Server 2008 以降においてもクラスター グループに他のアプリケーションを追加したり、クラスター グループやクラスター コア リソースの設定値を既定の設定から変更することは非推奨となります。
以下、クラスター　グループに対しての設定変更で起き得る問題について紹介させていただきます。

1. クラスター グループに新たにリソースを追加した際には、新たに追加したリソースの影響によって予期せぬフェールオーバーが発生したり、フェールオーバーが失敗したりする等、想定されていない挙動を示すことがあり、クラスター自身の管理能力が低下する可能性がございます。

2. クラスター グループの設定値を既定値から変更した場合につきましても、想定されない挙動を示す場合がございます。過去、いただきましたお問い合わせでは、クラスター グループに対して優先所有者が設定されていたため、優先所有者が設定されたクラスター ノードが起動してくるまでクラスター サービスが開始できない、という事象が発生していたケースもございました。

3. また、クラスター コア リソースのひとつであるクォーラム構成で使用するディスク監視 (Witness Disk) につきましては、ディスク監視以外の用途で使用してディスク容量がひっ迫した場合にクラスターの管理情報が失われ、クラスターが正しく機能しなくなる可能性があります。

上述のように、クラスターの予期せぬ挙動が発生し、場合によっては業務継続に影響が出る可能性がございますので、クラスター グループおよびクラスター グループに含まれるクラスター コア リソースの設定変更及び推奨設定以外の設定につきましては実施しないことを推奨しております。

<参考情報>
 [タイトル] クラスタ グループについての情報
 https://support.microsoft.com/ja-jp/kb/168948
 [タイトル] Windows Server 2012 フェールオーバー クラスターでクォーラムを構成および管理する
https://technet.microsoft.com/ja-jp/library/JJ612870.aspx#BKMK_witness

こんにちは。Windows プラットフォーム サポートの横山です。

先日、以下の弊社ブログにて案内させていただいておりますが、Azure Backup エージェント 2.0.8715.0 より Azure Backup の容量制限が 1700 GB から 54400 GB へ変更されました。

Azure Backup enables backup of large volumes, VMs, databases and more
https://azure.microsoft.com/ja-jp/blog/azure-backup-enables-backup-of-large-volumes-vms-databases-and-more/

今回は、本容量制限についてお伝えいたします。

まず、今回の 54400 GB への変更は VHDX の機能を利用したものとなります。VHD の容量制限が 2 TB であるのに対し、VHDX は 64 TB までとなっております。Azure Backup は、バックアップ データの他にも管理用のデータを保存するため、バックアップ データに利用可能な制限を 65536 GB (64 TB) 中 54400 GB までとしております。

VHDX は Windows Server 2012 以降に実装された機能であるため、それ以前の OS では VHDX を扱うことができません。そのため、以下の OS では 2.0.8715.0 以降のバージョンの Azure Backup エージェントを利用した場合においても VHD が利用されるため、Azure Backup によるバックアップ データは 1700 GB までとなります。

• Windows 7
• Windows Server 2008
• Windows Server 2008 R2

注: Azure Backup エージェントをこれらの OS で利用した場合、ウィザードの表記上は 54400 GB となりますが、実際の制限は 1700 GB ですのでご注意ください。本表記については弊社開発部署へフィードバックしており、2015 年中に改善される予定です。

こんにちは。Windows プラットフォーム サポートの加藤です。

最近、Hyper-V クラスター環境の仮想マシンで "保護されているネットワーク" に接続された物理 NIC の LAN ケーブルを抜線した際に、ライブ マイグレーションが失敗するというお問い合わせをいただきます。

今回のブログでは、この事象の原因と回避策についてご紹介します。

1. 事象説明
まず最初に、 "保護されているネットワーク" の正常性検知について説明します。
これは Windows Server 2012 R2 からのフェールオーバー クラスタリングの新機能で、Hyper-V ホスト クラスターで動作している仮想マシンの仮想ネットワーク アダプターへの設定項目のひとつです。この "保護されているネットワーク" の設定がされている仮想マシンの仮想ネットワーク アダプターで切断が検出された場合、その仮想マシンは別の Hyper-V ホストに移動されます。"保護されているネットワーク" の設定は仮想マシンの設定ウインドウにて、対象の "ネットワーク アダプター" の［高度な機能］を展開して設定することができ、既定では有効化されています。

  Windows Server? 2012 R2 フェールオーバー クラスタリング構築・運用・管理ガイド
  「4. Windows Server 2012 R2 における改善や強化」項
  http://download.microsoft.com/download/0/7/B/07BE7A3C-07B9-4173-B251-6865ADA98E5D/WS2012R2_MSFC_ConfigGuide_v1.1.docx

お問い合わせでは、この設定をされている仮想ネットワーク アダプターに接続されている物理 NIC の LAN ケーブルを抜線すると、ライブ マイグレーションが開始されますが、以下のようなログが記録され失敗してしまう、という事象が報告されております。

2. 発生条件と原因
このライブ マイグレーションが失敗する事象は、以下の条件を満たした環境で発生いたします。
  1. 抜線した LAN ケーブルが接続された物理 NIC が 仮想スイッチと Hyper-V ホストで共有されていること
  2. その物理 NIC が Hyper-V ホストとドメイン コントローラー (DC) が通信するための唯一のネットワーク経路であること

なぜ、上記 2 の条件により、この事象が発生するかというと、ライブ マイグレーション実行には、Hyper-V ホストと DC の通信が必須であるからです。仮想マシンのライブ マイグレーション実行時には、Hyper-V 仮想マシン管理サービスは DC との認証により移行先の Hyper-V ホストとのセッションを確立し、データの移行を開始します。よって、Hyper-V ホストと DC との接続が切断されている状態の場合、Hyper-V ホストは仮想マシンのライブ マイグレーションに失敗します。

つまり、仮想マシンの 【"保護されているネットワーク" が接続されている物理 NIC】 と 【Hyper-V ホストが DC との通信に使用している物理 NIC】 が同一である場合、その物理 NICに接続された LAN ケーブルを抜線すると、「"保護されているネットワーク" の正常性検知により障害が検知され、ライブ マイグレーションが開始されますが、同時に Hyper-V ホストと DC との接続も切断されるため、移行先 Hyper-V ホストとのセッションが確立できずにライブ マイグレーションが失敗する」事象が発生することになります。

3．回避策
仮想マシンの "保護されているネットワーク" の設定がされた仮想ネットワーク アダプターが接続する仮想スイッチの物理 NIC は Hyper-V ホストが DC との通信をするための唯一のネットワーク経路となる物理 NIC と共有する設計にしないようにお願いいたします。

仮想スイッチに接続された物理 NIC が Hyper-V ホストと共有する設定になっているかどうかは、Hyper-V の仮想スイッチ マネージャーの [仮想スイッチのプロパティ] 画面にて、[接続の種類] - [外部ネットワーク] で "管理オペレーティング システムにこのネットワーク アダプターの共有を許可する" のチェック ボックスで確認できます。

また、Hyper-V ホストが DC との通信に使用できる物理 NIC が複数ある場合は、"保護されているネットワーク" が接続されている仮想スイッチとの共有も可能です。通常は仮想スイッチと共有している物理 NIC 経由で DC との通信を行い、障害時にのみ別のネットワーク経路の物理 NIC で通信を行いたい場合は、スタティック ルーティングにメトリックを設定することで実現可能です。

4. まとめ
Windows Server 2012 R2 からの新機能 "保護されているネットワーク" の設定に関するテストで想定された動作にならない場合、上記のように "LAN の抜線" により発生した Hyper-V ホストへ影響の可能性がないかをご確認いただけますようお願いいたします。

このブログがみなさまのお役に立てば幸いです。

こんにちは。Windows プラットフォーム サポートの鎌滝です。

今回のブログでは、クラスター環境でノードとドメイン コントローラー (DC) が持つ認証の情報が合わなくなってしまった場合に、OS として復旧が必要な作業についてご紹介します。

このような状態が発生するのは、チェックポイント (旧スナップショット) の適用や過去に取得したバックアップからリストアなど、クラスター ノードや DC が過去もしくは別の時刻の状態になるような操作を行った場合あるいはノードをしばらくシャットダウンしていた場合などです。

また、今回対象とするのは、ドメインの変更を伴わない作業です。バックアップを取得した環境と、リストアをした環境が別のドメイン環境である場合は、この作業ではクラスターを正常稼働させることができません。Windows Server 2008 以降のクラスターのドメインの移動は残念ながらマイクロソフトではサポートしておりません。

  How to move a Windows Server cluster from one domain to another
  https://support.microsoft.com/en-us/kb/269196
  --- 抜粋 ---
  Because of an increased dependence on Active Directory Domain Services, Microsoft does not support moving an already installed and configured Windows Server 2008, Windows Server 2008 R2 and Windows Server 2012 failover cluster from one domain to another.
  ------------

クラスターが稼働するためには、クラスターを構成するノードが Active Directory (AD) ドメインに所属することが前提となります。クラスター ノードとクラスター ノードが所属するドメインのドメイン コントローラー (DC) が長期間通信できていないような状態になった場合、その間にパスワードの変更期限超過してしまうことにより、ノードと DC の間のパスワードなどの認証情報をもつセキュア チャネルに破損が生じることがあります。
クラスター環境の場合、このような破損が起こりうるセキュア チャネルとは、以下の 2 箇所が該当します。
  1. クラスター ノード自身の DC とのセキュア チャネル
  2. クラスターの名前を表すクラスター名オブジェクト (CNO) のコンピューター アカウントの DC とのセキュア チャネル

1 については一般的な AD 環境とのセキュア チャネルが破損した場合の復旧手順と同様です。詳細については以下のブログをご一読ください。下記の「3. セキュア チャネルが破損した時の対処方法」項にドメインの再参加の手順もご案内しておりますので、必要に応じてご実施ください。クラスター環境はドメイン環境から離脱した場合に多くのエラー ログを出力しますが、一時的にクラスター サービスのスタートアップ設定を無効にすることでエラー ログを減らすことができます。

  ドメインにログオンできない ～ セキュア チャネルの破損 ～
  http://blogs.technet.com/b/jpntsblog/archive/2009/06/05/3250724.aspx

ドメインへの再参加でノード自身のセキュア チャネルの破損がクラスターに参加する全ノードで解消されたのち、2 の CNO のセキュア チャネルの破損の解消を実施します。
この事象が発生しているかどうかは、フェールオーバー クラスター マネージャーの画面から、[クラスター コア リソース] の CNO の状態から確認できます。クラスター コア リソースのクラスター名の [名前: <クラスター名>] が "オフライン" もしくは "失敗" 状態になっている場合、CNO のセキュア チャネルが破損している可能性があります。
また、その場合、以下のような イベント ログが記録されている場合もございます。

AD 環境にて管理される CNO のコンピューター オブジェクトの認証に必要なパスワード情報は、通常のアカウントと同様、2 世代保存されております。
コンピューター アカウントのパスワードの更新間隔はグループ ポリシーでの設定値に依存しますが、クラスターが利用するオブジェクトについては、更新が完了する確度をあげるため、その 75 % で更新されるという動作となっております。この動作は AD 環境のバージョンには依存しません。
グループ ポリシーは DefaultDomainPolicy では未定義が規定であり、その場合ローカル ポリシーの値が反映されますが、その既定値は 30 日と定義されているため、CNO ではその 75 % の 22 日が更新間隔の規定値になります。

よって、この更新をまたぐタイミングの時刻のずれが発生すると、セキュア チャネルの破損が発生します。その場合、クラスターから [Active Directory オブジェクトの修復] という作業が必要になります。手順については、後述いたします。

  [参考情報]
  Understanding the Repair Active Directory Object Recovery Action
  http://blogs.msdn.com/b/clustering/archive/2013/12/13/9067582.aspx

この作業は、セキュア チャネルが破損していない状態で実施いただいても、問題はございません。よって、クラスター コア リソースのクラスター名がオンラインにならない場合は、当作業をお試しいただくことが有効な方法のひとつとなります。

========================================================================
[Active Directory オブジェクトの修復] の手順
   (クラスターに参加するノード 1 台から実施)
========================================================================
1. [フェールオーバー クラスター マネージャー] 画面を開きます。

2. 左ペインからツリーを展開し、クラスター名を選択します。

3. 中央のペインから [クラスター コア リソース] を展開、表示します。

4. クラスター名リソースの現在の状態が "オフライン" もしくは "失敗" 状態になっていることを確認します。
"オフライン" もしくは "失敗" 状態になっていない場合、クラスター名リソースの右クリック メニューから [その他のアクション] - [このリソースのエラーをシミュレーションする] を選択し、エラーを発生させます。
   この操作を繰り返し実施し、クラスタ名 リソースを “失敗” のステータスにします。
  
5. クラスター名リソースに対して、右クリック メニューから [その他のアクション] - [Active Directory オブジェクトの修復] を選択します。
    (Windows Server 2012 以降ではメニュー名が [他のアクション] - [修復]  に変更されております。)
   修復が正常に行われた場合にはクラスター名リソースの状態が “オンライン” となります。
========================================================================

以上の手順にて、クラスター環境に時刻変化が起きたことによるセキュア チャネル破損に対する OS として必要な復旧作業は完了です。

クラスター環境にチェックポイントの適用、バックアップ＆リストアをしたときや久しぶりにクラスター環境を起動したとき、クラスター コア リソースがオンラインにならない。そんなとき、本ブログが少しでも皆様のお役に立てば幸いです。

こんにちは、Windows サポートチームです。今回は Windows 8.1 で発生するディスプレイの識別番号の問題とその回避方法についてご紹介したいと思います。

現象：

 2 つ以上の同型のモニターを接続した Windows 8.1 環境に 2014 年 11 月のロールアップ更新プログラムを適用すると、ディスプレイの識別番号が本来とは異なるディスプレイ上に表示されてしまう場合があります。

以下の画像で識別番号（大きな白い数字）が表示されているのをご覧頂けるかと思いますが、左側のディスプレイがメインで識別番号は本来 1 と表示されるべきですが、誤って 2 と表示されています。

再現方法：

1. Windows 8.1 のコンピューターに、同じ型のモニターを 2 台以上接続します。

2. 2014年11月のロールアップ更新プログラム (KB3000850) をインストールします。

Windows RT 8.1、Windows 8.1 および Windows Server 2012 R2 用の 2014 年 11 月付け更新プログラムのロールアップ

https://support.microsoft.com/ja-jp/kb/3000850

3. コントロールパネルから [ディスプレイ]-[画面の解像度] を開きます。

   または、デスクトップ上を右クリックして [画面の解像度] を選択します。

4. "ディスプレイ表示の変更" の [識別] ボタンをクリックします。

5. ディスプレイ上に表示された番号が、[ディスプレイ表示の変更] に表示された画面アイコンの番号と異なる場合があります。

回避方法：

この現象が発生する場合には、一旦ディスプレイの信号ケーブルをコンピューターから取り外して、別のポートに接続し直すことで識別番号も正しく表示されるようになります。

なお、この問題は識別番号の表示上の問題のみであり、その他のシステムやアプリケーションへの影響はありません。

また、今のところ修正の予定はありませんが、Windows 10 では発生しませんので、是非 Windows 10 へのアップグレードもご検討頂ければと思います。

こんにちは。Windows プラットフォーム サポートの松岡です。

今回は NTFS アクセス権と NFS アクセス時のアクセス権の動作についてご紹介します。

Windows サーバー上に作成された NFS 共有フォルダに UNIX クライアントからアクセスしファイルを作成した際に UNIX クライアントからは該当ユーザーにフル コントロールのアクセス権が付与されていることが確認できます。
しかしながら、該当ファイルを Windows サーバー上で削除しようとするとアクセス拒否が発生し削除できない場合があります。
この現象について以下のように検証を行いました。

- Windows サーバー: ユーザー "user1" とグループ "grp1" を作成し、grp1 に user1 を追加しプライマリー グループに設定する。
- Unix クライアント: ユーザー "user1" とグループ "grp1" を作成する。
- 作成したユーザーとグループのマッピングを行い、Windows サーバー上に NFS 共有フォルダ (NTFS-NFS) を作成する。

この際、以下のようなアクセス権が設定されたと仮定します。

> Cacles C:\NTFS-NFS
  C:\NTFS-NFS<machine_name>\grp1:(OI)(CI)(特殊なアクセス :)

                                                      READ_CONTROL

                                                      WRITE_DAC

                                                      WRITE_OWNER

                                                      SYNCHRONIZE

                                                      FILE_GENERIC_READ

                                                      FILE_GENERIC_WRITE

                                                      FILE_GENERIC_EXECUTE

                                                      FILE_READ_DATA

                                                      FILE_WRITE_DATA

                                                      FILE_APPEND_DATA

                                                      FILE_READ_EA

                                                      FILE_WRITE_EA

                                                      FILE_EXECUTE

                                                      FILE_READ_ATTRIBUTES

                                                      FILE_WRITE_ATTRIBUTES

                               NT AUTHORITY\SYSTEM:(OI)(CI)(ID)F

                               BUILTIN\Administrators:(OI)(CI)(ID)F

grp1 のアクセス権は以下の画像のハイライト部分以外はすべて許可されています。

※画像の C:\NTFS は C:\NTFS-NFS に読み替えてください。

※ 上記設定により user1 のアクセス権は grp1 に設定されたアクセス権を基に継承されます。

UNIX クライアントから以下の操作を実施します。

- NFS 共有を root 権限でマウントします。
- user1 でログオンします。( UNIX クライアント上の user1 は windows サーバー上の user1 にマップされています)
- NFS 共有配下に "user1_unix" フォルダを作成します。

この際に "user1_unix" フォルダを Windows 上で確認すると NTFS アクセス権は継承されておりません。
(同様に Windows サーバー上でフォルダを作成した場合には NFS アクセス権が継承されます。)

※画像の /TestNFS/ は /user1_unix/に読み替えてください。

UNIX クライアントからは以下のアクセス権が設定されていることを確認できます。

- user1 が "user1_unix" のオーナーに設定されている。
- user1 には RWX のアクセス権が設定されている。
- grp1 には親フォルダと同様のアクセス権が設定されている。

上述の通り、UNX クライアント側からは RWX が設定されており、且つ、オーナーにもかかわらず "user1_unix" フォルダを削除することができません。
ネットワーク キャプチャを取得してみると、rmdir コールが正しい UID、GID で送られていますが "err_access" (アクセス拒否) が返されています。

//Access call

//Access reply call

//delete call (RMDIR)

この時 Windows サーバー上で User1 でログオンし、NFS 共有配下にフォルダを作成すると user1 が当該フォルダのオーナーであり、フル コントロールの NTFS アクセス権が設定されていることが確認できます。 また当該フォルダの削除も行えます。

------------------------

まとめ

UNIX クライアントからファイル/フォルダを削除するには以下の条件を満たしている必要があります。

1. grp1 に対して親フォルダ (nfstest) に "サブフォルダーとファイルの削除" のアクセス権が設定されている。
2. user1 に対して親フォルダ (nfstest) に "削除" のアクセス権が設定されている。

検証の結果からは以下ののことがわかりました。

- "サブフォルダーとファイルの削除" のアクセス権を削除すると、UNIX クライアント側からは RWX のアクセス権が設定されていても対象ファイル/フォルダを削除することができない。
- Windows 側では、NFS 共有配下にフォルダを作成すると、該当ユーザーがオーナーに設定され、フル コントロールの NTFS アクセス権が設定されるため、対象ファイル/フォルダの削除が行える。

このように NFS 経由の操作では UNIX 標準に準拠するため NTFS アクセス権の継承は無視されます。
そのため、NFS 共有上のファイル/フォルダに UNIX と Windows の両方のユーザーからアクセスする場合には KeepInheritance を設定することをお勧めします。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ServerforNFS\CurrentVersion\Mapping\KeepInheritance

既定では 0 が設定されており、NTFS アクセス権の継承は行われません。
こちらの値を 1 に設定することで NTFS アクセス権の継承が行われるようになります。

※ この記事は以下の英語ブログを基に作成しました。
How NFS access works over NTFS permissions
 http://blogs.technet.com/b/sfu/archive/2009/08/27/how-nfs-access-works-over-ntfs-permissions.aspx

こんにちは。Windows プラットフォーム サポートの横山です。

今回は Microsoft Azure Backup のコンソールよりバックアップのスケジュールの登録に失敗する事象についてお伝えいたします。

バックアップのスケジュールを設定する際に、マウスではなくキーボードを利用して時間の登録を行うと CBSnapIn.dll 内部で例外が発生しスケジュールの登録が正常に行えません。
本エラーはキーボードを利用した際にプルダウン メニューのインデックス情報と実際に設定されている値の間で不整合が生じることに起因しています。
Microsoft Azure Backup ではキーボードによる操作を想定していないため、大変ご不便ご面倒をおかけいたしますがキーボードではなくマウスを利用してスケジュールをご登録ください。

// 日本語環境

// 英語環境

注: 本エラーについては弊社開発部署へフィードバックしておりますが、現時点で修正の予定はございません。

こんにちは。Windows プラットフォームサポートの林です。

本日は Hyper-V 環境における手動でのゲスト OS のクラッシュダンプ採取手順についてご説明致します。

手動でのゲスト OS のダンプ採取手順は本来は通常の物理環境と差異がなく、ダンプキー(右 Ctrl キー + Scroll Lock キー x 2回)をゲスト OS へ入力することでハング時などはクラッシュさせることができます。しかし、ダンプキーをゲスト OS へ送るには仮想環境の場合、仮想マシン接続でゲスト OS に接続し、仮想マシン接続に Window フォーカスが合っている状態でダンプキーをホスト OS から入力する必要があります。そしてこの場合、Window フォーカスが仮想マシン接続に合っているかどうか視覚的にわかりにくく、誤ってホスト OS にダンプキーが入ってしまうというリスクがありました。そこで今回はこのような方法ではなく、スクリプトや PowerShell のコマンドレットでダンプキーや NMI を安全にゲスト OS に送信してゲストをクラッシュさせる方法をご案内致します。

手動でゲスト OS をクラッシュさせる手順は Hyper-V ホストのバージョンに依存しており、ホスト OS が Windows Server 2012 R2 以降とそれ以前の OS で手順が異なります。

1. ホスト OS が Windows Server 2012 R2 以降の場合

• Windows Server 2012 R2 からは Debug-VM という PowerShell のコマンドレットにて NMI をソフトウェア的にゲスト OS へ送ることができるようになっております。そのため、ゲスト OS 内で NMI 受信時にクラッシュする設定を行い、ゲスト OS ハング時などには Debug-VM を使って手動でクラッシュさせメモリダンプを採取します。

2. ホスト OS が Windows Server 2008 / 2008 R2 / 2012 の場合

• Windows Server 2012 R2 以前の場合には Debug-VM コマンドがありませんので、VBScript 等にてダンプキー(右 Ctrl キー + Scroll Lock キー x 2回)をソフトウェア的にゲスト OS へ送ることで安全にゲスト OS をクラッシュさせることができます。

以下、上記それぞれの具体的なダンプ採取事前設定および手動でのクラッシュダンプ採取手順となります。

ゲスト OS 完全メモリダンプ設定および採取手順(ホストOS が Windows Server 2012 R2 以降の場合)

=========================
完全メモリダンプ設定手順
=========================

[作業対象ホスト]
ゲストOS

[再起動の必要性]
ゲストOS の再起動が必要

[作業タイミング]
現象発生前の任意のタイミング

注意：下記作業は "ゲスト OS" 内で実施お願いいたします。

1. PageFile の大きさを 物理メモリ + 300 Mbyte の大きさに設定します。
   例えば、物理メモリ 8192 MB（ 8 GB）を搭載の場合は、初期サイズに 8492 MB 以上を設定します。

   a) [スタート] - [コンピュータ] を右クリックし [プロパティ(R)] をクリックします。
   b) [システムの詳細設定(A)] をクリックします。
   c) [詳細設定] タブの [パフォーマンス] にある [設定(S)] をクリックします。
   d) [詳細設定] タブの [仮想メモリ] の項目にある [変更(C)] ボタンをクリックします。
   e) この画面にて、[すべてのドライブのページング ファイルのサイズを自動的に管理する(A)]
      オプションを外します。
   f) システムボリューム (通常 C: ) をクリックします。
   g) [カスタムサイズ] にチェックを付け、[初期サイズ]、[最大サイズ] の両方に物理メモリ + 300 Mbyte
      以上の値を入力します。 (例えば 4096MB メモリの場合、4396MB)
   h) その後 [設定] ボタンをクリックし設定を反映させ [OK] ボタンをクリックします。
   i) "変更結果はコンピューターを再起動しなければ有効になりません。" というポップアップが
      表示されますので、[OK] ボタンをクリックします。
   j) "パフォーマンス オプション" のウィンドウも [OK] ボタンにて閉じます。

2. 完全メモリ ダンプ (Full Dump) および NMI 受信時にクラッシュするよう
   レジストリ設定します。

   a) 「Windows ロゴ キー + R」キーを入力し "ファイル名を指定して実行" のウィンドウを
      表示させます。
   b) "regedit" と入力し、[OK] ボタンをクリックします。

   c) レジストリ エディタが起動しますので下記のレジストリを設定してください。

      キー: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl
      値: CrashDumpEnabled
      タイプ: REG_DWORD
      設定値: 1

   d) ゲストが Windows Server 2008 R2/Windows 7 もしくはそれ以前の場合には
      同じく上記キーに NMICrashDump というレジストリを作成します。

      キー: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl
      値: NMICrashDump
      タイプ: REG_DWORD
      設定値: 1

   注意: ゲストが Windows 8/Windows Server 2012 以降の場合には上記 NMICrashDump
         を設定する必要はありません。

3. ゲスト OS を再起動し、上記設定変更を反映させます。

以上で完全メモリダンプの設定は終了になります。現象発生時に下記の
「完全メモリダンプ取得手順」にてダンプをご取得お願いいたします。

========================
完全メモリダンプ取得手順
========================

[作業対象ホスト]
ホストOS

[取得タイミング]
現象発生時

[採取ファイル]
%systemroot%\Memory.dmp

[事前準備]
以下のように PowerShell を実行する環境設定をお願いします。
(すでに設定済みの場合は不要です)

1. 管理者権限のある PowerShell を起動し以下のコマンドを実行します。

2. 以下のコマンドにて現在の実行制限設定を確認します。
    「Restricted」もしくは「AllSigned」ではないことを確認します。
   
       PS > Get-ExecutionPolicy

    ※ 「Restricted」もしくは「AllSigned」の場合のみ以下を実行して、PowerShellを
       実行できるように設定変更を行います。
      
       PS > Set-ExecutionPolicy RemoteSigned

[ダンプ取得手順]

以下の手順を "現象発生時に" 管理者権限のあるユーザにて "ホスト OS" 上で実行します。

1. "ホスト OS" 上で管理者権限のある PowerShell プロンプトを起動し、以下のように
   dubug-vm コマンドで NMI をゲスト OS へ送信します。

   debug-vm -name [仮想マシン名] -InjectNonMaskableInterrupt -Confirm:$false -Force

2. ゲスト OS はクラッシュしますので、ゲストの再起動後にログオンし、
   以下のダンプファイルを採取します。

   C:\Windows\Memory.dmp

Hyper-V ゲストOS の完全ダンプ取得手順(ホスト OS が Windows Server 2008/2008 R2/2012の場合)

=========================
完全メモリダンプ設定手順
=========================

[作業対象ホスト]
ゲストOS

[再起動の必要性]
ゲストOS の再起動が必要

[作業タイミング]
現象発生前の任意のタイミング

注意：下記作業は "ゲスト OS" 内で実施お願いいたします。

1. PageFile の大きさを 物理メモリ + 300 Mbyte 以上の大きさに設定します。
   例えば、物理メモリ 8192 MB（ 8 GB）を搭載の場合は、初期サイズに 8492 MB 以上を設定します。

   a) [スタート] - [コンピュータ] を右クリックし [プロパティ(R)] をクリックします。
   b) [システムの詳細設定(A)] をクリックします。
   c) [詳細設定] タブの [パフォーマンス] にある [設定(S)] をクリックします。
   d) [詳細設定] タブの [仮想メモリ] の項目にある [変更(C)] ボタンをクリックします。
   e) この画面にて、[すべてのドライブのページング ファイルのサイズを自動的に管理する(A)]
      オプションを外します。
   f) システムボリューム (通常 C: ) をクリックします。
   g) [カスタムサイズ] にチェックを付け、[初期サイズ]、[最大サイズ] の両方に物理メモリ + 1 Mbyte
      以上の値を入力します。 (例えば 4096MB メモリの場合、4396MB)
   h) その後 [設定] ボタンをクリックし設定を反映させ [OK] ボタンをクリックします。
   i) "変更結果はコンピューターを再起動しなければ有効になりません。" というポップアップが
      表示されますので、[OK] ボタンをクリックします。
   j) "パフォーマンス オプション" のウィンドウも [OK] ボタンにて閉じます。

2. 完全メモリ ダンプ (Full Dump) を設定します。

   a) 「Windows ロゴ キー + R」キーを入力し "ファイル名を指定して実行" のウィンドウを
      表示させます。
   b) "regedit" と入力し、[OK] ボタンをクリックします。
   c) レジストリ エディタが起動しますので下記のレジストリを設定してください。

      キー: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl
      値: CrashDumpEnabled
      タイプ: REG_DWORD
      設定値: 1

3. キーボードから STOP エラーを発生させるように設定します。
   上記同様にレジストリ エディタで下記のレジストリを新規作成してください。

   キー: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters
   値: CrashOnCtrlScroll
   タイプ: REG_DWORD
   設定値: 1

4. ゲスト OS を再起動し、上記設定変更を反映させます。

以上で完全メモリダンプの設定は終了になります。現象発生時に下記の
「完全メモリダンプ取得手順」にてダンプをご取得お願いいたします。

========================
完全メモリダンプ取得手順
========================

[作業対象ホスト]
ホストOS

[取得タイミング]
現象発生時

[採取ファイル]
%systemroot%\Memory.dmp

以下の手順を "現象発生時に" 管理者権限のあるユーザにて "ホスト OS" 上で実行します。

1. 下記の DumpVM.vb_ の拡張子を vbs へ変更し、ホスト OS のデスクトップ
   に保存してください。

(Please visit the site to view this file)

2. 管理者権限のあるコマンドプロンプトにて下記のようにスクリプトを実行します。

   > cd %userprofile%\desktop
   > cscript DumpVM.vbs  -v "My VM Name"

   ※ "My VM Name" はダンプを取得するゲスト OS 名です。VM名にスペースを含む場合は
      上記例のように必ずダブルコーテーションで括ってください。

上記実施後、ゲスト OS はブルースクリーンになり、システムダンプが取得されます。

- ご参考 -
NMI_HARDWARE_FAILURE error when an NMI is triggered on Windows 8 and Windows Server 2012
https://support.microsoft.com/en-us/kb/2750146

How to generate a complete crash dump file or a kernel crash dump file by using an NMI on a Windows-based system
https://support.microsoft.com/en-us/kb/927069

How to determine the appropriate page file size for 64-bit versions of Windows
https://support.microsoft.com/en-us/kb/2860880

Debug-VM
https://technet.microsoft.com/ja-jp/library/dn464280(v=wps.630).aspx

こんにちは。

Windows プラットフォームサポートの丸山です。

本日は、弊社に問い合わせのあった Windows 10 に関する不具合についてご紹介させていただきます。

類似の事象が発生しておりましたら、本ブログの回避策をぜひお試しいただけますと幸いです。

■発生する事象について

Windows では、作成したドキュメントを保存せずにサインアウトしたり、コンピューターをシャットダウン、再起動しようとすると、次のようなメッセージが表示され、サインアウトしてもよいかどうかの確認画面が表示されます。

図：サインアウトの確認画面

上記の画面では、[強制的にサインアウト] をクリックしないまま 120 秒放っておくと、元のデスクトップ画面に戻るのですが、以下のように、デスクトップに白いアイコンが表示され、スタート ボタンが効かなくなり、タスク バーのアプリケーションも起動できなくなることがあります。

図：新しいプログラムを起動しようとすると・・・。

図：エラーになります。

なお、上記記載の問題については、サインアウト時にユーザー プロファイルが意図せずしてアンロードされてしまうために発生しております。

ユーザー プロファイルがアンロードされた場合には、イベント ログに以下のようなイベント 1530が記録されます。

図：ユーザー プロファイルのアンロード イベント (User Profile Service, 1530)

■問題の回避策について

上記問題が発生いたしますと、スタート ボタンが動かなくなりますので、通常の手段ではサインアウトができません。

未保存のドキュメントを保存してから、CTRL + ALT + DEL キーを押下して、サインアウトを選択してください。

※未保存のドキュメントがないにもかかわらず、サインアウトの確認画面が表示された場合には、[強制的にサインアウト] をクリックしてください。

図：CTRL + ALT + DEL キーを押したときの画面表示

また、[ユーザーのログオフ時に強制的にユーザー レジストリをアンロードしない] のグループ ポリシーを有効にすることで、問題を回避することができます。

※このグループ ポリシーは、[コンピューターの構成]、[ユーザーの構成] どちらにも存在します。特に問題がなければ、[コンピューターの構成] に設定いただくことを推奨します。

図：[ユーザーのログオフ時に強制的にユーザー レジストリをアンロードしない] のグループ ポリシー設定

■弊社の調査状況について

上記記載の問題については、弊社でも再現手順が確立されており、現在製品開発部門による調査が行われております。

製品開発部門による調査が完了しましたら、本ブログの内容をアップデートする予定です。

Windows 10 はユーザー様のフィードバックを受けながら日々、新しい機能が追加されていく進化する OS です。

日常業務でWindows 10 を積極的にご利用いただき、どんどんフィードバックをお寄せいただけますと幸いです。

※フィードバックの投稿には、Windows 10 付属の Windows フィードバック アプリをご利用ください。

図：Windows フィードバック アプリ

今後も、本ブログをどうぞよろしくお願いします。

--

丸山 健一 (マルヤマ ケンイチ)

Windows プラットフォームサポート担当

日本マイクロソフト株式会社

こんにちは。Windows プラットフォーム サポートの宇田です。

今回は Azure RemoteApp の一般的な構成と、構築手順についてご案内致します。

Azure RemoteApp 以外に、Active Directory、Azure Active Directory、Virtual Network など多岐にわたるテクノロジーを利用して構成されており、ハイブリッド構成を構築するまでの手順が非常に複雑なため、画面付きのスライドとして、手順をご用意しています。

検証作業などにぜひご活用いただければ幸いです。

こんにちは。
Windows プラットフォーム サポートの丸山です。

本日は、弊社にて調査中の “システム構成”ツールに関する不具合についてご紹介させていただきます。
もし、お使いの環境でも類似の事象が発生しておりましたら、本ブログ記事をご参考いただけますと幸いです。

■ 発生する事象について

Windows では、msconfig コマンドを実行すると、“システム構成”ツールが起動して、Windows の起動時に開始するサービスを一部無効化したり、デバッグ機能を有効にして、Windows 起動時のトラブルシューティングを行うことができます。
また、“システム構成”ツールを起動すると、通常の環境では “全般”タブの “スタートアップの選択”にて “通常スタートアップ”が選択された状態となっています。

図 : ”システム構成”ツール起動時の状態 (正常時)


ところが弊社では、一部の環境にて “システム構成”ツールを起動すると、“全般”タブの “スタートアップの選択”にて “スタートアップのオプションを選択”が選択されているという事象が報告されております。

 図 : “システム構成”ツール起動時の状態 (異常時)


本事象は以下製品をお使いの場合に発生することが確認されております。 

• Windows 8

• Windows 8.1

• Windows 10

• Windows Server 2012

• Windows Server 2012 R2

■ 弊社の調査状況について

上記に記載いたしました問題は、弊社でも事象の再現を確認しており、弊社製品の不具合として製品開発部門による調査が行われております。
製品開発部門による調査が完了しましたら、本ブログの内容をアップデートする予定です。

なお、本動作につきましては、”システム構成”ツールの表示上の問題であることが確認されております。
一度 “通常スタートアップ”を選択して “OK”または “適用”を押下しました場合には、次回 “システム構成”ツールの起動時に “スタートアップのオプションを選択”が選択されている場合にも、”通常スタートアップ”の設定は有効でございますため、ご安心ください。

本ブログが皆様の問題解決に少しでもお役立ちできますと幸いです。

--
丸山 健一 (マルヤマ ケンイチ)
Windows プラットフォームサポート担当
日本マイクロソフト株式会社

こんにちは。Windows プラットフォーム サポートの戸田です。

本記事では弊社過去事例データベースからの情報を基に、 Windows Server 2012 R2 を用いたフェールオーバー クラスター環境で以下のイベント ID 1206 が 24 時間毎に記録される場合の対処策について紹介します (同時にイベント ID 1207 が記録されることもあります)。

ログの名前:         System
ソース:           Microsoft-Windows-FailoverClustering
イベント ID:       1206
タスクのカテゴリ:      ネットワーク名リソース
レベル:           エラー
説明:

クラスター ネットワーク名リソース '<ネットワーク リソース名>' に関連付けられたコンピューター オブジェクトをドメイン '<ドメイン名>' で更新できませんでした。エラー コードは 'Password change' でした。クラスター ID '<クラスター名$>' は、オブジェクトを更新するために必要なアクセス許可を持っていない可能性があります。ドメイン管理者と協力して、このクラスター ID がドメインのコンピューター オブジェクトを更新できるようにしてください。

ログの名前:         System
ソース:           Microsoft-Windows-FailoverClustering
イベント ID:       1207
タスクのカテゴリ:      ネットワーク名リソース
レベル:           エラー
説明:

クラスター ネットワーク名リソース '<ネットワーク リソース名>' に関連付けられたコンピューター オブジェクトをドメイン '<ドメイン名>' で  Resource post online 操作中に更新できませんでした。 関連するエラー コードのテキストは次のとおりです: 操作エラーが発生しました。   クラスター ID '<クラスター名$>' は、オブジェクトを更新するために必要なアクセス許可を持っていない可能性があります。ドメイン管理者と協力して、このクラスター ID がドメインのコンピューター オブジェクトを更新できるようにしてください。

これらのイベントは "説明" 部分のとおり Active Directory 内でのコンピューター パスワードの更新に失敗したことを示しており、その理由として ”オブジェクトを更新するためのアクセス許可を持っていない可能性" のあるイベントです。このパスワード更新とは以下のポリシーで構成される、コンピューター アカウントのパスワードのことです。

ドメイン メンバ : コンピュータ アカウント パスワード : 定期的な変更を無効にする
https://msdn.microsoft.com/ja-jp/library/Cc785826(v=WS.10).aspx

ドメイン メンバ : 最大コンピュータ アカウントのパスワードの有効期間
https://msdn.microsoft.com/ja-jp/library/cc781050(v=ws.10).aspx

それぞれの既定値は「更新を行なう」「有効期間は 30 日」となっています。クラスター仮想サーバーに対するパスワード有効期限はこの設定値の 75 % (既定値では 30 日 * 0.75 = 22.5 => 22 日毎) で更新がスケジュールされます。このパスワード更新はドメイン メンバーのコンピューター全般で行なわれますが、クラスター仮想サーバーで今回のイベントが記録される理由としてはドメイン内での認証が失敗するなどセキュアチャネルが破損している場合や、クラスターがパスワード更新を行なう為に必要なアクセス許可設定が不足している場合が考えられます。なお、このイベントが記録される状況はパスワード更新のタイミングで初めて表面化するため、いつどのような状況でセキュアチャネルが壊れたのかなどの原因については捉えることが非常に困難となります。

一般的にこれらのイベントが記録される場合でもネットワーク名リソースはオンライン状態を維持しますので、クライアント アクセスへの影響が発生するような報告はありません。

◆ 対処方法について

もしご利用のクラスター環境において上記のイベントが記録される場合には、Active Directory 上の CNO (Cluster Name Object = クラスター管理用の仮想サーバー名オブジェクト)、VCO (Virtual Computer Object = アプリケーション/サービスが使用する仮想サーバー名のオブジェクト) のアクセス許可設定の確認とセキュアチャネルの「修復」操作として、以下の 手順 1 から 4 までを行い、現象が改善するかについてご確認ください。

アクセス許可設定の確認

以下の手順 1 と 2 はコンピューター オブジェクトのアクセス許可設定の確認です。ドメイン コントローラーの [Active Directory ユーザーとコンピューター] から操作を行ないます。

1． CNO のフルコントロールの確認

フェールオーバー クラスター環境ではクラスター管理用に CNO のアクセス許可設定が使用されます。自分自身のオブジェクトへのフルコントロールがあるかの確認を行ない、不足するようなら追加します (既定ではフル コントロールはついています)。

a)  ドメイン コントローラーの「Active Directory ユーザーとコンピューター」より CNO (クラスター管理用の名前) のコンピューター オブジェクトのプロパティを表示します。

b)  [セキュリティ] タブ※より SELF を表示、フル コントロールにチェックが付いているかどうかを確認します。もしチェックが付いていない場合にはチェックを付けます。

2．VCO に対して CNO のフルコントロールがあるかの確認

VCO は CNO によって管理されています。VCO に CNO のフルコントロールがあるかを確認し、不足するようなら追加します (既定ではフル コントロールはついていませんがここでは明示的に追加します)。

a)  ドメイン コントローラーの「Active Directory ユーザーとコンピューター」より VCO (クラスターの「役割」で使用する仮想サーバー名) のコンピューター オブジェクトのプロパティを表示します。

b)  [セキュリティ]タブ※より CNO (クラスター管理用の名前) を表示、フル コントロールにチェックが付いているかどうかを確認します。もしチェックが付いていない場合にはチェックを付けます。

※ [セキュリティ] タブが表示されない場合には、「Active Directory ユーザーとコンピューター」メニュー バーの [表示] - [拡張設定] にチェックを付けます。

セキュアチャネルの「修復」操作

以下の手順 3 と 4 はセキュアチャネルの修復方法です。フェールオーバー クラスター マネージャーから行ないます。既にパスワードの不整合が発生してしまっている場合には CNO、VCO に対して以下の操作を行ないセキュアチャネルを修復します。

3. CNO の修復手順

a) フェールオーバー クラスター マネージャーより、左ペインのツリーを展開し [フェールオーバー クラスター マネージャー] - [クラスター名(FQDN表示)]を選択(反転表示)します。

b) 中央ペインの [クラスター コア リソース]を展開します。

c) [クラスター名] の下にある [名前: <CNO の名前>] の右クリック メニューから[オフラインに移行]を選択しオフラインの状態にします。

d)  [名前: <クラスター名>] の右クリック メニューから [他のアクション] - [修復] ※をクリックすることにより、セキュア チャネルの修復を行うことが出来ます。

4.  VCO の修復手順

a) フェールオーバー クラスター マネージャーより、左ペインのツリーを展開し [役割] を表示、中央ペインから対象の役割を選択(反転表示)します。

b) 中央ペイン下段の [リソース] タブを表示します。

c) [サーバー名] の下にある [名前: <VCO の名前>] の右クリック メニューから[オフラインに移行]を選択し、オフラインの状態にします。

d) [名前: <VCO の名前>] の右クリック メニューから[他のアクション] - [修復] ※をクリックすることにより、セキュア チャネルの修復を行うことが出来ます。

  ※ [修復] メニューはリソース オンライン時にはグレーアウトされており選択することが出来ません。そのため、一時的に、手順 c でオフラインにする必要があります。 [修復]メニュー実施後は自動的にオンラインのステータスに戻ります。

以上、この情報が皆様のお役に立てば幸いです。

こんにちは。Windows プラットフォーム サポートの山崎です。

リモート デスクトップ サービス で使用される CAL の発行動作について説明いたします。

今回よくご質問いただく上記動作に関して、以下のフローチャートを作成いたしました。

Source Site:

RD Licensing Demystified – how it Works

http://social.technet.microsoft.com/wiki/contents/articles/21180.rd-licensing-demystified-how-it-works.aspx

上記フローチャートで " * " を記したポイントについては以下の補足説明をご参照ください。

目次

*1　RD セッション ホストで RD ライセンスを指定できていることを確認する方法

*2　接続モードとは?

*3　一時 CAL と恒久 CAL とはなにか？

*4　ライセンス猶予期間とはなにか?

1. RD セッション ホストで RD ライセンス サーバーを指定できていることを確認する方法

RD セッションホストでは、設定画面やグループポリシーから、RD ライセンス サーバーの指定できます。正しく CAL が発行できる RD ライセンス サーバーと認識した場合、RD セッション ホストに以下のレジストリが作成されます。

うまく CAL が発行されない、リモートデスクトップ接続ができないといった場合には、以下のレジストリが RD セッションホストに作成されているかご確認ください。

RD ライセンスが正常に指定されていることを確認する方法

1. RD セッション ホストで、 [スタート] – [ファイル名を指定して実行] を選択し、 regeditと入力してエンターキーを押します。
2. レジストリエディタが起動するので次のレジストリ サブキーを見つけてクリックし、下記のキーが作成されていれば、正常に RD ライセンス サーバーが指定されているとご判断いただけます。

　　　　　HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermService\Parameters

　　　　　　　Certificate

X509 Certificate
X509 Certificate ID
X509 Certificate2

戻る

2. 接続モードとは?

接続モードとは、購入された CAL の形態に合わせ、RD セッション ホストにて指定する接続モードとなります (設定は RD セッション ホストで行います)。

接続モードには、以下の二種類が存在し、購入された CAL の種類に合わせて指定する必要があります。

RDS CAL (接続デバイス数):

任意のユーザーが使用する 1 台のデバイスが RD セッション ホスト サーバーに接続することを許可します。

RDS CAL (接続ユーザー数):

1 人のユーザーに、無制限の数のクライアント コンピューターやデバイスから RD セッション ホスト サーバーにアクセスする権限を与えます。

- 参考文献

リモート デスクトップ ライセンス モードを指定する

https://technet.microsoft.com/ja-jp/library/cc742812.aspx

戻る

3. 一時 CAL と恒久 CAL とはなにか？

　　接続デバイス数モード使用時に発行されるライセンスです。

[一時 CAL]

クライアント からRD セッション ホストに初めて接続したときに発行されるライセンスです。

一時 CAL の有効期限は 90 日間となり、利用可能な恒久 CAL がない場合は、二度目以降の接続時も有効期間内は一時 CAL のまま接続できます。

一時 CAL の発行数に制限はありません。 有効期限が到来したときに、利用可能な恒久 CAL がない場合はRD セッション ホストに接続できません。

[恒久 CAL]

一時 CAL を持っているクライアントが二回目に接続したときに発行されるライセンスです。

恒久 CAL の有効期限は、52 ～ 89 日間のランダムな期間が設定されます。

RD ライセンス にインストールしたRDS CAL を上限として発行されます。 

詳細はこちらのブログにて詳しく説明していますので、ご参照ください。

戻る

4. ライセンス猶予期間とはなにか?

RD セッションホストでは、RD セッションホストの役割インストール後 120日間 は RD ライセンス  サーバー を必要としない猶予期間が設けられています。

この猶予期間が終了すると、リモートデスクトップでの接続を行うことがなくなります。それまでにRD ライセンス サーバーと RDS CAL をご用意ください。

- 参考文献

リモート デスクトップ ライセンスの概要

https://technet.microsoft.com/ja-jp/library/cc725933.aspx

戻る

こんにちは。日本マイクロソフトの江田です。
 

今回は Windows OS について、各バージョンのシステム要件をまとめました。

こちらは比較を目的として概要レベルでまとめたものになりますため、各 OS の詳細につきましては、

弊社 TechNet サイトをご参照ください。記事下部に URL リンクを記載しました。

Windows Server 2003 SP2 について 

Windows Server 2003 R2 について

*1 : ネットワークインストール *2 : CD インストール

Windows Server 2008 について

 
Windows Server 2008 R2 について

Windows Server 2012 について

 
ファイルシステムに関する制限について

- 参考情報

システム要件

http://technet.microsoft.com/ja-jp/windowsserver/bb430827.aspx

Windows Server 2008 のインストール

http://download.microsoft.com/download/a/5/3/a5361a95-87b0-4221-b9ec-a415f745a475/readme.htm

Windows Server 2008 R2 Service Pack 1 (SP1) システム要件

http://www.microsoft.com/ja-jp/server-cloud/local/windows-server/2008/r2/prodinfo/sysreqs.aspx

Installing Windows Server 2012

http://technet.microsoft.com/library/jj134246#BKMK_sysreq

Memory Limits for Windows Releases

http://msdn.microsoft.com/en-us/library/aa366778.aspx

Storage Technologies Collection

http://technet.microsoft.com/en-us/library/616e5e77-958b-42f0-a87f-ba229ccd8172

NTFS と FAT および FAT32 の比較

http://technet.microsoft.com/ja-jp/library/cc779002(v=ws.10).aspx

Resilient File System Overview

http://technet.microsoft.com/en-us/library/hh831724.aspx

こんにちは、日本マイクロソフトの松岡です。

Microsoft Exchange Server 2010 の DAG 環境において、3rd party 製のバックアップ要件などで、「DAG 環境のクラスター コア グループにバックアップ専用の IP アドレスを追加したい」というお問い合わせをいただくことがございます。しかしながら、DAG 構成においてバックアップ専用の IP アドレスを設定することは、サポートされておりません。

今回は以下の 2 点についてご案内させていただきます。

1. 「何故バックアップ専用の IP アドレスを追加することがサポート対象外であるのか」

2. 「どのようにバックアップをとれば良いのか」

1. 「何故バックアップ専用の IP アドレスを追加することがサポート対象外であるのか」という点について説明します。

まず DAG 構成をとる際のネットワーク要件について考えます。

---------------------

DAG 構成の環境を作成する際に、一意の名前を 15 文字以内で指定する必要があります。またそれ以外に、1 つ以上の IP アドレス (IPv4 または IPv4 と IPv6 の両方) を割り当てる必要があり、割り当てられた IP アドレスは、MAPI ネットワークのサブネット上で使用可能な状態である必要があります。その上で  DAG と IP アドレスの要件として各 DAG には複数の MAPI ネットワークが備えないようにする必要があり、指定された MAPI ネットワークは、他の Exchange サーバーおよび Active Directory や DNS などのその他のサービスへの接続を提供しなければなりません。

---------------------

※MAPI （Messaging Application Programming Interface） とはメッセージを送受信するアプリケーション用にマイクロソフトが作成した規約です。メッセージの送受信、アイテムの保存、アドレス帳の参照など Outlook のさまざまな機能は、MAPI を RPC ベースで呼び出すことによって実現されています。

上記要件を簡単にまとめると、以下の 2 つの要件によって DAG にバックアップ専用の IP アドレスを追加することができません。

・DAG に対して割り当てる IP アドレスは MAPI ネットワークというネットワーク上にある必要がある。

・DAG 構成では MAPI ネットワークを複数持つことが出来ない。

（ 注 : サイトを跨いだ DAG の場合、各サブネットに 1 つずつ DAG 用の IP アドレスを保持できます。）

MAPI ネットワークを複数設けた場合でも、スイッチオーバーやスイッチバック、Outlook からの接続等は、問題なく行うことが出来ます。しかし上述の通り、他セグメント上のサーバーや他サイトの DAG とも通信を行うためのネットワークであるため、ゲートウェイの問題を含め、様々な理由で複数ある状態は構成としてサポートされない状況となっております。

2. 「どのようにバックアップをとれば良いのか」という点について説明します。

バックアップを取得する対象についてですが、Exchange Server 2010 の構成情報は、Active Directory 上に保存されていますので、基本的にバックアップの対象となるのはデータベースとなります。DAG では全てのノードがアクティブである為、各ノードが保持するデータベースからバックアップを取得すれば問題ございません。

つまり、”バックアップ取得の為に、専用の IP アドレスを追加する必要は無い”ということになります。

ここで一例としてWindows Server Backup によるバックアップを以下にご紹介します。

<参考> Windows Server バックアップを使用した Exchange のバックアップ

https://technet.microsoft.com/ja-jp/library/dd876854.aspx

Windows Server Backup によるバックアップ取得では、制限事項としてアクティブ (またはスタンドアローン) のデータベース コピーのみ Exchange 対応バックアップを採取できます。今回は DAG 環境ですべてのノードがアクティブなので、問題なくバックアップを取得することが可能です。

　　～まとめ～

「DAG 環境でバックアップ専用 IP アドレスを設定できない」件についての弊社の見解は、以下 2 点となります。

・バックアップ専用のものに限らず IP アドレスを追加することは、DAG 構成の要件上 "サポート対象外" である！

・DAG 環境のバックアップは、各ノードが保持するデータベースから取得することが可能である！

繰り返しになりますが、Exchange Server 2010 の DAG 環境においてバックアップの計画を立てる場合は、バックアップ専用の IP アドレスを設定することなく、各サーバーのデータベースよりバックアップを取得いただく運用をお願いいたします。

以上、本情報がお役に立てば幸いでございます。

※以下参考 URL　

<参考> バックアップ、復元、および障害回復

https://technet.microsoft.com/ja-jp/library/dd876874.aspx

<参考> Windows Server バックアップを使用して Exchange のバックアップを復元する

https://technet.microsoft.com/ja-jp/library/dd876864.aspx

<参考> Exchange Server 2010 可用性ガイド ホワイト ペーパー

http://download.microsoft.com/download/5/2/2/5229EFB4-65BE-450D-B18A-4BBAF5519EDF/exchange2010_availability.doc

Windows サポートの永野です。

Windows Server 2008/2008R2 から Windows Server 2012/2012R2 の間で、ネットワーク名リソースの実装が大きく変わり様々な動作に変更が加えられております。ネットワーク名リソースに設定された名前を変更する際の挙動にも変更が加えられており、これまでと異なった挙動をすることがございます。ネットワーク名リソースは作成されたタイミングで CreatingDC というプロパティが設定されます。CreatingDC には、このネットワーク名リソースのコンピューター オブジェクトの作成時に利用されたドメイン コントローラーが設定されます。

CreatingDC
https://msdn.microsoft.com/en-us/library/aa371734%28v=vs.85%29.aspx

そして、ネットワーク名リソースに設定された名前を変更する際には、CreatingDC に登録されたドメイン コントローラーに接続して変更処理を行います。そのため、CreatingDC に登録されたドメインコントローラーに接続できないと名前の変更などが行えなくなる場合があります。Windows Server 2012/2012R2 のクラスターでは、ドメイン コントローラーのメンテナンスやリプレースが行われることを想定して CreatingDC を定期的にメンテナンスしております。メンテナンスのタイミングで CreatingDC に設定されたドメイン コントローラーが利用できなくなっていた場合には、CreatingDC の設定を現在利用可能なドメイン コントローラーに変更します。

CreatingDC に設定されたドメイン コントローラーが直前にシャットダウンした場合などには、CreatingDC のメンテナンスが完了しておらず、ネットワーク名リソースに設定された名前を変更する処理がエラー 0x8007230a (ERROR_DS_SERVER_DOWN) で失敗する場合がございます。そういった状況であれば、ネットワーク名リソースの修復を行い、CreatingDC のメンテナンスを手動で行うことで名前の変更が可能になります。そういった状況が発生した場合の対処方法を弊社検証環境を例に記載いたします。

CreatingDC は、各リソースのレジストリ内の Parameters 配下から確認することができます。
※ HKLM\Cluster 配下をネットワーク名で検索すると容易に探せるかと存じます

この状況で CreatingDC に登録されている DC2012R2.contoso.com をシャットダウンすると、notetest1 というネットワーク名を notetest2 というネットワーク名に変更する作業が失敗します。

そこで [修復] を実行します。[修復] はリソースを右クリックし、[他のアクション] を展開することで実行できます。
※ オフライン/失敗の状態でないと [修復] がグレーアウトしており、選択することができません

修復を実行すると CreatingDC が現在動作している他のドメイン コントローラーに変更されます。

CreatingDC に利用可能なドメイン コントローラーが登録されている状況となったので、問題なく名前が notetest2 に変更できております。

もし、ネットワーク名リソースに設定されている名前を変更する作業が 0x8007230a が発生しましたら、該当のネットワーク名リソースの CreatingDC を確認してみてください。CreatingDC に登録されたドメイン コントローラーがシャットダウンしているような状況で正常に動作していなければ、[修復] を実行することで変更が可能になるかどうか確認してください。