Video Screencast Help

Journal Search looks different now (gives selections of date ranges to search from)

Created: 13 Nov 2012 • Updated: 03 Dec 2012 | 6 comments
This issue has been solved. See solution.

I am the administrator of our EV9 environment, one of our admins recently went to do a journal search and noticed that the 'look' of the search page is different now.  The new 'look' is like this:

The 'Archived:' field was not there previously. When we would do a journal search it would look over the entire journal surface. Now it appears to be limited to what is in date range specified. When I change 'In Vault:' to my personal archive, the 'Archived:' field changes to "All items in the archive". We are preparing to move to EV10, but nothing has been changed that should have effected this. A couple months back we added the hotfix that would allow EV10 outlook add-in clients to connect to their EV9 vault, and I recently upgraded the SQL service pack from 2 to 3 (SQL 2005). Both of those are minor and unrelated to how this would operate (I would think!). I also recently upgraded NBU from 7 to 7.5...all of this in preparation to implement FSA.

My *guess* is that somewhere in one of the settings, something got changed and now instead of some sort of federated search across all archives, it is asking us to pick an archive to search from. I noticed that most of the dates are about 6 months apart, however there is one That is Monday, November 12, 2012 - Monday, November 12, 2012. Which makes me think this could also be some sort of index rollover funkyness? Hopefully the community will have an idea!

p.s another user claimed the browser search looks different as well, however I never use browser search so I am unable to verify.

Comments 6 CommentsJump to latest comment

Nate.D's picture

Thank you for the links, I think I figured out what happened (but I still dont understand why). When I listed the archives I have 6 in my list, the FederatedSearchMaxVolSets default is 5.

After following your links I found how to setup a webapp.ini file here:

I can get that setup and running, but my main question is why did this happen. Like, what process is happening within vault to cause it to roll over index volumes?  I checked my vault server and I see 8 index locations, all open. These are the same 8 indicies that we configured when we originally installed EV on 1/1/2010. Does this mean 6 of the 8 are full now? I also cant quite explain why one index rolled a single day:

If I was helpful in solving your issue please mark my post with a thumbs up or a solution!  Have a great day :)

AndrewB's picture

do you have discovery accelerator installed? it's far superior to the basic search options and it will automatically search across all the index volumes for you.

Andy Becker | Authorized Symantec Consultant | Trace3 | Symantec National Partner |

JesusWept3's picture

So typically what you have is Index Locations such as

I:\EV Indexes\Index1
I:\EV Indexes\Index2
I:\EV Indexes\Index3
I:\EV Indexes\Index8

Each Enterprise Vault Archive, be it an Exchange, Domino, SharePoint, File Server, SMTP, Journaling archive etc, all have an index created, which will be the archive ID....

When the Archive is first enabled, it picks any of the open Indexes that are open by Random and then creates a folder, such as

I:\EV Indexes\Index3\1087C72AC065FA3489F09C890F83F801B1110000EVSite

That folder will contain all the files that make up the users index, however a users index set can only contain so many "locations" (locations are Words, SMTP Addresses, MAPI properties etc, anything that is unique enough to be indexed)

Back around the EV6-2007 days, the default amount of Locations that could be made was 3 billion.
There was a general recommendation for Discovery Accelerator and Journal Users to make this closer to 500,000,000....then in EV8 onwards it got agreed upon that 1 billion locations is the ideal and most performant.

So when a users index becomes full it creates a roll over, and a new folder is created, randomly in any of the open indexes, it also attachest the first Item Sequence Number from that users archive in the folder

So the users indexes might look like the following

I:\EV Indexes\Index3\1087C72AC065FA3489F09C890F83F801B1110000EVSite
I:\EV Indexes\Index7\1087C72AC065FA3489F09C890F83F801B1110000EVSite_50000
I:\EV Indexes\Index5\1087C72AC065FA3489F09C890F83F801B1110000EVSite_90000

So based on the above, you assume that the first index archived 49999 items, it then reached its 1 billion "locations" and rolled over, the next index it created was in "Index7" and it starts off with the next number, _5000......then it fills up its quota after 40000 emails and rolls over again to Index5 etc

It can be quite common in large enterprises to see archives with hundreds of index roll overs.
That way when you are searching through DA it can be more efficient so it doesn't pull every single index in to memory, it just pulls what it needs.

Very much in the same way when you are going to the browser search, the reason it doesnt federate all of them is because you could end up in a situation where you are loading up 20 indexes just for one search, as efficient as it may be for an end user, it is not efficient on EV or indexing

Nate.D's picture

Thank you very much for that informative post! I double checked in those index locations and sure enough I had 5 rollovers (+ current) = 6 locations to search which was the number of archives I have a choice to search from :)

The problem with DA is we do so little searching, that I dont think it would be worth the cost/overhead to implement. In our environment we may only do one search every couple weeks, and there are only a couple users who can search the vault, so I think I may be OK to up the FederatedSearchMaxVolSets value for now.

We are upgrading from EV9 to EV10 this week does that have any changes to what we have talked about above?

We are also going to implement File System Archiving early next year, I did not realize the index locations were shared, so we may need to do some planning to accomodate all of those indicies...will we have issues searching FSA archives in this same way?

If I was helpful in solving your issue please mark my post with a thumbs up or a solution!  Have a great day :)

CareFreeX's picture

Different indexing engine is used in EV10, so you will have one addition indexvolume. All x32 indexvolumes are closed and x64 indexvolumes are created automatically when you upgrade to EV10. You can still search 32 indexvolumes or convert x32 to x64. You may end up with less roll over with x64 indexes. See link below: