Upgrade task sequence skipping locations and failing

Hi Liam,

The log entry"Skipping http(s) path" usually indicates that the task sequence found the content location, but the client doesn't consider the HTTP/HTTPS source as a valid download location and therefore skips it.

A few things I would check:

1. Boundary Group Content Associations
   • Confirm the affected clients are still assigned to a boundary group that contains the DP and allows content location fallback.
   • Verify the clients receive correct content locations in LocationServices.log.
2. DP Communication Settings
   • If there were recent certificate, IIS, PKI, or Enhanced HTTP changes, verify clients can authenticate to the DP.
   • Test content download outside the task sequence by deploying a normal package/application to an affected client.
3. Content Access Configuration
   • Review the task sequence deployment option:
     • Download content locally when needed
     • Download all content locally before starting TS
   • Ensure the OS Upgrade Package is successfully distributed and validated on the DP.
4. Client Logs
   • Check:
     • LocationServices.log
     • DataTransferService.log
     • ContentTransferManager.log
     • CAS.log
     • smsts.log
   • These logs usually reveal why the HTTP/HTTPS location is being rejected.

Since the task sequence was working a few weeks ago and only affects clients outside the IT network, I would focus first on Boundary Groups, DP assignment, and any recent HTTPS/Enhanced HTTP changes.

Microsoft References:

• Create an OS Upgrade Task Sequence:
  https://learn.microsoft.com/mem/configmgr/osd/deploy-use/create-a-task-sequence-to-upgrade-an-operating-system https://learn.microsoft.com/en-us/intune/configmgr/osd/deploy-use/create-a-task-sequence-to-upgrade-an-operating-system
• Manage Operating System Upgrade Packages:
  https://learn.microsoft.com/mem/configmgr/osd/get-started/manage-operating-system-upgrade-packages https://learn.microsoft.com/en-us/intune/configmgr/osd/get-started/manage-operating-system-upgrade-packages
• Configure Content Pre-caching for Task Sequences:
  https://learn.microsoft.com/mem/configmgr/osd/deploy-use/configure-precache-content https://learn.microsoft.com/en-us/intune/configmgr/osd/deploy-use/configure-precache-content

My suspicion is that the client is receiving the package locations but is rejecting the HTTP/HTTPS source due to a boundary group or DP communication/authentication issue rather than a problem with the upgrade package itself.

Those lines don’t, by themselves, show an HTTP download failure. They show OSDUpgradeWindows skipping HTTP locations while evaluating where it can access the upgrade source. Windows Setup needs an accessible filesystem path; the task sequence’s content-download mechanism handles getting HTTP content onto the client.

The first thing to check is the task sequence deployment’s Distribution Points settings, especially whether the affected collection is receiving a deployment configured to Access content directly from a distribution point.

1. Compare the deployment used by a working IT-network client with the one used by a failing client. The same task sequence can have different deployment settings.
2. For a small test collection, use Download content locally when needed by the running task sequence, or download all content locally before starting, rather than direct DP access. Confirm the upgrade package finishes downloading before Windows Setup starts.
3. If direct access is intentional, verify that the upgrade package is available through a package share and that the failing clients can reach it using the identity the task sequence actually uses. Successful IIS access doesn’t prove SMB access or authentication works across those networks.

Also collect the lines immediately before and after these messages through to the first actual error and exit code. If a content download is being attempted, check ContentTransferManager.log and DataTransferService.log; LocationServices.log can help confirm which DP locations the client received. A clean CAS log alone doesn’t establish that the transfer succeeded.

Given that the failures follow network boundaries, comparing deployment options and testing the actual content-access route is more useful than redistributing an already-distributed package. If the deployment already downloads locally, the next question is whether staging failed or the upgrade step failed to use the staged path—the “Skipping http(s)” lines alone can’t distinguish those.