• Virus Scanner (taking this off makes the disk access much faster and frees up almost 30MBs of RAM)
• Distributed File System Service (5MBs of RAM)
• File Replication Services (1.3MBs of RAM)
• SQL 2005 OLAP Services (22MBs of RAM)
• SharePoint (58MBs of RAM) - Unless you need to demo it
• A bunch of other random Windows Services (5MBs of RAM)

The error seems to be some form of timing issue.  If you wait for the "Customize Entities" page to fully load and then give it a second... the Entity Editor loads perfectly every time.  If however, you try to load an entity before the page is 100% done loading, you will get this error.  A quick look into the cause, shows that the URL that loads is different depending on whether or not you wait for the page to finish:

URL if you don't wait - This gives an error
http://crm/userdefined/edit.aspx?id=custom:{b5f1e023-4be4-48ba-a424-94f17e4be732}&etc=10003

URL if you wait - This one works
http://crm/Tools/SystemCustomization/Entities/manageEntity.aspx?entityId={b5f1e023-4be4-48ba-a424-94f17e4be732}

The work around is simple: Wait for the "Customize Entities" page to load and try loading the "Entity Editor" again.

• UploadFromBase64DataAnnotationRequest
• UploadFromBase64DataActivityMimeAttachmentRequest
• UploadFromBase64DataSalesLiteratureItemRequest

Unfortunately, there is a bug in this code (highlighted in RED).  The problem is that if you try to upload binary data the method by which the data is read from the file system and encode is in adequate.  Using the above code will result in files that only contain a portion of the binary file that intended to attach.  I am partly to blame for this (as I helped write this sample) and the above sample works great if you are uploading plain text (as our unit tests proved ).  However, if you want to upload binary data... you will need to do two things.  First you need to be sure to set the MimeType properly (this should be obvious and is not a bug in the sample).  Second you need to use the following code to read-in and encode the binary data:

Image:

Text:

As a developer working on the Microsoft CRM application team, we simply got use to it and got into the habit of simply hitting "continue" (instead of break) whenever the platform threw this "bogus" exception.  I know the platform team did some research (and I am fuzzy on the details) but it turns out that this is actually a problem with the .NET Framework and the team made the call to not try to fix/workaround the issue (given the risk, the scope of the fix, the ship date, etc.) As a note, I completely trust that decision and you should too .

http://www.microsoft.com/downloads/details.aspx?FamilyID=172861ae-d02e-4441-b432-26e88dd0ab14&DisplayLang=en

It is pretty safe to assume that this will be the last rollup for CRM v1.2 for a while and I would generally recommend it for all existing CRM v1.2 installs.

You can read about all the fixes in this release here:

http://support.microsoft.com/default.aspx?kbid=904435

This is sort of a non-event... but I think it is pretty cool that Microsoft CRM 3.0 seems to work perfectly under Internet Explorer 7.0 Beta 1 (7.5112.0).  I know the team did a bit of testing for IE7 compatibility during the final months before shipping and it appears that this worked paid off.
 
There are no guarantees that CRM 3 will continue to work with IE7 as the IE7 code base is ever changing... but the good news is that the CRM SE Team has a head start on compatibility and I would bet future fix requirements will be relatively minor.  If I had to take a guess, I would expect some form of Service Pack or Roll-up late next year to fix any issues that IE7 causes.

http://www.msreadiness.com/wscart.asp?eid=3457

Estimated Retail Pricing (US Only):

These prices are estimates only and vary based on your MSFT licensing program, geography, Software Assurance terms and other factors. You can get exact pricing through a CRM partner like Invoke Systems.

The time may come when you want to "purge" your CRM database.  Generally, you would want to do this on a test environment that you use repeatedly (like when you are testing a data migration) or perhaps in a client environment after you entered a bunch of test data prior to "going live".  When this happens, you have several options.  First, you can restore a previous database, second, you can reinstall CRM, third, you can try to use CRM to delete all the records (not always possible and certainly time consuming).  The fourth option of course, is to run the handy SQL script below. 

Before we get to the script, we have to get the formalities out of the way:

This script is provided "AS IS" with no warranties expressed or implied and no rights conferred.  By downloading and executing this script you agree to do so "at your own risk", you also understand that the use of this script is completely unsupported by Microsoft Corporation and Invoke Systems.  A final bit of caution, this script was original intended for test and demo environments; it is NOT recommended for production servers.

Now that we have that out of the way, let us move on to the script.  The "magic" of this script is knowing what to do delete, what not to delete and the order in which to perform the delete.  Generally speaking, we stayed away from anything "security related" (Business Units, Users, Roles and Teams), this is for safety and to prevent the 1001 bugs that would probably occur from such a brute-force assault on the CRM security model.  (Perhaps a future script will dare to venture down that path)  Additionally, this script avoids most "system level objects" including Templates and Views.

• Your callout is not firing for non-admin users.  Check the event log, the user trying to start the component may not have permissions to do so.  Check the "Identity" under which the component should run.
  
  
• Callouts do not fire when the administrator is not logged into the server.  This is probably because you have the components "identity" set to "Interactive User" (which means the user currently logged into the machine).  Configure the component to have an identity of "This User" and set the user to a known and privileged CRM user.
  
  
• You are trying to update the record that fired the update or create event in the first place.  If you must do this be aware of the following things:
  
  
• For some record types, SQL server maintains a lock on the entities table while the callout is firing.  This means that you cannot update the record synchronously.
  
  
• It is bad practice to make use of threading inside of your callout.
  
  
• To work around these problems, it is generally best practice to write events to a Microsoft Message Queue (MSMQ) and later have a service retrieve and process these messages.  This allows your callouts to return quickly and perform the update asynchronously later on.
  
  
• Be very aware of update loops!  For example, if your callout listens to the update event of an Account, and your code updates a field on that account, another update event will fire!  Your code must be "smart" enough to know which update events were triggered by your code and which were not.  Otherwise you will end up in a loop of updates that trigger updates which trigger updates (etc.)
  
  
• Use the debugger!  If you are attempting to troubleshoot your callout DLL, be user to make use of the debugger!  If you are unable to install Visual Studio in the environment, use the GUI Debugger that ships free in the .NET Framework SDK.

Troubleshooting Workflow:

The following diagram attempts to walk you through the process of troubleshooting your callout.  The workflow works by the process of elimination.  If you can rule out what isn't the problem, the root of your problem generally becomes obvious.



Click the image above for a readable version

Helpful URLs:

Michaeljon Miller's - Callouts are just plain hard to write
http://blogs.msdn.com/mikemill/archive/2004/12/09/279021.aspx

Business Logic Extensions to Microsoft CRM 1.2: Post-Callouts
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmbscrm1_2/html/mbs_crmpostcalloutsv1d2.asp


Microsoft CRM SDK - Post-Callouts
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/CrmSdk1_2/htm/v1d2postcallouts.asp


Microsoft CRM SDK - Registering your callouts:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/CrmSdk1_2/htm/v1d21addingyourcalloutstothemicrosoftcrmdatabase.asp

Microsoft KB Article 891979 - CRM Update Callouts do not fire for Assign Events
http://support.microsoft.com/default.aspx?scid=kb;en-us;891979