Export (0) Print
Expand All
Creating Audit Tables, Invoking COM Objects, and More
Exception-handling Techniques
Exploring SQL Server Triggers: Part 2
Deliver User-Friendly Reports from Your Application with SQL Server Reporting Services
SQL Server: Display Your Data Your Way with Custom Renderers for Reporting Services
Updating Data in Linked Servers, Information Schema Views, and More
XML Features in SQL Server 2000
Expand Minimize

Deployment Considerations for the Voicemail .NET Alerts Quick Start Kit on Notification Services

SQL Server 2000
 

Christa Carpentiere
Microsoft Corporation

August 2003

Applies to:
    Microsoft® SQL Server™ Notification Services

Summary: This article describes three common deployment options used with the Voicemail .NET Alerts quick start kit, which is developed using Microsoft SQL Server Notification Services. You'll learn about the configuration details associated with each deployment option, as well as Notification Services architecture basics and security considerations. By the end of the article, you should be able to identify the appropriate deployment option for your environment, and be familiar with the requirements for that configuration. (23 printed pages)

Contents

Introduction
Notification Services Application Components
Voicemail .NET Alerts Quick Start Kit Components
Notification Services Scaling Models
Pilot Project Configuration
Production Configuration
High-Availability Configuration
Subscription Management Application Access
Security Considerations
Hardware Considerations
Application Setting Considerations
Appendix

Introduction

There are three common application configurations for the Voicemail .NET Alerts quick start kit developed on Microsoft® SQL Server™ Notification Services:

  • Pilot project configuration
  • Production configuration
  • High-availability configuration

Each deployment configuration has particular requirements, as well as strengths and limitations. This MSDN® technical article reviews these issues and provides approximate performance numbers for each configuration.

Notification Services is a platform for developing and deploying a class of scalable applications that can generate and deliver personalized, timely information updates to a variety of connected and mobile devices. For more information on Notification Services, refer to the appendix.

The Voicemail .NET Alerts quick start kit provides working source code for a production-ready application. The quick start kit demonstrates the use of Notification Services Enterprise Edition, .NET Passport, and .NET Alerts in a real-world telecommunications scenario. All features and functionality for this application are available as source code using C# and the Microsoft .NET Framework. For more information on the Voicemail .NET Alerts quick start kit, refer to the appendix.

This article provides the requirements, as well as the benefits and limitations, of these three configurations to help you to plan for a deployment of the quick start kit in your own environment, as well as providing useful information about Notification Services deployments. There is also an article appendix that provides additional information and materials that can be helpful in planning such a deployment.

Who Should Read This Document?

This document addresses the needs of systems architects, chief technology officers, and any others who must plan for the implementation and deployment of information technology.

Notification Services Application Components

A Notification Services application has five primary components:

  • The subscription management application, which submits subscriber and subscription information to the system.
  • The event provider, which submits event data to the system. You can have multiple event providers for an application.
  • The generator, which matches event and subscription data to create notifications. You can have only one generator for an application.
  • The distributor, which formats the notifications and hands them off to a delivery system. You can have multiple distributors for an application.
  • The instance and application databases, which store application data.

The Notification Services engine consists of the generator, the distributor, and the provider host, which can optionally be used to host compliant event providers. Notification Services ships with two hosted event providers that allow event submission, either by reading XML event data files or by calling SQL Server stored procedures. The Notification Services engine runs as a Windows service.

There are four workflow stages of a Notification Services application (see Figure 1):

  • Stage 1: Information about subscribers, subscriber devices, and subscriptions comes into the system through a subscription management application, which uses the Notification Services API to submit this information.
  • Stage 2: Events are submitted to the system in batches by an event provider, which is optionally hosted in process by the Notification Services provider host. Events can also be submitted using an independent (non-hosted) event provider, which runs out of process and, therefore, is not scheduled by Notification Services.
  • Stage 3: The Notification Services generator uses Transact-SQL rules to match events with subscriptions. Each firing of a rule produces a batch of notifications.
  • Stage 4: The Notification Services distributor passes the raw notification data to a content formatter to be formatted, and then passes the formatted notification data to a delivery protocol to be packaged into messages. Finally the messages are handed off to one or more external delivery systems for delivery to subscriber devices.

Aa902679.sql_ns_deployment01(en-us,SQL.80).gif

Figure 1. SQL Server Notification Services workflow

NSControl Commands for Deployment

NSControl is a command prompt utility for administering Notification Services. It provides commands for deploying, configuring, monitoring, and controlling Notification Services instances and applications.

There are three NSControl commands that are most commonly used with deployment:

  • NSControl Create: Creates the instance and application databases.
  • NSControl Register: Registers a Notification Services instance. It can optionally create the Windows service that provides the Notification Services engine as well, by using the -service argument when using this command.
  • NSControl Update: Updates existing instance and application databases to reflect changes to the application.

For more information, see "NSControl Commands" in SQL Server Notification Services Books Online.

Voicemail .NET Alerts Quick Start Kit Components

The Notification Services application provided by the quick start kit has the following specifications:

  • One Notification Services instance.
  • One Notification Services application, hosted by the instance.
  • A subscription management application with a Web user interface.
  • One independent event provider. Because it is an independent event provider, it requires the Notification Services API to submit events, but it does not require the Notification Services engine to be running on the server where these API calls are made (the Web service host). The Notification Services API uses ADO.NET to communicate with SQL Server and submit events.

    This event provider receives incoming events via a Web service. Using a Web services interface makes it easy to enable a wide array of event sources to raise events that in turn are processed by the Notification Services application.

  • One distributor.
  • Formatting using the standard XSLT content formatter.
  • Notification delivery via the .NET Alerts Web service. (The .NET Alerts SDK provides integration to this service.)

Notification Services Scaling Models

Notification Services supports both scale-up and scale-out scaling models.

Scale-Up

Notification Services has been architected to allow multithreading for notification generation, formatting, and distribution. You can add processors and memory to a single server to allow for greater size or speed in a Notification Services application. You can use application settings to determine how your application uses the multithreading capabilities of Notification Services, in order to balance system resource consumption against application throughput in a way that is optimal for your environment. For more information on optimizing application settings, see Application Setting Considerations in this article.

Scale-Out

The Notification Services scaling model allows for two types of scale-out. The first type of scale-out allows you to place the Notification Services engine, databases, and subscription management application on different servers in order to distribute the workload.

Aa902679.sql_ns_deployment02(en-us,SQL.80).gif

Figure 2. Scaling out the engine, databases, and subscription management application

The second type of scale-out allows you to break out the generator, the event providers, and the distributors onto separate servers. Each server in the configuration can host one or several of these components. For example, you could have the generator on one server, and a distributor and an event provider on another. Or you could have the generator on one server, two distributors on two other servers, and an event provider on yet another. You can always add servers to take on additional event providers or distributors if your application needs room to grow.

Note   You do not have to specify information about the location of the Notification Services engine elements when creating and registering an instance. This information is already available to the instance through settings in the application definition file (ADF), a metadata file that specifies the structure and settings for the application.

The generator is lightweight; its primary function is to call stored procedures in the databases in order to trigger rule execution. Because of this, as well as to avoid network traffic, the generator is sometimes installed on the same server as the databases. One scale-out configuration option is to have a Web server for the subscription management application, a server with Notification Services and SQL Server to host the databases and the generator, and one or more additional servers to host the event providers and distributors for the application, as illustrated in Figure 3.

Aa902679.sql_ns_deployment03(en-us,SQL.80).gif

Figure 3. Scaling out the Notification Services engine

Note   Scale-out functionality is only available in Notification Services Enterprise Edition.

Pilot Project Configuration

The pilot project configuration involves a single server, which runs all of the Notification Services application components.

The typical business scenarios for using the pilot project deployment are:

  • Developing the application and performing quality assurance.
  • Implementing a pilot project or providing a beta testing environment.
  • Providing a production environment for a small or limited-use notification application.

Figure 4 illustrates the pilot project configuration.

Aa902679.sql_ns_deployment04(en-us,SQL.80).gif

Figure 4. Pilot project configuration

Benefits

The pilot project configuration offers three significant benefits. It is easy to plan and deploy; it creates low administrative overhead; and there are limited hardware costs associated with it.

Limitations

