Hello,
I apologize in advance if this issue has already been discussed in another thread. I have gone through the vast majority of the discussions, but I have not come across this specific issue anywhere. I've been trying to identify the root cause of the issue, and I was wondering whether you've come across a similar problem before and, if so, whether you happened to find a workaround or a fix for it?
I have the following environment configuration:
Server_1 : Distribution point, Management point, ...
Server_2 : Software update point (NO Distribution point role), ..
My SCCM environment is configured to patch servers using ADR Software Update Deployments. All Windows Server operating system versions are patched successfully except for Windows Server 2025. As you know, Windows Server 2025 uses UUP technology, which has probably caused headaches for many of us. The issue I'm running into is that the download gets stuck at 0% and eventually fails. I managed to identify the error, and I'm currently trying to find a viable and acceptable solution.
I came across the issue while monitoring Delivery Optimization jobs:
Status
ownloading
TotalBytesDownloaded:0
BytesFromHttp:0
DownloadDuration:00:26:44
SourceURL : http://server2.testdomain.com/Content/...
Of course, it fails because I don't have the packages hosted at this location. For UUP content, the client receives metadata that cointains references to http://server2.testdomain.com/Content/.. which is typical of UUP/WSUS content handling. I noticed that the server successfully downloads/builds the patch and patches successfully if I stop the Windows Update service, restart the SMS Agent Host service, and immediately trigger the installation.
At that point, I can see the correct information:
ContentLocationRequest
Calling back with the following distribution points
Distribution Point=http://server1.testdomain.com/SMS_DP_SMSPKG$/945fce80....
Distribution Point=https://server1.testdomain.com/CCMTOKENAUTH_SMS_DP_SMSPKG$/945fce80....
The working machine received and actual Content Location Request response and got DP locations on : server1
I believe the following that the actual failure is:
Client -> WSUS/SUP server2 -> tries UUP content URL -> HTTP404 (because I don't store the content at that location)
The logs show that, with the following workflow, everything is downloaded and installed successfully:
Cleint -> SUP(server2) -> MP provides content locations -> DP(server1)
Why did stopping windows update service and restarting ccmexec fix it:
LocationServices -> New ContentLocationRequest -> MP lookup -> Fresh DP selection
The problem is that, unfortunately, after some time, the first (failing) workflow is always used again. So, have you come across any workaround that allows you to continue taking advantage of ADR automation for Software Updates? Or is the only option to manually create update packages and distribute them, or perhaps deploy them as an application package instead?
Thank you in advance for any advice. I'd also be happy to provide the logs if needed.
I apologize in advance if this issue has already been discussed in another thread. I have gone through the vast majority of the discussions, but I have not come across this specific issue anywhere. I've been trying to identify the root cause of the issue, and I was wondering whether you've come across a similar problem before and, if so, whether you happened to find a workaround or a fix for it?
I have the following environment configuration:
Server_1 : Distribution point, Management point, ...
Server_2 : Software update point (NO Distribution point role), ..
My SCCM environment is configured to patch servers using ADR Software Update Deployments. All Windows Server operating system versions are patched successfully except for Windows Server 2025. As you know, Windows Server 2025 uses UUP technology, which has probably caused headaches for many of us. The issue I'm running into is that the download gets stuck at 0% and eventually fails. I managed to identify the error, and I'm currently trying to find a viable and acceptable solution.
I came across the issue while monitoring Delivery Optimization jobs:
Status
ownloadingTotalBytesDownloaded:0
BytesFromHttp:0
DownloadDuration:00:26:44
SourceURL : http://server2.testdomain.com/Content/...
Of course, it fails because I don't have the packages hosted at this location. For UUP content, the client receives metadata that cointains references to http://server2.testdomain.com/Content/.. which is typical of UUP/WSUS content handling. I noticed that the server successfully downloads/builds the patch and patches successfully if I stop the Windows Update service, restart the SMS Agent Host service, and immediately trigger the installation.
At that point, I can see the correct information:
ContentLocationRequest
Calling back with the following distribution points
Distribution Point=http://server1.testdomain.com/SMS_DP_SMSPKG$/945fce80....
Distribution Point=https://server1.testdomain.com/CCMTOKENAUTH_SMS_DP_SMSPKG$/945fce80....
The working machine received and actual Content Location Request response and got DP locations on : server1
I believe the following that the actual failure is:
Client -> WSUS/SUP server2 -> tries UUP content URL -> HTTP404 (because I don't store the content at that location)
The logs show that, with the following workflow, everything is downloaded and installed successfully:
Cleint -> SUP(server2) -> MP provides content locations -> DP(server1)
Why did stopping windows update service and restarting ccmexec fix it:
LocationServices -> New ContentLocationRequest -> MP lookup -> Fresh DP selection
The problem is that, unfortunately, after some time, the first (failing) workflow is always used again. So, have you come across any workaround that allows you to continue taking advantage of ADR automation for Software Updates? Or is the only option to manually create update packages and distribute them, or perhaps deploy them as an application package instead?
Thank you in advance for any advice. I'd also be happy to provide the logs if needed.
