http://blogs.technet.com/b/scottstu/archive/2015/04/16/potential-impact-on-lync-and-skype-for-business-meeting-join-experience-when-google-chrome-is-the-default-browser.aspx

Since that time Microsoft has published updates for all on-premises server versions as well as updating all online tenants which changes the meeting join to work as seamless as with any other supported browser (without any special configuration of NPAPI).

The following table shows the minimum build that contains the NPAPI fix as well as the direct link for where to download the updates from.

In order for this change to take effect you need to ensure that you patch the server or pool of servers which hosts the meeting simple url in your environment to the correct version as noted above.

Microsoft has published a KB article describing this behavior and is working on a server-side solution that does not require you to use NPAPI to join a meeting. When a solution to this problem is released, the KB article will be updated with additional information.

When will the user experience be impacted?

It is important to understand the scope of this issue. If a user is using Microsoft Outlook 2013 and primarily joining meetings organized with the same company they are unlikely be impacted. It is when a certain set of circumstances are in play that the user experience will be impacted.

The user experience will be impacted when the following conditions are true:

• Google Chrome is configured as the default browser.
• Google Chrome is upgraded to version 42 or later.
• The user clicks the "Join Lync Meeting" or "Join Skype Meeting" link on a meeting that meets one of the following criteria: 
  • The join meeting link was presented within any application that is not Outlook 2013. (I.e. a web browser, an email, etc.)
  • The meeting join information was not created using the Outlook Lync or Skype for Business meeting plugin. (I.e. the meeting organizer copied the meeting invite from somewhere else and pasted it into the invite, the meeting was scheduled from the web scheduler, etc.)
  • The meeting invitation was sent by an organizer from another organization that has not configured the option to preserve the Transport Neutral Encapsulation Format (TNEF) for outgoing emails. This is likely the default experience when joining a meeting scheduled from another organization.

An easy way to indicate if this is the case is that you won't get the option join the meeting when right clicking on the meeting invite in the Outlook 2013 calendar view. Figure 1 shows the experience of a meeting that will not be impacted by the change in Google Chrome. Figure 2 shows a way of indicating a meeting that would be effected by the change in Good Chrome.

Figure 1: Outlook 2013 experience when Lync meeting has the proper metadata

Figure 2: Outlook 2013 experience when the meeting does not have the Lync meeting metadata

Similarly, you will not get the join option in the meeting environment view of the Lync or Skype for Business client. Figure 3 shows the difference as seen in the Lync 2013 client meetings experience.

Figure 3: Lync 2013 client meeting experience showing the difference between meetings that have Lync meeting metadata

What is the user's experience when they meet the above criteria?

When a user clicks the 'Join Lync Meeting' or 'Join Skype Meeting' hyperlink they are directed to the Lync Web App or Skype for Business Web App. They are prompted to install the plugin or are joined to the meeting using the web experience.

Figure 4: Google Chrome Lync Web App prompt to install the plug-in

Figure 5: Google Chrome Lync Web App prompt to join the meeting via LWA

This is a change in previous experience where the locally installed Lync or Skype for Business client would be launched and joined to the meeting.

Options to override this behavior in Google Chrome

There are two options that can be used to override this behavior in Chrome. The first is a manual client side override that would be configured on each user's Chrome browser. The second override is configured by an enterprise administrator via Group Policy objects that enables the same functionality. Additional background on these overrides can be found here.

Manual override for Enabling NPAPI

Google has provided steps for manually adjusting the NPAPI setting in the Chrome browser. These steps work for both Chrome on Windows and Chrome on Mac.

1. Open Google Chrome and enter the following address: chrome://flags/#enable-npapi  

Figure 6: Google Chrome configuration option to enable NPAPI plugins when configured with the default value

1. Under Enable NPAPI Click on Enable

Figure 7: Google Chrome configuration option when the NPAPI plugins are enabled

1. Close all Chrome browser instances.
2. Click on the meeting join URL and NPAI detection will be enabled however the join launcher plug-in will still be blocked. There will be a warning message allowing you to allow the specified URL.

Figure 8: Google Chrome experience when a web page NPAPI plugins are enabled and a website tries to run the plug-in

1. Select Always allow plugin-ins on meet.lync.com (or whatever the meeting join URL is that you are connecting to).

If you choose to configure a list of websites in advance of receiving the warning message, you can complete the following steps.

1. Open Google Chrome and enter the following address: chrome://settings/contentExceptions#plugins
2. Enter a URL as follows: https://meet.lync.com
3. Select allow
4. You will need to add an additional entry for every meeting join URL that you wish to connect to.

Figure 9: Google Chrome configuration options to specify URLs were plug-ins are allowed to run

Enterprise override for Enabling NPAPI

Google has provided pre-configured Group Policy templates that can be loaded in the Group Policy Management console to control behavior of the Chrome browser for Windows computers. The following section describes how to setup and configure this group policy.

1. Download the Google Chrome policy templates can be found at: http://www.chromium.org/administrators/policy-templates
2. Follow the instructions at Jack Stromberg's blog to load the policies.
3. Create a new Group Policy object and configure the following values

• Policy #1 - Enable NPAPI:
  • Navigate to "Computer Configuration\Policies\Administrative Templates\Google\Google Chrome\Specify a list of enabled plugins"
  • Add "NPAPI" to the list of enabled plugins.

  

  Figure 10: Group Policy setting enabling the NPAPI plug-in

• Policy #2 - Configure allowed join URLs
  • Navigate to "Computer Configuration\Policies\Administrative Templates\Google\Google Chrome\Content Settings\Allow plugins on these sites"
  • The plugin must be allowed to run on an allowed list of websites. An entry should be made for all known URLs for internal, federated, and Lync Online meeting URLs.

