.ini files in network deploys

[Dave Lewis]

I need to create one network deploy that can be installed in multiple offices
In RAC2009\AdminImage\RevitSetup\RevitBuilding\Revit.ini there is

IESFileLocation=\\serverlocation\RAC2009\Content\IES
[ContentInstalled]
ENUTutImp.cab=\\serverlocation\RAC2009\Content\
ENUTutMet.cab=\\serverlocation\RAC2009\Content\
IES.cab=\\serverlocation\RAC2009\Content\IES
ENUHelp.cab=\\serverlocation\RAC2009\Content\

In other offices it has been observed that the silent network deploy will call back to the location where the original deploy was created, thus installing over the WAN
How do I stop this?

[Devin_82]

I am dealing with this issue right now and so far all I have been able to come up with is creating two separate install files. I downloaded the .exe file from the subscription for the install in each office and set up two separate installation files locally in each office's server. If you are worried about the content management aspect of having all the content in different locations you could set up some sort of mirroring process between the local install locations that runs at a time of day that the network is freed up a bit (like 2am).

Another option my IT guy and I were going to try out, though more complicated, was to go into the .ini and look for all instances where it is pointing to a network location and manually change it. This can be pretty tricky because the .ini also points to multiple other install related files that point to network locations as well. So you end up having to browse through a lot of text to find it all. We started this process but ultimately abandoned it for the above process.

If you come up with anything better or different please post it. I would be eager to see it. There are plenty of things that I don't like about the way we have set it up.

[Dave Lewis]

That process is ridiculous
I have 13 offices and 3 versions.
There is no way I am manually modifying 39 deploys and each deploy has 4 ini files.
I'm not attacking your deploy, just saying there must be a better solution.
At my last company we deployed Revit via SMS packages.
SMS has deployment servers in each office and one master server.
So I know the ini files were modified post autodesk setup.exe
I just don't know how they were modified.

What I am doing now is creating a custom .bat file that is office agnostic. It figures out what server path it is being launched from and then issues the equivalent of the shortcut .lnk

My issue is modifying the revit ini files.

[bcgatti]

We have a common naming convention for our commonly utilized network shares between our offices. We also utilize replication of certain directories between the office servers. You will see the same common name as the root share - regardless of which office you happen to be in.

Ex: "\\cad_root " would be the same for any and all offices and it will contain all necessary files and directories (the availability of specific file and directories is defined on an as needed basis per office). In this scenerio, each office only sees their local (replicated) version of "\\cad_root". They do not see or refer back to that directory name at a different location.

Using this method has allowed us to create one deployment per software package and load it at any office. The deployment does not know (or care) that it is not in it's original location because all of the directories and files that it refers to and installs exist on each server (and are loaded/installed from the local server only) through replication.

[Dave Lewis]

There is a few problems with that for us
#1 the customers do not have the ability to install software
#2 our software installation folders have serial numbers and other sensitive information within them.
#3 we have a hidden software installs folder in every office and under there it varies with every office. For example office 1 may be a structural office so they need enercalc & ram while office #2 may need mechanical software and office #3 needs sketchup. We cannot replicate our entire software library to every office nor do I want to maintain 2 folder structures.

