4,608 questions
If you are working with ms support, I would keep working with them. Your only other option is to read all of the log.
Issue with MECM site systems communicating using direct private IP rather than with FQDN
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(262.40000000000003, 74%, 35%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EGM%3C/text%3E%3C/svg%3E)
Gary Moss
0
Reputation points
We are currently experiencing an issue within our MECM sites where traffic between site system servers (within the same site) uses in some cases the private IP of the remote server rather than the IP which resolves to the FQDN.
As an example, within the site, the Primary Site Server is in one Windows domain (tenant), we have a source distribution point within the same domain and a pull distribution point in a separate domain (tenant).
When observing the network traffic flow between the Primary Site Server and the Pull DP (in the separate domain) we notice that on SOME occasions, that rather than the communications (e.g. SMB, RPC) taking place using the FQDN of the remote host (which by using our DNS resolves it to a public IP address configured on a proxy server) it uses the private IP of the remote host instead. This causes us problems in our secure environment in that all traffic between domain (tenants) must go via a proxy server in a DMZ - hence the use of DNS to resolve it to a public IP configured on the proxy.
The vast majority of MECM traffic uses the FQDN-resolved IP as expected. Of course when you add a new site system to MECM you configure it with the FQDN and hence it should use that.
I was wondering if anybody else had observed this behaviour and had any ideas?
We experienced the issue with MECM 2203 but the issue remains after upgrading to 2303.
Microsoft Security | Intune | Configuration Manager | Other
{count} votes
-
Garth 5,801 Reputation points2023-08-11T11:59:14.8833333+00:00 ConfigMgr itself use name resolution for everything, with one exception. The exception is remote control. As such, I would look at the OS and not ConfigMgr for the problem.
-
Gary Moss 0 Reputation points
2023-08-11T15:22:31.8833333+00:00 Thanks Garth - we've done a lot of investigation into whether there is something strange going on from a DNS perspective e.g. checking nslookups, having tried adding PTR records etc, but the name resolution side of things seems to be okay from an OS perspective as far as we can tell and I'm not sure what else it could be from purely a Windows OS side of things.
We use the same method of forcing cross-domain traffic to go via proxy servers using DNS for many other applications within the estate but we only see this specific issue with ConfigMgr.
My working theory originally was that ConfigMgr may be caching the private IP somewhere, e.g. in the client object for the remote site system or perhaps in the DB, but already having engaged MS Config Mgr support they have confirmed that this should not be the case.
Sign in to comment