Figure 11: Group Policy setting specifying the URLs where plug-ins are allowed to run

In Summary

We want you to understand the potential user impact of the Google Chrome browser update and how to restore the previous user experience. Please comment with any questions and we would be happy to address. Again, it is important to know that the user experience can be different depending on the meeting that will be joined including how and who organized the meeting. We expect Google Chrome browser changes will not impact the majority of your meetings. We hope this article helps to explain when and how the meeting join will be impacted.

The good news is that regardless of whether you are using Lync Online or Lync Server, you have the ability to control when the updated experience is rolled out to your users.

The attached PowerPoint presentation provides details on how you can control the client experience with Skype for Business. The document builds on the information provided on this blog - http://blogs.office.com/2015/04/01/whats-new-in-skype-for-business-and-how-you-can-take-control-of-updates/?garage=true and provides prescriptive guidance for all possible server and UI combinations.

4/13/2015 Update - We have updated the attached PowerPoint file to include an additional option for controlling the UI in Lync Online. Please review the updated deck for additional details.

4/14/2015 - The client updates have now been published and can be found here:

Skype for Business 2015 desktop client (lyncmso)
http://support.microsoft.com/KB/2889923

Skype for Business 2015 desktop client (lynclochelp)
http://support.microsoft.com/KB/2889853

Note: The two links above are still working their way through the system, so please be patient if they are not immediately available.

Please download the latest PowerPoint file from here:

Controlling the Client Experience with Skype for Business_v1.2.pptx

I work with many customers and partners on Skype for Business and Lync and one of the areas that I focus on is online meetings. One question that comes up quite frequently is "can I use my Skype for Business or Lync client to join a meeting anonymously".

In short the answer is "yes" however there are many different situations and scenarios that both the meeting attendee and the meeting organizer may find themselves in. The purpose of this blog is to better explain how this anonymous join process works and to give the reader as much detail and background as I can on all the different things that you need to think about when looking at the process of joining a meeting anonymously.

Skype for Business and Lync (both 2013 and 2010 and Lync for Mac) can be used to join meetings anonymously if you are already signed in with your own Skype for Business or Lync account. This anonymous join scenario is only needed if you are trying to join a meeting hosted by a company that you are not federated with. Here is an overview of how this works is as follows:

• Client sends an INVITE message to your front end server with a request to join a meeting
• Server determines that you are not federated with the domain that the meeting organizer resides in
• Server responds with a SIP message and Diagnostic code indicating that you are not federated with the organizer's domain
• Client interprets the SIP message and Diagnostic code and decides if it should try to join anonymously
• Client does a DNS lookup to determine where to send the anonymous INVITE to
• Client sends an anonymous INVITE to the meeting organizer's Edge server in an attempt to join the meeting
• Client joins you to the meeting as an anonymous user and the word "Guest" appears next to your name in the meeting roster

There are actually many combinations of meeting join scenarios and they all differ depending on where the meeting attendee and organizer are homed. Each of these different combinations will produce a slightly different set of log files on the client however ultimately each one of them should result in either a meeting join or a successful anonymous join. This blog post focuses on the sip invite portion anonymous meeting join and does not cover media connectivity for audio and video. I will cover that part in a future blog post.

If you are interested to see how anonymous join works when you have a Lync 2013 client that is not signed in please see my previous my blog post on anonymous join via LWA - http://blogs.technet.com/b/scottstu/archive/2014/10/30/lync-2013-now-supports-falling-back-to-the-lync-web-app.aspx as we will not be covering that scneario here.

Requirements

The meeting attendee's client must be

• Able to look up SRV records in the meeting organizer's DNS domain if they are using SRV records for remote user access or must be able to look up A (host) records if the meeting organizer's company is using A (host) records for remote user access
• Able to connect directly to meeting organizer's edge server via the remote access port (typically 443 but sometimes 5061)
• Able to trust the certificate presented by the meeting organizer's edge server
• Running an appropriate client that supports anonymous join fallback (Lync 2013, Lync 2010 and Lync for Mac)

The meeting organizer's organization must have the following configuration

• Have anonymous meetings enabled for the meeting organizer
• Allow remote user access on their access edge server on the port defined in their SRV record or via port 443 or port 5061
• Have appropriate SRV records or A (host) records configured in their external DNS server
• Have configured an appropriate certificate on their edge server that is issued via a public certificate authority

Anonymous join walk through

In this section we will discuss the steps that the client takes in order to join a meeting anonymously and we will review it step by step looking at an example.

The original meeting invite that the client sends to join a federated meeting is sent via its own front end server however if the user is connected via an Edge server then the message will be sent via the Edge. The user's front end server will determine if the user is enabled for federation or not. If they are not enabled the front end server sends back a SIP response that contains a specific ms-diagnostics value.

In this section we will walk through an example meeting join sequence where you will see the meeting attendee is karen@contoso.com and the meeting organizer is garth@tailspintoys.com.

SIP Message 1 shows a partial segment of the original invite sent by Karen to Garth.

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

03/30/2015|13:36:59.928 16EC:1030 INFO :: Sending Packet – 209.216.129.2:443 (From Local Address: 192.168.1.200:52952) 2067 bytes:

03/30/2015|13:36:59.928 16EC:1030 INFO :: INVITE sip:garth@tailspintoys.com;gruu;opaque=app:conf:focus:id:2Z92HZZZ SIP/2.0

Max-Forwards: 70

From: <sip:karen@contoso.com>;tag=9004006031;epid=23c6af65b1

To: <sip:garth@tailspintoys.com;gruu;opaque=app:conf:focus:id:2Z92HZZZ>

CSeq: 1 INVITE

Contact: <sip:karen@contoso.com;opaque=user:epid:LKHrZjUoxV66Oi8tgk1A9gAA;gruu>

User-Agent: UCCAPI/15.0.4701.1000 OC/15.0.4701.1000 (Microsoft Lync)

Supported: ms-dialog-route-set-update

Supported: timer

Supported: histinfo

Supported: ms-safe-transfer

Supported: ms-sender

Supported: ms-early-media

ms-keep-alive: UAC;hop-hop=yes

Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY, OPTIONS

Content-Type: application/cccp+xml

Content-Length: 1008

<?xml version="1.0"?>

<request xmlns="urn:ietf:params:xml:ns:cccp" xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions" C3PVersion="1" to="sip:garth@tailspintoys.com;gruu;opaque=app:conf:focus:id:2Z92HZZZ" from="sip:karen@contoso.com" requestId="387792480"><addUser>

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

SIP Message 1 – Invite sent by karen@contoso.com to join a meeting organized by garth@tailspintoys.com

As you can see in SIP Message 1 the from: tag shows karen@contoso.com while the to: tag shows garth@tailspintoys.com and the message is being sent to IP address 209.216.129.2 which is the IP address of Karen's edge server.

At this point Karen's front end server determines that federation is not enabled and sends the response that you can see in SIP Message 2 below.

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

03/30/2015|13:28:27.682 16EC:1030 INFO :: Data Received -209.216.129.2:443 (To Local Address: 192.168.1.200:52952) 1033 bytes:

03/30/2015|13:28:27.682 16EC:1030 INFO :: SIP/2.0 504 Server time-out

ms-user-logon-data: RemoteUser

Authentication-Info: TLS-DSK qop="auth", opaque="21A773E9", srand="5EA20BA7", snum="33", rspauth="e4e881d3db7c97b7b49d552966315c3b5d0481d6", targetname="server.contoso.com", realm="SIP Communications Service", version=4

Via: SIP/2.0/TLS 192.168.1.200:52952;received=42.157.86.172;ms-received-port=52952;ms-received-cid=2C00

Content-Length: 0

From: "Karen Berg"<sip:karen@contoso.com>;tag=0fa5a85424;epid=23c6af65b1

To: <sip:garth@tailspintoys.com;gruu;opaque=app:conf:focus:id:2Z92HZZZ>;tag=BA6EAB929067DF296876B3B74D35748D

Call-ID: ab166f84d6db431c8c461da04d3c3407

CSeq: 1 INVITE

ms-diagnostics: 1017;reason="Cannot route From and To domains in this combination";summary="Cannot route between the source and destination domains because partner discovery is not enabled";external-domain="tailspintoys.com";external-type="domain-type-remote";internal-domain="contoso.com";internal-type="domain-type-local";source="sipfed.contoso.com"

Server: RTC/5.0

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

SIP Message 2 – Server response received by karen@contoso.com.

Karen's client receives a SIP 504 response code along with a 1017 diagnostic code and now knows that it should invoke the anonymous join process.

In general the client examines the SIP response and diagnostic code it receives back and triggers the anonymous join process if it finds a valid response code OR a valid ms-disagnostics code.

All valid response and ms-diagnostic codes are shown below in Table1:

Table 1 – Valid response and ms-diagnostic codes

Now that the client has decided to join anonymously it must determine where to deliver the new anonymous meeting invite to. The client leverages the same functionality that would be used by to sign in to Skype for Business as a remote user in the meeting organizer's domain.

If you look in the sip traces of the client log file you will notice that Karen's client has started to query DNS to determine how to deliver this anonymous invite. Trace Message 1 below shows the first record that Karen looks for.

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

QueryDNSSrv - DNS Name[_sipinternaltls._tcp.tailspintoys.com]

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

Trace Message 1 – DNS query for _sipinternaltls record

Karen's client will continue querying these DNS records until it is successful in finding a destination. The DNS records that it will search are:

• _sipinternaltls._tcp.tailspintoys.com
• _sip._tls.tailspintoys.com
• sipinteral.tailspintoys.com
• sip.tailspintoys.com
• sipexternal.tailspintoys.com

If it receives a result for the SRV record it will use the port that was provided however if it only succeeds in matching an A record the client will try to connect on port 443 and then on port 5061.

In our example Karen's client receives a DNS response for _sip._tls.tailspintoys.com which returns a host record of sip.tailspintoys.com on port 5061. Karen's client then resolves the value of sip.tailspintoys.com to the IP address 206.555.123.456.

SIP Message 3 shows a partial segment of the anonymous invite sent by Karen to Garth.

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

03/30/2015|13:37:01.769 16EC:1030 INFO :: Sending Packet - 206.555.123.456:5061 (From Local Address: 192.168.1.200:53025) 2050 bytes:

03/30/2015|13:37:01.769 16EC:1030 INFO :: INVITE sip:garth@tailspintoys.com;gruu;opaque=app:conf:focus:id:2Z92HZZZ SIP/2.0

Via: SIP/2.0/TLS 192.168.16.221:53025

Max-Forwards: 70

From: "Karen Berg" <sip:36825c7a-a4ea-430b-aa85-e8aa6ee97ebc@anonymous.invalid>;tag=1152deba20;epid=4edd74c4be

To: <sip:garth@tailspintoys.com;gruu;opaque=app:conf:focus:id:2Z92HZZZ>

CSeq: 1 INVITE

Contact: <sip:36825c7a-a4ea-430b-aa85-e8aa6ee97ebc@anonymous.invalid>;proxy=replace;+sip.instance="<urn:uuid:CC4F4797-4760-58C5-8CAB-8AB72E4546BC>"

User-Agent: UCCAPI/15.0.4701.1000 OC/15.0.4701.1000 (Microsoft Lync)

Supported: ms-dialog-route-set-update

Supported: timer

Supported: histinfo

Supported: ms-safe-transfer

Supported: ms-sender

Supported: ms-early-media

ms-keep-alive: UAC;hop-hop=yes

Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY, OPTIONS

Content-Type: application/cccp+xml

Content-Length: 1121

<?xml version="1.0"?>

<request xmlns="urn:ietf:params:xml:ns:cccp" xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions" C3PVersion="1" to="sip:garth@tailspintoys.com;gruu;opaque=app:conf:focus:id:2Z92HZZZ" from="sip:36825c7a-a4ea-430b-aa85-e8aa6ee97ebc@anonymous.invalid" requestId="387813728"><addUser>

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

SIP Message 3 – Anonymous Invite sent by karen@contoso.com to join a meeting organized by garth@tailspintoys.com

As you can see in SIP Message 3, the from: tag shows 36825c7a-a4ea-430b-aa85-e8aa6ee97ebc@anonymous.invalid while the to: tag still shows garth@tailspintoys.com. The message is being sent to IP address 206.555.123.456 which is the IP address of Garth's tailspintoys.com edge server. You will also notice that Karen's client has extracted her display name and sent that in the from: tag which is how her name will appear in the roster when she has joined the meeting as shown in Figure 1 below.

Figure 1 – Meeting window showing Karen joined as a Guest

That is all there is to it! We have walked through a step by step example that shows how the anonymous meeting join works.

Common Meeting Join Scenarios

As you may have noticed in the above example I didn't specifically say where the meeting attendee and the meeting organizer were homed. Lync (and soon to be Skype for Business) is available in both an on-premises version via Lync Server 2013 or Lync Server 2010 as well as in a service model via Lync Online. There are many scenarios in which a user may be trying to join a meeting that is organized by a user in another organization that is hosted in a different domain.

Table 2 below shows some of the most common combinations of meeting join scenarios.

Table 2 – Meeting join scenarios

The reason that it is important to understand these various scenarios is due to the fact that the SIP response codes returned by the meeting attendee's registrar server will vary depending on whether the user is homed on-premises or if they are homed online. The response received will also vary depending on how the federation setting is configured in both environments.

We will now look at 4 specific combinations of meeting attendee/organizer.

Scenario 1

		Meeting Organizer On-premises Lync 2013 tailspintoys.com
		Federation enabled from contoso.com	Federation disabled from contoso.com
Meeting Attendee On-premises Lync 2013 Contoso.com	Partner domain discovery disabled Tailspintoys.com not allowed	Anonymous join works RC - 504 Ms-diag – 1017	Anonymous join works RC - 504 Ms-diag – 1017
	Partner domain discovery disabled Tailspintoys.com allowed	Federated join works	Anonymous join works RC - 504 Ms-diag – 1034
	Partner domain discovery enabled Tailspintoys.com not allowed	Federated join works	Anonymous join works RC - 504 Ms-diag – 1034
	Partner domain discovery enabled Tailspintoys.com allowed	Federated join works	Anonymous join works RC - 504 Ms-diag – 1034
	Partner domain discovery enabled Tailspintoys.com blocked	Anonymous join works RC - 504 Ms-diag – 1064	Anonymous join works RC - 504 Ms-diag - 1064

Table 3 – Scenario 1

ms-diagnostics: 1017;reason="Cannot route From and To domains in this combination";summary="Cannot route between the source and destination domains because partner discovery is not enabled";external-domain="tailspintoys.com";external-type="domain-type-remote";internal-domain="contoso.com";internal-type="domain-type-local";source="sipfed.contoso.com"

ms-diagnostics: 1034;reason="Previous hop federated peer did not report diagnostic information";Domain="tailspintoys.com";PeerServer="sip.tailspintoys.com";source="sipfed.contoso.com"

ms-diagnostics: 1064;reason="Cannot route to blocked domain";domain="tailspintoys.com";suffix="tailspintoys.com";source="sipfed.contoso.com"

Scenario 2

		Meeting Organizer Lync Online contoso.onmicrosoft.com
		Federation enabled from contoso.com	Federation disabled from contoso.com
Meeting Attendee On-premises Lync 2013 Contoso.com	Partner domain discovery disabled contoso.onmicrosoft.com not allowed	Anonymous join works RC – 504 Ms-diag – 1028	Anonymous join works RC – 504 Ms-diag - 1028
	Partner domain discovery disabled contoso.onmicrosoft.com allowed	Federated join works	Anonymous join works RC- 504 Ms-diag - 1036
	Partner domain discovery enabled contoso.onmicrosoft.com not allowed	Federated join works	Anonymous join works RC- 504 Ms-diag - 1036
	Partner domain discovery enabled contoso.onmicrosoft.com allowed	Federated join works	Anonymous join works RC- 504 Ms-diag - 1036
	Partner domain discovery enabled contoso.onmicrosoft.com blocked	Anonymous join works RC - 504 Ms-diag – 1064	Anonymous join works RC - 504 Ms-diag - 1064

Table 4 –Scenario 2

Note – The results shown in Table 4 above assume that you have configured a hosting provider pointed to sipfed.online.lync.com. If you do not have this hosting provider configured then some of the scenarios may produce different results.

