Forum Discussion

Stefan_Klotz's avatar
Stefan_Klotz
Icon for Cumulonimbus rankCumulonimbus
Jul 12, 2011

Sharepoint 2010 can't open documents

Hi,

 

we have a very complex Sharepoint 2010 setup with two Loadbalancer clusters in the path. Both VS doing SSL offload, but encrypt it again. This is necessary to use Cookie persistence.

 

Surfing the Sharepoint is not a problem, but when clicking on a document to open it the user gets a popup "Choose a digital certificate":

 

"The website you want to view requests identification.

 

Please choose a certificate."

 

If the clients tries to open the file directly they get a popup: "Could not open https://URL/filename"

 

Bypassing all the loadbalancer does not show this error.

 

From the customer we also got the following link for potential troubleshooting:

 

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

 

There something with HTTP OPTIONS is mentioned, but I don't know how this affects our configuration. I expect that the SSL-offload breaks the session, but I don't know how I can further troubleshoot and at the end how to solve this problem.

 

Disabling HTTP OPTIONS and PROPFIND verb support in Sharepoint 2010 seems to be NOT an option for the customer, so how to solve it on the Loadbalancer?

 

Are you aware of such a behavior or do you need more information of our configuration?

 

Thank you!

 

 

Ciao Stefan :)

2 Replies

  •  

    As the described behavior of the customer was that it is working sometimes and sometimes not (mostly not), we came to the conclusion that it seems to be related to the persistence configuration. Therefor we enabled only one poolmember on each Loadbalancer instance and the error wad gone. Then we tried it with two poolmembers on each Loadbalancer separately to verify if the persistence breaks only on the internal or external Loadbalancer. The result was that only the internal persistence, where the "real" Sharepoint servers are balanced, was somehow not working correctly.

     

    As already mentioned we are using default Cookie insert persistence with a Session Cookie.

     

    The solution for this problem was to change the Session Cookie (which will only be stored in memory on the client) to a file-based Cookie, by specifying a dedicated expiration time.

     

    Currently I still have no clear picture of this very strange behavior, but maybe someone of you can explain it to me.

     

    Thank you!

     

     

    Ciao Stefan :)

     

  • Hi Stefan,

     

     

    Are the pools names the same on the 2 clusters ? The cookie by default is named BIGipServer , would it be possible that the last cookie (near the backend) was lost when setting the cookie on the cluster nearest the client ?

     

     

    Thank for posting your solution.

     

     

    Fred.