I'm trying to upgrade from Vault pro 6.1 to 9.1.
SQL Server is on a different machine.
The documentation for the installation says that the user doing the install must be a "full SQL administrator".
The user I am using is db_owner of the five vault databases. Not administrator of the server.
Is there a way to do the upgrade without having to be server admin?
I currently get an error in the install process is after the dialog "Connect to SQL Server".
"SQL Connection failed. Unable to connect to SQL.
Login failed for user 'DomainName\ComputerName$'"
It is using the computer name as a user name instead of the current user.
Is this because I am not a Server admin.
Rights in SQL Server on install.
Re: Rights in SQL Server on install.
Do you know if your SQL Server has 'SQL Server authentication' enabled or not?
During the upgrade installer setup, do you get a SQL Server authentication dialog? What information is being used there? If SQL Server has 'SQL Server authentication' enabled, use an account with full SQL Server administrative rights. If Windows authentication is only enabled, the account in which the installer runs must have full SQL Server administrative rights.
Note, you may want to try running the installer from a command line with elevated 'Administrative' privileges, and use 'msiexec /i "<path_to_vault_server.msi>"'
Some background... Full SQL Adminstrative rights will be required for installation because of the changes made to SQL Server (creating databases, adding / creating / modifying user authentication for the sg* databases).
There is a work-around, but it is quite tedious. Users have moved all sg* databases to a SQL Server they *do* have Administrative rights against, and run the installer against that SQL Server instance. Next they move the databases back to the other SQL Server, and manually configure connection logins and authentication for that other SQL Server. If you need assistance with that, you can directly contact support or post any questions here.
During the upgrade installer setup, do you get a SQL Server authentication dialog? What information is being used there? If SQL Server has 'SQL Server authentication' enabled, use an account with full SQL Server administrative rights. If Windows authentication is only enabled, the account in which the installer runs must have full SQL Server administrative rights.
Note, you may want to try running the installer from a command line with elevated 'Administrative' privileges, and use 'msiexec /i "<path_to_vault_server.msi>"'
Some background... Full SQL Adminstrative rights will be required for installation because of the changes made to SQL Server (creating databases, adding / creating / modifying user authentication for the sg* databases).
There is a work-around, but it is quite tedious. Users have moved all sg* databases to a SQL Server they *do* have Administrative rights against, and run the installer against that SQL Server instance. Next they move the databases back to the other SQL Server, and manually configure connection logins and authentication for that other SQL Server. If you need assistance with that, you can directly contact support or post any questions here.
Jeff Clausius
SourceGear
SourceGear
Re: Rights in SQL Server on install.
Thanks Jeff!
I got the same error when trying against a server where I am admin but using an elevated command line made the installer go all the way.
Happy about that I also tried that against the server where I'm not a server admin.
That failed in a later step with an error that it was not allowed to create a function in sgvault.
It looks like the installer first set sgvault in single user mode because the database was left like that after the installer failed.
Then I guess the installer tried to modify the security for the specified user account. That account was db_owner before but after it was just public in sg_vault. That does explain why the create function failed and why the database is still in single_user mode. I was using the same account when installing as the one I specified in the installer so the installer effectively locked me out of sg_vault leaving it in single_user.
Don't worry, I'm only testing this right now and can restore back to what it was before with some help from admins.
Right now it is up to the powers that be if I will be granted server admin rights in SQL Server or not on that server. If not it looks like the work-around will work.
Just want to confirm what steps I need to take after the restore of the upgraded database to the server.
I guess I need to modify server server property with the new server name in all places in the web.config files that holds connection strings.
I have found four:
C:\inetpub\VaultPro\Web.config
C:\inetpub\VaultService\Web.config
C:\inetpub\VaultService\VaultIndexService\Web.config
C:\inetpub\VaultService\VaultNotifyService\Web.config
I got the same error when trying against a server where I am admin but using an elevated command line made the installer go all the way.
Happy about that I also tried that against the server where I'm not a server admin.
That failed in a later step with an error that it was not allowed to create a function in sgvault.
It looks like the installer first set sgvault in single user mode because the database was left like that after the installer failed.
Then I guess the installer tried to modify the security for the specified user account. That account was db_owner before but after it was just public in sg_vault. That does explain why the create function failed and why the database is still in single_user mode. I was using the same account when installing as the one I specified in the installer so the installer effectively locked me out of sg_vault leaving it in single_user.
Don't worry, I'm only testing this right now and can restore back to what it was before with some help from admins.
Right now it is up to the powers that be if I will be granted server admin rights in SQL Server or not on that server. If not it looks like the work-around will work.
Just want to confirm what steps I need to take after the restore of the upgraded database to the server.
I guess I need to modify server server property with the new server name in all places in the web.config files that holds connection strings.
I have found four:
C:\inetpub\VaultPro\Web.config
C:\inetpub\VaultService\Web.config
C:\inetpub\VaultService\VaultIndexService\Web.config
C:\inetpub\VaultService\VaultNotifyService\Web.config
Re: Rights in SQL Server on install.
Yes. The connection strings will all be in web.config. If the SQL accounts (either trusted or named) are the same (and passwords for named), then it should be simply a matter of moving the databases in place, ensuring the correct SQL settings have been applied to the sg* databases, and making sure those accounts have access + dbo, and then modifying the web.config connect strings.
Jeff Clausius
SourceGear
SourceGear