Cloud, Hybrid, or On Premise? Where’s the Skype for Business PBX?


I’ve recently taken an interest in the many different voice deployment options available with Skype for Business.  Traditionally this would mean an on premise deployment with on premise PSTN breakout however in recent years cloud based pbx functionality has become a reality, although at this point in time, not all deployment types are created equal. Depending on what feature set is required Skype for Business may be deployed on premise, hybrid, or online.  Some of the deciding factors when choosing which deployment model that will suit your needs best are what call control and features are required, and does your Office 365 tenant provide PSTN calling services.

Voice deployment options include

  • On Premise Enterprise Voice
  • Cloud PBX with PSTN Calling Services
  • Cloud PBX with On Premise PSTN Connectivity that include a couple of variations
    • Skype for Business Cloud Connector Edition
    • Existing On Premise Deployment

Some basic questions that can help decide on what deployment solution is best for you include

  1. Is an advanced call control feature such as response groups required?  If so then these accounts must be homed on premise.
  2. Is the Office 365 deployment in a region that offers PSTN calling?  Not all regions currently support this feature, including Australia.
Basic vs Advanced Call Control 

Because on premise and online feature parity does not currently exist it’s extremely important to have user accounts homed in the correct location.  Whilst basic call control is possible on premise and in the cloud only an on premise deployment can cater for advanced call control and full Skype for Business feature set.  Some of the differences include –

Basic Call Control (On premise & online)

  • Call Initiation/Call Answering
  • Call Forwarding/Simultaneous Ring
  • Call Hold/Call Retrieve
  • Call Delegation
  • Call On Behalf

Advanced Call Control (On premise only)

  • Response Groups
  • Call Pickup Groups
  • Call Park
  • Auto Attendant

Deployment Options

On Premise 

All Skype for Business server roles are deployed on premise.  This may include standard or enterprise edition servers with on premise PSTN connectivity.  This is the only option that should be considered if advanced call control is required for all accounts.  In addition to advanced call control an on premise deployment caters for additional functionality such as PIN authentication, common area phones, and privates lines.

In Summary

  • All Skype for Business server roles deployed on premise
  • Users homed on premise
  • All Skype for Business features and call control available
  • PSTN connectivity is located on premise
Cloud PBX with PSTN Calling Services

Full cloud deployment utilising Office 365 and Skype for Business Online.  Users are homed in the cloud with basic call control, and through an additional add-in PSTN connectivity is provided by Microsoft.  This option is appealing if no on premise deployment is required.  Keep in mind some of the limitations include

  • Only basic call control functionality and limited feature set is available.
  • Availability restricted to US, Puerto Rico, and UK
  • PSTN connectivity provided by Microsoft.  Do not expect to be able to route calls via on premise PSTN.
Cloud PBX with On Premise PSTN Connectivity – Skype for Business Cloud Connector Edition 

This deployment option should be considered if not all Skype for Business features including advanced call control is required.  This is a hybrid deployment with all Skype for Business accounts located in the cloud whilst PSTN connectivity is provided on premise.   On premise a minimal Skype for Business topology is deployment called cloud connector edition that consists of a CMS role, Edge, and Mediation component.  This option will suit if

  • All users will be located in the cloud
  • Advanced call control features not required
  • No existing on premise Lync or Skype for Business deployment
  • Want to continue using existing carrier
  • PSTN Calling services not available in Office 365 region
Cloud PBX with On Premise PSTN Connectivity – Existing On Premise Deployment 

This deployment option should be considered if an existing on premise deployment including PSTN connectivity is currently in use and you’d like to migrate some or all accounts to the cloud.  The on premise deployment is stretched to include Office 365 and  accounts can be enabled in either environment.  Accounts homed on premise still have the full feature set whilst cloud based accounts do not and this should still be the main consideration on where you’ll place each account.  This may be the ideal solution if only the basic feature set is required for all or some accounts, or if you’d like to dip your toes into the cloud pbx environment for testing purposes.   This deployment may consist of

  • Users located on premise and in the cloud
  • Hybrid deployment consisting of an on premise deployment and Office 365.
  • Accounts requiring full functionality homed on premise
  • Accounts requiring basic functionality homed in the cloud
  • PSTN calls route via on premise and where PSTN calling services not available
So what’s the answer? 

I think there’s a small number of questions that help decide how you will deploy Skype for Business

  1. Do I require advanced call control and all features available with a Skype for Business deployment for all accounts?  If yes then you’d want to deploy both Skype for Business and PSTN connectivity on premise
  2. Is PSTN calling services available in my region?  If no then there is no other choice than to have an on premise or hybrid deployment.   Accounts could be located either on premise or in the cloud depending on required functionality and PSTN connectivity would be provided on premise.
  3. Is this a new Skype for Business deployment and do I only require basic functionality?  If yes and you reside in a region providing PSTN calling then all services can be located in the cloud.  If PSTN calling services do not exist in your region then a hybrid deployment with cloud connector edition would suit.

For more information on what features are available when accounts are enabled in the cloud visit –

Microsoft Teams – Under the hood and membership administration.

Microsoft Teams is the latest application to be released on the Office 365 platform.  Teams is Microsoft’s answer to the latest generation of persistent chat products currently available on the market.  With further updates and expanded integration with other O365 products it could see considerable uptake.

I decided to take a look at what happens when a team is created to better understand the moving parts underneath the hood and if this could assist when administering individual teams such as modifying membership and owners.  If Teams become popular and begin to proliferate then finding a way to automate or simplify the administrative tasks involved would be beneficial.

Whilst no powershell module created specifically for Teams is currently available there are portions of the solution that can be administered by powershell such as Office 365 groups however I found this brings a mixed bag of results.

To be fair to Teams is a very new application and I wouldn’t hesitate to believe Microsoft will be focusing a lot of energy to deliver a compete solution to reach its full potential.

What happens when you create a team

When creating a team within Microsoft Teams using either the desktop app or web client a number of things occur behind the scenes

  • Office 365 Group is created.  Group members are granted access to the team and content.  Group owners have additional administrative rights.  By default Teams belong to private groups.
  • Sharepoint site created to host content

Microsoft Teams makes use of Office 365 groups as they grant access to resources and reference sharepoint for additional functionality such as shared workspace for conversations, files, and calendar events.

The first thing I did was to create a couple of groups.  Below you can see teams as seen from the desktop app, the related Office 365 groups, and sharepoint site.

Example Teams after cretion

When a team is created a corresponding Office 365 group is created

Some of the Office 365 group attributes utilised by Teams

Sharepoint site automatically created for a team

Modifying Teams using Powershell

Because Teams groups rely on Office 365 groups I decided to see if it was possible to add Team members via powershell using the following command

add-unifiedGroupLunks testteam2 –linkType Members –link

A few moments after adding the account to the Office 365 group Test Team 2 appreaed in the application.   
Test Team 2 is now available

The next step was to test removing members via powershell using the following command
Remove-UnifiedGroupLinks testteam2 -LinkType Members -Links 

The group then disappeared from Teams
Access to Test Team 2 has been removed

So far this looks to be a viable method of adding and removing team members.  However once an account has been removed from a teams corresponding Office 365 group using powershell there was an issue if the account was re-added.  Whilst the account is now a member of the Office 365 group the team would never show to the user within the application.

Account for Paul Maggs re-added to Office 365 group as a member

Team does not update to reflect this change

Re-adding accounts to the team was still possible when an owner granted access from the application.

Unlike re-adding accounts via powershell which was unsuccessful it was possible to continually remove accounts from an Office 365 group to revoke access.

Another scenario was adding team owners via powershell using the following command

Add-UnifiedGroupLinks testteam2 -LinkType Owners -Links 

Account for Paul Maggs now has owner rights

The same occurs if an account is re-added to the Office 365 group as an owner.  The account will display as an owner when querying the Office 365 group however will not have owner administrative rights available from within the application.

Paul Maggs account is listed as an Owner

Owner controls not granted in Teams web app when account added to Office 365 group using powershell.

It’s quite clear adding Team members and owners works best using either Teams web or desktop app.  There may be additional steps available to correctly assign permissions using powershell however I am unaware of them at this point in time.

A few other things I learn’t from this process  –

Team display names do not need to be unique and this is also reflected with Office 365 groups  –

Duplicate team names

Duplicate Office 365 Group name.  Note smtp address is unique

Even though the group names are the same a number of unique attributes exist.  Here’s an example of a few –

If you’re planning on deleting any Teams then I suggest you do so using the Teams web or desktop app and by doing so the deleted team is no longer viewable.  The office 365 group is also removed however the sharepoint site seems to remain.  I’m not overly familiar with Sharepoint so there could be additional tasks that need to occur.

Another thing that seemed rather strange was if a Teams Office 365 group is deleted then the Team is still remains in the Teams web or desktop app and I could continue to view and add to persistent chat however files and notes were no longer available.