Showing results for 
Search instead for 
Did you mean: 

Slow item recall with EV 11 OWA users.

Level 6


I've just recently upgraded a customer from EV10.0.1 to EV11 and now the OWA access seems to be very slow when opening an item. It takes about 12 - 15secs. Which is a long time when you're sitting wathcing it - it will always eventually open, but I'm trying to find out why it takes so long.

When EV10 was upgraded the EV server was also moved to a new Windows 2012 platform and had a new IP address and server name. DNS aliases were all updated and everything else works fine with the exception of the OWA. 

I'm not entirely sure how long it took prior to the server upgrade\migration but the customer says it was significantly shorter in time (perhaps <5s)

I've got some logs and dtraceand followed a couple of recommended tests - but wanted to post some log information to see if anyone can confirm where I'm seeing delays as the root cause and also suggestions on why these dalys may be experienced.

I did check the time it takes to restore an item in Archive Explorer and IMO this also seemed slower than I would have expected - not as slow as opening an item in OWA but a tad longer than I would have thought.

The OWA issues is evident with both internal and external OWA access, affects all the users and is no different with differing versions of IE.

I've the a full web.config log available if useful but just initially wanted to see if the following delay I saw is key to the issue

I've highligted a 7s delay in recieving a response from the EV Server...... Is this normal??

25/07/2014 15:17:38 [8572,1] [EVServerRequest::AddHeader] Set header: EV-OWA-2010-Extensions-Version=
25/07/2014 15:17:38 [8572,1] [EVServerRequest::CreateRequest] Making request for user: My.Domain\A.user
25/07/2014 15:17:38 [8572,1] [EVServerRequest::AddHeader] Set header: X-EVOWA-User-Encoded=5500500050002D004C00540044005C00640061006E00690065006C002E006200750063006B0069006E006700680061006D00
25/07/2014 15:17:45 [8572,1] [EVServerRequest::LogResponseHeaders] Response received from EV server:

25/07/2014 15:17:45 [8572,1] [EVServerRequest::LogResponseHeaders]   Status: 201 Basket Restoring
25/07/2014 15:17:45 [8572,1] [EVServerRequest::LogResponseHeaders]   Headers: 
25/07/2014 15:17:45 [8572,1] [EVServerRequest::LogResponseHeaders]     Content-Length: 16

Below is a section of Dtrace - with a delay around the basket deletion - so again is this normal?

There is a delay of 6s in the sequence below, but this seems to occur AFTER the basket has been successfully restored so may be a red herring......

252    15:02:02.709     [2060]    (w3wp)    <380>    EV:M    The following basket description has been successfully saved to disk:| Shopper: My.Domain\OWAUser| BasketID: 20140725150202256 |
253    15:02:02.709     [2060]    (w3wp)    <380>    EV:H    Successfully restored the following basket.| Shopper: My.Domain\OWAUser| BasketID: 20140725150202256| |
254    15:02:02.709     [2060]    (w3wp)    <380>    EV:L    The following basket has been successfully built:| Shopper: My.Domain\OWAUser| BasketID: 20140725150202256 |
255    15:02:02.709     [2060]    (w3wp)    <380>    EV:L    The following basket has been successfully built:| Shopper: My.Domain\OWAUser| BasketID: 20140725150202256 |
256    15:02:02.709     [2060]    (w3wp)    <380>    EV:H    Deleted the following basket:| |Shopper: My.Domain\OWAUser| |BasketID: 20140725150202256 |
269    15:02:08.822     [2524]    (ShoppingService)    <6624>    EV:H    Failed to find the following basket description:| Shopper: My.Domain\vaultservice| BasketID: 20140725150202256 |
270    15:02:08.822     [2524]    (ShoppingService)    <6624>    EV:L    Failed to update the restoration status of a restoring item because the basket has been deleted. |
277    15:02:12.378     [2060]    (w3wp)    <7488>    EV:L    CIndexSearch2::Reset
278    15:02:12.378     [2060]    (w3wp)    <7488>    EV:L    CIndexSearch2::FinalRelease



Any thoughts greatfully recieved - can post the entire log if necessary.

kind regards





Partner    VIP    Accredited

i just saw another thread on the forum where a slowness issue was resolved by turning off certificate revocation. not sure if it's what you're seeing but might be worth a shot.

Level 6

Thanks Andrew

Sorry for the late reply - I was just checking into your suggestion  - but I don't think that's it. The EV server does have internet access and the other symptoms such as the slow VAC opening etc aren't there.

I've gone through the logs again and have a question on the process of getting the item from the shopping basket to the 'deleted items' folder in the users mailbox. As the Exchange server and the EV server are both VM’s they share the same time which is useful in understanding the sequence of events.

I’m currently trying to undersand if the following log extracts from a recent test are significant

Below is an extract from the web.config log of when the request was received to open an archived item at 15:13:03.

25/07/2014 15:13:03 [8572,5] #############################################################

25/07/2014 15:13:03 [8572,5] Request processing started

25/07/2014 15:13:03 [8572,5] Url:

25/07/2014 15:13:03 [8572,5] Query String parameters:

25/07/2014 15:13:03 [8572,5]     ae: Item

25/07/2014 15:13:03 [8572,5]     a: Open

25/07/2014 15:13:03 [8572,5]     t: IPM.Note.EnterpriseVault.Shortcut

25/07/2014 15:13:03 [8572,5]     id: RgAAAACG2EGO+nhZRq9ycjuGzt6CBwDcr7+GHwklS6mVo74WlPiMAAABAbpwAAALPa3YhCdXSrQpA09b/sGKAAAH8mpIAAAJ


25/07/2014 15:13:03 [8572,5] [EVServerRequest::AddHeader] Set header: X-EVOWA-User-Encoded=5500500050002D004C00540044005C00640061006E00690065006C002E006200750063006B0069006E006700680061006D00

25/07/2014 15:13:08 [8572,5] [EVServerRequest::LogResponseHeaders] Response received from EV server:

25/07/2014 15:13:08 [8572,5] [EVServerRequest::LogResponseHeaders]   Status: 201 Basket Restoring

The last two lines indicate that a response was received back from the EV server at 15:13:08 (5 secs later)

Below is now the Dtrace of the same request from the EV server.

Enabled Trace options


Id    Name                                              Detail     Include Events

6   - AuthServer                                     Verbose    Yes        

96  - ShoppingService                          Verbose    Yes

108 - w3wp                                            Verbose    Yes    


1233       15:13:08.679       [2228]   (AuthServer)         <8132>  EV:L        {CClientAuthIntImpl::CancelClientIdentity:#965} Token [CUSTSRVEV3.MYDOMAIN.local =ea5124=8mXy*****], Cancel Id [33239312].

1234       15:13:08.679       [2060]   (w3wp)   <5092>  EV:M       The following basket description has been successfully saved to disk:| Shopper: MYDOMAIN\OWAUser| BasketID: 20140725151304359 |

1235       15:13:08.679       [2060]   (w3wp)   <5092>  EV:H        Successfully restored the following basket.| Shopper: MYDOMAIN\OWAUser| BasketID: 20140725151304359| |

The last line here shows the basket as being Successfully restored??

This is about the same time as the Web.config log showed the “Response received from EV server”

However back to the Web.config log – I can see the first check for the item in the deleted items shows the item count is 0 (end of the below extract)

25/07/2014 15:13:08 [8572,5] [EVServerRequest::LogResponseHeaders] Response received from EV server:

25/07/2014 15:13:08 [8572,5] [EVServerRequest::LogResponseHeaders]   Status: 201 Basket Restoring

25/07/2014 15:13:08 [8572,5] [EVServerRequest::LogResponseHeaders]   Headers:

25/07/2014 15:13:08 [8572,5] [EVServerRequest::LogResponseHeaders]     Content-Length: 16

25/07/2014 15:13:08 [8572,5] [EVServerRequest::LogResponseHeaders]     Cache-Control: private

25/07/2014 15:13:08 [8572,5] [EVServerRequest::LogResponseHeaders]     Content-Type: text/html

25/07/2014 15:13:08 [8572,5] [EVServerRequest::LogResponseHeaders]     Date: Fri, 25 Jul 2014 14:13:08 GMT

25/07/2014 15:13:10 [8572,5] [EWSBase::GetRestoredItemId] Item count: 0


This is 2 seconds after the EV server had logged the basket as being restored?

The Web.config then proceeds to check for another 4 times (at 2 second intervals before it shows the item count = 1


25/07/2014 15:13:18 [8572,5] EwsResponse:

<Trace Tag="EwsResponse" Tid="5" Time="2014-07-25 14:13:18Z" Version="14.01.0218.002">

  <?xml version="1.0" encoding="utf-8"?>

25/07/2014 15:13:18 [8572,5] [EWSBase::GetRestoredItemId] Item count: 1

25/07/2014 15:13:18 [8572,5] [RequestProcessor::RestoreAndActOnItem] Item has been restored

25/07/2014 15:13:18 [8572,5] [Id::OwaId] Converting EwsId to OwaId


So not until 15:13:18 seconds does the user get to see the item  - a wait time of 15 seconds from the initial request.

But my questions are

 – the ev server seems to the basket restored in the first 5 secs yet it doesn’t appear to be in the deleted items for a further 10 secs after this. Does this indiciate a delay somewhere in the Exchange processing?

Are there any other logs that might help to narrow this down further.

To be honest I’m not actually looking for a fix, just opinions as to if these logs indicate an issue or ‘just how it is’….. I can log a support call with Symantec to get their view but thought I’d try a few guru’s first.


Kind regards