However, most users do not know how to achieve this, and they end up resorting to using third party software integrations with Dynamics 365. They want to select a button in Outlook, fill out a form, and have the information mapped back into Dynamics 365. If credentials are cached, such authentication changes should be transparent, allowing users to work without interruption as laptops roam between various locations.Many people are interested in establishing a reliable connection between Outlook and Microsoft Dynamics 365.
If this succeeds, the Outlook client obtains intranet web application and web service URLs from the internal discovery service endpoint, and again refreshes Outlook CRM web folders accordingly. First, the cookie is deleted, and AD authentication is attempted.
When the Outlook client re-joins the workplace network, an IP change is detected, and a similar procedure is applied.
USING OUTLOOK AS A CRM OFFLINE
If authentication fails, and the Outlook client is offline-enabled (and has synchronized offline data at least once), it automatically moves to the offline state, allowing the user to work in disconnected mode. The Outlook client refreshes Outlook CRM web folders to point to the correct web application URL. The Outlook client also obtains Internet web application and web service URLs from the external discovery service endpoint. Subsequent requests therefore automatically carry the cookie, which the server of course verifies. The CRM authentication ticket is persisted in the IE cookie jar. Since specified credentials are transmitted over the network, using SSL is strongly recommended to prevent interception. In IFD mode, the Outlook client submits specified credentials to the external discovery service endpoint, and receives a CRM authentication ticket in exchange. If cached credentials expire or become otherwise invalid, this dialog will of course reappear.
USING OUTLOOK AS A CRM PASSWORD
You can request that credentials be cached by checking the “Remember my password and connect me automatically” option, in which case this dialog should not be displayed any more. If credentials are not cached, an authentication dialog is displayed. If this fails, it attempts to connect using IFD authentication. To implement authentication switching, the Outlook client first attempts to connect using AD authentication. Users may receive balloon notifications indicating the Outlook client is trying to apply the appropriate authentication method. To detect when switching authentication mode may be required, the Outlook client detects IP changes, which should occur when joining or leaving a network. Step through the wizard to complete configuration.Īfter configuration, the Outlook client will automatically select the appropriate authentication mode. Enter the discovery service URL exposed to the internet in the text box labeled “Extranet Web address”. Enter the internal discovery service URL in the text box labeled “Intranet address”. Next, the wizard prompts for both an intranet and an internet server URL. Also, ensure that at least one server has already been configured in IFD mode. For configuration to succeed, the Outlook client must be able to connect to the server using AD authentication. To enable the Outlook client to take advantage of this new capability, select the “My company” option during configuration. The Implementation Guide – “Sample Server XML Configuration File for Internet-Facing Deployments” section provides instructions to configure CRM Servers in IFD mode. Version 4.0 includes a new authenticated mode, called Internet Facing Deployment (IFD) mode, specifically designed to eliminate the VPN requirement. However, this requirement increased complexity, and sometimes was impossible to meet if bandwidth was limited. To connect from outside the workplace network, a VPN solution was therefore required. In version 3.0, the CRM Outlook client could only use Active Directory (AD) authentication to connect to servers.