Import a vault from one server into another vault server with existing vault

[egil.sporild]

Hi

Is there anyone that can give some recommendations re. importing vault basic vault 2014 from one server into an other server with vault professional 2014 with existing vault?

I don't want to do a restore because I want to keep the existing vault in 2014 Pro.

Thanks in advance.

[tmoney2007]

Someone can correct me if I'm wrong, but I don't believe that standard methods support moving an image from one server to another with anything but a fully restore.

Are we talking about one of several vaults on the Vault Basic server being moved to the Vault Professional server which also contains other vaults? Or would all of the vaults on the Vault Basic server be transferred (and replace) anything on the Vault Professional server?

I'm about 99% sure the first scenario is not possible.

For the second scenario, you should either be able to restore the basic vault onto the professional server or you can set a windows restore point on your basic server, upgrade it to professional, then do the backup, and it would definitely restore to the other professional server. 

[Neil_Cross]

Correct me if I'm wrong, but the problem you have is whichever way you go about doing it... if you restore a backup from Server1 into Server2, it'll wipe the Vault that was there on Server2? As tmoney said above there's no way using the standard ADMS backup & restore functionality to move just one Vault.  Mainly because a Vault is more than just a storage box, it has user accounts etc in the knowledgevaultmaster DB which must come along with it, you can't really blend that with another.  But I guess you know that bit 

There is a way to achieve what you want to do, well a couple of ways, but again like tmoney said they're not part of the standard product.

1.  The official proper way to do this would be to use the Data Transfer Utility (Autodesk DTU) which is a command line based extraction tool.  This extracts the entire Vault, all file history, items, ECOs, users, everything, and creates a full XML based package duplicate of your Vault.  You then use the same DTU tool to upload that package into a new fresh Vault.  That new Vault can be on a Vault server with an existing Vault already there, essentially you're creating a new Vault and squirting the contents into it from the extracted package.  And it'll work from Basic to Pro.

The bad news is that the DTU isn't available to the general public, it's a Consulting Services specialised utility only available to select Autodesk partners.  Personally I've used it a lot and it'll definitely do the job you want, however you'd need to approach your local Autodesk reseller or Autodesk Consulting Services team to raise a request for them to do this work.  I guess you'd need to decide if what you're wanting to do is critical enough to justify this.

2.  Option 2 is kind of a fudge, ridiculously simple, and could take ages depending on how big your Vault is on the Basic server.  This option is do a 'Get' on the entire Vault, download it all to a local folder, then use either the Autoloader or various CAD apps to check it all into a new Vault on the other server.  You'd lose all file history and user traceability records etc.  If it's a big Vault this could be a no go anyway.

Personally I'd recommend the DTU as it's safe and solid, but like I said you'd need to get in touch with someone who could provide that service to you.

[clastrilla]

 Hi Neil,

Have you ever tried using Vault DTU, importing a package (exported from another Vault) to a Vault which is using a remote SQL server?

I've merging the data from one server to another (Vault Pro 2015), and everything works fine in the test environment (with the exact same dataset), but on the production environemnt, the DTU import gives the error:

-------------------------------------

Preparing database...
*******************************************************************
Error: Object reference not set to an instance of an object.
Exception: Object reference not set to an instance of an object.
Stacktrace: at VaultBCP.Serialization.VaultRoot.Import(XmlReader reader, Context ctx, Boolean verify)
at VaultBCP.Processor.Import()
at VaultBCP.Processor.begin()
Fatal Error: exiting...
Cleaning up Database...

---------------------------------------

No other logs seem to be able to shed any light, even after setting Verbose to 2.

The only difference between the production environment and test environment is that on the production environment, the SQL server is on a remote server (still within the LAN though).

[Neil_Cross]

I haven't imported into an ADMS using a remote SQL, they've all been local to the ADMS.  I'm interested myself to see if this is achievable so I'll see if I can maybe set up a similar environment and test that as I don't see why it shouldn't work, there's no documentation to say remote SQL isn't supported. 

Whilst I'm doing that, I have contact details for one of the product managers actively involved with the DTU so I'll drop him a quick mail to ask the question.  If it is supported then it may be an issue unique to the customers environment.

Also whilst that's going on, have you tried putting in the FQDN of the remote SQL server into the DTU import string, or the IP address? Just incase it's something daft like a DNS issue.  Might want to start a new thread too so we're not spamming this poor guys inbox with something he'll have no interest in!

[clastrilla]

Hi Neil, just figured it out (or at least resolved it). It's not that the remote SQL is the issue, but could be one of two things:
1. Vaultbcp.exe does not like a path for the package that has a space in it (e.g. "D:\DTU Export") even with the quotes enclosing the path
2. Vaultbcp.exe does not like a path for the package that is on another local drive (or the way the VM paths what looks like to be a local drive)

After seeing a coolOrange blog post on how vaultbcp does not like mapped paths, on a hunch I moved the import package to the same drive from where a
I execute the saved batch file which runs the vaultbcp command. In moving the package, I also removed the space between the folder name. It worked. Which was the exact root cause, I don't know yet. Once I finish this merge on the live server, I'll do further tests on my test environment.

Thanks for the info!

[Neil_Cross]

Awesome, at least you can get cracking with it 

On all my previous DTU imports I've went out my way to ensure the DTU application files & ADMS, the export package, filestore & SQL instance are all on the same server ideally the same partition, although I know you can't always have your own way  I used the DTU on huge datasets (500GB+) so obviously minimising having to pass data over a LAN or across different interface connections will ensure the job goes a load faster.  Again, I've only ever done this on production Vaults where the company essentially has to stop working whilst I'm doing it, so speed has always the most important factor after reliability.  

I suspect the issue was probably with the path type though rather than character spaces in the path, I recall having spaces in folder names previously and using the quotes to enclose it, so I'm guessing it was the path.  Would be good to get confirmation for future reference tho!

[Neil_Cross]

Interestingly enough I've just heard back from the Autodesk PM who seems to think that the DTU will not work with a remote SQL, he's going to double check with the dev team but that's the feedback I've had so far.  

If you've managed to get it working then perhaps it may be more of a 'not supported' thing rather than it just won't work.