DotNetNuke 6

Today we posted a blog about How to configure IFD Hosted Setup in CRM 2011
Following on from that we tested the migration from CRM 4.0 hosted CRM instillations to the newly configured test environment for CRM 2011.
We ran into a few problems (and a few things we did not know) and thought others may benefit from this.

CRM Migration

The process was reasonably simple for us and for that reason we will just list the steps.

1. Backup the CRM 4.0 database to file.
2. On the new CRM 2011 SQL server, perform a normal SQL database restore from the backup file.
3. Use the CRM 2011 deployment tool to “Import and Organisation”. Specifying the obvious settings for the database selection and user mapping. (In our case, we were on the same domain, so user mapping was easy).

All this worked well, but there were a few problems when we went to browse the new Org from outside the server. In other words, using the IFD to access the org.
Internally the org was accessible with https://internalcrm.domain.com/orgname  but external access: https://orgname.domain.com:xxx  failed.

The Problems

First one

Was simple but only because we have seen it before. Originally we had accessed the org from our IE 9 browser with https://org.domain.com and accessed the CRM 4.0 IFD. Actually we used it for over a year.
Now we wanted to use the new IFD on CRM 2011, but on the same browser. We found when going to: https://org.domain.com:444 that the browser was not even rendering the request for user name and pass that we expected:

The IE failure gave no message or indication of why. Basically a 404 failure to hit anything useful.
Yet in another “real browser” (not IE) we could at least get prompted for user and pass info.

The Cause

IE really sucks with clearing old data. The delete all / clear cache / remove cookies appears on the outset to dump everything, but it does not. In our case, it cached something from the previous connection to CRM 4.0 that was killing our access. We then also deleted data in “C:\Windows\Temp”  Can’t explain what the cause is… I would just rather put it down to the fact that IE 9 “blow chunks” (big ones).
The solution is to manually navigate to the Temporary Internet Files directory under Windows, and manually delete everything you find in there. That fixes the page rendering issue.
More information here: http://www.interactivewebs.com/blog/index.php/crm/crm-2011-server-error-404-file-or-directory-not-found/
The Second One
Second, we entered a user name and pass, and received a message:

There was a problem accessing the site. Try to browse to the site again. If the problem persists, contact the administrator of this site and provide the reference number to identify the problem. Reference number: numbers

There was a matching set of AD FS 2.0 Event Logs that looked like this:

A token request was received for a relying party identified by the key ‘https://org.domain.com:444/default.aspx’, but the request could not be fulfilled because the key does not identify any known relying party trust.
Key: https://org.domain.com:444/default.aspx
This request failed.
User Action
If this key represents a URI for which a token should be issued, verify that its prefix matches the relying party trust that is configured in the AD FS configuration database.

and

Encountered error during federation passive request.
Additional Data
Exception details:
Microsoft.IdentityServer.Web.InvalidScopeException: MSIS7007: The requested relying party trust ‘https://org.domain.com:444/default.aspx’ is unspecified or unsupported. If a relying party trust was specified, it is possible that you do not have permission to access the trust relying party. Contact your administrator for details.
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, Uri& replyTo)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, MSISSession& session)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseCoreWithSerializedToken(String signOnToken, WSFederationMessage incomingMessage)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseCoreWithSecurityToken(SecurityToken securityToken, WSFederationMessage incomingMessage)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseForProtocolRequest(FederationPassiveContext federationPassiveContext, SecurityToken securityToken)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponse(SecurityToken securityToken)

The solution

An easy one, but something we did not know. With CRM 2011 in IFD. Each time you add an org, you need to update your Relying Party Trusts from Federation Metadata. Big words that mean…

1. Open AD FS Management Tool
2. Expand Trust Relationships
3. Click on Relying Party Trusts
4. Click on you IFD Trust, Right Click and Select Update From Federation Metadata

I have no idea why this is not automatically updated every time the service starts, or even every time the service is called upon….
In any case, that fixed the issue and we are on our way for testing our CRM – DotNetNuke integration suite with CRM 2011 and DotNetNuke 6.0. Wish us luck.