Any disadvantage with no integrating the hotfixes?

[ponghy]

Ok, One question more:

If I decide to integrate (i.e., direct integration) the hotfixes in the CD, when repairing or updating the system the new files will be copied, since the old files have been overwritten. Right, and what about doing the following operation?

SFC /SCANNOW

You know, this command scans and repairs (if needed) system files missing or corrupt. I think the new files will be written to the disk. If I would decide to not integrate (calling the hotfixes from svcpack.inf, but the files in the CD have SP2 version), the above operation will overwrite the new version files with the old ones (supplied with original SP2). Right?

So, it seems that direct integration is full of advantages, and no one disadvantage, except when replacing old hotfixes or when adding new ones (I use for this task a directory synchronizer app, and a diff app).

Edited April 23, 2006 by ponghy

[RogueSpear]

Because Ryan includes the .cat files for each hotfix, the new versions of files replaced are protected under SFC. The new files really do become a native part of your source. This is really a fantastic benefit. So much so that I really can't believe that Microsoft has not actually devised an officially supported method that does what Ryan has been doing for over a year now.

If there is any possible downside, and this is pretty debatable anyway, if you use Ryan's Update Pack you're getting all of the hotfixes on Windows Update. I suppose someone somewhere may not want a specific hotfix for one reason or another, but really you're getting a source that should be as up to date and bug free as possible natively. I think that if someone makes a blanket statement that this way of integrating hotfixes is somehow not as good as using /integrate, then they don't have a full understanding of both how Microsoft is doing things and how Ryan is doing things.

This really is one of those rare instances where the unofficial way of doing something is superior in every conceivable fashion to the official Microsoft way. For all of their greed, DRM fetishes and attempts to patent the air we breathe, Microsoft really does do a pretty good job planning things out and tieing everything together in a sensible manner. This is just one of those things that makes me scratch my head.

[ponghy]

I hope this will be my last question, he he.

If I integrate (direct integration mode, for example the included in nLite), what happens if a hotfix needs to be uninstalled in order to install a newer one? I know when a hotfix is installed, Windows creates a folder "$hf_mig$" in %windir% in order to put the files backed up there. How to workaround this (or is not necessary)?

Again, thanks for all your help

[andrew84uk]

I hope this will be my last question, he he.

If I integrate (direct integration mode, for example the included in nLite), what happens if a hotfix needs to be uninstalled in order to install a newer one? I know when a hotfix is installed, Windows creates a folder "$hf_mig$" in %windir% in order to put the files backed up there. How to workaround this (or is not necessary)?

Again, thanks for all your help

If you intergrate direct using Ryans packs, from my undastanding you will not be able to uninstall it. That's one of the downsides.

For example, you decide just to add the hotfix way with no i386 intergration, your hotfix can be uninstalled just using control panel / add remove programs. good luck

[RogueSpear]

It's the same as installing a hotfix in the first place. Files are being replaced. Why should there be a difference? I think the only difference is that the newer hotfix .cat file takes over as far as file signing goes. So if you integrate hotfix KB000001 that replaces ntfs.sys, you should have KB000001.cat in the svcpack directory (and a corresponding entry in svcpack.inf) in your source install media. So let's say after you complete an install KB000002 comes out that further updates ntfs.sys. KB000002.cat will now hold the signature for ntfs.sys that SFC uses.

I'm not sure if I got all the terminology 100% correct, but I think that's the basic idea.

[RyanVM]

Actually, $hf_mig$ serves an entirely different purpose than you think. The KB article below should explain everything you need to know.

http://support.microsoft.com/?scid=kb%3Bes%3B824994&x=9&y=11