At this point, pretty much everyone is aware of how important communication is in today’s corporate environment, and how vital it is to running a company smoothly and efficiently. Different technologies have been developed to meet this need and provide faster, better, and easier communication between people (or groups of people). Imagine how difficult your work life would be if there was no email, phones, or instant messaging available and you needed to talk to your coworker. You would have to walk to their desk and talk to them face to face…
Thankfully, communication technology allows you to communicate with anyone from anywhere. It has also allowed for corporations to expand at a much faster rate. Imagine the same scenario above, but instead your coworker/manager is in New York City, while you are sitting in a branch office in Los Angeles.
With that in mind, we can see how important communication technology is to making corporations more efficient, more responsive, and more adaptable.
In this article, we will be looking at Microsoft’s Skype for Business Server (SfB) and its’ capabilities in an on premise deployment (i.e. the servers are hosted/maintained in your datacenter rather than the cloud/O365) for communication. SfB was released in April 2015 and is essentially a rebranding of Microsoft’s previous communication solution, Lync. This will be a basic rundown of SfB’s functionality and components in an on premise deployment. Think of it as Skype 101; it will be aimed at those who are new to the application and are not quite sure what everything means or how to understand SfB’s topology.
In order to start planning a SfB deployment, we will need to define what our sites are. Sites act as a container for your SfB servers and are also used as an organizational tool for maintaining different SfB environments. You may have different infrastructure or configurations in one site than in another, so having separate sites allows you to manage your environments through the same console.
Front End Servers
Both the Standard Edition server and the Enterprise Front End pool will provide the core functionality of SfB. The Front End pool (along with a Back End server) is the only server role that is absolutely required for any SfB deployment. If deploying the Front End pool by itself, you will only have Instant Messaging (IM), conferencing, and voice/video calls available to your internal users. Additional functionality such as external dialing, web conferencing, and presentations will require other server roles to be deployed.
Back End Servers
The Back End server will not be running any SfB software, but it will run SQL databases that serve as backup stores for the Front End pool. Basically, the Back End server is just a SQL database server that the Front End pool points to for backing up SfB data including information about users, conferences, chats, presence, and contact lists.
Ahh, the Edge Server…probably my favorite part. This is the first of the optional roles and also the one that will have the greatest impact on the functionality of your SfB deployment. It is potentially the most complex, but we won’t dive into too much technical detail here. The Edge Server role allows for the services hosted by the Front End pool on your internal LAN to be accessible via the internet by external users. Also, if you plan on deploying Enterprise Voice (with voice calling via PSTN, DIDs, and dial-in conferencing), then this will be one of the required server roles you will need to deploy.
Edge Servers also provide services such as federation and mobility. Federation allows you to connect your SfB environment to another company’s SfB environment, so that both companies can communicate with each other via IM, voice/audio calling, and conferencing.
Mobility services allow users to install SfB on their mobile device (smartphone, tablet) and be able to send/receive IMs, view contacts and presence, and join conferences. If Enterprise Voice is deployed in your environment, then the SfB app can also function as a softphone.
The mediation server role is the other piece needed for deploying the full capabilities of SfB and is required for implementing Enterprise Voice in your environment. This allows SfB users to have DIDs (Direct Inward Dial – 10-digit numbers for direct dialing), make and receive phone calls via PSTN, and use other phone features (softphones on laptops/mobile devices, voicemail, call forwarding).
The above components form the core of SfB functionality, but there are other pieces you can add to provide a bit more functionality to your environment.
- Office Web Apps: OWA is used to provide access to Word, Excel, PowerPoint, and OneNote files from within your browser. Specifically, SfB uses OWA for handling PowerPoint presentations from within the SfB client.
- Director Server: The Director Server itself does not provide any SfB services to the user; its use is to add a layer of security in a deployment that allows external users to access the SfB environment. The Director Server (or Pool if working with a large deployment) authenticates requests from external users before redirecting them to the Front End pool. If there were an attack on your SfB environment, it would be stopped at the Director Server rather than possibly impacting your Front End pool.
- Persistent Chat Server: Configuring a Persistent Chat server allows users to set up conferences that persist over time. Conference chat history and information about conferences (such as IMs, links, and files shared) are stored in the Persistent Chat server to be reviewed at any time.
I will end this article by saying that SfB is only one of many solutions that allow people to communicate. Depending on your budget or the needs of the company, you may end up looking into other applications or even setting up a SfB subscription in O365. SfB is a strong choice because it is a modular, flexible, and all-in-one solution that is customizable for each individual environment. You can have a single server providing basic IM and internal voice/conferencing, or you can have a massive global deployment with multiple sites/servers, redundancy/fault tolerance, and provide voice, web conferencing, and IM capabilities to all your users no matter where they are in the world.
Assuming, of course, they have some kind of network connection to the outside world. You may have some slight issues in the Arctic regions…