A Little Dash of IT Magic for Deployments

The nature of deployments means that they will most likely end up on a network server somewhere. But for one reason or another, you might not want to just dive in and create those deployments right on the server: you could be running out of space, you might be testing out a new configuration, or it’s often just a good idea to test these things out first anyway.

Two assumptions with this trick. First, you are using the Autodesk Deployment tools with your software. Secondly, you are going to be deploying from a mapped drive (that has its own potential issues, but it’s a very common practice).

I like to be able to have my cake and eat it too. In this case, that means creating a test deployment in a sandbox, but being able to use it for my final deployment if it works. Let’s say we want to make our deployments on the network L: drive. Being good software folks, we don’t want to create our deployments on that drive directly. It’s easy to disconnect the drive, but how do you convince your local PC that it has that L: drive?

Time to crack open the Command Line! Good old DOS. The command subst allows you to set a local folder as a new drive letter, spoofing it so Windows sees a new drive.

I’ve used this all the time to build deployments. I have to make sure my folder tree matches the real network drive… so if my network deployments live under L:\Autodesk, I make a folder on my C: drive called Deploy, then I use subst to make my computer think that C:\Deploy is L: and then I just need to create an Autodesk folder under C:\Deploy.

So I create my Autodesk deployments, say the administrative image path is L:\Autodesk\<<whatever>>, and I am creating test deployments on my hard drive, that I can then just move up to the network location if they work. All the paths will align properly and users can then run the install from that L:\Autodesk path.

Revit Deployment Time

It’s that joyous time of year again! The time when the “first” service pack comes out for my favorite design software and I start thinking about deployments!

I wrote a very detailed deployment article some years back, and most of it still fits, however I have been able to tweak the code slightly. Here is a quick overview of what we found to be most effective:

Since we are in a domain setting and our users don’t have admin rights, we removed the UAC for workstations through a GPO.

A fantastic tip from the outstanding blog Up and Ready helped me track down the individual software packages for the Suites that we have. I like having an individual deployment for each piece of software, so I can give User A Revit and AutoCrap, but I can give User B Revit and Max, and then give User C only Navisworks. When you create a deployment from the Suite, you can specify only one piece of software, but the package that gets created is HUGE and has a lot of extra crap. Fortunately, you can use your Suite license on each individual software that the Suite includes. So, download the individual software package and create deployments from those to save space.

I then use the Autodesk utilities to create a deployment, after tweaking our Revit.ini file. This is much better than years ago. It’s clean and the importing of the Revit.ini is really nice. It’s a tad annoying that I have to install “vanilla” Revit first, edit my options, and then track down the Revit.ini file to use, but it’s not horrible, and it works. Possibly it would be better to have a utility that only creates a Revit.ini file with no Revit; some wizard-y thing. Eh.

Again, I am using the remarkable AutoIT script editor to create two “wrapper” files: one we call “net” and one “local”. If you do some IT, this utility is gold. Get it. Now.

The “net” wrapper gets assigned through a GPO to a scheduled task that kicks off whenever someone logs in to the appropriate PC. “Net” will check to see if a little .txt file exists on the C: drive. If it doesn’t, then it goes and copies “local” to the C: drive and runs it. A little note about the text file: it’s here to see if the installer has run. We could check to see if the Revit.exe exists, but this way I can copy the .txt file to individual PCs that we may happen to want to skip this install, but not put in their own OU.

“Local” wrapper has all the info from the installer shortcut created by the deployment. Its main job is to pretend it is a user with admin rights, then run the install. Once it is finished, it write the .txt file to the PC to say “Hey! I’m done!”

We have had a high rate of success with this method. It allows us to deploy a nice tweaked version of Revit and not spend too much time messing with it. If you would like to get a copy of our “net” and “local” files, fee free to take a look below.

NET

Local $TxtFileNameLocal
Local $TxtFileName2
Local $LauncherFilePath
Local $LauncherFileName
Local $LocPath
Local $LocLauncher
Local $MSoftPath

;create the place to keep the local file – will skip if path already exists
DirCreate(“LOCAL WRITABLE PATH TO SAVE THE LOCAL FILE”)
$MSoftPath = “LOCAL DRIVE LOCATION TO STORE TEXT FILES”
$LauncherFilePath = “NETWORK PATH TO LOCAL WRAPPER FILE”
$LocPath = “LOCAL DRIVE LOCATION TO STORE LOCAL WRAPPER FILE”

; the file that gets written after installer runs so it doesn’t run again
$TxtFileName = “REVIT_15.txt”

; local wrapper name
$LauncherFileName = “rvt15-local.exe”

; checks if the text file exists
If FileExists($MSoftPath & $TxtFileName) Then
;text file exists, so nothing to do
Else
; no text file – rock on
$LocLauncher = $LocPath & “\” & $LauncherFileName

; copy the local file down
FileCopy($LauncherFilePath & $LauncherFileName, $LocLauncher)

; run the local file with admin rights
RunAs(“ADMIN”, “DOMAIN”, “PASSWORD”, 1, $LocLauncher)

EndIf

Local

