Re: Creo will not start for publishing

BenLoosli · ‎Oct 23, 2017

I have upgraded to CreoView 3.0m032 and now Creo will not launch to publish any files.

I have cleared all of the cache files.

I get a "did not find available worker" error message.

Any suggestions as to what I missed?

RandyJones · ‎Oct 23, 2017

@BenLoosli wrote:

I have upgraded to CreoView 3.0m032 and now Creo will not launch to publish any files.

I have cleared all of the cache files.

I get a "did not find available worker" error message.

Any suggestions as to what I missed?

Perhaps the exec_file path to the dll in the protk.dat? This will almost always change when updating Creo View Adapters.

dharlan-2 · ‎Oct 25, 2017

I'm assuming you checked the compatibility matrix to make sure that adapter works with your version of WC?

Did you rebuild the recipe and batch files?

BenLoosli · ‎Oct 25, 2017

Yes, the build install was requested by PTC and I verified it both with the tech and by the document matrix.

Recipe and batch files have been rebuild by the adapter_config program.

Creo runs on that machine when started standalone.

Creo will start when launched from proepublish.bat.

Creo does not start when launched from proeworker.bat.

BenLoosli · ‎Jan 08, 2018

Continuation of same problem but different versions!

I have upgraded to Windchill 11.0 m030 and installed CreoView Adapters 4.1 F000.

The WorkerDaemon starts on the publishing machine at startup from the GS Worker service.

The proeworker will not start automatically. I have to log into the publishing machine and start proeworker.bat every day. Once started publishing runs fine for that day.

Has anyone seen this issue with the system not fully starting automatically? When I had the issue earlier, PTC tech support could not find a solution so I closed the call hoping WC 11 and the new adapter would allow the startup to work.

RandyJones · ‎Jan 08, 2018

@BenLoosli wrote:

Continuation of same problem but different versions!

I have upgraded to Windchill 11.0 m030 and installed CreoView Adapters 4.1 F000.

The WorkerDaemon starts on the publishing machine at startup from the GS Worker service.

The proeworker will not start automatically. I have to log into the publishing machine and start proeworker.bat every day. Once started publishing runs fine for that day.

Has anyone seen this issue with the system not fully starting automatically? When I had the issue earlier, PTC tech support could not find a solution so I closed the call hoping WC 11 and the new adapter would allow the startup to work.

Basically all proeworker.bat does is to start a workermonitor.exe process. The workermonitor.exe process is what Windchill uses to start/end the Creo Parametric session. The workermonitor.exe process then "lives" forever unless you kill it the the Worker Agent Administration dialog or from the cadworker machine's task manager or you restart Windchill. So this is why starting it manually would allow publishing to work.

Your issue sounds like one of two possibilities:

Your cadworker Windows firewall is preventing Windchill from running proeworker.bat
- I have had this happen
- Turn off the Windows firewall to see
You have the incorrect path to the proeworker.bat file in your agent.ini file
- <Windchill>/conv/wvs/agent.ini

A couple of ways to debug:

look in the <Windchill>/logs/cadagent directory for log files
- The log files contained under here will generally provide a good clue as to the issue
stick an "echo something to some file" in your proeworker.bat file to see if it is actually getting called ie:
- echo Here at proeworker.bat >> c:\home\cadworker\proe_setup\startup.log

BenLoosli · ‎Jan 09, 2018

Randy,

Not seeing anything out of the ordinary in any log files. Windows firewall is turned off due to it being a private network.

The GS Worker service starts automatically and this is the WorkerDaemon.exe. Is this also supposed to start/launch the proeworker,bat to start the workermonitor.exe process?

Everything works fine as long as I start the proeworker.bat file manually. What PTC and I could not resolve was how to get the proeworker.bat file to launch at system startup. It used to work fine until one day it just quit. IT has done no system updates for over a year, so we ruled that out. Maybe I need to see if they changed some system level setting that did not require a patch.

RandyJones · ‎Jan 09, 2018

@BenLoosli wrote:

Randy,

Not seeing anything out of the ordinary in any log files. Windows firewall is turned off due to it being a private network.

The GS Worker service starts automatically and this is the WorkerDaemon.exe. Is this also supposed to start/launch the proeworker,bat to start the workermonitor.exe process?

No. The workermonitor.exe process is only started when something arrives in the publishing queue.

Everything works fine as long as I start the proeworker.bat file manually.

A couple of other things to look for:

What user is the WorkerDaemon.exe process being run as?
What user are you logging in and running the proeworker.bat as?

What PTC and I could not resolve was how to get the proeworker.bat file to launch at system startup. It used to work fine until one day it just quit. IT has done no system updates for over a year, so we ruled that out. Maybe I need to see if they changed some system level setting that did not require a patch.

Maybe changed the user the GS Worker service is being run as?

BenLoosli · ‎Jan 09, 2018

A couple of other things to look for:

What user is the WorkerDaemon.exe process being run as?

What user are you logging in and running the proeworker.bat as?

Worker Daemon is being run from the default system account..

When I launch it manually I am using my own account which has local admin rights on the publisher.

Maybe changed the user the GS Worker service is being run as?

I used to use a dedicated account but stopped that when we installed Windchill 10 in April 2014.

TomU · ‎Jan 09, 2018

Just to reiterate what Randy said, the proeworker.bat is used to start Creo and the worker monitor. It only starts up when something needs to be published or you manually start it. After the timeout period Creo will shut down but the worker monitor will stay running. You can manually start and stop both of these from the Worker Agent Administration panel.

BenLoosli · ‎Jan 09, 2018

On the publishing machine if I manually start Proeworker.bat, worker monitor starts.

When I submit a job for publishing, Creo launches and the file is created in Windchill.

From this standpoint, everything appears to be working and pointed to the correct pieces.

The system used to start proeworker automatically when the WorkerDaemon started. Creo would start and stop during the day as it was needed to publish jobs.

Then one day, it stopped starting. PTC said update to CreoView 3.1m030, no change. We had been on CreoView 2.0m040. Tried going back to CV2, still no autostart. Closed the call in hopes that CV4.1f000 used with Windchill 11.0m030 would allow the autostart to resume, no luck there.

What process triggers the proeworker.bat to run?

Is it the WorkerDaemon process from the GS Worker executable?

Has anyone else seen this issue?

It has done no updates to the system in over a year.

TomU · ‎Jan 09, 2018

The system used to start proeworker automatically when the WorkerDaemon started.

I don't think this is correct. I've certainly never seen this behavior. The GS Worker Daemon is a service that listens to Windchill. It does not start the worker monitor or Creo until instructed to do so from Windchill. Starting this service should not automatically start anything else.

I'm wondering if you could customize the .bat slightly. Maybe add a few extra lines to write something out to a text file. Then you would at least know if the .bat file was getting called. You also could turn on audit logging for this file and then see what gets recorded in the Windows log.

By the way, you can start the worker daemon manually without it running as a service. Just to test, stop the service and then manually start the daemon with your local user account. Go to Windchill and try to start that worker. If the worker monitor and Creo successfully startup you probably have a permissions issue with the service account.

BenLoosli · ‎Jan 10, 2018

I found this in a log file and have no idea what it means.

Log file is under Windchill logs\cadagent\GCEP006519-PROE1 folder and named GCEP006519-PROE1.log.

I tried to start publishing from the CAD Agent and it returned Failed to start. Log file said: Worker exe does not have any of the trusted prefixes.

Anyone know what trusted prefixes I need?

The batch files are all created by the Creo View Adapter setup program.

TomU · ‎Jan 10, 2018

Yes. You need to update some properties on the Windchill server. See these articles:

https://www.ptc.com/en/support/article?n=CS140965

https://www.ptc.com/en/support/article?n=CS182327

BenLoosli · ‎Jan 10, 2018

Thanks, Tom.

I also looked up the Dummys Guide thread on PTC/User to see what you and David had been referencing.

These changes must have come with 10.2, which is why I did not know about them as I went from 10.0 to 11.0.

BenLoosli · ‎Jan 11, 2018

Added wt.auth.trustedHosts to wt.properties with the publishing machine IP address.

Added worker.exe.whitelist.prefixes to wvs.ppeoperties with c:/PTC which is where the Adapter code is located.

Still will not start when I try from my session.

Still get the worker prefixes error.

Tried started proeworker manually and it starts but now when I submit a job it fails, too with PROE cannot be started error.

Back to the manuals to try to figure out what PTC changed to screw everything up.

RandyJones · ‎Jan 11, 2018

@BenLoosli wrote:

Added wt.auth.trustedHosts to wt.properties with the publishing machine IP address.

Added worker.exe.whitelist.prefixes to wvs.ppeoperties with c:/PTC which is where the Adapter code is located.

Still will not start when I try from my session.

Still get the worker prefixes error.

Tried started proeworker manually and it starts but now when I submit a job it fails, too with PROE cannot be started error.

Back to the manuals to try to figure out what PTC changed to screw everything up.

Despite what article CS140965 says:

https://www.ptc.com/appserver/cs/view/solution.jsp?n=CS140965

Using forward slashes will for the path separator will NOT work. You have to use back slashes:

c:/PTC (will not work)

c:\PTC (will work))

Example site.xconf entry:

Translates to wvs.properties entry:

worker.exe.whitelist.prefixes \=c\:\\PTC

