How do you manage your Pro/ENGINEER configuration files?

[mmeadows]

I know there are several methods for managing Pro/ENGINEER configuration files. I would like to build a list of the various, or at least most common solutions.

I will start by briefly describing my favorite. This works very well in a single-site Pro/ENGINEER configuration.

1. I centrally manage all "corporate" configuration files on a shared network drive called "ProSystem" and map it to the P drive for each Pro/ENGINEER user. I have also seen "pro_stds" as the folder name. These standards are read-only to the Pro/ENGINEER users and only a couple of responsible individuals have read-write permissions.

2. A shortcut on the desktop for each user points to the Pro/ENGINEER launch script at P:\bin\proestart.bat. The launch script is a batch file and can perform various actions like cleaning up the startup working directory, offering users a choice of what Pro/ENGINEER license to run, or allowing an upgrade testing team to run Pro/ENGINEER Wildfire 5.0 from the same desktop shortcut as Pro/ENGINEER Wildfire 3.0.

3. Among other things, the launch script copies the corporate standard configuration files (P:\configs\config.pro, config.sup, config.win) into the text directory of Pro/ENGINEER before launching Pro/ENGINEER. It also sets the Windchill local cache to a unique and accessible location.

The standards are secure, only modifiable by qualified people. Updates to the standards are easy to roll out, just make changes to the ProSystem content and the users' standards will be updated the next time the start Pro/ENGINEER. The infrastructure can be extended to support multiple sites relatively easy. I create identical ProSystem structures on each of the replica servers and use a distribution script to clone the master set of configuration files to each of the file servers.

It isn't a perfect solution. I've found it challenging to support individual remote or off-line users.

It goes without saying that this technique or any of the others that get posted here are not supported by PTC. However, it works very well for me.

What are your techniques? Don't get too detailed yet. The idea is to vote on the responses and then detail the more popular techniques.

Thanks,

Matt

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.

[Marc-AndreVervi]

I use exactly the same technique.

Works well for me!

[ptc-321702]

During the loading of Pro/E and Intralink by the use of a startup script, the default config.pro file is recopied to the users computer in the c:\ptc\text folder along with other config files being copied to the D drive. By doing it this way, we are assured that the latest version of the config.pro file is loaded on everyone's computer. We also have a folder called d:\proiwork\username\NE\user_config on everyone's local system that has specialized config files in addition, allowing each user to store their own config.pro files. If there is a need to customize the c:\ptc\text\config.pro file, then the user needs to change it to read only after editing it.

[pwyndham]

We use the same method of copying the config files down from a server drive during the launch script.

It would be nice to get away from old DOS batch files. Then you could make it more user friendly and more functional for running, editing and using.

I am thinking about writing something.

[mmeadows]

I just uploaded a document on how to create a Pro/ENGINEER launch script. My hope is this helps those companies who don't control their configuration files today take control. I'm also interested in what others have done in this area. For instance, different scripting languages, different approaches to the document's use cases, or additional use cases and how they were addressed.

[ptc-147699]

Matt - good document; I'm going to add a few things and email back to you. We have 6,000+ users at John Deere, so effeective administration is a key aspect of reducing our TCIT.

Paul Crane, John Deere Ag & Turf Division

[mdebower]

We have it set up on the server, but am always looking to improve. Good info! I look forward to your input too, Paul.

-marc

[JoshH]

Great discussion folks!

In my little pond (approx. 30), users have had a great deal of latitude, especially due to working in "offline mode". The general rule I go by is that everybody gets standard configs from the same type of server location on install. From then on, they have control over any config in their startup folder. If they ask for support or something else points to a problem with their system, their modifications are wiped out and replaced with completely standard configs. This is rare, but it happens at times.

