Logo 
Search:

Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Links generated not always using proper protocol or fully qualified

  Asked By: Tameka    Date: Sep 09    Category: Sharepoint    Views: 2041

One of the most annoying things about the SharePoint configuration
I've been working with is its propensity to not always generate links
properly. For the sake of example, I have a server with the fully
qualified hostname of share.test.com and an internal hostname of
share. This server has multiple applications running across multiple
ports, all on SSL certificates (HTTPS). Most of the time (about 99%),
SharePoint will correctly use links in the format:

https://share.test.com:port/whatever

but occasionally, it will generate links in the format:

http://share:port/whatever

Not only is this the wrong protocol, but it uses the internal network
hostname to create the link, which isn't typically correct! I've
noticed that certain search functions across web apps are broken
because of this and some of the admin pages create bad links (between
the SSP Admin pages and Central Admin pages, for instance).

Is there a configuration setting missing someplace? We do have host
headers defined, but only on the default web application (and not on
any of the others).

Share: 

 

8 Answers Found

 
Answer #1    Answered By: Alphonso Mckay     Answered On: Sep 09

There are two potential scenarios that I can think of which cause this
type of result.

The first is not setting up Alternate Access Mappings correctly. When
links on a page are generated  SharePoint will match the link  to the
protocol/address of the incoming request IF an alternate Access Mapping
of a matching protocol/address exists. Otherwise it will normally
default to the AAM of the default zone. AAMs are setup per Web
Application. Having one setup on Share.test.com won't help with
Share.test.com:otherport.

The second time  this happens is with links  returned by email from things
like alerts. When an alert fires there is no protocol/address to use in
a request to match an Alternate Access Mapping. So Alerts will always
use the address from the default Zone. This is a common mistake,
because many people will setup a site using the Internal Server name
address first (default zone). Then Alerts are always generated using
the least accessible address in the link. The default zone should be a
widely accessible address.

 
Answer #2    Answered By: Daron Oneill     Answered On: Sep 09

The first is not setting up Alternate Access Mappings correctly. When
links  on a page are generated  SharePoint will match the link  to the
> protocol/address of the incoming request IF an alternate Access Mapping
> of a matching protocol/address exists. Otherwise it will normally
> default to the AAM of the default zone. AAMs are setup per Web
> Application. Having one setup on Share.test.com won't help with
> Share.test.com:otherport.

This sounds most likely, since we're not having any problems with
alert links that I've been informed of. Looking at our alternate
access mappings, I see entries like:

Internal URL: http://share:port
Zone: Default
Public URL for Zone: http://share:port

Internal URL: https://share.test.com:port
Zone: Custom
Public URL for Zone: https://share.test.com:port

Each web application has the same pair of entries with the same
difference in usage of http/https and the fully  qualified or local
host names. Port numbers are offset by one in each pair (so the
default http  link might be using 32123, while the custom https  is
using 32124). It seems like the custom and default zone information
should be reversed to work properly - or is the current configuration
correct?

 
Answer #3    Answered By: M Juarez     Answered On: Sep 09

Those are probably fine, but I would add a third entry for the Intranet
zone.

Internal URL: http://share.test.com" target="_blank" rel="nofollow">http://share.test.com:port
Zone: Intranet
Public URL for Zone: http://share.test.com" target="_blank" rel="nofollow">http://share.test.com:port

Without that entry people who request the FQDN of the server  using HTTP:
might end up with links  using HTTPS: and the FQDN instead of HTTP: and
the servername. I would actually make that the default Zone entry
instead of the simple servername. Then make the servername the Intranet
entry.

 
Answer #4    Answered By: Marty Mcdowell     Answered On: Sep 09

I usually add Host Headers and AAMs for the
server host names as well, when load balancing. This allows direct
testing of servers in the farm using the host name (http://wfe3) .

 
Answer #5    Answered By: Dakota Shaffer     Answered On: Sep 09

Changing the default values do seem to have at least fixed part of the
problem - some of those links  are now properly resolving to the FQDN,
but they're still pointing at http  (which I would expect, since that's
what the mapping points at). Is there any reason not to use https  as
the default and eliminate the custom entry (other than that the custom
entry has a slightly different port number than what the new default
and intranet entries have)?

 
Answer #6    Answered By: Ted Gilmore     Answered On: Sep 09

The Links generated  should normally match protocol  to the incoming
Request. Are the users accessing the server  via an HTTPS: address? If
so, is it possible that a firewall is stripping the HTTPS: protocol at
the firewall and sending the request to the SharePoint server as HTTP:.
If so, then You need to enable HTTPS: tunneling on the firewall so that
the HTTPS: protocol comes all the way to the SharePoint server.

I often use HTTPS: as the default Access Mapping since it is reachable
from inside and outside a firewall.

 
Answer #7    Answered By: Monte Cooley     Answered On: Sep 09

All users access via https  (though I've noticed that if I do certain
things on the machine itself, it goes to http  and works, which is a
little disturbing). This isn't a firewalled machine either, so it
seems like changing the default to the custom https settings would
work. I'll give it a shot.

 
Answer #8    Answered By: Guadalupe Bullock     Answered On: Sep 09

Continuing this - I think I've now got everything mapped properly, but
I'm still having a problem that seems related to the alternate access
mapping changes I just made. Just for reference, the mappings now
look like:

Internal URL: https://share.test.com:port
Zone: Default
Public URL for Zone: https://share.test.com:port

Internal URL: https://share:port
Zone: Intranet
Public URL for Zone: https://share:port

Each web app running  has its own pairing, set the same way (different
ports for each, obviously).

I'm still having a problem if I try to run any search from my MySites
application (which is one of the things  I originally set out to fix).
It attempts to direct the search to:

share/SearchCenter/Pages/Results.aspx?k=test&s=All%20Sites

I'm guessing I missed something when redoing the AAMs. I've done an
iisreset and still have issues. Again, this should be using https  and
the FQDN.

 




Tagged: