09-26-2018 03:18 PM
09-26-2018 10:16 PM
Hello,
I assume you followed the documentation, and have updated the directory database and the fingerprint database already. To reconfigure the Vault Store database(s), you should be able to do just the below. If that fails, then run Deployment Scanner, and enter only the NEW sql information. See if all SQL checks are green.
Stop the Enterprise Vault Storage service.
Move the vault store database to the new SQL Server.
Make sure that the Vault Service account has the correct permissions to access the new database.
In the Administration Console, right-click the vault store whose database you have moved, and click Properties.
Click the Database tab.
In the SQL Server box, enter the name of the new SQL Server.
Click OK.
Restart the Enterprise Vault Storage service.
09-26-2018 10:54 PM
09-26-2018 11:45 PM
Deployment Scanner reports issues with collation and the absence of SQLXML. The collation of the EV databases are consistent with each other but different from that of the instance.
Would either of these cause the issues we're seeing?
Thanks again.
09-27-2018 12:30 AM
I saw a similar error during the mgiration.
I had to login to the server which holds the Vault store and make this change. Ofcourse the directory services had to be started fully (8192 event) on that server.
My servers are on EV 11.
09-27-2018 12:53 AM
Hi. Sorry when you say "make this change", what change do you mean?
09-27-2018 01:38 AM - edited 09-27-2018 01:51 AM
absence of sqlxml is no issue if you do not use FSA Collation issue is going to be problematic! do not continue if the collation mismatch is indeed existing!
But, it might be a false alarm. Can you paste the exact lines for a database pls?
I just ran it on an EV I know has collation issues. If you have a red cross with SQL Collation, and the lines show:
sqlserver, port: Unmatched default SQL collation: Server: Latin1_General_CI_AI;
databasename database: SQL_Latin1_General_CP1_CI_AS.
then you have to make sure that the collection of the NEW server matches the collation of the OLD server, or at least the collation of the databases. If you do not have the same collation, you WILL run into trouble. Upgrading for instance will not be possible.
09-27-2018 02:19 AM
Yeah, the server collation is certainly different from the database collation:
May have to look at a dedicated instance for EV :(
09-27-2018 05:18 AM
Most definitely.
For each DB you have 2 entries. Are these the same SQL server, or are they different?
If the same, you *might* be fine. The you need to check in SQL. Check the server collation. Then check all databases for their collation.
If you still have support, call VRTS. They can investigate if you are ok. I personally would not want to risk having a mismatch. It means you can not upgrade anymore, and might give some troubles down the line.
09-27-2018 05:54 AM
09-28-2018 03:17 AM
I've created a new instance with the same collation and now everything is green in the Deployment Scanner but I'm still getting the same problem. I'm wondering if it's the instance name that's the problem, given that the error comes up immediately. I've tried:
but both of them fail. I'm wondering if the application supports instances with this naming convention or if it can only be in the format:
Thanks again.
09-28-2018 03:59 AM
Hello again,
Good to see you now have green ticks everywhere!
For the instance, I have the following:
servername.domain.com\instancename,portnumber
sqlserver.mydomain.com\evault,12345
Works fine.
10-01-2018 11:54 AM
Thanks for that. Was hoping this was some unsupported functionality biting me. Guess not :(
10-02-2018 02:13 AM
Would it be possible to make the connection updates via ODBC and/or registry changes to circumvent whatever issue appears to be causing this alert?
10-02-2018 03:13 AM
If you moved all databases to the new server:
edit registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KVS\Enterprise Vault\Directory\DirectoryService, value SQLSErverName to read the servername+ the instance+portnumber (server\instance,port)
then use C:\Windows\SysWOW64\odbcad32.exe, system dsn. Verify all are correct. Here wyou will see portnumber.
10-03-2018 12:36 AM
Thanks for that. Tried it but unfortunately the original value is still reported inside the Administration Console. I presume it must be stored elsewhere which is why the AC is the documented way to update it.
10-04-2018 02:27 AM
Ended up deconstructing the PowerShell script which is referenced in https://www.veritas.com/support/en_US/article.TECH35744. This identified the SQL table that needed to be updated to perform the same task as the Administration Console would have done.
So far all seems to be working.
10-08-2018 01:08 AM
Still got one problem I can't address. The Enterprise Vault Accelerator Manager Service is still configured to point to the original database server. I manually updated the *.config files to get the service to start but when I go into the Symantec Accelerator Manager and select the properties, the Database Details point to the original server.
The form does not appear to be editable and the value isn't stored in the config files - I've checked again.
Any ideas how I can update these values?
10-08-2018 02:54 AM
Hi, again,
Can you recheck, following the below document?
edit config files DA after SQL database move
10-08-2018 04:06 AM
I'd done the config files but not the database update.
Thanks.