Configuring Windows Accounts for an Instance of Notification Services

The Notification Services engine is key to Notification Services operation. This engine runs the hosted event providers, generator, and distributors used to submit events, generate notifications, and distribute the resulting messages. The engine is typically run by the NS$instanceName Microsoft Windows service but can also be hosted by another application or process.

The engine runs in the context of a Windows account. If using the NS$intanceName Windows service, you specify the account that the service runs under when you register the instance of Notification Services. If you are hosting the engine in another application or process, you must configure Windows permissions for the application or process.

Windows Permissions Required by the Engine

The account under which the engine runs must have the following permissions:

• Read and execute permissions in the Notification Services folder (%ProgramFiles%\Microsoft SQL Server\90\NotificationServices\n.n.nnn) and subfolders. By default, only members of the local Administrators and Power Users groups have access to the files within these folders. Notification Services grants these permissions when you register the instance by adding the service account to the Windows SQLServer2005NotificationServicesUser$ComputerName group.
• Permission to read and write registry keys at the following registry locations: HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\Services\NotificationServices and HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services. This permission is granted to the Windows service account when you create the service while registering the instance.
• Permission to write to the Windows application log.
• For applications using a file system watcher event provider, the event provider must be able to read and rename files in the folder where events are dropped, and must have read access to the event schema file (.xsd).
• For applications using a file delivery protocol to post notifications, the distributor must have write permissions in the folder where the notifications are written.
• For applications using the XSLT content formatter, the distributor must have permission to read the folders that contain the XSLT files. For more information, see XSLT File Locations.

In addition, the engine account may require membership in the local Administrators group. If an application hosted by the instance uses the local Internet Information Services (IIS) Simple Mail Transfer Protocol (SMTP) service to send notifications, the distributor must send those notifications in the context of an administrator.

Windows Service Account Types

If the engine for your instance of Notification Services is not hosted in a separate application or process, the instance runs as a Windows service. A Windows service can run under the following account types, although some are more difficult to manage, and their use is therefore discouraged:

• A domain user account. A domain account makes it easier to control access to network resources and to databases, because you can specify the exact permissions the account should have. For optimal control of permissions granted to the service, the domain administrator can create a new account for the instance of Notification Services.
• A local user account. You can create a user account on the local computer and run the NS$intanceName service under that account. The account uses the format computer\username. If the databases are on the same server, you can also grant database permissions to this user account. If the databases are on a remote computer, you must configure a SQL Server login account for the instance of Notification Services.
• The NT AUTHORITY\Local Service account. This is a built-in account that is available in Microsoft Windows XP and Microsoft Windows Server 2003. The Local Service account has the same level of access to resources and objects as members of the Users group; it accesses network resources as a null session with no credentials. If the databases are on the same server, you can grant database permissions to this account. However, Microsoft discourages using the Local Service account for the NS$intanceName service. Multiple services can use this account, so it is difficult to control which services have access to SQL Server databases.
• The NT AUTHORITY\Network Service account. This is a built-in account that is available in Windows XP and Windows Server 2003. Microsoft discourages using the Network Service account for the NS$intanceName service. All services running under the Network Service account are mapped to the domain\remotecomputername$ account when accessing network resources. Because multiple services can use this account, it is difficult to control which services have access to network resources and to SQL Server databases.
• The Local System account. This is a built-in account. Microsoft strongly discourages using the Local System account for the NS$intanceName service because this account has unrestricted access to all local resources. Also, all services running under the Local System account are mapped to the domain\remotecomputername$ account when accessing network resources. Because multiple services can use this account, it difficult to control which services have access to network resources and to SQL Server databases.

Specifying the Account for the Windows Service

You set the Windows account for the NS$intanceName Windows service when you create the service. You create the service when you register the instance. You can update the account by reregistering the instance or by changing the account in the Windows Services Manager.

• How to: Register an Instance of Notification Services for Engine Components (SQL Server Management Studio)
• nscontrol register Command
• RegisterLocal

See Also

Concepts

Hosting the Notification Services Engine
Configuring Notification Services Windows Services
Configuring SQL Server Permissions for an Instance of Notification Services

Other Resources

Setting Up Windows Service Accounts

Help and Information

Getting SQL Server 2005 Assistance

Change History