Office 365 Usage Location and Skype for Business Online

Questions often arise in Skype for Business Online (SfBO) administration regarding the a user’s registered “location”.  In the SfBO admin center we see it as the location field in the user listing as shown here:


This subtle setting is important for the voice Phone System calling plan (PSTN) service configuration in SfBO because it restricts what phone numbers can be assigned to a user, and their associated emergency location.  Specifically, only registered emergency locations (addresses) that belong to the same country as a users’ location can specified for that user. In addition, when assigning phone numbers to a user, only acquired numbers in the same country are available for assignment.

This is usually only confusing for multi-national companies when the location attribute is not accurate, or when user relocations occur.

So Where does this Location Come from and How is it Set?

Like many user configuration properties, this Location property is sourced from the underlying Office 365 tenant user configuration, which is sourced from the underlying associated Azure AD tenant.

In Office 365 it is known as the UsageLocation attribute.  It is an important attribute in Office 365 because it determines what Office 365 Licenses and and associated features can be assigned to a user based on geographic availability and laws. For example, a Calling Plan add-on service might not be available in Australia, and if a user has an Office 365 Location of Australia, that user account cannot be assigned the Domestic and International Calling Plan add-on available to the tenant license.

Where is this setting in the Office 365 Portal?

Note, the UsageLocation setting is different from the address configured in the Contact Information configured on the user (and it does not have to be the same). Because this setting directly impacts what Office 365 licenses are available to a user, it is the first setting displayed in the O365 Admin Portal by navigating to Users | Active users | select a user | Edit Product Licenses as shown here:


Where did the Value for this Setting Originally Come From?

This is a common question because the UsageLocation was usually set without explicit attention to what the default value should have been when the Office 365 tenant was originally provisioned.

There are two primary origins for the user value of UsageLocation:

  1. Local Active Directory
    • If the underlying Azure AD tenant is synchronized from on-premises AD (e.g. using AAD Connect), this value was likely set from the directory synchronization.
    • By default, I believe AAD Connect configuration uses the on-premises msExchUsageLocation attribute to populate the UsageLocation by default, but do more research on that because that can depend on the environment. Either way, you can customize an AAD Connect synchronization rule to use whatever attribute you want.  A good article on doing that is available here:
  2. A Default Setting in the Office 365 Tenant
    • With a pure online Office 365 tenant, there was default setting for the tenant location that was the default UsageLocation of users that corresponded to the country tenant Organization profile.  I can no longer find this setting in the Office 365 Admin Center. I believe it is moved to the “Country or region” setting in the associated Azure AD tenant as shown here in the AAD Admin Portal:


How do I change it?

If it is a one-off change, or only a few users need that Location updated, it can be done through the Office 365 Admin Portal as shown above.

There is a good chance you will need to use PowerShell for anything more than a handful of user changes.  There are plenty of PowerShell examples of doing this, and/or assigning Office 365 licenses, so I won’t re-hash it here, but for reference, the Office 365 / Azure AD v1 (aka MSOnline) module has two cmdlet’s that can be used to read and write this setting on a user:

> Get-MsolUser -UserPrincipalName | select UserPrincipalName, UsageLocation

> Set-MsolUser -UserPrincipalName –UsageLocation <2 letter ISO Country Code>

There are equivalent cmdlet’s in the Microsoft Azure AD v2 PowerShell Module.

Tips for Transitioning from Skype for Business Hybrid to Pure Online

As Office 365 adoption grows, more Skype for Business (SfB) hybrid deployments are being transitioned to pure online after all of the users have been migrated to online. While some steps in this final transition process are well documented, such as the decommissioning of the SfB on-premises servers, other steps are poorly documented.

This post provides some details on one step of the transition to pure online that isn’t well documented: removing the SfB user attributes (e.g. msRTC*) in on-premises AD from users after hybrid mode has been changed to pure online. This post assumes that the hybrid environment has AD directory synchronization configured (e.g. on-prem AD was synchronized to Azure AD).

Why do we Care about SfB On-Premises AD Attributes after all Users are Migrated and Hybrid is Switched to Pure Online?

This is a good question, and there is no official documentation. However, two reputable sources reference deleting these on-premises AD user attributes after migration (or a when doing a full cut-over), but without much explanation:

As stated in the first article mentioned above, the recommended method to clear those on-premises AD user attributes is to use the Disable-CsUser (e.g. Get-CsUser -Identity| Disable-CsUser -Verbose). In field experience this sometimes does not fully clear the msRTC attributes, and in at least one deployment I have seen it leave behind the msRTCSIP-DeploymentLocator attribute.

So why do we need to clear these attributes? After doing some research, it seems the risk of not clearing those user attribute on-premises is that some SfBO features – specifically voice features using Cloud Connector Edition (CCE) – will use those msRTC* attributes to determine where the user resides (on-prem or online). Specially after the switch to pure online is completed (e.g. DNS records point to online, etc…), CCE will see those synchronized Azure AD attributes, or the InterpretedUserType attribute set as “HybridOnline”, and conclude that the user voice services are still serviced by SfB on-premises, and attempt to direct the calling services to on-premises. The calling features will fail because the SfB on-premises is no longer operational.

What is this InterpretedUserType attribute?

This is another good question with little documentation. The InterpretedUserType attribute has two values which reflect whether a user is in hybrid mode (value = “HybridOnline”), or pure online (value = “PureOnline” or “DirSyncedPureOnline”).

From what I can tell, SfBO sets this value based on the presence of the msRTC* user attributes in the underlying Azure AD user object. Meaning, if the user object has those msRTC* attributes, InterpretedUserType is set to “HybridOnline”.

If the remaining msRTC* attributes are cleared in AD on-premises and synchronized into Azure AD, it appears SfBO will see those blanked attributes and change InterpretedUserType to “PureOnline” or “DirSyncedPureOnline”. Any features such as voice features in CCE will then know to properly use SfBO.

If you have any thoughts on manually manipulating this value, it cannot be set manually with PowerShell.

Should I Remove the Remaining SfB/Lync User Attributes from On-Premises AD?

This step is documented in the two reputable Microsoft sources above, and is recommended. My initial concern with doing this is that it would break integration of some existing on-premises applications or clients; specifically Outlook integration with the Skype for Business or Lync client.

This integration is purely client based integration as there is no server-side API’s used per se. Meaning when a user see’s the SfB presence for another user in Outlook, it is the Outlook client is retrieving that from the SfB or Lync client running on the same desktop. It is actually the Skype for Business Outlook Add-In, and not Outlook itself.

A good write-up on this integration is available here: Skype for Business and Outlook : Presence information on Outlook – how to get it ? Answer is here (with “the Ugly, the Bad and the Good” illustration scenarios)

Although this is client-side integration, I have read forum references stating that Skype for Business Outlook Add-In uses the SIP address to establish the link, so if we clear that attribute won’t the integration break? The next section explains that.

Note: the reverse integration – the Skype for Business client integration with Exchange  is a bit different. This is not pure client-to-client integration. It uses an API, Exchange Web Services (EWS), to retrieve free/busy, store conversation history, and other information. The bigger dependency here is that the SIP address used in the SfB client matches the email address.

ProxyAddresses vs msRTCSIP-PrimaryUserAddress Attribute

Back to the question of possibly breaking Outlook or Outlook Web App integration if we delete or blank the msRTCSIP-PrimaryUserAddress attribute.

The Outlook client (via the Skype for Business Outlook Add-In) will use the SIP address in the list of email addresses in the ProxyAddresses attribute to establish the link to the SfB client for integration.

Generally the answer is that we should populate the users proxyAddresses attribute with the SIP address. I use the word ‘generally’ because there are many sources (such as this one) which refer to Outlook needed the SIP address in the proxyAddresses but I have seen Exchange integration (Outlook 2016) work without either (with Exchange on-premises and SfBO). It likely depends on the hybrid configuration and clients used.

When using Exchange Online, the Outlook Web App does need the SIP value in the proxyAddresses attribute, so my recommendation is to populate it with the SIP address and fully remove the msRTCSIP-PrimaryUserAddress as part of completing the move to pure online.

Another Reason to Populate the SIP Address Value in the ProxyAddresses Attribute

When a user object is synchronized to Office 365 their UserPrincipalName (UPN) is used to provision the identity and service addresses for Exchange and Skype for Business Online.

In some enterprises, this UPN does not match the users email or SIP address, which breaks the golden rule for smoothly integrating Exchange and SfB integration. That is, the user’s SIP address should match their primary e-mail address.

One way around this problem, is to set the msRTCSIP-PrimaryUserAddress attribute in the associated on-premises AD user object to be the same as the email address. However, in this case, where we have just completely the transition to pure online, and deleted this attribute, this can’t be used.

As fellow MVP Mark Vale documented here, a way around that is to populate the ProxyAddresses value with the properly formatted SIP address and let dirsync populate it in Azure AD. SfBO will then use this value as the SIP address, which will match the email address, and not the UPN.

I hope that helps in your journey to pure online!

5 Tips for Skype for Business Modern Authentication Scenarios

The world is adopting multi-factor authentication, and Microsoft is rapidly adding support in their server, services, and clients to support it. Microsoft’s name for multi-factor support is Modern Authentication (MA) and support has been added for Skype for Business Server (SfB), Exchange Server, and more recently, the equivalent online cloud services (Exchange Online and Skype for Business Online).

In practice, with potentially a decade of legacy client versions, and a now matrix of possible SfB and Exchange hybrid topologies, supporting MA for all the users in an enterprise requires some planning.

There is plenty of good documentation about how to enable MA both on-premises and online. This article highlights 5 specific things you’ll want to have answers to before enabling MA in an enterprise.

1. Pay Attention to Supported Topologies for Hybrid – Especially the Supported Exchange Topologies

As we all know, Skype for Business (SfB) is highly integrated (and therefore dependent) on Exchange, which increases the matrix of topology scenarios. MA is not supported in all scenarios of Exchange and SfB MA, or requires special configuration. There is a very good TechNet article which clearly describes what mix of Exchange on-premises, SfB on-premises, Exchange Online, and SFBO topologies support MA:

> Skype for Business topologies supported with Modern Authentication ( Authentication in Skype for Business)

I want to highlight a couple key points:

  • Exchange Integration and Mobile Clients will not work for SFB on-premises with MA and Exchange on-premises with no MA.
  • Exchange On-Premises and SFBO with MA is Supported (a common scenario). Azure AD needs to be the identity provider for SFBO, and on-premises AD needs to be the identity provider for Exchange on-premises.
  • Multiple Prompts for Users: the TechNet article referenced above calls out an important point that will happen if MA is not enabled equally across all the server resource the SfB clients are using (e.g. the related Exchange resources):

    “It’s very important to note that users may see multiple prompts in some cases, notably where the MA state is not the same across all the server resources that clients may need and request, as is the case with all versions of the Mixed topologies. Also note that in some cases (Mixed 1, 3, and 5 specifically) an AllowADALForNonLynIndependentOfLync registry key must be set for proper configuration for Windows Desktop Clients

2. Plan for Client Support

If SfB has been used in an organization for several years, there are likely a wide variety of clients out in the wild such as older Lync clients on unmanaged devices, Office 2013 and Office 2016 clients, and mix of mobile Android, iOS, and Windows Phone versions.

A summary of the various client applications and the associated modern authentication support for Office 365 is available here: Updated Office 365 modern authentication. In a nutshell, any Skype for Business client version that is not part of Office 2016 (or later) will not have built in support for Modern Authentication.

For the Skype for Business client specifically, here is a summary of that support:

  • Office 2016 – built-in support
  • Office 2013 – and updated client and two registry keys are required (see Enable Modern Authentication for Office 2013 on Windows devices)
  • iOS – yes, but watch the caveat if you are in a SfB hybrid shared namespace scenario (see below)
  • Android – yes, but watch the caveat if you are in a SfB hybrid shared namespace scenario (see below)
  • Windows Phone – not supported yet

The supported client list is similar for Skype for Business Server on-premises

3. App Passwords can be used for Legacy Skype for Business and Lync Clients using Office 365

There is another option for legacy non-MA clients (e.g. Office 2013) clienst This is a somewhat cumbersome option for end users, but a viable option for those users that require legacy clients (client versions that do not natively support MA such as Microsoft Lync and Skype for Business client in Office 2013).

The App Password option involves the end user signing into the Office 365 portal and creating a special app password that is used in legacy clients and bypasses MA. The big drawbacks are that the app password is yet another password the user needs to have available and ready to use. It is auto-generated and difficult to enter on a mobile device.

The process of a end-user configuring an app password is described here: Set up multi-factor authentication for Office 365 users.

One major limitation to be aware of is that this option is not available in hybrid as described here :

App passwords don’t work in hybrid environments where clients communicate with both on-premises and cloud autodiscover endpoints. Domain passwords are required to authenticate on-premises. App passwords are required to authenticate with the cloud.

