We are in the prosess of implementing Lync to all our employees. We have a problem for some of our users. The error message on the client is.

"Cannot sign in to Lync: Please sign out at another location and try again. You have reached the maximum number of computers or devices allowed"

We have verified that they only are singed in to one device. The ten users with the problem all have first name starting with the letter "A". I don't now if this is a  coincidence.

They can log in but get loged out whe the error appears. If they try to log in again it works after trying some time. The users get the error several times each day.

Hi,

It seems relate to maximum number of endpoints,please check the value of Maximum devices per user at global properties and compare it with others.

http://technet.microsoft.com/en-us/library/dd572363(office.13).aspx

Regards,

Sharon

We are shure the users only are using one endpoint, but i have now increased the number of endpoints from 8 to 30. If this does fix the problem we later have to find out what makes the system believe there is to many endpoints.

The link you sent was for OCS. The command i did run in Lync PowerShell where.
Set-CsRegistrarConfiguration –Identity global –MaxEndpointsPerUser 30

I found it here http://blogs.technet.com/b/csps/p/ocsmap03.aspx

• Marked as answer by Kmm3 Wednesday, March 30, 2011 5:15 PM
• Unmarked as answer by Kmm3 Wednesday, March 30, 2011 5:15 PM
• Marked as answer by Kmm3 Wednesday, March 30, 2011 5:15 PM

We are shure the users only are using one endpoint, but i have now increased the number of endpoints from 8 to 30. If this does fix the problem we later have to find out what makes the system believe there is to many endpoints.

The link you sent was for OCS. The command i did run in Lync PowerShell where.
Set-CsRegistrarConfiguration –Identity global –MaxEndpointsPerUser 30

I found it here http://blogs.technet.com/b/csps/p/ocsmap03.aspx

• Marked as answer by Kmm3 Wednesday, March 30, 2011 5:15 PM
• Unmarked as answer by Kmm3 Wednesday, March 30, 2011 5:15 PM
• Marked as answer by Kmm3 Wednesday, March 30, 2011 5:15 PM

We are shure the users only are using one endpoint, but i have now increased the number of endpoints from 8 to 30. If this does fix the problem we later have to find out what makes the system believe there is to many endpoints.

The link you sent was for OCS. The command i did run in Lync PowerShell where.
Set-CsRegistrarConfiguration –Identity global –MaxEndpointsPerUser 30

I found it here http://blogs.technet.com/b/csps/p/ocsmap03.aspx

• Marked as answer by Kmm3 Wednesday, March 30, 2011 5:15 PM
• Unmarked as answer by Kmm3 Wednesday, March 30, 2011 5:15 PM
• Marked as answer by Kmm3 Wednesday, March 30, 2011 5:15 PM

After we increased the number of endpoints the problem was solved. Why this error happend and only affected useres with first name starting with "A" is still a mystery. At this time we are ok with this as long as the problem is solved.

I have this issue with all users.  Anyone have a fix for this.  I ran the command above and increased it to 60. Still no luck.

I got the same error in my lab, I just increased from 8 to 30, I'll report back if it fixes the issue.

We have the same exact problem. However, all users get disconnected at the same time with the error "Can't sign in to Lync Please sign out at another location and try again...." Our implementation is a Lync 2013 Enterprise with currently only one front end server. This is an upgrade/migration from a Lync 2010 implementation. We did not have the problem with Lync 2010.

The MaxEndpointsPerUser was set to default of 8 and we reset it to 30 and then 60. Still no change. Several times per day everyone is simultaneously kicked and can log right back in. Doesn't matter whether they are in a conference or not.

The FE server is running on a 2012 Hyper-V cluster and time synchronization is NOT set to be offered by Hyper-V which means time on the server is domain synchronized so all workstations and servers have the same system time.

All updates applied to server and clients.

Any suggestions would be greatly appreciated.

Peter, we are getting the same thing as you.  We drop connection usually around the same time every day now for some reason. 

I looked at the logs and it appears that there is a "time change" log entry around the same time as the disconnects.  I am not sure if this is what is causing the issue or not, just found it weird that that log is in there when no one was even on the Lync server at that time.

I placed our connections to the max at 64, so no luck with that.  A fix for this would be nice, since we will be using this as a replacement for GoToMeeting and we cant have users being signed off of lync in the middle of support calls.

Help Microsoft!!!

Thanks,

James

Hello,

I see same error at customer with name starting with "A". In customer case user has only one Lync 2013 client on his computer and user is only enabled for PC-to-PC connectivity.

The MaxEndpointsPerUser is set to 30. The error still occurs.

There is more to this error than just MaxEndpointsPerUser settings.

If anyone can point the issue will be a great help.

Thanks,

Ketan Shah

We are still recieving this error.  Actually its happening more and more, sometimes 3-4 times a day now.  Are there any other suggestions at this time? 

We are just performing a trial of the product and this is not looking real good to management.

Thanks,

James

James and Peter-

I've recently had the same issue for a major program i run, and was able to get escalated engineering support. It does appear the issue you are describing is related to time. (Not sure about the other folks here having things happen only to users that start with A) I would get all users logging off at the same time, with the "maximum connections" error message. I too tried to up the maximum endpoints without resolution. 

After some talks with Engineering, it appears that time sync adjustment on a Lync FE server of greater than a minute can cause this issue. In order to test this, we turned off all hyper-V time syncing, as well as disconnected the entire forest from the internet, and kept the DC in sync with the Lync FE. This resolved the problem. We then tried other variables, such as enabling time sync again, but syncing more often.  The two that always work for us are disabling Hyper-V time sync for the DC and the FE, and leaving time sync only enabled for the DC and syncing everything else off the DC. 

I would start by maybe trying to turn off all of your time syncing for the FE and maybe syncing it direct to a public time source? If you have the luxury, maybe disable time syncing across your entire forest temporarily to test.

Jason

Thanks,  This line is a little confusing but I think I understand what you mean:

"The two that always work for us are disabling Hyper-V time sync for the DC and the FE, and leaving time sync only enabled for the DC and syncing everything else off the DC. "

I have unchecked it on our FE and Edge server and rebooted them.  Will be awaiting to see if the message is there Monday morning or not.

Thanks again!

James and Peter-

I've recently had the same issue for a major program i run, and was able to get escalated engineering support. It does appear the issue you are describing is related to time. (Not sure about the other folks here having things happen only to users that start with A) I would get all users logging off at the same time, with the "maximum connections" error message. I too tried to up the maximum endpoints without resolution. 

After some talks with Engineering, it appears that time sync adjustment on a Lync FE server of greater than a minute can cause this issue. In order to test this, we turned off all hyper-V time syncing, as well as disconnected the entire forest from the internet, and kept the DC in sync with the Lync FE. This resolved the problem. We then tried other variables, such as enabling time sync again, but syncing more often.  The two that always work for us are disabling Hyper-V time sync for the DC and the FE, and leaving time sync only enabled for the DC and syncing everything else off the DC. 

I would start by maybe trying to turn off all of your time syncing for the FE and maybe syncing it direct to a public time source? If you have the luxury, maybe disable time syncing across your entire forest temporarily to test.

Jason

Jason,

I made the change on Friday and came into the office this morning and was NOT greeted with the Lync signed out message.  I do believe making the change as you suggested worked for us.  Time will tell though...  

Just as a safety measure I did this on both our FE and our EDGE servers.  Not sure if the EDGE server really needs it but did it just in case.

Now only if they fix the 2013 mobile client and OWA server NEEDING a reverse proxy to work Lync will be a perfect fit for us.

Thanks again!!!!

Now only if they fix the 2013 mobile client and OWA server NEEDING a reverse proxy to work Lync will be a perfect fit f

This issue is Time Synchronization related.

1.In the settings of VM (FE Server) uncheck Time Synchronization (Integration Services)

2.Login to the FE, open CMD and type "W32tm /query /status" to chek from where you sync the time. If the time is NOT from your NTP server you need to resync the time.

3. To resync the time type the folowing command "W32tm /resync

4. Again type the query command above, and you wil notice that the time now is from your NTP server.

The problem is now solved. Essentially we have two problems:

1) Time synchronization between PDC and Lync Front End. The time was off by more than 2 minutes. Once corrected most of the errors gone.

2) Over subscribed Host machine. This was actually causing us the issue with the number of sessions.

Thanks,  This line is a little confusing but I think I understand what you mean:

"The two that always work for us are disabling Hyper-V time sync for the DC and the FE, and leaving time sync only enabled for the DC and syncing everything else off the DC. "

I have unchecked it on our FE and Edge server and rebooted them.  Will be awaiting to see if the message is there Monday morning or not.

Thanks again!

I too have this problem when I come into work in the morning.  See when I leave at the end of the day I change my status to out of the office, then lock my screen.  In the morning when I unlock the screen Lync is usually open but not signed in with this error message that I have signed into too many locations.  But I did not sign in anywhere else! (iphone, laptop, etc...).

Sure you just click OK and click sign in and everything is good.

I ran this : Set-CsRegistrarConfiguration Identity global MaxEndpointsPerUser 30 So now its a wait and see if this is still going to be an issue.

I was curious what MaxEndpointsPerUser was set to but I just could not get anything out of Get-CsRegistarConfiguration as PowerShell says its not a recognized cmdlet.  How would one determine what this value is if I cannot do a simple Get and do |FL and search for the parameter MaxEndpointsPerUser ?

Do you think this could also be the Veeam snapshot consolidating the LYNC front end server in VMWare ESXi 5.0's nfs datastore.  I know machines are stunned for a minute or two while the snapshot consolidates back into the primary VMDK virtual disk file.  Thats why all backups are run after hours.

• Edited by KJSTech1 Thursday, November 13, 2014 1:27 PM veeam tidbit.

I too have this problem when I come into work in the morning.  See when I leave at the end of the day I change my status to out of the office, then lock my screen.  In the morning when I unlock the screen Lync is usually open but not signed in with this error message that I have signed into too many locations.  But I did not sign in anywhere else! (iphone, laptop, etc...).

Sure you just click OK and click sign in and everything is good.

I ran this : Set-CsRegistrarConfiguration Identity global MaxEndpointsPerUser 30 So now its a wait and see if this is still going to be an issue.

I was curious what MaxEndpointsPerUser was set to but I just could not get anything out of Get-CsRegistarConfiguration as PowerShell says its not a recognized cmdlet.  How would one determine what this value is if I cannot do a simple Get and do |FL and search for the parameter MaxEndpointsPerUser ?

Do you think this could also be the Veeam snapshot consolidating the LYNC front end server in VMWare ESXi 5.0's nfs datastore.  I know machines are stunned for a minute or two while the snapshot consolidates back into the primary VMDK virtual disk file.  Thats why all backups are run after hours.

• Edited by KJSTech1 Thursday, November 13, 2014 1:27 PM veeam tidbit.

I too have this problem when I come into work in the morning.  See when I leave at the end of the day I change my status to out of the office, then lock my screen.  In the morning when I unlock the screen Lync is usually open but not signed in with this error message that I have signed into too many locations.  But I did not sign in anywhere else! (iphone, laptop, etc...).

Sure you just click OK and click sign in and everything is good.

I ran this : Set-CsRegistrarConfiguration Identity global MaxEndpointsPerUser 30 So now its a wait and see if this is still going to be an issue.

I was curious what MaxEndpointsPerUser was set to but I just could not get anything out of Get-CsRegistarConfiguration as PowerShell says its not a recognized cmdlet.  How would one determine what this value is if I cannot do a simple Get and do |FL and search for the parameter MaxEndpointsPerUser ?

Do you think this could also be the Veeam snapshot consolidating the LYNC front end server in VMWare ESXi 5.0's nfs datastore.  I know machines are stunned for a minute or two while the snapshot consolidates back into the primary VMDK virtual disk file.  Thats why all backups are run after hours.

• Edited by KJSTech1 Thursday, November 13, 2014 1:27 PM veeam tidbit.

Hi Ketan,

Please, could you be more specific about what you mean with "2) Over subscribed Host machine. This was actually causing us the issue with the number of sessions". I already disabled Time synchronization and made a resync. However the issue is still occurring. All of Lync 2013 clients logs off unexpectedly displaying the message "please sign out at another location..."

Thank you.

Hi all,

Interestingly, I have just seen a similar issue. Last night, clients were signed out of Lync (both mobile and desktop) with similar errors. From a users iPhone, I can see in the logs messages such as:

"You've been disconnected because you're signed in to Lync in too many places"

and

"We can't sign you in. Looks like you are already signed in on too many devices"

On coming across this thread this morning, I checked the time synchronisation on the FE (SE) server. This was over 2 minuets out from the DC's, however, when I checked the "W32tm /query /status", all looked OK - the Lync server was pointing to the correct DC. The DC time was correct and syncing to a local NTP server, but the time difference was still large. All other member servers seemed to be synch correctly

C:\Windows\system32>W32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 4 (secondary reference - syncd by (S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0686951s
Root Dispersion: 0.1420435s
ReferenceId: 0x892CACD1 (source IP:  111.111.111.111)
Last Successful Sync Time: 30/04/2015 09:14:46
Source: DC1.mydom.com
Poll Interval: 15 (32768s)

I ran a "W32tm /resync" on the Lync FE, and over a period of time (about an hour), the synchronisation started coming back into line. Checking the "W32tm /query /status" again revealed the the Poll interval had changed from 15 to 10, which a shorter time span. Check no shows that the Poll interval has risen to 11, so I guess this rises over a period of time if the client thinks that synchronisation is OK.

The initial "root dispersion" was low (see above), indicating that the FE Server 'thought' that its local clock was pretty much synced with the DC clock - obviously it wasn't, but I'm not sure why this was the case.

However, even after syncing the clocks, some mobile users are still unable to log in. I have had the users send over the sign in logs from the mobiles and the thing that standards out is the following response:

2015-04-30 11:07:27.953 Lync[262:5799000] INFO TRANSPORT TransportUtilityFunctions.cpp/1079:<ReceivedResponse>
POST https://lyncweb.mydom.com/WebTicket/WebTicketService.svc
Request Id: 0x178a54d8
HttpHeader:Content-Length 58
HttpHeader:Content-Type text/html
HttpHeader:Date Thu, 30 Apr 2015 10:07:27 GMT
HttpHeader:Server Microsoft-IIS/8.5
HttpHeader:StatusCode 401
HttpHeader:Strict-Transport-Security max-age=31536000; includeSubDomains
HttpHeader:Www-Authenticate NTLM
HttpHeader:X-Content-Type-Options nosniff
HttpHeader:X-MS-Server-Fqdn FE1.mydom.com
HttpHeader:X-Powered-By ASP.NET, ARR/2.5

You do not have permission to view this directory or page.
</ReceivedResponse>

Annoyingly, this happened again this morning. It would appear that the DC with the PDC role receieved an updated from something that pushed the time forward by 2 1/2 minuets that had a knock on effect to the Lync server. The DC are virtualised (VMware), although host time synchronization is disabled, the PDC syncs with known good NTP time servers, and the reset of the domain syncs as expected.

The error on the PDC just said:

The system time has changed
to 2015-05-01T08:05:24.511000000Z from
2015-05-01T08:02:44.566672200Z.

Change Reason: An application or system component changed the time.

I don't think there is anything on the DC that would cause this, by I'm not sure what Harlock refers to as disabling the "save state". However, whilst the VM time sync to host options are OFF, this article eludes to time synchronising still occurring even when the option is switched off. It makes no mention what those specific events" are, but does go into information with regard to completely removing at time synchronisation to the VMs.

I did note that a Veeam backup took place within a few second of the time jump, so we will be looking at this next week.

Just to feedback on this, from our point of view, it certainly looks as though it was a subtle time difference between the VMware Host and the NTP server that the VM DC eventually synced with. As a quick work around, I simply disabled the VMware tool services on the DC, but will need to implement the configuration changes referenced in the article linked above to stop ANY time syncing between the host and VM full. Ideally, I would like to do this for ALL my VMs, just in case the Host times slip again.

Cheers