Inside Autodesk University 2024
Meet Paul Deyo and dive into his first experience at Autodesk University 2024.
I've been upgrading Vault systems for a decade, and if there is one thing that doesn't surprise me it's companies not checking that they have a valid Vault backup.
Every week I will check a company's server or receive a support call, because they are looking to upgrade or have just noticed they have not had a backup. This could have been going on for days, weeks or months and no one has checked on the process. In fact the current record found by our support desk stands at 1549 days without a backup; over 4 years without ensuing that your engineering data and company's IP is recoverable should something happen.
The reasons for backups not running correctly are many and varied but in my experience here are the top 3 things to check:
The main 2 culprits are:
As a bit of a guide to the various accounts and passwords I've put together the below guide. For security reasons I've excluded passwords from the list:
The backups will run off of up to five different accounts of various types:
Account 1 – Impersonation Account
Type: local
User: autodeskvault
Password: Please see Symetri for default details
Role: This impersonation account is used by the ADMS to store data on the server, change configuration files and access the web services. The account information is changed from within the ADMS console. Changing this account could lock a company out of the Vault. It is a local user account by default although this can be changed to a domain user.
Account 2 – VaultSys SQL account
Type: SQL Account
User: Vaultsys
Password: Please see Symetri for default details
Role: This account acts as the database owner inside SQL, creates the databases as required and manages the backups / restore processes
Account 3 – SQL SA account
Type: SQL Account
User: SA
Password: Please see Symetri for default details
Role: This is the default SA account for SQL. The ADMS uses this account to write the the SQL database. Should these password be altered then the new password will need to be to be input within the ADMS console and altered within the backup scripts.
Account 4 – ADMS-servername (SQL Account)
Type: SQL Account
User: ADMS-servername
Password: Please see Symetri for default details
Role: All ADMS operations use this account. Get files, check out etc...
Account 5 – Backup task account
Type: Local / Domain
User: Admin or service account
Password: N/A
Role: This account is used to run the windows scheduled task. This will require enough permissions to start and stop services on the server. It should also be a domain account if you wish to copy the backup off the server as part of your script.
Account 6 – Vault Administrator Account
Type: Vault Account
User: Administrator
PW: blank by default
Role: This is the account that the administrator would use to log into the vault via the client. This account is utilized within the backup scripts which will need to be altered should the details change.
Again, each of these accounts have a role in backing up the vault and users should be wary of password changes. Common backup failures are due to passwords expiring or being changed without these changes being reflected within this backup process.
Also note that the backup will not run if the ADMS console is open on the server under any account. Please ensure that this is closed after use.
There will be a future blog post on how to backup your vault without having the password stored/visible in the backup script so subscribe to the feed so you dont miss out.
For more information on monitoring your Vault backups please see our web pages about our ActiveEye service for Vault.