Today I had an issue where I had deleted a number of records from CRM during my loads of testing through Scribe.  After deleting these records, CRM updated those records to have a deletestatecode = 2.  Therefore, every subsequent scribe job would no longer work properly as the address still existed in the database.  Those of you used to CRM 3.0, there used to be a MSCRMDeletionService you could restart in your running services and it would force the job to run through all your records.  That is now wrapped in the Async Service of CRM 4.0 which you can restart.  For those of you who don't/can't restart that service for any reason, try this here:

USE MSCRM_CONFIG

UPDATE dbo.ScaleGroupOrganizationMaintenanceJobs SET
NextRunTime = getdate() -- Now
WHERE OperationType = 14 -- Deletion Service

This was found on an old archive site, posted by Aaron Elder.  Hope this helps others find it.  Be patient.  I fumed for a few minutes thinking it wasn't working but just give it some time. ;)

When all else fails.....

There are other ways going directly to the database level, but I cannot stress how bad of an idea that is and how much it should never be done.  Exhaust all other options CRM provides you before going to the database level and modifying it by hand.  'Because it would be faster' should never be a good enough excuse!!  If you have no other options of using CRM to it's full abilities and must do it by hand, something went horribly wrong and needs to be re-evaluated immediately after you clean up your data.

you're still reading....*sigh* ok but I warned you.

 CRM gurus correct me if I'm wrong, but from the understanding I have at this moment, every entity in CRM has two tables:

• [YourEntity]base - table that holds all the default out of the box attributes of your entity

• [YourEntity]extensionbase - table that holds all your 'new_' custom attributes for your entity

So if you have a 'Contact' with a 'new_foo' attribute and someone adds a new 'Contact' to your CRM instance, 

•  1 row added to your 'Contactbase' table - holds address1_line1, name, firstname, etc (all defaults)
  

•  1 row added to your 'Contactextensionbase' table - holds new_foo (all custom)
  

The BOTH have the same ContactID because they ARE the same contact.  So if you have to delete at the database level you MUST delete from the extensionbase table first and foremost.  The smartest thing to do is to first find out exactly which contacts you need to delete.  Whether its on IDs or a certain field state, get a select statement as correct and accurate as possible.  Once you have that select, I like to make a temp table of those records but this is purely optional.  The reason I like to do this is because sometimes the field I care to do my search on is a 'new_' attribute.  Where 'new_foo' = null.  But if I run my delete query on extensionbase where 'new_foo' = null, I just shot off my own foot.  The reason?  I just deleted all the rows who had any knowledge that 'new_foo' existed.  How do I know what rows I just deleted to now clear out the base table?   With a temp table, I can capture all that data and include a 'contactid' so I never am without a reference of what fields need to be deleted.

 As always, BACKUP before attempting this.  Run your delete on extensionbase.  Write down the number deleted.  Run your delete on base.  Match number deleted.  If it doesn't match, Panic.  Restore you database and refine your search until those numbers match.  Re-evaluate your process and NEVER DO IT AGAIN!

Why is seems like just yestarday we were posting about Update Rollup 3, and here comes Rollup 4!

You can find the KB article here: http://support.microsoft.com/kb/968176 

The actual files are here: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0ddf8e83-5d9c-4fe7-9ae6-f2713a024071#filelist  

Don't forget the updated help files!

One quick addendum, make sure you clear your Internet Explorer cache after installing on both the server and the client side.

While at Convergence last week, Microsoft went ahead and released Update Rollup 3 for CRM 4.0.  You can get it here.

A few important notes:

• Importing and exporting customizations is supported between servers with Update Rollup 2 and 3, but not supported between Release, Rollup 1 and Rollup 3. 
• The CRM for Outlook Client has some memory usage issues resolved.
• Performance issues with CRM related to the email router have been resolved.

For those of you who are looking for resources to help with CRM issues, or just to keep up on the news of CRM, I wanted to provide a few links.

• Microsoft Dynamics CRM Team Blog
• Microsoft Dynamics CRM Online Blog
• Microsoft Dynamics official forum The Development forum specifically is nice for customization issues. (Updated link to reflect new site)
• Microsoft CRM Google Group   
• Microsoft CRM Developer Google Group  
  
• Microsoft CRM Deployment Google Group   
• Microsoft Dynamics CRM - Jim Wang's technical blog  
• Stunnware CRM JavaScript Snippets  (works best in IE)

So I hope that helps anyone looking for solutions and/or community for CRM.  If you are in LinkedIn, there are numerous CRM groups there as well.

Finally, Update Rollup 2 for CRM 4.0 has been released!  Get those patches up and running.

First off, I want to give a big thank you to Jeremy Winchell for writing up the post that got me started in the right direction for this solution.

For those of you that customize Microsoft Dynamics CRM 4.0, like I do, then likely one of the things you repeatedly run into is clients and users that need to have better names for their actions.  Changing these names on the main navigation page relatively simple, but what about on all the other pages, like Contacts, Accounts, etc.?  These, for whatever reason Microsoft had, aren't removable or changeable.  It's a really painful oversight to have to tell a client that even though you have renamed "Products" to "Hardware", they're going to have to remember that it's still going to be "Products" in a few places.  Hopefully the next version of CRM will have the capability to alter and remove these natively, but until then, we'll have to roll our own.

 Warning, the following actions are not supported or even documented by Microsoft.  Use at your own risk.

Now that the disclaimer is out of the way, let's take a look at the meat of the solution.  First, go to the customization area of the Entity you want to change, and open its form view.  In there, click Form Properties and enable JavaScript for the OnLoad action.  The link above has pictures if you're not sure how to get there.

Now you will need the JavaScript:
document.getElementById("%variableName%").style.display = "none"

So in this line, %variableName% is the variable related to the button on the left-hand nav.  “none” will hide this element entirely.  (Also, make sure if you copy and paste that you don’t end up with retarded Word-style quotes.  That happened to me and I spent 10 minutes trying to find a typo in my code)

If you want to change the display name of a button, then you have a bit more work to do.

Again, the JavaScript:
document.getElementById("%variableName%").innerHTML= "<img src=\"%imageLocation%\" /> %displayName%";

Here, you will see that we’re using innerHTML to actually change the content of that button.  Now you don’t have to have the image code in here, but if you leave it out, then your link won’t have an image anymore, and will just be text.  If you want to keep the image, the best thing I have found is to use the IE Dev Toolbar and then look at that button’s properties (to get the IE Dev toolbar on a popup screen, hit Ctrl+N).  You will see the link to the default image there.  This is going to be different for every CRM install, so I have not included it on the table below. Then just change the Display Name with whatever you want the button to actually say, and you’re set!  Note that the quotes around the image location have to be escaped.

Below is a list of the links, their variable names, and their default Title.  From there, making changes to the left nav of any entity in CRM should be simple.   You will see repeats of some.  The reason for that is because MS was not 100% internally consistent in its naming scheme.  For example, Cases is IDed by both navService and navCases, depending on where you are.  For those, I would either try both, or check on the screen itself.

So now you should have all the tools you need to customize the Entity Screens into something useful for your clients and users.  And don't forget, if you break something, you can always just delete the JavaScript and start over.