prompted to install sec. update for Dot Net - KB928365

  • Thread starter Thread starter davexnet
  • Start date Start date
D

davexnet

Hello, I've got WU set to prompt me, rather than automatically
install.. Today I got a WU alert asking me to install KB928365,
a security update for .Net 2.0.

As far as I can see, I don't actually have any flavor of .Net
installed at all. Why would I get this update?

Thanks for any info.
 
You sure about that?

How to determine which versions of the .NET Framework are installed and
whether service packs have been applied
http://msdn.microsoft.com/en-us/kb/kb00318785.aspx

NB: .NET Framework 3.5 also installs .Net Framework 2.0 SP2 and 3.0 SP2
--
~Robear Dyer (PA Bear)
MS MVP-IE, Mail, Security, Windows Client - since 2002

 
PA Bear said:
You sure about that?
Click to expand...

Thanks for responding. The article mentions searching this folder:
%systemroot%\Microsoft.NET\Framework

I have no such folder. However, using the registry method, I do see some
item listed.
They are version one and version 2. I believe I had it installed about a
year ago and uninstalled it.

Could these redundant entries be causing WU to screw up?

Secondly, there is a comment at the bottom of the article you linked to,
which says the registry method is unreliable for determining which dot net
is installed for the very reason that they may be left overs from
uninstalled
versions.
 
Here's how to get rid of any "leftovers" & get back to square one.

Step #1 => Before doing anything else, write down what .NET Framework
versions are currently installed. (See previous reply.)

Step #2 => Now see Resolution Method 2 in this KB article (ignore the
subject & referenced error numbers): http://support.microsoft.com/kb/923100

After running the .NET Framework Cleanup Tool (not the Windows Installer
Cleanup utility), reinstall all .NET Framework versions (but only the ones
you wrote down in #1 above) manually using the download links in KB923100
then run Windows Update manually to install security updates for same.

NB: If you remove .NET Framework 3.5 (SP1) using the tool, reinstalling .NET
Framework 3.5 will also install .Net Framework 2.0 SP2 and 3.0 SP2; then
Windows Update will offer .NET Framework 3.5 SP1.

IMPORTANT! => If you remove .NET Framework 3.5 (SP1), reinstall your .NET
Framework versions in the following order:

1. .Net Framework 3.5, then...
2. .Net Framework 1.1, then...
3. .Net Framework 1.1 SP1

NB: KB923100 references this page:
http://blogs.msdn.com/astebner/archive/2006/05/30/611355.aspx. Please read
ALL of it as well as the related page
http://blogs.msdn.com/astebner/pages/8904493.aspx before using the .NET
Framework Cleanup Tool.

Step #3 => Check-in at Windows Update and install any critical security
updates offered.
 
Thanks for responding. The article mentions searching this folder:
%systemroot%\Microsoft.NET\Framework

I have no such folder. However, using the registry method, I do see some
item listed.
They are version one and version 2. I believe I had it installed about a
year ago and uninstalled it.

Could these redundant entries be causing WU to screw up?
Click to expand...

Just verifying that %SYSTEMROOT% is just a variable that is typically
C:\WINDOWS\SYSTEM32 (or C:\WINNT\SYSTEM32 for Win2K.)

Finally, if the software is not installed, the update should fail
anyways. I don't think there would be any problem letting it run. You
could always manually run Windows update, then uncheck it for
installing. I think that can be saved so it won't ask again.

Finally, .NET is pretty ubiqutous this days. Many program rely on it,
even if it doesn't seem obvious. Most anything written in VB2005/VC2005
would probably be .NET2 based.
 
Andrew Rossmann said:
Just verifying that %SYSTEMROOT% is just a variable that is typically
C:\WINDOWS\SYSTEM32 (or C:\WINNT\SYSTEM32 for Win2K.)

Finally, if the software is not installed, the update should fail
anyways. I don't think there would be any problem letting it run. You
could always manually run Windows update, then uncheck it for
installing. I think that can be saved so it won't ask again.

Finally, .NET is pretty ubiqutous this days. Many program rely on it,
even if it doesn't seem obvious. Most anything written in VB2005/VC2005
would probably be .NET2 based.

--
If there is a no_junk in my address, please REMOVE it before replying!
All junk mail senders will be prosecuted to the fullest extent of the
law!!
http://home.comcast.net/~andyross
Click to expand...
Thanks for the info - I'm running on a old Win2k PC, it's too small and slow
for DotNet (It's a 4GB partition). I don't need it, since it runs minimal
SW.

I'm going to follow PA Bears link and find out how to clean it up.
I suspect those orphan registry entries are the problem.
 
Just verifying that %SYSTEMROOT% is just a variable that is typically
C:\WINDOWS\SYSTEM32 (or C:\WINNT\SYSTEM32 for Win2K.)
Click to expand...

Actually C:\WINDOWS or C:\WINNT.

Harry.
 
In
Harry Johnston said:
Actually C:\WINDOWS or C:\WINNT.
Click to expand...

"Typically" being the keyword wrt win2000, as clearly stated in the
addressed Usenet groups.

The actuality is determined by:

Control Panel -> System -> Advanced (tab) -> Environment Variables (button)

and I don't find "%SYSTEMROOT%" defined there, in either the "System" or
"User" variables ... do you? Or are you just blowing smoke out your ass?
 
"Typically" being the keyword wrt win2000, as clearly stated in the
addressed Usenet groups.
Click to expand...

Yes, it is certainly possible for the system root to be in a non-standard
location. It can even be on a different drive. However, my point was that the
SystemRoot environment variable references the root of the operating system
folders, not the system32 subdirectory.
The actuality is determined by:

Control Panel -> System -> Advanced (tab) -> Environment Variables (button)

and I don't find "%SYSTEMROOT%" defined there, in either the "System" or
"User" variables ... do you? Or are you just blowing smoke out your ass?
Click to expand...

Only some environment variables are assigned by the settings in that control
panel. Others are assigned during system startup or the user logon process.

Go to Start Menu, Run (or just Start Menu if on Vista or later) and type this:

cmd /k set

and press ENTER. That will show you the complete set of environment variables
given to new user processes, and it will contain SystemRoot. (Or at least it
ought to. It certainly does on my computer.)

Harry.
 
Back
Top