Community Tip - If community subscription notifications are filling up your inbox you can set up a daily digest and get all your notifications in a single email. X
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?
@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.
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?
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.
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.
@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:
A couple of ways to debug:
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.
@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 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?
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.
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.
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.
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.
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.
Yes. You need to update some properties on the Windchill server. See these articles:
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.
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.
@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:
<Property name="worker.exe.whitelist.prefixes" overridable="true"
targetFile="codebase/WEB-INF/conf/wvs.properties" value="c:\PTC" />
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.
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
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
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?
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.
So our typical steps for setting up (I know yours stopped working- but this might help ring a bell)
<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:\|"/>
Sometimes we have had to restart the worker machine after initial configuration
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