In the larger standard corporate enviornment (1000's of users), there is an application startup that copies everything from the main server and sets all defaults every time. It's programmed through Visual Basic and allows choices for Pro/E license, Pro/E Release (WF2 or WF3), Intralink or Windchill as well as add-on modules, etc.

[JoshH]

Sure David,

it was built in-house by a really sharp admin. (not me).

It handles:

• Where you are getting licenses and what server to download stuff (necessary due to many global locations).
• Default units, e.g. ANSI or ISO
• Performance settings (for netmeeting, large assembly, etc.)
• Allows choices for licenses (rendering, analysis, etc.)
• Working directory
• Set-up of locked license for those traveling
• I believe it is all done in Visual Basic
• Used to launch any Pro/E session and downloads updates as required
  • Based on user response to the above requirements
  • Updates release or configs if required

[JackBender]

This thread is old, but I thought there is something to contribute.

At our company, our admin came up with a way of having a generic config file with customizations for every individual.

Creo Parametric is launched through a Windows batch script that creates a custom "config.pro" file for the current work session.

1. The startup script is launched by the user (shortcut on desktop pointing to a .BAT file stored our network attached drive, so that everyone has the same centralized launch script)
2. The user is prompted to enter the number associated with its identity (John is user #1, Wendy #2, Paul #3, ...) and press Enter
3. The script copies a generic config file "base.pro" from a config directory on our network mapped drive to "C:\Users\Public\Documents\config.pro"
4. The script then appends a custom "personal.pro" from the specific user's config subdirectory to the newly created file "C:\Users\Public\Documents\config.pro"
5. The script then starts Creo normally

It doesn't matter if the same setting appears twice or more in the "config.pro" file, only the last one read by Creo will be the setting applied. So, a user can alter a setting found in "base.pro" by adding the same setting to its "personal.pro" but with the value of its choice.

Generic changes in configuration can be made in the "base.pro" file and will take effect for every user on next Creo launch.

Personal customizations are made in the "personal.pro" file by users themselves or by the admin on their request.

For our simple IT setup, such a solution offers the advantageous possibility for users to use Creo on any computer and still load a customized config.pro.

Our admin also plans on adding management for the various "creo_parametric_customization.ui" in the same centralized and dispatchable way.

[AndreasSiedler]

Our config for Creo based on the following four config - files:

1. config.sub

-- all setting which are essential for your configuration

2. config.pro (install dir)

-- basic configuration

3. config.pro (working dir) [fixed due Windchill]

-- standard configuration

-- created by a start script, based on

--- language

--- with / without Windchill

--- user ID

4. User config

-- loaded by the user via a mapkey

--> as standard all user shall start with a basic configuration, then it is easier to locate "config mistake" by the user.

[mbraaten]

We use a script that copies the config.pro and sup to the C:\temp folder each time Creo launches. The configs in C:\temp folder are linked (mklink /d <link> <target>) to the load point text directory. This ensures that the latest config.pro and sup are available every time the users launch and also makes sure that they can have both a home directory config.pro and a start up config.pro.

True, the use could remove or modify the config.pro and sup in the C:\Temp folder but only for one session. So far, we have not had any issues with this.

[ToddWoodall]

Where are the ones of you that run Windchill storing the master copy of your config.pro and config.sup before you copy it out to the users. Is it possible to copy it out from a Windchill Library in the startup script before Creo starts or do you have to maintain them on your network somewhere?

[swood]

We are in the process of joining several business units in a global Windchill database. In order to make sure everyone is playing nicely, we would like to set the basic required settings in a config.sup and have each machine copy it to their PROE_TEXT_DIR each time they launch. We have been successfully copying the file from our local server at our BU, but now that we're going global, we want it in Windchill.

We were using this line in our .bat file, and it worked great:

copy %PRO_STDS%\scripts\aquapart\config.sup %PROE_TEXT_DIR%\config.sup

I tried to revise it based on the way database locations are set in the config.pro, and came up with this:

copy wtpub://Aquapart/Libraries/CAD Components/Settings/NA\NA_config.sup %PROE_TEXT_DIR%\config.sup

Unfortunately, that doesn't work. The first error I got said it didn't recognize the wtpub, so I removed that. It now says it is a syntax error.

Can anyone help?

[mmeadows]

If I understand correctly, you want to maintain the corporate standard config.pro and config.sup files inside Windchill.  This is not a practical approach as Creo does not access Windchill until after it has launched, read the config.pro/sup files, and prompted the user for login.  Most of the Creo schema (templates, formats, library objects, etc.) are managed cleanly in Windchill because Creo There are a few files in the Creo configuration that aren't meant to be managed inside Windchill (launch scripts, pro/sup, psf files, .ui, etc.).  These should still be managed from a network location or a source control system like BitBucket.

Copy and other file copy commands commonly available in Windows won't recognize a URL (wtpub://...) as a source location.  You could Google for custom commands to copy from a URL to disk but now you need to make the utility available to all users.  Then you would have to store and pass Windchill credentials for each user and this will most likely be a security issue.  It is just a messy, ugly way of working.

FYI: All currently supported Creo workstations include robocopy by default.  Robocopy is preferred over copy because it will copy the files if they are different and will not waste time or network resources copying if they have not changed.  Syntax example...

robocopy /mir %PRO_STDS%\scripts\aquapart %PROE_TEXT_DIR% /IF config.sup config.pro tree.cfg

[swood]

Thank you for that info. It stinks that we have a document control system and cannot use it to control these documents, but so be it. The BU admins will have to be notified and responsible for copying corporate files to local networks for installation.

I'll make the revisions to our .bat file to use robocopy. Thank you for that tip.