Thursday, January 03, 2008

OWA 2007: Error 440 - Login Timeout

The other day I was facing a Outlook Web Access problem on Exchange 2007. Users could succesfully resolve the URL, but would immediately receive a message "440: Login Timeout", without further explanation not in the browser nor in the event viewer of the exchange server.

This particular exchange server was a new installation, but I've read that this also happens to exchange servers that were upgraded from 2003.

On the msmvps.com blog site, Chad has written a post that can help you with this message.
Basically, the procedure he describes lets you manually synchronize the passwords of the IUSR_ & IWAM_ between AD and IIS.
From the comments below the post it shows that many were helped with this, unfortunately for me, it didn't ...

I did however find another article on the Microsoft sites that did help me.
Below are the steps needed restore the OWA functionality on a Exchange server 2007. Please be aware that although the risk of deleting valuable information is low (since we won't touch the "Management tools", only the "Client Access Server"), the server will be fully unavailable for users during these steps.

1. Uninstall the Common Files subcomponent of the IIS (Internet Information Services), located in the Windows components of Add or remove programs.
2. Reinstall the Common Files and reapply the appropriate service packs.
3. Remove only the Client Access Role! To do this select "Remove Microsoft Exchange server 2007" under Add or remove programs.
4. Reinstall the Client Access Role. To do this select "Change Microsoft Exchange server 2007" under Add or remove programs.
5. Open the Exchange management shell and run these commands:
a) get-owavirtualdirectory -server server_name -DomainController dc_name | ? {$_.OwaVersion -eq "Exchange2003or2000"} | remove-owavirtualdirectory -DomainController dc_name
b) new-OwaVirtualDirectory -OwaVersion "Exchange2003or2000" -VirtualDirectoryType "Mailboxes" -DomainController dc_name
c) new-OwaVirtualDirectory -OwaVersion "Exchange2003or2000" -VirtualDirectoryType "Exadmin" -DomainController dc_name
d) new-OwaVirtualDirectory -OwaVersion "Exchange2003or2000" -VirtualDirectoryType "PublicFolders" -DomainController dc_name
e) new-OwaVirtualDirectory -OwaVersion "Exchange2003or2000" -VirtualDirectoryType "exchweb" -DomainController dc_name

Now run the iisreset command and OWA should work.

The full article from Microsoft you can find here.

Enjoy!

12 comments:

6d 6a 6d 63 73 68 61 6e 65 2e 63 6f 6d 20 76 2e 35 said...

Dude,
This post saved my butt. I am still having some smtp issues but nothing big.
Thanks again!
Mike

Anonymous said...

This worked for me too. Thank you!

Anonymous said...

Great article... thanks!! Saved me a whole afternoon of troubleshooting.

Now, back to my beer.

RPassero said...

BTW (for indexing purposes), if you have SP1 installed on your server, the error you will get will look like the following:

Preparing Exchange Setup

The following server roles will be installed
Client Access Role

Performing Microsoft Exchange Server Prerequisite Check

Client Access Role Checks ......................... COMPLETED

Configuring Microsoft Exchange Server


Opening package 'E:\exchangeserver.msi' failed. Another version of this pro
duct is already installed. Installation of this version cannot continue. To co
nfigure or remove the existing version of this product, use Add/Remove Programs
on the Control Panel. Error code is 1638.

The Exchange Server setup operation did not complete. Visit http://support.micro
soft.com and enter the Error ID to find more information.

Exchange Server setup encountered an error.



As I mentioned, the solution is to reinstall the server role using the SP1 setup.

Anonymous said...

This post rocked! Saved me A LOT of headaches. Thanks!

Anonymous said...

hi all: I accidentally created this OWA "440 login timeout" error accidentally in the process of troubleshooting another OWA problem.

However I was smart enough to back up the IIS metabase BEFORE starting work so I was able to back out of it. Basically my client had disabled anonymous login on the Default Web Site so his OWA wouldn't work.

On my first attempt, I enabled anonymous login on the Default Web Site. I was prompted to reset the subfolder permission like "owa" directory which I selected and clicked Yes. Then I was prompted to reset all *other* subdirectories including Exchange, Exadmin, Exweb, RPC, RPCcert, etc... which I selected YES TO ALL. That's when I got the 440 Login Timeout OWA error.

I restored the IIS configuration to it's previous state and re-applied anonymous logon permissions to the Default Web Site. Only this time I only selected the "owa" subfolder to inherit the anonymous logiin permissions (this is necessary according to Microsoft's own specifications regarding access permissions to the "owa" subfolder. However this time I DID NOT allow the the other subfolders like Exchange, ExchangeActiveSync, etc to inherit anonymous permissions.

Now OWA, Exchange ActiveSync, Outlook Anywhere and everything else works like a charm.

IIS is very picky about permissions. Always make sure you back up the IIS metabase configuration BEFORE and AFTER making any changes because it is almost impossible to know which subfolders require what permissions.

Most of the OWA, ActiveSync, Outlook Anywhere problems are due to permissions and NOT due to the IUSR, IWAM account passwords which are auto-synched by default. All the files are usually present so the only thing left to troubleshoot are the permissions, both NTFS and IIS.

Hope this helped.

Anthony Maw, Vancouver, Canada
tel: +1 604 318 9994
anthony@maw.bc.ca
www.anthonymaw.com

Anonymous said...

Thanks, I deleted the 'exchweb' folder by mistake (doh!!), which eventually WILL kill OWA. The steps here worked for me. This info can be found in a few other places, but it is presented very clearly here. Thanks a lot!

Anonymous said...

almost a year old your post and yet still very applicable - i tried to fiddle with permissions for two days or so already without any success. following your instructions took about an hour and all is working fine now... thanks!!!

Anonymous said...

For those of you who wish to save some time, it's possible to skip the removal & re-installation of IIS if you know the IIS installation is intact. In my case, I was simply dealing with messed up permissions in my virtual IIS folders.

What to do: Open the IIS Manager on the computer with IIS installed. Right-click on the local computer, select all tasks, then select Backup/Restore configuration. At this point, you'll want to create a backup. When you have done that, you'll want to perform a restore - look for something called "Initial Backup - created automatically by IIS setup." Be fore-warned that when you restore this initial backup, IIS is "blank." At this point you can proceed with the remainder of the article starting with the removal & re-installation of the Microsoft Exchange 2007 Client Access Role. If you had the RPC over HTTP Proxy component installed, you'll need to remove & reinstall this as well (Add/Remove Programs->Add/Remove Windows Components->Networking Services). This worked for me as my IIS installation wasn't corrupt, but the permissions within IIS manager were messed up. Once you have restored the IIS virtual folders, I highly recommend you make another backup of your IIS configuration at this point. It'll save a lot more time in the future if you mess up IIS permissions.

Great article, though. It was precisely what I was looking for, and I am simply passing on some of my experience. Naturally, if your IIS install is completely ruined, you will need to follow each & every step.

Anonymous said...

I am wondering if these solutions would also work on an Exchange 03 server. Has anyone been able to confirm this?

ReddLefty said...

My install was brand new and this error occured. However, I had already used the same server name. You would think I learn by now to never to use the same server name twice. There is always a security issue that coughs up somehow in the AD.... I did this procedure and it cleared up the issue. Great job.

Anonymous said...

Very useful saved my DAY