Share
ReportThis post can be used for troubleshooting on-prem authentication issues, access issues, custom App. connectivity, Outlook plugin not working, etc.
Once there is custom NLB in place and there are authentication/access issues. We need to validate if this doesn't happen/reproduce with a direct connection.
In scenarios where you have a configuration that ADFS cannot connect directly to CRM servers, but the connection gets redirected through an NLB or proxy we need to validate if bypassing them the issue experienced is still present.
In an on-premise environment we can indicate from where the requests are coming from by using the "ping" command via PowerShell to the external URL or the auth. URL or discovery URL and check whether the response is coming from the LOCAL IP (of CRM Servers) or from a different IP address(external).
*Per configuration guidance the auth. URL host A entry and the CRM external URL host A and discovery URL host A entry should be pointing to the IP of CRM application server*
Example:
Confirm the local IP addresses of the CMR server.
You can do that through Server manager - Local server - Private Switch
Ran command: "ipconfig" and confirm the IPv4 Address
We can confirm the origin of the (external) IP address, but in order to test if the configuration of CRM with AD FS is working fine without the 3rd party NLB/Proxy we can perform the following actions on both ADFS and CRM Servers:
Locate the host. files on both machines:
C:\Windows\System32\drivers\etc – hosts
Open with Notepad.
On both machines enter the following entries in the hosts file and save (for example):
172.16.0.100 auth.contoso.com
172.16.0.100 crmv9.contoso.com
172.16.0.100 dc.contoso.com
!IMPORTANT!
Take backup of the host files in their original state prior to making any changes.
======================================================
These steps should be related to the respected IP that the machine has and also the dedicated DNS entries for the auth. and CRM external URL (which should mimic the org.name) and Discovery URL.
That way we will force the connection between the machines to happen on local level and by-pass the network configuration.
Following this you can test the connection/behavior from the CRM Server's browser. If you are able to resolve the scenario from the local machines, but from client machines (outside of the local setup) you are still facing the problem/issue it would mean that the issue is on your network level and you should review the scenario with the help of your network team to validate if a direct connection makes the problem go away.
All responses (
31
