strel

Silent .NET Maker synthesized 20100118 - W2K/XP/2K3 x86

1,004 posts in this topic

Would it be OK to always just use KB960043-v4?

Isn't this how Windows Update basically works?

In absence of actual documentation, all we CAN do is presume the every superseeding hotfix already contains the code included in the previous versions, as well as some repairs done to it. Of course, this will only work if every following version contains the exact files that were in the previous ones.

That's what I do.

bphlpt, I read your PM; hope this helps.

Cheers

0

Share this post


Link to post
Share on other sites

Isn't this how Windows Update basically works?

In this case, I don't know. Since KB960043 is included inside the hotfix exe that requires its presence, I don't know what WU/MU does when it comes across another hotfix that also has KB960043, but a different version. Is it applied also? Potentially 8 times since I found 8 versions? Only versions 4, 7 and 8, or what? What happens if you use version 8 only, even though the hotfix was distributed with version 1 or 2? I have found NO documentation from M$. As I said, I can try it, but how do we verify it? If I can't find anyone who knows, I guess that's what I'll have to do, but it's frustrating. (But isn't everything M$ does?)

When I get this done I'll have to rely a LOT on you guys to test this.

Cheers and Regards

0

Share this post


Link to post
Share on other sites

Bear with me for a while:

I recently completely uninstalled a normally installed .NET 3.5 SP1 (including .NET 2.0 SP2 and 3.0) package and installed a modified package (SNMSynth) with included hotfixes (including those made with IExpress using the above mentioned method). Windows Update showed I missed a few packages, so I extracted the .msp files from those hotfixes and tried manually. The first one asked for Netfx30a_x86.msi (would not work with the modified one from SNMSynth, but it did work with the original one from dotnetfx35.exe). In the end, I extracted the files from the other .msp files, renamed them and replaced them manually. This also did the trick.

Conclusion (although it took me a while to get there): Windows Update checks the file version and reports what you need.

BTW, I used the QFE (not the GDR) files wherever possible.

0

Share this post


Link to post
Share on other sites
Conclusion (although it took me a while to get there): Windows Update checks the file version and reports what you need.

BTW, I used the QFE (not the GDR) files wherever possible.

I'll just have to make sure I do just as good a job as WU since I'll be doing WU's job as I build the administrative installs. :) Thanks for the heads up regarding WU's sensitivity about Netfx30a_x86.msi as it stands now. I'll try to make sure that is not an issue. One way that comes to mind to check that would be to build a pack but leave out on purpose one hotfix/update and see if WU is then able to add just that one update without complaining about needing Netfx30a_x86.msi. As I get further along, I'm sure that that and other issues will be resolved.

Cheers and Regards

0

Share this post


Link to post
Share on other sites

bphlpt,

KB960043 is not really an update. It only sets a flag on the system. It is called dual branch servicing.

I think it's better to paste this text from MS that explains something:

What does Dual Branch Servicing mean exactly?
With Dual Branch Servicing, updates for GDR class releases (updates, cumulative updates, and security updates) will contain two versions of the payload,
a "clean" payload that carries only the security fix but no cumulative hotfixes and a second payload that contains the cumulative hotfixes
together with the security fix.

The first "clean" payload would be installed for customers who have no hotfixes applied (most customers) and the second cumulative payload
would be installed for customers who do have one or more hotfixes installed.

How does Dual Branch Servicing work?
When a customer installs a hotfix, the update is installed together with baseliner update 960043.
This baseliner is like a flag in the computer that tells future updates for that product that a hotfix is present.

In the future, when the customer installs a GDR-class update (including a security update), that update looks for the baseliner.
If the baseliner is not present because no previous hotfix was installed, the payload from the GDR branch is installed so that the hotfix is not included.

If the baseliner is found, then the payload from the LDR branch, such as the cumulative binary that includes a hotfix, is installed.
This model prevents the installation of the GDR for customers who have hotfixes installed.

The advantage of this model is that if you install a GDR first, the GDR payload will then be applied.
If you then install a hotfix, and the baseliner is present, the GDR will be automatically switched from the GDR branch payload to the LDR branch payload.
This prevents a regression of the hotfix.

Most probably you've already read that.

I think because we are making a complete installer instead of updating previous framework installs, you'll be OK with the last version of the baseliner. No need to install previous versions.

Cheers.

0

Share this post


Link to post
Share on other sites

Thanks for the heads up regarding WU's sensitivity about Netfx30a_x86.msi as it stands now

Let me make myself clear as much as I can. Netfx30a_x86.msi was required by the .NET 3.0 .msp files which don't install correctly through SNMSynth, and they are the same ones that have to be extracted and repacked with IExpress. Those didn't install properly (even when repacked) with SNMSynth, so I started them manually and discovered this interesting fact, i.e. their dependency with the unmodified Netfx30a_x86.msi.

As a consequent result, they won't install from Windows Update either.

Hope that helps.

0

Share this post


Link to post
Share on other sites

Anyone out there use the Request only hotfixes? I'm looking at the logic needed to be able to advise the user which have been superceded by what. strel didn't do this and I'm beginning to see why. Some of them are quite intermingled and overlapped so it's not at all a straight forward decision. It would be a lot easier to figure that if it's request only then the user is responsible for deciding whether to put it in there or not. If it's there it will get ingtegrated, which is essentially what strel did. Problems with that? Does anyone care?

Has anyone used NDP1.1sp1-KB946922-X86.exe? The exe and msp are both named NDP1.1SP1xxxxx, but the info from M$ about KB946922 says that it applies to .NET 2.0. I'm tempted to believe M$, but I'm more likely to either ignore it if it's there, or again since it's a request only hotfix apply it even though I don't think it's right and let the user be responsible. Opinions?

Any other requests for changes/additions/subtractions? NOW is a good time to let me know.

Cheers and Regards

Edited by bphlpt
0

Share this post


Link to post
Share on other sites

My opinion is of that the updates must consist of script the integration of all, also the optional ones, that they could be added for in agreement integration the interest of each user.

Cheers

0

Share this post


Link to post
Share on other sites

A better example of what I meant is:

We start out with:

17-Nov-2004 06:57 1.1.4322.2048 2,138,112 Mscorlib.dll

16-Nov-2004 03:28 1.1.4322.2048 2,514,944 Mscorsvr.dll

07-Dec-2004 03:29 1.1.4322.2048 2,506,752 Mscorwks.dll

Then KB890340 says it changes only:

07-Dec-2004 20:27 1.1.4322.2053 2,138,112 Mscorlib.dll

07-Dec-2004 20:27 1.1.4322.2053 2,519,040 Mscorsvr.dll

07-Dec-2004 20:30 1.1.4322.2053 2,506,752 Mscorwks.dll

Then KB893251 says it changes only:

25-Mar-2005 23:34 1.1.4322.2310 2,138,112 Mscorlib.dll

31-Mar-2005 02:37 10,916 Mscorlib.ldo

29-Mar-2005 18:48 1.1.4322.2310 2,519,040 Mscorsvr.dll

29-Mar-2005 18:48 1.1.4322.2310 2,506,752 Mscorwks.dll

Then KB899181 says it changes only:

06-May-2005 22:37 1.1.4322.2323 2,138,112 Mscorlib.dll

06-May-2005 22:39 10,904 Mscorlib.ldo

06-May-2005 22:48 1.1.4322.2323 2,519,040 Mscorsvr.dll

06-May-2005 22:49 1.1.4322.2323 2,506,752 Mscorwks.dll

Then KB900822 says it changes only:

09-Jun-2005 05:46 1.1.4322.2331 2,138,112 Mscorlib.dll

09-Jun-2005 05:48 10,908 Mscorlib.ldo

09-Jun-2005 05:56 1.1.4322.2331 2,519,040 Mscorsvr.dll

09-Jun-2005 05:57 1.1.4322.2331 2,506,752 Mscorwks.dll

and it continues with 922542, 924421, 927495, 935224, 942228, 953297, 979906, and 2416447 all having later editions of those four files. So my thought was, if I could figure all the interactions out, if you have one of the later files, there is no need to apply the earlier ones because they will get overwritten anyway. strel already does this with the "standard" updates - he only applies the latest, if it supercedes an earlier file. But the request only hotfixes are VERY intermingled so it's complicated. Other opinions?

Cheers and Regards

Edited by bphlpt
0

Share this post


Link to post
Share on other sites

Here's one: I think you should create a poll and see how many of the users out there actually use those hotfixes. My opinion is that most of the people that use SNMSynth here are just end-users like me (and I have no idea what those specific hotfixes are for, in spite of the elaborate explanations), that use .NET just for application compatibility.

I was going to ask if request-specific hotfixes were superseded by any normally released hotfix, and then I found this on page 1:

These hotfixes are not deployed through win/ms update or direct ms download link, but only after asking MS for them. They are not needed to stop update system prompting .NET hotfixes. They fix uncommon errors, may be not fully tested, and ocassionally may be included on future regular updates, so up to you to use them or not.
I tried one of them once (can't remember which one), and it integrated successfully; at this point many of those could very well be replaced by regular updates.

Cheers

0

Share this post


Link to post
Share on other sites
Here's one: I think you should create a poll and see how many of the users out there actually use those hotfixes.

Good idea. Please, be my guest and set it up. That would be most helpful.

...many of those could very well be replaced by regular updates.

Many of them are, or at least seem to be.

Cheers and Regards

Edited by bphlpt
0

Share this post


Link to post
Share on other sites

I'm with Spoiled Brat. Framework is only used here for application compatibility.

Besides that, the request-only hotfixes solve some rather isolated problems that the most of us never will encounter.

So my vote will be against the inclusion of request-only hotfixes.

As for the file versions, Microsoft policy for updates states that a non-security update cannot "supersede" a security update, so even if later versions of the updates are released, if they don't fix any security update they cannot be identified as superseding even though, functionally speaking - it does, in fact, do exactly that.

This was explained on technet a while ago.

On a side note, there are some outdated runtimes in the package, it would be nice to know what runtimes are needed and their latest versions. For example Visual C runtimes 2005 and 2008 and 2010 for .Net 4.

Cheers.

0

Share this post


Link to post
Share on other sites

Hi guys,

I'm trying to install the merged package from nLite or through RunOnce and I always seem to get the same error. Do you guys have any clue on what I'm doing wrong? I've noticed the XPS path, does this have anything to do with the KB that's needed for 3.5 integration?

Update: I've extracted my 2K3DNF20SP230SP235SP1.exe and I see the folder XPS in DNF30 but the folder is empty.

Thanks!

FYI, this is for Windows Server 2003R2 SP2 32bits en-us with a butt load of updates that are slipstreamed with nLite.

post-310602-0-57117400-1291050384_thumb.

post-310602-0-57117400-1291050384_thumb.

Edited by Spoui
0

Share this post


Link to post
Share on other sites

Update: I've extracted my 2K3DNF20SP230SP235SP1.exe and I see the folder XPS in DNF30 but the folder is empty.

OK, after reading the posts regarding thx4thepen issue, it seems that I have the same problem regarding Xcopy. I will try to elevate the cmd box from which I run the script to see if xcopy will succeed.

Update: I've ran the script with an elevated cmd interface and \DNF30\XPS is still empty. :( I will check the process log that it will generate.

Edited by Spoui
0

Share this post


Link to post
Share on other sites

The log says nothing that's clearly pointing to a failure of access and I can use xcopy from the cmdline I opened to run the script by trying a simple xcopy file.txt C:\.

I am starting to run out of ideas, any help would be appreciated.

I have attached a list of all the files that are in my directory and my .ini settings are the following:

PROCESSDNF11=NO

PROCESSDNF20=NO

PROCESSDNF3520=YES

PROCESSDNF3530=YES

PROCESSDNF3535=YES

TARGETOS=2K3

T13ADDONS=YES

ROEADDONS=

ALSOINSTALLERS=YES

MERGEFXS=YES

SILENT=

COMPRATIO=

What's in between has been left to default.

Thanks

post-310602-0-88760400-1291058040_thumb.

Edited by Spoui
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.