We’ve seen this issue come up a couple times so I wanted to give it a mention here just in case you run into it. The problem is that you may notice Software Deployments are not working for a small percentage of your Configuration Manager clients and you may notice that the status of the problem clients is Waiting on content. You may also notice that the affected clients are unable to automatically re-discover their site code in the control panel applet.
The last time I saw this, we checked the properties of the affected client's resource in the Configuration Manager 2007 Console and it showed multiple subnets for these clients (e.g. 220.127.116.11 and 18.104.22.168).
The site boundary for these clients was entered as simply 22.214.171.124 on the Site server and these boundaries did not overlap with any other site.
We then found the following error in the CAS.log which seem to point to a boundaries issue:
ctm job suspended
We enabled verbose and debug logging in the registry on one of the affected clients and then created a new advertisement and a test collection to send it to. When we did this we found the following in the LocationServices.log:
Discarding DP with SiteLocality 'FALLBACK'. Accepting only 'LOCAL' DPs. 10/30/2009 1:37:24 PM 164 (0x00A4)
The number of discovered DPs(including Branch DP and Multicast) is 0 10/30/2009 1:37:24 PM 164 (0x00A4)
When we tried to perform automatic site discovery on the client that was failing we saw this”
"LSGetAssignedSiteFromSLP : No site code returned from SLP"
"The number of discovered DPs (including Branch DP and Multicast) is 0"
Everything seemed to point to a Protected Distribution Point but there were none in this case. It also seemed like it could be a boundary issue which was not obvious on the surface since the 126.96.36.199 boundary included all of the affected clients. Also this problem did not affect all clients in these subnets, only some.
It turns out that this issue was nonspecific Site Boundaries in the site. 188.8.131.52 is not specific enough to allow the clients to find the site and/or find its Distribution Point servers. This is referred to as super netting, and this will not yield consistent results for your Configuration Manager clients.
Once you add a specific 184.108.40.206 subnet and/or the 220.127.116.11 subnet (whichever applies), the clients in these subnets will be able to find their Site ID and Distribution Points without error, so the solution is to add the specific individual subnets to the Site Boundaries.
This problem can also manifest itself in other ways such as when an AD Subnet is specified as 18.104.22.168 and the AD site is added as a boundary in SMS or Configuration Manager, then you also add some specific subnets as boundaries like 22.214.171.124 and 126.96.36.199. This can also cause the same symptoms documented above.
The TechNet article below articulates the IP Subnet configuration recommendations of entering each IP subnet individually, however it does not indicate that super netting is not supported so I created this document to help shed more light on this issue since we have seen several cases with this issue.
Hope this helps,
Clifton Hughes | Senior Support Engineer
Solved !!! Hey Guys Please have another check after you check boundaries configuration
your Antivirus Application rules Or any FW on your Workstations !!!
our case was policy restricts from app rules blocked autorun.inf files in cache directory.
Thanks for this information. I might be in the other situation you described in "More Information".
We have AD Sites and Services' Subnet set to 188.8.131.52/16 while the phyiscal network is set to Class C level (9.9.x.0/24)
When we have intermittent weird locality detection issue on DP, we found that the system properties on each computer with the issue had both Subnet=184.108.40.206 and Subnet=9.9.x.0 (while boundary is defined only for 9.9.x.0. listed.)
We are NOT using Network Discovery but heavily rely on:
- AD System Discovery (Full discovery daily with 5 mins delta discovery)
- Predelivered SCCM Client on the image (or just in time delivery via OSD)
Q1 I don't know if it is the root cause of the issue but I don't know if I have to convince AD Administrator to change AD Sites and Services configuration for the sake of matching boundary? What is the typical reason to have supernetted configuration on AD Sites and Services? Just simplicity?
Q2 As SCCM 2012 comes with Active Directory Forest Discovery, it might be better to match it anyway?