4. Mobile Clients will not Work if MA is Enabled for SfB Server On-Premises and SfB Online in Hybrid

This one scenario is easy to overlook, so I wanted to highlight it.


Modern Authentication for mobile clients is not yet supported in the following deployment topologies:

  • Exchange Online with Modern Authentication turned on and Skype for Business on-premises without Modern Authentication turned on.
  • Skype for Business Server 2015 and Skype for Business Online in a split domain hybrid configuration (for example, SharedSIPAddressSpace = true) with Modern Authentication turned on for both Skype for Business Server and Skype for Business Online

5. Update those Mobile Clients

Even with supported MA topologies, I’ve seen mobile clients have sign-in problems after MA has been enabled. Several times updating the mobile client – specially iOS – the latest-and-greatest as solved the issue. There are also mobile client side logs which can be useful in tracking down MA sign-in problems.

For example, one user could not sign in with MFA for the iOS Skype for Business client version  Upgrading to 6.17.3 (released Nov 15, 2017) worked.

More Information

Tip - How to Mute the Audio in a Skype for Business Call

I have talked to several people lately who have had the need to mute the audio coming from a Skype for Business meeting or web conference.  Not mute their microphone, but the speaker/headset audio stream from the conference.  They they are needing to listen to something else  – take another call, listen to music while they just watch the conference, or even trying to participate in two conference calls at the same time.

They have struggled in the Skype for Business 2016 client on how to control this, so I wanted to pass along a couple of tips.

The simplest option to just mute the incoming audio stream is using the volume controls on the call control icon in the client. As shown below, you can either fully mute the audio, or reduce the volume.


Another option is to use the “Hold” control on the same Call Controls (as shown with the ‘pause’ icon in the screen shot above). My web conferences are all VoIP audio, so many users do not realize they can put the audio stream "on hold", just like a regular phone call.  This is nice for momentary interruptions where you just need to pause the audio, do something, and then resume it.

Putting the call on-hold has some pros and cons. When you put the call on hold, a visual indicator updates in your participant entry which let’s other participants know that you have the call on hold and are not available right now, as shown here:


Another advantage is that you can a periodic ‘beep’ reminder that the call is on-hold, so that you know to return to it if you get disrupted or distracted.

A major disadvantage one reader pointed out is that a Skype for Business user can choose to configure their client to Play Music On Hold. Obviously this would be a major distraction for the rest of the participants if you put the call on hold because they would all hear music being played.  The is off by default (and can be disabled by an Administrator client policy), but if you have this enabled, do not put the call on hold.  The ‘play music on hold’ setting is in the Skype for Business ‘Ringtones and Sounds’ setting in the client as shown here:


Another useful feature in this scenario is the Devices button (next to the Hold).  You can use this to transfer the audio to another device (like a headset instead of an external speaker).

Skype for Business Online Coexistence with Exchange On-Premises

As Skype for Business Online gains adoption, there are more questions regarding feature support with Exchange On-Premises and pure Skype for Business Online (not hybrid). Specifically, what integrated features are supported and what limitations exist? This article provides a summary of what to expect in this scenario.

For starters, Exchange Server 2016/2013/2010 on-premises and a pure Skype for Business Online is supported with the right configuration. This Microsoft Support article is not well advertised but is a good reference on how to support this scenario: How to integrate Exchange Server 2013 with Lync Server 2013, Skype for Business Online, or a Lync Server 2013 hybrid deployment.

More details on co-existence with Exchange Server, support criteria, and limitations in various combinations of on-premises and online are detailed in this TechNet article: Plan to integrate Skype for Business and Exchange. Note, this article highlights a best practice, which is to “move the user’s mailbox to Exchange Online before moving the user’s Skype for Business home“. In practice, I have not found anything detrimental to moving the Skype for Business user first; aside from the feature limitations discussed here.

The most challenging issue I’ve seen so far is multiple sign-in prompts in the SfB client, especially when MFA is enabled. This can happen with SfB on-premises and Exchange as well however, and I have not been able to pinpoint anything specific with the SfB user residing online.

Generally, from a feature standpoint, the full set of integrated features are supported with the exception of:

  • Outlook Web App integration – Instant Messaging and Presence
  • Outlook Web App integration – Scheduling Meetings
  • Unified Contact Store
  • High Resolution Photo’s (in the SfB/Lync client)