#RequireAdmin
; text file to create after installer attempts to run
Local $TxtFileName
$TxtFileName = “LOCAL DRIVE LOCATION TO STORE TEXT FILES\REVIT_15.txt”

; warm up the network
DriveMapAdd(“”, “UNC PATH TO DEPLOYMENT”)

;setup.exe and the deployment ini file can be copied from the shortcut
;that gets created with the deployment
;as can the arguments – below are what I get from mine
Local $ProgramFile, $argFile, $command

$ProgramFile = FileGetShortName(“PATH TO DEPLOYMENT\Setup.exe”)
$argFile = FileGetShortName(“PATH TO DEPLOYMENT\RVT2015.ini”)
$command = $ProgramFile & ” /qb /I ” & $argFile & ” /language en-us”

;this is the actual installer
RunWait($command);MsgBox(1, “Title”, $ProgramFile)

;write the text file – note that the file gets written even if the installer fails
;this is so the PC doesn’t keep trying to install again and again – track down the issue
FileOpen($TxtFileName, 1)
FileWriteLine($TxtFileName, “Revit 2015 Installed”)
FileClose($TxtFileName)

Enjoy! Hope this makes your installations a little happier!

Autodesk Application Manager Annoyance

If you’re like me, you get annoyed with extra software getting installed on your user’s PCs without your control. I like streamlining deployments as much as possible, I do all I can to keep users from installing software on their own, etc.

With the 2015 branded software, Autodesk introduced the Autodesk Application Manager. In theory, a cute little piece of software that can let you know when your Autodesk programs are out of date. In my environment it’s another memory suck, another pop-up, and another phone call from a user. My users simply cannot install the updates on their own even if they knew about them. They don’t have admin rights.

Luckily, according to the FAQ, if I don’t want it for a network deployment I can just uncheck the box! Perfection!

(Cue ominous music)

My AutoCrap deployment and my Revit deployment did this wonderfully. Uncheck the box, no Application Manager. And then I got to 3D Max Design…

If Autodesk had pants, they would be on fire right now

Of course we had a problem. The deployment wizard said I couldn’t have Max if I didn’t install the App Manager.

Well, I wanted Max. There are some notes in the FAQ about editing the setup.ini file for a non-deployment installation, but I worried since I wasn’t doing a stand-alone install, this wouldn’t work.

The workaround I opted for was to tweak the Application Manager settings before the deployment. Like a lot of the software, you can first install it, set it up the way you like, and then save the settings to apply to your deployment. So that’s what I did.

I got Application Manager installed on my machine and tweaked the settings to tell it to not start on Windows start-up, to only check for updates once a week, and to not show any pop-up when it finds updates. Not ideal, but it should at least stay hidden mostly from my users. Mostly.

Once that is done, you export your settings as a tiny .ini file. I put mine in the same location of the deployment, just in case.

When you created you deployment, under the options for Application Manager, you can then import this .ini file to suck up those settings.

VERY IMPORTANT!!!! When you export your settings to an .ini file, there is a setting for “Files Location”. The default is the current users Windows Documents folder. The installer will NOT re-interpret this as a variable username and will deploy with the precise path that’s in there, so BEFORE you export your settings, change this to some universal non-user specific file location.

Change this path before exporting your settings

 

Revit 2013 One Box Deployment Problem

We are working on getting our installation for Revit 2013 ready and have stumbled across an issue that the deployment can have.

Leveraging the power of the “One Box”, we planned on putting the deployment files on the server, and simply tweak the deployment for multiple disciplines.  Save a ton of server space!  High five!

Well, everything looked good, and we had five shortcuts with five different ini files saved in the “CustomSettings” folder.  Things were going smoothly.

Then we went to install.  For some odd reason, only the first deployment we created had the entire set of customizations, the others only got the license file; file location settings were missing, tweaks to options weren’t there.  Basically, the installations were ignoring the custom ini file.

We contacted Autodesk, and they confirmed that this is an issue.

I never know if I’m supposed to feel better or worse when they tell me that.

No fix, of course.  And I’m not holding my breath on there being a fix.

The workaround involves tweaking our install script so it copies the tweaked ini filed from the AdminImage\CustomSettings folder to the application data folder for the user’s PCs.  Keep in mind that this location is not the same in XP and Windows 7 (Vista is dead to me).

For Windows 7, you need to copy here:
C:\ProgramData\Autodesk\RVT 2013\UserDataCache\

For XP, copy the ini here
C:\Documents and Settings\All Users\Application Data\Autodesk\RVT 2013\UserDataCache\

In both cases, you need to copy your custom ini file and rename it to Revit.ini, replacing the one that the installer created.

What’s odd is the deployments that weren’t created from One Box work fine.  I have given up expecting any Autodesk deployment to go as advertised.  Every year we fight a new set of problems. My expectation is that the smaller firms just walk from desk to desk to install.  And the really big firms have an IT group and fancy-pants servers whose single job is to install software.  We are very much a middle size firm: WAY too many seats to install one at a time, and not nearly enough in the IT budget to dedicate to software deployment.  So, we make do with what we have.  It would be nice if Autodesk could put a little more effort in their deployment creation tools.

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
DirCreate(“c:\temp_wrapper”)

