Resolving Common Notification Services Issues

Článek
12/03/2008

Microsoft has compiled the following list of issues and solutions encountered by users of Notification Services.

Important

When troubleshooting a Notification Services application, first go to the Application log in Windows Event Viewer. Events in the Application log are often the best way to determine the source of an application problem.

Deployment and Administration Troubleshooting

Creating an instance fails due to time-out error

The processes that create a Notification Services instance perform several tasks, and each task has a time limit. The database creation process tends to take more time than the other operations; the time limit for this operation is 10 minutes, which is normally more than adequate. However, if your instance configuration or application definitions specify very large database sizes (several gigabytes), the create process might time out; if it does, a time-out message is displayed.

To successfully create the instance you must reduce the database file sizes in the ADF and configuration file and then create the instance. You then can increase the sizes of the database files using SQL Server Management Studio or Transact-SQL statements.

Creating an instance fails due to full transaction log

If you add a log is full or nearly full, creating an instance of Notification Services might fail. Increase the size and maxsize values of the transaction log and then try again.

Updating an instance fails

Updating a Notification Services instance might fail because of errors in an application definition or instance configuration. Before updating an instance, you should validate all XML files to reduce the possibility of this error occurring. If an error does occur, fix the file, and attempt to perform the update again.

Because updating an instance modifies instance and application databases, always back up the instance and application databases before updating the instance.

For more information about updating an instance, see Updating Instance Properties. For more information about updating an application, see Updating an Application.

The Windows service does not start

If you use the NS$instanceName Windows service to run the Notification Services engine components, and the Windows service will not start, the service password might be incorrect, the instance name you are trying to start might not be an exact match for the Notification Services instance name, the databases might be inaccessible, or the Windows user account under which the service has been configured to run might not have permissions to log on as a service. Try the following to resolve the problem:

**Verify that the service account is a member of the SQLServer2005NotificationServicesUser$**ComputerName group in Windows. Members of the SQLServer2005NotificationServicesUser$ComputerName group have permission to read and execute Notification Services binary files, including NSService.exe.
Reset the Windows password. When you use the Notification Services commands to configure a service password, and the password contains special characters or was entered incorrectly, the NS$instanceName service will not start.
To resolve this error, update the password using the Services application:
1. In Control Panel, open Administrative Tools.
2. Open Services.
3. Right-click the **NS$**instanceName service (instanceName represents the name of the Notification Services instance), and then click Properties.
4. Click the Log On tab, type your password in the Password and ConfirmPassword text boxes. Click OK.
5. Right-click the service, and then click Start.
Check the databases. If the service cannot access the instance and application databases, it will not start.
- Is the database name in the instance registry correct?
- Is the Database Engine instance that hosts the instance and application databases running?
- Are the instance and application databases available?
- Are there any network issues that would prevent the service from accessing the databases?
Start the service from the Services application. When you start the service using the net start command, the characters used at the command prompt must match the Unicode characters used in the configuration file. If the characters do not match, the instance cannot start.
To resolve this error, start the service using the Windows Services application:
1. In Control Panel, open Administrative Tools.
2. Open Services.
3. Right-click the **NS$**instanceName service, and then click Start.

Errors are not written to the application log

If the Notification Services engine will not start, but there are no errors in the application log to indicate the cause, your application log may be full. To reconfigure the application log, do the following:

In Control Panel, open Administrative Tools.
Open Event Viewer.
Right-click Application, and then click Properties.
Do one or both of the following:
- Increase the Maximum log size value.
- Select Overwrite events as needed.

Unexpected errors appear in the application log

If you receive unexpected errors in the application log, try restarting the Notification Services engine.

For example, if you remove an application from an instance while the Windows service is running, and you then see errors in the event log for the application you removed, restarting the Windows service should stop these errors from appearing.

For more information, see Starting and Stopping Instances of Notification Services.

Event Collection Troubleshooting

I cannot submit events to an application

When troubleshooting event collection, verify the following:

If using a hosted event provider, verify that the Notification Services engine that runs the event provider is running.
Make sure event collection is enabled. You can quickly view the status of instance components by running the nscontrol status command. If events are Disabled or Enable Pending, you will not be able to submit events.
For more information about viewing status, see Viewing the Status of Instances, Applications, and Components.
For more information about enable and disabling components, see Enabling and Disabling Instances, Applications, or Components.
Verify that the account used to run the event provider has NSEventProvider permissions in the instance and application databases.

The file system watcher event provider fails

The file system watcher event provider might fail if the performance counters on the server become corrupted. If you receive the following error in the event log, a performance counter is corrupted:

Event ID: 2980

If a performance counter is corrupted, the counter will not return values. To attempt to resolve the corruption, do the following:

If the instance is running, stop the instance. For more information, see Starting and Stopping Instances of Notification Services.
Close any applications that query the Notification Services performance counters, such as System Monitor.
Re-register the instance. For more information, see Updating Registry Information.

This re-creates the performance counters for the instance. You might need to run these steps multiple times.

Notification Generation and Delivery Troubleshooting

Duplicate notifications are generated

If subscribers are receiving duplicate notifications, verify how you are collecting and using events:

Verify that your notification generation rules are not directly accessing the notification table when they should be accessing a view named after the notification class. The view returns only the current set of events, whereas the notification table contains all events that have not been removed via vacuuming.
For example, if the name of an event class is StockEvent, use the StockEvent view in your subscription rule, not the NSStockEventEvents table.
If you are obtaining events from another source, such as an event chronicle or external table, your query must contain logic to select only the data you want to use to create notifications. For example, you might include events submitted in the previous 24 hours or events that have a specific value in a column. Statements in your subscription rules can modify values in the event source so that you can track event usage.
Verify that you are not submitting the same event data multiple times.

For more information about writing subscription rules, see Defining Subscription Rules.

Notifications are not generated or delivered

If notifications are not being sent from your application, check the following:

Is the Notification Services engine that runs the generator component running? Is it enabled?
Are there any events available?
Run the NSDiagnosticEventClass stored procedure in the instance database. Look in the EventBatchesCollectedCount column to see if events arrived when you expected.
Are there any subscriptions?
Use the NSSubscriptionClassNameView view in the application database to verify that the application has subscriptions to evaluate.
Are scheduled subscriptions properly scheduled?
Use the NSSubscriptionClassNameView view in the application database or run the NSScheduledSubscriptionList and NSScheduledSubscriptionDetails stored procedures in the application database to view subscription details.
Do the subscriber devices referred to in the notifications exist?
In your subscription rules, you must provide a subscriber ID and a subscriber device name. The subscriber device name must match the name of a subscriber device defined for the subscriber. To view subscriber devices, use NSSubscriberDeviceView in the instance database.
Are rules timing out?
If the subscription rules that generate notifications are timing out, your application will not generate notifications. Verify that your rules are efficient, that you have the proper indexes defined on event and subscription data, that vacuuming is running to remove old data, and that the rules are not being blocked by other processes running on the server. For more information about developing subscription rules, see Defining Subscription Rules.
Are notifications being generated?
Run the NSDiagnosticNotificationClass stored procedure in the instance database to verify that notifications are being generated. Look in the NotificationsGenerated column for the interval at which you expected them to be generated. If there are no notifications it is possible that there are no events or no subscriptions, or that the subscription class match rules do not insert any notifications into the notification class function. For more information about rules, see Defining Subscription Rules.
Are notifications failing?
Run the NSDiagnosticFailedNotifications stored procedure to check for failed notifications.
Are the notifications going to the correct delivery channel?
Verify that the application defines the correct protocols for the notification class and that the subscriptions added to your application are using the correct delivery channel.
Are your delivery channels functional?
Run the NSDiagnosticDeliveryChannel report to see if the delivery channels are operational.
Are your distributors enabled?
For more information about enable and disabling components, see Enabling and Disabling Instances, Applications, or Components.

Generic delivery errors occur

Some delivery errors can in fact be configuration errors. For example, if you incorrectly configure an SMTP delivery channel, when Notification Services tries to deliver a notification using the delivery channel you might receive a message such as this:

SMTP Delivery Notification Generic Error

If you receive several errors like this, verify that your delivery channels are configured correctly. For more information, see Defining Delivery Channels.

SMTP delivery fails

When using the Internet Information Services (IIS) SMTP protocol with the local IIS SMTP service, Notification Services must look in an IIS directory to determine where to deliver the notifications. Only administrators can access this information.

To use the local IIS SMTP service, the account used to run the distributor engine component must be a member of the local Administrators group.

The distributor times out

If you receive various time-out errors in the event log, the distributor logging level might be too high. This typically occurs only when the database system is processing high volumes of notifications, and cannot handle both the distribution and logging tasks.

To resolve the problem, set the turn off logging. For more information, see Specifying Delivery Protocol Execution Settings.

Vacuumer Troubleshooting

Data is not being removed, resulting in large event and notification tables

If data is not being removed from your application database as expected, check the following:

Does your application definition provide a vacuuming schedule? For more information, see Configuring Data Removal.
Did you specify a reasonable retention age? (The longer the retention age, the more data will accumulate in your tables.)
Is vacuuming running during a period of low system activity? If not, vacuuming might not have enough system resources to efficiently remove data.
Note that the start time is a UTC value. For example, if you specify a value of 02:00:00 as the start time, this is 2:00 A.M. Greenwich Time. To specify a time of 2:00 A.M. in your time zone, add or subtract the difference between your time zone and Greenwich Time. For example, Pacific Time is 8 hours behind Greenwich Time. To run vacuuming at 2:00 A.M. Pacific Time, specify a start time of 10:00:00.
Is the vacuuming duration adequate? Depending on the volume of data, you may need to run vacuuming for longer periods of time.

To evaluate vacuuming performance, use the following resources:

Run the NSSnapshotApplications stored procedure to determine when vacuuming last ran and how many events and notifications were removed. For more information, see NSSnapshotApplications (Transact-SQL).
Monitor the NS$instanceName: Vacuumer performance object using Windows Performance. For more information, see NS$instance_name: Vacuumer Object.

Web Application Troubleshooting

My subscription management application cannot access the Notification Services instance

Your subscription management application must be able to locate and access the instance and application databases. This requires the instance to be registered on the server where the application is running, and the account used by the application to be added to the NSSubscriberAdmin role in the instance and application databases. For more information, see Deploying a Subscription Management Interface.

Sdílet prostřednictvím