今回のトラブルはこちら
「windows updateが失敗し、累積更新プログラムでエラー0x80080008が発生」

システム構成／処理シーケンス

1. クライアント端末からwindows update を実行
2. WSUS（ダブルサス）から最新の修正パッチがクライアント端末にダウンロード
3. クライアント端末で更新プログラムを適用

トラブル内容

1.実行後、クライアント端末の画面では「更新に失敗しました。いくつかの更新プログラムのインストールに問題がありましたが後で再試行します」エラー0x80080008が表示されました。windows update失敗の発生です。

直接原因

2.までは正常終了し、3.実行中に上記エラーが発生

Ｃドライブの空きディスク容量に、更新プログラムをインストールするだけの空き容量が足りていなかった。

詳細解析

今回の更新プログラムは「KB5011495」

この更新プログラム適用に、具体的にどの程度の空きディスクが必要だったのか厳密に示すことは難しいものの、Cドライブに6GB程度の空き容量が必要だった

対策

Cドライブに存在している不要ファイル削除実施後、1.windows updateの再実施

ダウンロードフォルダ、マイドキュメントフォルダに存在する不要なファイルの削除、もしくはDドライブなどシステム容量と別のドライブへ移動するなどすることでディスクの空き容量を確保するようにする。

背景／標準化

セキュリティ対策の厳しいシステムにおけるクライアント端末のトラブルです。解析、対策難易度も低いトラブルを紹介したのは、この件に関する問い合わせが非常に多いという理由があります。FAQやよくあるトラブルに掲載しているものの、ユーザーはそんなもの参照せず、サポートへ問い合わせしてくるケースがほとんどです。

クライアント端末には、最新の更新プログラム適用済かを判断するツールがインストールされており定期的にチェックされていました。こういったクライアント端末がひとたびこのようなトラブルに見舞われると、インターネット接続はもちろん、outlookメール、teams利用なども利用が制限される可能性があり、ユーザー業務が滞ることから即サポートへの問い合わせにつながります。ユーザーのITスキル、運用状況を勘案しながら、必要に応じてディスク容量不足を通知するツール、ファイルの自動削除ツール（対象フォルダやタイミングなど事前にユーザーと合意が必要）の導入を検討すると良いでしょう。

追加情報として、本トラブルが発生するとwindowsアップデートを再実行しても失敗するケースが報告されています。

その場合は「MicrosoftUpdate カタログ」から所定のパッチをダウンロードして適用します。システムによっては、クライアント端末へ更新プログラムが適用されていない場合でも、「MicrosoftUpdate カタログ」へのアクセスが許可されているケースがあります。

Microsoft Update Catalog

www.catalog.update.microsoft.com

余談ですが「累積更新プログラムでエラー0x80080008」は、インストール対象ディスクの空き容量の不足だけが原因で発生するわけではありません。今回紹介した対応で解決しない場合は保守サポートへ解析依頼をするなどの対応を検討ください。

今回のトラブルはこちら
「ユーザーから見ると帳票印刷済みとなっているにも関わらず、プリンターから印刷されない」

システム構成／処理シーケンス

1. ブラウザ上の印刷ボタンを押下／命令送信
2. apサーバへ命令送信（httpプロトコル）
3. lprコマンド実行
4. lprの正常終了により印刷ジョブを生成
5. lpr発行順にcupsのキューへ登録
6. プリンタへキューの送信（lprプロトコル）
7. 受信したキューをプリンタ上のキューへ登録
8. キュー登録順に印刷

トラブル内容

1.の結果、ユーザーのWebアプリケーション画面上では印刷実行結果が「印刷済み」となる。
しかし、実際は「8.印刷」がされておらず、Webアプリケーション画面の「印刷済み」と異なる。

直接原因

lprコマンドは正常終了しているが、cupsのキューが消失しており、プリンタまでキューが到達していない。
webアプリケーションはlprの実行結果（echo $の結果）だけで「印刷済」か「印刷失敗」を判断していたが、lprの実行結果だけではプリンタから印刷が完了しているか判断できない。

