Known issues when developing for MSCRM 4.0
-
Organization specific URL requests to CrmService.asmx are case-sensitive (32068)
- You must use all lowercase for mscrmservices in the following URL.
- http://ServerName/OrgName/mscrmservices/2007/CrmService.asmx
- PreReturnValue.Stop Callout in 3.0 does not show any error (22605)
-
Returning a Stop value from a Microsoft Dynamics CRM 3.0 callout has been deprecated and is made equivalent to returning an Abort value. Callouts returning a Stop value will result in an Abort. However, a standard error message will be displayed to the user instead of a custom message.
-
Offline plug-ins or offline SDK creating entities (10858)
-
Inside a plug-in, if an entity is created or updated, the action is recorded as offline user even though it is impersonated as SYSTEM.
- Offline plug-ins that create entities use the offline user's credentials, even if the plug-in specifies impersonation.
- Deletion of plug-ins (8574)
-
When an Asynchronous plug-in or Custom Workflow Activity is deleted, it is recommended that you stop and restart the Async Service so that entries in the Async queue are aware of the plug-in or custom workflow deletion.
-
Metadata API: Failure on update of system required attribute (32170)
-
When you try to update an attribute that is system required, an exception is thrown.
-
Workaround: Set the required level to NULL before calling update.
-
Metadata API: Unable to update the default value on the statuscode attribute (31251)
-
There is no method in the MetadataAPI that allows you to update the default value for a statuscode attribute.
-
Workaround: Use import or edit the value using the application user interface.
- Metadata API: GetValidReferencingEntities and GetValidReferencedEntities messages return results for entities that cannot be referenced from the task entity (32116)
-
The task entity cannot be a referenced or referencing entity in a custom relationship. However, the GetValidReferencing and GetValidReferenced messages return a list of possibile entities for a relationship.
-
Workaround: Use the CanBeReferenced or CanBeReferencing messages to determine if the task entity can participate in a relationship.
- Text attribute value cannot contain escape characters (2134)
-
When you create an entity instance such as an account, the name attribute value cannot contain escape characters. For example, if you create an account where the name is "Name_\r_123", after the create the actual name of the account will be "Name_\n_123".
-
Bulk Delete UI: Deleted records not shown in Bulk Record Deletion Grid (31741)
-
When executing the BulkDelete message, if the BulkDeleteRequest.RecurrenceStartTime property is set to "today", the Bulk Record Deletion grid will not show the correct number of deleted records and the number of failures for the bulk delete job.
- Lookup Type is not always populated (31612)
-
For the following attributes, the lookup type is not set when you retrieve an entity instance:
-
activitypointer.serviceid
annotation.objectid
appointment.serviceid
customeraddress.parentid
documentindex.documentid
fax.serviceid
incidentresolution.serviceid
letter.serviceid
listmember.entityid
opportunityclose.serviceid
orderclose.serviceid
phonecall.serviceid
queueitem.objectid
quoteclose.serviceid
site.createdby
site.modifiedby
task.serviceid
timezonelocalizedname.timezonedefinitionid
timezonerule.timezonedefinitionid - AssociateRequest message does not work for several relationships (28900)
-
The AssociateRequest message will fail for these relationships: systemuserroles_association and teammembership_association.
-
Workaround: Use the following specialized requests that are available for these relationships: AssignUserRolesRoleRequest and AddMembersTeamRequest.
- SPLA/IFD: Anonymous access for DiscoveryService in SPLA is not allowed on all methods (32683)
-
In some configurations, download of the WSDL will fail because anonymous access is not allowed.
-
Workaround: You can publish the Discovery service WSDL for partners/developers. You can use the static WSDL shipped with the SDK, located in the folder \SDK\WSDL.
MSCRM 4.0 Duplicate Detection Publishing Statuses
-
Unpublished: Rule has been created, but matchcodes have not yet been created.
-
Publishing: Matchcodes are in process of being created. Rule is not yet in effect. This step can take a while if you have many records.
-
Published: Matchcodes have been created for each record in the base and matching record type for the rule. Records created or updated after the rule is published will be checked against existing records.
MSCRM Requirements - Server
Note: This is compiled from a x86 install. The x64 install mileage may vary.
The file locations are relative to the setupserver.exe.
-
Microsoft .NET Framework
-
Download From: http://go.microsoft.com/fwlink/?LinkId=91338&clcid=1033
-
Location: DOTNETFX\dotnetfx3.exe
-
Microsoft Visual C++ Runtime
-
Download From: http://go.microsoft.com/fwlink/?LinkId=91355&clcid=1033
-
Location: VcRedist\vcredist_x86.exe
-
SQL Reporting Service Report Viewer Control
-
Download From: http://go.microsoft.com/fwlink/?LinkId=91351&clcid=1033
-
Location: ReportViewer\ReportViewer.exe
Note you find this information in the crm40srvsetup.log file in <system drive>:\Documents and Settings\<username>\Application Data\Microsoft\MSCRM\Logs
Trend Micro OfficeScan Password when Uninstall - How to Bypass
First off I would not have figured this out if it wasn't for a similar post about bypassing the protection on the server available at http://www.sbsfaq.com/Lists/FAQs/DispForm.aspx?ID=23
The differences on the client side (compared with article above) start with the location of the file it's in C:\Program Files\Trend Micro\OfficeScan Client. Next the keys are a little different, first you need to find the [INI_CLIENT_SECTION] and in that file, change the following keys:
- Client_Allow_Uninstall to 1
- Client_Allow_Unload to 1
- Uninstall_Pwd to 70
- Unload_Protect to 0
- RemoveCTA to 1
Windows Complete Backup - Report from the trenches
The VHD was created in an acceptable time and I moved to the new machine and popped the Vista disk in and started the restore. That was quick. However when I tried to boot it blue screened. So I popped the Vista disk back in and tried to use the startup repair tool, it said ti found a problem but couldn't repair it

