Notification services is one of the deprecated features in SQL Server 2008, essentially it is supported for now but will not be in the next release of SQL Server. If you are using notification services currently and you are looking to upgrade to SQL Server 2008 then you can get it from here.
But why deprecate the feature? Basically not many people were using and it wasn’t seen as being easy to use or flexible enough. But what are your migration options if you are using it?
That’s going to depend on what you are using it for:
- Alerting of system health. A good alternative here would be use the policy management features in SQL Server 2008 and either schedule them (which is built into the UI) or set them to OnDemand: notify if the policy supports that (as per this post of mine.
- Audit. You can trap audit details to file, or the event logs (including the security log)in SQL Server 2008. From there you could run a report on a schedule to show you any issues or use the capabilities of the event logs. Change Tracking can do similar things for reporting on changes to actual data
- Performance. Extended events and the Data collection elements of SQL Server 2008 will allow you to trap detailed telemetry of what’s happening to your database and the wider context of what’s happening server.
Having collected the information you want to track, the challenge then is to get this information back to you when things go wrong. This could simply be a case of making use of an agent job to do a test to see if there’s a problem, and then to conditionally running a reporting services report of the problem(s), or a send mail procedure to do it that way. DDL triggers might also be an option, so there are lots of options but no obvious single thing to take your existing setup and migrate it to any of the above I’m afraid.
So I would be interested in the comments this generates, and as ever if you have some ideas or an issue with this then Microsoft Connect is the forum for that.