Search This Blog

Saturday 6 September 2014

ASP.NET problems with 2013 CU6 install

I recently did a fresh install of Exchange 2013 CU6 for a customer and had major issues trying to access the Exchange Admin Centre (EAC) and Outlook Web App (OWA).

The server was a brand new 2012R2 machine.  The AD forest was brand new and composed entirely of 2012R2 Domain Controllers.  Due to an issue they had they completely deleted the entire environment and recreated it.  All servers were installed from the 2012R2 ISO and all Windows Updates applied.  The following problem occurred in both the original environment and the rebuilt one.

After installation the Application Eventlog was full of event 1310 from source 4.0.30319.0.  This was logged every few seconds.  EAC/OWA was not accessible and simply returned the "Something Went Wrong :-(" error message.  The event was logged for each of the virtual directories, e.g. OWA/Autodiscover/EWS etc.  Details of the event related to "The file specified could not be found", each referring to a different module that was referenced in the web.config file related to each virtual directory, e.g. AntiXSS.

I spent over a day investigating, including the following and much,much more:
  • The DLLs referenced did in fact exist
  • Permissions on the file system matched another working system
  • ASP.Net was installed correctly
  • All Application Pools were configured correctly
  • IIS was working
I compared the web.config for each of the Virtual Directories with a CU5 server and noticed a big difference.  In CU5 at the end of the web.config there is a list of paths detailing where to find each of the DLL files referenced earlier in the web.config file.  In CU6 these paths are not present.  However, I noticed a reference to c:\program files\microsoft\exchange server\v15\clientaccess\sharedwebconfig.config.  This sharedwebconfig.config file did not exist on the two CU6 servers experiencing the problem.

After building yet another CU6 server, which worked correctly, I located the sharedwebconfig.config file.  Copying this to the broken servers and executing an IISRESET fixed the issue.

It would seem that MS have moved from repeating the same paths in every web.config to a shared model, reducing duplication of configuration items in multiple files.  For some reason, on both occasions, setup did not create this file and hence IIS didn't know where to load the modules from.

These are the lines in the web.config that references the shared web config file:

  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <linkedConfiguration href="file://C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\SharedWebConfig.config" />

And here an extract of the contents of that shared file.  I can't post the whole file due to the size.

    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <assemblyIdentity name="AntiXssLibrary" publicKeyToken="d127efab8a9c114f" culture="neutral" />
        <codeBase version="" href="file:///C:\Program Files\Microsoft\Exchange Server\V15\bin\AntiXssLibrary.dll" />
        <assemblyIdentity name="AsyncDnsManaged" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <codeBase version="1.1.5274.28150" href="file:///C:\Program Files\Microsoft\Exchange Server\V15\bin\AsyncDnsManaged.dll" />

I have no idea why the file is not created on some servers but hopefully this post will save someone from the pain and headaches that I went through.


  1. Thank you. I just had the same problem and spent a few hours looking into this.

    Fortunately there is a copy of this file in another folder. I copied the sharedwebconfig.config file from “Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy” into the ClientAccess folder and ran IISreset and I was able to login to OWA.

  2. Installed two new Exchange 2013 servers with CU9. One server had the sharedweb.config file and the other one did not. the one without the file was throwing the event id 1310, warning until I copied the file to this server and restarted IIS. In my case OWA was working and I could get to the EAC, so I'm not sure what I fixed exactly yet, but its good to see the warning gone!
    Thanks for your post!

  3. Interesting that people are still hitting this several CU releases later. I personally know of at least 10 instances of the file being missing, but none of us can figure out the commonality and why it only happens sometimes. Glad I could help any way.

  4. Many Thanks. I had the same with fresh CU9 installation.

  5. Many Thanks ,Solve my problem

  6. had the same problem disabled virusscanner and re-extracted the package in a new folder. Seems a problem if you extract the package in the same download folder...

  7. Great post thanks for sharing for more update at
    .Net Online Course

  8. Awesome, I had Microsoft rebuild the entire Ex 2013 server CU23 only to get this issue which they said wasn't supported only the rebuild, even though I argued that if CAS doesn't work nothing works as all client access is now through https, its taken me weeks to get to this solution. Thanks guys.

  9. Thanks for sharing such informative guide on .Net technology. This post gives me detailed information about the .net technology. I am working as trainer in leading IT training academy offering Dot Net Training in Chennai and i use your guide

    Dot Net Training in Chennai | Dot Net Training in anna nagar | Dot Net Training in omr | Dot Net Training in porur | Dot Net Training in tambaram | Dot Net Training in velachery