• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2188
  • Last Modified:

Problem with Exchange 2013 OWA

Dear

We've about 20 different customers with Exchange 2013 running, but since Friday we've trouble with an OWA that has worked before (no idea what changed).

The situation is as follows:

On customer site there is an Exchange 2013 Standard on premise installed with all roles on one server. It's a SME with about 25 mailboxes - nothing very complicated or large scaled.

All updates are installed and the current version is

Name                                    AdminDisplayVersion                     ExchangeVersion
----                                    -------------------                     ---------------
SRVEX01                                 Version 15.0 (Build 516.32)             0.1 (8.0.535.0)

Open in new window


The server itstelf works fine: ActiveSync, ECP, mailbox and mailtransmission - everything without problem.

However, when accessing OWA (doesn't matter if locally or externally) the OWA redirects the user to the Back End Site (https://internalservername:444/owa) which isn't available externally and throws a 404 when accessing from the exchange server itself (resource /owa/auth/logon.aspx isn't available on the Back End Site). I've played around with the internal and external hostname of the OWA installation, recreated the OWA virtual directory via shell and ECP - but the problem is still the same.

Does anyone has an idea why the login redirects me to the Back End Site (and port)? The same login works with the ECP like a charm.

The OWA is shown an version 2010, but I think this is just a MS bug, isn't it?

Name                                    Server                                  OwaVersion
----                                    ------                                  ----------
owa (Default Web Site)                  SRVEX01                                 Exchange2010

Open in new window


Any suggestion is appreciated,
Jan
0
schlueter
Asked:
schlueter
  • 5
  • 3
1 Solution
 
jrhelgesonCommented:
Run this command, provide the output:
Get-OwaVirtualDirectory | fl *URL*
0
 
schlueterAuthor Commented:
Sorry, I've been in bed some days (having the flu).

First of all, thanks for your reply. The output is:

Url             : {}
SetPhotoURL     :
Exchange2003Url :
FailbackUrl     :
InternalUrl     : https://[correctExternalFQDN]/owa
ExternalUrl     :

Open in new window

0
 
schlueterAuthor Commented:
And just to not confuse you: Of course I've also tried with the correct internal and external URL for all virtual directories (except PowerShell and Autodiscover). I just wanted to make sure that the internal hostname isn't used at any place... However, I've now switched to

Url             : {}
SetPhotoURL     :
Exchange2003Url :
FailbackUrl     :
InternalUrl     : https://[hostname].[domain]/owa
ExternalUrl     : https://[correctExternalFQDN]/owa

Open in new window


This changes nothing (server restarted)...
0
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

 
jrhelgesonCommented:
Okay, that's fine. I just wanted to record what those values were prior to re-creating the virtual directory.

Virtual directory corruption happens so often, that Microsoft created a button to automate the task of deleting & re-creating the virtual directories.  You can do this using the ECP, or Powershell.

Both methods are outlined here:
http://technet.microsoft.com/en-us/library/ff629372.aspx

I prefer using Powershell, as it creates the new OWA with the values obtained from the old, rather than having to go back and re-enter the configuration for InternalUrl & ExternalUrl.
Remove-OwaVirtualDirectory “ServerName\owa (Default Web Site)”
New-OwaVirtualDirectory  -InternalUrl “https://[correctExternalFQDN]/owa” -ExternalUrl “https://[correctExternalFQDN]/owa"

Open in new window

I also usually keep the internal & external URL the same so they're both using the same certificate, and I update the internal DNS to point to the server, but I don't know how your environment is laid out.

Be sure to run IISRESET /noforce after you've made the changes - no need to reboot.
0
 
schlueterAuthor Commented:
Thank you again for your reply. First of all, I've already recreated the VirtualDirectories. But your post helped me in another way:

I've now added a DNS entry to point to the external FQDN to the local IP and did a IISRESET. Now I get a login, which redirects me to https://[correctExternalFQDN]/owa/auth.owa. But this throws a 404.

Any more suggestions?
0
 
jrhelgesonCommented:
You need to ensure that all the virtual directories point to their proper URL's.  It is critical that the /owa and /ecp virtual directories share the same "https://[correctExternalFQDN]/" path (each pointing to their respective virtual directory, of course.)

Compare the output of the following commands:
Get-OwaVirtualDirectory | fl *URL*
Get-EcpVirtualDirectory | fl *URL*   
Get-OABVirtualDirectory | fl *URL*
Get-AutodiscoverVirtualDirectory | fl *URL*
Get-WebServicesVirtualDirectory | fl *URL*

Open in new window

Here for reference is the output from my server:
[PS] C:\>Get-OwaVirtualDirectory | fl *URL*
Url             : {}
Exchange2003Url :
FailbackUrl     :
InternalUrl     : https://mail.example.com/owa
ExternalUrl     : https://mail.example.com/owa

[PS] C:\>Get-EcpVirtualDirectory | fl *URL*
InternalUrl : https://mail.example.com/ecp
ExternalUrl : https://mail.example.com/ecp

[PS] C:\>Get-OABVirtualDirectory | fl *URL*
InternalUrl : https://mail.example.com/OAB
ExternalUrl : https://mail.example.com/OAB

[PS] C:\>Get-AutodiscoverVirtualDirectory | fl *URL*
InternalUrl : https://mail.example.com/autodiscover
ExternalUrl : https://mail.example.com/autodiscover

[PS] C:\>Get-WebServicesVirtualDirectory | fl *URL*
InternalNLBBypassUrl : https://exchange10.example.local/ews/exchange.asmx
InternalUrl          : https://mail.example.com/EWS/exchange.asmx
ExternalUrl          : https://mail.example.com/EWS/exchange.asmx

Open in new window

0
 
schlueterAuthor Commented:
We've reinstalled the Exchange and it works again...
0
 
schlueterAuthor Commented:
Not really a solution...
1
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

  • 5
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now