Video Conferencing in Skype for Business Online

September 26, 2016 by · 1 Comment 

Fresh on the heels of the recent Microsoft broadcast entitled Video Interop in the Cloud have come a number of questions from the overall community looking for further clarification on exactly what all this means.  The summaries below also include various details from today’s announcements from Microsoft and some of their device partners at the Ignite 2016 event in Atlanta.  Interoperability is a term which can been used in a few different ways throughout the industry, but the articles here attempt to separate the overall term between ‘native’ integration provided directly within a client or endpoint versus ‘interoperability’ which can be provided indirectly between systems by way of an intermediary component.

The concepts outlined here may look familiar as much of what was covered in this previous article has been applicable to on-premises Skype for Business Server (SfB) deployments for some time.  The main differences since then are that the overall solutions have become more streamlined and feature-rich in the few years that have passed while knowledge of the back-end infrastructure is deemed less important as more of these components are moving into cloud-provided models.

The intent of this article is to clearly explain a few of the concepts and delivery models surrounding a topic of continuously growing interest: bringing traditional video teleconferencing (VTC) solutions into Skype for Business meetings.  Note that in the past most of the interoperability requests were described more often as “bringing together standard conferencing and desktop conferencing systems.”  More recently that need is specifically about getting the traditional solutions to play along in the Microsoft UC workflow. 

The tide that seems to driving this is the ubiquitous usage and understanding of a very common workflow based on using Outlook to schedule a Skype for Business meeting.  This familiar behavior was the figurative linchpin in the literal redevelopment of interoperability solutions like Polycom RealConnect back in 2014, later followed by other products like Pexip Infinity or Acano Dual Homed Conferencing (now part of Cisco Meeting Server) which began to use similar architectures pioneered by Polycom.

Video Conferencing can generically refer to the simple act of turning on the embedded video camera on a laptop or mobile phone while participating in a Skype for Business meeting, or walking into a traditional corporate conferencing room and expecting to join the same meeting using some level of in-room equipment providing a higher-end video experience.  Practically it should refer to any and all scenarios in between these.  The goal is to get away from disparate workflow that ultimately may limit end-users by forcing them to select from one of several different ways to collaborate, none of which may address all of their needs individually and also not be able to operate in conjunction. Thanks to the pervasiveness of readily available tools like Skype this demand is common-place and almost expected of by many information workers today.

In the present stage getting to this single holistic solution is a reality, and in more ways than one.  The two available approaches can be leveraged independently or in conjunction, depending on the current state of an environment or the desired outcome.

The Interoperability route has several options and allows for the continued use of, or rekindled interest in, traditional standards-based video conferencing solutions available by a number of manufacturers.  The Native approach is best suited for greenfield deployments or environments looking to refresh aging equipment that may be beyond its useful life.  And of course a combination of both approaches can be used to leverage some of what may be in place today as well as start the journey towards replacing other solutions with compatible systems which can end up getting to a place where interoperability may no longer even be needed.

Native Compatibility

The simplest, yet often most expensive solution is typically to just go back to the drawing board.  Scrap whatever what may have been shortsightedly tossed together or improperly designed and then inherited.  Whether it is broken, perfectly functional, adequate but unpopular, out of warranty, disjointed, or in the event of equipping new office spaces there are many reasons to look at starting fresh to coincide with an established or emerging Skype for Business deployment.

End-users enabled in Office 365 will immediately have a range of conferencing options available to them across personal and corporate-owned devices.  With the wide array of Android, iOS, and Windows clients available on mobile phones, tablets, Surfaces, laptops, and desktop computers any of these can be used to create or join either scheduled or instant, ad-hoc meetings and provide the ability to share their own video as well as see one or more active video streams from other participants.

So how does one bring this comfortable experience into the traditional conference room space now?  On paper the easiest approach is to add or replace equipment in the room that uses the preferred solution and workflow.  Something that natively and securely registers to the Skype for Business platform, can access Exchange mailbox information to retrieve meeting invitations, and uses the same protocols and codecs to communicate with Skype for Business clients and servers.

There are basically three device categories which addresses this approach: Optimized, Compatible, and Unsupported.  Microsoft maintains a list of currently available partner solutions the Skype for Business Solutions Catalog.

Optimized Solutions

The most obvious category includes systems that run on software that Microsoft has created.  This includes solutions completely owned by Microsoft from development to sale, like the newer Surface Hub products.  This also includes co-developed products where Microsoft owns the software while one or more of their technology partners develop and build hardware devices to run this software.

The original Lync Room System (LRS) products fall into this category as while Microsoft developed and maintains the core Windows Embedded software manufacturers like Crestron and SMART have developed the overall hardware packages, basically building appliances to run the Microsoft-provided software.

The native Lync and Skype for Business capabilities offered by these systems are inherent due to the fact they typically run some flavor of an embedded Windows operating system along with the actual Lync or Skype for Business desktop clients installed.  The design and user interface can often obfuscate this fact but rest assured that the base Microsoft code is included in these software packages in some fashion.  The goal is to provide the core functionality offered by using the native Microsoft software but in a less-personalized package that is well-suited for use in common areas like conference rooms.

Other well-known examples of these types of solutions are the popular Lync Phone Edition desk phones originally built by various partners like Aastra (now owned by Mitel), LG-Nortel, Snom (built for and sold by HP) and Polycom.  It is worth pointing out that Microsoft has been moving away from the optimized model for IP phones for some time, relying on solutions in the next category to provide the next generation of IP telephony desk sets and conference phones.  Note that by now those compatible phones have eclipsed the original optimized phones in terms of telephony capabilities.

An important distinction covering products in this category is that because they are true Microsoft software clients then they only work with the Microsoft platforms.  A Lync Room System on its own cannot directly communicate with a standards-based H.323 or SIP platform, or the Lync Phone Edition device cannot register to a Cisco Call Manager environment.  These are purpose-built solutions which require access to Lync Server, Skype for Business Server, Exchange Server, etc.

Other offerings are the upcoming room systems designed under the Project Rigel program which were announced at Enterprise Connect earlier this year.  Microsoft just announced today at Microsoft Ignite 2016 that these products will officially be named Skype Room Systems, joining products like the previous Lync Room System (which is also referred to as Skype Room System) and Surface Hub products.  This new Skype Room System platform will be running Microsoft-developed software on a Surface Pro 4 bundled with a purpose-built dock offered by the existing program partners of Crestron, Logitech and Polycom.  The dock provides USB connectivity to certain qualified video and audio conferencing products already available today from these manufacturers, with more solutions to be brought into the fold later.  The user interface created by Microsoft will be identical across the various vendors with the actual camera and microphone devices being the main differentiation between the various systems.

Microsoft will cover more details on these new Skype Room System solutions in their upcoming Ignite session Dive into Project Rigel and the Skype for Business Meeting Device Portfolio.  Pre-production models of these will also be on display in the Ignite partner expo this week, like the Polycom MSR series.

Compatible Solutions

‘Compatible’ is the term that Microsoft reserves for third-party products which undergo an official qualification process, hence these also being loosely referred to as ‘qualified’ or ‘certified’ solutions as well.  In practice all of these terms are often used interchangeably but the critical identifier in this category is that these are solutions developed entirely by the partner, hardware and software, and are officially supported by both the manufacturer and Microsoft upon successful completion of a defined qualification process.  This program can also sometimes be seen referred to as 3PIP, or Third Party Interoperability Program.

This can be a difficult category to understand based on the various terminology that in reality is not even used consistently throughout Microsoft’s own documentation.  Even browsing between different categories in the device catalog like Meeting Peripherals versus Meeting Room Systems will display ‘Certified’ on one, yet ‘Compatible’ on the other.  Improved clarity across these various programs and catalogs would no doubt be welcomed by all.

An example of a product in this category is the RealPresence Trio 8800 conference phone, which is designed and built entirely by Polycom.  While the actual Microsoft Lync or Skype for Business client software is not included in these devices they do support an array of Microsoft protocols and codecs, providing the features and capabilities needed to pass the qualification requirements.  This simply means that the manufacturers include native support for things like server auto-discovery, secure SIP registration, presence advertisement, voice calling features, video codecs like X-H264UC, and more.

Whereas the optimized solutions will only work with Microsoft UC platforms many of the devices in this category are not limited in that way.  These products often support many different call control platforms, although not always concurrently.  So the same device could register to Skype for Business or could register to a Cisco VCS or Call Manager platform, or possibly even both at the same time.  The supported alternative platforms and capabilities will vary based on the products used but this flexibility can open the door for using a combination of approaches covered in this article.

Take the Polycom Group Series endpoints for example.  This solution’s unique design allows it to communicate with concurrent disparate platforms by leveraging the SIP configuration to register to a Lync/SfB server while also using the H.323 configuration to participate in calls with other systems outside of the Microsoft UC platforms.  The previous generation HDX products also supported this same dual registration model with Lync Server.

Furthermore there are modular solutions available today, like the Trio 8800, which are qualified in a specific configuration but not currently in others.  To clarify the Trio is qualified for SfB as stand-alone audio conference phone but not when paired with a Visual+ module to provide connections to a display and camera.  Then audio scenarios are still covered within the qualified realm but video conferencing and content sharing features fall into the remaining “supported but not certified” category.

Unqualified Solutions

The category is more of a catch-all then a specifically defined set of products. Basically anything not qualified or supported by Microsoft falls in here.  This could include a product that the manufacturer performs extensive internal testing and officially supports it themselves with Lync or Skype for Business environments, yet Microsoft does not directly support or may even acknowledge the existence of.  This could include products that barely function with Skype for Business and are not even supported by their own vendor.  Generally these types are not recommended as the interoperability can come as a result of reverse-engineering processes as opposed to working directly through the Microsoft partner programs.

Interoperability

A number of different scenarios were covered in the previous article focused primarily with on-premises conferencing deployments but at this stage the clear favorite among users and administrators alike has been the cascading topology that allows the SfB platform to drive nearly every part of the meeting lifecycle yet still allow for typically incompatible room systems to join in.  A meeting is scheduled, managed, and hosted using routine SfB tasks and all SfB clients are still connecting to their native environment for this experience.

This cascading experience was first developed by Polycom for use with Lync Server 2013 deployments and has since been adopted to the Skype for Business Server platform, with other vendors following suit and largely moving away from the legacy model of dialing directly into a Virtual Meeting Room (VMR) where the Microsoft UC clients would place calls directly into the standards-based bridges and not their own Lync/SfB meeting bridge.

Office 365 Offering

The Polycom RealConnect solution has been becoming more cloud-focused and this culminates with the addition of cloud video interoperability services directly in Office 365.  The Skype for Business product team’s recent broadcast meeting on this topic provided further details as to what this service is intended to be.  Basically this offering will be the Polycom RealConnect solution running inside of Office 365 and tied directly to the Skype for Business Online environment.  Gone will be any requirements to host on-premises components to leverage this basic capability.  Existing SfB Online users will continue to schedule meetings as they have done and the plethora of available standards-based conferencing systems can also join these same meetings.  While the term “standards-based” can sometimes be a gray area the functionality is available for nearly every type of common video conferencing solution from manufacturers like Cisco/Tandberg, Polycom, and LifeSize.

For those keeping a keen eye on the space this solution was also announced during Microsoft’s Enterprise Connect keynote this year.  It has since been referred to by various unofficial names including “Project Aqua”.  Another announcement from today is the official name for this offering as “Polycom RealConnect Service for Office 365.”  The public Skype for Business Preview program for this service will be made available later this year for select existing Office 365 tenants based in the U.S.  Next year will see the service rolled out to globally in a similar manner as other Office 365 features have been in the past.

But what about the native Video Interoperability Service (VIS) that was provided in Skype for Business Server 2015?  Why has Microsoft not simply leveraged software that is already in the sever platform today?  While the VIS role is still available for on-premises server deployments it has not received any further development since the original RTM version of the server platform. VIS does not currently provide near the features or level of security that purpose-built third party solutions can offer today when integrating with SfB.  By leveraging an existing complete solution rooted in the standards-based world that interoperability is desired with then a huge leap forward can be taken, yet still protecting the SfB user experience.

Third-Party Alternatives

Because this embedded Office 365 service is not yet available to the general public then what about addressing immediate needs?  The popular SfB interoperability solutions offer some level of capabilities today but the main limitation is these have not yet supported the preferred cascading topology with Office 365 users.  Regardless of where the third-party software is deployed (on-premises or in a cloud service) they have not been able to allow SfB Online users to schedule normal meeting that any room system can join.  Only the legacy VMR approach has worked with SfB user accounts which are homed in Office 365, meaning that those users must place a peer SIP call to something like “12345@video.domain.com” which terminates on the third-party Multiparty Control Unit (MCU).

The desired MCU cascading methodology has so far been limited mostly to on-premises Lync and Skype for Business server deployments, but Polycom RealConnect has also introduced support for Hybrid or Federated SfB scenarios.  By utilizing SIP connectivity provided by on-premises Skype for Business servers (which no longer actually host any user accounts) the cascading meeting interoperability workflow can be provided to Skype for Business Online user accounts.

