Tuesday, June 07, 2011

Restart Roulette & Taking Revit Server On the Road

The posts on Revit Server just keep coming... The topics just keep coming to me as I talk to more people or have the opportunity to try things out, etc.

So, as we know (thanks to Mr. Baldacchino) we can install Revit Server on a Windows 7 computer running IIS (not supported by Autodesk in any way!).

Thus, springs the idea, let's put RS on a laptop running Windows 7, and then, when someone has to go on site, they can still work with the Central File, without having to use a remote desktop connection, detach from central or "check-out at risk".

As I mentioned in my previous post "Taking Revit Server Off-Road" the first concern is that you can't simply shut down Revit Server and everything will be all-right. If there is an on-going data transaction, then bad things could happen! I should add that if you have multiple files cached to your Laptop, then keep in mind all those files are going to update regularly assuming other folks are working on them, so it is not just a matter of being concerned about the file you just made changes to, but all files that are "local" to your Local Server.

So for fun, I installed Revit Server on a Win7 laptop (I actually had an excuse as I needed to verify some behavior quickly, but it is good to have those!). When I went to point Revit Arch at my new Local Server on the laptop, I had to stop and think.

  • Should I use the Hostname? But doing that would potentially (I don't know for sure) loop the data out and back on the network (which seems kinda silly).
  • Should I use the IP address? Which one? This is a laptop after all, I've got WiFi and Hard Wire among other things, and once again, that might loop the data out and back on the network.
  • Then is occured to me, I should use the "Loopback IP" (127.0.0.1) this would always work, regardless of which connection I'm on, and even regardless of computer name.
So, I plugged the Loopback IP in and everything seems to be kosher. I won't swear to doing extensive testing, but I was able to open a file, add some stuff and Sync back without any problems.

Now, all of that said, the other issue which came up recently is dealing with Server Restarts, particularly as they are related to Windows Updates. In his post David says:
"Next, I made sure to download and install all updates and set them to automatically install at the default time from there onwards."
Well, generally speaking updates come down in the middle of the night, no one is the wiser and no one cares. I don't know about you, but I've pulled some late nights in my architecture career (even professionally). To that end I would never want to have a production Revit Server set to restart automatically no matter what, unless I have something in place that is also going to gracefully shutdown Revit Server, and stop the restart if Revit Server won't shutdown gracefully. This is all goes to my original point in the Off-Road post about interuppting data transactions in Revit Server. Sure in the middle of the night there should be no data, because no should be working, but should and being 100% certain are two very different things and do you want to play Restart Roulette with your project teams and their data?

2 comments:

Joe said...

This is good stuff, remote use is only going to become more and more prevelant. It sounds as though most of the functionality is there to have a workstation or laptop be the local server, we just need Autodesk to adjust the RS service to be able to start and stop based on a client workflow instead of an always on server. Keep pushing the envelope guys.

Robert said...

Services simply run, so its not a question of adjusting the service perse, its a question of implementing another level of software and control that can monitor the data and do something, whether it simply throws up a warning that says "No, you can't shutdown until I finish my current operation" or can pause the operation and pick-up where it left off when it can reach the network again. This would all go to any type of fail over strategy and would likely help to overcome the weakness of a Hub & Spoke system. But they had to start somewhere, and while not perfect, it has been a great start so far!