What Is A Shore Tel Dvm And Why Do I Need One - Presentation Transcript
What is a ShoreTel DVM and why do I need
one?
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.
0 comments
Post a comment