Trying to install Creo3 m130. Nothing but creo agent errors on the two that I've done. Looks like this has been going on in the Creo world for a couple years.
So the solution is to jerry rig the install by setting creo_agent_exe_path? This seems like a simple to fix, should PTC not simply fix the install?
I have concerns about this. What about my current production Creo Elements pro version that still needs to be running? Will this need to change with every install?
Am I submitting to a lifetime of babysitting this env variable for 150 people?
No Takers? I do a search and find pages of people fighting this. The advertised solution does not seem to work so well.
No problems here.
CS104032 states the only reason you would have to set the environment variable is if you are running Creo from a network share.
From previous discussions with PTC you can't put that specific variable in the startup script. It has to be added to the client machine. And again this is only applicable if your running Creo from a network share. Your screen shots indicate you are not doing that.
You shouldn't need to do anything. It should just run. M130 works for me using the same install path you show. Installed on a clean VM in Windows 7. I made a shortcut on the desktop of parametric.exe and set the start in folder to the desktop.
If you do need to install an environment variable, you could add it to your install script using the setx command, you'll need to look up the syntax. I used this to prevent the windchill workgroup manager from auto registering Mathcad.
setx UWGM_SKIP_AUTOREGISTRY TRUE /m
If you are installing on a machine that had a previous version, make sure you rename or delete this hidden folder:
Thanks you guys. Tried all these. Notta.
I think the correct answer is " walk away from PTC, Install SolidWorks "
Honestly, I'd recommend doing what I do. Test out your install on a virtual machine. I use Virtual Box, from Oracle, which has an out-of-the-box install of Windows on it. That Windows has none of our security settings, firewall, etc. Just Vanilla Windows. Once you verify it works there, then you have a data point you can take to your IT group to see if they have done something to interfere with the proper install of the software.
I had no install problems on this vm. When the software is running, there are five associated processes. If any one of these are left running after Creo exits, they could cause a problem on a second startup of Creo. I'd look at killing nmsd.exe first, then see if Creo runs.
You might want to add these lines to your Creo startup script.
After testing the install, I grab the xml files from the pim folders and use those to create a silent installer. Instructions are in the install guide or you can look at my Creo Admin 102 presentation, it's attached to this converstation... Re: Creo 3 silent install
C:\ptc\Creo 3.0\M130\Common Files\bin\pim\xml\creobase.p.xml
C:\ptc\Creo 3.0\M130\Creo 3.0\help\creo_help_pma\bin\pim\xml\creohelppma.p.xml
C:\ptc\Creo 3.0\M130\Creo 3.0\help\creo_help_sim\bin\pim\xml\creohelpsim.p.xml
I do not understand the meaning of your information that out-of-the-box install of Windows is available in Virtual Box. Do you mean that Oracle provides virtual machine with preinstalled Windows operating system ?
What I actually said was, "I use Virtual Box, from Oracle, which has an out-of-the-box install of Windows on it." I can see where my choice of words would lead to the conclusion that Oracle is providing a copy of windows in VirtualBox. No they do not. I'm the one that installed Windows on it, and haven't added any of our standard security settings on that VM. Typically these VM's are set to internal network, so they don't see the host and the host doesn't see them. I have another internal VM that is a virtual copy of my production license server so I can do testing of new license files and flexlm settings without affecting production. I'm now doing the same with our AutoCAD license server. I have a VM that's a copy of our production license server.
Working in the VM environment like this allows me to develop install scripts, configurations, etc, in a self contained environment. When I'm done I just have to copy the files to our production environment and do a final sanity check to make sure they work.
Working this way saves me a lot of headaches dealing with all the security roadblocks Microsoft and our IT department put in the administrator's way. We use a central software distribution solution that allows the end user to self deploy the software. When they select the application, it installs using local system, which has way more admin rights than I as an administrator have, and then it runs a post install script as the username, which allows me to configure the users environment and record who deployed what on which machine.
thanks for providing clarification . I am watching all your contributions in Community. Thanks for publishing your knowledge !
Thanks for your reply Dave. The software has installed correctly on about 80% of the machines. And they all have the same security settings throughout the building. As I see it, the first 5 machines I installed were fine, I don't see why there would be any issue with the others.
I've never seen software so fragile that it must be installed in a vacuum.