Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds


  Asked By: Stacey    Date: Jul 30    Category: Sharepoint    Views: 4066

i currently have a sharepoint server that we reverse proxy outside the
network via https.

inside the network the site is accessed http://sitename.domain.org and
outside https://sitename.domain.org. (still actually working the bugs

my question is what links will be sent in things such as alert emails?
from a limited test that i've done so far the http site is what goes
out in the link. if that's how its supposed to work what's the best
process to redirect that http to https outside the network?



19 Answers Found

Answer #1    Answered By: Trevor Davis     Answered On: Jul 30

Things like Alerts have no http  context to use to decide which Alternate
Access Mapping to use to create links. So Alerts will always default to
using the Default Zone address in the AAMs.

Answer #2    Answered By: Kristie Hardy     Answered On: Jul 30

what's the best/recommended way to make this work? create a
custom redirect  on the outside network  or is it easier just to make
the external site https  inside and ouitside the network?

Answer #3    Answered By: Shayla Mcbride     Answered On: Jul 30

The best way to handle it depends on the resources you have at your

1) If you have a sophisticated Firewall, you can let it handle the
HTTPS termination and leave everything in SharePoint as HTTP.

2) You can set the default zone to be HTTPS, that way things  like
Alerts will default to the most accessible address. Users who actually
access the site  using an Intranet or FQDN based AAM will still see non
https links, except in alerts. (This is what I normally do. But you
have to make sure you have all the appropriate AAMs entered for example,
both http://server <http://server> and http://server.domain.com
<http://server.domain.com> need to be AAMs)

3) You can train people to add the 's' to the links  they get in
things like alerts (Low tech, but it does work)

Answer #4    Answered By: Jarvis Rowe     Answered On: Jul 30

#2 is how i have it setup now. my only issue is the group
likes the idea of alerts, but most of them are outside the network
(board of directors). the isa server  is handling the https.

but your post has me re-thinking... if i add the https  site as default
then the alerts will go out as https. i can then create a redirect
inside that if https://site.domain.org is entered inside  the network  to
redirect to http..

Answer #5    Answered By: Christian Waters     Answered On: Jul 30

I am having trouble with this as well. We have a site  that has an
external domain  for access, but all alerts arrive with embedded links
as http://<servername>.

The default URL is hard-
coded into the Web App at creation so I started from scratch. I
wiped all Web Apps, and created a fresh one, using the external
domain at creation. I then created a Host Header site collection.
Everything pointing to external domains, etc.

Outcome: Alerts are still arriving with the http://<servername> in

Any ideas on how to get alerts to arrive with the external URL,
whether that is using AAM, etc. I have tried everything I know; AAM,
new Web Apps, new Site Coll, etc. Is this something with the initial

By the way, this is WSS 3.0, not MOSS.

Answer #6    Answered By: Virendar Bahudur     Answered On: Jul 30

When you created your site  collection did you use the <servername> as
the Host Header or did you use the FQDN? The first default Alternate
Access Mapping created becomes the address used for alerts. You have to
create your Host Header site collection with the FQDN of the server  as
the Host Header. You can add additional Host Headers as AAM mappings
later. It's the original one that counts.

BTW, it works this way in both WSS and MOSS.

Answer #7    Answered By: Sierra Beck     Answered On: Jul 30

You can change the default internal URL by 'edit public URL' in
Alternate Access Mappings. Usually, this changes the alert  URL sent in
messages. Be aware you must then create an entry for the original URL,
or traffic will fail.

It seems FBA zones might behave differently, but I haven't had time to
lab this and verify the behavior.

Answer #8    Answered By: Elisabeth Walsh     Answered On: Jul 30

Following up on this because I just saw the latest MS SharePoint team
blog post. They're introducing some new administration tools including
an STSADM command called "updatealert". From the post:

"Alerts in SharePoint store the URL which the users used to create
them—which is needed so that users of different "zones" get the proper
URL in their email—but if the URL changes you can now use "STSADM –o
UpdateAlert" to let SharePoint fix these alerts"

So it looks like the url in alerts _should_ work  how I expect and want
them to as opposed to what Paul described, but my current install
isn't working  how MS describes and is rather behaving as Paul
mentioned. Now to figure out how to get the MS expected behavior...

Answer #9    Answered By: Bhavesh Doshi     Answered On: Jul 30

I think there is still some confusion on this one. Note that they are talking
in the BLOG about updating alerts created on different ZONES, not just different
Alternate Access Mappings. That means if you actually Extend the Web
Application to a different Web App (that's a zone) then the URL is stored as
part of the Alert. Otherwise the default address would be used.

I haven't tested this specific scenario, but it is at least plausible. However,
it requires that the alternative address be created by extending the Web app to
a different URL. You can't extend to an address that simply applies an HTTPS
version of the address, it would need to be a completely separate Url, because
it creates a separate website in IIS. For example, you could extend
http://intranet.company.com to https://extranet.company.com but not
https://intranet.company.com. From what I read in the BLOG, if you extend to a
different address the address is stored as part of the alert  when you create the
alert. So if you create the alert on intranet it will use intranet and if you
create it on extranet it will use extranet.

As I say I haven't tested that specific scenario. I have tested doing it on a
separate Alternate Access Mapping and it does NOT store the AAM address, it
stores the default AAM.

Answer #10    Answered By: Elisa Santos     Answered On: Jul 30

Oh I know there's still confusion on this. It's in my head!

I'm still not quite seeing the MS described behavior on my server. I
have a web app extended into a different zone and with an AAM
(//machine name --> intranet.example.com) and I'm still seeing my
alerts going to the default (//machine).

The http  to https  of the same name does throw a different wrinkle into it.

Answer #11    Answered By: Tatiana Houston     Answered On: Jul 30

From how I understand it, https://portal and http://portal are as
different as http://apples and http://oranges. If a single character
changes, SharePoint Server 2007 sees it as a different URL altogether.

Answer #12    Answered By: Arlene Hodge     Answered On: Jul 30

SharePoint does, but IIS doesn't. http  and https  are both defined in
IIS for the same website. You can't extend a web app to a new zone and
only change from http to https. You have to supply either a different
port number or host header. Apples and oranges would/could be different
host headers and not just an AAM change. HTTPs://portal
<HTTPs://portal> and http://portal <http://portal> can only be an AAM

Answer #13    Answered By: Jolene Sandoval     Answered On: Jul 30

Why are you picking on me on Friday? (just kidding)

True. You would need to use another mechanism, such as a netscaler, f5,
or foundry, to differentiate the 'S'.

Answer #14    Answered By: Brandan Roach     Answered On: Jul 30

The entire toolkit can be downloaded from here:

(may wrap)

32 bit

64 bit

Answer #15    Answered By: Kai Carney     Answered On: Jul 30

Don't have a better solution, just the same problem. It's particularly
frustrating for me though because I want two less restrictive URLs in
addition to our intranet. One for employees coming in externally (AD
pool 1, basic http  auth) and one for partners coming in externally
(LDAP pool 2, form based auth).

What I don't understand is why Alerts don't have context. When the
user selects to be alerted, they are doing so from a context.
SharePoint should store that and use AAMs appropriately.

Answer #16    Answered By: Gaurav Nemane     Answered On: Jul 30

But there is no guarantee that the context where the user is creating
the alert  is the context where they will be receiving it. I would
expect it to be very common for users to create alerts while on the
Intranet at work, but then use them to access things  when home or off
site. If the context where the alert was created was used this would
lead to chaos. If you understand the process the way it works now is
manageable. Otherwise it would have to be managed per user.

Answer #17    Answered By: Marjorie Humphrey     Answered On: Jul 30

I've had a different experience with this.

Default: http://Servername (Windows Auth)
Internet: https://fqdn (FBA) - Extended Web Application port 443

Alert configuration:
When a user logs in via https:// and configures the alert, any alerts are sent
to the user with embedded https://. And, if a Windows Auth (Default AAM) user
makes a change to a document library via http:// an alert  is sent to the
external user with https:// embedded links  and vice-versa.

Answer #18    Answered By: Chelsey Watts     Answered On: Jul 30

can you help us understand how you get this behavior? I would
very much like to replicate.

If the internet zone uses windows auth (for grins), does it still use
https:// as the alert  URL? Paul and I are wondering if your
implementation is different because of FBA?

Didn't find what you were looking for? Find more on HTTP and HTTPS Or get search suggestion and latest updates.