Feature support does differ slightly between Exchange 2016/2013 and 2010. Here I’ve summarized the feature support for just Exchange 2016/2013 vs 2010 on-premises and SfBO scenarios, and highlighted unsupported features in red:

Skype for Business Feature Exchange 2016/2013 Exchange 2010
Presence in Outlook Y Y
Respond via IM, PSTN Call, Skype Call or Video Call from an Outlook email Y Y
Schedule and join online meetings through Outlook Y Y
Presence in Outlook Web App N N
Respond via IM, PSTN Call, Skype Call or Video Call from an OWA email N N
Schedule and join online meetings through Outlook Web App N N
IM/Presence in Mobile Clients Y Y
Join online meetings in Mobile clients Y Y
Publish status based on Outlook calendar free/busy information Y Y
Contact List (via Unified Contact Store) N N
High-resolution Contact Photo (Requires Lync 2013 or Skype for Business clients at a minimum. Not supported for LWA, mobile apps, Lync 2010, Lync for Mac, and other older clients.) Y N
Meeting delegation Y Y
Missed Conversations history and Call Logs are written to user’s exchange mailbox Y Y
Archiving Content (IM and Meeting) in Exchange N N
Search archived content N N
Exchange UM Voice Mail Y Y
Server Side Conversation History Y N

The Skinny on Skype for Business and Teams

As expected, at Ignite, Microsoft announced their plans around Skype for Business (SfB) and Teams at this session:

Here is what you need to know:

  1. Skype for Business Server will continue and evolve stand-alone product.
    • Brand new refresh of main stream support expected in Q4 of 2018
    • Will also refresh the SfB client during this time
    • Microsoft will continue invest in voice features
    • Will include Team integration in hybrid
  2. Skype for Business Online (SfBO) Features will be available in Teams, and over time the Teams Client will become the client for Users to Consume all Communication and Collaboration Features
    • Features include IM, Presence, Calling, Conferencing, Meetings, Contact & Conversation History, VoiceMail …. all Communication Features!
    • Net new voice investments (client and cloud) will be in Teams
    • Many of the voice and calling features have been built with a new cloud architecture that is expected to provide better quality
    • A screen shot of the new client with the communication features is shown below
  3. Skype for Business Online will still be available as a Separate offering (at least in the short term)
    • There will be a transition period with IT and End-User to transition SfBO users to Teams
    • These controls govern which client is used to consume voice and calling features
  4. Existing SfBO Voice Investments and Configuration will not Change
    • Current Conferencing Bridge numbers in SfBO will not change
    • Current Phone numbers will not change as users transition to teams
  5. Existing SfB and SfBO Phone Devices will Continue to work in Teams
    • Expanding cloud voice and video interop
  6. Skype for Business Room Systems will be Supported
  7. The Skype for Business and and Team Clients can run Side-by-Side, and Users can choose where they consume the communication feautres
    • For example, Can keep chat and calling in Skype if desired

You can see the official blog post here:


Skype for Business Online PowerShell Throttling Limits

As many ITPro’s have found out through remote PowerShell scripting against Exchange Online, there are limits. 

The same holds true for Skype for Business Online when using the Skype for Business Online Windows PowerShell Module. These are often an issue when scripting across thousands of objects.  For example, applying a SfBO policy to 15,000 user objects.

The throttling limits are very similar to that in Exchange Online. From experience, here are the hard limits:

  1. 3 concurrent sessions per credential used to connect
  2. 10 concurrent sessions per tenant
  3. Throttle Limits for Resources and Types of Resources
    • A resource is an object, or a type of object such as a Policy, a User, etc….
    • If your PowerShell script is repeatedly taking an action on a specific resource (read/write), or the same type of resource, you will be throttled
    • First, you will get a Warning Message like this one:  “WARNING: Micro delay applied. Actual delayed: 21956 msecs, Enforced: True, Capped delay: 21956 msecs, Required: False, Additional info: ….”
    • Secondly, if your script does not slow down, it will get slower responses to cmdlet’s, etc…
    • Thirdly, if you are really bad, you will be denied access in the form or just no response, or a hard denial depending on the resource and cmdlet.
    • Note: the throttle per resource or resource type happens across all concurrent sessions under the same credential.  Each credential seems to have a resource budget that is consumed regardless of the session.