Understand that the upcoming Office 365 service discussed above is not simply taking a third-party infrastructure and hosting it into Microsoft Azure.  So while solutions like Pexip Infinity currently support installation of the core components into Azure that does not provide the ability to cascade the standards-based MCU with the SfB MCU.  The clear benefit of the upcoming native cloud interoperability service is allowing the ‘better together’ workflow which keeps the call control and majority of the moving pieces within the SfB platform by allowing for the cascading model to be used.

Also, just as with best practices common with device selection, make sure to reference the Skype for Business Catalog to consider officially supported infrastructure solutions available from active Microsoft partners.

Basically the landscape is set to leverage several years worth of the RealConnect cascading workflow and experience for environments moving from on-premises SfB footprints, to hybrid, and eventually into Office 365 primarily.

Some of Both

The obvious question to come from all of this information is which approach to use: Native, Interoperability, or both?  This can best be answered by understanding the current strengths or any existing limitations in each and weighing them against what is needed in the environment.  Each can offer different experiences based on whether granularity of features or a focus on simplicity is more important.

When a video conferencing system is acting solely as a standards-based system, either by limitation (when it cannot register to SfB) or by choice (when available SfB registration capabilities are intently not enabled) then the interoperability model alone is used.  Traditional VTCs fall into two types: those which support calendaring and those which do not.  Many of the present-day VTCs from Polycom and Cisco support connecting to Exchange Server mailboxes to retrieve and display scheduling meeting information created by Outlook.  When these invitations also include Skype for Business meeting details then these systems can provide a simple click-to-join experience whether driven by a remote control, touch panel, or even touchscreen displays.

The older systems which do not support calendaring are limited to continuing the legacy experience of dialing number strings to join any meetings. Yet this action can now end up in a Skype for Business Meeting instead of being locked into meetings that only the other similar VTCs can participate in.

Another important use-case when considering between the two options is whether meetings will need to allow external parties like partners or customer the ability to join from their own standards-based video systems.  When looking at the native approach by deploying and/or upgrading all corporate conference rooms having an additional interoperability may seem unnecessary.  But what about outside participants in room systems that are not equipped to handle native SfB communications?  Leveraging an interoperability solution allows for this when desired by incorporating a perimeter network solution akin to the Edge Server that handles the communications protocols used by traditional VTCs.

Overall a fair amount of concepts and direction is included here yet without getting into the weeds on different products and their capabilities.  It is important to spend some time investigating specific offerings to understand that there is not always a one-size-fits-all solution.  The nuisances of each approach can either be ideal or cumbersome, depending on the desired outcome and overall flexibility to move away from workflows that are not working today and eagerness to adopt new and improved ways of doing old things.

Consider this post as an open forum to ask any questions via the comments section on this specific topic or if clarification is required on individual capabilities of any of the solutions or platforms covered above.

Fall 2016 SkypeUG Meetings

August 26, 2016 by · 1 Comment 

The next round of quarterly Skype for Business Users Group meetings has been announced and scheduled starting this month.

newlogo_title

Event Details

This quarter’s event will be conducted in our familiar two-session format:

The first session will take a look at the upcoming Skype for Business Mac client as well as review the various Skype for Business Preview Programs available today.

The second session will be a sneak peak at the Microsoft Ignite 2016 event, highlighting the solutions and products available by our group’s many sponsors.

Industry Experts will be on-site to deliver these presentations and help answer any questions related to Skype for Business.  Food, beverages and additional door prizes will be provided courtesy of the Skype for Business Users Group and its official sponsors.

Western U.S.

Central U.S.

Southern U.S.

Eastern U.S.

 

For a full schedule of regional events the Skype for Business Users Group Meetups page lists all planned event locations with links to the associated registration page for each regional group.  For anyone who is not yet a member and would like to participate simply visit the site listed above and register for your local group, this will automatically create a new user account for you to use again for all future event registrations..


Chicago Event

As usual I will be hosting the Chicago event downtown.  Food will be ready at 5:30 so come early if you can to spend time socializing with the group before the presentations begin at 6:00.

Date Location Address
Tuesday, Sept 13th
5:30PM – Food and Networking 
6:00 PM – Presentation Kickoff
Chicago Users Group Microsoft Technology Center 
200 East Randolph Drive, Suite 200 
Chicago, IL 60601

Device Updates with Skype for Business Online

July 8, 2016 by · 1 Comment 

As outlined in this previous article a wide array of Polycom phones are now supported directly with Skype for Business Online in Office 365.  In the past dealing with device updates has been covered in several articles for the different device families and models.  These same concepts still generally apply when using the devices with Skype for Business Online but the configuration and management is slightly different.

While separate provisioning servers can still be utilized with the various 3PIP devices, the guidance across all of the previous articles is focused on traditional on-premises deployments of Lync and Skype for Business server platforms.  But what about the growing number of environments where none of those components exist and literally everything outside of the clients and end-user devices are simply leveraging the Office 365 cloud platform?

This article addresses these online-only tenants with guidance on how to manage IP phone firmware without using any additional management solutions.  Keep in mind that in the future some of these management tasks may become even easier as with Microsoft’s recent acquisition of some portions of Event Zero’s UC Commander platform as that could materialize into more direct control of Polycom UCS configuration parameters inside of the Office 365 administration portals.

Background

With the introduction of official support for Qualified IP Phones in the online platform there arose a need to offer some sort of firmware management capability that resembles what the existing Lync and Skype for Business server installations already offered.  This is handled by the native Device Update service which is already part of Skype for Business Server.  The main difference though is that while the on-premises server platform the configuration is performed through a combination of Control Panel setting and Management Shell cmdlets, Office 365 administrators only have access to settings exposed in the online Administration Portal.  There is a limited subset of cmdlets defined for online tenants which do not match the vast array of on-premises server cmdlets.

Office 365 administrators today are given control of only a few IP Phone-specific options which includes the ability to disable the default in-band firmware updates behavior.  Microsoft controls what firmware version this will be so an administrator can only control whether or not they want the officially approved and supported firmware automatically deployed to their VVX phones, which is enabled by default.  It is not possible to select or upload a desired version using the device update service in Office 365 like an on-premises deployment offers.  To utilize any version other than the currently approved release the automatic update behavior must manually be disabled.

Default Behavior

At the time this article was written only the Polycom VVX IP phones will automatically receive device updates when registered with a Skype for Business Online user account.  The Trio 8800 conference phone, which is part of the same core Unified Communications Software (UCS) family, does not yet receive updates from the Skype for Business Online device update server.  Lync Phone Edition devices also do not receive firmware updates when registered directly to Skype for Business Online.

As outlined in Adam Jacob’s article earlier this year a pair of new cmdlets were added to the Skype for Business Online PowerShell Module for controlling some behavior of the IP Phones.  These new Get-CsIPPhonePolicy and Set-CsIPPhonePolicy cmdlets are only available using the online management shell.

  • Using Skype for Business Online Management Shell issue the Get-CsIPPhonePolicy cmdlet to review the following default configuration for any Office 365 tenant.  Note that the EnableDeviceUpdate parameter is set to True by default.

Get-CsIPPhonePolicy

image

When a VVX phone is registered with a user account in this online tenant running at least the minimum required 5.4.0A firmware version it will automatically check with the device update server when signing in or booting up with previously entered cached credentials. 

Shortly after a successful registration the phone may display a message that a new firmware update is available.  This will happen if the phone is currently running a version which does not exactly match the version that Microsoft currently has published on their servers.  As is always the case with the device update process it does not matter if existing version is older or newer, meaning the phone can upgrade or downgrade based on its version compared to the version advertised by the server.

So if the phone has detected that a different version is available on the server then an alert notification message will be shown on the Warnings screen, which is reported on the Alert icon on the top-left corner of the home screen.

image

For example the phone used to capture these screenshots is a VVX 601 running the most recent 5.4.4.3041 version of software supported for on-premises Lync and Skype for Business environments.

Understand that Microsoft publishes only the most recently qualified version for Skype for Business Online.  While updated versions are released for Skype for Business on-premises deployments often not every individual release goes through the complete online qualification process.  The point here is that the most current version that is both qualified and fully supported by Microsoft and Polycom is what should be used on O365-registered phones.  Leaving the device update service enabled is currently the best practice for keeping the phones on that specific approved version.

image

As shown above the qualified version at the time of writing this article is 5.4.1.17653 which is a few releases older than the 5.4.4.3041 version currently installed on this specific phone.

So what will happen here is that as soon as this phone is left inactive for 15 minutes (900 seconds) it will automatically begin the process of installing the approved firmware version from the server, effectively downgrading the device to the older, approved version.  Also note that the Reboot button on the above screen can be used to immediately trigger the update process as apposed to waiting for the inactivity timeout to be reached.

The Lync Device Update menu shown below can be used to see the last time the phone checked in with the device update service.

Home > Settings > Status > Diagnostics > Lync Device Updates

image

Disable Device Updates

To allow phone to run on a different version then the device update behavior can be disabled by editing the online IP phone policy that Polycom UCS devices natively understand.

Configure Policy

  • Using the Skype for Business Online Management Shell issue the following Set-CsIPPhonePolicy cmdlet to change the device update behavior.

Set-CsIPPhonePolicy -EnableDeviceUpdate $false

image 

  • Then run the Get-CsIPPhonePolicy cmdlet to verify the change has been applied to the policy.  The following cmdlet example simply shows how to filter out the other parameters.

Get-CsIPPhonePolicy | Select-Object EnableD* | fl

image

As with any policy changes the registering device will not see this immediately.  There are several factors at play impacting how quickly a currently registered phone would pick up the new setting.  Typically within 8 hours policy changes are refreshed throughout all clients, but a manual reboot of the phone can help expedite this.  Given that this change is applied to a massive and mostly uncharted cloud provider environment it typically takes a few minutes for that change to propagate amongst the tenants home pool.

Testing has shown that waiting about 15 minutes after applying the policy change above is sufficient before rebooting a phone.  Because the default update timeout is also 15 minutes make sure to interact with the phone at least once to reset that timer to prevent the device from updating itself before picking up the new setting.

Obviously this approach works if one is prepared for this but most likely the phones have already flipped to the undesired version and when looking for a solution this blog article was found.  So more likely the phone is already been downgraded and the timing is not really critical.  Simply disable the update service, wait until the phones have picked up the policy change, and then upgrade them to the desired version using any of the supported methods.

Validate Endpoint Configuration

To verify that the phone has picked up the new configuration after rebooting and re-registering to Skype for Business Online there are a few items which can be checked.

  • The notification of an available device update will no longer appear on the phone’s home screen nor in the Warnings window.

  • The Lync Device Updates menu is now hidden and will no longer be shown under the Diagnostics menu. 

  • The ‘device.prov.lyncDeviceUpdateEnabled’ parameter will be set to ‘0’ to indicate that it is disabled.

While the first two items can easily be seen directly on the phone to be absolutely sure that device updates has been disabled on the device configuration parameters can be viewed using the following procedure.

  • Connect to the web management UI on the phone.  If it is disabled then enable it and reboot the phone, as shown in the Enable Web Server section of this past article..

  • Sign in using the defined Admin password (456 by default) and then browse to the Utilities > Import & Export Configuration menu.

  • Expand the Export Configuration section and then select Device Settings from the drop-down menu.

image

  • Click Export and save the file.  Once downloaded open the Export_device_settings.cfg file.  These files are easiest to navigate using an XML Editor like XML Notepad, but any text editor/viewer will work.

  • Scroll down towards the bottom of the file and look for the device.prov.LyncDeviceUpdate* section of parameters.

  • Check the value of the device.prov.lyncDeviceUpdateEnabled parameter.  As shown below a defined value of 0 indicates that the device updates are disabled which the phone did receive in-band during the last registration attempt.

image

Configure Individual Phones

As mentioned earlier it is recommended to leave these device updates services enabled to insure the phones are always running on the latest approved build.  But in the event that a different version needs to be installed on all phones then the process above can be used.

If only looking to prevent one or a few phones from upgrading for the purposes of testing other firmware versions then it is better to disable the update capability directly on the phone instead of on the server which currently only supports a single Global policy that applies to all users in the specific O365 tenant.

  • Create a new txt file called DisableLyncUpdate.cfg and copy/paste in following text:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<PARAMETERS device.set="1" device.prov.lyncDeviceUpdateEnabled.set="1" device.prov.lyncDeviceUpdateEnabled="0" lync.provisionDeviceParams.enabled="0" />

  • Using the process shown in the previous step access the web management UI and from the Utilities > Import & Export Configuration menu Import the file that was created in the previous step into the phone.

The first two parameters must be set to 1 in order to write changes to any phone parameters in the device settings partition.  The last two parameters will then disable device updates in addition to ignoring any device paramters currently being provisioned in-band during the SfB registration process.  Obviously changing only the device update parameter would not be sufficient as the next time the phone applies the client policy settings then it will simply revert back to the server-provisioned behavior.  Setting the lync.provisionDeviceParams.enabled parameter to 0 makes sure that does not happen.  Be aware though that this means the phone will ignore all in-band client policy settings controlled by the Set-CsIPPhonePolicy cmdlet. not just the device update parameter itself.

