ShoreTel – Does a “single image” deployment always make sense?

We continue to be a major fan of ShoreTel solutions, but that does not mean that they we accept everything without question.  One of the most touted advantages of the ShoreTel architecture is the concept of a “single image” solution with no single point of failure.   We find that in large enterprise deployments that may not be an advantage.  Just because you can deploy as a single image, does not mean that you should!  Lets take a closer look at this battle cry and test that claim against real world situations for large enterprise deployments.

First, the concept of a “single image” system.   All phone systems, bar none, have to deal with the realities of a database.   Generally a phone system has two databases;  the configuration database and the run-time or state machine.   Again, all telephone systems have the same challenge as there can only be one copy of the primary data base.   In a ShoreTel system, the primary database through version 10 was located on the HQ server.    If you lost the HQ server, you could not make any changes to the system configuration.  This meant agents could not log in or out of workgroups and automated attendants could not change from day to night mode.   If a user, as another example of a “state” , had their calling mode set to “out of office”  you were going to stay absent until the HQ serve came back!

Lets consider a large system deployed over several time zones.  Assume a HQ server in the PST zone and a workgroup in the UK on GMT, with maybe a few branch offices in the EST and CST!    Any network issues, even a simple flapping WAN, will result in the UK agents going off line and not being able to log back in.  After Version 10 ShoreTel implemented “distributed’ databases and optional, distributed workgroup services.  You had to make a choice however, either you could distribute your database or you could distribute your workgroup service, but you can not do both.    As you can have one but not the other, it seems that though the workgroup service might be available the current state would not be available to change.  What does this mean?

If we distribute workgroup services, in the above example, away from the HQ server to a distributed server running in the UK,  ShoreTel workgroup functionality would be enabled for  continued operation in a WAN down scenario.     Agents, however, would not be able to change their states from log in to log out or back again.   This is because the availability of the only read/write database is still unavailable.  ( Generally, we would recommend that workgroup services , in a large ShoreTel deployment, not be distributed for this reason, opting to have the ability to change call handling modes and have workgroups fail over to hunt groups).

Nobody that has had responsibility for maintaining or upgrading a multi-site deployment with the geography as defined above, would ever vote for a “single image” solution!  Imagine organizing an upgrade for the above scenario?  All of the servers, switches and phones across all time zones would have to be upgraded in a single maintenance window.   Then again,  this might have been the wrong deployment model to begin with!  Just because you can install as a single image, does not mean you have to deploy using a single image.   The above scenario could have been deployed using two separate systems, one in North America and One in Europe.   They could have had a uniformed dialing plan that would have masked the two system as a single system to the users, through a SIP tie line between the two systems.  Clearly, they would have had two voice mail systems and two administration portals.  On balance, however, it  might be a more stable model with less operational head aches and certainly a lot more manageable when it came time to upgrade!

Then again, that deployment strategy model would look an awful lot like a CISCO deployment!

Compare ShoretTel and CISCO Part 3 – Users and phones

All of the architecture “geek speak”  aside, CISCO and ShoreTel have fundamental “cultural” differences that defines their approach to the entities of  a “phone” and  a “user”.    Simply stated in the ShoreTel world a phone can not exist without a user, but the CISCO world a phone can exist without a user.  Now this is  not a bad thing or a good thing, it is a just the way it is thing!  What does that cultural distinction mean to you and your business?   Does it mean anything?   From a system definition perceptive, it does change how you think about your deployments.

In the CISCO world, you can bring up a range of phones, auto-assign an extension number, have a fully functioning dial plan  and never define a user!  In a ShoreTel deployment you can auto-register a range of phones, but they can not participate in a dial plan until they are assigned or “owned” by a user.   In one solution, the privileges that a phone has, like being able to make International phone calls, is set by the privileges of the user.  In ShoreTel a user is associated with a user group and that group has privileges associated with it.

In the ShoreTel world,  users are licensed but phones are not directly licensed.  You clearly have to have ShoreGear resources for the phones to register in the system,  but aside from the cost of the phone and ShoreGear switches, the phone is not directly licensed.   If you deploy that phone in the “Parts”  department you will need to create a User and associate that User to the phone.    So we now need to create  a user and user name like “Parts Desk1” and assign it to a phone.   Optionally, we could create a user named Tony Slavetore who works in the parts department, but that brings up the issue of of separating a “function” from a “person” which is an entire deployment discussion in itself and the subject of another blog.

In the CISCO world, you can have phones with extension numbers and they do not have to have a User profile associated with them.   In a CISCO deployment, phones belong to “partitions” and “calling search spaces” and that is what determines the phones privileges.    In fact the concept of a “partition” makes it possible to separate phones in such a way that “staff” for example, can not dial “executives”.   ( If asked in a ShoreTel system to restrict a phone from being able to dial a specific other phone, I would have to puzzle that one out ).   Again, this is not a which strategy is better discussion, but it is a distinct cultural difference that we seldom hear about.

The included video demonstrates adding a user and a phone in both the ShoreTel and the CISCO CUCM solution.  System Administrators will spend +80% of there time in this area!  Adding, deleting or modifying Users is a key part of the day to day maintenance of a phone system.

Compare ShoreTel & CISCO Part 2 – System Admin Portal

All telephone systems have to deal with the same key architectural  issues regardless of who manufactured the equipment.   All phone systems have to provide for the definition of a system “dial plan”; trunk groups, call flow options, phone devices, gateways and user profiles.   The dial plan, for example,  not only has to identify the patterns used to route callers between system extensions, but as is often the case in a VoIP deployment, between geographically distributed corporate locations or “sites”.    The dial plan identifies the legitimate patters that define system end points and also include system extensions.  System extension define various facilities and features with in the system.  The Automated Attendant, for example, has a system extension number that can not be used by another extension in the system.  Likewise so does the conference bridge, park feature, hunt groups and paging groups.

The phone system defines Trunk Groups which in turn contain individual telephone lines.  Permissions are defined within the system to enable access to these different trunk groups and also define what other facilities a user might  have access to.  Devices are defined within the system, typically consisting of phone instrumentation, media gateways to the PSTN or Remote Sites and collaboration facilities like conferencing and presence.  Other application servers are also defined in the system to provide for advanced functionality like Contact Center.

The entire subject of User configuration is contained within the system database as both a comparatively static form as well as a run time representation.    A user name and extension number, is an example of a relatively static configuration data parameter.   Which mode or state that users is in, would be an example of a “run time” state.   Which phone the user is currently assigned, where do their voice message reside and what restrictions have been placed on them are all examples of administrative options that need to be configured.
Both ShoreTel and CISCO have developed Web based interfaces to enable system administration.  ShoreTel argues a single “brilliantly simple”  portal to all system configuration facilities.  CISCO argues a level of control over configuration details that enable laser like configuration options.   For example ShoreTel operates on the concept of canonical dialing.  If a user dials 123-4567  ShoreTel will translate that into +1 (123) 456-7890.   CISCO anticipates  “dial-patterns” that make it possible to strip +1 (123) 456-7889 out from +1 (123) 456-7890 and route it differently.   The System Administration portal is the interface that is used to configure, define and revise all system options and for this reason it is as important as the phone set itself!

Over the next few blogs we will look at the actual web portal interface of both of these solutions.  In this first video, we will go over the portal interface in general, comparing both systems.  In subsequent blogs on this subject we will compare different administrative activities such as adding users, phones, gateways, sites and configuring call flows including automated attendants and hunt groups.

Deploying ShoreTel – A project managers notes!

Having deployed literally thousands of phone systems of all sizes and levels of complexity, we have distilled a set of rules and check lists that work.   (see our “network readiness check list” and our “VoIP planning guide”) When phone systems were analog or traditional TDM based solutions,  deployments were challenging enough!  You always had the User group, Call flow and “K plans” to hammer out along with the usual Telephone carrier challenges.  With VoIP solutions however, the level of complexity has dramatically increased.  This technology touches so many other infrastructure domains that it is becoming increasing more difficult to draw a box around what is included in the project!   Consider that you are required to  integrate a phone system with Active Directory,  Exchange, CRM applications and deploy over a geographical topology that might be global in scope!  You need a road map for success and  project management becomes an essential component of a successful deployment.

The first post sale step should be to organize a “kick off” meeting.  The kick off meeting  is an opportunity to set expectations and establish guidelines that will help complete the project on time and within budget. When you leave the kickoff meeting, everyone on the project team must be on the same page.  It is imperative that we identify the key “stake holders” in this project.  Minimally this list has to include an Executive sponsor, the Account manager and the Project manager.    During this meeting you will want to spell out goals, objectives and deliverable identities then obtain “buy in” from the kick off team.   You will introduce the project team members and identify their individual “roles and responsibilities”.   Setting a target for “go live” often helps drive the milestones that have to been executed if that time line is to be achieved, so I am a big proponent of working backwards from a target date!   Developing a contact list should be accomplished at this meeting and if the project will use a web portal for communicating, it should be demonstrated.   Allow for the possibly that there may be outside vendors that need to be identified at this time and added to the contact list.  Finally, assign “home work” and set due dates for the next meeting.

The kick off meeting is almost a social event and is a time for people to associate names and faces.   It is not a working session, but an effort to set expectations for all that will be either on the project implementation team or will be impacted by the implementation process.   There is a wide range of personalities and skill sets at a “kick off meeting” so it is important to adopt a language that is comfortable for all.  The team will consist of very technical people, financial  professionals and technology consumers (We are trying to avoid using the work “users”.  There are only two industries that call customers users.  The IT community and the drug trade).   It has been my experience that we will almost always get all of the technical stuff settled; all the speed and feeds, bits and bytes.   The area that is always the most difficult to extract is the Call Flow information .  For this reason it is imperative that the team have a representative that can speak for the User group.   Someone has to define a callers experience and the scripts that are head by the caller as they progress through the telephone system (see also: ).

Some of the internal players that will need to be included on the implementation team are responsible for key infrastructure components.   Active Directory integration is now almost always a part of a VoIP deployment.   Messing with a companies domain and user authentication polices are never take lightly and you will need to get key intellectual resources involved to pull this off successfully.   Clearly, the computer network both LAN and WAN will touch the the new phone system and this area requires even more planning and communication.  Generally, there will be outside vendors involved especially as it relates to the WAN connectivity.   Getting the carrier to the table early on in the process will greatly facilitate the success of the project.

Facilities management or property management and the bag full of deal killing goodies needs to be addressed early on!  If you are deploying in a “greenfield” you will have a different set of challenges then if you are replacing an existing phone system.   Often a “greenfield” is another word for “new construction” and construction always means scheduling conflicts and delay.  This is where your project management software really gets exercised!

The actual deployment of equipment is almost reduced to a task list. Properly managed most of the heavy lifting has already been accomplished before the equipment is actually installed.   The network has been assessed, made ready, routes updated and QOS applied.   The user database, IVR scripts, trunk facilities, Extension lists, Hunt groups and system definition have already been programmed.   We are down to “rack and stack” and set placement in anticipation of exercising our detailed system test and acceptance process.

It is about this time that we will want to have the Training team make an appearance.    Generally, it is best to schedule user training as close to the “go live” dat as possible.  We have found that we can brake user training into two groups.  The first group is a an abbreviated session design to assure that all can answer an incoming call, park, transfer and conference.  If users can do that by “go live”  only good things can happen.    The second group is an extended session augmented by multimedia and other online solutions.  This training is for your power users and special users like Operators, Agents and Supervisors.  Actually, this is a process not an event and your training program has to be ongoing over the life of the deployment.   People come and go in any company.  Your reputation and phone system stay. Make sure new users have a good impression!

The “go live” is also more of a process than an event.   Moving the old numbers to the new phone system, might be a single task in time, but it is part of a process that includes a series of collateral events.  For example, how do we get our Voice Mail off the old system?   In fact, what happens to the old system?   Was Garbage removal in the project plan?   A new VoIP deployment needs a “post cut” support plan that includes establishing a “help desk” and identifying a problem reporting process and resolution team.

If there is a “kick off” meeting there should also be a project close and review meeting.    This is where we can review what happen and how to transition the project to a support mode.   There should be an “as built” documentation package that is handed off from the project team to the operations team.  These documents will be outdated in less than a month, but it makes ongoing support viable if we have a record of changes to date, so make the extra effort to get this package completed as part of your project plan.   Ultimately you will want to have a 30 day review.   Keeping a client takes as much effort as getting a new client, so make ongoing client contact and system optimization part of your service offering.   Include ongoing training and you should be able to keep a client for life!