Event ID 103 Source SQLSERVERAGENT
| Event ID | 103 |
| Source | SQLSERVERAGENT |
| Type | Error |
| Description | SQLServerAgent could not be started (reason: Unable to connect to server "(local)"; SQLServerAgent cannot start). |
| English, please! | Request a translation of the event description in plain English. |
| Comments |
Adrian Grigorof
(Last update 9/22/2003): The first thing to verify for this event is that the SQL Server service is running as the SQLSERVERAGENT service depends on it. If the SQL Server service is not started, troubleshoot that problem first. From a newsgroup post: "Please check the following registry key. HKLM\Software\ODBC\ODBCINST.INI\SQL Server\Driver It should be pointing to c:\winnt\system32\SQLSRV32.dll. When the above registry key is not present or if the value is not pointing to the SQL server driver, you will see the error message. If the registry key is not present, please add a new String Key with the name 'Driver' and the value 'c:\winnt\system32\sqlsrv32.dll' or the appropriate location. If the value is pointing to a wrong location, update it correctly and make sure the driver exists at the location you have specified for the value. If it doesn't work, please reapply the MDAC to solve the problem." From a newsgroup post: "Check the sqlagent.out file in the sql 'log' directory. It will have some more information about why it is failing." Jeff Hatzinger (Last update 7/9/2007): A DBA discovered this problem on one of our SQL 2000 systems after we started removing NetBIOS from the network bindings. I was able to get the service to start if I opened Enterprise Manager, right-clicked the SQL Server Agent object underneath Management, and in the SQL Server Alias section, changed the default setting (default) to one of the connections aliases that I set up in the Client Network Utility. Once I saw that worked, I went back into the WINS tab for the network connection, and bound NetBIOS back to this connection. I was then able to set the SQL Server alias back to its default (default), rebooted, and everything was fine. The lack of NetBIOS appears to (potentially) cause this problem as well. Karstenenh (Last update 4/14/2005): Check whether the account that runs the SQL Server itself is local administrator on the machine or that it has appropriate rights. It is possible to run the SQL Server underprivileged, but in this case windows authentication will not work at all even if it is set in the security properties of the server. This scenario will result in a situation where the SQLSERVERAGENT will only run using SQL Server authentication. Ionut Marin (Last update 7/16/2004): As per Microsoft: "The BUILTIN\Administrators login does not have access to SQL Server or the BUILTIN\Administrators login has been removed from SQL Server, and the SQLAgent service is starting under the LocalSystem account. The issue does not occur if the SQLAgent service is starting under a domain or computer account that is listed separately in SQL Server Enterprise Manager and that has System Administrators (sysadmin) privileges". See M237604 for a workaround. From a newsgroup post: "It appears that the SQL Server service fails to start on the other node. SQL Server Agent depends on SQL Server Service. Since SQL Server is failing, SQL Server Agent will fail too. To find why SQL Server failed, please review the SQL Server Error logs. The reason, the group fails over to the other node is that by the cluster service will try to start the SQL server service 3 times. If it fails 3 times in the default time (900s), the group is failed to other node. If you do not want the failure of a resource to affect the group, you can right click the resource and select properties, click Advanced and uncheck "Affect the group". Also, to find the actual service that is failing do the following: 1) Right click the SQL group and bring it offline. 2) Move the group to other node (where resources fail). 3) Now start bringing resources online (one at a time). Start with disk/s, followed by IP, followed by network name then SQL Server, followed by SQL Server Agent. From the errors, you will find that the SQL Server will fail to come online. Also, for this test, uncheck "affect the group" for SQL Server resource. If you don’t do this, then it will try to come online 3 times and if it fails all 3 times, it will affect the group and fail the whole group to previous node. Once you know that SQL Server service failed to come online. Review the SQL Server error logs to get detailed information. If SQL Server service comes online, then start SQL Server Agent resource. If it fails, review the SQL Server Agent logs (located in the LOG folder - same place where the SQL error logs are located)". From a newsgroup post: "If you also receive event id 17055 with the following description: "The maximum limit for connections has been reached", then you should try the following: Start the SQL server in single user mode. To do this, go to control panel, services. Stop the server and before you restart it, type “-m” in the startup parameters and see if you can get in that way. See if you can check the connections property of the server. It if has been set to a static number, try changing that to a dynamic setting". David Hewison (Last update 11/22/2003): A workaround is to change the Agent authentication method to Windows Authentication from SQL Authentication. See M320338 for more details. Why bother deciphering Event logs when GFI EventsManager can do everything for you? Free trial here! |
| Links | M237604, M320338, Download latest MDAC |
| Search | Google Web - Microsoft Support - Bing - EventID.Net Queue - More links... |
| Feedback | Send comments - Notify me when updated |
| Print version |