To configure the alternative scenario of disabling updates on the client policy and then enabling them for a few individual phones then simply change the device.prov.lyncDeviceUpdateEnabled values to ‘1’.

Skype for Business VBSS Update

June 30, 2016 by · 9 Comments 

Since the introduction of VBSS in the article Video Based Screen Sharing (VBSS) for Skype for Business last year Microsoft has released several changes to the platform to further leverage this technology.  This new article will serve as an update to the concepts outlined in the original as well as outline any future behavior or functionality.

It is recommended to read through the original article to gain a basic understanding of what VBSS is to better appreciate the changes and improvements covered in this new article. 

Conferencing Support

First and foremost Microsoft has delivered, in two separate stages, the ability for Skype for Business 2016 Windows clients to leverage VBSS in conferences now. As covered in the previous article when this new capability was released in 2015 it was only available for peer-to-peer Desktop Sharing sessions between to 16.x version Windows clients.  In the event that these same clients were participating in a multi-party conference then the Skype for Business Front End Server’s Application Sharing Multipoint Control Unit (ASMCU) would be driving the media control for sharing content between all parties.  This ASMCU, whether it was in an on-premises Lync or Skype for Business Server deployment or instead running in the Office 365 cloud as part of Skype for Business Online would still be using the legacy Remote Desktop Protocol (RDP) technology.

Online Meetings

Since posting that original article though this has changed.  Early in 2016 Microsoft quietly added VBSS support to the ASMCU components in their Skype for Business Online platform.  This means that any conference hosted by a Skype for Business Online user and attended by only Skype for Business 2106 Windows clients can leverage VBSS for sharing their desktops.  If any older client versions were to join the meeting then the ASMCU will immediately step-down to using RDP, just as peer sessions were already reverting to RDP in the event that the receiving party would attempt to take remote control of the session.

It is important to understand that the ASMCU does not create a multiple codec stream scenario like the AVMCU can do with X-H264UC encoded video.  As covered in a past Lync Conference presentation the AVMCU can request that the active speaker in a conference should send two encoded video streams: one using Scalable Video Coding (SVC) and the other in Real Time Video (RTV).  This is a “highest-common denominator” experience which continues to provide the SVC video streams to all other meeting participants which support that video codec, yet also allows a legacy client which only supports RTV to still see the active speaker’s video.

The ASMCU does not function this way as only a single Desktop Sharing stream is provided by the sending client, it cannot simultaneously encode an SVC stream and and RDP stream.  Thus the inclusion of any client in the meeting which does not support VBSS (which is literally every Lync/SfB client available except for the 2016 Windows desktop client) will trigger the ASMCU to request the client that is sending content to only use RDP, otherwise referred to as a “lowest-common-denominator” experience.

On-Premises Meetings

As of this week with the release of the June 2016 Skype for Business Server 2015 Cumulative Update (a.k.a. CU3) now on-premises Skype for Business deployments can join in the fun.  With the application of these server updates the ASMCU and all related components are now VBSS-aware and the functionality is identical to what is explained above, although it can be turned off if desired.

Upon closer inspection of the various June update articles there exists one interesting item that may seem a bit confusing at first glance: some of seemingly unrelated server components are referencing VBSS updates.  For example the Video Interop Service knowledge base article states that this cumulative update introduces VBSS.  So does the Mediation Server update article.  It does seem plausible that, with an understanding of VIS, one might think that X-H264UC could now be utilized to somehow provide desktop sharing across the VIS server, but how in the world could a Mediation Server leverage VBSS?  The answer is that these various components are simply updated to be aware of VBSS as a media session so that they function properly, and no different than before, when VBSS is active in a call or conference.  They do not actually support handling VBSS session themselves, only the ASMCU does that.

Along with the recent release of these cumulative updates Microsoft has also posted some guidance in TechNet around VBSS.  That article basically defines the same limitations in the usage of VBSS as originally covered on this blog.  So new new functionality appears to have come to VBSS itself, only that it is now more widely supported throughout the Skype for Business platform.

In short, given the proper circumstances, an improved desktop sharing experience is now available for both peer sessions and conferences.  The key words there are “desktop sharing” as that is still the only modality which can leverage VBSS.  Any other content sharing modality (e.g. Programs, PowerPoint Files, etc).

Management

The ability for the 16.x clients to leverage VBSS is enabled by default, but can be disabled if desired.  As covered in the previous article this can be seen in SIP messages during the initial setup of a desktop sharing session.  The conferencing engines in Skype for Business Online and Server 2015 (with CU3) platforms are also enabled by default, but only the on-premises version can be disabled.

So as long as the remote host that a client is attempting to negotiate and send a desktop share also supports VBSS then it will be used, initially at least.  Regardless of whether that remote host is another supported client, a SfB Online ASMCU, or a SfB Server 2015 ASMCU running CU3.

If an administrator wishes to disable the default behavior for some reason then this can be archived using one of three different methods currently available:

  • Disable VBSS for either peer sessions and/or conferences at the client level directly on the workstation.
  • Disable VBSS for conferences only at the ASMCU level directly on the server.
  • Disable VBSS for both peer sessions and conference at the client level on a server-side client policy.

Out-of-Band Client Configuration

The first option is to disable it at the client level by updating the registry of the workstation where the desired client is installed.  Using this method will disable the use of VBSS and limit the client to using RDP for Desktop Sharing in any and all scenarios. 

image

This is applicable to both on-premises and online user accounts as the configuration is performed solely at the workstation level and does not depend on any server-side management control.

  • Using either the Registry Editor (or an Active Directory Group Policy configuration) set either of these registry values to control the applicable client(s) based on their platform (32 or 64 bit).

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Lync]
"EnableP2PScreenSharingOverVideo"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\16.0\Lync]
"EnableP2PScreenSharingOverVideo"=dword:00000000

Keep in mind that disabling this feature will mean that if the affected client joins a conference were VBSS is available then the ASMCU will be forced to revert to the lowest-common-denominator scenario and fallback to using RDP for all attendees.  It does not matter if the ASMCU still prefers to use VBSS by default though as if any or all connected clients have this disabled then they will not attempt to use it and instead force the use of RDP as the only remaining option.

With the addition of VBSS support in conferences there is now another new registry value made available to the client.  While not specifically stated in the Microsoft documentation, assume that the June update for the Skype for Business 2016 client is also needed in order to support this new setting.  (Some of the testing performed for this article was using the 16.0.6925.1018 Click-to-Run version.)

  • Using either the Registry Editor (or an Active Directory Group Policy configuration) set either of these registry values to control the applicable client(s) based on their platform (32 or 64 bit).

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Lync]
"EnableConferenceScreenSharingOverVideo"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\16.0\Lync]
"EnableConferenceScreenSharingOverVideo"=dword:00000000

The TechNet documentation is currently a bit vague here as while these parameters are included, the actual implementation of them is vague and confusing.  There is also a statement that both of these P2P and Conference settings should be set to the same values: either both disabled or both enabled.  Yet testing showed that the expected behavior is seen when only one of the two modes are disabled.  Given the amount of other incorrect information currently in that document it is difficult to state why it might not be supported.

Server-Side Configuration

Another approach is to control the behavior directly from within Skype for Business Sever.  There are currently two server-side options available to control whether VBSS or RDP is the default option for desktop sharing.  These settings are only available for on-premises deployments as Online tenants clearly could not be given control of a multitenant-impacting feature such as this in the various ASMCUs across the cloud.

The first server-side option applies only to conferences by turning off VBSS at the ASMCU level.

  • In the Skype for Business Server Management Shell use the Get-CsMediaConfiguration cmdlet to verify the current configuration.  Note that EnableVideoBasedSharing parameter should be enabled by default after the successful installation of CU3.

Get-CsMediaConfiguration

image

  • To disable the default usage of VBSS on conferences simply use the following Set-CsMediaConfiguration.

Set-CsMediaConfiguration -EnableVideoBasedSharing $false

image

  • To confirm the modification simply use the Get-CsMediaConfiguration alone or optionally with a filter as shown below weed out the unwanted parameters

Get-CsMediaConfiguration | Select-Object Identity,EnableV* | fl

image

Omitting the Identity parameter in the cmdlet above will apply the change to the default Global entry.  If additional Media configurations are defined then the above parameter could alternatively be configured differently for individual pools at the site or service levels.

Remember that this configuration parameter only applies to the ASMCU though.  So while RDP will be used in conference calls hosted on the configured environment or pool this does not disable the use of VBSS in peer desktop sharing sessions between SfB clients in the same environment.  The change is near immediate and will start to apply to any new Desktop Sharing sessions started in a conference, even in existing conferences, but not to an active sharing session that was already running before the change was applied.

In-Band Client Configuration

This option will disable VBSS for both conferences and peer to peer sessions by using a single parameter which actually controls the clients themselves.  Where the setting above disables VBSS directly on the ASMCU, making client configuration moot, this approach leaves VBSS enabled on the ASMCU and utilizes the client policy provisioning model to disable VBSS at the client level.

One advantage of this option would be to configure unique conferencing polices for different groups of users, allowing VBSS for some and limiting others to RDP.  Clearly VBSS cannot be disable at the ASMCU for that scenario to work so the previous configuration option would not work as it would disable VBSS for all ASMCU participants.

In essence this configuration can produce the same behavior as the out-of-band registry approach with one exception: both conferencing and P2P functionality is impacted.  Where as with the registry approach it is possible (although stated as unsupported) to individually disable one call scenario or the other.

  • In the Skype for Business Server Management Shell use the Get-CsConferencingPolicy cmdlet to see the new ApplicationSharingMode parameter and default VideoWithFallback value.

Get-CsConferencingPolicy

image

  • To disable VBSS for both conference and peer sessions for all clients assigned to the Global policy enter the following Set-CsConferencingPolicy cmdlet.

Set-CsConferencingPolicy -ApplicationSharingMode RDP

image

  • To confirm the modification simply use the Get-CsConferencingPolicy alone or optionally with a filter as shown below weed out the unwanted parameters.

Get-CsConferencingPolicy | Select-Object Identity,App* | fl*

image

For this change to take affect the Front End server was rebooted and the clients were (automatically) reregistered.

The relationship between the server policy and client configuration is shown in the table below.  The steps above would have changed the configuration from the default of enabled to disabled.

Parameter VBSS Enabled
(Default)
VBSS Disabled
Server ApplicationSharingMode VideoWithFallback RDP
Client EnableConferenceScreenSharingOverVideo
EnableP2PScreenSharingOverVideo
True
True
False
False

 

To validate the configuration and actually see how these in-band settings are pushed to the client then the workstation’s UCCAPI logs can be reviewed to see the provisioning information outlined above.  Each time a client signs-in then the following provisioning data is passed in-band to the client.

  • Inside the meetingPolicy provisioning group the EnableConferenceScreenSharingOverVideo parameter will be set to False when the server parameter is set to RDP as explained above.

<provisionGroup name="meetingPolicy" >
<instance >
—snipped—
<property name="EnableConferenceScreenSharingOverVideo" >False</property>
—snipped—
</instance>
</provisionGroup>

  • A little farther down the log file the endpointConfiguration group will contain the peer to peer parameter EnableP2PScreenSharingOverVideo which is also now set to False.

<provisionGroup name="endpointConfiguration" >
<propertyEntryList >
—snipped—
<property name="EnableP2PScreenSharingOverVideo" >False</property>
</propertyEntryList>

Summary

As the behavior covered in this article is brand new and still awaiting additional documentation from Microsoft then any future changes or additional details will be added to this article.

Skype for Business Updates

May 16, 2016 by · 10 Comments 

By popular request here is an updated article, similar to that of the living Updating Lync 2013 article, which will track the various Skype for Business client and server updates.  Note that as with the previous article the various mobile clients are omitted mainly due to their update frequency and little value the historical data really provides.

Server Updates

Download

As Microsoft only provides the latest releases for the server components then the following two links are always updated with the most recent information and can be used as a definitive source of the latest server updates.

Unlike Lync Server 2013 which provided both individual component package downloads and the entire installer package only the complete installer package (SkypeServerupdateInsaller.exe) is available for Skype for Business Server 2015.

image

Installation

Just as with applying updates to Lync servers the same basic guidance exists for Skype for Business servers:

  • Download and run the the SkypeServerUpdateInstaller shown above.
  • Start inside-out and work from Front End servers toward Edge servers.
  • Do not forget to update and verify the backend SQL database for each Enterprise Edition pool that is patched

Component History

For occasions when working with the individual packages is desired then the following table covers each cumulative update release with links to the original Knowledge Base articles for each new component.

This matrix provides a visual aid to when and how often some of the various Lync components are updated as cumulative releases will typically not refresh every single server component.  The official package version numbers will always be in the format of 5.0.8308.xxx but the 5.0 has been truncated fro the following table for spacing purposes.

  RTM – HF1
