Ask CORE

Microsoft Japan Windows Technology Support

2018 年 1 月更新プログラムを適用後、ライブマイグレーションが失敗する

こんにちは。Windows プラットフォーム サポートです。 2018 年 1 月更新プログラム適用の Hyper-V ホストから 未適用の Hyper-V ホストに対して仮想マシンのライブマイグレーションを実行するとイベントログに Hyper-V-VMMS ID:24004 が記録され、失敗する場合があります。 ————————————— ログの名前: Microsoft-Windows-Hyper-V-VMMS/Admin ソース: Hyper-V-VMMS 日付: XXXX/XX/XX XX:XX:XX イベント ID: 24004 タスクのカテゴリ: なし レベル: エラー キーワード: N/A ユーザー: SYSTEM コンピューター: XXXXXXXX 説明: 仮想マシン ‘XXXX’ は、物理コンピューター ‘XXXX’ でサポートされていないプロセッサー固有の機能を使用しています。 異なるプロセッサーを持つ物理コンピューターにこの仮想マシンを移行できるようにするには、仮想マシン設定を変更して、 仮想マシンで使用されるプロセッサー機能を制限します。(仮想マシン ID XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX) ————————————— ※ 未適用の Hyper-V ホストから適用した Hyper-V ホストへのライブマイグレーションは成功します。 ※ 本事象は以下の更新プログラム適用で発生する場合がございます。… Read more

WSFC 環境の NFS サーバーに対して 40 台以上のクライアントがロックを解放しないままフェールオーバーすると STOP エラー 0x9e が発生することがある

こんにちは。Windows プラットフォーム サポートです。 本稿では、WSFC 環境の NFS サーバーで特定の条件下においてフェールオーバーした場合、STOP エラー 0x9e が発生する現象について確認しております。 [現象] Windows (Storage) Server 2012/Windows (Storage) Server 2012 R2/Windows (Storage) Server 2016 の Windows Server フェールオーバー クラスタリング (WSFC) 環境で、NFS サーバーに対して、40 台以上の NFS クライアントからロックを保持し、正しくロックを解放しないまま疎通が取れなくなった状態で、NFS サーバーのフェイルオーバーを連続して 2 回実施した場合、STOP エラー 0x9e (USER_MODE_HEALTH_MONITOR) が発生する可能性があります。   [原因] この現象は以下のシナリオで発生します。 1. NFS クライアントからクラスター ノード A 上の NFS サーバーにアクセスし、ファイルをロックします。 その後ファイルのロックを解放しないままネットワークから切断します。このような端末が 40 台存在すると想定します。 2…. Read more

LPRemove タスクの動作について

こんにちは。 Windows サポートの丸山です。 現在弊社にて提供しております多くの Windows 製品では、多言語対応となっており、あらかじめ言語パックが追加されたイメージを展開いたしますと、セットアップ時に表示言語を選択できるようになっております。 ※ Windows Server 2016 製品のセットアップ時における、言語選択画面の例 またいっぽうで、使用していない言語パックを削除する LPRemove タスクが登録されており、コンピューターの起動時や、メンテナンスのタイミングにて、言語パックのクリーンアップを行っております。 LPRemove タスクは、バックグラウンドで実行されておりますが、すべての言語パックが削除される前にコンピューターの再起動を行いますと、削除されなかった言語パックが残されたままとなる動作が確認されております。 不要な言語がインストールされている場合には、手動で言語パックの削除を実施してください。 ※言語パックの削除ツールは、”lpksetup /u” コマンドで起動できます。 多言語環境の構築を検討いただくにあたり、本ブログ記事の情報がお役に立てますと幸いです。… Read more

パフォーマンス ログのススメ

こんにちは。 Windows サポートの水上です。 今回は、パフォーマンスの問題が発生した際にお願いしたい、パフォーマンス ログの採取についてご紹介します。… Read more

Windows Server 2012 / 2012R2 以降のデフラグの変更点

こんにちは、Windows プラットフォーム サポートの鎌滝です。 デフラグは Windows XP/2003 世代から実施されていたファイル システム レベルのメンテナンスであり、断片化の起きたファイルのディスク I/O のパフォーマンスを向上させるために実施されます。今回は Windows Server 2012 以降のデフラグに追加された機能とデフラグを実施する必要性について、ご紹介したいと思います。 本項は Windows Server 2012 以降のデフラグにについて書かれた以下のブログをもとに、日本語での説明を行います。 What’s New in Defrag for Windows Server 2012/2012R2   1. デフラグの有効性 そもそも、デフラグは何のために行われるのか、実施する必要はあるかについて、説明します。なお、ここで議論するデフラグはファイルの断片化を解消する “従来のデフラグ” です。 ファイルへの書込み、消去、サイズ変更が継続的に実施される環境で、物理ディスク上で継続した領域を確保できない場合に、その変更は別の空き領域に書き込まれるため、ファイルの断片化が起こるのは自然な現象です。ファイルに断片化が起きた場合、そのファイルの読み書きには断片化が起きていないファイルより多くの時間を要するため、ディスク I/O のパフォーマンスの観点からデフラグは有効です。 また、デフラグを実施することで、ディスク上に連続した空き領域を確保できます。 Windows Server バックアップなどでボリューム シャドウ コピー サービス (VSS) を使用する場合、スナップショットの準備に Diff Area と呼ばれる連続した領域が必要になります。極度な断片化を解消し、連続した空き領域確保する観点からもデフラグは有効です。 では、この “従来のデフラグ” を実施する必要はあるのか、の説明の前に、デフラグ コマンドに追加されたオプションについて次項で説明します。結論はその後の項番 3 で触れたいと思います。… Read more

イベント FailoverClustering 1230 について

こんにちは。Windows プラットフォーム サポート担当です。 本日は、クラスター環境で発生するイベント ID 1230 (ソース:Microsoft-Windows-FailoverClustering) についてご紹介します。   – イベント ID 1230 クラスターではリソースに対する操作 (正常性チェック LooksAlive, IsAlive など) で応答が無い場合に、リソースの応答を待ち続けることでクラスターの動作が停止することを防ぐためにタイムアウト値 DeadlockTimeout が設けられています。 リソースの操作が DeadlockTimeout 値を超えて完了しないとタイムアウトが発生しイベント ID 1230 が記録されます。   – イベント ID 1230 の原因調査 イベント ID 1230 が記録された時のクラスター ログからは何の操作でタイムアウトが発生したかを確認することができますが、リソースの操作が停止しタイムアウトした原因はイベント ログやクラスター ログなどから調査することが困難となります。   // リソース Disk01 への操作 LOOKSALIVE がタイムアウトしたことを示すクラスター ログ ERR   [RHS] RhsCall::DeadlockMonitor: Call LOOKSALIVE timed out… Read more

マルチサイト クラスター環境で記録されるイベント ID 1135 について

こんにちは。Windows プラットフォーム サポート担当です。 本日は、弊社に比較的多くお問い合わせをいただくマルチサイト クラスター環境で記録されるイベント ID 1135 について対処策を紹介します。   – イベント ID 1135 イベント ID 1135 はクラスター ノード間のハートビート通信がすべてのネットワークで失敗し、クラスターを構成するノードがクラスターから除外されたことを示すイベントです。 ハートビート通信はクラスター ノード間で定期的 (既定で 1 秒毎) にパケットの送受信が行われ、一定の期間パケットが届かないと失敗と判断されます。   <参考> フェールオーバー クラスターのハートビートについて https://blogs.technet.microsoft.com/askcorejp/2012/03/22/156/   通常、シングルサイト クラスター環境ではクラスターで使用されるネットワークが複数構成されているため、一つのネットワークで問題が発生した場合でも他のネットワークでノード間の通信が可能であればイベント ID 1135 は記録されません。   一方、マルチサイト クラスター環境ではノード間通信が WAN 回線を経由しておこなわれるため、WAN 回線が不安定な場合、ハートビート通信が失敗しイベント ID 1135 が記録されクラスターを構成するノードがクラスターから除外される問題が発生します。   実際にマルチサイト クラスター環境では、WAN 回線の問題によりイベント ID 1135 が記録される報告が弊社まで多く寄せられていますが、ネットワークの問題のため弊社にお問い合わせをいただいても OS 側からは調査が困難です。 クラスターでは既定で 5… Read more

リモート デスクトップ サービス環境にてファイルが削除ができない事象について

こんにちは。Windows プラットフォーム サポートの吉田です。 Windows Server 2012 以降のリモート デスクトップ サービス環境において、ファイルが削除できない現象が発生することがあります。 発生要因と回避策についてご案内いたします。 ■ 現象概要: Windows Server 2012 以降のリモート デスクトップ サービス環境をご利用しており、かつ、プロファイル管理にユーザー プロファイル ディスク (UPD) をご利用いただいている場合に、ファイルを右クリックして “削除” もしくはごみ箱にファイルを移動させようとすると、削除時に管理者権限の資格情報を要求される場合があります。 このとき、Shift + Delete による直接削除は可能です。   ■ 詳細: 通常時は、ごみ箱にファイルを削除する際は、<%UserProfile%>\RECYCLE.BIN\<User-SID> フォルダー下に削除ファイルを作成いたします。 しかしながら、事象が発生している場合、<%UserProfile%>\RECYCLE.BIN フォルダー直下に削除ファイルを作成しようと動作いたします。 <%UserProfile%>\RECYCLE.BIN フォルダー直下は、正常時でも通常ユーザーは Write 権限がありません。 このため、ごみ箱に削除できない事象が発生いたします。 UPD はユーザーが RD セッション ホストにログオンする際にマウントされ、マウントポイントのリストが作成されます。この際、タイミングによりマウントポイントのリストへの追加が行われない場合があります。この状況が発生すると <%UserProfile%>\RECYCLE.BIN\<User-SID> ではなく、<%UserProfile%>\RECYCLE.BIN フォルダー直下がゴミ箱の格納先として使用されます。 これにより、削除 (移動) の権限が与えられず、ファイルが削除できない事象が発生します。 これは、UPD のマウント時に動作するマウント の通知とリストの作成がそれぞれ別のサービスで動作し、それぞれのサービスの動作するタイミングによって発生します。  … Read more

LPD サーバーへ印刷時のポート設定について

こんにちは。Windows サポートの鈴木です。 印刷の出力先として LPD サーバーを指定いただく際のポートの設定についてご紹介いたします。 LPR プロトコルを使用した印刷は、プリント サーバーが UNIX / Linux 等の場合に使用されるほか、 サーバー側で印刷のログを取得したり、ドキュメントを蓄積、分類等を行うアプリケーションなどを ご使用の際にも使用されることがあります。また、お使いのプリンターが対応している場合は、 LPR プロトコルを使用して直接印刷を実行できる場合もあります。 さて、ここで注意いただきたいのが、印刷の相手がサーバーなのか、プリンターなのかという点です。 Windows の既定の状態で、プリンターに対して LPR プロトコルで印刷データを送信するために 「標準 TCP/IP ポート モニター」が使用可能となっています。 同じ LPR プロトコルですから、この「標準 TCP/IP ポート モニター」 を使用して プリンターではなく LPD サーバーへの印刷を行うことも、多くの場合は可能です。 しかしながら、サーバーとクライアント間のネットワークが切断された場合の リトライ動作等で予期しない事象が発生するという報告をお寄せいただいております。 このような場合にご検討をいただきたい回避策として、以下 2 点があります。 [LPR バイト カウントを有効にする] チェックボックスを有効にします。 標準 TCP ポート モニターの代わりに “LPR ポート モニター” を使用します。 [LPR バイト カウントを有効にする]… Read more