Deployments, content and hacks

One of the most tedious and thankless jobs is creating software deployments. “Why is it taking so long?!” I remember asking towards the end of May back in the days. I couldn’t appreciate why, because…well, I didn’t know what it involved. Now that I know I can appreciate it a bit more, although I don’t think it should take weeks on end to get Revit onto users machines.

The first challenge is to get the content downloaded and placed on your network, and install your network licenses (I won’t be discussing the latter on this post). Autodesk have, IMO, made it more cumbersome since the 2012 releases to get content prior to creating deployments, which used to be available for download from their site. My solution is to install a version on a virtual machine (such us VirtualBox from Oracle) and then mine the content to be placed on the network library.

At my previous employer, content was placed on a DFS share which replicated to all offices and then its contents were copied to each machine’s local drive in read-only folders at log-on. This was mainly done due to laptop users and in theory, should cut down on network chattiness when accessing content. At my current employer, we keep everything in a library on the network, which is replicated nightly to another office on the same share as the main office (mapped on desktops with the same drive letter). This is a very important thing to consider in order to simplify your content mapping.

Upgrading of content is a must-do step for some. In my case, I have kept the content as is because we have multiple versions of Revit running so it doesn’t make sense to upgrade and duplicate the custom content in versioned folders. The most used families are pre-loaded in the template so only a limited number need to upgrade when loaded into a project. Of course Autodesk content is placed in its own versioned folder and mapped through the xml files that debuted last year and caused quite a headache. When we don’t need an older version anymore, we can easily nuke the old content folder.

If all your offices have content in exactly in the same location, you’re on your way to simplifying and accelerating deployments. However lots end up having to manually create unique deployments in each office because of two other things that tend to be unique resources at each location: Revit Server and the license server. However, with a little collaboration with your IT department and some basic understanding of DNS, you can actually create a single deployment that works at all your other offices! Sounds too good to be true, but it’s actually quite simple.

Depending on your office network infrastructure, you might be running DNS on your Windows server or some other box. In our current setup, it’s actually running on the router software. So to edit DNS entries, we log into the router and make changes there (called DNS forwarders in our case but your router might have this functionality under DHCP settings, such as with Tomato router firmware). But why should we be bothered with DNS when we’re talking about deployments? Well, whenever you try to connect to a machine with the hostname, a query is sent to the local DNS server first to see if it can trace it to an IP address on the local subnet (if connected together via VPN, each network is defined by it’s own subnet. So for example 192.168.1.XXX is a different subnet/network than 192.168.2.XXX, assuming you have less than 255 IP devices plugged in to each one). This is also what happens within your home network and high-speed internet router. If the hostname is not found, the query is passed on upstream through the gateway and onto your ISP’s DNS server.

You’re probably familiar with naming a Windows machine with a hostname so its easier to locate on a network. The DNS server keeps track of the hostnames and associated IP addresses, which typically change from time to time, so when you try accessing a resource with the hostname, it forwards you to the correct device with the IP address stored in its database. This fundamental fact is extremely important to understand.

However hostnames can be entered on the DNS server (or DHCP settings) manually, so you can think of them as “nicknames” or placeholders to point you to a specific resource. In fact multiple hostnames can be used to point to the same resource. To illustrate, let’s say you have 2 offices A & B. When creating a deployment:

• Office A is mapped to RevitServer-A
• Office B is mapped to RevitServer-B

So now you’re probably saying…”well Dave, that means you need 2 unique deployments or at least, make a copy of A in office B and modify the deployment”. That is one way of doing it for sure, but not the smartest way. Think back to the DNS discussion above: You can create a new hostname to point you to a unique resource in each subnet. So I can enter a DNS entry as follows at each office:

• Office A: revitserver mapped to RevitServer-A’s IP
• Office B: revitserver mapped to RevitServer-B’s IP

Now my deployment can be used in both offices and when the local DNS is queried for revitserver, it returns the correct IP address for that location and no deployment tweaks are necessary.

Similarly, if you have a license server at each location, you can easily set up the deployment to use distributed license servers as this minimizes the possibility of running completely out. So let’s say I have the following setup:

• Office A: license server called Apples
• Office B: license server called Bananas.

Typically you’d enter them as follows in each deployment:

• Office A: Apples, Bananas
• Office B: Bananas, Apples

In essence, you prioritize them so that each local license server is accessed first and if no more licenses are available, it will find the other one through the Wide Area Network (WAN), assuming your offices are connected together via VPN or ethernet. Once again these seem to require unique deployment packages, but with the above described magic of DNS, we can circumvent this issue. So my deployment can now say fruit1, fruit2 and work at both locations without further tweaks once again. Have you guessed how the DNS entries would be set up?

• Office A: fruit1 –> Apples’ IP,   fruit2 –> Bananas’ IP
• Office B: fruit1 –> Bananas’ IP, fruit2 –> Apples’ IP

So once again, the same deployment can be used and the DNS will resolve accordingly. The beauty of this is that you set it once and be done with it. With the advent of Design Suites and the myriad of deployments that come with it, this methodology will save you tons of time and then multiply that by the number of offices you have to support!

I hope this is of help to someone out there. As always, comments are very welcome.

Deployments, content and hacks

Resolving locking issues with Revit Server

Hi everyone, hope this New Year brings you all lots of health, happiness and prosperity!

If you’re using Revit Server (why not?), then you’re probably familiar with this particular WIKI article on Model-Level Locks. If you have not noticed, when users report that they cannot access a particular project or synchronize, you also cannot lock the project in the Revit Server Administrator. Without the ability to lock a project, users cannot do anything so it is of utmost importance to get locking-unlocking to work first. Unfortunately we’ve had a couple of occasions where models were in limbo, even though we followed the instructions in the WIKI article.

There are various reasons that could cause a project to break and I won’t try to analyze that. But it seems there is a way to restore balance to the universe once the permissions get sorted out.

First, clear the .lock files as described here. As a precaution, it seems sane to stop the Local Servers in the IIS Manager first, and then stop the Revit Server Autosync service on each Local Server. Alternatively, you could shut them down completely, but as long as you stop the communication between all servers, you should be good to perform some minor “surgery” on the main patient: the Central Server, which has to be up and running. However you also need to stop the Revit Server Autosync service on the Central Server. It seems that in this state, project files that were previously unlockable, can be locked once again, so cycle through them…wax-on, wax-off. If this doesn’t work and you previously deleted the two .lock files for each problem project, go ahead and re-create them manually (notepad is your friend…remember to remove the .txt extension) and try again. I cannot say with certainty whether this is a necessary step since we did perform this task and I honestly don’t know whether to attribute success partially to this fact or not.

When you’re satisfied that locking/unlocking is working, re-start the Revit Server Autosync service on the Central Server. Go back and cycle locking back and forth once again (preferably at the Central Server master node) to ensure everything is working properly. Finally, bring the Local servers back online and don’t forget to restart the Autosync service.

I hope this helps someone in the future. If you have had similar experiences or found alternative solutions (don’t tell me “re-create the central file”: been there, done that!), I would love to hear about them.

Resolving locking issues with Revit Server

Revit Server is Desktop no more

Well, we finally gave up. Reluctantly.

Our Windows 7 setup seemed to be working just fine. However we were plagued by Revit crashes following a successful synchronization with central at the location connected to the Local server. At first we thought bandwidth was to blame so we upgraded our connections by installing business cable at the location with the least bandwidth, fully dedicated to Revit Server to Server traffic (2Mbps up, 12Mbps down). We left the previous connection in place to other uses such as VoIP, VPN, etc. In the main office we left the bonded T3 (3Mbps up, 3Mbps down) alone but removed traffic shaping to make sure Revit Server received maximum capacity.We also configured the Revit Servers with their own public IP address so traffic was outside of VPN and thus not slowed down by encryption. The servers are protected and not accessible from outside the network through various router rules and protection safeguards.

Unfortunately this did not eliminate crashing at the user’s desktop. Our next experiment was to switch the Central and Local servers around to see what effect this would have (not the physical machines). We ended up with the Local server in our main office with around 6 people working on server-based projects and 2 at the remote location saving directly to the Central server. Through our upgraded connection, we could now create central files through the Local server, which was not possible in the past. So we know that at least bandwidth cured that issue. The crashing unfortunately followed the Local server and users in the main office started experiencing this crashing following a successful SWC, 90% of the time. Go figure.

Our next step was to install Windows Server 2008 SP2. We did this on the Local server first. Lo and behold, the crashing ceased even with the central server still running Windows 7! At this point we don’t know exactly why this is happening and gave up on our endeavor. We still think Windows 7 should do the job but somehow, there’s some setting somewhere that is causing Revit to blow up. Or maybe WS2008 is more efficient at handling limited resources such as RAM? But why would Revit crash, with no debugging info. available?The machines we’re using as servers are low on RAM so who knows? The journals do not point at the culprit and Revit mysteriously crashes after successful saves (servers keep running fine, projects do not corrupt and the Revit Server administrator reports the saves are successful), so at this point we bow our heads and wave the white flag. Bummer.

Revit Server is Desktop no more

Revit Server update

What a slacker! 2 months with no post, like I fell off a cliff. Well, I’ve been a bit busy especially trying to take care of some stuff I’ve been procrastinating on for a loooong time and it’s going to take a bit longer than anticipated. But enough excuses.

Our maverick Revit Server setup has been working quite good. Unfortunately we cannot get support since we’re not running on the required Windows Server 2008 / SP1 OS, but so far it seems to have been working perfectly fine. We did encounter some hitches that we were not quite sure what was causing them.

We’ve come to realize that our bandwidth was just not enough. Or at least that is the current indicator, especially based on some tests. Here’s what our setup looks like:

Central office: Bonded T1 with 3Mbps up and 3Mbps down

Remote office: DSL with up to 768Kbps up and up to 6Mbps down

Clearly the bottle-----neck is the remote office upload speed. The 768Kbps is not an absolute number (just like your 401(k)!). In our case we had some “traffic shaping” at the routers which allocated a certain percentage to VoIP and some other things, which meant that we barely had 200 to 300Kpbs for Revit Server uploads from the remote office to the central office. Here’s the conversion for reference (all this talk of bits and bytes is confusing for every-day users like myself):

1 Byte = 8 bits; 1 KB = 1,024 Bytes (8,192 bits)

Data transfer: 1 Kbps = 1,000 bits/sec

Data Storage: 1KB/s = 1,024 Bytes/sec (8,192 bits/sec)

So with our connection, the remote office was uploading to the central server at a familiar rate of 24.4 to 36.6 KB/s, which is probably too low (reminds me of dial-up downloads!). One of the issues we were having was with creating central files at the remote location: they kept failing, citing a “network failure”. However if we created them at the central office and then opened them at the remote location, everything ran just fine after the main copying was complete. Assuming we were getting 1Mbps, the upload from Central to Local server was happening at a familiar 122KB/s, which is a lot more acceptable. So it’s clear that you need to pay particular attention to your upload bandwidth. We temporarily disabled traffic shaping and were getting about 650Mbps (79.35KB/s) consistently from remote to central office. In theory this number could go up to 768Mbps (93.75KB/s) but it is unlikely you can get that throughput consistently, apart from the fact that you will also have other network traffic that will reduce this number. We have now finally been able to create moderately sized central files at the remote location. Increasing bandwidth will probably cure the failures but we have to assess what the cost implications are at this point. It is also noteworthy that round-trip ping times from each location are around 85ms. This seems to be a consistent baseline in our case but we have also seen it fluctuate pretty high. I think these fluctuations could also account for the network failures.

Autodesk has just released 3 documents which you really need to read before deploying Revit Server. They will help tremendously in planning your hardware costs and bandwidth requirements. You can download them from HERE.

Revit Server update

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”

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.

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.

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.

Revit Server goes Desktop

Where is Baldo?

Ok, so my April fool post wasn't funny eh? I actually wasn't trying to be, so there :p

The next couple of days are going to be a real treat. I cannot say much yet but if you're a regular reader of this blog, you know what happened at the end of September 2010. So stay tuned for some more news.

As for my Revit Server post, it was quite cool to see several users play around with the admin panel. What was REALLY cool was getting it to work properly with my buddy Daniel, collaborating on some goofy files across national boundaries: from Houston to Montreal! It looks promising but not totally reliable. I was also really happy to see Phillip of KiwiCodes (Family Browser) actually save a file to the central server! One of the main concerns was that the admin. panel was unsecured and open to all. This was obviously the first test, but I can tell you that I was able to lock it completely and have it serviceable only through the machine hosting the Central server itself. This opens up more possibilities, such as remote controlling the Central server machine directly and administering through this means. Even with the admin. panel completely locked (blocking port 80 in the Windows firewall), syncronization from local server to central server was still successful.

I have received several emails expressing interest in how to set this up and also wanting to know how it performs. I will share more details in the coming weeks as I'm still trying to learn a few more particulars prior to posting. You know that I like to have all my ducks in a row as they say ;) A huge thanks goes to a very smart guy named Kevin who does not settle for "can't be done" for an answer ;) I sure learned a lot from him over the past few months.

I'll leave you with one tip though: if you're wanting to install Revit server on Windows 7, you need to install IIs7 first and edit the setup.ini file. Remember thay this is UNSUPPORTED by Autodesk, so please don't go about pestering them about it. You've been warned!

Where is Baldo?

Public Revit Server?

Imagine you could work efficiently with others outside your office on workset-enabled Revit files without being within the same network infrastructure or connected together via VPN. Wouldn’t that be cool?

I’m not implying this will work (yet) but I think it’s actually possible. See for yourself by clicking here! Note that this is a temporary URL and will only work for a short period of time after this post. If testing is successful, I’ll follow up with details.

Public Revit Server?

Ready, download, install

Ahh, the goodies have hit the street earlier today. Sounds like it is going to be a busy weekend of testing, playing and drooling!

There’s lots of talk about the SAP in the blogosphere but you probably want to take special note of the following:

• Subscription Advantage Pack for Revit 2011 (videos)
• Subscription Advantage Packs
• Subscription Advantage Pack for Revit 2011 (Revit Clinic)

As is customary, the bloggers Robert Manna, Steve Stafford and David Light have provided great commentary and insight (and keep going, and going, and going…), so make sure to check out their writing over the past days as there are several informative articles about the subject.

On the subject of the Revit server, I have to say that I’m not thrilled with the terminology, and the folks at Autodesk have struggled with the language too. I would love to hear what you, the readers, have to say about this. Personally, I would have preferred using something like this:

• Central Server –> Master Server/Project Vault/Revit Vault
• Local Server –> Sync Server

Honestly, I am still not sure how this whole setup works and will do my best to get some answers before writing in more depth. For example how does one create local files if the end user cannot physically navigate to any of these servers from Explorer? Are we to assume that we have to use Revit’s current solution of automatically creating local files on our C drive?

In the meantime, you might want to view this video taken from the Autodesk Wiki to get a decent overview of the Revit Server setup.

Ready, download, install

Revit Server

A hot topic in today's global economy is: how can we collaborate with other professionals in geographically dispersed locations in a Workshared Revit model? Plenty of large firms have invested a lot of money in WAN acceleration technologies, sometimes with unsatisfying results. Welcome the Revit Server. Oh, and the software is free for subscription customers!

Essentially, you need to set up one central server location, regardless of how many office locations you have, and one additional server in each of your offices ('local' server...not to be confused with your local files). In its simplest form, the local servers caches data from the central server behind the scenes to each local (office) server. So the connection between the satellite offices and the central server needs to be very good. There will also be a web-based management tool that IT or a BIM manager will use to manage projects and folders. All permissions will now be saved on the servers and not in your backup folder. So the local office servers are transparent to the end user and serve the purpose of enhancing the user experience in terms of working speed by caching only the delta locally (only the bytes of data that change). For the current implementation, you will host all your projects on the central server and each office can see everything.

Currently, the local and central servers will be behind your firm's firewall. In the future though, this technology could open up the possibility of multi-firm collaboration.

If you have WAN acceleration, you're not going to throw away the money you have invested. But you might want to try this system first and then think about WAN acceleration if performance is not satisfactory and you don't own the technology.

Note that it is recommended to not set up your servers on other servers running intensive services, such as Exchange or VoIP.

Published with Blogger-droid v1.6.0

Revit Server