What is a ShoreTel DVM and why do I need one?
April 21st, 2009

What exactly is the value of a Distributed Voice Mail Server (e.g. DVM)?   What are the pro’s and con’s of installing one?  Does it have any impact on resiliency (not redundancy) as it relates to business continuity in the event of server failures?  ShoreTel has a distributed architecture but like all other VoIP solutions there is only one “read/write” database and that is a component of the ShoreTel architecture aptly named the HQ server.   IF this server goes down and the R/W database is unavailable configuration changes can not be made throughout the “single image” installation.

Installing a DVM at the same level, or in the same site as the HQ server, provides a high degree of resiliency at comparatively low cost.     At the HQ site, put all your HQ users on a DVM.   If the DVM goes down, the HQ will pick up the heavy lifting for the Users on the DVM.  If the HQ goes down, the DVM users will still have VM and AA services.  As of today, there are three services, however,  that are NOT distributed in the ShoreTel architecture. These services are known as Workgroups, Route Points; and Account codes.   If you lose the HQ server, you will lose these services for all sites, even if they have a DVM installed at that site!

As it relates to low cost business continuity options, we like to install a DVM at the HQ site, but we want all switches at all sites to be managed by the HQ server.   This usually provokes a heady discussion, but here is our reasoning.   The real value of a DVM is to keep VM and AA media streams off the very expensive WAN connections. Remember that a DVM can fail up, which means the HQ server can take over Voice Mail and AA processing for the users at a site that has a failed DVM.   It makes sense to put the users at a remote site on the DVM at that site, but does it really make sense to have the switches at that site managed by the DVM at that site?

We think not.   Lets separate the issue of Users and Voice Mail from issues like TAPI, Workgroups and Personal Call Managers.   We need to remember that if a server goes down, the switches managed by that server will lose all the TAPI information for the phones that it controls.  This means you will have no functioning Workgroup Agents and not ability to monitor those Agents. Additionally, the Personal Call Managers will not work for any extensions on switches managed by the down server.

Given that Workgroups is not a distributed service, if the HQ server goes down, you will not have Workgroups anyway.   If the DVM at a remote site goes down, the HQ server will proxy for that sites Voice Mail and Automated Attendants.  Given that the HQ server was managing the switches at that remote site, you will not lose any of the PCM functionality highlighted above.  It occurs to us that this is a better place to be.   Let the HQ manage all switches and use the DVM’s for Voice Mail services for the users at remote sites!  Use a DVM at HQ for additional resiliency.