SharePoint Server 2019/2016 に KB5002639 以降の更新を適用した後、BCS（BDC）ソリューションがデプロイできず「DotNetAssembly/WebService system type is not supported.」で失敗する事象があります。本記事では原因の整理と、修正パッチ適用・PowerShellによる暫定回避・再発防止までを具体的にまとめます。
起きていること：KB適用後に BCS（BDC）ソリューション／BDCモデルのデプロイが失敗する
SharePoint Server 2019（オンプレミス）で KB5002639 および後続の更新プログラムを適用した後から、Business Connectivity Services（BCS）の BDC/BCS ソリューション（BDCモデル）がデプロイできなくなるケースが報告されています。SharePoint 2016 でも同様の症状が出ることがあり、外部リストや検索クロール（LOB コンテンツのクロール）でも例外が発生することがあります。
現場でよく見える症状は次のとおりです。
- Visual Studio から BDC モデルをデプロイしたはずなのに、BDC（外部コンテンツタイプ）が見えない／外部リストが作れない
- Central Administration（または PowerShell）で
.bdcmを手動アップロードすると インポートに失敗する - ULS などに以下のようなエラーが出る
DotNetAssembly/WebService system type is not supported.Error was encountered at or just before Line: '4' and Position: '6'.
| 操作・イベント | 期待する結果 | 実際に起きること | ログ／メッセージの例 |
|---|---|---|---|
| Visual Studio から BDC モデルをデプロイ | 外部コンテンツタイプが作成され、外部リストで利用できる | デプロイは完了したように見えるが、BDC が表示されない／利用できない | ULS に system type 非対応の例外が残る場合がある |
Central Admin から .bdcm をインポート | モデルがインポートされ、外部コンテンツタイプが作成される | インポート自体が失敗し、モデルが取り込まれない | DotNetAssembly/WebService system type is not supported. |
| 既存の外部リスト／外部データ列を閲覧 | 外部システム（LOB）からデータが表示される | ページ表示時に例外、またはデータが取得できない | BCS 関連の例外（環境によりメッセージは異なる） |
| 検索クロールで BCS コンテンツをクロール | 外部データが検索インデックスに入る | クロール失敗や例外が発生 | クロールログ／ULS に BCS 起因のエラーが残る |
原因の整理：DotNetAssembly / WebService タイプの BDC モデルがブロックされている可能性
本件の要点は、BDC モデル（.bdcm）の中でも DotNetAssembly または WebService を使うモデルに症状が集中している点です。エラーが示唆するように、モデル内に以下のような定義があると失敗しやすくなります。
<LobSystem ... Type="DotNetAssembly">
...
</LobSystem>
更新プログラム適用後に「DotNetAssembly / WebService 系の BCS（BDC）モデルがブロック（または互換性が破壊）される」挙動になっている可能性が高く、スレッド内では退役（無効化）相当の変更が入ったのではという推測も出ています。
DotNetAssembly / WebService は、SharePoint サーバー側で .NET アセンブリや SOAP/サービス呼び出しを伴う設計になりやすく、セキュリティ強化や制限変更の影響を受けやすい領域です。今回のように「以前は動いていたが、特定の KB 以降で import/deploy が落ちる」場合、モデル側の不具合というより プラットフォーム側の許可／制限変更を疑うのが切り分けの近道になります。
| BDC モデルの LOB 種別（Type） | 典型的な接続先 | 今回の事象との関係 | 確認のポイント |
|---|---|---|---|
| Database | SQL Server 等の DB | 比較的影響が少ないケースが多い | Database 型が動くなら「DotNetAssembly/WebService 限定の問題」の可能性が上がる |
| OData（環境・実装により） | OData エンドポイント | DotNetAssembly/WebService を避ける代替になりうる | オンプレの構成・認証方式で接続できるか事前検証が必要 |
| DotNetAssembly | SharePoint サーバー上の .NET アセンブリ | エラーの中心 | Type="DotNetAssembly" が含まれるか、デプロイ後に import が失敗していないか |
| WebService | SOAP/サービス連携 | エラーの中心 | Type="WebService" が含まれるか、同様に import が失敗していないか |
切り分けのコツ：まず「DotNetAssembly/WebService だけが落ちている」かを確認する
復旧作業の前に、次の観点で状況を整理すると、対応の優先順位が決めやすくなります。
| 確認項目 | やること | 判断の目安 |
|---|---|---|
| 影響が出たタイミング | 直近で適用した KB（特に KB5002639 以降）を洗い出す | 更新直後から発生していれば、パッチ起因の可能性が高い |
| BDC モデルの Type | .bdcm を開き、Type="DotNetAssembly" または Type="WebService" が含まれるか確認 | 含まれる場合、本事象に該当しやすい |
| Database 型の BCS が動くか | 同じ環境で Database 型モデル（既存でも検証用でも可）を import してみる | Database が動くなら、BCS 全体停止ではなく「特定タイプの制限」に寄っている |
| 既存モデルの挙動 | 更新前からあった外部リスト／検索クロールが、更新後に同時に落ちたか確認 | 既存も落ちるなら、単なる新規デプロイ失敗ではなく実行時にも影響がある |
特に、エラーが Line 4 / Position 6 のように早い位置を指している場合は、モデル内の先頭付近（<LobSystem ... Type="..."> など）の型チェックで弾かれている可能性が高いです。つまり「モデルが壊れている」より「型が許可されない」方向の問題に寄ります。
恒久対応：修正済み更新プログラム（KB5002771 / KB5002772）の適用を最優先にする
コミュニティ報告では、2025/8/12 公開の KB5002771 と KB5002772 が本件を解消する旨が共有されています。SharePoint 2016 側でも「このパッチで解決した」という報告があり、まずは 該当の修正パッチ適用を最優先で検討するのが現実的です。
| 製品 | 現象のきっかけになりやすい更新 | 解消が期待される更新（報告ベース） | 狙い |
|---|---|---|---|
| SharePoint Server 2019 | KB5002639 および後続の更新 | KB5002771 / KB5002772 | DotNetAssembly/WebService の import/deploy 互換性を回復 |
| SharePoint Server 2016 | 同様の更新適用後に発生することがある | （同パッチで解決したという報告あり） | 同上 |
SharePoint の更新適用は、単に KB をインストールするだけではなく、ファーム全体の整合性（ビルド番号の一致、構成のアップグレード）が重要です。復旧を急ぐほど手順を省略しがちですが、BCS のようにサービスアプリケーションが絡む領域では、結果的に遠回りになることが少なくありません。
パッチ適用の基本チェック（オンプレ運用の現実に寄せた手順）
- 影響範囲と停止許容を整理（外部リスト、外部データ列、検索クロール、連携バッチ、ユーザー影響）
- 検証環境があれば先に適用し、BDC モデル import と外部リスト表示、検索クロールを一通り確認
- 本番適用前に ファーム/DB のバックアップと、戻し手順（ロールバック手順）を用意
- ファーム内の全サーバーへ更新を適用（順序・同時適用のポリシーは運用に合わせる）
- 更新適用後に SharePoint 製品構成ウィザード（PSConfig）を実行し、構成をアップグレード
- 適用後、BDC モデルの import（既存・新規）と、外部リストの表示、検索クロールの正常化を確認
運用上、「すぐ直したい」ほど本番での一発勝負になりがちですが、BCS の復旧確認は“インポートが通った”だけでは不十分です。最低でも以下の 3 点はセットで確認してください。
- BDC モデル（.bdcm）が import できる
- 外部リストが実際にデータを取得できる（一覧表示・詳細表示・フィルタなど）
- 検索クロール（対象にしている場合）がエラーなく進む
暫定回避：ServerDebugFlags に 57007（DotNetAssembly）/ 57008（WebService）を追加して許可する
「修正済みパッチを適用するまで待てない」「ただしロールバックも難しい」という状況では、暫定的に PowerShell で DotNetAssembly / WebService を再度許可する回避策が共有されています。SharePoint 2019 では「復旧した」という報告があり、実施後に IIS リセットまで行うケースが多いようです。
重要：この回避策は、環境・ビルド・既存設定により期待通りに動かない可能性があります。また、制限が入った背景がセキュリティ強化である場合、許可を戻すこと自体がリスクになり得ます。必ず検証環境で影響を確認し、恒久対応（修正パッチ適用）が完了したら設定を戻す前提で扱ってください。
実行前の準備
- SharePoint 管理シェルで実行する（Farm 管理者権限）
- 対象の BDC Service Application を特定する（ファームに複数ある場合に注意）
- 現在の
ServerDebugFlags値を必ず控える（ロールバック用）
回避策の例（文字列で保持するパターンが多い場合）
$bdc = Get-SPServiceApplication | Where-Object { $_.TypeName -like "*Business Data Connectivity*" } | Select-Object -First 1
if (-not $bdc) { throw "BDC Service Application が見つかりません。" }
# 現在値を退避（必ずメモしておく）
$current = $bdc.Properties["ServerDebugFlags"]
Write-Host "Current ServerDebugFlags: $current"
# 追加したい値（報告ベース）
$add = @("57007","57008")
# 既存値に追記（重複は排除）
if ([string]::IsNullOrWhiteSpace([string]$current)) {
$new = ($add -join ",")
} else {
$list = ([string]$current) -split "," | ForEach-Object { $*.Trim() } | Where-Object { $* -ne "" }
$new = ($list + $add | Select-Object -Unique) -join ","
}
$bdc.Properties["ServerDebugFlags"] = $new
$bdc.Update()
# 反映のため IIS リセット（運用影響に注意）
iisreset 回避策の例（数値として保持している環境を想定し、ビット演算で追記するパターン）
$bdc = Get-SPServiceApplication | Where-Object { $_.TypeName -like "*Business Data Connectivity*" } | Select-Object -First 1
if (-not $bdc) { throw "BDC Service Application が見つかりません。" }
$current = $bdc.Properties["ServerDebugFlags"]
Write-Host "Current ServerDebugFlags: $current (Type: $($current.GetType().FullName))"
# 既存値が数値のときはビット演算で追加（環境によっては効かない場合があります）
$new = ([int]$current) -bor 57007 -bor 57008
$bdc.Properties["ServerDebugFlags"] = $new
$bdc.Update()
iisreset どちらの形式が正しいかは環境により異なり得ます。まずは 現在値の型（文字列か数値か）を確認し、同じ形式で変更するのが安全です。変更後は、BDC モデルの import → 外部リスト表示 → 検索クロールの順で復旧確認を行ってください。
「AllowList に追加する」案について
スレッド内には AllowList（SPSerializationCustomizedAllowList）へ追加する案も出ていますが、パラメータが不明瞭で、実際には「ほぼ何もしていないのでは」という指摘もあります。実施する場合は、本番に入れる前に検証環境で差分（実行前後で何が変わったか）を必ず確認してください。
それでも直らない場合にやるべきこと：サポート／ロールバック／方式変更を現実的に比較する
修正パッチの適用も回避策も効かない場合、あるいは環境制約でどちらも取れない場合は、選択肢を整理して「どこで折り合うか」を決める必要があります。おすすめは、次の優先順位で判断することです。
| 選択肢 | メリット | デメリット／注意点 | 向いている状況 |
|---|---|---|---|
| Microsoft サポートへエスカレーション | 根本原因の調査・正式な修正ルートに乗せられる | 調査に時間がかかることがある／再現情報の準備が必要 | 業務影響が大きく、暫定回避が許容できない |
| 該当更新のロールバック | 更新前の状態に戻せる可能性がある | セキュリティリスクが増える／戻した後の再適用計画が必要 | どうしても止められない業務で、短期的な復旧が最優先 |
| DotNetAssembly/WebService を避けた方式へ移行 | 今回のような制限変更の影響を受けにくくなる | 作り替えコストがかかる／要件・認証方式の見直しが必要 | 継続運用を見据え、技術負債を減らしたい |
ロールバックを選ぶ場合は、「戻す」までが作業ではなく「安全に再適用できる状態を作る」までがセットです。セキュリティ更新を外したまま運用を続けるのは、監査・事故対応の観点で後から必ず問題になりやすいため、短期の緊急避難として扱うのが現実的です。
方式変更を検討するなら：DotNetAssembly/WebService 依存を減らす設計の考え方
今回の事象は、「BCS が悪い」というより、“特定の BCS 実装（DotNetAssembly/WebService）が壊れやすい”ことを再認識させるタイプのトラブルです。将来の更新で同種の制限が再び入っても影響を最小化できるよう、方式変更を検討する価値があります。
| 選択肢 | 概要 | メリット | 注意点 |
|---|---|---|---|
| Database 型 BCS へ寄せる | 外部データを DB 側に寄せ、BCS は DB 接続に限定する | シンプルで運用が安定しやすい | DB 集約のための設計（ETL/同期/権限設計）が必要 |
| OData 等の標準 API を介す | 外部システムの前段に API 層を置き、BCS は API 連携へ | 外部システム側の変更を吸収しやすい | 認証（Kerberos/Claims/証明書等）やネットワーク設計の難易度が上がることがある |
| BCS 以外の統合手段へ | 要件により、検索連携・アプリ連携・バッチ等へ置換する | 制限変更の影響を受けにくい設計を取りやすい | 外部リストの「SharePoint から透過参照」のUXが変わる可能性 |
「外部リストで一覧表示したい」要件は強い一方で、BCS は SharePoint の内部機構に依存します。今回のように更新によって挙動が変わると、業務影響が一気に顕在化します。長期運用するシステムほど、外部連携の責務を SharePoint から切り離す（疎結合にする）設計は効果が大きいです。
現場で使えるトラブルシュート手順（ログと確認コマンド）
原因が「制限変更」なのか「構成不整合」なのかを切り分けるために、次の順序で情報を集めると効率的です。
ログで確認するポイント
- ULS に
DotNetAssembly/WebService system type is not supported.が出ているか Line: '4' Position: '6'のようにモデル先頭付近が指されているか（型チェックで落ちている可能性）- 検索クロールのログに BCS 起因の失敗が出ているか（外部データを対象にしている場合）
モデル側の確認（最短チェック）
.bdcmをテキストとして開き、Type="DotNetAssembly"/Type="WebService"を検索- 同時に、モデルが参照するアセンブリ名／エンドポイントが想定通りかも確認（更新適用で参照先が変わるわけではないが、切り分けのため）
SharePoint 管理シェルでの確認例
# BDC Service Application の有無を確認
Get-SPServiceApplication | Where-Object { $_.TypeName -like "*Business Data Connectivity*" } | Format-Table Id, DisplayName, TypeName
# BDC 関連サービスインスタンスの状態（環境により表示名は異なる）
Get-SPServiceInstance | Where-Object { $*.TypeName -like "*Business*" -or $*.TypeName -like "*BDC*" } | Format-Table Server, TypeName, Status BCS 周りは「サービスアプリケーション」「サービスインスタンス」「モデル（メタデータ）」が絡むため、どこか一つだけ見ても判断を誤りがちです。“更新直後から DotNetAssembly/WebService の import が落ちる”という状況が確認できれば、まずは修正パッチ適用（恒久対応）に寄せるのが最短です。
運用目線のまとめ：最短復旧の優先順位と判断基準
最後に、復旧を急ぐ現場で迷いがちなポイントを、意思決定しやすい形で整理します。
| 優先度 | やること | 狙い | 判断基準 |
|---|---|---|---|
| 高 | KB5002771 / KB5002772（報告ベース）を適用し、PSConfig まで完走 | 恒久的に互換性を戻す | メンテナンス時間を確保できる／セキュリティ要件を満たしつつ直したい |
| 中 | ServerDebugFlags へ 57007/57008 を追加し、IIS リセット | 短期の業務復旧 | パッチ適用まで時間があるが、外部リスト停止が許容できない |
| 中 | Microsoft サポートへエスカレーション | 正式調査・修正 | 暫定回避が効かない／再現・証跡を持って調査を進めたい |
| 低（緊急避難） | 該当更新のロールバック | とにかく戻す | 業務停止が致命的で、短期復旧が最優先（ただし再適用計画が必須） |
| 計画対応 | DotNetAssembly/WebService を避けたモデルへ作り替え | 将来の更新耐性を上げる | 長期運用・技術負債解消を見据え、改修コストを取れる |
BCS は「動いている間は便利」ですが、更新適用の影響が表面化すると、業務に直結して止まります。今回のケースでは、まず 修正済み更新の適用を軸にしつつ、どうしても待てない場合だけ ServerDebugFlags の暫定回避を使い、最終的には DotNetAssembly/WebService 依存を減らす設計へ寄せる——この順で考えると、復旧と再発防止のバランスが取りやすくなります。
コメント