If you’re running the IE9 Release Client (huge improvement over IE8) and sites are crashing it could be that your Java isn’t updated to version 6 update 24. Versions before that (I had update 23) will crash the web page and send it in a loop of crash, reload, crash, etc. You can also click the compatibility mode button (if you’re fast enough) to prevent the crash.
Archives For Networking and Security
They were getting random prompts for passwords in ActiveSync on Windows Mobile 6.0 and 6.1. They had Exchange 2007, and ISA Server 2006, but this problem showed up months after Exchange was migrated to 2007. It seemed random. The error on ActiveSync was the generic:
please log in access was denied 0×85010002
In the ISA Monitoring you would see a denied connection on your ActiveSync rule with this status:
12239 The server requires authorization to fulfill the request. Access to the Web server is denied. Contact the server administrator.
I tested with Windows Mobile Emulator from outside the firewall and was able to reproduce the error within hours (just letting it sit there).
I first thought this was the HTTP session timeout that changed with a Exchange 2003 service pack when Direct Push came out back in 2005. I remembered that setting and looked under the ISA Web Listener for ActiveSync on the Connections tab>Advanced>“connection timeout”. The wizard had correctly set it to 1800 seconds (30 minutes). No dice.
I poked around the web listener settings some more and noticed the timeout settings for forms authentication were set (this same web listener was used for OWA). ISA is supposed to be smart enough to not apply any of the forms auth settings to clients that don’t support it (falling back to basic auth as with ActiveSync).
Tom and the forums at isaserver.org confirmed my suspicion. The forms auth timeout was indeed affecting ActiveSync. To find it, look for the web listener of your ActiveSync rule, go to properties>Forms tab>Advanced> and make sure “apply session timeout to non-browser clients” is unchecked.
I see a lot of people saying they are getting auth prompts for public anonymous content on SharePoint sites. Once you have anonymous enabled in Central Admin and in the site collection, you’d expect it to be all good right?
I discovered one more resaon beyond the obvious permissions problems. If you put a graphic or something embded in a page, then publish that page but NOT the embeded object (i.e. it’s still draft or unapproved) you’ll get an auth prompt when the page loads.
On a busy (lots of stuff) page it can be tough to find what’s the issue. The quickest way I’ve found to discover the problem (99% of time an image) is to cancel out of auth prompts, then look for broken stuff on the page. An image you can right click the broken icon and find the location of it… then jump to that library and check the file. My bet is it’s never been published.
