DYNAMIC Intranet Microsoft Update Service Location

problem:
having mobile workers [users with laptops/notebooks travelin from branch
office to branch office], they have configured wsus server at headquarter,
and when they boot their mobile computer at branch office, they start to
download updates accross corporate network from headquarter, overloading
corporate network

question:
is it possible to have group policy, some script or anything to allow mobile
users to automaticaly receive updates from the *nearest* update server
[server from the local lan] and not from the fixed server from remote
headquarter
since they change their location frequently and in unknown interval, mobile
users need to automaticly discover curently the nearest update server
the local network is controlled by dhcp, so when they boot their mobile
computers they may hev info on which their current network is

i try to avoid option to have update disabled or switched to manual

any help or suggestion?

thnx

We don't use "chatspeak" here.

sali wrote:
> problem:
> having mobile workers [users with laptops/notebooks travelin from branch
> office to branch office], they have configured wsus server at headquarter,
> and when they boot their mobile computer at branch office, they start to
> download updates accross corporate network from headquarter, overloading
> corporate network
>
> question:
> is it possible to have group policy, some script or anything to allow
> mobile
> users to automaticaly receive updates from the *nearest* update server
> [server from the local lan] and not from the fixed server from remote
> headquarter
> since they change their location frequently and in unknown interval,
> mobile
> users need to automaticly discover curently the nearest update server
> the local network is controlled by dhcp, so when they boot their mobile
> computers they may hev info on which their current network is
>
> i try to avoid option to have update disabled or switched to manual
>
> any help or suggestion?
>
> thnx

(cross-post added to WSUS)
"sali" <> wrote in message news:%...
> problem:
> having mobile workers [users with laptops/notebooks travelin from branch
> office to branch office], they have configured wsus server at headquarter,
> and when they boot their mobile computer at branch office, they start to
> download updates accross corporate network from headquarter, overloading
> corporate network
>
> question:
> is it possible to have group policy, some script or anything to allow mobile
> users to automaticaly receive updates from the *nearest* update server
> [server from the local lan] and not from the fixed server from remote
> headquarter
> since they change their location frequently and in unknown interval, mobile
> users need to automaticly discover curently the nearest update server
> the local network is controlled by dhcp, so when they boot their mobile
> computers they may hev info on which their current network is
>
> i try to avoid option to have update disabled or switched to manual
>
> any help or suggestion?


Try the WSUS NG. Cross-posting to it for convenience.


>
> thnx


Good luck

Robert Aldwinckle
---

"Robert Aldwinckle" <> wrote in message
news:O%...

>> problem:
>> having mobile workers [users with laptops/notebooks travelin from branch
>> office to branch office], they have configured wsus server at
>> headquarter,
>> and when they boot their mobile computer at branch office, they start to
>> download updates accross corporate network from headquarter, overloading
>> corporate network

This is a quite common scenario, discussed many many, times in this forum
and others.

>> question:
>> is it possible to have group policy, some script or anything to allow
>> mobile
>> users to automaticaly receive updates from the *nearest* update server
>> [server from the local lan] and not from the fixed server from remote
>> headquarter

Well, yes. It involves the use of DNS through Netmask Ordering and
Round-Robin resolution. I would suggest consulting with somebody with
expertise in DNS and networking infrastructure if you're interested in this
solution, as configuring it incorrectly can do more harm than good.

--
Lawrence Garvin, M.S., MCITP(x2), MCTS(x5), MCP(x7), MCBMSP
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

I can see how DNS would handle it but get concerned about how the WSUS
servers react.

Let's keep it simple with two sites, HQ and Location1 (L1).

WSUS is installed on HQWSUS.our.lan and also on L1WSUS.our lan with L1WSUS
being a replica of HQWSUS. A DNS entry exists at each location pointing
LOCALWSUS to the local WSUS at each location and group policy tells all PC's
to use LOCALWSUS.