Special thanks to Gary Hu for his contributions on this blog article.

    Installing on the new Skype for Business Online PowerShell Module on Windows 10

    A new Skype for Business Online PowerShell Module was released on April 19, 2017.

    Recently I commissioned a new Windows 10 desktop client and downloaded and installed this new module. When I went to use it, I received an error while trying to acquire an authentication token (e.g. Get-CsAccessToken) because of a missing Microsoft.IdentityModel.Clients.ActiveDirectory assembly.

    I was somewhat surprised to see Windows 10 not officially listed as a “Supported Operating System” as shown below.

    However, after resolving the missing assembly error, I have been able to use it without any issues. This blog article describes how to resolve this issue.

    Installation of the Skype for Business Online (SfBO) module should go fine, but you will likely get this error when trying to use the SkypeOnlineConnector (e.g. via Import-Module):

    • SkypeOnlineConnector Get-CsAccessToken : Could not load file or assembly ‘Microsoft.IdentityModel.Clients.ActiveDirectory, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35′ or one of its dependencies. The system cannot find the file specified.

    Human translation: either Microsoft.IdentityModel.Clients.ActiveDirectory is missing, or one of its dependencies.

    The Microsoft.IdentityModel.Clients.ActiveDirectory assembly is the Azure Active Directory Authentication Library (ADAL). The SfBO module uses it to authenticate the credentials used in the script against Azure AD. It is installed with the SkypeOnlineConnector Module. The SfBO Connector ships with Version 2.19 of the Microsoft.IdentityModel.Clients.ActiveDirectory.dll as shown below, but the there are other dependencies in this library that need to be installed.

    The ADAL library can be downloaded here:

    The client-side SfBO module running on Windows 10 will use the .NET Client version (either V2 or V3 will work; I would use V3 since it’s the latest).

    For some reason the built-in Install-Package cmdlet of the Microsoft PowerShell Package Management cannot find the ADAL library as shown here:

    There is probably an easy fix to that, but instead I just downloaded and used the NuGet Command Line Interface (CLI). It is built into Visual Studio 2017, or you can download it here: Download the “nuget.exe” and call it from the command line as shown here:

    You now need to exit and restart your PowerShell console or ISE session for it to take effect.

    Enabling PSTN Calling for an Office 365 E3 User in 5 Easy Steps

    I frequently encounter the situation where a company (or individual) has an Office 365 tenant with all E3 licenses but they want to enable some users for Skype for Business Online PSTN Calling (the ability to dial-out and receive calls to phone numbers in a geo-region where Skype for Business Online (SfBO) PSTN calling is currently available).

    This article discusses the most basic direct way to accomplish this so that people can understand the basic process and requirements.

    One of the first questions people have is whether they can  purchase a handful of E5 licenses in an “E3 tenant” (an O365 tenant that currently has nothing but E3 licensed users).  The answer is ‘Yes’ – you can purchase one or more E5 licenses and apply those licenses to one or more existing E3 users (upgrade their licenses). The PSTN Calling functionality can also be enabled by purchasing add-on licenses to the E3 license, but in most cases it is just as cost effective (or more cost effective) to use the full E5 license – this is situation I describe here.

    Here are the steps to fully enable PSTN Dial-In / Dial-Out for an existing Office 365 E3 user.

    1.  Purchase and Assign the Necessary Licenses

    For an existing E3 licensed user, there are basically have two licensing options to enable PSTN Calling:

    1. Purchase and assign an E5 license.  Then purchase and assign a PSTN calling add-on license for the user.
    2. Purchase and assign a Cloud PBX add-on license. Then purchase and assign a PSTN calling add-on license for the user.

    As you can see, the significant difference between these two options is that the E5 license includes the Cloud PBX license which provides the ability to then purchase a PSTN calling plan so that the user can make and receive phone calls in regions that have PSTN Calling enabled (in May 2017 this includes the US, France, UK, Spain, and Puerto Rico). The E3 license does not contain the Cloud PBX add-on license, and you must separately purchase it.

    Tip – think of the Cloud PBX license as providing PBX-like call control capabilities, but not the PSTN calling plan (or connectivity) on-top. The PSTN Calling Plans and Cloud PBX licenses go together – the Cloud BPX license is required to have the ability to add a voice calling plan.

    The cost of an E3 license with the Cloud PBX add-on in USD as of May 2017 is:

    • Office 365 E3: $20 / user / month
    • Skype for Business Cloud PBX :  $8.00 / user / month
    • TOTAL:  $28 / user / month

    The cost of an E5 license as of May 2017 is $35 / user / month (USD) which also includes PSTN Conferencing capabilities, MyAnalytics, Advanced Treat Protection, Advanced Information Protection (DLP and encryption), and more features, so it is worth considering for the extra $7 / user / month.

    FYI, as of May 2017, the Skype for Business PSTN Domestic Calling add-on license in the US is $12.00 / user / month.

    Once you have purchased an E5 license (or the equivalent add-on Cloud PBX and PSTN Calling licenses for E3), go into the Office 365 Admin Portal and assign the E5 license to a user.  This is straightforward process (see here if you have any questions: Assign or remove licenses for Office 365 for business).

    Tip – you need to turn off the existing E3 or E1 license before assigning the E5 license or the Office 365 Admin Portal will give you an error about “conflicting plans” – e.g.  Skype for Business Online Plan 1 conflicting with Skype for Business Online Plan 2.

    After assigning the E5 license, it is normal to see this warning:


    In fact, before we can assign the user a phone number, you need to ensure the user has a PSTN Calling Add-On License as described in Step #3.

    Tip – in my experience there is always a delay, and it’s not just a fSkype for Business PSTN Domestic Calling ew minutes.  I’ve typically had to wait many hours. In fact, as stated in the Microsoft Support Article  Assign Skype for Business licenses :

    Latency after assigning licenses: Because of the latency between Office 365 and Skype for Business Online, it can possibly take up to 24 hours for a user to be enabled for PSTN Calling after you assign a license. If after 24 hours, the user isn’t enabled for PSTN Calling please call us.

    2. Acquire and Assign a Skype for Business Online PSTN Calling Add-On License

    The ability for a user to make and receive calls through the phone system is an add-on license on top of the E5 license.  You can purchase this option through the “Billing | Purchase Services” options in the O365 Admin Portal.  There are a couple of options for PSTN Calling based on your region as shown below for the United States:


    For all the various PSTN Calling add-on license plans see PSTN Calling plans for Skype for Business.

    Tip – If you haven’t assigned a CloudPBX or PSTN Calling add-on License to a user, you will see this in the Voice tab of the SfBO Admin Portal


    Once you have obtained a PSTN Calling Add-On License (or CloudPBX license), you should see it in the available licenses in the Office 365 Admin Portal when  you edit a user (under Active Users) to apply it as shown here:


    Once the add-on license is successfully applied to a user and the change replicates to SfBO, you will see the user enabled for Voice in the SfBO Admin Portal as shown here:


    Tip – many times I need to re-launch the SfBO Admin portal from the O365 Admin portal to see this change.  You might get the same result by refreshing the browser.

    Now that a user is licensed for E5 and PSTN calling, you just need to configure an emergency location, and acquire and assign the user a phone number.

    Step 3.  Configure an Emergency Location for the User

    A this point, if you try to assign the a phone number to the user, you will quickly find out that you need to add an Emergency Location for the user before you can assign a number as shown here with this warning:


    This location represents a real physical address where the user consuming PSTN will likely reside and is used in the case the user dials an emergency number (e.g. “911” in North America).

    Configuring Emergency Locations is a straightforward process you can configure under in the “emergency locations” in the SfBO voice settings.  A real example is shown here:


    Tip – this needs to be a real physical address and it is validated against a database of real addresses before you can save and continue.

    Step 4.  Acquire a Phone Number

    Before you can assign a phone number to a user, you need to acquire one. You can do that in the SfBO Admin Portal under “voice” and “phone numbers” and select the “+” sign the Add a New Number. You will be able to select a new DID from the regions where PSTN calling is supported for the location of your Office 365 tenant as shown here:


    You should see the newly acquired DID in the available phone number list.

    Step 5.  Assign a Phone Number

    After successfully configuring an Emergency Location for the user, and acquiring a phone number, we can now assign a phone number to a user.  Go into “Voice | Voice Users” in the SfBO portal as shown here:


    And finally, after selecting the previously acquired phone number and emergency location, you can enable this user for PSTN Calling!


    Tip – all of the above steps showed how to do this in the Office 365 and SfBO Admin Portal but it can all be accomplished through PowerShell (e.g. for configuring many users).

    More Information

    The following Microsoft articles provide more information on PSTN Calling: