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

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 10 Enterprise で Windows Update を開くと、Windows 10 version 1511 が検出されない場合の設定について

$
0
0

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

Windows 10 が公開されてから、早半年が経過しました。また、初のメジャー アップデートである Windows 10 version 1511 が公開されてからも、3ヶ月が経過いたしました。
Windows 10 ご活用いただけておりますでしょうか ?

今回は、Windows 10 Enterprise をご利用頂いている環境で、Windows Server Update Services (WSUS) は利用していない場合の Windows 10 version 1511 へのアップグレードについてお話したいと思います。

Windows 10 Enterprise については、多くの企業の皆様にご利用頂いておりますが、企業内にご利用頂くにあたって、Windows 10 Pro などと若干 Windows 10 version 1511 へのアップグレード手順に違いがございます。

Windows 10 Pro の場合
——————————————-
Windows Update サイトで検出され、ユーザー操作によってアップグレードすることが出来ます。

Windows 10 Enterprise の場合
——————————————-
ライセンスの認証形式によって、Windows Update を開いたときの Windows 10 version 1511 に検出動作に以下の様な差異があります。

Key Management Service (以下 KMS) 認証環境の場合: Windows 10 version 1511 が検出されません。
Multiple Activation Key (以下 MAK) 認証環境の場合: Windows 10 version 1511 が検出されます。

これは、ライセンスを一括管理されている環境 (KMS)  で Windows 10 をご利用頂くにあたり、ユーザー意思のみで Windows 10 version 1511 へのアップデートが行うことができてしまうのは、ライセンスを管理頂く上で好ましくないと考えた設定となります。
ただし、企業様によってライセンスは一括管理されるが、Windows の更新などは各環境で対応される場合もありますため、KMS 環境でも Windows Update から Windows 10 version 1511 へ更新することができるようにする設定についてご紹介いたします。

KMS 環境下のWindows 10 Enterprise クライアントに対して、以下レジストリ設定を行って頂くことで、Windows Update で Windows 10 version 1511 が検出されるようになります。

————-
キー : HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\OSUpgrade
名前 : AllowKMSUpgrade
種類 : REG_DWORD
値 :  1
————-

このレジストリをコマンドで適用する場合には以下の reg から /f までのコマンドを、管理者権限で実行ください。
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\OSUpgrade /f /v AllowKMSUpgrade /t REG_DWORD /d 1

<参考情報>

Windows 10 Enterprise: will a non-domain computer running version 10240 — ever get build “1511” (version 10586) via Windows Update?
https://social.technet.microsoft.com/Forums/ja-JP/b3d02663-59a1-42a7-aa6a-7dfa906832b6/windows-10-enterprise-will-a-nondomain-computer-running-version-10240-ever-get-build-1511?forum=win10itprosetup

これからも、Windows 10 をよろしくお願いいたします。

Windows Server 2012 および Windows Server 2012 R2 環境で発生する Explorer.exe のクラッシュについて

$
0
0

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

本日は、リモート デスクトップ環境で発生する Explorer.exe のクラッシュについて、ご紹介したいと思います。

最近弊社では、リモート デスクトップへのログオン時に、Explorer.exe がクラッシュしてしまう問題が報告されております。
事象発生時には、以下の動画のように Explorer.exe がクラッシュし、再起動を繰り返すためユーザーはデスクトップを操作することができません。 

[View:~/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-74-97/REPRO.mp4:0:0]

また、アプリケーションのイベント ログには、次のようなイベントが多数記録されます。

ログの名前:         Application
ソース:           Application Error
イベント ID:       1000
レベル:           エラー
ユーザー:          N/A
コンピューター:       XXXXXXXX
説明:
障害が発生しているアプリケーション名: explorer.exe、バージョン: 6.3.9600.16384、タイム スタンプ: 0x5215d379
障害が発生しているモジュール名: twinui.dll、バージョン: 6.3.9600.16384、タイム スタンプ: 0x5215d80a
例外コード: 0xc0000005
障害オフセット: 0x000000000001022c
障害が発生しているプロセス ID: 0x42c
障害が発生しているアプリケーションの開始時刻: 0x01d178287f81e4da
障害が発生しているアプリケーション パス: C:\Windows\explorer.exe
障害が発生しているモジュール パス: C:\Windows\system32\twinui.dll

上記の事象は以下の条件に合致する場合に発生することが確認されております。 

  1. Windows Server 2012 または Windows Server 2012 R2 製品を利用している。
  2. “リモート デスクトップ サービス ユーザーに対してリモート デスクトップ サービス セッションを 1 つに制限する” ポリシーが無効化されている。
  3. “デスクトップ エクスペリエンス” の機能が有効になっている。
  4. 1 つのユーザー アカウントを利用して、同時に複数のセッションにログオンしている。

また、本事象につきましては以下のいずれかの回避策が有効であることを確認しております。

  1. “リモート デスクトップ サービス ユーザーに対してリモート デスクトップ サービス セッションを 1 つに制限する” ポリシーを有効にする。または未構成に戻す。
  2. “デスクトップ エクスペリエンス” の機能を無効にする。

本事象に遭遇されました場合には、お手数ですが、回避策の適用をご検討いただけますと幸いです。

なお、本事象につきましては、弊社でも製品開発部門と連携し、調査を開始しておりますので、アップデートがあり次第、本ブログ記事も更新する予定です。 


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

フェールオーバー クラスターの異なるネットワーク セグメント間通信について

$
0
0

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

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

本日は、フェールオーバー クラスターが行うクラスター ノード間の異なるネットワーク セグメント間通信についてご紹介します。

フェールオーバー クラスターでは、規定でクラスター ノード間で別ネットワーク セグメントが存在する場合、別ネットワーク セグメントに対して定期的に通信 (UDP 3343) を行っております。

【発生する通信】
・UDP 通信
・サービス:ms-cluster-net(3343ポート)

これは、マルチサイト クラスター構成のための重要な通信であり、異なるネットワーク セグメントに対してハートビート通信ができるかルート検出を行う動作となります。

