Not have enough privilege to complete Create operation for an Sdk entity.

Submitted by Robert MacLean on Mon, 01/21/2008 - 15:31
The following error message is likely the least thought out requirement of MSCRM 4.0 and a common cause of frustration for developers in enterprise customers who are using the multi-tenancy features.
 0x80040256
 Not have enough privilege to complete Create operation for an Sdk entity.
 Platform

You get this error during an attempt to register a workflow activity or plug-in into MSCRM 4.0, and you may think that to do this customisation you need atleast the System Customizer role. Well you are wrong, you need higher than that. In fact the highest role for an organisation (System Administrator) isn't even enough. You need to be Deployment Administrator. This role is assigned on a server level, in the Deployment Manager tool and gives that user full powers on all organisations!
The reason I think this is badly thought out, is three fold. Firstly, I do not want to enable developers to see certain things in MSCRM in live enviroments (thus the great System Customizer role) but I want them to do the customisations. The second is if I have a developer working in a certain division or group company with it's own MSCRM organisation, I really don't want to let that developer loose on other organisations on the server (security and stability reasons). Lastly I don't want to have to give access to the server to more people than absolutely needed, and as I now need to be able to set people up to be Deployment Administrators from time to time it means extending that group of people. Anyway heres hoping MSCRM 5.0 will fix it ;)

How to debug workflow assemblies and plug-ins in MSCRM 4.0

Submitted by Robert MacLean on Wed, 01/16/2008 - 15:19

Remote debugging sounds like the title to a book but it isn't - in truth, I have never used remote debugging because haven't needed to. In MSCRM 3.0 the exceptions bubbled up nicely in workflow and I could do a lot on my own machine. However in MSCRM 4.0, those exceptions don't bubble up nicely :( All you get is something like this:

Beside's adding logging to your assembly (which you should do anyway), what's a dev to do now? You can now debug your plug-in's and custom workflow activities using the remote debugging facility in Visual Studio and that's what I hope to show in the next 9 easy steps!

  1. On your machine you'll find a folder <system drive>\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger (assuming you installed Visual Studio 2008 to the default location) which contains an x86 folder. Copy that to the MSCRM server and run the msvsmon.exe file.
  2. Now click Tools -> Permissions and give yourself access to it.
  3. Now load you plug-in or custom workflow activity (when I refer to plug-in for the rest of the document it means both, unless otherwise stated) using the *cough*annoying*cough* plug-in registration/developer tool.
  4. Next copy the PDB file for your assembly to the <system drive>\Program Files\Microsoft Dynamics CRM\Server\bin\assembly (assuming you installed MSCRM 4.0 to the default location).
  5. Now to finish up the MSCRM server side do an IISReset and restart the Async Windows Service.
  6. Back on your machine now in Visual Studio, set a break point in your code.
  7. Next click Debug -> Attach to Process. The transport should be Default and the Qualifier should be <domain>\<username running msvsmon.exe on the server>@<Server name>. Note: You can get this from the Tools -> Options in msvsmon.exe. You may need to do some firewall configuration but it should be automated.
  8. Next select the process to attach to, for an online plug-in, attach the debugger to the w3wp.exe process on the Microsoft Dynamics CRM server. For an offline plug-in, attach the debugger to the Microsoft.Crm.Application.Hoster.exe process. For asynchronous registered plug-ins or custom workflow activity attach to the CrmAsyncService.exe process.
  9. Now do whatever is needed to trigger your event and watch Visual Studio on your machine do it's magic!

MSCRM 4.0 Workflow Configuration Tool for Visual Studio 2008

Submitted by Robert MacLean on Tue, 01/15/2008 - 09:55
The workflow configuration tool is a great tool in the SDK which you build. It creates a couple of assemblies and and nice installer. You then run that and it puts the add-in into visual studio 2005, which I don't use anymore :( So I have updated it for Visual Studio 2008: The changes to do it were:
  • Add the missing sdk proxy assembly to the files for the installer.
  • Set the directory for the templates to the Visual Studio 2008 one.
  • Changed the version of the assembly from 8.0 to 9.0 in the CRMWorkflowAddin.AddIn file.
  • Change the title to show it is specially for Visual Studio 2008
  • Changed the product ID so that it is not confused with the semi-offical one in the SDK.

You can download the actual installer files here and the updated deployment project file (in case you want to check) here.

Note: This is based on the first public release of the Microsoft CRM 4.0 SDK. If newer versions come out, you maybe better off using those versions. I'll (try) keep this one up to date.

Update 16 Jan 2008: This tool doesn't add the MSCRM workflow actvities which are available. To add those to the tool box see this post.

MSCRM 4.0 Development - Stupid Tips

Submitted by Robert MacLean on Tue, 01/15/2008 - 08:52
It seems that my stupid tips is catching on, however I did not expect this level of duh from the official MSCRM blog itself. The post states that you can use .Net 3.5 for development as it uses the same CLR as .Net 3.0 (which MSCRM 4.0 is based), however they don't recommend it because it could break if .Net 3.5 isn't installed. Duh! Does that mean that I should not use .Net 3.5 at for any dev since I can't guarantee that it will ever be available on a machine?! How about not using Windows cause I might write code and then there is a Linux box that exists. *sigh*
They should have said if you write code in .Net 3.5 and it breaks because it's not installed and you can't figure it out, then you need to stop writing code and become a chef or something and leave the dev to the people with at least a double digit IQ.

MSCRM 4.0 Deployment Manager - Stupid tips

Submitted by Robert MacLean on Mon, 01/14/2008 - 19:35

Two stupid tips when using it (it's duh if you think about it, but anyway I did it):

  • Don't try to create a new organisation when installing Windows updates, especially if there is a SQL update in there which stops the SQL server.
  • Don't run multiple copies of the deployment manager to create multiple organisations at the same time.

If I do anything else duh with the deployment manager I'll be sure to let you know.

Known issues when developing for MSCRM 4.0

Submitted by Robert MacLean on Mon, 01/14/2008 - 10:37
If you get the MSCRM 4.0 SDK there is a little html file called sdkreadme.htm, which you would assume (incorrectly) is about the SDK itself and not the development side. Well in there is a number of issues that can occur. So in the interest of helping someone out who is searching for this particular issue on the net (instead of reading the manual, like we ever do that) here are the issues (related to development only. There is some samples stuff which I have removed):
  • Organization specific URL requests to CrmService.asmx are case-sensitive (32068)
  • 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

Submitted by Robert MacLean on Mon, 01/14/2008 - 08:23
I recently was looking for some concrete information on the various status meanings in MSCRM 4.0 for the duplicate rules publishing. Checking the help didn't help, so I used the feedback option on it to say so. This morning I got a response answering the exact question. Anyway for anyone else looking for this information here it is (not like you couldn't guess, but better to be safe than sorry):
  • 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

Submitted by Robert MacLean on Thu, 01/10/2008 - 08:35
If you downloaded MSCRM and you do the server install you are likely presented with a lovely missing requirements screen like the one below, which you then need to download the requirements and install. Besides the waste of time and bandwidth, there are occasions where this isn't possible so this is how you can download the files yourself (using your favorite download manager for added speed) and put them in the install location so the installer finds them. It also helps with the fact that no matter if the Visual C++ runtime is installed it wants to download and install it each time.

Note: This is compiled from a x86 install. The x64 install mileage may vary.
The file locations are relative to the setupserver.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

Submitted by Robert MacLean on Wed, 01/09/2008 - 20:41
This is a great proof of how NOT to protect software. When you try to uninstall it can ask for a password configured by the network admin, but what it the server admin, servers or entire infrastructure is gone basically giving you no chance of getting the password back. Well facing that scenario myself, I hacked around and found a work around.
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
Save the ini file and launch the uninstall. Now enter 1 as the password and viola it's gone! From a development point of view this is an example of how not to use encryption. The machine encryption in the patterns&practises Enterprise Library is a much better place to start, and in addition you should also look into using hash to sign files like this, so that tampering with them, invalidates them and requires an update from the server.

Windows Complete Backup - Report from the trenches

Submitted by Robert MacLean on Wed, 01/09/2008 - 07:35
Vista has a great feature called complete backup with makes a VHD of your hard drive (more details see channel 9: http://channel9.msdn.com/Showpost.aspx?postid=229767), or so I'm told. Yesterday was the first chance I got to sit down and use it, and I'm not over the moon by it. I used an external SATA drive (connects via USB) to store the backup and that was fine. It didn't run the first time cause the laptop was on battery mode (probably a good thing that it warned me).
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 itCry. So in the end I installed Vista over the restored version, which has it's plus in that it meant any files out side of the My documents of the user also got copied across but meant cleanup of the Windows.Old folder.
Looking around this morning it seems there are some issues in it To be fair thought some people have good luck with it, like this guy: http://coolthingoftheday.blogspot.com/2007/11/vista-complete-pc-backup-it-winner-in.html