ShoreTel Enhanced Workgroup Services!
Historically, there were three services in the ShoreTel architecture that were no distributed to other servers. To oversimplify, 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 affected user would not be able to place a call. Likewise, 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 server would not dramatically affect 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!