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

Active Directory サーバーでシステム状態のバックアップに失敗する

$
0
0

こんにちは。日本マイクロソフト株式会社 高谷 です。

最近、Active Directory サーバーにおいて、Windows Server バックアップで “システム状態” のバックアップをとろうとすると失敗する、というお問い合わせを複数のお客様からいただきましたが、多くのケースで vsock.sys (VMWare製)ドライバーの ImagePath が不正な値になっていることが原因であることが確認できました。

この事例に当てはまる場合、ユーザー様にて比較的簡単に修復ができますので、原因と対処方法についてご紹介したいと思います。
この事例に当てはまるかご確認いただき、当てはまる場合は修復方法をお試し下さい。
.

■ 事象の確認ポイント

.
確認ポイント (1)  環境の確認

お客様の環境は以下に当てはまりますか?

…..・VMWare 環境である。(物理サーバーおよび Hyper-V 仮想環境では事象は確認されておりません。)

…..・OS は Windows Server 2012 R2もしくは Windows Server 2016 である。

…..・Active Directory の役割を担っている。

.
確認ポイント (2)  バックアップのログの確認

エラーのログが以下のパスに作成されていますか?

…..パス:C:\Windows\Logs\WindowsServerBackup\Backup_Error-dd-mm-yyyy_xx-xx-xx.log

▽ Backup ログに記録されるエラーの内容
———————————————————————————————-
C:\windows\\systemroot\ のバックアップで列挙中にエラーが発生しました: エラー [0x8007007b]
ファイル名、ディレクトリ名、またはボリューム ラベルの構文が間違っています。
———————————————————————————————-

.
確認ポイント (3)  イベント ログの確認

アプリケーションのイベント ログには、以下のログが記録されていますか?

▽ アプリケーションのイベント ログに記録されるエラーのイベント
———————————————————————————————-
レベル:エラー
イベントソース:Backup
イベント ID:517
メッセージ:’‎YYYY‎-‎MM‎-‎DDT09:00:43.533016300Z’ に開始したバックアップ操作は、次のエラー コード ‘0x80780049’ (バックアップに含まれるいずれの項目もバックアップされませんでした。) のため失敗しました。
イベントの詳細で解決策を確認し、問題の解決後にバックアップ操作を再実行してください。
———————————————————————————————-

上記 3 点が全て当てはまる場合、この事例に合致する可能性が高いですので、次の項の修復方法をお試しください。
.

■ 修復方法

.
vsock.sys ドライバーの ImagePath のパス情報の \SystemRoot\ を削除することで改善します。

// 修正手順

  1. [スタート] > [ファイル名を指定して実行] > regedit と入力してレジストリ エディターを起動します。
  2. 以下のパスの階層を展開します。

……….HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Services > vsock

  1. ImagePath の値を右クリック > 修正 をクリックし以下のように変更します。

…..…..———————————————————————
…..…..変更前:
….…...\SystemRoot\system32\DRIVERS\vsock.sys

…..…..変更後:
…..…..system32\DRIVERS\vsock.sys
…..…..———————————————————————

……….※ 変更内容は \SystemRoot\ を削除するのみです。

  1. レジストリ エディターを終了し再起動を実施します。

……….以上で作業は完了です。

なお、上記のレジストリの変更作業が、Active Directory の機能も含めてシステムへ影響を与えた報告はございませんので、ご安心ください。
.

■ 原因

.
バックアップ取得の要求が発生すると、まず静止点の確保のために、各種 VSS Writer がそれぞれの管轄するモジュールの列挙を行います。列挙が正常に完了して初めて静止点の確保が行われ、バックアップが取得される流れとなります。

今回の事象は、VSS Writer の一つである System Writer が、自身が管轄するモジュールの一つである vsock.sysの列挙に失敗したことで、バックアップ取得に失敗しています。

さらに、vsock.sys の列挙に失敗した理由としては、vsock.sys の ImagePath の情報が正しくないことが原因です。

通常、各ドライバーの情報は、ドライバーのインストール時にレジストリに保存されており、この情報の一つである ImagePath に正しくない値が入力されていることにより、列挙に失敗します。

そのため、ImagePath の値を正しい値に修正すれば今回の事象は改善します。

▽ vsock.sys の ImagePath の情報
———————————————————————
誤:\SystemRoot\system32\DRIVERS\vsock.sys

正:system32\DRIVERS\vsock.sys
———————————————————————

(参考) vsock.sys とは?
vscok.sys は VMWare 様の提供する VMWare Tools のドライバーです。
以下に VMWare 様の公開情報ページを掲載します。

.
VMWare 様 公開情報)
“VMware Tools デバイス ドライバ”
https://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vmtools.install.doc%2FGUID-6994A5F9-B62B-4BF1-99D8-E325874A4C7A.html

なお、VMWare 様の公開質問ページにて、この事象が取り上げられておりました。

.
VMWare 様公開情報)
“Unable to backup Windows AD Server with VMware Tools installed”
https://communities.vmware.com/thread/565599

いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立てますと幸いです。


STOP エラー 0x00000050 メッセージが Windows ベースのコンピューターで表示される事象について

$
0
0

いつも弊社製品をご利用いただきまして誠にありがとうございます。
Windows プラットフォーム サポートの石田です。

パフォーマンス モニターのプロセス情報の監視を行っている環境などプロセスの情報を参照する処理を行っている環境にて STOP エラー 0x00000050 が発生した場合の対応についてご案内させていただきます。

[事象]
Microsoft Windows Server 2012 ベースまたは Microsoft Windows Server 2012 R2 ベースのコンピューターで、パフォーマンス モニターのプロセス情報の監視を行っている環境などプロセスの情報を参照する処理を行っている環境にて、ごく稀に以下の STOP エラー メッセージが表示され予期せぬ再起動が発生します。


STOP:0x00000050 (parameter1, parameter2, parameter3, parameter4)

PAGE_FAULT_IN_NONPAGED_AREA (50)


注意事項
STOP エラー メッセージ内のパラメーターは、コンピューターの構成によって異なる場合があります。
すべての STOP エラー 0x00000050 メッセージが本問題とは限りません。

[原因]
プロセスの情報を参照する処理と参照対象のプロセスの終了が重なった際に、ごくわずかなタイミングでメモリー マネージャーが解放済みの領域にアクセスしてしまい、STOP エラーが検知されます。

[解決策]
本事象は Windows Server 2016 以降で改修されました。Windows Server 2012 R2 以前の OS では修正はリリースされておりません。

[回避策]
Windows Server 2012 R2 以前の OS では本事象を完全に回避する方法はありません。ただし、プロセス情報のパフォーマンス カウンターを取得し監視を行っている場合は、参照頻度を下げるもしくは監視を除外することで発生頻度を軽減できる可能性があります。

本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。

高速スタートアップの設定が有効な場合にOS をシャットダウンすると、次回起動後に Numlock キーがオフになる

$
0
0

こんにちは、日本マイクロソフトの Windows サポートチームです。
今回は、Windows 10 環境で高速スタートアップが有効時に次回起動時に Numlock がオフになる事象についてご紹介いたします。

【事象】
本事象は、以下の条件が全て揃った時に次回ログイン時に Numlock キーがオフになります。
この動作は次回起動前後に Numlock キーをオンとしてもシャットダウン操作を行うと
次回次回起動後に Numlock キーがオフとなります。

- 発生条件
・高速スタートアップが有効
・シャットダウン

高速スタートアップが有効かどうかはイベント ログからもご確認いただけます。

—- 高速スタートアップが有効であることを確認する

システム イベント ログから以下のようなイベント ID 27、ソース Kernel-Boot にて、
ブートの種類が “0x1” の場合に高速スタートアップが有効です。

———————————————–
ログの名前: System
ソース: Microsoft-Windows-Kernel-Boot
日付: 2018/08/06 xx:xx:xx
イベント ID: 27
タスクのカテゴリ: (33)
レベル: 情報
キーワード:
ユーザー: SYSTEM
コンピューター: TEST-DESKTOP
説明:
ブートの種類は 0x1 でした。
^^^
———————————————–

【原因】
弊社製品の既知の問題となります。

【回避策】
次回起動後にログイン画面が表示されたら、キーボード操作でNumlock キーをオンと変更してください。

ボリューム シャドウ コピー サービス (VSS) について

$
0
0

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

本ブログでは、ボリューム シャドウコピー サービス(以下、VSS) についてご紹介いたします。
VSS は Windows において、バックアップの作成や “以前のバージョン” 機能をはじめとする様々な役割を支える重要なテクノロジーです。
弊社では VSS に関連したお問い合わせも多くいただいておりますので、VSS に関して基本的な仕組みとよくあるお問い合わせ事例についてまとめ、公開をさせていただきます。
本ブログが皆様のお役に立てば幸いです。

■ VSS とは?

.
ボリューム シャドウ コピー サービス(VSS)は、ボリュームの静止点であるシャドウ コピーを作成するサービスです。通常、サービスは停止しており、必要に応じて呼び出され、シャドウ コピーを作成します。
このシャドウ コピーをもとにバックアップを作成したり、そのまま保管して古いファイルを復元できるようにするなどの用途で利用されます。シャドウ コピーのことを ”スナップショット” と呼称する場合もございますが、本公開情報では表現をシャドウ コピーに統一します。

■ シャドウ コピーの実体

.
シャドウ コピーとは、実体としては「静止点を確保したタイミングからの差分データ」です。
シャドウ コピーを作成すると、ボリューム全体が一旦静止し、Diff Area と呼ばれる差分データの格納領域が作成されます(下図の②)。つまりこの時点では、差分データを格納するための空の箱が確保された状況であり、この空の箱がシャドウ コピーの実体となるファイルです。ここから、ファイルの更新等によりボリューム内のデータに変更箇所が生じると、変更前のデータを Diff Area に退避させ、格納します(下図の③)。

このように、ボリューム内のデータに変更が発生すると、その都度変更前のデータを Diff Area へ退避してゆくので、静止点を確保したタイミングへファイルを戻したい場合は、Diff Area に保存された以前のデータを使って復元を行うことができます。
ここで、次のシャドウ コピーを作成した場合の動作についても説明をしておきましょう。次のシャドウ コピーを作成すると、これ以降の差分データはこの Diff Area には退避されなくなり、Diff Area は 1 世代前のシャドウ コピーとして確定します (下図の④~⑤)。確定と同時に新たな Diff Area が作成され、以降にデータ更新が発生した場合は、この新 Diff Area にデータが退避されます(下図の⑥)。

この状況でさらにボリューム内のデータに変更が生じた場合 (下図の⑦~下図の⑧)、これまでに待避していなかった箇所への変更が発生した場合は、差分データを Diff Area へ退避させますが、すでに退避したことのある個所への変更であれば、差分データの待避は行われません。

このようにして退避した差分データを確定させ、新たな Diff Area に最新の変更データを退避していくことによりシャドウ コピーは複数の世代を管理することができ、復元したいタイミングのシャドウ コピーを利用して過去のファイルを復元することが可能です。
通常、シャドウ コピーを作成する際に Diff Area を意識する必要はありませんが、シャドウ コピーの実体としては「静止点を確保したタイミングからの差分データ」であることはご理解いただければ幸いです。

■ VSS を構成する 4 つのコンポーネント

.
VSS は、ボリュームの静止点を確保するサービスですが、以下の 4 つのコンポーネントによって動作しています。

・VSS リクエスター (VSS Requester / VSS-R)
VSS を利用する(シャドウコピーの作成を要求する)コンポーネント。バックアップソフトなど。VSS サービスを起動する最初のきっかけであり、バックアップ ソフトウェアなどが保有しています。リクエスターによってシャドウ コピーの作成要求が出され、作成がスタートします。

・VSS サービス (VSS Service / VSS-S) (vssvc.exe)
VSS リクエスターからの要求を受け、VSS ライター(後述)やVSS プロバイダー(後述)を制御し、シャドウコピーの作成の過程のコントロールを行うコンポーネント。

・VSS ライター (VSS Writer / VSS-W)
VSS サービスからの指令により、シャドウ コピーを作成するために、各アプリケーションを一旦静止する役割をもつコンポーネント。すべてのアプリケーションが整合性のとれた状態になるために必要な処理を実施します。アプリケーションごとに存在し、各 VSS ライターは自信に紐づいたアプリケーションの処理を行います。

・VSS プロバイダー (VSS Provider / VSS-P)
VSS サービスからの指令により、シャドウ コピーの作成を行うコンポーネント。整合性が取れることを確認した上でシャドウ コピーを作成するため、VSS サービスを通して VSS ライターとも密に連携して動作します。

それぞれのコンポーネントが連携してシャドウ コピーを作成します。大まかな動作の流れは以下のようになっています。

■ Diff Area について

.
・Diff Area のサイズについて

既にご説明の通り、Diff Area はシャドウ コピーを作成するときに用意される、差分データ退避用の空の箱です。既定の初期サイズはボリュームのサイズと残りの空き領域のサイズに応じて OS 内部ロジックによって計算され、32 MB ~ 3 GB のサイズで確保されます。この領域に差分データが次々と格納されていきますが、差分データが初期サイズを上回ることが予想された場合、システムによって Diff Area は自動的に拡張され、継続して差分データが保存されてゆきます。
Diff Area の初期サイズは、レジストリ設定によって固定することも可能です。Windows Server 2012R2 までの OS での固定可能な最大サイズは 3 GB、最小サイズは 300 MB です。Windows Server 2016 では、最大サイズが拡張されており、50 GB まで指定が可能です。

注 1 : Windows Server 2012R2 では、以下の修正プログラムを適用することで Diff Area の固定可能な最大サイズを Windows Server 2016 と同じ 50 GB まで引き上げることができます。

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

注 2 : Diff Area サイズの指定は、ボリュームごとの指定ではなく、すべてのボリュームに一律で適用されます。従って、例えば Windows Server 2016 でDiff Area のサイズを 50 GB に指定した場合、C ドライブなど容量が十分に確保できていないボリュームに関してはシャドウ コピーが作成できなくなります。ご注意ください。

・Diff Area の確保される場所について

Diff Area は既定では、シャドウ コピーを作成する対象のボリューム内に確保されます。シャドウ コピーを作成すると、ボリューム内に隠しフォルダとして、”System Volume Information” という名称のフォルダが自動的に作成されます。シャドウ コピーはその中にファイルとして確認することができます。

次のシャドウ コピーを作成すると、Diff Area はその時点までの差分データとして確定され、それ以上の差分データはここには保存されません。同時に新たなDiff Area が確保され、以降の差分データはこの新しい Diff Area に保存されるようになります。Diff Area がその時点までの差分データとして確定される際に、Diff Area 内に空き容量があれば、この空き容量は解放されます。

・シャドウ コピーとバックアップ

これまでのご説明の通り、シャドウ コピーとは、確保した Diff Area に差分データを退避しているだけであり、ボリュームの完全なコピーを保管しているわけではありません。この意味ではシャドウ コピーはバックアップではない、と言えます。Diff Area の拡張に失敗したり、新たな Diff Area を確保できない場合に、シャドウ コピーの作成に失敗したり、古いシャドウ コピーが削除されることがありますので、バックアップとしての用途をお考えの場合は、バックアップ ソフトウェアでバックアップを取得する方がより確実です。

また、バックアップ ソフトウェアでバックアップを取得する際も、バックアップ中にボリューム内のデータに変更が発生する可能性があるため、一旦シャドウ コピーが作成されて、これをもとにデータをコピーする仕組みが一般的です。
コピーが完了してバックアップが完了すると、シャドウ コピーは削除されます。

■ よくいただくご質問

.
ここからは、よくいただくご質問と事象ごとに詳しくご案内している弊社公開情報をご紹介いたします。

Q1. シャドウ コピーの保管先の場所を変更したい。現在は既定値のまま、シャドウ コピーを作成したボリューム内に格納しているので、これを消さずに別の場所へ移動させたい。

A1. シャドウ コピーの保管先の場所を変更すること自体は可能です。しかしながら、既存のシャドウ コピーを維持したまま変更することはできません。一旦既存のシャドウ コピーをすべて削除したうえで、保管先を変更する必要があります。保管先の変更は、以下の手順で行います。

(1) ボリュームを右クリックし、[プロパティ] を開きます。
(2) [シャドウ コピー] のタブを開きます。
(3) 対象ボリュームが選択されていることを確認して、[設定] をクリックします。
(4) “記憶域” の項目でプルダウン メニューからシャドウ コピー保管先のボリュームを変更します。

Q2. シャドウ コピー機能は無効の状態なのに、勝手に作成されている。

A2. “次回実行時刻=無効” の設定は、スケジュールによるシャドウ コピー作成が無効となっている事を示しています。そのため、実際のシャドウ コピーの作成および保存動作とは異なり、VSSを使用するバックアップを実施した場合などシャドウコピーが保存されることがあります。
なお、”有効” となっている場合は、定期的にシャドウ コピーが作成されるようにスケジュールが組まれていることを示し、既定では ”無効” となっています。

Q3. サード パーティ製のバックアップ ソフトウェアで、日次でバックアップを取得している。一時的に作成されるシャドウ コピーはどこに作成されるのか。

A3. バックアップ ソフトウェアに依存いたします。例えば、Windows Server 標準のバックアップ ソフトウェアである ”Windows Server バックアップ” でバックアップを取得いただく場合、バックアップ対象ボリューム内にシャドウ コピーは作成されます。しかし、サード パーティ製のバックアップ ソフトウェアでは、全ボリュームの空き容量を確認し、最も空いているボリュームを自動的に選択してシャドウ コピーを作成する動作となっているものもございます。

■ VSS に関連する弊社公開情報のご紹介

.
シャドウ コピーやバックアップに関連した公開情報が複数ありますので、ご紹介いたします。各事象については本ブログよりも詳細に説明していますので、詳しくは各公開情報を参照ください。

“Volsnap 25 イベントについて”

イベント ログにソース:Volsnap、ID:25 のエラーのイベントが記録され、それまでに取得していたシャドウ コピーが全て消えてしまう事象についてご紹介しています。

“ボリューム シャドウコピーの履歴が消える現象について”

上述の「Volsnap 25 イベントについて」と近い内容となっていますが、具体的な対処策の手順を説明していますので、合わせてご確認いただくことをお勧めします。

“VolSnap 33 が大量に出てしまう問題について”

イベント ログにソース:Volsnap、ID:33 のエラーのイベントが記録され、それまでに取得していたシャドウ コピーが全て消えてしまう事象についてご紹介しています。

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

気づいたらシャドウ コピーがボリュームの容量を圧迫していることがあります。必要に応じてシャドウ コピーを削除することで、空き領域を作ることができるのですが、まれに削除に失敗することがあります。シャドウ コピーが削除できなくてお困りの時はこちらの公開情報をご確認ください。

“Windows Server バックアップにおける容量と世代管理について”

バックアップとシャドウ コピーには深い関連があります。
この公開情報は、主にWindows Server バックアップについて紹介していますが、シャドウ コピーに関しても説明がありますので、お役に立つ情報と思います。

“エクスプローラーで全ファイルを選択したときのファイル合計サイズとディスクのプロパティの使用領域との差異は何故おきるのか?”

シャドウ コピーが保存される”System Volume Information” フォルダについてご説明している公開情報です。

“Registry Keys and Values for Backup and Restore”
https://docs.microsoft.com/ja-jp/windows/desktop/Backup/registry-keys-for-backup-and-restore#mindiffareafilesize

Diff Area の初期サイズは、通常はボリュームのサイズと空き領域のサイズで OS によって計算され、サイズが決定しますが、レジストリ設定によって固定することが可能です。具体的なレジストリの場所については上記公開情報の ”MinDiffAreaFileSize” の項目をご確認ください。

“MinDiffAreaFileSize レジストリ に関しての更新プログラムが公開されました。”
https://blogs.technet.microsoft.com/askcorejp/2016/05/23/mindiffareafilesize-レジストリ-に関しての更新プログラムが公/

“Diff Area について” の項目で触れましたが、Windows Server 2012 R2 では、修正プログラムを適用することで Diff Area の固定可能な最大サイズを Windows Server 2016 と同じ 50 GB まで引き上げることができます。この公開情報で修正プログラムのご説明をしています。

いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立てば幸いです。

操作を 2 つ以上設定したタスクの実行が失敗する問題について

$
0
0

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

本日はタスク スケジューラにて “操作” を複数登録しているタスクの実行が失敗する問題について、ご紹介いたします。

[現象]

タスク スケジューラにて、タスクに “操作” を複数 (2 つ以上) 登録した場合、タスクのスケジュール時刻がスキップされたタイミング以降に、タスクがスケジュール実行されなくなる問題があります。

ここでタスクのスケジュール時刻がスキップされたタイミングとは、例えば、システムのシャットダウン中にタスクのスケジュール時刻 (トリガーに設定した日時) が過ぎてしまい、その後 システムを起動したタイミングが該当します。システムの再起動以外にも、システムの時刻変更、またはタスクの無効化と有効化等の操作により、同様にスケジュール時刻がスキップされる可能性があります。
スケジュール時刻がスキップされて以降、(“操作” が複数登録されたタスクは) 以降のスケジュール実行のタイミングで実行失敗します。

なお、もし事象が発生した場合でも、システムの再起動を行うか、または、一度タスクのプロパティを開き、保存を行うことで、それ以降の実行は成功します。

[発生条件]

この問題は以下の 3 つの条件を全て満たす場合に発生します。

① OS バージョンが以下のいずれかに該当する。

Windows Server 2016
Windows Server 2012 R2
Windows 10 (Version 1803 までの全てのバージョン)
Windows 8.1

② “操作” を複数 (2 つ以上) 登録しているタスク。

③ [設定] タブにて “スケジュールされた時刻にタスクを開始できなかった場合、すぐにタスクを実行する” が設定されていないタスク。

[対処策]

操作を 1 つにしていただくことで回避が可能です。
全ての処理内容を 1 つのバッチ ファイル (またはスクリプト ファイル) にまとめる、または、複数の処理を順次呼び出すバッチ ファイルを作成する等の方法が考えられます。

[関連情報]

タスク スケジューラにおいて、すべてのタスクの履歴を有効化している場合には、タスクのスケジュール時刻がスキップされたタイミング、および、事象が発生したタイミングで以下のイベントが記録されます。

タスクのスケジュール時刻がスキップされたタイミングで記録されるイベント:
————————————————————
ログの名前: Microsoft-Windows-TaskScheduler/Operational
ソース: Microsoft-Windows-TaskScheduler
イベント ID: 153
タスクのカテゴリ: 実行されなかったタスクの起動が拒否されました
レベル: 警告
説明:
タスク スケジューラは、スケジュールに間に合わなかったため、タスク “<タスク名>” を起動しませんでした。スケジュールに間に合わなかった場合は可能なときにタスクを起動するという構成オプションの使用を検討してください。
————————————————————

事象が発生したタイミングで記録されるイベント:
————————————————————
ログの名前: Microsoft-Windows-TaskScheduler/Operational
ソース: Microsoft-Windows-TaskScheduler
イベント ID: 322
タスクのカテゴリ: 起動要求が無視されました。インスタンスは既に実行中です
レベル: 警告
説明:
タスク スケジューラは、タスク “<タスク名>” を起動しませんでした。同じタスクのインスタンス “<インスタンス GUID>” が既に実行されているためです。
————————————————————

2018 年 8 月時点で、本問題を全て解消する更新プログラムのご用意はございませんため、上記の対処の実施をご検討いただけますと幸いです。

この問題について新たな情報が確認でき次第、本ブログ記事を更新させていただきます。

Windows 10 における Sysprep 実行時の注意点 その 1

$
0
0

みなさん、こんにちは。

日本マイクロソフト Windows サポート チームです。
今回は Windows 10 バージョン 1803 における Sysprep 実行ユーザーの注意事項について、ご紹介いたします。

現在、Windows 10 バージョン 1803 において展開作業を進めているお客様より CopyProfile を有効とした応答ファイルを使用して Sysprep を実行した際、Sysprep の処理が正常に完了しないとのお問い合わせを多くお寄せいただいております。

この事象は Windows 10 バージョン 1803 において、クリーン インストール時に作成したユーザーで Sysprep を実行した場合に発生するもので、実行ユーザーを Built-in Administrator にしていただくことで、回避することができます。

– 回避手順

1. OS のクリーン インストール時に作成されたユーザーで Built-in Administrator を有効化します。
2. 有効化した Built-in Administrator でログオンし、クリーン インストール時に作成したユーザー アカウントおよびユーザー プロファイルを削除します。

※ ユーザー プロファイルの削除は、以下の手順で行って下さい。

—————————————————–
<ユーザー プロファイルの削除手順>

1. コントロール パネルを起動し、システムを選択します。
2. 左ペイン内の [システムの詳細設定] をクリックします。
3. [システムのプロパティ] が開きますので、[詳細設定] タブ内の [ユーザー プロファイル] から [設定] 開きます。
4. [このコンピューターに格納されているプロファイル] からクリーン インストール時に作成したユーザーを選択し、下部に表示された削除ボタンから削除を実行してください。
—————————————————–

また、上記ユーザー プロファイルの削除によってユーザーに保持されるカスタマイズ情報もあわせて削除されるため、Built-in Administrator でカスタマイズの作業を行ってください。

3. Built-in Administrator で CopyProfile を有効とした応答ファイルを使用して Sysprep を実行して下さい。

※ Built-in Administrator で Sysprepを実行した場合、Built-in Administrator は無効化されます。

-参考情報

以下の公開情報にも記載があります通り、CopyProfile を有効化して Sysprep を実行する際には、Built-in Administrator
アカウントで実行していただく必要があります。

CopyProfile
https://docs.microsoft.com/en-us/windows-hardware/customize/desktop/unattend/microsoft-windows-shell-setup-copyprofile

———- 公開情報より抜粋 ——————–
On the reference computer, only use the built-in administrator account.
Creating multiple accounts might result in copying the wrong user profile as the default profile.
————————————————

Windows 10 バージョン 1803 において Sysprep を実行される際に、ご参考になればうれしく思います。

なお、本ブログは予告なく変更される場合がございますのでご了承下さい。

クラスターの検証 (記憶域の項目) で失敗する

$
0
0

いつも弊社製品をご利用いただきまして誠にありがとうございます。
Windows プラットフォーム サポートの岩井です。

フェールオーバークラスターを構成している仮想環境(仮想OS)でクラスターの検証を実施した場合、
記憶域の項目でローカルディスクに対して検証が行われ、エラーが発生するという件でよくお問い合わせをいただいております。
今回は、当該事象についてご紹介いたします。

[事象]

クラスターを構成している仮想環境(仮想OS)で、フェールオーバークラスターの構成検証テストを実施した場合に、
記憶域項目(クラスターの互換性の検証を行う、[検証されるディスクを一覧表示]の項目)で失敗する場合がございます。

▼構成の検証 失敗イメージ

▼検証テストレポートのエラーメッセージ
エラーメッセージ例)
ノードxxxの物理ディスクxxxxxxxxで永続的な予約の削除を確認しているときにエラーが発生しました。

[対象OS]

Windows Server 2008以降でこの事象を確認しております。

[原因]

クラスターは、各ディスクをディスク署名にて識別しております。
クラスターは各クラスターノードが認識しているディスク署名が同一の場合、
共有ディスクとして認識し、クラスター検証の対象として確認いたします。

仮想環境ではディスクを複製して構築されるケースが多くございます。

当該複製したディスクを各クラスターノードのローカルディスクとして利用した場合、
ノード間でディスク署名が一致してしまうため、クラスターは共有ディスクとして
認識してしまいディスクの検証を実施いたします。

▼原因のイメージ図

[解決策]

エラーが発生している対象ローカルディスクの署名を一致しないように変更することで、本事象は解決することが可能です。
手順は次の通りです。

手順1:Nodeのコマンドプロントからdiskpart.exeを起動します。


>diskpart.exe
出力例)Microsoft DiskPart バージョン 10.0.14393.0
Copyright (C) 1999-2013 Microsoft Corporation.
コンピューター:2016NODE1

手順2:List diskで対象のディスクを確認します。


DISKPART>list disk

※対象のディスクの番号は、検証レポートの[ディスクを一覧表示]項目からも確認できます。
    エラーメッセージに表示されたディスク署名より、ディスク番号を参照してください。

▼エラーメッセージ例

▼検証レポート[ディスクを一覧表示] 画面イメージ

手順3:対象のディスクを選択します。


DISKPART>select disk 1 (※ディスク1を選択する場合)
出力例)ディスク1が選択されました。

手順4:現在のディスク署名を確認します。


DISKPART>uniqueid disk
出力例)ディスクID: 2CD80906

手順5:当該ディスクをオフラインにします。


DISKPART>offline disk
出力例)DiskPartは選択されたディスクをオフラインにしました。

手順6:ディスク署名を変更します。


DISKPART> uniqueid disk id=xxxxxxxx
※ディスク署名がほかのディスクのディスク署名と同一にならないよう
    任意の値8桁(MBRディスクの場合)を設定してください。
※GPTディスクの場合も同様の手順で設定の変更が可能です。
    署名の書式はディスクの種類に従ってください。
※ディスク署名として利用可能な文字は0からfまでです。

手順7:当該ディスクをオンラインにします。


DISKPART>online disk
出力例)DiskPartは選択されたディスクをオンラインにしました。

手順8:再度、構成検証テストを行い、すべての項目でテストが合格することを確認します。

いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立てますと幸いです。

OS が起動しなくなる問題 (NoBoot) 発生時の対処方法について –概要

$
0
0

こんにちは、日本マイクロソフトの Windows サポートチームです。

OS のトラブルの中でも、OS が急に起動しなくなった場合は、業務への影響が大きく、多くの場合緊急での対応が必要になるため、弊社へお問い合わせを多くいただく分野となっております。

また、OS が起動しない状態(弊社では 「NoBoot (ノーブート)」 と呼びます)になってしまうと、通常起動時のトラブルシューティングは実行できずとれる手段が限られるため、短時間で適切な対処を行うことが必要になります。

この記事では、NoBoot 事象が発生した場合でも、現状を適切に把握し、復旧手段などを素早くとっていただけるよう、弊社サポートでご支援させていただいている際のポイントをまとめさせていただきました。事象へ対処の参考としてご活用いただけますと幸いです。

1 回目の今回は NoBoot の概要について、2 回目は対処方法についてご紹介させていただきます。

NoBoot とはどんな事象か


PC の電源投入後、Windows OS は、以下の段階を経て起動します。

0. BIOS/UEFI (Windows OS の起動前)
1. Windows Boot Manager (Bootmgr/Bootmgr.efi)
2. Windows operating system loader (Winload.exe/winload.efi)
3. Windows NT OS Kernel (ntoskrnl.exe)

NoBoot は “Windows OS が起動しなくなる問題” ではありますが、どのタイミングで問題が発生したかによって遭遇する状況が違います。問題を正確に把握するためには、どのような画面が表示されているかを確認しておく必要があります。

各起動段階で発生する NoBoot の例としては以下のようなパターンが挙げられます。(ここでは Windows 8 / Windows Server 2012 以降の Windows OS を対象にした画面を紹介しています)

[パターン 1]

画面表示:黒画面に白い文字
起動タイミング:
0. BIOS/UEFI (Windows OS の起動前)
1. Windows Boot Manager (Bootmgr/Bootmgr.efi)

[パターン 2]

画面表示:青い画面に白い文字
起動タイミング:
1. Windows Boot Manager (Bootmgr/Bootmgr.efi)
2. Windows operating system loader (Winload.exe/winload.efi)

[パターン 3]

画面表示:繰り返しロゴ画面が表示される / ロゴ画面表示中に繰り返しストップエラー (青い画面に白い文字) が表示される
起動タイミング:
3. Windows NT OS Kernel (ntoskrnl.exe)

Windows 回復環境 – “オプションの選択” 画面


稀に以下の画面の表示についてご質問をいただきます。この画面は前述の 1~3 とは異なり Windows 回復環境 (Windows RE) と呼ばれるもので、Windows OS が起動しない場合の一般的な原因を修正するためのミニ OS 環境になります。

次の問題が検出された場合は、自動的に Windows RE が起動します。

  • Windows の起動が 2 回続けて失敗した場合。
  • 起動の完了後 2 分以内に予期しないシャットダウンが 2 回続けて発生した場合。
  • セキュア ブート エラー (Bootmgr.efi に関連する問題を除く) が発生した場合。
  • タッチ操作のみのデバイスで BitLocker でエラーが発生した場合。

Windows 回復環境の詳細につきましては以下のサイトをご参考ください。

Windows 回復環境 (Windows RE)
https://msdn.microsoft.com/ja-jp/library/windows/hardware/dn938364(v=vs.85).aspx

なぜ NoBoot が発生しているのか – Windows OS が起動しない原因


OS が起動しなくなる直接の理由は様々です。本質的な問題としては以下のような例が挙げられます。

  • ハードウェア故障 (例:CPU 等が正常に動作しない、ディスクが認識できない、)
  • ドライバ ファイル 破損 (例:ドライバが破損し、ディスクから OS のデータが読み込めない)
  • レジストリ 破損 (例:レジストリが破損し Windows OS の稼働に必要なプロセスが起動できない)

一般的には後述いたします各種回避策を実施いただき、状況から原因を推測します。
パターン 3 の様にストップ エラーが発生している場合、その際に保存されるメモリ ダンプ ファイルを解析することで、ストップ エラーが発生した原因・対処策が判明する場合があります。なお、上記スクリーンショットにある INACCESSIBLE_BOOT_DEVICE (0x7B) の場合は例外でメモリ ダンプ ファイルが出力されないため各種回避策の実施が必要となります。

Bug Check 0x7B: INACCESSIBLE_BOOT_DEVICE
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x7b–inaccessible-boot-device

なぜ NoBoot が発生するようになったのか – Windows OS が起動しなくなった原因


非常に残念ながら、Windows OS が起動しなくなった原因は通常特定できません。災害の様に突然起こってしまう本問題については、既に問題が発生してしまった後の環境からは原因を特定する術がありません。

例えばディスクの故障などで事前にイベント ログに情報が残っている場合は分かる場合もありますが、ファイル・レジストリ破損などはログが残らず、特定する術がないためです。

NoBoot から復旧させるためには


最も確実な方法はバックアップから復旧させる方法です。そのため、定期的なバックアップの (Hyper-V 環境の場合はチェックポイント) 計画をご検討ください。とはいえ、突然の NoBoot に対して事前に準備ができている場合も多くはありません。バックアップから復旧できない場合は、問題の発生状況に対して以下のような対処方法が考えられます。

[1] スタートアップ修復
[2] Boot 構成情報の修正
[3] SFC (System File Checker)
[4] regback を用いたレジストリ復旧
[5] 更新プログラムのアンインストール

他にも正常に起動するかどうかの切り分けとして以下の方法も有効です。

[A] セーフモード
[B] ドライバ署名の強制を無効

ただし、これらの対処方法を実施しても必ず Windows OS が起動できるようになる保証はありません。また、企業様の社内にて運用されているサーバー機といった環境にてファイル破損により NoBoot が発生している場合、無事に復旧した後に破損の影響範囲を把握することは非常に困難です。そのような観点からもバックアップから復旧させることが NoBoot の復旧方法として最も理想的と言えます。

次回の公開では上記の対処方法についてご紹介していきます。

OS が起動しなくなる問題 (NoBoot) 発生時の対処方法について – 対処方法
https://blogs.technet.microsoft.com/askcorejp/2018/08/24/os-が起動しなくなる問題-noboot-発生時の対処方法につ-2/

 

本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。


OS が起動しなくなる問題 (NoBoot) 発生時の対処方法について –対処方法

$
0
0

こんにちは、日本マイクロソフトの Windows サポートチームです。

前回に続いて今回は NoBoot の対処方法について紹介させていただきます。なお、前回も記載させていただいておりますが対処方法を実施しても必ず Windows OS が起動できるようになる保証はないことをご注意下さい。

OS が起動しなくなる問題 (NoBoot) 発生時の対処方法について – 概要
https://blogs.technet.microsoft.com/askcorejp/2018/08/24/os-が起動しなくなる問題-noboot-発生時の対処方法につ/

実際に NoBoot が発生してしまった場合、いつも使用している Windows OS は起動できないため Windows 回復環境から操作を行い各種の対処策を実施します。

対処策はコマンド プロンプトよりコマンドにて実行するため、事前に Windows 回復環境からコマンド プロンプトを起動しておく必要があります。万が一 Windows 回復環境が起動していない場合は、インストール メディアから起動します。お手元にインストール メディアが無い場合は、以下のサイトを参考にインストールメディアの準備をお願いいたします。

Windows 10 のダウンロード
https://www.microsoft.com/ja-jp/software-download/windows10

コマンド プロンプト起動手順


— Windows 回復環境の場合 ——————–
1. 現象が発生した後、回復画面が表示されます。
2. [オプションの選択] で [トラブルシューティング] を選択します。
3. トラブルシューティングの画面で [詳細オプション] を選択します。
4. 詳細オプション画面で [コマンド プロンプト] を選択します。
5. [コマンド プロンプト] で管理者のアカウントを選択します。
6. 管理者のパスワードを入力します。
7. コマンドプロンプト(cmd.exe)が表示されます。

— インストール メディアの場合 ——————–
1. Windows 8 / Windows Server 2012 以降の OS メディアから起動します。
2. [Windows セットアップ] の画面で言語関連の設定を指定し、[次へ] をクリックします。
3. ウィンドウ内左下に表示される [コンピューターを修復する] をクリックします。
4. [オプションの選択] で [トラブルシューティング] をクリックします。
5. [詳細オプション] で [コマンド プロンプト] をクリックします。

また、コマンドでは Windows フォルダーが存在するドライブを指定する場合があるため、以下の手順にて Windows フォルダーが存在するドライブを特定しておく必要があります。

Windows フォルダーが存在するドライブの確認手順


1. 起動したコマンド プロンプト上で notepad コマンドを実行し、メモ帳を起動します。
2. メモ帳で [ファイル] – [開く…] を実行します。
3. [開く] ダイアログで左側の [コンピューター] をクリックし、ドライブ一覧を表示させます。
4. X: 以外の各ドライブの内容を確認し、Windows フォルダーが存在するドライブを確認します。

  • 多くの場合は C もしくは D ドライブに Windows フォルダーが確認できると思います。下図では D:ドライブに Windows フォルダーが存在していることが確認できます。
  • 万が一、Windows フォルダーが存在するドライブを確認できない場合は、ディスクが認識できない・読み取ることができない可能性が考えられます。ハードウェア障害もしくか暗号化ソフトウェアに起因する可能性も考えられるため、PC の製造元様へご確認下さい。


これで対処策を実行するための環境が整いました。この後は以下のいずれかもしくは複数の対処策を実施し、復旧確認を行います。

[1] スタートアップ修復
[2] Boot 構成情報の修正
[3] SFC (System File Checker)
[4] regback を用いたレジストリ復旧
[5] 更新プログラムのアンインストール

どの対処方法を実施するかは実際の表示内容やエラー情報を参考に行うため一概には言えませんが、一般的にご確認いただく流れとして前回ご紹介しました NoBoot 画面を参考に言うと、大まかに以下のような流れで実施します。

  • 全パターン共通
    [1] スタートアップ修復
    [5] 更新プログラムのアンインストール ※ 更新プログラムのインストール直後に NoBoot になった場合
     
  • パターン 1 の画面が表示される
    [2] Boot 構成情報の修正  ※ Bootmgr / Operating System が見つからない趣旨のメッセージが表示される場合
    ※ ハードウェア故障と思われるメッセージが表示される場合は PC の製造元様までお問合せ下さい
     
  • パターン 2 の画面が表示される
    [2] Boot 構成情報の修正 ※ Boot 構成情報 (BCD : Boot Configuration Data) に問題がある趣旨のメッセージが表示される場合
    [3] SFC (System File Checker)
    [4] regback を用いたレジストリ復旧
      
  • パターン 3 の画面が表示される
    [3] SFC (System File Checker)
    [4] regback を用いたレジストリ復旧 

[1] スタートアップ修復


[概要]
システム ファイルの欠落や損傷など、Windows の正常な起動を妨げる可能性のある特定の問題を修復します。

[手順]

  1. コマンド プロンプトより以下のコマンドを実行します。コマンド実行後は、”PC を診断中” と表示されます。
    X:\Sources\Recovery\StartRep.exe
    < 補足 >
    [オプションの選択] 画面から [トラブル シューティング] -> [詳細オプション] -> [スタートアップ修復] でも実行可能です。
  2. スタートアップ修復完了後、[シャットダウン] を選択してコンピューターの電源を切り、再度電源を入れ、Windows OS が起動することを確認します。

スタートアップ修復のログは以下に記録され、修復状況を確認することが可能です。
%WINDIR%\System32\LogFiles\Srt\SrtTrail.txt

[2] Boot 構成情報の修正


[概要]
MBR (master boot record) やブートセクター、Boot 構成情報 (BCD:Boot Configuration Data) の破損を検知し修復します。

[手順]

  1. コマンド プロンプトより以下のコマンドを実行します。
    Bootrec /RebuildBcd
  2. コマンド完了後、コマンド プロンプトを終了し、[続行] を選択します。Windows OS が起動することを確認します。

参考情報:
“Bootmgr is missing Press Ctrl+Alt+Del to restart” error when you start Windows
https://support.microsoft.com/en-us/help/2622803/bootmgr-is-missing-press-ctrl-alt-del-to-restart-error-when-you-start

Use Bootrec.exe in the Windows RE to troubleshoot startup issues
https://support.microsoft.com/en-us/help/927392/use-bootrec-exe-in-the-windows-re-to-troubleshoot-startup-issues

[3] SFC (System File Checker)


SFC は System File の整合性をスキャンし、破損が見つかった場合は %WinDir%\WinSxS フォルダー配下の情報をコピーして修復します。

[手順]
※ Windows フォルダーが存在するドライブを D: とします。

  1. コマンド プロンプトより以下のコマンドを実行します。
    set windows_tracing_logfile=D:\sfc.log
    sfc /scannow /offbootdir=D:\ /offwindir=D:\Windows
  2. コマンド完了後、コマンド プロンプトを終了し、[続行] を選択します。Windows OS が起動することを確認します。

SFC のログは以下に記録され、修復状況を確認することが可能です。
< Windows フォルダーが存在するドライブ>:\sfc.log

参考情報:
Use the System File Checker tool to repair missing or corrupted system files
https://support.microsoft.com/en-us/help/929833/use-the-system-file-checker-tool-to-repair-missing-or-corrupted-system

[4] regback を用いたレジストリ復旧


[概要]
Windows OS では 10 日おきにレジストリ情報 (レジストリ ハイブ) を以下のフォルダーにバックアップします。
このため、正常に OS が起動していたレジストリのバックアップデータにて現在のレジストリ情報を上書きいただくことで、OS が起動できる可能性があります。
%SystemRoot%\System32\config\RegBack

[注意事項]
SYSTEM、Software レジストリ ハイブ全体を置き換えることになるため、レジストリ のバックアップが採取された以降に変更された情報(各種インストール情報や設定変更など)は破棄されます。

[手順]
※ Windows 回復環境起動時、Windows フォルダーが存在するドライブを D: とします。

  1. コマンド プロンプトより以下のコマンドを実行し、現在のレジストリハイブのコピーを作ります。
    copy d:\Windows\System32\config\SYSTEM d:\Windows\System32\config\system.bak
    copy d:\Windows\System32\config\SOFTWARE d:\Windows\System32\config\software.bak
  2. コマンド プロンプトより以下のコマンドを実行し、レジストリ ハイブを Regback フォルダーから復元します。
    copy d:\Windows\System32\config\RegBack\SYSTEM d:\Windows\System32\config
    copy d:\Windows\System32\config\RegBack\SOFTWARE d:\Windows\System32\config
  3. コマンド完了後、コマンド プロンプトを終了し、[続行] を選択します。Windows OS が起動することを確認します。

[5] 更新プログラムのアンインストール


[概要]
何らかの理由により更新プログラムが期待通りインストールされていない場合、直近でインストールした更新プログラムをアンインストールすることで復旧できる場合があります。

[手順]
※ Windows 回復環境起動時、Windows フォルダーが存在するドライブを D: とします。

  1. コマンド プロンプトより以下のコマンドを実行し、更新プログラムのパッケージの一覧を表示します。
    dism /image:D:\ /get-packages
  2. 各パッケージ情報が以下の書式で表示されます。パッケージ ID の KBxxxxxxx の部分で、直近にインストールした更新プログラムを特定します。またインストール時刻も参考にすることが可能です。
    – [表示例] ————-
    パッケージ ID : Package_for_KB4343669~31bf3856ad364e35~amd64~~17134.165.1.1
    状態 : インストール済み
    リリースの種類 : Update
    インストール時刻 : 2018/07/12 22:23
    ————————
  3. 以下のコマンドを実行してパッケージを削除します。2 で確認したパッケージ ID 情報を PackageName オプションの引数として渡します。例えば、下記では KB4343669 をアン インストールしています。
    dism /image:D:\ /remove-package /PackageName:Package_for_KB4343669~31bf3856ad364e35~amd64~~17134.165.1.1
    < 補足 >
    更新プログラム適用中に問題が発生していた場合、パッケージ情報の “状態” が “インストールの保留中” と表示される場合があります。この場合は以下のコマンドを実行してロールバックすることで保留状態を解除します。
    Dism /Image:D:\ /Cleanup-Image /RevertPendingActions
  4. コマンド完了後、コマンド プロンプトを終了し、[続行] を選択します。Windows OS が起動することを確認します。

参考情報:
DISM オペレーティング システム パッケージ (.cab または .msu) サービスのコマンド ライン オプション
https://msdn.microsoft.com/ja-jp/library/windows/hardware/dn898551(v=vs.85).aspx

 


上記対処策を実施しても復旧しない場合は、Windows OS の起動に必要なドライバ ファイルの破損の可能性があります。切り分けとして [スタートアップ設定] 画面から以下の両方をお試しいただき、Windows OS が起動できるかをご確認下さい。
なお、Windows OS 標準の設定から設定変更されている環境では [スタートアップ設定] 画面を表示できない場合があります。

[A] セーフモード
[B] ドライバ署名の強制を無効

スタートアップ設定


1. [オプションの選択] で [トラブルシューティング] を選択します。
2. [トラブルシューティング] の画面で [詳細オプション] を選択します。
3. [詳細オプション] の画面で [スタートアップ 設定] を選択します。
4. [再起動] ボタンをクリックします
5. [スタートアップ設定] 画面から、任意のボタンをクリックします。

ボタンと項目の対応はお使いの環境によって異なる場合があります。例えば、以下の画面が表示された場合は下記ボタンを押下します。
F4 キー:セーフモード起動
F7 キー:ドライバ署名の強制を無効して起動

参考情報:
Windows のスタートアップ設定 (セーフ モードなど)
https://support.microsoft.com/ja-jp/help/17076/windows-8-startup-settings-safe-mode

[A] セーフ モード

ドライバーとサービスの最小のセットで Windows をセーフ モードで起動して、問題をトラブルシューティングすることができます。
PC をセーフ モードで起動して問題が再現しなければ、既定の設定および基本的なデバイス ドライバーとサービスを、可能性のある原因から除外できます。

直近でインストールしたソフトウェアがある場合は、そのソフトウェアをアンインストールします。

[B] ドライバー署名の強制を無効にする

不適切な署名が含まれているドライバーのインストールを許可します。NoBoot 時の切り分けとして本設定の無効化により起動できる場合は、ドライバの署名情報が正しく取得できていない可能性が高く、その多くの場合はカタログ ファイルの破損によって引き起こされます。
Windows OS 起動時に各ドライバから参照されるカタログ ファイルは以下の場所に保存されています。そのため、同様の構成の環境がある場合は正常な PC から上記フォルダをコピーいただくことで復旧できる可能性もあります。
<Windows フォルダーが存在するドライブ>:\Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}

 


これまでの対応策でも復旧できない場合は、時間をかけて更に詳細な調査が必要となります。

なお、優先事項がデータの抽出であれば、(ディスクにアクセスできる場合は) コマンド プロンプトからコピー関連のコマンドをお使いいただくことで、データを異なるストレージ領域にコピーが可能です。

参考情報:
copy
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/copy

xcopy
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/xcopy

また、PC のリフレッシュ機能をご利用いただくことでもユーザー データをある程度残したまま Windows OS を復旧させることも可能です。更新プログラムや各種ソフトウェアの再インストールは必要となる場合がありますが、Windows OS をクリーン インストールするよりは少ないコストで Windows OS の再インストールが実現可能です。

  • 万が一に備え、重要なデータについては必ずバックアップをご採取ください。
  • 各 PC 製造元様のアプリケーションの保持状況などは PC 製造元様までご確認下さい。
  • 企業様によっては専用の Windows OS イメージをご利用いただいている場合もございますため、IT 管理者様にご確認下さい。
  • 実行手順や保持されるデータなど、詳細につきましては下記サイトをご参考下さい。
    PC のリカバリー機能のしくみ
    https://msdn.microsoft.com/ja-jp/library/windows/hardware/mt210509(v=vs.85).aspx

ストレージがネットワーク上に配置されることが多くなった今日、ローカルで必要としているデータは意外と少ない場合もあります。また現在の Windows Update は累積更新のパッケージがあるため更新プログラムの適用もスムーズではないかと思います。現在お使いの環境が復旧できるのが理想ではありますが、復旧が困難な場合は環境を再構築した方が結果的に少ないコストで状況を復旧できる場合もありますため場合によっては有効な対処方法にもなり得ます。

以上、2 回に渡り NoBoot の概要および対処方法についてご紹介させていただきましたが、いかがでしたでしょうか。本ブログが少しでも皆様のお役に立てますと幸いです。

 

本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。

Workgroup Clusterの構築手順

$
0
0

いつも弊社製品をご利用いただきまして誠にありがとうございます。
Windows プラットフォーム サポートの岩井です。
今回はWorkgroup Clusterの構築手順をご案内させていただきます。

[はじめに] Workgroup Clusterとは

Windows Server 2012 R2以前のフェールオーバー クラスターは、すべてのクラスターノードが
同じActive Directory ドメインに参加するメンバーである必要がありました。
Windows Server 2016では、新たに Active Directoryドメインに参加しないワークグループ構成の
フェールオーバークラスターをサポートしております。
このActive Directoryドメインのメンバーとして構成していない、ワークグループ構成のノード間で
構成されたクラスターをWorkgroup Clusterと呼びます。

今回は、このWorkgroup Clusterの構築方法および留意事項についてご説明します。

[事前準備していただく必須要件]

✓すべてのサーバーがWindows Server2016であること
✓すべてのサーバーにフェールオーバークラスター機能がインストールされていること
✓クラスターを構成する全ノードにローカルユーザーアカウントを作成しておくこと
✓各ノードのアカウントのユーザー名とパスワードはすべて同一であること
✓各ノードのアカウントはローカル管理者のメンバーであること

[構築手順]

【ステップ1】 アカウントの作成
1-1.  Windows Server2016をインストールした複数台のサーバー(ノード)を用意します。

1-2.  各ノードにローカルユーザーアカウントを作成します。
   ユーザ名とパスワードはすべてのノードで同一のものとし、アカウントはローカル管理者のメンバーに設定してください。

1-3.  各ノードのコンピュータ名を設定します。サーバーのワークグループ構成は、既定のWorkgroupのままにしておきます。

1-4.  プライマリDNSサフィックスを、各ノードで同一になるように設定します。

【ステップ2】DNSの登録
2-1.  ノード間およびクライアントから名前解決ができるように、
   DNSサーバーにノードのA(アドレス)レコードを登録します。
   また、クラスター名とクラスターIPのAレコードも登録しておきます。

【ステップ3】クラスターの作成
3-1.  各ノードにフェールオーバークラスター機能をインストール後、
   フェールオーバークラスターマネージャーより構成の検証を行い、すべてのカテゴリで検証が成功することを確認します。
   ※[Active Directory構成の検証]項目では警告が出ますが、Workgroup Clusterの構成上、問題ありません。

3-2.  フェールオーバークラスターマネージャーより、クラスターの作成を行います。
   構成するノードを選択し、DNSに登録したクラスター名とクラスターIPを入力します。
   ※確認画面で、[クラスター登録]項目が『DNSのみ』となっていることを確認してください。

3-3.  クラスターを作成し、作成レポートを確認します。
   ※[クラスター登録]項目が『DNSのみ』になっています。

[留意事項]

Workgroup Clusterをご利用いただく際の留意事項について2点ご説明します。

【留意事項1】サポートしている機能
Workgroup Clusterには一部機能の制約がございます。
以下の表に、サポートの有無と備考を示します。

【留意事項2】Workgroup Cluster構築後のドメイン参加
Workgroup Cluster構築後に、ドメイン参加をしてクラスターを再構築したいというお問い合わせがあります。
しかし、Workgroup 構成はWorkgroup用のクラスターとなりますので、ADモードのクラスターの動作は保証されておりません。
したがって、AD環境のクラスター構築をされたい場合は、AD環境の下で最初から構築を行っていただく必要があります。

AD環境のクラスターか否かは、以下の方法で確認可能です。

PowerShell起動後、以下のコマンドを実施し、AdmnistrativeAccessPoint項目の出力を確認してください。
> get-cluster | fl *

▼AD環境のクラスターの場合

出力)AdmnistrativeAccessPoint : ActiveDirectoryAndDns

▼Workgroup Clusterの場合

出力)AdmnistrativeAccessPoint : Dns

出力が『ActiveDirectoryAndDns』の場合は、クラスターは AD 環境のクラスターであり、
出力が『Dns』の場合は、クラスターはWorkgroup Clusterであることが確認できます。

※参考情報
本クラスターはSQLで利用される場合が多くございます。
その際の注意事項など、詳細については以下のリンクをご参照ください。
“ドメインに依存しない可用性グループ”
https://docs.microsoft.com/ja-jp/sql/database-engine/availability-groups/windows/domain-independent-availability-groups?view=sql-server-2017

いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立てますと幸いです。

Windows Server 2016 環境にて共有フォルダーのサブフォルダーを削除、または移動すると、その上位フォルダーのアクセス権が一部削除されてしまう事象について

$
0
0

こんにちは。Windows サポートの丸山です。

今回は、Windows Server 2016 環境にて共有フォルダーのサブフォルダーを削除、または移動すると、その上位フォルダーのアクセス権が一部削除されてしまう事象について、ご紹介させていただきます。

■ 発生する事象について

Windows Server 2016 環境にて共有フォルダーのサブフォルダーを削除、または移動すると、その上位フォルダーのアクセス権が一部削除されることがあります。
例えば、以下のように、共有フォルダーとなる C:\SHARE 配下の SUB フォルダーを削除しますと、上位フォルダーのアクセス権の一部が削除されることがあります。

現在のところ、削除されるアクセス権には、以下のような特徴があることがわかっています。

(1) 共有されているローカル フォルダーの配下である
(2) 上位のフォルダーに継承が “なし” のアクセス権が付与されている
(3) 当該アクセス権には、既定の “読み取りと実行”、または “変更” 権限のみが付与されている
(4) 当該アクセス権は、上位のフォルダーから見た子のファイル、フォルダーには付与されていない
(5) エクスプローラーを用いて、フォルダーの削除、または移動を行っている

また、本事象は Windows Server 2016 環境のほか、バージョン 1511 以降の Windows 10 でも発生することが確認されております。
Windows 8.1 以前のクライアント OS や、Windows Server 2012 R2 以前のサーバー OS では発生しません。

■ 確認されている抑止策について

本事象を回避いただくには、共有フォルダーを操作するときにローカル フォルダーとしてアクセスせず、ネットワーク共有フォルダーとしてアクセスすることで抑止可能でございます。

前述の条件に合致するようなアクセス権が運用されております場合には、ご不便をおかけしますが、回避策による運用を検討ください。
また、本事象につきましては、弊社製品開発部門と連絡を取り、根本的な問題解決に向けた検討を進めております。
状況に進展がありましたら、本 BLOG の更新にてご報告させていただきます。


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

最も古い共有フォルダーのシャドウコピーが削除されてしまう事象について

$
0
0

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

今回は、共有フォルダーのシャドウ コピーが世代数の上限値まで保存されている状態で、Windows Server バックアップや読み取り chkdsk など、シャドウ コピーの自動作成を行うアプリケーションを実行すると、最も古い共有フォルダーのシャドウ コピーが削除されてしまう事象について、ご紹介いたします。

この事象は、次期の Windows OS より修正が行われるため、現在お使いの OS ではシャドウ コピーを取得する世代の上限値を 1 つ多く設定する対策が必要となります。
 

対象 OS

  • Windows Server 2008 / 2008 R2
  • Windows Server 2012 / 2012 R2
  • Windows Server 2016

 

目次

 

シャドウ コピーとは

シャドウ コピーとは、ボリュームの静止点 (特定の時点) の複製であり、専用の記憶領域 (以下、シャドウ コピーの記憶域)に格納されています。
 

シャドウ コピーの種類

シャドウ コピーには、用途に応じて、下記の種類が存在します。
 

種類 説明
ClientAccessible ・ vssadmin create shadow コマンドでシャドウコピーを作成した場合
・ 共有フォルダーのシャドウ コピー機能の利用でシャドウコピーを作成した場合
DataVolumeRollback Windows Server バックアップ実行時など、アプリケーションの要求によって自動作成
された場合 (バックアップ データの世代管理などのために利用される)
ApplicationRollback Windows Server バックアップ実行時に、バックアップ作成元の整合性チェックのために
自動作成された場合
FileShareRollback Chkdsk コマンド使用時 (ボリュームの整合性チェックのために一時的に利用される)
ClientAccessibleWriters 復元ポイント作成時

 

ClientAccessible 属性は、共有フォルダーのシャドウ コピー機能を用いてシャドウ コピーを作成するため、共有フォルダーのシャドウ コピーと呼ぶ場合があります。共有フォルダーのシャドウ コピーを利用すると、ファイルを編集前の状態に戻したい場合や誤って削除してしまった場合に、過去にシャドウコピーを取得した時点のボリュームの状態に復元することができます。

DataVolumeRollback 属性は、Windows Server バックアップ実行時に、バックアップ データの世代管理のために、バックアップ先に自動で作成されるシャドウ コピーです。常に最新のバックアップ データが上書き保存されていくため、それ以前のバージョンはシャドウ コピーによって管理されています。

ApplicationRollback 属性 と FileShareRollback 属性 は、Windows Server バックアップ実行時、読み取り chkdsk 実行時に、ボリュームに変更があると整合性が合わなくなるため、一時的に作成したシャドウ コピーを利用します。
これは、一時的に作成・使用されるものであり、それぞれの実行後に使うことはないため自動で削除されます。

ClientAccessibleWriters 属性は、コンピューターの復元を利用して復元ポイント作成した際に、作成されるシャドウ コピーです。

本ブログでは、共有フォルダーのシャドウ コピー (ClientAccessible 属性) と、アプリケーションによるシャドウ コピー (DataVolumeRollback 属性 / ApplicationRollback 属性 / FileShareRollback 属性) が登場します。
 

シャドウ コピー作成 / 世代管理 の仕組み

シャドウ コピーの記憶域には、直前の状態との差分を記録している「Diff Area」と、それ以前の世代の差分を記録している「シャドウ コピー (差分データ)」が保存されています。

想定された動作では、ファイルの更新や削除などボリュームに変更が生じた場合、変更前のデータをシャドウコピーの記憶域の中の Diff Area に退避し、実際のボリュームに変更部分を反映させています。シャドウ コピーの作成を行うと、この Diff Area に退避されていたデータがいわゆる “差分データ” として保存されます。
その後、再びボリュームに変更が生じた際には、新しい Diff Area が作成され、変更前のデータを退避し、シャドウ コピーの作成を行うと、差分データとして保存されます。

このように、シャドウ コピーは差分を1世代ごとに管理しているため、特定のタイミングのボリュームの状態に復元を行う場合、復元したいタイミングのシャドウコピーに至る前のすべてのシャドウ コピーが必要になります。
 

詳しい情報:
===========================================================================
[タイトル] ボリューム シャドウ コピー サービス (VSS) について
[URL] https://blogs.technet.microsoft.com/askcorejp/2018/08/15/aboutvss/
[内容] シャドウ コピーを作成するサービスである、ボリューム シャドウコピー サービス
   (VSS) についてご紹介しているブログになります。
===========================================================================
 

シャドウ コピーの設定

シャドウ コピーには、保存できる世代数や記憶域に上限値を設定できます。

シャドウ コピーの記憶域の上限値とは、シャドウ コピー を保管するための領域全体のサイズのことです。

保存できる世代数の設定は共有フォルダーのシャドウ コピーのみに制限がかかり、記憶域の設定は共有フォルダーのシャドウ コピーとアプリケーションによるシャドウ コピーの両者に制限がかかります。

上限に達した状態でシャドウ コピーを作成した場合は、シャドウコピーの種類を問わずに最も古い世代から自動で削除される動作となっています。
 

シャドウコピーの世代数の設定レジストリは、以下のコマンドから確認することができます。
===========================================================================
[コマンド] reg query “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Settings”
[確認箇所] MaxShadowCopies REG_DWORD 0x
※ MaxShadowCopies の値がない場合は、標準の 64 世代が上限となります。
===========================================================================
 

シャドウ コピーの記憶域の最大領域の確認方法は、以下のコマンドから確認することができます。
===========================================================================
[コマンド] vssadmin list shadowstorage
[確認箇所] シャドウ コピーの記憶域の最大領域
※ 標準は、下記のとおりです。
  共有フォルダーのシャドウ コピーの場合: 当該ボリュームのディスクサイズの 10 %
  Windows Server バックアップの場合: 当該ボリュームのディスクサイズの 30 %
  Windows Server バックアップ専用ディスクの場合: 制限なし (UNBOUNDED)
===========================================================================
 

事象について

事象解説

世代数上限値まで共有フォルダーのシャドウ コピーが保存されている状態でシャドウ コピーの自動作成を行うアプリケーションを実行すると、最も古い共有フォルダーのシャドウ コピーが削除されるという問題が発生しています。

本ブログでは、読み取り chkdsk の実行を例として、順を追ってボリュームの状態を説明します。
 

◆ 補足:読み取り chkdsk とは

本事象は、 MaxShadowCopies の動作と chkdsk コマンドが作成するシャドウ コピーが関係して発生しています。
chkdsk コマンドは、ファイルシステムのエラーをチェックし、表示・修復するためのプログラムです。
オプションを指定せずに実行すると、一切の修復作業を行いません。

上述の通り、chkdsk コマンドを実行すると、chkdsk 中にボリュームに変更が生じた場合の整合性を保つために、一時的なシャドウ コピー(FileShareRollback 属性) を作成します。これは、一時的に作成・使用されるものであり、chkdsk 終了後に使うことはないため自動で削除されます。
 

コマンド:
chkdsk

実行例:Dドライブに対して読み取り chkdsk を実行
> chkdsk d:
 

詳しい情報:
===========================================================================
[タイトル] chkdsk
[URL] https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/chkdsk
[内容] Windows のコマンドのうち、chkdsk コマンドの仕様について書かれたページになります。
===========================================================================
 

◆ 想定された動作について

以下の図は、共有フォルダーのシャドウ コピーが世代上限まで作成されたボリュームの状態を示しています。
青線の四角はシャドウ コピーの記憶域を示しており、今回は MaxShadowCopies を 5 世代に設定している想定です。
緑の四角は各世代の共有フォルダーのシャドウ コピーを示しており、黄色の四角はデータの差分を示しています。
最新の共有フォルダーのシャドウ コピーを作成した後、データには変更が生じていないことを想定しているため、データの変更を退避するための Diff Area は空の状態となっています。

共有フォルダーのシャドウ コピーが世代上限まで作成されたボリュームの状態

Windows の想定された動作として、世代数上限値 (上の図では 5 つ )まで共有フォルダーのシャドウ コピーがすでに保存されている状態で、新しく共有フォルダーのシャドウ コピーを作成すると、最新のシャドウ コピーを保存するために、最も古いシャドウ コピーがシステムによって自動的に削除されます。
 

以下の図は、実際の GUI 上の表示と、ボリュームの状態を図示しています。

最も古いシャドウ コピーが自動削除される過程のボリュームの状態
 

◆ 想定していない動作について

本来であれば、chkdsk を行う際に作成されるシャドウ コピーはアプリケーションによるシャドウ コピーであるため、MaxShadowCopies による削除は発生しません。
しかし、今回はこの動作にバグがあり、MaxShadowCopies が、新しく追加されるシャドウ コピーの属性を見ないままに、次のシャドウ コピーが入るように、最も古い共有フォルダーのシャドウ コピーを削除するという現象が発生しています。

想定外の動作時のボリュームの状態

しかし、実際は、アプリケーションによるシャドウ コピーが追加されており、共有フォルダーのシャドウ コピーが追加されることはありません。そのため、結果として、最も古い共有フォルダーのシャドウ コピーが想定外に削除されています。
なお、これは MaxShadowCopies の動作のため、保存されている共有フォルダーのシャドウ コピーが世代上限に達している状況でなければ発生することはありません。
 

事象の回避策

本事象では、最も古い共有フォルダーのシャドウ コピーが削除されてしまうことが、システムへの影響となります。お客様の運用で保存しておく共有フォルダーのシャドウ コピーの世代数を決めている場合は、上記の動作により、想定よりも世代が一つ少なく管理されている可能性があります。

上述の通り、本事象は 次期の Windows OS より修正が行われるため、現在お使いの OS での回避策としては、シャドウ コピーを取得する世代の上限値を 1 世代多く設定する必要があります。
 

[参考] 事象発生の検証

  1. 共有フォルダーのシャドウ コピーの世代数の上限を設定する
    1. [スタート] – [ファイル名を指定して実行] をクリック、regedit と入力し、[OK] をクリックする 
      画面キャプチャ:プログラムを指定して実行
    2. 以下のレジストリ キーを開 
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Settings
    3. メニュー バーより、[編集] – [新規] を選択し、[DWORD 値] をクリックする
    4. MaxShadowCopies と入力し、Enter キーを押す
    5. MaxShadowCopies を選択した状態で、メニュー バーより、[編集] – [修正] をクリックする
    6. 設定する世代数を入力し、[OK] をクリックする 
      レジストリー キー設定
  2. 設定した世代数の上限まで共有フォルダーのシャドウ コピーを作成する
    1. エクスプローラーを開き、左メニューの [PC] – [<当該ドライブ>] を選択し、右クリックで [シャドウ コピーの構成(W)] を開く
    2. 新しく開いたシャドウ コピーのウィンドウにて、[<当該ドライブ>] を選択し、[有効 (E)] ボタンをクリックする
    3. [今すぐ作成ボタン] から 手順 (1) で設定した世代数の上限まで共有フォルダーのシャドウ コピーを作成する
    4. エクスプローラーを開き、左メニューの [PC] – [<当該ドライブ>] を選択し、右クリックで [プロパティ] を開く
    5. 新しく開いたプロパティのウィンドウのタブから [以前のバージョン] をクリックする 
      画面キャプチャ:以前のバージョン 
      ※ OS のバージョンによって [シャドウ コピー] タブがある場合とない場合がございます。
    6. (2-6) 手順 (1) で設定した世代数と同じ数の共有フォルダーのシャドウ コピーが作成されていることを確認する
  3. chkdsk コマンドを実行する
    1. コマンドプロンプトを管理者権限で開く
    2. 以下のコマンドを実行する 
      > chkdsk  
      実行例: > chkdsk f: 
      画面キャプチャ:chkdsk入力
    3. chkdsk の実行が終了後、当該ボリュームのプロパティを開きなおし、[以前のバージョン] タブをクリックし、共有フォルダーのシャドウ コピーの数を確認する 
      画面キャプチャ:chkdsk実行後 
      chkdsk コマンド実行前から、最も古い共有フォルダーのシャドウ コピーが 1 世代減った場合は、事象の発生が確認されました。

 

いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立てば幸いです。

%Systemroot%\System32\LogFiles\Sum フォルダ内に作成される文字化けしたファイルについて

$
0
0

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

今回は、%Systemroot%\System32\LogFiles\Sum フォルダ内に作成される文字化けしたファイルについて、ご紹介させていただきます。

■ 発生する事象について

Windows Server 2016 環境において、%Systemroot%\System32\LogFiles\Sum フォルダ内に文字化けしたファイルが作成されることがあります。

文字化けしたファイルが作成されている例:

■ 対処策について

前述のような、文字化けしたファイルが作成された場合、そのまま放置していただいてもシステムの動作に影響はございませんが、不要なファイルでございますので、文字化けしたファイルは削除していただいても問題ございません。

■ 根本的な対処に向けて

現在弊社では、将来バージョンの Windows Server 製品で本問題が解決されますよう、調査が行われております。
状況に進展がありましたら、本 BLOG を更新する予定です。


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

Windows 10 Version 1703 以降で発生する印刷時の現象について

$
0
0

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

今回は、Windows 10 Version 1703 以降で発生する印刷時の現象について、ご紹介いたします。
端末の入れ替えなどでこれから Windows 10 を導入される方や、同じような現象でお悩みの方は、ご参照いただけますと幸いです。

[現象例]
C++ MFC で作成したプログラムで、Windows 10 のアップデート後に、固定ピッチフォントを使用しているのにも関わらず、特定のフォントサイズで半角文字と全角文字で印刷位置がずれる現象が発生する。
Windows 10 Version 1511 では現象が発生しなかったが、Version 1703 以降では現象が発生する。

[デザインの変更点と回避策]
Windows 10 Version 1703 以降では、固定ピッチフォントを保持するレジストリ情報の “Jpn98FixPitch” キーがサポートされておらず、使用できなくなりました。
しかしながら、多数のお客様よりご要望をいただき、下記以降の更新プログラムを適用いただくことで、再度 “Jpn98FixPitch” キーの設定が有効となります。

そのため、まずはご利用の端末において、以下の更新プログラムが適用されているかをご確認くださいますようお願い申し上げます。

<適用していただく更新プログラム>
Title : 2017 年 12 月 13 日 KB4054517 (OS ビルド 16299.125)
適用対象: Windows 10 Version 1709
URL : https://support.microsoft.com/ja-jp/help/4054517/windows-10-update-kb4054517

Title : 2018 年 1 月 18 日 KB4057144 (OS ビルド 15063.877)
適用対象: Windows 10 Version 1703
URL : https://support.microsoft.com/ja-jp/help/4057144/windows-10-update-kb4057144

Windows Platform 担当 : 栗山

Windows 10 April 2018 Update で縦書きのフォントを使用すると一部の記号が正しく表示されない

$
0
0

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

Windows 10 April 2018 Update (Version 1803) で縦書きのフォントを使用した場合に一部の記号が正しく表示されない現象が確認されています。

[詳細]


Windows 10 April 2018 Update (Version 1803) 以降の Windows 10 において、ワードパッドなどの縦書きに対応したアプリケーションで、縦書き用のフォントを使用すると、次のようになどの一部の記号が正しく表示されない場合があります。

Windows 10 April 2018 Update (Version 1803) の場合

Windows 10 Fall Creators Update (Version 1709) の場合 (正しい表示)

[状況]


この問題について、詳細を調査中です。現在のところ、有効な回避方法はありません。

なお、現象は GDI を使用するアプリケーションで確認されており、Word 2016 などの DirectWrite を使用するアプリケーションでは確認されていません。

状況に進展がありましたら、本ブログ記事を更新させていただきます。


Windows 10 における Sysprep 実行時の注意点 2

$
0
0

皆さん、こんにちは。

日本マイクロソフト Windows サポート チームです。

Windows 10 バージョン 1803 における Sysprep 実行時の注意点について、本ブログでご紹介いたします。

本ブログでは以下の事象について、ご説明いたします。

Windows 10 バージョン 1803 において、マスター イメージに対し IE のプロキシの設定を実施した状態で CopyProfile を有効とし Sysprep を実行すると、Sysprep 完了後の新規ユーザー初回ログオン時の処理が進まない事象が発生いたします。

Windows 10 バージョン 1803 から OS 起動時にプロキシ サーバーの情報を確認する処理が追加されており、こちらの実装が追加されたことによって Sysprep 後の初回起動時にデッドロックが発生するため、本事象が発生いたします。

本事象は以下の設定の組み合わせによって発生するため、いずれかの設定を解除していただくことで回避可能でございます。

– IE のプロキシに関連した設定を行っている
– 応答ファイルの CopyProfile 設定を有効にしている

CopyProfileを使用しないことがご要件上難しい場合には、IE のプロキシの設定のみマスター イメージ対して事前に直接設定せず、以下いずれかの方法を用いてSysprep の処理が完了したタイミングでプロキシの設定を行ってください 。

A. Sysprep 後に各ユーザーが初回ログオンするタイミングで実行させるバッチ ファイルをマスター イメージに組み込む

B. ドメイン コントローラーからグループ ポリシーを配付する

以下に、各設定手順をご案内いたします。

<手順 A : Sysprep 後に各ユーザーが初回ログオンするタイミングで実行させるバッチ ファイルをマスター イメージに組み込む>
1. 以下のようにお客様の環境に合わせて IE のプロキシ設定を行うコマンドを記載したバッチ ファイルを作成し、拡張子を .bat にして保存します。

—————————
REG ADD “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings” /v “AutoConfigURL” /t REG_SZ /d “http://www.example.com” /f del %0
—————————
※ 上記コマンドに記載のレジストリは一例となりますため、お客様にて設定されたいプロキシの設定を保持するレジストリに適宜編集いただけますようお願いいたします。

2. 1 で保存したバッチ ファイルを以下のフォルダ配下に保存します。

C:\Users\<Sysprep の実行アカウント名>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

例)
C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup となります。

3. Sysprep を実行し、マスター イメージの作成を行います。

上記手順を実施することで、Sysprep 実施後に各ユーザーが初回ログオンを行うタイミングで、事前に配置したバッチ ファイルが自動的に実行され、各ユーザーのプロキシが自動的に設定されます。

<手順 B : ドメイン コントローラーからグループ ポリシーを配付する>
1. AD サーバーにて、[グループ ポリシー管理エディター] を開きます。

2. グループ ポリシー管理エディターの左ペインから、以下の通り選択します。

[<ポリシー名>]
– [ユーザーの構成]
– [基本設定]
– [コントロール パネルの設定]
– [インターネット設定]

3. [インターネット設定] を右クリックし、[Internet Explorer 10] を選択します。
※ クライアントの環境が Internet Explorer 11 の場合も [Internet Explorer 10] を選択します。

4. “新しい Internet Explorer 10 のプロパティ” というウィンドウが表示されたら、[全般] タブ内のホーム ページを入力する欄にカーソルを合わせ、F8 を押下し、緑色/赤色の点線をすべて赤色にします。
※ インターネット設定では、緑色の印が配布の対象となり、赤色の印は配布の対象となりません。設定の構成時に表示されたタブにおいて緑色の印だったものは値が配布されてしまうため、F8 を押下してすべて赤色とし、不要な設定を配布しないようにします。

なお、緑色/赤色の線は、以下のように変更が可能です。

– 画面上の全項目を有効(全て緑)にする:F5
– 画面上の全項目を無効(全て赤)にする:F8
– 選択中の項目を有効にする(項目のみ緑):項目選択中にF6
– 選択中の項目を無効にする(項目のみ赤):項目選択中にF7

5. [接続] タブを開きます。

このとき、タブ中段の “プロキシ サーバーを構成する必要がある場合は…” の項目に赤線/緑線が表示されていましたら、カーソルを合わせて F7 を押下し、赤線とします。

6. [LAN の設定] を押下します。

7. [ローカル エリア ネットワーク (LAN) の設定] というウィンドウにて、ご要望の設定を構成します。

※ プロキシ サーバーにアドレス等を入力する場合で、例外を設定したい場合には、[詳細設定] を押下し、例外を設定します。

8. 設定後、[OK] を押下し、[ローカル エリア ネットワーク (LAN) の設定] というウィンドウを閉じます。

9. クライアント環境に “一度だけ” 適用したい場合には、[共通] タブを開き、[1度だけ適用し、再適用しない] にチェックを入れます。

10. [適用] – [OK] でウィンドウを閉じます。

– 公開情報
上記インターネット設定については、以下の Blog 記事でも紹介しております。

“Internet Explorer の メンテナンス” 廃止に伴う代替案の紹介 – Part1.基本設定の紹介とプロキシ設定の配布

https://blogs.technet.microsoft.com/jpieblog/2014/08/12/internet-explorer-part1-2641/

上述のプロキシ設定を画像付きで紹介しておりますので、ご参照ください。

各設定手順については以上となります。
ご要件に合わせて、いずれかの設定方法をご検討下さい。

以上となります。
Windows 10 バージョン 1803 において Sysprep を実行する際に、ご参考になれば幸いでございます。

なお、本ブログは予告なく変更される場合がございますので、ご了承下さい。

.NET Framework 3.5 を有効化する手順について ( Windows Server 2012 R2 )

$
0
0

いつも弊社製品をご利用いただきまして誠にありがとうございます。Windows プラットフォーム サポートの濵谷です。

今回はよくお問い合わせいただくWindows Server 2012 R2 上の .NET Framework 3.5 有効化の方法についてご紹介いたします。
また、.NET Framework 3.5 を有効化する時に 0x800f081f ( CBS_E_SOURCE_MISSING ) エラーとなる事象についての対処方法もご紹介いたします。

.NET Framework 3.5 について


.NET Framework 3.5 は、Windows Server 2012 / Windows 8.1 以降既定のインストールでは有効化されません。
また、インストールされた Windows には .NET Framework 3.5 を有効化するためのソースとなるファイルが存在しておりませんので、インターネット上もしくはインストール メディアから用意する必要がございます。

[オンライン環境での .NET Framework 3.5 有効化について]
Windows Update に直接繋がる環境であれば、サーバー マネージャー内の簡単な操作で有効にする事が出来ます。
Windows Update サイトへの接続を制限している環境については、以下 [オフラインでの .NET Framework 3.5 有効化について] をご参照ください。

[オフライン環境での .NET Framework 3.5 有効化について]
インターネットに接続出来ない、Windows Update サイトに接続出来ない等のオフライン環境でインストールする際には、Windows のインストール ディスクもしくはインストール ISO (インストール イメージ ファイル) をソース ファイル として用います。
ISO 内 \sources\sxs フォルダーにある .NET Framework 3.5 のソース ファイルを DISM コマンドによりインストール ソース ファイルとして指定します。
※ インストール ディスク、インストール ISO はセットアップ時に利用されたお客様の環境に適切なメディアをご使用ください。

 

インストール手順


.NET Framework 3.5 のインストール手順は 2 種類あります。

1 つ目はサーバー マネージャーより、Windows Server 2012 R2 にインストールする方法です。( Windows Update に直接接続できる環境で利用します。)

1. サーバー マネージャーより、.NET Framework 3.5 を有効にする。
—————————-
1-1 サーバー マネージャーの管理を選択し、管理の中の「役割と機能の追加」を選択します。

1-2 「役割と機能の追加」の中の機能を選択します。
有効化する場合は、.NET Framework 3.5 Features のチェック ボックスをオンにします。

 

2 つ目はコマンドによって、Windows Server 2012 R2 にインストールする方法です。( Windows Update に直接接続出来ない環境などで利用します。)

2. Dism コマンドにより、.NET Framework 3.5 を有効にする
—————————-
2-1 上述の[オフラインでの .NET Framework 3.5 のインストール ソースについて]の部分で紹介したインストール メディアを用意します。

2-2 インストール メディアをドライブ(例 D: )にセットして、管理者としてコマンド プロンプトを実行します。

C:\Windows\system32>Dism /online /enable-feature /featurename:NetFX3 /all /Source:D:\sources\sxs\ /limitaccess

2-3 サーバー マネージャーを開き、「機能や役割の追加」より、.NET Framework 3.5 が有効化されているかを確認します。

 

言語パック追加済み環境で有効化する際に起こる動作について


言語パックが追加済みの環境に対して、オフラインで .NET Framework 3.5 を有効化した際に起こる動作 ( 0x800f081f エラー) への対処方法についてお話しいたします。

インストール メディアには、そのメディアの言語のソース ファイルしか含まれておりません。
そのため、英語環境でインストールされた Windows Server 2012 R2 に、日本語言語パックを追加した状態で .NET Framework 3.5のインストールを実施した際に 0x800f081f ( CBS_E_SOURCE_MISSING ) エラーが起きる動作が確認されております。
なお、Windows Update に接続出来る環境の場合、Windows Update サイトからそれぞれの言語にローカライズされたソースを自動的に取得するため、本問題は発生いたしません。

英語版のインストール メディアには、英語版のソース ファイルのみとなりますため、0x800f081f エラーとなる動作は日本語版のソース ファイルが不足することによって発生します。

この動作に対する解決方法を紹介いたします。

 

解決方法


言語バックをアンインストール後、.NET Framework 3.5 を有効にします。
—————————-
[表示言語のインストールまたはアンインストール] か、コマンド プロンプト上から日本語の言語パックをアンインストールします。
コマンド プロンプト上で言語パックをアンインストールする場合は、管理者として下記を実行してください。

C:\Windows\system32>lpksetup.exe /u ja-jp

注:コマンド実行後に自動的に再起動が行われますのでご注意ください。

※ 言語バック削除後再度上記のインストール手順を実施ください
※ 日本語の言語パックが必要である場合は、もう一度「言語のインストール、アンインストール」より日本語の言語パックのインストールをお願いいたします。

 

参考情報


Windows 8、Windows 8.1、および Windows 10 への .NET Framework 3.5 のインストール
https://docs.microsoft.com/ja-jp/dotnet/framework/install/dotnet-35-windows-10

オフライン モードで Windows 8 上で .NET Framework 3.5 を有効にする方法
https://support.microsoft.com/ja-jp/help/2785188

展開イメージのサービスと管理 ( DISM ) を使用して .NET Framework 3.5 を展開する
https://msdn.microsoft.com/ja-jp/library/windows/hardware/dn898529(v=vs.85).aspx

DISM とは
https://msdn.microsoft.com/ja-jp/library/windows/hardware/dn938351(v=vs.85).aspx

Windows Server 2012 R2 上の .NET Framework 3.5 有効化の際の一助となりましたら幸いです。
なお、本ブログは予告なく変更される場合がございますのでご了承下さい。

ディスク オフラインに時間がかかる事象について

$
0
0

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

最近、 ディスクをオフラインにするのに非常に時間がかかる というお問い合わせをいただきました。
そこで今回は、多くの世代のシャドウ コピーを保管している環境にて、ディスクのオフライン作業を行う際の考慮事項について ご紹介します。

下記のような運用状況において、ボリューム シャドウ コピー (VSS) 機能をご利用の場合に、シャドウ コピーが原因となって本事象が発生している可能性があります。

  • ボリュームの共有フォルダーのシャドウ コピーを、そのボリューム上に複数世代作成し保管している場合
  • ※ ボリュームのシャドウ コピーの記憶域を別のディスク上に保存しているディスクの場合は現時点でこのような事象が発生した報告はありません。
  • クラスター環境にて、上記同様にシャドウ コピーを作成したディスクのオンライン / オフラインを切り替えて運用を行っている場合

また、本事象はパフォーマンスの影響を受けやすいクラウド環境のストレージで発生することが多く報告されております。
シャドウ コピーを大量に作成しているお客様で特にクラウド環境やクラスター環境をご利用の場合は、本事象を避けるために、本ブログの内容を考慮に入れての運用をご検討ください。
 

シャドウ コピー とディスク オフライン作業

システムを運用する中で、新しいディスクのマウント作業やクラスター環境の運用などを行う際には、ディスクのオンライン / オフライン状態の切り替えを行うことがあると思います。
通常の環境であれば、環境自体を起動させた際にディスクがオンラインとなり、シャットダウン時にオフラインにする処理が行われるため、シャットダウンが遅くなることはありますが、ディスクのオフライン作業を意識することは少ないと思います。
しかしながら、クラスター環境やバックアップのためにディスクを一時的にマウントしたい場合など、OSが起動している状態で、一時的に利用するディスクを取り外す場合であれば、手動で作業を行うためディスクのオフライン作業を意識することになります。

ディスクのオフライン作業は、安全にディスクを取り外し可能な状態とするために、メモリ上から当該ディスクに行うデータ書き込みを終わらせたり、データの整合性を保つための確認処理を行います。

シャドウ コピーを保存しているディスクをオフラインとする際には、このディスクに対して差分をデータ退避する処理を終了し、シャドウ コピーの整合性を確認するための読み込み処理を行います。

具体的には、対象のボリュームに対して事前通知が行われ、通知を受けた Volsnap (VSS 用ドライバ) が、ボリューム上の Diff Area (ボリュームの差分データ) に対して、データの整合性を保つために、クリーンナップ処理や、Bitmap の確認処理などの、必要な処理を行います。
そのため、当該ディスクにシャドウ コピーが大量に保存されていると、全シャドウ コピーをブロック単位で確認するため、シャドウ コピーの世代数やデータ量が多ければ多いほど、上記の必要な処理に時間を要し、ディスクのオフライン作業に時間がかかっています。
なお、ドライブ レターの変更を行う際に関しても、一度ドライブを OS からアンマウントし、上記と類似した処理が行われるため、処理が遅くなる可能性があります。

クラスター環境の場合は、ディスクのオフライン処理が進まないことを影響して STOP エラーが発生することがあります。
(クラスターは、一部のクラスター リソースに対し異常を検知した際に復旧のために各リソースの再起動を行います。ディスクのオフライン処理が進まずこの再起動が一定時間内に完了しないとクラスターは復旧のために意図的に STOP エラー 0x9E を発生させることがあります)

また、サードパーティー制の製品を使ってオフライン、または、シャットダウンまでの時間を監視している場合は、タイムアウトが発生することがあります。
 


[タイトル] ボリューム シャドウ コピー サービス (VSS) について
[URL] https://blogs.technet.microsoft.com/askcorejp/2018/08/15/aboutvss/
[内容] シャドウ コピーを作成するサービスである、ボリューム シャドウコピー サービス (VSS ) についてご紹介しているブログになります。
 

対処策: 保存されるシャドウ コピーの世代数を減らす

本事象の対処策としては、保存されるシャドウ コピーの世代数を減らすことが有効となります。
シャドウ コピーには、大きく分けて “共有フォルダーのシャドウ コピー” と バックアップソフトなど “アプリケーションが自動で作成するシャドウ コピー ” の2種類があり、どちらであるかによって制限方法が異なります。
 


[タイトル] vssadmin コマンドでシャドウ コピーが削除できない場合の対処方法について
[URL] https://blogs.technet.microsoft.com/askcorejp/2013/11/28/vssadmin-2096/
[内容] シャドウ コピーの種類についてと削除方法についてご紹介しているブログになります。
 

共有フォルダーのシャドウ コピーの制限手順

共有フォルダーのシャドウ コピーの世代数の上限を変更するには、以下のレジストリ値を編集します。
 

MaxShadowCopies の変更手順

  1. [スタート] – [ファイル名を指定して実行] をクリック、regedit と入力し、[OK] をクリックします。
  2. 以下のレジストリ キーを開く
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Settings
  3. メニュー バーより、[編集] – [新規] を選択し、[DWORD 値] をクリックします。
  4. MaxShadowCopies と入力し、Enter キーをクリックします。
  5. MaxShadowCopies を選択した状態で、メニュー バーより、[編集] – [修正] をクリックします。
  6. 設定する世代数を入力し、[OK] をクリックします。

 

なお、MaxShadowCopies の設定に関しては、共有フォルダーのシャドウ コピーが世代数の上限値まで保存されている状態で、Windows Server バックアップや読み取り chkdsk など、シャドウ コピーの自動作成を行うアプリケーションを実行すると、最も古い共有フォルダーのシャドウ コピーが削除されてしまう事象が報告されています。

そのため、シャドウ コピーを取得する世代の上限値を 1 つ多く設定する対策が推奨します。
詳しくは、下記の公開情報をご参照ください。
 


[タイトル] 最も古い共有フォルダーのシャドウコピーが削除されてしまう事象について
[URL] https://blogs.technet.microsoft.com/askcorejp/2018/09/03/oldest_shadowcopy_deletion/
[内容] 最も古い共有フォルダーのシャドウ コピーが削除されてしまう事象についてご紹介しているブログになります。
 

また、レジストリ値の変更はシステム構成が変更されてしまうので難しいという場合は、定期的に古いシャドウ コピーを削除していただいても有効です。
 

アプリケーションが自動で作成するシャドウ コピーの制限手順

共有フォルダーのシャドウ コピー以外の種類のシャドウ コピーの世代数を制限するレジストリ値はないため、シャドウ コピーの保存領域の制限を行う方法が有効となります。
 

VSS の記憶領域の制限方法

  1. サーバー マネージャーから [コンピュータの管理] 画面を開きます。
  2. 左ペインの [記憶域] – [ディスクの管理] を選択し、中央ペインで対象のボリュームを右クリックして、ボリュームのプロパティを開きます。
  3. [シャドウ コピー] タブを開き対象のボリュームを選択した状態で [設定] をクリックします。
  4. 記憶域の最大領域を変更する場合には [制限値] の値を修正します。

 

なお、こちらに関しても、定期的に古いシャドウ コピーを削除していただいても有効です。
 

対処策: クラスター環境においてタイムアウトの時間を延ばす

上述の通りクラスターは、ディスクのオフライン処理が進まず、各リソースの再起動が一定時間内に完了しないと、
タイムアウトとなり復旧のために意図的に STOP エラー 0x9E を発生させることがあります。

タイムアウトは、クラスター リソースのプロパティ DeadlockTimeout の 4 倍の値となります。
ディスク リソースの DeadlockTimeout が 5 分で設定されているため既定では 4 倍である 20 分が再起動のタイムアウト値となります。

20 分以内に再起動が終了しない場合に STOP エラー 0x9E が発生するため、タイムアウト値を延ばすことで、オフライン処理に対する待ち時間を延ばすことも可能です。
 

DeadlockTimeout を変更する方法

  1. 管理者権限で PowerShell を起動します
  2. 以下のコマンドレットで、使用しているリソース一覧を確認します。
    Get-ClusterResource
  3. 設定はリソースごとになります。上記で確認できた “Name” 列の情報を利用して、以下のコマンドレットを実行し、現在の設定値を確認します。単位はミリ秒になります。
    (Get-ClusterResource “Name”).DeadlockTimeout

    仮に、”Name” が “クラスター ディスク 1” の場合、実行コマンドレットは以下になります。
    (Get-ClusterResource “クラスター ディスク 1”).DeadlockTimeout
  4. 現在の設定値を確認後、以下のコマンドレットを実行することで設定変更を行います。以下は、DeadlockTimeout を 600000 ミリ秒 (10 分)に設定している例となります。
    (Get-ClusterResource “Name”).DeadlockTimeout = 600000

    ※ 10 分に設定した場合、40 分以内に再起動が終了しない場合に STOP エラー 0x9E が発生します。
  5. 再度、設定変更できていることを確認します。
    (Get-ClusterResource “Name”).DeadlockTimeout
  6. 該当リソースのオフライン/オンラインを実施し、設定変更を反映させます。

 

補足

StorSimple のボリュームの VSS スナップショットを設定する場合、Azure ストレージにもデータが保存される環境ではこの事象が発生しやすいことが報告されており、パフォーマンスに影響を与える可能性があるため、Diff Areaはローカル固定ボリュームに保存することが推奨されております。ローカル固定ボリュームは、Azure ストレージにはデータを保存しない、ボリュームとなります。
 


[タイトル] Microsoft Azure StorSimple 8000 Series Deployment Best Practices
[URL] https://gallery.technet.microsoft.com/Azure-StorSimple-8000-72b01b68″ target=”_brank”>https://gallery.technet.microsoft.com/Azure-StorSimple-8000-72b01b68

[原文抜粋]
Volume Shadow Copy service (VSS)
When using Volume Shadow Copy service (VSS) in StorSimple volumes, we recommend that the diff area for VSS be in a StorSimple locally pinned volume. You could also use an external disk with sufficient capacity for your diff area.


 

いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立てば幸いです。

スタートアップ時タスクの実行に失敗する問題について

$
0
0

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

本日はタスク スケジューラにて “スタートアップ時” (システム起動時) のトリガーを登録しているタスクの実行が失敗する問題について、ご紹介いたします。

[現象]

タスク スケジューラにて、”スタートアップ時” (システム起動時) のトリガーを登録しているタスクが複数 登録されている場合、それらのタスクがランダムに実行失敗する場合があります。

事象発生時には、該当のタスクが実行されず、タスク スケジューラの履歴タブにエラー イベント ID: 101 が記録されます。またその際のエラー値は ERROR_LOGON_FAILURE (2147943726) となります。(タスク スケジューラの履歴機能を有効化している場合のみ。)

[発生条件]

この問題は以下の 3 つの条件を全て満たす場合に発生する可能性があります。

① OS バージョンが以下のいずれかに該当する。

Windows Server 2016
Windows Server 2012 R2
Windows 10 (Version 1803 までの全てのバージョン)
Windows 8.1

② 2017 年 9 月 以降の更新プログラムを適用している。

本問題は、Windows 10 Version 1703 以降の OS バージョンでは更新プログラムを適用しない状態でも発生いたします。

対して、Windows 10 Version 1607 までの OS バージョンおよび、サーバー OS では 2017 年 9 月以降の更新プログラムを適用した場合に発生することが確認されています。
具体的には、以下の更新プログラムを適用した場合には、本問題が発生することが確認されています。また該当のモジュールが含まれる更新プログラム、例えば、より新しいロールアップ更新プログラムを適用した場合にも同様の問題が発生します。(セキュリティ更新プログラムを適用した場合には該当のモジュールが含まれず、発生しない場合があります。)

– Windows 8.1 / Windows Server 2012 R2
2017 年 9 月 20 日 – KB4038774 (マンスリー ロールアップのプレビュー)
https://support.microsoft.com/ja-jp/help/4038774/

– Windows 10 RTM
2017 年 9 月 13 日 – KB4038781 (OS ビルド 10240.17609)
https://support.microsoft.com/ja-jp/help/4038781/

– Windows 10 Version 1607 / Windows Server 2016
2017 年 9 月 29 日 – KB4038801 (OS ビルド 14393.1737)
https://support.microsoft.com/ja-jp/help/4038801/

③ 以下の 3 つの条件を全て満たすタスクが複数 (2 つ以上) 登録されている。

この問題は、タスクの実行にあたりタスク スケジューラから資格情報マネージャーに資格情報の要求を行った際、資格情報マネージャーにおいて、複数スレッドでの処理を正しく完了できなかった場合に発生します。そのため、複数のタスクで以下の設定が行われている場合にのみ発生します。

  • 実行ユーザーが、SYSTEM アカウント等の特殊なアカウントではない。
  • “パスワードを保存しない” オプションが設定されていない。

  • トリガーに “スタートアップ時” (システム起動時) が設定されている。

[対処策]

以下のいずれかの対処を行うことで、本問題を回避することが可能です。

a) SYSTEM アカウントを使用する

タスクの実行ユーザー アカウントとして “SYSTEM” 特殊アカウントを指定することで、お問い合わせの問題を回避することが可能です。
SYSTEM アカウント (Local System アカウント) は、Windows OS により内部的に使用される特殊なサービス アカウントです。セキュリティ識別子としては S-1-5-18 が割り当てられており、ローカル コンピューターにおいては管理者 (Administrators グループ) と同等、或いはそれ以上の権限を持ちます。

SYSTEM アカウントは以下手順にて、タスク スケジューラの実行ユーザーに指定することが可能です。その場合、タスク スケジューラからのタスクの実行に際して資格情報マネージャー等は使用せず、そのため、お問い合わせの問題を回避することが可能です。
なおログオン ユーザーのプロファイルを使用するなど一部の処理は SYSTEM アカウントを使用できない場合がありますのでご注意ください。

– 設定例

  1. 管理者ユーザーでログオンします。
  2. スタート メニューの管理ツールより [タスク スケジューラ] を開きます。
  3. 該当のタスクを右クリックし、”プロパティ” を開きます。
  4. [全般] タブのタスクの実行時に使うユーザー アカウント欄の、[ユーザーまたはグループの変更] ボタンを押します。
  5. 選択するオブジェクト名として “SYSTEM” を記入し [OK] にて設定します。実行時に使うユーザー アカウントは “NT AUTHORITY\SYSTEM” となります。
  6. [OK] にてタスクのプロパティを閉じ、タスクを保存します。
b) “パスワードを保存しない” を設定する (ドメイン ユーザーの場合のみ)

タスクの実行ユーザーとしてドメイン ユーザーを設定している場合、タスクの [全般] タブにて “パスワードを保存しない” を設定いただくことで、お問い合わせの問題を回避することが可能です。
これは “パスワードを保存しない” を設定した場合には、ローカル コンピューターの資格情報マネージャーへ資格情報を保存せず、タスクの実行時には他の方法 (Kerberos 認証プロトコルの S4U 拡張) を使用してトークン情報を取得するためです。
なお、この設定を行うことで、設定項目に記載のとおり、タスクとして実行したバッチ ファイル等からのネットワーク アクセスを行うことができない動作となりますので、ご注意ください。

– 設定例

  1. 管理者ユーザーでログオンします。
  2. スタート メニューの管理ツールより [タスク スケジューラ] を開きます。
  3. 該当のタスクを右クリックし、”プロパティ” を開きます。
  4. [全般] タブのセキュリティ オプションにて、タスクの実行時に使うユーザー アカウントがドメイン ユーザーであることを確認します。
  5. “パスワードを保存しない (タスクがアクセスできるのはローカル コンピューター リソースのみ)” にチェックを入れます。
  6. [OK] にてタスクのプロパティを閉じ、タスクを保存します。
c) 異なる “遅延時間” を設定し同時に実行しない

システム起動時のトリガーに遅延時間を設定することで、事象の発生頻度を大きく下げることが可能です。
例えばシステム起動時のトリガーを持つタスクが 2 つ存在する場合、一方のトリガーに、遅延時間 1 秒を指定することで、事象の発生タイミングがずれ、事象の発生頻度が大きく下がります。(タスクが 3 つ以上ある場合、タスクには異なる遅延時間を設定します。)

– 設定例

  1. 管理者ユーザーでログオンします。
  2. スタート メニューの管理ツールより [タスク スケジューラ] を開きます。
  3. 該当のタスクを右クリックし、”プロパティ” を開きます。
  4. [トリガー] タブを開きます。
  5. “スタートアップ時” のトリガーを選択し、[編集] にて開きます。
  6. 詳細設定の “遅延時間を指定する” にチェックを入れ、遅延時間を指定します。
    ※ プルダウン メニューでは 30 秒が最小ですが、秒数は手動で指定が可能です。確認の結果では 1 秒を指定した場合にも十分な効果が得られましたが、できる限り事象の発生を回避するため、許容可能な最大の秒数、分数を指定します。
    ※ 遅延時間は、”スタートアップ時” (システム起動時) の全てのタスクで異なる値となるよう、設定します。
  7. [OK] にてトリガーを設定します。
  8. [OK] にてタスクのプロパティを閉じ、タスクを保存します。
d) タスクを 1 つにまとめる

設定されている複数のタスクについて、実行する操作 以外の設定 (特にタスクの実行ユーザーの設定) が同じ場合には、タスクを 1 つにまとめ、1 つのタスクに複数の操作を設定することで、本問題を回避可能です。

[弊社での対応]

マイクロソフトでは、この問題をこの資料の発生条件に記載されているマイクロソフト製品の問題として認識しています。

2018 年 9 月時点で、本問題を全て解消する更新プログラムのご用意はございませんため、上記の対処の実施をご検討いただけますと幸いです。
この問題について新たな情報が確認でき次第、本ブログ記事を更新させていただきます。

2018 年 8 月更新プログラムを適用後、仮想マシンの起動が失敗する

$
0
0

こんにちは。Windows プラットフォーム サポートです。
Windows Server 2016 Hyper-V ホストに 2018 年 8 月更新プログラム (KB4343887) を適用後、仮想マシンの起動が以下のエラーにより失敗する場合がございます。

—————————————
ログの名前: Microsoft-Windows-Hyper-V-VMMS/Admin
ソース: Hyper-V-VMMS
日付: XXXX/XX/XX XX:XX:XX
イベント ID: 20144
タスクのカテゴリ: なし
レベル: エラー
キーワード: N/A
ユーザー: SYSTEM
コンピューター: XXXXXXXX
説明:
Hyper-V コンポーネントの1 つが実行されていないため、仮想マシン管理サービスは仮想マシン “XXX” を起動できません。
(仮想マシン ID XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)
—————————————

[原因]
仮想マシン管理サービス (vmms) は起動時に Hyper-V コンポーネントである仮想インフラストラクチャー (VID) が動作しているか
情報取得を行いますが、本事象は VID の情報が取得できないことにより発生いたします。

[対処]
Hyper-V ホストを OS 再起動することにより、本事象は復旧いたします。
そのため、更新プログラム適用後に上記のエラーが発生した際には、Hyper-V ホストを再起動いただきますようお願いいたします。

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

Viewing all 590 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>