Keep in mind this prefix is the path to the directory (or a parent of this) which contains your proeworker.bat or whatever you have configured for "exe=" in the agent.ini file. This is not necessarily where you installed creo view adapters.

RandyJones · ‎Jan 11, 2018

Translates to wvs.properties entry:
worker.exe.whitelist.prefixes \=c\:\\PTC

Correction the wvs.properties entry translates to this:

worker.exe.whitelist.prefixes=c\:\\PTC

TomU · ‎Jan 11, 2018

What Randy said.

Here is how I entered mine:

xconfmanager -s worker.exe.whitelist.prefixes=E\:\\ptc -t /codebase/WEB-INF/conf/wvs.properties

If you have more than one worker, make sure you include all of the trusted hosts inside double quotes.

xconfmanager -s wt.auth.trustedHosts="192.168.21.11 192.168.21.23 tmmpceng02" -t codebase/wt.properties -p

jbailey · ‎Jan 16, 2018

Have you tried to set the GS Worker Daemon to use a service account, and not a local account? Also, have you enabled windchill to use Trusted Hosts?

BenLoosli · ‎Jan 17, 2018

Tried both and the worker still will not start automatically.

I have opened a call with PTC, but not holding my breath as it is the same support engineer who could not solve the issue when it first started last October while still on Windchill 10, which did not have the higher security settings.

jbailey · ‎Jan 17, 2018

So our typical steps for setting up (I know yours stopped working- but this might help ring a bell)

Auth.properties file in <windchill home> with the authorized publishing user
Windchill props for trusted hosts - if worker is on a machine other than the WC server

<Property name="wt.auth.trustedHost" overridable="true"

targetFile="codebase/wt.properties"

value="<ipaddress worker 1> <ip address worker 2"/>

<Property name="worker.exe.whitelist.prefixes" overridable="true"

targetFile="codebase/WEB-INF/conf/wvs.properties"

value="C:\|c:\|D:\|d:\|"/>

If you are re-installing the worker (or installing a new worker), I always remove the GS worker daemon service from the registry and verify it is no longer in services, then install the CreoView adapter...
Set firewall rules for the in/out ports (I know you said you weren't using firewall)
Set the GS Worker Daemon user as a service account / or a network account to test
Set up share on the worker server (if different) where the worker will create temporary files. Make sure you can get to the shared folder from the WC application server AND create a file using the service account from the previous step.
Configure the adapter - (run proe2pv_config.exe)
Make sure the setup directory is correct
Make sure the start command is <setupdirectory\proeworker.bat
In the Server host field, host.domain ex mycoolPDM.mycompanyrules.net (no http/https, \Windchill, or port# here)
Enter the Server port - ootb will be 600, use the port you specified on the install
In Windchill. go to the worker agent administration
For host, don't use the FQDN ( so if it is cadworker.mycompanyrules.net just put cadworker) - obviously select Proe
Set where the worker location is setup (the windchill machine, another windows, etc)
Under execute command, ensure that it is the <creo setup location>\proeworker.bat <<< double check this for spelling! This is usually where we foul up. Set your startup time. Our defaults are Startup time 30s, auto idle stop 60s, autobusystop 3600s, and AutoStart ischecked.
Specify the worker daemon port - ootb is 601, use the one you specified on install.
For common file system (files on another machine)
<networksharedpath\myworkerfolder> ex \\cadworker\SharedWorker\myworkerfolder
<cadworker> path - use the actual drive letter mapping here - ex c:\ptc\shared\myworkerfolder
Make sure to hit apply on the nexst screen
Make sure to Click "Save File" on the WCW Step 1 screen
return to worker agent administration
Reload workers
Go back to the worker machine, and open up the setup configuration... and run the Test tool to verify connection.
If you have multiple method servers, we set xconfmanager -s wt.queue.executeQueues=false -t \codebase\wt.properties -p

Sometimes we have had to restart the worker machine after initial configuration

jbailey · ‎Jan 17, 2018

Sorry, had a mistake... when setting up the adapter...

The start command is the link to the parametric start batch file. Make sure when you run the batch file - that creo ACTUALLY starts.

D:/ptc/<creo folder on server>/Creo 4.0/M010/Parametric/bin/<batch file to start creo>.bat

the bat file may or may not call out a psf file which specifies environment variables, license, etc...

Once you launch Creo using the batch file, I always try to connect to Windchill using the internal creo browser as the user specified in auth.properties. One VERY important note.... this process needs to be prompt free. No error messages, no java errors on the page etc.... We ran into this issue before where IT Security has changed IE policies on servers which disabled certain things (java, set compatability etc). IF you cannot log in as the auth.proeprties user and get a clean, prompt free windchill after login- the worker will NOT work