Distrib/remote server

[southeasternMI]

When you add a remote server doesn't that server handle auto-attn, route points, workgrps along with VM for the site you assign it to or am I way off?

[cburgy]

When you add a remote server doesn't that server handle auto-attn, route points, workgrps along with VM for the site you assign it to or am I way off?

Yes it does

[southeasternMI]

So if you have a remote server at a site, then the switches you have at that site will get there firmware updates from that remote server, correct?

[cburgy]

So if you have a remote server at a site, then the switches you have at that site will get there firmware updates from that remote server, correct?

That's correct.

[southeasternMI]

So you should be able to assign switches to that site that uses the remote server for everything (auto attn, work grp, ect) and the only need for the main server is to get updates and failover. So the remote server acts like a stand alone until it needs the main server or needs something from it, but all system changes would be done at the main server.

[cburgy]

So you should be able to assign switches to that site that uses the remote server for everything (auto attn, work grp, ect) and the only need for the main server is to get updates and failover. So the remote server acts like a stand alone until it needs the main server or needs something from it, but all system changes would be done at the main server.

Yes BUT there are some caveats. You can't reboot the DVM if connectivity is lost, or it won't come back up. I have also seen where it gives up after connectivity is lost for so long (24 hours or so... this may have been resolved). The DVM maintains a copy of the appropriate database records in memory and if anything happens, it stops functioning. I wouldn't say that the DVM is a standalone server, as it works in conjunction and requires the HQ server for LOTS of things. For example, if your link to HQ goes down and you want to start up PCM, it won't work. PCM checks in with the HQ server and is then redirected to the local DVM server. The phones also ping the HQ VM extension and then are redirected when dialing into the vm. IT should function properly when the link is down but again I have seen it choke up.

These experiences were based primarily on 6.0 at the time of failures. Usually, things run pretty smoothly. I think a lot of the issues will be resolved once they come up with a database sync between HQ and the DVM servers.

The really big benefit of DVMs is that you can localize VM, AA, PCM and WG so that you don't have to traverse WAN links for these services.

[southeasternMI]

Would you say that the most basic functional use of the DVM would be having all the sites and switches (everything) under the HQ server and just use the DVM server for user voice mail that would be without voice mail if a link went down back to the HQ. So under the user profile under voicemail server, I would select the remote server for those users that fall into that link fail catagory. But as you stated, if the link between HQ and DVM goes down, from that point on there will not be any new voicemail, because the the phones ping the HQ before going to DVM to leave a message and is that even for shoretel users to hear their vm. If that is true, then to me all the DVM server really is, is a holding place for messages and recordings.

[cburgy]

Would you say that the most basic functional use of the DVM would be having all the sites and switches (everything) under the HQ server and just use the DVM server for user voice mail that would be without voice mail if a link went down back to the HQ. So under the user profile under voicemail server, I would select the remote server for those users that fall into that link fail catagory. But as you stated, if the link between HQ and DVM goes down, from that point on there will not be any new voicemail, because the the phones ping the HQ before going to DVM to leave a message and is that even for shoretel users to hear their vm. If that is true, then to me all the DVM server really is, is a holding place for messages and recordings.

I would consider it's purpose localizing the items I mentioned before and then as a backup solution. Now that being said, I have seen it work properly with the link seperating and I've seen it not work properly. I think the important point is to do proper testing and not to expect that all functionality of the Shoretel system will be gauranteed with a link loss. You SHOULD get vm, aa, wg and local PCM (if you have an existing session open).

[phoneguy]

Ok....I have a DVM at a remote site and when my HQ goes down, nobody can access the DVM and any new calls that are sent to VM are given a message that the voicmail system is currently unavailable. SHouldn't the DVM take messages for the HQ VM even if the user is not on the DVM?

[southeasternMI]

Do you have any users or switches assigned to the DVM?

[phoneguy]

I have one user for testing assigned to that DVM. WHen I moved switches to that DVM connectivity was lost.

[Ken]

Hi,

I believe the WG support is only on the HQ server, if you are using a DVM, you will be left with Hunt Group.

Phoneguy,

If the HQ server went down, it can't get resources down stream.
But if a user is in the remote site with a DVM and the DVM is down, you can leave VM for the DVM's user in the HQ server.
HQ server can proxy for the DVM.

[Jason Learmouth]

My understanding is that VM failover is upstream only. HQ down will not fail VM to DVM, DVM down will fail VM to HQ (take message only, not retrieve). Also WG are on HQ server only.

[southeasternMI]

As long as you have trunks to the DVM or have a WAN link to the DVM you can leave messages on the DVM, but that is the only thing that rolls down if you want to call it that. You will get the BAA when calling into the main server.