Community Tip - When posting, your subject should be specific and summarize your question. Here are some additional tips on asking a great question. X
Likely something trivial that I'm missing but:
- Had a great running setup with adapter version 9.0
- Installed and updated adapter to version 10.1 (pointed to existing installation for the worker .bat files)
- if I kick off the worker.bat by my self everything works fine. But try as I might, the Worker Agent doesn't seem to trigger anything on the worker.
I checked services, all the .bat files and everything seems fine.
Solved! Go to Solution.
Looks like for major version upgrades, @HelesicPetr is right.
Using existing installations isn't recommended even if completely new worker daemon services are made.
With 10.1, there was a firewall blocking the daemon from starting and the windows access permission only popped up when I started the daemon for the right port manually.
CS25414 is the recommended process for upgrades.
Did you check the Windchill property for worker.exe.whitelist.prefixes?
The value MUST match exactly what windows reports the folder is, it is case sensitive.
I have the same issue on one of my 3 Windchill servers. Two of them will start publishing automatically but the one that was upgraded from 7.0.10 to 9.0.5 will no longer start. It did start with 7.0.10. If I start proeworker.bat manually, then disconnect from the server the publishing will work after I start it up from Worker Administration.
I confirmed that the list is correct there too.
The port numbers are right too.
I did make separate worker daemon services for the different ports because I have a number of workers on that machine but those look correct... just somehow don't get started. Something is just not talking on the right channel.
Check the paths in all these files. Make sure the new path to the 10.1 adapters folder matches. Did you also fix your worker daemon services?
Checked all the paths and confirmed they are correct.
Confirmed that the WorkerDaemon is correct... to make sure, I even created a new service and had just that one run.
Still nothing. Everything works if I manually start the worker.bat. On start from worker agent, the worker monitor isn't coming up.
Hi,
Typically I perform the below steps if my newly configured worker doesn't start.
You can try this and check if it helps you.
Regards,
Hemant Chaugule
There are no logs when I try to start the CAD worker. Just "Fails to start" shows up in the Worker Agent.
However, everything is communicating just fine on the right ports (and those haven't changed) via telnet.
The hosts file is unchanged and the agent.ini looks correct.
How fast does it come back when it shows fails to start? If very quick, check the worker daemon service, ports and firewalls. If it sits for a bit, it likely issues the command to start but times out.
It's the latter. Sits for a bit.
Doesn't look like the command gets to the CAD worker though. The startup.bat never kicks on.
Hi @Dobi
Have you used old configuration settings from a previous adapter? Proe-setup folder?? If so
Create new configuration. and new proesetup folder.
PetrH
Hi @HelesicPetr
For Creo, yes. And that one worked just fine.
For NX and Office, I did the same, but those are now struggling.
I have a call with tech support on this tomorrow.
For the particular system in question:
- the Creo instances updated just fine with the new adapter version and using the existing installations.
- the NX and Office installations have the "fail to start" error
I have separate worker daemons and ports for the workers on this machine and the issue seems to be with the worker daemons. The office worker worked fine when the worker daemon service was still pointed to the adapter 9.0 version worker daemon service. However, when I created a new service at the 10.1 level is when it too started behaving like the NX worker that fails to start.
Both work just fine if I manually launch the worker.bat file. So something with the worker daemon at that version seems to be unhappy.
Looks like for major version upgrades, @HelesicPetr is right.
Using existing installations isn't recommended even if completely new worker daemon services are made.
With 10.1, there was a firewall blocking the daemon from starting and the windows access permission only popped up when I started the daemon for the right port manually.
CS25414 is the recommended process for upgrades.