retrieve "selfcontained" updates instead of "delta compression" updates
T. Valen
Is there a possibility to make the Windows Update Service use
"selfcontained" updates instead of these "delta compression" updates?
Does MS provide the selfcontained (oldstyle) updates alternatively?
The reason is that we need to do a lot of analysis with a new binary
before it can be used in a highly secured environment. Even if the
update is a signed MS update, the file is not authorized to be used on
production systems before full analysis has been done. Unfortunately the
new Delta Compression method MS uses, makes it impossible to analyse a
binary before it's being authorized because the final file (which is the
result of the patching process) is not contained in the patch any more.
Therefore the file could only be analysed _after_ patching has been
completed, which just makes no sense.
Any idea how to solve this?
Thx,
T.
T. Valen
>> "selfcontained" updates instead of these "delta compression" updates?
> we're talking about the same thing)
I don't think we're talking about the same thing.
See
http://en.wikipedia.org/wiki/Binary_delta_compression
or
http://msdn.microsoft.com/en-us/library/ms811406.aspx
AFAIK it has nothing to do with express updates. Instead, it's some new
format MS uses to apply patches. Just take a look at a file like
windows6.0-kb958690-x86-rc_7e745ae6a0604c0f88afc74bbb63f55b5e9b976d.cab
(will have different name in your WSUS)
This is a patch for Vista and it contains just the delta, no real
binaries. That's the problem.
Lawrence Garvin [MVP]
news:12409991...@nix.hamcom.de...
>>> Is there a possibility to make the Windows Update Service use
>>> "selfcontained" updates instead of these "delta compression" updates?
>> The "delta compression" updates, aka Express Installation Files, (if
>> we're talking about the same thing)
>
> I don't think we're talking about the same thing.
I believe we are. This is the technology (from 2005) that makes Express
Installation Files possible in the WSUS environment.
> AFAIK it has nothing to do with express updates. Instead, it's some new
> format MS uses to apply patches. Just take a look at a file like
>
> windows6.0-kb958690-x86-rc_7e745ae6a0604c0f88afc74bbb63f55b5e9b976d.cab
KB958690 is a classic example of an update available as a full installation
package or an Express Installation Package. In WSUS, these three files
possibly exist in the file library for the Vista update:
Windows6.0-KB958690-x86.cab (1.1mb)
Filename: 7FDDE98ED4EDD6B95FE918C3AADBA4A488D66A2.cab
Windows6.0-KB958690-x86.psf (5.2mb)
Filename: A2317A7696C5EF58ACECCE8773B670C43583D0FE.cab
Windows6.0-KB958690-x86-EXPRESS.cab (56kb)
Filename: AA03DE7522EDB0FD2DE27EACA4CB1194E1DB62E0.psf
If you have Express Installation Files enabled on your WSUS Server, you'll
have all three files. If you do not have Express Installation Files enabled,
you'll have only one file:
Windows6.0-KB958960-x86.cab
> This is a patch for Vista and it contains just the delta, no real
> binaries. That's the problem.
No, it's not the problem. In a WSUS environment *both* sets of files are
available to a server with EIF enabled, only the FULL installation package
is available to a server without EIF enabled.
Now, if you're obtaining this package from the download center, then you're
on your own to make sure you get the right installation package.
In a WSUS environment, the Windows Update Agent first queries the metadata
to determine if EIF files have been downloaded. If EIF files are available,
the WUA downloads the EIF files (in this case the *EXPRESS.cab and .psf
files); if the EIF files are not available, the WUA downloads the full
installer.
In the case of browsing direct to the WU/MU site, you have no choice in the
matter, but EIF (delta compression updates) are not designed for deployment
direct to client systems in a WU/MU environment, so generally the client
browing to WU/MU will also download the fullfile installer.
One exception to this would be if a Vista client has peercaching for WU/MU
enabled, in which case that Vista client *might* download the delta update
(which is significantly larger than the fullfile installer -- as you can see
above), for subsequent peer-distribution to other Vista clients on the same
LAN segment.
--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)
MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
T. Valen
>>> we're talking about the same thing)
>> I don't think we're talking about the same thing.
> I believe we are.
Thanks a lot for the explanation. I think that helped! I'll take a
closer look at all this later.
T. Valen
I think I still have not understood the internals of WSUS updates that
are provided as a CAB file.
I set up a new WSUS 3 server and had it replicate Vista Updates (no
express updates). So I found a lot of cab files in my WSUSContent.
I took 77A3F2B89D7B3E0A311B9338E8863C7AE3647708.cab and unpacked it.
Looking at the file _manifest_.cix it seems this is kb944533.cab
(Security Update for IE).
There's not one .exe file in this cab (nor is there in any other CAB).
But _manifest_.cix contains references to a lot of .exe files
(iexplore.exe), which makes me believe that all the executables in that
list are to be patched by this cab-file.
Maybe I was wrong in my original posting where I assumed that the
patches were DeltaCompression patches. Anyway, the patch obviously does
not contain a binary in its final (patched) form.
"In former times" patches contained the full patched binary that was to
replace the original one. This does not seem to be the case anymore.
So I may have to change my question:
How do I get to see the patched binaries without actually applying the
patch on the destination machine?
Thanks in advance!
T.
Lawrence Garvin [MVP]
> So I may have to change my question:
> How do I get to see the patched binaries without actually applying the
> patch on the destination machine?
My suggestion -- if you want to see what an update is intended to update --
is to read the associated KB article or MSRC bulletin, which will explicitly
enumerate the files to be updated, their version numbers, sizes, and dates.
For example, KB944533 is a Cumulative Security Update for IE (MS08-010), and
to complicate matters, it's been superseded a dozen times over. Nonetheless,
if you review the KB article, you'll see that it updates in excess of 30
files, more or less, depending on the specific version of IE and the
platform it's installed on. I can tell you, from the KB article, that
iexplore.exe is replaced on IE7 installations.
Frankly, I wouldn't begin to try to analyze what goes on inside a CAB file
distributed via WU/MU or WSUS; I'm just not interested at that level of
detail. I might be interested in knowing specifically which files are
affected (if I have some actual issue with update post-installation), and
I've noted where to get that information from -- much more easily than
trying to analyze the contents of a CAB file.
Beyond that bit of information -- I'm not going to be much help to you on
that question. If you're really interested in digging into that level of
internals, then I'd suggest a good Windows Internals book.
T. Valen
rolled out. There are some tools we need to run against the newly
patched files and off course we want to automate that as much as
possible. So reading an article about the patch is not really an option.
> Frankly, I wouldn't begin to try to analyze what goes on inside a CAB
> file distributed via WU/MU or WSUS;
That's exactly what I need. So I'll post this question here in a new thread.
> If you're really interested in digging into that level
> of internals, then I'd suggest a good Windows Internals book.
I would, but who can tell which book does dig that deep?
Lawrence Garvin [MVP]
> The whole purpose of this is analysing the new file before it's being
> rolled out. There are some tools we need to run against the newly
> patched files and off course we want to automate that as much as
> possible. So reading an article about the patch is not really an option.
>
>
>> Frankly, I wouldn't begin to try to analyze what goes on inside a CAB
>> file distributed via WU/MU or WSUS;
>
> That's exactly what I need. So I'll post this question here in a new
> thread.
Posting in a new thread isn't going to change reality.
>> If you're really interested in digging into that level
>> of internals, then I'd suggest a good Windows Internals book.
>
> I would, but who can tell which book does dig that deep?
You can.. if you actually open it and read it. At that point, either it goes
deep enough to answer your question, or it doesn't.
Dave Mills
files.
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.