Windows Server の Work Folders で、管理者がサーバー側に作成・更新したファイルが一部 Windows 10 端末に同期されず、クライアント側でエラー 0x8007017c が出て停止する──そんなトラブルの切り分けと、KB アンインストールによる復旧手順、運用上の注意点をまとめます。
発生している症状を整理する（まずは事実を揃える）
今回のケースは、Work Folders の「サーバー側で変更したファイルがクライアントに降りてこない」タイプの不具合です。現場で混乱しやすいので、最初に症状を定義しておきます。
- Windows Server 上の Work Folders（ユーザー共有）で、管理者がユーザー領域のファイルを作成・更新する
- 一部ユーザーの Windows 10 クライアントで同期が進まず、Work Folders が停止状態になる
- クライアント側で エラー 0x8007017c が表示される
- 問題のファイルをサーバー側（共有側）から削除するまで復旧しない（削除すると同期が再開する）
| 項目 | 内容（例） | 確認の狙い |
|---|---|---|
| クライアントOS | Windows 10（1909 / 2004 / 20H2） | 該当KBの見当を付ける |
| サーバーOS | Windows Server 2016（v1607） | Work Folders（Sync Share）の前提条件を揃える |
| トリガー | 管理者がサーバー側でファイル作成・更新 | 「クライアント起点」ではない点が重要 |
| 復旧条件 | 問題ファイルを共有から削除すると復旧 | 特定ファイルのメタ情報/処理が引き金の可能性 |
ポイントは、同じサーバー／同じ共有でも「一部の Windows 10 端末だけ」止まることです。サーバー側の構成ミスというより、クライアント側の状態差（更新プログラム、構成、ポリシー、セキュリティ製品など）の影響を疑うのが近道になります。
Work Folders の同期の仕組み（トラブルの起点を理解する）
Work Folders は、ユーザーごとの領域（同期共有）をサーバーで管理し、クライアントは Work Folders の仕組みでサーバーと同期します。体感としては「フォルダーが勝手に同期される」ですが、内部的には以下の要素が絡みます。
- サーバー側：Sync Share（Work Folders の役割）でユーザーごとのデータを保持
- クライアント側：Work Folders クライアントが同期状態（差分、競合、メタ情報）を管理
- ファイル単位：内容だけでなく、タイムスタンプ、属性、アクセス権、暗号化や保護設定などの影響も受ける
このため、管理者がサーバー側でファイルを作成・更新した際、クライアント側が「想定外のファイル状態」と判断すると、保護のために同期を止めることがあります。今回の 0x8007017c で停止し、ファイルを消すまで復旧しないという挙動は、クライアントが特定ファイルの処理で詰まり、キュー全体が止まっているイメージに近いです。
エラー 0x8007017c が出るときに疑うべき方向性
0x8007017c 自体は「Work Folders の同期がエラーで停止している」状況を示しますが、原因は一つではありません。とはいえ今回の事例では、次の整理が現実的です。
- 同一サーバーでも端末によって発生有無が分かれる
- 問題ファイルを削除すると復旧する（＝ファイルが引き金だが、端末依存の処理差がある）
- 特定の Windows 10 累積更新（CU）適用後に発生しやすいという報告がある
結論として、Windows 10 の特定の累積更新プログラム適用後に発生する不具合（パッチ起因）の可能性が高い、という切り分けになります。
最短で切り分けるためのチェックリスト
「あれもこれも試す」の前に、影響端末で最低限そろえると判断が早い情報をまとめます。
| チェック項目 | 確認方法（例） | なぜ必要か |
|---|---|---|
| Windows 10 のバージョン | winver、設定 → システム → バージョン情報 | 1909/2004/20H2 で疑うKBが変わる |
| 該当KBの有無 | 設定 → 更新とセキュリティ → 更新履歴、または「インストールされた更新プログラム」 | パッチ起因かどうかを最短で確認 |
| 止まるファイルの特徴 | 拡張子、サイズ、パス長、ファイル名、暗号化/保護属性など | パッチ起因以外の制限（長いパス等）も潰せる |
| サーバー側の操作方法 | エクスプローラー、スクリプト、別サーバー経由、バックアップ復元など | 属性・権限・タイムスタンプが変わる経路の特定 |
この段階で「Windows 10 のバージョン」と「該当KBの有無」が揃うと、次に説明する対処（KB アンインストール）の成功率を上げられます。
有力な解決策：該当KBをアンインストールして挙動を確認する
今回の整理では、クライアント側の Windows 10 に入った特定の累積更新が Work Folders の同期処理と相性問題を起こし、0x8007017c で止まる可能性が高い、という前提です。そのため、対処はシンプルに「該当KBを外して改善するか確認」します。
| Windows 10 バージョン | 疑うKB（例） | メモ |
|---|---|---|
| 1909 | KB4592449（環境によっては KB4598229 も関与の報告あり） | まず KB4592449 を外して挙動確認、改善しない場合は追加検討 |
| 2004 / 20H2 | KB4592438 | 同様にアンインストール後、再起動して同期を再試行 |
ここで重要なのは「恒久対策として外しっぱなしにする」ではなく、切り分けとして外して改善するかを見ることです。改善すれば原因の方向性が定まり、次の打ち手（後続アップデートでの解消確認、展開設計の見直しなど）に移れます。
手順（GUI）：更新プログラムのアンインストール
- 影響端末で Windows 10 のバージョン（1909 / 2004 / 20H2）を確認する
- 「設定」→「更新とセキュリティ」→「Windows Update」→「更新履歴を表示」へ進む
- 「更新プログラムをアンインストールする」を開く（従来の画面が表示されます）
- 一覧から該当する KB（例：KB4592449 / KB4592438）を選択してアンインストール
- 再起動
- Work Folders の同期を「今すぐ同期」などで再試行する
手順（コマンド）：wusa でアンインストール（管理者向け）
端末台数が多い、またはリモート支援で素早く試したい場合は、コマンドでのアンインストールも有効です。
インストール済みKBの確認（PowerShell例）
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 30アンインストール（例）
wusa /uninstall /kb:4592449
wusa /uninstall /kb:4592438無人実行（運用都合が許す場合のみ）
wusa /uninstall /kb:4592449 /quiet /norestart無人実行は再起動の扱いを誤ると逆に切り分けが遅れるため、まずは手動で「外した → 再起動 → 同期確認」を丁寧に踏むのがおすすめです。
アンインストール後に必ず見るべき「復旧確認ポイント」
「エラーが消えた気がする」で終えると、後日また同じ障害が再発します。復旧確認は、最低でも次の観点で行います。
- Work Folders のステータスが「最新」または同期進行中から正常完了に戻る
- サーバー側で変更したファイルがクライアントに降りてくる（問題ファイルを削除しなくても同期できる）
- 同じ操作（サーバー側で管理者が作成・更新）を再現しても止まらない
- イベントログに同種のエラーが残らない、またはエラー後に正常に回復する
ログ確認（クライアント側）
原因がパッチ起因だったとしても、ログは残しておくと「後続アップデートで直ったか」「別要因が混ざっていないか」の判断材料になります。
| 場所 | 見るポイント |
|---|---|
| イベントビューアー アプリケーションとサービス ログ | Work Folders 関連の Operational ログ（同期開始/終了、エラーの詳細） |
| Work Folders の管理画面 | エラーコード、対象ファイルの情報、再試行の挙動 |
ログ確認（サーバー側）
サーバー側にも同期共有（Sync Share）関連のログが残ります。クライアント起因が濃厚でも、サーバー側のログが「正常に配信している」ことを確認できれば、切り分けの裏取りになります。
- Sync Share / Work Folders 役割のイベントログ（接続、同期要求、エラー）
- 該当ユーザーの領域で権限や所有者が想定通りか（管理者が置いたファイルだけACLが変になっていないか）
注意点：セキュリティ更新を外すことのリスクと現実的な判断
累積更新プログラム（CU）にはセキュリティ修正が含まれます。したがってアンインストールは、やり方を間違えるとリスクが増えます。一方で、Work Folders が止まって業務が止まるのも現実的なリスクです。大事なのは「無計画に外しっぱなし」ではなく、影響と代替策をセットで判断することです。
| 観点 | メリット | デメリット / 注意 | 現実的な落とし所 |
|---|---|---|---|
| 該当KBを外す | 同期停止の早期復旧が期待できる | 脆弱性修正も外れる可能性がある | 切り分け目的で短期間実施し、後続アップデートで再検証 |
| 後続アップデートで解消を狙う | セキュリティと機能の両立がしやすい | 「いつ直るか」が環境により変わる | 検証端末→段階展開（リング方式）で安全に進める |
| 更新配布の制御（WSUS等） | 問題の更新を組織的に避けられる | 運用設計が必要 | Work Folders 利用端末だけでも制御できると強い |
「恒久対策」としては、修正を含む後続アップデート適用で解消できるかを検証し、業務影響とリスクのバランスで判断するのが現実的です。更新管理（段階展開、停止ルール、監視）を入れておくと、同種トラブルの再発時にも対応が早くなります。
KBを外したら別のエラー（例：0x80041006）が出た場合
現場報告として、KB を外した結果、別のエラー（例：0x80041006）が出て Work Folders が同期できなくなるケースもあります。この場合は「0x8007017c と同じ原因」と決め打ちせず、別件として切り分けを進めるのが安全です。
ただし、すぐに手を付けられる一次対応としては次が候補になります（環境ポリシーに合わせて実施してください）。
- Work Folders を「今すぐ同期」で再試行し、エラーが恒常か一過性かを見る
- 端末再起動（同期キューや関連サービス状態のリセット）
- Work Folders 関連サービスの再起動（実施できる場合）
- システム整合性チェック（
sfc /scannow、DISM /Online /Cleanup-Image /RestoreHealth） - イベントログを採取し、エラー発生時刻・対象ファイル・発生条件を特定する
この段階で無理に「この操作で必ず直る」と断言できる性質のものではないため、ログ採取・検証（必要に応じてサポート問い合わせ）に進めるのが現実的です。重要なのは、0x8007017c の切り分けのために KB を外したこと自体は無駄ではなく、問題領域（更新起因か、端末固有か、Work Folders 構成か）を狭める材料になる点です。
再発防止のために運用でできること（オリジナルの現場対策）
パッチ起因の不具合は、個別のKB対処だけだと「また別の更新で再発」しがちです。Work Folders を業務で継続利用するなら、次のような運用面の工夫が効きます。
管理者がサーバー側で直接編集・投入する運用を見直す
今回のように「管理者がユーザー領域にファイルを置く」運用は、便利な一方でトラブルの火種にもなります。改善案としては次が考えられます。
- 配布用の共有（別パス）を用意し、ユーザーが自分の Work Folders に取り込む形にする
- どうしてもサーバー側で投入するなら、投入手順を固定する（コピー方法、権限継承の確認、ファイル名ルール）
- 投入後に「特定端末だけ止まる」兆候を監視する（早期検知）
問題を起こしやすいファイル条件を事前に潰す
パッチ起因が濃厚なケースでも、ファイル条件が悪いと別の障害に繋がります。次の観点は、事前にルール化しておくと事故が減ります。
| 観点 | 例 | 対策例 |
|---|---|---|
| パスが長すぎる | 深い階層＋長いファイル名 | フォルダー階層と命名規則をシンプルにする |
| ファイルが巨大 | 大容量の動画、仮想ディスク、巨大ZIP | Work Folders で扱う範囲を業務文書中心に限定する |
| 頻繁に更新される | ログ、DB、キャッシュ | 同期対象から除外する（別運用に分離） |
| 属性・保護設定 | 暗号化、保護ラベル、セキュリティ製品の隔離 | セキュリティ要件と同期要件の両立を検証し、例外/ルール化 |
Windows Update の「段階展開」を前提にする
Work Folders のように業務影響が大きい仕組みは、更新を一斉適用すると障害時の影響が拡大します。おすすめは以下の考え方です。
- 検証端末（IT部門の端末や仮想環境）で先に累積更新を適用し、Work Folders の基本動作（アップ/ダウン同期、競合処理）を確認する
- 問題がなければ少数部門→全社へ段階展開する（リング方式）
- 止まった場合は「どのKBからか」「どのバージョンでか」を短時間で追える体制にする
今回のように「特定のKBが怪しい」という情報が出たとき、段階展開の設計があるだけで、影響を最小化できます。
最短復旧のためのまとめ（この順で進めると迷いにくい）
- 影響端末の Windows 10 バージョン（1909 / 2004 / 20H2）を確定する
- 該当する累積更新（KB4592449 / KB4592438、必要に応じて KB4598229）の有無を確認する
- 切り分けとして該当KBをアンインストールし、再起動後に Work Folders の同期を再試行する
- 改善したら「更新起因」の線が濃厚。後続アップデートでの解消確認、更新展開設計の見直しへ進む
- 別エラー（例：0x80041006）が出たら別件としてログ採取・追加切り分けを行う
Work Folders の同期障害は「ファイルを消すと直る」などの場当たり対応で回ってしまいがちですが、根本原因が更新起因の場合は、同じ現象が繰り返し起きます。端末の Windows 10 バージョンと KB を軸に整理し、短いサイクルで検証していくのが復旧と再発防止の近道です。
コメント