Security and the User Context

To install SQL Server on a machine, you need not be an administrator of the domain, but you must have administrator privileges on the machine. Users can install most of the SQL Server client utilities without administrator privileges.

Before you set up your system, give some thought to the user context in which SQL Server and SQL Server Agent will run. A new SQL Server environment can set up the SQL Server engine to run in the context of the special system (LocalSystem) account. This account is typically used to run services, but it has no privileges on other machines, nor can it be granted such privileges. Because LocalSystem is always present, Setup can reliably use it. However, the default is to have the SQL Server service and the SQL Server Agent service run in the context of the domain Administrator account. This allows SQL Server to more easily perform tasks that require an external security context, such as backing up to another machine or using replication. If you don't have access to the domain Administrator account, you might want to set up SQL Server to run in the context of a local Administrator. This will still give SQL Server sufficient privileges to run on the local machine.

If you're not going to use the LocalSystem account, it's a good idea to change the account under which SQL Server runs to a user account that you have created just for this purpose, rather than use the actual local or domain Administrator account. The account must be in the local Administrators group if you are installing on Windows NT. You can create this account before you begin installing SQL Server, or you can change the account under which SQL Server runs at a later time. Changing the account is easy: you use the Services applet in the Windows NT Control Panel. When you choose or create a user account for running SQL Server, choose the Password Never Expires option for that account in Windows NT User Manager; if the password expires , SQL Server won't start until the information in the Services applet is updated. (This is why we don't recommend using the real Administrator account for SQL Server; that account will probably have its password changed regularly.)

If you will use the mail integration features (SQLMail), you should be aware of one additional issue: if you are using Microsoft Exchange on the same machine as SQL Server, you should run SQL Server in the context of the user account for which your Exchange client is configured. SQL Server can then pick up the Exchange configuration for that user automatically.

By default, the installation program chooses to use the same account for both the SQL Server and the SQL Server Agent services. However, you can override this account sharing during or after installation using the Services applet in Control Panel. SQL Server Agent needs a domain-level security context to connect to other computers in more situations than does SQL Server. For example, if you plan to publish data for replication, SQL Server Agent needs a security context to connect to the subscribing machines. If you will not publish data for replication or schedule tasks on SQL Server that require access to other computers, you can have SQL Server Agent run in the LocalSystem account. If you specify a domain account but the domain controller cannot validate the account (perhaps because the domain controller is temporarily unavailable), go ahead and install using the LocalSystem account and change it later using the Services applet or from SQL Server Enterprise Manager.