Saturday, April 23, 2011

Revit Server goes Desktop

So you have plenty of vacant workstations lying around in your office (I know of a lot of firms with whole graveyards worth of equipment sitting there collecting dust). And if these machines are already running Windows 7 64 bit, you can get up and running with a Revit Server setup at a whopping cost of $0. How does that sound?

“Sure” you might be saying, “it’s unsupported”. Maybe that’s true (meaning, Autodesk doesn’t guarantee it will work since it has not been officially tested) but the key to knowing that Revit Server will work is in the System Requirements: at least IIS v.7 and Microsoft .NET 3.5 SP1, all of which can be installed on Windows 7 x64.

However if you tried to do this, RS (Revit Server) won’t let you install it since it is checking for the existence of Windows Server 2008. In the following step by step guide, you’ll learn how to get things working properly and I can tell you from at least a week’s worth of experience that things seem to be working just fine.

Disclaimer: Use at your own risk and please, don’t bother Autodesk about any of this!

Our “Servers”

2011-04-14 18.29.11

We re-purposed two old Shuttle boxes that meet the minimum CPU system requirements (core 2 6600 @2.4GHz) with 2GB RAM. Autodesk recommends 8GB minimum, however in our first week of testing, we have not encountered any problems. Note that we only have one team currently working on this setup (4 to 5 users), so the more users you have and the larger the number of projects, the higher the specs. you might require. However I’ve been told by Mr. T that RAM probably will not make that much of a difference; time will tell I guess. In fact our next upgrade will probably be a bigger, faster hard-drive (and maybe someday, a better connection between offices!). At the moment we have about an average of 85ms latency.

Setup

You can start from scratch and install a fresh copy of Windows 7; I opted to clean out the machines instead. I started by deleting any Windows profiles and associated files, all applications, and made sure to enable Remote Desktop on them (I did miss setting one up properly so now I know better! Start>type “allow” and select Allow remote access to your computer; set properties and you’re done).

Next, I made sure to download and install all updates and set them to automatically install at the default time from there onwards. I then renamed the machines properly (set the Computer name to something that identifies each server easily).

A very important step is to set a static IP address for the machines. In the Network Adapter properties, set the IPv4 to your IP of choice (don’t forget the subnet mask) and make sure to set your DNS server address to each office’s gateway IP. In your router’s DNS settings, make sure to provide an entry for the server that will reside in the network behind that particular router & firewall (the machine name and associated IP address). This will ensure that name resolution works as expected: when your users type in which Revit Server to connect to by name, this is resolved properly.

Next, make sure to install IIS7 and Microsoft .NET 3.5 SP1. Go to Control Panel>Programs>Turn Windows features on and off and check the appropriate options.

Windows Components

I used a registry cleaner to make sure performance is as optimized as possible since I didn’t install the OS from scratch. I also installed BgInfo to make it easy to identify which machine is being remote controlled in the event we needed to. It’s nice to have some on-screen stats when remote-controlling and BgInfo is perfect for this, so customize the fields to suit your needs. We also set our browser to open automatically to the Revit Server Administration page on Startup so when we log in to the machine for any reason, we have what we need right there: Browser docked to the left and BgInfo on the right side of the desktop.

You also need to install Microsoft Silverlight. You can wait till you finish installing Revit Server and are accessing the Revit Server Administration utility for the first time or install in advance.

These Servers will probably be running behind secure firewalls, so there’s really no need to leave Windows Firewall running on them. I suppose you could leave them if you wanted and then open only the appropriate ports. We chose to turn Windows Firewall off completely and not worry about it as there is no documentation regarding exactly which ports are in use (port 80 for HTTP traffic is a must but I’m sure there are a lot of others we’re unaware of).

Installing Revit Server

Now on to the key tweak to get Revit Server to actually install!

Run Setup.exe and once it decompresses in C:\Autodesk and the installer is waiting for your next step, cancel out of it. The reason is that we need to make an adjustment to the setup.ini file so we circumvent the OS check. As long as IIS v.7 and .NET 3.5 SP1 are properly installed, everything should be fine.

Go to C:\ Autodesk, open Setup.ini in Notepad and look for the following excerpt:

Setup tweak

I opted to copy & paste the highlighted line and remove RevitServerOSVerCheck; from it. Then I commented the original line (prefix with a “;”) to preserve it, saved the file and exited. Now you’re ready to install Revit Server as usual (pick up from #2) and start by setting up your Central Server. Then move on to your Local Server installations once the Central is up and running.

Troubleshooting

We did have some trouble getting the Local server to recognize the Central server once each machine was in their final destination (initial testing with the two servers was all done in the same subnet and everything worked). We traced the problem to an incorrect gateway IP on the Local server, which was set to the public DNS server that we use. Since private IPs were being resolved internally by the gateway, everything worked fine but once the incorrectly set Local server was in it’s new home, the new gateway couldn’t resolve properly and requests/traffic was routed out to the public DNS servers, which obviously don’t know anything about our machines! Unfortunately Revit Server administrator is as helpful as a door knob to troubleshoot networking & routing issues and gives you absolutely no hint as to what could be wrong. Once we got this corrected, everything worked like a charm. So make sure to have some knowledgeable IT guys around for troubleshooting.

If you try connecting to a Revit Server by name and it doesn’t work, use the IP address instead and if it works, it means that you need to tweak your router’s settings to fix the name resolution issues.

One interesting thing that I didn’t know was that you don’t have to have the machines logged in for Revit Server and webserver services to run. So just fire them up and you’re good to go.

Implications

What does this all mean? Well, for starters, Revit Server is actually accessible to a lot more people than I previously thought. I think the “required” Windows Server 2008 OS is a huge psychological barrier, but it doesn’t have to be. You do need to set things properly from a networking standpoint, but once you do it’s really a breeze to use and processes don’t change a whole lot for the end users. As I said, it cost us $0 in additional hardware and software to get it going, so there should be no financial barrier to even start considering it. I think even small practices that work with long-distance collaborators stand to benefit from taking advantage of this technology. All it should take is VPN access (or a VPN tunnel between 2 or more networks) and the rest is as mentioned above.

In an earlier post, I briefly mentioned my limited success with installing a Public Revit Server (further testing is required…I really need to get me a decent desktop to test with and keep learning as much as possible about IP addressing, routers, etc.!). Aaron already hinted on his blog that they are running Local Revit Servers on laptops with Windows 7 and I hope that the above “tutorial” can help others actually getting it to work.

I’ll make sure to post again once we have a little more experience running this system but so far, silence on the part of our users tells me that things are running efficiently and as smooth as silk.


Share/Save/Bookmark

14 comments:

Cesar said...

This is great! I can now have our "Consultants" use our own VPN we built with a certain "security profile" eliminating the "Updating Backgrounds to the FTP" routine :D
You got to submit this as an AU class ;p
If things run smooth on my end I'd like to co-contribute to the class as a testimony to the success in a separate environment :)

Dave Baldacchino said...

Class to AU? I think it would not be permitted hehe. Plus I'm not going to AU unfortunately (didn't even bring the topic up to be honest).

As for using it with consultants: are you going to link the project directly from Revit Server? I wonder how that would work out when the model consultants are working on is open to modification. If Revit Server allowed locking a model on a specific local server without affecting others, that would be great but for now it doesn't do that. So there's always the risk of accidental editing that could potentially happen.

Cesar said...

I want to Link (attach) our Arch Model into an empty Revit Server Model file to deny modification from the Consultants.
I'm trying to use your "How To..." to "interlink" Consultant files live thru a secured VPN (with access to only the Revit Server we want to set up for them), but "use" revit server as it's ment to be used in-house, not, XD :p LOL.
Once I have my Ducks in a row (no longer theory) I'll post it to my blog, unless someone beats me to the punch or I used a different approach.