6.0.9319.55
June 2015
RTM – HF2
6.0.9319.88
Sept 2015
CU1
6.0.9319.102
Nov 2015
CU2
6.0.9319.235
March 2016
CU3
6.0.9319.259
June 2016
Core Components KB3051958 KB3098601 KB3097644 KB3134259 KB3149226
Front End server and Edge Server KB3061059   KB3097645 KB3134260 KB3149227
Enterprise Web App KB3061058   KB3097647    
Web Components Server KB3051960 KB3098600 KB3097642 KB3134262 KB3149228
UC Managed API 5.0 Runtime KB3063353   KB3097649   KB3149232
Response Group Service KB3063352   KB3097643 KB3134265 KB3149229
Conferencing Server     KB3097708   KB3149233
Conferencing Attendant     KB3097646 KB3134264  
Group Call Pickup     KB3124205    
Performance Counters     KB3097648 KB3134266 KB3149231
Busy Options         KB3137160
Mediation Server         KB3149234
Video Interop Server         KB3149235

Client Updates

The client versions listed in this article are only applicable for the Windows Installer (MSI) packages which are still made available by Microsoft to Volume License customers .  The newer Click to Run (C2R) distribution model (explained in more detail here) is now the favored method of providing Office software updates and will not be recorded in this article.  As these updates are released much more frequently it would be a dauntless task to keep up to date, as well as a bit pointless as environments leveraging C2R are not really concerned with understanding and managing periodic updates

Skype for Business 2016 Windows Client

The following table lists major 16.x client version update packages with links directly to the download pages for the clients for each processing architecture (32-bit versus 64-bit).  Be aware that Microsoft recommends using the 32-bit version software in most cases, even on 64-bit platform.

Release Date Version Number Type KB Article Client Prerequisites
September 30, 2015 16.0.4288.1000 Security Update KB2910994 x86 | x64
November 10, 2015 16.0.4300.1001 Security Update KB3085634 x86 | x64  
December 8, 2016 16.0.4312.1000 Security Update KB3114372 x86 | x64  
January 12, 2016 16.0.4324.1000 Update KB3114516 x86 | x64 16.0.4312.1000
February 9, 2016 16.0.4339.1000 Update KB3114696 x86 | x64 16.0.4312.1000
March 8, 2016 16.0.4351.1000 Update KB3114846 x86 | x64 16.0.4312.1000
April 12, 2016 16.0.4363.1000 Security Update KB3114960 x86 | x64  
June 9, 2016 16.0.4393.1002 Update KB3115087 x86 | x64 16.0.4312.1000

 

Skype for Business 2015 Windows Client Updates

A current listing of Skype for Business 2015 (15.x) client updates is still maintained in the Updating Lync 2013 article.

Spring 2016 SkypeUG Meetings

April 13, 2016 by · Leave a Comment 

The next round of quarterly Skype for Business Users Group meetings has been announced and scheduled starting this month.

newlogo_title

Latest News

The user group family has grown to 18 national events this quarter with the addition of Cleveland, OH.

Event Details

This quarter’s event will be conducted in our familiar two-session format:

The first session, presented by AudioCodes, will cover in detail the new Cloud Connector Edition (CCE) solution for Skype for Business Online as well as Cloud PBX topologies.

The second session will be an open discussion forum for all local attendees to participate in, lead by a local subject matter expert.

Industry Experts will be on-site to deliver these presentations and help answer any questions related to Skype for Business.  Food, beverages and additional door prizes will be provided courtesy of the Skype for Business Users Group and its official sponsors.

Western U.S.

Central U.S.

Southern U.S.

Eastern U.S.

 

For a full schedule of regional events the Skype for Business Users Group Meetups page lists all planned event locations with links to the associated registration page for each regional group.  For anyone who is not yet a member and would like to participate simply visit the site listed above and register for your local group, this will automatically create a new user account for you to use again for all future event registrations..


Chicago Event

As usual I will be hosting the Chicago event downtown.  Food will be ready at 5:30 so come early if you can to spend time socializing with the group before the presentations begin at 6:00.

Date Location Address
Tuesday, May 3rd 
5:30PM – Food and Networking 
6:00 PM – Presentation Kickoff
Chicago Users Group Microsoft Technology Center 
200 East Randolph Drive, Suite 200 
Chicago, IL 60601

Skype for Business 2015 Edge Server Deployment

March 28, 2016 by · 19 Comments 

This article is intended for those following along with this series of deployment articles to create a Skype for Business (SfB) 2015 Server environment.

The instruction in this article is without much of the typical in-depth explanation provided alongside most deployment articles on this blog.  A much more detailed companion article entitled Skype for Business 2015 Edge Pool Deployment is also available which overlaps with a lot of the concepts and steps in this article.  This other article addresses the more complex topic of deploying multiple Edge servers in production-like setting, but also includes additional guidance and can be used as a deeper reference to the topics covered in this shorter article.  Basically the other servers as a production deployment reference guide while this is the quick reference guide for lab deployments.  Nearly all of the guidance in the companion article related to network configuration and server preparation holds true for either scenario.

Also worth pointing out is that if one is attempting this deployment then a fair amount of Windows server and networking knowledge is assumed.  Because the Edge Pool article goes into great depth on topics and step-by-step directions this article will omit some of the basic instructions on how to get to specific windows and focus on just the important aspects.

Preparation

The baseline for this deployment is a new Windows Server 2012 R2 installation that is not joined to any Active Directory domain and is connected to two separate IPv4 networks.  These are basic requirements for an Edge Server and must be met in order to move forward with a successful deployment.

The network topology of the lab environment used for all the articles in this deployment series simply consistent of two physically separated network segments.

image

A single firewall with separate network interfaces provides connectivity for each network segment to the Internet.  The two networks do not have access to each other except for any explicitly defined firewall rules.  The rules required to allow communications to and from the Edge Server across either network are covered in the Edge Pool article which can be used as a reference.  Make sure to open and test the required ports and protocols before attempting to deploy and start the Edge Server services.

Configure Network Interfaces

The existing server has been prepared with two network interfaces connected to two separate IPv4 networks.

In order to allow normal communications typically the internal interface would have been configured with the default gateway set to the router’s IP address for that segment and the external interface would not yet have a default gateway set.

The server cannot have multiple default gateways defined yet moving the server’s default gateway to the external interface might break communications with hosts on other routed internal networks than the one it is directly connected to.  To prevent this problem then some persistent static routes are required. This topic is covered in more detail in the Edge Pool deployment article which outlines creating up to three new persistent static routes to tell the server to use the internal router to locate hosts on any of these reserved IP address ranges.  This is a normal practice in environments with multiple routed internal networks but unnecessary in a standalone lab environment like what is used in this example.

  • Review the current IPv4 configuration on both the Internal and External interfaces and configure the default gateways as appropriate.

image   image

If Remote Desktop connectivity is lost after moving the default gateways as shown above then connect to the server console and either define a required static route to back to the network where the remote console is, or if that console is actually in the ‘External’ network then check the firewall configuration to allow remote desktop connections to the external interface.  Clearly this is safe in a lab environment but if the Edge server’s external interface is to be routed to the Internet than a different approach may be advisable.

Configure Computer Name

As covered in the other article it is critical to set the proper Fully Qualified Domain Name (FQDN) on this server so that the server component installation will function correctly.  This is a commonly missed step that leads to troubleshooting installation issues further down the line.

  • View the server’s System Properties and use the More button under Computer name field to access the following window.  Enter the same DNS domain and suffix used by the internal SfB Front End server so that the Edge Server is configured with an FQDN.

image

  • Reboot the server to apply the new computer name.

Add Server Features

The Windows 2012 R2 operating system used on these servers already includes some of the require components by default (like PowerShell 3.0) and as the Edge server does not contain any web service components then IIS subcomponents will also not be installed on these servers.

  • If the server does not have Internet connectivity then mount the Windows Server 2012 installation media on the server to an available drive letter as some of the components to be installed will need to be read from the installation media as provided by the Source parameter in the following cmdlet (e.g. D:\sources\sxs).

  • Launch Windows PowerShell by selecting ‘Run As Administrator’ and enter the following cmdlet to quickly install the .NET Framework package, the Remote Server Administrative Tools, and all additional prerequisites followed immediately by a required server reboot.  (The Telnet client is also installed as it helpful for testing/troubleshooting port connectivity issues with the Edge server.)

Add-WindowsFeature RSAT-ADDS, NET-Framework-Core, NET-Framework-45-Core, NET-Framework-45-ASPNET,  Web-Net-Ext45, NET-WCF-HTTP-Activation45, Windows-Identity-Foundation, Telnet-Client –Source D:\sources\sxs

image_thumb[102]

  • Once the installation is complete a restart will not typically be required, but if prompted to do so then reboot before moving on to the next step.

Windows Updates

Before installation any SfB components make sure to apply the most recent Windows Updates, with one notable exception: do not install the Microsoft .NET Framework 4.6.1 package as this is not currently supported by Microsoft.

    • Run Windows Update and hide the package for Microsoft .NET Framework 4.6.1 for Windows Server 2012 R2 for x64 (KB3102467). Install any other pending recommended updates.

image

Configuration

This section covers updating the SfB Topology and access policies to enable both the deployment of the Edge Server and enable its functionality.

Define Edge Pool

  • Open the Skype for Business Server Topology Builder tool on the existing SfB Front End server, then download and save the current topology to a text file.
  • Navigate to the desired site, expand the Skype for Business 2015 container, highlight Edge Pools and then select the New Edge Pool action. 
  • Enter the desired Pool FQDN (e.g. edge.jdskype.net) and then select the option for This pool has one server.

image

  • On the Enable Federation window select the desired options, in this case only the Enable Federation option is addressed.  The Skype Search and XMPP options can be enabled now or later if so desired.

image_thumb[69]

  • Select the option to Use a single FQDN and IP address.

image

  • For this deployment only IPv4 addresses will be utilized, and for any Internet access then Network Address Translation (NAT) will need to be used as the Edge server’s external interface has a private IP address bound directly to it.

image

  • In the External FQDNs window the wizard will populate the suggested ports due to selecting the single FQDN and IP address option earlier.   

image

Leave the suggested ports as these are typically the best options available.  The Access Edge service will collocate external client and federation traffic on the same port (5061) and it is recommended to leave 443 assigned to the critical A/V Edge role to provide the best chance of successfully negotiating media sessions.  The assigned FQDN is typically “sip.<sipdomain>” but in this lab environment a different FQDN is used to avoid potential overlap with the internal sip record.  While any name can be used the sipexternal FQDN is one of the legacy Host (A) look records used by many clients and IP phones, so it was selected for that reason primarily.

  • At the Define the computers in this pool window click Add to launch the Add server to Edge pool wizard.

  • Enter the Internal IPv4 address that is assigned to the internal interface.

image

  • Enter the External IPv4 address in the proper field for each service and then click Finish.

image

  • Enter the Public IPv4 address for the A/V Edge service which will be translated to the server’s actual external  IP address.   This NAT configuration would be handled by the firewall depicted in the original diagram and is not addressed in this article.

image

  • Select the desired Next hop pool from the drop-down menu (e.g. fe.jdskype.net).

image

  • At the Associate Front End or Mediation Pools step select the desired Front End server or pool, which in most cases is the same as what was just selected in the previous step (e.g. fe.jdskype.net).

image

Publish Topology

Now that the new pool has been created the next step is to save and publish these changes to the Central Management Store.

  • In Topology Builder expand the newly created Edge Pool and double-check the configuration on the pool and each computer object to make sure there are no mistakes.

  • From the Action menu select Topology > Publish to launch the Publish Topology wizard.  If all goes as planned then the result should be reported as successful on all steps.

image_thumb[84]

Enable External Access

While the majority of the environment preparation is handled in the topology this is a critical step which must be performed before any external communications will be allowed.  The three major types of communications supported by the Access Edge service are Remote User Access, Federated User Access, and Public Provider Access.  To enable one or more of these feature follow these example steps.

Only remote user access will be enabled in this article.  For reference the Edge Pool deployment article discusses the other external communication types.

  • Using the Skype for Business Server Control Panel browse to the Federation and External Access section

  • Under the External Access Policy page open the default Global policy and check the Enable communications with remote users option and save the changes to the policy.

image

  • Under the Access Edge Configuration page open the default Global configuration and check the Enable remote user access option and save the changes to the configuration.

image

Export Topology

As briefly discussed earlier the Edge server deployment will require that the SfB topology data is manually exported and imported on the Edge servers which do not have the ability to locate and download this configuration information automatically.

  • Using the Skype for Business Management Shell run the following Export-CsConfiguration cmdlet to export. (This file will be retrieved in a later deployment step.)

Export-CsConfiguration -FileName c:\temp\topo.zip

image_thumb[86]

Deployment

Due to this being a lab installation then private certificates will be involved.  Both the internal and external Edge certificates will be issued from the same AD-integrated Enterprise Certificate Authority (CA) that was used for certificates assigned to the other SfB server roles.  If a public certificate is intended to be used on the external interface then the other article covers those configuration steps.

Full step-by-step directions for performing these actions can be found throughout a myriad of other articles covering various options like using the SfB Certificate Wizard, Internet Information Services Manager, the Windows certificate snap-in and even third party tools.  For the steps outlined below the popular, free DigiCert Certificate Utility for Windows is utilized.

Create Internal Certificate

Because the SfB Front End server is joined to the domain then it is an ideal host to perform online certificate requests to the AD-integrated Enterprise CA.

  • Download, install and launch the DigiCert tool on the SfB Front End server.
  • Fill out the Certificate Details field as appropriate for the Edge Server Internal certificate.  The Common Name field should be the FQDN of the Edge Server (e.g. edge.jdskype.net) and the Subject Alternative Name (SAN) should be blank.

image

  • Generate the request and then save the request data to a text file on the local server (e.g. C:\Temp\edge_internal.txt).

image

  • On the same Front End server launch either the Windows Command Prompt or PowerShell as an administrator and then issue the following certreq.exe command.  Supply the name of the text file saved in the previous step which contains the certificate request information and then enter the name of the new certificate file itself to be created (e.g. edge_internal.cer).

certreq -submit -attrib certificatetemplate:WebServer edge_internal.txt edge_internal.cer

  • When prompted to select a Certificate Authority highlight the desired CA (in this environment there is only a single Enterprise Root CA).

image

  • Select OK and if the process is successful the end result should be reported as Issued.

image

  • Use the Import option in the certificate tool to import the issued certificate file (e.g. edge_internal.cer) into the server.

image

  • Enter a descriptive Friendly Name (e.g. Edge Internal Cert) to complete the certificate creation process.

image

  • Return to the main SSL window of the utility and highlight the newly imported certificate (e.g. edge.jdskype.net) and then click Export Certificate.

  • Make sure to select the options to Export the Private Key and to Include all certificates in the certification path

image

These options are critical as without the private key this certificate is useless to the Edge server. Also the issuing Root CA’s public key needs to be manually imported into the Edge server because it is not a member of the AD domain and has not  automatically been provided these root certificates.  These options will address both of those requirements.

  • Define a password (e.g. password) to protect the export file which will contain the certificate’s private key.  This step is mandatory and cannot be skipped.

  • Choose a location and filename to save the exported certificate (e.g. C:\Temp\edge_jdskype_net.pfx).  (This file will be retrieved in a later deployment step.)

Create External Certificate

Now that the internal certificate for the Edge Server is ready a second certificate needs to be created for the external interface.  Typically this request is sent to a third-party Certificate Authority and the process above can be used to do that.  Instead of running the certreq.exe command simple copy/paste the request text into the request field of whatever CA is used.

  • Repeat all the steps above in this section to request, import, and then export the Edge Server external certificate.  The only configuration difference is that the Common Name will need to be set to the Edge Server’ External FQDN that was defined (e.g. sipexternal_jdskype_net.pfx).

image 

Now that all the server and environment preparation steps have been completed then the final processes of actually installing and configuring the Edge Server roles can begin.

Copy Files

The exported files created in the previous certificate topology and certificate preparation steps need to be manually copied from the Front End server to the Edge server.

  • On the SfB Front End server locate the topology export file (e.g. C:\Temp\topo.zip) and the two exported certificate packages (e.g. C:\Temp\edge_jdskype_net.pfx & C:\Temp\sipexternal_jdskype_net.pfx).

image

  • Copy these three files to the Edge Server to prepare for deployment and configuration steps in the next section.

Install Server Components

The steps in this section address the installation of the actual SfB Server components using the deployment wizard.  These steps can be performed on both servers simultaneously or one after another.

  • Mount the Skype for Business Server 2015 installation media on the first Edge server and then open the mounted drive to trigger autoplay of the deployment wizard.

The deployment wizard will automatically (if needed) install Visual C++ 2013.

image_thumb[90]

  • When that package installation is complete then select the option at the next window to skip checking for any updates. Leave the default Installation Location.  Click Install to advance.

image_thumb[93]

  • Accept the licensing agreement and then wait while the deployment wizard automatically installs the Core Components.

image_thumb[95]

  • Once the main screen appears select the option to Install or Update Skype for Business Server System.

  • On the Install or update member system window click Run on Step 1: Install Local Configuration Store.
  • The next window will be limited to a single option because this server is not a member of any Active Directory domain.  Browse to the location where the exported topology file (e.g. topo.zip) was copied to in the previous section and click Next.

image

The local configuration store installation process will begin immediately by loading the local installation files and then performing a check against the various prerequisite components currently installed on the server.  Assuming none of the prerequisites are missing and no problems occur with the installation of the SQL Express components then after some time that Task Status should be reported as Completed.

image_thumb[104]

  • Return to the Install or update member system window and click Run on Step 2: Setup or Remove for Business Server Components.

image_thumb[114]

This concludes the server components installation process and all that remains is to import and assign the SSL certificates before the individual services can be started and tested.

Assign Certificates

The separate internal and external certificates that were created earlier in this article can now easily be imported into the server and assigned to the proper roles.

  • Click Run on Step 3: Request, Install, or Assign Certificates to launch the Certificate Wizard.

  • Click the Import Certificate button and then enter the location of and the password for the export file which was already copied to the Edge server in an earlier section.

image

  • On the Import Certificate Summary page confirm that the Contains Private Key value is displayed as True, indicating that the import file is a complete certificate, and then click Next to complete the process.

  • On the Certificate Wizard home page highlight the Edge internal row and click Assign.
  • Select the desired certificate (e.g. Edge Internal Cert) and click Next.

image

  • On the summary page verify that the desired Certificate Use matches up with the correct certificate as identified by the Friendly Name and Subject Name fields. 

image

  • Finish the wizard to assign the certificate to the internal Edge service.

  • Repeat all steps above in this section, but this time select the External Edge certificate.

The Certificate Wizard should now indicate that the chosen certificates have been assigned to the appropriate roles, as indicated by the green checkmarks.

image

Start Services

The final step is to start the SfB Edge Server services.  The new Start-CsPool cmdlet provided in SfB Server 2015 only applies to Front End pools and cannot be used with Edge Servers.  Thus the services can either be started manually or the server can be rebooted to leverage the automatic startup procedure.

  • Restart the Edge server and when it comes back online monitor the status of the individual services to validate that all have started successfully.

image

Skype for Business 2015 Edge Pool Deployment

March 28, 2016 by · 34 Comments 

Moving on with this series of deployment articles the next major component of the core Skype for Business (SfB) infrastructure to address is the Edge Server role.  This server role, from a deployment and architecture standpoint, is basically unchanged from previous Lync Server product releases.  These articles have all focused on a simple Skype for Business topology starting with a single Standard Edition server deployment.  The driving force for selecting that topology was primarily that the much-improved official documentation from Microsoft already covered the deployment of an Enterprise Edition Front End server pool.

For those following along with these deployment articles to create a lab environment then a simpler companion article entitled Skype for Business 2015 Edge Server Deployment is also available which quickly addresses adding a single Edge Server to this example environment.

But for this article a different, much more verbose approach has been taken.  The Server deployment article linked above only covers the unique, individual steps to quickly deploy an Edge Server in a lab with private certificates. This article covers in-depth best practices and explanations of each step along the way to deploying a pair of servers in an Edge Pool leveraging a more realistic scenario using public IP addresses and third-party certificates.  Basically this article is the production deployment reference guide and the other is the lab quick reference guide.  Nearly all of the guidance in this article related to network configuration and server preparation holds true for either scenario.

Background

A functional Front End server deployment is required before one or more Edge servers can be deployed into the environment.  This means successfully completing the configuration detailed in at least these three articles: Part 1, Part 2, and Part 3.  Note that following those articles verbatim only covers the deployment of a single Standard Edition Front End Server, which actually is sufficient to perform this deployment.  The Edge Server article mentioned above is meant for environments built specifically to those articles, while this article basically assumes that there is already at least one Skype for Business Enterprise Edition Front End Pool deployed in the environment.  But if desired, it is officially supported (albeit a bit unorthodox) to mix a resilient Edge Pool with a single Standard Edition Front End Server.

A Reverse Proxy solution is also not covered yet.  This role will be addressed after the completion of Edge server deployment, but leveraging some of the legacy behavior that is still supported in even the latest Skype for Business clients will allow for at a minimum of external connectivity from Windows Desktop clients and many IP desk phones.  To support the myriad of newer clients and platforms the Lyncdiscover service will need to be published using a reverse proxy model of some sort.  A future article will cover this topic in some capacity.

Two virtual servers will be used for this deployment and have already been installed with Windows Server 2012 R2 and prepared using the same methods as the other servers in the environment.  The key difference is that these two servers are located in a Perimeter Network or Demilitarized Zone (DMZ) and thus are not joined to the same Active Directory domain that the rest of the internally-located server roles are.  In fact these two new servers are not joined to any domain and are simply in the default Workgroup mode.

The network configuration used for this environment leverage the best practice model of two separate perimeter networks on different IP address subnetworks.  The internally-facing segment contains a dedicated internal private Class A IPv4 addressing scheme that is routed without the use of any Network Address Translation (NAT) to all of the internal servers.  The externally-facing perimeter network contains a fully-routable public IPv4 subnet.  The best practice approach of leveraging DNS Load Balancing will also be applied to this Edge pool, there will be no complicated Hardware Load Balancers (HLB) to address.


Preparation

Deploying an Edge Server is a complicated venture as it touches some of the most complex parts and concepts of networking in general.  This article by no means is intended to be a single reference on this topic but is meant to show at least one end-to-end deployment scenario by example.  Additional guidance and various accepted best practice guidance is also intermixed throughout where appropriate.  Any deviation from the example instructions warrants reading through the official Microsoft planning documentation to make sure that a supported, functional scenario is selected.

Also the details covered here in the preparation stage are reviewing an already staged environment, the actual Windows Server deployment and configuration steps will not be covered in detail here.  The various items required for the actual Edge Server role deployment are identified and outlined but basic Windows Server administration knowledge is assumed.

Network Configuration

The following diagram shows a typical network topology for a pair of Edge Servers.  Each server has two network interfaces which are connected to separate networks which cannot route traffic directly between them outside of the dual-homed Edge servers themselves.

image

  • The Public DMZ is using a full Class C with a natural subnet mask (this is a random network and the individual IP address were just made up for this example).  Each Edge Server has three individual public IP addresses assigned directly to a single external interface connected to this network.

  • The Private DMZ uses a reserved Class A segment with one IP address assigned to the internal interface on each Edge Server connected to this network.  

  • The Internal network includes a SfB Front End pool with three individual servers assigned one IP address per host in a naturally masked Class C network.  Also depicted is a pair of internal DNS servers assigned which will be leveraged by the Edge servers for resolving hosts in any network. (It is assumed this internal DNS server also handles requests for any public hosts by using root hints or forwarding.)

As covered in a various articles (like this) only a single default gateway should be defined on the server, and only on the external interface.  The default gateway setting on the internal interface must be left blank.  This insures that connections to undefined networks will always go out toward the Internet.  To allows these servers to find and communicate with internal hosts there is a standard accepted practice of defining static routes for all reserved subnet ranges to utilize the internal interface as the target route.

Understand that while IPv4 addresses in these ranges cannot be routed to the Internet there may be cases where some of these subnetworks are actually in use inside the external firewall.  So any connections to hosts on any subnets within these ranges which can only be reached via the external interface can be handled in one of two ways.  Either define only the internal networks that exist in the environment below instead of including the entire ranges, or use the configuration below to include all ranges and then add additional static route for the specific external networks and assign the external gateway as the destination for those custom routes..

  • To configure all private reserved networks as internally reachable then on each Edge Server run the following netsh commands as an administrator in the Windows Command Prompt or in PowerShell

netsh interface ipv4 add route 10.0.0.0/8 "Internal" 10.222.4.1
netsh interface ipv4 add route 172.16.0.0/12 "Internal" 10.222.4.1
netsh interface ipv4 add route 192.168.0.0/16 "Internal" 10.222.4.1

The ‘Internal’ string is unique to the server as it is the actual name of the network interface.  This name can be found in the Network Connections properties or by using the ‘netsh interface ipv4 show interfaces’ command.

  • To validate that the above commands completed successfully use the following netsh command to list all defined persistent routes.

PS C:\> netsh interface ipv4 show route store=persistent

Publish  Type      Metric    Prefix               Idx  Gateway/Interface Name
——-  ——–  ——-   ——————-  —  ———————-
Yes      Other     100       10.0.0.0/8             0  10.222.4.1
Yes      Other     100       192.168.0.0/16         0  10.222.4.1
Yes      Other     100       192.16.0.0/12          0  10.222.4.1

Yes      Other     Default   0.0.0.0/0             15  240.42.5.1

The default gateway that was configured on the external interface will be displayed in this list but is identified with a Metric value of Default.  The three other entries highlighted above reflect the three static routes used to locate any hosts which might be on the reserved IPv4 address ranges which are not routable over the public Internet.

DNS Configuration

With the prerequisite IP addresses already configured on the Edge servers then the next step is to select Fully Qualified Domain Names (FQDN) to be used in the deployment and then create the required DNS records. This is a good step to perform early as when dealing with public DNS servers it can take several hours for these requests to be created and propagate throughout the Internet.

As shown in the diagram each Edge server is assigned 4 unique IP addresses, three on the external network and one on the internal network.  These address will be assigned to separate server roles as shown in the following table.

External DNS Records
Type FQDN IP Address Host Service Purpose
A sip.jdskype.net 242.42.5.104
242.42.5.107
Access Edge Service
A webconf.jdskype.net 242.42.5.105
242.42.5.108
Web Conferencing Service
A av.jdskype.net 242.42.5.106
242.42.5.109
A/V Edge Service
SRV _sip.tls.jdskype.net sip.jdskype.net 443 Client Autodiscover (Legacy)
SRV _sipfederationtls._tcp.jdskype.net sip.jdskype.net 5061 Open Federation
SRV _xmpp-server._tcp.jdskype.net sip.jdskype.net 5269 XMPP Gateway Service

 

  • These records are to be added to a publically available DNS server available on the Internet.

  • The Host (A) records highlighted in blue are mandatory and their creation is critical to providing the functionality of each external Edge service.  The FQDN values selected for are commonly used suggestions but are not requirements.  It is a best practice to utilize ‘sip’ for the Access Edge record but a different name can be selected if desired as well as for the other roles.

  • The Service Locater (SRV) records highlighted in green are optional but if created their names must be used in the exact format shown above and cannot be altered or they will not provide the designed functionality.  It is still a best practice to deploy the autodiscover record to support and clients and device which do not yet utilize the Lyncdiscover process.  More importantly for this specific article is that because there is no reverse proxy deployed yet then the web-based Lyncdiscover process will not yet be available to external clients, meaning that they must use the legacy fallback discovery process in order to successfully register.  The other service records can be created or omitted based on whether Open Federation and/or XMPP discovery is desired.
Internal DNS Records
Type FQDN IP Address Purpose
A edge1.jdskype.net 10.222.4.204 Internal Edge Server Interface
A edge2.jdskype.net 10.222.4.207 Internal Edge Server Interface
A edgepool.jdskype.net 10.222.4.204
10.222.4.207
Internal Edge Pool
A dc1.jdskype.net 192.168.0.100 Internal DNS Server
A dc2.jdskype.net 192.168.0.101 Internal DNS Server
A fe1.jdskype.net 192.168.0.151 Internal Front End Server
A fe2.jdskype.net 192.168.0.152 Internal Front End Server
A fe3.jdskype.net 192.168.0.153 Internal Front End Server

 

  • The records in the top three rows are to be added to the internal DNS server which houses records for both the Internal network zone and the Private DMZ zone.

  • Because the Edge servers are not domain joined then the server host records will not typically be created automatically via Dynamic DNS, so it is common to create these server records manually in the internal DNS zone that the rest of the SfB and Active Directory servers also utilize.

  • The bottom rows highlighted in gray are only in included for reference and will not need to be created manually. These host records for the DNS and Front End servers will already be in the internal DNS database due to the Dynamic DNS behavior of domain-member servers. 

Firewall Configuration

Now that the servers are properly configured on the network then next critical task is getting the proper ports and protocols opened on each firewall.  The critical steps are making sure that the internal firewall will allow the needed communication between the internal Edge interface and all Front End server(s).  This previous article outlines in detail the traffic requirement for Lync Server 2010.  Skype for Business Server 2015 includes some new services which add to the list of needed ports and protocols so those unique items will be addressed below.  Otherwise the rest of that article still applies and can be used as a resource for understanding and troubleshooting port connectivity.

The following diagram depicts the required ports and protocols used by the Skype for Business 2015 Edge Server.  To keep things simple on the actual port numbers and network protocols are shown, more detail on what type of traffic is carried over these lines of communication will be cover shortly.

image

The following tables will incorporate the rules above along with the example IP addresses assigned to each server role to show an completed table that outlines all of the specific rules needed.  The individual table rows are color-coded to match the separate lines in the diagram above to assist matching up the different rules.

External Rules
Server
Role
Source
IP
Source
Port
Protocol Destination Port Destination
IPs
Communication
Type
Direction
Access Edge Any Any TCP 443 242.42.5.104
242.42.5.107
External client SIP signaling Inbound
Access Edge 242.42.5.104
242.42.5.107
Any TCP 443 Any Skype Consumer Directory Search Outbound
Access Edge Any Any TCP 5061 242.42.5.104
242.42.5.107
Federation SIP signaling Inbound
Access Edge 242.42.5.104
242.42.5.107
Any TCP 5061 Any Federation SIP signaling Outbound
Access Edge Any Any TCP 5269 242.42.5.104
242.42.5.107
XMPP Proxy service Inbound
Access Edge 242.42.5.104
242.42.5.107
Any TCP 5269 Any XMPP Proxy service Outbound
Windows OS 242.42.5.104
242.42.5.107
Any TCP 53 Any Queries to external DNS servers Outbound
Windows OS 242.42.5.104
242.42.5.107
Any TCP 80 Any Certificate validation and revocation checking (CRL) Outbound
Web Conf Edge Any Any TCP 443 242.42.5.105
242.42.5.108
External client/server Web Conferencing data Inbound
A/V Edge Any Any UDP 3478 242.42.5.106
242.42.5.109
External client/server media Inbound
A/V Edge 242.42.5.106
242.42.5.109
Any UDP 3478 Any External client/server media Outbound
A/V Edge Any Any TCP 443 242.42.5.106
242.42.5.109
External client/server media Inbound
A/V Edge 242.42.5.106
242.42.5.109
Any TCP 443 Any External client/server media Outbound
A/V Edge Any Any TCP 50000-59999 242.42.5.106
242.42.5.109
External client/server media Inbound
A/V Edge 242.42.5.106
242.42.5.109
Any TCP 50000-59999 Any External client/server media Outbound

 

Internal Rules
Server
Role
Source
IP
Source
Port
Protocol Destination
Port
Destination
IP
Communication
Type
Direction
Internal Edge 10.222.4.204
10.222.4.207
Any TCP 5061 192.168.0.151
192.168.0.152
192.168.0.153
Server-to-Server MTLS Inbound
Internal Edge 192.168.0.151
192.168.0.152
192.168.0.153
Any TCP 5061 10.222.4.204
10.222.4.207
Server-to-Server MTLS Outbound
Internal Edge 192.168.0.151
192.168.0.152
192.168.0.153
Any TCP 5062 10.222.4.204
10.222.4.207
Media Relay Authentication Service Outbound
Internal Edge 192.168.0.151
192.168.0.152
192.168.0.153
Any TCP 4443 10.222.4.204
10.222.4.207
CMS Replication Service
Skype Consumer Directory Search
Outbound
Internal Edge 192.168.0.151
192.168.0.152
192.168.0.153
Any TCP 23456 10.222.4.204
10.222.4.207
XMPP Proxy Service Outbound
Internal Edge 192.168.0.151
192.168.0.152
192.168.0.153
Any TCP 50001-50003 10.222.4.204
10.222.4.207
Centralized Logging Service Outbound
Internal Edge 192.168.0.151
192.168.0.152
192.168.0.153
Any TCP 8057 10.222.4.204
10.222.4.207
Internal client/server Web Conferencing data Outbound
Windows OS 10.222.4.204
10.222.4.207
Any TCP 53 192.168.0.100
192.168.0.101
Queries to internal DNS servers Inbound
Internal Edge Any Any UDP 3478 10.222.4.204
10.222.4.207
Internal client/server media Outbound
Internal Edge Any Any TCP 443 10.222.4.204
10.222.4.207
Internal client/server media Outbound

 

The following clarifications and observations can be made about the information shown above:

  • Solid lines denote required items.  Excluding any of these from the firewall configuration can result in partial to no connectivity. Dashed lines indicate optional rules.  For the purposes of this article only the XMPP gateway services are identified as optional, as this is not a common deployed feature and will not be part of this deployment.  All other capabilities provided by the Access Edge service will be desired in most if not all deployments.

  • Traffic labeled as Inbound is always from the Internet to the Internal network (left to right on the diagram), and outbound is the reverse direction. It should not be visualized as the Edge Server being the center of focus.

  • The gray lines labeled as TCP 53 and 80 are simply indicating that the Edge server will need the ability to (1) query external DNS servers on the Internet to successfully perform autodiscovery processes for establishing open federation communications, and (2) download the Certificate Revocation Lists (CRL) hosted by trusted third party certificate authorities as part of TLS and MTLS communication setup.  These are commonly used ports for any type of server and these types of outbound connections to the Internet are typically open already allowed.  In the case they are not then they need to be included as part of the firewall configuration for each Edge server.

  • Pay special attention to the arrowheads as these indicate which types of communication are bidirectional which often require the creation of two separate rules in most firewall policies.  Notice that in the internal side with the exception of 5061 TCP all traffic is all coming from the internal network to the Edge server.  The Edge server does not need to initiate new connections to any internal hosts other then for server-to-server MTLS communications over port 5061. On the external side of the coin it’s a completely different story as nearly all of the rules require inbound and outbound connections to be allowed.  This has more to do with the fact that the external side is made up of external clients and federated servers.

  • All rules on the external side typically are setup to allow traffic in from any IP and to be established outbound to any IP.  For the set of internal rules the allowed sources and destinations depend on the type of traffic.  For a detailed list of which ports and used by Front End servers, Director servers, and/or Survivable Branch Appliances (SBA) see the official Microsoft documentation.  For the purposes of this deployment there is only the single Front End server and not directors or SBAs.

  • In some environments it is normal to see all outbound connections from more trusted networks to less trusted networks to be allowed by an existing policy.  In these cases that means only the rules denoted as Inbound would need to be configured in the firewall as all outbound traffic would already be allowed..  For example on the internal side of the diagram only inbound rules for 5061 TCP to internal SfB servers and. 53 TCP to internal DNS servers would be needed.

  • This topic has been figuratively beaten to death but it still warrants a brief note.  The range of 10,000 ports (50,000-59,999) used by the A/V Edge service is still a best practice to allow outbound (at minimum).  Realistically it is still opened bi-directionally but these are not active listening ports.  A few of them are dynamically opened at the exact time an ICE client needs to relay media and this is done securely.  The one exception here is that ports 50001, 50002, and 50003, which are used by the Centralized Logging Service (CLS) is programmed to actively listen on these ports.  Unfortunately on an Edge server this service will open these listening ports on both interfaces, meaning that those 3 of the 10,000 ports opened from the Internet to the Edge external interface will be actively listening. The workarounds are either to limit the open inbound range to 50004 and above, or block those external ports directly on the server as outlined in this blog article from fellow Skype for Business MVP James Cussen.

  • With one exception all traffic types are transported as TCP.  The only rules that can utilize UDP are for handling audio and video streams.  All A/V media connections will prefer to use UDP for delivery and only fall-back to TCP if a UDP connection is unsuccessful.  Application sharing media (RDP) is limited to using TCP only.

  • All ports labeled on the diagram are destination ports.  When traffic in either direction is to be established it will leave from a dynamically assigned random high port on the source host, headed for the specific listening port on the destination host.  This is why all source ports are listed as ‘Any’ in the table above.

Using the diagrams and details above should provide a clearer picture of exactly what ports are used to carry what types of data and where that traffic needs to flow between.

Certificate Configuration

Deploying Edge servers typically involves purchasing at least one certificate from a public Certificate Authority (CA) which is usually not an immediate process. Thus it is ideal to have a defined plan before starting the actual server deployment and in some cases even perform the requests to third party CAs several days in advance.

An older article on Lync Edge Serve Best Practices covers a lot of detail on how to select and configure certificates, nearly all of which is still unchanged since Lync 2010.  The last section on Edge Pools outlines the requirement that a single standard SSL certificate, with no SAN field and only the pool FQDN (not the server FQDN) is used for the internal Edge role.  This is one of the more commonly misunderstood requirements in multiple server Edge pool deployments.

There are two different certificates which need to be created for application to the new Edge Server:

  • A single SSL certificate will be requested from a private internal Windows Enterprise CA during the deployment.

  • A single SSL UC certificate will be requested from a public third party trusted CA.

Because the internal certificate will be issued by an Windows AD-integrated Enterprise CA this process can be started as part of the environment preparation in a simpler method than using the certificate wizard on the Edge server itself.  The external certificate request will be addressed later in this article but it can also be performed ahead of time as the desired configuration is already known.

  • Connect to the existing SfB Front End server and launch Internet Information Service Manager (inetmgr.exe) and then highlight the local server object.

  • Open the Server Certificates feature listed under the IIS group.

  • Select the Create Domain Certificate action and then enter the Edge Pool FQDN as the Common Name (e.g. edgepool.jdskype.net).  Fill out the remaining fields as desired.

image

As mentioned above this certificate which will be bound to the Internal Edge service on both servers must contain only the shared pool name.  Unlike a Front End server, the individual Edge server hostname should not be included on the certificate.  (This concept is discussed in more detail in this article.)  By contrast If this was a single standalone Edge server then the server’s own hostname would be used here, but not when dealing with multiple computer pools.  Other server and clients communicating with Edge Servers in a pool need to be presented the exact same certificate by either server as to not break the secure communications channel during an Edge server failure event.

  • On the next window use the Select button to enter the desired AD-integrated Enterprise CA (e.g. jdskype-RootCA\DC.jdskype.net) and then enter a descriptive Friendly Name for the new certificate (.e.g. Internal Edge Pool Cert).

image

  • Click Finish to perform an immediate online request, which once successful will also automatically import the certificate into the local server and pair it with the private key.

While IIS Manager is a great tool for creating quick basic SSL certificates it is not ideal for exporting these certificates as it will not include the CA chain.  To export the certificate so that it can be easily imported in the Edge Server a different tool should be used.

  • On the same server open a new Microsoft Management Console (mmc.exe) window and select File > Add/Remove Snap-in.

  • Add the Certificates snap-in and  then select Computer account.

image

  • Select Next, Finish, and then OK to return to the main console window.

  • Expand Certificates (Local Computer) > Personal > Certificates and then highlight the certificate which was just created (e.g. edgepool.jdskype.net).

image

  • Select Action > All Tasks > Export to open the Certificate Export Wizard.

  • Select Yes, export the private key on the Export Private Key page.

image

The previous step is critical as without the private key as part of the export then the certificate would be useless on the Edge Server.  As of equal importance is the next step which ensures that the Root CA’s public certificate is also included in the export file as the Edge servers do not currently trust the internal CA as they are not part of the internal AD domain.

  • Leave the default settings on the Export File Format page but ensure that the Include all certificates in the certification path if possible option is enabled.

image

As this export file will include the all-important private key portion of this certificate then it must be secured.  Because it will be copied to computers that are not domain members then the Group or user names option cannot be selected.  A password must be created and set on this export file.

  • Enter and confirm a password (e.g. password) to protect this export file.

image

  • Select a name and location to save the file (e.g. C:\Temp\internaledge.pfx)

image

  • Click Finish to complete the export wizard and then copy this file to both of the Edge Servers.  The certificate will be imported into the server’s store in a later step.

Configuration

At this point the core Windows Server is prepared and ready for the SfB installation to begin.  Just as with any other server role the first step in the deployment is updating the Topology.  But where this server role differs is how that is performed.  With all other internal server roles these are places on domain member servers which typically will have network access to the existing servers, meaning that during the actual server installation the SfB Central Management Store is reachable.

But when looking at the traffic rules above there is no path opened for the replication service to reach the internal servers.  Because the database replication model is push-only for Edge servers then that is why the 4443 TCP entry is only outbound.  This means that during the initial Edge Server deployment the topology information will need to be manually imported into the Edge Server.  This process is covered in the steps below, but otherwise the deployment process of this server is very much like any other SfB server.

Define Edge Pool

  • Open the Skype for Business Server Topology Builder tool on the existing SfB Front End server, then download and save the current topology to a text file.

  • Navigate to the desired site, expand the Skype for Business 2015 container, highlight Edge Pools and then select the New Edge Pool action. 

  • Enter the desired Pool FQDN (e.g. edgepool.jdskype.net) and then select either option to create a multiple server or single server pool.  As explained at the front of this article a multiple computer pool will be covered in this configuration.

image

  • On the Enable Federation window select desired options  In this example only Lync/SfB Federation will be configured.  Skype consumer search capabilities will be added later and potentially addressed in a future article.  As mentioned earlier the XMPP gateway will not be used.

image

  • Do not enable the option to Use a single FQDN and IP address as multiple Edge servers and separate dedicated IP addresses have already been allocated for this deployment.

image

  • For this deployment only IPv4 addresses will be utilized, and there will be no Network Address Translation (NAT) used as the Edge server’s external interfaces have public IP addresses bound directly to them.

image

  • In the External FQDNs window enter the previously selected hostnames (e.g. sip.jdskype.net, webconf.jdskype.net, av.jdskype.net) for each of the three external Edge services, retaining the default port selection of 443 for each.

image

  • At the Define the computers in this pool window click Add to launch the Add server to Edge pool wizard.

  • Enter the Internal IPv4 address and FQDN of the first Edge server and then click Next.

image

  • Enter the three External IPv4 addresses in the proper field for each service and then click Finish.

image

  • Repeat the two steps above and enter the unique information for the second Edge server.  When complete the Define New Edge Pool window should include two entries as shown below.  Click Next to advance.

image

  • Select the desired Next hop pool from the drop-down menu (e.g. fe.jdskype.net).

  • At the Associate Front End or Mediation Pools step select the desired Front End server or pool, which in most cases is the same as what was just selected in the previous step (e.g. fe.jdskype.net).

Publish Topology

Now that the new pool has been created the next step is to save and publish these changes to the Central Management Store.

  • In Topology Builder expand the newly created Edge Pool and double-check the configuration on the pool and each computer object to make sure there are no mistakes.

  • From the Action menu select Topology > Publish to launch the Publish Topology wizard.  If all goes as planned then the result should be reported as successful on all steps.

image

Enable External Access

While the majority of the environment preparation is handled in the topology this is a critical step which must be performed before any external communications will be allowed.  The three major types of communications supported by the Access Edge service are Remote User Access, Federated User Access, and Public Provider Access.  To enable one or more of these feature follow these example steps.

At minimum remote user access will be enabled in order to later test Edge functionality by attempting to sign in externally, via the Edge Server, with a Skype for Business enabled user account.

  • Using the Skype for Business Server Control Panel browse to the Federation and External Access section

  • Under the External Access Policy page open the default Global policy and check the Enable communications with remote users option.

image

Going back to the introduction of the Edge Server this functionality has always been poorly named.  Reading that option as it is written makes it seem like it controls the ability for externally registered users to communicate with internally registered users, which is completely incorrect.  This feature really should be called “Enable external user registration” as that is exactly what it does.

  • If federation and public IM connectivity are also desired then these options can also be selected, but will not be addressed in this article.

Note that steps above are the simplest way to enable these features for use with all users in the environment.  If a more granular approach is preferred then it is recommended to instead create new User or Site Policies and then users can be enabled automatically by their site association or by manually assigning them to the newly created policy.

  • Save the changes and the main window should now reflect the desired external access policy settings.

image

That first step simple enables the policy to allow these types of communications in the environment.  Next the actual Edge server configuration must also be defined to handle these actions.

  • Under the Access Edge Configuration page open the default Global policy and check the Enable remote user access option.  If federation was also enabled in the previous policy then make sure to enable the desired, related settings here as well.

image

  • Save the changes and the main window should now reflect the desired Access Edge configuration.

image

Export Topology

As briefly discussed earlier the Edge server deployment will require that the topology, which now includes the new configuration steps performed in this section, to be manually exported and imported on each Edge server.  During the deployment of these servers they do not have the ability to directly access the internally-stored configuration information so it must be provided manually during deployment.  The following steps will prepare this data for use in the later server installation process.

  • Using the Skype for Business Management Shell run the following Export-CsConfiguration cmdlet to export.

Export-CsConfiguration -FileName c:\temp\topo.zip

image_thumb86_thumb

  • Copy the exported file (e.g. topo.zip) and save it to a convenient location on both Edge servers for use later in this article.

Deployment

As with any Windows servers which will have SfB server components installed there are various prerequisite packages which must be installed or enabled first.

Add Server Features

The Windows 2012 R2 operating system used on these servers already includes some of the require components by default (like PowerShell 3.0), but as the Edge server does not contain any web service components then IIS subcomponents will not be installed on these servers.

  • If the server does not have Internet connectivity then mount the Windows Server 2012 installation media on the server to an available drive letter as some of the components to be installed will need to be read from the installation media as provided by the Source parameter in the following cmdlet (e.g. D:\sources\sxs).

  • Launch Windows PowerShell by selecting ‘Run As Administrator’ and enter the following cmdlet to quickly install the .NET Framework package, the Remote Server Administrative Tools, and all additional prerequisites followed immediately by a required server reboot.  (The Telnet client is also installed as it helpful for testing/troubleshooting port connectivity issues with the Edge server.)

Add-WindowsFeature RSAT-ADDS, NET-Framework-Core, NET-Framework-45-Core, NET-Framework-45-ASPNET,  Web-Net-Ext45, NET-WCF-HTTP-Activation45, Windows-Identity-Foundation, Telnet-Client –Source D:\sources\sxs

image

After installing these components make sure to run Windows Update to apply any new .NET 3.5 and 4.5.2 updates.  At the time of posting this article .NET Framework 4.6.1 is not supported for use with Skype for Business Server so make sure to avoid installing that update.  If that package has already been mistakenly updated then this article shows how to remove it before.performing advancing further.

  • Run Windows Update and hide the package for Microsoft .NET Framework 4.6.1 for Windows Server 2012 R2 for x64 (KB3102467).

  • Install any other pending recommended updates.

Validate Hostname

Another critical step that is sometimes missed when deploying Edge servers is configuring the local computer name correctly.  The server hostnames have all been shown as FQDN so far but by default a Windows server that is not joined to a domain will not be configured as such.  If an administrator does not manually configure the FQDN on the server then the deployment steps in the next section will not do anything because the local server hostname (e.g. edge1) does not match anything in the imported topology (e.g. edge1.jdskype.net).

  • To configure/validate that the proper FQDN on the Edge Server open Server Manager and then select Local Server.

  • Click on the Computer Name value (e.g.edge1) to open the System Properties window.  Click Change.

If the Full Computer Name looks like the example below then this will need to be fixed to include the proper FQDN.

image

  • Click the More button and then enter the proper DNS domain and suffix in the field shown below and save the change.

image

Now the desired FQDN should appear as the Full computer name.  Save this configuration and reboot the server to apply the new hostname.

image

Install Server Components

The steps in this section address the installation of the actual SfB Server components using the deployment wizard.  These steps can be performed on both servers simultaneously or one server at a time.

  • Mount the Skype for Business Server 2015 installation media on the first Edge server and then open the mounted drive to trigger autoplay of the deployment wizard.

The deployment wizard will automatically (if needed) install Visual C++ 2013.

image

  • When that package installation is complete then select the option at the next window to skip checking for any updates. Leave the default Installation Location.  Click Install to advance.

image

  • Accept the licensing agreement and then wait while the deployment wizard automatically installs the Core Components.

image

Install Local Configuration Store

  • Once the main screen appears select the option to Install or Update Skype for Business Server System.

  • On the Install or update member system window click Run on Step 1: Install Local Configuration Store.

  • The next window will be limited to a single option because this server is not a member of any Active Directory domain.  Browse to the location where the exported topology file (e.g. topo.zip) was copied to in the previous section and click Next.

image

The local configuration store installation process will begin immediately by loading the local installation files and then performing a check against the various prerequisite components currently installed on the server.  Assuming none of the prerequisites are missing and no problems occur with the installation of the SQL Express components then after some time that Task Status should be reported as Completed.

image

Install Server Components

  • Return to the Install or update member system window and click Run on Step 2: Setup or Remove for Business Server Components.

image

This concludes the server components installation process and all that remains is to setup the SSL certificates before the individual services can be started and tested.

Import Internal Certificate

The internal Edge certificate which was created during the preparation steps at the beginning of this article will now be imported into the Edge servers.

  • Click Run on Step 3: Request, Install, or Assign Certificates to launch the Certificate Wizard.

  • Click the Import Certificate button and then enter the location of and the password for the export file that was created earlier on the Front End server and then copied to this Edge server.

image

  • On the Import Certificate Summary page confirm that the Contains Private Key value is displayed as True, indicating that the import file is a complete certificate, and then click Next to complete the process.

If completed successfully then the wizard will have imported the certificate, its private key, and the CA chain (in this case a single Root CA certificate) into the local server.  The wizard will place the certificate in the proper place in the local repository so how any certificates issued by the internal CA will be trusted by this computer.

Assign Internal Certificate

Now that the certificate has been imported into the Windows server it can be selected by the SfB deployment wizard and assigned to the appropriate service.

  • Highlight the Edge internal section of the Certificate Wizard and then click Assign.

image

  • Select the newly imported certificate (e.g. Internal Edge Pool Cert) which might very well be the only certificate option shown on the server at this point.

  • Advance to the Certificate Assignment Summary page and confirm that the Certificate Use is reported as Edge internal.

image

  • Complete the wizard and verify that the Task Status is reported as Completed.

image

  • Return to the Certificate Wizard’s main window to verify that the certificate is now reported as assigned to the Edge Internal service.

image

Request External Certificate

For the external certificate an offline request will be issued against a third party certificate authority.  Where IIS was previously used on a different server to create the internal interface the external certificate will instead be dealt with directly on the Edge server using the SfB Deployment Wizard.

  • On the Certificate Wizard home screen highlight the External Edge certificate (public Internet) section of the Certificate Wizard and then click Request.

image

  • Select the option to Prepare the request now, but send tit later (offline certificate request).

  • Enter a path to save the certificate signing request file that this process will create (e.g. C:\Temp\externaledge.req).

  • Do not enable the option to use an alternate template; the default Web Server SSL certificate templates used by any third party CA is desired for this request.

  • Enter a descriptive Friendly Name (e.g. External Edge Pool Cert) and leave the Bit Length at 2048.  Insure that the option to Mark the certificate’s private key as exportable is enabled as this is a critical step!  If this certificate’s private key cannot be extracted from the first Edge server then it cannot be copied to the second Edge server.

image

All Edge servers must have the exact same certificate installed on the external interfaces to function properly, they cannot use separately issued certificates even if the user-defined fields are set to the same values.  The certificates keys would not be the same and thus communications between the pool and various client connections would be adversely impacted

  • Enter the desired Organization and Geographical information in the next two windows.

  • The Subject Name (SN) and Subject Alternative Name (SAN) fields should already be populated with the external FQDNs which were defined earlier in the topology (e.g. sip.jdskype.net and webconf.jdskype.net), These names were included of the configuration data initially provided to this Edge server with the topology export file.

image

Note that the SN value is duplicated in the SAN field as this is an accepted best practice for all SSL certificates.  Make sure to be aware of this as some third party CAs will charge more for each individual SAN entry that is to be included on the certificate.

  • Leave the default settings for the remaining steps and complete the wizard.

At this point the certificate request data is saved in the specific .req file and can be submitted to a third party CA.

  • The following example shows requesting a SAN certificate from DigiCert by directly submitting the CSR data.

image

  • Submit the request and when the certificate file is provided from the CA then use the Import Certificate button on the SfB Certificate Wizard home screen to install the new server certificate as well as import the chain that may be provided from the CA.

  • Once imported then the new public certificate highlight the External Edge certificate (public Internet) section and then click Assign.

Start Services

The final step is to start the SfB Edge Server services.  The new Start-CsPool cmdlet provided in SfB Server 2015 only applies to Front End pools and cannot be used with Edge Servers.  Thus the services can either be started manually or the server can be rebooted to leverage the automatic startup procedure.

  • Restart the Edge server and when it comes back online monitor the status of the individual services to validate that all have started successfully.

image_thumb22

Polycom Phones with Skype for Business Online

February 29, 2016 by · 51 Comments 

As of the end of January 2016 many currently available Polycom IP handsets and conference phones are now supported with Skype for Business Online with Office 365.  This functionality was first added to the VVX IP handset models back in September 2015 as covered in this previous article.  Direct registration support was just added to the new RealPresence Trio 8800 last month as introduced in the firmware release table here.

This brief article reviews the basic requirements for each family of phones along with the few steps needed to successfully register a device.  Some of this content has already been made available in previous articles but is revisited here for the sake of providing a single referenceable article.  This can help clear up any confusion that long-time users of these phone may have, as well as provide a starting point for the various administration which may be completely new to these products as they move to the new voice capabilities provided in Office 365.

Background

To recap Microsoft has begun providing voice service directly in Skype for Business Online to new and existing tenants of their Office 365 cloud offering.  This new functionality has been called Cloud PBX and is comprised if a few different topologies and options.  Primarily the simplest option is for tenants to purchase additional licenses for their online users to provide PSTN Conferencing and PSTN Calling capabilities.  PSTN Conferencing provides one or more telephone numbers to be added to the user’s Skype Meetings to allow for any PSTN telephone user to dial-in to a meeting from their phone.  PSTN Calling simply means that the users will be assigned a real telephone number and can place and receive calls with any PSTN phone in the country or worldwide, depending on the purchased call plan.  This can now all be done with absolutely no Microsoft servers or services deployed on-premises.

The secondary option is to allow for a tenant to bridge their own on-premises IP-PBX or SIP trunks directly to their online tenancy.  This hybrid technology can be provided by either leveraging a small deployment of Lync or Skype for Business servers on-premises or by using the upcoming Cloud Connector.

At present the following list of devices are supported for use directly with Skype for Business Online as well as Exchange Online using the same set of credentials.  This provides both SIP registration to SfB Online and mailbox connectivity via Exchange Web Services for features like the calendar, calls logs, voice mail, etc.

  • CX600, CX3000
  • VVX 201, VVX 300/301, VVX 310/311, VVX 400/401, VVX 410/411, VVX 500/501, VVX 600/601
  • RealPresence Trio 8800

CX Phones

These two devices in the CX family of IP handsets include a Type A USB port and run Microsoft’s Lync Phone Edition software.

image

At present only the CX600 and CX3000 models are supported; the CX500 is not.  This is due to the fact that the CX500 Common Area Phone does not include a Type A USB port and thus cannot be used with the Better Together method of registering the phone.  Only the PIN Authentication method can be used with the CX500 model and this capability is not compatible with Skype for Business Online.

Prerequisites

The only requirements of the phone itself is that the installed firmware be upgraded to at least the minimum supported version for Skype for Business Online.  The following version, or newer, must be installed onto the phone prior to attempting to register it to Skype for Business Online. 

Microsoft Lync Phone Edition for Polycom CX500, Polycom CX600 and Polycom CX3000

Version: 4.0.7577.4463
Released: 5/6/2015
Download: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=23866

As of the publishing of this article Microsoft has released a newer version of this firmware (4.0.7577.4487).  This is the version that is currently available from the download link above and is also supported with Skype for Business Online.

Using a firmware version older than the .4463 release may result in a failure to register the phone and there is no way to upgrade a Lync Phone Edition device without it  first registering successfully.  For those familiar with this device there is a way to support an unregistered device update but that approach is only applicable for on-premises Lync for Skype for Business deployments.  It cannot be used with Skype for Business Online registration.  In the event that a device is still using older firmware then it must be upgraded to at least the .4463 version using some other environment first.

Registration

  • Using a USB cable connect either the CX600 or CX3000 to a Windows desktop PC running either Lync or Skype for Business clients.

  • Enter the appropriate user credentials when prompted. 

image

For most Office 365 users account the the User name will be identical to the Sign-In address.  In hybrid environments with Directory Synchronization in place then it’s possible that the User name will be in different string, but the format must be entered as a User Principal Name (UPN) and the legacy DOMAIN\username format cannot be used with online account.

Management

Only in-band provisioning information is leveraged by Lync Phone Edition devices, no differently than when registered to an on-premises server deployment.  Devices registered to online accounts do not leverage all of the same parameters which are available with traditional on-premises server deployments, but this list is growing over time.  Skype for Business MVP Adam Jacobs has an article which calls the supported commands today.

VVX Phones

These devices include all of the previously and currently available VVX Business Media Phones which run Polycom’s Unified Communications Software (UCS).

image

As of the end of 2015 Polycom has started a hardware refresh on these models which includes newer faster processing internals.  These newer modes are denoted by ending in a ‘1’ instead of the previous models ending with a ‘0’.  So while a brand new VVX 501 may have updated internals over the older VVX 500 the software capabilities today are the same.  Any and all of these models support the same firmware, thus the same software features and capabilities with Skype for Business.

Prerequisites

As with the CX phones the only requirement is that the minimum supported firmware version is installed on the device.  The following version, or newer, must be installed onto the phone prior to attempting to register it to Skype for Business Online. 

Polycom UC Software 5.4.0A

Version: 5.4.0.10182
Released: 9/25/2015
Download: Latest Polycom UC Software Release

As of the publishing of this article there are newer firmware releases for the VVX phone which still support Skype for Business Online but have also added new functionality..  Reference this updated article for the latest recommended firmware version to be used with Skype for Business platforms.

Registration

The various ways to sign into a VVX phones as covered by many other article on this blog are all still applicable, with the exception of PIN Authentication as explained earlier.  For any of the user credential methods the same formatting guidance as what is mentioned above holds true.  The UPN format is required for online registration, thus the Domain field must be left blank.

Enable Lync Base Profile, if it is not already enabled.

  • This can be controlled directly on the phone from the Settings > Advanced > Administration Settings > Network Configuration > Base Profile menu. Or by using the web management UI at Simple Setup > Base Profile.

  • Use either the handset interface (pictured below) or Web Management UI (pictured below), or the Better Together over Ethernet (BToE) application (which looks the same as the CX process above).

  • Enter the appropriate user credentials.

image

image

Management

The VVX platforms supports a variety of in-band provisioning information like the the Lync Phone Edition devices in additional to a large amount of out-of-band options.  These other options can be managed by a variety of options today like basic a provisioning server or third-party applications like Event Zero’s UC Commander.

Trio 8800

The brand new RealPresence Trio 8800 is the only model in this family thus far and runs on the same UCS platform as the VVX phones.  This solution is the subject of a separate in-depth article which will be posted online shortly.

image

Prerequisites

Again the only requirement is that the minimum supported firmware version is installed on the device.  The following version, or newer, must be installed onto the phone prior to attempting to register it to Skype for Business Online. 

Polycom UC Software 5.4.1AA

Version: 5.4.1.17597
Released: 1/29/2015
Download: Latest Polycom UC Software Release for Trio

Registration

As the Trio uses the VVX platform then the registration capabilities are nearly identical.  While the BToE method is not currently supported with the Trio 8800 the other two options are the same.  The web interface looks identical is what was shown above and the user interface directly on the Trio looks like the following.

Enable Lync Base Profile, if it is not already enabled.

  • This can be controlled directly on the phone from the Settings > Advanced > Administration Settings > Network Configuration > Base Profile menu. Or by using the web management UI at Simple Setup > Base Profile.

  • Use either the handset interface (pictured below) or the Web Management UI also (which looks the same as the VVX process above).

  • Enter the appropriate user credentials.

image

Management

The Trio supports all the same management models as the VVX in addition to one new functionality, USB Provisioning. This concept is covered in detail in the new Trio article but basically it’s the ability to copy a provisioning server-like directory to a USB disk and the phone will treat it identical as to how it would read from a centralized network server.  This method allows for quick one-off changes to be applied to a few devices manually.

CX5500

This device is a bit unique as while it is categorized in the CX family it does not run Lync Phone Edition software.  Instead the 5500 model includes an embedded version of UCS just like that found on the VVX phones.

image

Prerequisites

Note that support for direct registration to Skype for Business Online is not yet available in the CX5500 product.  When the supported firmware is release then this article will be updated to reflect that.  That being said the device can be used with SfB Online users via USB tethering, just not yet using the embedded line registration capabilities of the VVX software.

Registration

As the Trio uses the VVX platform then the registration capabilities are nearly identical.  When connected via USB the desktop client’s own registration is used and this device simply acts as a microphone, speaker, and video camera.  The individual line registration over its Ethernet connection is still available.

Management

The CX5500 supports all the same management models as the VVX because it runs the VVX software.

Winter 2016 SkypeUG Meetings

January 26, 2016 by · 2 Comments 

The next round of quarterly Skype for Business Users Group meetings has been announced and scheduled starting this month.

newlogo_title

Latest News

As of last quarter’s events our group has made a few exciting changes.  First and foremost is the rebranding from the Lync Users Group to the Skype for Business Users Group. For discussing and sharing event information on social media keep an eye out for @SkypeUG and #SkypeUG.

This change also includes a brand new web site which will be used for all member registrations, for all locations, going forward.  The events will transition away from the individual Meetup.com pages over the next few quarters.  The new site gives us the ability to roll out new features and content for all event locations uniformly and will allow us to grow as additional cities are added over time.

Event Details

This quarter’s event will be conducted in our familiar two-session format:

The first session, presented by Polycom, will cover an array of available video and audio conferencing products as well as video interoperability solutions for Skype for Business.  A Microsoft Solutions Architect from Polycom will be on-hand to lead the discussion and address any technical questions from the group

The second session will provide an in-depth look at the new features and capabilities of the recently launched Cloud PBX solution in Skype for Business Online.  A local subject matter expert will be leading this presentation.

Industry Experts will be on-site to deliver these presentations and help answer any questions related to Skype for Business.  Food, beverages and additional door prizes will be provided courtesy of the Skype for Business Users Group and its official sponsors.

Western U.S.

Central U.S.

Southern U.S.

Eastern U.S.

 

For a full schedule of regional events the Skype for Business Users Group Meetups page lists all planned event locations with links to the associated registration page for each regional group.  For anyone who is not yet a member and would like to participate simply visit the site listed above and register for your local group, this will automatically create a new user account for you to use again for all future event registrations..


Chicago Event

As usual I will be hosting the Chicago event downtown.  Food will be ready at 5:30 so come early if you can to spend time socializing with the group before the presentations begin at 6:00.

Date Location Address
Thursday, January 21th
5:30PM – Food and Networking 
6:00 PM – Presentation Kickoff
Chicago Users Group Microsoft Technology Center 
200 East Randolph Drive, Suite 200 
Chicago, IL 60601

 

Additionally I am attending the following events this quarter to provide the sponsor presentations in-person:

  • Jan 26 – Cincinnati, OH
  • Jan 27 – Milwaukee, WI
  • Jan 28 – Kansas City, MO
  • Feb 04 – Boise, ID
  • Feb 10 – Portland, OR
  • Feb 11 – Seattle,WA
  • Feb 16 – Detroit, MI
  • Feb 18 – Charlotte, NC
  • Mar 02 – Atlanta, GA

The remaining events are being handled by regional experts including Dustin Hannifin, Randy Wintle, Adam Jacobs, Jose Mateo, and Paul Gurman.

Next Page »