I don’t think this problem/solution is much different in older versions.
Problem: when you send a link from Communicator client to another, the link isn’t clickable, has a _ (underbar) in front of it, or both. Results may be different on different computers. It’ll look like this
_http://www.google.com
Solution: Two things are happening here that are not related. The first is the OCS Server (and Edge Server) have the URL Filter enabled, which are adding the _ underbar to all links. Also called “Intelligent IM Filter”. You need to tone that filter down or disable all together to your liking. If users are coming in through an Edge Server, they will follow the Filter settings of the Edge Server they are using, which seams to supersede the Front End Server (my guess is the most restrictive wins). So be sure to set it on both servers separately. Results were instant in new IM’s.
The other issue is the lack of a clickable hyperlink. If you disable the URL Filters above, the underbar goes away but links are still not blue and underlined. To fix this you need to apply a GPO or set a local registry setting to allow Communicator to make hyperlinks clickable:
HKEY_CURRENT_USER\Software\Policies\Microsoft\Communicator\
new DWORD EnableURL=1
After that exit and restart Communicator.
In both of these cases they are secure by default, which is great; but even years after this features release over several versions their use and configuration are still a mystery to most starting out.
Published on
Oct 1, 2009 in
Microsoft, Networking and Security, Solution Writeups and Tech.
Tags: activesync, email, exchange, firewall, isa, Microsoft, timeout, windows mobile.
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.
On trying to remove a old server from the directory (2003 server in a 2003 forest) I received this error
Failed to configure the service NETLOGON as requested “the wait operation timed out.”
The root problem was that this domain controller had a DNS entry to another domain controller that no longer existed. It was trying to contact it but couldn’t. Removing that entry and running dcpromo.exe again solved it.
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.
Also seen as:
- search is running but no results returned
- search errors in event log (can’t access content, etc.)
- you can access sites fine from other boxes but not from the local server
- only seems to happen for URL’s (http://sitename1, http://sitename2) that are different then the host name (http://servername).
Problem:
Windows Server 2003 SP2 and newer (Windows Server 2008) have a Anti Denial Of Service feature that prevents the server from accessing itself via different names (that’s the simple answer).
Fix (assuming you want to keep your custom URL’s):
- Set a registry value to turn off this security feature (I still don’t understand the specific type of attack that it’s preventing)
- Set a registry value to a list of all the cname’s your server goes by.
Further Info:
Rant:
In the KB Microsoft basically says “don’t turn it all off unless your lame”, so your left with “edit the registry every time you add a website”. This is a cumbersome workaround for something that happens out of the box default. Most SharePoint boxes will want more then one web site name and best practice says to NOT make production sites the server name. IMO SharePoint should be updating the reg key itself and keep in sync with the host headers created/managed by central admin. Or, the localhost loopback “new feature” should be looking at iis host headers and allowing them.
