This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](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(249.60000000000002, 71%, 34%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ELD%3C/text%3E%3C/svg%3E)
Hi,
We have configured CMG, where we have a standalone Primary Site server version 1910. Before implementing CMG, installed a New site system server with the following site system roles:
CMG status is ready and connection point is in Connected status. On the client machine--> Control panel--> Configuration Manager-->Network tab shows the Internet-based MP FQDN correctly which is the CMG.
Assigned the new MP site system to the boundary group and confirmed that the client is able to identify the available MPs.
Once I disconnect from VPN, the client's connection type changes from intranet to Internet. However it is not showing the Assigned MP (E-HTTP) as the Internet MP.
LocationServices.log file shows repeated errors as "Failed in WinHTTPSendRequest API, ErrorCode = 0x2ee7" which translates as ERROR_WINHTTP_NAME_NOT_RESOLVED. Please guide on what is missing here for the client to be unable to get assigned to Internet MP.
ERROR_WINHTTP_NAME_NOT_RESOLVED
That says it all. Whatever name you've configured for the CMG service is not resolvable via DNS from the client.
So the E-HTTP site system server should be added to public DNS. Is this correct ? So that the internet clients can communicate with this MP over Internet.
No. The client is attempting to connect to the FQDN you assigned to the CMG service.
Under Primary site server properties-->Communication Security tab -->Site System settings , the setting for using E-HTTP is enabled.
Under Client settings-->"Trusted Root Certification Authorities" there is no Root CA specified currently. Should we specify the client's trust root CA here for this issue ?
No. And, neither of these have anything to do with DNS name resolution.
ok will add the CMG service to public DNS and check again.
Still seeing name resolution error. After installing CMG connection point, it established connection with CMG service using port 443 as port 10140 is not open on the server. With this the connection analyzer showed all in Green. However now the last check in connection analyzer is failing with error "Failed to get ConfigMgr token with Azure AD token. Status code is 500 and status description is 'CMGService_No_Connector'.
Along with 443 should we also open 10140 port on the CM connection point server ? Thanks for your help.
The CMG connection point first tries to establish a long-lived TCP-TLS connection with each CMG VM instance. It connects to the first VM instance on port 10140
Does this mean while opening the port 10140, the source is the CMG VM instance and destination is CMG connection point ? Our network team is asking this question
These are two separate, unrelated issues.
For the name resolution issue, you need to add the proper names to your DNS zones.
For the CMG connector and ports, TCP 443 is not enough. This is well defined in the official documentation: https://learn.microsoft.com/en-us/mem/configmgr/core/clients/manage/cmg/plan-cloud-management-gateway#ports-and-data-flow. You need TCP 443 and 10140 or TCP 443 and TCP 10124.
Does this mean while opening the port 10140, the source is the CMG VM instance and destination is CMG connection point ? Our network team is asking this question
The CMG connection point initiates the network connections. As long as there is a stateful packet firewall in place and the outbound traffic from the CMG connector is allowed, then the return, inbound traffic from the CMG service and CMG VM will be allowed.
Thank you for the response.
For the name resolution, the CMG service name is already added to public DNS and Alias for the same is also created. Should we add the internet-facing site system with Enhanced HTTP MP's FQDN also to be added to public DNS ?
Should we add the internet-facing site system with Enhanced HTTP MP's FQDN also to be added to public DNS ?
I already answered that above: no. That's the entire point of the CMG service.
I can't tell why DNS name resolution is not working though for the CMG name from the client. You need to troubleshoot that as it could be one of many different things, none of which have anything to do with ConfigMgr or CMG.