Looking around this morning it seems there are some issues in it
- http://techrepublic.com.com/5208-10877-0.html?forumID=102&threadID=210131&messageID=2163410 (some minor things to be aware of)
- http://professionalinsight.net/VistaBackup.aspx (didn't have this issue and the drives were very different)
How to set all your users to use the same email handling methods
- Step 1: Create a new blank workflow and set the entity to system user (despite my picture). http://www.sadev.co.za/files/user1.png
- Step 2: Turn off the automatic options (well maybe, you may want this to run on create so future users also are set right). Click "On Demand" under available to run. Add a step to update the user. http://www.sadev.co.za/files/user2.png
- Step 3: Click the set properties and update the "Email Access Configuration" to your preferred method. http://www.sadev.co.za/files/user3.png
- Step 4: Save your work flow and now click the "Run Workflow" button on the user list and select your workflow and click OK. http://www.sadev.co.za/files/user4.png
MSCRM Email Router: Incoming Status: Failure - The remote server returned an error: (403) Forbidden.
This is actually caused by a bad UI (IMHO) which kinda gets you to configure it wrong. What has happened is that the outgoing has a tick box saying to use SSL and asks for a server name, while the incoming asks for a URL. It automatically puts in http:// so naturally you fill in your server, i.e. http://myexchange
However Exchange runs on SSL so it actually needs to be https://myexchange
If that doesn't help then open up the URL you are putting in, in a web browser and see if it works. You'll get a lot more information on the real cause.
Find your MSCRM License Key
In MSCRM 3.0 I did a few redeployments of MSCRM and what was nice was in the database was the license table which contained the key. This was great since most of the time the customer couldn't find the original media a year down the line.
Well for MSCRM 4.0 the license table is gone, but fear not you can still get the key. If you have the media the key is in a file called license.txt (atleast according to the implementation guide). If you got the download version there is no such file but you can still get it from the MSCRM_CONFIG database in the ConfigSettings table.
Essential Developer Tools - Part 4: Static Analysis Tool
I'm a knitting term?!
