Troubleshooting a mailbox that will not archive in Enterprise Vault
One of the most common questions asked by Enterprise Vault administrators on the Symantec Connect forums is: “Why does this mailbox not get archived?”. There are many different reasons why the mailbox may not be archiving, and in this article we'll go through several of them.
EV Dashboard... Monitor, manage, maintain Enterprise Vault infrastructure, users, mailboxes, archives.
EV Dashboard; an ASP based IIS site which can do a lot of things to help you manage Enterprise Vault. NOTE: This software should be installed into your test environments first. By no means should you go right ahead and install it into your production systems. Only one person is responsibile for your EV infrastructure; you. Use this software responsibly.The Old and New; The Difficulties of Keeping Up To Date
IT investment into software and hardware inevitably fluctuates over time. This has been the case in recent years, with many organisations having to choose carefully what to invest money in, and what to perhaps leave behind, running an older version of some software, or on an older hardware platform.The Three Fastest Ways to Upset Your Users
We all know that there are a lot of different ways that Enterprise Vault can be configured from both the server side processing of items, to the end-user experience on users’ desktops and laptops. There has been a lot written in the past about how to configure various aspects of the product, with pro’s and con’s of different approaches.Testing Your Enterprise Vault Environment
A lot of the time people might think that testing an environment, any environment, is something that the software company itself should be doing. This to some extent, is right. And to some extent it’s wrong. In this article we’ll see five different considerations which are needed and why testing your own environment is critical to having a healthy Enterprise Vault environment.
How collections and sparse collections work
One feature of Enterprise Vault is the use of Collections, where Enterprise Vault will collect multiple items into a Collection which is a Microsoft Cabinet (CAB) file. The main use for doing this is to help with backup times. For instance if you have 1 x 10MB cab file, this will backup quicker than say 100 x 10KB files, one thing to note however, is that the CAB files are not compressed, meaning that if you extract a 10MB CAB file, it will result in 10MB of DVS Files. The reason for this is that DVS files are already highly compressed, and when you attempt to compress something that’s already compressed, it results in a bigger file. Enterprise Vault Collections are configured on the Collections tab, where you can figure when the collections run, how big the CAB files can be, and how old the items have to be before they can be collected in to a CAB file. Note that when you enable Collections, you cannot disable them. The best you can do is either make the age of the files to collect so old that nothing would get archived, or you can limit the amount of time that the collections process can run (i.e setting the start AND end time to be at 11:00AM). A word of caution on the second method though, when an item is retrieved from a CAB file, it is put in its original location and named as an ARCHDVS (or ARCHDVSSP, ARCHDVSCC etc on EV8(, those files are not automatically deleted after the user has finished reading the email. Instead, it is the Collections process itself that goes behind and deletes the ARCHDVSxx files after a certain period of time, if the collections period is set too short or has 0 seconds to run, then then archdvs files cannot be cleaned up and you will end up duplicating space unnecessarily. Where are CAB Files stored? Collections themselves are stored in different places dependent on your version of Enterprise Vault. Enterprise Vault 2007 and below: The following folder structure is used to store DVS files, and the Collections are placed in the “Day” folder. Files are stored in a yyyy\mm\dd\hh format. For example E:\Enterprise Vault Stores\Journal Vault\ptn1\2010\01\30\17\<saveset>.dvs The above would symbolize an item archived at 5pm on 30 th January 2010 The CAB files are stored in the \dd\ section..so it may look like E:\Enterprise Vault Stores\Journal Vault\ptn1\2010\01\30\Collection12345.cab In Enterprise Vault 8 however, the locations are stored in a little different format. it stores it in \yyyy\mm-dd\LETTER Example: E:\Enterprise Vault Stores\Journal Vault\2010\01-11\A\074\<saveset>.dvs The above would suggest an item is archived on 11 th January 2010. However rather than storing in an additional hour folder as it used to in EV2007, it now uses parts of the file name of the DVS. In this example we have a file name called A07465CEEC2320A040210B08E3549781.DVS, the name is based on the Transaction ID assigned to the item, it takes the first letter of the transaction ID (A) and then creates folders that use the next three numbers or letters of the transaction ID. Another example, if an item called 107DC3824ADB33CDABCE5C15B7B46BD1.DVS and it was archived on January 11 th 2010, it would be located in the following location: E:\Enterprise Vault Stores\Journal Vault\2010\01-11\1\07D On Enterprise Vault collection files are stored in the first letter of the transaction id’s location. For instance the collection file may be stored here E:\Enterprise Vault Stores\Journal Vault\2010\01-11\1\Collection12345.cab What happens when I delete an item or run storage expiry? When items are added to a CAB file, they will remain there until a process called Sparse Collections is run, which involves extracting valid savesets and then deleting the cab, those savesets are then re-collected at a later date. When an item is deleted, Enterprise Vault simply cannot delete an item with in a CAB file (this actually applies to any compressed file such as ZIP or RAR) therefor you get in to a situation where items are deleted from the Databases and indexes, but still remain in the CAB files. So what occurs is that Enterprise Vault does a look up of all the items in a CAB and determines which ones are still valid, if there is only a certain percentage of items that truly exist in the CAB file, then EV extracts all the items, and the cab file is deleted. So how does Enterprise Vault know which cab files to check? Well when a collection file is created, there are two SQL Columns populated in the Collections table. One is called RefCount and one is called TotalCount. When a Collection is first created, it takes a count of how many items are stored, and sets the refcount and totalcount to the same number, so if 100 items are stored , both refcount and totalcount will be set to 100. Then, when an item is deleted or expired from that collection, it will reduce the number of the refcount, but the totalcount will remain the same. So if 50 items are deleted that belong in that CAB file, then refcount will be set to 50, and the totalcount will remain at 100. When the Refcount hits 0, this means that none of the DVS files within that CAB file exist in the database or the indexes, thus the CAB file and all its contents can be deleted. But what happens if you have a refcount of 1 and a totalcount of 100? This 1 item that still exists in EV is stopping the other 99 items from being removed from disk and freeing up storage. So what happens is the Sparse collections process. The last items are extracted to their original location, the refcount is set to 0 and then EV deletes the CAB file. By default, Enterprise Vault will initiate the sparse collections when the refcount is 15% of the the totalcount. So if you have 100 items stored in a cab, as soon as the refcount hits 15 items or lower, it will extract and then delete the cab file. So if you every run a storage expiry, make sure you run your collections process after so that you can reclaim disk space immediately.
EV, EMC Centera and Collections
I had the opportunity to test various configuration options in EV as well as on an EMC Centera. A customer has stored the EV archive data on NTFS devices and wanted to move the data to EMC Centera. The sole reason for this exercise was verifying the expected size of data on the EMC Centera compared to NTFS.
