AU Class
AU Class
class - AU

Revit Server Round Trip

Share this class

Description

This class will cover the setup and deployment of Revit Server across 14 locations currently being used internally in production for multioffice, multicontinent collaboration. We will cover everything from planning and hardware selection to training as we complete our first year utilizing this technology. This session features Revit. AIA Approved

Key Learnings

  • Discover Revit Server and find out how will it help your firm
  • Learn how to set up Revit Server for effective work sharing
  • Learn how to select hardware and configure sites
  • Learn how to train users and discover backup strategies for Revit Server

Speaker

  • Matt Krebs
    Matt is a highly motivated BIM Manager for Thornton Tomasetti, a large structural engineering firm headquartered in New York City, New York. He has expertise in Autodesk® products 3ds Max, AutoCAD®, AutoCAD® Architecture, AutoCAD® MEP, Navisworks®, Revit® Architecture, Revit® MEP, Revit® Structure. Matt's responsibilities include managing the customization, deployment, development, documentation, implementation, support & training of all Autodesk® products within the firm. Matt has also worked with several project teams to ensure that models are accurately modeled for coordination for Navisworks® usage. Prior to joining Thornton Tomasetti, Matt worked in the Autodesk reseller channel as a BIM Implementation Specialist to guide multiple firms' Building Design Suite adoption and implementation. He is based in Thornton Tomasetti's Philadelphia, Pennsylvania office.
Video Player is loading.
Current Time 0:00
Duration 0:00
Loaded: 0%
Stream Type LIVE
Remaining Time 0:00
 