例えば、本動作によりクラスター ノード間で以下の通信が発生します。

フェールオーバー クラスター  2 ノード(WSFC1、WSFC2)環境において、クラスター ノード間に 2 つのネットワークが存在している。

① Public 用ネットワーク(クライアント アクセスポイントが割り当てられたパブリック ネットワーク)
② HeartBeat用ネットワーク (クラスター ノード間を結ぶ Closed なプライベート ネットワーク)

本環境で、WSFC1 の Publicnet から WSFC 2 の HeartBeatnetに対して、また、WSFC2 の Publicnet からWSFC1 の HeartBeatnet に対して UDP 3343 のパケットが送信されます。

パブリック ネットワークにファイアウォール装置が存在する場合は、本通信は検出されます。

PlumbAllCrossSubnetRoutes

ローカルサイト クラスターで本通信の検出を抑止したい場合は、
以下の対処を実施することで対処可能でございます。

==========================================================================
クラスター ノード間で発生する異なるネットワーク セグメント間通信の抑止方法
==========================================================================

異なるネットワークセグメントに対しての UDP 3343 を抑止したい場合は、
クラスターのプロパティ PlumbAllCrossSubnetRoutes により制御可能です。

PlumbAllCrossSubnetRoutes

https://msdn.microsoft.com/ja-jp/windows/jj151934%28v=vs.80%29
このプロパティの値は 0 – 2 がございます。

0 ローカルルートが発見された場合はクロス サブネットルートを検索しない。(規定)

1 必ずサブネットを横断するルートを検索します。

2 ノードが正常に参加した後、クロス サブネットルートを検出する動作を無効にします。

既定は 0 であるため、サービスの起動時にはクロス サブネットのルートは検索されませんが、
ノードが参加した後に、クロス サブネットルートを検出する動きが定期的に発生します。

抑止したい場合は値を 2 に変更していただくことで、クロス サブネットルートを検出する
動作 (UDP 3343) を完全に無効にする必要があります。

UDP 3343 の対処方法
====================

変更方法は以下の PowerShell コマンドを実施します。

[作業対象]
任意のクラスター ノード 1台

1. 管理者権限の PowerShell を起動します。

2. 以下のコマンドで、”PlumbAllCrossSubnetRoutes” の値を確認します。

> Get-Cluster | fl *

3. 以下のコマンドで、”PlumbAllCrossSubnetRoutes” の値を変更します。

> (Get-Cluster). PlumbAllCrossSubnetRoutes = 2

[作業対象]
全クラスター ノード

4. クラスター サービスを再起動します。

 
<設定変更による影響>
ローカルサイト クラスターの場合、本設定変更により影響などはございません。

本設定変更は、クラスター ノード間で発生する異なるセグメントに対する送信パケット
(ファイアウォールにてブロックされる通信) を無効にしているためです。

以上、どうぞよろしくお願い申し上げます。

サービス起動の問題について (Windows Server 2012, Windows Server 2012 R2)

$
0
0

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

Windows Server 2012, Windows Server 2012 R2 の環境で、サービス再起動時にサービスが起動しないという既知の問題が報告されています。
この既知の問題については、すでに原因を特定し、修正プログラムを以下の技術情報で公開しています。

DNS server freezes and service restart fails during the service restart in Windows Server 2012 R2 or Windows Server 2012
DNS サーバーがフリーズして、Windows Server 2012 R2 または Windows Server 2012 のサービスの再起動時にサービスの再起動が失敗します。(日本語機械翻訳)

技術情報には “サービスの再起動を実行した際にサービスが起動しない” 現象として記載されていますが、”システムの再起動後にサービスが起動しない“、といった現象も報告されています。また、クラスター環境の場合には “フェールオーバー先で汎用サービスがオンラインにならない現象” が発生する報告もあります。

この問題は “Windows Server 2012 or Windows Server 2012 R2 の環境” で “サービスの起動アカウントがドメイン ユーザー” の場合に発生することが分かっています。
また、この現象が発生した場合、”システムを再起動するまですべてのサービスで起動/停止が行えない状況になる” ことが特徴です。

もし、このような現象に遭遇した場合には、技術情報で公開されている修正プログラムを適用してみてください。
修正プログラムの適用で現象が改善しない場合には、弊社サポート サービスの利用をぜひご検討ください。

 

※ 本記事は 2016/03/17 時点の情報となります。

Windows Server 2012 R2 におけるネットワーク障害からの仮想マシンの復旧について

$
0
0

こんにちは。Windows プラットフォーム サポートの野村です。今回は、Windows Server 2012 R2 の新機能である保護されているネットワークにより、ネットワーク障害から仮想マシンが復旧するシナリオについてご紹介します。

Windows Server のフェールオーバー クラスターの機能は仮想マシンの実行状態、およびクラスター ネットワークとクラスター ストレージの正常性をを常時監視しています。さらに、仮想マシンのネットワークと仮想スイッチの接続の障害検知も行います。

Windows Server 2012 R2 では、ネットワーク障害が発生した場合にライブ マイグレーションによって、仮想マシンをフェールオーバー クラスターの他のノードに移動させる新機能を導入しました。これにより、仮想マシン内で起動しているサービスが中断してしまうようなネットワーク障害が発生した場合でも、仮想マシンをネットワーク アクセスが提供できるノードへ移動することで、可用性を向上させることができます。既定では、この機能を提供するプロパティである [保護されているネットワーク接続] が全ての仮想ネットワーク アダプターにおいて有効になっています。

なお、ライブ マイグレーション先のノードにおいて使用可能なネットワークが無い場合、上述の仮想マシンのライブ マイグレーションは実行されません。これは、そもそもライブ マイグレーションを開始させるリソースを所有していないノードへ仮想マシンが移動することを避けるためです。クラスター ノード上の必要なネットワークとシステム リソースが利用可能である限り、そのノードは仮想マシンの移動先として選択されます。

また、同時にライブ マイグレーションが可能な仮想マシンの台数には制限があります。ホスト上のネットワーク障害により影響を受ける仮想マシンが、同時ライブ マイグレーション可能台数よりも多い場合、仮想マシンのライブ マイグレーションは一旦キューに登録されます。ネットワーク障害が復旧し再び利用可能になると、ライブ マイグレーション キューに登録されている仮想マシンのライブ マイグレーションはキャンセルされます。

[保護されているネットワーク接続] のプロパティは、仮想マシンのネットワーク アダプターの設定では [高度な機能] の新しいプロパティです。このプロパティにより、ネットワーク障害が起きた際に、仮想マシンを他のノードへ移動させて可用性を保つための重要なネットワーク アダプターにするかどうかを選択することができます。

例えば、仮想マシンに外部ネットワークとバックアップとして使用するネットワークの 2 つの仮想スイッチが接続されている場合、バックアップ用ネットワーク アダプターに対してプロパティを無効にし、外部用ネットワークに対して有効にする、といった仮想ネットワーク アダプター単位の設定が可能です。この場合、もし、バックアップ用ネットワークに障害が発生しても、仮想マシンは移動しませんが、外部用ネットワークに障害があった場合、仮想マシンはネットワークが有効なノードにライブ マイグレーションされます。

なお、多くのネットワーク障害のシームレスな処理および冗長性確保のためにも、運用に際して重要なネットワークに対してはネットワーク チーミングを使用することを推奨しています。

 

<シミュレーション>

Windows Server 2012 R2 の新機能である保護されているネットワークがどのように機能するか、以下の例で確認してみましょう。

以下の図 1 は、仮想マシンを所有する 2 ノードのクラスターを表しています。

(※本ブログでのネットワーク構成は数ある構成の中でも 1 例です。ネットワークの構成はアダプターの数や速さ等によって変わります。)

各ノードの親パーティション (管理パーティション) には、それぞれのノードに対して専用のネットワーク アダプターがあります。また、各ノードには Hyper-V の仮想スイッチとして構成された 2 番目のネットワーク アダプターがあります。仮想マシンには、その仮想スイッチと接続するように構成された統合ネットワーク アダプターがあります。

仮想スイッチが使用している物理ネットワーク アダプターで障害が起きた場合、ノード B は仮想マシンが使用するネットワークと繋がっているため、仮想マシンはノード B にライブ マイグレーションします。各サーバー間のプライベート ネットワークが機能しているため、仮想マシンはノード A からノード B にライブ マイグレーションすることができます。

diagram_1

( 1)

 

// ネットワーク障害が起きても、仮想マシンのライブ マイグレーションが起きない仮想ネットワーク アダプターの構成について

上述のクラスターと同様な構成で、各ノードに別のネットワーク アダプターを追加して仮想スイッチと接続した場合を考えていきます ( 2 を参照してください)2 つ目の仮想ネットワーク アダプターに仮想マシンを配置して、新しい仮想スイッチに接続します。このシナリオでは、そのネットワークはバックアップとして利用されるか、短期間の障害ではクライアントが仮想マシンを使用することに影響を与えない場合の仮想マシン間の通信に利用されます。この新規のネットワークを “Backup” と呼ぶこととします。

この新しいネットワークは短期間の障害は許容するため、仮想ネットワーク アダプターに重要なネットワークとして構成しないようにします。これにより、Backup ネットワークは切断してしまっても、仮想マシンがクラスターの別のノードに移動することはありません。

これを行うためには、仮想マシンの設定を開いて、バックアップのネットワークの仮想ネットワーク アダプターを展開し、[高度な機能] をチェックしてください。そこで、[保護されているネットワーク] のチェックをオフにしてください (下記の図 3 を参照してください)

既定では、[保護されているネットワーク] の設定はすべての仮想ネットワーク アダプターにおいて有効になっています。

diagram_2

(図 2)

ScreenShot

(図 3)

 

// PowerShell により、仮想ネットワーク アダプターをネットワーク障害に反応させないようにする場合について

ここでは、上述の設定を行う PowerShell のコマンドおよび、”VM1″ という名前の仮想マシンの仮想ネットワーク アダプターに対するコマンドの出力結果をご紹介します。このコマンドは、クラスターを構成しているいずれのノードからでも実行できます (コマンドを実行するノード上にその仮想マシンがホストされていなくても可能です)。なお、クラスターを構成していないノードから本コマンドを実行する場合は、コマンドの初めに Get-Cluster コマンドレットを実行し、クラスターの名前を指定してください。

PS C:\Windows\system32> Get-ClusterGroup VM1 |Get-VM | Get-VMNetworkAdapter | FL VMName,SwitchName,MacAddress,ClusterMonitored

 

VMName           : VM1

SwitchName       : Corp

MacAddress       : 00155D867239

ClusterMonitored : True

 

VMName           : VM1

SwitchName       : Storage

MacAddress       : 00155D86723A

ClusterMonitored : True

 

VMName           : VM1

SwitchName       : Private

MacAddress       : 00155D86723B

ClusterMonitored : True

 

次に、”Private” という名前の仮想スイッチを使用するネットワーク アダプターの “ClusterMonitored” プロパティを無効にする PowerShell のコマンドをご紹介します。

(※ プロパティは “ClusterMonitored” ですが、変更するプロパティは “NotMonitoredInCluster” です。従って、-NotMonitoredInCluster に True を明示することにより、”ClusterMonitored” プロパティを false に変更できます。逆もまた同様です。)

 

PS C:\Windows\system32> Get-ClusterGroup VM1 |Get-VM | Get-VMNetworkAdapter | Where-Object {$_.SwitchName -eq “Private”} | Set-VmNetworkAdapter -NotMonitoredInCluster $True

PS C:\Windows\system32> Get-ClusterGroup VM1 |Get-VM | Get-VMNetworkAdapter | FL VMName,SwitchName,MacAddress,ClusterMonitored

 

VMName           : VM1

SwitchName       : Corp

MacAddress       : 00155D867239

ClusterMonitored : True

 

VMName           : VM1

SwitchName       : Storage

MacAddress       : 00155D86723A

ClusterMonitored : True

 

VMName           : VM1

SwitchName       : Private

MacAddress       : 00155D86723B

ClusterMonitored : False

 

<“保護されているネットワーク接続” の検証について>

仮想マシンが起動しているサーバーの物理ネットワーク アダプターのネットワーク ケーブルを抜くことで、上記の動作を検証することが可能です。

ここで注意していただきたいことは、クラスターが仮想マシンがネットワーク障害の影響を受けていることを検知するのに、1 分程度かかる場合があるということです。クラスター上の各仮想マシンは仮想マシンのエラーを監視するクラスター リソースを保持しており、既定で 60 秒毎に仮想スイッチの状態をチェックしています。

つまり、仮想マシンによっては監視タイミングに依存して、”仮想スイッチが障害の発生している物理 NIC に接続されていること” が検知されるまでに最大で 60 秒かかる場合があります。

そのため、障害が起こった仮想スイッチを使用している仮想マシンが複数存在する場合でも、全ての仮想マシンで同時にライブ マイグレーションが行われるわけではありません。

なお、先述いたしましたように、ネットワーク障害が復旧した場合、待機中のライブ マイグレーションはキャンセルされ、仮想マシンは元のノードで稼働します。また、既に実行中のライブ マイグレーションはキャンセルされずに仮想マシンは移行されます。

 

以上の通り、”保護されているネットワーク” の機能によるネットワーク障害からの仮想マシンの復旧についてお伝えいたします。本ブログが皆様のお役に立てましたら、幸いです。

<参考情報>

– Windows Server 2012 R2 Virtual Machine Recovery from Network Disconnects

http://blogs.msdn.com/b/clustering/archive/2013/09/04/10446482.aspx

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

https://blogs.technet.microsoft.com/askcorejp/2016/01/27/windows-server-2012-r2/

– 仮想マシンのライブ マイグレーションの概要

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

 

 

 


Windows 10 アップグレード通知機能について

$
0
0

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

昨年 10 月に Windows Blog (英語日本語抄訳)で公表したとおり、マイクロソフトは Windows 7 および Windows 8.1 をお使いのユーザー様が、Windows 10 へのアップグレードをさらに簡単に行えるよう取り組んでいます。
Windows 10 は、Windows 史上において最高の、そして最も安全なオペレーティングシステムとなります。
2016 年 7 月に Windows 10 無償アップグレードの提供期間を終えるのにあたり、より多くのユーザー様が、その期限前に、さらに簡単にアップグレードしていただけるようにサポートしたいと考えています。

Windows 10 アップグレードのスケジュールに関して
https://www.microsoft.com/ja-jp/atlife/article/windows10/guide/schedule.aspx

Windows 10 アップグレード スケジュール
https://support.microsoft.com/ja-jp/kb/3095675

この取り組みの一環として、”Windows 10 を入手する” (以下 GWX) アプリの通知内容およびナビゲーションの最適化を行っております。
本 ブログでは、現時点でユーザー様のお手元に表示される、Windows 10 アップグレードの通知とその中での設定方法についてご紹介いたします。
(なお、最適化が進行中のため、以下の画面と違う画面が表示される場合もございます。)

GWX より表示される以下通知画面での操作についてご紹介いたします。
————————————————————————————————
・ [今すぐアップグレード]: Windows 10 のインストール イメージのダウンロードが開始されます。
・ [今夜アップグレード]: クリック当日の夜間にアップグレードされるようスケジュールされます。
・ [時刻を指定]:5日先までアップグレードをスケジュール出来ます。
※ 今夜アップグレード、時刻を指定のいずれを選択頂いた場合でも、Windows 10 へのアップグレードが予約されます。

1

[今夜アップグレード]を選択した場合
———————————————————————————–
設定当日の夜にアップグレードがスケジュールされます。

ToghtUpg

アップグレードのスケジュールを変更されたい場合には、[アップグレードの予定を変更または取り消し] をクリックします。

アップグレード日時を変更する場合には、以下画面でアップグレードの予定時刻を変更し、[確認] をクリックします。
アップグレードを一旦取り消すには、[アップグレードの予定を取り消す] をクリックします。

ToghtUpgCancel

[アップグレードの予定を取り消す] をクリックすると以下の画面となりますので、[アップグレードの予定を取り消す] をクリックします。
アップグレードのスケジュールが一旦取り消されますので、アップグレード日時をご検討ください。

ToghtUpgCancel2

[時刻を指定] を選択した場合
———————————————————————————–
アップグレードのスケジュールが設定出来ますので、ご都合の良い時間を設定し、[確認] をクリックします。

Timeselect

スケジュールを指定した日時が表示されますので、[閉じる] をクリックして GWXアプリ画面を閉じます。

TimeSelect2

アップグレードのスケジュールを変更する場合には、[アップグレードの予定を変更または取り消し] をクリックします。
変更手順については、”今夜アップグレードを選択した場合” のスケジュール変更と同じとなります。

Windows 10へのアップグレードのスケジュールを確認するには
———————————————————————————–
タスクバー上の Windows アイコン(GWX アプリ)をクリックします。

GWXSelect

以下画面が表示されスケジュールが確認出来ます。
スケジュールの変更を行う場合には、[予定の変更] より、スケジュール変更、アップグレード予定の取り消しが行えます。

Scheled

Windows 10へのアップグレードのスケジュール開始間近になると
———————————————————————————–
スケジュールされたアップグレード時刻の1時間前になるとアップグレードの開始までの時間が通知されます。
[後で実行する] をクリックするとスケジュールの変更およびアップグレードの取り消しが行えます。

Schesuled1h

[予定の変更]をクリックすると、スケジュールの変更およびアップグレードの取り消しが行えます。

Sche2

お使いのデバイスでアップグレードの準備ができるとアップグレードがスケジュールされたことを通知する以下の画面が表示される場合があります。
———————————————————————————–

Reserved2

“今すぐアップグレード” をクリックすると、アップグレードが開始されます。

アップグレード のスケジュール変更またはキャンセルするには、”ここ”(図中赤枠) をクリックすると行うことができます。

