Deploying and configuring a Notification Services instance involves several steps:
Creating the instance and application databases
Installing the Windows Service, registry keys, and performance counters for the instance
Granting the appropriate access permissions to the databases
Notification Services provides a command-line utility called nscontrol for performing the first two of these steps. The third step can be done using the standard SQL Server tools.
The following sections show how to execute these steps. A key decision in deploying a Notification Services instance is whether or not to use Windows integrated security or SQL Server Authentication. This decision affects how the nscontrol utility logs in to the database, as well as how the Windows Service and the subscription management application log in to the database when the application runs. Notification Services supports both authentication modes, although Microsoft recommends using Windows integrated security. The sections that follow will describe the use of both authentication modes.
To create the instance and application databases, pass the instance configuration file to the nscontrol create command. The syntax of the command is
nscontrol create [-nologo] [-help] -in <configFile> [-sqlusername <sqlUserName> -sqlpassword <sqlPassword>] [-argumentkey <key>] [param=value ...]
The Notification Services Books Online file provides a detailed description of all the command options. The following is a typical example of an invocation of nscontrol create:
nscontrol create ?in C:\MyInstance\MyInstanceConfig.xml
The important point to note here is that the name of the configuration file (including the full path, if the file is not in the directory from which the command is run) is passed in the -in argument. The name of the database server is specified in the configuration file itself.
This command will parse the configuration file, as well as the ADF files it refers to, and create the instance and application databases. If you wish to use SQL Server Authentication to log in to the SQL Server to create the databases, provide a SQL user name and password in the -sqlusername and -sqlpassword arguments to nscontrol create. If you do not use these arguments, nscontrol create connects to the database using Windows integrated security, with the credentials of the user running the command.
The user under whose identity nscontrol create logs in to the database (either the user running the command if using Windows integrated security, or the specified SQL user if using SQL Server Authentication) must have permission to create databases. This requires the user to be a member of the dbcreator and sysadmin fixed server roles.
If nscontrol create executes successfully, you will see new databases on your SQL Server. There will be one database for the instance, named <InstanceName>NSMain, where <InstanceName> is the name of the instance. For example, the instance database for an instance named MyInstance will be called MyInstanceNSMain. In addition to the instance database, there will be an application database for each application declared in the configuration file. The application database will be named <InstanceName><ApplicationName>, where <InstanceName> is the name of the instance, and <ApplicationName> is the name of the application. For example, the application database for an application named StockAlerts in the MyInstance instance will be called MyInstanceStockAlerts.
After creating the instance and application databases, the next step is to register the instance. Registration installs the Windows Service, registry keys, and performance counters associated with the instance. Registration is performed via the nscontrol register command.
If your instance is distributed across several different computers for scale-out reasons, you will need to perform the registration step on each of the computers that will run the Windows Service.
The syntax of the nscontrol register command is
nscontrol register [-nologo] [-help] -name <instanceName> [-server <databaseServer>] [-service [-serviceusername <NSServiceUserName> -servicepassword <NSServicePwd>] [-sqlusername <sqlUserName> -sqlpassword <sqlPassword>] [-argumentkey <key>]]
The Notification Services Books Online file provides a detailed description of all the command options. The following is a typical example of an invocation of nscontrol register:
nscontrol register ?name MyInstance ?server MyDBServer -service ?serviceusername MYDOMAIN\MyUser ?servicepassword MyPassword
Table 45.1 lists the various arguments used in this sample invocation and their meanings.
Argument Name | Meaning |
---|---|
-name | Name of the instance being registered |
-server | Name of the database server for the instance |
-service | Instructs the command to install the Windows Service for the instance |
-serviceusername | Windows username under which the Windows Service should run |
-servicepassword | Password for the username specified in the -serviceusername argument |
The nscontrol register command installs the service and stores the name of the database server for the instance in the registry. When the Windows Service starts, it reads this server name from the registry and uses it to connect to the instance and application databases.
If you wish to have the Windows Service connect to the database server using SQL Server Authentication, specify -sqlusername and -sqlpassword arguments to the nscontrol register command. If specified, the values of these arguments are also stored in the registry, but are encrypted so that they cannot be freely read. If you do not specify -sqlusername and -sqlpassword arguments to the command, the Windows Service will be configured to log in to the database using Windows integrated security, with the credentials of the user account under which the service runs. This user account is specified by means of the -serviceusername and -servicepassword arguments.
Microsoft recommends that you configure the Windows Service to run under a weak (non-Administrator) domain account, and use Windows integrated security to log in to the database.
Access to the instance and application databases in Notification Services is granted via roles. Notification Services defines a set of roles, and the various elements of the databases (tables, views, stored procedures, and functions) are set up in such a way that only members of the appropriate roles can access them. Notification Services defines separate roles for each of the functions that needs to be performed in relation to a Notification Services instance (for example, event collection, generation, distribution, subscriber and subscription management, and administration). These functions can each be run under different user accounts, and each of these user accounts need only be a member of the roles required for its function. You can therefore grant a particular account only the minimum permissions it needs to perform its tasks.
Table 45.2 lists the various database roles that Notification Services defines.
Role Name | Allowed Operations |
---|---|
NSAnalysis | Executing reporting stored procedures |
NSAdmin | Enabling and disabling components via nscontrol enable and disable |
NSDistributor | Performing distributor functions |
NSEventProvider | Performing event provider functions |
NSGenerator | Performing generator functions |
NSMonitor | Executing stored procedures that collect data used to update the Notification Services performance counters |
NSReader | Reading information from the configuration tables in the instance and application databases |
NSRunService | All operations allowed by the NSDistributor, NSEventProvider, NSGenerator, NSMonitor, NSReader, and NSVacuum roles |
NSSubscriberAdmin | Performing subscriber and subscription management functions |
NSVacuum | Removal of old data from the Notification Services tables |
If you are running all the components of the Notification Services Windows Service (event providers, generator, and distributor) on the same computer, you can simply add the service account to the NSRunService role. Note that if you're using Windows integrated security, the service account is the Windows account under which the service runs; if you're using SQL Server Authentication, the service account is the SQL user whose credentials you passed to the nscontrol register command when registering the instance.
If you have deployed the various Notification Services components on separate computers for scale-out, you can configure the Windows Service on each of these computers to run under a different account. You can then add these accounts to the various roles (NSEventProvider, NSDistributor, NSGenerator, and so on) separately, as needed. This ensures that each account has only the permissions it needs to perform its designated functions.
The user account under which your subscription management application runs needs to be added to the NSSubscriberAdmin role. This account will vary depending on the nature of your subscription management application. If it is an ASP.NET Web application, the user account may be the local ASP.NET account on your Web server computer.
There are two steps in granting database permissions to a user account:
Granting database access to the account
Adding the account to the required database roles
You can perform both of these steps graphically through Enterprise Manager, or by invoking system-stored procedures. To grant database access, invoke the sp_grantdbaccess stored procedure. Note that you must grant access to the instance database and all the application databases that the user account needs to access. To add an account to a role, invoke the sp_addrolemember stored procedure. Stored procedures are fully documented in SQL Server 2000 Books Online.