Windows XP Computers Contacting Windows Update Web Site

I have a WSUS 3.0 server with over 100 Windows XP Clients attached to it. The
XP Computers daily check in for updates and they only download updates when I
have released the updates from the WSUS server console. GPO is also
configured for each computer to contact the WSUS server for updates. We
monitor our Internet connection for performance and security reasons. I've
noticed that even though the computers are only to download updates from the
WSUS Server, they daily contact 65.55.13.88 and 207.46.17.124. Both sites are
registered to Microsoft and a considerable amount of bandwidth is used by the
computers to contact these websites. My problem is, how do I disable this
behavior?

"Benny" <> wrote in message
news:954C9F0A-FEF2-432D-863F-...
>I have a WSUS 3.0 server with over 100 Windows XP Clients attached to it.
>The
> XP Computers daily check in for updates and they only download updates
> when I
> have released the updates from the WSUS server console. GPO is also
> configured for each computer to contact the WSUS server for updates. We
> monitor our Internet connection for performance and security reasons. I've
> noticed that even though the computers are only to download updates from
> the
> WSUS Server, they daily contact 65.55.13.88 and 207.46.17.124. Both sites
> are
> registered to Microsoft and a considerable amount of bandwidth is used by
> the
> computers to contact these websites. My problem is, how do I disable this
> behavior?

Have no idea.

First you'll need to demonstrate that these connections are actually coming
from the Windows Update Agent -- otherwise, this isn't a WSUS problem.

Documenting the actual traffic moving across the connections, or the ports
that the connection is being made on would be useful as well.

Just because the IP Addresses are registered to Microsoft does not mean it's
the Windows Update Agent doing the contacting; you know, there's probably a
dozen other applications on those Windows XP machines that might have an
interest in connecting to a website inside microsoft.com.


--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

Lawrence

Thank you for your reply. If you browse to either 65.55.13.88 or
207.46.17.124 web page, you'll find you have arrived at
http://update.microsoft.com/microsof....aspx?ln=en-us this is
the Windows Update Website.

I can provide a PDF with a log of the attempts from the different computers.
I'll have to check to see if I can get the actual port as well as the TCP/IP
address. Let me know if you'd like to see that log.


"Lawrence Garvin [MVP]" wrote:

> "Benny" <> wrote in message
> news:954C9F0A-FEF2-432D-863F-...
> >I have a WSUS 3.0 server with over 100 Windows XP Clients attached to it.
> >The
> > XP Computers daily check in for updates and they only download updates
> > when I
> > have released the updates from the WSUS server console. GPO is also
> > configured for each computer to contact the WSUS server for updates. We
> > monitor our Internet connection for performance and security reasons. I've
> > noticed that even though the computers are only to download updates from
> > the
> > WSUS Server, they daily contact 65.55.13.88 and 207.46.17.124. Both sites
> > are
> > registered to Microsoft and a considerable amount of bandwidth is used by
> > the
> > computers to contact these websites. My problem is, how do I disable this
> > behavior?
>
> Have no idea.
>
> First you'll need to demonstrate that these connections are actually coming
> from the Windows Update Agent -- otherwise, this isn't a WSUS problem.
>
> Documenting the actual traffic moving across the connections, or the ports
> that the connection is being made on would be useful as well.
>
> Just because the IP Addresses are registered to Microsoft does not mean it's
> the Windows Update Agent doing the contacting; you know, there's probably a
> dozen other applications on those Windows XP machines that might have an
> interest in connecting to a website inside microsoft.com.
>
>
> --
> Lawrence Garvin, M.S., MCITP:EA, MCDBA
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2009)
>
> My Blog: http://onsitechsolutions.spaces.live.com
> Microsoft WSUS Website: http://www.microsoft.com/wsus
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>

"Benny" <> wrote in message
news:541A453D-8867-4AB0-B708-...
> Lawrence
>
> Thank you for your reply. If you browse to either 65.55.13.88 or
> 207.46.17.124 web page, you'll find you have arrived at
> http://update.microsoft.com/microsof....aspx?ln=en-us this
> is
> the Windows Update Website.

Okay. But that doesn't prove anything except that you've identified the IP
Address.


> I can provide a PDF with a log of the attempts from the different
> computers.

A log of the attempts from where? If you already have log files, then
presumably those log files also answer the WHY? Now, if we're talking about
the WindowsUpdate.log file, then I'd rather you simply POST the text of the
WindowsUpdate.log into this thread, showing your WUAgent attempting to
connect to microsoft.com.

One possibility, though, if you have installed Forefront Client Security and
you're not maintaining Forefront updates on your WSUS Server is that the
WUAgent may be getting redirected to microsoft.com to get the Forefront
Definition Updates - which would involve a significant amount of bandwidth
(~300mb per day per PC). I don't know exactly how the FCS and WUA interact
about the FCS updates if they're not on the assigned WSUS server. (I'm still
learning Forefront.) -- but I do know that FCS proxies it's update
detection/download process through the Windows Update Agent and the
Microsoft Update website if a WSUS server is not available.



--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

You've raised some interesting questions. We do not have Forefront Client
Security and the software and its updates are all automatically declined by
the WSUS server. We use a non-Microsoft product for antivirus and malware
protection. We do have the Windows XP Firewall enabled for all computers. I'm
attaching the WindowsUpdate log for one of the computers, I didn't see where
it tried to communicate with any server for updates other than our local WSUS
server (http://192.168.1.171). We use Websense to monitor and block our web
traffic. That is where I can find that I have computers communicating with
Microsoft. There are actually more than the two addresses that I initially
listed, but I thought I'd simplify the question. Websense will show me what
computers were communicating with the web and what websites they accessed and
what protocols they were using. In this cate, they are using port 443 to
communicate with Microsoft's web site.

Here is the Windows update log file from one of the computers:

2009-09-25 02:00:56:960 1420 d28 AU Forced install timer expired for
scheduled install
2009-09-25 02:00:56:960 1420 d28 AU UpdateDownloadProperties: 0 download(s)
are still in progress.
2009-09-25 02:00:56:960 1420 d28 AU Setting AU scheduled install time to
2009-09-26 08:00:00
2009-09-25 05:30:34:406 1420 d28 AU #############
2009-09-25 05:30:34:406 1420 d28 AU ## START ## AU: Search for updates
2009-09-25 05:30:34:406 1420 d28 AU #########
2009-09-25 05:30:34:406 1420 d28 AU <<## SUBMITTED ## AU: Search for updates
[CallId = {6427D486-8B66-4583-B671-3FB5B4A4E498}]
2009-09-25 05:30:34:406 1420 16c0 Agent *************
2009-09-25 05:30:34:406 1420 16c0 Agent ** START ** Agent: Finding updates
[CallerId = AutomaticUpdates]
2009-09-25 05:30:34:406 1420 16c0 Agent *********
2009-09-25 05:30:34:406 1420 16c0 Agent * Online = Yes; Ignore download
priority = No
2009-09-25 05:30:34:406 1420 16c0 Agent * Criteria = "IsHidden=0 and
IsInstalled=0 and DeploymentAction='Installation' and IsAssigned=1 or
IsHidden=0 and IsPresent=1 and DeploymentAction='Uninstallation' and
IsAssigned=1 or IsHidden=0 and IsInstalled=1 and
DeploymentAction='Installation' and IsAssigned=1 and RebootRequired=1 or
IsHidden=0 and IsInstalled=0 and DeploymentAction='Uninstallation' and
IsAssigned=1 and RebootRequired=1"
2009-09-25 05:30:34:406 1420 16c0 Agent * ServiceID =
{3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
2009-09-25 05:30:34:406 1420 16c0 Agent * Search Scope = {Machine}
2009-09-25 05:30:35:746 1420 16c0 Misc Validating signature for
C:\WINDOWS\SoftwareDistribution\SelfUpdate\Default \wuident.cab:
2009-09-25 05:30:35:793 1420 16c0 Misc Microsoft signed: Yes
2009-09-25 05:30:35:824 1420 16c0 Misc Validating signature for
C:\WINDOWS\SoftwareDistribution\SelfUpdate\Default \wuident.cab:
2009-09-25 05:30:35:824 1420 16c0 Misc Microsoft signed: Yes
2009-09-25 05:30:35:871 1420 16c0 Misc Validating signature for
C:\WINDOWS\SoftwareDistribution\SelfUpdate\Default \wsus3setup.cab:
2009-09-25 05:30:35:871 1420 16c0 Misc Microsoft signed: Yes
2009-09-25 05:30:35:886 1420 16c0 Setup *********** Setup: Checking whether
self-update is required ***********
2009-09-25 05:30:35:886 1420 16c0 Setup * Inf file:
C:\WINDOWS\SoftwareDistribution\SelfUpdate\Default \wsus3setup.inf
2009-09-25 05:30:35:902 1420 16c0 Setup Update NOT required for
C:\WINDOWS\system32\cdm.dll: target version = 7.4.7600.226, required version
= 7.4.7600.226
2009-09-25 05:30:35:949 1420 16c0 Setup Update NOT required for
C:\WINDOWS\system32\wuapi.dll: target version = 7.4.7600.226, required
version = 7.4.7600.226
2009-09-25 05:30:35:949 1420 16c0 Setup Update NOT required for
C:\WINDOWS\system32\wuapi.dll.mui: target version = 7.4.7600.226, required
version = 7.4.7600.226
2009-09-25 05:30:35:949 1420 16c0 Setup Update NOT required for
C:\WINDOWS\system32\wuauclt.exe: target version = 7.4.7600.226, required
version = 7.4.7600.226
2009-09-25 05:30:35:964 1420 16c0 Setup Update NOT required for
C:\WINDOWS\system32\wuaucpl.cpl: target version = 7.4.7600.226, required
version = 7.4.7600.226
2009-09-25 05:30:35:980 1420 16c0 Setup Update NOT required for
C:\WINDOWS\system32\wuaucpl.cpl.mui: target version = 7.4.7600.226, required
version = 7.4.7600.226
2009-09-25 05:30:35:980 1420 16c0 Setup Update NOT required for
C:\WINDOWS\system32\wuaueng.dll: target version = 7.4.7600.226, required
version = 7.4.7600.226
2009-09-25 05:30:35:995 1420 16c0 Setup Update NOT required for
C:\WINDOWS\system32\wuaueng.dll.mui: target version = 7.4.7600.226, required
version = 7.4.7600.226
2009-09-25 05:30:36:011 1420 16c0 Setup Update NOT required for
C:\WINDOWS\system32\wucltui.dll: target version = 7.4.7600.226, required
version = 7.4.7600.226
2009-09-25 05:30:36:011 1420 16c0 Setup Update NOT required for
C:\WINDOWS\system32\wucltui.dll.mui: target version = 7.4.7600.226, required
version = 7.4.7600.226
2009-09-25 05:30:36:011 1420 16c0 Setup Update NOT required for
C:\WINDOWS\system32\wups.dll: target version = 7.4.7600.226, required version
= 7.4.7600.226
2009-09-25 05:30:36:011 1420 16c0 Setup Update NOT required for
C:\WINDOWS\system32\wups2.dll: target version = 7.4.7600.226, required
version = 7.4.7600.226
2009-09-25 05:30:36:027 1420 16c0 Setup Update NOT required for
C:\WINDOWS\system32\wuweb.dll: target version = 7.4.7600.226, required
version = 7.4.7600.226
2009-09-25 05:30:36:042 1420 16c0 Setup * IsUpdateRequired = No
2009-09-25 05:30:43:177 1420 16c0 PT +++++++++++ PT: Synchronizing server
updates +++++++++++
2009-09-25 05:30:43:177 1420 16c0 PT + ServiceId =
{3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
http://192.168.1.171/ClientWebService/client.asmx
2009-09-25 05:30:43:302 1420 16c0 PT WARNING: Cached cookie has expired or
new PID is available
2009-09-25 05:30:43:302 1420 16c0 PT Initializing simple targeting cookie,
clientId = 2ee2e086-a6ec-41ed-9809-210b4bee3216, target group = WSUS, DNS
name = pc229.www.pueblowater.org
2009-09-25 05:30:43:302 1420 16c0 PT Server URL =
http://192.168.1.171/SimpleAuthWebSe...impleAuth.asmx
2009-09-25 05:31:48:808 1420 16c0 PT +++++++++++ PT: Synchronizing extended
update info +++++++++++
2009-09-25 05:31:48:808 1420 16c0 PT + ServiceId =
{3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
http://192.168.1.171/ClientWebService/client.asmx
2009-09-25 05:32:01:629 1420 16c0 Agent * Found 0 updates and 50
categories in search; evaluated appl. rules of 788 out of 1356 deployed
entities
2009-09-25 05:32:01:754 1420 16c0 Agent *********
2009-09-25 05:32:01:754 1420 16c0 Agent ** END ** Agent: Finding updates
[CallerId = AutomaticUpdates]
2009-09-25 05:32:01:754 1420 16c0 Agent *************
2009-09-25 05:32:01:770 1420 117c AU >>## RESUMED ## AU: Search for
updates [CallId = {6427D486-8B66-4583-B671-3FB5B4A4E498}]
2009-09-25 05:32:01:770 1420 117c AU # 0 updates detected
2009-09-25 05:32:01:770 1420 117c AU #########
2009-09-25 05:32:01:770 1420 117c AU ## END ## AU: Search for updates
[CallId = {6427D486-8B66-4583-B671-3FB5B4A4E498}]
2009-09-25 05:32:01:770 1420 117c AU #############
2009-09-25 05:32:01:770 1420 117c AU Featured notifications is disabled.
2009-09-25 05:32:01:770 1420 117c AU AU setting next detection timeout to
2009-09-26 06:07:27
2009-09-25 05:32:01:770 1420 117c AU Setting AU scheduled install time to
2009-09-26 08:00:00
2009-09-25 05:32:06:739 1420 16c0 Report REPORT EVENT:
{54813FB1-5B4D-4E84-BB4B-DE6771E8D900} 2009-09-25
05:32:01:754-0600 1 147 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Software
Synchronization Windows Update Client successfully detected 0 updates.
2009-09-25 05:32:06:739 1420 16c0 Report REPORT EVENT:
{590A38C6-9031-4B4B-AD71-682DADA72AC2} 2009-09-25
05:32:01:754-0600 1 156 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Pre-Deployment Check Reporting client status.
2009-09-25 05:34:06:461 1420 16c0 Report Uploading 2 events using cached
cookie, reporting URL =
http://192.168.1.171/ReportingWebSer...ebService.asmx
2009-09-25 05:34:06:477 1420 16c0 Report Reporter successfully uploaded 2
events.
2009-09-25 06:00:21:174 1420 d28 AU ########### AU: Uninitializing
Automatic Updates ###########
2009-09-25 06:00:25:518 1420 d28 Service *********
2009-09-25 06:00:25:518 1420 d28 Service ** END ** Service: Service exit
[Exit code = 0x240001]
2009-09-25 06:00:25:518 1420 d28 Service *************
2009-09-25 06:01:02:703 1420 4a4 Misc =========== Logging initialized
(build: 7.4.7600.226, tz: -0600) ===========
2009-09-25 06:01:02:734 1420 4a4 Misc = Process:
C:\WINDOWS\System32\svchost.exe
2009-09-25 06:01:02:734 1420 4a4 Misc = Module:
C:\WINDOWS\system32\wuaueng.dll
2009-09-25 06:01:02:703 1420 4a4 Service *************
2009-09-25 06:01:02:734 1420 4a4 Service ** START ** Service: Service startup
2009-09-25 06:01:02:734 1420 4a4 Service *********
2009-09-25 06:01:02:765 1420 4a4 Agent * WU client version 7.4.7600.226
2009-09-25 06:01:02:765 1420 4a4 Agent * Base directory:
C:\WINDOWS\SoftwareDistribution
2009-09-25 06:01:02:765 1420 4a4 Agent * Access type: No proxy
2009-09-25 06:01:02:796 1420 4a4 Agent * Network state: Connected
2009-09-25 06:01:55:982 1420 4a4 Agent *********** Agent: Initializing
Windows Update Agent ***********
2009-09-25 06:01:55:999 1420 4a4 Agent *********** Agent: Initializing
global settings cache ***********
2009-09-25 06:01:55:999 1420 4a4 Agent * WSUS server: http://192.168.1.171/
2009-09-25 06:01:55:999 1420 4a4 Agent * WSUS status server:
http://192.168.1.171/
2009-09-25 06:01:55:999 1420 4a4 Agent * Target group: WSUS
2009-09-25 06:01:55:999 1420 4a4 Agent * Windows Update access disabled: No
2009-09-25 06:01:56:117 1420 4a4 DnldMgr Download manager restoring 0
downloads
2009-09-25 06:01:56:251 1420 4a4 AU ########### AU: Initializing Automatic
Updates ###########
2009-09-25 06:01:56:318 1420 4a4 AU AU setting next sqm report timeout to
2009-09-25 12:01:56
2009-09-25 06:01:56:386 1420 4a4 AU # WSUS server: http://192.168.1.171/
2009-09-25 06:01:56:386 1420 4a4 AU # Detection frequency: 22
2009-09-25 06:01:56:386 1420 4a4 AU # Target group: WSUS
2009-09-25 06:01:56:386 1420 4a4 AU # Approval type: Scheduled (Policy)
2009-09-25 06:01:56:386 1420 4a4 AU # Scheduled install day/time: Every
day at 2:00
2009-09-25 06:01:56:403 1420 4a4 AU # Auto-install minor updates: Yes
(Policy)
2009-09-25 06:01:56:470 1420 4a4 AU Setting AU scheduled install time to
2009-09-26 08:00:00
2009-09-25 06:01:56:554 1420 4a4 AU Initializing featured updates
2009-09-25 06:01:56:588 1420 4a4 AU Found 0 cached featured updates
2009-09-25 06:01:58:321 1420 4a4 Report *********** Report: Initializing
static reporting data ***********
2009-09-25 06:01:58:321 1420 4a4 Report * OS Version = 5.1.2600.3.0.65792
2009-09-25 06:01:58:657 1420 4a4 Report * Computer Brand = IBM
2009-09-25 06:01:58:657 1420 4a4 Report * Computer Model = 821521U
2009-09-25 06:01:58:691 1420 4a4 Report * Bios Revision = 2EKT44AUS
2009-09-25 06:01:58:691 1420 4a4 Report * Bios Name = Phoenix
FirstBios(tm) Desktop Pro Version 2.0 for ThinkCentre.
2009-09-25 06:01:58:691 1420 4a4 Report * Bios Release Date =
2008-01-16T00:00:00
2009-09-25 06:01:58:691 1420 4a4 Report * Locale ID = 1033
2009-09-25 06:01:58:909 1420 4a4 AU AU finished delayed initialization
2009-09-25 06:01:58:909 1420 4a4 AU #############
2009-09-25 06:01:58:909 1420 4a4 AU ## START ## AU: Search for updates
2009-09-25 06:01:58:909 1420 4a4 AU #########
2009-09-25 06:01:58:926 1420 4a4 AU <<## SUBMITTED ## AU: Search for updates
[CallId = {4ED8AD06-D416-4907-88A2-F8560C3F9822}]
2009-09-25 06:02:00:356 1420 b84 Agent *************
2009-09-25 06:02:00:356 1420 b84 Agent ** START ** Agent: Finding updates
[CallerId = AutomaticUpdates]
2009-09-25 06:02:00:356 1420 b84 Agent *********
2009-09-25 06:02:00:373 1420 b84 Agent * Online = No; Ignore download
priority = No
2009-09-25 06:02:00:373 1420 b84 Agent * Criteria = "IsHidden=0 and
IsInstalled=0 and DeploymentAction='Installation' and IsAssigned=1 or
IsHidden=0 and IsPresent=1 and DeploymentAction='Uninstallation' and
IsAssigned=1 or IsHidden=0 and IsInstalled=1 and
DeploymentAction='Installation' and IsAssigned=1 and RebootRequired=1 or
IsHidden=0 and IsInstalled=0 and DeploymentAction='Uninstallation' and
IsAssigned=1 and RebootRequired=1"
2009-09-25 06:02:00:373 1420 b84 Agent * ServiceID =
{3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
2009-09-25 06:02:00:373 1420 b84 Agent * Search Scope = {Machine}
2009-09-25 06:03:25:182 1420 b84 Agent * Found 0 updates and 50 categories
in search; evaluated appl. rules of 590 out of 1356 deployed entities
2009-09-25 06:03:25:334 1420 b84 Agent *********
2009-09-25 06:03:25:334 1420 b84 Agent ** END ** Agent: Finding updates
[CallerId = AutomaticUpdates]
2009-09-25 06:03:25:334 1420 b84 Agent *************
2009-09-25 06:03:25:334 1420 b84 Report REPORT EVENT:
{6A9DFF6D-3A29-42E9-831D-8884EE69BDF3} 2009-09-25
06:01:56:588-0600 1 202 102 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Content Install Reboot completed.
2009-09-25 06:03:25:351 1420 f64 AU >>## RESUMED ## AU: Search for updates
[CallId = {4ED8AD06-D416-4907-88A2-F8560C3F9822}]
2009-09-25 06:03:25:351 1420 f64 AU # 0 updates detected
2009-09-25 06:03:25:351 1420 f64 AU #########
2009-09-25 06:03:25:351 1420 f64 AU ## END ## AU: Search for updates
[CallId = {4ED8AD06-D416-4907-88A2-F8560C3F9822}]
2009-09-25 06:03:25:351 1420 f64 AU #############
2009-09-25 06:03:25:351 1420 f64 AU Featured notifications is disabled.
2009-09-25 06:03:25:351 1420 f64 AU Setting AU scheduled install time to
2009-09-26 08:00:00
2009-09-25 06:09:35:919 1420 b84 Report Uploading 1 events using cached
cookie, reporting URL =
http://192.168.1.171/ReportingWebSer...ebService.asmx
2009-09-25 06:09:36:015 1420 b84 Report Reporter successfully uploaded 1
events.
2009-09-25 07:53:44:279 1420 4a4 AU ########### AU: Uninitializing
Automatic Updates ###########
2009-09-25 07:53:47:679 1420 4a4 Service *********
2009-09-25 07:53:47:679 1420 4a4 Service ** END ** Service: Service exit
[Exit code = 0x240001]
2009-09-25 07:53:47:679 1420 4a4 Service *************
2009-09-25 07:53:49:535 1420 868 Misc =========== Logging initialized
(build: 7.4.7600.226, tz: -0600) ===========
2009-09-25 07:53:49:535 1420 868 Misc = Process:
C:\WINDOWS\System32\svchost.exe
2009-09-25 07:53:49:535 1420 868 Misc = Module:
C:\WINDOWS\system32\wuaueng.dll
2009-09-25 07:53:49:535 1420 868 Service *************
2009-09-25 07:53:49:535 1420 868 Service ** START ** Service: Service startup
2009-09-25 07:53:49:535 1420 868 Service *********
2009-09-25 07:53:49:535 1420 868 Agent * WU client version 7.4.7600.226
2009-09-25 07:53:49:535 1420 868 Agent * Base directory:
C:\WINDOWS\SoftwareDistribution
2009-09-25 07:53:49:535 1420 868 Agent * Access type: No proxy
2009-09-25 07:53:49:535 1420 868 Agent * Network state: Connected
2009-09-25 07:53:58:736 1420 b8c Agent *********** Agent: Initializing
Windows Update Agent ***********
2009-09-25 07:53:58:736 1420 b8c Agent *********** Agent: Initializing
global settings cache ***********
2009-09-25 07:53:58:736 1420 b8c Agent * WSUS server: http://192.168.1.171/
2009-09-25 07:53:58:736 1420 b8c Agent * WSUS status server:
http://192.168.1.171/
2009-09-25 07:53:58:736 1420 b8c Agent * Target group: WSUS
2009-09-25 07:53:58:736 1420 b8c Agent * Windows Update access disabled: No
2009-09-25 07:53:58:767 1420 b8c DnldMgr Download manager restoring 0
downloads
2009-09-25 07:53:59:828 1420 b8c AU ########### AU: Initializing Automatic
Updates ###########
2009-09-25 07:53:59:828 1420 b8c AU AU setting next sqm report timeout to
2009-09-25 13:53:59
2009-09-25 07:53:59:828 1420 b8c AU # WSUS server: http://192.168.1.171/
2009-09-25 07:53:59:828 1420 b8c AU # Detection frequency: 22
2009-09-25 07:53:59:843 1420 b8c AU # Target group: WSUS
2009-09-25 07:53:59:843 1420 b8c AU # Approval type: Scheduled (Policy)
2009-09-25 07:53:59:843 1420 b8c AU # Scheduled install day/time: Every
day at 2:00
2009-09-25 07:53:59:843 1420 b8c AU # Auto-install minor updates: Yes
(Policy)
2009-09-25 07:53:59:859 1420 b8c AU Setting AU scheduled install time to
2009-09-26 08:00:00
2009-09-25 07:53:59:859 1420 b8c AU Initializing featured updates
2009-09-25 07:53:59:859 1420 b8c AU Found 0 cached featured updates
2009-09-25 07:54:01:107 1420 868 Report *********** Report: Initializing
static reporting data ***********
2009-09-25 07:54:01:107 1420 868 Report * OS Version = 5.1.2600.3.0.65792
2009-09-25 07:54:01:231 1420 868 Report * Computer Brand = IBM
2009-09-25 07:54:01:231 1420 868 Report * Computer Model = 821521U
2009-09-25 07:54:01:231 1420 868 Report * Bios Revision = 2EKT44AUS
2009-09-25 07:54:01:231 1420 868 Report * Bios Name = Phoenix
FirstBios(tm) Desktop Pro Version 2.0 for ThinkCentre.
2009-09-25 07:54:01:231 1420 868 Report * Bios Release Date =
2008-01-16T00:00:00
2009-09-25 07:54:01:231 1420 868 Report * Locale ID = 1033
2009-09-25 07:54:30:006 1420 d18 Report REPORT EVENT:
{CE361628-B2A4-4A77-AD9D-1EE2E1B42334} 2009-09-25
07:53:59:859-0600 1 202 102 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Content Install Reboot completed.
2009-09-25 07:54:30:115 1420 b8c AU AU finished delayed initialization
2009-09-25 07:54:30:115 1420 868 AU #############
2009-09-25 07:54:30:115 1420 868 AU ## START ## AU: Search for updates
2009-09-25 07:54:30:115 1420 868 AU #########
2009-09-25 07:54:30:115 1420 868 AU <<## SUBMITTED ## AU: Search for updates
[CallId = {D8B1AD65-1F40-4A7B-B51B-9A4AF8012A2B}]
2009-09-25 07:54:30:115 1420 d18 Agent *************
2009-09-25 07:54:30:115 1420 b8c AU Triggering AU detection through
DetectNow API
2009-09-25 07:54:30:115 1420 d18 Agent ** START ** Agent: Finding updates
[CallerId = AutomaticUpdates]
2009-09-25 07:54:30:115 1420 b8c AU Will do the detection after current
detection completes
2009-09-25 07:54:30:115 1420 d18 Agent *********
2009-09-25 07:54:30:115 1420 d18 Agent * Online = No; Ignore download
priority = No
2009-09-25 07:54:30:115 1420 d18 Agent * Criteria = "IsHidden=0 and
IsInstalled=0 and DeploymentAction='Installation' and IsAssigned=1 or
IsHidden=0 and IsPresent=1 and DeploymentAction='Uninstallation' and
IsAssigned=1 or IsHidden=0 and IsInstalled=1 and
DeploymentAction='Installation' and IsAssigned=1 and RebootRequired=1 or
IsHidden=0 and IsInstalled=0 and DeploymentAction='Uninstallation' and
IsAssigned=1 and RebootRequired=1"
2009-09-25 07:54:30:115 1420 d18 Agent * ServiceID =
{3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
2009-09-25 07:54:30:115 1420 d18 Agent * Search Scope = {Machine}
2009-09-25 07:56:21:844 1420 d18 Agent * Found 0 updates and 50 categories
in search; evaluated appl. rules of 590 out of 1356 deployed entities
2009-09-25 07:56:22:125 1420 d18 Agent *********
2009-09-25 07:56:22:125 1420 d18 Agent ** END ** Agent: Finding updates
[CallerId = AutomaticUpdates]
2009-09-25 07:56:22:125 1420 d18 Agent *************
2009-09-25 07:56:22:172 1420 55c AU >>## RESUMED ## AU: Search for updates
[CallId = {D8B1AD65-1F40-4A7B-B51B-9A4AF8012A2B}]
2009-09-25 07:56:22:172 1420 55c AU # 0 updates detected
2009-09-25 07:56:22:172 1420 55c AU #########
2009-09-25 07:56:22:172 1420 55c AU ## END ## AU: Search for updates
[CallId = {D8B1AD65-1F40-4A7B-B51B-9A4AF8012A2B}]
2009-09-25 07:56:22:172 1420 55c AU #############
2009-09-25 07:56:22:172 1420 55c AU Featured notifications is disabled.
2009-09-25 07:56:22:172 1420 55c AU Setting AU scheduled install time to
2009-09-26 08:00:00
2009-09-25 07:56:22:188 1420 868 AU #############
2009-09-25 07:56:22:188 1420 868 AU ## START ## AU: Search for updates

Here is the Websense log for 9-21 through 9-25. It shows the TCP/IP address
and number of times the computer contacted that one Internet address during
that period.

Risk Class: Business Usage > Category: Information... [2009-09-21 >>
2009-09-25] 2009-09-25 10:09:55
Page 1
Risk Class: Business Usage > Category: Information Technology > URL
Hostname: 65.55.13.88 > User
User Hits
192.168.1.104 41
192.168.1.27 39
192.168.1.25 37
192.168.1.99 27
192.168.1.70 24
192.168.1.55 17
192.168.1.20 16
192.168.1.110 15
192.168.1.77 14
192.168.1.82 14
192.168.1.68 13
192.168.1.52 8
192.168.1.33 8
192.168.1.36 7
192.168.1.139 7
192.168.1.85 6
192.168.1.78 5
192.168.1.62 5
Any thoughts?

"Benny" <> wrote in message
news:8A4C7FD3-35E2-4AF5-BCB1-...
> and the software and its updates are all automatically declined by
> the WSUS server

Really! I'm not aware of a tool in WSUS that can be used to Auto-Decline
updates based on product or category. There is a tool that permits the
auto-declination of an older revision when a newer revision is published,
and that's turned on by default. Otherwise, my only observation is that the
product permits an automatic rule to Approve an update for Installation
based on specified product(s) and/or classification(s).

Frankly, if I were to be interested in a rule to Auto-Decline an entire
product or classification, I'd just Not Synchronize the product or
classification in the first place.


> I didn't see where
> it tried to communicate with any server for updates other than our local
> WSUS
> server (http://192.168.1.171).

Well, see, right there's pretty much the termination of this conversation
then, Benny; because without any real evidence that the =WUAgent= is
initiating those connections, I'll have to suggest they are coming from
something else installed on those clients.

So, I do concur, there's no evidence that this traffic is being initiated by
the Windows Update Agent -- which, functionally speaking, makes this "not a
WSUS issue" :-)


> That is where I can find that I have computers communicating with
> Microsoft.

Well .. now.. let's have us a small "reality check" here.

What you have is this:
[a] Evidence that the client is connecting to one or more =IP ADDRESSES=.

[b] IP Addresses that are *not* listed in Reverse DNS. (Have you searched
for PTR records for those addresses.)

[c] IP Addresses that *ultimately* ends up at what appears to be the v6
Microsoft Update site - but also is seen (by me) redirecting through at
least three other sites on the way there -- so Who Knows!? I did notice,
also, that the connection got bounced through test.update.microsoft.com; so
maybe there's something "old" or "pre-release" still running on those
machines that's doing it's own update queries against an intentionally
non-published beta server that was subsequently redirected to the production
v6 Microsoft Update site?

Of interest is this query to determine the *actual* address of where the
browser ends up after initiating that connection.

>nslookup www.update.microsoft.com
Server: sbs2003r2.onsitech.lmg
Address: 192.168.90.80

Non-authoritative answer:
Name: www.update.microsoft.com.nsatc.net
Address: 65.55.185.26
Aliases: www.update.microsoft.com

Notice that the final destination is on a different subnet.

Finally, I'm also intrigued by the results from a traceroute to those two
addresses...

The logged address, 65.55.13.88 traces into NTWK.MSN.NET, and then gets past
a router that reports a 10.* address (Bad Configuration)...

>tracert 65.55.13.88

Tracing route to 65.55.13.88 over a maximum of 30 hops

<*internal and local ISP addresses removed*>
7 52 ms 52 ms 52 ms ge-0-3-0-0.dal-64cb-1a.ntwk.msn.net
[207.46.45.78]
8 113 ms 139 ms 103 ms ge-1-0-0-0.co2-64c-1a.ntwk.msn.net
[207.46.43.190]
9 104 ms 115 ms 106 ms ge-6-1-0-0.co1-64c-1a.ntwk.msn.net
[207.46.43.170]
10 101 ms 102 ms 103 ms 10.22.8.50
11 * * * Request timed out.
12 * * * Request timed out.
13 * 10.22.8.62 reports: Destination net unreachable.

Trace complete.

Which then redirects to the resolved IP Address, and from the actual MU v6
website @ 66.55.185.26... we end up at a completely different router (but
with the same type of configuration error, a 10.* router responding to ICMP
back to a public IP Address)

>tracert 65.55.185.26

Tracing route to 65.55.185.26 over a maximum of 30 hops

<*internal and local ISP addresses removed*>
7 53 ms 52 ms 52 ms ge-0-3-0-0.dal-64cb-1a.ntwk.msn.net
[207.46.45.78]
8 87 ms 87 ms 88 ms 207.46.43.10
9 89 ms 86 ms 88 ms ge-4-1-0-0.bl2-64c-1b.ntwk.msn.net
[207.46.43.7]
10 89 ms 88 ms 87 ms 10.22.112.121
11 88 ms 87 ms 88 ms 10.22.112.78
12 * * 10.22.112.78 reports: Destination net unreachable.

Trace complete.



The common divergence of these two traceroutes appears to be the primary
entry point into the NTWK.MSN.NET network in Dallas.

<btw... also looks like the network admins at MSN.NET need some lessons on
how to properly configure internal routers>

I'm doubting that this is malicious, but it's definitely behavior that
suggests something ain't right.


> In this case, they are using port 443 to communicate with Microsoft's web
> site.

Here's a second "flaw" in the scheme -- The WUAgent does not use SSL to
connect to the public WU/MU servers, and it only uses SSL to connect to a
local WSUS Server when the environment is explicitly configured to support
inbound SSL connections on the published WSUS Server.

So...you don't have Forefront installed; you're using third party products
for AV/AM protection, and these are XP Service Pack 3 machines (not Vista or
later, in which I'd immediately consider Windows Defender) -- However!
That's not to say that you shouldn't rule out the possibility that Windows
Defender is on these machines and querying for updated definition files (or
maybe even a beta version of WD from before you opted to deploy your third
party AV/AM products), or even that it's some other *Microsoft* production
product that's configured to auto-update from the Microsoft Update
servers -- like Windows Live, etc.


> 2009-09-25 06:01:55:999 1420 4a4 Agent * WSUS server:
> http://192.168.1.171/
> 2009-09-25 06:01:55:999 1420 4a4 Agent * WSUS status server:
> http://192.168.1.171/

btw, side note, as a "best practice" I would recommend removing the trailing
slash from the URL specification. That trailing slash, when appended with
other relative pathnames, can result in the URL having a double-slash, which
is known to cause issues in some scenarios.



> Here is the Websense log for 9-21 through 9-25. It shows the TCP/IP
> address
> and number of times the computer contacted that one Internet address
> during
> that period.
>
> Risk Class: Business Usage > Category: Information... [2009-09-21 >>
> 2009-09-25] 2009-09-25 10:09:55
> Page 1
> Risk Class: Business Usage > Category: Information Technology > URL
> Hostname: 65.55.13.88 > User
> User Hits
> 192.168.1.104 41
> 192.168.1.27 39
> 192.168.1.25 37
> 192.168.1.99 27
> 192.168.1.70 24
> 192.168.1.55 17
> 192.168.1.20 16
> 192.168.1.110 15
> 192.168.1.77 14
> 192.168.1.82 14
> 192.168.1.68 13
> 192.168.1.52 8
> 192.168.1.33 8
> 192.168.1.36 7
> 192.168.1.139 7
> 192.168.1.85 6
> 192.168.1.78 5
> 192.168.1.62 5
> Any thoughts?

Based on the frequency of usage, I'd guess that 192.168.1.104 would be a
good starting point for an analysis. You might start with a review of the
active processes in the Task Manager and the output from a netstat -a that
shows the originating process of the connection. Also, with a list that
long, it should be fairly easy to make a short list of the commonly running
applications/processes that exist on all 18 identified systems.

If that doesn't provide any useful leads, then you might find it useful to
fire up up a Network Monitor session on that client, or even run a 3rd party
probe on the segment containing that machine and capture the actual traffic
to/from those IP Addresses (although if they really are SSL encrypted, the
probe probably won't be of much use).

--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

Thank you for your detailed response. Apparently I phrased my first comment
about not accepting or auto-declining some products. Under Options for the
Update Server, I've only selected the products that we currently have
purchased and installed for updates. Forefront Security is not one of the
Microsoft Products that we've purchased or receive updates.

I did a spot check of several of our systems to ensure that Forefront
Security or Windows Defender have been installed on a system and did not find
it.

Thank you for the observation about the trailing slash on the WSUS Server
address. I thought I'd read a Technet Article suggesting that it should be
used but I can no longer find the article so I'll have to look at changing it.

I'll look through the systems and see what processes are running in comment
but I think it will be a fairly long list. One of the systems that is
contacting the website is mine. I have to a tendency to rebuilt it from
Microsoft retail media about every six months. The last time was about two
months ago so I know exactly what's been loaded on it. There is nothing that
should be contacting Microsoft for updates except through Windows Update
Service.


"Lawrence Garvin [MVP]" wrote:

> "Benny" <> wrote in message
> news:8A4C7FD3-35E2-4AF5-BCB1-...
> > and the software and its updates are all automatically declined by
> > the WSUS server
>
> Really! I'm not aware of a tool in WSUS that can be used to Auto-Decline
> updates based on product or category. There is a tool that permits the
> auto-declination of an older revision when a newer revision is published,
> and that's turned on by default. Otherwise, my only observation is that the
> product permits an automatic rule to Approve an update for Installation
> based on specified product(s) and/or classification(s).
>
> Frankly, if I were to be interested in a rule to Auto-Decline an entire
> product or classification, I'd just Not Synchronize the product or
> classification in the first place.
>
>
> > I didn't see where
> > it tried to communicate with any server for updates other than our local
> > WSUS
> > server (http://192.168.1.171).
>
> Well, see, right there's pretty much the termination of this conversation
> then, Benny; because without any real evidence that the =WUAgent= is
> initiating those connections, I'll have to suggest they are coming from
> something else installed on those clients.
>
> So, I do concur, there's no evidence that this traffic is being initiated by
> the Windows Update Agent -- which, functionally speaking, makes this "not a
> WSUS issue" :-)
>
>
> > That is where I can find that I have computers communicating with
> > Microsoft.
>
> Well .. now.. let's have us a small "reality check" here.
>
> What you have is this:
> [a] Evidence that the client is connecting to one or more =IP ADDRESSES=.
>
> [b] IP Addresses that are *not* listed in Reverse DNS. (Have you searched
> for PTR records for those addresses.)
>
> [c] IP Addresses that *ultimately* ends up at what appears to be the v6
> Microsoft Update site - but also is seen (by me) redirecting through at
> least three other sites on the way there -- so Who Knows!? I did notice,
> also, that the connection got bounced through test.update.microsoft.com; so
> maybe there's something "old" or "pre-release" still running on those
> machines that's doing it's own update queries against an intentionally
> non-published beta server that was subsequently redirected to the production
> v6 Microsoft Update site?
>
> Of interest is this query to determine the *actual* address of where the
> browser ends up after initiating that connection.
>
> >nslookup www.update.microsoft.com
> Server: sbs2003r2.onsitech.lmg
> Address: 192.168.90.80
>
> Non-authoritative answer:
> Name: www.update.microsoft.com.nsatc.net
> Address: 65.55.185.26
> Aliases: www.update.microsoft.com
>
> Notice that the final destination is on a different subnet.
>
> Finally, I'm also intrigued by the results from a traceroute to those two
> addresses...
>
> The logged address, 65.55.13.88 traces into NTWK.MSN.NET, and then gets past
> a router that reports a 10.* address (Bad Configuration)...
>
> >tracert 65.55.13.88
>
> Tracing route to 65.55.13.88 over a maximum of 30 hops
>
> <*internal and local ISP addresses removed*>
> 7 52 ms 52 ms 52 ms ge-0-3-0-0.dal-64cb-1a.ntwk.msn.net
> [207.46.45.78]
> 8 113 ms 139 ms 103 ms ge-1-0-0-0.co2-64c-1a.ntwk.msn.net
> [207.46.43.190]
> 9 104 ms 115 ms 106 ms ge-6-1-0-0.co1-64c-1a.ntwk.msn.net
> [207.46.43.170]
> 10 101 ms 102 ms 103 ms 10.22.8.50
> 11 * * * Request timed out.
> 12 * * * Request timed out.
> 13 * 10.22.8.62 reports: Destination net unreachable.
>
> Trace complete.
>
> Which then redirects to the resolved IP Address, and from the actual MU v6
> website @ 66.55.185.26... we end up at a completely different router (but
> with the same type of configuration error, a 10.* router responding to ICMP
> back to a public IP Address)
>
> >tracert 65.55.185.26
>
> Tracing route to 65.55.185.26 over a maximum of 30 hops
>
> <*internal and local ISP addresses removed*>
> 7 53 ms 52 ms 52 ms ge-0-3-0-0.dal-64cb-1a.ntwk.msn.net
> [207.46.45.78]
> 8 87 ms 87 ms 88 ms 207.46.43.10
> 9 89 ms 86 ms 88 ms ge-4-1-0-0.bl2-64c-1b.ntwk.msn.net
> [207.46.43.7]
> 10 89 ms 88 ms 87 ms 10.22.112.121
> 11 88 ms 87 ms 88 ms 10.22.112.78
> 12 * * 10.22.112.78 reports: Destination net unreachable.
>
> Trace complete.
>
>
>
> The common divergence of these two traceroutes appears to be the primary
> entry point into the NTWK.MSN.NET network in Dallas.
>
> <btw... also looks like the network admins at MSN.NET need some lessons on
> how to properly configure internal routers>
>
> I'm doubting that this is malicious, but it's definitely behavior that
> suggests something ain't right.
>
>
> > In this case, they are using port 443 to communicate with Microsoft's web
> > site.
>
> Here's a second "flaw" in the scheme -- The WUAgent does not use SSL to
> connect to the public WU/MU servers, and it only uses SSL to connect to a
> local WSUS Server when the environment is explicitly configured to support
> inbound SSL connections on the published WSUS Server.
>
> So...you don't have Forefront installed; you're using third party products
> for AV/AM protection, and these are XP Service Pack 3 machines (not Vista or
> later, in which I'd immediately consider Windows Defender) -- However!
> That's not to say that you shouldn't rule out the possibility that Windows
> Defender is on these machines and querying for updated definition files (or
> maybe even a beta version of WD from before you opted to deploy your third
> party AV/AM products), or even that it's some other *Microsoft* production
> product that's configured to auto-update from the Microsoft Update
> servers -- like Windows Live, etc.
>
>
> > 2009-09-25 06:01:55:999 1420 4a4 Agent * WSUS server:
> > http://192.168.1.171/
> > 2009-09-25 06:01:55:999 1420 4a4 Agent * WSUS status server:
> > http://192.168.1.171/
>
> btw, side note, as a "best practice" I would recommend removing the trailing
> slash from the URL specification. That trailing slash, when appended with
> other relative pathnames, can result in the URL having a double-slash, which
> is known to cause issues in some scenarios.
>
>
>
> > Here is the Websense log for 9-21 through 9-25. It shows the TCP/IP
> > address
> > and number of times the computer contacted that one Internet address
> > during
> > that period.
> >
> > Risk Class: Business Usage > Category: Information... [2009-09-21 >>
> > 2009-09-25] 2009-09-25 10:09:55
> > Page 1
> > Risk Class: Business Usage > Category: Information Technology > URL
> > Hostname: 65.55.13.88 > User
> > User Hits
> > 192.168.1.104 41
> > 192.168.1.27 39
> > 192.168.1.25 37
> > 192.168.1.99 27
> > 192.168.1.70 24
> > 192.168.1.55 17
> > 192.168.1.20 16
> > 192.168.1.110 15
> > 192.168.1.77 14
> > 192.168.1.82 14
> > 192.168.1.68 13
> > 192.168.1.52 8
> > 192.168.1.33 8
> > 192.168.1.36 7
> > 192.168.1.139 7
> > 192.168.1.85 6
> > 192.168.1.78 5
> > 192.168.1.62 5
> > Any thoughts?
>
> Based on the frequency of usage, I'd guess that 192.168.1.104 would be a
> good starting point for an analysis. You might start with a review of the
> active processes in the Task Manager and the output from a netstat -a that
> shows the originating process of the connection. Also, with a list that
> long, it should be fairly easy to make a short list of the commonly running
> applications/processes that exist on all 18 identified systems.
>
> If that doesn't provide any useful leads, then you might find it useful to
> fire up up a Network Monitor session on that client, or even run a 3rd party
> probe on the segment containing that machine and capture the actual traffic
> to/from those IP Addresses (although if they really are SSL encrypted, the
> probe probably won't be of much use).
>
> --
> Lawrence Garvin, M.S., MCITP:EA, MCDBA
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2009)
>
> My Blog: http://onsitechsolutions.spaces.live.com
> Microsoft WSUS Website: http://www.microsoft.com/wsus
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>
>

"Benny" <> wrote in message
news:0A037A9B-24A9-45B5-BAD8-...
> Thank you for the observation about the trailing slash on the WSUS Server
> address. I thought I'd read a Technet Article suggesting that it should be
> used but I can no longer find the article so I'll have to look at changing
> it.

If you recall such an article, or find it, please let me know.


--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin