Tonight, I was preparing a Hyper-V image running Windows Server 2012 R2, SQL Server 2014 and Dynamics CRM 2015 to investigate a problem we ran into the other day. The problem we were facing was described in an earlier article “Developer 101: Help! My managed solution cannot be uninstalled…”.
Instead of having a butter smooth installation it looked like Murphy’s law came back to life with a vengeance.
The installation of Windows 2012r2 was a breeze. Once installed I added domain services (as I want to run the image in it’s own domain), application services, internet services and .Net 3.5 support. A little configuration and a couple of reboots later I was running my own domain.
From there on I started with a fresh installation of SQL Server 2014. This is where all hell broke loose.
In the installation I choose for a typical scenario: Database Engine Services, Integration Services, Reporting Services, Management Studio. I specified the data location, the administrative account. Chose for mixed authentication mode (enabling the good old SA account which turned out to be my rescue). The installation started and everything seemed to go smoothly.
The SQL Server 2014 installer finished with the error message “Could not find the Database Engine startup handle”. *Yikes*
I tried to repair the installation, but no luck. I deinstalled SQL Server, rebooted and started the installation once again.
The result, another “Could not find the Database Engine startup handle”.
Internet provided me the answer. On the website http://kalcik.net/2014/04/04/problems-with-the-installation-of-sql-server-2014-after-the-windows-8-1-update/, I found an instruction to change the credentials the SQL Server Service is using, to use the built-in network service account.
Changing to this account, I was finally able to start SQL Server. Then I fired up SQL Server Management Studio and tried to connect to SQL Server. All accounts I specified before were not able to logon. *HUH?*
Something else went wrong in the finalizations steps of the installation. I did another search on the internet and stumbled upon an article on the technet site. http://blogs.technet.com/b/meamcs/archive/2011/12/02/cannot-login-to-sql-server-using-administrator-account.aspx
Following the steps:
Stop SQL Service: on the command line type: net stop MSSQLServer
Start the SQL Server in Management mode: on the command line type: net start MSSQLServer /m
Open the SQL Server management studio, cancel the login dialog
Open new sql server engine query window: from the menu, Click file->new->Database engine query
Enable SA account if not enabled: in the query window type: Alter login sa enable
Set the password of the sa account: alter login sa with password=’my password’
Stop the SQL server from the command line: net stop MSSQlServer
Start SQL Service from the command line: net start mssqlserver
Start the SQL Management studio and connect to the server using sa account
Add you domain administrator as sysadmin
I was able to gain full access and control over SQL Server. Murphy seemed to be defeated…
Once SQL Server was installed I turned to the Reporting Server Configuration tool, in order to configure reporting. Once done it was time to install CRM 2015.
I installed the prerequisites for CRM 2015, and proceeded to the next step. CRM started a preflight check which resulted in two exceptions:
The SQL Server instance name must be the same as the name of the server.
Luckily David Jennaway, tackled this error on his blog.
Start SQL Management Studio to execute the following query:
This will return output like the following:
ORGNAME,ORIGNAME,rpc,rpc out,use remote collation,0,null,0,0
If the value in the name column does not match the current computer name, then you have to use the following SQL stored procedures to fix the problem. Note that sp_helpserver normally returns one record, but can return more records if you have configured linked servers. If this is the case, it is the row with id=0 that matters.
To change the information you have to first remove the incorrect record, then add the correct one, with the following queries:
sp_dropserver ‘ORIGNAME’ – where ORIGNAME is the name returned by sp_helpserver
sp_addserver ‘CURRENTNAME’, ‘LOCAL’ -– where CURRENTNAME is the current computer name
Once done, restart the SQL Server Service and you are ready to go.
SQL Server Reporting services cannot be accessed
This thread on the Dynamics Community forums provided me with the answer I wanted to hear.
open up the Reporting Server Configuration Manager and choose a network account as service account.
Once done, the preflight check passed and I was able to finish my installation without any further glitch.
Sometimes, Murphy is still around… *Sigh*