NLB Troubleshooting

K2 requires that the NLB persistence type is set to IP Affinity. Seemingly random 401 authentication issues occur when using Cookie Affinity or any other non-IP Affinity setting.

Different NLB persistence Types

Some network load balancers use the concept of Cookie Affinity. Some companies consider this a valid “sticky session” configuration because it ensures that all requests from the same cookie-based session are routed to the same server. This works well when all activity in the browser stays in one session. However, there are many situations in SharePoint and K2 where a new session, including a new cookie, might be spawned. When this happens, the client machine is no longer guaranteed to go to the same back-end server in the farm. If this happens, the tickets are not passed between the servers and the result is a 401 Unauthorized Error in the browser.

For example, when you render a SharePoint library, you are in one session, when you click New for your web-based form, you are in a different session. If the system uses Cookie Affinity, there is a good chance those sessions are on different machines in the cluster results in 401 errors when you try to submit the form.

Error Message

The following error message relates to this Article:

401 authentication error

Error Resolution

The product requires your NLB persistence type to be IP Affinity. Different load balancing technologies may call this by different names so be sure to research the specific hardware in order to perform the correct configuration.

In Windows NLB software configuration, IP Affinity is obtained by setting the Filtering mode for Multiple host to either Single (routes all requests from a single IP to the same load balanced server) or Class C (routes all requests from IPs of the same Class C IP address range to the same load balanced server) as shown here.

In F5 (BIG-IP) hardware configuration, configure IP Affinity by setting the Persistence Type to Source Address Affinity.

Tracking down the issue

You can use the IIS logs to track down this issue. You can prove very quickly that when you see a 401 error, the initial browser session was hitting Node1 and the rendered form with the error was hitting Node2. When there were no errors, all pages render on the same node. This technique is very good to use when trying to debug NLB issues, especially when you can’t get to the configuration settings yourself.