システム準備 (Sysprep) ツールを利用し、展開している皆様、こんにちは。
Windows プラットフォーム サポートの河野 (コウノ) です。

Windows 8 / Windows 8.1 の環境において、応答ファイルの設定で CopyProfile を有効にした状態でイメージ展開した場合、展開後の端末にて以下の事象が発生する可能性がございます。 

• 一部 WEB ページのコンテンツが空白となる。(DOM Storage という技術が利用できず、これを用いたページが正しく表示できない）
• Web ページの印刷を行う際に、印刷プレビューの画面が表示されない。
• エンタープライズモードが正常に機能しない。

上記事象は Sysprep のプロファイル コピーの処理によって、%userprofile%\AppData\LocalLow フォルダーにLow Mandatory Level のアクセス権が付与されないことに起因しています。
上記事象が発生している場合、以下の状況に応じた回避策をお試しください。


- 回避策

• 既に展開済み、使用中の端末の場合
• 展開中の場合

===========================================
既に展開済み、使用中の端末の場合
===========================================

既に展開済みで使用中の端末においては、icacls コマンドを利用して、以下のように各ユーザー フォルダ配下の対象フォルダーに対してアクセス権を付与することで解消されます。

  icacls %userprofile%\appdata\locallow /setintegritylevel (OI)(CI)L
  icacls %userprofile%\appdata\locallow\microsoft /setintegritylevel (OI)(CI)L
  icacls "%userprofile%\appdata\locallow\microsoft\Internet Explorer" /setintegritylevel (OI)(CI)L


===========================================
・展開中の場合
===========================================

展開直後の端末にて以下のフォルダーを削除します。

  C:\Users\Default\AppData\LocalLow

既定ユーザー プロファイルの配下の LocalLow フォルダーを一度削除することによって、新規ユーザー アカウントでログオンする際に、プロファイルの作成とともに Low Mandatory Level アクセス権が付与された形で自動生成されます。

皆さん、こんにちは。

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

今回は、リモート接続する際の画面に関連する以下の設定を紹介させて頂きます。

1. 複数モニター

2. 最高解像度

3. Smart Sizing



1. 複数モニターについて

Windows 7 / Windows Server 2008 R2 から複数モニターがサポートされるようになり、“スパン モード” (例は後述) とは異なって、クライアントの全てのモニターをリモート デスクトップ セッションで利用できるようになりました。

使い方 :

以下の 3 つの何れかの設定を行うことによって、複数モニターでリモート接続が可能になります。

* 接続先と接続元のOS はWindows 7 / Windows Server 2008 R2 以降のバージョンから、設定可能です。

a. 画面 (GUI) から設定する方法

b. コマンド プロンプトで設定する方法

c. RDPファイルで設定する方法

上記の詳細手順を以下に記載いたします。

a. 画面 (GUI) から設定する方法

1. Remote Desktop Client (mstsc.exe) を起動します。

2. "オプション" をクリックし、詳細設定を表示させます。

3. "画面" タブを開き、[リモート セッションで全てのモニターを使用する] にチェックを入れます。

b. コマンド プロンプトで設定する方法

1. コマンド プロンプトを起動します。

2. "mstsc /multimon" を実行します。

3. 起動したRemote Desktop Client にてリモート接続します。

c. RDPファイルで設定する方法

1. RDP ファイルを作成します。

1.1 Remote Desktop Client を起動します。

1.2 "オプション" をクリックし、詳細設定を表示させます。

1.3 "接続設定" にて、[名前を付けて保存] をクリックします。

1.4 ファイル名と保存先を指定し、保存します。

2. 作成されたRDP ファイルを右クリックします。

3. "プログラムから開く" にポイントし、"メモ帳" をクリックします。

4. 設定されたパラメータが表示されますので、新しい行に以下を記載します。

use multimon:i:1

尚、複数モニターを接続先の以下のグループ ポリシーで制限することも可能です。

[コンピューターの構成]

 – [管理用テンプレート]

 – [Windows コンポーネント]

 – [リモート デスクトップ サービス]

 – [リモート デスクトップ セッション ホスト]

 – [リモート セッション環境]

ポリシー名 : モニターの最大数を制限する (Windows Server 2012 では、"モニターの数を制限する")

注意事項として、上記の制限を超えるとシングル モニターになるという動作になります。

詳細の理由は後述します。■

見え方 :

複数モニターのリモート接続は、接続元のモニターがどの様な配置になっていても利用可能です。

例 :

上記で触れた “スパン モード” は、Windows Vista から導入された設定です。

スパン モードとは、シングル モニターと概要的には同様であるため、リモート デスクトップでウィンドウを最大化すると、全てのモニターに広がります。

しかし、複数モニターではモニター単位で管理されているため、最大化されたウィンドウも存在するモニターで最大化されます。

スパン モードの例 :

また、スパン モードでは、以下の制限があります。

1. 一番左のモニターがプライマリ モニター

2. モニターの全体図は長方形

3. 最高解像度が 4096 × 2048 以下

   (例 : 1600 × 1200 のディスプレイを 2 枚利用している環境では 1600 × 1200 ＋ 1600 × 1200 = 3200 × 1200 なので、スパンモード可能です。)

スパン モードが出来ない例 :

スパン モードが利用できない理由 :

図 1 : モニターの全体図は長方形でない

図 2 : モニターの全体図は長方形でない、一番左のモニターがプライマリ モニターでない

モニターの最大数は、以下のグループ ポリシーで制限することが出来ます。

[コンピューターの構成]

 – [管理用テンプレート]

 – [Windows コンポーネント]

 – [リモート デスクトップ サービス]

 – [リモート デスクトップ セッション ホスト]

 – [リモート セッション環境]

ポリシー名 : モニターの最大数を制限する (Windows Server 2012 では、"モニターの数を制限する")

注意事項として、上記の制限を超えるとシングル モニターになるという動作になります。

詳細な理由は後述します。■

2. 最高解像度について

リモート デスクトップ セッションの合計最高解像度 (全てのモニターを合計した解像度) は現時点で 4096 × 2048 と制限されています。

以下のグループ ポリシーにて、最高解像度を制限することが出来ます。

[コンピューターの構成]

 – [管理用テンプレート]

 – [Windows コンポーネント]

 – [リモート デスクトップ サービス]

 – [リモート デスクトップ セッション ホスト]

 – [リモート セッション環境]

ポリシー名 : 最高解像度を制限する

注意事項として、上記のポリシーは複数モニターを利用している際のみ適用されるポリシーです。

複数モニターで利用している際のみ適用される理由は、グループ ポリシーは設定した制限を超えると、複数モニターと同様で、シングル モニターになるという動作であるからです。

そのため、例えば1600 × 1200 のモニターを 2 台利用している環境で、最高解像度をグループ ポリシーで 1024 × 768 と設定すると、1 台のモニターを利用することになります。

シングル モニターで更に解像度を制限することは不可能です。

尚、複数モニターと最高解像度を両者制限している場合、計算は (複数モニターの制限) × (最高解像度の制限) であるため、その積を超えるとシングル モニターになります。

■ ネットワークの負荷を減らすために複数モニターと最高解像度の制限のグループ ポリシーが導入されました。

  複数モニターの負荷と比べてシングル モニターでの負荷は低いためこのような動きとなっています。

3. Smart Sizing について

Smart Sizing はWindows XP から導入された機能で、一つのウィンドウでリモート デスクトップの画面を全て表示させることが出来ます。

通常のリモート接続では、ウィンドウがリモート デスクトップの画面より小さい場合は、スクロール バーが表示され、不便な場合があります。

Smart Sizing モードを利用することによって、サーバーの画面を縮小して、スクロール バーを使用することなく表示できます。

Smart Sizing はRDP ファイルに “smart sizing:i:1” を記入することによって利用できます。

手順は以下の通りでございます。

※上記の [手順 1.c] とほぼ同様でございます。

1. RDP ファイルを作成します。

1.1 Remote Desktop Client を起動します。

1.2 "オプション" をクリックし、詳細設定を表示させます。

1.3 "接続設定" にて、[名前を付けて保存] をクリックします。

1.4 ファイル名と保存先を指定し、保存します。

2. 作成されたRDP ファイルを右クリックします。

3. "プログラムから開く" にポイントし、"メモ帳" をクリックします。

4. 設定されたパラメータが表示されますので、新しい行に以下を記載します。

smart sizing:i:1

Smart Sizing を利用することによって、リモート接続画面の画面を自由自在に変えることが出来ます。

また、Windows 8 以降 (接続元がRDP 8.0 以降) の場合、Smart Sizing はリモート デスクトップのトップバーを右クリックすることによって、切断することなく有効にすることが出来ます。

上記の画面に関連する 3 つの設定を使いこなして、より快適にリモート接続が出来ることを心から望んでおります。

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

今回は、C:\Windows\Temp フォルダーに cab_XXX_X (以下図) が生成されディスクの容量を圧迫している場合の対処方法についてご紹介いたします。

C:\Windows\Temp\cab_XXX_X は、Windows Module Installer Service によって利用される、CBS.log を圧縮する際に利用される一時ファイルとなります。
このファイルは、本来圧縮完了後削除されるはずですが、圧縮時の処理の中で問題が発生した場合、残存することがございます。

この問題が発生した場合の対処方法をご紹介いたします。

- 対処方法
以下のファイルを別の場所に移動するもしくは削除します。
 
C:\Windows\temp\cab_XXX_X (前述の図)
C:\Windows\logs\CBS\CbsPersist_xxxxxxxxxxx.log (以下図)
C:\Windows\logs\CBS\CbsPersist_xxxxxxxxxxx.cab (以下図)

・ cab_XXX_X は、.cab ファイル生成失敗を示す一時ファイルとなりますので、削除していただいても問題はありません。

・ CbsPersist_xxxxxxxxxxx.logは、更新プログラムの適用や機能の追加と削除実行時にエラーが発生した場合に有効な情報が記録されたログのバック アップ ファイルとなります。

・ CbsPersist_xxxxxxxxxxx.cabは、上記 CbsPersist_xxxxxxxxxxx.log が正常に圧縮された際の Cab ファイルとなります。

CbsPersist_から始まるファイルについては、更新プログラムの適用時や機能の追加時になど問題が発生している際には削除ではなく、移動いただくことを推奨いたします。
ただし、CbsPersist_xxxxxxxxxxx.logについては、ファイルサイズが大きい場合や破損している場合、開くことができない可能性がございますので、開けない場合には削除ください。

- cab_XXX_X ファイルが増加し続ける際の動作について

cab_XXX_X ファイルは、以下の流れに沿って生成されます。

1. cbs.log のバック アップ用のログが CbsPersist_xxxxxxxxxxx.log というファイル名で保存されます。

2. このバック アップ用の CbsPersist_xxxxxxxxxxx.log を元に CbsPersist_xxxxxxxxxxx.cab が生成されます。

   この時に、CbsPersist_xxxxxxxxxxx.log ファイルサイズが 2GB 以上である場合、また、ファイルが破損している場合などに、CbsPersist_xxxxxxxxxxx.cab の生成に失敗します。
   この生成に失敗した場合、C:\Windows\temp フォルダーに cab_XXX_Xファイルが残存します。

3. CbsPersist_xxxxxxxxxxx.cab ファイルの生成に失敗するため、CbsPersist_xxxxxxxxxxx.log ファイルとして CBS フォルダーに残ります。(以下図)

Cbs.log のバックアップ処理の際に、 Cab ファイルの生成が再実行され、再度失敗しますので、 C:\Windows\temp フォルダーに cab_XXX_X ファイルが生成され続け結果、C:\ ドライブの容量を圧迫いたします。

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

今回は Hyper-V のゲスト マシンとして、Windows 8.1 や Windows Server 2012 R2 をセットアップ時 (プロダクト キーを入力した後) に以下のエラーが出た場合の対処方法をご紹介いたします。

"プロダクト キーを検証できませんでした。インストール メディアを確かめてください"

- 発生原因について
このエラーは以下のような場合に出力され、プロダクト キーの入力以降インストールが進まなくなります。

・ インストール時に使用しているメディアと、プロダクト キーが違った場合
・ HyperｰV のゲスト マシンに割り当てられたメモリが不足している場合
・ 利用しているメディアが正常に読み込めない場合

- 対処方法について
このエラーが表示されて先に進まない場合には以下をご確認ください。

・ インストールに使用したメディアとプロダクト キーの組み合わせが合っているか。
   (たとえば、Windows Server 2012 R2 のメディアを使用して、プロダクト キーが Windows Server 2012 の場合等)

・ HyperｰV のゲスト マシンに割り当てられたメモリがシステム要件を満たしているか。
   (たとえば、Windows 8.1 をインストールする際に、割り当てられたメモリが 512 MB の場合)

・ インストールに利用したメディアに汚れや傷などが発生していないか。(メディアの確認)

・ 他のインストール メディアでもインストールできるか。(光学ドライブの確認)

- 参考情報
Windows 8.1 のシステム要件は以下をご覧ください。

システム要件 (Windows 8.1 / Windows 8)
http://windows.microsoft.com/ja-jp/windows-8/system-requirements

そのほか、同様の条件で以下のような問題も発生します。

併せてご参照ください。

“マイクロソフト ソフトウェア ライセンス条項が見つかりません” でエラーになる事象について
http://blogs.technet.com/b/askcorejp/archive/2013/12/12/3617960.aspx

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

長く運用しているサーバーでは 「ボリュームの空き領域が減少したため対策をとりたい」 というお問い合わせをいただくことがあります。

今回は Windows Server 2008 以降の OS を対象とし、空き領域の確保する対策の一つとして 「ボリュームの拡張」 する方法をご案内いたします。

===============
図 1 - 拡張可能な例
===============

この図 1 の例では、ボリューム C: に連続する未割り当て領域があるため拡張可能です。

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

図 2 - 拡張できない例

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

この図 2 の例では、ボリューム E: や F: を拡張しようとした場合でも、空き領域がないため拡張することができません。

*******

では、実際に 「図 2 - 拡張できない例」 の場合でも、データの移行が可能な場合に、ボリューム拡張を行う具体的な手順についてご案内します。

===================
ボリュームの拡張手順例
===================

1. ボリューム Z: には十分な空き領域があるため、F: の必要なデータを Z: に移動します。
   (又は、ボリューム縮小および新たなボリュームを作成後データの移行を実施します)
2. F: を選択し、右クリックのメニューより [ボリュームの削除] を選択し実施します。
   (全てのデータが削除されるメッセージが表示されるので、問題なければ [はい] をクリックして先に進みます)
3. ボリュームの削除が完了すると、以下のようにボリューム E: の連続する領域に未割り当て領域が表示されます。
   
   
4. ボリューム E: を選択し右クリックのメニューより [ボリュームの拡張] を選択し実行します。
5. 以上でボリュームの拡張の対応は完了です。

*******

補足情報

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

通常、ボリューム拡張を行うと、パーティションの拡張、および、ファイル システムの拡張が同時に行われますが、まれにファイル システムの拡張に失敗し、パーティション サイズとファイル システムが別の値になることがあります。この場合、エクスプローラーから参照するとボリュームの容量が増えていない状況となり使用可能な領域が増えません。パーティション上のファイル システムのサイズが拡張されていない状態を確認した場合には、diskpart ユーティリティからファイル システムの拡張を実施します。

=======================
ファイル システムの拡張方法
=======================

1. 管理者権限でコマンド プロンプトを起動します。
2. diskpart を起動します。
3. ボリュームをリストします。
   
   DISKPART> list volume
   
   
4. ボリュームを選択します。
   (X には 3. で確認したボリューム番号を指定します。)
   
   DISKPART> select volume X
   
   
5. ファイル システムを拡張します。
   
   DISKPART> extend filesystem
   
   
6. diskpart を終了します。
   
   DISKPART> exit

- 参考情報

Extend
http://technet.microsoft.com/ja-jp/library/cc770938(WS.10).aspx

--------------------
注意事項 1.
--------------------

ボリュームの拡張については、対象のディスクに連続する未割り当て領域がある場合に対応可能です。そのため、まず最初にディスクの管理コンソール (diskmgmt.msc) からディスクの構成を確認します。 物理環境で未割り当ての領域が無い場合には、注意事項 2. を参照してください。 なお、仮想環境の場合には未割り当て領域が無い場合でも、仮想ディスクの拡張後、対応することが可能です。

ボリュームを拡張する
http://technet.microsoft.com/ja-jp/library/cc771939.aspx

--------------------
注意事項 2.
--------------------

「図 2 - 拡張できない例」 のように対象のディスクに連続する未割り当て領域が無く、別のボリュームで該当領域を利用している場合には、必要に応じて別のディスクへの移行を実施してください。

いつも弊社製品をご利用いただきまして誠にありがとうございます。

Windows プラットフォームサポートの宮澤です。

OS 標準で搭載されている Windows Server バックアップを用いた"ベアメタル回復" や"システム状態" のバックアップについてはよく耳にされると思います。

今回は、そんな Windows Server バックアップのバックアップ項目にある Hyper-V Host Component についてご紹介させていただきます。

Hyper-V Host Component とは

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

Windows Server バックアップ (カスタム) から個別に選択しバックアップ取得が可能です。

Host Component には一部の Hyper-V の設定と仮想 SAN マネージャーの情報が含まれます。

Hyper-V Host Component バックアップと復元

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

 ■ Wbadmin コマンドで実行する場合は、以下のコマンドにて取得可能です。

 >wbadmin start backup -backuptarget:E: -hyperv:"Host Component"

 ■ Wbadmin get versions コマンドで取得された状態を確認します。

 >wbadmin get versions

バックアップ時間: 2015/03/12 18:59

バックアップ対象: 固定ディスクラベル付きボリューム(E:)

バージョン識別子: 03/12/2015-09:59

回復可能: ボリューム, ファイル, アプリケーション, 仮想マシン

スナップショット ID: {b40a17f6-c8ef-425d-8df2-a6326e58bc3b}

■ wbadmin get items コマンドで詳しい情報を確認します。

>wbadmin get items -version:03/12/2015-09:59

wbadmin 1.0 - バックアップコマンドラインツール

(C) Copyright 2013 Microsoft Corporation. All rights reserved.

ボリューム ID = {bc78a36a-a1dc-11e4-80b8-806e6f6e6963}

ボリューム''、C: にマウント

ボリューム サイズ = 74.16 GB

回復可能 = 選択されたファイル

アプリケーション = HyperV

VM 名: Host Component

VM キャプション: Host Component

VM 識別子: Host Component

合計サイズ: 50.51 KB KB

 ■ wbadmin start recovery コマンドで復元します。

 >wbadmin start recovery -version:03/12/2015-09:59 -itemtype:hyperv -items:"Host Component"

wbadmin 1.0 - バックアップコマンドラインツール

(C) Copyright 2013 Microsoft Corporation. All rights reserved.

警告: 別の場所に回復しようとしている仮想マシンが、このホストからバックアップされたものである場合、この操作により、元の仮想マシン (まだ存在する場合)は削除され上書きされます。

アプリケーション HyperV の回復を選択しました。

次のコンポーネントが回復されます:

警告: 回復後にネットワークの設定が異なっていると、仮想マシンが起動しない場合があります。回復が完了したら、起動する前に、Hyper-V マネージャーを使用して仮想マシンのネットワーク設定を確認してください。

VM 名: Host Component

VM キャプション: Host Component

VM 識別子: Host Component

アプリケーション HyperV を回復しますか?

[Y] はい [N] いいえ y

回復するコンポーネント Host Component を準備しています...

コンポーネント Host Component のファイルを回復中に、(0%) をコピーしました。

コンポーネント Host Component のファイルを回復中に、(100%) をコピーしました。

コンポーネント Host Component を回復しています。

コンポーネント Host Component が正常に回復されました。

回復操作が完了しました。

正常に回復されたファイルのログ:

C:\Windows\Logs\WindowsServerBackup\ApplicationRestore-12-03-2015_10-48-39.log

回復操作の概要:

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

コンポーネント Host Component が正常に回復されました。

※ Windows Server バックアップ GUI 画面からのもちろん操作も可能です。

Hyper-V Host Component で復元される内容

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

実際には以下のフォルダが復元されます。

C:\ProgramData\Microsoft\Windows\Hyper-V

└─InitialStore.xml

｜

└─Resource Types

       ├─4EA4F71F-16E6-4250-99A8-A2315332CC64.xml

       ├─06FF76FA-2D58-4BAF-9F8D-455773824F37.xml

       ├─6A45335D-4C3A-44B7-B61F-C9808BBDF8ED.xml

       ├─70BB60D2-A9D3-46AA-B654-3DE53004B4F8.xml

       ├─78AA0C27-B2BD-45BA-83D1-5F2A8C4C6656.xml

       ├─118C3BE5-0D31-4804-85F0-5C6074ABEA8F.xml

       ├─146C56A0-3546-469B-9737-FCBCF82428F4.xml

       ├─353B3BE8-310C-4CF4-839E-4E1B14616136.xml

       ├─7951A5ED-8DC5-42D7-AA8C-9F14C54CEB84.xml

       ├─19839BFF-6F04-4B24-B4B5-1AFCCBE729DE.xml

       ├─72027ECE-E44A-446E-AF2B-8D8C4B8A2279.xml

       ├─4764334E-E001-4176-82EE-5594EC9B530E.xml

       ├─B637F347-6A0E-4DEC-AF52-BD70CB80A21D.xml

       ├─BDE5D4D6-E450-46D2-B925-976CA3E989B4.xml

       ├─D92D268E-9AA8-49DD-8C7D-821CEFB5F597.xml

       ├─D45268DA-37C5-44DA-B827-B0C55CCB3BDC.xml

       ├─DACDCF3F-6F67-4EB8-A4D0-5D93B48A2468.xml

       └─F6293891-F32F-4930-B2DB-1A8961D9CB75.xml

Hyper-V マネージャーで設定された SAN接続や Ethernet の構成、ライブマイグレーションなど多くの設定は、ホスト側や他のサーバーへも影響があるため、レジストリなどへ保存されます。

Host Compornet のみを復元した場合、Hyper-V マネージャー上の各項目に復元される内容は以下の3 項目のため、Hyper-V マネージャー上の設定を復元する場合は、Host Compornet と併せてシステム状態も復元の実行をお願いいたします。

または、"ベアメタル回復" での復元をご検討ください。

■Hyper-V Host Component のみで復元される Hyper-V マネージャ上の項目

 ・ Hyper-V の設定> [物理GPU] 内の [この GPU を RemoteFX で使用する]

    ※ ホストサーバーへ 3D グラフィックス等 GPU 対応のグラフィック カード搭載時のみ

・ Hyper-V の設定> [記憶域の移行] 内の [記憶域の同時移行] の数

・ 仮想 SAN マネージャー> [仮想ファイバーチャネル SAN] の名前

いつも弊社製品をご利用いただきまして誠にありがとうございます。

Windows プラットフォームサポートの宮澤です。

今回は、Azure Backup で使用されている暗号化方式などについてご案内いたします。

Azure Backup の暗号化について

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

Azure Backup ではバックアップ実行の際に、コンテナー資格情報もしくは条件を満たした自己証明書をご用意いただく必要があります。

この証明書を使用し、データの暗号化を行います。

2015 年 4 月時点、コンテナー資格情報の証明書はSHA-1 (SHA128) を使用しています。

※サムプリント アルゴリズムについては SHA-1 のみですが、署名アルゴリズムについては、SHA-256 も対応しております。

- 参考資料

コンテナーの証明書の管理 -コンテナーの証明書の要件

https://msdn.microsoft.com/ja-jp/library/dn169036.aspx

Azureへの接続の際に使用される SSL/TLS についての暗号化方式、Cipher Suitesの優先度については、ご使用のサーバーもしくは接続するクライアントよりご確認ください。

==========

確認方法

==========

1. コマンド プロンプトで、gpedit.mscと入力し、[OK] をクリックし、ローカル グループ ポリシー エディターを起動します。

2. [コンピューターの構成] を展開し、[管理用テンプレート] を展開し、[ネットワーク] を展開および [SSL 構成の設定] をクリックします。

3. [設定] ウィンドウで、[SSL 暗号の順位] を右クリックし、[編集] から設定内容を確認ください。

 ※状況"未構成" となっている場合でもリストの上位から使用可能な暗号化が適用されます。

その他、Azure Backup では データを暗号化する際にパス フレーズを指定します。

パスフレーズは、ユーザーが指定するか、[パスフレーズの生成] をクリックして生成することができます。

このパス フレーズを紛失すると、データの復元や復旧がまったくできなくなります。

パス フレーズ設定の際は、紛失しないよう外部に保管することをお勧めいたします。

パス フレーズは Azure Backup インストール時に設定を行います。

設定後に変更する場合は、Azure Backup のプロパティ - [暗号化] タブより指定可能です。

Azure Backupにて [データの回復] から [別のサーバー] を選択して回復を実行した場合、設定したパスフレーズを求められます。

- 参考資料

コンテナーの証明書の管理 -コンテナーの証明書の要件

https://msdn.microsoft.com/ja-jp/library/dn169036.aspx

サービスと証明書の関連付け

https://msdn.microsoft.com/ja-jp/library/gg465718.aspx

Cipher Suites in Schannel

https://msdn.microsoft.com/en-us/library/windows/desktop/aa374757(v=vs.85).aspx

Azure Backup の利用を始める

http://blogs.msdn.com/b/windowsazurej/archive/2014/10/01/blog-getting-started-with-azure-backup.aspx

こんにちは！Windows プラットフォーム サポートの河野 (コウノ) です。

Windows Server 2012 R2 または Windows 8.1 の環境で KMS ホストを構築した場合、

電話でライセンス認証を行う際、以下の事象が報告されております。

slui.exe 4 コマンドで電話によるライセンス認証のウィザード画面を表示させようとしても、

[電話による Windows のライセンス認証はできません] とのメッセージが表示され、

電話によるライセンス認証のウィザード画面は表示されません。

この場合、以下のコマンドによる電話認証の手順をお試しください。

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

1. コマンド プロンプトを管理者権限で開きます。

2. 以下のコマンドを実行し、OS のインストール ID を確認します。

   cscript %WinDir%\system32\slmgr.vbs /dlv

※ この後の手順でインストール ID を使用します。

   メモ帳などのテキスト エディターにコピーし、

   以下のように 6 桁毎に区切っておいていただくことをお勧めいたします。

(例)

xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx

3. マイクロソフトのライセンス認証窓口 (0120-801-734) に電話をかけていただき、

   電話の音声ガイダンスに従って、手順 2 で確認したインストール ID を

   電話機で入力します。

4. 電話の音声ガイダンスに従って操作し、OS 認証用の確認 ID を書き留めます。

※ この後の手順で確認 ID (48 桁) を使用します。

   いったん、メモ帳などのテキスト エディターに入力しておいていただく

   ことをお勧めいたします。6 桁毎の区切り文字は不要です。

(例)

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

5. 以下のコマンドを実行し、指定した確認 ID を使用して

    ライセンス認証を行います。

   cscript %WinDir%\system32\slmgr.vbs /atp <確認 ID>

※ <確認 ID> には、手順 4 で取得した確認 ID を入力します。

(例)

cscript %WinDir%\system32\slmgr.vbs /atp xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

上記コマンドが正しく実行されると、確認 ID が正常に登録された旨の

メッセージが表示されます。

6. 以下のコマンドを実行し、KMS ホスト キーが正しくインストールされ、

   ライセンス認証されているかどうかを確認します。

   "ライセンスの状態" が "ライセンスされています" と表示されていれば

   問題ございません。

  cscript %WinDir%\system32\slmgr.vbs /dlv

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

こんにちは。Windows プラットフォーム サポートの加藤です。
本日は、クラスター化したファイルサーバー (Windows Server 2012 以降) に別名 (CNAME) でアクセスする方法についてご紹介します。

Windows Server 2003 以前のクラスター サービスでは、仮想サーバー名や、物理サーバー名をブラウズした場合、ローカルおよびクラスター化されているすべてのファイル共有が区別なく表示され、アクセスが可能でした。
Windows Server 2008 と Windows Server 2008 R2 のクラスターではセキュリティ強化の観点から、ファイル シェア スコーピングが導入され、クラスターのファイル共有をリクエストしているのか、ローカルのファイル共有をリクエストしているのかを判断して、表示、アクセス制御が行われるようになり、IP アドレスや DNS の CNAME レコード (エイリアス) を使用したファイル サーバーへのアクセスができなくなっていました。

WSFC: ファイル シェア スコーピングについて
http://blogs.technet.com/b/askcorejp/archive/2010/06/09/windows-server-failover-clustering.aspx

Windows Server 2012 以降のクラスターでは、ファイル シェア スコーピングの動作が変更されセキュリティを維持しつつ、以前のクラスターでは、実現できなかった、IP アドレスと DNS の CNAME レコード (エイリアス) を使用したファイル サーバーへのアクセスが可能になりました。
IP アドレスを使用したアクセスは追加の設定は不要でございますが、CNAME レコード (エイリアス) を使用する場合には、以下の設定を実施します。

- 設定手順
1. DNS サーバー上に CNAME レコード (エイリアス) を作成します。
2. ファイルサーバーで使用しているネットワーク名リソースのプロパティ "Aliases" に CNAME レコードで設定したエイリアスを設定します。
  (1) 以下の PowerShell コマンドレットを管理者権限で実行し、ネットワーク名リソースのプロパティ “Aliases” に現在設定されているエイリアスを確認をします。
  ※ “Aliases”が未設定の場合、Value の値が空欄になっています。

    > Get-ClusterResource  "ネットワーク名リソース名" | Get-ClusterParameter Aliases

  (2) ネットワーク名リソースのプロパティ “Aliases”に CNAME レコードで設定したエイリアスを設定します。

    > Get-ClusterResource  "ネットワーク名リソース名" | Set-ClusterParameter Aliases "エイリアス"

  (3) ネットワーク名リソースを一旦オフラインにし、再度オンラインにします。

  (4) エイリアスでファイル共有へアクセスが可能です。

------------------------------------------------------------------------------
<補足情報> 登録したエイリアス (CNAME) を削除するためのコマンドレット
-------------------------------------------------------------------------------
PS C:\> Get-ClusterResource  "ネットワーク名リソース名" | Set-ClusterParameter Aliases

コマンド実行後は、ネットワーク名リソースを一度、オフラインにした上で再度オンラインを実施ください。

- 参考
How to Configure an Alias for a Clustered SMB Share with Windows Server 2012
http://blogs.msdn.com/b/clustering/archive/2012/04/08/10291792.aspx

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

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

日々のサポート業務の中で、お問い合わせを頂く内容についてご紹介します。

Windows Server 2012 および Windows Server 2012 R2 においては ”ドレイン” という機能が追加されており、クラスター環境のメンテナンスがより容易になりました。メンテナンスの参考としまして、クラスターで修正プログラムを適用する手順を以下にご紹介いたします。

- 修正プログラムの適用手順

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

以下 2 ノード クラスター (ノード A および B) を想定した手順をご案内いたします。

1. システムのイベント ログを確認し、エラーが発生していないかどうか、およびシステムが正常に動作しているかどうかを確認します。 

2. 各システムについて最新のバックアップがあることを確認します。ファイルの破損、電源障害、または互換性の問題が発生した場合は、修正プログラムのインストールを実行する前のシステムの状態に戻す必要が生じることがあります。

3. [フェールオーバー クラスター マネージャー] を開き、左ペインより [ノード] クリックし、中央画面より [ノード A] を右クリックし、[一時停止] - [役割のドレイン] をクリックします。すべてのグループがノード B に移動されます。

4. ノード A に修正プログラムをインストールしコンピューターを再起動します。

5. システムのイベント ログを調べて、エラーが発生していないかどうかを確認します。エラーが発生している場合は、そのエラーを解決してから、この手順を続行します。

6. フェールオーバー クラスター マネージャーで [ノード A] をクリックし、[再開] - [役割のフェールバック] をクリックします。移動したグループが既定の所有者 (ノード A) に戻ります。

7. フェールオーバー クラスター マネージャーで [ノード B] をクリックし、[一時停止] - [役割のドレイン] をクリックします。

8. ノード B に修正プログラムをインストールし、コンピューターを再起動します。

9. システムのイベント ログを調べて、エラーが発生していないかどうかを確認します。エラーが発生している場合は、そのエラーを解決してから、この手順を続行します。

10. フェールオーバー クラスター マネージャーで [ノード B] をクリックし、[再開] - [役割のフェールバック] をクリックします。移動したグループが既定の所有者 (ノード B) に戻ります。

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

Windows Server 2008 および Windows Server 2008 R2 の環境での修正プログラムの適用手順においては、以下の URL をご参照ください。

参考: クラスター環境に適用を推奨する修正プログラムについて

http://blogs.technet.com/b/askcorejp/archive/2012/08/16/3514648.aspx

 また以下にノードのドレインについて簡単にご紹介させていただきます。

- ドレインの機能について

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

ドレインとは、クラスター化された役割をノード間で移動させ、少ないダウンタイムで役割を実行するノードを変更する際に使用します。

・ノードをメンテナンス モードにしたり、ノードにその他の変更を加えたりする前に自動的にノードのドレインが行われます (ノードで実行されているクラスター化された役割が別のノードに移動されます)。

・メンテナンス操作が完了すると役割は元のノードにフェールバックします。

・管理者は、1 度の操作で (クラスター マネージャー内での操作、もしくは PowerShell コマンド “Suspend-ClusterNode“) ノードのドレインを実行できます。またドレインの操作ではクラスター化された役割の移動先のノードも指定できます。

・クラスター対応更新では、クラスター ノードにソフトウェア更新プログラムを適用する自動プロセスでノード ドレインが使われます。

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

本日は、最近お問い合わせのあった Windows Server 2012 のフェールオーバー クラスター環境でフェールオーバー クラスター マネージャーを終了した際にクラッシュが発生する事象についてご紹介します。


[現象]
以下のような状況で問題が発生します。
・Windows Server 2012 を使用している
・フェールオーバー クラスター を構成している
・フェールオーバー クラスター マネージャーをクローズ ボタン ([×] ボタン) で閉じる

上記のシナリオでは管理コンソールがクラッシュし動作を停止した旨を示すポップアップが表示されることがあります。

[原因]
本現象は「ウインドウのクローズ ボタンが押下された際に Windows OS が行うウインドウ破棄の処理」と 「MMC スナップインが利用している Windows Presentation Foundation (WPF) および .NET Framework のファイナライザー」の実行タイミングに起因して発生する事象です。

ウインドウのクローズ ボタンが押下されると、クローズ ボタンのアニメーション効果を実行するため、特別なウインドウ メッセージが OS から送信されます。通常は、本メッセージを Windows のテーマ機能が受信し、アニメーション効果の処理を実行します。
しかし、本現象の発生時には一連の動作が Windows Presentation Foundation (WPF) および .NET Framework のファイナライザーがオブジェクトを破棄するタイミングで実行されております。この実行タイミングが重なることによって、予期しない動作となり問題が発生します。

[対処について]
本現象は終了時の問題となり、フェールオーバー クラスター マネージャーで処理した内容やクラスター上のデータに影響はございません。
終了時に本現象が発生した場合には、エラーを無視してください。


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

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

日々のサポート業務の中で、お問い合わせを頂く内容についてご紹介します。

Windows Server 2012 および Windows Server 2012 R2 における、仮想マシンの高可用性の構成方法についてご案内いたします。

Hyper-V マネージャーを使って作成、移動、インポートした仮想マシンを、フェールオーバー クラスター マネージャーを使って高可用性構成にすることができます。仮想マシンを新規で構成する際には、フェールオーバー クラスター マネージャーの [役割] を右クリックし [仮想マシン] を選択する事で進める事が可能ですが、既に Hyper-V 上に存在する場合には、[仮想マシン] の項目からではなく [役割の構成] から進める必要がございます。

既に Hyper-V 上に存在する仮想マシンを構成する際には、手順がわかり辛い可能性がありましたので、以下の手順をご紹介させていただきます。

- 事前設定
対象の仮想マシンをクラスターで使用可能なディスク上 (CSV、パススルー・ディスク、Hyper-V 仮想ファイバー チャネルの記憶域) に配置します。

- 手順
1．フェールオーバー クラスター マネージャーを起動します。
2．左ペインより [役割] を右クリックし [役割の構成] をクリックします。
3．“開始する前に” 画面で [次へ] をクリックします。
4．“役割の選択” 画面より “仮想マシン” を選択し [次へ] をクリックします。
5．“仮想マシンの選択” 画面より対象となる仮想マシンのチェック ボックスを有効にし [次へ] をクリックします。
6．“確認” 画面で再度内容を確認し [次へ] をクリックします。“高可用性の構成” 画面で暫く待ちます。
7．“概要” 画面で正常に処理が終了している事を確認し [完了] をクリックします。

以上で仮想マシンをクラスターに登録する手順は終了です。

- 参考
タイトル: Windows Server 2012 でのフェールオーバー クラスタリングの新機能
https://technet.microsoft.com/ja-jp/library/hh831414.aspx#BKMK_CSVS
参考箇所: クラスターの共有ボリューム

タイトル: Hyper-V 仮想ファイバー チャネルの概要
https://technet.microsoft.com/ja-jp/library/hh831413.aspx

タイトル: クラスターでの Hyper-V と仮想マシンについて
https://technet.microsoft.com/ja-jp/library/dd759249.aspx

タイトル: Hyper-V のクラスター構成における、仮想マシンの設定変更における注意事項
http://blogs.technet.com/b/askcorejp/archive/2012/12/12/tewst.aspx

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

クラスター構築時に利用した管理者アカウントのパスワードを変更した場合の
影響についてご紹介します。

結論から申しますと、Windows Server 2008 以降でクラスター構築時に利用した
管理者アカウント（ドメイン ユーザー アカウント）のパスワードを変更しても
クラスターの動作に影響はございません。

Windows Server 2008 以降、クラスター サービスの起動にはローカル システム
アカウントが利用されるようになっております。
また、フェールオーバー クラスターが、ドメインの認証を必要とする場合は
クラスター名オブジェクト (CNO) が利用されるようになっております。
（CNO はフェールオーバー クラスターの最初の作成時に Active Directory の
  Computers コンテナーに既定では作成されるコンピューター オブジェクトです。）

Windows Server 2003 では、クラスターの起動にドメイン ユーザー アカウントが
利用されておりましたが、Windows Server 2008 以降、クラスターを起動させる際に、
ドメイン ユーザー アカウントは利用されなくなりました。
（Windows Server 2008 以降でも、クラスター構築時に CNO の作成には
  ドメイン ユーザー アカウントが利用されますが、それ以降のクラスターの
  稼働には利用されません。）

そのため、クラスターの構築時に利用した
管理者アカウント（ドメイン ユーザー アカウント）のパスワードを
変更してもクラスターの動作には影響はございません。

参考情報：
Description of the failover cluster security model in Windows Server 2008
https://support.microsoft.com/en-us/kb/947049/en-us

Introducing Windows Server 2008 Failover Clustering
https://technet.microsoft.com/en-us/magazine/2008.07.failover.aspx
※「 Enhanced Security Features 」をご参照ください

Active Directory ドメイン サービスでクラスター コンピューター オブジェクトをプレステージする
https://technet.microsoft.com/ja-jp/library/dn466519.aspx

みなさん、こんにちは。

Windows プラット フォーム サポートの小堀です。

暑い日が多くなり、夏が近づきつつあることを実感することが多くなってきました。

さて、夏と言えば Windows 10 のリリースは、2015 年 7 月 29 日、盛夏の時期を予定しております。
リリースが近づくにつれて、Windows 10 に関する様々なご質問をいただくようになってきています。

Windows 10 のリリースと同時に、たくさんのユーザーの皆様に Windows 10 という新しい Windows を体験していただくため、一部のエディションを除く Windows 7 SP1 、Windows 8.1 環境から Windows Update を通じて無償アップグレードを行うことができるようになります。
この無償アップグレードの予約が 6 月 1 日から通知領域に表示されたアイコン (Get Windows 10 アプリ) や、Windows Update 画面から簡単に行うことができるようになっています。

今回はこの無償アップグレードを予約する方法についてご紹介させていただきます。

※ ビジネスユースのお客様で、計画的に、Windows 10 を導入するために、このアイコンを表示させないようにしたいとのお問い合わせもいただいております。
   この表示させない方法についても補足情報として後述しております。

(1) 通知領域の Get Windows 10 アプリ から予約する方法

いつの間にか通知領域に見慣れない以下の Windows ロゴ アイコンが表示されて、驚かれた方も多いのではないでしょうか。

このアイコンが Get Windows 10 アプリ アイコンです。
※ Windows Update から配信されている更新プログラム KB3035583 をインストールすることによって追加されます。

Get Windows 10 アプリ アイコンをクリックすると、以下の "無料アップグレードの手順" 画面が表示されます。

この "無料アップグレードの手順" 画面で、[無料アップグレードの予約] ボタンをクリックすると、すぐに予約処理が始まります。

予約処理が完了すると、以下の "アップグレードが予約されています" 画面が表示されます。

アップグレードに関する通知が必要な場合には、ここでメールアドレスを入力して [確認の送信] をクリックします。

メールによる確認が必要ない場合には、[電子メールによる確認をスキップする] をクリックします。

以下の “完了しました” 画面が表示されましたら、これで予約は完了です。

ちなみに、通知領域の Get Windows 10 アプリ アイコンを右クリックすると、以下の 4 つのメニューが表示されます。

[Windows 10 を入手する] をクリックすると上記の "無料アップグレードの手順" 画面が表示されますが、[無償アップグレードを予約する] をクリックすると、すぐに予約処理が始まり、"アップグレードが予約されています" 画面へと進むことができます。

なお、アップグレードの予約が完了した環境で Get Windows 10 アプリ アイコンを右クリックすると、[無償アップグレードを予約する] メニューが [アップグレードのステータスを確認する] に変更されており、現在のアップグレードのステータスを確認することができます。
また、 [Windows 10 の詳細を確認する] をクリックすると、Window10 に関する Q&A Web ページが表示されますので、予約した後にこちらもご確認ください。

(2) Windows Update 画面から予約する方法

Windows Update で配信されております、重要な更新プログラムがすべてインストールされている環境では、
更新プログラムの確認後に、以下の画面が表示され、ここからも予約を行うことができます。

ここで、[予約] ボタンをクリックするとすぐに予約処理が実施され、上述の “完了しました” 画面が表示されます。

補足情報 - Get Windows 10 アプリ アイコンを表示させない方法

以下のレジストリを設定いただくことにより、KB3035583 がインストールされた環境におきましても、通知領域の Get Windows 10 アプリ アイコンからの通知を停止することが可能となります。

キー : HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Gwx
名前 : DisableGwx
種類 : REG_DWORD
値 :  1

※ 上記レジストリを設定しても Windows Update 画面の予約画面は表示されることに、ご留意ください。

コマンドにて設定いただく場合には管理者権限で以下の reg から /f までの一行のコマンドを実行することで設定いただくことが可能です。

reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Gwx /v "DisableGwx" /t REG_DWORD /d 00000001 /f

※ Windows 10 への無償アップグレードは Windows Update を通じて行われる予定です。
※ 今後、すでに上述の予約を行われてしまった環境でも、Windows Update を通じてのWindows 10 へのアップグレードをブロックする方法をご提供する予定です。
※ この方法につきましては、後日、本記事を更新することで公開させていただきます。

そのほかにも、Windows 10 への無償アップグレードの予約に関しては、以下の Windows 10 Q&A サイトにも取りまとめられておりますので、こちらもご確認いただけますと幸いです。
http://www.microsoft.com/ja-jp/windows/windows-10-faq?ocid=win10_auxapp_context

夏に向けての季節の代わり目ですが、皆様も、体調を崩されないようご自愛ください。

こんにちは。Windows プラットフォーム サポートの加藤です。
本日は、Hyper-V フェールオーバー クラスターの環境で、仮想マシンの移動後に、移動元のノードに仮想マシンの情報が残ってしまう事象の回避策をご案内します。
※ [移動] = ライブ、クイック マイグレーションとフェールオーバーを含む所有者変更を指します。

Hyper-V フェールオーバー クラスターの環境で、仮想マシンの移動後に、移動元のノードに情報が残ってしまい、移動元の Hyper-V マネージャーと、移動先の Hyper-V マネージャーの両方に同じ仮想マシンが表示される場合がございます。

また、この問題が発生すると、仮想マシンの情報が二つのノードで重複して表示される以外に、以下の事象が発生する場合もございます。

1. ライブ マイグレーションやクイック マイグレーションを実行すると [時間がかかっています] と表示され、完了しない。
2. 仮想マシンを最新の情報に更新をしても同様に [時間がかかっています] と表示され、正常に完了しない。
3. すべてのノードの Hyper-Vマネージャーで仮想マシンが表示されなくなる。
※ この時、移動元のノードのクラスター サービスを停止すると、移動元の Hyper-V マネージャーと、移動先の Hyper-V マネージャーの両方に同じ仮想マシンが表示されることが確認できます。

通常であれば、移動元のノードからは、情報が削除されるため、両方のノードで表示されることはございません。
表示されるのは、仮想マシン リソースのオーナーノードのみです。

しかしながら、何らかの原因で情報が残ってしまった場合には、両ノードで表示されてしまいます。
上記状態に陥ってしまった場合には、以下の手順で復旧可能です。

以下の手順は移動元のノードで実施します。

1. まず、ノード上に不要な情報が残っているか確認します。
---------------------------------------------------------
当該ノード上に仮想マシン リソースがすでに存在していない (他のノード上に存在している) にもかかわらず、
以下のフォルダに XML ファイル (ファイル名：＜VmID＞.XML) が存在する場合は、情報が残っています。

----------------------------
"C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines Cache"
"C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines"
----------------------------

ファイル名例:
00866BD3-E68F-4724-B891-82048BD0D60C.xml
※ 00866BD3-E68F-4724-B891-82048BD0D60C は VmID です。

そのため、当該ノード上の上記のフォルダを確認していただき、＜VmID＞.XML ファイルが存在していましたら後述の手順で削除をお願いいたします。
※ 削除前に Cluster Service と Hyper-V Virtual Machine Management の停止を実施します。

- 参考
VmID は以下の手順で確認可能です。

Windows Server 2008 R2 以前
----------------------------
1) 管理者権限のコマンド プロンプトを起動します。
2) 以下のコマンドを実行します。
> cluster res "＜重複している仮想マシンの仮想マシン構成リソース名＞" /priv:vmid
※ 仮想マシン リソース名ではありません。

例：
cluster res "仮想マシン構成 test" /priv:vmid

'仮想マシン構成 test' のプライベート プロパティの一覧を作成しています:

T  リソース             名前                           値
-- -------------------- ------------------------------ -----------------------
S  仮想マシン構成 test  VmID                           3766b456-94d4-46b8-9e4d-95255841eb96
--------------

Windows Server 2012 以降
----------------------------
1) 管理者権限で PowerShell を起動します。
2) 以下のコマンド レットを実行します。

Get-ClusterResource "＜重複している仮想マシンの仮想マシン構成リソース名＞" | Get-ClusterParameter vmid | FL

例：
Get-ClusterResource "仮想マシン構成 test" | Get-ClusterParameter vmid | FL

Name          : VmID
IsReadOnly    : False
ParameterType : String
Value         : cc80876e-15e8-47b1-a81c-423c2c4f6936

2. 次に残っている情報を削除します。
---------------------------------------------------------
1) [スタート] - [ファイル名を指定して実行] をクリックします。
2) services.msc と入力し [OK] をクリックします。
3) サービス コンソールが開きますので Cluster Service を右クリックし、"停止" を実行します。
4) Hyper-V Virtual Machine Management をダブルクリックします。
5) [スタートアップの種類] を [無効] に変更し、[適用] をクリックします。
6) [停止] をクリックして、サービスを停止します。
7) 残存している XML ファイルを削除します。
8) Hyper-V Virtual Machine Management の [スタートアップの種類] を [自動] に変更し、[適用] をクリックします。
9) [開始] をクリックして、サービスを開始します。
10) Cluster 右クリックし、"開始" を実行します。

削除完了後に、他の問題も解消されるか確認をお願いいたします。

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

Windows プラットフォーム サポートの宇田です。

今回は、Microsoft Azure 上の仮想マシン (IaaS) にリモートデスクトップ接続が行えない症状のよくある例と、対象方法などをご紹介できればと思います。

RDP は Azure VM の生命線といっても過言ではありませんので、皆様一度は何かしら体験されているのではないでしょうか。ただ、一言で「リモートデスクトップ接続が出来ない」といっても、実際には様々な要因があり、エラー メッセージや対処方法もそれぞれの状況によって異なります。

この為、まずは発生した事象を正確に把握する事が解決には重要となります。

1. よくある症状と対処策

[症状 1.]
リモート デスクトップはリモート コンピューターに接続できません。次のいずれかが原因です。

1) サーバーへのリモート アクセスが有効にされていない
2) リモート コンピューターの電源が入っていない
3) リモート コンピューターがネットワークで使用できない

リモート コンピューターの電源が入っていること、ネットワークに接続されていること、リモート アクセスが有効になっていることを確認してください。

このメッセージが出て、認証が求められない場合には、メッセージの通りそもそもOS が起動していない場合や、ネットワーク接続に問題がある場合が考えられます。また、仮想マシンを誤ってセーフモードで起動したり、OS 起動に至らず、前回の予期せぬ再起動などの影響を受けて、スタートアップ修復が起動していたりする場合にも本メッセージが表示されます。

対処法は、状況により様々ですので、後述の切り分けを実施してください。

[症状 2.]
ライセンスを提供するためのターミナル サーバー ライセンス サーバーがないため、リモート セッションは切断されました。サーバー管理者に問い合わせてください。
ライセンスを提供するためのリモート デスクトップ ライセンス サーバがないため、リモートセッションは切断されました。

リモート デスクトップの RD セッションホストの役割サービスを追加後、ライセンス サーバーの構築・設定を行わずに、猶予期間 (120 日) が経過すると本メッセージが表示されます。また、それ以前からログオン後にポップアップで残りの日数が表示されているのではないかと思います。

Windows Server では同時に 2 名までが管理接続の為にリモート デスクトップ接続を行う事が可能であり、多くのユーザーが同時にログオンするようなターミナル サーバーやリモート デスクトップ サーバーとしての利用でない限り (3 人以上が同時接続しない限り) リモート デスクトップ サービスの役割を追加する必要はありません。誤って役割を追加してしまった場合などにおいては、本役割を削除する事で本現象が改善します。

なお、このメッセージが表示されている場合であっても、管理接続 (mstsc /admin) での接続は可能です。Azure 管理ポータルから RDP ファイルをダウンロードして接続するのではなく、クライアント コンピューターから、[ファイル名を指定して実行] -> “mstsc /admin” としてリモート デスクトップ接続を起動する事で管理接続を行い、役割の削除を実施してください。

(参考)
リモート デスクトップ サービス接続を削除するリモート デスクトップ ライセンス役割サービスをアンインストールする
https://technet.microsoft.com/ja-jp/library/cc754247.aspx

[症状 3.]
お使いの資格情報は機能しませんでした。(パスワードの再入力要求)

メッセージの通り、パスワードを間違って入力した場合 (ないし忘れた場合) に表示されます。こちらは、ゲスト エージェントが導入済みであれば (既定でチェックされているので、大半の方は導入されています) PowerShell 等からリモートでパスワード リセットが可能です。

具体的な手順などは、以下に記載がありますので、ご参考に頂ければと思います。

(参考)
「Azure仮想マシンにログオンできない！」という悲劇からの生還
http://blogs.technet.com/b/ksasaki/archive/2014/03/21/enable-rdp-or-reset-password.aspx

2. 原因個所の特定

上記の対処で改善しない場合、原因が仮想マシン内の問題なのか、ネットワーク等のインフラ側にあるのかを切り分ける必要があります。簡単にですが、いくつかのパターンをまとめてみましたので、一時切り分けの参考にご利用ください。(拡大してご覧ください。)

それぞれのパターンでの対処手順は以下の通りです。

パターン 1.

すでに上でも書いている通り、ゲストエージェント の VMAccessAgent 拡張を利用してパスワード リセットを行います。詳細は以下をご覧ください。

(参考)
「Azure仮想マシンにログオンできない！」という悲劇からの生還
http://blogs.technet.com/b/ksasaki/archive/2014/03/21/enable-rdp-or-reset-password.aspx

パターン 2.
この場合にありがちな原因として、仮想マシン内で NIC に対して IP や DNS の設定を行っている場合がありますが、これは Azure のお作法的に NG となります。

Azure では手動での再起動や、ホストのメンテナンス等の際に、仮想マシンがホストされている物理サーバーが変わる場合があり、この際に異なる NIC に差し替わったと仮想マシン内では認識されるためです。この場合、仮想マシンとしては Azure の DHCP サーバーから割り振られた設定に戻ってしまいますので、設定済みの DNS サーバーの参照設定が無くなり、DC へ通信できずに認証エラーが発生します。

この為、Azure で DNS の指定を行う場合には、Azure の仮想ネットワーク (VNET) にて、DNS サーバーの指定を行う必要があります。また、IP を固定したい場合には、Reserved IP という Azure で用意された機能を利用してください。

以下のように [仮想ネットワーク] -> [構成] にて、dns サーバーを指定します。

(参考)
VM 用の静的内部 IP アドレスを設定する
https://msdn.microsoft.com/ja-jp/library/azure/dn630228.aspx

パターン 3.
こちらの症状の場合には、3389 のポートが LISTEN していない場合や、Firewall でブロックされているといった、通信の問題の場合が考えられます。単純に リモートデスクトップ 接続を OS の設定で禁止してしまった場合などは、先にも紹介した VMAccessAgent で修復が可能です。

一方、アンチウイルス製品をインストールしたら通信できなくなった (3389 がブロックされた) などの場合、残念ながら有効な対処策がありません。残念ですが、VHD ファイルをダウンロードして頂き (注: Azure データセンターから出ていくデータには課金が発生します。)ローカルの Hyper-V 環境などでポート 3389 を解放してから、再度アップロードして起動しなおしてください。

VHD のダウンロード・アップロードは、AzCopy や Azure PowerShell、各種ストレージ エクスプローラをご利用ください。

(参考)
AzCopy コマンド ライン ユーティリティの概要
http://azure.microsoft.com/ja-jp/documentation/articles/storage-use-azcopy/

Windows Server VHD の作成と Azure へのアップロード
http://azure.microsoft.com/ja-jp/documentation/articles/virtual-machines-create-upload-vhd-windows-server/

Windows Azure Storage Explorers (2014)
http://blogs.msdn.com/b/windowsazurestorage/archive/2014/03/11/windows-azure-storage-explorers-2014.aspx

また、リモート デスクトップの機能のみがハングしていたり、正常に動作していなかったりという場合も考えられますので、管理ポータルから仮想マシンの再起動を行って改善されるかもあわせてご確認下さい。

パターン 4.
Ping にすら応答しない場合には、OS 自体がハングアップしているか、仮想マシン内のネットワーク周りで問題が生じている可能性が高いかと思われます。一旦、管理ポータルから仮想マシンを再起動して改善されるかを確認してください。

Azure 外や、Azure 内の異なる仮想ネットワーク (ないしクラウド サービス) 上からの Ping (ICMP) は応答しませんので、必ず同一仮想ネットワーク内の他の仮想マシンから Ping に応答があるかを確認してください。

パターン 5.
複数の仮想マシンに接続できない等の場合、ネットワーク接続全体に何らかの問題が生じている可能性が疑われます。エンタープライズでご利用の場合には、S2S の VPN や Express Route などの形態で接続されている場合もあるかと思いますので、設定等を改めてご確認頂ければと思います。(ネットワークの場合には要因が様々考えられますので、全てを網羅できないため今回は割愛させて頂きます。)

パターン 6.
仮想マシンがそもそも起動できない場合には、CPU のクォータ制限 (デフォルトでは 20 コア等となっています。) を超過していないかをご確認下さい。なお、CPU に限らず Azure の各種クォータはサポートにご連絡頂ければ上限の引き上げが可能です。

詳しくは Azure サポートチームのブログをご覧ください。

(参考)
Microsoft Azure のクォータ増加について
http://blogs.msdn.com/b/dsazurejp/archive/2013/10/22/windows-azure-quota-increase.aspx

例: クォータが 20 コアの場合
4 コアの仮想マシンを既に 4 台起動している状態で、8 コアの仮想マシンを起動しようとした場合には、合計で 4x4 + 8 = 24 コアとなりますので、起動できません。

以上が、Azure 上の仮想マシンに リモートデスクトップ接続できない場合のよくある原因と対処策になります。
上記のパターンで対処が出来ない場合、以下のページでもトラブルシューティングに役立つ情報がまとまっていますので、こちらもあわせてご確認下さい。

Windows ベースの Azure 仮想マシンへのリモート デスクトップ接続に関するトラブルシューティング
https://azure.microsoft.com/ja-jp/documentation/articles/virtual-machines-troubleshoot-remote-desktop-connections/

リモート デスクトップ接続がある日突然出来るなくなる現象は、Azure をご利用の皆様が、日々多く直面する問題だと思いますので、少しでも解決のお役に立てば幸いです。

こんにちは、Windows サポートの小堀です。
 
猛暑が続いていますが、皆様いかがお過ごしでしょうか。
さて、ついに Windows 10 のリリースまであと 一週間を切りました！
 
みなさま Windows 10 のアップグレード準備はお済みでしょうか？
リリースが近づくにつれて Windows 10 に関するご質問を耳にするようになってきています。

是非Windows 10 をご利用頂きたいと思いますが、ビジネスユースの場合にはご利用頂くにあたり、アプリケーションの動作確認など管理上のご確認が必要とのお声を頂いております。
そのため、今回はWindows Update を経由した、Windows 10 への無償アップグレードを抑止する方法をご紹介いたします。
Windows 10 をご利用頂くにあたっての検証などがお済みになるまでの間、ご活用頂けますと幸いです。

※ Windows Update を利用した Windows 10 の無償アップグレードを予約する方法については以下のブログ記事をご覧ください。

Title: Windows Update からの Windows 10 へのアップグレードを予約する
URL: http://blogs.technet.com/b/askcorejp/archive/2015/07/23/windows-update-windows-10.aspx

Windows 10 への無償アップグレードを抑止する方法
 
事前準備
----------
現在 Windows Update にて配信を行っております、以下の更新プログラムを抑止したい環境にインストールし、後述の実施手順をご利用頂くことで、Windows Update 経由でのWindows 10 のダウンロードおよびインストールを抑止することができます。
 
Windows 7 SP1
 Title: Windows Update Client for Windows 7 and Windows Server 2008 R2: July 2015
 URL: https://support.microsoft.com/en-us/kb/3065987
 
Windows 8.1
 Title: Windows Update Client for Windows 8.1 and Windows Server 2012 R2: July 2015
 URL: https://support.microsoft.com/en-us/kb/3065988
 
実施手順
----------
以下のグループポリシーを有効にしていただくことによって、Windows Update からのWindows 10 のダウンロードおよびインストールを抑止することが可能となります。
 
場所
[コンピューターの構成]
 +-- [管理用テンプレート]
   +-- [Windows コンポーネント]
     +-- [Windows Update]
 
項目名: [Turn off the upgrade to latest version of Windows Update]
値 : 有効
 
 
レジストリからブロックする方法

上述のポリシー設定をレジストリで行う場合には以下値を設定します。

キー : HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate
名前 : DisableOSUpgrade
種類 : REG_DWORD
値 :  1
 
このレジストリをコマンドで適用する場合には以下の reg から /f までのコマンドを、
管理者権限でご実施いただきますようお願い致します。
 
reg add HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate /v "DisableOSUpgrade" /t REG_DWORD /d 00000001 /f
 
7 月 29 日以降には、自動でダウンロードが行われ、アップグレードの準備ができ次第、アップグレードのスケジュールを促すポップアップが表示される予定です。
 
Windows 10 を、より快適にご利用いただくためにも、計画的にアップグレードに向けた準備を進めていただけますようお願い致します。

 
暑い日が続きますが、体調など壊されぬようご自愛ください

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

今回のトピックはクラスターのハートビート通信に関わるパラメーターの設定値 (閾値) に
ついて分かりやすくご紹介したいと思います。

ハートビートとはクラスター ノード間で互いのノードの正常性を確認するための仕組みで、
詳細につきましては以下の記事がございます。ハートビート通信の設定変更手順などの
記載がございますので、こちらにつきましても、ぜひご一読ください。

  フェールオーバー クラスターのハートビートについて
  http://blogs.technet.com/b/askcorejp/archive/2012/03/22/3488080.aspx

このハートビートに関するパラメータの設定可能な範囲については、Windows Server 2008 および
Windows Server 2012 / 2012 R2 では公開された情報がありましたが、Windows Server 2008 R2 における
設定可能値の情報は、公開されておりませんでした。

そのため、当ブログでは Windows Server 2008 R2 を含めた OS  バージョン毎のハートビート通信の
設定値の範囲についてまとめさせていただきます。

上記の通り、Windows Server 2008 R2 では同一サブネットにおけるハートビート通信の閾値を最大 20 秒、
異なるサブネット間では最大 80 秒まで設定可能となっています。

負荷の高いネットワークであったり、 WAN 環境などのパケット遅延が発生しうる環境では、これらの値を
変更することで一時的なハートビート通信遅延などによる障害検知の影響を軽減することができます。

しかしながら、ハートビート通信の閾値を必要以上に延長すると、クラスター ノードにおける障害検知 (例えば
ブルースクリーンでノードが落ちた場合等) が遅くなるリスクがあります。そのため、TCP/IP やアプリケーションが
もつ各種タイムアウト等を考慮に入れ、お客様の運用方針に合わせた適切な値を設定いただければと思います。

[参考資料]
・ Windows Server 2012 / 2012 R2 の設定値の範囲
  SameSubnetDelay
    https://msdn.microsoft.com/en-us/library/jj151938(v=vs.85).aspx
  SameSubnetThreshold
    https://msdn.microsoft.com/en-us/library/jj151939(v=vs.85).aspx
  CrossSubnetDelay
    https://msdn.microsoft.com/en-us/library/jj151927(v=vs.85).aspx
  CrossSubnetThreshold
    https://msdn.microsoft.com/en-us/library/jj151928(v=vs.85).aspx

・ Windows Server 2008 の設定値の範囲
  Clustering and High-Availability
    http://blogs.msdn.com/b/clustering/archive/2012/11/21/10370765.aspx

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

今回は KB3072401 の事象についてご紹介いたします。

  文書番号: 3072401
  File system corrupts when you delete a file that has 4 GB-1 bytesof size on FAT32 system in Windows
  https://support.microsoft.com/en-us/kb/3072401

FAT32 ファイル システムで作成可能な最大ファイル サイズは 4294967295 (4 GB-1) バイトとなりますが、当事象では この最大サイズのファイルを削除するとファイル システム破損が発生いたします。
削除後にこのボリュームに対して chkdsk コマンドを実行すると破損が検出され、修復の実行が必要であるメッセージが出力されます。
このような状態になった場合は、修復を実施する /f オプションをつけた chkdsk /f コマンドを実行しファイルシステムを修復します。

本事象の発生が確認されている OS は以下の通りです。

  Windows Server 2008
  Windows Server 2008 R2
  Windows Server 2012
  Windows Server 2012 R2
  Windows 7
  Windows 8
  Windows 8.1

また発生条件はファイルを作成したボリュームのクラスター サイズに依存しております。

例:

クラスター サイズが 4KB の場合

ファイルサイズ: 4,294,963,200 バイト <-- 発生しない (4GB-4096)

ファイルサイズ: 4,294,963,201 バイト<-- 発生する (4GB-4095)

クラスター サイズが 8KB の場合

ファイルサイズ: 4,294,959,104 バイト<-- 発生しない (4GB-8192)

ファイルサイズ: 4,294,959,105 バイト<-- 発生する (4GB-8191)

 Windows Server 2012、Windows Server 2012 R2、Windows 8、及び Windows 8.1 については、KB3072401 の修正プログラムを適用することで事象が修正されます。
※ 既にファイルシステムの破損が発生している場合には、chkdsk /f の実行が必要です。

ただし、Windows Server 2008、Windows Server 2008 R2、及び Windows 7 については、本事象が発覚したタイミングで既にメインストリーム サポートが終了していたため、修正プログラムが提供されておりません。
修正プログラムの提供されていないこれらの環境でこの問題を発生させないためには、以下の点にご注意ください。
  - FAT32 ファイル システムを利用する際には 4294967296 (4GB) - クラスター サイズより小さなファイル サイズのファイルをご利用ください。
  - 破損が検知されたボリュームに対しては chkdsk /f コマンドにて修復を実行してください。

※  クラスター サイズが不明な場合は CHKDSK の実行結果に表示されるアロケーション ユニット サイズをご確認ください。

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

クラスター環境で FailoverClustering ID : 1069もしくは ID : 1573のイベントが記録され、ディスク リソースがオンラインにならない、といったお問い合わせをいただきます。

そのような事象の原因のひとつとして、フィルター ドライバーの競合がございます。

フィルター ドライバーの競合が原因のお問い合わせの中で、Data Protection Manager (DPM) とウイルス対策ソフトの競合により、ディスクのオンラインができない問題が複数報告されております。

  [DPM] DPM と特定のウイルス対策ソフトの競合について
  http://blogs.technet.com/b/systemcenterjp/archive/2012/04/10/3491184.aspx

今回のブログでは、このような事象が与える影響について、クラスターの観点でご紹介いたします。

このフィルター ドライバーの競合が発生すると、ディスクのオンラインに時間がかかるようになります。
OS 領域のディスクのように、OS が起動するタイミングでオンラインになるディスクは競合するフィルター ドライバーがロードされる前にオンライン処理が行われるため、時間がかかることはありません。
しかしながら、クラスターが制御する共有ディスクはフェールオーバーなどタイミングでオンラインになることがあります。
このタイミングではすべてのフィルター ドライバーがすでにロードされているので、オンラインの処理に時間がかかり、結果的にディスク リソースのオンライン タイムアウトが起こるため、前述のエラー イベントが記録されます。

ディスク リソースがオンラインにならないことにより、目に見えるクラスターの挙動としては以下のような事象があげられます。

   1. 役割を開始できない
   2. フェールオーバーが失敗する
   3. グループの移動 (手動でのフェールオーバー) およびクラスター コア リソース (クラスター グループ) の移動ができない

このような事象が発生した時、ディスクがオンラインにできないことが原因であるかどうかを確認するため、以下のどちらかもしくは両方のイベント ログが記録されているかどうかを確認します。

■ イベント ログ

上記が確認でき、さらに DPM のフィルター ドライバーとウィルス対策ソフトがインストールされている環境の場合、フィルター ドライバーの競合の可能性を疑います。
さらに 切り分けを進めるには、影響を受けそうなフィルター ドライバーをアンインストールして、 事象が再現するかを確認する方法が有効です。

ご参考として過去弊社にお問い合わせのいただいた際に確認できた競合するドライバーとして、トレンドマイクロ社製のウイルス対策ソフトの報告がございました。
トレンドマイクロ社で以下のような情報を公開しております。
当情報を参照し、対象の製品をご利用であればレジストリー キーの変更で事象が改善するかを確認してください。

  Microsoft Cluster resources fail when the OfficeScan client is running
  http://esupport.trendmicro.com/solution/en-us/1058335.aspx
  - 免責事項
    上記リンクは、マイクロソフトのサイトではございませんため、設定につきましての責任は負いかねます。
    設定にあたってのご質問や懸念点につきましては、制作元との十分なご協議の上、実施いただくことを推奨いたします。