Posted: Tuesday, June 03, 2008 10:15 PM by K|Dubya While requests to use Microsoft Dynamics CRM and CRM Online from a Mac are not terribly frequent, it comes up every once in a while so it is definitely worth addressing.
Supported clients for Dynamics CRM include Internet Explorer 6 (SP2) and later, and Outlook 2003 (SP2) and later. Unfortunately, Entourage is not a supported client. And, supported operating systems are all of the Windows flavor.
So, while there's no direct method to do this, there's always a way, right? Here's a compilation of ideas.
Use Virtual PC, Parallels or Bootcamp software to run Windows on the Mac
I have made some minor upgrades to the Plug-in Registration v2.0 tool that is included in the Microsoft CRM 4.0 SDK download or downloaded from Code Gallery.
The following features were added for making the developer’s life easier.
1. Support for https:// in the tool
The Connections Grid now accepts a Discovery Service server name in one of the following formats.
When making web service calls to the https:// servers, the current logic blindly accepts all the certificates. The program trusts the https:// endpoint that you provided to the tool. It does not verify if the certificate is Expired or if it is from VeriSign etc. You could change the implementation of the logic in the code.
2. Support to change the endpoint returned by the DiscoveryService Web service
Sometimes due to incorrect configuration the SDK endpoint returned by the discovery service is incorrect. So I made modifications to the tool to allow you to change the endpoint that is returned by the discovery service before making any calls to the CrmService Web service.
3. Support registering images for a subordinate entity for Merge
The Merge request involves 2 entities, a parent entity and a subordinate entity. Inside the plug-in you might want to Plug-in Registration Tool 2.1get the image of both the parent and subordinate entities. Now, in the plugin registration tool 2.1, when you register an image for Merge, a dialog is displayed that states “Do you want the image for Parent or Subordinate entity?” You can now register for both.
4. Plugin Registration in IFD/SPLA
IFD or SPLA installations do support plug-ins. You can now use the tool to register a plug-in on the Microsoft CRM server using AD authentication. You will need the DeploymentAdmin privilege to register a plug-in just like you would for an on-premise installation.
5. Works with Visual Studio 2008
6. Restrict image registration for a Create pre-event and Delete post-event
Images are snapshots of the entity’s attributes at the corresponding stage in the pipeline. When you look at the CreateRequest, a plug-in registered for a pre-event on Create gets fired before the Create platform operation occurs. For example, the plug-in is fired before the entity is created in the system. So it doesn’t make sense to register the plug-in step for a pre-event image. The new version of the tool doesn’t allow that image registration.
Similarly for post-event Delete step, we don’t have an entity after a Delete operation, so it doesn’t make sense to support registering for a post-event image.
David Fronk wrote on Tuesday, July 01, 2008 received word from Microsoft that they have an update available to fix an issue that occurs with the email router. For whatever reason the email router will poll for an hour and then lock for an hour. If it unlocks itself after that second hour it will work for another hour and then lock itself again. The hour comes from the default polling time that is set up in the email router config file. So, if you were to modify that polling time then you would extend the life of your email router from locking up but also extend the amount of time to get the email router back up once it is locked.
I used a work around to get by until this hotfix became available by restarting the email router service each hour via a bat script.
However the hotfix you want to check out is KB article 952019. You will need to contact Microsoft via PartnerSource or CustomerSource in order to obtain the hotfix, but you will not be charged for the ticket if you are requesting the hotfix.
Hope this comes in handy for someone else as well.
Extra Parameters passed by CRM To support multi-tenancy and multi-language deployments, CRM 4.0 passes additional parameters on the query string when the 'pass record object-type...' option is set for the IFrame. These extra parameters are orgname, UserLCID and OrgLCID.
For the report to work in reporting services you will have to add parameters with these names to your report. The orgname parameter has to be a string, the UserLCID and OrgLCID can be either strings or integers. As with the type and typename parameters, these new parameters don't have to be used in the report, they just need to exist for reporting services to accept values for them on the query string.
Changes to the query string for ISV.Config buttons In CRM 4.0, Microsoft have standardised the parameters such that they are the same for IFrames and ISV.Config buttons. This means that your report should have parameters id, type, typename, orgname, UserLCID and OrgLCID.
I was recently coding a plug-in and every time I ran it it gave me errors, 401 or 404. I then backed my code out to the basics and every time I tried to call the crm service it failed. I went as far as to reading the SDK and Documentation. Then copying code from there. I still received errors. This was very frustrating; however, I came upon the attached blog that solved my issue. First there IS A BUG WITH CRM (go figure) that will return localhost instead of your crm server website. NICE!!! So basically if your CRM website is not resolvable to 127.0.0.1 then plug-in FAIL. Binding 127.0.0.1 to your CRM website will fix this for now.
George wrote this Article Yesterday I was working on some plug-in code which was working fine earlier. I changed pipeline to synchronous and started to get consistent "404 - Not Found" error from calls to CrmService. I reduced the problem to something like this:
publicclass MyPlugin: IPlugin { publicvoid Execute(IPluginExecutionContext context) { ICrmService service = context.CreateCrmService(true); account a = new account(); a.name = "test"; service.Create(a); // this line fails with 404 } }
And it just was not working. We all know about very "informative" SoapException which would have been fine but I was getting simple http-level 404. Something was pointing somewhere it shouldn't have...
Stepping through with the debugger I managed to find out that, if plugin is registered for synchronous execution, call to context.CreateCrmService seems to return a service wrapper that ALWAYS points to http://localhost/MSCrmServices/2007/CrmService.asmx regardless whether CRM is handling requests to http://localhost or not. In my environment CRM was installed outside of the default web site and, as such, did not handle requests sent to localhost. Hence consistent 404 error.
I managed to "reflectorise" the problem down to the class Microsoft.Crm.Extensibility.CrmServiceFactory in the assembly Microsoft.Crm.ObjectModel. In this class GetServerUrl() method contains something like this:
string deploymentSetting; // protocol, i.e http or https
int nullable? = null; // this is actually local port for crm, e.g. 5555 on the server or 2525 offline
<snip >some cassini logic and getting localsdkport setting from registry</snip>
string str2 = "localhost"; // here you have it if (nullable.HasValue) { str2 = string.Format(CultureInfo.InvariantCulture, "{0}:{1}", newobject[] { str2, nullable }); } returnstring.Format(CultureInfo.InvariantCulture, "{0}://{1}/MSCRMServices", new object[] { deploymentSetting, str2 }); // this is always a localhost?!
So, basically it always returns something like http://localhost[:optionalport]/MSCRMServices. Which is fine if you are in offline mode or if you have your http://localhost pointing to your CRM web site which is not the case in my development environment.
Plug-ins registered for asynchronous execution are getting CrmService wrapper from a different proxy factory located in assembly CrmAsyncService.exe which seem to honour all configuration settings.
Workaround
I could not think of anything better but to add localhost to the list of headers handled by CRM web site. Simple yet effective - the problem's gone. This workaround is fine in development environment but not in a deployment where for one reason or another localhost must point elsewhere.
I am curious to hear from fellow developers if anybody has come across of this problem as well as from anyone from MSFT if this behaviour is by design or it's a bug.
June 5, 2008 15:56 by menno We released a new version of Microsoft Dynamics CRM but the questions regarding the product seem to stay the same. Recently, I have received several questions around how to install Microsoft Dynamics CRM 4.0 with the minimum required permissions, as this is not well documented in the Implementation Guide.
Rather then to type it myself I would like to point you to our Online Knowledge Base. The guys in support have created a step-by-step KB article for v3.0 and v4.0 to help you with this.
Adding Activities to the Contact form in an iFrame
I came across the details on how to do this when reading a blog posting from Matt Wittemann a couple years back. I still use it and thought you might be interested. Another capability to demonstrate the flexibility of the configuration options of Microsoft Dynamics CRM Online.
1. Create an iFrame on the Contact form with the following properties.
2. Note the iFrame Name. The color coding will come in handy later. In this example I use IFRAME_Activities.
5. Open a new IE window and enable the IE Developer toolbar
6. Paste the contact URL to load the Contact record with the IE dev toolbar enabled. Click on the toolbar icon for “Select Element by Click”
7. Find the Activities id by clicking on Activities from the left nav bar. Ensure to select the whole Activities area, not just the logo or the text. See outlined in blue in the screenshot below. Note the id: NavActivities from the middle window of the toolbar.
8. Click on the toolbar icon for “Select Element by Click” to disable it and click on Activities in the left nav bar to open the Contacts’ Activities list view in CRM. Enable the “Select Element by Click” functionality and click to the left of Filter On: Next 30 Days to select the windows highlighted in blue below.
9. Note the src value (areas.aspx?oId=…) from the middle window of the toolbar. In particular the part of the string after the CRM GUID starting at “&oType=2&security=…..”
10. Include the nav values and src value in the following script. The script is complete with values highlighted.
I work for a consulting firm in Dublin Ohio called Affiliated Resource Group. For the four years I have been spearheading our Microsoft Dynamics CRM practice. I have a deep appreciation for the Microsoft CRM platform and I am very excited about it. You might even describe me as a Microsoft CRM Advocate. I have many battle scars from my experience with the product and I’m constantly being asked questions about CRM and how-to-do something in it. Hence, this BLOG is to help disseminate that knowledge and information to everyone. Now, knowledge is not always gained by my suffering through issues, I have found that it is very advantageous to read what other people are going through as well. I subscribe to about 60-80 other CRM blogs and as good information is logged on them, I will post those tidbits of knowledge on my blog as well. Why, so that my customers can subscribe to one blog and not have to read about someone’s cat or political views. With that said, 90-95% of the blog posts on this site are from other CRM bloggers. So good luck and I hope that this blog may help in some way. If you have suggestions or questions, please email me them.
While requests to use Microsoft Dynamics CRM and CRM Online from a Mac are not terribly frequent, it comes up every once in a while so it is definitely worth addressing. 
Posts
