New Release Process defines ShoreTel Upgrade paths

ShoreTel will often have a controlled release of software.   For example, Version 9.0 might be shipping to new clients but will not be availalbe to existing installations until it is declared GA.    Existing clients with a compelling need, could always obtain the upgrade, but it would be subjected to the terms of a controlled release.  Over the years I have observed that an 8.0 release, for example, never goes GA, but becomes 8.1 when it does.   With the release of Version 9,  ShoreTel has now formalized this “enhanced delivery” process.

Starting with ShoreTel 9 add-on feature sets will be made available as “dot” releases in the form of 9.1, 9.2 etc.  The impact of this new development process is taht features delivered in a “dot” release will not be included in the first major release of the next version.    So if you are on 9.1 you will not be able to upgrade to a controlled release (CR) of 10.0 butt will have to wait until 10.0 goes GA with a 10.1 release.

So we witness a fomalization of a process that has really be in use for quite some time!   It is a process, however, that has built in software assurance as the primary goal.   If you have an interest in the latest feature set, send me an email and we will update you!

Modify ShoreTel Database to Kill “dial 9” requirement?

Fax Machines on ShoreTel?   It is not uncommon for system administrators to create a user named FAX SEVER, then define it as EXTENSION ONLY.    Though I personally have been trying to eliminate all the forest eating fax machines and printers on the planet, it would appear that Fax machines are going to be with us for quite some time.   Even with a fax server, people want to stick a piece of paper into the machine and watch it “go through” after dialing the distant end.  This is an example of  “Experiential compatibility” as the marketing folks like to say.   We are more comfortable with a technology that is compatible with our experience.

Often, there are other analog devices that survive the move to IP telephony.   For example, the credit card machine!  Many company’s will have another ShoreTel user named CREDIT CARD and it also is defined as EXTENSION ONLY.  These devices share one common trait that many clients find very annoying.   If you connect a fax machine or credit card machine to a ShoreTel analog port, the device will now need to know how to “dial 9” to get an outside line, to complete a call.   So these means that you have to reprogram the fax machine and the speed dial lists that most companies have accumulated over the years.  Not an exciting thought and a great waste of human resourcess.

Is there a way to “hack” l the ShoreTel configuration database to just connectthe fax machine  to an outside line without the need to “dial 9”?   The answer is yes, there is a way.   I hope that you have watched enough of my stuff to have loaded a copy of SQLyog on your ShoreTel Server by now?  In the MySQL configuration database for the ShoreWare sever, there is a data table named “USERS”.   In the USERS database, look for the column labeled EXTERNAL DIAL TONE.   Find the USER of interest, in this example FAX MACHINE, and locate this column.  You will find that the existing default value is 0, requiring the user to “dial 9”.   By changing this value to -1, the user is directly connected to an outside line and is able to dial without using an access code.  Be careful changing this configuration database!  If you do not know MySQL or SQLyog, you should probably find someone who does.    The film clip accompanying this blog will walk you throught the configuration change.   Enjoy!

Microsoft OCS + ShoreTel = IM

Microsoft Office Communications is a powerful collaboration tool. The MOCS provides web conferencing, IM, audio conferencing, desktop sharing and also provided SIP. For purposes of this brief discussion, we will stay focused on the Internet Messaging component of MOCS. With the Release of ShoreTel 8+, the Professional Call Manager provides both desktop to desktop video conferencing and Internet Messaging. The Internet Messaging component makes use of a Microsoft OCS server and the ShoreTel solution integrates the solution as an application server defined within the ShorewareDirector portal.

Internet Messaging, or IM as it is popularly referred to, seems to fall into two corporate philosophy camps: companies who absolutely abhorrer its use; and companies who find it to be an essential business tool. Those companies who do not allow IM of any kind typically have very tightly controlled employee desktops, enable website filtering and block IM ports for Yahoo, AOL, Google and others. Sometimes the excuse is HIPA/Sarbanes Oxley compliance or a general concern that employees might communicate private company information out this internet portal. Companies that find IM to be essential can be broken down into two additional categories: those that allow IM clients on an ad hoc basis and those who want total control of the IM client.

Microsoft OCS provides a solution for that last group of customers; those that need IM but want to control and monitor its utilization. MOCS enables you to “record” all IM conversations to an achieve server to meet those HIPA and Sarbanes Oxley compliance requirements and to assure the content of IM does not violate Corporate use policy. MOCS also enables you to set up “federations” so that inside IM participants across the Company can communicate with Yahoo, AOL or Other corporate MOCS users outside the domain. All in all, MOCS is the great unsung hero of the Microsoft Servers!

