Forum Discussion
Upgrade task sequence skipping locations and failing
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.
- 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.
- 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.
- 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.
I have good clients that work and clients that don't in the same deployment collection. Both clients can browse the http location using edge. Both clients are using the same boundary group. The TS deployment is set to download content locally before starting. A good client lists the files in the log and does not skip http location. A bad client does not even list the files from the location and just skips. The only difference with the clients is that they are in different IP ranges or ad site but in the same boundary group. It makes no sense why one client would skip and the other does not skip. Could there be any network internal routing rule preventing the clients outside my known network? Other os operating system packages work on other networks from the same DP so there should be no reason why this location does not when it is the same DP smspkg$ location.