Vault GPS: Make All the Right Turns During Your Vault

Upgrade
Irvin Hayes Jr. Autodesk, Inc.

PL5843-P Upgrading your replicated Vault software environment to a new release of Vault software shouldnt
be an intimidating endeavor. Building an understanding of what actually happens when clicking the install button
is crucial to having confidence in your upgrade plan. This class will cover existing and newly supported methods
for upgrading your replicated Vault software installation, and you will leave armed with the knowledge of what is
actually happening in the background with SQL so that you can proceed with confidence.

Learning Objectives
At the end of this class, you will be able to:

Understand the importance and role that SQL plays in a Vault software upgrade

Understand the out-of-the-box procedure for Vault software upgrades of replicated environments

Understand the alternate snapshot procedure for Vault software upgrades of replicated environments

Learn how to set yourself up for a successful migration

About the Speaker

Irvin Hayes Jr. is a product manager for the data management group at Autodesk in Novi,
Michigan. Irvin has worked at Autodesk for seven years starting in product support and as a
user experience designer. Irvin is a Microsoft Certified Professional, and has been working in
the information technology field for more than 21 years.

Table of Contents
Learning Objectives..................................................................................................... 1
About the Speaker........................................................................................................ 1
Introduction................................................................................................................... 3
What happens with a normal vault upgrade?..................................................... 3
How it works....................................................................................................................................... 3
Understanding the obstacles........................................................................................................ 5
Planning to overcome the obstacles........................................................................................... 6

Using Alternate Snapshots ....................................................................................... 8

How it works....................................................................................................................................... 8
Understanding the obstacles......................................................................................................12
Planning to overcome the obstacles.........................................................................................12

Setting yourself up for success...............................................................................12

Closing............................................................................................................................13

Every Silver Lining Has a Vault in the Cloud

Introduction
Upgrading your replicated Vault software environment to a new release of Vault software
shouldnt be an intimidating endeavor. Building an understanding of what actually happens
when clicking the install button is crucial to having confidence in your upgrade plan. This class
will cover existing and newly supported methods for upgrading your replicated Vault software
installation, and you will leave armed with the knowledge of what is actually happening in the
background with SQL so that you can proceed with confidence.

What happens with a normal vault upgrade?

How it works
Some of the information in this section is taken from the Autodesk Vault Upgrade guide. Please
refer to the guide for additional information as this class will not cover everything in the guide.
As called out in the guide, the upgrade process for an Autodesk Vault environment is comprised
of 5 steps:
1. Validating a Backup
2. Upgrading SQL
3. Upgrading Vault Server
4. Upgrading Clients
5. Creating a Backup
Autodesk recommends that every Vault upgrade starts with a validated backup. This validation
will ensure that if the upgrade process fails, there is a backup that can be restored. It is also
recommended that you have a test environment that is close to your production environment as
possible. The reason for this is to allow you to better estimate how long the actual migration may
take. You should add a buffer to the migration time so that you can report back your estimation
of downtime to the reset of the business. Also, testing your backup and migration will help you
identify potential pitfalls prior to executing the migration in the production environment.
Prior to the upgrade, you may want the various business units to sign-off on the migration. It
is recommended to create a document containing the key features that the business uses.
Testing workflows, customizations and integrations should all be done the test environment to
make sure that everyone understands the changes and can be trained prior to upgrading the
production server.
Using the test environment provides a safe option to experience the migration process and
discover unexpected hurdles. Although this process takes time it can, in the long run, save time
and stress by avoiding impact to the production environment. You can use this environment
to create documentation that is necessary for a successful migration. This can come in handy
in case something happens to any of the key players involved with the migration. This will be
revisited later.

Every Silver Lining Has a Vault in the Cloud

Now lets move on to the Upgrading Vault Server step. Before we can look at a replicated
environment, we first must understand the single site environment. This single site environment
is made up of the database (SQL), Autodesk Data Management Console (ADMS) and the
Autodesk Vault File Store (AVFS).

As called out in the Autodesk Vault Upgrade guide, you need to pay attention to how many
releases you are skipping over in your migration. For example, if you are going from 2011 to
2015, you will need to go to some intermediate release. In the example, you would need to
go from 2011 to 2013 followed by 2013 to 2015. Autodesk doesnt allow you to migrate more
than 2 releases apart. I would recommend getting to the appropriate service pack or hotfix
level prior to opening up the ADMS Console during the migration process. Once you open the
ADMS Console, the migration will begin. What is going on at this phase is that the database
is being prepped for the current release. This involves updating stored procedures, tables and
restructuring data where necessary.
Now lets look at a replicated environment. It does consist of the same pieces that a single
environment entailed. However, it allows for multiple SQL locations which are known as
Connected Workgroups. Believe it or not, upgrading a replicated environment isnt that difficult.
You must first upgrade the main Workgroup, also known as the Publisher Workgroup, by
upgrading an ADMS machine within the workgroup. This starts the process of migrating the
Publisher SQL databases. Once the SQL databases is properly updated, snapshot are created.
A snapshot is a read-only view of a database at the time the snapshot was taken. This snapshot
is then consumed by the SQL subscriber machines. Once the snapshot is consumed by the
subscriber, the environment is now ready for use once all the ADMS / AVFS machines within
that workgroup have been updated accordingly with the appropriate software release. It is best
to upgrade all the ADMS machines in the subscriber workgroup first prior to moving onto the
AVFS machines.

Every Silver Lining Has a Vault in the Cloud

Understanding the obstacles

We recently worked closely with a customer to help them through a rather large migration
process. Our goal was to help identify problems that may arise during the migration and also
to ensure that the migration completed in a timely manner. In order to have success with this
venture, we needed to collect various information from them. In particular, we needed the
following:

Their databases

A detailed mapping of their network

Hardware specifications

Once we had this information, we set up a lab environment close to what they have so that we
can better understand the pitfalls. Along with us running a series of tests in our lab they were
running similar tests in their lab. This was beneficial since it allowed us to compare notes and
focus on various differences within the environment.

Every Silver Lining Has a Vault in the Cloud

This is a smaller example of their Vault environment.

During our first couple migrations we noticed that there was considerable differences in the
timings between the environments. This made us focus on the hardware. Since the migration
process is very read/write intensive, we started to focus on the hard drives. We needed to look
at what partitions the database were on and the type of RAID configuration. Another area of
focus was on memory since SQL utilizations as much as it can (you can limit the amount within
SQL itself). We monitored both of these activities use Performance Monitor to help us get a
better understanding of what is going on. We also utilized a utility called Wireshark to get an
understanding of how much data was going over the network. Upon investigating all avenues, it
was determined that we were sending too much data over the network in terms of the snapshot.
Remember the snapshot is the data that the publisher creates post migration and is updated
from time to time based on the SQL schedule. There was obstacles with the hard drive and
memory but they did not impact the total migration time as much as the network traffic did.
Planning to overcome the obstacles
Now that we understand the obstacles of the migration we were able to come up with solutions
to get around them.
The main obstacle was the network. We were able to overcome this obstacle by using the
Alternate Snapshot solution which will be discussed in the next section.
The hard drive can be handled by purchasing additional partitions or reconfigure the existing
partitions. If you are going to reconfigure the RAID partition, it is highly recommended copying
all data off the entire drive to another location prior to beginning the operation. As mentioned in
the previous section, a migration has intense read/write operations. If you are setup up a RAID
configuration, you need to make sure that it can handle a lot of read/write operations. You will
want to pull out SQLs temp database and log files to a separate partition. The main database
should be on a partition that can handle a lot of read/writes. You will want to have the log files
on a separate partition as well. Once you are satisfied with your configuration, restore your data
accordingly. NOTE: The file store is not impacted by a migration and if you are running it on the
SQL machine as well you will want it on its own partition.

Every Silver Lining Has a Vault in the Cloud

Depending on your current system, you will want to have a sufficient amount of memory in the
system. If more memory is determined to be needed, prior to the migration may be the best
time to upgrade it. This way it can be fully utilized during the migration process itself. The
memory / processor upgrades is something that the business unit will need to determine if it is
worthwhile now or if the budget is even there for the upgrade.
We found that having the issues documented prior to the migration made the actual migration
run smoothly. If you are working with Autodesk or a reseller during your testing phase and
have issues, they can help you solve this problems in the test environment prior to migrating
the production environment. A documented process also allows the migration process to be
executed by anyone on the team.
NOTE: Please contact your reseller or Autodesk to make sure that whatever is being deleted
can be deleted. Autodesk or the reseller may have to create a special script in order to make
the migration run smoothly.

Every Silver Lining Has a Vault in the Cloud

Using Alternate Snapshots

How it works
Since we determined that the network is a problem for the size of the database we need to
migrate, we need to look at the Alternate Snapshot method. The point of this solution is to
allow you to move the snapshot from the publisher to the subscribers in a manner that you find
conducive to your environment. For example, you do not want to have a 500GB snapshot going
over a network that has bandwidth of 1mbs with a 200ms latency. Here are the steps for using
the alternate snapshot:
1. Wait for the migration and snapshot to be created on the publisher. This can view the
status by opening SQL Management Studio, launch the Replication Monitor and select the
database that you want to see the status on. You should see a dialog as shown below.

2. Immediately after the snapshot is created, turn off the SQL job on the remote SQL
servers using the SQL Management Studio
3. Move the snapshots to the subscriber location
4. Modify the agent to point to the Alternate Snapshot location. At the end of the command
line remove -Continuous and add -AltSnapshotFolder D:\VC_Replication_Share\ where
D:\VC_Replication_Share\ is the local path of the unc folder.

Every Silver Lining Has a Vault in the Cloud

5. Reinitialize the Subscriber

Every Silver Lining Has a Vault in the Cloud

Select YES to this dialog.

6. Restart the Job

7. Wait until the snapshot consumption completes. The status of this can be viewed in the
dialog above and when it shows that it is complete.
8. Stop the SQL job
9. Set the synchronization setting back to Continuous

10

Every Silver Lining Has a Vault in the Cloud

10. Start the SQL job

11. Wait until replication to get into steady state. The replication status on a database will
show Waiting 60 second(s).

12. At this point, your subscriber is ready for use

11

Every Silver Lining Has a Vault in the Cloud

Understanding the obstacles

The reason why we are doing the Alternate Snapshot is that the network has some sort of
issues with it whether it is bandwidth, latency or both. This obstacle will still be there. Other
obstacles could be around the delivery method used to get the data to the subscribers. The
data could arrive and be corrupt. Maybe you sent someone on a plane to the location and
somehow the drive was wiped. We will need a plan to overcome these.
Planning to overcome the obstacles
Ways to get around this would be use multiple methods to assure that data will arrive in a timely
manner. If you decide to go with a zip method, you would want to test that the zip is indeed
working properly prior to sending it via a device.

Setting yourself up for success

Before we do the migration we definitely want to remember that we need to have a good
solid backup plan which includes a backup and several test iterations in a non-production
environment. You will want to make sure that your backups are proper and indeed cover
everything in your environment. You never know what could go wrong during the migration.
To quote Jonathan Landeros of Inventor Tales, Should the worst happen, have a backup plan
that includes having a backup to restore, instead of slipping out the back door before anyone
notices!. I cannot iterate this enough that you want to run multiple migrations prior to the day
of the actual migration. Write out a preliminary migration plan. Take notes during your test
migrations. Combine your initial plan along with your notes to create robust document in which
anyone can use in case the need arises.
Remember, you are the expert of your environment. If you are doing the migration yourself or
are getting outside resources to help out, it is best to make sure everyone is aware of the details
of the environment. You will be the best to predict slowness at particular workgroups. This
knowledge can be used during the testing phase of the migration. Again, your environment
should be as close to the production environment as you can make it. You can set up network
emulators and such to give you a better idea on what will go on during the migration day. Just
remember that during this process there will be down time. Your system will be unavailable
to the business units while it is executing. But, you can limit the down time and impact to the
business by planning accordingly.
Have a plan for migration day. Make sure you have the who, what, where, when & hows all
in order prior to that day. Make sure that the team involved in the migration is lined up. It is
worth mentioning that you may want to have backup people ready to go in case something
happens on the day of migration. They need to know where they are going to meet (online / at
the office). They need to know when to start. This could be during business hours or off hours
depending on what your plan yielded. Make sure that everyone understands what their role is
during the migration. Who is updating what servers and when are they being updated. With a
good predictable plan your team will know where they are at during the entire migration process.
This will lead towards a smooth migration.

12

Every Silver Lining Has a Vault in the Cloud

Closing
Now that we know what to expect during a migration we can go forward and have a successful
migration.

13