I recently had a surprise in my SCCM environment that I wanted to share in hopes of helping others in similar situations. We are on current branch of ConfigMgr (1610 at the moment) and during our monthly update deployment cycle we had many machines failing to install due to content issues. Upon looking closer we learned a little more about the boundary changes that happened in the product recently. There are now relationships between boundary groups, and a new "default site boundary group" that comes into play.
The key to all of these changes is to look in your CAS log for lines similar to the following:
Matching DP location found 0 - http://FOO.redmond.corp.microsoft.com/sms_dp_smspkg$/content_AAAAAAA-BBBBBB-1234-1234-123456789.1 (Locality: BOUNDARYGROUP)
That locality part is the key thing to watch. In our case we had many machines where it was "Locality: site". This means no boundary group was associated with the given boundary, and no relationship to another boundary group, so the client was using the default site boundary group. Fixing boundaries to be in proper boundary groups got us on the right track. Locality: BOUNDARYGROUP or Locality: ADSITE is a much better line to see.
So lesson to share, keep an eye on your CAS.log and that locality line to make sure things go where you want them to.