SharePoint Server 2019 に KB5002754 / KB5002753 を適用した直後から、モダンページの左ナビや編集UIが消える、Nintex ワークフローが失敗／停止する、といった障害が同時に発生することがあります。本記事では原因の当たりを付ける切り分けと、現場で効果のあった対処を安全度順に整理します。
SharePoint Server 2019 更新（KB5002754 / KB5002753）適用後に起きる代表的な症状
SharePoint Server 2019 は、累積更新プログラム（Core update）と Language Pack update を同じタイミングで適用した直後に、モダンUI（静的ファイル参照）とワークフロー（タイマー側処理）の双方で不具合が表面化することがあります。見た目は「ナビが消えた」「ボタンが無い」ですが、実態としては JavaScript/CSS の読み込み失敗や、ワークフローのコンパイル／セキュリティチェックの扱いの変化が引き金になっているケースが多いです。
| 更新 | 種別 | 適用対象 | 影響が出やすい箇所 |
|---|---|---|---|
| KB5002754 | Core update | SharePoint Server 2019（Farm 全体） | モダンUIの静的リソース参照、ワークフロー実行基盤、タイマー処理 |
| KB5002753 | Language Pack update | Language Pack を導入しているサーバー | 言語フォルダー（ローカライズ）配下の静的リソース欠落・差分 |
| 分類 | 主な現象 | 影響範囲の目安 | 最初に疑うポイント |
|---|---|---|---|
| モダンページ（Modern Site Pages） | 左ナビが表示されない／編集ボタンが出ない／コマンドバーが欠ける | 複数サイトコレクションで再現しやすい（環境全体に波及） | LAYOUTS のバージョン付きフォルダー参照、言語フォルダーの静的ファイル欠落、404 |
| ワークフロー（主に Nintex） | 「failed to run」で開始できない／Change State・Pause For 等で無言停止 | 特定のアクションを使うWFで顕在化しやすい | PreParseSecurityCheck、WorkflowCompiler / authorizedTypes、OWSTIMER と web.config の不整合 |
最短復旧の考え方：変更は「安全度が高いもの」から段階的に
本番障害の対応では、成功しやすい順に打つのがセオリーです。特に SharePoint はサーバー台数や役割（WFE/APP）が絡むため、設定変更の前に「影響の出方」を観察しておくと、手戻りが大きく減ります。
| 優先度 | 狙い | 具体アクション | ポイント |
|---|---|---|---|
| 高 | 現象の可視化 | ブラウザ開発者ツールで 404/JS エラー確認、WF 実行履歴・ULS で失敗点確認 | 「UI系」と「WF系」を分離してから手を入れる |
| 高 | サーバー差の排除 | 更新適用状況を全台で揃える／問題サーバーの切り離し（LB配下） | 台数差があると、症状がランダムに見えて迷走しやすい |
| 中 | 参照先の整合 | SideBySideToken の見直し、言語フォルダー差分補完（バックアップ前提） | モダンUI系に効きやすい |
| 中 | WF 実行基盤の整合 | WorkflowCompiler（web.config / OWSTIMER.EXE.CONFIG）の整合、必要なら構成キャッシュ整理 | WFの「途中停止」「開始失敗」に効くことがある |
| 低 | 暫定回避 | EnablePreParseSecurityCheckForWorkflow を無効化 | セキュリティ面の判断が必要（変更管理必須） |
| 最終 | 確実に元へ戻す | 更新のロールバック（アンインストール）／Microsoft・Nintexへ正式サポート | 業務影響が深刻な場合の現実解 |
まず行う切り分け：原因を「UI系」と「ワークフロー系」に分離する
この手の障害は、焦って一気に設定変更すると検証が難しくなります。最初の30分は「何が壊れているか」を可視化して、対処の成功確率を上げるのが近道です。
| チェック項目 | 手順（例） | 判断のポイント | 次に進む方向 |
|---|---|---|---|
| 適用状況の確認 | 全サーバーで更新適用の有無と適用順を確認（WFE/APP で差がないか） | サーバー間で適用差があると、ロードバランサ配下で「出たり出なかったり」に見える | 差がある場合は先に揃える／一時的に問題サーバーを切り離す |
| モダンページの開発者ツール確認 | ブラウザ開発者ツールで Network を開き、JS/CSS の 404や読み込みエラーを確認 | sp-pages-assembly.js 等が 404 なら、ナビや編集UIが欠ける説明が付く | 「モダンページUI系」の対処へ |
| ワークフローの実行ログ確認 | Nintex の実行履歴／Workflow History、ULS、イベントログで「失敗タイミング」を特定 | 開始直後に失敗か、途中の特定アクションで停止かで対処が変わる | 「ワークフロー系」の対処へ |
| Timer Service の状態 | SPTimerV4 の稼働、再起動、過負荷（キュー詰まり）の有無を確認 | 停止・不安定だと「黙って止まる」が増える | サービスの健全化→設定対処 |
モダンページの左ナビ・編集ボタンが消える：原因と対処
モダンページの左ナビや編集ボタンは、サーバー上の静的ファイル（Next/spclient など）を読み込んで描画します。更新後にその参照が崩れると、ページ自体は表示できても UI の一部が欠けます。特に Language Pack を入れている環境では、言語フォルダー側のファイル欠落で発生することがあります。
現象の見え方（よくあるパターン）
| 見た目の症状 | 裏で起きていること（推定） | 確認方法 |
|---|---|---|
| 左ナビが空白になる | 関連 JS が読めず、ナビ描画が走っていない | 開発者ツールで 404 / JS エラー |
| ページ編集ボタンが出ない | コマンドバーのコンポーネントが初期化されていない | 同上（エラーが出ていることが多い） |
| 特定言語だけ崩れる | 言語フォルダーに必要ファイルが欠けている | en-us と対象言語（例：cs-cz）を比較 |
対処の全体像（安全度が高い順）
- 参照先フォルダーが存在するかを確認し、Side-by-Side（バージョン付き LAYOUTS）を正しい更新フォルダーへ向ける
- Language Pack による不足ファイルが疑われる場合、バックアップを取った上で言語フォルダーへファイルを補う
- IIS リサイクル／iisreset を全WFEに実施し、反映差をなくす
手順：SideBySideToken を更新して新フォルダーを参照させる
更新後の LAYOUTS 配下に、バージョン付きフォルダー（例：16.0.xxxxx.xxxxx）が作成されます。SharePoint がそこを参照できていないと、古い参照先に残っていないファイルを探して 404 になり、UI が欠けます。
更新後のバージョン付きフォルダーが存在するか確認
# 例：LAYOUTS 配下のフォルダー一覧を確認（実行サーバーで確認）
$layouts = Join-Path $env:CommonProgramFiles "microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS"
Get-ChildItem $layouts -Directory | Sort-Object Name -Descending | Select-Object -First 10Web アプリケーションが参照する SideBySideToken を更新
asnp *sharepoint* -ErrorAction SilentlyContinue
$webApp = Get-SPWebApplication "[https://your-sharepoint-url/](https://your-sharepoint-url/)"
$ws = $webApp.WebService
# 現在値の確認（念のため控える）
$ws.EnableSideBySide
$ws.SideBySideToken
# 実在するバージョンフォルダー名に置換して設定
$ws.SideBySideToken = "16.0.10417.20037"
$ws.EnableSideBySide = $true
$ws.Update()反映
- 全WFEでアプリケーションプール リサイクル、または iisreset を実施
- ロードバランサ配下の場合、1台ずつ実施して切り戻しポイントを確保
- 改善確認は「同じURLに何度も」ではなく、複数サイトコレクション／複数ページで行う（キャッシュの見かけ改善を除外するため）
手順：言語フォルダーに不足している JS を補う（Language Pack 影響が疑わしい場合）
更新後のパス例として、次のような場所にモダンUI関連のファイルがあります。
...\16\TEMPLATE\LAYOUTS\16.0.xxxxx.xxxxx\Next\spclient\
ここで en-us には存在するが、対象言語（例：cs-cz）に無いファイルがあると、対象言語でのみ UI が欠けます。運用現場では sp-pages-assembly.js を補うことで改善した例が報告されています。
| 作業 | ポイント | 注意 |
|---|---|---|
| 不足ファイルの特定 | en-us と対象言語フォルダーでファイル差分を取る | 「ファイルが無い」ことが確実に分かってから実施 |
| バックアップ | 対象言語フォルダーを丸ごとバックアップ（zip でも可） | 復旧手段を確保してから変更 |
| ファイル補完 | 例：en-us の sp-pages-assembly.js を対象言語へコピー | 全WFEへ同じ操作が必要（サーバー差が残ると再発に見える） |
作業後は iisreset などで反映し、モダンページを複数サイトで再確認します。もし 404 が残る場合は、別ファイルが不足している可能性があるため、Network の 404 一覧から「欠けているファイル名」を起点に埋めていくと作業が最短になります。
よくある落とし穴：設定は直っているのに「見え方」だけが戻らない
- ブラウザキャッシュで古い JS が残り、改善が遅れて見えることがあります（別ブラウザ／シークレットで確認すると判断が早いです）。
- WFE が複数台ある場合、1台だけ修正しても LB で別の WFE に当たると「直っていない」ように見えます。必ず全台反映を前提に進めます。
Nintex ワークフローが失敗／停止する：原因と対処
更新適用後にワークフローが不安定になる場合、表に出るエラーは大きく2種類に分かれます。原因が違うため、まずはどちらの系統かを切り分けます。
| 症状 | 典型的な見え方 | よくある原因の方向性 | 優先して試す対処 |
|---|---|---|---|
| 開始できず「failed to run」 | 起動直後に失敗。履歴にエラーが残る | 許可型（authorizedTypes）やセキュリティチェックが引っかかる | PreParseSecurityCheck、WorkflowCompiler/authorizedTypes 整合 |
| 途中で黙って停止 | Change State / Pause For 等で止まり、エラー無し。手動再実行で進む | タイマー側（OWSTIMER）での処理不整合、設定差、タイマーの不安定 | OWSTIMER と web.config の整合、Timer/キャッシュ周りの健全化 |
対処を始める前の準備（トラブルシュートを短くする）
- 再現条件を固定：どのWebアプリ／どのサイト／どのWFで再現するかを1つに絞り、毎回同じ手順で試します。
- 設定バックアップ：
web.configとOWSTIMER.EXE.CONFIGは編集前に必ずバックアップ（差分が追えるようファイル名に日時を付ける）。 - 影響を見える化：「開始直後に失敗」「特定アクションで停止」など、失敗パターンを言語化してから作業します。
対処案：EnablePreParseSecurityCheckForWorkflow を無効化（定番回避として効く場合がある）
更新後にワークフローが突然落ち始めた場合、Farm 設定の EnablePreParseSecurityCheckForWorkflow が影響することがあります。無効化して改善した報告がある一方、セキュリティ目的のチェックを下げる変更でもあるため、変更管理（承認・記録・切り戻し）を前提に実施します。
Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
$farm = Get-SPFarm
# 現在値を確認
$farm.EnablePreParseSecurityCheckForWorkflow
# 無効化（改善報告のある回避策）
$farm.EnablePreParseSecurityCheckForWorkflow = $false
$farm.Update()
iisreset
Restart-Service -Name SPTimerV4切り戻し（元へ戻す）
Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
$farm = Get-SPFarm
$farm.EnablePreParseSecurityCheckForWorkflow = $true
$farm.Update()
iisreset
Restart-Service -Name SPTimerV4| メリット | デメリット／注意点 |
|---|---|
| 変更点が少なく、効果が出る環境では復旧が早い | セキュリティ意図のチェックを下げるため、適用判断は慎重に（特に外部公開・厳格な監査環境） |
対処案：WorkflowCompiler 設定（web.config / OWSTIMER.EXE.CONFIG）の整合を取る
ワークフローは「Web（w3wp）」だけで完結せず、タイマー（OWSTIMER）側でも実行されます。更新後に System.Workflow.ComponentModel.WorkflowCompiler の扱いが厳格化したように見えるケースでは、web.config と OWSTIMER.EXE.CONFIG の記述がズレているだけで失敗することがあります。
| 設定ファイル | 主に効くプロセス | ズレた場合の典型症状 | 備考 |
|---|---|---|---|
| web.config | IIS（w3wp）経由の処理 | 開始時に失敗、Web ベースの操作で顕在化 | Webアプリ単位で存在（場所は環境で異なる） |
| OWSTIMER.EXE.CONFIG | SharePoint Timer Service（OWSTIMER） | 途中停止、遅延、再実行が必要になる | サーバー単位。全台で揃える必要がある |
パターン：OWSTIMER 側の WorkflowCompiler を整理し、構成キャッシュも含めて整合を取り直す
改善例として多いのが「OWSTIMER.EXE.CONFIG の <System.Workflow.ComponentModel.WorkflowCompiler> を整理し、web.config 側と食い違いをなくす」手法です。環境により最適解が分かれるため、以下の方針で進めると安全です。
| 方針 | 概要 | 向いている状況 |
|---|---|---|
| OWSTIMER から WorkflowCompiler ノードを削除して寄せる | OWSTIMER 側の記述を削り、web.config 側に寄せて管理 | OWSTIMER と web.config の差分が大きい／何を追加すべきか判断しづらい |
| authorizedTypes を両方に同一内容で明示 | web.config の targetFx 配下を OWSTIMER にも同一で反映 | 不足している型がある程度特定できている／追加で収束させたい |
構成キャッシュ（Configuration Cache）を扱う場合の標準手順（例）
構成キャッシュは SharePoint の内部整合に関わるため、作業するなら「手順の固定」が重要です。一般的には Timer Service を止めた上で、構成キャッシュの XML を整理し、cache.ini をリセットして再生成させます。
| ステップ | 作業内容 | 注意点 |
|---|---|---|
| 準備 | 対象サーバーを決め、作業順序（全台）を固定する | 複数台環境は「全台同じ状態」に揃えるのが前提 |
| 停止 | SharePoint Timer Service（SPTimerV4）を停止 | 停止を確認してから次へ |
| 整理 | 構成キャッシュ配下の XML を整理（環境の標準手順に従う） | 手順ミスは別障害に繋がるため、運用ルール化が必須 |
| 再生成 | cache.ini を初期化し、Timer 起動で再生成させる | 再生成完了まで待ってから IIS 側を触る |
| 起動・反映 | Timer 起動 → IIS/AppPool リサイクル | 反映順序を崩さない |
追加で効くことがある操作
WorkflowCompiler の変更を入れた後は、SharePoint に「設定が変わった」ことを再認識させるための更新処理が効く場合があります。
asnp *sharepoint* -ErrorAction SilentlyContinue
$webApp = Get-SPWebApplication "https://your-sharepoint-url/"
$webApp.UpdateWorkflowConfigurationSettings()- Nintex 管理画面から Web Application Activation を再実行（必要に応じて）
- IIS と Timer Service を再起動し、再現手順（固定した1本）で効果確認
「黙って止まる」→「failed to run が出る」への変化はヒントになる
Nintex を最新版へ更新した後に「黙って止まる」から「failed to run（エラーとして表に出る）」へ変化した場合、ワークフロー自体は従来どおりでも、実行基盤側の例外が表面化した可能性があります。重要なのは、エラーが出るようになったこと自体は前進という点です。
- 停止していた箇所（アクション）を特定しやすくなる
- authorizedTypes や権限／セキュリティチェックに関係する例外ログが追える
それでも解決しない場合の現実的な選択肢
同じ更新でも、Farm 構成・Language Pack・Nintex バージョン・カスタムの有無で効く対処が変わります。復旧を最優先するなら、次の選択肢を比較して判断します。
| 選択肢 | メリット | デメリット | おすすめの状況 |
|---|---|---|---|
| Microsoft サポート（オンプレ）へチケット | 製品側の見解・修正情報（ホットフィックス等）に繋がる可能性 | 調査に時間がかかることがある | 環境全体に影響、再発が許されない |
| Nintex サポートへチケット | Nintex 側の既知問題や設定指針が得られる | SharePoint 側の根本原因が別にあると往復が増える | Nintex 更新後も不安定、特定アクションで止まる |
| 問題更新のロールバック（アンインストール） | 短時間で「元に戻る」可能性が高い | セキュリティ更新を戻すことになるため、判断は慎重に | 業務影響が深刻、暫定回避では運用できない |
ロールバックを検討する場合の実務ポイント
- 可能なら検証環境で「戻したら直る」ことを確認してから本番に適用します。
- Core と Language Pack を両方当てている場合、戻す対象（KB）と順序を明確にし、手順・結果を記録します。
- 戻した後は、セキュリティ上の穴を認識した上で、代替の緩和策（公開範囲の見直し、アクセス制御、WAF 等）も合わせて検討します。
補足：外部リスト（BDC DotNetAssembly）が動かないという報告
同じ更新の影響として、BDC モデルが DotNetAssembly の External List が動かなくなったという話題も出ることがあります。Farm のフラグで再有効化を試すスクリプト例が共有されることもありますが、環境によっては効かない例もあるため、まずは影響範囲の確認とログ取得を優先してください。
再発防止：パッチ適用を「作業」ではなく「手順」にする
SharePoint 2019 の更新は、単に適用して終わりではなく、周辺製品（Nintex 等）と合わせたスモークテストが重要です。特に今回のように UI とワークフローが同時に揺れるケースでは、「事前にテスト観点を固定しておく」だけで復旧速度が変わります。
| タイミング | 実施内容 | チェック観点（例） |
|---|---|---|
| 適用前 | 構成・設定の記録、バックアップ、差分管理 | web.config / OWSTIMER の控え、SideBySideToken、Nintex バージョン |
| 適用直後 | スモークテスト（短時間で網羅） | モダンページ編集、左ナビ、代表WFの開始・完了、Timer 状態 |
| 翌営業日まで | 監視強化とログの保全 | ULS のエラー増加、WF の失敗率、ユーザー報告の収集 |
まとめ
KB5002754 / KB5002753 適用後に「モダンページの左ナビが消える」「Nintex ワークフローが失敗／停止する」場合、単一原因ではなく、UI（静的ファイル参照）とワークフロー（タイマー＋コンパイル設定）の両面が同時に揺れていることがあります。まずは開発者ツールやログで 404／例外を可視化し、SideBySideToken と言語フォルダー、PreParseSecurityCheck と WorkflowCompiler の整合を安全度順に当てていくと、無駄な変更を減らしながら復旧に近づけます。
コメント