The 2013 Deployment (Debacle?) Process

The Malleristic blog has gone unattended for quite some time, as this has been about the busiest year so far in my career.  I suppose that’s good and bad at the same time.  In the midst of that, two things were happening simultaneously:  A few months ago, Revit 2013 was released; we were planning to purchase 150 new computers for our users at The Beck Group.  Naturally, this meant timing a LOT of deployments, for all Autodesk Verticals: All three Revits, AutoCAD Architecture, two verticals of Navisworks, and two verticals of 3DSMax… All for 6 different offices.  Yes, the licensing Gods were not with us, or the BDS Ultimate cross grades.  Cest la vie.

While this was happening, I was also hard at work making some big changes to our Revit deployment structure, and it seemed like the right time to pull the trigger.  So- this post is:  What was required, and where did it have to go.  In addition, how the ‘PragmaticReviteer’ Deployment tools helped us get there.  You know I'm not much of one for Product Plugging, but the list of necessities for successful deployment was substantial, and this tool saved me hundreds of hours.  (I'm focusing on Revit 2013.  I’ll mention how I used the PR tools to deploy the others, but not about the specific changes to THEIR 2013 deployments.)

2013 saw more file structure changes to Revit, meaning things that control your software aren’t where they were.  Here are the ones I PERSONALLY deem critical for deployment.  Your mileage may vary.  I’ll list them all, then explain the “why do you care” then explain how the PR tools make more of this possible than a standard Adsk deployment. One asterisk (*) means it’s a file you place in the Autodesk deployment.  Two (**) means the PR Deployment Tools take care of it for you.  Three  (***) means it’s your choice (but unanimously the PR tools are more friendly.)  Ill save you my long winded thoughts on where you should store all these files in your library.

First, this list:

Revit.ini / inifile.xml*
Revit.exe.config*
RSN.ini***
MaterialUIconfig.xml***
PhysicalMaterial.adsklib**
AECMaterials.adsklib***
UniformatClassifications.txt***
KeyboardShortcuts.xml***

Revit.ini / inifile.xml*- 2012 saw a shift from standard Text edited Revit.ini (which, in 2011, lived in the native Program Files/Revit Architecture 2012/Program directory) to the ini being seeded in UserProfile/AppData, but still from the Program Files directory.  2012 also so a shift, that we were now intended to edit an XML file called “inifile” instead of the INI itself.  The GOOD news about this, is it made things tremendously easier, if you had to support multiple verticals.  Well, in 2013, they recanted, and decided you could edit the ini text file again, and just append it in the deployment.  Direct support wasn’t give to editing the XML anymore, however Autodesk Revit Support was gracious enough to help me through it:  You CAN still use the XML.  (with 3 verticals * 6 offices, I wanted to reuse whatever I could.  One XML file creates ALL of the verticals deployments for a given location).  This XML goes INSIDE your deployment.  It lives in 3 locations (I thought it was 4, but I only have three).  Which one is the magic one?  No idea.  Replace all 3, and it works though.  Haha!

…\AdminImage\x64\RAC2013
…\AdminImage\x64\RAC2013\Program Files\Autodesk\Root\Program\Setup\Cache\sfCache
…\AdminImage\x64\RAC2013\Program Files\Autodesk\Root\Program\Setup\Cache\sfRxCache

Why do you care?  Here is what is setup from our inifile.xml (each vertical can be configured differently in one file):

UI Colors (selection, etc)
Family Templates
Library Locations* (this can be done through Pragmatic Reviteer tools, which works better. I only put one place here in the xml, because you have to)
Project Paths (local files)
Project Templates (BTW... The syntax changed.  Again.  Sigh)
Allowance for Online content from Autodesk (ours is disabled)
Allowance for users to access Seek (ours is disabled)
Allowance for RSS feeds, email notifications, etc (ours is disabled)
UI changes, including press+Drag, and DisableMPPAutoApply (annoying accidental auto apply of the properties palette)

 

 

Next is Revit.exe.Config*.  This lives in your Program Files\Revit Architecture 2013\Program Directory.  This also ONLY matters if you are doing what I am with addins.  Once the API opened up in 2010, I began to get worried about the Black Hole of support that would be coming, and- sure enough- its starting.  So many addins are coming out, and people want them. Then updates and changes becomes a management sinkhole.  Well… You have options.  Installed typically, they sit on the users machines.  If you have robust SCCM support, or some other mechanism, you can auto-push updates to DLL’s on to machines.  We have it, but it’s still cumbersome.  So, we are putting all of the DLL’s (basically installing the addins) on the Beck Network.  We configure those Shares with Sync Center (formerly Offline Files in WinXP), so disconnected laptops still work.  In 2012, you could do this without any changes to the program.  In 2013 (thanks to .net4.0), you need to edit Revit.exe.config, to add the following line under the

    <loadFromRemoteSources enabled="true"/>

That enables addins to run from non-local places.  The end result?  The next time an addin sends an updated DLL, I replace one file on the network, instead of 150.  Everyone’s is updated, as they sync or work off the network.  NOTE:  Don’t forget to re-path the locations in your Manifest Files. Also don’t forget to Unblock the DLL’s when you copy them to your network.  By the way, this isn’t without side effects:

1.        Its not supported by Autodesk.  Their official policy is that you shouldn’t do this, and that you should all have SCCM or some other software copying things to local locations, for performance reasons.

2.       It DOES have a performance hit, but only on STARTING up Revit.  Our start times ARE slower.  From icon click, to Revit UI responsiveness (past the splash screen), we have 36 seconds.  I accept this, as its usually a once or twice a day occurance.  Responsiveness in the program is completely normal.

3.       You want to configure those networked resources with offline files, or they wont work when you’re offsite.

RSN.ini***.  The good news is, you only need this If you roll with Revit Server 2013.  It goes in ProgramData\Revit Server 2013\Config\.  It is a simple text file listing all of the Host servers on your RSN.  It needs to be there for the workstation to have access to the Revit Servers.  This file (I think) causes a lot of confusion for new Revit Server users:  When they try to connect, they “see” the servers but cant access them.  Well, you don’t really *see* them, this file just tells your machine to list them.  We have 5 offices, and we are using all five servers as Hosts and Accelerators now, so this file just lists all of our servers.  It **only** has to list the Hosts (formerly Central's).  So if you are hacking workstations in to local servers like we are, that doesn’t matter.  Getting it on the machines:  Supposedly the Deployment tool can do it, but gosh… It’s too complicated for my simple brain.  So I used the PR_Deployment Tools to put this on every machine in the office.  Didn’t even have to think twice.

Why do you care? If you aren’t using RS, you don’t.  If you are, because copying it around on to every machine is a pain in the ass if you have 150 machines. 

Next is the Materials debacle, and it’s a doozy.  The short version:  The Material Editor changed in 2013, and it morphed in to a raging piece of junk (my opinion).  HOWEVER, the UI of the material editor CAN be made to ALMOST resemble the one from 2012 (although not the nice one from 2011… But hope is on the Horizon).  Here is where that gets interesting:

MaterialUIconfig.xml:  This is a file that lives in C:\ProgramData\Autodesk\RAC 2013\UserDataCache.  That means it also gets copied in to the UserProfile’s Appdata\Roaming location, with the Revit.ini.  This, you CAN do with your deployment, by placing it in the UDC of the Adminimage, but since the PR tools help you in so many other ways, simplify your deployment and have the PR tools do it.

 

Why do you care? If you aren’t aware, this little file does a lot for you:

It saves the UI state of the Material Editor.  (Switch all the mat lists to text style, no rendered preview, open the Mat Editor and place it next to the Mat selector, then close it.  Then grab this file from your machine and everyone will see it that way by default.  If not?  They are in rendered preview hell.

ALSO, this file is HOW YOU DEPLOY with a NETWORKED OFFICE MATERIAL LIBRARY.  If you have started an .adsklib for your custom materials, load it on your machine in the mat editor.  Then grab the UIconfig.xml file, and place that in your deployment, and EVERYONE has your materials.  We discussed this in Harlan Brumm’s class at RTC, and I misspoke, as I thought it wasn’t possible.  Thanks to Gordon at Pragmatic Reviteer for setting me straight.

Now, if you are me (which you aren’t, and I'm sure that makes you happy) part of setting up the Material UI is GETTIGN RID OF the Autodesk Materials.  And guess what:  They made it harder and harder.  I'm not sure why ,they are bent on us using their overly generic materials.  Well here is the deal: 

PhysicalMaterial.adsklib- This is the autodesk materials that you want to vaporize.  Trouble is, this file doesn’t EXIST anywhere in the deployment, it is instantiated later. The Pragmatic Reviteer deployment tools, however, include an executable that is run post-deployment, to automatically go in and REPLACE this file with a blank variant.  That’s the ONLY way to get rid of the Adsk materials.  (Note:  I'm not talking about getting rid of the render images, or assets.  The overall MATERIALS for revit.  If you have your own, you don’t want users having single click access to these, and the new UI forces them in your face.)

AECMaterials.adsklib*** - These are the materials called AEC Materials, which you CAN replace in the deployment if you want to strip them out and put your own in… But since youre already using the PR tools (if youre me) its easier to not have to mess with the deployments.

Why do you care?  Maybe you don’t.  But trying to tag all materials intelligently, using QC approved terminology, and getting correct Quantities from the models, and such, I cant have random junk Materials showing up in Models just because they are easily accessible in the UI.  So they are removed.

And finally, there is User Data.

UniformatClassifications.txt- Now, this one is easy to take care of.  It goes in UDC and User App Data, with the other stuff above.  So you can handle it in the deployment, OR with the PR tools.  Since I have all three verticals to deploy, using one script to handle it, versus copying it in to all 18 deployments, was the way to go.

Word of warning:  We were years in the making, on pulling the trigger for this change, but it’s not something to take lightly.  You want to do it at a version change, and you want to make it a year you DON’T force project teams to upgrade.  Here is why:

1.        It involves opening every single file in your library, and redoing assembly codes for Every Family Type, in every file.  A family Type that has an old assembly code will still work, as long as no one goes in the type properties.  If they do, it will force them to pick a currently functional assembly code, or it will cancel their changes.  If your users don’t understand this, they’ll be lost. 

2.       A project upgraded from the last year, will have the old codes.  But since Revit 2013 will have the new text file, the problem above rears its ugly head, unless you keep switching text files in AppData.  Yikes.

Why do we care?  For us at The Beck Group, this file is paramount.  In the 2013 release, re completely rewrote out UniformatClassifications file, and completely discarded the Autodesk one.  This isn’t a slam on the adsk file, at all:  Our Timberline Cost Database is organized completely different, and in the shorter decimalized format (B1010.150 instead of the longer old format the Autodesk one is written in.  It was also organized differently (Autodesk’s has wall finish and backup in one assembly code, we itemize them out.)  So it’s a great change to make, as exporting data OR schedules from Revit can now be mapped easier.

KeyboardShortcuts.xml***- Obviously you know what this one does: it’s your keyboard shorties.  You can handle it in UDC, either within all of your deployments, or with the PR deployment tools.  But here is one more place where the PR deployment tools give a massive advantage over standard deploy:  You can tell it to GET the Shorties from the last version of Revit that’s CURRENTLY on the users machine.  That way, you aren’t just deploying the OFFICE standard, but that users.  I didn’t get to do this, since we were deploying brand new machines with new hard drives, but it’s a great feature.

Why do you care?  Because users don’t want to start over every year, making Keyboard Shorts.

More on the Pragmatic Reviteer Deployment Scripts:

You can visit Gordons site, to understand more about how it works, but the system gives you some other benefits which might seem small, but have pretty decent returns.

1.       Places (File open, save dialogues).  Of course we can handle this with the Revit.ini, and they end up underneath all of the standard Windows stuff (out of sight and sometimes out of mind).  The PR tools afford you the ability to place your libraries in the Places, but do so ABOVE the standard windows things. It’s a nice benefit.

2.       Desktop Cleanup and Taskbar Shortcuts.  Again, it’s a quickie, but I like that, since I place icons in the taskbar to let people know ive installed something new.

3.       Multiple Deployments.  This is where the rubber hits the road, for me.  The PR tool is a single click instantiation, to deploy whatever you have told it to deploy.  So with a single click on a Users Workstation, here is what happens at Beck, in order:

a.       Navisworks Simulate 2013, Navisworks Manage 2013, RAC2013, RME2013, RST 2013, ACA 2013, RACupdate1, RMEupdate1, RSTupdate1, 3dsmax 2013, 3dsmaxdesign 2013, all installed per deployments.

b.      Kiwicodes Family Browser installed and configured. Revit DB link, Model Review, eTransmit, hatch22, AaronsGETid, all installed.

c.       Revit Server Configured

d.      Comm Center disabled (bonus)

e.      Material issues Fixed.

Then the user logs in, and one final script runs (three minutes) that seeds their user data shortcuts, etc, and they are off to the races.

Obviously, for this to have a big time save, you need to disable UAC prompts temporarily through either Group Policy, SCCM, or using an elevated admin that isn’t subjected to UAC at all (even clicking OK).  If UAC prompts exist, you still need to be there to click OK, which is to be expected.  So we push the single script through SCCM, and UAC never pops up.  Literally, from home I can deploy every Autodesk Product and API addin (something we havent gotten from Autodesk yet, sigh), and be cooking dinner while 50 machines get 11 installs.

What does it take to use the Pragmatic Reviteer setup?  Well, there are some scripts to edit.  Here is the thing about that:  Writing code is the one class in I actually failed in school, and these are set up simply enough that I can handle it.  That means any of you can, without hesitation.

Here is what I suggest, though:  Sit and talk with Gordon while planning out your next deployment.  File locations, permissions, and access play an important role in this.  As his solution is new, 2013 was my first year using it, but I am CERTAIN our 2014 deployments will be seamless.  And ill remain ever optimistic that 2014 really delivers, to make up for this Material Editor. J  Check out his website, he’s got a lot of interesting solutions in the works.

http://www.pragmaticreviteer.com/