Hi James Toner,

This can happen if you change the sa password and don't create / update an entry for it in the Execution Server Settings.

To do this, log into your server using Remote Desktop and run the GroupShare Console. Go to Settings and locate Execution Server Settings. If there is not already an entry in the list then choose +Add... followed by Server-based Translation Memory Credential.... If you already have an entry then just select, and Edit it.

It should look something like this:

Make sure you specify the correct protocol (either http or https) and click OK when you've finished. Then click Apply Changes under Actions -> Settings. A services restart is required.

Kind regards,
Nick

@Nick Date

Hi Nick,

Thanks for this.

I was hopeful your solution would work, because we had indeed changed the admin password.

However, it does not seem to have resolved the issue (still no lookups, no TM matches).

What other avenues might we explore?

Thanks,

James

Hi James Toner,

Are there any clues in the GroupShare log files? The default location is C:\ProgramData\SDL\Service\Logs

First I would open one of the files in Online Editor and move around between segments (where you should get matches, but don't). Then check the TMService.log and TMServiceAgent.log files in the above location to see if there are any errors or warnings, and post anything relevant here.

Quick question - do you have different internal and external URLs that your translators use depending on whether they connect to the GS server from inside or outside your network?

Kind regards,
Nick

@Nick Date

Hi Nick,

Several logs are written to when we connect – I have included the final entries of the following logs:

EditorService.log

2020-02-06 17:15:16.1015|XX-DMZXXXXXXXXX123|Warn|THREAD_ID:7|TR_ID:f4c11a97-c7ed-4166-b7be-87947c354a68|CONN_ID:cf2b7e17-bab3-4e5a-8209-390c6d5760a6|DOC_ID:6f244e38-cc7e-4135-bbfa-0712f847e25d|No resources available for lookups!

TMServiceAgent.log

2020-02-06 17:15:21.2735|XX-DMZXXXXXXXXX123|Warn|THREAD_ID:60|TR_ID:3115be88-1c32-48d3-a41a-01e054e02d7c|OTHER:WorkerId=db3eaf2f-cded-4430-b608-8eebac703dd0|Bearer lifetime was removed

Although TMService.log did not write at the same time, I am including the final entry here:

2020-02-06 10:48:47.0444|XX-DMZXXXXXXXXX123|Warn|THREAD_ID:28|TR_ID:c6b8b9fc-bf3a-4e44-ad2f-600526b14920|Translation Model Service call failed | Method:GET | Uri:lmnspqurv.ab.ccc.dd.eee.com/.../should-build | Status:404 Not Found | Content:

Assume this last one is not relevant, but just in case:

Sdl.Router.log

2020-02-06 17:16:19.457#Router.IssuedTokenRouter#Forwarding response sdl.com/.../HasNewSynchronizationPackageResponse version Soap11 (schemas.xmlsoap.org/.../) AddressingNone (schemas.microsoft.com/.../none)

For your final query, we are currently testing internal users only, so the issue I believe is not (yet) relevant.

Many thanks,

James

Hi James Toner,

The only other thing I can suggest is to change the AppParameters keys in the following locations of the Windows Registry, and then restart the GroupShare services (make sure you back up the registry keys first):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SDL Feedback Service\Parameters\ :

-XX:NewRatio=7 -Xmx1024m -jar "C:\Program Files\SDL\SDL Server\Feedback Service\gs-feedback-service.jar" --spring.profiles.active=std --logging.file="C:\ProgramData\SDL\Service\Logs\gs-feedback-service.log" --server.port=41259 --gs.proxy.location=localhost --gs-management-service.ribbon.listOfServers=localhost --translation-memory-service.ribbon.listOfServers=localhost

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SDL Translation Service\Parameters\ :

-XX:NewRatio=7 -Xmx1024m -jar "C:\Program Files\SDL\SDL Server\Translation Service\gs-translation-service.jar" --spring.profiles.active=std --logging.file="C:\ProgramData\SDL\Service\Logs\gs-translation-service.log" --server.port=41258 --gs.proxy.location=localhost

Note that this assumes that the web server and application server are the same. If they are not then use the FQDN of the application server instead of localhost. It also assumes that GroupShare is installed on drive C: so please adjust accordingly.

If this still doesn't work, and your SMA contract covers this server (i.e. it is not a self-installation) then please log a case for SDL Support to investigate further. If it is a self-install then please contact your SDL account manager and request an SDL Professional Services consultancy.

Kind regards,
Nick