Forum Discussion
tarundlejr_9041
Nimbostratus
NimbostratusShare Point 2007 and Integrated Reporting Svcs
We were looking to load balance MOSS 2007 behind an F5 LTM (with SSL off-loaded the the LTM.) We followed the deployment guide provided by F5 Networks and everything seemd to be fine. However, when we tried to do anything with Integrated Reporting Services, we received an error that was less than helpful. The strange part is that we were able to take the LTM out of the configuration and everything worked.
The problem was a combination of Share Point Alternate Access Mappings (AAM) and the Share Point front end webservers resolving the FQND to the F5 virtual server. The result was that inter-server communication between the webservers and the SQL reporting server broke with the resulting error about "...Make sure that the Reporting Server is in Share Point Integrated Mode."
The fix is actually obvious after the fact. It's a combination of two things:
1) Spoofing the local host file on each of the front end SharePoint web servers to resolve the public FQDN to themselves.
2) We took out the Alternate Access Mappings (AAM) and used an iRule on the F5 to rewrite the http stream on the outbound traffic; modifying any URLs in the stream to point to https://FQDN instead of http://FQDN. Only the clients outside of the network needed the https.
Thats the fix. It took opening support calls with both F5 and Microsoft to get to this point. We went through several remote support sessions, took TCP dumps, Sniffed traffic between all the servers, etc. And, although the solution was worked out by myself and another engineer in house, both F5 (specifically Tristan Pipo) and Microsoft were helpful.
If you have any questions, please reply as I'll keep an eye on this thread.
- This is great information, and something that we don't currently document in our solution.
As soon as I get the chance, I'll repro this in the lab and add the steps into our SharePoint BIG-IP deployment guide.
Again, thanks for the information!
-Ryan 
tarundlejr_9041Thanks Ryan.
Although my primary responsiblity isn't networking and all the layer 3 stuff, I was lucky to have access to the LTM during the troubleshooting process. Although I haven't tried it yet, I think the only possible downside is that the "alternate access mappings" that were handled by SharePoint are now being handled by the LTM. I would assume you'd need to have all of the possible FQDNs accounted for in the stream iRule. Other application admins/engineer's may not have access to the LTM and they will need to engage thier network engineering team for any new web applications they deploy on thier SharePoint farm.
Also, we were very specific in the stream iRule. We have many virtual servers on the LTM not all of which need the outbound rewrite to https. So we spelled out the entire FQDN to avoid causing issues outside of the SharePoint configuration.
~Tom
brad_scherer_11I am currently facing the exact same challenge in my company. Could someone please share the code in a generic form? Currently I only have a standard http to https redirect as described in the implementation guide.
Thanks,
Brad
Dennis_F__24560Has the irule for this fix been posted anywhere?
Thanks,
Dennis- brad_scherer_11We have a standard redirect on the port 80 VIP to redirect to 443. On the 443 VIP we have the following irule:
when HTTP_RESPONSE {
Disable the stream filter by default
STREAM::disable
Check if response type is text
if {[HTTP::header value Content-Type] contains "text"}{
Replace any http:// instance with https://, unless the original string is http://example.com
STREAM::expression "@http://@https://@"
Enable the stream filter for this response only
STREAM::enable
}
}
This works for us.
Thanks,
Brad
