VPN and working Offline

[dbaldacchino]

Hi all,

I recently started working with worksets for the first time and had some questions about two scenarios that I thought of that could potentially spell disaster, and wanted to see if anyone had any experience with any of these or some suggestions to share.

Case A: Working via VPN, no offline files being synchronized

A team of 2 is working on a project with worksets enabled. I'm one of the team members and am working via VPN while the other is in the office. So I log into the network via VPN, go to my local files folder and open my local file. I borrow elements and modify elements as needed. In our office, we're keeping local files on the network so everything is backed up safely everyday. Every so often, we save to central and all is well. Now let's say I lose connection or my DSL goes down. Can I keep borrowing elements or will Revit realize that I'm not connected to the network and prevent me from borrowing? Does Revit keep track of the network connection? I cannot see how it doesn't...I'm guessing it's constantly writing data to the central or some other tracking file to know what's been borrowed or not. Can I now save my local file to the desktop, and save to central once I re-establish network connection or do I lose my work?

Case B: Working via VPN, with offline files being synchronized

Similar to A, I'm outside the office and my colleague is at the office. My laptop has the entire project folder available offline so it synchronizes automatically when I log to the network at the office. I log-in via VPN, work on my local file and borrow elements, and I lose connection once again. Yet, now I can still save to central as my drive letters are mapped just as if I'm in the office (I have folders made available offline, then re-mapped the drive letters and checked the "reconnect at logon" so that I always see the usual drive letters and a couple offline folders in their usual location, rather than in the single offline files window, where everything is lumped together). Even if my drives weren't mapped, the fact that the central file is available offline, I can save to it and Windows will synch it next time I'm on the network. So when I log back to the network, my laptop will synch the files and if I have a more current version, the central will be overwritten. But that doesn't mean that my central is the most up to date, it means that my central was the last saved. If my colleague made major changes and saved before me to the central file on the network, his changes will be overwritten. This could be a major disaster if, say, 6 people were working at the office and making changes, while I was working via VPN.

Depending on your responses, this will help me define a best-practices policy in our office, and hopefully others will also benefit from it. Thanks!

[dbaldacchino]

No takers on this?

[Wes Macaulay]

Case A: I expect that Revit communicates with the central file whenever you make a change, make an element editable, etc.

The instant it can't talk to the central file, Revit will tell you. You can continue to work on editable elements, but Revit won't let you sign out new ones until it can talk to the central file again. You won't lose work as long as you can save your local file. I wonder if it's possible that the local and central files could become incompatible with a process like this; then you'd have to copy data from your old local file to a new one made from the central file. But generally as soon as the central file becomes available again you should be able to STC and carry on.

Bandwidth issues will probably make this pretty slow going. You may have to re-point Revit to the location of the central file manually when switching between working via LAN and VPN since the UNC path to the central file might be different in each case? However your system works...

Case B: Yikes! Having two copies of the central file is a no-no. Your VPN application doesn't know how to "merge" the two central files, and if it always keeps the newer file it could make your local file incompatible with the newer central file, so this scenario is certainly going to be a problem.

Case A might work; Case B almost certainly won't, but try them both on files you can throw away and let us know how they work!

[Steve_Stafford]

Scenario A - Have you tried this yet? Most likely as Wes says it will be too slow. Remote Desktop combined with VPN access might be the best route to work remotely. Requires your office PC to be on so you can log into that PC and work on the project through your PC at home.

When Revit can't find the central file to lend elements to you Revit calls this "Editing at Risk". The strategy you can use for this condition is to let the other person at the office know what things you are borrowing and have them open the central file using your username and check them out to you. This way Revit will think you have them checked out and in most cases allow you to save to central later.

Scenario B - Nope...as soon as you move, copy or rename a central file it becomes a local file. Drive letters are ignored since Revit uses UNC paths.

I'd try to get very comfortable with worksharing in general before I'd tackle working remotely. Doing both out of the gate is asking for some heartache at some point.

I've recently seen some very promising results with Riverbed (http://www.riverbed.com) and worksharing.

[Wes Macaulay]

Just on Friday we were wondering if we could get our hands on some Steelheads to try out! Yeah -- these are the guys to watch for this.

[dbaldacchino]

Hey, Thanks a lot guys. Well, here's what prompted me to start this thread...

For the past couple of months, I've been working on a laptop using offline files. I traded my desktop at work for a good laptop. Anyway, until last week, I was the only one working on this project and had the entire project available offline. So before logging off at work and un-docking, it would sync the files and vice versa in the morning when logging in. So after "work", I was able to do some more stuff and especially on weekends (when you're learning something new, you have to catch-up somehow!).

Well, I've started using VPN a couple of weeks ago. Saving a 29MB file over VPN is about a 15-30 minute process on regular DSL. I still sync'd my files just in case the network or my DSL was down. Well, last week I enabled worksets for the first time and I have another team member working on this project. We have a "User" folder on the network where we keep our local files. So last weekend I worked off my local file (opened through VPN) and saved to central via VPN every so often. At one point, I saved to central and in the midst of it all, the VPN lost connection. This kinda got me thinking....what if we were both working at the same time.....would Revit let me borrow elements if I got disconnected from the network or does it constantly monitor the status of the Central file and would prevent me from borrowing? In the future I anticipate teams made up of members in different offices to be working on one job, and this scenario could apply when you have temporary disconnections in the network. I was worried about those interruptions that go un-noticed and that could cause loss of work. I'm going to try some more experiments on this with a dummy project.

Back to what i was doing....since I had my network drives all mapped and to re-connect at log-on(the offline files were thus available through these drive letters), I saved to central again, thinking that the offline central would sync back once connected. I got some error about the central file being moved or incompatible (because of the UNC I guess....instead of \\server\folder\1folder2\etc (file://serverfolder1folder2etc/)., the offline central was now at Y:\folder1\folder2\etc, just as if I was in the office). I was getting some errors, so I saved my local and then re-created the central from it (I was the only one working so I was safe). Then I re-created the locals from that to be sure all is good.

So basically, after that experience I wanted to see whether it was advisable (or not) to use BOTH VPN and offline files at the same time. I know I'll be doing work on weekends/evenings and wanted to find what was the best way to do so, as before enabling worksharing, offline files were working perfectly, but now it's a whole other world. I'm trying to find out what not to do, so I can offer some advise to our other users. And in the meantime, I stopped using offline files.

EDIT: Actually the network paths are the same on VPN as they are internally.

[dbaldacchino]

Well, I did some tests and found some interesting things.

I created a test file, saved as central and created two locals while running two sessions of Revit via VPN. I started editing in one local, then in the other and Revit kept track of borrowed elements as expected. I disconnected from VPN and tried to borrow an element and Revit didn't let me. It did offer me to check out a workset "at risk", which I did in both locals and made an edit. I re-connected and chose one local and saved to central. All was fine. The second file caused an error "File is incompatible etc." because changes were made to the same element in two locals. I undid the change in that file and tried saving to central again, and Revit accepted.

So then I tried the same thing again, this time to try find out whether Revit accepts the latest change of the two or whether it just accepts the first local that attempts a save to Central. The latter seems to be true. The first local I saved to Central from was fine, the second came with an error that the changes couldn't be reconciled. Then I tried to see if I could outsmart Revit by saving to a new local copy, quit the first local after relinquishing everything, and tried to re-save to central. No luck there either....your only option is to past your changes manually if you remember what they are, but it won't let you save to central. I guess Revit also keeps track of when something gets updated after a save to central, so that if the same thing shows up as having been changed before the newly updated element (from STC), it knows something is wrong and there's a double edit.