Like many services, SQL Server and the SQL Server Agent can run in a variety of account contexts. By default, both SQL Server and the Agent are installed in the Local System Account context. However, Microsoft notes in one of its own discussions that the Local System Account is provided for backward compatibility only, and it has privileges that SQL Server Agent (and perhaps SQL Server itself) does not require.
For that reason, many security-conscious administrators elect to run SQL Server and SQL Server Agent in a reduced-privilege context. Unfortunately, they sometimes choose a context that's too restricted, especially if SQL Server or the Agent needs to make network connections to or from another host (such as a database server). An account that's too restrictive will prevent SQL Server from accessing the network at all and may make it almost unusable. This applies to both TCP/IP and Named Pipes protocols, since Named Pipes uses the protected IPC$ network share resources.
If you recently changed credentials for SQL Server and have trouble getting the service to authenticate network connections, start checking account permissions. Microsoft recommends creating a domain user account that has no administrative rights but can access the network. If you switched SQL Server to a domain user account, but didn't grant that account type access to the network as an inherited privilege, make sure you explicitly grant that permission and see what happens. (The only other caveat with using a domain account is that the account has to be authenticated on a domain controller.)
About the author: Serdar Yegulalp is editor of the Windows Power Users Newsletter. Check it out for the latest advice and musings on the world of Windows network administrators -- and please share your thoughts as well!
More information from SearchSQLServer.com
Tip: Setting up SQL Server clusters on a SAN
Undocumented DBCC: Report on settings with DBCC RESOURCE>
Stored procedure: Examining SQL Agent job run history
