Config : SP2010 std SP1, TMG 2010 SP2, Win7, IE9. The site in question is a database attached and upgraded and initially working SP2007 contentDB with customized feature for rolling out V3 MasterPages.
From the server without a hosts file - the site works fine. From my computer with a hosts file it also works fine. The TMG is in a DMZ, the SharePoint server in it's own domain. DNS settings have been checked in this domain.
I'm in a seperate domain. Logging on with credentials checked again AD in the domain where SharePoint resides.
There is clearly something with corruption of cache or maybe security concerning opening something from cache. The TMG cache is off - so take that out of your considerations.
I will continue to examine IIS cache and file based location of files. I would appreciate any insights into this type of problem .. especially from MCMs ;-)
I'm reading this on IE9 caching improvements - http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx - Worth the read.
UPDATE : On the IIS side running 7.5 - Three webapplications on 443, created on port 443, none on port 80. Only the default website in IIS is on port 80. There is a wildcard SSL terminating on an TMG 2010 SP2 and between the TMG and the SharePoint WFE IIS7.5 there is a dedicated SSL certificate.
UPDATE2 I just removed the Timer Cache XML files, cachi.ini to 1 and started the timer service again. For whatever reason site actions and such are working, Ok button for adding new list items not and the CSS on my system master is not loading.
UPDATE3 We are back on testing TMG 2010 SP2. Current behaviour : without a hosts file entry.
- After altering the hosts file I need to delete cache (do that from fiddler) and the links start working again (with a hosts file entry that is).
Client Object Model Permission Requirement
You can require that the user must have the Use Remote Interfaces permission in order to use the Client Object Model to access the server. The Client Object Model is used by some parts of the UI. Enabling this prevents users from performing some tasks using the UI if they do not have the Use Remote Interfaces permission.
UPDATE 5 - We did a TMG clean install - that works - so it seems TMG. We have an error 50 on the Scriptresource.axd leading to a HTTP status 500 in fiddler on protocol HTTPS. Googling this issue results in little concrete guidance.
UPDATE 6 - We narrowed it down to the Web access policy and Web compression filter. Turning them on and off in turn has resulted in the required result. Turning the Web compression filter on seems to do the trick - but Why?
- Edited by nicodejong Wednesday, December 14, 2011 2:24 PM
Great to hear you got the solution.
I have seen some strange things with compression and cache though. For instance IE6 had a bug loading OWA with compression enabled. It would load perfectly. On the next load though the style sheet was all wrong. The cause was that the style sheet was compressed and in cache, this caused the issue, so the resolve it we had to turn off compression on the .css content type! and clear the local cache!
Another problem I found was with an external site. The apache server on their side incorrectly compressed a page and this cause TMG to reject it. I had to exclude that site form requesting compressed content. Check the whole issue here: http://fixmyitsystem.com/2011/03/tmg-error-code-502-proxy-error-data-is.html