Cracking the Vault

#13 Don't... Attach a Database from One Master to Another

In every Vault readme that is released, it states the following:-

"Detaching a Vault and attaching it to a new server installation, without also attaching the Knowledge Vault Master, will lose all non default users and corresponding data. All detach and subsequent attach cases should include all Vaults as well as the Knowledge Vault Master."

#12 Don't... Use A Long Computer Name (>15 Characters)

Following an experience blogged here, avoid using long file names on machines with Microsoft SQL installed.

It probably won't be a problem until it comes to enabling SQL replication int he ADMS Console (Connected Workgroups).

Limit the Computer Name to 15 characters or less.

#11 Don't... Use a proxy server for internet traffic.

Unless you understand how to re-configure Vault as per the Advanced Configuration Guide for Vault, don’t use a Proxy server for Internet traffic.

#10 Don't... Make direct changes to the databases unless guided by Autodesk.

Direct access and editing of the Vault database is not supported. Autodesk can provide no assistance once it has been established that the database has been modified manually. This rule also applies to the server file store.

All access to the Vault server data must go through the Web Service API. If it is not possible to achieve the desired functionality through the API, it should be assumed that it is outside Vaults design parameters and therefore not supported. In this situation you can log a Support Request and ask for this to be supported in a future version.

Here are some examples of prohibited actions:

• Adding rows to a Vault table
• Updating rows in a Vault table
• Adding or updating triggers to Vault tables
• Adding or updating Vault stored procedures
• Adding or updating Vault table constraints
• Adding tables to a Vault database
• Adding columns to a Vault table
• Replacing\Deleting\Moving a file in the file store
• Deleting any entries in a Vault database
• Using SQL Management Studio to manually Attach, Delete, Backup or Restore Vault or Vault Library databases to the AUTODESKVAULT instance.
• Modifying users or security in the AUTODESKVAULT SQL instance
• Adding another database to the AUTODESKVAULT SQL instance.
• Changing default settings within the AUTODESKVAULT instance unless otherwise sanctioned by Autodesk.

Making changes to replicated environments is not supported unless executed from the ADMS Console.

Database maintenance actions are allowed.  These commands include re-indexing, and backup. Autodesk does not recommend Defragmenting any of the database within the AUTODESKVAULT instance for performance reasons.

#9 Don't... Use a network shared folder for the clients workspace.

Before implementing Vault, a common practice was to configure a user’s workspace to point to a network share. The main reason for this was to ensure that their files were regularly backed up. This had a negative impact on the users productivity performance as well as increasing overall network activity. With Vault this practice is unnecessary. If all files are routinely checked into Vault, at least at the end of the working day, if not more frequently, the regular Vault Server backup should negate the main reason for saving files regularly over the network.

#8 Don't... Rename or change the domain on the server if SQL is local.

If the AUTODESKVAULT SQL instance is also located on the local machine, refrain from changing the Vault Servers name. This extends to adding changing the domain that the server is a member of. Remote SQL is only supported with Vault Collaboration and Vault Professional. For all other versions of Vault Server, the Vault database should be located on the same machine as the Vault Server itself. For more information see this blog post (“-OSiteRename Advisory Limitation Warning”) http://crackingthevault.typepad.com/crackingthevault/2010/10/-ositerename-advisory-limitation-warning.html

#7 Don't... Apply an Autodesk update or hotfix until you understand the steps involved.

Before installing any Vault Server Update or Hotfix to ensure that the procedure is fully understood. The installation procedure would be documented in the “readme” file that accompanies the Update or Hotfix.

#6 Don't... Apply an update or hotfix until you have a restorable backup.

Before applying any Vault Server hotfix or Update, ensure that you have taken a backup from the ADMS console. For complete peace of mind, ensure that you can restore that backup to a test server.

#5 Don't...Create a backup over the network.

The ADMS Console backup utility supports backing up to either mapped drives or shared network locations. As the Vault grows over time, doing this can have a significant affect in the time taken to complete the backup. Instead, configure the ADMS Console backup to place the backup on a local disk. If it is necessary to copy the backup to a remote network share, that is then backed up to tape, then configure the command line utility to copy the backup after the ADMSConsole backup has completed. One recent extreme example was that it was taking nearly 9 hours to complete a backup over the network. The backup completed in less than 2 hours when configured to backup locally.

# 4 Don’t… Use the Windows Indexing Service.

Older versions of Vault Server utilized the Windows Indexing service to index the contents of each file. Vault server no longer uses the Windows Indexing Service. On some systems that were upgraded from earlier releases, the Window Indexing System is still active and can have a negative impact on performance. Of course there may be other reasons for keeping the service running but if there are not, then make sure it is disabled.