Secrets of the Vault Configuration File

Today we’ll discuss a significant feature for those who count themselves Vault Administrators. I have always recommended having a “Test Vault” for sampling new functionality, training, testing the waters, etc. This means you can validate new workflows by using house money, so to speak. Then you can save all of your hard work out and import it into a new Vault, and move forward with the implementation, hitting the ground running. With the release of Vault Family 2010 (except base Vault) we had this functionality. Recall this earlier post for review.

The 2011 Vault Family has some enhancements to this wonderful feature, and this is the focus of this post. First, let’s examine the information captured in the configuration file (.cfg):

• DWF Publish Options
• Lifecycle Definitions
• Revision Schemes
• User Defined Properties
• Property Mapping
• Categories
• Category Assignment Rules

To export a configuration from one Vault to another, log in to the ADMS (Autodesk Data Management Server) console. Choose the specific Vault database and right click. Choose Export configuration and save this to disk. Hint: save this to a public location, fir instance C:UsersPublicDocuments.

Now, to leverage this on the same ADMS in another Vault, you can right click another Vault and select Import Configuration. Or, you may create a new Vault and during the process, use a custom configuration file. see image below:

Only objects not already existing in the target Vault are imported. Existing object with same name will not be imported or modified. No Users or Groups set in the Life Cycle Definitions security for the states and the transitions will be imported, but will have to be defined BEFORE import. If you are keeping this on the same ADMS, this is not an issue. But what if you are targeting this cfg onto another server/ADMS?

As mentioned, what is not stored in the configuration is Users and Groups – which of course are important in connection to Life Cycle Definition , where the permission are a great part of the setup. But this can be accomplished any way by planning a little ahead and using generic user and group names, which after the import are renamed and added with more users.

First if all – if you are going to export/import configurations remember to start by creating a COPY of the standard setup element be it a Life cycle definition of a revision scheme. The reason is during a import to a new Vault, the ADMS will always first import the custom settings and THEN run a stored procedure to recreate the standard elements – which means all customization will be over written unless named differently.

The Process of creating a Generic setup is:

Start by creating a number of Generic Groups (and the corresponding users needed to create a group) like indicated below:

Best practice is to use Groups when assigning permission and security to Lifecycle Schemes, and to apply user roles on a group level rather than on a user level.

Now develop the Configuration and save it out in a .cfg file in ADMS. Also make a Backup as . cfg files cannot be migrated to a new release. Instead you migrate the Backup and then save a new .cfg file from the next release.

When preparing a new Vault, start by creating it in ADMS Console, add the Users and the Groups with EXACTLY the same names as you used when exporting the .cfg in the first place.

Then use Import Configuration, and you should have a empty Vault with all the above settings preset, and the last step is to rename the Groups to relevant names, and to add users to the group.

This also work for imported Active Directory users and groups, and you just include the AD group into the relevant Vault Group, without further need for changes.

-Brian Schanen