Although I used an unattended setup file, I still chose to step through each of the setup screens and run the Environment Diagnostics Wizard (EDW). Everything checked out OK so I proceeded. Everything seemed to be going well, until I hit the following error:
“Action Microsoft.Crm.Setup.Server.CreateSetupUserAction failed. Exception from HRESULT: 0x80048306.”
It took me a while to figure out that this might be a security-related issue, so I took a guess and added my User Account to the “CRMPrivUserGroup” and “CRMSQLAccessGroup” groups. After cleaining up the remenants of the first installation, I retried the installation and everything went as planned.
Now to the configuration issue that seems to be causing the most confusion out there – DELEGATION
Microsoft CRM 3.0 makes use of impersonation and delegation, allowing the CRM Application Server to delegate user credentials through to the Database and Report Servers. When a user on Client Machine A authenticates with the CRM Application Server on Machine B, they prove that they know a secret associated with their User Account (typically a password). However, the user doesn’t tell machine B what the password is. In normal circumstances, machine B has no way of proving to the SQL Server on Machine C that it really does have a valid logon for the client, but C needs proof. This is why we need impersonation and delegation.
There is a great article which explains this step-by-step, available in the September 2005 issue of MSDN Magazine, which I recommend you take the time to read: http://msdn.microsoft.com/msdnmag/issues/05/09/SecurityBriefs/default.aspx. All clear??? Good, so now all I have to do is figure out what delegation settings I need to request Microsoft IT to configure – remember I don’t have AD administration rights.
Firstly, I needed to make sure I have the correct Service Principle Names (SPNs) set up on the correct AD objects. Because I am running the SQL Server, the CRM Web Server and the SRS Web Server using the Network Service credential, then I must set the SPNs the relevant computer accounts (Network Service uses the machine account to access resources). Using the SETSP.EXE tool that comes with the Windows Server 2003 Support Tools, I ran the following commands (domain names have been changed to protect the innocent):
- SETSPN -A MSSQLSvc/SQL01:1433 DOMAIN\SQL01
- SETSPN -A MSSQLSvc/SQL01.domain.com:1433 DOMAIN\SQL01
- SETSPN -A HTTP/RPT01 DOMAIN\RPT01
- SETSPN -A HTTP/RPT01.domain.com DOMAIN\RPT01
- SETSPN -A HTTP/CRM01 DOMAIN\CRM01
- SETSPN -A HTTP/CRM01.domain.com DOMAIN\CRM01
That’s taken care of the SPNs, now I needed to request Microsoft IT to set up the following constrained delegations:
On Machine Account CRM01:
On Machine Account RPT01:
Suddenly, everything in the world is goodness and I have access to the reports which were missing before.
To be continued…
This posting is provided “AS IS” with no warranties, and confers no rights.