Forum Discussion
JoeTheFifth
Altostratus
AltostratusSharePoint 2013 Cookie persistence
hi Guys,
We ar using big-ip 11.x. default settings (http) VS for sharepoint using cookie peristence. we're not using iapps. question: is this config ok? I understand the NO COOKIE persistence wa...
That is some ambiguous wording, we'll look into changing it in the guide.
It's fine to use cookie persistence with SharePoint 2013. Although in this case, wouldn't you create two pools and use an iRule to do pool assignment based on the host header? You'd need to do that to send the request to the correct server before applying persistence.
JoeTheFifthSo I'm good creating a Virtual Server using a default config and choosing cookie for persistence. If I choose to use an iApps template I shouldn't use cookie as persistence. I'm asking this because SharePoint 2013 has a new mecanism of storing authent tokens and will not require re-authent if the Big-Ip redirects you to a new pool member. The other goal behind the irule is simple. eventhough sharepoint has the new cache mecanism i think it is better if a user stays on the same server for all his sharepoint work as far as the server is ok. Big-Ip redirects the same user session (same webpage) to 2 servers because the webpage calls 2 urls webapp01.domain.com and webapp01.domain.com. what I have already done for a similar scenario with UAG is to rewrite the big-ip cookie with a domain cookie so that the user stays on the same server for the same domain domain.com. Of course both webapps live on the same server. It's a VS with one pool and 4 memebers.- JoeTheFifthSharePoint 2013 uses a new Distributed Cache Service to cache login tokens. In SharePoint 2010 Products, the login token is stored in the memory of each web front-end server. Each time a user accesses a specific web front-end server, it needs to authenticate. If you use network load balancers in front of your web front-ends, users need to authenticate for each web front-end server that is accessed behind the load balancer, causing possible multiple re-authentications. To avoid re-authentication and its delay, it is recommended to enable and configure load balancer affinity (also known as sticky sessions). By storing the login tokens in the Distributed Cache Service in SharePoint 2013, the configuration of affinity in your load balancing solution is no longer required. There are also scale-out benefits and less memory utilization in the web front-ends because of a dedicated cache service. http://technet.microsoft.com/en-us/library/jj219758(v=office.15).aspx
