Forum Discussion

JoeTheFifth's avatar
JoeTheFifth
Icon for Altostratus rankAltostratus
Jul 09, 2014

SharePoint 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 warning is only for iapps. Is this right?

 

Now i have another question: let's say we have webapp01.mydomain.com and webapp01.mydomain.com with the current VS a single users is being redirected to 2 servers when he load webapp01.mydomain.com as the homepage has requests to webapp02.mydomain.com because of the different urls webapp01/webapp2 . I'm thinking of using an iRule to persist the user on the same server based on cookie domain mydomain.com. is this supported? remember we are not using iApps. The "NO COOKIE persistence" mentioned here: https://devcentral.f5.com/wiki/GetFile.aspx?Page=iApp.Microsoft-SharePoint-2013-iApp-Template&File=iapp-sharepoint-2010-2013-RC-1d-dg.pdf

 

8 Replies

  • The persistent cookie option is really only relevant to SharePoint with Access Policy Manager (APM). You don't need it for a straight LTM deployment. As for persisting across VIPs, setting a domain attribute in a cookie persistence iRule would certainly be a good option.

     

    I may be misunderstanding your question though. Are you saying that there are two SharePoint servers behind a single VIP, or that you have two VIPs (with the same pool members) and you want to persist to the same pool member across both VIPs?

     

  • 4 sharepoint servers behind a vip with cookie persistence and standard VS config. http.

     

    Then you don't need iRule-based cookie persistence. The built-in cookie persistence profile should work fine.

     

  • ok. so first question: sharepoint 2013 + cookie persistence => OK? No worries about the warning in the iApps/sharePoint manual ?

     

  • I'm assuming here that you're referring to the statement pertaining to persistence:

    Do not create this profile if using SharePoint 2013
    

    I'm not 100% sure, but I think this is some weird wording. You should be able to use the built-in cookie persistence profile without any issues.

  • mikeshimkus_111's avatar
    mikeshimkus_111
    Historic F5 Account

    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.

     

    • JoeTheFifth's avatar
      JoeTheFifth
      Icon for Altostratus rankAltostratus
      So 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.
    • JoeTheFifth's avatar
      JoeTheFifth
      Icon for Altostratus rankAltostratus
      SharePoint 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