2

I'm running Exchange 2010 SP1. I have internet publishing for calendars setup and the ability to "publish calendar" is available to the users with the appropriate sharing policy.

I have published calendars with both Public and Restricted access levels. On both sets, I sent the internet share links to myself and have tried to access them from outside the corporate network. When attempting to use any of the links (either HTML web view or ICS subscription) for either of the calendars (Public with its readable URL or Restricted with the obscure URL) I am taken to the OWA login form.

The login form URL does show the redirect target of the calendar page, but that completely obliterates the desire to be able to publicly share these calendars. We want anonymous internet users to be able to open an ICS file and subscribe to our calendar.

How can I get the published calendars to just open without first dropping the internet user into our Exchange server's OWA login page?

Improve this question
5
  • What does the OWA virtual directory for Calendar have for permissions in IIS? Sounds like it isn't set to Anonymous but rather forms based.
    – TheCleaner
    Jan 7, 2014 at 19:01
  • the /owa/Calendar virtual directory has Anonymous enabled and all other authentication types (including Forms) disabled. That was actually my first stop, sorry for not including that.
    – Ruscal
    Jan 7, 2014 at 19:41
  • Are you saying that it is redirecting the URL to the OWA login page? Do you have a custom redirect for that site setup in IIS perhaps that auto redirects to maybe the SSL version or similar?
    – TheCleaner
    Jan 7, 2014 at 19:48
  • There is a reason you're sporting that rep. We do have a catch-all redirect pushing from HTTP over to HTTPS, and that was it. The URL sent by Exchange was http:// (even though the external OWA url is https:// ). If I add the magic "s" in there the ICS file (and OWA Calendar view) both work perfectly without requesting additional authentication. Now to figure out how to fix that and I'll be all set. Thanks TheCleaner, I totally missed that.
    – Ruscal
    Jan 7, 2014 at 19:58
  • Welcome mate. I'll change my comment to an answer. I had to re-read your question to catch the part about "first dropping the user into our login page" to think it through.
    – TheCleaner
    Jan 7, 2014 at 20:04

1 Answer 1

Reset to default
2

As you've discovered from my comment, if you have a catch-all redirect in IIS that is grabbing HTTP requests and redirecting them to SSL (often done for OWA so that the user doesn't get a 404 on the HTTP version), you can experience the issue you are having.

You may check and make sure you are doing proper http/https redirecting instead of a catch-all for everything. http://support.microsoft.com/kb/975341 -- I've seen cases where they've carried over the old Exch2k3 way of using a redirect file but it's better to do it this way.

If you have any questions let me know.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .