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

Multi-Domain Cluster 作成後にノードの削除、再追加がエラーで失敗する

0
0

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

Windows Server 2016 では、Active Directory に依存しないフェールオーバー クラスターを作成する機能が導入されており、異なるドメインのサーバーでクラスターを構成する「Multi-domain Clusters」とワークグループのサーバーでクラスター構成する「Workgroup Clusters」という新機能が追加されております。

Multi-domain Clusters」と「Workgroup Clusters」の要件や作成手順は、下記ブログに記載がございますのでご参考ください。

 

<参考> Workgroup and Multi-domain clusters in Windows Server 2016

https://blogs.msdn.microsoft.com/clustering/2015/08/17/workgroup-and-multi-domain-clusters-in-windows-server-2016/

 

本日は「Multi-domain Clusters」の環境でノードの追加が失敗する事象を紹介いたします。

クラスター作成後にノードの削除、再追加を行うと認証を正常に行うことができず、下記エラー (error code 0x5b4) が発生しノード追加に失敗することがございます。

 

error code 0x5b4 ERROR_TIMEOUT を示します。

 

このエラーは、再度追加するノードと同じドメインのサーバーがクラスターに 1 台も参加していない場合に発生します。

例えば下記 3 台のノードでクラスターを作成した後で、ノード Node3 (ドメイン B) の削除、再追加を行うと再追加時にはドメイン A のサーバーしかクラスターに参加していないため、エラー (error code 0x5b4) が発生し失敗します。

 

   – Node1 (ドメイン A)

   – Node2 (ドメイン A)

   – Node3 (ドメイン B)

 

※ 上記構成で Node1 または Node2 のいずれかをノードの削除、再追加を行うともう 1 つ同じドメインにノードがあるため再追加に成功します。

 

また、上記 3 台のノードでクラスターを作成した後で、異なるドメイン C からノード Node4 (ドメイン C) を新しく追加しようとした場合にも同じエラーで追加が失敗いたします。

 

つまり Windows Server 2016 の「Multi-domain Clusters」環境では、追加できるサーバーは、現在クラスターに参加しているノードが属しているドメインのメンバー サーバーのみということになります。

そのため、異なるドメインからクラスターにサーバーを追加するにはクラスターを一度破壊して再作成する必要がございます。

 

上記 3 台のノード (Node1, Node2, Node3) で作成したクラスターの構成に問題はございませんが、Node3 の削除、再参加が必要なシナリオを考慮する必要がある場合には、一つのドメインごとにサーバーを複数台追加いただくことをご確認ください。

 

   構成例 1)

   – Node1 (ドメイン A)

   – Node2 (ドメイン A)

   – Node3 (ドメイン A)

   – Node4 (ドメイン B)

   – Node5 (ドメイン B)

 

   構成例 2)

   – Node1 (ドメイン A)

   – Node2 (ドメイン A)

   – Node3 (ドメイン A)

   – Node4 (ドメイン B)

   – Node5 (ドメイン B)

   – Node6 (ドメイン C)

   – Node7 (ドメイン C)

 

 

※ 注意

この情報は 2017/10/20 時点のものでございます。

現時点で上記動作に変更が加わる情報はございませんが、今後修正により本エラーが解消される場合もございます。

最新の情報につきまして確認が必要な場合には、弊社サポート窓口までお問い合わせをいただけますようお願いいたします。


Windows Server バックアップがサーバーマネージャーの GUI 上から表示されなくなる事象について

0
0

こんにちは。Windows プラットフォーム サポートの三田です。今回は、Windows Server 2012 以降の環境で確認されている、Windows Server バックアップがサーバーマネージャーの GUI 上から表示されなくなる現象についてご説明いたします。

■ 現象概要:

Windows Server 2012 以降の環境で、Windows Server バックアップとリモートデスクトップセッションホストが機能としての役割がインストールされている環境において、サーバーマネージャーの GUI 上からリモートデスクトップセッションホストの機能を削除後、Windows Server バックアップの項目がサーバーマネージャーの GUI 上から表示されなくなる(※)。

※ 事象発生時、C:\Windows\System32 配下にある、wbadmin.msc も消えていることを確認しております。

※ なお、Wbadmin.exe は存在しているため、wbadmin コマンドによるバックアップは可能でございます。

 

■ 詳細:

1 . リモートデスクトップセッションホストの機能を削除する前のサーバーマネージャーでは、

以下のように Windows Server バックアップが表示されています (赤線部)。

 

 

 

2 .しかし、リモートデスクトップセッションホストの機能を削除する後、以下のようにサーバーマネージャーから Windows Server バックアップの項目が消えていることが確認できます。

 

