Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security NTBugtraq
[Top] [All Lists]

Re: SUS strange language behaviour with Microsoft .NET Framework Service

Subject: Re: SUS strange language behaviour with Microsoft .NET Framework Service Pack 2
Date: Mon, 27 Sep 2004 13:19:01 -0400
Summary of responses:

Paul Adare said;

Regarding the downloads of the Framework, this is a common question
about SUS and is by design. Unlike other language specific OS patches
which can only be applied to a matching language OS, the Framework
service packs can be applied to any language. IOW, the Framework SP in
Chinese can be applied to an English Windows XP system. This is why it
appears that the language setting is being ignored for the Framework
SPs. You can find more info on this by googling the Microsoft SUS news
group.

Rick Newton said;

I too can confirm this oddity in SUS...  I however, only have English
"selected" (the default) and for several of the updates pulled down to
my SUS server I've obtained copies for between 6 and 10 languages.  It
doesn't happen for every update downloaded only some (thank god...).
I've gotten Italian, Korean, Chinese (both), Russian, German, etc. ...
And as I say, XP SP2 isn't the first update to come to me in multiple
languages!  If you get an answer to this problem before I do I look
forward to cleaning out all the non-requested language files...

As an aside, for those using SUS... I've just finished with MS Support
on a different SUS issue.  Perhaps this information might be useful to
others utilizing SUS:

I had a few systems that were once listed in my AD 2003 domain, and
reporting to SUS, which were then removed from the domain/SUS and moved
to a satellite office with VPN connectivity for reaching our Terminal
Server; these systems after being moved were still attempting to contact
the SUS server for updates.

All "visible" (e.g.: registry, etc.) references to the SUS server had
been changed back to Windows Update (e.g.: Automatic Updates, registry
entries). Since the SUS server refuses connections from anything but the
segment it is on, the systems were being refused.  Thankfully, the
systems were getting their updates successfully from the Windows Update
site (although a little later than expected).

However, they were appearing on the SUS logs as refused connections.  It
took about a month to correct (due to travel to the secondary site,
etc.) and the execution of several tools supplied by MS Support, and
several scripts of my own for delivery and information collection,
without resolution (everything appeared correct) before the following
was suggested and resolved the issue...

The culprit turned out to be the URLLOG.DAT file (the file can be found
on systems that reported to a SUS server in C:\Program
Files\WindowsUpdate\v4). This file contained information pointing back
to the SUS server. Deleting the file resolved the issue.

Rob Pickering said;

<saw the same thing and added>
As an interesting sidenote, the SUS content directory (for a
installation that has only choosen English as it's language)now exceeds
1.2Gb, that's a lot of patches!

Cheers,
Russ - NTBugtraq Editor

-----
NTBugtraq Editor's Note:

Want to reply to the person who sent this message? This list is configured such 
that just hitting reply is going to result in the message coming to the list, 
not to the individual who sent the message. This was done to help reduce the 
number of Out of Office messages posters received. So if you want to send a 
reply just to the poster, you'll have to copy their email address out of the 
message and place it in your TO: field.
-----

<Prev in Thread] Current Thread [Next in Thread>