Journal Mailbox folders with Enterprise Vault
Have you ever looked inside an Exchange journal mailbox after it's been targeted with Enterprise Vault? If you have never opened your Enterprise Vault journal mailbox with Outlook, then you should! In this article I'll give a brief list of the folders that the mailbox may contain and what they mean to the health of your Enterprise Vault journaling environment. Remember that not all of these folders will be present, and even if some are it doesn't mean that you have to immediately try to change something to 'fix' a problem. The list is more for you to gain an understanding of what the folders are, and what they might mean. Above Maximum Size In the Enterprise Vault journaling policy you can configure a limit to the size of the messages that will be journal archived. Hopefully your Exchange administrators are sensible and have some sort of maximum message size in place on the Exchange environment, so you could mirror that same size in this particular policy setting, or, you could take the decision that you want the Enterprise Vault maximum to be lower. Whatever limit you set in the Enterprise Vault policy messages exceeding that limit will be placed here. A lot of items in the folder may mean you have either got the policy setting wrong, or something else is wrong in your environment causing massive messages to arrive (and be left unprocessed) I always think it is a good idea to have (sensible) limits in place. The default is as you seen in the screenshot, 250 Mb. That to me seems quite large, users shouldn't really be emailing files/messages of that size. However, if the limit is too high, or too low, you can adjust it. You can even set it to zero, which means that there is no limit whatsoever. I advise against using the 'no limit' option option however. One thing to remember here is that items above the size limit you specify will be left in the journal mailbox meaning that the mailbox grow in size. Here is the folder in the journal mailbox on my test environment: Failed Codepage xyz The appropriate code pages are needed in order to process messages with that code page. So to fix this problem you should install the correct code page, or use the default ANSI code page. After you've done that step you should move these messages back in to the Inbox to be processed by the journal task. This folder shouldn't really contain any items, so if it does, rectify the problem and then retry the messages. You can force Enterprise Vault to use the default code page by removing the entry from CodePages.txt file shown in the Enterprise Vault program folder. Failed DL Expansion If Distribution List expansion is turned on in the journaling policy (and it should be for journaling!) any distribution list expansion failures will result in the message being moved to this folder. The folder should not contain any items really, a build up of messages here might mean that Enterprise Vault is talking to a Global Catalogue server which has incomplete data. You can set the option in the policy to archive the item anyway, even though it failed distribution list expansion, but before doing so it is worth investigating why the failure is happening in the first place. Remember that if you archive the item anyway, then you're compromising in someways the integrity of the data because you can not prove who did or didn't receive that particular message. Failed External Filter This contains messages which have failed to be processed by a custom filter. A build up of messages here means that the filter might not be correct. The event log sometimes contains more information about the reason for the failure. Of course if you don't use custom filters then nothing should be in this folder. Failed to copy This is usually messages which are corrupt. You can try dragging them to your desktop and double clicking on them. If they open correctly you can try dragging them back to the journal Inbox for reprocessing. Again a big build-up of messages here isn't healthy for your environment. Failed to store This folder contains messages which cannot be archived. They may have failed because of an issue with the Storage Service. Again this folder shouldn't have any items in it, and if it does you may want to see if there is an issue with the storage service, rectify it, then drag and drop the items back to the Inbox in the journal mailbox and try them again. Invalid Journal Report This contains messages where the P1 envelope message doesn't conform to Microsoft standards. This folder should also not contain any items. In the past I've seen items in this folder when Antivirus software has modified the P1 message because of suspect content. The net result here is that these various folders should be pretty much empty all of the time in a healthy Enterprise Vault Exchange journaling environment. You can also see how it is important to check the journal mailbox regularly, as a build of messages may indicate a problem, and if nothing else is likely to mean that your journal mailbox starts to get very big, very quickly. How do you monitor your journal mailboxes? Have you ever had a build of items in any of these queues? Let me know in the comments below... Reference: Monitoring journal mailboxesRoles Based Administration with Enterprise Vault 8
Introduction I wanted to correlate all the various information about Roles Based Administration that is in the Admin Guide and technotes into an article that will make it easier for you to take advantage of this great feature. I hope you find it useful.
EV Dashboard... Monitor, manage, maintain Enterprise Vault infrastructure, users, mailboxes, archives.
EVDashboard; an ASPbased 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 EVinfrastructure; you. Use this software responsibly.How to remove an EV Server from your site
How to remove an EV Server from your site There may come a time where you want to decommission or remove an EV Server from your environment. This has come up a few times on the Forum so I decided to document the steps to help you avoid the pitfalls of not doing it correctly. Before doing anything BACKUP ALL EV DATABASES!!
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.
Best Practice Considerations for Upgrading EV6 - EV7/ EV7 - EV2007/EV2007 - EV8
Sections in this document Preface Review Product Release Notes Document your current environment Review prerequisites Install prerequisites Backup your existing environment Validate backups are good Upgrading to Enterprise Vault 7
