Cannot connect with the Lync Windows Store App for Windows 8

I installed the new Lync client from the Microsoft app store and I am unable to get it to connect. I am using the same login information that works for my desktop PC and my Windows Phone but it just keep saying it cannot connect without providing any details or logging anything to the event log.

Since I know the Lync Edge server is running and working with other Lync clients and I cannot find any logging information does anyone have a good idea of where to start looking to debug why the new Lync Windows Store application will not connect?

Thank you in advance.

October 26th, 2012 9:54pm

I get the same thing.  "Can not connect to server"  Right now I am not running an edge server so I wasnt sure if that was the problem but I dont have any problems connecting with Lync 2010 or 2013 Preview client on the desktop. 

Im trying to figure out where it saves the log files to see if that gives any more i

Free Windows Admin Tool Kit Click here and download it now
October 26th, 2012 10:35pm

Seeing the same thing here. Tried it on the network and outside the network. Verified everything works fine with the regular client\iPhone and Windows 7 phone. We are using godaddy certs but that shouldn't matter if the regular client can connect. 
October 26th, 2012 11:09pm

I know its working for some as I have seen tweets about it.  I tried a friends account at a different company and it at least sees the server and asks you to log in.

Free Windows Admin Tool Kit Click here and download it now
October 26th, 2012 11:19pm

Yeah I have seen others say it works. We can get it to prompt for username and password now and we see the FE server logging the connection but still can't see any error. 
October 26th, 2012 11:21pm

There's an option to enable logging but no mention of the location of the log file.
Free Windows Admin Tool Kit Click here and download it now
October 26th, 2012 11:38pm

Having the same issue, just have the spinning Wheel, have installed the October update http://support.microsoft.com/?kbid=2493736&wa=wsignin1.0

October 26th, 2012 11:49pm

I guess all the Microsoft guys are hung over from last night. :)

Free Windows Admin Tool Kit Click here and download it now
October 26th, 2012 11:54pm

Experiencing the same problem, got a spinning circle for hours, and a few tries later, the "We cannot connect you to the server, check your connection information" error message immediately when trying to sign in.

Lync server is up to date with CU7 (October update, Lync 4.0.7577.203, Core 4.0.7577.205, and Mobility service 4.0.7577.203), using internal certificates (installed on Windows 8 PC through AD). Trying to connect on the local network only so far.

Can connect using the same address just fine using discovery with Lync 2010, 2013 clients locally and remotely, Lync for Windows Phone locally and remotely, and Lync Phone Edition 2010 locally (not tested remotely yet).
Same Windows 8 PC connects fine using Lync 2013 client.

October 28th, 2012 4:09pm

I got the same issue on my Windows 8 tablet, but it works on my Windows 8 desktop computer. When I installed Office 2013 on tablet and tried to sign-in with Lync 2013 I got error: wrong time. Checked my settings, and indeed time zone was incorrect - thanks to Bill Gates for making Pacific default in all Windows installations.

So I updated time zone (I'm in Toronto so it is Eastern Standard Time -5hrs), re-synced time and Lync APP signed in without any glitch. I hope this may help others too, let me know.

So far I like new app. Best thing you can make and receive calls just like in Lync 2010/2013. I will test video conferencing later today, and look forward to see how it works...

  • Proposed as answer by lync15 Monday, October 29, 2012 10:37 AM
Free Windows Admin Tool Kit Click here and download it now
October 29th, 2012 1:37pm

That's fine, but we're looking into sigh-in issue with Lync client from Windows Store.

It's not the same to Lync 2013 client app, right?

October 29th, 2012 2:27pm

You can enable logging by following Elan's blog:

http://www.shudnow.net/2012/10/28/lync-rt-client-viewing-logs/

I had no issue signing from my surface, and 2 other Windows 8 Pro PC and laptop.

Free Windows Admin Tool Kit Click here and download it now
October 29th, 2012 2:36pm

If you read slowly and carefully, you can see this: Lync APP signed in without any glitch.

Lync APP means Metro/Modern style App, not Lync 2013, and not Lync 2010, and not Lync Phone Edition :-)

Lync MX (I saw this name in the Internet, looks like this is the name for Lync APP in Windows 8) can sign in as long as your Lync environment has all the settings right (SSL, DNS SRV records, and CU7 from October).

So Lync APP means Windows 7 Modern UI APP, and not Office-based Lync 2013 or older Lync 2010...

October 29th, 2012 3:38pm

If you read slowly and carefully, you can see this: Lync APP signed in without any glitch.

Lync APP means Metro/Modern style App, not Lync 2013, and not Lync 2010, and not Lync Phone Edition :-)

Lync MX (I saw this name in the Internet, looks like this is the name for Lync APP in Windows 8) can sign in as long as your Lync environment has all the settings right (SSL, DNS SRV records, and CU7 from October).

So Lync APP means Windows 7 Modern UI APP, and not Office-based Lync 2013 or older Lync 2010...

Im not sure how this is helpful to us.  We dont care what its called.  LyncRt, LycnMX, LyncMetro.  It doesnt matter.  We are also not talking about the full Office Lync 15 client either.  One person mentioned it but we got back on track.

Thanks to JPs link.  I got the log files open but do not see any errors but this one:  HRESULT API failed: 80070002 = hr. Panoramic device registry key couldn't be read

Looking that up, it appears to be related to the attendee client which none of us are using either.  Like I have said previously.  I dont have an EDGE server in the topology yet.  I am working on that this week now that I have recources to do so.  We are also getting ready to migrate to lync 2013 for full production.  Since my 2010 clients and office 2013 preview clients can connect with out any problems, I am thinking the Lync-RT client requires an EDGE server but no one has confirmed that yet.  

If I had an SSL, DNS SRV records issue, would my desktop client not work either?  I have made sure CU7 is installed as well.  Also rebooted the server after the installation.

Free Windows Admin Tool Kit Click here and download it now
October 29th, 2012 5:23pm

You don't need an Edge, if you are connecting thru your corporate WIFI...

Have you provisionned your internal certificate from your Root CA ?

What device are you actually using: Surface, surface pro, Windows 8 Pro ?

October 29th, 2012 5:38pm

I am on windows 8 Ent.  We also have a surface RT but I assumed like the mobile clients that you had to have an edge network for that to work.  Since my office2013 preview client is working fine doesnt that mean the cert is good?

Thanks for your help.

Free Windows Admin Tool Kit Click here and download it now
October 29th, 2012 6:09pm

So your Win8 Ent is domain join right?

You should be good from a Certificat stand point, if your Win8 Pro is domain join.

Are your current Lync 201 client connecting with Automatic configuration?

Than I would suggest to enable Logging on your Front End.

October 29th, 2012 6:16pm

Correct.  I am trying to capture logs on the front end.  But Im wondering if the client is saying it cant contact the server if the FE will capture any logs at all.

Im looking at the join launcher and the SIP components

Free Windows Admin Tool Kit Click here and download it now
October 29th, 2012 6:22pm

Enable SIPStack and S4  on the logging tool.

One question:

When you launch Lync RT...  You enter your SIP adress

Then you are prompt to enter you Credential?  right

In what format do you enter your credential?

October 29th, 2012 6:30pm

I am using my email address as that is what we have set up for our SIP uri

One other thought.  Since I have "assumed"  that Edge was needed for Mobile clients I have never installed the Mobility Service either.  

I know I'm very green at administrating lync.  I appreciate your help.

Free Windows Admin Tool Kit Click here and download it now
October 29th, 2012 6:42pm

The Mobility and edge service  are not required.

Lync RT will singin the same way a Full Lync client do.

After you have entered your email adress, you should be prompted to enter your Username and Password.

In what format did you entered those information:

domain\username   or   UPN style :  first.last@domain.com  ?

October 29th, 2012 6:50pm

I dont get that.  All I have is username which is my email address and the "Sign in AS" drop down box.

With the sign in  button and then the "We can't connect to the server." error.

I know this has to have something to do with my deployment.  Im trying to go through the logs now but am not finding anything with my username as of yet.

Free Windows Admin Tool Kit Click here and download it now
October 29th, 2012 7:05pm

On my setup, Lync RT only asks for the SIP address, it never gets to the point of asking for credentials. It just says unable to connect to server, check connection address (not sure about the exact terms used in English UI, I'm on a French version).

Lync 2013 desktop client on the same computer connect just fine using autodiscovery.

basically:
- Lync 2013 desktop client : connects from corp and remotely using auto-discovery.
- Lync Phone Edition 2010 : connects from corp and remotely (provisionned on corp net)
- Lync Mobile on Windows Phone 7 : connects fine on corp and 3G (Mobility Services installed on server)
- Lync MX : does not connect from corp, nor remotely.

Lync MX seems to first have a spinning waiting wheel, then triggers the "cannot connect to server" error message immediately.

Another user accounts manages to get to the credentials prompt, but then fails with the same error (tested both domain\user and user@domain formats).

October 29th, 2012 7:10pm

After entering your SIP Adress,

you should get this:

Free Windows Admin Tool Kit Click here and download it now
October 29th, 2012 7:50pm

And if you don't see this UI (where Lync app is asking for your credentials), it is likely that either the server discovery is not successful or the Lync servers are not reachable on the network your device is connected to. To help isolate the problem, can you please confirm if the server discovery was enabled on your iPhone or Windows Phone Lync:

  1. Sign out if you are already signed in
  2. On the sign-in page, expand More Details where you can view Sign-in As etc.
  3. Check the Auto detect server setting (ON/OFF)

If it was set to ON and you were able to sign-in from Lync Mobile, then Lync app on Windows 8 should be able to get past through the server discovery and prompt the user for credentials.

If it turns out to be not related to server discovery (i.e. Mobile clients work fine), then check your Proxy and Firewall settings on your Windows 8 machine. It is possible that the server discovery is failing through your proxy server.

October 29th, 2012 7:56pm

Nope not getting that. :(

Free Windows Admin Tool Kit Click here and download it now
October 29th, 2012 8:07pm

On Windows Phone, Lync can be disconnected and reconnected fine using automatic discovery.

Lync 2013 desktop client on laptop (domain joined) connects fine using automatic discovery as well.

On the same laptop, Lync MX fails.

I found one more weird behavior:

For my user account (which Lync 2013 is connecting to just fine), Lync MX fails before asking for username and password.
Using another user name, Lync MX prompts for username and password, then fails with the same error.
Now for the weird thing, Lync MX prompts for credentials even if the address is invalid, it only fails before asking for credentials for my own account.
For other existing accounts it fails after providing the credentials.
For invalid accounts on the same domain, as expected, it fails after providing credentials as well.

I don't see why the behavior is different for my account, except if Windows is providing credentials automatically when using the same AD user account.

October 29th, 2012 8:23pm

Philpee.  I actually have the same thing happen here.  If I use a different signon address I get the prompt.  This only works if I try to connect to a different server though.  Using our internal domain nothing changes.

Free Windows Admin Tool Kit Click here and download it now
October 29th, 2012 9:47pm

Based on what Philippe and Dusty described, it makes me believe that the server side requirements may not have been fully met for Lync app on Windows 8. We are drafting the high level requirements and plan to post them here. Please stay tuned, and appreciate all your enthusiasm to resolving the sign-in issues.
October 29th, 2012 10:10pm

I'm also experiencing issues.  After  downloading Lync from the windows store, when I try to open it I get an error stating "We can't connect to the server.  Please check your sign-in info."

In the past, we have had a GPO which set the server address and TLS setting for our lync 2010 clients, but we could also go in manually and edit the sign in info if needed.  I did recently add the SRV record in DNS for _sipinternaltls, and that seems to have made it so we don't need to set the custom settings anymore, the lync client can correctly auto-discover the server.  

Even so, I would try entering the server info in the new lync client, but in the Lync MX client I don't see any way to adjust any settings. 

Free Windows Admin Tool Kit Click here and download it now
October 29th, 2012 10:13pm

Thank you Rama.

I am now able to get the sign in box.  I had to change the sign-in name to my username@domain.local vs my email address which is how the desktop client connects (user@school.edu)

I still can not log in however but now I might be able to pull logs..which IM working on.


October 29th, 2012 10:55pm

On a side note:  It was mentioned for autodiscover to be working.  I just installed the mobility connector.  My phone now works when using wireless on the domain.  But my ipad and surface-RT still can not connect evern after installing the cert.  Using the same login as my phone. HMMM

I look forward to the required setup for this.

Free Windows Admin Tool Kit Click here and download it now
October 29th, 2012 11:05pm

Find below a few troubleshooting suggestions for the end-users:

  1. You must have a Lync account from Office 365 or from your enterprise.  If you already are using Lync desktop or Lync on a mobile device, you have a Lync account
  2. Make sure that your device has an Internet connection.  Try opening a browser and going to a web page
  3. Make sure that the time and date on your device is set accurately.  This is particularly important for devices that are not joined to a domain, such as Microsoft Surface or other devices running Windows RT (from Administrator console, run w32tm /resync). The time setting on the device must be in close synchronization with the time setting on the server.
  4. Check the sign-in credentials.  Ensure that your sign-in address, user name and password are all typed correctly (please double check for typo)

If you are trying to connect to Office 365 service, you could ignore the below server side requirements. Contact your support team if you are not sure about the server and deployment requirements.

Here are the on-premises Lync server and other Enterprise deployment requirements to support Lync Windows Store App:

  1. Lync Server 2010 CU5 or later
  2. Server must have REACH service enabled
  3. Server must have auto-discovery service enabled.  You must also publish the DNS CNAME records for the auto-discovery service
  4. The Certificate Revocation List (CRL) Distribution Point (CDP) for the certificates issued to Lync server must point to an HTTP resource instead of an LDAP resource
  5. HTTP proxies in your enterprise must be configured to allow Lync server related HTTP traffic.  You may need to add exceptions for the Auto-discovery service, REACH service, and Webticket services traffic

One of the known issues that can prevent sign-in after server prerequisites are met is that, some Network adapters (like the 4G LTE USB modems) do not register as physical devices. You may be able to access the web over these networks, but some Windows 8 apps may not be able to access the servers/service over the same network.

We will continue to share the information and help you get past through sign-in. Thank you for patience and for sharing your experience here.

  • Proposed as answer by crumbrian Wednesday, October 31, 2012 9:39 PM
October 30th, 2012 2:43am

Thanks Rama!

I have been contributing to a thread in the Office365 Lync forums about this problem:

http://community.office365.com/en-us/forums/166/p/73737/279277.aspx?PageIndex=1

I have an Office365 E3 Plan subscription.  I have successfully logged into Lync using my Lon@{ourdomain.com} user email address on: the 2010 client, the 2013 Preview client, and the WindowsPhone7.5 client.  These have been from a Windows7 Pro PC, a WindowsPhone7.5 phone, a Windows8CommunityPreview PC, and Windows8ProRTM PC. 

On my new SurfaceRT, with the Lync MX client installed, I can't login with that same user email.  I CAN login with the default user ID, admin@{ourOffice365Name}.onmicrosoft.com.  So, that suggests the SurfaceRt is configured OK, the firewall works, and the Lync client works.  But, not with my user ID.

Hope that helps,

Lon

Free Windows Admin Tool Kit Click here and download it now
October 30th, 2012 5:00pm

I have a solution to my problem! 

Riyaz from Lync Online Support (I entered a ticket in our O365 portal) showed me where our DNS settings were not current.  We entered the original DNS settings when we created our O365 account (within the first week it went live) but we didn't enter these:

Lync autodiscover for desktop and mobile clients

Type Host name Destination TTL

CNAME

sip.yourDomainName.com

sipdir.online.lync.com

1 hour

CNAME

lyncdiscoverinternal.yourDomainName.com

webdir.online.lync.com

1 hour

The lyncdiscoverinternal one is the culprit in this case --  its' required for mobile device Lync clients.  I entered these into our DNS and tried to login with my user name again and it instantly connected.

Hope that helps,

Lon

October 30th, 2012 6:12pm

lyncdiscoverinternal is present in our system, and resolves correctly, but the problem still exists.  there is also lyncdiscoverexternal in many circumstances.  We ran into this deploying iPhones and iPads.  The problem still happens on Lync via Surface RT and Lync via metro app Windows 8.
Free Windows Admin Tool Kit Click here and download it now
October 30th, 2012 6:59pm

I've having the same issue, but not only with the RT version but also with the 2013 version. The Old one works perfectly on my mac and the clients for the Android and ipad also worked flawlessly. any ideas?
October 30th, 2012 11:00pm

Got mine working from the outside. Run all the latest updates on both FE and Edge server rebooted both and now it's working. Still no luck internally but I think it's a configuration issue. The log file is showing the edge server url port 5061 but when I try to hit the web address for that it errors out. I'm not real sure what step I missed setting it up but internally we most likely just be using the regular client so I'm not going to lose sleep over it. Maybe once we upgrade to 2013 I'll figure out what I missed. 
Free Windows Admin Tool Kit Click here and download it now
October 31st, 2012 5:44pm

Rama, any update on this?  The iPad is working fine and the Win8 and Surface RT metro app is not.  Not a very compelling sell to our CEO to choose a MS product...
October 31st, 2012 8:50pm

Hi Ben,

Is this OnPrem deployment or office365?

If it is OnPrem, can you please check if the Certificate Revocation List (CRL) Distribution Point (CDP) for the certificate issued to Lync server point to an HTTP resource instead of an LDAP resource?

Thanks

Free Windows Admin Tool Kit Click here and download it now
October 31st, 2012 10:06pm

Lon,

Glad to know that the sign-in issues have been resolved and thank you for sharing the outcome. For Office 365 customers, we understand this is an area where our customers are required to create the necessary DNS CNAME records to point to O365 servers. We are working on making this requirement explicit/clear.

Thanks,

Rama

November 1st, 2012 12:00am

Ben,

If I understand correctly, Lync app on iPhone and iPad have sign-in issues as well? Or you ran into sign-in issues when Lync app on iPhone/iPad were rolled out, but they are working fine now. Just so you know, Lync Mobile and Lync app on Windows 8 use similar server discovery so it will be helpful to know if any of these clients work for you. Without the access to app logs, it is challenging for us to understand what could be going wrong, but as long as server and deployment requirements mentioned above are met, ideally, sign-in should succeed.

Thanks,

Rama

Free Windows Admin Tool Kit Click here and download it now
November 1st, 2012 12:04am

Kevin,

Good luck with your investigations and hope you will find out the root cause soon.

Thanks,

Rama

November 1st, 2012 12:05am

Ben,

Glad to know that Lync on iPad is working, but sorry to know that Lync app on Windows 8 isn't working. I presume you have tried both the clients on the same network (Corporate Wi-Fi or Home Wi-Fi)? If so, as Venky suggested below, please check the certificates sent by Lync Servers (from the browser, try to access HTTPS://lyncdiscover.domain.com or HTTP://lyncdiscover.domain.com or HTTPS://lyncdiscoverinternal.domain.com or HTTP://lyncdiscoverinternal.domain.com - and if the server responds to HTTP/HTTPS request, check the certificate)

If the CDP contains an HTTP resource, then I think we are running out of options here and we may need to app logs to possibly root cause the issues.

Thanks,
Rama

Free Windows Admin Tool Kit Click here and download it now
November 1st, 2012 12:14am

I am having the same issues as most everyone here as well.

I have a Standard FE Server and an Edge server deployed.

Mobility service is installed and works correctly both internally and externally from iOS and Android devices.

The Lync Windows 8 store app however just sits in an eternal spin and never connects internally. However, if I connect my laptop externally it connects just fine.

I'm at a loss at this point and have been pulling my hair out with this issue all afternoon. Any guidance would be appreciated.

November 1st, 2012 12:20am

When i look trough the log. I see this: 

11/01/2012|11:46:00.069 D50:F70 INFO  :: Data Received -XXX-XXX-XXX-XXX:443 (To Local Address: 192.168.1.9:60410) 749 bytes:
11/01/2012|11:46:00.069 D50:F70 INFO  :: SIP/2.0 401 Unauthorized

I'm 100% sure that my credentials are right. We don't have CU7 (yet) 
Will that be the solution?

  • Edited by K.smink Thursday, November 01, 2012 10:59 AM
Free Windows Admin Tool Kit Click here and download it now
November 1st, 2012 1:54pm

Hello, colleagues!

About "eternal spin" and "spinning wheel" - we have the same issue. Domain computer, lync-enabled domain user. Lync Servers are updated to CU7.

That is it looks like:

Looked through the SIP/S4 traces, and among various related errors and warning I saw this:

(TL_ERROR, TF_SECURITY)

$$begin_record
LogType: security
Text: Parsing failed
Result-Code: 0xc3e93f21 SIPPROXY_E_INVALID_URI
Connection-ID: 0x181C00
Peer-IP: 10.177.62.169:51016
Peer: 10.177.62.169:51016
SIP-Start-Line: NEGOTIATE sip:(null) SIP/2.0
SIP-Call-ID: a82653425b8e46d68faee761cca9cb2e
SIP-CSeq: 1 NEGOTIATE
Data: Malformed SIP URI
$$end_record

Above this error there were numerous null sip-address errors.

It seems to be the issue needs more investigation...


November 1st, 2012 2:39pm

After further investigation this morning. Here's the various errors the LyncLog is showing:

HRESULT API failed: 80070002 = hr. Panoramic device registry key couldn't be read

HRESULT failed: 800780006 = HRESULT_FROM_WIN32(::ShimWSAGetLastError()) . Failed to convert string IP to SOCKADDR

CSIPAsyncSocket::Connect: HRESULT API failed: 80072733 = hr

SIP_MSG_PROCESSOR::GetLocalConnectionAddrSubnet get subnetmask failed

CSIPAsyncSocket::OnConnectReady - Error: 8211 dest:fdqnofmyfeserver.mydomain.org

CSIPClientConnection::OnConnect (80ee0067) this: 00000030578FA590

SIP_MSG_PROCESSOR::OnConnectComplete connect failed 80ee0067 retry connecting via HTTP tunnel

Alot of these same message repeated, then

CSIPAsyncSocket::OnConnectReady - Error: 11001 dest:externalfqdnofmyedge.mydomain.org

Followed by more of the same messages.

It's important note as I did before, both internal and external mobility work fine iOS, Android, WP doens't matter.

It's only this Lync MX app that can't connect. All clients 2010, 2013, Attendee all work fine both internally and externally as well.

This might be a totally different topic in itself but the web app from any browser in Windows 8 tells me the meeting URL is invalid, yet I can join from any other machine running any OS.

I'm at a loss at this point and am beyond frustrated.

Free Windows Admin Tool Kit Click here and download it now
November 1st, 2012 4:49pm

About meeting URL I can say only that CU7 on Lync Server machines needed to be installed for meeting to work from the Lync App (for other general functionality from the Lync App - CU5 is enough).
November 1st, 2012 5:27pm

Thanks for that Dmitry! It turned out last night that I was missing 1 of the 3 updates on my Edge. Did those this morning and hadn't tested URLs until just now after your reply. I'm happy to announce that they ARE INDEED working now. Still no dice on the MX app though.
Free Windows Admin Tool Kit Click here and download it now
November 1st, 2012 5:35pm

All,

I finally fixed the issue! Since I use my FW for port translation and loopback NAT for reverse proxy, it was simply just another Loopback NAT that had to be added for the Edge.

All services now function as intended and I'm a happy camper, also earned some brownie points from the folks in charge.

I wanted to give a big thank you to all who have contributed to this thread and I wish you nothing but luck on your endeavor to get MX working in your environment.

Thanks again!

November 1st, 2012 6:29pm

Fantastic news and thank you for sharing your experience here, especially the positive outcome. We, Microsoft Lync folks, continue to try our best to help address the issues related to Lync app, and specifically sign-in issues discussed here.
Free Windows Admin Tool Kit Click here and download it now
November 2nd, 2012 2:02am

We managed to publish some information related to Lync app sign-in issues along with the server and deployment requirements: http://office.microsoft.com/en-us/lync-help/lync-sign-in-issues-HA103747515.aspx?CTT=1 - hope you will find it helpful. Lync official help page is: http://office.microsoft.com/client/15/help/home?Shownav=true&lcid=1033&ns=LyncWindowsStoreapp&ver=15&mode=WindowsStoreapp
November 2nd, 2012 2:52am

Hi Dmitry,

Can you please confirm if you have tried the user name in both the formats below:

1. username@domain.com (preferred format)

2. AD-domain\username

If none of them work, - and assuming SIP URI, user name, and password were all entered correctly with no typo errors - it sounds like we will need the access to app logs to investigate the issue further. I presume the same set of SIP URI, user name, and password work for other Lync client like Desktop or Mobile.

Free Windows Admin Tool Kit Click here and download it now
November 2nd, 2012 3:25am

Hi guys,

if you want to solve this problem, you need to do the following:

1. uninstall all other Lync clients

2. close outlook

3. make sure no UCMA is installed

than got to APP Store and download the App, sign in with SIP Address, than with domain\username

That's simply all, I had to support this the last days massively in our Company and it was always the same issue.

Additionally, enterprise users should have the Client version installed too, follow here exactly the same instructions.

good lync

November 2nd, 2012 11:53am

Hi, Rama!

If I input my login to the "Sign-in address" field in SAM format, it fails immediately ("We couldn't sign you in. Please check your sign-in info and try again"). If I input UPN/SIP-address to the field I face the issue I described (endless spinning wheel). Desktop clients work good at the same workstations and users.

I'm ready to give you the logs, so please tell me how I can send the archive to you.
Free Windows Admin Tool Kit Click here and download it now
November 2nd, 2012 2:12pm

Hi, Thomas!

I tried LyncMX at various workstations. And one of them is without the Office and Lync-desktop apps at all from the beginning of its life.

As for "domain\username" type of sign-in address I've written above (in the message to Rama).
November 2nd, 2012 2:16pm

I too still get the spinning wheel of death.  This is using Sip address as sign in address and then domain\username as log in.  If I use domain account as sign in and log in I get the cannot log in message.  

We do not have an edge server yet and the external discovery is turned off.  We are only allowing this on the internal network lan and wireless.

I dont know what else I am missing but it has to be something in the set up that we are doing wrong.

Free Windows Admin Tool Kit Click here and download it now
November 2nd, 2012 7:09pm

This might be some insight to some of the issues with the Lync app not connecting.

From what I found, the Lync app doesn't use the standard discovery methods, it looks for sip.yourdomain.com.

I got mine working externally but not internally as my sip domain and my internal domains dont match. Might try and re-direct the internal traffic to the reverse proxy

November 2nd, 2012 7:41pm

Thanks Victor.  We dont run a Reverse Proxy right now as we havnt needed one.  I will be setting one up when I get closer to deploying lync to the rest of campus and allowing external access via the edge server.

I have sip.domain.com pointed to my pool.  We do use split brain.  domain.net is internal and domain.edu is external.  I have a DNS entry in both.  Thats another project is to convert domain.net all over to domain.edu to make it all one domain..  but thats a big project that I sometimes wonder if its worth messing with. :)

Free Windows Admin Tool Kit Click here and download it now
November 2nd, 2012 8:02pm

Hi Dusty,

Few clarifications:

1. "We dont run a Reverse Proxy right now as we havnt needed one" - do you have Lync Mobile clients that access Lync servers from Internet? If so, I wonder how would Lync Mobile clients work from external network and Im positive Lync app on Windows 8 will not work unless HTTP/S traffic is allowed to hit the Lync pool (not the Edge server)

2. "We do use split brain.  domain.net is internal and domain.edu is external" - I do not intend to ask how the SIP URI will look like for your users, but just so you know, our server discovery is based on the domain part of SIP URI (i.e. for alias@domain.net, we use "domain.net" to discover the servers). For this purpose, one common domain must be used that is accessible from both Internal and External networks (with appropriate DNS mappings)

I've learnt this today that our customers could have two domains for Internal and External access. I'll try to find out from our product teams on how Lync clients/servers work in this scenario. Good luck with your domain unification project :)

November 3rd, 2012 12:35am

Rama,

I just recently got the mobile clients working..And they are only allowed to connect when on the corp network/wireless.  Not outside on public internet or over LTE wireless connection from phone provider.

We have all users setup to use user@domain.edu as their sip uri.  I have the DNS of sip.domain.edu pointing to the pools IP address.  So the way I have it set up, I have a DNS entry for pool.domain.net pointing to the IP address of the server.  I also have sip.domain.edu pointing to the same IP address.  The same goes for the rest of the dns requirements.  I am setting up both as this allows the users to use either their user@domain.net  or user@domain.edu as they both with this way.  My autodiscover is also set up this way right now and it works great with both logins.  I might be doing it wrong and welcome a better solution.  With 2013 about to release we are going to be going to a full pilot with more then the IT folks and then by next spring hopefully role this out to everyone so I want to do this next install correct. :)

I appreciated all the help.  If you need to know more about our network feel free to email me.  I dont like our info out there for everyone to see, not that Technet users are malicious or anything. :)

Free Windows Admin Tool Kit Click here and download it now
November 3rd, 2012 1:14am

Hi, Rama!

If I input my login to the "Sign-in address" field in SAM format, it fails immediately ("We couldn't sign you in. Please check your sign-in info and try again"). If I input UPN/SIP-address to the field I face the issue I described (endless spinning wheel). Desktop clients work good at the same workstations and users.

I'm ready to give you the logs, so please tell me how I can send the archive to you.

Rama, what about my post above (in quote)? :)
November 6th, 2012 12:46pm

So I've got the same problem right now:

Desktop client internally works no problem

Desktop client from a non-domain pc from an external network works fine

iphone, android and wp7 device all work fine

Both the 2010 and 2013 desktop clients work fine

Lync MX on Windows RT, MS Surface, fails, I get the second prompt for domain credentials, tried them in various combinations, some fail, domain.local.fqdn\user.name gives us the spinning circle, no errors on TMG, nothing on MCX log on front end server.

Edit: Forgot to mention server is lync 2013 now, TMG as reverse proxy, one edge, one fe

Free Windows Admin Tool Kit Click here and download it now
November 8th, 2012 12:25pm

So I'm also seeing the following error but its just start-up I think when its interrogating the device caps

HRESULT API failed: 80070002 = hr. Panoramic device registry key couldn't be read

I'm looking at the log-in and I see the following dodgies:

It hits webticketwith no creds

Executing wws method with no auth auth

then ProxyChallenge kicks in and asks for credentials

is see this:

Error string with resource id '0x485' is not found for the language id '0x809'.

followed by

.]]><ExecuteWithWindowsOrNoAuthInternal><SequenceID>1.1.1.1.2</SequenceID><hr>0x80f10046</hr></ExecuteWithWindowsOrNoAuthInternal><![CDATA[ExecuteWithMetadataInternal, asyncContext=02F207E8,

 context: WebRequest context@ :105181080

  MethodType:6

  ExecutionComplete? :0

  Callback@ :0646834C

  AsyncHResult:80f10046

  TargetUri:https://lync.mydomain.com/WebTicket/WebTicketService.svc

  OperationName:http://tempuri.org/:IWebTicketService

 Error:

Then....

.]]><ExecuteWithMetadataInternal><SequenceID>1.1.1.1.3</SequenceID><hr>0x80f10046</hr></ExecuteWithMetadataInternal><SequenceID>1.1.1.1</SequenceID><hr>0x80f10046</hr></Get-NewWebTicket><![CDATA[Lync autodiscovery completed with hr: 0X80004005 sipint:  sipext:  authint:  authext:  wts:  retry: 0]]><SequenceID>1.1.1</SequenceID><hr>0x80004005</hr></Lync-autodiscovery><![CDATA[

   autoRetryByErrorCode=1

   withRescheduleHint=0

   withAutoRetrials=0

   Login failed with permanent error or no auto-retrials]]><SequenceID>1.1</SequenceID><hr>0x80ee0088</hr></Login>

It's given up then, what's bogus though it it's getting through to TMG no problems.

November 8th, 2012 1:04pm

This might not be the same scenario for all of you guys, but if your Lync certificate are being provisioned from an internal enterprise certificate authority you need to check your certificates for HTTP-based CRL and CDP publication.

Lync MX will not utilise LDAP (as the Lync PC client will). I've written up this process here:

http://imaucblog.com/archive/2012/06/17/lync-online-adfs-sign-in-issues-server-is-unavailable-for-non-domain-joined-client-pcs-and-a-windows-ca/

Hopefully this helps.

A

  • Proposed as answer by Adam JacobsMVP Saturday, November 10, 2012 12:46 PM
Free Windows Admin Tool Kit Click here and download it now
November 10th, 2012 2:56pm

Adam, not sure you can propose your answer as the solution, maybe we should wait until a few more people chime in on what type of external certs they have issued, any moble client would only be worried about one certificate, the external cert issued by the reverse proxy , more than likely a UCC if exchange is in the environment and TMG is in the mix.

Now in my case that's a comodo issued certificate and remember that most people here are saying their other mobile devices are connecting ok, I haven't checked but I would assume externally issued certs don't even include an LDAP binding for CRL or CDP.

I've checked my external cert for good measure and it checks out fine, also if I remember correctly if your certs are messed up the authentication process bombs a lot earlier no? people seems to be in and getting asked to pass their domain credentials to the server, aside from the Lync MX logs I've posted above, I can't see any bogus behaviour going on in either the SIP or MCX

November 12th, 2012 12:17pm

All my certs point to HTTP.  
Free Windows Admin Tool Kit Click here and download it now
November 12th, 2012 5:23pm

Hi Simon,

Point taken, if your CRLs are already accessible via HTTP (which to your point is entirely probable if you're using public certs) then two other issues are worth investigating:

1) If your backend is Lync Server 2010 ensure you are running the October Cumulative Updates throughout

2) Autodiscovery is configured i.e. lyncdiscover.yoursipdomain.com (external) and lyncdiscoverinternal.yoursipdomain.com (internal)

A

November 12th, 2012 6:25pm

I know I won't be able to answer for everyone but my back end is now 2013, again all mobility works with no problems with the exception of the Lync MX client, Android, Windows phone & iPhone, even off domain PC connect no problems.

Auto discovery must be working for the LyncMX client to prompt for credentials right, otherwise how would it find the webticket web service?

Si

Free Windows Admin Tool Kit Click here and download it now
November 12th, 2012 8:20pm

I have tried and gone through every possible fix with no luck. RT does not work internally or externally. Of course every other clients work just fine.

Any help would be appreciated.

Here are the two errors I am seeing in the debug capture on the Edge Server:

1. See the from SIP address

Direction

: outgoing;source="local";destination="external edge"

Peer

: 99.110.130.113:49624

Message-Type

: response

Start-Line

: SIP/2.0 400 Malformed SIP URI

From

: <sip:192.168.1.95:49624>;tag=9e6a1da7d3824454bf8f1aebe22cb4b5

To

: <sip:(null)>

CSeq

: 1 NEGOTIATE

Call-ID

: d281df158bed44af8931457aed22c082

ms-user-logon-data

: RemoteUser

Via

: SIP/2.0/TLS 192.168.1.95:49624

Server

: RTC/4.0

Content-Length

: 0

Message-Body

:

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

2.

LogType

: connection

Severity

: error

Text

: Connection was closed because the limit on number of incoming connections per user was exceeded

Local-IP

: 192.168.250.100:443

Peer-IP

: 99.110.130.113:49595

Connection-ID

: 0x74100

Transport

: TLS

November 18th, 2012 2:40am

I see the exact same errors as MCable12 (HRESULT failed: 800780006 = HRESULT_FROM_WIN32(::ShimWSAGetLastError()) . Failed to convert string IP to SOCKADDR, etc.)

My certificates are from a Enterprise CA in the domain, is it the CDP/LDAP issue that's the problem here?

Free Windows Admin Tool Kit Click here and download it now
November 23rd, 2012 7:39pm

My issues with the "modern app" have indeed been solved by changing the certificates on both the pool and the edge (external interface). As they indeed didn't have a http CRL distribution point.

November 27th, 2012 12:34pm

Result!  I fixed the issue with my Lync MX client.  When I checked the Enterprise CA it was running AD Certificate Services but did not have the Certification Authority Web Enrollment role service installed - hence the CRL could not be published to a HTTP source?  I installed this role service and tried the Lync MX client again a day or so later and it successfully logged in for the first time.  Suggest anyone else having trouble with the client and who uses certificates from an AD CA, make sure you've got Certification Authority Web Enrollment role service installed.
  • Proposed as answer by dbooth Tuesday, November 27, 2012 12:08 PM
Free Windows Admin Tool Kit Click here and download it now
November 27th, 2012 3:08pm

Result!  I fixed the issue with my Lync MX client.  When I checked the Enterprise CA it was running AD Certificate Services but did not have the Certification Authority Web Enrollment role service installed - hence the CRL could not be published to a HTTP source?  I installed this role service and tried the Lync MX client again a day or so later and it successfully logged in for the first time.  Suggest anyone else having trouble with the client and who uses certificates from an AD CA, make sure you've got Certification Authority Web Enrollment role service installed.
I already have this installed.  Not working for me
November 27th, 2012 5:19pm

Are you saying it is working for you on your LAN or WAN?  If it is to work on the WAN, would we need to make the HTTP source external accessible?  Seems stupid this app can't work with Lync when everything else (Mobile App, Gourp Chat, etc) all do with no problems.
Free Windows Admin Tool Kit Click here and download it now
November 27th, 2012 5:22pm

If you're using a public certificate (external access) then the CDP will already be pointed to a publically available HTTP resource, for those using certs provisioned from their own CA (internal access) then then the cert needs to publish an HTTP-based CDP as the Lync MX client does not ustilise LDAP.

A

November 27th, 2012 5:32pm

Just making sure I understand and I am not the best at Lync.  Are you talking about the Cert on the client or the Lync edge server?

Free Windows Admin Tool Kit Click here and download it now
November 27th, 2012 5:35pm

This has enabled the Lync MX client to log in whilst on the LAN, I haven't had chance to test it off-LAN yet I will try and test it later.  I guess it depends how long the client will remember or trust how long ago it was last able to check the CRL.
November 27th, 2012 6:03pm

Is there a way to disable CRL checking in Lync MX?
Free Windows Admin Tool Kit Click here and download it now
November 27th, 2012 7:47pm

Are you saying it is working for you on your LAN or WAN?  If it is to work on the WAN, would we need to make the HTTP source external accessible?  Seems stupid this app can't work with Lync when everything else (Mobile App, Gourp Chat, etc) all do with no problems.

The best way to achieve this (IMHO) is to deploy an Online Responder (OCSP) (which could run using HTTP), make this online responder accessible to the outside and make sure the Lync certificates have this AIA available to them (if not you need to re-create, re-request the certificates) to make sure this online responder is being considered use the CA MMC.

http://technet.microsoft.com/en-us/library/cc770413(v=WS.10).aspx 
November 27th, 2012 9:46pm

I tested the Lync MX client on my Surface RT yesterday whilst off-LAN and I just got the Bees Of Death endlessly circling.  This is different to it's previous behaviour off-LAN, it would give the 'Cannot connect to server' message (same as on-LAN before I sorted the CDP).
Free Windows Admin Tool Kit Click here and download it now
November 28th, 2012 2:41pm

I tested the Lync MX client on my Surface RT yesterday whilst off-LAN and I just got the Bees Of Death endlessly circling.  This is different to it's previous behaviour off-LAN, it would give the 'Cannot connect to server' message (same as on-LAN before I sorted the CDP).

Did you sort out the CDP on your external edge interface, as this is the exact behaviour I witnessed when "off Lan", by changing the external edge interface certificate to include the CDP/AIA I could connect "off lan" instantely.
November 28th, 2012 4:20pm

For me Lync was able to sign in after I updated my clock. It was one hour early because I still had a wrong time zone set on my Surface. Go to the desktop. Click the clock. Change date and time -> Internet Time -> Change Settings -> update now.
Free Windows Admin Tool Kit Click here and download it now
December 20th, 2012 9:30pm

I stopped at this point... have a user in IT with RT version.  When they go to login it just says it can't connect.

Had them install CA cert.  Hopefully correctly. 

no change.

I checked the Internal CA and the options mentioned above were not set.  Did not do yet as I want to find out if it will break anything 1st.  Get that we would have to goback to setup wizzard on lync and request new certs and assign.  (currently no edge role and no external access yet)

RT is not domain joined.  If it was would this app work without the CRL settings changed?

Right now I really just  want it to work on the inside.

January 18th, 2013 2:40am

If no external?  have DNS point to inside IP for now?
  • Proposed as answer by Chico BRZ Tuesday, January 22, 2013 1:23 PM
  • Unproposed as answer by Chico BRZ Tuesday, January 22, 2013 1:23 PM
Free Windows Admin Tool Kit Click here and download it now
January 18th, 2013 2:40am

Good morning!

I am facing a problem similar to that described in all posts.
I have a lync 2010 infraesturura implemented an Enterprise pool, array Edge and Mediation.
Access via internal and external client 2010 and 2013 work very well.
External access via mobile works great, android and iOS.
However the lync app does not work at all.
The dns records and certificates are correct and valiados solution by Microsoft.
https://www.testexchangeconnectivity.com/
but the Lync App displays the log errors
ONENABLE_FAIL_SERVER_NOT_REACHABLE
   ACTION: SERVER NOT reachable

detail of all this is that it opens a pop up for authentication, the error happens after that.

Anyone ever had this problem?

regards,
 

Chico
January 22nd, 2013 4:35pm

Good morning!

I could solve my problem!
After a few weeks I ended up solving the following way:
I reviewed all records of Dns, reverse proxy and valid certificates.
I reviewed all my Mobile service implementation was validated by external access via mobile client and the script below:

$ usr1 = Get-Credential
$ usr2 = Get-Credential


Test-CsMcxP2PIM-TargetFQDN poolname-SenderSipAddress SipAddress-SenderCredential $ usr1-ReceiverSipAddress SipAddress-ReceiverCredential $ usr2-v

And the results were favorable.

It was found then installing CU7 Lync.
More my problem was still being presented:
ONENABLE_FAIL_SERVER_NOT_REACHABLE
    ACTION: SERVER NOT reachable

Then I installed fiddler web debugging to start a more accurate troubleshooting of my case.
In one of these checks noticed what existed a web session with the following error

30,500 webapp.maxserver.com HTTPS / Reach / Sip.svc / AuthBroker 576 private text / xml; charset = utf-8 lyncmx: 3292

where in the process the logon pop up login was loaded and pointed to the User and Password, it showed the error of connection with the server.
So I decided to enable the logs of web config folder reach.
was when the error stating that the schedule of the remote host did not fit the server.

then when equated schedules the client functioned normally

I hope this post helps!

thank you,

chico
  • Proposed as answer by Chico BRZ Tuesday, February 05, 2013 6:06 PM
Free Windows Admin Tool Kit Click here and download it now
February 5th, 2013 9:06pm

We are excited to announce the new Microsoft Lync Connectivity Analyzer. This tool will help Lync administrators determine whether the deployment and configuration of their on-premises Lync Server environment meets the requirements to support connections from Lync Windows Store app and Lync mobile apps.

http://blogs.technet.com/b/nexthop/archive/2013/02/08/the-new-lync-connectivity-analyzer.aspx

February 9th, 2013 4:34am

OK, probably good, however, this tool passes for me inside and outside. However:

- Lync Win 8 App works outside but not inside

- Windows Phone doesn't work at all

- Android & iPhone are fine inside and outside

Looks like it needs some more work!

Free Windows Admin Tool Kit Click here and download it now
February 10th, 2013 11:13pm

We are excited to announce the new Microsoft Lync Connectivity Analyzer. This tool will help Lync administrators determine whether the deployment and configuration of their on-premises Lync Server environment meets the requirements to support connections from Lync Windows Store app and Lync mobile apps.

http://blogs.technet.com/b/nexthop/archive/2013/02/08/the-new-lync-connectivity-analyzer.aspx

Thanks guys.  This tool looks like it will be a big help.  I downloaded it this morning and ran it on my local win. 8 client that is having issues and I get a green light with the message -
Your deployment meets the minimum requirements for Lync Windows Store app.

I still get the spinning wheel during sign in.  I would be happy to provide the log files of the analyzer.

February 11th, 2013 7:05pm

Have exactly the same situation.  Lync connectivity analyzer fully green on local network (still can't connect using w8 lync app). From external network I also get that minimum requirements are met (using lyncdiscover only over https) - can't connect using w8 lync app.. Had a little hope something will be changed on Friday update, but still no luck with connecting. Maybe someone found a solution?
  • Edited by TRIUMF Friday, February 22, 2013 11:36 PM
Free Windows Admin Tool Kit Click here and download it now
February 23rd, 2013 2:36am

I'm seeing the same thing.  I'm not part of the department who manages the backend servers for lync, so I cannot access the server side logs or the settings.  I have run many experiments from the various clients both inside and outside our corp network.    Here are my results:

  1. android phone, on 3G data plan, with lync 2010 android client - logs in just fine
  2. windows7, using lync 2010 desktop, external to corp network, - logs in fine
  3. win-8RT, external to corp network, lync communicator from store -  will not connect

I am running latest lync communicator from the store, I got an update on 2/23.  I think the results above are consistent with everyone else. 

The results below maybe show some new data.   my work laptop is windows8.  it's a member of our domain.    I've run the following tests:

  1. win8, lync2010 desktop, not connected to corp vpn - logs in fine
  2. win8, lync2010 desktop, connected to corp vpn - logs in fine
  3. win8, Lync store app(metro), not connected to corp vpn - does not log in
  4. win8, lync store app(metro), connected to corp vpn - logs in fine (with latest version of lyncMX)

BTW - in result 3, when lync metro from store this fails, the 2010 desktop is connected the entire time.  

I have run the lync communicator connectivity analyzer from the windows8 work laptop with the following results:

  1. win8, Lync connectivity analyzer, connected to corp vpn:  your deployment meets the minimum requirements for the lync store app
  2. win8, Lync connectivity analyzer, not connected to corp vpn: your deployment meets the minimum requirements for the Lync store app.

In summary:

  • being on my corp network (via VPN) will allow lync store app to work under win8. 
  • lync store app will not connect from any system outside corp network under win8 or winRT
  • the Lync connectivity analyzer, in all cases (even the failing cases), tells me that our deployment meets the minimum requirements for the lync store app

Since the connectivity analyzer says the store app should work and the lync2010 desktop apps works, i'm thinking the lync store app is still buggy and/or isn't completely compatible with some private lync deployments.    Even if the problem is with the infrastructure, the rest of the clients work across operating systems, so in my view the metro client should as well.  This seems like a major miss. 

Unfortunately my goal is to get this working under windowsRT for work travel.  I don't have VPN client for RT, so i'm stuck like everyone else. 

any thoughts or breakthroughs? 

February 24th, 2013 8:51am

If you're using a public certificate (external access) then the CDP will already be pointed to a publically available HTTP resource, for those using certs provisioned from their own CA (internal access) then then the cert needs to publish an HTTP-based CDP as the Lync MX client does not ustilise LDAP.

A

How can I identify from the logs, that this is indeed the issue?  Before I go through all the work to replace the internal Lync certificates, I would like to know for certain that this is indeed the right solution.
Free Windows Admin Tool Kit Click here and download it now
February 27th, 2013 9:29pm

I managed my problems using this fix: http://support.microsoft.com/kb/2801679

The problem was that Lync FE (Edge also) got update, which updated trusted root certificates. Servers had ~350 of trusted certificates and it was the main problem. After applying the fix windows 8 app started working.

Hope it will solve your problems.

  • Proposed as answer by Andy Rusch Wednesday, April 24, 2013 5:50 PM
March 1st, 2013 4:13pm

I managed my problems using this fix: http://support.microsoft.com/kb/2801679

The problem was that Lync FE (Edge also) got update, which updated trusted root certificates. Servers had ~350 of trusted certificates and it was the main problem. After applying the fix windows 8 app started working.

Hope it will solve your problems.

Thanks, but I have never seen the Events specified in that KB, so I assume that fix will not help me.
Free Windows Admin Tool Kit Click here and download it now
March 1st, 2013 7:48pm

I am having a similar issue, I tried removing the trusted root certificates as this actually caused issues with the LPE handsets we have, although there was another workaround that I used to fix that previously.

I can see in the log on the client that the registration appears to complete but that the client interface never updates to reflect the fact. I can then even see call signalling in the logs when I receive an inbound call via enterprise voice.

After several unauthorised request and then sending back the proper header I get this:

03/28/2013|13:24:37.705 2370:2744 INFO  :: Sending Packet - X.X.X.X:5061 (From Local Address: 192.168.10.9:53909) 930 bytes:
03/28/2013|13:24:37.705 2370:2744 INFO  :: REGISTER sip:domainx.co.uk SIP/2.0

Via: SIP/2.0/TLS 192.168.10.9:53909

Max-Forwards: 70

From: <sip:james.cook@domainx.co.uk>;tag=e2a470264a;epid=713dd99476

To: <sip:james.cook@domainx.co.uk>

Call-ID: 7dc612e9f2f6440da732aff6ea54959c

CSeq: 4 REGISTER

Contact: <sip:192.168.10.9:53909;transport=tls;ms-opaque=03359cb7f3>;proxy=replace;+sip.instance="<urn:uuid:C4D6979B-1082-5774-8279-AAC37472D25A>"

User-Agent: UCCAPIIMM/15.0.4481.1503 LyncImm/15.0.4481.1503 (Microsoft Lync)

Supported: gruu-10, adhoclist, msrtc-event-categories

Supported: ms-forking

Supported: ms-cluster-failover

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

Expires: 7200

Event: registration

Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="32DB1D52", targetname="LYNCENTFE2.vo.domainx.co.uk", crand="8fdff044", cnum="1", response="5523c190a4a0b963b828edfd3ebd12dbe7a6cf9b"

Content-Length: 0




03/28/2013|13:24:37.705 2370:2744 INFO  :: End of Sending Packet - X.X.X.X:5061 (From Local Address: 192.168.10.9:53909) 930 bytes
03/28/2013|13:24:37.705 2370:2744 TRACE :: CSIPAsyncSocket::Send this 0592D1B0, sending pbSendBuf 0584AF78, dwSendBufSize = 930
03/28/2013|13:24:37.705 2370:2744 TRACE :: CSIPAsyncSocket::SendHelper - [0x0592D1B0]
03/28/2013|13:24:37.705 2370:2744 INFO  :: WriteCompletionHandler::WriteCompletionHandler opening txn for write 0A071D40
03/28/2013|13:24:37.706 2370:2744 INFO  :: CAsyncSocketWinRT::Send WriteOperation started 03093F50
03/28/2013|13:24:37.706 2370:2574 INFO  :: WriteCompletionHandler::Invoke WriteOperation completion 03093F50
03/28/2013|13:24:37.706 2370:2574 INFO  :: WriteCompletionHandler::~WriteCompletionHandler closing txn for write 00000000
03/28/2013|13:24:37.706 2370:2744 INFO  :: ~Out trxn corr-id (0586D988)
03/28/2013|13:24:37.709 2370:2744 INFO  :: Bytes Written 930
03/28/2013|13:24:37.761 2370:2040 INFO  :: PushNotificationBackgroundTask::Run - Push notification task ended. ID: {F37B798D-6ABD-4320-8352-51DC57AF47E1}, name: [SignalingNotificationChannel05316FC8], suspended count: 0
03/28/2013|13:24:37.769 2370:2574 INFO  :: ReadCompletionHandler::Invoke ReadOperation completion 03093CB0
03/28/2013|13:24:37.769 2370:2574 INFO  :: CAsyncSocketWinRT::OnReadCompletion entry
03/28/2013|13:24:37.769 2370:2574 INFO  :: CAsyncSocketWinRT::OnReadCompletion opening txn for read to be processed (02A91D00)
03/28/2013|13:24:37.769 2370:2744 INFO  :: CAsyncSocketWinRT::ProcessRead closing read txn (02A91D00), result 0x0, bytesRecv: 2210
03/28/2013|13:24:37.770 2370:2744 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x0592D1B8]
03/28/2013|13:24:37.770 2370:2744 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x0572A090]
03/28/2013|13:24:37.770 2370:2744 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x02A51328]
03/28/2013|13:24:37.770 2370:2744 INFO  :: Data Received -X.X.X.X:5061 (To Local Address: 192.168.10.9:53909) 2210 bytes:
03/28/2013|13:24:37.770 2370:2744 INFO  :: SIP/2.0 200 OK

ms-user-logon-data: RemoteUser

ms-keep-alive: UAS; tcp=no; hop-hop=yes; end-end=no; timeout=900

Authentication-Info: TLS-DSK qop="auth", opaque="32DB1D52", srand="29E650DF", snum="1", rspauth="839a6c6c6877af9ad0ab92773e244a4abeb7d8e9", targetname="LYNCENTFE2.vo.domainx.co.uk", realm="SIP Communications Service", version=4

From: "James Cook"<sip:james.cook@domainx.co.uk>;tag=e2a470264a;epid=713dd99476

To: <sip:james.cook@domainx.co.uk>;tag=D061BA09B9EAE648B063548837C5907E

Call-ID: 7dc612e9f2f6440da732aff6ea54959c

CSeq: 4 REGISTER

Via: SIP/2.0/TLS 192.168.10.9:53909;received=92.233.38.40;ms-received-port=53909;ms-received-cid=C9400

Record-Route: <sip:sip.maindomain.com:5061;transport=tls;opaque=state:Ci.Dc9400;lr;ms-route-sig=gcBftGN9J-m4yBpvQnIfw6l1fScLju5wM_jrFWpoMbDlkSpuGvL9a2zwAA>

Path: <sip:edgepool1.lync.vo.domainx.co.uk:50792;transport=tls;maddr=10.95.141.10;opaque=state:Ee.gcqRWWfxX29I1tIitV1vy2dQAA;lr;ms-received-cid=7C9300>;tag=871644DDB52A403EAFD10A8EAEFCABB7

Contact: <sip:5.133.20.155:56882;transport=tls;ms-opaque=2c803d3fe4;ms-received-cid=A6100>;expires=170;+sip.instance="<urn:uuid:22f9df52-cd66-5589-9fee-dd53aa475f2d>";gruu="sip:james.cook@domainx.co.uk;opaque=user:epid:Ut_5ImbNiVWf7t1TqkdfLQAA;gruu"

Contact: <sip:92.233.38.40:53909;transport=tls;ms-opaque=03359cb7f3;ms-received-cid=C9400>;expires=900;+sip.instance="<urn:uuid:c4d6979b-1082-5774-8279-aac37472d25a>";gruu="sip:james.cook@domainx.co.uk;opaque=user:epid:m5fWxIIQdFeCearDdHLSWgAA;gruu"

Contact: <sip:92.233.38.40:53450;transport=tls;ms-opaque=ff8c7fedb9;ms-received-cid=A2B00>;expires=512;+sip.instance="<urn:uuid:00120ecb-edd2-5b88-ba83-94b291a3e4cd>";gruu="sip:james.cook@domainx.co.uk;opaque=user:epid:yw4SANLtiFu6g5SykaPkzQAA;gruu"

presence-state: register-action="added"

Expires: 900

Allow-Events: vnd-microsoft-provisioning,vnd-microsoft-roaming-contacts,vnd-microsoft-roaming-ACL,presence,presence.wpending,vnd-microsoft-roaming-self,vnd-microsoft-provisioning-v2

Supported: adhoclist

Server: RTC/4.0

Supported: msrtc-event-categories

Supported: ms-keepalive-deregister

Supported: ms-userservices-state-notification

Content-Length: 0




03/28/2013|13:24:37.770 2370:2744 INFO  :: End of Data Received -X.X.X.X:5061 (To Local Address: 192.168.10.9:53909) 2210 bytes
03/28/2013|13:24:37.770 2370:2744 TRACE :: CSIPMessageCollator::AsyncProcessSipMsg - [0x05728210]
03/28/2013|13:24:37.770 2370:2744 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x05728210]
03/28/2013|13:24:37.771 2370:2744 TRACE :: verified buffer: <TLS-DSK><29E650DF><1><SIP Communications Service><LYNCENTFE2.vo.domainx.co.uk><7dc612e9f2f6440da732aff6ea54959c><4><REGISTER><sip:james.cook@domainx.co.uk><e2a470264a><sip:james.cook@domainx.co.uk><D061BA09B9EAE648B063548837C5907E><><><900><200>-length-258. signature:839a6c6c6877af9ad0ab92773e244a4abeb7d8e9
03/28/2013|13:24:37.771 2370:2744 TRACE :: SA(5491b28) Established 
03/28/2013|13:24:37.771 2370:2744 TRACE :: SA(5491b28) state change(3)=(4)
03/28/2013|13:24:37.771 2370:2744 INFO  :: SIP_AUTH(0536ECAC) AsyncNotify SA Established
03/28/2013|13:24:37.771 2370:2744 INFO  :: Trxn corr-id (0586D778), SIP msg corr-id (976abd6f)
03/28/2013|13:24:37.771 2370:2744 INFO  :: CRegistrationRefreshScheduler::OnRegistrationSucceeded - Marked a successful regn refresh.
03/28/2013|13:24:37.771 2370:2744 TRACE :: CUccPrincipalServerEndpoint::ProcessSetProviderPropertyUINT - SIP_PROVIDER_PROPERTY_CLUSTER, 0
03/28/2013|13:24:37.771 2370:2744 TRACE :: CUccPrincipalServerEndpoint::ProcessSetProviderPropertyUINT - SIP_PROVIDER_PROPERTY_CONN_TO_PRIMARY, 0
03/28/2013|13:24:37.771 2370:2744 TRACE :: CUccPrincipalServerEndpoint::ProcessSetProviderPropertyUINT - SIP_PROVIDER_PROPERTY_USC, 0
03/28/2013|13:24:37.772 2370:2744 ERROR :: REGISTER_CONTEXT::HandleRegistrationSuccess - ParseMsUserLogonDataHeader - hr=0x00000000, bRemoteUser=1
03/28/2013|13:24:37.772 2370:2744 TRACE :: CSIPTransportLayerNotify::CSIPTransportLayerNotify - [0x0584A908]
03/28/2013|13:24:37.772 2370:2744 TRACE :: CSIPWhiteSpaceKeepAlive::CSIPWhiteSpaceKeepAlive - [0x0584A908]
03/28/2013|13:24:37.772 2370:2744 TRACE :: CSIPWhiteSpaceKeepAlive::Initialize - [0x0584A908]
03/28/2013|13:24:37.774 2370:2744 TRACE :: CSIPWhiteSpaceKeepAlive::StartTimerHelper Not using regular timer, this 0584A908
03/28/2013|13:24:37.774 2370:2744 INFO  :: REGISTER_CONTEXT(586ae48) SetAndNotify Recv(1) at State (1)
03/28/2013|13:24:37.774 2370:2744 INFO  :: Function: SIP_CALLMGR::RefreshRouteForAllDialogs
03/28/2013|13:24:37.774 2370:2744 ERROR :: HRESULT API failed: 80004005 = pSipMsgProc->InternalRefreshRoute()
03/28/2013|13:24:37.774 2370:2744 WARN  :: CUccPrincipalServerEndpoint::NotifySuspended suspended [no], no change, this 0574C370
03/28/2013|13:24:37.774 2370:2744 TRACE :: OUTGOING_REGISTER_TRANSACTION::ProcessSuccessfulResponse received 200 Registration SUCCEEDED
03/28/2013|13:24:37.774 2370:2744 INFO  :: ~Out trxn corr-id (0586D778)
03/28/2013|13:24:37.774 2370:2744 INFO  :: SIP_AUTH(536ecac) SetState (1) => (2)
03/28/2013|13:24:37.786 2370:2040 INFO  :: PushNotificationBackgroundTask::Run - Push notification task invoked. ID: {F37B798D-6ABD-4320-8352-51DC57AF47E1}, name: [SignalingNotificationChannel05316FC8], suspended count: 0
03/28/2013|13:24:37.787 2370:2040 INFO  :: PushNotificationBackgroundTask::Run - Push notification task ended. ID: {F37B798D-6ABD-4320-8352-51DC57AF47E1}, name: [SignalingNotificationChannel05316FC8], suspended count: 0
03/28/2013|13:28:36.555 2370:19D4 INFO  :: KeepAliveBackgroundTask::Run - Keep alive task invoked. ID: {9F76E760-AD0E-4E4F-83F6-5DD10488EBC4}, name: [42], suspended count: 0
03/28/2013|13:28:36.559 2370:2744 TRACE :: CSipTlsDskSecAssociationImm::OnWhiteSpaceTimerExpire - Entered
03/28/2013|13:28:36.560 2370:2744 INFO  :: CSipTlsDskSecAssociationImm::IsSARefreshNeeded - IsSARefreshNeeded: 0
03/28/2013|13:28:36.562 2370:2744 INFO  :: this(0536ECAC) - SA(05491B28) reported OnWhiteSpaceTimerExpire(240000l)
03/28/2013|13:28:36.563 2370:2744 INFO  :: CRegistrationRefreshScheduler::IsRegistrationNeeded - IsRegistrationNeeded: 0
03/28/2013|13:28:36.564 2370:2744 INFO  :: CSIPWhiteSpaceKeepAlive::OnTimerExpire 0584A908
03/28/2013|13:28:36.565 2370:2744 TRACE :: CRegistrationRefreshScheduler::OnMessage - Received event WM_REGISTRATION_REFRESH_EVENT
03/28/2013|13:28:36.566 2370:2744 INFO  :: Out trxn corr-id (0586C1D0)
03/28/2013|13:28:36.567 2370:2744 ERROR :: SIP_MSG_PROCESSOR::GetLocalConnectionAddrSubnet get subnetmask failed
03/28/2013|13:28:36.568 2370:2744 INFO  :: SIP_MSG_PROCESSOR::GetSubnetHeader Invalid subnet -1
03/28/2013|13:28:36.570 2370:2744 INFO  :: Trxn corr-id (0586C1D0), SIP msg corr-id (976abd6f)
03/28/2013|13:28:36.571 2370:2744 INFO  :: Sending Packet - X.X.X.X:5061 (From Local Address: 192.168.10.9:53909) 930 bytes:
03/28/2013|13:28:36.572 2370:2744 INFO  :: REGISTER sip:domainx.co.uk SIP/2.0

Via: SIP/2.0/TLS 192.168.10.9:53909

Max-Forwards: 70

From: <sip:james.cook@domainx.co.uk>;tag=e2a470264a;epid=713dd99476

To: <sip:james.cook@domainx.co.uk>

Call-ID: 7dc612e9f2f6440da732aff6ea54959c

CSeq: 5 REGISTER

Contact: <sip:192.168.10.9:53909;transport=tls;ms-opaque=03359cb7f3>;proxy=replace;+sip.instance="<urn:uuid:C4D6979B-1082-5774-8279-AAC37472D25A>"

User-Agent: UCCAPIIMM/15.0.4481.1503 LyncImm/15.0.4481.1503 (Microsoft Lync)

Supported: gruu-10, adhoclist, msrtc-event-categories

Supported: ms-forking

Supported: ms-cluster-failover

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

Expires: 7200

Event: registration

Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="32DB1D52", targetname="LYNCENTFE2.vo.domainx.co.uk", crand="ffb06f29", cnum="2", response="7c410fcc2489c6c252faac0fdc435e6282ad2f6d"

Content-Length: 0




03/28/2013|13:28:36.576 2370:2744 INFO  :: End of Sending Packet - X.X.X.X:5061 (From Local Address: 192.168.10.9:53909) 930 bytes
03/28/2013|13:28:36.577 2370:2744 TRACE :: CSIPAsyncSocket::Send this 0592D1B0, sending pbSendBuf 0572E2D0, dwSendBufSize = 930
03/28/2013|13:28:36.578 2370:2744 TRACE :: CSIPAsyncSocket::SendHelper - [0x0592D1B0]
03/28/2013|13:28:36.580 2370:2744 INFO  :: WriteCompletionHandler::WriteCompletionHandler opening txn for write 0572E098
03/28/2013|13:28:36.582 2370:2744 INFO  :: CAsyncSocketWinRT::Send WriteOperation started 0527A730
03/28/2013|13:28:36.583 2370:2744 INFO  :: WriteCompletionHandler::Invoke WriteOperation completion 0527A730
03/28/2013|13:28:36.585 2370:2744 INFO  :: WriteCompletionHandler::~WriteCompletionHandler closing txn for write 00000000
03/28/2013|13:28:36.586 2370:2744 INFO  :: REGISTER_CONTEXT(586ae48) SetAndNotify Recv(4) at State (1)
03/28/2013|13:28:36.587 2370:2744 TRACE :: CSIPWhiteSpaceKeepAlive::StartTimerHelper Not using regular timer, this 0584A908
03/28/2013|13:28:36.588 2370:2744 INFO  :: Bytes Written 930
03/28/2013|13:28:36.590 2370:19D4 INFO  :: KeepAliveBackgroundTask::Run - Keep alive task ended. ID: {9F76E760-AD0E-4E4F-83F6-5DD10488EBC4}, name: [42], suspended count: 0
03/28/2013|13:28:36.842 2370:1AC4 INFO  :: ReadCompletionHandler::Invoke ReadOperation completion 0565AB98
03/28/2013|13:28:36.844 2370:1AC4 INFO  :: CAsyncSocketWinRT::OnReadCompletion entry
03/28/2013|13:28:36.846 2370:1AC4 INFO  :: CAsyncSocketWinRT::OnReadCompletion opening txn for read to be processed (02A91AC0)
03/28/2013|13:28:36.848 2370:2744 INFO  :: CAsyncSocketWinRT::ProcessRead closing read txn (02A91AC0), result 0x0, bytesRecv: 2518
03/28/2013|13:28:36.849 2370:2744 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x0592D1B8]
03/28/2013|13:28:36.851 2370:2744 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x0572A090]
03/28/2013|13:28:36.853 2370:2744 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x02A51328]
03/28/2013|13:28:36.854 2370:2744 INFO  :: Data Received -X.X.X.X:5061 (To Local Address: 192.168.10.9:53909) 2518 bytes:
03/28/2013|13:28:36.856 2370:2744 INFO  :: SIP/2.0 200 OK

ms-user-logon-data: RemoteUser

ms-keep-alive: UAS; tcp=no; hop-hop=yes; end-end=no; timeout=900

Authentication-Info: TLS-DSK qop="auth", opaque="32DB1D52", srand="C93EE7C0", snum="2", rspauth="5da86ebf8571d115be21dc16405b22b0a3fceda2", targetname="LYNCENTFE2.vo.domainx.co.uk", realm="SIP Communications Service", version=4

From: "James Cook"<sip:james.cook@domainx.co.uk>;tag=e2a470264a;epid=713dd99476

To: <sip:james.cook@domainx.co.uk>;tag=D061BA09B9EAE648B063548837C5907E

Call-ID: 7dc612e9f2f6440da732aff6ea54959c

CSeq: 5 REGISTER

Via: SIP/2.0/TLS 192.168.10.9:53909;received=92.233.38.40;ms-received-port=53909;ms-received-cid=C9400

Record-Route: <sip:sip.maindomain.com:5061;transport=tls;opaque=state:Ci.Rc9400;lr;ms-route-sig=gc8qvm8Y8hLpEgOSXM1JjWbhz7k9lVTovUN4IlGtzxx92BEtB3L9a2zwAA>

Path: <sip:edgepool1.lync.vo.domainx.co.uk:50792;transport=tls;maddr=10.95.141.10;opaque=state:Ee.gc1uBXWRDBEnFKMTnYcKozTgAA;lr;ms-received-cid=7C9300>;tag=871644DDB52A403EAFD10A8EAEFCABB7

Contact: <sip:frontendpool1.lync.vo.domainx.co.uk:5087;ms-fe=LYNCENTFE2.vo.domainx.co.uk;transport=Tls;ms-opaque=0e08ffbcc8875452>;expires=1578;+sip.instance="<urn:uuid:2fa20129-7ce0-5769-ba7a-f3c8af7ece4f>";gruu="sip:james.cook@domainx.co.uk;opaque=user:epid:KQGiL-B8aVe6evPIr37OTwAA;gruu"

Contact: <sip:5.133.20.155:56882;transport=tls;ms-opaque=2c803d3fe4;ms-received-cid=A6100>;expires=404;+sip.instance="<urn:uuid:22f9df52-cd66-5589-9fee-dd53aa475f2d>";gruu="sip:james.cook@domainx.co.uk;opaque=user:epid:Ut_5ImbNiVWf7t1TqkdfLQAA;gruu"

Contact: <sip:92.233.38.40:53909;transport=tls;ms-opaque=03359cb7f3;ms-received-cid=C9400>;expires=900;+sip.instance="<urn:uuid:c4d6979b-1082-5774-8279-aac37472d25a>";gruu="sip:james.cook@domainx.co.uk;opaque=user:epid:m5fWxIIQdFeCearDdHLSWgAA;gruu"

Contact: <sip:92.233.38.40:53450;transport=tls;ms-opaque=ff8c7fedb9;ms-received-cid=A2B00>;expires=273;+sip.instance="<urn:uuid:00120ecb-edd2-5b88-ba83-94b291a3e4cd>";gruu="sip:james.cook@domainx.co.uk;opaque=user:epid:yw4SANLtiFu6g5SykaPkzQAA;gruu"

presence-state: register-action="refreshed"

Expires: 900

Allow-Events: vnd-microsoft-provisioning,vnd-microsoft-roaming-contacts,vnd-microsoft-roaming-ACL,presence,presence.wpending,vnd-microsoft-roaming-self,vnd-microsoft-provisioning-v2

Supported: adhoclist

Server: RTC/4.0

Supported: msrtc-event-categories

Supported: ms-keepalive-deregister

Supported: ms-userservices-state-notification

Content-Length: 0




03/28/2013|13:28:36.861 2370:2744 INFO  :: End of Data Received -X.X.X.X:5061 (To Local Address: 192.168.10.9:53909) 2518 bytes

Does the above logging mean that it was successfully registered against the server?

Also just after this I can see INVITE sip requests for inbound calls.

Has anyone else come across this?

March 28th, 2013 5:11pm

Thank you very, very much!
Free Windows Admin Tool Kit Click here and download it now
April 24th, 2013 8:51pm

Is Lync MC on the Surface RT capable of working in a coporate environment with a Lync Server 2010 or 2013 backend?

If the SIP and username/domain/password settings are correct, is it likely that the issue is with the backend server/firewall settings?

Is it possible to get into more detailed settings/config of the Lync MX app on the Surface RT?

August 8th, 2013 5:36pm

what are you running for your RP?  You need to enable hairpining or at least spoofing.  My setup is this and I finally got it working. Does it work for you when not on the internal network?

Internal DNS -

Lyncdiscover on the internal DNS points to my RP-ARR server of the Internal IP address.

Lyncdiscoverinternal points to my FE server

External Web service points to the internal IP of the RP server

Internal Web service points to FE server.

Download and install Fiddler.  You need to set up in the options to De-crypt all https traffic.  You also need to set up the windows 8 settings.  uncheck all and then check the Lync app and the Microsoft Store checkbox.  Close Fiddler and open task manager to make sure your Lync client is completely closed.  Relaunch fiddler and then open Lync and try to sign in.  If you get the grey box for your cred make sure you put your domain\user account in this format and then your password.  once you do that go back to fiddler and you can watch the connection path and figure out where the client is trying to connect to.  It will use either the internal or the external web services.  Microsoft tried to tell me it always uses the external but I proved that wasn't the case.

I have to manually install the internal CA root cert on the devices.  I will be getting a public cert and installing it on the Lync server that way I dont have to manage users personal devices that are not domain joined.

Free Windows Admin Tool Kit Click here and download it now
August 8th, 2013 6:12pm

I have this same issue...  I am attempting to connect internally ..   Other clients work fine.. but Lync Modern app .. fails to authenticate.

Trace show:

VerifyOnEnableEvent result return 13

     ONENABLE_FAIL_AUTH_FAIL

   status=0x80ee00a6

authWebserviceBaseUrl=https://my.lyncfe.com:443/CertProv/CertProvisioningService.svc

ACTION: AUTH FAIL

then it prompts for credentials again...  Obviously once again.. at MS .. the right hand has no clue what the left hand is doing..  #fail.

January 9th, 2014 11:58pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics