CAD worker gives "WWGM ERROR: Error from UWGM-Registration with server failed" error

[Dobi]

Version: Windchill 13.0

Use Case: We upgraded the dev server from WC12 to WC13. I prepared a new CAD worker with clean CAD/WGM/Adapter installations. It connects fine, tests fine (when worker in Worker Agent is in offline mode) but on a publish job gives a "WWGM ERROR: Error from UWGM-Registration with server failed: The server couldn't be found at the given location" error. Why? The dev environment was a new VM with a clean install and then migrated over our production settings. Is there some dangling pointer to the prod server that's messing with this?

Description:

We upgraded the dev server from WC12 to WC13. I prepared a new CAD worker with clean CAD/WGM/Adapter installations. It connects fine, tests fine (when worker in Worker Agent is in offline mode) but on a publish job gives a "WWGM ERROR: Error from UWGM-Registration with server failed: The server couldn't be found at the given location" error. Why?

[VladimirN]

Articles:

• "WWGM ERROR: "The workspace couldn't be found" or "The server couldn't be found at the given location" is received while publishing objects through 3rd party CAD worker": https://www.ptc.com/en/support/article/CS315692 
• "Publishing jobs fails with "Error from UWGM : Registration with server failed : Authentication failed" in Windchill PDMLink": https://www.ptc.com/en/support/article/CS119692 

[Dobi]

All of that seems fine.

What I'm seeing as the behavior is that the .ws (PTC_WLD_ROOT) doesn't get created when I send a job to the worker. But if I log into Windchill on the worker WGM, the PTC_WLD_ROOT folder creates fine. 

[avillanueva]

This sounds like the service account running the job may need some tweaking.:

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

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

[Dobi]

The worker daemon has no issue starting up and staying running. It runs under my account on this system. And the worker daemon starts up the worker just fine. 

[avillanueva]

It may start up but it still can see issue like you described. The clue is that if you log in, it works fine. Can you provide details on how the service is configured? I have all my workers run a batch file that setups up any environment variables so each instance is self-contained. Have you tried to have the service run as the SYSTEM account? If you are having it run as you on this system, I vaguely remember your account needed to be elevated. 

[Dobi]

I have it setup so that it's self-contained, borrowing heavily from a lot of your posts and suggestions to my other CAD worker issues. 

It's an NX worker. 

It has it's own Worker Daemon and port (CS49182 ). It does run as my account which is the admin account on that machine. I haven't tried running this as a SYSTEM account but will.

In the ug_setup folder I have the ugworker.bat set the PTC_XXX_xxx environment variables when it's kicked off and also there's a ugstartup.bat that runs (-su "ugstartup.bat") to clean up .ws and .wf folders on starts/restarts. 

At this time this is the only worker on that machine. 

This exact same setup (literally exactly the same) is on my other 3 machines with several workers each, and this works just fine. 

[Dobi]

Can confirm that running as local system account gives the same error. The .ws folder is never created.

[Dobi · Accepted solution]

Ok, so... this is fixed. 

The issue was site.xconf + company.xconf file related. 

Both had wt.auth.trustedHosts called out. The company.xconf (that is linked to the site.xconf) had the worker details in it's value and then the site.xconf had the same attribute but further down... overwriting the company.xconf values. 

Consolidating these fixed the issue. 

[vnamboodheri]

Hello @Dobi,

It looks like you have a response from our community champion. If it helped you solve your question please mark the reply as the Accepted Solution. 

Of course, if you have more to share on your issue, please let the Community know so other community members can continue to help you.

Thanks,
Vivek N.
Community Moderation Team.