Discovery Accelerator 10.4 client failing after upgrade
First had the issue with installing, but go around that following the command line install method here. https://www-secure.symantec.com/connect/forums/accelerator-install-requires-uac-be-turned Once that is done, the client installs without issue. However, once the client is started - it sees the instance it needs to talk to, but upon attempting to connect it fails and closes out the client. This error is seen in the application log. Faulting application name: AcceleratorClient.exe, version: 10.0.4.1060, time stamp: 0x51d5b819 Faulting module name: KERNELBASE.dll, version: 6.1.7601.18409, time stamp: 0x53159a86 Exception code: 0xe053534f Fault offset: 0x0000c42d Faulting process id: 0x%9 Faulting application start time: 0x%10 Faulting application path: %11 Faulting module path: %12 Report Id: %13 That points to this document http://www.symantec.com/business/support/index?page=content&id=TECH214055&profileURL=https%3A%2F%2Fsymaccount-profile.symantec.com%2FSSO%2Findex.jsp%3FssoID%3D1427732213471AVKTeZLwnn27Lme8MkQbNYgnG25OIJPIh4DEt However, 3 installs and even turning of UAC later I'm still at the same place. Any help?Solved2.1KViews0likes11Comments
Plans to upgrade Enterprise Vault from 9 (32bit) to 10 (64-bit)
We are currently running EV and DA in the following configuration: Single EV site 2 EV MailArchive Servers (Windows 2003 Std SP2 32-bit, EV 9.0.5) 1 EV MailJournal Server (Windows 2003 Std SP2 32-bit, EV 9.0.5) 1 DA Server (Windows 2003 Std SP2 32-bit, EV 9.0.5) We need to upgrade to EV 10 to support Exchange 2013. What has thrown a wrench in the clockworks is that there is no migration path from DA 9.0.5 to DA 10. Only from DA 9.0.5 to DA 11. I know that DA11 would be compatible with EV10, but from what I've read, DA11 requires the EV10 binaries installed. So the question is, will the DA11 server with EV10 binaries work in the environment until we upgrade the EV9 servers to EV10? Has anyone done the upgrade from DA 9.0.5 to DA 11?Solved901Views1like4CommentsUpgrade from DA90SP4 to DA10SP4CHF1 breaks SQL replication
FYI. We had the below issue occur twice in different environments. This might or might not be happening to you, but if it does, you know now... Starting situation: Windows 2008 R2 x64 standard edition (EV and SQL server). SQL 2008R2SP2 standard edition, with log-shipping as DR solution (replication). Enterprise Vault 9.0SP4, and DA9SP4 Upgrade DA9SP4 to DA10SP4 - upgrade config-database, upgrade customer-db, verify evbaadmin is ok, verify DA10SP4 client connects ok. Apply CHF1 for DA10SP4 - upgrade etc. Verify DA10SP4CHF1 client connects ok. Logoff. Monitor SQL logshipping. You might see error: The log shipping primary database PROD SQL SERVER\INSTANCE.xxxEVDACM has backup threshold of 60 minutes and has not performed a backup log operation for 61 minutes. Check agent log and logshipping monitor information. Case 05907358462Views0likes3CommentsAfter Upgrade to 10.0.4 Compliance Accelerator is seeing 10.0.3 binaries
I upgraded CA and DA to 10.0.4 and all was well and then upgraded Enterprise Vault to 10.0.4. Though the accelerator service starts I get errors when the client attempts to retrieve instances A problem occured while retrieving the list of instances from 'server' localhost. The Accelerator service is either not running or the server could not be contacted. The event viewer has the following two entries Event ID 201 APP Undefined - Initialisation of the Accelerator Manager Failed. System.IO.FileLoadException: Could not load file or assembly 'KVS.EnterpriseVault.ProcessManagement, Version=10.0.3.0, Culture=neutral, PublicKeyToken=26c5e2ccf2b9267c' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) File name: 'KVS.EnterpriseVault.ProcessManagement, Version=10.0.3.0, Culture=neutral, PublicKeyToken=26c5e2ccf2b9267c' ---> System.IO.FileLoadException: Could not load file or assembly 'KVS.EnterpriseVault.ProcessManagement, Version=10.0.4.0, Culture=neutral, PublicKeyToken=26c5e2ccf2b9267c' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) File name: 'KVS.EnterpriseVault.ProcessManagement, Version=10.0.4.0, Culture=neutral, PublicKeyToken=26c5e2ccf2b9267c' WRN: Assembly binding logging is turned OFF. To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1. Note: There is some performance penalty associated with assembly bind failure logging. To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog]. at KVS.Accelerator.Server.Manager..ctor(ApplicationStartup Force_AS, ApplicationStartup Force_ATM, ApplicationStartup Force_Analytics) at KVS.Accelerator.Server.Manager..ctor() at KVS.Accelerator.Server.AcceleratorManager.OnStart(String[] args) Event ID 203 APP Undefined - Error when stopping the Accelerator Manager Service. System.NullReferenceException: Object reference not set to an instance of an object. at KVS.Accelerator.Server.AcceleratorManager.OnStop() As per control panel the versions of software installed are CA 10.04.1060 (install date 23/10/2013) EV 10.04.1189 (install date 12/03/2014) Any help would be much appreciated.Solved1.3KViews0likes2Comments
Error upgrading DA
Any suggestions on what I should do if I get this error when I try ot upgrade a database? DELETE failed because the following SET options have incorrect settings: 'ANSI_PADDING'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or query notifications and/or xml data type methods. DELETE failed because the following SET options have incorrect settings: 'ANSI_PADDING'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or query notifications and/or xml data type methods. DELETE failed. Other databases upgraded sucessfully, I only have 2 out of 7 that are like this. I verified that 'ANSI_PADDING' is off for all databases. Thanks.Solved1.3KViews1like8CommentsComplianc Accelerator evbaadmin cannot connect to server
Upgraded EV and CA from 9 SP2 to 10 SP4 (via the approved upgrade paths. Now, when trying to connect to evbaadmin on the CA server, get the error cannot connect to server. (and the Configuration DB and the Customer Databases were upgraded at each step.) We were/are trying to get the journaling connector configured.Solved1KViews0likes4CommentsEV Discovery Accelerator - EV Versions
After reviewing the requirements for EV base software (Services or API) to be installed prior to EVDA I am not 100% as to the versions allowed. I have an EV server running 10.0.1, which will be upgraded to 10.0.4 over the coming months. I will be installing EVDA shortly (before the EV 10.0.4 upgrade) and therefore want to install 10.0.4 on the DA server to save work in the future. I know that EVDA can be at a later version than EV itself, but does this include the services/API installed on the EVDA server ? In summary, I would like to do the following: EV Server has 10.0.1 installed and running (mailbox/journal/FSA archiving) New EVDA server - install EV 10.0.4 services or API runtime , install EVDA 10.0.4 Is this OK, or do I need to install the 10.0.1 services or API runtime on the new EVDA server Thanks, AJ.Solved660Views0likes2CommentsOrder of upgrade for DA 10.0.4?
Just reading Upgrade instructions for 10.0.4. On page 34 it states; Order of upgrade in an environment with Compliance Accelerator or Discovery Accelerator If the Enterprise Vault environment that you are upgrading includes Compliance Accelerator or Discovery Accelerator, the Accelerator version must be upgraded to 10.0.4 or later. The Accelerator version can be up to one major version higher than Enterprise Vault, but it must not be lower than the version of Enterprise Vault. See the Enterprise Vault Compatibility Charts at http://www.symantec.com/docs/TECH38537. You must upgrade the Accelerator product before you upgrade Enterprise Vault. Perform the upgrades in the following order: Upgrade the Accelerator product. Then upgrade Enterprise Vault on the Accelerator server. Finally, upgrade Enterprise Vault on the Enterprise Vault server. This is a change from previous upgrades, where you had to upgrade EV first, then EV components on DA server and then DA itself. Can anyone confirm? Anyone did DA 10.0.4 upgrade yet?Solved1.5KViews1like5Comments
Change in Legal Hold Process with DA 9.0.4 CU2 / 10.0.2 CU2
Hello All Recently we upgraded our EV 9.0.1 environment to EV 9.0.4 CU3 along with appropriate DA updates. Since the upgrade, we faced issue where cases stayed in "idle" status and the legal holds didn't apply at all i.e. items stayed in "remaining items" bucket for case. We tried normal troubleshooting included with legal hold which can be read about here. However same didn't help. In the event logs we were getting Error 562, which basically indicates that some items could not be processed due to legal hold error. On quick search for that error, i stumbled on this technote 66365 which tells you that after 9.0.4 CU2, DA will keep retrying applying legal hold on items which've been erroring out in hope that administrators have fixed the issue with that particular item accordingly. However, it still didn't explain why no item was going into hold state at all. The SQL query in above technote didn't help either. Running out of option, we opened case with Symantec and after couple weeks of troubleshooting, they asked us to disable "Sync validation" configuration via DA client (which is hidden by the way, to display same, you'll need to show hidden settings in DA client, steps for which are covered here.) After disabling Sync validation and restarting DA service, the items started processing and all items which DA didn't have any issue with were put on hold accordingly. The remaining items in our scenario basically are those which no longer exists in EV environment. The status changed from "Idle" to "To Add Holds" with some remaining items in case bucket. According to Symantec, the DA should basically give up after n number of retries but in our case it is not doing so. Currently investigating same. If anyone has further thoughts in this direction, please do share. Once we reach final case resolution, I'll update same here accordingly. Hope it helps ! Thank You.1.5KViews1like10Comments