With AU Virtual we can stay at home to present ;)

Anonymous said...

What about running this on a workstation - no separate server? I think this this is where we want Revit server to end up where we can work from home or for consultants who are independent contractors.

brianjdavis said...

Problem with linked files for outside consultants (I am one), you can't place a hosted element into a linked file! So Light fixtures and diffusers can't host to ceilings, outlets to walls, etc. Anybody else run in to this problem? Other than problems caused by poor connections and problems with local server connecting to central server and lack of IT support on central server end, Revit Server works great.

J said...

F'ing Awesome once again David!!! Thanks from the BIM O Sphere...

Luigi Coletta said...

To BrianJDavis, what you wrote is true, but wouldn't you be using face baced families? In our office we mainly have MEP in House, and we still use the linked files aproach...all of our standard families are face based, which then do attach to faces of any object. For outside consultants I would think you definitely want to link the files and use face based families...unless there is some specific requirement from client/contractor.

Dave Baldacchino said...

Yeah AU Virtual is an option but I'm just too busy to think about presenting. Training is no longer my day-job/career (in a firm, no one respects it), although I still do it in one form or fashion. As for linking in an empty project, that should work; good thinking!

Anonymous, this post is about installing on a workstation (?) so yes, you can do what you're wanting. Look at the "Implications" section.

Brian, as Luigi explained (thanks man!), you can do what you're after with face-based families. Which is also why now you can also reconcile hosting for when the hosting surface was deleted.

Jay, glad you like it ;)

NKramer said...

Has anyone run into problems where the user shuts the server/ laptop down before is is done syncing?

Would this cause corruption or other unforeseen consequences?

Dave Baldacchino said...

We've had some issues saving at times (could have been due to slow network connections between offices) but after trying to save a second time, everything returned to normal. I have not tried any tests to deliberately "break" things by shutting down the servers during a SWC. Might be worth testing but so far the system seems pretty reliable and robust in terms of file corruption.

Anonymous said...

are you guys still using this setup?
have you thrown more users at it?
is it still surviving on just 2GB of ram? (if not, how much now?)
are you using this between offices?

would love to know some updates on this! thanks!

Dave Baldacchino said...

See new blog post for further info.

Anonymous said...

I am trying to setup Revit Server 2013 thru windows 7 and got it going and works great. I am using Revit Server on the same machine I use Revit on. I can connect to the Revit server with using this same machine.

Here is the problem, when I go to my other computer in my office I can connect to the revit server but when I go to open a project I don't get the Revit Server listed on the left pane at all. I created the RSN.ini file and it is in the right folder. How can I resolve this issue and see the revit server to open new central files for local.

I also have another question. I don't know very much about VPN and setting trusts etc from one office to another office. Could you explain how you get that to work. I cannot find anything very useful on this. My scenario is I work from my home office and it is me and another person (so 2 of us max.) and we work as a consultant with another office that I will be installing revit server 2013 on also. How do I get the Hosts/ Accelorator computer from both offices to "talk" to each other so central files are updated on their own?

Any help with explaining this or links or any overall information will be a great help.

Thanks,

Chris

Dave Baldacchino said...

Chris,

Make absolutely sure the RSN.ini file is in the correct location and set up properly. If it is, I am not aware of any reason it shouldn't work (this file has to reside at each workstation if I recall). Sorry but I cannot offer much more detail as we don't use Revit Server at my new employer (HOK) so I cannot check. I set up 2013 at my previous workplace and it worked fine.

As for VPN, it's all dependent on your router hardware/software. You have to consult your documentation to set it up (site-to-site VPN). We managed to set up a connection between servers outside of VPN (by doing NAT, etc. so traffic was properly forwarded to the correct IP addresses). Once you set up VPN, it'll be easier to get RS to work. If you go outside of VPN, you can even open it up to the outside world (ex: access the Admin panel through a URL or using the server's IP address).

Post a Comment