[OK]ボタンならびにウィンドウの右上の[x]を選択してウィンドウを閉じた場合は、スケジュールの変更またはキャンセルはされないためスケジュールされた日時にアップグレードが開始されます。。

アップグレード プロセス中のソフトウェア使用許諾(EULA)画面で [拒否] を選択することで、アップグレードを終了してアップグレード前の OS (Windows 7, Windows 8.1) に戻すことができます。
また、Windows 10 にアップグレード後 31 日間は、アップグレード前の OS (Windows 7, Windows 8.1) に戻すことができます。

補足
Windows 10へのアップグレードをしばらくの間お待ち頂く場合には、スケジュールの取り消しおよび予約の取り消しを行った上で、後述の参考情報に記載された設定を実施ください。

予約の取り消しについて
———————————————————————————–
予約を取り消した後も、無償アップグレード期間内であれば、いつでもWindows 10 へアップグレードが出来ますので、ご希望のタイミングにて予約ください。

Rescan1

Rescan2

Rescan3

Rescan4

Rescan5

参考情報
[企業ユーザー向け] Windows Update からの Windows 10 への無償アップグレードを管理する方法
https://blogs.technet.microsoft.com/askcorejp/2015/07/22/windows-update-windows-10-2/

Windows 10 の通知とアップグレードのオプションを管理する方法
https://support.microsoft.com/ja-jp/kb/3080351

これからも、Windows 10 をよろしくお願いいたします。

統合書き込みフィルター (Unified Write Filter (UWF)) について

$
0
0

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

本日は Windows 10 にて新しく利用できるようになった統合書き込みフィルター (Unified Write Filter (UWF)) についてご紹介します。

これまでは組み込み向けとして利用され、弊社からエンドユーザー様への直接の提供がなく、エンドユーザー様向けの日本語ドキュメントが少ない状況となっておりましたため、今回は Windows 10 にて UWF をご検討の皆さまに UWF の概要や使用する上で必要な構成作業等をご紹介いたします。

 

Unified Write Filter (UWF) について

Unified Write Filter (UWF) は Windows Embedded (組み込み向け) の機能として実装されていた Enhanced Write Filter(EWF) や File Based Write Filter(FBWF)、Registry Filter 等の後継機能という位置づけで Windows Embedded 8 にて実装されました。

これらの機能は元々は組み込み向け機器にてディスクやフラッシュデバイスに書き込みを行うことにより、機器の摩耗や劣化を防ぐ目的で実装されました。

Windows 10 では Embedded (組み込み向け) 系も含めてカーネルをひとつに集約したため Embedded (組み込み向け) 系で提供されていた様々な機能が OS の機能として統合され、Windows 10 の Enterprise や Education Edition にて使用できるようになりました。

Embededd

:参考サイト
:Windows Embedded 8.1 Industry からのロックダウン機能 [機能比較情報]
https://technet.microsoft.com/ja-jp/library/mt621548.aspx

Unified Write Filter (UWF) で実現できること

既定では UWF を構成の上で書き込みが行われるとすべての書き込みはメモリ上のオーバーレイ用の領域に書き込まれるため、SSD や フラッシュ メモリ メディアなどの書き込みを行うことで劣化が懸念されるデバイスの摩耗を低減します。
※ディスク上にオーバーレイ用の領域を確保することも可能です。

また、これらの動作によって再起動を行うことで、UWF を構成したタイミングの状態に戻すことが可能です。
(除外設定等を行っていない場合、OS 再起動前に行った設定やファイル等はすべて消去されます)

UWF は HDD や SSD、内蔵 USB デバイスや外付けの SATA デバイスなど、 Windows でサポートされている書き込み可能な標準的なデバイスにて使用することができます。
※UWF は外部リムーバブル ドライブや USB 、フラッシュ ドライブ、記憶域プールを保護するために使用することはできません。
※UWF は高速スタートアップと同時に利用することはできません。

:参考サイト
:Unified Write Filter [英語サイト]
https://msdn.microsoft.com/en-us/windows/hardware/mt572001.aspx

Unified Write Filter (UWF) の構成方法について

Windows 10 にて [プログラムと機能] から UWF の機能を導入し、有効化するには以下の手順にて実施が可能です。

a. 機能のインストール
b. 機能の構成
c. 機能の有効化

a. 機能のインストール

以下の手順にて機能のインストールを実施ください。

1. [コントロール パネル] から [プログラムと機能] を選択します。
2. [Windows の機能の有効化または無効化] を選択します。
3. [統合書き込みフィルター] を選択して、[OK] を選択します。
4. ウィザードに従い、インストール処理を進めます。

以上の手順にて [統合書き込みフィルター] (UnifiedWriteFilter) の導入は完了です。

 b. 機能の構成

設定の変更を行う場合は一度、Filter を無効にしてから設定変更を行い再度有効化を実施ください。
ご案内するそれぞれの作業を実施する場合には管理者権限にて以下の各コマンドを実施ください。

- 設定値の確認コマンド
以下の現在構成中の設定情報を確認することが可能です。
>uwfmgr.exe get-config

- 該当ボリュームの保護の有効化
以下のコマンドを実施した後、設定変更を有効にするにはシステムの再起動を実施します。
>uwfmgr.exe volume protect <ドライブレター>

   //C ドライブのプロテクトを有効に設定する場合
>uwfmgr.exe volume protect c:

- ファイルの除外設定
以下のコマンドを実施した後、設定変更を有効にするにはシステムの再起動を実施します。
>uwfmgr.exe file add-exclusion <除外するファイルパス>

   //C:\Temp\Setting.ini.txt ファイルを除外する場合
>uwfmgr.exe file add-exclusion C:\Temp\Setting.ini.txt

   //C:\Temp1\ フォルダを除外する場合
>uwfmgr.exe file add-exclusion C:\Temp1

- レジストリの除外設定
以下のコマンドを実施した後、設定変更を有効にするにはシステムの再起動を実施します。
>uwfmgr.exe registry add-exclusion <除外するレジストリパス>

   //HKLM\Software\Microsoft\Windows\run を除外する場合
>uwfmgr.exe registry add-exclusion HKLM\Software\Microsoft\Windows\run

 c. 機能の有効化

設定の変更を行う場合は一度、Filter を無効にしてから設定変更を行い再度有効化ください。
それぞれの作業を実施する場合には以下の各コマンドを実施ください。

- フィルターの有効化
以下のコマンドを実施した後、システムの再起動を実施します。
>uwfmgr.exe filter enable

- フィルターの無効化
以下のコマンドを実施した後、システムの再起動を実施します。
>uwfmgr.exe filter disable

:参考サイト
:uwfmgr.exe [英語サイト]
https://msdn.microsoft.com/en-us/library/windows/hardware/mt572002.aspx

 

UWF の一般的な構成や使用方法については以上です。

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

Windows 8.1 の起動時に真っ黒な画面で止まってしまう

$
0
0

こんにちは、Windows  サポートチームです。今回は Windows 8.1 で発生する、起動時に真っ黒な画面で停止してしまう現象について、その理由と対処方法についてご紹介したいと思います。

 

現象:

Windows にサインインした状態からシャットダウンを行うと 「このアプリがシャットダウンを妨げています。」 というメッセージが表示される場合があります。この画面が表示された状態から一旦画面をロック(Windows キー + L)し、その後のパスワード入力画面で強制的にシャットダウンを行うと、次回 Windows の起動時に真っ黒い画面で止まってしまい何も操作ができない状態になってしまいます。

以下に現象発生の流れを画面に沿って説明します。

1. メモ帳を開いて編集状態(データーは未保存の状態)からシャットダウンを選択します。

Capture1

2. 「このアプリがシャットダウンを妨げています。」というメッセージが表示されます。

Capture2

3. Windows キー +L を押下して、画面をロックします。

Capture3

4. サインイン画面に戻り、電源ボタンのマークから [シャットダウン] をクリックします。

Capture4

5. [強制的にシャットダウン] をクリックします。

Capture5

6. シャットダウンが完了後、PC の電源を投入します。

Capture6

7. 暫くすると真っ黒い画面になり、止まってしまいます。

Capture7

 

理由:

「このアプリがシャットダウンを妨げています。」というメッセージは、シャットダウンの処理が途中まで進んだ状態で表示されています。その後、画面をロックして解除した際のシャットダウンから強制的にシャットダウンを行うと、最初のシャットダウンの処理は途中の状態のまま、2 回目の別のシャットダウン要求が発生して Windows はシャットダウンします。この時高速スタートアップが有効である場合は、完全なシャットダウンではなく内部的には休止状態に移行しています。次に Windows を起動すると、休止状態から復帰してきたときに、最初のシャットダウンが途中まで進んでいたところから処理が再開されてしまい黒い画面で止まってしまいます。

 

対処方法:

本来であれば強制シャットダウンを行わずに一旦デスクトップに戻ってアプリケーションの指示に従って頂くのが望ましいのですが、それ以外の方法としては、高速スタートアップの機能を無効化して頂くことで回避することが可能です。(高速スタートアップを無効化することで、起動時間が多少長くなりますのでご留意ください。)

高速スタートアップの機能を無効化する手順を以下に説明します。

1. コントロールパネルを開き、表示方法を [大きいアイコン] にします。

Capture8

2. 電源オプションをクリックします。

Capture9

3. [電源ボタンの動作の選択] をクリックします。

Capture10

4. [現在利用可能でない設定を変更します] をクリックします。

Capture11

5. [高速スタートアップを有効にする] のチェックを外して [変更の保存] ボタンをクリックします。

Capture12

以上の手順で、高速スタートアップの無効化の作業は完了です。

 

なお、この現象については今のところ修正の予定はありません。

また、Windows 10 ではこの現象は発生しないことを確認しています。

V2 VM の IaaS バックアップがパブリック プレビュー版で公開されました

$
0
0
こんにちは、Windows プラットフォーム サポートの世古です。 V2 仮想マシン (リソース マネージャーから作成した仮想マシン) のパブリック プレビュー版 IaaS VM バックアップが公開されました! 以前まではプライベート プレビュー版であり、別途登録等が必要でしたが、現在は新ポータルにアクセスするだけで、Recovery Services Vaults をご利用いただけます。... Read more

クラスター ログにおける MSMQ エラーについて

$
0
0

こんにちは。Windows プラットフォーム サポートの野村です。今回はクラスター ログに記録される MSMQ エラーについてご紹介します。

PowerShell の Get-ClusterLog コマンドレットまたは、管理者権限のコマンドプロンプトにて cluster log /g を実行することでクラスター ログを生成できます。生成したログを確認すると以下のエラーが記録されていることがございます。

ERR   [RHS] s_RhsRpcCreateResType: ERROR_NOT_READY(21)’ because of ‘Startup routine for ResType MSMQ returned 21.’

WARN  [RCM] Failed to load restype ‘MSMQ': error 21.

ERR   [RHS] s_RhsRpcCreateResType: ERROR_NOT_READY(21)’ because of ‘Startup routine for ResType MSMQTriggers returned 21.’

WARN  [RCM] Failed to load restype ‘MSMQTriggers': error 21.

 

<原因>

上述のエラーは、クラスター サービスにリソースの種類として “MSMQ” と “MSMQTriggers” が登録されているものの、MSMQ リソース DLL を読み込めない場合に記録されます。多くの場合、MSMQ の機能がインストールされていないために MSMQ リソース DLL もインストールされておらず、発生するエラーとなります。

 

<考えられる対応方法>

1. 無視する

これらは “MSMQ” と “MSMQTriggers” を利用していない場合には、記録されていても影響の無いイベントですので無視しても問題ございません。クラスターの機能に何も影響を与えず、障害を示すイベントでもございません。

 

2. MSMQ の機能をインストールする

“MSMQ” と “MSMQTriggers” を利用する場合には、サーバー マネージャーを開いて “メッセージ キュー” の機能をクラスターの全てのノードにインストールしてください。これで、上述のエラーは記録されなくなります。

 

3. MSMQ リソースの登録を削除する

“MSMQ” と “MSMQTriggers” を利用しない場合、リソースの種類 “MSMQ” と “MSMQTriggers” の登録を削除します。こうすることで、上述のエラーは記録されなくなります。PoweShell の Remove-ClusterResourceType コマンドレットにより登録の削除が可能ですので、PowerShell のウインドウを開いて、以下のコマンドレットを実行してください。

PS C:\> Remove-ClusterResourceType MSMQ

PS C:\> Remove-ClusterResourceType MSMQTriggers

 

<まとめ>

MSMQ のエラーは MSMQ をインストールしていない場合には無視可能で、一種のノイズのようなものと考えていただいて構いません。これらのイベントがどうしても気になったり、MSMQ を利用する予定が無い場合は、MSMQ リソース タイプの登録を削除してください。

 

<参考情報>

– MSMQ Errors in the Cluster.log

https://blogs.msdn.microsoft.com/clustering/2013/04/05/msmq-errors-in-the-cluster-log/

-【IDM】MSMQ を使って確実なユーザー登録を行う その1 ~ MSMQ って何してくれるの?

https://blogs.technet.microsoft.com/junichia/2008/06/24/idmmsmq-1-msmq-12390/

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

クラスター ログにおける MSMQ エラーについて

$
0
0

こんにちは。Windows プラットフォーム サポートの野村です。今回はクラスター ログに記録される MSMQ エラーについてご紹介します。

PowerShell の Get-ClusterLog コマンドレットまたは、管理者権限のコマンドプロンプトにて cluster log /g を実行することでクラスター ログを生成できます。生成したログを確認すると以下のエラーが記録されていることがございます。

ERR   [RHS] s_RhsRpcCreateResType: ERROR_NOT_READY(21)’ because of ‘Startup routine for ResType MSMQ returned 21.’

WARN  [RCM] Failed to load restype ‘MSMQ': error 21.

ERR   [RHS] s_RhsRpcCreateResType: ERROR_NOT_READY(21)’ because of ‘Startup routine for ResType MSMQTriggers returned 21.’

WARN  [RCM] Failed to load restype ‘MSMQTriggers': error 21.

 

<原因>

上述のエラーは、クラスター サービスにリソースの種類として “MSMQ” と “MSMQTriggers” が登録されているものの、MSMQ リソース DLL を読み込めない場合に記録されます。多くの場合、MSMQ の機能がインストールされていないために MSMQ リソース DLL もインストールされておらず、発生するエラーとなります。

 

<考えられる対応方法>

1. 無視する

これらは “MSMQ” と “MSMQTriggers” を利用していない場合には、記録されていても影響の無いイベントですので無視しても問題ございません。クラスターの機能に何も影響を与えず、障害を示すイベントでもございません。

 

2. MSMQ の機能をインストールする

“MSMQ” と “MSMQTriggers” を利用する場合には、サーバー マネージャーを開いて “メッセージ キュー” の機能をクラスターの全てのノードにインストールしてください。これで、上述のエラーは記録されなくなります。

 

3. MSMQ リソースの登録を削除する

“MSMQ” と “MSMQTriggers” を利用しない場合、リソースの種類 “MSMQ” と “MSMQTriggers” の登録を削除します。こうすることで、上述のエラーは記録されなくなります。PoweShell の Remove-ClusterResourceType コマンドレットにより登録の削除が可能ですので、PowerShell のウインドウを開いて、以下のコマンドレットを実行してください。

PS C:\> Remove-ClusterResourceType MSMQ

PS C:\> Remove-ClusterResourceType MSMQTriggers

 

<まとめ>

MSMQ のエラーは MSMQ をインストールしていない場合には無視可能で、一種のノイズのようなものと考えていただいて構いません。これらのイベントがどうしても気になったり、MSMQ を利用する予定が無い場合は、MSMQ リソース タイプの登録を削除してください。

 

<参考情報>

– MSMQ Errors in the Cluster.log

https://blogs.msdn.microsoft.com/clustering/2013/04/05/msmq-errors-in-the-cluster-log/

-【IDM】MSMQ を使って確実なユーザー登録を行う その1 ~ MSMQ って何してくれるの?

https://blogs.technet.microsoft.com/junichia/2008/06/24/idmmsmq-1-msmq-12390/


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

クラスター ログにおける MSMQ エラーについて

$
0
0

こんにちは。Windows プラットフォーム サポートの野村です。今回はクラスター ログに記録される MSMQ エラーについてご紹介します。

PowerShell の Get-ClusterLog コマンドレットまたは、管理者権限のコマンドプロンプトにて cluster log /g を実行することでクラスター ログを生成できます。生成したログを確認すると以下のエラーが記録されていることがございます。

ERR   [RHS] s_RhsRpcCreateResType: ERROR_NOT_READY(21)’ because of ‘Startup routine for ResType MSMQ returned 21.’

WARN  [RCM] Failed to load restype ‘MSMQ': error 21.

ERR   [RHS] s_RhsRpcCreateResType: ERROR_NOT_READY(21)’ because of ‘Startup routine for ResType MSMQTriggers returned 21.’

WARN  [RCM] Failed to load restype ‘MSMQTriggers': error 21.

 

<原因>

上述のエラーは、クラスター サービスにリソースの種類として “MSMQ” と “MSMQTriggers” が登録されているものの、MSMQ リソース DLL を読み込めない場合に記録されます。多くの場合、MSMQ の機能がインストールされていないために MSMQ リソース DLL もインストールされておらず、発生するエラーとなります。

 

<考えられる対応方法>

1. 無視する

これらは “MSMQ” と “MSMQTriggers” を利用していない場合には、記録されていても影響の無いイベントですので無視しても問題ございません。クラスターの機能に何も影響を与えず、障害を示すイベントでもございません。

 

2. MSMQ の機能をインストールする

“MSMQ” と “MSMQTriggers” を利用する場合には、サーバー マネージャーを開いて “メッセージ キュー” の機能をクラスターの全てのノードにインストールしてください。これで、上述のエラーは記録されなくなります。

 

3. MSMQ リソースの登録を削除する

“MSMQ” と “MSMQTriggers” を利用しない場合、リソースの種類 “MSMQ” と “MSMQTriggers” の登録を削除します。こうすることで、上述のエラーは記録されなくなります。PoweShell の Remove-ClusterResourceType コマンドレットにより登録の削除が可能ですので、PowerShell のウインドウを開いて、以下のコマンドレットを実行してください。

PS C:\> Remove-ClusterResourceType MSMQ

PS C:\> Remove-ClusterResourceType MSMQTriggers

 

<まとめ>

MSMQ のエラーは MSMQ をインストールしていない場合には無視可能で、一種のノイズのようなものと考えていただいて構いません。これらのイベントがどうしても気になったり、MSMQ を利用する予定が無い場合は、MSMQ リソース タイプの登録を削除してください。

 

<参考情報>

– MSMQ Errors in the Cluster.log

https://blogs.msdn.microsoft.com/clustering/2013/04/05/msmq-errors-in-the-cluster-log/

-【IDM】MSMQ を使って確実なユーザー登録を行う その1 ~ MSMQ って何してくれるの?

https://blogs.technet.microsoft.com/junichia/2008/06/24/idmmsmq-1-msmq-12390/

Azure Backup reliability update: March 2016

$
0
0

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

MARS エージェントの最新版が先日公開されました。本修正におきましては、大容量のストレージ (2 TB 以上) のバックアップを行う際などに発生しておりましたファイル カタログのアップロードに失敗する問題について改善されております。またその他のバックアップにおける問題についても改善されておりますので、今後の安定運用の為にも、アップデートいただけますと幸いです。

詳細につきましては、以下の公開情報をご参照ください。
Azure Backup reliability update: March 2016
(日本語機械翻訳版)

また MARS エージェントのアップデートにつきましては、以下の内容をご参照いただけますと幸いです。

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

クラスター ログにおける MSMQ エラーについて

$
0
0

こんにちは。Windows プラットフォーム サポートの野村です。今回はクラスター ログに記録される MSMQ エラーについてご紹介します。

PowerShell の Get-ClusterLog コマンドレットまたは、管理者権限のコマンドプロンプトにて cluster log /g を実行することでクラスター ログを生成できます。生成したログを確認すると以下のエラーが記録されていることがございます。

ERR   [RHS] s_RhsRpcCreateResType: ERROR_NOT_READY(21)’ because of ‘Startup routine for ResType MSMQ returned 21.’

WARN  [RCM] Failed to load restype ‘MSMQ': error 21.

ERR   [RHS] s_RhsRpcCreateResType: ERROR_NOT_READY(21)’ because of ‘Startup routine for ResType MSMQTriggers returned 21.’

WARN  [RCM] Failed to load restype ‘MSMQTriggers': error 21.

 

<原因>

上述のエラーは、クラスター サービスにリソースの種類として “MSMQ” と “MSMQTriggers” が登録されているものの、MSMQ リソース DLL を読み込めない場合に記録されます。多くの場合、MSMQ の機能がインストールされていないために MSMQ リソース DLL もインストールされておらず、発生するエラーとなります。

 

<考えられる対応方法>

1. 無視する

これらは “MSMQ” と “MSMQTriggers” を利用していない場合には、記録されていても影響の無いイベントですので無視しても問題ございません。クラスターの機能に何も影響を与えず、障害を示すイベントでもございません。

 

2. MSMQ の機能をインストールする

“MSMQ” と “MSMQTriggers” を利用する場合には、サーバー マネージャーを開いて “メッセージ キュー” の機能をクラスターの全てのノードにインストールしてください。これで、上述のエラーは記録されなくなります。

 

3. MSMQ リソースの登録を削除する

“MSMQ” と “MSMQTriggers” を利用しない場合、リソースの種類 “MSMQ” と “MSMQTriggers” の登録を削除します。こうすることで、上述のエラーは記録されなくなります。PoweShell の Remove-ClusterResourceType コマンドレットにより登録の削除が可能ですので、PowerShell のウインドウを開いて、以下のコマンドレットを実行してください。

PS C:\> Remove-ClusterResourceType MSMQ

PS C:\> Remove-ClusterResourceType MSMQTriggers

 

<まとめ>

MSMQ のエラーは MSMQ をインストールしていない場合には無視可能で、一種のノイズのようなものと考えていただいて構いません。これらのイベントがどうしても気になったり、MSMQ を利用する予定が無い場合は、MSMQ リソース タイプの登録を削除してください。

 

<参考情報>

– MSMQ Errors in the Cluster.log

https://blogs.msdn.microsoft.com/clustering/2013/04/05/msmq-errors-in-the-cluster-log/

-【IDM】MSMQ を使って確実なユーザー登録を行う その1 ~ MSMQ って何してくれるの?

https://blogs.technet.microsoft.com/junichia/2008/06/24/idmmsmq-1-msmq-12390/

Windows Server 2012 (2012 R2) の EFI システム パーティション サイズについて

$
0
0

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

今回は、Windows Server 2012 や Windows Server 2012 R2 を EFI 構成にインストールしたときの既定のパーティション サイズについてご紹介いたします。

Technet などの技術文書では、EFI システム パーティションを構成する際のサイズを最小 100 MB としてご紹介いたしておりますが、Windows セットアップからインストールを実行した場合、以下の画像のように 99 MB となることがございます。
99 MB 、100 MB いずれのサイズであっても、Windows によって構成された設定となりますので、システム上問題ありませんのでご安心ください。

EFIRED

– 補足
既存の環境を再構築する場合、以下のようにセットアップ手順によって差異が生じますが、問題ありません。

Windows セットアップの画面でパーティションを切り直すと 100 MB の EFI システム パーティションが構成されます。
Diskpart (Diskpart Clean) コマンドなどで、ディスクをクリーンにしたあとに、Windows セットアップよりインストールを進めた場合、99 MB の EFI システム パーティションが構成されます。

Viewing all 590 articles
Browse latest View live




Latest Images