詳細解析

• cupsが、キュー最大滞留時間3時間を超えたキューを削除した。
  デフォルト設定の3時間、送信先物理プリンターが応答しない（送信要求を受けたあとのLPDレスポンス待ちなど）場合、サーバー上に登録されたキューを削除する

• 物理プリンター送信エラー時（フィニッシャーュ故障、紙詰まりなど）、送信リトライ5回×30秒を超えキューを削除する　　　

　　　　 /etc/cups/cupsd.conf　　　
　　　　    JobkillDelay=30　←　デフォルト　　　
　　　　　JobRetryLimit=5　←　デフォルト

対策

• キュー最大滞留時間を無制限に修正

　　　　MaxJobs　　　　MaxJobTime=0　←　無制限

• 送信リトライ回数を無制限想定

　　　 /etc/cups/cupsd.conf
　　　　JobkillDelay=864000　←　10日
　　　　JobRetryLimit=1000000　→　仮想無制限

• アプリケーションの「印刷済み」は、プリンターの印刷ログにおける「印刷完了」をもって判定する。

背景／考察

システム更改案件において、商用ソフトウェアSVFからOSS向け印刷システムcupsへの処理方式変更がありました。一方、機能、非機能に変更がない前提だったため、性能試験、負荷耐久試験は行っていません。しかし、実運用では数万ページの大量印刷が実行され、cupsキュー、プリンタキュー両方とも上限値に到達、長時間の印刷待ちが発生しました。

既存機能が実現できているのか試験はしていたものの、SVFより習熟度の劣るcups利用ということで設計、トラブル対応とも苦労したという事実があります。OSSを使うトレンドは継続すると思いますが、既存のソフトウェアからOSSへ移行する場合は注意が必要です。有償ソフトウェアはOSSより完成度（豊富な機能、流通している情報、サポート充実度など）が高く多くのメリットがあることを忘れてはいけないでしょう。

標準化／管理の定着

開発関連の実施要領に追加した一部を抜粋します。

• lprの正常終了により「印刷完了」とする業務ロジック自体が間違いである。設計はプリンタの印刷完了確認をもって「印刷完了」とする業務ロジックとする。
• 印刷量に応じたcupsキュー、プリンタキューのチューニングを実施する。（上限値にならない設定とすることで、lpr実行エラーの発生防止にもつながる）
• 帳票印刷試験の観点に「大量印刷」に関するユースケースを検討する。
  特にプリンタ管理ソフトおよびプリンタのキュー上限、プリンタ障害時の連続印刷などについて想定されるケースでの試験を行うことをお勧めします。

まとめ

プレプリント（テンプレートとなる代行収納用紙などに宛先、住所などの個別情報を後から印刷する帳票のこと）のように、印刷部数や専用プリンタを利用することが明確な場合は、想定印刷数による耐久負荷試験は実施すると思いますが、事務所で担当者がどういった使い方をするのか明確になっていない帳票印刷がある場合は、要件定義の性能／拡張性、運用性を必ず検討する必要があります。

特に今回のようにミドルウェア更改も含む場合、非機能要件に関する設定も引き継がれているのか十分確認しましょう。

コラム

今回選定したプリンターは、印刷順序に「データ受付順」と「データ処理順」の2モードがありました。
「データ処理順」を設定すると、以下のようなバグと思われる事象が内在していました。

メーカーは仕様だといってますが、明らかに動作がおかしい上、「データ受付順」の場合はこの事象は発生しません。こういったバグと思われるような事象をテストで発見することは難しい場合もありますが、設定値に対する負荷耐久試験は必ず実施し、品質を向上させる努力は必要です。

初歩的なトラブルを頻発させると、品質強化試験を迫られる場合があり余計な稼働がかかりますので、計画的な試験計画を立案するようにしてください。

ITエンジニアの転職ならNext Career（ネクストキャリア）がおすすめです。