Deployments, content and hacks

One of the most tedious and thankless jobs is creating software deployments. “Why is it taking so long?!” I remember asking towards the end of May back in the days. I couldn’t appreciate why, because…well, I didn’t know what it involved. Now that I know I can appreciate it a bit more, although I don’t think it should take weeks on end to get Revit onto users machines.

The first challenge is to get the content downloaded and placed on your network, and install your network licenses (I won’t be discussing the latter on this post). Autodesk have, IMO, made it more cumbersome since the 2012 releases to get content prior to creating deployments, which used to be available for download from their site. My solution is to install a version on a virtual machine (such us VirtualBox from Oracle) and then mine the content to be placed on the network library.

At my previous employer, content was placed on a DFS share which replicated to all offices and then its contents were copied to each machine’s local drive in read-only folders at log-on. This was mainly done due to laptop users and in theory, should cut down on network chattiness when accessing content. At my current employer, we keep everything in a library on the network, which is replicated nightly to another office on the same share as the main office (mapped on desktops with the same drive letter). This is a very important thing to consider in order to simplify your content mapping.

Upgrading of content is a must-do step for some. In my case, I have kept the content as is because we have multiple versions of Revit running so it doesn’t make sense to upgrade and duplicate the custom content in versioned folders. The most used families are pre-loaded in the template so only a limited number need to upgrade when loaded into a project. Of course Autodesk content is placed in its own versioned folder and mapped through the xml files that debuted last year and caused quite a headache. When we don’t need an older version anymore, we can easily nuke the old content folder.

If all your offices have content in exactly in the same location, you’re on your way to simplifying and accelerating deployments. However lots end up having to manually create unique deployments in each office because of two other things that tend to be unique resources at each location: Revit Server and the license server. However, with a little collaboration with your IT department and some basic understanding of DNS, you can actually create a single deployment that works at all your other offices! Sounds too good to be true, but it’s actually quite simple.

Depending on your office network infrastructure, you might be running DNS on your Windows server or some other box. In our current setup, it’s actually running on the router software. So to edit DNS entries, we log into the router and make changes there (called DNS forwarders in our case but your router might have this functionality under DHCP settings, such as with Tomato router firmware). But why should we be bothered with DNS when we’re talking about deployments? Well, whenever you try to connect to a machine with the hostname, a query is sent to the local DNS server first to see if it can trace it to an IP address on the local subnet (if connected together via VPN, each network is defined by it’s own subnet. So for example 192.168.1.XXX is a different subnet/network than 192.168.2.XXX, assuming you have less than 255 IP devices plugged in to each one). This is also what happens within your home network and high-speed internet router. If the hostname is not found, the query is passed on upstream through the gateway and onto your ISP’s DNS server.

You’re probably familiar with naming a Windows machine with a hostname so its easier to locate on a network. The DNS server keeps track of the hostnames and associated IP addresses, which typically change from time to time, so when you try accessing a resource with the hostname, it forwards you to the correct device with the IP address stored in its database. This fundamental fact is extremely important to understand.

However hostnames can be entered on the DNS server (or DHCP settings) manually, so you can think of them as “nicknames” or placeholders to point you to a specific resource. In fact multiple hostnames can be used to point to the same resource. To illustrate, let’s say you have 2 offices A & B. When creating a deployment:

• Office A is mapped to RevitServer-A
• Office B is mapped to RevitServer-B

So now you’re probably saying…”well Dave, that means you need 2 unique deployments or at least, make a copy of A in office B and modify the deployment”. That is one way of doing it for sure, but not the smartest way. Think back to the DNS discussion above: You can create a new hostname to point you to a unique resource in each subnet. So I can enter a DNS entry as follows at each office:

• Office A: revitserver mapped to RevitServer-A’s IP
• Office B: revitserver mapped to RevitServer-B’s IP

Now my deployment can be used in both offices and when the local DNS is queried for revitserver, it returns the correct IP address for that location and no deployment tweaks are necessary.

Similarly, if you have a license server at each location, you can easily set up the deployment to use distributed license servers as this minimizes the possibility of running completely out. So let’s say I have the following setup:

• Office A: license server called Apples
• Office B: license server called Bananas.

Typically you’d enter them as follows in each deployment:

• Office A: Apples, Bananas
• Office B: Bananas, Apples

In essence, you prioritize them so that each local license server is accessed first and if no more licenses are available, it will find the other one through the Wide Area Network (WAN), assuming your offices are connected together via VPN or ethernet. Once again these seem to require unique deployment packages, but with the above described magic of DNS, we can circumvent this issue. So my deployment can now say fruit1, fruit2 and work at both locations without further tweaks once again. Have you guessed how the DNS entries would be set up?

• Office A: fruit1 –> Apples’ IP,   fruit2 –> Bananas’ IP
• Office B: fruit1 –> Bananas’ IP, fruit2 –> Apples’ IP

So once again, the same deployment can be used and the DNS will resolve accordingly. The beauty of this is that you set it once and be done with it. With the advent of Design Suites and the myriad of deployments that come with it, this methodology will save you tons of time and then multiply that by the number of offices you have to support!

I hope this is of help to someone out there. As always, comments are very welcome.

Deployments, content and hacks