Dynamics CRM 2011 Sharepoint list component is not installed

Check my Wiki article for most recent CRM sharepoint list gotchas:
http://social.technet.microsoft.com/wiki/contents/articles/6918.dynamics-crm-2011-sharepoint-list-component-gotchas.aspx

While installing the Dynamics CRM 2011 List Component I get Microsoft Dynamics CRM List Component is not installed. After a couple of search engine results was clear that this was a common configuration error.

I found a website that was suggesting creating new accounts and give site collection admin etc. I have tried all that and it didn't work. My case was different. Also there is no need to give extra permissions or extra configuration e.g. there is no need to give Site Collection Administrator permissions to the account running the CRM AppPool, also you don't need to change the web application to permissive.

So I've installed the component as instructed on the download page, the only note I want to add as the page does not clarify is how you add the extension AllowHtcExtn.ps1 to sharepoint:

Run the Windows powershell as Administrator and do the following:

 Navigate to the file location and run: filename http://servername

After completed make sure your wsp solution is enabled. On dynamics CRM navigate to settings > document management > Document management settings

Type the Sharepoint site address and click next:

  

And I get the above error.

Solution

I've installed sharepoint foundation on the same server as dynamics CRM. Sharepoint automatically stopped CRM website and taken over port 80. My first reaction was to change CRM to port 81

I've realised that if I swap ports CRM to port 80 and sharepoint to port 81 (needs sharepoint internal address alternate mapping to be changed) the configuration would work.

So I've come to the conclusion that the Sharepoint List Component must be connecting back to CRM reading the following database keys:

ADSdkRootDomain

ADWebApplicationRootDomain

The above keys hold the CRM address plus the port number. In  CRM 4 you could change this directly on the database,  however CRM 2011 deployment manager ships with more functionality and this can now be done from deployment manager. Open deployment manager and on the Actions panel (on the right) click Properties. Go to Web Address:

Change the port number to the correct one and click ok.

If you now try to configure the sharepoint list component you get the correct screen :)

The CRM admin setting up the document management settings, does not need full control in Sharepoint the minimum permissions to create the sharepoint libraries are: Design, Read and contribute.

Conclusion
Dynamics CRM 2011 reads the following database keys, to establish a connection back to CRM:

ADSdkRootDomain
ADWebApplicationRootDomain

If CRM port was changed in IIS, make sure this is also changed on deployment manager so the port number is also applied to the above database keys.

Quick notes:

1. No need to give Site Collection Administrator permissions to the account running CRM Application pool
2. The CRM Admin user setting up document management settings only requires Design, Read and contribute permission to create the document libraries in sharepoint. Full control is not needed.
3. No need to create a second Domain account with domain admin. CRM uses the current logged on user permissions to create the sharepoint libraries and not the Application Pool account.
4. The two steps given on the microsoft download page are enough to complete the configuration. However the CRM user setting up the document libraries in CRM needs permissions in sharepoint to create the document libraries.
5. There is no need to change the web application to Permissive.

Hope this helps! :)

Dynamics CRM 2011 Name translation: Could not find the name or insufficient right to see name

I'm in the process of upgrading CRM 4 to 2011 and while installing my dev environment I get an interesting error; interesting for the fact that it relates with AD infrastructure and not an AD permission issue, also is not referring to what is exactly causing the issue:

Name translation: Could not find the name or insufficient right to see name
(Exception from HRESULT: 0x80072116)

 The error message says that it can't resolve something, and the issue is related with a user account given for the sandbox service, although if you give an incorrect user account on the previous step, it will automatically error with; user account is invalid.

The installer could not resolve the AD account because the Global Catalogue on that site was not aware of the AD account. The user account was not replicated to the Global Catalogue site where I'm trying to set up CRM. The below diagram is an example of two sites with a DC GC which replicate between each other. Global catalogues store AD objects, if you create a user account in NYC site and if AD replication is set to occur only the next day due to limited bandwidth available, user accounts in New York will only be available in the London site the next day.

If you have the permissions you can trigger AD replication between two servers using Active Directory Sites and Services. Open ADSS and expand one of the sites, open the servers folder and highlight one server, on the right you see NTDS Settings double click and you should see a number of connections to other Servers in different sites. right click and select Replicate Now.

That message also refers to insufficient rights to view it, this could also be lack of permissions to access the AD object.

Manually triggering AD replication, has fixed the issue.

Dynamics CRM 4.0 SQL Dead Locks

I have to admit Dynamics CRM is slightly addictive. A web based application that integrates with Outlook, can challenge you at many different levels, authentication(kerberos), IIS, AD, SQL, reporting services, E-mail relays, Exchange integration, development and customization, it uses all Microsoft main platforms to create this powerful and flexible application. And is this interesting integration with a variety of systems that makes me constantly busy in search for more knowledge.

I want to share a few registry keys and SQL tips to improve the SQL dead locks that can occur on enterprise role based environments.

Lets consider the following environment:

Platform01 & Platform02 work on a Active/Active set up, there is no out of the box Active/Passive option unless you configure a Windows Cluster. Both Asynchronous servers constantly read the CRM database for pending jobs to process. As you can imagine having two servers actively looking for jobs to process will certainly at same point both servers will try to process the same jobs and this is one of the main reasons deadlocks occur on this type of environments.

CRM Tweaks

Registry changes: Configure the following registry key on the Asynchronous servers in order to improve performance and avoid dead locks.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM

Name: AsyncDBAppLock          
Type: DWORD
Value: 1

For more information on the above registry key refer to the following KB:
http://support.microsoft.com/kb/2249156

Database changes: On the MSCRM_CONFIG database, DeploymentProperties table you can find a few fields starting with Async, these fields are used to control the Asynchronous service behaviour tweaking it to your exact needs. Important: changes to these fields should be done always on a dev/test environment before applying it to production and always backup your database or table before changing it.

We will not cover all the available keys here, the idea with the below changes are intended to reduce the amount of records the async services process, lowering the probability of accessing the same records and causing deadlocks.
--

update DeploymentProperties set IntColumn = 200 where columnname = 'AsyncItemsInMemoryHigh';
update DeploymentProperties set IntColumn = 100 where columnname = 'AsyncItemsInMemoryLow';

 --
The default values are 1000 and 2000 we lowering to 200 and 100. keep an eye on the backlogging, if you notice jobs building up, you can increase this slightly or play with the below query to increase the Select Interval, again these values should be customized based on our environment workload:

--

update DeploymentProperties set IntColumn = 1 where columnname = 'AsyncSelectInterval'

--


"AsyncItemsInMemoryHigh – Max number of async operations the service will store in memory. Upon selection interval, if the number of items in memory falls below AsyncItemsInMemoryLow, the service will pick enough to reach up to AsyncItemsInMemoryHigh again.
AsyncItemsInMemoryLow – Minimum number of async operation the service needs to have in memory before loading new jobs into memory. Upon selection interval, if the number of items in memory falls below this value, the service will pick up enough to reach AsyncItemsInMemoryHigh again."

Performance and Scalability Assessment of Customer Implementation
http://www.microsoft.com/downloads/details.aspx?FamilyID=e76d8916-81a6-4330-90ae-b24f8263fff8&DisplayLang=en


SQL Server Tweaks
On the SQL side there are a couple of tweaks I want to mention to improve performance and avoid dead locks. I would start with enabling read committed snapshot isolation. Important: Enabling this option can impact on the SQL server performance, make sure you monitor performance closely after changes made.

Enable snapshot isolation on both:

• MSCRM_CONFIG
• ORG_MSCRM

MSCRM4 Optimizing and Maintaining. [page. 33]
"use READ COMMITTED isolation to minimize potential locking contention while protecting transactions from “dirty” reads of uncommitted data modifications. With dirty reads, data within the current transaction can potentially be modified by other transactions between individual statements, resulting in non-repeatable reads or phantom data"


The second is setting Max Degree of Parallelism to: 1

sp_configure 'show advanced options', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO
sp_configure 'max degree of parallelism', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO

MSCRM4 Optimizing and Maintaining. [page. 34]
"Setting this value to 1 will suppress parallel plan generation, while setting the value to a number greater than 1 (up to a maximum of 64) will restrict the maximum number of processors used by a single query execution"

Hope this gives you a hand.

Dynamics CRM 4.0 Mobile Express Read Only

For those who applied CRM 4.0 mobile express, know the limitations and lack of flexibility can cause management and usability issues. One of the limitations is not being able to run javascript. Fair enough a mobile version should be simple and light enough to be used on a 3G connections. However the main drawback is related with read-only fields, these will be editable on the mobile version, users are allowed to edit those fields, but this is if the users have the buttons to edit the records.

Another limitation is the security, the existing security roles are applied to mobile express access the same way are applied to the full version, you cannot set up granular permissions for the mobile view alone, users get the same level of access on both the mobile and full version, there is no distinction.

Challenged with the fact that custom javascript cannot be used on the mobile view, any hidden and read-only fields will behave like any other static forms, which means if the users click edit, or click create new record, they will be allowed to enter data on these fields. One of the questions your company may ask: can we make it read-only? since the security roles are the same, this cannot be done, out of the box.

To make it read-only we want to remove the buttons avaiable to the user, forcing the user just to read and navigate around. The way to do this, I've managed to identify the CSS files associated with the mobile view, and add a few lines of code with the CSS statement display: none; removing the buttons I want.

The files to be edited are located:

C:\Program Files\Microsoft Dynamics CRM\CRMWeb\_common\styles\mobile\

Open in a notepad the below two files and edit the following lines:

Entityform.css.aspx 

td.actionButton

{

width: 50%;

display: none;

}

input.editButton

{

display: none;

<% if (CrmStyles.IsRightToLeft) { %>

float: right;

<% } else { %>

float: left;

<% } %>

}

input.deleteButton

{

display: none;

<% if (CrmStyles.IsRightToLeft) { %>

float: left;

<% } else { %>

float: right;

<% } %>

}

Entityhome.css.aspx

#newrecord {

display:none;

}

 The above CSS code exists on the above files, we just adding the display: none; section to hide those CSS ID's and Class's

Adding/changing CSS code on these files, also allows you to manipulate the look-and-feel of the entire mobile page. Read the HTML source code and identify which CSS ID's and Class's that control the page layout and overwrite the CSS settings on the above files.

Hope this was useful :)

Dynamics CRM 4.0 Disaster Recovery

I've posted a new article on the technet wiki for Disaster recovery planning, you can find the article here:http://social.technet.microsoft.com/wiki/contents/articles/6404.aspx

Dynamics CRM 4.0 Disaster Recovery

When designing CRM 4.0 disaster recovery solution there are a few system tweaks needed depending on which method you use to restore a lost CRM environment, is not widely documented so I want to write this article in order to assist admins understanding different approaches to DR and the small tweaks needed in the system. When talking about disaster recovery, the first thing that you may want to do is identify two important pieces of information. (a) the time the business requires you to bring back CRM to a working state (b) how much data loss is acceptable. These two pieces of information are critical to successfully design the appropriate disaster recovery solution to your business needs. these pieces of information are generally applied to all kinds of disaster recovery systems and are called:

1. Recovery Time Objective (RTO)
2. Recovery Point Objective (RPO)

Recovery Time Objective:
RTO refers to the total acceptable time to recover the system.
Recovery Point Objective
RPO refers to the acceptable amount of data loss if the system is lost.
The above brief explanation gives you an idea what RPO and RTO measures in time. Together they define the starting point of your disaster recovery solution. The Business should set these values and define how critical CRM is for the company. If 4hours is the total time defined to both RTO and RPO it means you need a backup strategy that cannot lose more than 4hours of data and you must be able to recover the system inside the 4hours RTO.

Disaster Recovery Scenarios
CRM also relies on DNS, database backups and other network components for which you also need to account in a Disaster recovery solution, is out of scope of this article to cover those components. I'm only covering the technical aspects of CRM. In a tipical DR solution, you have stand-by servers on a separate site, these servers will be specifically configured for CRM or any other application, also known as fail-over servers. I'm considering the following servers:

• 1x Application Server
• 1x Platform Server
• 1x SQL server

On your live environment you have an enterprise role-based CRM configuration with multiple Application and Platform servers. The database is backed up regularly with log shipping to comply with 4hours RPO, you backup MSCRM_CONFIG and COMPANY_MSCRM. The following are the possible scenarios to consider as a disaster recovery after the complete loss of the CRM live environment:

Restore Databases & Join servers to existing Organisation
Based on Microsoft documentation you can do a full restore of both CRM databases to a fail-over SQL server, and run the CRM setup wizard and instead of creating a new environment select the option to join to an existing environment. This method is valid although a manual tweak on the database is needed to actually make it work. The problem with this method is the time it takes to actually configure the servers with IIS pre-requisites and other server roles e.g. Indexing service, then running the setup wizard and obviously crossing fingers that no installation error occurs, if you don't update the installation setup files will most likely error. The MSCRM_CONFIG database holds a SQL connection string which CRM servers use to identify which SQL server to connect to, when you join the server to the organisation the servers will try to connect to the hard-coded server specified on this connection string, this case would be the live server which is down, even though they are actually connected to a working SQL server. You can test this, when you doing a DR exercise because the live database server is working, you will notice after joining the servers to the fail-over database server, data gets updated on the live server.
Before installing CRM and joining the servers to the new CRM environment, I would highly recommend you to manually change this SQL connection string:

1. Open SQL management studio
2. Connect to the SQL fail-over server and expand the MSCRM_CONFIG database and tables folder
3. Locate the Organization table, right click over it and select EDIT top 200 rows
4. The first column is ConnectionString this is the fields we need to edit
5. Edit each entry and replace the server name or IP address on Provider=SQLOLEDB;Data Source=SERVER_NAME;Initial Catalog=ArupSandBox;Integrated Security=SSPI

This database change will make sure the servers joining to this environment will also connect to the correct SQL server. You ready to install the Application and Platform server and join these servers to the new environment, when completed test CRM and confirm is working fine, all previous registered plugins will also be published and working as normal. The second step will be configuring the report server, the live report server is also down and reports are not working. On the application server open deployment manager, disable the organisation, right-click and edit organisation, you can specify the fail-over SQL server with reporting services and click next to configure, when completed, this creates a new folder on the SRS server, and will also publish all existing reports including custom reports. However if you use custom iframes which point at specific reports outside the folder 4.0, these reports would have been lost if you don't backup the ReportServer database, if you do use custom iframes you need to include the ReportServer database in your daily backups. If you do restore the ReportServer database make sure the datasources are correctly configured.
If you have a heavy customized CRM environment, you have to make sure you restore from backup or network location, all the images or ISV files associated with custom solutions. Environments which are configured to use Kerberos authentication also require extra IIS configuration in order to work correctly. Take note of all your manual added CRM Registry keys as this is also something you want to restore to the DR environment, e.g. DisableOutlookClient, this disables the CRM Outlook client button from the CRM interface, you may not want extra load of calls asking why the Outlook client is not working after users have installed it from the web interface.
The process is not as straight forward as you may have envisaged, the time needed to perform all configurations may not comply with the company RTO. Is important to mention that other components e.g. DNS, Database Backup method/Restore time, network load balancers etc... Have not been taken into consideration, if you have a low RTO is important you consider all components which CRM is dependent on. This method advantage does not force the use of specific servers, giving you the flexibility to use any server available in a DR scenario. The following is a resume of the steps:

1. Restore Databases
2. Configure servers with minimum pre-requisites (if not done already)
3. Database Connection String manual update
4. Run CRM setup wizard and join Application and Platform servers to the organisation
5. Manually configure extra IIS or other components
6. Restore any custom images or ISV solutions
7. Restore any CRM web.config configuration and Registry keys
8. Deployment manager EDIT Report Server

Restore Databases onto a stand-by environment
With this solution you configure a stand-by fully working CRM environment on your DR site. You can install a new CRM environment creating an organisation with the same name or join the servers to an existing restored database. Configure IIS, copy ISV and image files, restore Registry keys and reports, confirm all is working correctly, set up log shipping for the databases and you ready to go.
The main difference is that you need to allocate servers and resources permanently even though you are not using them. The benefit is a faster recovery method, with many of the configuration and installation tasks done. You still need to edit the SQL connection string as explained on the previous scenario because the databases still need to be restored from backup and again edit the report server configuration. The following is a resume of the steps:

1. Restore Databases
2. Database Connection String manual update
3. Deployment Manager EDIT Report Server

Conclusion
I hope this article has helped you in the design of your disaster recovery solution for CRM 4.0. For an advanced admin the two solutions described on this article are obvious and I believe the positive side to take from this article are the small details that can help towards understanding how CRM works and on what situations and configurations to consider in order to successfully design the appropriate disaster recovery solution.
For those with very very low RTO and RPO times, and a more automated solution is needed, please look at platespin or doubletake solutions, these are software that can make a copy of other servers in real time to a different location.