A client of ours recently reported that they could no longer create custom attributes to an entity in Microsoft Dynamics CRM 4.0. They received a generic "An error has occured" error message when the CRM administrator tried to do this.

After some investigation, we disocvered that they had changed the name of their network's local domain to reflect a change in their company's name. Their network folks went through all the proper processes to implement the change in the Active Directory domain name - except when it came to CRM.

Typically, when changing the domain name, where Microsoft CRM is installed on-premise, you would need to redeploy or reinstall Microsoft CRM in the new domain, and import the backed up organization database into the new deployment. This process would take care of updating the database where necessary to reflect the domain name changes. (See Microsoft KB 952934 for details on how to redeploy CRM.)

In this case, this didn't happen, and the result was a somewhat malfunctioning CRM system.

Of course, this problem wasn't immediately apparent to us based on the generic error message and the limited information we were provided by the user who was experiencing the error. We used SQL Profiler to see what messages were being passed to the database directly before the error occurred, and that's where we were able to see the errant references to the former domain name. The culprits were in the OrganizationBase table, specifically in the SqlAccessGroupName, ReportingGroupName and PrivReportingGroupName fields.

To fix the error, we did a manual update on the SQL databases (after making good backups!) in the SQL Query Analyzer as follows*:

UPDATE [ClientOrgName_MSCRM].[dbo].[OrganizationBase]
SET SqlAccessGroupName = 'NEWDOMAIN\SQLAccessGroup {60ebfabc-4c2d-4ab7-9870-84d544336af5}'
  
UPDATE [ClientOrgName_MSCRM].[dbo].[OrganizationBase]
SET ReportingGroupName = 'NEWDOMAIN\ReportingGroup {60ebfabc-4c2d-4ab7-9870-84d544336af5}'
  
UPDATE [ClientOrgName_MSCRM].[dbo].[OrganizationBase]
SET PrivReportingGroupName = 'NEWDOMAIN\PrivReportingGroup {60ebfabc-4c2d-4ab7-9870-84d544336af5}'

(NOTE: If you use this script on the SQL database, make sure to replace 'ClientOrgName_MSCRM' with the actual name of the CRM database, and NEWDOMAIN with the new name of the local domain. You can find the correct GUIDs in Active Directory by looking at the security groups that your CRM is using.)

*WARNING: This is unsupported. Microsoft does not support direct updates to the SQL database!