Vault Collaboration 2012 to Vault Pro 2014 with Connected WG upgrade / migrate

[Raider_71]

Hi guys we are about to embark on a very daunting journey to migrate directly from Vault Collaboarion 2012 to Vault Pro 2014. We have set up connected workgroups about a year ago and this has been running for about a year between our two offices located in different towns.

Doing this migration and moving forward are there any pitfalls you guys can point out to us or any experiences you might have to share?

Thanks

Pieter

[paul.gunn]

Hi,

I do have a couple of suggestions:

(1) before migrating the production environment, try restoring a recent backup onto a stand-alone test VP2014 system. This is a good way to check ahead of time that there won't be unexpected migration issues. Problems are unlikely, but you definitely don't want to find out about issues when your production system is partially migrated.

(2) before actually migrating the production system, ensure that replication of all the databases is healthy and reasonablly up-to-date. Migration requires that all of the sql servers be on-line and checks that all data has been replicated to the publisher before proceeding. So making massive data changes just before migration will impact downtime.

Hope this is helpful,

Paul

[Raider_71]

Hi Paul,

Thanks for the feedback!

Ok so my plan so far is:

• Ensure all databases are migrated and replicated to the publisher and subscriber.
• Perform a manual backup of the publisher server
• Try and restore backup on a test server
• Uninstall ADMS 2012 from both servers
• Make sure all servers are online and install SQL 2008 SP3 on publisher and subscriber
• Install ADMS 2014 on publisher
• Perform migration on publisher and let the changes replicate
• Install ADMS 2014 on the subscriber server

 Does this look right?

[paul.gunn]

Hi,

This sounds like a good plan to me.

Paul

[tech]

Hi Paul thanks for the help so far. Here is another quick question if you don’t mind. It’s an issue that’s come as a bit of a surprise when we wanted to do the initially planned migration. So as we wanted to start the process we realised that the Vault server in location “B” is still running Server 2003 x64.

Ok so just for clarity here is the current setup:

Lacation A:

• Server 1: Windows Server 2008 with Vault Collaboration 2012 – Hosting the Filestore
• Server 2: Windows Server 2008 with SQL 2008 SP2 – Hosting the Database

Lacation B:

• Only one server: Server 2003 x64 with SQL 2008 SP2 and Vault Collaboration 2012

Ok so currently the two locations is setup and connected using connected workgroups in Vault Collaboration 2012.

What we are now planning is to setup another server in location B. This will be a Windows 2008 server which will have Vault running on it and hosting the filestore as well. The original server at location B will still remain a 2003 x64 server with SQL 2008 hosting the database.

My question is, would this be a supported setup? …and what would be the best way to split the currently one server with SQL and Vault to two servers having another server for Vault, bearing in mind we want to end up with Vault Pro 2014 after the whole migration in both locations.

[paul.gunn · Accepted solution]

Hi,

I don't see any problems here. Steps would look something like this:

(1) install vault server onto new machine - configuring to point to remote sql on the old machine

(2) run ADMS console on the new machine [this will add the new site] and enable vaults on the new site. OPTIONAL: if you copy the filestore(s) from the old machine, you can have 'enable vault' on the new machine point to the copied filestore (avoiding a bunch of replication)

(3) [cleanup] from ADMS console (either machine) delete the old site from under the 'sites' node to remove it from the system and uninstall vault server on the old machine

Hope this helps,

Paul

[Raider_71]

Ok great that sounds good. So would it not just be a good idea to uninstall ADMS Console on the old 2003 server before I even start. I am just thinking also to try and prohibit anyone from making changes to Vault during the whole process of moving ADMS to the new server. What would be the best way to lock both sites/databases so users cant make changes, before I attempt an upgrade or anything like this for instance? Just to make sure the databse and the filestore dont get out of sync when I do the Filestrore move to the new server.

Ok so then once the new server has been implemented on Location B I suppose I can start the 2014 migration right?

Thanks once again for the help!

[paul.gunn]

Hi,

Uninstalling from the 2003 server probably makes sense. That would prevent any data modifications from there. Technically should be OK if the other workgroup remains operational, but if you want an easy way of preventing access is turning off the web site in IIS manager. That would prevent any client connection.

Regarding migration, you will want to wait until the system has reached a steady state first. When you enable the vault on the new site, it will go through the filestore and record what files it has in the database - and also build a search index for the vault. You will want to wait for those operations to complete (and fully replicate) before doing a migration.

Paul

[Raider_71]

Hi Paul thanks for the info. I think this thread will be very useful to other users as well in future.

Just a few more things as this has been a while since I last set up remote SQL. If I remember correctly there will have to be a shared folder set up on one of the servers. Can I set this folder up on the new Vault server?

Then if I remember correctly it’s quite a tricky thing to get this folder shared so that both the Vault service and SQL service have full access to it. What would you advise?

Thanks once again!

[paul.gunn]

You're welcome -

The share can be on any machine - although commonly on either the sql or adms machine. In short, the permissions need to be such that the vault impersonating user (account vault server runs under) and the SQL service user (that SQL server runs under) have access to the folder. Often this can be facilitated by using domain accounts for these uses. The advance configuration guide has a section on this: http://wikihelp.autodesk.com/Vault/enu/Help/Help/0376-Advanced376

You might want to look at your eixsting permissions / users in your other workgroup configuration (which I believe is using remote sql) and mirror how that was set up.

Paul

[Raider_71]

Hi Paul,

I am trying this on a replicated test setup but get the following error. Please see the images.

I have basically just got a new server up and running and started installing Vault 2012 Collaboration on there. ADMS was uninstalled from the other server in location B. The installation went seemless but when I got to the end and started up ADMS consol I get these two errors. Any idea?

[paul.gunn]

Hi,

It sounds like the new ADMS is not at the same version or product tier as the database (and presumably the other site). So when it tried to migrate the database it was unable to - since you cannot run migration on a subscriber.

Paul

[Raider_71]

Ok I think I have left out Update 2 when I installed ADMS. All the servers are Collaboration 2012.

I am trying it again. I have also deleted the site of location B using the console of the publishing server.

[Raider_71]

Ok I got it working thanks for all the help and advice! When installing ADMS it must be the exact same version the all the other ADMS's and especially the publisher. 

[Raider_71]

Hi Paul,

Everything went fine with the upgrade but as with everything nothing goes 100% smooth...

I have one question. It looks like on one of the vault databases replication did not go through properly. The other vault seems fine and the clients on the subscribing site can connect fine. If I open ADMS 2014 on the subscribing site and select the one vault it show me all the info for that vault etc. If I select the other vault I get an error. See image.

Is there a way to push the replication for that database again? We did have an issue with the replication shared folder rights but we sorted that out and everything seems fine except for this message we get.

Any idea what it could be or how we can get past this?

[paul.gunn]

Hi,

Have you checked the replication status of the vault (r-click menu on the workgroup node in ADMS console). If you drill down into details you will see current state of the database replication . If it is a large database it may just take more time to create the snapshot and replicate changes.

Paul

[Raider_71]

Hi Paul see the reply from IT. Don’t you think it’s got something to do with shared folder rights? There are three folders that are shared. Two between the two SQL and Vault servers and one between the two connected workgroups. We had issues with the initial migration attempt because of rights and we have subsequently modified permissions and the upgrade database changes seemed to have gone through and replicated properly as per what we can tell and also according to the Vault server status in the publisher workgroup as per your previous instructions. Any idea? Should I create a support case rather?

Response from IT:

I’ve double checked the replication status and everything seems to be replicated.

I ran a validation with checksums against the data to confirm what replicated was accurate and the error in ADMS is still occurring.

The Summarize script it’s referring to seems to be here:

\\unitempctdc1\VaultReplication\unc\CPTSQL$AUTODESKVAULT_UNITEMPCT_ADMS_UNITEMPCT\20130623000005\Sum...

It may be possible to manually run that and generate the missing stored procedure but I don’t know what other scripts may need to be run before/after it or if there are other dependencies.

[paul.gunn]

Hi,

I would recommend a support case at this juncture. If the stored procedures have not replicated then the replication status detail should not be showing database replication as up-to-date.

Paul