After installing MS14-082 (part of December 2014 Public Updates for Office) you might get the error run-time error '438': Object doesn't support this property or method, when clicking on the enable content button. If you click Debug you will see the reference shown below:

The root cause of this appears to be related to problems mentioned in KB3025036 and here and performing the steps in the Resolution 1 section of the KB has fixed the issue.. 

This post is authored by Henrik Jørgensen from Microsoft Services in Denmark.

The following is based upon real life experience with the CQM framework from a Microsoft Consulting Services project.

One of our customers reported bad experiences with Lync. Specifically the customer reported, that their end-users complained about problems with Audio and Video. The problems reported could be divided into 2 scenarios:

1. In PC to PC communication, where 2 end-users communicated via the Lync 2010 client.
2. In Conferences hosted on the Lync 2010 platform, where multiple end-users participated in a conference call.

The customer is a major global player in their specific area. They host several Lync pools globally and are represented in countries around the globe.

An approach to analyze the above problems is to use the Call Quality Methodology (CQM) framework as introduced by the Microsoft Lync product group.

The approach was to establish a baseline, in order to understand the level of the problems but also have a benchmark to compare with after implementation of changes to the Lync environment and related IT infrastructure components.

We divided the work into the following areas:

• Client analysis
  • Bios and device drivers
  • Patch level of the OS in use
• Server Analysis
  • Compare hardware in use vs. Lync Server hardware requirements
  • Bios and device drivers
  • Patch level of the Server OS
  • Lync Key Health Indicators as defined in the Lync Networking Guide
• CQM analysis
  • Use the CQM SQL queries to analyze the data in the QoE database
• Network analysis
  • Definition of persona profiles for Lync usage
  • Logical map of the Network topology
  • Bandwidth estimate calculation
  • Network Assessment for UC

The work involved several IT teams at the customer. A key learning was, that the operation of a complex IT-infrastructure as Lync calls for co-operation and communication between the IT teams involved in operations and maintenance of the Lync infrastructure.

The analysis work revealed several findings:

• Clients
  • The Bios level needed to upgraded on some pc's
  • It was necessary to deploy newer versions of drivers for Network Interface Cards in the clients
• Servers
  • The Hardware requirements was met
  • Newer BIOS and firmware was needed at the server level

The KHI, CQM and Network Analysis revealed other findings. These are presented in more detail in the following.

Server Key Health Indicators

We used the KHI collection PowerShell script from the networking guide. We collected data for 5 working days. Afterwards, the data was imported to Microsoft Excel.
Among other critical findings, we observed packet loss on some of the front-end servers. This called for further analysis of the server problems. A firmware upgrade was part of the solution.

CQM Analysis

The CQM SQL queries are divided in 3 areas

1. Endpoints – the methodology will help to determine whether there are problems with the client pc's or the devices connected to these.
2. Server to server / gateway traffic – in order to document whether the Lync media servers are healthy or not. Furthermore, the methodology can document whether conditions on the servers are contributing to packet loss and Jitter.
3. Network – the methodology will document which LAN subnets the Lync poor calls are coming from.

We used the queries in the Networking guide. A summary of the findings are provided below:

Endpoints

The CQM queries revealed that a majority of end-users at given locations did not use Lync certified devices. The customer initiated a process to

• Provide the end-users with certified devices
• Learn the end-users to use the devices

Server traffic

The CQM queries documented packet loss between the AVMCU and the Mediation Server and from the Mediation Server to the gateway at some sites. Further analysis looked at

• Non Lync Software on the servers
• Lync pre-requisites regarding antivirus exclusions
• Ensure that the network equipment are healthy and it follows Microsoft guidelines from the Open Interoperability List
• Firmware on the servers network interface card

Network traffic

We identified several issues

• All access to the Lync infrastructure was via VPN for the customers employees when working remotely. Split tunneling was not implemented.
• Some internal peer-to-peer traffic was relayed via the Edge servers.
• RTT > 500 Ms was observed on some network connections
• Packet loss on WiFi networks.

All above findings called for additional analysis and work in order to solve the problems.

Network Analysis

Together with the customer, we defined three persona profiles. These where defined in the bandwidth calculator.
The customers HR department provided us with a number for each of the persona profiles at the specific locations where the customer is represented.

The calculations in the bandwidth calculator revealed:

• Possible overflow of the QoS queue allocated for Lync traffic
• Locations where more bandwidth was needed to handle the Lync traffic

Furthermore, the customer initiated a network assessment of the WAN. The assessment documented the predictions from the bandwidth calculator.

Customer initiated actions to improve the Lync experience

The customer initiated several actions to improve the Lync experience of their end-users. In summary these are

• Acquiring more WAN bandwidth for given locations
• Implementation of Quality of Service on the network
• Renewal of network equipment at given locations
• Improvements to existing WiFi implementations at given sites
• Training of the end-users
• Proactively use of the CQM methodology in order to monitor improvements

   

Key learnings

With the CQM approach, we helped our customer to not only troubleshoot and fix problems with their Lync infrastructure. We also established a methodology that is used pro-actively in their environment to prevent problems in Lync communications internally as well as with external parties.

A key learning is that CQM is a very good framework, but the value from it can be very limited, if the processes at a customer are not aligned to CQM and a proper Lync service mapping is not in place. Furthermore, the different IT teams at the customer needs to communicate very close about operation and maintenance of the IT infrastructure.

[Updated August 8, 2014]

In this post, I will show some of the common problems people run into when using the CQM Scorecard and how to fix them.

Microsoft Visual Basic for Applications – Compile error: Method or data member not found

You might see the error message shown below.

The reason you see this message is most likely that you are using a version of Microsoft Excel prior to 2013. The CQM Scorecard require Microsoft Excel 2013. To solve the problem open the CQM Scorecard in Microsoft Excel 2013.

Microsoft Visual Basic for Applications – Rune-time error '13': Type mismatch

You might see the error message shown below.

The most likely reason for seeing this error is that you have loaded the CQM results using the wrong decimal separator. The Scorecard needs to use the same decimal separator as in the CQM result CSV files. If it is not the same, Excel will load the PoorStreamsRatio as text and not as a number, and that causes the above error.

You can check if this is the reason for the error by looking at one of the Trend sheets and the PoorStreamsRatio column. If you see formatting being a mixture of left and right aligned values as shown in the figure below, the CQM results were loaded with the wrong decimal separator.

To discover which decimal separator to use open one of the Trend CQM result CSV files in Notepad and look at one of the lines. An example is shown below.

"1/23/2014","18874","2380","12.6","Trend_3_Wired"

The bolded yellow value shows you that the decimal separator is a dot. Therefore, you need to use Dot as the decimal separator, when loading the CSV results.

You can also get this error when all the devices listed in Endpoint_0_Device sheet has AvgSendListenMOS below the target value set in the Scorecard. There is a bug in logic in this scenario, which will be fixed in the next release. Possible work-arounds are either to add one device with AvgSendListenMOS above target or lower the target.

Different formats for date labels on trend charts

You might see different format for date labels on charts. An example of this is shown below. You can see that the date format changes from 1/31/2014 to 02-02-2014.

This happens if the CQM results are loaded with the wrong date format. This leads Excel to load the dates incorrect and that makes the charting incorrect.

You can see if this is the case by looking in one of the Trend sheets. If you see the dates in the ReportDate column formatted as shown in the figure below the results were loaded with the wrong date format.

To discover which date format to use open one of the Trend CQM result CSV files in Notepad and look at one of the lines. An example is shown below.

"1/23/2014","18874","2380","12.6","Trend_3_Wired"

