Journal Search looks different now (gives selections of date ranges to search from)
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.
So typically what you have is
So typically what you have is Index Locations such as
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
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
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