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.
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.
What if you want to take your simple 2 NIC “Internal/External” firewall and add a DMZ to it on the fly? We recently tried this on a production firewall no less and hoped it would work. It did after a few bumps.
The big problem with changing your Network Template is that ISA wants’ to slick your config and start over, so you’ll end up with two options: Try to make a 3 NIC config work in your original design by adding in networks and network rules, or applying a new network template and then bringing your config back in via import. After failing the former (likely my lack of skills), we chose the later.
Mileage may very, but here’s some notes on what we did:
- Obviously you need the 3rd NIC installed first.
- Add the Subnets to the new NIC’s IP config for your DMZ aka “Perimeter” network in Windows.
- Export your firewall config, including all settings, make a copy of the XML file, and open for editing.
- We’re going to remove the network section of the XML file to prevent issues later. Once you’ve chosen a new network template, you’ll want to import the config back in, minus the network related stuff (which is what the network template will change for you).
- Search the XML file for the open and closing NetConfig tags:
- <fpc4:NetConfig StorageName="NetConfig" StorageType="1">
- </fpc4:NetConfig>
Remove everything between these two tags and save the file.
Run through the network template wizard for 3-leg perimeter. If clicking finish generates errors, work through them and come back to try again. Our single error was because we had web listeners using HTTP compression, so we removed all objects from “General > Define HTTP Compression > Return Compressed Data” and added them back in later after re-import.
Once template wizard works, notice the lack of rules in your firewall policy and missing objects. About now your thinking “OMG you screwed me!”, so import your augmented config and they should all be back.
You’ll likely have a few dupe firewall rules if you chose a template firewall policy other then “block all”. Sort your rules by the various columns to look for dupes. We had dupes for “Allow Internal Routing” and “VPN Clients to Internal Network”.
Lastly go through your rule list and ensure the From/To columns are filled in. You’ll want to restart the firewall service at this point to be sure it can start properly, and if it fails it’s likely a rule that won’t work in the new network config. Check event logs for hints. We had several rules we deleted and recreated based on new network names.
You should be trying hard to keep the firewall on when deploying Windows Server 2008. If you need to ping the server and haven’t enabled File and Printer Sharing, then open Windows Firewall with Advanced Security and under Inbound rules, enable “File and Printer Sharing (Echo Request – ICMPv4-In)”. Might as well enable ICMPv6 while your at it.