If a user is running Windows with active directory and the user that jobs are run as is a domain user, then the local profile (e.g. %LOCALAPPDATA% directory) does not seem to exist for that user until the user has done an interactive logon. So, if a job that is run by the worker agent makes use of the user's local profile (e.g. putting fonts in %LOCALAPPDATA%) then that job will fail and the root cause is unlikely to be obvious.
Proposed Solution
There does seem to be a workaround, but it would be nice if users didn't have to employ the workaround.
In the worker agent, before creating the logon token (or when creating the openjd.sessions.SessionUser for a username/password combo outside of the service context) do a call to the Win32 CreateProfile API.
Alternative solution to investigate may involve loading the domain user's roaming profile in the LoadProfileW API call; that appears to require setting the lpProfilePath property of the lpProfileInfo structure.
Use Case
If a user is running Windows with active directory and the user that jobs are run as is a domain user, then the local profile (e.g. %LOCALAPPDATA% directory) does not seem to exist for that user until the user has done an interactive logon. So, if a job that is run by the worker agent makes use of the user's local profile (e.g. putting fonts in %LOCALAPPDATA%) then that job will fail and the root cause is unlikely to be obvious.
Proposed Solution
There does seem to be a workaround, but it would be nice if users didn't have to employ the workaround.
In the worker agent, before creating the logon token (or when creating the openjd.sessions.SessionUser for a username/password combo outside of the service context) do a call to the Win32 CreateProfile API.
Alternative solution to investigate may involve loading the domain user's roaming profile in the LoadProfileW API call; that appears to require setting the
lpProfilePathproperty of thelpProfileInfostructure.