There are two major limitations with the pilot project configuration. It can have performance limitations depending on application specifics: the Notification Services distributor and the SQL Server query processing can compete for resources in high-traffic, resource-intensive situations. Also, it has no failover capability.

Hardware Requirements

One server is needed for all components: the Notification Services engine, the Notification Services databases running on SQL Server, and the subscription management application. See Hardware Considerations later in this article for server details.

Note   It is possible to use a scale-up model to maintain a single server in a production environment rather than a pilot environment, by adding more resources to the existing server instead of adding additional servers. If you find that a single server is giving you adequate performance, and you are prepared to accept short-term down times, you can use a custom failover solution to provide the level of availability required in some production scenarios.

Software Requirements

To configure the pilot project server, you must follow these general steps:

  1. Install SQL Server. (We recommend installing SQL Server Enterprise Edition SP3 on Windows Server 2003 Standard Edition.)
  2. Make sure Internet Information Services (IIS) is installed and running.
  3. Install the engine, database, and client components of Notification Services Enterprise Edition SP1.
  4. Run NSControl Register with the -service argument.
  5. Run NSControl Create.

This is a very simplified overview of the installation and configuration requirements. For a full explanation, see "Installing Notification Services" and "Deploying and Administering Notification Services" in SQL Server Notification Services Books Online.

Performance and Scaling Numbers

The average performance numbers you can expect for a typical application on the pilot project configuration are shown in the following table:

ActivityPerformance
Incoming events500 per second
New subscribers added300 per second
New subscriptions added200 per second
Notifications generated600 per second
Notifications delivered via .NET Alerts100 per second

To use .NET Alerts for delivery, you need to constrain the rate at which notifications are distributed to match the .NET Alerts service level agreement (SLA) of 100 notifications per second. See "Using .NET Alerts with Notification Services" in the appendix for an algorithm you can use to determine appropriate application settings. Note that this algorithm does not constrain data input (events and subscriptions) into the application.

If you do not constrain the notification distribution, the system will back up. This may cause delivery failures. Also, if you have time-sensitive notifications with a short expiration age, it is possible that they might expire before delivery in the case of extensive backups.

These performance numbers are conservative estimates. Actual performance numbers will vary, subject to individual applications and data volumes. The size of event, subscription, and notification records, as well as the complexity of application rules, will have an impact on performance.

Security context

With the pilot project configuration, you need one account for the Notification Services instance and one account for the subscription management application. Both of these accounts must be added as logins to SQL Server and granted access to the Notification Services databases and the master database. For more information, see "User Accounts Required by Notification Services" in SQL Server Notification Services Books Online.

The Notification Services instance account should be the LocalService account if you are using Windows XP or later and if you do not use SMTP as a delivery protocol. Otherwise, you should use a local Windows account with the following permissions and characteristics:

  • Read and write permissions for the Notification Services directory (InstallLocation\Microsoft SQL Server Notification Services\VersionNumber).
  • The ability to log on as a service, which is granted when you run NSControl Register.
  • The ability to read and write registry keys in HKEY_LOCAL_MACHINE\Software\Microsoft\NotificationServices, HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services, and their subkeys.
  • Appropriate permissions to any files or folders in the operating system that are used by the event provider, the content formatter, or the delivery protocol.
  • Membership in the local Administrators group, if the application uses the SMTP delivery protocol.

The subscription management application account should be the ASPNET account that is installed by default with the .NET Framework, if you are using managed code for that application. Otherwise you can use the LocalService account if you are using Windows XP or later, or a low-privilege local Windows account.

Note   You will usually use Windows XP only in development and functional testing scenarios. A server operating system should be used for performance testing and production roll-out.

Production Configuration

The production configuration involves three servers.

In this configuration, one server runs the Notification Services SQL Server databases as well as the generator. Because the generator is lightweight, it doesn't compete with SQL Server for processing resources, and having it on the same server reduces network traffic for the stored procedure calls that the generator makes. This server is located in a secure zone, behind an internal firewall that separates it from the subscription management application. This helps protect the proprietary data in the database, in case the Web server is compromised.

A second server runs the subscription management application, and a third server runs the event provider and the distributor. These servers reside in the zone between the internal firewall and the Internet firewall, because both the subscription management application and the distributor need access to the Internet.

The typical business scenario for using the production configuration is to deploy a small- to medium-sized notification application where availability needs don't require automatic failover.

Figure 5 illustrates the production configuration.

Aa902679.sql_ns_deployment05(en-us,SQL.80).gif

Figure 5. Production configuration

Benefits

Because of its multiple servers, the production configuration provides several advantages over the pilot project configuration. It alleviates the performance limitations that affect the pilot project configuration. With the databases on a separate server, a layer of indirection is added between the database server and the client application, which enhances security. Application reliability is increased by having fewer components on each server, thereby decreasing the change of software conflicts and contention for resources.

The production configuration also provides ease of scalability through use of the Notification Services scale-out model. It also allows you to quickly replace a downed Notification Services computer by installing and registering Notification Services on a replacement computer.

Limitations

Like the pilot project configuration, the production configuration has no automatic failover capacity. Additionally, the production configuration entails greater administrative overhead and higher hardware costs.

Hardware Requirements

Three servers are required for the production configuration: one for the subscription management application and the event provider, one for the databases and the generator, and one for the distributor. For details about these servers, see Hardware Considerations.

Software Requirements

With the production configuration, software requirements vary for each server.

Subscription management application and independent event provider server: We recommend Windows Server 2003 Standard Edition for the operating system on this server. To configure this server, you must follow these general steps:

  1. Make sure IIS is installed and running.
  2. Install the client components of Notification Services Enterprise Edition SP1.
  3. Run NSControl Register.

Database and generator server: We recommend SQL Server Enterprise Edition SP3 on Windows Server 2003 Enterprise Edition. To configure this server, follow these general steps:

  1. Install SQL Server.
  2. Install the engine, database, and client components of Notification Services Enterprise Edition SP1.
  3. Run NSControl Register with the -service argument.
  4. Run NSControl Create.

Distributor server: We recommend Windows Server 2003 Standard Edition for the operating system on this server. To configure this server, follow these general steps:

  1. Install the engine and client components of Notification Services Enterprise Edition SP1.
  2. Run NSControl Register with the -service argument.

This is a very simplified overview of the installation and configuration requirements. For a full explanation, see "Installing Notification Services" and "Deploying and Administering Notification Services" in SQL Server Notification Services Books Online.

Performance and scaling numbers

The average performance numbers you can expect for a typical application on the production configuration are shown in the following table:

ActivityPerformance
Incoming events1500 per second
New subscribers added500 per second
New subscriptions added300 per second
Notifications generated800 per second
Notifications delivered via .NET Alerts100 per second

To use .NET Alerts for delivery, you need to constrain the rate at which notifications are distributed to match the .NET Alerts service level agreement (SLA) of 100 notifications per second. See "Using .NET Alerts with Notification Services" in the appendix for an algorithm you can use to determine appropriate application settings. Note that this algorithm does not constrain data input (events and subscriptions) into the application.

If you do not constrain the notification distribution, the system will back up. This may cause delivery failures. Also, if you have time-sensitive notifications with a short expiration age, it is possible that they might expire before delivery in the case of extensive backups.

These performance numbers are conservative estimates. Actual performance numbers will vary, subject to individual applications and data volumes. The size of event, subscription, and notification records, as well as the complexity of application rules, will have an impact on performance.

Security context

With the production configuration, you need one account for the Notification Services instances, and one account for the subscription management application. Both of these accounts must be added as logins to SQL Server and granted access to the Notification Services databases and the master database. For more information, see "User Accounts Required by Notification Services" in SQL Server Notification Services Books Online.

The Notification Services instance account should be a domain account with the following permissions and characteristics:

  • Read and write permissions for the Notification Services directory (InstallLocation\Microsoft SQL Server Notification Services\VersionNumber).
  • The ability to log on as a service, which is granted when you run NSControl Register.
  • The ability to read and write registry keys in HKEY_LOCAL_MACHINE\Software\Microsoft\NotificationServices, HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services, and their subkeys.
  • Appropriate permissions to any files or folders in the operating system that are used by the event provider, the content formatter, or the delivery protocol.
  • Membership in the local Users group.

This account should be used for the Notification Services service on all servers that run the event provider host, generator, or distributor. For an application where the SMTP delivery protocol is being used, the account should be granted membership in the local Administrators group on any computer that is hosting a Notification Services distributor. This is necessary to meet the privileges required for use of the local SMTP service.

The subscription management application account should be a low-privilege domain account.

High-Availability Configuration

In the high-availability configuration, a cluster of servers runs the Notification Services SQL Server databases as well as the generator, so that these components have failover coverage. Since the generator is lightweight, it doesn't compete with SQL Server for processing resources, and having it on the same server reduces network traffic for the stored procedure calls that the generator makes. This server is located in a secure zone, behind an internal firewall that separates it from the subscription management application. This helps protect the proprietary data in the database in case the Web server is compromised.

Note   It is possible to run the generator on a separate cluster if it is not appropriate in your environment to install the generator on the same server as SQL Server.

Two servers run the subscription management application and the event provider. Both of these components run on both servers to provide load balancing. These servers reside in the zone between the internal firewall and the Internet firewall, because the subscription management application needs to be accessed from the Internet.

Two servers run the distributors. While one distributor is the default for the Voicemail .NET Alerts quick start kit, we recommend that in this configuration you have two servers and add at least one more distributor to the application. (For more information on how to do this, see "Specifying Distributor Settings" in SQL Server Notification Services Books Online.) By having two or more distributors, you add redundancy to this part of the application. If one of the distributor servers fails, the other distributors keep running so that notifications continue to go out. These servers also reside in the zone between the internal firewall and the Internet firewall, because the distributors need access to the Internet.

The typical business scenario for using the high-availability configuration is to deploy a medium- to large-sized notification application with failover capabilities.

Figure 6 illustrates the high-availability configuration.

Aa902679.sql_ns_deployment06(en-us,SQL.80).gif

Figure 6. High-availability configuration

Benefits

In addition to all the advantages of the production configuration, the high-availability configuration also provides the failover capability that the pilot project and production configurations lack. As with the production configuration, the high-availability configuration offers the following benefits:

  • Alleviates the performance limitations that affect the pilot project configuration.
  • Provides increased security by moving the databases to a separate server, providing a layer of indirection between the database server and the client application.
  • Can increase application reliability by having fewer components on each server, thereby decreasing the change of software conflicts and contention for resources.
  • Provides ease of scalability through use of the Notification Services scale-out model.
  • Allows you to quickly replace a downed Notification Services computer by installing and registering Notification Services on a replacement computer.

Limitations

The high-availability configuration incurs greater administrative overhead and higher hardware costs.

Hardware Requirements

For the high-availability configuration, a minimum of six servers is required. Two servers are required for the subscription management application and the event provider. An additional two (or more) servers are required for the cluster containing the databases and the generator, and two more servers are needed for the distributors. For server details, see Hardware Considerations.

Software Requirements

With the high-availability configuration, software requirements vary for each server.

  • Subscription management application and independent event provider servers: We recommend Windows Server 2003 Standard Edition for the operating system on this server. To configure these servers, you must follow these general steps:
    1. Make sure IIS is installed and running.
    2. Install the client components of Notification Services Enterprise Edition SP1.
    3. Run NSControl Register.
  • Database and generator servers: We recommend SQL Server Enterprise Edition SP3 on Windows Server 2003 Enterprise Edition. To configure these servers, you must follow these general steps:
    1. Install SQL Server in a clustered configuration.
    2. Install the engine, database, and client components of Notification Services Enterprise Edition SP1.
    3. Run NSControl Register with the -service argument.
    4. Run NSControl Create.
  • Distributor servers: We recommend Windows Server 2003 Standard Edition for the operating system on this server. To configure these servers, you must follow these general steps:
    1. Install the engine and client components of Notification Services Enterprise Edition SP1.
    2. Run NSControl Register with the -service argument.

This is a very simplified overview of the installation and configuration requirements, especially in regards to clustering. For a full explanation, see "Installing Notification Services" and "Deploying and Administering Notification Services" in SQL Server Notification Services Books Online.

Performance and Scaling Numbers

The average performance numbers you can expect for a typical application on the high-availability configuration are shown in the following table:

ActivityPerformance
Incoming events1500 per second
New subscribers added 700 per second
New subscriptions added 400 per second
Notifications generated1000 per second
Notifications delivered via .NET Alerts100 per second

To use .NET Alerts for delivery, you need to constrain the rate at which notifications are distributed to match the .NET Alerts service level agreement (SLA) of 100 notifications per second. See "Using .NET Alerts with Notification Services" in the appendix for an algorithm you can use to determine appropriate application settings. Note that this algorithm does not constrain data input (events and subscriptions) into the application.

If you do not constrain the notification distribution, the system will back up. This may cause delivery failures. Also, if you have time-sensitive notifications with a short expiration age, it is possible that they might expire before delivery in the case of extensive backups.

Note   These performance numbers are conservative estimates. Actual performance numbers will vary, subject to individual applications and data volumes. The size of event, subscription, and notification records, as well as the complexity of application rules, will have an impact on performance.

Security Context

With the high-availability configuration, you need one account for the Notification Services instances, and one account for the subscription management application. Both of these accounts must be added as logins to SQL Server and granted access to the Notification Services databases and the master database. For more information, see "User Accounts Required by Notification Services" in SQL Server Notification Services Books Online.

The Notification Services instance account should be a domain account with the following permissions and characteristics:

  • Read and write permissions for the Notification Services directory (InstallLocation\Microsoft SQL Server Notification Services\VersionNumber).
  • The ability to log on as a service, which is granted when you run NSControl Register.
  • The ability to read and write registry keys in HKEY_LOCAL_MACHINE\Software\Microsoft\NotificationServices, HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services, and their subkeys.
  • Appropriate permissions to any files or folders in the operating system that are used by the event provider, the content formatter, or the delivery protocol.
  • Membership in the local Users group.

This account should be used for the Notification Services service on all servers that run Notification Services engine components. For an application where the SMTP delivery protocol is being used, the account should be granted membership in the local Administrators group on any computer that is hosting a Notification Services distributor. This is necessary to meet the privileges required for use of the local SMTP service.

The subscription management application account should be a low-privilege domain account.

Subscription Management Application Access

Web-based subscription management applications make database connection requests using the ASP.NET worker process credentials. You can use either Windows security or SQL Server security to give this process access to the Notification Services databases in SQL Server. Microsoft recommends the use of Windows security. The following five options identify the ways in which the user name and password for the Windows domain account may be supplied to SQL Server:

  • You can store the account information in the <processModel> element of the web.config file for the application. This is the recommended way to handle credentials for the subscription management application.
    Note   When ASP.NET is running under IIS version 6 in native mode, the IIS 6 process model is used and the settings in the <processModel> section are ignored. To configure the process identity, cycling, or other process model values, use the Internet Services Manager to configure the IIS worker process for your application.

    You can also store the account information in the <processModel> element of the machine.config file for the server. Changing the account settings in machine.config causes all ASP.NET applications running on IIS on the server to use the configured account.

  • You can hard-code the user name and password in the application code. This is not recommended for production environments because this represents a security risk.
  • You can store the user name and password in a protected registry key.
  • You can programmatically set the account information for the active application thread, using the Thread.CurrentPrincipal method.
  • You can have the application impersonate the current user via Kerberos delegation.

Security Considerations

