In our Release Notes of Unity 2.46 and above we do recommend using the Veritas Software backup ptogram as a strategy for backing up Unity server. We also give some procedures on how to navigate in the Veritas porgram of Backup Exec and what to backup on the Unity Server GREAT!<br><br>What if the customer has another Back strategy from say ARCServe. Will we support/recommend this too?<br>Are there specific procedures for backing up with ARCServe say that we need to be aware of?<br>Exactly what on the Unity Server needs to be backed-up?<br><br><br>
As an aside here... let me throw this out and see what folks think. I'm currently working on a DisasterRecovery tool as part of the new applications team I'm running (AnswerMonkey comes in house, basically). The purpose of this tool is to backup all Unity specific data out of the registry, SQL, local files, greetings, etc... and dump it out to a designated location (presumably a shared network drive in most cases). This can be configured to run on a schedule such that it's always resonably up to date.
When there's a disaster (i.e. Unity box gets hit by an asteroid or something) the customer must rebuild the box to the point where Unity is running as a new install. You can, of course, take the opportunity to install on new hardware, maybe switch to off box Exchange etc... no problem. Once you're here, you run the restore portion of the app which reapplies all the Unity specific settings, right down to phone passwords, greetings etc...
The basic idea is to disassosiate myself from the backend configuration which can be varried. It's up to the customer to make a backup of the OS if that's what they want to do and/or Exchange... the message store is their territory.
From my perspective this is a reasonably clean backup/restore model since the customer can use whatever backup method they're comfortable with for the OS/Exchange/Domino/Whatever and we'll take care of the Unity data on our end. This way we don't have to worry constantly about qualifying various backup methods/tools and the like. For POV boxes this may be an issue since folks may want an "all in one" push button solution they don't have to worry about... that's a situation where we can point them to a package we approved and roll with it.
Anyone have any objections to running down this path?
IntroductionCUCM Routing RulesDial String implementation PolicyCUCM Routing LogicSIP URI Call Routing Analysis+++ Case Study: 1 ++++++ Case Study: 2 +++Conclusion
Over the last few months, I have had the privilege of working on SI...
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...