🔄Scenario Description

Consider the following scenario in Exchange 2013/2016/2019 environment. While trying to view properties of virtual directories in EAC you get an error message “An iis directory entry couldn’t be created. The error message is access denied. HResult = -2147024891”

Let’s look at couple of issues with similar symptomatic, troubleshooting steps and different root cause.

🔄Valuable questions for troubleshooting

When we troubleshoot any issue, we should get as much information as possible to understand where this issue relies. That can give you an answer, or at least give an idea for further troubleshooting steps.

Where is this issue reproduced?  Can we reproduce this issue with powershell? For which servers we get error above? Can we get more extended error description?  – That’s what I would ask myself to troubleshoot this kind of issues.

In our example scenario we will imagine some fictitious Contoso organization with two Exchange servers, called EX-TR1 and EX-TR2. So, we could say that issue is reproduced on TR-EX2 when we’re trying to view virtual directory settings in EAC or perform get-*directory cmdlets for server TR-EX1.

Usually, I’m happy to exclude EAC and reproduce errors with powershell. Because, I don’t use EAC, really 😊 But not just because of that.

• In most cases EAC is something “on top” of Powershell. That means, it make troubleshooting easier if you exclude additional layer
• EAC is really relied on proxying – you should always remember, that your session is proxied to backed server where your mailbox is located
• Powershell output usually provide more information and opportunities for troubleshooting

Running Get-OWAVirtualDirectory -Server TR-EX1  from EMS, connected to TR-EX2:

Other questions I usually ask to verify:

1. Can we reproduce this issue on TR-EX1? No, EMS connected to TR-EX1 works fine
2. Can we reproduce this issue on TR-EX2 from regular powershell with Microsoft.Exchange.Management.PowerShell.SnapIn loaded (i.e. exclude remote powershell). No, it works fine.

Also, MSExchange Management log can be checked for extended events. In fact, when you do something in the Exchange admin center (EAC), the Exchange Control Panel (ECP), it’s the Exchange Management Shell that does the work behind the scenes.

This output is shorted for visibility. The most important information is highlighted.

🔄Where information about virtual directories is stored?

1. In Active Directory’s Configuration partition. Virtual Directories can be viewed via ADSIEDIT.

2. In IIS metabase. Virtual Directories can be viewed with IIS Metabase Explorer which is a part of IIS (6.0) Resource Kit:

Access denied error can be related to Active Directory or Metabase, but according to our error, it’s clear enough that we’re dealing with second option. Also, it looks like we are using some DCOM calls.  

Also, we could double check that by running Get-OwaVirtualDirectory -Server tr-ex1 –ADPropertiesOnly

That also works OK as it doesn’t try to get information from IIS metabase.

🔍What next?

So, we don’t see anything related to this issue in System or Application logs. As for me it looked like more a platform issue, not pure Exchange one.

As I don’t troubleshoot DCOM related issues every day, I needed to find how to enable DCOM extended  logging:

1. Open regedit and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
2. Locate the OLE registry key.
3. Create ActivationFailureLoggingLevel type of DWORD and change its value to 1
4. Create CallFailureLoggingLevel type of DWORD and change its value to 1

So, I enabled those settings on both servers and tried to reproduce the issue without restart anything.

Nothing interesting on TR-EX2. But on TR-EX1 there was event that needed some attention:

In Exchange Management Shell, if RBAC allows an action to proceed, the action is performed in the context of the Exchange Trusted Subsystem and not the user’s context.

So, the request for remote activation comes from Exchange server’s computer account. We don’t expect some specific configuration settings for single computer accounts or specific groups. So the first option is to check if TR-EX2 computer account is administrator on TR-EX1. That’s done by including Exchange Trusted Subsystem group to Local Administrators group.

This is a common scenario that can be seen on the internet. As a typical resolution it advised to verify that Exchange Trusted Subsystem group is included in local Administrator’s group on Exchange Servers but without any troubleshooting steps.

📌Another example with the same symptoms

Another case with the same main symptoms and troubleshooting steps showed DCOM error:

This issue is really good described in articles below:

🔗DCOM authentication hardening: what you need to know

🔗KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414)

Actually, this is a long running process of DCOM authentication hardening happening in stages staring from 2021.

This is applicable to Windows Server 2022, 2019, and 2016, 2012 R2.

So, if you have old Exchange servers in your organization that are not updated for some reason, and you install new freshly updated servers this is the exact issue you can potentially have.

✅Conclusion

Even if issues have similar symptomatic, the root cause can be completely different.

I hope, problem solving techniques, describes in this post will be useful for you in the future.

End.