The bolded yellow value shows you that the date format is MDY, because the date is shown as 1/23/2014. Therefore, you need to use MDY as the date format, when loading the CSV results.

Yesterday we made version 2.2 of the Networking Guide available and it now includes the Microsoft Call Quality Methodology Scorecard for Lync Server. The Scorecard is used to implement Call Quality Methodology (CQM) as discussed in Appendix C of the Networking Guide.

The new features in this version of CQM includes:

• PowerShell script to run the CQM queries against the QoE database
• The ability to use different conditions to flag an audio stream as poor
• The ability to remove off-work days from the results and thereby removing outliers skewing the poor stream ratios
• The Excel 2013 macro-enabled Scorecard which can load the CSV files generated by running the CQM queries, draw charts, show the Top 10 Issues for various categories and not least update the Scorecard with green/yellow/red status for the different CQM dimensions

You can read much more about the Scorecard and how to use it in the Microsoft Call Quality Methodology Scorecard for Lync Server document included in the ZIP file located here. Enjoy!

At the Lync Conference 2014, Andrew and I did two sessions on Call Quality Methodology (CQM):

• You Sound Marvelous Part 1 - An introduction to the Lync Call Quality Methodology
• You Sound Marvelous Part 2 - A deep dive into the Lync Call Quality Methodology SQL Queries and Data

At TechEd North America 2014 Andrew and Kent did a session on CQM. It includes a deep discussion on how to troubleshoot packet loss reported by CQM and demonstrates the scorecard we are working on.

• You Sound Marvelous: An Introduction to the Lync Call Quality Methodology

Enjoy! J

At the Lync Conference 2014 in Las Vegas Andrew and I talked about Call Quality Methodology (CQM) in two sessions. In the session on the CQM queries I used 2 SQL Queries to show streams coming from a subnet and from a given user. I've attached the queries to this post. The queries are based on the 2013 QoE schema.

Demo9.1 - Individual Streams from a Subnet

Change the time period and the subnet you are interested using the x.x.x.x notation.

Demo9.2 - Individual Streams From a URI

Change the time period. Set the variable @lyncUser1 to the SIP address of the user you are interested in with sip: prefixed. The query use @lyncUser1 as the caller. I've kep the variable @lyncUser2 to hold the SIP address of a second user in case you want to look at streams between two users. If so add and CalleeUser.URI = (@lyncUser2) to the query.

When Lync 2013 shipped we did not provide the user interface to allow the user to configure his/her picture to be available on a web site (sometimes referred as photo url). With the November 7, 2013 update to Lync 2013 we have added this capability to Lync 2013. We have also changed the layout a little bit in the My Picture options page.

The ability to configure the picture from a web address is controlled by a new ClientPolicy entry called EnablePresencePhotoOptions. It can only be set via the Lync Server Management Shell (see below for an example on how to do it).

When the entry is set to True Lync 2013 will display a 3^rd radio button in the My Pictures options page, as shown below.

The user can then select the radio button and enter the Url to the picture. The maximum size of the picture is controlled by the ClientPolicy parameter MaxPhotoSizeKB. In the screenshot below I've set this value to 1000 and that is reflected in the user interface. The picture at the Url needs to be publically available without requiring a password for accessing it.

In the first screenshot you can also see the change in the layout of the page. We are no longer showing 2 different sizes of the picture in use, just one. We will show a 200x200 pixels version of the picture, either scaled up or down as needed.

Here is an example of how to set the policy entry using Lync Server Management Shell

• $pe=New-CsClientPolicyEntry -Name EnablePresencePhotoOptions -Value True
• $po=Get-CsClientPolicy
• $po.PolicyEntry.Add($pe)
• Set-CsClientPolicy -Instance $po

The MediaLine table in the Lync 2013 QoE database contains a column called MediaLineLabel. The label specifies the media type related to the MediaLine. In Lync 2010 you have been used to seeing the values 0, 1 and 2 in the column. However in Lync 2013 you might find the additional values 3, 4, 5, 6, 7 and 8. What does these values specify?

I have shown it in the table below. The new additions are 3 for application sharing and 4 – 8 for gallery view video. The Lync 2013 client supports up to 5 video streams in the gallery view and that is why we have the values 4 – 8.

During the last 6 months my colleagues Andrew, Brandon, Kent and I have been busy documenting the Call Quality Methodology or CQM as we call it.

CQM is a holistic way to systematically define and assert call quality. CQM divides a Lync implementation into ten discrete areas that impact quality, defining targets and a remediation plan for each one. CQM is a framework to tackle call quality problems – you can modify or extend it to address the particular conditions on your network. It is based on Key Health Indicators (KHI) for server health and on QoE data reported by Lync clients and servers.

We have published it as version 2 of the Networking Guide. The download is a ZIP file containing the updated Networking Guide, the Lync 2010 KHI and the SQL queries for Lync 2010 and Lync 2013 QoE schemas. We are working on Lync 2013 KHI's and will make them available at a later time. Enjoy!

Introduction

In Microsoft Lync 2013 for Mobile release 5.2 we are introducing support for passive authentication via Active Directory Federation Services (AD FS). It enables customers to sign in using other authentication methods than Active Directory including support for users, who don't know their Active Directory password. Kaushal gives a great overview about the feature in his post here. In this post I will describe the sign-in experience for passive authentication user on Microsoft Lync 2013 for Mobile and how to configure your environment to support passive authentication.

How is the sign in experience?

Kaushal shows the sign experience on the mobile device using AD FS forms based authentication in his Figure 3. In this section I'll describe when the user has to sign in using passive authentication and when it is not necessary based on different scenarios.

There are 3 elements relevant for the sign in experience:

• Authentication token issued by AD FS after the user has authenticated
• Web ticket. The web ticket is used by the mobile app to authenticate the communication with the UCWA component on Lync Server 2013 and is issued by the Lync server after the app has presented the AD FS authentication token. The web ticket has 8 hours expiration time
• Lync client certificate. The Lync client certificate is issued by the Lync Certificate Provisioning Service to the mobile app after it has obtained a web ticket. As an administrator you can see and revoke the certificates by using Get-CsClientCertificate and Revoke-CsClientCertificate. The default Lync client certificate has a 6 month expiration time. It can be changed by setting the MaxValidityPeriodHours value on the WebService configuration.

The Save Password setting is not used when using Passive Authentication. Table 1 lists the passive authentication sign in experience behavior in different scenarios.

Table 1 Sign in experience

Device Operating System versions

The following versions of the device operating systems are recommended for use with passive authentication

• Windows Phone 8: It is recommended to use version 8.0.10211.204 or later
• iOS: 6.1 or later

Topology Requirements

In order to implement passive authentication for Microsoft Lync 2013 for Mobile users it is necessary to disable some of the other authentication methods supported by Lync 2013 Server. Lync 2013 Server offers a list of authentication methods to clients, and others methods take precedence over passive authentication. If you are not disabling these other methods they will be used to authenticate instead of passive authentication.

Table 2 shows the service type, server role and the authentication methods, which needs to be enabled and disabled for passive authentication for mobile users. Please note that these settings are NOT on a per user basis, but rather on a per pool basis. That means all users homed on a specific pool will use the settings.

Table 2 Authentication Methods

Note1: The pool running the Lync Autodiscover service, i.e. the pool pointed to by lyncdiscover.<SIP domain> and lyncdiscoverinternal.<SIP domain>, authenticates the users based on its own authentication settings and not those of the users home pool. If there is a discrepancy between the authentication methods supported on the Lync Autodiscover pool and the user home pool, the sign in experience might be non-optimal and might not work. In such scenarios it is recommended to use manual discovery configuration for either the passive authentication users or for the default authentication users.

Note2: Table 2 does not list configuration of Registrar for Edge servers. This needed for passive authentication for Microsoft Lync 2013 desktop clients, but Edge is not used by the Microsoft Lync 2013 for Mobile clients.

Functionality dependent on Microsoft Exchange

The Microsoft Lync 2013 for Mobile clients contains the following functionality dependent on Microsoft Exchange:

• Unified Contact Store (UCS)
• Meetings environment
• Voice Mail environment

The Microsoft Lync 2013 for Mobile clients does not support passive authentication against Microsoft Exchange, and therefore the device is not able to use Exchange Web Services (EWS) to connect to Microsoft Exchange and get information about meetings and voice mails. Unified Contact Store (UCS) continues to work, since the connection to Microsoft Exchange is happening via the Lync server.

It is recommend to set the AllowExchangeConnectivity parameter to $false in the CsMobilityPolicy for the passive authentication users. This will make sure that the meetings and voice mail environments are not shown on the device and that errors related to the failed communication to Microsoft Exchange are not shown on the device.

End-to-End configuration

Haven discussed the sign in experience, topology requirements and Microsoft Exchange related features it is now time to explain how to configure passive authentication end-to-end. To illustrate this I will use a fictitious environment and in it I am using AD FS as the passive authentication provider.

For the purpose of explaining the configuration of passive authentication assume the lab configuration shown in Table 3.

Table 3 Servers in the environment

All users on lync-int.contoso.dk will be configured to use passive authentication.

Reverse Proxy Configuration (ARR)

For configuration of ARR as a reverse proxy for Lync Server 2013 please see this http://blogs.technet.com/b/nexthop/archive/2013/02/19/using-iis-arr-as-a-reverse-proxy-for-lync-server-2013.aspx. Remember to change port numbers before you click Add for the server.

Table 4 shows the Server Farms and Servers defined in ARR.

Table 4 ARR Server Farms and Servers

DNS

Table 5 shows the DNS records in the internal and external DNS servers that has been configured in the environment.

Table 5 DNS records

Hair pinning

The environment supports hair pinning, that is the ability of internal computers to access external available resources via the reverse proxy. As an example internal Lync servers can connect to the AD FS server using its external DNS record.

Certificates

The environment has been configured with mutually trusted certificates containing the appropriate FQDN's as subject alternate names (SAN). The certificate used on the reverse proxy is from a public trusted root CA.

AD FS Configuration

The AD FS server has been configured for base functionality and forms based authentication has been enabled. We need to configure AD FS to have a trust relationship with Lync Server 2013. This is done by creating a Relaying Party Trust and appropriate Issuance Authorization and Transform rules. Information about the trust partner is contained in the federation metadata document.

The trust relationship means that Lync will trust credentials coming from AD FS. AD FS could have obtained them from a number of authentication providers, but in this environment we use Active Directory as authentication provider via the AD FS forms authentication.

The following section describes how to configure Active Directory Federation Services to support passive authentication with Lync Server 2013.

1. Log in to sts2012r2-int.contoso.dk using a Domain Admin account
2. Launch Windows PowerShell
3. Make sure sts2012r2-ext.contoso.dk is set as the Federation Service Name
   1. Get-AdfsProperties | fl HostName
4. Establish a trust partnership with the Lync Server 2013 Pool that will be enabled for passive authentication. For pools add the trust for both internal and external Web Services FQDN. In this environment we need to add it for lync-int.contoso.dk and lync-ext.contoso.dk. Configure it by running the following command: 

$IssuanceAuthorizationRules = '@RuleTemplate = "AllowAllAuthzRule" => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");'

$IssuanceTransformRules = '@RuleTemplate = "PassThroughClaims" @RuleName = "Sid" c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"]=> issue(claim = c);'

Add-ADFSRelyingPartyTrust -Name Lync-PassiveAuth -MetadataURL https://lync-int.contoso.dk/passiveauth/federationmetadata/2007-06/federationmetadata.xml

Set-ADFSRelyingPartyTrust -TargetName Lync-PassiveAuth -IssuanceAuthorizationRules $IssuanceAuthorizationRules

Set-ADFSRelyingPartyTrust -TargetName Lync-PassiveAuth -IssuanceTransformRules $IssuanceTransformRules

Add-ADFSRelyingPartyTrust -Name Lync-Ext-PassiveAuth -MetadataURL https://lync-ext.contoso.dk/passiveauth/federationmetadata/2007-06/federationmetadata.xml

Set-ADFSRelyingPartyTrust -TargetName Lync-Ext-PassiveAuth -IssuanceAuthorizationRules $IssuanceAuthorizationRules

Set-ADFSRelyingPartyTrust -TargetName Lync-Ext-PassiveAuth -IssuanceTransformRules $IssuanceTransformRules

Lync 2013 Server configuration

The trust between AD FS and Lync has been created on the AD FS side. We now need to create it on the Lync side. This is done by using the following command:

1. Log in to lync-int.contoso.dk using a Lync administrator account
2. Launch the Lync Server 2013 Management Shell
3. From the Lync Management Shell command-line interface, create a new Web Service configuration for lync-int.contoso.dk by running the following command: 

New-CsWebServiceConfiguration -Identity webserver:lync-int.contoso.dk -WsFedPassiveMetadataUri https://sts2012r2-ext.contoso.dk/federationmetadata/2007-06/federationmetadata.xml

After the trust now has been established from both sides we need to set the required authentication methods as shown in Table 2. From the Lync Management Shell command-line interface issue the following commands:

Set-CsWebServiceConfiguration -Identity webserver:lync-int.contoso.dk -UseWsFedPassiveAuth $true -UseWindowsAuth none –UseCertificateAuth $true

New-CsProxyConfiguration -Identity registrar:lync-int.contoso.dk -UseKerberosForClientToProxyAuth $false -UseNtlmForClientToProxyAuth $false

Final server configuration element is to create the Mobility Policy disabling Exchange connectivity. From the Lync Management Shell command-line interface issue the following command:

New-CsMobilityPolicy -Identity PassiveAuthUsers -AllowExchangeConnectivity $false

User configuration

Make sure your users are homed on lync-int.contoso.dk and then grant them the PassiveAuthUsers mobility policy. From the Lync Management Shell command-line interface issue the following command for all the relevant users: 

Grant-CsMobilityPolicy -PolicyName PassiveAuthUsers -Identity <user>

Manual Discovery configuration

The environment is now setup to support passive authentication. However since Lync Autodiscover points to a Lync pool, which has not been configured to support passive authentication, the users on lync-int.contoso.dk needs to manual configure the discovery address on the mobile device. The settings will be:

• Internal Discovery Address: https://lync-int.contoso.dk/Autodiscover/autodiscoverservice.svc/Root
• External Discovery Address: https://lync-ext.contoso.dk/Autodiscover/autodiscoverservice.svc/Root

These addresses needs to be set in the Microsoft Lync 2013 for Mobile clients by clicking on more details on the home screen, setting auto-detect server to Off and entering the relevant addresses. The relevant fields are in Figure 1.

Figure 1 Manual Discovery configuration

Troubleshooting

In order to troubleshoot the passive authentication between Microsoft Lync 2013 for Mobile, AD FS and Lync Server 2013 the best starting point is looking at the https communication between the client and the servers.

You can use the Fiddler tool for this. The tool does not run on the mobile device, but by running it on a desktop or laptop in the network, you can look at the communication. You can use similar steps as the ones here for Windows Phone 7 to do it. Please understand that the only way to remove that certificate on Windows Phone 8 is to reset the mobile device.

