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!