How to Recreate IIS Virtual Directories (ECP, OWA) on Exchange Server

6.8K

Client applications connect to the Exchange Server using virtual directories published through the IIS web server. Users may experience various problems when accessing Exchange services if these virtual directories are missing, damaged, or misconfigured. Resetting IIS virtual directories (including OWA and ECP) can resolve many issues with on-premises Exchange Server 2019/2016/2013 connectivity.Exchange Server Virtual Directories Overview. Keep in mind that recreating virtual directories may require IIS restarts and temporarily interrupt client connectivity.

Note. This guide applies to Exchange Server 2016/2019, but modern deployments may also include Exchange Server Subscription Edition (SE). In these scenarios, hybrid connectivity, OAuth authentication, and TLS enforcement are default considerations. Also, you should always ensure the server is running the latest supported Cumulative Update (CU) and Security Update (SU) before attempting virtual directory recovery.

Important. Note that in modern Exchange Server (2016/2019/SE) virtual directory recreation is a last-resort recovery method. You should resolve most of the configuration problems using Set-*VirtualDirectory cmdlets.

What Are Exchange IIS Virtual Directories?

Exchange virtual directories are used to access web applications: Outlook Web App (OWA), Exchange ActiveSync, Autodiscover, Exchange Control Panel (ECP), EWS, MAPI, Offline Address Book (OAB), etc.

You can view a list of Exchange virtual directories by using the Internet Information Services Manager console (Inetmgr.exe).

Modern Exchange authentication and hybrid context

Nowadays on-premises Exchange environments (Exchange Server 2016/2019 and Exchange Server SE) are often deployed in hybrid configs with Microsoft 365. In such environments, authentication and client connectivity may rely on modern authentication (OAuth 2.0) instead of legacy Basic Authentication.

Keep in mind that virtual folder recreation may also affect:

• OAuth endpoints used by Hybrid Modern Authentication (HMA)
• Outlook connectivity in hybrid tenants
• Exchange Online–on-premises integration cases

Before modifying virtual directories, you should check if the environment uses hybrid config or modern authentication (because incorrect recreation can temporarily break OAuth-based authentication flows).

Note that Exchange environments may use different authentication models depending on config:

• Legacy Basic Authentication (supported mainly for compatibility with older on-premises clients and devices). Note that Basic Authentication has been removed from Exchange Online. References in this article apply only to on-premises Exchange deployments.
• Modern Authentication (OAuth 2.0, recommended)
• Hybrid Modern Authentication (HMA) for Microsoft 365 integrations

Virtual directory changes have different impact depending on the authentication model you are using.

Note that in Exchange Server Subscription Edition (SE), modern authentication and TLS enforcement are expected defaults. Keep in mind that legacy authentication scenarios are increasingly unsupported/disabled by default.

Default Web Site vs Exchange Back End

There are two built-in IIS sites that are created during the Exchange installation:

• Default Web Site
• Exchange Back End

Exchange virtual directories

There are multiple Exchange virtual directories on each of these IIS sites (depending on Exchange roles installed on the server).

Exchange service	Virtual Directory Name	IIS Directory Name	URL
Exchange Control Panel	ecp	EcpVirtualDirectory	https://EX.theitbros.loc/ecp
Outlook Web App	owa	OwaVirtualDirectory	https://EX.theitbros.loc/owa
MAPI over HTTP	mapi	MapiVirtualDirectory	https://EX.theitbros.loc/mapi
Exchange ActiveSync	Microsoft-Server-ActiveSync	ActiveSyncVirtualDirectory	https://EX.theitbros.loc/Microsoft-Server-ActiveSync
AutoDiscover	AutodiscoverVirtualDirectory	Autodiscover	https://EX.theitbros.loc/Autodiscover/Autodiscover.xml
Offline Address Book	OAB	OABVirtualDirectory	https://EX.theitbros.loc/OAB
PowerShell	PowerShell	PowerShellVirtualDirectory	https://EX.theitbros.loc/powershell
Exchange Web Services	WebServicesVirtualDirectory	EWS	https://EX.theitbros.loc/EWS/Exchange.asmx

Recreate Virtual Directories on Exchange Server Using PowerShell

Note that  when you are modifying/recreating virtual directories in hybrid Exchange deployments, you may break authentication flows between Exchange Server and Microsoft 365. You need to ensure that Hybrid Configuration Wizard (HCW) settings and OAuth trust relationships are validated after changes.

It may be useful to recreate the virtual directories of the Exchange Server in the following cases:

• Incorrect operation of OWA/ECP
• Blank screen problems
• Web page errors (including HTTP 404, 500, ECP runtime)
• Outlook connectivity problem
• Permission problems
• Missing files

Recommended approach (for Exchange 2016/2019/SE)

In most cases, you can’t resolve virtual directory problems by recreation. Instead, you should use Set-*VirtualDirectory cmdlets to correctly config without removing objects. For example:

Set-OwaVirtualDirectory -Identity "ex2016\owa (Default Web Site)" `
-InternalUrl https://mail.contoso.local/owa `
-ExternalUrl https://mail.contoso.local/owa

The most common problems are with the ECP and OWA virtual directories, so we will now look at how to recreate these directories using PowerShell.

General Steps to Reset IIS Virtual Directories

Note that Exchange environments require TLS 1.2 or higher for all client communication. After recreating virtual directories, you should verify SSL bindings, certificate assignments, and TLS config (these settings may impact OWA, ECP, and MAPI connectivity).

The process of recreating any of the specified Exchange directories using PowerShell consists of three steps:

Preferred approach (modern Exchange 2016/2019/SE)

• You should use Get-XXXVirtualDirectory to inspect config
• Use Set-XXXVirtualDirectory in order to correct URLs/auth settings
• Restart IIS only in case it’s needed

Only in case the directory is corrupted in AD/IIS metadata, you should use the following:

• Remove-XXXVirtualDirectory
• New-XXXVirtualDirectory

Note that removing/New virtual directory creation is a break-glass recovery operation and you should use it only when:

• AD config is corrupted
• IIS metabase is inconsistent with Exchange config
• Set-* cmdlets fail to apply changes

Extended Protection and Exchange Security Hardening

Note that in modern Exchange Server environments you should use the latest Security Updates (SU) together with Extended Protection enabled in IIS.

After major Exchange vulnerabilities such as ProxyShell and ProxyNotShell, Microsoft recommends enabling Extended Protection and maintaining current Security Update levels in order to harden Exchange against authentication relay and token abuse attacks.

Keep in mind that recreating IIS virtual directories may affect:

• Extended Protection settings
• IIS authentication bindings
• Channel Binding Token (CBT) config
• SSL/TLS requirements
• Authentication compatibility with load balancers/reverse proxies

Before recreating/modifying Exchange virtual directories, you should verify the current Exchange config, authentication settings, and client connectivity config. This will help you to identify existing security hardening settings and reduces the risk of breaking hybrid authentication/Outlook connectivity after changes:

Get-ExchangeServer | Format-List Name,AdminDisplayVersion
Get-OrganizationConfig | Select-Object OAuth2ClientProfileEnabled
Get-MapiVirtualDirectory | Select-Object Identity,IISAuthenticationMethods
Get-OutlookAnywhere | Select-Object Identity,ExternalHostname,InternalHostname

If Extended Protection is enabled in the organization, you should verify if recreated virtual directories still comply with the existing IIS and Exchange hardening config.

Important. Before enabling/validating Extended Protection, you need to ensure that load balancers, SSL offloading devices, and reverse proxies support the required authentication and channel binding scenarios.

We also recommend you to validate the Exchange Server health state using the Microsoft Exchange Health Checker script before and after virtual folder recreation.

If the Exchange server participates in a load-balanced/DAG environment, you should validate health probes, namespace configuration, and client access routing after recreating virtual directories.

Default Authentication Methods

The following table lists the default IIS authentication methods that are enabled by default for various Exchange virtual directories:

Virtual directory	IIS Default Authentication methods
OWA	Anonymous authenticationWindows authentication
ECP
Autodiscover
EWS
MAPIowa\Calendar	Anonymous authentication
Microsoft-Server-ActiveSync	Basic authentication (legacy; we recommend you to use modern authentication methods where supported)
OAB	Windows authentication
PowerShell

Important. Note that Basic Authentication is considered a legacy authentication method in modern Exchange environments. Although, you can still use it some on-premises Exchange Server deployments for compatibility with older devices and apps, we recommend you to minimize/disable Basic Authentication wherever possible and use Modern Authentication (OAuth 2.0) instead.

Keep in mind that some legacy mobile devices, scripts, monitoring tools, and third-party mail clients may still depend on Basic Authentication.

After you performed the changes, you need to validate Exchange services. You can do that using the following commands:

• Test-OutlookWebServices
• Test-WebServicesConnectivity
• Test-EcpConnectivity
• Test-ActiveSyncConnectivity

Also don’t forget to validate:

• Get-AuthConfig
• Test-OAuthConnectivity (hybrid cases)
• Test-MAPIConnectivity

In addition to Exchange connectivity tests, you should also check if the published virtual directory URLs are accessible and return the expected responses. For example:

Invoke-WebRequest https://mail.contoso.local/owa
Invoke-WebRequest https://mail.contoso.local/ecp

You should also check that the correct Exchange certificate is assigned and has not expired. Certificate-related issues are a common cause of OWA, ECP, EWS, and ActiveSync connectivity problems after virtual directory recovery:

Get-ExchangeCertificate |
Select-Object Thumbprint, Services, NotAfter

You should also validate access from a web browser and verify:

• SSL certificate presentation;
• HTTP response status codes;
• Authentication prompts and sign-in pages;
• Load balancer or reverse proxy behavior (if applicable).

Note that many post-recreation issues are related to IIS bindings, certificates, authentication settings, or reverse proxy config rather than the virtual directory objects themselves.

Doing this, you should ensure that virtual directory recreation has not impacted client connectivity.

Resetting Specific Exchange Virtual Directories

Recreate OWA Virtual Directory

OWA (Outlook Web Access) is a virtual directory that implements a client web interface for accessing a user’s mailbox. You can reset its settings using the Exchange Management Shell (EMS).

In case your environment uses Modern Authentication (OAuth), you need to keep in mind that recreating OWA/ECP virtual directories may temporarily disrupt authentication flows (especially for Outlook on the web and Exchange Admin Center access in hybrid deployments).

Standard config method (recommended)

In modern Exchange, you should update OWA config using Set-OwaVirtualDirectory:

Set-OwaVirtualDirectory -Identity "ex2016\owa (Default Web Site)" `
-InternalUrl "https://mail.contoso.local/owa" `
-ExternalUrl "https://mail.contoso.local/owa"

Open the EMS console as administrator and list the OWA directories in the Exchange organization:

Get-OwaVirtualDirectory

We are going to repair the owa (Default Web Site) virtual directory on the server named EX2016.

List the current OWA virtual directory settings (note the configured ExternalURL, InternalURL, and authentication settings):

Get-OwaVirtualDirectory "ex2016\owa (Default Web Site)"|select-object InternalUrl, ExternalUrl, BasicAuthentication,WindowsAuthentication,DigestAuthentication, FormsAuthentication

Note. Change ex2016 to the name of your Exchange Server.

Before removing any virtual directory, you need to export its current config for rollback purposes:

Get-OwaVirtualDirectory |
Export-Clixml C:\Temp\OWA-VDir.xml

Delete the OWA virtual directory on the server ex2016:

Remove-OwaVirtualDirectory "ex2016\owa (Default Web Site)"

Create a new OWA directory:

New-OwaVirtualDirectory `
-Server "ex2016" `
-Name "owa" `
-InternalUrl "https://mail.contoso.local/owa" `
-ExternalUrl "https://mail.contoso.local/owa"

Note that explicitly specifying the -Name parameter is optional and may vary depending on Exchange version and existing IIS config.

In some cases, it is also recommended to recreate OWA on the Exchange Back End site:

Remove-OwaVirtualDirectory "ex2016\owa (Exchange back end)"

New-OwaVirtualDirectory `
-Server "ex2016" `
-Name "owa" `
-WebSiteName "Exchange Back End" `
-InternalUrl "https://mail.contoso.local/owa" `
-ExternalUrl "https://mail.contoso.local/owa"

Recreate ECP Virtual Directory

In the same way, you can reset the settings and create the ECP virtual directory.

Standard config method  (recommended)

Instead of recreating the virtual directory, you should use Set-EcpVirtualDirectory:

Set-EcpVirtualDirectory -Identity "ex2016\ecp (Default Web Site)" `
-InternalUrl "https://mail.contoso.local/ecp" `
-ExternalUrl "https://mail.contoso.local/ecp"

ECP virtual directory used to manage Exchange through the Exchange Admin Center web interface.

List ECP virtual directories:

Get-ECPVirtualDirectory

Get the current ECP virtual directory settings (note the configured ExternalURL, InternalURL, and authentication settings):

Get-EcpVirtualDirectory "ex2016\ecp (Default Web Site)"|select-object InternalUrl, ExternalUrl, BasicAuthentication,WindowsAuthentication,DigestAuthentication, FormsAuthentication

Delete and recreate the ECP directory (using the previous setting you listed above):

Remove-EcpVirtualDirectory -Identity "ex2016\ecp (Default Web Site)"

New-EcpVirtualDirectory `
-Server "ex2016" `
-InternalUrl "https://mail.contoso.local/ecp" `
-ExternalUrl "https://mail.contoso.local/ecp"

Then recreate ECP on the Exchange Back End site:

Remove-EcpVirtualDirectory -Identity "ex2016\ecp (Exchange Back End)"

New-EcpVirtualDirectory `
-Server "ex2016" `
-WebSiteName "Exchange Back End" `
-InternalUrl "https://mail.contoso.local/ecp" `
-ExternalUrl "https://mail.contoso.local/ecp"

Recreate Exchange ActiveSync Virtual Directory

Standard config method

In most cases, to recreate ActiveSync virtual directoryyou should use Set-ActiveSyncVirtualDirectory instead of recreation. For example:

Set-ActiveSyncVirtualDirectory -Identity "ex2016\Microsoft-Server-ActiveSync (Default Web Site)" `
-InternalUrl "https://mail.contoso.local/Microsoft-Server-ActiveSync" `
-ExternalUrl "https://mail.contoso.local/Microsoft-Server-ActiveSync"

Recreate ActiveSync virtual directory using PowerShell:

Get-ActiveSyncVirtualDirectory -Server ex2016

Remove-ActiveSyncVirtualDirectory -Identity "ex2016\Microsoft-Server-ActiveSync (Default Web Site)"

New-ActiveSyncVirtualDirectory -Server "ex2016" -InternalUrl "https://mail.contoso.local/Microsoft-Server-ActiveSync" -ExternalUrl "https://mail.contoso.local/Microsoft-Server-ActiveSync"

Recreate Autodiscover Virtual Directory

Autodiscover is a critical component for both on-premises and Exchange Online clients in hybrid environments. Keep in mind that changes to Autodiscover virtual directories may affect Outlook profile config and Hybrid Modern Authentication routing.

Standard config method

Where possible, you should perform Autodiscover virtual directory changes with Set-AutodiscoverVirtualDirectory. For example:

Set-AutodiscoverVirtualDirectory -Identity "ex2016\Autodiscover (Default Web Site)" `
-BasicAuthentication $true `
-WindowsAuthentication $true

Note that Autodiscover problems are often not related to virtual directory config, but to:

• SCP (Service Connection Point)
• DNS records
• Hybrid redirect rules

You can recreate Autodiscover virtual directory using the commands:

Get-AutodiscoverVirtualDirectory -Server ex2016

Remove-AutodiscoverVirtualDirectory -Identity "ex2016\Autodiscover (Default Web Site)"

New-AutodiscoverVirtualDirectory -Server "ex2016" -BasicAuthentication $true -WindowsAuthentication $true

Set-ClientAccessServer -Identity "ex2016" -AutodiscoverServiceInternalUri https://autodiscover.contoso.local/Autodiscover/Autodiscover.xml

Recreate Exchange Web Services (EWS) Virtual Directory

Standard config method

Set-WebServicesVirtualDirectory -Identity "ex2016\EWS (Default Web Site)" `
-InternalUrl "https://mail.contoso.local/EWS/Exchange.asmx" `
-ExternalUrl "https://mail.contoso.local/EWS/Exchange.asmx"

You can recreate the Exchange Web Services (EWS) virtual directory using the following PowerShell commands:

Get-WebServicesVirtualDirectory -Server ex2016

Remove-WebServicesVirtualDirectory -Identity "ex2016\EWS (Default Web Site)" -Confirm:$True

New-WebServicesVirtualDirectory -Server "ex2016" -InternalUrl "https://mail.contoso.local/EWS/Exchange.asmx" -ExternalUrl "https://mail.contoso.local/EWS/Exchange.asmx"

Recreate MAPI Virtual Directory

Standard config method

Note that you should use Set-MapiVirtualDirectory for config changes instead of recreating the directory:

Set-MapiVirtualDirectory -Identity "ex2016\mapi (Default Web Site)" `
-InternalUrl https://mail.contoso.local/mapi `
-ExternalUrl https://mail.contoso.local/mapi

You can recreate the MAPI virtual directory using the following PowerShell commands:

Get-MapiVirtualDirectory -Server ex2016

Remove-MapiVirtualDirectory -Identity "ex2016\mapi (Default Web Site)"

New-MapiVirtualDirectory -Server "ex2016" -InternalUrl https://mail.contoso.local/mapi -ExternalUrl https://mail.contoso.local/mapi -IISAuthenticationMethods Ntlm, OAuth, Negotiate

Note that OAuth authentication is controlled by Exchange organization-level config and AAD trust (not only by IIS virtual directory settings).

Recreate Offline Address Book (OAB) Virtual Directory

Standard config method

Set-OabVirtualDirectory -Identity "ex2016\OAB (Default Web Site)" `
-InternalUrl "https://mail.contoso.local/OAB" `
-ExternalUrl "https://mail.contoso.local/OAB"

Recreate OAB virtual directory:

Get-OABVirtualDirectory -Server ex2016

Remove-OabVirtualDirectory -Identity "ex2016\OAB (Default Web Site)"

New-OabVirtualDirectory -Server "ex2016" -InternalUrl "https://mail.contoso.local/OAB" -ExternalUrl "https://mail.contoso.local/OAB"

Note. We recommend explicitly specifying the -Server parameter when creating Exchange virtual directories. Although Exchange can often determine the local server automatically from the current EMS session, using -Server makes scripts more predictable and avoids ambiguity in multi-server Exchange environments.

Recreate PowerShell Virtual Directory

Standard config method

Note that you should not recreate PowerShell virtual directory unless it is broken. To do this, use Set-PowerShellVirtualDirectory:

Set-PowerShellVirtualDirectory -Identity "ex2016\PowerShell (Default Web Site)" `
-InternalUrl https://mail.contoso.local/PowerShell `
-ExternalUrl https://mail.contoso.local/PowerShell

Recreate powershell virtual directory using the commands:

Get-PowerShellVirtualDirectory -Server ex2016

Remove-PowerShellVirtualDirectory -Identity "ex2016\PowerShell (Default Web Site)"

New-PowerShellVirtualDirectory `
-Server "ex2016" `
-Name PowerShell `
-InternalUrl "https://mail.contoso.local/PowerShell" `
-ExternalUrl "https://mail.contoso.local/PowerShell"

Restart IIS or reboot the Exchange Server host.

Important. Note that in modern Exchange Server deployments, you should use HTTPS/TLS-secured PowerShell virtual directories. We don’t recommend you disabling SSL requirements (except for temporary troubleshooting/highly specific legacy compatibility cases).

Reset OWA Virtual Directory from Exchange Control Panel (ECP)

You can also perform some Exchange virtual directory resets from the ECP web interface. In the case of OWA:

1. Sign in Exchange Control Panel (using the link https://yourexchange/ECP);
2. Go to Server > Virtual directories;
3. Select the owa (default Web Site) directory and click the Reset button;

   

4. You will be prompted for a file name to save the current OWA virtual directory settings.
   When you reset “owa (default Web Site)” virtual directory, the current settings will be lost. The current virtual directory will be deleted and then re-created with the default settings.
   

   

5. Click Reset;
6. Then restart IIS with the command (note that IIS reset temporarily interrupts Exchange web services connectivity for connected users; you should perform this operation during a maintenance window whenever possible):
   

   iisreset /force

7. After restarting IIS, you should verify that the core IIS services are running correctly before testing Exchange connectivity:
   

   Get-Service W3SVC,WAS

8. Manually set InternalUrl and ExternalUrl for OWA.

Check that all the Exchange virtual directories that you re-created are now displayed in the EAC console.

After recreating any Exchange virtual directory, you should always verify:

• SSL certificate bindings in IIS
• TLS protocol config (we recommend TLS 1.2 or higher)
• Authentication method compatibility (Basic vs OAuth)
• External load balancer/reverse proxy settings (if applicable)

Keep in mind that in case of misalignment in these components, you can face OWA/ECP access failures even if virtual directories are correctly recreated.

An Error Occurred While Creating the IIS Virtual Directory

In some cases, you might receive an error when you use the New-XXXVirtualDirectory cmdlet to create a virtual directory in Exchange:

An error occurred while creating the IIS virtual directory `IIS://Exch2016/W3SVC/1/ROOT/ECP’

Or:

The AD configuration for virtual directory ‘owa’ already exists in ‘CN=xxx’ , please remove this AD configuration manually.

IIS vs Active Directory Metadata Conflict

This error occurs because the IIS metabase contains a record of the virtual directory, that prevents the New-XXXVirtualDirectory cmdlet from creating a new directory (where XXX is the name of the directory: ECP, OWA, etc.).

This is because Exchange stores virtual directories in two locations::

• Active Directory
• IIS

The Get-XXXVirtualDirectory cmdlet gets information from AD, and not from the IIS configuration.

The Remove-XXXVirtualDirectory cmdlet removes the Exchange virtual directory from AD.

Using ADSI Edit to Remove Virtual Directory Entries

Note that ADSI Edit should only be used when Exchange cmdlets cannot remove stale virtual directory objects from AD.

Run the ADSI Edit tool and connect to your domain configuration. Go to the following directory configuration partition: CN=Configuration > CN=Services > CN= Microsoft Exchange > CN=YourExchangeName > CN=Administrative Groups > CN=Exchange Administrative Groups > CN=Servers > CN=YourExchangeServerName > CN=Protocols > CN=HTTP. Find the virtual directory you want to recreate in this partition.

If the directory is removed from IIS but remains in AD, you must first remove the directory from AD using the Remove-XXXVirtualDirectory cmdlet.

Hint. Do not use IIS Manager to manually delete Exchange Server virtual directories unless you are sure that the metadata for them is not stored in Active Directory.