<aside> 🧭
Navigation:
</aside>
The Dynamics CRM (on-premise) data migration failed following an update to Windows Server 2003 (security patches). Precisely, the refresh token process of Google Service (DFP Publishers) failed.
Resolving this authentication issue consisted of a 3-step approach:
→ Preliminary validation process: Windows Service (listener) and data migration Servers (event viewer) logs.
→ Problem isolation process: Windows Service application as an executable, Debugging of the .Net Library of Google API , Physical environment of the Windows Service and finally, the users and the domain controller.
→ Resolution process related to Windows Service physical environment: It was necessary to develop a new service (as a listener) to transfer the Dynamics CRM data to the new physical environment (Windows Server 2008/2012) and in a new queue. Once the data is transferred, the service (listener) deployed in the new physical server will be able to retrieve data from the queue and will be able to migrate data to Google Cloud.
The white paper does not provide any confidential client data related to data migration. All the code in this white paper is only related to the CRM SDK365 code
The architecture is composed of Dynamics CRM (On-Premise), Windows Services (Listener), Microsoft Message Queue, Google Premium (Google Cloud Service) and Third-Party (DFP Publishers).
Accounts and contacts data had to be retrieved from CRM and placed in the Microsoft Message Queue (MSMQ) data storage directory. Data was exported in XML format and stored in a directory created for this purpose. The service (Windows Service - .NET application developed in C#, deployed in Windows Server 2003) behaved as a "Listener" in order to retrieve the data stored in the MSMQ directory. Once retrieved, the "Listener" had to authenticate to Google Premium Web Services in order to import the data (CRM accounts and contacts) into the online service directories (Google Premium).
Once the data was extracted from the MSMQ directory to the Google Premium directories, the data was cleaned from the MSMQ directory. However, in the event of an error or exception generated by Google’s Web services, the data was stored in an MSMQ directory created for this type of situation.
Finally, the "Listener" had to establish communication with Google’s Web services and for that purpose, a security token ("Token") had to be generated and its refresh was also generated during the transaction. For further information, Google API Web service uses the OAuth 2.0 "Framework" which specifies several types of authorization (Refresh Token, Client Credentials, etc.).