After migration from MS CRM 4.0 to 2011 I faced one weird related to displaying reports in MS CRM 2011. Getting this message while loading any of the report
"Reporting Error:
The report cannot be displayed."
Additionally, the following error message is logged in the Application event log in the Microsoft Dynamics CRM 5 server:
Exception type: CrmReportingException
Exception message: The item '/OrgName_MSCRM/2011/{GUID}' cannot be found. (rsItemNotFound)
To resolve this problem, publish all reports from the computer that is running Microsoft Dynamics CRM into the computer that is running Microsoft SQL Server Reporting Services. To do this, follow these steps:
1) Click Start, click Run, type cmd, and then click OK.
2) At a Command Prompt, change the directory to the following folder:
Drive:\Program Files\Microsoft Dynamics CRM\Tools
3) Type the following command:
publishreports.exe Orgname
Note The Orgname placeholder represents the name of your organization for which you want to publish reports.
4) Press Enter.
Saturday, May 28, 2011
Wednesday, October 1, 2008
Update Account Ownership
With help of this code snippet you can update Account ownership programatically.
TargetOwnedAccount target = new TargetOwnedAccount();
// Account Id for which you want to update ownership
target.EntityId = accountGuid;
systemuser objSystemUser = new systemuser();
// Set SystemUser which you want to set as a owner for account
objSystemUser = (systemuser)becSystemUser.BusinessEntities[0];
SecurityPrincipal assignee = new SecurityPrincipal();
assignee.Type = SecurityPrincipalType.User;
// Set fetched user id which we want to set as owner
assignee.PrincipalId = objSystemUser.systemuserid.Value;
AssignRequest asgRequest = new AssignRequest();
asgRequest.Assignee = assignee;
asgRequest.Target = target;
AssignResponse asgResponse = (AssignResponse)objCRMService.Execute(asgRequest);
TargetOwnedAccount target = new TargetOwnedAccount();
// Account Id for which you want to update ownership
target.EntityId = accountGuid;
systemuser objSystemUser = new systemuser();
// Set SystemUser which you want to set as a owner for account
objSystemUser = (systemuser)becSystemUser.BusinessEntities[0];
SecurityPrincipal assignee = new SecurityPrincipal();
assignee.Type = SecurityPrincipalType.User;
// Set fetched user id which we want to set as owner
assignee.PrincipalId = objSystemUser.systemuserid.Value;
AssignRequest asgRequest = new AssignRequest();
asgRequest.Assignee = assignee;
asgRequest.Target = target;
AssignResponse asgResponse = (AssignResponse)objCRMService.Execute(asgRequest);
Tuesday, September 30, 2008
Registering Plug-In
Plug-in Storage
Plug-ins can be deployed to the Microsoft Dynamics CRM server's database or the file system that is known as "on-disk". We strongly recommend that you deploy your plug-ins in the Microsoft Dynamics CRM database, instead of on-disk, as the primary way to deploy plug-ins for Microsoft Dynamics CRM. Plug-ins stored in the database are automatically distributed across multiple Microsoft Dynamics CRM servers in a datacenter cluster. On-disk deployment of plug-ins is supported for backward compatibility with Microsoft Dynamics CRM 3.0 callouts and also to support debugging of plug-ins by using Visual Studio 2005.
Deployment
When you deploy plug-ins from another computer to the Microsoft Dynamics CRM server disk (on-disk deployment), the plug-in assembly must be copied to the server before registration. The assembly must be deployed to the following folder. This is the same folder that is used for Microsoft Dynamics CRM 3.0 callout assemblies.
\Program Files\Microsoft CRM\server\bin\assembly
Plug-in registration should be done after the assembly has been copied to the \bin\assembly folder on the server to prevent the situation where a system user causes an event in Microsoft Dynamics CRM to be raised but the registered plug-in assembly does not yet exist on the server. For server database deployment, the plug-in assembly is automatically copied during plug-in registration so that the earlier situation is not an issue.
A plug-in can be composed of more than one assembly. Plug-ins can be a collection of files that includes other referenced assemblies and configuration files. Regardless of whether you deploy your plug-in to the database or disk, if your plug-in requires other assemblies to run, you must put copies of these assemblies in the Global Assembly Cache (GAC) on each server where the plug-in is to execute.
Before you unregister an asynchronous plug-in, stop the asynchronous service. Failure to do this can result in a situation where the plug-in has been queued to execute, but the plug-in assembly is no longer available.
Security Restrictions
There is a security restriction that enables only privileged users to register plug-ins. The system user account under which the plug-in is being registered must exist in the Deployment Administrators group of Deployment Manager. Only the System Administrator user account or any user account included in the Deployment Administrators group can run Deployment Manager.
Note Failure to include the registering user account in the Deployment Administrators group results in an exception being thrown during plug-in registration. The exception description states "Not have enough privilege to complete Create operation for an Sdk entity."
The system user account under which the plug-in is being registered must have the following organization wide security privileges:
1. prvCreatePluginAssembly
2. prvCreatePluginType
3. prvCreateSdkMessageProcessingStep
4. prvCreateSdkMessageProcessingStepImage
5. prvCreateSdkMessageProcessingStepSecureConfig
The System Administrator and System Customizer roles have these privileges.
Plug-ins can be deployed to the Microsoft Dynamics CRM server's database or the file system that is known as "on-disk". We strongly recommend that you deploy your plug-ins in the Microsoft Dynamics CRM database, instead of on-disk, as the primary way to deploy plug-ins for Microsoft Dynamics CRM. Plug-ins stored in the database are automatically distributed across multiple Microsoft Dynamics CRM servers in a datacenter cluster. On-disk deployment of plug-ins is supported for backward compatibility with Microsoft Dynamics CRM 3.0 callouts and also to support debugging of plug-ins by using Visual Studio 2005.
Deployment
When you deploy plug-ins from another computer to the Microsoft Dynamics CRM server disk (on-disk deployment), the plug-in assembly must be copied to the server before registration. The assembly must be deployed to the following folder. This is the same folder that is used for Microsoft Dynamics CRM 3.0 callout assemblies.
Plug-in registration should be done after the assembly has been copied to the \bin\assembly folder on the server to prevent the situation where a system user causes an event in Microsoft Dynamics CRM to be raised but the registered plug-in assembly does not yet exist on the server. For server database deployment, the plug-in assembly is automatically copied during plug-in registration so that the earlier situation is not an issue.
A plug-in can be composed of more than one assembly. Plug-ins can be a collection of files that includes other referenced assemblies and configuration files. Regardless of whether you deploy your plug-in to the database or disk, if your plug-in requires other assemblies to run, you must put copies of these assemblies in the Global Assembly Cache (GAC) on each server where the plug-in is to execute.
Before you unregister an asynchronous plug-in, stop the asynchronous service. Failure to do this can result in a situation where the plug-in has been queued to execute, but the plug-in assembly is no longer available.
Security Restrictions
There is a security restriction that enables only privileged users to register plug-ins. The system user account under which the plug-in is being registered must exist in the Deployment Administrators group of Deployment Manager. Only the System Administrator user account or any user account included in the Deployment Administrators group can run Deployment Manager.
Note Failure to include the registering user account in the Deployment Administrators group results in an exception being thrown during plug-in registration. The exception description states "Not have enough privilege to complete Create operation for an Sdk entity."
The system user account under which the plug-in is being registered must have the following organization wide security privileges:
1. prvCreatePluginAssembly
2. prvCreatePluginType
3. prvCreateSdkMessageProcessingStep
4. prvCreateSdkMessageProcessingStepImage
5. prvCreateSdkMessageProcessingStepSecureConfig
The System Administrator and System Customizer roles have these privileges.
The following restrictions apply when registering a plug-in assembly:
Subscribe to:
Posts (Atom)