product focus 2012 Revit Structure Something similar exists in Revit, although not as editable, and not as transparent in location or functionality. Prior to 2012, we referred to it as the Revit.ini file—a text document residing in the Program Files directory that was written by the program when options, settings, and paths were changed. For years, power users have grown accustomed to editing the Revit.ini file manually and burying it in the root directory of their Revit deployment, which would populate the machines being deployed to with the correct configuration settings. Figure 2: Revit.ini file (2011) While it still exists, the Revit.ini file protocol underwent serious changes that may throw many implementers for a loop as they prepare to deploy Revit 2012. First, Revit.ini no longer resides in the Program Files directory. Users who aren’t aware of this change may drop it in the root directory of their deployment and discover (after deploying) that the stock Revit.ini file is used. In an effort to better support Remote computing applications and roaming profiles, Revit moved the Revit.ini file to a location in the Users directory (Win7), or the Documents and Settings/Username directory (pre-Vista). What this means, however, is that the location for the Revit.ini file may not exist until that user has logged onto the machine already. How this is handled is through a new file called “inifile.xml.” This document exists in a number of places, but for our deployment I edited and replaced the one at: [AdminImage]/ x64/RAC2012. (The same rules apply for all three verticals.) Bonus: With this new configuration, this one XML file serves as the installation configuration file for all three verticals, even using different templates and different file paths. (At The Beck Group we use all three Revit Platforms.) If you are accustomed to having a GUI for editing configurations, editing the XML may feel daunting at first. The downside of this workflow is you won’t know if part of your XML is faulty until you launch Revit and have unexpected results. TIP: If you don’t feel comfortable editing the XML directly, Autodesk has released a Deployment Utility to help with this: http://usa.autodesk.com/adsk/servlet/ps/dl/item?siteID=1231 12&id=17352374&linkID=9280927 On the surface, this file may look like abstract code. These lines, however, are at the core of Office Standardization and Management. This file contains controls for all of the following and more. Highlighting and Selection Colors, Paths and file locations for: Project Template, Content Libraries, Content Templates, CAD Import and Export Layer settings, “Places” Directory Locations, Custom Rendering Material libraries, Lookup Tables, Warning message suppression, User Interface settings, Help file setup, and Content search locations. With the new XML setup, you can also locate different templates and different options for the different verticals of Revit, saving you from having to write an XML for each product. BUT I DON’T WRITE CODE! No one was more up in arms about trying to manage an office with 2012 and XML than I was, to be sure. The perceived ease of use (or difficulty) of Revit lies in how accessible the right solutions are, and how inaccessible the wrong ones are. For me, this means having paths that work correctly when the user clicks on them, an Office Library that automatically shows up, and settings that don’t need adjustment by every user. With the move to XML, this was daunting. So, a few notes and samples from the XML file: What we once wrote in the Revit.ini file as: [Directories] FamilyTemplatePath=\\office network\Revit\2012\Beck Family Templates DataLibraryLocations=Families=\\office network\Revit\2012\ Beck Family Content (3d), Detail Comp=\\office network\ Revit\2012\Beck Detail Components (2d), Model Groups=\\ office network\Revit\2012\Beck Model Assemblies, Drafting Details=\\office network\Revit\2012\Beck Drafted Details, Material Images=\\office network\Revit\Beck Material Maps ProjectPath=C:\Temp Now gets written in the inifile.XML as this instead:

Figure 3: inifile.xml file (2012) 36 www.augi.com It gets tricky, just as it did with the old INI file. Some multi-entry fields are separated by commas, some by “pipes,” and some require July 2011