Lessons Learned: CRM 4.0 Adapter for GP 10.0

We are excited about this new integration, so we jumped right in, and installed it on our production systems. Our systems engineer is a genius, and what follows are his comments related to his experience. Consider this an experiential addendum:

1. Must have GP 10 SP4 applied. (There are caveats to sp4 so be aware)

2. Must have at least rollup5 for CRM applied. (Rollup6 was out in Oct 2009 so I used rollup6)

3. Must have GPwebservices for GP10 sp4 and Management tools sp4 installed.

• Had issues with the GPwebSerice not showing up in Dynamics Security console.
• Ran a repair on the GPWebServices and the management tools and it resolved the issue.

4. Must have Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update applied to same server GPwebservices is installed. http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=766a6af7-ec73-40ff-b072-9112bab119c2#filelist

5. Must have domain service accounts created. You can determine how many you need. Recommend at least 3 svc_gpweb, svc_gpcrmadmin, svc_gpcrm.

6. GPWebservice Account - Permissions granted during install.

7. Installation account – The account that installs the Microsoft Dynamics CRM Adapter for Microsoft Dynamics GP.

a. Be a domain user and a member of the Local Administrators group on the server where Microsoft Dynamics CRM Adapter for Microsoft Dynamics GP is to be installed.
b. Be assigned at least the dbcreator and securityadmin server roles on the SQL server where the MSDI database is to be stored

8. Integration account – The account that the Microsoft Dynamics CRM Adapter Service runs as. Permissions granted during install of Dynamics GP CRM adapter.

9. Configuration account – The account that runs the Microsoft Dynamics CRM Configuration Utility.

a. This account must be able to modify the membership of the CRM PrivUserGroup Security Group in the domain that the Microsoft Dynamics CRM Servers are joined to.
b. If this account is not in the db_datareader and db_datawriter roles for the Microsoft Dynamics CRM organization databases, you must use a SQL Server user name and password to update the Microsoft Dynamics CRM organization databases.

10. Integration GP account – The account that the Microsoft Dynamics CRM Adapter for Microsoft Dynamics GP uses to connect to Microsoft Dynamics GP Web Services.
a. Permissions granted in the Dynamics Security Console

11. Integration CRM account – The account that the Microsoft Dynamics CRM Adapter for Microsoft Dynamics GP uses to connect to Microsoft Dynamics CRM Web Services.
a. This account must belong to a Microsoft Dynamics CRM User that has organizational-level read privileges for system user on the CRM Organization that you plan to integrate.

12. CRM Deployment Administrator account – The account that the Microsoft Dynamics CRM Configuration Utility uses to retrieve a list of Microsoft Dynamics CRM organizations and apply customizations to the Microsoft Dynamics CRM organizations.

13. GP Adapter configuration - Had an error: application domain ...... Only way to fix it was uninstall adapter and remove MSDI database. (just removing database may have fixed it but just uninstall did not)

How do you install a large number of workstation after an upgrade efficiently?

Recently we have discussed best practices about upgrades in our company. One of the big challenges in an upgrade is installing a large number of Dynamics workstations at the appropriate time with minimal user interruption as possible. Installing Dynamics has always been a pain. MBS has approached fixing this issue with their mass deployment tools but they never work and it usually ends up easier to do the installation manually. Depending on the installation you could spend 15 mins - 40 mins per workstation. Launching the installs simultaniously (3 at a time in the same area for example) may cut time a bit but still a huge pain.


This led to a series of responses by our technical team. Here is a summary from one of our team member Jason Young. Summary of response below:


One of the tricks I have used many times to minimize downtime for large rollouts is to leverage imaging tools like Acronis True Image. This tool lets you take a picture of a server or servers and redeploy them in a virtualized environment or dissimilar physical hardware. In essence, you can take the customers environment back to the office for the test upgrade without risk of downtime or impacting day to day production of the customer.

Imaging gives you some big advantages:

1. You don’t change the state of the customers environment until testing is successful and you are ready for the production rollout. This gives you huge kudos in the eyes of local IT staff.


2. You always have a clean rollback image.


3. You don’t have to bother local IT staff because you are working with an image offsite.


4. You can couple this type of test upgrade with a Terminal Server (which we have and is easy to build) and now you can do your user acceptance testing via web. Again, no customer impact.

To do the production rollout it is always optimal to do a parallel installation, but the obvious drawback is the cost of hardware. For customer without additional server resources, there is another trick that can minimize downtime and customer impact. For customers with a single backend server (single SQL server), you install a name instance of SQL and restore production data to the new named instance.

Here are the advantages;

1. A named instance of SQL means you have to use a different DSN name than the default instance. This means you can pre-install workstations with the new version and point them at the new instance without worry of an accidental upgrade.
2. The current state is not affected so you have a rollback in the event of an upgrade failure. You don’t have to do any type of restore because you never changed the data in the default instance of SQL.
3. You are basically taking a single server and doing a parallel application upgrade. So, it’s an in-place upgrade in terms of hardware but parallel in terms of the application and data.

End of summary.

Discussion: I like the seperate instance of SQL approach. I do this with different versions of Dynamics. I have 9.0 on one instance and 10.0 on another. You'd have to be careful that users do not launch and continue working in the older version instead of the newer version but that can be overcome with training or simply stopping the older instance of SQL when the time is right (probably need to set the older instance to manually start in case of a server reboot).

Anything you do to make this task easier?