You can also use the Lync 2013 desktop client and Fiddler on a desktop/laptop. You start Fiddler and the Lync client, enter the SIP URI of a passive authentication user and make sure to click 'Delete my sign-in info' before clicking 'Sign in'. Based on your environment you might need to manually configure the internal and external server names (to overcome the Lync Autodiscover issue mentioned earlier).

Some things to look at in the Fiddler trace related to sign in:

• Is the client being re-directed to the AD FS in the sign in sequence via a 302 re-direct to the AD FS url? If this is not happening check the WsFedPassiveMetadataUri and that UseWsFedPassiveAuth has been set to true. The Lync server will report any errors in communicating with AD FS in the event log
• Does the returned MEX document contain the expected WsFedPassive_policy? If it lists the wrong combination check the enabled authentication methods on the WebServiceConfiguration for the pool
• Does AD FS return a reference back to the Lync pool on the virtual directory PassiveAuth/PassiveAuth.aspx after the user has signed into AD FS? If not, check the relaying party trust on AD FS
• Any 5xx errors coming back
• Are cookies disabled on the mobile device?

On the Lync server side the relevant trace component is WebInfrastructure.

In Lync 2013 we changed how we classify poor calls in QoE. The flag is called ClassifiedPoorCall and it is now available in the MediaLine table. It is moved here, because we now support classifying poor calls for audio, video and application sharing.

The conditions we use to classify poor calls are shown in the 3 tables below. The poor call flag is set if one or more the conditions are met. Please note that a record in the MediaLine table can cover multiple media streams. The flagging occurs on the MediaLine level, so if you want to understand specifically which stream was the reason for the classification you need to look at the individual streams and use the columns in the tables below.

In many scenarios you are interested in knowing how a given caller or callee was connected to the network, i.e. was it a wired or wireless connection. The information is contained in the columns CallerNetworkConnectionType and CalleeNetworkConnectionType in the MediaLine table. It is then easy to use those columns in your SQL queries. However you need to understand what values you can see in those columns and what they mean. To make it a bit more complex there are differences between the Lync 2010 and Lync 2013 QoE schemas on this point.

The Lync 2010 QoE Schema use NetworkConnectionType directly (I'll use this term to refer to both CallerNetworkConnectionType and CalleeNetworkConnectionType) and it can have the integer values 0 for wired and 1 for wireless. You can use those values directly in your SQL queries. For instance if you want to see all audio streams, where both caller and callee were connected via a wired connection, you can use a query like below:

SELECT

        *

FROM [Session] s WITH (NOLOCK)

        INNER JOIN [MediaLine] AS m WITH (NOLOCK) ON

            m.ConferenceDateTime = s.ConferenceDateTime

            AND m.SessionSeq = s.SessionSeq            

        INNER JOIN [AudioStream] AS a WITH (NOLOCK) ON

            a.MediaLineLabel = m.MediaLineLabel

            and a.ConferenceDateTime = m.ConferenceDateTime

            and a.SessionSeq = m.SessionSeq            

WHERE

        (m.CallerNetworkConnectionType = 0 and m.CalleeNetworkConnectionType = 0)

The Lync 2013 QoE Schema introduces a new table call NetworkConnectionDetail to store information about network connection type and the MediaLine columns for NetworkConnectionType are now indexes into this table. The actual network connection type values are stored as strings in the NetworkConnectionDetail column in the new table. Values you'll most likely see are 'wired', 'wifi' and 'Ethernet'. The 'Ethernet' string was introduced with Lync 2013. If you want to get the same list of wired audio streams in Lync 2013, you can use a query like below:

SELECT

        *

FROM [Session] s WITH (NOLOCK)

        INNER JOIN [MediaLine] AS m WITH (NOLOCK) ON

            m.ConferenceDateTime = s.ConferenceDateTime

            AND m.SessionSeq = s.SessionSeq            

        INNER JOIN [AudioStream] AS a WITH (NOLOCK) ON

            a.MediaLineLabel = m.MediaLineLabel

            and a.ConferenceDateTime = m.ConferenceDateTime

            and a.SessionSeq = m.SessionSeq    

        INNER JOIN [NetworkConnectionDetail] AS CallerNcd WITH (NOLOCK) ON

            CallerNcd.NetworkConnectionDetailKey = m.CallerNetworkConnectionType

        INNER JOIN [NetworkConnectionDetail] AS CalleeNcd WITH (NOLOCK) ON

            CalleeNcd.NetworkConnectionDetailKey = m.CalleeNetworkConnectionType

WHERE

        CallerNcd.NetworkConnectionDetail in ('wired','Ethernet')

        and CalleeNcd.NetworkConnectionDetail in ('wired','Ethernet')

So now alarm bells should be going off, when you read the above, because you'll ask yourself: will all my existing queries using the filter directly on the MediaLine columns (as above) have to be changed? Yes and No is the answer J

No, because if you are only testing on 0 and 1, the NetworkConnectionDetail table is pre-populated with two rows: index 0 = 'wired' and index 1 = 'wifi'. This is done for backwards compability reasons.

Yes, you'll have to change your queries, because the 'Ethernet' strings was introduced in Lync 2013 and many components use that to specify a wired connection. For portability between deployments it is also more correct to use the string comparison filter than filtering directly on index values.

In QoE we store information about sessions and different type of media streams, but how many of these do we store for a conference scenario?

Let me answer that question by using the following scenario:

• July 11, 2013 tu14@contoso.dk drags tu26@contoso.dk and tu29@contoso.dk into a conference and they both accepts it
• tu14 adds audio to the conference
• Later tu14 adds application sharing to the conference
• tu14 stops application sharing
• tu14 adds video to the conference all tu26 and tu29 accepts and joins with their video started
• The conference ends

How many sessions do this scenario generate in the QoE database? To answer the question I use the following SQL query in SQL Management Studio connected to the QoEMetrics database in the Lync 2013 Monitoring Store:

SELECT s.ConferenceDateTime

,s.ConferenceKey

,CallerUser.URI as Caller

,CalleeUser.URI as Callee

FROM [QoEMetrics].[dbo].[Session] s WITH (NOLOCK)

        INNER JOIN [User] AS CallerUser WITH (NOLOCK) ON

            CallerUser.UserKey = s.CallerURI

        INNER JOIN [User] AS CalleeUser WITH (NOLOCK) ON

            CalleeUser.UserKey = s.CalleeURI

WHERE s.ConferenceDateTime > '2013-07-11'

The select statement joins information from the Session and User tables. The result of this query is shown below. It shows 6 sessions: 1 session from each three participants to the AV MCU (conferencing server for audio and video) and 1 session from each three participants to the AS MCU (conferencing server for application sharing).

So how many audio streams do we have? To answer the question I use the following SQL query in SQL Management Studio connected to the QoEMetrics database in the Lync 2013 Monitoring Store:

SELECT s.ConferenceDateTime

,s.ConferenceKey

,CallerUser.URI as Caller

,CalleeUser.URI as Callee

     ,a.SenderIsCallerPAI

FROM [QoEMetrics].[dbo].[Session] s WITH (NOLOCK)

        INNER JOIN [MediaLine] AS m WITH (NOLOCK) ON

            m.ConferenceDateTime = s.ConferenceDateTime

            AND m.SessionSeq = s.SessionSeq            

        INNER JOIN [AudioStream] AS a WITH (NOLOCK) ON

            a.MediaLineLabel = m.MediaLineLabel

            and a.ConferenceDateTime = m.ConferenceDateTime

            and a.SessionSeq = m.SessionSeq            

        INNER JOIN [User] AS CallerUser WITH (NOLOCK) ON

            CallerUser.UserKey = s.CallerURI

        INNER JOIN [User] AS CalleeUser WITH (NOLOCK) ON

            CalleeUser.UserKey = s.CalleeURI

WHERE s.ConferenceDateTime > '2013-07-11'

The select statement joins information from the Session, MediaLine and AudioStream tables to give me the result shown below. It shows 6 audio streams. Two audio streams between each participant and the AV MCU: one from the user to the AV MCU and one from the AV MCU to the user (SendIsCallerPAI shows the direction).

How many application sharing streams do we have? To answer the question I use the following SQL query in SQL Management Studio connected to the QoEMetrics database in the Lync 2013 Monitoring Store:

SELECT s.ConferenceDateTime

,s.ConferenceKey

,CallerUser.URI as Caller

,CalleeUser.URI as Callee

     ,ap.SenderIsCallerPAI

FROM [QoEMetrics].[dbo].[Session] s WITH (NOLOCK)

        INNER JOIN [MediaLine] AS m WITH (NOLOCK) ON

            m.ConferenceDateTime = s.ConferenceDateTime

            AND m.SessionSeq = s.SessionSeq            

        INNER JOIN [AppSharingStream] AS ap WITH (NOLOCK) ON

            ap.MediaLineLabel = m.MediaLineLabel

            and ap.ConferenceDateTime = m.ConferenceDateTime

            and ap.SessionSeq = m.SessionSeq            

        INNER JOIN [User] AS CallerUser WITH (NOLOCK) ON

            CallerUser.UserKey = s.CallerURI

        INNER JOIN [User] AS CalleeUser WITH (NOLOCK) ON

            CalleeUser.UserKey = s.CalleeURI

WHERE s.ConferenceDateTime > '2013-07-11'

The select statement joins information from the Session, MediaLine and AppSharingStream tables to give me the result shown below. It shows 6 app sharing streams. Two app sharing streams between each participant and the AS MCU: one from the user to the AS MCU and one from the AS MCU to the user (SendIsCallerPAI shows the direction).

How many video streams do we see? To answer the question I use following SQL query in SQL Management Studio connected to the QoEMetrics database in the Lync 2013 Monitoring Store would show it:

SELECT s.ConferenceDateTime

,s.ConferenceKey

,CallerUser.URI as Caller

,CalleeUser.URI as Callee

    ,v.SenderIsCallerPAI

FROM [QoEMetrics].[dbo].[Session] s WITH (NOLOCK)

        INNER JOIN [MediaLine] AS m WITH (NOLOCK) ON

            m.ConferenceDateTime = s.ConferenceDateTime

      ��     AND m.SessionSeq = s.SessionSeq            

        INNER JOIN [VideoStream] AS v WITH (NOLOCK) ON

            v.MediaLineLabel = m.MediaLineLabel

            and v.ConferenceDateTime = m.ConferenceDateTime

            and v.SessionSeq = m.SessionSeq            

        INNER JOIN [User] AS CallerUser WITH (NOLOCK) ON

            CallerUser.UserKey = s.CallerURI

        INNER JOIN [User] AS CalleeUser WITH (NOLOCK) ON

            CalleeUser.UserKey = s.CalleeURI

WHERE s.ConferenceDateTime > '2013-07-11'

The select statement joins information from the Session, MediaLine and VideoStream tables to give me the result shown below. It shows 9 video streams. Three video streams between each participant and the AV MCU: one from the user to the AV MCU and one per conference attendee in the gallery view from the AV MCU to the user. In my case there was 2 attendees in the gallery view.

Conclusion

In a conference there is a session from each participant to each media conferencing server being used (IM is not a real media conferencing server and therefore it is not generating a session). For each session there will be two or more media streams. For audio and application sharing you will always have two, but for video you can have more due to gallery view in Lync 2013 with up to five video streams and the panorama view video stream (for more information about the video streams see this post by Jeff Schertz).

We released the update yesterday and it is found here. Until now it has not been easy for an administrator to see if a given user had been migrated to UCS, but with the update we introduced the cmdlet Debug-CsUnifiedContactStore!

The cmdlet will show the UCS status for a given user or for all users on a pool. The user needs to be homed on a pool running the July update for the cmdlet to work, since it is using a new server based interface to get the status. An example of running the cmdlet is below:

Debug-CsUnifiedContactStore -Identity tu34@contoso.dk

UcsMigrationAttemptCount LastUcsMigrationAttempt SipUri           UcsMode

------------------------ ----------------------- ------           -------

                       2 3/20/2013 1:00:00 PM    tu34@contoso.dk Migrated

The cmdlet shows how many attempts have been made to migrate the user, when the last attempt was made, the SIP URI of the user and the UcsMode of the user. UcsMode can have the values:

• Disabled – the UserServicesPolicy does not allow UCS
• Allowed - the UserServicesPolicy allows UCS
• Migrating – the user is being migrated
• Migrated – the user has been migrated

You can also use it to see the general UCS status for all users on a given pool. An example of this is shown below:

Debug-CsUnifiedContactStore -PoolFqdn pool.contoso.dk

FrontEnd          : pool.contoso.dk

UcsDisabledCount  : 8

UcsAllowedCount   : 0

UcsMigratingCount : 0

UcsMigratedCount  : 2

FailedUserData    :

You can also use the cmdlet to export the UCS contacts for a migrated user by using –ContactDataExportFileName. The cmdlet will read the UCS contacts from Exchange 2013 and save them in the ZIP file used as parameter.

PS C:\> Debug-CsUnifiedContactStore -Identity tu34@contoso.dk –ContactDataExportFileName c:\ucs1.zip

UcsMigrationAttemptCount LastUcsMigrationAttempt SipUri           UcsMode

------------------------ ----------------------- ------           -------

                       2 3/20/2013 1:00:00 PM    tu34@contoso.dk Migrated

The ZIP file contains two files as shown in the picture below. The actual contacts are stored in an XML format in the file DocItemSet.xml.

Sasa and I presented this session at TechEd 2013 in Madrid. In the deck we show the results of running 3 custom SQL queries against the QoE data. The query from slide 44 (Individual Poor Streams Wired to MS and AVMCU per Subnet v13.txt) and the query from slide 49 (Individual Poor Streams Wireless to MS and AVMCU per Subnet v13.txt) are attached to this post in the queries.zip file. The trending query from slide 48 is discussed in this post.

The queries are sample queries, comes "as-is" and I'm not providing any support for them.

Each query is its own text file. You run one of the queries by copying all the text from the query text file into a New Query window inside SQL Management Studio connected to your QoE database. You then change the @beginTime and @endTime to suit your requirements and execute the query.

Please consider the impact running these queries might have in your environment depending on your amount of QoE data and the date range you select.

The queries are developed based on the Lync 2013 QoE Schema.

(Queries updated Sep 11, 2013 to be in line with http://blogs.technet.com/b/jenstr/archive/2013/09/11/how-to-determine-network-connection-type-in-qoe-queries.aspx)

When you start working with device information in QoE you might find that there is an issue around the naming of devices.

The different Lync client reports the name of the device used for capture and rendering in the QoE report sent to the Monitoring Server. However the name is based on the device name in the operating system. That name might contain localized text and different ordinals based on which USB port the device was connected to on the device. This means that you might end up having a number of different devices seen in QoE, but they are actually all the same type of device.

To illustrate the issue let us assume that you would like to know the AvgSendListenMOS value for all devices over all audio streams in a period of time. You create the necessary SQL query against QoE data and it output something like the sample shown in Table 1.

Table 1. Example of different device names in QoE data

You can see that all these streams actually used the same device, GN 2000 USB OC, but viewed from QoE they are different because of the naming. So how can this be changed to report on just the specific devices?

In this post I'm suggesting a solution based on a PowerShell script to extract the specific device names from the QoE data and store them in a SQL table called TrimDeviceNames in a database called QoEMetricsUtil. You can then use the TrimDeviceNames SQL table in your queries.

Populating the TrimDeviceNames table by running TrimDeviceNamesV10.ps1

The solution use a database called QoEMetricsUtil. You have to create that database before running the PowerShell script.

The attached DeviceQuality.ZIP file contains the TrimDeviceNamesV10.ps1 PowerShell script and it does the following:

• Connects to your monitoring server database and reads all device names out of the Device table
• Extracts the specific device names (please see note below!)
• Drops and Creates the TrimDeviceNames table in the QoEMetricsUtil database
• Stores all the specific device names in the TrimDeviceNames table

As new devices are being used in your deployment you will have to re-run the script to pick-up the new specific device names.

The script has the following mandatory parameters:

• -SqlServerForQoE – the SQL server name hosting your monitoring database
• -SqlServerInstanceForQoE – the SQL server instance name hosting your monitoring database
• -SqlServerForQoEMetricsUtil – the SQL server name hosting the QoEMetricsUtil database
• -SqlServerInstanceForQoEMetricsUtil – the SQL server instance name hosting the QoEMetricsUtil database

An example of running the script is: TrimDeviceNamesV10.ps1 -SqlServerForQoE sql1 -SqlServerInstanceForQoE rtc -SqlServerForQoEMetricsUtil sql1 -SqlServerInstanceForQoEMetricsUtil rtc

You need to run it with an account having appropriate permissions to the Lync monitoring database and to the QoEMetricsUtil database.

Using the TrimDeviceNames table

In your device related queries against QoE data you can now use the TrimDeviceNames table. The way the specific device name is extracted assumes that the resulting device name is a sub-string of the original device name. Based on this assumption you can use sub-string matches to join TrimDeviceNames on CallerCaptureDeviceName and CalleeCaptureDeviceName.

Query to show device quality using TrimDeviceNames table

The output shown in Table 1 was generated by a query reporting AvgSendListenMOS value for all devices over all audio streams in a period of time. I have changed that query to use the TrimDeviceName table. An example of the output of running this changed query is shown Table 2

Table 2. Example of output from DeviceQualityNormalizedV13.txt using TrimDeviceNames table

You can see that there is now just one device name row for GN 2000 USB OC and it covers all audio streams using that type of device.

The full query is attached in the DeviceQuality.zip file in the file DeviceQualityNormalizedV13.txt. You run the query by copying all the text from the file into a New Query window inside SQL Management Studio connected to your QoE database. You then change the @beginTime and @endTime to suit your requirements and execute the query.

Notes and Caveats

This is not solution, which will cover all device names out there. The string extraction logic in the PowerShell script is built around the assumption that the specific device name is contained within parentheses in the device name (as shown in Table 1 for GN 2000 USB OC). The logic will most likely need to be changed based on the actual devices used in your Lync deployment. I have only tested with a limited set of device names and there are other string combinations out there. My recommendation is to run the PowerShell script once, and then examine all the resulting rows in the TrimDeviceNames table. If any of them look odd then you have to change the logic in the script to handle that kind of string as well.

The query expects the QoEMetricsUtil database to be in the same SQL instance as the monitoring server database.

The use of sub-string matches might not cover all device names used in your deployment. If the sub-string match does not work for a device name any streams using that device will not appear in the query output.

The PowerShell script has no built-in error handling.

Please consider the impact, running the script and query, might have in your environment depending on your amount of QoE data and the date range you select.

The query is developed against the Lync 2013 QoE schema.

The script and query are sample, comes "as-is" and I'm not providing any support for them.

Acknowledgements

Thanks to Henk.

In this I discussed how to view network health trends using QoE data. In this post I'll describe some queries you can use to help you diagnose where you might have network health issues in your Lync deployment.

The first query is the Streams Statistics query. The query will tell you the maximum, standard deviation and average for PacketLossRate and PacketLossRateMax across all your audio streams. This will give you an idea where the health is compared to the poor streams definition of packet loss rate over 1 percent and a maximum packet loss rate over 5 percent. An example of the output of the query is shown in Table 1.

Table 1. Sample output from Streams Statistics query

Next you'll probably want to dive into the different media paths to investigate where the poor streams are coming from. I'll use the media path between conferencing and mediation servers in the following examples.

To understand more about the streams between conferencing and mediation servers you can use the Poor Streams between Conferencing and Mediation Servers query. The query will tell you per day the number of streams, number of poor streams and the poor streams ratio for all streams between conferencing and mediation servers. An example of the output of the query is shown in Table 2.

Table 2. Sample output from Poor Streams between Conferencing and Mediation Servers query.

Having seen the different pairs of servers you might want to dive into the individual streams between two specific conferencing and mediation server, i.e. between FE2 and FE3 in the example on Table 2. To do that you can use the Individual Poor Streams between Two Servers query. The query will list a number of media related values from all streams between the two servers you specify in the query.

Table 3. Sample output from Individual Poor Streams between Two Servers

I hope that you based on these sample queries can develop your own diagnostics queries to gain further understanding of potential causes of poor network health.

Running the queries

The queries are located in the attached DiagnosticsQueries.Zip file. The queries are sample queries, comes "as-is" and I'm not providing any support for them.

Each query is in its own text file. You run one of the queries by copying all the text from the query text file into a New Query window inside SQL Management Studio connected to your QoE database. You then change the @beginTime and @endTime to suit your requirements and execute the query. For the query between two servers you need to replace the placeholder server name with the real names from your deployment in capital letters.

Please consider the impact running these queries might have in your environment depending on your amount of QoE data and the date range you select.

Notes

It is not possible to run multiple of the queries in the same Query window in SQL Management Studio.

Queries are developed using the Lync 2013 QoE schema.

(Updated queries Sep 11, 2013 to be in line with http://blogs.technet.com/b/jenstr/archive/2013/09/11/how-to-determine-network-connection-type-in-qoe-queries.aspx)

Introduction

In the newly published Networking Guide the authors, in Appendix B, discuss using custom queries against QoE data to manage audio call quality. They introduce the concepts of server-server reports, which present the network health of network paths between various types of Lync media servers, and subnet reports, which present the network health of network paths between Lync desktop clients and various types of Lync media servers.

The network health is expressed by the number of poor audio streams, where a poor stream is defined as having a packet loss rate over 1 percent and a maximum packet loss rate over 5 percent. For a discussion on why to use these values (and not the ClassifiedPoorCall values) please see the section B.4.4 in the Networking Guide.

In this blog post I'm reusing the reports (or queries) they introduce, but have modified them a bit. I wanted to have queries, which would allow me to show how the network health is trending day-over-day for media paths between additional types of end-points. The idea is to run these queries regularly while any network health problems are remediated and then hopefully see the resulting downward trend for poor streams.

Media paths

The media paths from the Network Guide are:

• Between conferencing servers and mediation servers
• Between mediation servers and IP PSTN gateways
• Between desktop clients and conferencing & mediation servers

I wanted to include these additional media paths:

• Between Lync clients
• Between Lync clients and other Lync server end-points
• Between conferencing and mediation servers and other Lync server end-points
• Between other Lync server end-points
• Between Lync clients and 3^rd party end-points

Having described which media paths are interesting let us look at the queries themselves.

Query output

The queries are built in the same way as in the Networking Guide, i.e. with INNER JOIN's, temporary views and audio streams from Caller and Callee.

The queries all display the same type of information: date, number of streams, the number of poor streams and the ratio of poor streams to total streams. An example is shown in Table 1 below.

Table 1. Sample output

Query structure

The elements that varies from query to query is the type of media end-point, how the end-point is connected to the network and the location of these end-points. I'm varying over 3 variables:

• UAType. The UAType specifies the type of end-point in the media path (represented by the UserAgent table column UAType). Examples are Conferencing Server (AVMCU), Mediation Server (MS) and Lync desktop client. By looking at the media streams between different UATypes you can get information about the audio streams used in the different scenarios, i.e. person-to-person calls or persons calling into an audio conference. The list of UATypes used in the queries are shown in Table 3
• Network Connection Type. This specifies the type of network connection used by the end-point, either wired or wireless (represented by the MediaLine table columns CallerNetworkConnectionType and CalleeNetworkConnectionType)
• Location. This specifies the location of the end-point, either Inside or Outside (represented by the MediaLine table columns CallerInside and CalleeInside). Outside means connected via the Edge

As an example let us look at the scenario where users are dialing in to audio conferences from PSTN or the audio conference dials out to PSTN users. This scenario involves conferencing servers talking to mediation servers. How can that be expressed using the 3 variables above?

The UAType for conferencing servers is 2 and for mediation servers it is 1. I assume that all conferencing and mediation servers are connected to the network using a wired connection, and that they are all placed inside on the corporate network. This gives us a query using the 3 variables which would look the following way in pseudo-code

• Get me all audio streams from (Caller with UAType 2, network connection type = wired and Inside) to (Callee with UAType 1, network connection type = wired and Inside)
• Get me all audio streams from (Caller with UAType 1, network connection type = wired and Inside) to (Callee with UAType 2, network connection type = wired and Inside)

The queries

Having described the different media paths, the UAType, network connection type and location it is now time to combine these into queries. When I created the queries I wanted to separate inside and outside streams, since typically outside or external streams would be using networks outside the control of the company. I also wanted to separate wired from wireless streams, because typically wireless streams provides worse quality than wired streams. I wanted to separate person-to-person calls, but have combined several of the streams to other server type media end-points into the same query.

Table 2 shows the different queries and the media path, end-point, network connection and location they cover for both Caller and Callee.

Table 2. Query definitions

The UAType groups I am using above are defined in Table 3 below.

Table 3. UAType groups

Running the queries

The queries are located in the attached TrendQueries.Zip file. The queries are sample queries, comes "as-is" and I'm not providing any support for them.

Each query is its own text file. You run one of the queries by copying all the text from the query text file into a New Query window inside SQL Management Studio connected to your QoE database. You then change the @beginTime and @endTime to suit your requirements and execute the query.

Please consider the impact running these queries might have in your environment depending on your amount of QoE data and the date range you select.

Summary

I hope you can use the queries to get an understanding of your network health expressed by the packet loss rate and max packet loss rate experienced during Lync audio calls.

Notes

As can be seen from Table 2 above the queries all utilize the location and connection type. For some audio streams these columns can contain NULL values. In order to make sure that the Total query is the actual sum of the other queries, it only reports streams, where these columns have the values used by the other queries. That means streams with NULL values for location and connection type are not surfaced by the queries.

The queries are not handling streams over VPN separately.

It is not possible to run multiple of the queries in the same Query window in SQL Management Studio.

The queries are developed using the Lync 2013 QoE Schema.

(Updated Sep 11, 2013 to be in line with http://blogs.technet.com/b/jenstr/archive/2013/09/11/how-to-determine-network-connection-type-in-qoe-queries.aspx)

In this post we announced the Skype-Lync connectivity. One of the screenshots in the post shows adding the Skype contact in the Lync 2013 client using Add a Contact Not in My Organization .

In the fly-out Skype is listed with the Skype logo. The Lync client get the list via in-band provisioning from the server based on the enabled public providers. To add Skype to the list issue the following commands on the Lync server in Lync 2013 Lync Server Management Shell:

• Remove-CsPublicProvider -identity MSN
• New-CsPublicProvider -ProxyFqdn federation.messenger.msn.com -VerificationLevel UseSourceVerification -Enabled $true -Identity Skype -IconUrl https://images.edge.messenger.live.com/Messenger_16x16.png

Wait for CMS replication and sign out and in again in the Lync client. Skype should now be in the list.

Update 9-AUG-2013: Lync 2013 clients connecting to Lync 2010 servers will not show Skype in the add contact drop-down list. This is caused by Lync 2010 server not supporting the in-band provisioning group sending the list of public providers to the client.

When you are participating in a Lync meeting with 75 and more participants the experience will change to optimize the experience. The client will remove the participant list (roster), the gallery view will not be available and IM errors will not be displayed. The client will display the notification shown below.

In the title line of the conference window we will show the number of participants in the meeting. The presenters in the meeting will still get the participant list, such that they can take actions on the attendees.

We will not re-instate the normal user experience, even if the number of participants drops below 75. The experience will stay the same until the conference has ended.

The above change in user experience is not directly related to large meeting support in Lync 2013. It happens regardless of large meeting being enabled in the conferencing policy.

When I participate in Lync Meetings, I often hear the above sentence, when someone is presenting a PPT deck, the whiteboard, their desktop or a program. However, there is really no need for this, since the presenter (and the rest of the people in the meeting) can see from the roster or participant list, who can see the content. The color of the icon represents the modality status of the participant:

• Grey means that the participant is not connected to the modality
• Blue means that the participant is connected to the modality
• Turquois means that the participant is currently sending this modality

In Figure 1 below the first participant is currently sending both audio and content, but has not started video. The second participant is connected to audio and content, but has muted the microphone. The third and fourth participant are connected to both audio and content. However the fifth participant is connected to audio, but is not connected to the content.

Figure 1 Modality Status

You might have the situation that you are receiving Lync Meeting invites from federated partners using Exchange 2013 and Lync 2013, but when Outlook 2013 or OWA 2013 CU1 brings up the reminder dialog for the meeting, the Join button is missing. Outlook and OWA will show the Join button based on the existence of the MAPI property OnlineMeetingExternalLink on the calendar item representing the meeting in the attendee's mailbox.

It is the Lync Meeting Outlook add-in used by the organizer of the meeting, which sets the property on the meeting invite, before it is sent. However the MAPI property might be stripped from the message, when it is sent from the organizers Exchange 2013 environment to your, i.e. the meeting attendee, Exchange 2013 environment. You need to ensure that in the organizer's Exchange 2013 environment, the remote domain matching your Exchange 2013 environment, has the parameter TNEFEnabled set to True (http://technet.microsoft.com/en-us/library/bb232174.aspx#External). When TNEFEnabled is set to true Exchange 2013 does not strip MAPI properties including OnlineMeetingExternalLink and the Join button will be shown on the reminder.

Let us assume that the SMTP domain of the attendee is contoso.com. In the organizer's Exchange 2013 environment it is necessary to create a remote domain with TNEFEnabled = True representing contoso.com. One way of doing it is by using the following commands in Exchange Management Shell:

• New-RemoteDomain -Name contoso.com -DomainName contoso.com
• Set-RemoteDomain -Identity contoso.com -TNEFEnabled:$true

One of the new features in Exchange 2013 CU1 is support for creation of Online Meetings in Outlook Web App (OWA). When you create a new event in OWA you can click on Online meeting, and the meeting is created as an Online meeting. You can also update an existing event to be an Online meeting. See Figure 1 for a screenshot showing the Online meeting button.

Figure 1 Creating an Online Meeting

Prerequisites

In order for this feature to work, the following needs to be in place:

• The scheduling user needs to be Lync enabled and homed on a Lync 2013 pool
• The mailbox of the scheduling user needs to be hosted on Exchange 2013 CU1
• Server to Server authentication (S2SOAuth) needs to be configured between Exchange 2013 and Lync 2013
• The Lync Autodiscover service needs to be configured (http://technet.microsoft.com/en-us/library/hh690030.aspx) with DNS records for lyncdiscover.<SIP domain> and lyncdiscoverinternal.<SIP domain>

How it works

OWA use the Unified Communications Web API (UCWA) interface to create the Online Meeting. When OWA boots, and whenever you create a new event in Calendar tab, OWA checks, if UCWA is enabled for the user. OWA uses the Lync Autodiscover service to find the user's pool and the UCWA Url. If UCWA is enabled (happens automatically if the user is homed on a Lync 2013 pool) OWA shows the Online meeting button.

The communication between OWA and Lync happens via Server to Server OAuth (S2SOAuth).

When the Online meeting button is clicked, OWA is creating the Online Meeting. It sets the parameters used for the meeting based on the relevant CsMeetingConfiguration setting (Global, Site or Service scope) in Lync 2013. The parameters used are:

• PstnCallersBypassLobby
• LogoUrl¹
• LegalUrl²
• HelpUrl
• CustomFooterText

In addition to these parameters, it creates the meeting with the options that all company employees joins as presenters and bypass the lobby.

You are able to join the Online Meeting from the OWA calendar peek via the Join button (see Figure 2). You can also join from the Calendar read form (see Figure 3).

Figure 2 Calendar peek with Join button

Figure 3 Calendar read form with the Join button

Configuration

Let me show how to configure the integration. I will use the following sample environment to illustrate the configuration:

• One Exchange 2013 CU1 Client Access server with FQDN e15fe.contoso.com
• One Exchange 2013 CU1 Mailbox server with FQDN e15be.contoso.com.
  • The test user has Exchange 2013 CU1 mailbox with the primary SMTP address test1@contoso.com
• One Lync Server 2013 Enterprise Edition pool with one Lync Server 2013 Front End Server lyncfe1.contoso.com
  • Pool FQDN is lync.contoso.com.
  • One test user is enabled with SIP URI test1@contoso.com
• A DNS record for autodiscover.contoso.com points to e15fe.contoso.com
• A DNS record for lyncdiscoverinternal.contoso.com points to lync.contoso.com
• The url pointing to legal text is https://web.contoso.com/legalurl.txt
• The url pointing to help text is https://web.contoso.com/helpurl.txt
• The custom Contoso logo is https://web.contoso.com/logo.jpg

Step 1: Exchange 2013 Autodiscover Service

Configure the Exchange 2013 Autodiscover service to be available on the FQDN autodiscover.contoso.com. Use the following Exchange Management Shell command on e15fe.contoso.com.

Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://autodiscover.contoso.com/autodiscover/autodiscover.xml

Step 2 Exchange S2SOAuth configuration with Lync

We now need to configure the Exchange 2013 side of things. Use the following Exchange Management Shell commands:

• cd \Program Files\Microsoft\Exchange Server\V15\Scripts>
• .\Configure-EnterprisePartnerApplication.ps1 -AuthMetadataUrl https://lync.contoso.com/metadata/json/1 -ApplicationType Lync

Step 3 Lync S2SOAuth configuration with Exchange

We now configure the Lync side of things. Use the following Lync Server Management Shell commands:

• New-CsPartnerApplication -identity Exchange -ApplicationTrustLevel Full -MetadataUrl https://autodiscover.contoso.com/autodiscover/metadata/json/1
• Set-CsOAuthConfiguration -Realm contoso.com

Step 4 Lync Meeting Configuration

We now configure the Lync meeting configuration for the pool. Use the following Lync Server Management Shell commands:

• Set-CsMeetingConfiguration –LegalURL https://web.contoso.com/legalurl.txt
• Set-CsMeetingConfiguration –HelpURL https://web.contoso.com/Helpurl.txt
• Set-CsMeetingConfiguration –HelpURL https://web.contoso.com/Helpurl.txt
• Set-CsMeetingConfiguration –LogoURL https://web.contoso.com/logo.jpg
• Set-CsMeetingConfiguration –CustomerFooterText "This is the footer text"

Troubleshooting

In situations, where the Online meeting button does not appear or the creation of the Online meeting fails, the administrator will have to enable logging in OWA to get diagnostic information about the potential issues. Logging is enabled by editing the web.config file in C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa on the Exchange 2013 CU1 mailbox server and changing the line <add key="OWAIsLoggingEnabled" value="false" /> to <add key="OWAIsLoggingEnabled" value="true" />. After saving the changed web.config, recycle the MSEXchangeOWAAppPool in IIS Manager for OWA to pick up the change. OWA will now log information to log files in the directory C:\Program Files\Microsoft\Exchange Server\V15\Logging\OWA\server\.

Ask the user to repro the problem and examine the log file in the directory above. Look for lines with the keywords GetUcwaUserConfiguration and CreateOnlineMeeting and timestamps matching the repro. Hopefully he information in the log file can point to the root cause of the issue.

1. In Exchange 2013 CU1 the logo will only be shown, if the CustomFooterText has text in it
2. In Exchange 2013 CU1 the hyper link for the legal URL will always be empty no matter, if it is set or not

Office Web Apps Server 2013 provides the ability to create a farm with one or more machines in it. Recently I had to create a farm with two machines, and it took a little bit to get my head around how to do it. Here is how I ended up doing it

I had the following environment:

• Two servers: wac1.contoso.dk and wac2.contoso.dk
• The internal fqdn of the farm should be wac.contoso.dk and the external fqdn should be wacext.contoso.dk
• Hardware load balancer configured for wac.contoso.dk

On wac1.contoso.dk

I did the following steps:

• Installed Office Web Apps Server 2013 and the March 12, 2013 update.
• Used the MMC certificate snap-in to create a certificate from my internal CA based on WebServer template with:
  • Subject name WacFarm
  • Friendly name WacFarm
  • Subject alternate names of wac1.contoso.dk, wac2.contoso.dk,wac.contoso.dk,wacext.contoso.dk, wac1 and wac2
  • Allow private key to be exported
• After the certificate was loaded in the personal local computer certificate store, I exported the certificate with the private key to a file
• Used PowerShell to create the Office Web Apps Farm with the cmd:
  • New-OfficeWebAppsFarm -InternalURL https://wac.contoso.dk -ExternalURL https://wacext.contoso.dk -CertificateName WacFarm -Verbose -AllowHttp:$true

On wac2.contoso.dk

I did the following steps:

• Installed Office Web Apps Server 2013 and the March 12, 2013 update
• Used the MMC certificate snap-in to import the certificate, I had exported on wac1.contoso.dk, into the personal local computer certificate store
• Used PowerShell to join wac2 to the Office Web Apps Farm, which has wac1.contoso.dk as the Master
  • New-OfficeWebAppsMachine -MachineToJoin wac1.contoso.dk

The tricky part to get right was the last command. You have to run it on the machine you wish to join to the farm, and you have to reference an existing machine in the farm. It needs the reference to be able to read the farm settings.

We have made an update available for the Office Web Apps Server 2013 (used by Lync 2013 for PowerPoint presentations). The update is from March 12, 2013, and is available at http://support.microsoft.com/kb/2760445. It is important that you follow our guidance on how to install the update. The guidance is available at http://technet.microsoft.com/en-us/library/jj966220.aspx.