Quantcast
Channel: Ask CORE
Viewing all 590 articles
Browse latest View live

Azure 仮想マシン (IaaS VM) のバックアップ方法について

$
0
0

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

今回は仮想マシンをバックアップする手順についてご案内させていただきます。

現状 (1 月 14 日) は V1 ”クラシック” の仮想マシンにおいては  IaaS バックアップが可能ですが、V2 の仮想マシンにおいては IaaS バックアップはサポートされておらず、VHD の情報をコピーして、その情報を基に復元する必要がございます。以下それぞれの手順についてご紹介させていただきます。


V1 の仮想マシンのバックアップ方法について
======================================================================
以下弊社公開情報より Azure Backup による Azure 上の仮想マシンのバックアップ手順が記載されております。画面ピクチャ付きの手順となりますので、以下の手順を参考に仮想マシンのバックアップを実施ください。
 
タイトル: Azure 仮想マシンのバックアップ
https://azure.microsoft.com/ja-jp/documentation/articles/backup-azure-vms/
 
事前準備および構成の計画については以下の URL をご参照ください。
 
タイトル: Azure 仮想マシンをバックアップする環境の準備
https://azure.microsoft.com/ja-jp/documentation/articles/backup-azure-vms-prepare/
 
タイトル: Azure における VM バックアップ インフラストラクチャの計画を立てる
https://azure.microsoft.com/ja-jp/documentation/articles/backup-azure-vms-introduction/
 
 
・リストアの手順について
============================================
以下の公開情報を参考に仮想マシンの復元を実行出来ます。
 
タイトル: Azure での仮想マシンの復元
https://azure.microsoft.com/ja-jp/documentation/articles/backup-azure-restore-vms/
 
・バックアップ データの削除方法について
============================================
以下の公開情報を参考に仮想マシンの登録を解除し、仮想マシンに関連付けられているバックアップ データを削除ください。
 
タイトル: 仮想マシンの保護を停止する
https://azure.microsoft.com/ja-jp/documentation/articles/backup-azure-manage-vms/#-2
 
タイトル: バックアップ データの削除
https://azure.microsoft.com/ja-jp/documentation/articles/backup-azure-manage-vms/#-5
 
 


V2 の仮想マシンのバックアップ方法について
======================================================================
V2 の仮想マシンについては、現状として IaaS のバックアップはサポートされておらず、VHD の情報をコピーして、その情報を基に復元する必要がございます。その為、後述の手順よりバックアップおよび復元を実施ください。
 
以下のコマンドレットは、VHD ファイルの Blob をコピーするコマンドレットであり、コピーを取得している期間中、対象の VHD ファイルの読み書きが発生します。そのため、オンラインでバックアップを実行した場合、データ内容に不整合が生じる可能性がございます。運用要件上、許容されるダウンタイムが少ない場合や、オンラインでバックアップを取得する必要がある場合は、事前に Blob のスナップショットを作成する方法が有効でございます。Blob のスナップショット作成手順も併せてご案内いたしますので、必要に応じご参照ください。
 
なお、SQL 等ファイル レベルではなくアプリケーション レベルでの整合性を必要とするデータをバックアップする場合、整合性を保てない状態でバックアップが取得される可能性があるため、対象の仮想マシンが停止している状態での実行を推奨します。
 
これらの方法にてコピーされた Blob から起動可能であることは確認しておりますが、ご利用の際には、リストアの手順も含めてお客様環境にて十分なテストを行った上で、運用に組み込んでいただきますようお願いいたします。
 
- 現在の仮想マシン データを別の VHD として保存します。
============================================
1.現在の仮想マシンの構成情報を確認します。
    実行コマンド1 : $VMinfo = Get-AzureRmVM -Name ”仮想マシン名” -ResourceGroupName ”リソース グループ名”
    例: $VMinfo = Get-AzureRmVM -Name 2008r2d1 -ResourceGroupName 2008r2d1
    リソース グループ名については、新ポータルより ”仮想マシン” - ”対象の仮想マシン” を選択すると画面左上より確認出来ます。
 
    実行コマンド2 : $VMinfo.StorageProfile.OSDisk.VirtualHardDisk.Uri 
 
2.上記実行コマンド 2 より仮想マシンの OS ディスクの情報を確認します。

     実行結果例:  https://2008r2d19472.blob.core.windows.net/vhds/2008R2D1.vhd


     "コピー元ストレージ アカウント名" = 2008r2d19472
     "コピー元コンテナー名" = vhds
     "コピー元 Blob 名" =2008R2D1.vhd
 
3.Azure の新ポータルより、コピー元ストレージ アカウントのアクセス キーを確認します。
     3.1 新ポータルより "ストレージ アカウント" を選択します。
     3.2 対象のストレージ アカウントをクリックします。対象のストレージ アカウントは手順 2 で実行した "コピー元ストレージ アカウント名" と同様です。
     3.3 画面中央部より鍵のマークをクリックします。
     3.4 "KEY1" をメモします。
 
4.同じコンテナー上にデータをバックアップする場合には、コピー先およびコピー元は同じ情報を使用します。もし他のコンテナーや他の仮想マシンのコンテナーにバックアップする場合には、上記手順に従い、移行先の仮想マシンを対象に 1 ~ 3 の手順を実行します。
 
5.以下の 2 つコマンドを実行し、対象の仮想マシンの BLOB をコピーします。
    - 仮想マシンの情報を記載し実行します。
    $SourceStorageAccountName = "コピー元ストレージ アカウント名"
    $SourceStorageAccountKey = "コピー元ストレージ アカウントのアクセス キー"
    $SourceContainerName = "コピー元コンテナー名"
    $SourceBlobName = "コピー元 Blob 名"
    $DestStorageAccountName = "コピー先ストレージ アカウント名"
    $DestStorageAccountKey = "コピー先ストレージ アカウントのアクセス キー"
    $DestContainerName = "コピー先コンテナー名"
    $DestBlobName = "コピー先 Blob 名 (任意)"
    $Ctx = New-AzureStorageContext -StorageAccountName $SourceStorageAccountName -StorageAccountKey $SourceStorageAccountKey
    $blob = Get-AzureStorageBlob -Context $Ctx -Container $SourceContainerName -Blob $SourceBlobName
    $snap = $blob.ICloudBlob.CreateSnapshot()
    $DestContext = New-AzureStorageContext -StorageAccountName $DestStorageAccountName -StorageAccountKey $DestStorageAccountKey
 
    - BLOB のコピーを実施します。
    Start-AzureStorageBlobCopy -SrcUri $snap.SnapshotQualifiedUri -SrcContext $Ctx -DestContext $DestContext -DestContainer $DestContainerName -DestBlob $DestBlobName
  
 
- バックアップした VHD を仮想マシンに接続します。
============================================
6.Azure の新ポータルの "仮想マシン" - ”すべての設定” - ”ディスク” を選択します。
7.画面上部より "既存のディスクの接続" を選択します。
8."必要な設定の構成" - ”対象のストレージ アカウント” - ”対象のコンテナー名” をクリックします。
9.コンテナーの画面より手順 5 にて指定した Blob (DestBlobName) を選択し ”選択”をクリックします。(画面上に無い場合には ”更に読み込む” をクリックし、すべての表示します。)
10.”既存ディスクの接続” 画面より ”OK” をクリックします。
 
 
- バックアップした VHD よりデータを移行します。
============================================
11.仮想マシンを起動し接続します。
12.エクスプローラーを起動し、新しいディスクが接続されている事を確認します。(ドライブ レターが割り振られていない場合にはディスクの管理より設定ください。)
13.データを新しく接続したディスクから、既存のディスクにコピーします。
 
 
- 接続したディスクを取り外します。
============================================
14.仮想マシンをシャットダウンします。
15.Azure の新ポータルの左ペインより "仮想マシン" を選択します。
16.中央ペインより対象の仮想マシンを選択し ”すべての設定” - ”ディスク” をクリックします。
17.取り外すディスクをクリックします。
18.  画面上部より ”切断” をクリックし ”はい” をクリックします。
 
 
以上でデータ移行が完了します。


MARS (Microsoft Azure Recovery Service) エージェントのアップグレード方法について

$
0
0

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

今回はオンプレミスおよび Azure VM のデータをバックアップする際に必要となる MARS エージェントのアップグレード方法についてご案内いたします。
まずは、MARS エージェントの概要およびアップグレードが必要となる理由についてご説明いたします。

- MARS エージェントとは
---------------------------------------------------------------------
オンプレミスまたは Azure VM のデータをバックアップする際に必要となるサービスであり、このサービスにより Azure 上へのデータ転送やバックアップの処理が行われます。


- アップグレードを推奨している理由について
---------------------------------------------------------------------
以前の MARS エージェント (2.0.9022 より前) においては、バックアップ・リストアにおける処理時間が長い、またバックアップ処理に失敗する問題等が多数発生しておりました。それらの問題はバージョン 2.0.9022 で修正されており、解決される事を確認しております。その為、バックアップおよびリストアの処理等で問題が発生する場合には、最新版へアップグレードして問題が解決されるかご確認くださいますようお願いいたします。また今後も同様に改善が行われていきますので、定期的にアップグレードいただけますと幸いです。

以下、2016 年 1 月 19 日時点での最新版の MARS エージェント情報をご案内させていただきます。

タイトル:Azure Backup optimization update: December 2015
https://support.microsoft.com/en-us/kb/3109750
https://support.microsoft.com/ja-jp/kb/3109750 (日本語機械翻訳版)
修正点
・Azure バックアップの時間を最大 50 % 削減しております。
・必要なキャッシュ領域を 15 % から 5 % に削減しております。
・保存出来るバックアップ コピー数が 366 から 9999 に増加しております。
・その他、バックアップ出来ない障害 (また完了はするがエラーが検知される問題) を修正しております。


- MARS エージェントのアップグレード方法について
---------------------------------------------------------------------
1.以下の URL より最新版の MARS エージェントをダウンロードします。
      http://aka.ms/azurebackup_agent
2.ダウンロードした "MARSAgentInstaller.exe" を対象のサーバーで実行します。
3.更新プログラムをインストールするかの画面では [次へ] をクリックします。
4.インストールの画面では必要なソフトウェアのアップグレードをするかのメッセージが表示されますので、[アップグレード] をクリックします。
5.アップグレードが完了した事を確認し [完了] をクリックします。

以上でアップグレードの手順は完了です。

- MARS エージェントのバージョンの確認方法について
---------------------------------------------------------------------
1.[コントロール パネル] - [プログラム] - [プログラムの機能] をクリックします。
2.中央画面より "Microsoft Azure Recovery Services Agent" の "バージョン" タブを確認します。