The following security recommendations should be kept in mind when designing and deploying your Notification Services application:

  • Control access to your subscription management application according to the requirements of your application. If subscriber membership is limited, provide an authentication mechanism. For public applications, ensure that a malicious user cannot create very large numbers of subscriptions, or enter subscriptions for other users.

    For example, the Voicemail .NET Alerts quick start kit requires an authenticated .NET Passport ID and a telephone number, plus a cross-referenced ZIP code or account number, in order to create a subscription. Requiring these three pieces of data prevents a malicious user from creating large numbers of bogus subscriptions that could ultimately create a denial-of-service attack by overloading the distributor and the .NET Alerts delivery service.

  • If your event data comes from an external source, validate it before submitting it to the Notification Services system. This ensures that no falsified information is used to generate notifications.

    For example, the independent event provider in the Voicemail .NET Alerts quick start kit is enabled for access only by the voice mail switches that sit behind an internal firewall. This keeps the event provider protected from malicious attacks.

  • Access to the Notification Services databases should be limited. Use the built-in roles that Notification Services provides to tailor user privileges to accomplish specific tasks.
  • Notification Services generally allows the use of low-privilege accounts, and you should take advantage of this whenever possible — with two exceptions.

    The first exception is when enabling cross-database ownership chaining (usually done when running NSControl Create) when using Notification Services without SP1 applied on SQL Server 2000 SP3. In this case, either the domain account used to run NSControl Create must have a SQL Server login that belongs to the sysadmin role, or a system administrator must manually enable cross-database ownership chaining after you run NSControl Create.

    The second exception is when you wish to use SMTP as a delivery protocol. In this case, the account used for the Notification Services instance that runs the distributor must be part of the local Administrators group on the SMTP server.

  • Use the <EncryptArguments> setting in the Notification Services configuration file to encrypt event provider and delivery channel arguments that are stored in the SQL Server databases.
  • If your notifications contain sensitive information, make a reasonable attempt to authenticate that the target devices that have been entered truly are appropriate delivery locations for valid subscribers. One good way to restrict access to sensitive information is to provide a browse-back URL in your notification, and then authenticate the user on that Web site before displaying any data.

We also recommend that you review Microsoft SQL Server 2000 SP3 Security Features and Best Practices for additional SQL Server security considerations to keep in mind for your Notification Services application.

Hardware Considerations

This article has referred to servers in a generic sense throughout. The attributes of a "typical" server in this context are:

  • 34 gigabytes (GB) of hard disk space
  • 1 GB of RAM
  • Four 2.2 gigahertz processors
  • A mirrored SCSI drive
  • For the high-availability configuration, a disk subsystem adequate to support the cluster

Application Setting Considerations

There are a couple of ways in which the settings that you choose for your notification application can affect your hardware requirements. Some settings can affect disk space requirements, while others may affect performance and influence the amount of RAM or the number of processors you select for your system.

The settings associated with the following nodes in the ADF can influence the amount of resources that your application requires.

/ApplicationExecutionSettings/QuantumDuration

The quantum duration setting can be used to optimize generator performance by balancing latency (the time required to generate and distribute notifications) against the load on the system. This setting determines how frequently the generator fires to process the application rules. Smaller quantum durations cause more frequent firing of the generator, which means more frequent Transact-SQL rule processing and greater application speed. With smaller quantum durations the generator takes up more processor time overall, and therefore requires more resources on the server.

/ApplicationExecutionSettings/ChronicleQuantumLimit

The chronicle quantum limit setting can be used to optimize generator performance by balancing application speed against data completeness. Smaller quantum limits permit the generator to do less work when falling behind, and therefore it can catch up more easily. With smaller quantum limits, more event chronicle rules can go unprocessed, which will affect the event data that goes into the system and the notification data that it generates.

/ApplicationExecutionSettings/SubscriptionQuantumLimit

The subscription quantum limit setting can be used to optimize generator performance by balancing application speed against data completeness. Smaller quantum limits permit the generator to do less work when falling behind, and therefore it can catch up more easily. With smaller quantum limits, more subscription scheduled rules can go unprocessed, which might cause some notifications not to be generated that otherwise would have been.

/ApplicationExecutionSettings/ProcessEventsInOrder

The process events in order setting can be used to optimize generator performance by balancing notification timeliness against the load on the system. Notification Services provides two options for determining how application rules are processed. You can specify whether event and subscription rules are fired for each event batch arrival time (known as sub-quantum sequencing), or whether they are fired once per quantum period, regardless of event batch arrival time (known as quantum sequencing).

Some systems do not require the strict in-order guarantee provided by sub-quantum sequencing, and can take advantage of the performance benefit of not having to provide such a guarantee. However, if your application does require this guarantee and you therefore select sub-quantum sequencing, your system resources will have to be a bit more robust than otherwise.

/ApplicationExecutionSettings/DistributorLogging

The distributor logging settings can be used to optimize application performance by balancing ease of application debugging against the load on the system. Setting the distributor logging settings to true is useful when testing your application. However, these settings enable the logging of verbose delivery-related information into database tables, which can lead to increased storage requirements over time. The logging operations also increase the amount of time required for distributor functioning, and therefore will also affect system performance. If you choose to leave them enabled in a production environment, you might want to increase system resources to handle the load.

/ApplicationExecutionSettings/Vacuum

The vacuum settings can be used to optimize application performance by balancing the size of the application database against the load on the system. The vacuum settings determine how frequently the vacuumer function deletes obsolete event data, notification data, and batch header data from the system.

Vacuuming is essential for maintaining application performance. Less frequent or shorter vacuuming intervals decrease the vacuumer's use of system resources, but also lead to an increase in disk space requirements to accommodate the expired but unremoved data. This degrades application performance. As table sizes increase, it extends the length of time needed to perform database operations on them. We recommend that you schedule vacuuming for periods of low activity in the application.

/NotificationClasses/NotificationClass/Protocols/Protocol/ProtocolExecutionSettings/RetrySchedule

The retry schedule settings can be used to optimize application performance by balancing database size and notification timeliness against notification delivery requirements. The retry schedule settings determine how often and at what intervals the system will attempt to re-send notifications that failed to be delivered. The longer a period of time you select to keep these notifications and re-attempt their sending, the greater the possibility that undelivered notifications will stack up and require more disk space for storage.

/NotificationClasses/NotificationClass/ExpirationAge

The expiration age setting can be used to optimize application performance by balancing notification timeliness against notification delivery requirements. The expiration allows you to specify the length of time a notification can live before it is determined to be out of date. If Notification Services cannot successfully deliver a notification before it expires, it abandons the notification without delivering it, whereupon the vacuuming process can remove it. If you do not specify an expiration age, notifications never expire. You should take the expiration age into account, as the longer the expiration age period, the more live notifications that can be maintained in the system, and the greater the disk space requirements.

Appendix

Signing up for .NET Passport

You can sign up to use .NET Passport at the Microsoft .NET Passport Web site. Find details on becoming a .NET Alerts and .NET Passport service provider at the Microsoft .NET Services Manager site and the Microsoft .NET site.

Getting provisioned for .NET Alerts

You can sign up to receive .NET Alerts provisioning at the Microsoft .NET Passport Web site. Find details on becoming a .NET Alerts and .NET Passport service provider at the Microsoft .NET Services Manager site and the Microsoft .NET site.

Additional information on the Voicemail .NET Alerts quick start kit

  • Voicemail Alerts Web site.
  • For more information on using .NET Passport and .NET Alerts, download the respective SDKs from the Microsoft .NET Services Manager site. (At the Web site, select the second menu option, Service Guide Kit, and then select the .NET Passport or .NET Alerts link for the download you want.)

Additional information on Notification Services

Using .NET Alerts with Notification Services

To use .NET Alerts with Notification Services, you must add information to the Notification Services metadata files to support .NET Alerts as a delivery system. Add a delivery channel section to the configuration file, and a protocol section to one or more of the notification class nodes in the application definition file (ADF). A standard .NET Alerts delivery protocol to use with Notification Services system is available as part of the .NET Alerts SDK.

You also must implement .NET Alerts subscription mirroring. Subscription mirroring essentially involves redirection of the subscription request to the .NET Alerts service. Once .NET Alerts has accepted the subscription, the result is sent back to your Web site so you can mirror the subscription in the Notification Services database. This ensures that the user has actively requested the notifications that they will be receiving, and alleviates user concerns related to notification spamming.

The standard service level agreement (SLA) that .NET Alerts offers is 100 notifications per second. To constrain your Notification Services application in order to provide the optimal throughput for working with this SLA, use the following algorithm:

Alerts Submitted Per Second = Number of Distributors * Distributor Thread Pool Size * Notification Batch Size / Distributor Quantum

For example, you could use the following application settings to constrain an application to meet the .NET Alerts SLA:

  • 1 distributor
  • The distributor <ThreadPoolSize> = 4
  • <NotificationBatchSize> = 25
  • The distributor <QuantumDuration> = P0DT00H00M01S (1 second)

This algorithm assumes there is zero latency. Because there is always a certain level of latency, the actual throughput will always be somewhat less.

Submitting more than the number of messages provided for by the SLA to .NET Alerts will result in an error message being raised.

For additional information on using .NET Alerts with Notification Services, visit the Microsoft Windows Server System Web site.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft