Exchange 2007 OWA Page Does not work unless you put a trailing / on the end of the URL.

I need some help before I put a perminent dent in my head from banging it on the wall.

Brand new SBS 2008 install, which was a ball of fun, but that is another story. Got the server all up and running, and everything was good. Then, tried to put the Trend client agent on the system, which caused a BSOD on the tcpip.sys file. Finally got trend removed from the system, and all seems well except OWA. For what ever reason, you can no longer use the url HTTPS://Server.servername.com/owa. It comes up page cannot be displayed. It will how ever come up when using HTTPS://server.servername.com/owa/. Please someone tell me they know why I have to have that last / for the page to work!! I have users on BIS, and BIS will not allow me to put that last / in, so no one is getting their email on their blackberries either.

Those solutions are ok for what they are meant for... for people forgetting to type in https:// or just going to mail.servername.com and forgetting the /owa at the end. But, my problem is different. On a normal exchange system, you should be able to type in https://mail.servername.com/owa and have it bring up the correct login page. If you notice, when you do use that URL, IIS automatically sends you to the correct place. But, for some reason, on my system if you leave off that last / you just get a page could not be displayed error. Its almost like there is not even a server there.

Ok... so they couldnt fix it either... so I tried the redirect, that doesnt work any better. It's almost as if IIS doesnt even see a web being located there.... Even with the redirect, I get a page cannot be displayed message.

No, neither works. I do get the warning that the SSL cert doesnt match the name, but as soon as you continue anyway, I just get page cannot be displayed. Using the extra / at the end of both the IP and localhost does work.

One thing to add, with the problem with the Trend install, they do have an article on their KB that says the following:

The setup requires .NET 1.1 for installation. However, installing .NET 1.1 on Exchange 2007 modifies the Outlook Web Access (OWA) settings and prevents users from using OWA. This is a NET1.1 compatibility issue with 64-bit .NET2.0. For this issue, Trend Micro recommends installing the Security Server on another computer.

Now, this KB is on for version 5.0 of the product, and I am using 5.1. Everything on Trend's site says this product works with SBS 2000, 2003, and 2008. So, how they can say it works with those servers, but then state that they recommend it to be installed on another computer is garbage. Any possiblity that .net could be the cause of this issue?

Dont think it is outside of this server since I cannot even connect to it locally. There is no ISA or any active firewall on this network, just a standard Netopia router. This all worked fine until the Trend install last night.

One thing I did notice, and it may or may not be related. I have another customer that has a new install of SBS 2008 as well, so I have been using their system to compare any differences. The only one I can find is that on the system that works, they have the standard OWA web in IIS. On this system that is not working, there is the OWA web, then below that web, is ANOTHER virutal web below OWA that is called 8.1.359.2. Research on this web is that it is a part of the Exchange Rollup update, so it looks like it is supposed to be there.. but maybe something else is hosed along the way that is causing the redirect to that updated site to be broken? The working server does not have that web, and reports that all windows updates have been applied....

Ok... more digging shows that those subwebs are a normal addition when you install Rollups... I have another box that has been running Exchange 2007 since the beginning, and it has 6 of those subwebs. So, that web itself i dont think is the problem, but maybe something that tells the browser to look into that new folder is?

I have tested this on an SBS 2008 system and both /owa and /owa/ works correctly.
Was this system setup with the wizards?
If you run the Best Practises tool for Exchange from the Toolbox, does that flag anything?

Is this SBS Standard or Premium? Do you have ISA on this machine as well?

Yes, that was the first thing that was done... Trend actually was causing BSOD's, so I had to get that removed just to get the server stable again. It has to be something that the trend install did, but the uninstall did not repair/replace.

Actually, IIS wants the trailing slash (since OWA is a folder name), but since it knows that people want to omit it, it generates a 301 or a 302 response:http://support.microsoft.com/kb/298408
Which the client then automatically responds to by requesting the same resource but with a slash appended. In your case, either IIS is no longer sending it (check your IIS logs to see if it is), or the clients are no longer reacting (which seems even stranger).

I have been trying to work with the logs, and I went through, stopped the web, renamed the current log file, started the web back up, and tried to goto the page without the slash. Nothing at all is logged.... put the slash in the URL, it comes up just fine, and the log shows that transaction.

This is happening on all PC's, not just domain systems, even ones that have no relation to this client at all.

Changing the log files (you said you renamed it) will not help you - they only show how the server reacts to the various requests that it accepts. So, when you try to go to owa without the trailng slash, nothing is logged? Try again, and wait a few minutes before checking the log file. IIS keeps log lines in memory before flushing them to the file every few minutes. If you can, try posting the log entries here.

I have done that.... I can replicate it many times.. I can rename the log file (Only to give me a fresh copy so I am not wading through 1000's of lines), start the web, and then try to open the OWA page. I have let it sit, nothing is logged. As soon as I put the slash on the URL and open that page, I can go right into the log and see that transaction.

See how one of the leading financial services organizations uses Recorded Future as part of a holistic threat intelligence program to promote security awareness and proactively and efficiently identify threats.

As another troubleshooting step, I tested hitting other virtual webs on the same site, and they do not require the trailing slash either. It is solely a problem with the OWA subweb. I have also gone through the steps of using the exchange power shell to completely remove and recreate the OWA web, no change there either.

I don't have IIS7 in front of me right now - we may need to come back to that. Another thing to try - if you sit at the server console, open a CMD prompt, and type the following (some of it will not be visible, or correctable, so type carefully), what is displayed as a response to the GET command?

Tried your command, nothing happens at all, just goes to the next line with the cursor.

The site is actually running on port 443, so tried that as well, same thing.

There are multiple sites on this system, so there are host headers involved... even tried to telnet to localhost 443, then did GET mail.granitecontracting.com/owa and got nothing back there as well.

Looked around for your wildcard applications... if you are talking about the app pool, it is just assigned the standard app pool the same as my other SBS installs.

May have found something... HTTP Redirects do not seem to be working on this web at all... I went into the HTTP Redirects control panel for the OWA web and set it to redirect to http://www.cnn.com. Restarted IIS, I still get nothing without the slash, and with the slash I still get the OWA login page. If I am thinking right, i should have gotten CNN, right?

More troubleshooting... Used the exchange powershell to create a new OWA VDir under the default web site, and it has the same problem there.... so something in the OWA config has to be our problem... This is where my knowledge of IIS gets thin as I am not sure exactly what config information is stored where. I did find the web.config file for the OWA site, and it had some redirect line in there that was NOT in the web.config.bak file.. removed that line, tested, no changes.

You say that there are several sites on the server. There may be things other than host headers involved. Check that the Default Web Site is configured to use port 80 for TCP and port 443 for SSL. Is there a Host Header configured? If so, then obviously things like 'localhost' aren't going to work. Are any of the other sites configured to use the same ports? Remember that Host Headers don't work with SSL. If you have several sites that use SSL, then they must use separate port numbers or IP addresses. Host Headers aren't enough.

Had a chance to look at wildcard mappings in IIS7. If you look at the properties of /owa in IIS Manager, then Handler Mappings, wildcard mappings are indicated by a path of just '*'. On mine there are three: OPTIONSVerbHandler, TRACEVerbHandler, and StaticFile. Anything else can be viewed with suspicion. Also look for ISAPI filters in the Default Web Site (there should be just Exchange ActiveSync and Exchange OWA cookie auth), and at the server level (there should be just ASP.Net). Beyond this, I'm getting a bit stuck. This is more of an IIS problem, I think, than an Exchange one (which is my area). I think you'd have more luck with a new question in an IIS zone, asking what controls the courtesy redirect.

Well... not 100% sure what I did to fix the issue, but never did get a straight answer on why the HTTP redirect wasn't working. My theory is that when you make changes to the OWA settings via the EMC, the changes are not made to the actual web unless you restart the whole server. I was just restarting IIS, and that wasnt making a difference.

What I think I did to make it work was in the EMC, i went under the properties of OWA and set the internal and external URL for OWA to https://mail.granitecontracting.com/owa without the trailing slash. Then I restarted the system, and all is working. Now, this was one of the first things I looked at, and played with, but did not do any type of restarting of the whole system at that time. Also, I did not dig deeper into that because I have another SBS 2008 system that is working, and I was using it to compare settings to, and it has the trailing slash in the URL properties.

So, it has a 95% chance that working with those properties fixed it... but I was also doiing things with removing and recreating the OWA web using the exchange power shell, and all of those things were done before the reboot as well.

Well, I'm glad you got it working in the end. You shouldn't have had to restart the server, but there is a process that periodically copies from EMC into IIS. In E2003, it was called DS2MB ot MSExchangeMU, but the name may well have changed in E2007. Anyway, it was common for this process to fail (and you would therefore see events in the event log), thus preventing the settings from being propagated to IIS.

In this video we show how to create a User Mailbox in Exchange 2013. We show this process by using the Exchange Admin Center.
Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center.
Navigate to the Recipients >> Mailb…

The basic steps you have just learned will be implemented in this video. The basic steps are shown to configure an Exchange DAG in a live working Exchange Server Environment and manage the same (Exchange Server 2010 Software is used in a Windows Ser…