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

昨日よりプレミアム ストレージを所有する仮想マシンのバックアップがパブリック プレビュー版として公開されました。

Azure ポータルからバックアップを実施いただく場合、プレミアム ストレージを所有する際としない場合の手順に違いはございません。

以下、その他バックアップ時の動作の違いおよびリストアについてご説明します。

・プレミアム ストレージのバックアップ
————————————————–
プレミアム ストレージを持つ仮想マシンのバックアップ中、バックアップ サービスはプレミアム ストレージ アカウント内に一時的なステージング領域を作成します。ステージング領域は “AzureBackup-” という名前で、仮想マシンに接続されているプレミアム ストレージ上のディスクの全データ サイズと等しいサイズです。

(注意) バックアップ時に作成されるステージング領域の変更・削除は行わないでください。

バックアップが終了するとステージング領域は削除されます。ステージング領域で使用するストレージ料金はプレミアム ストレージ価格と同じです。

・プレミアム ストレージのリストア
————————————————–
プレミアム ストレージを所有する仮想マシンの Recovery Point をプレミアム ストレージへ戻すことがリストアの一般的なプロセスとなりますが、仮想マシンの Recovery Point をスタンダード ストレージへ戻すことも可能です。仮想マシンからファイルの一部が必要な場合、以下の様なリストアが使用できます。

1. スタンダード ストレージヘ仮想マシンの Recovery Point をリストア
2. プレミアム ストレージヘディスクをコピー
3. Azure IaaS 仮想マシンの作成

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

Azure リカバリー サービス (Azure バックアップ及び Azure  Site Recoveryを含む) がすべての CSP パートナー様向けに公開され、2 つの Azure サービスを CSP モデルからご利用頂けるようになりました。

これは CSP パートナー様から何か月も前よりご要望いただいていた機能です。Azure バックアップと Azure サイト リカバリー (ASR) はクラウドに詳しくなくても簡単にご利用いただけるサービスとなりました。

これまでバックアップや ASR の設定は PowerShell や API を利用しており、CSP パートナー様にとってデプロイや管理が行いにくい状況でした。現在この機能は Azure ポータルで利用出来るので、簡単かつ管理された方法でバックアップや災害復旧サービスをお客様へ提供できます。また Azure CSP のテナントは、これらのサービスを既存サブスクリプションに追加するだけで、自身で Azure バックアップ及び ASR を利用できます。

既存の Azure CSP サブスクリプションにバックアップや災害復旧サービスを追加するには、Azure Marketplace の “Data + Storage” メニューから “Recovery Services” を追加するだけです。

バックアップおよび ASR の課金データを他の Azure サービス（IaaS、DBs 等）と区別するために、別途リソース グループに Recovery Services コンテナーを作成することをお勧めします。

バックアップおよびリカバリー サービスは同メニューの “Recovery Services コンテナー (Vault)”より設定出来ます。

・Azure バックアップ
まず最初に Azure バックアップの価格モデルをご案内します。下記 2 種類の課金があります。

1．保護インスタンス- 仮想マシン、SQL データベース、Exchange データベース等、バックアップするインスタンス毎に支払います。 Exchange サーバーとサーバー上の仮想マシンをバックアップする場合、2 インスタンス分課金されます。インスタンス毎のデータ サイズによリ (50 Gb未満、50～500 Gb、500 Gb超過) 3 段階の価格があります。

2．Backup コンテナーの消費されたストレージ。ここでは Block Blob ストレージが使用されますが、Locally Redundant Storage (LRS) 及び Geo-Redundant Storage (GRS) を選択できます。価格はこちらでご確認ください。

デフォルトでは Backup コンテナーは Geo-Redundant Storage を使用していますが、余分な冗長 (リダンダンシー) を支払いたくない場合には、Locally Redundant Storage へ切替えることで価格を半分に抑えられます。設定の “Backup Configuration” で最初に切り替えることをお勧めします。尚、Recovery Service コンテナーへバックアップ データを保存後、この設定を変更することは出来ません。

Azure バックアップには 3 つのシナリオがあります。

1．Azure Virtual Machine Backup – Azure の仮想マシンをバックアップ
2．File-Folder Backup – 専用の Recovery Services エージェントを使用し、Windows クライアントや Windows サーバーのファイルをバックアップ
3．System Center Data Protection Manager – (オンプレミスもしくはクラウドにある) System Center Data Protection Manager サーバーを Azure バックアップへ接続し、DPM バックアップ データを Azure Backup コンテナーへ保存

・Azure 仮想マシンバックアップ
———————————————————
Azure バックアップは Azure で実行されている仮想マシンのバックアップをシンプルな 2 ステップで設定できます。

1．Backup Policy を新規作成、もしくは既存より選択
2．バックアップしたい仮想マシンを選択。現在のサブスクリプションでアクセス権のあるすべての仮想マシンより選択出来ます。

“Backup Items” メニューからこのバックアップの現在の状況を確認し、リカバリー ジョブの管理が出来ます。

・File-Folder Backup
———————————————————
このシナリオでは、リモート Windows クライアントの仮想マシンや Windows サーバーのファイルをバックアップします。コンピューターはオンプレミス、Azure、サービス プロバイダー環境等、どこにあっても大丈夫です。設定するには Recovery Services エージェントをダウンロードし、ファイルをバックアップしたいすべてのコンピューターにインストールが必要です。また、”Download” をクリックしエージェントのインストールに必要なコンテナー認証ファイルをダウンロードする必要があります。

エージェントのインストール後、Azure Backup Client を開き、新しバックアップをスケジュールします。バックアップするアイテムを選択し、保持ポリシー (Retention Policy) を設定します。

エージェントは設定時に指定された暗号化キーを使い、データを暗号化します。Azure に保存されるすべてのバックアップは暗号化されます。

データのリカバリーには、このコンピューター、もしくは他のコンピューターで Agent Backup Client を起動し、”Recover data” を選択します。

いくつのリカバリー ポイント（回復ポイント）がバックアップ コンテナーに保存されているか Azure ポータルで確認出来ます。

・System Center Data Protection Manager
———————————————————
このシナリオでは System Center Data Protection Manager が Azure Backup コンテナーに以下で使用するバックアップをコピーします。

1．長期バックアップ
例：先月分のみローカル ディスク ストレージへバックアップし、毎週バックアップを Azure Backup コンテナーへコピーし、そこへ数年間保存します。

2．短期バックアップ
ローカル ディスクのバックアップを日々 Azure Backup コンテナーへコピー。Azure Backup コンテナーへ移動する前にローカル ディスクに少なくとも １ つバックアップを保存する必要があります。

高額なテープ ストレージ システム購入よりも Azure へバックアップする方がずっと安価なので、Azure Backup コンテナーがあれば長期バックアップ用のテープ ストレージが必要なくなります。現在過去 99 年分のバックアップ データを保存できますが、これだけあれば十分です。

DPM 2012 R2 及びそれ以降はファイル、SQL サーバー データベース、Exchange データベース、SharePoint ファーム、Windows サーバー システム状態、Hyper-V の仮想マシンをバックアップします。詳細はこちらをご覧ください。

この機能は下記 2 つの方法で使用できます。

1. サービス プロバイダーがすべてのテナントのデータ（IaaS, ホスト型 Exchange、Database-as-a-Service）を DPM へバックアップ。DPM は Azure Backup コンテナーへ Azure CSP サブスクリプション経由でバックアップをコピー。現在各 DPM サーバーは 1 つの Azure Backup コンテナーのみしか使用できないため、同 DPM サーバー上で異なるテナント データの違う Azure サブスクリプションを使用することは出来ません。

2. CSP パートナー様が管理されたバックアップ サービスを顧客へ提供。CSP パートナー様がオンプレミスの顧客環境で DPM サーバーをデプロイ（あるいは既存のものを設定）し、専用の Azure CSP サブスクリプションの Azure Backup コンテナーを使用するよう設定。
最初に DPM サーバーへ Azure Recovery Services エージェントをインストールする必要があります。これは File-Folder バックアップ シナリオで使用されたエージェントと同じです。”Download” ボタンをクリックし、コンテナー認証ファイルを DPM サーバーからアクセス出来る場所へ保存します。

次に DPM Administration Console の Management -> Online へ進み、”Register” ボタンをクリックします。

Azure ポータルからダウンロードしたコンテナー認証ファイルを選択します。

インストール プロセスでインターネット接続の設定ができます。また Azure Backup コンテナーからリカバリする際に一時保管するローカルのステージング フォルダの指定が必要です。

Azure Backup コンテナーのデータ暗号化に使用するパス フレーズを作成ください。このパス フレーズはプライマリの DPM サーバーが機能しない場合、Backup コンテナーからデータをリカバリするのに必要となります。

次に Protection Group を作成するか、既存の Protection Group に Online Protection オプションを追加します。

Azure Backup コンテナーへ移動したい膨大なデータがあり、インターネット接続に制限がある場合、Azure Import/Exportサービスを利用し、最初のデータ コピーの入ったディスクを FedEx (US 及びヨーロッパ)　あるいは、DHL（アジア）で Azure データ センターへ送ることをご検討ください。詳細はこちらです。いずれにせよ完全なデータ コピーが Azure Backup コンテナーへ送られるのは一度だけです。それ以降は圧縮された増加分データのみが送られ、データサイズははるかに小さいです。

“Backup Management Servers”のメニューから Azure CSP ポータル上のすべての接続されたDPMサーバーを確認出来ます。

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

今回は、Windows 10 環境で WPD (*1) のデバイス間でファイル コピーを実行した際に Explorer から
応答が返らなくなる現象についてご紹介いたします。

 *1 WPDとは？

WPD (Windows Portable Device) は、Windows Vista 以降の OS に標準で用意されている、携帯電話、
デジタル カメラ、ポータブル メディア プレーヤーなどの多くのポータブル デバイスをサポートする
ドライバー ベースのテクノロジです。スマートフォンや従来の携帯電話を USB で PC につないで
ファイル転送などを行う際には WPD が利用されます。

現象：
Windows 10 環境に WPD のデバイスを接続し、Explorer 上で WPD から WPD へファイル コピーを行うと、
以下のようなコピー処理中のダイアログが表示され、Explorer が処理中の状態から復帰しなくなる現象が発生します。

ダイアログの例)

この現象は、Windows 10 の Explorer の処理において WPD 間でファイル コピー処理を行う際、内部でロックによる
排他処理が適切に処理されていないことに起因して発生いたします。そのため、ローカル ドライブから WPD、
もしくは WPDからローカル ドライブへのファイル コピー時には本現象は発生しません。

なお、この現象が発生した場合もエクスプローラー自体がハングしてしまうわけではなく、キャンセル ボタンを
押下することで処理を中断することは可能です。
また、本現象は Windows 7、Windows 8/8.1 では発生しませんが、 2016/4/20 時点の最新ビルド版である
Windows 10 (Build 10586) を含めてすべてのバージョンの Windows 10 で 発生する可能性があります。

対処方法：
Windows 10 の Explorer 上で WPD 間のファイル コピーを行う場合、一旦WPDのコピー元ファイルをローカルの
ハード ディスクにコピーし、その後ローカルのハード ディスクからWPD  へファイル コピーを実行します。

本現象につきましては、現在製品開発部門と連携して調査を進めております。

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

Build 2016 の時期となりましたが、Azure Storage チームからいくつか嬉しい告知があります。このブログでは新しい告知と既存プログラムのアップデートの概要をご紹介します。新しい機能やアップデートがサービス、アプリケーション及びその他のニーズで Azure Storage をよりご活用頂けると幸いです。

・プレビュー プログラムの告知
===================================================
・ストレージ サービス暗号化プレビュー
ストレージサービス暗号化は、Block Blobs、Page Blobs 及び Append Blobs を含む Blob ストレージ データを自動的に暗号化することで、組織としての安全性やコンプライアンスの要求事項に対応します。Azure Storage は最も強い暗号キーの 1 つである暗号化方式 AES 256-bit を使用し、すべての暗号、暗号解読、キーの管理をトランスペアレントに処理しています。この機能を有効にするのに追加料金は必要ありません。

プレビュープログラムへは Azure Portal もしくは Azure PowerShell よりサブスクリプションを登録してリクエスト出来ます。一度サブスクリプションが登録されると Azure Portal を使用し新規ストレージ アカウントを作成し、機能を有効にすることが出来ます。
この機能についての詳細は “Azure Storage Service Encryption for Data at Rest (Preview)” 参照ください。

・Azure ストレージのロードマップ
===================================================
・増分スナップショットをコピーする為の GetPageRanges API の公開
Azure Storage チームでは GetPageRanges API に Page Blobs の新機能の追加を予定しています。この機能により より速く効果的に Azure 仮想マシンのバックアップ ソリューションを提供出来ます。API は Base blob とスナップショットの変更点リストを返すので、各スナップショット固有の変更点のみ特定し、コピーすることが出来ます。

これは仮想マシン ディスクの増分バックアップ時、移行に必要なデータ量を著しく減らします。API は Standard Storage 及び Premium Storage の Page Blobs をサポートします。この機能はより多くの Client Libraries サポートが追加され、REST API 及び .NET Client Library より 2016 年 4 月よりご利用頂ける予定です。

・Azure Import/Export
Azureインポート/エクスポートはサービスを提供するすべての地域で 8 TB までハード ドライブをサポートします。また、Azure インポート/エクスポートは 2016 年夏、日本及びオーストラリアで発売になります。これにより日本もしくはオーストラリアでストレージ アカウントをお持ちのお客様は他地域ではなく、同地域内の国内住所へディスクの発送が可能となります。

・Azure Premium Storage の Azure バックアップサポート
Azure Premium Storage は Azure 仮想マシン上で IO インテンシブ アプリケーションを実行するのに理想的です。Azure Backup サービスはパワフルかつお手頃なクラウド バックアップ ソリューションを実現し、また Azure Premium Storage のサポートを予定しています。Azure Backup サービスがあれば、Premium Storage の仮想マシンで実行する重要なアプリケーションを保護できます。
詳細は Azure Backup 及び Premium Storage をご参照ください。

・クライアント ライブラリ及びツールのアップデート
===================================================
・Java クライアント側暗号化が公開されました
Azure Storage の Client Java Library でクライアント側暗号化機能が利用可能になりました。この機能により開発者は Azure Storage にデータ送信する前に Blob、Table、及び Queue データの暗号化が出来ます。また Azure Key Vault との統合がサポートされおり Azure Key Vault でキーを保存・管理出来ます。この公開により Windows.Net で暗号化されたデータは Linux の Java で暗号解除でき、またその逆も可能です。
詳細については概要をご参照ください。

・ストレージ Node.js プレビューのアップデート
Azure ストレージ Node.js Client Library の最新プレビュー(0.10)をご案内します。これには開発者としての豊富な体験、Account SAS 機能のフルサポート、カスタマー ユーザビリティのフィードバックと共に Service SAS の IPACL 及び Protocol 仕様が含まれます。npmjs の Storage Package を活用すればアプリケーションで今すぐ Node.js Preview Azure Storage Library の使用を開始頂けます。
詳細やソースコードについては GitHub Repo を参照ください。

・ストレージ Python プレビューのアップデート
Azure ストレージ Python Client Library の最新プレビュー(0.30) をご案内します。このバージョンで 2015-04-05 REST バージョンの Append Blobs のサポート、Azure ファイル ストレージ、Account SAS、JSON テーブル フォーマッティング、その他諸々を含むすべての機能が利用可能となります。
詳細については、はじめに、最新文書、アップグレード ガイド、使用サンプル及び互換性変更ログ等をご参照ください。

・Azure Storage Explorer
Azure Storage Explorer の最新の公開プレビューをご案内します。本リリースは CSV ファイルへのエクスポートを含む Table Storage のサポート、Queue Storage、Account SAS 及びアップデート UI を追加しました。
詳細及び Windows/Linux/Mac プラットフォーム用エクスプローラーのダウンロードについては www.storageexplorer.com へお進みください。

・文書及びサンプルのアップデート
===================================================
・ストレージ セキュリティガイド
Azure Storage は開発者が安全なアプリケーションを構築できるよう、広範囲なセキュリティ機能を提供しています。ストレージ アカウントの管理を確保し、データ送信中のストレージ オブジェクトやストレージ アカウント、その他多くのデータの暗号化が可能です。Azure Storage Security Guide はセキュリティ機能の概要や資源への助言を提供し、知識を深めることが出来ます。
詳細については Storage Security Guide をご参照ください。

・ストレージ サンプル
Azure ストレージ チームは開発者がエンド ユーザー体験を改善できるよう絶え間なく奮闘しています。最近開発した標準サンプルは理解しやすく 5 分で始める事が出来ます。また詳しい説明、フル機能、コミュニティ フレンドリーがあり、且つランディング ページからアクセス可能なので、使用するプラットフォームで必要なサンプルを見つける事が出来ます。コードはオープン ソースで Github より簡単に利用でき、コミュニティがサンプル レポジトリに貢献出来ます。

サンプルは Storage Samples ランディング ページよりご使用頂けます。最後になりますが、Azure Storage が初めての方は一番早く学び、始めることのできる Azure Storage Documentation Page へお進みください｡

参考： Build 2016: Azure Storage announcements

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

新しい PowerShell においては、以前 Blog に書きました Add-AlertRule での手順でアラートを作成する事が出来ません。その為、今回は RM コマンドを利用した IaaS VM Backup のアラート通知手順についてご案内いたします。

– Add-AlertRule を使用した手順
IaaS VM Backup のアラート通知について

アラートの設定につきましては、Add-AzureRmLogAlertRule コマンドを利用する事で、アラート配信を実施する事が可能です。以下設定手順についてご案内いたします。

– アラートの設定手順
==========================================================================
1．管理者権限で PowerShell を起動します。

2．Azure のアカウントでログインします。
実行コマンド: Login-AzureRmAccount
– 実行例
PS C:\WINDOWS\system32> Login-AzureRmAccount
Environment           : AzureCloud
Account               : ****@microsoft.com
TenantId              : ****88bf-86f1-41af-91ab-2d7cd011****
SubscriptionId        : ****d84b-f76a-40f7-a159-10950893****
CurrentStorageAccount :
—————————————————————-

3．Azure の管理ポータルよりアラート対象とする、バックアップ コンテナー名を確認します。

4．バックアップ コンテナーの詳細情報を確認します。
実行コマンド: Get-AzureRmResource | Where-Object { $_.ResourceName -eq “バックアップ コンテナー名”}
– 実行例
PS C:\WINDOWS\system32> Get-AzureRmResource | Where-Object { $_.ResourceName -eq “EAST-US-TEST1″}
Name              : EAST-US-TEST1
ResourceId        : /subscriptions/****d84b-f76a-40f7-a159-10950893****/resourceGroups/RecoveryServices-****IZBYRTB6YDWNPCPY5Z5PJH3GAKHOGSLYZXAELCN74LBJRL5Q-East-US/providers/microsoft.backup/BackupVault/EAST-US-TEST1
ResourceName      : EAST-US-TEST1
ResourceType      : microsoft.backup/BackupVault
ResourceGroupName : RecoveryServices-****IZBYRTB6YDWNPCPY5Z5PJH3GAKHOGSLYZXAELCN74LBJRL5Q-East-US
Location          : eastus
SubscriptionId    : ****d84b-f76a-40f7-a159-10950893****
—————————————————————-

5．アラートの送り先として指定するメール アドレスを登録します。
実行コマンド: PS C:\WINDOWS\system32> $actionEmail = New-AzureRmAlertRuleEmail -CustomEmail “メール アドレス″
– 実行例
PS C:\WINDOWS\system32> $actionEmail = New-AzureRmAlertRuleEmail -CustomEmail ****@microsoft.com
—————————————————————-

6．アラート ルールを作成します。
手順 4 で確認した内容よりオプションをそれぞれ指定します。

-Location “リージョン″  <=  Location: eastus
-Name “アラート名”  <=  アラート名となるので適当な名前をご指定ください
– ResourceGroup “リソース グループ名”  <=  ResourceGroupName : RecoveryServices-****IZBYRTB6YDWNPCPY5Z5PJH3GAKHOGSLYZXAELCN74LBJRL5Q-East-US
-TargetResourceId “リソース ID”  <=  ResourceId        : /subscriptions/****d84b-f76a-40f7-a159-10950893****/resourceGroups/RecoveryServices-****IZBYRTB6YDWNPCPY5Z5PJH3GAKHOGSLYZXAELCN74LBJRL5Q-East-US/providers/microsoft.backup/BackupVault/EAST-US-TEST1

実行コマンド: Add-AzureRmLogAlertRule -Location “リージョン″ -Name “アラート名” -OperationName Microsoft.Backup/backupVault/Backup -ResourceGroup “リソース グループ名” -Actions $actionEmail -TargetResourceId “リソース ID”
– 実行例
PS C:\WINDOWS\system32> Add-AzureRmLogAlertRule -Location “East US” -Name AlertTestInfo -OperationName Microsoft.Backup/backupVault/Backup -ResourceGroup RecoveryServices-****IZBYRTB6YDWNPCPY5Z5PJH3GAKHOGSLYZXAELCN74LBJRL5Q-East-US -Actions $actionEmail -TargetResourceId /subscriptions/****d84b-f76a-40f7-a159-10950893****/resourceGroups/RecoveryServices-****IZBYRTB6YDWNPCPY5Z5PJH3GAKHOGSLYZXAELCN74LBJRL5Q-East-US/providers/microsoft.backup/BackupVault/EAST-US-TEST1

RequestId                            StatusCode
———                            ———-
e5c4f318-9987-4731-9b3c-bfc3f9ec55e7    Created
—————————————————————-

以上でアラートの設定が完了です。
上記設定を実施する事で、対象のバックアップ コンテナーに登録されている仮想マシンのバックアップ状態 (Started、Succeeded、Failed 等) をアラート メールで確認する事が出来ます。
バックアップ状態を指定してアラート メールを受信するには、追加オプション (Level、Status、SubStatus) を指定くださいますようお願いいたします。
詳細動作については、”help Add-AzureRmLogAlertRule -Detailed” よりご確認ください。

アラート メールは以下の様な内容で送信されます。

送信元: Microsoft Azure Alerts alerts-noreply@mail.windowsazure.com
タイトル: [ALERT ACTIVATED] – AlertTestInfo  happened for BackupVault EAST-US-TEST1
内容:

– アラート内容の確認
==========================================================================
設定したアラート ルールを確認するには、以下のコマンドを実施ください。

実行コマンド: Get-AzureRmAlertRule –ResourceGroup “リソース グループ名”
– 実行例
PS C:\WINDOWS\system32> Get-AzureRmAlertRule -ResourceGroup RecoveryServices-****IZBYRTB6YDWNPCPY5Z5PJH3GAKHOGSLYZXAELCN74LBJRL5Q-East-US

Properties : Microsoft.Azure.Management.Insights.Models.Rule
Tags       : {[$type, Microsoft.WindowsAzure.Management.Common.Storage.CasePreservedDictionary, Microsoft.WindowsAzure.Management.Common.Storage], [hidden-link:/subscriptions/****d84b-f76a-40f7-a159-10950893****
/resourceGroups/RecoveryServices-****IZBYRTB6YDWNPCPY5Z5PJH3GAKHOGSLYZXAELCN74LBJRL5Q-East-US/providers/microsoft.backup/BackupVault/EAST-US-TEST1, Resource]}
Id         : /subscriptions/****d84b-f76a-40f7-a159-10950893****/resourceGroups/RecoveryServices-****IZBYRTB6YDWNPCPY5Z5PJH3GAKHOGSLYZXAELCN74LBJRL5Q-East-US/providers/microsoft.insights/alertrules/AlertTestInfo
Location   : East US
Name       : AlertTestInfo
—————————————————————-

詳細を確認するには “-DetailedOutput” オプションを指定してください。
実行コマンド: Get-AzureRmAlertRule -ResourceGroup “リソース グループ名” -DetailedOutput

– アラート ルールの削除
==========================================================================
設定したアラート ルールを削除するには、以下のコマンドを実施ください。

実行コマンド: Remove-AzureRmAlertRule -Name AlertTestInfo -ResourceGroup “リソース グループ名”
– 実行例
PS C:\WINDOWS\system32> Remove-AzureRmAlertRule -Name AlertTestInfo -ResourceGroup RecoveryServices-****IZBYRTB6YDWNPCPY5Z5PJH3GAKHOGSLYZXAELCN74LBJRL5Q-East-US

RequestId                            StatusCode
———                            ———-
dc5fd5b5-7e08-43e9-a261-38070949c860         OK
—————————————————————-

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

Hyper-V 上の仮想マシン環境のドメイン コントローラー (DC) にて記録される、ActiveDirectory_DomainService ID: 1539 の警告イベントは無視してよいか、というお問い合わせをいただくことがあります。

今回はこのイベント ログの出力される原因および無視可能な場合の条件についてご紹介いたします。

1. 概要

仮想マシン環境の DC では、以下のイベントが記録されます。

本イベントは以下の構成のいずれかに該当している場合は無視していただいて問題ありません。

・Hyper-V ホストに接続されているディスクの書き込みキャッシュが無効化されている。
・Hyper-V ホストに接続されているディスクが Force Unit Access (FUA) をサポートしており、仮想マシン側の仮想ディスクも SCSI 接続で構成されている。

2. 仮想マシン環境にて本イベントが記録される原因

Active Directory はドライブの電源が切断され重要な更新が失われてしまうことを防ぐため、データベースやログ ファイルを格納する各論理ドライブのディスクの書き込みキャッシュを無効化します。

本メッセージは IOCTL_DISK_SET_CACHE_INFORMATION コマンドにて該当デバイスの書き込みキャッシュの無効化に失敗した場合に出力されます。

しかしながら、仮想マシン環境における仮想ディスクは以下の理由のため、書き込みキャッシュの無効化の設定ができない仕様となっております。

・複数の仮想ディスクが、単一の物理ディスクに配置される可能性があり、すべての仮想ディスクが同一のキャッシュ設定を持つことが保証されないため
・仮想マシンのライブ マイグレーションや記憶域の移動により、仮想ディスクが別の物理ディスクに移動する可能性があるため

従いまして、仮想マシン環境にて仮想ディスクの書き込みキャッシュが無効化できない事象は想定された挙動であるため、本イベントが出力されることも想定された挙動となります。
無視の可否につきましては、後述しております Hyper-V ホストのハードウェア構成についてご確認いただく必要があります。

3. 無視可能な場合の条件

■ Hyper-V ホストに接続されたディスクが IDE 接続や ATA 接続など FUA をサポートしていないハードウェアの場合

Hyper-V ホストにて物理ディスクの書き込みキャッシュを無効化にすることで、データの整合性が保たれるため、本メッセージは無視しても問題ありません。

■ Hyper-V ホストに接続されたディスクが FUA をサポートする SCSI 接続のハードウェアの場合

SCSI 環境では、Force Unit Access (FUA) と呼ばれるディスク キャッシュを使用せずに書き込みを行うフラグを付けた SCSI コマンドを利用することができます。FUA を利用した書き込みの処理は、直接ディスクへの書き込みが行われ、停電などの障害時にもデータの整合性を保つことができます。

仮想マシン環境でも SCSI 接続のディスクに Active Directory のデータベースを配置している場合は、Active Directory から FUA を利用した書き込みの I/O が発行され、その FUA が物理ディスクまで透過的に届けられます。よって、本メッセージは無視しても問題ありません。

なお、第 1 世代の仮想マシンでは SCSI 接続のディスクからの起動ができませんので、C ドライブは必ず IDE 接続となります。C ドライブ配下に Active Directory のデータベースを配置する場合は、第 2 世代で仮想マシンが作成されている必要があります。

仮想マシン環境にて SCSI 接続のディスクをご利用いただけない場合は、FUA に対応していないハードウェアの対処と同様に、Hyper-V ホストにて物理ディスクの書き込みキャッシュを無効化していただく必要がございますので、ご注意ください。

また、お使いの SCSI 接続のディスクが FUA をサポートしているかどうかについては、ハードウェア ベンダーにご確認ください。

4. まとめと注意事項

以下に仮想マシン環境での本イベントの無視の可否を判断するために必要な対処策についてまとめました。

また、Windows Server 2008 R2 / Windows Server 2012 では、Hyper-V 環境の Active Directory のデータの整合性について、以下の修正が行われておりますので、本修正プログラムが適用されているかをご確認ください。

IDE に接続されている仮想ハード ディスクで HYPER-V ホスト サーバーで発生した、計画外の再起動との整合性の損失
https://support.microsoft.com/ja-jp/kb/2853952

[参考情報]
Hyper-V storage: Caching layers and implications for data consistency
https://support.microsoft.com/en-us/kb/2801713

仮想化ドメイン コントローラーの展開に関する考慮事項
https://technet.microsoft.com/ja-jp/library/dd348449.aspx

仮想ホスト環境で Active Directory ドメイン コントローラーをホストする場合の考慮事項
https://support.microsoft.com/ja-jp/kb/888794

Clarifications on KB 2853952, Server 2012 and Active Directory error c00002e2 or c00002e3
https://blogs.technet.microsoft.com/askpfeplat/2013/09/10/clarifications-on-kb-2853952-server-2012-and-active-directory-error-c00002e2-or-c00002e3/

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

今回は以前より何度かお問合せ頂いているファイル サーバー リソース マネージャ (FSRM) の SMTP 設定についてお話しします。

FSRMはWindows Server 2003から登場した機能であり、以下の機能を提供します。

(1)クォータの機能
ボリュームまたはフォルダ ツリーに対して、記憶域容量の上限(ソフトまたはハード)を設定する。

(2)ファイル スクリーンの機能
ボリュームまたはフォルダ ツリーに特定の種類のファイルを保存しようとするユーザーの操作を監視またはブロックする。

(3)記憶域レポートの機能
クォータの使用率、ファイル スクリーンの動作状況、および記憶域使用のパターンを追跡するための組み込みレポートを生成する。

これらを使用して、容量しきい値が超過した場合や記憶域レポートを通知する方法として、SMTPサーバーへ電子メールを送信する設定があります。
この設定はオプション構成画面にて設定が可能です。

ただし、FSRMのSMTP機能は以下の仕様にて動作します。

・SMTPサーバとの通信には25番ポートを利用する
・SMTPサーバへのアクセスには匿名ユーザを利用する。

そのため、上記仕様に合わせた環境をSMTPサーバ側にて準備する必要があります。
上記環境を準備するのが難しい場合は、通知方法の代替として、以下をご検討いただければと思います。

(a)しきい値を超過時にイベントログへ書き込む設定し、イベントログ監視ソフトにて異常を検知する。
(b)しきい値を超過時に実行されるコマンドを設定し、異常を検知する。

(a)、(b)ともにクォータ テンプレートのプロパティにて設定が可能です。

追加ボタンをクリックすると、イベントログやコマンドの設定画面が表示されます。

イベントログへの出力をした場合、以下の内容でイベントログに書き込まれますので、
こちらの内容をログファイル監視の条件にしていただければと思います。

【イベントログへの出力内容】
出力先：アプリケーション
ソース：SRMSVC
イベントID:12325
レベル：警告

コマンドについては、通知先に合ったコマンドやスクリプトを設定いただければと思います。

設定例としては以下の通りです。

・通知先がSMTPサーバの場合、SMTPサーバの仕様に合うメールクライアントのコマンドやスクリプト

・通知先が運用管理ソフトのマネージャである場合、マネージャへ通知を上げるコマンド

ご自身の環境に合った方法を選択ください。

平素は弊社製品をご愛顧いただき誠にありがとうございます。
本項では、Makecab コマンドを使用してファイルを分割する際の問題についてお伝えいたします。

あるファイルをキャビネット形式 (.cab) のファイルとしてパッケージ化したい場合、Windows OS には、
標準で Makecab というコマンドが用意されております。

Makecab
<https://technet.microsoft.com/en-us/library/hh875545.aspx>
– Package existing files into a cabinet (.cab) file.

この Makecab コマンドを利用することでファイルを複数の .cab ファイルに分割することができます。
また、Makecab コマンドでは /F オプションを指定することにより、予め用意しておいた設定ファイル(拡張子が .ddf のファイル) の情報を基に、分割後のファイル サイズを指定してファイルの分割、圧縮を実行することができます。
しかし、Makecab コマンドでファイル分割を行った場合、以下の問題が発生することがあります。

問題が発生する場合の動作詳細 1
================================
Makecab コマンドでファイルを分割する際、分割された 1 つの cab ファイルに書き込む純粋なデータ サイズは、
以下の技術情報に記載されている cab ファイルのフォーマットに記載されている通り、ヘッダー情報(CFHEADER、CFFOLDER、CFFILE) 等のサイズを除いた CFDATA のデータ部分のサイズとなります。

Microsoft Cabinet Format
<https://msdn.microsoft.com/ja-jp/library/bb417343.aspx>

しかし、Makecabコマンド内部でこのデータ部分の計算を行う際、分割元ファイルのサイズが、cabファイルのデータ部分のサイズちょうどで割り切れる場合に、分割後のファイル フォーマットが破損する現象が発生いたします。
この破損したフォーマットのファイルを結合すると、結合時にエラーが発生するか、もしくはファイル内容が破損した状態で結合されます。

分割するファイル サイズが大きい場合には、データ部分のサイズがちょうど割り切れる確率が低くなるため
発生頻度は低くなりますが、この場合も本現象が発生する可能性があります。

– 対処方法：
上述のフォーマット情報を参考に分割ファイル サイズを変更して再度実行します。

問題が発生する場合の動作詳細 2
=================================
Makecab コマンドで 3 つ以上の cab ファイルに分割した場合、これらのファイルを Explorer から展開すると
結合後のファイルが破損します。この問題は、展開時の処理において 2 つ目の cab ファイルのヘッダーに含まれるCbUncomp の値が誤判定されることに起因して発生します。

– 対処方法：
分割後の cab ファイル数が 3 つ以上にならないように分割ファイル サイズを変更して再度実行します。

上述いたしました Makecab コマンドの 2 つの問題は、分割した時点ではエラーが発生しないため、分割したファイルを展開して結合する際に初めて確認できる問題です。

また、これらの問題を対処するためには、事前に cab ファイルのフォーマットを意識して分割していただく必要がございますため、運用上のシステムにおいてバッチ ファイル内でファイル分割、結合を行う必要があるような場合には、makecabコマンド以外のファイル分割、結合のソリューションを併せてご検討いただけますと幸いでございます。

こんにちは、Windows プラットフォーム サポートの城野です。
ボリューム シャドウコピー サービスに関しまして重要な更新が二つ公開されましたので以下にご説明いたします。

Windows Server 2012 R2 環境で、MinDiffAreaFileSize レジストリ の設定が正常に動作しない問題、
および MinDiffAreaFileSize レジストリの最大設定値の変更について、以下二つの更新プログラムが公開されました。

文書番号: 3140250
MinDiffAreaFileSize doesn’t work on Windows Server 2012 R2
https://support.microsoft.com/en-us/kb/3140250

文書番号: 3145384
MinDiffAreaFileSize registry value limit is increased from 3 GB to 50 GB in Windows 8.1 or Windows Server 2012 R2
https://support.microsoft.com/en-us/kb/3145384

- 詳細
Windows Server 2012 R2 で MinDiffAreaFileSize レジストリにて、Diff Area の初期サイズを任意のサイズに設定しているにも関わらず、レジストリの設定が無視され Diff Area の初期サイズが、規定値に設定されてしまう現象がございます。
今回公開された更新プログラム KB3140250 では、MinDiffAreaFileSize レジストリが任意に設定した値に基づいて、正常に動作するように修正されました。また、更新プログラム KB3145384 では MinDiffAreaFileSize レジストリで設定可能な最大サイズが
3000 MB (3 GB) から 50000 MB (50 GB) まで拡張されております。

当ブログでも、 VolSnap ID: 25 エラーの対処法として、 MinDiffAreaFileSize レジストリをご紹介していることがありますので、ご存知の方もいらっしゃるかと思いますが以下に簡単にご説明いたします。

- VolSnap ID: 25 エラー と MinDiffAreaFileSize レジストリ について
ボリューム シャドウコピーを使用されている環境で、シャドウ コピーの作成中に問題が発生し、意図せずシャドウ コピーが削除され
VolSnap ID: 25 がシステムイベントとして記録されることがあります。この現象は、シャドウ コピーの差分情報を保存する Diff Area と呼ばれる領域に差分情報を正しく書き込めないことにより発生することがあります。Diff Area は元々一定サイズで作られており、シャドウ コピーの差分情報を書き込む際に、差分情報の増加量に合わせてDiff Area 自体も拡張する処理が行われますが、何らかの要因で Diff Area の拡張処理で問題が発生した場合に、差分情報 が正しく書き込めず、前述のVolSnap ID: 25 が記録されすべてのシャドウ コピーが削除されます。

この現象の発生頻度を下げる方法として、あらかじめ Diff Area の初期サイズを増やしておき、拡張する頻度自体を抑えることが有効ですが、その初期サイズの設定は MinDiffAreaFileSize レジストリを作成、編集し設定を行います。

[参考情報]
- ボリューム シャドウコピーの履歴が消える現象について
https://blogs.technet.microsoft.com/askcorejp/2012/09/21/12390/

しかしながら、Windows Server 2012 R2 では、この MinDiffAreaFileSize を設定しても、サイズが規定値に設定されてしまう現象があるため、この対処法を行うことができませんでした。今回の更新プログラム KB3140250 ではこの問題が修正され、MinDiffAreaFileSize レジストリにて設定した値が、正常に動作するようになりました。

また、MinDiffAreaFileSize で設定可能な最大値 3000 MB (3 GB) を設定しても、それを超えた差分情報の書き込みが発生した場合には Diff Area の拡張処理が起きるため、結果 VolSnap ID: 25 が発生することとなり、問題が解決しないことがありました。今回の更新プログラム KB3145384 では、より多くの初期値の確保が必要な環境を考慮し、MinDiffAreaFileSize で設定可能な最大値が 50000 MB (50 GB) まで拡張可能に修正されております。

Windows Server 2012 R2 のボリューム シャドウコピー サービスを利用されている環境で、履歴が削除されてしまう等の障害の対処策、あるいは障害の抑止方法の対処策として MinDiffAreaFileSize レジストリの変更をされている場合には、是非これらの更新プログラムを適用し、
Diff Area のサイズを増加させることで回避となるかご確認頂ければと思います。

[備考]
本更新プログラムをインストール後、言語パックを新たにインストールした場合には、再度本更新プログラムをインストールする必要がありますのでご注意ください。

* ボリューム シャドウコピー サービスの関連情報について、以下ブログでも紹介しておりますのでよろしければご参照ください。

[参考情報]
- Volsnap 25 イベントについて
https://blogs.technet.microsoft.com/askcorejp/2012/02/21/volsnap-25/

– VolSnap 33 が大量に出てしまう問題について
https://blogs.technet.microsoft.com/askcorejp/2009/06/04/volsnap-33/

以上ご参考になりますと幸いです。

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

今回は Windows Server バックアップにおける容量と世代管理についてご紹介します。

Windows Server バックアップは OS 標準で搭載されている機能です。

GUI とコマンド (Wbadmin.exe) によるバックアップ・リストアができます。

バックアップ データの保存形式として仮想ディスク (VHD または VHDX 形式) を使用し、VSS (ボリューム シャドウ コピー サービス) の機能を用いて複数世代のバックアップを保持できます。

バックアップ データの格納先として、[バックアップ専用のハードディスクにバックアップする]、[ボリュームにバックアップする] と [共有ネットワーク フォルダーにバックアップする] を指定できますが、格納先の種類により保持可能なバックアップの世代数が異なります。

バックアップ格納先での容量の圧迫を避けるために、バックアップの容量・世代数を制限したいとのお問い合わせをいただくことがあります。

本ブログでは、この世代数の管理の違いについてご案内いたします。

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

保持可能なバックアップの世代数について

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

それぞれのバックアップ格納先における世代管理について纏めると、以下の表のようになります。

※ 世代数が 512 に達した場合も、同様に最も古い世代のシャドウ コピーから自動的に削除します。

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

バックアップ データの容量を制限したい場合

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

ディスクをバックアップ専用として使用できず [ボリュームにバックアップする] を指定している環境において、他のデータ領域の圧迫を避けるために、バックアップ格納先として使用される領域・世代数を制限したいとのご要望をいただくことがあります。

明示的に指定して容量や世代数を制限 (ex. ○○GB まで / ××世代まで) することはできませんが、バックアップ領域に保存されるシャドウ コピーの容量は制限することができます。詳細は以下でご説明いたします。

Windows Server バックアップでは、バックアップの実データを Windows Server 2008 R2 以前の OS では VHD 形式、Windows Server 2012 以降の OS では VHDX 形式でバックアップ格納先に保存し、そこに保存してある前回のバックアップ データに対しての更新分はシャドウ コピーとして保持することで世代管理を行っています。

さらに、バックアップのリストのカタログ情報などをメタデータとして xml ファイルに保管しています。

具体的には、以下のイメージのように、WindowsImageBackup フォルダ配下に実際にファイルとして保存されているデータは最新の世代のもののみとなり、過去のデータはシャドウ コピーとして、システムで保護された System Volume Information に保存されています。

// バックアップ先ボリュームの保存イメージ

<バックアップ先ボューム>:\

  ｜─ WindowsImageBackup          <== 最新状態のバックアップ データとメタ データが保存

  ｜─ System Volume Information   <== シャドウ コピー (*)

バックアップで使用されるディスク容量としては、以下の合計値となります。

実データの仮想ディスク (VHD または VHDX) の容量 + シャドウ コピーの容量 + メタデータの xml ファイルの容量

バックアップ格納先の容量について制限可能なのは、上記のシャドウ コピーで利用される記憶域 (*) です。

ここの領域を制限することで、保持されるバックアップの世代数を減らすことができます。

————————————————————————————–

シャドウ コピー記憶域の容量制限変更手順について

————————————————————————————–

記憶域ボリュームの制限設定を変更するには以下の手順を実行します。

例として D:\ の設定変更手順を記載いたします。

1. [スタート] – [管理ツール] – [サーバー マネージャー] をクリックします。

2. “記憶域” － “ディスクの管理” と展開し、“ディスクの管理“の右クリック メニュー の“すべてのタスク“からシャドウ コピーの構成を起動します。

3. ボリューム D: を選択した状態で [設定] をクリックします。

4. 最大サイズ、制限値を設定します。

また、バックアップ データの容量の管理については、バックアップ データを削除することも考えられます。

しかしながら、バックアップ格納先にバックアップ専用ハードディスクまたはボリュームを指定した場合、Windows Server バックアップから任意のバックアップを削除できません。

この場合、diskshadow ユーティリティーと呼ばれるシャドウ コピーの管理ユーティリティーからは以下の手順で削除できます。

——————————————————————————–

任意の世代のシャドウコピーの削除手順について

———————————————————————————

1. 管理者権限にてコマンド プロンプトを起動します。

2. diskshadow と入力し diskshadow ユーティリティを起動します。

3. delete shadows SET <セット ID> や delete shadows ID <シャドウ ID> コマンドを利用します。

   <セット ID> や <シャドウ ID> に指定する値は list shadows all コマンドにて確認できます。

なお、削除対象のシャドウ コピーが一番古いものではない場合には、表示上のシャドウ コピーの削除のみが行われ System Volume Information 配下のファイルは削除が行われないため、使用領域は削減されません。

Diskshadow コマンドでは、全てのシャドウコピーを削除、一番古いシャドウ コピーを削除といった操作を行うこともできます。

詳細な手順は、以下のブログに記載させていただいています。

しかしながら、この方法では Windows Server バックアップにて作成されるバックアップのカタログからは削除されないため、“回復” を実行した際に、すでに存在しないシャドウ コピーのバックアップも選択可能となってしまいます。

この場合、リストアはできません。バックアップのシャドウ コピーが保存場所に見つからないためです。

次回のバックアップ取得時にバックアップの履歴は更新されます。運用時は十分ご注意ください。

// 参考情報

- vssadmin コマンドでシャドウ コピーが削除できない場合の対処方法について

http://blogs.technet.com/b/askcorejp/archive/2013/11/29/vssadmin.aspx

========

補足

========

運用時にバックアップ格納先の容量が不足してバックアップに失敗することがありますが、それ以外の要因でも失敗することがあります。

この原因が既知の不具合である場合、Windows Server バックアップに関連するモジュール (wbengine.exe、volsnap.sys および vssvc.exe) の修正プログラムを適用することで回避できる可能性があります。

以下にこれらの最新版 (2016 年 5 月 24 日時点) をご案内いたしますので、未適用の場合は予防保守の観点で適用をご検討ください。

– Windows Server 2008 R2

// wbengine.exe

“0x80073B92″ error when you perform a Bare Metal Recovery on a Windows 7 or Windows Server 2008 R2-based UEFI computer

https://support.microsoft.com/en-us/kb/3001264

https://support.microsoft.com/ja-jp/kb/3001264 (機械翻訳)

// volsnap.sys

“0x0000007E” Stop error after you perform a VSS backup job in Windows 7 or Windows Server 2008 R2

https://support.microsoft.com/en-us/kb/3026771

https://support.microsoft.com/ja-jp/kb/3026771 (機械翻訳)

// vssvc.exe

Backup task fails with a time-out error in Windows

https://support.microsoft.com/en-us/kb/2996928

https://support.microsoft.com/ja-jp/kb/2996928 (機械翻訳)

– Windows Server 2012

// wbengine.exe

Wbengine.exe crashes when you run a backup on a GPT formatted drive in Windows Server 2012

https://support.microsoft.com/en-us/kb/3146600

https://support.microsoft.com/ja-jp/kb/3146600 (機械翻訳)

// volsnap.sys

Chkdsk report errors when a snapshot creation is running in Windows

http://support.microsoft.com/en-us/kb/2974325

https://support.microsoft.com/ja-jp/kb/2974325 (機械翻訳)

// vssvc.exe

“VSS_E_PROVIDER_VETO” error occurs when VSS restore fails in Windows Server 2012

https://support.microsoft.com/en-us/kb/3137726

https://support.microsoft.com/ja-jp/kb/3137726 (機械翻訳)

- Windows Server 2012 R2

// wbengine.exe

Windows Server backup fails despite sufficient free space on target volume in Windows Server 2012 R2

https://support.microsoft.com/en-us/kb/3140786

https://support.microsoft.com/ja-jp/kb/3140786 (機械翻訳)

// volsnap.sys

MinDiffAreaFileSize registry value limit is increased from 3 GB to 50 GB in Windows 8.1 or Windows Server 2012 R2

https://support.microsoft.com/en-us/kb/3145384

https://support.microsoft.com/ja-jp/kb/3145384 (機械翻訳)

// vssvc.exe

VSS restore fails when you use ResyncLuns VSS API in Windows Server 2012 R2-based failover cluster

https://support.microsoft.com/en-us/kb/3137728

https://support.microsoft.com/ja-jp/kb/3137728 (機械翻訳)

以上の通り、Windows Server バックアップにおける容量と世代管理についてお伝えいたします。

本ブログが皆様のお役に立てましたら、幸いです。

<参考情報>

- Windows Server バックアップ

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

- Windows 2008 R2 のバックアップと回復の概要

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

- サーバーをバックアップする

http://technet.microsoft.com/ja-jp/library/cc753528.aspx

– Backup Version and Space Management in Windows Server Backup

http://blogs.technet.com/b/filecab/archive/2009/06/22/backup-version-and-space-management-in-windows-server-backup.aspx

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

Windows Server 2012 R2 環境において、リモート デスクトップ サービスを展開しており、ユーザー プロファイル ディスク (UPD) を使用している環境で、スタート メニューやコンテキスト メニューの一部が英語表記になってしまう事象があります。

英語表記になる箇所は、以下の通りです。

• [コンテキスト メニュー] – [送る] 内の一部項目
• [スタート メニュー] – [すべてのアプリ] – [Windows アクセサリ] の一部
• [スタート メニュー] – [すべてのアプリ] – [Windows 簡単操作]
• [スタート メニュー] – [すべてのアプリ] – [Windows システム ツール] の一部

今回は、この英語表記になってしまう事象の原因と対処方法について、解説します。

1. ユーザー プロファイル ディスクについて
2. 原因
3. 対処方法

ユーザー プロファイル ディスクについて

まず、ユーザー プロファイル ディスクについて、簡単に紹介します。

ユーザー プロファイル ディスクは、Windows Server 2012 以降で使用できるようになりました。

これまで、複数のセッション ホストにログオンをする環境において、共有のユーザー プロファイルを使用するために、移動ユーザー プロファイルを使用していました。

しかし、移動ユーザー プロファイルは、ログオン/ログオフ時にプロファイル データをコピーする必要があり、プロファイルが大きくなればなるほど、コピーに時間もかかり、ネットワークへの負荷やログオン/ログオフ遅延が発生していました。

そこで、.vhdx 形式のイメージ ディスクを用いることで、一つのディスクとして管理できるようになりました。イメージ ディスクはマウントすることができ、ディスクのマウントによって、全てのデータをコピーすることなく、使用するデータを必要な時にコピー、書き込みを行うことで、ログオン遅延の解消や特定の時間帯 (朝、夕方等) のネットワーク負荷の軽減を実現しました。

リモート デスクトップ サービスで、ユーザー プロファイル ディスクを使用する場合は、[サーバー マネージャー] – [リモート デスクトップ サービス] – [コレクション] – [<コレクション名>] – [プロパティの編集] から、[ユーザー プロファイル ディスク] の項目で設定を行います。

この設定を行うことで、コレクションに参加しているセッション ホスト サーバーに接続を行うユーザーは、ユーザー プロファイル ディスクを使用できます。

ユーザー プロファイル ディスクの設定を行うと、保存先に UVHD-template.vhdx が作成されます。
これは、テンプレート プロファイルとなり、ユーザーの初回ログオン時に、この UVHD-template.vhdx をコピーして各ユーザーの VHD ファイルを作成します。
保存先には、”UVHD-<ユーザーの SID>” の形で、ユーザー プロファイル ディスクが作成され、次回以降この VHD ファイルをマウントして使用します。

原因

今回問題となっている 一部メニューの表記が英語になる 事象の原因は、各ユーザーの UPD 作成時にあります。各ユーザーの UPD 作成時は、先ほどもお伝えした通り、UVHD-template.vhdx からコピーを行い、作成します。このコピーの際、必要な “属性値” がコピーされないことによって、事象が発生します。

原因の説明にあたって、まずは日本語化の仕組みについて解説します。
皆さんが Windows を使用している時に、ふとこのようなことを思ったことはないでしょうか。

「エクスプローラーで見ると日本語なのに、ファイルのパスは英語になっている」

その通りです。実際確認すると、[デスクトップ] や [ドキュメント] 等は、以下のように異なっています。

Windows は、世界中の様々な言語で使用されています。しかし、各言語によってファイル パスが異なっていると、同じ処理をするにも、各言語でファイル パスを書き換えたものを使わないといけなくなってしまいます。
そのようなことを避けるために、ファイル パスは同じでも表記のみ各言語に変更する という仕組みが採用されています。この各言語への変更を管理しているのが “Desktop.ini” ファイルです。

Desktop.ini は、フォルダー名の表示言語やフォルダーのアイコン情報などを保持しています。
実際に今回、事象が発生する [コンテキスト メニュー] – [送る] の Desktop.ini を見てみましょう。
※Desktop.ini は OS で保護されたファイルなので、既定では表示されません。

[エクスプローラー] では、日本語表記になっており、[コマンド プロンプト] では、英語表記になっています。
このディレクトリ内の Desktop.ini を見てみると、”[LocalizeFileNames]” という項目があり、その下に各フォルダー名に対し、様々なパラメーターが書かれています。
この Desktop.ini の設定により、英語表記と日本語表記の両方を保持できる仕組みになっています。
ちなみに、試しにこの Desktop.ini を削除すると、英語表記に戻ってしまいます。
※Desktop.ini の削除は推奨されないため、削除しないでください

このことから、今回事象が発生した原因は、この Desktop.ini が正しく読み込まれていないということが考えられます。
では、正しく読み込まれない原因はどこにあるのでしょうか。

正常に日本語表記となっている環境と、事象が発生する環境でどの点が違うかを確認すると、Desktop.ini が格納されているフォルダーの属性値が異なっています。
属性値を確認する attrib コマンドで確認すると、このようになります。

正常な環境

C:\Users\Administrator\AppData\Roaming\Microsoft\Windows>attrib SendTo
     R       C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\SendTo
C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs>attrib Accessibility
     R       C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessibility
C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs>attrib Accessories
     R       C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessories
C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs>attrib "System Tools"
     R       C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\System Tools

事象が発生している環境

C:\Users\test01\AppData\Roaming\Microsoft\Windows>attrib SendTo
             C:\Users\test01\AppData\Roaming\Microsoft\Windows\SendTo
C:\Users\test01\AppData\Roaming\Microsoft\Windows\Start Menu\Programs>attrib Accessibility
             C:\Users\test01\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessibility
C:\Users\test01\AppData\Roaming\Microsoft\Windows\Start Menu\Programs>attrib Accessories
             C:\Users\test01\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessories
C:\Users\test01\AppData\Roaming\Microsoft\Windows\Start Menu\Programs>attrib "System Tools"
             C:\Users\test01\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\System Tools

今回事象が確認できているフォルダーに対して、”R (読み取り専用) 属性” が付与されていません。
これは、UVHD-template.vhdx から UPD を作成する際に、属性値を正しくコピーできなかったことが原因となっております。属性値が付与されなかったため、正しく Desktop.ini が解釈されず、事象が発生しております。

対処方法

既に UPD が作成されているユーザー と UPD が作成されていないユーザーで、対処方法が異なります。

■ UPD が作成されていないユーザー

今後、サーバーへ接続し、UPD を作成するユーザーについては、テンプレートとなる UVHD-template.vhdx に対処を行うことで、事象が改善されます。

以下の手順で、UVHD-template.vhdx をカスタマイズします。

1. まず、正常に日本語表記になっている環境 (例えば、UPD を使用していない環境) にログオンします。
   ※できるだけ、ソフトウェアのインストールやカスタマイズのされていないユーザーをご利用ください。
   ※同じ OS のバージョンをご利用ください。
2. 冒頭で記載した 4 つの項目について、正常に日本語表記になっていることを確認します。
3. そのユーザーで以下の場所を [エクスプローラー] で開きます。

   %USERPROFILE%\AppData\Roaming\Microsoft\Windows

4. 以下のフォルダーを抽出し、UPD を格納しているサーバーへ配置します。
   ・SendTo
   ・スタート メニュー
5. UPD を格納しているサーバーへ、管理者権限のあるユーザーでログオンします。
6. UPD の格納フォルダーを [エクスプローラー] で開きます。
7. “UVHD-template.vhdx” を右クリックし、[マウント] をクリックします。
   
8. UVHD-template.vhdx がマウントされるので、以下のフォルダーを作成します。

   [AppData]
   　- [Roaming]
   　　- [Microsoft]
   　　　- [Windows]

9. 手順 8. で作成した AppData\Roaming\Microsoft\Windows\ 内に、手順 4. でコピーした [SendTo] と [スタート メニュー] のフォルダーを配置します。
   
10. [エクスプローラー] より、マウントした UVHD-template.vhdx を右クリックし、[取り出し] をクリックします。
    
11. 新規ユーザーで UPD 環境にログオンを行い、正常に日本語表記になっているか、確認します。

■ 既に UPD が作成されているユーザー

既に UPD が作成されているユーザーについては、[送る] は属性値の付与のみで改善されますが、[スタート メニュー] については、残念ながら属性値の付与のみでは改善されません。
[送る] と [スタート メニュー] に分けて手順を説明します。

—- [送る] —-

1. 事象が発生しているユーザーでログオンします。
2. [コマンド プロンプト] を起動します。
3. 以下のコマンドを実行し、”読み取り専用” 属性を付与します。

   > attrib +R %USERPROFILE%\AppData\Roaming\Microsoft\Windows\SendTo

4. 念のため、以下のコマンドで、正しく属性が付与されていることを確認します。

   > attrib %USERPROFILE%\AppData\Roaming\Microsoft\Windows\SendTo
        R       C:\Users\test01\AppData\Roaming\Microsoft\Windows\SendTo

5. ユーザーをログオフし、再ログオン後、日本語化されていることを確認します。
   

—- [スタート メニュー] —-

1. 事象が発生しているユーザーでログオンします。
2. [コマンド プロンプト] を起動します。
3. 以下のコマンドを実行し、3 つのフォルダーに対し、”読み取り専用” 属性を付与します。

   > attrib +R "%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessibility"
   > attrib +R "%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessories"
   > attrib +R "%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\System Tools"

4. 念のため、以下のコマンドで、正しく属性が付与されていることを確認します。

   > attrib "%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessibility"
        R       C:\Users\test01\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessibility
   > attrib "%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessories"
        R       C:\Users\test01\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessories
   > attrib "%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\System Tools"
        R       C:\Users\test01\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\System Tools

5. [エクスプローラー] で以下の場所を開きます

   %USERPROFILE%\AppData\Roaming\Microsoft\Windows

6. [スタート メニュー] – [プログラム] 内の以下のフォルダーが、日本語表記になっていることを確認します。
   ・ Windows アクセサリ (英語表記: Accessories)
   ・ Windows システム ツール (英語表記: System Tools)
   ・ Windows 簡単操作 (英語表記: Accessibility)

   属性付与前	属性付与後

7. %USERPROFILE%\AppData\Roaming\Microsoft\Windows にある [スタート メニュー] フォルダーを、任意の場所にコピーします。
   
8. コピー終了後、%USERPROFILE%\AppData\Roaming\Microsoft\Windows 内の [スタート メニュー] フォルダーを削除します。
   ※[スタート メニュー] フォルダーの削除は、[Shift] + [Del] キーを押して、完全に削除してください。
   右クリック – [削除] をされた場合は、[ごみ箱] にて [ごみ箱を空にする] を実施してください。
9. 手順 6. で退避させた [スタート メニュー] フォルダーを、%USERPROFILE%\AppData\Roaming\Microsoft\Windows に配置します。
   
10. ユーザーをログオフし、再ログオン後、日本語化されていることを確認します。
    

以上が、日本語表記に戻す手順となります。

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

Windows Server 2012 または Windows Server 2012 R2 のリモート デスクトップ サービス環境をご利用いただいている環境で、適切に RD ライセンス サーバーを指定しているにも関わらず、クライアントからの接続時に以下メッセージが表示され、接続できない場合があります。

本エラーについては、RDS CAL に発行余力がない場合や、RD セッション ホスト サーバーとライセンス サーバー間で疎通が取れない場合に発生いたしますが、既知の不具合にて発生する場合があります。
以下をチェックし、設定に問題がない場合は、OS バージョンに応じて後述の修正プログラムの適用をご検討ください。

事前確認項目
================
1. RDS CAL (ライセンス) に発行余力はありますか？

ライセンス サーバーで [RD ライセンス マネージャー] を起動してください。
RD ライセンス サーバーがアクティブ化されている事と、OS に応じてインストールいただいた RDS CAL について、[利用可能] 欄に余力がある事をご確認ください。
[利用可能] が 0 の場合は、発行できる RDS CAL が残っていませんので、適切な数量の RDS CAL の購入、インストールをお願いいたします。

2. ライセンス診断にエラーや警告はありませんか？

RD セッション ホスト サーバーで、[RD ライセンス診断] を実行してください。
([RD ライセンス診断] は、サーバー マネージャーから [ツール] – [Terminal Services] – [RD ライセンス診断機能] で実行できます)

以下の通り、エラーや警告が表示されていない事をご確認ください。
エラーや警告が発生している場合は、内容を確認し、適切な処置を実施してください。

3. レジストリを確認してください

上記確認までで、RDS CAL の数が足りている事、RD セッション ホストと RD ライセンス間の通信に問題がない事が確認できたら、以下の手順でレジストリを確認します。

3-1. RD セッション ホスト サーバーでレジストリ エディターを起動します。([ファイル名を指定して実行] で “regedit” で起動します)
3-2. 以下まで展開します。

HKEY_LOCAL_MACHIN\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM

3-3. 左ペインで [RCM] キーを選択した状態で、右ペインに [X509] から始まる名前のレジストリが存在しているかを確認します。
正常な場合、以下の通りのレジストリが存在します。

3-4. [X509] から始まる名前のレジストリが存在していない場合、既知の不具合に該当している可能性がございます。
次項の手順にて、修正プログラムの適用をお願いいたします。

修正プログラムの適用について
===========================

本不具合は、RD セッション ホスト サーバーが、適切な RD ライセンス サーバーを指定する事で生成されるはずの X.509 証明書が生成されない事が要因となっています。
RD セッション ホスト サーバーの OS バージョンに応じて、修正プログラムの適用をお願いいたします。

A. Windows Server 2012 の場合
——————————————

下記修正プログラムを RD セッション ホスト サーバーに適用してください。

Windows Server 2012 の RDS ファームに接続するときに RDS ライセンスがなしと示される
https://support.microsoft.com/ja-jp/kb/2916846

上記修正プログラムを適用後、再起動した後に RD ライセンス診断を実施し、改めて [X509] レジストリが作成されているかを確認します。

※ 適用後、タイミングによってはすぐに [X509] レジストリが作成されない事もございますが、RD ライセンス診断や、クライアントからの接続を何度か繰り返していただく事で作成されます。

B. Windows Server 2012 R2 の場合
———————————————–

下記修正プログラムを RD セッション ホスト サーバーに、上から順番に適用してください。

1. Windows RT 8.1、Windows 8.1、および Windows Server 2012 R2 のサービス スタック更新プログラムが利用できます: 2014 年 3 月
   https://support.microsoft.com/ja-jp/kb/2919442
2. Windows RT 8.1、Windows 8.1、および Windows Server 2012 R2 の更新プログラム: 2014 年 4 月
   https://support.microsoft.com/ja-jp/kb/2919355
3. Windows RT 8.1、 Windows 8.1、および Windows Server 2012 R2 用の2014年5月の更新プログラム ロールアップ
   https://support.microsoft.com/ja-jp/kb/2955164/

上記修正プログラムを適用後、再起動した後に RD ライセンス診断を実施し、改めて [X509] レジストリが作成されているかを確認します。

※ 他の Windows Update やセキュリティ更新プログラムによって、適用できない更新がある場合もございますが、その場合は飛ばして構いません。
[X509] レジストリが作成されない不具合については、KB2955164 が対応しています。
※ 適用後、タイミングによってはすぐに [X509] レジストリが作成されない事もございますが、RD ライセンス診断や、クライアントからの接続を何度か繰り返していただく事で作成されます。

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

Windows 8.1 をご利用いただいている環境でコンピューター名にサロゲート ペアを指定すると Windows Event Log サービスが開始しない問題があります。
Windows 8.1 以前の環境ではコンピューター名にサロゲート ペアを使用できない為、本問題は発生しません。

※ サロゲート ペアは Unicode の拡張文字で U+DBFF ～ U+D800 と U+DFFF ～ U+DC00 の範囲のコード値を使用します。

本条件を満たした場合、サービス管理ツールから Windows Event Log サービスを起動しようとしても、下記エラーとなり起動できない状況となります。

なお、現時点でWindows Event Log サービス以外の Windows 標準サービスに対しての影響は確認されておりません。

本エラーの回避策は以下のいずれかとなります。Windows 8.1 での本問題に対する修正は予定されておりません。

・コンピューター名にサロゲート ペアを使用しない
・本問題が解消されている Windows 10 を使用する

サロゲート ペアにつきましては、以下の内容をご参照頂けますと幸いです。

特殊文字 : サロゲート ペア
https://msdn.microsoft.com/ja-jp/library/cc419800.aspx

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

今回は Windows 10 Version 1511 にてリモート コンピューターに対しイベントが作成されない問題についてご紹介いたします。

Windows OS ではユーザーが任意のイベントを出力できる方法を提供しており、例として eventcreate コマンドがございます。また、eventcreate コマンドでは /S オプションを用いることで、リモート コンピューター上のイベントログにイベントを作成することが可能です。

しかし、Windows 10 Version 1511 をご利用いただいている環境で eventcreate を利用し、他の OS 上にイベントを作成しようとすると、下記のエラーが表示されます。

> eventcreate /S …
エラー: プロシージャ番号が正しい範囲にありません。

この問題は Windows 10 Version 1511 から以前の OS (Version 1511 以前の Windows 10 や、Windows 8.1, Windows Server 2012 R2 等) に対してイベントの作成を行おうとすると発生します。これは、Windows 10 Version 1511 で追加されたイベント記録のための関数が過去の OS に存在せず、この関数の有無を考慮していない実装のためとなります。なお、上記の理由のため、Windows 10 Version 1511 同士でのリモート コンピューターに対するイベントの作成では正常に動作します。

この動作は、8 月 2 日 (米国時間) 公開予定の Windows 10 Anniversary Update にて修正され、以前の OS に対しても正しくイベントの作成を行えるようになります。

Microsoft announces Windows 10 anniversary update available Aug. 2
http://news.microsoft.com/2016/06/28/microsoft-announces-windows-10-anniversary-update-available-aug-2/#sm.000norvcb16sre4zzif1vk70zcqcd

動作の修正まで今しばらくお待ちいただきますようお願い申し上げます。

– 影響範囲:
eventcreate コマンドならびに WshShell.LogEvent メソッド , Write-EventLog コマンドレット, System.Diagnostics.Eventlog.WriteEntry メソッド についても該当します。

– 回避方法:
リモート処理セッションの作成を通じて、任意のコンピューター上にイベントを作成することは可能です。（この場合、資格情報の入力が必要となります）

[WinRM を利用した Write-EventLog の実行例]
$session = New-PSSession -ComputerName コンピューター名 -Credential アカウント名
Invoke-Command -Session $session -ScriptBlock { Write-EventLog -LogName Application -EntryType Information -Source “TestSource” -EventId 1 -Message “TestMessage” }

– 参考情報:
Eventcreate
https://technet.microsoft.com/ja-jp/library/cc755240.aspx
/S オプションを用いることで、リモート コンピューターを指定できます。

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

今回は、Windows 8 および Windows Server 2012 以降のタスク スケジューラでお問い合わせの多い、UBPM と呼ばれる実行エンジンの注意事項についてご紹介させていただきます。

■ タスク スケジューラで使用されている 2 つの実行エンジンについて

Windows 7、および Windows Server 2008 R2 以降のタスク スケジューラでは、従来の実行エンジンと合わせて、Unified Background Process Manager (UBPM) と呼ばれる実行エンジンが利用されるようになりました。

しかしながら、弊社では、UBPM を利用して起動されるタスクの動作が、従来の実行エンジンで動作するタスクとは違った動作をすることが確認されております。

本ブログでは、UBPM 利用時における注意点について、弊社問い合わせ事例などを紹介させていただきます。

■ 実行エンジンの違いによる問い合わせ事例について

UBPM を利用して実行されるタスクでは、従来の実行エンジンと比較して以下のような動作の違いが報告されております。

(1) “タスクの実行時に使うユーザー アカウント” に “ユーザーがログオンしているかどうかにかかわらず実行する” が選択されている場合、”最上位の特権で実行する” のチェックが外れていても常に最上位の特権で動作します。

管理者ユーザーを利用して、以下のようにタスクを設定した場合、従来の実行エンジンではユーザー アカウント制御 (UAC) の機能により制限された権限でタスクが動作しますが、UBPM では完全な権限でタスクが動作します。

従来の実行エンジンで実行されたタスクは制限された権限でタスクが動作しています。

UBPM で実行されたタスクは完全な権限でタスクが動作しています。

(2) タスクを開始するまでのコンピューターのアイドル時間は無視されます。

タスクの実行条件として “タスクを開始するまでのコンピューターのアイドル時間” を設定した場合、従来の実行エンジンでは指定された時間アイドル状態が継続された場合にタスクが実行されますが、UBPM ではトリガーが成立するとタスクがすぐに実行されることが報告されております。

■ タスクの実行エンジンを見分ける方法について

タスクが従来の実行エンジンで実行されているか、UBPM で実行されているかどうかを見分けるには、以下のような方法があります。

(1) 親プロセスが svchost.exe であるか、taskeng.exe であるか

UBPM で実行されているタスクは svchost.exe が親プロセスとなります。
従来の実行エンジンで実行されているタスクは taskeng.exe が親プロセスとなります。

(2) タスクの履歴に ID 319 のイベントが記録されるかどうか

従来の実行エンジンで起動されるタスクは、タスクの履歴にイベント ID 319 が記録されます。
UBPM で実行されているタスクはタスクの履歴にイベント ID 319 が記録されません。

■ タスクを 従来の実行エンジンで実行するには

タスクの以下のような設定変更を行うことで、タスクの実行エンジンが従来のタスクエンジンに切り替わることを確認しております。

(1) “タスクがすでに実行中の場合に適用される規則” を “既存のインスタンスを停止する” に変更する。

以下のように、タスクの設定画面にて “タスクがすでに実行中の場合に適用される規則” を “既存のインスタンスを停止する” に変更すると、当該タスクは従来のタスク エンジンで実行されるようになります。

弊社のお問い合わせ事例におきましても、タスクの実行エンジンの違いにより問題が発生していることが疑われる場合には、UBPM で実行されるタスクを従来の実行エンジンで実行するよう設定を変更する、または従来の実行エンジンで実行されているタスクを UBPM で実行するよう設定を変更する。といった切り分けをご提案させていただくことがございます。

本ブログの注意事項で記載した事象が発生しました場合には、タスクの実行エンジンを切り替え、状況が変わるかどうかをご確認いただけますと幸いです。

■ 最後に

タスクスケジューラーで新たに使用されるようになった UBPM は便利な機能ですが、扱いには注意が必要です。
弊社では、UBPM をご利用時の注意事項について、本ブログを積極的に更新していきたいと思います。
今後ともどうぞよろしくお願いします

本日は、Hyper-V クラスター環境で全ノードで、クラスター サービスを停止させる場合の仮想マシンの状態について説明します。

全ノードでクラスター サービスが停止される場合にはクラスターはすべてのリソースに対してオフライン作業を実施します。そのため、仮想マシン リソース内部の状態については、“クラスター制御されたオフライン操作” というプロパティの値で決められた設定に従います。

<参考> 仮想マシンの <リソース名> プロパティ : [設定] タブ

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

————————

保存 :

仮想マシンをオフラインにする前に、クラスターで仮想マシンの状態を保存します。これにより、仮想マシンがオンラインに戻ったときにこの状態を復元できるようにします。これは既定の設定です。

シャットダウン :

仮想マシンをオフラインにする前に、仮想マシン上のオペレーティング システムのシャットダウンをクラスターで適切な順序で実行します (すべてのプロセスが終了するのを待機する)。

シャットダウン (強制) :

反応が遅いプロセスが終了するのを待たずに、仮想マシン上のオペレーティング システムのシャットダウンをクラスターで実行し、仮想マシンをオフラインにします。

停止 :

仮想マシンをオフラインにする前に、オペレーティング システムをシャットダウンせずにクラスターで仮想マシンを停止します。この操作は電源をオフにする場合と同じであり、データが失われる可能性があります。

————————

“クラスター制御されたオフライン操作” は、仮想マシン リソースをオフラインにするときにクラスターが実行する操作です。

この設定については Windows PowerShell またはアプリケーションを使用してリソースを移動する場合や、リソースをオフラインにする場合のみ影響し、ライブ マイグレーション、クイック マイグレーション、または計画外のフェールオーバー時には影響しません。

また、ノード (Hyper-V ホスト) がシャットダウンされる場合の仮想マシンの動作として、VMMS (仮想マシン管理サービス) により管理される “自動停止アクション” の設定がありますが、仮想マシンがクラスターのリソースとして登録されている場合には、上述の “クラスター制御されたオフライン操作” により仮想マシンの状態が決定されますので、仮想マシンの設定についてはご注意をお願いします。

<参考> 仮想マシンの設定

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

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

Windows プラットフォーム サポート 三浦です。

本日は Windows 10 のリモート デスクトップ接続に関して紹介させて頂きます。

Windows 10 のリモートデスクトップ接続 (mstsc.exe) では、Windows 8.1 までに存在した [プログラム] – [接続時に次のプログラムを起動する] オプションがなくなっています。
今回は、Windows 10 を使用する環境でも同様の機能を実現するためのポリシーをご紹介します。

[Windows 7]

[Windows 10]

Windows 10 でも [接続時に次のプログラムを起動する] と同様の動作を実現するには、接続先 RD セッションホストにて以下のグループ ポリシーを設定する必要があります。

コンピューターの構成
　- 管理用テンプレート
　　- Windows コンポーネント
　　　　- リモートデスクトップ サービス
　　　　　　- リモート デスクトップ セッション ホスト
　　　　　　　- リモート セッション環境

[接続時にプログラムを起動する]

上記ポリシーを “有効” に設定し、プログラムパスとファイル名にアプリケーションを指定します。
なお、このポリシーは、接続先において RD セッションホストの役割がインストールされている場合のみ使用可能です。

– 参考文献 –
リモート デスクトップ接続の接続時に起動するプログラムを指定する
https://technet.microsoft.com/ja-jp/library/cc782233(WS.10).aspx

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

本日は、WSFC 環境でパッシブのクラスター ノード再起動後にノード間通信失敗する事象についてご紹介します。

クラスター環境では、各クラスター ノードのメモリ上に他のノードとのコネクション情報を保持しています。
本コネクション情報はノード間通信で使用されますが、クラスターノードが起動したタイミングや他ノードとのネットワークが接続されたタイミングで構成され、ノードが停止したタイミングやネットワークが切断されたタイミングで削除されます。

しかしながら、稀に削除が実施されるべきタイミングで削除が正常に行われず、コネクション情報が残存してしまい、クラスター サービスの起動に問題が発生することが報告されております。

具体的には、パッシブのクラスター ノードを再起動した際に、アクティブのノード上でパッシブ ノードのコネクション情報が残ってしまうために、ノード間通信の失敗が発生する事例が弊社に複数寄せられております。

例として、以下、クラスター 2 ノード (WSFC1、WSFC2) の環境において説明いたします。

通常、パッシブ ノードである WSFC2 を再起動すると、アクティブ ノード WSFC1 では WSFC2 と接続が切断されるため WSFC2 のコネクション情報は削除されます。そして、パッシブ ノード起動後アクティブ ノード WSFC1 はパッシブ ノードとのネットワークが接続されたタイミングで、パッシブ ノード WSFC2 からコネクション情報を受け取り、ノード間通信を行います。

しかしながら、パッシブ ノードを再起動した際にアクティブ ノード WSFC1 上にコネクション情報が残る事象が発生した場合、パッシブ ノードと接続された際にパッシブノードから受け取るコネクション情報が既に保持しているコネクション情報と重複しているためアクティブノードで破棄する処理を行い、再接続を拒否します。
そのため、アクティブ ノードとパッシブ ノードの間で通信が行えない問題が発生します。

本事象が発生した際はパッシブ ノードのシステムログ上に以下のログが記録されます。

————
ログの名前  : System
ソース      : EventLog
イベント ID : 1135
レベル      : 重大
説明:
クラスター ノード ‘<クラスターノード名>’ がアクティブなフェールオーバー クラスター メンバーシップから削除されました。クラスター サービスがこのノードで停止されている可能性があります。また、このノードがフェールオーバー クラスター内の別のアクティブなノードと通信できないことが原因である可能性もあります。構成の検証ウィザードを実行して、ネットワーク構成を確認してください。状況が変化しない場合は、このノードのネットワーク アダプターに関連するハードウェアまたはソフトウェアのエラーがないか確認してください。また、ハブ、スイッチ、ブリッジのような、ノードが接続されている他のネットワーク コンポーネントにエラーがないか確認してください。
————

また、アクティブ ノードのクラスター ログでは、パッシブとの接続時の処理で以下のログが記録されます。

————
INFO  [Reconnector-<パッシブ クラスターノード名>] Reconnector from epoch 1 to epoch 2 waited xx so far.
:
:
INFO  [FTI] Got new raw TCP/IP connection.
INFO  [FTI][Follower] This node (<ノード番号>) is not the initiator
// パッシブ ノードから返ってきたコネクションが重複しているため拒否
WARN  [FTI][Follower] Ignoring duplicate connection: route to remote node found
:
:
// コネクションは closed される
WARN  mscs::ListenerWorker::operator (): GracefulClose(1226)’ because of ‘channel to remote endpoint <パッシブ ノード IP アドレス>:~ <ポート番号> ~ is closed’
————

========================================
本事象の発生後のクラスター動作について
========================================

本事象が発生した場合は、ノード間通信に失敗するためにノード間通信のリトライ処理が定期的に行われます。しかしながらアクティブ ノードではコネクション情報が残っている状態でリトライ処理が行われるため全て失敗してしまいます。

そのため、クラスターとしてはノード間で通信できない状況のため対象パッシブ ノードは停止していると判断されクラスターに参加できない状態が発生する場合があります。
尚、クラスターは対象パッシブ ノードを除くクラスター ノードとクォーラムで動作します。

=========
対処方法
=========

本事象はアクティブ ノードのメモリ上にコネクション情報が不正に残っているために発生します。そのため、本事象が発生した場合は、アクティブ ノードのクラスター サービスを再起動することにより対処可能です。再起動によりアクティブ ノードが保持していた不正なコネクション情報は削除され、パッシブ ノードとの通信が正常に行われます。

クラスター ログから同様の状況であることが確認できましたら、アクティブ ノードの再起動を試すことをご検討ください。