I see the following error message in Lync FE eventlog everytime a user signs in with the Lync client:

Event log:

Log Name: Lync Server
Source: LS UserPin Service
Date: 09/06/2011 19:46:21
Event ID: 47055
Task Category: (1044)
Level: Warning
Keywords: Classic
User: N/A
Computer: LYNCFE01.DOMAIN.com
Description:
GetAndPublish web service failed due to an internal error

Request Details - Entity: [user1@DOMAIN.com], Device Id: [{A7C394D3-99CB-5D24-A361-4865A9D4421B}], Authenticated User: [sip:user1@DOMAIN.com].
Cause: This is an unexpected failure
Resolution:
Re-start the web server. If you see this error continuously, examine the server traces and contact product support.
Event Xml:
">http://schemas.microsoft.com/win/2004/08/events/event">
47055
3
1044
0x80000000000000
1084112
Lync Server
LYNCFE01.DOMAIN.com
user1@DOMAIN.com
{A7C394D3-99CB-5D24-A361-4865A9D4421B}
sip:user1@DOMAIN.com

 

The "get-csclientcertificate" command does not return any certificate for any of the enabled users.

"Test-csclientauth" also fails in the environment.

I made a complete rollback from CU3 (and CU2) to RTM version of Lync, and the error message did not come back. I re-applied CU3, and the error message appears again in the log.

Hi,Richard,

LS User Pin service event is mostly related to the Lync phone edition service,have you also installed the latest update package for Lync Phone edition?

Lync 2010 Phone Edition (Polycom CX500, CX600 & CX3000) – KB2577594

Lync 2010 Phone Edition (Aastra 6721ip & 6725ip) – KB2577595

Lync 2010 Phone Edition (Polycom CX700 & LG Nortel 8540) – KB2577593

In case you omit some update packages for Lync,here is  the latest update packages listed below:

http://blogs.technet.com/b/cs2010/archive/2011/07/26/lync-july-2011-update.aspx

Please do let us know if these works.Thanks!

Regards,

Sharon

No IP phones were connected to this environment, only Lync 2010 clients.

After 4 months of troubleshooting it turned out to be an ugly and sneaky certificate issue. MS product support confirmed it, after contacting the developer responsible for that piece of code. After the certificate has been re-issued all the issues (including this one and several other PSTN conferencing related ones) just magically disappeared. I was fighting with MS product support to issue at least a proper documentation of the crazy strict requirements of Lync, as the current product documentation is cinycally silent about this.

Just in short: in your certificate dont ever dare to use any exotic signature algorithm other than "sha1RSA". I really mean literally "sha1RSA", no other permutation of RSA must be allowed here. Otherwise you will go into an endless pit of hell with all kind of impossible to resolve. Turned out Lync is sensitive if communicates with the EXUM and EXUM provides such an exotic signature algorithm in the certificate, like "RSASSA-PSS".

After both Lync FE and EXUM certificate has been replaced with a simple sha1RSA, everything started to be working. The root CA also had such an exotic RSASSA-PSS certificate, but luckily we didnt have to change this, as fortunately Lync was not looking at the whole cert chain. On the other hand it was a live production Root CA. I would start arguing that if Microsoft offers all these exotic algorithms in its Certificate Authority product, it must be accepted by all of its products, and not cause such weird headaches.

But if MS doesnt support all these exotic crypto-nightmares in Lync, at least doucment this properly! If you have a look at the current Lync documentation, its a joke what they have been written about certificate requirements. This should have been written much more professionally!

• Marked as answer by Richard Pasztor Monday, November 14, 2011 3:55 PM
• Edited by Richard Pasztor Monday, November 14, 2011 4:07 PM

After 4 months of troubleshooting it turned out to be an ugly and sneaky certificate issue. MS product support confirmed it, after contacting the developer responsible for that piece of code. After the certificate has been re-issued all the issues (including this one and several other PSTN conferencing related ones) just magically disappeared. I was fighting with MS product support to issue at least a proper documentation of the crazy strict requirements of Lync, as the current product documentation is cinycally silent about this.

Just in short: in your certificate dont ever dare to use any exotic signature algorithm other than "sha1RSA". I really mean literally "sha1RSA", no other permutation of RSA must be allowed here. Otherwise you will go into an endless pit of hell with all kind of impossible to resolve. Turned out Lync is sensitive if communicates with the EXUM and EXUM provides such an exotic signature algorithm in the certificate, like "RSASSA-PSS".

After both Lync FE and EXUM certificate has been replaced with a simple sha1RSA, everything started to be working. The root CA also had such an exotic RSASSA-PSS certificate, but luckily we didnt have to change this, as fortunately Lync was not looking at the whole cert chain. On the other hand it was a live production Root CA. I would start arguing that if Microsoft offers all these exotic algorithms in its Certificate Authority product, it must be accepted by all of its products, and not cause such weird headaches.

But if MS doesnt support all these exotic crypto-nightmares in Lync, at least doucment this properly! If you have a look at the current Lync documentation, its a joke what they have been written about certificate requirements. This should have been written much more professionally!

• Marked as answer by Richard Pasztor Monday, November 14, 2011 3:55 PM
• Edited by Richard Pasztor Monday, November 14, 2011 4:07 PM

After 4 months of troubleshooting it turned out to be an ugly and sneaky certificate issue. MS product support confirmed it, after contacting the developer responsible for that piece of code. After the certificate has been re-issued all the issues (including this one and several other PSTN conferencing related ones) just magically disappeared. I was fighting with MS product support to issue at least a proper documentation of the crazy strict requirements of Lync, as the current product documentation is cinycally silent about this.

Just in short: in your certificate dont ever dare to use any exotic signature algorithm other than "sha1RSA". I really mean literally "sha1RSA", no other permutation of RSA must be allowed here. Otherwise you will go into an endless pit of hell with all kind of impossible to resolve. Turned out Lync is sensitive if communicates with the EXUM and EXUM provides such an exotic signature algorithm in the certificate, like "RSASSA-PSS".

After both Lync FE and EXUM certificate has been replaced with a simple sha1RSA, everything started to be working. The root CA also had such an exotic RSASSA-PSS certificate, but luckily we didnt have to change this, as fortunately Lync was not looking at the whole cert chain. On the other hand it was a live production Root CA. I would start arguing that if Microsoft offers all these exotic algorithms in its Certificate Authority product, it must be accepted by all of its products, and not cause such weird headaches.

But if MS doesnt support all these exotic crypto-nightmares in Lync, at least doucment this properly! If you have a look at the current Lync documentation, its a joke what they have been written about certificate requirements. This should have been written much more professionally!

• Marked as answer by Richard Pasztor Monday, November 14, 2011 3:55 PM
• Edited by Richard Pasztor Monday, November 14, 2011 4:07 PM

Richard,

Thank you VERY much !!!

I killed a lot of time searching for this error. But thanks to your information, I found the solution !

Konstantin

 

Richard,

Thank you VERY much !!!

I killed a lot of time searching for this error. But thanks to your information, I found the solution !

Konstantin

 

Did you have a similar crazy exotic certificate, like in my case?

Sorry for the long silence ..
Yes, we use the win 2008 r2 PKI infrastructure and use the type of signature SHA256-RSASSA-PSS. Now communicate with the PSS, we want to open a design change request.

Richard,

Do you know if this issues is still outstanding with CU6?

Thanks,
Frank

If you read my post -above- describing the real situation, you will see this is not really a bug, but a limitation of the Lync software. And most probably it will not be fixed in any CU release, but MAYBE in the next major version. But only in case you and other victims of this problem keep continuously banging the walls at the Redmond MS HQ, otherwise the mammoth wont make any move towards fixing this painfull limitation.

The problem is solved. There is a huge Microsoft mistake in documentation for MS Lync. I don't know why but I can't find any information about exact PKI requiments for MS Lync. In my case all my certificates use RSASSA-PSS algorythm instead of RSAsha1. I changed the registry key on my Enterprise CA server.    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CertSvc\Configuration\Your Cert Authority\CSP

value AlternateSignatureAlgorithm from 1 to 0 and restart CA service.

After this request a new certificate from Lync deployment withard and everything become OK.

It take me about 3 month to find out this!!!!

Thanks both Richard and Rufat. Oddly, my Lync deployment seemed to be OK apart from these errors mentioned above (both internal and remote connectivity for users and federated partners was OK). However, I was seeing some odd error on the Remote Connectivity Analyser (RCA - https://testconnectivity.microsoft.com/) so I thought I would run through these steps to see if it resolved my issue.

Indeed, I had recently setup and two tier PKI with Windows 2012 and enabled the subordinate to use "Alternate Signature Algorithm", which seemed like a reasonable assumption to make after reading umpteen documents and web sites. However, resetting this, then re-issuing the Lync FE and Edge certificates via the CA, the "LS UserPin Service" error disappeared.

I should say that the signature algorithm used is SHA256RSA, so it doesn't seem necessary to go right back to SHA1 (which is now seen to be insecure).

However, it still didn't resolve my RCA error, which I just can't figure out as the information provided by RCA is too woolly:

    Couldn't sign in. Error: Error Message: The operation failed after several attempts..
    Error Type: RegisterException.
    Deregister Reason: None.

Still, I appreciate your efforts both to track down the certificate issue. Certificates and all their intricacies confuse the hell out of me, however, I would have thought that the encryption layer would be abstracted away from the main Lync application, so it shouldn't care how the encryption is done.

I suppose it just goes to show....

I just found another blog, where it seems even the Lync 2013 Edge does not like SHA2 signature hash algorithm. Check this out:

http://www.lynclog.com/2015/02/lync-edge-sip20-488-compression.html

By the way, the Technet clearly says: "Lync and SHA256 is supported". Seems not.

MS owes the community a "Lync certificates" guide whitepaper!