We’ve seen this issue come up a couple of times so I wanted to give it a mention here just in case you run into it. The problem is that if you are using System Center Configuration Manager 2007 (ConfigMgr 2007) or System Center 2012 Configuration Manager (ConfigMgr 2012) and trying to push packages to a VPN client, the client reports the below error and also fails to get the content location.
Current AD site of machine is XYZ 1/1/1601 12:00:00 AM 0 (0x0000)
Adapter {D4CB67B7-FC80-439A-BC06-C41489B73259} has 1 IPv4 address(es). 1/1/1601 12:00:00 AM 0 (0x0000)
Adapter {23C23F44-8A8E-46A1-A863-8BC925CBBA05} has 0 IPv4 address(es). 1/1/1601 12:00:00 AM 0 (0x0000)
Discarding DP with SiteLocality 'FALLBACK'. Accepting only 'LOCAL' DPs. 1/1/1601 12:00:00 AM 0 (0x0000)
The number of discovered DPs(including Branch DP and Multicast) is 0 1/1/1601 12:00:00 AM 0 (0x0000)
LSGetSiteCodeFromWMI 1/1/1601 12:00:00 AM 0 (0x0000)
LSGetSiteCodeFromWMI : Site code returned from WMI is <XYZ> 1/1/1601 12:00:00 AM 0 (0x0000)
Troubleshooting:
We checked and found that this issue occurred only with the VPN clients, as only those clients were not getting the content location. We then checked and found that the VPN clients have two NIC’s with two different IP’s, but there was no boundary for the clients VPN boundary.
Cause:
The VPN subnet needs to be added as a boundary to the site server according to the DHCP scope set for VPN clients.
Solution:
We need to understand that the client machine connects to the domain after logging on to the workstations and after dialing in to the VPN tunnel, and until that time it already has an IP assigned to its physical NIC. After connecting to the VPN it also gets another dynamic IP through the DHCP server of the domain, and this IP is assigned to the virtual NIC configured for connecting to VPN tunnel. At this point, the machine in the domain will be identified by this VPN NIC IP address and not the physical NIC IP address of the workstation, meaning that the client machine will do the content location lookup using the VPN NIC IP address. If the ConfigMgr server does not have a boundary configured with that IP subnet or address range, the VPN client will fail the content location, and also it will not fail over to the physical NIC IP address to find a suitable boundary.
More Information:
This problem can occur when the VPN clients get dynamic IP address assignments that are not a part of any boundary. If you’d like to verify this scenario, you can take a NetMon trace here to find the client machines network connection, and also enable verbose logging.
The TechNet articles below have more information on this:
http://technet.microsoft.com/en-us/library/cc984479.aspx
http://technet.microsoft.com/en-us/library/gg682077.aspx
Arvind Kumar Rana
Get the latest System Center news on Facebook and Twitter:
App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/
The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity- support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/