The user of PC37 is at HQ and connects for less time than a download takes,
unplugs the PC and takes it to L1. It would not surprise me to find the PC
'resuming' the download but it may start from beginning again, no real
problem either way. Problem is we now have PC37 registered on both servers
(even if it wasn't partway through a download).

Does the WSUS 'uniqueID' given each workstation allow such movement to be
tracked between cascaded servers? Is the entry on HQWSUS deleted or moved so
that it is recognised as 'belonging' to L1WSUS? or do we end up with
different status of the machine (and hence in reports) on the 2 servers?

--
SBS remote support services. (Fees apply)
mickm at mickmalloy dot dyndns dot org

"Lawrence Garvin [MVP]" <> wrote in message
news:...
> "Robert Aldwinckle" <> wrote in message
> news:O%...
>
>>> problem:
>>> having mobile workers [users with laptops/notebooks travelin from branch
>>> office to branch office], they have configured wsus server at
>>> headquarter,
>>> and when they boot their mobile computer at branch office, they start to
>>> download updates accross corporate network from headquarter, overloading
>>> corporate network
>
> This is a quite common scenario, discussed many many, times in this forum
> and others.
>
>>> question:
>>> is it possible to have group policy, some script or anything to allow
>>> mobile
>>> users to automaticaly receive updates from the *nearest* update server
>>> [server from the local lan] and not from the fixed server from remote
>>> headquarter
>
> Well, yes. It involves the use of DNS through Netmask Ordering and
> Round-Robin resolution. I would suggest consulting with somebody with
> expertise in DNS and networking infrastructure if you're interested in
> this solution, as configuring it incorrectly can do more harm than good.
>
> --
> Lawrence Garvin, M.S., MCITP(x2), MCTS(x5), MCP(x7), MCBMSP
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2009)
>
> MS WSUS Website: http://www.microsoft.com/wsus
> My Websites: http://www.onsitechsolutions.com;
> http://wsusinfo.onsitechsolutions.com
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>

"SuperGumby [SBS MVP]" <> wrote in message
news:...


> Let's keep it simple with two sites, HQ and Location1 (L1).
>
> WSUS is installed on HQWSUS.our.lan and also on L1WSUS.our lan with L1WSUS
> being a replica of HQWSUS. A DNS entry exists at each location pointing
> LOCALWSUS to the local WSUS at each location and group policy tells all
> PC's to use LOCALWSUS.
>
> The user of PC37 is at HQ and connects for less time than a download
> takes, unplugs the PC and takes it to L1. It would not surprise me to find
> the PC 'resuming' the download but it may start from beginning again, no
> real problem either way.

This is where understanding the functionality of BITS is important, as well
as the benefits of using Range Protocol Headers in HTTP v1.1. Suffice it to
say that BITS is capable of resuming the download from where it's left off.
In fact, this is no different a solution than if this were a desktop PC and
simply powered off whilst a download were in progress -- a scenario that
happens a lot more often than is likely thought of.

> Problem is we now have PC37 registered on both servers (even if it wasn't
> partway through a download).

Actaully PC37 will only *register* if an actual detection takes place. The
download, which is a pure HTTP-based file transfer from
http://LocalWSUS/Content/* will not cause a registration with the WSUS
Server to take place; that's done by a call to the webservice
http://LocalWSUS/ClientWebService/* -- but your point is, nonetheless,
valid. As some point PC37 *will* become registered with both machines, and
this is a management issue that must be worked out.


> Does the WSUS 'uniqueID' given each workstation allow such movement to be
> tracked between cascaded servers?

If you're doing reporting rollup from the replica server, presumably all of
the "events" recorded against the SusClientID of PC37 will be rolled up, and
the upstream server will have a full record of activity against this client.
The consideration here is that the replica server(s) will *not* have a
complete record of activity against this client.

> Is the entry on HQWSUS deleted or moved so that it is recognised as
> 'belonging' to L1WSUS? or do we end up with different status of the
> machine (and hence in reports) on the 2 servers?

The whole key is the GUID, known as the SusClientID, combined with (added in
WSUS v3), the FQDN of the machine.

The other consideration, even more critical, is understanding that the TTL
on the DNS records must be abnormally short in a scenario where there is
high mobility, in order to prevent the client machine from accessing the
"last accessed" server across the WAN, because of cached DNS 'A' records,
pointing to the wrong (not local) WSUS Server.


--
Lawrence Garvin, M.S., MCITP(x2), MCTS(x5), MCP(x7), MCBMSP
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

Would the use of different policy settings re 'Set the intranet update
service for detecting updates:' vs 'Set the intranet statistics server:'
avoid such problems?

Seems to me that 'Set the intranet update service for detecting updates:'
should be changed to 'Set the intranet update service for DOWNLOADING
updates:' and both detection and reporting could be set to the 'master'
WSUS. The intention being that all PCs only report to master but may
download from a local WSUS at each location.