ms-diagnostics: 1028;reason="Domain resolved by DNS SRV to a configured hosting service but the domain is not in the allow list";domain="contoso.onmicrosoft.com";fqdn1="sipfed.online.lync.com:5061";source="sipfed.contoso.com"

ms-diagnostics: 1036;reason="Previous hop shared address space peer did not report diagnostic information";Domain="contoso.onmicrosoft.com";PeerServer="sipfed.online.lync.com";source="sipfed.contoso.com"

ms-diagnostics: 1064;reason="Cannot route to blocked domain";domain="contoso.onmicrosoft.com";suffix="contoso.onmicrosoft.com";source="sipfed.contoso.com"

Scenario 3

		Meeting Organizer On-premises Lync 2013 Contoso.com
		Federation enabled from contoso.onmicrosoft.com	Federation disabled from contoso.onmicrosoft.com
Meeting Attendee Lync Online contoso.onmicrosoft.com	On only for allowed domains contoso.com not allowed	Anon join works RC – 504 Diag – 27000	Anon join works RC – 504 Diag – 27000
	Off Completely	Anon join works RC – 403 Diag – 1002	Anon join works RC – 403 Diag – 1002
	On except for blocked domains contoso.com not blocked	Federated join works	Anon join works RC – 504 Diag – 1034

Table 4 –Scenario 3

ms-diagnostics: 1002;reason="From URI not authorized to communicate with federated partners";from-uri="garthf@contoso.onmicrosoft.com";destination="karenb@contoso.com";source="sipfed0A.online.lync.com"

ms-diagnostics: 1034;reason="Previous hop federated peer did not report diagnostic information";Domain="contoso.com";PeerServer="sipfed.contoso.com";source="sipfed0A.online.lync.com"

ms-diagnostics: 27000;reason="To-Uri Domain is not in the sender-tenant allow list";source="SN20A05FES03.INFRA.LYNC.COM";appName="OutgoingFederation"

Scenario 4

		Meeting Organizer Lync Online tailspintoys.onmicrosoft.com
		Federation enabled from contoso.onmicrosoft.com	Federation disabled from contoso.onmicrosoft.com
Meeting Attendee Lync Online Contoso.onmicrosoft.com	On only for allowed domains contoso.com not allowed	Anonymous join works RC – 504 Diag – 27000	Anonymous join works RC – 504 Diag – 27000
	Off Completely	Anonymous join works RC – 403 Diag – 1002	Anonymous join works RC – 403 Diag – 1002
	On except for blocked domains contoso.com not blocked	Federated join works	Anonymous join works RC – 403 Diag – 4033

Table 5 –Scenario 4

ms-diagnostics: 1002;reason="From URI not authorized to communicate with federated partners";from-uri="garthf@contoso.onmicrosoft.com";destination="bonniek@tailspintoys.onmicrosoft.com";source="sipfed0A.online.lync.com"

ms-diagnostics: 4033;reason="To User not authorized for Federation";processing-cluster="sippooldm21a05.infra.lync.com";processing-frontend="DM21A05FES06.infra.lync.com";target-user-primary-pool="sippooldm21a05.infra.lync.com";source="DM21A05FES06.infra.lync.com"

ms-diagnostics: 27000;reason="To-Uri Domain is not in the sender-tenant allow list";from-uri="garthf@contoso.onmicrosoft.com";destination="bonniek@tailspintoys.onmicrosoft.com";source="sipfed0A.online.lync.com"

Federation Configuration

The various meeting join scenarios described above showed various federation configuration settings so we will now describe how to configure each of them.

On premises Configuration – Allowing Domain Federation

There are methods that a Lync on-premises administrator can use in order to configure an "allowed" domain for federation. The following section will cover those different methods and provide details on how to configure each.

Partner Domain Discovery

In this scenario the administrator can allow "partner domain discovery" which means that the target domain is not added directly but rather it is allowed to be discovered. The partner company must publish an SRV record for _sipfederationtls._tcp.domain.com in order for this to work.

To do this navigate to the "Access Edge Configuration" tab that is located under the Federation and External Access tab in the Lync Server control panel and check the box next to Enable partner domain discovery as shown in Figure 2 below.

Figure 2 – Configuring partner domain discovery

Allowed Domain

If you choose not to enable partner domain discovery as documented above then you should navigate to the "Access Edge Configuration" tab that is located under the Federation and External Access tab in the Lync Server control panel and uncheck the box next to Enable partner domain discovery as shown in Figure 3 below.

Figure 3 – Disabling partner domain discovery

If you have disabled partner domain discovery then you must specifically add the federated domain to the SIP Federated Domains tab as shown in Figure 4 below where we have allowed contoso.com.

Figure 4 – Allow domain federation with contoso.com

On premises Configuration – Blocking Domain Federation

There are three ways to block domain federation and which one you choose depends on whether or not you want to block federation completely or whether or not you want to block it for a specific domain.

1. Uncheck the Enable federation and Public IM connectivity check box under the Access Edge Configuration tab.

If you choose this option then you are blocking federation for all domains and can't turn on or off a specific domain. To do this uncheck the box next to Enable federation and public IM connectivity as shown in Figure 5 below.

Figure 5– Disabling federation and public IM connectivity

2. Disable partner domain discovery and not allow a specific domain

If you choose this option you should uncheck the box next to Enable partner domain discovery as shown in Figure 6 below. With this configuration set and no domains configured in the SIP Federated Domains tab then you have disabled federation with all domains.

Figure 6– Disabling partner domain discovery

3. Enable partner domain discovery but block a specific domain

If you choose this option you should check the box next to Enable federation and public IM connectivity as shown in Figure 7 below.

Figure 7 – Configuring partner domain discovery

You should also add the domain that you want to block to the list under SIP Federated Domains as shown in Figure 8 below.

Figure 8 – Adding northwindtranders.com as a blocked domain

Online Configuration – Allowing Domain Federation

There are a few ways to allow domain federation in Lync Online.

1. On except for blocked domains

To allow federation to all domains you should navigate to the organization/external communications tab in the Lync Admin center and select On except for blocked domains as shown in Figure 9 below.

Figure 9 – Configuring On except for blocked domains access in Lync online admin center

2. On only for allowed domains

To allow federation in an online tenant you should navigate to the organization/external communications tab in the Lync Online control panel and select "On only for allowed domains" as shown in Figure 9 below. You also need to specifically add the domain to the list of allowed domains as shown in Figure 10 below.

Figure 10 – Configuring On only for allowed domains in Lync online admin center

Note: When making changes to the external access configuration in Lync Online the changes do not take effect immediately. It can take up to 30 – 45 minutes for the changes to take effect.

Configuring Anonymous Meeting Access

On-premises configuration

To configure anonymous meeting join on a user's conferencing policy navigate the Conferencing tab on Lync Server Control Panel. From there go to the Conferencing Policy sub tab and make sure to check the box next to All participants to invite anonymous users.

Figure 11 – Configuring anonymous user access

If you try to join a meeting as an anonymous user and the meeting organizer has not been assigned a conferencing policy that enables permits anonymous join as show in Figure 11 above then you will get an error as shown in Figure 12 below.

Figure 12 – Anonymous join error message

Conclusions

I hope that this document has helped you understand the anonymous join process that exists in the Lync client today and the required configuration pieces that need to be in place to make it work. Please review the blog post and let me know you have any thoughts/comments as I do read them all and will make adjustments if needed.

Special thanks to the Boston MTC for their support in my testing of these scenarios.

Thanks for reading.

Scott

We recently made a change to the Lync 2010 client to better support the situation where a Lync 2010 user is trying to view a PowerPoint document that was uploaded by a Lync 2013 web app user.

The change was first introduced in a hotfix for Lync 2010 version 4.0.7577.4456 so if you install any version that was released after that your Lync client will contain this change.

You can find a link to this hotfix here - http://support2.microsoft.com/kb/3006209. Any future cumulative updates should contain this hotfix.

Challenge

Prior to this change the experience was as follows:

The user clicks on a meeting link or pastes the link into a browser and joins a meeting where a Lync 2013 Web App User has uploaded a PowerPoint.

Upon joining the meeting the Lync 2010 user sees the following message.

Clicking on the "Join" button simply launches the join launcher again which simply calls Lync 2010

More details can be found at this link - http://support2.microsoft.com/kb/2890167

Resolution

After the change the experience is as follows:

The user clicks on a meeting link or pastes the link into a browser and joins a meeting where a Lync 2013 Web App User has shared a PowerPoint.

Upon joining the meeting the Lync 2010 user sees the following message.

When click on the "Rejoin" button the Lync Web App will be launched with ?sl= at the end of the meeting URL which will instruct the client to join via the browser where they will be able to see the content.

If you join Lync Web App as an authenticated user the Lync 2010 client will be disconnected from the meeting.

Conclusion

This change will improve the meeting experience for a user running Lync 2010 when they are trying to view a presentation that was uploaded by a Lync 2013 Web App user. Please check it out in your environments and let us know if you have any feedback.

This configuration change will disable the user's ability to upload PowerPoint documents from the Lync 2013 client as well as the Lync Web App.

The required configured configuration to disable this in Lync Web App is described at the following URL:

http://support.microsoft.com/kb/2978444

After you apply the update you need to change the user's conferencing policy using this cmdlet

Set-CsConferencingPolicy DisablePPT -AllowOfficeContent $False

After you have applied this change the affected user will no longer be able to upload a PowerPoint file in their meeting.

Note:

You need to be running a minimum client version of 15.0.4615.1000 in order for the client to properly interpret this configuration change.

The default configuration for the WebService configuration is as follows:

Get-CsWebServiceConfiguration | select UseDomainAuthInLWA | fl

UseDomainAuthInLWA : True

When this default is in place you will see the ability to "Sign in if you are from the organizer's company"

If you want to remove the ability for LWA users to authenticate you can make the following configuration change.

set-CsWebServiceConfiguration -UseDomainAuthInLWA $False

Get-CsWebServiceConfiguration | select UseDomainAuthInLWA | fl

UseDomainAuthInLWA : False

Once you have made this change you will see LWA appears as follows:

Notes:

This change applies to users connecting to LWA from internally as well as externally.

We recently made a change to the Lync 2013 client to support the ability to fall back to the Lync Web App in the event that a user has Lync installed but has never signed in. This was frequently a challenge because various versions of Office 2013 come with Lync 2013 installed by default. There are ways that IT pros and administrators can control this however many installations include Lync 2013 by default.

The change was first introduced in Lync 2013 version 15.0.4623.1001 so if you install any version that was released after that your Lync client will contain this change. You can find a link to the most recent Lync updates at the following URL: http://technet.microsoft.com/en-us/office/dn788954.aspx.

Challenge

Prior to this change the experience was as follows:

The user clicks on a meeting link or pastes the link into a browser

The Lync join launcher page will start up and detect that the user has Lync installed locally

Lync launches and since the user has never signed in stops processing any further. It doesn't provide an error message or description of why you can't join the meeting.

Resolution

After the change the experience is as follows:

The user clicks on a meeting link or pastes the link into a browser

The Lync join launcher page will start up and detect that the user has Lync installed locally

At this point Lync will start up and detect that the user is not signed in and will close.

When Lync closes a new browser window launches where the meeting can now be joined via the Lync Web App.

At this point the user can type in a Guest name and can join the meeting.

Notes

This update should automatically be available to any user that is running Office 365 ProPlus or any user that is running Office 2013 Professional Plus and is receiving automatic updates. If you do not see this behaviour ensure that you are running a Lync version greater than 15.0.4623.1001.

This does not change the existing behaviour of the Lync client which automatically launches and signs you in automatically if you click to join a meeting. The change described in this post only impacts user profiles that have never previously signed in to Lync.

This change was made primarily to support users who had legitimately never signed in to Lync before. If you want to clean up a profile though you should be able to delete HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Lync and then you will get the behaviour described above.

Conclusion

With this change we have overcome a significant meeting join challenge. Please review the change, check it out in your environments and provide us with your feedback.

These new capabilities have been added for the purpose of supporting high fps in particular for the sharing of CAD/CAM dynamic models or other similar type of content when network bandwidth is plentiful (such as on LAN or well provisioned WAN). They are not generally needed or desirable for sharing Office documents or static content. They are also not advisable where network bandwidth is already constrained.

The conferencing policy discussed below will be leveraged by the Lync 2013 desktop client and any connections from the Lync Web App 2013. Anonymous participants will inherit the organizer's policy.

Enable High Frame Rate Peer to Peer Desktop Sharing

Lync Server version 5.0.8308.420 (July 2013) introduced a setting to increase the frame rate used in peer to peer desktop sharing sessions by adding the EnableHighPerformanceP2PAppSharing parameter to the clientpolicy object.

You can create a new client policy and set the parameter by using the following syntax:

New-CSClientPolicy -Identity tag:HighFpsTrue -EnableHighPerformanceP2PAppSharing $true

Note: When you use this syntax to create a new clientpolicy object you will see a warning as shown below.

You can update an existing client policy by setting the parameter use the following syntax:

set-CSClientPolicy -Identity tag:MyExistingClientPolicy -EnableHighPerformanceP2PAppSharing $true

Note: When you use this syntax to update a clientpolicy object to enable High Performance app sharing you will see a warning as shown below.

Enable High Frame Rate Multi-party Conference Desktop Sharing

Lync Server version 5.0.8308.556 (October 2013) introduced a setting to increase the frame rate used in multi-party conference desktop sharing sessions by adding the EnableHighPerformanceConferencingAppSharing parameter to the clientpolicy object.

You can create a new client policy and set the parameter by using the following syntax:

New-CSClientPolicy -Identity tag:ConfHighFpsTrue -EnableHighPerformanceConferencingAppSharing $true

You can update an existing client policy by setting the parameter use the following syntax:

set-CSClientPolicy -Identity tag: MyExistingClientPolicy -EnableHighPerformanceConferencingAppSharing $true

An astute blog reader might notice that you are controlling a conferencing feature via a parameter of the clientpolicy object and that reader would be correct however this is how the configuration works so there are no typos in the above syntax.

If you wanted to create a single policy and set both parameters at the same time you would use the following syntax:

new-CSClientPolicy -Identity tag:HighFpsTrue –EnableHighPerformanceP2PAppSharing $true -EnableHighPerformanceConferencingAppSharing $true 

If you wanted to update an existing client policy and set both parameters at the same time you would use the following syntax:

set-CSClientPolicy -Identity tag: MyExistingClientPolicy –EnableHighPerformanceP2PAppSharing $true -EnableHighPerformanceConferencingAppSharing $true 

Note: You will only be able to set both parameters on the clientpolicy object at the same time if your Lync Server environment has been updated to at least version 5.0.8308.556.

If you want to verify that a user is receiving the correct client policy when logging on you can search for the following in the sip trace file.

<property name="EnableHighPerformanceP2PAppSharing" >false</property>

<property name="EnableHighPerformanceConferencingAppSharing" >false</property>

How do I know who to apply the High Performance policies to?

• In a peer to peer desktop sharing session the user sharing the content must have the applicable client policy applied to them in order to share content at increased frame rates and for the optimal viewing experience, the viewer should have the appropriate policies applied as well
• In a conference only the person sharing the content must have the applicable client policy applied to them (this applies to authenticated users in Lync Web App as well)
• Anonymous sharers will honour the organizer's policy
• Federated sharers will honour the settings given to them by their own company

   

Understanding and Configuring the Desktop Sharing Frame Rate

Simply enabling the high frame rate option in the client policies as shown above is not sufficient for actually increasing the frame rate used by the desktop sharing feature. In addition to implementing the changes above you also need to implement a change that increases the allowed frame rate. When the client policy settings (EnableHighPerformanceConferencingAppSharing or EnableHighPerformanceP2PAppSharing) are turned off, the frame rate will be capped to 2.5 fps max however if either are enabled the fps max will increase based on the values specified in the conferencing policy as shown below.

You can create a new conferencing policy and set the increased frame rate by using the following syntax:

New-CSConferencingPolicy -Identity tag:HighAppSharingBitRate -AppSharingBitRateKb 13000

You can then grant this new conferencing policy to a user by using the following syntax:

Grant-CSConferencingPolicy -Identity sip:user@domain.com tag:HighAppSharingBitRate

Your next logical question should be to ask: "What should I set the AppSharingBitRateKb value to and what type of network bandwidth should I expect to see as a result of this change.

The following table shows an approximation of the fps that you should expect. Please note that these values were derived from internal testing of the feature and the results in your particular environment may vary based on current network conditions and the type of content being shared. They are not absolute values or limits however they represent estimates.

The actual fps that the client will yield will be based on a number of factors such as:

• Network conditions - High bandwidth and low latency network will yield the best fps which low bandwidth and or high latency networks will cause a decrease in fps
• Content - If you have more rapidly changing content on the screen you will see a lower fps value however if the content is static you will see a higher fps value

Additional Points

• If the sharer is using the Lync Desktop client they must be using build 15.0.4551.1005 or higher

Summary

As the above blog post has shown we have made some changes to allow a Lync administrator more control over the frame rate that is produced during a Lync desktop/application sharing session. Please test this out in your labs or customer environments and share your feedback on how it is working for you.

Companies that deploy Lync Enterprise Voice (EV) have the ability to easily leverage the "delegate" scheduling feature. However, customers that don't deploy EV do not get to take advantage of the delegate functionality.

A delegate scheduler should be able to schedule a Lync meeting on behalf of their boss/manage even if both users are not enabled for Enterprise Voice.

Detailed Description of the Problem

We will walk through an example of delegation without EV and show how it works without administrative interaction.

In this example we have two users named Player2 (Manager) and Player3 (Delegate). As you can see in Figure 1 below, Player2 has shared his Outlook calendar with Player3.

Figure 1 - Player2 Delegation Configuration

Player3 is now eligible to create meetings on behalf of Player2.

Figure 2 - Player3 schedules a meeting for Player2

So far everything is working as expected.

The issue arises when Player3 attempts to schedule a Lync meeting on behalf of Player2.

Figure 3 - Error message when Player3 tries to schedule a Lync meeting

As you can see in Figure 3 above, Player3 receives an error that they do not have delegate permissions for Player2. These particular delegate permissions are in addition to the mailbox delegate permissions that are needed.

The issue here is that Player2 is not enabled for Enterprise voice and therefore has no ability to alter his delegates list.

Solution Overview

The solution that we will describe in this blog post involves the Lync administrator using the SEFAUtil administrative tool to configure Player 3 as a delegate for Player2. This solution will enable Player3 to be configured as a delegate for Player2 while neither user is enabled for Enterprise Voice. This solution requires some administrative input but it is scalable and allows the configuration to be easily changed after the fact.

Detailed Description of the Solution

This configuration requires that you are running a minimum build of 8308.577 of the SEFAUTIL that is available via the following URL: http://www.microsoft.com/en-ca/download/details.aspx?id=36821.

This document will only cover the delegation configuration using SEFAUtil and it will not cover the actual Lync server configuration required to make the SEFAUtil work. For detailed steps on how to enable SEFAUtil please see this blog post (http://blogs.technet.com/b/jenstr/archive/2010/12/07/how-to-get-sefautil-running.aspx).

In this sample configuration we will start with two users named Player2 and Player3 that are not EV users and do not have delegation in Lync configured. At this point we assume that the Exchange delegation has already been completed (http://office.microsoft.com/en-us/outlook-help/allow-someone-else-to-manage-your-mail-and-calendar-HA102749417.aspx) and that the EnableExchagneDelegateSync parameter has not been set on any client policies. The reason that we choose not to use this option is that Exchange Delegate sync is a one way sync only in that when someone is removed as an Exchange delegate they are not automatically removed as a Lync delegate.

Figure 4 - Player2 signed in to Lync

Figure 5 - Player3 signed in to Lync

As you can see in Figure 4 and Figure 5 above, both users are not enabled for Enterprise voice and as a result do not have the ability to manage their call forwarding settings and the delegate access feature.

The following steps assume that you have configured the Lync infrastructure (see note earlier in this document) to support the SEFAUtil and are now ready to configure the delegate relationship between these two users.

Open a command prompt and type the following command syntax (in this example pool01.p52.local has already been configured as a trusted application pool to run the SEFAUtil application)

SEFAUtil.exe /server:pool01.p52.local player2@p52.ca /adddelegate:player3@p52.ca

Once the command completes you should see output such as what is shown below.

User Aor: sip:player2@p52.ca

Display Name: Player2

UM Enabled: True

Simulring enabled: False

Simultaneously Ringing Delegates: sip:player3@p52.ca

You should now see a change in the Lync client for both Player2 and Player3.

Figure 6 - Player2 showing Player3 as a delegate

Figure 7 - Player3 showing as a delegate for Player2

As you can see in Figure 6 above Player2 now has Player3 listed under the "Delegates" group which gets created automatically when you have delegates configured.

In Figure 7 above you can see that Player3 has Player2 listed under the "People I Manage Calls For".

As you can see in Figure 8 below Player3 is now able to schedule a Lync conference on behalf of Player2.

Figure 8 - Player3 schedules a meeting for Player2

If you decide that you want to reverse the changes made earlier you can do that with the SEFAUtil as well.

Open a command prompt and type the following command syntax (in this example pool01.p52.local has already been configured as a trusted application pool to run the SEFAutil application)

SEFAUtil.exe /server:pool01.p52.local player2@p52.ca /removedelegate:player3@p52.ca

Once the command completes you should see output such as what is shown below.

User Aor: sip:player2@p52.ca

Display Name: Player2

UM Enabled: True

Simulring enabled: False

User Ring time: 00:00:20

Call Forward No Answer to: voicemail

Summary

This blog post described how a company that has not deploy Lync Enterprise Voice (EV) can use the SEFAUtil tool to configure delegate access and allow their users to leverage the "delegate" scheduling feature.