- MARS エージェントのアップグレード自動化について
---------------------------------------------------------------------
現状としては MARS エージェントを自動でアップグレードする方法はございません。尚、今後機能として追加するよう、弊社開発部門にて検討しております。以下フィードバック サイトから機能改善要望を発行する事も可能ですので、自動アップグレード機能の要望がございます際には、VOTE をクリックいただけますと幸いです。

タイトル: Automatic Update of Microsoft Azure Recovery Services Agent
https://feedback.azure.com/forums/258995-azure-backup-and-scdpm/suggestions/7449796-automatic-update-of-microsoft-azure-recovery-servi

フェールバックの動作について

$
0
0

こんにちは。Windows プラットフォーム サポートの加藤です。
本日は、フェールオーバー クラスターの機能のひとつであるフェールバックについてご紹介させていただきます。


■フェールバックとは
フェールバックとは、障害が発生したノードが再び利用できる状態になった時点で、フェールオーバーにより移動したサービスまたはアプリケーションが既定のノードへ自動的に移動する設定です。
既定値では無効となっていますが、[フェールバックを許可する] を有効にすることで設定いただくことができます。


以下、フェールバックの動作について Node 1 , Node 2 の 2 台のノードでクラスターを構成する環境を例にご紹介させていただきます。

(1) 通常稼働状態

通常時の構成は、下記の図のように仮想マシンを 2 台ずつそれぞれのノードがホストする構成です。
仮想マシン 1 (VM 1 :以下仮想マシンは VM と記載)、VM 2 は優先所有者を Node 1 として [フェールバックを許可する] を設定しています。

Node 1 : VM 1、VM 2
Node 2 : VM 3、VM 4

(2) 障害の発生 (クラスター サービスの停止)

Node 1 で何らかの障害が発生し、Node 1 のクラスター サービス (または OS ) が停止したとします。
 

(3) フェールオーバー

Node 1 でクラスター サービスが停止したことにより、Node 1 でホストしていたサービスやアプリケーション (今回は VM 1、VM 2) は Node 1 上で提供することが不可能となるため、Node 2 にフェールオーバーします。

 

(4) フェールバック

Node 1 を対象としてフェールバックの設定を許可しているサービスやアプリケーション (今回は VM 1、VM 2) は Node 1 のクラスター サービスが再び利用できる (起動) 状態になった時点で自動的に Node 1 へ移動します。
優先所有者ノードに設定したノードへサービスやアプリケーション  (今回は VM 1、VM 2) が自動的に移動する動きがフェールバックです。

 


上述の例でご紹介させていただきました通り、クラスター環境が障害から復旧する際には手動で設定変更をいただかずに既定値の状態に戻すことができ、またフェールバックを設定いただくことで、クラスターを構成するノードの正常稼動時にどのリソースをどのノードでホストするか明示的に指定することが可能です。
そのため、下記のような運用を想定されている環境では非常に有用な設定です。

・障害発生時を除き、クラスターの保有するリソースを常に一定のノードで運用したい
・障害から環境が復旧した際には、負荷分散や管理の観点から元々稼働していたノードにリソースを自動的に移動させたい
・クラスター上の仮想マシンの OS の停止時間を最小限に抑え、それに伴う通信断を発生させたくない(ライブマイグレーション)


 [補足] フェールオーバー時の負荷分散について
  --------------------------------------------------------------
なお、フェールオーバーにつきましては、3 台以上のノードでクラスターを構成いただいている環境で、1 台に障害が発生しクラスター グループや使用可能記憶域、クラスターの役割やリソースがフェールオーバーした場合、フェールバック等を設定していない場合でも稼働しているノードの負荷状況を考慮し、リソースが分散しフェールオーバーすることが確認できています。
  --------------------------------------------------------------

 

■フェールバックの設定
下記ではフェールバックの設定についてご紹介させていただきます。


フェールバックの設定
--------------------------------------------------------------
フェールバックを設定いただく際には下記の 2 点をフェールオーバー クラスター マネージャーより設定いただく必要があります。
・[全般] タブの [優先する所有者]
・[フェールオーバー] タブの[フェールバック設定]: フェールバックを許可する (今すぐ)


上記の設定項目の展開手順
--------------------------------------------------------------
1. フェールオーバー クラスター マネージャーを起動し、<クラスター名> - [役割] - 中央ペインでフェールバックを設定したい役割を右クリックして [プロパティ] でプロパティ ウィンドウを起動します。


2. [全般] タブの [優先する所有者] をチェックします(いずれか 1 台のノードを指定してください)


3. [フェールオーバー] タブの[フェールバック設定] で "フェールバックを許可する(今すぐ)" をチェックしてください (既定ではフェールバックを禁止するがチェックされています)

 


このブログが皆様のお役に立てれば幸いです。


<参考情報>
[タイトル] クラスター化されたサービスまたはアプリケーションの設定の変更
https://technet.microsoft.com/ja-jp/library/cc755151.aspx

[タイトル]フェールオーバーとフェールバック
https://msdn.microsoft.com/ja-jp/library/cc757139(v=ws.10).aspx

Premium Storage を使用する仮想マシンのバックアップについて

$
0
0

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

今回は Premium Storage のバックアップ方法についてご案内いたします。

Premium Storage は Standard Storage と比べ格段に速度が早いストレージを使用する事が出来ます。

現在 (2016 年 1 月 21 日)、Premium Storage を使用する仮想マシンでは IaaS バックアップの機能はサポートされておりません。その為、Premium Storage を使用する仮想マシンのバックアップには、VHD の情報をコピーしてバックアップを取得する事をご検討ください。VHD の情報のバックアップおよびリストアにつきましては、V2 の仮想マシンのバックアップおよびリストア手順と同様になりますので、以下の記事をご参考ください。

タイトル: Azure 仮想マシン (IaaS VM) のバックアップ方法について
http://blogs.technet.com/b/askcorejp/archive/2016/01/19/azure-iaas-vm.aspx
参考手順: V2 の仮想マシンのバックアップ方法について

なお、Premium Storage を使用する仮想マシンの IaaS バックアップにつきましては、2016 年 3 月下旬を目途に実装予定です。

Feedback Site: Azure Backup to support VMs with Premium Storage disks
https://feedback.azure.com/forums/258995-azure-backup-and-scdpm/suggestions/7658478-azure-backup-to-support-vms-with-premium-storage-d

タイトル: Premium Storage: Azure 仮想マシン ワークロード向けの高パフォーマンス ストレージ
https://azure.microsoft.com/ja-jp/documentation/articles/storage-premium-storage-preview-portal/

Windows Server 2012 R2 のクラスターの共有ボリュームにおける Defrag および Chkdsk コマンドの実行について

$
0
0

こんにちは。Windows プラットフォームサポートの野村です。今回は、Windows Server 2012 R2 のフェールオーバークラスター環境のクラスターの共有ボリューム (CSV) における Defrag および Chkdsk コマンドの実施方法についてご案内いたします。

クラスターの共有ボリューム (CSV) とは、1 つの論理ボリュームに対して複数のクラスターノードからアクセス可能になる技術です。Windows Server 2012 R2 では、ディスクを NTFS または Resilient File System (ReFS) として、リソースを割り当てることができます。

CSV でない通常のボリュームと同様に、CSV のファイルシステムに対してデフラグまたは Chkdsk の実行が必要となる場合があります。以下に、CSV にてデフラグおよび Chkdsk を行う際の推奨される手順をご案内いたします。

 

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

CSV における Defrag コマンドの実行手順

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

CSV におけるファイルの断片化はシステムのパフォーマンスに影響を及ぼします。従いまして、定期的に CSV にデフラグを実行することにより、ボリューム上の断片化したファイルを統合することを推奨いたします。

スタンドアロンサーバーにおけるデフラグは、メンテナンスタスクとして自動的に実行されますが、CSV においてはデフラグは自動的に実行されません。よって、手動またはスクリプトにて実行する必要があります。なお、デフラグの実行はシステムのパフォーマンスに影響を与える可能性があるため、システムの負荷が少ない時間帯に実施することを推奨いたします。

 

1. 管理者権限で以下のコマンドを実行し、CSV にデフラグが必要かどうかチェックします。

> Defrag.exe <CSV Mount Point> /A /U /V

   /A : 指定したボリュームを最適化しないで、分析レポートを表示します。

   /U : 画面上に処理の進行状況を出力します。

   /V : 詳細モードで実行します。

 注意点 :

CSV にデフラグが必要な場合は、赤枠内に"このボリュームを最適化してください。" とメッセージが表示されます。

CSV がシンプロビジョニング環境のストレージである場合、スラブ統合がデフラグ時に行われます。スラブ統合を実行するには、実行前に CSV をリダイレクトモードにする必要があります。CSV をリダイレクトモードにするには手順 2. を参照してください。

  

2. CSV をリダイレクトモードにします。以下の a. または b. の手順のどちらかを実施してください。

a. 管理者権限のある PowerShell にて、下記のコマンドを実行します。

> Suspend-ClusterResource <Cluster Disk Name> -RedirectedAccess

 

b. [フェールオーバークラスターマネージャー] にて、CSV を右クリックし、[リダイレクトされたアクセスの有効化] を選択します。

 

注意点 :

 CSV をリダイレクトモードにしていない場合、以下のエラーが出力されます。

   "ボリュームがリダイレクトモードでないため、CSVFS での操作が失敗しました。(0x8007174F)"

 

 

 また、次のエラーメッセージが表示される可能性もあります。

  "このファイルシステムでは、この操作はサポートされていません。(0x89000020)"

  3. 以下のコマンドを管理者権限で実行します。デフラグが実行されます。

 > Defrag.exe <CSV Mount Point>

 

  

4. デフラグが完了したら、CSV をリダイレクトモードからダイレクトモードに戻します。以下の a. または b. の手順のどちらかを実施してください。

a. 管理者権限のある PowerShell にて、下記のコマンドを実行します。

> Resume-ClusterResource <Cluster Disk Name>

b. [フェールオーバークラスターマネージャー] にて、CSV を右クリックし、[リダイレクトされたアクセスの無効化] を選択する。

 

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

CSV における ChkDsk コマンドの実行手順

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

ファイルシステムが破損した場合は Chkdsk による修復が必要です。しかし、Windows Server 2012 R2 CSV ReFS をサポートしています。ReFS にはメタデータの整合性チェックによる自己修復機能があるため、Chkdsk ReFS CSV には実施する必要はありません。ここでは、CSV のファイルシステムが NTFS の場合についてご案内いたします。

Windows Server 2012 にて、Chkdsk の操作は破損のスキャン (オンライン処理) と修復 (オフライン処理) に分けられるようになりました。また、Chkdsk /Spotfix CSV に該当する物理ディスクリソースのクラスター IsAlive チェックに統合されました。従って、CSV のファイルシステム破損の修復に、ほとんどダウンタイムが生じなくなりました。

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

