Sql-server – Can’t get SQL Server 2012 RTM LocalDB working on Server 2008/x86/ SQL Server 2008 machine

The way you do this really depends on your network setup, corporate security policies, and what kind of infrastructure you have available to use.

What's worked really well for me is creating a totally separate management server on which SSMS, BIDS, etc., is installed, and all management of servers is done from there.

There are many advantages to doing this:

• Management tools are installed and configured centrally, which itself does a couple of important things:
  • Alleviates the installation of management tools on the actual production servers (SQL Server 2012 can be installed on Server Core, which makes external management a necessity). This saves your production CPU cycles, memory, and (probably) expensive storage.
  • If you retire a server, the management tools don't go down with the ship, too.
• If you need to manage multiple servers, it's the perfect place to install a CMS, and do things like centralized monitoring and logging.
• It gives you an area you can test with and not affect production. (If you blow something up, you haven't blown up production!)
• Eliminates the need to directly connect to the SQL servers from the outside (simply RDP to the management box).
• You can land the O/S on less expensive or performant storage than the production boxes, thus saving $$.

This kind of thing is super easy to set up if you have a virtualized infrastructure available to use.

Dealing with Active Directory is always so much fun. The single most important thing here is to realize you are dealing with distributed data that can take time to propagate across your network.

The SQL Servers in question had their name changed as part of an upgrade procedure; we replaced an existing machine (SQL01) running SQL Server 2005 with a new machine (SQL03) running SQL Server 2012. SQL03 was the name of the new machine when I initially set it up in the domain. SQL01 had an existing SPN associated with a single domain account we used for several SQL Servers running 2005. Since it is a best practice to only run a single machine under any given domain account, I created a new account and configured SQL03 to run with that account name. After taking the original SQL01 out of service, and renaming SQL03 to SQL01, there was an SPN conflict.

I used the SetSPN.exe utility to delete the conflicting SPN (on the old domain account) - and it still didn't work. At this point, I did nothing further and moved on to other items. When I came back around 30 minutes later, KERBEROS authentication was working. I simply needed to wait for the SPN change to propagate among our domain controllers.

I used SetSPN -L DOMAIN\Account and compared that output with SetSPN -Q MSSQLSvc/Machine.domain.inet:1433 to find the duplicate SPNs, and then used SetSPN -D MSSQLSvc/Machine.domain.inet:1433 DOMAIN\Account to remove the old SPNs.