Sharepoint nightmares

Hi Steve,

 

 

Is the problem with web access or fileshares? Have you been able to capture a tcpdump of a failure? It sounds like there might be some kind of look up being performed on the servers which times out. I've done a few Sharepoint implementations for customers and not seen this issue. We typically use standard VIPs with client SSL, HTTP, OneConnect with a mask of 255.255.255.255, and cookie insert persistence set to ~30min.

 

 

The deployment guide doesn't cover fileshare access. To allow it, you'd need to configure a VIP on port 445 with a TCP profile. This post might also have some related info for fileshare access delays (Click here).

 

 

I'm surprised that F5 Support wasn't able to help you resolve this issue. What was the result of the case?

 

 

For point 2, do you have a persistence profile added to the VIP? Can you try source address to start with and then move to something more complicated if that fixes it?

 

 

Aaron

Posted By hoolio on 08/26/2008 6:56 AM

 

 

Hi Steve,

 

 

Is the problem with web access or fileshares? Have you been able to capture a tcpdump of a failure? It sounds like there might be some kind of look up being performed on the servers which times out. I've done a few Sharepoint implementations for customers and not seen this issue. We typically use standard VIPs with client SSL, HTTP, OneConnect with a mask of 255.255.255.255, and cookie insert persistence set to ~30min.

 

 

The deployment guide doesn't cover fileshare access. To allow it, you'd need to configure a VIP on port 445 with a TCP profile. This post might also have some related info for fileshare access delays (Click here).

 

 

I'm surprised that F5 Support wasn't able to help you resolve this issue. What was the result of the case?

 

 

For point 2, do you have a persistence profile added to the VIP? Can you try source address to start with and then move to something more complicated if that fixes it?

 

 

Aaron

 

 

 

Aaron,

 

 

Thanks for the reply. It has been a while and I still am having issues. I will look at that other post.

 

 

Here is the latest on my 2 issues:

 

 

1. My VIP for this is an IP (*) VIP allowing all ports and the nodes behind it are also IP (*).

 

 

2. I have made it a little further with this one. I can introdude a 2nd node but unless I use desination address persistence, and requests continue to go to one node, everything fails (404 authentication errors). I am not using SSL. I am using standard VIPs, HTTP, NO OneConnect because the doc says not to if we are using NTLM, and cooke persistence (with the one server of course).

 

 

I guess my questions are these at this point...

 

 

1. Is it wrong to configure VIPs, pools, and node for IP?

 

 

2. Is it possible to get load balancing to work with destination address affinity (sticky) persistence? Because every time I configure sticky, everything goes to one node. Even after the clients clear their cache.

 

 

Thanks to all who respond and offer suggestions...

 

 

Steve

 

 

 

Hi Steve,

 

 

I'd suggest configuring a single port VIP (VIP:80 -> pool:80) to restrict clients to just the port that is required. If you do end up needing HTTPS access, you can configure a second VIP on 443 pointing to the same HTTP pool. Having a separate VIP per service makes it easy to tailor the profiles for the required protocols.

 

 

Apparently there are issues with OneConnect and NTLM so I think you're right to not use OneConnect.

 

 

You should be able to configure source address (with a /32 mask) or cookie insert persistence to persist either individual client IP addresses or client browser sessions. Destination address persistence is more suited for load balancing cache servers or external links--not web applications. Destination address persistence creates a persistence record on the BIG-IP based on the client's destination address. So all clients would be persisted to the same pool member if they're all requesting the same VIP address. The persistence record is stored on the BIG-IP for the configured timeout length, so there is nothing the client can do to force re-selection of the pool member.

 

 

Hope this helps,

 

Aaron

I am also having nightmares with sharepoint deployment. We recently moved from Radware to F5 environment and there are number of issues reported. Even we have complaints from users where the UNC access to sharepoint is too slow.

 

I have configure 2 vips, 1. http vs which redirects requests to https and 2. https for pool, persistence etc. I would appreciate some help in resolving this issue. I am new to F5 and really dont know what else to troubleshoot.