ファイルシステムの破損の検知について

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

Windows Server 2012 R2 における NTFS の破損をスキャンする流れは以下のようになります。

 

システムがアイドルでない状態の場合、Chkdsk のスキャン実行されない可能性があります。この場合は、手動で実行する必要があります。手動で実行する際には、以下のコマンドを管理者権限で実行します。

> Chkdsk.exe <CSV mount point name> /scan

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

物理ディスクリソースの IsAlive チェック時における CSV の破損の修復について

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

Windows Server 2012 R2 における CSV のファイルシステムの修復は、以下の流れで行われます。

1 つの CSV の破損を修復するのに 15 秒よりかかる場合、上記の流れでファイルシステムの破損が修復されません。この場合、手動で修復する必要があります。

Chkdsk を実行する前に CSV をメンテナンスまたはリダイレクトモードにする必要はありません。Chkdsk が完了したら、CSV は自動的に状態を回復します。この操作を手動で実行するには、以下のコマンドを管理者権限で実行してください。

> Chkdsk.exe <CSV mount point name> /Spotfix

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

Repair-ClusterSharedVolume コマンドレットにおける Defrag Chkdsk の実行について

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

Repair-ClusterSharedVolume コマンドレットによる Defrag または Chkdsk の実行についてもご紹介いたします(※このコマンドは今後使用できなくなる予定です)CSV に上述の手順にて Defrag.exe および Chkdsk.exe を実行することを推奨いたしますが、Repair-ClusterSharedVolume コマンドレットの使用は、まだサポートされています。このコマンドレットにて Chkdsk または Defrag を実行する際には、管理者権限のある PowerShell にて実行してください。

> Repair-ClusterSharedVolume <Cluster Disk Name> -ChkDsk –Parameters <ChkDsk parameters>

> Repair-ClusterSharedVolume <Cluster Disk Name> –Defrag –Parameters <Defrag parameters>

なお、Get-ClusterSharedVolume コマンドレットを以下のように実行することで、CSV に該当するクラスターディスクの名前を特定することが可能です。

> Get-ClusterSharedVolume | fl *

<参考情報>

- How to Run ChkDsk and Defrag on Cluster Shared Volumes in Windows Server 2012 R2

http://blogs.msdn.com/b/clustering/archive/2014/01/02/10486462.aspx

Windows 8 / Windows 8.1 / Windows 10 環境において、展開後の一部フォルダーに Low Mandatory Level アクセス権が付与されない

$
0
0

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

Windows 8 / Windows 8.1 / Windows 10 の環境において、応答ファイルの設定で 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 Server 2012 R2 Hyper-V にて仮想マシン作成日が "1601/01/01 9:00:00" と表示される

$
0
0

こんにちは、Windows プラットフォーム サポートの鎌滝です。
今回は、仮想マシン管理サービス (VMMS) の再起動により、仮想マシン作成日が "1601/01/01 9:00:00" と表示される事象についてお伝えいたします。

1. 現象
Hyper-V マネージャーにて "実行中" もしくは "一時停止" 以外の状態の仮想マシンの作成日が "1601/01/01 9:00:00" と表示されます。

本事象の発生条件は以下の通りです。
・仮想マシンの状態が "実行中" もしくは "一時停止" 以外の状態であること
・VMMS を再起動すること


2. 原因と詳細
VMMS の起動時にはすべての仮想マシンの構成ファイルの作成日の情報を VMMS 内で保持する構成情報キャッシュへ読み込む処理が行われます。本事象は、VMMS 内部のロジックの不具合により、 "オフ" もしくは "保存完了" の状態の仮想マシンではこの構成情報キャッシュへ読み込む処理が行われないことが原因で発生します。

Hyper-V マネージャーは VMMS 内で保持する構成情報キャッシュの情報から作成日を表示しておりますが、構成情報キャッシュ上に作成日の情報が存在しない場合、Hyper-V マネージャー上の仮想マシンの作成日は Windows のシステム時刻の初期値である "1601/01/01 9:00:00" が表示されます。

構成情報キャッシュに構成情報を読み込む処理は仮想マシンを起動する際にも行われます。作成日が "1601/01/01 9:00:00" と表示されている仮想マシンでも、そのタイミング (仮想マシン起動時) で正しい作成日の情報が構成情報キャッシュへ読み込まれるため、Hyper-V マネージャー上でも正しい作成日が表示されるようになります。その後、仮想マシンをシャットダウンしても、Hyper-V マネージャー上は正しい作成日の情報が表示された状態のままとなります。

また、VMMS の起動時に、すでに "実行中" もしくは "一時停止" の状態である仮想マシンは、正しく構成情報キャッシュへ仮想マシン作成日が読み込まれるため、Hyper-V マネージャー上でも正しい作成日が表示されます。


3. 影響
本事象は VMMS 内部での仮想マシン作成日取得処理の不具合であり、結果として Hyper-V マネージャーの表示に影響を与えます。その他にも WMI にて仮想マシン作成日を取得している場合はその作成日も不正なものとなります。なお、仮想マシン ワーカー プロセス (VMWP) 自体は正確な作成日の情報を保持しております。従いまして、仮想マシン自体および仮想マシン作成日取得処理以外の VMMS の動作にはいっさい影響がありませんので、本事象により業務 (サービス) や運用上に影響が発生することはありません。


4. 事象が発生するバージョンおよび今後の予定
この事象は Windows Server 2012 R2 でのみ発生し、Windows Server 2012、Windows 10 では発生いたしません。
本事象については弊社開発部門にて製品の不具合として認められておりますが、仮想マシンの業務サービスや Hyper-V の運用操作等に影響を与えないことから、現時点で修正の予定はありません。

Windows Server 2012 R2 の "保護されているネットワーク" について

$
0
0

こんにちは。Windows プラットフォームサポートの野村です。今回は、Windows Server 2012 R2 Hyper-V における新機能の一つである"保護されているネットワーク" についてご紹介いたします。

この保護されているネットワーク”を設定することで、仮想マシンの仮想ネットワークアダプターで切断が検知された場合、その仮想マシンは自動的に別の Hyper-V ホストに移動します (※この機能は、Hyper-V クラスタリングを構成している場合に機能します)

"保護されているネットワーク" Hyper-V の仮想マシンの設定ウインドウにて、対象の [ネットワークアダプター] の[高度な機能]を展開して設定することができ、既定では有効化されています。そのため、Windows Server 2012 R2 において、仮想マシンに追加されたネットワークアダプターは、いずれも保護されているネットワークアダプターとして自動的に構成されます。

 

保護されているネットワーク”の設定がされた仮想マシンにおいて、仮想ネットワークアダプターと紐づいている仮想スイッチの物理 NIC に切断が検知された場合、その仮想マシンのライブマイグレーションが行われます。この動作が実行される前には、移動先の Hyper-V ホストの仮想スイッチが正常にネットワークに接続されていることを確認します (※移動先のHyper-V ホストのスイッチでネットワーク障害を検知して、仮想マシンのライブマイグレーションが何度も行われることを避けるためです)

保護されているネットワーク”が設定されていない場合、仮想ネットワークアダプターと紐づいている仮想スイッチの物理 NIC に障害が発生しても、仮想ネットワーク上では障害の発生を検知できないため、仮想マシンのセッションの維持に影響を及ぼします。

従いまして、この"保護されているネットワーク" の機能を有効にすることで、ライブマイグレーションにより仮想マシンのセッション状態を維持できるため、ダウンタイムが生じなくなり、より高いレベルでネットワークの可用性を維持することができます。

 

<参考情報>

- Protected Networks in Windows Server 2012 R2

http://blogs.msdn.com/b/virtual_pc_guy/archive/2014/03/11/protected-networks-in-windows-server-2012-r2.aspx

- What's New in Failover Clustering in Windows Server

https://technet.microsoft.com/en-us/library/dn265972.aspx

- Windows Server 2012 R2 フェールオーバークラスタリング

  構築・運用・管理ガイド (Word 形式)

http://download.microsoft.com/download/0/7/B/07BE7A3C-07B9-4173-B251-6865ADA98E5D/WS2012R2_MSFC_ConfigGuide_v1.1.docx


Hyper-V に対しての "アクセス制御" について

$
0
0

こんにちは。Windows プラットフォーム サポートの古谷です。
本日は、Hyper-V 操作のアクセス制御についてご紹介します。

Windows Server 2012 R2 および Windows 8.1 環境からアクセス制御の対応可能な範囲が変更となっています。

========================================
Windows Server 2012 以前や Windows 8 の場合
========================================

Windows Server 2012 以前や Windows 8 のHyper-V 環境では、承認マネージャー (AzMan.msc) を使用して Hyper-V 操作に対するアクセス制御が可能です。
例えば、承認マネージャー使用により Administrators グループに属さない特定の一般ユーザを指定して、仮想マシンに対する接続権限を付与、また仮想マシン作成の権限付与が対応可能です。



========================================
Windows Server 2012 R2 や Windows 8.1 以降の場合
========================================

Windows Server 2012 R2 および Windows 8.1 以降、承認マネージャーは廃止されております。
そのため、Windows Server 2012 R2 や Windows 8.1 以降は承認マネージャーを使用した Hyper-V 操作に対する詳細なアクセス制御は行えませんが、他の手段としてローカルセキュリティグループ Hyper-V Administrators グループ利用により一般ユーザでも Hyper-V の操作が可能となりますので、ご紹介します。

Windows Server 2012 Hyper-V 以降の環境では Hyper-V の全ての機能に対する完全な操作が可能なローカルセキュリティグループ Hyper-V Administrators グループを導入されています。

Hyper-V Administrators グループは Hyper-V の全ての機能を操作可能となりますため、承認マネージャーで提供していた詳細な Hyper-V 操作のアクセス制御は対応しておりませんが、一般ユーザを使用した Hyper-V操作が可能となります。

管理者権限を持たないユーザーに対して、Hyper-V を管理する権限の設定方法について紹介させていただきました。Windows Server 2012 R2 以降の Hyper-V 操作のアクセス制御が変更となっている点にご留意ください。

<参考情報>
- Features Removed or Deprecated in Windows Server 2012 R2
https://technet.microsoft.com/en-us/library/dn303411.aspx

- Windows Authorization Manager
https://msdn.microsoft.com/en-us/library/bb897401.aspx

- Allowing non-Administrators to control Hyper-V–Updated
http://blogs.msdn.com/b/virtual_pc_guy/archive/2014/06/11/allowing-non-administrators-to-control-hyper-v-updated.aspx

「フェールオーバー クラスターの IP アドレス変更手順」

$
0
0

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

本日は、クラスター環境の IP アドレス変更手順についてご紹介いたします。

 

