One of the most common questions asked when working among the array of available Skype for Business (SfB) audio and video endpoints is regarding what type of Lync or Skype for Business account can or should be used?  The short answer here is that there typically is not only one right answer.  Most of the phones and conferencing devices can work with either available types and generally do not have a single recommended approach due to potential behavioral differences.  This article will go into detail on what those differences are as a way to help the reader understand which approach may be ideal, if not a mixture of both in the same environment.

While the detailed instructions shown later in the article focus on configuring meeting room accounts for Skype for Business Online be aware that most of the concepts explained throughout are also applicable to on-premises Lync and Skype for Business deployments.  The only major difference is how the accounts are initially provisioned as the administrative process differs slightly between on-premises and online environments.  Once configured though the behavior of these accounts are the same whether they are homed on-premises or online.

The steps for configuring these types of accounts for on-premises environments have been covered by multiple sources as well as on this blog so they do not need to be revisited in this article.  Also another earlier article covered setting up remote PowerShell for Lync Online but those steps have been updated for Skype for Business Online as well as expanded upon for additional functionality in this article.

(For repeat visits there is quick reference on creating and configuring Skype for Business Online Meeting Room accounts using PowerShell in the last section of this article.)

Background

The two methodologies mentioned above are simply referring to the use of standard user accounts or special meeting room accounts.  Much of the foundation of these two account types are identical; they are just handled and treated differently within the various products that leverage them.

• Active Directory – At the primary directory services level there is no difference between the two accounts models.  They both utilize a standard Active Directory (AD) User Account object, meaning any and all of the attributes available to these object types are available to both.  Whether this is a traditional on-premises deployment in Windows Server Active Directory, Azure Active Directory in Office 365, or a Hybrid of both leveraging some directory synchronization services then a standard user account object is always the core component.
• Exchange Server – Within Exchange Server there exists different mailbox types which for regular users and bookable resource accounts, the latter being meant for things like conference room equipment which can be fixed or mobile.  Exchange treats a User Mailbox differently from a Resource Mailbox in terms of how mail is stored in those mailboxes and even what portions of the messages are retained or stripped.  Mailboxes of either type will allow devices the same level of access to their calendar of scheduled meetings.  A key distinction though is that while resource mailboxes still use the same type of standard user account in AD by default the account cannot actually be used for authentication as no password is defined and the account is disabled.  This is because in the traditional workflow of booking meeting rooms in Outlook which leverage Auto Accept agents no one would typically need to login as the mailbox itself.  This has changed with the addition of the Communications Server platform to this workflow though.  When configuring room mailboxes as part of a Lync or Skype for Business workflow these meeting room mailboxes are enabled specifically to allow authentication using the account’s own credentials.
• Skype for Business – An AD account is created which allows for user authentication.  That account is then mailbox-enabled within Exchange primarily to provide it an email address and calendar to accept and store meeting invitations.  The final piece in the puzzle now is to SIP-enable the same account to provide all the desired capabilities of adding Lync or Skype for Business to the workflow.  Just like in Exchange there are also two different types of Skype for Business accounts.  A standard User which can be enabled using either the Control Panel or the Management Shell, or a newer Meeting Room which was first introduced in Lync Server 2013 with the advent of the original Lync Room System product.  The meeting room account can only be enabled and managed from the Management Shell and is treated differently by Lync/SfB.  Either approach can be used by devices to sign-in and interact with the SfB services and use the previous calendar access to perform actions like joining the scheduled Skype for Business meetings.

Differences & Guidance

As mentioned above Active Directory itself does not really know, nor care if the core user account object has been used by Exchange to provide either a user or resource mailbox, nor if SfB has enabled a standard SIP user or a meeting room. (Technically it can be aware of the Exchange Server and SfB Server configuration because much of that configuration is stored among various AD attributes defined on the AD account, but that point it moot as AD does not ‘act’ upon that information in anyway that makes a difference as to which approach to chose.)

Because Active Directory does not have different account types for this scenario and the AD account is automatically created during either the Exchange or SfB provisioning step then there is no decision to make here, hence no guidance. Basically, this is irrelevant.

Exchange Server will treat user and resource mailboxes differently.  There are various additional customizations available to control the behavior of a room mailbox by using the Set-CalendarProcessing cmdlet in on-premises and online Exchange environments.  There a several parameters available to adjust the default behavior of actions related to acceptance responses, handling time conflicts, meeting duration, or even the allowed reoccurrence scheduling window to name a few.

Another critical difference between user and resource mailboxes is related to licensing.  Whether dealing with traditional Microsoft licenses or modern Office 365 licenses a standard mailbox user will consume one of these licenses, but a room mailbox will not.  This is easy to see in Office 365 as license-consuming Users are sorted and managed separately from Resources like Rooms and Equipment which are not assigned any licenses.

When it comes down to the vast level of customization offered with a resource mailbox paired with no user-level licenses required then there is virtually no reason to opt to use a regular user mailbox over a resource mailbox.  In short, always use a room mailbox.

Up to this point nothing new has really been covered as that is the way it has been for years across various releases of the Windows Server and Exchange Server products.  As pointed out earlier it was not until Lync Room System created the need for new functionality in Lync Server 2013 that there was really any decision to be made here.

Using a Room Mailbox by itself for just calendaring in Office 365 does not require any licenses be assigned, but when that same room mailbox is also configured .as a Skype for Business Meeting Room then a license must be assigned.  So there is no advantage to using a regular user versus a meeting room as both require SIP registration and authentication to function on a device.  This need for a license also overrides the fact that the Exchange account does not need one as these are one in the same.  For example the configuration shown in the second half of this article for creating a Room Account in Office 365 could be assigned an E1, E3, or E5 license, depending on the device type it was being used for.

There are two important distinctions regarding Meeting Rooms in Skype for Business which relate to the user experience.

Audio Behavior

Meeting Room accounts trigger special behavior when other participants are joining Lync and Skype for Business meetings.  When any device or client registered with a Meeting Room account is already connected to a SfB meeting (ad-hoc or scheduled) then the server is aware of this and triggers a prompt to appear on any other Lync or Skype for Business clients registered as normal user accounts which then join the same conference.

Basically when a Skype for Business or Lync client joins a meeting if there is already at least one participant using a meeting room account in that meeting then the client prompts them to answer the question “Are you in the Skype Room?” before connecting to the meeting.

If the new participant is connecting from their desk or home office they simply answer ‘No’ and are connected to the meeting using the selected default behavior for each modality.  If they happen to actually be in the same physical room as the already connected conferencing system then they would select ‘Yes’ and their client will connect automatically on mute.  This helps to prevent any audio feedback loops which can occur with multiple systems in the same vicinity connected to the same conference.

This scenario can be common when in-room participants want to join the same meeting from their own device to share or control content in ways that may not be available directly via the in-room system controls.  Obviously if using a regular SfB user account on these conference room systems would then prevent the above prompt from appearing and force users to learn to immediately mute their clients as they join meetings in the same room with their own clients.

Lobby Behavior

Meeting Room accounts are treated differently than other user accounts when joining a meeting in another important way.

A scheduled Skype for Business meeting that uses the default lobby option of “Anyone (no restrictions)” will allow all participants to immediately connect to the meeting and bypass the lobby.  Thus devices using either a user or meeting room account will behave the same and connect directly to the meeting like any standard participant.

Where things get interesting though is when the individual meeting options have been customized to control specifically which participants are forced into the lobby.  A scheduled Skype for Business meeting that is configured to allow either “Anyone from my organization” or “People I invite from my company” to bypass the lobby will behave differently between user and meeting room accounts.

The following table shows which account types will bypass the lobby and which will be forced into the lobby across the 4 different lobby settings.

Lobby Configuration	User Account	Meeting Room Account
Only me, the meeting organizer	Forced into Lobby	Forced into Lobby
People I invite from my company	Allowed Directly into Meeting	Forced into Lobby
Anyone from my organization	Allowed Directly into Meeting	Forced into Lobby
Anyone (no restrictions)	Allowed Directly into Meeting	Allowed Directly into Meeting

Clients or devices registered with a meeting room account are forced into the lobby when invited directly to the meeting in the two middle options above, even though it is registered as a corporate account from the same organization .  This is because a Skype for Business Meeting Room account is not treated as someone from the organization or someone that was invited directly.  This behavior is by design as one can imagine that anyone could walk into a conference room or up to a common area device and join a meeting on the calendar; employee or guest.  This behavior allows actual authenticated users who are granted presenter rights to ability to curate the lobby list and only allow (or allow and then promptly remove) possibly unknown participants joining from shared endpoints.

Obviously if this behavior is not desirable for specific devices then choosing to use a regular SfB user configuration instead of a meeting room configuration for that device will address this by always allowing the room to bypass the lobby (unless the meeting was configured for only the meeting organizer to be allowed).  But as covered in the previous section registering a room system with a user account will omit the “Are you in the Skype Room?” prompt from appearing in those meetings.

Given the potential trade-off between audio and lobby behaviors described above there is no single right answer for selecting account types for all devices.  Generally it would be best to use the vendor-preferred approach which is typically a Meeting Room account for most devices. But the desired lobby behavior could be one of the most critical items in making this decision.

Solutions like Skype Room Systems and Group Series video conferencing systems are best suited using the meeting room approach, but work equally as well (when properly configured) with a regular SfB user.

Remember that in either scenario an Exchange room mailbox  is always recommended so the calendaring functionality is no different between them.  Also Audio conferencing phones can leverage Common Area Accounts which do not support Exchange and thus have no calendaring and do not really apply here.  Audio conferencing phones can also leverage Common Area Accounts which do not support Exchange and thus have no calendaring

Given that the overall guidance is to leverage Meeting Room accounts then the remainder of this article will cover exactly how to configure these in Skype for Business Online.

Office 365 PowerShell Setup

As mentioned earlier it is not possible to create Meeting Room accounts using the Skype for Business Online Admin Center so this configuration must be performed using PowerShell cmdlets.  In order to leverage PowerShell for Online services the following workstation configuration must be addressed first.

Software Installation

In order to use Windows PowerShell to connect to Office 365 and manage any of the various online services a few software packages must be installed.  The current Microsoft TechNet documentation covers how to do this but the required steps are also included here in this section.  These steps only need to be performed once per workstation and can be skipped if this prerequisite software is already installed.

Additional steps may be required depending on the Windows and PowerShell version so if there are any problems getting these packages installed and working make sure to reference the official TechNet guide above as well as this previous article which covers this as well as modifying the workstation’s Execution Policy if needed.

If the older Lync Online PowerShell module is installed then it is highly recommended (although not mandatory) to uninstall that package from the workstation and reinstall the newer Skype for Business module covered below.

• Download and install the 64-bit version (msoidcli_64.msi) of the Microsoft Online Services Sign-in Assistant.

• Download and install the Windows Azure Active Directory Module for Windows PowerShell.

• Download and install the Skype for Business Online Windows PowerShell Module

.

Now that the required software has been installed the next step is to create a simple PowerShell script to leverage all of these new components in a single command instance.

Management Script

The following basic script file can be used to initiate and authenticate multiple sessions into Office 365 for the purposes of leveraging any Azure Active Directory , Exchange Online, and Skype for Business Online PowerShell cmdlets.  Note that the Skype for Business Online module must be installed on the local workstation first but this is not the case for Exchange Online.  The Exchange session is created manually using the New-PSSession cmdlet and thus does not need any local installation files.

Follow the steps below to create a new script file.  Make sure to pay attention to spacing and dashes in the cmdlets as the formatting on various browsers and display resolutions can change where the longer commands are wrapped to a new line in this article.

• Using either a simple text editor like Notepad or a more advanced tool like Windows PowerShell ISE create a new script file and select any desired name (e.g. O365.ps1).
• Enter the following text into this file, replacing the highlighted example user account name with the desired administrator account for the appropriate Office 365 tenant (e.g admin@mycompany.onmicrosoft.com)

$credential = Get-Credential admin@domain.com

Import-Module MsOnline

Connect-MsolService -credential $credential

$exchSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $credential -Authentication Basic -AllowRedirection

Import-PSSession $exchSession -DisableNameChecking

Import-Module SkypeOnlineConnector

$sfboSession = New-CsOnlineSession -Credential $credential

Import-PSSession $sfboSession

These 8 individual command lines above perform the following functions:

1. Prompts the user to enter the password for the defined admin account and securely stores the set of credentials in a newly defined variable.
2. The previously installed Azure AD module is loaded into the current PowerShell session.
3. A secure connection is opened to Azure AD in the account’s online tenant.
4. A new Exchange Online session is defined and stored in another new variable.
5. The Exchange Online session is imported into the existing PowerShell session.
6. The previously installed Skype for Business module is loaded into the current PowerShell session.
7. A new Skype for Business Online session is defined and stored in a third new variable.
8. The Skype for Business Online session is imported into the existing PowerShell session.

If the workstation still has the older Lync Online module installed and it was decided not to replace it with the Skype for Business module then simply edit command 6 to reference the LyncOnlineConnector instead.

• Save the file on the local workstation.  Preferably save in a path that PowerShell can see by default (e.g. C:\Windows\) to make it easier to run the script from the command line.
• Open a new PowerShell session and then run the new script. 

• Enter the Office 365 tenant administrator account password when prompted.

Once the script completes then the new Exchange and Skype for Business sessions should be displayed as seen below.

To validate a successful connection to all three services run the following basic cmdlets to verify AD, Exchange, and Skype for Business.

Get-MsolUser –UserPrincipalName user@domain.com

Get-Mailbox user@domain.com

Get-CsOnlineUser –Identity user@domain.com

If all steps are successful then the workstation preparation is complete.

Online Meeting Room Configuration

Now that the one-time workstation configuration is complete then the remainder of the steps in this article can be repeatedly used to create individual meeting room accounts at any time.

Exchange Room Mailbox

Using either the same or a new PowerShell session as established in the previous section define a new variable to store the desired User Principal Name for the new meeting room account and then create the new room mailbox.

• Replace the text in blue below with the desired details for the new meeting room and then issue the following New-Mailbox cmdlet to create a new Room mailbox and enable the account to allow authentication.

$newUser="chicago@jdskype.net"

New-Mailbox –MicrosoftOnlineServicesID $newUser -Name "Chicago Meeting Room" -Room -RoomMailboxPassword (ConvertTo-SecureString –String "P@ssw0rd1" -AsPlainText -Force) -EnableRoomMailboxAccount $true

It may take several seconds for this cmdlet to return any results and may also even report a replication request failure.  This is normal as it can take up to 15 minutes before the mailbox provisioning is completed in Exchange Online.  There is no need to wait that long though to complete the rest of the Exchange Online configuration steps.

• Run the following Set-CalendarProcessing cmdlet to modify some of the default behaviors of a standard resource mailbox which are critical to providing the proper in-room join experience

Set-CalendarProcessing -Identity $newUser -AutomateProcessing AutoAccept -AddOrganizerToSubject $false -RemovePrivateProperty $false -DeleteComments $false -DeleteSubject $false –AddAdditionalResponse $true –AdditionalResponse "Your meeting is now scheduled and if it was enabled as a Skype Meeting will provide a seamless click-to-join experience from the conference room."

• This optional step simply uses the Set-Mailbox cmdlet to define a custom Mail Tip message for when Outlook 2013 and newer users attempt to send messages to this mailbox. 

Set-Mailbox -Identity $newUser -MailTip "This room is equipped to support Skype for Business Meetings"

Another optional step is to disable password expiration on this new account.  By default, as with any AD account, the password defined in a previous step will automatically expire based on the account’s inherited password policy.  When dealing with shared meeting devices it may not be desirable to be forced to administratively update the account’s password within that interval.

• To set the new account’s password to never expire simply run the following Set-MsolUser cmdlet and then optionally run the Get-MsolUser cmdlet to verify the change.

Set-MsolUser -UserPrincipalName $newUser -PasswordNeverExpires $true

Get-MsolUser -UserPrincipalName $newUser |fl userp*, passwordN*

Skype for Business Meeting Room

The final steps are used to create a Meeting Room account in Skype for Business Online.  Just as with on-premises deployments of Lync Server 2013 or Skype for Business Server 2015 this configuration is only available via PowerShell and is not provided in the web-based user management tools like the Control Panel or Office 365 Admin Portal.

Just as was performed above some additional variables will be defined to be used by the actionable cmdlet.  One difference here though is that in order to create a meeting room the online tenant’s registrar pool information must first be located. The first command is used to store the name of any existing Skype for Business Online user in the tenant as it will be used to query the proper registrar pool FQDN in the second command.  The third and final command goes about creating the new meeting room account.

It is important to run these commands after the previous Exchange commands in the same PowerShell session it uses the previously defined $newUser variable which would still be cached in the command shell session.

• Define another variable which will be used to query and store up the proper Skype for Business Online registrar pool name for the specific tenant which will be needed to create the meeting room account.  Enter the SIP URI of any existing Skype for Business Online user in the tenant below (e.g. jeff@jdskype.net) .

$pool=Get-CsOnlineUser -Identity "jeff@jdskype.net" | select -expand RegistrarPool

• Execute this final cmdlet to create the new meeting room account using the previously created Exchange room mailbox.

Enable-CsMeetingRoom -Identity $newUser -RegistrarPool $pool -SipAddressType EmailAddress

If the Enable-CsMeetingRoom cmdlet fails with the following error then replication of the previously created mailbox has not yet completed throughout the Office 365 environment.  It may be necessary to wait anywhere from a few minutes to hours depending on the health status of Office 365.  Typically it only takes a few minutes before this cmdlet is successful but in some scenarios this has taken up to 24 hours before it works.

Management object not found for identity chicago@jdskype.net.
+ CategoryInfo           : NotSpecified: (:) [Enable-CsMeetingRoom], ManagementException
+ FullyQualifiedErrorId  : Microsoft.Rtc.Management.AD.ManagementException,   Microsoft.Rtc.Management.AD.Cmdlets.EnableOcsMeetingRoomCmdlet
+ PSComputerName         : admin1a.online.lync.com

When the Enable-CsMeetingRoom cmdlet is reported as successful then wait a few additional minutes and then run the following cmdlet to return all available meeting room accounts to verify that the new account is listed.

Get-CsMeetingRoom | ft Disp*,SIP*

Office 365 License

The final step is to assign an Office 365 license to the meeting room account.  This action can be performed in either the Admin Center or via PowerShell.  Both approaches are included below but obviously the action only needs to be performed once for each meeting room account that is created.

To assign a license using the same PowerShell session perform the following steps.

• Enter the Get-MsolAccountSku cmdlet to return a list of the current tenant’s existing license types and units.  The example tenant used here as 25 enterprise licenses available with a unassigned licenses available.

Get-MsolAccountSku

• Before assigning a license the new account will need to be assigned to a regional usage location. Use the Set-MsolUser cmdlet with the appropriate two-letter country code (e.g. US) for the tenant.

Set-MsolUser -UserPrincipalName $newUSer -UsageLocation "US"

• Then use the Set-MsolUserLicense cmdlet with the appropriate TenantName:LicenseName value which was queried for earlier to assign a license to the new meeting room account.

Set-MsolUserLicense -UserPrincipalName $newUSer -AddLicenses "Schertz:ENTERPRISEPACK"

Alternatively to assign a license by using the Office 365 Admin Center perform the following actions instead.

• Login to the Office 365 Admin Center and then browse to Users > Active Users.
• Either locate the desired account or use the Filters drop-down menu to quickly list only Unlicensed users.

• Highlight the new meeting room account and then click Edit to the right of the Product licenses option.
• Select a Location and then enable the desired license (e.g. Office 365 Enterprise E1) and then Save the changes.

The configuration is now complete and the new Skype for Business Online Meeting Room account can be used with the intended device.

Quick Reference

As with many of these articles once the concepts are understood then repeat visits are typically those occasions when the only the process is important.  Thus once a workstation is configured and the script is saved then creating a new meeting room account is as simple as running a host of PowerShell commands, and then tidying things up by assigning a license.

The following block of text cleans up all of the detailed explanation and steps above into a straightforward process.  The commands can be run in three individual groupings to allow for replication process to complete between some of the steps.  Additionally a number of variables have been included to simply repeat usage of these commands.  Simply populate the fields in blue with the desired details and then copy/paste the remainder of the individual cmdlets as shown below.

• Change the text in blue to the desired information and then execute these commands, waiting for the mailbox creation to complete.

$newUser="meetingroom@jdskype.net"
$name="Meeting Room"
$pwd="P@ssw0rd1"
$location="US"
$license="Schertz:ENTERPRISEPACK"
$existingUser="jeff@jdskype.net"

New-Mailbox –MicrosoftOnlineServicesID $newUser -Name $name -Room -RoomMailboxPassword (ConvertTo-SecureString -String $pwd -AsPlainText -Force) -EnableRoomMailboxAccount $true

• Wait about 30 seconds after the mailbox has been successfully created before running the next group of cmdlets to customize the user account and mailbox settings.

Set-MsolUser -UserPrincipalName $newUser -PasswordNeverExpires $true

Set-MsolUser -UserPrincipalName $newUSer –UsageLocation $location

Set-MsolUserLicense -UserPrincipalName $newUSer –AddLicenses $license

Set-Mailbox -Identity $newUser -MailTip "This room is equipped to support Skype for Business Meetings"

Set-CalendarProcessing -Identity $newUser -AutomateProcessing AutoAccept -AddOrganizerToSubject $false -RemovePrivateProperty $false -DeleteComments $false -DeleteSubject $false –AddAdditionalResponse $true –AdditionalResponse "Your meeting is now scheduled and if it was enabled as a Skype Meeting will provide a seamless click-to-join experience from the conference room."

• Given the aforementioned replication delays it may be required to wait up to 15 minutes (typically observed 5-10 minutes) in a healthy tenant before successfully running the next commands.

$pool=Get-CsOnlineUser -Identity $existingUser | select -expand RegistrarPool

Enable-CsMeetingRoom -Identity $newUser -RegistrarPool $pool -SipAddressType EmailAddress

The screenshot below shows all of these commands successfully executed in secession, with suggested interval timing.