Hi

I have a native IIS module which creates an impersonation token for a user.  The module is configured against owa (Default Web Site) and ecp (Defualt Web Site) and works, as designed, no problems.

I remove the native module via a custom powershell script, which backs out any references to the schema and entries in applicationHost.config.

However, when I navigate to https://myexchangeserver/owa or https://myexchangeserver/ecp both sites completely fail to load, giving an error of unable to find Microsoft.Exchange.Client.Strings assembly.  I have successfully removed and created the owa and ecp virtual directories using the Exchange powershell scripts, but this made no difference to the owa and ecp site displaying.

Any ideas as to what Exchange owa and ecp files might be affected by removing a module??

Thanks, Craig

Hi

Try the steps on this thread

http://social.technet.microsoft.com/Forums/exchange/en-US/d25a4c1b-4931-4bcb-8028-3004a82c040d/microsoftexchangeclientsstrings

1. Get the file Microsoft.Exchange.Clients.Strings.dll on the following location:  C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\Bin
2. Then copy that file to the folder C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\ecp

Cheers

If you have any feedback on our support, please click here

Thanks for the reply.

We used the web.config.bak file to recover the owa and ecp web sites, however this file (for Exchange 2013) is completely bogus!  There are environment variables referenced in this file that don't exist.  TO NOT USE THE web.config.bak file!!

Given that I was testing the IIS native module, in the end, I rebuilt the Exchange server and updated a script to ensure the configuration entries that get applied from IIS are removed when the IIS feature is removed.

Craig

So the issue is resolved by rebuilding?

Yeah, we quickly rebuilt a new domain controller and Exchange virtual machine, loaded in a couple of users and set the configuration in Exchange for OAW and ECP to Windows; this took less than an hour.

We put on Windows Server 2013 shadow copy feature which keeps the updates that get made during configuration.

We weren't able to pin point what the exact cause was, only the resulting error, but we did determine that using web.config.bak in the FrontEnd folder for owa and ecp will cause those Exchange web applications to be inoperable.