When planning for a full Skype for Business voice deployment there are a number of elements which should be aligned and setup properly for a smooth transition. This is an introduction article for a series where I’ll provide some insight on what info you need to collect and understand for a successful PBX replacement within your organization.
Deploying any PBX replacement can be a daunting task and Skype for Business is no exception. There are the many moving parts to consider in your plans. This includes (but is not limited to) the Skype for Business and Exchange server architecture and deployment, current WAN and PSTN site local infrastructure readiness, and devices to select and deploy for the end users. There are many guides out there for deploying and designing your servers and even on selecting your devices but one aspect of a deployment that I don’t see covered quite well enough is the actual PBX assessment and replacement on a per site basis. I’m hoping fill this gap a bit with some tools, checklists, and tips that I’ve put together.
I’ll be upfront and state I believe much of this information is PBX agnostic and can be applicable for any phone system upgrade. But I do target Skype for Business though so you may want to bone up on your nomenclature. Instead of reinventing the wheel I’ll point you out to another excellent set of articles by Jonathan McKinney that I consider not so hidden gems of knowledge that everyone should have when deploying Lync/Skype for Business as a PBX.
If you have made it this far then great! That means you have more than just a passing interest in taking the next steps of what can be a difficult but rewarding process for your organization. These rewards go beyond simply removing an old (and often failing) PBX gone from your life as well. There are real and tangible cost savings to be had in undergoing this process, sometimes in areas which may surprise you. Simply going through the discovery process may bring to light expensive PSTN lines which are not in use, nonsensical dial plans, or ridiculous processes people undertake (like faxing between offices).
Unsurprisingly, there are multiple phases to a Skype for Business and Exchange based unified messaging deployment before you ever get to the point of deploying enterprise voice though. Lets go the overarching deployment phases for the entire organization in this first article. This is primarily focused around on premise deployments but generally holds true for Office 365 hybrid as well (where Phase 1 and 2 are kind of merged).
Phase 1 – Internal IM and Presence
This phase includes deploying the Skype for Business client to end user workstations and devices for internal or VPN connected end users. In phase 1 the active directory environment is prepped and internal Skype for Business front end pools are created. SIP domains are determined and then used used to create a basic Skype for Business topology. At the end of this phase most enterprise users should be able to use their Skype for Business enabled devices and workstations to communicate and collaborate internally with direct Skype for Business to Skype for Business communications. This internal collaboration capability includes voice, video, and application sharing. On premise deployments might include the office web application services as part of this phase as well (if they are not already in the environment for Sharepoint or other reasons).
Phase 2 – Edge Access, Mobility, and Federation
This phase consists of configuring Skype for Business servers at the edge of the network and includes setup of one or more Skype for Business edge access servers, external IP addresses, and DNS addresses. The edge services allow for non-VPN connected enterprise workstations to still use the Skype for Business client securely from the outside network. The edge services also allow for direct Skype for Business communication with other federated services (such as Skype and XMPP based IM services). Optionally, you can also configure selective or open federation at this time for cross organization Skype for Business communication with your business partners.
By the end of this phase your users will be able to utilize the Skype for Business client across many devices both on and off your network. This is also an ideal phase to discuss and re-architect the edge of your network (if required) to accommodate one or, ideally, two DMZ’s for increased security.
Note: This phase usually includes setup and configuration of reverse proxy services directly from the external network to your internal Skype for Business pool. The reverse proxy services are used for Skype for Business access from mobile devices and the Skype for Business web client among other things.
Phase 3 – PBX Integration
Up through phases 1 and 2 Skype for Business is capable of being used between Skype for Business capable devices within and outside of the organization. You can also host Skype for Business meetings that can be joined over the web. What you cannot do is dial a number from your phone to call a Skype for Business user or meeting. Phase 3 extends the Skype for Business infrastructure out to the public phone network by integrating with the current PBX to enable PSTN usage and overcome this limitation.
Skype for Business can be deployed to entirely replace the existing PBX infrastructure or, in many cases, be integrated in with a SIP capable phone system. In this phase we focus on PBX integration instead of replacement. This integration is typically limited a small handful of users or conference number as a proof of concept for the business. Some organizations stay at this integration level and go the route of setting up something called ‘remote call control’ enabled users (which is mutually exclusive from enterprise voice enabled users). This might be done if there is a significant investment in the current PBX and phones that are connected to it. This requires vendor specific client plugins and can be quirky to setup and maintain and is not an encouraged route to take from Microsoft’s perspective.
With PBX integration it is common to replace existing third party conferencing solutions (i.e. WebEx) at your central office. You can also realize your current phone infrastructure investments longer with some extra work and configuration. This entire phase is reliant upon a supported IP based PBX and may not be possible in every environment. In these cases an organization might go directly to Phase 4.
I like to split this phase out into two possible scenarios. In one scenario we are looking a coexistence using a VoIP gateway. This essentially puts a new device between the existing PBX and your PSTN provider and splits out call flow depending on factors like AD attributes for users. This is not an option for environments which do not have a SIP capable PBX.
Otherwise you can simply integrate Skype for Business with your existing PBX. You will see this being done for most VoIP capable PBXes. This leaves the onus to the PBX to route inbound calls to Lync intelligently. What you need to be aware of in this situation is that eventually you will need to move in and outbound call flow to another gateway device (coexistence) if you are to remove the old PBX anyway. Integration can be a nice temporary solution for testing out Skype for Business PSTN capabilities though.
Phase 4 – PBX Replacement
When Skype for Business is integrated with your PBX you are left with two infrastructures to maintain and support. Number assignments become more complex as knowledge of two systems becomes necessary. Your dial plans and routes also tend to be more complicated and error prone. But with the correct hardware purchases an organization might opt to entirely replace their existing PBX with Skype for Business. A full Skype for Business voice solution opens a wide range of possibilities for your end users and can reduce costs over time. When you fully replace your existing PBX you can physically replace phones with Skype for Business compliant devices, and you can have phone numbers which follow employees everywhere from their cell phone, to their iPad, to their physical phones.
Now that we are all on the same page we can start to look at better preparing yourself for Phases 3 and 4 of your migration. To do this we will need to better understand your current phone system and provider configuration. If you had enough foresight to plan for enterprise voice instead of it organically happening in your environment then it should be noted that you can begin much of the information gathering for the final phases of the deployment while you are implementing the first phases.
If you like the diagrams in this article I’ve uploaded them into Github for your convenience and reuse. Stay tuned for part 2 of this series where we will talk about the importance of being nice to people so we can get the information we need to help make your voice deployments easier.