Exchange Server Pro » OWA

OWA Error: The Mailbox You’re Trying to Access Isn’t Currently Available

Paul Cunningham — Wed, 07 Sep 2011 12:07:25 +0000

During the co-existence phase of an Exchange 2007 to 2010 migration, when you have cut over your ISA Server publishing rules for Outlook Web App to point to the Exchange 2010 Client Access server, you may encounter the following error for some OWA users.

The mailbox you’re trying to access isn’t currently available. If the problem continues, contact your helpdesk.

Depending on your Exchange environment you may find that this is only occurring for some users and not all of them. In particular you may find that Exchange 2007 mailbox users in remote AD sites are receiving the error, but Exchange 2007 mailbox users in the internet-facing AD site are not.

This can occur because of how the Client Access servers handle OWA traffic differently, depending on which AD site the mailbox user is in.

For the internet-facing AD site the scenarios are simply as follows.

Exchange 2010 Mailbox user:

Connects to published name for Outlook Web App
The internet-facing Exchange 2010 CAS connects to the mailbox server in that site on behalf of the user

Exchange 2007 Mailbox user:

Connects to the published name for Outlook Web App
The internet-facing Exchange 2010 CAS redirects them to the legacy namespace, which is published to the internet-facing Exchange 2007 CAS
The Exchange 2007 CAS connects to the mailbox server in that site on behalf of the user

For mailbox users in remote AD sites the situation is slightly different.

Exchange 2010 Mailbox user:

Connects to published name for Outlook Web App
The internet-facing CAS proxies the connection to an Exchange 2010 CAS in the remote AD site
The Exchange 2010 CAS in the remote AD site connects to the mailbox server in that site on behalf of the user

Exchange 2007 Mailbox user:

Connects to the published name for Outlook Web App
The internet-facing CAS proxies the connection to an Exchange 2007 CAS in the remote AD site
The Exchange 2007 CAS in the remote AD site connects to the mailbox server in that site on behalf of the user

For this to work correctly there are a few configuration requirements.

The OWA virtual directories on the Client Access servers in the remote AD site must have Integrated Windows authentication enabled
The OWA virtual directories on the Client Access servers in the remote AD site must not have an external URL configured (it should be blank)
The internet-facing Exchange 2010 CAS needs a copy of the OWA resources files from any down-version Client Access servers it will be proxying to

Often people get the first two correct and leave out the third one. However without meeting that third requirement you will receive the error shown at the start of this article. On the internet-facing Exchange 2010 CAS you’ll also see an event ID 46 logged in the Application Event Log, with details similar to the following:

Log Name: Application
Source: MSExchange OWA
Date: 9/6/2011 11:42:35 PM
Event ID: 46
Task Category: Proxy
Level: Error
Keywords: Classic
User: N/A
Computer: HO-EX2010-CAHT1.exchangeserverpro.net
Description:
Client Access server “https://mail.exchangeserverpro.net/owa”, running Exchange version “14.1.323.3″, is proxying Outlook Web App traffic to Client Access server “br-ex2007-caht.exchangeserverpro.net”, which runs Exchange version “8.3.83.4″. To ensure reliable interoperability, the proxying Client Access server needs to be running a newer version of Exchange than the Client Access server it is proxying to. If the proxying Client Access server is running a newer version of Exchange than the Client Access server it is proxying to, the proxying Client Access server needs to have an Outlook Web App resource folder (for example, “)\ClientAccess\owa\8.0.498.0″ that contains all the same versioned resource files as the Client Access server it is proxying to. If you will be running Outlook Web App proxying with mismatched server versions, you can manually copy this resource folder to the proxying Client Access server. After you copy this resource folder to the proxying Client Access server, you need to restart IIS before proxying will work.

To resolve this issue you simply follow the instructions in the error. Copy the OWA resource files from a down-version Client Access server over to the Exchange 2010 CAS, and then restart IIS on the Exchange 2010 CAS.

You’ll find the folder name matching the server version (eg 8.3.83.4 above) in the location where Exchange is installed, for example C:\Program Files\Microsoft\Exchange Server\ClientAccess\OWA.

After copying the files run IISReset from a command prompt.

[PS] C:\Windows\system32>iisreset

Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted

Outlook Web App should now work successfully for all users regardless of which site their mailbox is located.

Get more Exchange Server tips at ExchangeServerPro.com

500 Internal Server Error for Exchange 2007 Outlook Web Access

Paul Cunningham — Fri, 05 Aug 2011 11:36:52 +0000

In an Exchange Server 2007 environment you may encounter the following error when users attempt to access Outlook Web Access.

500 – Internal server error.

There is a problem with the resource you are looking for, and it cannot be displayed.

The error occurs when user access OWA via the /exchange path but not the /owa. For example:

https://mail.company.net/owa (gets no error)
https://mail.company.net/exchange (gets the 500 internal error)

This can occur when the Exchange 2007 Mailbox server is missing the Web-ISAPI-Ext feature. You can check this by logging on to the server and running this command:

C:\>servermanagercmd -q | findstr "Web-ISAPI-Ext"
            [ ] ISAPI Extensions  [Web-ISAPI-Ext]

If there is no check mark next to the feature then it will need to be installed by running the following command:

C:\>servermanagercmd -i web-isapi-ext
..

Start Installation...

[Installation] Succeeded: .
[Installation] Succeeded: [Web Server (IIS)] Application Development.
[Installation] Succeeded: [Web Server (IIS)] ISAPI Extensions.

Success: Installation succeeded.

When you check the status of the feature it will now show as installed.

C:\>servermanagercmd -q | findstr "Web-ISAPI-Ext"
            [X] ISAPI Extensions  [Web-ISAPI-Ext]

That should resolve the “500 internal error” when accessing OWA via the /exchange path.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server 2010 Error: Outlook Web App Didn’t Initialize

Paul Cunningham — Thu, 12 May 2011 13:27:33 +0000

When connecting to Outlook Web App (OWA) for Exchange Server 2010 users may report the following error in their web browser.

Outlook Web App didn’t initialize. If the problem continues, please contact your helpdesk.
Couldn’t find a base theme (folder name=base)

This can be caused by missing OWA theme files in \ClientAccess\Owa\14.1.287.0\themes sub-folder of the Exchange 2010 installation path. By default this is C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\14.1.287.0\themes.

To resolve the error you can perform a restore of the files to the Client Access server from a previous backup.

If that is not available to you then you can also restore the files by re-running Exchange Server 2010 SP1 setup in upgrade mode.

C:\Admin\Exchange2010SP1>setup /m:upgrade

Welcome to Microsoft Exchange Server 2010 Unattended Setup

Preparing Exchange Setup

    Copying Setup Files                           COMPLETED

The following server roles will be upgraded
Languages
Hub Transport Role
Client Access Role
Management Tools

Performing Microsoft Exchange Server Prerequisite Check

    Configuring Prerequisites                                 COMPLETED
    Language Pack Checks                                      COMPLETED
    Hub Transport Role Checks                                 COMPLETED
    Client Access Role Checks                                 COMPLETED

Configuring Microsoft Exchange Server

    Language Files                                            COMPLETED
    Restoring Services                                        COMPLETED
    Languages                                                 COMPLETED
    Hub Transport Server Role                                 COMPLETED
    Client Access Server Role                                 COMPLETED
    Exchange Management Tools                                 COMPLETED
    Finalizing Setup                                          COMPLETED

The Microsoft Exchange Server setup operation completed successfully.

You should now see the restored files in the correct location, and OWA will begin working again.

Get more Exchange Server tips at ExchangeServerPro.com

How to Publish Outlook Web App with ISA Server 2006

Paul Cunningham — Sun, 03 Apr 2011 13:11:17 +0000

One way to make Exchange Server 2010 Outlook Web App (OWA) available for remote users is to publish it using ISA Server 2006. There are several parts of this solution that make it work.

A public DNS name for Outlook Web App (in this example mail.exchangeserverpro.net is used)
An ISA Server 2006 (with Service Pack 1) firewall configured with an external interface and IP address corresponding to the above DNS record
An SSL certificate for Exchange Server 2010
Exchange 2010 Client Access and Mailbox servers deployed in the organization

This diagram provides an overview of how Outlook Web App is published using ISA Server 2006. The remote user makes a connection over HTTPS (SSL) to the ISA firewall, which then reverse proxies the traffic over SSL to the Client Access server. The Client Access server is then responsible for proxying the requests for the user’s mailbox to the appropriate Mailbox server using RPC connections.

Configuring the Exchange 2010 Client Access Server

In this example the /OWA virtual directory on the Client Access server is configured for both Basic and Integrated authentication. This combination allows internal, domain-joined computers to seamlessly log on to Outlook Web App while also permitting the ISA server to use Basic delegation to authenticate the remote user.

For more details see this article on how to configure Outlook Web App authentication.

The Client Access server /OWA virtual directory has also been configured with the external URL to match the public DNS name.

The Client Access server also needs to be configured with an SSL certificate. Preferably this SSL certificate is from a public certificate authority but it can also be a private CA, as long as it is one that the ISA server trusts so that ISA considers the certificate to be valid. You can of course import root certificates to make just about any certificate trusted by ISA but it is less effort and a better overall solution to use a public CA.

Configuring the ISA Server SSL Certificate

The ISA server needs to be configured with an SSL certificate to accept the secure remote access connections. Although you can issue the server with its own certificate for this purpose you could also export the SSL certificate from the Client Access server and import it to the ISA server, provided that the license terms your issuing CA allow for that. Digicert is an example of a CA that allows certificates to be installed on multiple servers.

For more details see this article on exporting an SSL certificate from Exchange 2010 (note that it refers to importing it for Exchange 2003 but the steps are the same for importing to an ISA Server 2006 firewall running on Windows Server 2003).

Configuring the ISA Server Publishing Rule for Outlook Web App

In the ISA Server Management console right-click the Firewall Policy and choose New -> Exchange Web Client Access Publishing Rule.

Give the new rule a name and click Next to continue.

Set the Exchange version to Exchange Server 2007 (yes this is correct for Exchange 2010 publishing) and tick the box for Outlook Web Access, then click Next to continue.

In this case a single server is being published. Click Next to continue.

Enter the internal site name for OWA (in this case mail.exchangeserverpro.net), and optionally enter a computer name or IP address for ISA to connect to if the internal site name does not resolve in the internal DNS zone. Click Next to continue.

Configure the public names that this rule should accept connections for and click Next to continue.

Now we need to configure a web listener to accept the remote user connections. Click on the New button.

Give the new web listener a name and click Next to continue.

Leave the default choice to require SSL and click Next to continue.

Select the External interface for the web listener to listen on. If your External interface has multiple IP addresses you can configure the web listener to listen on all, some, or just one of those IP addresses. Click Next to continue.

Click on the Select Certificates button.

A list of valid certificates will appear, which should include the one you imported to the server earlier. Choose that certificate and click the Select button, then click Next to continue.

Leave the authentication set to HTML Form Authentication and Windows (Active Directory). Note this assumes your ISA server is joined to the domain, otherwise you can configure LDAP authentication. Click Next to continue.

Single Sign-On is useful but optional. Click Next to continue.

Click Finish to complete the new web listener wizard. If there are no warnings or errors displayed click Next to continue.

Leave the authentication delegation set to Basic Authentication and click Next to continue.

Leave the users set to All Authenticated Users and click Next to continue.

Before you click Finish to create the new rule first click on the Test Rule button to validate the settings you chose.

If the tests are all successful click on Close and then Finish to create the rule.

Before applying the changes to the Firewall Policy double-click the new rule to open its properties. Select the Paths tab and then click Add.

Add the Exchange Control Panel virtual directory path of /ecp/* and then click OK and OK again.

Now click Apply to commit the changes to the Firewall Policy.

Testing the ISA Server 2006 Publishing Rule for Outlook Web App

Now that the rule has been configured we can test it from outside of the firewall using a web browser. When the remote user first connects to the Outlook Web App URL they will see the Exchange 2007 style log on form that ISA 2006 renders.

However after logging in the Exchange Server 2010 Outlook Web App interface will be available to the remote user.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange 2010 OWA Legacy URL Redirection HTTP 500 Error

Paul Cunningham — Wed, 05 Jan 2011 13:40:10 +0000

During the co-existence period of a transition from Exchange Server 2003 to Exchange Server 2010 you may encounter an issue with the legacy Outlook Web Access URL redirection.

When users connect to the Exchange 2010 Client Access server for OWA login they receive a second login prompt for the legacy URL.

Authentication prompt when accessing OWA legacy URL

No matter which credentials are entered into this authentication dialog box the login is not successful, and a HTTP 500 error is displayed.

HTTP 500 error accessing OWA legacy URL

The solution is to enable forms-based authentication on the Exchange 2003 front-end server. This is located in the Properties of the Exchange Virtual Server.

Open the Properties of the Exchange Virtual Server

In the Settings tab enable forms-based authentication and click OK to apply the change.

Enabling Forms-Based Authentication for Exchange 2003

Exchange will warn you that SSL must be configured and IIS restarted if you are not offloading SSL elsewhere, or have not already configured it in IIS. Click OK to close the warning (and obviously if you have not already got SSL offloaded or configured then you should go ahead and do that).

Exchange 2003 warning about SSL configuration for forms-based authentication

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server 2010 Outlook Web App Authentication Settings

Paul Cunningham — Sun, 19 Sep 2010 13:12:09 +0000

Outlook Web App (OWA) is the webmail interface for Exchange Server 2010. Most of you will already be familiar with the acronym OWA from previous versions of Exchange Server where webmail was named Outlook Web Access.

Outlook Web App is hosted on the Client Access Server role for Exchange Server 2010 and integrated with IIS 7. The OWA URL is typically something like this:

https://webmail.mycompany.com/owa

To connect to Outlook Web App users must authenticate first. The OWA virtual directory can be secured using different authentication settings depending on the network environment.

Exchange Server 2010 Outlook Web App Authentication Types

There are four authentication methods available for Exchange Server 2010 OWA. They are:

Integrated Authentication – this allows domain users who are logged on to domain computers to automatically logon to Outlook Web App. This is useful for internal Outlook Web App access as it simplifies the logon process for domain users (they don’t need to logon once to the computer and then a second time for OWA). However Integrated Authentication is not suitable for remote access by people using non-domain member computers, or people who are connecting via proxy servers.

Basic Authentication – this uses the HTTP protocol to send the logon credentials to the server. Because the credentials are sent “in the clear” the use of SSL is highly recommended for securing them. Also, because Basic Authentication credentials can be cached in web browsers it is recommended to use an additional authentication factor (eg a one-time password from a token) to prevent unauthorized access from public kiosk computers using the cached credentials.

Logon dialog box for Outlook Web App using Basic Authentication

Digest Authentication – this method solves the problem with Basic Authentication where credentials are sent “in the clear” by sending a hashed password instead. Digest Authentication also works through a proxy server unlike Integrated Authentication. However Digest Authentication does have some other configuration requirements, such as the use of reversible encryption for password storage in Active Directory. These may make it an undesirable option for many organiztions.

Forms-Based Authentication – this method uses a sign-in webpage on the server to collect logon credentials. as with Basic Authentication the use of SSL with Forms-Based Authentication is highly recommended to protect the user credentials.

The Exchange Server 2010 OWA Logon Page

Forms-Based Authentication has three additional configuration options for how the user credentials are submitted.

Domain\Username – users enter their credentials in the format Domain\Username, using either the NETBIOS or FQDN for the domain name.
User Principal Name (UPN) – if this option is chosen only users who have a UPN specified that matches their email address will be able to logon to Outlook Web App.

[PS] C:\>Get-Mailbox "alan reid" | fl name, userprincipalname, primarysmtpaddress

Name               : Alan.Reid
UserPrincipalName  : Alan.Reid@exchangeserverpro.local
PrimarySmtpAddress : Alan.Reid@exchangeserverpro.local

Username Only – with this option the Exchange administrator specifies a default domain for OWA logons, and users in that domain can logon with username only. Users in other domains must still use Domain\Username.

Configuring Outlook Web App for Integrated Authentication

In this example the Exchange Server 2010 OWA virtual directory is being configured for Integrated Authentication.

Using the Exchange Management Console navigate to Server Configuration -> Client Access, and choose the server you wish to configure. Select the Outlook Web App tab, then right-click the OWA virtual directory and choose Properties.

Configuring an Exchange Server 2010 OWA Virtual Directory

Select the Authentication tab. Choose Use one or more Standard Authentication Methods and tick the Integrated Windows Authentication box.

Enabling Integrated Authentication for Exchange Server 2010 OWA

Click OK to apply the change.

To perform the same configuration using the Exchange Management Shell run this command.

[PS] C:\>Set-OwaVirtualDirectory "EX3\owa (Default Web Site)" -BasicAuthentication $false -WindowsAuthentication $true -DigestAuthentication $false

You will notice that three settings were specified in the command. This is because Basic, Integrated, and Digest Authentication can be enabled concurrently so that the OWA virtual directory supports multiple authentication methods. Because of this you should explicitly configure the authentication methods the way that you intend them to be set, rather than modifying only a single authentication method.

Configuring Outlook Web App for Forms-Based Authentication

In this example the Exchange Server 2010 OWA virtual directory is being configured for Forms-Based Authentication.

Configuring an Exchange Server 2010 OWA Virtual Directory

Select the Authentication tab. Choose Use forms-based authentication and then choose a logon format, in this example User name only.

Configuring Forms-Based Authentication for Exchange Server 2010 OWA

Click OK to apply the change.

To perform the same configuration using the Exchange Management Shell run the following command.

[PS] C:\>Set-OwaVirtualDirectory "EX3\owa (Default Web Site)" -FormsAuthentication $true -LogonFormat UserName -DefaultDomain exchangeserverpro.local

Other Steps When Changing Outlook Web App Authentication Settings

You will notice as you modify OWA virtual directory authentication settings that two additional steps are usually required:

Resetting IIS – this is required any time you switch to or from Forms-Based Authentication. From a command prompt window run the following command:

iisreset /noforce

Modifying the ECP virtual directory – ECP stands for Exchange Control Panel and is the self-service web portal for end users to make changes to their mailbox, distribution lists they manage, and some other items. The authentication method for this virtual directory should be configured to match the OWA virtual directory.

Get more Exchange Server tips at ExchangeServerPro.com

SSL Certificate Trust Errors for New Thawte Certificates

Paul Cunningham — Fri, 27 Aug 2010 09:00:46 +0000

If you renew a Thawte SSL certificate or purchase a new one since 26th July 2010 you may encounter SSL certificate trust errors when clients connect to published websites such as Outlook Web Access.

Web browsers will return an error such as:

The security certificate issued by this website was not issued by a trusted certificate authority

On inspection of the certificate being issued by the website you may see this error:

The issuer of this certificate could not be found

This can be confusing for people who assume that any certificate issued by a commercial CA such as Thawte will be trusted by devices and web browsers that people are connecting from, especially when it occurs after renewing an existing Thawte SSL certificate.

Thawte has published the reason for this:

On June 27 2010, in the interest of better security, thawte signed all certificates with a primary and secondary intermediate that need to be installed along with the SSL certificate. Any certificate issued on or after this date requires the primary and secondary intermediate to be installed.

The new certificates are issued by an intermediate CA known as “Thawte SSL CA”. This CA is not automatically trusted by most web browsers. Thawte provides instructions for installing the correct certificates on the web server or ISA Server that is publishing the website.

Take note of the final steps, the change may not take effect until IIS or ISA Server are restarted.

If your site still have the chaining error, restart the IIS service. If the problem continues, the whole server needs a reboot to use the new roots.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server 2010 OWA Support Browser Matrix

Paul Cunningham — Fri, 09 Apr 2010 02:04:11 +0000

Microsoft’s Outlook Web App help site has the list of web browsers on different OS platforms that support the full Outlook Web App feature set.

To use the complete set of features available in Outlook Web App and the Web management interface, you can use the following browsers on a computer running Windows XP, Windows 2003, Windows Vista, or Windows 7:

Internet Explorer 7 and later versions.

Firefox 3.0.1 and later versions.

Chrome 3.0.195.27 and later versions.

On a computer running Max OS X, you can use:

Safari 3.1 and later versions.

Firefox 3.0.1 and later versions.

On a computer running Linux, you can use:

Firefox 3.0.1 and later versions.

If you use a Web browser that doesn’t support the full feature set, Outlook Web App will open in the light version.

The light version is primarily designed for accessibility for the visually impaired. However with its stripped down interface and limited features it is also useful when on slow connections and has the broadest browser compatiblity of the two versions.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Remote Connectivity Analyzer Updated

Paul Cunningham — Tue, 20 Oct 2009 00:08:29 +0000

Microsoft has released an update to the useful Exchange Remote Connectivity Analyzer. Announced by the MS Exchange Server Team today, the update includes:

New CAPTCHA interface
New tests for Exchange Web Services (useful for testing Entourage for Mac clients) and Outbound SMTP
Updates for Exchange 2010 Outlook Web Access
Password confirmation to reduce test failures from password typos
Removal of the “Beta” label

The tool also has a slick new interface. Check out the differences between the old site and the new site.

Old Exchange Remote Connectivity Test Interface

New Exchange Remote Connectivity Test Interface

Check out the Exchange Remote Connectivity Analyzer Tool.

Get more Exchange Server tips at ExchangeServerPro.com

Publish Exchange Server 2007 OWA Using ISA Server 2006

Paul Cunningham — Mon, 31 Aug 2009 08:30:27 +0000

Before we begin we must first use the same procedure used for migrating the SSL certificate from Exchange Server 2003 to Exchange Server 2007 to also migrate the certificate to the ISA Server 2006 firewall. Once an SSL certificate has been configured on the ISA server we can continue with the publishing rules for Outlook Web Access.

Open the ISA Server Management console and navigate to /Firewall Policy.

Click on Publish Exchange Web Client Access in the Tasks pane on the right side of the ISA Server Management Console.

Enter a meaningful name for the new publishing rule such as “Exchange Remote Access”. Click Next to continue.

Select the Exchange version Exchange Server 2007 and tick the Outlook Web Access box. Click Next to continue.

Choose Publish a single Web site or load balancer. Click Next to continue.

Choose Use SSL to connect to the published Web server or server farm as this is the most secure option. Click Next to continue.

Enter the FQDN of the Client Access Server. If for any reason your ISA Server is not able to resolve this name you should also tick the box and enter a name or IP that ISA can use to connect to the server. Click Next to continue.

Enter the Public Name of the server. This should match the name on the SSL certificate you imported on the Exchange and ISA servers, the External URL setting on the OWA virtual directory for the Exchange Client Access Server configuration, and the external DNS name that your clients use to connect to Exchange remote access. Click Next to continue.

Click New to create a new web listener for Exchange Remote Access.

Give the listener a meaningful name such as “ExchangeSSL”. Click Next to continue.

Choose Require SSL secured connections with clients. Click Next to continue.

Select the External network to listen for incoming web requests. If you have more than one external IP address you must click Select IP Addresses and specify which IP address bound to the External network to listen on. Click Next to continue.

Click Select Certificate and choose the SSL certificate you imported on the ISA Server firewall. Click Select and then click Next to continue.

Leave the authentication settings set to HTML Form Authentication with Windows (Active Directory). Click Next to continue.

Clear the Enable SSO check box. Click Next to continue.

Click Finish to complete the New Web Listener wizard. Select the web listener you have just created and click Next to continue.

Choose Basic Authentication for authentication delegation. Click Next to continue.

Note: Delegation using Basic authentication allows a single SSL certificate, public IP address, and ISA publishing rule to be used for all Exchange remote access methods (eg Outlook Web Access and Outlook Anywhere). In environments with multiple public IP addresses and a requirement to delegate Outlook Anywhere authentication using Kerberos/NTLM then Negotiate(Kerberos/NTLM) would be chosen.

Leave the users set to Authenticated Users. Click Next to continue.

Click Finish to complete the Publishing Rule wizard.

Right click the newly created rule and choose Properties.

Navigate to the Paths tab. Click the Add button to add more paths to the publishing rule for ActiveSync, AutoDiscover, and Outlook Anywhere.

Note: If you are planning to publish these services on separate IP addresses and SSL certificates you would not perform these steps.

Add the following paths:

/rpc/*
/Microsoft-Server-ActiveSync/*
/AutoDiscover/*

Click OK when you have added each of the paths to the rule.

Apply the ISA rule changes.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server Pro » OWA

OWA Error: The Mailbox You’re Trying to Access Isn’t Currently Available

Related posts:

500 Internal Server Error for Exchange 2007 Outlook Web Access

Related posts:

Exchange Server 2010 Error: Outlook Web App Didn’t Initialize

Related posts:

How to Publish Outlook Web App with ISA Server 2006

Configuring the Exchange 2010 Client Access Server

Configuring the ISA Server SSL Certificate

Configuring the ISA Server Publishing Rule for Outlook Web App

Testing the ISA Server 2006 Publishing Rule for Outlook Web App

Related posts:

Exchange 2010 OWA Legacy URL Redirection HTTP 500 Error

Related posts:

Exchange Server 2010 Outlook Web App Authentication Settings

Exchange Server 2010 Outlook Web App Authentication Types

Configuring Outlook Web App for Integrated Authentication

Configuring Outlook Web App for Forms-Based Authentication

Other Steps When Changing Outlook Web App Authentication Settings

Related posts:

SSL Certificate Trust Errors for New Thawte Certificates

Related posts:

Exchange Server 2010 OWA Support Browser Matrix

Related posts:

Exchange Remote Connectivity Analyzer Updated

Related posts:

Publish Exchange Server 2007 OWA Using ISA Server 2006

Related posts: