Video Based Screen Sharing (VBSS) is a new Skype for Business client capability that has for the most part flown in under the radar. There is currently very little information available about this new functionality, and as with anything not well understood it seems to be creating more confusion than warranted. Most of the questions have been centered around the topic of video interoperability, thanks in part to some generalized statements.
This article will explain what this new functionality is, as well as what it is not. With a more complete understanding of VBSS and its potential roadmap then the answers to various interoperability questions should be quite clear.
The Office 365 Roadmap currently lists this feature under the In Development section, but it is now available with the release of the Skype for Business 2016 client that is included in Office 2016.
Up until now there have been only a few places that this new feature has been discussed in the public realm, and most of that was before there was even a name for it. Generically speaking it was communicated as some level of native support for “H.264 content sharing” coming to the Skype for Business platform. Obviously companies looking to address interoperability scenarios with SfB and their standards-based video conferencing systems would sit up and take notice to these claims.
Unfortunately the problem with that simple statement is it can be interpreted differently depending on whom is reading it. For those with a foundational understanding in the traditional video conferencing world that statement can sound odd. The H.264 standard is simply a video codec which could include anything in the actual image. The transmitted pixels could be arranged to display a smiling face captured by a camera, or instead show the familiar view of a user’s PowerPoint application captured by a video output device of some sort. While a standard H.323 or SIP call can support sending a second stream of video displaying this content the actual standard that makes this possible are not H264 itself.
A call established using the H.323 call control platform will actually use the H.239 standard for establishing content sharing, where as a call that instead leverages a standard video SIP platform will use Binary Floor Control Protocol (BFCP) for establishing content. In the Microsoft world content sharing has leveraged Remote Desktop Protocol (RDP) since this ability was first provided in Office Communications Server 2005.
The most significant difference between these two workflows are the lines of communications that are established, and how they are established, even though the resulting experiences are very similar. For example:
- On one side a Skype for Business call will use Microsoft’s SIP platform to setup and negotiate a call or conference, leverage X-H264UC as the codec for the video streams, maybe opt for SILK as the audio codec, and then utilize RDP to share the desktop from one participant. Each of each lines of communications are separately established connections between the same endpoints, with their own streams and bandwidth utilization.
- In comparison the same scenario in the video conferencing world might utilize H.323 to establish the call signaling, H.264 AVC as the video codec, G.722 as the audio codec, and then leverage H.239 to send the desktop screen of a computer in a conference room connected to a VGA cable.
The delivery mechanisms for sharing content in these two worlds are very different though. While the traditional video conferencing systems use H.239 or BFCP to control the transport of the content, the actual content itself is encoded using a video codec and is sent within the same allowed bandwidth defined for the specific call. The content essentially steals bandwidth away from the main video when needed. Normally the content is encoded as an H.264 AVC video stream, but could in some cases fall back to a legacy H.263 stream.
Yet on the Lync/SfB side an additional session is created for content outside of any established video or audio sessions (if they even exist) and will transmit RDP as media over TCP, consuming additional bandwidth on top of whatever the audio and video sessions are already using. A content sharing session can be established all by itself in the Lync/SfB world, but with traditional video conferencing a video call must first be placed and then content can be added to that existing call.
These inherent differences in content encoding and transport are why traditional video content sharing has always been able to provide smoother motion, include audio in the stream, and use less overall bandwidth. Comparatively content sharing in Lync/SfB has been of much sharper quality and resolution but severely limited in frame rate and typically more costly on the network.
In an initial step to improve the content streaming quality of RDP the July 2013 cumulative update for Lync Server 2013 introduced a new parameter (EnableHighPerformanceP2PAppSharing) for peer to peer application sharing. This optional setting still utilized RDP for the data stream but boosted the frame rate a bit (as well as the bandwidth usage). A side-by-side comparison of the default and high performance RDP options can be seen in this blog article by Skype for Business MVP Michael LaMontagne. While the frame rate was slightly improved it was still very short of the frame rate needed to display video or other moving animations sufficiently.
Seeing that RDP has been stretched to its limits in terms of providing quality streaming another approach was taken with the Skype for Business client. The addition of Video Based Screen Sharing helps address some of these limitations while at the same time not negatively impacting the overall image quality that RDP has provided to date.
The primary change here is that Skype For Business clients can now utilize something other than RDP to share content between clients. Understand that currently this capability is only provided in the Office 2016 version of the Skype for Business 2016 client, starting with the public release of the 16.x client version (e.g. 16.0.4266.1003). The rebranded Lync 2013/Skype for Business 2015 15.x client installations do not include this capability and will continue to share content using RDP.
VBSS is also only available in peer-to-peer SfB sharing sessions and is only utilized on the Present Desktop sharing option. Selecting any of the other sharing options like Present Program or Present PowerPoint Files will still behave the same as in previous clients. The PowerPoint File sharing option leverages the Office Web Apps Server which does not actually stream the content and thus VBSS is not applicable here. The Present Program option does not currently take advantage of VBSS so RDP at a low frame rate is still used.
The Application Sharing service on the SfB Front End Server does not support this feature so content shared into Skype for Business meetings will also continue to use RDP regardless of the individual client versions.
Additionally in the single use-case where VBSS can be used the content sharing is provided as view-only. If remote control is requested by or given to the receiver then the content stream will seamlessly fall back to using RDP. This switch is invisible to the user except that the frame rate of the content will immediately drop as VBSS is replaced with RDP for delivery of the content. Releasing control will not upscale the content back to using VBSS, it will remain as RDP for the duration of the sharing session. Stopping and restarting the sharing session will allow VBSS to be used again.
Just as the addition of X-H264UC as the primary video codec in Lync 2013 did not magically remove all video interoperability hurdles with Lync, using this same codec for content streaming is no different. As stated previously this is not standards-based H.264 content sharing, just like video in Lync/SfB is not the same as H.264 AVC payloads.
In the field most video interoperability solutions available today are focused on conferences, not individual peer to peer calls. Simply stated, VBSS is no different than the addition of SILK to some of the Lync and SfB clients. These clients can choose to utilize the newer codec when negotiating peer calls between each other, but when involved in larger multiparty conferences are still limited to the codecs supported by the server.
That is not to say is there are no inherent benefits here. Clearly any improvements built on top of this workflow could be leveraged by additional development by third parties. For example video conferencing systems which already include native support for RDP content sharing could in theory be updated to support VBSS to further improve quality.
The following video clips were recorded with a camera showing the actual display of a Windows workstation receiving the same shared content in two separate tests.
- In the first video the typical RDP experience is shown which is clearly evident by the very low frame rate.
- The second video shows the same YouTube video being streamed from the same SfB user but this time VBSS is used and the frame rate improvement is obvious.
These embedded videos may be muted by default but if the playback audio is heard understand that the camera used to capture these clips has picked up the sound from the source (sharing) PC’s speakers located in the same room. The content sharing in SfB is still limited to video only and does not deliver any audio from the sharing client to the receiving client. To perform the same side-by-side tests simply switch between using Present Desktop (which uses VBSS) and Present Program (which uses RDP).
Using some basic math and monitoring tools the following behavior was observed when sharing a full motion video at full screen for an elapsed time of 4 minutes.
- The RDP session averaged 2.83 Mbps with 85MB of data transmitted
- The VBSS session averaged 3.5 Mbps with 105MB of data transmitted
Based on these numbers VBSS consumed roughly 25% more bandwidth than when RDP was used, yet increased the frame rate by much more than that percentage. The RDP session displayed about 3 frames per second at best while VBSS could provide 7.5, 15, or 30fps streams based on X-H264UC specifications. Note that only a single Temporal Layer is transmitted as this is a P2P session and multiple frame rates would not be applicable.
Under the Hood
When selecting the Present Desktop option in the Skype for Business 2016 client a SIP invitation message will be sent to the other party including the following Session Description Protocol (SDP) messaging.
- The initial SDP data will look no different than what was seen in the past. This is because the first portion of the SDP messaging always includes the legacy ICE v6 declaration for communicating with Office Communicator 2007 and older clients, as denoted by the ms-proxy-2007fallback string, Clearly these old clients cannot support VBSS so there is no need to advertise any new capabilities here. Only a single media session (m=application) is declared here and the media type advertised is RDP (a=rtpmap:127).
Content-Disposition: session; handling=optional; ms-proxy-2007fallback
o=- 0 0 IN IP4 126.96.36.199
c=IN IP4 188.8.131.52
m=applicationsharing 58323 TCP/RTP/AVP 127
<candidate and crypto data snipped>
- The next grouping of SDP data is what will be used if the receiving client is running at least Office Communicator 2007 R2 or newer. Note that the Content-Disposition parameter no longer includes the fallback string; this section leverages ICE v19. The differences highlighted below outline how this new capability is advertised.
Content-Disposition: session; handling=optional
o=- 0 1 IN IP4 184.108.40.206
c=IN IP4 220.127.116.11
m=applicationsharing 58323 TCP/RTP/AVP 127
<candidate and crypto data snipped>
m=video 58167 RTP/AVP 122 123
c=IN IP4 18.104.22.168
a=rtcp-fb:* x-message app send:src,x-pli recv:src,x-pli
<candidate and crypto data snipped>
First, a new session level attribute a=x-mediabw is included under the m=application section. This is what the SfB 2016 clients can use to identify and use VBSS for the sharing session between them. If both parties do not support this new capability then it will not be used and RDP will be leveraged instead just as it has been.
Secondly, an additional media session is advertised to negotiate a video stream under the familiar m=video string, including two new attributes: a=label:applicationsharing-video and a=x-mediasettings. Note that the media payload type here is the same X-H264UC (a=rtpmap:122) that has been used for video since the release of Lync 2013. For added measure the out-of-band Forward Error Correction (a=rtpmap:123) codec used with SVC video is also included.
While not visible above because the candidate details were clipped for easier reading the RDP session only advertises TCP candidates while the VBSS session will advertise a full set of UDP (preferred) and TCP (fallback) candidates. The fact that content sharing with VBSS can now utilize the stateless UDP communication protocol is already an advantage in improving streaming. Also not represented is the communication between clients within the RTCP channel for Video Source Requests (VSR) in which the two clients negotiate resolution, frame rate, and other parameters of the video channel in-session.
As both the RDP and VBSS capabilities are advertised in the messages above then the clients will negotiate both sessions even though the content will actually flow through the VBSS session. In the event that RDP needs to be used (e.g. for remote control) then the clients can quickly switch to using RDP as a legacy fallback option.
Because all of this new functionality is embedded directly into the clients then the underlying infrastructure does not seem to be relevant to its functionality. As long as both parties have the Skype for Business 2016 client then it will be leveraged even if one or both of them are homed on a Lync Server, or even on different servers via federation. In fact the example SIP data shown above was captured from a peer call between a 2016 client registered to Skype for Business Online and a federated contact registered to a separate Lync 2013 on-premises environment.
The latest release of the Polycom VVX 5.4 UCS firmware branch is now available for Lync and Skype for Business environments. While the initial 5.4.0 release (22.214.171.12441) was published a few months ago that was only intended for Open SIP applications. The recent 5.4.0A release (126.96.36.19982) is fully supported for Lync and Skype for Business (SfB) 2015 Server environments.
Additionally this release introduces the capability to register directly to Skype for Business Online and Exchange Online as provided by Microsoft’s Office 365 cloud environment. This sets the stage for the planned launch of the voice features later this year. As official support for voice and IP phones with Skype for Business Online is coming later this year then the registration outlined in this article is at this moment unsupported, but is functional. For any hybrid environments with an on-premises Lync or Skype for Business deployment paired with Exchange Online this version also resolves connectivity issues previously seen in 5.3 with Exchange Online.
As covered in various other articles this process is unchanged. The same steps listed at the beginning of this recent article can be used to upgrade the phone firmware if not already familiar with it.
The new firmware is now available directly from the public Polycom Hosted upgrade server, and it identified as “SFB-Lync Only” so that customer using VVX phones on Open SIP platforms do not use this specific release.
As usual the entire release package can also be downloaded from this page and then loaded on to a custom provisioning or distribution server.
- Before advancing verify that the phone is upgraded to the proper firmware version by pressing the Home button and then then selecting Settings > 4 > 1 > 2 > 1 to quickly navigate to the Status > Platform > Phone > Main menu.
Office 365 Registration
Registering the phone to an existing on-premises or third-party hosted environment is performed the same as in previous releases. Given that registration to Office 365 is a new feature for leveraging Skype for Business Online and Exchange Online then this article will walk through these steps below.
Note that some of the steps shown here are new, which are a result of improving the first-time sign in process for users. These improvements are seen when registering to any Lync or Skype for Business environment, on-premises or hosted.
Select Base Profile
The VVX phone in use may already have this step configured by default, depending on the specific SKU that was used to purchase the phone. Regardless of the part number and what was pre-staged at the factory any VVX phone can be moved between the Generic and Lync Base Profiles.
- Depress and hold the 1, 4, and 9 keys on the phone’s keypad and keep them held for for at least 3 seconds.
- When prompted enter the Administrator password (factory default is 456).
- Select Lync if it is not already the default configuration. If the phone was previously set to Generic then it will automatically reboot when Lync is selected.
Any of the methods detailed in the recent article Lync Registration on VVX Phones can be used. The only difference for O365 registration would be the format the user credentials are entered in. As SfB Online does not utilize legacy Windows NetBIOS formats then only the User Principal Name format can be used.
A touch-enabled VVX 600 model is used for the examples shown in this article, but the steps are identical between all VVX models. For non touch-screen models entering the user credentials using the keypad could be a slow process and thus utilizing BToE or the Web Management UI are faster, easier methods of registering the phone.
The example below will show the process as performed directly on the phone itself.
- Select the Sign In soft key displayed on the home screen of the phone.
Another improvement in the sign-in process with this release is that in the event the phone does not discover any Lync/SfB certificate provisioning services URL from either the network (DHCP Option 43) or a dedicated provisioning server (STSURI) then PIN Authentication support will be automatically disabled on the phone. For Office 365 tenants or users of other hosted Lync/SfB environments where that authentication option is not currently supported this will simplify the sign-in process by defaulting directly to the User Credentials option.
- Using the on-screen keyboard enter the desired Office 365 user credentials as shown in the following screenshot. Only the Sign-In Address, User, and Password fields should be populated. The Domain field should be left blank.
- Select Sign-In and wait for the phone to complete registration.
- Once sign-in is reported as successful press the Next key to move on and pick a time zone, or press Done to skip right to the home screen.
If Next was selected in the previous step then the Time Zone menu will have appeared.
- Select the desired time zone and then either select Next or Done.
If Next was selected then additional menus will provide the ability to change the default Time Format from 12-hour to 24-hour, and then configure the desired Date and Time Format.
If Done was previously selected then the wizard will complete and the phone will display the home screen and along with it any currently pinned Favorites in Lync or SfB, just as it always has.
- To validate a successful connection to Exchange Online press the Home key and then select the Calendar icon. Any scheduled meetings should be displayed as shown.
When using either of the other documented registration processes the same requirements apply in terms of how to populate the user credentials.
- If using the Lync SignIn feature available the phone’s web management UI then the credentials are entered in the same as as shown in the steps above, omitting the Domain field.
- If using Better Together over Ethernet (BToE) pairing the Lync/SfB client prompt for sign-in credentials should be populated as shown below. (There is no separate Domain field to skip in this format.)
While this new wizard which mimics the behavior of Lync Phone Edition can be beneficial to unmanaged phones meant for hosted Skype for Business tenants current customers may already be handling time zone settings via DHCP or a provisioning server configuration. In these scenarios it would be ideal to disable this setup wizard to streamline the user sign-in process even further.
- To disable the user setup wizard simply configure the following three attributes on the phones using a supported provisioning server model.
This edition in a series of deployment articles for Skype for Business Server 2015 addresses the integration of an existing Exchange Server 2013 installation with a recently installed Skype for Business Standard Edition server. The article outlines establishing the prerequisite partnership between each platform, allowing the Skype for Business server to leverage the Exchange Server database engine for storage of some types of data
Further configuration of additional features provided by this integration will be covered in later articles, as in Unified Contact Store, Exchange Unified Messaging, and Outlook Web App with Skype for Business Server 2015. For each of these additional integrations the following Partner Application relationship must first be enabled in the environment. An updated listing of only the articles specific to Exchange Server integration with Skype for Business Server 2015 can be found using this link
The sections in this article are outlined in the following configuration steps:
In the event that Exchange Autodiscover is not correctly configured this could prevent the Skype for Business server and clients from being able to locate the Exchange server and thus cripple the ability to complete this integration. The steps in this first section are optional and may not be required in all environments, so long as Autodiscover is correctly deployed.
In event that the existing autodiscover URL will be used then skip to the next section to configure OAuth.
- Using the Exchange Server Management Console run the following Get-ClientAccessServer cmdlet to view the current Autodiscover configuration. The Identity parameter cab be either the Exchange server’s hostname or the Fully Qualified Domain Name (FQDN).
Get-ClientAccessServer -Identity EXCH | Select-Object AutoD*
In this example environment the default configuration is still applied whereas the server name is utilized in the internal autodiscover URL. This will be updated to use the well-known autodiscover record format which is generally an Exchange Server deployment best practice.
Most likely when the Exchange Server was originally deployed the Autodiscover option was selected which would have included the proper FQDN in the certificate request. To validate this the following commands can be used to identify and parse the server certificate currently assigned to Exchange Server roles.
- Using the Exchange Server Management Console run the following Get-ExchangeCertificate.
Get-ExchangeCertificate | Select-Object Subject,Services,CertificateDomains | fl
As seen in the example above the desired certificate should be the entry with a FQDN in the Subject which is also assigned to at least the IIS service. This example snows that the Subject Alternative Name (SAN) field of the certificate in use by IIS already includes the desired FQDN of autodiscover.jdskype.net.
Create DNS Records
If the following two DNS records do not already exist in the environment then they need to be created before modifying the Exchange configuration. These are the two well-known DNS records that mostly autodiscover-aware clients will query when attempting to locate an Exchange Server.
- Create a new Alias (CNAME) record in the proper SMTP/SIP namespace forward lookup zone, pointing to the Exchange Server FQDN.
- Create a new Service Location (SRV) record using the following parameters, pointing this record to the CNAME record created in the previous step.
To validate the records were created successfully and are functional run the following two test commands from a command shell.
nslookup -q=srv _autodiscover._tcp.jdskype.net
_autodiscover._tcp.jdskype.net SRV service location:
priority = 0
weight = 0
port = 443
svr hostname = autodiscover.jdskype.net
Update Autodiscover URL
- Using the Exchange Server Management Console run the following set-ClientAccessServer cmdlet to update the configuration to use the new FQDN. The Identity parameter should be the Exchange server FQDN, while the new Autodiscover FQDN replaces the server FQDN in the internal URL.
Set-ClientAccessServer -Identity EXCH -AutoDiscoverServiceInternalUri "https://autodiscover.jdskype.net/autodiscover/autodiscover.xml"
- When the process completes perform a reset of Internet Information Server to immediately apply the change using the following iisreset shell command. (If performing this in a production environment with active connections then it is recommended to use the /noforce switch.)
Internet services successfully stopped
Internet services successfully restarted
The Partner Application pairing provides the ability for the Skype for Business and Exchange servers to communicate with each other via an authenticated secure connection that does not require any third party system to negotiate or establish the session.
OAuth is the server-to-server authentication mechanism used between the Skype for Business and Exchange servers to establish secure communications. During the initial SfB server deployment in this article an SSL certificate was created specifically for OAuth.
Before defining Exchange Server as a partner application Skype for Business needs to know about the Exchange Autodiscover configuration.
- Using the Exchange Server Management Console run the following Get-ClientAccessServer cmdlet to query the existing internal autodiscover URL. This is either the existing or newly defined value, depending on whether the previous section was skipped or not.
Get-ClientAccessServer -Identity EXCH | Select-Object AutoDiscoverServiceI*
Pay special attention to the fact that the retrieved autodiscover URL points to an .xml file; this will be important in a few steps.
- On the SfB server open the Skype for Business Server Management Shell and enter the following Get-CsOAuthConfiguration cmdlet.
The ExchangeAutodiscoverUrl parameter should be blank as it has not yet been defined.
- Enter the following Set-CsOAuthConfiguration cmdlet to define the Exchange autodiscover location as shown below.
Set-CsOAuthConfiguration -Identity global -ExchangeAutodiscoverUrl https://autodiscover.jdskype.net/autodiscover/autodiscover.svc
In contrast to what was pointed out earlier the path provided above must end with .svc and not .xml. This is a minor detail not specifically called out in the TechNet documentation but can easily be missed, especially if cutting and pasting these strings between steps.
- Run the Get-CsOAuthConfiguration cmdlet again to verify the new parameter value is applied as intended.
Configure Exchange Server
Enabling the partner application relationship requires that some configuration is performed on both side. Starting with the Exchange Server configuration pre-packaged script will be called while passing a few parameters. Before executing the script
- Identify the proper path for the Skype for Business server authentication metadata document. This URL should be identical to the following format, utilizing the SfB Front End server FQDN.
- Connect to this URL in a web browser from the Exchange Server to validate connectivity which should result in a prompt to open or save a file simply named ‘1’.
- Open the file using Notepad to view the contents, which should start with a x509 certificate string and end with the OAuth realm.
- Open the Exchange Server Management Console on the Exchange Server and change to the Scripts directory by using the following command.
cd c:\’Program Files’\Microsoft\’Exchange Server’\V15\Scripts
- Then execute the Configure-EnterprisePartnerApplication.ps1 script using the following command.
.\Configure-EnterprisePartnerApplication.ps1 -AuthMetaDataUrl ‘https://fe.jdskype.net/metadata/json/1′ -ApplicationType Lync"
- To complete the changes restart Internet Information Services using the iisreset command.
Configure Skype for Business Server
To complete the pairing a new partner application will also need to be defined on the Skype for Business side.
- Identify the proper path for the Exchange server authentication metadata document. This URL should be identical to the following format, utilizing the SfB Front End server FQDN.
- Connect to this URL in a web browser from the Skype for Business Server to validate connectivity, which should look similar to the results the previous section.
- Using the Skype for Server Business Management Shell enter the following New-CsPartnerApplication cmdlet to define the other half of the association.
New-CsPartnerApplication -Identity Exchange -ApplicationTrustLevel Full -MetadataUrl "https://autodiscover.jdskype.net/autodiscover/metadata/json/1"
To validate that the partner application relationship has been successfully established a simple cmdlet can be run from the SfB Server.
- Enter the following Test-CsExStorageConnectivity cmdlet, providing the SIP address of a user account which has already been enabled for Skype for Business. (The -Verbose parameter is optional and is used here to display additional information about the test process.)
Test-CsExStorageConnectivity -SipUri "sip:email@example.com" -Verbose
If the test cmdlet fails to return a successful result of “Test Passed” then here are a couple of the most common issues.
- In the event that the Skype for Business OAuth configuration was previously defined with an incorrect ExchangeAutodiscoverUrl parameter, as could happen by accidentally using .xml instead .svc for example, then the following error may occur. In fact if this parameter is null or invalid in any way then this error can occur.
Test-CsExStorageConnectivity : ExCreateItem exchange operation failed, code=50043,
To resolve the above error define the proper ExchangeAutodiscoverUrl in Skype for Business server using the Set-CsOAuthConfiguration cmdlet as outlined earlier in this article.
- If the AD user account which is used to execute the test cmdlet does not have the correct permissions then the process will fail with the following error being reported.
Test-CsExStorageConnectivity : ExCreateItem exchange operation failed, code=5,
To resolve this issue follow the directions outlined in this TechNet article to add the account to the RTCUniversalUserAdmins universal security group.
Now that Exchange Server has been successfully integrated with Skype for Business Server then additional features can now be deployed. An updated list of articles covering other Exchange Server integration options can be found here.
One of the major differences in deploying a Standard Edition server in Skype for Business as opposed to an Enterprise Edition server is that the Standard Edition Front End server utilizes SQL Express instead of a full SQL Server installation. This means that by default there is no simple way to view or manage the SQL Express databases out of the box. Luckily it is relatively simple to install the missing SQL management tools directly on the Standard Edition Front End server.
This article shows how to install SQL management tools on a Standard Edition Skype for Business Server. Take note that this is unsupported and not typically performed in Skype for Business deployments. Usage of this tool throughout this and any future article is strictly for educational purposes.
In an Enterprise Edition server deployment a separate backend SQL Server is utilized which already includes these management tools. Also understand that in many environments the SQL servers are already deployed and managed by separate resources and so the Skype for Business administrators may not even have that level of database access to the SQL servers.
In a Standard Edition model though the SQL databases are all stored locally on the Front End server and thus a time may come when the databases stored on the local SQL Express instances may need to be viewed, queried or even modified directly (recommended only by experts or under the guidance of Microsoft support in specific cases). But for test environments or when attempting to simply learn more about the Skye for Business platform based on a Standard Edition server deployment there is no way by default to get access to the SQL databases.
The trickiest part is finding the correct software package to download as there are multiple different versions of SQL Server and SQL Server Express for both the servers and management tools.
- On the Front End server the Programs and Features control panel can be used to confirm the currently installed version of SQL Server (Express), which should be 2014.
- Go to the Microsoft SQL Server 2014 Express download page t and then select the Download button.
- Select MgmtStudio 64BIT\SQLManagementStudio_x64_ENU.exe from the list of available packages to choose from.
- Once the package has completed downloading expand the contents and then run Setup.exe to start the installation wizard.
- From the main Installation menu select the option for New SQL Server stand-alone or add features to an existing installation.
- On the Installation Type page select Add features to an existing instance of SQL Server 2014. The default selection of an existing instance is sufficient as the management studio only needs to be installed for once instance to be made available to connect to any on the server. The RTC instance was left as the choice in this example.
- On the Feature Selection page click Management Tools – Complete.
- Complete the installation wizard and close it when the requested features are finished installing.
The first time this new application is launched it can be configured to connect to multiple database instances.
- Search Windows for “SQL Server Management Studio” to find the newly installed application.
- Launch the application and the local SQL Server instances should be displayed in the Server Name drop-down menu. Select Connect to open up the LYNCLOCAL database instance
Once open the Object Explorer tree will show the instance and databases as a child item. The Connect button can be used to add the other SQL instances to the explorer view, as shown below. This is the complete list of default databases which are installed on a Standard Edition Skype for Business 2015 Front End server (the other objects have been edited out for easier reading).
As seen above there are three different SQL instances which were created during the initial server deployment. The first and most important is the RTC instance which stores the primary databases in Skype for Business Server. The xds database is the most critical as it stores the Topology data defines the entire environment. Other key database are stored here like the Address Book database (rtcab), conferencing information (rtcshared), or services like location information (lis). In an Enterprise Edition pool deployment this instance and its databases would be stored only on the backend SQL database servers, not locally on the Front End server.
The RTCLOCAL instance stores local copies of the critical xds, rtc, and rtcdyn databases. In an Enterprise Edition pool deployment these are the only databases which would be stored locally on the Front End server. Yet as the Standard Edition pool model does not use separate SQL servers then all databases and instances are hosted locally.
Finally the LYNCLOCAL instance holds only the Lync Storage Service (lyss) database which is a storage engine used for a variety of tasks.
As additional roles and features are deployed their associated databases will be created and synchronized between one or more of these various instances. During deployment of those features this topic will be revisited to validate where those individual databases are stored.
This article addresses the deployment of a single Office Web Apps 2013 Server and subsequent integration with an existing Skype for Business (SfB) Server 2015 environment. The environment and example steps outlined here are a continuation of a series of related articles covering the installation and configuration of a Standard Edition topology of Skype for Business Server 2015.
When testing various Skype for Business meeting modalities in the last article a specific feature was briefly mentioned which was not yet available: the ability to use the Present PowerPoint Files option from the Present menu. This is because the deployed environment does not yet include an Office Web Apps Server which is required to support that functionality. This server is not a SfB role but is actually part of the Office server family and is leveraged by Skype for Business as well as other Microsoft server products like Exchange and SharePoint.
It is important to be aware that once deployed this feature may still not function on any Skype for Business clients on workstations which are not joined to the same domain as the SfB deployment. In these scenarios either server certificate revocation checking needs to be disabled on the workstations or the RootCA certificate configuration needs to be modified. These concepts are addressed in this TechNet article. (For this environment the later RootCA approach has already been addressed in the prerequisite statements defined in the first deployment article of the series.)
Note that the Office Web Apps (OWA) Server is also sometimes referred to as the “WAC Server” which is a carryover from the product’s pre-release name of Web App Companion Server. Also be aware that this server role is completely separate from the Exchange Server web application entitled Outlook Web App which provides a browser-embedded client experience for access to Exchange email similar to the Outlook desktop client.
In the example Skype for Business environment this PowerPoint sharing functionality has not yet been introduced. The steps in this first section show how to confirm that the feature is not yet available.
- On the Skype for Business Front End server open the Skype for Business Server 2015 Topology Builder and select Download Topology from existing deployment.
- Expand the default site (e.g. Lab), the Skype for Business Sever 2015 object, then Standard Edition Front End Servers, and finally highlight the pool FQDN (e.g. fe.jdskype.net).
- Scroll the right-hand window down to the Associations section to see that the Office Web Apps Server value should not yet be configured.
Test Missing Feature
- Sign into a Skype for Business client and start a meeting using the Meet Now menu item.
- From the Present button select the Present PowerPoint Files menu option. Select an existing PowerPoint file on the computer or network to share with the meeting.
- While the client will appear to attempt uploading the selected file the process should actually fail after a few seconds with the following error.
- On the SfB Front End server open the Event Viewer and browse to Applications and Services Logs > Lync Server.
- Search for the following log entry recorded with Error ID 41033.
Log Name: Lync Server
Source: LS Data MCU
Event ID: 41033
Office Web Apps Server (WAC) discovery failed, PowerPoint content is disabled.
Attempted Office Web Apps Server discovery Url:
Received error message: Invalid Uri syntax for WAC configuration
The number of retries: 1, since 8/27/2015 4:44:40 PM.
Cause: Office Web Apps Server may be unavailable or network connectivity may have been compromised.
Check HTTPS connectivity from this box to the Office Web Apps Server deployment using the discovery Url.
At this point it is evident that the environment is missing the required server role and configuration in order to support this feature. The remainder of this article details the installation and integration steps required to add the desired functionality.
The remaining sections in this article are outlined in this diagram to show the general order of steps and visually represent which steps are performed on which platform. For example orange indicates configuration steps completed on the OWA server where the blue is for steps performed on the SfB server.
As the Office Web Apps Server can not be collocated on any of the existing servers in the environment like a Domain Controller, Exchange Server, or Skype for Business Server then a separate, dedicated server needs to be deployed to host this role.
A new Windows Server 2012 R2 virtual machine was deployed and joined to the existing jdskype.net domain. Alternatively both Windows Server 2008 R2 and 2012 are also supported server operating systems for this role if desired. (The following steps are for Server 2012 R2, if a different server version is used then check this TechNet article for a list of different required components.)
- Run Windows Update on the new server and apply any pending or recommended update packages prior to installing any Office Web Apps Server components.
- Download the latest Office Web Apps Server installation media. For MSDN subscribers as of the publishing of this article the most recent version is the Office Web Apps Server 2013 with Service Pack 1 (x64) ISO package.
Windows Server 2012 R2 will require that the .NET Framework version is upgraded to at least 4.5.2. This can be accomplished in one of two ways:
- The simplest method is to launch Windows Update on the server and then review the Optional updates. If available, select the Microsoft .NET Framework 4.5.2 for Windows…(KB293450) package and then click Install. Restart the server when the update is complete.
- Alternatively if this package is not listed in Windows Update then download and install the NDP452-KB2901954-Web.exe hotfix from Microsoft Download Center. Restart the server when the update is complete.
- Launch PowerShell as an administrator and enter the following command string to install all required Windows Features and then restart the server when completed.
- Mount the Office Web Apps Server 2013 installation media and run setup.exe.
- Either retain the default file location of C:\Program Files\Microsoft Office Web Apps or change the path to the desired application volume, and then select Install Now.
If the installation is successful then the follow message should appear.
As outlined in this TechNet article Office Web Apps Server cannot be upgraded without losing some of its configuration data. Thus us is recommended to disable any automatic updates on this server and configure them to require manual approval. If a future Office Web Apps update is automatically installed via Windows Update it will most likely result in a broken server and PowerPoint presentations will no longer function for any SfB clients in the environment.
For this reason it is recommended to apply any newer Office Web Apps Server updates prior to the initial configuration. When applying future updates to a functional, configured server make sure to follow the guidance in the TechNet article referenced in the previous paragraph which explains how to remove and recreate the server farm each time and update is applied.
The following historical table lists the more recent public updates for Office Web Apps. As these are service packs and cumulative updates then only the most recent update needs to be applied. (A complete list of updates including minor hotfixes and security patches see this blog article.)
|Date||Package||Version||Download Package||KB Article|
If for some reason the Office Web Apps server was installed with the RTM installation media then the SP1 update must be applied before installing the latest update. As the SP1 media was used for the server installation then only the most recent July 2015 cumulative update needs to be installed on the server.
- Download and install the latest Update for Microsoft Office Web Apps Server 2013. Restart the server when the installation is complete.
Install Language Packs
This step is optional and is only applicable if additional language support has also been configured on the Skype for Business Server. If so then this package adds support for other languages to shared PowerPoint presentations.
- Download and install the latest Language Packs for Microsoft Office Web Apps Server.
While the previous steps where basically just collecting and installing downloaded software this section will cover the configuration of the Office Web Apps Server. Once this is completed the next section will address configuration on the Skype for Business side to complete the integration.
Note that this article deals with an internal-only lab environment and thus any External configuration is not covered. In a potential future article when a Skype for Business Edge Server is introduced and thus a reverse proxy solution is needed then this configuration will be revisited to provide for external access. As this server handles only HTTPS (TCP 443) requests then it is not a role that is handled by the Edge Server, but must be published through a supported reverse proxy model in the same way that the SfB Front End server web services will be.
Before creating the new Office Web Apps farm a new server certificate will need to be requested and issued to the server to support HTTPS connections required by the Skype for Business clients and servers. For environments with an AD-integrated Certificate Authority (CA) this process can easily be performed from the domain-joined OWA server using the steps shown below. In environments leveraging a third-party CA for certificates then an offline request may need to be issued, which is covered in this older article.
- On the OWA Server launch Internet Information Services (IIS) Manager (inetmgr.exe) and in the Connections window pane highlight the server object.
- In the main window under the IIS section open the Server Certificates feature under the IIS section.
- From the Action pane select Create Domain Certificate which will launch a wizard to request, issue, and import a new server certificate all in one pass.
- Enter the server’s Fully Qualified Domain Name in the Common Name field (e.g. owa.jdskype.net).
- Populate the remaining fields with any applicable information and then click Next.
- On the Online Certification Authority window click Select to bring up a list of AD-integrated certificate authorities and then select the desired CA. In this environment a single Enterprise Root CA is available (e.g. jdskype-RootCA).
- Enter a Friendly Name for the new certificate (e.g. OWA Server Cert) and click Finish.
This previous step is critical as the next section will utilize the certificate’s Friendly Name name to assign it to a new Office Web Apps farm. Because Widows Server does not prevent multiple certificates on the same server from having the same friendly name this could cause problems with the OWA server configuration. Make sure that the Friendly Name entered above is unique from any other server certificates which might already be assigned to the server. Note that the Friendly Name field on a certificate is not actually part of the signed information and can be changed anytime, so there is no need to request a new certificate if this were to occur. Simply rename one of the conflicting certificates to resolve this.
Completing the previous step will process the request, immediately issue it to the online CA, and then import the returned, signed certificate into the local server. The new certificate should be listed under the Server Certificates panel as shown below.
Create New Server Farm
There is no user interface tool for managing the Office Web Apps server and thus all configuration is performed using the PowerShell cmdlets which were automatically added during the earlier server installation.
- On the OWA server open Windows PowerShell as an administrator and issue the following New-OfficeWebAppsFarm cmdlet. The InternalUrl parameter should use the server’s FQDN and the CertificateName value must match exactly to the Friendly Name given to the certificate created in the previous section.
New-OfficeWebAppsFarm -InternalUrl "https://owa.jdskype.net" -CertificateName "OWA Server Cert"
Note that by assigning a certificate during the creation of the server farm that unencrypted HTTP access is not allowed and only encrypted HTTPS access is supported. This is the correct setup for integration with Skype for Business Server.
- To validate the configuration and test access to the Office Web Apps Server open Internet Explorer locally on the OWA server and connect to the Internal URL with the suffix of /hosting/discovery as shown below. If successful then some XML code should be displayed in the browser.
- Repeat the same test from another server or workstation in the environment to validate network access to the same service.
- Collapse all of the XML tags to easily locate the PowerPoint app name. While this server includes support for other Office applications this is the section that Skype for Business Server will be leveraging for sharing presentation files.
Now that the Office Web Apps server appears to be functional then the final configuration step is to integrate it with Skype for Business Server 2015.
The configuration in SfB is as simple as telling the server where to find the newly deployed Office Web Apps server; there is no additional configuration required.
- On the Skype for Business Front End server open Topology Builder and select Download Topology from existing deployment.
- Expand the default site (e.g. Lab), the Skype for Business Sever 2015 object, then Standard Edition Front End Servers, and finally highlight the pool FQDN.
- Edit the pool properties and under the General section enable the Associate pool with an Office Web Apps Server parameter.
- Click New and then enter the Office Web Apps Server FQDN (e.g. owa.jdskype.net). Notice that the Office Web Apps Server discovery URL will automatically be populated with the the same value that was used to test the server previously.
If the OWA server is not deployed in an internally-routable network to the SfB Front End server then click the checkbox in this window. In this environment the servers are all located in the same LAN so it is left unchecked.
- Click OK to save the changes and then verify in the main window that the new entry is associated to the pool.
- From the Action menu select Topology > Publish to complete the changes and publish the new configuration to the Skype for Business environment.
- When the publishing process completes successfully then click Finish and then close Topology Builder.
Before testing the integration the SfB server log can be checked to make sure that the OWA server has been discovered and enabled in the environment.
- On the SfB Front End server open Event Viewer and browse to Applications and Services Logs > Lync Server.
- Filter the current log for the Event source of LS Data MCU to simplify locating the desired log entries on the server.
Looking at the most recent log entries the following two Information events should be logged shortly after publishing the changes to the SfB topology.
- First an entry for Event ID 41032 should be recorded indicating that the SfB Front End server has successfully discovered then OWA server.
Log Name: Lync Server
Source: LS Data MCU
Event ID: 41032
Web Conferencing Server Office Web Apps Server (WAC) discovery has succeeded
Office Web Apps Server internal presenter page: _https://owa.jdskype.net/m/Presenter.aspx?a=0&e=true&
Office Web Apps Server internal attendee page: _https://owa.jdskype.net/m/ParticipantFrame.aspx?a=0&e=true&
Office Web Apps Server external presenter page: _
Office Web Apps Server external attendee page: _
- Immediately following that should be an entry with Event ID 41034 which indicates that PowerPoint content sharing is now enabled.
Log Name: Lync Server
Source: LS Data MCU
Event ID: 41034
Web Conferencing Server has successfully discovered Office Web Apps Server, PowerPoint content is enabled
With the topology published the final step is to repeat the same test that was performed at the onset of this article.
- Sign into a Skype for Business client and start a meeting using the Meet Now menu item.
If this client was already signed-in during the deployment then make sure to sign out and back in to receive the latest SfB provisioning settings from the server which reflect the changes.
- From the Present button select the Present PowerPoint Files menu option. Select the same PowerPoint file that was tested earlier and failed.
- This time the shared PowerPoint file should be successfully uploaded and shared with all clients connected to the meeting.
This concludes the deployment of a single Office Web Apps Server into the environment. More Skype for Business 2015 Server deployment articles like this one can always be found in this updated list, which will include an upcoming article on Exchange Server integration.
Advancing from a previous post this article addresses setting up a few test users and configuring various client and server features. The overall functionality and health of the newly installed Skype for Business Server 2015 environment will be validated prior to moving forward with the deployment of any additional roles or configuring any partner applications.
Throughout this section a mixture of approaches will be used to create and configure a pair of test accounts. Examples of both GUI (Graphical User Interface) and CLI (Command Line Interface) approaches will be leveraged in an attempt to educate the reader on both options as well as serve as a quick reference for some simple, yet customized PowerShell cmdlets to perform routine tasks. For the sake of simplicity the personally preferred option can obviously be used for all steps.
Create User Accounts
- Using Active Directory Users & Computers create a new Active Directory user account (e.g. firstname.lastname@example.org). This first account can be used for the majority of validation steps through this series of articles.
- Utilizing Windows PowerShell create a second user account (e.g. email@example.com) for the purposes of testing various two-way communication tasks. Enter the desired name, account, location, and password fields in the following example cmdlet.
New-ADUser -Name "First Last" -GivenName "First" -Surname "Last" -DisplayName "First Last" -Path "OU=Users,OU=Lab,DC=jdskype,DC=net" -SamAccountName "first" -UserPrincipalName "firstname.lastname@example.org" -AccountPassword (ConvertTo-SecureString -AsPlainText "p@ssword1" -Force) -Enabled $true -ChangePasswordAtLogon $false -PasswordNeverExpires $true
Now that two new user accounts have been created in Active Directory some additional steps can be performed on each to configure them for Exchange and Skype for Business.
Enable Users for Exchange
This is an optional step and can be skipped if the environment does not include any Exchange servers. As integrating with Exchange Server 2013 provides a number of features for Skype for Business (Voice Mail, Unified Contacts Store, Archiving, etc.) then it is recommended to deploy Exchange .
- Connect to the Exchange Admin Center and then from the default Recipients > Mailboxes page select the “+” icon to create a new User Mailbox.
- Select Existing User and then click Browse. Highlight and select one of the two new users accounts and then click OK and Save.
By contrast the other account can be enabled with the same mailbox configuration using a simple Exchange Server cmdlet instead of the web management user interface.
- Using the Exchange Server Management Shell enter the following cmdlet with the appropriate username.
Enable-Mailbox -Identity "DOMAIN\username"
Enable Users for Skype for Business
As in the previous steps the first account will be enabled using the GUI process.
- Using the Skype for Business Server 2015 Control Panel navigate to the Users section and click Enable Users.
- Click the Add button and then either type in the name of the first user account or simply click Find to list all AD user accounts which have not yet been enabled for Skype for Business.
- Highlight the desired user account and click OK to return to the previous screen.
- Select the Skype for Business Front End server from the ‘Assign users to a pool menu. If Exchange mailboxes were created for these accounts then the default SIP URI option of Use user’s email address is sufficient. If there is no associated mailbox for the user accounts then instead select Use the user principal Name (UPN) option. (Either option in this environment will work as both the SMTP address and UPNs are identical.)
- Click Enable to complete the process and enable the account for Skype for Business.
Additional options will be enabled and configured later on as those associated components are configured on the servers (e.g. Enterprise Voice). The next step is to enable the other account using a command line.
- Using the Skype for Business Server 2015 Management Shell enter the following cmdlet with the desired user account name.
Enable-CsUser -Identity "DOMAIN\username" -SipAddressType EmailAddress
This completes the prerequisite setup for the two test accounts. If additional accounts are desired simply repeats these steps, using either method for each new account to be created.
Update Address Book
As these two accounts where just created then manually updating the Skype for Business Address Book data will make it possible to search for them in the client without waiting for the preprogrammed server interval of 24 hours. This process has remained relatively unchanged since Lync Server 2010.
- In the Skype for Business Server 2015 Management Shell execute the following Update-CsAddressBook cmdlet.
Using the verbose (-v) switch is optional but displays additional details explaining that this action is not immediate.
- To check on the status of the process open the Windows Event Viewer and then navigate to Applications and Services Logs > Lync Server. Refresh the log periodically until the following grouping of LS Address Book Server messages are recorded.
Test Client Connectivity
Starting with a single domain-connected workstation attempt to sign-in to a Skype for Business 2015 client with either user account that was created.
Notice that the client’s experience is very basic at the moment. There is no user photo, no Phone tab, and no Location data for example. The user’s photo could be provided by either Active Directory (low resolution) or in Exchange Server 2013 which will be addressed in a later article.
- To check the configuration information passed down to the client during registration hold the CRTL key while right-clicking the Skype for Business notification icon in the System Tray. This will reveal a hidden menu option called Configuration Information which will display details like the following:
DG URL Internal;https://fe.jdskype.net:443/groupexpansion/service.svc;–;
DG URL External;https://fe.jdskype.net:443/groupexpansion/service.svc;–;
Quality Metrics URI;;–;
ABS Server Internal URL;https://fe.jdskype.net:443/abs/handler;–;
ABS Server External URL;https://fe.jdskype.net:443/abs/handler;–;
Voice mail URI;sip:email@example.com;opaque=app:voicemail;–;
Call Park Server URI;sip:firstname.lastname@example.org;gruu;opaque=srvr:Microsoft.Rtc.Application…
Server Address Internal;;–;
Server Address External;;–;
Server SIP URI;email@example.com;–;
GAL or Server Based Search;GAL search;–;
PC to PC AV Encryption;AV Encryption Enforced;–;
Telephony Mode;Telephony Mode Disabled;–;
Line Configured From;Auto Line Configuration;–;
Configuration Mode;Auto Configuration;–;
EWS Internal URL;;–;
EWS External URL;;–;
SharePoint Search Center URL;;–;
Skill Search URL;;–;
Skype for Business Server;fe.jdskype.net;–;
Local Log Folder;C:\Users\jeff.JDSKYPE\AppData\Local\Microsoft\Office\15.0\Lync\Tracing;–;
Inside User Status;TRUE;–;
Contact List Provider;Skype for Business Server;–;
Pairing State;Skype for Business cannot connect to your desk phone because the USB cable is not plugged in. Make sure that you connect the cable.;Enabled;
UCS Connectivity State;Exchange connection Down;–;
MAPI Information;Your Outlook profile is not configured correctly. Contact your support team with this information.;MAPI unavailable;
EWS Information;;EWS not deployed;
License State;Lync ProPlus;–;
Hanging Notification Status;;Disconnected;
pChat Room Mgmt Int URL;https://fe.jdskype.net:443/PersistentChat/RM;–;
pChat Room Mgmt Ext URL;https://fe.jdskype.net:443/PersistentChat/RM;–;
Container list Preferred Endpoint;TRUE;–;
pChat Default URI;;–;
Note the null values above for the various roles which have not yet been deployed or configured. As additional roles are deployed like an Edge Server, Outlook Web App Server, and Exchange Server these parameters will no longer be blank .
To validate that the different Multipoint Control Unit (MCU) services are functional on the Front End server an ad-hoc conference can be started to test the various modalities.
- On the Skype for Business client menu select Meet Now.
If this is the first time a meeting was started, and depending on the available resources and processing power on the Front End server the initial startup could take a few seconds. A beeping tone may be heard during this time as the server allocates resources to host this conference.
- When the meeting begins enable video by selecting Start My Video from the camera button.
- If a second workstation is available then sign in to a Skype for Business client using the other the other account (e.g. firstname.lastname@example.org) .
- Invite the other user account to the meeting to test audio and video in both directions. This validates the operation of the Audio/Video Conferencing service (RTCAVMCU).
- Click the IM button to show the conversation panel and type in a message. Verify that the messages was received on the other workstation and type in a response. This capability leverages the IM Conferencing service (RTCIMMCU).
- On either workstation click the Present button, select either Present Desktop or Present Programs, and choose from a running application. Click Present to being sharing the screen. This tests the Application Sharing service (RTCASMCU).
If the earlier deployment was successful and each of these features are working as expected this indicates a healthy Skype for Business Front End server. This seems like a good point to start (temporarily) breaking things for the purposes of education.
- Leave the conference running as shown above and then connect to the Skype for Business Front End server.
- Open the Services administrative tool on the server and scroll down to the multiple Skype for Business Server entries.
- Select the Skype for Business Server Application Sharing service and then choose the Stop action.
Almost immediately the following messages should appear on screens of both meeting participants, and the shared desktop or application will have disappeared.
Note that the remainder of the meeting capabilities (e.g. video, IM) are still functioning. Yet if the Present button is selected the menu options for presenting the desktop or an application are now gone. Only the Present PowerPoint Files option should still remain, although this feature is not yet functional as the required Office Web Apps server has not yet been deployed in this environment.
- Stop the Skype for Business IM Conferencing service and then attempt to send another message in the meeting.
Another error will appear indicating that the service providing this capability is not currently available.
- Stop the Skype for Business Audio/Video Conferencing service.
Immediately both of the far-end participant and local video displays should disappear and within a few seconds a message should appear indicating that the call has been dropped. Technically the client is still connected to the meeting, but nearly all of the available modalities have been crippled.
Attempting to click rejoin at this point would result in an ‘Operation was unsuccessful’ response. Restoring the individual services will also allow the meeting to return to its former state.
- Start the Skype for Business Audio/Video Conferencing service and then select Rejoin from on of the clients. The other participants in the meeting will be prompted to reestablish the audio and video.
- Start the Skype for Business IM Conferencing service to restore instant messaging in the meeting.
- Start the Skype for Business Application Sharing service to return the server back to fully functional. Share the desktop or an application from one of the workstations to verify the functionality..
With the existing conference still running and all modalities restored a number of basic queries can be run on the server to get some insight into what the current load is. Obviously in this example there is only a single meeting running but the same concepts apply when performing these actions on a test or production environments which may return much more data.
- Open the Skype for Business Management Shell and type in the Get-CsWindowsService cmdlet to query the status of each service.
Note that the ActivityLevel field reports the concurrency of active conferences, connoted users, and how many are participating in the various modalities. In this environment the single running conference with two participants are reflected in the data shown above.
To get a detailed look at the performance metrics for the running conference the basic Windows Server Performance Monitor tool can be used. As usually is the case with this tool it can be a daunting task to identify what counters to view, so here is an easy way to list all, or a subset, of the sets related to Skype for Business Server.
- In the Skype for Business Management Shell enter the following Get-Counter cmdlet to list any sets which are applicable to the various MCU services. (All of the Skype for Business counters are prefixed with ‘LS:’ which is a carry-over for Lync Server.)
Get-Counter -ListSet "LS:*MCU*" | Select-Object CounterSetName
- Launch Performance Monitor on the Front End server and select a few various counters from the counter sets listed above. In the following example are a handful of different related counters were added across the application sharing, IM, and A/V MCUs.
- For environments with a small number of conferences running change the graph’s Maximum to a value lower than 100 in the Action > Properties > Graph > Vertical Scale settings.
At this point the Skype for Business environment is ready for additional configuration which will be covered in upcoming articles in this series. To find an updated list of the applicable articles simply combine the Deployment and 2015 tags as shown in the following URL to filter for only Skype for Business 2015 Server deployment articles on this site.
The next round of quarterly Lync Users Group meetings has been scheduled and announced for this month.
This meeting will be conducted in our familiar two-session format:
This meeting will include two sessions, with the first session covering Skype for Business Hot Topics, addressing commonly asked questions on SfB infrastructure and tools. Topics will include supported topologies, VDI, dial-in conferencing and security.
The second session will dive into Skype for Business Recent Announcements, an open forum on the Office 365 preview for Cloud PBX, Audio Conferencing and Broadcast meetings.
Industry Experts will be on-site to deliver these presentations and help answer any questions related to Lync. Food, beverages and additional door prizes will be provided courtesy of the Lync Users Group and its official sponsors.
For a full schedule of regional events the Lync Users Group Locations page lists all planned event locations with links to the associated Meetup.com page for each regional group. For current members if your region’s event is not yet scheduled just make sure that your notification options are configured so that you’ll get an alert when the new event is posted. For anyone who is not yet a member and would like to participate simply create a new Meetup account (or use an existing one) and join your local group.
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.
|Thursday, July 23rd
5:30PM – Food and Networking
6:00 PM – Presentation Kickoff
|Chicago UC Users Group||Microsoft Technology Center
200 East Randolph Drive, Suite 200
Chicago, IL 60601
Continuing from a previous post this article moves into the installation and configuration of the Skype for Business Server components for a Standard Edition Front End server. As with the previous article any mandatory steps are identified by bulleted paragraphs while non-indented steps for validation and educational purposes are optional.
The second article in this series will cover the following deployment steps:
Defining the Topology
Deploying the Server Components
Verifying the Installation
Before performing these steps in this article make sure to successfully complete all of the prerequisite actions covered in Part 1 of this series.
Before installing any additional server components the Skype for Business topology must be defined.
Create New Topology
- Launch the Skype for Business Server 2015 Topology Builder and then select New Topology.
- Save a new .tbxml file with any desired name (e.g. 06072015.tbxml).
- For the Primary SIP domain enter the desired domain namespace (e.g. jdskype.net).
Add any additional desired SIP domains at this point , but a single SIP domain is sufficient for most deployments as well as this series of articles.
- Select a Name for the first site to be created in the topology (e.g. Lab) and enter a Description if desired.
- Specify the locality information associated with the first site and then complete the wizard.
At this point the Define New Front End Pool wizard should be automatically launched.
- On the Define Front End Pool FQDN page select Standard Edition Server and then enter the Fully Qualified Domain Name (FQDN) of the Windows domain member server where the SFB prerequisites were installed (e.g. fe.jdskype.net).
- Select the features which should be installed and enabled on this Front End server. Later articles will cover the deployment of some of these additional features.
- Retain the default enabled setting of Collocate Mediation Server on the Select Collocated Server Roles page.
- On the Associate Server Roles with this Front End Pool page leave the option blank as an Edge Server does not yet exist. This setting will be addressed when an Edge Server is deployed in a later article.
- As this is a Standard Edition server then there will be no configurable options available on the Define the SQL Store page. Take note of the automatically defined SQL Server store which is comprised of the server’s FQDN (fe.jdskype.net) followed by the previously installed SQL Express instance name (RTC).
- On the Define a File Store page enter the name of the Windows file share created in the previous section (e.g. SFBShare).
On the Specify the Web Services URL page the External Base URL will automatically be set to the same FQDN as the internal Front End server (e.g. fe.jdskype.net). For the purposes of this article the default setting will be retained and in the future when external services are published this will be updated to reflect the external namespace.
The next page Select an Office Web Apps Server is used to either define a new OWAS pool FQDN or associate this server with an existing OWAS pool. The next article will cover deploying this server role so simply uncheck this option and then click Finish to complete the wizard. (Note that until this server is deployed that PowerPoint content sharing will be unavailable as this service is not handled by the Skype for Business Front End server role.)
Upon completion the Topology Builder window should refresh and the defined settings will be populated as shown.
- Back at the main Topology Builder window select Edit Properties on the Lync Server root-level object. Highlight the Simple URLs section and enter the desired Administrative Access URL (e.g. https://admin.jdskype.net). Technically his is an optional step as the administrative access URL is not required, but is a convenient way to access the Server Control Panel via a web browser internally.
- Move down to the Central Management Server section and select the new Front End server (e.g. fe.jdskype.net) as the location to install the CMS component on.
The final process is to publish the changes made to the topology into the Central Management Server database which also updates information in the RTC services container in Active Directory and sets up the folder structure and permissions on the file share.
From the Action menu select Publish Topology. The local server FQDN for the Central Management Store location should already be populated in the drop-down menu due to the previous step. If all configuration steps were performed correctly then the wizard should complete without any errors or warnings.
Unlike most other Microsoft server platform products were installation of the actual server components is one of the very first steps, the Communications Server family has historically been different. The server installation itself is quite hands-off and can be automated to a large degree. The fair amount of activity up until this point has been geared around providing the backend components to store the overall configuration of the environment, which is now available for use by the server installation steps.
Install Skype for Business Server Components
The next step is to install a second SQL Express named instance called RTCLOCAL on the local server which will contain a replica of the existing RTC named instance.
Only the first Standard Edition server in the organization would contain the authoritative RTC instance installed in the previous article, while all other Front End Servers (and even Edge Servers) would contain their own RTCLOCAL instance to replicate the Central Management Store data.
As the Administrative Tools have already been installed on the server then the Skype for Business Server Deployment Wizard can be found in the Start Menu on the local server. The installation media is no longer required as the installation files have been copied to the server.
- On the Windows Start Menu search for ‘Deploy’ to locate and launch the Skype for Business Server Deployment Wizard. From the main menu select Install or Update Skype for Business Server System.
- On Step 1: Install Local Configuration Store select Run and leave the default setting of Retrieve the configuration data directly from the Central Management Store and complete the wizard.
Reviewing the results in the execution window should confirm that the second SQL Express instance of RTCLOCAL was installed as well as the core SFB Server components.
Checking prerequisite SupportedOSNoDC…prerequisite satisfied.
Checking prerequisite DotNet35…prerequisite satisfied.
Checking prerequisite SupportedSqlRtcLocal…prerequisite satisfied.
Checking prerequisite WMIEnabled…prerequisite satisfied.
Checking prerequisite NoOtherVersionInstalled…prerequisite satisfied.
Checking prerequisite PowerShell…prerequisite satisfied.
Checking prerequisite SqlUpgradeInstanceRtcLocal…prerequisite satisfied.
Installing SQLEXPR_x64.exe(/Q /IACCEPTSQLSERVERLICENSETERMS /UPDATEENABLED=0 /HIDECONSOLE /ACTION=Install
/FEATURES=SQLEngine,Tools /INSTANCENAME=RTCLOCAL /TCPENABLED=1 /SQL…
Secondly the Local CMS replica was instantiated by importing the configuration from the existing CMS database an then replicating the database data itself.
Import-CSConfiguration -FileName "C:\Users\ADMINI~1.JDS\AppData\Local\Temp\2\CSConfigData-2015_06_08-13_19_39.zip" -Verbose -LocalStore
> Enable local replica service
Enable-CSReplica -Verbose -Confirm:$false -Report "C:\Users\administrator.JDSKYPE\AppData\Local\Temp\2\Enable-CSReplica-[2015_06_08][13_17_14].html"
Additionally the replication of any certificates stored in the CMS is performed. Although no certificates have been installed yet for this deployment had there been one then this action would have replicated any existing OAuthcertificates required for server to server MTLS communications.
Logging status to: C:\Users\administrator.JDSKYPE\AppData\Local\Temp\2\ReplicateCMSCertificates-[2015_06_08][13_17_14].html
To confirm the installation location of the RTCLOCAL database files on the server check the default SQL Server installation directory for the existence of the xds files.
%ProgramFiles%\Microsoft SQL Server\MSSQL12.RTCLOCAL\MSSQL\DATA
- On the Skype for Business Server Deployment Wizard advance to Step 2: Setup or Remove Skype for Business Server Components and click Run to start the Set Up Lync server Components wizard.
Once again the Bootstrapper application will execute and perform a prerequisite check before installing additional components. These include a third SQL instance called LyncLocal and additional Windows Speech components and foreign language packs.
Checking prerequisite KB2858668Installed…prerequisite satisfied.
Installing WindowsFabric\v3\WindowsFabric.msi( REBOOT=ReallySuppress STARTUPTYPE=demand REMOVEDATA=yes IACCEPTEULA=yes TESTMODESKIPPREREQUISITECHECK=yes)…success
Installing MicrosoftIdentityExtensions.msi( REBOOT=ReallySuppress ALLUSERS=1)…success
Checking prerequisite SqlUpgradeInstanceLyncLocal…prerequisite satisfied.
Installing SQLEXPR_x64.exe(/Q /IACCEPTSQLSERVERLICENSETERMS /UPDATEENABLED=0 /HIDECONSOLE /ACTION=Install
/FEATURES=SQLEngine,Tools /INSTANCENAME=LYNCLOCAL /TCPENABLED=1 /SQL…
Immediately following will be the installation of the Lync server components which make up the different services and roles on the Front End server (e.g. AVMCU, Mediation Server).
Verify that the installation task status was reported as successfully completed.
Create Default Server Certificate
Returning to the server deployment process the next step is to request and assign server certificates so that the Lync services can be started.
If using an Enterprise Windows CA make sure that before any server certificates are requested that the guidance mentioned in the Environment section of the previous article is followed. In order to properly support PowerPoint file sharing to any Office Web App attendees which are on workstations which are not domain-joined then the default Windows Certificate Authority configuration must be modified.
- Using the guidance covered in either of these two articles launch the Certification Authority (certsrv.exe) application and under the CA’s properties configure the CRL Distribution Point (CDP) and Authority Information Access (AIA) extensions to include the HTTP paths in any certificates issued and signed by this CA.
At this point any new certificate requests will include this critical information in the issued certificate.
- Run Step 3: Request, Install or Assign Certificates and then expand the Default Certificate entry to verify that all roles are checked. Click Request to start the Certificate Request wizard.
Populate the desired information making sure to select the SIP domain to add the sip.<sipdomain> record to the certificate.
The Friendly Name can be set to anything and is not actually part of the certificate request, it can even be changed after the certificate is returned and imported. Note that although Lyncdiscover.<sipdomain> was not defined as an internal DNS record in the previous article the certificate wizard still includes this FQDN as a requirement for external support.
- Submit the request to the online certificate authority and when the task completes successfully select the View Certificate Details button to validate the certificate status and that a private key was correctly associated.
- Advance to the next wizard to perform the Certificate Assignment task. In the event that the role assignment is accidentally lost between the request and assignment wizards then the assignment task might fail with an error that a Type has not been provided. If that occurs simply cancel out of the wizard and return to the main wizard screen. On the Certificate Wizard main screen If the checkboxes to the left of the Server Default, Web Service Internal, and Web Service External roles are no longer selected then reselect them and click Assign.
- Verify that the proper certificate is highlighted (in the event that this server already has any other server certificates installed on it) and then complete the wizard, verifying that the task status is reported as Completed.
- Back at the Certificate Wizard main screen the new certificate should now be listed on each of the three Default Certificate roles.
Create OAuth Certificate
As this is the first SfB server deployed into the environment then a new OAuth certificate needs to be created as well. This is a one-time process as this certificate will be shared by any other SfB server which may be later installed.
- On the Certificate Wizard main screen select the OAuthTokenIssuer role and then click Request.
- Enter a descriptive Friendly Name and then submit the certificate request.
- Advance through the assignment wizard to finish the OAuth certificate configuration in the same fashion as performed for the server certificate.
In previous releases the services could be started directly from the deployment wizard as part of Step 4: Start Services. With the addition of a new PowerShell cmdlet in SFB this task is now a manual one. While SfB Server now includes a new cmdlet called Start-CsPool this is only intended for use with multiple node Enterprise Edition pools. When dealing with a single server in a pool or a Standard Edition server as in this article then the previous guidance of using the CsWindowsService cmdlets still holds true.
- Launch the Skype for Business Server Management Shell and execute the following Start-CsWindowsService cmdlet.
To validate the server status the Get-CsWindowsService cmdlet can be issued to list the individual SfB services.
Utilizing the Skype for Business Server 2015 Control Panel the basic functionality of the new deployment can begun to be tested.
Before opening the Skype for Business Server 2015 Control Panel, just as with previous Lync Server releases, it is helpful to configure the local server’s Internet Options to bypass the the prompt for credentials whenever the tool is launched.
- Open Internet Options, navigate to the Security tab, select Local Internet and click Sites, then click Advanced.
- Enter the local server’s FQDN as a URL (e.g. https://fe.jdskype.net) and then save the changes.
- If Silverlight is not already installed on the server than the Control Panel will report this fact.
- Use the provided link to immediately download and install Silverlight on the local server.
- Once the installation is complete the Home page of the control panel will be displayed. Select the Topology menu and verify that the new server is listed and the Status and Replication fields are healthy.
With the conclusion of this article a functional Skype for Business Server should now be deployed and is ready for further configuration. The next article in the series will cover enabling a test user account and then progress on with deploying additional server roles like the Office Web Apps Server.
Similar to past articles this series of basic deployment articles will be used to capture a specific environment to also be used as the foundation for many Skype for Business (SfB) Server 2015 specific deployment articles. Starting with a single Standard Edition Skype for Business Server in a fresh Active Directory forest future articles will build on this deployment with additional component installation like Edge Services, Exchange Server integration, etc.
Throughout this series of articles the same basic instructional flow is used as for previous releases. Although it may not have been obvious the usage of bulleted items is intentionally specific. Steps starting with a bullet are mandatory to reach the same level of installation completion as the article intends to provide at the end. Yet normal paragraphs without bullets may include optional steps intended to provide a deeper understanding of a previous action or cover the installation of optional tools or components used to aid in knowledge transfer of the topic at hand. This format aids in skimming through the article for repeated installations.
For these articles specific to Skype for Business Server 2015 a new lab environment has been created which is slightly different to environments used in the Lync Server articles. An important change from the past is that a single, flat internal Active Directory and SMTP/SIP domain namespace is now being utilized. This decision was made based on two factors: that a single namespace is easier to deal with when performing fresh lab installations and also that this reflects more common best practices today. Because many corporate networks still utilize disparate namespaces the difference between them may be specifically called out in these articles when prudent for educational reasons.
As was also done in the previous Lync Server 2013 deployment articles a valid Top Level Domain (TLD) name was selected for the single namespaces to allow for the use of public certificates where desired, as described in this previous article. A joint Active Directory and primary SIP/SMTP namespace of jdskype.net is used throughout this new series of articles.
- Physical Host: VMware ESXi 6.0 server running on an HP ProLiant DL380 with 96GB of RAM and 12 physical CPU cores.
- Domain Controller: A single Windows Server 2012 R2 x64 guest promoted to a domain controller for the new Active Directory forest root domain of jdskype.net.
- Skype for Business Front End Server: A second virtual guest running Windows Server 2012 R2 x64 Standard Edition and joined to the jdskype.net domain.
- The default domain administrator account used to perform all steps is a member of the Domain Admins, Enterprise Admins, and Schema Admins domain security groups.
- The Forest and Domain functional levels were set to Windows Server 2012 R2.
- A Windows Enterprise Certificate Authority was deployed on the domain controller to provide SSL certificates for internal services. The CA configuration was updated to provide access to the Certificate Revocation List via HTTP, as explained in this article. The Root CA certificate was created with a hash algorithm of SHA256 and a 2048 bit key length.
- While optional, an Exchange Server 2013 deployment was also previously completed in this environment which will be utilized in future integration articles for features like Unified Messaging or Outlook Web Access integration.
This article will begin with the installation of a single Standard Edition Skype for Business Front End Server. For the purposes of test or educational lab environments it is more efficient to use this option than to deploy Enterprise Edition servers which requires at least one additional backend SQL Server. For details specific to deploying Enterprise Edition pools the Skype For Business Server installation documentation should be used to accomplish this as it covers an Enterprise Edition deployment as the primary example.
The first article in this series will address the following preparation steps:
- Creating a File Share
- Configuring DNS Records
- Installing the Server Prerequisites
- Installing the Administration Tools
- Preparing Active Directory
- Preparing the Central Management Store
Before performing any of these steps though the following actions were already completed in the environment:
- Windows Server 2102 R2 installed with a static IP address on a new server.
- Renamed the server and joined it to the Active Directory domain (e.g.fe.jdskype.net).
- Signed into the server using the default domain administrator account (e.g. JDSKYPE\administrator).
Create File Share
As this will be a Standard Edition server then it is supported to collocate the required file share on the same server, unlike Enterprise Edition server which must use a separate server to host this.
- Create a new folder on the server (e.g. SFBShare) anywhere on the server. The following path was used in this lab deployment:
- Verify that the local Administrators group is already granted Full Control at the NTFS file permission level and then enable sharing for this folder. Provide a name for the new share (e.g. SFBShare) and then assign Full Control share permissions to the local Administrators group . The permissions on this share will be more granularly defined when the Topology is published in a later step, so this step is just to ensure that the later installation process will have sufficient rights to this directory to perform the required changes.
- Verify that the newly created directory is now available as a shared directory.
Configure DNS Records
The next step is to manually create a few DNS records to support various client lookup requests.
The following table lists the various Fully Qualified Domain Names (FQDN) which must be manually created for a Standard Edition server deployment . Many guides will instruct that these records are all created as a standard Host (A) record but most of these records are also supported as an Alias (CNAME) record. Utilizing Alias records when supported is generally a better practice in DNS than managing multiple Host records, but either approach is acceptable.
|FQDN||Record Type||Resolves To||Description|
|meet.jdskype.net||CNAME||fe.jdskype.net||Meeting Simple URL|
|dialin.jdskype.net||CNAME||fe.jdskype.net||Dial-In Simple URL|
|lyncdiscoverinternal.jdskype.net||CNAME||fe.jdskype.net||Internal SfB Client Auto Discovery|
|sip.jdskype.net||A||192.168.0.102||Legacy Client Discovery|
|_sipinternaltls._tcp.jdskype.net||SRV||sip.jdskype.net||Legacy Client Discovery|
Note that with a Standard Edition server the server’s hostname is the same as the Front End Pool name which will already be defined in DNS as all domain member servers will dynamically create and manage their own DNS record. The only records which need to be created manually in this step are for client auto-discovery and the various web URLs.
Also be aware that to fully support older Lync clients, especially Lync Phone Edition devices, it is still a best practice to define a ‘sip.<sipdomain>’ DNS record as well as the associated Service Location Record (SRV) in the environment.
- In the appropriate DNS Forward Lookup Zone create a new Alias (CNAME) record for the ‘meet‘ FQDN, selecting the desired SfB Front End server’s FQDN as the target host. Repeat this step for the ‘dialin’ and ‘admin’ FQDNs as well.
- Repeat the previous step for the ‘dialin’ and ‘admin’ FQDNs.
- Create a new Alias (CNAME) record for the ‘lyncdiscoverinternal’ record, selecting the same FQDN as the target host.
- Create a new Host (A) record for the legacy ‘sip’ hostname, entering the desired SfB Front End server’s IP address as the target host.
Verify the new records were successfully created and test them against the ping or nslookup command from a server or workstation in the environment.
- Create a new Service Location (SRV) record from the Other New Records menu option in the Microsoft DNS Manager, entering the following details.
Port Number: 5061
Verify that the new SRV record has been successfully created and is resolvable using the following command in either Windows Command Prompt or Windows PowerShell.
nslookup -q=srv _sipinternaltls._tcp.jdskype.net
Install Server Prerequisites
Prior to running any Skype for Business Server installation tasks a number of Windows Server components need to be installed.
- 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.
Add-WindowsFeature NET-Framework-Core, RSAT-ADDS, Windows-Identity-Foundation, Web-Server, Web-Static-Content, Web-Default-Doc, Web-Http-Errors, Web-Dir-Browsing, Web-Asp-Net, Web-Net-Ext, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Http-Logging, Web-Log-Libraries, Web-Request-Monitor, Web-Http-Tracing, Web-Basic-Auth, Web-Windows-Auth, Web-Client-Auth, Web-Filtering, Web-Stat-Compression, Web-Dyn-Compression, NET-WCF-HTTP-Activation45, Web-Asp-Net45, Web-Mgmt-Tools, Web-Scripting-Tools, Web-Mgmt-Compat, Server-Media-Foundation, BITS -Source D:\sources\sxs -Restart
- After the server finishes rebooting disconnect the Windows Server media and mount the Skype for Business Server 2015 installation media.
These newly installed Windows Server components may have one or more applicable pending Windows Updates.
- Run Windows Update on the server, install any pending recommended updates, and reboot the server if requested.
- Open Windows Update again and perform another check to verify there are no additional pending recommended updates.
Additionally there is at least one critical hotfix which if not detected by the deployment wizard will block the installation of the SfB server components. While the required hotfix has already been included as part of the December 2014 Update Rollup the SfB deployment wizard will still fail to locate the prerequisite and fail. It is recommended to install both the update rollup and the individual prerequisite hotfix.
- Return to Windows Update on the server to install the Optional Update for Windows Server 2012 R2 (KB3013769). Sort the list by file size and this large rollup package should be listed near the top of the Server 2010 R2 updates.
- Also download and install the available hotfix for KB2982006 and then reboot the server.
Install Admin Tools
In order to configure the Topology in a later step the Topology Builder application needs to be installed, which is part of the SfB administration tools package.
- Open the mounted DVD drive and the deployment wizard should autoplay and (if required) begin the installation of Visual C++ 2013 Runtime package.
- Confirm the default Installation Location or change the path to a different directory if desired.
C:\Program Files\Skype for Business Server 2015
The Core Components package will automatically be installed.
- When the Deployment Wizard loads the main page select the Install Administrative Tools option on the right-hand side to launch the Install Administrative Tools wizard. Advance through the wizard and when both the prerequisite component check and the tools installation is successful the task status will be reported as Completed.
To see the list of newly installed application search for ‘skype’ in the server.
Prepare Active Directory
As this is the first Skype for Business Server 2015 installation in the Active Directory forest then the AD Schema, Forest, and Domain will need to be extended to include the various configuration objects utilized by Skype for Business Server 2015.
- Return to the main menu of the deployment wizard and select Prepare Active Directory and then click Run on Step 1: Prepare Schema.
To confirm some of the changes applied by this step open adsiedit.msc and connect to the Schema container to verify that the various ‘ms-RTC-SIP…’ schema attributes have been created.
If deploying in an environment with a single domain controller there is no need to run the replication verification processes.
- Select Run on Step 3: Prepare Current Forest and select the Local Domain as the Universal Group Location if desired. If SfB is being installed into a multiple domain forest and the universal groups need to be stored in a domain other than the domain that the current server is a member of then enter the desired domain FQDN.
Run dsa.msc to open Active Directory Users and Computers and then browse to the default Users container. Look for a number of groups starting with ‘CS’ and ‘RTC’ in their names. These groups were created during the Forest preparation step in the chosen domain.
- Advance to Step 5: Prepare Current Domain to complete the Active Directory preparation steps.
Prepare Central Management Service
The final preparation step is to install SQL on the first Front End server in the forest so that the topology configuration can be published to it.
This process will install the SQL Native Client and SQL Server Express components as well as configure Windows Firewall exceptions for remote SQL connectivity. Mostly importantly it also deploys a SQL Server Express named instance, simply called RTC. This instance will be the default location for the Central Management Store which is where Lync will store the majority of the global (forest-wide) configuration data. The RTC Service container shown above in the AD Configuration partition is still used to store some data, but mainly for coexistence with previous releases.
- Return to the main menu of the deployment wizard and select Prepare First Standard Edition server. It is normal for this process to take a few minutes to complete as the SQL Server Express components are installed.
A quick glance at the Programs and Features control panel shows all of the components which were installed on the server once this process is completed.
- Before moving further the domain Administrator account used throughout this process should be added as a member to the domain security groups CsAdministrator and RTCUniversalServerAdmins.
- This user account should then logoff and back on to the Windows Server where Skype for Business Server is being installed to update the associated security token.
Once logged back on use the following whoami commands in the Windows Command Prompt to verify the new group membership.
whoami /groups /fo list | findstr /i CsAdmin
whoami /groups /fo list | findstr /i RTC
This concludes the preparation of the environment and the next article in this series will address defining a new topology and installing the SfB Front End server components.
Next week at the Microsoft Ignite 2015 event in Chicago I will be presenting a session on video conferencing with Skype for Business 2015.
This presentation will brush up on a few new client features, introduce various interoperability models and then dive deep into the new Video Interop Server role in Skype for Business Server 2015.
Wednesday, May 6
5:00 PM – 6:15 PM
The great video experience of Skype for Business demystified! Behind the smiling faces of your customers, colleagues, and partners is some sophisticated technology. Come learn the details of how Skype for Business pulls it all together for a great video calling experience. We provide in-depth coverage of architecture, user experiences, and the new investments around Video Interoperability.
If you are attending Ignite you can join me for this session by adding it to your My Schedule page. I’ll also be working in various booths across the Expo floor so come by and say hello at either the Polycom, Skype for Business, or Lync Users Group booths throughout the week.