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!
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.
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.
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:
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.
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.
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.