Technology Tips and News
I have an iPhone 5(?) and I installed the lync2010 client on it and can sign in just fine. So can another user here that has the low end version of the iPhone 6, the lync client works just fine.
But people here that have the iPhone 6S or Galaxy 5s cannot
I checked their settings and they mach mine (except user name and password of course lol)
The message they get just say 'cannt log on' its just weird that those phones dont work.... any ideas?
are they on the internal wifi?
If they were to disconnect from wifi and use mobile network - can they sign in?
well, do you have a reverse proxy that is setup to route the internet:443 traffic to the FE:4443 and a public cert on the RP?
ALSO, send yourself a copy of the logs from the mobile client and see what those logs say ... post them. That would help - cert issues show up pretty clearly in the logs.
I will get their logs when I find were the people wandered off to.
not sure about a reverse proxy, but if that wasn't working then nobody would be able to get it working right? its just these 2 phone models that have been reported to me as not working
not necessarily ... let's say that your admin was cheap and didn't get a RP and just port forwarded :443 to FE:443 and that IIS site has internal certs in the bindings - then, your subset of working devices happen to have the trusted SSL chain installed - in that scenario those phones would work. I'm just wondering if you have a standard setup.
If you're just saying that you have tons of phones working and 2 phones that don't - I agree - it's probably not your RP -> FE setup.
I did find where it says https is listening on port 4443.
It isn't just 2 phones, its just these 2 phone models.
Also, it has been said elsewhere that you should check your client versioning policies in Lync. This also is known to cause things such as this:
https://technet.microsoft.com/en-us/library/jj898475.aspx
https://social.technet.microsoft.com/forums/lync/en-US/cffe0e55-db45-4c65-91ce-ee3783702ed1/unable-to-login-via-lync-for-android
well, I guess management wants to have it running on their cell phones while in the building using our internal wi-fi, which has limited lan conectivity due to firewall rules.
What port needs to be open so I can see if that is the issue?
My phone cannot connect when using the internal wi-fi
here is the log file
oh snap. Really. So, you're only using it internally, not externally? Then you're going to run into SSL issues.
Here's some TMI ....
So, here's how we did it, with a recommendation from our friends at Modality - we setup a internal VIP on our F5 that we put a public certificates on that had all of the FQDNs of our Internal web services on the SAN - DNS pointed the internal web services FQDN's to this F5 VIP. So, we have a public cert on the web services therefore the mobile clients (droid, ipad, windows phone, app store client) can all join while connected to the internal WIFI and not run into certificate issues.
We did that because of the requirements of having the machine name in the cert - thus, making public (comodo) certs not an optoins as we have a machine.domain.local scheme.
Here is the mobility stuff ... as if you don't' have this already .
https://technet.microsoft.com/en-us/library/hh690030.aspx?f=255&MSPPError=-2147217396
The way to troubleshoot this is to instal your certs on the non-working phone and see if they can then signin. I'll look at the log right quick....
Also there is little doubt that you are getting SSL errors in your log. FYI. the following appears after each attempt to https://lyncdiscoverinternal.domain.com/....
CFNetwork SSLHandshake failed (-9807)
painfully enough......
They want it to work internal AND external
How do I go about getting the certs so I can install them on the phone?
export your internal web services SSL cert (the pool one is fine, and get the whole chain in there) into a DER encoded X.509 .cer file. ZIP the cert and email it to your phone. install it from there. It will install from the email client when you launch the attachment (per my recollection, it's been a few years)
Before we can really talk about getting mobility externally accessible - you'll need to know about how your reverse proxy is setup.
The scope of this chain, it's getting long now . .lol... was getting the mobile clients logged in. I think with the certs we will.
You just have to be SURE that you have installed the ROOT CA cert and any (if applicable) intermediate signing certs. If you paste the text of your CER into https://www.sslshopper.com/certificate-decoder.html (although you'll have to convert it to pem first) do you get all of the signing certs in there?
Reboot the phone too ... not sure if that is required. There are several incidents that seem to say that a reboot is required on android
http://stackoverflow.com/questions/4461360/how-to-install-trusted-ca-certificate-on-android-device
are they on the internal wifi?
If they were to disconnect from wifi and use mobile network - can they sign in?
are they on the internal wifi?
If they were to disconnect from wifi and use mobile network - can they sign in?
are they on the internal wifi?
If they were to disconnect from wifi and use mobile network - can they sign in?
are they on the internal wifi?
If they were to disconnect from wifi and use mobile network - can they sign in?
are they on the internal wifi?
If they were to disconnect from wifi and use mobile network - can they sign in?
are they on the internal wifi?
If they were to disconnect from wifi and use mobile network - can they sign in?
well, do you have a reverse proxy that is setup to route the internet:443 traffic to the FE:4443 and a public cert on the RP?
ALSO, send yourself a copy of the logs from the mobile client and see what those logs say ... post them. That would help - cert issues show up pretty clearly in the logs.
well, do you have a reverse proxy that is setup to route the internet:443 traffic to the FE:4443 and a public cert on the RP?
ALSO, send yourself a copy of the logs from the mobile client and see what those logs say ... post them. That would help - cert issues show up pretty clearly in the logs.
well, do you have a reverse proxy that is setup to route the internet:443 traffic to the FE:4443 and a public cert on the RP?
ALSO, send yourself a copy of the logs from the mobile client and see what those logs say ... post them. That would help - cert issues show up pretty clearly in the logs.
well, do you have a reverse proxy that is setup to route the internet:443 traffic to the FE:4443 and a public cert on the RP?
ALSO, send yourself a copy of the logs from the mobile client and see what those logs say ... post them. That would help - cert issues show up pretty clearly in the logs.
well, do you have a reverse proxy that is setup to route the internet:443 traffic to the FE:4443 and a public cert on the RP?
ALSO, send yourself a copy of the logs from the mobile client and see what those logs say ... post them. That would help - cert issues show up pretty clearly in the logs.
well, do you have a reverse proxy that is setup to route the internet:443 traffic to the FE:4443 and a public cert on the RP?
ALSO, send yourself a copy of the logs from the mobile client and see what those logs say ... post them. That would help - cert issues show up pretty clearly in the logs.
Ok, after Installing all the certs in the chain, I dont see the SSLHandshake message anymore.
But now (very quickly) when trying to sign in (internal network) the message on the screen says
"Can't sign in. Please check your account information and try again"
But, if I turn wi-fi off and connect externally, it works just fine. (I did restart the phone)
i am unsure why, but I assumed that your users could NOT log into the system using external access. If this is the case, you need to consider hairpinning the users to the external web services.
https://social.technet.microsoft.com/forums/lync/en-US/3a11d1f6-1190-4c82-9175-2d8ac19627a8/lync-mobility-for-internal-users-and-hairpinning
please research this . it entails getting rid of the lyncdiscoverinternal dns record internally and exposing the lyncdiscover dns record internally, and having the usres hairpin through the RP into the external web services on the FE - and the internal cert challenge is moot. I am sorry that this goes on and on...
also, re: getting rid of the SSL error, good - make sure that in OPTIONS that are specifying domain\samaccountname in there ... see if that works. Along with the sipaddress on the main screen.
yes, the "domain\sameaccountname" is set.
I will look at the link you posted
from outside the wifi, if I ping lyncdiscover.mydomain.com I get an external ip...(as expected)
if i ping lyncdiscover.mydomain.com, I get the internal address of the Lync FE machine.
If I understand correctly...... I need to make it so that points to the external address. correct?
If that is correct.....will that have any bad effects on the desktop clients?
If you have people running the 2013 client, it could. The 2013 client shifted from preferring SRV records to ARECORDS and the lyncdiscover record is higher in the order than the SRV records IF the lyncdiscoverinternal does not exist. As long as you don't have 2013 clients - you're good. You can test it, I think that the 2013 client will log in ... just over the EDGE.
It's really catch 22 that you're in.
at my desk, I have the 2013 client. I modified my Hosts file to make lyncdiscover.mydomain.com point to the public address. I closed and reopened the client and it works fine
Guess I will need to 'test' with DNS
there you have it then. The only affect that I noticed when I migrated to the 2013 client was the fact that my client was connecting externally (like, internal=FALSE) when I looked at the configuration. Better that than having to manage 1 trillion (or, 7) mobile devices. Ax the lyncdiscoverinternal and tell your bosses how great you are.
Again, initially, i was under the understanding that your users were unable to connect wither they were WIFI or e.g. 4G. You stated 'that was the first thing you checked' therefore it led us down this path. If they were able to connect 4g, we could have discussed this option a while back. Sorry if i misunderstood.
Plesae refer to this article as well for manual configuration of android.
https://support.getcloudservices.com/entries/26481810-Lync-Mobility-Manual-Configuration-of-Lync-2013-for-Android
export your internal web services SSL cert (the pool one is fine, and get the whole chain in there) into a DER encoded X.509 .cer file. ZIP the cert and email it to your phone. install it from there. It will install from the email client when you launch the attachment (per my recollection, it's been a few years)
Before we can really talk about getting mobility externally accessible - you'll need to know about how your reverse proxy is setup.
The scope of this chain, it's getting long now . .lol... was getting the mobile clients logged in. I think with the certs we will.
export your internal web services SSL cert (the pool one is fine, and get the whole chain in there) into a DER encoded X.509 .cer file. ZIP the cert and email it to your phone. install it from there. It will install from the email client when you launch the attachment (per my recollection, it's been a few years)
Before we can really talk about getting mobility externally accessible - you'll need to know about how your reverse proxy is setup.
The scope of this chain, it's getting long now . .lol... was getting the mobile clients logged in. I think with the certs we will.
export your internal web services SSL cert (the pool one is fine, and get the whole chain in there) into a DER encoded X.509 .cer file. ZIP the cert and email it to your phone. install it from there. It will install from the email client when you launch the attachment (per my recollection, it's been a few years)
Before we can really talk about getting mobility externally accessible - you'll need to know about how your reverse proxy is setup.
The scope of this chain, it's getting long now . .lol... was getting the mobile clients logged in. I think with the certs we will.
export your internal web services SSL cert (the pool one is fine, and get the whole chain in there) into a DER encoded X.509 .cer file. ZIP the cert and email it to your phone. install it from there. It will install from the email client when you launch the attachment (per my recollection, it's been a few years)
Before we can really talk about getting mobility externally accessible - you'll need to know about how your reverse proxy is setup.
The scope of this chain, it's getting long now . .lol... was getting the mobile clients logged in. I think with the certs we will.
export your internal web services SSL cert (the pool one is fine, and get the whole chain in there) into a DER encoded X.509 .cer file. ZIP the cert and email it to your phone. install it from there. It will install from the email client when you launch the attachment (per my recollection, it's been a few years)
Before we can really talk about getting mobility externally accessible - you'll need to know about how your reverse proxy is setup.
The scope of this chain, it's getting long now . .lol... was getting the mobile clients logged in. I think with the certs we will.
export your internal web services SSL cert (the pool one is fine, and get the whole chain in there) into a DER encoded X.509 .cer file. ZIP the cert and email it to your phone. install it from there. It will install from the email client when you launch the attachment (per my recollection, it's been a few years)
Before we can really talk about getting mobility externally accessible - you'll need to know about how your reverse proxy is setup.
The scope of this chain, it's getting long now . .lol... was getting the mobile clients logged in. I think with the certs we will.
You just have to be SURE that you have installed the ROOT CA cert and any (if applicable) intermediate signing certs. If you paste the text of your CER into https://www.sslshopper.com/certificate-decoder.html (although you'll have to convert it to pem first) do you get all of the signing certs in there?
Reboot the phone too ... not sure if that is required. There are several incidents that seem to say that a reboot is required on android
http://stackoverflow.com/questions/4461360/how-to-install-trusted-ca-certificate-on-android-device
You just have to be SURE that you have installed the ROOT CA cert and any (if applicable) intermediate signing certs. If you paste the text of your CER into https://www.sslshopper.com/certificate-decoder.html (although you'll have to convert it to pem first) do you get all of the signing certs in there?
Reboot the phone too ... not sure if that is required. There are several incidents that seem to say that a reboot is required on android
http://stackoverflow.com/questions/4461360/how-to-install-trusted-ca-certificate-on-android-device
You just have to be SURE that you have installed the ROOT CA cert and any (if applicable) intermediate signing certs. If you paste the text of your CER into https://www.sslshopper.com/certificate-decoder.html (although you'll have to convert it to pem first) do you get all of the signing certs in there?
Reboot the phone too ... not sure if that is required. There are several incidents that seem to say that a reboot is required on android
http://stackoverflow.com/questions/4461360/how-to-install-trusted-ca-certificate-on-android-device
You just have to be SURE that you have installed the ROOT CA cert and any (if applicable) intermediate signing certs. If you paste the text of your CER into https://www.sslshopper.com/certificate-decoder.html (although you'll have to convert it to pem first) do you get all of the signing certs in there?
Reboot the phone too ... not sure if that is required. There are several incidents that seem to say that a reboot is required on android
http://stackoverflow.com/questions/4461360/how-to-install-trusted-ca-certificate-on-android-device
You just have to be SURE that you have installed the ROOT CA cert and any (if applicable) intermediate signing certs. If you paste the text of your CER into https://www.sslshopper.com/certificate-decoder.html (although you'll have to convert it to pem first) do you get all of the signing certs in there?
Reboot the phone too ... not sure if that is required. There are several incidents that seem to say that a reboot is required on android
http://stackoverflow.com/questions/4461360/how-to-install-trusted-ca-certificate-on-android-device
You just have to be SURE that you have installed the ROOT CA cert and any (if applicable) intermediate signing certs. If you paste the text of your CER into https://www.sslshopper.com/certificate-decoder.html (although you'll have to convert it to pem first) do you get all of the signing certs in there?
Reboot the phone too ... not sure if that is required. There are several incidents that seem to say that a reboot is required on android
http://stackoverflow.com/questions/4461360/how-to-install-trusted-ca-certificate-on-android-device
yes, the "domain\sameaccountname" is set.
I will look at the link you posted
yes, the "domain\sameaccountname" is set.
I will look at the link you posted
yes, the "domain\sameaccountname" is set.
I will look at the link you posted
yes, the "domain\sameaccountname" is set.
I will look at the link you posted
yes, the "domain\sameaccountname" is set.
I will look at the link you posted
yes, the "domain\sameaccountname" is set.
I will look at the link you posted
there you have it then. The only affect that I noticed when I migrated to the 2013 client was the fact that my client was connecting externally (like, internal=FALSE) when I looked at the configuration. Better that than having to manage 1 trillion (or, 7) mobile devices. Ax the lyncdiscoverinternal and tell your bosses how great you are.
Again, initially, i was under the understanding that your users were unable to connect wither they were WIFI or e.g. 4G. You stated 'that was the first thing you checked' therefore it led us down this path. If they were able to connect 4g, we could have discussed this option a while back. Sorry if i misunderstood.
Plesae refer to this article as well for manual configuration of android.
https://support.getcloudservices.com/entries/26481810-Lync-Mobility-Manual-Configuration-of-Lync-2013-for-Android
there you have it then. The only affect that I noticed when I migrated to the 2013 client was the fact that my client was connecting externally (like, internal=FALSE) when I looked at the configuration. Better that than having to manage 1 trillion (or, 7) mobile devices. Ax the lyncdiscoverinternal and tell your bosses how great you are.
Again, initially, i was under the understanding that your users were unable to connect wither they were WIFI or e.g. 4G. You stated 'that was the first thing you checked' therefore it led us down this path. If they were able to connect 4g, we could have discussed this option a while back. Sorry if i misunderstood.
Plesae refer to this article as well for manual configuration of android.
https://support.getcloudservices.com/entries/26481810-Lync-Mobility-Manual-Configuration-of-Lync-2013-for-Android
there you have it then. The only affect that I noticed when I migrated to the 2013 client was the fact that my client was connecting externally (like, internal=FALSE) when I looked at the configuration. Better that than having to manage 1 trillion (or, 7) mobile devices. Ax the lyncdiscoverinternal and tell your bosses how great you are.
Again, initially, i was under the understanding that your users were unable to connect wither they were WIFI or e.g. 4G. You stated 'that was the first thing you checked' therefore it led us down this path. If they were able to connect 4g, we could have discussed this option a while back. Sorry if i misunderstood.
Plesae refer to this article as well for manual configuration of android.
https://support.getcloudservices.com/entries/26481810-Lync-Mobility-Manual-Configuration-of-Lync-2013-for-Android
there you have it then. The only affect that I noticed when I migrated to the 2013 client was the fact that my client was connecting externally (like, internal=FALSE) when I looked at the configuration. Better that than having to manage 1 trillion (or, 7) mobile devices. Ax the lyncdiscoverinternal and tell your bosses how great you are.
Again, initially, i was under the understanding that your users were unable to connect wither they were WIFI or e.g. 4G. You stated 'that was the first thing you checked' therefore it led us down this path. If they were able to connect 4g, we could have discussed this option a while back. Sorry if i misunderstood.
Plesae refer to this article as well for manual configuration of android.
https://support.getcloudservices.com/entries/26481810-Lync-Mobility-Manual-Configuration-of-Lync-2013-for-Android
there you have it then. The only affect that I noticed when I migrated to the 2013 client was the fact that my client was connecting externally (like, internal=FALSE) when I looked at the configuration. Better that than having to manage 1 trillion (or, 7) mobile devices. Ax the lyncdiscoverinternal and tell your bosses how great you are.
Again, initially, i was under the understanding that your users were unable to connect wither they were WIFI or e.g. 4G. You stated 'that was the first thing you checked' therefore it led us down this path. If they were able to connect 4g, we could have discussed this option a while back. Sorry if i misunderstood.
Plesae refer to this article as well for manual configuration of android.
https://support.getcloudservices.com/entries/26481810-Lync-Mobility-Manual-Configuration-of-Lync-2013-for-Android
there you have it then. The only affect that I noticed when I migrated to the 2013 client was the fact that my client was connecting externally (like, internal=FALSE) when I looked at the configuration. Better that than having to manage 1 trillion (or, 7) mobile devices. Ax the lyncdiscoverinternal and tell your bosses how great you are.
Again, initially, i was under the understanding that your users were unable to connect wither they were WIFI or e.g. 4G. You stated 'that was the first thing you checked' therefore it led us down this path. If they were able to connect 4g, we could have discussed this option a while back. Sorry if i misunderstood.
Plesae refer to this article as well for manual configuration of android.
https://support.getcloudservices.com/entries/26481810-Lync-Mobility-Manual-Configuration-of-Lync-2013-for-Android
Hi,
Would you please elaborate your Lync Server environment?
1. You need to deploy a Reverse Proxy in DMZ zone to support external/ internal mobile function.
2. For Lync Server 2010, if you not use Lync 2013 desktop client, you can configure one or both of the lyncdiscover or lyncdiscoverinternal DNS host records located on internal DNS zones to point directly to the external IP address of the Reverse Proxy.
3. As you have Lync 2013 desktop client, in internal DNS zone, if you point lyncdiscover or lyncdiscoverinternal DNS host records to the external IP of the Reverse Proxy, the Lync 2013 desktop client will login using lyncdiscoverinternal or lyncdiscover DNS host records as the external user.
4. It is supported to make the hairpinning setting in DMZ zone, so the correct workflow for the internal Lync mobile user is as following: users device must be able to query the internal DNS zone and resolve the external Lync Web Services FQDN to the IP address of the external interface of the reverse proxy. The user will then make an outbound, hair-pinned connection to the Mobility Service through the reverse proxy.
More details:
https://technet.microsoft.com/en-us/library/hh690030(v=ocs.14).aspx
Best Regards,
Eason
I did check that the user I was first working with was not connected to wi-fi, and is not able to log in.
Then as I was working on it, I was informed that they (and others) need to be able to connect either way, wi-fi or no wi-fi.
So basicly, the scope of the issue started getting larger and larger...
I do appreciate your help and patience
the only dns entry I have found is lyncdiscover.... haven't seen anything for lyncdiscoverinternal.
ok. good. if that's the case, your mobile clients will find the lyncdiscover.sipdomain.com record (that has to point to the external ip of the reverse proxy... not internal). The mobile clients and the Lync 2013 clients will then hairpin through the RP to login.
I am told that the only real downside to that is 'media optimization' is not optimal. however, i'd really wonder if that's the case with how TURN/ICE/STUN do media negotiation ... maybe there's info out there on that somewhere or if somebody knows the true consequence of this configuration. (but, I think in your case, the value outweighs the other options)
ok. good. if that's the case, your mobile clients will find the lyncdiscover.sipdomain.com record (that has to point to the external ip of the reverse proxy... not internal). The mobile clients and the Lync 2013 clients will then hairpin through the RP to login.
I am told that the only real downside to that is 'media optimization' is not optimal. however, i'd really wonder if that's the case with how TURN/ICE/STUN do media negotiation ... maybe there's info out there on that somewhere or if somebody knows the true consequence of this configuration. (but, I think in your case, the value outweighs the other options)
ok. good. if that's the case, your mobile clients will find the lyncdiscover.sipdomain.com record (that has to point to the external ip of the reverse proxy... not internal). The mobile clients and the Lync 2013 clients will then hairpin through the RP to login.
I am told that the only real downside to that is 'media optimization' is not optimal. however, i'd really wonder if that's the case with how TURN/ICE/STUN do media negotiation ... maybe there's info out there on that somewhere or if somebody knows the true consequence of this configuration. (but, I think in your case, the value outweighs the other options)
This topic is archived. No further replies will be accepted.
Other recent topics
Click here to get your free copy of Network Administrator. Over 25 plugins to make your life easier