--
SBS remote support services. (Fees apply)
mickm at mickmalloy dot dyndns dot org

"Lawrence Garvin [MVP]" <> wrote in message
news:egX%...
> "SuperGumby [SBS MVP]" <> wrote in message
> news:...
>
>
>> Let's keep it simple with two sites, HQ and Location1 (L1).
>>
>> WSUS is installed on HQWSUS.our.lan and also on L1WSUS.our lan with
>> L1WSUS being a replica of HQWSUS. A DNS entry exists at each location
>> pointing LOCALWSUS to the local WSUS at each location and group policy
>> tells all PC's to use LOCALWSUS.
>>
>> The user of PC37 is at HQ and connects for less time than a download
>> takes, unplugs the PC and takes it to L1. It would not surprise me to
>> find the PC 'resuming' the download but it may start from beginning
>> again, no real problem either way.
>
> This is where understanding the functionality of BITS is important, as
> well as the benefits of using Range Protocol Headers in HTTP v1.1. Suffice
> it to say that BITS is capable of resuming the download from where it's
> left off. In fact, this is no different a solution than if this were a
> desktop PC and simply powered off whilst a download were in progress -- a
> scenario that happens a lot more often than is likely thought of.
>
>> Problem is we now have PC37 registered on both servers (even if it wasn't
>> partway through a download).
>
> Actaully PC37 will only *register* if an actual detection takes place. The
> download, which is a pure HTTP-based file transfer from
> http://LocalWSUS/Content/* will not cause a registration with the WSUS
> Server to take place; that's done by a call to the webservice
> http://LocalWSUS/ClientWebService/* -- but your point is, nonetheless,
> valid. As some point PC37 *will* become registered with both machines, and
> this is a management issue that must be worked out.
>
>
>> Does the WSUS 'uniqueID' given each workstation allow such movement to be
>> tracked between cascaded servers?
>
> If you're doing reporting rollup from the replica server, presumably all
> of the "events" recorded against the SusClientID of PC37 will be rolled
> up, and the upstream server will have a full record of activity against
> this client. The consideration here is that the replica server(s) will
> *not* have a complete record of activity against this client.
>
>> Is the entry on HQWSUS deleted or moved so that it is recognised as
>> 'belonging' to L1WSUS? or do we end up with different status of the
>> machine (and hence in reports) on the 2 servers?
>
> The whole key is the GUID, known as the SusClientID, combined with (added
> in WSUS v3), the FQDN of the machine.
>
> The other consideration, even more critical, is understanding that the TTL
> on the DNS records must be abnormally short in a scenario where there is
> high mobility, in order to prevent the client machine from accessing the
> "last accessed" server across the WAN, because of cached DNS 'A' records,
> pointing to the wrong (not local) WSUS Server.
>
>
> --
> Lawrence Garvin, M.S., MCITP(x2), MCTS(x5), MCP(x7), MCBMSP
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2009)
>
> MS WSUS Website: http://www.microsoft.com/wsus
> My Websites: http://www.onsitechsolutions.com;
> http://wsusinfo.onsitechsolutions.com
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>

"SuperGumby [SBS MVP]" <> wrote in message
news:%...
> Would the use of different policy settings re 'Set the intranet update
> service for detecting updates:' vs 'Set the intranet statistics server:'
> avoid such problems?

No, those two values must be identical. Even the most insignificant
variation in their values will totally halt the functionality of the Windows
Update Agent.

> Seems to me that 'Set the intranet update service for detecting updates:'
> should be changed to 'Set the intranet update service for DOWNLOADING
> updates:' and both detection and reporting could be set to the 'master'
> WSUS. The intention being that all PCs only report to master but may
> download from a local WSUS at each location.

Well, presumably, the original intention, way back in the days of SUS 1.0,
was that the WUA was going to support alternate reporting locations (the
"statistics server") vs the detection server.

Alternatively, it may be that "statistics server" is used internally at
Microsoft Update, and simply needs to be replicated in the WUA setup for
functionality purposes.

Truly we've never gotten a good detailed answer as to why they must be
identical, or even why both continue to be retained after so many years,
despite their redundancy. It seems a simple thing to have 'bugfixed' the WUA
in any of the last half dozen releases to simply ignore the "intranet
statistics server" value, and point it at the "detection" server value.


--
Lawrence Garvin, M.S., MCITP(x2), MCTS(x5), MCP(x7), MCBMSP
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin