I have an interesting situation I wish to discuss.
Our current Vault database is installed with Integrated Windows.
We want to migrate our database to a new installation on a production server and use SQL Authentication. We want to do this for several reasons. One is because the password in the Vault web.config file is encrypted and we can impoersonate.
While I know how to use SQLServer's backup/restore, this is what I did.
Step 1 Create new database sgvault on prod server.
Step 2 Restore db from test to production using SQLServer Backup and restore.
Step 3:
For the web server installation, we want to impersonate. So when I install web server on a production web server I choose SQL Account. This creates the following line in the web.config file.
<add key="ConnectString" value="Application Name='SourceGear Vault Server'; Connection Reset='true'; Server=(local); Database=sgvault; User ID=sgvaultuser; pwd=bOj+gJw98Q4yRo6x/ol+8A5qjfFZa5ci" />
Step 4: I have to go into IIS and enable Anonymous Access to vaultservice and shadow virtual directories on the production server.
Step 5: Logon to Vault admin and disable the the check box Authenticate using Active Directory for all users. I also changed each client's password too.
So right now everything works just fine!
We want to run in parallel for a few days to make sure all of our repositories check out.
So when I restored the database a second time, from a more recent backup, I found the only thing I had to do was run the script that you supplied to grant sgvault user access to the database.
But I'm curious about the encrypted password in the web.config file.
Does this need to change? If not, how does Vault know how to impersonate since the db was restored after I set up the Vault web server?
Thanks
btd
Vault Restore
Moderator: SourceGear
The presence of the Connect String is not Identity Impersonation, but a manner in connecting to the SQL Server.
If you restore a backup from a different Server, there are a lot of things that may not be configured correctly. In an instance like this, I would recommend to:
If you restore a backup from a different Server, there are a lot of things that may not be configured correctly. In an instance like this, I would recommend to:
- Uninstall the Vault server (Keep or Drop the database when prompted)
- Restore the Database (forcing it to install over the existing database or dropping the existing data if it still exists)
- Install the Vault Server (Keep the database when prompted)
Jeff Clausius
SourceGear
SourceGear