The integration of ShoreTel Professional Call Manager and the MOCS is not that complex, but falls under that summary statement “well know, to those who know it well”. Microsoft clearly has a VOIP strategy in which the MOCS plays a key role. Working with a ShoreTel IPBX and a Professional call manager, it becomes a viable solution for adding IM to and existing ShoreTel installation. The video is just a quick overview of how you actually deploy the integration.

ShoreTel Legacy Integraiton: ShoreTel as Voice Mail!

One of the more interesting aspects of PBX system installation in general and ShoreTel in particular, is the subject of Legacy PBX integration. There are a variety of reasons that a new ShoreTel installation might need to integrate with the old, in place or “legacy” PBX phone system. You might be installing the ShoreTel at the first location of a multi-site installation with the rest of the sites coming on line as older equipment leases expire. PBX’s typically use a tandem tie-line to join systems together. The ShoreTel, in this instance, would know the dial plan of the other PBX extensions and know which users lived in which PBX. If a ShoreTel user dials and extension number or receives a call for an extension known to live across the tie-line, the call is sent to the other PBX. The tie-line is typically define as part of a trunk group that outlines a list of “off-premise extensions”. The ShoreTel can also provide digit translation and manipulation to accommodate over lapping dial plans.

Increasingly, as ShoreTel grows in popularity and increased market acceptance, it is being asked to be the Voice Mail system for the legacy PBX. If you think about it, legacy PBX systems have traditionally been installed with separate Voice Mail systems. As it relates to market share, large corporate clients often have OCTEL voice mail systems that are now coming up on ten years after service life! Perhaps the telephone system is not ready for replacement quite yet, but the VM is about to die under its own weight. The ShoreTel makes for a great solution! Install the ShoreTel as a voice mail system for the legacy PBX. Then, as the opportunity allows, let it grow up and strangle the PBX as its obvious replacement.

We have been involved in the integration of Nortel, Avaya, NEC, Mitel and even a Toshiba key system to the ShoreTel as a PBX. We are now seeing growing demand for the ShoreTel to do both functions! The ShoreTel not only integrates as the new PBX with the old, legacy PBX to smooth client migration and transition; but it simultaneously provides VM for the users on the legacy PBX. Now how kool is that? ShoreTel as VM is a powerful migration strategy and a win/win for both client and vendor. Finding someone, however, that has a demonstrated competency in legacy integrations for both ShoreTel as PBX and ShoreTel as VM , complete with a client list that can be referenced is an essential element of a successful solution and implementation.

New family of ShoreTel SG voice enabled switches!

ShoreTel has a family of new media gateways. The more interesting switches are referred to as SGV switches. There is an SG50V and an SG90V that differ only in the number of FXO and FXS ports that they support. What makes these switches (i.e. media gateways) so interesting is that they have a LINUX kernel built in to support a Compact Flash Card which enables localized Automated Attendant and Voice Mail. In the world of ShoreTel’s “single image solution” we have the concept of a DVM (e.g. Distributed Voice Mail sever. The DVM are typically deployed at remote sites and, as explained in previous blog, provide for a level of resiliency (not redundancy) in your multi-site solution. More importantly, as the DVM enables Voice Mail and Automated Attendant to be localized at a remote site, it keeps these bandwidth intensive functions off your very expensive WAN.

For example, if I have a New York HQ site with users, media gateways and workgroup services; I might have a North Carolina remote site with a DVM, media gateways and users. Workgroups are currently NOT a distributed service, so any workgroup functions will require the HQ server. However, in North Carolina I can assign the users at that site to Voice Mail boxes on the DVM at that site. Callers to telephone lines that terminate on media gateways at that remote site will be answered with an Automated Attendant that lives on that remote DVM, eliminating the need to stream that media across the very expensive WAN. (Note: historically the media stream was G711 as it originated from the server regardless of the Inter-site codec. Recent release of ShoreTel enable a HQ media gateway to proxy the media stream enabling the use of the lower bandwidth Inter-site code). Should the DVM at the remote site fail, the HQ server would take over for the remote site. In this way VM and AA are still provide to the remote users.

The new SG50V and SG90V are typically used as replacements for or instead of a DVM at a remote site. The question arises as to what would happen if you added an SG50V or SG90V to a remote site under the control of a DVM? One would argue that it would make no sense to install these media gateway in that scenario. In the ShoreTel architecture it is important to note that DVM’s fail upward. For this reason we might install the SGV media gateway as a new site under the remote site. So in this example we might install a new site under North Carolina and put the SGV media gateway in that new site. Then we might move all the users at the North Carolina site to the new SGV media gateway for voice mail and automated attendant. In this way, the SVG should it fail, would have its services picked up by the North Carolina DVM; which in turn should it fail, would have all services picked up by the HQ server.

The new SGV switches are very interesting building blocks for the ShoreTel architecture and should be studied in some detail. They also might indicate a move by ShoreTel away from both Microsoft and VxWorks. This is only conjecture on my part and not based on any fact other than that we which can all observe. ShoreTel has dropped the Microsoft Access Database in favor of the MySQL database engine. Clearly this could be just a cost cutting move. However, the SGV switches, do not have VxWorks, they have a Linux kernel. Taken together these may in fact be an indication of a product road map that is moving steadily toward a total Linux based solution.  (Click here if Video does not load).

ShoreTel Linux Based Voice Switches

VoIP and SRST/AES Encryption!

Encryption of VoIP traffic was, for some of us a humorous concept. I remembered as a young development professional how much fun it was to use a packet sniffer to capture the bosses packets and reassemble his email over the LAN. Years before that when I worked at the phone company as a central office test engineer, it was not uncommon to find an interesting phone call and plug it into the over head paging system to provide entertainment for the late night test crew. There are times I still think the concept of encryption on VoIP is humorous, but it is becoming less funny all the time as we move toward end to end VoIP with no TDM at all in a world populated by terrorists and other evil doers. In any VoIP environment today, you can at some point use the usual tapping tools to capture a phone call as it hits the TDM gateway and is converted from VoIP to traditional analog or digital signals. From an induction coil to a line mans butt set, you can still intercept a VoIP call as it crosses the TDM boundary.


Now that VoIP is being used end to end, we do need to have a mechanism for encrypting at least the media stream. Today we generally do that with SRTP and IETF standard in combination with AES. AES or the Advanced Encryption Standard was adopted by the US Government and comprises three block ciphers: AES 128, AES 192 and AES256. Each AES cipher has a 128 bit block size with key sizes of 128, 192,and 256 respectively. This standard has generally replaced the former Data Encryption Standard or DES. It is important to understand the difference between encryption and authentication. Determining that a signal is “authentic” and originated from a source we believe to be authentic, and encrypting the contents of that communication are two very different issues. Media authentication and encryption ensures that the media streams between authenticated devices (i.e. we have validated the devices and identifies at each end) are secure and that only the intended device receives and reads the data. We need to encrypt both the media (i.e. the voice) and the signaling information (i.e. the DTMF). In most VoIP systems today, SRTO or secure RTO is implemented to assure media encryption. Understand that this encryption is not passed through to the TDM network, so once the media stream leaves the VoIP environment it is subject to eavesdropping.

Clearly as we are now able to employ VoIP end to end, SRST/AES encryption has very powerful ramifications for both the good guys and the bad guys!

How to backup your ShoreTel IPBX!

Prior to version 7 of  ShoreTel, backing up your ShoreTel system was very straight forward. There was a single folder in the root directory named d:\ Shoreline data. This folder contained all the information that was required to completely restore your ShoreTel system from a bare metal server in the event of a major disaster. The folder contained the configuration database, which at the time was kept in Microsoft Access. It also contained all of your recorded prompts for Automated Attendant, your voice mail messages, all of your Call Detail Records and softswitch related information. You could easily identify this one folder and make it a part of your normal system backup process for your company. With the introduction of Version 7 of ShoreTel the company began to migrate away from the Microsoft Access database and move toward the MySQL database. First they moved the Call Detail Records and with Version 8, the entire configuration database had migrated to MySQL. For this reason the database backup process for a ShoreTel system has changed. The process must now include the backup of two MySQL databases and the aforementioned Shoreline data folder. ShoreTel does provide a few BAT file examples of how you might do this, but if you want to automate the process complete with a schedule you will want to consider using some other tools. We recommend the use of SQLyog and include a copy on every server that we support or install (just another reason to have DrVoIP do your ShoreTel maintenance). Send an email request to drvoip@drvoip.com and we will send you a tech note that details this process or you can watch this silent video linked below!

How to Backup a ShoreTel IPBX Version 7+

Your ShoreTel Provider – What does it take to implement VoIP!

If you ask your average IT professional what a T span is, the usual response will be that it is a 1.5MB connection to the internet. Ask your average telecom tech what a T span is and you will be told it is 24 channels of dial tone! As a VoIP Engineer what a T span is and you should get the answer:, “what do you want it to be”? One of the great challenges of implementing a VoIP solution is the absolute requirement that the implementation team possess an interdisciplinary skill set. The solution demands expertise in a range of specialized skills including IP network, switching, routing, supplementary telephony services , server technology management and application call flow integration. If the user group is going to fully realize the benefits of a VoIP implementation, then each of these specialized areas of technology are going to be necessary to a successful deployment. Traditional telephony vendors are comfortable with all things TDM. They like to punch things down on 66 blocks and use “butt sets” to test for “dial tone”. Network professionals have their area of comfort as to Microsoft or Linux server professionals. Call Center professionals understand caller greeting, salutation, screening, call routing, message acquisition and message retrieval at the application level, but seldom understand the underlying technology. At the end of the day, you can shop the internet and find out who can sell you a shiny new telephone thing cheaper, but finding a team that can execute the delivery of a VoIP solution is worthy of the time you would invest selecting a new CFO! You need to work with a team that can demonstrate proficiency in each of the required discipline and accept responsibility for every aspect of the implementation. From concept to “go live”, the voip solution provider you select  must know the difference between a “dress rehearsal” and a “take”.

What is a ShoreTel DVM and why do I need one?

What exactly is the value of a Distributed Voice Mail Server (e.g. DVM)?   What are the pro’s and con’s of installing one?  Does it have any impact on resiliency (not redundancy) as it relates to business continuity in the event of server failures?  ShoreTel has a distributed architecture but like all other VoIP solutions there is only one “read/write” database and that is a component of the ShoreTel architecture aptly named the HQ server.   IF this server goes down and the R/W database is unavailable configuration changes can not be made throughout the “single image” installation.

Installing a DVM at the same level, or in the same site as the HQ server, provides a high degree of resiliency at comparatively low cost.     At the HQ site, put all your HQ users on a DVM.   If the DVM goes down, the HQ will pick up the heavy lifting for the Users on the DVM.  If the HQ goes down, the DVM users will still have VM and AA services.  As of today, there are three services, however,  that are NOT distributed in the ShoreTel architecture. These services are known as Workgroups, Route Points; and Account codes.   If you lose the HQ server, you will lose these services for all sites, even if they have a DVM installed at that site!

As it relates to low cost business continuity options, we like to install a DVM at the HQ site, but we want all switches at all sites to be managed by the HQ server.   This usually provokes a heady discussion, but here is our reasoning.   The real value of a DVM is to keep VM and AA media streams off the very expensive WAN connections. Remember that a DVM can fail up, which means the HQ server can take over Voice Mail and AA processing for the users at a site that has a failed DVM.   It makes sense to put the users at a remote site on the DVM at that site, but does it really make sense to have the switches at that site managed by the DVM at that site?

We think not.   Lets separate the issue of Users and Voice Mail from issues like TAPI, Workgroups and Personal Call Managers.   We need to remember that if a server goes down, the switches managed by that server will lose all the TAPI information for the phones that it controls.  This means you will have no functioning Workgroup Agents and not ability to monitor those Agents. Additionally, the Personal Call Managers will not work for any extensions on switches managed by the down server.

Given that Workgroups is not a distributed service, if the HQ server goes down, you will not have Workgroups anyway.   If the DVM at a remote site goes down, the HQ server will proxy for that sites Voice Mail and Automated Attendants.  Given that the HQ server was managing the switches at that remote site, you will not lose any of the PCM functionality highlighted above.  It occurs to us that this is a better place to be.   Let the HQ manage all switches and use the DVM’s for Voice Mail services for the users at remote sites!  Use a DVM at HQ for additional resiliency.

Voip Network Monitoring

We have been actively working with VoIP since 1999!   Since 2001 we have installed well over 10,000 ShoreTel desktops and one characteristic of these VoIP environments has surfaced into high relief on the radar screen here in technical support:  A VoIP solution is only as good as the computer Network it runs on! Network Monitoring – a Necessary Evil?  When someone mentions network monitoring, most network administrators immediately start thinking: overpriced, large server requirements, difficult to install, time-consuming to configure.  If those hurdles are overcome, then there’s a potential rainbow at the end of the road: Immediate notification of problems, faster problem resolution, less downtime of services.  That equates to happier & more productive users, and a more profitable organization. What’s interesting to realize is that the vast majority of companies all want to know the same things with their network:

  • When do problems happen?
  • Where are the problems?
  • Why do these problems exist?

We have decided to create a product that eliminates all of the hurdles and answer these same questions no matter how large or complex a network was deployed.

We can now:

  • Deploy and auto-discovers your entire network in just a few minutes
  • Continuously monitors the health of every device and interface on your network

This allows for some proactive analysis that includes:

  • Quickly learn which interfaces in your entire network are discarding packets
  • Perform a call path mapping of the health of every interface used in a VoIP call
  • Run a call simulation from any computer to any IP endpoint (including router interfaces)
  • Know what your current Internet utilization is – live (updated every 2.5 seconds)
  • Learn the switch and port where your VoIP phones are connected

Contact us today and we will send you a FREE completely operating network monitoring system for your evaluation.  Send a return email that lists:

  • Company Name
  • User Name
  • User email address
  • User phone number

And we will email you the download link and evaluation license code! Our only requirement is that you be a ShoreTel  system user.!

networkmonitor