I had been having problems with the client access server and noticed that mail wasn't synchronizing to my smartphone....
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
I tried to open OWA to access my messages, but this only brought up an HTTP 500 internal server error message. After some digging, I discovered that I had a corrupted IIS metabase.
Fixing a corrupt IIS metabase is easy. I opened the Exchange Management Shell (EMS) and deleted the corrupt virtual directories using the following commands:
Remove-OwaVirtualDirectory “Exchange (default web site)”
Remove-OwaVirtualDirectory “Public (default web site)”
Remove-OwaVirtualDirectory “exchweb (default web site)”
Remove-OwaVirtualDirectory “owa (default web site)”
Remove-ActiveSyncVirtualDirectory –Identity “
After removing the corrupt virtual directories, I uninstalled the client access server role and then uninstalled IIS from the server entirely. Once these were gone, I reinstalled IIS and the client access server role. This recreated the IIS metabase and all of the virtual directories.
The final step was to re-associate my server’s SSL certificate with IIS. If I skipped this step, OWA would have worked with certificate warnings, but ActiveSync would not have worked.
Fixing a mailbox permissions error
These steps restored ActiveSync and OWA to a functional state; however, both stopped working again a few days later. When I tried to log into OWA, it displayed a message stating, “You do not have permission to open this mailbox.” I searched for ActiveSync-related errors in the CAS event logs and found a series of Access Denied messages.
Knowing that my account wasn’t corrupt and that I did have permission to access my mailbox, I decided to reboot the CAS. Then I logged into OWA, which opened but didn’t display the sign-in screen. Instead, OWA displayed the following error message:440 Login Timeout.
This meant that my problem was due to a permissions-related issue. However, I was slightly confused why, since none of the permissions had changed.
I did discover that the IUSR_servername and the IWAM_servername accounts had been deleted. IIS uses these accounts to provide anonymous access to Web content. Although OWA and ActiveSync both require authentication, OWA displays the sign-in screen before any authentication occurs. Therefore, it’s critical that CAS support anonymous access to at least some portion of Exchange-related virtual directories.
If the IUSR_servername or IWAM_servername accounts have been deleted, recreating the accounts and resetting the passwords would fix the problem. And although you can create the accounts as you regularly would, you must use the following procedure to reset the passwords:
- Open a command prompt window and enter the Notepad adsutil.vbs command.
- When Notepad opens, search for the text:
If (Attribute = True) then
IsSecureProperty = True
- Set the IsSecure Property = True line to equal False and save your changes.
- Enter the commands:
Cscript adsutil.vbs get w3svc1\anonymouspass
Cscript adsutil.vbs get w3svc1\wamuserpass
The first command will return a string that reflects the value of the password that the IUSR_servername account used previously. The second command will return the previous IWAM_servername account password. Copy both passwords and reset the passwords for both accounts so that they match the ones you just looked up. You don’t need to reset any passwords within the Service Control Manager.
If you don’t correctly apply permissions to the IIS virtual directory structure, these commands may return an error message. If this happens, use the following commands to retrieve the passwords:
Cscript adsutil.vbs get w3svc\anonymouspass
Cscript adsutil.vbs get w3svc\wamuserpass
If these commands return the passwords but the initial commands you used did not, then you’ll need to reset the IUSR_servername and IWAM_servername passwords using the steps above. Next, fix the IIS virtual directory permissions by resetting the permissions, opening a command prompt window and entering:
Cscript adsutil.vbs delete w3svc/1/ROOT/anonymoususerpass
Once the reset is complete, enter:
Cscript adsutil.vbs find w3svc/anonymoususerpass
The anonymoususerpass property should be set at W3SCV, but not at w3svc/1/ROOT.
Revert to the IIS Manager , navigate to the Default website and click on your OWA container. Right-click on the 8.x.xxx.xx container and select Properties.
Next, go to the Directory Security tab and click Edit. Enable Anonymous Access and clear any check boxes designating authenticated access. Click OK twice and then repeat the process for the AUTH container.
The final -- and most important -- step is to reset the script that you modified earlier. Open a command prompt window and enter the following command:
When Notepad opens, search for the following text:
If (Attribute = True) then
IsSecureProperty = False
Set the IsSecureProperty = False line equal to True and save your changes.
Note: Don’t run the Setup with the /M:RecoverServer switch if the configuration information is damaged; this process won’t work.
ABOUT THE AUTHOR
Brien M. Posey, MCSE, is a seven-time Microsoft MVP for his work with Windows 2000 Server, Exchange Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. For more information visit www.brienposey.com.