Last updated: 1-Jun-2012
To download the latest version of this document and the other Enterprise Vault release notes, or to obtain Japanese or Simplified Chinese versions, see article TECH147785 on the Symantec Enterprise Support site. For the latest news about this release, including any hotfixes, subscribe to http://www.symantec.com/docs/TECH147786. |
This document describes the changes introduced in Enterprise Vault 9.0.4 (service pack 4 for Enterprise Vault 9.0).
Before installing or upgrading to Enterprise Vault 9.0.4, you must read this document and also the ReadMeFirst for Enterprise Vault 9.0. The ReadMeFirst lists current known issues and describes new features in the original release of Enterprise Vault 9.0.
For changes introduced to Enterprise Vault 9.0 by earlier service packs, see the Previous Updates document.
For the latest information on supported versions of software, see the Enterprise Vault Compatibility Charts at http://www.symantec.com/docs/TECH38537.
To obtain the changes described in this section, the Enterprise Vault 9.0.4 Outlook Add-Ins must be installed.
In some circumstances, individual Vault Cache database files could grow very large, causing slow Vault Cache performance for users.
This has been fixed. Vault Cache database files should not now grow larger than the default size of 500 MB. Note that any existing large Vault Cache database files are not automatically resized.
This issue could occur in Enterprise Vault 9.0.1/9.0.2/9.0.3.
The issue occurred if When shortcut is opened on the Exchange mailbox policy Shortcut Content tab was set to Show properties. When an Outlook 2010 user opened a shortcut, the shortcut properties were displayed as expected, but the user could not view the original item by clicking the gray banner of the opened shortcut.
This has been fixed.
This issue affected Outlook 2003/2007 users only.
If a user copied a calendar item by drag and drop, the Enterprise Vault Outlook Add-Ins caused a delay before the copy action completed.
This has been fixed. As a result of the fix, and by design, users can now always copy archived calendar items even if the Outlook advanced setting Allow shortcut copy in the Exchange desktop policy is set to its default value of Off.
In some circumstances, users could not open archived items from shortcuts in a public folder if the Outlook option In folders other than the Inbox, save replies with original message was selected. (By default, this option is not selected.)
If this issue occurred, the following error was displayed:
This item cannot be displayed.
Additional information: You may need to install additional software to view items of this type or it may only be possible to display this item from the folder that contains this item.
This has been fixed.
In Enterprise Vault 9.0.3, if you configured Enterprise Vault to use an SSL connection for the Web Access application, the Outlook Add-In could not connect to the Enterprise Vault server. As a result, Vault Cache and Virtual Vault did not work correctly because Vault Cache was not synchronized. Also, you could not open archived items.
This has been fixed.
In some circumstances, DatabaseList.ini
became corrupted and caused Vault Cache to fail. For example, this could happen when the file was locked by another process.
This has been fixed.
Vault Cache synchronization could fail due to a timeout in the conversion of a large item in Virtual Vault. The item was archived, but it remained in the To Archive folder in Virtual Vault. Subsequent items were not uploaded and also remained in the To Archive folder. On the next synchronization the item was removed from the To Archive folder, though it was still not converted or indexed, and the other items were uploaded as expected.
This has been fixed. If a conversion timeout occurs, the item is archived and remains in the To Archive folder, as before. The Enterprise Vault Outlook Add-In now uploads the subsequent items. On the next synchronization the item is removed from the To Archive folder, though it is still not converted or indexed.
Note the following:
web.config
file must be greater than the registry value ConversionTimeout to prevent the same item from being archived several times. For more information, see the ConversionTimeout section in the Registry Values guide.Occasionally, Vault Cache synchronization failed because of a missing folder property. The following error was written to the client log:
HDR:SYNC:ARC: Synchronization failed (std::exception):PSTCacheServerNewFolder being created on a folder that is missing PROP_EVSERVER_NEWFOLDER
This has been fixed.
In some circumstances, if an Enterprise Vault Outlook Add-In was installed on a Citrix server, Outlook stopped responding when the user tried to close it.
This has been fixed.
This issue occurred if an Outlook user who was not enabled for Enterprise Vault archiving (user A) had delegate access to the mailbox of a user who was enabled for archiving (user B). The issue caused the following problems for user A:
This has been fixed. User A now sees only the Search Vaults option, provided Search Vaults is enabled by the Exchange desktop policy for user B.
A new registry value has been introduced to enable user notifications for serious Vault Cache errors that require the intervention of an administrator.
To enable user notifications, set the NotificationsEnabled DWORD value to 1.
By default, NotificationsEnabled is not set. In this case, or if NotificationsEnabled is set to 0, users are not notified of Vault Cache synchronization errors.
For more information about this registry value, including its location in the registry, see the Registry Values guide.
For information about the notifications that may be displayed, see the following technical note on the Symantec Support Web site:
http://www.symantec.com/docs/TECH184772
In some circumstances, particularly in environments with elevated Internet Explorer security settings, the Enterprise Vault Outlook Add-Ins could cause Outlook 2007 to become unresponsive.
This has been fixed.
This issue affected the Outlook Add-In (not the HTTP-Only Outlook Add-In) when the Exchange desktop policy setting Shortcut Deletion on the Options tab was set to Ask User. When the user right-clicked a folder containing shortcuts and chose the Delete option on the context menu, Enterprise Vault should always have asked the user whether to delete the shortcuts only, or the shortcuts and the archived items.
However, if the focus was on a different folder when the user right-clicked, the correct prompt was not displayed. The following Outlook prompt was displayed instead:
Are you sure you want to delete the folder folder_name and move all of its contents into the Deleted Items folder?
This has been fixed.
If an Outlook user suspended Vault Cache synchronization, and then restarted Outlook and tried to resume Vault Cache synchronization, the following message was displayed:
No vaults available. Contact your Help Desk.
Also, Virtual Vault no longer appeared in the Navigation Pane after the restart.
This has been fixed.
This issue affected Enterprise Vault 9.0.1/9.0.2/9.0.3 Outlook Add-Ins on Outlook 2003/2007.
The issue occurred when a public folder that was enabled for archiving had one or more subfolders, and a user added one of the subfolders to their public folder Favorites. The user could not archive or restore items using the subfolder in public folder Favorites.
This has been fixed.
When a user replied to an Enterprise Vault shortcut in a secondary mailbox, the From field was not set to the address of the secondary mailbox. When the message was received, it appeared to have come from the primary mailbox. The same issue affected the Reply to All/Reply All and Forward actions.
This has been fixed.
This issue occurred when the following conditions applied:
In this case, subsequent attempts by user B to synchronize Vault Cache failed.
This has been fixed.
In some circumstances, Windows Search could fail repeatedly on users' computers with an Enterprise Vault Outlook Add-In installed and Vault Cache enabled.
This has been fixed.
In some circumstances, the Enterprise Vault Outlook Add-Ins allowed deletion of a delegated mailbox's protected special folders; for example, the Inbox or the Sent Items folder. This issue did not apply to Outlook 2010, and only affected special folders that contained one or more Enterprise Vault shortcuts.
This has been fixed.
The Enterprise Vault Outlook Add-Ins allowed deletion of an RSS Feeds folder if it contained one or more Enterprise Vault shortcuts. Normally, Outlook prevents the user from deleting this folder.
This has been fixed.
In certain circumstances, duplicate entries were created in the Vault Cache. If this happened, the Vault Cache synchronization failed repeatedly. The client trace log reported that a folder contained more than one message with the same SNUM or SSID.
This has been fixed.
If the local Vault Cache agents were not set to use 'Local' for 'Where The Agent Runs' in the Agent Schedule, the Vault Cache update failed.
This has been fixed. The value of 'Where The Agent Runs' is now repaired automatically, if necessary.
It was possible for Enterprise Vault to fail to delete Vault Cache temporary databases in the Enterprise Vault Domino Gateway folder. The temporary databases were left behind when users closed the Notes client while Vault Cache was synchronizing.
The resulting buildup of temporary databases could cause out-of-date Vault Cache information and in extreme cases could affect the performance of the Enterprise Vault Domino Gateway.
This has been fixed.
If you disabled Enterprise Vault archiving for Lotus Notes users, they lost the ability to search their archives, as the More > Enterprise Vault Search command was hidden.
This has been fixed.
Users whose Domino mail databases had been enabled for Internet Mail Access Protocol (IMAP) could not restore archived items. The following error message would appear when they tried to do so:
Notes error: Unknown OS error
This has been fixed.
Enterprise Vault's Exchange Journaling task wrote event ID 6469 (An exception has occurred
) to the event log in environments where auditing was enabled.
This has been fixed.
Enterprise Vault 9.0.4 introduces a new Exchange mailbox policy advanced setting, Valid Enterprise Vault server aliases. You can use this setting to specify a semi-colon separated list of the Enterprise Vault servers that are currently in operation in your environment.
During shortcut processing, Enterprise Vault does not attempt to make connections to any server that is not in this list. This prevents connection attempts to Enterprise Vault servers that no longer exist in your environment.
For more information, see the section "Valid Enterprise Vault server aliases (Exchange Archiving General setting)" in the Administrator's Guide.
Mailboxes whose names contained braces, { or }, were not archived. When this happened, the following error was written to the event log:
Event ID: 3361 Failed to determine the provisioning group for the mailbox /o=Example/ou=Exchange Administrative Group/cn=Recipients/cn=?G?Sales. |This mailbox cannot be processed until the Exchange provisioning task has processed the corresponding user's details. Ensure that a provisioning group includes this user and then run the provisioning task. |Error: The mailbox does not have an entry in the Enterprise Vault database. (0xc0040d1e)
In some circumstances, this issue also caused the Enterprise Vault mailbox archiving task to fail.
This has been fixed.
In some environments, delays occurred during journal archiving. This happened when custom filtering was enabled, and a very large number of internal SMTP domains was specified in the InternalSMTPDomains string value under the following registry key:
HKEY_LOCAL_MACHINE \SOFTWARE \KVS \Enterprise Vault \Agents
This has been fixed.
When the name of an Exchange organization was in double-byte characters, the Enterprise Vault Enable Mailbox wizard did not display the list of mailboxes, even though provisioning had been run.
This has been fixed.
The Exchange Policy Properties: Message Classes tab should produce a warning about the implications of clearing the IPM.Note* message class when this change is applied.
However, when the administrator clicked OK or Apply, the change was applied and no warning appeared.
This has been fixed.
Exchange Journal archiving did not archive messages whose SMTP address contained a backslash character (\), and the messages were moved to the Failed to Copy folder in the journal mailbox.
This has been fixed.
The Exchange Provisioning task failed to process users who had a job title that was longer than 64 characters. Errors similar to the following were reported in the event log:
Type: Error Date: 26/08/2011 Time: 06:29:52 Event: 13360 Source: Enterprise Vault Category: Directory Service User: N/A Computer: EVServer1 Description: An error was detected while accessing the Vault Database 'EnterpriseVaultDirectory' (Internal reference: .\ADODataAccess.cpp (CADODataAccess::ExecuteSQLCommand) [lines {1392,1394,1409,1441}] built Oct 6 11:22:46 2010): Description: [Microsoft][ODBC SQL Server Driver][SQL Server]String or binary data would be truncated. SQL Command: UPDATE ExchangeMailboxEntry SET ExchangeMailboxEntryId=...
This has been fixed.
This issue occurred when both of the following conditions applied:
-BaseFolderOnly $true
, which means that any subfolders should be treated as standard folders.
This issue caused Enterprise Vault to treat the subfolders as managed folders, not as standard folders.
This has been fixed.
In some circumstances, items from some mailboxes were archived despite being excluded by the applicable user archiving policies.
This happened after the archiving task encountered an item that had exceeded its maximum pending timeout, but had been secured. After the archiving task deleted the safety copy, it reverted to the default mailbox archiving policy while it processed the remainder of the mailbox, ignoring the user archiving policy that should have applied.
This has been fixed.
In some circumstances, users could not retrieve some large items archived in versions of Enterprise Vault older than version 8.0. When this happened, users saw the following error message:
Network operation did not complete in a reasonable amount of time; please retry
This has been fixed.
The Domino Provisioning task failed to process a mail-in database file if any of the following were true:
These issues have been fixed.
In some circumstances, the Domino mailbox archiving task became unresponsive and wrote the following error to the event log:
Log Name: Symantec Enterprise Vault Source: Enterprise Vault Date: 20/12/2011 8:00:36 AM Event ID: 41050 Task Category: Lotus Domino Mailbox Archiving Task Level: Error Keywords: Classic User: N/A Computer: EVSRV1.example.com Description: Task: 'Domino Mailbox Archiving Task' Unable to initialize Names and Address Book (NAB) session for Domino server: 'Failed to create Notes Session (mutex)'
This has been fixed.
When a non-English template that had been created by EVInstall.nsf
was used, it was not
possible for users to retrieve or restore archived items.
This problem was present in Enterprise Vault 9.0.1 and later.
This has been fixed.
The Domino Mailbox Archiving task would fail to create shortcuts for items in private folders if the mail databases had been enabled for either Internet Mail Access Protocol (IMAP) or folder references. When this issue arose, the following entry would appear in the event log:
Log Name: Symantec Enterprise Vault Source: Enterprise Vault Event ID: 41163 Task Category: Lotus Domino Mailbox Archiving Task Level: Error Description: There was an error processing an item in a mailbox. The task will process the item again on the next archiving run. Task: Domino Mailbox Archiving Task Error: ... You are not authorized to perform that operation
This has been fixed.
Domino archiving tasks did not use local address lookup for the local domains set in the InternalSMTPDomains registry string values below the following registry key:
HKEY_LOCAL_MACHINE \Software \KVS \Enterprise Vault \Agents \NotesDomains \NotesDomainName
Where NotesDomainName
is the name of one of the Notes domains in your environment.
This has been fixed. For more information about the NotesDomains and InternalSMTPDomains registry string values, see the Registry Values guide.
In some large environments, the Domino provisioning task took a very long time to run. This happened due to delays in the method used to identify mail-in databases.
This has been fixed.
In some circumstances, while processing some Domino views, Enterprise Vault's Domino archiving tasks could cause an NSD crash.
This has been fixed.
The Domino provisioning task failed when the Domino journaling method was set to "Send to Mail-in database".
The following events were written to the event log:
Type : Error Date : 29/03/2012 Time : 10:01:43 Event : 40966 Source : Enterprise Vault Category : Lotus Domino Mailbox Provisioning Task User : N/A Computer : SERV3.example.loc Description: A program fault has raised an exception. Exception: Unable to get journal settings from server: CN=evdg/O=example - System.ApplicationException: Missing journal database name definition at DomJournalSettings.Get(String sServerName) at DomJournalSettings..ctor(DomSession session, String sNAB) at DomNAB.GetJournalSettings(S_NAB_RECORD s)
Type : Error Date : 29/03/2012 Time : 10:01:43 Event : 41118 Source : Enterprise Vault Category : Lotus Domino Mailbox Provisioning Task User : N/A Computer : SERV3.example.loc Description: The Domino Mailbox Provisioning task 'Domino Provisioning Task for EXAMPLE' has been aborted.
This has been fixed.
Sometimes the following warning message was displayed when a user attempted to forward a message from a mail file:
Unable to record which documents have been processed by the agent. Try making a replica of the database.
This issue could affect mail files that had the ev_mail85.ntf
mail template applied.
This has been fixed.
When the principal and delegate users were in different time zones, the created date of iCalendar invitation notices could be corrupt or missing. The Domino Journaling task was unable to archive such items, and it reported error messages with the IDs 41206 and 41058 in the event log.
This has been fixed. The Domino Journaling task now archives such items.
The issue is documented in the following technical note on the Symantec Support Web site:
http://www.symantec.com/docs/TECH169575
During the retrieval of items from a source archive, Move Archive failed when it encountered an item with corrupted properties that was embedded in another item.
This has been fixed.
In the Administration Console, changes to provisioning group properties, and to the order in which provisioning groups are evaluated, generate the following on-screen message:
The change you have made to the provisioning group will take effect when the provisioning task has run.
When the site setting Retain archive transaction history for x days was changed, Enterprise Vault did not apply the new setting to existing archives.
This has been fixed. When you change this setting, it applies immediately to all archives.
Storage Expiry always processed items that were on legal hold. When a very large number of items was on legal hold, Storage Expiry could fail to complete its work within the available time.
This has been fixed.
When there were more than approximately 100,000 archives in a single vault store it was possible for Storage Delete processes to terminate with the following error:
Event ID: 8390 The EnterpriseVault DirectoryConnection object reported an error. Ran out of Memory
When this problem occurred, Storage Expiry also failed with the following error:
Event: 6606 Category: Storage Delete Failed to process all expired items in Vault Store. Not enough storage is available to complete this operation.
This has been fixed.
The Storage Expiry report incorrectly treated items that were on hold, and so not eligible for deletion, as items that failed to be deleted. This behavior resulted in incorrect totals for the following:
Total number of expired items deleted Total number of items deleted
This has been fixed.
In some circumstances, the Enterprise Storage service wrote multiple errors with ID 6720 (The specified network name is no longer available
) to the event log in a short space of time, and caused Enterprise Vault to shut down. This happened when a storage device or path was unavailable, and each Storage service thread wrote the same error.
This has been fixed. When the Storage service cannot connect to a storage device or path, it writes just one error to the event log.
Clearing backup mode from all the vault stores in a site did not trigger StorageFileWatch, which is the component of the Storage service that scans partitions to check whether or not they have been backed up.
This has been fixed.
On the Vault Store Partition Properties: Backup tab, you can change the partition scan interval using the Scan partition every value. When you set this interval to less than the 60 minute default, the new interval was not honored by storage until after the default period of 60 minutes had elapsed.
For example, if you set a scan interval of 5 minutes, 60 minutes would elapse before the scans at 5 minute intervals began.
This has been fixed.
This issue affected Domino Mailbox, Domino Journal, and File System archiving to Centera, when collections were used and the Remove Safety Copies setting was "immediately after archive". Under these conditions it was possible for Enterprise Vault to remove safety copies when the savesets were still in the staging area, before collection and transfer to the Centera.
If this situation occurred, no safety copies were available if for some reason a saveset got deleted from the staging area before collection and transfer to the Centera.
This has been fixed. Now, the safety copies are not removed before the collections are archived on the Centera. This precaution already applied to Exchange and SharePoint archiving.
In the EVSVR Operations dialog box with which you create or edit an operation file, a new option is available in the Date Range To Process area: Trust CIFS Partition Created Dates. For operations that scan CIFS partitions, selecting this option can increase the speed with which EVSVR scans the partitions. However, you must be confident that all the folders and files that you want to scan have accurate creation dates, because these dates play an important part in helping EVSVR to determine when certain, older items were archived.
.dvs
) file that Enterprise Vault 2007
or earlier has made, EVSVR uses the creation date to determine the date
of the first archived item in the file. The last-modified date of the saveset
file gives EVSVR the date of the last archived item that Enterprise Vault
has added to the file as a sharer. The creation dates of saveset files
may have changed if you have copied or moved them while restoring the partition
from backup. On the other hand, if you trust the creation dates, and they
fall outside the date range that you specify in EVSVR, then you can safely
omit the files from the scan and so run it more quickly.Some EVSVR operations scan database records rather than the files in vault store partitions. For example, this is true of the Verify operations ArchiveObjects and DatabaseLinkages. These operations ignore the Trust CIFS Partition Created Dates setting.
The version of EVSVR in Enterprise Vault 9.0.4 provides several new Repair operations with which you can recreate missing records in the vault store databases, fingerprint databases, and Directory database.
Operation | Action |
---|---|
Archives |
Combines the functions of two Repair operations: ArchivesDirectory and DatabaseReferences. In outline, the Archives operation does the following:
|
ArchivesDirectory |
Recreates any missing Archive and ArchiveFolder records in the Directory database to make it consistent with the vault store databases. To do this, the ArchivesDirectory operation does the following:
|
ArchivesVaultStore |
Recreates any missing ArchivePoint and Vault records in the vault store databases to make them consistent with the Directory database. To do this, the ArchivesVaultStore operation does the following:
|
For more information on these operations, see the "EVSVR" chapter of the Utilities guide.
Caution: The Archives and ArchivesDirectory operations can cause data loss in some circumstances. We strongly recommend that you contact Symantec Technical Support before you run these operations.
If you clustered Enterprise Vault in a Windows Server failover cluster, some FSA-related operations could create resource locks that prevented the successful failover from one cluster node to another. These operations were as follows:
FileScreenFilter.sys
, of
the System Volume Information folder on the cluster node.
[Ref 14145, E2565304, R11035, E2565306].reg
) file of the FSA-related registry entries
on the cluster node, if the .reg
file could not be written for any reason.
[Ref 13210, E2569273, R11820, E2569275]These issues have been fixed.
The FSA checkpoint mechanism is designed to process the subfolders of a partially processed target volume in alphabetical order to determine whether the previous checkpoint has been reached. Some systems do not present the list of folders in alphabetical order. A non-alphabetical list can cause FSA to reprocess some folders repeatedly during multiple archiving runs.
To fix this issue, you can set the CheckpointSort registry value to make the checkpoint mechanism sort the list of folders into alphabetical order before inspection.
For more information on using the registry value, see the entry for CheckpointSort in the "File System Archiving" chapter of the Registry Values guide.
A problem could occur if the SQL Server connection was lost during an archiving run, and a "Create shortcuts later" policy was used.
Files in the folder that the File System Archiving task was processing when the SQL Server connection was broken were incorrectly added to the list of files to be archived from the next folder, when the connection was resumed. The task therefore archived these files twice, with the second copy going to the archive associated with the other folder, and with the wrong folder path reference.
This has been fixed.
A content search failed to return any data from an archived text file, if the file had all of the following characteristics:
This has been fixed.
If a File System Archiving task was stopped before completion then when it continued it generated false warning events in the Enterprise Vault event log for volumes that it had partially processed on the previous run. The warning events had the following format:
Event ID: 40976 The file system volume \\?\UNC\server\volume has no Archive points associated. No items will be archived for this volume. See the Administrator Help for information on configuring file system volume archive points.
This has been fixed.
After a successful installation of the FSA Agent, Enterprise Vault sometimes generated an error similar to the following in the event log:
Log Name: Symantec Enterprise Vault Source: Enterprise Vault Date: 9/06/2012 12:23:17 Event ID: 8390 Task Category: File Placeholder Service Level: Error Keywords: Classic User: N/A Computer: EVSERVER1.example.com Description: The EnterpriseVault.DirectoryConnection object reported an error. The name of the directory machine cannot be blank.
This has been fixed.
When pass-through recall was enabled and a file larger than 100 MB was recalled from an EMC Centera storage device, the restored file was corrupt.
This has been fixed.
If you configured an HTTPS connection from an EMC VNX series device to Enterprise Vault for placeholder support, the placeholder creation failed with an UNKNOWN_PROTOCOL error.
This has been fixed. For updated information on how to configure HTTPS connections for FSA with Celerra/VNX servers, see "Preparing a Celerra/VNX device for FSA" in Setting up File System Archiving.
Users with permission to delete files from folders of a file server share were unable to delete the archived files, unless they had Full Control or co-owner permissions on the file server share.
This has been fixed. The archive folder permissions are now set so that a user with permissions to delete files from the original source folder share can delete any file from the archive folder.
On upgrade, the change in archive folder permissions takes place on the next occasion that the File System Archiving task synchronizes archive permissions for a file server share.
Note that if you archive files with explicit permissions, a user with permission to delete files from the folders of a file server share can now delete an archived file even if someone else created the original file with permissions to prevent deletion. However, if the user did not have permission to delete the original file, the user cannot delete its shortcut.
In some circumstances, when the logging level for archiving and report runs was set to full, the File System Archiving task would log the following error in the File System Archiving task report even though the item was successfully archived:
An item with the same key has already been added.
This has been fixed.
In some circumstances, if folders and subfolders containing placeholders were deleted from a file server, FSA ignored the Delete archived file when placeholder is deleted policy setting and failed to remove the corresponding items from the archive.
This has been fixed.
In some circumstances, placeholder creation failed for files that had the read-only attribute set even though the files were successfully archived. This affected the available disk space on the file server.
This has been fixed.
FSAUtility failed to report errors when the migration of placeholders to the destination location failed.
Logging is now enhanced for the FSAUtility –pm
option. During a placeholder migration, the console displays messages about each step of the migration.
Additionally, FSAUtility records detailed entries including errors in the DTrace logs, and in the following report file in the Enterprise Vault program folder:
Reports\FSAUtility\EV_FILESYSTEM_UTILITY_LOG_DateTime.xml
There has also been a change in the way that FSAUtility –pm
behaves if it detects that a previous migration between the same paths failed. FSAUtility still displays the following prompt, but the actions for a yes response have changed:
FSAUtility has detected a previously unsuccessful run of the placeholder migration (-pm) option from source path path1 to destination path path2. If archiving occurs on the destination path, the archived data for that path may become split across multiple archives. We recommend that you retry the placeholder migration.
To retry the placeholder migration, type 'yes' and press 'Enter'. To cancel the placeholder migration, type 'no' and press 'Enter' (yes/no)?
Previously, if you answered yes to this prompt, FSAUtility did not repeat any checks for conflicting archive points, and proceeded with the migration. Now if you answer yes, FSAUtility repeats the check for conflicting archive points. If any conflicts are found it exits with errors, without proceeding with the migration.
The FSAUtility -pm
option updated the FolderName database record
for the archive's top-level folder incorrectly when it updated the archive
folder paths. This error caused the Directory database records for the archive
paths to become inconsistent, which could result in Enterprise Vault archiving
newly archived items in different folders than the original ones.
This has been fixed.
The FSAUtility -pm
option has a new optional parameter -i,
which causes
FSAUtility to ignore errors when it attempts to move a placeholder to the
new location. Such errors include:
If you include the -i
parameter and any placeholder move errors occur,
FSAUtility logs them and continues with the remaining steps of the
migration: it moves the archive points and updates the Directory database. You can correct
any placeholder move errors after FSAUtility has finished the
migration, if you want.
If you omit the -i
parameter and any placeholder move errors occur,
FSAUtility logs them and stops when it has finished
attempting to move all the placeholders. It does not go on to move the archive
points or update the Directory database. In this case you may need to rerun
FSAUtility -pm
when you have fixed the causes of the placeholder move
failures.
We recommend that you omit the -i
parameter on the first run of a
placeholder migration. If the migration fails and the report indicates that the
failure was due only to errors in moving some placeholders, you can rerun the
command with the -i
parameter if you want to continue with the migration
despite these errors.
For more information, see the description of FSAUtility placeholder migration in the "FSAUtility" chapter of the Utilities guide.
An FSAUtility -a
command to recreate archive points sometimes failed if the
archive had a very large number of folders. The following error was logged in the
Enterprise Vault event log:
Log Name: Symantec Enterprise Vault Source: Enterprise Vault Date: 2/24/2012 4:53:57 PM Event ID: 8390 Task Category: FSAUtility Tool Level: Error Keywords: Classic User: N/A Computer: EVSERVER1.example.com Description: The EnterpriseVault.DirectoryConnection object reported an error. Not enough storage is available to complete this operation.
This has been fixed.
When an index had more than five volumes, searching the archive with a Web part or clicking Show archived versions of this document failed with the following error:
exception from HRESULT: 0xC0041C82
This has been fixed.
In some circumstances, multi-threaded NTFS to Centera migrator jobs stalled when they were close to completion. This occurred when the migrator was processing some complex savesets.
This has been fixed.
In rare circumstances, the NTFS to Centera migrator could cause Enterprise Vault storage to write the following error to the event log:
Log Name: Symantec Enterprise Vault Source: Enterprise Vault Date: 20/12/2011 12:37:28 PM Event ID: 7109 Task Category: Storage File Watch Level: Warning Keywords: Classic User: N/A Computer: evsrv1.local Description: An invalid saveset was encountered while doing watch file scan. This archive operation will be attempted to be cancelled. Following further information is available. Partition Name = Ptn6 VaultStoreEntryId = 1726C795A7ADBFD46A551E1006292EBA71210000EVSRV1 TransactionID = C0B4556D-F1F9-B88C-BFEA-D9C328FED661 Invalid Reason = File 'V:\EVStores\Ptn6\ 1DFA6N1353JSUe93GM44FLGI1QLG4169PHN83E0T92R5UTL7FFGOE' not found for SavesetIdentity = [2772]
When this happened, users could not retrieve some items from their archives.
This has been fixed.
In some circumstances, archives that contained a very large number of folders caused the Enterprise Vault Directory service to write the following error to the event log:
The EnterpriseVault.DirectoryConnection object reported an error. Ran out of memory Internal references: Error 0x8007000e CDirectoryConnectionObject::GetArchiveFoldersByArchive
Note that in the case of EVSVR operations, these errors are written to the EVSVR log file rather than to the event log.
The handling of archives that contain large numbers of folders has been improved to reduce the frequency of out-of-memory errors.
During export to a PST file, if the Export Archive wizard encountered non-fatal errors on certain legacy mail items, it treated the errors as fatal and the export failed.
This has been fixed.
This release includes the following Outside In® Technology content converters and patches from Oracle® Corporation:
Installing the Enterprise Vault API Runtime did not allow NSF migration to work.
This has been fixed.
Copyright © 2012 Symantec Corporation. All rights reserved.
Symantec, the Symantec Logo, Veritas, Enterprise Vault, Compliance Accelerator, and Discovery Accelerator are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners.
This Symantec product may contain third party software for which Symantec is required to provide attribution to the third party (“Third Party Programs”). Some of the Third Party Programs are available under open source or free software licenses. The License Agreement accompanying the Software does not alter any rights or obligations you may have under those open source or free software licenses. Please see the Third Party Software file accompanying this Symantec product for more information on the Third Party Programs.
The product described in this document is distributed under licenses restricting its use, copying, distribution, and decompilation/reverse engineering. No part of this document may be reproduced in any form by any means without prior written authorization of Symantec Corporation and its licensors, if any.
THE DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. SYMANTEC CORPORATION SHALL NOT BE LIABLE FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS DOCUMENTATION. THE INFORMATION CONTAINED IN THIS DOCUMENTATION IS SUBJECT TO CHANGE WITHOUT NOTICE.
The Licensed Software and Documentation are deemed to be commercial computer software as defined in FAR 12.212 and subject to restricted rights as defined in FAR Section 52.227-19 "Commercial Computer Software - Restricted Rights" and DFARS 227.7202, "Rights in Commercial Computer Software or Commercial Computer Software Documentation", as applicable, and any successor regulations. Any use, modification, reproduction release, performance, display or disclosure of the Licensed Software and Documentation by the U.S. Government shall be solely in accordance with the terms of this Agreement.
Symantec Corporation
350 Ellis Street
Mountain View, CA 94043