0

I'm trying to install Dynamics CRM 2013 on a server. This server is on a VM. There are several other VMs, an ADDS & DNS, a MSSQL and a WebServer VM.

Each server is a Windows Server 2012 R2. The SQL Server is 2012 Enterprise.

Each VM is part of the main Domain, set by the ADDS & DNS. NSLookup confirms I can see the computer at the right IP address.

Each separate VM has its own static IP, the DNS is set to the ADDS & DNS. I use the domain administrator to log into all the servers, and make the that domain administrator a local administrator.

I've set up all the domain users for the CRM and gave them appropriate permissions, I have also added the accounts to the appropriate places, such that the CRM Deployment user is in the SQL security.

The SQL Agent is running. SQL server configuration manager has SQL server network configuration TCP/IP enabled to allow remote connections. The SQL server has the domain user as a administrator, which is the same user being used to install the CRM.

In the CRM setup i point to the [Servername]\[Instance] and I have also tried just the [Servername]. to make this easier I called the server MSSQL and left the instance name to the default. I even install the MSSQL instance as the domain administrator.

CRM can find the ReportServer url. I have enable all the ports required, including: 135, 1433, 1434, 2382, 2383, 4022. 1434 UDP.

I feel like I have absolutely done everything, I have google many times and tried all the different methods, and for the life of me I cant seem to get the CRM setup to find the SQL server agent. It passes everything else perfectly fine. I can even ping the MSSQL server.

What is the problem, why does the CRM still keep giving the error:

SQLSERVERAGENT (SQLSERVERAGENT) service is not running on the server MSSQL

On the MSSQL server, the name of the sql server agent service is:

SQL Server Agent (MSSQLSERVER)
Arun Vinoth-Precog Tech - MVP
  • 314
  • 1
  • 3
  • 15
Callum Linington
  • 143
  • 2
  • 8

2 Answers2

1

I needed to have opened port 445 on the MSSQL server machine. That was all....

Callum Linington
  • 143
  • 2
  • 8
-1

We had something very similar...except opening the ports, ensuring permissions and other advised steps did not help. The error still persisted.

By pure chance - we stumbled across the file shares not being accessible. By allowing "File and Printer Sharing for Microsoft Networks" on the SQL server's LAN connection, we were able to solve the problem.

I am including this here purely as reference for the above solution... as we were unable to solve the problem via search engines/forums/q & a sites etc.

Jarfish
  • 1
  • 1