Recentelijk heb ik voor een aantal installaties de kans gehad om me eens wat verder te verdiepen in het installeren van CRM 2011 met behulp van een config file. Omdat de organisaties niet zomaar een OU open konden/wilden stellen waarbinnen de groepen was ik genoodzaakt om CRM te installeren met behulp van voorgedefiniëerde security groups. De enige manier om dit aan te geven tijdens de installatie is met een config file. Inmiddels heb ik met behulp van documentatie en een aantal andere sites een checklist opgesteld en ik merk dat deze manier van installeren voor mij de nieuwe standaard is.

Voor de installatie is het zaak om de security groups en service accounts goed te definiëren. Steeds vaker ontbreekt het mij (gelukkig) aan de rechten om dit zelf te mogen doen en/of zijn er bepaalde naming conventions en geldende principes waaraan deze zaken moeten voldoen. Hierdoor ben ik steeds vaker genoodzaakt om vooraf een “wensenlijstje” aan te leveren met zaken die van tevoren geregeld moeten worden. Uiteraard gelden hier ook hard- en software requirements, echter zijn deze dermate goed beschreven en zo gemakkelijk te vinden dat ik die niet zal herhalen.

Mijn standaard lijstje is als volgt:

Services and CRMAppPool IIS application pool identity permissions

4 Service Accounts need to be created:

Microsoft Dynamics CRM Sandbox Processing Service

The following permissions must be set for this account:

• Domain User membership on the domain in which CRM will be installed
• Granted the Logon as service permission in the Local Security Policy on the server which will act as CRM Server
• Folder read and write permission on the \Trace folder, which will be by default located under \Program Files\Microsoft Dynamics CRM\Trace and user account %AppData% folders on the server which will act as CRM Server
• Read permission to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM subkey in the Windows Registry on the server which will act as CRM Server

Microsoft Dynamics CRM Asynchronous Processing Service and Microsoft Dynamics CRM Asynchronous Processing Service (maintenance) services

The following permissions must be set for this account:

• Domain User membership on the domain in which CRM will be installed
• Member of the Active Directory Performance Log Users group.
• The Logon as service permission in the Local Security Policy on the server which will act as CRM Server
• Folder read and write permission on the \Trace folder, which will be by default located under \Program Files\Microsoft Dynamics CRM\Trace and user account %AppData% folders on the server which will act as CRM Server
• Read and write permission to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM and HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\MSCRMSandboxService subkeys in the Windows Registry on the server which will act as CRM Server

Deployment Web Service (CRMDeploymentServiceAppPool Application Pool identity)

The following permissions must be set for this account:

• Domain User membership on the domain in which CRM will be installed
• The Logon as service permission in the Local Security Policy on the server which will act as CRM Server
• Local administrator group membership on the server which will act as CRM Server
• Local administrator group membership on the server which will act as SQL Server for the CRM deployment
• Sysadmin permission on the  instance of SQL Server which will act as SQL Server for the CRM deployment to be used for the configuration and organization databases.
• Folder read and write permission on the \Trace folder, which will be by default located under \Program Files\Microsoft Dynamics CRM\Trace and user account %AppData% folders on the server which will act as CRM Server
• Read and write permission to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM and HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\MSCRMSandboxService subkeys in the Windows Registry on the server which will act as CRM Server
• CRM_WPG group membership on the server which will act as CRM Server. This group is used for IIS worker processes. The group is created and the membership is added during Microsoft Dynamics CRM Server Setup.

Application Service (CRMAppPool IIS Application Pool identity)

The following permissions must be set for this account:

• Member of the Active Directory Domain Users group on the domain in which CRM will be installed
• Member of the Active Directory Performance Log Users group
• Local administrator group membership on the server which will act as CRM Server
• Local administrator group membership on the server which will act as SQL Server for the CRM deployment
• Folder read and write permission on the \Trace and CRMWeb folders, which will be by default located under \Program Files\Microsoft Dynamics CRM and user account %AppData% folders on the server which will act as CRM Server
• Read and write permission to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM and HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\MSCRMSandboxService subkeys in the Windows Registry on the server which will act as CRM Server
• CRM_WPG group membership on the server which will act as CRM Server. This group is used for IIS worker processes. The group is created and the membership is added during Microsoft Dynamics CRM Server Setup.

Active Directory security groups

5 AD Security Groups need to be created in the domain in which CRM Will be installed. The “Group Scope” should be set to “Domain Local”.

• PrivUserGroup
• PrivReportingGroup
• ReportingGroup
• SQLAccessGroup

For each of these 4 groups add the following permissions for the user account which will perform the installation and to the security groups that are created:

• Permissions
• Read
• Write
• Add/Remove self as member
• Advanced permissions
• List Contents
• Read All Properties
• Write All Properties
• Read Permissions
• Modify Permissions
• All Validated Writes
• Add/Remove self as member

Dit lijstje is gebaseerd op de minimale rechten welke nodig zijn om CRM 2011 te installeren en gaat uit van een windows 2003 of hoger domein omgeving. Dit biedt de betreffende afdeling(en) alle info welke nodig is om de groepen en accounts aan te maken. Hoe en waar ze dit doen en wat de namen worden zijn vrij in te vullen.
Helaas is het nog te vaak noodzakelijk om alles door te lopen, aangezien de installatielogs van CRM 2011 niet uitblinken in duidelijkheid waarom iets niet door de controle komt.

Nadat deze zaken geregeld zijn vul ik op basis van de teruggekoppelde gegevens een config xml. Een voorbeeld ervan vind je hier.
Bijkomend voordeel van een dergelijk bestand is dat je de gegevens niet steeds opnieuw in hoeft te vullen als de installatie niet in een keer slaagt. Daarnaast wordt ook de beschrijving van de installatie zoals uitgevoerd een stuk eenvoudiger
Alle beschrijvingen van de elementen in de config file zijn terug te vinden in de helpfile van de implementation guide.

Vervolgens zorg ik er altijd voor dat IIS vantevoren is geïnstalleerd op de CRM server en dat de standaardsite is verwijderd. Dit is om problemen met de CRM website op poort 80 te voorkomen (bij het overschrijven van deze standaardsite komen de nodige warnings).
Vervolgens is het een kwestie van de software downloaden, de config xml op een locatie op de server zetten en het magische commando geven.

“SetupServer.exe /config c:\installconfig.xml”

En de installatie zou letterlijk een kwestie van next-next-finish moeten zijn

Een tijd geleden hebben we voor een implementatie een integratie met WSS 3.0 gemaakt. Dit betrof destijds een machine waarop CRM en Sharepoint naast elkaar geïnstalleerd waren. Recentelijk waren er wat aanpassingen nodig aan deze integratie. Onze ontwikkelomgeving is in de tussentijd aangepast waardoor CRM en Sharepoint op verschillende machines geïnstalleerd zijn.

De plugin die de communicatie naar Sharepoint verzorgde werd hier niet blij van. Bij het triggeren van de plugin ontstond de volgende error:

Web Service Plug-in failed in OrganizationId: 44e86ab7-a9f8-df11-b2d4-005056933f09; SdkMessageProcessingStepId: 524bd026-5ef9-df11-b2d4-005056933f09; EntityName: account; Stage: 50; MessageName: Create; AssemblyName: AccountPlugin.AccountPlugin, Account, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0b2a6fda89de94da; ClassName: AccountPlugin.AccountPlugin; Exception: Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly ‘Microsoft.SharePoint.Library, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ or one of its dependencies. The system cannot find the file specified.

Het plaatsen van deze dll in de GAC (wat overigens nog een avontuur op zich is in Windows Server 2008 R2) bood niet de gehoopte oplossing. Het samenvoegen van de Sharepoint en de plugin assemblies met behulp van ilmerge bleek onmogelijk. Ook de plugin op disk registreren met de Sharepoint assembly in de folder erbij had geen effect.

Zoeken op internet naar het probleem in de context van CRM leverde weinig op. Na een zoekopdracht met wat bredere parameters kwam ik in dit topic terecht die mij de verklaring gaf waarom dit niet werkt en ook nooit zal werken op een multi server deployment:

For everybody in this thread: you can only use the object model of SharePoint (available in the assembly Microsoft.SharePoint.dll etc) in an application if that application is executed on a SharePoint server! So if you create an application that has a reference to Microsoft.SharePoint.dll, it can’t be executed on a machine that’s NOT running SharePoint. Copying the DLL(s) from the SharePoint server to the other machine will NOT help. 

If you have the requirement to build an application that communicates with SharePoint and that will not be executed on the server itself, you must use the web services of SharePoint.

Op zich een vrij helder verhaal. De uiteindelijke oplossing is het vervangen van de assembly door de webservice en de bijbehorende wijzigingen in de code. Voortaan alleen nog data aan sharepoint toevoegen via de webservice dus om de schaalbaarheid van CRM niet in het geding te laten komen

Vandaag was ik aan de slag met de welbekende Periodic Workflow Tool. Ik wilde een aantal workflows draaien over een vers geïmporteerde set van records (zo’n 26.000 stuks). Dit leek op zich allemaal goed te gaan, maar later bleek dat de workflow niet over alle records gelopen had…
Al snel bleek dat het alleen voor de eerste 5.000 records in de betreffende view wel goed gegaan was, daarna hield het op.

De sourcecode van de Periodic Workflow Tool bevatte geen verwijzing naar een limit van 5.000 dus ging ik verder op zoek. Uiteindelijk kwam ik op dit artikel van Microsoft uit. Hierin wordt uitgelegd dat de FetchXml met paging werkt en dat je die kunt aanpassen.

De voor mij winnende combinatie:

1. Click Start, click Run, type regedit in the Open box, and then click OK.
2. Locate and then select the following registry subkey:
   HKEY_LOCAL_MACHINE\Software\Microsoft\MSCRM
3. On the Edit menu, point to New, and then click DWORD Value.
4. Type TurnOffFetchThrottling, and then press ENTER.
5. Right-click TurnOffFetchThrottling, and then click Modify.
6. Type a number other than 0 in the Value data box, and then click OK.

   Note Step 6 lets you retrieve the number of records specified in the Count attribute of your fetch statement.

7. On the File menu, click Exit.

Een verrasing uit de Reporting Service 2008 doos. Een configuratie die ik vandaag heb aangepast waarbij de reporting server service verplaatst is naar dezelfde server als CRM, echter wilde het draaien van rapporten niet lukken. Het aanmaken van een nieuwe organisatie leverde de volgende foutmelding op:

Aanvullend stond in het logfile de volgende melding:

12:56:53|   Info| Create Organization Reports…
12:56:53|  Error| Create new Organization (Name=dummy, Id=fa5556d7-aee5-df11-9c34-005056933f09) failed with Exception:
System.ArgumentException: The specified path is not a metabase path.

Na wat googlen vond ik deze site. De uiteindelijke oplossing was dan ook deze:

This issue occurs when the path of Reporting Services does not exist on the server.

To work around this issue, create a Web site that runs on the same port and the same URL that the Reporting Services server is using. In SQL Server 2008 Reporting Services, IIS is not used for accessing reports. However, if Microsoft Dynamics CRM 4.0 is installed on the same server, Microsoft Dynamics CRM 4.0 must find a Web site that has the same URL to bypass the error. To verify the URL of Reporting Services, follow these steps:

1.     Click Start, click All Programs, click Microsoft SQL Server 2008, click Configuration Tools, and then click Reporting Services Configuration Manager.

2.     Click connect to connect to your report server instance.

3.     Click the Web service URL, and see what the report server Web service URL is. For example, the URL may be http://SQLServername:8181/ReportServer.

In Windows Server 2008, follow these steps:

1.     Click Start, click Run, and then type inetmgr.

2.     Expand the server name, right-click Sites, and then click Add Website.

3.     Enter a name for the site, and then select a physical path.

4.     Enter the port number of the report server Web service. For example, enter 8181.

5.     Click OK.

In Windows Server 2003, follow these steps:

1.     Click Start, click Run, and then type inetmgr.

2.     Expand the server name, right-click Web Sites, click New, and then click Web Site.

3.     Enter a description for the site, and then click Next.

4.     Enter the port number of the report server Web service. For example, enter 8181, and then click Next.

5.     Enter a path for the Web site, and then click Next.

6.     On the Permissions page, click Next.

7.     Click Finish.

Sinds CRM 4.0 zijn er N-N relaties beschikbaar. Een handige feature, want in 3.0 moest dit nog met een “koppelentiteit” opgelost worden. Deze werd dan voorzien van een 1-N en N-1 relatie, maar je had altijd nog die vervelende koppelentiteit.

Er zijn echter situaties te bedenken waar deze ouderwetse manier van N-N relaties maken nog heel erg handig kan zijn. Bijvoorbeeld als je een kenmerk aan de N-N relatie mee wil geven. Wanneer je een N-N relatie maakt zoals dat in 4.0 mogelijk is (wat overigens onder water ook gewoon met een koppeltabel werkt), is het niet mogelijk om daar nog een of meerdere aanvullende attributen aan toe te voegen. Met de 1-N N-1 oplossing kun je meerdere attributen opnemen om de relatie tussen de twee betreffende records verder te specificeren

N-N relatie via koppeltabel vs direct

Vandaag kwam ik een probleem tegen die ik nota bene zelf gecreeerd heb. Op een formulier heb ik een aantal velden gekenmerkt met ForceSubmit = true. Dit omdat er met javascript een aantal inactieve velden voorzien worden van een (aangepaste) waarde.

Wanneer je de velden met een ForceSubmit echter niet aanraakt in een bulk edit form worden de waardes die op dat moment in die velden staan toch weggeschreven in de database. Dit komt neer op het leegmaken van de betreffende velden (zelfs al zijn ze gedisabled). Een situatie die absoluut onwenselijk is!

Gelukkig is de oplossing vrij simpel. De ForceSubmits moeten uitgesloten worden voor het bulk edit formulier.

if (crmForm.FormType != 6)
{
    crmForm.all.new_veld.ForceSubmit = true;
}

Regelmatig maken we gebruik van één of meerdere tabelletjes in CRM waarin parameters opgeslagen worden voor gebruik binnen CRM of in maatwerk gerelateerd aan CRM.

Ik heb hiervoor een dedicated entiteit gemaakt genaamd “Parameter” en deze is voor iedereen beschikbaar!

Vandaag kreeg ik tijdens het uitrollen van een custom webservice de volgende meldingen

Error 1 Server was unable to process request. —> Unable to generate a temporary class (result=1).
error CS2001: Source file ‘C:\WINDOWS\TEMP\9a1mhqzb.0.cs’ could not be found
error CS2008: No inputs specified

Wanneer er gewenst is dat de items in de linkernavigatie van een formulier aangepast worden kun je daar met google best een leuk scriptje voor vinden waarmee je bijvoorbeeld de naam van zo’n item overschrijft. Het probleem hiermee is echter dat zo gauw je een andere taal selecteert of de naam van de entiteit aanpast dit niet meer werkt.

Een recente vraag die bij ons kwam was het aantal gerelateerde records in de linkernavigatie van een formulier te tonen. Uiteraard was dit op een meertalig systeem. Er waren al de nodige plugins geschreven die het aantal gerelateerde records wegschreef in een attribuut op de contact entiteit. De javascript zorgt voor de toevoeging in de linkernavigatie.

De code is als volgt:

// Rename Left Nav Display links
function leftNavRename(leftNav, amount)
{
if (amount == null){amount = 0;}
var navItem = document.getElementById(leftNav);
if(navItem != null)
{
var length = navItem.innerHTML.length;
var nobrstart = navItem.innerHTML.indexOf(“</NOBR”);
var startString = navItem.innerHTML.substring(0, nobrstart );
var endString = navItem.innerHTML.substring(nobrstart , length);

navItem.innerHTML = startString + ” (” + amount + “)” + endString;
}
}
leftNavRename(‘navActivities’, crmForm.all.new_numberofactivities.DataValue);
leftNavRename(‘navActivityHistory’, crmForm.all.new_numberofhistory.DataValue);

En het resultaat is een getal tussen haakjes achter de link naar de gerelateerde records, volledig multilingual-proof!

Gratis? Jazeker!!

Achter deze link vind je een aantal kleine maar hele praktische tools voor Microsoft Dynamics CRM.
Deze website is opgezet door Tanguy Touzard welke tevens de eigenaar is van deze blog. Hij haalt zijn voldoening blijkbaar uit het gebruik van zijn tools door anderen.

Deze tools gaan mijn leven op sommige vlakken een stuk eenvoudiger maken en dus hulde aan de maker!