Wrong Distribution Point mounting

[dfarnworth]

Hi,

We've come across a problem in our organisation where despite a computer having an IP address from subnet X which has DP X (this is the master DP) assigned to it in the JSS, when we run a policy the machine will mount DP Y to cache or install packages.

As we have people around the globe and travelling regularly, this can cause both performance and bandwidth issues, particularly with larger software such as OS upgrades.

There does not seem to be any particular pattern to this although I have noticed that often this seems to relate to the user spending long periods working at or being based at the site where DP Y is located.

This would seem to indicate that the JAMF binary on the client machine is in some way caching the commonly used DP in file somewhere. I cannot any reference in the usual preference files, but perhaps there's one I missed.

Any thoughts anyone?

[bpavlov]

Make sure to do a backup. Contact your TAM. And reference this: https://macmule.com/2014/05/14/jss-using-wrong-distribution-points-after-v8-v9-upgrade/

We recently had this issue ourselves and that article really helped us. Thanks @bentoms for posting that.

[dfarnworth]

Thanks @bpavlov

[scottb]

I did see this. We have a DP that is a very old server, and is overloaded. A nearby server was performing better, even though it's on another site. When I made the changeover on the JSS, the Macs were still using the old one and failing.
I finally removed the DP (temporarily until they put in a new box) and after about a week - maybe two - they finally started using the new DP.

So, I reckon you're right that there is info cached, and it may not update rapidly enough for a traveling user. I'll keep an eye out to see if I can monitor laptops that move from site to site. You'd think/hope that the subnet/DP info would update as rapidly as the next contact, but I don't believe that to have happened.

[bpavlov]

@scottb Check the link I posted. If it's the same issue, it's not that the information is cached locally on the client. It's that the records in the database have the clients set to use a specific DP. This is basically means the DP info is hardcoded for that client regardless of what network segment or IP the client has. I recommend working with your TAM as it should be relatively easy to fix particularly if you reference that blog post.

[scottb]

@bpavlov - I'll see if I can. Our Wintel servers are locked down and I may not be able to access that data. I'll have a look though - looks simple enough to at least see if there's a problem. Thanks.

[davidacland]

It could be worth having a look at this video from Expedia at last years JNUC. They had a better DP setting script using the API. http://www.jamfsoftware.com/resources/jss-rest-api-the-key-to-a-better-nights-sleep/

[dfarnworth]

Looks like it is the same issue. Interesting thought to use the API, need to look into this as would avoid having to raise a CR I suspect...

[lisacherie]

Ask your TAM about distribution points scoped by network segments if you are using that feature.

Also ask your TAM about "IP Address" vs "Reported IP Address". Sorry to be vague, there are a few things that could be contributing, and dependent on how your environment is configured.

Re-architected the DP's here to use physical load balancers to work around some of the issues.