Any 2013 Deployment creation how-to's?

[patricks]

Are there any meaningful how-to's out on creating a deployment with custom settings for Revit 2013? I see there are some options as far as including custom Revit.ini files and something about a inifile.xml I think. I have no idea how to use or modify that stuff. I *REALLY* want to have all the file locations and everything as part of the deployment so I don't have to go around doing it every time.

Would it be as simple as installing it on my own machine, getting everything set, and then using the INI file on my machine in the deployment?

*edit* I went back and looked at the 2012 Deployment threads, and there was a link posted to this Deployment Creation Utility from Autodesk: http://usa.autodesk.com/adsk/servlet/ps/dl/item?siteID=123112&id=17169612&linkID=9273944

Will there be something similar for 2013 or is this utility already built in with the 2013 deployment creation process?

[patricks]

I don't know, it may actually be less time for me to just set it up on each machine rather than spending the time and trial-and-error trying to get a deployment right.

[rosskirby]

Try this: http://www.youtube.com/watch?v=6QgVxfpsPoA

[patricks]

Yeah I watched that last night, not sure how that DFS stuff relates to our setup. We just have a server in the back room running a domain for the office, and all users have a domain login that runs a login script to map several shared folders on the server as drive letters on the workstations. However I did notice when setting up the deployment that it wants the deployment location specified as the UNC path, i.e. \\server\revit2013\deployment instead of the mapped driver letter path.

I guess my question is should I go ahead and install on my machine, get it set up, and use my Revit.ini file as the basis for the INI used in the deployment? And if so then do I even need to mess with anything in the inifile.xml file?

[rosskirby]

That's pretty much what I'm doing (setting up mine first, then pushing that out as part of the deployment). It doesn't seem like we even need to mess with the inifile.xml anymore.

[patricks]

okay cool. So have you been able to get the deployment to work correctly with all the options set up after installation, or are you still working on it?

I'm trying to get a big project out this week so will probably try it myself next week.

[patricks]

Oh, haha I guess DFS is what we have - just the definition of having files stored on a server that multiple users in the office can access. I had not heard the term "Distributed File System" used before to describe this setup.

[patricks]

I went back and watched the video again. I believe this is essentially what I need to do. Only thing I wonder about is that error about the Project Path being relative, which he then changes to the UNC network path of his content. Does that not change the Location setting for user files, or not? Reason I ask is that needs to be set to the user's local Documents folder on our machines. So could I make that line say ProjectPath=C:\Users\%USERPROF­ILE%\Documents instead? This would be for a Win7 installation.

[heath.simone]

Just a question why you want the content local to each machine and not centrally stored on the network?

Is that only the Autodesk content or all your content that is stored local?

[patricks]

That's what I'm asking - is ProjectPath referring to the option in File Locations where user documents are stored? Normally that's assigned to username\Documents which is why I was asking.

We typically install the content that comes with each Revit release on the local machine, but still path to our server as the default Library path.

[heath.simone]

I look at Project path as a working folder for revit files. We have this set to C:\Users\Public\Documents\...\Revit\Projects so any user can log onto the machine and access the files vs in each individual users profile.

We install all the content onto the server once - as a single repository and then in the deployment image i remove all content installs. Our guys don't get any content packs installed locally. I also put all the IES and Lookup tables onto the single network repository also. It just makes it easier to maintain continuity, only the CAD Admins have access to place new content onto the network store after it's been verified by one of the product champs. I just do a basic standalone install with all the required content packs ticked to install, once they have all been installed onto the machine - i just copy them to our network share ..\REVIT\Sample Content\2013.

You can remove all the content packs from being installed by removing the information between the first <ContentPacks> and last </ContentPacks> in the content xml files in your deployment image (...AdminImage\Content\Revit)

Looking at the deployment image creation wizard there is a part where you can load a revit.ini file which will alter the revitini xml file for you so you don't have to go through and alter the xml file yourself. So yeah if you don't like xml just do an install customize it to how you want and then upload it in the wizard.

I'm just starting to look at Revit onebox deployment now.

[hermeytheelf]

Reviving an old thread here, hopefully you guys are subscribed to get updates.
Our deployments are very similar to the method that Heath describes. Using the custom .ini file seems to be the way to go. I have found that instead of modifiying a deployment after the fact using the deployment tools you should be able to directly edit the custom .ini file that you created. The deployment stores it here \\SERVER NAME\DEPLOYMENTNAME\AdminImage\CustomSettings.

One thing that I am struggling with is the location of some files that by default are installed to the ProgramData\Autodesk\RVT 2013 location. In particular, the DWG export layer.txt files. I had these mapped to a network location in my .ini file but when you open the fresh install of Revit and create an export to .dwg you are still promted to browse to the ProgramData location when you want to reference a custom export layers file. It's making me think that I need to keep the default location for this in the deployment and then add our custom files there. This would also apply to .pat files and import lineweights.txt files. Anyone know a way to redefine this default location?

Regarding oneBox deployments, we are on an ELA and NOT a Suite. Autodesk told us the only way that we could create oneBox deployments was to use the Building Ultimate Suite. This has proven to be a major pain in the a$$ and my deployment kept failing, getting 'file copy failure' messages. I have now used the trial download from Autodesk and created a deployment from that. It is pulling from our ADN license pool using that serial # and the product key from the Building Design Ultimate Suite. The next step, once our primary lic file is functional, is to see if it will successfully pull a licence from that pool. I don't see why it wouldn't but perhaps someone else may have some nuggets of wisdom here. :-)

[heath.simone]

Hermey,

Sorry i only just saw this...

If i remember correctly (it was a little while ago and a whole lot of software deployments ago) the CustomSettings folder stores the custom revit.ini but it does not copy the file from within the deployed network image - it used it from the original deployment creation location. We use SCCM and have the deployment image on about 15 servers internationally so any content that doesn't reference that the package it's being called from - typically has to connect internationally to the original deployment creation location and copy the requested content to the location the installation is being run from. This was a massive issue in the past when our company was installing the content locally on the users machines.

If you can find a Vista 32bit machine and copy the contents of the USB key to the machine you can do the install from the suite source. It's such a HUGE PAIN IN THE BUTT this damm issue with copy fail / write protection with the Building Design Suite, it also happened on a couple other suite installers i had as well. It took way way too long for me to try and create the damm deployments. You will still potentially get issues with intergrating / amending service packs via teh wizard - i now just add them in the vbs script for the install.

We don't use onebox due to the licensing issues we have with it - we have a couple non-suite migrated Revit MEP, Arch, Structure licenses; one box will not use theses licenses and we didn't want to have to create 4 deployments just to use Onebox... The standalone versions will use the suite licenses so thats not an issue, just more work for me.

I would have to have a closer look into how the .pat / lineweight information is stored / loaded to see how/where to edit it in the deployment. I also want to edit the default keyboard shortcuts, but just haven't had the time to delve into where they are located.

[controlsgirl]

Did you ever find a solution to this? I do want to keep the project files local for each user that installs using the deployment.