boco wrote:Sync hell of chaos. MS screwed the pooch. Need I say more?
What would be certainly interesting is what happens if we would use BITSADMIN (or Powershell) to retrieve the catalog. Could someone try if the result is valid?
- Code: Select all
bitsadmin.exe /TRANSFER WSUSOU_Get_Catalog /DOWNLOAD http://download.windowsupdate.com/microsoftupdate/v6/wsusscan/wsusscn2.cab <full path here>\WSUSSCN2.CAB
and . . . . .
Please try PowerShell, too.
- Code: Select all
powershell Start-BITSTransfer http://download.windowsupdate.com/microsoftupdate/v6/wsusscan/wsusscn2.cab <full path here>\wsusscn2.cab
Boco, I agree that the results would be interesting - but I fail to see the point. It has already been established that the question of getting the bad download vs the good one is related to the M$ load-balancing scheme - and their lack of synchronization across their update servers.
Assuming that M$ hasn't corrected the sync problem and purged the bad files, (which we cannot know except by experiment), the fact that these two commands returned "good" files when tried once proves nothing.
We'd have to repeat these commands about a dozen or so times, (and perform the same file transfers with wget at the exact same time, using the same DNS settings, on the same ISP), to see if there is a statistically significant difference. (
i.e. The two internal commands
ALWAYS returned "good" files where wget returned the "bad" files at least 50% of the time.)
As far as I can tell, it shouldn't matter
HOW you get the files, as you're going through the same load-balancing "Sync hell of chaos" each time.
Now you have "my curiosity riz" as they say. . . Is there something specifically and peculiarly different about how btsadmin and/or PowerShell get files that would cause
different results than what wget returns? If so, how and/or why? If this is provably true, maybe WSUS Offline should use these commands instead of the more generic wget?
What say ye?
Jim (JR)