Migrating from one vault server to another.

[Jim]

Hi

I'm looking for assistance in migrating our old vault server onto new hardware. We have 192 users on vault 3.1.9 on Win2k/SQL2000 and are looking to migrate onto a new Win2k3 server.

Ideally we would like to take the opportunity to go to SQL2005 at the same time but could do with some advice on how to approach this.
- Should we migrate to SQL2005 or is there any reason not to?
- Should we take the opportunity to upgrade to vault 4.Current at the same time?
- Is the backup, restore, then install approach valid?

As context we have currently tried these two approaches:
Backup Live, restore to new live. (SQL2005) Install vault server 3.1.9. Run vault client. (LOTS of errors occurred during checkin and checkout)
Backup Live, restore to new live (SQL2000) install vault server 3.1.9. Run vault client. (Some errors, including unable to get latest as it simply loops forever getting folders).
Therefore I would like to start with a recommended approach and go from there if some of the strange behaviour we have noted re-occurs. Obviously if it reoccurs during the correct migration approach then I'll look at the specifics of the errors.

Thanks
Jim

[lbauer]

- Should we migrate to SQL2005 or is there any reason not to?
- Should we take the opportunity to upgrade to vault 4.Current at the same time?
- Is the backup, restore, then install approach valid?

Yes, all of the above is a good strategy.

Backup Live, restore to new live (SQL2000) install vault server 3.1.9. Run vault client. (Some errors, including unable to get latest as it simply loops forever getting folders).

It's strange that just moving the database and reinstalling the server is causing problems. Because of the issues you've encountered, we'd strongly recommend using a test environment to work out the kinks before making any changes to your production system.

The first step I'd suggest is to restore a backup of your Vault database to SQL 2005 on a test machine. Install Vault 3.1.9. Install a client on the Vault Server machine and use it to log in, checkout, checkin, etc. and do a few other source control operations. If that seems ok, upgrade the database in stages by first upgrading to Vault 3.5.3, then 4.0.6, then to 4.1.4

You can download previous versions here:
http://www.sourcegear.com/vault/downloads2.html

NOTE ON VAULT 4.0.6: There was a bug in the uninstall routine for the 4.0.6 if you install the server and the client together using the server's installer. Upgrading will succeed, but leave two client shortcuts on the desktop. Please follow the instructions at support.sourcegear.com/viewtopic.php?t=9653 for instructions on removing the 4.0.6 server and client before upgrading to 4.1.4.

Once you have successfully upgraded to Vault 4.1.4 with SQL 2005 on the test server, and source control operations seem to be functioning normally, you can either use this installation for production, or move the upgraded database to your production environment. Let me know when you're ready to do this and I'll provide additional instructions.

[Jim]

Linda

Thanks for the reply.

I have now successfully got 3.1.9 running in the non production environment and am about to upgrade to vault 4.
Am I correct in thinking I should now go 3.5.3 then 4.0.6 then 4.1.4? or is it acceptable to go straight to 4.1.4 ?

Once I have done this I will need to restore from the production database (3.1.9) - when we do our actual migration. So I'm wondering if I need to repeat all of the upgrades when I actually go live or if I can just do the latest one?

thanks
Jim

[lbauer]

Am I correct in thinking I should now go 3.5.3 then 4.0.6 then 4.1.4? or is it acceptable to go straight to 4.1.4

You *might* be able to upgrade directly to 4.1.4, but it depends of the state of your database. The installers not only upgrade, but fix issues in the database. It's better to do these fixes incrementally rather than all at once.

When you've upgraded successfully, you'd need to run the same sequence of upgrades on the production database. Either that, or use the upgraded test database for production, if it's not out of date already.

[Jim]

Linda

thanks for the help so far. I have made it up to 4.0.6 but when installing 4.1.4 I get the following error during the setup.

Error 1713. SouceGear Vault Server cannot install one of its required products. Contact your technical support group.

It is strange this is the first setup where it has not offered me the chance to install the admin tool and also the first setup where it failed to recognise the installation directory of the vault services and default to the correct location.

Can you please advise what to do?

thanks

[lbauer]

There was a bug in the 4.0.6 installation. See this KB article for a fix:

http://support.sourcegear.com/viewtopic.php?f=13&t=9653

[Jim]

Thanks for all of the help so far. This has been a fairly fraught process but its implementation weekend this weekend so I will try the live migration.

I was running my upgrade process again to test the migration path for the weekend and hit the issue of duplicate objects in pk_serialnumbers. My guess is that the issue is that the SG_MASTER database is created by this installation and therefore having it in place during the upgrade causes the fault. Does this sound correct?

Error log below....

Thanks for any help.

OK
Upgrading your Vault configuration.
Checking for IIS Version...Connecting to the SQL Server...OK
Verifying the SQL Server requirements...OK
Requesting Vault Admin user password...OK
Upgrading the existing source control database...
This may take a long time. Do NOT stop this process!
Checking the installed database version...OK
Grant database access to NT AUTHORITY\NETWORK SERVICE...OK
Upgrading SourceGear master database schema...OK
Upgrading SourceGear source control database schema...Violation of PRIMARY KEY constraint 'pk_serialnumbers'. Cannot insert duplicate key in object 'dbo.serialnumbers'.
Violation of PRIMARY KEY constraint 'pk_groups'. Cannot insert duplicate key in object 'dbo.groups'.
Violation of PRIMARY KEY constraint 'pk_users'. Cannot insert duplicate key in object 'dbo.users'.
Violation of PRIMARY KEY constraint 'pk_groupmembers'. Cannot insert duplicate key in object 'dbo.groupmembers'.

[Jim]

For completeness that did seem to be the issue. Removing the SG_Master database resolved the fault.

That left the SG_VAult database in "single user mode" but once that was removed the installation went through successfully.


thanks

[lbauer]

An upgrade from one 4.x version to another should upgrade both sgvault and sgmaster databases. Not sure what happened in your case that you had to remove sgmaster. Did you have to recreate all your users?

[Jim]

Sorry I was not clear enough in my post. I was starting again from scratch therefore I reverted the database back to 3.1.9 hence when it hit the first 4.X version it found an SGMaster already in place. Once I had deleted the SGMaster Database the upgrade from 3.x -> 4.x worked fine(ish).

Currently I am unable to do any check-ins and the server simply returns "Internal Server Error" for each transaction. I can not find the server logs (they are neither being written to c:\windows\temp\sgvault nor where I want them configured E:\applications.net\vaultlogs. Panic starting to set in.......

[Jim]

Ok now we are back. It appears to be working again - Have changed the log path to E:\vaultlogs and it seems to be fine, I guess there is an issue with having a . in the directory name that you write logs to?

As an aside is there a separate download of the old winforms admin tool that works with this version? Personally speaking I found it to be considerably better than the new web based one.

[lbauer]

Sorry for the emotional distress . . . Glad things are working now.

I guess there is an issue with having a . in the directory name that you write logs to?

No, I set up a folder for logging using the same path name. Maybe it was a permissions or other issue.

is there a separate download of the old winforms admin tool that works with this version

The Vault Admin Client is a web client in 4.x and later. There's no Windows client. We do have feature request 13753 logged for this, though; I'll add your "vote."