Introduction
I often see questions on the MSExchange.org message boards (and other places) from people asking how to fix a damaged OWA 2003 installation by resetting the OWA virtual directories back to their defaults. I therefore thought it would be a good idea to write an article providing step by step instructions on how to do so.
The Six OWA related Virtual Directories
Let’s begin by taking a look at each of the Outlook Web Access (OWA) virtual directories and see what each does. As can be seen in Figure 1 below, six virtual directories are created during a default installation of Exchange Server 2003.
Figure 1: The six OWA related Virtual Directories
In order for you to understand what the purpose of each virtual directory is, I’ve listed them in Table 1 below with a short description.
OWA Virtual Directories
Description
Exadmin
The Exadmin virtual directory is used when administering Public Folders via the Exchange System Manager.
Exchange
The Exchange virtual directory stores the mailbox root (\\.\BackOfficeStorage\domain\MBX)
Exchweb
The Exchweb virtual directory stores all graphics and other subordinate files used by Outlook Web Access. This virtual directory points directly to C:\Program Files\Exchsrvr\ExchWeb.
Microsoft-Server-ActiveSync
The Microsoft-Server-ActiveSync virtual folder (please don’t ask me why it was given this name) stores all the files used by Exchange ActiveSync (EAS). This virtual directory points directly to C:\Program Files\Exchsrvr\OMA\Sync.
OMA
The OMA virtual directory stores all files used by Outlook Mobile Access (OMA). This virtual directory points directly to C:\Program Files\Exchsrvr\OMA\Browse.
Public
The Public virtual directory stores the Public folders tree (\\.\BackOfficeStorage\domain\Public Folders).
Table 1: Description of each OWA related virtual Directory
Fixing the OWA Virtual Directories
Alright enough chit chat, you have an OWA 2003 Server where you have messed up several of the OWA virtual directories, and you want it fixed right now! What to do? Well the simplest method is to delete the virtual directories by right-clicking them in the IIS Manager, then selecting Delete in the Context menu. Perhaps some of you remember doing so in Exchange 2000 Server, then restarting the Exchange System Attendant service re-created the virtual directories automatically. But hold on a minute! Because of some design changes, this is not the case in Exchange Server 2003. Well partly that is, the recommended method is still to delete the virtual directories manually via the IIS Manager, but restarting the Exchange System Attendant Service doesn’t re-create them. Instead you need to delete the DS2MB key under the LM hive in the IIS Metabase.
Note:
DS2MB is short for Directory Service to Metabase and the purpose of this process is to transfer configuration information from Active Directory to the IIS Metabase. The configuration is stored in the IIS Metabase instead of the registry mainly for performance and scalability reasons. The DS2MB process is a one-way write from Active Directory to the IIS Metabase, which means that the Metabase never writes back to Active Directory.
This can be done either by using the Metabase Explorer tool form the IIS 6.0 Resource Kit, or by using ADSUtil which by default is located in the AdminScripts folder under Drive:\Inetpub. Lastly there’s a method which involves editing directly in the Metabase.xml file using Notepad or a similar text editor. In this article we’ll focus on how they’re reset using Metabase Explorer, to see how it’s accomplished using the two other methods, I recommend you give MS KB article 883380 a read.
Before you start deleting the virtual directories you should make a backup of the IIS Metabase. You do this by opening the IIS Manager, here you right-click the Default Web Site then select Save Configuration to a File. Now type a name in the appearing dialog box, and then click OK as shown in Figure 2 below.
Figure 2: Saving Configuration to a File
Time has come to delete each of the OWA virtual directories, so while you still have the IIS Manager open, right-click each of the six virtual directories (refer back to Table 1 to see which) one at a time then select Delete. Click Yes to the question on whether you really want to delete virtual directory as shown in Figure 3 below.
Figure 3: Confirming deletion of an OWA virtual directory
When each OWA virtual directory has been deleted you should exit the IIS Manager.
We have now come to the time where the DS2MB key is to be deleted using Metabase Explorer. To do so first install the IIS 6.0 Resource Kit, then fire up Metabase Explorer by pointing to Start > All Programs > IIS Resources > Metabase Explorer > Metabase Explorer. Now expand Server (local) > LM then right-click the DS2MB key (see Figure 4) and select Delete.
Figure 4: Deleting the DS2MB key in Metabase Explorer
Now that the DS2MB key has been deleted, click Start > Run and type Services.msc. Now drill down to and restart the Exchange System Attendant Service and voila! The six OWA virtual directories have now been re-created and configured with their default settings as can be seen in Figure 5 below.
Figure 5: The six re-created OWA Virtual Directories
Almost that is, as there’s one more little thing to do. We need to reset the access permissions to Anonymous on the ExchWeb virtual directory. In order to do so start the IIS Manager then right-click the ExchWeb virtual directory and select Properties. Now select the Directory Security tab and click Edit under Authentication and access control. Make sure the Anonymous access and Integrated Windows Authentication check boxes are enabled then click OK and Apply. If an Inheritance Overrides dialog box pops up make sure you click Select All then OK. Under Authentication and access control, click Edit then clear the Integrated Windows authentication check box again. Click OK twice and you’re done.
Now that you’re done, verify you can connect to the OWA server using a Web browser. If you’re suing or plan to use Exchange ActiveSync and/or OMA also make sure to check connectivity via a Windows Mobile or PDA. You should also make sure you secure the OWA server properly at least by using SSL (preferably with an ISA Server publishing the services). For steps on how to secure OWA 2003 using SSL, see the below three articles:
SSL Enabling OWA 2003 using your own Certificate Authority:
http://www.msexchange.org/tutorials/SSL_Enabling_OWA_2003.html
Securing Exchange Server 2003 & Outlook Web Access: Chapter 5 on MSExchange.org!:
http://www.msexchange.org/tutorials/Securing-Exchange-Server-2003-Outlook-Web-Access-Chapter5.html
SSL Enabling OWA 2003 Using a Free 3rd Party Certificate:
http://www.msexchange.org/tutorials/SSL-Enabling-OWA-2003-Using-Free-3rdParty-Certificate.html
