In the hope that this might help you in your quest for better CRM, here's how it played out:
The server configuration was pretty simple and normal, with the possible exception of that last bullet, but we tried it without that also:
- CRM Web Server (1) running all latest software, joined to corp domain
- ADFS Server (1) running all the latest software, joined to corp domain
- Wildcard cert purchased through internet cert issuer for *.mydomain.com
- We replaced the default self-signed ADFS token-signing cert with our SSL wildcard cert
Then we configured IFD and all seemed well. Next, on the ADFS server, we tried to create a Relying Party Trust for CRM. This wouldn't allow us past. So we popped open IE and tried to go to https://auth.mydomain.com/FederationMetadata/2007-06/FederationMetadata.xml. This threw an ASP.net error, so we went to the log file on the CRM server to see what was up.
The error in the Application Event log was "CrmSecurityException: Relying Party Certificate was not found". So we went through all kinds of checking to ensure that the cert was in the Personal and Trusted CA store on both servers and that the CRM app pool account had access. We finally hit a breakthrough when we turned on tracing. The error in the trace file was pretty much the same as the event log: "Relying Party Certificate was not found., ErrorCode: -2147220906". But what was interesting was the line before the error:
Query execution time: 0.0 seconds; database: MSCRM_CONFIG; command: SELECT Id, Name, CertificateData, StoreName, StoreLocation, StoreFindType FROM Certificates WHERE (((ParentId is null) AND (Type = 'RelyingPartyEncrypting')) ) AND (IsDeleted = 0).
So I looked at the database and sure enough, there was no Relying Party cert in there. I checked another server where IFD was working and found the record with Type = 'RelyingPartyEncrypting' so it became obvious that the config had failed. Hence the crashing snap-in in Deployment Manager. So we decided to trace which that error happened and were delighted to find that error in the trace file also. We were not, however, delighted with the content of the error message:
Exception creating Certificate, Name=(CN=*.mydomain.com, OU=Domain Control Validated - RapidSSL(R), OU=See www.rapidssl.com/resources/cps (c)11, OU=XXXXXXXXXX, O=*.mydomain.com, C=US, SERIALNUMBER=xxxxxxxxxxxxxxxxxxxxxxxx-wdfpf :Exceeded column length: Column Name)
When I looked in the database at the Certificates table, the Name column where this value is bound is an nvarchar(128). Our name value for this cert is 162 characters, thanks to all the extra garbage which RapidSSL threw in there. Then I tried exactly what you would have tried ... I did the unthinkable and resized the database column to 256. No dice. Same error in the same place. I later received some information from a fellow CRM-er (pogo69) that there was also a metadata field which was being checked when Deployment Manager opens. He suggested a temporary fix for this issue until Microsoft has a chance to release a hotfix. I have tried it in my client's environment and it appears to work.
Please note that this is an unsupported change and there could be unintended consequences including causing future Rollups to fail, having future Rollups or hotfixes overwrite (reverse) this change, and causing some unrelated functionality to fail.
You would need to run this in the MSCRM_CONFIG database:
ALTER TABLE Certificates ALTER COLUMN Name NVARCHAR(256);
UPDATE
MSCRM_CONFIG.dbo.ConfigurationMetadata
SET
ConfigurationMetadataXml =
REPLACE(
CAST(ConfigurationMetadataXml AS NVARCHAR(MAX)),
'Name of the Certificate nvarchar 128 ',
'Name of the Certificate nvarchar 256 '
);Hopefully Microsoft will release a hotfix for this sometime soon. If you are having this problem, even if this above fix works for you, then please login to Connect and vote up the following 2 issues and add them to your watch list:
