Forum Discussion
Steve_85547
Nimbostratus
NimbostratusSharepoint nightmares
Hello I was just wondering if anyone could take a look at the following symptoms and provide me a suggestion or idea:
1. I have a virtual server serving up a 4-node 2007 Sharepoint cluster - well call it 123.abc.com. When I try and hit 123.abc.com like this - \\123.abc.com\sharename - it takes 3 minutes MINIMUM for it to come up. I tried changing SNATs, followed the Sharepoint design guide to a T - and even engaged F5 support and its still an issue. Any help would be greatly appreciated.
2. I have another Sharepoint implementation in which a SINGLE sharepoint server sits behind an F5 virtual server and it works fine. As soon as I introduce a 2nd node into the pool - the application times out with 404 errors. Any ideas?
Anyone out there havs a successful 2007 Sharepoint behind LTM that can share configs or suggestions with me?
Thanks
Steve Sneed
network engineer
Coventry Health Care
724-630-3513
sksneed@cvty.com
hoolioCirrostratus
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
Steve_85547Posted 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- hoolioHi 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 
Vishal_96707I 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.