Advice on potential Pro/E installation configurations

[bbailey]

Hi All,

We are looking at some options for Pro/E installations. I would very much
like some thoughts on a couple of points under consideration.

The first is a proposal to consolidate the 32 and 64 bit Pro/E folder
structures. The thought is that these structures are the same except for
a few, easily recognizable areas that could be accommodated by having both
the 32 and 64 bit pieces included. One could use a folder comparison
tool, such as Beyond Compare to determine the exact differences.

The second thought is to bypass the standard Pro/E start scripts and
executables such as proe1.bat, proe1.psf, config.pro, etc. in favor of a
new script/executable (not sure which) that sets the environment
variables and config options in a controlled fashion, then calls the
binaries such as proe.exe. For example the config.pro options would be
read from the various locations as Pro/E does and combined into one
config.pro that would then be used.

I am interested in your thoughts and advice on the viability,
supportability, and advantages/disadvantages of these options.

Thanks,

Ben


This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[kbrault1]

Hi Ben,

We do almost what you are asking to do. We have a batch file on a server share with a shortcut to all the user's desktops. The batch file combines config.pro's (unfortunately this does not work with the config.win file), sets the environment variables, checks version of ProE and Intralink (pulls down newer version if required) and does several other things, then starts ProE from <loadpoint>\bin\proe1.bat.

Kevin

[dgschaefer]

I missed your original post.

We do #2, to a point. We have a *.bat file (actually a series of nested
files) that do a series of things like ask the user to choose which
client they are working on, copy the company config.pro & config.win to
the loadpoint, make sure the user has a config folder on the server,
create a config.pro for that user and that Pro|E version if non exists,
back up the user's config files locally, set the start up working
directory to the user config folder so that the user config.pro &
config.win loads after the company files and lastly sets a trail file to
run, if needed, which loads a client specific config.pro based on the
user's choice of client.

At the end of it all, it calls proe.exe directly.

We don't combine config files, we simply make sure the right ones are in
the right place and that Pro|E launches from the right folder so they
all get read.

Doug Schaefer

[pwilliams-3]

Ben,
We have our 32 bit clients installed directly onto the user's workstation. We have C# application that the users execute first to start Pro/INTRALINK. The application configures the Pro/INTRALINK and Pro/ENGINEER environment by setting environment variables and copying the proper config.pro and config.win files into the text directory. This application looks up the domain of the current user to determine what license server should be used (we have 3). Once the user makes his choices the Ok button is clicked and Pro/INTRALINK starts. Here is a screenshot.

[cid:image001.png@01C9D85A.FE2120D0]

Patrick Williams | Sr. Applications Engineer | Engineering Systems | Steelcase Inc. | 616.698.4078 | My Site<">http://my.steelcase.com/Person.aspx?accountname=NA\PWILLIA3>

[cid:image002.jpg@01C9D85A.FE2120D0]

[pperry]

Ben,

We use a product called WinBatch and have written a Windows Batch job. The batch job is on a mapped drive that all Pro/E users have as part of their login. The batch job copies all system files the local computer using robocopy (i.e. config.win, config.pro,and config.sup). We also use it to upgrade Pro/E and Pro/I.

The reason we chose this method is we have 3 different Intralink installations. One of the key functions of the batch job is to copy the tnsnames.ora file for whichever Intralink installaton selected -- this way we only need one Intralink loadpoint. I have not yet converted it to identify the user's host machine (32bit vs. 64bit) but from what I have read this is reading one variable and making a logical choice based on the system variable.

We also use the batch job to set up the variables for other software (e.g. Microsoft Word). The only issue we have had here is the paths are hard coded into the batch job and if someone loads software in a different directory that variable is not set (i.e. Adobe uses revision in the load directory).

A little different than what others are doing, but some of the same concepts.

Patrick Perry -- BAE Systems

[JohnGetty]

Hi Ben. You're proposed action is essentially what I do at our site. I have a couple suggestions though. I use a preproduction environment on my server to allow advanced testing of new configurations, formats, seed parts, symbols, etc... Basically it's PREPROD and PROD folder on the network drive. I then use an environment variable (PRO_ENV) to control the network location Pro/ENGINEER references. I also have two batch files on my client machines, one called [proever]_startup.bat and another called ProE.bat. This allows me to replace the actual batch file if necessary as well as still load ProE if the network is unavailable. So basically the [proever]_startup.bat copies the standard files (.psf, .dmt, .sup, etc...) and then the ProE.bat actually kicks off the application. I also delete all .psf files before copying the files to the PC to help catch anyone trying to cheat the system.

I like your idea of combining all the config.pro options. That probably would help with roaming profiles.

Regards,
John P. Getty
Mechanical Engineer
Mechanical Engineering Technical Apps Support Liaison
Northrop Grumman Corporation