1x
  • Chapters
  • descriptions off, selected
  • subtitles off, selected
      Transcript

      MATT KREBS: All right, can everybody hear me now across the microphone? All right, good. All right, so well, good morning everybody. How's everybody doing? Third day of AU, I'm just glad to see that some of you guys are still standing. I don't know about you, but it's wearing on me a little bit.

      So welcome to IT15537. This is Revit Server Round Trip. My name is Matt Krebs. I'm the Design Technology Manager for Thornton Tomaseti. We're about a 1,600 person structural engineering firm spread all over the world. And this class is essentially a reboot of a class that my supervisor and I gave four years ago when we'd just finished up our pilot project for Revit Server.

      So we're basically building on that and then going through our experiences that we've had with Revit Server and going through some of the successes that we've had. So with that, let's just go ahead and get started. All right, so class summary, get this stuff out of the way. So this class is going to cover the setup and deployment of Revit Server across 16 office locations. It's currently being used for production work for a multi-office multi-continent collaboration.

      And in this class, we're going to go ahead and cover as much as possible, and try to cover specific information as far as planning out your hardware, your network deployments, or your network setups, training, and et cetera. And as I mentioned, we'll go through some of the successes that we've now had through our fourth year while utilizing this technology.

      So learning objectives. By the end of this class, hopefully-- hopefully-- you would have discovered the Revit Server application and the ways it can possibly help your firm. You learn how to set up the Revit Server application for effective work sharing. You learn how to select hardware and configure said hardware, and learn how to train users and some different backup strategies that we've enabled, and we've had success with. So.

      And this is just kind of a brief outline of the agenda that we'll try to cover today. I'm going try to cover this in about 45 minutes to leave about 15 minutes for Q&A session. I know that's how much we needed last time that we did it. But in general, we're going to go ahead and cover and introduction. Just about why we needed Revit Server, who we are, what we do, that kind of stuff-- some of the old methods that we used to use prior to Revit Server.

      The solution, which in this case is Revit Server, how it operates, how it works, that kind of stuff. How to set it up, how to work on it, how to set up local machines, how to administrate and manage the data on Revit Server. Again, I mention the backups, and then training and support as well.

      So whenever I do these classes, I try to get a pole or an idea of the kind of people that I'm working with. How many of you guys would be under pseudo IT window? I mean, I would consider myself under pseudo IT manager, or IT window. All right. How many of you guys are engineers or architects? How many of you guys have Revit Server? Wow, more than I thought. All right cool.

      How many of you guys are interested in Revit Server? All right. Good. All right, general questions out of the way. So with that, let's go ahead and just go into some of the instruction stuff. So let's start off with who we are. So how many of you guys have heard of Thornton Tomaseti before? Well, then this slide is kind of self-explanatory for some of you guys.

      But this is actually my supervisor's favorite slide to throw in every single presentation that he ever has. And it's basically just a concept of showing you that we aren't typically going through and doing three-story, single-story office buildings. We're working with some of the largest data sets that you're going to have to do. I mean, we specialize in stadium and super tall. So as you can tell, it's going to be some pretty complex geometry and some large, large data sets.

      So we aren't using Revit Server for those smaller things. You can see several stadiums throughout here. And then, in the lower left hand corner here is what has been dubbed the TT Skyline, which is just kind of a group of towers that we've completed, and we've used Revit Server for several of them. And then, it boils down to where we are, which is really what fueled our need for some kind of collaboration across the WAN, some kind of solution for that work.

      We have 35 total offices. Sorry, I'm still adding up all of them. We just had a recent acquisition that added a whole new handful of them. But we'll have 13 here in the United States-- or 23 here in the United States-- I'm sorry-- and then, 15 international offices. Our heaviest users internationally are going to be our London and Mumbai offices, which are going to be featured throughout this demonstration, as well as several offices in the United States.

      All right, so what really happened to cause a need for Revit Server? And for us it was what we call the big shift, which is when we went ahead and moved from AutoCAD drawings to Revit. Now, the main difference between these two platforms, or the main difference for us, was really the file size change. Your typical AutoCAD drawings, you're working with files there are in the hundreds of kilobytes, which is average size.

      But then, even on your large drawings you're probably looking at what, 5 megabytes as a large file? It's not that bad to deal with. Now, when you start to go over to Revit, all of a sudden you're dealing with files that are in the hundreds of megabytes. And you're experiencing all the issues that that's runs wild with on your WAN.

      So this is actually an internal marketing scheme that we used to sell the feature of Revit to our shareholders. And one of the selling features, oddly enough, was that we were moving away from all of these small little files that were easy to manage and share all over the place to one consolidated database of information. I just find it kind of amusing that now we're trying to find solutions for something that we're actually billing as a selling feature of the software.

      So now with that being said, let's go ahead and talk about some of the old methods that we used to experience when we were trying to share this-- these types of files. And the first thing that we had to do was try to plan these projects appropriately. That was step one in trying to accomplish the task of sharing these across multiple offices. And that involved creating best practices. It involved creating model planning techniques to try to break these models up into more manageable chunks.

      Specific linking schemes to make sure that when we sent these files to other offices that they would actually be able to use them. And it also involved technology road mapping to highlight what offices had relatively stable connections, while some offices were a little bit more laggy and would have issues just opening these files across the WAN.

      Now after that was all complete, what we would then go through and do is we would use good old Winzip to kind of transfer these files from one place to another. So we would go ahead and take all of the Revit models, all the linked in models, throw them into a ZIP file, shoot to them off to whatever office that they need to work on. And then, the other office would unzip them, re-link them, re-path them, repeat that process over and over again. Rinse and repeat, rinse and repeat.

      All right, so it wasn't exactly ideal. And it's actually kind of led to several corruption issues, mostly due to impatience for some of our users. Before the fire was done copying, they would already try to extract these files. And that's never fun for anybody. So it didn't exactly work out as we planned. Which led us to develop our own tool internally. The ultra unique name of the Revit Project Transfer Utility was a quick VB application that I threw together when I actually first started at Thornton Tomaseti.

      And it was basically a way to send these files from a location from site A to site B without the user have to really do it themselves. Essentially, the application worked as a simple copy process and logging it where users in site A would browse to the files that they would like to send. They would select the office that they would like to send them to. And then, they would transfer them.

      Basically it would go through, it would copy those models from site A to site B, mark them as read only so that people in site A would no longer work on them. And it would also rename them so that it was blatantly obvious that these were located in a different office now. And then it would log this transaction with the username and a time and date stamp, as well as if it was a success or failure-- just so that if you ever did need to know who transferred what when, you'd have a log of it.

      And then, when the work was done the users in office B would then just return those files. It would go ahead and copy them back over, delete the existing ones that were marked as read only, and we would have the files back in site A. And it would log that transaction as well. Now, this really didn't change anything. However, what it did is it added a standard methodology to our practice.

      So rather than everybody doing whatever they felt like doing, whether it was just copying them manually, Winzipping them, or whatever other method that they decided to cook up in their head, at least we had some kind of a standard process. And It's kind of a stickler, just a big detail for me. I'm kind of a stickler for standards and some kind of just standard process because I believe that if you have a standard process you can always improve upon it. But you have to have some kind of a process.

      Now unfortunately, this didn't solve the issue which we were experiencing, which was the amount of buildup time it actually took for users in each office to get these files up and running. We're transferring all of these files all the way across the network, and it's not recreating them in the central files, so multiple people still can't work them. It's just looking at them as detached copies. So every single morning somebody would need to go in, open these files, re-save them to central, then re-link all the links.

      So you're looking at a three hour lead time before anyone could even work in these models, so it was just a lot of waste. And this brings us to the solution, which in this case is Revit Server. Just kind of the standard line-- Revit Server is a platform that helps accelerate models across a network. Our primary use for it was inter-office model sharing. However, we do have some offices that just like using Revit Server and put all of their projects on there in the event that they may want to share it at some point.

      And then, just a quick note. How many of you guys have heard of C4R? All right, I'd be surprised if you hadn't just yet. But essentially, it's Revit Server in the cloud. And we typically use that when we're dealing with external consultants that want to work in a more collaborative environment. There are methods to open up, say a VPN tunnel between Revit Server networks. However, we find that C4R is just a cleaner method of enabling work sharing between multiple firms, so we try not to do that too much.

      All right, so what you're seeing here is you're seeing a quick outline or a quick sketch of our pilot system, our pilot project for Revit Server. It involved placing a Revit Server in each of our largest US offices-- our two largest US offices in New York and Chicago-- and also in our two largest international offices, which were Mumbai, India and London. And then, you see this little one for PA, for Philadelphia. And I think that's just because that's where I'm located. So I'm a little special and got my own Revit Server.

      And this also demonstrates our naming a schema. We tried to follow a simple naming schema that would enable users to understand what files they were accessing and in what location. So we used basically a copy of our existing server naming scheme and replicated that for our Revit Server network. All right, so now just a little bit about-- well, for you guys that actually have Revit Server this may be a little bit redundant. But just a general scheme of how Revit Server works.

      So let's say that we have a Revit file, a Revit model, in our New York office that needs to coordinate with a user in our Mumbai office. Now, in a typical scenario without Revit Server, this user is going to go ahead and try to open that file-- either open that file all the way across the WAN, which as you know is going to be a disaster for everybody and everybody's going to have a bad time. Or they're going to have to do what I said before about relocating that project after hours for that user to work on it.

      Now, what Revit Server does is it takes that process, and rather than having a user communicate all the way across the WAN to New York, Revit Server, or the user in Mumbai, will browse to the New York Revit Server and open that file. Now, unbeknownst to the user, what Revit Server will do is it'll then create a cached version of that model on the Indian Revit Server, on the Mumbai Revit Server. And then it'll communicate back and forth with small little packets of data-- which, again, invisible to the user.

      He is simply synchronizing through his local accelerator, which means that he's only looking at the server in India. He doesn't necessarily need to save all the way across the WAN. Now let's go ahead and just take a look at some of the more nitty gritty details of how this operates. So for this example, let's say that we have a 20--plus megabyte model. If we take a look at-- this is the Revit Server administrator, which is going to show you some granular data on who's working on what projects and when.

      If you take a look at some of the information that's stored inside of this dialog box, you'll see starting from the right hand side that there is a Support Files column right next to the Model Size column. Now the benefit of Revit server is that it's not sending the full model size across the WAN. It's simply communicating via the support files. So it's only actually communicating with 87 megabytes of data, rather than the full 205. So you're working with about-- less than half of the actual data.

      So now, if you were to, in Revit Server, in the Revit Server itself in Windows Explorer, browse to the actual project location-- the first thing that you'll see is that these actually aren't Revit files at all. This was actually a little shocking for some of our users. They would actually browse to these locations and see that they're really just these folders, and they couldn't just grab these files out of there. More granular detail, if we go into there and then go into the data folder, you'll see that it's housing just these .rws folders or files, which when you actually take them and add up all their sizes, amount to the support files that are being passed back and forth.

      So these are the files that get consolidated from the accelerator to the host model in the host location. So again, just kind of recapping general concepts, when you work without Revit Server, you're taking a Revit model, and you're pushing it all the way across the WAN. And then, you're pushing it all the way back when you go out and sync. And it's doing its whole thing.

      Now, when you use Revit Server it's sending more granular data across, creating a cached version of that model. And then, it's communicating in that same methodology back and forth. Now, Revit Server has been very successful for us. However, when we tried not using Revit Server-- well, you get the idea.

      With that being said, let's go ahead and start to go into some more of the nitty gritty information when it comes to actually setting up Revit Servers. So for us, we want to go through our main considerations when we are setting up these. And it involves the actual physical hardware selection with Revit Server, the storage location and size, our speed, latency between sites, and our Riverbed Acceleration. Now, we had already had in place Riverbed boxes in each of these offices to actually try to improve just the basic WAN performance of Revit.

      And unbeknownst to us that actually helped increase the performance of our Revit Server network. It was actually able to utilize that box to speed up its own connection. So it really did come in handy, and it was kind of a happy accident for us. One thing I do want to point out is that we decided internally to move forward with dedicated servers in each location. I know a lot of people move forward and try to use virtual setups, virtual servers.

      For us, one, there was a cost issue of trying to set up VMs in each individual office. And additionally, when we were setting this up back in 2014 we did hear that there were some issues working with Revit Server on virtual machines. So with that in consideration, we decided to move forward with dedicated boxes. Again, also, another little side benefit is it allowed our Revit Server network to really only need to pass back and forth Revit Server information.

      Whereas our, standard file systems would handle all of the other weight of all the Word documents, and calculations, and ETABS models, and et cetera, et cetera. And basically, this allowed us to create essentially a high speed corridor. For those of you not from the East Coast, 95 is the road to goes straight up the East Coast, the fast road. It's bad a bad example for some people, but for us it works.

      All right, so more specifics. Right off the bat, we decided to move forward with a Dell R520 rack mounted server. Again, if you guys have access to the hand out, all of this information is in there as well. Each one of these servers had two 2.2 gigahertz 12 core processors, 32 gigs of RAM, dual gigabit network interfaces, an on-board graphics card, and two partitions. One, the C: drive, simply to house the OS, and then our D: drive, which was actually 6 terabytes-- a little bit overkill-- but 6 terabytes to actually store the cached data and the hosted models.

      And at the time, this number may have changed, but at the time this averaged out to about $6,500 per site.

      AUDIENCE: On the graphics card, how much memory from the graphics card?

      MATT KREBS: What was that?

      AUDIENCE: How much memory from the graphics card?

      MATT KREBS: I'm not sure. The actual Dell order is on this handout. I think it was one of the things that I had in there, and it-- What was that?

      AUDIENCE: I was concerned about the [INAUDIBLE].

      MATT KREBS: Yeah All right, so now that we've gone through the hardware specifics, let's just go through some of the basic setups for the software. Now this bullet point list is going to make it sound really, really easy. And it starts with just going ahead and enabling your prerequisites, which mostly is your IIS manager. That's going to be very important that you install on your servers.

      Now after you enable this service or this task on your server, you're going to have about a million restarts, which is a little bit of exaggeration. But last time that I did it I think it was about 12 restarts to make sure that Windows Update actually updated all the way and there was no more pending updates. Then it comes down to acquiring your Revit Server media, whether that be from a download or the actual media you already possess.

      And then, installing Revit Server, which consists of actually agreeing to the end user license agreement, configuring your options, configuring your roles-- which we'll go ahead and discuss in a little bit-- and then configuring your storage locations. And then that's it. You're done. Makes it sound really easy, doesn't it? You had your hand up?

      AUDIENCE: [INAUDIBLE].

      MATT KREBS: This stuff is all in the handout as well if you want.

      AUDIENCE: Yeah, thank you. Thank you so much.

      MATT KREBS: No problem. So as I mentioned, let's go through some of the roles. So there are more technical explanations up here from the Autodesk help file. However, the three roles that you're going to have the options to set up on each individual Revit Server are going to be a host, which allows you to actually store Revit models and save Revit models to that location. You have the ability to choose to enable acceleration, which allows you to store cached versions of said Revit models.

      And then, you have the ability to enable the Admin console, which allows you to have the web GUI that allows you to manage the data for any given Revit server. Now for us, we enabled all three roles on all of our servers because we really want to replicate our existing file storage system and allow each individual office to be able to store their own project information-- while also letting each individual office act as an accelerator as well. We really wanted to kind of replicate the same system that we had in our standard file system and not control it too much. Yeah?

      AUDIENCE: According to what you said, you had non-Revit, non-essential type files are using the [INAUDIBLE]?

      MATT KREBS: Oh no, they have to be central files. Revit Server will only allow you to save central files.

      AUDIENCE: How will [INAUDIBLE]?

      MATT KREBS: They still exist on the standard file system. And in those situations most of the time we'll still end up sending those files from point A to point B.

      AUDIENCE: So we're not using the Revit on a separate server?

      MATT KREBS: No. And I mean, in reality, we have minimized the amount of DWG links and non-Revit links that we've had that we use. Most of the time, if we are using links, they are provided by an external party. We don't really do our own internal links anymore.

      AUDIENCE: And you're going to have a separate folder for that?

      MATT KREBS: No, no. we put those in the standard project folders, and they'll just link those across. Because again, those file sizes are going to be so much easier to manage than-- so it's really not that bad to go from--

      AUDIENCE: You can't put them on Revit Server. You have to put them on--

      MATT KREBS: Yeah you can't actually save them to Revit Server.

      AUDIENCE: You sau you setup each center as a host so they control their own [? prep ?] room?

      MATT KREBS: Yes. And it actually partially ties into our backup procedure, which I'll get into a little bit later. But yes, each office is its own host. Again, the idea to replicate because they each have their own storage location for their standard projects. So we didn't want to venture too far out of that norm and make them feel like they're saving it to an office that's better than them. People are very finicky. Yeah. Yeah, nobody wants to feel like they're reporting back to the mothership, so we let everybody save it on their own server.

      Now, let's go ahead and talk about some of the basic setup procedures for your Services Security when it comes to Revit Server. So this is going to be just a collection of screenshots. But essentially, what it boils down to is, if you look at the upper left hand corner, the first thing after you install Revit Server is that you're going to notice that there is a Revit Server auto sync for each version that you set up.

      And this is what enables files to act as an accelerator and push the files back and forth. So it's very important to make sure that these are always-- they're set to automatic and started. Otherwise, your Revit Server isn't going to be behaving as it should. Below that is going to be your IAS application pools, which actually represents, again, your Revit Server infrastructure. Always make sure that those are started.

      Now, skipping over the INI for right now, all the way to the right hand side, your firewall settings. You're going to make sure that you open up port 808 completely. That is what Revit Server uses to push traffic back and forth. So it's very important. Otherwise, you're going to run into some latency issues. And then finally, after you've done all of that, the most important part is to set up your Revit Server INI, or your rsn.ini file, which exists in the install directory.

      For us, that was C:/programdata. And inside of that config folder is, as I mentioned, this rsn.ini, which is a file that can be read in any text editor. For this, we just used Notepad. But essentially, it allows the server to know what other Revit Servers it can communicate with. Now for us, because we want it to have a fully collaborative environment, this always has every single Revit Server that we have. We just go ahead and deploy that all the way across.

      And it also helps make sure that when we distribute the individual rsn.ini files to local machines, which we'll talk about in a little bit, that they all match. So it's just one ini file for everybody and every server. Just makes things easier for us.

      All right, as I mentioned, local machine setup. For us, it really involved using group policy. How many of you guys you use group policy internally, startup scripts? Yes. That's what we use as well. And really, again, this just kind of pieced right into that for us. So what we did was we went ahead and created a small C# script that essentially accomplishes the following tasks.

      So it'll go through and, on each startup on each machine, it will obtain the versions of Revit Server installed on each machine. It'll verify that those Revit Servers actually exist. And then, it goes through, it replicates the rsn.ini from the master directory to make sure that they have access to it. Then, a little trick, is it goes through and it actually monitors the log-on server-- so the domain controller that it actually is tapping into when it's starting up.

      And what this allows us to do is it allows for our mobile users that are bouncing between offices, our higher level employees that have laptops-- so if a guy from New York goes to Chicago for a week and he's going to work on a project, rather than him still being connected to the local accelerator in New York, as soon as he plugs his machine into Chicago and starts it up, it recognizes he's in Chicago and change his accelerator to match that office. And as I mentioned, it does that by adjusting the environment variables inside of each individual machines.

      And again, it allows it to change per user, per login. So with that, let's go ahead and show just some of the screenshots as I mentioned. There are system variables. So inside of the Environment Variables dialog box is one way to control all of this. And that's how we went ahead and did that with our startup script. However, if you do need to control this manually, the easiest way to do it is inside of Revit.

      If you go to the Collaborate tab, choose the pull down menu underneath it, Synchronize, you'll have the ability to select Manage a Connection to a Revit Accelerator. And then, you can just manually type in that value of whatever Revit server you'd like to connect to in this dialog box. In addition to environment variables, it's also stored in the registry editor. And that's shown in the upper right hand corner.

      If you do make a change for the value either in Revit or through the system variables, it does replicate down to the registry. So you don't need to change that manually. It just is replicated from those two locations. Now after-- or I should say the ini over on the right hand side, as I mentioned, that's copied down locally every time just to make sure that everybody is up to date at all times.

      And after you've copied that ini into the local directory, which again, is in C:/programdata/autodesk/revitserver, down that line, then in the config folder as soon as that file is copied in place, people will have access to the Revit Server network within Revit. Which is either available from the Look In pull down in the Open dialog box, and it also puts a shortcut in your Favorites to easily access the Revit Server. Now after you go ahead, it operates in the same manner. You just go ahead and browse where you need to browse.

      So a little bit about Revit Server administration. I kind of showed you a quick screen grab before. But really, there are three main tasks that you're going to be operating or doing inside of the Revit Server administrator. You're going to be creating or editing existing-- or creating new projects or editing existing projects. You're going to be deleting projects, or placing locks on models or folders.

      Now I know that the Revit Server administrator has like six icons, but those are basically just your Copy, Paste, Cut commands. These are really the three main tasks that you're going to be able to do. It's a pretty straightforward dialog box. So I'm not going to spend too much time on it. All right, so permissions. This is actually a happy accident discovery by us in later versions.

      But essentially, if you do want to control who has access to the Revit Server Administrator, you do have the ability to do that. Now, the one caveat is that it is a server level restriction. You can't do it for individual projects, which for some people in our office, was kind of a downer. They wanted to be able to control individual projects. But unfortunately, Revit Server just doesn't have that level of permissions.

      So just kind of how to do that. So inside of the IIS manager for the given server, if you expand the default web site, if you scroll down in the list you can see this in the right hand-- or the left hand-- screen grab. You'll see that you have the Revit Server Admin for whatever versions that you have installed. Now, if you were to select that in IIS manager and then select the Authentication option, there's a couple of things that you need to do.

      First, you'll need to go ahead and disable Anonymous Authentication. And then you'll need to enable both Basic and Windows authentication. Now, the reason that we went through and did this is because getting into the Administrator is actually a lot easier than you would think. If you know the server's DNS name, it's really just backslash, backslash, server name, Revit Server Admin whatever year. So if you don't trust your people to not delete and mess with other people, or you're afraid that you're going to have a vengeful employee on the way out the door, maybe you do want to enable some of these security settings.

      But after you enable the authentication options, if you were to then select the Revit Server Admin node on the left once more, and then go into the Authorization Rules option, by default the only entry that's going to be in there is the All Users. And it's going to be enabled. Remove that, and then you'll be able to add your own authorization rules, whether it be individual users or groups of users. But we did that's simply because, yeah, we didn't want people just poking around and creating their own projects without our knowledge.

      So we kind of locked that down. Again, specifically, really because of our backup techniques. And I'll to get into that specifically in a little bit.

      All right, so how to work on Revit server. This is actually probably the quickest section out of all of them because it's pretty much the same line repeated over and over again. So how to open a model. It's the same exact process as to open up any other model. It's just a different location. So you go into Windows-- or you go into Revit, not into Windows Explorer. You use the Open dialog to just browse the Revit Server, browse to whatever file you want to open. That's it. It's done. Same process, different location.

      All right. And using links, again, same line, same process, different location. And you'd be surprised at how many people we actually need to explain this to. You just browse the Revit Server, choose is the model you want to link in, and move forward. Again, just a little caveat. You need to make sure that these are work shared enabled files, for those of you that don't have Revit Server. You actually don't have the ability to even save non-work-shared-enabled files up to Revit Server.

      And then, overwriting a model. Now this was a big hangup for a lot of our people. And it's basically because you do not have the ability anymore when you use Revit server to simply browse to a location and copy and paste files anymore. You unfortunately need to go through Revit to actually save these files up there. And you're presented with the following dialog box whenever you do want to overwrite it, which is basically just asking you whether or not you actually really mean to overwrite this file or not.

      And after you've gone through and done that, if you were to look in the Revit Server Administrator, you'll see the entry for that specific sync with, just in brackets, auto replaced. So just something to keep in mind. Now, for us that was a really big issue, especially when you're receiving gigs and gigs of consultant models on a weekly basis.

      And there is a way to go through and, in the API program, an upload tool, which we have a small group of programmers on staff that actually helped us with that one and created a little plug-in that allows us to batch upload files to Revit Server. So it is possible. I don't speak that language. So I don't know how, but it is actually possible through the API.

      All right, and then eTransmit In the same vein as not being able to browse to these files and simply grab them or overwrite them was sending them out to additional parties, sending them out to our consultants, which is where the eTransmit plug-in came in really handy for us. Just a little caveat. This is a subscription plug-in. So if you're not on subscription you might not have access to it. But we've found it to be very useful for our workflow, simply because it allows us to simply browse to Revit Server and select the model or models that we'd like to actually transmit.

      And additionally, that does have some nice little cleanup features, and the screenshot on the right kind of gives a preview of just what we usually like to do, which involves purging and auditing the models, and then removing any views that aren't on sheets. It just reduces the file size when we send it to external clients. And we've actually started to ask our consultants and the other people that we work with on teams to make sure that they use-- or not make sure-- but if they can use the eTransmit function to send these models, do so.

      Simply because it just reduces the amount of files, or the file sizes of the files that we need to throw on Revit Server. Just makes life easier for everybody. So as I mentioned, let's go ahead and get into some of our backup techniques. You actually have multiple options when it comes to backing up. One is much better than the other, I will say.

      So the first one is just doing a manual Save As, which as you all may expect, would be very painful when you have a large model, especially if any of you guys are [? MEP ?] guys, I know you guys end up stacking up quite a few models. For us it's not as bad, but yeah, you can either do that-- or you can use the command line utility, the revitservertool.exe, which is actually installed in every single version of Revit Server that you install. And as I mentioned, it's a command line utility that allows you to create local backups of a given file at any specified location, which is what we utilize.

      Woop, got to watch this microphone. So what we did was, again, we automated this process by using C# or Visual Basic. You can really do it with batch files if you really wanted to. But essentially, on each Revit Server we created a copy of what we call Revit Server backup.exe, which again, as I mentioned, is a custom VB.NET application that we made for our file system. And then we assigned it to a scheduled task at 3:00 AM local time for each individual Revit Server.

      So that way we're not interrupting middle-of-day production work just to back up these models on a regular basis. And basically, what it goes through and does is for each project it creates-- or I should say before, and why we wanted to lock down the permissions on the Revit Server Administrator so that only we could create projects-- was to create this backup mapping file. And this is basically the key to our backup infrastructure.

      It's basically a text file that shares the same exact name as our project folder on Revit Server. So in this case the text file's name is l13075.00. It's the same name as the project folder on Revit Server. And then, inside of the text file is simply the location of the actual regular file server project location. And that's basically where we're going to back up these projects, these models to. Because the biggest concern that we had from our user base when we were starting to move to Revit Server was, what if it breaks?

      No matter how much we reassured them it wasn't going to break, they were convinced it was going to break. So for us, we wanted to make sure that we were putting redundant copies of every model on a standard file system so that in the event that it did fall over, and everybody lost their local files, and the end of the world happened-- that they'd actually have access to their data. And as I mentioned, it does it every day at 3:00 AM, which then gets rolled into our standard nightly IT backups.

      So they can just pull a version from whenever that they want if they need it. And it also helps for projects that have to get rolled back because you actually don't have the ability to do the rollback function when it comes to Revit Server. So it's just kind of like a standard built in fail-safe for us. Now, with the paths stored in those txt files, our custom application would perform the following steps.

      It would first go through and obtain the project numbers and model names from any folder that actually was named Revit Server with a year. So basically, at this point it searches through the storage location for any folders that are named Revit Server 2000. We basically future proofed it until the year 2100. So I think we're safe.

      And then, using RevitServerTool, it would then search through each of the projects in that folder and grab anything that had the rvt suffix inside of the structural folder for us. Because we actually aren't going to go through and back up consultant models because that's not our responsibility. So we're not going to do that. And it would grab those files, and then it would create local copies in the given directory based on the txt file every single night at 3:00 AM for each of those files.

      So that's basically how that would go through and create those backup files. And then, it would also go through and log the completed and failed attempts just to make sure that we have a consistent log of what is going wrong if anything is going wrong. But yeah. All right, now just a quick little blurb on training and support.

      So when we started rolling this out, there were a lot of apprehensive users just because of-- well, it's new. So of course everybody was a little apprehensive. And what we did was we actually did-- at the time, we only had, I want to say 12 US offices. So we actually made the pilgrimage to each of these offices and gave a lunchtime learning presentation to each office on how to work with Revit Server, and then the extra fail-safes that we had in place.

      And then we also created a video of that session, posted it on our internal intranet. And then, we also created a standards document and a quick start guide. Basically, we gave them as much information as they could possibly ever need, and probably a little bit more, just to make sure that they were comfortable with the new system. Now when it comes to support, it always boils down to your BIM subject matter experts, which in this case is me.

      So I became the master, de facto master, of Revit Server. And my inbox hated me for it. And then, we trained our IT department staff for some of the basic procedures that they might experience, whether that be opening the model not working, not being able to see the Revit Server network. And most of the time it just boiled down to telling them to restart their damn computer for the first time in three months.

      So that really kind of put that down. And then, it was also who to call when a server goes down. So basically told them to just call us if anything goes wrong. And honestly, so I know I kind of flew through that one guys, but that is kind of it for me. So if you have any questions, I'd be more than happy to answer them. But before we do that, just I would appreciate if you guys go through and do a survey. They help.

      Last year, I actually had-- or when we first gave this presentation, I had a zero star review. And the review was-- didn't realize this class would be on Revit Server. I'm never going to use this. So if you're in here by accident, don't give me a review. Thanks. And yeah, that's it. So if you have any questions, I'd be than happy to have them. Yeah?

      AUDIENCE: Here's-- how many [INAUDIBLE]?

      MATT KREBS: What was that, I'm sorry?

      AUDIENCE: Revit has a lot of [INAUDIBLE] in our files?

      MATT KREBS: Yes.

      AUDIENCE: [INAUDIBLE] how it is helping because different builds are giving us correct result on Revit Server?

      MATT KREBS: Now all your machines have the same build, or no?

      AUDIENCE: They are a little bit different. So is there any data loss?

      MATT KREBS: We haven't experienced that. We roll out, again, our updates via group policy as well, not via startup script, but actually through group policy deployments-- because it is kind of a well-known thing that if you have users that are all different builds of Revit, you're going to experience more than just issues with Revit Server. You're going to really start to see stability issues across the board when it comes to Revit. So I can't speak to solutions for that, other than saying make sure that everybody's on the same build, unfortunately.

      AUDIENCE: What is the efficiency?

      MATT KREBS: Yeah, same for C4R.

      AUDIENCE: What is the efficiency between your Revit Server versus the C4? Oh my god, I am clicking two extensions, for example, two offices, and we need maybe 15 [? grams ?] in the two offices.

      MATT KREBS: Yeah.

      AUDIENCE: Same with the 15 mainly have 10 users for C4R for $8,000.

      MATT KREBS: Yeah.

      AUDIENCE: Pretty even. Do you see a like a kind of--

      MATT KREBS: I know what you're talking about. Basically, where does that cost benefit ratio tip over to Revit Server? Now for us, all the offices that we went through and did in our pilot project were 50-plus users. And C4R wasn't around, so that also helped. But basically, it still works out to where the math-- you know, $700 at seat, $800 a seat for C4R in a 50 person office, versus $6,500 for a Revit Server. The cost benefit for us was easily on making sure that we implement Revit Server

      It just made more sense for us. And then, we had such a resounding success with it that we just made it part of our standard office build at this point. Saw some over here first. I'll come over for this side next. Yeah?

      AUDIENCE: Can you tell me if it's first time that you have accessed the files through Revi Server across offices-- --takes a little bit longer time to access the file--

      MATT KREBS: Yeah, it's the creation of the cache basically. It takes a little bit.

      AUDIENCE: Yeah. Especially if there's a lot of vin files?

      MATT KREBS: Yeah.

      AUDIENCE: But what we've know is when you start saving backups, it's not as bad.

      MATT KREBS: Yeah.

      AUDIENCE: [INAUDIBLE] back, there's also a lag time? Is there any benefit because we don't have Riverbed. Is there-- from your experience, did the Riverbed help out on that?

      MATT KREBS: It definitely did. For us, it absolutely did. We actually-- in, I want to say, our Vietnam office, installed the Revit Server before the Riverbed simply because we couldn't get anybody out to install the Riverbed before. And we had somebody actually in the office to install the Revit Server. And we saw a drastic increase in performance after the Riverbed was installed.

      Additionally, we started structuring our models a little differently to where we placed all links on specified work sets, and then had users that were opening it up for the first time not open up those work sets. And essentially, it cut down the actual cache speed and only allowed them to cache their model first. And then, on subsequent opens they would open up one work set at a time. So they're really only creating a cache.

      AUDIENCE: That's why.

      MATT KREBS: Exactly.

      AUDIENCE: THE other thing is like [INAUDIBLE] doesn't have the same fast speed as we have in LA. So [INAUDIBLE].

      MATT KREBS: As long as the ping times are under 300 milliseconds, we see ideal performance. Once it ranges above that, we start to see a little bit of shake, which is where those specifying work sets and all that kind of stuff really starts to come in play. And right now, that's only isolated to our Vietnam office just because the internet there isn't exactly the most stable.

      So for the most part, we've seen it's pretty good. But that 300 mark that, 300 millisecond mark, is kind of our magic number.

      AUDIENCE: Can you email me with something else--

      MATT KREBS: Absolutely. If you want to have cards up here, or my email is on the presentation. Just, yeah, if you have any questions, please email me. And I saw a question back here next? Yeah, back in the corner I think.

      AUDIENCE: So I know you started off with the talk about VM [INAUDIBLE].

      MATT KREBS: Yeah.

      AUDIENCE: So what [INAUDIBLE]?

      MATT KREBS: Well, we didn't actually even drive VMs. We didn't have the infrastructure for it at that point in time. And this was back in 2014, and 2013 had known issues with working with VMs. So at that point, we didn't know that it was going to get more stable for VMs, so we just specifically moved forward with this. And I mean, it's much more expensive to get a VM box set up in individual offices than it is just to get a rack mounted server.

      So really, it was effort time and cost. And it's still effort, time and cost for us. It's not as much about the stability issue anymore. It's really just for cost. I mean, we have set up a few private Revit Servers for individual projects that need that level of security on VMs. And it's pretty good, but those are limited in their scope. So we're not putting giant models like that on that. But--

      AUDIENCE: So security-wise, people want to [INAUDIBLE]--

      MATT KREBS: Yeah.

      AUDIENCE: People are classified [INAUDIBLE].

      MATT KREBS: Oh, that's a nightmare. I can't stand that stuff.

      AUDIENCE: Oh, I'm really--

      MATT KREBS: Sorry, sorry. I kind of let my passion out a little bit there.

      AUDIENCE: [INAUDIBLE] just find it a little [? loss ?] here and there--

      MATT KREBS: And it drops the connection regularly and stuff like that?

      AUDIENCE: I haven't seen [INAUDIBLE] weird things like IS [INAUDIBLE].

      MATT KREBS: Yeah, I've seen that as well. We did it on one project, and that project moved away from it after about six months because it was just not stable enough. And there were just these weird little quirks that would just spring up, for no reason either. Like nothing changed. All of a sudden, it would just fall apart. Yeah.

      AUDIENCE: [INAUDIBLE].

      MATT KREBS: Yeah, it's miserable. But so clarity?

      AUDIENCE: [? Management. ?] We need security--

      MATT KREBS: I was going to say, smile and a nod. So I'm assuming he's in the same boat that I am. But so basically, for that level we actually, for that level of security for some of those projects, we control access to the individual Revit Servers via-- I know it's not exactly the most ideal thing, but it's an Excel file that's locked down in a secure location that has a tab per specific project. And we basically keep track of individual machine numbers.

      And we built an additional little thing into our startup script that basically looks at that file and will add that secure project server's name to their rsn.ini based on the entry inside of the Excel file. So that's what we did to kind of lock that down a little bit more. Yes?

      AUDIENCE: Have you considered using [INAUDIBLE] the way you can get rid of Riverbed?

      MATT KREBS: For us it was a cost issue again. For us, it was a cost issue again. We actually just implemented Nasuni, which is a competitor of Panzura. And it's a much lower price point. And we just weren't sure as to how much we would take advantage of Panzura, especially with-- we were approached by Panzura after we had already set up our base Revit Server network. So again, it was like we have this money already invested in a Revit Server network.

      Do we then scrap it and move to something else that we aren't sure is going to work? So we decided to move and stay with Revit Server.

      AUDIENCE: Do you have concerns like I do with Autodesk not continuing to support Revit Server?

      MATT KREBS: After their servers went down on Friday, no.

      AUDIENCE: OK.

      MATT KREBS: And also, the fact that I'm actually able to give this class kind of also says no. If they really were kind of pushing Revit Server off to the side, I don't think that they would allow me to give a class on Revit Server, personally. Yeah?

      AUDIENCE: So currently, you do have SteelHeads in--

      MATT KREBS: Each office location.

      AUDIENCE: --each office location. And you have a server in each office.

      MATT KREBS: Yes.

      AUDIENCE: [INAUDIBLE].

      MATT KREBS: What was that?

      AUDIENCE: You have a server in each office in addition to--

      MATT KREBS: The SteelHead.

      AUDIENCE: Your SteelHeads.

      MATT KREBS: Yes. We put SteelHeads in beforehand to try to help with just overall WAN speed. And Revit Server just kind of added on top of that basically.

      AUDIENCE: Right. So because [? I know in ?] my own you're talking to some of the folk in Riverbed, they say you don't need a server in each office. You could just use your SteelHead. But I still kind of get why we would all want-- still want the server.

      MATT KREBS: Just that little added extra security basically.

      AUDIENCE: --is a warm fuzzy thing.

      MATT KREBS: It is a warm fuzzy thing. It's absolutely a warm fuzzy thing.

      AUDIENCE: Yeah, so my question is in our case, we have kind of the same setup. We have, in our bigger offices, SteelHead, and then there's a server behind that. And it serves as the entire office server. All the project data is on that one server. They're big enough.

      MATT KREBS: Yeah.

      AUDIENCE: But what I want to know is can we install Revit Server on a server like that, or should we put in place either a virtual or another box just to run Revit Server? Does Revit Server have to be on it's own server?

      MATT KREBS: No it doesn't. That was a choice for us because we wanted to isolate the traffic between our Revit Server network. We were a little iffy on the performance. We weren't sure. And we wanted to give it every chance to succeed. And in order to do that, we went ahead and moved forward with individual servers. And it's kind of been our mantra in our IT group for a long time. We'd like to have a little bit of redundancy and safety built in for, like you said, the warm fuzzy feeling.

      So we really don't store anything on our SteelHeads. They are all isolated servers. Even our file systems servers are their own boxes. And that's just-- I haven't tried it, so I don't know how it would perform. But I don't imagine that it would be an issue.

      AUDIENCE: I wanted to try it just because we don't have 1,600, or however many offices that you have.

      MATT KREBS: Yeah.

      AUDIENCE: We have five.

      MATT KREBS: And if you're just putting--

      AUDIENCE: Just one or one-on-one, execute-- and the one I have in mind.

      MATT KREBS: And in that case, you actually might be better off just using HQ as a host, and then having every other office as just an accelerator, which honestly, would reduce the amount of stress on the SteelHead. Because then you're only using it as a cache, and you're not using it as a host.

      AUDIENCE: Yeah, it's running IIS.

      MATT KREBS: Yeah, it's just running IIS, and it's just passing--

      AUDIENCE: Because I know you can sometimes when you do certain things for Revit Server inside of IIS you may be switching off something that needs that--

      MATT KREBS: So you actually don't need to disable anything for IIS. There's only certain things that you need to enable for Revit Server. You're not turning anything off. So the standard build, you're not disabling other things. But you just need to have their prerequisites on. There are no you need to have this off prerequisites for Revit Server.

      AUDIENCE: OK. And I know if there is a SteelHead, you can tell the SteelHead to repopulate from the HQ down, [INAUDIBLE] anymore.

      MATT KREBS: Yeah.

      AUDIENCE: Which is another thing I think the Riverbed folks will tell you, don't put a server out on satellite with just a SteelHead. You can do, I think it's called a [? CIS ?] re-population. It's done on the SteelHead itself, which is only-- it's the same thing as copying files.

      MATT KREBS: Yeah.

      AUDIENCE: But it's just not sitting on another circuit. You know what I mean?

      MATT KREBS: I think so.

      AUDIENCE: Is that, do you utilize that at all? Or is it not necessary?

      MATT KREBS: For us it's not necessary. We have this infrastructure for a Revit Server. And that's what we use. And everybody's comfortable with it at this point. So it really hasn't been an issue. You had your hand up for a while, so.

      AUDIENCE: I have two questions.

      MATT KREBS: Sure.

      AUDIENCE: First of all, this Riverbed system, how much does it cost?

      MATT KREBS: Oh, I'm not sure actually. You guys just talking about Riverbed.

      AUDIENCE: Oh, Riverbed? I think-- we have a big one in our HQ-- $10,000-$12,000.

      MATT KREBS: Sounds about right.

      AUDIENCE: For the bigger appliance.

      MATT KREBS: Sounds about right.

      AUDIENCE: And then, we've got the smallest one the sell for all our other offices, which I know it's less than $5,000. And it's just, of course, there's maintenance--

      AUDIENCE: Every type on both sides, or if you have two sides that you have [INAUDIBLE]?

      AUDIENCE: We have a big in our headquarter office. And then, we have the smaller one in our satellite office.

      MATT KREBS: Yeah.

      AUDIENCE: And they probably have a booth in the exhibit.

      MATT KREBS: I think they actually do have a booth in the exhibit also. Go and talk to them. Yeah. You literally plug it in, just plug it in. And it's pretty much does. It's pretty straightforward.

      AUDIENCE: It's way easier than setting up a [INAUDIBLE] server.

      MATT KREBS: One second. One second. Part 2?

      AUDIENCE: You have part 2 of the security because the way you show it right now, [? I just actually ?] the address of the DNS and I can access it. How do you prevent this?

      MATT KREBS: Well, for us the program data folder is actually locked down by administrator privileges. So users can't actually edit their rsn.ini, and we control what's contained in that rsn.ini.

      AUDIENCE: But from the outside, if I want to access, for example, if I don't have permission I basically just need your ip.

      MATT KREBS: No. No you can't. You have to be able to add that to your rsn.ini, and you need to be connected to the network. So from the outside, you can't just type in our IP address and get all the way in. Yeah, no.

      AUDIENCE: So you basically have an outer firewall to protect--

      MATT KREBS: Yeah, it's inside of our network. It's not in a DMZ environment or anything like that. So it's completely locked down. Yeah. And then, there you go.

      AUDIENCE: On average, how many user project [INAUDIBLE].

      MATT KREBS: What was that?

      AUDIENCE: The locked file.

      MATT KREBS: Oh, the locked file. Yeah, we haven't really had-- we haven't had issues with overloading on the servers yet. I mean, our office sizes vary. So I mean our New York server is pretty full I think at this point. On just 2016 alone, I think the last count was like 30-something projects on there. But then again, we don't use it for every single project-- for projects that don't need to collaborate with other offices, which is a pretty decent amount, especially for our larger offices.

      AUDIENCE: So that's 30-something projects [INAUDIBLE]?

      MATT KREBS: No. No, absolutely not.

      AUDIENCE: You have all these [INAUDIBLE].

      MATT KREBS: It's really important that you have local accelerators. That's what we've noticed. We've noticed that people that don't have their local accelerator actually set, which does happen every once in a while, they start to see that issue where synchronize with centrals fail, and files get locked, and stuff like that. And it's really important to make sure you have those local accelerators so that they're not going all the way across the WAN.

      It's latency. Yeah. A lot of times it's latency.

      AUDIENCE: [INAUDIBLE]?

      MATT KREBS: Yes. Every six months we basically take down the Revit Server network and do maintenance. That involves clearing the cache, clearing the logs so that it starts everything from fresh. Because those log files get really, really big for active servers.

      AUDIENCE: That's a big one.

      MATT KREBS: It's a really big thing. And the larger those files get, the longer it takes for Revit Server to add and manipulate those files. So every six months we go out and we're pulling 750 megabyte log files to gigabyte log files. So it's important that you make sure that you clear the cache, clear your log files on a semi-regular basis. And for us, we basically boiled that down to twice a year.

      AUDIENCE: Is that [INAUDIBLE]?

      MATT KREBS: Yeah.

      AUDIENCE: Every file you open, or a it will take your backup and put it open?

      MATT KREBS: Oh no. We don't take down the models. We shut off the server and-- or shut off the services-- and then just purge the log. Yeah, we don't actually mess with the models themselves. It's really just the server side adjustments. So yeah, we don't go through-- we leave it to the project teams to actually do purges and audits on their models.

      We really deal with the infrastructure portion of it, which is clearing your S-logs, and then clearing your local cache, temp directories, that kind of stuff.

      AUDIENCE: How does it clear out within the Administrator? You have all those saves or syncs that are occurring--

      MATT KREBS: No, it doesn't clear that. It's not that. That's stored inside of the Revit model itself I believe. But this is basically the communication logs. So it's--

      AUDIENCE: You have to do that periodically clear those out.

      MATT KREBS: Do you? Yeah. We haven't done that. Yeah, I can see that helping because some of those get really big, especially when people get a little sync happy. And you'll see people, like four names just stacked in a 2-minute period, and they synced four times because they wanted to be safe. So. Anybody else?

      AUDIENCE: Oh, so [INAUDIBLE] supporting the [INAUDIBLE] only. They have Revit Server and Clarity, and we're just-- we have a local accelerator only. But I don't have as much privilege to go in and actually have any control of my [INAUDIBLE], do I? Right, because it's their networ, and the only thing I can do is run that [? backwards ?] scripts that you showed, have a copy of my data. [INAUDIBLE]?

      MATT KREBS: Clarity throws a little wrench in there. It sounds like it. It sounds like your models are stored on their server. However, whenever you do open it, it does create a local version on your C: drive, wherever your local version is. So you always have that. And you can always do it to Save As from Revit if you want to do it that route.

      AUDIENCE: We have [INAUDIBLE].

      MATT KREBS: OK. OK. Yeah. For us, basically, we built that up so that we didn't have to update the batch files for each individual model. Basically just parses it for us and creates the list for us automatically.

      AUDIENCE: [INAUDIBLE] access to the Revit Server of headquarters, the logistics [? bring what they are. ?]

      MATT KREBS: No. No not with Clarity. It really sounds like you're kind of just--

      AUDIENCE: [INAUDIBLE].

      MATT KREBS: What was that?

      AUDIENCE: [INAUDIBLE].

      MATT KREBS: Yeah, pretty much. Anybody else? All right. Great. Thanks guys.