クラスター環境の移行をおこなう場合など、クラスターを構成している各ノードの物理 IP アドレスと、クラスター上で稼働しているアプリケーションに紐づく仮想 IP アドレスを変更する必要がある場合があります。その際、クラスター環境の IP アドレス変更については、以下の 3 種類の IP アドレスの変更を検討していただく必要があります。

 

物理 IP アドレス:

・クラスター構成ノード (物理サーバー) IP アドレス


仮想 IP アドレス:

・クラスター管理用 (クラスターコアリソース) の仮想 IP アドレス

・クラスター化されたアプリケーションの仮想 IP アドレス

 

今回は上記 3 つの IP アドレスの変更の順番と、変更方法についてご案内したいと思います。

 

※注意点※

クラスター環境構成後はドメイン移行、物理ホスト名の変更はサポートしておりません。

変更が必要となる場合には、一度クラスターを解除する必要があります。

 

仮想 IP の変更を行う場合、クラスター化されたアプリケーションの設定も変更が必要な場合があります。

詳細につきましてはご利用のアプリケーションの提供元様にご確認ください。

 

 設定手順

===========

Blog では Windows Server 2012 R2 における IP アドレスの変更手順についてご案内します。

 

設定手順は以下の順番で行います。

 

1) クラスターサービスの停止

2) クラスター構成ノード (物理サーバー) IP アドレス変更

3) クラスター管理用 (クラスターコアリソース) IP アドレス変更

4) クラスター化されたアプリケーションの IP アドレス変更

 

1) クラスターサービスの停止方法

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

クラスターの IP アドレスを変更するには、[クラスター コア リソース] と、クラスター上で稼働している各種アプリケーションを停止した上で、クラスターサービスを停止する必要があります。

 [クラスター コア リソース] と、クラスター上で稼働している各種アプリケーションを停止する理由は、不要なクラスター リソースの失敗やエラーの検知を避けて、変更が完了したものから順番に起動することで、正常にオンラインになるかを確認する為です。

 

1-1.

[フェールオーバークラスターマネージャー] を開きます。

 

1-2.

左側のウィンドウから [クラスター名] を選択した後、中央ウィンドウの [クラスターコアリソース] を展開します。[サーバー名] を展開し、[IP アドレス: XXX.XXX.XXX.XXX] を右クリックし、[オフラインに移行] を選択します。

 

 

1-3.

左側のウィンドウから [役割] を展開し、登録されているグループを、右クリックし、[役割の停止] を選択します。

※この手順で、役割に登録されている全てのグループを停止してください。

 

  

1-4.

左側のウィンドウから [クラスター名] を 右クリックし、[他のアクション] より [クラスターのシャットダウン] を選択し、クラスターを停止させます。

 

  

以上で、クラスター サービスの停止は完了です。

 

2) クラスター構成ノード (物理サーバー) IP アドレス変更手順

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

IP アドレスを変更するノード (物理サーバー) にログインし、以下の手順を各ノード上で実施します。

 

2-1.

[ネットワークと共有センター] を開き、[アダプタ―の設定の変更] から [ネットワーク接続] の画面に進みます。

IP アドレスを変更するネットワークアダプタを右クリックし、表示されたメニューから [プロパティ] を選択します。

  

2-2.

中央の"この接続は次の項目を使用します" の一覧から、変更する IP [TCP/IPv4] または [TCP/IPv]6 を選択し、[プロパティ] をクリックします。

2-3.

[次の IP アドレスを使う] または [次の IPv6 アドレスを使う] がチェックされた状態で、IP アドレスを設定し [OK] をクリックします。

 

 

以上で、クラスター構成ノード (物理サーバー) IP アドレス変更は完了です。

 

- 補足 ------

なお、本手順によってセグメントの変更されると、クラスターに登録されているネットワーク名が、規定の「クラスター ネットワーク 1 」などに変更され、ネットワークのオプションが「クラスターのみ」となる場合がございます。その際は、ネットワークのサブネットをご確認の上、適切なネットワークの設定を再度おこなってください

<参考> フェールオーバークラスターのネットワーク設定を変更する

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

また、変更したネットワークがフェールオーバー クラスター マネージャー上から見えていない場合には、上記手順 2-1. から変更したネットワークを右クリックし、 [無効] にしていただき、再度 [有効] を選択してください。同時に、一度フェールオーバー クラスター マネージャーを閉じていただき、再度開いていただくことで最新の情報が反映されます。

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

 

3) クラスター管理用 (クラスターコアリソース) IP アドレス変更手順

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

物理 IP アドレスの変更後に、[フェールオーバー クラスター マネージャー] から仮想 IP アドレスの変更を実施します。

 

3-1.

[フェールオーバークラスターマネージャー] の左側のウィンドウから [クラスター名] を右クリックし、[クラスターの起動] を選択し、クラスターサービスを起動します。

※もし [クラスター名] が表示されていない場合は、中央ウィンドウの"管理" から [クラスターに接続する] を選択し [OK] を押すと、クラスターに接続を開始します。接続完了後、左側のウィンドウに [クラスター名] が表示されます。

  

 

3-2.

左側のウィンドウから [クラスター名] を選択した後、中央ウィンドウの [クラスターコアリソース] を展開します。[サーバー名] を展開し、[IP アドレス: XXX.XXX.XXX.XXX] を右クリックし、[プロパティ] を選択します。

 

 

3-3.

[全般] タブから [ネットワーク] のリストから使用するサブネットを選択し、[静的 IP アドレス] の項目から使用する IP アドレスを設定し、[適用] を選択した後、[OK] を選択します。

 

  

3-4.

中央ウィンドウの [クラスタコアリソース] 内の [サーバー名] を右クリックし、[オンラインにする] を選択し、変更した IP アドレスリソースが正常にオンラインになることを確認します。

 

 

以上で、クラスター管理用 (クラスターコアリソース) IP アドレス変更は完了です。

 

4) クラスター化されたアプリケーションの IP アドレス変更手順 

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

上記、クラスター コア リソースの IP アドレス変更手順と同じ手順で、変更が必要な全てのアプリケーションの仮想 IP アドレスの変更を実施します。

 

4-1.

[フェールオーバークラスターマネージャー] の左側のウィンドウから [役割] を選択し、登録されているグループを選択します。下の [リソース] タブを選択し、変更したい [IP アドレス: XXX.XXX.XXX.XXX] をダブルクリックします。

 

4-2.

[全般] タブから [ネットワーク] のリストから使用するサブネットを選択し、[静的 IP アドレス] の項目から使用する IP アドレスを設定し、[適用] を選択した後、[OK] を選択します。

 

4-3.

変更した IP アドレスリソースが紐づくアプリケーションを右クリックし、[オンラインにする] を選択します。登録されているアプリケーションが正常にオンラインになることをご確認ください。

 

上記変更方法を参考に、変更が必要な全てのアプリケーションの仮想 IP アドレスの変更を実施してください。

以上の手順でクラスターの IP アドレスの変更の全てが完了です。

  

- クラスター構成の確認

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

以上の手順を実施した後、変更を行った IP アドレスリソースが正常にオンラインになっているかをご確認いただき、通信に問題はないか、またイベント ログにエラーが出ていないかをご確認ください。

※アドレスの変更に伴って、IP アドレスのエラー (FailoverClustering ID:1069) や通信の切断を示す (FailoverClustering ID:1123) などが発生する可能性があります。IP アドレスに関するエラーについても、作業完了後に発生したエラーでなければ問題は無いので、ご安心ください。

 

また、クラスター構成を変更した後は構成の検証を行いクラスターが正常に動作しているかご確認ください。クラスターの検証については、左側ウィンドウの [クラスター名] を右クリックし、[クラスターの検証] から実施することが出来ます。

 

<参考> フェールオーバークラスター構成の検証

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

 

このブログが皆様のお役に立てれば幸いです。

グループ ポリシーを使用してリムーバブル デバイスのアクセスを制御する方法

$
0
0

いつも弊社製品をご利用いただきまして誠にありがとうございます。
Windowsプラットフォーム サポートの加藤です。
 
昨今、情報漏えい対策の一環として多くのお問い合わせをいただいておりますグループ ポリシーを使用してリムーバブル デバイスを制御する方法についてご紹介させていただきます。
グループ ポリシーを使用してリムーバブル デバイスを制御する方法は大きく分けると以下の 2 点の方法がございます。

- グループ ポリシーを使用してリムーバブル デバイスのアクセスを制御する方法
   本項ではこちらの方法についてご紹介させていただきます。

- グループ ポリシーを使用してリムーバブル デバイスのインストールを制御する方法
   こちらにつきましては以下のページでご紹介させていただいております。
 
   『グループ ポリシーを用いた WPD デバイスの制限について』 
     http://blogs.technet.com/b/askcorejp/archive/2014/08/18/wpd.aspx

併せて、以下もご参照いただけますと幸いです。

  『グループポリシーを用いて リムーバブル デバイス アクセス制御を行う前に行っていただきたいこと』
   http://blogs.technet.com/b/askcorejp/archive/2014/12/11/3641905.aspx

<本項の概要>
----------------------------------------------------------------------------
■グループ ポリシーを使用してリムーバブル デバイスのアクセスを制御する方法
1. リムーバブル記憶域へのアクセス制御の概要
2. 設定方法
 
■補足情報
1. コンピューターの構成とユーザーの構成
----------------------------------------------------------------------------

 

■グループ ポリシーを使用してリムーバブル デバイスのアクセスを制御する方法
1. リムーバブル記憶域へのアクセス制御の概要
2. 設定方法

----------------------------------------------------------------------------------------------------------------
1. リムーバブル記憶域へのアクセス制御の概要

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

このグループ ポリシーでは、リムーバブル デバイスとして認識されたデバイスに対し、書き込み、読み取り、実行の制御を行うことが出来ます。対象OSは Windows Vista 以降のクライアント OS, サーバーOSです (※1)。


リムーバブル記憶域へのアクセス制限のグループ ポリシーを設定すると、グループ ポリシー サービス (Gpsvc) から通知を受けた Portable Device Enumerator Service (WPDBusEnum) サービスが、制御の対象となるデバイスを特定し、デバイスのアクセス コントロール リスト (ACL) を設定します。

このグループポリシーでは、下記の 5 つに分類されるリムーバブル デバイスについてアクセス制御を行うことが可能です。
またこのあとご紹介させていただく カスタム クラスをご利用いただくことにより、デバイス セットアップ クラス GUID によるデバイスのアクセス制御を行うことも可能です。

 制御対象代表的なデバイス
CD および DVDCD および DVD
フロッピー ドライブUSB フロッピーを含むフロッピー
リムーバブル ディスクUSB メモリ、USB ディスク等
テープ ドライブテープ ドライブ
WPD デバイスメディア プレーヤー、デジタルカメラ、SD、MD、携帯電話(スマートフォン)等

SD カードは一般的には WPD デバイスとして認識されますが、製造メーカーによってはリムーバブル ディスクとして認識されるものもございます。制御を行いたいデバイスが特定のものである場合は、念のため製造メーカーにご確認いただければ幸いです。

 
<参考情報>
[タイトル] System-Defined Device Setup Classes Available to Vendors (英語)
      http://msdn.microsoft.com/en-us/library/ff553426(VS.85).aspx

 ※1.  [リムーバブル記憶域へのアクセス制御] ポリシーによる制御をサーバー OS に対して実施する場合、 [コンピューターの構成] を使用したポリシーのみ設定する事が可能です。(サーバー OS に対して [ユーザーの構成] を使用して本ポリシーを適用した場合、本ポリシーによる設定は反映されません)。なお、制御対象がクライアント OS の場合には、[コンピューターの構成 / ユーザーの構成] のいずれでも対象デバイスを制御する事が可能です。


----------------------------------------------------------------------------------------------------------------
 2. 設定方法

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

1. リムーバブル記憶域へのアクセス制御の設定方法

  以下は、グループ ポリシーを用いて、ローカルのコンピュータに対して 『リムーバブル ディスク への書き込み』 を制御する手順についてご紹介します。

 
   [スタート] 右クリック
   - [ファイル名を指定して実行] gpedit.msc と入力します
    - [コンピューターの構成]
     - [管理用テンプレート]
      - [システム]
       - [リムーバブル記憶域へのアクセス]
        - [リムーバブル ディスク: 書き込みアクセス権の拒否] 設定値: 有効

 

■補足情報
----------------------------------------------------------------------------------------------------------------
1. コンピューターの構成とユーザーの構成

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

以下のようなシナリオをベースにご紹介させていただきます。

 
<シナリオ>
-------------------------------------------------------------------
情報漏えい対策の一環として、コンピュータの構成で [リムーバブル ディスクの読み取りアクセス権の拒否] と [リムーバブル ディスクの書き込みアクセス権の拒否] を有効にしている。

しかし一部のユーザー (User A) は、USB メモリを使用する必要があるため User A に対してのみ [リムーバブル ディスクの読み取りアクセス権の拒否] と [リムーバブル ディスクの書き込みアクセス権の拒否] を無効に設定したい。
 
想定する設定方法
- コンピュータの構成でポリシーを有効化
- User A に対いてポリシーの無効化
-------------------------------------------------------------------

上記のような方法で設定を行った場合、結果は User A に対しても [リムーバブル ディスクの読み取りアクセス権の拒否] と [リムーバブル ディスクの書き込みアクセス権の拒否] が有効になってしまします。
これはグループ ポリシーのリムーバブル記憶域へのアクセス制御については、設定項目がユーザーの構成とコンピュータの構成で重複した場合、コンピュータの構成が優先されるためです。

               グループ ポリシーのリムーバブル記憶域へのアクセス制御で優先される構成

                             コンピュータの構成 > ユーザーの構成

 
従いまして、本シナリオの要件を満たすためには、コンピュータの構成で設定を行うのではなく、ユーザーの構成で全ユーザーに対してアクセス拒否のポリシーの有効を設定いただいた上で、User A に対いてポリシーの無効化を設定いただきますようお願いいたします。

 
<設定方法例>
新規で作成した AccessEnableOUに User A を追加し、 新規で作成した AccessDenyOU に全ユーザーを追加します。それぞれの OU に対して以下のように GPO をリンクさせます。
GPOをリンクさせるとき、AccessEnableOU , AccessDenyOU の順番で行います。

AccessEnableOU →     - [リムーバブル ディスク: 書き込みアクセス権の拒否] 設定値: 無効
            - [リムーバブル ディスク: 読み取りアクセス権の拒否] 設定値: 無効

AccessDenyOU →   - [リムーバブル ディスク: 書き込みアクセス権の拒否] 設定値: 有効 
            - [リムーバブル ディスク: 読み取りアクセス権の拒否] 設定値: 有効  

 

なお、グループ ポリシーのリムーバブル記憶域へのアクセス制御を特定のユーザーに設定する場合は、以下の手順で行うことが出来ます。

 [スタート] 右クリック
   - [ファイル名を指定して実行] gpedit.msc と入力します
    - [ユーザーの構成]
     - [管理用テンプレート]
      - [システム]
       - [リムーバブル記憶域へのアクセス]
        - [リムーバブル ディスク: 書き込みアクセス権の拒否] 設定値: 有効

 
参考:
Windows 8 および Windows 8.1 のリムーバブル デバイスへのアクセス制御の注意点について
http://blogs.technet.com/b/askcorejp/archive/2014/05/19/windows-8-windows-8-1.aspx
 
グループ ポリシーを用いたデバイスのアクセス制御について
http://blogs.technet.com/b/askcorejp/archive/2014/04/28/3516088.aspx

グループ ポリシーを用いた WPD デバイスの制限について
http://blogs.technet.com/b/askcorejp/archive/2014/08/18/wpd.aspx

“FSRM レポートのカスタマイズ" について

$
0
0

(※ 2016 年 2 月 23 日に更新しました)

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

 

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

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

 

  

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

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

=============================
1) 文書番号 : 3134812 を適用する
=============================

上述の通り、この "オプションの構成" を GUI から設定できない事象については
弊社製品の問題 (不具合) であったため、本事象を改善した修正プログラムが
2016 年 2 月にリリースされました。

-文書番号 : 3134812
You can't change settings from FSRM GUI in Windows Server 2012 R2
https://support.microsoft.com/en-us/kb/3134812
https://support.microsoft.com/ja-jp/kb/3134812 (機械翻訳)

まずは対応策の 1 つとして、上記修正プログラムをご適用いただきまして、本事象が
改善されるかについてご確認いただければと思います。

 

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

IaaS VM Backup のアラート通知について

$
0
0

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

今回は IaaS VM Backup のアラート通知手順についてご案内いたします。

そもそもアラートではどの様なことが実現出来るのだろうという事を確認したい場合には、以下の弊社公開情報をご参照ください。

タイトル: Azure 仮想マシンのバックアップを管理および監視する
https://azure.microsoft.com/ja-jp/documentation/articles/backup-azure-manage-vms/#-8
参考箇所: アラート通知

タイトル: Add-AlertRule
https://msdn.microsoft.com/en-us/library/mt282468.aspx

以下、アラートの設定についてご案内させていただきます。

アラートの設定につきましては、Add-AlertRule コマンドを利用する事で、失敗時にメールでアラート配信を実施する事が可能です。以下実施手順についてご案内いたします。
 
- アラートの設定手順
--------------------------------------------------------------------
1."Microsoft Azure PowerShell" に Azure のアカウントでログオンします。
 
- 実行例
----------------------------------------------------------
PS C:\Users\taseko.000> Login-AzureRmAccount
 
Environment           : AzureCloud
Account               : ms@microsoft.com
TenantId              : 72f988bf-86f1-41af-91ab-2d7cd01*****
SubscriptionId        : 0d8ad84b-f76a-40f7-a159-1095089*****
CurrentStorageAccount :
 
 
2.以下のコマンドを実行し、Alert の設定対象となるバックアップ コンテナ情報を確認します。
 
実行コマンド: Get-AzureRmResource | Where-Object { $_.ResourceName -eq "バックアップ コンテナ名" }
 
- 実行例
----------------------------------------------------------
PS C:\Users\taseko.000> Get-AzureRmResource | Where-Object { $_.ResourceName -eq "EAST-US-TEST1" }
 
Name              : EAST-US-TEST1
ResourceId        : /subscriptions/0d8ad84b-f76a-40f7-a159-1095089*****/resourceGroups/RecoveryServices-*****ZBYRTB6YDWNPCPY5Z5PJH3GAKHOGSLYZXAELCN74LBJRL5Q-East-US/providers/microsoft.backup/BackupVault/EAST-US-TEST1
ResourceName      : EAST-US-TEST1
ResourceType      : microsoft.backup/BackupVault
ResourceGroupName : RecoveryServices-*****ZBYRTB6YDWNPCPY5Z5PJH3GAKHOGSLYZXAELCN74LBJRL5Q-East-US
Location          : eastus
SubscriptionId    : 0d8ad84b-f76a-40f7-a159-1095089*****
 
 
3.Add-AlertRule コマンドを実施し、アラートを追加します。
 
実行コマンド:
Add-AlertRule -EventName Backup -EventSource Administrative -Level Error -Location <String> -Name <String> -OperationName Microsoft.Backup/backupVault/Backup -Operator GreaterThanOrEqual -ResourceGroup <String> -ResourceId <String> -ResourceProvider Microsoft.Backup -RuleType Event -Status <String> -SubStatus <String> -Threshold <Double> [-CustomEmails <String[]> ] [-Description <String> ] [-DisableRule] [-EmailAddress <String> ] [-SendToServiceOwners] [-WindowSize <TimeSpan> ] [ <CommonParameters>]
 
- 実行例
----------------------------------------------------------
PS C:\Users\taseko.000> Add-AlertRule -EventName Backup -EventSource Administrative -Level Error -Location eastus -Name TestCase -OperationName Microsoft.Backup/backupVault/Backup -Operator GreaterThanOrEqual -ResourceGroup RecoveryServices-*****ZBYRTB6YDWNPCPY5Z5PJH3GAKHOGSLYZXAELCN74LBJRL5Q-East-US -ResourceId /subscriptions/0d8ad84b-f76a-40f7-a159-1095089*****/resourceGroups/RecoveryServices-*****ZBYRTB6YDWNPCPY5Z5PJH3GAKHOGSLYZXAELCN74LBJRL5Q-East-US/ -ResourceProvider Microsoft.Backup -RuleType Event -Status Failed -SubStatus Failed -Threshold 1 -EmailAddress ms@microsoft.com  -SendToServiceOwners
 
RequestId                            StatusCode
---------                            ----------
12b8bf6b-bc29-4212-999d-9778f01*****    Created
 
 
- コマンドのオプションについて
~~~~~~~~~~~~~~~~~~~~~~~~~~~
- EventName
バックアップ失敗のアラートを作成するには "Backup" を指定ください。
IaaS VM バックアップに関するアラートの場合、サポートされる値は、以下の値です。
Register、Unregister、ConfigureProtection、Backup、Restore、StopProtection、DeleteBackupData、CreateProtectionPolicy、DeleteProtectionPolicy、UpdateProtectionPolicy
 
-EventSource
ルールによってモニタリングするイベント ソース名となります。Azure Backup のソースは ”Administrative” となります。
 
- Level
サポートされる値は、Informational、Error です。操作が失敗した場合のアラートには Error を使用し、ジョブが成功した場合のアラートには Informational を使用します。
 
- Location
対象のバックアップ コンテナの場所を指定します。手順 2 の実行結果から "Location" をご確認ください。
 
- Name
アラート ルールの名前を指定します。
 
- OperationName
バックアップのアラートを作成するには "Microsoft.Backup/backupVault/Backup" の形式で指定します。
 
-Operator
指定したルールの条件を実行する際の比較演算子を指定できます。バックアップが失敗した際にアラートを通知するには、GreaterThanOrEqual をご指定ください。以下 4 つの値があります。
(GreaterThan | GreaterThanOrEqual | LessThan | LessThanOrEqual)
 
- ResourceGroup
操作がトリガーされるリソースの ResourceGroup です。手順 2 の実行結果から "ResourceGroupName" をご確認ください。
 
- ResourceId
手順 2 の実行結果から "ResourceId" をご確認ください。
 
- ResourceProvider
リソース プロバイダーの値を指定します。”Microsoft.Backup” は Azure Backup に使用されるリソース プロバイダーとなります。
 
- RuleType
イベント ベースのバックアップ アラートであるため、Event を指定します。
 
- Status
サポートされる値は、Started、Succeeded、および Failed です。失敗時のアラートを設定するには "Failed" を指定ください。Status に Succeeded を指定する場合、Level には Informational を指定してください。
 
- SubStatus
バックアップ操作の Status と同じです。
 
-Threshold
アラートが通知されるまでのしきい値です。
 
- Description
アラート ルールの説明を指定します。
 
- CustomEmails
アラート通知を送信するカスタム電子メール アドレスを指定します。
 
- SendToServiceOwners
このオプションを指定すると、サブスクリプションの管理者と共同管理者全員にアラート通知を送信します。
 
-WindowSize  “時間:分:秒 (00:05:00)” (最短は 5 分です)
オプションを追加する事で、アラートの確認頻度を指定出来ます。運用に合わせて設定の変更をご検討ください。 
 

- アラートの確認手順
--------------------------------------------------------------------
1.以下のコマンドを実行して、アラート対象のバックアップ コンテナのリソース グループ名を確認します。
 
実行コマンド: Get-AzureRmResource | Where-Object { $_.ResourceName -eq "バックアップ コンテナ名" } 
 
- 実行例
----------------------------------------------------------
PS C:\Users\taseko.000> Get-AzureRmResource | Where-Object { $_.ResourceName -eq "EAST-US-TEST1" }
 
Name              : EAST-US-TEST1
ResourceId        : /subscriptions/0d8ad84b-f76a-40f7-a159-1095089*****/resourceGroups/RecoveryServices-*****ZBYRTB6YDWNPCPY5Z5PJH3GAKHOGSLYZXAELCN74LBJRL5Q-East-US/providers/microsoft.backup/BackupVault/EAST-US-TEST1
ResourceName      : EAST-US-TEST1
ResourceType      : microsoft.backup/BackupVault
ResourceGroupName : RecoveryServices-*****ZBYRTB6YDWNPCPY5Z5PJH3GAKHOGSLYZXAELCN74LBJRL5Q-East-US
Location          : eastus
SubscriptionId    : 0d8ad84b-f76a-40f7-a159-1095089*****
 
 
2.以下のコマンドで対象のリソース グループ名に関連付けられているアラートを
   確認出来ます。
 
実行コマンド: Get-AlertRule -ResourceGroup <リソース グループ名>
 
- 実行例
----------------------------------------------------------
PS C:\Users\taseko.000> Get-AlertRule -ResourceGroup RecoveryServices--*****ZBYRTB6YDWNPCPY5Z5PJH3GAKHOGSLYZXAELCN74LBJRL5Q-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/0d8ad84b-f76a-40f7-a159-1095089*****/resourceGroups/RecoveryServices-*****TB6YDWNPCPY5Z5PJH3GAKHOGSLYZXAELCN74LBJRL5Q-East-US/, Resource]}
Id         : /subscriptions/0d8ad84b-f76a-40f7-a159-1095089*****/resourceGroups/RecoveryServices-*****ZBYRTB6YDWNPCPY5Z5PJH3GAKHOGSLYZXAELCN74LBJRL5Q-East-US/providers/microsoft.insights/alertrules/TestCase
Location   : eastus
Name       : TestCase
 
 
詳細な内容を確認するには “-DetailedOutput” オプションを指定して実行してください。
 
実行コマンド: Get-AlertRule -ResourceGroup <リソース グループ名> -DetailedOutput
 
 
- アラートの削除手順
--------------------------------------------------------------------
以下のコマンドを実行して、対象のアラートを削除します。
 
実行コマンド: Remove-AlertRule -Name <アラート名> -ResourceGroup <リソース グループ名>
 
- 実行例
----------------------------------------------------------
PS C:\Users\taseko.000> Remove-AlertRule -Name TestCase -ResourceGroup RecoveryServices-*****ZBYRTB6YDWNPCPY5Z5PJH3GAKHOGSLYZXAELCN74LBJRL5Q-East-US
 
RequestId                            StatusCode
---------                            ----------
*****abe-6c0d-44a7-98ea-93f5fb152690         OK

Azure Backup に失敗する (0x1D4C2)

$
0
0

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

今回は Azure Backup を構成し、初めてバックアップを取得する際に、バックアップの取得に失敗する事例についてご紹介いたします。

1.バックアップに失敗した際には、GUI 上に以下の様なイベントが記録されます。



2.次にイベント ビューアーより "CloudBackup" のイベントを確認します。



ログの名前:         CloudBackup
ソース:           CloudBackup
日付:            2016/02/27 1:00:05
イベント ID:       11

3.中央ペイン下部より "詳細" タブをクリックして、EventData の内容を確認します。




- EventData StopInfo
StopInfo <?xml version="1.0"?> <CBJob><JobId>060f2660-e41a-413c-a955-b6ed089a2895</JobId>
<JobType>Backup</JobType><JobStatus><JobState>Aborted</JobState><StartFileTime>13100976
0052990143</StartFileTime><EndFileTime>131009760053180108</EndFileTime><FailedFileLog>
</FailedFileLog><ErrorInfo><ErrorCode>120002</ErrorCode><DetailedErrorCode>-2147024773
</DetailedErrorCode><ErrorParamList/></ErrorInfo><DatasourceStatus><CBDatasourceStatus>
<JobState>Aborted</JobState><LastCompletedJobState>Initializing</LastCompletedJobState>
<ErrorInfo><ErrorCode>120002</ErrorCode><DetailedErrorCode>-2147024773</DetailedErrorCode>
<ErrorParamList/></ErrorInfo><Datasource><DataSourceId>2026778163991805067</DataSourceId>
<DataSourceName>C:\</DataSourceName></Datasource><ByteProgress><Total>0</Total><Changed>
0</Changed><Progress>0</Progress><Failed>0</Failed></ByteProgress><FileProgress><CurrentFile>
</CurrentFile><Total>0</Total><Changed>0</Changed><Progress>0</Progress><Failed>0</Failed>
</FileProgress></CBDatasourceStatus><CBDatasourceStatus><JobState>Aborted</JobState>
  :
  :
  :
</CBJob>

4.以下のレジストリ キーを確認します。

HLKM\Software\Microsoft \Windows Azure Backup\Config
  キー: ScratchLocation

HLKM\Software\Microsoft \Windows Azure Backup\Config\CloudBackupProvider
  キー: ScratchLocation

問題が発生する環境においては、レジストリ キーの値のパスに余分な "\" が付与されております。

例:  F:\MARSAgent\Scratch\\Scratch
 

5.上記確認の結果、本問題に該当している場合には、不要な "\" を削除して変更します。本作業は手順 4 で確認したレジストリ キー両方ともの値を変更します。

例:  F:\MARSAgent\Scratch\Scratch

6.レジストリ キーの設定を反映させる為に Azure Backup エージェントのサービスを再起動します。管理者権限で起動したコマンド プロンプトより以下のコマンドを実行します。

  net stop obengine
  net start obengine

7.再度バックアップを実行し、バックアップが正常に終了するか確認します。


[参考情報]
上記状況をログ等の情報から確認するには、CBEngine ログより詳細動作を確認します。

ログの既定パス: C:\Program Files\Microsoft Azure Recovery Services Agent\Temp
上記パスはエージェントのインストール フォルダによって変更されます。

現象が発生した時間帯付近のログを展開し、以下の様なログが記録されているか確認します。尚、ログ内のタイム スタンプは GMT (標準時) で記録される為、日本標準時で確認するには +9 時間となります。

- CBEngine ログ
3380 6D6C 02/26 16:00:05.388 18 dsmfsenumerator.cpp(150) [000000001A36E370] 060F2660-E41A-413C-A955-B6ED089A2895 WARNING Failed: Hr: = [0x8007007b] : FindFirstFile failed For Dir:\\?\F:\MARSAgent\Scratch\\Scratch\*
3380 6D6C 02/26 16:00:05.388 18 fsutils.cpp(2409)  060F2660-E41A-413C-A955-B6ED089A2895 WARNING Failed: Hr: = [0x8007007b] : FindFirstFile failed for Path [\\?\F:\MARSAgent\Scratch\\Scratch\], FileSpec [*]

V2 の仮想マシンのバックアップ

$
0
0

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

遂に V2 仮想マシン (リソース マネージャーから作成した仮想マシン) のプレビュー版 IaaS VM バックアップが公開されました! 尚、Azure Advisors への事前登録とサーベイ サイトへのご回答が必要となりますので、以下の手順を実施くださいますようお願いいたします。

1) Azure Backup の Public Preview 参加に当たって、下記サイトにサインアップください。
  http://aka.ms/azureadvisors 

2) サインアップのあと、下記サイトにてサーベイにご記入ください。
  http://aka.ms/armbackupprev
  

サーベイ サイトへのご回答後、24 時以内にプレビュー Azure ポータル サイトより "Recovery Services コンテナー" を利用することで IaaS V2 VM のバックアップが可能です。

 - Azure ポータルへのアクセス サイト
  https://aka.ms/mab

上記登録に関するご不明な点がある場合には、本 Blog にコメントいただく、もしくは以下のサイトよりご質問くださいますようお願いいたします。
 

タイトル: How can we improve Azure Backup & SCDPM ?
https://feedback.azure.com/forums/258995-azure-backup-and-scdpm/suggestions/8369907-azure-backup-to-support-iaas-vm-v2?tracking_code=399d1563de96a54bfaee770e12e4f21b


Windows Server 2012 R2 の"保護されているネットワーク"について

$
0
0

こんにちは。Windows プラットフォーム サポートの野村です。今回は、Windows Server 2012 R2 Hyper-V における新機能の一つである保護されているネットワークについてご紹介いたします。

