Forum Discussion

Richard_Bedford's avatar
Richard_Bedford
Icon for Nimbostratus rankNimbostratus
Jan 24, 2008

HTTP 1.0/1.1, SSL, BigIP and Sharepoint <--BigIP noob...

Dear All,

 

 

I'm a BigIP noob and have been asked to look into an issue we have with the installation of our BigIPs. (note: I didn't do the install)

 

 

Setup:

 

 

BIG-IP 9.4.0 Build 517.5

 

 

Sharepoint Portal and Services 2003 SP2 running on W2K3 Server Enterprise SP2

 

 

IE7 client.

 

 

Client connects to BigIP virtual server over SSL.

 

BigIP forwards requests to IIS/Sharepoint via normal HTTP.

 

 

When going via the BigIP and trying to make changes to the website via the built-in 'edit' functions, everything seems to work until 'save' is pressed, then we get this error popup:

 

 

'Cannot retrieve properties at this time.' - followed by 'Cannot save your changes.'

 

 

If we go direct (over HTTP) to the Sharepoint server, it all works fine.

 

 

I've captured packets from wireshark and the only thing I can see different is that when the POST is via the BigIP it's posted as HTTP/1.0. When direct it's as HTTP/1.1

 

 

Q: Should this make a difference?

 

Q: Can I create an irule so that when posting data it's forced to post as HTTP/1.1?

 

 

TIA,

 

 

Richard B.

 

 

ps - off on my BigIP courses next week, but have been asked to look at this as a priority.

 

 

application delivery
dev
devops
iRules
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Jan 24, 2008
    Hi Richard,

     

     

    I can't see that the request version being 1.0 would break the edit process. You might try searching on MS's support site for more info on what might be causing the error. Once you figure out the cause then you can consider how to potentially fix it with your BIG-IP.

     

     

    Here is one KB article on the error:

     

     

    "Cannot retrieve properties at this time."

     

    http://support.microsoft.com/kb/830342

     

     

    And another possible solution:

     

     

    http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/MS-SharePoint/Q_21975446.html

     

     

     

    I have found a solution after speaking with Microsoft Technical support. They were able to duplicate our problem using our web.config file.

     

     

    The culprit was in an http handlers section of the file. I.e.

     

     

     

     

     

     

     

    By removing the first line, "" the problem was fixed.

     

     

    I am waiting for a for more information from Microsoft on how this could cause the issue.

     

     

     

     

    Aaron
  • Richard_Bedford's avatar
    Richard_Bedford
    Icon for Nimbostratus rankNimbostratus
    Mar 28, 2008
    After much scratching of heads we came up with a solution to this problem. I don't think it actually 'fixes' the issue, but it's a workaround that works.

    I discovered that if SSL was enabled on the IIS servers, and then we used SSl all the way through, we had no problems. So I devised a solution that used HTTP from the LTM to IIS for 'normal' web browsing, but whenever a 'post' was made, the LTM used SSL at the back-end.

    After tweaking the iRule (thanks nmenant) for stickyness between the http and ssl sessions, and enabling a streams profile to change any spurious http:// links into https:// (and applying a rechunk http profile with accept-encoding removed), it all seems to work.

    This is the iRule we're using:

    when HTTP_REQUEST {
 Read from persistence table which pool node the client previously connected to and
 set the IP_ADDR variable to the node IP address
set IP_ADDR [session lookup uie [IP::client_addr]]
 Look for the 'POST' method - a client is posting data back to the portal
if { [HTTP::method] equals "POST" } {
 If the client hasn't yet connected, let the LTM find a suitable node
if {$IP_ADDR == ""} {
 Set the LTM pool to the 'SSL' enabled pool
pool SPS_SSL_pool
} else {
 If the client has previously connected, force the client back to the same node in the pool
pool SPS_SSL_pool member $IP_ADDR 443
} 
}
else {
 Not a 'POST'...
 Disable the LTM-to-server SSL profile (so LTM talks in the clear to IIS)
SSL::disable serverside
 Select the HTTP only pool
 If the client hasn't yet connected, let the LTM find a suitable node
if {$IP_ADDR == ""} {
pool SPS_HTTP_pool
} else {
 If the client has previously connected, force the client back to the same node in the pool
pool SPS_HTTP_pool member $IP_ADDR 80
}
}
}
when LB_SELECTED {
 Record in the persistence table which client is load balanced to which node in a pool
session add uie [IP::client_addr] [LB::server addr] 1200
}

    This also requires a default pool to be added.

    I hope this can help other people with Sharepoint issues.

    Richard