If you have a Dynamics CRM 2011 installation, and users have started using Internet Explorer 11 (either by upgrading from IE10, or by installing Windows 8), then you’ve undoubtedly noticed that, when an IE11 user goes to your CRM site, they are greeted by the Mobile Express version, rather than the standard site. There are a few manual workarounds to this:
Downgrade from IE11 to IE10 (not an option for Windows 8).
Add your CRM domain name to the compatibility list in IE11 (not an option if you don’t want the entire domain to be in compatibility mode, or if you have group policy settings which prohibit this).
Instruct users to go to https://yourcrmdomain.com/main.aspx.
That third bullet is interesting… If you go to the root of your CRM domain name in IE11, you will be redirected to the Mobile Express site. If you go to the “main.aspx” page on the root, you go to the full CRM site. . . .
→ Read More: Stopping Internet Explorer 11 from showing the mobile express version of Dynamics CRM 2011
Lots of tables in Dynamics CRM use the ObjectTypeCode to identify the entity. Sure, we all remember that Account is ObjecTypeCode 1 and Contact is ObjectTypeCode 2… But what about your custom entities, which start at 10,000 and are not guaranteed to be the same in different organizations, even if you have the same solutions installed — how will we remember their ObjecTypeCode values?
You don’t remember them, you query them when they need you. It’s quick and easy if you are on premises and have access to the SQL database. (If you don’t, ask your DBA to create a view with this query and give you rights to it.)
select coalesce(OriginalLocalizedName,name) as DisplayName, Name as SchemaName, ObjectTypeCode
order by ObjectTypeCode
Much easier than memorizing, and avoids the problems of remembering the wrong number for the wrong organization or deployment. Oops!
. . .
→ Read More: Getting Dynamics CRM ObjectTypeCode values via SQL
Some would wonder why such a question is asked… but in my Microsoft Dynamics CRM 2011 environment, we do not require a First Name or Last Name on a Lead. When a Lead is qualified, users often click the buttons to create an Account and a Contact, even when they haven’t specified any contact-specific information (such as first and last name). What results is often a Contact with no name, and that contact is the Primary Contact for the Account. Ouch!
To fix this, we created a workflow on the Contact entity, which would deactivate the Contact if it had a Qualifying Lead, and had a blank First Name or Last Name. This took care of the Contact, but there was still a problem: the Account’s Primary Contact pointed still pointed to the nameless Contact we just deactivated!
Looking at the Audit History on the Account, we were able to figure out that, when . . .
→ Read More: Getting rid of nameless Contacts when Leads are qualified in Dynamics CRM
In the “oh my, how did that slip through?” category comes this one: in Dynamics CRM 2011, the ZIP/Postal Code field on the Address (CustomerAddress) entity is not searchable by default.
Weirder is that the ZIP/Postal Code fields on the Account, Lead, and Contact entities are searchable by default. Weird only because they use the same underlying table (CustomerAddress).
Keep this in mind when you wonder why you can’t search for additional addresses by ZIP code. Make that ZIP/Postal Code field on the Address entity searchable, and you’re good to go.
. . .
→ Read More: Dynamics CRM doesn’t enable search on Address ZIP/Postal Code by default
Anyone who has attempted to configure Dynamics CRM 2011 with an Internet-Facing Deployment (IFD) knows that it is no trivial task. Where there are blog posts that discuss setting up an IFD, and Microsoft documentation for configuring the IFD, they often assume that ADFS and Dynamics CRM are installed on the same server, and that there is only one Dynamics CRM front-end server. Unfortunately, real-world implementations don’t always follow that.
For example, take the following configuration:
- a Dynamics CRM front-end server on the internal network, providing services to internal clients
- a Dynamics CRM front-end server in an Internet-facing zone, providing services to external clients
- a separate ADFS server accessible to internal and external clients
Dynamics CRM with IFD requires a combination of ADFS relaying party trusts and DNS configuration to get things working. One caveat with IFDs is that the internal and external host names for the Dynamics CRM front-end servers must be different because, externally, the host name includes the CRM organization name. Where, internally, you may have https://icrm.contoso.com/crm, externally you would have https://crm.contoso.com.
Let’s flesh out our sample implementation and requirements:
- icrm.contoso.com is our internal Dynamics CRM front-end server, accessible only on the internal network
- ecrm.contoso.com is our external Dynamics CRM front-end server, accessible to our internal network and the public Internet
- adfs.contoso.com is our ADFS server, accessible to our internal network and the public Internet
- We have two Dynamics CRM organizations: CRM and CRM-Test.
- We want our internal and external (public Internet) clients to access CRM using the same URLs: crm.contoso.com and crm-test.contoso.com. In other words, we don’t want the two-URL problem outlined above.
The last bit has nothing to do with Dynamics CRM: it is all done in IIS. Let me explain how. . . . → Read More: URL Rewriting for user-friendly URLs with Dynamics CRM 2011