Windchill Windows Service install - run as "Local Service" & Windchill load point permissions issue

[GaryMansell]

Version: Windchill 12.1

Use Case: Installing Windchill 12.1 OOTB, then install the Windchill Windows Service using the Ant script - now sets the Service logon account to (low privileged - good) "Local Service" instead of "Local System" (high privileged - bad). But, the default permissions on the installed Windchill load point do not allow "Local Service" access to all the necessary files in the load point to start Windchill Successfully (Windchill starts from an Admin Windchill Shell OK).

Description:

Hi,

I think this may be new at 12.1 release (I can't remember seeing this at 12.0)?

It seems that doing a default install of Windchill 12.1 via the PSI as Local Admin (which I think is preferred & documented PTC install process?) and then creating the Windchill Windows Service by running the ant script - creates a Windows service that logs on as "Local Service", but this user does not have read access to all the necessary files in the Windchill load point for Windchill to start via the service.

This was a bit of a show-stopper that stumped me for a while until I noticed the change from "Local System" as I think it used to be.

I strongly support running Windchill as a low privileged "Local Service" account, if possible - but the OOTB Windchill install needs to leave the installed load point in a state that this will work with the "Local Service" user, surely?

Am I missing something here, or doing something wrong - as I see no mention of this in the Windchill install docs?

What are others doing to allow Windchill to run from a Windows Service as "Local Service" - as I would imagine (if you are managing the install as Local Admin, which is recommended), that doing system modifications/installs/patches, could again scatter admin read-able only config files in the load point that would break the Windows Service (as Local System) startup again.

[mmeadows-3]

I noticed the same issue and worked around it by running the Windows service as a domain service account that is a member of the local Administrators group.  Otherwise, Windchill will not start with some error about unable to modify the adapterservice.json file.

[GaryMansell]

Hi, yes, this is exactly the same situation.

I support the idea of PTC now running the Windchill Windows Service as a low privileged "Local Services" account - but they need to be clearer about what the implications of doing this are for the Windchill load point (and after any patching/regen scripts are run downstream after install). Otherwise admins can end up in an E-Down situation without realising why.

To be honest - if PTC are now defaulting to "Local Services" for the Windows Windchill Service account - then their PSI installer should leave the Windchill load point in a state that this will actually work...

Does anyone know exactly what needs doing to the Windchill load point to allow the Windchill Windows Service to run as "Local Service", and is this a sensible/safe/supported way of working?

[GaryMansell]

Update on this from PTC Tech Support...

It seems that if the ant tool that creates the Windows Windchill Service is ever run from a windchill shell without "run-as Admin" rights - it will always subsequently create the Service with the Account "Local Service", even if run from a subsequent Admin Shell. This is not expected behaviour so they are going to look into this.

FWIW, I don't think I did run as a non-admin user (but it's possible). It may be to do with how I set the Program Icon for the Windchill Shell's compatibility tab to always run as admin for all users...