この保護されているネットワーク” を設定することで、仮想マシンの仮想ネットワーク アダプターで切断が検知された場合、その仮想マシンは自動的に別の Hyper-V ホストに移動します (※この機能は、Hyper-V クラスタリングを構成している場合に機能します)

保護されているネットワーク Hyper-V の仮想マシンの設定ウインドウにて、対象の [ネットワーク アダプター] の[高度な機能]を展開して設定することができ、既定では有効化されています。そのため、Windows Server 2012 R2 において、仮想マシンに追加されたネットワーク アダプターは、いずれも保護されているネットワーク アダプターとして自動的に構成されます。

 

保護されているネットワーク” の設定がされた仮想マシンにおいて、仮想ネットワーク アダプターと紐づいている仮想スイッチの物理 NIC に切断が検知された場合、その仮想マシンのライブ マイグレーションが行われます。この動作が実行される前には、移動先の Hyper-V ホストの仮想スイッチが正常にネットワークに接続されていることを確認します (※移動先のHyper-V ホストのスイッチでネットワーク障害を検知して、仮想マシンのライブ マイグレーションが何度も行われることを避けるためです)

保護されているネットワーク” が設定されていない場合、仮想ネットワーク アダプターと紐づいている仮想スイッチの物理 NIC に障害が発生しても、仮想ネットワーク上では障害の発生を検知できないため、仮想マシンのセッションの維持に影響を及ぼします。

従いまして、この保護されているネットワークの機能を有効にすることで、ライブ マイグレーションにより仮想マシンのセッション状態を維持できるため、ダウンタイムが生じなくなり、より高いレベルでネットワークの可用性を維持することができます。

 

<参考情報>

- Protected Networks in Windows Server 2012 R2

http://blogs.msdn.com/b/virtual_pc_guy/archive/2014/03/11/protected-networks-in-windows-server-2012-r2.aspx

- What’s New in Failover Clustering in Windows Server

https://technet.microsoft.com/en-us/library/dn265972.aspx

- Windows Server 2012 R2 フェールオーバー クラスタリング

  構築・運用・管理ガイド (Word 形式)

http://download.microsoft.com/download/0/7/B/07BE7A3C-07B9-4173-B251-6865ADA98E5D/WS2012R2_MSFC_ConfigGuide_v1.1.docx

Hyper-V に対しての"アクセス制御"について

$
0
0

こんにちは。Windows プラットフォーム サポートの古谷です。
本日は、Hyper-V 操作のアクセス制御についてご紹介します。

Windows Server 2012 R2 および Windows 8.1 環境からアクセス制御の対応可能な範囲が変更となっています。

========================================
Windows Server 2012 以前や Windows 8 の場合
========================================

Windows Server 2012 以前や Windows 8 のHyper-V 環境では、承認マネージャー (AzMan.msc) を使用して Hyper-V 操作に対するアクセス制御が可能です。
例えば、承認マネージャー使用により Administrators グループに属さない特定の一般ユーザを指定して、仮想マシンに対する接続権限を付与、また仮想マシン作成の権限付与が対応可能です。

========================================
Windows Server 2012 R2 や Windows 8.1 以降の場合
========================================

Windows Server 2012 R2 および Windows 8.1 以降、承認マネージャーは廃止されております。
そのため、Windows Server 2012 R2 や Windows 8.1 以降は承認マネージャーを使用した Hyper-V 操作に対する詳細なアクセス制御は行えませんが、他の手段としてローカルセキュリティグループ Hyper-V Administrators グループ利用により一般ユーザでも Hyper-V の操作が可能となりますので、ご紹介します。

Windows Server 2012 Hyper-V 以降の環境では Hyper-V の全ての機能に対する完全な操作が可能なローカルセキュリティグループ Hyper-V Administrators グループを導入されています。

Hyper-V Administrators グループは Hyper-V の全ての機能を操作可能となりますため、承認マネージャーで提供していた詳細な Hyper-V 操作のアクセス制御は対応しておりませんが、一般ユーザを使用した Hyper-V操作が可能となります。

管理者権限を持たないユーザーに対して、Hyper-V を管理する権限の設定方法について紹介させていただきました。Windows Server 2012 R2 以降の Hyper-V 操作のアクセス制御が変更となっている点にご留意ください。

<参考情報>
- Features Removed or Deprecated in Windows Server 2012 R2
https://technet.microsoft.com/en-us/library/dn303411.aspx

- Windows Authorization Manager
https://msdn.microsoft.com/en-us/library/bb897401.aspx

- Allowing non-Administrators to control Hyper-V–Updated
http://blogs.msdn.com/b/virtual_pc_guy/archive/2014/06/11/allowing-non-administrators-to-control-hyper-v-updated.aspx

「フェールオーバークラスターの IP アドレス変更手順」

$
0
0

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

本日は、クラスター環境の IP アドレス変更手順についてご紹介いたします。

 

クラスター環境の移行をおこなう場合など、クラスターを構成している各ノードの物理 IP アドレスと、クラスター上で稼働しているアプリケーションに紐づく仮想 IP アドレスを変更する必要がある場合があります。その際、クラスター環境の IP アドレス変更については、以下の 3 種類の IP アドレスの変更を検討していただく必要があります。

 

物理 IP アドレス:

・クラスター構成ノード (物理サーバー) IP アドレス


仮想 IP アドレス:

・クラスター管理用 (クラスター コア リソース) の仮想 IP アドレス

・クラスター化されたアプリケーションの仮想 IP アドレス

 

今回は上記 3 つの IP アドレスの変更の順番と、変更方法についてご案内したいと思います。

 

※注意点※

クラスター環境構成後はドメイン移行、物理ホスト名の変更はサポートしておりません。

変更が必要となる場合には、一度クラスターを解除する必要があります。

 

仮想 IP の変更を行う場合、クラスター化されたアプリケーションの設定も変更が必要な場合があります。

詳細につきましてはご利用のアプリケーションの提供元様にご確認ください。

 

 設定手順

===========

Blog では Windows Server 2012 R2 における IP アドレスの変更手順についてご案内します。

 

設定手順は以下の順番で行います。

 

1) クラスター サービスの停止

2) クラスター構成ノード (物理サーバー) IP アドレス変更

3) クラスター管理用 (クラスター コア リソース) IP アドレス変更

4) クラスター化されたアプリケーションの IP アドレス変更

 

1) クラスター サービスの停止方法

——————————–

クラスターの IP アドレスを変更するには、[クラスター コア リソース] と、クラスター上で稼働している各種アプリケーションを停止した上で、クラスター サービスを停止する必要があります。

 [クラスター コア リソース] と、クラスター上で稼働している各種アプリケーションを停止する理由は、不要なクラスター リソースの失敗やエラーの検知を避けて、変更が完了したものから順番に起動することで、正常にオンラインになるかを確認する為です。

 

1-1.

[フェールオーバー クラスター マネージャー] を開きます。

 

1-2.

左側のウィンドウから [クラスター名] を選択した後、中央ウィンドウの [クラスター コア リソース] を展開します。[サーバー名] を展開し、[IP アドレス: XXX.XXX.XXX.XXX] を右クリックし、[オフラインに移行] を選択します。

 

 

1-3.

左側のウィンドウから [役割] を展開し、登録されているグループを、右クリックし、[役割の停止] を選択します。

※この手順で、役割に登録されている全てのグループを停止してください。

 

  

1-4.

左側のウィンドウから [クラスター名] を 右クリックし、[他のアクション] より [クラスターのシャットダウン] を選択し、クラスターを停止させます。

 

  

以上で、クラスター サービスの停止は完了です。

 

2) クラスター構成ノード (物理サーバー) IP アドレス変更手順

————————————————————-

IP アドレスを変更するノード (物理サーバー) にログインし、以下の手順を各ノード上で実施します。

 

2-1.

[ネットワークと共有センター] を開き、[アダプタ―の設定の変更] から [ネットワーク接続] の画面に進みます。

IP アドレスを変更するネットワーク アダプタを右クリックし、表示されたメニューから [プロパティ] を選択します。

  

2-2.

中央のこの接続は次の項目を使用しますの一覧から、変更する IP [TCP/IPv4] または [TCP/IPv]6 を選択し、[プロパティ] をクリックします。

2-3.

[次の IP アドレスを使う] または [次の IPv6 アドレスを使う] がチェックされた状態で、IP アドレスを設定し [OK] をクリックします。

 

 

以上で、クラスター構成ノード (物理サーバー) IP アドレス変更は完了です。

 

- 補足 ——

なお、本手順によってセグメントの変更されると、クラスターに登録されているネットワーク名が、規定の「クラスター ネットワーク 1 」などに変更され、ネットワークのオプションが「クラスターのみ」となる場合がございます。その際は、ネットワークのサブネットをご確認の上、適切なネットワークの設定を再度おこなってください

<参考> フェールオーバー クラスターのネットワーク設定を変更する

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

また、変更したネットワークがフェールオーバー クラスター マネージャー上から見えていない場合には、上記手順 2-1. から変更したネットワークを右クリックし、 [無効] にしていただき、再度 [有効] を選択してください。同時に、一度フェールオーバー クラスター マネージャーを閉じていただき、再度開いていただくことで最新の情報が反映されます。

————-

 

3) クラスター管理用 (クラスター コア リソース) IP アドレス変更手順

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

物理 IP アドレスの変更後に、[フェールオーバー クラスター マネージャー] から仮想 IP アドレスの変更を実施します。

 

3-1.

[フェールオーバー クラスター マネージャー] の左側のウィンドウから [クラスター名] を右クリックし、[クラスターの起動] を選択し、クラスター サービスを起動します。

※もし [クラスター名] が表示されていない場合は、中央ウィンドウの管理から [クラスターに接続する] を選択し [OK] を押すと、クラスターに接続を開始します。接続完了後、左側のウィンドウに [クラスター名] が表示されます。

  

 

3-2.

左側のウィンドウから [クラスター名] を選択した後、中央ウィンドウの [クラスター コア リソース] を展開します。[サーバー名] を展開し、[IP アドレス: XXX.XXX.XXX.XXX] を右クリックし、[プロパティ] を選択します。

 

 

3-3.

[全般] タブから [ネットワーク] のリストから使用するサブネットを選択し、[静的 IP アドレス] の項目から使用する IP アドレスを設定し、[適用] を選択した後、[OK] を選択します。

 

  

3-4.

中央ウィンドウの [クラスタ コア リソース] 内の [サーバー名] を右クリックし、[オンラインにする] を選択し、変更した IP アドレス リソースが正常にオンラインになることを確認します。

 

 

以上で、クラスター管理用 (クラスター コア リソース) IP アドレス変更は完了です。

 

4) クラスター化されたアプリケーションの IP アドレス変更手順 

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

上記、クラスター コア リソースの IP アドレス変更手順と同じ手順で、変更が必要な全てのアプリケーションの仮想 IP アドレスの変更を実施します。

 

4-1.

[フェールオーバー クラスター マネージャー] の左側のウィンドウから [役割] を選択し、登録されているグループを選択します。下の [リソース] タブを選択し、変更したい [IP アドレス: XXX.XXX.XXX.XXX] をダブルクリックします。

 

4-2.

[全般] タブから [ネットワーク] のリストから使用するサブネットを選択し、[静的 IP アドレス] の項目から使用する IP アドレスを設定し、[適用] を選択した後、[OK] を選択します。

 

4-3.

変更した IP アドレス リソースが紐づくアプリケーションを右クリックし、[オンラインにする] を選択します。 登録されているアプリケーションが正常にオンラインになることをご確認ください。

 

上記変更方法を参考に、変更が必要な全てのアプリケーションの仮想 IP アドレスの変更を実施してください。

以上の手順でクラスターの IP アドレスの変更の全てが完了です。

  

- クラスター構成の確認

———————–

以上の手順を実施した後、変更を行った IP アドレス リソースが正常にオンラインになっているかをご確認いただき、通信に問題はないか、またイベント ログにエラーが出ていないかをご確認ください。

※アドレスの変更に伴って、IP アドレスのエラー (FailoverClustering ID:1069) や通信の切断を示す (FailoverClustering ID:1123) などが発生する可能性があります。IP アドレスに関するエラーについても、作業完了後に発生したエラーでなければ問題は無いので、ご安心ください。

 

また、クラスター構成を変更した後は構成の検証を行いクラスターが正常に動作しているかご確認ください。クラスターの検証については、左側ウィンドウの [クラスター名] を右クリックし、[クラスターの検証] から実施することが出来ます。

 

<参考> フェールオーバー クラスター構成の検証

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

 

このブログが皆様のお役に立てれば幸いです。

グループポリシーを使用してリムーバブルデバイスのアクセスを制御する方法

$
0
0

いつも弊社製品をご利用いただきまして誠にありがとうございます。
Windowsプラットフォーム サポートの加藤です。
 
昨今、情報漏えい対策の一環として多くのお問い合わせをいただいておりますグループ ポリシーを使用してリムーバブル デバイスを制御する方法についてご紹介させていただきます。
グループ ポリシーを使用してリムーバブル デバイスを制御する方法は大きく分けると以下の 2 点の方法がございます。

- グループ ポリシーを使用してリムーバブル デバイスのアクセスを制御する方法
   本項ではこちらの方法についてご紹介させていただきます。

- グループ ポリシーを使用してリムーバブル デバイスのインストールを制御する方法
   こちらにつきましては以下のページでご紹介させていただいております。
 
   『グループ ポリシーを用いた WPD デバイスの制限について』 
     http://blogs.technet.com/b/askcorejp/archive/2014/08/18/wpd.aspx

併せて、以下もご参照いただけますと幸いです。

  『グループポリシーを用いて リムーバブル デバイス アクセス制御を行う前に行っていただきたいこと』
   http://blogs.technet.com/b/askcorejp/archive/2014/12/11/3641905.aspx

<本項の概要>
—————————————————————————-
■グループ ポリシーを使用してリムーバブル デバイスのアクセスを制御する方法
1. リムーバブル記憶域へのアクセス制御の概要
2. 設定方法
 
■補足情報
1. コンピューターの構成とユーザーの構成
—————————————————————————-

 

■グループ ポリシーを使用してリムーバブル デバイスのアクセスを制御する方法
1. リムーバブル記憶域へのアクセス制御の概要
2. 設定方法

—————————————————————————————————————-
1. リムーバブル記憶域へのアクセス制御の概要

—————————————————————————————————————-

このグループ ポリシーでは、リムーバブル デバイスとして認識されたデバイスに対し、書き込み、読み取り、実行の制御を行うことが出来ます。対象OSは Windows Vista 以降のクライアント OS, サーバーOSです (※1)。

リムーバブル記憶域へのアクセス制限のグループ ポリシーを設定すると、グループ ポリシー サービス (Gpsvc) から通知を受けた Portable Device Enumerator Service (WPDBusEnum) サービスが、制御の対象となるデバイスを特定し、デバイスのアクセス コントロール リスト (ACL) を設定します。

このグループポリシーでは、下記の 5 つに分類されるリムーバブル デバイスについてアクセス制御を行うことが可能です。
またこのあとご紹介させていただく カスタム クラスをご利用いただくことにより、デバイス セットアップ クラス GUID によるデバイスのアクセス制御を行うことも可能です。

 制御対象 代表的なデバイス
CD および DVD CD および DVD
フロッピー ドライブ USB フロッピーを含むフロッピー
リムーバブル ディスク USB メモリ、USB ディスク等
テープ ドライブ テープ ドライブ
WPD デバイス メディア プレーヤー、デジタルカメラ、SD、MD、携帯電話(スマートフォン)等

SD カードは一般的には WPD デバイスとして認識されますが、製造メーカーによってはリムーバブル ディスクとして認識されるものもございます。制御を行いたいデバイスが特定のものである場合は、念のため製造メーカーにご確認いただければ幸いです。

 
<参考情報>
[タイトル] System-Defined Device Setup Classes Available to Vendors (英語)
      http://msdn.microsoft.com/en-us/library/ff553426(VS.85).aspx

 ※1.  [リムーバブル記憶域へのアクセス制御] ポリシーによる制御をサーバー OS に対して実施する場合、 [コンピューターの構成] を使用したポリシーのみ設定する事が可能です。(サーバー OS に対して [ユーザーの構成] を使用して本ポリシーを適用した場合、本ポリシーによる設定は反映されません)。なお、制御対象がクライアント OS の場合には、[コンピューターの構成 / ユーザーの構成] のいずれでも対象デバイスを制御する事が可能です。

—————————————————————————————————————-
 2. 設定方法

—————————————————————————————————————-

1. リムーバブル記憶域へのアクセス制御の設定方法

  以下は、グループ ポリシーを用いて、ローカルのコンピュータに対して 『リムーバブル ディスク への書き込み』 を制御する手順についてご紹介します。

 
   [スタート] 右クリック
   - [ファイル名を指定して実行] gpedit.msc と入力します
    - [コンピューターの構成]
     - [管理用テンプレート]
      - [システム]
       - [リムーバブル記憶域へのアクセス]
        - [リムーバブル ディスク: 書き込みアクセス権の拒否] 設定値: 有効

 

■補足情報
—————————————————————————————————————-
1. コンピューターの構成とユーザーの構成

—————————————————————————————————————-

以下のようなシナリオをベースにご紹介させていただきます。

 
<シナリオ>
——————————————————————-
情報漏えい対策の一環として、コンピュータの構成で [リムーバブル ディスクの読み取りアクセス権の拒否] と [リムーバブル ディスクの書き込みアクセス権の拒否] を有効にしている。

しかし一部のユーザー (User A) は、USB メモリを使用する必要があるため User A に対してのみ [リムーバブル ディスクの読み取りアクセス権の拒否] と [リムーバブル ディスクの書き込みアクセス権の拒否] を無効に設定したい。
 
想定する設定方法
- コンピュータの構成でポリシーを有効化
- User A に対いてポリシーの無効化
——————————————————————-

上記のような方法で設定を行った場合、結果は User A に対しても [リムーバブル ディスクの読み取りアクセス権の拒否] と [リムーバブル ディスクの書き込みアクセス権の拒否] が有効になってしまします。
これはグループ ポリシーのリムーバブル記憶域へのアクセス制御については、設定項目がユーザーの構成とコンピュータの構成で重複した場合、コンピュータの構成が優先されるためです。

               グループ ポリシーのリムーバブル記憶域へのアクセス制御で優先される構成

                             コンピュータの構成 > ユーザーの構成

 
従いまして、本シナリオの要件を満たすためには、コンピュータの構成で設定を行うのではなく、ユーザーの構成で全ユーザーに対してアクセス拒否のポリシーの有効を設定いただいた上で、User A に対いてポリシーの無効化を設定いただきますようお願いいたします。

 
<設定方法例>
新規で作成した AccessEnableOUに User A を追加し、 新規で作成した AccessDenyOU に全ユーザーを追加します。それぞれの OU に対して以下のように GPO をリンクさせます。
GPOをリンクさせるとき、AccessEnableOU , AccessDenyOU の順番で行います。

AccessEnableOU →     – [リムーバブル ディスク: 書き込みアクセス権の拒否] 設定値: 無効
            – [リムーバブル ディスク: 読み取りアクセス権の拒否] 設定値: 無効

AccessDenyOU →   – [リムーバブル ディスク: 書き込みアクセス権の拒否] 設定値: 有効 
            – [リムーバブル ディスク: 読み取りアクセス権の拒否] 設定値: 有効  

 

なお、グループ ポリシーのリムーバブル記憶域へのアクセス制御を特定のユーザーに設定する場合は、以下の手順で行うことが出来ます。

 [スタート] 右クリック
   - [ファイル名を指定して実行] gpedit.msc と入力します
    - [ユーザーの構成]
     - [管理用テンプレート]
      - [システム]
       - [リムーバブル記憶域へのアクセス]
        - [リムーバブル ディスク: 書き込みアクセス権の拒否] 設定値: 有効

 
参考:
Windows 8 および Windows 8.1 のリムーバブル デバイスへのアクセス制御の注意点について
http://blogs.technet.com/b/askcorejp/archive/2014/05/19/windows-8-windows-8-1.aspx
 
グループ ポリシーを用いたデバイスのアクセス制御について
http://blogs.technet.com/b/askcorejp/archive/2014/04/28/3516088.aspx

グループ ポリシーを用いた WPD デバイスの制限について
http://blogs.technet.com/b/askcorejp/archive/2014/08/18/wpd.aspx

“FSRM レポートのカスタマイズ"について

$
0
0

(※ 2016 年 2 月 23 日に更新しました)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

 

  

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

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

=============================
1) 文書番号 : 3134812 を適用する
=============================

上述の通り、この “オプションの構成” を GUI から設定できない事象については
弊社製品の問題 (不具合) であったため、本事象を改善した修正プログラムが
2016 年 2 月にリリースされました。

-文書番号 : 3134812
You can’t change settings from FSRM GUI in Windows Server 2012 R2
https://support.microsoft.com/en-us/kb/3134812
https://support.microsoft.com/ja-jp/kb/3134812 (機械翻訳)

まずは対応策の 1 つとして、上記修正プログラムをご適用いただきまして、本事象が
改善されるかについてご確認いただければと思います。

 

=============================
2)  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 を使用してカスタマイズされた記憶域レポートを作成する場合には、上記の
“オプションの構成” の設定方法をお試しいただき、日々の運用にご活用いただければと
思います。

Viewing all 590 articles
Browse latest View live


Latest Images