locked
If 2 companies are using Lync, does federation have to be enabled for online meetings to work? RRS feed

  • Question

  • When testing we had "dynamic" federation enabled.  After we went into production we've since turned off all federation.  One of our partners has Lync as well, and now scheduled online meetings don't work if using the Lync client.  If company A sets the meeting up, those from company B get the error below.  It fails the same way if B sets the meeting and A joins...

     

    RequestUri:   sip:XXX@XXX.edu;gruu;opaque=app:conf:focus:id:BNHRRGB5
    From:         sip:jane.doe@opus-group.com;tag=7bb98e5e93
    To:           sip:xxx@xxx.edu;gruu;opaque=app:conf:focus:id:BNHRRGB5;tag=18C5AA0E6E76AA4311A50A6599276EBE
    Call-ID:      d5f3942de9ec419f80c5c2dd4f290bc1
    Content-type: application/cccp+xml

    <?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:xxx@xxx.edu;gruu;opaque=app:conf:focus:id:BNHRRGB5" from="sip:jane.doe@opus-group.com" requestId="0"><addUser><conferenceKeys confEntity="sip:xxx@xxx.edu;gruu;opaque=app:conf:focus:id:BNHRRGB5"/><ci:user xmlns:ci="urn:ietf:params:xml:ns:conference-info" entity="sip:jane.doe@opus-group.com"><ci:roles><ci:entry>attendee</ci:entry></ci:roles><ci:endpoint entity="{9BBD8E8F-A671-4881-90CE-9A40A38BBB74}" xmlns:msci="http://schemas.microsoft.com/rtc/2005/08/confinfoextensions"><msci:clientInfo><cis:separator xmlns:cis="urn:ietf:params:xml:ns:conference-info-separator"></cis:separator><msci2:lobby-capable xmlns:msci2="http://schemas.microsoft.com/rtc/2008/12/confinfoextensions">true</msci2:lobby-capable></msci:clientInfo></ci:endpoint></ci:user></addUser></request>


    Response Data:

    403  Forbidden
    ms-diagnostics:  1002;reason="From URI not authorized to communicate with federated partners";source="sip.opus-group.com"

     

     

    If I allow federation for a user, things work...  Does federation have to be on for fat clients to play nice?

     

    Tuesday, July 26, 2011 9:30 PM

Answers

  • Hi Ken,

    If you turn off the federation, you can't connect to federal partners. And the online meeting also can't work with each other.

    Maybe I've not got what your mean, please give me more comments about your issue.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Proposed as answer by Sean_Xiao Wednesday, August 3, 2011 1:54 AM
    • Marked as answer by Sean_Xiao Monday, August 8, 2011 1:56 AM
    Thursday, July 28, 2011 9:23 AM
  • Also, if I remember correctly, Lync is not good at explaining why it fails.

    We were baffled at first why we could not have a successful meeting via Lync, when everyone had it.

    • Marked as answer by Sean_Xiao Monday, August 8, 2011 1:38 AM
    • Unmarked as answer by Sean_Xiao Monday, August 8, 2011 1:38 AM
    • Marked as answer by Sean_Xiao Monday, August 8, 2011 1:56 AM
    Thursday, August 4, 2011 8:19 PM
  • If the user don't allow  federation, you can't join a federated meeting as a lync account. But you can join  the  meeting as anonymous. Because the lync server don't allow the user to get credential to access federated server.
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Marked as answer by Sean_Xiao Monday, August 8, 2011 1:56 AM
    Monday, August 8, 2011 1:55 AM

All replies

  • Hi Ken,

    If you turn off the federation, you can't connect to federal partners. And the online meeting also can't work with each other.

    Maybe I've not got what your mean, please give me more comments about your issue.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Proposed as answer by Sean_Xiao Wednesday, August 3, 2011 1:54 AM
    • Marked as answer by Sean_Xiao Monday, August 8, 2011 1:56 AM
    Thursday, July 28, 2011 9:23 AM
  • We ran into the exact same thing, and I believe that is correct.  I will do some testing to confirm.
    Friday, July 29, 2011 2:37 PM
  • Sean,

    Here's a more succinct description:

    Issue: Users who are running Lync from external companies cannot join meetings organized by the other if one of of the users is not enabled for federation.

     

    Using the following scenario:

    Ken and Amy at XYZ Company

    Ken has the global policy with no federation allowed

    Amy has AllowExt policy with federation on

    John at ABC Company with federation on

     

    You'll get the following:

    If Ken creates the meeting, John can't join it.

    If Amy creates the meeting, John can join it.

    If John creates the meeting, Ken can't join it but Amy can.

     

     

    Thursday, August 4, 2011 4:25 PM
  • Also, if I remember correctly, Lync is not good at explaining why it fails.

    We were baffled at first why we could not have a successful meeting via Lync, when everyone had it.

    • Marked as answer by Sean_Xiao Monday, August 8, 2011 1:38 AM
    • Unmarked as answer by Sean_Xiao Monday, August 8, 2011 1:38 AM
    • Marked as answer by Sean_Xiao Monday, August 8, 2011 1:56 AM
    Thursday, August 4, 2011 8:19 PM
  • If the user don't allow  federation, you can't join a federated meeting as a lync account. But you can join  the  meeting as anonymous. Because the lync server don't allow the user to get credential to access federated server.
    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Marked as answer by Sean_Xiao Monday, August 8, 2011 1:56 AM
    Monday, August 8, 2011 1:55 AM
  • Yes, but I don't remember there being any point at which Lync said "you can't do that, would you like to join as anonymous."  It just failed.
    Monday, August 8, 2011 2:51 PM
  • One thing I have seen.  If you sign up for the Hosted Lync service by default you don't have federation, especially with a trial account. If you then log into lync on that domain and receive a meeting invite from company A's Lync server, you can join the meeting without being prompted.  It will join you with whatever information you used to set up your account, but definitely shows that you are not authenticated and you have no presense info.

    This seems like it should be the default method when joining as a federated user fails.  But I have only seen it work seemlessly with their hosted service.

    Friday, August 26, 2011 6:20 PM
  • Sean,

    This is bad design.  It assumes that federation (aka passing of presence and chat info) is something that everyone wants.

    Its an incorrect assumption... I don't want to federate, but if a meeting needs to be set up, it should work.

    In my opinion federation shouldn't have ANYTHING to do with an online meeting...

    Ken

     

    Monday, September 19, 2011 11:27 PM
  • When you are a normal user from outside of a non-federated meeting provider, you do not use the Lync 2010 Client. You must use either the Lync Web App or the Lync Attendee when joining a non-federated meeting provider.

    Anyway, I refer to http://community.office365.com/en-us/f/166/t/15515.aspx that has a great solution that allows you to do this:

    1. Use the Lync Web App:

    1.1. Verify that Silverlight is installed (Control Panel, Programs, check for Microsoft Silverlight

    1.2. Copy the Join URL from the meeting invite, and then paste it into Internet Explorer.

    1.3. Add "?sl=1" to the end of the URL, and then press Enter.

    By adding the ?sl=1 to the end of the meeting URL it shows the options for joining as if you didn't have the Lync client installed, as it prevents the Lync auto-detect script. The will show the Web App URL and the Lync Attendee URL (if its enabled) just like a normal person.

    Microsoft: Please provide in built federation detection into clients, or something; Or just have the Lync Web App URL, and possibly the Lync Attendee option in the meeting invitation. I had to deal with another end user with this today, who happens to be the boss as well. End users don't like doing thing manually!

    I would also like more flexibility with the meeting invitation, formatting, logos. SP1 please?

    Regards,

    David

    [Edit] Removed contempt
    • Edited by DBR-9 Tuesday, January 24, 2012 12:34 PM
    Monday, November 28, 2011 3:28 PM
  • Thanks for the "?sl=1" trick.  That did the trick for me.  But explaning this to my users is going to be a pain.  Imagine me in the CFO's office after months of extolling the virtues of Lync and how we even got rid of our WebEx subscription because, heck, Lync does meetings too!  But suddenly, a meeting participant is also using Lync at his company but we have no federated relationship with each other, so when we click on each other's meeting links it just fails with a terrible numerical error.  "I thought this thing could replace WebEx," the CFO bellows, scowling at me in disdain.  "Oh, it can," I reply, "just make sure you modify every meeting invitation so that the URL has ?sl=1 at the end of it!"  Yea, that will go over well.


    Monday, January 23, 2012 11:36 PM
  • Hi Tim,

    I have felt the pain of the CFO bellowing and scowling with disdain over this situation. Not fun.

    Microsoft: There have been 2500+ hits on this thread, that is 2500+ CFOs! This needs a fix for this bug and politicial issue.

    Lync meetings are otherwise really smooth, work consistently and are a fantastic part of Lync. This issue is a minor bug overall.

    I guess the only other technical (non-training or documentation) thing you can do is enable partner domain discovery, and hope that the other side has autodiscovery enabled as well.

    Kind Regards,

    David

     

     

    Tuesday, January 24, 2012 12:51 PM
  • I have found a workaround that does not require meeting URLs to be modified by the user and ensures that all external connections to the meeting are forced to use the Silverlight control.

    It's a bit of a kludge, but it is working well for me.

    The workaround is to use the URLRewrite module for IIS to set up a reverse proxy for the Lync site.  Whenever anybody goes to your "Meet" URL, you rewrite the URL to the backend with SL=1 appended to the query string.  This is invisible to the end user.  So this does not affect your internal users, you need to have your router/firewall and DNS route all requests to the reverse proxy only from external connections.  So if your Simple URL is https://lync.contoso.com/meet then your internal DNS sends you directly to your Lync server and the external DNS sends you to your reverse proxy.

    I actually set the reverse proxy up as a separate site on my Lync server and forward requests to itself, but depending on your server load and whatnot, this can be done on separate servers.  It doesn't matter.

    1. Install the URLRewrite module and Application Request Routing module for IIS 7

    2. At the server level, enable Application Request Routing

    3. Create your reverse proxy site in IIS.  Point it to an empty folder because it will need to add entries to the web.config, so you don't want to reuse the path of an existing site or your default site.

    4. Create a dummy rule in the URL Rewrite section of your new site.  Just create the default reverse proxy rule since its simple.  Anything will do.  This is just so the web.config gets generated correctly.

    5. Edit the web.config and look under the rules section, delete the dummy rule and add the below rules, modifying the various URLs, ports, regex rules, and so on, so that it matches your environment's URLs and naming scheme.  The below example is for a Simple URL set up for lync.contoso.com.

                    <rule name="ReverseProxyInboundRule1" stopProcessing="true">
                        <match url="^meet/(.*)" />
                        <conditions>
                            <add input="{QUERY_STRING}" pattern="(.*)sl=(.*)" negate="true" />
                            <add input="{CACHE_URL}" pattern="^(https)://" />
                        </conditions>
                        <action type="Rewrite" url="{C:1}://lync.contoso.com:4443/{R:0}?sl=1&amp;{QUERY_STRING}" appendQueryString="false" logRewrittenUrl="true" />
                    </rule>
                    <rule name="ReverseProxyInboundRule2" stopProcessing="true">
                        <match url="^meet/(.*)" />
                        <conditions>
                            <add input="{QUERY_STRING}" pattern="(.*)sl=(.*)" negate="true" />
                            <add input="{CACHE_URL}" pattern="^(http)://" />
                        </conditions>
                        <action type="Rewrite" url="{C:1}://lync.contoso.com:8080/{R:0}?sl=1&amp;{QUERY_STRING}" appendQueryString="false" logRewrittenUrl="true" />
                    </rule>
                    <rule name="ReverseProxyInboundRule3" stopProcessing="true">
                        <match url="(.*)" />
                        <conditions>
                            <add input="{CACHE_URL}" pattern="^(https)://" />
                        </conditions>
                        <action type="Rewrite" url="{C:1}://lync.contoso.com:4443/{R:1}" appendQueryString="true" logRewrittenUrl="true" />
                    </rule>
                    <rule name="ReverseProxyInboundRule4" stopProcessing="true">
                        <match url="(.*)" />
                        <conditions>
                            <add input="{CACHE_URL}" pattern="^(http)://" />
                        </conditions>
                        <action type="Rewrite" url="{C:1}://lync.contoso.com:8080/{R:1}" appendQueryString="true" logRewrittenUrl="true" />
                    </rule>

    You will notice that I'm using ports 4443 and 8080 for HTTPS and HTTP, respectively.  This isolates my external Lync site from my internal one.  I think it's Lync default configuration for the External site.  If you use standard web ports and IP (non-standard Lync ports), you can consolidate those rules down to just two with RegEx.  But it doesn't matter.  It will work either way even with standard ports with the above code.  Actually, I removed the 80->8080 and 4443->443 rules in my firewall when I created this reverse proxy in IIS because it was no longer needed since the port redirections were being done here now.  But I digress...

    Now everybody who opens a meeting link from outside your organization, whether they are a Lync user or not, will be forced to use the Silverlight Lync meeting control and be given the option to log on anonymously.  No need to worry about federation or anything else.  It will Just Work.

    EDIT: I just noticed that Lync seems to want to stop non-Lync sites in IIS sometimes, such as republishing the topology.  I guess maybe hosting it on the Lync server is not the best idea.  YMMV :-P

    Wednesday, March 7, 2012 5:10 PM
  • If Company A (Alice) has Lync deployed, they should be able to attend a meeting at non-federated Company B (Bob) (assuming permissions) as a Guest. It does not matter if Company A has an Edge or not.  

     Scenario1) If Alice does NOT have an Edge:

    Alice àInternet àBob’s Edge àBob’s Conference MCU

    This might be caused by a failure due to STUN and TURN. Open port  TCP 443 and UDP 3478 on Company A’s (Alice) Firewall. This might solve the issue.


    http://voipnorm.blogspot.com/

    Friday, March 9, 2012 5:22 PM
  • Hi,

    Maybe CU6 solves this problem (just baked):

    http://voipnorm.blogspot.com.es/2012/06/lync-cumulative-update-for-june-online.html

    Hope it helps

    Thursday, June 21, 2012 10:25 AM