Delivery Optimization breaking Windows 11 update downloads?
We started seeing Delivery Optimization–related issues with Windows updates after upgrading devices to Windows 11 24H2. In our SCCM environment, Windows updates begin downloading but consistently fail or stall partway through the download. In many cases, the download restarts multiple times and eventually errors out. This behavior is consistent across multiple devices and different boundaries. These same devices were patching normally prior to the 24H2 upgrade. Since moving to 24H2, patching has become unreliable, especially for larger updates. From what we’re seeing, this doesn’t look like a traditional content or boundary issue. It feels like Delivery Optimization is failing mid-transfer or not resuming downloads correctly after the OS upgrade. So far we’ve checked the following: - Boundaries and boundary groups are unchanged - Content is available and distributed correctly on DPs - No recent SCCM site or infrastructure changes - Network connectivity looks normal On the client side, we’ve been reviewing: - DataTransferService.log (downloads start but fail or restart mid-way) - DeliveryOptimization logs (showing repeated retries / stalled transfers) - CAS.log and LocationServices.log (content location looks normal) - WUAHandler.log (update detection looks fine) Overall, detection and policy seem healthy — the issue appears during the actual download phase. Has anyone else seen Delivery Optimization downloads stall or fail during Windows patching after upgrading to Windows 11 24H2? If so, did you find a specific DO setting, policy change, or workaround that stabilized patching?Delivery Optimization breaking Windows 11 update downloads?
We started seeing Delivery Optimization–related issues with Windows updates after upgrading devices to Windows 11 24H2. In our SCCM environment, Windows updates begin downloading but consistently fail or stall partway through the download. In many cases, the download restarts multiple times and eventually errors out. This behavior is consistent across multiple devices and different boundaries. These same devices were patching normally prior to the 24H2 upgrade. Since moving to 24H2, patching has become unreliable, especially for larger updates. From what we’re seeing, this doesn’t look like a traditional content or boundary issue. It feels like Delivery Optimization is failing mid-transfer or not resuming downloads correctly after the OS upgrade. So far we’ve checked the following: - Boundaries and boundary groups are unchanged - Content is available and distributed correctly on DPs - No recent SCCM site or infrastructure changes - Network connectivity looks normal On the client side, we’ve been reviewing: - DataTransferService.log (downloads start but fail or restart mid-way) - DeliveryOptimization logs (showing repeated retries / stalled transfers) - CAS.log and LocationServices.log (content location looks normal) - WUAHandler.log (update detection looks fine) Overall, detection and policy seem healthy — the issue appears during the actual download phase. Has anyone else seen Delivery Optimization downloads stall or fail during Windows patching after upgrading to Windows 11 24H2? If so, did you find a specific DO setting, policy change, or workaround that stabilized patching?
更新プログラム適用後、bcp.exe の出力メッセージが英語になる
English follows Japanese こんにちは。SQL Server サポート チームです。 事象 日本語版の SQL Server をインストールし、利用している環境で、SQL Server へ更新プログラムを適用後、bcp.exe の出力メッセージが英語になる場合があります。 接続先インスタンスを誤った場合の例: 本事象は、ODBCドライバーの修正が含まれた更新プログラムを適用する場合、更新プログラムに含まれるODBCドライバーのインストーラーは各言語版ではなく英語版での提供となり、更新プログラムを適用時にODBCドライバーの日本語リソースファイルが削除されるために発生します。 対処策 SQL Server の更新プログラムを適用後、日本語リソースファイルを再配置します。再配置手順は以下の通りです。 ODBC ドライバー（17.10.6.1）を例としてご説明します。 日本語リソースファイルを再配置方法： 1) 以下のサイトにアクセスし、リリース番号 17.10.6.1 ODBC ドライバー(日本語) をダウンロードします。 ODBC Driver for SQL Server のダウンロード - ODBC Driver for SQL Server | Microsoft Learn 2) ダウンロードしたファイル(msodbcsql.msi) を任意のフォルダーに配置します。 なお、後述の手順はC:\temp フォルダーにインストールしたインストーラーを配置した場合の例です。 3) 管理者権限でコマンドプロンプトを起動し、下記のコマンドを実行し、ダウンロードしたインストーラーを展開します。 msiexec /a "C:\temp\msodbcsql.msi" /qb targetdir="C:\temp\msodbcsql_msi" 4) 展開したフォルダーにある msodbcsqlr17.rll を次の配置先のフォルダーにコピーします。 ※ 配置先のフォルダー C:\Windows\System32\1041 が存在しない場合は、フォルダーを作成したうえで msodbcsqlr17.rll をコピーします。 コピー元: C:\temp\msodbcsql_msi\Windows\System32\1041 配置先: C:\Windows\System32\1041 5) bcp.exe の出力メッセージが日本語となるか確認します。 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー Hello, this is the SQL Server Support Team. Issue In environments where the Japanese version of SQL Server is installed and used, after applying an update to SQL Server, the output messages from bcp.exe may appear in English. Example when connecting to the wrong instance: This issue occurs when the update includes a fix for the ODBC driver. The installer for the ODBC driver included in the update is provided in English rather than in each localized language version. As a result, the Japanese resource file for the ODBC driver is deleted during the update process. Resolution After applying the SQL Server update, relocate the Japanese resource file. The steps below explain how to do this using ODBC Driver version 17.10.6.1 as an example. Steps to relocate the Japanese resource file: 1) Access the following site and download the ODBC Driver version 17.10.6.1 (Japanese version): Download ODBC Driver for SQL Server - ODBC Driver for SQL Server | Microsoft Learn 2) Place the downloaded file (msodbcsql.msi) in any folder. The following steps assume the installer is placed in the C:\temp folder. 3) Open Command Prompt with administrator privileges and run the following command to extract the installer: msiexec /a "C:\temp\msodbcsql.msi" /qb targetdir="C:\temp\msodbcsql_msi" 4) Copy the msodbcsqlr17.rll file from the extracted folder to the following destination folder: If the destination folder C:\Windows\System32\1041 does not exist, create it before copying the file. Source : C:\temp\msodbcsql_msi\Windows\System32\1041 Destination : C:\Windows\System32\1041 5) Confirm that the output messages from bcp.exe are displayed in Japanese.
Windows Server 2025 にインストールしたSQL Server の更新プログラムを削除する方法
こんにちは。SQL Server サポート チームです。 事象 Windows Server 2025 にインストールしたSQL Server に対して適用した更新プログラムが、Uninstall Updates(更新プログラムをアンインストール) 画面に表示されません。 // Microsoft SQL Browser とMicrosoft SQL Server VSS Writer は表示されますが、SQL Server は表示されない 対処策 SQL Server の更新プログラムをアンインストールする必要がある場合は、以下の方法でアンインストールをお願いします。 SQL Server 2022 CU19(KB5054531) を例としてご説明します。 ※注意事項※ レジストリ エディターまたは別の方法を使用してレジストリを誤って変更すると、深刻な問題が発生することがあります。 最悪の場合、オペレーティング システムの再インストールが必要になることがあります。 マイクロソフトは、レジストリの変更により発生した問題に関しては、一切責任を負わないものとします。 そのため、十分に注意のうえ、作業ください。 SQL Server の更新プログラム(KB5054531) のアンインストール方法： 1) スタートボタン -> ファイル名を指定して実行 から「regedit.exe」と入力し、「OK」をクリックします。 2) レジストリエディターが起動したら、以下のレジストリ キーを開きます。 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\KB5054531 3) UninstallString をダブルクリックして表示される画面から、[値のデータ] に記載の内容をコピーします。 4) コマンドプロンプトを管理者で起動し、手順3 でコピーしたコマンドを実行します。 5) 更新プログラムをアンインストールする画面が表示されるため、指示に従い更新プログラムのアンインストールを進めます。 以下のように[状態] が全て[成功] となっていれば、SQL Server の更新プログラムをアンインストールすることができたと判断できます。 6) コマンドプロンプトとレジストリエディターの画面を閉じます。SQL Server の更新プログラム GDR, CU, Service Pack の違いと適用可否
こんにちは、 SQL Server サポートです。 今回は、SQL Server の GDR, CU, Service Pack の違いと適用可否について紹介します。 GDR、CU、Service Pack の違い SQL Server の更新プログラムには主に GDR, CU, Service Pack の3種類があります。 GDR (General Distribution Release) 主にセキュリティ関連の修正を提供します。 そのバージョンのSQL Server の以前のGDR のすべての修正を含みます。 例えば、CU も GDR も適用していない SQL Server 2019 で、SQL Server 2019 向けの GDR5 を適用すると、GDR1～GDR4の修正も適用されます。 そのため、GDR1 → GDR2 → GDR3 →・・・のように段階的に適用する必要はありません。 CU (Cumulative Update) 機能改善やバグ修正を含む更新を提供します。 そのバージョンのSQL Server の以前のCU や以前のGDR のすべての修正を含みます。 例えば、CU も GDR も適用していない SQL Server 2019 で、SQL Server 2019 向けの CU5 を適用すると、CU1～CU4の修正も適用されます。 そのため、CU1 → CU2 → CU3 →・・・のように段階的に適用する必要はありません。 Service Pack 大規模な更新を提供し、複数の修正や新機能をまとめて提供します。 そのバージョンのSQL Server の以前のService Pack や以前のCU、以前のGDR のすべての修正を含みます。 そのため、例えば どの Service Pack も適用していない SQL Server 2016 で、Service Pack 3 を適用したい場合、 Service Pack1 → Service Pack2 → Service Pack3 のように段階的に適用する必要はありません。 ただし、どの Service Pack も適用していない SQL Server 2016 で Service Pack 3用の CU や GDR を適用したい場合は、Service Pack3 → 目的の CU や GDR のように適用する必要があります。 なお、Service Pack は SQL Server 2016 以前で提供されていました。 シンプルで予測可能なメインストリームサービス ライフサイクルを採用したため、SQL Server 2017 以降ではService Pack は存在せず、CU と GDR のみとなります。 GDR、 CU、 Service Pack の適用可否 ・GDR を適用済みの SQL Server には、より新しい GDR か Service Pack か CU が適用できます。 ・CU を適用済みの SQL Server には、より新しい CU か Service Pack が適用できます。 ・Service Pack が適用済みのSQL Server で、かつ CU も GDR も適用していない場合は、その Service Pack 用の CU または その Service Pack 用の GDR を適用できます。 各バージョンの SQL Server の最新の更新プログラムは下記から確認できます。 // SQL Server の最新の更新プログラムとバージョン履歴 - SQL Server | Microsoft Learn https://learn.microsoft.com/ja-jp/troubleshoot/sql/releases/download-and-install-latest-updates ※参考情報 // Announcing the Modern Servicing Model for SQL Server | Microsoft Community Hub https://techcommunity.microsoft.com/blog/sqlserver/announcing-the-modern-servicing-model-for-sql-server/385594 // SQL Server 累積的更新プログラム (CU) のインストールに関する一般的な問題のトラブルシューティング - SQL Server | Microsoft Learn https://learn.microsoft.com/ja-jp/troubleshoot/sql/database-engine/install/windows/sqlserver-patching-issues#cumulative-update-and-service-pack-installation-information // SQL Server のサービス モデル - SQL Server | Microsoft Learn https://learn.microsoft.com/ja-jp/troubleshoot/sql/releases/servicing-models-sql-server ※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。SQL Server 2019 の累積的な更新プログラム適用後に発生するイベント名 feature_restriction_usage が見つからないエラーについて
こんにちは SQL Server サポートチームです。 今回は SQL Server 2019 CU2 以降を適用した際に ERRORLOG に記録されるエラーについてご説明します。 ■概要 SQL Server 2019 CU2 以降で拡張イベントの"sqlserver.feature_restriction_usage"が廃止されたことにより、 累積的な更新プログラムを適用した後の初回起動時に、下記のエラーが記録されることがあります。 このエラーは更新プログラム適用後の一時的なものであり、無視していただいて問題ありません。 Error: 25623, Severity: 16, State: 1. The event name, "XXXXXXXXXXXXXXXX.sqlserver.feature_restriction_usage", is invalid, or the object could not be found Error: 25710, Severity: 16, State: 1. Event session "telemetry_xevents" failed to start. Refer to previous errors in the current session to identify the cause, and correct any associated problems. Error: 25709, Severity: 16, State: 1. One or more event sessions failed to start. Refer to previous errors in the current session to identify the cause, and correct any associated problems. ■発生条件 SQL Server 2019 CU1 以下のバージョンの SQL Server を使っている環境に対して、SQL Server 2019 CU2 以降の更新プログラムを適用することで発生します。 ■影響 このエラーによるお客様のアプリケーションへの影響はありません。 拡張イベントの"feature_restriction_usage"は、SQL Server CEIP サービス に関連して動作する拡張イベントセッション"telemetry_xevents"で使用されています。 SQL Server CEIP サービスは、Microsoft が SQL Server の使用状態に関する情報を収集する内部機能となっており、お客様のすべてのアプリケーションの動作には影響しません。 SQL Server CEIP サービスに関する詳細は下記の公開情報をご確認ください。 SQL Server の使用状況および診断データの収集を構成する (CEIP) https://docs.microsoft.com/ja-jp/sql/sql-server/usage-and-diagnostic-data-configuration-for-sql-server?view=sql-server-ver15 ■注意事項 SQL Server CEIP サービスを停止/無効化している環境や、SQL Server CEIP サービスが"telemetry_xevents"の定義を変更する前に、SQL Server サービスが再起動された場合は引き続きエラーが記録される可能性があります。 SQL Server CEIP サービスの無効化はサポートされないため、起動した状態にする必要があります。 なお、SQL Server CEIP サービスが起動した状態であれば拡張イベントセッションの定義変更は通常数分で完了し、定義変更後は基本的に自動で"telemetry_xevents"が起動するため特に操作は不要です。
Changes to Knowledge Base articles used for Cumulative Updates
In March 2020 we introduced inline, short description of fixes in the master Cumulative Update KB articles. We call those descriptions “blurbs” and they replace many of the individual KB articles that existed for each product fix and contained brief descriptions. In other words, the same one-two sentence description that existed in a separate article before, now appears directly in the master CU KB article. For fixes that require longer explanation, provide additional information, workarounds, and troubleshooting steps, a full KB article is still created.July 10, 2018 Windows updates cause SQL startup issues due to "TCP port is already in use" errors
First published on MSDN on Jul 26, 2018 We have recently become aware of a regression in one of the TCP/IP functions that manages the TCP port pool which was introduced in the July 10, 2018 Windows updates for Windows 7/Server 2008 R2 and Windows 8.
