locked
CRM 2011 SQL Server Alias RRS feed

  • Question

  • Hi folks

    I am installing CRM 2011 On-Premise and my client would like to use a SQL server alias. This flatly fails as the installer cannot see the SQL Server and so never gets past the checks page.

    Has anybody got this to work? Is this even supported ? (I suspect that the answer is no)

    I would really appreciate it if anybody has any info on this subject

    Thanks

    Alan

     

     


    Alan Ashton
    Wednesday, July 13, 2011 3:44 PM

Answers

  • I've not seen official documentation that states this in unsupported, but it won't work. The fundamental reason it fails is because the CRM setup program checks the given SQL Server name against the sysservers table. I could also imagine subsequent problems with SPNs.

    Why do they want to use a SQL Server alias ? I've yet to find a good reason for doing so


    Microsoft CRM MVP - http://mscrmuk.blogspot.com  http://www.excitation.co.uk
     
    Friday, July 15, 2011 1:47 PM
    Moderator

All replies

  • I've not seen official documentation that states this in unsupported, but it won't work. The fundamental reason it fails is because the CRM setup program checks the given SQL Server name against the sysservers table. I could also imagine subsequent problems with SPNs.

    Why do they want to use a SQL Server alias ? I've yet to find a good reason for doing so


    Microsoft CRM MVP - http://mscrmuk.blogspot.com  http://www.excitation.co.uk
     
    Friday, July 15, 2011 1:47 PM
    Moderator
  • Yes I agree. There is some thought that they could change the SQL server at some point without having to reconfigure crm. I have pointed out that to reconfigure crm is not a big issue.

    Thanks for the input

     


    Alan Ashton
    Wednesday, July 20, 2011 3:35 PM
  • (hoping not to derail this thread)

    SQL Server aliases give you flexibility when there is a required change in environment. For example, lets assume you have an instance dedicated to CRM on a server, SQL01\CRMInstance. Due to usage on the SQL01 server, it is decided to move the instance to a newer cluster with dedicated hardware, SQL02\SecondInstance.

    This is a fairly routine SQL management example but if you were using SQL aliases you could just migrated the sql databases across, change the SQL server alias, and you're done. If you have "hard-coded" the alias in to the CRM configuration, then CRM also needs to be reconfigured. This might be easy to do, but it is extra effort required by the CRM admins as well as the SQL admins, when it could be just a straight-forward change. You could use straight DNS to achieve a similar result, but DNS doesn't know about SQL instances so you need to keep the SQL instances the same, even though you can change the server name.

    Extrapolate that out to "OMG we've lost the whole cluster!". You can restore your data to a second SQL cluster, change the alias, and you're up and running again. That may not seem like much if just change the Dynamics CRM config, but if you have multiple Dynamics installs and additional applications using the same instance, that is a lot of extra configuration to have to do.

    Not sure about SPN issues - under the hood the SQL Native Client is converting the call for "my-alias" to "SQL01\CRMInstance", so the SPN should be passed across correctly as it is lower in the TCP/IP stack. This is a guess though, would need to be confirmed by an SPN-expert (which isn't me ;)

    Sunday, August 28, 2011 11:52 PM