I appreciate your point, its just that we cannot use it :(

[bcgatti]

I fully understand where you're coming from and your concerns. Every organization is different and every company has their own methodology for protecting and safeguarding their data.

However, just to clarify; I think that you may have misunderstood some of my comments (or I just wasn't very clear). I'll comment to each of your numbered points.

#1 - Someone with adequate rights is still responsible for running the deployments on each computer. End users in our offices cannot install software.

#2 - The end users do not need to see these folders - just the person (people) who is (are) responsible for the software installs. We control folder access and installation rights on a "group" basis.

#3 - From my last response: "the availability of specific files and directories is defined on an as needed basis per office".

This applies to replicated software installation folders as well. The full software library does not get replicated to each office. We are somewhat split up by discipline as well so we don't replicate all items to all offices. Each office has specific software needs and they only have access to the items that they require and once again, the end users do not need to see these folders.

Brett

[Dave Lewis]

Agreed except the IT department does not use any mapped drive letters.
Often times the IT department just does a runas to install software
We have about 5 IT members that float across the company so it would be cumbersome for them to create mapped network drives on every workstation that they wanted to install some software.

[bcgatti]

We don't have any drive lettters mapped within our organization. Everything is done with UNC pathing. You just type in (or browse to) the path in Explorer to access the correct folder(s). This method allows us to access commonly named shares without having to figure out how to allocate drive letters between the different offices - that can be a nightmare.

The above noted method along with the replication of specific folders/directories to the local servers for each of the offices (on an as needed basis per each particular office's disciplines/requirements) has allowed us to commonize our deployments between the offices. The key is to have the root share named the same at each office so that the deployment .ini file does not see any difference (ex: "\\serverlocation" as noted in your original post - where each server will have its root share named "serverlocation") and it will always install from the local server (if the deployment information has been replicated to the same directory structure on the remote server).

Granted, this setup is not for everyone and I know that every organization has their own methodology so far as network infrastructure but this has worked pretty well for us. I have not seen an installation at any of our offices (done from a network deployment) look to a different server or pull files from anywhere but the local server - regardless of which server the deployment was originally created on.

[Dave Lewis]

ok lets say you have 2 offices, Newport Beach and Newyork
So you have 2 deploy locations
\\newport\installs\RAC2009 &
\\newyork\installs\RAC2009

How am I going to have the same path in 2 offices?

[cstanley]

ok lets say you have 2 offices, Newport Beach and Newyork
So you have 2 deploy locations
\\newport\installs\RAC2009 &
\\newyork\installs\RAC2009

How am I going to have the same path in 2 offices?


I believe it's more like this:
Newport has a drive R:\installs\RAC2009 and
New York has a drive R:\installs\RAC2009

that way you deploy to both locations, and when the install occurs, it just looks to the R: drive for that local office.

That also the way we have it set up...

[truevis]

I recommend making compiled install scripts -- AutoIT or AutoHotkey. This also has the advantage of being able to Run-As Administrator/Password for the setups, so users can even do the installations themselves.

Any file copying or INI mods can be done, too. One can use full network paths; drive letters aren't needed.

[bcgatti]

I believe it's more like this:
Newport has a drive R:\installs\RAC2009 and
New York has a drive R:\installs\RAC2009

that way you deploy to both locations, and when the install occurs, it just looks to the R: drive for that local office.

That also the way we have it set up...

Exactly. The only difference being that we don't actually map to drive letters. Your example of "R:\installs" would equal our "\\cad_root."

[Dave Lewis]

what?
How would you not map network drives?
I have a dozen servers
Each server is named differently
\\server1\
\\server2\
etc.....

How are you going to have \\cad_root\ in every office

[bcgatti]

what?
How would you not map network drives?
I have a dozen servers
Each server is named differently
\\server1\
\\server2\
etc.....

How are you going to have \\cad_root\ in every office

Each office has it's own series of servers. Each office has a share established on one of the servers named \\cad_root\. Note: this share does not necessarily need to exist at the root of the server, it just needs to exist. This share contains whatever software installation files (deployments, etc..) that are required based upon that specific office's needs. This share is populated (as needed) on each satellite office's server via replication from the "master" server at my location.

We also share configuration files, templates, profiles, etc..(Revit, AutoCAD, etc..) between offices using this method as well.

Here is a portion of the Revit.ini file from my computer (I've also attached a screen capture of a portion of my AutoCAD configuration showing the same methodology):

[Revit.ini]
[Directories]
DefaultTemplate=\\cad_root\Revit_Support\Revit 2009\Imperial Templates\RAC Project Template.rte
FamilyTemplatePath=\\cad_root\Revit_Support\Revit 2009\Imperial Templates
DataLibraryLocations=Imperial Library=\\cad_root\Revit_Support\Revit 2009\Imperial Library,Imperial Detail Library=\\cad_root\Revit_Support\Revit 2009\Imperial Library\Detail Components,Training Files=\\cad_root\Revit_Support\Revit 2009\Training Architecture 2009,Revit Local Folder=C:\Revit Local
ProjectPath=
ImportLineweightsNameDWG=\\cad_root\Revit_Support\Revit 2009\Imperial Library\importlineweights-dwg-default.txt
LookupTableLocation=\\cad_root\Revit_Support\Revit 2009\Content\LookupTables
IESFileLocation=\\cad_root\Revit_Support\Revit 2009\Content\IES
MaterialLibraryFiles=\\cad_root\Revit_Support\Revit 2009\Rendering\assetlibrary_base.fbx
ExternalParameters=\\cad_root\Revit_Support\Revit 2009\Imperial Library\Shared Parameter.txt
ExportLayersNameDWG=\\cad_root\Revit_Support\Revit 2009\Imperial Library\exportlayers.txt

I hope this helps to clear things up a little and doesn't just muddy up the waters even more.

Brett

[Dave Lewis]

Yes each office has its own server with a "installs" folder
How does that get one ini file for every office?

\\server1\installs\RAC2009\
\\server2\installs\RAC2009\

\\CAD_Install\RAC2009\ would be one server installing over the WAN which is not what I want

[bcgatti]

Yes each office has its own server with a "installs" folder
How does that get one ini file for every office?

\\server1\installs\RAC2009\
\\server2\installs\RAC2009\

\\CAD_Install\RAC2009\ would be one server installing over the WAN which is not what I want

Each office has it's own version of \\CAD_Install (file://\\CAD_Install) (to cite your example). This share is established in every office and it contains (via replication) the necessary files for that office. The deployments look to the local version of \\CAD_Install (file://\\CAD_Install) and it never looks outside of that offices server structure. It never looks back to the "master" server.

To use your example server names - the common share name between offices, would be established at the "installs" level (your "\\CAD_Install" would = "\\server1\installs"). It would not refer back to "server1" or "server2". Therefore, the deployment never looks higher in the tree than the common share name that was established and named at the "installs" level. Due to this it doesn't care what the server name is (it never sees that far up) - it only cares about the established common share name in that office (\\CAD_Install).

[Dave Lewis]

That does not work
a double back slash tells windows that is the server name
\\cad_root\ would mean that there needs to be a server called "cad_root"

Can you post part of your ini files from your AdminImage
for example

#==================== Global MSI Properties
#DEPLOYMENT_LOCATION=\\newport\installs$\RAC2009

[bcgatti]

I've attached a slightly modified version of AdminImage.ini - renamed to AdminImage.txt so it would post - from our 64 bit RAC deployment.

In the section that is noted below, \\cad_root (file://\\cad_root) is a local alias for the server name. As an example, the server name could be \\server1 (file://\\server1) (\\server2 (file://\\server2) and \\server3 (file://\\server3) could be server names in other offices) but it's alias (local share name) in this example is cad_root. Each office has it's own alias (\\cad_root (file://\\cad_root) in this example) for their actual server name.

#==================== Global MSI Properties
EXE_SET=REVIT
DEPLOYMENT_LOCATION=\\cad_root\cadsetup\Revit\Architecture 2009-64bit
DEPLOYMENT_PLATFORM=x64\\

We utilize this method and a single common deployment (replicated to the offices that require that specific software) to install all of our AutoDesk software at all of our offices.

HTH

[Dave Lewis]

Then how are you setting an "alias"

[bcgatti]

Distributed File System / DFS Namespaces

http://www.microsoft.com/windowsserver2003/technologies/storage/dfs/default.mspx

[Dave Lewis]

oh?
DFS
Why didn't you say that 2 days ago :P

[bcgatti]

oh?
DFS
Why didn't you say that 2 days ago :P

and here I thought I was doing a bang up job of explaining, but I do have a bad habit of sometimes going all the way around the block just to get next door....:screwy:

[heath.simone]

If you wanted to you could create a vbs script that would temp create a drive mapping based off scriptpath (where the script is being run from) after the install's finished disconnect the mapped drive and your done. This will allow you to get around the content installation problems also (full and download paths in the content.rcl files).

i know it's an old post but figured i'd post it anyways for anyone that searches for help.