Dynamics 365 Finance/Supply Chain を 10.0.44 にアップグレードした直後から、Batch Job の「Full Reset」が Executing のまま止まり、Entity Store と標準 Power BI レポートが更新されないケースがあります。本記事では、運用側で試せる具体手順と、サポート起票が必要になる判断基準を整理します。
現象の概要：アップグレード後に分析基盤だけが止まる
Dynamics 365（本記事では 10.0.44）へアップグレードした後、トランザクション処理（受発注・在庫・会計など）は動いているのに、分析系の更新だけが止まることがあります。典型例が、Batch Job の 「Full Reset」 が Executing のまま進まず、Entity Store が更新されないパターンです。
Entity Store が更新できないと、Dynamics 365 標準の Power BI レポート（ワークスペースに展開されるレポートや、組み込みの分析ワークスペース）で 最新データが反映されない／更新エラー／前日から数日分が欠けるといった影響が出ます。運用目線では「業務は回るが、数字だけが更新されない」ため、気づきにくい一方でインパクトが大きい障害です。
| 症状 | 画面での見え方 | 影響 |
|---|---|---|
| Full Reset が Executing のまま | System administration（システム管理）> Inquiries（照会）> Batch jobs（バッチジョブ）でステータスが変わらない | Entity Store の再構築が完了せず、以降の更新が滞留 |
| Entity Store が更新されない | System administration（システム管理）> Setup（設定）> Entity Store で最終更新時刻が進まない／Refresh が失敗 | 標準 Power BI レポートが古いまま、または更新エラー |
| axdwadmin のログイン失敗が出る | Entity Store 側のログ・エラーに「ログイン失敗」関連が記録（例：Login failed for user 'axdwadmin'） | DWH（分析ストア）への接続に失敗し、Full Reset/Deploy/Incremental が連鎖的に詰まる |
ポイント：Full Reset の「詰まり」は原因ではなく結果になりやすい
今回の芯は ユーザー axdwadmin のログイン失敗です。Full Reset が止まって見えるのは“表の症状”で、実際には Entity Store（分析用データベース）への 接続認証や、バックエンド側の状態不整合が原因になっているケースが多いです。
そのため、次のような操作を一通り試しても改善しないことがあります。
- Full Reset の再実行（複数回）
- AOS／BATCHAOS の再起動依頼（クラウド環境では運用者側で直接再起動できないこともあります）
- PQU（Platform update quality update）適用（例：PQU1）
根本の認証/接続が直っていない場合、再実行しても同じ地点で止まるため、「ジョブを増やしすぎない」「待機キューを雪だるま化させない」ことが実務上の重要ポイントになります。
最初にやるべき切り分け：本当に“止まっている”のかを確認する
Full Reset は重い処理なので、単に時間がかかっているだけの可能性もあります。そこで、まずは “進捗がある実行中” と “詰まり” を切り分けます。以下の観点で確認すると、無駄な再実行を減らせます。
| 確認ポイント | 見る場所 | 判断の目安 |
|---|---|---|
| Batch job のタスクが動いているか | Batch jobs の該当ジョブで、タスク（Batch tasks）/ 履歴（History）/ ログ（Log） | タスクが更新されない、開始時刻だけが古いままなら“詰まり”の可能性 |
| 例外/エラーが蓄積していないか | Batch job history / 例外の詳細 | axdwadmin ログイン失敗が繰り返されている場合、認証/接続がボトルネック |
| Entity Store 更新ジョブが連鎖的に滞留していないか | Batch jobs で Waiting のジョブ数と、説明（Description） | Deploy measurement / Incremental update が大量に Waiting のままなら、まず渋滞解消が必要 |
対処方針：運用側で試せるのは「詰まりを解消して再実行」まで
バックエンド認証が原因の場合、運用だけで完全解決できないことがあります。それでも、現場でまず試す価値が高いのは次の 2 つです。
- Executing の Full Reset を Force cancel（強制キャンセル）して、再実行できる状態に戻す
- Entity Store 関連の Waiting ジョブを整理し、必要な measurement を手動 Refresh する
ここから先は、実際の操作手順を画面パス付きでまとめます。
対処1：Executing の Full Reset を Force cancel して再スケジュールする
“Executing のまま張り付く” 状態をいったん解消し、正常系の再実行に戻すための手順です。ポイントは、単なる Cancel ではなく Force cancel を使うこと、そしてキャンセル後に Waiting 状態へ戻して再スケジュールすることです（操作ラベルは環境の言語設定や画面構成で若干異なる場合があります）。
| 手順 | 操作 | 実務上の注意点 |
|---|---|---|
| 1 | System administration（システム管理）> Inquiries（照会）> Batch jobs（バッチジョブ） を開く | 「Batch job history」や「Batch task」も見られる画面で実施すると切り分けが速いです |
| 2 | 説明（Description）やジョブ名で Full Reset を特定する | 同名が複数ある場合、開始時刻・作成者・バッチグループで判別します |
| 3 | アクション（Functions）から Force cancel を実行する | 権限が必要です。運用ルール上、事前連絡や承認が必要な場合があります |
| 4 | キャンセル後、必要に応じて ステータスを Waiting に変更して再実行の形に戻す | 「同じジョブ定義を使って再実行したい」場合の実務的手段です（無理に多重実行しない） |
| 5 | スケジュール（Recurrence）や実行条件を見直し、再実行を待つ | Full Reset は重いので、他の大量バッチと競合しない時間帯が望ましいです |
Force cancel → 再実行してもすぐ Executing で止まる場合は、Full Reset 自体の不具合というより、Entity Store 側へ接続できていない可能性が高いです。その場合は、次の「対処2」を先に行い、待機ジョブの雪だるま化を止めることを優先してください。
対処2：Entity Store 関連の Waiting ジョブを整理し、measurement を手動 Refresh する
Full Reset が詰まると、その後ろにぶら下がる Entity Store 関連ジョブ（Deploy measurement / Incremental update など）が Waiting に溜まり続け、結果として“何を実行しても進まない”状態になります。ここでは、待機ジョブを整理してから、必要な measurement を 手動 Refresh する流れを取ります。
Waiting ジョブ整理の考え方
- 対象は、説明に Deploy measurement／Full reset／Incremental update などが含まれるもの
- 「明らかに Entity Store 系」と判断できるジョブに絞って削除する（他業務のバッチは触らない）
- 削除の前に、スクリーンショットやエクスポートで“何を消したか”を残す（サポート依頼時の材料になります）
| やること | 具体的な操作 | 狙い |
|---|---|---|
| Waiting ジョブを抽出 | Batch jobs でステータス＝Waiting をフィルターし、説明（Description）で絞り込む | Entity Store 系だけを対象にする |
| 待機キューの整理 | 不要な Waiting ジョブを削除（特に重複して積み上がっているもの） | 後続処理の渋滞を解消する |
| measurement の手動 Refresh | System administration（システム管理）> Setup（設定）> Entity Store で measurement を選び Refresh | 必要な分析だけを最短で復旧させる |
measurement を手動 Refresh するときの実務ポイント
全 measurement を一気に Refresh すると、処理時間が伸びたり、失敗時の原因切り分けが難しくなります。まずは“影響が大きいもの”から順に更新すると、業務側の痛みを早く軽減できます。
- 経営・会計系のダッシュボードが止まっているなら、売上/仕入/総勘定元帳など優先度の高い measurement から
- 現場が困っているなら、在庫・購買・販売の measurement から
- Refresh 実行後は、Batch jobs と Entity Store 画面の両方で結果を確認する
実施後の確認：Power BI 側まで“更新されたこと”を見届ける
Entity Store の Refresh が成功しても、Power BI 側の表示が更新されるまでにタイムラグがあったり、別のエラーで止まっている場合があります。次の観点で確認すると、切り分けが早くなります。
| 確認対象 | 見るポイント | よくある落とし穴 |
|---|---|---|
| Entity Store | 最終更新時刻が進んだか／Refresh の結果が Success か | Batch 側は成功でも、特定 measurement だけ失敗していることがあります |
| Batch jobs | Full Reset/Deploy/Incremental のステータス遷移、例外ログ | Executing が解消しても Waiting が残り続け、再び渋滞することがあります |
| Power BI レポート | レポートの更新日時、表示上のフィルター、反映される数値 | キャッシュや閲覧者のフィルターで「更新されていないように見える」ことがあります |
それでも解決しない場合：サポートチケット起票が現実的な近道
上の 2 つの対処を行っても、axdwadmin のログイン失敗が継続する場合は、運用者の操作だけで直せない領域（バックエンド側の資格情報復旧、分析ストア側の状態修復、サービス側の再構成）が疑われます。こうなると、現実的な回避策は Power Platform 管理センターから Microsoft へサポートチケットを起票することです。
サポート起票前に揃えると強い情報
サポートの初動を速くするには、「再現条件」と「ログの揃え方」が重要です。以下をメモしておくと往復が減ります。
| 情報 | 例 | 目的 |
|---|---|---|
| 環境名 / 対象サービス | Prod / UAT / Sandbox、対象の環境名 | 対象環境を誤らない |
| 発生タイミング | 10.0.44 アップグレード直後から、いつから止まったか | アップグレードとの因果を追える |
| バッチジョブ情報 | Full Reset のジョブ ID、開始時刻、ステータス遷移 | バックエンド調査の手掛かり |
| エラーメッセージ | axdwadmin ログイン失敗の文言、例外のスタック | 認証系か接続系かを早期に判断 |
| 実施済みの対処 | Full Reset 再実行、AOS/BATCHAOS 再起動、PQU1 適用、Force cancel、Waiting 整理など | 同じ提案の繰り返しを防ぐ |
コミュニティでの追加相談も有効
サポートの回答待ちの間に、回避策や同様事例の情報を集めたい場合は、Dynamics 365 のコミュニティで相談するのも有効です。同じバージョン・同じ症状の投稿が見つかれば、暫定手順（回避策）を先に試せることがあります。
原因切り分けの観点：axdwadmin ログイン失敗で疑うべきこと
axdwadmin は、Entity Store（分析ストア）への接続に使われる内部ユーザーとして扱われることが多く、ログイン失敗が出ると Full Reset だけでなく Deploy/Incremental も連鎖的に止まります。原因のパターンを大きく分けると次の通りです。
| 分類 | 起きやすい状況 | 運用側でできること | サポートが必要になりやすい度合い |
|---|---|---|---|
| 資格情報の不整合 | アップグレード後に接続情報が噛み合わない | バッチの詰まり解消、再実行、関連ジョブ整理 | 高い |
| 分析ストア側の状態異常 | バックエンドで一時的な障害、内部処理が詰まっている | 運用でできることは限定的。ログを揃えて起票 | 高い |
| バッチ実行基盤の問題 | Batch server が実行できない、バッチグループ未割当など | Batch server 設定・稼働確認、再起動依頼 | 中 |
| ジョブ定義の競合/渋滞 | Full Reset を連続実行、Waiting が増殖 | Force cancel、Waiting 整理、実行順序の整理 | 低〜中 |
今回のように「Full Reset が Executing 固定」かつ「axdwadmin ログイン失敗」が出ている場合、上の表では 資格情報の不整合または 分析ストア側の状態異常に寄りやすく、サポート介入が必要になる確率が上がります。
やってはいけないこと：復旧を遅らせる典型パターン
焦って操作すると、かえって渋滞を増やして復旧が遅れます。現場でよく起きる“やりがち”を整理します。
- Full Reset を短時間に何度も実行する：実行中/待機中が積み上がり、原因が見えづらくなります
- Entity Store と無関係な Waiting ジョブまで削除する：業務バッチに影響が出る可能性があります
- エラー文言を控えずに画面だけ閉じる：axdwadmin ログイン失敗など、芯の情報が後で追えなくなります
再発防止：Entity Store 更新を“詰まらせない”運用のコツ
根本原因が解消された後も、同様の渋滞を起こさないために、運用で効くポイントをまとめます。
- Full Reset は最小回数で：実施が必要なときだけ行い、むやみに連続実行しない
- 実行時間帯を分ける：大量バッチやデータ移行と同時間帯にぶつけない
- Waiting の増殖を見張る：Entity Store 系ジョブが Waiting で積み上がったら早めに手を打つ
- エラー文言を保全する：axdwadmin ログイン失敗のような“芯のエラー”を最優先で追う
- 定期的に Power BI 側も点検：利用者目線で「更新日時が動いているか」をチェックする
まとめ：運用でやるべきことと、サポートへ渡すべきことを分ける
Dynamics 365 10.0.44 アップグレード後に Full Reset が Executing のまま止まり、Entity Store／Power BI が更新されない場合、まずは Force cancel → 再スケジュールと、Waiting ジョブ整理 → measurement 手動 Refreshで“詰まり”を解消してみてください。
それでも axdwadmin のログイン失敗が消えない場合は、運用だけで抱え込まず、Power Platform 管理センターからサポートチケットを起票し、環境名・発生時刻・ジョブ ID・エラー文言・実施済み対処を揃えて渡すのが最短ルートになります。
コメント