Recently I have had to configure a virtual environment for IFD to test a MSCRM 2011 solution I have developed. The solution had to work on the internal domain as well as externally. Below I have listed the steps I went through to get IFD working internally and externally on the same machine. Please note that these steps worked for me and my scenario/setup. They may help as a guide for your deployment. This guide expects you to have some knowledge around DNS, Certificate Management, Internet Information Services and Microsoft Dynamics CRM.
I am in the final stages of deploying a Silverlight calendar that I have developed for Microsoft Dynamics CRM 2011. One of the final touches is to place a link for the calendar on to the sitemap. For this to work a webresource reference was placed into the sitemap that points to the HTML page which has the Silverlight application embedded in it. When the link was tested for some bizarre reason an embossed border was placed around the web resource.
In Microsoft Dynamics CRM 4, to make CRM externally facing you had to configure the internet facing deployment tool. This would enable you to access CRM externally through forms based authentication. In Microsoft Dynamics CRM 2011 Microsoft have decided to ditch forms based authentication for claims based authentication.
One of my first choices while starting my Silverlight development in Microsoft Dynamics CRM 2011 was to used SOAP or REST. What surprised me was the lack of a clear answer in the Microsoft SDK. All I could see was a fuzzy answer, something along the lines of “Well REST is potentially OK for this… but SOAP can do that as well…”, and “SOAP is good for this…, but REST can actually achieve that as well…”. AHHHHHHHHH!!!!!!!! So I’ve given both a go and finally came to a conclusion.
From time to time you can find yourself in a scenario where your System Jobs list is clogged up with workflows stuck in a waiting state. The Microsoft supported way of removing the items is through performing an advance find on waiting workflows and manually cancelling up to 250 workflows at a time. In extreme situations we do have another option which is suited to cases where we don’t have manageable amounts of workflows stuck in waiting.