.NET 3 framework "needed" when already manually installed

Hi,

I've found that the .NET 3 framework (928416) is detected by WSUS (and Windows
Update, and Microsoft Update) as "needed" even when it has already been manually
installed. It will be downloaded and installed, apparently successfully, just
as if it really weren't already there. (Note that the recent security update
for .NET 3 is also detected as needed if it hasn't been installed.)

Once .NET 3 has been (re)installed by WSUS/WU/MU it is then correctly detected
as already installed. This seems to happen consistently, so I suspect a fault
in the detection logic, or perhaps in the downloadable installer.

I used this link to download the .NET 3 installer for the manual install:

<http://go.microsoft.com/fwlink/?LinkId=70848>

I also tested using the download from this link, the behaviour was no different:

<http://www.microsoft.com/downloads/details.aspx?FamilyID=10cc340b-f857-4a14-83f5-25634c3bf043&DisplayLang=en>

Harry.

"Harry Johnston" <> wrote in message
news:%...
> Hi,
>
> I've found that the .NET 3 framework (928416) is detected by WSUS (and Windows
> Update, and Microsoft Update) as "needed" even when it has already been manually
> installed.


Are the packages identical? If not, perhaps what you get from the AU site
is not all of it but just some modules which are more up-to-date that way.
Check with the Event viewer or verbose logging to see what is really
happening.


---


> It will be downloaded and installed, apparently successfully, just
> as if it really weren't already there. (Note that the recent security update
> for .NET 3 is also detected as needed if it hasn't been installed.)
>
> Once .NET 3 has been (re)installed by WSUS/WU/MU it is then correctly detected
> as already installed. This seems to happen consistently, so I suspect a fault
> in the detection logic, or perhaps in the downloadable installer.
>
> I used this link to download the .NET 3 installer for the manual install:
>
> <http://go.microsoft.com/fwlink/?LinkId=70848>
>
> I also tested using the download from this link, the behaviour was no different:
>
> <http://www.microsoft.com/downloads/details.aspx?FamilyID=10cc340b-f857-4a14-83f5-25634c3bf043&DisplayLang=en>
>
> Harry.

Robert Aldwinckle wrote:

>> I've found that the .NET 3 framework (928416) is detected by WSUS (and Windows
>> Update, and Microsoft Update) as "needed" even when it has already been manually
>> installed.
>
> Are the packages identical?

Well, they should be; they're both the .NET 3.0 framework. I don't know of any
way to compare the frameworks - well, I suppose I could do a file comparision
between a machine that hasn't installed from WSUS vs. one that has. It's
definitely downloading the entire framework, though, not just a few pieces; the
download is 59MB (when obtained from WSUS).

> If not, perhaps what you get from the AU site
> is not all of it but just some modules which are more up-to-date that way.
> Check with the Event viewer or verbose logging to see what is really
> happening.

There's nothing of interest in the event log or in WindowsUpdate.log; I'm not
aware of any way to enable "verbose logging" for the Windows Update Agent.

Harry.

"Harry Johnston" <> wrote in message
news:...
> Robert Aldwinckle wrote:
>
>>> I've found that the .NET 3 framework (928416) is detected by WSUS (and Windows
>>> Update, and Microsoft Update) as "needed" even when it has already been manually
>>> installed.
>>
>> Are the packages identical?
>
> Well, they should be; they're both the .NET 3.0 framework. I don't know of any
> way to compare the frameworks - well, I suppose I could do a file comparision
> between a machine that hasn't installed from WSUS vs. one that has. It's
> definitely downloading the entire framework, though, not just a few pieces; the
> download is 59MB (when obtained from WSUS).
>
>> If not, perhaps what you get from the AU site
>> is not all of it but just some modules which are more up-to-date that way.
>> Check with the Event viewer or verbose logging to see what is really
>> happening.
>
> There's nothing of interest in the event log or in WindowsUpdate.log; I'm not
> aware of any way to enable "verbose logging" for the Windows Update Agent.


Too bad. FWIW I got some very informative Application log entries
in the Event Viewer for updating .NET Framework 2.0 I was assuming
the same sort of things would have been available for the new version too.
(I don't have Vista so I haven't seen this update.)

You could also Run... ProcMon. That would capture any registry and file
operations which might be related to the log entries you do see.
Fortunately each separate write of a log record is recorded along with its
length, which allows us to infer a more accurate timestamp for each one.
Tip: use Notepad's Status bar with Word Wrap off and press End to see
the approximate length of a line. The length of its write usually would be
exactly 1 byte longer.

Are you getting a reboot request? Then you could also check the versions
of the files listed in PendingFileRenameOperations (in the registry)
and that the modules involved are identical in each of your two cases.
(If any of the versions of the set of modules to be copied is different
in each case it could explain your symptom.)
Also make sure that those copy/renames were being done by the boot.
Tip: Filever (e.g. from the Support Tools package) is a very handy
way of listing module details including version in a cmd window.

