Our Mama Bear Size Revit 2011 Deployment

Heads up!  This post is kinda heavy on the IT end of things.  EDIT: Code snippets included at bottom… You’ve been warned.

Just this week I finally got around to pulling the trigger on our 2011 installation of Revit Architecture, MEP, and Structure.  This goes to about 120 PCs over six offices in the firm. 

We aren’t the big boys with 1,000 designers and a team of 20 people on our IT staff, one whose specific job is to figure out how to deploy software.  Neither are we the little guys with only five employees and you can carry a CD to each desk to install new software in the course of an afternoon.  We’re right in the middle.  We’re the warm porridge of firms, which offers some interesting “opportunities” when trying to deploy and manage software.  (You like that?  I pulled out my business speak thesaurus and got the word “opportunity” in place of the word I wanted to use!) 

The question then is, how to deploy software to over 100 desktops without having to walk/drive to each one.  That might take some time.  We’re going to walk through how we overcame some of these hurdles and hopefully you can learn from our mistakes or maybe pick up a tip or two. 

First up, simply make the deployment.  Using the deployment wizard, we tweaked the install and set file locations and other wonderful settings and saved it all to a central location (we call it our “Library” server).  This Library drive gets replicated over the WAN to each office every night.  This was a lot of data, so we made the deployment on a Friday to copy over the weekend.  Pushing three different installs of Revit to five remote offices wrapped up the following Thursday. 

Then it was onto a test.  We had a spare PC in the “lab” (this term is used loosely).  Remember all those file locations and other great settings tweaked in the wizard?  Turns out Revit decides to ignore a lot of them during the actual install.  Hooray!  This write-up on the AU Website gave us a hint to tweak an install, then copy the Revit.ini file around AFTER installation.  Good tip.  I also like how at the bottom he says that “Installing Revit is a three-part process”, then lists 5 steps.  But I digress.  And seriously, we got some good tips here.  Be sure to read it if you are prepping your own deployment.  EDIT: Matt Stachoni sent a note to let me know that there is another location for the above mentioned deployment article here.  This one is better and has not been edited.  And five does equal five. 

So.  We now will need to copy the Revit.ini file over to the PCs after the install, if we want to get the most customized bang for our buck – file locations, template locations, etc.  Great.  Let’s tackle that later. 

Aside from the ini file, the install goes fine.  How are we going to get it on everyone’s machine?  In the past, we tried to use the msi files, and push the deployment through Active Directory to the PCs.  We ended up with many failures due to some missing prerequisites.  Then trying to push the prerequisites before the install got difficult. 

At the completion of the creation of the deployment with the wizard, you get a nice shortcut that you run that points to the install executable with all the tweaks that Revit will try to ignore later.  This is the most solid way to get the deployment out there, because the install executable includes the prerequisites.  So we really just want to copy this process. 

However, we couldn’t just have people double-click the shortcut because
1) our users are not admins on their PCs
2) I still want to PUSH this out as much as I can, so everyone gets it.  If I ask folks to double-click on something, it won’t happen on probably 30% of the machines, then I’m back to what would be a manual install 

We looked at RUN AS batch scripts, but anyone could open a .bat file and see the login credentials of an admin user pretty easily.  We needed something that could build a RUN AS wrapper to allow us to assign a login script that would give users temporary admin rights to install the software. 

Enter one of my favorite tools, AutoIt

If you do any IT management or work, you should download this now and look through some examples.  It’s a scripting platform that can do many things and will compile a nice little .exe file when you’re done.  Oh, and it’s freeware. 

Writing an AutoIt solved all four problems – .exe file that we could assign as a login script, allow to run with different credentials, run the install exe and arguments exactly like the wizard shortcut, and at the end of it all we copy over the tweaked Revit.ini file. 

Using a script wrapper is how we are making the majority of our installs now, and we have a nice generic script that we just tweak for each one.  There are actually two scripts, one local and one network due to an odd issue with Vista and Windows 7 UAC, but it works.  The network file is run first, which copies the local file over to the PCs C: drive.  Then the network file runs the local file under admin credentials.  The local file actually runs the install exe.  When it’s all done, we write a little text file to a folder on the C: drive, this way the network file has something to check to see if the software has installed, otherwise it will just run every time the user logs in. 

That’s the basics of it.  We’re happy with what we’ve worked out and have had several successful deployments using the above method.  If there’s some interest, I’ll post the actual script files up here later (EDIT: I’ve posted them below in this article), just let me know via comments or email.  But right now, this post is getting pretty long, and I’m getting kinda tired.  That bed looks good.  No not that one, that one’s too hard.  No, that other one looks too soft.  I’m talking about the one in the middle there. 

Yeah, that one looks just right.

OK, so here’s the code I mentioned above, with some notes in there and the fie locations genericized.  Watch out for line-wrapping and weird HTML format crap if you copy and paste.  As always, this is provided as-is and I would strongly recommending testing before throwing into a production environment.

The first is the network script which is the actual file that gets assigned as a login script.

Local $TxtFileName
Local $TxtFileName2
Local $LauncherFilePath
Local $LauncherFileName
Local $LocPath
Local $LocLauncher 
Local $SoftPath

;create a temp folder to copy the local wrapper to – make sure that people have execute rights to it

;the next location is where we write/check for the text file to see if the script should run completely
$SoftPath = “C:\WINDOWS\OurSoft\”
$LauncherFilePath = “(network path of the local wrapper file, not including the filename, ending with a \)”
$LocPath = “c:\temp_wrapper”

$TxtFileName = “(name of text file to see if the wrappers have already run”
$LauncherFileName = “(name of local wrapper file)”
;checks to see if the text file exists and if it does, it does nothing – if it doesn’t it runs the else
If FileExists($SoftPath & $TxtFileName) Then
 $LocLauncher = $LocPath & “\” & $LauncherFileName
;copies the local wrapper from the network location to the location folder – needed to get around UAC issues with Vista and 7
 FileCopy($LauncherFilePath & $LauncherFileName, $LocLauncher)
;runs the local file as admin
 RunAsWait(“(admin login)”, “(domain)”, “(password”, 0, $LocLauncher)

Next is the local file that gets copied over and run with the RunAsWait.  Some of these strings I just copied directly from the shortcut that gets created by the deployment wizard.

;UAC prompt

;name of the text file to create when local wrapper has run
Local $TxtFileName
$TxtFileName = “C:\WINDOWS\OurSoft\(name of textfile from network wrapper)”

;belts and suspenders – warms up the network location before the install
DriveMapAdd(“”, \\server\share)

Local $ProgramFile, $argFile, $command
;location to the setup.exe file copied from the shortcut
;does NOT include arguments
;filename shortened to 8.3 filename
$ProgramFile = FileGetShortName(“\\server\share\path to install\AdminImage\Setup.exe”)
;location to the ini file from the shortcut
;does NOT include /qb /I etc, ONLY the ini file
;filename shortened to 8.3 filename
$argFile = FileGetShortName(“\\server\share\path to install\AdminImage\install.ini”)
;the following string rebuilds the link from the wizard created shortcut with all arugments
$command = $ProgramFile & ” /qb /I ” & $argFile

;checks for the revit.ini file to exist
;if not, loop until it is installed
;was necessary to wait until AFTER install was complete before copying final revit.ini file
While FileExists(“C:\Program Files\Autodesk\(Revit flavor)\Program\Revit.ini”) = 0

;once revit.ini exists locally, copy our tweaked one over top of it
FileCopy(“\\server\share\tweaked-revit.ini”, “C:\Program Files\Autodesk\(Revit flavor)\Program\Revit.ini”, 1)

;creates and writes a note in the text file stating that the install is done 
FileOpen($TxtFileName, 1)
FileWriteLine($TxtFileName, “Revit 2011 installed.”)

Hope this helps as a jumping off point for everyone.

11 thoughts on “Our Mama Bear Size Revit 2011 Deployment

  1. Anders says:

    Great post. We are just about to roll out Revit Architecture 2011 in the office (+50 seats) and this was exactly the info we were looking for. If you would be so kind to post the script files here we would be even happier. Thanks in advance.

  2. Matt Stachoni says:

    Hi, Jason, and thanks for the reference to my AU article. Unfortunately the submitted copy was severely edited to what appears on the AU site. I also don’t know where the weird screen shot image in the middle of the article came from….You might want to check out the full version at http://www.cadapult.net/blog/aecblog.html

    Matt Stachoni

  3. David Kingham says:

    I would be interested in taking a look at the code, I’m an avid user of autohotkey and do lots of customization through my Revit Launcher script but I have never looked at autoit (I believe they’re nearly the same) Thanks!

  4. jkunkel says:

    Scripts have been posted. Good luck. Obviously they were made for our environment, but we’re pretty vanilla. I hope they can help out.

  5. jkunkel says:

    Code’s all up. We love AutoIt over here. We’ve been able to snag MAC addresses for wake on lan scripts and other fun things, too. “Fun” being in the eye of the nerd.

  6. mr.fact says:

    I have just gone through this process with a similar organisation. RMEP 2011 deployment distributed via dfs and then pushing the revit.ini file to appropriate PC’s. Has worked fine so far. The question has to be raised as to what Autodesk are doing to fix? We had the same issue with 2010 deployments and pointed it out to them then.

  7. john says:

    interesting,why dont you use Microsoft SMS and
    VB script technology to deploy software to desktops?

  8. jkunkel says:

    It does feel like Autodesk drops the ball when it comes to deployment. Just like you, we have the same chat with anyone over there who will listen, and it hasn’t gotten us very far. I would love to simply push the MSI with a MST through Active Directory, but there are so many prereqs, it never works.

  9. jkunkel says:

    SMS costs money, and right now we are doing everything we can to trim costs. If we had SMS or a Kace box we would probably use it, but currently we are trying to make do with what we have (less even!)
    A VBS is just is just a text file so that would expose our admin password. At least when it’s wrapped up in an EXE file, the average user isn’t going to find it.

  10. mr.fact says:

    SMS also out of the price point for us. Currently AD pushes a VBS to run the deployment, no passwords necessary. Not the IT expert so don’t have the full details.

Comments are closed.