CRM 2011: ADFS Error – Each identifier for a relying party trust must be unique


When deploying ADFS/IFD solution, you will most likely want to build a seperate ADFS server. Since ADFS is Microsoft’s STS (Security Token Service) many of their applications including Microsoft Dynamics CRM 2011 will be federating with it for single sign-on within your enterprise.

ADFS can be setup on a single server, and can work with multiple instances (Dev, Test, Production) or deployments of Microsoft Dynamics CRM 2011 as show below:

The gotcha is the names of the CRM Organizations across the multiple CRM deployments. You cannot have duplicate organization names between dev, test and production. So for example an organization named CRM, cannot be used in both DEV, TEST and PROD when using ADFS. This will give you the following error message:

An error occurred during an attempt to access to the AD FS configuration database (Write to). Each identifier for a replying party trust must be unique across all replying party trust. This error is because the indentifier in this case CRM is referenced by the identifier https://crm.domainname.com. Once you add in DEV, the duplication occurs when you then try to add TEST and PROD.

A CRM Organization name change is required to use one ADFS server for three seperate deployments, so CRM would become CRMDEV,CRMTEST & CRM, hence eliminating the duplication in identifiers, hence the error. Enjoy!

 


CRM 2011: ADFS 503 Error and How to Fix It!


When implementing ADFS to support Internet Facing Deployments (IFD) for CRM 2011 Claims Based Authentication, many administrators will experience an ADFS 503 error when trying the endpoint for both internal CRM and auth within a browser. The error message is usually 503, service not available. A simple IISreset might do the trick but for these cases it will not.

Previously, the undocumented fix was to use the handlers/FederationMetadata.ashx URL instead of the complete https://internalcrm.domain.com/FederationMetadata/2007–06/FederationMetadata.xml.

The issue behind why the 503 occurs, is because the URL was previously reserved in the Access Control List (ACL). Because of how the URL’s are reserved (before instead of after installation) and change of bindings and ports will leave the reserve URL already in place for /FederationMetadata/2007-06 etc.

From the CRM Server (or ADFS for external trust), using an adminstrative command prompt, issue the following command:

netsh http show urlacl (note: you can also use the > to pipe the output to a text file etc)

You are looking for the reservations made by ADFS:

 

 

 

 

 

 

Now delete the old URL reserveration by entering the following command:

netsh http delete urlacl url=https://+:443/FederationMetadata/2007-06

 

 

 

The URL has been deleted, you will need to reconfigure Claims Based but clicking on the wizard in the deployment manger again, re-stepping through the same steps (next,next,next etc). Now try the URL again and the ADFS 503 error will be gone!

Special thanks to Dan Francis @ Microsoft for contiuning to share ADFS tips together. Enjoy.

 

 

 

 


CRM 2011 Rollup 5: Issues Reported After Installs


Several customers are reporting issues since installing rollup 5 which is not uninstallable:

  • Workflow based Organizations (many levels deep)
  • ADFS / IFD Deployments
  • CRM Email Router and Outlook Clients ( Cannot access the webservices)

A hotfix was originally released but now has been disgarded. Micorosft has now released UR6 to fix some of the issue(s) introduced with UR 5.


Best Practices for Implementing CRM 2011 Claims Based Authentication


Presentation from the CRM UG Summit 2011 in Las Vegas, November 11, 2011

Configuring ADFS/IFD for CRM2011 can be challenging. During this session we will explore the technology, focus on key configuration points, and discuss best practices and tips. The information presented during the session is based on lessons learned from working in the trenches on more than 40 real-world implementation of CRM 2011 since Feb 2011.

 CRMUG_Summit_2011_IFDADFS


CRM 2011: Reinstallation of ADFS fails after installation removal.


When installing ADFS to support your CRM 2011 IFD installation, if you have any errors or stop the install, the install will leave directories under the default website that need to be deleted.

You can run this from the command prompt:

appcmd delete app “Default Web Site/adfs/ls

This will delete the website. You can also view the application pool in IIS to see all applications still associated to the application pool as shown:


CRM 2011 ADFS/IFD Installation Tip: Using the BackConnectionHostNames Registry Key


During the CRM 2011 installation process for ADFS/IFD, you will notice issues when resolving external non matching internal domain references (crm.microsoft.com to crm.go.local) especially when using the SSL certficates. This can take hours of tracing and troubleshooting to realize its related to a new lookback feature introduced with Windows 2003 Server SP1.

The solution is to add to key BackConnectionHostNames to the registry, with the DNS, most likely your ADFS and internalcrm webserver FQDN (fully qualified domain names ie xxxx.companyname.com)

Click Start, click Run, type regedit, and then click OK.

In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_04.Right-click MSV1_0, point to New, and then click Multi-String Value.

Type BackConnectionHostNames, and then press ENTER.

Right-click BackConnectionHostNames, and then click Modify.

In the Value data box, type the host name or the host names (Adfs.companyname.com the external address for the ADFS system) for the sites that are on the local computer, and then click OK.

Quit Registry Editor, and then restart the IISAdmin service from the command prompt using IISRestart

http://support.microsoft.com/kb/896861