Program Download to roaming client
I have been testing roaming between Config Mgr sites to confirm how best to configure laptops and packages/programs targeted at them to support regular travellers in the organisation.
I have created a package/program/advertisment. The advertisement is not mandatory, is set to download to target and run on fast boundary but set to not run if on a slow boundary.
The package has been distributed to distribution points on Config Mgr Site 1, Site 2 and Site 3. Site 1 and 2 are Primary Sites and Site 3 is a secondary site / child of Site 2.
The advertisement has been targeted at a collection containing my test laptop.
My test laptop is connected to Config Mgr Site 3.
The advertisement is run on the target laptop and correctly starts to download the package/program from the distribution point on Site 3.
I interrupt the download by shutting down the laptop.
I then connect the laptop to Config Mgr Site 2. Its IP address now sits within a fast boundary of Site 2.
The download continues automatically from the checkpoint (good stuff!). However, it continues to download from the distribution point on Site 3 rather than from the distribution point on Site 2 as I was expecting.
I then disconnect again whilst download is still in progress and this time reconnect on an IP address with a slow boundary on Site 2. The download continues from where it was interrupted although this is a slow boundary. Furthermore it still continues to download from the distribution point on Site3.
Is this behaviour correct?
Answers
Yes, we get the DP location from the MP. So we'd have to contact the MP to find that we're in a different location and then need to use a different DP.
Sounds like the issue, and I feel better now :-)
All Replies
- Moving the thread to the Software Distribution forum.
My understanding from long ago, was that once disconnected, the client would look at its current location, select a local DP with the content (if available) and then use a local DP.
If that is not happening, then either my understanding is wrong (which means it has been so for years), or the content was not available to the clients at the two other sites - either not distributed to DPs at those sites (which you said it was) or the client was not within the boundaries of the site.
In either case, if the advertisement was configured to not support remote clients (slow boundaries or no boundaries), and if the client was not within the secondary site's boundaries, then it should not resume.
I'll check to validate this is correct. In the mean time, can you validate that the three sites have unique Boundaries configured (no overlapping boundaries and no boundaries from the secondary site added to the primary site's boundaries)?
Also, how did you determine that the client used the same DP?
Hi Wally, thanks for the response. My understanding of many weeks
from the documentation was the same as yours and is again now.I re-checked the boundary definitions and they are OK, no overlaps etc.
I determine which DP is being used by monitoring the network traffic on the client and the site servers with Netmon.
I have been continuing my testing and I think I have found what my 'problem' was.......
It appears to be a timing issue (once again I was perhaps being impatient). When the roaming client reconnects to the network but within a different site boundary it appears that the download continues where it left off using the previous DP...until the client manages to contact its MP. At that point the client appears to establish that it is within a different boundary and behaves as expected, i.e. uses new distribution point if on fast boundary or stops the xfer if it is slow boundary.
It just seems to take a while for the client to contact its MP and 'apply the rules' after restart from shutdown or resume from hibernate. Program download just appears to get going first.
I'd appreciate it if you could confirm that my interpretation is correct......and once again apologies for my naivety.
Your help is very much appreciated.Yes, we get the DP location from the MP. So we'd have to contact the MP to find that we're in a different location and then need to use a different DP.
Sounds like the issue, and I feel better now :-)
