Windows Updates filenames confusion

[wupsy2016]

My recent W7 NTLite integration used Windows Updates Downloader (with ulz lists) to get the required updates.

All of those files had names in this format -  'Windows6.1-KB2872339-x64.msu'
 

But when I went to Microsoft Catalog to grab some missing updates, I noticed that all the files have a much longer filenames.

 

For example: 'AMD64-all-windows6.1-kb2803821-v2-x64_d89c709a7908f771a78e27933081f269c2abfb9d.msu'

 

Additionally, each file is in its own, separate folder. The above file was inside this folder: 'Security Update for Windows 7 for x64-based Systems (KB2803821.'

Could someone explain why the naming difference?

 

I intend to build another integration and will probably merge the the short-name files with the long-names, as long as it won't cause NTLite to hemorrhage.

[submix8c]

That's becuase the ULZ were created from manually obtianing the direct links from the actual KB download.

Whereas the MS Downloads via Windows/MS Update are from a diggerent server (AFAIK).

 

IOW...

AMD64-all-windows6.1-kb2803821-v2-x64_d89c709a7908f771a78e27933081f269c2abfb9d.msu

..is the exact same file as...

windows6.1-kb2803821-v2-x64.msu

 

And I'm betting you're using the OUTDATED ULZ file from the WUD website.

 

See this for the latest -

http://www.msfn.org/board/topic/139877-post-sp1-updates-for-windows-7-updated-25032015/#entry1100970

Be aware that the Wincert website (which is link inside that post) requires you to be a member to get it.

 

You're spinning your wheels (like all the other WUD obsolete ULZ users).

 

HTH

[Glenn9999]

Could someone explain why the naming difference?

Anything directly associated with the Windows Update system, like Microsoft Catalog, will have a checking mechanism, which is the SHA-1 of the file appended to the file name. If you run a SHA-1 of the file, it should match that last part of the named file.   You'll also notice this if you obtain the links directly off Windows Update as other alternatives to WUD will do.

[wupsy2016]

Thanks guys.

 

submix86: The reason I asked my question was to avoid 'spinning my wheels', LOL.

 

I'm aware that the ulz lists used by W.U.D are way out of date, and that's why I grabbed 100 updates from Catalog to use in my next integrated build.

 

I was just curious about the naming difference. From what you've said, I understand now that the two files that I used as an example are actually one and the same (given identical KB numbers, of course).

 

I've no idea where W.U.D. gets its files from, but it seems to me that the app is perhaps renaming the files to the shorter version. And, because the Catalog files are each contained in a separate folder, stripping that folder from the file. Is that correct?

 

Glenn9999. Thanks, also. The other reason I asked for enlightenment was because of the 'AMD64' prefix of the Catalog-derived files. I've just found an explanation on Tom's site, so I'll post it below for the benefit of anyone else who's as dumb as I am :-)

 

The "amd64" files are required for a 64-bit system. They have the initials "AMD" in them because the 64-bit extension of the Intel x86 architecture was actually created by AMD, and the first 64-bit x86-compatible processors were AMD processors. So when Microsoft first started adapting 64-bit Windows they were designing it for AMD processors.

 

 

I also now understand that file-names (plus file-path) shouldn't be too long, for integration purposes.

 

So it seems sensible that I remove the containing folder from each Catalog download, and perhaps also truncate the long file names to a shorter version.

[submix8c]

Pick an ULZ. Copy it to a different folder (to retain the original). Rename to xxx.ZIP. Extract the UL. Rename to xxx.XML. Open it. You'll see that the files come directly from MS. WUD simply facilitates the display/download of the contents. The format of the UL is very specific. Indeed, it "could" be used to download just about anything that has a direct (and GOOD, mind you) link. Bad file links will cause a HALT of the WUD awaiting a response.

 

HTH

[wupsy2016]

Aha! That's what I was trying to understand.

 

So W.U.D. would take this Catalog folder and file:

'Security Update for Windows 7 for x64-based Systems (KB3093513)\AMD64-all-windows6.1-kb3093513-x64_2c1e5ff88f5acbd93bb3d80b09731db3fb85eb1e.msu'

 

...then discard the folder and rename the file to: 'Windows6.1-KB3093513-x64.msu'?

 

Have I got that right?

[Glenn9999]

I've no idea where W.U.D. gets its files from, but it seems to me that the app is perhaps renaming the files to the shorter version. And, because the Catalog files are each contained in a separate folder, stripping that folder from the file. Is that correct?

When you do a program (full disclosure, I actually did one of those "alternatives to WUD") and download a file, you can control how you save a file - basically save it to whatever you want. AFAIR from when I considered doing a "make a UL" function in mine, I think when someone cooks up a UL a "friendly name" get specified along with the URLs.

 

The other reason I asked for enlightenment was because of the 'AMD64' prefix of the Catalog-derived files.

 

Actually what you posted wasn't *quite* right.   Intel actually cooked up a 64-bit processor architecture of their own.  The problem with it was that it wasn't very 32-bit backwards compatible so it floundered.  So basically like a HD-DVD, Blu-ray thing, you had a format war and an eventual winner (AMD64).   I don't know what tipped the balance in the end.  Anyhow, you'll see patches with IA64 as well in older Windows as well as more modern things like .NET patches.

 

So it seems sensible that I remove the containing folder from each Catalog download, and perhaps also truncate the long file names to a shorter version.

Most will handle the long file names okay, but if you have something that claims to batch process (NLite or my patcher being two instances), grouping the files into the same folder is almost always best so they can all be picked up at once in a controlled fashion.

 

[wupsy2016]

Much appreciated, Glenn9999, your explanations were most helpful. I think I'm just about ready to do a second NTLite integration.

 

I find it somewhat ironic (more like 'frustrating') that we have access to the greatest repository of information that's ever been assembled on this planet, and yet it can take a totally disproportionate amount of time to get answers to what, for those 'in the know' are fairly simple questions. I've been trying for weeks to get the answers that you and submix8c have provided above.

 

It's a bit like using a calculator - you need to have an idea of the answer you're expecting. But for the more esoteric information, like a lot of IT, you need to first find an assembly of experts in that field, and then, frame the question in exactly the right way to encourage someone to respond.

 

Sure, there's more information around than ever before, but a great deal of this data site is stored in the cerebrums of people who are either unable or unwilling to share it.

 

Thanks.

[Kelsenellenelvian]

I answered your questions at wincert days ago

[wupsy2016]

Not me, Kelsenellenelvian, possibly my son-in-law. He's doing the same exercise as me, but prefers to do his own research :-)

 

Guys, I've been wading through my Updates, renaming them and tossing away the containing folders.

 

I've come across several folders that contain one or more .msu files, plus an exe.

Example-folder contents:
 

AMD64-all-mpsyschk_b2f2b1fe31b7ecec4ea43004bc4e2c7b7171b74f.exe

AMD64-all-windows6.1-kb3004375-v3-x64_c4f55f4d06ce51e923bd0e269af11126c5e7196a.msu

AMD64-all-windows6.1-kb3031432-x64_e648abe279c8b0095a57271ffbab5d5d376da558.msu

 

As I said earlier, I'm renaming the files like this one from the above folder to:

'Windows6.1-KB3031432-x64.msu'

 

I plan to merge the renamed files with an older collection of short-named updates I downloaded via W.U.D.

 

But I'm not sure what to do with the accompanying exe.

Edited January 22, 2016 by wupsy2016

[wupsy2016]

Since yesterday, I've been thinking about my previous post.

 

To sum up, I downloaded a bunch of Updates from Microsoft Catalog, but five folders each contain an exe file plus one or more Update files.

 

I'm thinking now that I should just pull out the .msu files and merge them with the main collection, then toss the exes along with the containing folders.

 

Does this sound right?

 

If so, just a 'Yes' would be enough for me to go on.

 

Thanks.

[submix8c]

I say *again* that MS has two separate repositories, one for Windows/Microsoft Update and one for Downloads (manual). If you get one of the ones from WU and get the same KB# from Downloads (using the KB#) you'll find they have different dates. HOWEVER, they *should* be identical. The Catalog (as well as WU/MU) uses a different repository (WSUS Server). This is the same method Big Corporations use to roll out Updates instead of allowing Users (employees on the LAN) to go to MU/WU.

 

Does this clarify your post #6 (which is a wrong assumption)? You'll find, if you look in a Log file (?can't remember the name) it will give where WU got it from. It will *not* be the same place as getting it from the KB#.

 

Hint - when going to the KB# Download, right-click on the "If your download didn't start..." link, copy it, and paste it into Notepad. Those are the Links that are used for WUD ULZ files, not the ones from WU.

 

It's called (loosely described) Sub-Domains.

 

HTH (again...)

[submix8c]

(sigh...) An EXE may *very well have* an MSU *inside* it! Also note *some* updates do *not* directly Integrate and *must* be installed via a Command Script (the OEM way).

 

Is there some reason you don't wish to get the ULZ from WinCert and note the very specific information (that you *can* read)?

 

I *suppose* I could get the latest, do the downloads, and give you a full list to compare to, but I'm rather busy with another project.

 

As an *alternative* I could get the ULZ, and strip out everything but the KB# and Description. I will *not* post it (complete) here as the project is over *there* and some of the forums have a mutual respect for one anothers' efforts. If they *wanted* to share it here they would *post* it here, but the people would have to sign up *here* to download, same as WinCert.

 

 

edit - I will *again* note that MS Catalog will give you Superseded updates, whic you do NOT want a a *newer* Fix will simply *overwrite* it!

http://www.merriam-webster.com/dictionary/supersede

KB#123 has abc.sys in it.

KB#456 is newer and has abc.sys in it.

Forget KB#123 because KB#456 replaces it in its entirety.

Trust me on this, I've done some merry chases eliminating older updates for XP via KB articles.

 

------------------------------

 

EDIT#2 - Apparently, the OP is in need of explanation. If I sounded rude, my apologies. I just hate to see someone repeat the efforts that other noble contributors have already done (wherever). I will agree that the OP probably has quite a bit of experience, but (no offense) it may be a bit shy of what a lot of "Been There, Done That" folks have experienced.

 

Addendum - Want to *really* get confused? Use "WSUS Offline" and compare results to WUD (using the latest ULZ) results. It's not pretty, due to the fact that "WSUS Offline" isn't as exacting as WUD ULZ (latest) is.

 

And trust me on this... "Been There, Done That".

 

HTH

 

Side note - We know that WSUS and WUD get Updates directly from MS, as opposed to "Encrypted" download lists/locations (even though they *nay* get them direct.) Just sayin'....

Edited January 22, 2016 by submix8c

[Glenn9999]

(sigh...) An EXE may *very well have* an MSU *inside* it! Also note *some* updates do *not* directly Integrate and *must* be installed via a Command Script (the OEM way).

 

I *suppose* I could get the latest, do the downloads, and give you a full list to compare to, but I'm rather busy with another project.

 

As an *alternative* I could get the ULZ, and strip out everything but the KB# and Description.

(Just a general response and not to any specific person) FWIW, I'm not sure the question at issue anymore.  But a number of patch options will serve extra EXE files, which I figure are run as part of the process of actually patching the system.   Older patches are EXEs by default, and those EXEs will be served by both WU and MS's public download links.  But the newer ones vary depending on whether you get it from WU or download.  The variance is whether you get MSU or CAB, which are processed by different patching systems if you have those files (WUSA versus DISM).  MSUs are served by Microsoft's public download links (like Microsoft Update Catalog), while CABs are served by WU.   A MSU file is actually a renamed CAB file which contains the CAB file served by WU along with an associated data file and any non-file serving EXEs.  And if you want to get even more confused, certain KB numbers actually serve a number of patches reflected by still different KB numbers.

 

If you have a concern of which patch files are actually "current", you can drop a list of patches off of WU or the offline scanner file (WSUSSCN2.CAB)  along with file links and compare, which is a function I've been playing with (more off and on).  It works well if you want to keep a flash drive of patches off of all the systems you encounter if you want to automate it, but the best you can do otherwise is drop a list to text.  For instance (a snippet, edited to keep the forum from serving hyperlinks):

 

----------------------------------------------------------------

2016-01-12          Update for Windows 8.1 for x64-based Systems (KB2976978)

Listing of File URLs:

EnableTask - hxxp://download.windowsupdate.com/d/msdownload/update/software/updt/2015/12/enabletask_7323565d9cdc11ab9f0efd489554e7de30fc6e4a.exe(24KB)

windows8.1-kb2976978-v13-x64 - hxxp://download.windowsupdate.com/d/msdownload/update/software/updt/2015/12/windows8.1-kb2976978-v13-x64_2459843122db53d0f4568cf87ce3f11721165f26.cab(3220KB)

Description:

Install this update to resolve issues in Windows. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article for more information. After you install this item, you may have to restart your computer.

----------------------------------------------------------------

 

A lot of where confusion lies is that there's just so many options for those that are technically and nothing particularly uniform.

Edited January 23, 2016 by Glenn9999

[wupsy2016]

Glenn999, thanks for your helpful explanation. I think I'm finally beginning to get a handle on the update process :-)

 

I only found out about the Catalog site a week ago, and now I see from your notes and others, that there's at least one more update download site that I haven't utilized.

 

In your last post you said, "FWIW, I'm not sure the question at issue anymore".

 

I'll summarize where I'm up to and add one last question.

 

First, I created a slipstreamed W7 Ultimate 64-bit ISO using W.U.D and NTLite

I installed W7, then found 223 updates available via Windows Update. Downloaded all from Microsoft Catalog and added them to a new ISO.

After the rebuilt W7 was installed, there were still 100 updates available via Windows Update. Downloaded all of those from Microsoft Catalog.

Now I'm preparing a third NTLite integration to try and minimize the amount of online updating required post install.

But I've run into a confusing hitch. Of the 100 updates noted above, 96 are standalone single files.

All 96 were previously contained in folders of their own, which I've since discarded to make it easier for NTLite.

There are 4 files remaining in the main download folder. They're in 3 sub-folders as one folder contains 2 files.

But each of these 3 folders also contains an executable.

Here are the properties and size of the executable in each KB-numbered folder:
(KB3004375): Description - MP System State Check. Size - 23.2K
(KB3033929): Description - MP System State Check. Size - 23.2K
(KB3031432): Description - MP System State Check. Size - 23.2K  
(This last folder is the one with two .msu files - KB3031432-x64 and KB3004375-v3-x64.msu)

I'm wondering if these exes are there simply to enable a standalone install of each .msu file\files, as might occur where someone wants to install only one or two updates.

If that's the case, I'm thinking I should pull out the four files and merge them with the main group, then discard the sub-folders and exes.

 

Comments?