During a co-existence scenario with a mixed client environment (XP SP2 through 7) we found an issue when Windows XP machines could not log in but Windows 7 clients could. From the client side we saw the following error:
I had the user sign in from a known good machine and everything worked. Since we were sure the credentials were right I decided to take a look at the Event Viewer on the server.
In the server I noticed the following event:
The great thing about this event is the text in the error message is actually very useful. It explains that the 2008 R2 server requires 128-bit encryption and lower level clients have this setting disabled by default.
Cause: This error can occur if the settings in “Network security: Minimum session security for NTLM SSP based (including secure RPC) clients” policy on the client computer are not the same as the settings in the “Network security: Minimum session security for NTLM SSP based (including secure RPC) servers” policy on this server. By default, the “Require 128-bit encryption” setting is disabled for computers running Windows Server 2008, Windows Vista, Windows Server 2003, Windows 2000 Server, or Windows XP. For computers running Windows 7 or Windows Server 2008 R2 this setting is enabled by default.
Because some of the machines in the environment were unmanaged external clients and we didn’t want to impact their productivity, we decided to update the server to allow the lower level clients (XP in this case) to connect.
To view the current settings you can open the “Local Security Policy” snap-in under Administrative Tools on the front end server.
After expanding Local Policies and clicking on Security Options we can scroll down to “Network Security: Minimum security: Minimum session security for NTMP SSP based (including secure RPC) servers” and see the default setting of “Require 128-bit encryption”.
To change this, double click the entry then un-check the box next to “Require 128-bit encryption” and click OK.
After closing the box we now see the modified setting which takes effect immediately and our XP and Vista clients can now sign-in.
My preference was to leave this setting in place, but because there were so many remote clients in place we had to make a change to allow them to work on the server side.
The Lync Guy's Blog 
I am having this issue on random computers on our network. After going through this guide I found that those settings were already setup with no minimum any other suggestions? 😦
Sam,
Are those settings set on the server or client side? Also, can you try logging in with an account that is having the issue from a known good machine (like a Win 7 machine).
Hope this helps!
-kp
Hi, totally off topic here.
I am busy with a client who is using terminal services for 80% of the users on a Windows Server 2008 R2 server. I have purchased IP phones and will using the phones for voice only and the Lync client will be used for IM and Presence on the TS server. Is there any way that I can stop the Lync client on the TS server from ringin when a call comes in and allow allow the phones to ring.
Hi Deon,
I’m not aware of a way to make this happen with the Lync client. I’ll do a bit of research and will post back if I find anything.
Thanks for reading!
-kp
OK thanks…
This worked for me with same error using Lync 2010 on a Win08 32 bit server outside my LAN. Thanks!
Chris,
Glad it helped and thanks for sharing the info with us all!
-kp
Thanks! This saved me hours of troubleshooting.
I had the same issue, so I checked the security policies on both the XP client and the Windows 2008 R2 Server. The client had the 128 bit encryption disabled. As I could not change this due to local policy, I just rebooted my client and it started working again. The settings are still incorrect and do not match the server.. So answers on a postcard please. Both machine and server are in different AD domains, does this make a difference ?
Thanks dude. Used your fix this morning … xp clients getting all crazy on me.
Can you verify that this change only had to be made on the Front-End, or both the Front-End and Edge?
Yes, the change should only be made on the Front End, not the edge.
HTH
-kp
It depends on your deployment,
In our deployment we have a DIRECTOR pool that takes care of the authentications.
so this solution had to be done on both of my DIR servers
–
Correct Daniel, you would have to add this setting to directors if they are doing auth. Thanks for pointing this out!
-kp