Monday, August 1, 2011

Reflections on Testing and Setting up Revit Server

It occurred to me recently while talking with a colleague to make a blog post on some of the things I came across when going through setting up and testing Revit Server (RS). Hopefully this will help out others who are looking at implementing RS at their firm. I've made a post about Revit Server previously on my older blog which may be of reference, but already a few things on it have become out dated.

Testing on Revit spec Desktops
For starters and to get our feet wet, we setup 2 regular Revit spec desktop boxes with Windows Server 2008R2. One was the central RS and the other the local RS. Initial testing across the WAN was promising as save times dropped from minutes to seconds. When the average time for saves went from 7 minutes across the WAN for 180MB file done to around 30-45 seconds, I knew we had to get this going throughout the firm.

Expanded to Actual Servers
Now that we decided to implement this fully, we had to get our ducks in a row so to speak if we were going to place production projects into RS. We knew that for reliability, the setup needed to be on appropriate server grade boxes with redundancies built in that all servers should have, especially for the hard drive. Looking back, we spec’d out servers that are below the recommendations from Autodesk, but they have been working out so far just fine as we only have one active project going in it. If the use increases over time, then we will look at the need of whether or not the servers need to be upgraded.

File Backup for Disaster Recovery
We also verified that appropriate backup measures are in place. We are using Windows Shadow Copy 3 times throughout the day to ensure we have something ready in the event something is lost mid-day. Also, at night we employ a script per the RS Wiki site to place a server lock on all models andback up all files on a nightly basis.

Planning out Central vs Local Servers
We realized that we needed to establish early on which office location would serve as the central server as you can’t flip a switch and make a central server a local server. Also, we felt it would be an IT administrative nightmare trying to establish multiple offices with central servers.  We decided on making our office with the largest head count the central site. All other office locations will be local servers pointing to it. We felt this was appropriate because the majority of work is carried out in this location and it has the largest bandwidth for handling connections to outside locations. Connection bandwidth will have an effect on your experience with RS too. If it’s not fast enough, you can end up with corrupt models or models failing to access the central properly.

What needs to be installed for local/server systems
For local systems, getting ready to use RS will vary depending on the version of Revit you are dealing with. As detailed in myprevious post, Revit 2011 needs the following components installed: Web Update2, Subscription advantage pack 2 (link takes you to sub ctr), RS client app (link takes you to sub ctr), Project Bluestreak and RevitActivity Stream (more on these last two will follow). For Revit 2012, all you need is Project Bluestreak and Revit Activity Stream. Its recommended though to ensure Web Update 1 for 2012 is installed as it provides a number of stability enhancements when working with RS.

For server systems, you will want to ensure Windows Server 2008R2 is up and running along with IIS. Then, setting up RS is pretty much a breeze via the install wizard found on your Revit installation disk or downloaded files (it's been noted by Autodesk to not extract the files for RS install from the main Revit install setup). The latest recommendation from Autodesk is to install RS 2012, update1. I can confirm this is the desired tool as we were having issues with RS 2011.  One thing we did once we got one local server setup was we imaged the setup, then ghosted it onto the other local servers, changed the box and local server name and had a really quick setup.

Security issues
The biggest hurdle I had to overcome was when I said to IT that we needed to install Project Bluestreak (BK) for anyone using RS. BK requires certain ports to be open in order to allow it to communicate through Autodesk servers. These ports happened to be the same ones they had blocked for IM apps like AOL AIM. I was able to convince them that this was the only way to have automated messages display when people were STC.

The other thing we did was set only certain people to have access to RS. There are 2 ways you will want to have access setup. You will want to limit the number of people that can access any of these areas to minimize the risk of someone accidentally messing with files they shouldn’t. The RS admin panel operated via Windows Internet Explorer can be set so that only certain users can access it in order to set model locks for maintenance. Also, Windows Explorer should have 2 paths opened to allow access to the physical files. One goes to the location where the model data is stored and the other goes to the log folder for RS as both of these locations will need to be accessed in the event you need to send files to Autodesk if there is a problem. This applies to both the central and the local servers.

Stability issues
It would seem that RS 2012 update 1 has fixed many of the problems we were experiencing with RS. RS 2012 update 1 will work with both Revit 2011 and 2012. Things like model locks, where no one could save to central would randomly occur or the local files for users would become disassociated from the central. It seemed these issues were occurring once a week for a while. Still, even with the occasional issues we were having in RS 2011, the team estimated they were saving about 12 hours a week for 3-4 people working on the project. Now that we seem to be done with file locks and disassociated local files, productivity should increase even more.

As mentioned earlier Project Bluestreak (BK) is required for automated communication of actions such as STC. Earlier on there was a lot of communication interruptions due to working out server port issues and some bugs Autodesk was working out on their side. It seems that most of that has been worked through now.

Also, you will want to ensure that if in the event the team is comprised of people only in remote offices, that you have a support person or computer you can remote into at the central office location. You will want this if you need to place a model into RS. It can’t be done safely over the WAN and in order to ensure the model does not go corrupt, you need a local system in the central office for that.

The other thing to think about is that RS only hosts Revit models. You cannot place other files into it that you might normally link into a Revit model such as dwg files. You will want to make this clear to the team that the model will no live in a different place than the project. Also, when you go to send the file to other trades, you need to open the central with detach from central selected, otherwise, if they don’t have RS setup, they won’t be able to use the file. So plan for a little extra time for that.

Next steps
Now that we have it running smoothly for one project we will be opening it up to other projects that utilize teams from different offices. If this continues to scale smoothly, we will start looking at the possibility of building a DMZ to allow other trades to work on projects on the same server. That probably won’t be able to happen for testing until next year though.

No comments:

Post a Comment