;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
 
Else 
 $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)
EndIf

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
#RequireAdmin

;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
 
RunWait($command)

;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
 Sleep(30000)
WEnd

;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.”)
FileClose($TxtFileName)

Hope this helps as a jumping off point for everyone.

Commitees Suck for Deploying Software

I know the drill.  Hey look!  New software!  Let’s set up a committee!  Let’s get everyone’s input!  Let’s hold hands and sing folk songs and this software will magically deploy itself when butterflies flit around and run the installation files on everyone’s PC.

No no no.

As architects, we like design charettes.  We like to get together and hash out unique solutions to design issues.  That’s great.  You can come up with excellent resolutions to some big problems.  And quite often, that’s close to the most social some of us ever get.

That shared workforces mentality can spill over into other facets of our business.  Let me tell you, deploying software isn’t designing a building.

Aside from the charette mentality, to maintain good relationships in a firm, we like to make sure everyone feels like their opinion has been heard and counts.

Deploying software isn’t like ordering pizza, either.

I’ve been through a couple major software deployments now, and each time, the committee gets used less and less.  Why?

Because committees suck for deploying software.

Now, I’m not talking the lone wolf here.  I don’t endorse the idea that one person should be making all these decisions.  Sometimes that works, with Revit, it won’t.  But a committee is the wrong approach.  Get three people, each more opinionated than the next.  That’s your core group of decision makers for a Revit migration.

Why is a smaller group better?

Standards changes– I said in an earlier post that I was using our Revit deployment as a jumping off point for enforcing our standards fresh.  That does not mean that we used Revit as a reason to rewrite our entire standards book.  On the contrary, we used our old standards as a jumping off point.  We were going to be making enough changes with just the software without having to change everything.  Often, our hand would be forced to look at and change the standard because of how Revit functions (leaders at the end of text, I’m looking at you).  Usually the smaller team would be quickly in agreement.  A large committee would require way too much time on conversation and evaluation of the issue.

Education – Some issues are new and hard to understand.  It’s far easier to train three people on a complicated issue to make a good decision than it is to educate a roomful.

Passionate ideas – sometimes an individual in the smaller group would be VERY passionate about an issue.  The others would give way, understanding that their pet issue might come up soon and there would be some mutual back scratching.  With a larger group, there is a lot more heel digging in, just to dig in heels and feel like you have to be forceful on each issue so you’re heard.

You might be right – in some situations, you’re just right.  It doesn’t matter what others say, you know you’re right.  Convincing only two people is a lot easier than a roomful.

You might be wrong – in some situations, you’re just wrong.  You think you’re right, but you’re not.  It’s much easier to get shown the error of your ways by a small personal group than by a large room of people.

Camaraderie– a small group makes it easier to feel like a team.  By the nature of being in your group you will get each other’s back, because it’s just the three of you.  The larger groups can easily break down into smaller factions and then you just have group A arguing with group B, sometimes outside of the meeting and that is just plain bad.

Try to avoid the committee for your Revit deployment.  Find one or two competent and appropriate individuals to work through this important task with.  It will go much faster with a smaller group.

And, if someone complains, you change it.  But in my experience, the amount of complaints and changes to newly deployed software has no correlation to the size of your deployment team.

Media Control During Your Revit Deployment

Several years back, I went through a Microstation (with PArch – yeah to the Intergraphers in the house!) to ADT migration.  I would absolutely categorize major portions of it as a disaster.  At least looking back on it I would call it a disaster.  I was able to build on that experience to coordinate and control our ADT to Revit migration.

The migration is still technically going on, but we are nearing the end of the big push.  I feel confident that this time around things went a lot better, which in some ways is odd since hopping from Microstation to ADT is nothing compared to the hop from ADT to Revit.  For the most part, the first transition was “OK, instead of clicking this button, you click this button, and oh, yeah, you can have infinite layers and you have to save all the time.”  Huh.  When I put it like that I’m sad that I screwed it up so badly.  Anyway, the ADT to Revit transition is more like “OK, instead of clicking this button you need to completely change how you think about putting a job together.”

Wow, I really got lost in that one.

Anyway, one of my tactics for the Revit transition was to control everything that was put out to our firm’s general users about BIM and the software.  If it was about Revit, it was 1984 and I was Big Brother.  There were a couple slips at the beginning, but once I explained to my bosses what needed to be done, a filter was set up where any media, any meetings, any discussions any anything that involved BIM or Revit was put through a filter in our firm.  That filter was me.  I never before invited myself to meetings, but I started to.  Sometimes there were just donuts and the meeting had nothing to do with Revit, but that’s another story…

If you are working on your deplyment, if you are partway through your transition, it is not too late to make this important step.  It might not be you, but someone has to be seen as the BIM Master in your firm.  Not a committee.  You can’t have a hydra BIM Master.  I mean, there has to be a committe to help migrate standards, but there has to be a single face of BIM carrying the flag and mixing the Kool-Aid.

This might seem extreme and archaic, but it is so much easier to maintain control later on down when the deployment really ramps up.  I’ll be sure to take some time later to post some other thoughts on a successful deployment including how to be sneaky and why commitees suck.