The reboot prompt gives a convenient checkpoint so you can find out
what should be happening without doing too much analysis.
Before I noticed the Event Viewer records I thought this was
the best way of seeing this information. Ultimately it is still
the clearest method of finding out what the boot should be doing
for the update(s). The next level of detail that I would try
(which is probably not relevant for your case) is to Run... ProcMon
with its Log Boot option. Analysing that trace could be tedious
but if the renames/writes were not being done it might give some
clues as to why.


Good luck

Robert
---

Robert Aldwinckle wrote:

>>>> I've found that the .NET 3 framework (928416) is detected by WSUS (and Windows
>>>> Update, and Microsoft Update) as "needed" even when it has already been manually
>>>> installed.

> You could also Run... ProcMon. That would capture any registry and file
> operations which might be related to the log entries you do see.

Hmmm. Worth a try, I suppose, though in the circumstances it seems likely that,
as usual when installing a product that is already installed, nothing much will
be happening.

> Are you getting a reboot request?

Nope.

Harry.

"Harry Johnston" <> wrote in message
news:...
> Robert Aldwinckle wrote:
>
>>>>> I've found that the .NET 3 framework (928416) is detected by WSUS (and Windows
>>>>> Update, and Microsoft Update) as "needed" even when it has already been manually
>>>>> installed.
>
>> You could also Run... ProcMon. That would capture any registry and file
>> operations which might be related to the log entries you do see.
>
> Hmmm. Worth a try, I suppose, though in the circumstances it seems likely that,
> as usual when installing a product that is already installed, nothing much will
> be happening.


As I explained I suspect you are likely to find that one of the packages
is more complete than the other. So, yes, perhaps "nothing much will be
happening" but what will be happening may be significant. ; )


>
>> Are you getting a reboot request?
>
> Nope.



If nothing else is using the .NET 3.0 modules I suppose that might be valid.
Have you looked at the install log? It usually explains these things too.
It would be most useful I suspect to have a log from a successful install
to compare with or at least get some input from someone who has one.


Good luck

Robert
---

[crosspost to microsoft.public.dotnet.framework.setup]

Robert Aldwinckle wrote:

>>>>>> I've found that the .NET 3 framework (928416) is detected by WSUS (and Windows
>>>>>> Update, and Microsoft Update) as "needed" even when it has already been manually
>>>>>> installed.

>>> You could also Run... ProcMon. That would capture any registry and file
>>> operations which might be related to the log entries you do see.
[...]
> As I explained I suspect you are likely to find that one of the packages
> is more complete than the other. So, yes, perhaps "nothing much will be
> happening" but what will be happening may be significant. ; )

OK, this did turn up something - thanks. It seems that the .NET 3 framework
installers available for download include an earlier version of MSXML6 than the
installer provided with WSUS/WU/MU.

If I install the downloaded .NET 3 framework, then update MSXML6 to 6.0.3890
(KB927977) or later, WSUS no longer offers the .NET 3 framework. This provides
a workaround for my problem, so I can stop worrying about it.

However, this still indicates a problem with either the WSUS/WU/MU package (if
KB927977 is not required by .NET 3) or the downloaded packages (if it is).

These are the links I used to download the installers:

<http://go.microsoft.com/fwlink/?LinkId=70848>

<http://www.microsoft.com/downloads/details.aspx?FamilyID=10cc340b-f857-4a14-83f5-25634c3bf043&DisplayLang=en>

Harry.

"Harry Johnston" <> wrote in message
news:...
> [crosspost to microsoft.public.dotnet.framework.setup]
>
> Robert Aldwinckle wrote:

>> As I explained I suspect you are likely to find that one of the packages
>> is more complete than the other. So, yes, perhaps "nothing much will be
>> happening" but what will be happening may be significant. ; )
>
> OK, this did turn up something - thanks. It seems that the .NET 3
> framework installers available for download include an earlier
> version of MSXML6 than the installer provided with WSUS/WU/MU.


Good find!


>
> If I install the downloaded .NET 3 framework, then update MSXML6
> to 6.0.3890 (KB927977) or later, WSUS no longer offers the .NET 3
> framework. This provides a workaround for my problem, so I can stop worrying about it.
>
> However, this still indicates a problem with either the WSUS/WU/MU
> package (if KB927977 is not required by .NET 3) or the downloaded packages (if it is).


At least they have bothered to think about XML dependencies at all.
Previously that was a hard-to-diagnose problem for Win2000 users
trying to install a rollup that wouldn't stick until Dave Hawley did some
detailed analysis for us like yours--and that was before I had heard of
ProcMon. ; )

http://groups.google.com/group/micro...d6dcccecd2952c


Thanks for sharing your resolution.


Robert
----