CAD worker fails to start

[Dobi]

Alas, in a flood of "CAD worker isn't working" posts I do think I have a new one... 

Running on one VM are 2 instances of Creo and 1 instance of NX. 

The two Creo instances are identical (copy/paste) with edit to names (i.e. "instance 1" folder and "instance 2" folder).

WorkerDaemon is set up as a service and runs automatic with a local system account.

After a restart, when I check the the worker agent, the 3 instances on this machine (and only this machine. The other 2 work fine and are setup the same) shows the workers as not started and the worker monitor is off. 

If I toggle the workerdaemon to try to get some action, nothing happens. 

I can start the worker monitor manually and then only 1 of the 2 Creo instances starts. The only way I can get the other Creo and the remaining NX workers to start is to manually launch their respective worker.bat files. 

Not sure what else to look at.

Ports that are used for the workers? 

[Ajit_Kulkarni]

I hope you have checked this check box.

 

Could you please give us OS details ? 

[Dobi]

It's checked, yes. 

OS is Windows Server 2019

[Ajit_Kulkarni]

We too face this issue for SW 2021 and WGM 12.1 on Windows server 2019. 

I am not sure but its security related stuff in Windows server 2019. In 2016 it works just fine.

Solution : We are using "FireDaemon Pro 4 " software. You can download demo version and try. 

[rhart]

Also seen this with CAD workers, Windows 10 (version H21h2) works fine, but Windows 10 (version 1607) can't launch the CAD application unless a user is signed, so foreground mode only

[MikeLockwood]

It's really pretty incredible that PTC has not come up with a definitive instruction / procedure for setting up publishing of Solidworks on a server.

To my knowledge, the only supported way is to use a Windows 10 machine for publishing Solidworks.

Every admin seems to have to struggle with similar problems and it's really hard to get it stable and reliable.

[VishwasAnantwar]

Hi Mike, 

https://www.ptc.com/en/support/article/cs245930 does not answer everything but could be helpful for admins. 

[VishwasAnantwar]

Dobi,

Have you configured it as Instances or aliased workers?

When the worker monitor does not start it indicates that Server --> Worker or Worker--> Server communication is not happening and that could be due to ports or hostname entries

You may need to add the aliased name in the Server hosts 

The port should work for each aliased name 

From Worker --> Server -    telnet Server_name 5600

From Server --> Worker - telnet Worker_aliasname 601(or port which workerdaemon runs on)

Hope this helps

Vishwas 

[Dobi]

@VishwasAnantwar my friend, I must admit that when I changed companies I felt a good bit of sadness in realizing I may not get to work with you directly anymore. I am very glad that not the case 🙂 

I was trying to remember and in a way retrace steps you walked me through back a few years ago on this topic. I followed the documentation and I think the bit I missed is editing the Server hosts file. 

The workers are aliased and the while I did update the worker machine hosts file I did miss the server. 

I'll be able to test this after hours to confirm.

Many thanks!

Dobi

[Dobi]

Alas, updating the hosts file on the server didn't fix the problem. Still the same behavior. 

[Dobi]

Your approach did point me in the right direction. The reason only one of the workers on that machine gets kicked off by the daemon is because that's the only one I can telnet to. I cannot to the others. 

[avillanueva · Accepted solution]

It may seem overly complicated but I have normed to setting up my workers as if they were on independent machines. 1 worker per, each with their own virtual hostname, port, FTP folder and dedicated daemon. They all essentially run on the same machine in reality but act as if they are not.  

There are so many ways that these can be configured. 

[Dobi]

At the moment it seems that the alias is the issue. 

hosts files on both the worker and server are updated but I can't ping the aliases from the server. 

[avillanueva]

Alias needs to be added to the server hosts file.

[avillanueva]

sorry, I replied too quickly from my phone. Double check settings. You should be able to ping CAD worker from server since without that, it does not know where to send the request to. Here is what my hosts file says on my server:

<ip address> cadworker1 cadworker2 cadworker3 allegroworker1 captureworker1

This matches my CAD Admin screen above. On the CAD worker, it need not have those in its hosts file the worker batch file should point to the server AND tell it which host it is:

"C:\ptc\creo_view_adapters_7.1\x86e_win64\obj\workermonitor" -su "C:\ptc\cad_workers\creo7worker1\proestartup.bat" -UH -s "C:\ptc\creo_view_adapters_7.1\x86e_win64\obj\proe2pv" -DA cadworker1 -vt -r proe2pv.rcp -EW PROE -CS<server hostname> 5600

that -DA parameter is key.

Some tests I've tried is if I manually start the worker by running the batch command, see if the server sees the connection. If it works, issue lies on the server side or the GS Worker Daemon, firewalls, etc. The startup process is the server connects via the port to the GS Worker Daemon and tells it to run the startup command. The Worker connects back to the server on port 5600 to announce itself. From there it is able to send jobs over for it to process.

[Dobi]

I have the -DA parameter in there. Cache separation btw Creo instances and NX (on the same machine), taskkills for clean launches etc.

The problem is somewhere with the worker daemon. 

When its in automatic mode, I get a "fails to start" in the worker agent. But if I launch the worker.bat files manually, everything works fine. 

When I set the worker to manual mode and run as admin, then all of my instances come up just fine from the worker agent. 

So the issue seemingly is that the worker daemon service in automatic mode doesn't register the request from the server. 

[avillanueva]

Which user is running the worker daemon? Is it a normal user or the system? Also may want to eliminate firewall issues?

[Dobi]

System is running the worker daemon. 

Although for the OFFICE publisher, the documentation requires it to run as a user. How did you set up multiple daemons? 

We checked firewall... no issues there (as in: it's the same behavior with and without it up). 

[avillanueva]

Check out this article:

https://www.ptc.com/en/support/article/CS49182?source=search

Each one of my workers has its own port. That way if the daemon goes down, it does not take them all out.