なお、上記はリモートデスクトップセッションホストの機能を削除時に事象が発生しておりますが、フェールオーバークラスターマネージャー 機能を削除した場合も同様に Windows Server バックアップの項目が サーバーマネージャーの GUI より表示されなくなることを現時点で確認しております。

    また、本事象は Windows Server 2012/2012R2 /2016 環境で発生することを確認しております。

     

    ■ 回避策

    本事象を回避いただく場合には、恐れ入りますが、管理者権限を持つコマンド プロンプトより、以下のコマンドを実行してください。
     dism.exe /online /enable-feature /all /featurename:WindowsServerBackupSnapin

     

     

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

    0
    0

    こんにちは。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 のマウント時に動作するマウント の通知とリストの作成がそれぞれ別のサービスで動作し、それぞれのサービスの動作するタイミングによって発生します。

     

    ■ 回避策:

    先述の通り、本事象はタイミングの問題であるため、現時点 (2017/10) では、恒久的な改善策はございません。

    もっとも簡易な回避策といたしましては、ユーザー プロファイル ディスクの使用しない、もしくは、ファイルの削除には Shift + Delete による直接削除を使用するといったものとなります。

    もしくは、設定変更が伴う手順とはなりますが、以下の方法がございます。

    1. <%UserProfile%>\RECYCLE.BIN フォルダー の削除

    前述の通り、本事象は <%UserProfile%>\RECYCLE.BIN フォルダーのマウント時の権限によって発生いたします。
    一度、<%UserProfile%>\RECYCLE.BIN フォルダーを削除することで、次にファイルを削除したタイミングで 新しい $RECYCLE.BIN が作成されますので、事象が改善いたします。

    ユーザー権限での削除も可能ですが、事象発生時に各ユーザーに操作いただくことが難しい場合、ログオン時に毎回 <%UserProfile%>\RECYCLE.BIN フォルダーを削除するよう、ログオン スクリプトにて設定いただくこともご検討願います。
    ログオン スクリプトは以下のスクリプトをご利用ください。

    ===========
    rd /s /q %Userprofile%\$Recycle.bin
    rd /s /q %Userprofile%\Userdata\$Recycle.bin
    ===========

    UPD 内のごみ箱につきましては、「ユーザー プロファイル ディスクのデータ設定」に依存して保存箇所 (UPD のマウントポイント) が変化することから、削除するパスが 2 種類となります。
    ・ すべてのユーザー設定とデータをユーザープロファイル ディスクに格納する
    -> %UserProfile%\
    ・ 次のフォルダーのみをユーザー プロファイル ディスクに保存する
    -> %UserProfile%\userdata

    ただしこの場合、ごみ箱内のファイルがすべて削除されますので、ごみ箱に移動したファイルを戻すといった運用をされる可能性がある場合にはご注意願います。

    2. フォルダー リダイレクトを利用する

    本事象は、UPD 内のファイルを削除しようとする場合に発生いたします。そのため、UPD 外に保存されているデータは削除が可能です。
    これは、例えば C ドライブの情報であれば、 C ドライブ直下の $RECYCLE.BIN など、マウント ポイント直下に存在する $RECYCLE.BIN が使用されるためです。
    この動作を利用して、デスクトップやドキュメント、お気に入りなどをフォルダー リダイレクトを利用して UPD 以外の場所に保存させることで、事象が発生いたしません。
    フォルダー リダイレクトにつきましては、グループ ポリシーをご利用ください。

    参考: フォルダー リダイレクトの概要
    https://technet.microsoft.com/ja-jp/library/cc732275(v=ws.11).aspx

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

    0
    0

    こんにちは。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 秒間パケットの送受信ができないとハートビート通信の失敗が検知されますので、まずはネットワーク ベンダーへお問い合わせいただきパケットが 5 秒遅延するような状況でなかったか確認をしていただければと存じます。

     

    暫定的な対処

    もしイベント ID 1135 が頻発するような環境で、WAN 回線側で対処が難しい場合には、ハートビート通信の閾値を伸ばすことで暫定的な対処をとることが可能です。

    ハートビートの閾値は既定で 1 秒ごとに送受信されるパケットの失敗が連続で 5 (5 秒間) までとなっているので、この設定を 1 x 10 ( 10 秒間) 2 x 10 秒間 ( 20 秒間) など大きくしてください。

     

    以下、変更手順です。

     

    // Windows Server 2008, Windows Server 2008 R2

    ————————-

    ・コマンド プロンプトでの Cluster.exe コマンド

    ————————-

    1. 管理者権限でコマンド プロンプトを実行します。

     

    1. CrossSubnetDelay, CrossSubnetThreshold の値を確認します。

       > cluster /prop:CrossSubnetDelay

       > cluster /prop:CrossSubnetThreshold

     

    1. CrossSubnetDelay, CrossSubnetThreshold の値を変更します。

       (以下は例として、2 10 回で設定します。)

       > cluster /prop CrossSubnetDelay = 2000

       > cluster /prop CrossSubnetThreshold =10

     

    1. 再度 CrossSubnetDelay, CrossSubnetThreshold の値を確認し変更が反映されているか確認します。

       > cluster /prop:CrossSubnetDelay

       > cluster /prop:CrossSubnetThreshold

     

    ※コマンドで設定いただいた後に再起動は不要です。

     

    // Windows Server 2012 以降

    ————————-

    PowerShell コマンドレット

    ————————-

    1. 管理者権限で、Powershell を実行します。

     

    1. CrossSubnetDelay, CrossSubnetThreshold の値を確認します。

       PS C:\> Get-Cluster | fl CrossSubnetDelay, CrossSubnetThreshold

     

    1. CrossSubnetDelay, CrossSubnetThreshold の値を変更します。

       (以下は例として、2 10 回で設定します。)

       PS C:\> (Get-Cluster).CrossSubnetDelay = 2000

       PS C:\> (Get-Cluster).CrossSubnetThreshold = 10

     

    1. 再度 CrossSubnetDelay, CrossSubnetThreshold の値を確認し変更が反映されているか確認します。

       PS C:\> Get-Cluster | fl CrossSubnetDelay, CrossSubnetThreshold

     

    ※コマンドで設定いただいた後に再起動は不要です。

     

    <参考> ソース: FailoverClustering, イベント ID :1135, イベント ID :1177 が記録されクラスター サービスが停止してしまう

    https://blogs.technet.microsoft.com/askcorejp/2015/10/22/failoverclustering-id-1135-id-1177-124/

     

    最後に

    クラスター環境のハートビート通信の閾値はそれぞれ下記のとおりです。

     

    Parameter Win2012 R2 まで (既定値) Win2016 (既定値) 最大値
    SameSubnetDelay 1 second 1 second 2 seconds
    SameSubnetThreshold 5 heartbeats 10 heartbeats 120 heartbeats
    CrossSubnetDelay 1 second 1 seconds 4 seconds
    CrossSubnetThreshold 5 heartbeats 20 heartbeats 120 heartbeats
    CrossSiteDelay NA 1 second 4 seconds
    CrossSiteThreshold NA 20 heartbeats 120 heartbeats

     

    Windows Server 2016 ではハートビートの閾値が変更されています。

    お客様の環境 (Windows Server 2012 R2 以前) でハートビートの閾値変更時には、Windows Server 2016 の既定値を参考値としていただければと存じます。

     

    Windows Server 2012 R2 の環境で Hyper-V の役割がインストールされている場合や、KB3161606 が適用されている場合には既定値が変更され Windows Server 2016 と同じ値になっている可能性がございます。

     

    <参考> Clustering and High-Availability

    https://blogs.msdn.microsoft.com/clustering/2012/11/21/tuning-failover-cluster-network-thresholds/

     

    GPO で配布したタスクが Windows Vista、Windows Server 2008 で登録されない事象について

    0
    0

    こんにちは。
    Windows サポートの城野です。

    今回は、GPO を使用してタスクを配布しようとした際、Windows Vista および Windows Server 2008 に
    タスクが登録されない事象についてご紹介させていただきます

    1. 事象
    ———————————
    ドメイン環境で、以下の GPO を使用してタスクを配布しますと Windows Vista および Windows Server 2008
    に対して設定どおりタスクが登録されない事象が発生いたします。
    ただし、gpresult コマンドでポリシーの結果セットを見ても、GPO 自体は適用されていたりするため、
    一見タスクの設定の仕方に問題があったかのように見えたりします。

    – GPO の設定場所
    コンピューターの構成/基本設定/コントロールパネルの設定/タスク ※ DC が Windows Server 2012 以降の場合、”Windows Vista およびそれ以降” の表記が “Windows 7 以降” と表記されます。

    上記画像の通り、設定可能なタスクとして 4 種類 (本説明ではA,B,C,Dとします)の設定がありますが、Windows Vista
    および Windows Server 2008 においては A の “タスク” は正常に動作いたしますが A 以外の 3 種類のタスクは
    タスク スケジューラに登録されない事象が発生します。 (ただし B が登録されないのは、表記通りの正常な動作です)

    A. タスク
    ==> ○ (正常に動作します。)

    B. 即時タスク (Windows XP)
    ==> N/A (対象が Windows XP 用 のため動作いたしません。)

    C. タスク (Windows Vista およびそれ以降)
    ==> × (動作いたしません。)

    D. 即時タスク (Windows Vista およびそれ以降)
    ==> × (動作いたしません。)

    2. 本事象の発生要因
    ———————————
    本事象については Windows Vista および Windows Server 2008 の既知の
    不具合により発生いたします。

    具体的には GPO 更新時に、クライアント側はタスクの情報を取得しますが、ファイル内のタスクを
    登録する処理にて Task Scheduler 2.0 に関連する API が Windows Vista および Windows Server 2008 に
    実装されていないことに起因して C および D のタスクを 登録することができません。

    3. 対処法について
    ———————————
    本不具合に関しては修正プログラムのご用意がなく、回避策がございません。

    そのため Windows Vista および Windows Server 2008 でも利用可能な “タスク” をご利用いただくか、
    ログオンスクリプト等で schtasks コマンド (タスクを登録するコマンド) を実行するなど、代替の手段を
    ご検討いただければと存じます。

    プリンター ドライバーの設定により、イベント ログに印刷済みのページ数が 0 と記録される

    0
    0

    こんにちは。Windows サポートの鈴木です。

    プリント サーバーをお使いいただく目的の一つとして、「印刷のログを取得するため」を挙げるお客様が多くいらっしゃいます。
    今回は、印刷の完了を示す Event ID: 307 に正しくページ数が記録されない事象についてご紹介いたします。

    印刷が成功し、Event ID: 307 にジョブのバイト数が表示されているにもかかわらず、”印刷したページ数: 0″ と記録されることがあります。この場合、印刷時のプリンター ドライバーの設定で、内部的にドキュメントを画像として変換し印刷している可能性があります。

    この設定は、ドライバーの種類やメーカーにもよりますが “ラスター” や “ラスタライズ”、”ピクセル化” などと表示されている場合があります。

    この場合、印刷の処理の中で Windows が複数ページを認識できず、したがってページ数のカウントが 0 のままになることがあります。意図して上記のような設定を使用しない場合でも、透かしを入れたり、高画質化など、プリンター ドライバー内で画像処理を行うオプションを設定いただいた場合には、無意識のうちに本事象に遭遇する可能性もありますので、ご注意いただけますようお願いいたします。

    なお、本事象に合致する場合、表示されるページ数は常に “0” です。その他の数値になることはございません。

     

    (追記)
    既定の設定では、印刷の完了を示すイベントの記録は行われません。下記の手順を実施いただくことで、当該イベントの記録が開始されます。

    1. [Win] + [R] キーを押下し、“eventvwr.msc” と入力し [OK]をクリックします。
    2. [表示] メニューより、[分析およびデバッグ ログの表示] をクリックします。
    3. [アプリケーションとサービス ログ] – [Microsoft] – [Windows] と選択します。
    4. [PrintService] を展開し、[Operational] をクリックします。
    5. [操作] ペインより、[ログの有効化] をクリックします。

     

    イベント FailoverClustering 1230 について

    0
    0

    こんにちは。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 for resource ‘Disk01’.

     

    例えば、上記のようにクラスター ログからはディスク リソース ‘Disk01’ に対する LooksAlive がタイムアウトしたことが分かりますが、LooksAlive がタイムアウトした原因については判断することができず、別途調査が必要となります。

    一般的にディスク リソースの操作でタイムアウトが発生する原因としては、ウィルス対策ソフトなどのフィルター ドライバーによりディスクへの I/O が阻害される問題や、ストレージ側の高負荷により応答を返せない問題が多く報告されています。

    この場合、ウィルス対策ソフトを停止し事象の切り分けを行うことや、ストレージ側での事象発生時の負荷状況などを確認していただく必要がありますが、OS の観点からは事象発生時にメモリダンプを採取いただくことでタイムアウト発生時のメモリ情報からリソースへの操作が何の処理で待たされていたのか調査を進めることが可能です。

    ※ タイムアウトの一例としてディスク リソースを上げていますが、メモリダンプの調査はリソースの種類に依存せず有効です。

     

    以下、イベント ID 1230 が記録された時に自動でメモリダンプ採取を行う方法を紹介します。

    運用中の環境などでイベント ID 1230 が記録され再現性がある場合には、原因調査のために下記設定を行い事象再現時のメモリダンプを採取して弊社サポートまでお問い合わせいただくことをご検討ください。

     

    – イベント ID 1230 記録時に自動でメモリダンプを採取する方法

    メモリダンプの設定については、下記ブログをご参考ください。

    ※ メモリダンプの種類は完全メモリダンプを採取いただくことを推奨いたしますが、完全メモリダンプへの設定変更が難しい場合には、まずはカーネル メモリダンプの採取をお願いします。

     

    <参考> メモリ ダンプ ファイルを生成する方法について

    https://blogs.technet.microsoft.com/askcorejp/2014/08/10/339/

     

    < Windows Server 2008, Windows Server 2008 R2 >

    イベント ID 1230 が記録された際に、タスクから NotMyFault を実行し、ブルースクリーンを発生させメモリダンプを採取します。

    NotMyFault はマイクロソフトから提供しているブルースクリーンを強制的に発生させるツールです。

     

    NotMyFault によるメモリ ダンプ自動採取手順

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

    ※ 事前にメモリダンプの設定を確認します。

     

    1. NotMyFault ツールをダウンロードします。

    下記の URL より、NotMyFault.zip をダウンロードします。

     

    http://download.sysinternals.com/files/NotMyFault.zip

     

    2. ツールをサーバーに設置します。

    ダウンロードした Notmyfault.zip を解凍し、解凍したフォルダをメモリダンプ採取対象のサーバーの任意の場所 (D:\Notmyfault など) に配置します。

     

    3. イベント トリガーを設定します。

    以下の手順ではソース : Microsoft-Windows-FailoverClusteringID: 1230 のイベントの出力に対応して NotMyFault を自動で実行しブルー スクリーンを発生させます。

     

    a) イベント ビューアー からソース : Microsoft-Windows-FailoverClustering、ID : 1230″ を右クリックし、[このイベントにタスクを設定] をクリックします。

    b) [基本タスクの作成ウィザード] が起動します。

    c) [名前] [説明] を必要に応じて編集し、[次へ] をクリックします。

    d) [特定イベントのログへの記録時] [次へ] をクリックします。

    e) [操作] [プログラムの開始] を選択し [次へ] をクリックします。

    f) [プログラムの開始] [プログラム/スクリプト] [参照] をクリックし、解凍した Notmyfault フォルダから NotMyfault.exe を選択します。

     

    (例:32 bit OS 用パス)

    “D:\NotMyFault\NotMyfault.exe”

    Notmyfault D ドライブに置いた場合

    (例:64 bit OS 用パス)

    “D:\NotMyFault\NotMyfault64.exe”

    Notmyfault D ドライブに置いた場合

     

    g) [引数の追加] /AcceptEula /crash を入力して [次へ] をクリックします。

    h) [概要] で下記にチェックを入れ [完了] をクリックします。

    [完了] をクリックしたときに、このタスクの [プロパティ] ダイアログを開く

    i) 作成したタスクのプロパティで [全般] タブの [セキュリティ オプション] で下記にチェックを入れます。     

    □ユーザーがログオンしているかどうかにかかわらず実行する

    □最上位の特権で実行する

    k) タスクを実行するユーザー アカウントの情報を求められますので、ローカル管理者のアカウントの情報を入力します。

     

    4. NotMyFault を使用できるようにします。

    NotMyFault を使用するには初めにライセンス認証が必要なため、下記コマンドを実行いただきライセンスの認証画面が出力されたら、[Agree] を選択します。

     

    > NotMyfault.exe /?

     

    これで、ソース : Microsoft-Windows-FailoverClusteringID : 1230 が記録された際に NotMyFault が自動で実行され完全メモリダンプが取得されます。

     

    < Windows Server 2012 以降 >

    Windows Server 2012 以降では、クラスター リソースの DeadlockTimeout が検知されると自動でメモリダンプを出力させるレジストリ設定が備わっています。

    そのため以下のレジストリを設定し、イベント ID 1230 が記録された際のメモリダンプを採取します。

    ※ レジストリの設定はクラスターを組む全ノードで行い、変更後には再起動が必要です。

     

    タイムアウト発生時のメモリ ダンプ自動採取手順

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

    ※ 事前にメモリダンプの設定を確認します。

     

    1. 管理者権限のコマンド プロンプトを起動し regedit と入力し、[OK] を選択します。

    2. レジストリ エディタが起動しますので、次のレジストリ キーを見つけて選択します。

     

    <対象キー Windows Server 2012>

    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Failover Clusters\

    ※ Windows Server 2012 では下記 a) ~ d) を行い手順 3. に進みます。

    a) 対象キーを [右クリック] -> [アクセス許可] -> [詳細設定] を選択します。

    b) ダイアログ上部に記載されている [所有者] 欄の [変更] を選択します。

    c) 変更を行うユーザーまたはグループを指定します。

    d) 変更を行うユーザーまたはグループのフルコントロール権限を追加します。

     

    <対象キー Windows Server 2012 R2, Windows Server 2016>

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ClusSvc\Parameters\

     

    3. [編集] メニューの [新規] をポイントし、[DWORD ] をクリックします。

    4. DebugBreakOnDeadlock と入力し、Enter キーを押します。

    5. [編集] メニューの [修正] をクリックします。

    6. [値のデータ] [3] を入力して [OK] を選択します。

    Unified Write Filter (UWF) 環境での運用を考慮した設定について

    0
    0

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

    今回は統合書き込みフィルター (Unified Write Filter (UWF)) の環境を運用する場合に、考慮すべき設定についてご紹介します。

    Unified Write Filter (UWF) とは Windows 10 にて新しく利用できるようになったディスクへの書き込み処理をメモリ上のオーバーレイという一時領域に行う機能です。 UWF を有効化することで、物理デバイスへの書き込みを少なくすることでデバイスの摩耗を低減したり、再起動ごとに必ず UWF の設定に基づいてオーバーレイ領域のデータを削除 (設定時の状態に戻す) する事で、ユーザーが保存したファイルなどで意図せずディスク容量を使用しないようにする事ができます。 本機能は Windows Embedded (組み込み向け) の機能として実装されておりましたが、Windows 10 でも利用できるようになったことにより、最近では OA PC などの用途にもご利用を検討いただくことが多くなっています。 本機能の概要や設定方法については、以下にブログがございますので、ご参照ください。

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

    上述の通り UWF 環境では、OS 動作中に実施されたオーバーレイ領域への書き込み処理は、すべてシャットダウン時に破棄されます。 次回起動時は UWF を設定したときの状態で起動しますが、 サービスによっては UWF 環境下でも再起動後にも保持されている必要がある情報や、保持されていると利便性が高い情報があります。 そのため、UWF では書き込みフィルターの除外設定を行うことで個別にファイルやフォルダ、レジストリの情報を保持することが可能です。 UWF 環境を運用する際に除外設定や事前に設定を行う必要がある項目についてはいくつか公開情報がございますが、本ブログではそれらの各公開情報をおまとめすると共に、そのほかの留意事項や良くお問合せいただく設定情報についてご紹介いたしますので、UWF 環境の運用を検討する場合に参考にしていただけますと幸いです。

     


    公開情報


     

     

     

     


    よくあるお問い合わせ


    (1) StartComponentCleanup タスクの無効化もしくは除外設定

    システム メンテナンスを目的とするタスクのひとつに “StartComponentCleanup” と呼ばれるタスクがあります。 本タスクは不要なドライバーや Windows Update で更新されて使わなくなった古いコンポーネントを削除したり圧縮したりするタスクです。 本タスクが行った書き込み処理も再起動で破棄されるため、再起動ごとに本タスクが実行され、オーバーレイや CPU を消費してしまう事象が報告されております。 Windows Update を定期的に実行いただく運用など、定期的にドライバーのアップデートが実施される環境で本事象が発生します。

    対処策: 以下のいずれかの対処により本事象を回避できます。
    1. “StartComponentCleanup” タスクの無効化
    UWF が無効化された状態で、タスク スケジューラーから、以下のタスクを右クリックで “無効” にした後、再度 UWF を有効化します。

    パス: [システムツール] – [タスク スケジューラ] – [タスク スケジューラ ライブラリ] – [Microsoft] – [Windows] – [Servicing]
    タスク: StartComponentCleanup

    2. “StartComponentCleanup” タスクで利用されるフォルダ・レジストリの除外設定
    以下の領域を除外設定に追加します。

    // フォルダ

    C:\Windows\Winsxs
    C:\Windows\servicing

    // ログ

    C:\Windows\Logs\CBS
    C:\Windows\Logs\DISM
    C:\Windows\System32\winevt\Logs\Setup.evtx

    // レジストリ

    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing
    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide
    HKLM\COMPONENTS\CanonicalData
    HKLM\COMPONENTS\ccpinterface
    HKLM\COMPONENTS\DerivedData
    HKLM\COMPONENTS\Drivers
    HKLM\COMPONENTS\Installers
    HKLM\COMPONENTS\NonCanonicalData
    HKLM\COMPONENTS\ServicingStackVersions
    HKLM\COMPONENTS\TransformerRollbackData

    (2)ドメイン ユーザーのキャッシュ ログオン

    ドメイン コントローラーに一時的に接続できない状況が発生する環境など、キャッシュでのログオンが必要な環境では、キャッシュを残せるようレジストリの除外設定が必要です。

    対処策:
    以下のレジストリを除外設定に追加します。

    HKLM\SECURITY\Cache

    (3) ディスプレイ設定の保存

    最近使用されたトポロジ (複製、拡張など) や解像度、向きなど、ディスプレイの設定は再起動後も残したい環境では、関連するレジストリの除外設定が必要です。

    対処策:
    以下のレジストリを除外設定に追加します。

    HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\Configuration
    HKLM\System\CurrentControlSet\Control\GraphicsDrivers\Connectivity

     


    留意事項


    また、除外設定を行っている領域に書き込みを行った場合についても、オーバーレイのメモリは利用されます。 詳細は以下のブログで公開しております。 また、イベント ログなど通常運用でも書き込みを行う処理でオーバーレイを消費することは避けられませんので、UWF 環境の運用にあたっては適切な間隔で再起動を行うことをご検討ください。

    Windows 10 の統合書き込みフィルター機能 (UWF) で、フィルターの除外設定を行ってもオーバーレイのメモリを消費してしまう

     

    なお、UWF 機能として、内部的に既定で除外設定が行われているファイル、フォルダやレジストリもありますが、それらの内部設定は公開されておらず、今後変更される可能性がございます。 本情報は現時点で有用と考えられる除外設定についてまとめました。 本情報がみなさまのお役に立てれば幸いです。


    Windows 10 で UWF (Unified Write Filter) とグループ ポリシーによるデバイスのインストール制限を併用する場合の動作について

    0
    0

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

    この記事では、 Windows 10 で UWF (Unified Write Filter) とグループ ポリシーによるデバイスのインストール制限を併用する場合に発生する事象についてご案内します。

     

    事象

    グループ ポリシーでデバイスのインストール制限を有効にした状態で、UWF のフィルターでドライブの保護を有効にすると、以下のような事象が発生します。

    ・フィルター除外を設定したフォルダーを開こうとすると、「<アクセスしたフォルダー> は利用できません。」というエラー メッセージが表示される。
    ・UWF 関連の処理 (uwfmgr コマンドの実行など) に非常に時間がかかる。

     

    (グループ ポリシーでデバイスのインストール制限を実施する設定例)

    以下の設定と、許可または禁止するデバイスの設定を組み合わせて適用します。

    項目:[コンピューターの構成] – [管理用テンプレート] – [システム] – [デバイスのインストール] – [デバイスのインストール制限]
    設定:[他のポリシーで記述されていないデバイスのインストールを禁止する] を [有効]

     

    発生理由

    これは想定された動作です。
    UWF によるフィルター除外設定やコミット処理などの変更を一時的に保存するため、Windows では仮想ボリュームを使用しますが、グループ ポリシーでデバイスのインストール制限を有効にしている場合、仮想ボリュームのインストールが制限されるため、上記のような動作となります。
    この事象が発生する場合、システム イベント ログに以下の ID 20005 の UserPnp イベントが記録されます。

    (記録されるイベントの例)
    情報 xxxx/xx/xx xx:xx:xx UserPnp 20005 (7005)
    デバイスのインストールの制限ポリシー設定により、ドライバー管理が、デバイス インスタンス ID STORAGE\VOLUME\x&xxxxxxxx&x&-x のインストールを制限しました。

     

    回避策

    上記の通り、上記動作は想定されたものであり、現時点で回避策はございません。

     

    参考情報: Universal Write Filter について
    Unified Write Filter (UWF) feature
    https://docs.microsoft.com/en-us/windows-hardware/customize/enterprise/unified-write-filter

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

    0
    0

    こんにちは、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 で触れたいと思います。

     

    2. Windows Server 2012 以降で追加されたデフラグ コマンドの機能

    Windows server 2012 のデフラグ機能には大幅な機能強化と変更点があります。その影響で以下のオプションが追加されています。

           /D     従来の最適化を実行します (これが既定値です)。
           /K     指定したボリュームに対してスラブ統合を実行します。
           /L     指定したボリュームに対してトリムを再実行します。
           /O     各メディア タイプに適した最適化を実行します。

    さらに、Windows Server 2012 R2 では以下のオプションが追加になりました。

           /G    指定したボリュームの記憶域階層を最適化します。

    Windows Server 2012 以降では、ディスクの種類 (メディア タイプ) ごとに適切なストレージの最適化を行えるように考慮された設計となっています。近年はストレージも仮想化が進み、複数のサーバーで 1 台のストレージ装置を共用すること多くあります。そのような環境では、シンプロビジョニングというプロビジョニング方式によりディスクを割り当てることがあります。シンプロビジョニングとは、ストレージの仮想化を行う技術のひとつで、OS に割り当てられたディスク容量のうち、実際に利用している容量のみの物理ストレージを割り当てることで、全体の物理ストレージを効率よく利用するためのディスクの割り当て方法です。また、Windows Server OS としても、”記憶域スペース″ という機能により、ストレージの仮想化を行うための “記憶域” を作成することができます。このメディア タイプは管理ツールのドライブのデフラグと最適化 (GUI) の “メディアの種類” という項目から確認することができ、ハード ディスクやシンプロビジョニング対応ドライブ、記憶域などの種類があります。

    /K /L のオプションはシンプロビジョニング対応ドライブに対して実行可能なオプションです。通常のハード ディスクを指定しても、エラーとなり実行されません。また、/K で指定するスラブ統合の処理には /L で指定するトリムも含まれます。

    /O オプションはメディア タイプに応じてストレージの最適化を行います。メディア タイプがハード ディスクの場合は /D オプション、シンプロビジョニング対応ドライブでは /K および /L オプションなど、デフラグ ツールが実行対象のドライブのメディア タイプを内部的に判断し、そのメディア タイプで実行可能なすべてのデフラグのオプションを指定して実行します。

    スラブの統合やトリムなどのストレージ最適化については、トピックが長くなりますので本ブログでは触れませんが、詳細は以下をご参照ください。

    Optimizing Windows Server 2012 storage management via PowerShell for both performance and resiliency

    また、/G オプションは記憶域階層の最適化を行うオプションです。Windows Server 2012 R2 の新機能として追加された SSD やハード ディスク ドライブを組み合わせたストレージ プールの記憶域階層についての詳細も以下をご参照ください。

    Storage Spaces Overview

    Storage Spaces: How to configure Storage Tiers with Windows Server 2012 R2 

    What’s New in Storage Spaces in Windows Server 2012 R2

     

    3. “従来のデフラグ” が必要かどうかの判断方法

    ここで冒頭の質問に戻ります。結論から述べると、”従来のデフラグ”  の必要性は環境や使用状況に依存します。
    デフラグはパフォーマンスに深刻な問題がある場合は必要ですが、それ以外は時間やリソースを利用する割に、効果が得られず、割にありません。また、パフォーマンスが悪い原因はファイルの断片化だけではありません。例えば、ボリュームに断片化した多くのファイルがあっても、あまり頻繁にアクセスされていない場合は、パフォーマンスに影響をほとんど与えないと考えられます。デフラグが必要かどうかを判断するためには、断片化に比例して、徐々にパフォーマンスを遅くなっているかを定常的に確認する必要があります。また、断片化が問題と判断した場合でも、デフラグを長時間実行することや全体的なコスト(CPU などのシステム リソース) を踏まえ、どれだけ効果的かの検証が必要です。

    デフラグ前に Sysinternal ツールの Contig.exe で断片化のレベル チェックができます。
    Contig v1.8
    以下が出力例です。

    この例の場合、空き領域が 13,486 に断片化 (Free space fragments) されていますが、デフラグは必要ないと言えます。
    理由は C ドライブには約 96 GB の空き領域があり、最も大きい連続した空き領域 (Largest free space block) は約 54 GB あることから、データはディスク全体に分散していないので、I/O 処理は滞ることはなく、デフラグをしても有効性はありません。

    基本的には、バックアップなどの VSS を使用するアプリケーションが Diff Area のための連続した空き領域を確保できないことが原因で失敗した場合など、”従来のデフラグ” の必要性ができたタイミングに手動でデフラグを実行することを推奨します。バックアップの失敗がシステムに大きな影響を与える場合や、継続的に同じ理由で失敗する場合以外は、スケジュールで “従来のデフラグ” を実行することは推奨しません。

     

    4. 自動メンテナンス タスクで定期的に実行されるデフラグ

    Windows のバージョンごとの既定でスケジューリングされたデフラグ タスクは以下の通りです。なお、”-c” は “/C” と同じオプション指定です。

    Windows Server 2008R2: defrag.exe –c
    Windows Server 2012: defrag.exe –c –h –k
    Windows Server 2012 R2 / 2016: defrag.exe –c –h –k –g
    クライアント OS: defrag.exe –c –h –o

    Windows Server 2008 R2 では、ストレージの特性 (SCSI ディスク / RAID / シンプロビジョニング対応ドライブ等) は考慮されず、すべてのボリュームに対して “従来のデフラグ” を行っていました。一方、Windows server 2012  / 2012 R2 以降では、”通常” の優先度レベル (既定は “低” ) ですべてのボリュームのスラブ統合 (/K オプション) や記憶域階層の最適化 (/G オプション) を行います。つまり、これらのオプションに対応していないハード ディスクに対してはなにも処理が実行されません。

    なお、クライアント OS では /O オプションが指定されており、ハード ディスクには “従来のデフラグ” が実行されるようになっています。

     

    5. ドライブのデフラグと最適化 (GUI) からのデフラグ

    デフラグの GUI ツールである “ドライブのデフラグと最適化” (dfrgui.exe) から実施する [分析] ボタンと [最適化] ボタンの挙動について紹介します。

    [分析] ボタン: デフラグ コマンドの /A オプションと同等の処理が実行されます。
    [最適化] ボタン: デフラグ コマンドの /O オプションと同等の処理が実行されます。

     

    6. 手動で “従来のデフラグ” を実施する方法

    先述のとおり、従来のデフラグは多くの環境に実行する必要がないものとなっています。特に SSD やシンプロビジョニング対応ドライブなどはファイルの断片化がパフォーマンスに影響を与えることがないため、GUI ツールの操作から従来の最適化を実施することができなくなっています。また、先述の通り、Server OS では通常のハード ディスクであっても、OS による自動メンテナンス タスク内で “従来のデフラグ” が行われないよう、設計が変更されております。

    そのため、Windows Server 2012 以降、SSD やシンプロビジョニング対応ドライブに対し、連続した空き領域の確保の目的など手動で “従来のデフラグ” を実行する必要がある場合は、defrag コマンドの /D オプションを明示的に指定し、デフラグを実行する必要があります。

    また、/O オプションを指定することで、デフラグ ツール内でメディアのタイプ (ハード ディスクやシンプロビジョニング対応ドライブ) を自動的に判断するため、通常のハード ディスクにのみ “従来のデフラグ” を実行したい場合には、/O オプションをご利用ください。

     

    7. 仮想環境でのデフラグ

    最後に、Hyper-V などの仮想マシン内の OS のデフラグについて、少しだけ触れたいと思います。

    基本的には、物理環境と同じように “従来のデフラグ” は必要ありません。仮想ディスク ファイル (Hyper-V では VHD/VHDX) 内で仮想マシン OS は同じような動作をし、仮想ディスク自体の内部にファイルの断片化が発生します。連続した空き領域を確保できないためにバックアップが失敗するなどの理由がある場合にのみ、実施を検討してください。なお、Hyper-V 環境の仮想ディスクは容量固定であっても、仮想マシン内部 OS からはシンプロビジョニング対応ドライブと認識されます。そのほかの仮想環境では、メディアの種類を GUI ツールから確認してください。

    仮想環境でのデフラグについて、以下にフォーラムで議論された内容をまとめた情報が公開されておりますので、こちらをご参照ください。

    Hyper-V: Defragmentation

     

    [参考資料]

    Windows Server 2012 以降の OS でイベント ログに、エラー Microsoft-Windows-Defrag ID:257 (0x8900002D) が記録される

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

    Windows 10 Fall Creators Update 適用後にプリンターの双方向サポートが無効になる

    0
    0

    こんにちは、Windows プラットフォーム サポートの永岡です。
    Windows10 Fall Creators Update 後にプリンターの “双方向サポートを有効にする” チェックが外れる場合があるとのお問合せを複数いただいております。

    本動作につきましては、Windows10 Fall Creators Update (1709) へアップデートを行ったことにより以下のレジストリ キーの書き換えが行われることで、”双方向サポートを有効にする” のチェックが外れる事が要因となります。

    キー : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers
    サブ キー : プリンター名
    名前 : Attributes
    種類 : REG_DWORD

    回避策は、1709 への Update 後にプリンターのプロパティ画面より手動で “双方向サポートを有効にする” のチェックを有効化していただくことが必要となります。

    1. スタートメニューをクリックします。
    2. 歯車アイコン (設定) をクリックします。
    3. “デバイス” をクリックします。
    4. “Bluetooth とその他デバイス” をクリックします。
    5. “デバイスとプリンター” をクリックします。
    6. ご利用のプリンターアイコンを右クリックします。
    7. “プリンターのプロパティ” をクリックします。
    8. “ポート” タブより “双方向サポートを有効にする” を有効化します。
    9. “OK” で画面を閉じます。

    なお、Attributes の値は、Update 後に変更が行われることが弊社環境にて確認を行っておりますが、ご利用環境により値は異なるためレジストリによる回避はお勧めいたしません。
    そのため、プリンターのプロパティ画面からの設定変更による回避をご検討いただければ存じます。

    また、以下の公開サイトにアップグレードにてアプリケーションや設定が移行されない場合がある旨を公開させていただいております。

    Title : Windows 10 の仕様とシステム要件
    URL : https://www.microsoft.com/ja-jp/windows/windows-10-specifications

    –該当箇所抜粋–
    アップグレードと同時に多数のアプリケーション、ファイル、設定が移行されますが、一部のアプリケーションや設定が移行されない場合があります。

    1709 などの大型アップデートは Windows のアップグレードに相当する機能変更となるため、アプリケーションや設定の引継ぎが行われない場合がございます。
    ほとんどの設定は引き継がれますが、引き継がれていない設定につきましては、改めて設定を行うことが基本的な回避策となります。
    大型アップデートを行う際はあらかじめご留意くださいますようお願い申し上げます。

    オフラインパッケージの入手方法およびストアアプリのインストール手順について

    0
    0

    こんにちは。Windows プラットフォーム サポートの三田です。
    Windows 8 から登場した ”ストアアプリ” ですが、通常 Microsoft ストア (旧 Windows ストア) からお好みのアプリをユーザーの任意に入手できて大変便利です。
    一方で、なかには、ドメイン環境で共用の端末としてユーザーに利用させていたり、あるいは、端末そのものがオフライン環境での利用を想定されていたりなど、Microsoft ストアが利用できず、Microsoft ストア経由では入手できないといったケースもあるのではないかと思います。

    今回はそういった状況下でもストアアプリを入手されたいといったご要望を実現するために、ビジネス向け Microsoft ストア経由でストアアプリのオフラインパッケージを入手する方法とそのインストール手順についてご紹介したいと思います。

    =============================
    オフラインパッケージの入手方法
    =============================

    1. https://www.microsoft.com/ja-jp/business-store/ にアクセスし、[サインアップ/サインイン] をクリックします。

    2. [職場のメールアドレスをお持ちではありませんか?] をクリックします。

    3. 各項目を入力していきます。

    4. 電話、もしくはメッセージで認証コードを取得し、入力します。電話は日本語音声になります。

    5. 最後にサービス規約に同意をします。これでアカウント作成は完了です。

    6. [管理] タブをクリックします。

    7. 左ペインから[設定]をクリックします。

    8. “オフライン アプリを表示する” をオンにします。

    9. “電卓” を検索し、”Windows 電卓” のページに移動したら、ライセンスの種類を [オフライン] を選択し、[アプリを取得] をクリックします。

    10. プラットフォーム、最小バージョン、アーキテクチャなどを環境に合わせて選択いたします。
    ここでは、以下のような構成を想定してご案内します。

    プラットフォーム: Windows 10 デスクトップ
    最小バージョン: 1703
    アーキテクチャ: x64

    11. [オフラインで使用するパッケージのダウンロード] から、AppxBundle 形式のパッケージファイルをダウンロードします。

    12. [アプリのライセンスを取得する] から、”エンコードされていないライセンス”を選択し、ライセンスファイルをダウンロードします。

    13. [必要なフレームワーク] から、依存ファイルをダウンロードします。Windows 電卓の場合は、依存ファイルとして、以下の VClibs ファイルがあるため、今回の環境である x64 版の VCLis ファイルをダウンロードします。

    ====================================================
    オフラインパッケージを用いたストアアプリのインストール方法
    ====================================================

    以降の手順は以下のファイル群を基に記載いたします。
    (x64ベースとなります)
    フォルダー
    C:\temp\Calculator

    2017/11/12 16:32 753,600 Microsoft.VCLibs.140.00_14.0.25426.0_x64__8wekyb3d8bbwe.Appx
    2017/11/12 16:32 8,929,511 Microsoft.WindowsCalculator_2017.928.0.0_neutral_~_8wekyb3d8bbwe.AppxBundle
    2017/11/12 16:32 2,682 Microsoft.WindowsCalculator_8wekyb3d8bbwe_68bc3251-2d8b-a604-92ba-893638ca72ea.xml

    1. Powershell のコマンドプロンプトを [管理者として実行] から起動します。
    2. 以下のコマンドを実行します。(記載時とパッケージのバージョンが異なる場合があります)
    ※ 以下は、Store for Business 経由でダウンロードしてきたファイル群を C:\temp\Calculator に
    モジュールを置いてることを想定しておりますが、お問い合わせの環境に応じて適宜
    読み替えていただければと思います。
    ※ 見やすくするために改行していますが、実際には 1 行になります

    Add-AppxProvisionedPackage -Online
    -PackagePath “C:\temp\Calculator\Microsoft.WindowsCalculator_2017.928.0.0_neutral_~_8wekyb3d8bbwe.AppxBundle”
    -DependencyPackagepath “C:\temp\Calculator\Microsoft.VCLibs.140.00_14.0.25426.0_x64__8wekyb3d8bbwe.Appx”
    -LicensePath “C:\temp\CalculatorMicrosoft.WindowsCalculator_8wekyb3d8bbwe_68bc3251-2d8b-a604-92ba-893638ca72ea.xml”

    3. 新規ユーザーでログインすると、スタート一覧にアプリのアイコンが表示されます。

    *注意点*
    (1) オフラインパッケージの用意がないアプリもあります
    (2) アプリによっては、用意されていないプラットフォーム、アーキテクチャがあります

    [補足]
    上記手順によって、端末自体にプリインストールされているアプリ群 (プロビジョニング パッケージ) に任意のストアアプリをインストール可能ですが、ユーザー毎にストアアプリをインストールされたい場合は以下のコマンドを実行することで実現できます。

    Add-AppxPackage
    -Path “C:\temp\Calculator\Microsoft.WindowsCalculator_2017.928.0.0_neutral_~_8wekyb3d8bbwe.AppxBundle”
    -DependencyPath “C:\temp\Calculator\Microsoft.VCLibs.140.00_14.0.25426.0_x64__8wekyb3d8bbwe.Appx”

    差分更新プログラム適用後「インストールされた更新プログラムの一覧」に、同じ KB 番号が 2 つ表示される現象について

    0
    0

    こんにちは。Windows Platform サポートチームです。

    Windows Server 2016 及び Windows 10 のバージョン 1607 (Anniversary Update)、1703 (Creators Updatre) では、非 WSUS 環境向けに、Windows カタログサイトよりダウンロードいただける、差分更新プログラムを配信しております。
    差分更新プログラムを適用すると、累積更新プログラムを適用するよりも、クライアントが更新に要する時間が大幅に短縮されます。

    差分更新プログラムをインストールした後に、コントロールパネルのプログラムと機能からご確認いただける「インストールされた更新プログラム」の一覧に、インストールしたサポート技術情報番号 (KB 番号) のプログラムが 2 つ表示されます。

    これは、OS側及び更新プログラムの仕組みに起因して発生する現象で、正常な状態です。
    そのため、いずれのプログラムについてもアンインストールされないよう、お願いいたします。

    「インストールされた更新プログラム」の一覧に「更新プログラムID」を表示させる (※) ことで、それぞれ別のプログラムであることを確認いただけます。
    ※一覧の列タイトルを右クリックし、その他を選択し表示される「詳細表示の設定」画面より「更新プログラムID」にチェックを入れると表示されます。

    なお、差分更新プログラムをアンインストールする際には、Package_for_RollupFix、Package_for_RollupFix_Wrapper の順番で、同じサポート技術情報番号のエントリを 2 つともアンインストールしてください。

    なお、Windows 10 のバージョン 1709 (Fall Creators Update) では、この現象は発生しません。

    [参考情報]
    Monthly Delta update ISV support without WSUS

    セッション ホストサーバーにローカル アカウントでログオンすると “利用できるリモートデスクトップライセンスサーバーがありません”との警告が表示される

    0
    0

    こんにちは。
    Windows サポートの城野です。

    今回は、セッション ホストサーバーにローカル アカウントでログオンした際に、
    RD ライセンス サーバーに関する警告メッセージが表示される事象についてご説明させていただきます。

    1. 現象について
    ———————————–
    RD セッション ホスト サーバーから RD ライセンス サーバーの指定や、RD ライセンス サーバーのアクティブ化、CAL のインストールなど
    一通り完了している環境にて、RD セッション ホスト サーバーにローカル アカウントでログオンした場合に、以下の警告メッセージが
    通知領域に表示される事があります。

    通知領域に表示される警告メッセージ

    ただし、ドメイン アカウントでログインした際には、事象が発生しないため、
    RD ライセンス サーバーの指定に誤りがあるのかどうか判断がつかなかったりします。

    ではなぜこのようなことが起きるのか、その理由については次の [原因について] にて説明させていただきます。

    2. 原因について
    ———————————–
    RD セッション ホスト サーバーにログオンした際、RD セッション ホスト サーバーは RD ライセンス サーバーに対して、
    ライセンス情報の更新の為に SMB プロトコルを使用し、接続を行います。SMB プロトコルでは、動作上資格情報
    を必要とする為、RD セッション ホスト サーバーに対してログオンした際のユーザー アカウントの資格情報をもって、
    RD ライセンス サーバーに接続を行います。

    この際、RD セッション ホスト サーバーにログオンしたユーザーがローカル アカウントであったり、ドメインの構成(信頼関係のないドメインにまたがっている場合 等) によっては、RD ライセンス サーバーに接続の際、該当のユーザー アカウントでの認証を行うことが出来ず、表題の警告メッセージが表示されます。

    3. 対処の必要性について
    ———————————–
    ドメイン アカウントでログオンした場合に事象が発生しない場合には、上記のシナリオに合致し想定された動作となりますので、
    基本的に設定変更などを行う必要はありません。

    実際にローカル アカウントとは関係なく、RD ライセンス サーバーの検出に問題が発生していないかどうかはドメインの管理者
    アカウントで RD セッション ホスト サーバーにログインし以下の手順を実行することで確認いただく事が可能です。

    1. RD セッション ホスト サーバーにドメインの管理者ユーザーでログオンします。
    2. 左下にカーソルを合わせ [スタート] – [管理ツール] – [リモート デスクトップ サービス] と展開します。
    3. [RD ライセンス診断機能] を起動します。

    [リモートデスクトップ サービス RD ライセンス サーバー情報] 欄において、対象の RD ライセンス サーバー名 が
    表示されており、また [RD ライセンス診断情報] にて問題が検出されていない場合には、今回ご説明させていただいた
    事象とご判断いただき、表題のエラーメッセージは無視していただいて問題ありません。

    ただし、ドメインの管理者アカウントでログオンしても事象が発生する場合には、RD ライセンス診断機能に表示される
    警告やエラー メッセージおよび推奨される解決策をご確認いただいたうえで対処願います。

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

    TPM をクリアする方法

    0
    0

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

    本日は TPM (Trusted Platform Module) をクリアする方法についてご紹介いたします。

    TPM は通常マザーボードに取り付けられているセキュリティチップです。
    TPM のロックアウトをリセットや TPM の所有者情報の再設定など、TPM を初期化する場合は TPM をクリアします。

    TPM をクリアした場合、TPM を利用している機能やアプリケーションに影響を及ぼす可能性がございます。
    そのため、ご利用いただいている機能ごとに TPM をクリアする際に実施すべき手順があるかどうか確認した上で TPM のクリアをご実施ください。
    また、サード パーティー製のアプリケーションをお使いいただいている場合は、アプリケーションの提供元にご確認ください。

    ■ TPM をクリアする手順
    1. お使いのシステムで TPM を利用している機能があるかどうか確認します。

    TPM の推奨事項 (※ “TPM と Windows の機能” をご参照ください。)
    https://technet.microsoft.com/ja-jp/library/mt604232(v=vs.85).aspx

    2. それぞれの機能、アプリケーションごとに TPM をクリアする前後で実施すべき手順を確認します。

    – Windows の機能
    ※ 現在記載がない機能につきましては、随時、更新してまいります。
    ※ 空欄 (-) は実施すべき手順のない機能です。

    機能 TPM をクリア時に実施する手順 TPM をクリアした後に実施する操作
    BitLocker BitLocker の保護を中断します。 BitLocker の保護を再開します。
    Windows Hello
    Windows Hello For Business and Azure Active Directory (Passport: ドメイン AADJ への参加) Azure Active Directory から切断します。 Azure Active Directory に参加します。
    Windows Hello (and Microsoft Accounts (MSA)) (Passport: MSA またはローカル アカウント) PIN コードを再設定します。
    Credential Guard 資格情報を再入力します。
    Shielded VM

    3. 手順 2 で確認した内容をもとに下記手順を実施します。

    3-1. それぞれの機能、アプリケーションごとに確認した “TPM をクリアする前に実施する手順” を行います。
    3-2. [ファイル名を指定して実行] で “tpm.msc” を入力し TPM 管理コンソール画面を起動します。
    3-3. “TPM をクリア” ボタンをクリックします。

    3-4. 画面に従ってコンピューターを再起動します。
    3-5. ほとんどのコンピューターでは次回起動時にハードウェア側の画面が表示されますので、画面に従って TPM クリアを実行します。
    3-6. それぞれの機能、アプリケーションごとに確認した ”TPM をクリアした後に実施する手順” を行います。


    Windows 10 の機能アップデート後、USB 接続のプリンターが削除される

    0
    0

    ※ この記事の動作は、Windows 10 Version 1709 (Fall Creators Update) 以降には該当いたしません。Windows 10 Version 1709 で本動作が改善され、プリンターが引き継がれるようになりました。

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

    Windows 10 の機能アップデート (ビルド番号が上がる大型アップデート) の後に USB 接続のプリンターが削除されているというお問い合わせをいただいております。

    Windows 10 Version 1703 までの機能アップデートでは、USB 接続のプリンターは Windows の更新を行う一連のプロセスの中で削除されます。
    プリンター ドライバーは新しいバージョンの Windows に引き継がれるため、プリンターがコンピューターに接続されており電源が入っている場合は、アップグレードの完了後初回起動時に再度プラグ アンド プレイにより認識し [デバイスとプリンター] 画面にアイコンが作成されます。

    しかしながら、この場合でもカスタムしていた印刷設定や適用するプリンター ドライバーを変更していた場合には設定が既定値に戻ります。また、更新中にプリンターが接続されていなかった場合には、Windows がプリンターを認識するまでプリンター アイコンは作成されません。

    大変恐れ入りますが、この動作は Windows 10 Version 1703 までの Windows 10 の仕様であり、現時点で変更される予定はありません。お手数をおかけいたしますが、実施いただいていた印刷設定等は機能アップデートの完了後に再度設定いただく必要がございます。

    なお、更新前のバージョンに関わらず、Windows 10 Version 1709 (Fall Creators Update) への更新の場合は設定も含めプリンター アイコンが自動的に移行されます。可能な限り、最新の Windows 10 をお使いいただくことをお勧めいたします。

    Windows 10 のスタート画面から一部のタイルが削除される

    0
    0

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

    今回は Windows 10 のスタート画面に表示されるタイルの配置に関する不具合についてお知らせします。

    Windows 10 Version 1709 (Fall Creators Update) において、PC を初回起動した時に表示される最初のセットアップ画面(Windows Out of Box Experience (OOBE) と言います)を終了してデスクトップ画面に移った後、スタート画面を確認すると、幾つかのアプリのタイルがスタート画面に表示されない場合があります。(実際にはスタート画面にピン留めされていないだけで、[すべてのアプリ] ビューからは利用できます。)また、PC のリセットを実行した場合も同様に発生する場合があります。

    以下は、本来の既定の構成で表示されるべき正常なスタート画面の例です。(この画面では下向きの矢印のタイルが表示されていますが、これらのタイルはネットワークに接続すると自動的に適切なイメージに更新されます。)

     

    一方、この問題が発生すると以下のようなスタート画面になります。

    幾つかのタイルが削除されており、配置も変更されて異なるグループに移動していることが分かります。

     

    この問題は、タイミングによってスタート画面のレイアウトの初期化が行われるよりも前に、SYSTEM アカウントのタスクからスタート画面にピン留めされたタイルを調べるタスクが実行されてしまうことに起因して発生します。

    タイミング的な問題であるため、この現象を回避する有効な手段はありませんが、比較的スペックの高い PC では発生頻度が低いことが分かっています。

    なお、この問題は次期の Windows 10 バージョン(2018年春頃)で修正を予定しています。

     

    11 月の更新プログラム適用後、Epson 社製プリンターでの印刷に失敗する事象について

    0
    0

    11 月の更新プログラムを適用すると、Epson 社製プリンターでの印刷に失敗する事象を確認しており、現在、マイクロソフトは、本事象の対策版のリリースに向け全力を尽くしております。一部の Windows に対しては、対策版の更新プログラムをリリースしております。(詳細は後述しております。)

    本ブログは、11 月の更新プログラムにより発生する問題に対して、タイムリーに情報を発信することを目的としています。
    そのため、掲載内容は、随時更新いたしますことご理解をいただけますようお願いいたします。

    • 原因

    11 月のセキュリティ更新プログラムには、GDI と呼ばれる Windows での描画処理を主に担当するモジュールに対し、セキュリティ上の脆弱性を解消する変更が含まれております。
    この変更が影響し、Epson 社製のプリンター ドライバーの実装に依存して印刷の開始に必要な内部の処理が失敗することが原因で発生することを確認しております。
    現時点では不特定多数のプリンターで発生するという情報はありません。広範囲に発生する事象ではないと判断しております。

    • 回避策

    現在、本問題に対して影響を受ける Windows に対して、対策版更新プログラムを随時リリースしております。

    ※2017/11/22 09:00 時点の対策版更新プログラムのリリース状況になります。

    OS バージョン 種別 11 月の更新プログラム 対策版更新プログラム
    Windows 10 1709 https://support.microsoft.com/ja-jp/help/4048955/ リリース準備を進めています。
    Windows 10 1703 https://support.microsoft.com/ja-jp/help/4048954/ リリース準備を進めています。
    Windows 10 1607 / Windows Server 2016 https://support.microsoft.com/ja-jp/help/4048953/ リリース準備を進めています。
    Windows 10 1511 https://support.microsoft.com/ja-jp/help/4048952/ リリース準備を進めています。
    Windows 10 1507 https://support.microsoft.com/ja-jp/help/4048956/ リリース準備を進めています。
    Windows 8.1 / Windows Server 2012R2 Security-only update https://support.microsoft.com/ja-jp/help/4048961/  

    技術情報

    https://support.microsoft.com/ja-jp/help/4055038/

     

    対策版更新プログラム入手先

    https://www.catalog.update.microsoft.com/Search.aspx?q=KB4055038

    Monthly Rollup https://support.microsoft.com/ja-jp/help/4048958/
    Windows Server 2012 Security-only update https://support.microsoft.com/ja-jp/help/4048962/
    Monthly Rollup https://support.microsoft.com/ja-jp/help/4048959/
    Windows 7 / Windows Server 2008 R2 Security-only update https://support.microsoft.com/ja-jp/help/4048960/
    Monthly Rollup https://support.microsoft.com/ja-jp/help/4048957/

    対策版更新プログラムは順次リリースされます。それまでの間、対策版更新プログラムがリリースされていない Windows をお使いのお客様で、この現象に遭遇しているお客様は、一時的に 11 月のセキュリティ更新プログラムを削除することで本現象を回避することができます。しかしながら、セキュリティ更新プログラムの削除は、コンピューターが脆弱になる可能性があるため、弊社では推奨しておりません。事象の回避の優先度に応じてご検討いただき、対策版更新プログラム公開後には直ちに必要なセキュリティ更新プログラムの適用をいただけるようお願いします。

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

    0
    0

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

    "理由はわからないけど、とにかく PC ・サーバーが遅くて困っている!" – そんなときはパフォーマンス ログ

     
    パフォーマンス関連のお問い合わせの背景をお伺いすると、システム パフォーマンスの問題の解決に取り組む際の手がかりがなくて困っている、と仰るお客様が多くいらっしゃいます。
    このようなとき、私たちはパフォーマンス ログの採取・提供をお願いしています。

    パフォーマンス ログとは、 Windows や Windows 上で実行されるアプリケーションのパフォーマンス情報の記録です。
    Windows では、標準でパフォーマンス ログを採取する機能が備えられており、データ コレクター セットで定義したパフォーマンス カウンター (情報採取項目) の数値をファイルに書き出すことができます。

    PC やサーバーのパフォーマンスの低下は、さまざまな要因で発生します。

    • CPU への負荷が大きく、 CPU 処理待ちが発生している。
    • I/O 割り込みなど優先度の高い処理が多く、一般の処理が滞りがちになっている。
    • 処理が “待ち (WAIT)” の状態のまま止まってしまっている。
    • メモリ不足が発生している。
    • ディスク I/O でボトルネックが発生している。

    原因を特定し対策を実施する際には、闇雲に調査を進めないためにも、まずはどの観点で調査を進めるべきかを明確にする必要があります。
    パフォーマンス ログを見れば、 CPU、メモリ、ディスク、ネットワークなど、さまざまなリソースの状況を一度に確認することができ、調査の初動をスムーズにできます。
    そのため、パフォーマンス関連のお問い合わせを頂戴した際には、必ずと言ってよいほど、パフォーマンス ログの採取をお願いしています。

    本稿では、一般的なパフォーマンス ログの採取手順についてご紹介します。
    この手順でパフォーマンス ログを採取・解析することで、問題の切り分けにお役立ていただけると思います。
    また、マイクロソフトのサポートにお問い合わせいただくときも、パフォーマンス ログがすでに手元にあると、調査がスムーズに始められます。
     

    設定手順

     
    私たちがパフォーマンス ログの採取をお願いするときは、以下の手順でご採取いただくようご案内しています。

    1. 管理者権限で起動したコマンド プロンプトにて下記コマンドを実行し、データ コレクター セットを作成します。
       
      logman create counter AskCore-Triage -c "\Cache\*" "\LogicalDisk(*)\*" "\Memory\*" "\Network Adapter(*)\*" "\Network Interface(*)\*" "\PhysicalDisk(*)\*" "\Process(*)\*" "\Processor(*)\*" "\Processor Information(*)\*" "\Server\*" "\System\*" "\Paging File(*)\*" "\Database(*)\*" "\Server Work Queues(*)\*" "\Objects\*" -si 00:00:15 -cnf 24:00:00 -v NNNNNN -o %systemdrive%\PerfLogs\Admin\AskCore-Triage
    2. 引き続き、管理者権限で起動したコマンド プロンプトにて下記コマンドを実行し、ログの採取を開始します。
       
      logman start AskCore-Triage
    3. 引き続き、管理者権限で起動したコマンド プロンプトにて下記コマンドを実行し、再起動後も自動的にパフォーマンス ログの採取が開始されるよう、起動時に実行されるタスクを作成します。
       
      schtasks /create /tn \Microsoft\Windows\PLA\AskCoreTriageLogOnStart /sc onstart /tr "logman start AskCore-Triage" /ru system
    4. 事象の再現を待ちます。
       
      +++ この間、バックグラウンドでシステム リソースの状態が記録されます。 +++
    5. 事象の再現を確認したら、管理者権限で起動したコマンド プロンプトで下記コマンドを実行し、ログの採取を停止します。
       
      logman stop AskCore-Triage
    6. <システム ドライブ (通常 C)>:\PerfLogs\Admin\AskCore-Triage にログ ファイルが格納されたフォルダーが作成されるので、回収します。

    上記手順により、CPU、メモリ、ディスク、ネットワークなど、調査の手がかりになるパフォーマンス カウンターのデータを一括して 15 秒ごとに採取します。
    1 時間あたり最大で 200 MB のログ ファイルが出力される場合がありますが、ログ ファイルは 24 時間に 1 回分割されるので、古いログを順次退避・削除することで、ディスク容量の逼迫を避けることができます。
    また、 logman create コマンドにオプションを追加することで、循環ログにすることも可能です。

    パフォーマンス ログを採取するデータ コレクター セットは、パフォーマンス モニター (perfmon.exe) を使用して GUI 上で作成することも可能です。
    しかし、 3000 個以上もあるカウンター (実際に私の PC で確認すると 3513 個のカウンターがあります) から必要なカウンターを GUI 上で選別するのは大変な苦労です。
    現に、 “これだけたくさんあるカウンターの中からどれを選べばよいのかわからない” とのお問い合わせも頂戴しています。
    そのため、上記のような、コマンドを使用し一括してパフォーマンス カウンターを記録する手順をご案内しています。
     

    採取したログはどうするの?

     
    パフォーマンス モニター (perfmon.exe) を使用し、採取したパフォーマンス ログの確認することが可能です。 (既定で関連付けが設定されています。)
    ログ ファイルを開いたのち、 [カウンターの追加] メニュー (グラフ上を右クリックすると選択できます) から、画面上に表示するパフォーマンス カウンターを追加することもできます。
    また、 relog コマンド (https://technet.microsoft.com/en-us/library/bb490958.aspx) を使用しログを CSV 形式に変換すれば、ご自身で Excel などを使用して数値解析することも可能です。

    まず最初に確認したいカウンターは、次のとおりです:

    • \Processor(_Total)\% Processor Time -> CPU 使用率が高騰し、負荷が過剰になっていないか?
    • \Processor(_Total)\% Privilaged Time -> 優先度の高い処理の負荷が過剰になっていないか?
    • \System\Processor Queue Length -> CPU 割り当て待ちの処理が発生してないか?
    • \Memory\Available Bytes -> メモリ不足が生じていないか?
    • \LogicalDisk\% Idle Time -> ディスクの負荷が過剰になっていないか?
    • \LogicalDisk\Avg. Disk Queue Length -> ディスクのリソース待ちが慢性的に発生していないか?

    上記カウンターの状況を踏まえ、次のようなアクション プランを検討します。

    • 他のパフォーマンス カウンターや関連のパフォーマンス カウンターの確認。 (例: メモリ不足による処理遅延の疑いがある際に、 \Paging File(_Total)\% Usage や \Memory\Pages Output/sec などを確認する。)
    • Windows Performance Recorder (WPR) を使用したログの追加採取・詳細調査。 (例: CPU 使用率の高騰やディスク アイドル率の低下が見られるときに、具体的にどの処理がリソースを消費しているかを WPR のログにより確認する。)
    • ダンプによるメモリ使用状況の確認。

    なお、パフォーマンスの問題に関するお問い合わせとして、パフォーマンス ログと併せてマイクロソフトのサポートにご連絡いただければ、ログの解析から次のアクション プランのご提案まで、問題の解決にむけ全面的にご支援いたしますので、ぜひご検討ください。
     

    日ごろからパフォーマンス ログ

     
    ディスクに余裕がある環境では、日ごろからパフォーマンス ログを採取しておくことをおすすめします。

    冒頭でお伝えしたように、パフォーマンスの問題でお問い合わせいただくと、私たちはかなりの高い頻度でパフォーマンス ログの採取・提供をお願いしています。
    なぜなら、確実かつ迅速に課題を解決するには、パフォーマンス ログを根拠に適切な調査方針を決めることが重要となるからです。
    このときに、すでに採取されているパフォーマンス ログがあれば、調査がスムーズに進む可能性が高くなります。
    逆に、問題発生時のパフォーマンス ログがなく、ログ採取の設定をしたけど今度は問題が再発しない – こうなってしまうと、調査が行き詰ってしまうことにもなりかねません。

    パフォーマンス ログは、システムの負荷が小さく、採取したまま放置することができるので、発生頻度が低くいつ起きるかわからない事象の記録にも向いています。
    古いログ ファイルの削除や循環式ログの設定など、適切な設定さえ行えば、ログ ファイルによりディスク容量を食いつぶす心配もありません。
    そのため、 “転ばぬ先の杖” として、パフォーマンス ログを日常的に採取することは、効果的な戦略となります。
     

    パフォーマンス ログは便利だけど万能ではない

     
    パフォーマンス ログは便利ではありますが、万能ではありません。

    たとえば、 CPU 負荷やメモリ負荷が高い状況では、具体的にどの処理が負荷を高めているのかを確認する必要がありますが、パフォーマンス ログでは処理を特定することはできません。
    また、処理が待ち状態で止まってしまっていることが原因の場合、待ち状態の処理はリソースをほとんど消費せず、パフォーマンス ログ上ではあたかも何も問題がないように見えるため、別の情報を採取する必要があります。

    パフォーマンス ログは初動で活躍し、原因特定のフェーズでは別途詳細な情報採取が必要であるということを覚えておいてください。

    LPRemove タスクの動作について

    0
    0

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

    現在弊社にて提供しております多くの Windows 製品では、多言語対応となっており、あらかじめ言語パックが追加されたイメージを展開いたしますと、セットアップ時に表示言語を選択できるようになっております。

    ※ Windows Server 2016 製品のセットアップ時における、言語選択画面の例

    またいっぽうで、使用していない言語パックを削除する LPRemove タスクが登録されており、コンピューターの起動時や、メンテナンスのタイミングにて、言語パックのクリーンアップを行っております。

    LPRemove タスクは、バックグラウンドで実行されておりますが、すべての言語パックが削除される前にコンピューターの再起動を行いますと、削除されなかった言語パックが残されたままとなる動作が確認されております。

    不要な言語がインストールされている場合には、手動で言語パックの削除を実施してください。

    ※言語パックの削除ツールは、”lpksetup /u” コマンドで起動できます。

    多言語環境の構築を検討いただくにあたり、本ブログ記事の情報がお役に立てますと幸いです。

    Viewing all 590 articles
    Browse latest View live




    Latest Images