Exchange2013 Prompt "Unexpected error, unable to process your request" processing scheme _win server

A few days ago, the company's overseas site Exchange Sever 2013 a problem, Outlook users can connect to the Exchang server to send and receive mail, Offline address Book, ActiveSync, and so are normal, but only through the Web Access to OWA and ECP , enter the username and password, click Login to verify the user name password, start to jump to the mailbox will be clearly seen in the process of opening your mailbox, is processing ... , but in the end you will be prompted to "have an unexpected error, unable to process your request", click "Details" to see something like "x-owa-error:system.nullreferenceexception" or "X-owa-error: Microsoft.exchange.data.storage.connectionfailedtransientexception "and other words. This is the same problem either on the client or the Exchange sever itself. Another interesting issue is that the Exchange server has BJ and HK two sites, BJ all normal, the problem is only the HK site.

See the experienced partners here will first check the IIS OWA virtual directory or the mailbox database where the backend user is located. Opening Event Viewer in Exchange Server does not identify significant error logs associated with Exchange and IIS, or even other logs, such as other applications. Outlook can send and receive mail normally, so basically can eliminate mailbox problem, but still check the state of the database through Eseutil.exe-"clean shutdown", that also can eliminate the problem of the database. Next up is OWA, to check OWA log, in the "\v15\logging\owa\servertrace" of the Exchange installation directory

At Microsoft.exchange.clients.common.canary15..ctor (String logonuniquekey)

At Microsoft.Exchange.Clients.Common.Canary15Cookie.TryCreateFromHttpCookie (HttpCookie cookie, String Logonuniquekey, Canary15profile profile)

At Microsoft.Exchange.Clients.Common.Canary15Cookie.TryCreateFromHttpContext (HttpContext HttpContext, String Logonuniquekey, Canary15profile profile)

At Microsoft.Exchange.Clients.Owa2.Server.Core.OwaRequestHandler.InternalOnPostAuthorizeRequest (Object sender)

At Microsoft.Exchange.Clients.Owa2.Server.Core.OwaRequestHandler.OnPostAuthorizeRequest (Object sender, EventArgs E )

At System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute ()

At System.Web.HttpApplication.ExecuteStep (IExecutionStep step, boolean& completedsynchronously)

This process is likely to show the process of creating a connection request between the front-end CAs and the back-end mailbox of Exchange. At this point, you may be thinking of the front-end CAs and back-end mailbox network communication problems?

Since CAs and mailbox are currently two all in one roles (with Dag), CAS and mailbox communications are basically on the same server, and the network has not made any adjustments, and network problems can be largely ruled out.

The next thing you can think of is that the OWA virtual directory may be out of the question, but the problem remains when you reset the OWA virtual directory ... The ultimate killer. Find a server Reinstall a exchange2013, do not make any changes create users and databases directly, and then try to access OWA on Exchange native, there are no words ...

At this point you can determine that the problem is not caused by Exchange Server itself ....

Since it's not an exchange issue, the only thing that is associated with Exchange is the domain-controlled DC server, but the replication status of the ad site has been checked from the outset, and no obvious error has occurred.

At this time to think of having seen a friend similar problems abroad, and finally he opened a case to Microsoft, Microsoft used 3 days 15 hours to troubleshoot, and finally by modifying the ADSI Editor in the CAS attribute to solve, the whole good is also OWA can not access related. Since the issue of exchange itself cannot be ruled out, and the problem is difficult to connect with the domain control, it has not dared to try. Now that you can determine if the problem is related to DC, the solution is worth trying ...

The specific actions are as follows:

1. Because ADSI content involves the entire contents of the Active Directory, you must make a backup before you do it, first through Windows Server Backup to complete a full backup of the entire DC to prepare for the future. (here is estimated to be despised again, a big company unexpectedly does not have the consummation backup system, O (╯-╰) o)

2. Open ADSI Editor, connect to "Configure", and then find "Cn=services"--> "Cn=microsoft Exchange"--> cn=< your Exchange organization name > "-->" cn= Client Access, then right-click to select Properties, open the Property Editor window, locate the property value of the word "msexchcanarydata" on the Property Editor tab, and then empty (there may be 0-n multiple items)

Here we will copy the contents of these values again to Notepad to save, this can play a backup of the role of double, prudent operation, after all, is the production environment.

3, open the CAS server IIS Manager, click "Application Pool", find "Msexchangeowaapppool", and then click on the right window of the "recycle"

4. Restart Exchange Server

After the Exchange Server reboot is completed, the Overseas users OWA and ECP are back to normal and other Outlook features are normal. Beijing headquarters users are also all normal. The problem is finally solved!

The final problem is solved, but the cause is not really found, hope to see this article and familiar with EXCHANGE2013 's small partners to discuss ....

About Exchange2013, just over a year's time has been CU5 update, but the frustration of the Exchange2013 architecture changes make people refreshing, but also brought the n many problems, Sincerely hope that the fate of Exchange2013 not like Exchange2007 ... (╯-╰)

Solve the process of consulting a number of technical friends, because Exchange2013 is not too popular new products, small partners have not met, thank you! At the same time feel that they inadvertently become the first to eat crabs ... (╯-╰), and then the company did not buy Microsoft Technical support services, and finally want to pass the MVP channel to Microsoft to seek technical support, Zennai need 1 working days of response time, and ultimately did not use the MVP benefits ... (╯-╰)