Last time I tried to create a new systemuser, which is mananged in an other domain as the CRM system, I wasn’t able ton enter a backslash key in the domain name field.
After some investigation, it turned out that I was not able to enter \ in any field. I’ve reproduced this issue on multiple systems (On-Line and On-Premise) and multiple language packs.
With help of @nzregs I could verify that it is not a general problem. After comparing system parameters, I found out that I was able to enter a backslash with an different keyboard layout than ‚de-de‘. Therefore I opened a ticket with the CRM support which is currently under investigation. It looks like it is a bug in the default form scripts.
If you have to enter a backslash in the meantime and you are experiencing the described problem, you could either copy/paste it from anywhere or you could enter ALT + 92.
This issue was confirmed as a bug. The fix will be released with Rollup 7, which is currently scheduled for March 2012.
Recently I had a problem with a dev system at a customer site. The system was redeployed from the production site without any problems. Everything worked well, until I tried to customize the system. As soon as I tried to create new attributes or new relationships, the system produced an error
The language code 1033 is not a valid language for this organization
I searched the net, but the only things I found was that this error is listed as an error code of Dynamics CRM (see http://msdn.microsoft.com/en-us/library/bb930493(loband).aspx) and a thread in the Dynamics Forums (http://social.microsoft.com/Forums/en/crm/thread/70bbbf36-1ecb-443e-852a-bebaa70c7206), but sadly without a solution.
After contacting the Dynamics CRM support team, the cause of this error was found in a matter of minutes. The system was redeployed from an installation with German base language to a system with English base language. This is an unsupported scenario.
Neither there was a warning at the redeployment wizard, nor is this mentioned in the Implementation Guide (at least, I haven’t found it there). The support engineer provided me following excerpt there this scenario is described as unsupported
The original deployment and the new deployment of Microsoft Dynamics CRM must be the same base language.
NOTE: Redeployment between different base languages, for example from English to French, is not supported.
To bad that this snippet is only included in the course material for the Installation and Deployment exam and not in the Implementation Guide. The only solution was to do a full reinstall of Dynamics CRM with the same base language as the originating system and to do the reployment again.
In the meantime I got new feedback from the support engineer (thank you José) who is responsible for my case. Microsoft will document this scenario either with a knowledgebase article or by adding the quoted note to the Implementation Guide.
Today I had a service call with Microsoft CRM Support. After the import of an organization into a development system at a client, it stopped working. Trying to logon CRM via web client fails with error message:
System.InvalidOperationException: ExecuteNonQuery requires the command to have a transaction when the connection assigned to the command is in a pending local transaction. The Transaction property of the command has not been initialized.
The solution of this problem was quite simple (after the reason was found). The application pool of the system had insufficient rights for the organization database.
To get the system up and running again you have to
- Identify the identity of the application pool
- Ensure the app pool idenity has a sql user assigned for the organization database
- Grant the app pool identity the right db_owner on the organization database
- Restart IIS
Today I had a service call with a customer who got an error on creating appointments. The error message was General Failure in Scheduling Engine
A quick search in the internet revealed that this error message is not an unknown one (at least for Dynamics CRM 3)
Because the description of the articles were not suitable for the customers environment and the CRM system is a newer one ( Dynamics CRM 4), we had to dig further.
We enabled the tracing on the crm application server and set the TraceCategories to *:Error which writes only the message with TraceLevel Error to the trace file.
The generated trace file contained following error
Crm Exception: Message: SecLib::CrmCheckPrivilege failed. Returned hr = -2147220960 on UserId: bcf9bb2e-6070-de11-a4a6-000c29abeb6c and PrivilegeId: b5f2ee06-d359-4495-bbda-312aae1c6b1e, ErrorCode: -2147220960
MessageProcessor fail to process message 'Book' for 'appointment'.
A quick search for the name of the denied privilege showed that the security role of the user doesn’t give him the right to share appointments. Apparently, this right is needed for creating an appointment. After adjusting the security role the error was gone and the customer was happy.