Symantec Management Platform (Notification Server)

I'm trying to design a plan for disaster recovery of our Notification Server but I'm having trouble finding good information on it. I was hoping someone here can give me some pointers on what the best strategy is.

Can I set up another NS and in case of failure of the primary NS, restore the database to the backup NS and then change DNS to make sure all agents talk to backup NS?

https://kb.altiris.com/article.asp?article=22485&p=1 - Checklist

https://kb.altiris.com/article.asp?article=2112&p=1 - Miscellaneous information

Ideally, backing up the database, and having copies of your custom reports, packages, tasks, etc, as well as the coresettings.config should do what you need.

quote:

---

Originally posted by: jharings
https://kb.altiris.com/article...?article=22485&p=1 - Checklist

https://kb.altiris.com/article.asp?article=2112&p=1 - Miscellaneous information

Ideally, backing up the database, and having copies of your custom reports, packages, tasks, etc, as well as the coresettings.config should do what you need.

---

Thanks for the reply. This helps but I guess I should re-word what I'm looking for slightly. We can fairly easily recover from a disaster given enough time but if we need the NS back immediately or within an hour or so, we'd need a plan for that as well. I guess what I'm looking for is some sort of high-availability solution although I know the current NS does not support clustering.

We have very strict outage windows for monthly patching and we'll have a big problem if the window is missed because the NS is down for a longer period of time.

Is there anything we can do for immediate recovery/failover of the NS?

Ok, the key is always the database. So if you have another NS, and can point and\or move the database to the new box, you could use several methods (DNS change, or modifying the agent configs via the aexagentutil - local to each system) to point the agents to the new box.

Looking at the first document, you'll have to forgive me, but I think it answers precisely how to do disaster recovery. Have a "hot-standby" NS\DS ready, with bogus databases and no clients, and if the primary system(s) fail move the databases over. I guess the missing key is the agent redirection, hopefully my answer helps clarify this.

quote:

---

Originally posted by: jharings
Ok, the key is always the database. So if you have another NS, and can point and\or move the database to the new box, you could use several methods (DNS change, or modifying the agent configs via the aexagentutil - local to each system) to point the agents to the new box.

Looking at the first document, you'll have to forgive me, but I think it answers precisely how to do disaster recovery. Have a "hot-standby" NS\DS ready, with bogus databases and no clients, and if the primary system(s) fail move the databases over. I guess the missing key is the agent redirection, hopefully my answer helps clarify this.

---

I might be missing it but I don't see anywhere in the first document where it mentions having a standby server. The only option mentioned in the document that seems similar to that talks about how to restore the NS on different hardware, but only after the NS has failed. It seems that assumes that you will build a new server (on new hardware) after the NS has failed (which will be too late for us as we need it to recover almost immediately), using the same computer name as the failed NS since you can't have two servers with the same name simultaneously running. I guess I'm wondering if I can build a standby server that has a different computer name and if the primary NS fails, use DNS to redirect agents to the new server. I'm just wondering if that will be a problem for the agents in any way since the standby NS has a different computer name.

I think we are on the same page, if perhaps slightly different novels. The DNS redirection (or using a deployment server to utilize the aexagentutil.exe redirection) should work fine.