Exchange - Server Type Troubleshooting

This section covers troubleshooting authentication and connectivity related issues.

Typically Exchange Server Type is used on environment that does not have Microsoft Outlook installed or environment with 64-bit of Microsoft Outlook installed.

Keep in mind that Exchange Server Type does not require Microsoft Outlook for functionality.

Authentication

When a new GP client session is started, user will be prompted for their email credential when attempting to perform an email related task; any subsequent email related tasks will not prompt the user for their email credential.

On most environment entering the email address and password is sufficient for Exchange server authentication. However, on some environment, user may need to click Show Advanced... and enter their login ID (DOMAIN\USERNAME).

The most common issue encountered with Exchange server type select, are users repeatedly prompted for their email credential not being able to get pass the Exchange Log On window.

Exhcange Autodiscover Service

The email credential entered on the log on prompt above (specifically the email address) is used to determine the Exchange server to connect to using the Exchange Autodiscover Service.

For example if the email address johnd@fabrikam.com is entered, the following address/record will used for the autodisover service address:

• https://fabrikam.com:443/Autodiscover/Autodiscover.xml
• https://autodiscover.com:443/Autodiscover/Autodiscover.xml
  
  
• HTTP Redirect
  For example if environment has a website accessible via http://fabrikam.com, any attempt to access http://fabrikam.com/Autodiscover/Autodiscover.xml can be redirected to the correct Autodiscover Service address.
  
  
• DNS SRV Redirect
  A DNS SRV (Service) record can be added to redirect to the correct Autodiscover Service address.

It is important that the Exchange Autodiscover Service is properly setup, and is accessible from the workstation/server the Dynamics GP client is running from.

Also, Dynamics GP client has the least problem authenticating when Autodiscover Service address has very few or no redirects; preferably accessible using the first address it tried (https://<FQDN>:443/Autodiscover/Autodiscover.xml).

Exchange Troubleshooting

Troubleshooting Exchange Autodiscover Service Accessibility

There is three tools that I use for troubleshooting Autodiscover related issue.

Microsoft Remote Connectivity Analyzer

The first one is Microsoft Remote Connectivity Analyzer page. This is the quickest and easiest way to determine if the Exchange Autodiscover Service setup has been performed correctly and is accessible. However, keep in mind that the tool checks service accessibility externally; service accessibility is not guaranteed to be the same on internal network.

Select Outlook Autodiscover under the Microsoft Office Outlook Connectivity Tests, then click Next.

Enter the user's credential + captcha on the next page, then click Perform Test. The test may take a couple of minutes to complete.

Once complete, you will see similar page below. Result you are looking for is Connectivity Test Successful or Connectivity Test Successful with Warning. However Connectivity Test Failed can also indicate an issue with an incorrect password, so I recommend running the test a couple of times.

If you do receive a fail even after verifying all the details, then it indicates Autodiscover Service has not been setup or connectivity issue to Autodiscover Service. Important points to check are:

• • Exchange Autodiscover Service setup
    https://docs.microsoft.com/en-us/exchange/architecture/client-access/autodiscover?view=exchserver-2019
    
    
    • Autodiscover FQDN/URL - this can be different for external/internal network. Confirm that this is accessible.
    • Autodiscover certificate - valid certificate (trusted) is required for proper functionality.
      
      
  • DNS records
  • Website redirects.

The second tool is EWSEditor. This is a powerful tool that allows testing and debugging Exchange Web Services (including Autodiscover Service). Similar to the Microsoft Remote Connectivity Analyzer tool, we will be using EWSEditor to determine if the Exchange Autodiscover Service setup has been performed correctly and is accessible. Unlike the Microsoft Remote Connectivity Analyzer tool, the EWSEditor tool checks service accessibility from within the internal network.

Navigate to File > New Exchange Service... to open the Exchange Service Configuration. Then enter the user's email address on the Autodiscover Email field, select Use the following credentials instead of the default Windows credentials and the user credential in the appropriate fields, then click OK.

If you receive the dialog below, click Yes - this means that the Autodiscover Service has been setup and is accessible.

If you receive an error, try Use oAuth (Registration must have been complete first) on the Exchange Service Configuration window if environment utilizes Office 365 Exchange/Exchange Online service. 

Note which authentication method were successful - it will be important on later troubleshooting steps.

Important points to check are pretty much the same with the Microsoft Remote Connectivity Analyzer tool.

Fiddler

In addition to the two tool above, you can use Fiddler to log and analyze traffic between Dynamics GP client and Exchange Autodiscover Service. Specially if you are able to confirm that the Exchange Autodiscover Service has been setup correctly and is accessible, but are still encountering an issue, this tool can give you an insight on what is occurring on the background.

Make sure that there no other network traffic (specifically web traffic) when running Fiddler, as it logs all web traffic.

After starting Fiddler, it will start logging right away - either push F12 or nagivate to File > Capture Traffic to stop logging.

Before restarting logging with Fiddler, you will need to install the intercept certificate to allow HTTPS traffic decryption - traffic to the Autodiscover Service is encrypted and skipping this step will prevent you from reading traffic details.

Navigate to Tools > Options then navigate to the HTTPS tab, then enable Capture HTTPS CONNECTs and Decrypt HTTPS traffic. Finally, click Actions then select Trust Root Certificate.

You will be prompted sever times if you really want to install the cetificate - click yes on all of them.

Click OK to close the option window and you're ready to start logging.