2009/07/30

Installing CRM 3.0 in a SQL instance

If you want to use CRM 3.0 with a named SQL instance you first have to disable the Environmental Diagnostics Wizard (EDW). How to do this? I couldn’t find a way except for a couple blogs/newsgroups pointing me to a support call with Microsoft. The Microsoft CRM Support Team might not like me posting this simple solution, but I think it is crazy that we got charged a support call for something like this and hopefully my post can prevent someone else from being on hold for two hours.

To disable it, you simply open RegEdit on the CRM server, browse to the MSCRM key at HKEY_LOCAL_MACHINE -> SOFTWARE -> Microsoft -> MSCRM and add the DWORD “IgnoreChecks” and give a value of 1.

You will have to reinstall CRM on the box and reconfigure what SQL server/instance you want to use there. You will get to the screen that has the warnings/errors, and the SQL line item will still give you an warning/error, but with the registry edit you can still click the Next button to proceed (without EDW disabled you can’t proceed). After finishing the install you can delete the registry entry you added.

2009/07/13

Active Directory Security Groups for MSCRM

Active Directory Security Groups for MSCRM
Posted on January 26, 2007 by Ayaz Ahmad [MVP - MSCRM]
When developing custom applications or MSCRM integration with SharePoint, security issues are the prime concerns. In order to handle these issues, one must need to know the internals of MSCRM security and how it interacts with Active Directory. Microsoft Dynamics CRM stores user information in Active Directory to provide application security. For this purpose, the following Active Directory groups are added to the Organizational Unit specified during installation:
UserGroup
ReportingGroup
PrivUserGroup
SQLAccessGroup
UserGroupAll Microsoft CRM users. This group is updated automatically as users are added and removed from Microsoft CRM.
ReportingGroupA group that contains all users within Microsoft CRM. This group is updated as users are added to Microsoft CRM. Users in this group have read-only access to the filtered views in the Microsoft CRM database.
PrivUserGroupPrivileged Mi
crosoft CRM user group for special administrative functions.
SQLAccessGroupA group that contains Microsoft CRM ASP.NET account and other service accounts. Members in this group have full access to the Microsoft CRM database and this group is used by the Microsoft CRM platform layer. End users should never be added to this group. Now instead of adding each user and granting him access to SharePoint Libraries, try adding these security groups and setting permissions as given in the screenshot below:

Use these two SQL queries to get these groups at your system:
SELECT SqlAccessGroupName FROM FilteredOrganization
SELECT ReportingGroupName FROM FilteredOrganization
When developing applications/add-on, please consider these scenarios:
Callout and Workflow .NET assemblies typically run under the context of the local machine’s Network Service account.
Code called from the client using a custom script typically runs under the context of the logged on user.
Code called from the server using an ASPX page running in a Virtual Directory or other Internet Information Services (IIS) site typically runs under the context of the logged on user.
So, configure proper security roles to your users before setting up add-on/custom applications/callouts/workflows.
For information on how to grant access to your user, please look into MSCRM SDK “External Components”
For Information on how to manage security at Reports, please look into MSCRM Implementation guide “Understanding Report Permissions”.