ShoreTel Enhanced Workgroup Services!

Historically, there were three services in the ShoreTel architecture that were no
distributed to other servers. To over simplify, this meant that if the HQ server (read
primary server) was unavailable, the services that were not distributed would not
function. The three services were Route Points, Account Codes and Workgroups. For
example, if a user group was set to “forced” account code verification and the server was
unavailable, that service would fail and the effected user would not be able to place a call.
Like wise, if the HQ server were unavailable, Workgroup services would fail. ( The
“best practice’ deployment strategy was to backup a Workgroup with a “hunt group”
given that the HG ran on a switch and not a server, it would continue to function in this
scenario. Calls targeting agents in a Workgroup would fail over to a hunt group that
would target the same list of agents).

ShoreTel has steadily progressed the distribution of these services out from the HQ server
to either SG switches or Distributed servers. With the latest release of ShoreTel, they
have migrated critical services to include Workgroup services. This is a major
enhancement and any organization that makes use of the Workgroup functionality,
especially in a multi-site environment, will realize a benefit by these enhancements.

Through the ShoreTel administration portal, we now find a drop down window that
enables us to select which server should be utilized to run the Workgroup we are
defining. For example, in a multi-site environment, I might want to have the
Workgroups organized by Site and run the workgroup service on the DVM at that site.
This would keep the Workgroup local and a failure of the HQ sever would not
dramatically effect the workgroup at the remote site. We note that, in the absence of the
HQ server, we are still unable to make database changes. For example, Logging In/Out
of a Workgroup would not be possible, but the remote Workgroup would still function.

Additionally, we note that you can continue to name a Hunt Group as a backup extension.
The key difference here is that the Hunt Group can contain extensions that are
Workgroups on other servers! This offers a degree of flexibility not previously
available and is a viable alternative to a straight Hunt Group solution. A failure of the
HQ server will only effect the Workgroups that are on that server and distributed
Workgroups on other servers will continue to run. A failure of a DVM with an operating
Workgroup can fail to a Hunt Group that can be used to route calls to other Workgroups.

The vocabulary might be a bit confusing, but the strategy represents a significant step
forward in assuring the operation of a distributed call processing application as powerful
as ShoreTel Workgroups!