Forum Discussion

MeAndMyBIGIP_60's avatar
MeAndMyBIGIP_60
Icon for Nimbostratus rankNimbostratus
Jun 29, 2009

Sharepoint Content Editor Webpart dies behind F5

We made the move to put an existing Sharepoint 2007 site behind an LTM 6400 running 10.0.1, and using SSL Offloading.

 

The move went great, the Application Template made it super-easy... EXCEPT:

 

Now, when the site admins log in and try to edit pages using the Content Editor Webpart in IE8, they get:

 

"Cannot retrieve properties at this time"

 

If we take the F5 back out from in front of the site, we're good.

 

Recommendations I've seen say to either restart IIS (no change), or to re-extend the site (sounds messy), but all assume and point to ISA being the problem, which I only mention as it sounds like there's a problem with the SSL to HTTP traffic translation

 

Did I miss something?

 

--MeAndMyBIGIP

10 Replies

  • Does the error occur only with IE8? What about IE7 or IE6 or FF? Can you use a browser plugin like Fiddler to compare a working browser versus a failing one?

     

     

    This post has a few suggestions from people that encountered the same error:

     

     

    http://www.sharepointblogs.com/agoodwin/archive/2007/09/03/content-editor-webpart-error-quot-cannot-retrieve-properties-at-this-time-quot.aspx

     

     

    Aaron
  • Hi Aaron -- thanks for the reply and the link.

     

     

    From what we've seen, it's only on the IE variants. Firefox gets you edit-ability, however it's only from within the small webpart editor window-let (?) that only give you a small text box to work within.

     

     

    It's a workaround for now, but not doing it for us, especially since everything works fine when we bring it back out from behind the F5.

     

     

    I actually spent the better part of yesterday comparing scenarios from that very link, but hadn't done anything with Fiddler... sounds like as good a time a any to start it up.

     

     

    Me
  • Okay... so newbie to Fiddler, but made sure to get the version that can see HTPPS traffic. Here's what we got when we repro'd the error:

    ResultProtocolHostURLBodyCachingContent-TypeProcessComments 
     130401HTTPSwebsiteURL 
     /Programs/BetaMobile/_vti_bin/WebPartPages.asmx341text/html; charset=us-asciiiexplore:4588 
     131500HTTPSwebsiteURL 
     /Programs/BetaMobile/_vti_bin/WebPartPages.asmx534private text/xml; charset=utf-8iexplore:4588 
     132304HTTPSwebsiteURL 
     /Programs/BetaMobile/_themes/Lacquer/siteactionsmenugrad_lacquer.gif0private,max-age=0 iexplore:4588 
     

    The 500 appears to be when the popup "Cannot retrieve properties at this time" shows its face.

    FWIW, there's no indication in the W3SVC logs of this particular 500 error.

    Again, this is client-side in IE8 only, WinXP, Win7 and WinVista. Site is running on IIS7/Win2008 behind an LTM 6400 10.0.1 that was created using the Sharepoint 2007 Application Template.

    ?

    -Me
  • Update:

    OK so there actually was some info in the IIS log....

    When it doesn't work:
        
     datetimes-ipcs-methodcs-uri-stemcs-uri-querys-portcs-usernamec-ipcs(User-Agent)sc-statussc-substatussc-win32-statustime-taken    
     6/30/200916:04:14WFE Node1 IPPOST/Programs/BetaMobile/_vti_bin/WebPartPages.asmx-80domain\admin.userF5 IPMozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+5.1;+Trident/4.0;+GTB5;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+3.0.04506.648;+.NET+CLR+3.0.4506.2152;+.NET+CLR+3.5.30729;+InfoPath.2;+MS-RTC+LM+8)50000546    
     

    When it does work:
        
     datetimes-ipcs-methodcs-uri-stemcs-uri-querys-portcs-usernamec-ipcs(User-Agent)sc-statussc-substatussc-win32-statustime-taken    
     6/30/200915:57:36FQDN IPPOST/Programs/BetaMobile/_vti_bin/WebPartPages.asmx-443domain\admin.userClient Workstation IPMozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+5.1;+Trident/4.0;+GTB5;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+3.0.04506.648;+.NET+CLR+3.0.4506.2152;+.NET+CLR+3.5.30729;+InfoPath.2;+MS-RTC+LM+8)20000156    
     

    I can easily repro this error condition from any IE browser by simply moving the site back behind the F5. As well, not only can I not edit the contents of an existing page, I can't create a new one.

    I can reliably perform these actions successfully from other browsers using the same creds (Firefox, Chrome, etc)
  • hope this isn't bad form, but wanted to bump this up to get a little more airplay, and see if anyone else has seen this issue... thanks!
  • You might try opening a case with F5 Support. They could help you compare the browser recordings from a successful request with a failing request. You might also be able to enable verbose errors or some kind of debug on Sharepoint to get a better idea of what Sharepoint doesn't like about the requests from IE clients via LTM versus direct.

     

     

    Aaron
  • Hello MeAndMyBIGIP,

     

     

    I was wondering... the logs show https and you mention that when you pull the BIG-IP out of the equation everything works fine. Are you SSL offloading onto the BIG-IP and would you mind showing your AAM's?
  • Right...

    When it doesn't work (this is when we're behind the LTM with SSL Offloading enabled):
           
     datetimes-ipcs-methodcs-uri-stemcs-uri-querys-portcs-usernamec-ipcs(User-Agent)sc-statussc-substatussc-win32-statustime-taken       
     6/30/200916:04:14WFE Node1 IPPOST/Programs/BetaMobile/_vti_bin/WebPartPages.asmx-80domain\admin.userF5 IPMozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+5.1;+Trident/4.0;+GTB5;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+3.0.04506.648;+.NET+CLR+3.0.4506.2152;+.NET+CLR+3.5.30729;+InfoPath.2;+MS-RTC+LM+8)50000546       
     

    When it does work (this is when we're NOT behind the LTM with SSL going straight to the server itself):
           
     datetimes-ipcs-methodcs-uri-stemcs-uri-querys-portcs-usernamec-ipcs(User-Agent)sc-statussc-substatussc-win32-statustime-taken       
     6/30/200915:57:36FQDN IPPOST/Programs/BetaMobile/_vti_bin/WebPartPages.asmx-443domain\admin.userClient Workstation IPMozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+5.1;+Trident/4.0;+GTB5;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+3.0.04506.648;+.NET+CLR+3.0.4506.2152;+.NET+CLR+3.5.30729;+InfoPath.2;+MS-RTC+LM+8)20000156       
     

    AAM is set to https://FQDN with Zone set to INTERNET
  • I forgot to mention. We had problems with some of the admin functions calling HTTP pages even though we were logged in via HTTPS... until we set the AAM's up like I mentioned.

     

     

    Just a thought.
  • We had the same problem thanks a stack naladar, this problem caused me to age a couple years, There are still numerous users out there that have exactly the same issue, i'll post some more detail with regards to the AAMs. MeandMyBigIP I see you struggled with this for months, hope you came right eventually. It would be great if we can have a note somewhere in the deployment guide RE. the AAM's.