MSCRM Workflow Stopping, IFD cannot login, Async Service Crashing

Submitted by Robert MacLean on Wed, 05/14/2008 - 18:08
Eek, my first post in 50 days. I have been very busy on a new business venture which is very exciting from an offering and technology view. So lots of long nights with not enough time to blog. I will be posting a huge multipart blog on the expierences of that in the near future. Add to that finding out I will be a parent in Jan '09 it's been extra hectic.

Anyway on to the my new favorite issue of MSCRM 4.0, the async service crashing. Should it crash it takes down lots of features, to name some big ones:
  • Imports
  • Data Duplication
  • Workflow
  • Logging into a IFD deployment via the forms login
Well this can occur if you have added a new deployment to your MSCRM deployment which contained workflows which were running. These rogue workflows crash async with a lovely message in the eventlog (The entity with ObjectTypeCode = 0 was not found in the MetadataCache.). Well Microsoft have released a hotfix for this issue, which is available at

MSCRM 4.0 Error: Invalid Action

Submitted by Robert MacLean on Tue, 03/25/2008 - 17:42
So I had a great surprise this morning walking into the office, MSCRM 4.0 greated me with Invalid Action, The Selected Action Was Not Valid. This is after a long weekend with no one doing anything, or any system changes. So first I check if it's my machine only, nope everyone. Next I check if the server does it to itself by logging on to the server and opening MSCRM, still same problem. IIS reset, same problem. Check services, same problem. Check if SQL is up and the database is fine, yip.

Then suddenly someone mentions an issue on MOSS where they can't edit a document... I wonder if it's related so I log on to the SQL box and check the disk space and (DUM DUM DUM!!) there is no space left on the disk drive for the databases. A quick clean of the transaction logs and the system is back up and running great.

Making ASP.NET pages look like MSCRM

Submitted by Robert MacLean on Mon, 03/17/2008 - 19:19
(This is a repost of the content which was previously available on the IW community site)

Microsoft CRM supports many customizations, some of them are simple (adding a field) while others (also simple to do) actually allow you to embed other web pages view IFrames or add new buttons to the tool bar or the links on the left hand side of the window. This is great as part of the ability to link pages in is that CRM automatically passes various parameters to the web page that is being referenced, including the Guid and type of object. This means if you build a web page your web page gets context information for free (no weird JavaScript to navigate to it).

The problem seen at many customers is that these pages look nothing like CRM. This would make sense if you are embedding something like Live Maps, but if you are building the pages yourself why not make them look like CRM. This improves the user experience significantly and really isn't hard to do. In fact Microsoft has shipped a sample in the SDK for you. The problem is this is a HTML page and when converting to ASP.NET you will hit a few problems. However it is a simple 9 quick steps to get it right. So let's get into how to make your ASP.NET page look like Microsoft CRM.
  1. Once you have loaded your project (I am assuming you are using a new page which has had nothing done to it), navigate to where you have extracted the CRM SDK, and under it you will find a style sheet you will need. It can be found in: CRM SDK\sdk samples\stylesheet\template.css. Add this to your project.
  2. Next drag the CSS file from the solution explorer onto the default.aspx (I am assuming that Visual Studio is in design view and not source view). If you get this right the background will go that lovely light blue.
  3. Next open the sample html page (CRM SDK\sdk samples\stylesheet\sample.htm) in your favorite text editor and copy the content from opening body tag to closing body tag. Now switch VS to source mode and replace the pages content from opening body tag to closing body tag with the copied source.
  4. When you try to switch back to design view you will get 11 errors. Thankfully it is easy to fix those. li>
  5. The first fix is to add the runat attribute to the form tab and move it up two lines so it appears above the table tag. So it looks like the image here.
  6. Next move line 245 to after the closing table tab on the following line so it looks like the image here.
  7. Now remove line 15 (should just have </td> in it).
  8. You should be able to get back to design view! But you will be greeted by something not very CRM like still
  9. Lastly switch back to source and go to line 3 (should start with: <!DOCTYPE) and remove it. This line controls if Internet Explorer works in standards compliant mode or quirks mode, which is a non-standard rendering method. As CRM works solely on IE on Windows, there was no need for compliancy and thus the designers didn't include this and used non-compliant tricks to improve the UI, like tables expanding to but not exceeding 100% of screen height and the gradient effects. <
If you now switch into design mode you will see the pretty CRM pages. What I would suggest is to now hit Ctrl+E,D in source mode which will format the HTML to be neat (great little feature in VS 2005 this is. It also works on code and XML) and save this page somewhere on your machine as a base so next time you don't need to do the cleanup to get it to work.

Undocumented MSCRM 4.0 Requirement

Submitted by Robert MacLean on Mon, 03/17/2008 - 19:19
Just what I love at 4pm on a Friday afternoon, finding a undocumented requirement for a product while sitting in front of the client. Anyway, it appears that the location of the MSCRM Monitoring (what ever that is, I found this by checking the install logs) is set in the installer to C:\Program Files regardless where you put MSCRM itself. Even worse is that it is not <System Drive>\Program Files, it is C:\Program Files. I have NO C: on this box (dunno why, but thats what IT provided).
I suspect you can work around this by creating an unattended installation (see the implementation guide for creating the XML files for that), but I'm actually lucky enough to have an empty second drive I can change the drive letter to C (using disk manager).

Add to this that nothing actually appears on C: once I fixed the issue (assuming it is checking for something, and that is failing and thus the issue). So all that I have left to do is:


MSCRM 4.0 IFD Manager - Stupid Tip

Submitted by Robert MacLean on Wed, 03/12/2008 - 09:25
I still make stupid mistakes, and I don't think that will change anytime soon. I grabbed a copy of the released IFD tool and tried to use it a couple of times, each time it crashed. I tried it on different machines with different OS's and no joy. I thought the download was bad so I downloaded it again. I almost even posted to the newsgroups for help (not having time is my saving grace). If you extract the tool and it just dies immediately, you may be like me and didn't read the manual.

It clearly states that it should be extracted to a specific folder, namely drive:\Program Files\Microsoft Dynamics CRM\Tools (see point 2). Once in there is works like a dream.

Workflow doesn't work, Imports never happen, emails don't flow and Outlook clients cannot connect - Reloaded

Submitted by Robert MacLean on Wed, 03/12/2008 - 09:07
Update 23 June 2008: See for an official way to do this.

In my previous post on Workflow doesn't work, Imports never happen, emails don't flow and Outlook clients cannot connect I went through the fix by changing SQL. I never liked that fix because it breaks rule one of MSCRM, never edit the database directly. It also has the high chance of screwing up your deployment (quote in the wrong place, or highlight skills lacking in SQL), so I finally found an offically supported tool which does the exact same thing: The IFD tool

What is great about the release version of the tool is it allows you to change those settings in a On Premise scenario only (the bottom set of items), so you don't need to suddenly switch to IFD with the tool to fix the issue. So definitely if you are having a problem, rather use the tool than the SQL statement.

Request IP Address has different address family from network address.

Submitted by Robert MacLean on Wed, 03/12/2008 - 09:02
Here is a new great error for MSCRM 4.0 "Request IP Address has different address family from network address.". You may get this when openning MSCRM. You may also get this in the event log. If you are seeing it in the event log it means that Workflow doesn't work, Imports never happen, emails don't flow and Outlook clients cannot connect. Lastly it is likely you are using Windows 2008 (although I suspect this can hit Win2k3).

Well what is happening is that MSCRM 4.0 doesn't work with IPv6 (as pointed out at, but what is happening is that the names are resolving internally to IPv6 addresses. The easy way to test is ping the server name and localhost for instance, if you get an IPv6 ip address then welcome to the black parade.

The fix for this is simple, open your hosts files (<system drive>:\windows\system32\drivers\etc\hosts) and add a line for your server name there with an IPv4 address. Save and ping again to make sure it is working. Once it is, do an IISReset and it will be working!

IE8 - The developers best friend

Submitted by Robert MacLean on Tue, 03/11/2008 - 08:52
There are a few good reasons to use IE 8 as a developer but yesterday I found my new favorite. When using Visual Studio 2008 and running the site a new section appears in the solution explorer called Script Documents. In this little gem of a folder is the pages you are looking at, the scripts etc... all as the server provided them to the browser! Meaning if you open the .aspx page there is no ASP controls, just normal HTML. If you do inserts of JavaScript via OnInit, that is there as well. Amazing!

The missing feature of remote desktop

Submitted by Robert MacLean on Tue, 03/11/2008 - 08:42

Remote desktop for Vista (and if you download the update for XP) has a great feature, it allows you to save the username/password combination so you don't have to type it in all the time. When I put the update for XP on, I was doing work for one of the large banks in the country and worried about what happens if they steal my laptop. If they can get in, they just need to open remote desktop to access various systems :(

Well Windows Server 2008 finally fixes this, but enforcing a rule which denies saved passwords. Meaning if you save or not, you have to retype.

Another great feature in 2008 is the ability to secure the remote desktop to use network level authentication, which means it is even more secure than normal. With the only requirement on the client being you have to run Vista.