F5 loadbalancers, sharepoint2013 designer problems

Sinbad

Honorary Master
Joined
Jun 5, 2006
Messages
88,618
Reaction score
41,121
Anyone out there got any experience with this?
The sharepoint sites themselves work perfectly through the LB, but designer regularly ****s itself with this error:
Capture.jpg
 
Haven't had much experience with sharepoint. With F5 i have though. From your image it looks like a valid error coming from the SP server. If it works to the SP server directly (and not via the F5) do a wireshark trace & see the difference in the payload.
 
Haven't had much experience with sharepoint. With F5 i have though. From your image it looks like a valid error coming from the SP server. If it works to the SP server directly (and not via the F5) do a wireshark trace & see the difference in the payload.

Yes it does work directly :/

Will fire up the shark directly to the farm - from initial inspection everything looks ok though. Not every request fails. Sometimes it's fine. (And I've disabled all the backends but one in the pool to be sure that it's not one of the servers giving trouble while the others are fine)
 
AFAIK, Sharepoint Designer is not a fan of server headers being replaced, hence why direct access via IP routing works. I could very well be wrong, though.

EDIT: This may or may not be the issue.
 
Ok - i would write an iRule to log which backend server you're going to. Then startup a wireshark trace & refresh the page until it fails. Check your /var/log/ltm logs and see which backend server you hit last & view the trace details.
 
Ok - i would write an iRule to log which backend server you're going to. Then startup a wireshark trace & refresh the page until it fails. Check your /var/log/ltm logs and see which backend server you hit last & view the trace details.
No need to log it, as I can control which backend it goes to ;)

Maverick: Interesting. However, the F5s are a bit smarter than ISAPI filters and will actually rechunk/reformat HTTP response appropriately.

Traffic trace looks like:
HTTP/1.1 200 OK

Server: Microsoft-IIS/8.5

Date: Tue, 15 Jul 2014 11:41:52 GMT

Connection: close

Content-type: application/x-vermeer-rpc

Set-Cookie: f5_cspm=1234;

Transfer-Encoding: chunked



b1e

<html><head><script id="f5_cspm">(function(){var f5_cspm={f5_p:'BGLEMPKCFGNHDDLMLHMBCNNFAKGOMMHOKJAAKPBALDNBKNANDALGKLGBHLEAHLIKDFCPFHLPLLOBLGPGCIEEGIJDBKHIDIHECNFPIACBJADFEOOKFNDLOMOANEHMPNNC',setCharAt:function(str,index,chr){if(index>str.length-1)return str;return str.substr(0,index)+chr+str.substr(index+1);},get_byte:function(str,i){var s=(i/16)|0;i=(i&15);s=s*32;return((str.charCodeAt(i+16+s)-65)<<4)|(str.charCodeAt(i+s)-65);},set_byte:function(str,i,b){var s=(i/16)|0;i=(i&15);s=s*32;str=f5_cspm.setCharAt(str,(i+16+s),String.fromCharCode((b>>4)+65));str=f5_cspm.setCharAt(str,(i+s),String.fromCharCode((b&15)+65));return str;},set_latency:function(str,latency){latency=latency&0xffff;str=f5_cspm.set_byte(str,32,(latency>>8));str=f5_cspm.set_byte(str,33,(latency&0xff));str=f5_cspm.set_byte(str,27,2);return str;},wait_perf_data:function(){try{var wp=window.performance.timing;if(wp.loadEventEnd>0){var res=wp.loadEventEnd-wp.navigationStart;if(res<60001){var cookie_val=f5_cspm.set_latency(f5_cspm.f5_p,res);window.document.cookie='aaaaaaaaaaaaaaa='+encodeURIComponent(cookie_val)+';path=/';}
return;}}
catch(err){return;}
setTimeout(f5_cspm.wait_perf_data,100);return;},go:function(){var chunk=window.document.cookie.split(/\s*;\s*/);for(var i=0;i<chunk.length;++i){var pair=chunk.split(/\s*=\s*/);if(pair[0]=='f5_cspm'){if(pair[1]=='1234'){var d=new Date();d.setTime(d.getTime()-1);window.document.cookie='f5_cspm=;expires='+d.toUTCString()+';path=/;';setTimeout(f5_cspm.wait_perf_data,100);}}}}}
f5_cspm.go();}());</script><title>vermeer RPC packet</title></head>
<body>
<p>method=list documents:15.0.0.4420

etc etc ec


What blows my mind is the apps guys have just informed me that it's all working perfectly in production, just not in our UAT environment. And production was not set up using an iApp, just a straight load balanced backend.

So I'm going to add the UAT sharepoint servers to the production F5 pools and disable the prod servers, and see if the problem recurs.
 
Maverick: Interesting. However, the F5s are a bit smarter than ISAPI filters and will actually rechunk/reformat HTTP response appropriately.

I expected as much. But now I think that this may be something to do with the way the iApp was written, if a straight load-balanced setup works perfectly.

Ultimately, though, this seems to be a Sharepoint issue.
 
I expected as much. But now I think that this may be something to do with the way the iApp was written, if a straight load-balanced setup works perfectly.

Ultimately, though, this seems to be a Sharepoint issue.

The reason I went with the iApp was in an attempt to resolve the exact same issue being experienced when I did a vanilla config. To be honest I forgot I'd even put this thing into production :o
So yeah, I'm also thinking it's a sharepoint issue. However, it's very hard to convince the sharepoint admins that their system is borked when designer works perfectly when it's not routed through the loadbalancers
 
These kinds of problems are really hard to find root cause for.

Had a similar issue a while back (not SharePoint though - bespoke app) - went down to code level on the app and eventually, after running out of things to look for, we 'rebuilt' the F5 and the problem went away.

Was a bastid of an issue - many late nights by the various teams

Good luck
 
So yeah, I'm also thinking it's a sharepoint issue. However, it's very hard to convince the sharepoint admins that their system is borked when designer works perfectly when it's not routed through the loadbalancers

Sounds like typical Sharepoint admins, then. Is Designer being hosted on the same hardware / server as the Sharepoint libraries?
 
Top
Sign up to the MyBroadband newsletter
X