I completed my Exchange 2013 to 2016 on-premise upgrade recently. I was installing one last component on a mail server for Nintex workflows which allow SharePoint to automatically generate email accounts for new employees. It required the installation of .Net 2.0. No big deal other than the path to source files and required reboot. After configuring a new app pool and URL for Nintex, I noticed OWA had stopped working for users on that server. The event log displayed the error:
Log Name: Application
Source: ASP.NET 2.0.50727.0
Date: 7/20/2016 9:17:37 AM
Event ID: 1310
Task Category: Web Event
Event code: 3008 Event message: A configuration error has occurred. Event time: 7/20/2016 9:17:37 AM Event time (UTC): 7/20/2016 2:17:37 PM Event ID: 5feea16bb6e64349967b7d8396f6821a Event sequence: 1 Event occurrence: 1 Event detail code: 0 Application information: Application domain: /LM/W3SVC/1/ROOT/owa-39-131134978579008397 Trust level: Full Application Virtual Path: /owa Application Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\ Machine name: [omitted] Process information: Process ID: 15100 Process name: w3wp.exe Account name: NT AUTHORITY\SYSTEM Exception information: Exception type: ConfigurationErrorsException Exception message: Unrecognized attribute ‘maxUrlLength’. Note that attribute names are case-sensitive. (C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\web.config line 85) Request information: Request URL: https://localhost:443/owa/ Request path: /owa/ User host address: 127.0.0.1 User: Is authenticated: False Authentication Type: Thread account name: NT AUTHORITY\SYSTEM Thread information: Thread ID: 10 Thread account name: NT AUTHORITY\SYSTEM Is impersonating
I didn’t notice it right away, but after digging around I found that OWA was suddenly using .Net 2.0 and that’s why it didn’t recognize all of the attributes. So my fix was to open IIS management, right-click Application Pools, right-click MSExchangeOWAAppPool and go to Basic Settings, and choose .Net 4.0 from the drop-down for .Net CLR Version.
Not sure why it reverted, but since I didn’t find this solution anywhere on the web I’m just throwing it out there. Other than that, I haven’t hit any snags with Exchange 2016. Changing the organization to use MAPI was the only major change and we had no issues with Outlook clients.